The payment method indicates the medium by which a first party payer makes a payment

to a third party payee. Payment methods also include other information used during the
early stages of payment processing, such as validations and rules that determine how
payment methods can be assigned to documents payable. Custom validation can be
attached to payment method.

In each payment process profile, a usage rule setup is done. Usage rules for payment
process profiles can be based on payment method, payment currency, first party
organization, or internal bank account. If usage rule defined is satisfied, then that PPP is
used. By default, all the conditions in usage rule of PPP are set to All.

Payments are built from documents payable that have the same payment process profile,
among other attributes. Payment instructions are built from payments that have the same
payment process profile, among other attributes.

A document payable is a transaction in a source product that is sent to Oracle Payments for
payment. An example of a document payable in Oracle Payables is an invoice. During the
payment process, documents payable are grouped together into actual payments.

A payment is a single transfer of funds from one person or organization to another via
printed payment document or electronic transmission. A payment can contain multiple
document payables and a payment instruction can contain multiple payments. Which all
document payables are grouped into a single payment are determined by grouping rule.

A payment instruction contains one or more payments, along with aggregate payment
information, and is created by running the Create Payment Instructions program.
Depending on your setup, a payment instruction can be converted into a payment file to be
printed onto payment documents, such as checks, or into a payment file that is transmitted
to a payment system or financial institution for further processing and disbursement.

When the Payment Instruction amount exceeds the maximum amount mentioned in the
Payment Process Profile setup, multiple payment instructions are created and the payments
does not stop.

The payment instructions are generated based on payment instruction creation rules.
Different payment instructions are created when payments have different values for a
grouping parameter.

The logical reference ID should be unique and it should not repeat in same payment
instruction nor in another payment instruction, even with a different payment reference
number and amount.

A payment process request(PPR) is a request created by a source product like AP for Oracle
Payments payment services. The PPR, which originates in the source product during the
documents payable selection process, contains one or more documents payable to be paid,
along with information that allows Oracle Payments and the source product to identify the
request and optional payment processing instructions. The source product may submit
payment process requests to Oracle Payments via user action or concurrent program.

During the PPR process, once document payable selection is done based on criteria specified
in the PPR, control passes to IBY. At this point input to IBY is selected Invoices/CMs and
processing options. Build payments program, payment instruction creation, formatting is
done by IBY.

The Payment Process starts when a source product, such as Payables, needs to pay
documents payable, such as invoices. The source product user groups the documents
payable into a payment process request and submits the request to Oracle Payments.
Within Oracle Payments, the Build Payments program takes the submitted documents
payable, validates them, groups them into payments, and then validates the payments.
Each payment consists of one or more documents payable. So the output of the build
payment is individual Payment documents. Each payment represents a check that will be
printed or a single electronic funds transfer transaction, depending on the type of
processing selected.

Next, the Create Payment Instructions program groups the payments into payment
instructions, and then validates the payment instructions. Each payment instruction results
in one payment file that contains pertinent information on one or more payments, such as
payment amount and an account to be credited or debited. In the case of electronic
payments, the payment file includes the payment instructions in a format required by the
financial institution. To actually make payments, you print checks or electronically transmit
the payment instruction to an external payment system or to a financial institution.

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. So when payment method is EFT, it
basically means that an electronic file would be generated and sent to bank, bank may
directly deposit money or cut checks to suppliers. When payment method is check, it means
it would be printed in-house. In check method also, PPP can be setup to create a file which
can be used to print check outside of oracle.

During submission of PPR, it’s not necessary to specify Internal bank accounts and payment
profiles. There is an internal flow in IBY which derives this if not specified. 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 i.e a
screen in PPR processing stage.

Payment Instruction Creation: 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.

Validation Failure Handling : Custom and/or standard validation sets can be assigned to
payment formats. These payment formats are assigned to PPPs. 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): After payment instructions are created, those are to be
extracted and formatted. In extraction step various information related to instructions are
extracted. There is a standard oracle extraction template which does it. I don’t think any
custom extraction can be used, however using a custom hook, the output of seeded
extraction template can be extended. This process will be noted later.

Once a payment instruction is created, it moves to the format process. The flow splits
depending on whether or not the format is electronic. 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.

For check format type, Print Payment Document Process is used. This process is used to
print payment documents in-house. This step is conditional and depends on the payment
process profile setup. 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 not used for Electronic Payments.

Record Print Status: This is only for printed processing type. 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.

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. 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.

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

After control passes to IBY, in the build process, Account/Profile Assignment Flow IBY
verifies if all the document payables have PPP and Internal bank account assigned. All the
documents will already have PPP and internal bank account assigned if the PPR/PPT has
these parameters. If PPR doesn’t have these parameters as these are not mandatory, then
IBY tries to default those. If defaulting is not possible, 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.

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 Complete Document Assignments Page Component provides a user interface for you to
manually assign required information to documents payable as needed i.e adding PPP, bank
account etc. The information that must be assigned is an internal bank account and/or a
payment process profile.

After assignment flow of PPP/Bank account , it goes to document validation flow. Here 2
types of validations are possible, validation attached to payment method of document or
validation attached to payment format attached to PPP. During this validation first it figures
out whats the validation failure level.

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.

Once validation of documents are done which results in validated document payables,
payment creation flow starts. First based on setup in PPP, it may wait for user to approve all
the documents payable. Then based on hard coded or system defined payment grouping
rule & user defined payment grouping rule, payments are created. At this stage a special
amount calculation hook is used which calculates if any amount alteration is to be done. For
example AP provides a hook for withholding and interest calculation. Thereafter once
amount of the payment is finalized, validation of payment takes place which is nothing but a
payment amount validation. If payment fails amount validation, based on rejection level
action is taken. 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.

At this stage the payments are proposed payments only. After proposed payments
validation, it goes to review of proposed payments if no payments failed validation.If any
payment failed validation it goes to review errors page. 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.

Once action in modify payment creation page is done, based on action it goes for
revalidation or payment is created. Then it goes to payment instruction creation flow.Create
payment instruction program is a concurrent program which can be scheduled or can be set
up in PPT to start as soon as payments are created. 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.
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.

The proposed payment instructions are subjected to validations which can be system
defined and or user defined. If there is any validation failure then it goes to Resolve
Payment Instruction Validation Errors Page. The Resolve Payment Instruction Validation
Errors Page Component supports the following actions:

 Action 1: Remove payments

 Action 2: Override errors

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 part extracts the data from db into a xml message. A format template is then
applied on this message to get the actual formatted output.

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.

Extraction is done by a seeded extraction template which I think cant be replaced. But there
are extension hooks available which will add to extracted xml message. 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.

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

Once extract and format operations are done, based on the payment format i.e printed or
EFT action is taken. If its EFT, then if its intended to be directly transmitted, then security
operation is done for encryption and then transmission is done. After which PPR is marked
complete. 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.

If its printed payment, then printing is done if its inhouse printing, written to file if its to be
printed outside. Then recording of print status is done after which PPR is marked confirmed.

For doing automatic transmission, transmission config, payment system account needs to
be setup.

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.
Irrespective of print is done inside Oracle or Outside, record print status has to be done.
After recording of print status , PPR is set to complete for printed types.

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

For printing, papr stock type can be 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.

Payment completion point for printed processing type is implicitly Manual and not visible in
front end, only visible for Electronic type. For printed type, once print recording is done it
completes.

