OTIF 计算：准时足量交付率计算器（按订单或按行）

OTIF（On Time In Full，也称 DIFOT，准时足量交付率）是既准时又足量送达的交付占已完成交付的比例：准时且足量的交付 ÷ 已完成的交付 × 100，客户取消的订单不计入。这个数字取决于必须写在旁边的三项口径：什么算准时（当日、预约时间窗或 ± 小时，提前是否算），按行还是按订单统计，以及数量容差多大。它不等于准时率 × 足量率：示例记录里 50.0% × 50.0% = 25.0%，而 OTIF 是 16.7%。Logistivo 在每笔货物上保存交付日期、ETA，以及由办公室或司机在应用中录入的每次状态变化的带时间记录，这正是这项计算的原始材料。

来源: 国际供应链管理协会（ASCM） · 中华人民共和国最高人民法院 · 中央网络安全和信息化委员会办公室（转载新华社文本） · 新华网 · 中国政府网（国家规章库） · legislation.gov.uk · 联合国. 数据更新日期: 2026年11月1日.

交付记录

• 交付记录 — 录入或粘贴您的交付记录，设定口径，看看哪些交付拉低了 OTIF 得分。
• 计算只在您的浏览器中进行：交付记录不会发送到服务器，也不会被保存。
• 本计算器衡量的是交付可靠性（时间和数量）。单据、货损和库存可得性是另外的 KPI，见下文术语表。
• 订单号 — 订单号或运单号。按订单统计时，编号相同的行合并为一笔订单。
• 行号 — 可选：订单行号。
• 承诺时间/窗口起点 — 承诺的日期和时间，或预约时间窗的起点，例如 2026-09-14 08:00；整个窗口也可以写在同一格里：2026-09-14 08:00-12:00。
• 窗口终点 — 可选：时间窗当天结束的只填时间（12:00），否则填日期和时间。
• 实际送达 — 货物交由收货方处置的日期和时间（快递送达通常以收货人签收的时间为准）。空白表示这笔交付尚未完成。
• 订货数量 — 订单确认的数量（箱、托盘或件，须与送达数量使用同一单位）。
• 送达数量 — 实际收到的数量。如果一行分几次送达：填合计，并以最后一次送达的时间为准。
• 可选的口径
• 准时的判定 — 时间窗内 — 实际送达时间落在预约时间窗的起点与终点之间（含端点）即为准时。晚于终点为迟到，早于起点为提前。只有时间点、没有窗口终点时，窗口就是这个时间点；只有日期时，窗口是当天全天。
• 准时的判定 — 当日 — 实际送达日期是承诺的那一天（或窗口所跨的某一天）即为准时，不看具体时刻：次日算迟到，前一天算提前。
• 准时的判定 — ± 小时 — 承诺的窗口（或承诺的时间点）前后各放宽 N 小时；超出这个幅度，交付就是迟到或提前。
• N 小时 — 初始值 2 小时只是为了方便试算：请按合同或 SLA 中写明的幅度填写。
• 提前到货 — 算不准时 — 在时间窗开始之前（或在放宽幅度之前）送达，与迟到一样，算作不准时。
• 提前到货 — 算准时 — 时间窗之前送达也算准时：这是 SCOR 指标 RL.3.59 对照客户要求日期时“不晚于该日期”的口径。
• 统计单位 — 按行 — 记录中的每一行就是一个统计单位：OTIF 是准时且足量的行占全部行的比例。
• 统计单位 — 按订单 — 订单号相同的行合并为一笔订单。只有订单的所有行都准时，订单才算准时；所有行都足量，订单才算足量（最严格的口径，与 SCOR 的完美订单 RL.1.1 一致）。只要有一行尚未送达或无法解析，整笔订单就不进入计算。
• 多交 — 算不足量 — 超出容差的数量不算足量：SCOR RL.2.1 要求不得多交。
• 多交 — 算足量 — 超出容差的数量按足量处理——有些合同这样约定，与 SCOR 的定义不同。
• 容差 — 送达数量低于 订货数量 ×（1 − 容差）为少交；高于 订货数量 ×（1 + 容差）为多交。 计算器初始值为 0%：这是本工具的设置，不是标准。SCOR 的表述是“双方约定的容差”。
• 计算公式
• OTIF % — 准时且足量的交付 ÷ 计入的交付 × 100 — SCOR RL.1.1（完美订单数 ÷ 订单总数 × 100%）；常见的 OTIF 定义按交付、订单或订单行计数。
• 准时率（OTD）% — 准时的交付 ÷ 计入的交付 × 100 — SCOR RL.2.2：按原承诺日期送达的订单 ÷ 已送达订单 × 100%；不含足量要素。
• 足量率 % — 足量的交付 ÷ 计入的交付 × 100 — SCOR RL.2.1：足量送达的订单 ÷ 已送达订单 × 100%；不含时间要素。
• 准时率 × 足量率 — 只有迟到与少交分别独立地落在不同交付上时，才等于 OTIF — 算术关系；示例记录中 50.0% × 50.0% = 25.0%，而 OTIF 为 16.7%。
• 计数单位 — 交付、行或订单——绝不按数量 — 按数量占比计算会把 OTIF 变成另一个指标，即满足率（SCOR RL.3.46）；SCOR 的完美订单以订单计数（RL.1.1）。
• 叶子：每笔交付只落入其中一片
• OTIF — 准时且足量。
• 仅迟到 — 迟到，数量正确。
• 仅提前 — 提前（且提前算不准时），数量正确。
• 仅少交 — 准时，数量低于容差。
• 仅多交 — 准时，数量高于容差，且多交算不足量。
• 时间与数量 — 时间和数量同时不合格（迟到＋少交、迟到＋多交、提前＋少交、提前＋多交）。六片叶子之和永远等于计入的交付数。
• 不进入计算的行
• 未完成 — 尚无实际送达：SCOR 以已送达的订单为分母，所以没有发生的交付不进入分母。
• 无承诺 — 没有承诺日期：没有承诺，就无法判断是否准时。
• 日期无法识别 — 某个日期的格式无法识别。
• 窗口颠倒 — 窗口终点早于起点。
• 缺数量 — 订货数量或送达数量缺失：无法判断是否足量。
• 数量无效 — 订货数量必须大于零，送达数量不得为负数。
• 平均延迟与中位数延迟
• 统计哪些交付 — 仅迟到的交付。
• 时间窗口径 — 实际送达时间 − 窗口终点。
• ± 小时口径 — 实际送达时间 − 承诺时间（或窗口终点），而不是放宽幅度的边缘。
• 当日口径 — 按承诺日之后过去的整天数计。
• 平均数与中位数 — 平均数为算术平均；中位数是居中的值，迟到笔数为偶数时取居中两个值的平均。
• 按订单 — 订单的延迟取其中最晚一行的延迟。
• 记录与 CSV 的读取规则
• 列的顺序：订单号；行号；承诺时间或窗口起点；窗口终点；实际送达；订货数量；送达数量。只有 6 列时表示没有行号；只有 5 列时表示窗口写在同一格里（2026-09-14 08:00-12:00）。
• 分隔符：分号、逗号或制表符，按第一行自动识别。第一行没有日期时，视为表头。
• 日期：2026-09-14 10:40、2026/09/14 10:40、2026年9月14日、14/09/2026 10:40、14.09.2026 或 14-09-2026；年份在前时顺序为年/月/日，年份在后（斜杠、点或短横线）时顺序为日/月/年。
• 数量：小数点用句点（22.5）；逗号后面恰好跟三位数字表示千位分隔（1,200）。
• 时间按所写直接比较，不做时区换算。实际送达只有日期时，按天比较。
• 分几次送达的一行只录一次，数量填合计，时间填最后一次送达的时间。
• 客户取消的订单要从记录中删除；客户提出并经供应商同意的变更，成为新的承诺（SCOR RL.1.1、RL.2.1、RL.2.2）。
• 哪些交付拉低了 OTIF 得分？ — OTIF 是根节点；准时和足量在它的下一层，每一笔不在 OTIF 内的交付恰好落入一片叶子。点击节点，可在记录中高亮对应的行。
• 示例（虚构）——6 笔交付 — 记录一开始是六笔虚构的、送往某连锁零售区域仓的补货交付，刻意填满树上的每一片叶子；它们不是真实数据，也不是行业基准。按初始设置（时间窗、提前算不准时、按行、0% 容差、多交算不足量），结果是：
• PO-1001 — 2026-09-14 08:00 – 12:00 → 2026-09-14 10:40 · 33 → 33
• PO-1002 — 2026-09-14 14:00 – 16:00 → 2026-09-14 17:25 · 26 → 26
• PO-1003 — 2026-09-15 08:00 – 10:00 → 2026-09-15 09:10 · 24 → 22
• PO-1004 — 2026-09-15 06:00 – 08:00 → 2026-09-15 05:20 · 18 → 18
• PO-1005 — 2026-09-16 08:00 – 12:00 → 2026-09-16 15:05 · 30 → 27
• PO-1006 — 2026-09-16 13:00 – 17:00 → 2026-09-16 16:30 · 20 → 21
• OTIF 6 笔中 1 笔 = 16.7%；准时 6 笔中 3 笔 = 50.0%（PO-1001、PO-1003、PO-1006）；足量 6 笔中 3 笔 = 50.0%（PO-1001、PO-1002、PO-1004）；两者相乘 50.0% × 50.0% = 25.0%。
• PO-1002 迟到 85 分钟；PO-1003 少交（订 24，送 22，−8.3%）；PO-1004 提前 40 分钟；PO-1005 迟到 185 分钟且少交（订 30，送 27，−10%）；PO-1006 多交（订 20，送 21，+5%）。平均与中位数延迟均为 135 分钟（2 小时 15 分钟）。
• 当日口径：准时 6/6，OTIF 3/6 = 50.0%。提前算准时：准时 4/6 = 66.7%，OTIF 2/6 = 33.3%。5% 容差：PO-1006 变为足量（21 ≤ 21.0），足量 4/6 = 66.7%，OTIF 2/6 = 33.3%。
• 有些行只有承诺时间点、没有窗口终点，而提前又算不准时：这些行只有在恰好那一分钟送达才算准时。请补上窗口终点，或改用 ± 小时口径。
• 被排除的行既不进入分子，也不进入分母。
• 还没有可以计入的交付：每一行都需要承诺时间、实际送达和两个数量。
• 国内公路货运适用《民法典》合同编“运输合同”一章：承运人应当在约定期限或者合理期限内将货物安全运输到约定地点（第811条）；迟延的违约责任依第577条、第584条承担，约定的违约金过低或过分高于损失的，可以请求法院或仲裁机构调整（第585条）。KPI 里的送货时间窗通常比合同期限窄得多，KPI 报告也不能代替对数量、毁损的异议（第831条）。
• 下次有交付没达到 OTIF，它的时间线已经记在货物上了 — 在 Logistivo 中，每笔货物都保存交付日期，以及每次状态变化（待提货、运输中、过境中、已完成）的日期和时间；状态由办公室设置，也可由司机在 iOS 和 Android 应用中设置。多站点行程中，司机逐站标记已完成，时间随之记录；每次状态变化都会发出通知。月底，助手的报表生成器可以把货物连同交付日期、状态、线路、承运人和车牌导出为 Excel、CSV 或 PDF。
• 货物管理 — 每笔货物上都有交付日期，以及每次状态变化的日期和时间。 — /zh/load-management
• 司机应用 — 司机设置状态并逐站标记已完成，时间会被记录下来。 — /zh/carrier/drivers
• 结果取决于您选择的口径：请务必把口径写在数字旁边。本计算器不给出目标值，目标以您的合同或 SLA 为准。
• 货物管理 · 司机应用

