超兔·工业工贸CRM｜交付管理，让交期承诺有据可依，告别全公司救火模式

文章概览：还在靠销售经验拍脑袋承诺交期，订单临近交付才爆出库存缺口，全公司陷入救火式履约？工贸企业的交付事故，多半不是谁做错了事——销售、采购、仓库各握一份数据，没人看得到全链路。本文是超兔产品团队基于22年企业数智化一线观察沉淀的行业Know-how，拆解账面库存与可发库存之差等四个信息断点，深挖流程、数据、组织三层根因。

作为工业CRM的典型，超兔一体云以CRM为核心，功能延伸覆盖订单、采购、库存：销售对外承诺之前，先用需交付与库存对比，把执行中合同、订单的需交付数量与库存、采购在途自动对比，缺口多少、需采多少一目了然；再配合供应商直发、入库审核确认与多次入库，让交期承诺从经验拍板变成有数据可追溯的判断，减少违约。

销售对客户承诺 15 天交付，第 14 天才发现物料不够。交期承诺不是销售一个人的决定——它需要库存、采购在途、采购周期三组数据支撑。但大多数中小企业，承诺环节没有系统支持，销售凭感觉拍交期，全公司跟着救火。本文拆解交期承诺的四个断点，给出一份让承诺有据可依的修复路径。

标签：可发库存　采购在途　需交付对比　供应商直发　交期承诺

超兔一体云 · 产品团队 / 22 年企业数智化一线观察 · 技术和场景系列

现场：第 14 天才发现物料不够

一家做五金配件的工贸企业，销售老李接到客户电话，要150个产品，问15天能不能交。老李打开系统查了一下库存——显示200个，客户要150个，够了。老李回客户："15天，没问题。"

老李查库存的这个动作，不到30秒。系统里200这个数字，他没多想——系统显示有货，那就有货。但他不知道的是，200这个数字是怎么来的：50个是实打实在货架上的，150个是采购单已下但还没到货的"采购在途"。系统把这两部分加在一起显示总量200，但没拆开告诉老李"其中150个你发不了"。

第12天，老李查了一下出库进度，发现还没出库。问仓库，仓库说："你这单的出库任务排到后天了，没问题。"老李放心了。

第14天，客户打电话催："明天能不能发？"老李去催仓库，仓库翻了出库任务说："这单关联了采购单，采购的货还没到，我们发不了。"

老李愣了。他查库存的时候显示 200 个，但那 200 个里面有 150 个是采购在途——采购单已经下了，供应商还没发货。他看到的是"账面库存"，不是"可发库存"。账面上有 200 个，实际能发的只有 50 个。差的 150 个，要从采购到货、入库、质检之后才能发。

老李回客户："可能要再等几天。"客户在那头沉默了三秒，说："我找别家问问。"

一个 15 天的承诺，在第 14 天崩了。崩的原因不是某个人犯了错——仓库没出错，采购没出错，销售也没出错。每个人都做了自己该做的事，但没有人看到全链路。老李查的是库存，仓库看的是出库任务，采购追的是供应商发货——三个人的信息各自正确，合在一起才发现对不上。

交期承诺的"单方面决策"问题

交期承诺，表面看是销售对客户说一个日期。实际上，这个日期是三个部门联合算出来的：库存有多少能发、采购的货什么时候到、仓库什么时候能出库。这三个数字，销售承诺时一个都没查。

这不是老李不负责。是他没有工具查——库存查询只显示总量，不显示多少是可发的、多少是采购在途的；采购在途数据在采购员手里，不跟销售共享；采购周期（从下采购单到货到仓库要多久）在采购员脑子里，没有系统记录。

于是销售承诺交期，靠两个东西：经验和运气。经验告诉他"这个产品一般 15 天能到"，运气决定"这次是不是一般"。运气好，承诺兑现了；运气差，第 14 天崩盘。问题不是销售不靠谱，是承诺环节缺了一层系统支持——承诺之前，需要有人把库存、在途、周期三组数据拉到一起算一遍。

核心判断

交期承诺失败，表面看是"库存数据不准"（参见前篇《库存不准，先崩的是销售》），实际是更深一层的问题：承诺环节没有"交期计算"这一步。库存准了只是基础；在库存数据之上，还需要一个机制——把库存、采购在途、采购周期拉到一起，算出"最早什么时候能发"。没有这一步，库存再准，承诺还是靠拍脑袋。

交期承诺的四个断点

从销售对客户说"15 天"到货发出去，中间有四个信息断点。每个断点都可能让承诺变成空头支票。

图 1：交期承诺的四个断点

断点一 · 库存：账面数 ≠ 可发数

销售查库存，系统显示 200 个。但 200 个里面，可能有 150 个是采购在途——采购单已下，供应商还没发货，系统里算作"库存"但实际不能发。销售看到的是账面库存，客户要的是可发库存，两个数字之间的差，就是采购在途的数量。这个断点与前篇《库存不准》一脉相承——库存数据本身的准确性是基础，但即使数据准确，"账面"和"可发"之间仍然隔着一道缝。

