Rounding error

geja

How do we solve a rounding errors in MTO items that uses SET as base uom but which our buyers prefer to buy in PCS.

For example, Item A is our code for three kings which is sold in sets of three. Therefore, the base uom of Item A is SET, qty per 1 and the equivalent uom of PCS is qty per .33333, Navision having limited the decimal places to 5.

Then Buyer A ordered 60 PCS of Item A. In the sales order document, the order qty would be 60 PCS. Internally, we produce this item in sets so in our production order documents, we will process 20 sets (60/3). All conversions will be ok until the order is finished. The problem arises when we ship the order. When Navision converts the qty 20 sets to pcs, the conversion becomes 60*.33333=19.9998 and leaves .0002 in the inventory.

I am thinking of following the SO uom in the production order but I'm not yet sure it will work. The item card base uom can no longer be changed once there is an open ledger entry for the item so we also cannot change it to PCS.

Savatage

The base uom should be the smallest qty "Piece=1"
your sale uom should be "Set=3"
your purchase uom could be either or whatever you want.

we changed all our BASE UOM to 1 an it solved all our problems.
for example we sell an item that we call a "deal"
the "deal" has 12 pieces in 1 box.
with the base uom set as 1 and the deal uom set as 12 they buyer can either order 144 pieces or 12 deals - it's all clean and neat.

this also allows us to sell a deal short. If 1 of the pieces is damaged we can sell the remaining as 11 pieces and all the prices and costs remain correct.

It's easier to start an item as 1 instead of changing it in mid stream.

This is the easiest way to solve the problem and they way it should be used.

Remember all the prices, costs and quantities need to be changed to match the base uom.

to us it was a big decision to break everything down to base uom of 1 because we had so many deal type items. But in the long run we are headache free and looking back it was the best thing we ever did.

....anybody else have an opinion...please post

geja

Thanks for the reply. Yes, I came to the same conclusion after some thought and that's how I discovered, to my consternation that base uom becomes unchangeable once the item starts having ledger entries, ie. purchases or sales records.

I guess we are stuck with this problem unless we decide to reload all data...

Dean_Axon

I guess we are stuck with this problem unless we decide to reload all data

not strictley true . You need to speak to a competent NSC who can write modiying reports and make sure that you are modifying all the relevant table entries. This is not the easiest thing in the world to achieve, but it CAN be done.

geja

Actually, I'm doing just as you suggested. Lately I have spoken to somebody in Singapore. I will ask if they can do this for us.

Thanks.