干了这么多年开发最常被小企业主问的一句话是“能不能帮我那把Excel里的库存理清楚”这其实不是表格美化问题而是整个进销存流程数字化的问题。最近刚上线了一套vuepython的B/S架构进销存管理系统项目编号是i59u2562服务对象是一家做商贸批发的中小公司SKU上千个采购、销售、库存、往来账、数据分析可视化大屏全部走这一套系统。从需求调研到开发再到真正跑起来前后小半年今天把完整过程写一遍尤其是可视化大屏部分到底怎么落地踩过哪些坑希望对做同类系统的朋友有点参考价值。针对的目标读者很明确准备自建管理系统、又不想一上来就上重型ERP的中小企业IT负责人以及想接这类外包项目的独立开发者。后端是Python生态前端是Vue数据库MySQL另外用Redis做缓存。这里不聊“架子搭得多花哨”只聊业务怎么建模、单据怎么流转、数据怎么在大屏上真正有用。1. 先聊为什么小企业进销存不缺“记账功能”缺的是数据闭环1.1 真实的库存痛点货号过千之后Excel根本扛不住公司是做商贸批发的仓库常年滚动着上千个货号采购价随批次波动同一个商品今天进货价和下周可能差了5毛。销售端更复杂有按整箱批发的老客户有按件零售的散客还有几类客户的账期完全不一样有的15天回款有的拖到45天。用Excel管这些初期还行SKU到500以内的确能勉强应付。但到上千个货号时问题集中爆发采购单和入库单对不上仓库实际发的货和销售单不一致财务月底对账要拿着几份表来回比对等把差异找出来新的差异又产生了。最头疼的是“建账容易平账难”。Excel里库存余额公式互相引用中间有人改了单元格没通知别人月底谁都不敢保证那个数字是真是假。这个问题不是靠“Excel用得更细致”能解决的本质是流程没被系统约束住。所以和客户聊下来的结论很明确他们要的不是一个“电子记账本”而是一套能把采购、销售、库存、资金串起来的系统每天能自动把账算平再把结果用大屏展示出来。1.2 成品SaaS没解决的事才是自研的空间有人可能会问市面上现成的进销存SaaS一大堆为什么还要自己搞一套这个决定其实也是经过反复权衡的。第一个问题出在定制能力上。进销存这种系统看起来大家都一样真用起来全是细节商品单位要从“箱”拆成“件”客户要有等级价批发订单允许负库存出库但零售不行退货单要根据原单自动带出价格应收款要做账龄提醒。成品软件大部分功能固定能配置的部分给了参数还是绕不过去只能去适应软件而不是软件适应业务。第二个问题是费用结构。按账号、按模块、按年续费小公司几十个账号算下来几年费用并不低而且数据始终在别人的平台上导来导去也麻烦。第三个问题才是关键客户要数据分析大屏。别管是老板想看的“今日销售额”“商品TOP10”还是库管关心的“低库存预警”成品大屏模板通常是固定的最多换换颜色。真要让大屏跟自己的业务口径完全对齐比如销售额含不含税、退货要不要冲减、账期超期客户有哪些改起来相当费劲。自研也有成本但一套针对单一公司的定制系统数据模型、字段、流程都是围着业务建的后期维护成本其实是可控的。所以最终定了方案Vue做前端Python做后端B/S架构部署在一台云服务器上公司内所有电脑浏览器打开就能用。1.3 B/S架构的价值不用装客户端门店和仓库共用一套系统这里多说一句为什么坚持B/S而不是传统的CS桌面端。这家公司除了总店还有两个分仓和几个经常要开单的业务员。B/S模式下服务器只需要一台员工电脑上装个浏览器就能访问业务员在外面用笔记本电脑也能开销售单不需要到门店装客户端也省掉了桌面运维的工作量。权限体系集中在后端控制开单、审核、看数据分别对应不同角色这些在浏览器架构下做起来很顺畅。2. 技术栈选型的底层逻辑Vue Python这个组合合不合理2.1 后端选PythonWeb框架、数据校验和Excel生态都很顺手确定了Python做后端我第一反应是选FastAPI。这家公司的系统逻辑集中在单据流转和库存计算上数据交互密集FastAPI在这类业务上有几个明显优势。一个是Pydantic做参数校验非常舒服。前端传过来的销售明细、采购明细都有嵌套结构Pydantic的模型校验能在入口就把格式错、字段缺、类型不对的问题拦下来而不是等到业务逻辑里各种if判断。另一个是自动生成OpenAPI文档联调的时候前端同事直接看 /docs 页面就知道接口长什么样省了一堆沟通成本。ORM用的SQLAlchemy配合Alembic做数据库迁移。进销存系统的表结构在开发初期变化很频繁今天发现往来账需要一个收款单号明天发现库存流水要加一个关联单据类型Alembic的迁移脚本让这些改动都可以追溯。定时任务用APScheduler每天凌晨计算前一天的各商品销售汇总、库存快照供大屏读取。Python生态里还有一个杀手锏是openpyxl。客户大量历史数据在Excel里迁移时要用脚本解析并导入后面又要经常导出月报表、对账单这套库处理起来比在Java里写POI舒服多了。2.2 前端选Vue一个人也能维护得动的组件生态前端这边我用了Vue 3 Element Plus ECharts状态管理用Pinia路由用Vue Router。选Vue而不是React核心原因是团队规模和生态成熟度。这类内部管理系统的UI复杂度不算高大量页面是表格加表单加弹窗Element Plus这些组件基本覆盖了80%的场景一个人也能维护得动。Vue 3的Composition API在组织“复杂业务页面”时确实好用。比如销售出库单页面既要管客户选择、商品明细、价格计算又要联动库存余额、应收款余额把这些逻辑按功能拆成一个个组合式函数比之前写Options API时一坨mixin清晰很多。Pinia用来保存当前登录用户、可访问仓库列表、商品价格策略这些全局状态组件之间不用再一层层丢props。可视化大屏不用多说ECharts是首选文档全、图表丰富折线图、柱状图、饼图、数字翻牌都很成熟。唯一要注意的是大屏页面的组件生命周期后面专门讲。2.3 接口约定前后端分离项目里的“隐形宪法”技术栈定下来之后真正决定项目后期痛不痛苦的是接口约定。这个项目里统一了返回体、密码加密、分页结构、错误码前端所有请求方法都先封装好后面加权限、加多仓库过滤时只改一层就够了。统一返回体的结构很简单{ code: 0, msg: success, data: { list: [], total: 123 } }code为0表示成功非0是业务错误码比如1001表示库存不足1002表示单据已审核不能修改。前端拿到非0的code时统一弹错误提示不需要每个页面单独写错误处理。鉴权用的JWT登录后前端把Token存在内存里请求拦截器自动带上刷新页面时再根据用户角色重新拉取菜单和权限。这里要特别说明接口规范在项目不复杂时看不出价值一旦销售单、采购单、库存流水、往来账这些模块同时开发没有统一约定就会出现“这个接口返回数组那个接口返回对象”的情况后期联调全是低级问题。3. 核心业务模块拆解从商品档案到库存流水3.1 商品档案与多单位换算最容易做错的第一个坑进销存系统的地基是商品档案。表面上看就是编号、名称、条码、价格实际上真正的坑在单位换算。这家公司经营的商品有几个典型特征有的按箱进货、按件零售一箱12件有的按公斤进货、按袋销售还有的会根据促销活动临时组合成套装。所以在设计商品表时特意拆出了基础单位、采购单位、销售单位之间的换算关系还有单独的条码表。同一件商品可以挂多个条码一个整箱条码、一个单件条码仓库扫码出库时扫哪个都能识别。价格体系分了三级参考进价、标准售价、客户等级价。批发客户有固定的等级开单时系统自动带出对应价格业务员只要确认就好。有个小经验多单位换算字段一定要用浮动小数而不是整数并且要保留四舍五入精度。因为存在“3公斤起卖、每0.1公斤计价”的商品用整数换算会算少了。商品档案字段示例SKU编码、名称、规格基础单位、采购单位、销售单位、换算率默认仓库、默认货位参考进价、标准售价、最低售价条码列表安全库存阈值、是否允许负库存3.2 采购、销售、退货的单据流设计单据和库存互相解耦进销存的单据设计是整个系统的核心。最开始设计时犯过不少错最大的教训是单据状态和库存变动必须解耦不能在一个方法里“既改单子状态又直接改库存数量”否则单据作废、回退、改单时库存很难回滚。最终采用了“单据驱动流水”的模式任何业务动作都会经历创建单据、提交审核、审核通过后生成库存流水、同时更新库存余额。整个过程都在一个数据库事务里完成。采购入库单的状态流转如下状态含义后续操作草稿采购员录入还没有提交可以修改、删除待审核已提交但未处理可以撤回已审核审核通过库存已入账只读可生成采购退货单已关闭手动中止或全部退货完成只读销售出库单的逻辑类似但多了一个“确认出库”动作。批发业务经常是上午开单、下午发货中间时间差很长如果开单就直接扣库存会出现单子积压但仓库已经断货的情况。所以这里做成销售单生成时占用库存但不实际扣减实际扣减发生在仓库确认出库时。库存流水的字段这里给一个参考流水号、关联单据类型、关联单据号商品SKU、仓库、变动数量变动前库存、变动后库存业务时间、操作人备注、来源类型这个表只增不改是账实一致的核心凭据。库存余额表只是流水表的聚合结果任何一次盘点、出库、入库都通过新增流水来改变余额不允许直接改余额表。3.3 库存盘点、预警与批次管理哪些必须做哪些可以缓一缓库存预警是必须做的。客户仓库里上千个货号靠人记安全库存不现实。系统里给每个商品配了安全库存阈值运行一个定时任务每天早上扫描一次低于阈值的自动生成预警列表并在大屏上展示缺货数。采购员根据预警单补货比月底盘点时才发现断货强多了。盘点功能则是上线后第二个星期才临时加的。原因很现实手工管理时代遗留下来的账实差异比预期大需要一套完整的盘点流程来纠偏。设计上做了盘点单库管选择仓库和商品范围填实盘数量系统自动和账面库存做差异计算生成“盘盈/盘亏调整单”调整单审核通过后同样走库存流水把这个差异记进账里。批次管理这里没有做因为客户的商品保质期较长而且目前没有过期召回需求。如果做食品、化妆品、医药类业务批次和保质期就必须在商品表、库存流水里全部带上否则后面没法追溯。这个取舍建议大家在接项目时提前判断清楚。3.4 往来账模块批发业务的应收应付比库存还重要做商贸批发往来账比库存还敏感。客户月结是常态只记销售额不追踪回款月底财务一定崩溃。这个项目里单独做了应收款模块。销售单审核通过后自动生成应收单按客户账期分为“现结”和“挂账”。财务收到回款后录收款单系统自动勾对对应客户的未结销售单。应收款最核心的功能是账龄分析。按未回款天数分档0到30天、31到60天、61到90天、91天以上。大屏上有一块专门展示超期应收的客户很多老板盯着看比看销售额还认真。因为这东西直接关系到现金流。3.5 一个容易被忽略的模块基础数据权限这家公司有总店、两个分仓还有三个业务员。同样的商品在不同仓库的库存是分开的同样的销售数据业务员只能看自己名下客户的店长能看整个门店老板能看全部。这是通过“用户—角色—数据范围”做的角色定义“资质”数据范围定义“看到哪个仓库、哪个业务员的单”。所有列表查询接口后端都统一注入当前用户的数据权限过滤条件前端根本不用关心。4. 数据分析可视化大屏指标定义比画图更花时间4.1 先和老板对齐口径再动ECharts项目推进到第二个月大屏这个需求才浮出水面。客户第一次说“搞个大屏吧”时我很警觉地说先不急着画图得聊聊你到底想看什么。因为以前见过太多电子屏上堆了十几张图表没有任何老板真正每天看。我们花了两个下午把业务方关心的指标逐条列出来逐条定义口径。这里最关键的一步销售额必须和财务口径对齐。比如“今日销售额”客户内部到底是指“当天出库单的应收金额”还是“当天实际收到的回款”如果这里不对齐屏幕上数字和财务日报对不上系统上线第一天就会被否定。最终确认的核心指标如下指标口径定义刷新频率今日销售额当日已出库销售单的应收合计不含作废单5秒今日销售单数当日已出库销售单数量5秒近7日销售趋势按自然日聚合销售金额的折线30秒商品销售TOP10按销售金额排序含销量和毛利30秒品类销售占比按一级分类聚合的销售金额饼图30秒库存总额当前所有仓库库存成本总和1分钟低库存预警低于安全库存的商品数量1分钟应收超期超过30天未回款客户数及金额1分钟今日采购入库当日已审核采购单的入库金额5秒每个指标都写明公式和取数来源。比如“商品销售TOP10”里销售数量是已出库单的明细数量合并退货单要冲减毛利里的成本用商品的平均进价而不是最后一次进价。口径确定后大屏才有讨论价值。4.2 后端聚合设计大屏刷新5秒一次数据库不能死撑大屏指标众多如果每个指标都实时查明细表做聚合数据库扛不住。这里采用了三层架构。第一层是Redis缓存。每个指标设计一个自动失效机制比如“今日销售额”在销售单审核通过时主动删除对应的Redis Key下次大屏请求时重新计算。如果一直没人访问这个Key就一直在缓存里避免无意义计算。第二层是每日统计表。每天凌晨用APScheduler跑定时任务把前一天的销售汇总、库存快照、应收汇总写进一张统计表。这样“近7日销售趋势”只需要查七条记录而不是去扫描百万行销售明细。第三层才是实时查询。真正需要实时的只有“今日销售额”“今日销售单数”这种当天数据因为当天明细量不大直接查也快。坏味道是连个预警数量都要去求和整个库存流水表这种查询必须进统计表。给一个示例商品销售TOP10的实时聚合SQL按已出库销售单明细分组SELECT sku_id, SUM(quantity) AS total_qty, SUM(amount) AS total_amount FROM sale_order_item WHERE order_status IN (confirmed, delivered) AND warehouse_id :当前用户可见仓库 GROUP BY sku_id ORDER BY total_amount DESC LIMIT 10;注意这个SQL在产品上线初期没问题但销售明细一旦膨胀还是要改成定时统计表方案。宁可让大屏和实时系统晚几分钟也不能让聚合查询拖垮核心开单。4.3 大屏前端实现要点布局、动画和自动刷新都要控制节奏大屏前端用的是Vue 3 ECharts独立路由全屏展示。整体布局直接用CSS Grid按比例划分区域顶部是主标题和三个核心数字翻牌左侧放销售趋势和品类占比中间放地图客户分布后来发现客户就那么几个城市就换成了分仓库销售对比、右侧放商品TOP10和应收超期底部放低库存预警和今日采购入库。设计稿按1920×1080的参考分辨率来做用rem配合缩放适配保证投到不同尺寸的电视上不变形。自动刷新这块有一个很重要的细节每个图表的刷新频率不完全一样。翻牌数字5秒一次图表类30秒到1分钟一次。一开始全部设成5秒结果发现ECharts更新动画互相打架CPU占用也高。后来把刷新逻辑统一收敛到一个定时器管理器里每个组件注册自己的刷新间隔组件卸载时自动注销定时期避免路由跳转后ECharts实例还在后台跑。大屏实际运行时还有网络波动问题。给每个请求加了失败重试和指数退避连续失败3次就不自动刷了只保留手动刷新按钮避免一直弹错误提示。ECharts组件化封装有个简单经验每个图表用同一个折线图、柱状图、饼图组件data属性接收配置好的option对象用watch监听数据变化后调用chart.setOption(newOption)不用每次都销毁重建。4.4 大屏的“口径一致性”细节容易被忽略再补充一个细节大屏右上角的“今日”如果设置为自然日0点到24点那凌晨开单出货就会被算到前一天老板早上来看数字会发脾气。这家公司营业时间是早8点到晚10点所以系统里专门配置了一个营业日规则“今日”从当天0点开始算但每天早上自动推送昨天的完整汇总。大屏上只显示“今日数据”和“昨日数据”两个数字口径统一谁来看都不会误解。5. 实测中踩过的坑并发、死锁、导出卡死和扫码枪的回车5.1 并发出库把库存扣成负数上线第二周仓库高峰期同时出库问题来了最后一件商品两个销售单同时提交出库结果两个单子都成功了库存变成了-1。这是典型的并发写问题。当时库存更新用的是“先查余额再计算新余额最后UPDATE”的写法在高并发下等于没有保护。解决方式用了乐观锁。库存表加了一个version字段更新语句改为UPDATE stock_balance SET quantity quantity - 1, version version 1 WHERE sku_id 商品ID AND warehouse_id 仓库ID AND version 读取到的version AND quantity 1;执行返回的影响行数是0说明版本冲突或库存不够这时回滚当前事务给前端返回“库存不足或已被占用”的提示。这里的取舍是为什么没用SELECT FOR UPDATE悲观锁因为出库操作非常频繁锁行时间虽然短但在高峰时段容易排队而且一旦事务里还有其他查询锁的持有时间不可控。乐观锁对“冲突概率低、峰值高”的场景更合适。5.2 事务顺序不一致导致死锁项目开发中遇到一次MySQL死锁报错信息指向库存流水表。排查后发现一个事务按“先更新销售单头、再更新库存流水”的顺序另一个事务按“先更新商品主表、再更新库存流水”的顺序。两个事务都申请了对方的行锁互相等对方释放数据库选择了回滚一个事务。这类问题最好的解法不是靠MySQL自动检测死锁而是让所有事务遵循统一的加锁顺序。我在库存写入口做了一个强制约定任何库存变动方法必须先锁定对应的库存余额行再操作流水。顺序统一后死锁就再也没出现过。5.3 十万行流水导出把进程打满上线一个月财务要求导出全部流水到Excel十万行数据。最初直接在接口里同步生成Excel前端等了几十秒超时后端CPU飙高其他请求全被阻塞。后来改成异步导出方案导出请求先写一条任务记录后台任务用openpyxl生成文件到服务器临时目录完成后更新任务状态。前端轮询任务状态发现完成后再触发下载。这个过程不占用请求线程用户体验也好。另外给所有导出任务加了行数上限和分页条件默认只导出最近三个月要更早的数据就走条件筛选。5.4 扫码枪的“回车尾缀”导致搜索框重复提交仓库扫码出库时用的是USB扫码枪。扫码枪默认行为是扫完条码后自动补一个回车正好触发前端输入框的回车事件导致页面在未处理完当前条码时又提交了一次。实际效果就是同一个条码扫一次屏幕上出现了两行。解决方法是输入框只做录入不监听回车统一在“扫描完成”按钮上触发事件。同时给输入加了一个300毫秒的防抖防止连续扫码时出现抖动。5.5 大屏高刷新间隔下的数据库连接数被打满大屏初期把刷新间隔全设在5秒多个指标同时刷新统计接口又走实时聚合数据库连接一度被打满。后来强制规定卡片类数据走Redis图表类数据走统计表实时查询只保留当天数据。连接池也调小了最大连接数控制在数据库能承受的范围宁可排队也不拖垮整个业务系统。6. 部署与上线系统真正跑起来还有三分靠流程6.1 单机最小部署方案这个系统的规模完全没到微服务那一步部署方案越简单越好。一台4核8G的云服务器装好MySQL 8、Redis、Nginx、Python环境前端构建后直接放在Nginx的静态目录后端用Gunicorn启动FastAPISupervisor守护进程。Nginx配置大概长这样server { listen 80; server_name _; root /var/www/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }前端路由是history模式所以需要try_files把未知路径指向index.html否则刷新页面会404。这点第一次部署时踩过写出来提醒一下。数据备份放在每天凌晨3点用crontab执行mysqldump备份文件保留30天。同时监控磁盘占用和慢查询日志每周看一次避免业务增长后磁盘写满或者某个SQL越来越慢。6.2 上线不是终点业务流程约束比代码更重要系统上线第一天一切正常。第三天就出问题了有几个销售单在系统里找不到对应的出库记录。查完发现是流程没走通有个业务员习惯先发货后回办公室补单结果货发出了单子忘了补库存却已经实发。这里只能说一个经验进销存系统能不能跑起来一半靠代码一半靠流程。代码层面能做的是把打印的单据、库存流水、审批日志都留好痕迹流程层面必须和客户约定清楚“先开单后出库不允许先出库后补单”否则库存永远是虚的。我们甚至还做了“不允许负库存出库”的开关但批发客户强烈要求保留负库存能力只是每次负库存出库都会在系统里打上标记每周盘点时重点检查这些异常单。6.3 上线后的几个具体效果系统完整跑了三个月之后几个数字很直观月底对账从两天缩短到半天财务不再需要人工比对Excel库存预警让客户第一次做到了“断货前补货”而不是断货后才知道应收账龄表成了老板每周一必看的东西超期客户催款有了明确依据大屏每天开着商家自己说“现在开会不用再用PPT翻Excel了”不过要说最值钱的地方其实不是大屏的科技感而是每天营业结束时系统能自动算清“今天卖了多少钱、哪些货要补、哪些客户该催款”。一夜之间把原来的手工流程数字化这才是这个项目真正解决的核心问题。7. 一些补充建议给正打算做同类系统的朋友最后聊几句自己的真实体会。第一进销存项目技术难度不高难点全在业务细节上尤其是单位换算、单据状态机、库存流水、往来账这四个部分。技术栈怎么样都行但这几块的数据模型如果没设计好后面会一直被返工困扰。第二大屏不要一开始就做。先把核心业务跑通把数据积累起来再做指标定义再做可视化。否则空有图表、没有数据大屏项目很容易变成“好看但不准”的半成品。第三上线前要给客户做至少两轮培训。第一轮是最常用的开单、入库、审核、查询第二轮才是盘点、退货、财务对账。很多小企业的员工没有用过进销存系统培训不到位上线后会出现“人用系统还是用Excel”并行的尴尬局面账照样对不上。第四如果自己接这种项目合同里一定要把“二次开发和修改成本”写清楚。进销存系统的需求是最容易“越做越多”的今天加一个报表明天加一个字段没有明确边界很容易拖垮工期。这次i59u2562项目本身管理得比较严需求都通过需求变更单确认后期才没有失控。最后再分享一个部署的小经验正式环境上线前最好先花两天把历史数据导入、补录、核对全部跑一遍。这个项目里面最大的工作量反而不是写代码而是把客户Excel里上千个商品、几万条历史流水清洗后导入新系统。清洗过程中发现不少数据是重复的、编码不统一的这步不做干净大屏上的数字就没有意义。
干了这么多年开发最常被小企业主问的一句话是“能不能帮我那把Excel里的库存理清楚”这其实不是表格美化问题而是整个进销存流程数字化的问题。最近刚上线了一套vuepython的B/S架构进销存管理系统项目编号是i59u2562服务对象是一家做商贸批发的中小公司SKU上千个采购、销售、库存、往来账、数据分析可视化大屏全部走这一套系统。从需求调研到开发再到真正跑起来前后小半年今天把完整过程写一遍尤其是可视化大屏部分到底怎么落地踩过哪些坑希望对做同类系统的朋友有点参考价值。针对的目标读者很明确准备自建管理系统、又不想一上来就上重型ERP的中小企业IT负责人以及想接这类外包项目的独立开发者。后端是Python生态前端是Vue数据库MySQL另外用Redis做缓存。这里不聊“架子搭得多花哨”只聊业务怎么建模、单据怎么流转、数据怎么在大屏上真正有用。1. 先聊为什么小企业进销存不缺“记账功能”缺的是数据闭环1.1 真实的库存痛点货号过千之后Excel根本扛不住公司是做商贸批发的仓库常年滚动着上千个货号采购价随批次波动同一个商品今天进货价和下周可能差了5毛。销售端更复杂有按整箱批发的老客户有按件零售的散客还有几类客户的账期完全不一样有的15天回款有的拖到45天。用Excel管这些初期还行SKU到500以内的确能勉强应付。但到上千个货号时问题集中爆发采购单和入库单对不上仓库实际发的货和销售单不一致财务月底对账要拿着几份表来回比对等把差异找出来新的差异又产生了。最头疼的是“建账容易平账难”。Excel里库存余额公式互相引用中间有人改了单元格没通知别人月底谁都不敢保证那个数字是真是假。这个问题不是靠“Excel用得更细致”能解决的本质是流程没被系统约束住。所以和客户聊下来的结论很明确他们要的不是一个“电子记账本”而是一套能把采购、销售、库存、资金串起来的系统每天能自动把账算平再把结果用大屏展示出来。1.2 成品SaaS没解决的事才是自研的空间有人可能会问市面上现成的进销存SaaS一大堆为什么还要自己搞一套这个决定其实也是经过反复权衡的。第一个问题出在定制能力上。进销存这种系统看起来大家都一样真用起来全是细节商品单位要从“箱”拆成“件”客户要有等级价批发订单允许负库存出库但零售不行退货单要根据原单自动带出价格应收款要做账龄提醒。成品软件大部分功能固定能配置的部分给了参数还是绕不过去只能去适应软件而不是软件适应业务。第二个问题是费用结构。按账号、按模块、按年续费小公司几十个账号算下来几年费用并不低而且数据始终在别人的平台上导来导去也麻烦。第三个问题才是关键客户要数据分析大屏。别管是老板想看的“今日销售额”“商品TOP10”还是库管关心的“低库存预警”成品大屏模板通常是固定的最多换换颜色。真要让大屏跟自己的业务口径完全对齐比如销售额含不含税、退货要不要冲减、账期超期客户有哪些改起来相当费劲。自研也有成本但一套针对单一公司的定制系统数据模型、字段、流程都是围着业务建的后期维护成本其实是可控的。所以最终定了方案Vue做前端Python做后端B/S架构部署在一台云服务器上公司内所有电脑浏览器打开就能用。1.3 B/S架构的价值不用装客户端门店和仓库共用一套系统这里多说一句为什么坚持B/S而不是传统的CS桌面端。这家公司除了总店还有两个分仓和几个经常要开单的业务员。B/S模式下服务器只需要一台员工电脑上装个浏览器就能访问业务员在外面用笔记本电脑也能开销售单不需要到门店装客户端也省掉了桌面运维的工作量。权限体系集中在后端控制开单、审核、看数据分别对应不同角色这些在浏览器架构下做起来很顺畅。2. 技术栈选型的底层逻辑Vue Python这个组合合不合理2.1 后端选PythonWeb框架、数据校验和Excel生态都很顺手确定了Python做后端我第一反应是选FastAPI。这家公司的系统逻辑集中在单据流转和库存计算上数据交互密集FastAPI在这类业务上有几个明显优势。一个是Pydantic做参数校验非常舒服。前端传过来的销售明细、采购明细都有嵌套结构Pydantic的模型校验能在入口就把格式错、字段缺、类型不对的问题拦下来而不是等到业务逻辑里各种if判断。另一个是自动生成OpenAPI文档联调的时候前端同事直接看 /docs 页面就知道接口长什么样省了一堆沟通成本。ORM用的SQLAlchemy配合Alembic做数据库迁移。进销存系统的表结构在开发初期变化很频繁今天发现往来账需要一个收款单号明天发现库存流水要加一个关联单据类型Alembic的迁移脚本让这些改动都可以追溯。定时任务用APScheduler每天凌晨计算前一天的各商品销售汇总、库存快照供大屏读取。Python生态里还有一个杀手锏是openpyxl。客户大量历史数据在Excel里迁移时要用脚本解析并导入后面又要经常导出月报表、对账单这套库处理起来比在Java里写POI舒服多了。2.2 前端选Vue一个人也能维护得动的组件生态前端这边我用了Vue 3 Element Plus ECharts状态管理用Pinia路由用Vue Router。选Vue而不是React核心原因是团队规模和生态成熟度。这类内部管理系统的UI复杂度不算高大量页面是表格加表单加弹窗Element Plus这些组件基本覆盖了80%的场景一个人也能维护得动。Vue 3的Composition API在组织“复杂业务页面”时确实好用。比如销售出库单页面既要管客户选择、商品明细、价格计算又要联动库存余额、应收款余额把这些逻辑按功能拆成一个个组合式函数比之前写Options API时一坨mixin清晰很多。Pinia用来保存当前登录用户、可访问仓库列表、商品价格策略这些全局状态组件之间不用再一层层丢props。可视化大屏不用多说ECharts是首选文档全、图表丰富折线图、柱状图、饼图、数字翻牌都很成熟。唯一要注意的是大屏页面的组件生命周期后面专门讲。2.3 接口约定前后端分离项目里的“隐形宪法”技术栈定下来之后真正决定项目后期痛不痛苦的是接口约定。这个项目里统一了返回体、密码加密、分页结构、错误码前端所有请求方法都先封装好后面加权限、加多仓库过滤时只改一层就够了。统一返回体的结构很简单{ code: 0, msg: success, data: { list: [], total: 123 } }code为0表示成功非0是业务错误码比如1001表示库存不足1002表示单据已审核不能修改。前端拿到非0的code时统一弹错误提示不需要每个页面单独写错误处理。鉴权用的JWT登录后前端把Token存在内存里请求拦截器自动带上刷新页面时再根据用户角色重新拉取菜单和权限。这里要特别说明接口规范在项目不复杂时看不出价值一旦销售单、采购单、库存流水、往来账这些模块同时开发没有统一约定就会出现“这个接口返回数组那个接口返回对象”的情况后期联调全是低级问题。3. 核心业务模块拆解从商品档案到库存流水3.1 商品档案与多单位换算最容易做错的第一个坑进销存系统的地基是商品档案。表面上看就是编号、名称、条码、价格实际上真正的坑在单位换算。这家公司经营的商品有几个典型特征有的按箱进货、按件零售一箱12件有的按公斤进货、按袋销售还有的会根据促销活动临时组合成套装。所以在设计商品表时特意拆出了基础单位、采购单位、销售单位之间的换算关系还有单独的条码表。同一件商品可以挂多个条码一个整箱条码、一个单件条码仓库扫码出库时扫哪个都能识别。价格体系分了三级参考进价、标准售价、客户等级价。批发客户有固定的等级开单时系统自动带出对应价格业务员只要确认就好。有个小经验多单位换算字段一定要用浮动小数而不是整数并且要保留四舍五入精度。因为存在“3公斤起卖、每0.1公斤计价”的商品用整数换算会算少了。商品档案字段示例SKU编码、名称、规格基础单位、采购单位、销售单位、换算率默认仓库、默认货位参考进价、标准售价、最低售价条码列表安全库存阈值、是否允许负库存3.2 采购、销售、退货的单据流设计单据和库存互相解耦进销存的单据设计是整个系统的核心。最开始设计时犯过不少错最大的教训是单据状态和库存变动必须解耦不能在一个方法里“既改单子状态又直接改库存数量”否则单据作废、回退、改单时库存很难回滚。最终采用了“单据驱动流水”的模式任何业务动作都会经历创建单据、提交审核、审核通过后生成库存流水、同时更新库存余额。整个过程都在一个数据库事务里完成。采购入库单的状态流转如下状态含义后续操作草稿采购员录入还没有提交可以修改、删除待审核已提交但未处理可以撤回已审核审核通过库存已入账只读可生成采购退货单已关闭手动中止或全部退货完成只读销售出库单的逻辑类似但多了一个“确认出库”动作。批发业务经常是上午开单、下午发货中间时间差很长如果开单就直接扣库存会出现单子积压但仓库已经断货的情况。所以这里做成销售单生成时占用库存但不实际扣减实际扣减发生在仓库确认出库时。库存流水的字段这里给一个参考流水号、关联单据类型、关联单据号商品SKU、仓库、变动数量变动前库存、变动后库存业务时间、操作人备注、来源类型这个表只增不改是账实一致的核心凭据。库存余额表只是流水表的聚合结果任何一次盘点、出库、入库都通过新增流水来改变余额不允许直接改余额表。3.3 库存盘点、预警与批次管理哪些必须做哪些可以缓一缓库存预警是必须做的。客户仓库里上千个货号靠人记安全库存不现实。系统里给每个商品配了安全库存阈值运行一个定时任务每天早上扫描一次低于阈值的自动生成预警列表并在大屏上展示缺货数。采购员根据预警单补货比月底盘点时才发现断货强多了。盘点功能则是上线后第二个星期才临时加的。原因很现实手工管理时代遗留下来的账实差异比预期大需要一套完整的盘点流程来纠偏。设计上做了盘点单库管选择仓库和商品范围填实盘数量系统自动和账面库存做差异计算生成“盘盈/盘亏调整单”调整单审核通过后同样走库存流水把这个差异记进账里。批次管理这里没有做因为客户的商品保质期较长而且目前没有过期召回需求。如果做食品、化妆品、医药类业务批次和保质期就必须在商品表、库存流水里全部带上否则后面没法追溯。这个取舍建议大家在接项目时提前判断清楚。3.4 往来账模块批发业务的应收应付比库存还重要做商贸批发往来账比库存还敏感。客户月结是常态只记销售额不追踪回款月底财务一定崩溃。这个项目里单独做了应收款模块。销售单审核通过后自动生成应收单按客户账期分为“现结”和“挂账”。财务收到回款后录收款单系统自动勾对对应客户的未结销售单。应收款最核心的功能是账龄分析。按未回款天数分档0到30天、31到60天、61到90天、91天以上。大屏上有一块专门展示超期应收的客户很多老板盯着看比看销售额还认真。因为这东西直接关系到现金流。3.5 一个容易被忽略的模块基础数据权限这家公司有总店、两个分仓还有三个业务员。同样的商品在不同仓库的库存是分开的同样的销售数据业务员只能看自己名下客户的店长能看整个门店老板能看全部。这是通过“用户—角色—数据范围”做的角色定义“资质”数据范围定义“看到哪个仓库、哪个业务员的单”。所有列表查询接口后端都统一注入当前用户的数据权限过滤条件前端根本不用关心。4. 数据分析可视化大屏指标定义比画图更花时间4.1 先和老板对齐口径再动ECharts项目推进到第二个月大屏这个需求才浮出水面。客户第一次说“搞个大屏吧”时我很警觉地说先不急着画图得聊聊你到底想看什么。因为以前见过太多电子屏上堆了十几张图表没有任何老板真正每天看。我们花了两个下午把业务方关心的指标逐条列出来逐条定义口径。这里最关键的一步销售额必须和财务口径对齐。比如“今日销售额”客户内部到底是指“当天出库单的应收金额”还是“当天实际收到的回款”如果这里不对齐屏幕上数字和财务日报对不上系统上线第一天就会被否定。最终确认的核心指标如下指标口径定义刷新频率今日销售额当日已出库销售单的应收合计不含作废单5秒今日销售单数当日已出库销售单数量5秒近7日销售趋势按自然日聚合销售金额的折线30秒商品销售TOP10按销售金额排序含销量和毛利30秒品类销售占比按一级分类聚合的销售金额饼图30秒库存总额当前所有仓库库存成本总和1分钟低库存预警低于安全库存的商品数量1分钟应收超期超过30天未回款客户数及金额1分钟今日采购入库当日已审核采购单的入库金额5秒每个指标都写明公式和取数来源。比如“商品销售TOP10”里销售数量是已出库单的明细数量合并退货单要冲减毛利里的成本用商品的平均进价而不是最后一次进价。口径确定后大屏才有讨论价值。4.2 后端聚合设计大屏刷新5秒一次数据库不能死撑大屏指标众多如果每个指标都实时查明细表做聚合数据库扛不住。这里采用了三层架构。第一层是Redis缓存。每个指标设计一个自动失效机制比如“今日销售额”在销售单审核通过时主动删除对应的Redis Key下次大屏请求时重新计算。如果一直没人访问这个Key就一直在缓存里避免无意义计算。第二层是每日统计表。每天凌晨用APScheduler跑定时任务把前一天的销售汇总、库存快照、应收汇总写进一张统计表。这样“近7日销售趋势”只需要查七条记录而不是去扫描百万行销售明细。第三层才是实时查询。真正需要实时的只有“今日销售额”“今日销售单数”这种当天数据因为当天明细量不大直接查也快。坏味道是连个预警数量都要去求和整个库存流水表这种查询必须进统计表。给一个示例商品销售TOP10的实时聚合SQL按已出库销售单明细分组SELECT sku_id, SUM(quantity) AS total_qty, SUM(amount) AS total_amount FROM sale_order_item WHERE order_status IN (confirmed, delivered) AND warehouse_id :当前用户可见仓库 GROUP BY sku_id ORDER BY total_amount DESC LIMIT 10;注意这个SQL在产品上线初期没问题但销售明细一旦膨胀还是要改成定时统计表方案。宁可让大屏和实时系统晚几分钟也不能让聚合查询拖垮核心开单。4.3 大屏前端实现要点布局、动画和自动刷新都要控制节奏大屏前端用的是Vue 3 ECharts独立路由全屏展示。整体布局直接用CSS Grid按比例划分区域顶部是主标题和三个核心数字翻牌左侧放销售趋势和品类占比中间放地图客户分布后来发现客户就那么几个城市就换成了分仓库销售对比、右侧放商品TOP10和应收超期底部放低库存预警和今日采购入库。设计稿按1920×1080的参考分辨率来做用rem配合缩放适配保证投到不同尺寸的电视上不变形。自动刷新这块有一个很重要的细节每个图表的刷新频率不完全一样。翻牌数字5秒一次图表类30秒到1分钟一次。一开始全部设成5秒结果发现ECharts更新动画互相打架CPU占用也高。后来把刷新逻辑统一收敛到一个定时器管理器里每个组件注册自己的刷新间隔组件卸载时自动注销定时期避免路由跳转后ECharts实例还在后台跑。大屏实际运行时还有网络波动问题。给每个请求加了失败重试和指数退避连续失败3次就不自动刷了只保留手动刷新按钮避免一直弹错误提示。ECharts组件化封装有个简单经验每个图表用同一个折线图、柱状图、饼图组件data属性接收配置好的option对象用watch监听数据变化后调用chart.setOption(newOption)不用每次都销毁重建。4.4 大屏的“口径一致性”细节容易被忽略再补充一个细节大屏右上角的“今日”如果设置为自然日0点到24点那凌晨开单出货就会被算到前一天老板早上来看数字会发脾气。这家公司营业时间是早8点到晚10点所以系统里专门配置了一个营业日规则“今日”从当天0点开始算但每天早上自动推送昨天的完整汇总。大屏上只显示“今日数据”和“昨日数据”两个数字口径统一谁来看都不会误解。5. 实测中踩过的坑并发、死锁、导出卡死和扫码枪的回车5.1 并发出库把库存扣成负数上线第二周仓库高峰期同时出库问题来了最后一件商品两个销售单同时提交出库结果两个单子都成功了库存变成了-1。这是典型的并发写问题。当时库存更新用的是“先查余额再计算新余额最后UPDATE”的写法在高并发下等于没有保护。解决方式用了乐观锁。库存表加了一个version字段更新语句改为UPDATE stock_balance SET quantity quantity - 1, version version 1 WHERE sku_id 商品ID AND warehouse_id 仓库ID AND version 读取到的version AND quantity 1;执行返回的影响行数是0说明版本冲突或库存不够这时回滚当前事务给前端返回“库存不足或已被占用”的提示。这里的取舍是为什么没用SELECT FOR UPDATE悲观锁因为出库操作非常频繁锁行时间虽然短但在高峰时段容易排队而且一旦事务里还有其他查询锁的持有时间不可控。乐观锁对“冲突概率低、峰值高”的场景更合适。5.2 事务顺序不一致导致死锁项目开发中遇到一次MySQL死锁报错信息指向库存流水表。排查后发现一个事务按“先更新销售单头、再更新库存流水”的顺序另一个事务按“先更新商品主表、再更新库存流水”的顺序。两个事务都申请了对方的行锁互相等对方释放数据库选择了回滚一个事务。这类问题最好的解法不是靠MySQL自动检测死锁而是让所有事务遵循统一的加锁顺序。我在库存写入口做了一个强制约定任何库存变动方法必须先锁定对应的库存余额行再操作流水。顺序统一后死锁就再也没出现过。5.3 十万行流水导出把进程打满上线一个月财务要求导出全部流水到Excel十万行数据。最初直接在接口里同步生成Excel前端等了几十秒超时后端CPU飙高其他请求全被阻塞。后来改成异步导出方案导出请求先写一条任务记录后台任务用openpyxl生成文件到服务器临时目录完成后更新任务状态。前端轮询任务状态发现完成后再触发下载。这个过程不占用请求线程用户体验也好。另外给所有导出任务加了行数上限和分页条件默认只导出最近三个月要更早的数据就走条件筛选。5.4 扫码枪的“回车尾缀”导致搜索框重复提交仓库扫码出库时用的是USB扫码枪。扫码枪默认行为是扫完条码后自动补一个回车正好触发前端输入框的回车事件导致页面在未处理完当前条码时又提交了一次。实际效果就是同一个条码扫一次屏幕上出现了两行。解决方法是输入框只做录入不监听回车统一在“扫描完成”按钮上触发事件。同时给输入加了一个300毫秒的防抖防止连续扫码时出现抖动。5.5 大屏高刷新间隔下的数据库连接数被打满大屏初期把刷新间隔全设在5秒多个指标同时刷新统计接口又走实时聚合数据库连接一度被打满。后来强制规定卡片类数据走Redis图表类数据走统计表实时查询只保留当天数据。连接池也调小了最大连接数控制在数据库能承受的范围宁可排队也不拖垮整个业务系统。6. 部署与上线系统真正跑起来还有三分靠流程6.1 单机最小部署方案这个系统的规模完全没到微服务那一步部署方案越简单越好。一台4核8G的云服务器装好MySQL 8、Redis、Nginx、Python环境前端构建后直接放在Nginx的静态目录后端用Gunicorn启动FastAPISupervisor守护进程。Nginx配置大概长这样server { listen 80; server_name _; root /var/www/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }前端路由是history模式所以需要try_files把未知路径指向index.html否则刷新页面会404。这点第一次部署时踩过写出来提醒一下。数据备份放在每天凌晨3点用crontab执行mysqldump备份文件保留30天。同时监控磁盘占用和慢查询日志每周看一次避免业务增长后磁盘写满或者某个SQL越来越慢。6.2 上线不是终点业务流程约束比代码更重要系统上线第一天一切正常。第三天就出问题了有几个销售单在系统里找不到对应的出库记录。查完发现是流程没走通有个业务员习惯先发货后回办公室补单结果货发出了单子忘了补库存却已经实发。这里只能说一个经验进销存系统能不能跑起来一半靠代码一半靠流程。代码层面能做的是把打印的单据、库存流水、审批日志都留好痕迹流程层面必须和客户约定清楚“先开单后出库不允许先出库后补单”否则库存永远是虚的。我们甚至还做了“不允许负库存出库”的开关但批发客户强烈要求保留负库存能力只是每次负库存出库都会在系统里打上标记每周盘点时重点检查这些异常单。6.3 上线后的几个具体效果系统完整跑了三个月之后几个数字很直观月底对账从两天缩短到半天财务不再需要人工比对Excel库存预警让客户第一次做到了“断货前补货”而不是断货后才知道应收账龄表成了老板每周一必看的东西超期客户催款有了明确依据大屏每天开着商家自己说“现在开会不用再用PPT翻Excel了”不过要说最值钱的地方其实不是大屏的科技感而是每天营业结束时系统能自动算清“今天卖了多少钱、哪些货要补、哪些客户该催款”。一夜之间把原来的手工流程数字化这才是这个项目真正解决的核心问题。7. 一些补充建议给正打算做同类系统的朋友最后聊几句自己的真实体会。第一进销存项目技术难度不高难点全在业务细节上尤其是单位换算、单据状态机、库存流水、往来账这四个部分。技术栈怎么样都行但这几块的数据模型如果没设计好后面会一直被返工困扰。第二大屏不要一开始就做。先把核心业务跑通把数据积累起来再做指标定义再做可视化。否则空有图表、没有数据大屏项目很容易变成“好看但不准”的半成品。第三上线前要给客户做至少两轮培训。第一轮是最常用的开单、入库、审核、查询第二轮才是盘点、退货、财务对账。很多小企业的员工没有用过进销存系统培训不到位上线后会出现“人用系统还是用Excel”并行的尴尬局面账照样对不上。第四如果自己接这种项目合同里一定要把“二次开发和修改成本”写清楚。进销存系统的需求是最容易“越做越多”的今天加一个报表明天加一个字段没有明确边界很容易拖垮工期。这次i59u2562项目本身管理得比较严需求都通过需求变更单确认后期才没有失控。最后再分享一个部署的小经验正式环境上线前最好先花两天把历史数据导入、补录、核对全部跑一遍。这个项目里面最大的工作量反而不是写代码而是把客户Excel里上千个商品、几万条历史流水清洗后导入新系统。清洗过程中发现不少数据是重复的、编码不统一的这步不做干净大屏上的数字就没有意义。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
