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

Payments Advice in S/4 HANA (On-premise)

In a recent post, I was talking about how to do physical checks payments the right way in S/4. Now in this one, I will show you how to generate Payment Advices in S/4 HANA. If you read my previous post, if not you should, you will know that the Tab "printout / data medium" has been removed and it just does not exists in the Fiori App "Manage Automatic Payments" which replaces Tcode F110. So another drawback of this, is the lack of possibility to select your Program Variant to issue your Payment Advice.

But ... there is no PMW (Payment Medium Workbench) solution for this as we have for Checks. In this case SAP has "hardcoded" it (literally) in the Fiori App "Manage Automatic Payments" to look for a specific Variant Name under program RFFOAVIS_FPAYM. If you do not have this Variant in your system, no matter what you do and try, your Payment Advices will not be generated.

Up until version 1809 FPS01, you needed to create this Program Variant manually. Now they woke up and they included it out-of-the-box. So if you are working on 1610, 1709 or initial 1809 chances are that you were (or are) missing this Variant. If you have it, it might mean that someone created it already.

Variant name required and "hardcoded" is: PAYM_LC

There is even an OSS Note (2690678 - Manage Automatic Payments: Cannot Print or Send Payment Advices) that SAP released that explains the issue and what you have to do.

Reference OSS Note:

2690678 - Manage Automatic Payments: Cannot Print or Send Payment Advices

https://launchpad.support.sap.com/#/notes/2690678

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 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.

www.dnabusinessconsulting.com

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

Changing a GL Account to Open item managed in S/4 HANA

For those like me that are coming from the old Era of SAP ECC6.0 or before, we used to have 2 different Abap programs that we could run to Switch ON/OFF the Open Item Management flag out of a GL Account Master Data.

Programs

RFSEPA03  Switch OFF Open Item Management

RFSEPA02  Switch ON Open Item Management

This was really helpful because either during Project or Production Support, somehow there was always the need to Flag or Unflag a GL account in terms of "Open Item Management". With the help of those 2 programs, we were able to troubleshoot this requirement.

Now in S/4 HANA those 2 programs are obsolete and cannot be used anymore. They have been replaced by a new program FINS_SWITCH_TO_OPEN_ITEM, it even has its own Tcode too FAGL_ACTIVATE_OP or FINS_ACTIVATE_OIM.

But first to be able to have access and use this program you need to implement an OSS Note that will bring this program into your environment ( 2745769 - FINS_SWITCH_TO_OPEN_ITEM: Activation of Open Item Management ).

Once the OSS Note is Implemented, you can Execute the program.

• With this program you can either Activate or De-activate the Open Item Management of any GL Account.
• It has to be run Account by Account, you cannot execute multiple GL Accounts at the same time.
• But, you can do it for Multiple Company Codes.
• You can Switch on at a specific Date.

For the "Test run" mode you can do it online, but once you remove the Test run it needs to be executed in the Background and then you will have to review the Execution Log.

Once the program executed, you can verify you GL Account Master Data (FS00) and you will see that the "Open Item Management" flag has been removed or added to the GL record.

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

Finance Fiori Apps not working properly due to Errors in Fiscal Year variants tables

When you try to run certain Finance Fiori Apps for the fist time in a brand new environment, you might get an error message after opening the App related to the "Fiscal Year variant". This is due to some missing records in Table FINSC_PERIOD. If you look at this table for your Fiscal Year variant, most likely you will not have any records for it.

As per OSS Note 2268557

" ... In some Fiori Apps like the "Trial Balance" or in apps using the Date Picker component, information about the fiscal calendar date or the fiscal year periods is used. This information is taken from the tables FINSC_FISC_DATE and FINSC_PERIOD or the CDS views I_FiscalCalendarDate and I_FiscalYearPeriod. At the moment these tables have to be filled manually by executing the report FINS_GENERATE_FISCAL_PERIOD. Additionally they will later be filled automatically by the balance carried forward ..." (As per OSS Note 2268557)

So you will have to execute Program FINS_GENERATE_FISCAL_PERIOD to fix this issue. The program will analyze the Fiscal Year variant that you input  (+ some other parameters) and will write records in Table FINSC_PERIOD. After that, your Finance Fiori apps will not give you an error anymore.

