The checks I add to supply chain data before planners trust it

My first artifact for item_location_week_supply_plan is a compact planner trust check card. Buy, expedite, and reallocate decisions stay blocked until every line on that card is green.

I have watched a planning feed arrive on time with expected row counts and still be unsafe to use. The file can look healthy at the table level while business-rule defects point planners toward the wrong move.

Problem

A planning feed can be fresh, complete by row count, and still unsafe for action.

I keep this boundary separate from two other supply-chain posts on purpose:

• KPI-definition boundary: in The supply chain numbers I define before they reach a business review, I decide metric meaning, timing, exclusions, grain, and owner before a review.
• Restatement-window boundary: in Handling late-arriving supply chain data without rewriting history by hand, I decide how late events restate history inside a declared correction window.

In this post, I decide whether the planning slice is safe enough for planners to act on right now.

Default approach

I run a check ladder in a fixed order.

• First gate: freshness and row counts. I use them as entry gates only. They are necessary, but they are explicitly insufficient for planner trust. This is the same premise I use in Row counts are not enough: the checks I add before I trust a pipeline.
• Then I run seven business-rule categories before I clear planning actions:
  1. Duplicate purchase orders
  2. UOM conversion integrity
  3. Missing location mappings
  4. Negative or impossible inventory states
  5. Order-status lifecycle validity
  6. Forecast vs actual demand grain alignment
  7. Raw material vs finished-goods classification integrity
• For every failed category, I attach one blocked action and one first-response owner so planners are not left guessing whether the slice can be used.

Example

In one weekly slice of item_location_week_supply_plan, FG-104 at WEST-03 looked healthy at the table level (freshness=PASS, row_count=PASS) and still failed planner trust.

Planner trust check card
Feed: item_location_week_supply_plan
Slice: FG-104 @ WEST-03
Entry gates: freshness=PASS, row_count=PASS (insufficient alone)

1) Duplicate purchase orders
- Trigger condition: two active lines share (po_number, line_id, item_id, location_id, required_date) after an EDI 850 resend lands with a new message_id
- Failure description: the same inbound case appears twice and inflates expected receipts
- Planner decision error it causes: planner skips a needed expedite because inbound looks bigger than reality
- First response: procurement data owner inactivates the duplicate line and republishes the slice

2) UOM conversion integrity
- Trigger condition: supplier EDI 856 arrives in CASE, ERP posts receipts in EA, and case-pack mapping is stale for FG-104
- Failure description: each receipt is multiplied by the old case-pack value and creates phantom on-hand overnight
- Planner decision error it causes: planner delays replenishment because phantom safety stock hides a true shortage
- First response: master-data/UOM owner corrects CASE→EA mapping and reruns the planning model

3) Missing location mappings
- Trigger condition: WMS emits alias location `W03-RCV`, but canonical mapping to `WEST-03` is missing in the hierarchy bridge
- Failure description: receipts and on-hand fall into an unmapped bucket and disappear from the WEST-03 planning view
- Planner decision error it causes: planner launches an unnecessary inter-DC reallocation for a shortage that is only a mapping miss
- First response: location-master owner backfills the alias mapping and revalidates affected keys

4) Negative or impossible inventory states
- Trigger condition: FG available quantity goes negative without an approved reason code after issue transactions post before in-transit settlement closes
- Failure description: timing-gap negatives are mixed with true data defects, so FG-104 shows an impossible shortage state
- Planner decision error it causes: planner triggers the wrong expedite instead of waiting for the settlement window close
- First response: inventory-control owner verifies transaction chain and reason codes before release

5) Order-status lifecycle validity
- Trigger condition: order cancelled in OMS, but the cancellation event is dropped in transit and the line stays OPEN in planning facts
- Failure description: the cancelled line sits permanently in the open bucket and inflates expected backlog
- Planner decision error it causes: planner over-allocates capacity and commits an unnecessary expedite to chase phantom backlog
- First response: order-management owner replays cancellation events, reconciles status snapshots, and re-emits order facts

6) Forecast vs actual demand grain alignment
- Trigger condition: forecast is uploaded at SKU-region grain when replenishment consumes SKU-DC grain
- Failure description: missing DC rows are treated as zero demand, triggering unnecessary safety-stock recommendations
- Planner decision error it causes: planner launches wrong replenishment transfers into DCs that are not actually under-demand
- First response: planning analytics owner disaggregates SKU-region forecast to SKU-DC with the approved split key before recomputing joins

7) Raw material vs finished-goods classification integrity
- Trigger condition: RM-881 is misclassified as FG during a product-master merge and enters FG availability logic without a transformation rule
- Failure description: raw material is counted as sellable finished stock for FG-104
- Planner decision error it causes: planner misses a real finished-goods shortage and delays the buy signal
- First response: product-classification owner restores RM/FG boundary and reruns publish checks

Blocked planning actions while any line is FAIL:
- Buy: blocked
- Expedite: blocked
- Reallocate: blocked

This card keeps me out of false confidence: the feed can look healthy at the table level and still be unsafe for planner decisions.

Tradeoffs

• Breaks when: I assert qty_on_hand >= 0 before the goods-in-transit settlement window closes, so legitimate shipment-before-receipt timing gaps look like defects → Mitigation: I apply strict non-negative assertions only after settlement close, and I require reason codes inside the open window.
• Breaks when: I run duplicate-PO checks without lifecycle context during ERP reopen/reclose cycles, so legitimately reopened lines are flagged as duplicates → Mitigation: I scope duplicate checks to active statuses plus lifecycle transition rules from the order-policy contract.
• Breaks when: I compare forecast and actual demand before SKU-region forecasts are disaggregated to SKU-DC, so missing DC rows are interpreted as zero demand → Mitigation: I enforce disaggregation and completeness checks at SKU-DC grain before replenishment logic runs.
• Breaks when: I trust status snapshots only and ignore event-stream loss during OMS→planning transport, so dropped cancellation events create phantom open backlog → Mitigation: I run event-vs-snapshot reconciliation and block planner release on unresolved cancellation gaps.
• Breaks when: I treat RM/FG product_type as static during new-item onboarding, so temporary classification drift enters FG ATP logic → Mitigation: I gate FG availability on explicit transformation rules and quarantine UNKNOWN/RM classes from sellable stock.
• Breaks when: I leave first-response ownership generic across plants and shifts, so failed checks sit unclaimed through weekend planning cycles → Mitigation: I assign a named owner + response SLA per category and route alerts by calendar coverage.

Close

Next step: Publish one planner trust check card for your highest-risk planning feed this week, and keep buy/expedite/reallocate blocked until every line on the card is green.

For a supply-chain anomaly already under debate, I’m happy to compare notes on the category, blocked-action, and owner boundary that keeps a bad planning slice from becoming a bad planner decision.