We are using IVc4.

One of our users wants to know if there's a way to process a Rev-Changing ECO that will Rev the assemblies/sub-assemblies without having to copy a BOM from Engineering to Production?

We have created a session to reverse copy a PBOM to an EBOM. She would like to make the changes in Production and then use this session to reverse copy the BOM back to Engineering.

Any help would be appreciated.

The entire concept of EBOMs and ECOs is that the engineering side of the system is the controlled standard. Revisions are created and controlled in engineering, so I don't know how you can start the process from the other end and maintain control (how do you create a new revision BOM in production when the revision has to be created in engineering?).

I think you have to either use revision control, based on the engineering data, or stay out of EDM competely and not have revision control (very dangerous in my opinion).

The ECO itself will copy the BOM to production for you. Are you trying to avoid the copy action? Why are you trying to initiate changes from the production side of the system?

Jim,
Thanks for your response. We do create all new revisions in engineering, but we have some ECOs that do not change the revision of the item. In those cases, only the PBOM is updated. We then run the session we created to copy a PBOM to an EBOM to keep the BOMs insync.

I probably didn't word my message very well, but you are correct. We are trying to avoid the BOM copy from Engineering to Production. We are trying to restructure a large number of BOMs that all need to be implemented on the same date. These will all be rev changing ECOs. Due to the large number of ECOs that need to be processed, we want to try to do them ahead of time and use a future date. To complicate things further, we may also need to implement an unrelated ECO for one of these parts that would need to be implemented prior to the effective date of the ECO for this mass change. The problem is that when this process was tested out in our test environment, our user found that the PBOM was not being updated correctly.

I guess I'm still having a hard time understanding how you handle engineering changes.

You have some ECO's that don't change a revision? I would have to assume that what you're doing is making a clerical update where you're not actually changing a BOM or an item spec but are using the ECO as a vehicle for traceability. Yet, on these same changes you're changing the PBOM and copying it back to engineering. Doesn't this then change the current revision of the EBOM (without making a revision change)? It still seems like using the ECO to control the changes and copy the EBOM to PBOM would be the way to go, but apparently I'm still missing something.

If you have a large number of changes to make, I would suggest putting them all on one ECO if possible and set the effective date in the future. That should work fine. The individual revision change should be processed and dated before the mass change. Remember that if you date a new revision in the future, it kind of ties up the revisions and you can't effectively make another revision change until that post-dated change takes effect.

What am I missing on the BOM change issue? You can e-mail me directly if you'd like.

Jim