This is an internal working record, not an everyday instruction. It was written while the system was being rebuilt, for whoever maintains it. If you are here to do today's work, use the everyday documents instead: Procedures · Processes · Runbooks · The working day, step by step

MK Inventory Allocation Reconciliation¶

Status: DETAILED SOURCE-RECONCILED PROCESS INPUT / OWNER REVIEW REQUIRED
Process: PROC-OMS-INVENTORY-TO-OUTBOUND-ALLOCATION-MK
Process contract: MK_SCHEDULE_ALLOCATION_WORKFLOW.md
Rebuild packet: MK_INVENTORY_ALLOCATION_CAPABILITY_REBUILD_PACKET.md
Source authority: MK_INVENTORY_ALLOCATION_SOURCE_AUTHORITY.md
Operating profile: mk-order
Effect boundary: documentation only

1. Reconciliation Result¶

The current Allocation Workbench is not a generic order editor and does not create a new shipment. It consumes eligible inventory into one existing Outbound Sales shipment.

Eligible Inventory Lot
-> client-side basket
-> existing Outbound target
-> new target Item per source row
-> T_LOAD_ALLOCATION relation
-> source remaining-weight decrement

The Process remains separate from Inbound, Outbound, Booking, Scale, Packing and Delivery.

2. Process Purpose¶

Allocation establishes the accepted inventory-consumption relation between:

received source inventory
and
outbound shipment demand/execution

It must answer:

which exact source lot was consumed;
which exact source order/item/transload produced it;
which exact outbound order/item received it;
what quantity, weight, UOM and rate were accepted;
what balance remained;
whether the request committed, conflicted or is unknown;
how correction/reversal is handled;
which next process owns physical execution.

3. Trigger, Preconditions And Completion¶

Boundary	Reconciled contract
Trigger	An authorized MK inventory/shipping operator needs to assign received inventory to an existing outbound shipment.
Source preconditions	active same-tenant lot; accepted source relation; eligible lot state; positive accepted balance; commodity/UOM policy satisfied
Target preconditions	active same-tenant Outbound Sales order; accepted active container/equipment bridge; target not downstream-locked for the operation
Basket preconditions	unique source identities; accepted full/partial amounts; one target; current freshness; no prior unknown request
Local completion	target item(s), allocation relation(s) and source balance updates commit in one accepted transaction and are reread
Incomplete	response missing, balance/identity mismatch, target/source changed, child rows disagree or correction/reversal unresolved
Next handoff	Outbound/Scale/Packing/Delivery owners consume the target order/item; Allocation remains the relation/balance owner
Cancellation	no universal current unallocate path is source-confirmed; correction/reversal remains policy-owned

4. Current Normal Path¶

`STEP-010` Enter and identify source context¶

Enter mk-allocation-workbench through the assigned menu.
Confirm MK tenant/profile and role.
Choose source mode/filter and optional Inbound order.
Search by source order, reference, commodity, lot or related identifier.
Open source evidence when identity is ambiguous.

`STEP-020` Select source lots¶

Review lot status, source order/item/transload, commodity, UOM, inbound quantity/weight, remaining quantity/weight and warehouse/source-mode projection.
Add only intended rows to the basket.
Current UI adds the full displayed remaining lot; it does not support entering a smaller partial amount.
Do not assume disappearing from the list means a previous allocation completed correctly.

`STEP-030` Select an existing outbound target¶

Search the intended Outbound Sales shipment.
Confirm order, Booking/reference, container, size and equipment bridge.
Current Workbench does not create a target order.
A target list row is eligibility input, not proof that all downstream work is ready.

`STEP-040` Review basket and target¶

Confirm one target and every source row.
Compare commodity, UOM, quantity, weight, rate and source identity.
Confirm no earlier request is unresolved.
Current source has no durable preview/version/idempotency record; future target must add one.

`STEP-050` Apply once¶

Submit one Apply request.
The current server uses one local transaction for the entire basket.
For each row it creates a new outbound item and one allocation relation, then conditionally decrements source remaining weight.
If a later row fails, the request is expected to roll back all earlier rows.

`STEP-060` Exact readback¶

Reread:

target Outbound order;
created target item IDs;
active allocation rows;
every source lot;
remaining quantity and weight;
target equipment bridge/readiness;
any downstream child that the operator plans to continue.

Completion is not established by the success message alone.

`STEP-070` Continue downstream¶

Proceed only through the owning child:

Scale
Packing
Delivery
Cost/Trade/Documents

Allocation completion does not complete those processes.

5. Current Transaction Boundary¶

Current Apply is one request-level local transaction.

sequenceDiagram
    actor Operator
    participant UI as Allocation Workbench
    participant API as Allocation API
    database DB as MySQL

    Operator->>UI: Apply basket to existing target
    UI->>API: Target + all source rows
    API->>DB: Begin transaction
    loop each source row
        API->>DB: Create target Outbound item
        API->>DB: Create allocation relation
        API->>DB: Conditional remaining-weight decrement
    end
    alt all rows succeed
        API->>DB: Commit
        API-->>UI: Target and created item IDs
    else any row fails
        API->>DB: Rollback
        API-->>UI: Error
    end

No provider, file, email or device effect is part of this transaction.

6. Current Source Eligibility And Write Revalidation¶

Source query checks¶

The source list currently considers:

active lot;
LOT_STATUS='OPEN';
positive REMAIN_NET_WEIGHT;
source order/item/transload relation;
source mode and optional filters.

