基于若依框架的MES二次开发：从车间数字化到数据闭环

简介：面向制造业信息化负责人、MES项目选型及实施人员、车间管理者的一份PDF资料，围绕智能制造与MES应用展开，可帮助读者建立从智能制造内涵到MES落地执行的整体认知框架。内容依据e-works黄培博士的行业报告整理，系统梳理了MES作为智能工厂枢纽需要解决的现场信息透明化、生产过程可追溯、资源配置优化等痛点，并详细讲解MES与ERP、自动化设备、传感器及数字孪生、物联网、工业大数据等新兴技术的集成关系，同时覆盖可视化排产、APS、无纸化、精益生产等应用热点。全包为1个PDF文件，大小2.68MB，便于下载后离线研读。目前已有160人学习浏览，适合正在规划数字化工厂或准备实施MES的企业人员快速充电，还可参考其中的智能制造市场热点、国内外MES供应商概况及e-works多年咨询案例，辅助项目选型与推进。

1. 智能制造与MES应用：一份PDF让我重新梳理了车间数字化的落地顺序

第一次拿到《智能制造与MES应用.pdf》时，我以为又是一本把MES讲成“万能药”的教材。通读两遍后我改变了看法：它没有停留在概念层，而是直击车间里最常纠缠的问题——工单怎么流转、报工怎么算数、异常怎么处置。这份PDF适合两类人：一类是刚接手MES选型的生产主管，另一类是要跟车间打交道的开发人员。我试着从里面提炼出一套能直接落地的分析框架，并结合目前主流的若依框架MES二次开发经验，把这本资料拆成可执行的方法。下面是硬核部分，先把边界说清楚，再谈技术。

2. MES的核心定位与若依框架的二次开发前提：先分清你是在选型还是在做实施

2.1 MES到底管什么：从工单到报工的闭环

MES的边界，很多人跟ERP混着谈。ERP管的是“何日需要多少货”，MES管的是“此刻这道工序用谁在设备上做了多少、合格没有”。这份PDF里反复强调“计划-执行-控制”三层模型：ERP是计划层，MES是执行层，PLC/传感器是控制层。MES处在中间，向上承接ERP的工单和物料需求，向下采集设备状态和产量数据。没有MES时，车间说“做了800件”，账上可能还是“计划1000件”，差异只有月底盘点才知道。有了MES，从工单下达那一刻起，每一个状态变化都会被记录。

要把这个概念落到实际，我一般会先做一张功能边界表，避免团队在选型会上吵到失控。下面这张表是我读PDF后整理的，可以作为立项时的初步依据：

判断一个功能应该放ERP还是MES，标准很简单：如果它要回答“某一天某个工位上发生了什么事”，那就是MES的事。比如“订单交货期”是ERP的事，“B线喷漆这个班次做了多少件”是MES的事。把这个边界画清楚后，再去读PDF关于“生产建模”的部分，思路就通顺多了。实际操作时，我会带着这张表格跟车间主任一条一条对，问“这个流程现在谁在盯”，他答不上来的就是MES要补的。很多团队一上来就画菜单树，结果把MES做成了“工单登记表”，根源就在于没先定义执行层的东西。

在若依框架里做MES二次开发，我发现很多人一上手就写CRUD，结果把MES做成了“电子Excel”。正确的姿势是先把业务对象梳理成“工单-工序-资源-人员-物料”五个主数据，然后对应建表。若依的权限模型只能覆盖“谁能看菜单”，管不了“谁能在某个工位上报工”，这需要在业务表里增加部门或岗位维度。后面第四章我会讲具体的数据模型设计，这里先记住一句话：MES的差异不在界面，而在状态机和数据闭环。

2.2 若依框架MES的常见形态：后台权限与数据模型的复用边界

