hello,
even if parent-child is not the preferred solution, it is unfortunatly the easiest one for us due to:
1. amount of data (need to have (too) many splitted files
2. multisource of information
then, in one file we can have
PARENT CHILD
A000001 A000002
and in antoher one:
PARENT CHILD
A000001 A000003
at the end the BOM Shall be as:
A000001
|-------A000002
|-------A000003
but we discovered that if you import file 1 and then file 2 (knowing that the option "For existing BOM relationships" is set to "Update the workspace") we have the following result:
A000001
|-------A000003
if know this information is on the same file, it seems to work... it is strange behavior... on a small set of data we have tried hierarchy method, it works fine but it would be too much effort to transform our data set ..... (any 'magical' solution on that may be?)
best regards
Yes, this behavior is as designed. Since we don't have any way of Deleting a BOM relationship using an import, we make the assumption that every import is complete with respect to the content of the BOM. So you cannot use it to Add BOM relationships.
With respect to the Parent Child import, it certainly has its uses and should be used when appropriate. The reason it is not 'preferred' is because it is somewhat counter-intuitive and does not support importing Historical Revisions (lifecycle states).
Hagay,
What I find counter-intuitive is to have to rebuild all the information in a level BOM after I've already created all the Items in the workspace. A parent-child BOM import seems to make the most sense since it is a one to one parent-child relationship.
For example I have an assembly with 100 parts in it. That is 100 parent-child relationships. Now if I use that assembly in 50 other assemblies... In a parent-child import that is 150 rows of info (100 + 50). In a level bom that is 5050 rows of info (50 * (100 + 1))
Also, maybe off topic, but how do you build BOM relationships with Items in another workspace? That doesn't seem to be supported by the import tool.