Showing posts with label Payment Medium Workbench. Show all posts
Showing posts with label Payment Medium Workbench. Show all posts

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

Aug 12, 2020

How to do (print) physical Checks with SAP S/4 HANA the new / right way !

For many of us that have been around for a while in the SAP Finance world, designing Checks is a constant on every project. I lost count how many Checks I have designed and implemented over the last 11 years, but I can tell you, I know quite a bit about it and have done it many times. I have designed Checks for Small, Medium and Large companies in Canada and in the US too. (For you guys in Europe, Checks are something of the past since 2014 and the introduction of SEPA, lucky you !).

I am also writing this as I have been asked several times by different colleagues on how this should be done in S/4 HANA as not a lot of Consultants know this already and have upgraded their skills to S/4.

So ... As many of you know by now (if not you should not be doing SAP anymore), things have changed in S/4 HANA (for the better) compared to the tools and ways of implementing Checks in ECC6.0 and before.

Developers have new tools to design FORMs like Adobe Forms with Adobe Lifecycle Designer that you should use instead of the old SAPScript. It is lot easier, faster, more user friendly and gives you a lot of flexibility to implement custom code.

So ... now, How should you be doing checks in S/4 HANA the new and right way ?

There are a couple of things that you should consider now in S/4 HANA. By now, you should not be deploying anymore the old SAP GUI logon Pad. There are certain exceptions, but you should deliver the new UI which is SAP Fiori. With that it comes a lot of new Apps that have been built for Finance. Among those you will find "Manage Automatic Payments" that replaces to old Automatic Payment Program Tcode F110. 

The new "Manage Automatic Payments" App is more user friendly, more intuitive and have lost several of the technical non-sense things that an end-user needed to select in order to issue Payments in SAP. I never understood why they made it so complicated for the end user (well it's SAP ...). 



Now the Tab "Printout/data medium" is gone from the Fiori App, you do not have access anymore to that Tab. It just does not exist in Fiori such an option to select what variants you will be using for each program. Instead you should be using the new Standard delivered Payment Medium Workbench (PMW) CHECK.

You cannot use anymore the old and traditional program RFFOUS_C (or any similar variant of it). Also, you cannot use the traditional Funds Transfer / Electronic payment program RFFOUS_T and you should be using the PMW and build a DMEE for Electronic Funds Transfer instead.  This is "IF" you want to use the new Fiori App, if you don't and you still want to use the old F110, then those programs will still work in S/4 HANA. But why would you want to keep on using it if you have a new one ? Would you keep driving your old car with no AC, no power windows and no power steering wheel ? Well, I don't !!!

Not long ago, I went into a client who was running S/4 (greenfield implementation) and saw that they were using the traditional RFFOUS_C Print program. In fact, they took a copy of the program and they customized and put their own code inside it. This is something that we all used to do in the old ECC days, but we should not do this anymore. (See below what we should not do anymore).

Unless you have a compelling technical reason for using the old Print Program, then I see this as poor knowledge and lack of skills from the Consultant that implemented this solution. Which it wouldn't be the first time I see someone that lacks the technical knowledge doing something like this ...

 

As I mentioned before, YOU SHOULD STOP USING RFFOUS_C and start using the new SAP Standard delivered Payment Medium Workbench CHECK to be able to print Checks.

Another thing you should STOP doing is using SAPScript to design your Check Form layout. The new way in S/4 and new tool is Adobe Forms (not Smartforms). SAP Delivers a Standard form that you should take as a reference and design your own as per your business requirements. 

Adobe Lifecycle Designer will allow your Developer to meet 100% of your Business requirements Layout and add any type of custom code needed to retrieve any extra information that could be required to be printed in the form that is not yet available . No more copying the Standard program and modifying it so then the SAPScript form has access to new information. That is not needed anymore with this new technology. A good and up-to-date Abaper will know what I am talking about. (It is not the purpose of this post to explain that and I am not an Abaper either).

After you have configured the use of the Payment Medium Workbench CHECK and have developed your custom Adobe Form, you should add it in the configuration. After that your config should not have this setup anymore.

In the line "Form for the Payment Medium" you should select PDF and enter your PDF Form name there instead of SAPScript.

After that you need to configure your Variants in Transaction OBPM4.


There you will create a Variant which will allow you to select your Check Printer among some other things.

As you can see, it is not complicated, you just have to know how to do it and your SAP Finance Consultant should have up to date knowledge too.

I am putting as a reference 2 OSS Notes that explain part of this new setup and gives you a possibility of using the Old programs if you still want. But I would not recommend it, it is not the way to go these days and I suspect that eventually SAP could close that door in subsequent versions.


Note: The described procedure and screens belong to S/4 HANA On-premise.


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.

Reference OSS Notes:


2794915 - No "Printout/data medium" tab in "Manage Automatic Payments"
https://launchpad.support.sap.com/#/notes/2794915


2418837 - Manage Automatic Payments: Add Support for Classic Payment Medium Programs
https://launchpad.support.sap.com/#/notes/2418837