物流管理系统

1 系统需求分析

1.1 系统描述

物流的概念最早是在美国形成的，起源于 20 世纪 30 年代，原意为“实物分配”或“货物配送”。1963 年被引入日本，日文意思是“物的流通”。20 世纪 70 年代后，日本的“物流”一词逐渐取代了“物的流通”。中国的“物流”一词是从日文资料引进来的外来词，源于日文资料中对"Logistics"一词的翻译“物流”。

中国的物流术语标准将物流定义为：物流是物品从供应地向接收地的实体流动过程中，根据实际需要，将运输、储存、装卸搬运、包装、流通加工、配送、信息处理等功能有机结合起来实现用户要求的过程。

随着人们对物流的需求越来越大，人工乃至半自动的管理已经远远不能满足人们对物流管理中包裹跟踪、包裹派送以及员工和仓库等基础信息的管理的需求，一个功能强大的物流管理系统已经成为一个必备项。

物流管理系统应该包括公共查询部分以及后台查询部分

1.1.1 公共查询部分

任何用户，包括员工和顾客，都可以在非登录状态下查询自己的包裹信息。具体操作流程应该是：用户输入自己的手机号，点击查询按钮，系统调用验证码发送接口发送短信验证码，用户在系统中输入验证码，即可查询到所有与自己相关的包裹信息，包括包裹的基本信息以及物流情况跟踪。

为了简化操作，本系统省略了调用短信验证码的部分，用户输入手机号、点击查询按钮，直接显示查询到的结果。

1.1.2 后台查询部分

后台查询部分包括员工信息的录入和更新、仓库信息的录入和更新、包裹信息的录入和更新。

这部分内容仅供后台用户登录后使用，未登录状态会隐藏这部分功能。登录后的用户根据所属权限不同，只能使用各自的部分，例如人力资源相关的员工只能使用员工相关的功能而不能管理包裹信息。

1.2 数据存储需求

jxtxzzw 物流管理系统需要存储如下信息。

员工信息 有关物流系统员工的基本信息，包括工号、姓名、出生年月、权限、薪水等。

包裹信息 有关包裹的基本信息，包括包裹编号、寄件和收件双方的基本信息（姓名、电话、地址等）、运费、寄收件日期等。

仓库信息 有关物流仓库的基本信息，包括仓库位置、仓库管理员等。

用户登录信息 有关员工登录账号的信息，包括用户名、密码等。

物流跟踪信息 有关物流信息的更新，包括入库出库操作、操作人、所属仓库、操作日期等。

派件信息 某一给定包裹是由哪一位派件员派送的，用户对此次快递评分多少。

仓库管理员 该表列出了拥有仓库管理权限的员工，并为今后添加仓库管理员职称、师徒关系预留接口。

派件员 该表列出了拥有派件权限的员工，以及用户对他们的平均评分。

人力资源管理 该表列出了拥有人力资源部门相关权限的员工。

前台接待员 该表列出了拥有前台接待、包裹信息录入相关权限的员工。

运输员 该表列出了拥有运输权限的员工，并为今后添加运输员所属运输车队、运输车辆、车辆检修和保险情况预留接口。

1.3 系统常做的查询与更新

经常做的查询，或许对创建索引有影响的：

1.包裹信息查询，包括列出所有包裹和根据用户的筛选列出指定包裹

2.物流信息查询，包括按时间序列列出给定包裹的物流跟踪情况

根据经常做的查询，需要创建有关视图的：无。

关于更新

1.包裹信息录入的频率非常大，但是一般情况下录入后更新较少

2.物流跟踪信息录入的频率非常大，一旦录入后不允许修改和删除

3.员工信息相对稳定，本系统只涉及姓名、出生年月、薪水等信息，这些信息或者一旦确定几乎永远不会被更改、或者一般用户没有修改权限，因此只需对人力资源部门开放展示和修改权限即可

1.4 应用程序功能

1.4.1 公共查询

