|Oracle Payments User's Guide|
Part Number E13415-04
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.
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:
how your company's payment process is set up
your needs for managing payments
how you set up payment instruction creation in Oracle Payments
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.
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.
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:
monitor items that require user action in the Pending Actions region
research completed payment process requests, payments, and payment instructions
mark electronic payment instructions complete
submit and monitor concurrent processes
record and resolve stop payments
view graphs of processing statistics
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||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.|
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.
|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.
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.
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.
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.
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.
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:
an overview of the payment instruction
payments in the payment instruction
documents payable within each payment
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.
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:
Click the Take Action icon corresponding to the applicable stopped payment instruction. This takes you to a warning page, allowing you to proceed with the program or cancel. If you proceed, the Format Payment Instruction program runs automatically.
Navigate to the Schedule Request Submission train. Enter the program (Format Payment Instruction) that you want to run and the reference of the payment instruction on which you want it to run.
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.
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.
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:
retransmitting the instruction file
ignoring the transmission failure by updating the status of the payment instruction to Transmitted after the bank confirms successful transmission
The Resolve Payment Instruction Transmission Failure page displays an overview of the payment instruction, along with transmission details.
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.
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:
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
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.
The Format Payment Instructions program sends the payment instruction to Oracle XML Publisher for printing.
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:
select payment documents to reprint
provide information on beginning the reprint, which includes overriding the default printer
review the payment document selection to be reprinted
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.
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:
Update the print statuses by marking payment documents Printed, Spoiled, or Skipped. The Payment Administrator can only mark prenumbered payment documents Skipped.
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.
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.
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.
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:
the Record Stop Payment Request link in the Payment Actions region of the Funds Disbursement Process Home page
the Payments Search page
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.
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:
Void the payment if the payment has already been marked complete.
Remove the payment from its payment instruction if it has not already been marked complete.
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 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:
Click the Void Payment link in the Payment Actions region of the Funds Disbursement Process Home page
Search for a payment on the Payments Search page and click the Void icon for the applicable payment. The Void icon is only available for payments that have been marked complete and that do not have stop requests placed on them.
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.
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.
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:
It removes disparities between national and cross border payments in Euro within SEPA payment zone by eliminating border effects. It ensues it is as easy and secure to make a cross border SEPA payment as making a payment within the national environment.
The cost for cross border Euro payment should as inexpensively as the cost for domestic payments.
The SEPA scheme ensures a maximum execution of 3 banking days from the date of acceptance. It is expected that the banks and communities of banks perform competitively to commercial customer needs by offering shorter execution time within the scope of the rules.
SEPA implementation leads to development of global remittance standards that support reconciliation and related procedures in the SEPA community. Automated reconciliation of invoices become much simpler as banks commit themselves to use the SEPA scheme to pass remittance reference information unchanged throughout the complete banking system on behalf of the originating Customer to the intended payment Beneficiary.
The SEPA implementation moves the banks and their Customers towards open standards that improve financial integration and act as a catalyst for additional products and services.
The SEPA scheme provides Customer benefits in terms of functionality, cost efficiency, ease of use and Straight Through Processing (STP). It also allows the Financials Institutions to meet their own mutually beneficial needs in terms of service and innovation for Customers.
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 Originator: is the Customer who initiates the credit transfer with the Originator Bank with an instruction. The funds for such a credit transfer is made available by means of a debit from a specified payment account of which the Originator is the account holder. .
The Originator Bank: is the Financial Institution that receives the Credit Transfer Instruction from the Originator and acts on the payment instruction by making the payment to the Beneficiary Bank in favor of the Beneficiary’s account according to the information provided in the instruction and in accordance with the provisions of the SEPA scheme.
The Beneficiary Bank: is the Financial Institution that receives the Credit Transfer Instruction from the Originator Bank and credits the account of the Beneficiary, according to the information provided in the instruction and in accordance with the provisions of the SEPA scheme. The Originator Bank and Beneficiary Bank may be one and the same Financial Institution.
The Beneficiary: is the Customer identified in the Credit Transfer Instruction who receives the funds by means of a credit to its payment account.
Demand for payment services using a customer credit transfer arises from an Originator, who wishes to transfer funds to a Beneficiary. While a bank provides the payment service, the underlying demand and its nature are outside the control and responsibility of the banking industry or any individual bank.
For this requirement to transfer funds to be satisfied, the bank holding the account of the Originator must have the means necessary to remit funds to the bank holding the account of the Beneficiary and in the process be provided with the necessary information to accomplish the transfer.
If the Originator has sufficient funds or sufficient credit with which to execute the credit transfer, if the Originator is acting within its authority and the credit transfer does not break any applicable legal, regulatory, or other requirements, including requirements established by the Originator Bank, then the Originator Bank makes the payment and advises the Originator accordingly.
If the bank holding the account of the Beneficiary, the Beneficiary Bank, has agreed to both the method and the rules for receiving the payment information as well as the method and the rules for receiving the payment value, then the transfer exists.
Based on these transfers the Beneficiary Bank uses the information received to credit the account of the Beneficiary, makes the funds available and informs the Beneficiary what has been applied to its account.
The purpose of inter-bank Clearing and Settlement is to correctly exchange information and to safely exchange value. The demand for Clearing and Settlement services stems from the need to transfer money between banks.
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:
A seeded XML Format Template, Format and Payment Process Profiles for SEPA and mapping the attributes to SEPA Credit Transfer Initiation message (SCT message).
Two new fields, Batch Booking and Grouping Mode, are added in the Payment Process Profile window.
New validation sets for SCT message are added to the specific SEPA payment format. This includes seeded BIC parameter and legal entity address fields in the user-defined validations and the formatting SCT message. You can create user-defined validations similar to the seeded validations.
The Payment Instruction Creation Program (PICP) is enhanced to group the payments within the Payment Instruction files based on fixed parameters. It includes stamping a logical group ID on each of the payment.
The BIC validation is handled in the Oracle Cash Management application when BIC is entered for a Bank Branch.
For Batch Booking, Manual and Automatic reconciliation logics are enhanced to include reconciliation based on the payment groups described above.
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.
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.
Three Payment Process Profiles are seeded representing each of the grouping mode, Single, Grouped, and Mixed.
Grouping and Batch Booking are supported as per the ISO20022 guidelines. The Payment Process Profile includes the Grouping Mode and Batch Booking indicators.
A Grouping mode field with a dropdown list is added in the Payment Process Profile setup window. The list has the following values, Single, Grouped, and Mixed. Based on the Grouping Mode selected the payment initiation message format differs. The default value is Grouped.
The Payment Instruction grouping parameters for Grouped is:
First Party Legal Entity
Internal Bank Account
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.
For SEPA transactions the payment method must be Electronic.
The SCT message structure consists of the following blocks:
Payment Information Block
Credit Transfer Transaction Information Block
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.
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, PaymentMethod, Payment Type Information, Requested Execution Date, Debtor, Debtor Account, Debtor Agent, Bank Charges Bearer etc.
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.
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:
The transaction currency is in Euro. This has been ensured by including EUR as the only valid currency for seeded Payment Process Profiles.
The Bank charge bearer is SLEV.
The Payer address fields are entered.
The originator bank IBAN and the beneficiary bank’s IBAN and BIC code for making SEPA payments are available.
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.
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.
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:
Control Sum - The mapping is provided for this element.
Payment type information: The mapping is provided for sub elements ‘Instruction Priority’ & ‘Category Purpose’
Debtor Account – The mapping is provided for currency of debtor bank account.
Ultimate Debtor: The mapping for ultimate debtor information including ultimate debtor name and identification is supported.
Instruction Identification: The mapping is provided for this element.
Creditor: The mapping for creditor name and address is already supported. Now the mapping for identification of the creditor is also supported.
Ultimate Creditor: The ultimate creditor information including ultimate debtor name and identification is supported.
Payment Purpose: This is supported as part of SEPA core payments.
The mapping for the following elements is changed in accordance with the change in usage rules described in SEPA implementation guidelines V3.3:
Grouping - Usage rules are changed. Only ‘Mixed’ grouping mode is supported.
Initiating party - The address of initiating party is not required and hence removed.
Debtor: The address elements like city, town etc are not required. The identification of debtor is now supported as part of SEPA core payments.
Remittance Information: Structured Remittance: The structured remittance information must contain the creditor reference information. The other details in the structured remittance like the document number, document amount are now prescribed as AOS specific and the mapping of these elements is removed.
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.
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.
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:
Requested Execution Date (Payment Date)
Debtor (First party Legal Entity)
Organization (Operating Unit)
Debtor account (IBAN of the Internal Bank Account)
Currency (Payment Currency)
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 Grouping mode now supports only Mixed and None. The existing users using Single and Grouped have to use only the Mixed grouping mode for SEPA payments. Or use none.
With the changes in the SEPA guidelines, the Structured Remittance information includes only the information of the Creditor Reference. The existing users can send only the Creditor Reference information in the structured remittance information block.
Copyright © 2000, 2010, Oracle and/or its affiliates. All rights reserved.