"empty nester" parents and lingering data
If a member has no parent then it's an orphan but if a parent member had children and they all get moved, the former parent is now...
Regardless of the term, this company loves to do big reorgs a c...
Forum Discussion
Not at all coincidentally, I had already kudoed the 7988 request but it looks like I'm nearly alone in this struggle though as it's been so long since I did that I forgot about it and there are still only a total of two. I did go ahead and kudo the other one as well though. It does seem odd that there's not a "no, for really real, I made this member on accident and it absolutely has to go, I don't care what data it has in it, I'm quite confident that it needs to be deleted, because I'm the boss and not you" function anywhere.
One of the weird situations when running this software is that a lot of requirements get dictated by finance directors and VPs and various managers who care nothing for practicality or common sense or technical limitations; they just need it done or the numbers will be wrong. If a department with four child entities gets dissolved and three of its entities go to an existing department and the fourth goes to a totally new department, that original department is well and truly dead. Having it stick around in the hierarchy is just plain wrong and causes double-counting. I get why it needs to be done, it's just a hassle.
I guess, in my head, I was wondering if I could find the offending members by writing some kind of rule that looked at number of children and the state of the data cells. Since the data at the parent level would have been consolidated and not entered directly, would that give me something to filter on?
Based on what I've seen so far, it seems like the general answer to my original questions is "no, not really, do it the hard way."
I cannot think of a reliable way that will get you there. You can try using O#AdjConsolidated as the data moves from AdjInput to AdjConsolidated in the entity dimension, but that assumes that journals have been booked on a level below the former parent you are looking for. If journals are used a lot in your organization, maybe that helps when you search for a base entity with data on that member.
Do parent entities use the same security in your solution? Maybe you can identify former parents based on this? Any other difference in your case? Any property that only base or parent entities were supposed to use?
Going forward - I know that does not help you now - you could establish a process where the parent / child status is stored on an entity's text property, that way you could filter base entities based on that easily.