Different completion point, based on the processing type of PPP

Specifying the Electronic Processing Type

If you select Electronic from the Processing Type drop-down box in the Create Payment
Process Profile page, the following fields display in the header that are pertinent to
electronic payment processing:

 Payment Completion Point drop-down box. This option indicates when a payment is
marked complete. Payments can automatically be marked complete anytime from
the time the payment instruction is formatted in Oracle Payments to when the
payment is transmitted to the payment system.
  Allow Manual Setting of Payment Completion check box. This setting enables
payment administrators to mark payments complete manually in the Payment
Processes region of the Funds Disbursement Process Home page.

To mark payments complete manually, the Payment Administrator navigates to the Mark
Payments Complete page from the Funds Disbursement Process Home page by first
selecting the Electronic Payment Instructions Not Marked Complete View under the Payment
Processes region, clicking the Go button, and then clicking the Mark Payments Complete
icon for an electronic payment instruction with a status of Formatted, Formatted - Ready for
Transmission, Transmitted, or Transmission Failed. This view only shows payment
instructions whose payment process profiles have the Allow Manual Setting of Payment
Completion check box selected. Once the payments in a payment instruction have been
marked complete by clicking the Apply button in the Mark Payments Complete page, the
source product is notified that the payments are complete. Simultaneously, the payment
instruction can no longer be terminated. Instead, if there are any problems with the
payments, they must be voided. The Terminate Payment Process action, therefore, does not
appear on any page that displays in the context of a payment instruction whose payments
have been marked complete.

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

 Automatically Transmit Payment File after Formatting check box. If selected, the
payment file is automatically transmitted to the payment system or bank after it is
formatted. If it is not checked, a payment administrator will have to initiate
transmission from the Funds Disbursement Dashboard.

Specifying the Printed Processing Type

If you select Printed from the Processing Type drop-down box, the following fields display in
the header that are pertinent to printed payment processing:

 Default Payment Document list of values

The list of values displayed for the Default Payment Document field are based on the
value selected from the Payment Instruction Format list of values. If you do not
make a selection from the Payment Instruction Format list of values, the list of
values in the Default Payment Document field is blank.

 Send to File radio button

 Send to Printer radio button
 Automatically Print after Formatting check box

If selected, the Default Printer field is populated with the default printer assigned in
Oracle Applications. You can change this value if you wish, but you must select a
default printer from the Default Printer list of values.
Separate remittance advice: 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.

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.

Payment Instruction Statuses:

Formatted - Ready for Transmission

Enables the Payment Administrator to initiate payment instruction transmission. Only used
for those payment instructions that are not transmitted to the payment system
automatically, based on Oracle Payments settings.

Formatted - Ready for Printing

Enables the Payment Administrator to initiate payment document printing within Oracle
Payments. Only used for those payment instructions that are not submitted for printing
automatically, based on Oracle Payments settings.

Created - Ready for Printing

Always used for payment instructions for which formatting and printing are deferred due to
another payment instruction locking the payment document needed to print the payments.
This is the case when one PPR produces multiple payment instructions and for the first
payment instruction, status has not been recorded, thus the payment document is locked.

Created - Ready for Formatting

Enables the Payment Administrator to initiate payment document printing outside Oracle
Payments, that is, initiate printing to file. Always used for payment instructions for which
formatting and printing are deferred due to another payment instruction locking the
payment document needed to print the payments.

Formatted - Ready for Recording

Enables the Payment Administrator to record the status of printed payment documents. This
action also marks payments complete. Recording print status is a required action for printed
payment instructions. This method of recording is always available for payment instructions
printed outside Oracle Payments, that is, printed to file.

Single Payment or Quick payment

In quick payment all the processing is similar to PPR but only for a single document
payable. When the Oracle Payables user commits the quick payment, Oracle Payables
submits a single payment request to Oracle Payments. 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.

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.
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

For a quick payment, 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. 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. 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.

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

Resolving Document Validation Errors

Once all documents payable have been assigned all required attributes, the Build Payments
program validates them, based on applicable validations assigned in Oracle Payments setup.
When submitting the payment process request, the source product specifies whether
documents that fail this document validation are rejected or whether the Build Payments
program simply stops the payment process for review by the Payment Administrator.
If review is required for failed documents, the Payment Administrator navigates to the
Resolve Document Validation Errors page to review the validation errors, dismiss individual
documents payable from the payment process, if necessary, and restart the Build Payments
process when the errors have been resolved.

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

Resolving Payment Validation Errors

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

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

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

Reviewing Proposed Payments

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

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

Resolving Payment Instruction Validation Errors

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

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

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

Payment Instruction Status of Created

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

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

 Click the Take Action icon corresponding to the applicable stopped payment
instruction. This takes you to a warning page, allowing you to proceed with the
program or cancel. If you proceed, the Format Payment Instruction program runs
automatically.
 Navigate to the Schedule Request Submission train. Enter the program (Format
Payment Instruction) that you want to run and the reference of the payment
instruction on which you want it to run.

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

Transmitting Payment Instructions

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

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

Note: This action step is the Payment Administrator’s final opportunity to terminate a
payment instruction.
Recording the Print Status of Prenumbered Payment Documents

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

 Update the print statuses by marking payment documents Printed, Spoiled, or

Skipped. The Payment Administrator can only mark prenumbered payment
documents Skipped.

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

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

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

Recording the Print Status of Non-Prenumbered Documents

When a payment document is not prenumbered, no renumbering needs to be done when

payment documents are skipped. This is because the skipped document is simply a blank
piece of paper that can be used in a new print run.

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

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

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

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

In general, electronic payments in a payment instruction are automatically marked complete

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

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

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

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

Recording Stop Payments Requests

When the Payment Administrator determines that a payment needs to be stopped, he

contacts the payer bank and requests a stop payment.

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

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

 the Record Stop Payment Request link in the Payment Actions region of the Funds
Disbursement Process Home page
  the Payments Search page

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

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

Resolving Stop Payments Requests

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

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

 Void the payment if the payment has already been marked complete.
 Remove the payment from its payment instruction if it has not already been marked
complete.

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

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

Voiding Payments

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

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

 Click the Void Payment link in the Payment Actions region of the Funds Disbursement
Process Home page
  Search for a payment on the Payments Search page and click the Void icon for the
applicable payment. The Void icon is only available for payments that have been
marked complete and that do not have stop requests placed on them.

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

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

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

Voiding all Payments

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

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

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

R12: Oracle Payments Grouping and Validations Explained (Doc ID 1384297.1)

In this Document

Purpose

Scope

Details

1. Understanding "Grouping"

1.1. Definition

1.2. "Hard-coded" grouping rules

1.3. How do you define user-defined grouping rules?

1.4. When does Grouping occur within a PPR?

1.5. Exceptions

1.6. Document Grouping examples

2. Understanding "Validations"

2.1. Definitions

2.2 How to build/assign Validations

2.3. "Validation point"

2.4. What to do in cases of Validation failure

Have more questions?

References

APPLIES TO:
Oracle Payments - Version 12.0.0 and later
Oracle Payables - Version 12.0.0 and later
Information in this document applies to any platform.

PURPOSE

To provide information concerning Oracle Payments grouping rules and validations, both of
which are performed during payment processing in R12.

