XML as Global Payment file | SCNSCN_files/cb=gapi.loaded_0" async>SCN_files/all.jSCN_files/widgets.SCN_files/google_service.js" type="SCN_files/8dSCN_files/niSCN_files/niSCN_files/NiSCN_files/NiSCN_files/n4SCN_files/n4SCN_files/n4SCN_files/n4SCN_files/haSCN_files/niSCN_files/ruSCN_files/SASCN_files/os

:

XML as Global Paymentfile

Appliesto

SAP ERP 5.0 / 6.0 with the focus of One XML format for global paymentsincluding SEPA

Summary

The purpose of this document is:

 To provide possible country specificrequirements (Europe and Americas) used at Banks to extend the XML format

 Development highlights to extend XMLformat as Global format

It is necessary the consultant is aware of all the basicsettings of the Automatic payment process. This document is only focused on thecreation of complete structure of payment file in XML format with the use ofSAP standard template SEPA_CT.

Table of Contents

1Introduction.

;

2Benefits of using XML format as Globalformat

;

3General Configuration.

;

4XML SEPA Country specific Configuration.

4.1;Rules to determine a SEPA Payment

4.2;General Considerations: All EU SEPAcountries.

4.2.1;Invoice reference in Payment file.

4.3;Country specific changes.

4.3.1;Spain.

4.3.2;Belgium.

4.3.3;France.

;

5XML SEPA extension as Global format

5.1;General Considerations.

5.2;If Beneficiary Bank has IBAN

5.3;If Beneficiary has No IBAN User exit

5.4;DKK Payments in Denmark.

5.5;SEK Payments in Sweden.

5.6;NOK Payments in Norway.

5.7;GBP Payments in UK.

5.8;USD Payments in US.

;

6Related Content

;

7Disclaimer and Liability Notice.

;

;

1 Introduction

This document aims to understand and to use the XMLformat as Global format including SEPA requirements / Transactions.

To start, SAPs standard template SEPA_CT for CreditTransfer is used. The basic requirements and technicalities to generate thepayment file takes into consideration the requirement of EPC (European PaymentsCouncil)

The EPC rulebooks contain the business requirements andrules for the operation of the SEPA. The implementation guidelines specify theSEPA core requirements that apply to the UNIFI (ISO20022) XML

standards and cover mandatory bank-to-bank messages andoptional recommended customer-to-bank messages.

2 Benefits of using XML format as Global format

 Converging to SEPArequirements, hence in line with the legal requirements

 Less maintenance cost forthe company

 Adaptability and flexibleto accommodate any future changes either by Financial institutions or bybusiness

 Highly Secured

3 General Configuration

Standard SEPA_CT for credit transfer cannot be usedunless changes are adopted as per the bank and country specific requirements.It also depends on the Beneficiary Bank details, Currency of payment andBeneficiary bank country.

A new format can be created as there are noformats available for a specific bank/ country. This customization can beeither done through modifying the standard function modules of an existingPMW (Payment Medium Workbench) format or through developing via DataMedium Exchange Engine (DMEE). (However this document does not deal withcustomizing through DMEE).

4 XML SEPA Country specific Configuration

;

4.1 Rulesto determine a SEPA Payment

Data Format

 Ordering and beneficiaryaccounts have to be in IBAN format

 BIC is required for bothordering and beneficiary parties

How recognizea payment elligible for SEPA

Thefollowing are few of the rules to make SEPA Credit Transfer:

 The transactions have tobe in Euro

 The Debtor and Creditormust each hold an account with a Participant located within the SEPA

 The transfers have to bein the SEPA area.

;

The SEPA area comprises the following countries: o EU : Euro-zone countries:

Austria, Belgium,Cyprus, Estonia, France, Finland, Germany, Greece, Ireland, Italy, Luxemburg,Malta, Netherlands, Portugal, Slovakia, Slovenia

and Spain

o Non-EU : non-Euro-Zone countries Bulgaria, Croatia, CzechRepublic, Denmark, Great Britain, Hungary, Latvia, Lithuania, Monaco, Poland,

Romania and Sweden

;

4.2 GeneralConsiderations: All EU SEPA countries

SAP Standard template SEPA_CT to be copied as a basetemplate with the necessary naming convention.

Path: SPROIMG Financial Accounting(New) Accounts Receivable and Accounts Payable BusinessTransactions OutgoingPayments Automatic Outgoing Payments Payment Media Make Settings for Payment Medium Formats fromPayment Medium Workbench

The above path can also be accessed through the T. Codes OBPM1 / OBPM2/ OBPM3 / OBPM4.

The steps in implementing PMW:

 Create/ change payment medium formats

 Assign variant to the format

 Assign the format to payment method

Tr. Code: DMEE: To Copy (highlighted below) the Standard template Fig1. This will copy all the standard segments of XML format used inpayment file.

