Funds Disbursement Process Flows

Overview

Note: This chapter assumes that Oracle Payments and all source products have been installed and properly set up. The user addressed in this chapter is the payment administrator, not the implementer.

This chapter provides the functional flows for funds disbursement. Information is also provided on printing checks and making single payments.

For funds disbursement functionality, Oracle Payments integrates with the following E-Business Suite products:

• Oracle Payables

• Oracle Cash Management

• Oracle Receivables

• Oracle Loans

Funds Disbursement Overview Flow

Oracle Payments processes funds disbursement payments in electronic and paper form. This Funds Disbursement Overview Flow in the diagram below depicts an overview of the process that occurs when a source product calls Oracle Payments for processing funds disbursement payments. Examples of products that can use the Funds Disbursement Overview Flow are Oracle Payables, for paying supplier invoices, Oracle Receivables, for paying customer refunds, and Oracle Student System for paying students.

The payment part of the Funds Disbursement Overview Flow can result in electronic payments or printed, paper payment documents. Electronic processing is the creation of a file that is transmitted to a financial institution. The file contains instructions to the financial institution on how to remit funds. In some cases, funds are remitted electronically by an automatic deposit to a bank account. In other cases, the payment file may instruct the financial institution to issue a check for payment.

The diagram below shows the steps performed by the Funds Disbursement Overview Flow.

Funds Disbursement Overview Flow

The table below describes the steps performed by the Funds Disbursement Overview Flow.

Funds Disbursement Overview Flow

Action	Description
Document Creation (F1)	The source product creates documents payable, such as invoices, for which it needs to make payment.
Document Selection (F2)	The source product performs a document selection process. The selected documents are grouped into a Payment Process Request. Note: Flows F2 and F3 are tightly linked. The Document Selection Flow (F2) can be scheduled. The steps in the Payment Process Request Flow (F3) happen automatically upon completion of Flow F2.
Payment Process Request (F3)	The Payment Process Request is submitted to Oracle Payments for processing. Note: Flows F3 to F7 occur in the context of a Payment Process Request.
Account/Profile Assignment (F4)	This flow assigns internal bank accounts, which are the deploying company's bank accounts, and payment process profiles to documents payable within the Payment Process Request. Oracle Payments automatically assigns these values when possible. It also provides a user interface for users to perform these functions if needed.
Document Validation (F5)	Oracle Payments validates the documents payable sent as part of the Payment Process Request to ensure that they have all the information needed for payment processing, and that the information is valid. Documents payable and payment process requests may be sent back to the source product as a result of validation failures, depending on setup options.
Payment Creation (F6)	Once Oracle Payments determines the net amounts due on the documents, it then groups them into proposed payments. Those payments are then validated. If no review or modification of proposed payments is desired, then the process moves to the Payment Instruction Creation Flow (F8).
Review/Modify Process (F7)	Implementers may set up Oracle Payments, or specific payment process requests, to stop the payment process for review after proposed payments are created and validated. You can review the proposed payments and possibly choose not to make some payments, before allowing the payment process to proceed. The next step in the funds disbursement payment flow varies, depending on the actions you take in this process. If modifications are made, the process returns to Payment Creation (F6), to be revalidated.
Payment Instruction Creation (F8)	Oracle Payments processes payments within each Payment Process Request and groups them according to their internal bank accounts, payment profiles, and other grouping rules to create payment instructions. This processing may result in Payment Process Requests being split into different payment instructions or combined together into payment instructions. Note: Flows F6 and F7 complete the creation of a payment process request. Flows F8 to F12 and F15 to F17 occur in the context of a payment instruction.
Validation Failure Handling (F9)	This step is a conditional part of the payment process. Once a payment instruction is created, it must be validated according to Payment's internal rules and by validation sets attached to the payment instruction format. If the payment instruction fails any of these validations, then the process stops, and you can take action.
Extract and Format Operation (F10)	Once a payment instruction is created, it moves to the format process. The flow splits depending on whether or not the format is electronic. Note: For electronic payments, a completion status may be returned to the source product automatically at one of two points, based on setup in the payment process profile: the end of the Extract and Format Operation (F10) or the end of the Transmission Process (F12). If the payment process profile setup allows it, the completion status may also be returned to the source product manually by a user at any time after the Extract and Format Operation.
Security Operation (F11)	For an electronic format, there may be a required way to secure the payment instruction before transmitting it to the financial institution. This step is conditional and depends on the requirements of the payment system.
Transmission Process (F12)	Once the payment instruction has been secured, it is transmitted to the financial institution for processing and disbursement of funds. This step is conditional and depends on the payment process profile setup. The payment process profile also allows Oracle Payments to skip transmission and to output a formatted payment file for a user to transmit outside Oracle Applications.
Print Payment Document Process (F15)	This process is used to print payment documents in-house. This step is conditional and depends on the payment process profile setup. The Print Payment Document Process (F15) shows payment documents printed through Oracle Applications. The payment process profile also allows Oracle Payments to skip printing and to output a formatted payment file for a user to print outside Oracle Applications. Note: Payment documents are printed payments, such as checks, whereas documents payable are entities that need to be paid, such as invoices. Payment Documents are no used for Electronic Payments.
Record Print Status (F16)	Once payment documents have been printed, their status must be recorded in Oracle Payments. This applies to both payment documents printed using Oracle Applications and payment documents printed outside Oracle Applications.
Separate Remittance Advice (F17)	If product setup indicates that separate remittance advice is required to be generated for the payment instruction, it is completed in this flow.

Document Creation Flow

The Document Creation Flow is the process used to create a document payable to be paid. The diagram below shows the steps performed in the Document Creation Flow (F1). Creation of documents payable is done by a source product user, such as a Payables clerk.

Document Creation Flow

Start Entry of Document Payable

The Document Creation Flow starts with the entry of a document payable in the source product.

Initialize Document

The source product initializes the document payable and calls the Default Payment Attributes API, an Oracle Payments component.

Default Payment Attributes API

This component is an API that Oracle Payments offers for population of payment attributes needed to pay a document. Payment attributes are payment details, such as the payment method, remittance bank account, and country-specific information. This API reads from Oracle Payments setup and defaults as much information as is available onto the document payable. The purpose of the Default Payment Attributes API is to streamline document payable creation.

Default Payment Method and Dependent Payment Attributes

The source product invokes the Oracle Payments Default Payment Attributes API to default a payment method for the document payable. Payment attributes that depend on the payment method are also defaulted. The payment method may depend on other attributes of the document payable, such as legal entity or country.

Override Payment Method?

(Yes) - Typically, source products can override the payment method on the document payable. If the source product user chooses to do this, the source product calls the Default Payment Attributes component API again to newly default the correct payment attributes based on the new payment method.

(No) - If the source product user does not override the payment method, the source product can commit the document.

Commit Document

The source product user commits the document payable to the database.

Validate Document

Oracle Payments performs a series of validations when a source product asks for document validation. It checks the setup of the third party payee and ensures that data elements required by the payment method are provided.

Payment Method-Based Document Validation API

A document can either pass or fail the validations performed by the Payment Method-Based Document Validation API. This component is an API that Oracle Payments offers for ensuring that documents are valid in terms of payment readiness. Source products use this API at points where they want to validate that all required payment attributes are populated and valid. The purpose of the Payment Method-Based Document Validation API is to ensure that documents are ready for payment before they are passed to Oracle Payments and that the source product user has an opportunity to address issues immediately. Only document-level validations that are attached to the selected payment method in Oracle Payments setup are applied at this stage. Depending on Oracle Payments setup, further document-level validations may occur later in the payment process.

Return Warnings

Oracle Payments returns any errors it finds during the validation operation to the source product. These errors, which are in the form of warnings, explain the error conditions so the source product user can take corrective action. These warnings, however, do not prevent the user from committing the document.

Show Warnings Online

The source product shows its users warnings for any validation errors, so they can take corrective action.

Review Warnings

The source product's users optionally review warnings. They can always choose to ignore the warnings and correct problems later in the process.

Correct Validation Problems and Finalize Documents

The source product's users optionally corrects errors shown in the warnings. They then commit the document again and it passes through the same validation process.

Return Success

Oracle Payments returns a success message to the source product if the document passes validations.

Document Complete

The source product completes the creation of a document payable.

Document Selection Flow

The Document Selection Flow comprises the steps that are performed when the source product selects documents to be paid. Each source product has its own criteria for allowing a payment to be made. The document selection process occurs within the source product before the payment process is transferred to Oracle Payments.

The diagram below shows the steps performed in the Document Selection Flow (F2).

Document Selection Flow

The information below describes the steps performed in the Document Selection Flow (F2).

Enter Source Product Document Selection Criteria

Each source product determines its own criteria for selecting valid documents to be paid. For example, Oracle Payables has user-specified criteria like Invoice Due Date, Invoice Discount Dates, and Pay Group.

Select Oracle Payments' Payment Profile and Bank Account

This step is optional and provides backward compatibility with Oracle Payables. When the source product user or source product selects documents to be paid, Oracle Payments does not require the user or source product to know the bank account from which the funds are to be disbursed. This information can be provided later in the payment process by a payment administrator or cash manager. However, source products may want to include this information as part of their payment selection criteria and subsequently submit it as part of the Payment Process Request created for Oracle Payments.

