摘 要
随着企业仓储管理日益复杂,传统人工记录方式难以满足库存透明化与多角色协同的需求。为此,本文设计并实现了一套基于SpringBoot与Vue框架的仓库管理系统。系统旨在解决采购、销售、仓管与管理员之间信息不同步、审批流程不规范等问题,提升库存周转效率与业务可追溯性。
系统采用前后端分离架构,后端基于SpringBoot框架提供RESTful接口,前端使用Vue框架构建用户界面,数据库选用MySQL存储业务数据。围绕管理员、采购用户、销售用户、仓管用户四类角色,系统实现了后台首页多维度数据统计、库存预警与处理、采购申请与审核、销售订单录入与审核、到货入库与销售出库操作等核心功能模块。通过统一的订单状态流转与库存增减逻辑,确保业务流程闭环可追溯。
实际应用表明,该系统能够有效规范企业出入库流程,实现库存数据的实时同步与预警提醒,减少人工差错,提升多角色协同效率。
关键词:仓库管理系统;SpringBoot;Vue;库存预警;订单审批
ABSTRACT
With the increasing complexity of enterprise warehouse management, traditional manual recording methods are unable to meet the needs of inventory transparency and multi role collaboration. Therefore, this article designs and implements a repository management system based onSpringBootand Vue frameworks. The system aims to solve problems such as information synchronization and non-standard approval processes between procurement, sales, warehouse management, and administrators, and improve inventory turnover efficiency and business traceability.
The system adopts a front-end and back-end separation architecture, with the back-end providing RESTful interfaces based on theSpringBootframework, the front-end using the Vue framework to build user interfaces, and the database using MySQL to store business data. The system has implemented core functional modules such as multi-dimensional data statistics, inventory warning and processing, procurement application and review, sales order entry and review, and arrival and sales outbound operations on the backend homepage, focusing on four roles: administrator, procurement user, sales user, and warehouse user. By implementing a unified order status flow and inventory increase/decrease logic, ensure the traceability of the business process loop.
Practical application has shown that the system can effectively standardize the process of enterprise inventory management, achieve real-time synchronization and warning reminders of inventory data, reduce manual errors, and improve the efficiency of multi role collaboration.
Keywords:Warehouse Management System;SpringBoot;Vue;Inventory warning; order approval
目录
摘 要
ABSTRACT
第一章 绪论
1.1 研究背景和意义
1.1.1 研究背景
1.1.2 研究意义
1.2 研究现状
1.2.1 国外现状
1.2.2 国内现状
1.2.3 国内外小结
1.3 相关技术简介
1.3.1 Spring Boot框架
1.3.2 Vue框架
1.3.3 Java语言
1.3.4 MySQL数据库
1.4 论文结构
第二章 系统分析
2.1 系统概述
2.2 功能需求
2.2.1 用例模型
2.2.2 用例描述
2.3 非功能需求
2.3.1 性能需求
2.3.2 安全性需求
2.3.3 可靠性与可用性需求
2.3.4 可扩展性与可维护性需求
2.3.5 用户体验需求
第三章 系统设计
3.1 软件架构设计
3.1.1 架构设计目标
3.1.2 软件架构
3.2 功能模块设计
3.3 系统流程设计
3.3.1 采购申请与审核流程
3.3.2 销售订单录入与审核流程
3.3.3 采购入库操作流程
3.3.4 销售出库操作流程
3.3.5 库存预警与处理流程
3.4 数据库设计
3.4.1 实体ER图
3.4.2 数据库表设计
第四章 系统实现
4.1 用户登录实现
4.2 管理员功能实现
4.2.1 用户管理实现
4.2.2 仓库信息管理实现
4.2.3 采购订单审核实现
4.2.4 销售订单审核实现
4.3 采购用户功能实现
4.3.1 采购申请实现
4.3.2 库存预警查看实现
4.4 销售用户功能实现
4.4.1 销售订单录入实现
4.4.2 销售订单记录查看实现
4.5 仓管用户功能实现
4.5.1 到货入库实现
4.5.2 销售出库实现
第五章 系统测试
5.1 系统测试概述
5.2 测试用例设计
5.3 测试结果
第六章 结论与展望
参考文献
附录
致谢
第一章绪论
1.1 研究背景和意义
1.1.1 研究背景
近年来,中小型制造企业与贸易公司的业务规模逐步扩大,产品种类和订单数量持续增加,但许多企业的仓库管理仍然依赖表格工具甚至纸质单据。采购部门无法实时掌握库存余量,往往凭经验提采购计划,容易出现断货或积压[1]。销售部门接到客户订单后,需要反复向仓管确认库存,响应速度慢,客户满意度受到影响。仓管人员入库出库登记随意,账实不符的情况时有发生,月底盘点耗时费力。更关键的是,采购、销售、仓管、管理层四个岗位之间缺乏统一的信息平台,订单审批靠口头传达或零星消息,流程不透明,出了问题难以追溯[2]。市面上已有的仓库管理软件,有些功能过于通用,与企业实际业务场景匹配度不高;有些则需要长期付费,对预算有限的中小企业来说是一笔不小的开支。与此同时,员工对操作便捷性也有要求,系统界面应当简洁直观,能够在不同设备上稳定使用[3]。基于上述现实问题,开发一套贴合中小企业实际业务流程、覆盖采购审批、销售审核、库存预警及出入库操作等核心环节的仓库管理系统,具有明确的现实需求背景。
1.1.2 研究意义
系统的研究意义主要体现在以下几个方面。第一,提升信息透明度。将采购订单、销售订单、库存数量、入库出库记录全部纳入系统管理,各岗位人员可以在权限范围内实时查看所需数据,减少跨部门沟通成本,避免信息不对称导致的业务差错。第二,规范业务流程。采购申请需要管理员审核才能生效,销售订单需要审核才能进入出库环节,仓管入库出库必须关联已有订单,每一步操作都有明确的前置条件和状态流转,使企业仓储管理有章可循。第三,降低库存风险。系统自动监测库存数量,当产品库存低于设定阈值时及时向相关人员发出预警,帮助采购用户及时补货,避免因断货影响生产或销售。第四,便于追溯与审计。系统记录每一条数据的创建人、创建时间、最近更新时间,关键操作留有日志,出现问题时可以快速定位责任环节。对于中小型企业而言,这套系统能够在不大幅增加硬件和人力投入的前提下,有效改善仓库管理现状,为后续业务扩张打下基础。
1.2 研究现状
1.2.1 国外现状
国外仓储管理系统的发展始于20世纪后半叶,经历了从纸质记录到条码、再到无线射频和云计算的多次迭代。如今,头部企业如曼哈顿联合软件、蓝色巨人、SAP等,其产品已深度集成人工智能与物联网技术。曼哈顿联合软件推出的主动式仓库解决方案,能够通过机器学习预测每个订单的最佳拣货路径和波次计划。亚马逊机器人(前身为Kiva Systems)的货架到人模式,让仓储中心摆脱了对长距离步行通道的依赖,员工只需在固定工位等待机器人搬运货架,这一模式已成为行业效率标杆[4]。
对于中小企业市场,美国Fishbowl Inventory和德国Lagerverwaltung等轻量级产品提供了成本较低的替代方案。这些工具重点解决库存跟踪、循环盘点等核心痛点,避免了大型系统的复杂实施周期[5]。同时,海外仓储软件正普遍向云订阅模式转型,通过多租户架构让企业能够随时扩展存储规模[6]。总体而言,国外WMS正从单纯的工具向供应链执行中枢演变,通过算法优化减少对人的经验依赖,大型企业与中小企业在技术使用上的差距正在逐步缩小。
1.2.2 国内现状
国内仓储管理系统的普及速度在最近十年明显加快,但起点较低且发展不均衡。早期,除了少数外资制造企业,大部分国内公司长期依赖用友、金蝶等财务软件的库存模块,或者直接使用Excel进行管理。近些年,随着电子商务和直播带货的爆发,海量订单对发货时效提出了极高要求,倒逼行业进行技术升级[7]。
目前,国内市场主要形成了三类解决方案。第一类是大型云服务商的企业资源计划生态,其内置的仓储模块凭借品牌优势和集成能力,覆盖了大量中小型商贸企业[8]。第二类是专注于物流科技的本土厂商,如富勒科技、唯智信息,它们在鞋服、医药、冷链等垂直领域积累了丰富经验,擅长处理复杂的促销组合和多计量单位换算。第三类是针对小微企业的软件即服务产品,这些产品主打开箱即用和低成本[9]。
国内还有一个显著特点是智能化设备的快速渗透。极智嘉、快仓等本土机器人企业推出的潜伏式搬运机器人,已经在多家电商仓和制造业线边库得到实际应用。以京东亚洲一号为例,其大规模部署的自动分拣机和搬运机器人,配合定制化的仓库控制系统,实现了从入库到出库的高度自动化[10]。此外,国内企业尤其注重仓储数据与企业资源计划、制造执行系统等生产系统的打通,追求业财仓一体化,避免形成新的数据孤岛。
1.2.3 国内外小结
综上所述,国内外仓储管理系统均朝着智能化与自动化方向演进。国外侧重于算法驱动的流程优化和机器人技术的深度融合,以亚马逊等巨头的实践为代表;国内则更强调系统的快速落地与性价比,通过云服务模式降低中小企业使用门槛,同时在本土电商物流的倒逼下实现了自动化设备的规模化应用。两者共同推动了仓储管理从人工经验决策向数据智能决策的转变。
1.3 相关技术简介
1.3.1 Spring Boot框架
后端则采用了Spring Boot框架,它是由Pivotal团队推出的一套基于Spring框架的快速开发工具集,不仅可以简化Spring应用的初始搭建和开发过程,而且通过提供开箱即用的配置和自动化特性可以快速构建生产级的Java应用,这也显著降低了开发复杂度并提升了开发效率[11]。Spring Boot具有内置的服务器支持,简化了应用的部署和管理的同时还支持多种中间件的集成。在本系统中Spring Boot被用于构建后端RESTful风格的Web服务接口,以此实现前后端分离架构下的数据通信[12]。同时它还与Spring Security、Spring Data JPA等模块实现了集成,为系统的权限控制、数据持久化提供了有力支持。
1.3.2 Vue框架
Vue是一款轻量级、渐进式的前端JavaScript框架,具有组件化开发、用户友好数据绑定、虚拟DOM等特性,适用于构建用户界面[13]。在本系统中,Vue被用于构建前后端分离的前端页面,实现了各个功能模块之间的动态交互[14]。通过Vue Router实现页面跳转,Vue管理全局状态,Axios发送异步请求,系统前端具备良好的可维护性和用户体验。Vue的使用提升了开发效率,也使得系统具备更好的响应速度和交互体验[15]。
1.3.3 Java语言
Java是一门广泛应用于企业级应用开发的面向对象编程语言,具有平台无关性、安全性高、性能稳定等优点。本系统后端采用Java语言进行开发,结合Spring Boot框架快速构建服务模块,实现业务逻辑处理、数据持久化、接口调用等功能[16]。Java强大的生态系统和丰富的类库支持,使得系统在处理高并发请求、复杂业务逻辑时依然保持良好的性能和稳定性[17]。同时,Java在大型分布式系统中的广泛应用,也为本系统的后续扩展和维护提供了坚实的技术保障。
1.3.4 MySQL数据库
MySQL是一种开源的关系型数据库管理系统,以其稳定性强、性能优越、易于维护等特点广泛应用于各类Web系统中[18]。在本系统中,MySQL被用于存储用户信息等核心业务数据。系统通过MyBatis框架与数据库进行交互,实现高效的数据读写操作[19]。MySQL提供了事务管理、索引优化、主从复制等功能,为系统提供了可靠的数据存储与访问能力,保障了数据的一致性和完整性,是支撑本系统业务逻辑的重要基础[20]。
1.4 论文结构
本文共分为六个章节,结构安排如下:
第一章绪论:介绍系统的开发背景和研究意义,分析当前相关系统的发展现状及存在的问题,概述本文所采用的关键技术,并说明全文的组织结构。
第二章需求分析:对系统整体功能需求进行详细描述,包括采购用户、销售用户、仓管用户和管理员的功能模块,使用用例图和用例描述的方式展示系统交互流程,同时简要说明非功能性需求如性能、安全性等。
第三章系统设计:从软件架构出发,设计基于SpringBoot框架和Vue框架的整体结构;划分核心功能模块,并完成接口设计和数据库设计,包括ER图和关键数据表结构。
第四章系统实现:以用户管理模块为例,详细说明后端服务的构建与接口实现方式,展示各个页面的协作逻辑与具体代码实现思路。
第五章系统测试:介绍测试策略与方法,设计主要功能模块的测试用例,分析测试结果,评估系统的稳定性、可用性和性能表现。
第六章结论与展望:总结本系统的研究成果与技术实现价值,指出当前系统的不足之处,并对未来可能的扩展方向和技术优化提出建议。
第二章系统分析
2.1 系统概述
本文旨在构建一个集仓库库存管理、采购销售协同与多角色权限管控于一体的专业化仓库管理系统。系统主要涵盖库存数据可视化看板、多维度仓库信息管理、采购订单全流程审批、销售订单审核与出库、库存预警与智能提醒、客户与供应商信息维护等核心功能,致力于为企业提供高效、透明、可追溯的仓储运营解决方案。同时,系统构建了完善的采购用户、销售用户、仓管用户及管理员四类角色后台,支持采购用户发起采购申请与查看入库记录,支持销售用户录入销售订单与查看出库情况,支持仓管用户执行到货入库与销售出库操作,支持管理员对用户权限、仓库资源、操作日志及系统通知进行统一监管与分析,从而提升企业的库存周转效率与供应链协同能力。
系统采用前后端分离架构,前端使用Vue框架实现页面交互与数据可视化图表展示,后端基于SpringBoot框架开发,具备良好的可扩展性与高并发处理能力。通过模块化设计,系统实现了采购端、销售端、仓管端与管理端的低耦合运行,便于后期维护与功能拓展,适用于中小型制造企业、贸易公司及第三方仓储服务商的实际应用需求。
2.2 功能需求
系统的功能需求主要通过UML用例模型进行描述,涵盖了管理员、采购用户、销售用户和仓管用户四大核心角色,各角色权限分明,业务流程合理。
管理员主要包括:后台首页数据统计查看(仓库库存/产品采购/产品销售/采购入库/销售出库)、系统用户管理(添加采购用户/销售用户/仓管用户)、仓库信息管理(列表/添加/地图)、仓库库存管理、采购订单审核、销售订单审核、采购入库管理、销售出库管理、客户信息管理、供应商信息管理、操作日志查看、通知发布等用例。
采购用户主要包括:后台首页查看、仓库库存查看(库存预警)、采购订单申请与记录查看、采购入库情况查看、供应商信息查看等用例。
销售用户主要包括:后台首页查看、仓库库存查看(库存预警)、销售订单录入与记录查看、销售出库情况查看、客户信息查看等用例。
仓管用户主要包括:后台首页查看、仓库信息管理、仓库库存查看(库存预警)、采购订单查看、销售订单查看、到货入库操作、销售出库操作等用例。
2.2.1 用例模型
管理员拥有系统的最高权限,主要负责平台基础数据的维护与业务流程的审批。核心工作包括添加并管理系统用户(采购用户、销售用户、仓管用户),维护仓库基本信息(支持地图标注),审核采购用户发起的采购申请以及销售用户录入的销售订单。同时,管理员需监控全平台的运营数据,在后台首页查看仓库库存统计、产品采购统计、产品销售统计、采购入库统计及销售出库统计图表,并可查阅操作日志、发布系统通知。管理员用例图如图2-1所示。