若依框架是目前国内开源后台管理里最常被拿来当MES基座的框架之一。它自带用户、角色、部门、菜单、操作日志、字典管理，省去了RBAC和代码生成器的时间。业界很多“若依MES”项目就是这么拼出来的：若依提供后台底座，业务团队在上面加车间模块。但这里有一个必须清醒的点：若依帮你搞定了“后台管理”，没帮你搞定“车间执行”。车间执行的关键是数据从哪来、状态怎么变、异常怎么处理。

用下表来对比若依自带能力和MES需要补的能力：

选型时，我建议团队先回答三个问题：第一，你们的车间生产是离散制造还是流程制造？这决定了工序模型的设计。离散制造按工单拆工序，流程制造按批次和配方，两种模型的表结构完全不同。第二，现有设备有没有联网数据？如果全靠人工报工，MES就类似电子工单，不要过度设计。第三，是不是需要与ERP对接？对接字段和时机要先谈好，否则后续改起来非常贵。若依框架不是MES的银弹，但它能让你把精力集中在业务核心上。

拿这份PDF来说，里面讲“生产工单状态”一般包括“创建、下达、开工、完工、关闭”。若依框架里没有现成的状态机，但我可以用自定义注解加AOP来统一处理状态变更日志，而不是在每个业务方法里手动写update语句。这样后端代码会干净很多。另外，若依的“数据权限”支持自定义，你可以把车间主任的数据范围限制到本车间，但不能精确到“某条产线的某个工位”，所以需要在业务表中增加“产线ID”字段，再用行级权限过滤。这一步很多人忽略，等上线后才发现跨车间能互相看到数据。我的习惯是，在开工第一周就写一个“权限检查SQL”，模拟不同角色的查询，把越权数据全部扫出来，比等用户投诉再排查强得多。

这一章的核心结论是：MES的应用边界必须先用业务对象画清楚，再映射到系统能力。不要因为用了若依就认为MES是“低代码搭个界面”；反之，也别觉得MES一定要上自动化设备采集，很多车间靠扫码报工就能解决90%的问题。

3. 把PDF读成实施手册：从业务调研到功能清单的转化方法

3.1 先画业务流程图，再对功能树

很多团队拿到MES以后，第一件事是找人开发“工单管理”菜单，结果做出了一个“电子Excel”，车间根本不买账。我读这份PDF时印象最深的一段话是：MES实施的第一成果不是系统，而是一张业务流程图。只要流程错了，系统做得越漂亮，错得越厉害。

具体的转化步骤我会这么走。第一步，选一条典型产线（比如组装线或机加工线），跟班组长一起走一遍实际流程：从ERP工单来到车间后由谁接收，怎么拆分到工序，谁来派工，员工做完后如何记录数量，不良品怎么处理，最后如何报完工。把这些动作按顺序写下来，不要跳过任何“打电话问一下”的隐性环节。

下面是一个离散制造车间的简化流程文本：

ERP工单下发 -> 车间计划员审核 -> 系统拆分工序计划 -> 产线组长派工到工位 -> 员工扫码开工 -> 加工完成 -> 扫码报工（良品数/不良品数） -> 质检员抽检 -> 合格则流转下一工序，不合格则发起异常单 -> 末工序完工 -> 入库

这个文本流程足以让团队统一认知。第二步，把流程中的每个动作映射成功能点：审核对应“工单审核功能”，拆分对应“工序计划”，派工对应“派工单”，报工对应“工序报工”，异常单对应“异常管理”。第三步，把这些功能点合并成功能树，比如“生产管理 > 工单管理 > 工单审核”，这样就能输出一份需求清单。

为什么一定要先画流程？因为我在若依框架里见到太多“菜单先行”的失败案例：菜单长得和ERP一样，但车间不用。实际上，MES的所有业务动作都围绕“工单-工序-报工”这条主线。只有把流程中每个节点的输入、输出、时间要求、责任角色定义清楚，功能树才有意义。这个步骤相当于把PDF里的理论翻译成车间听得懂的话。我一般还会用不同颜色标注“当前纸质流程”和“目标系统流程”，差异点就是实施要重点攻克的地方，比如原来靠口头传达的换料通知，系统里就要变成一条自动推送的消息。