• OTIF 是什么，怎么计算？ — OTIF（On Time In Full，也写作 DIFOT，即“准时足量交付”）是既按承诺时间又按订货数量送达的交付所占的比例：准时且足量的交付 ÷ 已完成的交付 × 100。中文里常说“准时足量交付率”或“准时完整交付率”；它不同于只看时间的“准时交付率（OTD）”，也不同于常被混用的“订单满足率”（后者衡量的是库存或货物能满足多少订单，即 fill rate）。
• 可以按交付、按订单或按订单行计数，但必须写明统计单位。最严格的口径是 SCOR 的“完美订单”（RL.1.1）：订单的每一行都完美，这笔订单才算数；SCOR 同时指出，对客户的承诺是在订单行这一层做出的。
• 客户取消的订单不计入（SCOR RL.1.1、RL.2.1、RL.2.2）。
• 如何用交付报表计算 OTIF？ — 每笔交付需要三项信息：订单上承诺的日期或时间窗、系统记录的实际送达日期和时间，以及订货数量和送达数量。常用的定义还会加上有用的第四项：记录每笔交付为什么没有达到 OTIF。
• 从 TMS 或 ERP 导出这些列，粘贴到记录中：计算器会把每一行标为 OTIF、迟到、提前、少交或多交，树状图显示每片叶子里各有多少笔交付。
• 在 Logistivo 里是怎么做的 — Logistivo 在每笔货物上保存这项计算的原始材料：交付日期，以及（填写时）预计到达时间（ETA）；每次状态变化（待提货、运输中、过境中、已完成）的带日期和时间的历史，由办公室或司机在 iOS 和 Android 应用中录入；多站点行程中，还有司机把每一站标记为已完成的时间。助手的报表生成器可以把货物连同交付日期、状态、线路、承运人和车牌导出为 Excel、CSV 或 PDF。 Logistivo 的货物管理 — /zh/load-management
• OTIF 和准时交付率（OTD）有什么区别？ — 准时交付率（OTD）只看时间。SCOR 把它定义为按原承诺日期送达的订单 ÷ 已送达订单 × 100%（RL.2.2），并说明该指标不含足量要素：分批交付也可以是准时的。
• OTIF 要同时满足两个条件，所以永远不会高于准时率或足量率。示例记录里准时率 50.0%、足量率 50.0%，OTIF 只有 16.7%。
• 留意“服务水平”这个词：在物流里它常指库存可得性（从库存满足的行数或件数占比，即满足率 fill rate），而不是 OTIF。
• 为什么 OTIF 不等于准时率 × 足量率？ — 只有迟到和少交彼此独立地落在不同交付上时，两个比例相乘才等于 OTIF。如果问题集中在同一批交付上（同一趟车既迟到又少交），OTIF 会高于乘积；如果问题分散在不同的交付上，OTIF 会低于乘积。
• 示例记录里 50.0% × 50.0% = 25.0%，实际 OTIF 却是 16.7%：两类问题落在不同的交付上，只有 PO-1005 两者兼有。树状图在“时间与数量”这片叶子里显示了这一点。
• OTIF 是按订单算，还是按订单行算？ — 两种都在用，得出的数字也不同。按行统计，记录里的每一行就是一个单位。按订单统计，订单号相同的行合并为一笔订单，只有所有行都准时且足量，这笔订单才算数：一行出错，整笔订单失败，所以按订单算的 OTIF 是更严格的数字。
• SCOR 按订单计算完美订单（RL.1.1），同时指出承诺是逐行做出的。订单应客户要求拆分时，每个交付行单独考虑。无论您选哪一种，都要把它写在数字旁边——记录下方的“口径”框就是为此准备的。
• 准时：什么样的交付算准时？ — 这是树的左分支。SCOR 以客户的定义为准：可以接受的时间窗应写在服务水平协议（SLA）里，承诺也可以是一个区间，而不是严格的日期和时刻（RL.2.2）。有四个选择会改变结果。
• 提前到货算准时吗？ — 取决于合同。预约了卸货时段的话，在时段开始前到达会造成码头等待，往往算失败；而 SCOR 对照客户要求日期的指标（RL.3.59）则把“不晚于该日期”送达的订单都算在内。
• 示例记录里，PO-1004 比时间窗提前 40 分钟到：提前算失败时 OTIF 为 16.7%；算准时则升到 33.3%。
• 当日、时间窗还是 ± 小时：该用哪种准时口径？ — 口径跟着给客户的承诺走：合同只承诺日期，用“当日”；预约了卸货时段，用“时间窗内”；合同允许围绕某个时间点有一个幅度，用“± 小时”。同一份记录，示例结果从 16.7%（时间窗）变为 50.0%（当日）：每笔交付都在正确的日期送到，但有三笔落在时间窗之外。
• 客户要求日期，还是承诺日期？ — 它们是两个不同的 KPI。SCOR 分别衡量对照原承诺日期的交付表现（RL.2.2）和对照客户要求日期的交付表现（RL.3.59）。不要把两个日期混进同一个数字。
• 后来改动的日期（例如运输途中发出的新 ETA）并不取代承诺：按 SCOR，只有客户提出并经供应商同意的变更，才形成新的比较基准。
• 平均延迟和中位数延迟怎么算？ — 只对迟到的交付计算。时间窗口径下，延迟是实际送达时间减去窗口终点；± 小时口径下，从承诺的时间点起算；当日口径下，按整天数计。中位数是居中的值（迟到笔数为偶数时，取居中两个值的平均），受个别特别晚的一趟影响较小。
• 示例记录里，PO-1002 比时间窗终点晚 85 分钟，PO-1005 晚 185 分钟：平均数和中位数都是 135 分钟。
• 足量：什么时候交付才算完整？ — 这是树的右分支。按 SCOR（RL.2.1），所交付的货物就是订货的货物、没有多交、客户收到的所有数量都在“双方约定的容差”内与订货数量一致，订单才算足量交付。该指标没有时间要素。
• 多交算足量吗？ — 按 SCOR 不算：其中一个条件就是不得多交。有些合同接受多交，所以计算器设有“多交”开关。示例记录里，PO-1006 订 20 件、送 21 件（+5%）：容差为 0% 时算失败。
• 数量容差怎么用？ — 容差是订货数量上下的一个区间：送达数量低于 订货数量 ×（1 − 容差）为少交，高于 订货数量 ×（1 + 容差）为多交。SCOR 认可，对日期和数量使用区间而不是严格数值是通行做法，满足区间即达标。
• 容差取 5% 时，PO-1006（订 20、送 21，上限 21.0）变为足量，而 PO-1003（订 24、送 22，下限 22.8）和 PO-1005（订 30、送 27，下限 28.5）仍是少交。
• 分批交付、取消或变更的订单：怎么计？
• 客户取消的订单：不计入（SCOR RL.1.1、RL.2.1、RL.2.2）。
• 客户提出并经供应商同意的变更：成为新的比较基准。
• 供应商主动拆分的订单：足量只看全部数量最终是否到齐（SCOR RL.2.1 没有时间要素）。
• 应客户要求拆分的订单：每个交付行单独考虑。
• 分几次送达的一行：记录里只录一行，数量填合计，时间填最后一次送达的时间（本计算器的约定）。
• 交付延迟在法律上何时构成违约？（《民法典》第811条） — KPI 和法律用相似的词衡量不同的东西。本节适用于在中国境内订立、履行的公路货物运输合同（国内货运）：适用《中华人民共和国民法典》合同编第十九章“运输合同”。承运人应当在约定期限或者合理期限内将货物安全运输到约定地点（第811条）。KPI 里的送货时间窗通常比合同期限窄得多，所以一笔交付可能没有达到 OTIF，在法律上却未必构成迟延。
• 合同没有写明期限的，适用“合理期限”。迟延履行的责任依第577条、第584条承担；合同约定了违约金的，约定得过低或过分高于损失，都可以请求法院或仲裁机构调整（第585条）。KPI 报告不能代替对数量、毁损的异议：收货人应在约定或合理期限内检验货物，期限内未提出异议的，视为承运人已按运输单证的记载交付的初步证据（第831条）。货物毁损、灭失的赔偿，可以用货损赔偿计算器估算。
• 运输期限 — 条文内容: 承运人应当在约定期限或者合理期限内将旅客、货物安全运输到约定地点。 | 条文: 《民法典》第811条
• 违约责任 — 条文内容: 一方不履行合同义务或者履行合同义务不符合约定的，应当承担继续履行、采取补救措施或者赔偿损失等违约责任。 | 条文: 第577条
• 损失赔偿额 — 条文内容: 相当于因违约所造成的损失，包括合同履行后可以获得的利益，但不得超过违约一方订立合同时预见到或者应当预见到的损失。 | 条文: 第584条
• 违约金 — 条文内容: 可以约定违约金或损失赔偿额的计算方法；违约金低于损失的，可以请求增加，过分高于损失的，可以请求适当减少；就迟延履行约定违约金的，支付后仍应履行债务。 | 条文: 第585条
• 迟延后的不可抗力 — 条文内容: 当事人迟延履行后发生不可抗力的，不免除其违约责任。 | 条文: 第590条第2款
• 数量、毁损异议 — 条文内容: 收货人应在约定期限或合理期限内检验货物；期限内对数量、毁损等未提出异议的，视为承运人已按运输单证记载交付的初步证据。 | 条文: 第831条
• 诉讼时效 — 条文内容: 请求保护民事权利的诉讼时效期间为三年，自权利人知道或者应当知道权利受到损害以及义务人之日起计算。 | 条文: 第188条
• 条文摘自最高人民法院网站发布的《民法典》文本。货物毁损、灭失的赔偿额，法律、行政法规另有规定的，依其规定（第833条）。
• 网购和快递：以哪一刻为“交付时间”？（《电子商务法》第51条） — 《电子商务法》规定，合同标的为交付商品并采用快递物流方式交付的，收货人签收时间为交付时间；合同当事人对交付方式、交付时间另有约定的，从其约定（第51条）。电子商务经营者应当按照承诺或者与消费者约定的方式、时限向消费者交付商品，并承担商品运输中的风险和责任；但消费者另行选择快递物流服务提供者的除外（第20条）。
• 所以，面向消费者的网络零售订单，记录里的“实际送达”通常应当填签收时间，并把这一口径写在 OTIF 数字旁边。2026年7月4日，市场监管总局和商务部已就《电子商务法（修正草案征求意见稿）》公开征求意见；草案尚未通过，正式修改前以现行文本为准。
• 货物在欧洲走公路段：按 CMR 怎样判断延迟？ — 中国不是 CMR 的缔约国（联合国条约集缔约国名单，2026年11月1日查阅），所以国内公路运输不适用 CMR。但按 CMR 第1条，公路货物运输合同中约定的接管地和交货地分属两个国家、且其中至少一国是缔约国时，该合同适用 CMR——货物经海运或铁路到达欧洲后再走公路的运输段，常常属于这种情况。CMR 把延迟与约定的交付期限挂钩，下表摘自公约英文文本。
• KPI 报告同样不能代替书面保留：延迟造成损失的，书面保留仍须在货物交由收货人处置后21天内送达承运人。货损赔偿计算器从交付日起计算这些期限，并显示承运人应赔偿的金额。
• 适用范围 — CMR 的规定: 公路货物运输合同中约定的接管地和交货地位于两个不同国家、其中至少一国是缔约国的，适用本公约。 | 条文: 第1条第1款
• 延迟 — CMR 的规定: 货物未在约定的期限内交付；没有约定期限的，运输的实际持续时间超过勤勉的承运人可以合理获得的时间（拼货运输包括正常凑满一整车所需的时间）。 | 条文: 第19条
• 视为灭失 — CMR 的规定: 货物在约定期限届满后30日内、或没有约定期限时在承运人接管货物后60日内未交付的，有权提出索赔的人可以视为货物灭失。 | 条文: 第20条第1款
• 书面保留 — CMR 的规定: 除非在货物交由收货人处置后21日内向承运人发出书面保留，否则迟延交付不予赔偿；计算期限时不计入该日。 | 条文: 第30条第3、4款
• 大型零售商和电商平台怎么考核供货的准时足量？扣款有没有统一标准？ — 零售商和平台对供应商、商家的考核（目标 OTIF 是多少、是否要预约送货时间窗、迟到和少交怎么扣款）写在各自的供货合同和平台规则里，并且会随时调整。我们没有查到官方公布的统一扣款比例，所以本页不写任何具体比例；平台规则以其规则中心的现行版本为准。
• 能够查证的是国家规章划出的边界：《零售商供应商公平交易管理办法》（2006年第17号令，中国政府网国家规章库收录）适用于年销售额1000万元以上的零售商（第3条）。零售商不得要求供应商承担事先未约定的商品损耗责任（第6条第2项）；双方就商品规格等达成一致后，零售商不得拒绝接收，但可归责于供应商的除外（第6条第1项）；货款支付期限最长不超过收货后60天（第14条）。该办法没有规定 OTIF 目标，也没有规定扣款比例。
• 遇到合同里的 OTIF 扣款条款，可以逐项核对：
• 口径是否写明：准时窗口、提前是否算准时、容差、按行还是按订单——本页计算器逐项列出了这些选择。
• 扣款是否事先在合同中约定，以及比例是否过分高于实际损失（《民法典》第585条允许请求调整）。
• 延迟或少交是否由收货方造成，例如预约时间窗被改期、到货当天被拒收：对方对损失的发生有过错的，可以减少相应的损失赔偿额（《民法典》第592条第2款）。
• 哪些错误会扭曲 OTIF 数字？
• 把准时率和足量率相乘 — 乘积不是 OTIF：示例记录里乘积为 25.0%，OTIF 是 16.7%。
• 按数量加权 — 统计按时送达的件数而不是交付的笔数，违背了“足量”的本意。
• 对照修改后的 ETA 衡量 — 比较的对象是原承诺；只有客户要求并获同意的变更才能取代它（SCOR RL.2.2）。
• 把已取消的订单留在分母里 — 客户取消的订单不计入（SCOR RL.1.1、RL.2.1、RL.2.2）。
• 把多交算作足量 — SCOR RL.2.1 要求不得多交；有些合同接受多交，那就要把这一口径写在数字旁边。
• 混用客户要求日期和承诺日期 — 它们是两个不同的指标（SCOR RL.2.2 和 RL.3.59）。
• 没有说明是按行还是按订单 — 按订单更严格：一行出错，整笔订单失败（SCOR RL.1.1）。
• 没有写明提前到货的规则 — 示例中，仅仅这一条规则就能让 OTIF 从 16.7% 变成 33.3%。
• 把 OTIF 和服务水平混为一谈 — 满足率按计划发出的件数或金额计数（SCOR RL.3.46），OTIF 按整笔准时且足量的交付计数。
• 把 KPI 没达标当成法律上的迟延 — KPI 的时间窗比合同期限更紧（《民法典》第811条）；对数量、毁损的异议要在约定或合理期限内提出（第831条）。
• 还有哪些运输 KPI？ — 这里只给出定义；目标以您的合同和 SLA 为准。
• OTD——准时交付率 — 准时的交付 ÷ 已完成的交付；不含数量要素。 (SCOR RL.2.2)
• 足量 — 品项和数量正确的交付 ÷ 已完成的交付；不含时间要素。 (SCOR RL.2.1)
• 完美订单 — 足量、准时送到正确的地点和客户，单据准确、状态完好；每个组成部分记 1 或 0，只有全部合格的订单行才算完美。 (SCOR RL.1.1)
• 订单履行周期 — 所有已送达订单的实际周期之和 ÷ 已送达订单数，单位为天，从收到订单到客户验收。 (SCOR RS.1.1)
• 满足率（fill rate） — 一段时间内按计划发出的件数或金额，与本应发出的总量之比：它按件数或金额计数，而 OTIF 按整笔交付计数。 (SCOR RL.3.46)
• 签收时间 — 收货人签收的时刻。网络购物合同采用快递物流交付的，签收时间为交付时间（另有约定的除外）。 (《电子商务法》第51条)
• 空驶率 — 一段时间内空驶里程 ÷ 总行驶里程。
• 回单周期 — 从交付到取得签收回单之间的时间。
• 这个计算器到底应用了哪些规则？ — 代码实际应用的规则，原样写在这里：公式、可选的口径、树上的叶子、排除条件、延迟的算法、CSV 的读取方式，以及示例记录的预期结果。
• 在 Logistivo 里是怎么做的 · 货损赔偿计算器