图2-1管理员用例图
采购用户负责企业的物资采购工作。用户登录后可查看后台首页数据及仓库库存情况,当库存数量低于预警阈值(如小于10件)时系统将弹出提醒。采购用户可发起采购申请,填写产品、数量、供应商及订单合同等信息,提交后等待管理员审核。此外,采购用户可在采购入库管理中查看已入库的采购订单记录,在供应商信息管理中查询合作供应商资料。采购用户用例图如图2-2所示。

图2-2采购用户用例图
销售用户负责企业的产品销售工作。用户登录后可查看后台首页数据及仓库库存预警信息,为客户录入销售订单,填写产品、数量、客户及订单合同等信息,提交后等待管理员审核。销售用户可在销售出库管理中查看已完成出库的销售订单记录,在客户信息管理中查询客户资料。销售用户用例图如图2-3所示。

图2-3销售用户用例图
仓管用户负责仓库的实际出入库操作。用户登录后可维护仓库基本信息(仓库编号、名称、库位、照片、状态、地址等),查看仓库库存及预警信息。当采购订单通过管理员审核后,仓管用户可在采购入库管理中执行到货入库操作,确认入库数量与日期;当销售订单通过管理员审核后,仓管用户可在销售出库管理中执行销售出库操作。仓管用户还可查看采购订单和销售订单的详细信息。仓管用户用例图如图2-4所示。

