Batch Processes
This section describes the batch processes used in processing recurring automatic bill payments through third-party payment processing systems:
Batch Flow - Recurring Automatic Payment Processing and Tender Controls
This flow includes the following:
Note: All the three batch processes require the use of object storage for sending/receiving files to/from the application. Refer to Connecting the Oracle Utilities Application to OCI Object Storage for information about connecting the Oracle Utilities application (example: Oracle Utilities Customer Cloud Service) to OCI Object Storage.
Third-Party Auto Pay Extract (C1-TAPEX)
This batch process is responsible for extracting bill auto pay transactions that are scheduled to be processed by a third-party payment processing system.
The plug-in driven batch process is delivered with a Select Records algorithm and a Process Record algorithm. Refer to the C1-TAPEX-PR and C1-TAPEX-SR algorithm type descriptions in the application for more details.
Refer to the Interfacing Automatic Payments To A Third Party in the user documentation for more details.
Third-Party Automatic Payment File (from CCB)
This is the output file of the Third Party Auto Pay Extract (C1-TAPEX) process. Each detail record in this file will contain comma-separated values (CSV) that include the following:
Field
Comments
Account ID
Unique identifier of the Account in CCB
Auto Pay Amount
 
Due Date
 
Maximum Withdrawal Amount
If applicable
Auto Pay Staging ID
Unique identifier of the auto pay transaction record in CCB. This needs to be passed back when the third-party payment processing system sends subsequent auto pay confirmation or cancellation.
A footer record in this file contains the following:
Field
Comments
Total Number of Records
Total number of auto pay detail records in the file
Total Amount
Sum of auto pay amounts in the file
Third-Party Auto Pay Confirmations(C1-TAPDF)
This batch process receives a file containing the IDs of auto pay transactions that the third-party payment processing system had processed successfully. For each auto pay transaction, the associated payment is distributed and frozen, to reflect on the account’s outstanding balance.
This plug-in driven batch process is delivered with a Process Record algorithm. Refer to the C1-TAPDF-PR algorithm type description in the application for more details.
Third-Party Automatic Payment Confirmation File (To CCB)
This is the input file for the Automatic Payment Confirmation (C1-TAPDF) process. Each record in this file should contain comma-separated values (CSV) that include the following:
Field
Comments
Account ID
Unique identifier of the Account in CCB
Auto Pay Staging ID
Unique identifier of the auto pay transaction record in CCB.
 
This information is sent with the Automatic Payments File. CCB needs this to locate the pending transaction.
Payment DateTime
As a standard, inbound and outbound communication with an external system use the standard xsd datetime format - yyyy-MM-dd'T'hh:mm:ss[+|-]hh:mm
 
Example: 2017-02-28T09:15:00-08:00
Third-Party Auto Pay Cancellations (C1-TAPCN)
This batch process receives a file containing the IDs of auto pay transactions that the third-party payment processing system did not process successfully. For each auto pay transaction, the associated tender and payment are canceled, leaving the account's outstanding balance unchanged.
This plug-in driven batch process is delivered with a Process Record algorithm. Refer to the C1-TAPCN-PR algorithm type description in the application for more details.
Refer to the Automatic Payment Confirmations and Cancellations section in the user documentation for more details.
Third Party Automatic Payment Error File (To CCB)
This is the input file for the Third Party Auto Pay Cancellations (C1-TAPCN) process. Each record in this file should contain comma-separated values (CSV) that include the following:
Field
Comments
Account ID
Unique identifier of the Account in CCB
Auto Pay Staging ID
Unique identifier of the auto pay transaction record in CCB. CCB needs this to locate the pending transaction.
Third-Party Auto Pay Tender Controls (C1-TAPCT)
This batch process creates a new tender control (with an associated deposit control) for each batch control and run number encountered for third-party bill automatic payments that are not already linked to a tender control.
This plug-in driven batch process is delivered with a Select Records algorithm and a Process Record algorithm. Refer to the C1-TPCT-SR and C1-BLAPY-PR algorithm type descriptions in the application for more details.
Batch Flow - One-Time Payment Tender Controls
This section includes the following:
Third-Party One-Time Payment Controls Pre-Processing (C1-TOPPP)
This batch process ensures that the one-time payment tender control includes payments that were processed within the designated cutoff time.
This batch process will retrieve auto pay staging records and check the processing date/time from the associated payment tender's characteristic. If the processing date/time is past the cut-off defined in the third-party integration master configuration, the batch number will be updated to the next batch number, which indicates that the record will not be processed.
This plug-in driven batch process is delivered with a Select Records algorithm and a Process Record algorithm. Refer to the C1-TOPPP-SR and C1-TOPPP-PR algorithm type descriptions in the application for more details.
Note: The Third Party Payment Pre-Processing batch control is stamped on the auto pay staging record as soon as the one-time payment is created and frozen. A post-processing script defined in the Third Party Payment Processing Integration master configuration does this. Refer to the Third-Party One-Time Payment - Post-Processing script (C1POSTTPOTP) section for more details. This script gets the batch code from the One-Time Payment Pre-Processing section of the master configuration where the C1-TOPPP batch control should be defined.
Third-Party One-Time Payment Tender Controls (C1-TOPCT)
This batch process creates a new tender control (with an associated deposit control) for each batch control and run number encountered for third-party one-time payments that are not already linked to a tender control.
This plug-in driven batch process is delivered with a Select Records algorithm and a Process Record algorithm. Refer to the C1-TPCT-SR and C1-BLAPY-PR algorithm type descriptions in the application for more details.
Refer to the Automatic Payment Confirmations and Cancellations section in the user documentation for more details.