Line Item or Line Item Subset or Line Item Subset mapping to Accounts

Hi, Anaplan friends,

 

In the attached file, there are three options for simple P&L by Stores. May I know what factors need to be considered in choosing one out of these three options ? What determines which option you should choose ? What motivates you to apply option 3 where you need to take three steps to derive ??

Your cooperation would be much appreciated.

Thanks !

 

John

Tagged:

Best Answer

Answers

  • Hi, Paul

     

    Thank you for having elaborated on the differences b/w the options their evaluations. It really helped me understand one aspect of why line item subsets ever exist. What I understand from your explanation is maintainance is the most important perspective in deciding whether line item subsets/mapping to Account hierarchy should be applied.

    Thanks again for the pointers.

     

    John

  • Hi all,

     

    Interesting to read experiences of other people how you have decided to implement P&L. I've also seen multiple types of solutions and tried to list some of my experiences below.

     

    1. P&L Rows as Line Items

     

    I agree with Paul that this option is the one for best formatting options (summaries, bolding, subtotals, percentage figures etc). It also allows most flexibility in formulas because you have separate formulas for each account. It should be kept in mind that flexibility is not always a good thing, sometimes it's better that you are "forced" to plan your architecture to be logical and structured well for maintability. It is really easy to make the P&L/model overly complex with each account as own line item. In my opinion P&L itself should only gather data from other modules but it is quite easy to fall into including too much logic to P&L with this option. Of course this is not a problem if you are aware of it.

     

    With this option you must define formula for each account separately and if you have a long chart of accounts which changes often (new accounts, minor changes in hierarchy...) it might require lots of manual work in the long run for maintaining your P&L. Therefore I would consider this option with quite simplified and static financial statement, not for a P&L with a large number of G&L accounts. Conditional formatting is also defined for each line item separately, so you have to edit conditional formatting options (in addition to formulas) every time you have new account in your report. Line items also don't synchronize between different modules in dashboards which means if you have same "account" (line item with a same name) in two modules, you won't be able to synchronize selections between them on dashboards although they would have same names. If you have accounts as a list in other modules, you probably need to hard code select-statements to your formulas which means the model is not that dynamic from technical perspective.


    2. P&L Rows as a Line Item Subset

    I'd skip this one as a real option. Like Paul, I've seen this one used only in combination with the option number 1. This is because the only dimension with calculation other than summing (that is line items) is used for calculating figures to accounts. You need to have another module for YTD calculations, moving averages, time sums. In a way you convert your line item dimension to account dimension (which is the option 3). In my opinion the appearance of line items subsets is not that nice either, therefore I mainly use them only as technical items, not on dashboards.


    3. P&L Rows as a List (i.e. the P&L section of the Accounts Hierarchy)

    Paul described the limitations of this option well already (aggregation is based only on summing, formulas might be long if there are many source modules). Opposite to Paul's preference, this is my favourite out of all these options. Reasons for this are mostly technical but there also some benefits for end users. Technical benefits include automatization of account hierarchy updates without the need for manual maintenance of formulas, easy linking of data between modules with account list/subset as dimension or parent hierarchy (linking is also handy by using collector modules and mapping tables), possibility of using line items in modules for other calculation than using them for accounts (could be YTD, rolling figures, currency conversion, comparisons between versions, etc), integration/exporting data with account codes and properties (with line items you export their names), synchronizing P&L on dashboards with planning modules with account as dimension. In my opinion also graphs work better when you have accounts as a list and different kind of measures as line items. End users have liked the option of account hierarchy with parent lists. The downside is that you must have the same number of levels for each account with this solution which sometimes might look stupid, but often users like when they can see the detailed account data with "reselect levels to show" button before actually using the drill down option to drill down to source modules. KPI reports and more stylished financial statements must be built separately in this case, but I don't see that as a big problem because you can publish them to the same dashboard.

     

    Br,

    Jaakko

  • Hello Friends,

     

    Here is a technical video that can provide further insight into building and maintaining line item subsets!

     

    https://www.youtube.com/watch?v=JiaEmMZGVCg