Supplier On-Time Delivery

Supplier on-time delivery is the share of eligible purchase schedules that physically reach the buying company's dock by a declared commitment date. The event is your receipt, not the supplier's ASN and not the date they say the truck left. That boundary keeps the metric tied to an event the buying company can verify.

There is no useful OTD number without a promise basis. A buyer-requested date measures whether the requirement was met; a supplier-confirmed date measures whether the supplier kept its commitment; a current confirmed date often measures whether the promise was moved before the receipt. Those are three different questions. The practice default keeps the original supplier-confirmed receipt date as the accountability clock and reports requested-date service beside it.

Partial receipts make the receipt event a second definition choice. First-receipt OTD lets one unit stop the clock. Complete-receipt OTD waits until cumulative accepted quantity reaches ordered less canceled quantity. Store both milestone dates on the fulfillment fact and choose one in the metric contract; do not let a dashboard silently switch between them.

Also answers to Supplier OTD · Vendor OTD · Purchase Order On-Time Delivery

Four switches. Promise basis and receipt event usually move the number more than any supplier improvement programme does.

• Scoring against the current promise — If a late line is rescheduled before it arrives, current-promise OTD turns the miss into a pass. Snapshot the original confirmation and publish promise-change rate beside OTD.
• Using ASN or ship confirmation as the actual — Those events describe what the supplier reported, not what reached your dock. Use the receiving ledger and state whether the milestone is receive, inspect, accept, or deliver-to-inventory.
• Letting a partial receipt stop the clock — One early unit can make a thousand-unit line look on time. If first receipt matters operationally, publish it separately from the complete or accepted-quantity milestone.
• Averaging supplier percentages — A portfolio OTD is passing schedules divided by eligible schedules, not the mean of supplier rates. Show the denominator because a 100% supplier on two lines is not stronger evidence than 91% on two thousand.
• Scoring history against today's tolerance — The tolerance fields that decide what counts as in-full — SAP's EKPO overdelivery and underdelivery percentages, D365's per-module item settings — are overwritten in place, so the extract holds only the tolerance in force today. Scoring last year's receipts against it silently rewrites the rules they were received under. If the tolerance window matters to the score, snapshot the tolerances into a type-2 dimension as part of the landing.

EKKO/EKPO identify the PO line and supplier; EKET is the schedule-line grain and holds the delivery commitment. Aggregate goods-receipt events from EKBE or MSEG back to that schedule before testing the receipt date. Snapshot the first confirmed date outside the current-state schedule if that is the chosen basis.

F4311 carries the ordered line and dates; receipt-type rows in F43121 carry quantity and receipt date. F43199 is the purchase-order detail ledger used to reconstruct promise changes. Convert Julian dates and implied-decimal quantities before comparing or summing them.

PurchLine carries requested and confirmed receipt dates; the posted product-receipt journal records physical arrival. The cataloged journal is header-grain, so a production build still needs the raw receipt-line transaction underneath it to preserve PO-line grain. Pin DataAreaId on every join and NULL-wrap sentinel dates.

MPLINE carries planned delivery and the receipt status ladder; MITTRA supplies inbound movement events tied back to the purchase order. Pin CONO, convert numeric YYYYMMDD dates, and normalize quantities into the item's basic unit before the cumulative receipt test.

PO_LINE_LOCATIONS_ALL is the shipment-schedule grain and carries need-by and promised dates. RCV_TRANSACTIONS is the insert-only event ledger: filter the receiving action deliberately and net corrections and returns through the parent chain before determining when cumulative accepted quantity reached the commitment.

The Fusion schedule exposes NEED_BY_DATE, PROMISED_DATE, and LAST_ACCEPT_DATE explicitly. Receiving remains an event ledger rather than a balance: a receipt can write receive, inspect, deliver, correct, and return rows, so summing every transaction type double-counts it. Scope the procurement BU and receiving organization separately.