图2-4仓管用户用例图
2.2.2 用例描述
(1)用户登录用例
用户登录用例描述如表2-1所示。
表2-1用户登录用例
| 简要描述 | 用户通过账号密码登录系统,系统根据角色跳转至对应首页 |
| 参与者 | 管理员、采购用户、销售用户、仓管用户 |
| 前置条件 | 用户已拥有合法账号(管理员/采购/销售/仓管) |
| 主业务流程 | 1. 用户访问登录页面;2. 输入账号和密码;3. 系统验证信息合法性;4. 系统识别用户角色;5. 登录成功跳转至对应角色的后台首页 |
| 扩展流程 | 1. 若账号不存在,提示“用户不存在”;2. 若密码错误,提示“密码错误”;3. 若账号被禁用,提示“账号已被禁用” |
| 后置条件 | 用户获得系统访问权限,可进入相应功能模块 |
(2)库存预警用例
库存预警用例描述如表2-2所示。
表2-2库存预警用例
| 简要描述 | 系统自动检测库存数量,当低于预警阈值时向用户弹窗提醒 |
| 参与者 | 采购用户、销售用户、仓管用户 |
| 前置条件 | 用户已登录系统,进入后台首页或库存管理页面 |
| 主业务流程 | 1. 系统实时监测各产品的库存数量;2. 若某产品库存数量大于0且小于10,触发预警;3. 系统弹窗提示“当前有数据达到预警值!库存数量大于0并且小于10的有X条,请尽快处理”;4. 用户点击“确定”关闭弹窗,或点击“取消”暂不处理 |
| 扩展流程 | 1. 若无库存预警数据,不弹出提醒;2. 预警列表支持点击查看具体产品明细 |
| 后置条件 | 用户可针对预警产品发起采购申请或调整库存 |
(3)采购申请与审核用例
采购申请与审核用例描述如表2-3所示。
表2-3采购申请与审核用例
| 简要描述 | 采购用户发起采购申请,管理员审核通过后生成待入库采购订单 |
| 参与者 | 采购用户、管理员 |
| 前置条件 | 采购用户已登录,且存在需要采购的产品(含库存预警产品) |
| 主业务流程 | 1. 采购用户进入“采购订单管理”,点击“采购申请”;2. 填写产品信息、采购数量、供应商信息、订单合同等;3. 提交申请,订单状态为“待审核”;4. 管理员在“采购订单管理”中查看待审核申请;5. 管理员审核,选择“通过”或“驳回”;6. 若通过,订单状态更新为“待入库”,仓管用户可看到该订单 |
| 扩展流程 | 1. 若采购数量小于等于0,提交失败;2. 若管理员驳回,采购用户可查看驳回原因并修改后重新提交 |
| 后置条件 | 审核通过的订单进入入库流程,库存将在入库后增加 |
(4)销售订单录入与审核用例
销售订单录入与审核用例描述如表2-4所示。
表2-4销售订单录入与审核用例
| 简要描述 | 销售用户为客户录入销售订单,管理员审核通过后生成待出库销售订单 |
| 参与者 | 销售用户、管理员 |
| 前置条件 | 销售用户已登录,且存在可销售的产品(库存充足) |
| 主业务流程 | 1. 销售用户进入“销售订单管理”,点击“录入销售订单”;2. 填写产品信息、销售数量、客户信息、订单合同等;3. 系统校验库存是否充足;4. 提交申请,订单状态为“待审核”;5. 管理员在“销售订单管理”中查看待审核订单;6. 管理员审核,选择“通过”或“驳回”;7. 若通过,订单状态更新为“待出库”,仓管用户可看到该订单 |
| 扩展流程 | 1. 若销售数量大于当前库存,提交失败并提示库存不足;2. 若管理员驳回,销售用户可查看驳回原因并修改后重新提交 |
| 后置条件 | 审核通过的订单进入出库流程,库存将在出库后减少 |
(5)采购入库用例
采购入库用例描述如表2-5所示。
表2-5采购入库用例
| 简要描述 | 商家维护自家商品信息,设置营销活动(优惠券),处理低库存预警 |
| 参与者 | 商家用户 |
| 前置条件 | 商家账号已通过管理员审核并登录 |
| 主业务流程 | 1. 商家进入“商品信息管理”,添加/编辑商品(名称、分类、多规格价格、库存);2. 系统监测库存,若低于阈值(如5件)弹出“库存提醒”;3. 商家进入“优惠券管理”,设置满减金额、有效期及适用商品;4. 商家执行商品上下架操作 |
| 扩展流程 | 1. 若商品必填项缺失,保存失败;2. 优惠券过期后自动失效 |
| 后置条件 | 前台商品信息与营销活动实时更新 |
(6)销售出库用例
销售出库用例描述如表2-6所示。
表2-6商家订单配送用例
| 简要描述 | 仓管用户对审核通过的销售订单执行销售出库操作,减少实际库存 |
| 参与者 | 仓管用户 |
| 前置条件 | 存在状态为“待出库”的销售订单,且库存充足 |
| 主业务流程 | 1. 仓管用户进入“销售出库管理”;2. 查看待出库的销售订单列表;3. 点击“出库”操作;4. 确认出库数量、选择出库日期;5. 填写出库备注;6. 提交出库,系统更新订单状态为“已完成”;7. 系统同步减少对应产品的库存数量 |
| 扩展流程 | 1. 若出库时发现库存不足,系统阻止出库并提示;2. 出库后若库存低于预警值,触发库存预警 |
| 后置条件 | 产品库存数量减少,销售订单流程结束 |
(7)仓库信息管理用例
仓库信息管理用例描述如表2-7所示。
表2-7仓库信息管理用例
| 简要描述 | 管理员和仓管用户维护仓库基本信息,支持地图标注仓库位置 |
| 参与者 | 管理员、仓管用户 |
| 前置条件 | 用户已登录且具有仓库管理权限 |
| 主业务流程 | 1. 用户进入“仓库信息管理”;2. 查看仓库信息列表(编号/名称/库位/照片/状态/备注/地址);3. 点击“添加”新增仓库,填写编号、名称、库位、状态、详细地址等信息,可上传仓库照片;4. 进入“仓库信息地图”,在地图上标注仓库位置;5. 对已有仓库进行编辑或删除操作 |
| 扩展流程 | 1. 若仓库编号已存在,添加时提示重复;2. 地图标注支持拖拽定位和地址搜索 |
| 后置条件 | 仓库信息更新,前台库存管理页面可关联新仓库 |
2.3 非功能需求
2.3.1 性能需求
系统应支持高并发访问,确保在多用户同时浏览及提交信息等操作时仍能保持良好的响应速度和稳定性。后端服务需具备良好的负载能力和处理效率,前端页面加载时间应控制在合理范围内。
2.3.2 安全性需求
系统需保障用户账户信息、交易数据的安全性。采用HTTPS协议进行数据传输加密,对用户密码进行加密存储,关键操作(如修改个人信息)需进行身份验证与权限控制,防止SQL注入、XSS攻击等常见安全风险。
2.3.3 可靠性与可用性需求
系统应具备较高的可用性,后端微服务需支持容错与自动恢复机制,如熔断、降级策略,避免单点故障影响整体服务。前端界面应具备良好的兼容性,适配不同浏览器与设备类型。
2.3.4 可扩展性与可维护性需求
系统架构设计应具备良好的扩展性,便于后续新增功能模块或对接第三方系统。代码结构清晰、模块划分合理,方便后期维护与升级。
2.3.5 用户体验需求
前端界面要求简洁美观、交互友好,操作流程直观易懂,提升用户的使用满意度。系统应提供必要的提示信息与反馈机制,减少用户操作失误。
第三章系统设计
3.1 软件架构设计
3.1.1 架构设计目标
系统的软件架构设计旨在满足多方面的非功能性需求,以确保系统的高效、稳定运行,为用户提供优质的服务体验。
(1)高稳定性与可用性。作为面向用户的系统需持续对外提供服务,避免因服务中断导致订单丢失或用户体验下降。因此,架构设计上采用微服务与分布式部署策略,结合服务注册与发现机制,确保各模块之间具备容错能力,整体系统应实现接近全天候运行,保障核心功能7×24小时稳定可用。
(2)高效响应性能。系统需在用户访问高峰期保持良好的响应速度,前端页面首次加载时间控制在3秒以内,关键操作如详情获取、信息提交等接口响应时间应低于1.5秒,以提升用户体验并增强平台竞争力。
(3)支持高并发访问。考虑到不同场景中可能出现的集中访问等情况,系统需具备应对突发流量的能力,设计目标为支持至少800个并发用户同时进行浏览、操作,且在压力下仍能维持基本功能的正常运转。
(4)良好的可扩展性与灵活性。随着业务发展,系统需要不断迭代更新,因此架构需支持模块化部署和横向扩展,便于后期新增功能模块或对接第三方服务,降低系统升级维护成本。
(5)安全可靠的数据处理能力。系统需保证交易数据、用户信息等敏感内容的安全性,采用加密传输、身份认证、权限控制等多重机制防范非法访问与数据泄露,同时数据库设计具备事务一致性与备份恢复机制,保障系统长期运行过程中的数据完整性与可靠性。
3.1.2 软件架构
系统采用前后端分离架构。前端基于Vue框架构建四类用户界面,通过路由拦截与API封装实现统一鉴权。后端基于SpringBoot框架,划分认证授权、业务处理、数据访问三层,核心覆盖用户管理、订单审核、库存操作及统计看板模块。数据层使用MyBatis操作MySQL数据库,部署运行于JDK与Tomcat环境。架构图如图3-1所示:

