Forum Discussion

photon's avatar
photon
Contributor
12 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 thi...
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.

     

    • photon's avatar
      photon
      Contributor
      10 days ago

      Ah, yes, it will just inherit as it rolls forward. That certainly makes much more sense. (I also mistakenly called it an agg weight but I've edited my reply to call it the OneStream-approved "consolidation percent" instead, just so future readers don't get confused.)

      I think the real problem is not with knowing the consolidation percentage, it's that the business doesn't want to see the amounts or even the members unless it's a period/parent where the data is relevant. This particular approach is more like conditional consolidation by period than actual org by period (which checks out, given the properties involved.) The organization is a mess in every period, and it just gets less organized over time, even if the higher level data checks out.

      Yes, I could find ways to update every single report and cube view and quick view and obscure spreadsheet to pull the consolidation percent and conditionally hide the unwanted data/members but that's not practical after being live on the platform for this many years. I think I'll have to go back to the business so they can judge the value of the alternatives and hope they're willing to be reasonable.

      Thanks for your help clarifying this!

    • photon's avatar
      photon
      Contributor
      10 days ago

      Ah, I think I just connected the dots on one thing I got wrong. If I move an entity to a new parent, I will have to go back to set a historical period to 0 consolidation percent for that parent. Otherwise, all the historical data shows up under both parents. Still, that's not so bad.

       

      • T_Kress's avatar
        T_Kress
        Valued Contributor
        5 days ago

        Correct.