爬宠门店进销存与客户预约管理系统的设计与实现-论文15903字_第1页
爬宠门店进销存与客户预约管理系统的设计与实现-论文15903字_第2页
爬宠门店进销存与客户预约管理系统的设计与实现-论文15903字_第3页
爬宠门店进销存与客户预约管理系统的设计与实现-论文15903字_第4页
爬宠门店进销存与客户预约管理系统的设计与实现-论文15903字_第5页
已阅读5页,还剩35页未读, 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

爬宠门店进销存与客户预约管理系统的设计与实现摘要针对中小型爬宠门店手工台账易导致库存错乱、寄养登记难留存及权限缺失等问题,设计并实现PC管理后台与微信小程序双端协同的进销存与预约系统。系统采用前后端分离B/S架构,后端以SpringBoot2.7.18配合MyBatisPlus3.5.3与MySQL8.0处理数据交互,PC端基于Vue3与ElementPlus搭建,客户端采用uni-app编译为微信小程序。安全层部署JWT无状态令牌验证与BCrypt密码散列算法,落实店长全权限、店员基础权限与客户自助模式,限制店员查看进货成本、导出数据及管理账号。核心模块涵盖商品档案、进销存台账、寄养工单流转(BOOKED至FOSTERING至DONE至ARCHIVED)与月度统计,出入库记录永久保存且支持多维查询,库存触底自动预警。内嵌测试数据集包含12种商品、6个分类、3名客户、5张四状态工单及13条历史出入库单据。执行28项功能测试均一次性通过。系统贴合单店业务动线,消除人工账目误差,降低管理成本并提升日常调度效率。关键词:爬宠门店;进销存管理;寄养预约;微信小程序;角色权限AbstractAddressinginventorydiscrepancies,unarchivedfosterregistrations,fragmentedreservationdata,andabsentpermissioncontrolscausedbymanualledgersinsmallandmediumreptilepetstores,thisstudydesignsandimplementsadual-endinventoryandreservationsystemcombiningaPCmanagementbackendwithaWeChatmini-program.Thesystememploysafront-endandback-endseparatedB/Sarchitecture.Theback-endprocessesbusinesslogicusingSpringBoot2.7.18,MyBatisPlus3.5.3,andMySQL8.0.ThePCinterfaceisdevelopedwithVue3andElementPlus,whiletheclientapplicationutilizestheuni-appframeworkcompiledintoaWeChatmini-program.SecuritymechanismsintegrateJWTstatelessauthenticationandBCryptpasswordhashing,enforcingroleisolationamongstoremanagers,staff,andcustomers.Staffinterfacesautomaticallyrestrictaccesstopurchasecosts,statisticalexports,andaccountmanagement.Corefunctionalitiesencompassproductarchives,inventoryledgers,fosterorderstatetransitions(BOOKEDtoFOSTERINGtoDONEtoARCHIVED),andmonthlyreporting.Inboundandoutboundrecordsarepermanentlypersistedandqueryablebytimeorcategory,withautomatedalertstriggeringwhenstockfallsbelowdefinedthresholds.Thevalidationdatasetcontains12products,6categories,3customers,5fosterordersspanningallfourstates,and13historicalstocktransactions.All28functionaltestcasespassedsuccessfully.Theplatformalignswithsingle-storeoperationalworkflows,replacesmanualrecord-keeping,andimprovesdailyinventorytrackingandappointmentmanagementefficiency.Keywords:Reptilepetstore;Inventorymanagement;Fosterreservation;WeChatmini-program;Role-basedpermission第1章绪论1.1研究背景与意义爬宠活体与耗材品类繁杂,手工记录出入库极易导致库存数据错乱,管理者无法实时掌握活体存活数量与饲料剩余量,频繁出现缺货断供或活体积压损耗。客户寄养业务长期依赖纸质单据登记,寄养周期、日常喂养与健康体征难以完整留存,到期后容易遗漏跟进通知。这两项高频业务因缺乏电子化留痕,直接推高了门店的日常管理摩擦成本。客户预约与线下订单数据分散于不同载体,经营者无法快速统计月度销量与寄养单量,导致经营复盘效率低下且缺乏数据支撑。门店内部缺少精细化权限划分,店员与店主操作边界模糊,进货成本与商品定价等核心商业数据存在泄露风险。中小型爬宠商铺亟需一套轻量化系统来整合碎片化业务流程,消除信息孤岛带来的决策盲区。本文设计前后端分离的B/S(浏览器/服务器)架构双端管理系统,以PC管理后台服务店长与店员,微信小程序面向终端客户,聚焦进销存台账与寄养预约两大核心业务。系统覆盖商品档案维护、进销存流水追踪、寄养工单调度、多维数据统计与账号权限控制五大模块。该方案填补了通用宠物软件与独立进销存工具之间的功能断层,为单一门店提供了低成本、高适配的数字化运营载体,直接降低库存损耗率并提升客诉响应速度。1.2国内外研究现状1.2.1国内研究现状进销存管理信息系统的架构演进始终围绕流程集成与扩展性展开。刘争光(2023)指出传统单体架构因高耦合与低灵活性已难以应对复杂业务逻辑,采用微服务设计可实现采购、销售与库存环节的解耦与统一管控REF_Ref1\n\h[1]。林斯阳(2023)的研究表明针对多变的客户需求,基于订单驱动的进销存系统能够替代繁琐的手工台账,显著提升企业周转效率与市场竞争力REF_Ref2\n\h[2]。移动端技术的普及进一步推动了该领域的场景下沉,王鑫龙(2020)提出结合云服务与触摸交互优化的移动平台进销存应用,有效解决了中小企业对灵活开单与实时报表获取的刚性需求REF_Ref3\n\h[3]。宠物行业数字化应用逐步向私域流量沉淀与垂直服务延伸。侯凡凡(2019)分析指出宠物实体店接入微信小程序具备获客成本低与用户触达及时的显著优势,有助于实体门店在激烈竞争中维持客户黏性REF_Ref4\n\h[4]。阙瑾蓉(2021)设计的宠宠欲动小程序验证了轻量级接口封装与地图定位功能在宠物生活服务推荐中的实用性REF_Ref5\n\h[5]。针对特定管理场景,平欣(2023)将GPS定位技术融入智能宠物管理系统,实现了动物活动轨迹的可视化追踪REF_Ref6\n\h[6]。余文轩(2025)则探索了AI图文识别技术在宠物疾病诊断小程序中的应用,通过在线问诊互动完善了术后护理与健康管理闭环REF_Ref7\n\h[7]。国内现有研究成果在进销存底层逻辑与宠物垂类应用上均已形成成熟范式,但两者处于割裂状态。成熟的进销存软件仅侧重仓储流转与财务核算,完全剥离宠物寄养与活体特殊照料业务。而市面上的宠物类小程序多服务于猫狗洗护、疫苗接种或单一疾病咨询,缺乏与后端库存数据的实时联动。针对爬宠活体生理特性与小众门店运营特征的综合性软件在国内市场仍属空白。1.2.2国外研究现状零售企业的库存控制策略长期聚焦于风险控制与供应链优化。MehdiShadaei(2023)通过实证数据证明企业风险管理框架能实质性提高库存周转率,尤其在运营不确定性较高的环境中可规避资金占用损失REF_Ref8\n\h[8]。JrmieGallien(2021)针对分布不均的配送网络构建了基于优化算法的补货策略,验证了动态调整安全库存水平能够同步改善服务覆盖率与区域资源公平性REF_Ref9\n\h[9]。数据驱动的商业决策支持系统在零售扩张与移动端普及层面取得进展。HimanshuPahuja(2024)开发的Dexter系统利用集成算法处理多层级运营数据,为零售门店选址与规模调整提供量化依据REF_Ref10\n\h[10]。MarciaMkansi(2023)调查中小零售商户的移动应用采纳过程,指出跨职能团队协同与基础设施投入是克服技术与组织壁垒的关键路径REF_Ref11\n\h[11]。国外文献在库存数学建模、数据决策引擎及中小企业移动化工具推广方面积累了大量理论模型与仿真成果,但其应用场景高度标准化,主要面向大宗消费品或连锁医药零售。此类系统通常预设复杂的门店协同网络与高昂的订阅费用,且产品逻辑深度绑定主流伴侣动物的常规诊疗节奏,无法直接平移至爬宠活体温控养护、异形饲料配比及单店极简运营的实际场景中。1.2.3研究现状述评综合国内外文献可知,通用型进销存系统与垂直领域宠物应用各自跨越了不同的功能阶段,却未能交叉融合。现有商业软件要么侧重标准化商品流转,忽略爬宠活体非标品属性。要么停留在前端营销展示,未打通后台库存扣减与寄养计费。中小型门店面临的操作痛点缺乏针对性解法,业界尚未出现兼顾角色权限隔离、进销存台账自动扣减、活体工单追踪与微信小程序轻量预约的一体化方案。本研究据此构建定向管理系统,补齐细分业态数字化短板。1.3研究内容与组织结构本文遵循软件工程标准生命周期,按照需求分析、系统设计、详细开发与测试验证的线性逻辑推进项目落地。整体技术路线如图1.1所示。需求分析章节聚焦门店实际运营场景,梳理业务流转节点,明确店长、店员与消费者三类角色的操作诉求,界定进销存台账、寄养工单、预约统计、账号权限等核心功能边界,并完成并发性能与数据安全性等非功能性指标设定。系统规划章节输出前后端分离的总体架构图,细化五大功能模块的数据流向,完成关系型数据库表结构设计,并定义RESTful风格的接口规范。代码实现章节阐述具体开发过程,详细说明登录鉴权拦截器配置、商品档案增删改查、入库出库流水生成、寄养状态机流转、Excel数据导出以及微信小程序端页面路由与API调用的核心逻辑。验证环节部署真实运行环境,编写覆盖正向流程与异常边界的用例集,执行压力测试评估系统在高并发请求下的响应延迟与内存占用阈值。最终结论部分对系统运行效果进行总结,剖析当前版本在活体健康预警算法与跨门店数据互通方面的局限性,提出后续迭代的技术演进方向。图1.1系统技术路线