If source products want to ensure that their request is handled as a single payment instruction, then their selection criteria must include a payment process profile and an internal bank account. In this case of ensuring that one Payment Process Request equals one payment instruction, the source product passes a parameter to Oracle Payments that indicates this.

Create Payment Process Request Header

The source product creates a Payment Process Request header. The header (or Source Product Reference) may be a request name that is meaningful to the source product user, or simply an internal identifier that allows the user to track the request and manage information about it.

Payment Method-Based Document Validation API

Once the source product creates the Payment Process Request header, it calls Oracle Payments’ Payment Method-Based Document Validation API to validate all documents selected that are to be paid as part of the Payment Process Request. The validations performed during this phase are identical to those that occur during the document creation process.

Validation Errors?

(Yes) - If any of the documents fail the validation process in C2, then the process terminates and the document selection process fails. This occurs because the problems that cause the documents to fail must be corrected in the source product before the documents are passed to Oracle Payments.

(No) - If there are no validation errors, then the flow proceeds to the next step.

Present Selected Document Information for Review

This is an optional process for most source products. Source products may wish to present the documents selected for review in a report or online for source products users to review.

Review Selected Documents

If the source product presents the selected documents for review, then the source product user can optionally review the information.

Modify Document Selection

If the source product provides an online way for users to review selected documents, they can also provide a way for users to modify them. For instance, the source product may allow users to deselect or add documents.

Note: Users can only add documents during the selection process if the source product supports the action. Once a Payment Process Request is submitted to Oracle Payments, no additions to that request can be made.

Modifications Require Re-validation?

(Yes) - Some modifications require source products to call the Payment Method-Based Document Validation API again. Examples of when this is needed are when new documents are added to the selection or when document amounts are changed.

(No) - If no changes were made that require re-validation, the process proceeds to the next step.

Finalize Documents to be Paid

This step ends the loop of selected document review and modification.

Group into Payment Process Request Structure

Source products group selected documents into a Payment Process Request for submission to Oracle Payments. The source product creates a Payment Process Request with the following structure:

• a header with the required identification information

• documents selected for payment

• document lines for the selected documents

Payment Method-Based Document Validation API

The subflow below shows the steps that are performed when the Payment Method-Based Document Validation API (C2) is called.

Payment Method-Based Document Validation API

The table below describes the steps performed in the Payment Method-Based Document Validation API (C2).

Payment Method-Based Document Validation API

Action	Description
Loop: Repeat for Each Document	This loop process is used when the Payment Method-Based Document Validation API is called for multiple documents payable, as in the Document Selection Flow. Each document payable must pass through this validation process.
Read Document Payment Method	Oracle Payments ties these validations to the payment method on the document payable. The document payable payment method is read first.
Perform Validations Based on Payment Method	Once the payment method is read, Oracle Payments performs the validations that are linked to that payment method.
Payment Process Profile and Bank Account Provided in Request?	Source products have the option of providing this information in their Payment Process Request header. If the information is provided in the Payment Process Request, then Oracle Payments validates it. If it is not provided, then the validation process ends.

Payment Process Request Flow

The source product submits a Payment Process Request to Oracle Payments to process payments for its selected documents. The diagram below shows the steps performed when a Payment Process Request Flow (F3) is submitted to Oracle Payments.

Payment Process Request Flow

The table below describes the steps performed in the Payment Process Request Flow (F3).

Payment Process Request Flow

Action	Description
Initiate Payment Process Request	The source product initiates the Payment Process Request process.
Read Documents in Request	The source product reads all the documents that it built into the Payment Process Request in the Document Selection Flow (F2).
Lock Documents from any Changes	The source product locks the documents from any further changes. Documents must be locked during the payment process so that Oracle Payments receives a controlled view of what needs to be paid. The source product provides a status on its documents that indicates the documents have been selected for payment or are in the payment process so the source product's users know why updates cannot be made.
Submit Payment Process Request (C3)	Oracle Payments provides an API component, Submit Payment Process Request (C3), that enables source products to submit a Payment Process Request , as well as optional information, such as payment process profile and internal bank account.
Validate Request Submission	Once the Oracle Payment Process Request is submitted, Oracle Payments validates the request submission. This validation ensures that the request parameters can be read and that the data is stored in Oracle Payments. Note: This process does not validate any of the documents in the request.
Validation Errors?	Yes. If the Payment Process Request finds errors during validation (for example, the records cannot be written to the Oracle Payments tables), Oracle Payments rejects the Payment Process Request. No. If the Payment Process Request is validated successfully, the process continues.
Fail Payment Process Request	The source product fails the Payment Process Request if Oracle Payments rejects it.
Unlock Documents	The source product unlocks the documents that were sent in the request and resets the document status. The documents are then ready for a new selection process.
Store Payment Process Request	Oracle Payments takes all data received in the Payment Process Request and stores it in its transaction tables. The Payment Process Request is given a status of Submitted. Oracle Payments shows different statuses on a Payment Process Request and payment instruction throughout the payment process. This is done to help control payment processing, as well as provide useful information.

Account/Profile Assignment Flow

The Account/Profile Assignment Flow assigns required payment information to the Payment Process Request. This information is needed for further payment processing, including validations in the Document Validation Flow. All steps in this flow are performed as part of the Build Payments program until you take action in the Complete Document Assignments page (C5).

The diagram below shows the steps performed in the Account/Profile Assignment Flow (F4).

Account/Profile Assignment Flow

The table below describes the steps performed in the Account/Profile Assignment Flow (F4).

Account/Profile Assignment Flow

Action	Description
Account/Profile Provided on Request?	The Build Payments program determines if the Payment Process Request has the internal bank account and payment process profile assigned to it.
(Yes) Assign to all Documents in Payment Process Request	If the bank account or payment process profile is provided, then it is assigned to all the documents payable within the Payment Process Request. The payment process proceeds to the document validation phase (F5).
(No) Loop: Repeat for Each Document	If no bank account or payment profile is provided (or only one of these is provided), then a loop process is performed for each document payable.
Automatically Default Information Where Possible	Oracle Payments attempts to default the required bank account and payment process profile information where possible. An example of when defaulting occurs is when a payment method is set up and linked to only one payment process profile. Default of an internal bank account may be possible if only one account is available for use by the operating unit that owns the transactions in a Payment Process Request.
Any Documents Missing Information?	Once the defaulting process is complete for each document in the Payment Process Request, Oracle Payments determines if any documents are missing the required information. (No). If all documents are complete, then the flow is complete and the payment process proceeds to the document validation phase (F5).
Update Request Status	If any documents are missing information, then the Payment Process Request is updated with a status of Information Required - Pending Action. This status enables you to access a page where you can assign the required information. You must complete the assignment of missing information to enable the payment process to continue.

Build Payments Program Component

All steps in the Account/Profile Assignment Flow are performed as part of the Build Payments program until you assign accounts and the payment process profile to the documents payable in the Complete Document Assignments page. Oracle Payments owns the Build Payments program component. The Build Payments program performs the following steps in the payment process:

1. assigns bank accounts and payment process profiles to a Payment Process Request

2. validates the documents payable sent in the Payment Process Request

3. builds documents within a Payment Process Request into proposed payments

4. validates the proposed payments in a Payment Process Request

5. optionally presents the proposed payments to the payment administrator for review

Complete Document Assignments Page Component

The Complete Document Assignments Page Component provides a user interface for you to manually assign required information to documents payable as needed. The information that must be assigned is an internal bank account and/or a payment process profile. You can also optionally change information in this page.

The Complete Document Assignments Page handles all validations of the entered values. When you access the page to assign missing information, the Payment Process Request status is Information Required - Pending Action. Once you have assigned all missing information, the page updates the Payment Process Request status to Assignment Complete. Requests with a status of Assignment Complete are available for further payment processing.

Document Validation Flow

Oracle Payments performs validation on all data received in the Payment Process Request. This validation process may result in failures when documents payable do not pass the validation checks. All steps performed by Oracle Payments in the Document Validation Flow are part of the Build Payments program. For information on the Build Payments program, see Build Payments Program.

The diagram below shows the steps performed when Oracle Payments validates documents in a source product’s Payment Process Request.

Document Validation Flow

The table below describes the steps performed in the Document Validation Flow (F5).

Document Validation Flow