For information on how to submit a new Payment Process Request (PPR), see Note
1307420.1: R12: How to Submit a New Payment Process Request (a "payment batch")

For information on how the PPR process works, or how to troubleshoot PPRs, see Note
1305001.1: R12: Master Troubleshooting Guide for Payment Process Requests (PPRs) in
Oracle Payments

SCOPE

This document is intended for functional and technical users of R12 Oracle Payments and
Oracle Payables.

DETAILS

SCROLL UP TO SEE THE TABLE OF CONTENTS

1. Understanding "Grouping"
1.1. Definition
"Grouping" is an option in R12 Oracle Payments that allows users to define rules for:

1. how to group selected "documents" (invoices and memos) into proposed

payments for a payment batch ("Payment Process Request"), and/or

1. how to group "proposed payments" into Payment Instructions.

Return to Table of Contents

1.2. "Hard-coded" grouping rules

Oracle has seeded several "hard-coded" grouping rules in the background that are not user-
configurable.
DOCUMENTS:
Following attributes used for Documents into proposed payments grouping rules:

Payment request
Organization id
Payee id
Currency
Payment process profile
Payment method
Payment date
Payment function
Internal bank account
Payee bank account
Pay alone flag
Original document id - interest invoices are grouped with related invoices
Payee address - only applicable for printed payments
Space left on stub - only applicable for printed payments
Beneficiary party - for third-party payments

PAYMENTS:
Following attributes used for proposed payments into Payment Instructions grouping rules

Payment Process Profile

Internal Bank Account - only for PPP type "printed"

Return to Table of Contents

1.3. How do you define user-defined grouping rules?

GROUPING DOCUMENTS

User-defined grouping rules for documents are selected on the Payment Creation tabbed
region on the Update/Define Payment Process Profile window.

(Payments Setup Administrator responsibility > Oracle Payments Setup menu > Codes
region> Payment Process Profiles row):

Click on the Go To Task icon to be taken to the PPP Search window (below) in order to
search for an existing Payment Process Profile, or to create a new PPP (by using
the Create button):
See the R12 Payments Implementation Guide > Step 17: Setting Up Payment Process
Profiles > sections "Creating Payment Process Profiles" and "Entering Header Information"
for information about completing the header portion of your new or existing PPP.

To enter selections for DOCUMENT (selected invoices and memos) grouping within a PPR,
open the Payment Creation tab:

GROUPING PAYMENTS

To enter user-defined grouping rules for PAYMENTS (that is -- grouping the proposed
payments into Payment Instructions), open the Payment Instruction Creation tab:

Return to Table of Contents

1.4. When does Grouping occur within a PPR?

GROUPING DOCUMENTS

When processing a payment batch in R12 (also known as a "Payment Process Request" or
"PPR"), one of the processes involved is the Create Payments process (Code:
IBY_PAYGROUP_PUB), which is administered by the Payments module (IBY).

During this process, validated documents (the selected invoices and memos for payment)
are grouped into "proposed" payments based on the defined DOCUMENT grouping rules -
both user-defined and hard-coded.

See Section 2: How does the PPR Process work? on Note 1305001.1: R12: Master
Troubleshooting Guide for Payment Process Requests (PPRs) in Oracle Payments for more
information.
Attributes available on a Payment Process Profile for user-configurable Document
grouping:

Due date
Unique remittance identifier
Bank charge bearer
Settlement priority
Remittance message
Payment reason
Delivery channel
Maximum documents per payment

GROUPING PAYMENTS

Another process involved during a PPR is the Format Payments process (Code:
IBY_PAYINSTR_PUB), which is also administered by the Payments module (IBY).

During this process, proposed payments are grouped into Payment Instructions based on
the defined PAYMENT grouping rules - both user-defined and hard-coded.

See Section 2: How does the PPR Process work? on Note 1305001.1: R12: Master
Troubleshooting Guide for Payment Process Requests (PPRs) in Oracle Payments for more
information.

Attributes available on a Payment Process Profile for user-configurable Payment

grouping:

First Party Organization

First Party Legal Entity
Internal Bank Account
Payment Currency
Payment Date
Payment Reason
Payment Function
Payment Process Request
Bills Payable
RFC Identifier

Return to Table of Contents

1.5. Exceptions
When credit or debit memos are selected in the Payment Process Request (PPR), then
document grouping is done by the Payables application (AP) instead of the Payments
module (IBY).

When a PPR contains memos, Payables will pre-group the "Documents Payable" (the
selected invoices and memos) by stamping them with a payment grouping number
(IBY_DOCS_PAYABLE_ALL.PAYMENT_GROUPING_NUMBER).

When the payments Build Payments program detects that the Documents Payable are pre-
grouped by Payables, it will ignore all the user-defined grouping rules defined in the
Payment Process Profile, and apply only the pre-defined grouping rules.

NOTE: In this context, it is important to mention the functionality of the check

box Maximize Credits on the header of the PPR.

When this check box is not enabled (left unchecked), the memos will be adjusted against
invoices only if the sum total of the selected invoices exceeds the sum total of the selected
memos.

If the sum total of the selected memos for a payee exceeds the sum total of the invoices,
then the PPR will not select any Documents Payable for that payee.

However, if this check box IS enabled (checked), the memos will be adjusted against
invoices up to a total payment amount of zero.

Return to Table of Contents

1.6. Document Grouping examples

Example 1: The following invoices are available for selection in a Payment Process Request
(PPR):

Payee Invoice Number Amount (USD) P

A A101 100

A A102 350

A A103 150

A A104 50

A A105 200
 A A106 250

A A107 400

If the associated Payment Process Profile has been set to group documents by Due Date,
the following payments will be created:

Payment 1: $450 (A101, A102) - Checks due Jan 10, 2011

Payment 2: $150 (A103) - Checks due Jan 15, 2011
Payment 3: $50 (A104) - Electronic payments due Jan 10, 2011
Payment 4: $450 (A105, A106) - Elec payments due Jan 15, 2011
Payment 5: $400 (A107) - No assigned payee bank account

Example 2: The following invoices/memo are available for selection in a Payment Process
Request (PPR):

Payee Invoice Amount (USD)

Number

A A101 100

A A102 (-) 350

A A103 150

If the Maximize Credit check box is enabled, then the payment amount will be zero ($250 of
the memo will be applied against the other two invoices, leaving a zero payment amount
and a credit balance on the memo of $100 available for future use).

If the Maximize Credit check box is not enabled, then these invoices will not be selected for
the PPR, since the available memo total is MORE than the available invoice total.

Return to Table of Contents

2. Understanding "Validations"
2.1. Definitions
Oracle Payments provides a flexible validation framework that allows the user to execute
validations at various levels during payment processing. The validations can be attached at
the payment method level or the payment format level. There are two types of validations:

o Pre-Defined validations: Payments provides a seeded library of various

"country-specific" validations that are required for country-specific
 requirements, and "standard" validations available to everyone, such as
"validate supplier bank account assignments", etc.

 User-Defined validations: Users can create validations using various seeded

attributes. For example, a user can define a validation that requires that payment
amounts should not be below $10, etc..

Return to Table of Contents

2.2 How to build/assign Validations

Assigning PRE-DEFINED (seeded) Validations:

(Payments Setup Administrator responsibility > Shared Setup region > Validations row):

