po_receive_by_date, eta_current, and order_commit_date are among the fields Tenoro reads when it ranks operational exceptions. The purpose of naming them is simple: a priority score is useful only when an operations team can see what data produced it, which fields influenced the result, and what would change if the data changed.
Tenoro connects purchasing, inventory, orders, and transport data to identify the downstream delivery impact of an exception. The ranking is based on the current data available from those systems. It does not replace the team's judgment about how to resolve the issue.
ERP fields: purchasing commitments and incoming supply
ERP data provides the purchasing context for an exception. These fields help establish whether supply is expected, blocked, late, or only partially available.
| Field | What it tells the ranking |
|---|---|
po_status |
Whether the purchase order is open, confirmed, on-hold, or partially-received. |
po_receive_by_date |
The contractual receipt date on the purchase order. |
hold_code |
The ERP-native reason a purchase order is blocked. |
approval_queue_age_hours |
How long an approval has been pending. |
line_item_quantity |
The quantity ordered on the affected line. |
received_quantity |
The quantity received so far, allowing the system to detect partial receipt. |
For example, an open purchase order with a near po_receive_by_date may need attention, but its urgency depends on what is already available and which customer orders depend on it. A mismatch between line_item_quantity and received_quantity indicates that the purchase order is only partially received. An approval hold with a high approval_queue_age_hours represents a different resolution path from a supplier shipment that has not arrived.
WMS fields: stock position and warehouse execution
WMS data shows whether the expected supply problem has already affected stock and warehouse work. Tenoro reads:
| Field | What it tells the ranking |
|---|---|
on_hand_quantity |
The current stock level. |
safety_stock_threshold |
The minimum inventory buffer. |
pick_queue_status |
Whether pick orders are in the queue or failing. |
location_code |
Which warehouse location is affected. |
The relationship between on_hand_quantity and safety_stock_threshold helps distinguish a delayed supply event with remaining cover from one that has put the buffer at risk. pick_queue_status adds an execution signal. A warehouse may have stock in theory, while a pick order is failing in practice. The location_code identifies where that condition is occurring so its effect can be connected to the relevant orders and transport activity.
TMS and carrier fields: changes in the transport promise
Transport data provides both the original expectation and the latest view of arrival. The relevant fields are:
| Field | What it tells the ranking |
|---|---|
eta_original |
The first estimated arrival date supplied by the carrier. |
eta_current |
The latest revised arrival estimate. |
delay_code |
The carrier-assigned reason for the delay. |
carrier_id |
The carrier identifier used to look up historical reliability. |
milestone_events |
The sequence of in-transit updates. |
Comparing eta_original with eta_current shows how the expected arrival has moved. The change matters most when it brings the arrival close to, or beyond, a customer commitment. milestone_events supplies the movement history, while delay_code provides the carrier's stated reason. carrier_id is used for the carrier reliability factor, based on historical accuracy for that carrier's revised ETAs.
OMS fields: customer commitments and downstream exposure
OMS data connects an upstream exception to the orders it may affect. Tenoro reads:
| Field | What it tells the ranking |
|---|---|
order_commit_date |
The date committed to the customer. |
order_status |
Whether the order is open, pick-fail, on hold, or shipped. |
orders_at_risk_count |
How many open orders are affected by the exception. |
These fields provide the customer-facing context for the queue. A delayed purchase order is not equally urgent in every situation. The ranking changes when the affected supply supports an order with a near order_commit_date, when several open orders are exposed, or when an order has already reached a pick-fail or hold state.
How the illustrative ranking model uses these fields
The following is an illustrative description of the ranking model, not a promise that every connection supplies every input in the same form. The score considers four factors:
- Delivery commitment proximity: the number of days until the earliest affected order commit date.
- Cascade depth: the number of downstream order lines affected by the exception.
- Carrier reliability factor: historical accuracy for the carrier when providing revised ETAs.
- Resolution complexity: whether the issue is supplier-side, an approval hold, or a transport problem, since these paths can require different resolution times.
The fields above supply the evidence for those factors. For example, eta_current and order_commit_date inform delivery commitment proximity. orders_at_risk_count helps indicate the size of the downstream exposure. carrier_id, together with the carrier's historical revised ETA accuracy, informs carrier reliability. ERP status and hold information help distinguish a supplier-side issue from an approval hold.
The score is not an instruction. It tells the operations team which exception has the highest downstream delivery impact based on current data. The decision about how to resolve that exception belongs to the team.
What changes the score, and what happens when data is missing
A ranking should move when the operating situation moves. If more stock arrives, the inventory exception can become less severe. If a purchase order is approved, an approval hold is resolved and its priority can change. If the ETA improves, delivery commitment proximity changes. These are not arbitrary score adjustments. They reflect changed input data.
Not every connected system exposes all of these fields. Older ERP configurations may not provide hold_code through an API. Some WMS deployments track safety_stock_threshold in a spreadsheet rather than in the WMS. Tenoro computes scores from the fields available in each connection. Missing fields reduce precision, but they do not prevent ranking.
This limitation is part of the transparency. When a team disagrees with a ranking, it can inspect the fields behind the result and identify whether the issue is a changed commitment date, a revised ETA, a stock difference, a growing affected-order count, or a missing input. That gives the team a practical way to understand why the score shifted and decide whether the connected data or the operational response needs attention.