WMS入库单据设计，用4张单、3张单还是1张单？
在之前的供应链产品经理私享课或是训练营课程当中，当我讲到WMS的入库类单据的时候，经常会有一些学员在听课的过程或者听课之后产生一些疑问。
其中最高频的疑问就是觉得入库类的单据有好多种名称、好多种叫法，很容易搞混。例如说有一些WMS叫ASN，有一些叫到货通知单，有一些叫入库单，有一些叫入库通知单，还有一些叫收货单。除了这些单据之外呢，后面还有质检单、上架单，这后面的两张单跟前面的那几张单是怎么关联的、关联关系是什么，经常容易搞混。
这里面并不是说这些单据本身很难，主要是因为名词定义不清楚，导致很多人在讲同一件事情的时候容易出现GAP，大家理解上面会有误差。
结合我之前做WMS的经验，以及我自己去做竞品调研和分析，再加上我跟AI的一些沟通和对话，我写了这篇科普性的文章，对这一块的单据做了拆解、下了定义，便于有疑问的学员更好地理解这些知识，也分享给其他在学这一块知识的朋友们，希望这篇文章可以帮助你们更好地去理解WMS入库环节中常见的业务单据的概念。
业务单据的定义与命名方式
首先，我们把入库过程中涉及到的这几张核心单据的定义先拉通一下。我这里给出的命名方式是我个人比较推荐的，不一定跟你的系统完全一致，但我觉得这样定义会更精准，听起来也更好理解。
入库通知单（也叫ASN）
这张单是上游系统推送给WMS的一份到货预告。它告诉仓库：某某供应商在什么时间会送来什么货、送多少。它的核心作用是让仓库提前知道“要来的东西是什么”，方便提前安排库位、人员和设备。
我个人比较推荐叫它“入库通知单”或者“ASN”，因为这两个名字都比较明确地表达了“通知”的意思——它不是一个执行单据，是一个预告。
收货单
基于入库通知单去做实物收货之后，会生成一张收货单。这张单记录的是“实际收到了什么”——实际数量、批次信息这些。
这里有一个关键点：入库通知单可以多次收货。比如供应商说送1000件，今天只到了300件，可以收300件生成一张收货单，明天剩下的700件到了再收一次，再生成一张收货单。一个入库通知单可以对应多个收货单。
收货单是一张结果单据，它记录的是已经发生的事实。收货完成后，收货单可以通过接口回传到上游的OMS或ERP做入库过账，也可以等上架完成之后再回传。同时，收货单也可以打印出来作为回执单据。
质检单
如果这批货是需要质检的，那么可以基于收货单去生成质检单（也可以叫质检任务单）。质检单是一张可执行的单据——质检员拿着它去验货，在上面记录质检结果。
这里有一个设计细节：一张收货单可以拆分成多个质检单。比如说收货单上有10个SKU，可以把其中3个SKU分给A质检员，另外7个分给B质检员，同时做质检。也可以整张收货单只生成一个质检单。
上架单
质检完成之后，会生成上架单。这里有一个比较关键的设计：一张质检单最多可以拆成两张上架单——一张是良品上架，一张是次品上架。因为良品和次品要分开上架到不同的库位库区，所以要拆分成不同的上架单类型。
到这一步，入库的完整链路就走完了。
我整理了一下，这四张单的核心职责分别是：
| 单据 | 类型 | 核心职责 |
|---|---|---|
| 入库通知单（ASN） | 预告单 | 告诉仓库“将要来什么” |
| 收货单 | 结果单 | 记录“实际收到了什么” |
| 质检单 | 执行单 | 记录“东西品质怎么样” |
| 上架单 | 执行单 | 记录“放到了哪里” |
前面说的是单张单据的定义。那在实际的产品设计当中，这些单据之间的流转关系和实体关系有好几种不同的做法。我分享一下做竞品调研的时候遇到的几种典型方案，看看有没有你见过的。
方案一：四单据模式
前面把每张单的定义拉通了。方案一就是按这个定义走——四张单各管各的，每一张都是独立的可执行单据。它们的流转关系用图表示是这样的：
flowchart LR
A[入库通知单/ASN] -->|多次收货| B[收货单]
B -->|可拆分| C[质检单]
C -->|良品| D1[良品上架单]
C -->|次品| D2[次品上架单]
下面我把每张单的关键字段列出来，方便你理解每张单都管了什么信息。
入库通知单（ASN）
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 表头 | 单据编号 | 系统自动生成 |
| 表头 | 供应商/货主 | 谁发的货 |
| 表头 | 仓库 | 送到哪个仓库 |
| 表头 | 预计到货日期 | 供应商预计送达时间 |
| 表头 | 单据状态 | 待收货/部分收货/已完成/已关闭 |
| 明细 | SKU编码 + SKU名称 | 来了哪些商品 |
| 明细 | 预计数量 + 单位 | 每种商品预计来多少 |
| 明细 | 已收数量 | 已经收了几个（多次收货时自动累加） |
关键逻辑：入库通知单可以多次收货，直到全部收完或手动关闭。
收货单
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 表头 | 单据编号 | 系统自动生成 |
| 表头 | 关联入库通知单 | 基于哪个ASN收的货 |
| 表头 | 供应商/货主 | 同上 |
| 表头 | 仓库 | 同上 |
| 表头 | 收货人 + 收货日期 | 谁收的、什么时候收的 |
| 表头 | 单据状态 | 已收货/质检中/已完成 |
| 明细 | SKU编码 + SKU名称 | 本次收了哪些商品 |
| 明细 | 实收数量 + 单位 | 实际到了多少 |
| 明细 | 批次号/生产日期 | 批次信息，用于追溯 |
| 明细 | 暂存库位 | 收货后暂存在哪个库位/待检区 |
| 明细 | 容器编号/类型 | 收货时使用的容器（托盘/周转箱编号） |
关键逻辑：一张入库通知单可以生成多张收货单（分多次收货）。收货单是结果单，记录已经发生的事实，可以回传上游做入库过账。
质检单
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 表头 | 单据编号 | 系统自动生成 |
| 表头 | 关联收货单 | 基于哪个收货单做的质检 |
| 表头 | 质检员 + 质检日期 | 谁检的、什么时候检的 |
| 表头 | 质检结果（总判） | 全部合格/部分不合格/全部不合格 |
| 表头 | 单据状态 | 待质检/质检中/已完成 |
| 明细 | SKU编码 + SKU名称 | 检了哪些商品 |
| 明细 | 批次号/生产日期 | 批次信息，用于追溯 |
| 明细 | 抽检数量 | 抽了多少个 |
| 明细 | 合格数量 + 不合格数量 | 合格和不合格各多少 |
| 明细 | 不合格原因 | 不良原因说明 |
关键逻辑：一张收货单可以拆分成多张质检单（分给不同质检员）。质检完成后，按良品和次品分别生成上架单。
上架单
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 表头 | 单据编号 | 系统自动生成 |
| 表头 | 关联质检单 | 基于哪个质检单上架 |
| 表头 | 上架类型 | 良品上架/次品上架 |
| 表头 | 上架员 + 上架日期 | 谁上的架、什么时候上的 |
| 表头 | 单据状态 | 待上架/上架中/已完成 |
| 明细 | SKU编码 + SKU名称 | 上了哪些商品 |
| 明细 | 批次号/生产日期 | 批次信息，用于追溯 |
| 明细 | 容器编号 | 上架时的来源容器（从哪个容器取出上架） |
| 明细 | 上架数量 + 单位 | 上了多少个 |
| 明细 | 推荐库位 | 系统建议放哪里 |
| 明细 | 实际上架库位 | 实际上放到了哪里 |
关键逻辑：一个质检单最多生成两张上架单——一张良品上架、一张次品上架。上架完成那一刻，库存才变成“可用库存”。
方案二：三单据模式（质检合并到收货单）
第二种方案跟第一种方案有点类似。我们可以对ASN进行收货，收完货之后，它还是一个结果单，会生成收货单。
区别在于：我们可以直接在收货单上面去做质检，去维护对应的质检内容，去关联一个质检明细表，然后把质检的结果放到里面。等质检完成之后，我们再生成对应的上架单，同样也可以根据质检的良品和不良品去生成两张上架单。
这个方案里面有一个限制：收货单得等到整张单全部质检完成才会生成上架单，所以一般来说，一个收货单就只会生成一个或者两个上架单——一个良品上架，一个次品上架。
flowchart LR
A[入库通知单/ASN] -->|多次收货| B[收货单
关联质检明细表]
B -->|全部质检完成| C1[良品上架单]
B -->|全部质检完成| C2[次品上架单]
这个方案下，收货单多了一个“待质检”的状态，而且需要关联一张质检明细表。下面列出它的关键字段（大部分与方案一收货单一致，统一列出方便对照）：
收货单（含质检）
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 表头 | 单据编号 | 系统自动生成 |
| 表头 | 关联入库通知单 | 基于哪个ASN收的货 |
| 表头 | 供应商/货主 | 同上 |
| 表头 | 仓库 | 同上 |
| 表头 | 收货人 + 收货日期 | 谁收的、什么时候收的 |
| 表头 | 单据状态 | 已收货/待质检/质检中/已完成 |
| 明细 | SKU编码 + SKU名称 | 本次收了哪些商品 |
| 明细 | 实收数量 + 单位 | 实际到了多少 |
| 明细 | 批次号/生产日期 | 批次信息 |
| 明细 | 暂存库位 | 收货后暂存在哪个库位/待检区 |
| 明细 | 容器编号/类型 | 收货时使用的容器（托盘/周转箱编号） |
| 质检子表 | 关联明细行 | 对应收货明细的哪一行 |
| 质检子表 | 批次号/生产日期 | 质检对象的批次信息 |
| 质检子表 | 抽检数量 | 抽了多少个 |
| 质检子表 | 合格数量 + 不合格数量 | 合格和不合格各多少 |
| 质检子表 | 质检结果 | 合格/不合格/降级 |
| 质检子表 | 不合格原因 | 不良原因说明 |
关键逻辑：收货单要等整单全部质检完成，才会生成上架单。所以一个收货单最多只生成两张上架单——良品和次品各一张。不会出现收货单质检了一半就生成上架单的情况。
方案三：一单到底模式
还有第三种方案，就是一单到底的方案。
上游推过来的这张单，统一把它定义为叫做入库单。收货的时候，基于入库单去收货。入库单会有收货状态和上架状态两个状态。收货的时候，可以基于入库单多次收货，每次收货会在入库单里面生成收货记录。
有了收货记录之后，可以基于这个收货记录去生成质检记录，也就是独立的质检明细。质检完成之后，又可以根据这个入库单去做上架。上架完成之后，也会生成对应的上架记录，也是关联在这个入库单里面。
它就是一种一单到底的设计——所有的操作都是基于这一张主单去发起，然后结果沉淀在这张主单的明细里面。这些明细就叫做操作明细，例如收货明细、质检明细、上架明细，主要就是这三种作业方式的操作记录。
flowchart TB
A[入库单
主单] --> B[收货明细]
B --> C[质检明细]
C --> D[上架明细]
这个方案的表结构很清晰——一张主单，三张子表：
入库单（主单）
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 主单 | 单据编号 | 系统自动生成 |
| 主单 | 供应商/货主 | 谁发的货 |
| 主单 | 仓库 | 送到哪个仓库 |
| 主单 | 收货状态 | 待收货/收货中/已收货 |
| 主单 | 上架状态 | 待上架/上架中/已完成 |
| 主单 | 备注 | 额外的说明信息 |
收货明细（子表A）
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 子表 | 关联主单 | 属于哪个入库单 |
| 子表 | SKU编码 + SKU名称 | 本次收了哪些商品 |
| 子表 | 实收数量 + 单位 | 实际到了多少 |
| 子表 | 批次号/生产日期 | 批次信息 |
| 子表 | 暂存库位 | 收货后暂存在哪个库位/待检区 |
| 子表 | 容器编号/类型 | 收货时使用的容器（托盘/周转箱编号） |
质检明细（子表B）
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 子表 | 关联主单 | 属于哪个入库单 |
| 子表 | 关联收货明细行 | 基于哪次收货记录做的质检 |
| 子表 | SKU编码 + SKU名称 | 检了哪些商品 |
| 子表 | 批次号/生产日期 | 批次信息，用于追溯 |
| 子表 | 抽检数量 | 抽了多少个 |
| 子表 | 合格数量 + 不合格数量 | 合格和不合格各多少 |
| 子表 | 质检结果 | 合格/不合格/降级 |
| 子表 | 不合格原因 | 不良原因说明 |
上架明细（子表C）
| 位置 | 关键字段 | 说明 |
|---|---|---|
| 子表 | 关联主单 | 属于哪个入库单 |
| 子表 | 关联收货明细行 | 是基于哪次收货记录上架的 |
| 子表 | SKU编码 + SKU名称 | 上了哪些商品 |
| 子表 | 批次号/生产日期 | 批次信息，用于追溯 |
| 子表 | 容器编号 | 上架时的来源容器（从哪个容器取出上架） |
| 子表 | 上架数量 + 单位 | 上了多少个 |
| 子表 | 推荐库位 | 系统建议放哪里 |
| 子表 | 实际上架库位 | 实际上放到了哪里 |
关键逻辑：主单有收货状态和上架状态两个独立维度，互不影响。收货可以多次操作，每次追加一行收货明细。质检基于收货明细生成独立的质检子表（子表B），验收通过后再生成上架明细（子表C）。这个方案的开发成本最低，但并行操作能力也最弱——所有操作都基于同一张主单，串行排队。
三种方案的差异对比
三种方案各有优劣势，我从几个维度拉了一张对比表，看起来更直观：
| 对比维度 | 方案一（四单据） | 方案二（三单据） | 方案三（一单到底） |
|---|---|---|---|
| 有几张单据 | 4张：通知单→收货单→质检单→上架单 | 3张：通知单→收货单（含质检）→上架单 | 1张主单 + 收货/质检/上架三个子表 |
| 每张单管什么 | 各管各的，职责很清楚 | 质检和收货合一张，少一道手 | 全压在一张单上，边界模糊 |
| 能不能并行干活 | 最强——收货和质检可以同时干 | 中等——质检得等收货完才能开始 | 弱——所有操作串行排队 |
| 查账好不好查 | 最好查——每步都有独立单据 | 中等——质检信息嵌在收货单里 | 最弱——得翻子表，比较费劲 |
| 开发成本 | 最高——4张单各自的状态机、权限都要设计 | 中等 | 最低——一张主单加几张子表就能跑 |
| 谁适合用 | 大中型专业仓库，医药/食品/跨境等合规要求高的 | 中小型仓库，质检简单的 | 小仓库、门店仓、调拨入库，追求快速上线 |
简单总结：
方案一拆得最开，每步都独立。好处是职责清楚、好追溯、能并行；代价是系统做得重、开发成本高。
方案二把质检合并到收货里面，少一张单。大部分中小仓库够用了，除非质检规则特别复杂。
方案三最省事，一张单走到底。开发快、操作简单，但并行和追溯能力最差，适合业务简单的场景。
这三套方案没有谁比谁高明，选哪个看你的业务场景。方案也不是一次定死的——业务量上来了，可以从方案三演进到方案二，再到方案一。
怎么选
说实话，没有哪一套方案是绝对好的。你选方案一不一定就比选方案三高明，关键看你的业务场景。
我这里给几个判断的维度供你参考：
第一看角色分工。 收货和质检是不是同一个人？如果是，方案二就够了，不需要为了“规范”强行拆成两张单。如果不是，方案一可能更合适。
第二看质检的复杂度。 如果质检就是简单的全检或者免检，不需要复杂的抽样规则，方案二足够了。如果有第三方送检、多级抽样这些复杂规则，方案一更合适。
第三看审计要求。 如果行业有合规要求，需要完整的质检追溯链，那就老老实实走方案一。如果是内部管理为主，方案二或三都能接受。
第四看团队和系统的定位。 有专职的WMS开发团队，可以做方案一。如果是小团队或者用外包，方案三先跑起来，后面业务量上来了再演进。
很多系统一开始用方案三跑，跑了一年业务量翻了几倍然后拆成方案二，又过了一年走向方案一，这种情况我也见过不少。设计是跟着业务走的，不是一次性选定的。
写在最后
我觉得对于刚开始接触WMS的朋友来说，与其死记硬背“ASN是入库通知单、收货单是结果单”这些定义，不如先理解清楚入库本质上就三件事——收货、质检、上架。然后套用上面三种方案去看你的系统，你大概就能判断出来：它用的是哪种方案？每个环节的职责是怎么划分的？
如果你看完发现自己用的系统好像是方案一但又带一点方案二的特征，那也很正常——很多系统是混合的，哪个环节需要独立就独立，不需要就合并。
你接触过的WMS用的是哪种方案？有没有踩过什么坑？欢迎在评论区交流。