Click on the Go To Task icon to be taken to the [Pre-Defined] Validations search window. To
see an existing Pre-Defined Validation and the entities (Payment Methods and/or Payment
Formats) that the validation has been assigned to, enter appropriate search criteria on this
window and click on the Go button.

The screenshot below shows the first 10 search results for Pre-Defined Validations that have
a Validation Point of "Payment". The first validation on the list is "Internal Bank Account
Currency Equal To", which has one parameter associated with it - "Internal Bank Account
Currency".

The Assigned Entities tabbed region shows that the same validation has been assigned twice
to the payment format called "German International EFT Format".
If you open the Update Payment Formats window and query up the "German International
EFT Format" (below), you can see that several Pre-Defined Validations have been assigned
to this format, including the two "Internal Bank Account Currency Equal To" validations we
saw above:

Removing assigned Pre-Defined Validations

Use the Remove icon for any user-assigned Pre-Defined Validation previously assigned to a
Payment Method or Payment Format.

NOTE: For seeded Payment Methods and Payment Formats, the Pre-Defined Validation
assignments seeded by Oracle cannot be removed.

Building USER-DEFINED Validations

User-defined validations are built directly in the Update window for the appropriate Payment
Method or Payment Format (for instance, see the User-Defined Validations region on the
"German International EFT Format" screenshot above):

To build a new User-Defined Validation on this format, click on the Add Another Row button,
and complete the fields necessary for the validation you want to build. The LoV for the first
field -- Field Name -- contains 76 seeded attributes:

The drop-down menu for the second field -- Validation Name -- contains several seeded
attributes to help you build your desired validation:
Add values for Country and Payment Method, if needed, before saving your new User-
Defined Validation.

Use these same steps to build a new User-Defined Validation for an existing Payment
Method on the Update Payment Method window.

Inactivating existing User-Defined Validations

If you need to inactivate an existing User-Defined Validation for a Payment Method or

Payment Format, simply set the Status to "Inactive". An end-date will be populated for you
automatically, based on the date you changed the Status to "Inactive".

Country-Specific Validations

Oracle Payments Implementation Guide

Release 12.1
Part No. E13416-04
August 2010

Page 3-30:

Country-Specific Validations

A country-specific validation is a validation related to a specific country. It is comprised of a

code and multiple sub-validations that are required for the specific country, a validation
point, and additional specifications regarding the payment formats and/or payment methods
to which the validations are applicable. Country-specific validations are seeded by Oracle
Payments and cannot be modified. For a listing of Oracle Payments seeded, country-specific
validations, see Country-Specific Validations, page B-3.

Return to Table of Contents

2.3. "Validation point"

"Validation point" is the stage at which the validation is executed in the payment process.
Validations occur at the following points in the payment process:

o Document level in the source product: In this case, the validation is

executed early in the process while the invoice is created in Payables (AP). To
perform document level validation, validations should be assigned to the
payment method. For example, a validation at payment method can be that
 document payee bank account is required on the invoice. In such case, when
invoice is created without payee bank account, the invoice will be put on hold.

o Document level in Oracle Payments (IBY): In this case, the validation is

automatically executed late in the process by the Build Payments program as
the documents are grouped into payments. These will be executed if
document-related validations are attached at payment format level. For the
same example as given above, if validation document payee bank account as
required is attached at payment format level, this validation will be executed
during build payment process.

o Payment level in Oracle Payments: In this case, the validation is

automatically executed late in the process by the Build Payments program as
the documents are grouped into payments. This occurs when the validation is
set on a field, such as the payment amount. The example of such validation
can be that payment amount should not be less than 10$. If such validation is
attached at payment format level, this will be executed during build payment
process.

 Payment Instruction Level in Oracle Payments: In this case, the validation is

automatically executed late in the process by the Create Payment Instruction
program as the payments are grouped into payment instructions. This occurs when
the validation is set on a field, such as payment instruction total should not exceed a
threshold amount.

Return to Table of Contents

2.4. What to do in cases of Validation failure

Oracle Payments User's Guide
Release 12.1
Part No. E13415-04
August 2010

Pages 5-12 and 5-13:

Resolving Document Validation Errors

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

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

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

Resolving Payment Validation Errors

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

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

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

Resolving Payment Instruction Validation Errors

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

 an overview of the payment instruction

 validation errors
 payments in the payment instruction
 documents payable within each payment
The Payment Administrator can remove payments, if necessary, leave the Funds
Disbursement Process pages altogether to change setup or third party payee data, or, in the
case of some errors, override the validation errors. If the validation errors are overridden or
resolved, the payment process proceeds to formatting and then printing or transmitting the
payment instruction.
Note: At this action step, the Payment Administrator does not have the option of removing
individual documents payable.

Specifying validation failure responses on a new PPR:

Validation failure criteria (what should the system do in case of a validation failure) can be
specified on the Validation Failure Results tab of each new Payment Process Request before
it is submitted for processing.

The validation failure criteria is specified for both DOCUMENT and PAYMENT validation
failures.

If any of the documents fail validation, the following are the options that can be taken by
the user:

 Reject only document with errors

 Stop process for review
 Reject all documents for payee when any document fails
 Reject all documents in the request

Similarly, the following options can be configured for payment validation failure:

 Reject only payments with errors

 Stop process for review
 Reject all payments for payee when any payment fails
 Reject all payments in the request

Exception

As noted in the "Tip" in the screenshot above, if withholding for a payee is enabled at
payment time and invoices related to that payee are selected in the Payment Process
Request, the system will override the user-defined validation failure options of "Reject only
document with errors" or "Reject only payments with errors".

In such cases, the system will set the validation failure option to "Reject all documents" (or
payments) when any document/payment fails.
NOTE: To clarify...for the invoices selected in a PPR, if AWT is enabled at payment
time for ANY payee, the rule "Reject all documents or payments for the Payee" will
be set for ALL the payees in that PPR.

The reason for this behavior is that withholding tax calculation can be configured for amount
ranges. In such cases, if any document or payment fails validation, the withholding
calculation that had already been performed may no longer hold true. Therefore, when such
a document fails validation, the system fails all documents/payments for the payees even if
only one of the documents/payments has failed the validation.

Example: For a payee A, withholding tax is applicable on payment time as per the following
ranges:

Payment Amount Tax Rate

Range

$0 - $99 0%

$100 - $199 10%

$200 - $499 20%

For payee A, the following invoices are selected in the PPR:

Invoice Number Invoice Amount

(USD)

A101 20

A102 400

A103 60

In this case, the following will be the withholding tax calculation:

Invoice A101 = (20 x 0%) = $0

Invoice A102 = (80 x 0% + 100 x 20% + 220 x 30%) = $86
Invoice A103 = (60 x 30%) = $18

Total withholding tax = $104

Let's say that during the Build Payments process, invoice number A102 gets rejected due to
a validation failure, while the other two invoices pass the validation. In that case, the
payment amount would initially be determined to be $80 (A101 + A103), and the payment
would be exempt from withholding since it is below the threshold limit of $100.

But the system cannot go backward at this point to recalculate the withholding tax amount
based on remaining invoices, so instead, the system will fail ALL the invoices for the payee.

Example 1: Validation failure handling

Invoices with the following attributes are selected in a Payment Process Request:

Payee Invoice Number Amount (USD) P

A A101 100

A A102 350

A A103 9

B B101 50

C C101 200

C C102 250

C C103 400

