Showing results for 
Search instead for 
Do you mean 


Some questions that I had:


1. Would you have 150% (with variants/effectivities etc.) MBOMs with a corresponding 150% BOP for every 150% EBOM


2. If the answer is YES, this would mean that top level part number for every 100% configuration of your MBOM remains the same. 100% MBOMs are just filtered views of 150% MBOMs based on the effectivity/variant values you choose. Correspondingly for every 100% configuration of MBOM, the 150% BOP will get configured automatically but the top level ID of the BOP remains the same for every config.

Now, this data would be integrated with SAP/ERP and MES systems. If Top level IDs of BOP remain the same. How are the routings / BOPs for 100% configs managed on ERP/SAp and MES side.


3. if the answer is NO. Every 100% MBOM and the Corresponding 100% BOP will have a separate Top level ID. But for every possible configuration (saleable) Teamcenter would have to maintain separate 100% MBOMs and 100% BOPs. This scenario becomes easier to manage on SAP and MES side but too cumbersome and messy on Tc side.


Whats your opinion?




Re: 150% EBOM-MBOM-BOP??

The 150% EBOM w/options and variants is configured then the configuration saved off as a new Item. The new Item EBOM is then used for the MBOM/BOP and communicated to ERP. Basically the 150% EBOM is a "master" for creating the individual configured EBOM's. Then all is normal after they have been saved off.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: 150% EBOM-MBOM-BOP??

Thanks Randy.


This way for each 100% EBOM configuration, we would have to maintain a 100% MBOM and 100% BOP. Can we not have 150% MBOMs and corresponding 150% BOPs as well? As we configure 100% MBOM BOPs get configured automatically for that 100% MBOM. This would reduce lot of overhead of maintaining each 100% configuration separately.


Any thoughts?

Re: 150% EBOM-MBOM-BOP??

The 150% EBOM to 100% MBOM/BOP is a one-to-many relationship configured using variants. Only classic variants support the sharing of variant structures (150% EBOM > 150% MBOM > 150% BOP). Variant structures consist of options, defaults and variant rule checks. They must be added to the top-level Item unless the assembly is shared with multiple top-levels then they must reside at the assembly level. Variants at the top-level override variants lower in the tree so some duplication may be needed to ensure the correct default is applied. You may need to duplicate variant rule checks lower in the assembly if the top-levels are not fully loaded. The modularity of the product becomes crucial.

Let's say you've completed all the above (not an easy task). Now you want to create the MBOM. Each plant has its own way of structuring the MBOM specific to its own workstations and resources. Same with the BOP.

A change to the EBOM to accommodate a new option would require a change to each of the MBOM and BOP that reference it even if the current product isn't modified. The work required for a change is still happening but at a different level of complexity. Maintaining 150% structures is not a small undertaking and requires "enlightened" users. In my opinion, users can deal with 100% structures as they are straight forward and the work is known where as 150% structures adds mystery and the impact is hard to predict. I can't even begin to fathom what an ERP interface would look like.

In summary, 150% structures are easy to break and hard to fix. Only classic variants are supported. Change requires modification of all top-levels (or their modular sub-assemblies). My recommendation is 150% EBOM > 100% EBOM > 100% MBOM > 100% BOP. And only for products where change is fairly static.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: 150% EBOM-MBOM-BOP??

The configured EBOM is closer to your product definition (minus the consumables, substitutes, BOM rearrangements etc).


Approach 1:

You may want to visualize this way and see if it solves your problem:

100% EBOM must be a child of a parent item/part. This parent item/part will be created each time you use an instance of an EBOM. The transfer to ERP must be done in the 'context' (not teamcenter in-context) of this top level. This top level parent object authored in PLM (through definition, training etc) can match your ERP Salesorder.


Approach 2:

You may want to create a collaboration context object (each time) to group your EBOM - MBOM - BOP (100%s). While you reuse your EBOM-MBOM-BOP, the collaboration context object (you can configure to allow your collaboration context object spit out a unique ID in Teamcenter) can be sent to ERP along with EBOM - MBOM - BOP.



Re: 150% EBOM-MBOM-BOP??

thanks a lot Randy!. This helps