# BOM Qty Issue

I have an Bom component that is 0.014.

When I create a Production Order, which creates a Pick List this componet is not there. If I change it from 0.014 to 1.014 this line shows up on the pick list but it shows it up to 1.00.

What am I missing?

Dear Mike,

first you have to specify Decimal Precision from 2 to 3.

it will not calculate .014 there is some limitation in AX for such calculation so it will calculate .5 or above.

not .01 or below.

in case you if find some solution with some sort of customization then please tell me also.

Mike Shy, you should consider to change the unit of measure for BOM consumption (Engineer section of the product information form), if you have kg as inventory unit, use g (grams) as BOM unit, so you can naturally change the number in the BOM or Fomula from 0.014 kg to 1.014 gr

Regards

Sorry! using your numbers it would be from 0.014 kg to 14 g !! [:\$]

I"m thinking there has to be a parameter. The standard BOM allows a quantity to be entered to 4 decimal places. So I create a bom that has a component that has a quantity of 1.41 and rounding set to ‘NO’.

I create a Production Order for 100 units. If I look at the BOM on the Production Order it shows 1.41 the Production Order Pick list shows 141 which is correct.

If I create a Production Order for 10 units. If I look at the BOM on the Production Order it shows 1.41 the Production Order Pick list shows no line because its less then 14 because it rounds to the whole number. even though rounding is set to ‘no’.

I’m doing this test on the new R3 Contoso environment. Anybody have any ideas or is having the same problem?

OK, I found the solution. In Units there is a place to specify rounding. I changed it from 0 to 4 and it works better. Even though its set to 4 it rounds to 2 but that is much better.

AX rounds to 2 throughout most aspects of the system. You can extend the EDT to greater than 2 for units, a debate that always causes issues. Essentially if you do this the physical change is relatively simple but because of the depth of the code, calculations and roundings Microsoft suggest that you parallel test this for 6 months on all processes and validate all calculations, which is a lot to ask, but without doing it whilst encountering some risk, MS can turn around at any point with any issue you have and point out that the EDT extension is probably the cause and not support you on the issue