面向场景离散制造企业多品种、小批量。接到销售订单后车间要开生产工单。本文不讲要不要转只讲系统怎么设计——包括为什么不该写死代码、数量反写怎么防重复、以及一个几乎所有 ERP 都会踩的 BOM 版本问题。一、问题手工开单的三重损耗先说清楚为什么需要「转」这个动作。销售订单和生产工单是两张不同的单前者面向客户我要什么、什么时候要、多少钱后者面向车间做什么、做多少、用什么料、走哪条产线。字段不同、粒度不同、责任人不同。如果全靠人手工开一张生产工单会有三重损耗损耗具体表现重复录入品名、规格、数量、交期要从订单里再抄一遍抄错是常态漏单订单多了之后哪张开了工单、哪张没开靠人记月底才发现漏了一单不一致订单改了数量客户加量工单没跟着改车间按旧数生产第三条最隐蔽。订单和工单一旦脱钩两张单就各说各话等到出货时才发现数量对不上。所以「转」这个动作的本质不是省打字而是建立一条可追溯的链路这张工单是哪张订单来的、转了多少、还差多少没转。二、三种触发方式我们只选其中两种做这个功能时第一个决策是「什么时候触发转单」。方式说明优点缺点我们的选择手工点按在订单界面点「生成工单」按钮可控、可抽查、可部分转依赖人的主动性✅ 默认方式审核后自动订单审核通过即自动生成工单不会漏单无法干预、异常订单也会转✅ 可选开关定时批量每天定时把未转订单批量转适合大批量时效差、出错影响面大❌ 不做为什么不做全自动制造业的销售订单并不都能直接投产。常见情况有客户还没付定金 / 信用额度不足业务上不该排产定制品还需要技术部门确认图纸交期在三个月后现在排产会占库存如果系统审核通过就无条件转工单生产部门会被塞满不该做的单。所以默认给手工触发把「自动」做成一个可选开关——这个开关本身就是不同企业管理成熟度的体现。这是个通用经验凡是「自动执行会产生物理后果」的动作排产、发料、扣账默认值应该是人工触发自动化作为可选项逐步开放。三、核心设计配置化映射而不是写死代码这是整篇文章最想说的一点。最常见的错误做法为新客户写一段代码——「把销售订单的 A 字段拷到工单的 B 字段」——然后第二个客户映射不一样再写一段。代码库里很快堆满if 客户A then ... elseif 客户B then ...。正确做法把映射关系做成配置。3.1 三层映射我们的单据结构分三层映射也必须分层对应对应到数据负载的三个键与桌面端保持一致层级负载键名映射内容表头FHeadTableData客户、交期、业务员、备注明细FEntryTableData产品、数量、单位子明细SubEntryTableData批次、序列号3.2 映射的三要素每条映射规则只需三个信息要素说明示例源字段从来源单据取哪个字段销售订单.数量目标字段写入目标单据哪个字段生产工单.计划产量转换规则如何取值直接取值 / 常量 / 计算 / 查表用配置表表达示意3.3 「来源单据类型 → 目标单据类型」本身就是一组配置配置化的价值在于一次开发多处复用。同一套机制可以支撑多种转换来源单据目标单据场景销售订单生产工单接单排产销售订单采购订单贸易型企业直接外购转销生产工单委外加工单工序外协采购订单入库单到货收货在界面上用户只需要选「来源类型」和「目标类型」两个下拉框系统按配置自动带出字段映射——不需要为每种组合单独开发一个按钮。这一条对交付效率的影响极大新增一种单据转换从一个开发任务变成一条配置。四、数量反写防重复转单的关键接下来是技术上的核心难点也是最多人做错的地方。4.1 问题同一张订单被转了两次销售订单 100 件生产部门转了工单。第二天业务员又点了一次「生成工单」——如果系统不做防重车间就多做 100 件。靠前端把按钮置灰是不可靠的刷新页面就复原多人同时操作也拦不住。必须在数据层面解决。4.2 做法在订单明细上记「已转数量」给来源单据的明细行增加两个字段转单时的逻辑关键点第 3 步的校验和第 5 步的反写必须在同一个事务里。否则两个并发请求可能都通过了校验然后各自反写结果「已转数量」变成 200而订单只有 100 件。实现上我们用的是「带版本号的乐观锁」而不是把整张表锁住为什么用乐观锁而不是悲观锁这个场景的并发冲突其实很低同一张订单被两人同时转单很少见但一旦发生后果严重。乐观锁在无冲突时几乎没有性能开销只在真正冲突时才回滚重试——比长期持有行锁更划算。更简单的方案是在UPDATE的WHERE里直接加上限条件AND converted_qty thisQty qty。这样连版本号都省了校验与更新一步完成天然原子。 但在需要「超转要给出具体原因」的场景下两步法更好定位问题。两种都能用选你能维护的那种。4.3 支持部分转单用「已转数量」而不是一个「已转」标记好处是天然支持部分转单场景处理订单 100 件分两批投产第一次转 60第二次转 40转完自动变为「已转完」订单 100 件先转 30 件试产剩余 70 件随时可再转客户中途加量到 150 件已转 60剩余 90 可转如果只用布尔标记这些场景全都做不了——「标记位」看起来简单但它把业务锁死在全转或全不转两种可能里。4.4 反查与追溯反写完成后两条链路都通了这就是第一节说的「可追溯链路」。有了它才能回答业务上最常问的几句话这张订单有多少还没排产这张工单是给哪个客户的本月已排产但未完工的有多少五、三个坑坑 1子明细批次、序列号在转换中丢失现象转单后表头和明细都对但子明细是空的。原因三层结构里子明细最容易在转换时被漏掉——因为很多实现只处理了两层表头 明细或者明细层的映射写完了就以为完事了。处理映射配置必须显式覆盖三层并且在转单后做一次校验——如果来源有子明细而目标没有要报警而不是静默通过。一般性的教训多层级数据结构在转换时少了最后一层这种错误不会报错、只会表现为数据缺失必须靠显式校验发现。坑 2单位换算现象销售单位是「箱」生产单位是「个」转单后车间拿到 10 个——实际应该是 1000 个。根因销售和生产的计量单位经常不一致。销售按包装单位卖生产按最小单位做。处理映射规则里必须有「查表」这一类转换即从产品档案里取单位换算率而不是假设两边单位相同。这类错误特别危险数量级错了 100 倍但界面上就是显示一个数字看起来完全正常。建议在转单结果页显式展示「销售单位数量 → 生产单位数量」的换算过程让人有机会发现不对。坑 3BOM 用哪个版本——制造业的经典难题这个坑最深也最容易被忽略。现象转单时生成用料需求用的是产品当前的 BOM。但一张订单是三个月前下的那时 BOM 是 V2现在已经是 V3 了。问题的实质BOM 有版本销售订单有下单时点生产工单有生产时点两者之间 BOM 可能已经变更。用哪个版本三种策略各有道理策略说明适用场景用下单时的 BOM报价时的成本基础保证报价与生产一致按订单报价、成本敏感的定制产品用生产时的 BOM默认用最新工艺避免按过期工艺生产标准品、工艺持续改进的场景转单时人工确认提示「BOM 已变更是否采用最新版」变更频繁且影响大的产品我们的做法是默认用最新版但在 BOM 发生过变更时给出显式提示让生产计划人员自己决定。理由是系统不该替人做这种判断但必须让人知道这里有判断要做。如果系统静默用了某个版本出问题后根本无从追溯——这才是最糟的。建议无论选哪种策略工单上都要记录生成时使用的 BOM 版本号。这一条在事后追责和成本分析时价值巨大。六、边界不是所有产品都需要转工单必须说清楚避免过度设计。场景是否需要转工单多品种小批量、按单生产✅ 必须这是本文场景标准品备库生产按预测排产⚠️ 一般由主生产计划驱动不直接从销售订单转纯贸易采购转销❌ 不需要转的是采购订单定制项目型单件、长周期⚠️ 更可能转「项目任务」而非工单如果企业没有生产环节这个功能一行都不该开发。我们把它做成配置而不是写死流程一部分原因就是同一个 ERP 交付给不同客户时需要启用哪几种转换关系是不同的。七、效果跑通之后实际改善主要在三点环节之前之后开单手工重录一遍表头与明细一键带出人只做确认防漏单靠人记哪张转过订单列表直接显示「未转数量」变更同步订单改了工单不知道剩余可转量实时反映追溯两张单靠人脑关联双向可查订单↔工单新增转换类型写代码加一条配置最实际的价值是最后一行把「单据转换」从一个需要开发的定制需求变成了一个实施阶段就能配好的工作。对没有专职 IT 的企业来说这决定了系统能不能被长期用下去。关键词销售订单转生产工单、ERP工单管理、生产排产、单据转换配置化、数量反写、BOM版本管理、离散制造ERP、生产工单管理软件、订单转工单防重复、ERP实施