简介一套基于PHP的SaaS版多商户多仓库ERP进销存管理系统源码面向需要快速搭建云端多商户平台的技术人员、创业者或中小企业。系统支持无限开通商户用户可前端自助注册由后台管理员审核并设置到期时间与权限支持多企业、多子公司、多门店、多仓库四级架构总公司和子公司账号可切换到各门店级别操作且各层级数据独立又可按需汇总同级或跨级仓库均可调拨。功能涵盖扫描入库、库存预警、仓库管理、商品管理、供应商管理等电脑端与手机端数据实时同步测试环境为PHP5.6MySQL5.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。下面这个表格是决策依据隔离方案数据隔离强度数据库成本维护复杂度适合阶段独立数据库最强最高较低大客户私有化、合规要求严格共享库独立Schema中等偏强中等中等有一定预算的多租户平台共享表租户ID逻辑隔离最低最高中小商户量大、追求性价比对于“无限商户版”这种定位共享表租户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源码好不好最快的检验方式是看它的库存调整单和盘点单有没有做“审核”机制。库存调整是最容易出猫腻的环节如果随便一个操作员都能无痕改库存这个系统的安全性就是空谈。正规系统里库存调整必须关联单据编号走“申请-审核-执行”流程所有调整留痕可追溯这套设计理念建议你也把它作为选型时的硬性标准。本文还有配套的精品资源点击获取