The output structure of standard DMEE file is as shownbelow - Fig 2

Important Considerations

 In the Payment file, aswift BIC code can be on 8 or 11 characters. i.e., for example you can indicatein files as BNPAGB22 or BNPAGB22XXX. The four first characters have to beLetters & the 5 - 6 characters is the ISO country code.

 In the payment file, Charges always set-upto SLEV for SEPA payments. This indicates to Bank that default chargesset-up will be applied and is born by the debtor. Other charges available forNON SEPA payments are : CRED, DEBT and SHAR.

 For example, in Denmark,default charges are shared. You can force charges to what you want byspecifying one of the following values: SHAR or DEBT or CRED. This depends onthe Business agreement with Beneficiaries.

 If the Payment is SEPArelevant, it is always mandatory to have the Payment type informationas follows:

SEPA

 

 Batch booking option.

If batch booking= true. The bank statement will mention a global debit ofthe instruction.

 If batchbooking= false. The bank statement will mention the details of all transactionswithin the instruction.

Sample as follows:

4.2.1 Invoicereference in Payment file

Based on the Business requirements, either the paymentcan be executed by grouping the invoices per vendor & currency or can beseparated per invoice. Thus with the following changes in SAP, invoicereferences can be transferred in the Payment file

4.2.1.1 Group of invoices paid per Vendor & Currency

If the invoice is grouped per Vendor & Currency withmultiple invoices to pay, it is required to capture all the invoice referencesin the payment file. This is required as this will serve as the reference tothe Beneficiary when the Account statement is received.

;

Tr. Code: OBPM2: Asper standard format, Note to Payee lines in XML tag can take only 4 referenceAtoms that are available (32 * 4 = 128 characters separated by /) under XML node. Hence for each vendor, four invoice numbers can only beaccommodated in the unstructured field which may not be sufficient for vendorsin getting remittance information details in their Account statement. It takesthe details based on the above Note to payee text format (Typ 1) line:&FPAYP-XBLNR&

Tr.Code: OBPM1

;

This change is called in the following node in the DMEE file:

4.2.1.2 Reference to betransferred without grouping

If grouping is not done, data is transferred withindividual invoice references. Hence note to payee length is not a challenge asit is enough to accommodate 18 character length as the invoice reference.

4.3 Country specific changes   4.3.1 Spain

Non-resident vendors can be determined based on firstthree characters from their VAT Reg. No. "ESN" or Tax number containspattern N* in vendor master control segment. Conditions can be maintained inRegulatory reporting XML tag where amount is greater than 50,000 Euros andVendor Tax or VAT registration number contains pattern N* or ESN*. Hence thefollowing condition.

;

4.3.2 Belgium

Initiating party ID needs to be mentioned as constantKBO-BCE for Belgium

4.3.3 France

For French beneficiaries,there is no sort code (it does not exist & sort code is just for UKdomestic payments and on 6 digits Explained below). The details as below:

Sample as follows:

CCFRFRPPXXX

Regulatory Reporting codeneeds to be mentioned as constant 152 for France where Payer is in France andPayee is outside France

Structure in the DMEE output file will appear as

Note: Null tags and empty tags are not allowed even on theaddress field => This involves the rejection of the whole file. Such Tagshave to be removed (or fill in) from the file.

;

5. XMLSEPA extension as Global format5.1 GeneralConsiderations

XML pain.001.001.02 for SEPA EURO payments and xml iso pain.001.001.03 forNon EURO payments. Thus to facilitate the XML format as Global, it is requiredto have the header as follows :

Sampleoutput at Header

 - f

;

To sum-up: - with pain.001.001.03, it is possible tosend SEPA and non SEPA payments - with pain.001.001.02, you can only sendSEPA payments

5.2 IfBeneficiary Bank has IBAN

If IBAN is found in the Beneficiary bank account, the IBAN is printed viathe structure in the Payment file. If not, BBAN (Basic Bank Account Number) isgenerated via the user exit

Output is:

5.3 If Beneficiary has No IBAN User exit

Conditions are put in place to check IBAN, and if blank under segment: Othr,User Exit is triggered. It is required to concatenate Bank Key and accountnumber of the beneficiary under segment Id.

Further, display the above generated numbers as the values are related toBBAN (Basic Bank Account Number)

under the SchemeNm as shown:

Also, Beneficiaries without IBAN number outside Europe, but with BIC codeand / Beneficiary Bank country same as Postal address country structure shouldappear as:

If the Beneficiary Bank country same as Postal address country but withoutIBAN and without BIC code, the structure should appear as:

Note: The tag for french regulatory reporting is mandatory to show in DMEE file

