WooliiPorter来货到中国仓才发现问题?供应商包裹入库质检(Inbound QC)规格书:抽样口径、缺陷分级与「放行/停发/返工/退回」处置决策(2026 商户版)
履约运营
返回资讯列表
履约模式
供应商发的是包裹，不是托盘：多供应商从中国发货的「供应商包裹接收」模式——什么时候走供应商分散寄仓，什么时候该升级 LCL/FCL 整箱（2026 商户版）
WooliiPorter供应商发的是包裹，不是托盘：多供应商从中国发货的「供应商包裹接收」模式——什么时候走供应商分散寄仓，什么时候该升级 LCL/FCL 整箱（2026 商户版）
如果你从多家中国供应商采购，每家单批货量都不大，订单是滚动下的，那么你面对的物流现实是：你的供应商发出来的是包裹，不是托盘。在这种情况下，「按供应商包裹接收」——供应商各自把小批货寄到我方中国仓，我们在入仓环节做代收留证、称重、点数，再按你的计划合箱、重打包或按 SKU 备货——对多家低 MOQ、滚动下单的商户通常是可考虑的默认入仓方式之一。LCL/FCL 整箱是另一个模式，它在某一批货已经真凑到托盘或集装箱量级时才有意义。
本文把三种容易被混在一起谈的模式拆开，给出一张只含判断因子的决策表，并说明收件侧需要配置什么，才能让碎片化到货在三个月后不变成一笔对不清楚的账。需要先说明的边界：商户自己向自己的供应商采购、自己付款；我们只做履约，从不经手货款，不是采购代发或代购，货权始终归商户。
三种模式的边界：整箱货代、供应商包裹接收、个人集运
这三类服务经常被放在同一句话里比较，但它们对「谁做什么」的回答完全不同。差别最大的地方在收件侧：整箱模式下的入仓动作发生在「一批货已经成型」之后，而供应商包裹接收模式下的入仓动作发生在货还没成型的时候。
| 维度 | 传统货代（LCL/FCL） | 面向商户的供应商包裹接收 | 个人集运 |
|---|---|---|---|
| 典型货量 | 单批接近整托或整柜 | 单批从几箱到若干托盘，可滚动到货 | 个人自用零散小包 |
| 谁把货发到仓 | 通常由一家工厂或供应商集中出运 | 各供应商分别把小批货寄到我方中国仓 | 个人买家在各平台下单 |
| 收件颗粒度 | 按提单或柜号 | 按每票包裹，按 PO/ASN 与 SKU 标注收件 | 按个人包裹 |
| 入仓证据 | 以出运文件为主 | 入仓拍照、称重、点数，形成可回溯记录 | 基础收件记录 |
| 入仓后的处理 | 整批清关后入仓或直送 | 质检、合箱、重打包、按 SKU 备货、头程与国际转运 | 合箱后发出 |
| 货权与货款 | 货权归商户 | 货权始终归商户；我们不代付货款、不代采购 | 货权归个人 |
换句话说，供应商包裹接收的核心不是「运输方式」，而是每一票包裹都能对上你的采购单。这正是整套流程的设计前提：包裹在入仓时就被赋予 PO/ASN 与 SKU 的身份，而不是等到发货前才回头猜。
决策因子：什么时候分散寄仓，什么时候考虑整箱
下面这张表只给判断因子，不含任何省钱幅度或体积重结论。体积重是否受影响，取决于你的包装方式、SKU 结构和所选线路，需要按实际货件测算；运输时效取决于线路与承运商，我们不做固定天数承诺。
| 判断因子 | 倾向供应商包裹接收 | 倾向 LCL/FCL 整箱 | 为什么 |
|---|---|---|---|
| 供应商数量 | 3 家以上、低 MOQ、分散在不同产地 | 单一工厂能一次出完整批 | 供应商多，货自然碎片化，整箱难以拼齐 |
| 单批发货体积/重量 | 每票远低于一个托盘 | 单批已接近整托或整柜 | 整箱要有体量才成立 |
| 下单节奏 | 滚动补货，每周或每两周到货 | 一次性集中大批采购 | 滚动到货本身就是接收模式的场景 |
| SKU 混装度 | 多 SKU、小批量混装 | 单 SKU、高单量 | 混装货更需要按 SKU 收件与后续分拣 |
| 是否需要入仓二次处理 | 需要质检、贴标、重打包、按 SKU 备货 | 到仓即整批出货，无需处理 | 处理动作必须在货权方与收货方之间完成 |
| 时效窗口 | 到货时间比较分散、可分批安排 | 整批同步到达更符合你的上架计划 | 取决于线路与承运商，按实际货件评估 |
这六个因子不用全部命中同一个方向。实践中更常见的情况是：平时走供应商分散寄仓，某个供应商攒到一批大货时单独安排整箱，两条线并存。
收件运营配置：地址、ASN 与证据链
多供应商模式下，收件侧要配的其实只有四件事，但每一件都会在对账时被追问。
- 地址下发要统一。把中国仓收件地址按规范格式一次性发给所有供应商，避免同一个仓出现三种写法。可直接参考 中国仓地址模板。如果个别供应商无法自行发出包裹、需要国内段安排，请先与团队确认可行性与线路，不要默认成立。
- 每票包裹要有身份。箱外标注供应商代码加 PO 号/ASN，箱内放装箱单。没有标识的包裹，是最容易在几周后变成对账争议的那一类。
- 入仓必须留证。入仓拍照、称重、点数，形成与每一票包裹一一对应的记录。当供应商说「我发了 20 件」而实收 18 件时，是这份记录决定缺口从哪里找起，而不是靠回忆。
- 异常要有固定路径。短装、错发、串货在入仓环节先留证、再走对账，最后才是与供应商沟通或索赔。我们是记录与履约方，不是货款方——采购付款与向供应商索赔始终由商户自己完成。
接收之后：滚动台账与三条路由
入仓只是起点。多供应商、滚动到货的场景下，真正决定运营效率的是滚动台账：每个 PO、每票包裹、实收数量与差异随时能和采购单对上，而不是等到发货前才发现缺口。这份台账通常会直接回流到你的采购节奏里——哪个供应商常延迟、哪个 SKU 常短装，会很快显现出来。
收件完成后，货可以走三条不同的路，而且同一批到货可以同时走其中两条：
- 按 SKU 备货。到货先进仓，等订单来了再按 SKU 拣配、合箱发出，适合 SKU 稳定、销量可预期的商户。参见 中国备货与国际履约。
- 合箱后发 FBA。把多个供应商的包裹合并成一票，重打包后发往 FBA 仓，详见 合箱与重打包。
- 按订单行路由给 DTC 客户。当一张混合订单里既有仓内库存能覆盖的行，也有需要供应商直发的行，就按订单行拆分履约。
哪条路更合适，取决于你的 SKU 稳定性、订单结构和销售渠道，而不是某一种模式的「先进程度」。
渠道接入：只陈述当前已验证的事实
- WooCommerce。我们的插件目前以 WordPress.org 插件目录的 listing 为准，这不等同于 WooCommerce Marketplace 上的上架。详情见 WooCommerce 集成。
- Shopify 与 Amazon。相关 listing 已获批准。在该渠道真实首单妥投完成之前，我们不会把状态写成「已全面可用」。
- Merchant API 与 MCP。如果你在做 OMS/ERP 对接或 Agent 侧自动化，可以按设计伙伴或私有试点的口径沟通，我们不对外描述公开 API key 或生产 webhook。
我们由美国实体 WOOLII, LLC 运营，一个接入点连接多渠道，收件、留证、合箱与头程在同一个流程里完成，不涉及商品销售，也不涉及代付供应商货款。
从哪里开始
供应商包裹接收不是「更高级」的模式，它只是在低 MOQ、滚动下单、碎片化到货的现实下更贴近你实际的收货形态；当某一批货确实达到托盘或整柜量级，LCL/FCL 才值得摆上桌面。
想把流程对齐到你自己的供应商结构上：可以 注册商户账户（注册时选择 Merchant），先看 供应商包裹接收 与 商户方案总览，再回到 运作方式 了解完整链路；如果希望我们按你当前的供应商数量与下单节奏给一次结构性反馈，可以提交 流程评估。做系统集成或 Agent 自动化的一方，可另从 开发者 与 集成 页面按试点口径联系。