Action	Description
Read System Options for Setup of Request Rejection Level	Oracle Payments supports four setup options for Oracle Payments to control how documents payable are rejected if they fail validation. The first option is Request Level. If this option was selected during implementation, it means that if any document in the entire Payment Process Request fails validation, then all the documents in the Payment Process Request are rejected. The second option is Payee Level. This option rejects all documents for a payee if any document for that payee fails validation. This option is useful when you want certain documents of a payee to be paid together, such as invoices with offsetting credit memos. The third option is Document Level. This option only rejects documents with validation errors. All other documents continue in the payment process. The fourth option is Stop Process For Review. No documents are immediately rejected and the validation errors are presented to you for review.
Payment Method-Based Document Validation API (C2)	Oracle Payments validates all documents using the Payment Method-Based Document Validation API (C2). All document validations are based on the payment method of the document.
Payment Format-Based Document Validations (F5-1)	Oracle Payments validates all documents using the Payment Format-Based Document Validations Flow (F5-1). These validations are based on the payment format assigned to the payment profile of the document.
Any Documents Failed Validation?	At this point, the flow branches, depending on whether any documents failed validation.
(No) Flag all Documents as Validated	When all documents pass validation, Oracle Payments assigns a validated status to each of them. Then the process updates the request status to Documents Validated and moves on to the Payment Creation Flow (F6).
(Yes) Rejection Level System Option?	Oracle Payments knows which rejection level it is by reading the system setup in the first step. Oracle Payments next performs one of four actions depending on the setting of the system option.
Request Level	Reject all Documents: At the Request Level, if one document fails validation, all documents in the Payment Process Request are rejected. Update Request Status: The status of the Payment Process Request is updated to Failed Document Validation. Payment Process Request Rejected: Oracle Payments informs the source product of the rejection of the Payment Process Request and the validation failures. The message instructs the source product to fail/cancel the Payment Process Request. The message sends the source product a list of all documents that failed, with identifying information and rejection reasons. Oracle Payments marks those documents as failed and takes no further action. The source product then treats those documents as new documents payable. The source product must correct any errors and send the documents to be paid in a new Payment Process Request. Fail Payment Process Request: The source product fails the Payment Process Request if Oracle Payments rejects it. Unlock Documents: The source product unlocks documents that were sent in the request and resets the document status. The documents are then ready for a new selection process.
Payee Level	Oracle Payments identifies: the payee on the document all documents in the Payment Process Request for the payee Reject all Documents for Payees with any Failed Document: Oracle Payments rejects all documents for the payee that had one or more failed documents. Documents Rejected: Oracle Payments informs the source product of the validation failures and rejection of the documents payable. The message sends a list of documents that failed with identifying information and rejection reasons. Oracle Payments marks those documents as failed and takes no further action. The source product treats those documents as new documents payable. The source product corrects any errors and sends the documents to be paid in a new Payment Process Request. Unlock Documents: The source product unlocks the documents that were rejected and resets the document status. The documents are then ready for a new selection process. Accept all Other Documents and Flag them as Validated: Oracle Payments continues processing all the documents that were not rejected. Update Request Status: Once all documents have been flagged as either failed or validated, Oracle Payments updates the status of the payment process request to Documents Validated. All documents marked as failed are invalid and disregarded for future processing.
Document Level	Reject Only Failed Documents: Oracle Payments rejects only those documents that fail validation. Documents Rejected: Oracle Payments informs the source product of the validation failures and rejection of the documents payable. The message sends a list to the source product of documents that failed, with identifying information and rejection reasons. Oracle Payments marks those documents as failed and takes no further action. The source product treats the failed documents as new documents payable. The source product corrects any errors and sends the documents to be paid in a new Payment Process Request. Unlock Documents: The source product unlocks the documents that were rejected and resets the document status. The documents are then ready for a new selection process. Accept all Other Documents and Flag them as Validated: Oracle Payments continues processing documents that were not rejected. Update Request Status: Once all documents have been flagged as failed or validated, Oracle Payments updates the status of the Payment Process Request to Documents Validated. All documents marked as failed are invalid and disregarded for future processing.
Stop Process for Review	No Documents Rejected: Oracle Payments does not immediately reject any documents payable. Instead, it updates the status of the Payment Process Request to Document Validation Errors - Pending Action, and presents the failed documents for review. Using the Resolve Document Validation Errors Page, you may review the errors and take action. You may fix related data, such as third party payee information, and submit the documents for revalidation. You may also remove documents from the Payment Process Request, which sends the documents back to the source product with the validation failure reason, just as rejection does. Unlock Documents: The source product unlocks the documents that were removed and resets the document status. The documents are then ready for a new selection process. Accept all Other Documents and Revalidate them: Oracle Payments runs the payment method-based document validations and the payment format-based document validations again. If there are further errors, they are again presented to you for review. Otherwise, Oracle Payments continues processing documents. Update Request Status: Once all documents have been flagged as failed or validated, Oracle Payments updates the status of the Payment Process Request to Documents Validated. All documents marked as failed are invalid and disregarded for future processing.

The diagram below shows the steps performed in the Payment Format-Based Document Validations Subflow (F5-1).

Payment Format-Based Document Validations Subflow

All steps in the Payment Format-Based Document Validations Subflow (F5-1), as shown in the table below, are performed by the Build Payments program component. For information on the Build Payments program component, see Build Payments Program.

Payment Format-Based Document Validations Subflow

Action	Description
Loop: Repeat for each Document	Each document must pass through this validation process.
Read Attributes of Payment Profile	Oracle Payments reads the attributes of the payment profile - most importantly the payment format. Examples of payment profile attributes are the payment format and the payment system.
Perform Applicable Validations	Once the payment attributes are read, Oracle Payments performs all validations that are attached to the payment format.

Payment Creation Flow

Oracle Payments groups documents to be paid into proposed payments according to payment creation rules. Payment creation rules specify how documents payable are grouped into payments. Some rules are hard coded while others are user-defined. Payment creation rules may result, for example, in grouping documents that are payable to Payee A and to Payee A's bank account A1 into one payment, while grouping documents that are payable to Payee A and to Payee A's bank account A2 into a second payment.

The diagram below shows the steps performed in the Payment Creation Flow (F6).

Payment Creation Flow

The table below describes the steps performed in the Payment Creation Flow (F6) within the Build Payments program (C4). For information on the Build Payments program, see Build Payments program.

Payment Creation Flow

Action	Description
Read Processing Option: Review Proposed Payments	In this step, the Build Payments program reads the setting of the processing option. Oracle Payments provides a system option to set if your business process requires review of proposed payments before finalizing them. This option defaults onto processing options contained in the Payment Process Request. If the option is enabled, then Oracle Payments prevents the Payment Process Request from proceeding until your review has been completed.
Payment Process Request: Read Documents that Passed Validation	Oracle Payments finds all documents that passed validation within a Payment Process Request. The Build Payments program reads all these documents.
Read Grouping Rules Set Up by User	The Build Payments program reads user-defined grouping rules.
Group Documents into Proposed Payments. Group by User-Defined Rules and System-Defined Rules.	The Build Payments program groups the documents into proposed payments. Grouping is done by user-defined and system-defined rules. Examples of system-defined rules include: grouping by payment profile, where all documents grouped into a payment must share the same payment profile grouping within payment process requests, where payments are not created across payment process requests
Hook: Payment Amount Special Calculation Component (C6)	The Payment Amount Special Calculation Component (C6) is provided by source products and used by Oracle Payments. Before Oracle Payments can create proposed payments, it must determine the net amount payable on the documents. Oracle Payments calls this component, a hook, which in turn calls code from source products to perform calculations on the documents. For example, Oracle Payables needs withholding and interest calculated on their documents. Oracle Payables provides these calculations as part of the Payment Amount Special Calculation Component and Oracle Payments calls the calculations.
Calculate Bank Charges (optional)	If functionality to calculate bank charges is enabled in setup, this is when bank charges are calculated. Note: This is only relevant for the Japanese bank charge feature as it existed in Oracle Payables in release 11i.
Number Payments	The Build Payments program numbers the payments with an internal identifier that can be used to identify the payments in communications between Oracle Payments and source products. This internal identifier is not the numbering of the payment documents, as in check numbering.
Validate Created Payments	Once proposed payments are created, validations that can only be done for a built payment, such as amount validations, are performed.
Any Payments Failed Validation?	If there are no validation errors, the payment creation process proceeds to store the proposed payments.
Store Proposed Payments	The proposed payments are stored in Oracle Payments' tables.
Proposed Payment Review Required?	The setting of the system option to require review of proposed payments determines the action performed.
(Yes) Update Request Status	If proposed payment review is required, the request status is set to Pending Proposed Payment Review. This status prevents the Payment Process Request from being picked up for processing into a payment instruction. The status of the proposed payments is set to Created.
(No) Update Request Status	If proposed payment review is not required, the request status is set to Payments Created. This status enables the Payment Process Request to be eligible for processing into a payment instruction. The status of the proposed payments is set to Created.

The diagram below shows steps performed in the Payment Creation Validation Error Handling Subflow (F6-1), which handles payment validation errors. These steps are handled within the Build Payments program component. For information on the Build Payments program, see Build Payments program.

Payment Creation Validation Error Handling Subflow

The table below describes steps performed in the Payment Creation Validation Error Handling Subflow (F6-1) within the Build Payments program (C4) to handle payment validation errors. For information on the Build Payments program, see Build Payments program.

Payment Creation Validation Error Handling Subflow

