Payment Configuration Controlled by Global Descriptive Flexfields : AP Module 12 Release New Features

Payment Configuration Controlled by Global Descriptive Flexfields : AP Module 12 Release New Features askhareesh blog for Oracle Applications

Payment Configuration Controlled by Global Descriptive Flexfields

Various aspects of payment configuration were controlled by Global Descriptive Flexfields (GDF) in Release 11i and are now implemented in an integrated fashion across core Oracle Payables, Oracle Payments and Oracle Cash Management. This section is organized by functional area and discusses the upgrade impact on Oracle Payables:
  • Bank Charge Bearer Controls
  • Bank Information and Instructions
  • Regulatory Reporting Controls
  • Regulatory Reporting, Payment Reasons
  • Settlement and File Directory Controls
  • Payment File Information
  • Payment File Formatting
  • Payment Text Messaging
  • Unique Remittance Identifiers
  • Remittance Advice Controls
  • Settlement Controls
  • Danish Payment Categories
  • Settlement Priority
  • Miscellaneous Obsolete GDFs
Bank Charge Bearer Controls
In Release 11i, there are a number of GDFs that support the entry of information in the payment file about who should bear the cost of bank fees for a payment. Presently, this feature is used by the following countries: Austria, Belgium, Denmark, Finland, Germany, Netherlands, Norway, and Sweden. If you are not operating in these countries, you can disregard this section. The Japan Bank Charge feature implemented in Oracle Payables did not change in Release 12.

In Release 11i, GDFs that hold bank-charge-bearer information are held at the supplier site. Denmark is the only country that has GDFs at the bank account level, which then defaults to invoices in both the invoice interface and the invoices tables.

In Release 12, the following Global Descriptive Flexfields are obsolete. During the upgrade, Oracle Payments will migrate the bank-charge-bearer information from the GDFs to bank charge bearer information stored on the payer and payee entities and optionally, the AP invoice:
  • Austria: Bank Charge Code
  • Belgium: Foreign Payment Cost Code
  • Germany: Charge Code
  • Finland: Bank Expense Code
  • Netherlands: Domestic Costs Code, Correspondent's Costs Code
  • Norway: Norwegian Cost, Foreign Cost
  • Sweden: Payment Expense Code
  • Denmark: Settlement Code
Bank Information and Instructions
In Release 11i, there are a number of GDFs that support the entry of information about the bank where the disbursement bank account is held as well as payment instruction information specifying when and how the bank should transfer money to the supplier. Presently, this feature is used by the following countries: Finland, Germany, Netherlands, Sweden. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold bank information are held at the supplier site and global payment format levels. In Release 12, the following GDFs are obsolete. The bank information is migrated to the central Cash Management bank data model and the bank instructions are migrated to Oracle Payments and stored at the payment process profile and payee setup levels:
  • Netherlands: DNB Registration Num, Authorized Bank
  • Denmark: Bank Code, Country Code
  • Finland: Processing Type
  • Germany: Bank Instruction, Bank Instruction Details
  • Netherlands: Cross Check, Check Forwarding Code
  • Sweden: UTLI Header Code, OCR Customer Reference
Regulatory Reporting Controls
In Release 11i, some GDFs support the reporting of certain information to country governments or central banks. Presently, this feature is used by the following countries: Germany and Netherlands. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold central bank reporting information and control fields, like thresholds, are held at the following levels: system payment format, supplier site, bank account, invoices (including invoice interface) and scheduled payments. The Netherlands also used two profile options, JENL: Reporting Threshold and JENL: Validate All Invoices. In Release 12, the following GDFs and profiles are obsolete and regulatory reporting is setup at the payment process profile level in Oracle Payments. Since this feature was redesigned with a fresh perspective based on requirements from all countries, no data will be upgraded from the GDFs.
  • Germany: Declaration Flag, Declaration Limit
  • Netherlands: EFT Rate Type and profiles Reporting Threshold and Validate All Invoices
Regulatory Reporting, Payment Reasons
In Release 11i, there are a number of GDFs that support collecting of information pertaining to why a supplier or invoice is being paid. This information is required by government or central bank reporting. This feature is used by the following countries: Belgium, Denmark, Netherlands, Norway, Poland, and Sweden. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold payment reason information are held at the following levels: system payment format, supplier site, bank account, and invoices (including invoice interface). In Release 12, the following GDFs are obsolete and payment reasons are collected at the payee level and defaulted to the invoice. Oracle Payments will not support a system level payment reason in Release 12. During the upgrade, existing values in the country-specific lookups for payment reasons will be migrated to Oracle Payments payment reasons and data in invoice GDFs will be migrated to the new columns on the invoice entities.
  • Belgium: IBLC, IBLC Code
  • Denmark: Import Code, Import Code Specification
  • Netherlands: Payment Category Code, Payment Nature, Goods Code
  • Norway: Declaration Code, Declaration Desc
  • Poland: Insurance Premium Type
  • Sweden: Federal Reserve Code