图3-1软件架构图
3.2 功能模块设计
系统基于角色权限划分为管理员、采购用户、销售用户和仓管用户四类核心用户。管理员端后台首页集成五大数据统计看板,功能覆盖系统用户管理、仓库信息管理、库存管理、订单审核、出入库管理、客户供应商管理、操作日志及通知发布。采购用户端以物资采购为核心,覆盖库存预警查看、采购申请提交与记录查看、入库情况及供应商信息查询。销售用户端以产品销售为核心,覆盖库存预警查看、销售订单录入与记录查看、出库情况及客户信息查询。仓管用户端以实物操作为核心,覆盖仓库信息维护、库存预警查看、订单查看及到货入库与销售出库操作。系统总体功能结构图如图3-2所示。

图3-2系统功能结构图
3.3 系统流程设计
3.3.1 采购申请与审核流程
采购用户登录系统后进入采购订单管理模块,点击“采购申请”填写产品信息、采购数量、供应商信息及订单合同等内容,提交后订单状态变更为“待审核”。管理员在后台查看待审核的采购申请,核对采购信息无误后点击“审核通过”,订单状态更新为“待入库”;若信息有误或采购数量异常,管理员可点击“驳回”并填写驳回原因,采购用户根据反馈修改后重新提交。审核通过的采购订单将推送至仓管用户端,仓管用户可看到待入库订单列表。采购申请与审核流程如图3-3所示。

图3-3采购申请与审核流程图
3.3.2 销售订单录入与审核流程
销售用户登录系统后进入销售订单管理模块,点击“录入销售订单”填写产品信息、销售数量、客户信息及订单合同等内容。系统实时校验当前库存是否满足销售数量需求,若库存不足则提示无法下单并拒绝提交;若库存充足,提交后订单状态变更为“待审核”。管理员在后台查看待审核的销售订单,核对客户信息及销售数量无误后点击“审核通过”,订单状态更新为“待出库”;若信息有误,管理员可驳回并要求修改。审核通过的销售订单将推送至仓管用户端。销售订单录入与审核流程如图3-4所示。

图3-4销售订单录入与审核流程图
3.3.3 采购入库操作流程
仓管用户登录系统后进入采购入库管理模块,查看状态为“待入库”的采购订单列表。点击“入库”操作后,系统展示订单详细信息(产品、采购数量、供应商等)。仓管用户确认实际到货数量(可修改为实收数量,系统自动记录差异),选择入库日期并填写入库备注,确认无误后提交入库。系统更新订单状态为“已完成”,同时自动增加对应产品的当前库存数量。若实收数量与订单数量差异较大,仓管用户需在备注中说明原因便于后续追溯。采购入库操作流程如图3-5所示。

图3-5采购入库操作流程图
3.3.4 销售出库操作流程
仓管用户登录系统后进入销售出库管理模块,查看状态为“待出库”的销售订单列表。点击“出库”操作后,系统展示订单详细信息(产品、销售数量、客户等)。仓管用户确认出库数量,选择出库日期并填写出库备注(如物流单号、承运商等),确认无误后提交出库。系统更新订单状态为“已完成”,同时自动减少对应产品的当前库存数量。若出库时发现实际库存不足,系统将阻止出库操作并提示仓管用户联系管理员或销售用户调整订单。销售出库操作流程如图3-6所示。

图3-6销售出库操作流程图
3.3.5 库存预警与处理流程
系统在用户登录后及库存管理页面加载时自动触发库存监测机制,遍历所有产品的当前库存数量。当某产品库存数量大于0且小于10时,系统判定为预警状态,向当前用户弹窗提示“当前有数据达到预警值!库存数量大于0并且小于10的有X条,请尽快处理”,并展示预警产品明细列表。用户点击“确定”关闭弹窗后可针对预警产品发起采购申请(采购用户)或通知相关人员补货。若用户忽略预警,系统在下次刷新页面时再次弹出提醒,直至库存得到补充或调整。库存预警与处理流程如图3-7所示。

图3-7库存预警与处理流程图
3.4 数据库设计
3.4.1 实体ER图
系统核心实体包括采购用户、销售用户、仓管用户、仓库库存、采购订单、销售订单、采购入库及销售出库。采购用户与采购订单为一对多关系,销售用户与销售订单为一对多关系,仓库库存分别与采购订单、销售订单关联。采购入库关联采购订单与仓管用户,销售出库关联销售订单与仓管用户,形成完整的采购销售与出入库闭环链路。系统软件中的E-R图如图3-8所示:

