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:

- 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 DEFINITION
R Required Standard element for CGI; Required either by schema or CGI
C Conditional Standard element for CGI; Dependent upon a certain condition.
BD Bilaterally Standard element for CGI. Contents are bilaterally determined
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:

Alternative Mapping Proposal for

CGI Mapping Proposal for data elements additional data requirements and
Message Item supported out of box unsupported data elements
GroupHeader

MessageIdentification Payment batch name.

CreationDateTime System generated date and time stamp.
Number of payments in the payment
NumberOfTransactions batch.

Total of payment amounts in the

ControlSum payment batch.
InitiatingParty

If LE name is not appropriate, then users

Name of legal entity attached to the can use DFFs at the LE level to capture the
Name operating unit. initiating party name.
Identification
OrganisationIdentification

Bank branch BIC of the internal bank

Not supported out of box. account can be passed as per the
BICOrBEI requirement.
Other
Legal Entity Registration number of the Pass the VAT registration number available
legal entity attached to the operating in the Legal Entity. Else, DFFs can be set up
unit will be passed in <Id> under <Othr> at Legal Entity to pass the required
Identification tag. identification.
SchemeName
DFFs can be set up at Legal Entity and pass
that information in payment file by
Code Not supported out of box. customizing the xml template.
PaymentInformation

PaymentInformationIdentification AP Batch Name.

PaymentMethod Hard code value - TRF passed.

Batch booking indicator passed from

BatchBooking payment format setup.
 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
NumberOfTransactions the same.
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
ControlSum sum at the group header level.

This information will be supported at the

payment information level and not at the
PaymentTypeInformation 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.
OR
Instruction priority on payments is
mapped to the transfer priority.

ServiceLevel
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
Code Not supported out of box. the xml template.

Add DFFs at supplier level and pass that

information in payment file by customizing
Proprietary Not supported out of box. the xml template.

LocalInstrument

Add DFFs at supplier level and pass that

information in payment file by customizing
Code Not supported out of box. the xml template.
Add DFFs at supplier level and pass that
information in payment file by customizing
Proprietary Not supported out of box. the xml template.

CategoryPurpose
 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:
Either
a hard coded value agreed to between the
customer and their banks.
Or
Add DFFs at supplier level

and Pass that information in payment file

Code Not supported out of box. by customizing the xml template.
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:
Either
a hard coded value agreed to between the
customer and their banks.
Or
Add DFFs at supplier level
and Pass that information in payment file
Proprietary Not supported out of box. 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.
Address line 2 of Legal Entity address.
SubDepartment
Address line 2 of Legal Entity address.
StreetName
BuildingNumber

PostCode Zip Code on the address.

TownName
CountrySubDivision
Country Country of the Legal Entity address.
 The Legal Entity address can be mapped to
the address line by customizing the xml
AddressLine Not Supported out of box. template.
Identification

OrganisationIdentification
Bank branch BIC of the internal bank
Not supported out of box. account can be passed as per the
BICOrBEI requirement.
Other
Legal Entity Registration number of the Pass the VAT registration number available
legal entity attached to the operating in the Legal Entity. Else, DFFs can be set up
unit will be passed in <Id> under <Othr> at Legal Entity to pass the required
Identification tag. identification.
SchemeName

DFFs can be set up at Legal Entity and pass

that information in payment file by
Code Not supported out of box. customizing the xml template.
DebtorAccount
Identification
IBAN IBAN of internal bank account.
Other
Bank account number of internal bank
account can be passed by customizing the
Identification Not supported out of box. xml template.
SchemeName
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
Code Not supported out of box. template.
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
Proprietary Not supported out of box. template.
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
Issuer Not supported out of box. 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.
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
Proprietary Not supported out of box. template.
Currency Bank Account Currency.
DebtorAgent
FinancialInstitutionIdentification

BIC of the bank branch of internal bank

BIC account.

ClearingSystemMemberIdentification

ClearingSystemIdentification
The bank branch number or routing transit
number can be passed in the clearing
MemberIdentification Not supported out of box. system member identification.

PostalAddress

Country on the bank branch address can

Country Not supported out of box. be passed for this data element.

BranchIdentification
The bank branch number or routing transit
number can be passed in the clearing
Identification Not supported out of box. system member identification.
Debtor and ultimate debtor parties are
same in 11i. So ultimate debtor value is
UltimateDebtor not 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
ChargeBearer Hard coded value supported. file by customizing the xml template.
CreditTransferTransactionInformation
PaymentIdentification

InstructionIdentification Mapped to Payment Document Number.

EndToEndIdentification Mapped to Payment Document Number.

This information is passed at the
PaymentTypeInformation payment information block level.
InstructionPriority

ServiceLevel

Code
Proprietary
LocalInstrument
Code
Proprietary
CategoryPurpose
Code
Proprietary
Amount
Payment amount and Payment Currency
InstructedAmount is mapped to this data element.
EquivalentAmount
No use case to support this data element
Amount Not Supported out of box. as per 11i payment architecture.
No use case to support this data element
CurrencyOfTransfer Not Supported out of box. as per 11i payment architecture.
ExchangeRateInformation
No use case to support this data element
as per 11i payment architecture.
ExchangeRate Not Supported out of box.
No use case to support this data element
as per 11i payment architecture.
RateType Not Supported out of box.
No use case to support this data element
as per 11i payment architecture.
ContractIdentification Not Supported out of box.
This data element is supported at
payment information block. Please see
the mapping proposal in the payment
ChargeBearer information block.

Not supported as debtor and ultimate Not supported as debtor and ultimate
debtor cannot be different in 11i debtor cannot be different in 11i payment
UltimateDebtor payment architecture. architecture.

IntermediaryAgent1
FinancialInstitutionIdentification
Users can capture the intermediary agent
BIC at the supplier site level DFFs and pass
the same information by modifying the
BIC Not supported out of box. template.
ClearingSystemMemberIdentification
ClearingSystemIdentification
MemberIdentification Not supported out of box. Supplier site level DFFs.
PostalAddress
Country Not supported out of box. Supplier site level DFFs.
BranchIdentification
Identification Not supported out of box. Supplier site level DFFs.
CreditorAgent
FinancialInstitutionIdentification

BIC BIC of Supplier bank branch.

ClearingSystemMemberIdentification
ClearingSystemIdentification
Bank branch number/ Routing transit
MemberIdentification number of supplier bank branch.

Name Supplier bank branch name.

PostalAddress
Country Supplier bank branch country.
BranchIdentification
Bank branch number/ Routing transit
Identification number of supplier bank branch.
Creditor
Name 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.
Address lines are needed if the structured
address is not passed. The supplier site
address can be passed under address lines
AddressLine Not supported out of box. by modifying the template.
Identification
OrganisationIdentification
BICOrBEI Not supported out of box.
Other
Supplier Tax registration number
Or
Identification 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
Bank Account number of the supplier bank
Identification Not Supported out of box. 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.
Not supported as debtor and ultimate Not supported as debtor and ultimate
debtor cannot be different in 11i debtor cannot be different in 11i payment
UltimateCreditor payment architecture. architecture.
Purpose
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
Code This element is not supported out of box. the required payment purpose.
Proprietary Same as above.
RegulatoryReporting Not supported out of box. Optional data not supported.
Optional data not supported. If required,
the withholding tax details can be passed
Tax Not supported out of box. 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

Pass Invoice Number, Invoice Date,

Invoice Amount, Invoice Paid Amount, Pass Invoice Number, Invoice Date, Invoice
Discount Amount using separators like , Amount, Invoice Paid Amount, Discount
Unstructured or / etc. Amount using separators like , or / etc.
Structured
ReferredDocumentInformation
Type
CodeOrProprietary
Invoice Type like Standard, Credit Memo,
Code 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
‘SCOR’ hard coded value can be passed If any other code is needed, this has to be
Code for SEPA implementation. 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.
Invoice Level GDFs/DFFs can be used to
Reference Not supported out of box. 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 Definitions

2. 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 -> Templates
2. 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 -> Define
2. 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 ->Programs
2. 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 Formats
2. Enter Name & Select Payment method as “Electronic”. Select Multiple option for Currency
3. Select Programs
4. 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 ->Banks
2. Search for Bank Name
3. Click on Bank Accounts
4. Click on Payables Documents
5. 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.

Change Record
Date Description of Change
June 30, 2013 Created document.

Oracle Corporation

Author and Date

Patruni Suresh, June 2013

Copyright Information
Copyright © 2004, 2005 Oracle. All rights reserved.

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)