3.2 用一张参数表把生产异常处理规则定下来

异常处理是MES里最容易“翻车”的模块。很多系统有异常登记功能，但异常单提交后石沉大海，原因是没有预先定义处理规则。这份PDF提到“异常闭环”概念：发现异常 -> 记录 -> 响应 -> 处理 -> 关闭，每一步都要有角色和时限。

我的做法是在需求阶段做一张异常处理参数表，让生产、质量、设备三方一起确认。这张表不需要覆盖所有异常，先抓最影响产出的三类：缺料、宕机、质量超标。

这张表的作用不是写进文档就完事，而是要落成系统参数：每个异常类型对应一个字典，处理角色对应若依的角色ID，响应时限用于超时提醒，影响状态用于自动更新工单状态。这样做的好处是，当现场出问题时，系统不是“记一笔”，而是自动把消息推给责任人并暂停或置罥相关工序。

在若依框架里实现时，我通常会把这套规则放到“异常类型表”和“异常处理配置表”中，而不是硬编码在业务代码里。比如，异常类型表中包含“异常编码、名称、处理角色ID、响应时限、影响状态”，这样后续改规则不用改代码，只要改配置。这个思路也吻合PDF强调的“柔性制造”理念——规则可配置，系统才有应变能力。注意，若依自带字典管理可以直接复用，但“响应时限”这类带数字的属性建议单独建配置表，因为字典值存字符串导致排序和比较都很别扭。另外，处理角色要填角色ID数组，因为现实里异常会升级到主管，需要在配置表里加“升级角色ID”字段。

3.3 从工序计划到报工的字段设计

报工字段的设计直接决定月底报表能不能算清工资。我在车间调研时发现，很多老班组长交上来的“工时”是臆造的，因为系统里没有“设备编号”“工位编号”这些维度，无法核对。这份PDF里的报工示例字段，我把它简化成下表的清单：

字段设计的核心原则是“采集一次，多处复用”。比如“设备ID”不仅要用于产量统计，还要用于设备稼动率计算，所以要保证它来自设备主数据，而不是报工页面手填。这里我踩过坑：拿着Excel导入设备时没有做唯一性校验，导致同一个设备在报工记录里出现“CNC-01”和“CNC-01 ”（带空格）两个版本，报表直接分裂。从那以后，所有主数据导入我都用“编码+名称”的联合去重，甚至先清洗空格和全角字符。

在设计字段时，我还会额外加一个“业务唯一键”字段，比如“工序报工唯一键 = 工单ID + 工序ID + 设备ID + 操作工ID + 报工时间截”，用来防止重复提交。这个字段配合数据库唯一索引，比在代码里判重要可靠得多。如果你用的是若依自动生成的代码，要记得在实体类中增加该字段，并在数据库表上建立唯一约束，否则并发请求下两条一样的报工会同时插入。还有一点，报工时间截最好由后端统一生成，不要信任前端时间，因为车间电脑的时钟经常不准。

4. 基于若依框架搭建MES的技术要点：数据模型、接口与权限

4.1 数据库表设计：用若依的部门表延伸车间-产线-工位

若依的sys_dept表是树形结构，天然适合组织映射。我在MES项目里一般让“部门”层级对应“公司-工厂-车间”，然后单独建一张“产线表”和“工位表”，通过车间ID关联。为什么不直接全部塞进部门表？因为产线和工位不是行政组织，是资源，它们有产能、状态等属性，塞进去会让权限控制变得奇怪。

下面以MySQL语法为例，给出产线表和工位表的简化设计。