图3-8系统实体关系图
3.4.2 数据库表设计
数据库表设计是系统开发中的关键环节,它决定了数据的组织方式、存储结构以及各数据实体之间的关联关系。良好的表设计能够确保数据的一致性、完整性和可扩展性,提升系统的查询效率与维护便利性,为业务功能的稳定运行和后期扩展奠定坚实基础。
采购用户表用于存储采购人员基础信息,关联系统用户ID实现权限映射。设计重点在于记录工号、手机及审核状态,确保采购用户准入规范与操作可追溯,如表3-1所示。
表3-1procurement_user(采购用户)
| 1 | procurement_user_id | int | 是 | 是 | 采购用户ID | |
| 2 | purchase_name | varchar | 64 | 否 | 否 | 采购姓名 |
| 3 | procurement_work_number | varchar | 64 | 是 | 是 | 采购工号 |
| 4 | purchase_of_mobile_phones | varchar | 16 | 是 | 是 | 采购手机 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 6 | user_id | int | 是 | 否 | 用户ID | |
| 7 | create_time | datetime | 是 | 否 | 创建时间 | |
| 8 | create_by | int | 是 | 否 | 创建用户ID | |
| 9 | update_time | timestamp | 是 | 否 | 更新时间 |
采购订单表用于存储采购申请与订单全流程信息。设计重点在于关联采购用户、供应商及订单状态(待审核/待入库/已完成),并记录到货入库限制次数防止重复操作,如表3-2所示。
表3-2purchase_order(采购订单)
| 1 | purchase_order_id | int | 是 | 是 | 采购订单ID | |
| 2 | product_name | varchar | 64 | 否 | 否 | 产品名称 |
| 3 | product_number | varchar | 64 | 否 | 否 | 产品编号 |
| 4 | product_specifications | varchar | 64 | 否 | 否 | 产品规格 |
| 5 | purchase_price | double | 否 | 否 | 进货价格 | |
| 6 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 7 | purchase_quantity | double | 否 | 否 | 采购数量 | |
| 8 | purchase_amount | double | 否 | 否 | 采购金额 | |
| 9 | order_date | date | 否 | 否 | 下单日期 | |
| 10 | supplier_name | varchar | 64 | 否 | 否 | 供应商名称 |
| 11 | vendor_number | varchar | 64 | 否 | 否 | 供应商编号 |
| 12 | contact_name | varchar | 64 | 否 | 否 | 联系人名 |
| 13 | contact_phone | varchar | 64 | 否 | 否 | 联系手机 |
| 14 | order_contract | varchar | 255 | 否 | 否 | 订单合同 |
| 15 | procurement_user | int | 否 | 否 | 采购用户 | |
| 16 | purchase_name | varchar | 64 | 否 | 否 | 采购姓名 |
| 17 | procurement_work_number | varchar | 64 | 否 | 否 | 采购工号 |
| 18 | purchase_of_mobile_phones | varchar | 64 | 否 | 否 | 采购手机 |
| 19 | order_status | varchar | 64 | 否 | 否 | 订单状态 |
| 20 | order_remarks | text | 65535 | 否 | 否 | 订单备注 |
| 21 | purchase_receipt_limit_times | int | 是 | 否 | 到货入库限制次数 | |
| 22 | create_time | datetime | 是 | 否 | 创建时间 | |
| 23 | create_by | int | 是 | 否 | 创建用户ID | |
| 24 | update_time | timestamp | 是 | 否 | 更新时间 | |
| 25 | extra | text | 65535 | 否 | 否 | 额外信息 |
| 26 | source_table | varchar | 255 | 否 | 否 | 来源表 |
| 27 | source_id | int | 否 | 否 | 来源ID | |
| 28 | source_user_id | int | 否 | 否 | 来源用户 |
销售用户表用于存储销售人员基础信息,关联系统用户ID实现权限映射。设计重点在于记录工号、手机及审核状态,确保销售用户准入规范与操作可追溯,如表3-3所示。
表3-3sales_user(销售用户)
| 1 | sales_user_id | int | 是 | 是 | 销售用户ID | |
| 2 | sales_name | varchar | 64 | 否 | 否 | 销售姓名 |
| 3 | sales_worker_number | varchar | 64 | 是 | 是 | 销售工号 |
| 4 | selling_mobile_phones | varchar | 16 | 是 | 是 | 销售手机 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 6 | user_id | int | 是 | 否 | 用户ID | |
| 7 | create_time | datetime | 是 | 否 | 创建时间 | |
| 8 | create_by | int | 是 | 否 | 创建用户ID | |
| 9 | update_time | timestamp | 是 | 否 | 更新时间 |
销售订单表用于存储销售录入与订单全流程信息。设计重点在于关联销售用户、客户及订单状态(待审核/待出库/已完成),并记录销售出库限制次数防止重复操作,如表3-4所示。
表3-4sales_order(销售订单)
| 1 | sales_order_id | int | 是 | 是 | 销售订单ID | |
| 2 | product_name | varchar | 64 | 否 | 否 | 产品名称 |
| 3 | product_number | varchar | 64 | 否 | 否 | 产品编号 |
| 4 | product_specifications | varchar | 64 | 否 | 否 | 产品规格 |
| 5 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 6 | sales_unit_price | double | 否 | 否 | 销售单价 | |
| 7 | sales_quantity | double | 否 | 否 | 销售数量 | |
| 8 | order_amount | double | 否 | 否 | 订单金额 | |
| 9 | order_date | date | 否 | 否 | 下单日期 | |
| 10 | customer_name | varchar | 64 | 否 | 否 | 客户名称 |
| 11 | customer_number | varchar | 64 | 否 | 否 | 客户编号 |
| 12 | contact_name | varchar | 64 | 否 | 否 | 联系人名 |
| 13 | contact_phone | varchar | 64 | 否 | 否 | 联系手机 |
| 14 | order_contract | varchar | 255 | 否 | 否 | 订单合同 |
| 15 | sales_user | int | 否 | 否 | 销售用户 | |
| 16 | sales_name | varchar | 64 | 否 | 否 | 销售姓名 |
| 17 | selling_mobile_phones | varchar | 64 | 否 | 否 | 销售手机 |
| 18 | order_status | varchar | 64 | 否 | 否 | 订单状态 |
| 19 | order_remarks | text | 65535 | 否 | 否 | 订单备注 |
| 20 | sales_issue_limit_times | int | 是 | 否 | 销售出库限制次数 | |
| 21 | create_time | datetime | 是 | 否 | 创建时间 | |
| 22 | create_by | int | 是 | 否 | 创建用户ID | |
| 23 | update_time | timestamp | 是 | 否 | 更新时间 | |
| 24 | extra | text | 65535 | 否 | 否 | 额外信息 |
| 25 | source_table | varchar | 255 | 否 | 否 | 来源表 |
| 26 | source_id | int | 否 | 否 | 来源ID | |
| 27 | source_user_id | int | 否 | 否 | 来源用户 |
仓管用户表用于存储仓管人员基础信息,关联系统用户ID实现权限映射。设计重点在于记录工号、手机及审核状态,确保仓管用户准入规范与操作可追溯,如表3-5所示。
表3-5warehouse_users(仓管用户)
| 1 | warehouse_users_id | int | 是 | 是 | 仓管用户ID | |
| 2 | warehouse_name | varchar | 64 | 否 | 否 | 仓管姓名 |
| 3 | warehouse_keeper_number | varchar | 64 | 是 | 是 | 仓管工号 |
| 4 | warehouse_cell_phone | varchar | 16 | 是 | 是 | 仓管手机 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 6 | user_id | int | 是 | 否 | 用户ID | |
| 7 | create_time | datetime | 是 | 否 | 创建时间 | |
| 8 | create_by | int | 是 | 否 | 创建用户ID | |
| 9 | update_time | timestamp | 是 | 否 | 更新时间 |
仓库库存表用于存储各仓库的产品库存信息。设计重点在于关联仓库与产品,记录进货价格、库存数量及产品备注,并通过采购/销售限制次数字段控制订单并发操作,如表3-6所示。
表3-6warehouse_inventory(仓库库存)
| 1 | warehouse_inventory_id | int | 是 | 是 | 仓库库存ID | |
| 2 | warehouse_no | varchar | 64 | 否 | 否 | 仓库编号 |
| 3 | warehouse_name | varchar | 64 | 否 | 否 | 仓库名称 |
| 4 | product_name | varchar | 64 | 否 | 否 | 产品名称 |
| 5 | product_number | varchar | 64 | 是 | 是 | 产品编号 |
| 6 | product_specifications | varchar | 64 | 否 | 否 | 产品规格 |
| 7 | product_picture | varchar | 255 | 否 | 否 | 产品图片 |
| 8 | purchase_price | double | 否 | 否 | 进货价格 | |
| 9 | inventory_quantity | double | 否 | 否 | 库存数量 | |
| 10 | product_remarks | text | 65535 | 否 | 否 | 产品备注 |
| 11 | purchase_order_limit_times | int | 是 | 否 | 采购申请限制次数 | |
| 12 | sales_order_limit_times | int | 是 | 否 | 销售订单限制次数 | |
| 13 | create_time | datetime | 是 | 否 | 创建时间 | |
| 14 | create_by | int | 是 | 否 | 创建用户ID | |
| 15 | update_time | timestamp | 是 | 否 | 更新时间 |
采购入库表用于记录仓管执行的到货入库操作。设计重点在于关联采购订单、采购用户及仓管用户,记录入库日期与备注,确保入库过程可追溯,如表3-7所示。
表3-7purchase_receipt(采购入库)
| 1 | purchase_receipt_id | int | 是 | 是 | 采购入库ID | |
| 2 | product_name | varchar | 64 | 否 | 否 | 产品名称 |
| 3 | product_number | varchar | 64 | 否 | 否 | 产品编号 |
| 4 | product_specifications | varchar | 64 | 否 | 否 | 产品规格 |
| 5 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 6 | purchase_quantity | double | 否 | 否 | 采购数量 | |
| 7 | order_date | date | 否 | 否 | 下单日期 | |
| 8 | supplier_name | varchar | 64 | 否 | 否 | 供应商名称 |
| 9 | vendor_number | varchar | 64 | 否 | 否 | 供应商编号 |
| 10 | contact_name | varchar | 64 | 否 | 否 | 联系人名 |
| 11 | contact_phone | varchar | 64 | 否 | 否 | 联系手机 |
| 12 | procurement_user | int | 否 | 否 | 采购用户 | |
| 13 | purchase_name | varchar | 64 | 否 | 否 | 采购姓名 |
| 14 | procurement_work_number | varchar | 64 | 否 | 否 | 采购工号 |
| 15 | purchase_of_mobile_phones | varchar | 64 | 否 | 否 | 采购手机 |
| 16 | warehouse_users | int | 否 | 否 | 仓管用户 | |
| 17 | warehouse_name | varchar | 64 | 否 | 否 | 仓管姓名 |
| 18 | warehouse_keeper_number | varchar | 64 | 否 | 否 | 仓管工号 |
| 19 | warehouse_cell_phone | varchar | 64 | 否 | 否 | 仓管手机 |
| 20 | receipt_date | date | 否 | 否 | 入库日期 | |
| 21 | receipt_remarks | text | 65535 | 否 | 否 | 入库备注 |
| 22 | create_time | datetime | 是 | 否 | 创建时间 | |
| 23 | create_by | int | 是 | 否 | 创建用户ID | |
| 24 | update_time | timestamp | 是 | 否 | 更新时间 | |
| 25 | extra | text | 65535 | 否 | 否 | 额外信息 |
| 26 | source_table | varchar | 255 | 否 | 否 | 来源表 |
| 27 | source_id | int | 否 | 否 | 来源ID | |
| 28 | source_user_id | int | 否 | 否 | 来源用户 |
销售出库表用于记录仓管执行的销售出库操作。设计重点在于关联销售订单、销售用户及仓管用户,记录出库日期与备注,确保出库过程可追溯,如表3-8所示。
表3-8sales_issue(销售出库)
| 1 | sales_issue_id | int | 是 | 是 | 销售出库ID | |
| 2 | product_name | varchar | 64 | 否 | 否 | 产品名称 |
| 3 | product_number | varchar | 64 | 否 | 否 | 产品编号 |
| 4 | product_specifications | varchar | 64 | 否 | 否 | 产品规格 |
| 5 | order_number | varchar | 64 | 否 | 否 | 订单编号 |
| 6 | sales_quantity | double | 否 | 否 | 销售数量 | |
| 7 | order_date | date | 否 | 否 | 下单日期 | |
| 8 | customer_name | varchar | 64 | 否 | 否 | 客户名称 |
| 9 | customer_number | varchar | 64 | 否 | 否 | 客户编号 |
| 10 | contact_name | varchar | 64 | 否 | 否 | 联系人名 |
| 11 | contact_phone | varchar | 64 | 否 | 否 | 联系手机 |
| 12 | sales_user | int | 否 | 否 | 销售用户 | |
| 13 | sales_name | varchar | 64 | 否 | 否 | 销售姓名 |
| 14 | selling_mobile_phones | varchar | 64 | 否 | 否 | 销售手机 |
| 15 | warehouse_users | int | 否 | 否 | 仓管用户 | |
| 16 | warehouse_name | varchar | 64 | 否 | 否 | 仓管姓名 |
| 17 | warehouse_keeper_number | varchar | 64 | 否 | 否 | 仓管工号 |
| 18 | warehouse_cell_phone | varchar | 64 | 否 | 否 | 仓管手机 |
| 19 | issue_date | date | 否 | 否 | 出库日期 | |
| 20 | outbound_remarks | text | 65535 | 否 | 否 | 出库备注 |
| 21 | create_time | datetime | 是 | 否 | 创建时间 | |
| 22 | create_by | int | 是 | 否 | 创建用户ID | |
| 23 | update_time | timestamp | 是 | 否 | 更新时间 | |
| 24 | extra | text | 65535 | 否 | 否 | 额外信息 |
| 25 | source_table | varchar | 255 | 否 | 否 | 来源表 |
| 26 | source_id | int | 否 | 否 | 来源ID | |
| 27 | source_user_id | int | 否 | 否 | 来源用户 |
第四章系统实现
前端
4.1 用户登录实现
用户登录是系统入口,所有角色共用同一登录接口。前端通过import引入自定义axios实例,调用后端登录接口传递账号与密码。后端验证用户身份后返回JWT令牌及角色信息,前端将令牌存入localStorage并根据角色跳转至对应首页。若账号或密码错误,后端返回具体提示信息,前端弹窗提醒用户重新输入。用户登录界面图如图4-1所示。

