ERPNext 开源部署与流程定制：中小团队自建进销存与业务核算指南

三个人共用一张 Excel 表管进货、出货和应收，月底一对账就发现仓库说货发了、财务说没收到；销售在群里问“这单还能不能改”，采购翻聊天记录找上次的报价——这是很多中小团队考虑上 ERP 的真实起点。商业 ERP 的授权和实施费用不低，流程稍微特殊一点还要额外付费定制，于是越来越多人把目光转向开源方案。ERPNext 是其中讨论度较高的一个：它基于 Python 的 Frappe 框架开发，把会计、销售、采购、库存、制造、CRM 等模块放在同一套系统里，采用 GPL v3 许可证，可以免费商用和修改。但“能下载”不等于“能上线”，中小团队真正容易卡住的地方，往往在部署后的主数据设计、权限流转和财务初始化。下面按实际实施顺序，把这条路径拆开讲清楚。

先判断：ERPNext 适合什么样的团队

ERPNext 的定位不是“装完就能用”的轻量工具，而是一套需要配置的业务系统。它的优势在于业务对象和流程可以改：自定义字段、自定义表单、工作流、权限规则、打印格式和报表都能在系统内完成，不一定上来就改源码。对于贸易、批发、小型制造、工程服务这类流程有自己习惯的团队，这种灵活性比功能数量更有价值。

反过来，如果团队没有一个人愿意接触服务器、Docker 和后台配置，或者业务只需要开单记账、完全不想维护系统，那么托管型 SaaS 或更轻量的进销存工具可能更省心。ERPNext 省下的是许可费，换来的是部署和运维责任，这笔账要在开始前算清楚。

部署前的环境准备

正式动手前，先把几件事定下来，后面能少返工：

服务器：仅做功能验证，2 核 4GB 可以跑起来；正式使用建议 4 核 8GB 以上，数据库和文件存储分开规划。ERPNext 的 MariaDB、Redis、后台 worker 都会占内存，配置太紧会在导入数据或生成报表时明显变慢。
域名与 HTTPS：提前准备好域名解析。生产环境不要长期用 IP 加端口访问，后面配置邮件、Webhook 和用户登录都会受影响。
时区与货币：在系统设置和公司资料里统一时区、默认货币和汇率规则。很多“单据日期差一天”的问题，根源是服务器用 UTC、公司时区没设。
备份位置：准备一个和服务器不同机器的存储位置。备份文件放在同一台云服务器上，等于没有异地备份。
Docker 与 Compose：官方维护的 frappe_docker 仓库提供了容器化部署方式，适合不想手工装 MariaDB、Redis、Node 依赖的团队。生产环境还需要反向代理和 HTTPS 证书。

用 Docker 跑起第一套环境

容器化部署的核心思路是：数据库、Redis、后端应用、前端、后台 worker 和调度器分别跑在容器里，通过 Compose 组织起来。具体用哪个 compose 文件、镜像标签怎么选，以仓库当前 README 为准，因为不同版本的目录结构和默认值会变化。下面是一个示意流程：

git clone https://github.com/frappe/frappe_docker.git
cd frappe_docker
cp example.env .env
# 编辑 .env：设置数据库 root 密码、站点名、时区等
# 按 README 选择单机或生产 compose 文件后启动
docker compose -f <compose文件> up -d

容器起来后，再创建站点并安装 ERPNext 应用。下面命令中的站点名、密码和参数名请结合当前版本 bench 的帮助确认：

docker compose exec backend bench new-site erp.example.com 
  --mariadb-root-password "$DB_ROOT_PASSWORD" 
  --admin-password '替换为强密码' 
  --install-app erpnext

第一次启动阶段，建议一边看日志一边操作：

docker compose logs -f backend db

如果容器反复重启，先不要急着改配置，优先确认数据库密码在 .env 和站点配置里是否一致、数据卷权限是否正常、服务器内存是否被耗尽。ERPNext 的部署问题里，很大一部分不是应用本身，而是环境变量和网络配置对不上。

站点能登录之后，不要马上让业务人员录入真实单据。先用一个测试公司走一遍“采购收货—入库—销售发货—开票—收款”的完整链路，确认库存数量、应收金额和会计凭证能对上，再开始正式初始化。

首次登录后，先把主数据骨架搭对

ERPNext 的很多“用起来别扭”，其实是主数据没设计好。建议按下面的顺序搭建：

公司：公司名称、默认货币、会计年度。多公司场景要提前想清楚哪些数据共享、哪些按公司隔离。
会计科目表：创建公司时可以选择模板，之后按实际业务增删。不要直接照搬别人的科目表，先列出自己每月要看的报表。
税率与税务模板：把常用税率、含税/不含税习惯固定下来，避免每张单据手工改。
仓库：至少区分主仓、次品仓或在途仓。仓库划分过细会增加操作负担，过粗又无法定位库存差异。
物料：物料编码、单位、默认仓库、是否批次/序列号管理。物料编码规则一旦有业务数据，再改成本很高。
客户与供应商：统一名称和纳税人识别号，避免同一家公司出现多个重复档案。

这一步看起来慢，但它决定了后面单据能不能自动带出价格、税率和库存。主数据阶段多花两天，比上线后洗数据便宜得多。

进销存表单设计：从“能录”到“能对账”

