FDE 实战（三）：把业务规则落成状态、追溯与协作

制造业系统最难的部分，通常不是表单，而是状态。状态没定义清楚，后面的库存、成本和报表就会一起漂。

同一批物料可能处于待检、合格、锁定或不合格；同一张订单可能经历待确认、生产中、部分发货和已结案；同一份配方还可能有历史版本。看起来只是几种标记，实际决定了谁能继续往下走。

状态先于页面

在项目里，我们把跨模块的关键状态当成一等设计对象：

• 采购合同：草稿 → 待审 → 已确认 → 可入库

• 物料批次：待检 → 合格 / 不合格

• 生产批次：待排产 → 生产中 → 已完成

• 销售订单：待确认 → 已确认 → 生产中 → 部分发货 / 已发货

每一次转换都要回答：谁触发、需要什么前置条件、会更新哪些关联数据、要不要通知别人、能否撤回。

例如，采购合同审核通过不仅改变合同状态，还决定仓库能否入库；入库又会生成待取样记录；检测结果改变后，库存的可用量和生产占用也要同步回算。页面上的一个按钮，背后可能是多个领域对象的一致性问题。

库存不是一个数字

项目早期的讨论里，仓库最关心的是“系统里的数量能不能和实物对上”。质量和生产则会继续追问：这批货是否合格、是否已被排产锁定、是否因为取样而减少。

因此，库存模型至少要区分数量和可用性。物料入库后自动进入待检状态，取样会留下独立记录，检验通过才转为正常可用；排产会冻结预计用量，取消排产则释放；不合格品通过专门的出库和销毁流程处理。这样，系统才能解释“总库存还有多少”和“现在能用多少”为什么不同。

成品也一样。生产实际产量、质量取样和销售取样不能简单相加成一个可发货数量。每一部分都要有来源和去向，财务、仓库、质量才能在同一条批次记录上对账。

追溯是业务能力，不是日志装饰

配方版本、物料批号、生产批次、领料记录和发货记录被设计成一条可追溯链。生产批次需要知道当时使用的配方，领料需要关联具体物料批号，成品出库需要落到库存批次，对账则要把实际发货重新匹配到订单。

这种设计也暴露了一个现实：一个生产批次可以服务多张订单，一个订单也可能分多次发货。系统不能只靠“当前订单号”字段解决，而需要保存批次、订单和出库明细之间的关系，在对账时按约定顺序分配数量，并允许人工复核边界情况。

电子化不等于取消现场动作

• 管理者更愿意在手机上比较历史采购价格并完成审批。

• 仓库希望根据采购合同自动带出待入库物料，只补实际到货数量。

• 车间需要在平板上录入产量和工时，单据仍要打印并保留签字区域。

• 物料和单据最好能通过条码快速定位，减少手写批号的错误。

所以我们把页面、移动端、打印模板、通知和扫码看成同一条流程的不同入口。只要数据模型一致，现场可以选择最顺手的入口；系统则负责保持状态、权限和追溯一致。

让状态驱动协作

在常规流程中，质量结果决定库存是否可用，库存状态又决定生产和发货能否继续。系统把这些前置条件写清楚后，仓库、质量、生产和销售可以围绕同一条记录协作，不需要反复通过口头确认状态。

这类设计既保留了各部门的职责边界，也让每一步都有明确的责任人和可追溯记录。

从首版到持续收敛

首版演示后的工程工作，集中在边界而不是装饰：检验报告按类型区分，检验结果变化时重新计算批次状态，盘点记录增加撤回和删除保护，审批待办补齐跳转信息，库存预警统一统计口径，历史数据迁移补上配方版本和生产批次关联。

这些工作有一个共同点：它们都在维护“同一个事实只能有一个解释”。当质量状态变化，库存、通知和出库权限必须跟着变化；当编码或合同号修正，关联记录也必须同步；当账号离职，审批链不能继续依赖旧账号。

FDE 的工程判断

在复杂企业项目里，FDE 需要同时接受两件事：业务不会在第一次访谈时完整表达自己，真实边界一定会在演示和使用中出现；不是所有现场习惯都应该被自动化，系统要把关键事实和风险控制下来，把仍然需要判断的部分明确交给人，并留下可追溯的记录。

最终交付的标准，不是页面数量，也不是需求文档的页数，而是业务人员能否用一条真实流程验证：数据从哪里来、现在处于什么状态、下一步由谁负责、出了问题能不能追溯。