Group Reporting Preparation Ledger - massive mappings for segment and performance

[dmitrij_rempel]

Dear Experts,

We need your experience in Group Reporting Preparation Ledger mapping functionalities.

We are right now in the evaluation for Group Reporting project and the customer has a massive mapping requirement for data delivery within management version.

In the mapping from accounting to the group data model (for integrated consolidation units) the dimension segment should not be taken over from ACODCA, but is to be derived from combination of cost type / cost center / profit center.

The number of mappings per segment at the moment is:

Segment 1 - 11.304

Segment 2 - 1.887

Segment 3 - 810

Segment 4 - 545

Segment 5 - 2.509

Segment 6 - 315

Segment 7 - 569

Segment 8 - 575

Segment 9 - 695

Segment 10 - 557

SUM - 19.766

Can I overwrite the segment information even if I want to make a matrix consolidation with dimension segment?

Can Group Reporting Preparation Ledger handle this number of mappings? Are any performance issues to be expected?

Kind regards,

Dmitrij

P.S.: I know, that this mapping would be possible with automatic connection via GRDC. But the customer doesn't want to loose the drill down functionality. But as a fallback it could be a solution. Would the customer get some performance issues in GRDC if we implement there such mapping?

[Florian_Roll]

Hi Dimitrij,

for the integration of accounting with GR in the release task for the dimensions segment and profit center, GR requires consistency between accounting and GR, i.e. the fields are associated 1:1. More information on the derivation of the accounting field segment can be found here.

Integration by the GRDC mapping does not require this 1:1 association, i.e. segment can be derived flexibly.

Hope this helps.

Kind regards,

Florian

[dmitrij_rempel]

Hello Florian,

thank you. The alternative with GRDC was clear for me.

I like proposed solution with substitution rule directly in ACDOCA, proposed by Jana. If the customer would agree, we would go this way.

Kind regards,

Dmitrij