Under normal circumstances, this Table FINSC_PERIOD is supposed to be filled by the Balance Carry Forward program (FAGL_GVTR), but if you are in an environment where you have never run the Balance Carry Forward before, this Table will be missing those records. So you have to a program to fix it manually.

As usual, to run a program. Go to Tcode SE38 / SA38 and enter the program name and Execute. (Note: this program has its own Tcode too OB_FCAL)

These are the options that you need to put in Program FINS_GENERATE_FISCAL_PERIOD.

1. Your Fiscal Year Variant (Ex. Z1).
2. Fiscal Year (Actual Fiscal year).
3. Offset before Fiscal Year (how many FYs you want to go in the past to write this records).
4. Offset after Fiscal Year (how many FYs you want to go in the future, I recommend at least 50 years).
5. Execute.

 

After executing, Table FINSC_PERIOD will have new records for your Fiscal Year variant (Ex. Z1) with 1 record per Fiscal Year period (month) indicating the exact Calendar Date for the Start and End of the Period among some other Data.

As mentioned before these records will be used by some Fiori Apps and will also be used in Analytics in CDS Views as well.

OSS Notes 

2268557 - Provide information about the fiscal calendar date and the fiscal year periods

2754943 - Trial Balance Fiori App showing incorrect values for year-dependent fiscal year

2456976 - CDS-View FCML_REP_V Beginning Inventory for periods w/o MLRUNLIST

Finally in case you need to clean up the values in Table FINSC_PERIOD, OSS Note 2734266 has a clean up custom code delivered by SAP to delete those records so you can run the generation again.

Give this OSS Note to an Abaper so he can create the Custom delivered program for you to rund it (ZCLEAN_FISCAL_TABLES).

Why would you want to do something like that ? I will tell you a real life anecdote.

My client had a FY Variant Feb to Jan but was also running 4-4-5 (Year dependent). So its own periods where also irregular and not following the calendar. Example: Period 1 instead of finishing on Feb-28, was finishing Feb-26, so Feb 27th was already part of Period 2. 

We had setup Fiscal Years already in the future for a couple of years to come, but later on during the project, their Finance organization decided to simplify their things and changed the periods to align them with the Calendar. So, after that Period 1 was really finishing on Feb-28. 

Because of that we already had records in Table FINSC_PERIOD but the system was not properly determining the new Start and End dates of each period (in certain places) because it was using the old and wrong data from FINSC_PERIOD. Not in all the case was using the traditional Tables T009 and T009b to determine the Periods.

So we implemented this custom code, we executed, cleaned up the Table and re-executed FINS_GENERATE_FISCAL_PERIOD.

Ex. One of the places where we were seeing the impact of this was on "Settlements" that was determining the wrong day as it is always posting at the last day of the month any Journal Entry deriving from the Settlement process.

2734266 - Trial Balance - fiscal year tables - clean up

*Note: This issue only applies to S/4 HANA versions, it does not apply to ECC6.0.

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

Testing Vendor Payment Advices (easy & quick)

A few weeks ago, I posted a way to test the creation of Electronic Payment files for Vendor Payments in a way that you do not need to regenerate the whole Payment Run over and over every time you need to re-test.

Today I will show you a way to retest the creation of Vendor Payment Advices in a similar way to my previous post.

In this case, this technique is really useful whenever you are developing your Vendor Payment Advice Form and you have your Abap developer asking you for the steps to generate the form. In this case, it will be hard for him to generate data for Vendor Invoices, do a Payment Proposal, pay it and trigger the Advice from it. That without mentioning that the Business Partner - Vendor needs to be properly setup and that he does not get any errors while generating the Payment Proposal (which it is quite common). That is to much for an Abaper !!! Not that they cannot do it, but imagine that this is not the only area / module that they work on. They cannot know how to do everything in the system. Even some Finance consultants that are not that experienced have issues doing this ...

Now, considering that you have a previously created and completed Payment Run for which the system should have triggered a Payment Advice Form, you will follow my steps and be able to continuously use the same one over & over.

Go to SE38 and execute program RFFOAVIS_FPAYM

Now that we have entered into the Payment Advice Program, you will enter the "Program run date" and the "Identification feature" (Ex. 20200305 and AD001) of your previously executed Payment Run that already triggered a Payment Advice.

This will trigger the creation of the Payment Advice again and you or your Abap developer will be able to see the changes that he did in the Form. 

