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