Cartons, zones and picking

One resolver, four outcomes. Scanning any code returns its kind and the actions permitted for it right now:

MC-4471 → carton → Receive · Count · QC · Move · Split · Open
MC-4462-A → sub-carton → Count · QC · Move · Split
319_A3_B12 → bin → Put-away here · Count this bin
319_PICKING → zone → Replenish · Count zone
E280 6894… → EPC → Unit timeline · Zone change

A carton scan followed by a bin scan inside 60 seconds executes the move without a confirm step. That pairing slot is one row per operator, so scanning a second carton safely replaces the pending pair.

In ops2, remove_pieces_to_picking calls record_movement(event_type="remove_to_picking"). That type is not in the valid-event set, so the call raises, and the caller swallows the exception with a comment saying movement logging is audit-only.

The result is that the carton is debited, the picking row is credited, and no movement row and therefore no ledger row is ever written. Every partial replenishment since that feature shipped is invisible to the ledger.

In i3 there is no audit-only path. carton_events.event_type is a foreign key to the event registry, so an unregistered type is a constraint violation at insert. The carton event and its ledger row are written in one transaction or neither is written. Nothing can swallow it into silence.

A multi-SKU parent's quantity is always the sum of its children, enforced by trigger. A parent contributes nothing to the reconciliation identity; only its children do.

Limits carried over from ops2: at most 20 distinct SKUs and 100 children per parent. A merge exists as the inverse of a split, for when the packing-list parser over-splits a mixed carton that arrived as one box.