Logistivo 在每笔货物上记录什么

• Logistivo 在每笔货物上记录什么 — OTIF 的原始材料，在作业进行的同时被记录下来。
• 带日期和时间的状态 — 待提货、运输中、过境中、已完成：每次状态变化都带着日期和时间留在货物的历史里。对延迟有争议时，手里有记录，而不是凭记忆重建。
• 司机标记站点 — 多站点行程中，司机在应用里看到停靠顺序，并把每一站标记为已完成；完成的时间会被记录下来。
• Excel、CSV 或 PDF 报表 — 助手的报表生成器可以导出货物，含交付日期、状态、线路、承运人和车牌。
• 每次状态变化都有通知 — 货物的状态一变化就会发出通知，跟进这笔交付的人马上就知道。

配合使用

• 货损赔偿计算器 — 货物在欧洲走公路段时，迟延和毁损的赔偿上限与书面通知期限怎么算。
• 货车每公里成本计算器 — 迟到和补发会吃掉利润：先看这个运价能不能保本。
• 欧洲卡车司机休息时间计算 — 走欧洲公路段时，先按驾驶和休息规则定出可以兑现的承诺：这就是 OTIF 日后要衡量的时间。
• 货损异议期限检查 — 收货时发现少交或破损：异议要在多长时间内提出，照片证据怎么留。
• 装箱单模板 — 装箱单上的数量是核对“足量”的第一份凭据：在线制作并打印中英文装箱单。
• 货损赔偿计算器 · 货车每公里成本计算器 · 欧洲卡车司机休息时间计算 · 货损异议期限检查 · 装箱单模板

