In the web UI, "adjust to absolute" is probably the wrong tool for inventory, and the kind of thing that should almost never happen. And inventory post is probably also an excessively-powerful primitive ("reason" is too freeform to say much about why something happened). Instead, users should have a reasonable fixed set of verbs for inventory. Also, all inventory should have a revision. For instance, I think the journal.ndjson should probably have something like:
{"txn": ..., "location": ..., "rev": "B02", "op": "build", "qty_delta": 200, "build_id": "b_..."} (optionally, serials in there; optionally, unit_cost) Because it is a build, the qty increases. Also because it is a build, it necessarily consumes its direct BOM items; those BOM items get "op": "consume" logged in their journals under the same txn. Happens as a result of a build completing.
{..., "op": "consume", "qty_delta": -300, "build_id": "b_..."} (optionally, serials)
{..., "op": "scrap", "qty_delta": -38, "reason": "..."} (optionally, serials; optionally, build_id)
{..., "op": "count", "qty": 54} We re-counted the inventory on location. No idea what happened before, but now we have 54 of them there.
{..., "op": "buy", "qty_delta": 38, "workorder": "...", "unit_cost": 5.38} We bought some of these, and here is how much they cost.
{..., "op": "sell", "qty_delta": -38, "workorder": "...", "unit_cost": 12.63} We sold some widgets!
{..., "op": "transfer", "qty_delta": 38} We shipped some from one location to another location. The other location has an opposing qty_delta with the same txn.
In the web UI, "adjust to absolute" is probably the wrong tool for inventory, and the kind of thing that should almost never happen. And
inventory postis probably also an excessively-powerful primitive ("reason" is too freeform to say much about why something happened). Instead, users should have a reasonable fixed set of verbs for inventory. Also, all inventory should have a revision. For instance, I think thejournal.ndjsonshould probably have something like:{"txn": ..., "location": ..., "rev": "B02", "op": "build", "qty_delta": 200, "build_id": "b_..."}(optionally,serialsin there; optionally,unit_cost) Because it is abuild, the qty increases. Also because it is abuild, it necessarily consumes its direct BOM items; those BOM items get"op": "consume"logged in theirjournals under the sametxn. Happens as a result of a build completing.{..., "op": "consume", "qty_delta": -300, "build_id": "b_..."}(optionally,serials){..., "op": "scrap", "qty_delta": -38, "reason": "..."}(optionally,serials; optionally,build_id){..., "op": "count", "qty": 54}We re-counted the inventory on location. No idea what happened before, but now we have 54 of them there.{..., "op": "buy", "qty_delta": 38, "workorder": "...", "unit_cost": 5.38}We bought some of these, and here is how much they cost.{..., "op": "sell", "qty_delta": -38, "workorder": "...", "unit_cost": 12.63}We sold some widgets!{..., "op": "transfer", "qty_delta": 38}We shipped some from one location to another location. The other location has an opposingqty_deltawith the sametxn.