Action	Description
Store Validation Error Information	Oracle Payments stores validation error information.
Read Processing Option for Setup of Rejection Level	Oracle Payments provides three options that can be selected to manage errors in payment validations: Request Level Payment Level User Intervention Required; No Automatic Rejections Performed The first option is Request Level. This option results in the entire Payment Process Request being rejected if there are any payments with errors. You may want this option to ensure that all your payments are processed together (to reduce bank fees, for example). The second option is Payment Level. This option rejects only the payments that had validation errors and proceeds with the payment process. The last option performs no rejections and requires user action.
Rejection Level Processing Option?	Oracle Payments checks the setting of the processing option and performs one of the following actions depending on the setting: Request Level Payment Level Stop Process for Review
Request Level	Reject all Payments: If the rejection level is Request, then the entire Payment Process Request is rejected if one document fails validation. Update Request and Payment Status: The status of the Payment Process Request and proposed payments is updated to Failed Payment Validation. Payment Process Request Rejected: Oracle Payments informs the source product of the rejection of the Payment Process Request and the validation failures. The message instructs the source product to fail/cancel the Payment Process Request. The message sends a list of all failed documents payable with identifying information and rejection reasons to the source product. Oracle Payments marks those documents as failed and takes no further action. The source product treats those documents as new documents payable, correct any errors, and sends the documents to be paid in a new Payment Process Request. Fail Payment Process Request: The source product fails the Payment Process Request if Oracle Payments rejects it. Unlock Documents: The source product unlocks the documents that were sent in the request and resets the document status. The documents are then ready for a new selection process.
Payment Level	Reject Only Payments with Validation Errors: Oracle Payments rejects only those payments that had validation errors. Update Payment Status: For any payments that had validation errors, the payment status is set to Failed Validation. Payments Rejected: Oracle Payments informs the source product of the validation failures and rejection of the payments. The message sends a list of all failed documents with identifying information and rejection reasons to the source product. Oracle Payments marks those payments and documents as failed (the payment status is set to Failed Validation) and takes no further action. The source product treats those documents as new documents payable, corrects any errors, and sends the documents to be paid in a new payment process request. Unlock Documents: the source product unlocks the documents that were rejected and resets the document status. The documents are then ready for a new selection process. Accept all Other Payments and Flag them as Validated: If the rejection level is Payment, Oracle Payments continues processing the payments that were not rejected. Update Payment Status: All accepted payments have their status updated to Created. The process then returns to the Payment Creation Flow, where it continues the process for all payments that successfully passed validation.
Stop Process for Review	Perform no Automatic Rejections: If the system option has this setting, Oracle Payments does not automatically reject any payments. Instead, user intervention is required to review and take action on the failed payments. Update Payment Status: For any payments marked as having validation errors, the payment status is set to Failed Validation. Accept all Other Payments and Flag them as Validated: Oracle Payments sets the status for all payments that passed validation to Created. Update Request Status: Oracle Payments updates the status of the Payment Process Request to Payment Validation Errors - Pending Review. This status prevents the request from being selected for further payment processing. You can then take actions in the Review/Modify Process Flow (F7) to cancel or correct payments with errors.

Review/Modify Process Flow

In general, once a source product user submits the Payment Process Request to Oracle Payments, Oracle Payments does not allow further revisions at the document payable level, but does allow changes at the Payment Level. Changes at the document level are allowed during the selection process before the Payment Process Request has been submitted and are managed by the source products.

Oracle Payments provides the Review/Modify Process Flow (F7) for you to optionally review or modify proposed payments. This process is available on a Payment Process Request with a status of Failed Payment Validation or Pending Proposed Payment Review. You can also optionally stop the process if any proposed payments have creation errors, review the errors, and take the appropriate action.

The diagram below shows the steps performed in the Review/Modify Process Flow (F7).

Review/Modify Process Flow

The table below describes steps performed in the Review/Modify Process Flow (F7).

Review/Modify Process Flow

Action	Description
Review Online	At the start of this flow, the payment process has stopped. Oracle Payments provides two ways to review proposed payments: in a report or online. The report is not available when the process is stopped because payments have failed validation.
Payment Process Request Status Report Component (C7)	The Payment Process Request Status Report Component (C7) is a report that you can run that displays proposed payment information. You can request the report to run automatically after proposed payments have been created and validated or run the report by standard report submission. The report provides parameters, such as the Payment Process Request name/identifier and runs if the Payment Process Request status is Payments Created.
Review Proposed Payments Component (C8)	The Review Proposed Payments Component (C8) is a user interface that displays proposed payment information for online reviewing.
Modify Payments (C8)	Once you have reviewed the proposed payments or payment validation errors, you can make changes. To make changes, use the Modify Payments Component (C8) as the user interface.

Modify Payments Component

The information below describes the Modify Payments Component (C8), which is within the Review/Modify Process Flow (F7).

The Modify Payments Component (C8) is a user interface that supports online review of proposed payments and optional modifications to the proposed payments. The component does not allow any actions that are initiated by the source products, such as adding payable documents and changing payment amounts. These actions are handled by the source product selection process user interface if needed.

The Modify Payments Component has two varieties. If payments fail validation and Oracle Payments is set up to stop the payment process for review, the Modify Payments Component is presented to you in the form of the Resolve Payment Validation Errors Page. If the payments have succeeded validation, the component is presented in the form of the Review Proposed Payments Page. These two pages have somewhat different functionality. The major difference is how the payment process handles the Payment Process Request upon which you act. When you submit your changes on the Resolve Payment Validation Errors page, the Payment Process Request rejoins the payment process at the payment validation stage in the Payment Creation Flow (F6). When you submit your changes and continue the payment process on the Review Proposed Payments Page, Oracle Payments determines whether you have removed documents payable from any payments. If so, the Payment Process Request rejoins the payment process at the payment validation stage in the Payment Creation Flow - (F6). If not, the Payment Process Request is considered complete. Its status is updated to Payments Created and its payments become available for the Payment Instruction Creation Flow (F8).

Other differences in the behavior of the pages are noted below.

The Modify Payments Component supports the following user actions:

• Action 1: Remove payments

• Action 2: Remove documents

• Action 3: Change remittance bank account. This action is only available on the Review Proposed Payments Page.

• Action 4: No modifications

As in the case of the Resolve Document Validation Errors Page, there is another action you can take that is not explicitly supported by this component. When payments have failed validation, you may leave the Resolve Payment Validation Errors page and update the setup of bank accounts, third party payees, payment methods, or payment formats to allow the payments to pass validation. You may then return to this page, follow one of the four actions listed above, and then continue the payment process. When the payments are revalidated, any setup changes you have made will be activated. Note that you cannot change details of the documents payable or payments, such as amounts or currencies.

Action 1: Remove Payments

You can decide that an entire payment should not be processed and you can indicate that the payment should not be included in the Payment Process Request. When this action is taken, Oracle Payments removes the payment and associated documents from the Payment Process Request. Oracle Payments informs the source product that the documents in the proposed payment are not being paid. The source product unlocks the documents and resets the document status. This makes the documents ready for selection in a new Payment Process Request.

Action 2: Remove Documents

You can decide that documents payable within a payment should not be processed. When this action is taken, Oracle Payments removes the documents from the Payment Process Request. Oracle Payments informs the source product that the documents are not being paid. The source product unlocks the documents and resets the document status. This makes the documents ready for selection in a new Payment Process Request.

Action 3: Change Remittance Bank Account

You can decide to change the remittance bank account (payee bank account). The user interface enables you to validate that the selection of a new bank account is valid for that payee/payment. This action is only available on the Review Proposed Payments page.

Action 4: No Modifications

You can always leave the component without making any changes to the proposed payments.

Payment Instruction Creation Flow

The Payment Instruction Creation Flow (F8) is primarily comprised of steps that occur within the Create Payment Instructions program Component (C9). For information on the Create Payment Instructions program, see Create Payment Instructions Program.

Oracle Payments builds a payment instruction for one or more Payment Process Requests. A payment instruction is a collection of payments, along with aggregate payment information. Depending on the setup, a payment instruction may be converted into a file to be printed onto checks or into a payment file that is transmitted to a payment system for further processing and disbursement.

The diagram below shows the steps in the Payment Instruction Creation Flow (F8).

Payment Instruction Creation Flow

The table below describes the steps performed in the Payment Instruction Creation Flow (F8).

Payment Instruction Creation Flow

Action	Description
Scheduling Initiates Start of Process	The Create Payment Instructions program is a concurrent request that can be scheduled.
Create Payment Instructions Program Component	Once a payment has been included in a payment instruction, its status is updated to Instruction Created. This status ensures that the payment is not selected by another payment instruction.
Any Errors that Cause Failure – Yes Result	If any validation failures occur that have not been overridden in the past (see Payment Instruction Validation Error Handling, Flow, F9), then the payment instruction fails with the status Failed Validation. The payment instruction can then be reviewed in the user interface that Oracle Payments provides.

Create Payment Instructions Program Component

The information below describes the Create Payment Instructions program Component (C9), which is within the Payment Instruction Creation Flow (F8).

The Create Payment Instructions program Component (C9) shown in the preceding figure is a concurrent program that creates one or more payment instructions. This program has several optional parameters that can be used to limit the payments that are included in the payment instruction creation process or to dictate further payment processing. First, the program reads all payments that have a status of Created. This status makes payments eligible to be built into a payment instruction.

If any of the selection parameters for the Create Payment Instructions program are provided, then the payment instruction is created from payments with that specific information.

Oracle Payments supports user-defined rules for creating payment instructions. You may want to group payments from separate Payment Process Requests into a single payment instruction that is sent to your bank. This can help defray bank fees. Alternately, you may want to split different kinds of payments into their own payment instructions to process them differently. The Create Payment Instructions program first divides eligible payments based on payment process profile. Each payment instruction may only contain payments that all have the same payment process profile. Then, the Create Payment Instructions program Component reads the setup rules for payment instruction creation in each payment process profile and groups the payments into payment instructions accordingly.

An example of a payment instruction creation rule is combining payments from different operating units into the same instruction to defray bank fees.

