企业官网建设流程全解析

很多人一听到“多店进销存”这几个字，第一反应就是大厂那套动辄几十万的企业方案，或者 SaaS 年费越交越心疼的订阅制产品。但我今天想聊的是另一条路：找到一套亲测可用的多店进销存管理系统源码，自己部署、自己改、自己掌握数据。这套东西解决的核心问题，其实就是连锁门店、分仓多点、品牌多店铺的老板们最头疼的库存同步、采购往来、门店调拨和利润核算。

文章适合谁？适合有三五家以上门店但不想被 SaaS 绑架的运营者，适合接私活需要快速交付方案的开发者，也适合想把进销存逻辑彻底搞明白再自己动手改一版的技术爱好者。我不会只丢一个“源码下载”链接了事，而是把整套系统的设计思路、核心表结构、关键代码逻辑、部署步骤和踩坑记录全部拆开讲清楚，你拿过去至少能省两周的试错时间。

1. 搞懂多店进销存的核心痛点，再动手选源码

1.1 单店软件搬到多店场景，为什么总是别扭

很多人一开始图省事，用单店版进销存让每家门店各装一套，结果月底对账直接崩溃。A 店卖出去的商品B 店还在库里躺着，总部压根不知道货去哪了。其实多店进销存和单店版的本质区别不在于“门店数量多了一个字段”，而在于数据组织和业务流程的复杂度完全不同。

单店模式只需要考虑一个库存账本、一个采购入口、一个销售出口。多店模式下，你至少得处理三个核心问题：总部的货发到门店A和门店B之后，库存归属怎么算；门店A缺货，是从总部调还是从门店B调，调拨过程要不要算成本差异；月底各门店的毛利、滞销品、员工提成怎么独立核算。

我接手的某模拟项目之前用的是 Excel 加微信群报数，后来发现每次盘点都要花一整天，而且永远有漏报错报。换成这套源码之后，最大的变化不是“有系统了”，而是“每个门店都只对系统负责”，所有数据流动在系统里自动留痕，不用再靠人肉对账。

1.2 选型之前，先梳理必须满足的功能清单

找源码最容易犯的错是看到界面漂亮就下载，装完发现连门店调拨都没有，白折腾。我建议你先在纸上列一个功能红线清单，凡是没有下面这几项的直接放弃，省得浪费时间。

• 多门店基础资料独立维护，但商品资料可以共享或按门店单独定价。
• 每个门店有独立库存账，支持总部统管库存和门店独立库存两种模式。
• 采购入库可以直接入到总部仓，也可以直入门店仓。
• 门店调拨要带出库、入库双动作，调拨单要能追溯。
• 销售出库支持零售和批发，批发最好能关联客户和欠款。
• 盘点功能必须覆盖盘点冻结、差异生成、盘盈盘亏处理。
• 报表要包括库存汇总、进销存明细、毛利分析、门店销售排行。

这套源码最打动我的地方，是它在“库存独立与统一”上的处理很灵活。既支持总部统一采购后按需分货，也支持各门店自行采购、独立核算。对绝大多数中腰部连锁来说，这两种模式往往同时存在，能在一套系统里兼容就很省事。

2. 源码技术方案怎么选，决定了你能不能用得长久

2.1 优先考虑三大主流技术栈，别碰冷门框架

源码的“可用性”一半取决于功能，一半取决于技术栈。我见过有人拿着十年前 ASP 写的老古董当传家宝，装一次环境能疯掉。以我实测和帮朋友部署的经验，优先看这三种组合：

• PHP + MySQL：部署门槛最低，虚拟主机就能跑，适合纯粹为了管理门店、不想折腾服务器的老板。
• Java（Spring Boot）+ MySQL：适合对并发和二次开发有要求的场景，后期加接口、接小程序、对接第三方支付都方便。
• Python（Django/Flask）+ MySQL：开发效率高，适合懂 Python 的技术型店主自己改需求。

