Skip to content

MK Order-First Core — Source Authority

  • Status: CURRENT SOURCE-AUTHORITY RECONCILIATION
  • Capability family: Commercial Agreement, Inbound Purchase, Outbound Sales and Booking
  • Operating profile: mk-order
  • Composite process: PROC-OMS-ORDER-TO-PACKING-MK
  • Rebuild packet: MK_ORDER_FIRST_CORE_CAPABILITY_REBUILD_PACKET.md
  • Effect boundary: documentation only; no Runtime, schema, provider, Wiki DB, deployment or Production change

1. Authority Decision

No single page, helper, table or process file owns the MK core order-first system.

Product/Profile intent
-> Order-to-Packing composite
-> four atomic Process contracts
-> current PHP/MySQL adapters and authoritative records
-> operator Runbook and Wiki projection
-> rebuild packet and migration matrices

The four atomic Process contracts remain the semantic owners. Current source remains authoritative for exact implemented behavior. The rebuild packet assembles their data/interface/migration meaning without becoming a second process authority.

2. Process Authorities

Process Owns Does not own
PROC-OMS-COMMERCIAL-ORDER-MK Purchase/Sales agreement, terms, lines, relation and current manual status execution receipt/shipment, inventory, allocation, Booking execution
PROC-OMS-INBOUND-PURCHASE-TO-INVENTORY-MK inbound execution header/items, receipt handoff and source-to-lot materialization allocation, Scale ticket authority, arbitrary lot correction
PROC-OMS-OUTBOUND-SALES-ORDER-MK outbound demand header/items and Booking/equipment bridge references inventory allocation, Scale/Packing/Delivery completion
PROC-TMS-BOOKING-LIFECYCLE-MK Booking plan, terms, flags, inactive marker, optional Sales link and clone inventory/allocation/order mutation in the target model
PROC-OMS-ORDER-TO-PACKING-MK child optionality, identity handoff and cross-child reconciliation child mutations or one universal status

3. Current Runtime Source Families

Commercial

frontend/pages/system/OMS/commercial-order/mk-commercial-orders.php
frontend/pages/system/OMS/commercial-order/commercialOrderPrint.php
app/systems/OMS/commercial-order/api_routes.php
commercial_order_query_handler.php
commercial_order_query_helper.php
commercial_order_post_handler.php
commercial_order_post_helper.php

Current facts:

  • only the Options route currently declares strict tenant principal explicitly;
  • create/update/delete run through legacy write context;
  • DELETE exposes numeric role IDs 1..6 as current compatibility access;
  • advanced/basic operations alter accepted input fields;
  • header and line writes are locally transactional;
  • execution guard is strongest on header-level T_LOAD.COMMERCIAL_ORDER_ID and does not prove every item-level execution relation;
  • current status is validated against a list but not an approved transition matrix;
  • pre-execution line replacement can change line IDs;
  • print has no durable completion record.

Inbound Purchase

frontend/pages/system/OMS/inbound-order/mk-inbound-orders.php
public/assets/js/modules/shared/mk-inbound-order-editor.js
app/systems/OMS/inbound-order/api_routes.php
mk_query_helper.php
mk_post_helper.php
YMS Scale purchase callers
WMS inventory/lot/transload/warehouse helpers
Export Brokerage and allocation compatibility callers

Current facts:

  • header/item atomic-save exists for the shared editor;
  • direct header/item routes remain active compatibility paths;
  • detail is strict-tenant-principal while many other routes use legacy context;
  • DELETE routes use numeric role IDs 1..6;
  • Scale checkout and Inbound finalize are separate owner boundaries;
  • no-scale completion has current source eligibility and cardinality restrictions;
  • branch intent is returned but not durably stored;
  • direct operational-state and time updates can materialize receipt effects;
  • progressed item updates can affect lot remaining values without complete allocation/ledger/placement reconciliation;
  • mk_post_helper.php owns a broad mixture of Purchase, Sales, Scale, Inventory, Warehouse and Booking compatibility behavior.

Outbound Sales

frontend/pages/system/OMS/outbound-order/mk-outbound-orders.php
public/assets/js/modules/shared/mk-outbound-order-editor.js
app/systems/OMS/outbound-order/api_routes.php
query_handler.php
outbound_order_query_helper.php
post_handler.php
app/systems/OMS/inbound-order/mk_post_helper.php

Current facts:

  • Outbound post_handler.php directly includes the Inbound mk_post_helper.php and delegates core writes to mk_sales_order_* functions;
  • atomic save exists for header/items/deletions;
  • direct routes remain active;
  • direct line Save does not allocate inventory;
  • allocated-item delete is blocked, while allocated-item update reconciliation remains incomplete;
  • Booking/equipment bridge and Scale/Delivery/Cost blockers are cross-owner dependencies;
  • delete may leave a stale Booking reverse reference;
  • role access and direct references remain compatibility-oriented.

Booking

frontend/pages/system/TMS/booking/mk-booking-list.php
shared Booking/Packing editor modules
app/systems/TMS/booking/api_routes.php
TMS delivery query/post/out-ref helpers
app/systems/OMS/inbound-order/mk_post_helper.php
BMS transaction helper consumers
Packing, report and output consumers

