Link orderable items to the trading account
Synthetic wholesaler offers items A, B and C publicly. Account K1 may order A and B; K2 may order B and C under the supplied assortment map. Being listed publicly does not make A orderable by K2. A later assortment change controls new requests while preserving what an earlier accepted order actually contained.
| Constraint | Required record | Example decision rule |
|---|---|---|
| Ordering key | Account ID + item ID + map revision | K2/A has no eligible map |
| Catalogue versus assortment | Public item list and account map separately | Visible does not mean orderable |
| Historical order | Accepted line and original map reference | Later map edit does not erase it |
Test the same product for two accounts
| Case | Input | Expected decision |
|---|---|---|
| K1 orders A | A in K1 map | Assortment condition met |
| K2 orders A | A public; absent from K2 map | Hold new request for decision |
- Identify ordering account
- Read current assortment revision
- Compare requested items
- Preserve original accepted lines
If the account map is missing, do not replace it with the public catalogue as implied approval.
K2 has an old accepted A order, but its current map excludes A. Is a new A request automatically permitted?
Show the worked answer
No. Preserve the old accepted line and review the new request against the current K2 map.
Require the demo to show a visible but account-ineligible item and a historical order surviving a map change.