Hi,
I think I now have enough information to solve this problem, and I'm
confident I can take it from here.
Thank you very much for your help and for taking the time to explain
everything so clearly. I really appreciate it.
Best regards,
Tomek
W dniu 30.06.2026 o 14:18, Aditi Patel pisze:
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
