Funds Disbursement Process Home Pages

Payment Process Overview

To present a simplified overview of the Oracle Payments payment process, the process begins when a source product, such as Oracle Payables, needs to pay documents payable, such as invoices. Oracle Payables groups the documents payable into a payment process request and submits it to Oracle Payments. Within Oracle Payments, the Build Payments program groups documents payable into groups known as payments, which represent individual checks or electronic deposits. The Create Payment Instructions program groups payments into payment instructions. Payment instructions are then printed or submitted electronically to payment systems or banks.

Managing the Payment Process

You can manage the payment process from the Oracle Payments Funds Disbursement Process Home Page or from the Payment Manager Dashboard in Oracle Payables. Your choice depends on:

Oracle Payments Funds Disbursement Process Home Page

The Funds Disbursement Process Home Page should be used when the deploying company uses a centralized payment processing system. Centralized payment processing is where one person or team is dedicated to payment processing, but not to Oracle Payables functions such as invoice selection and payment process request submission. It is that person's or team’s responsibility to ensure that the payments are paid. In this scenario, a user who is responsible for the payment process only, and not the Oracle Payables payment functions of entering invoices and submitting payment process requests, may decide to use the Funds Disbursement Process Home Page, but he has a choice.

If the deploying company sets up Oracle Payments so that the Create Payment Instructions program is run separately from the Build Payments program, then payments from different payment process requests are mixed together when creating payment instructions, and it is more difficult to follow the payment process from the perspective of the payment process requests. In this case, users are advised to use the Funds Disbursement Process Home Page.

Oracle Payables Payments Dashboard

The Oracle Payables Payments Dashboard should be used when the deploying company uses a decentralized payment processing system. Decentralized payment processing is where more than person or team performs multiple payment functions, such as selecting the invoices to be paid, making the payments, and remedying any problems that occur with the payment process. In this scenario, a user who is responsible for invoice selection and the submission of payment process requests, as well following the payment process, may decide to use the Oracle Payables Payments Dashboard.

Overview of the Funds Disbursement Process Home Pages

The Funds Disbursement Process Home page is the first page the Payment Administrator sees after logging in. This page and its subsidiary pages enable the Payment Administrator to monitor and manage the payment process described in the previous section.

The Funds Disbursement Process Home page is a read-only page that includes a Pending Actions region that displays the current status of payment process requests and payment instructions that are in-process. The Pending Actions region contains links to detailed views of these entities, as well as Take Action links to pages that enable the Payment Administrator to take the next step in the payment process. The Funds Disbursement Process Home page also contains links to other pages that are relevant to, but not necessarily part of, the payment process.

During the payment process, the Payment Administrator uses the Funds Disbursement Process Home page to:

Submitting and Monitoring Funds Disbursement Concurrent Requests

The Concurrent Requests subregion of the side navigation bar enables the Payment Administrator to quickly submit and monitor any concurrent requests. Like the links in the Shortcuts subregion, these links enables the Payment Administrator to specify applicable parameters, schedule the concurrent request, and then monitor the submission.

The table below describes the funds disbursement concurrent programs provided by Oracle Payments.

Funds Disbursement Concurrent Programs
Funds Disbursement Concurrent Programs Description
Create Electronic Payment Instructions Selects electronic payments and groups them into payment instructions.
Create Printed Payment Instructions Selects printed payments and groups them into payment instructions.
Create Regulatory Reporting of Payments Creates regulatory reports or central bank reports.
Format Payment Instructions Uses XML Publisher templates to format payment instructions into payment files.
Payment File Accompanying Letter Creates an accompanying letter for a payment instruction file.
Payment Instruction Register Creates a report, displaying the contents of a payment instruction.
Payment Process Request Status Report Displays the contents and status of a payment process request.
Positive Pay File Creates a positive pay file for each payment instruction the concurrent program is run against.

Note: If you run this program using the SRS functionality, the list of values for the Payment Process Profile field in the Schedule Request: Parameters page displays only payment process profiles that are limited to one or more internal bank accounts. Payment process profiles that can be used with all bank accounts do not appear in this list of values.
Reset Periodic Sequence Value Resets periodic sequences to a specified number or letter. Periodic sequences can be specified in the payment process profile setup entity.
Send Separate Remittance Advices Creates remittance advices that notify payees that payments have been made to them.

Actions the Payment Administrator Performs from the Funds Disbursement Process Home Page, Pending Actions Region

The table below describes actions the Payment Administrator can perform from the Funds Disbursement Process Home page, Pending Actions region. Note that the actions described in the table below do not always need to be invoked; only when necessary and/or required by Oracle Payments settings.

