What's the intended behaviour with dual UOMs?

My business case: I have a product X, which comes in bags of 25 kg. The price however is per Kg. The stock is alsoin Kg, as it might happen that a customer wants 20 kg of product X.

So buying is always in bags of 25 kg. Selling can be in 25 kg or less.

I have created the item with a primary UOM as Kg.
Set up a new UOM called “Bag 25 kg”
Set up a conversion factor for Product X between “Bag 25 kg” and “Kg” with factor 25.

Now when I create a new purchase order, and I enter the quantity as 2, UOM as “Bag 25 kg”, the price is not 50 x price, but 2 x price, which is the kg price. Manually overwriting the price works, but that’s not my issue.

So my question is: is this intended behaviour? Or should the price have changed to account for the secondary UOM? I have a feeling it should.
If the price is not changed, and you leave the Kg price, the Purchase Receipt will use the Kg price and the recalculated quantity, meaning the Stock is updated with 25 Kg correctly, but at the price of 1 Kg…

If this is a bug, I’ll log it in Github. If I misunderstood the intended behaviour, please enlighten me.

update: I’ve tested this in V5 by the way

Here On Production Order
For ‘Rate’ Field =Enter the rate for one bag

I kg =10 USD
Rate for one Bag =One bag contains 25 Kg
= 25* 10
= 250 USD

If we Enter Qty=2 and Rate=250 then Amount =500 ( auto display)

Geetanjali Shitole
New Indictrans Technologies Pvt. Ltd.

Good, so in manufacturing it is working as expected.
But from Purchasing perspective it isn’t
Tested v4 as well (demo VM) and there the same issue exists.

If the item comes in 25KG but you sell in say 1KG, how about set the item UOM as KG alright, but when receiving from supplier, rather than receive say 5 of 25KG, receive 125KG instead. So say price of one 25KG from supplier is $100, then in your GRN, you receive 125KG at a price of $4/KG, making a total of $500 (100 * 5). That’s what I do in one setup.

That’s a workaround, not a solution.

If I’m able to buy in multiple UOM’s, the price should be calculated correctly. The more I’m testing this, the more I’m convinced this is a bug. I’m logging it in GitHub to get an expert opinion from the crew :wink:

TLDR; price is as per stock UOM not purchase UOM? is that the issue? Post this on GitHub!

issue 2798 has been logged

I’m having the same issue…