[GG Rowe]

Hello!

We just started a PLM project and the question came up from the partner on why we are sending full BOMs from PLM instead just the changes.  i’d like to hear what others are doing and hear PROs and CONs on the option that they chose.  One CON we have on the AX side is that each new BOM has to be approved and activated.  There are also several fields on the BOM that needs to be added which is alot of manual work for our planning department.  However on the PRO side, it is easy to identify what BOM version was used on a production order.  As we discuss the BOM integration from PLM, it adds complexity to what is required in PLM and the integration logic to determine the BOM that should be sent.

Thank you in advance for sharing your business process along with the PROs and CONs.

——————————
GG Rowe, PMP
Oregon Chapter Leader
Chapter url: http://www.axug.com/portland
IT Applications Manager
Planar Systems, a Leyard company
Beaverton, OR 97006
USA
——————————

[Chan Stevens]

My random assortment of opinions to the variety of points you’ve raised:

• Assuming your interface from PLM to AX is custom, I would think you’d want to include in its requirement scope the automatic approval/activation of anything it sends down. If it’s not doing that, poke whoever created it and make that part of the automated process. The only reason I would think of that you’d intentionally want to manually click-approve and activate would be if you didn’t trust that the data all landed cleanly, such as some risk that a BOM component is also a new product that would have to be added within the bundle of stuff the interface is sending down and something goes wrong in that part add process, but interface exception handling is something I’d treat as a generic responsibility that should land somewhere in the IT world with reports and alerts, not something you want to push out to end users to have to keep looking at.
• Always add new versus add first/all subsequent=change “complexity” really isn’t that bad. You’d establish the PLM data as “system of record” and support only one-way flow (into AX). If someone changes, they change the PLM data and it flows to AX–don’t try to edit in AX and synch back upstream to PLM. As long as you have simple mapping of the “key” or ID field in PLM to the AX “key” field (BOM ID), whenever you need to send down a “change” instead of an add, your PLM simply selects the AX BOM mapped to the PLM BOM. I’d highly recommend that in AX you set BOM numbering to be manual, not automatic, so that the PLM “add” that creates any BOM would just use the PLM’s ID as the AX ID. Also, the “change” is only complex if you try to program the logic of figuring out which lines are new/adds, which lines exist but need to be deleted, which lines stay but have some fields changing, etc. Forget that–process the change as “keep my BOM header ID, delete all my existing lines, add all these new (complete PLM set of current lines)”, effectively replacing old BOM lines with complete set of new BOM lines instead of trying to figure out how to change the lines.
• Knowing which BOM “version” was used in production seems kind of useless–there’s a production BOM that is retained regardless of what later happens to the engineering BOM, the production order record only stores the BOM ID (not the ID and version), and if you’re really worried about whether something like whether the actual production pick list matches the historical as-designed BOM version, you could review transaction history to determine that.

In terms of whether to treat a change as adding a new BOM version versus sticking with one BOM version and replacing it, I generally recommend that sticking with single BOM version unless any of the following conditions apply:

• Any of the attributes that differentiate between versions (effectivity date, site, quantity). Date’s a pretty common one–if the change is not immediately effective, then you definitely need to send it down as a new version.
• For informational, historical, costing, etc. purposes you want the ability to compare old to new. For example, if you send down a new BOM, roll up costs, and some circuit breaker pops, it’s a lot harder to evaluate side-by-side the old and new.
• You have aftermarket/service/etc. activity that needs to be supported that need access to the older BOM information

——————————
Chan Stevens
Industry consultant
Cincom Systems
Cincinnati OH
——————————
——————————————-

[Nirav Modi]

?Good Day,

When we are working with the Integration, it is always better to Look at the following scenarios.

1. When we import Data from PLM to Ax, It should Generate the New Version and the Active Production Order will run with Version they have created with.

2. Sometimes it is possible that you have two or more BOM Version Activated based on the Site / Warehouse / from Qty & Date / and Product Dimensions.

3. If you change the existing BOM then you will not be able to generate Production order with older version, Sometime it is possible that you want to run Production order with different Specs / Versions, so If you change the Same BOM version every time then you want able to do that. ex. You have Customer with High end Product demand who is ready to pay Premium amount and another customer who is economic and want to go with Low end Product. so you might want to keep BOM Version with different Material Specs, so Your BOM will be same only Alloy or Metal will change in the item.

4. You can write a JOB to Approve and Activate the BOM Version when it is imported from PLM Software. so you have to run the JOB only.(Required Customization)

5.While Sending BOM from PLM You can Compare PLM BOM with active AX BOM Version and based on that You can create New BOM version in AX. (Required Customization)

——————————
Nirav Modi
Project Manager – Ax
Indusa
http://www.indusa.com
00919426381531
——————————
——————————————-

[Jack Moran]

Hi GG,
In general, would agree with Nirav and the supporting points he makes. Other consideration, is the PLM your using generating BOM versions on updates? If yes, then maintaining an alignment between the PLM and ERP systems offers benefits as well including other data in play on the PLM side such as 1) CAD drawings that marry to a specific BOM version within the PLM and then the BOM version within the ERP to which those same CAD drawings apply; 2) other BOM version data that may exist within the PLM such as work instructions that may need to be associated with a versioned Router file in the ERP system; and 3) historic lookups into the PLM and ERP system by installation & field services personnel to help in diagnostic and remediation activities.

——————————
Jack Moran
Director of Industry Solutions
Columbus Americas
Greenfield NH
——————————
——————————————-