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