Settlement and File Directory Controls
In Release 11i, there are a number of GDFs and profile options that control settlement and various aspects of payment formatting, including file directories. In Release 12, the following GDFs and profiles are obsolete and the features are handled as indicated:
  • Austria, Denmark, and all countries that use Oracle e-Commerce Gateway for electronic file delivery: Input File Path, Output File Path (upgraded to Oracle Payments payment process profiles)
  • Finland: Illegal Characters, Legal Replacement Characters (migrated to Oracle Payments payment formatting)
  • Netherlands: EFT Directory, Payment Separation, and Invoice Compression profiles (upgraded to Oracle Payments payment process profiles, payment formatting and payment building; no data upgraded for the grouping feature, however compression logic is upgraded)
  • Norway: Path for payment file, Last Sequence Number, Last Num Sent to BBS, Trans Seq Num, Seq Control and profile SigNet config fil (upgraded to Oracle Payments payment process profiles and payment formatting)
  • Norway: SIGILL Identifier, SIGILL Format (Oracle Payments' transmission and security feature allows integration with third party utilities, like the SigNet sealing operation. The Release 12 upgrade will not migrate the SIGILL setup data. Oracle Payments provides a standard configuration and you can re-configure to meet specific requirements for Norway.)
  • Sweden: Receiver Name (migrated to Oracle Cash Management bank account setup for factor bank accounts; no data will be migrated. You should set up parties for the factor companies, create their bank accounts, and link them to the supplier/payee model.)
  • Sweden: EFT File Directory, Date + Sequence (upgraded to Oracle Payments payment process profiles and payment formatting)
Payment File Information
In Release 11i, there are a number of Global Descriptive Flexfields (GDFs) that support entry of information assigned by a bank or third-party, payment system to the deploying company, also referred to as the first-party payer. The Global Descriptive Flexfields are used to capture this kind of information for implementations in the following countries: Finland, Germany, Netherlands, Norway, Sweden, Switzerland, and Denmark. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold this payment file information are held at payment format level and at internal bank account level. You could enter payment format information in two places. The first, used for Germany, Netherlands, Norway, Sweden, and Switzerland, is the EFT System Information window, accessed from the main menu. The second, used by Finland, is a window accessed from the AP Payment Formats window, the Payment Format EFT Details window. Denmark is the only country that has GDFs at the bank account level.

In Release 12, the following Global Descriptive Flexfields are obsolete:
  • Denmark: Sender Identification, Communication Agreement, User Name, Password, UBT-Number
  • Finland: EDI Identifier, EFT User Number, Exchange Rate Contract Number
  • Germany: LZB Area Number, Company Number
  • Netherlands: Trader Number, Business Sector
  • Norway: Customer ID, Agreement ID, NIF Value, Division, Operator Number, Password
  • Sweden: Customer Number
  • Switzerland: Company TELEKURS ID, Department TELEKURS ID, Company PTT File ID During the upgrade, Oracle Payments will create one Payment System record for each bank and a corresponding Payment System Account and its attributes for values formerly supported by the GDFs.
Payment File Formatting
In Release 11i, some GDFs and profile options for Netherlands and Sweden set a value at implementation time, then include that value in each formatted payment file to the bank. The values are not migrated during the upgrade. There are two options that users have in Release 12:
  • Populate the desired value in the Oracle Payments EFT payment format template
  • Create the value as a bank instruction on the payment process profile in Oracle Payments.
The following GDFs and profiles are obsolete in Release 12:
  • Netherlands: EFT Rate Tye and profiles EFT Reference Text, Carriage Return
  • Sweden: Sender Code, Credit Days, Payment Date, Accounting Code, Sort Option, Credit Code, Report code, Invoice Option, Days Credit Memo Valid
Payment Text Messaging
In Release 11i, there are several GDFs that support the entry of text messages to be sent to payees in a payment format. In Release 12, the following GDFs and profiles are obsolete and text message fields are available at Oracle Payments payment process profile and payee setup levels as well as at the invoice level in Oracle Payables:
  • Sweden: Invoice Information, Invoice End Date, Invoice Title, Amount Header, Message Row 1, Message Row 2
  • Finland: Short Message Line, Long Message Line 1, Long Message Line 2, Tax Message, Reference Text
  • Denmark: Short Notice, Bank Notice, Supplier Message
  • Norway: Message to Supplier
  • Germany: Explanation
Not all GDFs will migrate to the new functionality in Oracle Payments. Invoice End Date will be obsolete in Release 12. Users can remove any message text once they do not want it included in the payment file. Amount Header will also become obsolete. The requirement for this field can be met using the EFT format template in Oracle Payments.

Unique Remittance Identifiers
In Release 11i, there are several GDFs that support the entry of reference information that gets passed along with a payment in the payment file to assist in reconciling the payment to its invoices. In Release 12, the following GDFs are obsolete and the unique remittance identifiers, like reference number and check digit, can be entered on the invoice in Oracle Payables:
  • Denmark: Party ID
  • Finland: Reference Number, Check Digit, Tax Reference
  • Norway: KID, Invoice Number
  • Switzerland: ESR Number
Data will be migrated from the GDFs to the new fields on the invoice. Country- Specific validation for the reference numbers will be migrated into the validation module of Oracle Payments.
Remittance Advice Controls
In Release 11i, there are country-specific tables and profile options that control the frequency and method of creating a remittance advice. In Release 12, the following tables and profiles are obsolete and the remittance advice creation is managed by the payment process profile and its remittance controls:
  • Germany: JE_DE_AR_BATCHES.REMIT_BATCH_ID and REMIT_BATCH_NAME
  • Germany: JE_DE_AP_BATCHES.CHECKRUN_NAME
  • Netherlands: JE_NL_EFT_SPECS.CHECKRUN_NAME and CHECK_NUMBER
  • Italy: "AP Payment: Company Details Printed" profile option.
  • Netherlands: "JENL: Payment Specification" profile option.
Oracle Payments provides an XML Publisher template for creating a remittance advice.
You can modify this template to meet the requirements of your country.

Settlement Control
In Release 11i, there are several fields that specify the way an invoice should be settled. The fields used for this purpose come in three categories: payment methods, delivery channels (which specify how a bank provides a payment to the payee), and payment formats. These fields include both Oracle Payables functionality and GDFs. In Release 12, the following GDFs, and other entities, are obsolete and the settlement information is handled by Oracle Payments:
  • Denmark: JE_DK_PAY_CATEGORIES (Note: payment means and channel will not be upgraded. The mapping will happen in the Danish payment format template provided by Oracle Payments.)
  • Denmark: Payment Means, Payment Channel, Payment Category, Payment Category ID
  • Finland: Payment Type, Payment Format
  • Germany: Payment Method
  • Netherlands: Urgency Code
  • Sweden: Payment Type
  • Switzerland: Payment Type


During the upgrade, Oracle Payments will migrate payment methods from the Oracle Payables entity to the new Oracle Payments payment methods entity and will upgrade all invoice data. Payments will also migrate default values for payment method, delivery channels and payment formats from the Global/Payables system, supplier, supplier sites and payee setups to the new Oracle Payments solution.

Danish Payment Categories

The form that supports the specification of payment categories is obsolete in Release 12. The functionality that this form supported is partially migrated to new entities in Release 12. Part of the upgrade verification testing for electronic payment processing in Denmark should be to review the migrated data and configure new setup as needed.

Each payment category is upgraded to a payment method in Oracle Payments. As noted in the previous section, the payment means and payment channel associated with the payment category are not upgraded. In Release 12, values for these should be set in the XML Publisher format template associated with the specific payment format. The seeded Danish format templates contain example mappings to help guide you in setting this information.

The payment category setup allows implementers to define the validation of certain invoice fields based on the payment category (for example, a field is required). The upgrade does not automatically migrate these settings to the new Oracle Payments validation model. After the upgrade, the payment methods should be reviewed, and the validations should be configured as user-defined validations set as needed on each
payment method.

Settlement Priority

In Release 11i, there are GDFs that control how urgently the bank should handle the fund disbursement. In Release 12, the following GDFs are obsolete and the settlement priority is entered on the invoice and managed by Oracle Payments: 
  • Norway: Urgency Called
  • Sweden: Express Invoice, Express Payment (Note: In 11i, Sweden stores the payment format in a GDF context field. During the upgrade, the payment format is migrated to the payment format column on the invoice entity.)
During the upgrade information is migrated from the GDFs into the new columns.

Miscellaneous Obsolete GDFs

The following GDFs are not used in payment formats, and are obsolete:
  • Denmark: Dummy
  • Finland: Check A/B-form info?, Exchange Rate Contract Number, Dependence Code
  • Norway: Last Date File Created, Sigil ID, Sum
  • Sweden: Account Code, Clearing Number, Envelope, Future Contract Postgiro, Future Contract, BGC, Invoice charge Code
  • Switzerland: Company ID 


*/

No comments:

Post a Comment