Skip to content

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 Policy Decision Matrix

  • Status: RECOMMENDATIONS AND OPEN DECISIONS / NO RUNTIME POLICY CHANGE
  • Process: PROC-OMS-INVENTORY-TO-OUTBOUND-ALLOCATION-MK
  • Rebuild packet: MK_INVENTORY_ALLOCATION_CAPABILITY_REBUILD_PACKET.md
  • Source reconciliation: MK_INVENTORY_ALLOCATION_RECONCILIATION.md
  • Important: recommendations do not become Product or Runtime policy until accepted by the named owner and reflected in Product/Process/Task authority.

Decision Status

CURRENT COMPATIBILITY
RECOMMENDED
OPEN
DEFERRED
ACCEPTED
REJECTED

Policy Matrix

ID Decision Current source behavior Recommendation Owner / blocker
ALLOC-POL-010 Normal source identity basket uses lot + source item retain lot ID plus exact source order/item/transload P6/P5
ALLOC-POL-020 Existing target only Workbench requires existing target preserve in initial parity wave Product/Operations
ALLOC-POL-030 Full-lot versus partial UI allocates full displayed remaining lot preserve full-lot parity first; design partial only after explicit approval Product/Inventory
ALLOC-POL-040 Target line model one new outbound item per source row preserve initially; do not switch to existing demand line implicitly Product/OMS
ALLOC-POL-050 Basket atomicity whole request is one local transaction preserve all-or-nothing initial behavior Product/Operations
ALLOC-POL-060 Quantity authority quantity recorded but not immediately decremented define authoritative measure by UOM before migration Product/Inventory/DB
ALLOC-POL-070 Weight authority positive weight and conditional decrement retain conditional lower-bound check; define precision/rounding Product/Inventory/DB
ALLOC-POL-080 Dual balance update immediate command updates weight only target should update every authoritative measure atomically Product/P5/P11
ALLOC-POL-090 UOM compatibility no complete server conversion policy reject mismatches unless explicit versioned conversion exists Product/Inventory
ALLOC-POL-100 Source lot status list requires OPEN, write recheck is weaker command must revalidate accepted source state P5/P6
ALLOC-POL-110 Source receipt eligibility list joins source evidence command must validate exact source order/item/transload relationship P5/P6
ALLOC-POL-120 Target readiness existing active container/size bridge required preserve initially; separate eligibility from physical completion Product/Shipping
ALLOC-POL-130 Duplicate relation no universal uniqueness policy documented detect equivalent active relation and reject/return existing result Product/P5
ALLOC-POL-140 Request idempotency no durable token require token + normalized payload fingerprint P5/P12
ALLOC-POL-150 Concurrency conditional weight update add accepted version/freshness and duplicate protection P5/DB
ALLOC-POL-160 Preview browser constructs basket, no durable preview add server preview/fingerprint before target writer activation P7/P12
ALLOC-POL-170 Apply success response + browser refresh require exact target item/allocation/lot readback P6/P12
ALLOC-POL-180 Unknown result manual reload, no token reconcile by request/source/target before retry P5/P6/P12
ALLOC-POL-190 Correction no complete general owner explicit audited command; no generic field edit Product/P6
ALLOC-POL-200 Reversal/unallocate no general path confirmed immutable reversal/compensation, not hard delete Product/P6/P11
ALLOC-POL-210 Target item after allocation update can diverge require allocation-aware correction or block protected fields Product/Outbound/Allocation
ALLOC-POL-220 Source lot after allocation source update can recalc/reset balance require inventory/allocation reconciliation command Product/Inbound/Inventory
ALLOC-POL-230 Downstream locks distributed across Scale/Packing/Delivery/etc. define explicit blocker query and recovery owner P6/process owners
ALLOC-POL-240 Booking compatibility can affect allocation/lot retire hidden mutation; use explicit child commands Product/P5/P6
ALLOC-POL-250 Role model legacy context/advanced ops semantic capability + record scope P2/P4/P5
ALLOC-POL-260 Tenant/profile current MK/client compatibility mk-order profile/capability, no numeric branch P4/P5
ALLOC-POL-270 Audit current row timestamps/soft delete preserve actor, request, reason, before/after and reversal chain P5/P6
ALLOC-POL-280 Worker use core is synchronous local DB no worker for core Apply; only explicit async children P6/P12
ALLOC-POL-290 Current PHP parity wave current behavior contains known asymmetry preserve visible parity but block activation until integrity policy is explicit P12/Product
ALLOC-POL-300 PostgreSQL not first wave explicit decimals, constraints, indexes and idempotency later P11

The first write migration should preserve these accepted compatibility characteristics unless Product changes them explicitly:

existing outbound target only
full displayed source lot
one target item per source lot
one allocation row per target item
one all-or-nothing basket transaction
no provider/worker effect
exact post-commit readback

It must not preserve these defects as implicit policy:

no idempotency
weight-only balance consumption without an accepted quantity rule
weaker write eligibility than source-list eligibility
hidden Booking allocation mutation
no unknown-result reconciliation
generic/manual correction

Critical Decisions Before Any New Writer

ALLOC-POL-030 Full versus partial

Questions:

  • Is a lot operationally indivisible?
  • Can one lot be split across multiple shipments?
  • If partial, which measure is entered and which is derived?
  • How is the remainder displayed and corrected?

Recommended first wave: full-lot only for parity. Partial allocation is a separate Product feature.

ALLOC-POL-060 / 070 / 080 Quantity and weight

Questions:

  • For LB, is weight authoritative and quantity informational?
  • For piece/container/unit UOMs, is quantity authoritative?
  • Must both remain nonnegative?
  • What rounding tolerance applies?
  • Can one dimension be zero?

Recommendation: publish an explicit UOM policy table. Update every authoritative measure in one transaction. Do not infer conversion.

ALLOC-POL-190 / 200 Correction and reversal

Questions:

  • Which downstream states block correction?
  • Is a target item retained, cancelled or replaced after reversal?
  • How are original and restored source balances proven?
  • Which role approves and records reason?

Recommendation: immutable original allocation plus correction/reversal record. No hard-delete-first design.

ALLOC-POL-240 Booking compatibility

Current Booking compatibility can affect lot/allocation state. Target recommendation:

Booking command owns Booking only
-> explicit child handoff
-> Allocation owner command/result

Do not add another hidden sync layer in TypeScript.

Activation Blockers

Write migration remains blocked while any of these is unresolved:

  • source/target record authorization;
  • quantity/weight/UOM authority;
  • idempotency and duplicate result;
  • source and target freshness;
  • basket atomicity;
  • target line model;
  • correction/reversal scope;
  • downstream lock behavior;
  • Booking compatibility disposition;
  • rollback and caller-zero;
  • target-role acceptance.

Documentation Update Triggers

Update this matrix when:

  • current Workbench behavior changes;
  • Product accepts full/partial or quantity/weight policy;
  • a reversal command is introduced;
  • Outbound/Inbound/Booking changes affect allocation integrity;
  • target TypeScript request/repository schema is selected;
  • role/capability policy is accepted;
  • PostgreSQL design changes precision or constraints.

---

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