伤的是谁：对客户做了承诺的销售，和最终发不出货的仓库。

断点二 · 在途：采购的货什么时候到

采购单下了，供应商确认了，但什么时候发货、什么时候到仓库——这个信息在采购员手里，不跟销售共享。销售不知道在途的货今天到还是下周到，就无法判断"15 天"这个承诺能不能兑现。在途数据不透明，是交期承诺最大的盲区。

伤的是谁：承诺了交期却无法跟踪兑现进度的人——销售。

断点三 · 采购周期：从下单到到货要多久

库存不够，需要采购。从下采购单到货到仓库，要多久？这个周期决定了交期的下限。但采购周期没有系统记录——它散在采购员的脑子里，靠的是"这个供应商一般 7 天发货"的经验判断。经验没有数据校验，就不可能精确——供应商有时候 5 天发货，有时候 10 天，采购员取一个平均值告诉你"7 天"，但你这次可能恰好赶上了 10 天。

伤的是谁：基于错误的周期估算做承诺的销售，和被催到崩溃的采购。

断点四 · 跟踪：状态变了没人通知

承诺之后不是结束，是开始。物料状态在变化——供应商发货了、到仓库了、质检通过了、可以出库了——每一步变化都应该通知到销售。但大多数中小企业没有自动通知机制：采购员收到货不告诉销售，仓库入库不告诉销售，销售不知道自己的承诺能不能兑现，只能一个个去问。跟踪断点让承诺变成了盲盒——销售不敢主动联系客户，因为不知道该说好消息还是坏消息。

伤的是谁：在不确定中等待的销售，和等不到回音的客户。

三层根因：为什么交期总靠拍脑袋

道理不复杂——承诺之前查一下库存、问一下采购、算一下周期，谁都知道更靠谱。可为什么中小企业的交期承诺还是停留在"拍脑袋"上？原因分三层。

流程层 · 承诺无"交期计算"环节

中小企业的标准流程是：客户问交期→销售凭经验报一个→下单→等出货。整个流程里没有"交期计算"这一步——没有人把库存、在途、采购周期拉到一起算一遍。流程缺这一步，不是忘了加，是加了之后执行不动：库存数据不够准、在途数据不透明、采购周期没有记录——三个前提都不满足，"交期计算"就是空转。

数据层 · 三组数据散在三个部门

库存数据在仓库系统里，采购在途数据在采购员手里，采购周期在采购员脑子里。三个部门各有各的系统或记录方式，数据不互通。销售承诺交期时，需要跨三个部门拉数据——但在中小企业，跨部门拉数据的成本比"拍脑袋"高得多。不是不想查，是查的代价太高。

组织层 · 销售-采购-仓库各自为政

销售管接单，采购管买货，仓库管发货——三个部门各有各的 KPI，信息不共享是常态。销售不愿意提前告诉采购"可能要下单"（怕采购先安排了别的事），采购不愿意把供应商到货时间告诉销售（怕销售催），仓库不愿意把出库排期告诉销售（怕销售插单）。信息不共享不是技术问题，是部门博弈问题——每个人都在保护自己的节奏不被打乱。

组织博弈的真相

真实中小企业里，交期承诺停在"拍脑袋"上，不全是因为"没有系统"，还因为三个部门都不愿意把信息提前透明化。销售提前说"可能要下单"，采购觉得是给自己加活；采购提前说"供应商 10 天发货"，销售觉得太慢会丢单；仓库提前说出库排期，销售马上要插单。每个人都在保护自己的节奏，结果是全公司的节奏一起被打乱——承诺靠拍脑袋，兑现靠救火。系统能解决"能不能算"的问题，解决不了"愿不愿共享"的问题。

修复路径：从"凭感觉"到"有依据"

修复的方向，是在销售对客户承诺交期之前，加一步"交期计算"——把库存、采购在途、采购周期三组数据拉到一起，算出"最早什么时候能发"。超兔一体云的需交付与库存对比，就是这一步的系统实现。

图 2：交期计算的数据链路——三组数据汇成一个可承诺日期

需交付产品与库存数量对比表：系统按产品行展示需交付数量（A）、库存数量（B）、库存差值（C=B-A）、采购计划未执行（D）、已采购未入库（E）、需采购数量（F=A-B-D-E），红色为缺口、绿色为盈余，一眼看出"能发多少、差多少、在途多少"

第一步 · 需交付与库存对比：自动算缺口

系统从执行中的合同、订单中合计需交付数量，与库存、采购在途数量对比，自动算出"需要采购多少"。销售不用跨三个部门拉数据——系统已经算好了。这一步解决了"数据散在三个部门"的问题：不是让三个部门共享数据，是让系统自动汇总。

第二步 · 采购在途可视化