Payment Instruction Validation Failure Handling Flow

The Validation Failure Handling Flow begins when a payment instruction fails validation. The two kinds of errors that cause a payment instruction to fail are system errors and user-defined errors.

The diagram below shows the possible user actions that can be performed in the Payment Instruction Validation Failure Handling Flow (F9).

Payment Instruction Validation Failure Handling Flow

Resolve Payment Instruction Validation Errors Page Component

The information below describes the steps performed in the Resolve Payment Instruction Validation Errors Page Component (C10), which is within the Payment Instruction Validation Failure Handling Flow (F9).

The Resolve Payment Instruction Validation Errors Page Component (C10) is a user interface that supports review and management of payment instructions and their validation errors. From the context of a payment instruction, you can drill into detail and see the payments that make up the instruction. You can also drill down on the payments and see their constituent documents payable. The user interface enables you to take two possible actions.

The Resolve Payment Instruction Validation Errors Page Component supports the following actions:

• Action 1: Remove payments

• Action 2: Override errors

As in the case of the Resolve Document Validation Errors page and the Resolve Payment Validation Errors page, there is another action you can take, which is not explicitly supported by this component. You may leave the Resolve Payment Instruction Validation Errors page and update the setup of bank accounts, third party payees, payment methods, or payment formats to allow the payment instruction to pass validation. You may then return to this page, follow one of the two actions listed above, and then continue the payment process. When the payment instruction is revalidated, any setup changes you have made are taken into account. Note that you cannot change details of the documents payable or payments, such as amounts or currencies.

Action 1: Remove Payments

You can remove one or more payments. You may decide to take this action when a payment instruction exceeds a defined amount limit. Removing payments can result in lowering the payment instruction amount below the limit. When this action is taken, Oracle Payments removes the payment and associated documents from the Payment Instruction. Oracle Payments informs the source product that the documents in the payment are not being paid. The source product unlocks the documents and resets the document status. This enables the documents to be selected in a new Payment Process Request.

Next, the status of the payment instruction is updated to Retry Creation. The Create Payment Instructions program Component (C 9) looks at this status to determine whether to attempt to validate the payment instruction again.

Action 2: Override Errors

For some errors, you can choose to override the error and force the Create Payment Instructions program Component to ignore it when the payment instruction is revalidated. Oracle Payments stores your action so that the next time the Create Payment Instructions program Component processes the payment instruction, the errors will be ignored. This action can only be performed on user-defined errors. User-defined errors are those that result from instruction-level validations that are assigned to the payment method or payment format.

Format Payment Instructions

The information below describes the functionality of the Format Payment Instructions program. After the Create Payment Instructions program completes, the Format Payment Instructions program, another concurrent program, extracts, formats, prints, and transmits all payment instructions, according to Oracle Payments setup. Note that the Format Payment Instructions program is always initiated automatically. The Format Payment Instructions program also creates the following documents, if instructed to by setup:

• accompanying letter

• positive pay file

• central bank reporting

• remittance advice

From the Extract and Format Operation Flow (F10) forward in the Funds Disbursement Process, the Format Payment Instructions program performs the following actions:

• The Extract and Format Operation Flow (F10) extracts payment instruction data from the Oracle Payments tables and uses Oracle XML Publisher to format the payment instructions into files that are ready to transmit or print. The payment process profile may indicate that some payment instructions should not be transmitted or printed, but rather output to a file for handling outside the Oracle E-Business Suite.

• The Security Operation Flow (F11), if applicable, applies security procedures to formatted payment instructions, as specified by the appropriate payment system, before transmission.

• The Transmission Process Flow (F12), if applicable, transmits formatted payment instructions to the appropriate payment systems.

• The Print Payment Documents Process Flow (F13), if applicable, uses Oracle Applications to print payments onto payment documents.

• The Separate Remittance Advice Flow (F15), if applicable, sends separate remittance advice to third party payees.

Extract and Format Operation Flow

Oracle Payments uses Oracle XML Publisher to format its payment instructions according to formatting requirements of specific financial institutions. Formatting results in the placement of data in a data file by using a template that contains prescribed formatting attributes, such as location, font, and font size. Financial institutions, intermediaries, and/or countries have specific electronic format requirements that payers must adhere to before sending an electronic payment instruction. Payment documents also require correct formatting before payments can be printed onto them.

The diagram below shows the steps performed by the Extract and Format Operation Flow (F10) to format a payment instruction.

Extract and Format Operation Flow

The table below describes the steps performed in the Extract and Format Operation Flow (F10).

Extract and Format Operation Flow

Action	Description
Numbering Operation	The numbering operation includes the following: numbering required by the financial institution on both payment documents, for example checks, and payment instructions. This numbering is typically used by the financial institution to identify the payment and by the deploying company to perform reconciliation after the payment has been made.
Create Extract XML Message	Oracle Payments extracts payment instruction data from the database into an XML message.
Pass Extract XML Message to Oracle XML Publisher	The extract XML message is sent to Oracle XML Publisher for formatting.
Apply Format Template	Oracle XML Publisher uses templates to format the Extract XML message into a form that can be printed onto payment documents or that is acceptable to a payment system processing electronic payments. Oracle Payments tells Oracle XML Publisher which format template to apply to the message. The templates used for formatting are Oracle XML Publisher's eText templates. For information on using Oracle XML Publisher's eText templates, see Oracle XML Publisher User's Guide.
Format Payments and Store Output	Oracle XML Publisher formats the payments in the payments instruction and stores the output.
Update Payment Instruction and Payment Status	The status of the payment instruction is updated to Formatted and the status of all payments built into the payment instruction is also updated to Formatted.
Payment Register	Once a payment instruction has been formatted, payments within that payment instruction can be reviewed in report format. The Payment Instruction Register report can be run at any time after payment instruction creation. The report lists the various statuses of payments within the payment instructions, such as Formatted or Transmitted.

Security Operation Flow

When a payment instruction file is ready for transmission to the payment system, a security operation is performed. Security can take the following forms and is only performed according to the requirements of the payment system.

• encryption of data

• sealing of instruction payment file

• digital signatures

Oracle Payments provides the Security Program Component (C11) shown below to secure information in a payment instruction.

Security Operation Flow

Transmission Process Flow

Oracle Payments supports transmission of a payment instruction to a payment system. The diagram below shows the steps performed to transmit a payment instruction to a payment system.

Transmission Process Flow

The table below describes the steps performed in the Transmission Process Flow (F12) where Oracle Payments electronically transmits the payment instruction to the payment system. At this point in the process, the payment system has not yet read or processed the payment instruction.

Transmission Process Flow

Action	Description
Transmission	The Format Payment Instructions program transmits the payment instruction. Through the payment process profile, Oracle Payments can be instructed to transmit payment instructions automatically or to stop the process and wait for you to initiate transmission through the Funds Disbursement Dashboard.
Instruction Received Successfully	Oracle Payments detects that the transmission has completed successfully.
Update Instruction Status and Payment Status	The payment instruction status is updated to Transmitted. The payments built into the payment instruction are also updated with a status of Transmitted.
Time Out/No Receipt	If Oracle Payments detects that the transmission has prematurely terminated, or has timed out without completing successfully, then the process proceeds to the next step, which allows you to manage the transmission failure through the Resolve Payment Instruction Transmission Failure Component (C13)
Update Instruction Status	The payment instruction status is updated to Transmission Failed.
Resolve Payment Instruction Transmission Failure Component (C13)	The Resolve Payment Instruction Transmission Failure Component (C13) is a user interface that supports choosing one of the following actions: retransmit instruction ignore transmission failure terminate payment instruction

Transmission

The information below describes the Transmission portion of the Format Payment Instructions program, which is within the Transmission Process Flow (F12).

When the Format Payment Instructions program detects that the transmission operation has completed successfully, it updates the status of the payment instruction and all payments within the payment instruction to Transmitted. Note that detecting the status of the transmission operation simply involves interpreting the status returned by the transmission protocol (for example, a successful 200 status for HTTP). The payment system does not actively acknowledge that it received the transmitted payment instruction.

Resolve Payment Instruction Transmission Failure Component

The information below describes the Resolve Payment Instruction Transmission Failure Component (C13), which is within the Transmission Process Flow (F12).

The Resolve Payment Instruction Transmission Failure Component is a user interface that lets you view and manage payment instruction transmission failure. The interface supports the following actions on a payment instruction:

• Action 1: Retransmit Instruction

• Action 2: Ignore Transmission Failure

• Action 3: Terminate Payment Process

Action 1: Retransmit Instruction

This action launches the Transmission Program Component (C12) again and attempts to retransmit the payment instruction.

Action 2: Ignore Transmission Failure

You can take this action when you need to force the payment instruction status to Transmitted by handling transmission problems manually outside of Oracle Payments. For information on handling transmission failures, see Resolving Payment Instruction Transmission Failure.

Action 3: Terminate Payment Process

You can decide to terminate the payment instruction. When this action is taken, Oracle Payments sets the status of the payment instruction to Terminated. Oracle Payments informs the source product of the terminated documents payable. Then for each payment in the payment instruction, Oracle Payments sets the status to Canceled. The source product unlocks the documents and resets their status so they are ready for future selection.

Supporting Transmission Configuration

