这套咖啡门店进销存系统的毕设题是这段时间我帮学生带的项目里比较有意思的一个题号38142技术路线限定JAVA。看到题目第一反应是常规CRUD但真正把咖啡门店的进销存业务拆完才发现这玩意儿跟学校里那种纯商品进销存还是有不小的距离。咖啡门店除了有常规的采购、入库、销售、盘点外还夹着原料到成品的加工换算、鲜牛奶的保质期批次管理、杯装饮品的损耗折算。这篇文章我就把这套系统的拆题思路、数据建模、核心功能实现、还有联调时踩过的坑完整梳理一遍代码部分已经整理成可直接运行的工程需要的同学可以对照本文按图索骥。1. 项目背景与需求拆解1.1 咖啡门店进销存和普通商品进销存差在哪早几年很多学生做进销存系统会套超市模板——商品表、供应商表、采购单、销售单完事。但咖啡门店的真实运营状态完全不是这么回事。门店里要管的东西分成两大类一类是原材料咖啡豆、全脂牛奶、燕麦奶、糖浆、纸杯、杯盖、吸管、打包袋另一类是卖给顾客的成品拿铁、美式、卡布奇诺、冷萃甚至还有少数非咖啡饮品。原材料入库以后不能直接按件卖它要先经过咖啡机、制冰机、人手操作加工成成品才能销售。这意味着系统不能只管理商品本身的库存还必须管一条原料消耗关系链咖啡行业叫配方或BOM。第二点差异是保质期。普通便利店的进销存对保质期敏感性不强但咖啡门店的冷藏牛奶保质期短则6天长则14天一旦把批次先进先出做不好过期报废的损耗就会很夸张。系统里的库存就不能只是一个数量字段必须把每一批入库的原料按批次记录入库日期和保质期销售扣减时按先进先出原则消耗。这些需求在校验一般的商品进销存模板里根本没有。还要考虑半成品或门店自制带来的库存变化口径问题。咖啡门店有部分物料是二次加工的比如冷萃咖啡液提前批量制备装瓶后也会有损耗报废。不是说采购买进来多少销售端就能对上多少中间的损耗和内部转化需要有单据记录最好有独立的加工单或者领料出库单。1.2 系统角色与核心业务流程梳理和这类毕设系统常见的角色划分差不多这套系统我拆成了四类角色覆盖门店内外两条线。角色权限边界典型操作系统管理员用户管理、基础数据维护、角色授权创建员工账号、维护供应商档案、配置预警参数采购专员采购计划、采购订单创建与提交、到货确认新建采购单、提交审核、确认到货、登记采购入库店长采购审核、加工单审核、库存盘点审核、报表查看审批采购计划、批准盘点结果、查看经营日报收银员/店员前台开单、销售出库、简单库存查询点单结算、查看库存和预警角色划分定了以后核心业务流其实可以收敛成三条主线第一条是采购进店链路门店根据每日销售量预测和库存水位向供应商发起采购申请 → 采购专员录入采购订单 → 店长审核 → 供应商送货 → 仓库/吧台负责人确认收货 → 系统按采购明细自动生成入库记录并给每一批原料生成独立的批次和保质期信息。第二条是生产/加工消耗链路咖啡门店一般不会有庞大的生产车间更多是吧台边做边卖模式。这部分我建议用配方销售扣料来实现也就是在商品和物料之间维护BOM表销售一个拿铁系统就自动按配方扣减对应咖啡豆、牛奶、纸杯等原料库存。如果想要更严谨还可以加一个每日备料/预加工单来处理批量煮制咖啡液或批量备料这样能够区分理论消耗和实际消耗。第三条是库存查询与盘点链路店长和店员能实时查看每一种原料的库存数、可用天数、临期批次定期做全盘或抽盘系统自动生成盘盈盘亏记录并调整库存。这三条链路理顺了报表模块才有数据可以汇总日报就能算出原料成本率、理论毛利和损耗率而不是只有光秃秃的销售流水。2. 总体设计与技术选型2.1 后端技术栈选了哪些组件为什么这么选毕设项目的一个特点是既要保证技术方案能落地又不能让复杂度失控。这套系统最终锁定的后端组合是Spring Boot 2.7.x MyBatis-Plus MySQL 5.7权限部分用Spring Security整合JWT做无状态认证。解释一下每个选择的理由。Spring Boot不必多说当前企业级Java后端最主流、文档最全、学生最熟悉。MyBatis-Plus是加分项它的BaseMapper直接提供单表CRUD代码量少很多同时又保留了XML自定义SQL能力适合做进销存里那种多表关联、分组汇总的统计查询。MySQL稳定好用配SQLyog或Navicat管理都很方便。权限这块常见的选择有Spring Security JWT和Shiro JWT。我实际给学生用的是Spring Security JWT只有一个核心原因项目里不需要太复杂的资源级权限只需要按角色控制接口访问Spring Security的注解式鉴权最顺手。需要注意Spring Security 5.7版本之后WebSecurityConfigurerAdapter被弃用很多教程里的写法会报错所以工程里我直接用了SecurityFilterChain后面写代码时会贴这段。前端部分为了让论文里有界面截图和演示视频单独用Vue3 Element Plus起了一个管理端页面通过Axios调后端REST接口。如果觉得Vue门槛偏高也可以把前端换成Thymeleaf服务端渲染后端一套代码直接出页面工作量会更小。但考虑到进销存系统里表格、弹窗、表单交互很多Vue Element Plus做出来的视觉效果确实更好我就保持了这种前后端分离结构。一个容易被忽略的小点是JDK版本。如果选Spring Boot 2.7.x用JDK 8最稳不要顺手用JDK 17或21MyBatis-Plus老版本在编译期有时会踩坑如果非要用JDK 17就得把Spring Boot升到3.0以上但Spring Boot 3.x把javax改成jakarta很多细节点会跟着变毕设阶段真没必要给自己加戏。2.2 项目分层结构与源码目录规划工程项目按标准的单模块Maven结构组织但package分层一定要清晰不能让Service里蘸着Controller也不能把SQL写在业务代码里。这套系统我采用的包结构是这样的com.coffee.stock ├── common // 统一返回结果、异常处理、常量定义 ├── config // Security、CORS、Jackson等配置 ├── controller // 控制层接口入口 ├── service // 业务逻辑层接口及实现 ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体类 ├── dto // 入参出参对象、视图模型 └── utils // JWT工具、日期工具等分层的核心原则是接口不进controller做业务、controller只做参数接收和结果包装。很多学生喜欢把判断逻辑全写在controller里觉得这样代码少但一旦后面加入采购审核流、配方换算这些逻辑controller就会膨胀到没法看而且Service层没法独立测试。再单独说说exception处理。系统里要处理采购单不存在、库存不足、单据已被审核、重复提交这类业务异常我统一定义了BizException通过RestControllerAdvice做一个全局异常处理器把错误信息封装成统一格式返回前端。这样Service里不需要每个方法都try-catch来回传代码干净很多。2.3 数据库表结构设计的关键决策数据库是整个系统的地基这一块多花十分钟后面能少改三天代码。进销存相关的核心表我拆成了十二张按功能域可以分成四组。基础资料域比较直接包括sys_user用户、sys_role角色、product商品/物料档案、supplier供应商业务单据域是进销存的主干包括purchase_order采购单头、purchase_order_item采购单明细、inbound_order入库单、stock_record库存流水库存核心域是bom_info成品配方表、product_batch_stock批次库存表、stock_check盘点单再加上system_config系统配置用来存预警参数。重点说一下product表的建模。这张表不能只按业务直觉建成一张普通商品表因为咖啡门店的product既要存原料也要存成品两类数据字段大部分相同但业务含义差异很大。一张表里我用product_type做区分0代表原料、1代表成品价格、单位、库存预警值都放同一张表里就能统一维护。如果拆成RawMaterial和Product两张表配方表做关联和统计时会变得复杂没必要。批次库存表是整个库存模块的精华字段设计我强烈建议按下面的样子来字段名类型说明idbigint主键product_idbigint商品/物料IDsupplier_idbigint供应商IDbatch_novarchar批次号方便追溯quantitydecimal当前批次剩余数量production_datedate生产日期/入库日期expire_datedate保质期截止日期create_timedatetime创建时间把库存按批次拆开意味着同一个物料同一时刻可能有多个批次并存比如说牛奶7月1日和7月3日分别入库了两批批次库存表里就有两条记录。销售扣减时按expire_date升序遍历先扣临期批次这样先进先出才精准。如果只是在一行库存记录上写quantity加加减减保质期预警就无从谈起。配方表bom_info我是这样设计的一个成品对应多行配方明细每行记录原料id和用量。举例一杯拿铁对应的bom_info可以有三行咖啡豆18克、全脂牛奶220毫升、PET杯盖一套。销售端只需要知道卖出了一杯拿铁系统就按bom读取明细把消耗记录写入库存流水。这个思路对咖啡门店特别适配对写论文时讲成本核算也是一个很好的切入点。3. 核心流程与功能实现3.1 采购入库流程的状态机与实现思路采购业务这条链上状态管理是核心难点。我见过不少学生项目把采购单做成一次性创建的死单建成即入库这样虽然代码简单但完全不符合门店先审后收的真实流程。这套系统的采购单设计了四个状态待审核(0) → 已审核/待收货(1) → 已入库(2) ↘ 已驳回(3)具体来说采购员填单时录入供应商、预计到货日期和每行物料的数量、预估单价采购单生成后默认是待审核。提交给店长审核后有两种结果驳回退回给采购员修改通过采购单进入待收货状态。等货到了采购员或库管在系统里做确认到货并入库系统才把采购单状态改成已入库同时往两处写库存数据一是往product_batch_stock表插一条带批次的库存记录二是往stock_record表写一笔入库流水。很多初学者会问直接改库存表数量同时插一条流水不就行了为什么还要多一个批次表原因是库存数量是状态流水是行为如果要查某一天某一批牛奶还剩多少或者做保质期预警只靠流水远远不够。批次表相当于当前存量结构入库按批次插入出库按批次扣减流水则负责记录每一次变化的来龙去脉。库存快照行为流水分开维护报表和审计都能追溯。我贴一段采购入库service里生成批次库存的核心代码这是整个模块里最容易理解也最值得参考的部分Transactional(rollbackFor Exception.class) public void confirmInbound(Long orderId) { PurchaseOrder order purchaseOrderMapper.selectById(orderId); if (order null || !Integer.valueOf(1).equals(order.getStatus())) { throw new BizException(采购单不存在或当前状态不允许入库); } LambdaQueryWrapperPurchaseOrderItem itemWrapper Wrappers.lambdaQuery(); itemWrapper.eq(PurchaseOrderItem::getOrderId, orderId); ListPurchaseOrderItem items purchaseOrderItemMapper.selectList(itemWrapper); for (PurchaseOrderItem item : items) { ProductBatchStock batch new ProductBatchStock(); batch.setProductId(item.getProductId()); batch.setSupplierId(order.getSupplierId()); batch.setBatchNo(generateBatchNo(order.getId(), item.getProductId())); batch.setQuantity(item.getQuantity()); batch.setProductionDate(LocalDate.now()); Product product productMapper.selectById(item.getProductId()); // 库存预警天数在物料档案上配置比如牛奶3天预警 batch.setExpireDate(LocalDate.now().plusDays(product.getShelfLifeDays())); productBatchStockMapper.insert(batch); StockRecord record new StockRecord(); record.setProductId(item.getProductId()); record.setChangeType(INBOUND); record.setChangeQuantity(item.getQuantity()); record.setRefOrderNo(order.getOrderNo()); stockRecordMapper.insert(record); } order.setStatus(2); // 已入库 purchaseOrderMapper.updateById(order); }几个细节再强调一下。createOrder后如果货一直不到就永远卡在待收货状态系统里提供了一个采购单跟踪列表按供应商汇总可查看已订未到金额否则过期订单只能靠人去翻。入库时还要校验商品档案里是否启用了批次管理不是所有物料都严格按保质期走像吸管、打包盒这类仓储期很长的物料可以走简单库存逻辑批次表只记录一批即可。3.2 配方出库与销售扣料如何联动咖啡门店的前台卖出一杯饮品和后台库存之间不是直接一对一关系。一杯美式卖28元系统如果直接把美式这个商品的库存减1那咖啡豆库存一辈子都不会减少。所以这里必须引入配方扣料机制。表格化描述一下拿铁和美式两个配方能更直观看清建模逻辑成品配方原料单位用量单位拿铁(大杯)意式咖啡豆18克拿铁(大杯)全脂牛奶220毫升拿铁(大杯)大杯盖1套美式(大杯)意式咖啡豆20克美式(大杯)大杯盖1套销售结算操作触发的服务伪代码逻辑是这样的Transactional(rollbackFor Exception.class) public void sellFinish(SaleOrder saleOrder) { BigDecimal totalAmount BigDecimal.ZERO; for (SaleOrderItem saleItem : saleOrder.getItems()) { Product product productMapper.selectById(saleItem.getProductId()); if (Integer.valueOf(1).equals(product.getProductType())) { // 成品需要按配方扣减原料库存 ListBomInfo bomList bomInfoMapper.selectList(Wrappers.lambdaQuery() .eq(BomInfo::getFinishedProductId, product.getId())); for (BomInfo bom : bomList) { deductStock(bom.getMaterialId(), bom.getQuantity().multiply(saleItem.getQuantity())); } } else { // 如果物料被直接销售也需要扣库存 deductStock(product.getId(), saleItem.getQuantity()); } totalAmount totalAmount.add(product.getSalePrice().multiply(saleItem.getQuantity())); } // 落销售单主表 saleOrder.setTotalAmount(totalAmount); saleOrderMapper.insert(saleOrder); }如果门店有批量备料环节比如早上一口气煮2升冷萃液这时候需要在系统里做一个生产入库单把咖啡液按自制半成品入库再从半成品往下做一层配方。这种设计有两个好处一是核算准确冷萃液生产过程中产生的咖啡渣损耗可以体现在领料量与实际入库量的差额上二是收银员在高峰时段不需要逐杯扣料系统压力集中在备料环节。不过对大多数毕设而言做到销售单据自动按配方扣减原料这一层已经超过了及格标准。有了这层逻辑后台报表才能算出每杯饮品的原料成本比如一杯拿铁原料成本大约是多少当月总销量对应理论原料消耗又是多少再对比实际盘点结果损耗异常就能一眼看出来。3.3 保质期预警模块的设计进销存系统如果只是管数量保质期预警就没必要单独做模块了。但咖啡门店损耗重灾区就是牛奶过期没发现、到盘点才发现一整批报废。所以在批次库存表之上要单开一个预警模块。我是用一个Spring定时任务来做这件事的每天凌晨两点扫描一次product_batch_stock这张表找出expireDate与当前日期的差值小于等于预警天数物料档案可以单独配置比如牛奶配置3天、面包配置2天、糖浆配置15天且剩余数量大于零的批次在预警结果表里生成记录并在登录后的首页以醒目列表展示给店长。单纯有定时任务还不够临期处理动作也很重要。预警列表的每条记录要能点击处理处理动作分三种正常使用继续扣减优先消耗该批次、转赠/内部食用、报损报废。选择报废后系统会自动生成一条报损出库流水扣减该批次库存这样月底报损的原因是清晰可查的不会产生一笔进得来、出不去的账。3.4 盘点与损益调整怎么做到不破坏库存流水审计盘点逻辑看着简单实际上是进销存系统踩坑重灾区。原因在于盘点过程中会出现账实差异系统要调库存但库存调整如果直接去改product_batch_stock的现有数量那之前的所有流水记录跟当前库存必然对不上整套系统就丧失可信度了。正确的做法是让盘点也走单据流水先按实物盘点的结果录入初盘数量系统自动算出每项物料的账存数量-实盘数量差额正数代表盘盈、负数代表盘亏。盘点单经店长审核通过后系统生成一笔类型为STOCK_CHECK的库存流水并同时调整对应批次的库存剩余数量。这就能保证库存变化永远有单据来源不会出现凭空消失的记录。还需要考虑拆单审核场景。一张全店盘点单可能涉及两百多个物料如果某几个物料盘亏较大需要店长单独确认整个单一次性审核显然不方便。但考虑到毕设的演示场景做成整单审核完全没有问题也不会被评委抓住把柄。重点是表达清楚了盘盈盘亏是要经过审核的这个业务支撑。实际企业ERP会做拆单审批那是产品复杂度的问题与这个项目规模不匹配。4. 实战中容易踩的坑与排查方法4.1 库存扣减并发问题别用查再减做进销存系统并发是绕不开的话题。但大多应届生写的代码都是这样的套路ProductBatchStock stock mapper.selectById(productId); if (stock.getQuantity() target) { stock.setQuantity(stock.getQuantity() - target); mapper.updateById(stock); }这段代码单线程测没问题但一旦收银台同时来两笔订单两个请求同时读出库存为10同时判断够扣又同时把库存更新成8最后一杯饮品就被凭空卖了两次。这就叫超卖/超扣。解决方式最常用的是两条路一条是更新带上库存条件一条是用乐观锁版本号。更新带库存条件是这么写的int rows productBatchStockMapper.deductStock(batchId, quantity); // SQL: update product_batch_stock // set quantity quantity - #{quantity} // where id #{batchId} and quantity #{quantity} if (rows 0) { throw new BizException(库存不足扣减失败); }数据库行锁会保证同一时刻只有一个事务能成功更新该行不会出现先读出旧值再覆盖新值的问题。用乐观锁理论上也可以但需要额外维护version字段代码多几行不如直接用条件更新简单粗暴。注意这里一定要在事务里执行并且如果一次销售扣多个物料任何一个物料扣减失败都需要整体回滚避免出现收了钱却只扣了部分库存的脏数据。如果觉得批次级扣减还不够可以考虑在product上限时约束调整到物料维度再按批次先进先出遍历不过那属于更精细的库存引擎设计毕设做到单批次扣减防超扣已经足够答辩时能把并发扣减原理讲清楚就已经是亮点。4.2 BigDecimal不要用double算金额这是老生常谈但每次改代码还是会看到有人用double来存金额。门店一杯拿铁28元如果营销活动打9折double计算会出现25.200000000000003这种经典结果。哪怕最后四舍五入显示没问题审计一栏也会显得不专业。这系统里我统一要求数据库金额字段用decimal(10,2)Java实体用BigDecimal计算销售总价、采购总价、毛利都走BigDecimal。MyBatis-Plus映射decimal不会丢精度但做除法时注意要显式传入MathContext或setScale否则除不尽时会有ArithmeticException。还有一点销售单价、采购单价、成本价三个字段虽然在product表里都叫price但含义不同。为了论文里好描述建议在实体里明确区分salePrice、purchasePrice和costPrice而不是全都叫price。今后做利润计算、成本分析报表时就不用再猜字段含义了。4.3 JWT认证和接口鉴权的常见报错毕设项目里做接口权限的适配报错重灾区通常是Spring Security的过滤放行顺序写错了。早期的WebSecurityConfigurerAdapter不推荐之后新写法要让所有接口默认走认证同时把登录接口和静态资源放行Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests() .antMatchers(/api/auth/login, /doc.html, /webjars/**).permitAll() .antMatchers(/api/purchase/audit/**).hasRole(MANAGER) .anyRequest().authenticated(); http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }注意hasRole和hasAuthority的差异是Spring Security的经典扣分题。hasRole(MANAGER)要求用户角色名是ROLE_MANAGER但很多人数据库里存了manager接口一调就403。解决办法是统一在用户登录成功后给角色设置ROLE_前缀或者在配置里用hasAuthority(ROLE_MANAGER)总之前后要一致。这个问题我在联调阶段基本每次都会被绊一下建议项目跑起来就先用一个带权限的接口验证login、无权限、越权三个场景。5. 后期扩展与答辩准备5.1 这套系统还能往哪些方向做增强进销存系统是做不完的毕设能稳定运行、论文逻辑自洽就已经达到目标。但我个人建议如果时间和精力允许可以挑下面一到两个方向做增强会让项目明显区别于隔壁同学的普通管理系统。第一个方向是数据可视化大屏。把每天的销售额、订单量、原料消耗量、库存周转天数放到一个首页看板上用ECharts展示折线图和饼图。门店经营者不需要打开一堆列表自己去算今天赚了多少打开系统第一眼就能看到所有核心指标。这个方向对前端要求不高但演示时视觉冲击力极强。第二个方向是库龄分析和智能补货建议。目前系统能知道每个批次入库多久了、有多少临期库存那稍微扩展一下就能在采购计划页面上提示哪些物料需要在未来几天补货、建议补货量是多少。计算公式是近7天平均日销量×采购提前期天数-当前可用库存。这已经有点商业系统智能化的味道放在论文的创新点里也说得过去。第三个方向是移动端适配。用H5或微信小程序给店员做一个移动盘点入口和采购审核入口店长人不在店里也能完成单据审批贴近真实运营。如果做小程序需要考虑后端接口要能被微信访问本地联调时可以用内网穿透工具但如果担心复杂做H5配合浏览器直接访问会更省事。5.2 答辩评委常追着问的几类问题写论文和准备答辩的过程里有几个技术问题基本属于必问题提前把回答思路准备好现场就不会卡壳。第一个问题一定是库存扣减如何防止超卖。答案要讲清楚两层结构数据库层面靠条件更新解决并发覆盖应用层靠事务保证多物料扣减原子性。如果能说清悲观锁与乐观锁的取舍、为什么选择条件更新的理由基本就已经能够证明是真正理解了。第二个问题会围绕为什么要设计配方表。可以回答说咖啡门店的库存主体是原料而非成品销量不能直接对应库存量需要通过BOM配方将销售单转化为原料消耗同时还可以用预计消耗和实际消耗对比来发现原料浪费。最好举一个一杯拿铁需要18g豆子220ml牛奶的具体例子来佐证。第三个问题会问系统的表和表之间怎么关联。这时不能只会说外键而要说明主单据与明细单据是1对N物料库存按批次独立存储销售单、采购单、库存流水是围绕单据形成闭环并强调所有库存变动都有单据来源财务审计上才能解释每一笔差异。第四个问题可能会把业务和实现结合如果今天牛奶库存为负说明什么回应思路要给出具体的排查路径先确认是否存在未审核的盘点单再查临期报废有没有下达报损出库再核对销售扣料是不是BOM配置单位不对导致超扣。这些问题看起来在问业务实际上是在考察数据一致性和错误追踪意识。5.3 一份能直接上手的自测清单系统写完不等于功能全对建议大家按下面的顺序做一轮自测基本上可以把隐藏的80%逻辑问题暴露出来。编号自测场景预期结果1创建一个没有任何明细的采购单并提交系统应拦截不能生成空单2采购单驳回后再次编辑提交状态能回到待审核且原单号不变3对已入库的采购单再次入库系统拒绝提示采购单已完成4一次售出多杯不同饮品原料库存按BOM明细逐项扣减5库存不足时执行销售整笔订单回滚不产生部分扣减6修改物料保质期预警天数后重新扫描预警结果按新参数刷新7库存盘点提交后审核库存同步变化流水记录类型为盘点8三个角色分别登录访问越权接口返回403或无权限提示9销售总价用BigDecimal累加分页合计和订单金额完全一致10模拟同一商品并发销售库存不会出现负数或超扣这些自测项除了要过功能更重要的是观察程序有没有报异常或者日志里有没有莫名其妙被吞掉的错误。一个成熟项目前端弹错误提示也好、后端打日志也好错误信息必须能读懂不能只显示系统异常四个字否则排查问题会变得非常痛苦。在项目交付前我自己有一个多年的习惯从git仓库clone一份新代码按README文档从零把数据库和生产配置跑起来再完整跑一遍自测清单。很多毕设项目在原作者电脑上能跑、换台电脑就起不来绝大多数问题就出在环境依赖文档写得不完整、数据库脚本执行顺序没人验证、配置文件里的绝对路径没有改成相对路径。这套系统的数据库脚本和初始化数据已经全部集成到工程目录的doc/sql路径下执行顺序按文件名编号走就行双击跑完就能看到带演示账号的初始数据。最后再提醒一句如果时间不太够优先把主流程的健壮性打磨好其次才是页面美化毕竟系统最终是给店长和收银员用的一次入库录入中途报错、再登录发现单据状态错乱这种事一发生就会让整个系统的可信度垮掉。
