Business Flows
This integration supports the following business processes:
General Ledger Extract Process OS (Oracle Utilities Customer Cloud Service Initiated)
This integration process is used to transfer all approved General Ledger transaction from Oracle Utilities Customer Cloud Service to Oracle E-Business Suite for General Ledger and Accounts Payable for journal creation.
It is an asynchronous flow that is triggered by a schedule. Oracle Utilities Customer Cloud Service creates a GL Extract file which is picked up by the integration process and uploaded to Oracle E-Business Suite. This is just a file pass through and no transformation will be done by the integration.
Make sure the GL related batch processes (GLASSIGN, GLS, C1-GLFCX) in Oracle Utilities Customer Cloud Service are run before this integration process is executed.
The following diagram shows a graphical representation of the General Ledger Extract integration process. 
Business Processing
This asynchronous integration process is deployed on Oracle Integration Cloud and does the following activities:
1. If the extract file is in Object Storage, it invokes the Object Storage - List Objects REST API to get the list of files to be processed. Only files that start with the string entered in property name gl.extract.filename.prefix in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup are returned. Most of the time, this will only be one file.
2. If there is no file to process, a notification email is sent and the processing stops. If there is only one file to process, the following steps are performed. Else, the steps for each file to be processed are repeated.
a. Invokes the Object Storage: Gets Object REST API to get the actual file to process.
b. The file is unzipped.
c. The whole file is read.
d. Use the EBS Adapter Open Interface with operation Journal Import to load and import the GL data into EBS GL interface table.
Note: Bell and email notifications are enabled for any case in the Oracle E-Business Suite Cloud Adapter. This means when the load and import process are done, bell and email notification are sent out as long as these notifications are setup in the Oracle E-Business Suite for General Ledger and Accounts Payable.
In case of error:
a. If specified in the response, while creating the journals all the successful journals are deleted from the GL interface table.
b. The error is collected.
c. A local file is created using the original file name and the prefix.fileerrored property in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. This file is created in the directory specified by the gl.os.fileerrored.directory using the FTP Adapter. The file contains the failed journals and will be attached to the notification error email.
d. In case of an HTTP error, the process stops and a notification email is sent.
e. After the file is processed by the integration, it invokes the Object Storage - Rename Object REST API to rename the file just processed in Object Storage by adding a prefix to the filename. This prefix is obtained from the prefixtag.fileuploaded property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. The file is moved to the directory defined in the gl.os.fileuploaded.directory property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup.
3. A completion email notification with details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag Property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive an email notification when errors are encountered.
4. An optional email notification with error details are sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive an email notification when errors are encountered.
Retry Option: Re-run from Oracle Integration Cloud. If there are any previous processing errors, edit the file to fix/remove the error file(s).
It is recommended to check the GL interface table for Oracle Utilities Customer Cloud Service records to avoid double journal processing.
Technical Details
The following table describes the integration processes and the respective Oracle Utilities Customer Cloud Service and Oracle E-Business Suite for General Ledger and Accounts Payable artifacts used in this integration process.
Artifacts | Value |
|---|---|
Integration Process Name | OU CCS EBSFIN OS GL Extract Upl |
Integration Package Name | outl.ba.ccs_ebsfin.1_23_3000 |
Object Storage REST APIs | Object Storage Service API Endpoint https://{OSLocation_host_name} To get the list of files: Method: GET URI: /n/{namespaceName}/b/{bucketName}/o Query Parameters: prefix To get the file: Method: GET URI: /n/{namespaceName}/b/{bucketName}/o /{objectName} To rename the file: Method: POST URI: /n/{namespaceName}/b/{bucketName}/ actions/renameObject |
EBS Adapter | Journal Import Action: Open Interface Operation: Journal Import |
General Ledger Extract Process FTP (Oracle Utilities Customer Cloud Service Initiated)
This integration process is used to transfer all approved General Ledger transactions from Oracle Utilities Customer Cloud Service to Oracle E-Business Suite for General Ledger and Accounts Payable for journal creation.
It is an asynchronous flow triggered by a schedule. Oracle Utilities Customer Cloud Service creates a GL Extract file which is picked up by the integration process and uploaded to Oracle E-Business Suite for General Ledger and Accounts Payable. It is just a file pass through and no transformation will be done by the integration.
Make sure the GL related batch processes (GLASSIGN, GLS, C1-GLFCX) in Oracle Utilities Customer Cloud Service are run before this integration process is executed.
The following diagram shows a graphical representation of the General Ledger Extract integration process. 
Business Processing
This asynchronous integration process is deployed on Oracle Integration Cloud and does the following activities:
1. If the extract file is in FTP, it invokes the FTP Adapter to get the list of files to be processed. Only files that start with the string entered in the gl.extract.filename.prefix property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup are returned. Most of the time, this will only be one file.
2. If there is no file to process, a notification email is sent and the processing stops. If there is only one file to process, the following steps are performed. Else, the steps for each file to be processed are repeated.
a. Invokes the FTP Adapter to download the file to stage directory. Stage action is used to get the actual file to process.
b. The file is unzipped.
c. The whole file is read.
d. Use the EBS Adapter Open Interface with operation Journal Import to load and import the GL data into EBS GL interface table.
In case of error:
a. If specified in the response while creating the journals all the successful journals are deleted from the GL interface table.
b. The error is collected.
c. A local file is created using the original file name and the prefix.fileerrored property in OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. This file is created in the directory specified by the gl.ftp.fileerrored.directory using the FTP adapter. The file contains the failed journals and will be attached to the notification error email.
d. In case of an HTTP error, the process stops and a notification email is sent.
e. After the file is processed by the integration, it invokes the FTP Adapter to rename the file adding a prefix to the filename. This prefix is obtained from the prefixtag.fileuploaded property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. The file is moved to the directory defined in the gl.ftp.fileuploaded.directory property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup using the FTP Adapter.
3. A completion email notification with details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive an email notification when errors are encountered.
4. An optional email notification with error details are sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to ‘true’ to receive an email notification when errors are encountered.
Retry Option: Re-run from Oracle Integration Cloud. If there are any previous processing errors, edit the file to fix/remove the error file(s).
It is recommended to check the GL interface table for Oracle Utilities Customer Cloud Service records to avoid double journal processing.
Technical Details
The following table describes the integration process and the respective Oracle Utilities Customer Cloud Service and Oracle E-Business Suite for General Ledger and Accounts Payable artifacts used in this integration process.
Artifacts | Value |
|---|---|
Integration Process Name | OU CCS EBSFIN FTP GL Extract Upl |
Integration Package Name | outl.ba.ccs_ebsfin.1_23_3000 |
Oracle E-Business Suite Cloud Adapter | Journal Import Action: Open Interface Operation: Journal Import |
Account Payable Request Extract Process OS (Oracle Utilities Customer Cloud Service Initiated)
This integration process is used to transfer payable refund payment request from Oracle Utilities Customer Cloud Service to Oracle E-Business Suite for General Ledger and Accounts Payable for one-time payment creation.
It is an asynchronous flow that is triggered by a schedule. Oracle Utilities Customer Cloud Service creates an AP Request Extract file which is picked up by the integration process and uploaded to Oracle E-Business Suite for General Ledger and Accounts Payable. This is just a file pass through and no transformation will be done by the integration.
Note: Make sure the C1-APFCX batch process in Oracle Utilities Customer Cloud Service have been run before this integration process is run.
The following diagram shows a graphical representation of the AP Request Extract integration process. 
Business Processing
This asynchronous integration process is deployed on Oracle Integration Cloud and does the following activities:
1. If the extract file is in Object Storage, it invokes the Object Storage - List Objects REST API to get the list of files to be processed. Only files that start with the string entered in the apreq.extract.filename.prefix property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup file are returned. Most of the time, this will only be one file.
2. If there is no file to process, a notification email is sent and the processing stops. If there is only one file to process, it performs the following steps. Else, the steps for each file to be processed are repeated.
a. Invokes the Object Storage: Gets Object REST API to get the actual file to process. In case of failure the processing stops, and a notification email is sent.
b. The file is unzipped.
c. The file is completely loaded.
d. The distinct customers (AP vendors) are stored in a list.
For each vendor, the following task are executed:
• Using the EBS Adapter to invoke a custom API, the vendor is either created (if it does not exist) along with the site or it is updated if it exists.
• In case of an error specified in the response while creating or updating the vendor/site, the error is collected and the next vendor is processed. If there is an HTTP error, the process stops, and a notification email is sent.
• If there is no error, then using the EBS Adapter, the invoice headers are created.
• In case of error:
a. If specified in the response while creating the journals, all successful journals are deleted using the EBS Adapter.
b. The error is collected.
c. A local file is created using the original file name and the prefix.fileerrored property in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. This file is created in the directory specified by the gl.ftp.fileerrored.directory using the FTP adapter. The file contains the failed journals and will be attached to the notification error email.
d. In case of an HTTP error, the process stops and a notification email is sent.
• If there is no error, then using the EBS Adapter, the invoice lines are created.
• In case of error:
a. If specified in the response while creating the journals, all successful journals are deleted using the EBS Adapter.
b. The error is collected.
c. A local file is created using the original file name and the prefix.fileerrored property in OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. The local file then is created in the directory specified by ap.os.fileerrored.directory using the Object Storage PutObject REST API . The file contains the failed invoice lines and will be attached to the notification error email.
d. In case of an HTTP error, the process stops and a notification email is sent.
e. After the file is successfully processed by the integration, it invokes the Object Storage RenameObject REST API to rename the file adding a prefix to the filename. This prefix is obtained from the prefixtag.fileuploaded property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. The file is moved to the directory defined in the ap.os.prefixtag.fileuploaded property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup.
3. A completion email notification with details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
4. An optional email notification with error details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
Retry Option: Re-run from Oracle Integration Cloud. If there are any previous processing errors, edit the file to fix/remove the error file(s).
It is recommended to check the invoice interface tables for Oracle Utilities Customer Cloud Service records to avoid errors when retrying.
Technical Details
The following table describes the integration process and the respective Oracle Utilities Customer Cloud Service and Oracle E-Business Suite for General Ledger and Accounts Payable artifacts used in this integration process.
Artifacts | Value |
|---|---|
Integration Process Name | Oracle Utilities CCS EBSFIN OS AP Req Extr Upl |
Integration Package Name | outl.ba.ccs_ebsfin.1_23_3000 |
Object Storage REST APIs | Object Storage Service API Endpoint https://{OSLocation_host_name} To get list of files: Method: GET URI: /n/{namespaceName}/b/{bucketName}/o Query Parameters: prefix To get file: Method: GET URI: /n/{namespaceName}/b/{bucketName}/o /{objectName} To rename file: Method: POST URI: /n/{namespaceName}/b/{bucketName}/ actions/renameObject |
Oracle E-Business Suite Cloud Adapter | Bulk Import Data Action: Import Bulk Data into Oracle Oracle E-Business Suite Cloud Operation: Import Payables Payment Requests |
Account Payable Request Extract Process FTP (Oracle Utilities Customer Cloud Service Initiated)
This integration process is used to transfer payable refund payment request from Oracle Utilities Customer Cloud Service to Oracle E-Business Suite for General Ledger and Accounts Payable for one-time payment creation.
It is an asynchronous flow that is triggered by a schedule. Oracle Utilities Customer Cloud Service creates an AP Request Extract file which is picked up by the integration process and uploaded to Oracle E-Business Suite for General Ledger and Accounts Payable. This is just a file pass through, and no transformation will be done by the integration.
Note: Make sure the C1-APFCX batch process in Oracle Customer Care and Billing have been run before this integration process is executed.
The following diagram shows a graphical representation of the AP Request Extract FTP integration process. 
Business Processing
This asynchronous integration process is deployed on Oracle Integration Cloud and does the following activities:
1. If the extract file is in FTP server, it invokes the FTP adapter to return the list of files to be processed. Only files that start with the string entered in the apreq.extract.filename.prefix property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup file are returned. Most of the time this will only be one file.
2. If there is no file to process, a notification email is sent and the processing stops. If there is only one file to process, it performs the following steps. Else, the steps for each file to be processed are repeated.
a. Invokes the FTP Adapter: Download Operation to get the actual file to process.
b. The file is unzipped.
c. The file is completely loaded.
d. The distinct customers (AP vendors) are stored in a list.
For each vendor, the following task are executed:
• Using the EBS Adapter to invoke a custom API, the vendor is either created (if it does not exist) along with the site or it is updated if it exists.
• In case of an error specified in the response while creating or updating the vendor/site, the error is collected and the next vendor is processed. If there is an HTTP error, the process stops, and a notification email is sent.
• If there is no error, then using the EBS Adapter, the invoice headers are created.
• In case of error:
a. If specified in the response while creating the journals, all successful journals are deleted using the ABS Adapter.
b. The error is collected.
c. A local file is created using the original file name and the prefix.fileerrored property in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. This file is created in the directory specified by the gl.ftp.fileerrored.directory using the FTP adapter. The file contains the failed journals and will be attached to the notification error email.
d. In case of an HTTP error, the process stops and a notification email is sent.
• If there is no error, then using the EBS Adapter, the invoice lines are created.
• In case of error:
a. If specified in the response while creating the journals, all successful journals are deleted using the EBS Adapter.
b. The error is collected.
c. A local file is created using the original file name and the prefix.fileerrored property in OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. The local file then is created in the directory specified by ap.os.fileerrored.directory using the Object Storage PutObject REST API . The file contains the failed invoice lines and will be attached to the notification error email.
d. In case of an HTTP error, the process stops and a notification email is sent.
e. After the file is successfully processed by the integration, it invokes the FTP Adapter to rename the file adding a prefix to the filename. This prefix is obtained from the prefixtag.fileuploaded property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup. The file is moved to the directory defined in the ap.ftp.prefixtag.fileuploaded property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup.
3. A completion email notification with details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. Property name email.flag in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
4. An optional email notification with error details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
Retry Option: Re-run from Oracle Integration Cloud. If there are any previous processing errors, edit the file to fix/remove the error file(s).
It is recommended to check the invoice interface tables for Oracle Utilities Customer Cloud Service records to avoid errors when retrying.
Technical Details
The following table describes the integration process and the respective Oracle Utilities Customer Cloud Service and Oracle E-Business Suite for General Ledger and Accounts Payable artifacts used in this integration process.
Artifacts | Value |
|---|---|
Integration Process Name | OU CCS EBSFIN FTP AP Req Extr Upl |
Integration Package Name | outl.ba.ccs_ebsfin.1_23_3000 |
EBS Adapter | Payables Import Action: Open Interface Operation: Payables Import |
Account Payable Data Payment Update Process (Oracle E-Business Suite for General Ledger and Accounts Payable Initiated)
This integration process is used to send AP refund request payment information from Oracle E-Business Suite for General Ledger and Accounts Payable to Oracle Utilities Customer Cloud Service.
The payment information for system-generated checks to customers is generated and processed in Oracle E-Business Suite for General Ledger and Accounts Payable and then sent to Oracle Utilities Customer Cloud Service. Only payment information that corresponds to the AP refund requests originally generated in Oracle Utilities Customer Cloud Service are sent back. The integration process updates the original AP Request in Oracle Utilities Customer Cloud Service with the details of the payment including the payment status, check number, and date.
The following diagram shows a graphical representation of the AP Data Payment Update integration process. 
Business Processing
This asynchronous integration process is deployed on Oracle Integration Cloud and performs the following activities:
1. The scheduled integration by default will query the invoices and payments for the previous day. The integration process will only accept payments and invoices with source equals to the one defined in the Oracle E-Business Suite for General Ledger and Accounts Payable common lookup type INT_CCS_EBS_MORG_SETUPS with code INT_INVOICE_SOURCE. This criteria is used to identify payments and invoices made to Oracle Utilities Customer Cloud Service specific payables.
Note: When sending the AP Request from Oracle Utilities Customer Cloud Service, the payment method of the Payables is translated in the integration layer using the OUTL-BRT-CCS_EBSFIN_Payment_Method lookup.
2. The payment information retrieved from Oracle E-Business Suite for General Ledger and Accounts Payable using the adapter to call the custom API returns all the Oracle Utilities Customer Cloud Service payment details needed.
3. Transform the Payment information payload from the Oracle E-Business Suite for General Ledger and Accounts Payable format to the Oracle Utilities Customer Cloud Service format.
4. Using the adapter, invoke the Oracle Utilities Customer Cloud Service REST API - AP Check Request to pass the payment information to Oracle Utilities Customer Cloud Service.
5. Error Handling for this process.
Any errors encountered are collected for later use in the error notification.
Retry Option: Re-run from Oracle Integration Cloud.
6. A completion email notification with details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
Technical Details
The following table describes the integration process and the respective Oracle Utilities Customer Cloud Service and Oracle E-Business Suite for General Ledger and Accounts Payable artifacts used in this integration process.
Artifacts | Value |
|---|---|
Integration Process Name | OU EBSFIN CCS AP Payment Info Update |
Integration Package Name | outl.ba.ccs_ebsfin.1_23_3000 |
CCS REST IWS | C1-APCheckRequest Allows an external system to update the check-related information on an existing A/P Check Request record after the check has been cut. If the A/P Check Request is being canceled, this service also cancels the related adjustment. Computed URL: https://{host}:{port}/{tenant}/{domain}/rest/apis/customer/financials/apCheckRequest Method: PUT URI: /{apRequestId} |
Oracle E-Business Suite Custom API | Get Payment/Invoice details getCCSPaymentDetails |
Account Payable Data Payment Void Process (Oracle E-Business Suite for General Ledger and Accounts Payable Initiated)
This integration process is used to update Oracle Utilities Customer Cloud Service AP refund request payment status to canceled status when a payment is voided in Oracle E-Business Suite for General Ledger and Accounts Payable.
Only voided payments and cancelled invoices with no payments that corresponds to the AP refund requests originally generated in Oracle Utilities Customer Cloud Service are sent back. The integration process updates the original AP Request in Oracle Utilities Customer Cloud Service with the canceled status.
The following diagram shows a graphical representation of the AP Data Payment Void integration process.
Business Processing
This asynchronous integration process is deployed on Oracle Integration Cloud and does the following activities:
1. The scheduled integration by default will query the cancelled invoices and payments voided for the previous day. The integration process will only accept payments and invoices with source equals to the one defined in the Oracle E-Business Suite for General Ledger and Accounts Payable common lookup type INT_CCS_EBS_MORG_SETUPS with code INT_INVOICE_SOURCE. This criteria is used to identify payments and invoices made to Oracle Utilities Customer Cloud Service specific payables.
2. The payment information retrieved from the Oracle E-Business Suite for General Ledger and Accounts Payable using the adapter to call the custom API returns all the Oracle Utilities Customer Cloud Service payment details needed.
3. Transform the payment information payload from the Oracle E-Business Suite for General Ledger and Accounts Payable format to the Oracle Utilities Customer Cloud Service format.
4. Using the adapter, invoke the adapter the Oracle Utilities Customer Cloud Service REST API - AP Check Request to pass the payment information to Oracle Utilities Customer Cloud Service.
5. Error Handling for this process.
Any errors encountered are collected for later use in the error notification.
Retry Option: Re-run from Oracle integration Cloud.
6. An optional email notification with error details are sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
7. A completion email notification with details is sent to the users configured in the OUTL-BRT-CCS_EBSFIN_Email_Id lookup. The email.flag property name in the OUTL-BRT-CCS_EBSFIN_ConfigProps lookup must be set to 'true' to receive email notification when errors are encountered.
Technical Details
The following table describes the integration process and the respective Oracle Utilities Customer Cloud Service and Oracle E-Business Suite for General Ledger and Accounts Payable artifacts used in this integration process.
Artifacts | Value |
|---|---|
Integration Process Name | OU EBSFIN CCS AP Payment Info Update |
Integration Package Name | outl.ba.ccs_ebsfin.1_23_3000 |
CCS REST IWS | C1-APCheckRequest Allows an external system to update the check-related information on an existing A/P Check Request record after the check has been cut. If the A/P Check Request is being canceled, this service also cancels the related adjustment. Computed URL: https://{host}:{port}/{tenant}/{domain}/rest/apis/customer/financials/apCheckRequest Method: PUT URI: /{apRequestId} |
Oracle E-Business Suite Custom API | Get Payment/Invoice details getCCSPaymentDetails |