ERPNext 的进销存不是一张孤立表格，而是一条单据链。销售侧通常是“销售订单 → 交货单 → 销售发票 → 收款”，采购侧是“采购订单 → 采购收货 → 采购发票 → 付款”。库存数量由收货和交货推动，财务应收应付由发票推动。理解这个分工，才能判断问题出在业务还是财务。

几个容易忽略的设计点：

物料单位：采购按箱、销售按个时，要配置好单位换算，否则库存数量会乱。
批次与序列号：食品、电子元器件、设备类业务可能需要追溯，启用前想清楚录入成本。
库存估值：移动平均或 FIFO 会影响出库成本和毛利。方法一旦有大量历史数据再切换，代价很高。
提交与取消：ERPNext 的单据提交后不能直接改数量金额，需要先取消再修改。这不是 bug，而是为了保证账务可追溯。要在培训时明确告诉业务人员。

如果团队习惯“一张单解决所有事”，可以先用自定义字段把必要信息挂在销售订单上，但不建议为了少点几次鼠标而把交货和开票合并成手工流程。单据链断开后，库存和应收就对不上。

权限与流程流转：别让所有人共用管理员账号

小团队最容易图省事，所有人用同一个管理员账号。短期方便，长期会带来两个问题：操作日志无法追溯到人，误改单据也查不出是谁。ERPNext 的权限体系可以按角色、单据类型和用户权限三个层次来配：

角色：按岗位划分，例如销售、仓管、财务、采购。角色只决定“能不能看这类单据、能不能做这类操作”。
DocType 权限：控制某类单据的读、写、创建、提交、取消、删除。仓管通常需要交货单的提交权限，但不应该能改销售价格。
User Permission：把用户限制到指定公司、仓库或成本中心。多仓场景下，这个比角色更细。
Workflow：需要审批时，用工作流把“草稿—待审批—已批准—已提交”串起来，而不是靠群里喊一声。

权限配置完成后，一定要用测试账号实际登录验证。管理员视角能看到所有菜单，普通销售登录后可能连客户都建不了，这类问题只有切换账号才能发现。

财务初始化最常见的三个误区

误区一：科目表直接照搬同行或模板。 科目表应该服务于管理层每月要看的报表。如果只是照搬一套很细的科目，月底没人会去填；如果太粗，又看不出成本结构。建议先保留模板主干，再按自己的收入、成本、费用分类增补。

误区二：期初余额只录银行存款。 期初不只是资金余额，还包括应收、应付、库存和固定资产。应收应付可以通过期初发票或期初日记账录入，库存要用期初库存或库存重估单据。只录一部分，后面资产负债表永远平不了。

误区三：库存期初和估值方法不匹配。 期初库存的数量和单价要一起考虑。如果只录数量不录成本，出库成本会变成零，毛利失真；如果估值方法中途切换，历史成本会被重算。上线前把库存估值方法定下来，并用一小批数据验算一次出库成本。

财务初始化建议让实际做账的人参与，而不是只由 IT 完成。系统能跑通和账能做平，是两件事。

二次开发的边界：优先配置，谨慎改源码

ERPNext 的定制能力很强，但定制方式有优先级：

自定义字段、自定义 DocType、打印格式、报表：升级兼容性最好，优先用这些。
Server Script、Client Script：适合轻量逻辑，但要控制数量，避免把业务规则散落在脚本里。
自定义应用：确实需要复杂逻辑时，单独建 Frappe 应用，通过钩子扩展，而不是直接改 ERPNext 源码。
直接 fork 修改核心代码：升级时合并冲突最痛苦，除非有长期维护能力，否则不建议。

另外注意许可证边界：ERPNext 采用 GPL v3，内部使用和修改通常没有问题，但如果对外分发修改后的版本，需要遵守 GPL v3 关于源代码提供的要求。商业上怎么用，建议结合自己的分发方式确认，不要默认“开源就等于没有任何义务”。

备份、升级与日常运维

ERPNext 的备份命令可以同时带上数据库和文件：

docker compose exec backend bench --site erp.example.com backup --with-files

备份策略至少包含三件事：每天自动备份、备份文件传到另一台机器或对象存储、每隔一段时间做一次恢复演练。只备份不恢复，等于没验证过备份是否可用。恢复命令大致如下，具体参数以当前版本为准：

bench --site erp.example.com restore /path/to/database.sql.gz 
  --with-public-files /path/to/files.tar 
  --with-private-files /path/to/private-files.tar

升级前先在测试环境跑一遍，重点看自定义字段、打印格式和自定义应用是否兼容。生产升级当天先做完整备份，再停写入，升级完成后用测试账号走一遍开单、发货、开票和收款。

排错清单：几个高频故障

现象	优先检查	常见原因
容器反复重启	`docker compose logs backend db`	数据库密码不一致、数据卷权限、内存不足
浏览器 404 或 502	站点是否创建、反向代理配置、站点名与域名是否一致	Nginx 未指向正确站点，或容器网络变化
登录后提示数据库连接失败	站点配置文件中的数据库主机和密码	密码改过但配置未同步，或数据库容器未就绪
定时任务不执行	调度器是否启用、worker 日志、Redis 连接	调度器被关闭，或后台 worker 未启动
单据日期差一天	系统设置时区、公司时区、用户时区	服务器使用 UTC，业务时区未统一
邮件发不出去	邮件账户配置、SMTP 端口和加密方式	云厂商封端口，或 SSL/TLS 配置不匹配