trastCase C04 · synthetic exercise data
The delivery arrived. The invoice tells a different story.
At the loading bay, a dealership parts team records what actually arrived. Later, someone tries to reconcile the invoice against it and can't tell whether a difference is a shortage, a damaged item, a duplicate scan, or a second delivery. This prototype is a narrow, working slice of that workflow: a system that classifies and reconciles automatically, but never writes anything without a human confirming it first.
Log in to try it
1. Receiving
A delivery-note scan arrives (simulated). The system checks it against open purchase orders and proposes new vs. duplicate vs. ambiguous, computed fresh from live state every time, never a scripted answer. A human clerk confirms or corrects it. Nothing is written until they do.
2. Invoice reconciliation
An invoice arrives (simulated). The system sums the accepted quantity, not received, across every delivery note tied to that order, and shows a line-by-line evidence trail for any gap. A human approver signs off before a discrepancy notice is generated, and that notice is simulated: displayed, never sent.
About this prototype
- Real: new-vs-duplicate classification, computed from live state every time, never a scripted answer.
- Real: invoice reconciliation math — sums accepted (not received) quantity across every delivery note tied to the PO, with a line-by-line evidence trail for any gap.
- Real: nothing is written to state without an explicit human confirm/approve click.
- Real: login and session — a signed cookie checked against seeded demo users, with parts-receiving-lead/reconciliation-lead route gating. See
docs/01-system-design.md§10. - Real: the inventory ledger — received-to-date by part, summed live from receipts, never a maintained counter. Not a live warehouse stock count (no putaway/pick/consumption events). "Add new stock" is a real write, but only to this app's own tables — never to a real supplier or inventory-of-record system.
- Simulated: the incoming delivery-note scan and incoming invoice events (buttons, not a real scanner/EDI feed).
- Simulated: the discrepancy notice — generated and displayed, never actually sent to a supplier or posted to accounting.
Demo credentials (seeded by resetState()): priya_lead / @Passw0rd1 (parts receiving lead) or sam_lead / @Passw0rd2 (reconciliation lead). Only session enforcement is real here — no password policy, recovery, or OAuth/SSO.
Full design rationale, open questions, and the build log live in docs/ and dev-docs/ in the repository.