多商户SaaS化ERP系统设计：多仓库库存与扫码进销存实战

简介：一套基于PHP的SaaS版多商户多仓库ERP进销存管理系统源码，面向需要快速搭建云端多商户平台的技术人员、创业者或中小企业。系统支持无限开通商户，用户可前端自助注册，由后台管理员审核并设置到期时间与权限；支持多企业、多子公司、多门店、多仓库四级架构，总公司和子公司账号可切换到各门店级别操作，且各层级数据独立又可按需汇总，同级或跨级仓库均可调拨。功能涵盖扫描入库、库存预警、仓库管理、商品管理、供应商管理等，电脑端与手机端数据实时同步；测试环境为PHP5.6+MySQL5.6。资源为zip压缩包，共1333个文件，约21.64MB，以509个PHP文件为核心，配合JS、CSS、HTML等前端文件及图片、配置文件，构成完整可部署的源码项目，目录结构清晰，便于二次开发。已有1895人浏览学习，适合用于搭建实际SaaS服务，也适合作为PHP多商户系统开发的学习范例。 我做过不少进销存和ERP相关的项目，最近又完整梳理了一套多商户、多仓库场景下的SaaS化ERP系统设计，正好借这篇博文把核心逻辑和实操经验整理出来。如果你正在选型ERP源码、准备做SaaS化改造，或者为多仓库库存核算头疼，这篇内容应该能帮你省掉不少弯路。

先说一下这套系统到底解决什么问题。传统单机版进销存软件，数据存在本地，仓库多了、门店多了、商户多了以后，库存账目对不上、数据汇总慢、权限混乱，这是最常见的几类痛点。而标题里的“多商户、多仓库、SaaS化、无限商户版、扫码云进销存”，其实是在说一套完整的分租户、分仓库、支持移动端扫码作业的云端ERP系统。下面我从架构、数据模型、库存核算、移动端应用几个维度，把这套系统的技术细节拆开讲。

1. 多商户SaaS架构的第一道分水岭：租户隔离方案怎么选

做SaaS化ERP，最先要拍板的就是租户隔离方案。没有经验的人直接按单租户思路做，后期一定会被数据安全和扩展性问题反噬。目前业界主要做法就三种：独立数据库、共享数据库独立Schema、共享表加租户ID字段。实际交付中，我见过最多的是第三种，因为成本低、维护方便，但坑也最多——每个SQL都要带tenant_id，漏一条就是串数据事故。

1.1 三种隔离方案的成本与适用场景对比

我直接说结论，这套多商户ERP系统推荐走“共享表+租户ID”的路线，但在关键业务表上做双保险：既保留租户ID字段，又给核心订单表建联合唯一索引。这么做的好处是显而易见的：单租户数据量大时，可以按租户ID做分表分库；而查询层只要在ORM基类里统一注入租户过滤条件，就能防止开发者手滑写出跨租户的SQL。下面这个表格是决策依据：

对于“无限商户版”这种定位，共享表+租户ID几乎是唯一合理选择。原因很直接：独立数据库方案在商户数量上百后，备份、迁移、跨库统计全部变复杂，运维成本完全失控。但要注意，共享表方案必须在数据库访问层统一封装数据权限，而不是靠每个开发人员自觉，这一点做不到，后面积累的技术债会非常沉重。

1.2 商户套餐与功能权限的落地逻辑

租户隔离只是地基，上面还得建“套餐-功能-商户”三层权限体系。商户购买不同套餐，能看到的功能菜单、能用的仓库数量、可创建的员工账号数都应不同。这块我的做法是在数据库里设计一张tenant_package表记录套餐信息，再用tenant_permission做商户和功能点的多对多关联。

权限判断要放在前端路由守卫和后端接口中间件两层。前端控制菜单显示，后端控制接口访问，两者缺一不可。别只做前端隐藏，因为懂一点HTTP请求的用户完全可以绕过界面直接调接口，只有后端鉴权才能真正拦住越权访问。

另外一个容易忽略的点是：仓库和商户的绑定关系也属于权限范畴。某个商户建了5个仓库，另一个入驻的供货商型商户可能只能看到自己的2个仓库，这种数据范围的权限控制，需要一套warehouse_tenant_map表来管理。

2. 多仓库库存模型：账面库存、可用库存与在途库存为何必须分开

库存模型是整个ERP系统里最容易做错的部分。很多进销存系统只设计一个“库存数量”字段，开单就加、出库就减，看似简单，一旦遇到采购在途、销售锁定、多仓库调拨这些场景，账目立刻乱套。这套多商户系统里，我坚持把库存拆成三层：账面库存、可用库存、在途库存。

2.1 库存字段拆解与计算公式