-- 产线扩展表：一个车间有多条产线 CREATE TABLE mes_production_line ( line_id BIGINT PRIMARY KEY AUTO_INCREMENT, line_code VARCHAR(32) NOT NULL UNIQUE, -- 产线编码，如 L_A01 line_name VARCHAR(64) NOT NULL, workshop_id BIGINT NOT NULL, -- 关联 sys_dept.id，表示所属车间 capacity_per_hour DECIMAL(10,2) DEFAULT 0, status CHAR(1) DEFAULT '0', -- 0可用 1维修 create_by VARCHAR(32), create_time DATETIME, FOREIGN KEY (workshop_id) REFERENCES sys_dept(id) ); -- 工位表：一条产线上多个工位 CREATE TABLE mes_workstation ( ws_id BIGINT PRIMARY KEY AUTO_INCREMENT, line_id BIGINT NOT NULL, -- 关联产线表 ws_code VARCHAR(32) NOT NULL, ws_name VARCHAR(64) NOT NULL, device_id BIGINT NULL, -- 关联设备主数据，可选 is_key_point CHAR(1) DEFAULT '0', -- 是否关键工序 status CHAR(1) DEFAULT '0' );

这段SQL的逻辑：先定义产线，再定义工位，两者通过line_id关联；车间归属通过workshop_id指向sys_dept。这样用若依自带的用户管理，给班组长分配“车间数据权限”时，只需要在SQL里JOIN mes_production_line的workshop_id。注意：line_code和ws_code都加了唯一约束，这是防止Excel导入重复数据的第一步。

在设计时，我把“设备”单独建表而不是放在工位上，因为设备可能被调拨到不同工位。字段说明：capacity_per_hour用于排产估算，status用于设备/产线状态看板。这里要特别注意外键的级联删除策略：工位产能数据会被生产记录引用，所以不要物理删除，只用status标记停用，否则你把一个工位删了，历史报工数据全变孤儿记录。另外，workshop_id关联sys_dept时，要保证sys_dept的dept_type字段能区分“车间”和“公司”，否则会关联到错误节点。

4.2 工序流转与报工的接口设计

报工接口是MES的高频事务，生产高峰期每秒可能有几十个请求。若依框架的Controller层默认是基于单表的增删改查，如果直接用“先查工单状态，再更新工单数量，再插入报工记录”这种非原子操作，并发情况下必然出现超卖。我的做法是：报工操作放到一个Service方法里，用数据库事务控制，并且在业务表中加唯一约束。

给出一个简化版的Java接口逻辑：

