2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 1/24

Getting Started Newsletters Store   

Products Services & Support About SCN Downloads

Industries Training & Education Partnership Developer Center

Lines of Business University Alliances Events & Webinars Innovation

Log On Join UsHi, Guest Search the Community

Activity Communications Actions

Browse

0 Tweet 0

created by hemachandra Srinvasa on Sep 8, 2014 4:38 PM, last modified by hemachandra Srinvasa on Sep 9, 2014 7:20 PM

Applies toSAP ERP 5.0 / 6.0 with the focus of One XML format for global payments including SEPA SummaryThe purpose of this document is:

To provide possible country specific requirements (Europe and Americas) used at Banks toextend the XML format

Development highlights to extend XML format as Global format It is necessary the consultant is aware of all the basic settings of the Automatic payment process.This document is only focused on the creation of complete structure of payment file in XML formatwith the use of SAP standard template SEPA_CT. 

Table of Contents1       Introduction. 2       Benefits of using XML format as Global format 3       General Configuration. 

XML as Global Payment file

Share 0Like

Version 1

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 2/24

4       XML SEPA Country specific Configuration.4.1        Rules to determine a SEPA Payment4.2        General Considerations: All EU – SEPA countries.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. 5       XML SEPA extension as Global format5.1        General Considerations.5.2        If Beneficiary Bank has ‘IBAN’5.3        If Beneficiary has ‘No IBAN’ – User exit5.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. 6       Related Content 7       Disclaimer and Liability Notice.  

1  Introduction

This document aims to understand and to use the XML format as Global format including SEPArequirements / Transactions. To start, SAP’s standard  template SEPA_CT for Credit Transfer  is used. The basic  requirementsand  technicalities  to  generate  the  payment  file  takes  into  consideration  the  requirement  of  EPC(European Payments Council) The EPC rulebooks contain the business requirements and rules for the operation of the SEPA. Theimplementation  guidelines  specify  the  SEPA  core  requirements  that  apply  to  the  UNIFI

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 3/24

(ISO20022) XMLstandards  and  cover mandatory  banktobank messages  and  optional  recommended  customertobank messages.

2  Benefits of using XML format as Global format

Converging to SEPA requirements, hence in line with the legal requirements

Less maintenance cost for the company

Adaptability and flexible to accommodate any future changes  either by Financial institutionsor by business

Highly Secured

3  General Configuration

Standard SEPA_CT for credit transfer cannot be used unless changes are adopted as per the bankand  country  specific  requirements.  It  also  depends  on  the Beneficiary Bank  details, Currency  ofpayment and Beneficiary bank country. A new format can be created as  there are no formats available  for a specific bank/ country. Thiscustomization can be either done through modifying the standard function modules of an existingPMW  (Payment Medium Workbench) format or through developing via Data Medium ExchangeEngine (DMEE). (However this document does not deal with customizing through DMEE). 

4  XML SEPA Country specific Configuration ¨

 4.1 Rules to determine a SEPA Payment

·      Data Format

Ordering and beneficiary accounts have to be in IBAN format

BIC is required for both ordering and beneficiary parties 

       How recognize a payment elligible for SEPA·      The following are few of the rules to make SEPA Credit Transfer:

The transactions have to be in Euro

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 4/24

The Debtor and Creditor must each hold an account with a Participant located within theSEPA

The transfers have to be in the SEPA area. The SEPA area comprises the following countries:      o   EU : Eurozone countries:          Austria, Belgium, Cyprus, Estonia, France, Finland, Germany, Greece, Ireland, Italy,Luxemburg, Malta, Netherlands, Portugal, Slovakia, Slovenia          and Spain     o   NonEU : nonEuroZone countries Bulgaria, Croatia, Czech Republic, Denmark, GreatBritain, Hungary, Latvia, Lithuania, Monaco, Poland,          Romania and Sweden 4.2 General Considerations: All EU – SEPA countries

SAP  Standard  template  SEPA_CT  to  be  copied  as  a  base  template  with  the  necessary  namingconvention. Path: SPRO      IMG      Financial Accounting (New)     Accounts Receivable and AccountsPayable Business Transactions       Outgoing Payments     Automatic Outgoing Payments     Payment Media    Make Settings for Payment Medium Formats from Payment 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 – Fig 1. This will copy allthe standard segments of XML format used in payment file. 

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 5/24

The output structure of standard DMEE file is as shown below  Fig 2

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 6/24

 Important Considerations

In the Payment file, a swift BIC code can be on 8 or 11 characters. i.e., for example you canindicate  in  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  setup  to  SLEV  for  SEPA payments.  This  indicates  toBank  that  default  charges  setup  will  be  applied  and  is  born  by  the  debtor.  Other  chargesavailable for NON SEPA payments are : CRED, DEBT and SHAR.

