InfiniSynapse
What is on-time delivery?什么是准时交付？
On-time delivery (OTD) is the percentage of eligible deliveries completed within an approved delivery window relative to a governing requested, promised, or committed date.
准时交付（OTD）是指：相对于约定的需求日、承诺日或合同日期，在批准的交付窗口内完成的合格交付，占统计期内所有应交付对象的比例。
That short definition contains four policy choices: what is eligible, which date governs, which operational event counts as delivery, and how wide the acceptable window is. Until those choices are fixed, an OTD percentage is not comparable across suppliers, customers, sites, products, or periods.
这个简短定义包含四个政策选择：哪些对象进入统计、以哪个日期为准、哪个业务事件算“交付”、允许窗口有多宽。没有固定这些选择，供应商、客户、工厂、产品或期间之间的 OTD 百分比就不可比。
OTD is useful for supplier scorecards, customer-service monitoring, carrier and route analysis, production-to-customer handoffs, and promise-date governance. It answers a narrow but important question: did the defined item arrive when it was supposed to?
OTD 可用于供应商评分卡、客户服务监控、承运商与线路分析、生产到客户的交接，以及承诺日期治理。它回答一个范围明确但重要的问题：定义好的对象是否在应到时间到达？
On-time delivery formula准时交付率公式
The denominator should normally be based on items due in the measurement period, not items actually received in that period. If a July report includes only July receipts, an order due in July but still undelivered in August can disappear from both numerator and denominator. A due-date cohort keeps overdue open items visible.
分母通常应按统计期内应到期的对象确定，而不是按该期实际收货的对象确定。如果 7 月报表只统计 7 月收货，那么本应 7 月到货但到 8 月仍未交付的订单可能同时从分子和分母消失。按到期日建立队列，才能保留逾期未结对象。
For each eligible object, classify on-time status with a two-sided rule: actual event time must fall between the reference date minus the permitted early tolerance and the reference date plus the permitted late tolerance. Exact-date OTD simply sets both tolerances to zero.
对每个合格对象，可用双边规则判定：实际事件时间必须落在“基准日期减允许提前量”与“基准日期加允许延迟量”之间。若要求必须当天到达，则把两侧容差都设为零。
Write the measurement contract first先写清指标合同
A durable OTD KPI needs a compact measurement contract that analysts, operations, procurement, sales, finance, and suppliers can read the same way. Store the contract next to the dashboard and version it when policy changes.
一个可长期使用的 OTD KPI，需要一份让分析、运营、采购、销售、财务和供应商都能以同一方式理解的指标合同。应将合同与仪表板放在一起，并在政策变化时进行版本管理。
Customer-requested, supplier-confirmed, contractual promise, scheduled arrival, or appointment date.
客户需求日、供应商确认日、合同承诺日、计划到达日或预约日。
Ship confirmation, carrier arrival, proof of delivery, goods receipt, or customer acceptance.
发运确认、承运商到达、签收证明、入库过账或客户验收。
Early and late tolerances, time zone, timestamp cutoff, weekends, holidays, and site calendars.
提前与延迟容差、时区、截点、周末、节假日及站点日历。
Order, line, schedule line, shipment, or quantity; plus exclusions, cancellations, holds, and period rule.
订单、订单行、计划行、发运或数量；以及排除、取消、冻结和期间规则。
Requested date vs promised date需求日期与承诺日期怎么选
Customer-requested date measures performance against customer need. Supplier-confirmed or committed date measures adherence to an accepted promise. Both can be valuable, but they answer different questions. A supplier may keep an easy promise while missing the customer's original need; conversely, it may miss an unrealistic request while honoring an agreed confirmation.
客户需求日衡量是否满足客户需要；供应商确认日或承诺日衡量是否兑现已接受的承诺。两者都有价值，但回答的问题不同。供应商可能兑现了一个宽松承诺，却没满足客户最初需求；也可能未满足不现实的需求日，却按双方确认日期交付。
Avoid silently replacing an original promise with the latest revised date. If dates can change, retain date history and define a freeze point—for example, the committed date as of order acceptance or seven days before delivery. Track late promise changes separately, otherwise repeated replanning can make service appear better without improving physical flow.
不要用最新修改日期静默覆盖原始承诺。如果日期允许变化，应保留历史并定义冻结点，例如订单接受时的承诺日，或交付前七天的承诺日。承诺日期的迟改应单独跟踪，否则反复重排可能让服务指标变好，却没有改善实际物流。
Define the actual delivery event定义“实际交付”的业务事件
“Shipped on time” is not the same as “delivered on time.” A ship confirmation measures warehouse dispatch; a carrier scan measures a network event; proof of delivery measures arrival; goods receipt measures the customer's posting process; acceptance may occur later after inspection. Use the event closest to the service promise and disclose the source.
“准时发运”不等于“准时交付”。发运确认衡量仓库出库，承运扫描衡量运输节点，签收证明衡量到达，入库过账还受客户操作影响，验收则可能在检验后才发生。应选择最贴近服务承诺的事件，并披露数据来源。
Oracle's supplier-performance documentation, for example, compares an estimated arrival date with the first receipt date. SAP documentation shows other valid configurations, including requested ship or delivery dates compared with ASN ship or delivery dates, with configurable early and late windows. The lesson is not that one system is universally correct; it is that the comparison pair must be explicit.
例如，Oracle 的供应商绩效文档把预计到达日与首次收货日比较；SAP 文档则展示了其他有效配置，包括把需求发运日或交付日与 ASN 的发运日或交付日比较，并设置提前和延迟窗口。重点不是哪套系统永远正确，而是比较的日期对必须明确。
Order, line, and quantity-weighted OTD订单、订单行与数量加权 OTD
| Variant口径 | Formula unit公式单位 | Best for适合场景 | Watch out注意事项 |
|---|---|---|---|
| Order OTD | Eligible orders合格订单 | Customer promise view客户承诺视角 | One late line may fail the whole order一条晚到可能使整单失败 |
| Line OTD | Order or schedule lines订单行或计划行 | SKU and supplier diagnosisSKU 与供应商诊断 | Large orders carry more weight大订单行数权重更高 |
| Quantity-weighted OTD | Units due and on time应交与准时数量 | Volume and material flow体量与物料流 | High-volume items can dominate高体量品项可能主导结果 |
| Shipment OTD | Shipments or stops发运或停靠 | Carrier and route operations承运商与线路运营 | Split shipments change counts拆分发运会改变计数 |
Do not average percentages from groups with different denominators. Aggregate the underlying on-time counts and eligible counts, then divide. Report more than one grain when executives need a customer-level result and operators need diagnostic detail.
不要直接平均分母不同的分组百分比。应先汇总准时数量与合格数量，再相除。当管理层需要客户级结果、运营人员需要诊断明细时，可以同时报告多个粒度。
Interactive on-time delivery calculator交互式准时交付率计算器
Enter aggregated counts from the same due-date cohort and policy. The calculator displays order, line, and quantity-weighted rates side by side so weighting differences are visible.
输入同一到期队列、同一规则下的汇总数量。计算器并排展示订单、订单行和数量加权结果，让权重差异清晰可见。
This tool validates arithmetic, not date logic. Before publishing, inspect sampled records and confirm that each numerator is a subset of its denominator.
该工具验证算术，不验证日期逻辑。发布前应抽查记录，并确认每个分子都是对应分母的子集。
Worked OTD exampleOTD 完整计算示例
A business has 250 eligible customer orders due in June. Under its frozen promise-date and proof-of-delivery policy, 218 arrive within the approved window. Order OTD is 218 ÷ 250 × 100 = 87.2%, leaving 32 late or otherwise noncompliant orders.
某企业 6 月共有 250 个到期合格客户订单。按照冻结承诺日与签收证明口径，218 个在批准窗口内到达。订单 OTD 为 218 ÷ 250 × 100 = 87.2%，还有 32 个迟到或不合规订单。
Those orders contain 600 eligible lines, of which 552 are on time. Line OTD is 92.0%. They also contain 12,000 eligible units, of which 11,040 are on time, producing quantity-weighted OTD of 92.0%. The higher line and quantity rates show that late performance was concentrated in fewer orders—perhaps small multi-line orders or orders failed by a single late line.
这些订单含 600 条合格订单行，其中 552 条准时，行 OTD 为 92.0%；合格数量为 12,000 件，其中 11,040 件准时，数量加权 OTD 也是 92.0%。订单率更低，说明延迟集中在较少订单中，可能是小型多行订单，或整单因一条晚到订单行而失败。
Early delivery is not automatically on time提前交付不一定等于准时
A one-sided rule—anything before the deadline is on time—is simple, but it can reward deliveries that create dock congestion, storage cost, labor disruption, inventory carrying cost, or premature cash requirements. A two-sided window captures the operational meaning of “when expected.”
“只要不晚于截止日就算准时”的单边规则很简单，却可能奖励造成月台拥堵、仓储成本、劳动力扰动、库存持有成本或提前占用资金的交付。双边窗口更能体现“按预期时间到达”的运营含义。
Example: promised June 12, one calendar day early allowed, no late days allowed. June 11–12 is on time; June 10 is too early; June 13 is late. If business-day logic applies, calculate with the correct site calendar and time zone rather than subtracting raw timestamps.
示例：承诺日为 6 月 12 日，允许提前一个自然日，不允许延迟。6 月 11–12 日属于准时；6 月 10 日过早；6 月 13 日迟到。如果采用工作日逻辑，应使用正确的站点日历与时区，而不是直接减时间戳。
Handle partial and split deliveries consistently一致处理部分交付与拆分发运
If 80 of 100 units arrive on the promised date and 20 arrive later, several defensible outcomes exist. Whole-order OTD can fail the order because the complete requirement was not present. Quantity-weighted OTD can credit 80 units. Line OTD can score each line separately. A first-receipt rule may pass the delivery even though it says little about completion.
如果 100 件中有 80 件在承诺日到达，剩余 20 件随后到达，可以有多种合理结果：整单口径可因未齐量而判失败；数量加权口径可给 80 件准时信用；行口径可逐行评分；首次收货口径甚至可能判为通过，但无法说明是否完整。
Select the rule that matches the service promise and use a stable parent-child model linking order, line, schedule, shipment, receipt, and quantity. Never count each split shipment as a new opportunity unless shipment count is intentionally the denominator.
应选择与服务承诺一致的规则，并建立稳定的订单—订单行—计划行—发运—收货—数量父子模型。除非分母本来就是发运次数，否则不要把每次拆分发运当成新的达标机会。
On-time delivery vs OTIF准时交付与 OTIF 的区别
OTD measures “when.” OTIF measures “when” and “how much” together. An order delivered on the promised date with only 80% of the required quantity may pass a date-only OTD policy but fails OTIF. Conversely, a complete order delivered late fails both.
OTD 衡量“何时”，OTIF 同时衡量“何时”和“多少”。如果订单在承诺日到达但仅交付 80% 数量，它可能通过纯日期 OTD，却会在 OTIF 中失败；齐量但迟到的订单则两者都失败。
Keep separate KPIs when teams need to diagnose timeliness and completeness independently. Use the combined metric when the customer promise requires both. See the dedicated OTIF guide for in-full rules, quantity tolerances, and joint pass logic.
当团队需要分别诊断时间与齐量问题时，应保留两个 KPI；当客户承诺要求二者同时满足时，再使用组合指标。关于齐量规则、数量容差和联合通过逻辑，请阅读独立的 OTIF 指南。
Prepare auditable OTD data准备可审计的 OTD 数据
At minimum, retain order and line identifiers, customer or supplier, product, site, requested date, confirmed and historical promise dates, scheduled quantity, shipment identifiers, event timestamps, receipt or proof-of-delivery timestamp, received quantity, status, cancellation and hold flags, time zone, calendar, and reason code.
至少应保留订单与订单行标识、客户或供应商、产品、站点、需求日、确认承诺日及其历史版本、计划数量、发运标识、事件时间、收货或签收证明时间、实收数量、状态、取消与冻结标记、时区、日历和原因代码。
Normalize timestamps to an agreed business time zone but preserve originals. Deduplicate repeated scans and receipts; distinguish null from “not yet delivered”; map status codes before applying exclusions; and record which policy version classified each row. Reconcile eligible counts to source-system order cohorts before trusting the rate.
将时间戳统一到约定业务时区，同时保留原始值；去除重复扫描与收货；区分空值与“尚未交付”；应用排除前先映射状态代码；记录每行使用的政策版本。可信任比例之前，应把合格数量与源系统到期订单队列对账。
Build the KPI in seven steps七步建立 OTD KPI
- State the service question.明确服务问题。 Supplier reliability, customer delivery, carrier arrival, and warehouse dispatch need different events.供应商可靠性、客户交付、承运到达和仓库发运需要不同事件。
- Freeze the reference-date rule.冻结基准日期规则。 Choose requested, committed, contractual, or scheduled date and preserve revisions.选择需求、承诺、合同或计划日期，并保留修改历史。
- Define event, window, calendar, and time zone.定义事件、窗口、日历与时区。 Include early as well as late tolerance.同时明确提前与延迟容差。
- Choose grain and denominator cohort.选择粒度与分母队列。 Prefer objects due in the period, including overdue open items.优先按期间到期对象统计，并包括逾期未结。
- Document exclusions.记录排除项。 Apply cancellations, customer holds, invalid dates, and approved exceptions consistently.一致处理取消、客户冻结、无效日期和批准例外。
- Reconcile and sample.对账并抽样。 Trace pass, late, early, open, partial, revised, and excluded records to source events.将准时、延迟、过早、未结、部分、改期及排除记录追溯到源事件。
- Publish rate plus diagnostics.同时发布比例与诊断。 Show denominator, missing-data count, early/late distribution, trend, and reason mix.展示分母、缺失数据量、提前/延迟分布、趋势与原因结构。
Common OTD calculation errors常见 OTD 计算错误
- Using actual receipt month as the denominator period, which hides undelivered late orders.按实际收货月确定分母，导致尚未交付的逾期订单消失。
- Mixing requested, original promise, latest promise, ship, receipt, and POD dates in one trend.在同一趋势中混用需求日、原始承诺、最新承诺、发运、收货和签收日期。
- Counting early deliveries as successful without checking dock and inventory consequences.未考虑月台和库存影响，就把提前交付全部算作成功。
- Changing partial-delivery or exclusion rules between suppliers or periods.在供应商或期间之间改变部分交付或排除规则。
- Averaging percentages instead of aggregating numerator and denominator counts.直接平均百分比，而不是汇总分子与分母。
- Publishing a target without disclosing grain, window, denominator, or data completeness.发布目标时不披露粒度、窗口、分母或数据完整性。
There is no universal “good” OTD percentage independent of contract, product criticality, lead time, market, and measurement design. Benchmark only after aligning definitions; then set targets from customer requirements, baseline capability, risk, and improvement economics.
脱离合同、产品关键性、交期、市场和指标设计，不存在通用的“良好” OTD 百分比。只有在定义一致后才能做基准比较，再结合客户要求、基线能力、风险与改进经济性设定目标。
Improve on-time delivery with cause-based analysis用原因分析改善准时交付
A rate identifies a gap; it does not explain it. Segment late deliveries by supplier, customer, product family, site, lane, carrier, planner, promise horizon, order size, priority, and days late. Pair these views with reason codes such as material shortage, capacity constraint, quality hold, planning change, picking delay, missed carrier cutoff, transit disruption, customer appointment, master-data error, and receipt-posting lag.
比例只能指出差距，不能解释原因。应按供应商、客户、产品族、站点、线路、承运商、计划员、承诺跨度、订单规模、优先级和延迟天数分层，并结合缺料、产能约束、质量冻结、计划变更、拣选延迟、错过承运截点、运输中断、客户预约、主数据错误和收货过账滞后等原因代码。
Prioritize by customer impact and recoverable volume, not only event count. Use control charts or stable trend bands to distinguish persistent process shifts from ordinary variation. Review the largest actionable cause, assign an owner and due date, and verify whether the intervention improved future due-date cohorts without increasing early deliveries, expedites, inventory, or cost.
优先级不仅看事件数量，还要看客户影响与可挽回体量。可用控制图或稳定趋势带区分持续性流程变化与普通波动。针对最大的可行动原因指定负责人和截止日，并验证措施是否改善后续到期队列，同时没有增加过早交付、加急、库存或成本。
How InfiniSynapse supports OTD analysisInfiniSynapse 如何支持 OTD 分析
InfiniSynapse can serve as an analysis layer across connected order extracts, shipment files, receipt records, supplier scorecards, notes, and exception evidence. Analysts can compare suppliers, customers, products, sites, routes, and causes; inspect outliers; and prepare governed summaries for operational review.
InfiniSynapse 可作为分析层，连接订单导出、发运文件、收货记录、供应商评分卡、备注和异常证据。分析人员可以比较供应商、客户、产品、站点、线路和原因，检查异常值，并为运营复盘准备有治理依据的摘要。
Boundary: this is analytical support, not logistics execution. InfiniSynapse is not presented as an order-management system, WMS, TMS, supplier portal, dispatch scheduler, carrier-control tool, automated notification workflow, inventory allocator, delivery confirmer, or ERP writeback mechanism.
边界：这里描述的是分析支持，而不是物流执行。InfiniSynapse 不被描述为订单管理系统、WMS、TMS、供应商门户、派车排程、承运控制、自动通知工作流、库存分配、交付确认或 ERP 回写机制。
Turn delivery records into an auditable OTD view把交付记录转化为可审计的 OTD 视图
Prepare order lines, requested and confirmed dates, date-change history, shipment and receipt events, POD timestamps, quantities, cancellations, holds, site calendars, supplier or carrier fields, and reason codes. Then use InfiniSynapse to explore the connected evidence and investigate late-delivery patterns.
准备订单行、需求与确认日期、日期变更历史、发运与收货事件、签收时间、数量、取消、冻结、站点日历、供应商或承运商字段和原因代码，再使用 InfiniSynapse 探索关联证据并调查延迟模式。
Try InfiniSynapse Online在线体验 InfiniSynapseOn-time delivery FAQ准时交付常见问题
It is the share of eligible deliveries completed within an approved window relative to the governing date.
它是相对于约定基准日期，在批准窗口内完成的合格交付占全部到期合格对象的比例。
Divide on-time eligible deliveries by all eligible deliveries due in the period, then multiply by 100.
用统计期内准时的合格交付除以该期应交付的全部合格对象，再乘以 100。
Only when policy allows it. A two-sided window can classify excessively early deliveries as noncompliant.
只有政策允许时才算。双边窗口可以把过早交付判为不合规。
Require the whole order, score lines separately, or weight by quantity—but document and keep the rule stable.
可以要求整单齐套、逐行评分或按数量加权，但必须记录规则并保持稳定。
OTD tests timing; OTIF tests timing and complete quantity together.
OTD 检查时间，OTIF 同时检查时间与齐量。
No. It is positioned here as an analysis layer, not an OMS, WMS, TMS, supplier portal, or ERP execution tool.
不是。这里将其定位为分析层，而非 OMS、WMS、TMS、供应商门户或 ERP 执行工具。
Sources and limitations来源与局限
Method references: SAP: On-Time Delivery; SAP: Rating Criteria for Supplier Performance Management; Oracle: Supplier Performance; and Oracle: Monitoring Operational Metrics. Sources were reviewed August 18, 2026.
方法参考：SAP：On-Time Delivery；SAP：供应商绩效评分标准；Oracle：供应商绩效；以及 Oracle：运营指标监控。来源核验于 2026 年 8 月 18 日。
This page provides an adaptable measurement framework, not a universal accounting or contractual standard. Local agreements, incoterms, customer calendars, system behavior, and regulatory obligations may require different definitions. Validate the policy with operations, procurement, sales, finance, legal, and affected trading partners before using OTD for incentives or penalties.
本文提供可调整的指标框架，不是通用会计或合同标准。当地协议、国际贸易术语、客户日历、系统行为与监管义务可能要求不同定义。在把 OTD 用于激励或处罚前，应与运营、采购、销售、财务、法务及相关贸易伙伴共同确认政策。