老WMS操作手册拆解：状态机、业务约束与二次开发校验

简介《WMS系统操作手册》面向仓库管理员、供应链管理者及ERP/WMS实施与运维人员。文档围绕浙江三花智能控制股份有限公司自主开发的Web端仓储管理系统梳理从销售订单编制、提交、审核到订单变更的完整操作路径并覆盖主生产计划编辑、审核、抛砖与变更以及事业部入库、物流部验货上架等场景各章节按流程说明、操作项拆解、界面演示、注意事项的顺序展开适合作为企业内部培训教材或供学习者对照系统界面逐步演练。资源包共1个文件为docx格式的操作手册压缩包约23.02MB内置大量界面截图图文对照便于按模块查阅也方便打印成册或摘取章节做培训材料。该资源已有1659人学习读者可借此掌握WMS各业务环节的规范操作与关键控制点也能为新系统上线前的流程梳理和岗位交底提供参考。1. 一份只有操作手册的 WMS反而更值得拆接手一套跑了好几年的仓储系统最容易翻车的场景不是代码看不懂而是整个系统只剩一份 WMS 操作手册新人培训全靠老员工口口相传。手上的这份资料来自某制造集团应用开发中心的 WMS 项目版本 V1编制时间 2017 年正文覆盖销售订单编制审核、订单变更、主生产计划编辑与抛转、事业部入库、物流部验货上架、拣货装车、返工与形态转换、退货共十余条业务线末尾还挂了一份常见问题联系清单。它更适合当作「业务规则说明书 二次开发需求来源」来读不适合当成新人教程。适合两类人一类是要接手老系统运维、得快速搞清每个角色在哪个环节卡住的另一类是要照着手册把流程重做进新系统、需要知道哪些字段是硬约束的。2. 手册骨架与运行环境先摸清模块边界再谈怎么跑拿到手册别急着从头翻先看目录。这份文档的三级标题看着零散其实按角色和业务域能重排成五块订单域、计划域、仓储执行域、逆向域、附录。重排完再回头看每一节的「流程及环节简要说明—主要操作项说明—操作流程演示」三段式你会发现它是同一个模板套出来的理解了模板就等于理解了整本手册的写法。2.1 从目录反推模块边界手册正文的编号从 3.1 排到 3.12中间还有断号直接读会迷路。我一般按业务域重新归档一遍落到目录上大概是这样# WMS 操作手册按业务域重排章节号对应原手册编号 wms-manual/ ├── 01-overview/ # 1 引言、2 软件概述用途、BS 架构、访问方式 ├── 02-order/ # 3.1 销售订单编制/提交/审核 3.2 销售订单变更 ├── 03-plan/ # 3.3 主生产计划编辑/审核/抛转 3.4 主生产计划变更 ├── 04-inbound/ # 3.5 事业部入库申请 3.6 物流部验货、上架 ├── 05-outbound/ # 3.7 物流部拣货、装车 3.8 返工、形态转换 ├── 06-reverse/ # 3.9 返工功能 3.12 退货功能 └── 07-appendix/ # 4.1 常见问题联系清单这一层归档的价值在于标出角色边界。02-order的操作者是业务员、内务员、所长、营业管理岗03-plan换成了制造部计划员和主管04-inbound往下是事业部成品仓仓管员、运转工、物流部验货员05-outbound是物流部拣货和装车岗。每个域换一次人换人处就是审批节点也是权限配置最容易配错的地方。提示手册里的「抛砖」是原文用词按上下文语义应为「抛转」指把主生产计划转交给事业部执行。做二次开发时字段名、按钮名、接口名三处必须统一成同一个词否则前后端联调时会互相找不到。2.2 单据状态机保存、提交、驳回、弃审其实是同一套骨架手册把「保存」「提交」「驳回」「弃审」「删除」拆在十几个小节里各讲一遍读起来像是每张单据各有一套规则。实际不是这套系统所有单据共用一套状态机只是每张单据允许的流转边不一样。把这层抽出来后面看任何一节都能对上号。# 单据公共状态机手册中散落在各章节的按钮本质是下面这张流转表 STATES (DRAFT, SUBMITTED, APPROVING, APPROVED, THROWN, CLOSED) TRANSITIONS { (DRAFT, save): DRAFT, # 保存生成单据号仍处草稿 (DRAFT, submit): SUBMITTED, # 提交流入下一环节待办出现 (SUBMITTED, approve): APPROVED, # 审核通过 (SUBMITTED, reject): DRAFT, # 驳回退回上一环节编制人 (APPROVED, throw): THROWN, # 抛转商贸组织转事业部执行 (APPROVED, unaudit): DRAFT, # 弃审已审单据退回重编 (THROWN, close): CLOSED, # 关闭余量归零或返工主计划关闭 } def transit(doc, action, operator): key (doc.status, action) if key not in TRANSITIONS: raise BizError(f单据 {doc.no} 当前状态 {doc.status} 不支持 {action}) if doc.status SUBMITTED and action reject and doc.is_first_node: raise BizError(流程第一个环节不允许驳回) # 手册明确写的限制 return TRANSITIONS[key]这段代码要看的不是语法是三条业务约束。第一save落在DRAFT上说明保存只生成单据号不推进流程所以草稿被误删不会影响业务。第二reject只能从SUBMITTED出发is_first_node为真时直接拦掉对应手册里「当流程处理第一个环节无法执行驳回功能」。第三unaudit是审核之后才有的后悔药手册里叫「单据弃审功能」弃审完单据回到编制人手上可以重编也可以删除。2.3 运行环境与账号体系BS 架构下的三个前提软件概述写得很短BS 架构浏览器访问建议 Chromium 内核浏览器必须在特定内网环境使用。这三句话翻译成运维动作就是三件事——浏览器版本、网络可达、账号组织选对。前两个好办第三个是新人最常卡的地方登录页第一行选组织第二行填员工编号第三行填密码账号密码默认都是员工编号。组织选错不会报错只会看到一片空白的待办列表。# 排查页面打不开的连通性三步地址为示例按实际环境替换 curl -I --max-time 5 http://10.12.34.56:8080/wms/login # 服务是否存活看 HTTP 状态码 nc -zv 10.12.34.56 8080 # 端口是否放通不通就是网络策略问题 curl -I --max-time 5 http://10.12.34.56:8080/wms/health # 健康检查返回 503 多半是应用连不上库--max-time 5是必须加的内网故障时请求会一直挂着不设超时排查人员会以为是自己卡了。nc -zv只探端口不做业务请求用来区分「网络不通」和「应用挂了」这两种现象在用户侧表现完全一样都是转圈。注意登录账号默认是员工编号密码也默认是员工编号这是典型的历史遗留设计。做安全改造时不要直接改默认密码规则老账号没有邮箱和手机号可用来找回一改就是大面积锁号得先补一套管理员重置流程。2.4 哪些字段是自动带出的为什么不能随便改成手填手册在销售订单、入库申请两节里反复出现「系统自动带出」「由系统自动分配」这些字段构成了整套系统的隐性数据契约二次开发时把它们改成手填等于把数据一致性交给用户。字段来源是否可改改动后果币种、立账条件客户主数据否改错会导致应收对不上账销售员销售部门联动部门内可选跨部门选不到人属正常供应商订单方式为 OEM 时才必填是非 OEM 订单填了会被下游拒收操作仓库、业务部门登录账号绑定否换仓要换账号不能页面上切核算年系统按业务日期分配否跨月入库会影响财务归属月份库存操作类型单据类型决定二选一事业部入库只能选成品入库这张表看着平淡实际是排查工单时最常翻的一页。用户说「这个单子物流部看不到」八成是因为业务部门或操作仓库绑错了账号单据提交到了另一个组织的待办池里。3. 订单与前计划段从销售订单到主生产计划抛转这一段是整本手册里逻辑密度最高的部分涉及国内、国际两条订单录入流程以及销售订单变更、主生产计划编制审核、主生产计划变更四张单据。四张单据之间存在强依赖订单不审核计划员看不到看板数据主计划不抛转事业部那边就没有生产任务。搞清楚依赖顺序比记住每个按钮在哪重要得多。3.1 销售订单编制必填项、自动带出与可用量锁定手册把界面要素拆成九条我按「谁决定谁」重新归了一下类。客户是源头选了客户币种和立账条件自动带出订单方式决定是否要填供应商销售部门和销售员是联动下拉部门变了人选范围跟着变表格区的料号、数量、客户需求日期三列必填项目号选填但要理解它的默认逻辑——选完客户再新增行系统会按客户与项目号的绑定关系带出默认项目号可以手工改订货号也是选填填了会自动带出料号。国内流程是「业务员录入 → 所长提交 → 营业管理岗审核」国际流程是「内务员录入 → 单证处审核」两条流程共用同一个录入界面差别只在审批链。这个设计挺常见配置化审批链挂在单据类型上前端不区分。保存之后系统生成单据号、落草稿同时做一件容易被忽略的事库存自由量大于零时保存动作会把可用量锁住锁定结果直接显示在表格里。这条规则意味着「先保存后删除」不是无副作用的草稿期间已经占用了可用量别人下同样的料号可能就提示不够。# Excel 导入前的行级校验模板列与集团 ERP 保持一致 REQUIRED [客户编码, 订单方式, 销售部门, 销售员, 料号, 数量, 客户需求日期] def check_row(row, idx): errs [] for col in REQUIRED: if not str(row.get(col, )).strip(): errs.append(f第{idx}行{col} 为空) if row.get(订单方式) OEM and not row.get(供应商): errs.append(f第{idx}行OEM 订单必须指定供应商) if float(row.get(数量) or 0) 0: errs.append(f第{idx}行数量必须大于 0) if not (row.get(料号) or row.get(订货号)): errs.append(f第{idx}行料号与订货号至少填一个) return errs导入是最容易出问题的地方因为错误提示往往只告诉你「导入失败」不告诉你哪一行错。我的做法是先在本地跑一遍这段校验把错误一次性收集完再贴回给用户避免用户改一行导一次、来回十几趟。日期列要统一成yyyy-MM-ddExcel 里被识别成日期格式的单元格导出后会变成序列号这是血泪经验里最常见的一条。3.2 销售订单变更看板取数、变更原因与弃审订单变更不是直接在原单上改而是新起一张变更单通过看板把原销售订单捞出来。看板支持按业务单号、物品、项目号、订货号、客户代码、需求时间筛选筛选条件要手工添加选中的行点「确认选择」回填到变更单表单然后改需求数量或日期。变更单上有几个自动生成的字段值得记业务单号、发起部门、发起人、发起时间由系统匹配变更原因必须用文字写清楚这是后续追溯的唯一凭据。保存后系统生成单号落草稿提交后流转到制造部计划处指定人员做变更指令接受。这里有个手册自身的小坑变更单保存那一条写的是「系统自动生成返工单号」从上下文看应该是变更单号属于文档笔误。真按字面去核对返工单会找不到对应单据。弃审功能用在驳回之后。业务被驳回单据回到营业部编制人手上编制人可以重新编制也可以直接删掉取消这次变更。弃审和驳回不是一回事驳回是审核人把单子退回去弃审是编制人主动把已经审核通过的单子撤回重编。3.3 主生产计划编辑、审核与抛转商贸组织为什么多一步计划员的工作起点是销售订单看板。勾选已审核的订单、确认选择订单行进入主生产计划编辑单保存后生成业务单号同时编制人默认取当前登录账号。单据上有个 OEM 开关勾了就必须选供应商用于委外生产场景。真正需要理解的是「抛转」这一步。商贸类组织自己没有生产实体主生产计划编制、审核完之后要抛给对应事业部去执行有生产实体的组织审核完直接提交即可。操作路径是「协同 → 抛转 → 确认 → 保存 → 提交 → 确认提交」六步里前两步是选目标组织后四步跟普通提交一样。判断依据手册给得很明确商贸组织下的主生产计划都需要抛转其余直接提交。// 抛转前的前置校验别等点完六步才发现目标组织选错 function checkThrow(plan, targetOrg) { if (plan.status ! APPROVED) throw new Error(只有已审核的主计划可抛转); if (!plan.lines.every(l l.qty 0)) throw new Error(存在数量为 0 的行先清理再抛转); if (targetOrg.id plan.orgId) throw new Error(目标组织不能与编制组织相同); const left plan.lines.reduce((s, l) s (l.qty - l.inboundQty), 0); // 剩余未入库量 if (left 0) throw new Error(该主计划已全部入库无需抛转); return true; }left这个剩余未入库量是后面所有变更操作的核心指标。抛转不是把整张单子送过去而是把剩余量送给事业部事业部每入库一次剩余量减一次减到 0 这条抛转关系就关闭了。3.4 主生产计划变更的三条路径选错就得多干一遍手册 3.4 节写得最绕但它其实是三条并列的处理路径选哪条取决于「事业部有没有入库」和「主计划是不是返工产生的」两个条件。场景判断条件操作位置结果抛转后事业部未完成入库已入库量 销售订单量销售订单变更变更剩余未入库的主计划量抛转后事业部已全部入库已入库量 主计划量销售订单编辑页的订单取消关闭发货行变更后数量填 0返工归还生成的返工主计划返工单类型选错导致未归还对应组织返工申请页「更多」箭头里关闭返工主计划第一条的约束要记牢变更后的数量必须大于等于事业部已入库数量、小于销售订单数量。变更后数量正好等于已入库量时该事业部剩下的主计划数量被关闭。第二条常用于事业部返工单选错类型、导致主计划没归还的情况制造部用它把主生产计划补回去让数量和发货计划对齐操作是先输销售订单号查询、选中料品行、在右下角「变更后数量」填 0、保存。第三条藏在返工申请页的「更多」小箭头里不看手册基本发现不了。4. 仓储执行段入库、上架、拣货装车与逆向闭环仓储执行域覆盖 3.5 到 3.9 再加 3.12是手册里篇幅最大的一段。事业部入库写得极细字段级说明有二十条物流部验货上架、拣货装车则只有流程标题和注意事项具体操作靠演示截图。这种详略不均的老手册很常见——写的人是谁哪一节就写得多。4.1 事业部入库申请从主计划看板勾选到生成入库单流程是四个岗位接力事业部计划处按销售订单完成生产走 ERP 生产流程、成品仓仓管员根据流转卡在系统里编制事业部入库申请单、打印物资入库单和外箱条码贴到包装箱对应区域、运转工把实物和单据一起搬到物流部待验货区。编制环节的几个要点操作仓库和业务部门都由账号绑定带出仓管员不用选也选不了库存操作类型只有成品入库和返工入库两个选项事业部入库必须选成品入库供应商名称一栏显示的是主计划订单项目号对应的客户名称名字叫供应商但填的是客户这是历史字段命名问题来源仓库和来源部门在事业部成品入库场景下不填。数量有两个关键列。「可用数量」是该订单当前剩余可入库数量「总数量」是销售订单的总出货目标数。录入数量不能超过可用数量超了保存不了。实际入库量大于看板单行数量时勾选两行同项目号、料号、订货号的主计划一起带过来。注意同项目号同料号但订货号不同的主生产计划在系统里是两种独立库存有订货号和无订货号的主计划也各自独立互不影响。核对数量时按「项目号 料号 订货号」三元组匹配少一个维度就会算错可入库量。4.2 物流部入库验货、上架与库存状态迁移手册这一节主要给流程图和注意事项字段说明很少。按同类系统的常见做法验货上架环节至少包含三件事核对单据与实物、记录质检结论、分配上架库位。核对方式是扫外箱条码扫出来的入库单号、料号、批次与待验区实物比对对不上的挂异常质检结论分合格、让步接收、不合格不合格的进不良品区不进可用库存上架库位一般由系统按库区、容量、周转规则推荐允许手工指定但要受库区权限约束。状态迁移是这一节最该写清楚但没写清楚的部分。事业部提交的入库单到物流部只是「待验」库存在系统里还不是可用量验货通过并完成上架确认之后库存才从待验状态转成可用状态这时候销售订单那边锁定的可用量才算真正兑现。很多「明明入库了为什么还提示库存不足」的问题根源就在上架确认这一步没点。-- 查一张单为什么卡在待验看状态与上架时间的差异 SELECT d.doc_no, d.status, d.org_id, d.warehouse_id, d.submit_time, l.putaway_time, l.qc_result FROM wms_doc d JOIN wms_doc_line l ON l.doc_id d.id WHERE d.doc_no RK20240315001;status是SUBMITTED而putaway_time为空说明单到了物流部但没人做上架确认qc_result为空则是质检结论还没录。这两个字段分开看能快速判断卡在哪个岗位。4.3 物流部出库拣货、复核与装车过账出库段手册只给了「拣货、装车」的流程标题具体步骤同样按同类系统的常见做法补发货计划下达到物流部后生成拣货任务任务按库位路径排序减少走动拣货员扫码拣货扫错料号当场报警拣完进复核区二次扫码核对核对通过装车装车完成做出库过账库存扣减、单据关闭。有两处容易翻车。第一拣货任务的库位排序依赖库位主数据的坐标库位坐标没维护的组织任务顺序是乱的拣货员会来回跑。第二装车过账和实际发运时间往往不一致月底对账时以哪个为准要在实施阶段就定下来否则财务和物流两边永远对不上数。# 拣货异常时按单号捞日志看是扫码失败还是库存校验拦截 grep -n SO20240315007 /opt/wms/logs/wms-app.log | tail -50 grep -n QTY_NOT_ENOUGH\|BARCODE_MISMATCH /opt/wms/logs/wms-app.log | tail -20第一行捞这张单的全部日志第二行按错误码过滤看有没有库存不足或条码不匹配的记录。日志里带请求号的话顺着请求号能把一次扫码的完整链路串起来。4.4 返工、形态转换与退货逆向单据怎么闭环返工在手册里出现了两次3.8 是物流部返工出库3.9 是返工功能本身容易看成两件事。实际是一条闭环成品需要返工先从成品仓做出库到车间单据类型选返工出库车间处理完再入库入库时库存操作类型选返工入库而不是成品入库。这一选错库存就回到了成品口径返工履历断掉后面制造部想归还主计划也归不了——手册 3.4 节专门提到「事业部返工单选错类型导致没有归还主计划」就是这个情况。形态转换是一进一出两张单比如整箱拆零、组件拆解、包装更换。要点是转换前后料号可能相同也可能不同相同料号靠批次区分不同料号要建转换关系表。转换单不做金额核算只做数量与库存状态的迁移。退货走销售退回单退货入库后先落待检区质检判定良品才转可用库存不良品走报废或返工流程。手册在注意事项里强调退货单要关联原发货单不然批次追溯就断了。5. 避坑与排查现场五类卡单记录手册第 4 章只有一份「常见问题联系清单」谁负责哪个模块、电话多少没有一条讲现象和原因。下面这五条是照着流程跑下来最容易撞上的按「现象 → 原因 → 解决」记。5.1 单据流转类卡单第一条提交了对方看不到。现象是仓管员说入库单已提交物流部待办里空空如也。原因多半是登录组织选错单据提交到了另一个组织的待办池或者账号绑定的业务部门与该单据的业务部门不一致。解决办法是先按单据号查状态和org_id确认单据归属组织再核对操作人账号绑定的组织与仓库不一致就换账号重登不要试图在页面上改归属。第二条驳回按钮点不动。现象是流程第一个环节的操作人找不到驳回按钮或点了无反应。原因就是手册写死的那条规则流程第一个环节无法执行驳回。解决方式是让编制人直接删除重编或者走弃审别在第一个节点上耗。第三条主计划抛转后事业部没收到。现象是计划员点了提交事业部计划员的待办里没有任务。原因通常是组织类型判断错了——只有商贸类组织下的主生产计划才需要抛转有生产实体的组织直接提交即可反过来在非商贸组织上找抛转入口当然找不到也有可能是抛转的六步里漏了最后的「确认提交」。解决办法是先确认编制组织类型再看单据状态是不是停在APPROVED没到THROWN。5.2 数据与打印类卡单第四条外箱标贴打出来箱号全是 1。现象是一张入库单有多个批次打印出来的标贴条码全一样。原因是只打了第一行手册要求逐行打印点行号把整行拉蓝再点「更多」右边的黑色小箭头选打印外箱标贴多行批次依次逐行打。解决方式是把打印动作从「整单打印」改成「按行打印」模板里的箱序号用行号加行内序号生成。{ template: carton_label_80x60, fields: { barCode: {{docNo}}-{{lineNo}}-{{boxSeq}}, materialCode: {{materialCode}}, batchNo: {{produceDate}}-{{seq}}, qty: {{boxQty}}, projectNo: {{projectNo}} } }barCode里必须带lineNo和boxSeq只带单号必然重复batchNo由生产日期加流水拼出来生产日期一改批次跟着变这也是系统里生产日期和批次联动的原因。第五条复制行保存不了。现象是一张入库单要录多个批次复制第一行后改数量保存报错。原因是复制行数量之和超过了所选主生产计划的可用数量手册写得很明确复制行数量必须等于或小于所选主计划可用数量不够就保存不了。解决办法是先算清楚这张主计划还剩多少可入库量再决定拆几行、每行多少别边复制边试。6. 二次开发把手册里的隐式规则变成代码里的显式校验这份手册最值钱的地方是它把一堆口头约定写成了文字比如「入库数量不能大于可用数量」「复制行数量之和不能超过主计划可用量」「同料号不同订货号是两种库存」。这些规则现在的实现方式基本靠前端提示加后端兜底提示词还很含糊用户只知道保存失败不知道错在哪。重做或改造时第一件事就是把这些规则提到服务层做显式校验并且返回结构化错误。# 入库保存前的显式校验替代手册里不能大于可用数量的口头约定 def validate_inbound_qty(doc, line): avail get_available_qty(line.mps_id) # 主计划剩余可入库量 used sum(l.qty for l in doc.lines if l.mps_id line.mps_id) if line.qty 0: raise BizError(E1001, f行{line.no} 数量必须大于 0) if used avail: raise BizError( E1002, f行{line.no} 超出可用量可入库 {avail}本单已占用 {used}, detail{mpsId: line.mps_id, avail: avail, used: used}, ) return True关键是detail这一段。老系统只返回「保存失败」运维得去数据库里翻主计划余量带上mpsId、avail、used三个值前端就能直接在行上标红并显示差额用户自己就能改对。同样的思路可以用在抛转校验、复制行校验、批次拆分校验上一套错误码配一份错误文案表比散落在各 Service 里的字符串好维护得多。第二个改造点是批次与条码。生产日期改批次联动、外箱标贴按行打印这两条现在耦合在页面逻辑里一旦有移动端扫码枪接入就得重写。把「入库单行 → 批次 → 箱」拆成三层数据结构条码只承载唯一键展示信息全部后端拼装打印端和扫码端就都能复用。最后一个建议是别急着推翻审批链。手册里国内国际两条链、商贸与非商贸两种提交方式看着乱其实是组织架构的真实映射重构时先把它配置化成「组织类型 单据类型 → 审批链」的映射表跑一段时间对完账再动代码。这套手册我前后翻过三遍第一遍当教程看第二遍照着排查工单第三遍才是拿着它去对字段和状态。教训是第一次接手时偷懒觉得流程图上箭头连起来就懂了结果上线第一个月就被「同料号不同订货号」坑了一次库存对了两天才对平。从那以后我每次碰这类老系统都先把状态机和字段来源表抄一遍贴在显示器边上跑通一张单再动第二张。希望帮到你。本文还有配套的精品资源点击获取