Implied sharing is an old thing everyone knows the reasons and solutions of that, still little theory about that:

With Essbase implied sharing, some members are shared even if you do not explicitly set them as shared. These members are implied shared members. When an implied share relationship is created, each implied member assumes the other member’s value. Essbase assumes (or implies) a shared member relationship in these situations:

1. A parent has only one child

2. A parent has only one child that consolidates to the parent

In a Planning form that contains members with an implied sharing relationship, when a value is added for the parent, the child assumes the same value after the form is saved. Likewise, if a value is added for the child, the parent usually assumes the same value after a form is saved.For example, when a calculation script or load rule populates an implied share member, the other implied share member assumes the value of the member populated by the calculation script or load rule. The last value calculated or imported takes precedence. The result is the same whether you refer to the parent or the child as a variable in a calculation script. For more information have a look at:

Now the issue which we are going to talk about is We loose data on save even when the parent is dynamic calc and has a single child.

A dynamic calc parent to a single child: 

If we design the form with following selection:

In the data form we will find parent below the member and this is by design whenever you make a selection using commands to select all the member below parent, always children will appear before the parent:

Lets try to enter data,

Save it

Now, try to change the way we selected members

Here we go:

Now the question again why this behavior:

1. Data from Planning data form passes to Essbase row by row,

2. Because in data form the child member appears before the parent,

3. First, data goes to Essbase for child (SingleStoreChild),

4. Then when Planning passes the data for parent there was #Missing or No data, 

5. Over writes the data to #missing.

PS: As we know that dynamic calc members are calculated on the fly they are not allocated with any memory in the Essbase, here the parent was dynamic calc and it was pointing to same memory as child in the background, when Planning was passing data to Essbase for second row it has updated the child with missing data.(Little confusing, let me know if you need more explanation)

6. As one of the solutions just change the order of appearance of parent and child.

Cheers..!!!
Rahul S.
https://www.facebook.com/pages/HyperionPlanning/117320818374228