Edit MBOM within a part that is in the baseline configuration of EBOM.

[ptc-89814]

[Description]

Ability to edit MBOM(Downstream) by using only non-latest parts that are in baseline configuration of EBOM (Upstream).

[Use case]

EBOM creates a baseline when its released and stores it as released configuration.

EBOM has multiple releases when its revised to keep/manage them as baseline configurations.

MBOM consists of EBOM config parts that are correspond to each release.

MBOM might not be created with EBOM therefore, to create MBOM that corresponds to formally released EBOM, MBOM should be edited within a part of EBOM baseline configuration.

[Problem with current functionality]

With currently available functionality(PSE, MPSE,PSB), BOM editing is done for only for the latest part.

Formally released MBOM cannot be edited directly by using config part of formally released EBOM.

Formally released MBOM configuration can be shown by baseline based display control(Filter) but the following issue still exists:

・MBOM（Downstream）and baseline need to be edited in parallel which makes operation so complex.

[GregoryPERASSO]

I'm totally agree with your business case.

And it is the right way to work with xBOMs. As the equivalence link between the EBOM and MBOM is "Context" filter aware. An Ebom release is valid for a mBOM release

But I don't think baselines are the "correct object" to use in your case. As baselines are "static" photography of your xBOMs. ie a baseline stores a specific iteration of the WTpart. And is more used to store a particular state . But not to work in ...

You should be able to do exactly that you want by using "effectivities" (date, lot, serial number etc ...) which is another type of BOM filter. But contrary to Baselines, is more "dynamic"

and do as in your screeshot:

eBOM (lot 1)->mBom (lot 1)

eBOM (lot 2)->mBom (lot 2)

you will be able to work concurently , at the same time on several lot (ie different release of your xBOMs)

And when a lot is fully released (eBOM and mBOM) you can still store is by populating a baseline with the filter lot1 , and then lot 2 ...

[GregoryPERASSO]

an exception for effectivities managed by Change Management :

since 9.0, effectivities are pending until the Change Process is resolved. So they can not be used to filter the BOM

you can vote for my idea:

http://communities.ptc.com/ideas/1204

Anyway, you're able to set effectivities directly by the UI, or customize the Change Management workflow to apply directly effectivities before releasing the lifecycle State of the BOM's WTPart

[ptc-89814]

Dear Gregory PERASSO,

You said that Baseline is more used to store a "particular state".
What is the specific business use case you assumed ?
Could you make it clearer ?

[GregoryPERASSO]

Dear Tsuyoshi,

as a baseline store a particular iteration of the WTPart. it is not realy easy to update it during a "work in progress" phase.

It is more used to store "static mile stones" of your BOM.

For example a "photography" of your BOM for the prototype 1 , prototype 2 ... or to store the BOM state in a particular phase of your project.

You will be able to visulaize, your product as it was in this milestone . Or compare Proto 1 and Proto 2. Or proto 1 with Latest BOM ...

Effectivities are "version" based. (not iteration), so you are able to work with , and not manually maintain them , even if your WTparts iterates (checkout/in) ....

You will , as for baseline, be able to visualize or compare, lot 1 with lot 2, etc ...

regards

Gregory

[ptc-89814]

Dear Gregory,

I understand what you want to say.

In our thought,
Effectivity and Baseline are same as the the function which control Filter.
When we edit MBOM（Downstream), we need to take care Effectivity or Baseline which drive Filter in parallel.
For example, How about the case to add Phantom Part to MBOM.
Evev if we use Effectivity, we edit MBOM and need to set lot numbers to each related parts in parallel.
We think those situations are complex.

Our focus is "Easy to edit".
I think our idea and your idea fill the gap with each other and isn't conflict.
It is good if both ideas are implemented.

[GregoryPERASSO]

I'm agree we you. Working with effectivities is more complex.

But because of the complexity of the business need. (lot or serial number trackability during product lifecycle)

But to my thought, it is not an "IT tool" complexity. But in most case an organization problem.

effectivities should not be managed "directly" on the BOM, but as a part of the Change Management process. If end users are aware on which "lot or MSN" they have to work. It is as easy  as to work in LATEST.... For that , need a "real" Change control board, who will analyse and scope several compatible Change Requests in the "next lot" ... Engineers have "just" to work in the context of this "nest lot"

Anyway.  I'm totally understanding the "esay to edit" need.

In my previous job, we need to provide "released" baseline between engineering and manufcaturing department. In order to work and track "stable" configuration. And we have done a customization around baselines. 

As they are not Versionnable. we create for each new product a "production" baseline , which contains the released WTParts.   And each time we need to modify the product, this baseline was "historized" (copy with a name+letter  (ie a fake version level)), and the "production" baseline was after that updated in certain lifecycle state.

For example, when engineering dprt set state to "prototype" , it updates the baseline. Which then can be used as upsteram context by manufacturing dpt in MPMLink. And then when Manuf dpt set to "released to production" state. It updates the baseline with new  manufcaturing views ...

[GregoryPERASSO]

Phantom Parts is a particular case. As they are not "real" parts (no stocks, no process plan, not consumable ..) It is only organisational nodes in the BOM. So to my thought , they should inherit the effectivity (baseline, lot , etc ... ) of their parent WTPart.

[GregoryPERASSO]

Dear Tsuyoshi,

If I understand your screenshots , you want to store the eBOM and mBOM in the same baseline (to keep the "equivalence" of the 2 BOMs)

But a baseline can store only a single version (ie View) of a WTpart. So it will work only in case of a "new downstream part" , but not in case "new view version"

regards

Gregory