我自己部署的这套用的是 PHP 版本，原因很简单：授权给门店员工用的时候只要能跑就行，PHP 环境在 Linux 服务器上用宝塔面板点几下就完事，后续维护成本几乎为零。如果你计划以后做会员系统、对接外卖平台、甚至上数据分析大屏，那直接上 Java 那版更稳，省得将来推倒重来。

2.2 数据库表设计才是源码的灵魂

界面可以丑，代码可以老，但表结构烂了的源码绝对不能用。我拿到一套源码的第一件事不是跑起来看页面，而是打开数据库看表设计。多店进销存系统有几个核心表是一定要检查的：

门店表：门店编号是全局唯一的，不能拿自增主键当业务编号用。必须有状态字段，不然关店之后历史单据会变成孤儿数据。

商品表：sku_code 全局唯一，商品分类最好有层级，这样报表才能按大类汇总。

库存表：这是多店系统的分水岭。核心不是“一个商品一行库存”，而是“一个商品在每个门店一行库存”。字段至少要包含门店 ID、商品 ID、可用库存、冻结库存、锁定库存三个维度。

单据主表和明细表：不管入库、出库还是调拨，都是“主表记录单号和时间，明细表记录商品和数量”的两层结构。没有这种结构的系统扩展性极差，你连一个“整单作废”的功能都做不干净。

流水表：必须有库存流水。库存表里只存当前数量，流水表记录每一次增减的来源，这样才能追溯“库存去哪了”。

我见过最典型的烂设计，是拿单店版的库存表直接加了一个 shop_id 字段就当作多店版卖。表面看也能按门店查库存，实际上是库存计算全乱套，一张销售单只会扣掉默认门店的库存，调拨单做完总部库存和门店库存能对不上账。检查这套源码的表结构时，我发现它的调拨单设计得很细，从出库确认到入库确认分成了两个状态，彻底避免了调拨途中的账实不符。

2.3 源码质量快速评估的三个实操技巧

在没跑起来之前，怎么判断一套源码值不值得花时间部署？我总结了一套十分钟快速体检法。

第一，打开源码里的配置文件，看数据库连接、缓存、日志路径是不是集中管理的。如果到处硬编码数据库密码，这代码维护起来绝对是灾难。

第二，看有没有独立的权限表或者权限控制层。多店系统最怕员工跨店看到别人的成本和库存，没有权限控制的源码还不如用 Excel。

第三，搜索一下代码里有没有写死的门店 ID、门店名称之类的内容。多店系统一旦门店维度写死，后面新增门店就要改代码，这种源码直接弃坑。

这套源码在权限设计上做得比较踏实。员工表、角色表、权限节点表是完整的 RBAC 结构，总部角色能看到所有门店数据，门店角色只能看到本店数据，普通店员连成本价都看不到。对于管理十几家店的场景，这个设计起码能扛住大部分内部管理的需求。

2.4 部署后验证“可用”的判定标准

“亲测可用”不能停留在“能打开登录页”。我每次拿到源码部署完之后，都按一套标准动作做验收，全部通过才算可用。

先在两个门店里分别建商品，A 门店库存设 50，B 门店库存设 30。然后用 A 门店做一张销售单出 10 件，验证 A 库存变 40、B 库存不变。再建一张调拨单，A 店调 5 件到 B 店，确认后 A 变 35、B 变 35。最后看报表里进销存汇总数字是不是和手工算的完全一致。这套动作 20 分钟能跑完，能挡住九成的不合格源码。

3. 核心功能模块怎么实现的，直接看代码逻辑

3.1 库存扣减的正确写法，别用简单的 UPDATE 减库存

很多新手源码处理销售出库，就是那么简单粗暴：

UPDATE stock SET available_qty = available_qty - 5 WHERE shop_id = 1 AND sku_id = 100

这种写法在并发高的时候极容易出问题。两个收银员同时按下结算，数据库里执行的是“读出 5 再写回 0”，一旦没有锁或者没有条件判断，最后库存就变成负数了。

