# wms系统文档 **Repository Path**: nieps/wms-system-documentation ## Basic Information - **Project Name**: wms系统文档 - **Description**: wms系统文档 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 1 - **Created**: 2025-08-05 - **Last Updated**: 2025-12-06 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # WMS系统 面试问题： * 软件开发流程是什么？ > * 项目中有几个人开发？ > 3~4人 > > 后端： 最少2人 我们也写中后台 理想：1+1+2 高级开人员+中级+初级 > > 前端：app 小程序 h5 (混合开发) uniapp 1~2人 > > 测试人员 > > UI设计师、美工 > > 技术架构：一般指后端 > > 产品经理： 根据客户需求设计原型 （原型工具： axure | 墨刀） > > 技术经理（高级开发人员） > > 项目经理（协调客户与开发人员 ） * 你做为开发人员，与测试人员、产品经历有什么矛盾没有？如何解决 ## 项目管理工具 1. 早期项目管理 计划进度表 > 如到货登记： 开发时间 自己预估的时间上\* 1.5/2/3 > > 数据库设计：2h > > 接口实现：3h > > 页面排版：2h > > 绑定接口实现交互：3h > > 10h*1.5 = 15h===2个工作日 > > 开发时间： > > * 需求分析时间 很长 2个月 > * 开发时间 1 个月 > * 测试 修复bug 1~2个月 2. 项目管理工具 > * jira > * teambition > * 禅道 http://192.168.20.72:8088/zentao/user-login.html admin/Admin1357 > > 云项目管理： > > * 阿里云 > * 腾讯 https://coding.net/company/about ## 仓储作业 ![img](assets/640.webp) ## OMS 跨境ERP ## WMS WMS，也就是仓库管理系统，堪称仓库管理的“大脑”。它的**核心使命是帮助企业高效管理仓库库存，确保商品从入库到出库的每个环节都井然有序**。 ![image-20250806145817917](assets/image-20250806145817917.png) ## 数据库设计 一般表中要有常用字段： * 创建时间 createTime * 创建人 createUserId * 更新时间 updateTime * 更新人 updateUserId * 逻辑删除 isdel 0未删除 1已删除 ## 系统设置 * 类别表 id 名称 上级id 排序 * 产品 类别id > 设计冗余字段： 类别名称 * 库管： 库管员 登录手机号 常用字段 状态 密码（初始密码） 难点： 授权时 库官对应---（仓库/库区） > 第三方表： 库管仓库表 : 库管人员id 库区编码 > > A001-001 ## 到货管理 * 到货登记单 * 到货登记明细 ## 入库任务单 * 入库单 * 入库明细 ## 数据库账号 ~~~mysql #创建数据库 create database wms; #创建账号 create user 'wms2'@'%' identified by '1357'; #授权 grant all privileges on wms.* to 'wms2'@'%'; #提交 commit; ~~~ ## 类别 > id name cid > > 1 苹果 3 > > 2 香蕉 3 id=1的是水果 ----该类别有一个父类 水果类 1 编码： > 10 家用电器 > > > 1001 电视 > > > > > 100101 游戏电视 > > > > > > ..... > > > > 1002 空调 > > > > .... > > 11 手机 > > 12 家具 > id 名称 类别编码 > > 1 xxx 100101 > > 2 bxxx 100101 10% 物料的编码： 类别编码+物料序号 1001001 1001002 ## 物料 管理 * 新增物料 区分类别 编码建议自动生成 （1001） > 查询类别1001下有没有物料，如果没有 第一个物料的编码 10010001 > > 如果有如1001003 ----新编码在些基础上加1 * 查询物料 必传条件：类型 是产品还是商品 分页显示 * 更新功能 * 删除功能 * 设置库存 必传物料 id , 根据id查询物料库存表中是否有记录，如果没有，插入库存 ，如果有 直接更新 ## 8月7日 * 自动触发 > 1. 保存 > > 2. 查询 > > > 返回的数据 ： > > > > 1. 返回 数组 > > > > ~~~json > > [ > > {type:1,categoryCodes:[]}, > > {type:2,categoryCodes:[]}, > > ] > > ~~~ > > > > > > * 分页 > * 动态编码 > 1. 如果父id是0 说明添加的是一级编码 > > > 逻辑： > > > > 1. 先查询父id为0的 最大编码 ，如果不存在，编码默认是10 ，如果存在（假如是16,新的编码17），在已有编码的基础上加1 > > 2. 如果父id不为0，假如为1 > > > 逻辑： 查询 父id为1的最大编码 ，如果不存在 （查询id=1的编码如10）,则第一个子类的编码 1001 ; 如果存在，现有的编码基础上加1 ### 编码规则 前缀+日期+序号 按日归零： > DH20250808001 ...002 ... > > 明天 ：DH20250809001 按月归零： > DH202508001 按年归零： > DH2025001 ## 8月11号 ### 采购 采购单、采购明细 正常应该在scm供应链系统 （另外一个服务器的接口） 接口： * 采购单列表 （采购日期倒序排序 ）分页 多条件 * 采购单详情 * 新增采购单（接口） 不用写页面，模拟能过接口添加数据 ### 编码：前缀+日期+序号 CG25001 默认将最大编码存储内存中。 产生新的编码： 1. 判断内存中是否有最大编码，如果没有 查询，存储到内存中 2. 获取系统年份 判断年份与最大编码是否是同一年，如果是同一年 序号+1 3. 如果不是同一年，直接根据年份产生新的编码 ### 质检 在到货记录----增加按钮（质检） ，点击质检 -----质检列表 ，填写 ![image-20250811151844552](assets/image-20250811151844552.png) 质检日期 * 保存质检 结果 ### 出库 有共同的属性，也有不同的属性，设计方案： * 主表+子表实现 > 主表：设计共有的字段 > > 子表：设计 个性字段 * json 格式 > 存储不同的字段 extrea_info json > > * {"purchaseCode":"cg001", "supplier":"sss"} > * {"warmarea":"aa", "num":100} 方案： * 出库单 主表+子表 1+4 * 出库单明细 1张表 + 个性字段 用 json格式 存 ## 8月12号 ![image-20250812095444382](assets/image-20250812095444382.png) 实现入库单列表如下入库物品描述： * 在入库单表 增加一个字段 入库物品（根据明细按照上面的规则 拼接成字符串） * 如果前期没有增加 对应字段 也可以查 ~~~sql select t.id,t.arrivalCode,t.purchaseCode,t.supplier,(select GROUP_CONCAT(CONCAT(d.productName,'(',d.spec,')X',d.inNum,d.unit) SEPARATOR ';') from b_stock_in_task_detail d where d.taskId=t.id) '物品' from b_stock_in_task t ; #使用视图简化 select t.id,t.arrivalCode,t.purchaseCode,t.supplier,s.note from b_stock_in_task t JOIN v_stock s on t.id=s.taskId ; #mysql字符串函数 concat select CONCAT(d.productName,'(',d.spec,')X',d.inNum,d.unit) from b_stock_in_task_detail d where d.id=1; #根据任务id查询 select CONCAT(d.productName,'(',d.spec,')X',d.inNum,d.unit) from b_stock_in_task_detail d where d.taskId=1; #用group_concat 合并多行 多行 之间用，隔开 select GROUP_CONCAT( d.productName) from b_stock_in_task_detail d where d.taskId=1; #指定分隔符 select GROUP_CONCAT( d.productName SEPARATOR ';') from b_stock_in_task_detail d where d.taskId=1; #嵌套函数 select d.taskId,GROUP_CONCAT(CONCAT(d.productName,'(',d.spec,')X',d.inNum,d.unit) SEPARATOR ';') from b_stock_in_task_detail d GROUP BY d.taskId; #视图view 虚拟表 create view v_stock as select d.taskId,GROUP_CONCAT(CONCAT(d.productName,'(',d.spec,')X',d.inNum,d.unit) SEPARATOR ';') as note from b_stock_in_task_detail d GROUP BY d.taskId; ~~~ ### 报表下载 * 定时任务 spring task 在指定 时间内执行任务 * 任务是 ： 查询最近7天的 出库明细 ，然后导出为excel EasyExcel ,将excel文件存储到服务器 ，然后将服务器地址 存储到表中 > 难点： > > 最近7天怎么查？ > > 用到日期函数： > > ~~~sql > #现在购买一个月会员 用户表中有一个字段：会员到期日 > > select CURRENT_DATE(),DATE_ADD(CURRENT_DATE(),INTERVAL 1 MONTH); > > #查最近7天 > select CURRENT_DATE,DATE_SUB(CURRENT_DATE,INTERVAL 6 DAY); > ~~~ > > CDZC-A-U-... ## 8月13号 库存盘点： * 由盘点人员 核实实际商品数量与 库存数量 > 苹果： 10 > > 盘点结果： > > * 10 个 正常 > * 12 个 盘赢 ----> 盘赢入库 2 ---12 > * 8个 盘亏 ------> 盘亏出库2 ---8 ## 8.14号 ### 批次管理 当到货时，同一批物料 是同一个批次号，保存到货单和到货明细后（假如有5条明细），在批次管理中批量插入数据（5条 对应5条物料 ）：批次号相同 供应商id 物料 发现没有值： 生产日期 质检状态 入库时间 * 质检状态 到货质检修改状态 * 生产日期 入库时填写日期 * 入库时间 入库时填写 入库时： 更新批次里生产日期 入库时间 ，同时 在物料库区库存表 插入记录 ，不要忘记更新 物料库存表（库存数量 可用数量 +） ## 8月19号 路由的两个函数： * useRouter 返回的路由实例 用于跳转 * useRoute 返回路由参数 > ![image-20250819113314919](assets/image-20250819113314919.png) > > push方法： ~~~javascript // 字符串 router.push('home') // 对象 router.push({ path: 'home' }) // 命名的路由 router.push({ name: 'user', params: { userId: '123' }}) // 带查询参数，变成 /register?plan=private router.push({ path: 'register', query: { plan: 'private' }}) ~~~ ### 新增到货单 * 保存到货单 自动生成到货单编码 * 保存到货明细 * 保存对应明细 待 质检信息 * 生产批次号 * 调用采购入库任务单接口 ，生成入库任务单 ## 8.20 到货单： * 到货状态 1 未到货 2 部分到货 3 全部到货 ### 入库 * 批量入库 > 遍历入库任务明细： > > 一个物料入库： > > 1. 根据批次号和物料id 更新批次表：生产日期 供应商 入库时间 > 2. 在物料库区库存表中 插入 批次id（决定唯一 的批次号和物料id） 库存数量 可用数量 冻结数量 > 3. 更新物料 库存表 库存数量 可用数量 * 单个物料 入库 ## 8月21 到货质检： * 查询质检列表 （根据到货单id查询 ） * 保存 更新质检信息 * 上传质检报告 （在到货质检结果 表中记录下来） 针对到货单 * 保存评论 ---（根据质检id 查询 如果存在评论更新 不存在新增） ### 移动端 采购入库： * 查询采购入库任务单 返回未完全入库的 > ![image-20250821161658741](assets/image-20250821161658741.png) > > 返回：供应商id 入库任务单id * 根据任务id查询明细 （未完全入库的） * 单个商品入库 A001-01-02 ### css定位 position定位： * absolute 绝对 定位 * fixed 固定位置 * relative 相对定位 | 定位方式 | 是否占空间 | 定位基准 | 适用场景 | | ---------- | ---------- | ---------------- | ------------------------------ | | `relative` | 是 | 自身原有位置 | 微调元素位置、作为绝对定位容器 | | `absolute` | 否 | 最近的已定位祖先 | 相对于父元素精确定位 | | `fixed` | 否 | 浏览器视口 | 固定导航、悬浮按钮等 | ## 8月25 主表+子表+明细表 > 主表和子表：一对一 共用主键 （任务单） > > 任务单----明细： 一对多 > > 明细----出库记录： 一对多 出库任务单： * 新增 > 1. 保存任务单 （主+子 表 ） > > 2. 保存任务明细 > > 3. 是否要冻结库存 > > > 与出库明细对应： > > > > 明细A： ---（根据出库原则冻结FIFO）-- 将指定的批量 数量冻结 （记录冻结 记录 出库是根据冻结记录直接出库） > > > > ​ ----总的物料库存 冻结 * 查看 列表 * 查看详情 把表格梳理一 遍，所有涉及到物料信息时都要物料id ## 8月26 调拨： * 调拨记录 （发起了申请 ） > 1. 调拨单 记录 涉及的仓库及操作人 相关信息 > 2. 调拨明细 记录调拨的商品及数量 * 审批 > 1. 记录审批结果 > > 2. 审核通过后 > > > 1. 生成调拨出库任务单 库存数量的冻结等相信息 -----办理出库 > > 2. 生成调拨入库任务单 ----收货 ------办理入库 * 调拨单列表 多条件 分页 一个接口 * 调拨单详情 * 删除 逻辑删除 无法查看 * 关闭 不需要审核 但能查看 调拨操作记录表： 1 制单 2 审核 3 调出 4 调入 5取消 ## Token 常用种认证方式： * **Basic Auth** 基础认证 每次请求携带用户名和密码 （很少用） * Cookie认证 （会话技术： session 服务器端会话 cookie是客户端会话） （不用） > 最早jsp时代： > > * 登录 保存登录人的信息 > * 购物车 * token 认证 令牌 通俗理解：就是一个特殊的 加密过的 字符串 （解密），里面包含用户相关的信息 （常用） * oauth2 授权认证 搭建平台用的 token: 用户id 用户名 角色 权限 部门 岗位 ## 盘点 * 按货架盘点 * 按物品盘点 > 要求都要生成盘点任务、盘点明细 盘点任务（按区）： * 按任务id查询 盘点任务涉及到的库区 （taskid type=1） * 按任务id 库区id 查询任务中涉及到的货位 (taskid type=2 库区id=当前库区) * 按任务id 货位id 查询要盘点的物料 * 列表展示： 按任务id查询所有的 物料 保存盘点任务： * 保存任务单 * 保存明细 > 1. 遍历库区 > > > 在库区的基础上 ，遍历对应的货位 > > > > > 查询该货位下的物料 ## 调拨单 * 调拨单----一对多-----调拨明细 * 审核 > 调拨出库任务单------多条明细--------锁定库存（对应库区 货位 哪些批次---对应批次的数量） > > > 原仓库管理人员： -----办理出库 ----扣减库存 > > 调拨入库任务单------多条明细 ### 调拨入库单 * 新增 > 1. 调拨单 > 2. 调拨明细 * 列表 多条件 分页 * 入库单收货 > 1. 如果收货数量与调拨数量 一致 更改收货状态 为已收货 > 2. 如果收货数量小于调拨数量 更改收货状态 为部分收货 > 3. 如果收货数量大于调拨数量 提示收货失败---数量不对 * 调入处理列表 罗列具体的调拨明细 * 导出 * 业务处理 > 1. 5种处理类型，要求根据不同的处理类型，实现不同的处理结果 > 2. 记录处理日志 * 根据入库明细 查询 处理日志记录 测试： ​ 调拨单：id=3 ​ 调拨明细：2条 > 1. ​ 物料id=2 数量10----- 物料库存 冻结数量0----10 可用数量 100---90 批次p2508001 够了 可用数量变为0 > > 2. ​ 物料id=3 数量5 ------ 物料库存 冻结数量0----20 可用数量 200---180 > > 批次p2508001 ---扣减10个 > > ​ 批次p2508002 ---扣减10个 ## Vue3打印 在 Vue3 项目中，实现打印功能常用的插件有`vue3-print-nb`和`print-js`。下面分别介绍这两个插件的使用方法： ### 1. vue3-print-nb 这是一个专为 Vue3 设计的打印插件，使用简单，支持局部打印。 **安装：** ```bash pnpm add vue3-print-nb ``` **全局注册（main.js）：** ```javascript import { createApp } from 'vue' import App from './App.vue' import print from 'vue3-print-nb' const app = createApp(App) app.use(print) app.mount('#app') ``` **组件中使用：** ```vue ``` ### 2. print-js 这是一个更通用的打印库，不仅支持 Vue，还支持其他框架。 **安装：** ```bash pnpm add print-js ``` **组件中使用：** ~~~vue ~~~ 选择建议 - 如果只需要简单的局部打印功能，`vue3-print-nb` 更适合 Vue3 项目，使用更简洁 - 如果需要打印 PDF、图片等多种类型，或者需要更丰富的配置选项，`print-js` 功能更全面 # 前端 > 现有的中后台，若依 ## 准备 ~~~shell #安装pnpm npm install -g pnpm #查看帮助 pnpm --help #安装依赖 pnpm i #install #运行 pnpm dev ~~~ ## `husky` 是什么？可以删除 `husky` 提交前校验吗？如何彻底删除？ - `husky` 是什么？ 答：[官方文档(opens new window)](https://typicode.github.io/husky/#/) - 可以删除 `husky` 提交前校验吗？ 答：如果您们提交代码不需要严格的提交前校验，这当然可以删除 - 如何彻底删除？ ① 删除根目录 `.husky` 文件夹以及里面所有文件 ② 删除根目录 `commitlint.config.js` 文件 ③ 来到 `package.json` 下的 `devDependencies` ，删除 `@commitlint/cli` 、 `@commitlint/config-conventional` 、 `@commitlint/types` 、 `husky` 、 `lint-staged` 这些依赖 ④ 最后来到 `package.json` 下的 `scripts` ，删除 `"prepare": "husky"` 命令即可 ## 关闭eslint代码检查 找到eslint.config.js文件，增加如下： ![image-20250819101310389](assets/image-20250819101310389.png) # 移动端 ## 准备 ~~~shell #创建工程 pnpm create vue@latest #创建后 安装依赖 pnpm i #运行 pnpm dev ~~~ ## 编写移动的问题？ 如何适应移动端的屏幕大小 ？ ### 单位 > 微信小程序：rpx * rem 相对单位 相对于根元素字体大小 > html font-size:100px 1rem=100px * em 用的相对少 相对于父元素大小 设置的 ### 换算 页面设计：750稿 750px ---7.5rem 核心js: #### 参考一 ~~~javascript (function(doc, win) { var docEl = doc.documentElement, resizeEvt = 'orientationchange' in window ? 'orientationchange' : 'resize', recalc = function() { var clientWidth = docEl.clientWidth; if (!clientWidth) return; if (clientWidth >= 750) { docEl.style.fontSize = '100px'; } else { docEl.style.fontSize = 100 * (clientWidth / 750) + 'px'; } }; if (!doc.addEventListener) return; win.addEventListener(resizeEvt, recalc, false); doc.addEventListener('DOMContentLoaded', recalc, false); })(document, window); ~~~ #### 参考二 ~~~javascript (function(w, d) { function setSize() { var screenWidth = d.documentElement.clientWidth; var currentFontSize = screenWidth * 100 / 750; // 750 是设计稿的宽度 d.documentElement.style.fontSize = currentFontSize + 'px'; } w.addEventListener('resize', setSize); w.addEventListener('pageshow', setSize); w.addEventListener('DOMContentLoaded', setSize); })(window, document); ~~~ ### UI [Vant](https://develop365.gitlab.io/vant/zh-CN/home/) ~~~shell #安装依赖 pnpm add vant ~~~ 在main.js引入公共样式： ~~~javascript // 引入vant组件样式 import 'vant/lib/index.css'; ~~~ 按需引入： ~~~vue import { showToast } from 'vant'; ~~~ # 知识参考 ## WMS常见术语 以下是常见的 **WMS（仓储管理系统）术语** 及其解释，涵盖业务流程、功能模块、技术应用等维度，帮助你快速理解仓储管理领域的核心概念： ### **一、基础概念类** 1. **仓储管理系统（WMS，Warehouse Management System）** - 用于管理仓库日常操作（如入库、出库、库存管理、拣货、盘点等）的软件系统，通过优化流程提高仓储效率和准确性。 2. **仓库（Warehouse）** - 用于存储、保管货物的场所，可分为原材料仓、成品仓、中转仓等类型。 3. **库存（Inventory）** - 仓库中所有物料、半成品、成品的总和，包括在途库存、在制品库存等状态。 4. **SKU（Stock Keeping Unit）** - 库存保有单位，用于唯一标识一种商品或物料（如某品牌某规格的洗发水）。 5. **BOM（Bill of Materials）** - 物料清单，记录产品所需零部件、原材料及其数量的结构表，常用于生产型仓储的领料管理。 ### **二、业务流程与操作术语** 1. **入库（Receiving/Inbound）** - 货物从供应商或外部运输到仓库并完成验收、上架的过程，包括采购入库、退货入库、调拨入库等。 2. **出库（Shipping/Outbound）** - 货物从仓库发出的过程，包括销售出库、生产领料、调拨出库、报废出库等。 3. **拣货（Picking）** - 根据订单需求从存储区域提取货物的操作，常见方式包括： - **单品拣货**：按单个 SKU 拣选。 - **批量拣货**：一次拣选多个订单的同类货物，再分拣至各订单。 - **波次拣货（Wave Picking）**：按订单属性（如区域、优先级）分组批量拣货，提高效率。 4. **上架（Putaway）** - 将入库货物放置到指定库位的操作，需结合库位管理策略（如分类存放、周转率优先）。 5. **盘点（Inventory Count）** - 定期或不定期对仓库实物库存进行清点，核对系统数据与实际库存的差异，分为全盘、抽盘、循环盘点等。 6. **补货（Replenishment）** - 当拣货区库存不足时，从存储区向拣货区补充货物的过程，确保拣货效率。 7. **调拨（Transfer）** - 货物在不同仓库、库位或部门之间的转移，如跨仓调拨、库位调整。 8. **退货管理（Return Management）** - 处理客户退货的流程，包括验收、质检、入库（良品）或报废（不良品）。 ### **三、库位与存储管理** 1. **库位（Location）** - 仓库内用于存储货物的具体位置，通常用唯一编码标识（如 A-01-05 表示 A 区第 1 货架第 5 层）。 2. **库区（Zone）** - 仓库内按功能或属性划分的区域，如： - **待检区**：存放待验收货物。 - **合格品区**：存放合格库存。 - **不合格品区**：存放待处理的不良品。 - **拣货区**：用于订单拣选的高频库存区域。 - **存储区**：用于长期存放的低频库存区域。 3. **货位分配策略（Slotting Strategy）** - 确定货物存放位置的规则，常见策略包括： - **周转率优先**：高频出货的 SKU 存放在靠近出入口或拣货区的库位。 - **相关性原则**：经常同时销售的商品就近存放。 - **体积 / 重量原则**：大件、重物存放在低楼层或易搬运的库位。 4. **托盘（Pallet）** - 用于集装、堆放货物的水平平台装置，便于叉车搬运，常见尺寸有 1200mm×1000mm（欧标）、1100mm×1100mm（日标）等。 5. **货架（Racking）** - 仓库内用于存放货物的架子，类型包括： - **托盘货架**：存放托盘货物的重型货架。 - **阁楼货架**：分层结构，用于存放中小件货物。 - **流利式货架**：利用重力实现先进先出（FIFO）的拣货货架。 ### **四、技术与系统功能** 1. **条形码（Barcode）** - 用线条和空白组成的编码，用于快速标识商品信息，通过扫码枪读取数据（如 EAN-13、UPC 码）。 2. **RFID（Radio Frequency Identification）** - 无线射频识别技术，通过电子标签（RFID 标签）非接触式读取货物信息，适用于高速盘点和追踪。 3. **波次管理（Wave Management）** - 将多个订单按规则（如时间、区域、优先级）分组为 “波次”，统一执行拣货、复核等操作，提升批量处理效率。 4. **库存周转率（Inventory Turnover Rate）** - 衡量库存流动性的指标，计算公式：库存周转率 = 销售成本 / 平均库存余额，反映库存管理效率。 5. **先进先出（FIFO，First In First Out）** - 一种库存管理原则，先入库的货物优先出库，适用于对保质期敏感的商品（如食品、药品）。 6. **后进先出（LIFO，Last In First Out）** - 后入库的货物优先出库，适用于价格波动较大或需优先处理最新批次的场景（需符合会计准则）。 7. **ABC 分类法（ABC Analysis）** - 根据库存价值将 SKU 分为三类： - **A 类**：高价值、低数量（占库存价值 70%~80%，数量占 10%~20%）。 - **B 类**：中价值、中数量（占库存价值 15%~20%，数量占 20%~30%）。 - **C 类**：低价值、高数量（占库存价值 5%~10%，数量占 50%~70%），用于差异化管理。 8. **预警管理（Alert Management）** - 系统自动触发的异常提醒，如库存低于安全库存、保质期临近、订单超时未处理等。 ### **五、绩效与策略** 1. **订单履行率（Order Fulfillment Rate）** - 按时交付的订单数量占总订单数量的比例，衡量仓储对订单的处理能力。 2. **拣货准确率（Picking Accuracy）** - 正确拣货的订单数量占总拣货订单数量的比例，反映拣货操作的准确性（通常要求 99% 以上）。 3. **库存准确率（Inventory Accuracy）** - 系统库存与实物库存一致的比例，计算公式：（1 - 差异数量 / 总库存数量）× 100%。 4. **安全库存（Safety Stock）** - 为应对需求波动或供应延迟而预留的库存，用于防止缺货。 5. **JIT（Just-In-Time）** - 准时制库存策略，追求零库存或最小库存，通过精准计划实现 “按需供货”，减少库存成本。 ### **六、其他相关术语** 1. **TMS（Transportation Management System）** - 运输管理系统，与 WMS 对接实现仓储与运输的无缝协同（如出库后自动规划物流路线）。 2. **OMS（Order Management System）** - 订单管理系统，接收前端订单并传递至 WMS 执行仓储操作。 3. **WCS（Warehouse Control System）** - 仓储控制系统，连接 WMS 与自动化设备（如 AGV、堆垛机），实现设备调度和作业执行。 4. **自动化立体库（AS/RS，Automated Storage and Retrieval System）** - 利用自动化设备（如堆垛机）实现货物存储和 retrieval 的高架仓库，提升空间利用率和效率。 如果需要进一步了解某个术语的具体应用场景或系统功能，可以随时补充说明！ ## 库存盘点 在仓储管理系统（WMS）中，**库存盘点**是确保实际库存与系统记录一致的关键操作，目的是及时发现并纠正库存差异（如数量不符、货位错误、物品损坏等），保障库存数据的准确性，为采购、销售、生产等环节提供可靠依据。 ### 一、WMS 库存盘点的核心目标 1. **账实一致**：核对系统记录的库存数量、规格、批次等信息与实际仓储物品是否匹配。 2. **发现问题**：识别库存管理中的漏洞（如错发、漏发、盗窃、损坏等）。 3. **数据修正**：通过盘点结果更新 WMS 系统数据，确保后续操作（如出库、调拨）的准确性。 4. **合规审计**：满足财务核算、行业监管对库存数据的合规性要求。 ### 二、WMS 支持的盘点方式 根据业务需求和盘点范围，WMS 通常支持以下几种盘点方式： | 盘点方式 | 特点 | 适用场景 | | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | 全盘（全面盘点） | 对仓库内所有物品进行逐一清点，覆盖范围最广。 | 月末、年末财务结算；年度审计；库存差异较大时的彻底核查。 | | 抽盘（抽样盘点） | 随机或有针对性地选取部分物品、货位进行盘点，效率较高。 | 日常库存监控；验证近期出入库操作的准确性；重点核查高价值或易损耗物品。 | | 循环盘点 | 按计划分批次、周期性对不同区域或物品进行盘点（如每周盘点 1/5 货位）。 | 替代全盘的高频次盘点；维持日常库存准确性；适合大型仓库的持续库存管理。 | | 动态盘点 | 结合出入库操作实时盘点（如出库时核对剩余数量）。 | 高周转率物品的日常管理；减少专门盘点的停机时间，适合连续生产的仓库。 | | 盲盘 | 盘点时不显示系统记录数量，仅记录实际数量后再与系统比对。 | 避免盘点人员受系统数据干扰，提高盘点客观性（如第三方审计场景）。 | ### 三、WMS 库存盘点的操作流程 1. **盘点计划创建** - 在 WMS 中设定盘点范围（如仓库、货位、物品类别）、时间、参与人员。 - 可选：冻结盘点范围内的物品出入库操作（避免数据变动影响盘点结果）。 2. **盘点任务下发** - WMS 生成盘点清单（含物品编码、名称、系统库存数、货位等信息），通过 PDA、纸质单据或系统界面下发给盘点人员。 3. **实际清点与记录** - 盘点人员到指定货位清点物品，记录实际数量、批次、状态（如完好、损坏）等信息，通过 PDA 实时上传至 WMS，或录入系统。 - 支持多单位盘点（如箱 / 个）、批次管理（如生产日期、保质期）、序列号管理（如电子设备的唯一序列号）。 4. **差异比对与确认** - WMS 自动比对实际数量与系统库存数，生成 “盘点差异表”，标注差异物品（如盘盈、盘亏、货位错误）。 - 对差异项进行二次复核（避免误盘），确认差异原因（如录入错误、实际损坏、系统漏记等）。 5. **差异处理与数据更新** - 经审批后，WMS 根据盘点结果执行 “调账” 操作：盘盈时增加系统库存，盘亏时减少系统库存，并记录差异原因（作为后续分析依据）。 - 同步更新物品货位信息（如发现物品放错货位，自动修正货位关联）。 6. **盘点报告生成** - WMS 输出盘点报告，包含盘点完成率、差异率、差异明细、原因分析等数据，供管理层复盘和优化库存管理流程。 ### 四、WMS 在盘点中的核心功能支持 - **条码 / RFID 集成**：通过扫描物品条码或 RFID 标签快速识别物品，减少人工录入错误。 - **实时数据同步**：PDA 盘点数据实时上传至 WMS，避免纸质记录的二次录入误差。 - **差异预警**：自动标记超阈值的差异项（如盘亏数量超过 5%），提醒优先处理。 - **历史记录追溯**：保存每次盘点的时间、人员、差异原因等日志，支持后续查询和审计。 - **多维度分析**：通过 WMS 报表分析差异趋势（如某类物品频繁盘亏），定位管理问题（如货位规划不合理、出入库流程漏洞）。 ### 五、常见问题与解决建议 1. **差异率过高** - 原因：出入库操作不规范（如错扫、漏扫）、货位管理混乱、系统数据未及时更新。 - 建议：加强员工操作培训；优化货位标识（如清晰的条码 / 二维码）；启用 WMS 的实时库存更新功能。 2. **盘点效率低** - 原因：盘点计划不合理（如高峰时段盘点）、依赖纸质记录、人员不熟悉流程。 - 建议：采用循环盘点替代全盘；使用 PDA 实时采集数据；通过 WMS 路径优化功能规划盘点路线（减少无效移动）。 3. **盘点与业务冲突** - 原因：全盘时冻结库存导致出入库停滞，影响生产或销售。 - 建议：采用动态盘点或分时段盘点；对紧急出入库物品单独标记，盘点后优先处理差异。 通过 WMS 的系统化管理，库存盘点从传统的人工主导转变为流程化、数字化操作，既能提高盘点效率，又能通过数据追溯持续优化库存管理，是现代仓储精细化运营的核心环节之一。 ## 盘亏与盘赢：库存管理中的核心差异概念 #### **一、盘亏（Inventory Shrinkage）** **定义**： 盘亏指**实际库存数量小于系统账面库存数量**的情况，即实物短缺。这是仓储管理中常见的异常状态，需及时追溯原因并处理。 ##### **常见原因** 1. **操作失误**： - 入库时漏记、错记数量（如供应商送货数量与单据不符，未及时核对）。 - 拣货或出库时多发货、发错货，未更新系统库存。 - 库内移库后未同步更新库位信息（如货物从 A 库位移至 B 库位，但系统仍记录在 A 库位）。 2. **损耗与报废**： - 货物因存储环境问题（如潮湿、高温）损坏或过期，未及时报损处理。 - 易碎品、液体类商品在搬运中意外破损，未记录。 3. **盗窃或挪用**： - 仓库内人员违规取用货物未登记（尤其高价值商品，如电子产品、奢侈品）。 4. **系统漏洞**： - WMS 系统故障导致数据未同步（如网络延迟、软件 BUG）。 - 多系统对接时数据传输错误（如 ERP 与 WMS 库存数据不一致）。 ##### **影响** - **财务失真**：导致成本核算错误，利润虚高或虚低，影响财务报表准确性。 - **订单履约风险**：账面库存显示有货，但实际无货，导致客户订单延迟或取消，影响信誉。 - **供应链紊乱**：误导采购计划（如因盘亏未及时补货，导致缺货停产）。 ##### **处理流程** 1. **确认差异**： - 复盘盘点过程，排除盘点误差（如重复盘点、漏盘）。 - 重新核对出入库单据、库位移动记录，确认实际库存是否真的短缺。 2. **追溯责任与原因**： - 调取监控录像（如有）查看异常时段操作，排查是否人为失误或盗窃。 - 检查仓储流程薄弱环节（如入库验收是否严格、拣货复核是否到位）。 3. **系统修正与报损**： - 经审批后，在 WMS 中调减账面库存，记录盘亏数量及原因（如 “拣货多发”“货物破损”）。 - 涉及报废的货物，需走报废流程并申报税务处理（如进项税转出）。 4. **流程优化**： - 针对高频盘亏点加强管控（如增加复核环节、优化库位标识）。 - 对责任人员进行培训或调整岗位（如拣货员操作不规范导致多发）。 #### **二、盘赢（Inventory Overage）** **定义**： 盘赢指**实际库存数量大于系统账面库存数量**的情况，即实物多余账面记录。虽然看似 “有利”，但同样是库存管理异常的信号。 ##### **常见原因** 1. **操作失误**： - 入库时多记数量（如供应商实际送货 101 件，单据误记为 100 件，系统按 100 件录入）。 - 退货处理不当（如客户退货已收讫，但未在系统中恢复库存）。 - 出库时少发货（如订单需发 5 件，实际发 4 件，系统按 5 件扣减库存）。 2. **系统误差**： - 盘点时重复扫描同一货物（如 PDA 设备故障导致同一商品多次记录）。 - 历史数据调整未同步（如以前年度盘亏未完全处理，遗留差异）。 3. **供应链异常**： - 供应商超额供货未察觉（如误将其他客户订单混入本次发货）。 - 运输途中意外拾得货物（如相邻订单货物混装，仓库误收）。 ##### **影响** - **数据误导**：虚增库存可能导致采购决策失误（如本无需补货却重复采购，占用资金）。 - **合规风险**：盘赢若涉及供应商多供货未及时退回，可能引发法律纠纷或商业信誉损失。 - **流程隐患**：掩盖真实问题（如长期盘赢可能源于入库验收不严格，导致后续持续错漏）。 ##### **处理流程** 1. **确认差异真实性**： - 重新盘点并核对出入库记录，排除盘点操作错误（如计数错误、设备故障）。 - 检查是否存在未登记的退货、暂存货物或供应商多送货情况。 2. **追溯来源**： - 联系供应商核实是否超额发货，或与客户确认是否存在未结退货订单。 - 排查历史单据，确认是否因前期操作错误（如出库少扣库存）积累导致。 3. **系统修正与账务处理**： - 若属于供应商多供货，协商退回或补录采购订单（需供应商确认）。 - 若属于历史操作错误，调整对应期间的库存数据（如冲减前期盘亏记录）。 - 无明确来源的盘赢，需按 “无主物资” 流程申报，经审批后计入 “待处理财产损益” 科目。 4. **预防措施**： - 加强入库验收环节（如双人核对数量、扫码实收）。 - 规范退货流程（退货需系统登记并同步库存）。 - 定期校验系统数据与实物的一致性，避免差异累积。 #### **三、盘亏与盘赢的管理要点** | **维度** | **盘亏** | **盘赢** | | ------------ | ------------------------------ | ---------------------------------- | | **核心原则** | 优先追溯短缺原因，避免损失扩大 | 优先确认多余库存来源，避免数据失真 | | **流程重点** | 追责、止损、优化防损机制 | 溯源、合规处理、修正流程漏洞 | | **KPI 关联** | 库存准确率、损耗率 | 库存准确率、供应商交货准确率 | | **技术工具** | WMS 差异报警功能、监控系统 | 智能验收系统（如称重、扫码实收） | ##### **关键行动建议** 1. **建立预警机制**： - 在 WMS 中设置盘亏 / 盘赢阈值（如差异率＞0.5% 时自动触发报警），实时监控异常。 2. **ABC 分类管理**： - 对高价值 A 类商品严格管控，高频盘点（如每日循环盘点），降低盘亏风险；对 B/C 类商品定期抽盘，避免盘赢积累。 3. **人员考核挂钩**： - 将库存准确率纳入员工绩效，对持续低差异率的团队给予奖励，对人为失误导致的差异追责。 4. **定期复盘**： - 每月汇总盘亏 / 盘赢数据，分析趋势（如某库区高频盘亏可能因库位设计不合理），针对性优化仓储布局或流程。 #### **总结** 盘亏与盘赢本质上都是**库存管理失控的表现**，需以 “零差异” 为目标，通过流程优化、技术工具升级和人员管理减少异常。 ## 库存调拨 在仓储管理系统（WMS）中，**库存调拨**是指为平衡库存、满足需求或优化仓储布局，将商品从一个存储位置（如库位、仓库）转移到另一个存储位置的操作。其核心逻辑是通过标准化流程确保调拨过程可追溯、库存数据准确，并适配不同场景（如同一仓库内调拨、跨仓库调拨等）。 ### 一、库存调拨的核心目标 1. 平衡库存：解决部分仓库 / 库位积压、部分短缺的问题； 2. 支持业务需求：如从存储区调拨至拣货区满足订单拣货，或向其他仓库调拨以响应区域订单； 3. 优化仓储效率：例如将滞销品从黄金库位移至次要库区，释放优质位置给畅销品； 4. 满足特殊场景：如临期商品集中处理、破损商品移至待处理区等。 ### 二、库存调拨的核心业务流程 WMS 的库存调拨流程需确保 “有据可依、操作可溯、库存同步”，通常分为以下步骤： #### 1. 调拨发起（生成调拨单） - 触发方式 ： - 手动发起：仓管人员根据库存报表或业务需求在 WMS 中手动创建； - 系统自动发起：WMS 根据预设规则（如拣货区库存低于安全阈值时，自动从存储区调拨补货）或接收外部系统（如 ERP）指令生成。 - 调拨单核心信息 ： - 基础信息：调拨单号（唯一标识）、发起时间、状态（待审核 / 已审核 / 执行中 / 已完成等）； - 源位置：源仓库、源库位（明确货物从哪里出）； - 目标位置：目标仓库、目标库位（明确货物到哪里去）； - 商品信息：SKU 编码、名称、规格、调拨数量； - 附加信息：批次号（批次管理商品）、保质期（效期管理商品）、调拨原因（如补货、移库、退货等）。 #### 2. 调拨审核 - **目的**：确保调拨的合理性（如源仓库是否有足够库存、是否符合业务规则），避免无效操作。 - 审核规则 ： - 库存校验：检查源仓库 / 库位的实际库存是否满足调拨数量（需考虑已锁定库存，如已被订单占用的商品不可调拨）； - 业务合规性：如跨仓库调拨需确认目标仓库是否具备存储该商品的条件（如冷链商品需目标仓库有冷库）； - 权限控制：审核需由指定人员（如仓库主管）完成，防止误操作。 #### 3. 生成调拨任务 审核通过后，WMS 将调拨单拆分为具体执行任务，包括： - **下架任务**：指定人员到源库位下架商品（需核对商品、数量、批次等信息）； - **搬运任务**：若为跨区域（如同一仓库的不同库区）或跨仓库调拨，需安排搬运 / 运输（跨仓库可能关联物流系统）； - **上架任务**：指定人员将商品送至目标库位并完成上架（需核对目标库位是否合规，如是否为对应商品的存储区）。 #### 4. 执行调拨操作 - **下架**：操作人员通过 PDA 扫描源库位、商品条码，确认下架数量（若实际数量与调拨单不符，需实时反馈异常）； - **移库**：商品从源库位移至目标库位（跨仓库调拨可能涉及出库、运输、入库环节，需记录运输轨迹）； - **上架**：操作人员扫描目标库位、商品条码，确认上架数量（需确保商品存放符合规则，如先进先出 FIFO、批次隔离等）。 #### 5. 调拨确认与库存更新 - **确认**：操作人员完成上架后，在 WMS 中确认调拨任务完成，系统自动核对实际调拨数量与调拨单差异（无差异则直接通过，有差异需生成差异单并人工确认）； - 库存同步 ： - 源位置：扣减对应商品的库存（扣减数量 = 实际调拨数量）； - 目标位置：增加对应商品的库存（增加数量 = 实际调拨数量）； - 同步外部系统：若对接 ERP 等系统，需将调拨结果（如完成时间、实际数量）同步至外部系统，确保全链路库存一致。 ### 三、不同调拨类型的业务差异 根据调拨范围，库存调拨可分为以下类型，流程略有差异： | 调拨类型 | 场景举例 | 核心差异点 | | ----------------- | -------------------------------- | ------------------------------------------------------------ | | 同仓内库位调拨 | 从存储区→拣货区、破损区→待处理区 | 无需运输环节，仅涉及内部下架 + 上架；可快速完成，库存实时更新。 | | 跨仓库调拨 | 从 A 仓（北京）→B 仓（上海） | 需增加 “出库 - 运输 - 入库” 环节；可能涉及物流单、运输跟踪；库存更新需等商品到达目标仓并确认上架后完成。 | | 跨区域 / 公司调拨 | 总仓→区域分仓、子公司→母公司 | 可能涉及财务结算（如成本核算）、跨主体审批；需严格记录商品所有权转移信息。 | ### 四、涉及的核心单据与数据 1. **调拨单**：全程唯一标识，记录调拨全量信息（源 / 目标位置、商品、数量等）； 2. **下架单 / 出库单**：源仓库发货凭证，关联调拨单，记录下架商品明细； 3. **上架单 / 入库单**：目标仓库收货凭证，关联调拨单，记录上架商品明细； 4. **差异单**：当实际调拨数量与计划不符时生成，用于后续库存调整和原因追溯； 5. **库存流水账**：记录源 / 目标位置的库存变动（如 “调拨出库 - 10 件”“调拨入库 + 10 件”），支持追溯。 ### 五、异常处理逻辑 调拨过程中可能出现异常，WMS 需支持针对性处理： - **数量不符**：实际下架 / 上架数量与调拨单不一致（如少货、多货），需生成差异单，经审核后调整库存； - **商品损坏**：搬运过程中商品破损，需终止调拨，将商品移至破损区，并更新库存（源位置扣减、破损区增加）； - **库位错误**：误将商品送至非目标库位，需通过 “库位调整” 功能二次调拨至正确位置； - **调拨中止**：因业务取消或其他原因需终止调拨，系统需解锁源位置库存（释放被锁定的商品），并标记调拨单为 “已中止”。 ### 六、与其他系统的集成 库存调拨并非孤立流程，需与其他系统联动： - **ERP 系统**：调拨单可能由 ERP 发起（如根据销售预测调拨至区域仓），WMS 执行后反馈结果，双方同步库存数据； - **TMS（运输管理系统）**：跨仓库调拨时，WMS 将运输需求同步至 TMS，由 TMS 安排运力并反馈运输状态； - **MES（制造执行系统）**：针对生产型仓库，可能从原材料库调拨至生产线，需与 MES 同步生产进度。 综上，WMS 的库存调拨业务逻辑通过 “单据驱动、流程标准化、异常可控、系统联动”，确保商品在不同位置间的转移高效、准确，最终实现库存的动态平衡与精细化管理。 ## 调拨出库 调拨入库 在 WMS 的库存调拨业务中，**调拨出库**和**调拨入库**是两个核心执行环节，分别对应商品从源位置移出和向目标位置移入的操作，两者紧密衔接且需严格遵循 “账实一致、流程可溯” 原则。以下是两者的详细业务逻辑： ### 一、调拨出库（源位置发货） 调拨出库是调拨流程中 “商品离开源仓库 / 库位” 的执行步骤，核心目标是确保从源位置准确、合规地取出商品，并同步扣减库存。 #### 1. 出库前准备 - 任务分配 ：WMS 将审核通过的调拨单拆分为 “调拨出库任务”，分配给指定操作人员（通过 PDA 或作业终端推送），明确任务内容： - 源仓库、源库位（精确到具体货架 / 储位）； - 商品信息（SKU、名称、规格、需出库数量）； - 批次 / 效期要求（如先进先出 FIFO 的商品需优先出库最早批次）。 - **库存锁定**：为防止出库过程中商品被其他任务占用（如订单拣货），WMS 会临时锁定源位置的对应库存（锁定数量 = 调拨单数量），锁定状态持续至出库完成或调拨中止。 #### 2. 出库操作流程 - **库位核对**：操作人员到达源库位后，通过 PDA 扫描库位条码，WMS 校验库位是否与任务一致（防止错拿库位商品）。 - **商品核对**：扫描商品条码（或批次码），系统校验商品 SKU、批次是否与调拨单匹配（如批次管理商品必须出库指定批次）。 - 数量确认 ： - 若为整箱 / 整托商品，直接确认数量（如 1 托 = 10 箱，扫描托码即可关联数量）； - 若为散货，需人工清点后在 PDA 输入实际数量（或通过称重设备自动获取）。 - **异常处理**：若实际可出库数量少于调拨单数量（如商品破损、短少），操作人员需在系统中记录差异，触发 “差异处理流程”（如部分出库、取消调拨等）。 - 出库确认 ：完成商品取出后，操作人员在 WMS 中确认 “调拨出库完成”，系统自动： - 解除源位置的库存锁定； - 扣减源仓库 / 库位的实际库存（扣减数量 = 实际出库数量）； - 更新调拨单状态为 “出库完成，待入库”。 #### 3. 出库后的商品状态 - 若为**同仓内调拨**：商品处于 “在库内转移中” 状态，由操作人员直接搬运至目标库位，无需额外记录运输环节。 - 若为**跨仓库调拨**：商品需通过运输环节送至目标仓库，此时 WMS 会将商品状态标记为 “在途”，并可能与 TMS（运输管理系统）联动，记录运输单号、承运人等信息，便于跟踪。 ### 二、调拨入库（目标位置收货） 调拨入库是调拨流程中 “商品进入目标仓库 / 库位” 的执行步骤，核心目标是确保商品准确送达目标位置，并同步增加库存，同时校验商品状态是否符合要求。 #### 1. 入库前准备 - **任务触发**：当商品到达目标仓库（或同仓内搬运至目标区域）后，WMS 自动生成 “调拨入库任务”（关联对应调拨单），分配给目标仓库的操作人员。 - **库位规划**：系统根据商品特性（如尺寸、重量、存储条件）和目标仓库的库位规则（如 SKU 专属库位、随机库位），自动推荐目标库位；操作人员也可手动指定（需符合系统规则，如禁止将常温商品存入冷库）。 #### 2. 入库操作流程 - 商品接收校验 ： - 核对调拨单：操作人员通过 PDA 调取对应调拨单，确认商品 SKU、批次、预计入库数量与实际到货一致； - 状态检查：检查商品是否完好（如有无破损、包装是否完整）、效期是否符合要求（如临期商品是否允许入库），若有异常需记录并反馈（如拒收破损商品）。 - 数量确认 ： - 同出库操作，通过扫描或清点确认实际入库数量（需与出库数量核对，若有差异需说明原因，如运输损耗）； - 若存在差异（如入库数量＜出库数量），需在系统中记录 “入库差异”，经审核后调整（如按实际数量入库，差异部分由源仓库处理）。 - 上架操作 ： - 操作人员将商品送至目标库位，扫描库位条码确认位置； - 系统校验库位与商品的匹配性（如是否为该 SKU 的允许存储库位）； - 完成上架后，在 PDA 中确认 “商品已放置到位”。 - 入库确认 ：操作人员在 WMS 中确认 “调拨入库完成”，系统自动： - 增加目标仓库 / 库位的实际库存（增加数量 = 实际入库数量）； - 若为跨仓库调拨，清除商品 “在途” 状态； - 更新调拨单状态为 “已完成”； - 同步库存变动至关联系统（如 ERP），确保全链路数据一致。 #### 3. 入库后的后续处理 - 对于入库过程中记录的异常（如破损、数量差异），WMS 会生成 “调拨异常单”，由仓管人员审核后处理（如破损商品移至待处理区、差异数量进行库存调整）。 - 系统自动生成调拨出库 / 入库的明细记录（如操作人、时间、数量），作为库存追溯的依据。 ### 三、调拨出库与入库的关联与差异 | 维度 | 调拨出库 | 调拨入库 | | ------------ | ------------------------------------ | ---------------------------------- | | **核心动作** | 从源位置取出商品，扣减库存 | 向目标位置放入商品，增加库存 | | **校验重点** | 源库存是否充足、商品信息与调拨单匹配 | 商品状态是否完好、与出库数量一致性 | | **异常类型** | 源库存不足、商品短少 / 破损 | 到货数量差异、商品损坏 / 效期异常 | | **库存影响** | 源位置库存减少 | 目标位置库存增加 | | **状态联动** | 触发 “待入库” 状态 | 触发 “调拨完成” 状态 | ### 总结 调拨出库和入库是 WMS 中确保商品 “从哪里来，到哪里去” 的关键闭环，通过严格的校验（库位、商品、数量）、状态跟踪和库存同步，保障调拨过程的准确性和效率。两者的协同运作，最终实现了库存在不同位置间的有序转移，支撑仓储资源的优化配置和业务需求的响应。 ## wms 编码系统设计 WMS（仓库管理系统）编码系统是仓库数字化管理的核心基础，其设计直接影响库存准确性、作业效率和系统扩展性。合理的编码系统能实现对仓库内所有实体（货品、库位、批次等）的唯一标识、快速识别和全链路追踪。以下从设计原则、核心对象编码规则、管理机制三个维度展开设计方案。 ### 一、编码系统设计原则 1. **唯一性**：每个实体（如 SKU、库位）对应唯一编码，无重复或歧义。 2. **可读性**：兼顾机器识别（条码 / RFID）和人工理解（包含业务属性信息）。 3. **可扩展性**：预留编码位，支持业务扩展（如新增仓库、品类、规格）。 4. **兼容性**：与上游系统（ERP、SRM）和下游系统（TMS、MES）编码规则兼容，减少映射成本。 5. **高效性**：编码长度适中（通常 8-20 位），便于扫描、存储和传输。 ### 二、核心对象编码规则设计 WMS 编码系统需覆盖**货品、库位、批次、托盘、订单**等核心实体，不同实体的编码规则需结合其业务属性设计。 #### 1. 货品编码（SKU 编码） 用于唯一标识一款货品，需包含品类、规格等关键属性，支持快速定位货品分类。 - **结构**：`前缀 + 品类码 + 子品类码 + 规格码 + 校验位` - 说明： - 前缀（1 位）：固定为 “S”（表示 SKU），区分其他类型编码。 - 品类码（2 位）：一级分类（如 01 = 电子，02 = 服装，03 = 食品）。 - 子品类码（2 位）：二级分类（如 01 = 手机，02 = 电脑，隶属电子品类）。 - 规格码（4 位）：区分规格（如 0500=500ml，1000=1000g，或自定义规格编码）。 - 校验位（1 位）：通过模 10 算法计算，用于校验输入错误。 - 示例： ``` S010205003 ``` - 解析：S（SKU）+ 01（电子）+ 02（电脑）+ 0500（500g，此处为自定义规格）+ 3（校验位）。 #### 2. 库位编码 用于标识货品存储的物理位置，需反映仓库分区、货架、层位等空间信息，支持作业人员快速定位。 - **结构**：`仓库码 + 区域码 + 货架码 + 层码 + 列码` - 说明： - 仓库码（2 位）：多仓库场景下区分仓库（如 W1 = 北京仓，W2 = 上海仓；单仓库可省略）。 - 区域码（2 位）：仓库内功能分区（如 A1 = 收货区，B2 = 存储区，C3 = 拣货区）。 - 货架码（3 位）：货架编号（001-999，支持千级货架）。 - 层码（2 位）：货架层号（01-20，支持 20 层以内货架）。 - 列码（2 位）：货架列号（01-50，支持 50 列以内货架）。 - 示例： ``` W1B20150308 ``` - 解析：W1（北京仓）+ B2（存储区）+ 015（15 号货架）+ 03（第 3 层）+ 08（第 8 列）。 #### 3. 批次编码 用于追溯同 SKU 不同批次的货品（如生产日期、供应商差异），支持效期管理和质量追溯。 - **结构**：`生产日期 + 供应商码 + 批次序号 + 校验位` - 说明： - 生产日期（6 位）：格式为 “YYMMDD”（如 250819 表示 2025 年 8 月 19 日）。 - 供应商码（3 位）：供应商唯一标识（如 001=A 供应商，002=B 供应商）。 - 批次序号（3 位）：同一供应商同日生产的批次流水号（001-999）。 - 校验位（1 位）：模 11 算法计算，用于校验输入错误。 - 示例： ``` 2508190010057 ``` - 解析：250819（20250819 生产）+ 001（A 供应商）+ 005（当日第 5 批）+ 7（校验位）。 #### 4. 托盘编码 用于整托货品的管理（如大宗存储、整托出入库），需关联托盘承载的 SKU / 批次信息。 - **结构**：`前缀 + 生成日期 + 流水号 + 校验位` - 说明： - 前缀（1 位）：固定为 “P”（表示托盘）。 - 生成日期（6 位）：格式 “YYMMDD”（托盘创建日期）。 - 流水号（6 位）：每日托盘流水号（000001-999999，支持百万级日产能）。 - 校验位（1 位）：模 10 算法计算。 - 示例： ``` P250819001234 ``` - 解析：P（托盘）+ 250819（20250819 创建）+ 001234（当日第 1234 个托盘）+ 4（校验位）。 #### 5. 订单编码 用于标识仓库作业订单（入仓、出仓、移库等），需区分订单类型和时间。 - **结构**：`类型前缀 + 日期 + 流水号` - 说明： - 类型前缀（1 位）：I = 入仓单，O = 出仓单，T = 移库单，R = 退货单。 - 日期（8 位）：格式 “YYYYMMDD”（订单创建日期）。 - 流水号（6 位）：当日同类型订单流水号（000001-999999）。 - 示例： ``` O20250819000567 ``` - 解析：O（出仓单）+ 20250819（创建日期）+ 000567（当日第 567 个出仓单）。 ### 三、编码管理机制 1. **编码生成**： - 系统自动生成：SKU、订单、托盘等编码由 WMS 按规则自动生成，避免人工输入错误。 - 人工辅助录入：库位编码可结合物理布局人工规划后录入系统，确保与实际位置一致。 2. **编码映射与维护**： - 建立编码字典表：存储品类、区域、供应商等代码与名称的映射关系（如 “01 = 电子”），支持前台展示名称，后台存储编码。 - 版本控制：当编码规则调整时（如品类扩展需增加位数），需兼容旧编码（通过规则版本号区分），避免历史数据失效。 3. **校验机制**： - 校验位校验：通过算法（如模 10/11）检测扫描或输入错误（如少输、错输字符）。 - 格式校验：系统校验编码长度、前缀、日期格式等是否符合规则（如生产日期不能为未来日期）。 4. **集成适配**： - 与 ERP 对接：若 ERP 有自有物料编码，可在 WMS 中建立 “ERP 编码→WMS SKU 编码” 映射表，同步时双向转换。 - 条码 / RFID 关联：编码生成后自动转换为条码（Code128）或 RFID 标签，支持移动端扫描识别。 ### 四、扩展场景考虑 - **多仓 / 跨境场景**：库位编码增加 “国家码”（2 位，如 CN = 中国，US = 美国），批次编码增加 “进口批次标识”。 - **特殊货品**：危险品编码前缀增加 “D”（如 DS010205003），便于优先管理和安全作业。 - **系统升级**：预留 1-2 位 “扩展位”，应对未来业务新增属性（如环保等级、溯源标识）。 通过以上设计，WMS 编码系统可实现 “一物一码、一位一码、一批一码”，为库存精准管理、作业流程优化和全链路追溯提供坚实基础。实际落地时需结合企业业务规模（如是否多仓、SKU 量级）和系统集成需求调整细节。 ## 一批一位 多批一位 在 WMS（仓库管理系统）中，同一库区、同一物料的多批次存储需要兼顾**可追溯性**、**操作效率**和**管理原则（如 FIFO/FEFO）**，核心是通过 “货位与批次的精准绑定” 和 “布局策略” 实现有序管理。以下是具体方案： ### 一、明确批次管理的核心目标 在设计存储方案前，需先明确批次管理的目的，这直接影响存储策略： - **追溯需求**：如药品、食品需记录生产批次、供应商、质检报告等，需严格隔离； - **先进先出（FIFO）**：如电子元件、化工原料，需按入库顺序消耗； - **近效期先出（FEFO）**：如保健品、化妆品，需按保质期优先级； - **质量隔离**：如同一物料不同批次可能存在质检状态差异（合格 / 待检 / 不合格），需物理隔离。 ### 二、存储策略设计 #### 1. 货位分配原则：“一批一位” 优先，灵活兼容 “多批一位” - 核心原则：每个货位尽量只存放一个批次（“一批一位”），确保追溯清晰；若批次数量极少（如零散件），可在系统严格记录下 “多批一位”，但需明确标识。 - **示例**：同一库区的 A 物料有 3 个批次（B001、B002、B003），优先分配 3 个独立货位（如 S01-01-01、S01-01-02、S01-01-03），分别绑定 B001、B002、B003。 - **例外情况**：若 B003 批次仅余 2 件，可存入 B002 所在货位，但 WMS 需记录 “货位 S01-01-02 包含 B002（10 件）、B003（2 件）”，并通过条码区分（如每件商品贴批次码）。 #### 2. 布局策略：按批次属性分区 / 分层，强化操作效率 根据批次管理目标，在同一库区内部通过 “微分区” 或 “分层” 实现有序排列： - **按入库时间（FIFO）**： 库区内部划分 “入库顺序带”，如从左到右按批次入库时间递增排列（先入库的批次放左侧，后入库的放右侧）。拣货时优先从左侧货位取货，自然实现 FIFO。 *示例：B001（2024-01 入库）放 S01-01-01（左侧），B002（2024-02 入库）放 S01-01-02（中间），B003（2024-03 入库）放 S01-01-03（右侧）。* - **按效期（FEFO）**： 按批次保质期截止日排序，近效期批次放 “优先拣货区”（如库区前端或底层货架），远效期放后端或高层。 *示例：B001（效期 2025-06）放高层，B002（效期 2024-12）放中层，B003（效期 2024-09）放底层（最易存取）。* - **按质量状态**： 同一库区划分 “合格区”“待检区”“不合格区”（可用货位前缀区分，如 HQ-XXX 为合格，DJ-XXX 为待检），不同质检状态的批次严格分区域存储。 ### 三、系统与操作支撑 1. **批次与货位的精准绑定** WMS 需实时记录 “物料 + 批次 + 货位 + 数量” 的对应关系，入库时通过 PDA 扫描物料批次码和货位码，自动关联；出库时扫描批次码，系统指引对应货位，确保不混批。 2. **可视化标识** - 货位标签需标注 “当前存储的批次号”（如多批一位，需列出所有批次）； - 物料包装贴批次码（包含生产时间、效期等关键信息），便于快速识别。 3. **智能预警** WMS 可设置批次预警（如 FIFO 中先入库批次未消耗、FEFO 中近效期批次即将过期），提醒优先处理，避免呆滞或过期。 ### 四、特殊场景处理 - **批次合并**：若同一物料的多个小批次需合并存储（如零散件凑整），需确保批次信息可追溯（如合并后包装标注 “包含批次 B001、B002”，WMS 同步更新数量拆分关系）。 - **退货批次**：退货的同一物料批次需单独标识（如批次号后加 “-R”），与正常采购批次分区存储，避免混淆。 ### 总结 同一库区、同一物料的多批次存储核心是 “**以批次为单位规划货位，以管理目标（FIFO/FEFO/ 追溯）驱动布局，以系统绑定和操作规范确保准确**”。通过上述方案，既能满足合规性要求，又能提升入库、出库的操作效率。 ## 一批一位 多批一位 数据库设计参考 在 WMS 系统中，支持 “一批一位” 和 “多批一位” 的数据库设计需核心解决**批次、货位、数量的精准关联**，同时满足可扩展性（如支持 FIFO/FEFO 规则）和查询效率。以下是具体设计方案： ### 核心设计思路 通过 5 张核心表实现关联： - 用**物料表**定义物料基础信息； - 用**批次表**记录批次属性（如效期、质检状态）； - 用**库区表**和**货位表**定位存储位置； - 用**库存明细表**作为核心关联表，记录 “批次 - 货位 - 数量” 的映射关系（支持一对多或多对一）。 ### 详细表结构设计 #### 1. 物料表（material） 存储物料的基础信息，作为所有批次的 “母体” 标识。 | 字段名 | 类型 | 说明 | 约束 | | ------------- | ------------ | ------------------- | -------------------------- | | material_id | bigint | 物料唯一 ID（主键） | 自增、非空 | | material_code | varchar(50) | 物料编码（如 SKU） | 唯一、非空（业务唯一标识） | | material_name | varchar(100) | 物料名称 | 非空 | | spec | varchar(50) | 规格型号 | 可空 | | unit | varchar(20) | 单位（如个、箱） | 非空 | | create_time | datetime | 创建时间 | 自动生成 | #### 2. 库区表（warehouse_zone） 定义库区（如 “原材料区 A”“成品区 B”），用于划分货位的所属区域。 | 字段名 | 类型 | 说明 | 约束 | | --------- | ------------ | --------------------------- | ---------- | | zone_id | bigint | 库区唯一 ID（主键） | 自增、非空 | | zone_code | varchar(30) | 库区编码（如 “ZY01”） | 唯一、非空 | | zone_name | varchar(50) | 库区名称（如 “原材料一区”） | 非空 | | remark | varchar(200) | 备注（如 “存放常温物料”） | 可空 | #### 3. 货位表（location） 记录具体存储位置（如货架的 “排 - 列 - 层”），关联到所属库区。 | 字段名 | 类型 | 说明 | 约束 | | ------------- | ------------- | ------------------------------------ | --------------------------- | | location_id | bigint | 货位唯一 ID（主键） | 自增、非空 | | location_code | varchar(50) | 货位编码（如 “S01-02-03”） | 唯一、非空（业务标识） | | zone_id | bigint | 所属库区 ID（外键） | 关联 warehouse_zone.zone_id | | capacity | decimal(18,2) | 货位最大容量（按单位） | 非空（如 “100 箱”） | | use_status | tinyint | 状态（0 - 空闲；1 - 占用；2 - 锁定） | 非空，默认 0 | #### 4. 批次表（batch） 记录同一物料的不同批次属性，是批次管理的核心。 | 字段名 | 类型 | 说明 | 约束 | | --------------- | ----------- | ------------------------------------------ | ------------------------- | | batch_id | bigint | 批次唯一 ID（主键） | 自增、非空 | | batch_no | varchar(50) | 批次号（如 “20240501-B001”） | 唯一、非空（业务标识） | | material_id | bigint | 所属物料 ID（外键） | 关联 material.material_id | | production_date | date | 生产日期（用于 FIFO） | 可空（部分物料无生产日） | | expiry_date | date | 过期日期（用于 FEFO） | 可空（部分物料无保质期） | | supplier_id | bigint | 供应商 ID（外键，可选） | 关联供应商表（若有） | | quality_status | tinyint | 质检状态（0 - 待检；1 - 合格；2 - 不合格） | 非空，默认 0 | | in_time | datetime | 入库时间 | 非空 | #### 5. 库存明细表（inventory_detail） **核心关联表**，记录 “批次 - 货位 - 数量” 的映射关系，同时支持 “一批一位” 和 “多批一位”。 | 字段名 | 类型 | 说明 | 约束 | | ------------- | ------------- | -------------------------- | ------------------------- | | id | bigint | 记录唯一 ID（主键） | 自增、非空 | | batch_id | bigint | 批次 ID（外键） | 关联 batch.batch_id | | location_id | bigint | 货位 ID（外键） | 关联 location.location_id | | quantity | decimal(18,2) | 该批次在该货位的数量 | 非空（>0） | | lock_quantity | decimal(18,2) | 锁定数量（如拣货中未确认） | 非空，默认 0 | | update_time | datetime | 最后更新时间 | 自动更新 | ### 设计亮点（支持两种存储模式） 1. **兼容 “一批一位” 和 “多批一位”**： - 库存明细表通过batch_id和location_id的组合，允许： - 一个批次对应多个货位（`batch_id`相同，`location_id`不同）； - 一个货位对应多个批次（`location_id`相同，`batch_id`不同）。 - 例如： - 一批一位：`batch_id=100`仅关联`location_id=50`； - 多批一位：`location_id=50`关联`batch_id=100`和`batch_id=101`。 2. **支持批次管理规则**： - 通过`batch`表的`production_date`（生产日）和`expiry_date`（过期日），可快速查询 “最早入库批次”（FIFO）或 “最近过期批次”（FEFO）； - 通过`quality_status`可过滤 “合格批次”，避免不合格品被误出库。 3. **库存准确性保障**： - 用`quantity`（可用量）和`lock_quantity`（锁定量）区分实际可操作库存，避免超卖或重复拣货； - 所有库存变动（入库 / 出库）需同步更新此表，确保数据实时性。 ### 关键 SQL 示例（场景验证） #### 1. 查询 “同一库区、同一物料的所有批次及存储位置” ```sql -- 假设查询“库区ZY01”中“物料SKU001”的所有批次存储情况 SELECT m.material_code, b.batch_no, wz.zone_code, l.location_code, id.quantity FROM inventory_detail id JOIN batch b ON id.batch_id = b.batch_id JOIN material m ON b.material_id = m.material_id JOIN location l ON id.location_id = l.location_id JOIN warehouse_zone wz ON l.zone_id = wz.zone_id WHERE m.material_code = 'SKU001' AND wz.zone_code = 'ZY01'; ``` #### 2. 按 FIFO 规则查询 “某物料最早入库的批次及货位” ```sql -- 查找“物料SKU001”中最早入库的批次及其存储货位 SELECT b.batch_no, b.in_time, l.location_code, id.quantity FROM batch b JOIN inventory_detail id ON b.batch_id = id.batch_id JOIN location l ON id.location_id = l.location_id WHERE b.material_id = (SELECT material_id FROM material WHERE material_code = 'SKU001') AND b.quality_status = 1 -- 仅查合格批次 ORDER BY b.in_time ASC LIMIT 1; ``` ### 扩展建议 - 若需支持 “批次合并”（如零散批次合并存储），可增加`batch_merge_record`表记录合并关系（原批次→合并后批次）； - 增加 “库存事务表”（inventory_transaction）记录每次入库 / 出库的变动明细，用于追溯和对账； - 对`inventory_detail`表的`batch_id`和`location_id`建立联合索引，提升多条件查询效率。 通过此设计，既能满足 “一批一位” 的清晰追溯，也能支持 “多批一位” 的灵活存储，同时为后续的批次策略（FIFO/FEFO）提供数据基础。 ## PDA ### 介绍 PDA（掌上电脑 / 手持数据终端）的工作原理是通过集成多种硬件组件和软件系统，实现数据的采集、处理、存储、传输和交互，核心是 **“数据闭环处理”**—— 从外部环境获取信息，经内部处理后，再以特定形式输出或上传。 ### 硬件核心组件及工作逻辑 PDA 的硬件是实现功能的基础，各组件协同完成数据的 “输入 - 处理 - 输出” 流程： 1. **数据采集模块**：负责从外部获取信息（核心输入源） - 条码扫描头：最常见的采集方式，原理是通过光源（如激光、LED）照射条码，条码的黑白条纹反射光线强度不同，由光电传感器将光信号转换为电信号，再通过解码芯片解析为数字或字符（如商品编码、批次号）。 - 一维条码：通过线条宽度和间距编码，扫描头需 “瞄准” 线条方向； - 二维条码（如 QR 码）：通过黑白像素矩阵编码，需面阵传感器捕捉整个图案，解码更复杂但信息容量更大。 - **RFID 读写器**：通过射频信号与 RFID 标签通信，标签内置芯片存储数据，读写器发射特定频率的无线电波，标签接收后返回存储的信息（无需接触，适合批量快速读取，如仓库整托盘货物盘点）。 - **摄像头**：除拍摄外，可通过图像识别技术辅助扫描（如扫码支付场景）或采集证件、文档信息。 - **NFC 模块**：近距离（通常 10cm 内）无线通信，用于快速识别卡片、标签（如门禁、小额支付）。 2. **处理器（CPU）与内存**：负责数据处理和临时存储（核心 “大脑”） - 类似手机的处理器，接收采集模块传来的数据后，进行解析、验证（如与本地数据库比对）、计算（如库存数量增减）等操作。 - 内存（RAM）用于临时存储正在处理的数据和运行中的程序，确保操作流畅；存储芯片（ROM）则长期保存系统、软件和离线数据（如商品库、订单信息）。 3. **通信模块**：负责数据传输（实现 “联网交互”） - **无线网络**：通过 Wi-Fi、4G/5G 模块接入网络，将处理后的数据实时上传至服务器（如 WMS 系统、ERP 系统），或下载最新任务（如订单、库存清单）。 - **蓝牙**：用于短距离连接外设（如蓝牙打印机、扫码枪），或与其他设备同步数据。 4. **输入输出设备**：实现人机交互 - **屏幕**：触控屏接收用户操作（如点击、输入），同时显示数据（如扫描结果、任务列表）；部分工业 PDA 带实体键盘，适合戴手套操作。 - **按键**：自定义功能键（如扫描键、确认键），简化操作流程（如仓库中一键触发扫码）。 - **扬声器 / 指示灯**：通过声音（如扫码成功提示音）或灯光（如红色报错、绿色成功）反馈操作结果。 5. **电源管理**：保障持续工作 - 内置大容量电池（通常 3000-6000mAh），支持低功耗模式，配合电源管理芯片控制各模块电量分配，确保续航（如仓库 PDA 需支持 8-12 小时连续工作）。 ### 软件系统的协同作用 硬件需要软件驱动才能实现功能，PDA 的软件系统包括： 1. **操作系统（OS）**：如安卓（主流）、Windows CE，负责管理硬件资源（如分配 CPU 算力、调度通信模块），为上层应用提供运行环境。 2. **驱动程序**：针对扫描头、RFID 模块等硬件的专用程序，确保系统能识别并控制硬件（如通过驱动调用扫描头开始扫码）。 3. 应用程序（APP）：根据场景开发的专用软件（如仓库 WMS 的 PDA 端 APP），实现具体业务逻辑： - 例如 “入库扫码” 流程：APP 调用扫描头读取商品条码→将条码发送至 CPU→CPU 对比本地缓存的入库单信息→验证通过后，APP 更新本地库存数据→同时通过网络上传至服务器→屏幕显示 “入库成功” 并发出提示音。 4. **数据同步机制**：支持离线存储（断网时数据暂存本地），联网后自动与服务器同步，避免数据丢失（关键功能，尤其适合网络不稳定的仓库、物流场景）。 ### 典型场景工作流程示例（仓库入库） 1. 仓库员工在 PDA 上打开 WMS 入库 APP，接收服务器下发的 “待入库订单”（含商品编码、数量）。 2. 员工用 PDA 扫描商品条码，扫描头将光信号转为电信号，解码后得到商品编码。 3. PDA 的 CPU 将扫描到的编码与订单中的编码比对，确认匹配后，APP 自动记录 “已扫描数量”。 4. 全部商品扫描完成后，员工点击 “确认入库”，PDA 通过 Wi-Fi 将入库数据（商品、数量、时间）上传至服务器。 5. 服务器更新库存数据，并向 PDA 返回 “入库成功” 指令，PDA 屏幕显示结果并发出提示音。 ### 总结 PDA 的核心原理是 **“硬件采集 + 软件处理 + 网络传输” 的协同 **：通过专用模块获取外部数据，经处理器和软件解析处理后，实现本地交互或远程同步，最终满足移动场景下的数据高效管理需求（如仓储、零售、物流等）。其设计重点在于**便携性、耐用性（工业级防护）和针对性的采集能力**，以适应复杂环境下的工作。 ## SN 码（Serial Number）详解 SN 码即**序列号**，是英文 “Serial Number” 的缩写，它是产品出厂时由厂商赋予的唯一标识符，相当于产品的 “身份证号码”。每一个合格的产品（尤其是电子产品）通常都配有独一无二的 SN 码，其核心作用是对产品进行身份标识、追溯和管理。 #### 一、SN 码的主要作用 1. **产品身份唯一标识** 同一品牌、同一型号的产品，通过 SN 码可以区分个体，确保每个产品在生产、销售、售后环节都能被精准识别。 2. **生产与质量追溯** 厂商通过 SN 码可查询产品的生产批次、生产日期、生产工厂、零部件来源等信息，便于质量管控和问题追溯（例如召回特定批次产品）。 3. **售后服务凭证** 消费者维修、保修产品时，SN 码是重要依据，厂商可通过它确认产品是否在保修期内、是否为正品等。 4. **防伪造与防伪** 正规 SN 码通常有加密规则，可帮助消费者验证产品真伪（例如通过官网输入 SN 码查询）。 #### 二、SN 码的常见位置 不同产品的 SN 码位置不同，常见场景包括： - **电子产品**（手机、电脑、耳机等）：通常贴在机身背面、电池仓内、包装盒上，或在系统设置中可查询（如手机 “关于本机”、电脑 BIOS）。 - **家电产品**：多印在机身铭牌、说明书或包装盒上。 - **工业设备**：可能刻在设备外壳或内部标签上，用于资产管理和维护记录。 #### 三、SN 码与其他编码的区别 | 编码类型 | 特点 | 用途 | | ------------------------- | ---------------------------------- | ---------------------- | | SN 码（序列号） | 唯一，针对单个产品 | 个体身份标识、售后追溯 | | 型号（Model Number） | 同一批次 / 规格产品共用 | 区分产品类型、规格参数 | | IMEI 码（移动设备识别码） | 手机等移动设备专用，全球唯一 | 网络注册、防盗追踪 | | 条形码 / 二维码 | 包含产品信息（可能对应型号或批次） | 快速识别、库存管理 | #### 四、如何查询和使用 SN 码？ 1. **查询 SN 码**：根据产品类型查找机身标签、包装盒或系统信息（如手机 “设置 - 关于手机”）。 2. **验证真伪**：访问厂商官网，在 “产品验证” 页面输入 SN 码，查询是否为正品及出厂信息。 3. **售后维修**：保修时提供 SN 码，厂商可确认产品是否在保、是否为官方正品，避免非正规产品享受保修服务。 总之，SN 码是产品全生命周期管理的重要工具，对厂商的生产管控和消费者的权益保障都具有重要意义。在购买和使用产品时，留意并妥善保存 SN 码，有助于解决后续可能出现的售后问题。 ## GS1 编码：全球统一的商业语言 GS1 编码是由**国际物品编码协会（GS1）** 制定的一套全球统一的商业标识标准，旨在通过标准化的编码和数据载体（如条形码、RFID 标签等），实现供应链中产品、位置、资产等信息的高效识别、追踪和共享。它广泛应用于零售、物流、医疗、食品追溯等多个领域，是全球贸易和供应链管理的重要基础。 #### 一、GS1 编码的核心体系 GS1 编码体系包含多种编码标准，覆盖不同的标识对象，核心包括以下几类： 1. **全球贸易项目代码（GTIN）** - **定义**：用于标识零售商品、非零售商品、服务等 “贸易项目” 的唯一编码。 - 常见形式 - GTIN-8（8 位，用于小型商品） - GTIN-12（12 位，如美国 UPC 码） - GTIN-13（13 位，即 EAN-13 码，全球最通用的商品条码） - GTIN-14（14 位，用于非零售的整箱商品） - **应用场景**：超市扫码结算、电商商品标识、库存管理等。 2. **全球位置码（GLN）** - **定义**：标识参与供应链的法律实体（如公司）、功能实体（如仓库、门店）或物理位置（如货架、仓库区域）的唯一编码。 - **应用场景**：订单处理（标识发货 / 收货地址）、供应链协同（标识参与方）、库存定位等。 3. **序列号（Serial Number）** - **定义**：与 GTIN 或 GLN 结合，用于标识单个产品或资产的唯一性（如同一批次的产品通过序列号区分）。 - **应用场景**：产品追溯（如药品、奢侈品的防伪溯源）、资产追踪（如设备的全生命周期管理）。 4. **其他编码** - **全球资产标识符（GAI）**：用于标识固定资产（如设备、工具）。 - **全球服务关系代码（GSRN）**：用于标识服务相关的关系（如订阅服务、会员关系）。 - **全球文档类型标识符（GDTI）**：用于标识文档（如发票、装箱单）。 #### 二、GS1 编码的数据载体 GS1 编码需要通过具体的符号（数据载体）呈现，以便机器识别，常见形式包括： - 条形码 ： - EAN-13：对应 GTIN-13，用于零售商品。 - UPC-A：对应 GTIN-12，主要用于北美市场。 - GS1-128：可包含多个 GS1 编码（如 GTIN + 序列号 + 有效期），适用于物流、医疗等场景。 - Data Matrix：二维条形码，可存储更多信息，适用于小尺寸商品（如电子元件）或需要高密度信息的场景。 - **RFID 标签**：通过无线射频技术读取，可批量识别、非接触读取，常用于供应链中的整箱货物追踪。 #### 三、GS1 编码的作用与优势 1. **全球统一性**：GS1 编码由国际组织制定，全球通用，避免了不同地区编码标准不兼容的问题，方便跨境贸易。 2. **供应链效率提升**：通过标准化标识，实现从生产、仓储、运输到零售的全流程信息共享，减少人工录入错误，加快处理速度。 3. **产品追溯与安全**：结合序列号等信息，可实现产品全生命周期追溯，有助于召回问题产品、打击假冒伪劣（如食品、药品的安全管理）。 4. **数据标准化基础**：为企业 ERP、WMS（仓储管理系统）、电商平台等信息系统提供统一的数据标识标准，便于数据分析和智能化管理（如大数据分析、物联网应用）。 #### 四、如何获取 GS1 编码？ 企业或组织需向所在国家 / 地区的 GS1 成员组织（如中国的**中国物品编码中心 ANCC**）申请，流程大致包括： 1. 加入 GS1 成员组织，获得企业前缀（用于生成 GTIN、GLN 等编码的基础）。 2. 基于企业前缀，按规则生成具体的 GS1 编码（如 GTIN 需确保唯一性）。 3. 选择合适的数据载体（如条形码），并按规范印刷或制作。 #### 五、应用案例 - **零售场景**：超市中商品包装上的 EAN-13 条形码，扫码后可快速获取商品名称、价格等信息，完成结算。 - **物流场景**：快递包裹上的 GS1-128 条形码，包含了寄件 / 收件地址（GLN）、商品信息（GTIN）等，便于分拣和追踪。 - **医疗场景**：药品包装上的 GTIN + 序列号，可追溯生产批次、有效期，确保用药安全。 总之，GS1 编码是全球商业活动的 “通用语言”，通过标准化标识连接供应链各环节，为高效、安全、透明的商业运作提供了基础支撑。 ## 文章阅读 * [【演示】WMS仓储系统 (PDA-移动端-APP)原型 - AxureShop产品原型网](https://www.axureshop.com/ys/1291159) * [【演示】WMS仓储系统原型-PC端 - AxureShop产品原型网](https://www.axureshop.com/ys/1291135) * [【演示】《 SCM供应链管理》解决方案一（原型） - AxureShop产品原型网](https://www.axureshop.com/ys/1144843) * [WMS仓库管理系统 (qq.com)](https://mp.weixin.qq.com/s/738roxUHWI2cB0HRPGnNgA) * [仓库管理4大核心系统：OMS、WMS、WCS、WES ...信息系统](https://mp.weixin.qq.com/s/md6twu4b24op6gBVJ-zF3w) * [一文搞懂MES、ERP、SCM、WMS、APS、SCADA、PLM、QMS、CRM、EAM及其关系 (qq.com)](https://mp.weixin.qq.com/s/w7WpcONik1r1e1xwq3WR_Q) * [什么是WMS？WMS仓库管理系统核心功能及设计要点（文摘） (qq.com)](https://mp.weixin.qq.com/s/sQjnrwa32j7TEErkUTJ9dg) * [一文读懂WMS：定义、功能、部署、选型、适用全解析！ (qq.com)](https://mp.weixin.qq.com/s/Di48rPSCPfmnyXLP08aLyQ) * [一文带你全面了解WMS智慧仓库管理系统行业趋势及功能解析！ (qq.com)](https://mp.weixin.qq.com/s/1GBvTMXn16KQzNtWrVzTKw) * [仓库管理 系列知识](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU2MTkzMDgyNQ==&action=getalbum&album_id=3017348520368160769&subscene=159&subscene=189&scenenote=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU2MTkzMDgyNQ%3D%3D%26mid%3D2247493206%26idx%3D1%26sn%3Dd61f3c3cc6d5a61645f914797638bb6a%26chksm%3Dfc739170cb0418666762f420a9430edcf126ab8b6941b596e4e3d6c5c558a1c8765b2fd88e45%26cur_album_id%3D3017348520368160769%26scene%3D189%23wechat_redirect&nolastread=1#wechat_redirect) ## 第三方WMS体验 * [点狮后台管理系统](http://admin.dianshixinxi.com:90/login?redirect=%2Findex) ## 黑盒测试与白盒测试 在软件测试领域，**黑盒测试**和**白盒测试**是两种最基础且常用的测试方法，它们从不同角度验证软件质量，适用于不同的测试场景。以下是对两者的详细解析： ### 一、黑盒测试（Black Box Testing） 黑盒测试又称 “功能测试” 或 “数据驱动测试”，测试时不关注软件内部的代码结构、逻辑或实现细节，仅通过输入数据和输出结果来验证软件是否符合需求规格。 #### 核心特点： - **测试视角**：将软件视为一个 “黑盒子”，只关注外部功能是否正常，不涉及内部逻辑。 - **测试依据**：主要基于需求文档、用户手册等外部规格说明。 - **测试人员**：通常由不了解代码的测试工程师或用户执行。 #### 常用方法： - **等价类划分**：将输入数据划分为若干等价类（有效等价类和无效等价类），从每个类中选取代表性数据测试，减少冗余用例。 例：测试登录功能时，“有效用户名 + 有效密码”“无效用户名 + 有效密码” 等可作为等价类。 - **边界值分析**：针对输入输出的边界条件设计用例（如数值的最大值、最小值、空值等），因为边界往往是错误高发区。 例：测试年龄输入框（要求 1-120 岁）时，需验证 0、1、120、121 等边界值。 - **场景法**：模拟用户实际使用场景，覆盖多个功能点的交互流程。 例：电商平台的 “下单 - 支付 - 发货” 完整流程测试。 - **错误推测法**：基于经验猜测可能出现的错误，设计针对性用例（如网络中断、数据格式错误等）。 #### 优点： - 更贴近用户实际使用场景，能发现用户可见的功能缺陷。 - 不依赖代码知识，测试人员无需了解编程语言。 - 适合对整个系统或模块进行验证，尤其在集成测试、系统测试阶段。 #### 缺点： - 无法覆盖内部逻辑漏洞（如代码中的死循环、冗余判断等）。 - 部分用例可能重复或遗漏，测试覆盖率难以量化。 - 难以定位错误根源（只知结果错，不知代码哪部分错）。 ### 二、白盒测试（White Box Testing） 白盒测试又称 “结构测试” 或 “逻辑驱动测试”，测试时需了解软件的内部代码结构、逻辑流程和算法，通过直接检查代码或执行路径来验证其正确性。 #### 核心特点： - **测试视角**：将软件视为 “透明盒子”，关注内部逻辑是否符合设计要求。 - **测试依据**：基于源代码、流程图、伪代码等内部文档。 - **测试人员**：通常由开发工程师或熟悉代码的测试工程师执行。 #### 常用方法： - **语句覆盖**：设计用例确保每行代码至少执行一次。 - **分支覆盖（判定覆盖）**：确保每个条件判断的 “真”“假” 分支都被执行（如 if-else、switch-case 的所有分支）。 - **条件覆盖**：针对判断中的每个子条件（如`a>0 && b<5`中的`a>0`和`b<5`），确保其真假值都被覆盖。 - **路径覆盖**：覆盖所有可能的代码执行路径（如循环的 0 次、1 次、多次执行）。 - **基本路径测试**：通过控制流图分析，找出独立的基本路径并设计用例覆盖。 #### 优点： - 能深入代码底层，发现逻辑错误、语法错误、内存泄漏等内部缺陷。 - 测试覆盖率可量化（如语句覆盖率、路径覆盖率），便于评估测试完整性。 - 可在开发早期（单元测试阶段）执行，提前修复缺陷，降低后期修改成本。 #### 缺点： - 依赖代码知识，测试人员需掌握编程语言和代码结构。 - 当代码频繁变更时，维护测试用例的成本高。 - 可能过度关注细节，忽略整体功能的用户体验。 ### 三、黑盒测试与白盒测试的对比 | **维度** | **黑盒测试** | **白盒测试** | | ---------- | ---------------------------- | --------------------------- | | 测试对象 | 软件外部功能 | 软件内部代码结构 | | 测试依据 | 需求文档、用户手册 | 源代码、流程图 | | 测试阶段 | 集成测试、系统测试、验收测试 | 单元测试、组件测试 | | 核心目标 | 验证功能是否符合需求 | 验证代码逻辑是否正确 | | 覆盖率衡量 | 较难量化 | 可通过语句 / 路径覆盖率量化 | | 对人员要求 | 无需代码知识 | 需熟悉编程和代码结构 | ### 四、实际应用：两者结合 在软件测试流程中，黑盒测试和白盒测试并非对立，而是互补的： - **单元测试**：以白盒测试为主，验证函数、类的内部逻辑。 - **集成测试**：结合两者，用白盒测试验证模块接口的代码逻辑，用黑盒测试验证模块交互的功能。 - **系统测试 / 验收测试**：以黑盒测试为主，模拟用户场景验证整体功能。 例如：测试一个登录模块时，白盒测试会检查 “密码加密算法是否正确”“用户名非空判断的代码逻辑”；黑盒测试则会验证 “输入错误密码时是否提示正确”“连续输错 3 次是否锁定账户” 等用户可见的功能。 通过合理搭配两种方法，可最大化测试覆盖率，既保证用户可见的功能正常，又确保代码内部逻辑的健壮性。 ## 冒烟测试与回归测试 在软件测试领域，**冒烟测试**和**回归测试**是两种重要的测试类型，分别用于不同的测试阶段和目标。下面详细介绍两者的定义、特点、应用场景及区别： ### 一、冒烟测试（Smoke Testing） **定义**：冒烟测试是一种初步的、快速的测试，旨在验证软件的核心功能是否正常运行，确保基本流程可通，避免在后续详细测试中浪费资源。其名称源于硬件测试中的 “冒烟测试”—— 开机后若设备冒烟（功能失效），则无需进一步测试。 #### 特点： - **范围小而关键**：只测试核心功能（如登录、基本操作流程），不涉及细节或边缘场景。 - **执行快速**：通常在短时间内（如 1-2 小时）完成，多为自动化脚本执行。 - **门槛测试**：作为后续测试的 “准入条件”，若冒烟测试不通过，需先修复核心问题，再进行其他测试。 #### 应用场景： - 新功能开发完成后，首次构建版本的初步验证。 - 每日构建（Daily Build）后，验证基本功能是否可用。 - 修复重大 bug 后，确认核心功能未受影响。 #### 示例： - 对于电商 APP，冒烟测试可能包括：打开 APP、登录账号、浏览商品、加入购物车、提交订单（无需支付细节）。 ### 二、回归测试（Regression Testing） **定义**：回归测试是在软件发生变更（如修复 bug、新增功能）后，验证原有功能是否仍正常工作，确保变更未引入新的缺陷。 #### 特点： - **范围广而全面**：覆盖已测试过的功能，包括核心功能和次要功能，甚至历史 bug 场景。 - **可自动化程度高**：由于需重复执行，通常会编写自动化脚本（如 Selenium、Jmeter）。 - **持续迭代**：每次变更后都需执行，随软件版本迭代不断更新测试用例。 #### 应用场景： - 修复 bug 后，验证相关功能及关联模块是否正常。 - 新增功能上线前，确认旧功能未被破坏。 - 系统升级（如数据库、服务器变更）后，全面验证兼容性。 #### 示例： - 电商 APP 新增 “优惠券” 功能后，回归测试需验证：原有的支付流程、订单查询、退款功能等是否仍正常，且优惠券功能的加入未导致其他模块出错。 ### 三、两者的核心区别 | **维度** | **冒烟测试** | **回归测试** | | ------------ | ------------------------------- | ------------------------------------------- | | **目的** | 验证核心功能是否可运行（准入） | 验证变更后原有功能是否正常（防 regression） | | **测试范围** | 小（仅核心功能） | 大（覆盖已测功能） | | **执行时机** | 新构建 / 版本初期，作为测试前提 | 变更后（如修复 bug、新增功能后） | | **执行频率** | 高频（如每日构建后） | 随变更频率执行（如每次迭代后） | | **通过标准** | 核心功能无阻断性问题 | 原有功能无新增缺陷 | ### 四、总结 - 冒烟测试是 “快速把关”，确保软件具备基本可测性； - 回归测试是 “全面复查”，确保变更未对原有功能造成负面影响。 在实际测试流程中，通常先执行冒烟测试，通过后再进行回归测试及其他详细测试（如集成测试、系统测试），两者共同保障软件质量。 ## VO，BO，PO，DO，DTO区别 在软件开发中，VO、BO、PO、DO、DTO 是用于区分不同层数据对象的概念，它们帮助规范数据在各层之间的流转，降低耦合性。以下是详细解释： ### **1. PO（Persistent Object，持久化对象）** - **定义**：与数据库表结构一一对应，用于 ORM（对象关系映射）框架（如 MyBatis、Hibernate）直接操作数据库。 - 特点 ： - 字段名通常与数据库表字段完全一致。 - 包含 getter/setter 方法，可能有简单的构造函数。 - 不包含复杂的业务逻辑，仅作为数据存储的载体。 - **示例**：若数据库有`user`表（字段：id、name、age），则 PO 类`UserPO`会有对应的`id`、`name`、`age`字段。 ### **2. DO（Domain Object，领域对象）** - **定义**：对应业务领域的实体，封装了核心业务逻辑和属性，是业务层的核心对象。 - 特点 ： - 可能与 PO 有对应关系，但更侧重业务含义（如 PO 中的`user_name`在 DO 中可能为`userName`，并增加业务相关字段）。 - 包含业务方法（如计算、校验等），体现领域模型的行为。 - 独立于数据库设计，更贴近业务场景。 - **示例**：`UserDO`可能包含`id`、`userName`、`age`，以及方法`isAdult()`（判断是否成年）。 ### **3. DTO（Data Transfer Object，数据传输对象）** - **定义**：用于不同层（如服务层与客户端、服务间）的数据传输，解决数据冗余或隐私问题。 - 特点 ： - 按需封装数据，可能包含多个 PO/DO 的部分字段，或排除敏感信息（如密码）。 - 仅用于数据传输，不包含业务逻辑。 - 可根据传输场景定义不同 DTO（如`UserQueryDTO`用于查询，`UserCreateDTO`用于创建）。 - **示例**：客户端请求用户信息时，`UserDTO`可能只包含`id`、`userName`，不包含`password`。 ### **4. VO（View Object，视图对象）** - **定义**：专门用于展示层（如前端页面、APP 视图），与页面展示的数据结构一一对应。 - 特点 ： - 可能包含格式化后的字段（如日期转为`yyyy-MM-dd`字符串）、计算结果（如`totalPrice`）。 - 与 DTO 的区别：VO 更贴近视图需求，DTO 更侧重服务间传输。 - **示例**：订单详情页的`OrderVO`可能包含`orderId`、`formattedCreateTime`（格式化日期）、`productList`（商品列表）。 ### **5. BO（Business Object，业务对象）** - **定义**：封装复杂业务逻辑的对象，通常由多个 PO/DO 组合而成，用于业务层处理。 - 特点 ： - 聚合多个相关对象，处理跨实体的业务操作（如订单 BO 可能包含用户、商品、支付信息）。 - 包含核心业务逻辑，是业务处理的载体。 - **示例**：`OrderBO`可能包含`OrderDO`、`UserDO`、`ProductDO`，以及方法`calculateTotalAmount()`（计算订单总金额）。 ### **总结：核心区别与关系** | 类型 | 核心用途 | 常见场景 | 包含逻辑 | | ---- | --------------------- | ----------------------- | ------------ | | PO | 数据库映射 | ORM 操作 | 无（仅数据） | | DO | 领域实体 | 业务核心模型 | 基础业务逻辑 | | BO | 复杂业务处理 | 跨实体业务操作 | 复杂业务逻辑 | | DTO | 层间 / 服务间数据传输 | API 接口请求 / 响应 | 无 | | VO | 视图展示 | 前端页面 / APP 视图数据 | 格式化逻辑 | **流转关系**： 数据库 → PO → DO → BO（业务处理）→ DTO（传输）→ VO（展示）。 实际开发中需根据场景灵活使用，避免过度设计。 ## 如何在实际项目中选择使用VO、BO、PO、DO、DTO？ 在实际项目中选择使用 VO、BO、PO、DO、DTO 等数据对象，核心原则是**根据数据的流转场景和职责边界来划分**，避免过度设计或滥用。以下是具体的选择策略和实践建议： ### **1. 先明确项目分层，再匹配对象类型** 数据对象的设计与系统分层强相关，典型的分层架构（从下到上）如下： `数据库层 → 领域层 → 业务层 → 接口层 → 展示层` 不同层对应的数据对象选择： - **数据库层**：用**PO**（与表结构一一对应，ORM 直接操作）。 - **领域层**：用**DO**（核心业务实体，封装领域逻辑）。 - **业务层**：用**BO**（处理跨领域 / 跨表的复杂业务，聚合多个 DO/PO）。 - **接口层**（服务间 / 前后端交互）：用**DTO**（按需传输数据，控制权限和冗余）。 - **展示层**：用**VO**（适配前端视图，处理格式化、组合展示数据）。 ### **2. 按场景决定是否使用，避免为了用而用** #### **场景 1：简单 CRUD 项目（如管理后台）** - 核心需求：快速实现数据增删改查，业务逻辑简单。 - 选择建议： - 用**PO**直接映射数据库，简化 ORM 操作。 - 用**DTO**兼顾传输和展示（无需单独 VO），避免对象冗余。 - 可省略 DO 和 BO（业务逻辑简单时，无需额外抽象）。 例：用户管理模块，直接用`UserPO`操作数据库，`UserDTO`作为接口入参 / 出参（前端直接使用）。 #### **场景 2：中大型业务系统（如电商、支付）** - 核心需求：业务逻辑复杂，多模块交互多，需解耦和复用。 - 选择建议： - 必须用**PO**（数据库映射）和**DO**（领域核心）。 - 跨模块 / 跨表业务用**BO**（如订单 BO 聚合用户、商品、支付信息）。 - 接口层严格用**DTO**（隐藏内部结构，控制字段权限）。 - 前端展示用**VO**（处理格式化，如价格保留两位小数、日期转字符串）。 例：订单流程中，`OrderPO`对应订单表，`OrderDO`封装订单状态流转逻辑，`OrderBO`整合商品和用户信息计算总价，`OrderDTO`用于服务间传输，`OrderVO`格式化后给前端展示。 #### **场景 3：对外 API 服务（如开放平台）** - 核心需求：接口稳定，数据安全，适配不同调用方。 - 选择建议： - 内部用 PO/DO 处理业务，对外暴露**DTO**（严格定义字段，屏蔽内部变化）。 - 避免直接返回 PO/DO（防止数据库结构暴露，或字段变更影响外部）。 例：用户中心对外提供查询接口时，用`UserApiDTO`（只包含`id`、`nickname`等非敏感字段），而非内部的`UserDO`（可能包含密码哈希、内部状态等）。 ### **3. 关键区分：容易混淆的对象** #### **DTO vs VO** - **DTO**：强调 “传输”，解决不同服务 / 模块间的数据交互，字段通常是原始数据（如时间戳）。 - **VO**：强调 “展示”，解决前端视图需求，可能包含格式化后的数据（如`createTime`转为`"2023-10-01"`）。 - 选择：若前端直接使用接口返回的 DTO 且无需格式化，可省略 VO；若有展示层特殊处理（如多语言、格式化），则必须用 VO。 #### **DO vs BO** - **DO**：对应单一业务实体（如`UserDO`、`ProductDO`），包含自身的核心逻辑（如`UserDO.isVip()`）。 - **BO**：处理跨实体业务（如`OrderBO`需要`UserDO`和`ProductDO`协作计算），是 “业务操作的载体”。 - 选择：单一实体操作只用 DO；复杂业务（如订单创建需校验库存、扣减余额）必须用 BO。 #### **PO vs DO** - **PO**：完全依赖数据库表结构，字段与表一一对应（如数据库`user`表有`user_name`，PO 就有`userName`）。 - **DO**：依赖业务领域，可能与 PO 字段不同（如 DO 中增加`fullName`字段，由 PO 的`first_name`和`last_name`组合而成）。 - 选择：PO 仅用于数据库操作；DO 是业务的 “真相来源”，PO 需转换为 DO 后进入业务逻辑。 ### **4. 实践技巧：降低复杂度** 1. **对象转换工具化**：用 MapStruct、BeanUtils 等工具处理 PO→DO、DO→DTO 等转换，减少重复代码。 2. **避免多层嵌套**：DTO/VO 中尽量避免嵌套复杂对象（如 VO 里嵌套 BO），防止序列化问题和理解成本。 3. **命名清晰**：按 “前缀 + 类型” 命名（如`UserPO`、`OrderDTO`），明确对象职责。 4. **灵活取舍**：小型项目可简化（如用 DTO 代替 VO），大型项目必须严格区分（避免后期维护混乱）。 ### **总结** 选择数据对象的核心是 **“让数据在合适的层做合适的事”**： - 贴近数据库用**PO**，贴近业务用**DO/BO**，贴近传输用**DTO**，贴近展示用**VO**。 - 不要为了 “规范” 而引入不必要的对象，根据项目规模和复杂度动态调整，在 “灵活性” 和 “可维护性” 之间找平衡。