@Transactional public AjaxResult reportWork(ReportWorkDTO dto) { // 1. 生成业务唯一键：工单ID+工序ID+设备ID+操作工ID+报工时间截 dto.setUniqueKey(buildUniqueKey(dto)); // 2. 校验工单和工序状态：只有“已下达”且当前工序为待报工状态才允许 WorkOrder wo = workOrderMapper.selectById(dto.getOrderId()); if (wo == null || !"2".equals(wo.getStatus())) { return error("工单不存在或状态不允许报工"); } // 3. 插入报工记录，依赖数据库唯一索引防重复 try { reportMapper.insert(dto); } catch (DuplicateKeyException e) { return error("请勿重复提交报工数据"); } // 4. 更新工序完成数量 processMapper.updateCompletedQty(dto.getOrderId(), dto.getProcessId(), dto.getGoodQty()); // 5. 判断是否所有工序完工，是则更新工单状态 updateOrderStatusIfNecessary(dto.getOrderId()); return success(); }

这个接口用@Transactional保证步骤3到5要么都成功要么回滚。参数DTO里必须包含orderId、processId、deviceId、operatorId、goodQty、badQty。要点在第2步：状态校验不能放在前端，因为接口可以被绕过。第3步的捕捉DuplicateKeyException是最后一道防线，依靠数据库唯一索引来兜底。我一般把唯一索引建在“order_id + process_id + device_id + operator_id + report_time”上，但报工时间可能精确到秒，同一秒内同一人同一设备对同一工序手工报工两次，会被视为重复——这是合理的，因为正常情况下一个工单同一工序只报一次。

如果现场有“补报”需求，比如夜班结束后批量录入，那么唯一键应该去掉operator_id或改为“报工批次号”，否则会挡住合法的补报数据。这个细节要跟车间确认清楚：是每完工一件报一件，还是批次完工后统一报？不同模式对应不同的唯一键粒度。还有一个隐藏坑：若依框架自带的事务管理基于Spring，如果我们在Service里捕获DuplicateKeyException，事务不会自动回滚，因为异常已经被捕获了。所以我建议在catch块里主动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，否则后续步骤虽然不回滚，但已经插入的报工记录会保留，状态更新却可能失败，导致数据不一致。

4.3 数据看板与报表：别在框架里硬写SQL

若依有个很常用的设计是后台列表页+查询，但MES的看板需要实时汇总，直接在业务表上写sum查询会拖垮数据库。我建议分两类处理：事务明细表只保留最近一周的实时数据，汇总看板数据放到一张“生产统计汇总表”中，由定时任务计算。

下面是一个按小时统计产量的SQL示例，用于驱动看板：

-- 按车间、产线、小时统计良品数，结果写入统计表 INSERT INTO mes_prod_statistics ( stat_date, hour_no, line_id, good_qty, bad_qty, create_time ) SELECT CURDATE() AS stat_date, HOUR(report_time) AS hour_no, ws.line_id, SUM(CASE WHEN r.good_qty > 0 THEN r.good_qty ELSE 0 END) AS good_qty, SUM(IFNULL(r.bad_qty, 0)) AS bad_qty, NOW() FROM mes_work_report r JOIN mes_workstation ws ON r.ws_id = ws.ws_id WHERE report_time >= NOW() - INTERVAL 1 DAY GROUP BY ws.line_id, HOUR(report_time);

这条SQL的逻辑：从报工明细表中按产线和小时聚合，等待写入统计表。注意这里用了CURDATE()和HOUR()函数，在MySQL中效率尚可，但如果报工表非常大，建议在前一天定时任务中只处理“上月”的数据。参数说明：mes_work_report是报工流水表，mes_workstation是工位表，ws.line_id用于关联产线。执行频率建议每30秒一次，而不是每次都跑全表。

踩过的一个坑是：使用HOUR(report_time)做分组时，如果车间跨天，23:00到01:00的数据会落在不同的stat_date和hour_no中，看板会产生断点。解决办法是统计时用“班次”维度替代小时维度，同时存储班次开始时间。另外，不要用若依自带的代码生成器直接生成“看板列表”，生成的查询会带分页和排序，看板刷新会产生大量无意义的SQL日志，把网关都刷爆。我给看板单独建一个只读数据源，跟业务库隔离。这样即使看板SQL写得很重，也不会影响前台正常报工。

5. 避坑与常见问题排查：车间上线MES的五个典型翻车点

5.1 现象：工单状态不同步

常见场景是：上午10点计划员在ERP里下达了工单，MES里也生成了，但过了2小时产线已经开动，MES工单还停在“已下达”，导致后续报工全部被拦截。还有更隐蔽的：MES里工序已经完工了，但ERP工单还是“执行中”，月底对账时两边数量对不上。

原因通常有两个：一是两个系统之间的状态同步依赖定时任务，任务失败后没有重试机制；二是MES内部更新状态时，只更新了工序表，没更新工单主表。比如报工方法里只调用了processMapper.updateCompletedQty，而工单表的status字段没有联动修改。

解决方法是所有工单状态变更都必须走统一的状态机Service，并记录状态变更日志；定时任务加失败重试，同步一旦失败要输出异常邮件。我实际项目中碰到过，原因是若依的定时任务线程池被某个慢SQL卡死，后续任务全部堆积。排查时可以看任务日志，确认上一次同步时间距现在多久。从那以后，我要求每个定时任务必须设置超时时间，并且把单独工单状态同步改成按批次批量同步，速度提升了一个量级。另外，状态同步要加“对账接口”，每天凌晨比对一次ERP和MES的工单状态，把不一致的清单拉出来让人工处理。

5.2 现象：报工数据重复提交

现场最典型的情况是：员工在触摸屏上报工时，手指点了一下“确认”没反应，又点了一下，结果生成两条一模一样的报工记录，产量直接翻倍。如果是夜班交接，员工自己都没注意，等到月底对账才发现数量超了。

原因是前端按钮没有做防重复点击，后端接口也没有幂等控制。有人以为前端按钮置灰就万事大吉，但车间网络差，请求超时会自动重发，这时候前端状态已经恢复，后端的重复请求照样执行。

解决策略分三层：第一，前端在点击提交后把按钮置灰并显示loading，同时禁用触摸屏的双击事件；第二，后端在接收报文时先查Redis里是否已有该messageId，有就直接返回上一次结果；第三，数据库表加唯一索引，兜底防重。第三层最重要，也是最后防线。我在若依里实现时，还额外写了异常处理器，把DuplicateKeyException翻译成“请勿重复提交”，而不是给用户弹出500错误。注意，唯一的索引字段不要用可空列，因为MySQL下NULL值不参与唯一性约束，防重会失效。这个问题困扰了我很久，排查时发现字段在Excel导入时没填值，导致同一工单被重复报了很多次。

5.3 现象：看板数据延迟

车间的大屏显示“今日产量”从下午两点就没变过，但报工界面一直有数据在增加。重启一次服务，看板数据又更新了，过一会儿又卡住。这种问题在我经历的项目里出现过三次。

原因是定时统计任务把全量的报工表跑一遍，数据量一大，单次执行就要十几分钟，下一次任务启动时上一次还没跑完，线程池一塞，整个调度队列就堵住了。另外，大屏前端用的定时刷新如果写在浏览器标签页里，电脑休眠后定时器会停止，恢复后也不会自动重新拉数据。

解决方法是把全量统计改成增量预聚合：每5分钟只统计上一时段新增的数据，写入统计表；同时用WebSocket推送代替前端轮询。WebSocket断开后要自动重连，否则一次短暂的网络抖动就会让大屏永久沉默。具体到SQL，需要确保report_time和line_id上有联合索引，否则增量查询也会全表扫。还有一个建议：看板数据不要直接查业务表，而是查统计表。统计表可以做保留策略，比如保留3年，但业务流水表只保留几个月，定期归档。我在一次项目实施中，就是因为统计SQL里少了“where report_time > last_run_time”，又把全表扫了一遍，差点把生产库拖垮。从那以后，我的统计任务模板里强制带“last_stat_time”参数，每次运行都记录。

5.4 现象：用户权限混乱

车间C的员工打开系统，居然能看到车间A的工单，甚至能修改别人的报工数量。质检员查出不良后，想锁定工单，却发现自己没有权限按钮，找管理员又耽误了半天。

原因多半是：第一，若依默认的数据权限没有配置，或者配置了但Mapper的SQL没有带@DataScope；第二，给用户分配了“超级管理员”角色，一劳永逸但后患无穷；第三，自定义Mapper用了多表JOIN，若依的数据权限注解只对主表别名生效，子表数据没被过滤。

解决步骤：第一步，收回超管角色，只保留必需的运维账号，并且强制开启双重认证。第二步，在工单表增加dept_id字段，并在查询Mapper的SQL头部写上@DataScope(deptAlias = "wo")。第三步，把所有涉及工单、报工的查询统一收到一个带权限的公共Service里，禁止团队成员各自写Mapper。第四步，上线前用测试账号跑一遍“跨车间越权”的用例。我在项目里发现若依的数据权限有个细节：它会在SQL外直接拼接“and wo.dept_id in (...)”字符串，但如果SQL里已经有“and wo.status = '1'”且后面还有括号，拼接位置可能错乱。所以建议Mapper里的SQL只保留一层结构，不要嵌套子查询。权限规则是账面上的事，越早越严格越好，上线后再推倒重来非常伤。

5.5 现象：系统上线后没人用

最严重也最容易被忽视的翻车点：系统上线一个月，登录人数屈指可数，报工数据全是文员事后补录的，PDA和扫码枪挂在墙上吃灰。业务板块上的工单状态永远是“已创建”，没有“执行中”的过程数据。

原因是系统增加了工人的作业负担。比如报工页面要填8个字段，还要从下拉框里找设备编号，比原来在纸质流转卡上画勾慢得多；又比如工位电脑摆得远，工人来回走动浪费时间；还有一种情况是系统没有给工人带来任何好处，只像一个监控工具，谁都不愿意配合。

解决方法是上线前一定要做“岗位级”确认：跟班组长和操作工一起设计报工页面，尽量做到“扫一次码，自动带出工单、工序、设备，只填良品数和不良数”。把触摸屏或PDA放在工位伸手可及的位置，按钮做大，减少操作层级。同时把实时产量投到车间电视看板上，让工人看到自己班组的产量排名。技术不是核心，让现场感觉“系统是帮手而不是监工”才是。如果条件允许，把报工效率跟计件工资挂钩，工人自己就会主动用。我在一个紧固件车间里，把报工时间从原来的“每件填3个下拉框”改成“扫码枪扫一次自动计时”，上线第二天产能报表就活了。那一次我意识到，车间的人不是抗拒系统，是抗拒那些让他们多干活少拿钱的设计。

6. 进阶验证：用三条SQL验证MES数据闭环是否真的打通

系统上线两周后，我建议用三条SQL来自查数据闭环是否打通。第一，工单完工数量核对：选择一批已经关闭的工单，统计每个工单在报工表中“良品数之和”，跟ERP的完工数量比对。

SELECT w.order_code, w.plan_qty, (SELECT IFNULL(SUM(good_qty),0) FROM mes_work_report r WHERE r.order_id = w.order_id) AS report_qty FROM mes_work_order w WHERE w.status = '5' -- 已完工 AND DATEDIFF(NOW(), w.close_time) < 30;

第二，不良率统计：按产品、工序统计不良率，看是否超过质量控制线。

SELECT p.product_code, r.process_id, SUM(r.bad_qty) / (SUM(r.good_qty) + SUM(r.bad_qty)) AS bad_rate FROM mes_work_report r JOIN mes_work_order w ON r.order_id = w.order_id JOIN mes_product p ON w.product_id = p.product_id GROUP BY p.product_code, r.process_id HAVING bad_rate > 0.05;

第三，设备稼动率：用报工的可计算工时和理论工时对比。

SELECT line_id, SUM(good_qty) * 0.5 AS actual_work_hours, -- 0.5为单件标准工时 COUNT(DISTINCT ws_id) * 8 AS planned_hours -- 8为每班次小时数 FROM mes_work_report WHERE report_time >= DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY line_id;

这三条SQL都很实用，但前提是报工数据字段完整、唯一键可靠。如果第一张表对不上，多数问题出在报工漏报或重复报；第二张表异常，要查不良原因字典是否规范；第三张表不准，要检查标准工时维护是否正确。我后来养成了一个习惯：每次MES项目上线，第一周每天跑一遍这三条SQL，看趋势；有异常就顺着报工事务日志倒查。这个习惯帮我提前发现了不少“看起来能跑、实际数据是脏”的隐患。从那以后，我每次报工相关变更都强制走一遍“唯一键+状态机+对账SQL”三件套，数据库里再也没出现过对不上的糊涂账。希望这份PDF拆解和动手思路能帮到你，真正让MES系统成为车间里的“明白账”而不是第二个Excel。

本文还有配套的精品资源，点击获取