01 // SO
Order intake
Simulated customer demand enters through a controlled document layer, then every item, quantity and account must resolve against closed master data before the workflow can continue.
01.3 // SUPPLY CHAIN · TESTED SIMULATION
FROM ORDER INTAKE
TO CASH.
A synthetic distribution company, a mock D365 data surface and a hard question: can an AI-assisted workflow carry one transaction across planning, logistics, quality and finance without losing control of the evidence?
07
SYNTHETIC EXCEPTION SCENARIOS
27/27
REGRESSION ASSERTIONS
12/12
END-TO-END V2 ASSERTIONS
00
LIVE ERP WRITES
// why I built it
A useful agent must survive the whole object chain.
A single email demo is easy to make persuasive. Supply-chain work becomes difficult when one decision changes several records, several teams and a customer promise at once.
I built this simulation to make those dependencies visible. It follows synthetic orders through purchase, confirmation, receipt, quality release, delivery, invoice matching and cash — with exceptions deliberately injected along the way.
THE OPERATING RULE
No write without evidence and permission.
The agent may extract, calculate and recommend. A simulated system action happens only after the required data checks and the right approval gate have passed.
// the transaction spine
Three flows. One traceable case.
The model keeps information, physical product and cash connected. Each stage has its own state, checks and human boundary.
02 // ATP
ATP before buying
The flow checks released on-hand stock first, allocates what can ship now, and purchases only the uncovered gap instead of blindly turning demand into a full purchase order.
03 // PO
Confirmation & logistics
Supplier confirmations can arrive clean, late or split. The simulation updates delivery schedules, propagates promise-date risk and preserves the history of what changed.
04 // GRN
Receipt & quality
Inbound goods move through receipt, quarantine and a separate quality release. Stock cannot become available merely because a receipt record exists.
05 // FEFO
Allocation & delivery
Released batches are allocated by expiry-aware rules, with partial deliveries and backorders represented explicitly rather than hidden inside one status.
06 // P2P + O2C
Invoice & cash
The model closes both sides of the transaction: three-way AP matching and payment, then customer invoicing, receipt and cash allocation.
07 // CONTROL
Human approval gates
External commitments, price disputes, delivery promises and other consequential actions are staged for review. Only narrow, whitelisted routine actions may pass automatically.
08 // EVIDENCE
Auditable traces
Every simulated read, recommendation, approval and write-back carries a trace, so the result can be replayed and challenged instead of accepted as model prose.
// how I built it
Scenario first. Assertions last.
- 01
Start with exception stories, not a dashboard
I wrote seven concrete failure stories first: silence after a PO, partial supply, a delayed promise, a price variance, a batch-expiry decision and an invoice outside tolerance.
- 02
Model the ERP surface
A mock OData-style layer gives sales orders, purchase orders, batches, receipts, activities and invoices explicit state and observable reads and writes.
- 03
Separate extraction, validation and execution
Incoming documents become structured facts; rules test those facts; approval gates decide whether an action may proceed; only then does the simulated write-back happen.
- 04
Turn business expectations into assertions
Each scenario ends with machine-checkable claims: the right quantity was purchased, the right batch was allocated, the right exception was held and the right communication stayed pending review.
- 05
Close the full transaction chain
The first end-to-end version linked order through payment. A second realism pass added true ATP, quality release, landed cost, GST and the customer cash-receipt loop.
- 06
Write down the production gap
The case study ends by separating demonstrated logic from missing production infrastructure: real identity, ERP events, idempotency, outbox processing, evaluation data, access control, observability and recovery.
WHAT THE SIMULATION PROVES
A transaction can be reasoned about end to end.
- A recommendation is tied to an object chain, not generated in isolation.
- Rules, human judgment and simulated system actions remain visibly separate.
- Deterministic scenarios make regressions measurable when the workflow changes.
- The second realism pass shows a willingness to challenge a clean demo rather than defend it.
WHAT IT DOES NOT CLAIM
A tested simulation, not a live ERP integration.
- No production D365 tenant, company mailbox or real customer data is connected.
- The extraction layer is deterministic test logic, not a production document-understanding service.
- Reservation, ATP and financial posting would remain inside the ERP in a real deployment.
- The public case uses fictional organisations and synthetic transactions only.
THE SIGNAL // DOMAIN × SYSTEMS × CONTROL
The build is not the happy path. It is the evidence around the exception.
This project shows how I translate supply-chain operations into explicit state, testable rules, permission boundaries and a productionisation plan — while staying honest about the distance between a simulation and a deployed enterprise system.