# Rounding Issue in BOM Calculation? - AX 2009

We are using AX 2009. We want to create a rework BOM to break down a case of 144 units into individual units. The individual units are the stock keeping raw material units that we are “making”.

Each individual from the 144 unit case undergoes a change to make it a generic raw material, so we created a BOM for each individual unit being made up of 0.0069 of the 144 unit case ( 1/144 ), plus an extra item to make it generic.

The cost of a case is about \$56.00, so the cost of each individual should be about \$0.39 before any transformation. However, the BOM calculation comes up with \$0.00 as the cost of an individual. I think that, for costing, AX may be rounding the 0.0069 to 0.0000 and multiplying that by the \$56.00 to come up with a zero cost for the individual in the BOM.

Is there a way around this, or do we possibly have a setup wrong somewhere? We do want to maintain just a full dollars and cents (not partial cents) valuation for the general ledger.

I appreciate any help you can provide. Thanks.

Craig Cermak

You would need to set a unit conversion up and in the rework BOM have the UOM as an each - roundings are always awkward when you make batches in 100’s and then want to make 1. I believe AX will hold it behind the scenes and it is a display rounding, but clearly if you make 1 then the cost is 0.01 rounded, but in its component calculation it is returning 0. Have a play with the each approach, otherwise express the component as a per series, so 1 per x of the parent - either way when you make 1 you will have an issue I believe.

Thank you for taking the time to reply, Adam. I will discuss this with my Manufacturing IT guy. We’re a private label wound care product manufacturer, and this finished good is for a specific customer that does not want the product anymore. Rather than dump or donate, we want to unpack the case and make the individual units generic again to pack into another customer’s case. Trying to go from the 144 in a case to one only seemed to cause us this costing problem. Anyway, thanks again.