Thanks for your reply. I'm trying to build out the hierarchy using views as you suggested. Not been completely successful there.
One question though. If a child item is going to be used in multiple Parent item, how do I load the hierarchy so that it goes and sits in all parents as a child list item.
So a child can have multiple parents? That complicates things.
Is there a maximum number of parents (say, up to five) or do you need to support an arbitrary number of parents? Also, can a material have multiple children as well as multiple parents? That would make it a many-to-many relationship, which can't be modelled in a hierarchy.
Well. Its a Bill of Material. So a parent can have multiple children. And each children can have multiple children underneath. So multiple Finished Goods/Semi Finsihed Goods can have the same child ingredient.
In a flat structure it only shows as a single record.
As you can notice above, Finished Goods A and A1 both require B. Now, how do I build this hierarchy to ensure that B goes into both A1 and A.
This looks bit complicated to me too, let me try to see if this should solve it
1) Identify maximum number of processes required to manufacture a material
2) Based on number of processes required group the materials accordingly into subsets
3) Then create The material mix modules for each level of process and call only those materials which are part of that process
4) Have a numbered list in those modules and line items BOM, Materials requried
5) Let BOM be the End product (List formatted with that particulare level), Material required to produce (Total materials list formatted)
6) Cost of the materials : Let this be a look up of the previous level processes modules
7) Have final cost module to do a sum if of all the materials from all the material mix modules
This is very lengthy process but would surely work.
In that case I'd use a numbered list to define the relationships, which the user would enter, and then I'd have your Material Hierarchy as a second numbered list. So you end up with these three lists:
Material Relationships (numbered list with two Material properties called Parent and Child, plus any additional information about the relationship, such as how much of the child material goes into the parent material)
Material Hierarchy (similar to the Material Hierarchy I talked about yesterday, but as a numbered list, permitting a child material to appear under multiple parent materials)
The action to populate Material Hierarchy should now run off a module dimensioned by Material Relationships, and you should clear out the Material Hierarchy list before each import. And you may also need a separate action to insert materials that don't appear in the relationships list.
Everything else should work as I described before.