It is required to note that, the country of thebeneficiary bank is included in the swift BIC code. In case the swift BICcode of the bank is not included, you will have to include the name and addressof the bank of the beneficiary. Hence, the structure should appear as follows:

;

If the Beneficiary is in EURO zone and needs to be paidby multiple currencies, the challenge is to segregate and group the EURO (SEPARelevant) and NON-EURO payments.

SAP provides with the option to control the structure andgroup in relation to the currency. Under the segment in Header node, we cancontrol via the Key field as Transaction currency. Screen shot below shows whatneeds to be maintained under DMEE tree.

5.4 DKKPayments in Denmark

Payment type Information section for Denmark should beupdated with segment Prtry (proprietary code) with DO as follows.

This is a proprietary code which is mentioned to indicate that it is aspecific domestic payment. It allows to identify that the payment is a FIK/GIROpayment.

;

Sample as follows:

NORM NURG DO

;

;

5.5 SEK Payments in Sweden

;

For SEK Payments, OCR Reference text is mandatory. This reference should appear in TAG remittance info unstructured . It is important to populate ONLY with the OCRreference.Sample as follows:

 ;  /OCR/ reference text  

The Regulatory reporting forSweden is applied for all cross-border payment and when the beneficiary is anon-resident and for amount over 150,000 SEK (or equivalent) and has to bestructure as the following one. You have to change as below

;

Sample as follows:

101 where 14 is the value of thereason code.

;

And the country of residence of the beneficiary has to bepopulated in the address section fo the beneficiary as below

LABORATORIOS ABC QUIMICA,

 CO

 Apdo. 11111

 11123 BOGOTA Colombie

CO

;

5.6 NOK Payments in Norway

KID Number in Norway

Domestic standard KID number is maintained during invoice posting. Thisshould be populated during payment file creation to send the reference of theinvoice against each payment.

;

It is important to populate only with /KID/ + KIDreference

Sample as follows:

  

/KID/2023128155

;

The Regulatory reporting forNorway is applied for all cross-border payment and has to be structure as thefollowing.

;

Sample as follows:

5.7 GBP Payments in UK

The Clearing code for UK domestic payments has to bepopulated. It concerns only domestic payment and then it is to apply on thepayments of the first instruction (PmtInf) only. You have tochange as below

;

Sample as follows:

 

 YORKGB21568

 

 

  GBDSC

 

 050568

 

 

the value (050568) is a part of the IBAN (position from character 9 on 6characters)

;

5.8 USD Payments in US

It isnecessary to understand the types of USD payment based on the beneficiarycountry and bank country.

BeneficiaryCountry

A. Bene. Bank country

Currency

Type ofTransfer

US

US

USD

ACH >> CCD or PPD

SG

US

USD

ACH >> CCD or PPD

SG

SG

USD

NON ACH, can beUSD Wires (499)

SG

CN

USD

NON ACH, can beUSD Wires (499)

  ; ** CCD: Corporate Payments, PPD: Personal payments

Type of transfer should appear under tag Cd as follows:

 For any USD localpayments, service level code is NURG as follows

;

 NURG

;

 For any USD foreignpayments, service level code is URGP as follows

;

Sample as follows:

1000457118

TRF

false

3

950.00

 URGP

2014-07-06

;

Also, the formatting for the debtor accounttag should be

;

Sample as follows:

-

-30XXXX84

-

 BBAN

USD

;

6. Related Content

;

For more information for DMEE payment structure and configuration details,visit SAP help: http://help.sap.com/saphelp_46c/helpdata/en/cb/d82f3885b6097ae10000009b38f889/frameset.htm

;

7. Disclaimer and Liability Notice

;

This document may discuss sample coding or other information that does notinclude SAP official interfaces and therefore is not supported by SAP. Changesmade based on this information are not supported and can be overwritten duringan upgrade.

1818Views

Average User Rating

5

(5 ratings)

inShare0

Comments

2 Comments

Darshana Penta Jan 9, 2015 7:39 AM

A very deatiled and useful document. Thanks!!

Like(0)

TanguyMuffat Jan 30, 2015 3:44 PM

Hello Srinvasa,

Tahnk you for this document highlighting all those pointsof consideration.

Something you do not mention - Do we have to maintaininstruction key somehow ?

Like(0)

Name

Email Address

Website Address

Name (Required)

Email Address (Required, will not be published)

Website Address

Site IndexContact UsSAP Help PortalPrivacyTerms ofUseLegal DisclosureCopyright

Jive Software Version: 5.0.6.2 , revision:201308121150.54f5b14.release_5_0_6_2

$j(window).load(function(){if (jive.ActivityStream && jive.ActivityStream.TabCountsControllerMain){jive.ActivityStream.TabCountsController = new jive.ActivityStream.TabCountsControllerMain({pollingEnabled: true});}});SCN_files/sa