Actions the Payment Administrator Performs from the Funds Disbursement Process Home Page
Payment Process Type Status of Payment Process Type Clicking Take Action Icon Opens Action Payment Administrator Performs
Payment Process Request Information Required - Pending Action Complete Document Assignments page Enables the Payment Administrator to assign internal bank accounts and payment process profiles to documents payable. Only used if the source product administrator does not provide this information.
Payment Process Request Document Validation Errors - Pending Action Resolve Document Validation Errors page Enables the Payment Administrator to review and resolve document-level validation errors by dismissing individual documents payable from the payment process and/or by modifying Oracle Payments setup. Only used if Oracle Payments settings require document-level validation errors to be reviewed by a user.
Payment Process Request Payment Validation Errors - Pending Action Resolve Payment Validation Errors page Enables the Payment Administrator to review and resolve payment-level validation errors by dismissing individual payments or documents payable from the payment process and/or by modifying Oracle Payments setup. Only used if Oracle Payments settings require payment-level validation errors to be reviewed by a user.
Payment Process Request Pending Proposed Payments Review Review Proposed Payments page Enables the Payment Administrator to review and approve or remove proposed payments after the Build Payments program has created them and before the payments are grouped into payment instructions. Only used if Oracle Payment settings require the review of proposed payments.
Payment Instruction Failed Validation Errors - Pending Action Resolve Payment Instruction Validation Errors page Enables the Payment Administrator to review and resolve payment instruction-level validation errors by dismissing individual payments from the payment process, by modifying Oracle Payments setup, or by choosing to override certain errors. Always used for payment instruction-level validation errors.
Payment Instruction Formatted - Ready for Transmission Transmit Payment Instruction page Enables the Payment Administrator to initiate payment instruction transmission. Only used for those payment instructions that are not transmitted to the payment system automatically, based on Oracle Payments settings.
Payment Instruction Transmission Failed Resolve Payment Instruction Transmission Failure page Enables the Payment Administrator to respond to a transmission failure by retransmitting the file or by ignoring the failure by recording that the transmission was successful. Always used for failed payment instruction transmission.
Payment Instruction Formatted - Ready for Printing Print Payment Documents page Enables the Payment Administrator to initiate payment document printing within Oracle Payments. Only used for those payment instructions that are not submitted for printing automatically, based on Oracle Payments settings.
Payment Instruction Created - Ready for Printing Print Payment Documents page Enables the Payment Administrator to initiate payment document printing within Oracle Payments. Always used for payment instructions for which formatting and printing are deferred due to another payment instruction locking the payment document needed to print the payments.
Payment Instruction Created - Ready for Formatting Print Payment Documents page Enables the Payment Administrator to initiate payment document printing outside Oracle Payments, that is, initiate printing to file. Always used for payment instructions for which formatting and printing are deferred due to another payment instruction locking the payment document needed to print the payments.
Payment Instruction Submitted for Printing Payment Instruction page with a choice of navigating to the Record Print Status page or the Reprint Payment Documents page The Reprint Payment Documents page enables the Payment Administrator to reprint spoiled payment documents. Always available for payment instructions printed within Oracle Payments. The Record Print Status page enables the Payment Administrator to record the status of printed payment documents, including spoiled payment documents that should not be reprinted and skipped documents. This action also marks payments complete. Recording print status is a required action for printed payment instructions. This method of recording is always available for payment instructions printed within Oracle Payments.
Payment Instruction Formatted - Ready for Recording Record Print Status page Enables the Payment Administrator to record the status of printed payment documents. This action also marks payments complete. Recording print status is a required action for printed payment instructions. This method of recording is always available for payment instructions printed outside Oracle Payments, that is, printed to file.
Stop Payment Request Printed Resolve Stop Payment Request page Enables the Payment Administrator to confirm or release a stop. Always used for payments that have a previous stop request placed on them.

Note: The following sections describe actions that the Payment Administrator performs from the Funds Disbursement Process Home page. These actions are not presented in any particular order.

Completing Assignments

Source products are allowed to submit documents payable to Oracle Payments without assigning an internal bank account or a payment process profile to them. The Complete Assignments page and its subsidiary pages are used to assign required entities to documents payable, so that Oracle Payments has the necessary information to continue with the payment process. This page enables Payment Administrators to perform the first action that they can take during the payment process, which is to assign internal bank accounts and payment process profiles to documents payable. While providing this information, Payment Administrators can also change the assignments of documents that already have this information.

Important: Once internal bank account and/or payment process profile information has been supplied for all documents and the payment process restarted, no assignments can be changed.

Resolving Document Validation Errors

Once all documents payable have been assigned all required attributes, the Build Payments program validates them, based on applicable validations assigned in Oracle Payments setup. When submitting the payment process request, the source product specifies whether documents that fail this document validation are rejected or whether the Build Payments program simply stops the payment process for review by the Payment Administrator.

If review is required for failed documents, the Payment Administrator navigates to the Resolve Document Validation Errors page to review the validation errors, dismiss individual documents payable from the payment process, if necessary, and restart the Build Payments process when the errors have been resolved.

The Payment Administrator can also leave the Funds Disbursement Process pages altogether in order to change setup or third party payee data that may have caused the error, and then return to the Resolve Document Validation Errors page to restart the Build Payments process.

Resolving Payment Validation Errors

The Resolve Payment Validation Errors page enables the Payment Administrator to resolve validation errors at the payment level. This page displays the proposed payments and validation errors, as well as the documents payable that comprise each proposed payment.

Once payments have been built from documents payable, the Build Payments program validates them, based on applicable validations assigned in Oracle Payments setup. When submitting the payment process request, the source product specifies whether payments that fail this validation are rejected or whether the Build Payments program simply stops the payment process for review by the Payment Administrator.

If review is required for payments that fail validation, the Payment Administrator navigates to the Resolve Payment Validation Errors page to review the validation errors, remove documents payable or entire payments, if necessary, and restart the Build Payments process when the errors have been resolved. The Payment Administrator can also leave the Funds Disbursement Process pages altogether to change setup or third party payee data that may have caused the error, and then return to the Resolve Payment Validation Errors page to restart the Build Payments process.

Reviewing Proposed Payments

The Review Proposed Payments page enables the Payment Administrator to review and approve proposed payments after the Build Payments program has created them. This page displays all proposed payments after they have passed validation, as well as the documents that comprise each proposed payment.

When submitting the payment process request, the source product specifies whether the Build Payments process is stopped for payment review once the proposed payments are built. If review is required for proposed payments, the Payment Administrator navigates to the Review Proposed Payments page to review payments, remove payments or individual documents, if necessary, and then restarts the Build Payments process.

Resolving Payment Instruction Validation Errors

Once payment instructions have been built from payments, the Create Payment Instructions program validates them, based on applicable validations assigned in Oracle Payments setup. If a payment instruction fails validation, it is always stopped for review. The Resolve Payment Instruction Validation Errors page enables the Payment Administrator to review, resolve, or override validation errors found by the Create Payment Instructions program. This page displays the following:

The Payment Administrator can remove payments, if necessary, leave the Funds Disbursement Process pages altogether to change setup or third party payee data, or, in the case of some errors, override the validation errors. If the validation errors are overridden or resolved, the payment process proceeds to formatting and then printing or transmitting the payment instruction.