The following are some assumptions related to these invoices:

 The associated Payment Format has an assigned Document Validation that a payee
bank account is required if the related Payment Method is 'Electronic'.
 The associated Payment Format also has an assigned Payment Validation that
requires that any payment amount below $10 should be rejected.
 Payee B has withholding set at "payment time".
 There are no grouping rules specified in the associated Payment Process Profile
(PPP).
 The Validation Failure Results tab on the header of the Payment Process Request has
Document and Payment validation failure results set to "Reject only
documents/payments with errors".

1) Payee B has withholding set for "payment time", so the system will override the user-
defined settings on the Validation Failure Results tab on the header of the PPR, by setting
the Document and Payment validation failure results to "Reject all documents (and
payments) for payee".
2) Once the Document-level validations are processed, the following payments are
calculated and created (pending Payment-level validations):

Payee A: Payment 1: $450 (for invoices A101 + A102)

Payee A: Payment 2: $9 (for invoice A103)
Payee B: Payment 3: $50 (for invoice B101)

There were no payments created for Payee C because one of their documents (C103) failed
the Document-level validation which required bank account information. Because of the
system's override of the user-defined Validation Failure Resultssettings (as described in #1
above), all of the documents for Payee C were therefore rejected.

3) Once the payments were processed for Payee A and Payee B, the Payment-level
validations were applied. One of the payments for Payee A (Payment 2) is less than $10, so
it was rejected. Based on the Validation Failure Results setting described in #1 above, all
other payments for Payee A were therefore rejected as well.

4) So the only payment that will be processed is for Payee B for $50.

Best Practice for handling invoices with "payment time" withholding:

The correct way to handle the example above is to distinguish between invoices WITH
"payment time withholding" and WITHOUT "payment time withholding" and select them in
different PPRs.

This can be done by stamping invoices WITH "payment time withholding" with a separate
Pay Group or payment Priority. Then a separate PPR can be run for them by specifically
giving the payment Priority or Pay Group as a selection criteria on the header of the PPR.

For invoices WITHOUT "payment time withholding", specify no (or a different) Pay Group or
payment Priority on the header of new PPRs.

EXAMPLE 2: Validation failure handling using Best Practice

So if we take the example given above, the appropriate way to handle the use case will be
to:

 Stamp a different payment Priority or Pay Group on Invoice B101

 Provide payment priority/pay group in the selection criteria and run two PPRs.

PPR "A" -- which will select A101, A102, A103, C101, C102, C103 (invoices without
withholding), and PPR "B" -- which will select B101 (invoice with withholding).

In PPR "A", the following payments will be made:

Payee A: Payment 1: $450 (A101 + A102)
Payee C: Payment 4: $450 (C101 + C102)

Invoices A103 and C103 will be rejected (A103 because the payment is less than $9 and
C103 because it does not have a bank account)

In PPR "B", the following payment will be made:

Payee B: Payment 3: $50 (B101)

So net there will be only two rejections (A103 and C103), which are required for a business
reason.

Return to Table of Contents

Have more questions?

Join our growing Oracle Payables Community and learn from your peers and
Oracle on how to
address your unique issues in AP!

You can access the main Oracle Communities page at http://communities.oracle.com (If you
are
enrolled,the Payables community will be listed on your left. If you're not already enrolled in
the
Payables community, you can do so by clicking on the link Edit Subscriptions).

OR

from "My Oracle Support" as follows:

1. Log into My Oracle Support (Flash or Classic).

2. Click the "Community" link at the top of the page.
3. Click [Enter Here] on the following page.
4. Select the community from the "My Communities" list on the top-left.

REFERENCES

NOTE:1305001.1 - R12: AP/IBY: Master Troubleshooting Guide for Payment Process

Requests (PPRs) for Oracle Payables [VIDEO]
NOTE:1307420.1 - R12: How to Submit a New Payment Process Request (a "payment
batch")

Didn't find what you are looking for?

How To Add The Validation At Payment Method On Document Amount? (Doc ID

1505426.1)

How to add the validation at payment method on document amount as the UK BACS system
has a specific limit e.g. £100,000 and want to enforce a limit of £99,999.99 per supplier
within the BACS file
we create?

FIX

You need to add the validation by selecting the 'Payment Amount' instead of 'Document
Amount'. If there is any invoice with more than 100000, still the PPR will select the invoice
but will be
rejected during build payments.
The validations attached at the payment method level will be triggered during quick
payments also.

There are two alternatives.

1) Run the PPR batch with the validation active. After running the report, inactive the
validation and run another batch to make payment of the higher amount invoices.
2) Create two formats. Add the validation to the format1. Run the PPR using the format1.
Then run the PPR using the format2 (which would pay all the payments over and above the
limit).

---- Section 4: How is hold to a scheduled payment being applied automatically

Hold on scheduled payment applied automatically due to validation setup in payment

method.

If you setup a predefined validation or user defined validation for the payment method. If
these validation failed it will place automatic hold on scheduled payments of invoice.

Let's take an example as below:

Setup a user defined validation for settlement priority to be required.

Navigate to Payment Adminstrator > Payment Method > Under User-defined

validations tab > Add another row Document Settlement Priority to required.

R12: AP: How to apply a hold to a scheduled payment (Doc ID 1560143.1)

To test the validation create a new invoice as below but don't enter Settlement Priority at
invoice header (Settlement Priority field may be hidden so you can show from folder)

Navigate to invoices form

1- Enter invoice header information and use payment method created above "Test Payment
Method"

2- Save invoice header

3- Go to scheduled Payments tab will find hold automatically created with system Hold
Reason "Document Settlement Priority is required"

How to Setup and Extend R12 Payments Introduction

With R12 came the restructuring of how Payments(checks and electronic) are handled and
setup in Payables. Within this document you will learn how to setup the minimum
requirements in order to process payments.

This includes Bank Setup, Formats, XML Templates, Payment Process Profiles, how to
extend the iby_fd_extract_ext_pub to include custom data, attach font mapping sets(MICR)
in XML Publisher, as well as a solution on how to secure the electronic signatures for printed
checks. Setting up the Bank, Branch, Account, and Payables Document

The first step in setting up payments in R12 is to define the Bank and at least one Branch.
Use the Manage Banks and Branches page to access pages to specify general information
and define addresses and contacts for banks and bank branches. See: Create Banks, Oracle
Cash Management User's Guide and Define Bank Branches, Oracle Cash Management User's
Guide.

Next we need to create a bank account that we can use for payments. Use the Manage Bank
Accounts page to access pages to create account owners and use, controls, access, and
contacts. Also specify general information for your bank accounts. See: Bank and Account
Administration: Define Bank Accounts, Oracle Cash Management User's Guide.

Once we have defined which bank account we will be using for payments, we need to create
Payables Documents to actually make payments. These documents will serve as the ‘type’
of payment we will be trying to make. Use the Manage Payment Documents region on the
Manage Bank Account page to access the Payment Documents page. From this page, you
can access pages to create payments documents, update payment documents, and void
skipped documents. See: Oracle Cash Management User's Guide.

