How to Convert 0CALMONTH2 & 0CALYEAR to 0FISCPER?

[saurabhchoudhary90]

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.

 

[matt]

Or you could write it in 4 lines, specifying the period offset (which will vary for different companies/countries).

  CONSTANTS c_period_offset TYPE i VALUE 3.

  DATA month TYPE n LENGTH 3.

  month = ( source_fields-calmonth2 - c_period_offset - 1 ) MOD 12 + 1.

  result = source_fields-calyear && month.

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.

CLASS z_convertor DEFINITION PUBLIC CREATE PUBLIC.

  PUBLIC SECTION.

    METHODS convert_year_month2_to_fiscper

      IMPORTING

        i_calyear   TYPE /bi0/oicalyear

        i_calmonth2 TYPE /bi0/oicalmonth2

      RETURNING

         VALUE(r_result) TYPE /bi0/oifiscper.

  PRIVATE SECTION.

      CONSTANTS c_period_offset TYPE i VALUE 3.

ENDCLASS.



CLASS z_converter IMPLEMENTATION.

  METHOD convert_year_month2_to_fiscper.

    DATA month TYPE n LENGTH 3.

    month = ( i_calmonth2 - c_period_offset - 1 ) MOD 12 + 1.

    r_result = i_calyear && month.

  ENDMETHOD.

ENDCLASS.

In your field routine you can now use:

result = new z_convertor( )->convert_year_month2_to_fiscper(

            i_calyear   = source_fields-calyear

            i_calmonth2 = source_fields-calmonth2 ).

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

[former_member231709]

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?

[matt]

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

result = NEW z_convertor->convert_year_month2_to_fiscper(

            i_calyear   = source_fields-calyear

            i_calmonth2 = source_fields-calmonth2 ).

you require

cl_rsar_function=>calmonth_fiscper(

    EXPORTING i_calmonth = source_fields-calmonth

              i_fiscvar  = source_fields-fiscvar

    IMPORTING e_fiscper = result ).

              

Which, with those EXPORTING, IMPORTING parameters is slightly less readable and understandable.

I would change my method to:

CLASS z_convertor DEFINITION PUBLIC CREATE PUBLIC.

  PUBLIC SECTION.

    METHODS convert_year_month2_to_fiscper

      IMPORTING

        i_calmonth TYPE /bi0/oicalmonth

        i_fiscvar  TYPE /bi0/oifiscvar

      RETURNING

         VALUE(r_result) TYPE /bi0/oifiscper.

  PRIVATE SECTION.

      CONSTANTS c_period_offset TYPE i VALUE 3.

ENDCLASS.



CLASS z_converter IMPLEMENTATION.

  METHOD convert_year_month2_to_fiscper.

    cl_rsar_function=>calmonth_fiscper(

        EXPORTING i_calmonth = i_calmonth

                  i_fiscvar  = i_fiscvar

        IMPORTING e_fiscper = r_result ).

  ENDMETHOD.

ENDCLASS.

Then call by

result = new z_convertor( )->convert_year_month2_to_fiscper(

            i_calmonth  = source_fields-calmonth

            i_fiscvar   = source_fields-fiscvar ).

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.

 

[RafkeMagic]

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