简介这份WMS系统操作手册面向仓库管理员、供应链管理者及ERP实施人员聚焦仓储日常作业的规范化操作帮助读者快速上手浙江三花智能控制股份有限公司自主开发的Web版仓储管理系统。手册围绕销售订单编制、提交与审核销售订单变更主生产计划编辑、审核及抛砖主生产计划变更以及事业部入库等核心业务场景展开逐项说明流程环节、主要操作项与操作演示步骤并附有注意事项便于对照系统界面完成实际作业。资源包共1个docx文档压缩包约23.02MB内容以图文操作说明为主目录按功能模块分层编排便于按需检索。目前已有1658人学习下载适合需要熟悉WMS入库、订单与计划管理流程的从业者作为岗位培训与日常查阅的参考材料。1. 一份手册背后藏着的 WMS 全链路从销售订单到成品出库很多团队拿到仓储系统源码第一反应是翻代码找接口结果在几十张业务单据里绕不出来。我拆这份 WMS 系统操作手册时换了个思路先把它当成一张业务地图来读。它覆盖的是销售订单编制审核、主生产计划编辑抛转、事业部成品入库、物流部验货上架、拣货装车、返工与形态转换、退货这一整条链路采用 B/S 架构浏览器直接访问账号与组织、仓库、部门绑定。适合两类人一是要接手这套系统做二次开发的后端二是要照着流程配置权限和单据流的实施人员。手册本身不是代码但它把每个环节的必填项、状态流转、驳回规则写得极细这些恰恰是数据库表结构和状态机设计的直接映射。读懂它等于拿到了这套 WMS 的数据字典草稿。2. 业务架构拆解七类单据如何串成一条链2.1 从销售订单到主生产计划的单据流转这套系统的骨架是单据驱动。销售订单是源头业务员录入后经所长提交、营业管理岗审核审核通过的单据才会进入制造部计划处的视野。计划处根据销售订单下达成各组织的主生产计划这里有个关键动作叫「抛转」——商贸组织下的主生产计划必须抛转给事业部去生产而智控与制冷组织则直接提交不走抛转。这个差异不是拍脑袋定的它对应的是组织间生产职责的划分商贸组织自己没有产线必须把生产任务转交出去。从数据建模角度看销售订单和主生产计划之间是一对多的关系一张销售订单可以拆成多条主计划行按料号、项目号、订货号区分。订货号这个字段要特别注意手册里反复强调「同项目号同料号不同订货号在系统里是两种库存有订货号与无订货号的主计划也是各自独立互不影响」。这意味着库存维度的主键不是简单的料号而是料号加订货号的组合。二次开发时如果按料号做库存汇总数据一定对不上。状态机方面单据从草稿到提交到审核驳回只能退回上一环节第一个环节不能驳回。这个规则看起来简单实现时却容易翻车驳回操作要记录驳回人和驳回原因还要把单据状态回滚到上一环节的待办池同时清理当前环节的锁定标记。常见做法是在单据主表上维护 current_node 和 status 两个字段驳回时同时更新并在流转日志表里插一条记录。2.2 入库与出库的双向链路事业部入库的流程是事业部计划处根据销售订单完成生产生产环节走的是另一套系统成品仓仓管员根据流转卡拿到完工数量到主生产计划看板编制入库申请单打印物资入库单和外箱条码贴到包装箱上提交给物流部。运转工把实物搬到物流部待验货区物流部验货后上架。这条链路里有两个物理动作和两个系统动作交错系统里提交入库申请物理上搬货系统里验货确认物理上上架。手册特意提醒「确保入库单与入库单对应的实物能明显对应起来方便物流部验货」这就是为什么外箱条码要逐行打印——一个入库单可能对应多个批次每个批次一个条码。出库方向是物流部拣货、装车。拣货依据的是发货计划装车确认后库存扣减。返工和形态转换是两条特殊链路返工出库是把有问题的成品退回事业部返修形态转换则是物料形态发生变化比如半成品转成品需要走单独的出入库对冲。退货功能独立成章流程是退货指令下达、退货接收涉及库存回冲和财务核算月份的归属。这七类单据共享一套基础设施组织权限、仓库绑定、批次管理、条码打印、看板筛选。理解了这个分层再看代码就不会迷路。2.3 权限与组织模型手册里多处提到「账号绑定所处事业部默认成品仓库」「销售部门、销售员自动带出且联动变化」。这说明权限模型是组织驱动的用户登录时选择组织系统根据组织加载对应的仓库、部门、可操作的单据类型。销售员和销售部门联动本质上是组织架构树上的父子关系查询——选定部门后只列出该部门下的销售员。实现上常见做法是三张表组织表、用户组织关系表、仓库组织关系表。登录时校验用户属于哪些组织选定组织后把 org_id 写入 session后续所有单据查询都带 org_id 过滤。这里有个容易忽略的点跨组织抛转时单据的归属组织会变化但原始销售订单的组织不变。所以单据表上至少要存两个组织字段source_org 和 current_org抛转时更新 current_orgsource_org 保持不变用于追溯。3. 关键操作落地从登录到入库单生成的完整路径3.1 登录与组织选择系统访问地址是内网 IP 加端口用浏览器打开。登录界面三行输入第一行选组织第二行填员工编号第三行填密码账号密码默认都是员工 ID。这个设计很朴素但暴露了一个实施细节组织选择在登录时完成意味着同一个员工如果属于多个组织需要多次登录切换。二次开发如果要支持组织切换不重新登录就得把组织选择从登录环节挪到会话内做成顶部下拉切换。登录成功后系统加载该组织的菜单权限。手册里说「在发起任务中找到事业部入库申请或点击新建进入」说明菜单是按角色配置的。新建按钮和发起任务入口指向同一个表单区别在于新建是空白单发起任务是带上下文的。// 登录请求示例组织、工号、密码三要素 const loginPayload { orgCode: ORG_001, // 组织编码决定后续数据权限范围 employeeId: 11107618, // 员工编号同时作为默认账号 password: ****** // 默认与工号一致首次登录后应强制修改 }; // 登录成功后服务端返回会话令牌与组织上下文 // 后续所有请求头携带 token服务端据此过滤 org_id这段逻辑说明登录不只是身份校验更是数据权限的起点。参数里 orgCode 决定了 session 中的 org_idemployeeId 既做账号也做人员标识。实际部署时默认密码等于工号是个安全隐患二次开发第一件事就该加首次登录强制改密。3.2 事业部入库单的编制入库单编制分三步选主生产计划、改数量和批次、保存并打印条码。第一步点「主生产计划看板」勾选要入库的产品行点确认选择带入表单。如果实际入库数量大于看板单行数量要勾选两行同项目号同料号同订货号的主计划。第二步改数量数量不能大于可用数量改生产日期会同步更新生产批次字段一张单要多个批次就复制行再改。第三步保存生成单据号然后逐行打印外箱标贴。这里的核心约束是「可用数量」。可用数量等于主计划数量减去已入库数量每次入库申请提交时扣减驳回或删除时归还。实现上要么在提交时实时计算要么维护一个已入库数量字段做增量更新。实时计算更安全但查询压力大增量更新快但容易因并发出错。我一般会在主计划表上加一个 locked_qty 字段提交时用乐观锁更新版本号对不上就提示重试。-- 入库申请提交时扣减主计划可用量乐观锁 UPDATE mps_line SET locked_qty locked_qty :apply_qty, version version 1 WHERE id :mps_line_id AND version :expected_version AND plan_qty - locked_qty :apply_qty; -- 影响行数为 0 说明并发冲突或可用量不足需回滚并提示参数说明apply_qty 是本次申请入库数量plan_qty 是主计划总量locked_qty 是已锁定数量。where 条件里同时校验版本号和可用量一条语句解决并发和超量两个问题。这种写法比先查后改少一次往返也避免了查改之间的窗口期。3.3 条码打印与批次管理外箱标贴的打印逻辑是逐行触发选中行号区域整行拉蓝点更多右侧的黑色小箭头选打印外箱标贴。多行批次就依次逐行打印。条码内容通常包含单据号、料号、批次号、数量扫码枪扫出来能直接定位到入库单行。批次号由生产日期驱动生产日期变了批次跟着变。这意味着批次号不是独立输入的而是日期格式化加流水。常见做法是批次号等于生产日期加当日流水比如 20240327-001。二次开发如果要支持自定义批次规则得把批次生成逻辑抽成策略接口按物料类别配置不同规则。提示复制行时数量必须小于等于所选主计划的可用数量否则保存失败。这个校验在复制动作时就要做不能等到保存才提示否则用户填了半天才被打回。4. 避坑与排查五个真实会卡住你的地方4.1 订货号为空导致库存对不上现象入库单保存成功但库存查询里找不到这批货或者数量比预期少。原因主生产计划行有订货号和无订货号被视为两种独立库存入库时如果选错了行选了无订货号的行实际货物有订货号库存就记到了另一个维度。解决入库前核对主计划行的订货号与实物标签是否一致看板筛选时把订货号列显示出来不要隐藏。4.2 抛转后原组织查不到单据现象商贸组织把主生产计划抛转给事业部后原组织在待办里看不到这张单了以为丢了。原因抛转更新了单据的 current_org原组织的待办查询按 current_org 过滤自然查不到。解决待办列表增加「我发起的」页签按 source_org 查询或者在抛转日志里保留流转记录供追溯。4.3 驳回后单据卡在中间状态现象审核环节驳回单据回到编制人手里但编制人修改后再次提交审核人待办里不出现。原因驳回时只改了状态没清当前处理人或者再次提交时没有重新分配待办。解决驳回操作要同时做三件事——状态回滚、当前处理人置空、流转日志插记录提交操作要重新计算下一环节处理人并写入待办表。4.4 批次复制行数量超限现象复制行后修改数量保存时报错「数量不能大于可用数量」。原因复制行默认带出原行数量两行加起来超过了主计划可用量。解决复制行时数量默认置零或置为剩余可用量让用户主动填保存前做汇总校验把同一主计划行的所有明细数量加起来比对可用量。4.5 内网访问与浏览器兼容现象用某些浏览器打开页面样式错乱或按钮点不动。原因系统是 B/S 架构且年代较早前端可能依赖特定浏览器的渲染行为。解决统一用谷歌浏览器访问内网地址固定如果要做前端改造先摸清现有页面的 DOM 结构和事件绑定方式不要贸然换框架。5. 二次开发改造从手册反推数据模型与扩展点拿到这套系统做二次开发我的习惯是先用手册里的字段清单反推表结构再找扩展点。手册第 3.1.2 节列出的销售订单界面要素——客户、订单方式、销售部门、销售员、币种、供应商、立账条件、料号、数量、客户需求日期、项目号、订货号——基本就是销售订单主表和明细表的字段集合。其中客户决定币种和立账条件说明客户主数据表上挂着默认值订单方式选 OEM 时供应商必填说明这是个条件必填规则适合做成表单联动校验。扩展点我一般看三个地方。第一是单据状态机手册里每个功能都有保存、提交、驳回、删除四个动作状态流转是固定的如果要加「撤回」功能就在提交和审核之间插一个状态同时改待办查询逻辑。第二是看板筛选销售订单看板、主生产计划看板都是查询入口筛选条件手工添加、多条件用空格分开这个搜索解析逻辑可以抽成公共组件所有看板复用。第三是条码打印逐行打印的触发方式比较原始可以改成批量打印但要注意批次和数量的对应关系不能乱。验证方法上我建议先跑通一条最小链路建一张销售订单提交审核下主计划抛转事业部入库物流部验货上架然后查库存。这条链路走通说明组织权限、状态流转、库存扣减三个核心机制没问题。再跑返工和退货两条反向链路验证库存回冲和财务月份归属。最后用两个不同组织的账号交叉操作验证数据隔离。有个表格可以对照着看关键字段的归属字段所属单据是否必填联动规则客户销售订单是带出币种、立账条件订单方式销售订单是选 OEM 时供应商必填销售部门/销售员销售订单是部门变化时销售员列表联动料号/数量/需求日期销售订单明细是无订货号销售订单明细否选定后带出料号生产日期入库单明细是变化时同步更新批次号核算年入库单自动系统按财务规则分配最后说个血泪教训。我早期做类似系统时觉得驳回就是把状态改回去结果上线后单据在审核人和编制人之间来回弹待办列表越积越多。后来才明白驳回不是状态回滚是一次完整的逆向流转要清处理人、记日志、重新分配待办少一步都会留坑。从那以后我每次设计状态机都强制把每个动作的前置条件、后置影响、日志记录三样写全再动手。希望帮到你。本文还有配套的精品资源点击获取
简介这份WMS系统操作手册面向仓库管理员、供应链管理者及ERP实施人员聚焦仓储日常作业的规范化操作帮助读者快速上手浙江三花智能控制股份有限公司自主开发的Web版仓储管理系统。手册围绕销售订单编制、提交与审核销售订单变更主生产计划编辑、审核及抛砖主生产计划变更以及事业部入库等核心业务场景展开逐项说明流程环节、主要操作项与操作演示步骤并附有注意事项便于对照系统界面完成实际作业。资源包共1个docx文档压缩包约23.02MB内容以图文操作说明为主目录按功能模块分层编排便于按需检索。目前已有1658人学习下载适合需要熟悉WMS入库、订单与计划管理流程的从业者作为岗位培训与日常查阅的参考材料。1. 一份手册背后藏着的 WMS 全链路从销售订单到成品出库很多团队拿到仓储系统源码第一反应是翻代码找接口结果在几十张业务单据里绕不出来。我拆这份 WMS 系统操作手册时换了个思路先把它当成一张业务地图来读。它覆盖的是销售订单编制审核、主生产计划编辑抛转、事业部成品入库、物流部验货上架、拣货装车、返工与形态转换、退货这一整条链路采用 B/S 架构浏览器直接访问账号与组织、仓库、部门绑定。适合两类人一是要接手这套系统做二次开发的后端二是要照着流程配置权限和单据流的实施人员。手册本身不是代码但它把每个环节的必填项、状态流转、驳回规则写得极细这些恰恰是数据库表结构和状态机设计的直接映射。读懂它等于拿到了这套 WMS 的数据字典草稿。2. 业务架构拆解七类单据如何串成一条链2.1 从销售订单到主生产计划的单据流转这套系统的骨架是单据驱动。销售订单是源头业务员录入后经所长提交、营业管理岗审核审核通过的单据才会进入制造部计划处的视野。计划处根据销售订单下达成各组织的主生产计划这里有个关键动作叫「抛转」——商贸组织下的主生产计划必须抛转给事业部去生产而智控与制冷组织则直接提交不走抛转。这个差异不是拍脑袋定的它对应的是组织间生产职责的划分商贸组织自己没有产线必须把生产任务转交出去。从数据建模角度看销售订单和主生产计划之间是一对多的关系一张销售订单可以拆成多条主计划行按料号、项目号、订货号区分。订货号这个字段要特别注意手册里反复强调「同项目号同料号不同订货号在系统里是两种库存有订货号与无订货号的主计划也是各自独立互不影响」。这意味着库存维度的主键不是简单的料号而是料号加订货号的组合。二次开发时如果按料号做库存汇总数据一定对不上。状态机方面单据从草稿到提交到审核驳回只能退回上一环节第一个环节不能驳回。这个规则看起来简单实现时却容易翻车驳回操作要记录驳回人和驳回原因还要把单据状态回滚到上一环节的待办池同时清理当前环节的锁定标记。常见做法是在单据主表上维护 current_node 和 status 两个字段驳回时同时更新并在流转日志表里插一条记录。2.2 入库与出库的双向链路事业部入库的流程是事业部计划处根据销售订单完成生产生产环节走的是另一套系统成品仓仓管员根据流转卡拿到完工数量到主生产计划看板编制入库申请单打印物资入库单和外箱条码贴到包装箱上提交给物流部。运转工把实物搬到物流部待验货区物流部验货后上架。这条链路里有两个物理动作和两个系统动作交错系统里提交入库申请物理上搬货系统里验货确认物理上上架。手册特意提醒「确保入库单与入库单对应的实物能明显对应起来方便物流部验货」这就是为什么外箱条码要逐行打印——一个入库单可能对应多个批次每个批次一个条码。出库方向是物流部拣货、装车。拣货依据的是发货计划装车确认后库存扣减。返工和形态转换是两条特殊链路返工出库是把有问题的成品退回事业部返修形态转换则是物料形态发生变化比如半成品转成品需要走单独的出入库对冲。退货功能独立成章流程是退货指令下达、退货接收涉及库存回冲和财务核算月份的归属。这七类单据共享一套基础设施组织权限、仓库绑定、批次管理、条码打印、看板筛选。理解了这个分层再看代码就不会迷路。2.3 权限与组织模型手册里多处提到「账号绑定所处事业部默认成品仓库」「销售部门、销售员自动带出且联动变化」。这说明权限模型是组织驱动的用户登录时选择组织系统根据组织加载对应的仓库、部门、可操作的单据类型。销售员和销售部门联动本质上是组织架构树上的父子关系查询——选定部门后只列出该部门下的销售员。实现上常见做法是三张表组织表、用户组织关系表、仓库组织关系表。登录时校验用户属于哪些组织选定组织后把 org_id 写入 session后续所有单据查询都带 org_id 过滤。这里有个容易忽略的点跨组织抛转时单据的归属组织会变化但原始销售订单的组织不变。所以单据表上至少要存两个组织字段source_org 和 current_org抛转时更新 current_orgsource_org 保持不变用于追溯。3. 关键操作落地从登录到入库单生成的完整路径3.1 登录与组织选择系统访问地址是内网 IP 加端口用浏览器打开。登录界面三行输入第一行选组织第二行填员工编号第三行填密码账号密码默认都是员工 ID。这个设计很朴素但暴露了一个实施细节组织选择在登录时完成意味着同一个员工如果属于多个组织需要多次登录切换。二次开发如果要支持组织切换不重新登录就得把组织选择从登录环节挪到会话内做成顶部下拉切换。登录成功后系统加载该组织的菜单权限。手册里说「在发起任务中找到事业部入库申请或点击新建进入」说明菜单是按角色配置的。新建按钮和发起任务入口指向同一个表单区别在于新建是空白单发起任务是带上下文的。// 登录请求示例组织、工号、密码三要素 const loginPayload { orgCode: ORG_001, // 组织编码决定后续数据权限范围 employeeId: 11107618, // 员工编号同时作为默认账号 password: ****** // 默认与工号一致首次登录后应强制修改 }; // 登录成功后服务端返回会话令牌与组织上下文 // 后续所有请求头携带 token服务端据此过滤 org_id这段逻辑说明登录不只是身份校验更是数据权限的起点。参数里 orgCode 决定了 session 中的 org_idemployeeId 既做账号也做人员标识。实际部署时默认密码等于工号是个安全隐患二次开发第一件事就该加首次登录强制改密。3.2 事业部入库单的编制入库单编制分三步选主生产计划、改数量和批次、保存并打印条码。第一步点「主生产计划看板」勾选要入库的产品行点确认选择带入表单。如果实际入库数量大于看板单行数量要勾选两行同项目号同料号同订货号的主计划。第二步改数量数量不能大于可用数量改生产日期会同步更新生产批次字段一张单要多个批次就复制行再改。第三步保存生成单据号然后逐行打印外箱标贴。这里的核心约束是「可用数量」。可用数量等于主计划数量减去已入库数量每次入库申请提交时扣减驳回或删除时归还。实现上要么在提交时实时计算要么维护一个已入库数量字段做增量更新。实时计算更安全但查询压力大增量更新快但容易因并发出错。我一般会在主计划表上加一个 locked_qty 字段提交时用乐观锁更新版本号对不上就提示重试。-- 入库申请提交时扣减主计划可用量乐观锁 UPDATE mps_line SET locked_qty locked_qty :apply_qty, version version 1 WHERE id :mps_line_id AND version :expected_version AND plan_qty - locked_qty :apply_qty; -- 影响行数为 0 说明并发冲突或可用量不足需回滚并提示参数说明apply_qty 是本次申请入库数量plan_qty 是主计划总量locked_qty 是已锁定数量。where 条件里同时校验版本号和可用量一条语句解决并发和超量两个问题。这种写法比先查后改少一次往返也避免了查改之间的窗口期。3.3 条码打印与批次管理外箱标贴的打印逻辑是逐行触发选中行号区域整行拉蓝点更多右侧的黑色小箭头选打印外箱标贴。多行批次就依次逐行打印。条码内容通常包含单据号、料号、批次号、数量扫码枪扫出来能直接定位到入库单行。批次号由生产日期驱动生产日期变了批次跟着变。这意味着批次号不是独立输入的而是日期格式化加流水。常见做法是批次号等于生产日期加当日流水比如 20240327-001。二次开发如果要支持自定义批次规则得把批次生成逻辑抽成策略接口按物料类别配置不同规则。提示复制行时数量必须小于等于所选主计划的可用数量否则保存失败。这个校验在复制动作时就要做不能等到保存才提示否则用户填了半天才被打回。4. 避坑与排查五个真实会卡住你的地方4.1 订货号为空导致库存对不上现象入库单保存成功但库存查询里找不到这批货或者数量比预期少。原因主生产计划行有订货号和无订货号被视为两种独立库存入库时如果选错了行选了无订货号的行实际货物有订货号库存就记到了另一个维度。解决入库前核对主计划行的订货号与实物标签是否一致看板筛选时把订货号列显示出来不要隐藏。4.2 抛转后原组织查不到单据现象商贸组织把主生产计划抛转给事业部后原组织在待办里看不到这张单了以为丢了。原因抛转更新了单据的 current_org原组织的待办查询按 current_org 过滤自然查不到。解决待办列表增加「我发起的」页签按 source_org 查询或者在抛转日志里保留流转记录供追溯。4.3 驳回后单据卡在中间状态现象审核环节驳回单据回到编制人手里但编制人修改后再次提交审核人待办里不出现。原因驳回时只改了状态没清当前处理人或者再次提交时没有重新分配待办。解决驳回操作要同时做三件事——状态回滚、当前处理人置空、流转日志插记录提交操作要重新计算下一环节处理人并写入待办表。4.4 批次复制行数量超限现象复制行后修改数量保存时报错「数量不能大于可用数量」。原因复制行默认带出原行数量两行加起来超过了主计划可用量。解决复制行时数量默认置零或置为剩余可用量让用户主动填保存前做汇总校验把同一主计划行的所有明细数量加起来比对可用量。4.5 内网访问与浏览器兼容现象用某些浏览器打开页面样式错乱或按钮点不动。原因系统是 B/S 架构且年代较早前端可能依赖特定浏览器的渲染行为。解决统一用谷歌浏览器访问内网地址固定如果要做前端改造先摸清现有页面的 DOM 结构和事件绑定方式不要贸然换框架。5. 二次开发改造从手册反推数据模型与扩展点拿到这套系统做二次开发我的习惯是先用手册里的字段清单反推表结构再找扩展点。手册第 3.1.2 节列出的销售订单界面要素——客户、订单方式、销售部门、销售员、币种、供应商、立账条件、料号、数量、客户需求日期、项目号、订货号——基本就是销售订单主表和明细表的字段集合。其中客户决定币种和立账条件说明客户主数据表上挂着默认值订单方式选 OEM 时供应商必填说明这是个条件必填规则适合做成表单联动校验。扩展点我一般看三个地方。第一是单据状态机手册里每个功能都有保存、提交、驳回、删除四个动作状态流转是固定的如果要加「撤回」功能就在提交和审核之间插一个状态同时改待办查询逻辑。第二是看板筛选销售订单看板、主生产计划看板都是查询入口筛选条件手工添加、多条件用空格分开这个搜索解析逻辑可以抽成公共组件所有看板复用。第三是条码打印逐行打印的触发方式比较原始可以改成批量打印但要注意批次和数量的对应关系不能乱。验证方法上我建议先跑通一条最小链路建一张销售订单提交审核下主计划抛转事业部入库物流部验货上架然后查库存。这条链路走通说明组织权限、状态流转、库存扣减三个核心机制没问题。再跑返工和退货两条反向链路验证库存回冲和财务月份归属。最后用两个不同组织的账号交叉操作验证数据隔离。有个表格可以对照着看关键字段的归属字段所属单据是否必填联动规则客户销售订单是带出币种、立账条件订单方式销售订单是选 OEM 时供应商必填销售部门/销售员销售订单是部门变化时销售员列表联动料号/数量/需求日期销售订单明细是无订货号销售订单明细否选定后带出料号生产日期入库单明细是变化时同步更新批次号核算年入库单自动系统按财务规则分配最后说个血泪教训。我早期做类似系统时觉得驳回就是把状态改回去结果上线后单据在审核人和编制人之间来回弹待办列表越积越多。后来才明白驳回不是状态回滚是一次完整的逆向流转要清处理人、记日志、重新分配待办少一步都会留坑。从那以后我每次设计状态机都强制把每个动作的前置条件、后置影响、日志记录三样写全再动手。希望帮到你。本文还有配套的精品资源点击获取