For example, in Denmark, default charges are shared. You can force charges to what you wantby  specifying one of  the  following values: SHAR or DEBT or CRED. This depends on  theBusiness agreement with Beneficiaries.

If  the  Payment  is  SEPA  relevant,  it  is  always  mandatory  to  have  the  Payment  typeinformation as follows:

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 7/24

<PmtTpInf>    <SvcLvl>          <Cd>SEPA</Cd>

               </SvcLvl></PmtTpInf>

Batch booking option.

§  If batch booking= true. The bank statement will mention a global debit of theinstruction.

§    If  batch  booking=  false. The  bank  statement will mention  the  details  of  alltransactions within the instruction.

Sample as follows:

 4.2.1 Invoice reference in Payment fileBased on the Business requirements, either the payment can be executed by grouping the invoicesper vendor & currency or can be separated per invoice.  Thus with the following changes in SAP,invoice references can be transferred in the Payment file4.2.1.1 Group of invoices paid per Vendor & CurrencyIf  the  invoice  is grouped per Vendor & Currency with multiple  invoices  to pay,  it  is  required  tocapture  all  the  invoice  references  in  the  payment  file.  This  is  required  as  this  will  serve  as  thereference to the Beneficiary when the Account statement is received. Tr. Code: OBPM2: As per standard format, Note to Payee lines in XML tag can take only 4reference Atoms that are available (32 * 4 = 128 characters separated by “/”) under <Ustrd> XMLnode. Hence for each vendor, four invoice numbers can only be accommodated in the unstructured

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 8/24

field which may not be sufficient for vendors in getting remittance information details in theirAccount statement. It takes the details based on the above Note to payee text format (Typ 1) line:&FPAYPXBLNR&

Tr.Code:  OBPM1 

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

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 9/24

4.2.1.2  Reference to be transferred without groupingIf grouping is not done, data is transferred with individual invoice references. Hence note to payeelength  is  not  a  challenge  as  it  is  enough  to  accommodate  18  character  length  as  the  invoicereference. 4.3  Country specific changes                                                            

4.3.1 SpainNonresident vendors can be determined based on first three characters from their VAT Reg. No."ESN" or Tax number contains pattern “N*” in vendor master control segment. Conditions can bemaintained  in  Regulatory  reporting  XML  tag  where  amount  is  greater  than  50,000  Euros  andVendor  Tax  or  VAT  registration  number  contains  pattern  N*  or  ESN*.  Hence  the  followingcondition.

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 10/24

 4.3.2  BelgiumInitiating party ID needs to be mentioned as constant “KBOBCE” for Belgium

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 11/24

4.3.3  France·                 For French beneficiaries,  there  is no  sort  code  (it does not  exist & sort  code  is  just  for UK

domestic payments and on 6 digits – Explained below). The details as below: Sample as follows:<FinInstnId>   <BIC>CCFRFRPPXXX</BIC></FinInstnId> 

·         Regulatory Reporting code needs to be mentioned as constant “152” for France where Payer is inFrance and Payee is outside France

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 12/24

Structure in the DMEE output file will appear as

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

5. XML SEPA extension as Global format

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 13/24

5.1 General Considerations

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

      Sample output at Header     <?xml version="1.0" encoding="utf8" ?>

             <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"xmlns:xsi="http://www.w3.org/2001 /XMLSchemainstance">f To sumup:         with pain.001.001.03, it is possible to send SEPA and non SEPA payments         with pain.001.001.02, you can only send SEPA payments

5.2 If Beneficiary Bank has ‘IBAN’

If IBAN is found in the Beneficiary bank account, the IBAN is printed via the structure in thePayment file. If not, BBAN (Basic Bank Account Number) is generated via the user exitOutput 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 istriggered. It is required to concatenate Bank Key and account number of the beneficiary undersegment Id. 

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 14/24

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 15/24

Further, display the above generated numbers as the values are related to BBAN (Basic BankAccount Number)under the SchemeNm as shown:

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 16/24

Also, Beneficiaries without IBAN number outside Europe, but with BIC code and / BeneficiaryBank country same as Postal address country structure should appear as:

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 17/24

If the Beneficiary Bank country same as Postal address country but without IBAN and without BICcode, the structure should appear as:

Note:  The tag   <Ctry> for french regulatory reporting is mandatory to show in DMEE fileIt is required to note that, the country of the beneficiary bank is included in the swift BIC code.  Incase the swift BIC code 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: 

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 18/24

If the Beneficiary is in EURO zone and needs to be paid by multiple currencies, the challenge is tosegregate and group the EURO (SEPA Relevant) and NONEURO payments.SAP provides with the option to control the structure and group in relation to the currency. Underthe segment in Header node, we can control via the Key field as Transaction currency. Screen shotbelow shows what needs to be maintained under DMEE tree.

5.4 DKK Payments in Denmark

Payment type Information section for Denmark should be updated with segment Prtry (proprietarycode) with ‘DO’ as follows.

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 19/24