更好的写法是把库存操作全部收敛到统一的服务层，并且用带条件的更新来做原子操作：

UPDATE stock SET available_qty = available_qty - 5 WHERE shop_id = 1 AND sku_id = 100 AND available_qty >= 5

更新完后判断受影响行数，如果行数是 0 说明库存不足，整单回滚并提示。这套源码里的逻辑就是这种思路，批量出库时用了事务包裹，任何一个明细库存不足都会整体回滚，不会出现部分扣款成功、部分提示失败那种骑虎难下的状态。

3.2 调拨单的完整链路，状态机设计是关键

调拨是多店系统里最容易写错的功能。我见过不少源码做调拨就是直接在两个门店的库存表里各做一次加减，完全没有单据生命周期，出了问题根本查不了来龙去脉。

我部署的这套源码把调拨做成了标准的两段式流程。总部或者上级门店发起调拨单时，库存表先把“可用库存”减掉一部分放到“调拨在途”字段，然后生成一条调拨流水。门店确认收货之后，系统才把“在途库存”清零，同时增加本店可用库存。如果调拨单被取消，在途库存自动回到原门店可用库存。

这个设计非常实用。调拨不是“瞬间完成”的，中间涉及物流时间，如果在途期间不做账，财务和库管眼里这批货就是“凭空消失”了。在途字段虽然只是多一个数字，却是整个系统账实相符的基石。

3.3 报表统计不能只做 SUM，多店对比才是精髓

报表模块是最能拉开源码差距的地方。傻瓜型报表就是把所有门店的销售数据 SUM 在一起，看起来利润总额没毛病，但一问“哪家店贡献最大”“哪家店库存周转最差”就哑火了。

好的报表逻辑应该围绕门店维度做透视。一张销售汇总报表，默认列是“日期、门店、销售额、成本、毛利、毛利率”，行数据按门店分组，点击某个门店还能下钻到具体商品明细。这套源码里最有价值的一张报表是“进销存汇总表”，它的逻辑是把一段时间内每个 SKU 的期初库存、采购入库、调拨入库、调拨出库、销售出库、期末库存全部列出来。

单看这张表你可能觉得没什么特别，但实际经营里“期初加入库减出库是否等于期末库存”是财务对账的黄金公式。系统里这个数字如果对不上，就一定能在流水表里查出问题。很多 Excel 管店的人最痛苦的就是对不齐这张表，而源码系统直接从数据库里核账，基本不会出现人为加减错误。

3.4 多店权限控制的落地写法

权限控制在代码层面实现方式很多，但有经验的开发者会关注两个细节。一个是对数据的行级过滤，也就是“门店维度隔离”。另一个是对页面操作按钮的级别控制，也就是“总部按钮和门店按钮分开”。

行级过滤最简单的实现方式是给每个门店员工设置默认门店 ID，查询所有业务数据时强制拼接条件：

$this->db->where('shop_id', $this->user->shop_id);

但如果员工身兼多店管理，就需要在权限表里维护一个“可管理门店列表”，查询时用 IN 条件来过滤。这套源码在登录之后把当前用户的门店范围注入到全局数据对象里，后续所有查询自动带着这个条件，从根源上堵死了越权查询。

按钮级别控制在代码里就是权限节点判断：

if (!$this->auth->check('stock.transfer.create')) { exit('无权限操作'); }

为什么不推荐只在页面隐藏按钮的方式？因为懂技术的人直接拼接 URL 就能绕过按钮调用接口。必须在接口入口做二次校验，页面隐藏只是体验优化，入口校验才是真正的安全保证。

4. 把源码从压缩包变成能用的系统，完整部署实录

4.1 环境准备和参数选择

部署这套源码之前，我先把服务器环境捋了一遍。PHP 版本要求 7.4 以上，MySQL 要求 5.7 以上，Web 服务器用 Nginx 和 Apache 都行。我实测下来 Nginx 加 PHP-FPM 的组合跑进销存这种 IO 密集型应用更稳，并发稍微高一点的场景不会动不动 502。