图4-1用户登录页面
关键代码如下所示:
login(form) {
axios.post('/api/user/login', form).then(res => {
localStorage.setItem('token',res.data.token);
this.$router.push('/' +res.data.role+ '/home');
}).catch(() => alert('账号或密码错误'));
}
4.2 管理员功能实现
4.2.1 用户管理实现
管理员在用户管理页面可添加采购、销售、仓管三类用户。前端调用用户新增接口提交用户信息,后端校验工号与手机号唯一性后写入数据库。列表页支持按昵称、用户ID模糊查询,分页展示用户数据。删除操作需二次确认,后端软删除记录并保留日志。系统用户管理界面图如图4-2所示。

图4-2用户管理页面
关键代码如下所示:
@PostMapping("/user/add")
public ResultaddUser(@RequestBodyUserVovo) {
if(userService.existsByWorkNo(vo.getWorkNo()))
returnResult.error("工号已存在");
userService.insert(vo);
returnResult.success();
}
4.2.2 仓库信息管理实现
管理员可维护仓库基本信息并在地图标注位置。前端调用仓库列表接口获取数据并渲染表格,支持按仓库编号和名称搜索。添加仓库时需填写编号、名称、库位、状态及详细地址,支持上传仓库照片。编辑功能可修改已有仓库信息,地图模块集成第三方地图API,管理员可拖拽定位并保存坐标。仓库信息管理界面图如图4-3所示。

图4-3仓库信息管理页面
关键代码如下所示:
saveWarehouse() {
const{ id, code, name, address,lat,lng}=this.form;
axios.post('/api/warehouse/save',{ id, code, name, address,lat,lng})
.then(() =>this.$message.success('保存成功'));
}
4.2.3 采购订单审核实现
管理员在采购订单列表页查看状态为待审核的申请。前端通过接口获取订单详情,展示产品信息、采购数量及供应商资料。管理员点击通过或驳回时,后端更新订单状态并记录审核人及时间。驳回操作需填写原因,系统将原因回显至采购用户端。采购订单审核界面图如图4-4所示。

图4-4采购订单审核页面
关键代码如下所示:
@PutMapping("/purchase/audit")
public Resultaudit(@RequestBodyAuditDtodto) {
purchaseOrder.setStatus(dto.getStatus());
purchaseOrder.setAuditRemark(dto.getRemark());
purchaseOrder.updateById();
returnResult.success();
}
4.2.4 销售订单审核实现
管理员在销售订单列表页处理待审核的销售订单。前端调用订单详情接口展示客户信息、销售数量及产品规格。审核通过时后端更新订单状态为待出库,并正式扣减库存;审核驳回时需填写理由,前端将理由展示给销售用户。审核操作均记录操作日志便于追溯。销售订单审核界面图如图4-5所示。

图4-5销售订单审核页面
关键代码如下所示:
if("pass".equals(status)) {
order.setStatus("待出库");
stockService.deduct(order.getProductId(),order.getQuantity());
} else {
order.setStatus("已驳回");
}
4.3 采购用户功能实现
4.3.1 采购申请实现
采购用户在库存列表页可对任一产品发起采购申请。点击采购申请按钮后,前端弹出表单窗口,自动带出产品名称、编号及规格。用户填写采购数量、选择供应商并上传订单合同后提交。后端校验数量合法性并生成采购订单,状态默认为待审核。采购申请界面图如图4-6所示。

图4-6采购申请页面
关键代码如下所示:
submitApply() {
axios.post('/api/purchase/apply', {
productId: this.product.id,
quantity:this.form.quantity,
supplierId:this.form.supplierId
}).then(() =>this.$message.success('提交成功'));
}
4.3.2 库存预警查看实现
采购用户登录后台首页时,系统自动触发库存监测。前端调用预警接口获取库存大于0且小于10的产品列表,弹窗展示预警数量及明细。用户点击确定后可跳转至库存页面,针对预警产品快速发起采购申请。预警数据每次页面刷新均重新获取,确保信息实时准确。库存预警界面图如图4-7所示。