This is a proprietary code which is mentioned to indicate that it is a specific domestic payment. Itallows to identify that the payment is a FIK/GIRO payment. Sample as follows:  <PmtTpInf>     <InstrPrty>NORM</InstrPrty>     <SvcLvl>      <Cd>NURG</Cd>     </SvcLvl>     <LclInstrm>     <Prtry>DO</Prtry>     </LclInstrm>    </PmtTpInf>  5.5 SEK Payments in Sweden

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

     <RmtInf>                                     <Ustrd>/OCR/ reference text</Ustrd> </RmtInf>  

 ·       The Regulatory  reporting  for  Sweden  is  applied  for  all  crossborder  payment  and when  thebeneficiary  is  a  nonresident  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:</CdtrAcct><RgltryRptg>       <Dtls>            <Cd>101</Cd> where 14 is the value of the reason code.      </Dtls>

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 20/24

</RgltryRptg><RmtInf> And the country of residence of the beneficiary has to be populated in the address section fo thebeneficiary as below<Cdtr>            <Nm>LABORATORIOS ABC QUIMICA,</Nm>            <PstlAdr>                        <Ctry>CO</Ctry>                        <AdrLine>Apdo. 11111</AdrLine>                        <AdrLine>11123 BOGOTA Colombie</AdrLine>            </PstlAdr>            <CtryOfRes>CO</CtryOfRes></Cdtr> 5.6   NOK Payments in Norway·    KID Number in NorwayDomestic standard KID number is maintained during invoice posting. This should be populatedduring payment file creation to send the reference of the invoice against each payment. It is important to populate only with /KID/ + KID referenceSample as follows:<RmtInf>                             <Ustrd>/KID/2023128155</Ustrd></RmtInf>        ·    The Regulatory reporting for Norway is applied for all crossborder payment and has to bestructure as the following. Sample as follows:

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 21/24

5.7  GBP Payments in UK

The  Clearing  code  for  UK  domestic  payments  has  to  be  populated.  It  concerns  only  domesticpayment and then it is to apply on the payments of the first instruction (PmtInf) only. You have tochange as below Sample as follows:<CdtrAgt>                <FinInstnId>                                <BIC>YORKGB21568</BIC>                                <ClrSysMmbId>                                    <ClrSysId>                                                <Cd>GBDSC</Cd>                                    </ClrSysId>                                    <MmbId>050568</MmbId>                                </ClrSysMmbId>                </FinInstnId></CdtrAgt>the value (050568) is a part of the IBAN (position from character 9 on 6 characters) 5.8  USD Payments in US

·       It is necessary to understand the types of USD payment based on the beneficiary country and bankcountry.

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 22/24

BeneficiaryCountry

A. Bene.Bankcountry

Currency Type of Transfer

US US USD ACH >> CCD or PPD

SG US USD ACH >> CCD or PPD

SG SG USD NON ACH, can be USD Wires (499)

SG CN USD NON ACH, can be USD Wires (499)

                                                  ** CCD: Corporate Payments, PPD: Personal payments

Type of transfer should appear under tag Cd as follows:

For any USD local payments, service level code is NURG as follows <PmtTpInf>          <ScvLvl>                   <Cd>NURG</Cd>          </SvcLvl> 

For any USD foreign payments, service level code is URGP as follows Sample as follows:

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 23/24

<PmtInfId>1000457118</PmtInfId><PmtMtd>TRF</PmtMtd><BtchBookg>false</BtchBookg><NbOfTxs>3</NbOfTxs><CtrlSum>950.00</CtrlSum>   <PmtTpInf>          <ScvLvl>                   <Cd>URGP</Cd>          </SvcLvl><ReqdExctnDt>20140706</ReqdExctnDt> Also, the formatting for the debtor account tag should be Sample as follows:<DbtrAcct><Id> <Othr><Id>30XXXX84</Id>   <SchmeNm>

           <Cd>BBAN</Cd>     </SchmeNm></Othr></Id>

 <Ccy>USD</Ccy></DbtrAcct> 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 not include SAP official

2/18/2015 XML as Global Payment file | SCN

http://scn.sap.com/docs/DOC57923 24/24

Follow SCNSite Index Contact Us SAP Help PortalPrivacy Terms of Use Legal Disclosure Copyright

Average User Rating

(5 ratings)

0 Tweet 0

interfaces and therefore is not supported by SAP. Changes made based on this information are notsupported and can be overwritten during an upgrade.

1194 Views  

Share 0Like

2 Comments

Like (0)

Darshana Penta Jan 9, 2015 7:39 AM

A very deatiled and useful document. Thanks!!

Like (0)

Tanguy Muffat Jan 30, 2015 3:44 PM

Hello Srinvasa, Tahnk you for this document highlighting all those points of consideration. Something you do not mention  Do we have to maintain instruction key somehow ?