Payment Setups First we should set up the system security options. These security options
control settings for payment instrument encryption, masking, and credit card control. See:
Oracle Payments Implementation Guide. Next you should set up validations related to the
payment method. By setting these values up you ensure that funds capture and funds
disbursement transactions are valid, in addition to being correctly formatted before they are
printed or submitted to payment systems. Oracle Payments Implementation Guide.
Now we should turn our focus to the XML Publisher Templates. We need to either define
new templates or use seeded templates to properly format the output. At this point if you
had a custom font such a MICR.ttf or some other font, we could create the font, font
mapping set, and assign it directly to the template for use while processing payments.
Oracle Payments Implementation Guide.

Next we should create the payment format(s)s that will be tied to the template(s) we just
created in XML Publisher. I recommend applying validations at this point to make sure your
transactions are complete. In the case of creating a format used to send electronic
payments, I would add the following 3 validations: US NACH Payment Instruction Validation,
US NACHA Payee Validation, and US NACHA Internal Bank Validation. This will insure that
the Payment Instruction is less than 100,000,000, that the Payee routing number is 9 digits,
and that the internal bank account routing number is also 9 digits.

You might also consider add a uservalidation that makes sure the Payee bank account
number is not null. Oracle Payments Implementation Guide. Two other things you can
consider setting up are Transmission Configurations and Payment Systems. These allow for
the delivery of transactions along with the collaboration of Oracle Payments with external
payment systems. These are not necessarily required. Oracle Payments Implementation
Guide. Funds Disbursement Setups The predefined Payment Methods are typically the only
thing that you will need in order to process payments. These are the means by which you
will be making a payment to a third party. Payment Method Defaulting rules determine what
payment method will be applied to an invoice during invoice creation. Finally we should set
up our Payment Process Profiles. These profiles comprise of several types of payment
processing information, including specifications for formatting and transmission. Without a
Payment Process Profile we would be unable to process payments.
IBY_FD_EXTRACT_EXT_PUB This package allows the ability to add additional data to the
XML structure at multiple levels. These levels include: Get_Ins_Ext_Agg This API is called
once only for the payment instruction. Get_Pmt_Ext_Agg This API is called once per
payment. Get_Doc_Ext_Agg This API is called once per document payable.
Get_Docline_Ext_Agg This API is called once per document payable line. Get_Ppr_Ext_Agg
This API is called once only for the payment process request. eText, PAYMENTS, R12, XMLP
XML Publisher Setups for fonts Utilizing the built in functionality of XML Publisher within the
eBusiness Suite will allow us to add the appropriate fonts need in order to print checks. Add
the appropriate fonts and then create a “FO to PDF” font mapping set within the XML
Publisher Administration. You will then need to assign the font mapping set to the
TemplateConfigurationFO Processing setup. If the font is necessary globally, you could
optionally set the font mapping set value at the global configuration setup instead.

To add the font XML Publisher AdministratorAdministrationFont Files(Create Font File) To

add the Font Mapping Set XML Publisher AdministratorAdministrationFont Mappings(Create
Font Mapping Set) To set the FO ProcessingFont Mapping Set value globally XML Publisher
AdministratorAdministrationConfigurations – Expand PropertiesFO ProcessingFont Mapping
Set and set the value accordingly. To set the FO Processing at the template level – Query
TemplateEdit Configuration Expand PropertiesFO ProcessingFont Mapping Set and set the
value accordingly. Securing the signatures and MICR font Here are some ‘no cost’ best
practices for securing the signatures related to AP Checks. First you should limit access to
the responsibility that has access to the output of the ‘Format Payment Instructions’
concurrent program that print the checks. In R12 unless you have setup rules/grants in
User Management responsibility to allow access to see others output this should not be a
problem. Second you should regularly purge the output of ‘Format Payment Instructions’.
Lastly, limit access to the directory where the electronic signatures are stored. Our solution
is a combination of all of the above. We keep our signatures in $OA_MEDIA/zint/sig
directory. This directory is restricted by IP address so that only the applications server has
access to these files. The files have a naming convention of
{INSTANCE][VOID_FLAG]_[POSITION_NAME].gif(ex. PRODN_Chair.gif). This means that I
only want the file to be accessible to PROD Instance, only if the void flag is N, and only for
our County Chairman. We use the concatenation features of XML Publisher to generate the
file name on demand. This prevents potential fraud from test instances. To secure the MICR
line on the check, we use a simple “IF” condition to determine which instance the check is
being ran from and print(or not print) accordingly. These are some simple steps that you
can take to help secure the checks and signatures for AP check printing. Conclusion R12
changes the way payments are handled compared to previous versions such as 11i. This
version of payments takes full advantage of the integrated XML Publisher module to provide
enhanced visual check output without the use of 3rd party systems. The flexibility to issue
multiple payments of different payment methods within one Payment Process Request is
just one of the ways the R12 has enhanced the Payment Process. The ability to utilize the
IBY_FD_EXTRACT_EXT_PUB API is a fast and efficient way to get additional data in to the
XML structure. The above solution allows the user a simplistic way to issue payments that is
similar to 11i.
Hi All,

As we are upgrading from 11i to R12 and we are configuring payments in R12, and we have
four payment method:-
Scrren shot i have attched
1) Check
2) Electronic
3) Wire
4) Clearing

And we are configuring Payment Process Profile (PPP) in payment administrator and there is
one LOV/column at PPP's header level called: 'Processing Type' which has only three seeded
value available i.e. Electronic, Printed & Payment Card, so for payment method 'Check' we
use this as 'Printed' and for 'Electronic' payment method we will use 'Processing Type' as
'Electronic'. So we have few doubt here:-

1) What is the purpose and meaning of the column: 'Processing Type' at the PPP header
level?

2) Does it means that for 'Check' payment method we should choose only and only 'Printed'
option and for 'Electronic' payment method we should select only and only 'Electronic' ,does
this options is linked to these payment method?

3) We have remaining two payment method: 'Wire' and 'Clearing' for which we need to
configure payment process proifle and for these two payment methods we don't have any
option as 'Processing Type' as 'Wire' or 'Clearing', so what should be selected as prcossing
type for 'Wire' and 'Clearing' payment method

4) We did not see payment method as 'Clearing' in R12 while creating AP invoices, even
though this payment method is enabled in Payment Administrator...

Please suggest a way forward, eagerly waiting for your input and suggestion to configure
the PPP for 'Wire' and 'Clearing' payment method.

--

I would say, the relationship between Payment Method and the Processing Type used in
Payment process Profile is not on a ONE TO ONE basis, it is more like Many to One / One to
Many relationship Type...ALSO THERE IS NO DEPENDANCY BETWEEN PAYMENT METHOD
AND PROCESSING TYPE in PPP

The Processing type in the Payment process profile indicates how the Payment instruction is
going to be processed, which is a background process/system configuration and not shared
in front end.
The Payment method is an indication as to the available modes of payment shared in the
Front end, it does not really have any processing related information ....(apart from
seeded/user defined validations)

In Short any thing that is not printed would be electronic, hence Electronic, Wire and
Clearing would all fall under Electronic processing Type.

1) What is the purpose and meaning of the column: 'Processing Type' at the PPP header
level?
ANS - It means how the Payment Instruction would be processed.

2) Does it means that for 'Check' payment method we should choose only and only 'Printed'
option and for 'Electronic' payment method we should select only and only 'Electronic' ,does
this options is linked to these payment method?