Note: At this action step, the Payment Administrator does not have the option of removing individual documents payable.

Payment Instruction Status of Created

If you notice that the Create Payment Instructions program has stopped, leaving a payment instruction with a status of Created, as seen in the Status column under the Pending Actions region of the Funds Disbursement Process Home page, or on the Payment Instruction Search page, you can move the Created status to a formatting phase by running the Format Payment Instruction program.

To run the Format Payment Instruction program, perform either of the following steps:

Note: The preceding actions are error-recovery procedures only. Normally, when a payment instruction successfully finishes validation, the Format Payment Instruction program is run automatically, moving the payment instruction beyond the Created status.

Transmitting Payment Instructions

Payment instructions that are electronic, as opposed to printed checks, must be transmitted to a payment system. This transmission occurs automatically or is deferred, based on Payments setup. If Oracle Payments is set up to defer payment instruction transmission, the Payment Administrator navigates to this page to manually initiate the transmission.

The Transmit Payment Instruction page enables the Payment Administrator to initiate payment instruction transmission for those payment instructions that are not transmitted to the payment system automatically. This page enables the Payment Administrator to review payment instruction and transmission details before transmitting the instruction.

Note: This action step is the Payment Administrator’s final opportunity to terminate a payment instruction.

Resolving Payment Instruction Transmission Failure

Occasionally, a transmission fails. The Resolve Payment Instruction Transmission Failure page enables the Payment Administrator to respond to a transmission failure by taking one of the following actions:

The Resolve Payment Instruction Transmission Failure page displays an overview of the payment instruction, along with transmission details.

Printing Payment Documents

Oracle Payments setup enables the Payment Administrator to choose whether payment instructions are printed immediately after a payment instruction is formatted. For those payment instructions that are not printed immediately, the Payment Administrator must manually submit them for printing.

Manual submission occurs in the Print Payment Documents page. This page enables the Payment Administrator to initiate payment document printing for those payment instructions that are submitted manually for printing, rather than automatically. The Print Payment Documents page enables the Administrator to review basic details of a payment document and to override the default printer before submitting the payment instruction for printing.

In the case where a payment instruction is not formatted and printed because another payment instruction has locked the payment document (see below), this page is used to initiate both formatting and printing. In the case where a payment instruction is supposed to be printed outside Oracle Payments, that is, printed to file, this page is used to initiate formatting.

The Print Payment Documents page prints both prenumbered and non-prenumbered payment documents. Behind the scenes, the print program invokes Oracle XML Publisher to print the payment instruction onto checks or into a payment file that is transmitted to a payment system for further processing and disbursement.

Note: This action step is the Payment Administrator’s final opportunity to terminate the payment instruction.

Locking and Numbering Payment Documents

This section discusses printing in general, not just printing that is manually initiated by the Payment Administrator.

Note: The term payment instruction refers to a collection of payments, as built by the Create Payment Instructions program. The term payment document can refer to the stock of paper that is used to print payments onto, such as check stock or a check book. Alternately, payment document can also refer to a physical payment, such as a printed check, which is printed onto a single piece of check stock.

Payment document printing can occur immediately after payment instruction creation or later at the Payment Administrator’s request. Both the Print Payment Documents page and the Create Payment Instructions Program use the Format Payment Instructions program to perform the necessary print tasks. This program initiates payment document printing by internally tracking the numbering of the payment documents and locking the payment documents. For each payment instruction, Oracle Payments performs the following steps:

  1. The system checks whether the required payment document is available for printing. If the payment document is unavailable, printing cannot continue:

    • If the Format Payment Instructions program was invoked by the Create Payment Instructions program, printing is deferred.

    • If the Format Payment Instructions program was invoked by the Print Payment Documents page, an error message indicates that the Payment Administrator cannot print the payment instruction until he completes recording the print status of the prior payment instruction.

    • In either case, the Payment Administrator must complete the previous payment instruction, that is, the one that is locking the payment document, by recording its print status. For information on recording the print status of the payment instruction, see Recording the Print Status of Prenumbered Payment Documents and Recording the Print Status of Non-Prenumbered Documents.

      If the payment document is available, Oracle Payments locks it for this payment instruction. If the Format Payment Instructions program is invoked by the Create Payment Instructions Program and the Create Payment Instructions Program created more than one payment instruction that requires the same payment document, then the payment instruction that was created first locks the payment document.

      Note: A payment document is unlocked if either of the following occurs:

      • payment instruction is terminated

      • payment instruction prints correctly and its status is recorded by the Payment Administrator on the Record Print Status page

  2. Oracle Payments internally tracks the numbering of all the payments contained in a payment instruction, including the setup and overflow documents.

    Setup documents are occasionally required by older printing systems. These prenumbered setup checks are discarded after the print run, but the system tracks their numbers.

    Overflow documents are checks that are voided due to a continuation of descriptive text on more than one check stub. This occurs when the number of lines of descriptive text printed per check stub exceeds the maximum allowed.

  3. The Format Payment Instructions program sends the payment instruction to Oracle XML Publisher for printing.

Reprinting Payment Documents

The Reprint Payment Documents page is optional. If a Payment Administrator finds no problems with the initial print run or does not need to reprint, he can navigate directly to the Record Print Status page. The Reprint Payment Documents page can be used if, after printing has been submitted, the Payment Administrator discovers printing problems and wishes to reprint particular payment documents or the complete payment instruction. This page enables the Payment Administrator to reprint individual payment documents, ranges of payment documents, or the complete payment instruction, and then submit those payment documents for printing.

Note: The Payment Administrator must visually inspect whether the checks printed. He can reprint the complete payment instruction only if the initial print run has not started.

The Reprint Payment Documents page enables the Payment Administrator to:

Note: The Reprint button is available only after Oracle Payments attempts to print a payment document. In the reprint scenario, the payment document is still locked from the initial printing attempt.

