检验不合格后，返工返修工单怎么进入MES？

返工这两个字，听起来像把有问题的货拿回去再做一遍。真到系统建设时，事情没那么简单。

检验结果可能记在质量模块，生产任务在MES，库存又可能记在ERP或WMS。哪批东西不能继续流转、谁决定怎么处理、返完以后凭什么放行，这几件事要是没接上，系统就只能记录“发生过不合格”，回答不了“后来怎么样了”。

所以，先别急着找MES里的“新建返工单”按钮。我们把这条业务从检验结果开始，顺着往后捋一遍。

检验判了不合格，不等于已经决定返工

检验员发现问题，首先得把问题落到具体对象上：哪张生产工单、哪道工序、哪批或哪几件产品、涉及多少件、依据哪版检验要求判定。只写一句“尺寸不合格”，下一位接手的人很难知道该拦住谁。

接着还要分清，产品现在在哪儿。仍在工序间的在制品，重点是别让受影响的部分继续往下做；已经完工入库的成品，则要看能否先从可用库存里隔离出来。检验不合格是一个结果，暂停流转或隔离库存是后续动作，不能因为页面显示红色，就默认实物也被管住了。

然后才轮到处置决定。需要复核的先复核；能返工的，确定返工方法和复检要求；不能返工的，按企业规则走报废或其他批准的处置。

现场有时把“返工”“返修”混着说，但两者要解决的问题并不完全相同。返工是把产品重新做到原来的要求；返修则可能是修到预定用途下可以接受，未必完全符合原要求。后者尤其要写清批准条件和放行依据，必要时还要按合同或行业要求取得客户同意。系统不能只留一个“处理完成”，让两种结果走同一条放行规则。

质量、工艺和生产各自负责什么，也得定下来。MES可以提醒、流转和记录，但不能凭一个“不合格”标记，就把整批货自动派去返工。处置决定明确后，系统才有依据把它变成车间能执行、事后能追查的任务。

返工任务得认得原来的工单

返工单如果只写“产品A，返工4件”，车间也许能开工，后面却很难对账：这4件原本属于哪张工单？哪次检验发现的问题？返工用了什么料，做完又回到哪一步？

所以至少要把原工单、工序或批次、不合格记录、待处理数量和返工任务关联起来。需要按件追溯的产品，还要认到序列号。若处置决定是返修，执行任务里还应带上获批的修理方案和专门的验收条件。后来多用了物料、发生报废或增加了工时，也应记在这次处理上，不能混进正常生产记录里找不回来。

具体怎么进MES，要看问题出现在哪个阶段。

如果产品还在生产途中，系统可以在原工单下安排返工工序或补做任务，让这批在制品处理完再回到后续工序。若产品已经完工入库，返工需要重新领用、报工和单独核算，就可能要开一张关联原工单和原批次的返工生产订单。两种做法不必硬选一个当标准答案，关键是原来的生产履历不能丢，返工也不能被算成凭空多生产了一批货。

这类关系用低代码搭建时，不是加一张“返工申请表”就结束了。以织信为例，数据表可以关联工单、检验记录与返工任务，工作流可以承接评审和批准，权限能限定谁作出处置决定。表单是入口，原单关系和状态变化才是这件事的骨架。

返完了，还要把数量算对

拿一批100件、全部检验的产品举个简单例子：94件首次合格，6件不合格。质量评审后，4件返工，2件报废；4件返工品再次检验，全部合格。

最后可放行的数量是94加4，等于98件，不是100件，也不是把返工报工的4件再加到原来的100件上，算出104件。原工单的产出、首次合格数、返工投入数、复检合格数和报废数，说的是不同事情。系统如果只留一个“完成数量”，迟早有人要拿Excel重算。

同一批里的94件、4件和2件，也不能一直共用一个笼统的“批次状态”。至少要能按处置数量或件号分别追踪：哪些已经放行，哪些还在返工，哪些已经报废。否则一锁就锁住整批，一放又可能把不该放的货放出去。

复检这一步也不能省。执行人员报了“已完成”，只能说明处理动作做完；能否转入下一工序或可用库存，还得看适用的验收条件、复检和放行结果。若复检仍不合格，这几件就继续留在待处理状态，不能因为任务关闭了，库存也跟着自动变成可用。

至于补料、工时和报废成本记到哪里，要跟企业现有的成本核算口径对齐。MES可以留执行明细，ERP再按约定接收和核算；若企业已有其他成本管理方式，也应先确认主账在哪里。别让两个系统各自算出一份“返工成本”，月底再争哪份是真的。

已有MES和ERP，低代码该补哪一段？

先看看现有MES能不能把不合格记录、处置决定、返工执行和复检接起来。如果它已经能做，规则也能配置，先把现有功能用好。为了展示“系统统一”，再建一套同名返工流程，反而会出现两边都能改状态、谁都说不清以谁为准的问题。

真正需要补的，可能只是跨系统的那一段：质量部门已经作出处置决定，车间却没有收到返工任务，仓库也不知道其中几件暂时不能发；或者现场的返工路线总在变化，原系统每改一次都要排很久的开发期。

这时可以用织信把不合格评审、返工任务、复检结果以及权限规则建成有关联的业务应用，再按现有系统的接口条件，把获批的处置结果和实际执行结果送回MES、ERP或WMS。但无论怎么接，都得先定清哪边负责正式工单、哪边负责可用库存，接口失败后谁来补查。平台能提供搭建和连接能力，不会替企业拍这个板。

真要验收，就拿一批有返工也有报废的货走一遍

别只看演示里点完“返工完成”出现一个绿色勾。拿一批同时有首次合格、返工、报废的产品，从检验一路查到放行：不合格的件有没有被拦住？返工任务能不能找到原工单和缺陷记录？补料、工时留在哪儿？复检没通过时，库存是否仍不可用？最终合格数与报废数能否对上？

这几个问题走通了，再看系统还缺什么。若某一步只能靠人打电话解释，就先补那一步；若两套系统对同一批货给出不同数量，就先查口径和同步规则。返工返修任务进了MES，只是起点。等质量能查到放行依据、车间能查到处理记录、仓库能查到可用数量，而且三边指向同一批货，这件事才算处理完。

如果想继续改系统，织信能怎么接？

前面说的，是企业已经有ERP和MES，想把缺的流程补上。织信的AI对话开发可以先根据业务需求生成数据表、工作流等应用结构，团队再拿真实的返工单跑一遍：原工单能不能关联，审批该到谁，复检没过会不会误放行。发现不对，再让AI辅助修改。AI能加快搭建和调整，业务规则仍得靠企业自己验收。

还有一种情况：原有ERP、MES已经不适合继续用了，企业准备重新建设。织信也可以作为开发底座，按模块逐步构建自己的ERP和MES，而不只是给旧系统补一个页面。产品、BOM、工单、报工、质量、库存和成本这些对象之间怎么关联，哪些历史数据要迁，旧系统何时停用，都要在建设过程中一项项确认。先让新模块跑通并对上账，再决定切换范围，比喊一句“整体替换”更稳妥。

所以，选哪条路，先看企业要不要保留旧系统的主账。保留，就用织信补流程、接接口；要替换，就在织信上分阶段建系统，同时把迁移、权限和验收算进计划里。这样AI和低代码的速度，才能真正用在业务需要的地方。