Seven ideas behind this model
Late is decided at the hub
Once goods are on the water there is little left to do. The useful warning comes while goods sit at the hub, or before the supplier has even delivered.
One forecast, two judgements
The same forecast arrival date is compared with the site due date (did the need get met?) and with the freight standard (did logistics do its job?).
The clock depends on the stage
Before the hub, the supplier's promise date drives the forecast. At the hub, the standard consolidation. On the water, the actual departure.
Tolerance is an escalation window
Each hub has a band of days in which a late-looking order can still be recovered by pushing the departure. Past the band it is late even at standard sailing time.
Raw data is per delivery, the order is per line
Each receipt (RTN) is judged on its own for logistics. Quantities are then summed per PO line to decide in full and the site status.
The same engine runs outbound
Products leaving the site follow the mirror image: ready date, hub, consolidation, sailing, customer receipt. Only the labels change.
Every number is yours
All example values are generic placeholders. Replace them with your own lead times, standards and tolerances before drawing conclusions.
1The question
Which open orders will miss their due date if nothing changes, and which of them can still be saved?
A status such as "Ontime" or "Late" printed after delivery explains the past. A planner needs the opposite: a ranked list of orders that are heading late, a reason, and a date by which action still works. The model on this page builds that list from only five dates per delivery: the supplier promise date, the goods receipt at the hub (GR Offsite), the shipment start, the receipt at site (GR Onsite), and today.
2The business flow, end to end
Every shipment passes the same four phases. Each phase has an owner and a KPI. The model measures lateness along this chain.
Inbound and outbound are mirror images
| Concept | Inbound (materials) | Outbound (products) |
|---|---|---|
| Order | Purchase order line | Sales or delivery order line |
| Starting promise | PO Delivery Date: supplier delivers to the hub | Ready-to-ship date: plant hands over to the hub |
| Hub receipt | GR Offsite posted by the 3PL | Hub receipt posted by the 3PL |
| Consolidation | Combine supplier lots into a container or vessel | Stuff the container and wait for the vessel cut-off |
| Sailing | Shipment start to arrival, clearance, inland leg | Vessel departure to arrival, clearance, last mile |
| End point | GR Onsite at the site | Proof of delivery at the customer |
| Final target | Due Site Date = PO Delivery Date + Lead Time | Customer due date = Ready date + Lead Time |
| First KPI | RIFOT: supplier received in full and on time at the hub | OTIF at origin: product ready in full and on time |
Typical causes of delay, by phase (general experience, not company data)
Supplier or plant phase
Production or procurement slips, partial lots, documents not ready, supplier not confirming the date. The order is late before any logistics work starts.
Hub posting phase
Goods stand in the yard or dock waiting for inspection, labelling, or a posting action. The supplier looks late in the system although the goods were physically there.
Consolidation phase
Waiting for other lots to complete a container, for booking space, or for the next sailing. This is the phase where escalation still changes the outcome.
Sailing, clearance and inland phase
Port congestion, transhipment, inspection, customs release, trucking. Little can be recovered once the vessel has left.
3KPIs along the flow
Each KPI answers one question about one phase. Together they show who owns a delay.
| KPI | Question | From | To | Compared with | Owner |
|---|---|---|---|---|---|
| RIFOT | Did the supplier deliver in full and on time to the hub? | PO Delivery Date | GR Offsite (in full) | PO Delivery Date | Supplier, procurement |
| On-time GR | How long from physical receipt at the 3PL to the GR posting? | 3PL physical receipt | GR Offsite posting | GR KPI (days) | 3PL |
| Consolidation KPI | How long did goods stay at the hub before shipment started? | GR Offsite | Shipment Start | Standard consolidation days per hub | 3PL, logistics |
| Sailing standard | Did the sailing, clearance and inland leg meet the freight table? | Shipment Start | GR Onsite | Lead Time − standard consolidation | Carrier, forwarder |
| Logistics on-time | Did logistics as a whole meet the freight table? | GR Offsite | GR Onsite | GR Offsite + Lead Time | Logistics |
| DIFOT | Did the full quantity reach the site by the due date? | PO Delivery Date | GR Onsite (in full) | Due Site Date | Supply chain as a whole |
4Method
A rule-based forecast, in four steps, applied to every PO line and every receipt.
Step 1. Group the raw data
Raw data has one row per receipt (RTN). If the same PO line appears more than once with different RTNs, the line was delivered in parts. The model keeps both grains.
- RTN grain carries the logistics assessment, because each delivery has its own dates.
- PO line grain carries the in-full decision and the site assessment, because quantity is ordered per line.
Step 2. Decide the stage of each PO line
Only events dated on or before the as-of date count. Quantities from all receipts of the line are summed.
| Stage | Test (checked from the bottom up) |
|---|---|
| Received | Quantity at site ≥ PO quantity |
| On water | Quantity with a shipment start ≥ PO quantity |
| At hub | Quantity posted at the hub ≥ PO quantity (in full at hub) |
| Vendor | Otherwise, including partially delivered lines |
Step 3. Forecast the arrival
| Stage | Forecast arrival | Logic |
|---|---|---|
| Vendor | MAX(as-of, PO Delivery Date) + Lead Time | Assume the supplier delivers on its promise date. Once that date has passed, the earliest possible delivery is today. |
| At hub | As-of + (Lead Time − Std Consolidation) | Best case: the goods leave the hub today. The standard consolidation is already behind them. |
| On water | Shipment Start + (Lead Time − Std Consolidation) | The departure date is a fact. Only the standard sailing remains. |
| Received | Actual GR Onsite | Final. |
Step 4. Compare with the target, then apply the bands
Assessment 1: site status (per PO line)
Target is the Due Site Date. It includes the supplier, so it answers whether the need is met. Only final when the line is in full.
Assessment 2: logistics status (per RTN)
Target is GR Offsite + Lead Time. The clock starts when the goods enter the hub, so the supplier is excluded and each delivery is judged alone.
| Slack (target − forecast) | Status | Meaning for action |
|---|---|---|
| > tolerance | Ontime | No action |
| 0 to tolerance | Probably Ontime | Inside the escalation window: act now to keep it on time |
| −tolerance to −1 | Probably Late | Late by up to the tolerance unless the departure or sailing is accelerated |
| < −tolerance | Late | Late even at standard sailing time |
| Tolerance = 0 (direct routes) | Ontime / Late | No hub buffer, so no "Probably" classes |
The tolerance before shipment is used for the vendor and hub stages; the tolerance after shipment is used on the water. Both are variables per hub, separately for the site and the logistics assessment.
5Formulas
Dates and standards
Quantities per PO line (events on or before the as-of date)
Forecast, slack and status
Where the days go: exact split of a late arrival
For a received delivery, the days late against the Due Site Date split exactly into four parts, because the Lead Time is the sum of the standard consolidation and the remaining standard:
Worked example, computed live from the hub table
Probability layer (extension, section 10)
6Parameter setup
Fill in this section before reading the results. A generic example is loaded.
6.1 General
6.2 Hub parameter table
One row per route. Std consolidation is the number of days goods are normally held at the hub; it is part of the Lead Time. Tolerances are the escalation window in days. Set 0 for a direct route.
6.3 Deliveries (one row per RTN)
PO-level fields (hub, PO quantity, promise date, lead time, cancelled flag, as-of override) are read from the first row of each PO line. Keep them identical on all rows of the same line. Cancelled = X removes the whole line. Leaving the as-of override empty uses the general date.
6.4 Probability layer settings (illustrative)
7Results and what-if
Move the levers to see which orders change status, and why. All results recalculate instantly.
7.1 What-if levers
7.2 Headline
7.3 Which orders are likely to arrive late
Ranked by probability of arriving late, then by slack. The status columns come from the rule-based model; the probability column is the extension in section 10.
7.4 Timeline of open and closed lines
7.5 Status counts, base against what-if
7.6 Logistics assessment per delivery, and where the days go
Columns on the right split the days against the freight table into supplier, GR posting, hub dwell against the KPI, and sailing against the standard. Negative = better than standard. A dash means the phase has not happened yet.
7.7 KPI chain from the data (not affected by the levers)
7.8 Self-check against the Excel model
8Reading the results
Do not read "Probably Ontime" as safe
It means the order sits inside the escalation window. With the best-case assumption (depart today), a line with zero slack has no room for any variation. The probability column shows this: lines at zero slack often carry a high probability of late once variation is allowed.
Act on hub lines first
Vendor lines depend on a promise you cannot move. Water lines cannot be changed. Hub lines carry both a date and a lever, so they are the first call for escalation.
Read both statuses together
A line that is late on the site status and on time on logistics is a supplier problem. A line on time at the site but late on logistics is a hidden problem protected by an early supplier.
Test the levers one at a time
A hub hold of seven days and a sailing delay of seven days both add seven days to the arrival of a hub line. They differ in who owns the fix and when you can still act.
9Literature map
The rule-based model is the transparent baseline that recent research starts from. This map shows where three papers extend it.
Maturity ladder of the forecast
Paper 1 · Intelligent Early Warning System for Supplier Delays
Dynamic IoT-calibrated probabilistic modelling in engineer-to-order supply chains.
Paper 2 · Conformal Predictive Distributions for Order Fulfillment Time Forecasting
Forecasting the distribution of fulfilment time, with a cost rule for decisions.
Paper 3 · Uncertainty-Aware Delivery Delay Duration Prediction via Multi-Task Deep Learning
Classify delay first, then predict its duration.
10How to perfect the model
Nine gaps, what closes each one, and whether this page already shows it.
| # | Gap in the rule-based model | Upgrade | On this page | Data needed |
|---|---|---|---|---|
| 1 | "Vendor on time" assumption makes the vendor stage look safe | Probability of late from supplier and lane history, plus the supplier's confirmed date | Live (placeholder spreads) | Confirmed date, acknowledgement, reschedule count |
| 2 | Fixed tolerance for every supplier and lane | Derive the band from a percentile of historical lead time per route | Roadmap | 20 to 30 completed deliveries per route |
| 3 | Hub forecast assumes departure today | Use the planned consolidation or cut-off date; test hub-hold scenarios | Lever live | Booking and vessel schedule per route |
| 4 | GR posting lag hidden inside supplier delay | Capture the physical 3PL receipt date and split the delay | Live (optional column) | 3PL physical receipt date |
| 5 | Partial deliveries judged as one lump | Judge logistics per receipt, in full per line | Live | Receipt-level quantity and dates |
| 6 | Standard sailing time, no vessel signal | Feed vessel ETA and port events once the shipment is on the water | Roadmap | Carrier or tracking feed |
| 7 | No feedback loop | Daily snapshot of status per line, then hit rate, bias and tracking signal of the ETA error | Roadmap | Snapshot table in the dataflow |
| 8 | Only a label, no priority | Add days late, value, criticality and need date; rank by risk | Days and probability live | Need date, value, criticality |
| 9 | Outbound not measured the same way | Run the same engine on shipments leaving the site | Live (direction switch) | Ready date, hub receipt, vessel departure, customer receipt |
Back-test routine for upgrade 7
Store one row per PO line per day with its status. When a line closes, compare its status at day T−14 with the outcome:
Recalibrate each tolerance when the hit rate drifts. A lower tolerance raises the share of Late labels and lowers the share of missed late lines; the right value balances false alarms against missed warnings for your business.
Suggested build order
- Capture the 3PL physical receipt date and the supplier's confirmed date (small data change, large attribution gain).
- Start the daily snapshot now; it takes months to fill and every later upgrade depends on it.
- Estimate spreads per route from history and replace the placeholder spreads.
- Add the planned departure date at the hub, then vessel ETA.
- Rank open lines by risk, value and need date.
11Limits and sources
- All example values (lead times, hubs, tolerances, dates) are generic placeholders, not company data.
- The forecast is rule-based with fixed standard lead times. It has no vessel ETA, no supplier confirmation date and no lead-time history.
- The probability layer uses spreads you type in. It is an illustration of the idea, not a calibrated model.
- A line counts as in full only when the summed quantity reaches the PO quantity. Over-delivery counts as in full; units must match.
- Latest GR Offsite is used as the in-full date. If an extra receipt arrives after the line is in full, the date moves.
- Logistics tolerances are placeholders. Not validated on live data.
Sources
- Intelligent Early Warning System for Supplier Delays Using Dynamic IoT-Calibrated Probabilistic Modeling in Smart Engineer-to-Order Supply Chains (journal).
- Conformal Predictive Distributions for Order Fulfillment Time Forecasting (arXiv preprint).
- Uncertainty-Aware Delivery Delay Duration Prediction via Multi-Task Deep Learning (arXiv preprint).
- Forecast error measures (bias, MAD, tracking signal) and dependability metrics follow common supply chain management practice.