• 账面库存：商品在当前仓库实际拥有的总数，也是盘点时对账的依据，等于采购入库数量加上调拨入库，减去销售出库、采购退货、报损等。
• 锁定库存：用户提交销售订单但未正式出库前占用的数量，这个字段直接避免超卖。
• 可用库存：账面库存减去锁定库存后的值，也是前台展示给营业员看的那个“有货”数字。
• 在途库存：采购单已审核但从供应商发货到仓库收货期间的数量，对企业财务和采购计划很重要。

可用的计算公式其实不复杂：可用库存=账面库存-锁定库存，但计算时机很讲究。我是在每次库存流水写入时实时更新对应仓库的库存汇总表，而不是每次查询时去汇总所有流水。这个设计决策，可以保证高并发下查询速度快，还能避免大促时段数据库被汇总语句拖垮。

2.2 库存流水表如何做到可追溯

任何库存变化都必须记录流水，且流水不可修改、不可删除。每次出入库都要记录操作前数量、操作后数量、变动数量、业务单据号、操作人、操作时间。这套设计带来的直接好处是：当库存对不上账时，可以通过流水完全还原每笔业务，快速定位哪张单据导致差异。

流水表里我还有一个关键设计——来源单号字段。它记录的是“这次库存变动是哪个单子触发的”，比如销售出库单、采购入库单、盘点调整单。有了这个字段后，做库存明细穿透查询时，可以从库存汇总一路追踪到原始单据，整个链路是闭环的。售后排查的效率提升非常明显。

2.3 多仓库调拨的库存转移细节

多商户系统里调拨是个高频业务，仓库A调拨到仓库B，经常出问题的点是“调拨中”状态的库存怎么处理。我的做法是引入调拨在途仓：审核调拨单后，仓库A账面库存减少、调拨在途量增加；B仓库确认收货后，调拨在途量减少、仓库B账面库存增加。这样做的好处很明显——财务对账时，在途库存有据可查，不会凭空消失或出现。

3. 扫码云进销存：从PDA到手机，移动端作业的落地体会

标题里“扫描云进销存”这块，早期很多系统用PDA扫码，硬件成本高、系统封闭。现在趋势已经很明确：手机摄像头扫码配合云服务，成本最低、部署最快。这套系统的移动端我推荐用H5或小程序的方式实现，而不是做原生App，原因是商户员工换手机频率高，H5跨平台兼容性好，微信小程序和支付宝小程序还能免安装直接打开。

3.1 扫码场景的三种业务路径

• 采购收货：扫商品条码，系统自动带出采购单和该商品的预期到货数量，录入实收数量，确认后自动生成入库单。核心价值就是彻底告别纸张单据，也免去了手工录入的误差。
• 销售开单：门店收银员扫商品码，商品信息自动进入购物车，同时后端实时校验可用库存，库存不足时当前商品会有明显提示，而且无法提交订单。
• 盘点作业：拿着手机沿货架逐品扫码，系统自动记录扫码次数，盘点结束后把扫码明细与账面库存做差异比对，差异数据生成盘点调整单。

接入扫码最先要解决的是条码规则问题。商品条码一般分三种：69开头的中国商品条码、企业内部自定义的SKU条码、以及含有批次信息的复合条码。我在设计商品表时，把barcode字段设为可空但加了唯一索引，同时在商品条码表中保留多码关联，同一个商品允许有多个条码，这样能轻松处理“一个商品多个条码”的现实业务。

3.2 离线扫码与弱网环境的处理

云进销存系统最怕的场景是：仓库在地下室或偏远库区，手机没有信号，扫码后数据发不出去。针对这个情况，我建议移动端必须做离线队列：扫码先写本地缓存，网络恢复后自动同步到服务端，同时每个操作生成一个本地UUID，服务端按UUID做幂等判断，避免重复提交。

4. 采购、销售、库存联动：单据流与状态机的设计细节

刚接触进销存系统的人，容易把采购单、销售单、入库单、出库单当成彼此独立的表单。实际设计时它们必须通过状态机联动，否则业务流程根本跑不通。从技术实现看，一套清晰的状态流转规则能避免大量“脏数据”。

4.1 采购业务的核心状态流

采购单的状态设计我一般拆成：草稿、已审核、部分到货、全部到货、已关闭。审核后自动生成待入库记录，采购收货时逐单关联入库单；全部到货后采购单自动变为完成状态。这套流程的价值是：采购员能实时看到哪些订单到货了、哪些还在路上，财务对账也轻松很多。

4.2 销售业务与库存扣减时机

很多系统一提交销售订单就扣库存，这个设计在业务上是有问题的。用户提交订单只是锁定了库存，真正出库时才扣减账面库存。如果客户下单后反悔不买了，订单取消释放锁定库存；如果出库后客户退货，则系统自动生成退货入库单，把库存加回原仓库。针对“下单时扣减可用库存、出库时扣减账面库存”的策略，整个链路非常清晰，也天然支持超卖拦截。