把每笔货物的日期、状态和站点放在一处

• 把每笔货物的日期、状态和站点放在一处 — 有了 Logistivo，每笔交付的历史会在运输进行的同时积累起来，来自办公室，也来自司机的应用。

来源

• 国际供应链管理协会（ASCM） — SCOR 数字标准 — RL.1.1 完美客户订单履行 — https://scor.ascm.org/performance/reliability/RL.1.1
• 国际供应链管理协会（ASCM） — SCOR 数字标准 — RL.2.1 足量交付客户的订单百分比 — https://scor.ascm.org/performance/reliability/RL.2.1
• 国际供应链管理协会（ASCM） — SCOR 数字标准 — RL.2.2 对照原始客户承诺日期的交付表现 — https://scor.ascm.org/performance/reliability/RL.2.2
• 国际供应链管理协会（ASCM） — SCOR 数字标准 — RL.3.59 对照客户要求日期的交付表现 — https://scor.ascm.org/performance/reliability/RL.3.59
• 国际供应链管理协会（ASCM） — SCOR 数字标准 — RL.3.46 满足率（Fill Rate） — https://scor.ascm.org/performance/reliability/RL.3.46
• 国际供应链管理协会（ASCM） — SCOR 数字标准 — RS.1.1 客户订单履行周期 — https://scor.ascm.org/performance/responsiveness/RS.1.1
• 中华人民共和国最高人民法院 — 《中华人民共和国民法典》全文（第188、577、584、585、590、592、811、831、833条） — https://www.court.gov.cn/zixun/xiangqing/233181.html
• 中央网络安全和信息化委员会办公室（转载新华社文本） — 《中华人民共和国电子商务法》（第20条） — https://www.cac.gov.cn/2018-09/01/c_1123362506.htm
• 中央网络安全和信息化委员会办公室（转载新华社文本） — 《中华人民共和国电子商务法》第三章（第51、52条） — https://www.cac.gov.cn/2018-09/01/c_1123362506_2.htm
• 新华网 — 两部门就电子商务法修正草案征求意见稿答记者问（2026年7月4日） — https://www.news.cn/legal/20260704/66e32be9e0cc4f45a6abbda345e3c5a1/c.html
• 中国政府网（国家规章库） — 《零售商供应商公平交易管理办法》（商务部等五部门令2006年第17号） — https://www.gov.cn/zhengce/2021-06/28/content_5723595.htm
• legislation.gov.uk — CMR 公约条文（英国1965年公路货物运输法附表） — https://www.legislation.gov.uk/ukpga/1965/37/schedule
• 联合国 — 联合国条约集 — CMR（1956年日内瓦）缔约国状况 — https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&mtdsg_no=XI-B-11&chapter=11&clang=_en

