Forum Discussion

photon's avatar
photon
Contributor
11 days ago
Solved

Org by period Config

I've heard about org by period since my first exposure to OneStream but I see nothing in the docs and no clear discussion about how it works or what the limitations/requirements are.

Where does this information live?

Cubes
Metadata
Time
  • T_Kress's avatar
    T_Kress
    11 days ago

    It starts with this cube setting:

    And then is based on entity relationship properties found here.  So you can change the "Percent Consolidation" property from 100% to 0% for one parent, and then add the entity again to a different parent with 0% up until a point in time and then 100% from a point in time forward, as an example:

    Also, you may want to make sure your scenario setting appears as below so that elims happen correctly as you vary your org-by-period:

     

  • T_Kress's avatar
    T_Kress
    Valued Contributor
    11 days ago

    It starts with this cube setting:

    And then is based on entity relationship properties found here.  So you can change the "Percent Consolidation" property from 100% to 0% for one parent, and then add the entity again to a different parent with 0% up until a point in time and then 100% from a point in time forward, as an example:

    Also, you may want to make sure your scenario setting appears as below so that elims happen correctly as you vary your org-by-period:

     

    • photon's avatar
      photon
      Contributor
      10 days ago

      This does give me the basic shape of it, thank you!

      I'm already seeing a lot of practical concerns though, which may explain why I've never seen it implemented and they've never bothered to document it in any detail.

      It seems like, once you have a child under multiple parents, you're now required to give it a consolidation percent for every period and every parent in which there is data, be that 0 or 100. None of my testing with any kind of defaults got the behavior to something that actually felt manageable in the real world. (I have written some really elaborate metadata integrations that I can tweak to handle this for this but for most people this seems too impractical.)

      There's also the potentially-problematic (based on user opinion) behavior of displaying non-aggregating children as having a balance under the parent in the period for which they do not aggregate. With no indicator of why this is happening, it just looks like all the parents are "mysteriously" not aggregating correctly. For reports that don't go down to the child level, it's fine, but for everything else it's pretty gross. I guess it wouldn't be the most unreasonable thing to create a kind of "former children of <this parent>" member and move the entities under that but that breaks our hierarchy structure which is perfectly regular (not ragged.)

      Have I overlooked something to make this more practical in the real world?

      • T_Kress's avatar
        T_Kress
        Valued Contributor
        10 days ago

        I am not sure I follow your comment about the "required to give it an agg weight for every period and parent".  Entities do not have agg weights, they have "Percent Consolidation" and "Percent Ownership".  And both of those, once you put a value in will inherit that same value into perpetuity unless or until it is changed.  

        I do believe we have customers that use this without your concerns so maybe someone else can chime in and answer your other concerns directly.

        You may be correct in that an end-user, without the ability to look in the dimension library or without a cube view that shows them the "Percent Consolidation" property would have no way of understanding why something looks like it is not consolidating.  But that can be solved by allowing them view access to the dimension library to view these properties, or better yet, create a cube view with a dynamic U8 member that pulls the "Percent Consolidation" property and shows it over time.  There are definitely things, as a developer, you can create to give the end user transparency to these %s.