简介赤龙ERP是一款面向企业数字化管理场景的开源企业级ERP系统核心价值在于打通计划预算、订单出入库、发票收付款以及凭证分录总账等环节实现财务业务一体化适合需要搭建进销存、财务与工作流闭环的中小企业及二次开发者。压缩包共2000个文件大小53.26MB以802个Java源码、465个JavaScript脚本、196个JSP页面及84个SQL脚本为主兼顾HTML、CSS、XML配置与属性文件可覆盖前端界面、后端逻辑、数据库初始化与权限配置等完整开发链路。目前已有88人学习下载对于想研究ERP模块划分、单据流转与总账集成逻辑的开发者能直接查看全量源码与数据库脚本并结合具体业务场景快速定位核心代码。借助其工作流与进销存设计还可学习如何将复杂业务抽象为可配置的系统模块是一份适合实战参考与二次开发的企业应用源码包。1. 赤龙ERP 解决的从来不是“记账”而是企业三流脱节的老问题月底财务对账对不上仓库说入了库、财务说没收到单销售合同签了、预算却没扣客户款到了、应收还挂着——这些不是财务人员的错也不是仓库人员的错而是订单、出入库、发票、收付款、凭证各管一段管理流、信息流、数据流三张皮。赤龙ERP 这样的免费开源、业务闭环的企业级 ERP核心价值就在这儿从计划预算一路推到订单、出入库、发票、收付款再自动落到凭证、分录、总账业务单据和财务凭证在网上咬合成一条闭环。它适合两类人一是想用 ERP 真正实现财务业务一体化的中小企业和成长型企业二是打算做二次开发、想研究开源 ERP 闭环设计的技术团队。这篇笔记就按“架构怎么选、怎么部署、流程怎么走通、坑在哪、上线后怎么验证”来讲。2. 财务业务一体化的架构选型为什么“闭环”必须靠单据驱动而非接口拼接2.1 三种一体化方案接口拼接、中间表同步、单据驱动闭环市面上做财务业务一体化常见的有三条路。第一条是“接口拼接”业务系统归业务系统财务系统归财务系统中间写一堆接口把订单、出入库数据推给财务。两边字段命名、编码规则、时间口径不一样接口越写越多对账时一个单据对不上要查三层日志。第二条是“中间表同步”业务库和财务库共用一张中间表业务写、财务读。看似简单但中间表没人清理、没人加锁就变成黑匣子数据错了都不知道从哪查起。赤龙ERP 这类项目走的是第三条路——单据驱动闭环。核心思想是一张入库单不仅是仓库的单它同时触发库存变动、成本计算、应付暂估、凭证生成一张收款单同时核销应收、登记银行流水、生成收款凭证。业务单据和财务凭证是同一棵树的根和叶不是两套系统握手传数据。这样做的好处是每笔财务数据都能追溯到源头业务单据总账、明细账、单据三级对得上。我一般评估一套开源 ERP 是不是真闭环先看三件事业务单据审核后能不能异步/同步生成凭证凭证分录能不能反查回业务单据期间结账会不会检查“该入账而未入账”的单据。三点全中才是闭环设计否则只是把两个系统焊在一起。2.2 核心数据模型组织、账套、科目、物料怎么串起来单据驱动不是凭空来的它的底层数据模型有几根必须立住的柱子。第一根柱子是多组织/账套。企业级 ERP 得支持多公司、多工厂、多仓库而每个公司有独立账套、独立科目表。赤龙ERP 这类开源的体系里组织维度和财务维度必须解耦仓库属于“库存组织”公司属于“财务组织”一张出库单要能同时定位它在哪个仓库、属于哪个公司的账套。这块设计不好后面合并报表全是坑。第二根柱子是科目与业务类型的映射。凭证不是用户手填的而是由“业务类型 单据 对方科目规则”自动推出来的。比如采购入库业务类型是“采购入库”借方科目映射到“原材料/库存商品”贷方映射到“应付账款-暂估”。这套映射表是财务业务一体化的灵魂。开源 ERP 一般会做成“科目映射规则表”我在二次开发时会特别注意不要让用户在每个单据上选科目而是按存货类别、供应商类别、费用类型去配置映射否则一线操作员根本不会用。第三根柱子是物料主数据。物料贯穿计划、订单、出入库、成本核算一个料号乱全链路跟着乱。赤龙ERP 对物料的管控常见做法是统一编码、多计量单位、默认仓库、计价方式。这里有一条血泪经验计价方式移动平均、先进先出、个别计价一定要在期初就定死中途切换会导致成本核算翻车且不可逆。2.3 状态机和状态流转闭环的命门业务闭环系统里每张单据都是一个状态机。采购订单有“草稿 - 已审核 - 部分到货 - 全部到货 - 已关闭”销售发票有“草稿 - 已审核 - 已收款 - 已核销”。状态机的设计质量直接决定闭环跑不跑得起来。设计状态机有三个要点。第一状态的跳转必须是单向且明确的任何一步都不能让用户随意“回退”回退要走红冲或反审核流程不能直接改状态。第二状态变更要联动下游比如销售出库单审核后库存即时扣减、应收暂估推送给财务这些联动要同一个事务里完成防止扣了库存没生成应收。第三状态要可追溯单据头要记录“谁在什么时间把状态从 A 改到 B”这是审计追溯的基础。在实际项目里我看到太多团队在这上面图省事用数据库字段直接 UPDATE 改状态结果单子审核了库存没扣发票开了应收没生成。赤龙ERP 这类开源项目把状态流转做在统一的单据服务里二次开发时要守住的底线就是所有状态变更必须走统一的审核/反审核动作不要绕过服务直改库表改一次闭环必断。3. 把赤龙ERP 拉起来跑一遍从源码到可操作的最小环境3.1 选型为什么跑开源 ERP 用 Docker 而不是裸机部署第一次接触赤龙ERP 这类项目我建议直接用 Docker 部署。理由很实际开源 ERP 依赖 Java 运行时、MySQL 数据库、Redis 缓存和一堆中间件裸机部署光环境变量就能折腾一下午。用 Docker 能在一台 4 核 8G 的机器上把整套环境拉起来后面换机器、备份、升级也都有后悔药。先说明一点不同版本的基础镜像和启动参数会有差异下面的编排以“前后端分离 MySQL Redis Nginx 反代”这一最常见的开源 ERP 部署形态为例。实际操作时以你下载到的源码包里 docker 目录和 release 说明为准。3.2 最小部署的 docker-compose 配置我一般会在项目根目录下创建一个 docker-compose.yml把依赖中间件和应用服务编排在一起version: 3.8 services: mysql: image: mysql:8.0 container_name: erp-mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: chilong_erp TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --lower_case_table_names1 volumes: - ./mysql-data:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d ports: - 3306:3306 redis: image: redis:7 container_name: erp-redis restart: always ports: - 6379:6379 backend: image: chilong-erp-server:latest container_name: erp-server restart: always depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/chilong_erp?useUnicodetruecharacterEncodingutf8 SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: root123456 SPRING_REDIS_HOST: redis SERVER_PORT: 8080 ports: - 8080:8080 web: image: chilong-erp-web:latest container_name: erp-web restart: always depends_on: - backend ports: - 80:80这个配置里有几个参数值得细说。MySQL 的lower_case_table_names1是为了让 Linux 下表名大小写不敏感很多把 Windows 开发环境搬到 Linux 服务器的人在这一步翻车表建好了找不到。init-sql目录用于首次启动时自动执行初始化脚本把数据库结构建好、预置基础数据导进去。时区TZ: Asia/Shanghai必须配置否则单据时间和财务日期差八个小时月底对账时会非常痛苦。Redis 在这里不只是缓存还承担了验证码、登录态和部分并发锁的功能不能省。3.3 从代码构建镜像并启动如果你拿到的是源码而不是现成镜像需要先构建再启动。我用 Maven 构建 Java 后端、npm 构建前端# 后端跳过测试并打 jar 包 mvn clean package -DskipTests # 前端安装依赖并构建静态资源 npm install --registryhttps://registry.npmmirror.com npm run build # 构建镜像 docker build -t chilong-erp-server:latest -f docker/Dockerfile.server . docker build -t chilong-erp-web:latest -f docker/Dockerfile.web . # 启动整套环境 docker-compose up -d # 查看日志确认后端启动成功 docker logs -f erp-server这里的逻辑很简单后端先编译成可执行 jar前端构建出静态文件然后分别打进镜像最后用 docker-compose 统一拉起。-DskipTests是跳过单测第一次部署时能省不少时间但上线前建议打开跑一遍后面避坑章节会解释为什么。启动后验证三件事浏览器打开 http://服务器IP 能看到登录页接口文档能访问常见路径是 /swagger-ui/index.html数据库里能看到初始化脚本建出的表。三件事都通了环境就没问题了。3.4 首次登录后的基础资料配置顺序环境跑起来只是开始真正的“初始化”在系统界面里。我强烈建议按下面的顺序配置基础资料顺序错了后面全是返工第一配组织架构公司、部门、仓库。先有组织才能有业务归属。第二配会计科目表和账套。开源 ERP 一般自带一套预置科目你要按自己公司的情况调整损益类、资产类科目。第三配物料分类和计量单位。这一步决定了以后所有出入库单据的可用项。第四配客户、供应商档案。第五配财务映射规则把存货类别映射到科目把费用类型映射到费用科目。这套顺序的核心逻辑是“先有主数据再有业务单据”。你如果在物料还没建的情况下就去录采购订单后面物料数据补录完订单上的料号编码很可能和物料档案对不上导致发票无法匹配、凭证生成失败。这类问题在 ERP 实施里叫“脏数据”而脏数据的清理永远只能在源头处理。4. 从计划预算走到总账三流管控在系统里是怎么走通的4.1 管理流计划预算 → 订单 → 出入库 → 发票 → 收付款的完整链条赤龙ERP 的闭环不是一句口号它是从“计划”这个源头开始约束的。管理流的起点是预算。销售部门年初定销售计划、费用预算采购部门按生产计划做采购预算。预算不是摆设在开源 ERP 里一般有两种控制方式一种是硬控制预算不够就不让下单另一种是软控制即超预算时提示但放行。我见过不少实施项目在这块没想清楚预算只录不用月底才发现超支这时候再来追责已经晚了。预算之后是订单。销售订单审核后在系统里形成待交货的承诺采购订单审核后形成待入库的期望。这两类订单是业务的源头后续所有出入库、开票、收付款都挂在订单行上——这叫“来源单号贯穿”。我判断一套 ERP 是不是真闭环就看一张销售订单从审核到最终凭证生成能不能一路点回去看到当初的订单号。能做到管理流才称得上是闭环。再往后是出入库。采购到货做采购入库单销售发货做销售出库单。库存数据的变动就在这一环节发生。然后是发票采购发票、销售发票必须在出入库的基础上生成数量和金额与入库单/出库单勾稽。最后是收付款收款单核销应收付款单核销应付。到这里管理流的业务事实基本记录完毕但它还没有变成财务语言——这就需要数据流把单据翻译成凭证。4.2 数据流业务单据如何生成凭证、凭证如何追溯单据数据流是闭环最核心的部分也是赤龙ERP 这类自研开源系统和普通进销存软件最大的分水岭。普通进销存录一单是一单财务月末拿 Excel 汇总过账赤龙ERP 的设计是业务审核动作直接生成记账凭证。以采购入库为例采购入库单审核后系统根据“存货类别 业务类型 科目映射”自动生成一笔暂估入账的分录-- 查看某张采购入库单生成的凭证示意SQL实际以系统凭证查询界面为准 SELECT v.VOUCHER_NO, v.VOUCHER_DATE, l.SUMMARY AS 摘要, l.ACCOUNT_CODE AS 科目编码, l.ACCOUNT_NAME AS 科目名称, l.DEBIT_AMOUNT AS 借方金额, l.CREDIT_AMOUNT AS 贷方金额, s.BILL_NO AS 来源单据号 FROM GL_VOUCHER_LINE l JOIN GL_VOUCHER v ON l.VOUCHER_ID v.ID LEFT JOIN BILL_SOURCE_RELATION r ON r.VOUCHER_ID v.ID LEFT JOIN PURCHASE_RECEIPT s ON s.ID r.SOURCE_BILL_ID WHERE s.BILL_NO PO-RECEIPT-2025-0001;这段 SQL 的逻辑是从凭证分录表查出采购入库单单号为PO-RECEIPT-2025-0001的凭证并通过BILL_SOURCE_RELATION这张中间表反查到来源单据。这套“来源单据关联表”是整个数据流追溯的设计关键。反向追溯也是一样的道理看到总账上“原材料”科目有一笔借方发生额点进去能下钻到明细账再点到凭证再点到采购入库单最后看到采购订单和供应商。凭证生成有两种触发方式一种是审核时同步生成一种是月末批量生单。赤龙ERP 这类免费开源系统一般同时支持两种我建议日常业务用同步生成月底检查用批量补单。同步生成的好处是问题随现随处理不用月底一次性面对一堆差错。4.3 控制点预算占用、库存校验、信用控制怎么设计才不“软”闭环设计光有数据流动还不够还得在关键节点上设控制点否则业务可以随意突破规则管理流就是空的。第一个控制点是预算占用。采购订单审核时系统要检查该订单所属预算项目是否还有可用额度占用预算采购入库时不重复占用订单取消时释放预算。很多系统把预算控制做成“事后统计”那是管理信息表不是管控工具。赤龙ERP 的常见做法是预算占用表和预算执行表分离可用金额 预算金额 - 占用金额 - 实际执行金额每次下单前实时计算。第二个控制点是库存校验。销售出库单审核时系统要检查可用库存是否足够不够时阻塞出库。这里有个细节可用库存 现有库存 在途入库 - 已占用出库。如果你只查现有库存就会出现在途订单还没到、销售单已经超卖的情况。我见过一个项目报表上库存明明够出货时负数一大片就是没算在途和占用。第三个控制点是客户信用控制。销售订单审核、发货环节都应校验该客户的应收余额和信用额度超额度时按预先设定的策略处理——是提示、是冻结、还是需上级审批。这说起来简单但信用额度要支持“总额 期限”双维度否则治标不治本。这三个控制点直接决定了“灵活稳定”的“管控”成色。赤龙ERP 这类开源系统把控制规则做成参数二开时最忌讳的是一股脑把控制逻辑写死在业务服务里。用参数化的规则引擎客户随时能改控制强度那是灵活改一次规则要发一次版那叫作死。5. ERP 上线避坑闭环断点、期间错位与成本核算的五个常见坑5.1 单据已审核但凭证没生成现象业务人员在系统里早已审核了出入库单月末财务结账时却发现总账里面缺凭证库存模块和总账对不上。原因最常见的是凭证生成失败被静默忽略。比如科目映射没配好、存货类别没有对应科目、或者凭证生成服务依赖的下游接口超时。开源系统里这类异步任务往往只记录日志不弹窗提示业务人员根本不知道凭证没生成。解决我一般会做两件事。第一在业务单据列表页增加“凭证状态”列已生成为“已生成”未生成为“未生成”让业务人员审核后主动看一眼第二月末结账前跑一遍“业务单据 vs 凭证勾稽检查”把已审核但未生成凭证的单据全部列出来逐一排查。这类检查在赤龙ERP 里一般放在“期末处理”菜单下不要嫌麻烦而不跑。5.2 发票日期与出入库期间不一致现象3 月底采购入库4 月初供应商才开来发票。财务做采购入库暂估和发票校验3 月暂估入库、4 月收到发票后要做“红字冲回暂估”再按发票金额入账步骤一多就出错。原因系统默认的“期间”按自然月锁定期末结账后不允许再修改已结账期间单据。但如果发票日期落在 4 月、参考的是 3 月的入库单有些用户会尝试反审核 3 月的入库单来改金额结果被系统拦截。解决正确做法是3 月入库单保持原样4 月来票时录“采购发票”系统会自动生成一笔“暂估冲回 按票入账”的红蓝字凭证对。二开时千万不要去动已结账期间的单据后果是总账和明细账对不上。真需要调整走成本调整单或凭证冲销不要返工原单。5.3 预算控制只做提醒不做拦截现象预算模块配好了但销售、采购订单照样超预算审核预算报表红字一大片形同虚设。原因预算控制强度参数默认设在“提示”档位超预算时系统弹个提醒单据照样能审。业务人员赶单子根本不会理提示直接点确认。解决在系统参数里把预算控制设为“强制”超预算时必须走预算追加流程才能审核。我负责过的项目里管理者怕业务推不动初始都选“提示”上线三个月后预算跟没做一样。强制控制在初期会带来一些流程摩擦但这是预算能真正落地的最短路径。5.4 负库存导致成本核算异常现象销售出库先于采购入库发生库存变成负数。月底加权平均成本的计算结果变成了负数或异常大数。原因在很多前端单据驱动的 ERP 中负库存本身是业务流程允许的但成本计算模块没有做“负库存保护”。我见过一次移动平均单价从 10 元直接跳到 200 元就是一个先出后进的负库存导致的。解决从上线的第一天就开启“不允许负库存出库”参数宁可在流程上增加一个“紧急采购入库”步骤也不要放开负库存。如果系统已经跑出去了就找成本模块的重算功能按批次重新计算移动平均价并按调整后成本生成成本调整单。这个功能在赤龙ERP 里一般叫“成本重算”或“存货核算”。5.5 二开时绕过状态机直接改库表现象二次开发时为了让某个字段满足业务需求直接用 SQL 在数据库里 UPDATE 单据状态或金额字段。之后发现该单据对应的凭证、报表、预算占用全部乱套。原因状态机逻辑全在业务服务层你绕过服务直接改库表服务层缓存里还是旧状态下游联动也没触发整个闭环在数据层被撕了一个口子。解决任何供需变动都要通过系统的“变更单”“红冲单”“反审核”功能来完成。如果系统没有这个功能就去开发一个而不是直接 UPDATE。这是我给所有做开源 ERP 二开的人说的一条铁律宁可写代码走正规通道也不要图方便改库表改库表一时爽对账火葬场。6. “跑得通”不等于“走得稳”用追溯链和试算平衡给 ERP 做体检系统上线能录单和真正走得稳中间还差一套验证方法。我做完部署和流程配置后一定会做三轮体检。第一轮是“凭证反向追溯”。在总账里随机挑一个月的“原材料”科目发生额从总账下钻到明细账再到凭证再到入库单看整条链路能不能走通。走不通的地方就是闭环断点通常出在来源单据关联表缺失或凭证生成规则没配全。我会写一个小工具把一个月内所有凭证和来源单据关联关系扫一遍找出“有凭证无单据”和“有单据无凭证”的两类记录。第二轮是“试算平衡 期间科目余额校验”。结账前必须跑一遍试算平衡表看借方合计是否等于贷方合计。如果不等优先查“业务单据推凭证”环节有没有金额丢位。还有一种常见问题是期初余额录入不平这会导致后续所有月份的损益和资产负债都不平这类问题只能通过期初调整凭证修复。第三轮是“模拟业务演练”。用一套完整测试数据把一年的业务压缩到三天里跑完每天录采购订单、入库、开票、付款再录销售订单、出库、开票、收款月底做一次结账下个月初做一次反结账再结账看看会不会出现期间错位或单据锁死。这一轮能暴露大量真实业务里的边界问题比如跨月跨年、红蓝字对冲、退货退款叠加。演练数据不要用生产数据用一套独立的测试账套录完直接清掉。这套验证做完系统才算真正具备了交付条件。我自己的习惯是把这些验证步骤固化成一份“上线前检查单”每做一个客户或每升一个版本就照单跑一遍少一步都不上线。开源 ERP 最大的价值是给了你追查一切问题的入口但入口有了不沿着数据流走一遍等于白给。希望这篇笔记能帮你把赤龙ERP 从头跑到尾少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取 赤龙ERP落地指南：从部署到财务业务一体化的闭环实践
简介赤龙ERP是一款面向企业数字化管理场景的开源企业级ERP系统核心价值在于打通计划预算、订单出入库、发票收付款以及凭证分录总账等环节实现财务业务一体化适合需要搭建进销存、财务与工作流闭环的中小企业及二次开发者。压缩包共2000个文件大小53.26MB以802个Java源码、465个JavaScript脚本、196个JSP页面及84个SQL脚本为主兼顾HTML、CSS、XML配置与属性文件可覆盖前端界面、后端逻辑、数据库初始化与权限配置等完整开发链路。目前已有88人学习下载对于想研究ERP模块划分、单据流转与总账集成逻辑的开发者能直接查看全量源码与数据库脚本并结合具体业务场景快速定位核心代码。借助其工作流与进销存设计还可学习如何将复杂业务抽象为可配置的系统模块是一份适合实战参考与二次开发的企业应用源码包。1. 赤龙ERP 解决的从来不是“记账”而是企业三流脱节的老问题月底财务对账对不上仓库说入了库、财务说没收到单销售合同签了、预算却没扣客户款到了、应收还挂着——这些不是财务人员的错也不是仓库人员的错而是订单、出入库、发票、收付款、凭证各管一段管理流、信息流、数据流三张皮。赤龙ERP 这样的免费开源、业务闭环的企业级 ERP核心价值就在这儿从计划预算一路推到订单、出入库、发票、收付款再自动落到凭证、分录、总账业务单据和财务凭证在网上咬合成一条闭环。它适合两类人一是想用 ERP 真正实现财务业务一体化的中小企业和成长型企业二是打算做二次开发、想研究开源 ERP 闭环设计的技术团队。这篇笔记就按“架构怎么选、怎么部署、流程怎么走通、坑在哪、上线后怎么验证”来讲。2. 财务业务一体化的架构选型为什么“闭环”必须靠单据驱动而非接口拼接2.1 三种一体化方案接口拼接、中间表同步、单据驱动闭环市面上做财务业务一体化常见的有三条路。第一条是“接口拼接”业务系统归业务系统财务系统归财务系统中间写一堆接口把订单、出入库数据推给财务。两边字段命名、编码规则、时间口径不一样接口越写越多对账时一个单据对不上要查三层日志。第二条是“中间表同步”业务库和财务库共用一张中间表业务写、财务读。看似简单但中间表没人清理、没人加锁就变成黑匣子数据错了都不知道从哪查起。赤龙ERP 这类项目走的是第三条路——单据驱动闭环。核心思想是一张入库单不仅是仓库的单它同时触发库存变动、成本计算、应付暂估、凭证生成一张收款单同时核销应收、登记银行流水、生成收款凭证。业务单据和财务凭证是同一棵树的根和叶不是两套系统握手传数据。这样做的好处是每笔财务数据都能追溯到源头业务单据总账、明细账、单据三级对得上。我一般评估一套开源 ERP 是不是真闭环先看三件事业务单据审核后能不能异步/同步生成凭证凭证分录能不能反查回业务单据期间结账会不会检查“该入账而未入账”的单据。三点全中才是闭环设计否则只是把两个系统焊在一起。2.2 核心数据模型组织、账套、科目、物料怎么串起来单据驱动不是凭空来的它的底层数据模型有几根必须立住的柱子。第一根柱子是多组织/账套。企业级 ERP 得支持多公司、多工厂、多仓库而每个公司有独立账套、独立科目表。赤龙ERP 这类开源的体系里组织维度和财务维度必须解耦仓库属于“库存组织”公司属于“财务组织”一张出库单要能同时定位它在哪个仓库、属于哪个公司的账套。这块设计不好后面合并报表全是坑。第二根柱子是科目与业务类型的映射。凭证不是用户手填的而是由“业务类型 单据 对方科目规则”自动推出来的。比如采购入库业务类型是“采购入库”借方科目映射到“原材料/库存商品”贷方映射到“应付账款-暂估”。这套映射表是财务业务一体化的灵魂。开源 ERP 一般会做成“科目映射规则表”我在二次开发时会特别注意不要让用户在每个单据上选科目而是按存货类别、供应商类别、费用类型去配置映射否则一线操作员根本不会用。第三根柱子是物料主数据。物料贯穿计划、订单、出入库、成本核算一个料号乱全链路跟着乱。赤龙ERP 对物料的管控常见做法是统一编码、多计量单位、默认仓库、计价方式。这里有一条血泪经验计价方式移动平均、先进先出、个别计价一定要在期初就定死中途切换会导致成本核算翻车且不可逆。2.3 状态机和状态流转闭环的命门业务闭环系统里每张单据都是一个状态机。采购订单有“草稿 - 已审核 - 部分到货 - 全部到货 - 已关闭”销售发票有“草稿 - 已审核 - 已收款 - 已核销”。状态机的设计质量直接决定闭环跑不跑得起来。设计状态机有三个要点。第一状态的跳转必须是单向且明确的任何一步都不能让用户随意“回退”回退要走红冲或反审核流程不能直接改状态。第二状态变更要联动下游比如销售出库单审核后库存即时扣减、应收暂估推送给财务这些联动要同一个事务里完成防止扣了库存没生成应收。第三状态要可追溯单据头要记录“谁在什么时间把状态从 A 改到 B”这是审计追溯的基础。在实际项目里我看到太多团队在这上面图省事用数据库字段直接 UPDATE 改状态结果单子审核了库存没扣发票开了应收没生成。赤龙ERP 这类开源项目把状态流转做在统一的单据服务里二次开发时要守住的底线就是所有状态变更必须走统一的审核/反审核动作不要绕过服务直改库表改一次闭环必断。3. 把赤龙ERP 拉起来跑一遍从源码到可操作的最小环境3.1 选型为什么跑开源 ERP 用 Docker 而不是裸机部署第一次接触赤龙ERP 这类项目我建议直接用 Docker 部署。理由很实际开源 ERP 依赖 Java 运行时、MySQL 数据库、Redis 缓存和一堆中间件裸机部署光环境变量就能折腾一下午。用 Docker 能在一台 4 核 8G 的机器上把整套环境拉起来后面换机器、备份、升级也都有后悔药。先说明一点不同版本的基础镜像和启动参数会有差异下面的编排以“前后端分离 MySQL Redis Nginx 反代”这一最常见的开源 ERP 部署形态为例。实际操作时以你下载到的源码包里 docker 目录和 release 说明为准。3.2 最小部署的 docker-compose 配置我一般会在项目根目录下创建一个 docker-compose.yml把依赖中间件和应用服务编排在一起version: 3.8 services: mysql: image: mysql:8.0 container_name: erp-mysql restart: always environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: chilong_erp TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --lower_case_table_names1 volumes: - ./mysql-data:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d ports: - 3306:3306 redis: image: redis:7 container_name: erp-redis restart: always ports: - 6379:6379 backend: image: chilong-erp-server:latest container_name: erp-server restart: always depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/chilong_erp?useUnicodetruecharacterEncodingutf8 SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: root123456 SPRING_REDIS_HOST: redis SERVER_PORT: 8080 ports: - 8080:8080 web: image: chilong-erp-web:latest container_name: erp-web restart: always depends_on: - backend ports: - 80:80这个配置里有几个参数值得细说。MySQL 的lower_case_table_names1是为了让 Linux 下表名大小写不敏感很多把 Windows 开发环境搬到 Linux 服务器的人在这一步翻车表建好了找不到。init-sql目录用于首次启动时自动执行初始化脚本把数据库结构建好、预置基础数据导进去。时区TZ: Asia/Shanghai必须配置否则单据时间和财务日期差八个小时月底对账时会非常痛苦。Redis 在这里不只是缓存还承担了验证码、登录态和部分并发锁的功能不能省。3.3 从代码构建镜像并启动如果你拿到的是源码而不是现成镜像需要先构建再启动。我用 Maven 构建 Java 后端、npm 构建前端# 后端跳过测试并打 jar 包 mvn clean package -DskipTests # 前端安装依赖并构建静态资源 npm install --registryhttps://registry.npmmirror.com npm run build # 构建镜像 docker build -t chilong-erp-server:latest -f docker/Dockerfile.server . docker build -t chilong-erp-web:latest -f docker/Dockerfile.web . # 启动整套环境 docker-compose up -d # 查看日志确认后端启动成功 docker logs -f erp-server这里的逻辑很简单后端先编译成可执行 jar前端构建出静态文件然后分别打进镜像最后用 docker-compose 统一拉起。-DskipTests是跳过单测第一次部署时能省不少时间但上线前建议打开跑一遍后面避坑章节会解释为什么。启动后验证三件事浏览器打开 http://服务器IP 能看到登录页接口文档能访问常见路径是 /swagger-ui/index.html数据库里能看到初始化脚本建出的表。三件事都通了环境就没问题了。3.4 首次登录后的基础资料配置顺序环境跑起来只是开始真正的“初始化”在系统界面里。我强烈建议按下面的顺序配置基础资料顺序错了后面全是返工第一配组织架构公司、部门、仓库。先有组织才能有业务归属。第二配会计科目表和账套。开源 ERP 一般自带一套预置科目你要按自己公司的情况调整损益类、资产类科目。第三配物料分类和计量单位。这一步决定了以后所有出入库单据的可用项。第四配客户、供应商档案。第五配财务映射规则把存货类别映射到科目把费用类型映射到费用科目。这套顺序的核心逻辑是“先有主数据再有业务单据”。你如果在物料还没建的情况下就去录采购订单后面物料数据补录完订单上的料号编码很可能和物料档案对不上导致发票无法匹配、凭证生成失败。这类问题在 ERP 实施里叫“脏数据”而脏数据的清理永远只能在源头处理。4. 从计划预算走到总账三流管控在系统里是怎么走通的4.1 管理流计划预算 → 订单 → 出入库 → 发票 → 收付款的完整链条赤龙ERP 的闭环不是一句口号它是从“计划”这个源头开始约束的。管理流的起点是预算。销售部门年初定销售计划、费用预算采购部门按生产计划做采购预算。预算不是摆设在开源 ERP 里一般有两种控制方式一种是硬控制预算不够就不让下单另一种是软控制即超预算时提示但放行。我见过不少实施项目在这块没想清楚预算只录不用月底才发现超支这时候再来追责已经晚了。预算之后是订单。销售订单审核后在系统里形成待交货的承诺采购订单审核后形成待入库的期望。这两类订单是业务的源头后续所有出入库、开票、收付款都挂在订单行上——这叫“来源单号贯穿”。我判断一套 ERP 是不是真闭环就看一张销售订单从审核到最终凭证生成能不能一路点回去看到当初的订单号。能做到管理流才称得上是闭环。再往后是出入库。采购到货做采购入库单销售发货做销售出库单。库存数据的变动就在这一环节发生。然后是发票采购发票、销售发票必须在出入库的基础上生成数量和金额与入库单/出库单勾稽。最后是收付款收款单核销应收付款单核销应付。到这里管理流的业务事实基本记录完毕但它还没有变成财务语言——这就需要数据流把单据翻译成凭证。4.2 数据流业务单据如何生成凭证、凭证如何追溯单据数据流是闭环最核心的部分也是赤龙ERP 这类自研开源系统和普通进销存软件最大的分水岭。普通进销存录一单是一单财务月末拿 Excel 汇总过账赤龙ERP 的设计是业务审核动作直接生成记账凭证。以采购入库为例采购入库单审核后系统根据“存货类别 业务类型 科目映射”自动生成一笔暂估入账的分录-- 查看某张采购入库单生成的凭证示意SQL实际以系统凭证查询界面为准 SELECT v.VOUCHER_NO, v.VOUCHER_DATE, l.SUMMARY AS 摘要, l.ACCOUNT_CODE AS 科目编码, l.ACCOUNT_NAME AS 科目名称, l.DEBIT_AMOUNT AS 借方金额, l.CREDIT_AMOUNT AS 贷方金额, s.BILL_NO AS 来源单据号 FROM GL_VOUCHER_LINE l JOIN GL_VOUCHER v ON l.VOUCHER_ID v.ID LEFT JOIN BILL_SOURCE_RELATION r ON r.VOUCHER_ID v.ID LEFT JOIN PURCHASE_RECEIPT s ON s.ID r.SOURCE_BILL_ID WHERE s.BILL_NO PO-RECEIPT-2025-0001;这段 SQL 的逻辑是从凭证分录表查出采购入库单单号为PO-RECEIPT-2025-0001的凭证并通过BILL_SOURCE_RELATION这张中间表反查到来源单据。这套“来源单据关联表”是整个数据流追溯的设计关键。反向追溯也是一样的道理看到总账上“原材料”科目有一笔借方发生额点进去能下钻到明细账再点到凭证再点到采购入库单最后看到采购订单和供应商。凭证生成有两种触发方式一种是审核时同步生成一种是月末批量生单。赤龙ERP 这类免费开源系统一般同时支持两种我建议日常业务用同步生成月底检查用批量补单。同步生成的好处是问题随现随处理不用月底一次性面对一堆差错。4.3 控制点预算占用、库存校验、信用控制怎么设计才不“软”闭环设计光有数据流动还不够还得在关键节点上设控制点否则业务可以随意突破规则管理流就是空的。第一个控制点是预算占用。采购订单审核时系统要检查该订单所属预算项目是否还有可用额度占用预算采购入库时不重复占用订单取消时释放预算。很多系统把预算控制做成“事后统计”那是管理信息表不是管控工具。赤龙ERP 的常见做法是预算占用表和预算执行表分离可用金额 预算金额 - 占用金额 - 实际执行金额每次下单前实时计算。第二个控制点是库存校验。销售出库单审核时系统要检查可用库存是否足够不够时阻塞出库。这里有个细节可用库存 现有库存 在途入库 - 已占用出库。如果你只查现有库存就会出现在途订单还没到、销售单已经超卖的情况。我见过一个项目报表上库存明明够出货时负数一大片就是没算在途和占用。第三个控制点是客户信用控制。销售订单审核、发货环节都应校验该客户的应收余额和信用额度超额度时按预先设定的策略处理——是提示、是冻结、还是需上级审批。这说起来简单但信用额度要支持“总额 期限”双维度否则治标不治本。这三个控制点直接决定了“灵活稳定”的“管控”成色。赤龙ERP 这类开源系统把控制规则做成参数二开时最忌讳的是一股脑把控制逻辑写死在业务服务里。用参数化的规则引擎客户随时能改控制强度那是灵活改一次规则要发一次版那叫作死。5. ERP 上线避坑闭环断点、期间错位与成本核算的五个常见坑5.1 单据已审核但凭证没生成现象业务人员在系统里早已审核了出入库单月末财务结账时却发现总账里面缺凭证库存模块和总账对不上。原因最常见的是凭证生成失败被静默忽略。比如科目映射没配好、存货类别没有对应科目、或者凭证生成服务依赖的下游接口超时。开源系统里这类异步任务往往只记录日志不弹窗提示业务人员根本不知道凭证没生成。解决我一般会做两件事。第一在业务单据列表页增加“凭证状态”列已生成为“已生成”未生成为“未生成”让业务人员审核后主动看一眼第二月末结账前跑一遍“业务单据 vs 凭证勾稽检查”把已审核但未生成凭证的单据全部列出来逐一排查。这类检查在赤龙ERP 里一般放在“期末处理”菜单下不要嫌麻烦而不跑。5.2 发票日期与出入库期间不一致现象3 月底采购入库4 月初供应商才开来发票。财务做采购入库暂估和发票校验3 月暂估入库、4 月收到发票后要做“红字冲回暂估”再按发票金额入账步骤一多就出错。原因系统默认的“期间”按自然月锁定期末结账后不允许再修改已结账期间单据。但如果发票日期落在 4 月、参考的是 3 月的入库单有些用户会尝试反审核 3 月的入库单来改金额结果被系统拦截。解决正确做法是3 月入库单保持原样4 月来票时录“采购发票”系统会自动生成一笔“暂估冲回 按票入账”的红蓝字凭证对。二开时千万不要去动已结账期间的单据后果是总账和明细账对不上。真需要调整走成本调整单或凭证冲销不要返工原单。5.3 预算控制只做提醒不做拦截现象预算模块配好了但销售、采购订单照样超预算审核预算报表红字一大片形同虚设。原因预算控制强度参数默认设在“提示”档位超预算时系统弹个提醒单据照样能审。业务人员赶单子根本不会理提示直接点确认。解决在系统参数里把预算控制设为“强制”超预算时必须走预算追加流程才能审核。我负责过的项目里管理者怕业务推不动初始都选“提示”上线三个月后预算跟没做一样。强制控制在初期会带来一些流程摩擦但这是预算能真正落地的最短路径。5.4 负库存导致成本核算异常现象销售出库先于采购入库发生库存变成负数。月底加权平均成本的计算结果变成了负数或异常大数。原因在很多前端单据驱动的 ERP 中负库存本身是业务流程允许的但成本计算模块没有做“负库存保护”。我见过一次移动平均单价从 10 元直接跳到 200 元就是一个先出后进的负库存导致的。解决从上线的第一天就开启“不允许负库存出库”参数宁可在流程上增加一个“紧急采购入库”步骤也不要放开负库存。如果系统已经跑出去了就找成本模块的重算功能按批次重新计算移动平均价并按调整后成本生成成本调整单。这个功能在赤龙ERP 里一般叫“成本重算”或“存货核算”。5.5 二开时绕过状态机直接改库表现象二次开发时为了让某个字段满足业务需求直接用 SQL 在数据库里 UPDATE 单据状态或金额字段。之后发现该单据对应的凭证、报表、预算占用全部乱套。原因状态机逻辑全在业务服务层你绕过服务直接改库表服务层缓存里还是旧状态下游联动也没触发整个闭环在数据层被撕了一个口子。解决任何供需变动都要通过系统的“变更单”“红冲单”“反审核”功能来完成。如果系统没有这个功能就去开发一个而不是直接 UPDATE。这是我给所有做开源 ERP 二开的人说的一条铁律宁可写代码走正规通道也不要图方便改库表改库表一时爽对账火葬场。6. “跑得通”不等于“走得稳”用追溯链和试算平衡给 ERP 做体检系统上线能录单和真正走得稳中间还差一套验证方法。我做完部署和流程配置后一定会做三轮体检。第一轮是“凭证反向追溯”。在总账里随机挑一个月的“原材料”科目发生额从总账下钻到明细账再到凭证再到入库单看整条链路能不能走通。走不通的地方就是闭环断点通常出在来源单据关联表缺失或凭证生成规则没配全。我会写一个小工具把一个月内所有凭证和来源单据关联关系扫一遍找出“有凭证无单据”和“有单据无凭证”的两类记录。第二轮是“试算平衡 期间科目余额校验”。结账前必须跑一遍试算平衡表看借方合计是否等于贷方合计。如果不等优先查“业务单据推凭证”环节有没有金额丢位。还有一种常见问题是期初余额录入不平这会导致后续所有月份的损益和资产负债都不平这类问题只能通过期初调整凭证修复。第三轮是“模拟业务演练”。用一套完整测试数据把一年的业务压缩到三天里跑完每天录采购订单、入库、开票、付款再录销售订单、出库、开票、收款月底做一次结账下个月初做一次反结账再结账看看会不会出现期间错位或单据锁死。这一轮能暴露大量真实业务里的边界问题比如跨月跨年、红蓝字对冲、退货退款叠加。演练数据不要用生产数据用一套独立的测试账套录完直接清掉。这套验证做完系统才算真正具备了交付条件。我自己的习惯是把这些验证步骤固化成一份“上线前检查单”每做一个客户或每升一个版本就照单跑一遍少一步都不上线。开源 ERP 最大的价值是给了你追查一切问题的入口但入口有了不沿着数据流走一遍等于白给。希望这篇笔记能帮你把赤龙ERP 从头跑到尾少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取