销售接单前,交期到底能不能答应

客户问月底能不能交,销售需要先问清楚这个日期指工厂发货还是客户收货。随后还要核对数量、物料、已经占用的产能和原有订单。排程给出候选日期以后,企业授权人才决定怎样答复客户。

订单要求经过物料、产能与工序核对后形成候选可行日的示意图

先分清客户要求日、候选可行日和授权承诺日

客户说月底交货,可能指月底从工厂发出,也可能指月底送到客户仓库。两种说法中间还隔着包装、仓库处理和运输。接单评审先要写清产品、数量、发货或到货节点、地点、时区、是否允许分批,以及客户能够接受的日期范围。

Microsoft、SAP 和 Oracle 的官方文档都把客户要求日期与计算或确认后的日期分开。各家字段名称不同,常见写法包括 requested、expected、scheduled、confirmed 和 promised。它们不能全部翻成一个交期,更不能因为订单里已经填了日期,就认定企业已经对客户作出承诺。

本文把日期分成三层。客户要求日记录客户希望什么时间完成哪个节点,候选可行日记录当前资料和规则算出的结果,已授权承诺日记录企业最终同意向客户承担的日期和数量。每一次答复都要说明使用的是发货日还是到货日。

先判断这张订单需要查到多深

固定销售提前期可以帮助销售做第一轮筛选。Microsoft 的文档同时说明,这种算法依据预设天数推算日期,并不检查库存可用量、已知需求或计划供应。受物料或产能约束的制造订单,还需要继续往下查。

ATP 和 CTP 适合解释两种不同深度。Microsoft 的 ATP 会查看未承诺库存、计划收货和已有需求,并假设资源产能无限;它的 CTP 进一步查看材料与生产能力。SAP 文档以 Supply Creation-Based Confirmation(SBC)说明供应创建型确认,Oracle Global Order Promising 则有自己的订单承诺规则。三者的名称、配置和算法不能直接互换。

对备货品,现有和计划供应可能已经足够支持一次可用性判断。对按单生产或需要补产的订单,团队还要检查 BOM 组件、工艺路线、有限资源和运输时间。ATP 与 CTP 在这里是行业概念,不代表凯沃普当前已经提供独立的 ATP 或 CTP 引擎。

物料判断要带着数据时点

物料检查需要把可用库存、已经预留的数量、计划收货、采购与在途、现有订单需求,以及关键组件最早可用时间放在一起。账面库存只说明系统记录了多少,不能单独说明这些数量都能留给眼前的新订单。

SAP 的可用量检查会考虑当前与计划供应以及并发订单。Oracle 的订单承诺也依赖已经收集或实时提供的供需数据和规则。它们共同说明,任何物料结论都要注明数据截止时间、检查范围和供应状态。一个昨天导出的文件,不能自动代表今天仍然可用。

替代物料、供应提前和临时调拨可以作为候选条件,前提是对应数据真实,而且工程、质量、采购或客户已经授权。资料没有确认时,应把短缺和待核条件留下来,不能把建议写成已经存在的供应。

有限产能要和已有订单一起计算

需要新生产时,工艺路线、标准工时、资源日历、已经占用的负荷、班次和停机会改变候选日期。Microsoft 的有限产能文档说明,只有在计划与相关资源上启用有限产能,系统才会考虑已经预留的能力。能力不足时,日期可能后移。

新订单不能单独寻找一个理论空档。它会和已有订单争用同一批物料、机台和时间。评审应把新需求放进同一计划范围,查看哪些原订单变晚或变早,哪些资源和供应关系发生变化,以及哪些已经发布或开工的任务需要例外处理。

有限产能结果只覆盖已经建模并进入本次计算的约束。人员、模具、工具、维护、换型或外协没有写进资料时,系统不会凭空知道。候选日期旁边要保留未建模条件,让计划员判断它们会不会改变结果。

从生产可行日走到客户收货日

组件齐套以后,订单还要经过生产、检验、后处理、包装和仓库放行。随后才是提货、运输和客户收货。Microsoft 的日历文档说明,供应商、仓库、运输方式和客户收货日历都会影响计划日期。Oracle 也分别记录预计发货与预计到货节点。

因此,排程中的预计完工日不能直接当成客户到货日。企业需要从这一天继续加上真实的后处理和物流时间,并检查相关日历是否开放。客户要求指定船期或港口节点时,还要单独确认订舱、截关和海运条件。

