Entity Name Changes

[Sathish]

Hi Team,

I would like to understand how you are managing the Entity changes on a monthly basis.

For eg: the Entity name in 2021 M6 is San_Jose_213 and it is changed to SFO_213 in 2021 M7. If I choose the rename option, then 2021M6 cube data will override but custom tables created for our requirement will remain with the old MEP name. On the other hand, if I chose to create a new entity how to intact both the entities for future reference

[NicoleBruno]

Hi Sathish,
I’m not quite following your statement “If I choose the rename option, then 2021M6 data will override.”. If you rename the entity, all the data carries from the historical entity to the newly renamed entity so there’s no break when users are pulling data for YTD 2021. That seems like the lease disruptive way to handle a name change unless the old and newly named entities exist in different parts of the hierarchy, then you have additional factors to consider. Let me know if I’m misunderstanding.
Thanks,
Nicole

[Sathish]

Hi Nicole,

Thanks for your explanation. We are using custom tables to store additional attributes in the system periodically for our business needs. We have built dashboards on top of the cube views.

Business requirement is that historical data should not be changed Account reconciliation was already certified with old Entity name. I would like to understand how other organizations are handling this problem?

[Sai_Maganti]

Satish

Based on my understanding from your comments, here are a couple of ideas:

The integration between your ERP and OneStream should always be using unique codes which would never change. For example your entity San_Jose_213 would be constructed like this:

Entity Code: 213 (Name in OneStream)
Entity Name: San_Jose_213 (Description in OneStream)

So if there is a legal entity name change in your ERP, the code 213 will still be the same in both ERP and OneStream. You’ll only update the Description in OneStream. This way your AcctRec would be done using the code 213 always.

OR

You can create a parent entity hierarchy like this:

Parent_SFO_213_San_Jose_213

• San_Jose_213 (Load data upto 2021 M6 here)
• SFO_213 (Load data from 2021 M7 here)

Sai

[Sathish]

Hi Sai,

Thanks for your reply. Your suggestion won’t work in my case.

Let me explain with an example.

Parent Entity - SFO
Child Entities - SFO_210; SFO_211 and San_Jose_213.

Business users performed Account Reconciliation till 2021M6 under the entity name San_Jose_213 (ID - 11225). In 2021M7 rollover, the Corporate team decides to change the Entity name to SFO_213 (ID - 11338).

So if user want to see the historic data up to 2021M6, the entity should display as San_Jose_213 whereas from 2021M7 onwards it should be shown as SFO_213.

I would like to understand how other organizations using OS for their Account reconciliation are managing this issue.

We have used custom tables in our solution to store additional attributes provided by users as part of substantiation. I need some guidance on how to handle this scenario

[BrassRoch]

I have a similar issue. My client refers to it as effective dating. For tax audit purposes they need to report based on the hierarchy at a point in time in history. So using your member names:
In 2020:
Parent - SFO
Child - SFO_213
In 2021:
Moved to new Parent - California
Child SFO_213
When reporting for 2020 they want to reflect the SFO parent, but for 2021 the California parent. I would prefer not to create alt. hierarchies by point in time or copies of the application every time hierarchy changes are made. It would be nice to have a starting period for hierarchy changes.

[ckattookaran]

I hate to resurrect an old post. Why don’t you create a new member and vary the InUse property of old one and new one.
Let’s say San_Jose_213 will be InUse till 2021M6, 2021M7 onwards SFO_213 will be InUse. Now if there is data for San_Jose_213 in 2021M7 you’ll have to copy the data to SFO_213. Also all forms need to use suppress invalid rows/columns

[Sathish]

Hi Celvin,

But there is a hindrance in your suggested approach. We have built certain historical views which will allow top management to see the trended data something like Last Qtr vs Current Qtr. In such case, till M6 data is sitting in San_Jose_213 whereas from M7 it is sitting at SFO_213. Do you see any possible way to link both the ID’s?

We have created functionality called “Action Item” Tracker against each Global account under local entity level say San_Jose_213. If we stop using san_Jose_213 from M7, how to bring the data of the open Action items into SFO_213?

[ckattookaran]

Not sure why you want the data before M6 to be coming into the other member for the comparison only?
Now if you want to do move data from some and not others, then you need to copy data.

[OSAdmin]

Not fully knowing what is your business need of looking historical period , couple of inputs here

1. If you are just renaming a member then your previously loaded data will be still intact in the cube only issue you will face to drill back to your custom table if the member name is different during the prior period processing of data vs current period
2. You could have handled via custom drill back code in your connector business rule
3. You could change your transformation rule and reload back your history period which I will not recommend

I can provide further detail as we had custom solution in place to handle this kind of scenario with our business need. Let me know your exact use case.

Thanks
Khirod Palai

[Michel_Sabourin]

You may be able to utilize the Text Fields (assuming you’re not currently using them for some other purpose. This would be a little more difficult from a reporting standpoint, but you could, for example, put ‘2021M6 San_Jose_213’ in the Text1 field. You could then create an XFBR that looks at the text fields and compares it to the reporting period (if it’s 2021M6 or earlier, return the name ‘San_Jose_213’ else take the current name

[Sathish]

Hi Michel, thanks for your response. Yes, we identified your proposed solution couple of weeks back and we have started the setup to achieve the same. Only hindrance we see in RCM where system showing entity name from entity dimension. Seems we need to apply same time period approach here as well. We pretend to not add any customisation into RCM because we need to apply the same every time RCM upgrade happens. Do you have any other way to solve RCM issue?