The Payment Advice will be generated and sent to your Spool or via email depending if you have in place the necessary development to trigger it via email. (not part of this explanation).

If he needs to do more changes, he will just go back to the Form, adjust it and then re-execute this procedure. 

With this, you or him does not need to re-generate a whole set of new data and transactions every time he needs to do some testing or adjustments.

** Note: The Paying Company Code and the payment method are not needed, you can leave it blank if you need. They were part of a previous capture that I had.

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

Testing and recreation of the Electronic payments file for the Bank

When building and testing the creation of Electronic Payment files for the Bank, you will need to go through multiple iterations in order to get it built and tested. To do that, you will normally have to run multiple Payment Runs that will create your Electronic Payment file. You will create a Payment Run, then run it complete to get a Bank file created. Then you will adjust your config again. At this point you will have to either reverse the payment and pay again the same Vendor/Invoice or select / create new testing Data. During the build process of an Electronic file, this will happen multiple times over the course of your project.

In order to avoid paying and canceling the payment or entering new data over & over, I will show you a couple of tricks and 2 different ways to achieve this.

• 1 - Run your F110 Proposal with the "Create Payment Medium" flag activated.

F110 - Proposal Schedule

When you activate the flag, after running the Proposal; the system will create the Electronic file and then it will be available for you to download and check it. Then you will go back to adjust your config, delete the Proposal and re-run it again with the same data / options. 

This way you can re-use over and over the same data without the need for any payment reversal or entering new data.

When you will go to download the file, you will see that more than one file was created for your Payment Run, as it does not delete the old one, you need to select the one with the higher sequence number.

** Note: "Start Immediately" should also be activated.

• 2 - Recreate the Electronic Payment file for an already executed Payment Run.

There is another way to do it for a Payment Run that has already been executed all the way to Payments executed / posted. This is also an excellent trick to be used in Production when for any reason your payment file needs to be recreated and resent to your bank.

When a Payment Run has been fully completed, a normal user will not be able to recreate a file by himself. He will have to reach for support and if you do not know how to do it, your 1st reaction will be to cancel (reverse) all the clearing documents paid to Vendors and recreate a new payment run. This sounds easy, but companies normally pay tens or hundreds of Vendors in a Payment Run. So doing this will cost you a lot of time an effort to do it 1 by 1.

Instead, you need a way to "just recreate the file" ...

You will go and run Program RFPAYM_RESET with SE38 / SA38

SE38 / SA38 Program execution

Program RFPAYM_RESET

You will specify your Payment Run Data and Identification and Execute it. This will unmark your Payment Run as if a file creation was never done, allowing you to create a new file again. 

But how do you trigger the creation of a new file again ? Easy ....

You will go an Execute program SAPFPAYM with SE38 / SA38

You will specify your Payment Run Data, Identification, Payment Medium Format and Execute it (same data as you entered when you did the Reset). This will recreate your Electronic File again for the same Payment run and then you will be able to download it.

When you will go to download the file, you will see that more than one file was created for your Payment Run, as it does not delete the old one, you need to select the one with the higher sequence number.

You can repeat the Reset and Create as many times as you want.

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

www.dnabusinessconsulting.com

How to add SD Partner Functions as Characteristics in COPA for Profitability reporting

There are at least 3 different ways to add SD Partner Functions in COPA that I know.

1. This one is complex and it requires Abap code and enhancements in standard SAP programs. That one is outlined by SAP in OSS Notes (36557, 12682, 32878, 93658). 
2. Another one is kind of similar to the one that I will recommend, but it does not work in all the cases as the Sales Rep. is not always an SAP employee (PERNR). (This one was described by Paul Ovigele in the SAP Insider blog)
3. An easy one .... that I have used and developed through the years, that works, it's easy and it requires minimal development (around 15 mins. ). This is the one that I will share with you in this Blog Post ...

To start with we will look at a Sales Order with its Partner Functions

* For confidentialy reason, names and descriptions are masked

Here you can see that we have different Partner Functions in this Sales Order (AG - Sold To, RE Bill To, WE Ship To and a custom one ZE - Sales Representative).

The Sales Representative is a typical Custom Partner Function that SD implementation teams normally create. It is commonly used to calculate commissions, among other things. But from a Profitability Analysis perspective it is also really helpful to be able to calculate how profitable a Sales Rep. is (or his customers). So it is also a common business requirements to have it as a COPA reporting Characteristic.

