Hi, Thanks for the clear write-up and reproduction steps! The good news is that nothing is broken here. What you are seeing is OFBiz working as designed: it does not perform automatic unit-of-measure conversion across the purchase -> inventory -> sales flow.
A few things that explain both observations: - Inventory is counted in stocking units, not by weight. ATP and QOH are plain numeric quantities with no associated UoM, and reservation simply subtracts the ordered quantity. That is why selling 1 reduces ATP by exactly 1 rather than 0.25. - receiveInventoryProduct does not copy Product.quantityUomId or the SupplierProduct UoM onto InventoryItem.uomId, so it is left null. And even when you set it manually, the reservation logic never reads it, so the math is unchanged. - Product.quantityIncluded / quantityUomId are descriptive packaging metadata, not conversion factors applied to inventory or orders. So both behaviors are expected rather than a bug. If you need to buy in one unit and stock or sell in another, the cleanest options are: - Normalize everything to a single stocking UoM and convert at receipt time, e.g. receive the 1 kg PO line as quantityAccepted = 1000 and keep the product stocked in grams; or - Add your own conversion using the convertUom service together with the UomConversion entity in framework/common. Hope this helps clear things up, and happy to elaborate on any of the above. Best regards, Aditi Patel On Tue, Jun 16, 2026 04:15 PM, Tomek <[email protected]> wrote: > Hi everyone, > > I am facing an issue with UoM (Unit of Measure) handling in OFBiz and > would appreciate some guidance. > > Here is my setup and the steps to reproduce the issue: > > 1. I created a test product and configured it with: > - Quantity Included: 250 > - Quantity Uom Id: Grams (wt_g) > > 2. In the Suppliers tab, I added a supplier and set their supplier UoM > to Kilograms (wt_kg). > > 3. I created a Purchase Order (PO) from this supplier, who sells the > item in wt_kg. > > 4. I received the shipment for this PO, which automatically created an > InventoryItem. > > Problem: > > The uomId field in the newly created InventoryItem was not populated (it > is null). > > Next, I simulated a sales order for this test product. After adding the > product to the order and approving it, the system decreased the > Available To Promise (ATP) on the aforementioned InventoryItem by exactly > 1. > > This issue persists even if I manually update the uomId field to wt_kg > directly in the InventoryItem. > > Questions: > > 1. Why does OFBiz seem to ignore the Units of Measure in this scenario? > > 2. Shouldn't the sales order reduce the ATP value by 0.25 instead of 1, > given the product configuration? > > Any insights on what might be missing or if this is an out-of-the-box > limitation would be highly appreciated. > > Thanks in advance! > >
