The problem and the first release
An operations team manually merges two stock files. In this invented scenario, one identified warehouse feed is authoritative for quantity. An approved catalogue determines the permitted item identifiers. The first release accepts a UTF-8 CSV upload and produces a validated stock view and a readable error report. Live integrations, ordering and stock reservation are outside this example.
The business owner must approve the rules before implementation. “Use the newest number” is deliberately insufficient: a newer conflicting record is not necessarily true.
Make the rules explicit
- The fixture catalogue contains
AandB. Each row hasitem_id,quantityandsource. - The accepted source is
warehouse-1. Quantities must be whole numbers at least zero. - Repeated identical rows are collapsed. Different accepted quantities for the same item produce
needs_review; no quantity is published for it. - Invalid identifiers, sources or quantities are reported. Invalid rows never overwrite an accepted value.
- An item absent from the file remains
missing. Absence is not zero stock. - Row order must not alter the result. Identical input, rules and catalogue produce the same normalized values and statuses. Display and report timestamps are outside that claim.
Concrete acceptance examples
Input rowsitem_id, quantity, source | Expected result |
|---|---|
A,4,warehouse-1A,4,warehouse-1 | A: quantity 4, accepted; one duplicate reported. B: missing. |
A,4,warehouse-1A,7,warehouse-1 | A: needs_review, no published quantity. B: missing. |
A,-1,warehouse-1B,0,warehouse-1 | A row invalid; A: missing. B: accepted quantity 0. |
C,2,warehouse-1A,5,unknown-source | Both rows invalid. A and B: missing. |
| Reverse any row order above | Same normalized values, statuses and counts. |
These expected results follow from the synthetic rules. They have been inspected as a specification; no running application or automated test is claimed.
What a real delivery also needs
Agreement on the actual business authority and conflict behavior; real file contracts and scale and error limits; access control and safe upload handling; acceptance fixtures; a reproducible build and deployment package; source and documented rights and dependencies; operational ownership, rollback and state recovery where relevant; and a handover exercised by someone other than the author. File-format risks and actual client-data permissions would be assessed before processing real inputs.
The illustration establishes neither product readiness nor the correctness of the rules for a real warehouse. It shows the difference between “a file imported successfully” and “the agreed business conditions were checked”.