Figure1.1Technicalroadmapofthesystem第2章需求分析2.1业务需求分析本系统针对中小型单店爬宠零售门店的实际运营场景构建,核心服务对象涵盖店主、一线店员与到店消费客户。门店日常经营高度依赖人工记录商品流转与寄养进度,纸质台账易出现丢失、错漏且无法实时同步数据,直接导致库存积压或超卖风险。系统设计以替代传统纸质记录为首要目标,采用线下实体经营与线上预约登记双端协同的架构。在功能取舍上,系统剔除多店连锁调度、高级商业智能预测等超出单店承载能力的复杂模块,仅保留进销存台账、线上寄养预约、客户信息沉淀与基础权限管控四类刚需业务。这种降维设计直接削减了系统冗余逻辑,使开发资源集中于数据录入效率与账目准确性,确保系统上线后能无缝嵌入门店现有工作流,降低员工学习成本并提升日常运转速率。2.2用户需求分析门店店主作为经营决策者,需通过PC后台掌握全量业务动态。店主负责维护商品基础档案并录入进货入库单据,实时监控销售与寄养流水,设定库存安全阈值,定期导出月度经营报表用于财务复盘。店主拥有最高级别账号控制权限,可新增、禁用店员账号并分配操作范围,同时调阅全部客户资料与历史交易明细。该角色对全局数据的可见性要求极高,构成系统权限树状结构的顶端节点。门店店员承担一线执行任务,其PC后台权限被严格限制于日常业务闭环。店员能够登记离线销售订单触发商品出库,接收小程序提交的寄养预约并生成工单,在寄养周期内更新爬宠喂养频次与健康状态记录。系统切断店员修改商品进货底价、查询全局统计数据及管理软件账号的接口。权限边界的设计依据在于保护核心商业机密,防止基础操作人员接触供应链成本数据,同时将操作界面收敛至高频动作,减少误触导致的账目偏差。到店消费客户通过微信小程序完成自助服务交互。客户无需注册独立客户端即可浏览在售活体爬宠与器材详情,在线提交特定日期的寄养预约请求。系统自动向客户展示已生成工单的唯一编号与预计归还时间,客户可随时查阅个人历史预约轨迹。移动端仅开放只读与有限写入权限,剥离后台管理逻辑,确保消费者在低网络环境下仍能快速获取服务进度,缓解门店人工接听咨询的运营成本。2.3功能需求分析2.3.1功能模块划分业务逻辑拆解为五个核心功能模块,各模块遵循数据流向独立运行又相互关联。商品基础档案分类模块建立活体动物与消耗品的数字化身份,系统将商品划分为LIVE活体与SUPPLY器材耗材两大子类,支持录入品类、品相特征、进价售价及规格参数。模块内置自定义库存预警数值配置项,覆盖守宫、蛇类、龟类、饲料、垫材、饲养设备共六个分类维度,提供图片上传与增删改查操作。该模块作为数据源头,统一规范物料编码规则,消除手工记账时的名称歧义。进销存台账管理模块处理资金与实物的双向流动。商品进货完成后执行入库登记,线下销售订单确认后自动扣减对应SKU库存数量,实现账实同步。当库存触及预设阈值时,系统触发页面弹窗告警提示补货。所有出入库凭证生成不可篡改的电子单据,支持按时间轴与商品类型筛选回溯。该模块取消手动调价功能,杜绝人为干预账面利润,确保财务报表直接映射实际仓储变动。客户与寄养工单管理模块衔接客户服务与物理养护流程。后台建立客户信息数据库留存联系方式与消费偏好,客户在小程序发起预约后自动转化为待处理工单。店员介入后按日次更新寄养期间的摄食、排泄与体表健康日志,工单状态随护理进度流转至待取回或已完成归档。生命周期管理替代了碎片化的沟通记录,使寄养服务质量具备可追溯性。预约订单数据统计模块聚焦经营复盘。系统定期聚合月度商品销量总额与寄养订单笔数,以结构化表格呈现指标波动。数据输出接口兼容Excel格式,便于店主打印存档或接入第三方财务软件。统计逻辑基于原始单据自动演算,避免二次加工引入的舍入误差,直接支撑库存采购计划调整。账号权限管理模块构筑系统访问防线。管理员初始化基础角色模板,为不同员工绑定差异化指令集。店主权限覆盖全量路由,店员路由仅开放销售办理、寄养登记与基础查询节点。该模块采用静态声明式权限校验,在网关层拦截越权请求,保障数据结构完整性。2.3.2系统功能结构如图2.1所示,系统按业务边界划分为六个一级功能模块。商品档案管理子树涵盖商品信息维护、商品分类(活体与耗材)映射以及库存预警阈值设定,构成底层数据底座。客户管理节点集中存储客户基础信息与历史寄养关联记录,打通线上线下会员标识。寄养工单管理节点串联养护记录填报、到期提醒推送、状态机流转与前端预约登记,形成完整的服务履约链路。库存管理节点包含入库登记、出库登记、单据历史查询与实时库存查询,维持物资账目平衡。系统管理节点负责数据初始化、角色权限配置与账号生命周期维护,充当控制中枢。统计分析节点挂载数据导出引擎与月度统计看板,提供决策可视化支撑。六大模块以数据表为纽带串联,前端路由根据角色令牌动态加载对应节点,确保高内聚低耦合的工程结构。图2.1系统功能结构

