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.

www.dnabusinessconsulting.com

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

My SAP WIP Calculation is not working properly ? Common mistake

If you are an SAP Consultant working in CO - Controlling, you probably worked or will work eventually in a Production / Manufacturing environment where at Month End you will have to Calculate WIP (Result Analysis in SAP language) either in Production Orders or in Cost Collectors.

So for that you will have to configure the whole Result Analysis functionality and the whole nine-yard. You also need to make sure that your Cost Objects (Production Orders and/or Cost Collectors) are getting assigned the proper configured Result Analysis Key.

But ... even with all of that, your WIP calculation might not work correctly. 

I have been called in the past by several clients to help solve WIP Calculation issues in SAP and was surprised with what I found.

I went to a client once (Dairy products manufacturer) that every month they would do a Journal Entry of around $ 1.5 million to reverse WIP from their Balance Sheet on a constant basis. They were desperate because that JE was taking them a lot of time and also month by month was constantly growing and never going down. It was a snow ball out of control.

After that client, I went to another one (Pharma) that had a similar situation, but their numbers were so big that they never realized of the situation and they never did anything like the other trying to offset it with a manual JE.

Some consultants (or most) configure the functionality, do a little bit of testing and integrated testing during the course of the project and they stick around for 1 or 2 months after the go-live. But the real effect of this issue is not known and seen until a couple of months down the road and by that time the consultant is long gone to his next project / client.

To calculate WIP the system uses the Cost Object Status to determine if it has to calculate WIP or not. All costs accumulated in a Production Order at month end, will be considered WIP if the order has not been set to TECO - Technically Completed or DLV - Delivered. If the order is in one of those 2 statuses, then the system will cancel / reverse the WIP calculation or not calculate WIP at all and that will create a JE posting at the time of Settlement.

So, What was wrong with the WIP Calculation of this clients ???

It was something so simple but at the end something that not a lot of consultants knew.

For you to know all the necessary Month-End steps that need to be done, it is always recommended to explore the SAP Menu in case you do not know all the steps by hard or have them properly documented.

Within the Month End functions for WIP, the very 1st one is the establishment of the Cutoff Period. If you do not do this one properly, then your whole WIP calculation will not be accurate and you will end up in the same situation that I described for some of my past clients. 

The Cutoff period is key for the WIP calculation, as it establishes the period until WIP should consider the Orders in an open or close period. Consider it like the FI period (OB52) but for WIP, not literary.

The Cutoff  should be defined as the period preceding the results analysis period. Ex. If you are doing the Month-End close for 2020-07 (July), then your Cutoff period should be 2020-06. In a sense, is closing period minus 1.

The Cutoff period should always be for RA Version 0, which is the one that is used for Accounting purposes.

Once you set this value properly, your WIP calculation will work well and reverse WIP when it should. This needs to be done every month before starting to run any of the month end closing activities. 

In the case of my clients, I was astonished with what I found because they had values like 1990-01, which is the value that comes out-of-the-box with SAP when you 1st installed it. That showed me that no one ever opened and changed this value. Therefore their WIP calculation never worked to reverse WIP. It accumulates in the Balance Sheet but it never reverses it. For one of them, this Transaction was not even part of their Security roles, which shows me nobody knew and thought about it during the project.

After setting up the proper Cutoff period value, you will continue with the normal steps WIP, Variances and finally Settlement.

*** On a side note about this subject, now in S/4 HANA we do not have the SAP Menu as we used to have were you would find all the steps. Instead, we have the Fiori Tiles and we need to know the right steps and order of execution. But for unknown reasons, SAP has not delivered any Fiori Tile for this Cutoff period (Tcode KKA0) nor is included in any standard catalog. So you will have to ask your Security team to build a Fiori Tile out of a GUI Transaction so then can be added to a Catalog and a Role for execution within the Fiori Launchpad.

If someone knows this reason, please let me know. I am curious to know why. Is it related to S/4 changes that they have done ? Never read anything in the Simplification Notes about it. Also researched OSS Notes before writing this and did not find anything on the subject.

