Input Format for .CSV Files |
  
|
Navigation: Teller System > Transactions > Loan Transactions > Batch Transaction Program >
Input Format for .CSV Files |
|
Batch transaction requests must be submitted in a properly formatted comma-separated-values (.csv) file. This file can be created as a spreadsheet in Excel. The table below explains how to properly format this file.
Note: Fields 1–3 are required for all transactions. The other columns may be optional depending on the transaction. See the following table, followed by another table describing the transactions available for batch processing and which columns are required for each.
Field |
Content/Columns |
|---|---|
1 |
Office and Account Number: OOOOAAAAAA |
2* |
Effective Date: MM/DD/YYYY |
3 |
Transaction Code (see Transaction table below) |
4 |
Transaction Modifier (see Transaction table below) |
5 |
Correction Indicator (“C” or “c” indicates a correction) |
6 |
This column can be one of four code numbers:
1.New General Category for charge-offs (see General Category table below) 2.Descriptor code for payments (see Payment Descriptor table below) 3.Event Code for Write-offs (see Event Code table below) 4.Fee Code for assessment (tran code 660-00) or fee payment/correction (tran code 850-01, see Fee Code table below) |
7 |
TORC. For a list of possible TORCs, see Loan System TORCs |
8 |
Amount Field #1 (decimal point included, no dollar sign (“$”)) |
9 |
Amount Field #2 (decimal point included, no dollar sign (“$”)) |
10 |
Amount Field #3 (decimal point included, no dollar sign (“$”)) |
11 |
Any text that the user wants put into an F2QH record (up to 240 characters). This text will appear in Collection Comments on the Loans > Marketing and Collections > Contact tab.
Duplicate Transaction Options This column can also be used if you want to run two identical transactions for the same account in the same batch transmission. The transmission program does not normally allow two identical transactions on the same account unless a JCL option is set (Bit 40, see JCL Options below). If your institution does not have that JCL option set but still wants to process duplicate transactions, simply use this column to indicate different text for each transaction. Your institution can also set another JCL option (Bit 20) that will stop creation of the F2QH record (in other words, the collection comments) for these accounts. |
*The Effective Date can be backdated, but not prior to the last transaction date (LNTRAN). If you attempt to backdate the effective date before the last transaction date, the system will automatically adjust the effective date to be the same as the last transaction date (this is done so the transaction will not fail). However, there is a JCL option (Bit 80) your institution can implement that will cause the transaction to fail if the effective date of the transaction is before the last transaction date on the account (see JCL Options below). The account will show in the Batch Tran Output Report with the message “NO BACKDATING PAST CUST LAST TRAN DATE.”
If the Effective Date is invalid or filled with zeroes (00/00/0000), the program uses the current run date as the effective date. This is a time-saving way to ensure that the transactions will be recorded as effective on the date that they are run.
Transaction Codes and Modifiers
Teller Tran Code |
Modifier |
Description |
Required Columns |
|---|---|---|---|
1 |
Charge-off |
1-6 |
|
2 |
Charge-off Correction
The program will accept a 2022 mod 1 with “C” in the Correction field (Column 5) and will reverse a 2022 mod 2 to execute the correction. |
1-6 |
|
25 |
Payment |
1-8 (7 is optional) |
|
47 |
Principal Increase |
1-8 (7 is optional) |
|
47 |
Principal Decrease |
1-8 (7 is optional) |
|
53 |
Interest Increase |
1-8 (7 is optional) |
|
53 |
Interest Decrease |
1-8 (7 is optional) |
|
550 |
0 |
Pay Late Fee |
1-8 (7 is optional) |
560 |
0 |
Assess Late Fee |
1-8 (7 is optional) |
570 |
0 |
Waive Late Fee |
1-8 (7 is optional) |
0 |
Assess Fee |
1-8 (7 is optional) |
|
670 |
0 |
Waive Fee |
1-8 (7 is optional) |
0 |
Spread Payment Amount Field #1 has amount to principal |
1-10 (7 is optional) |
|
1 |
Pay Miscellaneous Fee |
1-8 (7 is optional) |
|
0 |
Partial Write off |
1-8 (7 is optional) |
|
05 |
Full Write off |
1-6 |
|
08 |
Repo Write off |
1-5 & 8 (6 & 7 not used) |
|
12 |
Sale of Security Full Write off |
1-6 |
|
1 |
Convert to Interest Bearing (PC2IB at maturity)
The program will accept a 2741 mod 1 with “C” in the Correction field (Column 5) and will execute a reversal to the previous precomputed to interest-bearing (PC 2 IB) transaction. |
1-4 (1-5 for correction) |
For charge-off corrections, the value given in Column 6 must be something other than the values in this list or the transaction will fail. For example, the value might need to be the general category from before the charge-off. |
The following table shows the text that appears in system history for indicated Payment Descriptors (tran code 2600-25). See the linked help for further information about descriptors.
|
Event codes are used with the Write-off Transaction (tran code 2510-05). When loans are written off, they can be reported to the government on a 1099-C (Cancellation of Debt). The 1099-C form requires an event code, as shown in the following table:
|
As of the HostBuild20210301 branch (April 2021 Update), we now offer the ability to assess or waive miscellaneous fee codes (tran code 850-01) on accounts using the Batch Transmission file. Possible fee codes are:
|
GPS offers three JCL options that can be set up to adjust the batch transmission file. You must contact your GOLDPoint account manager if you want any of these options set up, and the necessary setup may require a few days. You can also request a special run at any time.
1.Bit 80 will cause a transaction to fail if the effective date entered in the .csv file is before the date of last transaction (LNTRAN). The failed transaction will appear in the Batch Transmission Rejected Output Report with the message “NO BACKDATING PAST CUST LAST TRAN DATE.” If this bit is not set, the effective date of the transaction will instead be automatically set to match the date of last transaction (so the transaction will not fail).
2.If Bit 40 is on, the transmission upload process will not check for duplicate transactions on the same account, which means you can run more than one of the same transaction on the same account in the same transmission file. If this bit is not set, any of the same transactions run on the same account in the same transaction will be rejected and appear on the transmission report with the message “SKIPPED AS DUPLICATE.”
3.Bit 20: If Bit 40 (see above) is not set, and you want to allow duplicate transactions for some accounts, this bit can be set. Bit 20 allows users to enter information in Column 11 on the duplicate transactions they want to process. If this bit is set and Column 11 is being used to enter different text for one transaction that is the same as another transaction on the same account, the system will block the creation of the collection comment and the duplicate transactions will process successfully. |
