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