ANS - NEED NOT BE ! I did a test case myself to get clarified, system would allow you to
select a payment process profile of electronic type to a CHECK payment method ......It is
totally up to the organization to decide how they want to process thier payment instruction,
there is no dependancy on the payment method.... You could process a CHECK Payment
electronically, you could process a WIRE payment in printed fashion as well ..

In Dell, even for EFT payment method, the PPP processing type is printed. So that It could
use prenumbered/blank stock and one number would be assigned for each payment which
is used as some internal reference.

3) We have remaining two payment method: 'Wire' and 'Clearing' for which we need to
configure payment process proifle and for these two payment methods we don't have any
option as 'Processing Type' as 'Wire' or 'Clearing', so what should be selected as prcossing
type for 'Wire' and 'Clearing' payment method

ANS - Select as Electronic for Wire and Clearing payment methods..

4) We did not see payment method as 'Clearing' in R12 while creating AP invoices, even
though this payment method is enabled in Payment Administrator...

ANS - payment method was inactivated with the following explanation: "This is one of the
seeded payment methods coming from AP, but it was decided to seed it as inactive so that
it will not appear in LOVs automatically in release 12. This payment method is an odd work
around to deal with inter-company payments prior to release 12 and its use should be
discouraged in the new release." Customers can change the status to ACTIVE if they want to
use this Payment Method. Inter-Company Payments
should be done using Oracle Treasury. Refer (ID 864855.1 - Why The Clearing Payment
Method Is Inactive In R12?)

5) Additional point - when you create your payment process profile, there is a section called
USAGE RULES, where you have a region for Payment Methods. You have to select the
payment methods that can access this payment process profile, by default the value is
selected as ALL ... if you do not want it to be available for all,you can select specific
payment methods ... that is
1) Payment Process Profile of PRINTED processing Type should be available for CHECK
payment method only
2) Payment Process Profile of ELECTRONIC processing Type should be available for WIRE,
ELECTRONIC and CLEARING payment method only
This is a configurable control and not a system restriction / intended behaviour.

I am unable to find a clear oracle documentation to justify my view stated above, these are
purely based on my experience on the application .. hence i would await others to express
thier opinion and correct me if i am wrong ...

Hi Gurus,

I've one requirement in R12, need to define custom Payment formats in instance. In our
prior instance 11.5.7, we are generating custom payment format through concurrent
program defined and attached to the Payment formats in payabales, and this one is being
used in the Payments creation in 11.5.7 (which we knows very well). In the standard
program 'Format' we are generating one text file through custom coding.

Now we need to design similar functionality in R12, as per the Oracle we need to customize
IBY_FD_EXTRACT_EXT_PUB.Get_Pmt_Ext_Agg i am using for placing the custom code in
that package as suggested in the metalink. The template document also needs to redefined
for our purpose, we will not be using the output file. In place of that we need to generate
text which we are producing like in the older versions. This text file we will upload to the
banks. Our client don't want to change the process needs to adhere to the same old
concept.

My requirement is that , is there a way where we can remove template functionality and
only generate text output through IBY_FD_EXTRACT_EXT_PUB.Get_Pmt_Ext_Agg package.
Or do I still need to use the template and manage it. Please suggest is that packaged
function which I am referring suits for requirement or not.

Thanks in advance for your valuable suggestions.

---

Ans1: IBY_FD_EXTRACT_EXT_PUB is used only to provide some additional tags whcih the
standard format payment instruction does not provide. If the standard XML file provides all
the fields required by you, then you do not require IBY_FD_EXTRACT_EXT_PUB. As far as
the standard is concerned, you need to use the XML template and process ahead.

Since you need to generate the text output, you will have to define the XML template with
the output type as "e-text outbound". This will fire the concurrent program "Format
Payment Instruction with e-text output" and will generate the text output. If you need to
store this text file in a specified location, the patch need to be provided in the payment
process profile used in the payment.
Hope this clarifies

Res: Thanks for your inputs. Actually I am bit confused with the rtf files how to modify
them. As my requirement is to shown the same kind of output what we are generating in
the 11.5.7, means in the text output format. For generating this we are using the query in
the old instance and when ever any payment is created in the format request we will be
getting the output, where it was used to send it to the bank.

Now in R12 I want to use the same thing, for that what approach will be better, since what
r12 structure conveys is that we need to use the template which they have provided. My
question is whether is it mandatory for me to use the package IBY_FD_EXTRACT_PUB and
template for this. As I found of lot things in the google regarding, where it suggests to
customize the package and update the template. But how can I sync custom code with
package and again with package to the template. I found all these things but not exactly
getting how to put them in manner.

Can you please explain me in detail steps.

Ans2: As updated previously, it is not necessary to use "IBY_FD_EXTRACT_PUB". Fist have

a look at the xml tags provided by the standard application. If there are any tags which are
not provided by standard then you can use the above package to extend the tag and bring
in your tag to be displayed in the report.

In order to find the existing XML tags provided, please run the payment process using any
template provide. Once the format payment instruction is complete, open the log file for this
program. In the log file there will be a section containing the XML data. You will need to
copy the data into a notepad and open the file as XML. You will need some technical help to
understand the file and then use the same to generate the XML template. Please have a
look at the standard XML template provided by Oracle and see if the fields provided meet
your requirement.

PPR User Defined Validation - Payment Bank Instruction 1 & 2. (Doc To

ID 1905162.1) Bottom
Added 2 additional user validations from the list under Payment Administrator->Payment
Setup->Formats:

Document Payee Bank Instruction Code 1

Document Payee Bank Instruction Code 2

In our testing, we ran a payment for a supplier which is setup for EFT (this requires Bank,
Branch Number and the 2 instruction codes to be set). Test kept Instruction code 1 and 2
null. We were able to get a rejection in the PPR as expected.

The challenge is even if we go back to the supplier setup and add the bank instruction 1/2
and re-run the PPR, the rejections still occur. On the Invoice, there is no place we can find
where these values can be placed for Scheduled Payments
Issue is caused by code bug. This is explained in Bug 18251552 - PPR USER DEFINED
VALIDATION - PAYMENT INSTRUCTION 1 & 2. Column information is missing in
IBY_DOCS_PAYABLE_VAL_GT table for validations to take place

1. How to Modify a Payment Process Request in R12

From the Oracle Payables User’s Guide, Release 12 (Part No. B25454-01, December
2006)…page 5-32:

“If you optionally configured the payment process request run to pause after invoice
selection, you can review invoice selection, review the unselected invoices, add or remove
documents payable if necessary, change invoice amounts, and review cash requirements.
Once you finish reviewing the payment process request, you can click the Submit button to
initiate the payment creation process. This action also generates the Scheduled Payment
Selection Report.”

See Note 462791.1 for more information on:

– Reviewing Selected Invoices

– Removing Selected Invoices from the Payment Process Request

– Adding Selected Invoices to the Payment Process Request

2. How to “re-add” an Invoice to a PPR

See Note 557834.1 for steps and more information.

3. How to Complete a Payment Process Request that Shows Status = Formatting

If one hits “Reprint”, the batch gets stuck at Status “Formatting”. Users don’t want to
Record Print Status as “Printed” since nothing has printed.

See Note 553413.1 for steps.

XML PAYMENT TEMPLATES

1. What File Is Needed To Customize A “Standard Check Format” Xml Template

Package IBY_FD_EXTRACT_EXT_PUB controls the XML extract used in check printing. The
supplied version can be found in $IBY_TOP/patch/115/sql/ibyfdxeb.pls.