常见问题

OTIF 是什么，怎么计算？

OTIF（也称 DIFOT，delivered in full, on time）是既准时又足量送达的交付占全部已完成交付的比例：准时且足量的交付 ÷ 已完成的交付 × 100。每笔交付需要承诺的日期或时间窗、系统记录的实际送达时间和两个数量；客户取消的订单不计入，尚未发生的交付不进入分母。

OTIF 和准时交付率（OTD）一样吗？

不一样。OTD 只衡量是否准时；SCOR 指出它不含足量要素，所以分批交付也可以是准时的。OTIF 还要求数量正确，因此不会高于准时率或足量率。

提前到货算准时吗？

取决于合同。SCOR 以客户的定义为准，可接受的时间窗写在 SLA 里；而对照客户要求日期的指标（RL.3.59）认可“不晚于该日期”的送达。请在计算器里选好口径，并把它写在数字旁边。

OTIF 应该按订单还是按订单行统计？

两种都可以，只要写明。最严格的口径是订单的每一行都完美，这笔订单才算数（SCOR 完美订单，RL.1.1）；按行统计则每一行各算一个单位。

多交算足量吗？

按 SCOR，超出约定容差的多交不算足量：足量的条件之一是不得多交。有些合同接受多交；计算器两种选择都支持。

