2. 工单全生命周期建模

工单是生产追溯的最小业务单元，也是车间现场与管理系统之间的数据契约。一张工单从创建到归档，会经历多个状态迁移，每个状态对应不同的责任主体、可执行操作和必须记录的数据。如果状态定义模糊、字段缺失或规则冲突，追溯链就会在某个环节断裂——比如报工数量与完工数量对不上，或者质检结果无法关联到具体批次。本节围绕状态机、数据字段和业务规则三个维度，说明如何把工单全生命周期建模成可执行、可追溯、可校验的结构。

一、状态机：定义工单的合法迁移路径

工单状态机不是简单的状态列表，而是一组带条件的迁移规则。常见的核心状态包括：已创建（Created）、已派工（Dispatched）、已开工（Started）、报工中（Reporting）、待质检（PendingInspection）、质检中（Inspecting）、已完工（Completed）、已归档（Archived），以及异常分支已暂停（Paused）和已取消（Cancelled）。

迁移必须满足前置条件。例如，从“已派工”到“已开工”，要求操作人属于被派工班组、设备处于可用状态、且工单未被暂停；从“报工中”到“待质检”，要求累计报工数量达到工单计划数量，或操作人主动提交质检申请。反向迁移同样需要约束：已归档工单不允许回退到报工中，已完工工单若需返工，应生成返工子工单而不是直接改状态。

状态机设计的关键在于“单一入口、单一出口”。每个状态只允许通过明确的触发事件进入，触发事件必须记录操作人、时间戳和来源终端。这样，当追溯时发现某张工单在“已开工”停留了异常长的时间，就能定位到是设备故障、人员缺勤还是数据未及时上报。

二、数据字段：每个状态必须携带的最小数据集

工单数据字段分为三类：标识字段、业务字段和追溯字段。标识字段包括工单号、产品编码、批次号、计划数量、优先级；业务字段包括派工班组、设备编号、操作人、报工数量、合格数量、不良数量、工时；追溯字段包括创建时间、派工时间、开工时间、报工时间、质检时间、完工时间、归档时间，以及每个状态变更的操作人和终端标识。

字段设计要遵循“状态驱动”原则：不同状态下必填字段不同。例如，创建时必须有产品编码和计划数量；派工时必须补充班组和设备；开工时必须记录实际开始时间和操作人；报工时必须填写本次报工数量和累计数量；质检时必须录入检验结果和不良原因代码；完工时必须确认合格数量与计划数量的差异；归档时必须锁定所有字段并记录归档人。

一个常见的错误是把所有字段都设为可选，导致追溯时发现关键时间点缺失。建议在数据库层面用状态约束字段必填性，例如用检查约束（CHECK）或应用层校验，确保“已开工”状态的工单一定有开工时间，“已完工”状态的工单一定有合格数量。

三、业务规则：让状态迁移可校验、可审计

业务规则是状态机的“交通法规”。以下列举几条典型规则及其实现方式：

• 数量守恒规则：累计报工数量 ≤ 计划数量 + 允许超产比例。若超产比例设为5%，计划1000件，则累计报工不得超过1050件。超出时系统应拒绝报工并提示“超出允许超产上限”。
• 时间顺序规则：开工时间 ≥ 派工时间 ≥ 创建时间；完工时间 ≥ 质检时间 ≥ 报工时间。任何时间倒挂都应触发告警并阻止状态迁移。
• 质检前置规则：只有累计报工数量达到计划数量的90%以上，才允许提交质检申请。这避免半成品未完成就进入质检环节。
• 归档锁定规则：工单进入“已归档”后，所有业务字段变为只读，任何修改必须通过“归档更正”流程生成变更记录，保留原值和新值。
• 暂停恢复规则：暂停时必须填写暂停原因代码（如设备故障、缺料、计划变更），恢复时需记录恢复时间和恢复人，暂停时长自动计入工单总周期。

这些规则最好以配置表或规则引擎的形式管理，而不是硬编码在代码里。例如，用一张“状态迁移规则表”记录：当前状态、目标状态、触发事件、前置条件表达式、后置动作。这样当业务调整时，只需修改配置，不必重新部署。

四、建模落地：从状态机到可执行的数据结构

把上述设计落地时，建议采用“工单主表 + 状态迁移日志表 + 报工明细表 + 质检记录表”的结构。主表存储当前状态和关键汇总字段；迁移日志表记录每一次状态变更的事件、操作人、时间戳和前置条件快照；报工明细表按次记录报工数量、工时和操作人；质检记录表存储检验结果、不良数和原因代码。

这样设计的好处是：主表查询快，日志表可审计，明细表可追溯。当需要回答“这批产品是谁在什么时间报工的”或“质检时不良集中在哪个时间段”时，可以通过关联查询快速定位。同时，状态迁移日志表本身就是追溯链的骨架，任何一次状态跳变都有据可查。

最后需要强调的是，工单全生命周期建模不是一次性设计，而是随着业务变化持续迭代的过程。建议每季度回顾一次状态迁移规则和字段必填性，清理不再使用的状态，补充新出现的异常分支，确保模型始终与现场实际一致。