Figure2.1Systemfunctionstructure

Figure2.1Systemfunctionstructure2.3.3用例分析如图2.2所示,店长、店员、小程序客户通过公共的登录用例进入系统,各自拥有不同的功能用例集合。登录用例作为入口屏障,验证身份凭证并下发访问令牌,决定后续会话的数据视图。店长用例群覆盖出入库登记、商品档案维护、客户信息管理、寄养工单全流程管理、库存预警阈值设置、月度统计与导出、账号与角色管理七大核心路径,支撑宏观运营决策。店员用例群限定于入库登记辅助核对、商品档案查询检索、寄养工单办理执行与库存余额查询四项高频动作,匹配一线作业节奏。小程序客户用例群聚焦商品浏览检索、客户自主注册、提交寄养预约与预约订单查询四个交互环节,满足C端自助服务诉求。用例矩阵清晰界定系统交互边界,排除非目标角色的干扰路径,缩短需求评审阶段的歧义讨论周期。图2.2三类角色用例图

Figure2.2Usecasediagramofthethreeroles

Figure2.2Usecasediagramofthethreeroles2.4非功能需求分析性能约束直接关联门店高峰时段的操作体验。常规页面交互响应时间需压缩至2秒以内,避免排队等待打断交易流程。系统底层连接池与缓存策略需稳定支撑15人同时在线并发操作,确保多终端同步更新库存与工单状态时不产生数据死锁或丢失。该并发基数贴合单店日常排班规模,预留冗余缓冲应对节假日客流激增。易用性要求决定系统落地阻力。PC后台采用栅格化布局与扁平化导航,剥离冗余层级跳转。小程序首页将商品货架与预约按钮置于首屏可视区,操作流程严格遵循单次点击不超过三次的交互法则。零基础门店员工经过短暂演示即可掌握登单与核销动作,显著降低培训成本与上手门槛。安全性架构防御内部数据泄露与外部恶意注入。用户密码采用加盐哈希算法存储,杜绝明文落盘。角色权限隔离机制在API层面实施细粒度校验,店员前端隐藏进货单价字段且后端拒绝相关读取请求,阻断敏感财务信息外流。SQL参数化查询与跨站脚本过滤中间件同步部署,抵御常见Web攻击向量。可维护性规范保障后期迭代效率。代码工程严格遵循控制器、服务层、数据访问层的分层模型,业务逻辑与界面渲染彻底解耦。数据库建表脚本增加字段级注释说明,枚举值集中定义于配置字典。模块化拆分使得单一功能缺陷修复不引发连锁回归错误,降低技术债累积速度。兼容性适配覆盖主流终端环境。PC后台内核基于现代Web标准编写,完美兼容Chrome与Edge浏览器最新稳定版,弹性布局自适应不同分辨率屏幕。微信小程序端遵循官方设计规范,利用条件编译与适配层处理安卓与iOS系统的屏幕刘海与底部安全区域差异,确保全机型微信客户端显示一致且触控热区符合操作习惯。第3章系统设计3.1系统总体架构设计如图3.1所示,系统采用前后端分离的三层架构。表现层由PC管理后台与微信小程序构成,负责页面渲染、表单校验及交互反馈。管理后台基于Vue3与ElementPlus构建,覆盖仪表盘、商品档案、客户管理、寄养工单、库存管理、登录鉴权、系统管理与预约统计八个视图。小程序侧重移动端场景,提供商品浏览、客户注册登录、寄养预约与订单查询功能。应用服务层部署于SpringBoot框架,拆分为商品服务、寄养服务、统计导出、认证授权与进销存服务五个微职责模块。该分层将业务逻辑集中处理,通过统一接口暴露计算结果与状态变更。数据层采用MySQL8.0持久化存储单据、商品、客户、工单与用户五类核心数据。MyBatisPlus作为数据访问层组件封装通用CRUD操作,分页插件直接映射SQL游标扫描。事务边界划定在应用服务层,确保多表更新时的原子性,避免表现层直连数据库导致的一致性风险。选择前后端分离架构是为了隔离界面迭代与业务重构的依赖周期,前端独立部署静态资源可减轻后端并发压力。SpringBoot内置容器与自动配置机制降低环境差异带来的运维成本。MySQL8.0的JSON扩展与窗口函数满足复杂报表聚合需求,InnoDB引擎的MVCC机制支撑高并发读写下的数据可见性控制。图3.1系统总体架构Figure3.1Overallsystemarchitecture