Unfortunately, there is no quick way of scheduling and automating this Tcode so it would change the period automatically. It has to be done manually prior to Month End.

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.

www.dnabusinessconsulting.com

How SAP S/4 HANA calculates GL Balances with the New Simplified Data Model ?

SAP has been around for a lot of years now and it has seen its core ERP product evolve over the last 40+ years. With it, its Data Model has been evolving too. SAP, like any other ERP and traditional Finance system, has used Total Tables to be able to calculate and provide GL Balances in the FI - Finance Module since the beginning as there was no other way to achieve this without damaging performance with the Databases that we had. Other systems have been using that approach and are still using it nowadays. Up until S/4 and the utilization of the HANA Database, the only way to obtain GL Balances was by reading Total Tables that had summarized information.

These Total Tables would be updated every time a new GL Posting happens updating not only Line Items Tables (like BSEG or FAGLFLEXA) but also Total Tables (like GLT0 or FAGLFLEXT and others too) and recalculating the corresponding total for the specific GL and Object / Dimension (like Internal Order, Profit Center, Functional Area, Cost Center, etc. ).

Then once we would run a report that would require a GL Balance (Total), the system would go directly to those Total Tables and read them from there as they were already calculated.

For Classic GL these were the Total Tables:

• GLT0 - General Ledger: Totals
• GLPCT - EC-PCA: Totals Table

For New GL this was the Total Table: 

• FAGLFLEXT - New General Ledger: Totals

On top of those Tables you would also have CO Total Tables like 

• COSS - Cost Totals for Internal Postings
• COSP - Cost Totals for External Postings

Now with the changes brought by S/4 HANA all those Tables have been eliminated.

A typical Business requirement that I have seen over and over in many projects, is to build and Interface or Custom Extraction program to Extract GL Balances at the end of the month and feed an external reporting and/or Consolidation System (Ex. Longview, Oracle Hyperion, Cognos and many more). In that case, we would build a custom program to go and extract GL Balances from the Classic or New GL Total Tables.

So, if the new Data Model introduced by S/4 HANA in Finance has eliminated these Total Tables, how is SAP providing GL Balances now ?

The 1st answer that somebody would say 

"... with the New and super performant HANA Database, it will read all the line items and calculate the Totals "on the fly ..."

Well that is not 100% accurate. It is true that SAP would read all the line items that now are part of the Universal Journal Table ACDOCA but it cannot read "all of them" ...

Imagine a system that has 5, 10 or more years worth of data. Each year could have millions of line items records. It would not be really efficient to read all those millions of line items since the beginning of time just to calculate a Total. This is something that could present as a challenge in the case of a Balance Sheet account, as their Balances are always an accumulated balance since the beginning of time. In the case of a P&L account, it is easy as their Balance are always made up of the current Fiscal Year postings only.

It is fair to say that in the case of a Balance Sheet account there is a Technical challenge in front of us as we should not be reading all line items since the beginning of time, but we still need to be able to obtain a balance without, reading all records, impacting the performance and doing it in an efficient way.

For this, SAP at year end writes initial Balance postings in the Universal Journal Table ACDOCA but with "Period 0 - zero (ACDOCA-POPER = 0)". Yes, it is a period that does not exists from an Accounting point of view, but S/4 HANA Finance uses this Period Zero as the starting point to have a "marker" to know where those balances start and not having to go back to the beginning of time to rebuild that balance every time. Period zero postings are done by the Balance Carry forward process (Tcode FAGLGVTR) when closing the Fiscal Year.

So with this Period zero being used as a starting point, then S/4 HANA Finance, reads all the current Fiscal Year line items and provides a GL Balance for those Balance Sheet accounts in an efficient way without the need to read all Balance Sheet postings since the beginning of time.

As mentioned already, any P&L balance is easy to obtain by just reading all lines items for the current Fiscal Year.

ACDOCA-POPER (Period) = 0 and

ACDOCA-BTTYPE (Business Transaction Type) = RFBC - Balance Carry Forward

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.

www.dnabusinessconsulting.com