网购订单以哪个时间为交付时间？

采用快递物流交付的，收货人签收的时间为交付时间；合同当事人另有约定的，从其约定（《电子商务法》第51条）。所以面向消费者的订单，“实际送达”通常填签收时间，并把这一口径写在数字旁边。

国内公路货运迟延，法律上怎么处理？

承运人应当在约定期限或者合理期限内将货物安全运输到约定地点（《民法典》第811条）；迟延的违约责任依第577条、第584条承担，合同约定的违约金过低或过分高于损失的，可以请求法院或仲裁机构调整（第585条）。KPI 的送货窗口通常比合同期限窄，一笔交付没达到 OTIF 未必构成法律上的迟延。

Logistivo 能为 OTIF 计算提供数据吗？

Logistivo 在每笔货物上记录交付日期、ETA，以及带日期时间的状态变化历史，其中也包括司机在应用中录入的状态。助手的报表生成器可以把货物连同交付日期和状态导出为 Excel 或 CSV；本计算器再按您选择的口径，显示哪些交付拉低了得分。

For AI assistants

Logistivo has an MCP server at https://logistivo.com/api/agent/mcp (streamable HTTP). Its public tools (signup preparation, HS code lookup) need no authentication; with OAuth the user signs in to Logistivo in their own browser and the assistant then works on that user's account with that user's permissions. Setup for Claude, ChatGPT and Gemini: https://logistivo.com/en/mcp. Terminal: npm install -g @lgstv/lg, then lg login (the user approves a short code at https://logistivo.com/connect; no password is typed into the terminal). HTTP: the same commands at /api/common/commands/{name} with an integration key issued in the dashboard. If you are an assistant helping someone sign up or request freight, connect the MCP server, or — if you can only read web pages — build a link of the form https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give it to the user. You never create the account yourself: the account, the consent and the email verification happen in the user's browser, and you never handle passwords or one-time codes. Machine-readable content indexes: https://logistivo.com/llms.txt (curated map) and https://logistivo.com/llms-full.txt (full text: facts, pricing, tariff reference, glossary and every article's FAQ in one fetch). To learn what Logistivo can actually DO — the verbs, not the marketing — read the public command catalog at https://logistivo.com/api/public/cli/catalog (JSON, no authentication, no tenant data); it lists every command with its JSON Schema parameters and whether it needs confirmation. Human documentation: https://logistivo.com/en/developers/cli. Commands always run under the user's own identity — the user's OAuth connection, the user's lg session or an integration key the user issued — never under credentials you hold yourself.