简介一套基于VS2012 .NET与SQL Server开发的完整进销存ERP管理系统源码并配套可对接公众号与小程序的前端框架。系统面向中小型企业、软件实施人员及.NET开发者覆盖电商管理微信订单、小程序订单、公众号订单及轮播图等参数设置、销售管理、采购管理、仓库库存等核心业务并涉及生产相关环节整体采用标准版设计功能简洁稳定已有多家企业正常使用。压缩包共7267个文件、46.71MB内容包含752个C#后端源码、787个htm页面、799个JavaScript脚本、225个aspx页同时包括大量gif/png图片、小程序wxml/wxss/json配置、数据库备份与chm帮助文档代码目录清晰便于按模块检索和二次开发。目前已有9655人学习下载这套源码能为需要自建或改造进销存系统的读者提供从数据库结构设计到前后端联调的一整套可运行工程参照。 做进销存ERP管理系统这件事看着简单真要落地一套能跑、能卖、能交付的完整系统坑比想象中多得多。我从后台管理端到小程序端完整搭过一套源码结构、业务流程、支付对接、报表服务这些环节都淌过一遍今天把这套东西的整体设计、核心逻辑和那些容易踩雷的细节掰开揉碎讲清楚。无论你是接外包项目、做毕业设计还是公司内部要上一套进销存工具这篇都能给你省下大量试错的时间。1. 进销存ERP系统的定位与模块拆解1.1 进销存到底在管什么先明确一件事进销存ERP系统解决的永远是企业最痛的那几件事——采购花了多少钱、库存还剩多少货、销售回了多少款、利润到底是多少。听起来简单但很多项目做到一半就烂尾就是因为把这三件事硬生生做成了三个孤立的模块数据没打通。这套系统的核心思路是“进、销、存、财”四位一体。采购入库带动应付款增加销售出库带动应收款增加库存变动实时联动成本核算财务模块再反哺到报表。这样一套闭环下来老板打开手机小程序就能看到今天的销售额、库存预警、应收应付情况而不是月底让财务花三天对账。从业务角度看我习惯把系统拆成六个核心域采购域采购订单、采购入库、采购退货、供应商管理销售域销售订单、销售出库、销售退货、客户管理库存域商品档案、库存台账、库存调拨、盘点、预警财务域应收应付、收款付款、收支流水报表域销售报表、采购报表、库存报表、毛利分析系统域用户权限、操作日志、基础数据1.2 这个项目适合谁、怎么用如果你拿到这套源码是为了学习那我建议你重点看两处一是库存台账的逻辑二是订单状态机的流转。这两块是进销存系统的灵魂也是面试和答辩最容易被追问的地方。如果你是拿来商用或者二次开发需要关注的是技术栈的成熟度和可扩展性。我这套用的是Spring Boot Vue3 uni-app的组合后端负责核心业务逻辑和API管理后台用Vue3做PC端小程序端用uni-app一套代码编译到微信小程序。这套组合的好处是生态成熟、招聘好找人、踩坑资料多不像某些小众框架出问题连问都没地方问。2. 核心表结构设计与业务流程梳理2.1 数据库设计的关键取舍数据库是整个系统的地基。我见过太多项目上来就建库表结果做到库存模块发现设计烂到没法继续。进销存系统的表设计核心原则是流水表管流水档案表管档案两者别混在一起。商品档案表结构CREATE TABLE product ( id bigint(20) NOT NULL AUTO_INCREMENT, product_code varchar(32) NOT NULL COMMENT 商品编码, product_name varchar(128) NOT NULL COMMENT 商品名称, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, spec varchar(255) DEFAULT NULL COMMENT 规格型号, unit varchar(10) DEFAULT 件 COMMENT 单位, purchase_price decimal(10,2) DEFAULT 0.00 COMMENT 采购价, sale_price decimal(10,2) DEFAULT 0.00 COMMENT 销售价, stock_quantity decimal(10,2) DEFAULT 0.00 COMMENT 当前库存, stock_upper decimal(10,2) DEFAULT NULL COMMENT 库存上限, stock_lower decimal(10,2) DEFAULT NULL COMMENT 库存下限, status tinyint(1) DEFAULT 1 COMMENT 状态1启用 0停用, PRIMARY KEY (id), UNIQUE KEY uk_product_code (product_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里要特别提醒“当前库存”字段严格来说是个坏味道。如果并发高或者操作频繁这个字段很容易和实际库存对不上。但纯做进销存这种体量保留这个字段的便利性远大于它的风险因为查询库存的频次远高于写入每次查询都去SUM流水表性能扛不住。正确的做法是这个字段只做展示和查询用真正的库存依据永远以库存流水表为准。定期做库存对账发现不一致用盘点单纠正。2.2 库存流水表如何设计才能不出乱子库存流水表是整个系统的账本。每一笔出入库都必须记流水不管是采购入库、销售出库、盘盈盘亏还是调拨出入。流水表设计如下CREATE TABLE stock_ledger ( id bigint(20) NOT NULL AUTO_INCREMENT, product_id bigint(20) NOT NULL COMMENT 商品ID, biz_type tinyint(4) NOT NULL COMMENT 业务类型1采购入库 2销售出库 3采购退货 4销售退货 5盘盈 6盘亏 7调拨出 8调拨入, biz_no varchar(32) NOT NULL COMMENT 业务单号, change_quantity decimal(10,2) NOT NULL COMMENT 变动数量正入负出, before_quantity decimal(10,2) NOT NULL COMMENT 变动前库存, after_quantity decimal(10,2) NOT NULL COMMENT 变动后库存, create_time datetime DEFAULT CURRENT_TIMESTAMP, create_by varchar(32) DEFAULT NULL COMMENT 操作人, PRIMARY KEY (id), KEY idx_product (product_id), KEY idx_biz_no (biz_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意change_quantity用正负号表示出入方向这样汇总库存时直接SUM就行。before_quantity和after_quantity是冗余字段但它们很有价值——在做库存追溯和错误排查时能看到每笔操作前后的变化不用靠猜。业务单据的编号规则我建议统一用前缀日期序号比如CG20250115001表示2025年1月15日的第一笔采购单。这个规则要一开始就定死后面改起来牵扯太多历史数据得不偿失。2.3 采购到销售的完整流程闭环把一条完整的业务链路串起来走一遍你就能理解这些表之间怎么配合了。第一步采购下单。采购员在后台创建采购订单填入供应商、商品明细、采购数量和单价。订单初始状态是“待审核”此时不影响任何库存。第二步审核通过后订单状态变为“已审核”这时可以执行“入库操作”。入库操作会生成一张采购入库单同时写库存流水变动数量为正更新商品表的当前库存并生成供应商的应付账款。第三步销售端流程类似。客户在小程序下单生成销售订单。如果库存足够可以直接扣减库存并生成销售出库单如果库存不足需要提示库存不足或者走预订单流程。这里我建议初期就做实时扣减校验不要做预占库存因为预占库存涉及订单超时释放的复杂逻辑一期做不好反而添乱。第四步收款确认。客户付款后管理后台确认收款应收款核销订单状态变为“已完成”。这一整套流程核心是有单据必有流水有流水必影响库存和财务。业务单据、库存流水、财务流水三者要能互相追溯这是进销存系统的基本功。3. 进销存ERP的技术实现要点3.1 技术选型与项目结构后端我用的是Spring Boot 2.7 MyBatis-Plus MySQL 8.0。权限认证用Sa-Token比Shiro轻量比Spring Security好上手不需要配置那一大堆过滤器链对进销存这种单体系统非常合适。管理后台前端用Vue3 Element Plus Vite。Vite的冷启动速度实在比Webpack舒服太多了开发体验好了一个档次。小程序端用uni-app uview-plus一套代码编译到微信小程序、H5、App都行。后端项目结构我习惯按模块分包而不是按传统三层结构堆在一起com.example.erp ├── controller // 接口层 ├── service // 业务逻辑层 │ ├── purchase // 采购模块 │ ├── sales // 销售模块 │ ├── stock // 库存模块 │ └── finance // 财务模块 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 入参出参对象 └── common // 通用工具类、常量、异常处理按业务域分包的好处是某一块业务相关的代码都在一个包里从controller到mapper一条线直接拉通改需求的时候不用在一个几十层的目录树里来回跳。这个习惯是我经历过大项目之后总结出来的多人协作时减少很多“找文件”的时间。3.2 库存扣减的并发控制方案库存扣减是进销存系统并发最高的操作特别是小程序端搞促销时几十个人同时下单同一件商品库存不能变成负数也不能超卖。我用的方案是数据库行级锁 乐观锁双重校验。先看代码Override Transactional(rollbackFor Exception.class) public boolean deductStock(Long productId, BigDecimal quantity) { // 使用行锁查询并锁定商品记录 Product product productMapper.selectByIdForUpdate(productId); if (product null) { throw new BusinessException(商品不存在); } if (product.getStockQuantity().compareTo(quantity) 0) { throw new BusinessException(库存不足); } // 更新库存带版本号校验防止并发覆盖 int rows productMapper.deductStockWithVersion(productId, quantity, product.getVersion()); if (rows 0) { throw new BusinessException(操作太频繁请重试); } // 写入库存流水 stockLedgerService.recordLedger(productId, StockBizTypeEnum.SALES_OUT.getCode(), bizNo, quantity.negate(), product.getStockQuantity(), product.getStockQuantity().subtract(quantity)); return true; }这里做了三层防护Transactional保证原子性整个库存扣减操作要么全部成功要么全部回滚selectByIdForUpdate使用了SELECT ... FOR UPDATE行级锁把商品这一行锁住防止其他事务同时修改乐观锁版本号作为兜底就算行锁在某些极端情况下没生效版本号也能拦住并发覆盖很多人问要不要用Redis预减库存方案。我的经验是真正到了需要Redis预减的并发量级每秒上千单你的一期进销存系统应该早就撑不住了。先把数据库方案做对把流水记清楚比盲目引入缓存更实际。而且引入了Redis还要处理缓存和数据库一致性复杂度直接翻倍。3.3 报表统计的查询优化心得报表模块往往是系统上线后最受抱怨的部分——数据量大了报表查询奇慢无比。进销存系统里销售报表、库存报表高频访问的SQL很容易出现多表关联和分组统计的慢查询。我处理性能问题的方法是报表查询永远分两步走。第一步日常列表页和汇总页查预聚合表或者加索引的非实时表。比如昨天的销售汇总、本周的采购趋势这些数据当天结束后就不会变了完全可以用定时任务Spring Scheduled在凌晨计算好存入汇总表。用户白天打开报表基本毫秒级响应。第二步需要实时数据的报表比如今天的实时销售额只查当日流水表并做聚合把查询范围控制在一天内再配合create_time, product_id这样的联合索引性能完全够用。另外一定要回收习惯给SQL建立联合索引时要考虑实际查询条件的前后顺序。比如库存流水表经常按商品ID和时间范围查我建的是(product_id, create_time)而不是(create_time, product_id)这样商品维度的漏斗式查询能直接命中索引。很多时候索引建得对不对对性能的影响比换机器还大。4. 小程序端的关键实现4.1 小程序端的功能定位与页面规划小程序端不是管理后台的简单阉割版它的定位应该是“给老板和业务员用的移动工作台”。管理后台能做最复杂的报表分析小程序则聚焦在最高频的三件事管库存、看销售、审批单据。我规划的小程序端页面并不复杂但每个页面都直接命中业务痛点首页工作台展示今日销售额、今日订单数、库存预警数量商品查询扫码或搜索查商品、看库存、看价格销售开单业务员现场开单提交后自动扣库存审批中心老板在手机上处理采购申请、价格审批报表速览近7天销售趋势、Top10商品排行这里一个经常翻车的坑是权限控制不能只做菜单隐藏后端接口必须也做权限拦截。有些项目前端菜单没显示就当安全了结果有人拿着接口地址直接调用数据就裸奔了。我用Sa-Token的注解权限校验后端每个接口都标注需要的权限码用户没这个权限就算知道接口地址也调不通。4.2 小程序微信支付的对接坑点小程序做交易系统就绕不开微信支付。我自己踩过最痛的坑是支付回调地址必须是HTTPS而且公网可访问回调处理必须设置防重机制。先说回调。微信支付成功后微信服务器会往你配置的回调地址发起异步通知通知你的系统“钱到账了”。如果回调地址配置不对或者回调期间系统重启了这笔支付状态就会一直不对。我的建议是回调处理接口必须保证幂等性——同一笔订单回调N次结果必须和回调1次一样。回调处理的核心逻辑Override public String handlePayNotify(PayNotifyRequest request) { // 1. 验签确认请求确实是微信官方发来的 if (!wxPayService.verifySign(request)) { return FAIL; } // 2. 查询本地订单状态如果已处理则直接返回成功防重 SalesOrder order salesOrderService.getByPayOrderNo(request.getOutTradeNo()); if (order null) { return FAIL; } if (OrderStatusEnum.PAID.getCode().equals(order.getStatus())) { return SUCCESS; // 已经处理过了直接返回成功不重复处理 } // 3. 事务内更新订单状态 写入财务流水 salesOrderService.paySuccessCallback(order.getId(), request.getTransactionId()); return SUCCESS; }再说签名。微信支付V3的验签逻辑微信会用一个平台证书私钥对通知数据做签名你需要用微信支付平台公钥去验证。这个公钥可以调用微信支付API从证书平台下载。很多新手在这里卡住是因为没有分清商户API证书和平台证书——你的API证书是发请求时用的平台证书是验证微信通知时用的两者不可混用。4.3 小程序端常见的报错与原因排查小程序开发过程中有几个高频报错我先写在这里免得大家遇到的时候抓瞎。报错一url not in domain list域名不在合法域名列表原因小程序后台配置的request合法域名和你代码里请求的域名不一致。开发时可以在开发者工具里临时勾选“不校验合法域名”但上线前必须在小程序管理后台把正式域名配置好不然真机上请求会被拦截。报错二支付功能暂时无法使用这个报错多半是因为小程序的主体资质有问题比如个人主体小程序没有微信支付权限或者小程序审核还没通过。解决办法不是写代码而是去小程序管理后台检查支付权限——如果个人主体只能考虑用第三方支付托管或者企业主体注册。这个我在实际项目里见过好几个人问代码写得好好的就是支付打不开最后查到是主体资质问题。报错三request:fail net::ERR_CONNECTION_REFUSED一般都是本地开发时后端服务没起或者后端监听的IP不是的时候微信开发者工具连不上本地服务。用Chrome开发者工具测试接口没问题但小程序请求就会失败因为小程序的网络请求走的是系统代理需要把后端服务的IP从localhost改成局域网IP并且后端启动参数里监听0.0.0.0。5. 报表服务与ERP系统的集成5.1 报表服务器连接不上的常见原因进销存ERP系统往往会集成一个独立的报表服务比如用帆软FineReport或者积木报表这类工具。很多人在集成时遇到“报表服务器连接不上”或者“报表数据库连接失败”的报错。这类报错看起来吓人其实90%的原因都集中在两三处。第一处报表服务器的数据库连接配置错了。报表服务需要直接连数据库读取数据配置文件里数据库地址、端口、账号密码必须和ERP主库匹配。这里有个常见的坑ERP系统用的是内网IP数据库地址报表服务器配置成了localhost结果连着本机——本机当然没有这个数据库自然连接失败。第二处防火墙和端口没放开。如果你把报表服务部署在独立的服务器上前端页面访问的是报表服务的HTTPS端口后端ERP也通过HTTP调用报表服务接口。中间漏配防火墙放行规则导致报表服务只能本机访问外部连不上。第三处版本兼容性。ERP系统服务用的JDK版本和报表服务要求的版本不一致最容易引发启动失败或连接池初始化异常。比如报表服务要求JDK8而系统服务已经用了JDK17跑起来各种ClassNotFoundException排查起来非常浪费时间。5.2 报表服务的集成顺序建议集成报表服务时我强烈建议按以下顺序来能少踩很多坑先单独部署报表服务确保它自身能正常启动、能预览自带的示例报表配置报表数据源用数据库客户端测试连通性再用报表服务内置的连接测试功能验证一遍在报表服务里创建第一张极简单的报表比如“查询所有商品ID”验证数据通路设计正式报表模板嵌入 ERP 系统的菜单和权限体系最后再联调用户权限和单点登录千万不要一上来就直接上复杂的销售统计报表一旦报错你根本分不清是SQL逻辑错了、数据源不对还是报表设计器的问题。先跑通链路再逐步加复杂度这是最稳妥的路子。6. 常见问题排查与实用技巧6.1 库存对不上账怎么查这是进销存系统运维里最让人的问题之一库存流水对不上。排查思路我总结了一套“三步定位法”。第一步对比台账和流水。用SQL把商品表的当前库存和库存流水表的SUM比对找出不一致的商品先从最不一致的商品下手。SELECT p.id, p.product_name, p.stock_quantity AS realtime_stock, IFNULL(SUM(sl.change_quantity), 0) AS ledger_sum, (p.stock_quantity - IFNULL(SUM(sl.change_quantity), 0)) AS diff FROM product p LEFT JOIN stock_ledger sl ON p.id sl.product_id GROUP BY p.id, p.product_name, p.stock_quantity HAVING diff 0 LIMIT 50;第二步定位问题单据。找出该商品最近所有的出入库流水按时间排序逐一核对业务单据采购入库单、销售出库单等。重点看有没有手工改库存的操作有没有删除过的流水记录如果系统允许的话就是严重漏洞。第三步使用盘点单纠正。查出差额后不建议直接改库存字段正确做法是生成一张盘点单盘盈盘亏走正规流程留下审计轨迹。这样以后出问题随时能回溯。6.2 小程序端支付回调丢失怎么办回调丢失的情况在真实业务里很常见。用户确实付了款但因为某些原因微信服务器没有成功回调我们的系统或者回调了但处理失败导致订单一直卡在待支付状态。解决方案就是提供一个“主动查询支付状态”的接口。用户体验是用户点“我已支付”按钮后台调用微信支付订单查询接口。查询接口的响应会告诉我们这笔订单的支付状态如果已支付就走一遍和回调一样的状态更新逻辑。这样一来就算回调丢失用户一查就能恢复订单状态。这个功能在系统上线初期尤其重要因为上线初期的bug率往往最高不能指望回调百分之百可靠。6.3 数据备份策略进销存系统里的数据是企业资产的数字银行不能丢。我的习惯是数据库每天凌晨2点做全量备份保留最近7天每周末做一次异地备份防止服务器磁盘坏了连备份一起丢操作日志表单独保留至少3个月以上审计用。备份脚本不复杂但一定要测试恢复流程。我见过有人每天跑备份脚本从没检查过备份文件结果半年后要恢复才发现备份文件是坏的那才是真正的灾难。备份的价值在于恢复不在于备份本身。7. 最后再说点实操体会做完这套系统我最深的感觉是进销存ERP系统真正难的从来不是写代码而是把业务逻辑理顺、把各种边界情况想清楚。代码只是把已经想清楚的业务翻译成机器能理解的语言而已。几个我觉得特别有用的经验再强调一次库存流水表一定要记before和after这是排查所有库存问题的救命稻草。报表永远分快表和实时表两层不要试图用一个SQL满足所有报表需求。后端接口权限校验不能省前端页面隐藏菜单不等于安全。支付回调一定要做防重处理线上环境回调重复是常态不是异常。至于这套系统后续怎么扩展方向很多多仓库支持、条码打印、进销存和财务软件的对账接口、数据分析看板等等。从这套基础上长出来都不难关键是地基要打牢。如果你正准备做或者正在做类似的系统希望这篇内容能帮你避掉几个大坑。有问题欢迎交流我做项目时踩过的坑讲出来能帮你省不少时间。本文还有配套的精品资源点击获取
进销存ERP系统开发实战：从表结构设计到支付对接全解析
简介一套基于VS2012 .NET与SQL Server开发的完整进销存ERP管理系统源码并配套可对接公众号与小程序的前端框架。系统面向中小型企业、软件实施人员及.NET开发者覆盖电商管理微信订单、小程序订单、公众号订单及轮播图等参数设置、销售管理、采购管理、仓库库存等核心业务并涉及生产相关环节整体采用标准版设计功能简洁稳定已有多家企业正常使用。压缩包共7267个文件、46.71MB内容包含752个C#后端源码、787个htm页面、799个JavaScript脚本、225个aspx页同时包括大量gif/png图片、小程序wxml/wxss/json配置、数据库备份与chm帮助文档代码目录清晰便于按模块检索和二次开发。目前已有9655人学习下载这套源码能为需要自建或改造进销存系统的读者提供从数据库结构设计到前后端联调的一整套可运行工程参照。 做进销存ERP管理系统这件事看着简单真要落地一套能跑、能卖、能交付的完整系统坑比想象中多得多。我从后台管理端到小程序端完整搭过一套源码结构、业务流程、支付对接、报表服务这些环节都淌过一遍今天把这套东西的整体设计、核心逻辑和那些容易踩雷的细节掰开揉碎讲清楚。无论你是接外包项目、做毕业设计还是公司内部要上一套进销存工具这篇都能给你省下大量试错的时间。1. 进销存ERP系统的定位与模块拆解1.1 进销存到底在管什么先明确一件事进销存ERP系统解决的永远是企业最痛的那几件事——采购花了多少钱、库存还剩多少货、销售回了多少款、利润到底是多少。听起来简单但很多项目做到一半就烂尾就是因为把这三件事硬生生做成了三个孤立的模块数据没打通。这套系统的核心思路是“进、销、存、财”四位一体。采购入库带动应付款增加销售出库带动应收款增加库存变动实时联动成本核算财务模块再反哺到报表。这样一套闭环下来老板打开手机小程序就能看到今天的销售额、库存预警、应收应付情况而不是月底让财务花三天对账。从业务角度看我习惯把系统拆成六个核心域采购域采购订单、采购入库、采购退货、供应商管理销售域销售订单、销售出库、销售退货、客户管理库存域商品档案、库存台账、库存调拨、盘点、预警财务域应收应付、收款付款、收支流水报表域销售报表、采购报表、库存报表、毛利分析系统域用户权限、操作日志、基础数据1.2 这个项目适合谁、怎么用如果你拿到这套源码是为了学习那我建议你重点看两处一是库存台账的逻辑二是订单状态机的流转。这两块是进销存系统的灵魂也是面试和答辩最容易被追问的地方。如果你是拿来商用或者二次开发需要关注的是技术栈的成熟度和可扩展性。我这套用的是Spring Boot Vue3 uni-app的组合后端负责核心业务逻辑和API管理后台用Vue3做PC端小程序端用uni-app一套代码编译到微信小程序。这套组合的好处是生态成熟、招聘好找人、踩坑资料多不像某些小众框架出问题连问都没地方问。2. 核心表结构设计与业务流程梳理2.1 数据库设计的关键取舍数据库是整个系统的地基。我见过太多项目上来就建库表结果做到库存模块发现设计烂到没法继续。进销存系统的表设计核心原则是流水表管流水档案表管档案两者别混在一起。商品档案表结构CREATE TABLE product ( id bigint(20) NOT NULL AUTO_INCREMENT, product_code varchar(32) NOT NULL COMMENT 商品编码, product_name varchar(128) NOT NULL COMMENT 商品名称, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, spec varchar(255) DEFAULT NULL COMMENT 规格型号, unit varchar(10) DEFAULT 件 COMMENT 单位, purchase_price decimal(10,2) DEFAULT 0.00 COMMENT 采购价, sale_price decimal(10,2) DEFAULT 0.00 COMMENT 销售价, stock_quantity decimal(10,2) DEFAULT 0.00 COMMENT 当前库存, stock_upper decimal(10,2) DEFAULT NULL COMMENT 库存上限, stock_lower decimal(10,2) DEFAULT NULL COMMENT 库存下限, status tinyint(1) DEFAULT 1 COMMENT 状态1启用 0停用, PRIMARY KEY (id), UNIQUE KEY uk_product_code (product_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里要特别提醒“当前库存”字段严格来说是个坏味道。如果并发高或者操作频繁这个字段很容易和实际库存对不上。但纯做进销存这种体量保留这个字段的便利性远大于它的风险因为查询库存的频次远高于写入每次查询都去SUM流水表性能扛不住。正确的做法是这个字段只做展示和查询用真正的库存依据永远以库存流水表为准。定期做库存对账发现不一致用盘点单纠正。2.2 库存流水表如何设计才能不出乱子库存流水表是整个系统的账本。每一笔出入库都必须记流水不管是采购入库、销售出库、盘盈盘亏还是调拨出入。流水表设计如下CREATE TABLE stock_ledger ( id bigint(20) NOT NULL AUTO_INCREMENT, product_id bigint(20) NOT NULL COMMENT 商品ID, biz_type tinyint(4) NOT NULL COMMENT 业务类型1采购入库 2销售出库 3采购退货 4销售退货 5盘盈 6盘亏 7调拨出 8调拨入, biz_no varchar(32) NOT NULL COMMENT 业务单号, change_quantity decimal(10,2) NOT NULL COMMENT 变动数量正入负出, before_quantity decimal(10,2) NOT NULL COMMENT 变动前库存, after_quantity decimal(10,2) NOT NULL COMMENT 变动后库存, create_time datetime DEFAULT CURRENT_TIMESTAMP, create_by varchar(32) DEFAULT NULL COMMENT 操作人, PRIMARY KEY (id), KEY idx_product (product_id), KEY idx_biz_no (biz_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意change_quantity用正负号表示出入方向这样汇总库存时直接SUM就行。before_quantity和after_quantity是冗余字段但它们很有价值——在做库存追溯和错误排查时能看到每笔操作前后的变化不用靠猜。业务单据的编号规则我建议统一用前缀日期序号比如CG20250115001表示2025年1月15日的第一笔采购单。这个规则要一开始就定死后面改起来牵扯太多历史数据得不偿失。2.3 采购到销售的完整流程闭环把一条完整的业务链路串起来走一遍你就能理解这些表之间怎么配合了。第一步采购下单。采购员在后台创建采购订单填入供应商、商品明细、采购数量和单价。订单初始状态是“待审核”此时不影响任何库存。第二步审核通过后订单状态变为“已审核”这时可以执行“入库操作”。入库操作会生成一张采购入库单同时写库存流水变动数量为正更新商品表的当前库存并生成供应商的应付账款。第三步销售端流程类似。客户在小程序下单生成销售订单。如果库存足够可以直接扣减库存并生成销售出库单如果库存不足需要提示库存不足或者走预订单流程。这里我建议初期就做实时扣减校验不要做预占库存因为预占库存涉及订单超时释放的复杂逻辑一期做不好反而添乱。第四步收款确认。客户付款后管理后台确认收款应收款核销订单状态变为“已完成”。这一整套流程核心是有单据必有流水有流水必影响库存和财务。业务单据、库存流水、财务流水三者要能互相追溯这是进销存系统的基本功。3. 进销存ERP的技术实现要点3.1 技术选型与项目结构后端我用的是Spring Boot 2.7 MyBatis-Plus MySQL 8.0。权限认证用Sa-Token比Shiro轻量比Spring Security好上手不需要配置那一大堆过滤器链对进销存这种单体系统非常合适。管理后台前端用Vue3 Element Plus Vite。Vite的冷启动速度实在比Webpack舒服太多了开发体验好了一个档次。小程序端用uni-app uview-plus一套代码编译到微信小程序、H5、App都行。后端项目结构我习惯按模块分包而不是按传统三层结构堆在一起com.example.erp ├── controller // 接口层 ├── service // 业务逻辑层 │ ├── purchase // 采购模块 │ ├── sales // 销售模块 │ ├── stock // 库存模块 │ └── finance // 财务模块 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 入参出参对象 └── common // 通用工具类、常量、异常处理按业务域分包的好处是某一块业务相关的代码都在一个包里从controller到mapper一条线直接拉通改需求的时候不用在一个几十层的目录树里来回跳。这个习惯是我经历过大项目之后总结出来的多人协作时减少很多“找文件”的时间。3.2 库存扣减的并发控制方案库存扣减是进销存系统并发最高的操作特别是小程序端搞促销时几十个人同时下单同一件商品库存不能变成负数也不能超卖。我用的方案是数据库行级锁 乐观锁双重校验。先看代码Override Transactional(rollbackFor Exception.class) public boolean deductStock(Long productId, BigDecimal quantity) { // 使用行锁查询并锁定商品记录 Product product productMapper.selectByIdForUpdate(productId); if (product null) { throw new BusinessException(商品不存在); } if (product.getStockQuantity().compareTo(quantity) 0) { throw new BusinessException(库存不足); } // 更新库存带版本号校验防止并发覆盖 int rows productMapper.deductStockWithVersion(productId, quantity, product.getVersion()); if (rows 0) { throw new BusinessException(操作太频繁请重试); } // 写入库存流水 stockLedgerService.recordLedger(productId, StockBizTypeEnum.SALES_OUT.getCode(), bizNo, quantity.negate(), product.getStockQuantity(), product.getStockQuantity().subtract(quantity)); return true; }这里做了三层防护Transactional保证原子性整个库存扣减操作要么全部成功要么全部回滚selectByIdForUpdate使用了SELECT ... FOR UPDATE行级锁把商品这一行锁住防止其他事务同时修改乐观锁版本号作为兜底就算行锁在某些极端情况下没生效版本号也能拦住并发覆盖很多人问要不要用Redis预减库存方案。我的经验是真正到了需要Redis预减的并发量级每秒上千单你的一期进销存系统应该早就撑不住了。先把数据库方案做对把流水记清楚比盲目引入缓存更实际。而且引入了Redis还要处理缓存和数据库一致性复杂度直接翻倍。3.3 报表统计的查询优化心得报表模块往往是系统上线后最受抱怨的部分——数据量大了报表查询奇慢无比。进销存系统里销售报表、库存报表高频访问的SQL很容易出现多表关联和分组统计的慢查询。我处理性能问题的方法是报表查询永远分两步走。第一步日常列表页和汇总页查预聚合表或者加索引的非实时表。比如昨天的销售汇总、本周的采购趋势这些数据当天结束后就不会变了完全可以用定时任务Spring Scheduled在凌晨计算好存入汇总表。用户白天打开报表基本毫秒级响应。第二步需要实时数据的报表比如今天的实时销售额只查当日流水表并做聚合把查询范围控制在一天内再配合create_time, product_id这样的联合索引性能完全够用。另外一定要回收习惯给SQL建立联合索引时要考虑实际查询条件的前后顺序。比如库存流水表经常按商品ID和时间范围查我建的是(product_id, create_time)而不是(create_time, product_id)这样商品维度的漏斗式查询能直接命中索引。很多时候索引建得对不对对性能的影响比换机器还大。4. 小程序端的关键实现4.1 小程序端的功能定位与页面规划小程序端不是管理后台的简单阉割版它的定位应该是“给老板和业务员用的移动工作台”。管理后台能做最复杂的报表分析小程序则聚焦在最高频的三件事管库存、看销售、审批单据。我规划的小程序端页面并不复杂但每个页面都直接命中业务痛点首页工作台展示今日销售额、今日订单数、库存预警数量商品查询扫码或搜索查商品、看库存、看价格销售开单业务员现场开单提交后自动扣库存审批中心老板在手机上处理采购申请、价格审批报表速览近7天销售趋势、Top10商品排行这里一个经常翻车的坑是权限控制不能只做菜单隐藏后端接口必须也做权限拦截。有些项目前端菜单没显示就当安全了结果有人拿着接口地址直接调用数据就裸奔了。我用Sa-Token的注解权限校验后端每个接口都标注需要的权限码用户没这个权限就算知道接口地址也调不通。4.2 小程序微信支付的对接坑点小程序做交易系统就绕不开微信支付。我自己踩过最痛的坑是支付回调地址必须是HTTPS而且公网可访问回调处理必须设置防重机制。先说回调。微信支付成功后微信服务器会往你配置的回调地址发起异步通知通知你的系统“钱到账了”。如果回调地址配置不对或者回调期间系统重启了这笔支付状态就会一直不对。我的建议是回调处理接口必须保证幂等性——同一笔订单回调N次结果必须和回调1次一样。回调处理的核心逻辑Override public String handlePayNotify(PayNotifyRequest request) { // 1. 验签确认请求确实是微信官方发来的 if (!wxPayService.verifySign(request)) { return FAIL; } // 2. 查询本地订单状态如果已处理则直接返回成功防重 SalesOrder order salesOrderService.getByPayOrderNo(request.getOutTradeNo()); if (order null) { return FAIL; } if (OrderStatusEnum.PAID.getCode().equals(order.getStatus())) { return SUCCESS; // 已经处理过了直接返回成功不重复处理 } // 3. 事务内更新订单状态 写入财务流水 salesOrderService.paySuccessCallback(order.getId(), request.getTransactionId()); return SUCCESS; }再说签名。微信支付V3的验签逻辑微信会用一个平台证书私钥对通知数据做签名你需要用微信支付平台公钥去验证。这个公钥可以调用微信支付API从证书平台下载。很多新手在这里卡住是因为没有分清商户API证书和平台证书——你的API证书是发请求时用的平台证书是验证微信通知时用的两者不可混用。4.3 小程序端常见的报错与原因排查小程序开发过程中有几个高频报错我先写在这里免得大家遇到的时候抓瞎。报错一url not in domain list域名不在合法域名列表原因小程序后台配置的request合法域名和你代码里请求的域名不一致。开发时可以在开发者工具里临时勾选“不校验合法域名”但上线前必须在小程序管理后台把正式域名配置好不然真机上请求会被拦截。报错二支付功能暂时无法使用这个报错多半是因为小程序的主体资质有问题比如个人主体小程序没有微信支付权限或者小程序审核还没通过。解决办法不是写代码而是去小程序管理后台检查支付权限——如果个人主体只能考虑用第三方支付托管或者企业主体注册。这个我在实际项目里见过好几个人问代码写得好好的就是支付打不开最后查到是主体资质问题。报错三request:fail net::ERR_CONNECTION_REFUSED一般都是本地开发时后端服务没起或者后端监听的IP不是的时候微信开发者工具连不上本地服务。用Chrome开发者工具测试接口没问题但小程序请求就会失败因为小程序的网络请求走的是系统代理需要把后端服务的IP从localhost改成局域网IP并且后端启动参数里监听0.0.0.0。5. 报表服务与ERP系统的集成5.1 报表服务器连接不上的常见原因进销存ERP系统往往会集成一个独立的报表服务比如用帆软FineReport或者积木报表这类工具。很多人在集成时遇到“报表服务器连接不上”或者“报表数据库连接失败”的报错。这类报错看起来吓人其实90%的原因都集中在两三处。第一处报表服务器的数据库连接配置错了。报表服务需要直接连数据库读取数据配置文件里数据库地址、端口、账号密码必须和ERP主库匹配。这里有个常见的坑ERP系统用的是内网IP数据库地址报表服务器配置成了localhost结果连着本机——本机当然没有这个数据库自然连接失败。第二处防火墙和端口没放开。如果你把报表服务部署在独立的服务器上前端页面访问的是报表服务的HTTPS端口后端ERP也通过HTTP调用报表服务接口。中间漏配防火墙放行规则导致报表服务只能本机访问外部连不上。第三处版本兼容性。ERP系统服务用的JDK版本和报表服务要求的版本不一致最容易引发启动失败或连接池初始化异常。比如报表服务要求JDK8而系统服务已经用了JDK17跑起来各种ClassNotFoundException排查起来非常浪费时间。5.2 报表服务的集成顺序建议集成报表服务时我强烈建议按以下顺序来能少踩很多坑先单独部署报表服务确保它自身能正常启动、能预览自带的示例报表配置报表数据源用数据库客户端测试连通性再用报表服务内置的连接测试功能验证一遍在报表服务里创建第一张极简单的报表比如“查询所有商品ID”验证数据通路设计正式报表模板嵌入 ERP 系统的菜单和权限体系最后再联调用户权限和单点登录千万不要一上来就直接上复杂的销售统计报表一旦报错你根本分不清是SQL逻辑错了、数据源不对还是报表设计器的问题。先跑通链路再逐步加复杂度这是最稳妥的路子。6. 常见问题排查与实用技巧6.1 库存对不上账怎么查这是进销存系统运维里最让人的问题之一库存流水对不上。排查思路我总结了一套“三步定位法”。第一步对比台账和流水。用SQL把商品表的当前库存和库存流水表的SUM比对找出不一致的商品先从最不一致的商品下手。SELECT p.id, p.product_name, p.stock_quantity AS realtime_stock, IFNULL(SUM(sl.change_quantity), 0) AS ledger_sum, (p.stock_quantity - IFNULL(SUM(sl.change_quantity), 0)) AS diff FROM product p LEFT JOIN stock_ledger sl ON p.id sl.product_id GROUP BY p.id, p.product_name, p.stock_quantity HAVING diff 0 LIMIT 50;第二步定位问题单据。找出该商品最近所有的出入库流水按时间排序逐一核对业务单据采购入库单、销售出库单等。重点看有没有手工改库存的操作有没有删除过的流水记录如果系统允许的话就是严重漏洞。第三步使用盘点单纠正。查出差额后不建议直接改库存字段正确做法是生成一张盘点单盘盈盘亏走正规流程留下审计轨迹。这样以后出问题随时能回溯。6.2 小程序端支付回调丢失怎么办回调丢失的情况在真实业务里很常见。用户确实付了款但因为某些原因微信服务器没有成功回调我们的系统或者回调了但处理失败导致订单一直卡在待支付状态。解决方案就是提供一个“主动查询支付状态”的接口。用户体验是用户点“我已支付”按钮后台调用微信支付订单查询接口。查询接口的响应会告诉我们这笔订单的支付状态如果已支付就走一遍和回调一样的状态更新逻辑。这样一来就算回调丢失用户一查就能恢复订单状态。这个功能在系统上线初期尤其重要因为上线初期的bug率往往最高不能指望回调百分之百可靠。6.3 数据备份策略进销存系统里的数据是企业资产的数字银行不能丢。我的习惯是数据库每天凌晨2点做全量备份保留最近7天每周末做一次异地备份防止服务器磁盘坏了连备份一起丢操作日志表单独保留至少3个月以上审计用。备份脚本不复杂但一定要测试恢复流程。我见过有人每天跑备份脚本从没检查过备份文件结果半年后要恢复才发现备份文件是坏的那才是真正的灾难。备份的价值在于恢复不在于备份本身。7. 最后再说点实操体会做完这套系统我最深的感觉是进销存ERP系统真正难的从来不是写代码而是把业务逻辑理顺、把各种边界情况想清楚。代码只是把已经想清楚的业务翻译成机器能理解的语言而已。几个我觉得特别有用的经验再强调一次库存流水表一定要记before和after这是排查所有库存问题的救命稻草。报表永远分快表和实时表两层不要试图用一个SQL满足所有报表需求。后端接口权限校验不能省前端页面隐藏菜单不等于安全。支付回调一定要做防重处理线上环境回调重复是常态不是异常。至于这套系统后续怎么扩展方向很多多仓库支持、条码打印、进销存和财务软件的对账接口、数据分析看板等等。从这套基础上长出来都不难关键是地基要打牢。如果你正准备做或者正在做类似的系统希望这篇内容能帮你避掉几个大坑。有问题欢迎交流我做项目时踩过的坑讲出来能帮你省不少时间。本文还有配套的精品资源点击获取
