企业官网建设流程全解析

简介：赤龙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-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --lower_case_table_names=1 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?useUnicode=true&characterEncoding=utf8 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_names=1是为了让 Linux 下表名大小写不敏感，很多把 Windows 开发环境搬到 Linux 服务器的人在这一步翻车，表建好了找不到。init-sql目录用于首次启动时自动执行初始化脚本，把数据库结构建好、预置基础数据导进去。时区TZ: Asia/Shanghai必须配置，否则单据时间和财务日期差八个小时，月底对账时会非常痛苦。

Redis 在这里不只是缓存，还承担了验证码、登录态和部分并发锁的功能，不能省。

3.3 从代码构建镜像并启动

如果你拿到的是源码而不是现成镜像，需要先构建再启动。我用 Maven 构建 Java 后端、npm 构建前端：

# 后端：跳过测试并打 jar 包 mvn clean package -DskipTests # 前端：安装依赖并构建静态资源 npm install --registry=https://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 从头跑到尾，少踩几个我当年踩过的坑。

本文还有配套的精品资源，点击获取