Group Reporting Preparation Ledger - with fiscal year variants

[former_member429088]

I am working with a partner and a customer where we are considering using Group Reporting Preparation Ledger (GRPL) to tag the Universal Journal with the Consolidation Unit and FS Item. In reading the SAP Notes on this topic there appears to be a restriction where you cannot use GRPL if you have company codes within the leading ledger that have a different fiscal year variant.

I understand the complexity of pushing data automatically from ACDOCA to Group Reporting (GR) where there company codes that have a different fiscal year variant, but I do not understand why this would preclude the usage of GRPL to tag the data in ACDOCA. There is still value to doing this mapping in ACDOCA even if we need to use a different method (Group Reporting Data Collection) for the actual final mapping and posting of data to GR.

Please advise.

thanks,

Phil Jacobs

[FlorianRoll]

Let's take an example....

You have an accounting ledger (GRPL activated) 0L with the group GAAP and all company codes sharing the same FYV = K4.

You have a second accounting ledger (GRPL activated) 2L with local GAAP and company codes having different FYV:

• 1001-1005 with FYV K4 (region ASIA)
• 2001-2005 with FYV V6 (region NA)

You have the 3 GR versions

• Y10, "group GAAP" preparation ledger 0L, FYV K4: all consolidation units can be integrated from accounting because their FYV match the one from the version
• Y01, "local GAAP, ASIA", preparation ledger 2L, FYV K4: only consolidation units for comp codes 1001-1005 can be integrated from accounting. For 2001-2005 you will not be able to set the integration from accounting in their Consolidation Unit master data because of differing FYV. Hence the release task will not work for them.
• Y02, "local GAAP, NA", preparation ledger 2L, FYV V6: only consolidation units for comp codes 2001-2005 can be integrated from accounting. For 1001-1005 you will not be able to set the integration from accounting in their Consolidation Unit master data because of differing FYV. Hence the release task will not work for them.

As a result you have

• the total group in version Y10 in FYV K4, group GAAP
• ASIA region in Y01 in FYV K4, local GAAP
• NA region in Y02 in FYV NA, local GAAP

With this setup you can ignore the warning messages you receive in accounting.

• They basically tell you that you will not be able to integrate the consolidation units with differing FYV using the release task.
• In accounting the derivation of the GR fields will happen
• However, in the consolidation unit master data and the release task you will only be able to integrate 1001-1005 from 2L into version Y01, and 2001-2005 from 2L into version Y02.

Hope this helps.

(Btw. we're considering rephrasing the warning messages a bit, to make configuration users aware of such setup, and the fact that the derivation of the GR fields in accounting happen despite the warning.)

[FlorianRoll]

Hi Phil,

indeed when defining an accounting ledger as group reporting preparation ledger (GRPL) there are additional checks being performed at different places (e.g. maintenance of accounting ledgers, maintenance of group reporting preparation ledgers). The warning messages raised indicate that the fiscal year variant (FYV) assigned to the company codes in the ledger should match the one of the group reporting (GR) version.

The prerequisite for integrating data from accounting to GR with GRPL is indeed that for the integrated consolidation unit the FYV of the corresponding company code needs to match the one of the GR version. The rationale is that on accounting and GR side the period definitions need to be the same. There is no period transformation or derivation during the release task anymore, i.e. the period is transferred 1:1 from accounting to GR.

However, this does not imply that all company codes need to get the same FYV assigned in the accounting ledger. Consolidation units will not be able to be integrated into a GR version from an accounting ledger if the company code FYV does not match the GR version FYV.

Alternative options would be:

• define different versions (one per FYV), and only integrate company codes with matching FYV into the respective version. This can be an option if in addition to the group ledger with unified FYV there are local ledgers where regions may use differing FYV. As long as the regions share the same FYV, regional consolidations could be setup in additional versions with consistent FYV.
• use other integration (e.g. GRDC mapping with ACDOCA as a source - where periods can be transformed)

One remark to Martin: deviating fiscal year variants are not supported with GRPL

Hope this helps.

Kind regards,

Florian

[former_member429088]

I am still not 100% clear on your reply. Does the warning message prevent the system from tagging ACDOCA with the Consolidation Unit and FS Item for company codes with a different fiscal year variant (FYV), or is it just a warning message at this point and the records are still mapped and tagged? I understand preventing the automatic data flow to Group Reporting (GR) but there is still value in tagging the records even if a different method is required to release the data to GR.

[MartinJul]

Hi Phil,

I am not sure I can find a question in your post. But in regards to fiscal year variant and transfer to group reporting the main rule is that group reporting uses the FYV on your consolidation version. If you have consolidation units with deviating FYV you can set the fiscal year variant on your consolidation unit master data.

Fiscal Year Variant | SAP Help Portal

Br

Martin Jul

[davidcdixon2]

Florian, your remark to Martin that "deviating fiscal year variants are not supported with GRPL" and earlier explanation that "There is no period transformation or derivation during the release task anymore, i.e. the period is transferred 1:1 from accounting to GR." begs the question: Can this functionality can be made available with GPRL as it exists without GPRL (i.e. support of the scenario were ledger 2L company codes sharing differing FYV could be mapped into the same GR version (call it "Y20" as an alternative to "Y10")?). If technically possible to add in a more streamlined and optimized period transformation/ derivation option during the GPRL-based release task, I can submit a new feature request via the SAP Customer Influence portal and put it out to vote.