{"id":14215,"date":"2023-02-17T14:38:31","date_gmt":"2023-02-17T19:38:31","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/teamcenter\/?p=14215"},"modified":"2026-03-26T09:01:44","modified_gmt":"2026-03-26T13:01:44","slug":"drive-efficiency-bom-changes-teamcenter","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/teamcenter\/drive-efficiency-bom-changes-teamcenter\/","title":{"rendered":"Drive engineering efficiency by merging Bill of Materials modifications from multiple changes!"},"content":{"rendered":"\n

Managing changes is essential to deliver any industry product to meet customer needs. A vast majority of product development efforts involve teamwork and therefore many changes!<\/p>\n\n\n\n

In a perfect world, all change requests in the change process would arrive in sequential fashion and be implemented sequentially and quickly. <\/p>\n\n\n\n

\"changes\"<\/figure>
\n

Unfortunately, this is often not the case in practice.\u00a0Regularly, there are circumstances where a high priority change arrives while the implementation of a lower priority change is in progress. It is impractical to stop the partially completed low priority change to accommodate the higher priority change.\u00a0 For example, an engineering change may be in process while an emergency break-fix request is raised by manufacturing.<\/p>\n<\/div><\/div>\n\n\n\n

<\/div>\n\n\n\n

<\/p>\n\n\n\n

<\/div>\n\n\n\n

In short, you have separate change branches for a given item revision that are split. Then you start developing two different versions of one item in parallel.<\/p>\n\n\n\n

<\/div>\n\n\n\n

This satisfies your needs and gives you numerous possibilities. You can create separate changes for separate needs, simply use it as you want!<\/p>\n\n\n\n

<\/div>\n\n\n\n

At some point, you may want to merge these two parallel versions of the product together. What would you do with changes that affect the same products but are resolved differently?<\/p>\n\n\n\n

<\/div>\n\n\n\n

Don\u2019t worry. With Teamcenter Active Workspace 6.2, we\u2019ve introduced change merge function to help you to put your separate changes together. You can now merge an unincorporated released change in the current in-progress product design. While doing so, you can review the differences between two assembly versions side-by-side. You can merge one or all of the changes from source change to target change.<\/p>\n\n\n\n

<\/div>\n\n\n\n

What exactly is Change Merge?<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\n

Let\u2019s imagine a very simple scenario where we have our last assembly revision as A, this is where the product gets utilized with Change1<\/strong> and Change2<\/strong>, and each of them commits Revision B and C, respectively.  At this point the scenario looks like below:<\/p>\n\n\n\n

<\/div>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

Merge <\/strong>function allows us to merge changes from one change to another. In our case, we want to include Change1 <\/strong>to Change2.<\/strong> You can be on the target change, which is Change2<\/strong>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

System will then give you the new merge command to execute.<\/p>\n\n\n\n

<\/div>\n\n\n\n

How does Change Merge look?<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\n