The SD Partner functions in the Sales Orders can be found in Table VBPA - Sales Document: Partner

As you can see above, in our previous Sales Order, we had ZE - Sales Rep. Partner Function assigned to "Vendor" 35xxx52. We can see the record in the Table VBPA.

Now, if you know a little bit of COPA, you might see where this is going .... With a simple COPA Derivation step, we will read table VBPA (Table lookup) and get the Sales Rep. #.

But .... there is a hick here. How do I create this COPA Characteristic in a way that I will not only have the number, but also the "key description" so I can have the Sales Rep. name in my Profitability reports and not just the number? Otherwise, it will be easy just to get the Sales Rep # into a Custom Characteristic field. But people will need to know what is the name of Sales Rep. 35xxxx52, it is not practical if you have many Reps. like big companies normally have.

This is where we need to do a really small development.

All custom and additional Partner Functions that can be added in COPA, need to be added first in Structure MCPARTUSR (Additional Partners from VBPA).
The right way to do it is by doing an APPEND in this structure right after field PDUMMY. As you can see below, we added 2 fields. The one that we will use is ZSREP_LI

The Field ZSREP_LI is defined with a Check Table and all the right definition same as LFA1-LIFNR as our Sales Rep. has been defined as a Vendor by our SD Team. I have used it before defined as a Customer as a different solution.

This of course cannot be done by a Functional Consultant, it needs to be done by a quilified Abaper.

As you can see below, Structure MCPARTUSR is also an Include of Table PAPARTNER, so the new fields get added to PAPARTNER automatically after saving.

Once this is added to MCPARTUSR, then we can go to create the Custom Characteristc (Tcode KEA5) to be added later to the Operating Concern.

I will create a Characteristic based on Table PAPARTNER that will use my Appended Table MCPARTUSR fields. Ex. WWSRP

Now the added field ZSREP_LI can be used and I will call it WWSRP (In this case the image is slightly difference as this was previously done to taking the screen shoots).

There are other standard partner functions that normally do not come as part of the Operating Concern in COPA and can also be added as Characteristics. Ex. WE - Ship to. You just need to create a Characteristic using KUNWE. Similar process for RE - Bill To. (KUNRE). The difference with the Sales Rep. is that these other are SAP Standard Partner Functions and they all have their own fields and check tables that will give us all the validations and descriptions, not just the code.

Now that the Characteristic has been created, we will add it to the Operating Concern as you would add any other Characteristics.

*** Note: We will not describe this process. We assume that if you are reading this you have the basic COPA knowledge to perform it.

Finally, the Characteristic has been Added to the Operating Concern. But the way it is right now, it will not get filled with any values yet.

We need to build a Characteristic Derivation Step (Tcode KEDR) of the Type Table Lookup for Table VBPA, the one that contains the records that hold the Partner Functions of the Sales Orders.

It is important to take into consideration to have POSNR as '000000' as normally the Partner Functions are at the Header Level. In case your SD design has them at the Line item level, then this will not be a constant. (See Table VBPA displayed previously)
In PARVW you will use GLOBAL-USERTEMP1 and then input RE (SAP Internal denomination for Bill-to) or ZE as per my previous example for Sales Rep.
Then the Target field will be your recently defined COPA Characteristic (Ex, KUNRE, WWSRP, etc.).

This concludes our process to Add a Custom Partner Function in COPA. As you could see it just requires a small Append in a Table that would take a good Abaper, not more than 10/15 minutes. And for sure this is 100% upgrade proof ... !!!

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

S/4 HANA Profitability Report creation (COPA)

For COPA - Profitability Analysis purposes, in S/4 HANA the series of "Market Segment" Fiori Apps have replaced the good old fashion Report / Tcode KE30 where we used to build custom reports based on Report Painter technology. Now this is part of the past and we need to use these new "Market Segment" Fiori Apps in order to do Profitability COPA reporting.

Note: This is all based on the assumption that you are running "Account Based Profitability" as it is the recommended approach today for S/4 HANA. Also my preffered one as per many years of experience running both. (Account vs. Costing based).

Now, on an Account Based model COPA, you run all your Profitability Analysis based on GL Accounts postings. For that, in order to do Profitability reporting / reports, you have to build a Financial Statement Version (FSV) (Hierarchy Type FSVN, in Tcode HRRP_REP).

