B2B销售系统如何拆线索-客户-合同-定金-采购-交付？

结论：不要把线索、客户、合同、定金、采购、交付做成一张不断加字段的大单。应拆成三条关联主线：客户—商机—报价—合同负责销售承诺；销售订单—采购或生产—出库—物流—验收负责履约；应收计划—到账—核销—开票负责资金。三条线用客户、合同、订单和履约批次的稳定编号关联，任何一条都允许部分完成、变更和回退。

原问题把定金放在销售、采购放在交付是一个起点，但真实 B2B 业务往往不是一笔定金对应一次采购，也不是签完合同就完整发货。一个框架合同可能产生多张订单，一张订单可拆多批交付，客户一次付款可能核销多张应收，采购还可能服务多个销售订单。系统若只用“当前状态”串成一条直线，部分付款和缺货就会把流程卡死。

业务对象	它应记录什么	与下一环节的关系	不应混入的内容
线索与客户	来源、主体、联系人、归属和信用信息	合格线索转客户或关联已有客户	报价版本和收款事实
商机与报价	需求、预计金额、概率、产品和报价版本	获批报价形成合同谈判依据	把预计收入当已签合同
合同与变更	主体、标的、价格、付款、交付、税务条款	生成一张或多张销售订单和应收计划	用覆盖原合同的方式改约定
销售订单与履约批次	实际数量、交期、仓库、批次与验收	驱动采购、生产、出库和物流	把采购到货当客户已验收
应收、收款与核销	应收节点、实际流水、核销和余额	满足条件后释放备货或发货	用付款截图替代银行到账
采购与供应	供应商、采购单、到货、质检和成本	为一个或多个履约批次提供库存	让客户合同直接等同采购单

在继续拆分功能、数据与验收场景时，还可以对照 订单流程系统如何设计内勤审核-到款确认-发货闭环？ 和 培训机构做招生和学员管理系统，应该重点关注哪些功能？；这些内容补充了需要放在同一项决策中考虑的上下文。

合同是承诺边界，不是所有数据的容器

客户主体、开票主体和收货主体可能不同，合同必须冻结签署时的关键交易条件，并保留附件和审批版本。合同变更通过补充协议或变更单形成新版本，说明影响的订单、应收和交付；不能直接修改历史字段。框架合同、单次合同和采购订单式成交要先分类，因为它们生成销售订单的时点不同。

报价支持版本、有效期、币种、税率、折扣和审批。商机关闭失败也应记录原因，避免漏斗只剩成功样本。线索合并时保留来源归因，客户档案以经过核验的企业主体为中心，同一联系人可关联多个角色，但个人联系方式按必要范围授权访问。

到账、采购和交付各自拥有事实

应收计划来自合同付款条款，银行流水或受信支付渠道才形成收款事实，财务人员再核销到一项或多项应收。是否“定金到账才能采购”应做成合同或产品策略，而非系统硬编码；有些业务允许授信生产，有些必须全款后发货。截图、销售备注或预计到账不能自动解锁高风险动作。

销售订单经过可用量检查后，决定使用现货、生产还是采购。缺货可拆需求，多个需求可汇总采购，但系统保留来源分配。到货、质检、入库、出库、承运和客户验收是不同事件；部分到货和拒收产生剩余数量与异常单，而不是把整单退回起点。尾款、开票、质保和售后按合同条件触发，并可从任一事件反查原承诺。

权限应跟职责和金额走：销售维护客户和商机，商务或法务审批合同，采购选择供应商，仓库确认实物，财务认定到账和开票。任何人不能凭一个超级账号同时改合同、确认到账和放行出库。价格、付款条件、客户银行信息和导出行为进入审计日志，离职或岗位变化及时回收权限。

验收时用真实复杂单据，不只跑“全款现货一次发完”。至少覆盖框架合同多订单、报价改版、定金不足、一次收款核销多项、部分采购、分批出库、换承运商、客户拒收、补发、合同变更和退款。对账应满足订单数量＝已交＋在途＋待交＋取消的可解释平衡，应收＝已核销＋未核销＋调整，所有差额可追到业务凭证。经营指标再从这些事实计算销售周期、赢单率、按期交付率、应收账龄和采购满足率，口径写入数据字典。

滚水科技会先拿客户最近一段时间的代表性合同、报价、收款、采购和交付单据做“对象—状态—凭证”映射，再决定复用 CRM、ERP 还是建设中间业务系统。如果标准 CRM 与 ERP 已能覆盖两端，优先做主数据和单据同步；只有跨部门规则和追溯无法配置时才定制，不会为了做一套大后台替换全部成熟系统。

参考资料：

• OASIS Universal Business Language 2.4：用于参考订单、发运、收货和发票等商业文档的数据结构与关联方式。
• OMG BPMN 2.0.2 规范：用于参考跨角色业务流程、事件和异常路径的建模方法。
• 滚水科技工厂管理数字化案例：用于了解滚水科技公开展示的企业流程项目经验，不代表本项目适用相同模型。