Warning: Do not reprint the complete payment instruction if the initial printing attempt resulted in one or more checks printing successfully. If you reprint the entire payment instruction after successfully printing one or more payment documents, the numbering on the prenumbered payment documents may be incorrect. If printing did commence, but you need to reprint every payment document in the payment instruction, choose to reprint a range of payment documents and enter the first and last documents in the payment instruction as the range.

Those payment documents that are selected for reprint are automatically marked as Spoiled. Because payment document numbers cannot be reused for prenumbered payment documents, reprinting on prenumbered payment documents requires the Payment Administrator to provide the first document number for the reprints. Oracle Payments can then correctly renumber the payments.

Recording the Print Status of Prenumbered Payment Documents

Since the actual printing occurs outside of Oracle Applications and has many potential failure points, Oracle Payments does not know the outcome of printing or reprinting payment documents. Consequently, the Payment Administrator needs to provide that information to Oracle Payments through the Record Print Status page. This page enables the Payment Administrator to:

By default, payment documents that have been marked spoiled during the reprinting process are displayed as Spoiled in the Record Print Status page, but all other payment documents are initially displayed as Printed. For those payment documents that actually are spoiled or skipped, the Payment Administrator must enter applicable documents in the Record Spoiled Payment Documents region or the Enter Skipped Payment Documents region of the Record Print Status page.

The Record Print Status page also enables the Payment Administrator to choose whether to submit the Positive Pay program immediately after he finishes recording the print status, if the applicable setup enables the choice. The program creates a positive pay file, formats it, and transmits it electronically to your bank. This prevents check fraud by informing the bank which payment documents are issued and for what amount.

Important: Do not commit all print statuses unless you are sure that all documents with the status of Printed were successfully printed. If you click the Apply button, the payments are marked as complete and the payment documents are recorded as Printed. If you complete this action and discover printing errors, you will need to void the payment and select the documents to be paid in a new payment process.

Recording the Print Status of Non-Prenumbered Documents

When a payment document is not prenumbered, no renumbering needs to be done when payment documents are skipped. This is because the skipped document is simply a blank piece of paper that can be used in a new print run.

Spoiled payment documents that have not been reprinted and that you wish to remove, rather than reprint, do need to be marked, so that Oracle Payments can consider those payments failed and notify source products appropriately.

As with prenumbering, the Record Print Status page displays the Printed status by default. Since reprinting non-prenumbered documents involves using the same document number, rather than renumbering, all payment documents are shown with the status of Printed when the Payment Administrator first enters the Record Print Status page.

Marking payment documents as Spoiled in the Record Spoiled Payment Documents Region, and later committing them through the Review Record Print Status page, results in the removal of the associated payments from the payment instruction and informs the relevant source products that the documents payable have not been paid.

Marking Payments Complete

Oracle Payments must notify source products when payments are complete, so that the source products can perform any necessary actions, such as accounting. Printed payments are considered complete when the payment documents are recorded as Printed. For electronic payments, however, determining the point at which a payment is considered complete is more complex and depends on the first party payer’s business practices, as well as on what notification (acknowledgement and clearing) the payer’s payment system supports. An electronic payment can be considered complete any time after formatting.

In general, electronic payments in a payment instruction are automatically marked complete at some point chosen during the setup of payment process profiles. However, Oracle Payments also enables Payment Administrators to manually mark payments complete, before they are marked automatically. For information on setting up completion behavior, see Setting Up Payment Process Profiles., Oracle Payments Implementation Guide.

To mark payments complete manually, the Payment Administrator navigates to the Mark Payments Complete page from the Funds Disbursement Process Home page by first selecting the Electronic Payment Instructions Not Marked Complete View under the Payment Processes region, clicking the Go button, and then clicking the Mark Payments Complete icon for an electronic payment instruction with a status of Formatted, Formatted - Ready for Transmission, Transmitted, or Transmission Failed. This view only shows payment instructions whose payment process profiles have the Allow Manual Setting of Payment Completion check box selected.

Once the payments in a payment instruction have been marked complete by clicking the Apply button in the Mark Payments Complete page, the source product is notified that the payments are complete. Simultaneously, the payment instruction can no longer be terminated. Instead, if there are any problems with the payments, they must be voided. The Terminate Payment Process action, therefore, does not appear on any page that displays in the context of a payment instruction whose payments have been marked complete.

Note: The Payment Administrator must mark all the payments in a payment instruction as complete. Oracle Payments does not support partial marking of payments as complete in a payment instruction.

Norwegian Extensions Migration to Oracle Financials

This topic provides overview of Norwegian Extensions migration to Oracle Financials.