4.3 组合商品与拆零业务的库存处理

多商户场景里，经常遇到组合商品和拆零销售。比如A商品是一箱12瓶，B商品是单瓶装。实物库存只记录箱数，但客户可能买3瓶。这种场景我用“双单位换算”来解决：商品表存基础计量单位和换算率，库存明细里始终以最小单位存储数量，业务单据输入时自动做单位换算。这样的设计能把库存核算粒度做到最细，避免因四舍五入导致账实不符。

5. 无限商户版的技术陷阱：性能、扩展性和二次开发的取舍

标题里“无限商户版”这几个字，很多开发者当成营销话术，实际上它直接压着技术架构的天花板。商户量级从几十到几千，系统的数据模型、缓存策略、任务调度都要跟着变，这里展开讲讲几个关键点。

5.1 数据量增长后的分页与统计性能

在多租户共享表架构下，商品表、订单表的数据量会随着商户数量线性增长。一个常见的问题是：后台要查一个商品在全部仓库的库存，如果做成SELECT * FROM stock WHERE product_id = ?，数据量大以后必然慢。我的思路是维护一张product_stock_aggregate汇总表，字段包含商品ID、仓库ID、租户ID、总库存和锁定库存，所有库存操作在事务里同时更新流水表和汇总表。查询时直接走汇总表，速度快很多，也不会因为库存表行数膨胀而性能下降。

这套机制要注意的维护点：如果某次库存操作只更新了流水，没有同步更新汇总表，就会出现数据和实际不一致的情况。所以更新汇总表和写流水必须在同一个数据库事务里，任何异常都要一起回滚。

5.2 二次开发时最容易踩的“订单号生成”雷

很多源码交付项目，后期二次开发最痛的是单号生成逻辑。如果系统用“最大单号+1”的方式生成订单号，高并发下一定会出现重复或锁等待。建议一开始就采用分布式ID生成方案，比如：时间戳加商户ID加自增序列的组合方式。这样既能保证全局唯一、也方便从订单号看出归属租户和创建时间。

5.3 源码交付项目的隐藏维护成本

既然标题提到“源码”，那就要说说源码类ERP项目在落地时容易忽略的问题。每个商户的业务流程多少有点差异，有的需要审核流程、有的不需要；有的要求强制批次管理、有的按先进先出就行。一套好源码必须提供足够的开关配置，而不是每来一个客户就改一套代码。我见过太多源码项目因为定制化改得面目全非，后续升级完全没法做，最终推倒重来。

比较理想的处理方案是：核心公共逻辑沉淀在底层，业务差异通过配置项控制。系统设计时预留了参数配置表，把批次管理、负库存、审核流程、价格精度等常用差异点全部做成开关，二次开发时尽量避免改动底层逻辑。

6. ERP源码选型时我的四点建议

如果你正在评估买哪套ERP源码，或者准备基于开源系统二次开发，我这几个建议应该能帮到正在纠结的你。

第一，先想清楚是自用还是商用。自用系统重点看功能匹配度，商用部署则要看架构是否支持多租户隔离，以及授权协议是否允许你无限开商户。市面上有些源码打着“无限商户版”旗号，但用户体系实际上只支持一套基础数据，这通常意味着二次开发量巨大。

第二，看清技术栈能不能接住你的运维能力。如果团队只有PHP经验，买一套Java微服务的源码，后续维护门槛会非常痛苦。对应的，如果你只有Mysql单机经验，直接上微服务加分布式事务，反而会增加不稳定因素。技术栈匹配比功能全面更重要。

第三，关注报表和打印部分。很多进销存系统业务功能尚可，但报表功能非常薄弱。ERP落地时老板最常看的就是各类汇总报表，包括销售日报、毛利分析、库存周转表等。如果源码自带报表设计器或者至少留有自定义报表的接口，会为后续交付省十倍精力。

第四，确认移动端源码是否一起交付。很多所谓“扫码进销存”系统的源码只包含后端服务，App端只给一个编译好的安装包，二次开发极不方便。如果需要定制扫码页面或对接自己的打印机，建议一开始就选择前后端和移动端全套源码交付的项目。

最后再说一点我个人特别看重的经验：看一套ERP源码好不好，最快的检验方式是看它的库存调整单和盘点单有没有做“审核”机制。库存调整是最容易出猫腻的环节，如果随便一个操作员都能无痕改库存，这个系统的安全性就是空谈。正规系统里库存调整必须关联单据编号，走“申请-审核-执行”流程，所有调整留痕可追溯，这套设计理念建议你也把它作为选型时的硬性标准。

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