数据库建议单独建一个库，不要和别的项目混在一起，这样备份恢复都省心。字符集选 utf8mb4，别问为什么，涉及商品名称里有生僻字或者 emoji 的时候你就知道好处了。

PHP 配置里有两个参数容易被忽略。一个是 upload_max_filesize，商品图片如果比较多，默认 2M 太小，建议改成 20M。另一个是 max_execution_time，批量导入商品 Excel 的时候执行时间很容易超 30 秒，建议调到 300 秒。

4.2 配置文件和数据库初始化

源码下载解压后，第一件事是改配置文件。数据库连接信息集中在 /config/database.php 里：

'host' => '127.0.0.1', 'username' => 'your_db_user', 'password' => 'your_db_password', 'database' => 'erp_multi_shop'

记得把调试模式关掉，不然报错信息直接暴露给用户，既不安全又难看。然后把 install.sql 导入数据库，导入的时候我习惯用命令行的方式而不是用网页版数据库工具，因为文件稍微大一点网页工具就会超时：

mysql -u root -p erp_multi_shop < install.sql

导入完成之后打开安装目录下的初始化脚本，填入管理员账号和默认门店信息。这一步的关键是设置好总部的门店类型，因为后续创建的门店都挂在这个顶级节点下面，总部门店一旦创建错误，后面的层级关系会全部乱掉。

4.3 创建门店、员工和初始库存

部署完成后我做的第一件事不是急着录商品，而是先把组织架构搭好。进销存系统是先有门店，然后有员工，最后才有业务单据，这个顺序反了后面全是坑。

在基础资料里创建三个测试门店：总部仓、中心店A、社区店B。总部仓在系统里也占一个门店 ID，但它本质上承担的是中央仓库职能，可以不用设置前台收银功能。中心店A和社区店B则要设置独立的收银台参数、默认打印样式和门店地址信息。

创建完门店再建员工账号。我给总部运营人员配一个“总部管理员”角色，给两个门店店长配“门店店长”角色，再给店员配“收银员”角色。这三个级别的权限各测一遍，重点确认店员能不能看到成本价、店长能不能审批调拨单、总部能不能看到所有门店的销售报表。

最后一步是导入初始库存。这套源码支持从 Excel 导入商品和期初库存，我建议第一次导入一定要下载它的模板来填，不要自己另做表头。模板里带了一个示例数据，对应字段含义一目了然，比看文档快多了。导入完成后到库存汇总页面核对一下有没有数量和金额异常的商品。

5. 部署和试运行阶段最容易踩的坑

5.1 库存数据对不上，先从流水表开始排查

试运行第一周，最容易收到的反馈就是“库存不对”。我自己的处理套路是这样的：先找到差数最大的那个 SKU，看它的库存流水，把流水按时间排序列出来，找到第一次出现异常的节点。

常见的异常原因有三个。采购入库单没有审核，库存虽然显示增加了但财务确认那边还是空白的；销售退货单没有走红冲逻辑，导致库存增加但销售额负向统计；调拨单收货方已经确认，但出库方忘记审核出库，两边库存不在同一时间点变化。

这套源码里库存流水表记录得很清楚，每个动作都有单据类型、来源单号、变动方向、变动前后数量。排查了几次之后你会发现，九成以上的“库存不对”根本不是系统 bug，而是操作流程没走完。真正有问题的反而是那种系统允许“直接改库存数”的便捷功能，一旦有人用了，流水里看不出任何来源，账就成了糊涂账。

5.2 并发开单导致的超卖问题

传统进销存系统都是内网运行，并发不严重。但现在很多老板会把系统部署到公网服务器上，让门店通过浏览器访问，收银高峰时开单并发一上来，超卖就暴露了。