Write checks¶

The write helper checks:

tenant/lot existence;
positive allocation weight;
sufficient remaining weight;
target order/equipment bridge eligibility;
conditional affected row count.

The write is not represented as one explicit predicate that rechecks every list condition, source relation, UOM and quantity rule. Target design must close that gap.

7. Quantity And Weight Reconciliation¶

Current immediate Apply behavior:

T_LOAD_ALLOCATION.ALLOCATED_QUANTITY recorded
T_LOAD_ALLOCATION.ALLOCATED_NET_WEIGHT recorded
target T_LOAD_ITEM quantity/weight recorded
T_INVENTORY_LOT.REMAIN_NET_WEIGHT decremented
T_INVENTORY_LOT.REMAIN_QUANTITY not immediately decremented

Inbound lot synchronization can later recalculate remaining values from source and active allocation sums. This creates a reconciliation dependency and potential disagreement after post-receipt source changes.

Required Process decision:

which measure is authoritative by UOM;
whether both must be conditionally consumed;
how conversion/rounding works;
how drift is detected and corrected.

8. Target Item Behavior¶

Current parity behavior creates one new T_LOAD_ITEM per source-lot basket row.

This means:

one target order
+ multiple source lots
-> multiple newly created target items

The target migration should preserve this initially unless Product accepts allocation against existing demand lines. A redesign requires explicit demand identity, split/merge, line-level quantity and correction policy.

9. Duplicate And Unknown Result¶

Current risk¶

No durable request token is source-confirmed.

Apply commits
-> response is lost
-> operator clicks Apply again
-> another target item/allocation may be created
-> source may be consumed again if balance permits

Required recovery¶

preserve the basket/source/target identities;
reread target items and allocations;
reread source lot balances;
determine committed, absent, partial/conflict or unknown;
accept the existing result when committed;
retry only when absence is established;
never replay the complete basket on assumption.

10. Concurrency¶

Two operators can select the same source before either commits.

Current weight decrement uses a conditional lower-bound update. This can reject the losing request for weight overdraw, but the complete quantity/UOM/duplicate/source-state policy remains distributed.

Target invariant:

one accepted source balance cannot be consumed twice

Target command also requires request idempotency and exact result readback.

11. Correction And Reversal¶

Current general unallocate/reversal is not source-confirmed.

Target distinctions:

Correction
= accepted allocation identity remains; approved value/evidence changes through an audited command

Reversal
= original allocation remains; compensating relation restores source balance and disposes target line explicitly

Delete compatibility
= current soft-delete mechanism; not automatically the target business model

Before correction/reversal:

reread Scale/Packing/Delivery/Cost/Trade/Documents;
reread target item and source lot;
confirm downstream locks and business reason;
require stronger capability;
preserve original evidence.

12. Adjacent Process Boundaries¶

Inbound Purchase / Inventory¶

Inbound owns receipt and source-lot materialization. Allocation must not correct receipt by editing source rows. Post-receipt changes must reconcile active allocations and balances.

Outbound Sales¶

Outbound owns shipment demand/header/items. Ordinary Outbound Save does not allocate. An allocated target item must not be changed without Allocation reconciliation.

Booking¶

Booking owns Booking data. Target Booking Save must not mutate allocations. Current compatibility behavior remains a migration risk and recovery input.

Scale/Packing/Delivery¶

These children may lock correction/reversal. Their completion remains separate.

13. Exceptions And Safe Recovery¶

ID	Condition	Safe recovery
`EXC-010`	source lot hidden, closed or stale	reread source order/item/transload/lot; do not force list visibility
`EXC-020`	target missing container/size/active bridge	correct target in Outbound/Booking/equipment owner
`EXC-030`	insufficient/stale remaining weight	refresh source and active allocations; rebuild preview
`EXC-040`	quantity/weight/UOM conflict	stop and obtain accepted conversion/correction decision
`EXC-050`	basket row failure	current parity expects whole rollback; reread all rows
`EXC-060`	response missing	reconcile target item/allocation/source lot before retry
`EXC-070`	concurrent winning allocation exists	accept winner and refresh; do not overwrite
`EXC-080`	Outbound item changed after allocation	reconcile through Outbound + Allocation owner
`EXC-090`	Inbound source/lot changed after allocation	reconcile through Inbound/Inventory + Allocation owner
`EXC-100`	Booking compatibility changed allocation	preserve all child IDs and stop downstream work
`EXC-110`	operator requests unallocate	use approved reversal policy or escalate; no manual delete/balance edit
`EXC-120`	foreign/denied record	return through assigned account/menu; no direct-ID workaround

14. Completion And Non-Implication¶

Allocation completion proves only:

accepted target item(s) exist;
accepted allocation relation(s) exist;
accepted source balance update committed;
exact rows reread consistently.

It does not prove:

Outbound commercially complete
Scale complete
Packing complete
Delivery complete
Booking complete
Commercial fulfilled
Document output complete

15. Migration Disposition¶

Current source/process reconciliation:
M2 INPUT

Target policy acceptance:
INCOMPLETE

Target-role/runtime evidence:
REQUIRED

M4 migration authorization:
NOT ESTABLISHED

The selected migration order is defined in the rebuild packet and parity/cutover matrix. No write migration begins while quantity/weight/UOM, idempotency, correction/reversal, role or rollback policy is unresolved.

---¶

Source: docs/processes/MK_INVENTORY_ALLOCATION_RECONCILIATION.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.