Microsoft Dynamics NAV has multiple ways in which you can handle scrap in the production. There are scrap related to an operation in the routing, there are scrap related to individual components and there are scrap related to the product being produced. Just like any other functionality, it is important to know all the options when configuring and implementing Dynamics NAV.

The scrap related setup has an impact on both the material and capacity planning. If you are using the standard costing method to value your inventory then the scrap related setup also has an impact on the cost roll-up. Scrap is quite common in a manufacturing environment and many companies could benefit from utilizing the functionality.

It is important to know that scrap in Dynamics NAV is truly scrap (waste), if it is something that you want to keep track of in the system as inventory and reuse somehow then it should be handled as additional output instead (e.g. by-products, reclaimed material, etc.). See my other blog post about Additional Outputs on Production Orders.

Below are the different options described with some examples where item A is produced by machining component B and then assembling it with component C. The routing with the two operations is setup like below.

The two components are in the production BOM like below. Note the routing link codes that link component B to operation 10 and component C to operations 20.

Now let’s look at the different scrap related options one at a time using the above routing and production BOM.

Scrap % on the Item Card

The finished item can have a scrap percentage defined on the item card. This scrap percentage refers to the finished product and is used by NAV to both increases the required components and capacity need. If you are producing a 100 units and you define a 10% scrap on the item card you will get the demand for a 110 units of the components and the capacity need will also be according to producing 110 units.

In Dynamics NAV you find the Scrap % field on the Replenishment tab of the item card.

When the production order is created the value of the Scrap % field from the item is transferred to the Scrap % field on the production order line.

The run time part of the capacity need on each of the operations is increased by 10 % (just like if we were making 110 units instead of 100).

The components required are also increased with 10%.

This could for example be used if you after completed production have an inspection of the units (part of the routing) and you expect a certain failure rate.

Scrap % in Production BOM

You can also have a scrap % defined on the production BOM lines. This will increase the required quantity for that component but will not affect any of the other components or the capacity needs for the operations.

You set this up in the scrap % field on the production BOM line.

When the production order is created the value of the Scrap % field from the production BOM line is transferred to the Scrap % field of the production order component and the expected quantity for the component is increased accordingly.

This has no effect on the production order routing.

The use of this could be if you have certain components that you consume where not all are going to be accepted for any reason, or if you only use a part of a component (like 9 inch of a 10 inch bar) and scrap the rest.

Scrap Factor % in the Routing

You can define scrap in relation to an operation as well. Dynamics NAV has a scrap factor % field in the routing that can be used to define if an operation generates scrap. This will increase the required quantities for all the components that are used in the operation and all previous operations. It will also increase the capacity need for the operation and all previous operations. If you use this then linking the components to the operations using the routing link codes are important (otherwise all your components will have increased quantities).

The scrap factor % is setup in the routing line.

When the production order is created the value of the Scrap Factor % field from the routing line is transferred to the Scrap Factor % field of the production order routing and the capacity need for the operation is increased accordingly.

The related components quantities are also increased accordingly.

This could for example be used for operations that have a certain expected failure rate.

Fixed Scrap Quantity in the Routing

Scrap related to an operation can also be defined as a fixed quantity. Dynamics NAV has a fixed scrap quantity field in the routing; it has the same effect as the scrap factor % but with the difference that it is specified in an absolute quantity instead of a percentage.

You set this up in the Fixed Scrap Quantity field on the routing.

When the production order is created the value of the Fixed Scrap Quantity field from the routing line is transferred to the Fixed Scrap Quantity field of the production order routing and the capacity need for the operation is increased accordingly.

The related components quantities are also increased accordingly.

This could for example be used for operations on a machine that needs to be setup and tested on a few units before starting the run. Another common example is if you are doing some destructive testing on a certain quantity as part of the operation.

Posting of Consumption with Scrap

Consumption should always be posted according to how many units you have consumed (both good and bad units). This way you get an accurate inventory balance and correct cost posted against the production order. Dynamics NAV does not differentiate between consumption of components that was scraped and components that was used in good parts, there is only one consumption quantity field and this is where the total consumed quantity should go.

If you want to record why you consumed more than expected then there is a reason code field that could be used. The reason code field is a field that is not in the journal by default so if you want to use this field you need to add it (in standard Dynamics NAV the reason code is setup against a journal batch instead of for each line, but just adding the field to the journal works good).

The Reason Code goes onto the value entries when the journal is posted and can be used to analyse reasons for scrap.

The downside of the reason codes are that they are not mandatory for scrap, and they are hard to make mandatory since there is only one field to enter the consumed quantity (you don’t want to have it mandatory all the time since it then adds an overhead when posting consumption). Because of this, I think a better way to record reasons for scrap is to use scrap codes for the outputs (described below).

Posting of Output with Scrap

For posting of the operation outputs Dynamics NAV has two fields, output quantity and scrap quantity. It is important the quantity of the good parts and the scrap parts are separated when posting the output. The output quantity is obviously the quantity that goes into stock (if it is the last operation) and carries all the production costs, while the scrap quantities are only recorded against the operation on the capacity ledger entries.

For output you also have a Scrap Code field where you can select a code to record the reason for the scrap.

The Scrap Quantity and Scrap Codes goes onto the capacity ledger entries when the journal is posted and can also be used to analyse reasons for scrap.

If you are back flushing your components (see previous post related to Flushing Methods) then the quantity of those are based on the output quantity plus the scrap quantity, so it is important to enter the scrap quantities in this case.

The scarp codes are in standard Dynamics NAV only for machine centers (for some unknown reason), to enable it for work centers as well you could change the code as below (to make it available for all types of outputs).

To make the scrap code mandatory if there is a scrap quantity, just alter the code as below. Making scrap codes mandatory when posting scrap makes the data more reliable, otherwise you sooner or later end up with scrap quantities without scrap codes.

As with anything else; setup some sample items and model how things behave before applying/changing the setup for a larger sets of items.