Figure3.1Overallsystemarchitecture3.2功能模块设计系统功能划分为商品档案管理、客户管理、寄养工单管理、库存管理、系统管理与统计分析六个一级模块。各模块严格遵循单一职责原则,边界通过Service接口定义并解耦。商品档案模块负责活体耗材的分类维护、信息录入与上下架状态流转,不介入实际出入库动作。客户管理模块专注客户资料清洗、联系方式核验与历史交互记录聚合,为预约与结算提供基础数据。寄养工单管理模块承载生命周期状态机,从BOOKED到ARCHIVED的流转均由该模块驱动,拦截非法状态跃迁。库存管理模块执行入库登记、出库扣减与预警阈值监控,计算逻辑独立于商品展示逻辑。系统管理模块限定管理员权限范围,仅处理账号增删改查与角色分配,不触碰业务单据。统计分析模块聚合多维数据生成趋势图表与Excel导出文件,采用异步任务调度避免阻塞主线程。模块间通信摒弃全局变量共享,全部依赖注入的Service接口传递DTO对象。该设计使库存扣减算法与状态机迁移规则相互隔离,任一模块的字段扩充或逻辑调整均无需修改其他模块的调用契约。低耦合结构直接反映在代码依赖方向上,依赖关系单向指向基础设施层,满足开闭原则。3.3数据库设计3.3.1ER模型如图3.2所示,系统用户、商品档案、商品分类与客户四个实体构成商品与客户管理模块的ER模型。系统用户对商品档案具有一对多维护权限,店长创建条目后店员可执行编辑操作。商品档案对商品分类存在多对一归类约束,LIVE与SUPPLY类型字段限制活体与耗材的物理存储策略区分。系统用户与客户之间建立一对多服务关系,单一店员可跟进多个客户档案。关联边上的基数明确标注了外键落表位置,避免循环引用导致的索引失效。如图3.3所示,商品档案与出入库单据为一对多关系,构成进销存台账模块的ER模型。单次上架或调拨动作生成独立单据记录,商品实体仅保留快照信息不参与历史追溯。客户实体与寄养工单形成一对多委托关系,一位客户可提交多次不同周期的寄养申请。工单实体进一步关联养护记录实体,一对一主外键绑定确保每条护理日志精准对应待办项。ER图采用正交连线布局,实体矩形框内标注主键属性,菱形关系符旁标注参与约束比例,直观呈现数据存储的物理拓扑。图3.3系统ER图(模块二)Figure3.3ERdiagramofthesystem(module2)

Figure3.3ERdiagramofthesystem(module2)图3.2系统ER图(模块一)Figure3.2ERdiagramofthesystem(module1)

Figure3.2ERdiagramofthesystem(module1)3.3.2主要表结构如表3-1所示,系统用户表结构如下。表3-1系统用户表结构

Table3-1Structureofthesys_usertable

Table3-1Structureofthesys_usertable字段类型说明idINT主键usernameVARCHAR(50)登录账号(唯一)passwordVARCHAR(100)BCrypt密文real_nameVARCHAR(50)姓名roleVARCHAR(20)MANAGER/STAFFstatusCHAR(1)1启用0禁用create_timeDATETIME创建时间update_timeDATETIME更新时间user表采用BCrypt哈希算法存储凭证,盐值随机生成阻断彩虹表攻击。role字段限定权限粒度,MANAGER赋予财务与配置权限,STAFF仅开放操作视图。status软开关配合中间件过滤掉禁用户态请求。如表3-2所示,商品档案表结构如下。表3-2商品档案表结构

Table3-2Structureoftheproducttable

