White Paper ISO Credit Transfers support in Oracle Payables for Oracle Applications Release 11i TOC/Navigation Title This white paper contains the following information. 1. Introduction 2. ISO Credit Transfers Message Structure Mapping Description for CGI data elements 3. Step wise changes required to modify the template Creating Data Definition Creating Template using above Data Definition Creating new concurrent Program for Data Definition Registering a Payment Program for Concurrent Program Creating a Payment Format Associating Check stock to above Format Example for modifying data definition and template 4. Validations 5. Change Record Introduction The ‘International Organization for Standardization’ (ISO) develops standards on different areas. One of the areas where ISO provides standards is the payment area. It covers the customer to bank credit transfers, interbank settlements, payment acknowledgements and exceptions. A credit transfer is a payment initiated by the payer. The payer sends a payment instruction to his/her payment service provider (PSP). The payer’s PSP moves the funds to the payee’s PSP. This can be carried out via several intermediaries. The SEPA credit transfer format is one of the flavours of ISO credit transfers. This format is based on the rules & guidelines prescribed by EPC (European Payments Commission) and already supported in Oracle Payables. The 11i SEPA implementation in Oracle Payables provides support of SEPA core data elements (marked as yellow under the SEPA guidelines). The SEPA format supported in 11i has certain limitations like:
Transcript
White Paper
ISO Credit Transfers support in Oracle Payables for Oracle Applications Release 11i
TOC/Navigation TitleThis white paper contains the following information.
1. Introduction 2. ISO Credit Transfers Message Structure
Mapping Description for CGI data elements3. Step wise changes required to modify the template
Creating Data Definition Creating Template using above Data DefinitionCreating new concurrent Program for Data DefinitionRegistering a Payment Program for Concurrent Program Creating a Payment FormatAssociating Check stock to above FormatExample for modifying data definition and template
4. Validations 5. Change Record
Introduction
The ‘International Organization for Standardization’ (ISO) develops standards on different areas. One of the areas where ISO provides standards is the payment area. It covers the customer to bank credit transfers, interbank settlements, payment acknowledgements and exceptions.
A credit transfer is a payment initiated by the payer. The payer sends a payment instruction to his/her payment service provider (PSP). The payer’s PSP moves the funds to the payee’s PSP. This can be carried out via several intermediaries.
The SEPA credit transfer format is one of the flavours of ISO credit transfers. This format is based on the rules & guidelines prescribed by EPC (European Payments Commission) and already supported in Oracle Payables. The 11i SEPA implementation in Oracle Payables provides support of SEPA core data elements (marked as yellow under the SEPA guidelines).
The SEPA format supported in 11i has certain limitations like:- This format can be be used for making payments in euros within the SEPA zone, - The BIC/IBAN must be passed in the payment file,- The usage of different data elements is based on SEPA guidelines etc.
Due to these limitations, the SEPA payment format cannot be used for international payments outside SEPA zone.
CGI (Common Global Implementation) is an initiative of group of banks and financial institutions to have a wider acceptance of ISO20022 as a common xml standard between corporates and banks. CGI guidelines prescribe the usage of the ISO data elements for different type of transactions like ACH/WIRE/CHEQE payments. As per the CGI guidelines the data elements are broadly categorized as:
CODES TERM DEFINITIONR Required Standard element for CGI; Required either by schema or CGIC Conditional Standard element for CGI; Dependent upon a certain condition.
BD Bilaterally Determined
Standard element for CGI. Contents are bilaterally determined between client and bank
XOR eXclusive Or Standard element for CGI. Contents are XOR either by the schema or CGI usage.
NU Not Used Not Used by CGI
Customers have requested support of CGI flavor of ISO credit transfers which is a more flexible payment format supporting cross border payment in different currencies, supporting different data elements, multiple party identifications etc. The document describes:
- CGI data elements supported in 11i out of box & alternative mapping proposal for data elements not supported.
- How the existing SEPA payment format in 11i can be modified to make non Euro payments.
The mapping proposal of data elements covers the CGI data elements that are widely used and supported by banks. It does not cover the country specific data requirements of SEPA payment format.
ISO Credit Transfer message structure and mapping proposal of CGI data elements
The ISO Credit Transfers message structure consists of the following blocks:
• Group Header – Header level attributes like message identification, creation date and time, control sum, number of transactions, initiating party details etc.
• Payment Information Block – Contains the data elements like debtor, debtor bank account and branch details, payment method, block level control total and number of transactions, the payment type information details like instruction priority, service level, local instrument etc.
• Credit Transfer Transaction Information Block – Contains the payment level data elements like the creditor, creditor bank account and branch details, payment amount, invoice level details etc.
Mapping Proposal for data elements supported in CGI guidelines
The functional mapping description given below covers the mapping proposal of CGI data elements. It contains:
- The mapping proposal of data elements already covered as part of SEPA implementation.- The mapping proposal of additional data elements required as part of CGI guidelines where data
is already captured in system and
- Suggested mapping of CGI data elements that are not supported as the data is not captured in the system.
The alternative mapping proposals for additional data requirements must be handled through the customization of templates. The customization of template to pass additional data elements is covered in the next section. It describes the detailed steps with an example for customizing the payment format.
The mapping proposal is given in the tabular format as below:
Message ItemCGI Mapping Proposal for data elements supported out of box
Alternative Mapping Proposal for additional data requirements and unsupported data elements
GroupHeader
MessageIdentification Payment batch name. CreationDateTime System generated date and time stamp.
NumberOfTransactionsNumber of payments in the payment batch.
ControlSumTotal of payment amounts in the payment batch.
InitiatingParty
NameName of legal entity attached to the operating unit.
If LE name is not appropriate, then users can use DFFs at the LE level to capture the initiating party name.
IdentificationOrganisationIdentification
BICOrBEINot supported out of box.
Bank branch BIC of the internal bank account can be passed as per the requirement.
Other
Identification
Legal Entity Registration number of the legal entity attached to the operating unit will be passed in <Id> under <Othr> tag.
Pass the VAT registration number available in the Legal Entity. Else, DFFs can be set up at Legal Entity to pass the required identification.
SchemeName
Code Not supported out of box.
DFFs can be set up at Legal Entity and pass that information in payment file by customizing the xml template.
PaymentInformation
PaymentInformationIdentification AP Batch Name.
PaymentMethod Hard code value - TRF passed.
BatchBookingBatch booking indicator passed from payment format setup.
NumberOfTransactions
Total number of payments contained in the payment batch. The total number of payments at the group header level and payment information block level must be the same.
ControlSum
As per the payment architecture in 11i, payment batch can have only one logical group or payment information block. So the control sum at the payment information block is the same as control sum at the group header level.
PaymentTypeInformation
This information will be supported at the payment information level and not at the credit transfer information level.
InstructionPriority Hard code - NORM passed.
This is an optional data element. If no instruction priority is passed, banks treat the instruction priority as Normal. So this data element can be left blank.ORInstruction priority on payments is mapped to the transfer priority.
ServiceLevel
Code Not supported out of box.
Pass hard coded service level value in the payment file depending on the agreement entered into with the bank.OR Add DFFs at supplier level and pass that information in payment file by customizing the xml template.
Proprietary Not supported out of box.
Add DFFs at supplier level and pass that information in payment file by customizing the xml template.
LocalInstrument
Code Not supported out of box.
Add DFFs at supplier level and pass that information in payment file by customizing the xml template.
Proprietary Not supported out of box.
Add DFFs at supplier level and pass that information in payment file by customizing the xml template.
CategoryPurpose
Code Not supported out of box.
This is an optional element and no data is required to be passed.
However if there is any specific requirement to pass a specific value for category purpose, users can pass:
Eithera hard coded value agreed to between the customer and their banks.OrAdd DFFs at supplier level
and Pass that information in payment file by customizing the xml template.
Proprietary Not supported out of box.
This is an optional element and no data is required to be passed.
However if there is any specific requirement to pass a specific value for category purpose, users can pass:Eithera hard coded value agreed to between the customer and their banks.OrAdd DFFs at supplier level and Pass that information in payment file by customizing the xml template.
RequestedExecutionDate ‘Payment date’Debtor
Name ‘Legal entity Name’.
PostalAddress The ‘Legal entity address’. Department Address line 1 of Legal Entity address.
SubDepartmentAddress line 2 of Legal Entity address.
StreetNameAddress line 2 of Legal Entity address.
BuildingNumber
PostCode Zip Code on the address.TownName
CountrySubDivision
Country Country of the Legal Entity address.
AddressLine Not Supported out of box.
The Legal Entity address can be mapped to the address line by customizing the xml template.
Identification
OrganisationIdentification
BICOrBEINot supported out of box.
Bank branch BIC of the internal bank account can be passed as per the requirement.
Other
Identification
Legal Entity Registration number of the legal entity attached to the operating unit will be passed in <Id> under <Othr> tag.
Pass the VAT registration number available in the Legal Entity. Else, DFFs can be set up at Legal Entity to pass the required identification.
SchemeName
Code Not supported out of box.
DFFs can be set up at Legal Entity and pass that information in payment file by customizing the xml template.
DebtorAccountIdentificationIBAN IBAN of internal bank account.Other
Identification Not supported out of box.
Bank account number of internal bank account can be passed by customizing the xml template.
SchemeName
Code Not supported out of box.
This is an optional data element and the usage is decided by the agreement between the customer and bank. If required, users can use DFFs on Internal Bank Account and pass that information in payment file by customizing the xml template.
Proprietary Not supported out of box.
This is an optional data element and the usage is decided by the agreement between the customer and bank. If required, users can use DFFs on Internal Bank Account and pass that information in payment file by customizing the xml template.
Issuer Not supported out of box.
This is an optional data element and the usage is decided by the agreement between the customer and bank. If required, users can use DFFs on Internal Bank Account and Pass that information in payment file by customizing the xml template.
Type
Code Not supported out of box.
This is an optional data element and the usage is decided by the agreement between the customer and bank. If required, users can use DFFs on Internal Bank Account and pass that information in payment file by customizing the xml template.
Proprietary Not supported out of box.
This is an optional data element and the usage is decided by the agreement between the customer and bank. If required, users can use DFFs on Internal
Bank Account and pass that information in payment file by customizing the xml template.
Currency Bank Account Currency.DebtorAgentFinancialInstitutionIdentification
BICBIC of the bank branch of internal bank account.
ClearingSystemMemberIdentification
ClearingSystemIdentification
MemberIdentification Not supported out of box.
The bank branch number or routing transit number can be passed in the clearing system member identification.
PostalAddress
Country Not supported out of box.Country on the bank branch address can be passed for this data element.
BranchIdentification
Identification Not supported out of box.
The bank branch number or routing transit number can be passed in the clearing system member identification.
UltimateDebtor
Debtor and ultimate debtor parties are same in 11i. So ultimate debtor value is not supported.
ChargeBearer Hard coded value supported.
This bank charge bearer value depends on the agreement with the supplier. So a DFF at the supplier level can be used to capture the bank charge bearer value. These DFFs can be passed in the payment file by customizing the xml template.
Users can capture the intermediary agent BIC at the supplier site level DFFs and pass the same information by modifying the template.
ClearingSystemMemberIdentificationClearingSystemIdentificationMemberIdentification Not supported out of box. Supplier site level DFFs.PostalAddressCountry Not supported out of box. Supplier site level DFFs.BranchIdentificationIdentification Not supported out of box. Supplier site level DFFs.
CreditorAgent
FinancialInstitutionIdentification
BIC BIC of Supplier bank branch.
ClearingSystemMemberIdentification
ClearingSystemIdentification
MemberIdentificationBank branch number/ Routing transit number of supplier bank branch.
Name Supplier bank branch name.
PostalAddress
Country Supplier bank branch country.
BranchIdentification
IdentificationBank branch number/ Routing transit number of supplier bank branch.
CreditorName Supplier name.
PostalAddress
Department Supplier site address.
SubDepartment Supplier site address.
StreetName Supplier site address.
BuildingNumber Supplier site address.
PostCode Supplier site address.
TownName Supplier site address.
CountrySubDivision Supplier site address.
Country Supplier site address.
AddressLine Not supported out of box.
Address lines are needed if the structured address is not passed. The supplier site address can be passed under address lines by modifying the template.
Identification
OrganisationIdentification
BICOrBEI Not supported out of box.
Other
Identification
Supplier Tax registration number Or Supplier number. Supplier level DFFs.
SchemeName
Code Not supported out of box. Supplier/ Site level DFFs.
Proprietary Not supported out of box. Supplier/ Site level DFFs.
Issuer Not supported out of box. Supplier/ Site level DFFs.
PrivateIdentification
DateAndPlaceOfBirth
BirthDate Not supported out of box. Supplier/ Site level DFFs.
ProvinceOfBirth Not supported out of box. Supplier/ Site level DFFs.
CityOfBirth Not supported out of box. Supplier/ Site level DFFs.
CountryOfBirth Not supported out of box. Supplier/ Site level DFFs.
Other
Identification Not supported out of box. Supplier/ Site level DFFs.
SchemeName
Code Not supported out of box. Supplier/ Site level DFFs.
Proprietary Not supported out of box. Supplier/ Site level DFFs.
Issuer Not supported out of box. Supplier/ Site level DFFs.
CountryOfResidence Not supported out of box. Supplier/ Site level DFFs.
CreditorAccount
Identification
IBAN IBAN of the supplier bank account.
Other
Identification Not Supported out of box.Bank Account number of the supplier bank account.
Type
Code Not supported out of box. Supplier/ Site level DFFs.
Proprietary Not supported out of box. Supplier/ Site level DFFs.
Currency Not supported out of box. Supplier bank account currency.
Name Supplier bank account name.
UltimateCreditor
Not supported as debtor and ultimate debtor cannot be different in 11i payment architecture.
Not supported as debtor and ultimate debtor cannot be different in 11i payment architecture.
Purpose
Code This element is not supported out of box.
Users can pass a hard coded value depending on the payment purpose. Generally for payments created from payables this will be supplier payment where a hard coded value SUPP can be passed. Else users can setup the DFFs at supplier level and map it to the payment purpose by customizing the xml template to pass the required payment purpose.
Proprietary Same as above.
RegulatoryReporting Not supported out of box. Optional data not supported.
Tax Not supported out of box.
Optional data not supported. If required, the withholding tax details can be passed in this tag.
Creditor
TaxIdentification Not supported out of box. Supplier VAT registration number.
Debtor
TaxIdentification Not supported out of box. LE VAT registration number.
TaxAmount
TaxableBaseAmount Not supported out of box. Withholding Tax amount.
RemittanceInformation
Unstructured
Pass Invoice Number, Invoice Date, Invoice Amount, Invoice Paid Amount, Discount Amount using separators like , or / etc.
Pass Invoice Number, Invoice Date, Invoice Amount, Invoice Paid Amount, Discount Amount using separators like , or / etc.
Structured
ReferredDocumentInformation
Type
CodeOrProprietary
CodeInvoice Type like Standard, Credit Memo, Debit Memo.
Proprietary Not supported out of box. Optional data not supported.
Issuer Supplier Name
Number Invoice Number
RelatedDate Invoice Date
ReferredDocumentAmount
DuePayableAmount Invoice amount
DiscountAppliedAmount Discount amount
CreditNoteAmount Credit note amount
TaxAmount Not supported out of box. Optional data not supported.
AdjustmentAmountAndReason
RemittedAmount Paid amount
CreditorReferenceInformation
Type
CodeOrProprietary
Code‘SCOR’ hard coded value can be passed for SEPA implementation.
If any other code is needed, this has to be passed in by modifying the template.
Proprietary Not supported out of box. Optional data not supported.
Issuer Not supported out of box. Optional data not supported.
Reference Not supported out of box.Invoice Level GDFs/DFFs can be used to pass the structured creditor reference.
Invoicer
Name Supplier Name
Invoicee
Name Operating Unit name
AdditionalRemittanceInformation Not supported out of box. Optional data not supported.
Step wise changes required for to modify the template for passing new data elements
The above mapping proposal describes the mapping proposal for various data elements. This section describes is a stepwise summary of the changes required for creating a new ISO payment format. This illustrates how users can use the existing data definition of SEPA payment format can be used to customize and pass the ISO data elements in the payment file.
The modification of the xml publisher template needs to be handled through logging in to the responsibility – XML Publisher Administrator:
The following steps are required for making changes to the seeded SEPA payment format:
Step 1: Create Data Definition. Step 2: Create Template using above Data Definition.Step 3: Create a new concurrent Program for Data Definition.Step 4: Registering a Payment Program for Concurrent Program. Step 5: Creating a Payment Format.Step 6: Associating Check stock to above Format.
Detailed steps along with screenshots is described below:
Step 1: Steps for creating Data Definition.
1. Navigate to XML Publisher Administrator -> Data Definitions2. Enter Name, Code and Start Date and Description.3. Select Application “Payables”4. Click on Add File and attach data template:
Step 2: Steps for creating Template using above created Data Definition:
1. Navigate to XML Publisher Administrator -> Templates2. Enter the template Name, Code & Description.3. Select Application “Payables”4. Select Data Definition created in Step1.5. Select Type “XSL-XML” & Default Output Type as “XML”.6. In the Template File region, select the XSL Template file attached to the data definition.7. Select Language & Territory and save the details.
Following is Screenshot for Create Template
Step 3: Creating a concurrent Program for Data definition
1. Navigate to System Administrator -> Concurrent : Program -> Define2. Enter Program, Short Name, Application Name, & Description.3. Select Executable values as “XDODTEXE” and Format as “XML”.
4. Click on Parameters and enter the concurrent program parameters for Program Name and Application. Enter all the details like - Sequence Num, Parameter , Description & Value Set.
5. Leave other parameters as default and enter Token “P_PAYMENT_BATCH”:
Step 4: Registering a Payment Program for Concurrent Program
1. Navigate to Payables -> Setup : Payment ->Programs2. Enter the Name and Select Type as “Format Payments”.3. Select Registered Name “SAMPLEDD” (Short Name of Concurrent Program)
Step 5: Creating a Payment Format
1. Navigate to Payables -> Setup : Payment ->Payment Formats2. Enter Name & Select Payment method as “Electronic”. Select Multiple option for Currency3. Select Programs4. Build Payments : “Build Payments Program”5. Format Payments: “Sample Payment Program”6. Screenshot as below:
Step 6: Associating Check stock to above Format
1. Navigate to Payables -> Setup : Payment ->Banks2. Search for Bank Name 3. Click on Bank Accounts4. Click on Payables Documents5. Enter Document name “Sample Document”6. Disbursement Type “Combined”7. Payment Format “Sample Payment Format”
Example: How to modify data definition and template
Users can modify the data definition to fetch any additional data in the payment template. The below example describes how a new data element can be passed in the data definition. This example describes how a sample tag can be added to pass the Invoice Level DFF under the remittance information.
This example is illustrative only and customization of different data elements to pass the required data would need to be handled depending on the changes required.
Step 1: Modifying Data Definition for fetching Invoice level DFF. The seeded SEPA Data Definition can be saved and opened with any tool like Edit Plus/ Notepad etc. After opening the Data Definition the required changes can be made.
In this example below describes how an Invoice DFF ‘STRUCTURED_CR’ is added in the Data Definition attached APSEPAEXTRACT1.xml to pass the Creditor Reference Number:
Mapping Changes in Data Definition
Modifying template to show Creditor Reference in the payment output file:
Validations
For the newly created formats no validations can be added. So it will be the user responsibility to ensure that the payment file contains all the data required for payment processing.
Disclaimer This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Software License and Service Agreement, which has been executed and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without prior written consent of Oracle. This
document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this document without risking significant destabilization of the code.
Trademark Information Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Update Date dd-mon-yyyy Expire Date dd-mon-yyyy (ignore after this date)