Current facts:

  • Booking API directly includes TMS Delivery, BMS Transaction and OMS Inbound internal helpers;
  • tmsBookingWrite() starts a local transaction, calls mk_booking_post_handle() and flushes sync tasks;
  • the legacy Booking form still uses generic table mutation for Booking, Delivery Order and Equipment Load with blacklist-style restrictions;
  • Sales links are changed through Booking Save rather than generic form mutation;
  • clone is a separate route with numeric role IDs 1..6;
  • NOT_IN_USE is a manual independent flag;
  • current process evidence shows the misnamed BOOKING_RATE compatibility work can update or remove Order, Item, Lot and Allocation data and can leave partial/hidden results.

4. Current Data Authorities

Table/family Authority
T_COMMERCIAL_ORDER Commercial agreement header
T_COMMERCIAL_ORDER_ITEM Commercial agreement lines
T_LOAD Inbound Purchase and Outbound Sales execution header, distinguished by direction/class
T_LOAD_ITEM execution lines and current operational/source mapping
T_BOOKING Booking terms, planned container quantities, flags and links
T_TRANSLOAD inbound/execution bridge and separately owned physical workflow state
T_SCALE_TICKET physical weight evidence
T_INVENTORY_LOT received inventory
T_LOAD_ALLOCATION lot-to-outbound demand allocation
T_EQUIPMENT, T_EQUIPMENT_LOAD, T_EQUIPMENT_COMMODITY container/equipment execution bridge

A current table reference does not transfer process authority. Booking may reference a Sales order; it does not own the Sales process. Inbound may materialize a Lot; later lot correction remains Inventory-owned.

5. Current Cross-Module Dependency Risks

Shared MK helper concentration

app/systems/OMS/inbound-order/mk_post_helper.php is currently consumed by Inbound, Outbound and Booking routes and also integrates Scale, WMS Inventory and Warehouse behavior.

This is a compatibility implementation detail, not the target module boundary.

Booking hidden cross-owner work

Booking Save can initiate compatibility work affecting records outside T_BOOKING. The target must replace this with explicit application commands or retire the behavior.

Mixed principal/access styles

Current routes mix:

  • strict tenant principal on selected reads;
  • legacy tenant/session context on other routes;
  • numeric role-ID lists on selected destructive/cost/clone actions;
  • advanced/basic operations flags controlling accepted behavior.

The target uses semantic capability and record-scope decisions.

Generic mutation

Booking and related form paths still use generic table mutation with prohibited-column checks. The target does not expose table/column mutation as a business API.

6. Current Versus Target Ownership

Concern Current implementation Target owner
Commercial terms/lines PHP commercial helpers Commercial Application + repository
Commercial execution utilization page/query inference typed query projection
Inbound scheduled CRUD PHP MK helper Inbound Purchase Application
Receipt finalize and lot materialization Scale/Inbound/WMS helper chain explicit receipt command with accepted owners
Outbound scheduled CRUD Outbound adapter delegating to Inbound helper Outbound Sales Application
Inventory allocation Allocation workbench/current helpers Allocation Application
Booking fields/link Booking route + MK helper Booking Application
Booking cross-owner compatibility hidden sync task/helper behavior explicit child commands or retired compatibility
UI PHP/JS pages and shared editors React workspaces
HTTP/server boundary PHP route arrays Next.js adapters
Core business rules broad helpers framework-independent TypeScript application/domain
Durable async work mixed request-time behavior Node worker only where effects/reconciliation require it

7. Mandatory Read Order For Implementation Or Migration

  1. AGENTS.md and current Product/Context/Design/Roadmap.
  2. MK_ORDER_TO_PACKING_WORKFLOW.md.
  3. The applicable atomic Process contract.
  4. This source-authority file.
  5. MK_ORDER_FIRST_CORE_CAPABILITY_REBUILD_PACKET.md.
  6. Current schema and exact source files for the selected capability.
  7. Current operator Runbook and Wiki content after authorized read.
  8. The selected Task/stage, role matrix and verification plan.

Do not reconstruct scope from one helper, a page label, a legacy workbook or conversation memory.

8. Source Re-Pin Checklist

Before any Runtime change:

  • exact branch, commit and working tree;
  • current MySQL server/database/schema/index identity;
  • current MK tenant/profile/config/module state;
  • current role/page/API/record matrix;
  • all writers/readers for Commercial header/items;
  • all Inbound scheduled/receipt/lot writers;
  • all Outbound item/allocation/bridge writers;
  • all Booking and compatibility-sync callers;
  • current Scale, Allocation, WMS and Packing consumers;
  • active reports/documents/exports;
  • current T_WIKI_PAGE rows and rendered pages for MK slugs;
  • concurrent writers and release baseline.

9. Drift And Stop Conditions

Stop and reconcile when:

  • a target design copies CLIENT_ID === 2 or customer-name business branching;
  • one Route Handler/Server Action begins owning Commercial, Inbound, Outbound and Booking SQL together;
  • generic table mutation is exposed as a target API;
  • Booking Save continues to hide inventory/allocation mutation;
  • direct Outbound Save is treated as allocation;
  • Scale checkout is treated as receipt finalization;
  • a manual header status is presented as execution truth;
  • PHP and TypeScript write the same capability/cohort;
  • current Wiki content would claim target behavior before implementation;
  • a source/schema/role fact required for integrity remains unknown;
  • a policy decision is replaced by a convenient schema or status.

10. Update Triggers

Update this source-authority map when:

  • a route/helper/caller moves;
  • a process owner changes;
  • current principal/role handling changes;
  • mk_post_helper.php responsibility is extracted;
  • Booking compatibility sync changes or retires;
  • source tables/identity relationships change;
  • P12 activates a new writer;
  • caller-zero removes a compatibility path;
  • PostgreSQL changes the physical repository mapping.

---

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