企业官网建设流程全解析

简介：这份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_org，source_org 保持不变用于追溯。

3. 关键操作落地：从登录到入库单生成的完整路径

3.1 登录与组织选择

系统访问地址是内网 IP 加端口，用浏览器打开。登录界面三行输入：第一行选组织，第二行填员工编号，第三行填密码，账号密码默认都是员工 ID。这个设计很朴素，但暴露了一个实施细节：组织选择在登录时完成，意味着同一个员工如果属于多个组织，需要多次登录切换。二次开发如果要支持组织切换不重新登录，就得把组织选择从登录环节挪到会话内，做成顶部下拉切换。

登录成功后，系统加载该组织的菜单权限。手册里说「在发起任务中找到事业部入库申请或点击新建进入」，说明菜单是按角色配置的。新建按钮和发起任务入口指向同一个表单，区别在于新建是空白单，发起任务是带上下文的。

// 登录请求示例：组织、工号、密码三要素 const loginPayload = { orgCode: "ORG_001", // 组织编码，决定后续数据权限范围 employeeId: "11107618", // 员工编号，同时作为默认账号 password: "******" // 默认与工号一致，首次登录后应强制修改 }; // 登录成功后服务端返回会话令牌与组织上下文 // 后续所有请求头携带 token，服务端据此过滤 org_id

这段逻辑说明登录不只是身份校验，更是数据权限的起点。参数里 orgCode 决定了 session 中的 org_id，employeeId 既做账号也做人员标识。实际部署时默认密码等于工号是个安全隐患，二次开发第一件事就该加首次登录强制改密。

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 时供应商必填，说明这是个条件必填规则，适合做成表单联动校验。

扩展点我一般看三个地方。第一是单据状态机，手册里每个功能都有保存、提交、驳回、删除四个动作，状态流转是固定的，如果要加「撤回」功能，就在提交和审核之间插一个状态，同时改待办查询逻辑。第二是看板筛选，销售订单看板、主生产计划看板都是查询入口，筛选条件手工添加、多条件用空格分开，这个搜索解析逻辑可以抽成公共组件，所有看板复用。第三是条码打印，逐行打印的触发方式比较原始，可以改成批量打印，但要注意批次和数量的对应关系不能乱。

验证方法上，我建议先跑通一条最小链路：建一张销售订单，提交审核，下主计划，抛转，事业部入库，物流部验货上架，然后查库存。这条链路走通，说明组织权限、状态流转、库存扣减三个核心机制没问题。再跑返工和退货两条反向链路，验证库存回冲和财务月份归属。最后用两个不同组织的账号交叉操作，验证数据隔离。

有个表格可以对照着看关键字段的归属：

最后说个血泪教训。我早期做类似系统时，觉得驳回就是把状态改回去，结果上线后单据在审核人和编制人之间来回弹，待办列表越积越多。后来才明白，驳回不是状态回滚，是一次完整的逆向流转，要清处理人、记日志、重新分配待办，少一步都会留坑。从那以后我每次设计状态机，都强制把每个动作的前置条件、后置影响、日志记录三样写全再动手。希望帮到你。

本文还有配套的精品资源，点击获取