任何用户，包括员工和顾客，都可以在非登录状态下查询自己的包裹信息。

1.4.2 用户登录

员工可以在此登录。登录状态下访问该页面可以选择注销，或者修改密码。

预留了未来与其他系统通信的接口，例如可以访问财务管理系统导出历史 6 个月的工资和奖金。

1.4.3 单向信息更新

所谓单向信息更新，指的是快捷信息添加，且该信息只允许增加，不允许修改和删除。

派件信息 派件员可以在这个界面看到被分配给自己的、且正在派送中的信息，包括收件人地址、联系方式等，并提供一个按钮，允许派件员点击后确认送达。

物流信息 运输员可以在这个界面录入包裹的最新动态，只需给定仓库名称、包裹编号，即可在数据库中录入“包裹目前已经到达某一仓库”这一信息，系统将自动添加当前时间。

如上文所述，这些信息不具有可修改性，一旦录入就是终态，因此无需提供修改和删除功能，而之所以选择将这两个页面独立，是出于 2 方面考虑：

1.单页面应用可以很容易地部署到移动终端、例如小型嵌入式设备等，只需要极少量的信息展示和输入（甚至只需要一个按钮）无需支持复杂的交互逻辑

2.录入包裹编号可以很方便地与扫码枪结合，只需预先设置仓库名称，之后使用扫码枪扫描条形码录入包裹编号，即可自动提交并情况当前信息，实现快速、批量录入

1.4.4 完整信息更新

员工 员工信息的录入、修改和删除。录入员工信息时，必须给定员工的手机号、邮箱、出生年月、薪水等。其中，手机号必须是 11 位的数字，邮箱必须满足邮箱命名规则，薪水只能包含数字 0 到 9 和小数点且必须表示一个数值。

包裹 包裹信息的录入、修改和删除。录入包裹信息时，必须给定寄件收件双方的信息（联系方式、姓名、地址等）。其中，手机号必须是 11 位的数字，地址不得少于 10 个字，城市将提供下拉框以供选择，订单金额只能包含数字 0 到 9 和小数点且必须表示一个数值。其中，包裹信息查询页面，将嵌入物流信息查看页面。该页面包括给定包裹目前所处的状态（已揽件、运输中、派件中、已签收），并给出按时间序列排序的物流运输信息查看。

仓库 仓库信息的录入、修改和删除。录入仓库信息时，必须给定仓库所在地、仓库名称、仓库负责人名称。其中，城市将提供下拉框以供选择，仓库负责人将提供下拉框以供选择。

2 数据库概念设计

2.1 确定实体和属性

分析物流管理系统的管理需求，将系统中涉及到的人、包裹、仓库进行抽象，得到了系统的实体如下：

1.派件员实体集。属性包括：派件员员工工号、派件员平均得分

2.派件信息实体集。属性包括：包裹编号、派件员员工工号、顾客对这一次派件的评分

3.员工实体集。属性包括：员工工号、姓名、手机号、出生日期、薪水

4.人力资源实体集。属性包括：员工工号

5.城市实体集。属性包括：城市名称、上级城市名称

6.登录信息实体集。属性包括：邮箱、密码、员工工号

7.包裹接待员信息实体集。属性包括：包裹编号、接待员员工工号

8.包裹实体集。属性包括：包裹编号、寄件人姓名、寄件人联系方式、寄件人地址、寄件人所在城市、寄件日期、收件人姓名、收件人联系方式、收件人地址、收件人城市、收件日期、运费、运费是否已经支付、包裹状态

9.前台接待员实体集。属性包括：员工工号

10.物流信息实体集。属性包括：出入库操作、操作日期、操作员员工工号、仓库编号、包裹编号

11.运输员实体集。属性包括：员工工号

12.仓库管理员实体集。属性包括：员工工号

13.仓库实体集。属性包括：仓库编号、仓库名称、仓库所在城市、仓库管理员员工号

2.2E-R 图

总览 总览如图。

图 1:ER 图总览

