Technical Articles
How to Convert 0CALMONTH2 & 0CALYEAR to 0FISCPER?
You are here to learn the ABAP field routine to convert 0CALMONTH to ZFISQRT.
We have a 0CALMONTH2 (01, 02, 03.…..12) & 0CALYEAR (2014, 2016, 2017, 2020, etc.) in the DSO from this we have to calculate the 0FISCPER (Fiscal Period) in our Infocube then we write that code in field routine of transformation. Check the below transformation between DSO to Infocube.
Step 1 : Map 0CALMONTH2 & 0CALYEAR from source to target with 0FISCPER in transformation.
Then, Right Click on 0FISCPER in target of transformation and select the Rule details option.
Step 2 : Select Rule Type as Routine as mentioned in above screen.
Step 3 : Write the below code to convert 0CALMONTH2 & 0CALYEAR to 0FISCPER in field routine as –
DATA : MONTH(2) TYPE N,
YEAR(4) TYPE N,
YEAR1(4) TYPE N.
MONTH = SOURCE_FIELDS-CALMONTH2.
YEAR = SOURCE_FIELDS-CALYEAR.
YEAR = YEAR - 1.
YEAR1 = SOURCE_FIELDS-CALYEAR.
IF MONTH EQ 01.
CONCATENATE YEAR '010' into RESULT.
ELSEIF MONTH EQ 02.
CONCATENATE YEAR '011' into RESULT.
ELSEIF MONTH EQ 03.
CONCATENATE YEAR '012' into RESULT.
ELSEIF MONTH EQ 04.
CONCATENATE YEAR1 '001' into RESULT.
ELSEIF MONTH EQ 05.
CONCATENATE YEAR1 '002' into RESULT.
ELSEIF MONTH EQ 06.
CONCATENATE YEAR1 '003' into RESULT.
ELSEIF MONTH EQ 07.
CONCATENATE YEAR1 '004' into RESULT.
ELSEIF MONTH EQ 08.
CONCATENATE YEAR1 '005' into RESULT.
ELSEIF MONTH EQ 09.
CONCATENATE YEAR1 '006' into RESULT.
ELSEIF MONTH EQ 10.
CONCATENATE YEAR1 '007' into RESULT.
ELSEIF MONTH EQ 11.
CONCATENATE YEAR1 '008' into RESULT.
ELSEIF MONTH EQ 12.
CONCATENATE YEAR1 '009' into RESULT.
ENDIF.
0CALMONTH (INPUT) | 0CALYEAR (INPUT) | 0FISCPER (OUTPUT) |
12 | 2014 | 2014009 |
1 | 2015 | 2014010 |
4 | 2016 | 2016001 |
10 | 2017 | 2017007 |
Step 4 : Save the routine and transformation. Run your DTP and check the above table from Input data to Output data.
Conclusion : In the above blog post you have learned about the ABAP field routine code to convert 0CALMONTH2 (Calendar month) & 0CALYEAR (Calendar Year) to 0FISCPER (Fiscal Period). It’s a complete customization to convert Calendar Month and Year to Fiscal Period. In next some blogs you will get so many routine code for time characteristics conversion.
Or you could write it in 4 lines, specifying the period offset (which will vary for different companies/countries).
Better, would be to create a class with a method, then you can reuse it wherever you need it. This has the additional advantage that you could add an automated ABAP unit test to help protect it and make sure it works properly.
In your field routine you can now use:
Finally, you could replace the constant for offset with something else, if, for example, you're dealing with a number of entities with differing fiscal years. So it could be reading a config table, some master data.
The goal is flexibility, ease of use and reuse. Don't build the same code multiple times - that way leads to errors and errors are expensive. (Don't use includes as a tool for reuse - it is a very bad idea, as it can lead to huge recompilation times if the include is extensively used ).
For any BW team, I always recommend having an experienced ABAPper on board to try to ensure the code is of the highest quality. There are many performance "traps" in BW ABAP development, and it's far too easy for not-very-experienced developers to fall into them. Even with simple requirements.
I served in such a role for 15 years. I've seen some terrible things... 😀
In this case you can use formula CALMONTH_FISCPER, or in field routine use class CL_RSAR_FUNCTION with method CALMONTH_FISCPER.
Why using special coding for this?
Mainly - I didn't know about that method. It's certainly a massive improvement of the original solution.
CL_RSAR_FUNCTION=>CALMONTH_FISCPER takes CALMONTH (YYYYMM) as input, rather than CAL_MONTH2 (MM), which may not be desired. It also required Fiscal Year variant, which it's technically possible (unlikely) doesn't exist. Chances are though that FISCVAR and CALMONTH are available.
However, there's a reasonably good reason to embed that method call in a Z class method, based on Clean Code considerations - ease of maintenance, testability, readability and comprehensibility, hence Total Cost of Ownership. A minor improvement only.
Instead of a
you require
Which, with those EXPORTING, IMPORTING parameters is slightly less readable and understandable.
I would change my method to:
Then call by
It's a minor improvement, but the consensus is that functional methods such as this are easier to understand than those with exporting parameters. (It looks to me like the programmer of the class just converted a function module and didn't know about returning parameters).
You could, in this instance, define the functional method as a class method, but I find it's more flexible for changes
I spent a lot of time in the past 15 years dealing with ABAP code written by BW developers, that has rapidly become very difficult to understand and therefore costly to fix or enhance. Any ABAP written in a system should be focused on maintainability - regardless of the module.
Why isn't anybody checking the fiscal year variant here 🤔
The code in the blog is not valid for fiscal year variant K4 for example... these kind of codes are fine if you only use one fiscal year variant (and will never ever introduce another).