Assuming the problem you stated, i.e. "when an entity is owned by multiple 5 trusts equally 20% each" is the actual problem you wanted to solve, then i would suggest that you use a dynamic approach instead of using a parent hierarchy.
After all, the "parent-child" relationship mentioned in your statement depends on the allocation % between the 'Entity' and the 'Trust', so a dynamic approach accessible to the end users, i.e. a module published in a dashboard, is preferable.
Having said that, do see if the following works, and we can start from there:
1. There are 3 lists to be created.
I'm introducing a new list 'Blank Members' to act as containers.
2. Arbitrary members are created for the 3 lists.
3. 'Entity Value' module is created to carry the value of each 'Investment Entity'.
4. 'Trust Assignment' is created as shown below, with lists of 'Investment Entity' and 'Blank Members'.
'Select Trust' line item is a list formatted line item.
Allocation % and Allocated Value are self explanatory.
I want to state that the above approach is more of a starting point to our discussion, since you might want to incorporate additional features.
in this case I would say that Currency is characteristic of e.g. Country.
Therefore, you would store this information in your System Module, where Country would be your dimension, and Currency as list-formatted line item, then you can easily load, or select Currency for all your list members. You can easily select EUR for all Countries, it does not matter.
I believe the response by @LipChean_Soh might be the most suitable for your particular case since a child doesn't wholly belong to one parent. To answer your question more broadly.....
Technically a child belongs to one parent in Anaplan lists, however, there are ways to design and implement the hierarchical list to accommodate situations where we need to present a child under more than one parent.
Here are 2 common cases:
1. A Product (List) that I sell to many Stores (List) and you want to plan/report on the level of Account-Product. In this case, you use a Combination List where you combine every valid combination of products sold in a particular stores.
2. I need to report the same data differently, then we use Alternate Hierarchy.
In this case, you have the calculation done once on the child level - say product- but you want to report the data not only by Product Family (original parent) but also by location or business unit or manufacturing location.
The point here is to take the same Products to create the new (alternate) hierarchy so I don't lose all the calculations already done for products. This is also called Clone List/hierarchy. You should make sure to use the same Product Code in the original and clone hierarchy lists and use a mapping (lookup/finditem) to link the 2 list items.
As for @CommunityMember111277 question, it raises a good point which is when to use a hierarchy and when all you need is an attribute (another line item)
You need a hierarchy if you constantly need to aggregate the data in a certain manner. When you think about currency, it's not considered as a parent to a country - i.e. I don't need to aggregate the country data up to a currency level. More likely, I need to assign every country the appropriate currency as an attribute or property, if I happen to need all the values by a currency type then I can use the SUM function. Value[SUM:Currency]
Hopefully, that's helpful as a starting point, if you have any questions regarding any of the information here please let me know and we can go into more and specific details.
Einas "Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime"