Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X
My suggestion is an 80/20 approach... get 80% ROI/Value add for 20% effort.
This amounts to using the Auto-Associate to build a WTPart Structure (Windchill eBOM) [transforming eBOM's to various downstream views via MPM-Link functionality on it's way to ERP/MRP is a bigger chunk of complexity but a definite future benefit]. Where you can run into issues here is when you leave the association as "Owner" you can run into quantity/UoM mismatches and other "frustrations" (like soft goods - a single hydraulic hose P/N with multiple installed shapes is a prime example). An approach that has proven to work is to change the Association to "Content". You'll also want to make sure that users are selective in their auto-associatingor you'll end up with meaningless components (as an example - a weldment modelled as an assembly: you probably don't want individualWTParts and P/N's generated for all of the items that wouldbe in a material cut sheet - just the welded component)I've found the best way to do this is to get everything uploaded and checked in and then doing a selective auto-associate using "mark for Check-In"
So in short,we've found that CAD driven build shifted to Windchill driven WTPart Structure isa suitable approachwith the CAD drivenBOM being an effective tool to automate the building of the BOM and constituent components, but flexible enoughnot to get hemmed in by the nuances ofCAD references and representation.
Hope this helps
What are your business requirements?
If your answers are fro 1 and 2 above, its fine to have ProE BOMs generate the BOMs. If you plan for 3 to 5, you will have issues of which functional group controls the entire Product BOM.
Something to think about for future plans of Windchill.
To answer the other thread regarding the push. At Psion, integration was being done via ECNs which contained generated mapped values of ERP information based on the nomenclature of the WTParts. This producedthe standard format of theBAAN ERPdatafiles which autmatically can beuploaded based on a call to BAANloader service. Since the ERP information was just the initial data entry point for default fields of the ERP information, it is best to keep it out of the PLM objects and used logical attribute mapping instead in the background. Thus, the ERP information will mature after the fact the PLM objects have released which will not result in changes in the PLM information.
In Reply to Steve Vinyard:
As a side question. How is everyone doing the "push" to their ERP?
Steve,
At Weatherford we use a listener service to catch the following events on a WTPart and WTPartMaster:
Rename
Change State
Check-in
If the WTPart version being checked in is the latest version, or in the case of the WtPartMaster if the latest version is in one of the following states then an update is published to ERP.
Prototype
Released
Inactive
Obsolete
This means Windchill updates the item master record in ERP, there we use a combination of the State in Windchill and the line type in ERP to control the Stocking type in ERP, Stocking type controls certain behavior. E.G.
Prototype parts can be manufactured, but not sold.
Released parts are completely open for transaction.
Inactive parts can be sold, but not bought or made.
Obsolete parts cannot be sold, made or bought.
We also pass the Engineering BOM from the Windchill WTPart to ERP, when a user creates a new Item Branch plant record in ERP particular to their location, they automatically “Inherit” the BOM as sent from Windchill. They can add new lines to this BOM, but cannot remove or modify lines that are managed in Windchill.
If you are interested in more detail on how all this works in more detail, it is available from a presentation I gave at the World event in 2009, “Feeding the Beast with Release to Production”.
Good luck,