员工角色相关如图 2 表示员工及所属部门的 E-R 图，其中 Employees 为员工信息表，其余各表分别表示不同的职能，当员工属于某一部门时，信息将添加到对应表中，这些表采用了员工工号作为外键约束。

图 2:员工角色相关 E-R 图

仓储 如图 3 表示仓库管理员及所管理仓库的 E-R 图。

图 3:仓储 E-R 图

包裹及物流 如图 4 表示包裹信息、寄件和收件所在城市、物流信息跟踪（按时间序列的各城市仓库周转历史）的 E-R 图。

图 4:包裹及物流 E-R 图

派件 如图 5 表示包裹派件的 E-R 图，包括包裹由哪一个派件员派送、这一次派送的用户评分、派件员基础信息及平均得分等。

图 5:派件 E-R 图

包裹与前台接待 如图 6 表示包裹与前台接待的 E-R 图。

图 6:包裹与前台接待 E-R 图

3 数据库逻辑结构设计

3.1 关系模式设计

根据概念结构设计得到的 E-R 图和转换规则，得到如下关系模式 5：

Dispatchers 表(自增编号、员工工号 6、派件员平均得分、记录添加时间、记录最后一次修改时间)

DispatchPairs 表(自增编号、包裹编号 7、员工工号 8、顾客对这一次派件的评分、记录添加时间、记录最后一次修改时间)

Employees 表(员工工号、姓名、手机号、出生日期、薪水、记录添加时间、记录最后一次修改时间)

HumanResources 表(自增编号、员工工号 9、记录添加时间、记录最后一次修改时间)

Locations 表(城市名称、上级城市名称 10、记录添加时间、记录最后一次修改时间)

Members 表(自增编号、邮箱、密码、员工工号 11、记录添加时间、记录最后一次修改时间)

PackageReceptionists 表(自增编号、员工工号 12、包裹编号 13、记录添加时间、记录最后一次修改时间)

Packages 表(包裹编号、寄件人姓名、寄件人联系方式、寄件人地址、寄件人所在城市 14、寄件日期、收件人姓名、收件人联系方式、收件人地址、收件人城市 15、收件日期、运费、运费是否已经支付、包裹状态、记录添加时间、记录最后一次修改时间)

Receptionists 表(自增编号、员工工号 16、记录添加时间、记录最后一次修改时间)

Trackings 表(自增编号、出入库操作、员工工号 17、包裹编号 18、仓库编号 19、记录添加时间、记录最后一次修改时间)

Transports 表(自增编号、员工工号 20、记录添加时间、记录最后一次修改时间)

WareHouseManagers 表(自增编号、员工工号 21、记录添加时间、记录最后一次修改时间)

WareHouses 表(仓库编号、仓库名称、仓库所在城市 22、仓库管理员 23、记录添加时间、记录最后一次修改时间)

3.2 基本表设计

基本表设计如下所示。

表 1:Dispatchers

表 2:DispatchPairs

表 3:Employees

表 4:HumanResources

表 5:Locations

表 6:Members

表 7:PackageReceptionists

表 8:Packages

表 9:Receptionists

表 10:Trackings

表 11:Transports

表 12:WareHouseManagers

表 13:WareHouses

以上各表另有 2 个字段，表示每条记录新建的时间和最后修改的时间，如表 14 所示。

表 14:额外信息记录

4 数据库物理设计和实施

4.1 数据库的创建

使用 MariaDB10.3.14，数据库基本信息如下：

服务器类型：MariaDB

服务器版本：10.3.14-MariaDB-log-Sourcedistribution

协议版本：10

数据库客户端版本：libmysql-mysqlnd5.0.12-dev-20150407

服务器字符集：UTF-8Unicode(utf8)

4.2 创建基本表

基本表的创建使用 ORM 模型 实现。但是这里仍将给出创建每个基本表的 SQLDDL 语句。

4.3 触发器设计

触发器设计采用 ORM 模型，这里将给出 ORM 模型定义中与触发器相关的部分。