图4-7库存预警查看页面
关键代码如下所示:
checkWarning() {
axios.get('/api/stock/warning').then(res => {
if(res.data.length> 0)
this.$alert(有${res.data.length}种产品库存不足10件);
});
}
4.4 销售用户功能实现
4.4.1 销售订单录入实现
销售用户为客户录入销售订单时,需先选择产品。前端调用库存接口获取产品当前库存量,若销售数量超过库存则提示无法提交。用户填写客户信息、销售数量及订单合同后提交,后端生成销售订单并冻结对应库存数量,订单状态为待审核。销售订单录入界面图如图4-8所示。

图4-8销售订单录入页面
关键代码如下所示:
checkStock() {
axios.get(/api/stock/${this.productId}).then(res => {
if(this.quantity>res.data.stock)
this.$message.error('库存不足');
});
}
4.4.2 销售订单记录查看实现
销售用户可在订单列表页查看自己录入的所有销售订单。前端分页加载订单数据,支持按订单状态、下单日期筛选。每条订单展示产品名称、销售数量、客户名称及审核状态。审核被驳回的订单可点击修改重新提交,已出库的订单可查看出库日期和物流备注。销售订单记录界面图如图4-9所示。

图4-9销售订单记录查看页面
关键代码如下所示:
loadOrders() {
axios.get('/api/sales/order/list', {
params:{ page:this.page, status:this.status}
}).then(res =>this.orderList=res.data.records);
}
4.5 仓管用户功能实现
4.5.1 到货入库实现
仓管用户在采购入库管理页查看待入库订单列表。点击入库操作后,前端展示订单详情,仓管确认实收数量并填写入库备注。提交时后端校验数量合法性,更新订单状态为已完成,并同步增加对应产品的库存数量。若实收数量异常,系统记录差异便于追溯。到货入库界面图如图4-10所示。

图4-10到货入库页面
关键代码如下所示:
@PostMapping("/purchase/in")
public ResultinStock(@RequestBodyInStockDtodto) {
order.setStatus("已完成");
order.setActualQuantity(dto.getActualQuantity());
stockService.increase(dto.getProductId(),dto.getActualQuantity());
returnResult.success();
}
4.5.2 销售出库实现
仓管用户在销售出库管理页查看待出库订单列表。点击出库操作后,前端展示订单详情及客户信息。仓管确认出库数量、填写出库备注后提交,后端更新订单状态为已完成,并减少对应产品的库存数量。若出库时库存不足,系统阻止操作并提示仓管联系管理员。销售出库界面图如图4-11所示。

