Showing posts with label Electronic Payments File. Show all posts
Showing posts with label Electronic Payments File. Show all posts

Apr 11, 2023

Some banks can't deal with characters with accents and special characters, how to remove them with no-code ...

Recently, while doing a banking implementation with a US bank, I run into an issue that never had before. It caught my attention and thought it was worth sharing it because it is quite specific that I am sure it is going to benefit someone.

I was doing payment files testing with a US Bank (a really big one) for my client's US and Canadian operations and because my client also operates in the province of Quebec, Canada (where we also speak French); we run into some particular issue because we have data with French accented characters. 

It is really common in the French language to have accents on people's name, streets and companies too. But this bank's systems where not able to handle and read our files because of this "special characters / strange characters". Many times bank's systems are so antiquated that they are still running mainframe servers that were conceived in the 80's easily. Many of this servers and operating systems do not have the ability to handle some of this characters and even had a complete different code page too. In some of this cases, since we were passing them ASCII files (as per their request), their systems were not interpreting these characters and adding an extra space to the line record. This was making the record longer and therefore failing.

These are some of these "special characters" (Ex, À Á Ã È É Ê Ì Í Ò Ó Ô Ù Ú Û à á â è é ê ì í î ò ó ô ù ú û ).

Now there are 2 different scenarios that I had where I needed to remove this special characters, one without code and another one with.

# 1 - DME file creation (Ex. Electronic Payments, Positive Pay or any type of Banking file)

#2 - Check printing


# 1 - DME file creation

In this scenario we were creating 2 different types of files for this bank, an ASCII Positive Pay file and an XML ISO 20022 payment file. The ASCII one was the one that the bank was not able to process properly. 

In order to remove the 'special characters' on the DME file, you just need to flag one option on the corresponding field and the DME engine will take care of the rest.

Ex. I want to remove the 'special characters' from the Vendor Name (PayeeName1 field in my DME) that is part of the output file.


Select the Field name (Element or Atom) and click on the "Conv.Function" icon. You will get a pop-up like this one (see below).



Here you have a series of options to right justify or left justify your characters. Then on the 2nd part, you have the option "Replace National Chars". This option will allow you to replace these series of "accented" characters by no accented ones by executing a standard FM behind the scenes. (which opens the door to talk about my option #2).


#2 - Check printing

I mentioned that the output file was related to Positive Pay, so in this case, we needed to have a exact match file vs. printed check otherwise the bank was going to reject our checks. So, we also needed to adjust our check forms so that the printed names do not have these accented characters either. 

To do this, we will be using the exact same Function Module that is available in the DME engine, but in this case calling it via code.

FM SCP_REPLACE_STRANGE_CHARS


You can test it here to see the results before incorporating it in your code.


Here you will see how in the Input text I put all sort of accented characters and the FM returned all the same characters but without accents. The same can be executed in your forms or any other Abap program to remove these characters.


Bonus track ...

You can also use program RSCP0155 that has a selection screen where you can play with more sophisticated options like input and output code page and range of Unicode characters. Then this selection screen will end up executing this same FM and returning all the input characters and converted characters for the whole ASCII code. So you can see upfront what your characters will look like after conversion.



Part of this Post is based on OSS Note 
1062237 - Transliteration of characters with SCP_REPLACE_STRANGE_CHARS

(requires a valid SAP Marketplace ID to display the Note) 



If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.


Dec 15, 2020

Electronic Payment standards in SAP

In this article, I will explain how the Electronic Payment Process works, how you can configure it in SAP and what are the different electronic payment file standards used in North America and Europe.

First we will start by explaining what the Electronic Payment Process is about.

Some countries, banks and/or companies would call this Electronic Funds Transfers (EFT), some Electronic Payments, Electronic Payment Orders, Payment Initiation and so on ... But they all refer to the same process.

Now a days, companies instead of issuing a physical check to pay their bills, they have the possibility of issuing Electronic Payments. The process starts when a company executes a payment, with that payment their ERP system (SAP, Oracle, MS Dynamics, Netsuite, etc.) creates a file that contains all the necessary information for the bank to process it and issue a payment to their vendor. The Bank receives this file, reads it and selects all the payments contained inside and sends it to the Clearing / Settlement Entity for its processing. This entity works exactly the same as in the past for check clearing, but process electronic payments instead.  Then the payments are sent to the Payee/s bank/s which process them and deposits the funds in the Payee/s / Vendor accounts.

Depending on the country you are in, the country's Banking System will operate differently in terms of Electronic Payment file standards. And even within the same country, banks could be using different standards as well or adapt / tweak them to their own needs. Some could still be using old file format standards or some could have implemented newer and more technological advanced standards already. Requirement need to be analyzed on bank by bank basis.


SAP covers the majority of the main electronic file formats in an standard way. That does not mean they fit 100% as per your bank's requirements. But normally 90% of the standard is covered and you are left with some tweaking to do and be 100% compliant with your bank. The problem is that Banks rarely adhere 100% to the standard and they modify it to suit their own needs. SAP delivers the standard as per the industry. 

For example, in the case of SWIFT ISO 20022 standards, SAP is one of the founding members of the board that designed the standards for the industry. So compliance with the standard is guaranteed.

These are some of the most important electronic file standards in different countries / markets:



You will be able to use each of these standards by selecting them in the Payment Medium Workbench field in the Automatic Payment Program configuration (FBZP) for "Payment Method in country".

Each of these standards have their own particularities and minor extra configs that might be needed and could easily be the subject of a Blog posting on its own.



Contrary to what we used to do in the past, you do not need to use the "classic payment medium programs" RFFO* anymore, all of the standards are now present via the PMW. (See my previous Blog posting on the subject for the explanation).

After this you will do your config for "Payment methods in Company Code" and "Bank determination". Finally, you have to complete your config in OBPM4 (As described too in the previous posting).

Now depending on your bank's requirements, you might have to do some modifications by using the DMEE or DMEEX, which requires you to have a prior expertise using this tool. In my experience, execpt for ACH in the US, one way or the other I always ended having to do tweakins and adapting it to my bank specific requirements. But always starting from SAP standard delivered formats.

Once the configuration completed you will start your testing. For this purpose you can use Fiori Apps "Manage Automatic Payments" which is the equivalent of F110 and if you need to access and download the created file, you can use "Manage Payment Media" Fiori App that replaced FDTA.

At this point, testing with the bank can start as your main configuration is completed. Testing with the banks is a complex, long and bureaucratic process that by no means you should underestimate how long it will take you. In my experience, this is something that should be started as early as possible in any implementation process.


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Some sites for references:

https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/swift/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/sap-idoc/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/ansi-x-12-edi/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/edifact/

https://www.iso20022.org/iso-20022-message-definitions