This package contains functions that are called in SQLX Views and will be picked while
generating the XML.

The package also contains examples to show how each function in it is to be used, and how
we need to write the code in same.

Modifications to this package is considered a customization and is not supported by Oracle

Support.

See unpublished Note 787467.1 for more information.

2. How to Create or Modify a Payment Format Using XML Builder

How does one create an XML file from Oracle Payments Funds Disbursement Payment
Instruction Extract, Version 1.0 that can be loaded into the Template Builder to enable
creation or modification of Payment Formats?

See Note 465389.1 for details.

3. How to Customize a “Standard Check Format” Xml Template

Package IBY_FD_EXTRACT_EXT_PUB controls the XML extract used in check printing. The
supplied version can be found in $IBY_TOP/patch/115/sql/ibyfdxeb.pls.

This package contains functions that are called in SQLX Views and will be picked while
generating the XML. The package also contains examples to show how each function in it is
to be used, and how we need to write the code in same.

Modifications to this package is considered a customization and is not supported by Oracle

Support.

See Note 457539.1 for details.

4. How to Create / Modify Payment Formats

Financial institutions, payment systems, and/or countries have specific formatting

requirements for funds capture transactions, funds disbursement transactions, payment
documents, and payment-related reporting. Formats are created within Oracle Payments to
represent these requirements. Each format in Oracle Payments corresponds to one Oracle
XML Publisher template.

See Note 562806.1 for more information.

5. BACS Payment Format: Where to populate Service User Number (SUN)?

Q1: Where to enter the Service User Number (the number received from BACS authority)
for a bank account?

A1: The field used by default for this purpose EFT Number (because BACS is an Electronic
File Transfer).

To populate it, navigate : Setup -> Banks -> Bank Accounts then query for internal bank
account you use to make payments.

Then go to Account Information -> Field : EFT Number

Enter in this field the SUN.

Q2: How to include this number on the payment format output in case that it is not included
by default?

A2: If after populating the EFT Number this will not be included in the output of payment
format then you will have to create your own payment format starting from “UK BACS 1/2
Inch Tape Format”. It is not recommended that you modify the seeded format. Unpublished
Note 465389.1: “R12 Create Or Modify A Payment Format Using XML Builder” describes how
to accomplish this task.

Also see Note 467999.1 for more information.

6. How to Customize the XML Extract for Check Printing with Additional Data

The package IBY_FD_EXTRACT_EXT_PUB needs to be customized to accomplish this.

Package IBY_FD_EXTRACT_EXT_PUB controls the XML extract used in check printing. The
supplied version can be found in $IBY_TOP/patch/115/sql/ibyfdxeb.pls.

This package contains functions that are called in SQLX Views and will be picked while
generating the XML.
The package also contains examples to show how each function in it is to be used, and how
we need to write the code in same.

Modifications to this package is considered a customization and is not supported by Oracle

Support.

See Note 457539.1 for more information.

7. What File Is Needed To Customize A “Standard Check Format” Xml Template?

Package IBY_FD_EXTRACT_EXT_PUB controls the XML extract used in check printing. The
supplied version can be found in $IBY_TOP/patch/115/sql/ibyfdxeb.pls.

This package contains functions that are called in SQLX Views and will be picked while
generating the XML.

The package also contains examples to show how each function in it is to be used, and how
we need to write the code in same.

Modifications to this package is considered a customization and is not supported by Oracle

Support.

See Note 457539.1 for more information.

GENERAL PAYMENT ISSUES

1. How to create a Payment Process Profile (PPP)

Payment Process Profiles (PPPs) are created and managed using the Payments Setup
Administrator responsibility:

Navigate to: Oracle Payments Setup > Codes region > Payment Process Profiles row > click
on the Go To Task icon > use the Create button to create a new PPP, or search for an
existing PPP for updates.

See Note 437330.1 for more information.

2. How to Remove Seeded Validations for Oracle Payments
The Solution is to inactivate these validations in Oracle Payments or to define specific
combinations when they should not be triggered.

See Note 578369.1 for 2 examples.

3. How to Control the Delivery Channel Code of the Invoices if Selected for Payment is
Populated

There are two ways to handle this issue. You can add the validation at the Payment method
or at Format. The validations regarding the Delivery channel are available under the User
defined validations.

The field names are Document delivery channel and Payment delivery channel.

The validation can be attached with the name Required.

If you are making the payments through a specific payment method, the validation can be
attached to the Payment method. Otherwise, it is suggested to attach this to the format.

After adding this validation, when the PPR picks up invoices without the Delivery channel,
during formatting, the invoices without the Delivery channel data will be rejected with the
information Document Delivery channel is required.

See unpublished Note 578534.1 for more information.

What package needs to be modified to customize the XML extract for check printing with
additional data?

Package IBY_FD_EXTRACT_EXT_PUB controls the XML extract used in check

printing. The supplied version can be found in $IBY_TOP/patch/115/sql/ibyfdxeb.pls.

This package contains functions that are called in SQLX Views and will be picked while
generating the XML.

The package also contains examples to show how each function in it is to be used, and how
we need to write the code in same.

Modifications to this package is considered a customization and is not supported by Oracle

Support.

For more details please review Note: 787467.1: Format Customization in Oracle Payments
for Oracle Applications Release 12 and Note: 414336.1: R12: How to Assign/Modify XML
Publisher Payment Templates.
Check Printing Using XML Publisher (Doc ID 312353.1)

=== creating custom validations to use and assign to a Payment Format shall require creating
records in the tables IBY_VALIDATION_SETS_B and IBY_VALIDATION_SETS_TL.

---Business events can be defined to be triggered when formatting is completed, and that
business event can be subscribed to fire a trigger which will call custom formatting code in
pl/sql. In this case a dummy xml template would be used to complete a setup but the actual
formatting would be done by the PL/Sql program unit. Refer to Dell MD50 531.

---If PPP is not specified in PPT, then it may select documents with various processing types
i.e electronic,printed . During build phase you specify the PPPs for those document
payables.So eventually it’ll create as many Payment instructions as there are types of PPPs.
--- R12 doesn’t have the concept of Payment Format PROGRAM as it was in 11i where PL/SQL
code used to create formatted file. But in R12, xml templates extract the payment data on
which format templates are applied to get the formatted file.

---Below are the ways to limit the amounts of a payment batch.

Maximum Outlay. The largest currency outlay that you allow for a
payment batch for this bank account. If the total outlay of a payment
batch exceeds the maximum outlay for the payment batch, Payables
displays a warning, but allows you to continue processing the payment
batch. The Maximum Outlay for a bank account defaults from the
Payables Options window. When you initiate a payment batch using
the bank account, Payables uses the bank account’s Maximum Outlay
as a default. You can override this default.

Maximum Payment. The largest payment amount that you allow in a

payment batch. When you initiate a payment batch using the bank
account, Payables uses the bank account’s Maximum Payment as a
default. You can override this default.

Minimum Payment. The lowest payment amount that you allow in a

payment batch. When you initiate a payment batch using the bank
account, Payables uses the bank account’s Minimum Payment as a
default. You can override this default.

R12 does offer the user the ability to limit the number of invoices per check; allowing for
multiple checks to a single vendor per payment batch. The 'MAXIMUM DOCUMENTS PER
PAYMENT' feature is only available in R12.