We had a client where, by nature of their business, base entities may move from one parent to another. However, all historical data must stay with their previous parent. Only prospective data will belong to the new parent.
There may be several ways of complying with this client requirement, but for me, the simplest way is to create a new entity for prospective data. Let me explain why:
- Historical data integrity is preserved. Moving the existing entity to the new parent means that all its historical data will move with it. For locked periods, the consolidated numbers would not change but the base entity that contributed to the consolidated numbers would no longer be part of the affected hierarchy. In the process, the details supporting the consolidated numbers would be short. If a new entity is created, historical data stay with the old entity and prospective data are redirected to the new entity under the new parent. Necessarily, this requires modification of FDMEE mapping.
- Only prospective data are affected. As mentioned, FDMEE mapping change is needed to load data to the new entity. The old entity will no longer receive prospective data.
- When the consultants leave, it will be easier for the application administrator to create new entities and modify FDMEE mapping.
Of course, appropriately naming the new entity will allow the client to easily identify that it is the same entity that now belongs to the new parent.