开源 S-PMS 拆解：生产订单、领料报工与入库出库，怎么在一套 Spring Boot 里跑通

中小制造团队最痛的不是「有没有系统」，而是车间工单在一套软件、库房台账在另一套 Excel、采购销售又各开一张表。数据对不上、库存虚高、报工与入库脱节，最后只能靠人工对账。商业 MES / WMS 动辄几十万起步，二次开发还被厂商卡死；自己从零写又养不起一支全栈团队。

S-PMS（Smart Production Management System，智能生产管理系统）把这件事换了个思路：用 MIT 协议开源一整套「制造执行 + 仓储 + 渠道 + 设备采集」底座，后端 Java 17 + Spring Boot 3 + JPA + MySQL 8 + Redis，前端 Vue3 + Vite + TypeScript（AirPower4T），另有 UniApp 移动端与 Docker 一键部署仓。官方仓库在 s-pms/SPMS-Server、SPMS-Web、SPMS-Docker，演示站 spms.hamm.cn。本文基于官方 README、Docker 编排与 Server 源码模块目录做深度拆解——源微信页抓取失败时，以仓库与代码为准，不臆造功能。

一、S-PMS 是什么：不是「又一个后台 CRUD」，而是五块业务拼成的生产中台

官方定位很直白：集成 MES（制造执行）、WMS（仓库管理）、ERP 风格渠道与资源、QMS 质量相关活动，以及 IoTS（物联网采集）。落到代码里，包路径 cn.hamm.spms.module.* 比口号更有说服力：

底座依赖作者另一套框架 AirPower4J（后端）与 AirPower4T（前端）：统一 CRUD、单据基类 BaseBillController、权限与编码规则等，业务模块主要写「领域单据 + 状态流转」，而不是从零搭脚手架。

作者在文档里写得很清楚：为爱发电，精力有限，不承诺无偿技术支持。开源适合能自己读代码、愿意二次开发的团队；别把它当成「买了就能交钥匙」的商业交付。

和「只做库存的开源 WMS」或「只做工单的轻量 MES」相比，S-PMS 的差异在于：生产订单完成态可以直接衔接到入库单据，领料又回扣库存——同一套用户、权限、物料主数据，避免双系统主数据漂移。

二、模块对照：MES 管「怎么造」，WMS 管「货在哪」

MES：从计划到报工的闭环

OrderController 上挂的不只是增删改查，还有明确的车间动作：

• start / pause：开始生产、暂停生产
• addOrderDetail：订单报工
• setBillDetailsAllFinished：手动标为「生产完成待入库」（受系统配置 ORDER_MANUAL_FINISH 开关约束）

周围还有 生产计划（Plan）、BOM、工序（Operation）、生产工艺 / 工序配置（Routing）、领料单（Picking）。工艺路线把工序串起来，BOM 决定物料消耗，领料单把「计划用量」变成对仓库的真实扣减请求——这才是 MES 与 WMS 必须同库的原因。

WMS：入库、出库、移库、库存四件套

module.wms 四个 Controller 对应中文业务名就是：入库、出库、移库、库存。工厂侧 StorageController（仓库）、StructureController（生产单元）提供库房与产线组织主数据。单据继承 BaseBillController，明细行独立 Entity/Service，和 MES 订单同一套「单据 + 明细」范式，二次开发时心智负担更低。

渠道与设备：把采购销售、设备采集接进来

channel 包覆盖采购单、销售单、客户、供应商及采销价格查询；asset.device 提供设备实时采集、采集配置与参数历史——配合 iot.parameter 与配置里的 MQTT / InfluxDB，可以把产线传感器写进同一套系统，而不是另起时序中台。

三、技术栈与仓库分工：Server / Web / App / Docker

本地开发（非 Docker）官方推荐路径大致是：

# 后端（Gitee 镜像通常更快）
git clone https://gitee.com/s-pms/SPMS-Server.git
# IDEA 打开后刷新 Maven；复制 application-template.yml → application-local.yml

# 前端
git clone https://gitee.com/s-pms/SPMS-Web.git
cd SPMS-Web && yarn && cp .env.dev .env && yarn s

