Payment Process Request
Posted on May 12, 2020
The Payment Batch entry form used in R11i has been replaced in R12 by a
new module called the Payments Manager module (IBY).
Payment Process Request or “PPR” is a payment batch.
PPR process has the following four steps:
1. AUTOSELECT / DOCUMENT SELECTION (Code –
AP_AUTOSELECT_PKG):
The Selection process is handled by Payables (AP).
When a PPR is submitted, a record is created in
AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name, which is the
same as the PPR Name.
Selection:
Invoices are then selected based on Due Date, Discount Date, Pay Group,
and other criteria provided by the user while completing the PPR header.
The table AP_SELECTED_INVOICES_ALL is populated with selected
invoices.
The table AP_UNSELECTED_INVOICES_ALL is populated with the invoices
that were not selected.
Locking:
After selecting the documents, the invoices are locked to prevent other check
runs from selecting the same invoices.
AP_PAYMENT_SCHEDULES_ALL.checkrun_id is populated on the selected
documents (invoices).
Review:
If the PPR has been setup to Stop Process for Review After Schedule
Payment Selection (option available on the header of the PPR), the process
stops for user review after the initial selection of payables documents has
been completed. The status of the PPR is set to “Invoices Pending Review”.
After the user reviews and/or modifies the selected documents, and clicks on
the Submit button, AP calls the IBYBUILD program.
If the Stop Process for Review After Schedule Payment Selection parameter
was not enabled, then at the end of invoice selection, the Build program is
submitted automatically.
If no invoices met the selection criteria, the PPR is canceled automatically and
the status of the PPR is set to “Canceled – No Invoices Selected”.
2. BUILD PAYMENTS (Code: IBY_DISBURSE_SUBMIT_PUB_PKG):
The Build Payments process is handled by Oracle Payments (IBY).
The Build Payments program first creates a record in
IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code =
checkrun_name.
The Build Payments program goes on to populate the
IBY_DOCS_PAYABLE_ALL table with the proposed payments.
The link to the payment service request table is through the
PAYMENT_SERVICE_REQUEST_ID.
Internal Bank Account / Payment Process Profile Assignment (Code:
IBY_ASSIGN_PUB):
If the PPR has a default internal bank account and Payment Process Profile
(PPP) assigned to it on the header of the PPR, the values are assigned to all
of the selected documents in the PPR.
If a default internal bank account and PPP were not provided by the user on
the header of the PPR, Oracle Payments attempts to default the values.
If it cannot find a default value for all of the selected documents, the PPR
status is set to “INFORMATION REQUIRED”. The user display shows it as
“Information Required – Pending Action”. The user will need to use the
Information Required window to provide the missing internal bank account(s)
and PPP(s) for each selected document.
Document Validation (Code: IBY_VALIDATIONSETS_PUB):
During this step, Oracle Payments validates all the documents (selected
invoices & memos) using Pre-Defined and User-Defined Validations assigned
to Payment Methods assigned to the selected documents.
Afterward, the program validates all the documents again, using the Pre-
Defined and User-Defined Validations assigned to Payment
Formats associated with the PPPs specified on the PPR.
If all the documents pass validation, all the documents are set to a status of
VALIDATED in the tables and the request status is displayed as “Documents
Validated”.
If there any document validation failures, Oracle Payments uses the
parameter setting for “Documents” on the Validation Failure Results tab on the
PPR header (the DOCUMENT_REJECTION_LEVEL_CODE) to determine
the next action.
REQUEST : Reject all documents in this PPR
DOCUMENT : Reject only the document in error
PAYEE : Reject all the documents related to the supplier
NONE : Stop the PPR for review
Create Payments (Code: IBY_PAYGROUP_PUB):
The validated documents are then grouped into “proposed” payments based
on the grouping rules – both User-Defined and hard-coded. It then numbers
the proposed payments with an internal identifier (not “the” check number)
and validates the payments.
Records are inserted into IBY_PAYMENTS_ALL that holds the payment
information for the selected documents (invoices).
The Build Payments program then updates the IBY_DOCS_PAYABLE_ALL
table with the payment_id and formatting_payment_id values of the payment
associated with each document.
If there any payment validation failures, Oracle Payments uses the parameter
setting for “Payments” on the Validation Failure Results tab on the PPR
header (the PAYMENT_REJECTION_LEVEL_CODE) to determine the next
action.
REQUEST : Reject all documents in this PPR
DOCUMENT : Reject only the document in error
PAYEE : Reject all the documents related to the supplier
NONE : Stop the PPR for review
If the PPR setup Stop Process for Review After Creation of Proposed
Payments is enabled on the Process tab of the PPR header, the displayed
PPR status is set to “Pending Proposed Payment Review”. This status
prevents further processing until user takes action.
If this option to stop for a review is not enabled, the displayed status of the
PPR is set to “Payments Created”. In this status, payment instructions can be
created for the PPR.
3. FORMAT PAYMENTS (Codes: IBY_PAYINTSR_PUB,
IBY_CHECKNUMBER_PUB):
The Format Payments process is handled by Oracle Payments (IBY).
When a PPR is submitted, the program checks the setting for the Create
Payment Instructions parameter on the Process tab of the PPR header to
determine if the associated payment instruction(s) (PI) should be created
automatically after the payments are created (the
CREATE_PMT_INSTRUCTIONS_FLAG = Y), or if the program is to wait for a
manual kick-off of the Format Payment Instructions program through the
Standard Request Submission form (SRS) (the
CREATE_PMT_INSTRUCTIONS_FLAG = N).
If the PPR is set up to automatically submit instruction(s), the
payment_service_request_id will be populated in
IBY_PAYMENT_INSTRUCTIONS_ALL because the instruction will be specific
to the PPR. In this case, the instruction(s) can be linked to the PPR using
PAYMENT_SERVICE_REQUEST_ID.
If the PPR is set up for the user to submit the instruction program manually on
the SRS form, then when the instruction(s) is submitted, the instruction(s) is
linked to the PPR through the payments selected by the instruction(s). The
link in this case will be through the payment_instruction_id in
IBY_PAYMENTS_ALL.
In addition, the following processing occurs during the Format Payments step
– Sort and number the payments (paper checks and possibly, electronic
payments)
– Create XML extracted message
– Pass the extract to Oracle XML Publisher (also known as “BI Publisher”)
– XML Publisher applies the formatted template to the payments
– XML Publisher formats and stores the output
– Oracle Payments then updates the status of the Payment Instruction(s)
and the PPR. If successful, the displayed status of the PPR is “Formatted”,
and the status of the Payment Instruction(s) will be “Formatted” for electronic
payments and “Formatted – Ready for Printing” for check payments
– Print checks (Users can load stationery into the printer and print checks at
this stage by clicking on the Take Action icon for the related Payment
Instruction on the Search PPRs window)
– Transmit electronic payments:
4. CONFIRM PAYMENTS (Code: AP_PMT_CALLOUT_PKG):
The Selection process is handled by Payables (AP).
Oracle Payments calls AP_PMT_CALLOUT_PKG.PAYMENT_COMPLETED
to confirm the payments. During this step, the program does the following:
– Assigns sequence values for Document Sequencing (Vouchering).
– Creates data in the AP_CHECKS_ALL table with the appropriate data from
the IBY tables.
– Inserts data into the AP_INVOICE_PAYMENTS_ALL table for the
corresponding checks.
– The documents (invoices) are updated in the
AP_PAYMENT_SCHEDULES_ALL table to indicate in the Invoices
Workbench the payment details and status.
– The documents not paid in this PPR are released by setting the
checkrun_id on the Payment Schedules to NULL.
– The AP_INVOICES_ALL table is updated to show the payment status in
the Invoices Workbench for those documents that were paid by the PPR.
– Data for this PPR is deleted from the AP_SELECTED_INVOICES_ALL
table.
– Data for this PPR is deleted from the AP_UNSELECTED_INVOICES_ALL
table.
“Completing” Electronic Payments:
Electronic payments are not “confirmed” in the same way that paper
documents are handled. The system will automatically mark electronic
payments as “completed” based on the setting you chose for the “Completion
Point” field on the header of the associated Payment Process Profile (PPP):
– “Built” = the payments will be marked as “complete” when the Build
process completes
– “Payment Instruction is Created” = the payments will be marked as
“complete” when the PI is created
– “Payment Instruction is Formatted” = the payments will be marked as
“complete” when the PI has successfully completed the Formatting process
– “Payment Instruction is Transmitted” = the payments will be marked as
“complete” when they are transmitted”