简介：这份ERP进销存系统源码面向中小企业开发者与Java Web学习者，提供一套涵盖采购、销售、库存与财务核心流程的开源管理方案，可用于二次开发或作为企业信息化项目的参考实现。压缩包共1448个文件，约14.26MB，以png、gif等界面素材，java后端逻辑，js、html、css、jsp前端页面，以及xml配置、json数据、properties参数和sql数据库脚本为主，另含少量jar依赖与说明文档，结构完整、层次清晰。系统围绕进销存模块、财务核算、MySQL数据存储、角色权限管理、报表分析与系统集成等知识点展开，前端采用Web技术构建操作界面，后端实现业务逻辑并与数据库交互，配套脚本可完成建表与初始化数据。目前已有769人学习下载，适合希望理解ERP整体架构、掌握进销存业务实现或进行定制化扩展的开发者参考借鉴。
1. ERP进销存系统源码：一套能跑起来的最小闭环长什么样
很多开发者拿到「ERP进销存系统源码」这几个字，第一反应是去搜一套能直接部署的完整系统，结果下载下来发现要么是半成品，要么是某个培训机构的教学壳子，跑起来一堆报错。我见过太多人在这上面翻车：花了两周时间对比了七八套源码，最后连一张采购入库单都没跑通。
问题出在预期上。ERP进销存系统源码不是一个「下载即用」的成品，它更像一套骨架，核心价值在于把「采购→入库→销售→出库→库存→往来账」这条业务闭环用代码表达清楚。你要做的是理解这条闭环怎么在数据库表、服务层、前端表单之间流转，然后按自己的业务往里填肉。
这篇文章面向两类人：一是想自研进销存的中小团队开发者，需要一套可控的代码底座；二是想通过读源码理解ERP业务模型的工程师。我会按「数据模型→后端接口→前端交互→部署排错」的顺序，把一套典型ERP进销存系统源码的关键结构和落地路径拆开讲，中间给出可直接抄的代码片段和参数配置。不追求大而全，只求这条最小闭环你能亲手跑通。
2. 进销存核心数据模型：六张表撑起业务闭环
一套ERP进销存系统源码能不能用，先看它的表结构设计。表设计混乱的源码，后面业务逻辑一定是打补丁打出来的。我一般拿到源码先翻数据库迁移文件或建表SQL，重点看六张核心表：商品表、仓库表、供应商表、客户表、库存表、单据表（含明细）。这六张表的关系决定了整个系统的扩展上限。
2.1 商品、仓库、往来单位三张主数据表怎么设计
主数据表的设计原则是「字段够用但不冗余」。商品表最容易过度设计，很多人一上来就加几十个自定义属性字段，结果查询性能直线下降。常见做法是主表只放通用字段，扩展属性用JSON字段或独立的属性表存。
-- 商品表：主数据，只放通用字段 CREATE TABLE `product` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `sku_code` VARCHAR(64) NOT NULL COMMENT '商品编码，业务唯一键', `name` VARCHAR(128) NOT NULL COMMENT '商品名称', `category_id` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '分类ID', `unit` VARCHAR(16) NOT NULL DEFAULT '个' COMMENT '基本单位', `purchase_price` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '参考进价', `sale_price` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '参考售价', `spec_json` JSON DEFAULT NULL COMMENT '规格扩展属性，如颜色尺码', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_sku` (`sku_code`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品主表';这段建表语句有几个关键决策点。sku_code加了唯一索引，因为进销存里商品编码是业务主键，重复编码会导致库存对不上。金额字段统一用DECIMAL(12,2)，绝不能用FLOAT，浮点误差在库存金额汇总时会累积成灾难。spec_json用JSON类型存规格，避免了为每个品类建一张属性表的麻烦，MySQL 5.7以上都支持，查询时用JSON_EXTRACT即可。
仓库表和往来单位表（供应商/客户）结构类似，核心是编码唯一、状态可控。供应商和客户可以合并成一张partner表用type字段区分，也可以分开建。我倾向于分开，因为供应商关注结算周期和开票信息，客户关注信用额度和收货地址，字段差异大，合表反而增加理解成本。
2.2 库存表与单据表：为什么不能只存一个库存数量
新手最容易犯的错是库存表只设计一个quantity字段，每次出入库直接加减。这样做的后果是：一旦某次操作出错，你根本不知道错在哪一步，没有后悔药可吃。正确的做法是库存表存当前结存，同时用一张库存流水表记录每一次变动。
-- 库存结存表：按商品+仓库维度存当前数量 CREATE TABLE `inventory` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `product_id` BIGINT UNSIGNED NOT NULL, `warehouse_id` INT UNSIGNED NOT NULL, `qty` DECIMAL(14,3) NOT NULL DEFAULT 0.000 COMMENT '当前结存数量', `locked_qty` DECIMAL(14,3) NOT NULL DEFAULT 0.000 COMMENT '锁定数量，如已下单未出库', `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_prod_wh` (`product_id`,`warehouse_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存结存'; -- 库存流水表：每次变动记一条，可追溯 CREATE TABLE `inventory_log` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `product_id` BIGINT UNSIGNED NOT NULL, `warehouse_id` INT UNSIGNED NOT NULL, `change_qty` DECIMAL(14,3) NOT NULL COMMENT '变动数量，正入负出', `before_qty` DECIMAL(14,3) NOT NULL COMMENT '变动前数量', `after_qty` DECIMAL(14,3) NOT NULL COMMENT '变动后数量', `biz_type` VARCHAR(32) NOT NULL COMMENT '业务类型：purchase_in/sale_out/adjust', `biz_no` VARCHAR(64) NOT NULL COMMENT '关联单据号', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_prod_wh_time` (`product_id`,`warehouse_id`,`created_at`), KEY `idx_biz_no` (`biz_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存流水';inventory表的唯一键uk_prod_wh保证了同一商品同一仓库只有一条结存记录，更新时用INSERT ... ON DUPLICATE KEY UPDATE或先查后更新。locked_qty字段是很多简易源码缺失的，但实际业务里销售订单审核后、出库前需要锁定库存，否则会出现超卖。inventory_log记录变动前后数量，排查库存差异时直接查这张表，能定位到具体哪张单据导致的问题。
单据表分主表和明细表。采购单、销售单、调拨单、盘点单可以共用一套主明细结构，用bill_type区分。主表存单号、往来单位、日期、总金额、状态；明细表存商品、数量、单价、金额。单号生成规则建议用「前缀+日期+序列」，比如PO202501150001，避免用自增ID当单号，因为自增ID会暴露业务量且分库分表时不好处理。
3. 后端接口实现：采购入库与销售出库的完整链路
数据模型定好后，后端接口就是把业务动作翻译成对这几张表的操作。一套ERP进销存系统源码的后端质量，核心看两个链路：采购入库和销售出库。这两个链路跑通，其他单据都是变体。
3.1 采购入库接口：从单据审核到库存增加的原子操作
采购入库的完整流程是：创建采购单→审核→入库→更新库存→记流水。关键点是「审核」和「入库」要分开，审核只是改变单据状态，入库才真正动库存。很多简易源码把这两步合并，导致无法支持「先审核后分批入库」的场景。
# 采购入库核心逻辑（伪代码，框架无关） def purchase_inbound(bill_id, warehouse_id, operator_id): """ 采购入库：校验单据状态 -> 逐行增加库存 -> 写流水 -> 更新单据状态 整个过程必须在一个数据库事务里 """ with db.transaction(): # 1. 行锁锁定单据，防止并发重复入库 bill = db.query_one( "SELECT * FROM bill WHERE id=%s AND bill_type='purchase' FOR UPDATE", (bill_id,) ) if bill.status != 'approved': raise BizError("单据未审核或已入库，当前状态：%s" % bill.status) details = db.query( "SELECT * FROM bill_detail WHERE bill_id=%s", (bill_id,) ) for d in details: # 2. 锁定库存行，避免并发超卖 inv = db.query_one( "SELECT * FROM inventory WHERE product_id=%s AND warehouse_id=%s FOR UPDATE", (d.product_id, warehouse_id) ) before_qty = inv.qty if inv else 0 after_qty = before_qty + d.qty # 3. upsert库存结存 db.execute(""" INSERT INTO inventory (product_id, warehouse_id, qty) VALUES (%s, %s, %s) ON DUPLICATE KEY UPDATE qty = qty + %s """, (d.product_id, warehouse_id, d.qty, d.qty)) # 4. 写库存流水 db.execute(""" INSERT INTO inventory_log (product_id, warehouse_id, change_qty, before_qty, after_qty, biz_type, biz_no) VALUES (%s, %s, %s, %s, %s, 'purchase_in', %s) """, (d.product_id, warehouse_id, d.qty, before_qty, after_qty, bill.bill_no)) # 5. 更新单据状态为已入库 db.execute( "UPDATE bill SET status='inbound', inbound_at=NOW() WHERE id=%s", (bill_id,) ) return {"bill_no": bill.bill_no, "status": "inbound"}这段代码有三个必须注意的参数和逻辑。第一，FOR UPDATE行锁是必须的，否则两个入库请求同时到达会导致库存数量错误，这是血泪经验。第二，ON DUPLICATE KEY UPDATE qty = qty + %s利用了唯一键做原子累加，比先查后更新少一次查询且更安全。第三，before_qty和after_qty在并发下可能因为锁的顺序不同而有微小偏差，如果对流水精确性要求极高，可以在流水表里只记change_qty，before/after作为参考值。
事务边界要覆盖从锁单据到更新状态的全过程。如果中间任何一步失败，整个事务回滚，库存不会变。我见过有的源码把写流水放在事务外，结果库存加了但流水没记，对账时就是一笔糊涂账。
3.2 销售出库接口：库存不足判断与锁定数量释放
销售出库比采购入库多两个判断：库存是否充足、锁定数量怎么处理。销售订单审核时锁定库存，出库时扣减结存并释放锁定。
def sale_outbound(bill_id, warehouse_id, operator_id): """销售出库：校验可用库存 -> 扣减结存和锁定 -> 写流水""" with db.transaction(): bill = db.query_one( "SELECT * FROM bill WHERE id=%s AND bill_type='sale' FOR UPDATE", (bill_id,) ) if bill.status != 'approved': raise BizError("销售单未审核，无法出库") details = db.query("SELECT * FROM bill_detail WHERE bill_id=%s", (bill_id,)) for d in details: inv = db.query_one( "SELECT * FROM inventory WHERE product_id=%s AND warehouse_id=%s FOR UPDATE", (d.product_id, warehouse_id) ) if not inv: raise BizError("商品%s在仓库%s无库存记录" % (d.product_id, warehouse_id)) # 可用库存 = 结存 - 锁定 available = inv.qty - inv.locked_qty if available < d.qty: raise BizError( "商品%s可用库存不足：可用%s，需要%s" % (d.product_id, available, d.qty) ) before_qty = inv.qty after_qty = before_qty - d.qty # 扣减结存，同时释放对应锁定数量 db.execute(""" UPDATE inventory SET qty = qty - %s, locked_qty = GREATEST(locked_qty - %s, 0) WHERE product_id=%s AND warehouse_id=%s """, (d.qty, d.qty, d.product_id, warehouse_id)) db.execute(""" INSERT INTO inventory_log (product_id, warehouse_id, change_qty, before_qty, after_qty, biz_type, biz_no) VALUES (%s, %s, %s, %s, %s, 'sale_out', %s) """, (d.product_id, warehouse_id, -d.qty, before_qty, after_qty, bill.bill_no)) db.execute("UPDATE bill SET status='outbound', outbound_at=NOW() WHERE id=%s", (bill_id,))GREATEST(locked_qty - %s, 0)是为了防止锁定数量被扣成负数。理论上锁定数量不会小于出库数量，但实际业务里可能有手工调整库存的操作导致数据不一致，加个兜底避免负数。可用库存判断用qty - locked_qty，而不是直接用qty，这是支持预售或订单锁定的关键。如果你的业务不需要锁定，可以把locked_qty始终置0，逻辑退化成简单扣减。
出库接口还要考虑负库存是否允许。有些行业（如生鲜）允许先出库后补入库，这时需要配置一个开关，允许qty扣成负数。我一般建议默认不允许负库存，需要时再开，因为负库存是数据混乱的源头之一。
4. 前端交互与单据流转：从表单到库存变动的可视化
后端接口跑通后，前端要做的是让操作人员能顺畅地完成「开单→审核→入库/出库」的动作，并且能直观看到库存变化。ERP进销存系统源码的前端部分，重点不在UI多漂亮，而在表单联动和状态流转是否清晰。
4.1 单据表单的商品明细行怎么实现联动计算
采购单和销售单的核心交互是明细行：选商品、填数量、填单价，自动算金额和合计。这里的关键是「选商品后自动带出参考价和单位」，以及「数量或单价变化时实时重算」。
// 单据明细行联动计算（以Vue为例，React同理） function useBillDetail(initialRows = []) { const rows = ref(initialRows); const totalAmount = computed(() => rows.value.reduce((sum, r) => sum + (r.qty || 0) * (r.price || 0), 0) ); // 选择商品后带出默认单价和单位 async function onProductChange(row, productId) { const product = await api.getProduct(productId); row.product_id = product.id; row.unit = product.unit; // 采购单带进价，销售单带售价，由billType决定 row.price = billType.value === 'purchase' ? product.purchase_price : product.sale_price; recalcRow(row); } function recalcRow(row) { // 金额保留两位小数，避免浮点显示问题 row.amount = Number(((row.qty || 0) * (row.price || 0)).toFixed(2)); } function addRow() { rows.value.push({ product_id: null, qty: 1, price: 0, amount: 0, unit: '' }); } function removeRow(index) { rows.value.splice(index, 1); } return { rows, totalAmount, onProductChange, recalcRow, addRow, removeRow }; }onProductChange里根据单据类型决定带进价还是售价，这个判断放在前端做可以提升体验，但后端保存时一定要重新校验价格，不能信任前端传来的金额。recalcRow用toFixed(2)处理显示精度，但提交给后端的数量建议保留三位小数（DECIMAL(14,3)），因为有些商品按重量计价。
明细行的删除要注意：如果单据已审核，前端应该禁止编辑明细，只允许查看。状态控制在前端做一层，后端接口再做一层校验，双保险。
4.2 库存查询页面：实时库存与流水的关联展示
库存查询是进销存系统里访问最频繁的页面。好的设计是主表显示结存，点击某行展开该商品在该仓库的流水记录。
-- 库存列表查询：带商品名称和仓库名称 SELECT i.product_id, p.sku_code, p.name AS product_name, i.warehouse_id, w.name AS warehouse_name, i.qty, i.locked_qty, (i.qty - i.locked_qty) AS available_qty, i.updated_at FROM inventory i JOIN product p ON p.id = i.product_id JOIN warehouse w ON w.id = i.warehouse_id WHERE p.status = 1 AND (? IS NULL OR i.warehouse_id = ?) AND (? IS NULL OR p.name LIKE CONCAT('%', ?, '%')) ORDER BY i.updated_at DESC LIMIT ? OFFSET ?;这个查询用LEFT JOIN还是INNER JOIN取决于是否需要显示无库存的商品。如果要做「商品全列表+库存左连接」，用product LEFT JOIN inventory，无库存的显示0。上面的写法是只查有库存记录的，适合库存查询场景。分页参数LIMIT ? OFFSET ?在数据量大时性能会下降，超过十万行建议用游标分页（WHERE id > last_id LIMIT ?）。
流水展开查询直接查inventory_log表，按product_id和warehouse_id过滤，按时间倒序。前端展示时把biz_type翻译成中文，biz_no做成可点击跳转到对应单据。这样操作人员发现库存不对时，能自己顺着流水查到是哪张单据的问题，减少沟通成本。
5. 避坑与排查：ERP进销存源码落地时最容易翻车的五个点
这一章是我自己踩过和帮别人排查过的真实问题，按「现象→原因→解决」写。如果你的系统刚跑起来，建议逐条对照检查。
5.1 库存数量对不上，流水和结存不一致
现象：盘点时发现inventory.qty和inventory_log累加出来的数量不一致，差额不大但持续存在。
原因：最常见的是并发入库时没有加行锁，两个请求同时读到相同的before_qty，各自加了一次，但结存只加了一次（或加了两次但流水记错）。其次是某些调整操作直接改了inventory.qty但没写流水。
解决：所有涉及库存变动的操作必须走统一的服务方法，方法内强制写流水。给inventory表的更新加上FOR UPDATE行锁。定期跑对账脚本，用流水累加值校正结存值，差额记录到调整流水里。
5.2 单据审核后还能被修改，导致库存重复变动
现象：一张采购单入库后，操作人员又点了编辑并保存，结果库存被加了两次。
原因：后端更新接口没有校验单据状态，或者前端虽然禁用了编辑按钮但接口仍可被直接调用。
解决：在更新和删除接口里强制校验status，只有draft状态的单据允许修改。已审核或已入库的单据只能通过「反审核」流程处理，反审核要冲销库存并写红字流水。接口层的状态校验不能省，前端禁用只是体验优化。
5.3 商品编码重复导致库存合并错误
现象：两个不同商品因为编码相同，库存被合并到同一条记录，出库时扣错了商品。
原因：sku_code没有加唯一索引，或者导入商品时没有做去重校验。
解决：数据库层加唯一索引是最后一道防线。导入接口要做编码查重，已存在的编码要么拒绝要么更新。如果业务上确实需要允许编码重复（比如不同供应商的同款商品），那唯一键应该改成sku_code + supplier_id或引入内部商品ID作为真正的唯一标识。
5.4 金额计算出现分位误差，对账差几分钱
现象：单据明细金额之和与单据总金额差几分钱，或者库存金额汇总和财务账差几毛。
原因：用了FLOAT或DOUBLE存金额，浮点运算累积误差。或者前端计算金额和后端重新计算时舍入规则不一致。
解决：所有金额字段用DECIMAL，Python里用Decimal类型，JavaScript里金额计算用整数分或引入 decimal 库。统一舍入规则为「四舍五入保留两位」，前后端用同一套规则。单据总金额以明细行金额之和为准，不要单独存一个可能不一致的总金额字段（或存但定期校验）。
5.5 并发出库导致超卖，可用库存判断失效
现象：两个销售单同时出库同一商品，各自判断可用库存都够，结果扣减后库存变成负数。
原因：判断可用库存和扣减库存之间没有锁，两个事务读到了相同的库存值。
解决：把「查询库存」和「扣减库存」放在同一个事务里，查询时加FOR UPDATE。或者用乐观锁，更新时带条件WHERE qty - locked_qty >= %s，根据影响行数判断是否成功。高并发场景建议用乐观锁+重试，比悲观锁吞吐量高。
6. 进阶技巧：用库存快照和定时对账把数据可靠性拉满
前面五章把一套ERP进销存系统源码的核心链路讲完了。最后分享两个我在实际项目里必做的进阶动作，能让系统在长期运行后依然保持数据可信。
第一个是库存快照。流水表会越来越大，每次查历史库存都累加流水不现实。做法是每天凌晨跑一个定时任务，把当前inventory的结存值写入inventory_snapshot表，记录日期、商品、仓库、数量。查任意历史时点的库存时，找最近的快照加上之后的流水即可。快照表按日期分区，保留一年，超期归档。
-- 每日库存快照（定时任务执行） INSERT INTO inventory_snapshot (snap_date, product_id, warehouse_id, qty, locked_qty) SELECT CURDATE(), product_id, warehouse_id, qty, locked_qty FROM inventory ON DUPLICATE KEY UPDATE qty = VALUES(qty), locked_qty = VALUES(locked_qty);ON DUPLICATE KEY UPDATE保证同一天重复执行不会产生重复快照，唯一键是(snap_date, product_id, warehouse_id)。这个任务放在业务低峰期执行，数据量大时分批处理，每批一千条，避免长事务锁表。
第二个是定时对账。每天跑一次全量对账，用inventory_log的累加值（从上次对账点开始）去校正inventory.qty，差额超过阈值的记录生成告警。对账脚本的核心逻辑是：
def reconcile_inventory(): """对账：流水累加值 vs 结存值，差额写调整流水""" last_check = get_last_check_time() # 按商品+仓库分组累加流水变动 flow_sums = db.query(""" SELECT product_id, warehouse_id, SUM(change_qty) AS total_change FROM inventory_log WHERE created_at > %s GROUP BY product_id, warehouse_id """, (last_check,)) for row in flow_sums: inv = db.query_one( "SELECT qty FROM inventory WHERE product_id=%s AND warehouse_id=%s", (row.product_id, row.warehouse_id) ) # 这里需要结合上次对账时的结存值计算，简化示意 diff = abs(inv.qty - row.total_change) if diff > 0.001: # 允许千分之一误差 log_warning("库存差异：商品%s 仓库%s 差额%s", row.product_id, row.warehouse_id, diff) # 生成调整流水，把结存校正到流水累加值 adjust_inventory(row.product_id, row.warehouse_id, diff) set_last_check_time(now())对账的阈值不要设成0，因为并发场景下before_qty/after_qty可能有微小偏差，设一个合理容差（比如0.001）避免误报。真正需要关注的是差额持续扩大或单次差额很大的记录，那通常意味着有代码路径绕过了统一库存服务。
我自己的习惯是：任何一套进销存源码，先跑通采购入库和销售出库，然后立刻把对账脚本挂上。数据可靠性不是靠代码写得多完美，而是靠有对账兜底。系统跑三个月后，对账告警一直为零，你才敢说这套源码是真的稳。希望帮到你。
本文还有配套的精品资源，点击获取
