Hi Tomek, Both notes are right.
1. Yes, post a -7 and a +7000 rather than editing the existing row. That's how InventoryItemDetail is meant to work: it's append-only (the entity even re-sums all diff rows into the totals on each insert), so the original +7 stays for audit and the item lands at 7000. Just apply the -7 / +7000 to all three diffs (QOH, ATP, accounting), not only QOH, or the totals drift apart. One catch on cost: that rollup only sums quantities, not InventoryItem.unitCost. So set the /1000 cost on the item itself via updateInventoryItem, in the same call where you set uomId. 2. Correct: uomId is a field on InventoryItem, and Product.quantityUomId is the pre-configured target unit (g) the SECA reads for the conversion. Keep the earlier guard so you only convert when the item's uomId still differs from it. Best regards, Aditi On Tue, Jun 30, 2026 05:34 PM, Tomek <[email protected]> wrote: > > > On the split: you don't need to create a new InventoryItem yourself. > > prepareInventoryTransfer already handles that. A partial transfer clones > a > > new item > > for the moved quantity and reduces the source; a full transfer just moves > > the > > original. So by the time completeInventoryTransfer runs you already have > a > > single > > item (InventoryTransfer.inventoryItemId) at the destination, with the > > quantity moved > > 1:1. Your SECA just converts that item in place: add an > InventoryItemDetail > > with the > > converted values (convertUom, x1000 for kg -> g, inverse on unitCost) and > > set uomId > > to Product.quantityUomId. No second item, and no zeroed-out leftover to > > keep around > > for history, since the InventoryTransfer record already is the history. > > > Hi, > > Thanks for the detailed breakdown of the completeInventoryTransfer > mechanism and how prepareInventoryTransfer handles the item splitting. > That makes a lot of sense. However, I have two quick notes regarding the > actual conversion logic, as these technical details are quite important > in OFBiz. > > 1. The InventoryItemDetail and quantity summation issue > > Let's say we transfer 7 kg. Once the transfer completes, the system > automatically creates an InventoryItemDetail record with a quantity of > +7. If my SECA simply inserts another InventoryItemDetail with +7000 > (grams) and the recalculated unitCost, the resulting quantity on hand > would become 7007 g instead of 7000 g. > > Since I would prefer not to modify existing InventoryItemDetail records > in order to preserve a clean audit trail, I think the safest approach > would be to create two additional InventoryItemDetail records within the > SECA: > > The first InventoryItemDetail with a quantity of -7, effectively > reversing the original movement. > A second InventoryItemDetail with a quantity of +7000 and the > recalculated unitCost (divided by 1000). > > This would preserve the full history while leaving the final inventory > quantity at 7000 g. > > Would you recommend this approach, or did you have a different > implementation in mind for handling the InventoryItemDetail records? > > 2. Updating the uomId > > When you mentioned "set uomId to Product.quantityUomId", I assume you > meant updating the uomId field on the InventoryItem, correct? > > I am also assuming that Product.quantityUomId is already configured on > the product beforehand (for example, set to grams), and that this is how > the SECA determines the target unit for the conversion. > > Let me know what you think of this approach. > > Best regards, > Tomek > >
