CoA: Development and Troubleshooting Tips

Owned by Petr Buncik
Last updated: Oct 16, 2023
4 min read

  • If you encounter a missing account in FIN OCoA dimension while loading data into the FIN General Ledger TB, don't reject the record. Instead, add the account to both the FIN CoA Map:FIN OCoA and FIN OCoA dimensions as part of the Total GL Accounts rollup. The account will be marked as unmapped in the UI, but the data will remain loaded in the FIN General Ledger TB cube.

    • Please note: Since the account won't have the correct flags calculated after the data load, it's crucial to map it before proceeding with the roundtrip. Even OPV can't be calculated properly without mapping the account and applying the changes to the FIN OCoA dimension by syncing from template.

  • Follow below steps when implementing CoA:

    • You should already have structure of FIN BSEG and FIN Company dimensions loaded and verified it is correct. Crucial are Total FIN BSEG rollups for each BSEG dimension and Total FIN Company rollup for FIN Company dimension.

      • These dimensions should be always managed through APQ dimension framework to make sure you might run their maintenance anytime there are changes in these dimensions in the primary system.

    • Learn the account structure before loading into the system and consider which accounts should be assigned to mandatory C3 accounts. The accounts are:

      • C3_MGMTTB - this node represents total of assets and liabilities

      • C3_TB - this node represents Total GL Accounts rollup

      • C3_STATISTIC - this node is a root for all statistical accounts

      • C3_CTA - this node represents Cumulative Translation Adjustment account (the CTA effect calculation might be switched off)

      • C3_NPAT - this node represents root for Net Profit After Taxes

      • C3_PCFWPY - this node represents account to hold Profit Carried Forward From Prior Years (relevant for planning)

      • C3_EQ_RETEARN - this node represents Retained Earnings account from prior year

    • Import structure from your data source into staging area

      • The structure might be imported at once in one extract or from several extracts.

    • Import rollups from the staging area so they integrate properly to FIN OCoA Rollups and Reporting Rollups that are always included in FIN OCoA dimension.

      • You may decide to load the individual rollups without specifying parent rollup should you need to automatically attach the elements to their parents - in this case always consider proper sequence of loading, so the elements are loaded after their parents are in place.

    • Provide mandatory C3 accounts assignment so it is possible to proceed with flags calculation and Total GL Accounts and ApliqoC3 Technical Rollups management.

    • At this point you may sync FIN OCoA from the template dimension.

      • A good basic test to verify if FIN OCoA dimension structure is correct is to first check if Total GL Accounts total is netting to zero for totals per all BSEG dimensions and Total FIN Company in FIN General Ledger TB on TB Load consolidation value measure level. This test might be provided after loading source data into FIN General Ledger T, provided you have included all missing accounts during the load as per above point.

      • Following test should be able to verify FIN OCoA dimension structure in a bigger detail by observing totals per C3_MGMTTBnetting to zero in FIN General Ledger TB per BSEG and FIN Company totals as in prior case, but on OPV consolidated measure level. This test might be provided after mapping all unmapped accounts in FIN OCoA and syncing the dimension and then calculating OPV.

      • Note: You should not proceed with any data loading by roundtrip processing before you have tested the FIN OCoA dimension structure is correct.

    • Once the FIN OCoA structure is settled and verified, you should proceed with mapping FIN OCoA to FIN PCoA.

      • Simple 1:1 mapping is possible to achieve by setting Mapping Level Override on C3_MGMTTB level to 0 (this might be set automatically should the value of Mapping Level Override be empty before running process }APQ.C3.Dim.CoAMap.PlanDimension.Update).

      • Any other mapping should be provided manually by setting Mapping Level Override, then running planning CoA flags calculation by process }APQ.C3.Dim.CoAMap.PlanDimension.SetFlags and then checking calculated values of Plan Map ID for nodes that received manual entry.

        • Setting value to Mapping Level Override value will affect the immediate node and its children as they will inherit the override value from their parent node. However it is possible to set Mapping Level Override on any of the child nodes to override the inherited value from the parent node.

      • Once the mapping is verified, you may proceed with running the plan dimension structure update by running the process }APQ.C3.Dim.CoAMap.PlanDimension.Update.

        • Note: It is strongly recommended to have BSEG to BSEG Plan mappings already in place and have them verified for both BSEG to BSEG Plan and BSEG Plan to BSEG directions.

        • You may check the resulting FIN PCoA structure in the FIN CoA Map:FIN PCoA template dimension before syncing the dimension to production to verify your mapping was correct and the structure is valid for planning.

      • When you have tested FIN PCoA template dimension structure is correctly derived from FIN OCoA structure, you may proceed with syncing the template to FIN PCoA dimension by running process }APQ.C3.Dim.CoAMap.Dimension.Sync.

Â