图4-11销售出库页面
关键代码如下所示:
if(stockService.getStock(dto.getProductId()) <dto.getQuantity()) {
returnResult.error("库存不足,无法出库");
}
stockService.decrease(dto.getProductId(),dto.getQuantity());
第五章系统测试
5.1 系统测试概述
本系统的测试环境与测试工具配置如下:
| 操作系统 | Windows 11 / macOS Ventura 13.0(开发端) |
| 开发语言 | Java |
| 开发框架 | 前端Vue.js框架,后端基于Spring Boot 框架 |
| 数据库 | MySQL 8.0,Redis 6.2 |
| 应用服务器 | Nginx作为静态资源服务器,后端微服务部署在Tomcat 9 + JDK 11 |
| 浏览器 | Chrome 112、Edge 110、Firefox 109 |
| 网络环境 | 局域网内进行本地测试,部署后通过公网IP或域名访问,使用 HTTPS 协议保障通信安全 |
测试过程中,使用到的测试工具包括:
功能测试工具:Postman用于接口调试与功能验证,JMeter辅助进行简单接口测试
自动化测试工具:Selenium实现前端页面操作的自动化测试,TestNG组织和管理测试用例
性能测试工具:Apache JMeter用于模拟高并发场景,测试系统在压力下的响应能力与稳定性
5.2 测试用例设计
在系统的测试阶段,为了验证系统主要业务功能的正确性与稳定性,对系统的关键模块进行了详细的测试用例设计。测试范围覆盖了管理员端、采购用户端、销售用户端及仓管用户端的核心业务流程,包括用户登录、采购申请与审核、销售订单录入与审核、到货入库及销售出库等模块。以下为部分核心功能模块的测试用例表格示例。
(1)用户登录模块测试用例
表5-1用户登录模块测试用例表
| TC001 | 管理员正常登录 | 管理员账号、正确密码 | 1. 打开登录页;2. 输入账号密码;3. 点击登录 | 跳转至管理员首页,显示后台统计看板 | 页面跳转正常,统计数据加载成功 | 通过 |
| TC002 | 采购用户正常登录 | 采购账号、正确密码 | 同上 | 跳转至采购首页,显示库存预警 | 页面跳转正常,预警弹窗正常触发 | 通过 |
| TC003 | 密码错误登录 | 任意账号、错误密码 | 同上 | 提示“用户名或密码错误” | 提示信息正确,停留在登录页 | 通过 |
| TC004 | 账号不存在登录 | 未注册账号、任意密码 | 同上 | 提示“用户名或密码错误” | 提示信息正确,未泄露账号是否存在 | 通过 |
(2)采购申请模块测试用例
本模块测试采购用户发起采购申请及系统校验逻辑的正确性。
表5-2采购申请模块测试用例表
| TC005 | 正常采购申请 | 产品ID、采购数量(大于0)、供应商信息 | 1. 进入库存列表页;2. 点击采购申请;3. 填写表单并提交 | 生成采购订单,状态为“待审核” | 订单创建成功,数据库记录正确 | 通过 |
| TC006 | 采购数量为负数 | 采购数量填-5 | 同上 | 提示“采购数量必须大于0” | 前端校验拦截,提示正确 | 通过 |
| TC007 | 采购数量为零 | 采购数量填0 | 同上 | 提示“采购数量必须大于0” | 拦截成功,订单未创建 | 通过 |
| TC008 | 未选择供应商 | 不填写供应商信息 | 同上 | 提示“请选择供应商” | 前端校验拦截,提示正确 | 通过 |
(3)采购订单审核模块测试用例
本模块测试管理员对采购申请进行审核处理的功能。
表5-3采购订单审核模块测试用例表
| TC009 | 审核通过采购订单 | 待审核订单ID | 1. 进入采购订单列表;2. 点击通过 | 订单状态变更为“待入库”,推送至仓管端 | 状态更新成功,仓管端可见该订单 | 通过 |
| TC010 | 审核驳回采购订单 | 待审核订单ID、驳回原因 | 1. 点击驳回;2. 填写原因 | 订单状态变更为“已驳回”,原因回显至采购端 | 状态更新正确,采购端看到驳回原因 | 通过 |
| TC011 | 重复审核同一订单 | 已审核通过的订单ID | 再次点击审核按钮 | 提示“该订单已处理,请勿重复操作” | 拦截成功,状态未变化 | 通过 |
(4)销售订单录入模块测试用例
本模块测试销售用户录入销售订单及库存校验逻辑的正确性。
表5-4销售订单录入模块测试用例表
| TC012 | 正常销售订单录入 | 产品ID、销售数量小于库存、客户信息 | 1. 进入销售订单管理;2. 填写表单并提交 | 生成销售订单,状态为“待审核”,冻结库存 | 订单创建成功,库存被冻结 | 通过 |
| TC013 | 销售数量超过库存 | 购买数量大于当前库存 | 同上 | 提示“库存不足,无法下单” | 拦截成功,订单未创建 | 通过 |
| TC014 | 未选择客户 | 不填写客户信息 | 同上 | 提示“请选择客户” | 前端校验拦截,提示正确 | 通过 |
(5)销售订单审核模块测试用例
本模块测试管理员对销售订单进行审核处理的功能。
表5-5销售订单审核模块测试用例表
| TC015 | 审核通过销售订单 | 待审核订单ID | 1. 进入销售订单列表;2. 点击通过 | 订单状态变更为“待出库”,正式扣减库存 | 状态更新成功,库存正确扣减 | 通过 |
| TC016 | 审核驳回销售订单 | 待审核订单ID、驳回原因 | 1. 点击驳回;2. 填写原因 | 订单状态变更为“已驳回”,释放冻结库存 | 状态更新正确,库存释放 | 通过 |
| TC017 | 库存不足时审核通过 | 库存已被其他订单占用 | 点击通过审核 | 提示“库存不足,审核失败” | 拦截成功,订单状态未变化 | 通过 |
(6)到货入库模块测试用例
本模块测试仓管用户执行到货入库操作的功能。
表5-6到货入库模块测试用例表
| TC018 | 正常到货入库 | 待入库订单ID、实收数量等于采购数量 | 1. 进入采购入库管理;2. 点击入库;3. 确认数量并提交 | 订单状态变更为“已完成”,库存增加 | 状态更新成功,库存正确增加 | 通过 |
| TC019 | 实收数量小于采购数量 | 待入库订单ID、实收数量小于订单数量 | 同上 | 入库成功,订单状态变更为“已完成”,记录差异 | 库存按实收增加,差异字段记录 | 通过 |
| TC020 | 重复入库同一订单 | 已完成入库的订单ID | 再次点击入库操作 | 提示“该订单已完成入库,请勿重复操作” | 拦截成功,库存未重复增加 | 通过 |
(7)销售出库模块测试用例
本模块测试仓管用户执行销售出库操作的功能。
表5-7销售出库模块测试用例表
| TC021 | 正常销售出库 | 待出库订单ID、出库数量 | 1. 进入销售出库管理;2. 点击出库;3. 确认并提交 | 订单状态变更为“已完成”,库存减少 | 状态更新成功,库存正确减少 | 通过 |
| TC022 | 出库时库存不足 | 待出库订单ID,但库存已被其他出库占用 | 点击出库操作 | 提示“库存不足,无法出库” | 拦截成功,订单状态未变化 | 通过 |
| TC023 | 重复出库同一订单 | 已完成出库的订单ID | 再次点击出库操作 | 提示“该订单已完成出库,请勿重复操作” | 拦截成功,库存未重复减少 | 通过 |
5.3 测试结果
本次测试覆盖了管理员、采购用户、销售用户及仓管用户四端的核心业务流程,共执行23个关键用例。测试结果表明,系统功能逻辑正确,用户登录、采购申请与审核、销售订单录入与审核、到货入库及销售出库等模块均能稳定运行。正常流程与异常边界场景下,系统响应迅速,数据交互准确,库存增减与订单状态流转的事务处理一致,未出现崩溃或数据丢失现象。初期发现的少量前端提示问题经修复后回归验证通过。整体而言,系统权限控制严密、业务流程闭环完整,无严重缺陷,符合预期需求,具备正式上线运行的条件。
第六章结论与展望
本文设计并实现了一套面向中小企业的仓库管理系统,覆盖管理员、采购用户、销售用户、仓管用户四类角色。系统实现了后台首页多维度数据统计、采购申请与审核、销售订单录入与审核、库存预警、到货入库与销售出库操作等核心功能。采用SpringBoot加Vue前后端分离架构,MySQL存储业务数据,通过统一的订单状态流转与库存增减逻辑,确保了业务流程的闭环与可追溯。实际测试表明,系统能够有效规范企业出入库流程,减少信息传递误差,提升多岗位协同效率。
尽管系统完成了既定功能目标,但仍存在一些局限。其一,库存预警仅设置了固定的数量阈值,未能根据不同产品的销售频率和采购周期动态调整预警线,可能导致部分快消品预警滞后或慢销品频繁误报。其二,系统缺乏与外部系统的对接能力,无法与企业现有的财务软件或电商平台自动同步订单与库存数据,部分环节仍需人工导入导出。其三,前端页面在移动端的适配不够完善,仓管用户在外出盘点时使用手机操作体验欠佳。其四,高并发场景下的性能未做充分压测,若多个用户同时提交订单可能出现响应延迟。
后续工作可从三方面展开:引入动态预警算法,根据历史数据自动计算各产品的最优安全库存线;开发OpenAPI接口,实现与主流财务及电商平台的数据互通;优化移动端交互,并增加条码扫描功能以提升现场作业效率。
参考文献
[1] 温馨,李少波.智能化仓库管理系统设计与实现[J].中国储运,2025,(11):179-180.DOI:10.16301/j.cnki.cn12-1204/f.2025.11.217.
[2] 本丽莉,万京松,王城,等.基于智能技术的电力物资仓库智慧管理系统设计[J].集成电路应用,2024,41(12):102-103.DOI:10.19339/j.issn.1674-2583.2024.12.043.
[3] 艾新民,智能仓储管理平台技术开发与应用.河北省,中材建设有限公司,2024-08-17.
[4] MohammedA ,RahmanM ,DemirG ,et al. When warehouses dream: a systems-informed exploration of Industry 5.0 principles in warehousing performance management[J].InternationalJournal of Systems Science: Operations & Logistics,2025,12(1):DOI:10.1080/23302674.2025.2559257.
[5] WitekS ,RauchŁ,BzowskiK ,et al. Optimizing heat transfer models for efficient coil cooling in Warehouse Management Systems[J].Archivesof Civil and Mechanical Engineering,2025,25(7-8):296-296.DOI:10.1007/S43452-025-01347-8.
[6] YiZ .Design and Implementation of Warehouse Information Management System Based on Java[J].Journalof Electronics and Information Science,2025,10(2):DOI:10.23977/JEIS.2025.100207.
[7] 陈志升.WK公司仓库管理信息系统的设计与实施[D].南京理工大学,2024.DOI:10.27241/d.cnki.gnjgu.2024.000275.
[8] 丁士祥.H公司电商业务仓库管理系统规划研究[D].大连理工大学,2024.DOI:10.26991/d.cnki.gdllu.2024.002947.
[9] 吴思翰.基于单片机的智能物流仓库管理系统设计[J].中国储运,2024,(04):160-162.DOI:10.16301/j.cnki.cn12-1204/f.2024.04.058.
[10] 江乐康.S制造公司仓储管理优化研究[D].上海大学,2024.DOI:10.27300/d.cnki.gshau.2024.000750.
[11] 王志亮,纪松波.基于SpringBoot的Web前端与数据库的接口设计[J].工业控制计算机,2023,36(03):51-53.
[12] 刘汀.基于SpringBoot的微服务体系在企业信息管理系统中的应用[J].信息技术与信息化, 2023, (05): 23-26.
[13] 宋文凯,王利萍,荆巍巍.基于Vue框架的多源WEB前端页面数据可视化方法[J].电子设计工程,2025,33(06):63-66+71.
[14] 董宁,江平.Vue.js前端开发框架应用[M].人民邮电出版社:202405.237.
[15] 李晓薇. Vue框架在前端开发中的应用研究[J].软件, 2024, 45 (11): 108-110.
[16] 汪泊. Java编程语言在计算机软件开发中的应用[J].软件, 2025, 46 (06): 128-130.
[17] 韩欣洲.Java语言程序设计教学与实践探讨[J].物联网技术,2025,15(13):160-162.
[18] 沙雨彤.基于深度学习的计算机软件Java编程技术[J].信息记录材料,2025,26(07):128-130.
[19] 翟凌云.MySQL数据库在分布式系统架构设计中的应用[J].软件,2025,46(04):100-102.
[20] 赵新平.MySQL数据库在高并发Web系统中的优化技术[J].软件,2025,46(03):116-119.
致谢
在本文的撰写过程中,我得到了许多来自学术与生活方面的支持与帮助。首先,衷心感谢我的指导老师。从选题论证、框架设计到内容修改,老师始终给予我耐心细致的指导和中肯的建议。在老师的引导下,我逐步厘清了研究思路,提升了分析问题和解决问题的能力。指导老师严谨治学的态度和务实高效的工作作风让我受益匪浅,为本论文的顺利完成提供了坚实保障。
感谢学校在项目研究过程中提供的学习资源和技术支持,使本课题的研究得以顺利推进。同时,感谢我的同学以及参与技术讨论的伙伴们,在论文写作和系统开发过程中,大家围绕功能设计、架构实现等问题展开了多次深入交流,提出了许多宝贵意见,极大地丰富了我的研究视角和实践思路。
此外,还要感谢家人一直以来的理解和支持,在论文写作期间给予了我充分的鼓励与精神力量,使我能够专注于研究工作并顺利完成学业。最后,谨向所有在本研究中提供帮助和支持的大家表示诚挚的感谢。
点赞+收藏+关注 →私信领取本源代码、数据库
关注博主下篇更精彩
一键三连!!!
一键三连!!!
一键三连!!!
感谢一键三连!!!
网硕互联帮助中心







评论前必须登录!
注册