简介面向制造型企业与ASP开发者的生产管理系统源代码涵盖生产计划、物料需求计划、库存管理、进度跟踪、质量控制、订单管理等核心业务模块适合需要熟悉制造信息化流程或进行二次开发的技术人员。资源包共165个文件以97个asp动态页面为主辅以js交互脚本、css样式、gif/jpg图片素材及数据库文件压缩包整体仅1.33MB目录结构清晰便于按模块快速定位。已有2002人学习下载源码中不仅包含各模块的页面逻辑还涉及MRP算法、物料消耗计算、数据采集接口、报表分析、权限控制及数据库设计等关键实现并覆盖了生产进度跟踪中的条码/RFID接口、质量控制中的检验与不合格品处理流程可帮助开发者理解一套完整生产管理系统的架构与编码方式。对于希望快速搭建原型或扩展功能的企业这套代码能提供直接可用的基础与自定义空间。1. 生产管理系统源代码六个模块怎么把订单串成入库单生产管理系统这类源码包常见的问题是下载下来是一堆文件夹对着 README 折腾半天数据库还是连不上。这套源码给出的是另一条路六个功能模块覆盖订单、排产、物料、报工、入库和报表数据链路能从头跑通到尾。适合没搭过企业级应用的新手学习完整流程也适合小工厂做信息化选型时拿来做功能对照。我在拆这套系统时做的第一件事是跟着一张生产工单走完全部状态流转确认数据在每个环节都被正确记录。这一步走通了系统可用性就有底后续改造成本也可控。2. 系统模块与技术栈选型六个功能模块的边界与数据走向拿到一套生产管理系统源代码先别急着启动。如果连模块边界和数往哪流都没搞清后面排错会非常别扭。这里把这套系统的结构和选型逻辑拆开看。2.1 模块划分与数据流转关系这套系统按业务域拆成六个模块每个模块对应一组核心表。模块之间的边界很清晰基本遵循「主数据先行、计划驱动执行、执行回写库存」的原则。模块核心实体主要职责基础资料物料、BOM、工艺路线维护主数据是其他模块的依赖销售订单订单头、订单行记录客户需求作为计划来源计划管理主生产计划、物料需求把订单转成可执行的生产工单车间执行工单、报工单、质检记录记录生产进度与质量结果仓库管理领料单、入库单、库存台账控制物料收发与成品入库统计报表日报、月报、产出汇总从执行数据中抽取分析结果数据流转的主线是这样销售订单审核后生成主生产计划计划模块按 BOM 展开物料需求再生成生产工单车间按工艺路线报工报工通过后触发成品入库库存增加报表模块只读业务表做汇总展示。这种流向决定了你在配环境时要先初始化基础资料否则工单根本建不起来。我一般会强调一个点别把业务逻辑写到别的模块的表里。比如报工模块不应该直接改库存而是通过入库单接口触发库存变化。当前这套代码基本遵守了这个约束改起来比较顺手。2.2 技术栈选型为什么是 Spring Boot Vue 而不是单体 JSP后端用的是 Spring Boot前端用 Vue数据库 MySQL缓存走 Redis登录鉴权用 JWT。接口风格是 RESTful统一响应体长这样{ code, msg, data }。这套组合在中小型生产管理系统里非常常见原因很实际前后端分离之后车间平板、仓库扫码枪、办公室大屏都可以只接接口不用改后端。如果是单体 JSP 方案页面渲染逻辑塞在后端每加一个客户端就得重新写一套 Controller 返回 HTML维护成本高。而这套前后端分离的结构里后端只需要专注接口前端可以单独部署到任意静态服务器。表命名也能看出模块边界基础资料表以base_开头业务执行表以biz_开头计划相关表以plan_开头库存相关表以wms_开头。这个规律在排查问题时很有用看到表名基本就能判断它属于哪个模块。2.3 源码目录结构与关键配置文件的映射拿到源码包后第一件事是看目录结构确认三块内容后端工程、前端工程、数据库脚本。production-system/ ├── backend/ # Spring Boot 后端 │ └── src/main/java/com/example/production/ │ ├── controller/ # 接口层 │ ├── service/ # 业务逻辑层 │ ├── mapper/ # MyBatis 数据访问 │ ├── entity/ # 实体类 │ └── config/ # 跨域、拦截器、Redis 配置 ├── frontend/ # Vue 前端工程 │ ├── src/views/ │ │ ├── order/ # 订单管理页面 │ │ ├── plan/ # 计划管理页面 │ │ ├── workshop/ # 车间报工页面 │ │ └── report/ # 统计报表页面 └── sql/ ├── database.sql # 建库建表 ├── data_base.sql # 基础资料数据 ├── data_dict.sql # 数据字典 └── demo_data.sql # 演示数据这段目录树信息量很大controller 只做参数接收和响应封装业务都在 service 里mapper 层对应 MyBatis 的 SQL 映射别绕过去直接改 controller。sql 目录里四个脚本有严格执行顺序先建库建表再灌基础资料和数据字典演示数据和业务数据无关最后执行即可。关键配置文件在后端的application.yml里主要改三处MySQL 连接串、Redis 连接、文件上传路径。前端配置在frontend/.env.development里面有个VUE_APP_BASE_API指向后端地址。改完这两个文件系统才能连通。3. 本地跑通这套系统环境配置、建库脚本与启动参数很多人在这一步翻车因为生产管理系统牵扯的服务比普通 Demo 多一个 Redis数据库脚本也多。先确认版本再按顺序建库最后分别启动前后端这套顺序不要乱。3.1 环境要求与版本选择开发环境建议按以下版本对齐版本差太多会遇到一些莫名奇妙的依赖问题。组件推荐版本说明JDK1.8后端编译运行版本Maven3.6后端依赖管理Node.js14.x前端构建工具链MySQL8.0建库脚本按 8.0 语法编写Redis5.x缓存与 JWT 存储端口规划上后端默认 8080前端开发服务器默认 8081MySQL 3306Redis 6379。如果本机 8080 被占用后端启动会直接报端口冲突这时不用改代码启动时加一个参数覆盖就行后面会写。MySQL 8.0 和 5.7 的驱动类名不同这套源码默认走 8.0 的驱动。如果你本机是 5.7连接串里的驱动要改成com.mysql.jdbc.Driver同时删掉cj前缀否则会报 ClassNotFound 之类的错误。3.2 初始化数据库脚本顺序不能乱数据库脚本是我每次都要重点检查的部分。这套源码的脚本顺序是固定的先建库建表再灌基础数据最后补演示数据。如果跳过 data_base.sql 直接执行 demo_data.sql外键关联会失败工单引用的物料 ID 不存在。执行命令建议带上字符集参数不然会碰到中文乱码mysql -uroot -p --default-character-setutf8mb4 database.sql mysql -uroot -p --default-character-setutf8mb4 data_base.sql mysql -uroot -p --default-character-setutf8mb4 data_dict.sql mysql -uroot -p --default-character-setutf8mb4 demo_data.sql四行命令的执行逻辑很直接第一行建库建表第二行写入物料、BOM、工艺路线等基础资料第三行写入下拉框和枚举字典第四行写入一张演示用的销售订单和对应工单。每行都强制指定--default-character-setutf8mb4是为了让中文注释和业务数据落库时使用统一的 utf8mb4 编码避免出现乱码或者索引长度问题。执行完成后可以登录 MySQL 检查数据量。正常情况下物料表至少 20 条以上BOM 表 30 条以上工单表有 1 到 2 条待排产状态的数据。数据量不对就直接查日志大概率是脚本执行到一半报错中断了。3.3 启动后端与前端端口冲突排查后端启动命令很简单但有两个小坑要注意一是首次启动要联网下载依赖网络不稳定会卡在 Maven 下载步骤二是 Redis 没启动时后端会报连接异常启动直接失败。cd backend mvn spring-boot:run如果 8080 被占用用下面的方式覆盖端口mvn spring-boot:run -Dspring-boot.run.arguments--server.port8082spring-boot.run.arguments是 Spring Boot Maven 插件提供的参数透传入口作用是把--server.port8082传给应用主类等价于在 application.yml 里改server.port。这个参数在调试多个实例时特别好用不用反复改配置文件。前端启动相对简单cd frontend npm install npm run serve如果 npm install 报 node-sass 相关的错大概率是 Node 版本太高或太低换成 Node 14 再试。前端启动成功后浏览器访问http://localhost:8081登录页能出来就说明前后端至少有一半连通了。如果登录后接口报跨域错误回到前端.env.development确认VUE_APP_BASE_API是否指向http://localhost:8080。4. 生产工单的完整生命周期排产、BOM 展开与入库回写系统跑起来之后核心的验证动作是走一张工单的完整生命周期。从基础数据准备开始到排产生成执行顺序再到报工和入库回写每个环节都有对应的数据表和状态变化这也是这套源码最有学习价值的部分。4.1 基础数据准备物料、BOM 与工艺路线生产管理系统里基础数据决定上层业务能不能跑顺。物料表至少要包含物料编码、名称、规格、计量单位、默认供应商BOM 表表达的是父子件结构工艺路线表定义工序顺序和标准工时。这三张表缺一张工单都生成不了。BOM 表的核心结构大致如下CREATE TABLE production_bom ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_item_id BIGINT NOT NULL COMMENT 父物料ID, child_item_id BIGINT NOT NULL COMMENT 子物料ID, qty DECIMAL(12,4) NOT NULL COMMENT 单件用量, lost_rate DECIMAL(5,4) DEFAULT 0 COMMENT 损耗率, org_id BIGINT DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );这个表就是典型的父子结构。parent_item_id是成品或半成品child_item_id是它的直接下级物料qty表示生产一个父件需要几个子件lost_rate用于在物料需求展开时放大需求数量。实际业务里BOM 的层级可能很深比如成品下面有半成品半成品下面又有原材料所以在展开物料需求时需要用递归或循环逐层向下查。工艺路线表在生成工单时被引用报工时按工序顺序逐道确认。如果工艺路线没有维护工单虽然能建但报工页面拿不到工序列表会直接卡住。4.2 排产优先级计算交期、剩余工时与权重排产是生产管理系统里最容易被做成「玄学」的部分。这套源码的做法比较朴素给待排产工单算一个优先级分数分数越高越先排。分数由交期紧急度、已投入的工单数量、物料齐套率三个维度加权而成。public BigDecimal calcPriority(PlanOrder order, ListWorkOrder releasedOrders) { // 交期紧急度今天或之前到期的订单给 100 分权重 BigDecimal urgency order.getDeliveryDate().compareTo(LocalDate.now()) 0 ? BigDecimal.valueOf(100) : BigDecimal.valueOf(50); // 已派工数量挂起的工单越多说明车间越忙适当降低新单的插队权重 BigDecimal load BigDecimal.valueOf(releasedOrders.size()) .multiply(BigDecimal.valueOf(10)); // 物料齐套率齐套率越高越先排避免工单排下去却在等料 BigDecimal materialRate order.getMaterialReadyRate() .multiply(BigDecimal.valueOf(30)); return urgency.add(load).add(materialRate); }代码逻辑分三段看第一段urgency处理交期到期日小于等于今天的工单直接给 100 分否则只给 50 分保证快过期的单子有机会提前。第二段load用车间当前挂起工单数量乘 10意思是车间越忙系统越倾向于减少插队让已有工单先消化。第三段materialRate把齐套率换算成加权值齐套率越高分越高排下去不会因为缺料停工。实际使用时可以调整三个系数。如果工厂交期压力大把 urgency 的权重从 100 提到 150如果经常缺料把 materialRate 的权重从 30 提到 50。系数记录在配置项里比每次改代码方便。排序时把这个分数倒序排就得到了工单的执行顺序ListPlanOrder sorted orders.stream() .sorted(Comparator.comparing(this::calcPriority, Comparator.reverseOrder())) .collect(Collectors.toList());这个片段用 Stream 对订单列表按 calcPriority 的结果做降序排列。Comparator.reverseOrder()是关键参数表示从高到低把最紧急、最齐套的工单排最前面。4.3 报工与入库回写工序进度如何更新工单状态报工是车间执行的核心动作。工人完成一道工序后在系统里登记完成数量系统把这个数量累加到工单的completed_qty上同时判断工单是否全部完成。这里最容易踩坑的是数据一致性报工和入库必须是一个事务否则可能出现工单显示完成但库存没增加的尴尬情况。UPDATE production_work_order w JOIN ( SELECT work_order_id, SUM(plan_qty) AS completed_qty FROM production_report WHERE work_order_id #{workOrderId} AND status APPROVED ) r ON r.work_order_id w.id SET w.completed_qty r.completed_qty, w.status CASE WHEN r.completed_qty w.plan_qty THEN DONE ELSE RUNNING END, w.update_time NOW() WHERE w.id #{workOrderId};这段 SQL 的作用是先子查询汇总同一工单下所有已审核报工单的数量再用联表更新工单主表。CASE WHEN判断累计完成数是否达到计划数达到就把状态置为DONE否则保持RUNNING。更新update_time是为了让列表页的排序能反映出最新进度。需要注意的是status APPROVED这个过滤条件。如果报工单处于待审核状态数量不应该进入汇总否则工单还没实际完成进度就被刷上去了。很多二次开发的人会忽略这个状态过滤导致入库回写比实际进度快。在 Service 层报工审核和入库是两个动作但必须放在同一个事务方法里Transactional public void approveReport(Long reportId) { productionReportMapper.updateStatus(reportId, APPROVED); workOrderMapper.refreshCompletedQty(reportId); inventoryMapper.increaseStock(reportId); }Transactional声明事务边界三个写操作要么全部成功要么全部回滚。refreshCompletedQty执行上面那段连表更新increaseStock增加成品库存。如果这里漏掉事务注解报工审核通过但入库失败库存就和实际对不上月底盘点就要哭。5. 避坑指南环境、数据与并发场景下的五个典型坑这一章写的都是实际拆这套系统时踩过的坑不是理论推演。每条按「现象、原因、解决」给出来新手可以直接对照排查。5.1 数据库脚本报错编码、存储引擎与索引长度现象执行 database.sql 时报Specified key was too long; max key length is 767 bytes。原因MySQL 5.7 默认行格式下utf8mb4 编码里每个字符占 4 字节索引字段超过 190 个字符就会超长。脚本里某些 varchar 字段定义到了 255建索引时直接顶到上限。解决两个方向。优先把超长字段改为 128 或 64 长度如果业务上确实需要长字段就把表的行格式改成 DYNAMIC并打开innodb_large_prefixSET GLOBAL innodb_large_prefix ON; SET GLOBAL innodb_file_format Barracuda; ALTER TABLE production_bom ROW_FORMATDYNAMIC;这段 SQL 先打开大前缀开关和文件格式支持再把目标表改成动态行格式。实际操作中直接改字段长度最省事只要业务不要求在 255 字符的字段上建唯一索引。5.2 工单状态卡在待排产计划服务没跑起来现象销售订单审核通过后计划列表里看不到生成的工单或者工单一直停在待排产状态。原因这套系统的计划生成不是实时触发的而是依赖一个定时任务去扫描新订单。如果你启动后端时没启用调度配置或者 Redis 里没有对应的锁定时任务就不会执行。解决先确认后端日志里有没有计划调度的执行记录再看配置文件里 cron 表达式是否正确。常见做法是先用接口手动触发一次计划生成确认业务逻辑没问题后再回去查调度# 手动触发计划生成接口验证数据流是否正常 curl -X POST http://localhost:8080/api/plan/generate \ -H Authorization: Bearer 替换成登录返回的token \ -H Content-Type: application/json \ -d {orderId: 1}orderId是销售订单的主键 ID手动传 1 通常是对应演示订单。接口返回成功后查工单表如果有数据就说明计划逻辑正常问题出在定时任务配置上重点检查 cron 和开关。5.3 库存扣减对不上事务边界与并发锁现象两个工单同时领料时库存变成负数或者账面数和实际数对不上。原因扣库存的代码是先查库存再减数量两个请求同时查到了同一份可用库存然后各自减各自的值后提交的覆盖了先提交的结果。这就是典型的并发覆盖。解决把「查询并扣减」合并成一条原子 SQL让数据库自己判断库存是否足够UPDATE production_inventory SET available_qty available_qty - #{needQty}, update_time NOW() WHERE material_id #{materialId} AND available_qty #{needQty};关键在于AND available_qty #{needQty}这一行让数据库在扣减前自行判断可用量是否充足。如果影响行数为 0说明库存不足Java 侧应该抛出异常并回滚事务而不是继续往后面执行。5.4 报表加载慢大表全表扫与缺索引现象月度产量报表打开后要等十几秒甚至超时。原因报表模块直接对报工表和入库表做聚合统计过滤条件里用了report_date和work_order_id但这两张表上只有主键索引WHERE条件里的字段没有索引MySQL 只能全表扫描。解决给高频过滤条件加组合索引ALTER TABLE production_report ADD INDEX idx_report_date_order (report_date, work_order_id);加索引后查询会先按日期缩小范围再在日期范围内按工单 ID 过滤扫描行数从全表降到几十行。报表查询最怕的是在 SQL 里对索引字段做函数运算比如DATE_FORMAT(report_date, %Y-%m)这样索引会失效加了也白加。5.5 生产日期错位时区问题与日期格式化现象系统里录入的生产日期比实际日期少一天或者前端显示的时间和数据库存储时间不一致。原因MySQL 连接串里serverTimezoneUTC导致 JDBC 把时间按 UTC 时区存进去而本地是东八区差 8 小时。前端拿到时间戳后直接格式化没有做时区转换于是显示出来的日期就错位了。解决把连接串里的时区显式指定为上海时区jdbc:mysql://localhost:3306/production?useSSLfalseserverTimezoneAsia/ShanghaiuseLegacyDatetimeCodefalseserverTimezoneAsia/Shanghai让驱动按东八区处理时间useLegacyDatetimeCodefalse是让驱动使用新版的时间转换逻辑避免老代码里默认的 UTC 偏移。改完连接串后重启后端再录一条报工验证日期是否正常。6. 进阶玩法把流程系统改成车间真正愿意用的工具流程跑通只是第一步。这套源码真正能发挥价值的地方在于怎么通过小改造让车间主任、班组长、工人愿意天天打开它。6.1 给报工页面加移动端适配车间里的电脑通常不在工位旁边工人更愿意用平板或手机扫码报工。前端报工页面改成响应式布局核心改动只有两点把输入框改大触控友好把报工按钮固定在页面底部减少滑动。后端接口不用动因为接口本来就是 JSON 数据交换和前端展示形式无关。6.2 做一块车间看板接口轮询替代人工刷新看板是大屏显示当日工单进度。直接改报表页面的定时刷新即可前端加一个setInterval每 30 秒拉一次工单进度接口。setInterval(() { fetch(/api/work-order/progress?workshopId1) .then(res res.json()) .then(data renderBoard(data)); }, 30000);这段代码的核心参数是30000单位是毫秒表示每 30 秒刷新一次看板数据。workshopId1是车间主键 ID实际使用时要替换成当前车间的真实 ID。renderBoard函数负责把返回数据渲染到看板表格或卡片上。轮询间隔不要设太短5 秒以下会对后端造成不必要的压力30 秒足够车间使用。6.3 权限与数据字典上线前必须补的两件事这套源码虽然带了登录但接口层鉴权并不严格。上线前建议至少补两件事第一给核心接口加上角色校验注解操作员和管理员的权限边界要分清第二把数据字典里的工序状态、报工状态枚举完整过一遍该删的删、该补的补。车间现场最怕的是下拉框里出现两个意思相近的状态工人选错一次后面的数据全乱。从那以后我每次拿到这类生产管理系统源码都会强制走一遍「建库、启动、跟单、看报表」的完整流程任何一个环节卡住都不往下继续。这套系统让我最有收获的地方不是功能有多全而是它把生产管理里最核心的数据链路用一套可运行的代码完整串了起来。如果你正准备拿它做二次开发或者学习参考前期多花半小时把数据和流程摸透后面能省下好几个晚上的排错时间。希望帮到你。本文还有配套的精品资源点击获取