11g Release 1 (11.1.2)
Part Number E20375-02
Contents
Previous
Next
|
Oracle® Fusion
Applications
Financials Implementation Guide 11g Release 1 (11.1.2) Part Number E20375-02 |
Contents |
Previous |
Next |
This chapter contains the following:
Payment Method Defaulting: Explained
Payment Process Profiles: Explained
Payment Detail Formula: Explained
A disbursement payment method is a method of payment that your company uses to pay a supplier, customer, or employee. The payment method can be electronic, such as EFT, bill payable, or wire, or printed, such as a check. You can use a payment method to pay one or multiple third party payees.
The purpose of creating disbursement payment methods is to:
Define the disbursement payment methods you want to use to make payments
Define usage rules to limit the use of disbursement payment methods to specific business units, legal entities, and other attributes.
Assign validations to disbursement payment methods for running on documents payable, payments, and payment files
The level of granularity that you need for your disbursement payment methods is a factor to consider before you define them. You must decide whether to set up more or less granular disbursement payment methods. The least granular payment methods are those that are predefined in Oracle Fusion Payments, such as Check or Electronic. With this setup, you can associate each payment method with many payment process profiles and payment formats. This approach requires less knowledge from source product users, such as invoice entry clerks, but may involve more work later in the payment process.
Alternately, you can define more granular payment methods. When you do this, you can benefit from adding validations to the payment method, which are very targeted for specific transactions. An example of a very granular payment method is Italian EFT to which you might add a validation that is specific to Italy. With this kind of setup, validations are run as early as during invoice entry and thus, errors can be fixed more quickly.
Because the approach of creating very granular payment methods will lead to more payment methods, it is important to also set up payment method defaulting rules, so there is no added burden during invoice entry to manually select one appropriate payment method from the many available. You can also use supplier-specific defaults, an optional feature which can be enabled in the Payment Method Default Basis region on the Manage Disbursement System Options page.
Creating a disbursement payment method in Payments is comprised of the following major tasks:
Creating usage rules
Creating or assigning validations
Usage rules specify when a disbursement payment method is available for use by source products for documents payable. By creating usage rules, you enable or disable payment methods for each source product integrated with Oracle Fusion Payments. You can provide different usage rules for different source products and change whether and when the payment method is available.
In the Usage Rules tab of the Create Payment Method page, you decide whether to assign the payment method to all payees and whether to apply this payment method to all or only to specific Oracle Fusion Payables or Oracle Fusion Receivables business units, legal entities, transaction types, currencies, or payee locations.
In the Validations tab of the Create Payment Method page, you can assign predefined validations to this payment method or create user-defined validations for this payment method. Validations are rules that check the validity of documents payable, payments, or payment files.
Usage rules specify when a payment method or a payment process profile can be used on a document payable.
You can specify:
Usage rules for payment methods
Usage rules for payment process profiles
A payment method is the medium by which the first party payer, or deploying company, pays a supplier invoice, customer refund, or employee expense report.
By default, payment methods are available on all transactions, but by creating usage rules, you can limit the use of a payment method based on the following transaction conditions:
Source product
Business unit
First party legal entity
Transaction type
Whether domestic or foreign currency or payee location
Not all source products that are integrated with Oracle Fusion Payments have usage rule options. Some products, such as Oracle Fusion Fixed Assets, create transactions that are imported into Oracle Fusion Payables, and are included in Payables usage rules. Other products, such as Oracle Fusion Expenses, have fixed usage rules on supported payment methods.
The payment method that the source product user sees in the source product depends on the usage rules specified in the Create Payment Method page, Usage Rules tab, Payables subtab, and Receivables (Customer Refunds) subtab. For example, suppose you have a payment method that is specific to one country. You could create a usage rule so that the payment method is available for only the one business unit associated with that country. A user entering an invoice for any other business unit would not see that payment method available to select. Usage rules, combined with payment method defaulting rules and user-definable validations, make straight-though processing possible.
A payment process profile specifies the details of the disbursement payment process, such as specifications for document payable grouping, payment grouping, and payment file formatting.
By default, payment process profiles are available on all transactions, but by creating usage rules, you can limit the use of a payment process profile based on the following transaction conditions:
Payment method
Business unit
Disbursement bank account
Currency
The payment process profile that is applied to a document payable depends, in part, on the usage rules specified in the Create Payment Process Profile page, Usage Rules tab. When you submit a payment process request, Payments compares the attributes of each transaction to the payment process profile provided in the Submit Payment Process Request page. Any transactions whose attributes are in conflict with that payment process profile's usage rules will fail validation. If no payment process profile has been selected, Payments compares the attributes of each transaction to all existing payment process profiles to determine if there is one payment process profile for which the usage rules are a unique match with the transaction attributes. If a match does not occur, a custom hook implementation or user intervention is needed to determine the appropriate payment process profile to use.
To enable straight-through processing, it is important that usage rules be no broader than necessary. For example, having two payment process profiles in which the usage rules could both apply to the same document payable will lead to user intervention to differentiate between the two. However, if one of the two is specific to business unit X and the other to business unit Y, then there is no ambiguity and the system can uniquely identify which payment process profile to apply to the document payable without user intervention.
A payment method defaulting rule determines which payment method defaults onto a source document, such as an invoice or customer refund. During setup of the payment method defaulting rules, you specify conditions under which a payment method acts as a default.
A payment method can default onto a source document based on:
Source product
Business unit
First party legal entity
Transaction type
Whether domestic or foreign currency or payee location
Oracle Fusion Payments applies the payment method defaulting rules in the prioritized order you specify. For example, if the first rule is a match, Payments stops and defaults that rule's corresponding payment method onto the invoice. Further, suppose you specify that the payment method for all documents processed by Oracle Fusion Payables is first, Check, and second, EFT. In this case, if the conditions for payment method Check match those on the invoice, then payment method Check defaults onto the invoice. If the conditions for payment method Check do not match those on the invoice, then Payments determines whether the conditions for payment method EFT matches. If the conditions for payment method EFT match those on the invoice, then payment method EFT defaults onto the invoice.
The following factors may, depending on setup and data, influence payment method defaulting:
Whether the option, Based Only on Payment Method Defaulting Rules Setup, or the option, Override Defaulting Rules when Default Method Set for Payee, is selected as the payment method default basis in the System Settings subregion or Business Unit Level Override region of the Manage Disbursement System Options page
The prioritized order of the payment method defaulting rules
The content of the payment method defaulting rules, compared with the attributes of the transaction
The defaults set in Payables for supplier, address, and supplier site
A payment process profile is a payment attribute assigned to documents payable, which specifies handling of the documents payable, payments, and payment files by Oracle Fusion Payments. Payment process profiles include several types of information, such as specifications for payment file formatting and transmission. The payment method and other invoice attributes drive the assignment of a payment process profile to each document payable, and the payment process profile drives every subsequent step of the payment process.
A payment process profile controls payment processing for the disbursement flow. It provides the blueprint to:
Tie setups together
Control usage
Specify payment formatting, printing, and transmission behavior
Control creation of payments and payment files
Automate report generation
Before you can set up a payment process profile, you must have completed setting up the following:
Payment format
Payment system
Payment system account
Transmission configuration
Payment method
When you set up a payment process profile, you specify the values on a transaction that are compatible with it. You can specify whether the payment process profile can be used on a specific document payable based on its payment method, disbursement bank account, business unit, and currency. For example, if the payment format associated with the payment process profile only allows a specific currency, then enter that currency in the usage rules so that the payment process profile can only be used on documents payable of the appropriate currency.
When you set up a payment process profile, you specify whether it can be used for printed or electronic payment processing, as well as the payment file format. If the payment process profile will be used for electronic payment processing, you also select a payment system and enter details that allow the system to electronically transmit files to that payment system within the context of a payment system account. A payment system account is not a bank account, rather data that represents your processing relationship with your payment system. If the payment process profile will be used for printed payment processing, a payment system is not required for payment file handling, but you can optionally select a payment system and transmission details so that the system can electronically transmit positive pay files to your bank.
When you set up a payment process profile, you specify document grouping rules and document limits. These settings will be used when building documents payable into payments. An enabled grouping rule for an attribute means that two documents payable that share the same value for an attribute can be grouped into the same payment. If the values are different, they will be in separate payments. A disabled grouping rule for an attribute means that the attribute will not apply when documents payable are built into payments.
Similarly, payment grouping rules determine which attributes will be considered when grouping payments into payment files.
In addition, you can specify payment file limits, payment sorting rules, and bank instruction text.
When you set up a payment process profile, you specify whether you want the following types of reports generated when the newly created payment process profile is used: payment file register, positive pay, separate remittance advice, and regulatory reports.
A payment detail formula is a custom PL/SQL expression that drives the informational text that is sent to the bank or payment system for each payment. The Payment Detail Formula field in the Create Payment Process Profile page, Payment tab, Document Limits region, must contain a PL/SQL expression written by a database administrator. This PL/SQL expression, which can reference columns of the documents payable table, is used by Oracle Fusion Payments to generate payment detail in the form of text that becomes part of the payment.
An example of a payment detail formula is PO_NUMBER || ' ' || CALLING_APP_DOC_REF_NUMBER || ';'. This formula tells the application to create payment detail by concatenating the purchase order number and the source product's document payable reference, separated by a space. For example, suppose there are two documents payable in the payment. If document payable ABC associated with PO 123 is combined with document payable DEF associated with PO 124, then the concatenation for the documents payable in the payment results in the following payment detail:
123 ABC;124 DEF;
When the Build Payments program builds documents payable into payments, it uses the PL/SQL expression you entered in the Payment Detail Formula field to generate text from fields in the document payable table. This informational text displays in the Payment Details field in the Remittance Information region of the Payment page. Payments then places the payment detail text into the applicable payment format. Depending on the bank or payment system and the format type, the financial institution may process the payment detail text into its system, or it may just use the payment detail text as information only.
Oracle Fusion Payments enables you to specify payment codes that are required by financial institutions. Payment codes can provide details to banks or payments systems about transaction handling, bank charges, or payment reasons for regulatory reporting purposes.
Payment code types include:
bank instruction codes
delivery channel codes
payment reason codes
Bank instruction codes are values that contain information or instructions that need to be passed to a bank or financial institution at the payment file level. Up to two bank instructions can be entered on a payment process profile. When that payment process profile is used during the creation of a payment file, the bank instruction values are copied directly to it. The values are made available to the formatting process by the extract. If the payment format specifies the use of one or both bank instructions, the value or values will be passed to the bank in the header level of the payment file.
Oracle Fusion Payments provides many predefined bank instruction codes.
Delivery channels are instructions that tell the bank how to make the payment to the payee. A default delivery channel value can be set on the supplier, supplier address, or supplier site. A value defaults from the lowest of these levels with a value populated, onto the invoice in Oracle Fusion Payables. On the invoice, it is displayed with the installments and can be manually overridden there.
When an installment is paid, the delivery channel is copied from the document payable to the payment, only if all documents payable in the payment have the same delivery channel value. By enabling delivery channel as a document grouping rule on the payment process profile that is used, you can ensure that documents payable will only be grouped into a payment with other documents payable when they all have the same delivery channel value.
Oracle Fusion Payments provides many predefined delivery channel codes.
Payment reason codes are generally country-specific identifiers provided by a country's government or central bank. These codes provide the payment system or bank with additional details about the reason for the payment for regulatory reporting purposes. The purpose of entering country-specific payment reason codes required by a particular country's payment system or central bank is to enable you to specify the reason for the payment to the country-specific payment system or bank.
Oracle Fusion Payments provides many predefined payment reason codes.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