智能采购中心在计算采购量时，会考虑采购在途数量——已下采购单但还没到货的部分，自动从缺口中扣除。这意味着销售看到库存时，系统已经把"在途的货"和"能发的货"分开了。销售看到的不是"账面 200 个"，而是"可发 50 个，在途 150 个，在途预计 X 天到货"。

智能采购流程：系统自动匹配供应商、智能获取采购价，三种算法（最近采购、供应价最低、采购价最低）并列供选；人工只保留选择算法、与供应商确认修改两个动作，采购单自动拆分生成、全程自动（产品流程图）

第三步 · 供应商直发：省掉中间环节

有些场景不需要等货到自己的仓库再发。采购单支持供应商直发模式——供应商根据采购单直接发货给客户，省掉"到货入库再出库"的中间环节。采购直发必须关联在订单下，先有客户订单才有采购直发。客户签收后自动触发采购单完成和关联订单的发货单创建。供应商直发把交期从"采购到货+入库+出库"压缩到"供应商直接发货"，交期承诺的确定性大幅提升。

第四步 · 入库确认与多次入库

采购到货后，入库单必须经过库管人员审核确认——与实际收到货品对比确认后，方可完成入库。支持分多次入库——到多少入多少，不用等全量到齐。这意味着采购在途的货，部分到货就能部分可发，不用等全量到齐才出库。多次入库让交期承诺有了弹性——不是"全到才能发"，是"到多少发多少"。

代价与边界

这条路能走通，但不是免费的

前提 · 库存数据要准：需交付与库存对比的前提是库存数据可信——如果系统显示有 200 个，实际货架上只有 130 个（参见前篇《库存不准，先崩的是销售》），算出来的可发库存就是错的。交期计算的地基是库存准确性。

库存台账3.0：以仓库+产品为维度，自动核算期初、入库、出库、期末数据，支持积压天数、周转率等指标，保障库存数据准确性是交期计算的地基

代价 · 承诺从"快速回复"变成"需要核实"：有了交期计算，销售承诺交期时不再是"15 天没问题"一句话搞定，而是要先查系统、算缺口、看在途——回复速度变慢了。但慢出来的承诺是可靠的，快出来的承诺是盲盒。客户宁可等一个靠谱的答案，不要听一个不靠谱的承诺。

不适用 · 定制类与研发类项目：产品非标程度极高、一单一议、需要定制设计或研发的项目，采购周期不确定（供应商要看图纸排产），交期承诺靠的不是系统计算而是项目管理。这类项目需要 WBS 项目分解和甘特图管理，不在本篇"标准品交付"的讨论范围内。

回到现场

老李又接到客户电话，要150个产品，问15天能不能交。

这次老李没急着答。他打开超兔一体云的需交付与库存对比。系统列出这个产品的数据：需交付150个，库存50个，采购在途100个（预计7天到货）。系统自动算出：库存缺口100个，已由采购在途覆盖，无需追加采购。

老李看到了三个数字：50、100、150。50是能发的，100是在途的，150是客户要的。三个数字之间的关系一目了然——不需要打电话问仓库，不需要发微信问采购，不需要翻Excel算缺口。系统把三个部门的数据拉到一张表里，30秒算完。

最早可发日期：在途到货（7 天）+ 入库确认（1 天）= 8 天。

老李回客户："8 天能发。"不是 15 天——是 8 天，有依据的 8 天。

客户在那头说："这么快？"老李说："不是快，是准。"

第 7 天，采购在途的 100 个到货，库管确认入库。第 8 天，出库发出。承诺兑现了。不是靠运气，是靠数据。

老板打开系统，看到的不只是一张出库单，而是这张出库单背后的完整链路：库存 50 + 在途 100 = 可承诺 150；在途 7 天 + 入库 1 天 = 最早 8 天可发。交期第一次有了计算痕迹，不是拍脑袋的痕迹。

超兔一体云 · 技术和场景系列 · 前篇为《采购比价：传统方法翻一上午，CRM里3分钟跑完》

参考资料

超兔CRM产品说明书《需交付与库存对比》：从需交付与库存对比表出发做智能采购，需交付数量由执行中的合同、订单合计得出，与库存、采购在途对比得出需采购数量

超兔CRM产品说明书《智能采购中心》：集成三种驱动方式，核心能力包括智能计算采购量（考虑采购在途数量）、智能匹配供应商、智能合并和拆分采购单

超兔CRM产品说明书《采购单直发（供应商直发）》：供应商根据采购单直接发货给客户，省略发货给我方的环节；采购直发必须关联在订单下；客户签收后自动触发采购单完成和关联订单发货单创建

超兔CRM产品说明书《采购单入库》：采购单由采购人员填写，入库单由采购人员生成，入库单必须经过库管人员审核确认后方可完成入库

超兔CRM产品说明书《采购单多次入库》：采购单生成入库单后，库管可修改入库单产品和数量，根据实际到货情况分多次入库

超兔CRM产品说明书《WBS项目甘特图管理》：WBS项目分解结构，甘特图可视化，任务依赖管理，进度跟踪，AI辅助生成WBS模板