Payments generate settlement batch files based on unique combination of payee, payment system, and payment system account. For customers with multiple internal divisions, the number of settlement batch files generated could exceed the daily limit set by third party payment processors.

Earlier, the payment system accounts with the same set of transmission parameters were grouped into a separate settlement batch files. The transmission parameters were not considered while grouping the settlement batch files, as they were not uniquely identifiable. This resulted in more number of settlement batch files, even though the transmission parameters were same.

With this enhancement, the system groups the payment system accounts with the same set of transmission configuration in a single file, resulting in less number of settlement batch files generated.

In the Payments application, a new Transmission configuration is added for a Payment System Account with the same set of parameters. As a result, each transmission configuration is taken as a unique value and a separate settlement batch file is created.

When setting up Payee, the Transmission Configurations created is attached to a Payment System Account. You can reuse the Transmission Configurations.

While generating settlement batch files, the application uniquely identifies the Payment system accounts with the same transmission configuration and groups them in to a single file. This reduces the number of settlement batch files that are created.

A new option, Transfiguration Configuration is added under Payment Setup, Payment System menu.

You can use this window to create, update, or view the transmission configuration details.

To Create Transmission Configurations:

1. Enter the name of the transmission configuration to create.

2. Displays the selected Protocol.

3. Displays the parameter based on the selected protocol.

4. Name of the parameter displays.

5. Indicates the data type.

6. Enter the values for the parameter.

7. Click Apply to create a transmission configuration.

To Set Up Configuration Parameters:

1. Select a protocol in the Select Protocol field.

2. Click Create Configuration to create a new configuration. A Create Transmission Configuration window appears where you enter the values.

3. Displays the Name of the configuration.

4. Displays the name of the protocol for which the configuration was created.

5. Displays the status.

6. Select Update to update a transmission.

To Update Transmission Configurations:

1. Displays the name of the selected transmission configuration. You can update the name.

2. Displays the selected Protocol.

3. Displays the tunneling configuration details. You can update the value.

4. Displays the status of the configuration if it is Active or Inactive. You can update the value. If you change the value to Inactive, then the system assigns the current date and the end date. If you select Status as Active, then the end date is removed.

5. Displays the end date when the configuration is inactive from.

6. Update the values for the parameters.

7. Click Apply to update the transmission configuration.

Attaching the Transmission Configuration to a Payment System Account

The Transmission configurations created through the setup can be attached to a Payment System Account while defining the Payee. Each payment system account is attached with the uniquely identifiable transmission configurations. You can attach the same Transmission Configuration to multiple payment system accounts.

Payment Transactions corresponding to multiple Payment System accounts are rolled up in a single batch file if the transmission configurations for all the accounts are same. This reduces the number of settlement batch files generated.

You can enter the Account parameters values and select the respective value for attaching the configuration under connectivity parameters. Account parameters vary depending on the selected Protocol. The current window captured for the protocol mapped to the payment system is Paymentech.

You can navigate to the Transmission Configuration window if you select the list of values for the Online Authorization, Settlement, and Status enquiry fields.

Print Payment Documents Flow

Oracle Payments integrates with Oracle XML Publisher to support printing payment documents, such as promissory notes and checks. The diagram below shows the steps performed when you print payment documents from within Oracle E-Business Suite.

Note: For payment documents that have an attached remittance, there is a fixed number of lines that the remittance can support. You can specify either of the following:

• Overflow, where any remittance lines beyond the allowed number are printed on an overflow document which is voided

• No Overflow, where payments can be split at the point where overflow would occur

Oracle Payments supports the following procedures for creating or not creating overflow documents:

• payment document setup in Oracle Cash Management

  To create overflow documents, select the Attached Remittance Stub and in the Number of Setup Documents field, enter a value for the limit of supported documents on the attached remittance.

• maximum documents per payment in Oracle Payments

  If you do not want to create overflow documents, specify a value for the maximum number of supported lines on the remittance in the Maximum Documents per Payment field of the Create Payment Process Profile page.

Print Payment Documents Flow

The table below describes the steps performed in the Print Payment Documents Flow (F13).

Print Payment Documents Flow

Action	Description
Load Payment Documents in Printer	Load the payment documents into a printer. Payment documents can be prenumbered or they can be blank, that is, security paper on which the payments and numbers are printed during this flow. Through the payment process profile, Oracle Payments can be instructed to print payment instructions automatically (with the assumption that payment documents are already loaded) or to stop the process and wait for you to initiate printing through the Funds Disbursement Dashboard.
Print Documents per Format Output	Print payment documents from the output that Oracle XML Publisher stores in the Extract and Format Operation Flow.
Verify all Payment Documents Printed Correctly	Review payment documents to ensure that they printed correctly. This step also includes handling printer jams with the subsequent stopping of the printing process.
Printing Problems?	(No) If the process is complete, then proceed to the Record Check Print Status Flow (F14). (Yes) If printing problems develop and not all checks print correctly, then reprint checks.
Reprint Payment Documents Component (C13)	The Reprint Payment Documents Component (C13) is a user interface that enables recovery from payment document printing errors by allowing you to specify those payment documents that need to be reprinted. You can indicate specific payments or ranges of payments to reprint.
Print Documents per Instructions from Oracle Payments	Oracle Payments passes information to Oracle XML Publisher to reprint payment documents.

Oracle Payments can be set up to print documents within the Oracle E-Business Suite or to output the payment instruction as a file to be printed outside the suite. If Oracle Payments is set up to print within the Oracle E-Business Suite, it can be further set up to print instructions immediately or to defer them until you initiate printing. In addition, if the Create Payment Instructions program creates multiple printed payment instructions, there are special considerations involved in printing them all. These are discussed in subsequent topics.

Reprint Payment Documents Component

The information below describes the Reprint Payment Documents Component (C13), which is within the Check Print Process Flow (F13).

The Reprint Payment Documents Component (C13) is a user interface that enables you to re-print payment documents. From this interface, you can indicate specific payments or ranges of payments to reprint.

Record Print Status Flow

Once the printing process is complete, Oracle Payments supports a process for you to record the status of payment documents. This process is completed before releasing payment documents to payees. The diagram below shows the steps performed when you record the print status for payment documents. Recording the payment documents print status occurs after you have finished printing payment documents.

Record Print Status Flow

The table below describes the steps performed in the Record Print Status Flow (F14).

Record Print Status Flow

Action	Description
Determine Status of all Payment Documents	You can review all payment documents and note their print status, such as Printed, Spoiled, or Skipped.
Record Printed Status of all Payment Documents (C14)	Oracle Payments uses the Record Print Status Component (C16), a user interface, to record the results of payment document printing.
Payments Complete Notification	Once the printed status of all payment documents is recorded, Oracle Payments considers them confirmed and final. At this time, Oracle Payments notifies source products that payments are complete. Source products can update their document payable status from this event.
Positive Pay Program	Once payment documents are recorded as printed, a positive pay file can be generated if you set up this optional feature. A positive pay file is a document that the deploying company sends to its payment system to inform it of payments made to the payee by payment document.

Record Print Status Component

The information below describes the Record Print Status Component (C14), which is within the Record Check Print Status Flow (F14).

The Record Print Status Component (C14) is a user interface that enables recording of printed payment document status. This component provides you with a way to ensure that you are properly managing your payment document stock. After you have completed the payment document print process and you have all the printed, unprinted, or damaged payment documents, you can accesses this component and view the payments to record the print status before releasing the payment documents to payees.

You can record a number of statuses, depending on the setup of your payment document stock. The print statuses are as follows:

• issued: the payment document was correctly printed. The final status of the payment becomes Printed.

• spoiled: the payment document was spoiled and you do not intend to reprint it

• skipped: the payment document was skipped and the payment was printed onto a payment document with a different number

Prenumbered Payment Documents

Prenumbered payment documents are those that already have information printed on them, notably the document or check number. Some statuses are relevant for prenumbered check stock, but irrelevant for blank stock. For example, the Skipped status is relevant for prenumbered stock, because when a prenumbered payment document is skipped, Oracle Payments needs to track the new numbers of the subsequent payment documents.

Blank Stock

Blank stock has no payment document or check number printed on it beforehand. Instead, the number is printed onto the payment document at the same time as the payment details. The Skipped status is irrelevant for payments printed on blank stock because the correct number stays with the payment details.

Separate Remittance Advice Flow

Oracle Payments works with Oracle XML Publisher to support separate remittance advice creation and delivery. Separate remittance advice is a file or document for each third party payee that lists the invoices that the first party payer has paid to that payee. This is an optional feature initiated by the first party payer.

The diagram below shows the steps performed in the Separate Remittance Advice Flow (F15) to format and deliver a separate remittance advice for a payment instruction.

Separate Remittance Advice Flow

The table below describes the steps performed in the Separate Remittance Advice Flow (F15).

Separate Remittance Advice Flow

