Using alternative production BOMs or routings is quite common in a manufacturing environment. It could for example be that larger orders are run in higher capacity machines, versions of products are produced with slight variations in components (like different colors), or you might produce the same item in two different locations and therefor need two different routings. These are just some examples, there are many more scenarios like that where you might need to change the production BOM or routing based on different factors.

Microsoft Dynamics NAV allows you to manually change both the routing and production BOM used on each individual production order. This blog post describes how this is done manually and also how you can automate the process with some relative simple modifications. If you frequently are changing production BOMs and/or routing on production orders then automating it would be an alternative (kind of a requirement if you run MRP and want accurate suggestions).

In the examples below I will use a bicycle that is produced in two different locations and in different colors. The different colors are managed using variant codes on the item like below (blue and red color bicycle).

The bicycle has a standard production BOM and a routing that represent how it is typically produced (and it is also the ones that is used in the standard cost roll-up). Those are what are selected on the item card for the bicycle.

In addition to this I have create two alternative production BOMs for the two different colors; 1000-BLUE for a blue bicycle and 1000-RED for a red bicycle. They share the same components except for the paint component (blue paint in one and red in the other).

For the routing I have an alternative routing created for producing the bicycle in my TAMPA location. This alternative routing have a different work center and a different operation.

That should be what is needed in terms of setup.

Manually Change Production BOM or Routing

Now when a production order is created it will always use the production BOM and routing from the item card, to manually change this you just select an alternative on the production order line and then refresh the component and/or operations. Below I changed the routing no. from 1000 to 1000-TAMPA.

When you refresh the production order after you have changed the production BOM or routing then remember to uncheck the Line option, otherwise the field you just changed will be set back to the standard values.

Now the components and routing on the production order will be according to how the alternatives are setup. Simple and easy.

Note that you can also change the components and/or the routing manually on individual production orders as well without changing the production BOM no. and routing no.  on the production order line. This might be the more common way of doing it if the change is due to an exception (like a machine that is down, or a component that is missing).

Automatically Change Production BOM or Routing

Now to the fun stuff! 🙂

If you want Dynamics NAV to automatically select a production BOM or routing based on criteria like order quantity, location or variant code then this is relatively easy to do with a customization. Below is a suggestion of how to do it.

We need a setup to define the criteria for the alternative BOMs and routings. For this I create two new tables, one called Alternative Prod. BOM and the other called Alternative Routing. You could potentially do it with one table, but this is how I did it in this case (having two different tables could be an advantage from a permissions point of view, if you for example have engineers that are maintaining the BOMs and manufacturing people maintaining the routings then you probably want it separated).

The primary key for both the tables are Item No., Variant Code, Location Code, Min Order Size and Max Order Size. What fields you put in the tables depends on what logic you want NAV to use when selecting the alternatives.

The alternative Prod. BOM table is according to below. I have entered a setup to link the two production BOMs to the item and its variant codes.

The alternative Routing table is according to below. I have entered a setup to link the alternative routing to the TAMPA location for item 1000.

You can potentially add the above tables to the item list and card like below, so that users can easy access them from an item.

Now we need to write the logic for NAV to select the correct alternative. The logic is going to be used both when new production orders are created manually and when the planning worksheet is generated as part of MRP. If I know that something is going to be used in multiple places I typically place the code in a separate codeunit (instead of create new functions in each of the objects with the same kind of code). In this case I created an Alternative Prod. Mng codeunit where I placed two functions, one for retrieving the production BOM and one for the routing.

The functions above are self-explained I think, they basically returns the production BOM no. or routing no. based the parameters it is called with. If no alternative is found then the standard one from the item record is returned.

Now we have the tables where we do the setup and the functions to select and return the production BOM no. and routing no.. Next we need to place some code in the standard objects where the production BOM and routing is going to be selected.

The object to change is the prod. order line table, this is where the standard Dynamics NAV code for retrieving the production BOM no. and routing no. from the item record exists. We changes this so that the new functions in the codeunit above is used instead. This is the in the OnValidate trigger of the item no. field in that table. The code needs to be changed in two places according to below.

The above code change is all it takes to have production order that are refreshed to use the alternative production BOMs and routers. If you also want the same logic to happen if a user manually changes a production order line you need to insert the same code into the OnValidate triggers of the fields that are included in the logic. Wrap the code with ‘IF CurrFieldNo = FIELDNO(“Variant Code”) THEN BEGIN’ to not get a crazy circular reference. Something like below.

This should be it for the production orders that are created manually. Next we do similar changes to the MRP suggestions.

To do this we need to change the requisition line table. The change to the code will be very similar to what was done above to the prod. order line table. In this case it is in the OnValidate trigger of the replenishment system field where we basically replace the places where NAV retrieves the production BOM no. and routing no. from the item record with the new functions in the codeunit. Something like below.

And just like with the prod. order line table, if you want Dynamics NAV to automatically update the production BOM and routing if a user manually makes changes to the MRP suggestions in the planning worksheet then you will have to add code on those fields that are included in the logic, like below.

This should be all, time to test it! 🙂

I create a new production order for 10 bicycles by entering the item no., due date, location code, and quantity and then hit refresh. I can see that a production BOM and routing is selected on the line and it seems to be as expected (the standard ones).

Now I change the location code of the production order to the TAMPA location and refreshes the entire production order. The routing on the line changes accordingly. Nice! 🙂

Next I change the variant code on the line to be the blue bicycle variant and you can see the production BOM changes. You also need to recalculate the components after this (Dynamics NAV does not have a variant code in the header of a production order, which is a bit strange in my mind, but off-topic for this post).

The production order all seems to work fine. We also need to test the MRP suggestion. This can be done by setting up some SKUs with some planning parameters, running the plan and look at the suggestion. In this case I create 4 SKUs (blue/red variants on two different locations) with reorder point higher than the projected quantity on hand.

When I run the MRP I get the following suggestions in the planning worksheet, where the production BOMs and routings are selected based on my criteria. Sweet! 🙂

Just to be safe you should also check the planning components and planning routing to confirm that they are according to the production BOM and routing in the planning worksheet. This is what will drive the demand for the components and the allocation towards the work centers.

Planning components above looks good (the red variant gets the red pain component).

Planning routing also looks good (the suggestions on the TAMPA location gets the TAMPA routing).

Note that if you are using versions of production BOMs and routings then this should work as well since the code for finding the valid version is in the OnValidate triggers of the production BOM no. and routing no. fields.

Summary

As a summary I would say that if you are handling exceptions with alternative production BOMs or routings then changing them manually on individual production order would probably be fine (and this way you don’t need to do any modifications). You can also manually change individual components and operations without using any other production BOM or routing.

If alternative production BOMs or routings are frequently used, the doing some kind of modification like above would make sense (and it is not a big thing to do as you can see). The logic you build into selecting what production BOM or routing to use would be up to your business requirement.