Financial Consolidation and Close

Get Involved. Join the Conversation.


    Michael Bay
    Movement split instead of creating another custom dimension
    Topic posted February 26, 2018 by Michael BayGreen Ribbon: 100+ Points, tagged Cash Flow, Dimensions, Income Statement, Tip 
    144 Views, 7 Comments
    Movement split instead of creating another custom dimension
    Splitting FCCS_Mvmts_NetIncome for expense information

    Hi all,

    we have a client requesting to classify the expense accounts into different "line item details" (Marcoms, Travel...) which provide further details to the split that is already in the Income Statement. This classification needs to be provided by Business Unit and Cost Center which forces us to create another Custom dimension.

    We are now thinking about creating a structure below or in parallel to the "FCCS_Mvmts_NetIncome" member in the Movement dimension that is giving us the information about these expenses. For the indirect cash flow, we would integrate these members in the FCCS_CashFlow section.

    Did anyone already work with this kind of adjustment in the Movement dimension? Could there be any issue with regard to the automated cash flow, the calculation of FCCS_REC OBFXCTA or something else?

    I would appreciate any opinion!

    Thanks and regards,




    • Kimborey Lam

      That's the best way for me to save one custom dimension and I don't see any issue doing that (I haven't tested it yet). As long as all the P&L data rolls up to FCCS_Mvmts_NetIncome, it should work fine. If you put all your CC members directly under FCCS_Mvmts_NetIncome, since FCCS_Mvmts_NetIncome is already a shared member in the pre-built indirect cash flow, you shouldn't have any issue. Also the data would roll up to Closing Balance and will then be considered in the Opening Balance of the following year and therefore FCCS_REC OBFXCTA would be calculated correctly.


    • Bjoern

      Hi all,

      In Oracles Setup, the element FCCS_Mvmts_NetIncome is not defined as a calculated node element. (Data Storage = Never Share).

      The default setting for this item cannot be changed to dynamic calc.

      Any idea how should the aggregation work?

      Kind regards


    • Kimborey Lam

      On rule. If you check the data storage for all "dense" dimensions it is either store or never share.

      Only Account has dynamic calc members. This is an essbase thing where to optimise the performance they prefer running the aggregation on rules. (I personality hate it).

    • Bjoern

      Do you mean a self-defined rule or should it work with the predefined rules?

    • Kimborey Lam

      It's pre-defined. When you run the "Consolidate rule", it aggregates the data.

    • Bjoern

      Sounds good. I will test it and come back with Feedback.

      Thank you!

    • Keith Glide

      I would suggest that you create a new parent sibling of the existing FCCS_Mvmts_NetIncome in the Closing Balance hierarchy and add your analysis details under that member. Then add the new movement parent under the Cash Flow hierarchy. You can add your new movement parent under the same Cash Flow parent as the FCCS_Mvmts_NetIncome member (FCCS_CashFlow_NetIncome) in order to present a single value. Just remember to set the aggregation operator to Subtract as it is with FCCS_Mvmts_NetIncome(Shared).

      The FCCS_REC_OCFXCTA opening balance and FX calculations are applied to all base members of the FCCS_Mvmts_Subtotal parent member so as long as you create your analysis members within that section of the Closing Balance hierarchy then all subsequent calculations should work fine.