Employees.afterCreate(Async (employee) => {await Members.create({ email: employee.uuid + '@zzw.mock.com', uuid: employee.uuid, password: MD5_SUFFIX.OUTER + md5(MD5_SUFFIX.INNER + employee.phone.toString().substr(7)) }) }) Employees.beforeDestroy(async (employee) => { await Members.destroy({ where: { uuid: employee.uuid } }) })

例如上面这段代码，在添加新员工的时候，自动触发将员工信息添加到登录信息表。登录信息表中的密码默认采用员工手机号后 4 位、邮箱采用员工工号加企业域名组合、员工工号采用员工信息表中的工号。

4.4 存储过程设计

本系统涉及到较多的存储过程逻辑，这里只展示部分，完整内容可参看源码。存储过程设计采用 ORM 模型，这里将给出 ORM 模型定义中与存储过程相关的部分。

当前录入的物流信息中仓库所在城市与收件人地址所在城市相同时，自动将包裹状态更新为派件中，并随机从派件员列表中找出一位派件员指派派送该包裹

const params = request.body await WareHouses.findOne({ where: { warehouse_name: params.warehouse_name }, attributes: ['warehouse_id'] }).then(async warehouse = >{ const warehouse_id = warehouse.get('warehouse_id') await Trackings.create({ action: params.action, date: Date.now(), package_id: params.package_id, warehouse_id: warehouse_id, transport_id: request.user.uuid }).then(async() = >{ await Packages.update({ status: ' 运输中' }, { where: { package_id: params.package_id } }) // 只要有物流信息了，就自动进入运输中这一状态 .then(async() = >{ await Packages.findOne({ where: { package_id: params.package_id }, attributes: ['receiver_city'] }).then(async city1Project = >{ const city1 = city1Project.get('receiver_city') await WareHouses.findOne({ where: { warehouse_id: warehouse_id }, attributes: ['location'] }).then(async city2Project = >{ const city2 = city2Project.get('location') if (city1 === city2) { await Packages.update({ status: ' 派件中' }, { where: { package_id: params.package_id } }) // 如果当前城市和收件人城市相同，则进入派件状态 const Dispatchers = orm.import('../database/models/Dispatchers') await Dispatchers.count().then(async count = >{ const rand = Math.floor(Math.random() * count) await Dispatchers.findOne({ offset: rand }).then(async randomProject = >{ // 随机一个派件员 const randomUUID = randomProject.get('uuid') const DispatchPairs = orm.import('../database/models/DispatchPairs') await DispatchPairs.create({ package_id: params.package_id, uuid: randomUUID }) // 加入派件信息表 .then(() = >{ response.sendStatus(200) }) }) }) } else { response.sendStatus(200) } }) }) }) }, () = >{ response.sendStatus(403) }) })

5 应用程序设计

5.1 开发及运行环境介绍

5.1.1 技术栈前端

1.Node.js

2.Vue.js

3.Electron.js

4.iView

后端

1.Node.js

2.Express.js

3.Sequelize

5.1.2 数据库初始方式

有 3 种方式进行数据库初始化：

1.直接运行程序，使用我的服务器上的数据库进行演示

2.修改/server/database/util.js 的配置信息为你自己的数据库地址、用户名、密码，然后导入我提供的 SQL 数据

3.修改/server/database/util.js 的配置信息为你自己的数据库地址、用户名、密码，运行 npmruninit-database 命令，系统将自动初始化数据库，并新建初始超级管理员

5.1.3 运行方式

首先需要安装 Node.js 和 npm。

然后下载源码，在源码根目录下运行 npminstall，将自动下载并安装依赖。

最后运行 npmrunrun 启动程序。也可以通过分别运行 npmrunserver 和 npmrundev 启动后端和前端。

5.2 主要功能设计

这里展现各个功能的演示画面和部分代码，完整代码过于冗长不便展示，可以通过阅读源码的方式了解全部逻辑。

5.2.1 公共查询

该页面提供一个输入框，允许用户输入手机号进行查询。点击查询按钮之后，系统将从数据库找出寄件人联系方式或收件人联系方式为该手机号的所有包裹，并罗列包裹的基本信息、包裹所处状态、物流跟踪信息等。

图 7:公共查询

对于已签收的包裹还会给出一个评价按钮，用户点击该按钮后，可对这一次配送进行评分，评分提交后会保存进数据库，并自动计算和更新该派件员的平均得分。

图 8:用户评分

部分代码如下：

5.2.2 登录

该页面根据用户是否登录有不同的展示。当用户未登录时，页面提供用户名输入框和密码输入框，用户输入后点击登录按钮，系统将请求发送到后端，后端返回登录成功或失败。

图 9:用户登录

当登录失败时，弹出消息框，说明用户名或密码错误，用户可关闭消息框后再次登录，若登录成功，将展示个人信息页面，包括修改密码等功能。

图 10:用户登录失败

图 11:用户登录成功

5.2.3 派件信息

该页面仅在员工登录后可见。系统会从数据库搜索出被分配给本人派送的且还在派送状态的所有包裹，并以表格的形式展示，展示的数据隐藏了无关信息，只保留寄件收件双方的必要联系信息。

在表格的每一行还提供一个确认签收的按钮，派件员点击该按钮后，会将该包裹标记为已送达，表格中不再显示这条记录。

图 12:派件信息查看

部分代码：

5.2.4 物流跟踪

该页面仅在员工登录后可见。

该页面提供 2 个下拉框和 1 个输入框，分别需要选择出入库操作和所在仓库名称，选择完成后输入包裹编号并提交，系统会将对包裹的这一次操作保存到数据库中，并绑定当前操作时间。

图 13:运输状态录入

5.2.5 员工信息维护

该页面仅登录后可见。用户登录后将首先看到以表格的形式展示的所有员工的信息。

表格项目过多时，提供分页功能，表格每一行提供修改和删除按钮，分别进行修改和删除操作，表格顶部提供新增按钮点击可添加新员工的信息，点击新增或修改按钮后将进入员工信息的维护页面。

图 14:员工信息

维护页面包括一个表单，填写表单中各个项目后点击提交。该页面在新增员工时，表单各个项目为空。在修改员工信息时，表单各个项目的初始值为数据库中该员工的已有信息。

用户输入时和点击提交按钮后都会触发校验器，校验输入的信息是否正确。

图 15:员工信息维护

特别的，在修改员工信息的页面，同时提供了一个重置密码的选项，点击该按钮后，后端会随机生成一个密码，并重置该员工的密码。重置成功后，新密码会以邮件的形式发送到员工的邮箱。除本人外不再有其他人知道密码，是出于安全考虑。

图 16:重置密码

这些页面同时支持搜索。

图 17:搜索

5.2.6 包裹

该页面仅登录后可见。该页面与员工页面类似。

图 18:包裹页面

同时给出物流跟踪信息查看，给定一个包裹编号，将会展示包裹的物流变化情况。展示内容包括 2 部分，第 1 部分是包裹所属状态，状态以进度条的方式展示，第 2 部分展示包裹于何时到达何地，以时间轴的方式展示。

图 19:物流跟踪

5.2.7 仓库

该页面仅登录后可见。该页面与员工页面类似。

5.3 主要界面

图 20:主要界面

5.4 前后端通信

我的系统采用了前后端分离的方法，因此，需要有一个方法能够在前端和后端各自判断用户身份，以及做好权限跳转。

5.4.1 前端路由

前端路由采用 vue-router 和 axios，前端数据存放采用 vuex。当用户访问的页面需要登录后可见，那么会发送一个请求给后端，请求包括“跳转自”

页面和“跳转到”页面，即 from 和 to2 个信息，后端根据用户判断是否有权限访问对应页面，并返回结果。

当用户登录成功时，会自动将 Token 信息保存，当用户点击注销按钮后，或前端路由收到 401 响应时，会清空 Token 信息。

5.4.2 拦截器

请求拦截器 对于每一个发往后端的请求，都拦截下来，强制添加一个 Authorization 头部。包括用户登录成功后保存的 BearerToken，如果用户没有登录，则该字段为空。

响应拦截器对于后端发往前端的所有响应，全部拦截下来，拦截器会检查状态是否成功。

对于成功的状态（200），拦截器放行；对于未授权的状态（401），拦截器跳转到登录页面；对于已授权但权限不够的状态（403），拦截器弹出错误信息；对于其他状态（406 或者 50X），拦截器抛出异常。

5.4.3 后端路由

使用 ExpressRouter 进行路由中间件处理。

后端路由的工作流程是，收到请求时，请求会逐层、依次通过每一层中间件，当前层按照当前的逻辑处理完成后，将请求和当前层处理的结果一传递给下一层。

5.4.4 使用 JWT 进行身份验证

JWT 定义了加盐字符串以及无需经过校验的公共 API。

所有请求过来都会进行身份验证，只有通过了 JWT 校验的请求才会继续发往下一层，否则，JWT 中间件会返回 401。

通过 JWT 校验之后，依次通过其他中间件，最后进行错误处理。

5.5 后端其他

5.5.1 后端初始化

后端初始化过程首先定义了与跨域相关的头部，随后注册了后端路由。

5.5.2 数据库初始化

数据库的初始化，提供了一个初始化角本，按照数据表的依赖关系，强制删除和重建数据表，并录入初始的城市信息和超级管理员帐号，初始化时会对超级管理员授予所有权限。

5.5.3 异步请求

所有异步相关的代码都加了 async 和 await。

5.5.4 检查 Token

对于给定的 API，如果需要用户授权，则使用 JWT 解码，然后取出 UUID，并判断 Token 是否过期。

5.5.5 安全性

密码用了 MD5 加密，加密前和加密后都添加了前缀用以混淆。

5.5.6 权限

API 接口与数据库交互前都做了权限判断。

5.6 用户体验优化

我做了大量的优化用户体验的工作，以下仅列出部分：

1.成功就不要弹出 Modal 让用户再点一次，只要 Message 就好，失败必须弹出 Modal 手动确认

2.表单必须在用户输入的同时就 oninputvalidate，不要发到后台校验失败了再弹错误

3.有校验没有通过的表单就不给提交

4.表单提交失败不能清空表单

5.当页面上某一元素变化，不刷新整个页面，只要局部刷新

6.401 错误直接重定向到登录页面

7.新增一条记录成功之后返回前一页

8.点击遮罩层可以取消，点击 ESC 可以取消，不必一定点取消按钮或者右上角叉叉

9.下拉框可以搜索，例如城市页面或者仓库选择页面，用户可以直接输入关键字进行全文搜索

10.查询订单不用新开一个页面，直接当前页面批量 Render，且支持收起和展开 11.最后一个输入框中按下回车，等效于触发 PrimaryButton,除此而外还做了很多优化用户体验的工作，细说之下可能又是一篇报告，这里仅列出 injectreload 代替全局刷新的部分代码。

Vue 中刷新页面的方法有很多，但是用户体验都不太好，如下：

1.this.$router.go(0)，页面会一瞬间的白屏，体验不是很好

局部刷新可以用 provide/inject 组合。原理是允许一个祖先组件向其所有子孙后代注入一个依赖，不论组件层次有多深，并在起上下游关系成立的时间里始终生效。在 App.vue 声明 reload 方法，控制 router-view 的显示或隐藏，从而控制页面的再次加载。

在需要用到刷新的页面。在页面注入 App.vue 组件提供的 reload 依赖，在逻辑完成之后直接 this.reload()调用，即可刷新当前页面。

♻️ 资源

大小：2.25MB

➡️资源下载：https://download.csdn.net/download/s1t16/87404248

注：更多内容可关注微信公众号【神仙别闹】，如当前文章或代码侵犯了您的权益，请私信作者删除！