配置模板里需要你自己填：MySQL、Redis、邮件，以及物联网相关的 MQTT / InfluxDB。JPA 的 ddl-auto 开发可用 update；上生产务必改为 validate，先导出稳定库结构再导入——README 专门警告不要把 create-drop 带到生产。

前端 .env 关键三项：

VITE_APP_NAME = "开发环境"
VITE_APP_API_URL = "/api/"
VITE_APP_STATIC_URL = "/static/"

Windows 开发者建议用 Git Bash 跑克隆脚本；VS Code 请关掉 Vetur，避免 Vue2/Vue3 插件打架。AI 辅助改代码时，务必把各仓的 AGENT.md 与官方 Docs 丢进上下文，否则生成的 Controller / Entity 很容易偏离 AirPower 的单据基类约定。

四、Docker 一键部署：命令、端口与排坑

体验环境优先走 SPMS-Docker。deploy.sh 会克隆 Web/Server，检查 Docker / docker-compose，带重试拉取基础镜像（失败时尝试国内 registry），再 docker-compose up 构建。

git clone https://github.com/s-pms/SPMS-Docker.git
cd SPMS-Docker
chmod +x deploy.sh
./deploy.sh
# 需要清空库与缓存卷时：
./deploy.sh --clean

当前仓库里的 docker-compose.yml 端口映射（以 compose 文件为准，勿盲信旧 README 数字）：

默认 compose 里 MySQL 环境变量示例：MYSQL_DATABASE=spms、MYSQL_USER=spms、MYSQL_PASSWORD=spms、root 密码 root——仅适合内网试用，上线必须改密并限制端口暴露。Server Dockerfile 采用多阶段：maven:3.9.6-amazoncorretto-17 打包，再丢进 amazoncorretto:17-alpine 运行 app.jar。

排坑清单：

1. 首次构建很慢：要拉 Maven 依赖 + 构建前端，磁盘与内存不够时 Web 构建已预留 NODE_OPTIONS=--max-old-space-size=4096。

2. README 与 compose 端口不一致：以 docker-compose.yml 为准访问 http://localhost:18080。

3. 数据卷：日常 docker-compose down 保留卷；只有确认要重置时才 --clean / -v。

4. 演示站 ≠ 最新代码：官方提醒 spms.hamm.cn 可能落后，关键功能以自建为准。

五、和「单点开源 MES / WMS」怎么选？

选型口诀：若你卡在「报工完还要人工开入库单、Excel 对库存」，优先评估 S-PMS；若你已有成熟 ERP、只缺立体库波次与 AGV 对接，可能更该看专业 WMS；若只要离散车间看板、不管库房，轻量 MES 更轻。

二次开发建议：先读各仓 AGENT.md 与 SPMS-Docs，让 Cursor / Copilot 按项目约定生成代码，减少风格漂移。开放能力上已有 OAuth、开放应用、通知钩子，甚至 MCP 工具列表接口——方便把生产数据挂到 AI Agent 工作流，但这仍属扩展面，上线前务必做权限与审计设计。

六、写在后面：开源能省授权费，省不掉「业务建模」

S-PMS 解决的是「有没有一套可读、可改、可商用协议友好的一体化代码」；解决不了你们厂特有的工艺例外、委外、批次追溯规则——那些仍然要产品经理和开发一起在 BOM、工艺、单据状态机上建模。MIT 意味着可以商用与改闭源衍生，但也意味着社区没有 SLA。

建议落地路径：Docker 先在内网跑通「生产订单 → 报工 → 入库 → 库存查询」最小闭环 → 再导入真实物料与仓库主数据 → 最后才接 MQTT 设备与开放 API。源码与文档以 GitHub/Gitee 的 s-pms 组织为准；本文参考的微信分享链仅作选题来源，正文技术事实均核对自官方仓库。

仓库入口：

• Server：https://github.com/s-pms/SPMS-Server
• Web：https://github.com/s-pms/SPMS-Web
• Docker：https://github.com/s-pms/SPMS-Docker
• 交流 QQ 群（官方 README）：773726377
  )