简介：一套基于.NET 4.0的SimpleMES加工装配模拟系统，面向MES系统学习者、课程设计或毕业设计人员，以及需要快速搭建制造执行原型的开发者。服务端与客户端分工明确：服务端包含基础档案、加工与装配计划管理、实时看板和数据初始化；客户端覆盖加工、装配及搬运过程控制和质量异常处理，核心业务逻辑封装于数据库存储过程，便于深入研究MES的调度与数据流转。资源包共445个文件，压缩后约10MB，以175个C#源码、36个DLL库和12个EXE程序为主体，并附带MDF/LDF/BAK数据库文件、DOCX设计说明书、配置文件、图片及WAV提示音频，其中DB目录可直接附加数据库，Doc目录包含完整设计说明。已有557人学习下载，借助这套资源不仅能获得可运行的服务端与客户端工程，还可结合说明书理解计划、看板、实时监听与异常处理之间的联动，适合作为Visual Studio 2010与SQL Server 2008 R2环境下的二次开发蓝本。
1. 装配车间上MES最容易翻车的地方，为什么SimpleMES能绕过去
机械加工装配类的中小车间选MES，普遍卡在一个尴尬位置：大厂MES实施周期长、顾问费比软件费贵，一线班组根本不买账；纯靠Excel加微信群报数，又永远对不上在制数和齐套率。SimpleMES这类轻量级方案，恰好把加工装配场景里最核心的东西收成一张可维护的工单流：工艺路线、多级BOM、工序报工、齐套检查和异常处理，而且它常见的技术底座是若依框架，扩展方式清楚，不依赖原厂顾问。这套逻辑更适合预算有限、想先用起来再迭代的数字化专员、车间主任和负责落地的IT工程师。很多人把MES想成一个大黑匣子，其实加工装配类MES的骨架，一张工单流转表就能说清楚。
2. SimpleMES的数据建模核心：物料、多级BOM和工艺路线怎么落到一张工单上
2.1 基于若依框架的MES：SimpleMES把哪些能力白送给了你
若依框架在Java技术栈里普及度很高，基于若依框架的MES项目一搜一大把，SimpleMES是其中偏向加工装配场景的一种开源实现。选这个底座的直接好处是：用户管理、角色权限、菜单管理、操作日志、定时任务、代码生成器这些通用模块齐全，不用从零写。你做MES时最费时间的是业务建模，而不是用户登录和按钮权限这些重复工作。
RuoYi-Vue的技术栈是Spring Boot加Vue加MyBatis加MySQL，招人容易，二次开发门槛低。很多车间没有专职架构师，找一个能写SSM的工程师就能维护，这是我推荐它在中小厂落地的主要原因之一。再加上若依自带定时任务和缓存监控，MES里最常用的工单超时预警、设备状态心跳检测，都能直接挂在框架的调度器上，不需要额外引一套任务系统。
2.2 物料主数据先理清三件事：编码、单位、批次
加工装配车间的物料特点是层级多，半成品要过好几道工序才变成成品。物料主数据如果建不好，后边的BOM展开、齐套计算、报工入库全是错的。我一般建议在建SimpleMES的基础数据时，先把这三件事定死。
第一，物料编码全局唯一，禁用中文名当主键。第二，物料类型的边界要清楚：原材料、半成品、成品三类区分开，装配场景中半成品是否要建独立物料编码，要在项目启动会上拍板。第三，批次管理默认开启，哪怕现在的库存量不大也要开。理由是装配场景的追溯诉求很强，一旦客户投诉或者来料不良，你要能从成品条码倒查到批次、供应商和加工记录，没有批次字段这个追溯链就断了。
物料主数据在SimpleMES里通常对应的建表逻辑如下：
CREATE TABLE mes_material ( material_id BIGINT AUTO_INCREMENT PRIMARY KEY, material_code VARCHAR(64) NOT NULL UNIQUE COMMENT '物料编码，全局唯一', material_name VARCHAR(128) NOT NULL COMMENT '物料名称', material_type CHAR(1) NOT NULL COMMENT '类型：1原材料 2半成品 3成品', unit VARCHAR(8) NOT NULL DEFAULT 'PCS' COMMENT '基本单位', is_batch TINYINT NOT NULL DEFAULT 1 COMMENT '批次管理：1开启 0关闭', safety_stock DECIMAL(12,2) DEFAULT 0 COMMENT '安全库存', status TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB COMMENT='物料主数据';这里的关键参数是material_type和is_batch。类型会影响后续BOM展开时是否要继续往下拆；批次管理建议生产型和贸易型的物料都开，别为了省事关掉。单位这里建议统一到最小计量单位，装配车间经常混用“套”和“件”，如果不统一，报工数量换算会踩坑。
导入物料时，常见的做法是先把Excel模板导出，清洗后通过若依代码生成器做成的导入功能批量入表。要注意Excel里如果编码重复，MySQL的唯一索引会直接抛错，数据库层面加一道保险比什么都管用。
2.3 装配场景的关键配置：多级BOM展开与工艺路线绑定
装配BOM的难点不是建父子关系，而是变更多。今天换了一个供应商，螺栓规格变了，整条装配路径的物料需求都要跟着变。SimpleMES里通常把BOM和工艺路线分开维护，工单创建时选择“BOM版本加工艺路线版本”的组合，再取组合后的快照数据。这样老工单继续走老BOM，新工单自动用新版本，不会互相污染。
多级BOM展开的SQL，在MySQL里可以靠递归CTE完成。加工装配的叶子节点可能是采购件也可能自加工件，但齐套计算只关心最底层物料需求，所以要递归展开到叶子。我给一个可以直接调试的版本：
-- 按BOM版本递归展开到叶子物料，并折算成根节点的用量系数 WITH RECURSIVE bom_flat AS ( SELECT material_id, parent_id, qty, 1 AS level FROM mes_bom_item WHERE bom_revision_id = 1001 AND parent_id = 0 UNION ALL SELECT c.material_id, c.parent_id, c.qty * p.qty, p.level + 1 FROM bom_flat p JOIN mes_bom_item c ON c.parent_id = p.material_id WHERE c.bom_revision_id = 1001 ) SELECT material_id, SUM(qty) AS unit_qty FROM bom_flat GROUP BY material_id;这段SQL的逻辑是：先取根节点，然后逐层往下，子项的用量乘以父项的累计系数。bom_revision_id是BOM版本的外键，parent_id = 0表示根节点。展开后得到的unit_qty是单位成品的物料需求量，后面跟工单数量相乘就得到总需求。注意递归CTE在MySQL 8.0以上才支持，如果是5.7，要么换写法或者升级数据库，这一点会在老车间部署时经常发生，提前确认版本能省不少麻烦。
工艺路线相对简单，一张表就能维护：
CREATE TABLE mes_route_process ( id BIGINT AUTO_INCREMENT PRIMARY KEY, route_id BIGINT NOT NULL COMMENT '工艺路线ID', process_seq INT NOT NULL COMMENT '工序顺序，从10开始', process_name VARCHAR(64) NOT NULL COMMENT '工序名称，如装配、点焊、老化', workcenter_id BIGINT NOT NULL COMMENT '工作中心ID，关联产线或工位', standard_hours DECIMAL(8,2) COMMENT '标准工时，小时', is_check TINYINT DEFAULT 0 COMMENT '是否必检工序：1是 0否' ) ENGINE=InnoDB COMMENT='工艺路线工序表';process_seq我建议按10、20、30递增编号，中间要插工序时不用重排。有了这张表，工单创建时按process_seq排序批量生成工序实例，后续报工就是逐个工序走状态，逻辑就清晰了。很多MES说明书里把“工单生成的同时复制工艺路线”叫工序实例化，这是SimpleMES从建模走向执行最关键的一步。
3. 从工单下达到完工入库：SimpleMES的工序流转与报工逻辑
3.1 一张工单在SimpleMES里怎么走完五步
工序流转是加工装配MES的执行主线，操作工所有的操作都围绕“当前工单当前工序”展开。常见流程分五步：创建工单、下达车间、工序开工、报工、完工入库。
创建工单的时候，系统根据产品和数量的组合自动带出BOM版本、工艺路线版本，并生成一批工序实例，每道工序初始状态是等待开工。下达车间后，班组长才能看到任务并派工到产线。每道工序等待开工不等于设备正在生产，真正的开工动作是操作工扫码确认“我开始干了”，这个时间点就是工时采集的起点。报工后系统校验合格数、不良数，同时判断是否还有下一道工序；全部工序完成后，工单自动进入入库候选状态。
这套流程的价值在于：你不用额外安装设备采集硬件，也能先把工序级数据采集起来。对装配车间来说，设备自动化程度参差不齐，人员动作数据比设备数据更重要。
3.2 工单条码规则怎么定：从4321这个编号说起
标题里的4321，我理解是一套工单编号规则的典型示例。实际编码结构可以拆成“4位产品系列 + 3位工艺版本 + 2位产线代码 + 1位班次代码”，合起来就是一个可读、可追溯的工单号。关键不是数字位数，而是扫码后系统能解析出产品、版本、产线和班次信息。
生成工单号的Java代码也可以写得很直接：
public String buildWorkOrderCode(Product product, ProcessRoute route, String lineCode, Integer shiftCode) { // 4321规则示例：产品系列4位 + 工艺版本3位 + 产线2位 + 班次1位 String productCode = StringUtils.leftPad(product.getSeriesCode(), 4, '0'); String routeCode = StringUtils.leftPad(String.valueOf(route.getVersion()), 3, '0'); String linePart = StringUtils.leftPad(lineCode, 2, '0'); String shiftPart = String.valueOf(shiftCode); return productCode + routeCode + linePart + shiftPart; }参数说明：seriesCode是产品系列编码，不是完整物料编码，控制在4位只做标识不做含义解析。route.getVersion()是工艺路线版本号，3位足够用到999个版本。lineCode建议直接用厂区编号，不要用产线中文名，避免条形码里出现中文导致扫码枪乱码。班次代码用1、2、3对应早中晚班。
这里有一个很容易忽略的坑：编码里不要加上日期，日期变体天然每天不同，会导致返工追溯困难。日期单独在数据库字段里保存，扫码查询时传参即可，不要把动态日期拼进条码。车间师傅扫了条码也看不出日期，反而容易扫错工单。
3.3 齐套检查：装配车间最刚需的一张缺料清单
装配场景的典型痛点是开工前发现缺料，生产已经停了才发现仓库少一个贴片电容。齐套检查必须在工单下达前跑一次，逻辑也很直白：根据工单数量和BOM展开结果算需求，减去可用库存，大于零的就是缺料。
-- 齐套检查：需求数量减去可用库存，返回缺料清单 WITH RECURSIVE bom_flat AS ( SELECT material_id, qty, 1 AS level FROM mes_bom_item WHERE bom_revision_id = #{revisionId} AND parent_id = 0 UNION ALL SELECT c.material_id, c.qty * p.qty, p.level + 1 FROM bom_flat p JOIN mes_bom_item c ON c.parent_id = p.material_id WHERE c.bom_revision_id = #{revisionId} ) SELECT f.material_id, f.qty * #{orderQty} AS demand_qty, IFNULL(s.available_qty, 0) AS available_qty, f.qty * #{orderQty} - IFNULL(s.available_qty, 0) AS shortage_qty FROM (SELECT material_id, SUM(qty) AS qty FROM bom_flat GROUP BY material_id) f LEFT JOIN mes_material_stock s ON s.material_id = f.material_id HAVING shortage_qty > 0;这个查询的核心在available_qty字段。你库存表里的账面库存和可用库存一定不要混用。账面库存包括已经预留给其他工单的量，如果直接拿账面数去算齐套，就会得出虚假的“已齐套”，真正开工时又缺料。我一般在mes_material_stock表里加一个reserved_qty字段，可用库存等于库存总量减去预留量，齐套检查只认可用库存。这是很多MES实施中后期才补的补丁，建议一开始就按这个逻辑建表。
3.4 报工事务：为什么不能只写一条报工记录
工序报工看着简单，但它是MES里最容易出数据事故的地方。常见错误是只往报工表插入一条记录，然后不管在制数量。正确的做法是报工插入和工序数量更新必须在同一个数据库事务里，否则报工成功但工序状态没变，在制数量就变成一笔糊涂账。
/** * 工序报工：写报工记录并更新工序完成数量 */ @Transactional(rollbackFor = Exception.class) public void reportProcess(ReportDTO dto) { WorkOrderProcess wp = workOrderProcessMapper.selectByIdForUpdate(dto.getProcessId()); // 状态校验：只有运行中的工序才允许报工 if (!"RUNNING".equals(wp.getStatus())) { throw new BizException("工序状态不是运行中，不能报工"); } // 防错：累计合格数量不能超过工单计划数量 BigDecimal finishedQty = reportMapper.sumQualifiedQty(wp.getId()); if (finishedQty.add(dto.getQualifiedQty()).compareTo(wp.getPlanQty()) > 0) { throw new BizException("报工数量超出工单剩余数量"); } // 写入报工记录，同时更新工序完成数量 reportMapper.insert(dto); wp.setFinishedQty(finishedQty.add(dto.getQualifiedQty())); // 全部完成则工序状态流转为已完成 if (wp.getFinishedQty().compareTo(wp.getPlanQty()) >= 0) { wp.setStatus("FINISHED"); } workOrderProcessMapper.updateById(wp); }这段代码有三个关键细节。第一，selectByIdForUpdate加行锁，防止两个操作工同时扫同一道工序重复报工。第二，报工数量与工序余量做校验，这一步是“防错”，装配车间常见的错装漏装问题，通过数量校验能挡住一部分。第三，@Transactional保证报工记录和工序数量一起成功、一起失败，不会出现报工了但数量没涨的情况。
3.5 完工入库与后道工序解锁
一个工单的最后一道工序报工完成后，系统要自动把产品状态改成待入库，同时对下道工序解除锁定。这是通过报工后的事件触发实现的，而不是让操作工手动去点击“完工确认”。我见过很多项目在每一个环节都让人去点按钮，操作工嫌烦，最后直接不点，数据就是死的。
常见的实现方式是：报工事务成功提交后，通过Spring的事件发布机制，监听工序完成事件，然后自动判断process_seq是否为该工单最大的工序，如果是就更新工单状态为完工。你要在报表上查“今日完工量”，直接查这张工单状态即可，不要在Excel里再汇总一遍。
4. 基于若依框架的权限配置：车间里谁该看什么，一个按钮都不能多
4.1 三套常用角色菜单：操作工、班组长、计划员
MES上线后最让车间反感的不是系统慢，而是屏幕上堆满了和自己无关的菜单。SimpleMES基于若依框架的权限体系，可以很好地按角色裁剪菜单。我一般建议分三套默认角色模板。
操作工只保留“我的任务、工序报工、不良上报”；班组长增加“工单查询、齐套检查、异常处理、人员派工”；计划员增加“BOM维护、工艺路线维护、工单创建、库存查询、报表中心”。车间主任和管理层可能还要看“效率看板”，但这类角色建议后置，等数据稳定了再开。
在若依框架里，菜单权限通过perm字符串控制，角色配菜单用SQL就能批量完成：
-- 给班组长角色批量绑定菜单权限 INSERT INTO sys_role_menu(role_id, menu_id) SELECT r.role_id, m.menu_id FROM sys_role r, sys_menu m WHERE r.role_key = 'workshop_leader' AND m.perms IN ( 'mes:workorder:list', 'mes:material:available', 'mes:exception:handle', 'mes:report:list' );这段SQL用了SELECT ... FROM sys_role, sys_menu的笛卡尔积加条件过滤方式，避免逐条手写INSERT。真正执行时可以把role_key换成你系统里实际的角色标识。菜单权限的粒度建议控制到按钮级：操作工界面上连“删除工单”的按钮都不要出现，因为越权的操作人员点错一次，整条工单数据就乱了。
4.2 数据权限：让班组长只看到自己那条产线
菜单权限控制能不能进某个页面，数据权限控制进了页面能看哪些行。SimpleMES里常见的诉求是：A线的班组长看不到B线的工单和报工记录。若依框架自带@DataScope注解，可以在查询前自动拼接数据过滤条件。
/** * 工单查询列表，数据权限自动过滤产线 */ @DataScope(deptAlias = "d", userAlias = "u") public List<WorkOrder> listWorkOrder(WorkOrderQuery query) { return workOrderMapper.selectWorkOrderList(query); }对应的Mapper XML里要预留数据权限拼接位置：
<select id="selectWorkOrderList" parameterType="WorkOrderQuery" resultType="WorkOrder"> SELECT w.order_id, w.order_code, w.product_id, w.plan_qty, w.status FROM mes_work_order w LEFT JOIN sys_dept d ON d.dept_id = w.dept_id <where> <if test="status != null"> AND w.status = #{status} </if> ${params.dataScope} </where> </select>${params.dataScope}是若依框架数据权限解释器自动拼接的SQL片段。关键是工单表上要挂dept_id，这个部门对应实际产线，不能随便挂一个行政部门的ID。如果工单表里没设计dept_id字段，数据权限就无从谈起，这是建模阶段就要预留的字段，而不是上线后补。数据权限是MES项目里争议很大的功能，建议上线第一天就开启，后期再开会让工人觉得系统在“突然限制自己”，反而不配合。
4.3 字典参数与基础配置：合格率阈值、工时版本、不良代码
若依框架的字典管理可以直接复用。MES里最典型的字典是“工序状态”和“不良原因”。工序状态我建议就用四个：等待开工、运行中、已完成、已关闭。太多状态会让操作工不知道选哪个，太少又无法表达返工等场景。不良原因代码要提前跟质检部门对齐，装配场景常见的有错装、漏装、外观划伤、扭矩超差、尺寸超差这五类，宁可先少后补，也不要让人在文本框里随手敲中文。
合格的MES说明书，应该把每个字段的解释、可选值和流转规则写清楚，这比写代码重要得多。字典配置步骤很简单：在若依管理后台的“字典管理”里新建字典类型mes_wo_status，然后添加字典数据。这些数据在工单下拉框、报表筛选项里会自动生效，不需要改前端代码。
5. 加工装配场景里最常踩的5个坑，按现象、原因、解决方案排查
5.1 报工了但WIP在制数量对不上
现象：上午报工了120件，下午查在制数量还是0，或者变成了负数。整个车间在制数没人敢信。
原因：报工表和工序状态更新不在同一个事务里，半路失败导致报工记录写进去了但工序数量没更新；更常见的是直接在工单表存了一个冗余的wip_qty字段，报工加一笔、入库减一笔，中间任何一步漏了就对不上。
解决：不要单独存WIP字段，在制数量永远通过“累计报工数量减去累计入库数量”实时算出来。报工、质检判定、入库、状态更新全部放进一个事务。每周让班组长抽查三个工单的在制数和现场实物进行比对，坚持两周，数据可信度就上来了。
5.2 齐套检查显示齐套，开工还是缺料
现象：工单下达前齐套检查通过了，真正开工时仓库发不出料。
原因：齐套计算用了账面库存，而不是可用库存。账面库存没有扣掉已经预留给其他工单的数量，甚至没有扣掉已经被品质冻结的来料不良库存。
解决：库存表增加reserved_qty和frozen_qty两个字段。可用库存=总库存-预留-冻结。同时把齐套检查从“即时查询”改成“工单下达时生成快照”，缺少的物料锁定需求，后续采购到货后自动释放预留。操作上，仓库每次做库存异动时都要在系统里同步更新预留量，这一步做不到，齐套检查永远不准。
5.3 扫码枪输入项目标题时自动跳过字符
现象：操作工扫工单条码，输入框里偶尔少一个字符，或者最后多一个回车符，导致查询不到工单。
原因：扫码枪在键盘仿真模式下，中文输入法会截断字符；另外扫码枪默认的结束符是回车键，看系统有没有自动把回车转成查询触发。输入框没有去空格和回车处理，也是常见原因。
解决：扫码枪配置里把工作模式设置为“键盘仿真+回车后缀”，成本低兼容性好。代码层面对条码做统一处理：接收到输入框的值先trim()掉首尾空白，再去掉结尾的\r\n。查询按钮用回车事件触发，这样扫码和手动回车都能得到一致结果。不要改用USB串口模式，Windows和Linux的驱动配置差异会让你多踩三天坑。
5.4 修改BOM后，已下发的工单还在用旧版本，但物料需求变了
现象：技术员改了装配BOM，结果工单报工时物料需求全是错的，要么多算要么少算。
原因：工单没有对BOM做版本快照，BOM修改直接影响了在制工单。
解决：BOM表只做新增版本，不做原地修改。每个工单创建时把BOM明细复制到工单BOM快照表，后续查询物料需求都走快照表，而不是JOIN最新BOM版本。这样做还有一个好处，就是追溯历史工单时，可以还原当时的BOM到底是什么样。这条准则同样适用于工艺路线：工单一旦创建，工艺版本不可变更，除非显式做工序变更单。
5.5 若依定时任务和MES轮询任务并发，导致工序超时误报
现象：凌晨1点一批工单被自动标记为“超时”，但是实际上班次是下午4点才结束。
原因：若依框架自带的定时任务默认每分钟扫描一次，而MES工序超时检测任务也是独立调度的，两个任务并发执行时，超时检测读到了还没落库的班次结束事件。
解决：为超时检测任务补充“班次结束时间校验”逻辑，只处理当前时间大于计划结束时间加缓冲时间的工单。在若依的调度管理里把两个任务的执行错开，不要都放在整点。更重要的是给定时任务加上分布式锁，避免多实例部署时重复触发。经验是：MES里的定时任务一定要允许手动补跑，否则一旦漏跑，超时状态的数据补起来会非常费劲。
6. 把SimpleMES从“记录系统”变成车间看板：先盯住一条小时产出SQL
很多MES项目死在上线三个月后没人看报表。要避免这个结局，我的建议是不要一开始就做大而全的看板，而是先盯住一条小时产出SQL。对车间主任来说，今天现在这一刻产线干出了多少合格件，比任何漂亮图表都管用。
-- 按小时统计各工序的合格产出和折算标准工时 SELECT DATE_FORMAT(r.report_time, '%Y-%m-%d %H:00') AS hour_bucket, wp.process_name, SUM(r.qualified_qty) AS qualified_qty, ROUND(SUM(r.qualified_qty * wp.standard_hours), 2) AS standard_hours FROM mes_report_record r JOIN mes_workorder_process wp ON r.process_id = wp.id WHERE r.report_time >= NOW() - INTERVAL 24 HOUR GROUP BY hour_bucket, wp.process_name ORDER BY hour_bucket DESC, wp.process_name;要把这个查询跑起来，前提是报工记录里带准确的时间戳，并且每道工序实例上有standard_hours。很多实施项目把标准工时放在工艺路线表里，工单工序实例没有复制一份，结果报表只能按数量统计，算不了效率。工序实例落库时把标准工时快照下来，是我反复强调的一个点。
报表稳定后，可以算极简版OEE。口径不需要追求和教科书一致，能用就行：合格产出数量乘以标准工时，除以设备可动工时。可动工时按班次时长减去计划停机时间。这样算出来的OEE有一个偏差，但趋势是可靠的。对比每天的OEE波动，再结合不良代码占比，就能定位是哪个工序掉链子。等我回头看这些年做过的MES项目，凡是能坚持三周核对小时产出数据的车间，最后都把SimpleMES用成了真正管理的抓手；凡是只看月报的都半途而废了。数据这种事，你不能等它自己变准，要拉着班组一起较真，较真两三个礼拜，大家才认账。希望帮到你。
本文还有配套的精品资源，点击获取