Action	Description
Read Separate Remittance Advice Setup from Payment Profile	The payment process profile provides a way for you to indicate if a separate remittance advice is required.
Separate Remittance Advice Required?	If the payment process profile indicates that no separate remittance advice is required, then this flow is complete. However, if a separate advice is required, then the flow continues.
Read Delivery Method	The payment profile also contains the remittance delivery method. The delivery method specifies how the formatted data is to be delivered to the payee. Delivery methods supported by Oracle Payments include e-mail, print, and facsimile. Note: Delivery of the actual payment file happens outside Oracle XML Publisher and is managed as a completely separate process.
Read Delivery Address from TCA	Once the delivery method is determined, then the delivery address (e-mail address, fax number, or mailing address, as appropriate) is read from the TCA (Trading Community Architecture) model.
Pass Extract XML Message to Oracle XML Publisher	The extract XML message is sent to Oracle XML Publisher for formatting of the remittance advice. This is the same extract sent for the formatting of payments within the payment instruction, except now it includes the information about delivery method and address.
Apply Format Template	Oracle XML Publisher uses templates to format an XML message. Oracle Payments tells Oracle XML Publisher which format template to apply to the message.
Format Remittance Advice, Store Output, and Deliver	Oracle XML Publisher formats the remittance advice and stores the output. It then delivers the advice to the third party payee using the specified delivery method.

Printing Payment Documents

To set up the printing payment documents process, which includes checks or promissory notes, select the Payments Setup Administrator responsibility and navigate to the Create Payment Process Profile page as follows: Oracle Payments Setup link > Click the Go to Task icon corresponding to the Payment Process Profiles link. First, from the Processing Type drop-down list, select Printed. Secondly, for the Payment File option, select one of the following radio buttons.

• Send to File

• Send to Printer

Selecting the Send to File radio button produces a formatted output file by the Create Payment Instructions Program. This file is printed outside of the Oracle E-Business Suite.

Selecting the Send to Printer radio button produces checks or promissory notes printed within Oracle Payments. Add print-related setup options in the payment process profile, including the following:

• selecting whether to send the payment file to a printer immediately after formatting the payment instruction

  Note: The Create Payment Instructions Program produces Payment Instructions, which contain payments. Each payment, in turn, contains one or more documents payable. Each payment instruction is a payment file that contain payment instructions for the payment system or financial institution on how to pay the payee. Additionally, each payment instruction/payment file, is formatted according to the financial institution's unique payment criteria.

• selecting a default printer

• selecting a default payment document

The preceding options default settings to parameters in the Create Payment Instructions Program.

If you choose not to print payment instructions immediately, thereby deferring the printing process, you must submit the payment file for printing manually. This manual submission is done in the Print Payment Documents page. The navigation is as follows: Funds Disbursement Dashboard > Payment Instructions tab.

Printing Payment Instructions within the E-Business Suite

The table below describes three printing scenarios with their corresponding setup settings, printing statuses, printing results, and the actions you can take when you print payment instructions within the E-Business Suite.

Printing Payment Instructions within E-Business Suite

Scenario	Payment Process Profile Setting: Payment File	Payment Process Profile Setting: Automatically Print after Formatting	Payment Instruction Status	Printing Result	Possible User Intervention
User-Deferred Printing of a Single Formatted Payment Instruction	Send to Printer	No	Formatted - ready for Printing This status indicates that the payment instruction was successfully created and formatted and is now ready to be printed.	A single payment instruction that is formatted and ready to be printed from Oracle Payments' Print Payment Documents page. Nothing, however, is sent for printing. The Automatically Print after Formatting Option (No value) in the Create Payment Process Profile page defaults to the Print Now field in the Schedule Request: Parameters page of the Create Payment Instructions program.	To initiate printing, click the Take Action icon in the Funds Disbursement Process Home page to open the Print Payment Documents page. You can change the No value to Yes in the Print Now field in the Schedule Request: Parameters page of the Create Payment Instructions program.
Immediate Printing of a Single Formatted Payment Instruction	Send to Printer	Yes	Submitted for Printing This status indicates that the payment instruction has been sent to the printer and is waiting for you to reprint payments or record print status.	The payment instruction prints automatically after it is formatted. The Automatically Print after Formatting Option (Yes value) in the Create Payment Process Profile page defaults to the Print Now field in the Schedule Request: Parameters page of the Create Payment Instructions program.	You can change the Yes value to No in the Print Now field in the Schedule Request: Parameters page of the Create Payment Instructions program.
System-Deferred Formatting and Printing of Multiple Payment Instructions Created from a Single Submission of the Create Payment Instructions program	Send to Printer	Either	Created - Ready for Formatting. This status, which is applied to all except the first payment instruction, indicates that the payment instruction was successfully created and is ready to be formatted and printed.	Initially, only the first payment instruction is formatted and sent for printing (either automatically or by your intervention if it is user-deferred). This is because the payment document that the payment instructions are to be printed on is locked until you have recorded the print status of the first payment instruction from the Funds Disbursement Process Home page. Once you have recorded the status of the first formatted payment instruction for printing, you must then initiate formatting and printing of the second payment instruction. This process continues until all payment instructions have been formatted and printed.	To format and print the second payment instruction onward, click the Take Action icon in the Funds Disbursement Process Home page to open the Print Payment Documents page. When you click the Format and Print button, the payment documents are locked, the payments are numbered, formatted, and submitted for printing.

Printing Payment Instructions Outside the E-Business Suite

The table below describes two printing scenarios with their corresponding setup settings, printing statuses, printing results, and the actions you can take when you print payment instructions outside the E-Business Suite.

Printing Payment Instructions Outside E-Business Suite

Scenario	Payment Process Profile Setting: Payment File	Payment Instruction Status	Printing Result	Possible User Intervention
Printing a Single Formatted Payment Instruction Outside Oracle	Send to File	Formatted The Formatted status pushes the payment instruction into the Pending Actions region of the Funds Disbursement Process Home page.	The system produces a single payment instruction from a single run of the Create Payment Instructions program. Oracle Payments locks the payment document and formats the payment instruction, but does not send it to printing.	To record the print status of the documents, click the Take Action icon to open the Record Print Status page. Important: Even if you print outside Oracle, you must record the print status of the documents.
Printing Multiple Payment Instructions Outside Oracle	Send to File	Created - Ready for Formatting	One or more payment instructions are created, but not formatted. Initially, only the first payment instruction is formatted. This is because the payment document that the payment instructions are to be printed on is locked until you have recorded the print status of the first payment instruction from the Funds Disbursement Process Home page. Once you have recorded the status, you must then initiate formatting the second payment instruction. This process continues until all payment instructions have been formatted.	To format the second payment instruction onward, click the Take Action icon to open the Print Payment Documents page.

Making Single Payments

In general, a standard batch Payment Process Request contains multiple documents payable to be paid. These documents are processed in batch mode, where they are first built into one or more payments and then the payments are built into one or more payment instructions for final disbursement. The single payment feature allows the Oracle Payables user to make a single payment that is processed immediately, without involving other payments, payment process requests, or payment instructions.

Single Payment Flow - Part 1

To submit a single payment to Oracle Payables, a user must create a Quick Payment in Oracle Payables. For more information on quick payments, see Paying Invoices with Quick Payments, Oracle Payables. When the Oracle Payables user commits the quick payment, Oracle Payables submits a single payment request to Oracle Payments.

Note: Before Oracle Payables calls the Single Payment API, it performs any calculations to determine the actual payment amount to be sent to the API. In the standard batch payment process, Oracle Payments uses a hook to call Oracle Payables to perform certain calculations, like withholding or bank charges.

The diagram below shows the steps performed in Part 1 between Oracle Payables and Oracle Payments when Oracle Payables creates a quick payment.

Single Payment Flow - Part 1

The table below describes the steps performed in Part 1 between Oracle Payables and Oracle Payments when Oracle Payables creates a quick payment.

Single Payment Flow - Part 1

Action	Description
Store Data Sent in API in Standard Tables with Special Status	When Oracle Payments' Single Payment API is called, Oracle Payments creates a Payment Process Request for the single payment. Oracle Payments stores all the data sent in the Single Payment API in its standard payments and documents tables. The process type of Immediate is given to the payment and the documents. This process type prevents the payment and documents from being influenced by any other Oracle Payments' process. Note: In the standard batch payment process, Oracle Payables creates the Payment Process Request and passes it to Oracle Payments. Only documents payable are passed in the request. In the single payment process, the Oracle Payables user creates the payment and passes it to Oracle Payments for processing.
Perform all Required Validation Processing on Documents and the Payment	Oracle Payments performs all the following validations. Oracle Payables does not commit a record unless Oracle Payments verifies that the payment and included invoices can be processed successfully. Apply Special Single Payment Validations--There are certain validations that must be performed only in the case of a single payment. These validations are usually handled by Oracle Payables, but Oracle Payments applies them to be sure that all data is valid. Apply Payment Method-Based Document Validations--These validations are performed on each document sent in the Single Payment API, based on the payment method of the document. Apply Payment Format-Based Document Validations--These validations are performed on each document sent in the Single Payment API, based on the payment process profile assigned to the payment. Apply Payment Validations--These are the validations that the Build Payments program applies once it creates payments. In this case, the payment is already created, but the validations need to be applied.
Capture any Validation Errors	If any validation errors were found in the previous step, they are captured by the Single Payment API. The errors are linked to the entity that caused the error, whether it is a document or a payment. Note: In the standard batch payment process, only documents that have errors are marked as failed validation. With single payments, if any document has an error, all documents in the payment are marked as having failed.
Decision: Validation Errors Exist?	Oracle Payments determines if any validation errors were found at either the document or payment levels.
No: Proceed to Part 2	If no validation errors exist, Oracle Payments proceeds to Part 2 of the single payment flow.
Yes: Return all Errors and Delete Data from Oracle Payments Tables	If any validation errors exist, Oracle Payments returns all the errors in the response of the Single Payments API. Then the data that was input into the Oracle Payments tables is deleted. Note: If there are validation failures at any point, everything is failed and rejected. There is no support in the Oracle Payments user interface for any review or error correction.
Perform Error-Handling	Oracle Payables displays the errors and error messages that are returned from Oracle Payments.
Do not Commit Record	If an error is returned by Oracle Payments, Oracle Payables does not commit the payment record to any of its tables. Oracle Payables ultimately unlocks the selected invoices so they are available for selection in a new single payment or Payment Process Request.