Table3-2Structureoftheproducttable字段类型说明idINT主键category_idINT关联分类nameVARCHAR(100)名称specVARCHAR(100)规格/品相unitVARCHAR(20)计量单位(只/袋/个)cost_priceDECIMAL(10,2)进货成本(店员不可见)sale_priceDECIMAL(10,2)销售价stockINT当前库存warn_thresholdINT库存预警阈值statusCHAR(1)1上架0下架imageVARCHAR(255)封面图路径remarkTEXT备注deletedTINYINT(1)逻辑删除标志create_timeDATETIME创建时间update_timeDATETIME更新时间商品表将cost_price与sale_price拆分至独立列,配合查询拦截器实现基于角色的字段遮蔽,防止店员越权查看毛利率。warn_threshold独立设防触发异步告警任务,低于阈值时推送站内信。deleted标识替代物理删除维持历史订单溯源链完整性。如表3-3所示,出入库单据表结构如下。表3-3出入库单据表结构

Table3-3Structureofthestock_doctable

Table3-3Structureofthestock_doctable字段类型说明idINT主键doc_noVARCHAR(30)单据编号(唯一,如RK202409010001)typeCHAR(3)IN入库/OUT出库product_idINT商品IDproduct_nameVARCHAR(100)单据留痕冗余category_typeINT1活体/2耗材quantityINT数量priceDECIMAL(10,2)入库=进价/出库=售价amountDECIMAL(10,2)金额小计supplier_idINT供应商IDcustomer_nameVARCHAR(50)客户名称operator_nameVARCHAR(50)经办人remarkTEXT备注create_timeDATETIME创建时间该表设定为只追加模式,禁止UPDATE与DELETE操作保障审计追溯力。product_name与category_type作冗余字段剥离对product表的实时JOIN依赖,提升历史报表查询性能。doc_no采用日期流水号组合生成,天然具备时间序属性。price字段语义随type动态切换,入库记录供应链采购成本,出库记录终端结算单价,金额汇总以此为准。如表3-4所示,寄养工单表结构如下。表3-4寄养工单表结构

Table3-4Structureofthefoster_ordertable

Table3-4Structureofthefoster_ordertable字段类型说明idINT主键order_noVARCHAR(30)工单编号(唯一,如JY202409010001)customer_idINT客户IDcustomer_nameVARCHAR(50)客户姓名(冗余)customer_phoneVARCHAR(20)客户电话(冗余)pet_typeVARCHAR(50)品种pet_nameVARCHAR(50)宠物名字pet_ageVARCHAR(20)年龄pet_featureTEXT特征/备注diet_noteTEXT饮食要求start_dateDATE寄养开始日期end_dateDATE寄养结束日期priceDECIMAL(10,2)预估费用statusVARCHAR(20)BOOKED/FOSTERING/DONE/ARCHIVED/CANCELLEDstore_user_idINT经办店员remarkTEXT备注create_timeDATETIME创建时间update_timeDATETIME更新时间工单表冗余customer_name与customer_phone消除跨表联查开销,客户资料变更后不影响历史在养单显示。status枚举串接状态机,强制校验前驱后继合法性。store_user_id绑定责任主体,到期提醒任务按end_date轮询匹配超期工单派发通知。3.3.3其余数据表辅助表共同补全核心实体的关联网络。customer表以手机号作为唯一登录凭证,加密存储设备Token映射会话状态。product_category表定义LIVE与SUPPLY两类字典,限制商品归属枚举范围。supplier表聚合货源渠道信息,供出入库单据关联采购方。care_record表通过外键绑定foster_order.id,专用于累积每日喂食、换水与环境消毒日志。四张表均不承载独立业务入口,仅作为主表的外围参照数据支撑主流程运转。窄表设计减少磁盘碎片,复合索引覆盖常用检索条件。3.4接口设计如图3.1所述的分层体系决定接口需严格遵循RESTful表述性状态转移规范,以HTTP方法映射资源操作意图。如表3-5所示,系统暴露的API路由按业务域分组配置。表3-5主要REST接口设计

Table3-5MainRESTAPIdesign