NOEX stands for Norwegian Extensions migration to Oracle Financials. A Payment Acknowledgement for funds disbursement transactions (supplier payments) in Oracle Payments and Payables is a file that confirms the payer that their electronic payment (sent to a payee's bank) was successfully transmitted and received (acknowledged) by the bank.

Therefore, this type of Payment Acknowledgement processing starts after successful transmission of the payment file to the supplier's bank. Once the bank receives the payment file, the process generates the acknowledgement file. The acknowledgement file typically contains the status of each of the payments in the batch, and for the batch itself. These statuses indicate the progress of the payments in the clearing flow. The deploying organization (the payer) can use the data in the acknowledgment file to update the statuses of payments in Oracle and remain in-sync with their bank. Payment acknowledgement processing is widely used in various countries included in the EMEA region, especially by Norway and Denmark.

SEPA regulations also confirm the need for an acknowledgement-processing feature in order to support status report processing for SEPA credit transfer transactions.

To support acknowledgement processing, Oracle Payments provides a new public API to import the acknowledgement data in the system. It also provides an interface display the acknowledgment details and status, if there are any variance of payee bank account and payment amount.

Public API to Import Payment Acknowledgement Data

Acknowledgement file received from the bank is directly uploaded to the system in the set of acknowledgement tables by using a public API. Payment acknowledgement file can be directly retrieved from the bank’s server or bank may send the acknowledgement file. In either case, the deploying organization can decide the method to upload the acknowledgement file into system.

Oracle Payments provides a new public API using which the deploying companies can import the acknowledgement data into the system. To store the acknowledgement data in the system, Oracle Payments provides two new tables; one stores the payment acknowledgment details and the other bank reported errors.

Supporting Multiple Acknowledgement Files for a Payment

Banks send acknowledgement file only once in the life cycle of a Payment while some banks send multiple acknowledgement files. The followings are the reasons when a bank may send the acknowledgement file:

Payments supports multiple acknowledgements per payment. Payments administrator imports multiple acknowledgement files for the same payment. Payments data model lets you store multiple acknowledgement data linked to one payment.

Setting Up Bank Acknowledgement Codes

Bank provides acknowledgement code corresponding to each payment reported in the acknowledgement file. The bank reported acknowledgement codes represents the status of a payment in the clearing process. Different payments in an acknowledgement file can have different acknowledgement codes depending on their actual status in the bank’s process of clearing. As per ISO standards, statuses represented by acknowledgement status are as follows:

Different banks may have different coding schema for reporting acknowledgement codes. It is very difficult to find the exact status of a payment just by looking at bank-reported acknowledgement code. Therefore, Oracle Payments has provided a facility to set up bank acknowledgement codes and map them to ISO statuses so that users can easily understand the acknowledgement status of a payment.

The following are the setup steps to configure bank acknowledgement codes:

  1. Navigate to the Create Bank Acknowledgment window.

  2. Enter the status code and description (as per the bank’s format specification) in the corresponding fields.

  3. Map the bank’s acknowledgement status with the corresponding acknowledgement status established by the ISO standards.

  4. Save the setup.

The mapping of bank acknowledgment codes with ISO statuses is required to implement the acknowledgement processing solution. When importing acknowledgement records, Oracle Payments checks whether mapping of the bank acknowledgement codes with ISO statuses is available.

If the mapping is available, Oracle Payments updates the acknowledgement status of each payment with the corresponding ISO status. If the mapping is not available, then Oracle Payments does not import those acknowledgement records. Therefore, it is important for the deploying organization (the payer) to define the mapping of bank acknowledgement codes to ISO statuses in Oracle Payments before starting the acknowledgement process.

Acknowledgement Information in Payments

Payments window in Funds Disbursement Process Manager is enhanced to show payment acknowledgement and bank reported error information. In case of multiple acknowledgements for a payment, all acknowledgement records are displayed.

View Payment Acknowledgement Information

The Payment Details page has been enhanced to show payment acknowledgement and bank reported error information. A new region, Acknowledgement Information, is added that displays acknowledgement information. In case of multiple acknowledgements for a payment, the Payment Details page displays all acknowledgement records.

  1. Navigate to Payment Details.

  2. Click the Amount field to navigate to the Payment Details page for this payment:

In addition to the acknowledgement information, this region displays a variance indicator, Yes or No, for the payee bank account and payment amount. It is based on comparing the acknowledgement data with your actual payment record. It also displays calculated payment amount and calculated bank charge amount if the payee bank currency is different from the payment currency. The amount is calculated taking the exchange rate provided by the bank.

Followings are important business rules for this new region:

Payment Acknowledgement and Payment Acknowledgement Error Tables

Two new tables are added to store acknowledgement information and error information provided by bank at payment level. Successfully imported records are stored in these tables.

Payment Acknowledgement Table

A new table, IBY_ACK_PMT_ALL, is added that stores acknowledgement information at payment level.

A new table, IBY_ACK_PMT_ERRORS_INTERFACE, is added that stores acknowledgement errors information at the payment level. Once the matching is run, successful records are moved to IBY_ACK_PMT_ERROS table.

Changes to Payables Windows

To show acknowledgement status of a payment in Payables windows, Payment Workbench and Payment Overview, following changes are made:

Following change are made to Tools menu of Payment workbench to launch the acknowledgement details for a payment:

Changes to Payment Overview

The Payment Overview window provides high-level payment information and is used to review the status of the payment. This window displays the new field, Acknowledged Status. Valid values are Yes and No.

Recording Stop Payments Requests

When the Payment Administrator determines that a payment needs to be stopped, he contacts the payer bank and requests a stop payment.

Note: Payments does not support communication with payment systems regarding stop payments.

The Payment Administrator then records the stop payment request in the Record Stop Payment Request page. To navigate to the Record Stop Payment Request page, he uses one of the following:

If the Payment Administrator navigates to the Record Stop Payment Request page from the Funds Disbursement Process Home page, he enters a paper document number in the Paper Document Number field or a payment reference number in the Payment Reference field for the payment for which he wishes to record a stop payment request and then presses the Tab key on the keyboard. Information populates the Payee, Payment Date, and Amount fields. He then enters a stop request date, reason, and reference.

To navigate to the Record Stop Payment Request page from the Payments Search page, the Payment Administrator performs a simple search. When the results display, he clicks the Stop Actions icon for the applicable payee, and information displays in the payee, payment date, and amount fields. He then enters a stop request date, reason, and reference. The reference is provided by the bank.

Resolving Stop Payments Requests

After a stop payment request has been made, the bank checks that the payment has not already been made and then confirms or denies the stop payment request. The Payment Administrator then uses the Resolve Stop Payment Request page to enter the confirmation or release of the stop payment request. This includes recording the confirmation or release date, reason, and reference. The reference is provided by the bank.

Confirming a stop payment request causes Oracle Payments to automatically perform one of the following steps:

Releasing a stop payment request causes Oracle Payments to record the release, but no other change occurs. The system continues to treat the payment normally.

The Payment Administrator navigates to the Resolve Stop Payment Request page by using the Payments Search page to search for a payment with a stop request placed on it and then clicks the Stop Actions icon. Alternatively, he can click the Views button in the Payments Simple Search page, select the Resolve Stop Payment Requests View, and click the Stop Actions icon for the applicable payee.

Voiding Payments

Voiding a payment by specifying a void date and reason causes both Oracle Payments and the payment’s source product to reverse the payment.

To void a payment, the Payment Administrator navigates to the Void Payment page in one of the following two ways:

Note: A check should only be voided if it is in your physical possession or has been successfully stopped by your bank. A Payment Administrator cannot void a payment that has an unconfirmed stop payment request placed on it.

Source products may restrict whether and when a payment can be voided. Consequently, when the Payment Administrator attempts to void a payment on the Void Payment page, Oracle Payments contacts the source product to check whether the payment can be voided. If the payment cannot be voided, the system displays an error message. When the Payment Administrator uses the Payment Search page, Oracle Payments automatically checks whether the payments in the results region can be voided and displays the Void icon only for those payments that can be voided.

Voids are allowed on payments that have been transmitted to the payment instruction. However, if the payment system has already made the payment, this can cause a discrepancy between Oracle Payments and the real world. It is therefore best to check whether your payment system has actually made a transmitted payment before attempting to void it.

Voiding all Payments

Once the payments in a payment instruction are marked complete, a Payment Administrator cannot terminate the payment instruction. The only way to recover from an error or problem with the payment instruction, as a whole, is to void all the payments in the instruction. Because voiding all payments in a payment instruction is indicative of a serious payment-related problem, this action is intended only as an extreme error recovery procedure and should be invoked only when absolutely necessary. In addition, this page is disabled by default and can only be enabled through function security. Oracle Payments enables the Payment Administrator to void each payment individually, if necessary

Voiding payments causes both Oracle Payments and the payment’s source product to reverse those payments. Source products may restrict whether and when payments can be voided. Therefore, when the Payment Administrator attempts to void all payments, Oracle Payments checks whether each payment can be voided. If all payments cannot be voided, Oracle Payments displays an error message.

To void all payments in a payment instruction, the Payment Administrator must use the Payment Instructions Search page to navigate to the Void All Payments page. From the Payment Instructions Search page, the Payment Administrator searches on one or more variables, views the results, and then clicks the Void All Payments icon for the applicable payment instruction. In the Void All Payments page, the Payment Administrator enters a void date and reason that is applied to all payments in the payment instruction.

Supporting SEPA Credit Transfer

The European Payments Council (EPC) is the governing and coordination body of the European banking industry in relation to payments. It was established in the year 2002 and its purpose is to support and promote the creation of the Single European Payments Area (SEPA). The SEPA initiative involves creation of a zone for European countries (in 2008 the SEPA zone includes 31 countries) in which all payments in Euro are considered domestic even payment crossing borders. SEPA aims at improving the efficiency of cross border payments by developing common standards, procedures, and infrastructure to improve the economics of scale. The introduction of SEPA increases the intensity of competition amongst banks and corporations for customers across borders within Europe. SEPA provides cheaper, efficient, and faster payments within the SEPA zone to consumers, merchants, corporates and public administrations (Customers).

SEPA introduces a new Pan-European payment scheme for payments, both credit transfers and direct debits. The SEPA implementation guidelines for credit transfers are based on the adoption of the ISO20022 (a UNIFI standard). The implementation guidelines issued by the governing body, the European Payments Council, prescribe specific ISO20022 messages to be used to initiate SEPA payments.

SEPA implementation is important for the following reasons:

A SEPA Credit Transfer (SCT) is a payment instrument for the execution of credit transfers in Euro between Customers located in the SEPA zone. The SEPA Credit Transfer is executed on behalf of an Originator. The payment is transferred from the Originator’s Bank account to the Beneficiary’s bank account.

The following parties are involved in the process:

the picture is described in the document text

Credit Transfer Initiation Messaging

The SEPA credit transfer initiation messaging includes the various components associated with the payment process. In this process, functional mapping of the attributes in Oracle Application to the SCT messaging elements in accordance to the SEPA implementation guidelines is provided. The SEPA messaging format is XML. The concept of Grouping modes and Batch Booking for SEPA payment formatting is introduced. The grouping modes describe the way in which the payments are grouped in the file, which is sent to the bank. Batch booking defines how the entry appears in the bank statement. If enabled, the Bank sends a single line for all the transactions under one group.

To support SEPA implementation, Oracle Payments include the following components:

Seeding XML Template and Mapping the Attributes for SEPA Messaging

Oracle Payment now includes an XML template for specifying the SEPA payment format. All the attributes of Oracle Payments disbursement are mapped to the messaging elements as per SEPA format.

This template is seeded and is used for creating the SEPA payment file.

Payment Process Profiles

The Payment Process Profiles for the SEPA Credit Transfer Initiation are seeded in Oracle Payments. The payment instruction grouping depends on the grouping mode selected in the Payment Process Profile.

Payment Process Profiles are seeded representing the grouping mode Mixed.

Capturing Batch Booking flag and Grouping mode in the Payment Process Profile Setup

Grouping and Batch Booking are supported as per the ISO20022 guidelines. The Payment Process Profile includes the Grouping Mode and Batch Booking indicators.

Only ‘Mixed’ grouping mode is supported.

The Payment Instruction grouping parameters for Grouped is:

In the Payment Process Profiles window these fields are displayed as checked. You can change the default selection.

A checkbox, Batch booking, is added in the Payment Process Profile setup window. It is unchecked by default. It indicates whether the bank should book transactions individually or per payment group. When payments are batch booked, they will generate a single bank statement line entry per group. This is optional.

The company can have agreements with the bank to batch book certain transactions (usually ACH transactions) of similar characteristics. This is done outside the system.

The batch booking checkbox is added to the Create Payment Process Profile window.

Payment Method

For SEPA transactions the payment method must be Electronic.

Message Structure

The SCT message structure consists of the following blocks:

Group Header

This is the first block in the SCT message. The Group Header consists of the following elements: SCT Message Identification, CreationDateTime, BatchBooking, NumberOfTransactions, Grouping, Initiating Party etc.

Payment Information Block

This block consists of a set of parameters, which apply to the debit side of the payment transaction. These include information like: Payment Information Identification, Payment Method, Payment Type Information, Requested Execution Date, Debtor, Debtor Account, Debtor Agent, Bank Charges Bearer etc.

Credit Transfer Transaction Information Block

This block consists of a set of elements providing information specific to the individual payments included in the SCT message. This consists of the following elements: Payment Identification, Amount, Instructed Amount, Creditor Agent, Creditor Agent Account, Creditor, Creditor Account, Payment Purpose and Remittance Information etc.

Validation Sets for Checking the IBAN, BIC, Bank Charge Bearer and Legal entity Address

For a payment to be sent to a bank in SEPA format there are some basic conditions and validations that must be met. The validation architecture in Oracle Payments is used to ensure a payment included in the SEPA format satisfies the conditions. This in turn ensures Straight Through Processing (STP).

The following conditions must be met:

These details are validated at the format level and at invoice validation levels. In this component the validations at format level are explained. The validations at invoice validation are discussed in a separate section. You have to setup the invoice related validations.

When bank charge bearer setting is changed in the site level, the invoices that were created before the bearer is changed still continue to hold the old value. This change reflects only for the newly created invoices for this site and supplier.

Handling of International Bank Account Number

This feature explains how IBAN (International Bank Account Number) is handled in Oracle Payments.

SEPA (Single European Payment Area) requires IBAN (International Bank Account Number) for payer and payee bank accounts in the payment message. For countries using SEPA, IBAN is mandatory and is the driving factor for bank transactions. Whereas the regular Basic Bank Account Number (BBAN) is optional and is used as a secondary attribute. This requires all the products in the E-Business Suite application using first or third party bank account attribute on transaction creation or search windows to support IBAN in the place of BBAN.

This topic explains changes made to Payments and Payables for handling IBAN for external bank accounts.

In Payments and Payables, bank account with IBAN is supported. Oracle Payment and Payables use following approaches:

The bank account creation is based on the transaction attribute. In such cases, IBAN is included as a separate attribute. IBAN as a separate attribute is used in products integrating with Payments. For example, in Order Management, order creation window captures bank account attributes that are used for creating new bank account before order is confirmed and transaction extension is created within Payments. In such cases, Order Management provides IBAN as a separate attribute on the order creation window. In these cases, bank account number (BBAN) is a required filed only in these scenarios:

Similarly, you can create bank account through APIs instead of user interface as part of transaction processing. For example, AR automatic lock box processing. In such cases, Payments API derives BBAN from IBAN, which is captured at source and custom hook is implemented.

For the funds capture flow where the transaction extension is created by the upstream products at the time of transaction creation, there will not be any impact on the existing process due to creation of bank account via IBAN.

Changes to Search Supplier Bank Account Assignments Window

The Search Supplier Bank Account Assignments window features a bi-directional search. If you search on a supplier name, the results display all the bank account assigned to that supplier. Conversely, if you search on a bank account, the results display all the suppliers sharing that bank account.

This window lets you search based on IBAN or any other by any other option. Following changes are made to Payment and Payables windows:

Supporting SEPA Credit Transfer Enhancement

SEPA Credit Transfer feature introduced in Release 12 is based on SEPA Rule Book and SEPA implementation guidelines V2.3.The European Payments Council (EPC) recently published the new guidelines version V3.3 of these documents. There are changes prescribed in the usage rules of various message elements. The existing messaging structure must incorporate these changes to ensure that the message sent to banks is in accordance with the prescribed format.

This topic describes the changes to the existing solution to comply with the latest SEPA guidelines including the mapping changes of various messaging elements of SEPA core payments.

Mapping the Attributes for SEPA Messaging

All the attributes of Payments disbursement are mapped to the messaging elements as per SEPA format. The existing functionality provides the mapping of the SEPA core elements. However, there are changes in the usage rules of various messaging elements in the latest SEPA guidelines and the mapping for those messaging elements are provided.

In the latest version of SEPA guidelines, the mapping for the following new elements is supported:

The mapping for the following elements is changed in accordance with the change in usage rules described in SEPA implementation guidelines V3.3:

The mapping of these elements is supported as part of SEPA core payments. The mapping remains unchanged for the remaining elements.

The SEPA guidelines are revised to support only ‘Mixed’ grouping mode for SEPA payment format. The grouping mode list of values now include only ‘Mixed’ or ‘None’ values. The seeded Payment Process Profiles (PPPs) values of Single and Grouped grouping are removed.

Supporting Credit Transfer Format for Non-EURO Payments

This document provides overview of Credit Transfer Format for non-Euro Payments. The International Organization for Standardization (ISO) develops standards to ensure desirable characteristics of products and services such as quality, environmental friendliness, safety, reliability, efficiency and interchangeability, at an economical cost.

ISO provides standard in the payment area that covers customer to bank Credit Transfers, interbank settlements, payment acknowledgements, and exceptions. The ISO 20022 standard also called as UNIFI provides the financial industry with a common platform for the development of messages in a standardized XML syntax, using:

The objective is to enable communication inter-operability between financial institutions, their market infrastructures and their end-user communities.

SEPA Credit Transfer feature is one such ISO Credit Transfers. The SEPA Credit Transfer feature supports the credit transfer transactions originate and settle within European Union member nations. This feature covers transactions in euro currency and contains specific validations prescribed under SEPA guidelines.

The Common Global Implementation (CGI) is a forum for financial institutions to progress on various corporate-to-bank implementation topics on the use of ISO 20022 messages and to other related activities, in the payments domain. The CGI guide is intended specifically for global, multi-country, multi-bank and multi-instrument implementations that the participating banks can commonly accept as one of their implementations. The CGI focuses on the general message structure and then successful creation of individual transactions that can be executed by the participating banks.

It should be noted that the CGI message implementation template provides the opportunity to establish a generic harmonized multi-banking ISO 20022 XML message. However, this may not be the only implementation that banks support. Some banks offer value added solutions that are over and above the core CGI message implementation template.

New Lookup for Service Level and Seeding Values for Delivery Channel and Payment Reason

Code Name Description
BKTR Book Transaction Payment through internet book transfer.
NUGP Non-urgent Priority Payment Payment must be run as a non-urgent transaction with priority settlement.
NURG Non-urgent Payment Payment must be executed as a non-urgent transaction, which is typically identified as an ACH or the value transaction.
PRPT EBA Priority Service Transaction must be processed according to the EBA Priority Service.
SDVA Same Day Value Payment must be run with the same day value to the creditor.
SEPA Single Euro Payment Value Payment must be run following the Single Euro Payment Area scheme.
URGP Urgent Payment Payment must be run as an urgent transaction cleared through a real-time gross settlement system, which is typically identified as a wire or high value transaction.
URNS Urgent Payment Payment must be run as an urgent transaction cleared through a real-time gross settlement system, which is typically identified as a wire or high value transaction.

Changes to Supplier Payment Details

Following changes are made to the Supplier Payment Details region:

Changes to Payment Process Profile

Following fields and business rules are added for Service Level and Delivery Channel on Payment Process Profile Overrides region on the Create Payment Process Profile window.

The Payment Overrides for Service Level and Delivery Channel are added on Payment Process Profile. The override values defined in the Payment Process Profile take precedence over the value entered on the supplier setup. The Override values are taken into consideration for logical grouping instead of values entered at the supplier setup.

In the Create Payment Process Profile window, the Grouping Mode drop down list has been modified to include the ISO grouping option.

For the migrated Payment Process Profile values, the value Mixed is treated as Yes and blank is treated as No.

In the Payment Creation tab of Update Payment Process Profile window, following changes are added:

A field, Invoice Legal Entity, is added in the document grouping attributes. If this value is checked, then documents are grouped based on Invoice Legal Entity.

Note: For Payment Process Profiles being migrated, leave the field unchecked.

Seeding the XML Publisher Format Templates and Mapping the Attributes for ISO Credit Transfers

Credit Transfer initiation message format is based on ISO20022 framework. Before sending a message, ensure that the message is in the correct format. The XML Publisher Format Templates used for the ISO Credit Transfer Initiation are seeded. This lets you reuse the templates for creating your own formats.

Two new Credit Transfer Initiation Templates, ISOCGI Credit Transfer Initiation Template- Structured and ISOCGI Credit Transfer Initiation Template – Unstructured, are seeded.

Pre-defined Validations Attached to ISO 20022 CGI Credit Transfer Payment Format

Validation Set Name: ISO Grouping Attributes

Code: ISO_ Grouping_Attributes

If the Local instrument and Service Level values are not specified at both Payee and PPP levels, then an error displays.

Validation Point: Payment Formatting

Validation set is applicable to the following payment formats:

Validation Set Name: ISO Initiating Party

Code: ISO_Initiating_Party

It verifies that Initiating Party Identifier and the Party Name are present. If they are not specified, then an error displays.

Validation Point: Settlement Batch Validation set is applicable to the following payment format

Validation Set Name: ISO Debtor Agent and Creditor Agent

Code: ISO_Debtor_And_Creditor_Agent

The program verifies that both Payee bank branch BIC or Payee bank branch number are not Null. If the value is not specified, then an error displays. Also verifies that the Payee bank branch country is not Null.

Validation Point: Payment

Validation set applicable to the following payment formats:

Support Processing of Payment Status Report

A Payment Acknowledgement for funds disbursement transactions (supplier payments) in Oracle Payments or Payables is a file that confirms to the payer that their electronic payment (sent to a payee's bank) has been successfully transmitted and received ("acknowledged") by the bank. Therefore, this type of Payment Acknowledgement processing starts after successful transmission of the payment file to the supplier's bank. Once the bank receives the payment file, the process generates the acknowledgement file. Funds Disbursements acknowledgement processing is already handled in Oracle Payments. This acknowledgement processing solution is used to process the Payment Status Report.

Oracle Payments has provided a new public API (what is the name of this API) that can be used to import the acknowledgement data in to EBS. To store the acknowledgement data in the EBS data model, Oracle Payments has introduced two new tables (IBY_ACK_PMT_ALL and IBY_ACK_PMT_ERRORS).

The Payment Details window displays payment acknowledgement and bank reported error information. A new region, Acknowledgement Information, is added that displays acknowledgement information. In case of multiple acknowledgements for a payment, the Payment Details displays all acknowledgement records.

You can view the Acknowledged Status on the following windows:

Predefined Validations attached to SEPA Credit Transfer Payment Format

SEPA credit transfer initiation message initiates credit transfers.

The messages sent to bank must satisfy all the validations. The validation architecture in the Oracle Payments ensures that a payment included in the SEPA format satisfies the conditions. This ensures Straight Through processing (STP) and make sure that the file has no errors when being processed with bank. For SEPA payment format validations are added the check that the required information of various messaging elements is provided. Validation sets are provided to optimize the Straight Through Processing (STP).

New validations sets are introduced to validate the initiating party name and identification of initiating party, debtor and ultimate debtor.

New Attributes in Logical Grouping of Payments

The payment information block in the SEPA message structure contains the attributes of logical grouping. The SEPA payments are grouped using the following attributes of the payment information block:

With the changes in the usage rules, new elements, Instruction Priority and Category Purpose, are supported in the payment information block. These elements are included as attributes for logical grouping of payments. The invoice legal entity is added in the payment extract.

The logical grouping is already done for SEPA payment format. For CGI implementation, the following new attributes added in the logical grouping:

Impact on Existing Users