药房药品采购集中管理系统：设计、事务与权限实战-北京尧图网络

这系统我在开发组里前后摸了两轮第一轮光搭骨架就返工了三次第二轮才把流程理顺。身边不少朋友也做过同类课题踩的坑几乎都一样要么只把增删改查堆出来、业务逻辑稀烂要么前后端接口各说各话、联调时直接崩盘。这篇就用一个模拟项目X的完整落地过程把药房药品采购集中管理系统的设计思路、数据库要点、后端事务控制、前端权限对接、部署避坑一次讲透。适合正在做这类毕设的同学、刚接手中小型进销存项目的开发以及想了解药品采购业务怎么建模的产品新人。1. 需求拆解与整体方案选型1.1 药房采购管理到底在管什么药房采购不像普通商品采购那么简单牵扯到批次、效期、供应商资质、验收、库存周转这些环节。名为“集中管理”核心是把分散在各门店、各柜组的采购需求汇总到一个平台由专人统一比价、统一下单、统一入库避免重复采购和资源浪费。围绕这一目标系统必须覆盖五个关键环节需求来源各业务单元提交采购申请系统根据当前库存和预警阈值自动提示补货。供应商管理维护供应商名录、证件、联系人、历史报价采购单从名录中选择。采购执行申请审核通过后生成采购订单跟踪订单状态到货后做验收入库。库存联动入库即增库存出库即减库存库存变动同时生成流水。数据统计支持按月、按供应商、按药品统计采购金额和入库量给管理层做决策。这套业务模型决定了系统的技术形态SSMSpring Spring MVC MyBatis负责后端业务逻辑与数据处理Vue负责前端交互与数据展示MySQL作为持久层库。选SSM而不是Spring Boot一个原因是这套课题的经典组合教学资源和参考代码多遇到问题好查另一个原因是SSM对事务控制和SQL级别优化更直观适合把底层逻辑吃透。如果将来想迁移到Spring Boot改动成本也不高Mapper和Service层基本可以平迁。1.2 角色权限与模块划分角色设计是这类系统的基础我最终确定了五种系统管理员、采购员、库管员、审核人和普通业务人员如门店店长。每个角色对应不同的菜单和操作权限具体模块划分如下模块主要功能参与角色系统管理用户管理、角色管理、菜单管理、日志管理员基础资料药品信息维护、供应商信息维护管理员、采购员采购管理申请单、采购单、订单审核、收货验收采购员、审核人、库管员库存管理库存查询、入库记录、出库记录、预警查询库管员、采购员报表统计采购金额汇总、供应商供货统计、药品入库统计管理员、采购员模块与角色分离后前端可以根据登录用户返回的角色列表动态渲染菜单后端再基于拦截器校验接口权限双重控制。后面在权限对接部分我会详细讲实现方式。1.3 为什么选择前后端分离这里选Vue SSM做前后端分离不是因为“流行”而是业务本身就有这个诉求。采购单审核、库存预警、多条件查询这些页面交互比较密集用传统JSP模板引擎写起来很痛苦尤其是列表筛选和联动展示。Vue的双向数据绑定和组件化机制在这种场景下效率高很多。分离后后端只需提供规范的REST接口前端负责渲染和数据交互两边可以并行开发。接口用JSON格式传递统一返回结构为code、msg、data前端根据code判断业务状态。这套设计方案在实际开发中算是最稳妥的组合之一。2. 数据库设计与核心表结构2.1 药品信息表和供应商表数据库设计是整个系统的地基。药品信息这块字段设计得是否合理直接决定后续库存和采购模块好不好写。我的药品信息表核心字段如下字段类型说明idbigint主键drug_codevarchar(50)药品编码唯一索引drug_namevarchar(100)药品通用名specificationvarchar(100)规格如“10mg*20片”dosage_formvarchar(30)剂型manufacturervarchar(100)生产厂家approval_novarchar(50)批准文号shelf_life_daysint保质期天数用于效期预警warning_stockint库存预警阈值statustinyint1启用0停用药品编码建议做主数据的唯一标识自动化脚本导入Excel时也以编码为准避免录入重复药品。批准文号是药品合法性的关键信息虽然不参与业务流程计算但查询和报表会用到要留够长度。供应商表相对简单但三个字段不能少供应商编码、名称、状态。另外我加了联系人、联系电话、经营许可证号、结算账期。结算账期这个字段很多初做系统的人会漏实际业务中做采购订单时如果不记录账期后续财务对账会非常麻烦。2.2 采购订单的状态机设计采购订单是整个采购流程的核心载体。我定义的状态流转如下0待审核 —— 申请单提交后进入1已审核 —— 审核通过等待下单2已下单 —— 已发送至供应商3部分到货 —— 供应商分批送货已验收入库一部分4已完成 —— 全部到货入库5已取消 —— 审核不通过或人工取消这里最关键的是“部分到货”这个状态。实际业务中供应商分批送很常见如果只设计“已完成/未完成”两个状态部分到货时根本没法定级。每次验收记录都要更新订单的累计到货数量如果累计到货数量等于订单总数量就把状态置为已完成小于总数量则置为部分到货。采购单号建议设计为PO年月日三位流水号例如PO20250415001编排有规则后查询和Excel导出时来判断器更容易处理。订单明细表需要记录采购数量、实收数量、单价、金额。金额这里必须用DECIMAL(12,2)不能用double这是很多人容易忽略的点。double在MySQL和Java之间做计算时经常出现精度丢失比如0.1 0.2这种经典问题。2.3 建表SQL示例下面给出核心的采购订单表结构实际开发时可以直接复用调整CREATE TABLE procurement_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(30) NOT NULL, supplier_id BIGINT NOT NULL, total_amount DECIMAL(12,2) NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0, apply_user_id BIGINT, audit_user_id BIGINT, apply_time DATETIME, audit_time DATETIME, received_flag TINYINT DEFAULT 0, remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;配套的订单明细表CREATE TABLE procurement_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, drug_id BIGINT NOT NULL, plan_quantity INT NOT NULL DEFAULT 0, actual_quantity INT NOT NULL DEFAULT 0, unit_price DECIMAL(12,2), total_price DECIMAL(12,2) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;明细表的plan_quantity和actual_quantity分开就是为了支撑“部分到货”的状态判断。每次入库时根据实际验收数量更新actual_quantity然后汇总该order_id下的所有明细判断实收总数是否等于计划总数。库存表则建议单独建与药品表做关联记录药品编码、批号、效期、当前数量、所在仓位。批号和效期必须独立存储因为同一药品允许存在多个批次不同批次效期不同入库时药品批号不能混。3. 后端核心流程与SSM分层实现3.1 Controller、Service、Mapper三层架构SSM项目的分层规范很明确职责划分必须清晰。Controller层只负责接收参数和返回结果Service层承载业务逻辑Mapper层直接与数据库交互。我在项目中严格遵循这个约定举一个采购申请提交的接口示例RestController RequestMapping(/api/purchase) public class PurchaseController { Autowired private PurchaseService purchaseService; PostMapping(/apply) public Result submitApply(RequestBody Validated PurchaseApplyVO vo, HttpServletRequest request) { Long userId currentUserId(request); purchaseService.submitPurchaseApply(vo, userId); return Result.success(); } }看到没有Controller里没有写任何业务判断只是拿到了当前用户ID然后调Service。为什么要把当前用户放在Controller层处理因为拦截器已经完成了登录态解析从request里获取userId最合适。Service层内部要做的事情包括校验药品状态、判断申请数量是否合理、汇总申请总额、生成紧急采购标记、保存主单和明细。3.2 采购申请与审核的完整链路提交采购申请时Service层逻辑可以拆成四步校验提交的明细列表非空所有药品ID存在且状态为启用。逐条计算申请金额并累加totalAmount。生成申请单号保存procurement_plan表。批量保存申请明细到procurement_plan_item表。这里有一个需要设计的地方是否要直接生成采购订单我的做法是“先申请、后审核、再转单”。前段申请阶段不需要直接生成采购单号等审核通过后再把申请单转换成采购订单。这样可以避免审核不通过时产生无效订单也方便记录驳回原因。审核接口是权限敏感操作必须确认当前用户拥有审核角色。这里可以用简单的角色判断也可以用Spring AOP做自定义注解。项目初期用注解方式更省事Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }在Controller上加注解通过自定义拦截器读取注解值比对当前用户角色权限集合。这样做比在每个方法内部硬编码角色判断要优雅很多也方便后续扩展权限点。3.3 MyBatis动态SQL查询的实用写法列表查询是这个系统使用频率最高的接口。供应商查采购单、按状态查订单、按时间范围查流水这些条件组合起来字段非常多。MyBatis的动态SQL是处理这种场景的利器。以采购订单多条件查询为例select idselectOrderList resultTypemap SELECT o.id, o.order_no, o.total_amount, o.status, s.supplier_name, u1.user_name AS apply_name FROM procurement_order o LEFT JOIN supplier_info s ON o.supplier_id s.id LEFT JOIN sys_user u1 ON o.apply_user_id u1.id where if testorderNo ! null and orderNo ! AND o.order_no LIKE CONCAT(%, #{orderNo}, %) /if if testsupplierId ! null AND o.supplier_id #{supplierId} /if if teststatus ! null AND o.status #{status} /if if teststartTime ! null AND o.apply_time gt; #{startTime} /if if testendTime ! null AND o.apply_time lt; #{endTime} /if /where ORDER BY o.create_time DESC /select使用where标签而不是手动拼接“WHERE 11”MyBatis会自动处理首个子句前的AND避免SQL语法错误。时间范围查询时注意apply_time是datetime类型如果前端传的是“2025-04-15”endTime直接用“2025-04-15”会导致当天数据查不出来因为“2025-04-15 10:00:00”大于“2025-04-15”。解决方式是后端做时间左闭右开处理endTime自动加一天或者条件改为“小于等于次日零点”。LEFT JOIN关联供应商表和用户表在这里是必要的因为列表页需要展示这两列信息拼接成map返回比逐条调用单查接口效率高太多。3.4 事务控制与并发场景处理入库操作是系统中最需要严谨对待的地方。验收完成后库存表要增加数量流水表要插入记录订单明细表要更新实收数量订单表要更新到货状态。这四件事必须在同一个事务里完成任何一步失败都要全部回滚。Transactional(rollbackFor Exception.class) public void stockIn(StockInVO vo, Long userId) { int count stockMapper.checkBatchExist(vo.getDrugId(), vo.getBatchNo()); if (count 0) { stockMapper.increaseStock(vo.getDrugId(), vo.getBatchNo(), vo.getQuantity()); } else { stockMapper.insertBatchStock(vo); } stockRecordMapper.insertRecord(vo, userId); orderMapper.updateActualQuantity(vo.getOrderId(), vo.getDrugId(), vo.getQuantity()); orderMapper.updateReceivedStatus(vo.getOrderId()); }这里必须注意先更新库存再插入流水这个顺序不能反。插入流水时如果失败事务回滚会把库存增加也撤销掉两条数据保持一致。库存扣减的并发问题也要提前想清楚。如果两个用户同时针对同一药品做入库操作默认情况下MySQL的InnoDB引擎在默认隔离级别下UPDATE语句会对命中行加锁同一时间只有一个事务能更新。这里利用数据库行锁天然解决了并发问题不需要额外加分布式锁。但如果是先查询库存再判断是否充足再扣减需要在查询时加FOR UPDATESELECT quantity FROM stock_info WHERE drug_id #{drugId} AND batch_no #{batchNo} FOR UPDATE明确告诉数据库锁定这行数据直到事务结束。防止两个请求同时查到库存为1各自扣减1最后库存变成-1。药品库存是负数这个在业务上是严重事故宁可让操作失败返回“库存不足”也不能静默扣成负数。4. Vue前端实现与接口对接4.1 登录态管理与Axios统一封装前端部分我用的技术栈是Vue 2 Vuex Element UI。登录逻辑很简单用户输入账号密码后端校验通过后返回token和用户信息。token存放在localStorage里每次请求通过请求拦截器自动携带。service.interceptors.request.use(config { const token window.localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config })响应拦截器做统一错误处理如果后端返回code为401说明token失效或未登录直接跳转到登录页面并清除本地存储。网络错误、服务器异常这些情况统一弹出提示。这样做的目的是把通用逻辑收敛在拦截器里业务页面不需要重复写页面跳转和错误提示每个接口只要处理业务数据本身。4.2 动态菜单与按钮级权限控制菜单是根据后端返回的角色路由数组动态生成的核心思路是前端只维护路由映射表实际可访问的菜单由后端返回的权限点决定。登录成功后请求接口获取当前用户的权限点集合前端遍历路由表做过滤过滤后注入vue-router再渲染侧边栏菜单。按钮级权限通过自定义指令实现例如只有具备“PO_AUDIT”权限点的人才显示审核按钮Vue.directive(permission, { inserted(el, binding) { const code binding.value const points store.getters.permissionPoints if (!points.includes(code)) { el.parentNode.removeChild(el) } } })这种做法在页面中只需要写一行指令标签就能控制按钮显隐。不过要注意按钮权限只做前端展示控制后端接口的权限校验才是真正的安全边界。前端隐藏按钮只是提升体验如果用户直接调接口后端拦截器必须再拦一道这点不能省。4.3 采购订单页面的数据交互采购订单页面是前端交互复杂度最高的地方。创建采购单时需要实现的功能包括选择供应商、商品模糊搜索并自动补全、列表行内修改数量、动态计算合计金额、提交前确认校验。药品搜索这里我建议做成远程搜索模式输入关键词后从后端接口拉匹配结果而不是把所有药品全量加载到前端。全量加载数据量大的时候页面直接卡死而且浪费内存。handleSearch(query) { if (query.length 1) { searchDrugs(query).then(res { this.drugOptions res.data }) } }提交前校验包括至少有一行明细、每行数量大于0、供应商必选。因为后端也会校验前端校验更多是为了及时反馈降低用户操作错误率。审核页面则直接展示当前待审核订单列表点击详情进入只读模式审核通过或驳回时填写审核意见这些操作对应的接口都是权限点保护的。5. 部署与开发中的常见问题排查5.1 环境搭建与打包流程开发环境建议JDK 1.8 Maven 3.6 Tomcat 8.5 MySQL 5.7 Node 14。后端打包用mvn clean package生成的war包扔到Tomcat webapps目录下启动即可。前端在项目根目录执行npm install再执行npm run build生成dist目录。部署时最省事的方式是把dist里的静态资源放到Tomcat的webapps/ROOT下这样前后端同域名访问不会产生跨域问题。数据库初始化要注意字符集。建库语句建议写成CREATE DATABASE pharmacy_db DEFAULT CHARACTER SET utf8mb4否则中文数据写入报错或变成乱码。如果已经建了库记得检查my.ini里default-character-set和character-set-server配置确保整个链路都是utf8mb4。5.2 经典Bug实录精度、跨域与404开发过程中踩过的坑不少挑几个有代表性的记录一下。第一个是金额精度。初期在订单明细的单价字段选了double算合计的时候发现99.99 0.01有时候等于100.0有时候等于100.00000000000001。这问题在报表汇总时被放大对账差出几分钱。最后统一改成BigDecimal数据库字段同步改成DECIMAL(12,2)。Java后端所有金额类型都用BigDecimal传参不要用double接JSON解析。第二个是跨域。开发阶段前端跑在8080后端跑在8081axios请求直接抱跨域错误。我选择配置后端全局CORS解决在SpringMVC配置类里加CorsRegistry允许指定来源访问。生产部署后前后端同域名就不存在这个问题但如果以后前端单独部署到Nginx还是需要反向代理配置解决跨域。第三个是vue-router的history模式刷新404。开发时用了history模式一切正常部署到Tomcat后用户F5刷新页面直接报404。原因在于前端路由是JS控制的服务器没有对应的物理路径。最终的解决办法是前端路由改成hash模式或者在后端加一个重写规则把所有请求转发到index.html。如果没有运维权限用hash模式最省心代价是URL中多一个#号对系统使用几乎没有影响。第四个是MyBatis里使用order by排序字段时如果字段名从前端传来直接拼接会产生SQL注入风险。虽然排序字段通常不在预编译参数范围内但安全起见要做白名单校验只允许传入预先定义的排序字段集合。5.3 功能自测清单系统开发完成后的自测建议按业务链路逐条走。我列一个自测时的核心清单新增供应商提交后列表能否立即刷新显示提交采购申请后库存预警是否联动变化审核驳回后申请单状态能否被申请发起人看到采购订单部分到货时状态是否为部分到货库存扣减到0后再次出库是否被拦截并提示库存不足停用药品后采购申请选品时是否被过滤掉删除供应商时如果该供应商已有历史采购单是否做了删除保护第7条是很多人容易疏忽的。供应商与采购订单存在外键关联如果强制删除供应商采购订单的数据会丢失或出错。我在供应商删除接口里增加了检测逻辑如果该供应商存在未完成订单则提示“该供应商存在进行中的采购单不允许删除”只有全部订单终结后才允许物理删除或者统一使用状态字段做停用。还有一个值得注意的点是出库流水与库存扣减的顺序。这里和入库类似先扣库存再插流水两个操作在同一事务内。若流水插入失败则回滚不会导致库存扣了但查不到记录的情况。曾经遇到过一种情况出库扣减了库存但流水数据缺失最终报表统计出来的出库总数和库存变化对不上排查了很久才定位到是事务漏配了Service方法上没有加Transactional导致扣库存提交成功而插流水失败时没有回滚。6. 项目复盘与扩展方向6.1 开发顺序与工作量分配这个项目开发顺序的建议是先做基础资料管理再做采购申请和采购订单再做库存管理最后做报表统计和系统管理。为什么这个顺序因为采购申请依赖药品和供应商数据库存入库依赖采购订单报表统计依赖前面所有模块产生的数据。基础资料模块是地基地基不稳后面的模块全得返工。我第一轮就是把顺序搞反了先做订单后做基础资料调试订单时没有真实药品数据只能不停造垃圾数据验证逻辑十分痛苦。模块开发的预估工作量可以做如下参考模块后端接口数前端页面数系统管理186基础资料124采购管理168库存管理105报表统计63合计后端接口62个左右前端页面26个左右。一个人从环境搭建到功能自测每天有效编码6小时这个工作量大约需要三到四周。每天笔误和调整也占了大量时间如果时间紧张报表统计部分可以只做TOP10排行和月度汇总不要为了报表的完整性去做大量不必要的复杂图表交互。6.2 技术上可继续深挖的方向这个系统做扎实之后有几个方向可以继续扩展。第一个是Spring Boot迁移。SSM项目切到Spring Boot的成本其实不高Controller和Mapper基本不用动依赖管理和自动配置的调整值得做一次省掉大量xml配置。如果团队已经有Spring Boot基座建议直接在新项目中用Boot起步SSM的代码作为兼容层保留。第二个是采购审批流程的可视化配置。当前审批是固定角色审核如果组织架构调整或新增审批层级必须改代码。引入工作流引擎如Flowable或Activiti审批链路变成数据库配置业务变化不用发版。考虑到药品采购涉及的金额和合规性要求审批流设计成多级是合理的方向但复杂度会成倍上升要根据实际需求判断是否必要。第三个是数据报表的可视化升级。目前报表输出以表格为主如果接入ECharts做采购趋势图、供应商份额饼图、库存周转率趋势图管理层的数据感知会直观很多。前端页面把图表数据接口单独拆出来后端提供按月聚合的查询逻辑按供应商分组统计金额这一步并不复杂但对整体项目观感提升很大。第四个是移动端扫码入库。采购到货后库管员用手机扫描药品监管码或订单二维码自动匹配采购单明细、显示待收数量提交后完成入库。这个场景能明显提升验收效率技术上也相对成熟主要是PWA或小程序配合后端的扫码接口解析。如果有硬件扫码枪或手机摄像头属于低成本高体验的功能加分项。6.3 经验心得说点实际的。这类系统最难的不是某个技术点而是业务状态的一致性。一个采购单从申请到完成跨越了差不多六种状态、四张表的更新操作每一步都要考虑失败的回滚和状态的可回溯性。我在开发中途深刻理解了为什么要用事务为什么要记录流水。流水表本质上就是系统的一言一行录任何一次库存变化都能追溯到是哪个订单、哪个用户、什么时间操作的出了问题才能定位到根因。数据库设计阶段多花时间想清楚表和字段后面的编码和改bug时间才会少。如果当初能把“部分到货”这个状态设计提前想明白订单明细表和入库逻辑就不需要重做一遍省下的时间远比设计时多花的时间更值。最后再说一个小细节所有的金额展示前端格式化统一用toFixed(2)后端返回的JSON金额字段统一用字符串类型。避免BigDecimal在前端被JS自动转成Number导致大数精度丢失。这个问题隐藏得很深测试如果只输入小金额数据根本发现不了但金额到万级、亿级时就会明显异常。做药品采购系统金额的准确性永远是第一位的。

药房药品采购集中管理系统：设计、事务与权限实战

相关推荐

固定效应模型斜率异质性检验：xthbtest命令实操指南

C++ STL关联容器set map multimap底层原理与实战指南

Linux cat命令完全指南：原理、实战与避坑

更多资讯

磁盘未分配数据恢复，分区消失文件这样找回

GEO信任机制：企业内容如何通过大模型权威审核

传统SEO退场后，企业数字资产的GEO价值分化

第五篇：Keepalived + LVS 四层负载均衡高可用实战：DR 模式全流程

第六篇：Keepalived 脑裂专题：成因、危害与防脑裂实战（含检测脚本）

CentOS下源码编译安装高版本Python：依赖准备与环境配置全指南

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？