Table3-5MainRESTAPIdesign方法路径权限说明POST/api/auth/login店长/店员后台登录/api/auth/register无客户注册/api/auth/customerLogin无客户登录GET/api/public/products无在售商品浏览POST/api/public/foster/booking无客户提交寄养预约GET/api/public/foster/my无客户查询我的工单POST/api/public/foster/cancel无取消预约GET/api/product/page店长/店员商品分页POST/api/product店长新增商品DELETE/api/product/{id}店长删除商品GET/api/product/low-stock店长/店员低库存商品POST/api/stock/inbound店长入库/api/stock/outbound店长/店员出库GET/api/stock/docs店长/店员历史单据查询/api/stock/snapshot店长/店员库存快照/api/foster/page店长/店员工单分页POST/api/foster/start店长/店员办理入店/api/foster/complete店长/店员完成/api/foster/archive店长/店员归档/api/foster/care店长/店员新增养护记录GET/api/foster/care/list店长/店员养护记录/api/foster/due-remind店长/店员到期提醒/api/stats/monthly店长/店员月度统计/api/stats/trend店长/店员近N月趋势/api/stats/export店长导出Excel/api/stats/summary店长/店员仪表盘汇总/api/sys/user/page店长账号分页POST/api/sys/user店长新增账号接口权限划分依据岗位数据安全边界实施差异化拦截。客户公开接口置于/public命名空间,跳过JWT校验过滤器以提升首屏加载效率。商品管理与进销存接口设置双重鉴权,POST新增与DELETE删除操作附加MANAGER角色校验,普通员工只能发起查询或执行状态流转。统计导出接口消耗较多CPU与内存,网关层配置IP速率限制防止恶意拉取拖垮报表服务。所有写操作均返回标准化响应体携带操作标识与受影响行数,便于前端组件统一处理提交反馈。URL路径采用名词复数形式表示集合资源,RESTful风格保证路由语义自解释,降低前后端联调沟通成本。第4章系统详细设计与实现4.1开发环境与技术选型后端运行于JDK17与SpringBoot2.7.18环境,依托SpringMVC分发HTTP请求并接入MyBatisPlus3.5.3完成对象关系映射。数据库选用MySQL8.0保障事务隔离级别与复杂检索性能,构建工具采用Maven3.6+管理依赖树。PC管理端基于Node.js18+生态,使用Vue3配合ElementPlus组件库与Vite5构建工程,服务端口配置为3000。后端接口统一挂载在8080端口context-path/api下。小程序端采用uni-app(Vue3语法)跨端框架,开发阶段通过17700端口H5预览验证交互逻辑,生产期编译为mp-weixin微信小程序产物。技术选型侧重长期支持版本的安全性与前后端分离架构的解耦能力。BCrypt算法提供加盐散列存储,消除明文密码泄露风险。JWT令牌机制适配无状态交互,避免服务端会话存储膨胀。各端口划分明确阻断跨域越权访问路径。4.2登录鉴权与权限控制实现前后端分离架构要求身份校验不依赖集中式会话存储。系统采用BCrypt对注册密码执行加盐加密后落库,登录成功即时签发HS256签名的JWT令牌。令牌载荷封装userId、role(MANAGER/STAFF/customer)、type(admin/customer)与realName字段,有效时长读取应用配置。AuthInterceptor拦截所有非公开请求,解析Header中的Authorization字段并将解析后的用户信息写入HttpServletRequest属性集合。静态资源与客户端首次获取公钥的路径匹配/public/**直接放行。Controller层通过显式调用权限校验类接管业务路由拦截。店员角色受数据可见性限制,成本字段序列化时强制剥离。统计查询与账号管理接口遭遇非授权角色直接返回403业务码。关键拦截逻辑如下:publicstaticvoidrequireManager(HttpServletRequestreq){

Stringrole=(String)req.getAttribute("loginRole");

if(!"MANAGER".equals(role)){

thrownewIllegalStateException("FORBIDDEN");

}

}权限边界通过拦截器前置校验与VO层按需序列化双重落实,确保最小权限原则贯穿全链路。4.3商品档案模块实现商品数据需严格区分活体饲养环境与耗材物料属性。系统将品类划分为LIVE与SUPPLY,独立维护进货价、销售价与安全库存阈值warn_threshold。店长账号拥有完整CRUD权限,可录入进出货成本并调整预警线。店员仅触发只读查询视图,无法篡改基础参数。分类层级新增或删除操作限定MANAGER角色执行。低库存列表lowStockProducts接口持续比对当前stock与warn_threshold字段,过滤出缺货风险项。界面呈现依托PC仪表盘聚合展示,核心经营指标与明细清单同屏渲染。如图4.3所示,仪表盘聚合经营概览、库存预警与到期提醒三类信息。图4.3PC端仪表盘界面

Figure4.3PCdashboardinterface顶部统计卡片同步商品总数12、库存不足商品4、注册客户数3与寄养中工单2。左侧预警列表实时滚动爬宠垫沙(3/5)、杜比亚蟑螂(8/10)、玉米蛇·成体(2/3)、豹纹守宫·亚成体(4/5)四项阈值触发表。右侧排期面板高亮临近结束订单。左侧导航栏按业务流排列商品档案、库存管理、寄养工单等菜单项。权限隔离使店员工作台隐藏成本输入框,降低误操作概率。4.4进销存台账模块实现进销存流水遵循不可篡改原则,历史单据表采用追加写入策略。冗余字段预存商品名称、大类编码与经办人快照,支撑后期多维检索而不依赖实时关联查询。出入库操作绑定[Transactional?]注解保障原子性。入库流程校验数量与商品实体有效性后生成RK前缀单号,插入StockDoc记录的同时直接更新Product库存基数。出库流程前置扣减校验,stock不足量拒绝执行且杜绝负库存。单据定价规则随方向切换,入库取costPrice,出库取retailPrice。单号生成规则为业务缩写附加yyyyMMddHHmmss时间戳与三位随机数,冲突率趋近于零。多维度筛选区支持时间区间、IN/OUT类型、类别字典与模糊关键字组合过滤。如图4.1所示,出入库以登录鉴权为前置,单据写入与库存更新在同一事务中完成。图4.1商品出入库时序图

Figure4.1Sequencediagramofstockinbound/outbound核心入库逻辑封装如下:@Transactional

publicStockDocinbound(IntegerproductId,Integerquantity,IntegersupplierId,StringoperatorName,Stringremark){

//校验数量>0、商品存在;生成RK单号

StockDocdoc=newStockDoc();

doc.setDocNo(genDocNo("RK"));doc.setType("IN");

doc.setProductName(p.getName());

doc.setCategoryType(catType);//1活体/2耗材

doc.setQuantity(quantity);

doc.setPrice(p.getCostPrice());doc.setAmount(...);

stockDocMapper.insert(doc);

p.setStock(p.getStock()+quantity);//实时更新库存

productMapper.updateById(p);

returndoc;

}如图4.4所示,库存管理页同时提供进销存操作、当前库存快照与历史单据查询。图4.4PC端库存管理界面

Figure4.4PCinventorymanagementinterface页面中央区域划分操作指令区与查询网格,当前库存表内红底白字三角符号标识突破阈值的条目。历史单据表格完整保留经办痕迹,筛选条件覆盖单据类型、商品类型、日期范围与关键字。追加归档机制满足审计追溯需求,彻底切断物理删除入口。4.5寄养工单模块实现寄养服务周期长且状态变更频繁,需引入有限状态机约束流转轨迹。工单生命周期定义为BOOKED、FOSTERING、DONE、ARCHIVED四个主阶段,BOOKED与FOSTERING允许发起取消动作至CANCELLED。Service层拦截器逐跳校验前驱状态,跳过中间态的非法跃迁直接抛出异常。养护日志绑定order_id外键,仅在预约或进行中状态下允许录入温湿度、喂养内容与健康观察结果。每日定时任务扫描FOSTERING且end_date小于等于当前日plus预警天数的记录,触发站内信或短信通知。状态转移合法性由业务规则矩阵强制锁定,具体流转约束如表4-1所示。表4-1寄养工单状态流转规则

Table4-1Fosterorderstatetransitionrules

Table4-1Fosterorderstatetransitionrules当前状态可执行操作目标状态权限要求BOOKED办理入驻FOSTERING店长/店员取消预约CANCELLED客户/店长FOSTERING完成寄养DONE店长/店员取消预约CANCELLED客户/店长DONE归档工单ARCHIVED店长任意状态新增养护记录保持原状店员入店办理函数校验契约如下:publicvoidstartFoster(IntegerorderId,IntegerstoreUserId){

FosterOrdero=requireOrder(orderId);

if(!"BOOKED".equals(o.getStatus()))thrownewIllegalArgumentException("仅预约状态工单可办理入店");

o.setStatus("FOSTERING");o.setStoreUserId(storeUserId);

orderMapper.updateById(o);

}如图4.2所示,寄养工单覆盖预约、接单、日常养护、完成、归档及到期提醒的完整闭环。图4.2寄养工单流转时序图

Figure4.2Sequencediagramoffosterorderflow业务流始于客户线上提交诉求,店长后台审核派单。养护员按期录入体征数据。期满核对无误后标记完成并锁定归档。系统内置到期计算引擎维持履约节奏。如图4.5所示,寄养工单列表按状态展示不同颜色的标签与可执行操作按钮。图4.5PC端寄养工单界面

Figure4.5PCfosterordermanagementinterface工单表格渲染五条基线记录,横向贯穿预约、寄养中、已完成、已归档全阶段。操作列动态挂载办理入驻、完成寄养、归档与养护记录弹窗。右上角悬浮提示当前节点合规路径。状态机驱动杜绝超期未处理滞留,养护日志形成服务留痕链条。4.6数据统计模块实现月度经营复盘依赖精确的数据聚合引擎。统计服务按月切片汇总销售总额、出库单量与有效寄养单数。出库行为直接映射终端销售,取消状态工单不计入活跃产出。聚合函数按商品维度交叉核算销量峰值,提取最近N个月环比趋势数据集。报表导出模块集成ApachePOI开源包,实例化XSSFWorkbook创建双页签文档。Sheet1陈列商品销量排行并累加总销售额,Sheet2独立输出寄养业务流水明细。接口层实施MANAGER角色白名单过滤,禁止职员越权拉取财务口径数据。实测2026年9月数据呈现阶段性波动特征。本月累计产生439元营收,同步生成3笔出库凭证与3张寄养工单。拉长观测窗口至上半年,4月至7月业务流水归零。8月迎来季度高峰,销售总额突破2100元,寄养订单攀升至2单。9月回落至常规水位,销售额维持在439元,工单量微增至3单。如图4.6所示,预约统计页展示月度KPI、近6个月经营趋势与商品销量明细,并支持导出Excel。图4.6PC端预约统计界面

Figure4.6PCstatisticsinterface首屏三张核心指标卡锚定当月业绩基准。中部双轴折柱混合图表直观刻画客流与交易额的季节分布规律。底部明细网格列示TOP商品贡献度。导出按钮触发异步文件生成流程,POI自动填充公式与格式样式。店长凭借专属入口调取经营诊断依据,剔除无效噪声数据干扰决策模型。4.7小程序端实现移动端载体面向散客预约与轻量级信息查询场景。系统部署uni-app框架利用其声明式渲染特性编写通用组件,一套源码经条件编译分别输出H5调试包与微信小程序原生包。网络通信层抽象request.js模块封装uni.request方法,统一注入BASE_URL=:8080/api基础地址与前缀/api路径。鉴权令牌持久化至本地缓存pet_shop_token,拦截器自动携带Authorization头完成身份透传。公开接口如商品浏览与分类检索豁免登录校验,预约下单与订单追踪模块拦截未认证流量重定向至登录页。构建管线将vue3模板转化为wxss与wxml兼容语法,解决跨平台样式差异。如图4.7所示,小程序首页提供商品分类入口与人气商品展示,客户无需登录即可浏览。图4.7小程序首页界面

Figure4.7Miniprogramhomepage顶部品牌横幅标识爬宠之家活体耗材寄养服务定位,下方三个功能Tab分流核心业务线。商品区块采用双列瀑布流布局,头部设置爬宠活体与饲养耗材快捷通道。底部常驻导航栏固定首页、商品、订单、我的四个锚点。数据加载依赖异步轮询拉取服务端DTO对象,骨架屏掩盖首屏延迟。如图4.8所示,客户登录后可查看自己的寄养工单与状态,并对预约状态工单执行取消操作。图4.8小程序我的订单界面

Figure4.8Miniprogramorderspage登录后视图切换至个人资产中心,顶部FilterBar筛选全部待寄养寄养中已完成队列。卡片容器包裹订单编号、状态徽标、宠物画像、寄养周期、对接客户、应收费用及取消预约控件。交互链路闭合验证token有效期的续期机制与静默登出逻辑。H5预览期利用浏览器控制台模拟真机触控事件,排查视口缩放偏差与手势冲突。生产部署将产物上传至微信开发者工具进行云打包测试,确认mp-weixin产物符合上架规范。第5章系统测试5.1测试环境如表5-1所示,系统测试环境的软硬件配置与版本依赖如下。表5-1测试环境配置

Table5-1Testenvironmentconfiguration组件名称环境配置版本号端口/路径用途说明操作系统Windows11--基础运行宿主机运行时环境JDK17-Java虚拟机依赖后端服务框架SpringBoot2.7.188080(/api)RESTful接口路由与业务逻辑承载数据库系统MySQL8.0-pet_shop业务数据与日志持久化PC前端工程Vue3+ElementPlus+Vite-3000管理后台交互渲染与状态管理小程序预览端uni-appH5-17700跨端样式验证与接口联调小程序构建端mp-weixin--dist/build/mp-weixin产物编译调试工具链Chrome/Edge/微信开发者工具最新稳定版-多端兼容性验证与断点排查测试范围覆盖PC后台交互层、微信小程序端、SpringBoot后端服务群与MySQL数据层。各子系统通过HTTP协议与JDBC驱动建立通信,前后端分离架构要求接口契约严格对齐。Windows11基座统一调度端口资源,避免服务冲突。Chrome与Edge双核渲染验证消除CSS布局差异,微信开发者工具导入mp-weixin编译产物完成原生容器模拟。该环境配置复现生产部署拓扑,确保各模块在独立进程间调用稳定,数据库连接池与JDK17垃圾回收机制匹配,为全链路缺陷捕获提供确定基线。5.2功能测试如表5-2所示,核心业务场景的测试用例设计与执行结果如下。表5-2功能测试用例与结果Table5-2Functionaltestcasesandresults用例编号测试项操作步骤预期结果实际结果是否通过TC-01店长登录鉴权输入admin/admin123提交请求返回JWT令牌成功返回JWT是TC-02店员登录鉴权输入staff/staff123提交请求返回JWT令牌成功返回JWT是TC-03客户登录鉴权输13800138000提交请求会话建立成功登录成功是TC-04错误凭证拦截输入错配账号密码组合返回错误提示提示账号或密码错误是TC-05商品公开列表查询未携带Token请求商品API隐藏敏感字段返回12种商品且隐藏成本与预警阈值是TC-06商品分类检索按类别参数发起请求返回对应归类集合返回活体/耗材共6个分类是TC-07库存快照采集实时读取库存表接口返回各SKU可用数量12种商品实时库存数值准确是TC-08低库存阈值预警触发库存对比逻辑列出低于阈值明细返回4种库存不足商品(爬宠垫沙3/5等)是TC-09入库单据登记填写入库表单提交生成唯一入库编号自动生成RK单号、库存增加是TC-10出库单据登记填写出库表单提交生成唯一出库编号自动生成CK单号、库存扣减是TC-11超量出库拦截提交超出可用库存的数量阻断交易并提示不足拒绝提交、不允许负库存是TC-12历史单据多维过滤传入单据类型/商品类型/时间参数查询返回匹配流水记录按条件过滤正确是TC-13寄养预约提报客户端提交时间与选项创建工单锁定时段生成JY工单,状态BOOKED是TC-14工单状态流转限制对非BOOKED工单执行入店拦截请求并报错拦截并提示“仅预约状态工单可办理入店”是TC-15寄养履约进度推进连续执行入店/完成/归档状态单向变更BOOKED→FOSTERING→DONE→ARCHIVED成功是TC-16养护记录关联绑定提交工单专属护理日志日志与工单ID外键关联养护记录写入/查询成功,关联工单是TC-17到期提醒推送轮询比对预计离店日期返回超期未结清记录返回寄养中且即将到期工单是TC-18门店统计看板拉取管理员请求汇总数据接口返回当期核心指标summary返回12商品/4低库存/3客户/2寄养中是功能测试累计设计并执行28个用例,整体通过率维持100%。鉴权模块验证了三层级用户的身份校验逻辑,错误凭证拦截有效返回标准化业务提示。商品档案与进销存模块覆盖公开列表脱敏、分类检索、实时库存快照及低库存阈值触发机制,实测数据准确生成包含爬宠垫沙、杜比亚蟑螂、玉米蛇·成体、豹纹守宫·亚成体等4种预警商品清单。出入库流水登记自动生成唯一单据号,超量提交触发库存不足拒绝拦截,历史单据按类型、品类与时间区间的多维过滤查询返回精准子集。寄养工单状态机流转测试确认了BOOKED至FOSTERING、FOSTERING至DONE及归档状态的单向推进约束,非法中间态尝试入店被系统拦截并返回明确业务提示。其余客户侧预约、取消、注册及养护关联等用例均按预期执行,事务原子性无回滚异常。权限控制模块重点验证了角色边界与数据隔离机制。STAFF账号发起统计导出与账号管理请求时网关直接阻断返回业务码403,商品详情接口对非管理层返回costPrice为null,有效阻断越权访问路径。客户侧查询我的寄养接口严格依据手机号维度过滤,仅返回本人工单记录,杜绝横向越权窥探。月度统计接口精确聚合出本月销售总额439元、出库3单、寄养3单的报表数据,仪表盘核心指标与底层台账保持一致。全量用例执行完毕未出现空指针、数据丢失或状态死锁,核心业务闭环符合设计契约。5.3非功能测试如表5-3所示,系统多维度质量属性测试结果如下。表5-3非功能测试结果Table5-3Non-functionaltestresults测试项测试内容预期指标测试结果性能测试常规页面加载与高频CRUD接口响应<2秒页面加载与接口响应均在1秒内单机并发操作能力支持多用户同步无阻塞支持15人同时在线,接口无阻塞安全测试敏感数据存储加密库中无明文密码BCrypt加密存储,落盘为密文会话管理与身份鉴别令牌无状态且有效JWT令牌无状态鉴权,过期自动失效角色权限隔离执行越权请求返回阻断码店员请求统计/账号管理返回403生效兼容性测试PC后台多浏览器渲染布局一致无错位Chrome/Edge正常渲染,滚动条与弹窗适配小程序多端视口展示元素自适应不溢出H5预览安卓/iOS视口正常,mp-weixin产物完整易用性测试零基础人员操作路径流程直观无需复杂培训简要培训后可独立完成出入库与工单操作可维护性测试工程结构与文档完备度分层清晰、注释规范controller/service/mapper分层明确,SQL全中文注释安全与性能维度的实测数据表明系统具备生产可用性。安全机制依托BCrypt算法完成密码哈希存储,数据库落盘无明文痕迹。JWT令牌实现无状态会话管理,结合RBAC模型在应用层实施细粒度路由过滤,测试中越权请求均被前置拦截器判定终止。性能指标基于单机模拟环境采集,常规页面加载与高频CRUD接口平均响应时间压缩至1秒内,满足低于2秒的业务预期。并发层面支

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论