我在压测这套源码的销售出库接口时，用工具模拟了 50 个并发请求同时扣减同一个 SKU 的库存。结果发现偶尔会有个别请求多扣了数量。排查后定位到问题在库存预检和库存扣减之间没有加锁。解决办法是把查询库存和扣减库存合成一个 SQL 操作，用上面提到的条件更新写法，受影响行数为 0 就返回库存不足。

为了稳妥，我又在业务层加了一层 Redis 锁，同一 SKU 的扣减请求先争锁，拿到锁的才执行数据库操作。实测下来并发 100 以内不会出现超卖。如果你店里高峰期同时开单的人少于 50，这套方案已经绰绰有余。

5.3 员工看到了不该看的成本价

权限模块的坑比较隐蔽。有次试运行阶段店长跟我反馈，说收银员在商品列表页面按 F12 看了一下接口返回的数据，里面带着成本价字段。虽然页面没显示，但数据已经回到前端了，这就是安全设计上的疏漏。

解决方法是后端返回给前端的数据一律剔除成本相关字段。我在这套源码的 API 层加了一个字段过滤函数，对商品列表、销售单明细这类可能暴露给收银端的接口，统一使用不带成本信息的 DTO 结构输出。成本数据只在总部报表接口和店长报表接口里返回。

用这套思路顺带排查了其他几个接口，把采购单里的“最后进货价”也做了同样的处理。实际落地之后基本堵住了这个信息泄露点。

5.4 备份恢复千万别只备份数据库

源码系统的完整备份包含两部分：数据库和上传文件。很多人只备份了数据库，结果系统崩溃重装之后商品图片全没了。我在部署时写了一个简单的定时任务，每天凌晨把数据库 dump 加上 upload 整个目录打包上传到备份存储空间。

恢复流程我也实测过。先把代码重新部署好，然后把 upload 目录解压覆盖回去，最后导入数据库备份。整套动作半小时内能完成。这套源码还自带一个数据库备份功能，但我发现在文件量比较大的情况下，PHP 自带备份容易超时，还是直接用系统层面的 mysqldump 更可靠。

6. 试运行两周后的使用心得和调优建议

6.1 把“盘点差异”变成管理工具，而不是找茬工具

刚开始门店店员很抗拒盘点，总觉得系统就是来查他们有没有贪货的。我调整了使用思路，每周盘点不是为了抓错误，而是为了发现流程漏洞。比如社区店B连续两周盘亏都是同一款饮料，查了流水之后发现是赠品出库没有走单据，而是直接拿了库存。找到原因之后给赠品单独做了一个出库类型，第三周差异直接消失了。

6.2 分析报表要按门店拆，别只看汇总

部署完这套系统之后，我最大的收获是看清楚了各家门店的真实经营状况。以前用 Excel 看汇总，只知道整体是赚钱的。通过系统的门店维度报表，才发现社区店B的毛利贡献其实很低，房租水电一摊可能还是亏的。

测试期间我用系统导出了各门店的“滞销品清单”，发现中心店A有款商品三个月没动销，但库存资金占了不少。处理掉这批滞销货之后，现金流压力明显小了。这就是多店进销存真正值钱的地方：数据细化到门店之后，你的管理动作才会更有针对性。

6.3 这源码后续还能扩展什么

用顺手了之后，我又在这套系统上面做了两个小扩展。一个是接了企业微信通知，调拨单发起和审核通过后自动推送到当事人，门店之间的协作效率提升了不少。另一个是做了库存预警，低于安全库存的商品会在每天早上汇总推送到管理群，采购再也不用靠拍脑袋补货。

如果你有开发能力，下一步比较推荐的方向是给门店做一个小程序端导购数据查询，只开放本店库存和销售业绩，不让导购接触采购和成本数据。这方面的接口这套源码留得还算开放，二次开发难度不大。如果完全不写代码，自定义报表的需求也可以通过导出 Excel 后用数据透视表解决，系统的灵活度足够支撑大部分日常经营场景了。