最近在调研制造型企业的数字化方案时，经常听到类似的困扰：公司用 Excel 或者进销存软件管生产，物料编码越加越多，订单结构越来越复杂，往往到月底才发现该买的材料没有买、该排的产没有排，库存数据和生产计划完全对不上。这种时候，很多团队的第一反应是“上一套 ERP 系统”。
但走进 ERP 选型又会发现另一个难题：商用 ERP 实施成本高、交付周期长，SaaS ERP 虽然上线快，但定制能力有限，核心数据也不在自己手里。于是越来越多人开始关注开源 ERP 方案。本文要聊的 OpenMRP，是一个在海外开发者社区被持续关注的开源制造 ERP 项目，开发周期超过 4 年。这篇文章会围绕它的定位、制造业务流程、技术架构、部署方式和上线最佳实践展开，帮助你判断这类开源 ERP 是否适合你的团队。
1. 为什么制造业需要开源ERP：OpenMRP的定位与价值
1.1 从MRP到ERP：先理解概念边界
在讲 OpenMRP 之前，有必要先把 MRP 和 ERP 这两个词理清楚。
MRP 全称是Material Requirements Planning，也就是物料需求计划。它解决的核心问题是：现有库存够不够？还差多少？什么时候需要采购？什么时候需要安排生产？
MRP 运算依赖三个核心输入：
- BOM（Bill of Materials，物料清单）：一个成品由哪些原材料/半成品组成，每个组件需要多少数量。
- 库存数据：当前可用库存、在途采购、在制数量。
- 需求数据：销售订单、预测订单、安全库存策略。
ERP 全称是Enterprise Resource Planning，企业资源计划。它是在 MRP 之上扩展出来的企业级管理系统，覆盖销售、采购、库存、生产、财务、人力资源等全链路。
所以可以这样理解：MRP 是制造业 ERP 的灵魂，ERP 是承载 MRP 及其周边业务的骨架。一个真正面向制造的 ERP，不能只做进销存，必须要把“物料需求计算”这个能力做扎实。
1.2 商用ERP与开源ERP的取舍
国内企业接触比较多的 ERP，通常有用友、金蝶、简道云 ERP、星云 ERP 这类产品。它们各有优势：实施服务体系成熟、行业模板丰富、财务模块往往很强。但也要客观看待商用 ERP 的普遍问题：
- 实施成本高：软件授权、实施服务、二次开发费用加起来，对中小制造企业是笔不小的预算。
- 定制响应慢：制造企业的工艺路线、计件工资、质检规则差别很大，标准功能往往不能完全匹配。
- 数据自主权受限：SaaS 模式下数据存储在服务商侧的平台上，退出成本高。
开源 ERP 的价值恰好体现在这几个方面：源码开放，可以按企业业务做定制；没有 License 费用，降低起步门槛；数据自主控制，适合对数据安全要求高的制造企业。
OpenMRP 就是这样一个面向制造场景的开源 ERP 系统。它最大的标签不是“免费的 ERP”，而是“长期维护的开源制造 ERP”。
1.3 OpenMRP项目的核心定位
从项目标题可以看出，OpenMRP 已经经历超过 4 年的持续开发。这个时间长度在开源项目里其实很能说明问题。
企业级软件和开源工具不同，它需要覆盖真实业务场景，经过大量需求打磨。很多开源项目活跃一两年就停止维护了，而一个制造 ERP 能持续迭代 4 年，意味着它背后已经有明确的维护节奏和真实用户反馈。
OpenMRP 的定位可以归纳为三点：
- 面向制造业：核心能力围绕 BOM、物料需求计算、工单、采购、库存展开，而不是做一个通用进销存。
- 开源可定制：企业可以基于源码进行二次开发，扩展工序、计件、质检等特殊业务。
- 长周期演进：4 年积累迭代出来的是相对完整的模块体系和数据结构，不是教学 Demo。
2. 制造ERP的核心业务流程与功能模块
2.1 制造企业ERP的标准流程环
要判断一个开源 ERP 是否适合生产制造场景，先要看它能不能跑通制造企业最核心的业务闭环：
销售订单 → 主生产计划 → MRP运算 → 生产工单 + 采购计划 ↑ ↓ 财务核算 ← 成品发货 ← 完工入库 ← 车间领料/报工 ← 采购到货这个循环里每一步都会产生数据联动：
- 销售订单录入后，系统要能锁定商品库存。
- 库存不足时，MRP 运算要能自动拆出“生产建议”和“采购建议”。
- 生产建议转成生产工单后，按 BOM 展开生成“用料计划”。
- 车间领料时，系统扣减原材料库存；报工完工后，系统增加成品库存。
- 采购到货、质检合格后，原材料库存得到补充。
- 发货后触发应收，采购入库后触发应付，成本数据归集到财务模块。
如果一套 ERP 只能管理“进出存”，不能自动计算“缺什么、什么时候缺、需要买多少、需要做多少”，那它本质上还是进销存，不是面向制造的 ERP。
2.2 OpenMRP的核心模块清单
围绕上面这个业务闭环，一个成熟的制造 ERP 至少需要以下模块：
| 模块 | 核心功能 |
|---|---|
| 物料管理 | 料号编码、品名规格、分类、多计量单位、批次/序列号 |
| 产品数据 | BOM 维护、BOM 版本管理、工艺路线 |
| 销售管理 | 报价单、销售订单、发货、应收 |
| 采购管理 | 采购申请、采购订单、到货、质检、应付 |
| 库存管理 | 出入库、盘点、调拨、库存锁定、库存台账 |
| 生产管理 | 工单、派工、领料、报工、完工入库 |
| 财务管理 | 成本核算、应收应付、凭证 |
| 报表看板 | 库存周转、订单履约、生产进度、采购到货 |
对于 OpenMRP 这类开源制造 ERP，最值得关注的仍然是生产域和物料域是否完善。因为销售、采购、库存这些通用能力，开源界和商用软件都有较成熟方案，但真正贴合车间作业场景的 MRP 运算和工单管理，才是最考验项目功力的地方。
2.3 与传统进销存系统的区别
很多中小制造企业早期用的是进销存管理软件，它能记录“材料入库、成品出库、库存查询”，但回答不了这三个计划类的问题：
- 这个订单需要什么时候开始生产？
- 按照现有库存，我还缺多少原材料？
- 如果供应商交期是 7 天，我应该在什么时间下达采购订单？
进销存软件没有 BOM 展开能力和需求计算能力，这些问题只能靠人工在 Excel 里算。OpenMRP 这类制造 ERP 的价值，就是把“人工算料”变成“系统自动算料”，这也是 ERP 与进销存最本质的差别。
3. 技术架构与项目演进视角
3.1 常见的开源ERP技术栈
由于 OpenMRP 的具体技术栈需要以官方仓库的 README 为准，这里从开源 ERP 的技术选型共性出发，梳理一套典型的开源制造 ERP 技术架构。
一个适合制造企业的开源 ERP 通常采用前后端分离架构：
- 后端：常见选择是 Java/Spring Boot、Python/Django、Node.js/NestJS。Spring Boot 在企业级应用中更常见，因为生态成熟、事务管理完善；Python/Django 的优势是开发效率高，适合快速迭代。
- 前端：B 端管理后台常用的有 Vue 3 + Element Plus、React + Ant Design。国内团队对 Vue 生态更熟悉，上手成本低。
- 数据库：PostgreSQL 或 MySQL。制造业 ERP 涉及大量关联查询和复杂事务，PostgreSQL 在复杂 SQL 和 JSON 扩展上更有优势。
- 缓存与任务队列：Redis 用于缓存和分布式锁，Celery 或 RabbitMQ 用于异步任务，比如批量 MRP 运算、报表导出、消息通知。
- 部署：Docker Compose 适合中小团队单机/小集群部署，Kubernetes 适合更大规模场景。
下面是这类开源 ERP 常见的目录结构：
openmrp/ ├── backend/ │ ├── apps/ │ │ ├── mrp/ │ │ ├── sales/ │ │ ├── purchase/ │ │ ├── inventory/ │ │ ├── production/ │ │ └── finance/ │ └── core/ ├── frontend/ │ ├── src/ │ │ ├── views/ │ │ ├── components/ │ │ └── api/ ├── docs/ └── docker-compose.yml模块按业务域拆分，而不是把所有功能塞在单一大目录里，这是企业级系统与个人项目的重要区别。
3.2 为什么“4年”对开源ERP很重要
很多人看到 4 年开发周期，第一反应是“这项目是不是太慢了”。但站在企业级软件的角度，4 年恰恰是一个加分项：
- 数据库结构经得起真实业务推敲。第一版数据结构在落地后往往需要调整，持续迭代意味着表结构、字段设计已经经过多轮重构，比全新系统稳定。
- 权限模型和审批流经过了打磨。权限和审批是 ERP 上线时的隐形门槛，这类设计很难一次性做对，需要在不同企业场景里不断磨合。
- 模块度更高。项目从单模块扩展到多模块之后，自然会产生“核心基础数据、业务交易数据、报表数据”的层级划分，二次开发更容易定位落点。
- 社区和文档积累更多。开源软件最怕“网上连个解决方案都搜不到”，4 年项目通常积累了较完整的部署文档、常见问题记录和社区讨论。
3.3 模块化与可扩展性设计
对于打算引入 OpenMRP 的团队，要在选型阶段重点看三个可扩展性设计：
第一，基础数据和交易数据是否分离。物料、BOM、客户、供应商这些是基础数据，销售订单、采购订单、工单属于交易数据。两类数据如果混在一个表里，后续报表和审计会非常痛苦。
第二，是否预留接口层。现代制造企业周边通常有 MES、WMS、电子发票平台，ERP 需要与这些系统对接。有没有 REST API 或消息队列事件，直接决定后续集成的成本。
第三，二次开发是否安全。最怕的是为了改一个需求直接改动核心表。优秀的开源项目会鼓励通过扩展模块或 API 层实现定制，保持核心代码稳定。
4. 本地部署实战：从源码到可运行系统
这一节演示的是开源 ERP 最常见的部署模式：后端应用 + 前端应用 + PostgreSQL + Redis。OpenMRP 的具体命令请以官方文档为准，下面重点讲清楚部署思路与关键验证点。
4.1 环境准备
在开始部署之前，需要准备好以下基础环境：
- Linux 服务器或本地开发机，推荐 Ubuntu 22.04
- Docker 与 Docker Compose
- Git
- 浏览器（用于访问前端页面）
如果你需要本地二次开发环境，还需要安装对应技术栈的运行时，例如：
# 示例：如果后端基于 Python，需要 Python 3.10+ python3 --version # 如果后端基于 Node.js，需要 Node 18+ node -v # 如果后端基于 Java，需要 JDK 17+ java -version版本需要根据你实际拉取的项目代码调整，以仓库 README 为准。
4.2 获取项目源码
通过 Git 克隆项目到本地目录：
git clone <你的OpenMRP仓库地址> cd openmrp如果你只是体验功能，不需要二次开发，推荐直接使用 Docker Compose 启动整套环境。
4.3 初始化数据库
企业级 ERP 首次启动时需要创建数据库、执行迁移脚本、初始化基础数据。
PostgreSQL 创建数据库的通用命令：
CREATE DATABASE openmrp; CREATE USER openmrp WITH PASSWORD 'your_strong_password'; ALTER ROLE openmrp SET client_encoding TO 'utf8'; ALTER ROLE openmrp SET default_transaction_isolation TO 'read committed'; GRANT ALL PRIVILEGES ON DATABASE openmrp TO openmrp;执行数据库迁移的通用命令模式如下：
# Python/Django 项目 python manage.py migrate # Node.js 项目 npm run db:migrate # Java/Spring Boot 项目 ./mvnw flyway:migrate迁移的含义是把项目中的数据结构定义同步到数据库，比如创建表、字段、索引。
4.4 使用 Docker Compose 启动应用
如果你的项目提供了 docker-compose.yml，可以通过以下命令启动：
docker compose up -d一个典型的 ERP 环境编排文件结构如下：
version: "3.8" services: postgres: image: postgres:16-alpine container_name: openmrp-postgres environment: POSTGRES_DB: openmrp POSTGRES_USER: openmrp POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pgdata:/var/lib/postgresql/data ports: - "5432:5432" healthcheck: test: ["CMD-SHELL", "pg_isready -U openmrp"] interval: 5s timeout: 5s retries: 5 redis: image: redis:7-alpine container_name: openmrp-redis ports: - "6379:6379" openmrp: build: . container_name: openmrp-app depends_on: postgres: condition: service_healthy redis: condition: service_started environment: DATABASE_URL: postgres://openmrp:${DB_PASSWORD}@postgres:5432/openmrp REDIS_URL: redis://redis:6379/0 APP_PORT: 8080 ports: - "8080:8080" volumes: - ./data:/app/data volumes: pgdata:.env 环境变量文件示例：
DB_PASSWORD=change_me_before_production启动之后，用以下命令查看容器状态：
docker compose ps如果所有服务都处于 healthy/running 状态，说明应用已经正常启动。
4.5 浏览器验证
打开浏览器访问：
http://localhost:8080通常会出现登录页面或者初始化设置页面。首次登录后，系统会引导你创建管理员账号、设置公司基本信息，这是企业级系统第一次初始化时最常见的流程。
部署验证清单：
- [ ] 数据库容器是否健康运行
- [ ] Redis 是否可连接
- [ ] 后端应用日志是否报错
- [ ] 前端页面是否可以正常加载
- [ ] 能否完成管理员账号创建
- [ ] 能否进入主界面
5. 初始配置与基础数据准备
很多 ERP 项目上线失败，根源不在软件本身，而是基础数据没准备好。制造企业在正式使用 OpenMRP 前，需要先把以下基础数据整理好。
5.1 公司参数设置
开始录入业务数据之前，先配置公司层面的信息：
- 公司名称、地址、税号
- 本位币（人民币或美元）
- 会计期间（自然月或自定义期间）
- 默认税率
- 库存计价方式（移动平均、先进先出、标准成本）
这些参数会影响后续所有业务单据的金额计算，建议由财务负责人参与确认。
5.2 物料主数据与单位管理
物料主数据是制造业 ERP 的基石。一个物料至少需要以下属性：
- 料号：唯一编码，建议使用有规律的编码规则，例如“原材料-R-001”
- 品名规格：完整描述物料
- 物料分类：原材料、半成品、成品、辅料
- 计量单位：件、个、千克、米
- 默认仓库
- 采购属性：默认供应商、采购提前期
- 生产属性：默认工序、是否自制
如果需要批量导入，通常支持 CSV 格式，字段结构可以参考：
item_code,item_name,specification,category,unit,default_warehouse,is_purchased,is_manufactured R-001,Q235钢板,2mm*1250*2500,原材料,张,原材料仓库,true,false FG-001,设备支架,Q235焊接件,半成品,件,半成品仓,false,true导入前一定要做数据清洗：
- 检查料号是否重复
- 检查单位是否统一
- 检查同一种物料是否被录成多个不同名称
5.3 BOM结构的建立
BOM 是 MRP 运算的核心依据。一个简单的 BOM 示例：
成品“设备支架总成”由以下组件构成：
- 1 件 设备支架（自制件）
- 2 个 M8 螺栓（外购件）
- 1 个 垫片（外购件）
- 0.5 千克 焊丝（辅助材料）
在系统中，需要把子件和用量逐一录入，并且指定“发料方式”和“损耗率”。
BOM 维护最常见的问题是版本管理。例如旧版本 BOM 用 2 个螺栓，新版本改成 4 个螺栓，那么：
- 已经下达的旧生产工单，继续按旧 BOM 领料。
- 新下达的工单，按新 BOM 领料。
- 系统里要能保留历史 BOM 版本，不能直接覆盖。
5.4 库存期初录入
系统正式启用之前，需要把当前仓库里的实际库存录入系统，作为期初数据。
常见做法是：
- 仓库盘点，获取实盘数量。
- 整理成 Excel 导入模板。
- 系统导入后，做一次“期初库存盘点单”过账。
- 财务同步确认期初库存金额。
期初数据如果不准确，后续所有 MRP 运算都会失真，所以在正式业务开始前，务必确保库存准确率接近 100%。
5.5 用户与权限设置
制造 ERP 涉及生产、采购、销售、财务多个部门，必须做好权限隔离。
建议按照“最小权限原则”设计角色：
| 角色 | 核心权限 |
|---|---|
| 系统管理员 | 系统配置、用户管理、基础数据 |
| 销售专员 | 销售订单、发货单、客户管理 |
| 计划员 | MRP运算、生产工单、采购申请 |
| 采购专员 | 采购订单、采购到货、供应商管理 |
| 仓库管理员 | 出入库、盘点、库存查询 |
| 车间主任 | 工单执行、领料、报工、完工入库 |
| 财务人员 | 应收应付、成本核算、凭证 |
| 厂长/总经理 | 全部报表查询，不开放业务单据修改权限 |
6. 制造业务闭环示例：从订单到发货
这一节演示一个典型的制造业务闭环，帮助你理解 OpenMRP 这类系统在真实场景中的工作方式。
6.1 销售订单创建
客户下达订单：购买 100 台设备支架总成，交付日期为 15 天后。
系统操作路径：
- 选择客户。
- 录入产品“设备支架总成”，数量 100，单价 500 元。
- 确认交期。
- 系统自动检查可用库存：当前成品库存 30 台，可用 30 台，缺口 70 台。
- 订单提交后，系统给出提示：“库存不足，请安排生产计划”。
在这个过程中，系统已经将“可用库存锁定”了可发货的 30 台部分，避免被其他订单重复占用。
6.2 MRP运算与计划建议
计划员运行 MRP 运算模块，系统按以下逻辑展开计算：
- 判断净需求：需求 100 - 可用库存 30 - 在制数量 0 = 净需求 70。
- 展开 BOM：70 台成品需要 70 件 设备支架 + 140 个 螺栓 + 70 个 垫片 + 35 千克 焊丝。
- 判断每个组件的现有库存情况。
- 生成计划建议：
- 生产工单：70 台 设备支架总成。
- 采购建议：根据材料库存缺口，生成螺栓、垫片、焊丝的采购计划。
下面给出一个简化版 MRP 净需求计算 SQL 示例，帮助理解核心运算逻辑。注意：这仅用于理解 MRP 思路，不是 OpenMRP 的实际查询代码。
-- 简化版净需求计算逻辑 SELECT bom.parent_item_id, bom.component_item_id, bom.quantity_per_unit, COALESCE(SUM(inventory.on_hand_qty), 0) AS available_qty, demand.demand_qty, (demand.demand_qty * bom.quantity_per_unit - COALESCE(SUM(inventory.on_hand_qty), 0)) AS net_requirement FROM bom LEFT JOIN inventory ON inventory.item_id = bom.component_item_id LEFT JOIN ( SELECT item_id, SUM(quantity) AS demand_qty FROM sales_order_line WHERE status = 'confirmed' GROUP BY item_id ) demand ON demand.item_id = bom.parent_item_id GROUP BY bom.parent_item_id, bom.component_item_id, bom.quantity_per_unit, demand.demand_qty;真实系统中的 MRP 还要考虑在途采购、安全库存、批量规则、提前期、供应商交期等因素，比上面这个简化 SQL 复杂得多，但基本逻辑是一致的：需求 × 用量 - 可用库存 = 净需求。
6.3 生产工单下达与领料
计划员审核生产建议后，将建议转成生产工单：
- 工单编号：MO-2025-001
- 产品：设备支架总成
- 数量：70 台
- 计划开工日期：明天
- 计划完工日期：第 10 天
工单下达后，车间按工单领料：
- 领 70 件 设备支架
- 领 140 个 螺栓
- 领 70 个 垫片
- 领 35 千克 焊丝
系统扣减原材料库存，并生成“在制量”，在制品数量会参与后续 MRP 计算，避免重复采购。
6.4 车间报工与完工入库
车间每天报工，登记每个工序的完成数量、工时、不良数量。
例如：
- 工序 1：切割/焊接，完成 70 台，用时 8 小时
- 工序 2：组装，完成 70 台，用时 6 小时
- 工序 3：检验，合格 70 台，不良 0
全部工序完成后，执行“完工入库”，系统增加 70 台成品库存。此时成品库存变为 30 + 70 = 100 台，可以满足客户订单。
6.5 发货与财务核算
仓库根据销售订单做发货：
- 发货数量：100 台
- 发货后成品库存清零
- 系统生成发货单，财务确认应收 50000 元
采购模块完成材料入库后，财务确认应付。生产成本归集后，可以查看这批订单的实际毛利：
销售额：100 × 500 = 50000 元 材料成本：xx 元 人工成本：xx 元 制造费用：xx 元 毛利：xx 元一个完整的“接单 - 计划 - 采购 - 生产 - 发货 - 核算”闭环，就是制造 ERP 每天的核心工作。
7. 常见问题与排查思路
无论选择 OpenMRP 还是其他开源 ERP，在上线和日常使用中都会遇到下面这些问题。
7.1 部署阶段常见问题
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 数据库连接失败 | 连接地址或密码配置错误 | 检查 DATABASE_URL，使用 psql 单独测试连接 |
| 端口占用 | 8080 或 5432 已被其他程序占用 | 换端口或停止占用进程 |
| 页面能打开但接口 500 | 数据库迁移未执行 | 重新执行 migrate 命令 |
| 登录后权限异常 | 首次登录后未正确初始化管理员角色 | 进入系统设置，检查管理员权限 |
| Redis 连接超时 | Redis 服务未启动或地址错误 | 检查容器状态，确认 REDIS_URL |
排查数据库连接问题，可以先在宿主机上执行：
psql "postgres://openmrp:密码@localhost:5432/openmrp" -c "SELECT 1;"如果这个命令能返回1，说明数据库连接没问题，问题大概率出在应用配置上。
7.2 业务数据阶段常见问题
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| MRP算出的采购数量偏大 | BOM用量错误或库存数据不准 | 检查BOM子件用量，重做库存盘点 |
| 库存出现负数 | 发货/领料时未审核销售或工单，库存被重复扣减 | 检查单据审核状态，做库存调整单 |
| 料号重复 | 导入模板没有做唯一性校验 | 导入前用Excel去重，数据库增加唯一索引 |
| 单位换算错误 | 同一物料存在多个单位但未配置换算率 | 在物料主数据中维护单位换算关系 |
库存数据不准确是制造业 ERP 最常见的问题。建议每周做循环盘点，重点核对高价值物料和动态频繁的物料。不要等到月末才发现问题，那时查找原因的工作量会非常大。
7.3 运维阶段常见问题
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 备份恢复失败 | 备份文件不完整或版本不匹配 | 定期做恢复演练，备份要区分数据文件与代码版本 |
| 系统响应变慢 | 报表查询未走索引，或者数据量增长后未优化 | 使用慢查询日志定位SQL，补充索引 |
| 升级后功能异常 | 跳过版本升级，或未执行增量迁移脚本 | 严格按版本顺序升级，升级前备份 |
| 外系统对接失败 | API 接口变更或网络策略隔离 | 检查接口文档，确认网络白名单 |
开源 ERP 系统上线后，运维一定要做到两件事：
- 每日备份，每周恢复演练。
- 升级前先看 upgrade 文档，不要跳版本。
8. 开源ERP的上线建议与最佳实践
8.1 先梳理业务流程再考虑系统功能
很多企业犯的错误是：软件还没选，先要求系统按现有习惯来。实际上更合理的顺序是：
- 画出企业现在的业务流程图（现状）。
- 标出哪些环节是卡点、哪些数据是靠人工传递的。
- 设计“系统化之后”的目标流程（未来）。
- 再拿目标流程与 ERP 功能做匹配。
制造业还有一个现实问题：不同部门的编码习惯完全不一样。仓库叫“钢板”，采购叫“Q235板材”，财务叫“原材料”。如果不统一物料编码和命名规则，系统上线第一天就会数据混乱。
8.2 数据治理是上线成功的关键
制造 ERP 的数据治理要重点盯三块：
物料主数据。建议由专人负责，制定编码规则，审核新物料创建。料号一旦使用，不轻易删除，通过“禁用”控制。
BOM 准确率。BOM 不准，MRP 算出来的所有计划都不可信。建议新 BOM 在下发生产前，由工艺部门做一次“试算确认”。
库存准确率。期初盘点要细致，日常出库要及时录入，定期做循环盘点。
8.3 权限、审批与操作日志
开源 ERP 开放性强，更要注意权限边界。
- 每个账号只配置完成岗位工作所需的最少权限。
- 敏感操作（修改单价、删除单据、作废工单）必须走审批流程。
- 开启操作日志，记录谁在什么时间改了哪个单据、改了什么字段。
在 SQL 层面，还可以补充行级权限。也就是说，仓库主管只能看到自己仓库的库存数据，销售经理只能看到自己团队的客户和订单。这类数据隔离在制造企业中非常重要。
8.4 备份、升级与安全
生产环境一定要重视以下事项：
| 事项 | 推荐做法 |
|---|---|
| 数据库备份 | 每日自动全量备份，异地保存一份 |
| 恢复演练 | 每月至少执行一次真实恢复演练 |
| 服务器安全 | 不开放数据库端口到公网，使用防火墙白名单 |
| 密码策略 | 强制强密码，禁止共用超级管理员账号 |
| 代码版本 | 生产环境部署锁版本，不随便拉最新代码 |
升级前至少要在测试环境完整跑一遍，尤其是数据库迁移脚本。不要在数据未备份时直接在生产环境升级。
8.5 二次开发的取舍
开源 ERP 最大的价值在于可二次开发，但也要谨慎取舍。
推荐通过扩展方式开发：
- 新增独立的扩展模块，不修改核心表。
- 通过 API 与外部系统对接。
- 前端组件化，新功能优先做成独立页面。
不推荐直接修改核心代码：
- 直接修改核心业务表结构，升级时容易冲突。
- 在核心代码里写死企业特有逻辑，导致后续项目无法共用。
制造业企业的差异点通常集中在：工序管理、计件工资、质检规则、条码管理。这些功能应在二次开发模块里实现，而不是改乱核心流程。
9. 总结与选型建议
OpenMRP 这类开源制造 ERP，真正适合的场景是：企业有内部研发团队，愿意投入时间做定制化适配，同时希望掌握核心数据和系统源码。它在制造业务建模、物料需求计划、BOM 管理、工单管理上的价值，远比通用进销存软件更适合制造企业。
选型时建议按以下步骤走：
第一步，先看业务流程闭环。把手头的成品订单、BOM、原材料库存、供应商资料整理成一套测试数据，在系统里走一遍从销售订单到发货的完整流程，看系统是否顺畅。
第二步，看二次开发成本。尝试通过 API 对接一个简单的第三方系统，评估接口文档质量和开发体验。
第三步，参考社区活跃度。看最近一年的提交记录、Issue 回复速度、文档更新频率。开源项目最怕的不是功能少，而是维护停滞。
第四步，评估团队能力和实施节奏。没有专职 IT 的团队，直接上开源 ERP 风险较大，建议先咨询有实施经验的顾问团队，或者先在测试环境跑两到三个月，再决定是否全面上线。
制造业数字化转型并不一定等于购买昂贵的商用 ERP。把业务流程想清楚，把数据基础打扎实，选择一个像 OpenMRP 这样可掌控、可持续迭代的开源方案，同样可以走出一条适合自己企业的落地路径。如果你所在的公司正处于“进销存不够用、商用 ERP 又太贵”的阶段，不妨先下载一份 OpenMRP 源码，在本地跑通流程，用真实业务数据验证它的能力边界。