凯沃普当前文章讨论的是生产侧交期判断。海运出货属于同一条长期方向,现阶段不能把生产排程结果写成已经自动计算完成的船期或客户收货承诺。

给销售准备可以解释的候选答复

接单评审通常会形成几种基础答复。当前请求可以满足,就按请求节点和数量确认。客户允许拆批时,可以列出每批数量和日期。完整数量需要稍后完成时,可以提出整单候选日。关键资料或授权仍缺失时,先保留为暂不承诺。

每个候选版本都要使用同一数据截止时间,并写明假设。加班、外协、替代资源、替代料、拆批和更换运输方式只有在资料与授权存在时才能进入方案。系统能够算出一种可能性,不等于企业已经决定采用它。

候选表至少列出请求日期、候选发货或到货日、可承诺数量、关键物料、受约束资源、受影响原订单、需要突破的近期计划,以及仍未解决的风险。销售看到这张表,才能知道日期从哪里来,也知道哪一项条件改变后需要回来重查。

计算完成以后,还要明确谁能答复客户

官方产品允许把日期计算和订单确认分开管理。Microsoft 提供显式的销售订单确认操作。SAP 部分流程允许用户查看、调整并应用可用性结果。Oracle 则把 promised date 解释为企业与客户约定的日期。这些是不同产品的工作方式,不代表所有系统都强制同一种人工审批。

凯沃普当前生成可比较的候选排程,并说明预计完工时间、交期风险、瓶颈和对已有订单的影响。计划员或企业授权人核对输入与取舍以后,再由有权作出客户承诺的人确认日期。系统提供判断依据,不替企业接受或拒绝订单。

一次完整确认要留下采用版本、承诺节点、日期、数量、授权人和确认时间。若客户接受的是拆批或更晚日期,也要保存对应沟通记录。候选排程、内部批准和客户答复之间有记录,后续变化才有地方可查。

数量和约束变化以后,旧日期要重新检查

订单数量、生产地点、物料、提前期、预留、日历或供应日期变化以后,原候选日期可能已经过期。Microsoft 的标准 CTP 和 Batch CTP 在重算时点与状态上就有差别。Oracle 也记录了 Override Schedule 属性可能使后续数量或请求日期变化不触发重新排程。页面上仍然显示一个日期,不能证明它仍然有效。

企业应提前定义重查触发器。哪些字段变化会清除旧结论,谁负责发起复核,原承诺与新候选相差多少时需要升级,客户和现场分别由谁通知。更早的候选日期也要检查,因为客户可能有最早可收货时间,生产和物流也可能因此增加新的安排。

凯沃普第一轮可以用同一数据截止时点的一组脱敏订单做只读评审,比较当前排法与候选方案。第一轮不自动写回生产系统,也不能证明实时库存、自动承诺或 ERP 与 CRM 双向同步已经完成。先把日期依据、影响和人工确认跑清楚,再决定下一步怎样接入。

参考资料

本文依据以下官方资料说明客户要求日期、可用量检查、有限产能、日期日历、订单确认和变更复核。各产品术语与配置不同,凯沃普当前范围以本站公开的只读排程验证说明为准。

  1. Microsoft Learn 订单承诺
  2. Microsoft Learn 使用 CTP 计算销售订单交期
  3. Microsoft Learn 有限产能计划与排程
  4. Microsoft Learn 主计划概览
  5. Microsoft Learn 日历与主计划
  6. Microsoft Learn 确认销售订单
  7. SAP 高级可承诺量
  8. SAP PP/DS 供应创建型确认
  9. SAP 复核可用性检查结果
  10. SAP 计划时界
  11. Oracle 全球订单承诺概览
  12. Oracle 查看可用性日期
  13. Oracle 设置承诺发货与到货日期
  14. Siemens Opcenter 可制造承诺能力

拿一组真实订单,把客户要求日和生产候选日放在一起核对。

使用同一时点的脱敏订单、工艺、资源与物料资料,先做只读交期评审,再由企业授权人决定对外答复哪个日期。 样本结论不能直接外推到全厂。接单协同与海运出货是凯沃普围绕同一张订单逐步衔接的长期方向,不是已经上线的完整产品链路。文件或快照接入不证明实时同步、双向集成、冲突处理或生产系统写回已经完成。当前公开材料不证明凯沃普已经实现完整的库存、预留、供应、需求、短缺与替代料可用性逻辑。

预约一轮交期评审