Skip to main content

Hello Community,

We are migrating engineering part information into an existing implementation and have a need to create separate engineering part structures and hierarchies that utilize the same components.  For instance, Parts A and B may both utilize Part C as a child component, but the Part B hierarchy would have further children parts that Part A would not have.  

What we do not want is when looking at the structure and hierarchy for Part A, to see the child components related to Part B.  Further, we do not want modifications made to a parent/child to affect the structure of another part. 

Is this supported in Apps10, and if so, is there a recommended practice to implement this?  Looking at the engineering part structure data, it seems like this may be possible by delineating a structure ID, but I can’t find how to set that on the front end or through the migration documentation.  

 

 

You should migrate all of your parts first, all of them used in any structure, at any level as a flat list to the master and inventory parts so that all are available.  Then start from the lowest structure (determine the lowest depth of any part in any structure - is it 4, 5, 6, 7 levels deep). Start at whatever the lowest level is, migrate everything that is an assembly at the lowest assembly level.  Then do the next level above for all assemblies.  Keep working from bottom to top until you get to the catalog level items or top level.  Building it up in this manner, it won’t matter if part C is used in 1 or 100 other structures, it will only be treated as a part in the parent either A or B or both.  IFS handles this fine, it is the logic of your input spreadsheets and being clear about how everything is structured.  The hardest part I’ve found is validating that you’ve done things right.  There isn’t a good way I’ve found other than a good detail person and lots of checking.  Think from bottom up instead of top down and it will work out much better from my experience.