Single Payment Flow - Part 2

The diagram below shows the steps performed in Part 2 between Oracle Payables and Oracle Payments when Oracle Payables creates a quick payment.

Single Payment Flow - Part 2

The table below describes the steps performed in Part 2 between Oracle Payables and Oracle Payments when Oracle Payables creates a quick payment.

Single Payment Flow - Part 2

Action	Description
Create Payment Instruction with Special Process Type	When no validation errors occur at the payment level, Oracle Payments creates a payment instruction for the single payment. The instruction is created with a process type of Immediate. This process type prevents the instruction from being influenced by other process in Oracle Payments.
Apply Payment Instruction Validations	Once the payment instruction is created, any instruction-level validations linked to the payment method or format of the instruction are applied.
Capture any Validation Errors	If any validation errors were found for the payment instruction, they are returned in the response of the Single Payment API.
Decision: Validation Errors Exist?	Oracle Payments determines if any validation errors were found at the instruction level.
Yes: Return all Errors and Delete Data from Oracle Payments tables	If validation errors exist, Oracle Payments returns the errors in the response of the Single Payment API. Then the data that was input into the Oracle Payments tables is deleted.
Perform Error-handling	Oracle Payables displays the errors and error messages that are returned by Oracle Payments.
Do not Commit Record	If an error is returned by Oracle Payments, Oracle Payables does not commit the payment record to any of its tables. Oracle Payables ultimately unlocks the selected invoices so they are available for selection in a new single payment or payment process request. This ends the process in this case. If no errors are found, the process proceeds to the next step.
Decision: Printed or Electronic Payment Instruction?	Oracle Payments takes different paths, depending on whether the payment instruction has a processing type of Printed or Electronic.
Electronic: Perform Extract and Format Operation	If the payment instruction processing type is Electronic, then the standard extract and format operation is performed.
Update all Oracle Payments Data and Mark Payment Complete	Once the single payment process completes successfully, all the data in Oracle Payments is updated to the appropriate status, based on whether the transmission is to be performed immediately or deferred. For example, the payment instruction status is updated to Formatted, or a later status, depending on transmission setup. Generally, Oracle Payables directs Oracle Payments to mark single payments as complete immediately. In those cases, Oracle Payments marks the payment complete. Otherwise, Oracle Payments marks payments complete according to the setup in the payment process profile.
Send Success Message	Once the format step completes, Oracle Payments returns a success message to Oracle Payables through the response to the Single Payment API. Oracle Payments proceeds to the Electronic Subflow process, shown below.
Commit Record in Oracle Payables	When Oracle Payables receives a success result from Oracle Payments, it commits the record.
Decision: Print Payment Instruction Immediately Option = Yes?	If the payment instruction processing type is Printed, then Oracle Payments examines the parameters selected by the Oracle Payables user at the time of payment submission to decide whether to print immediately or defer printing.
No: Perform Extract and Format Operation	If the Print Payment Instruction Immediately option is set to No, then the process proceeds in a manner similar to that for a batch payment process. The standard extract and format operation is now performed.
Update all Oracle Payments Data	In the case of deferred printing, the single payment instruction ends with a status of Formatted - Ready for Printing and it appears in the Funds Disbursement Dashboard as a batch payment instruction would appear. You must then initiate printing. Once the single payment process completes successfully, all the data in Oracle Payments is updated to the appropriate status, based on the setup in the payment process profile regarding printing. In this case, the payment instruction status is updated to Formatted - Ready for Printing. Generally, Oracle Payables directs Oracle Payments to mark single payments as complete immediately. In those cases, Oracle Payments marks the payment complete. Otherwise, Oracle Payments marks payments complete after you complete printing through the Funds Disbursement Dashboard.
Send Success Message	Once the format step completes, Oracle Payments returns a success message to Oracle Payables through the response to the Single Payment API.
Commit Record in Oracle Payables	When Oracle Payables receives a success result from Oracle Payments, it commits the record.
Yes: Perform Extract and Format Operation	If the Print Payment Instruction Immediately option is set to Yes, then the process has more steps that need to be performed. The first is to run the standard extract and format operation.
Perform Payment Document Numbering	Next, Oracle Payments performs payment document numbering. This numbering, which is the same as in the batch process, combines setup and overflow documents with actual payments to calculate the number of documents payable needed for printing. Note that the payment document is already locked for use as part of the payment validations process.
Update all Oracle Payments Data	The data in Oracle Payments is updated to the appropriate status, based on the setup in the payment process profile regarding printing. For example, the payment instruction status is updated to Printed. Additionally, Oracle Payments marks the payment as complete.
Send Success Message: Include Number of Payment Documents Needed for Printing	The Single Payment API returns a success message to Oracle Payables. In the case of immediate printing, the API also returns the number of payment documents needed for printing. This message helps the Oracle Payables user understand why the paper document number that he or she entered at the time of single payment submission was changed at the time of the payment's completion. The Single Payment API also returns the actual paper document number used on the payment. Oracle Payables or any other source product must use that number if they store the payment in their own tables.
Display Number of Payment Documents Needed for Printing Message	Oracle Payables displays a message that informs the Oracle Payables user of the number of documents needed for printing. If you do not have an adequate number of payment documents loaded in the printer, you can load more before printing starts.
Commit Record in Oracle Payables Table	When Oracle Payables receives a success result from Oracle Payments, it commits the record.
Send Print Command to Oracle XML Publisher	After Oracle Payments sends Oracle Payables the success message, it sends a print command to Oracle XML Publisher to print the formatted payment.

Electronic Subflow

The diagram below shows the steps performed in the Electronic Subflow for an electronic single payment.

Electronic Subflow

The table below describes the steps performed in the Electronic Subflow for an electronic single payment.

Electronic Subflow

Action	Description
Decision: Instruction Set Up for Immediate File Transmission?	Oracle Payments checks whether the profile on the instruction is set up to transmit the payment instruction to a payment system and whether the parameters provided by the Oracle Payables user at the time of single payment submission, direct Oracle Payments to transmit the instruction immediately.
Yes: Perform Transmission Operation Immediately	When transmission is set up, Oracle Payments performs the transmission operation immediately, as in the Funds Disbursement Transmission Process Flow (F12).
No: End Special Handling of Single Payment	If transmission is not enabled, then no action is needed and this ends the special handling needed for a single payment. In this case, transmission is handled as specified in Funds Disbursement Transmission Process Flow (F12). If the payment process profile is set up to output the payment instruction to a file, it does so. If transmission is deferred, you must initiate transmission through the Funds Disbursement Dashboard.

Oracle Payables Void and Reissue Flow

The diagram below shows the steps performed between Oracle Payables and Oracle Payments when the Oracle Payables user chooses to reissue a single payment.

Payables Void and Reissue Flow

The table below describes the steps performed in the Oracle Payables Void and Reissue Flow for reissuing a single payment.

Oracle Payables Void and Reissue Flow

Action	Description
Open Payments Window and Query Payment to Reprint	The reprint process is initiated by querying the payment to reprint.
Open Actions Window and Select Reissue Option	Once the Oracle Payables user has queried the payment to reprint, he or she can follow the Oracle Payables procedure to reissue the payment and specify the paper document number. There may be restrictions on the user's ability to reissue the payment. For more information on reissuing a single payment in Oracle Payables or on the related limitations, see Creating Single Payments, Oracle Payables.
Call Paper Document Number Validation API	If the Oracle Payables user changes the paper document number, Oracle Payables directs Oracle Payments to execute the Paper Document Number Validation API and returns results to Oracle Payables. This happens as many times as the user changes the paper document number.
Default Printer Value from Payment Process Profile Setting	When the Oracle Payables user chooses to print, Oracle Payables defaults the value for the Printer field from the payment process profile of the existing payment.
Choose OK/Commit Action	The Oracle Payables user reviews the data he or she has entered and commits the payment.
Void Existing Payment and Call Void Payment API.	Oracle Payables voids the existing payment and notifies Oracle Payments of the voided payment by calling the Void Payment API.
Void Payment	When Oracle Payments receives notification of the voided payment from Oracle Payables, it voids the payment in its data model.
Call Single Payment API	Once Oracle Payables has voided the original payment, it calls Oracle Payments' Single Payment API. This is the same API used for issuing the first payment.

Record Manual Payment Flow

In some cases, the user of a source product may manually issue a payment. For example, a Payables clerk may write a check and hand it to a payee. In that case, the payment must be recorded and accounted for. The source product invokes Oracle Payments to record the manual payment. No processing, transmission, or printing is performed for the payment. Manual payments can be viewed in the Oracle Payments Funds Disbursement Dashboard.