Once you built your Profitability FSV, you just need to run Tcode HRRP_REP (Step #2 from my previous Blog post) to replicate it.

In order to create your FSV, you need to follow this IMG Path.

Then you will and create you own custom FSV for Profitability Purposes. Ex: YPA2

You will enter a description, a Maintenance Language and an applicable Chart of Accounts for this FSV. All the same as if you were configuring any other FSV as you did in the past for FI purposes.
Then you will click in "Financial Statement Items" to start building your Hierarchies and GL groupings.

This is the Standard SAP Best Practices Contribution Margin report (Profitability). I suggest you take a copy of it and create your own "Z / Y" one as per your specific business requirements.

Once created and saved, you will replicate it with Tcode HRRP_REP (as explained in Step #2 from my previous Blog post).

Note: 

Please do not confuse this FSV for COPA / Profitability with your other FSV that you might have created (or not) for FI purposes (I mean your Financial Statements). These are 2 different things / concepts.
One is for Management and Internal reporting (FSV COPA) and the other for External Financial reporting (FSV FI).
They both use the same config tool, as SAP decided to use this concept for both things; but they are definitively not the same and should not be confused with one another.
Another thing that you might have noticed, is that when you define your FSV options; Functional Area is not flagged in this YPA2 Contribution Margin Report as you do not use Functional Area for Profitability Reporting. In my opinion, Functional Area should only be used for External reporting and not for Management reporting.

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

Build and use Hierarchies like GL or Cost Center for Profitability (COPA) or other reporting in S/4 HANA Fiori Apps

Now a days in S/4 HANA we have a series of Fiori Apps available for reporting that are replacing the good old fashion S_ALR_xxx reports that we used to use to report on Cost Center, Internal Order, Profit Center and others on actuals/plan. The old reports are still working fine, but they are good for GUI, not for Fiori. (Unless you call the Tcode through Fiori GUI tile)
So now you have Fiori App reports like "Cost Center - Plan/Actual YTD" or COPA "Market Segments" (replacing old fashion KE30) among others that in order for you to use the Cost Center Hierarchy or Profit Center Hierarchy on them, you first need to run a couple of programs to make them available in those Fiori Apps.
These Hierarchies are stored in the back-end as SETs like any other SETs that we used to use in Finance for all sort of needs. In order to be able to have them available for these Fiori Apps, you need to convert them into BW Hierarchies as the Fiori Apps are based on BW Queries and those don't know anything about SETs, they run with Hierarchies.

This is a 2-step process that you need to run every time you do a modification in any of those Hierarchies, so then the changes become available in the Fiori Apps.

Step #1
Tcode: HRY_REPRELEV - Set Report Relevancy for Hierarchies

As you can see in the screen capture, you can use the following Hierarchies 

• Cost Center Group
• Cost Element Group
• Order (Ex Internal Order) Group
• Profit Center Group
• Account Group
• WBS Element Group
• Functional Area Group 

Once you select the Hierarchy (Set Class) that you want to use, you execute and you get the list of the available ones. In this case "Organizational Unit" is my SAP Best Practices Controlling Area "A000" and all the Groups that come with it. Depending on the Set Class you select, it could mean something different.
Then you activate the "Report Relevant" flag of the lines/lines that you want and SAVE.

Step #2

Tcode: HRRP_REP - FIN Runtime Hierarchy Replicator

This step is required to be able to replicate those previous elements as hierarchies so then the Fiori Apps will be able to use them. Without entering into to many technical details, the Fiori Apps use / show/ consume this as a kind of BW Hierarchies, and this process is required to expose them as such.

You will go, select your Hierarchy ID that you want to replicate, enter a valid from date, and select the "Run settings" for background or foreground. It does not take long to execute, so foreground should not be an issue.

This means that every time you do a change in any of the Hierarchies (GL, Cost Center, Profit Center, Internal Ordes, WBS, etc.) you need to run these 2-Step process so you will have the latest changes available for the Fiori Apps. Without this execution, you will not see the new changes.
This process can also be scheduled to run periodically, but this should only be in a context were you have constant changes.

An small example of an App that would use these hierarchies, "Cost Centers Plan/Actual YTD"

Click in "Cost Center Hierarchy", click "Go"

And you will get the list of Hierarchies that were replicated. (For confidentiality reasons, I am masking the names)

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