Creeks 订单履行业务全景（业务视角）
各平台的订单通过定时任务自动拉到系统里，先进「**订单池**」。订单池是所有平台订单的汇总地，方便店管人员统一查看和核算。 系统会做筛选，只有需要我们发货的订单才会进入履行流程： 订单进来后状态是「**待审核**」。系统会自动做一系列检查：
本文档从业务人员的角度，用通俗语言描述 Creeks 系统中订单履行的完整业务流程。
一、一句话概括
买家在平台下了单 → 我们把订单拉进系统 → 找到对应货物 → 决定从哪个仓库发、走什么物流 → 让仓库打包贴单发货 → 把跟踪号告诉平台和买家 → 完事。
二、业务全景总览
flowchart LR
subgraph S1["第一步：接单"]
A1["各平台订单自动拉取"] --> A2["进入订单池"]
end
subgraph S2["第二步：审核"]
B1["自动审核为主"] --> B2["生成包裹"]
B3["异常订单人工处理"]
end
subgraph S3["第三步：配货"]
C1["确定发货仓库"] --> C2["确定物流渠道"] --> C3["占用库存"]
end
subgraph S4["第四步：发货"]
D1["创建出库单和运单"]
D2["获取跟踪号和面单"]
D3["仓库拣货打包贴单"]
end
subgraph S5["第五步：完结"]
E1["跟踪号回传平台"]
E2["物流运输妥投"]
E3["订单完成"]
end
S1 --> S2 --> S3 --> S4 --> S5
三、详细业务流程
第一步：平台订单进来
各平台的订单通过定时任务自动拉到系统里，先进「订单池」。订单池是所有平台订单的汇总地，方便店管人员统一查看和核算。
拉单方式
| 方式 | 适用场景 | 频率 |
|---|---|---|
| API 自动拉取 | 已对接 API 的平台（Amazon、速卖通、eBay、Wish、TEMU、TiktokShop、Shopify、Walmart、Shein） | 每 5~7 分钟一次 |
| 手动导入 Excel | 未对接 API 的平台或特殊站点（如 Tiktok 巴西站、日本站） | 按需 |
各平台订单量级
| 平台 | 月订单量 | 店铺数量 |
|---|---|---|
| Amazon | 3万~11万单 | 多个 |
| AliExpress（速卖通） | ~5万单 | 28个 |
| TEMU | 增长中 | 多个 |
| TiktokShop | 增长中 | 多个 |
| eBay | 中等 | 多个 |
| Wish | 中等 | 多个 |
不是所有订单都进来
系统会做筛选，只有需要我们发货的订单才会进入履行流程：
| 订单类型 | 是否进入履行 | 说明 |
|---|---|---|
| Amazon 自配送订单 | 是 | 需要我们自己找仓库发货 |
| Amazon FBA 订单 | 否 | 亚马逊仓库自己发货 |
| TEMU 全托管订单 | 否 | TEMU 平台自己发货 |
| TEMU 半托管-合作仓订单 | 否 | TEMU 推单给合作仓发货 |
| TEMU 半托管-卖家履约订单 | 是 | 需要我们自己发货 |
| TiktokShop 卖家自发货订单 | 是 | 需要我们自己发货 |
| TiktokShop FBT 订单 | 否 | Tiktok 官方仓发货 |
第二步：订单审核
订单进来后状态是「待审核」。系统会自动做一系列检查：
自动审核（绝大多数）
- 商品配对：订单里的商品（平台 SKU）是否已经在系统里配对上了我们的产品？如果配对成功，系统就知道这个订单卖的是什么货。
- 信息完整性：收货地址、商品信息是否齐全。
- 货主识别：能不能确定这个订单属于哪个业务线/团队。
全部通过 → 自动审核成功 → 立即生成包裹（履约单）
需要人工处理的情况
| 异常状态 | 原因 | 处理方式 |
|---|---|---|
| 未知货主 | 订单的商品没有匹配到任何产品 | 订单处理员先去商品管理里配对好，再重新审核 |
| 不需要处理 | 判定为不需要发货的订单 | 人工确认后跳过 |
| 发货异常 | 各种原因导致无法正常流转 | 订单处理员排查后处理 |
第三步：生成包裹（履约单）
审核通过后，系统为订单生成「包裹」（业务上叫「履约单」）。
- 一个订单默认生成一个包裹
- 订单处理员可以手动合并多个订单为一个包裹（省运费）
- 也可以手动拆分一个订单为多个包裹（比如商品在不同仓库）
- 生成的包裹状态为「待配货」
第四步：配货（分仓分物流）—— 核心环节
这是整个流程最关键的步骤，需要回答两个问题：
- 从哪个仓库发货？（分仓）
- 走哪个物流渠道？（分物流）
4.1 分仓—— 决定从哪发货
我们目前有四类仓库：
| 仓库 | 说明 | 配货后动作 |
|---|---|---|
| 自营仓（codo） | 公司自己的仓库，在东莞 | 系统创建出库单，仓库人员看到后拣货打包 |
| 万邑通仓（Winit） | 第三方海外仓，在美国、英国等地 | 调万邑通 API 创建出库单，万邑通仓库操作 |
| FBA 仓 | Amazon 的仓库 | 调 Amazon 多渠道配送 API，FBA 代为发货 |
| 百世云仓 | 百世的仓库 | 同自营仓类似流程 |
4.2 分物流—— 决定怎么送
物流渠道的选择取决于三个因素：包裹寄到哪里、时效要求是什么、仓库支持哪些渠道。
目前对接的物流服务商有 18+ 家，按使用场景分三类：
| 类型 | 物流商 | 什么时候用 |
|---|---|---|
| 海外仓储+尾程派送 | 万邑通 | 从万邑通海外仓发货，尾程交给 USPS/UPS/FedEx 等 |
| 跨境直邮 | 递四方、燕文、云途、飞特等 | 从国内仓直发海外 |
| 平台指定物流 | TEMU 物流、TiktokShipping、Wish Post | 平台要求必须用他们指定的物流 |
4.3 配货的三种方式
flowchart TD
A["订单处理员点击配货"] --> B{"选择配货方式"}
B -->|"自动配货"| C["系统按规则自动匹配仓库和物流"]
B -->|"手动指定"| D["订单处理员自己选仓库和物流"]
B -->|"平台物流订单"| E["系统从平台获取仓库和物流并自动映射"]
C --> C1{"匹配成功且库存够"}
C1 -->|"是"| F["配货成功，库存已占用"]
C1 -->|"否-规则没配上"| G["提示配货失败，需人工处理"]
C1 -->|"否-库存不够"| H["提示缺货"]
D --> F
E --> E1{"映射关系配置好了"}
E1 -->|"是"| F
E1 -->|"否"| I["提示没有匹配的发货仓或物流渠道"]
4.4 自动配货的规则是怎么配的
订单处理员可以预先配置规则，系统在配货时按优先级逐条匹配。规则由条件和结果组成：
举例——一个典型的分仓规则：
当 平台 = eBay 且 目的国家 = 美国 且 邮编以 9 开头 → 分到万邑通美国西仓
再举例——一个典型的分物流规则：
当 仓库 = 万邑通美国西仓 且 订单总价 < 50美元 → 走 USPS First Class（最便宜的渠道）
系统支持按 39 种条件组合配置规则，常用的包括：
- 基础条件：平台、目的国家、州/省、邮编
- 商品条件：商品 SKU、产品类型
- 金额/重量条件：订单总价、单价、总重量
- 特殊条件：Wish 平台的各种物流等级
4.5 平台物流订单的特殊处理
有些平台（TEMU、TiktokShipping）会直接指定用哪个仓库和物流，不允许卖家自己选。这时候系统的工作不是匹配规则，而是做「翻译」：
| 平台指定的 | 需要翻译成 | 怎么翻译 |
|---|---|---|
| 平台的仓库 ID | Creeks 的实际仓库 | 预先配置好映射关系 |
| 平台的物流渠道 ID | Creeks 的物流渠道 | 预先配置好映射关系 |
这部分映射关系由店管人员在后台配置，需要保证平台仓和 Creeks 仓的地址一致。
第五步：创建出库单和运单
配货成功后，系统根据仓库类型做不同的事情：
5.1 自营仓（codo）路线
flowchart LR
A["配货成功"] --> B["系统创建出库单"]
B --> C["仓库人员看到出库单"]
C --> D["仓库拣货打包"]
D --> E["快递公司揽收"]
E --> F["系统获取跟踪号"]
5.2 万邑通仓 + 普通渠道路线
flowchart LR
A["配货成功"] --> B["调万邑通API创建出库单"]
B --> C["万邑通仓库操作"]
C --> D["万邑通回传跟踪号"]
D --> E["系统把跟踪号关联到包裹"]
5.3 万邑通仓 + 平台物流路线（TEMU/TiktokShipping）
这条线路最复杂，因为要同时跟万邑通和平台两边交互：
flowchart LR
A["配货成功"] --> B["调万邑通API创建自提出库单"]
B --> C["调平台API创建运单获取运单号"]
C --> D["调平台API获取跟踪号"]
D --> E["调平台API获取面单PDF"]
E --> F["把面单和跟踪号上传给万邑通"]
F --> G["万邑通仓库打印面单贴单"]
G --> H["平台指定的物流商上门自提"]
为什么要上传面单给万邑通？因为包裹在万邑通仓库里，他们需要按面单上的信息来打包贴单。但运单是平台出的（因为用的是平台物流），所以需要从平台拿到面单再给到万邑通。
5.4 FBA 仓路线
flowchart LR
A["配货成功"] --> B["调Amazon多渠道配送API"]
B --> C["FBA仓库发货"]
C --> D["获取跟踪号"]
D --> E["定时查询发货状态"]
这条线路主要用于：自营仓缺货时，临时把订单转给 FBA 仓发货。月均约 1600 单。
第六步：获取跟踪号和面单
跟踪号是包裹在物流系统中的唯一标识，面单是贴在包裹上的快递单。
| 物流渠道 | 跟踪号来源 | 面单来源 |
|---|---|---|
| 万邑通渠道 | 万邑通出库后自动回传 | 万邑通提供 |
| TEMU 平台物流 | 调 TEMU API 获取 | 调 TEMU API 获取，2页PDF需裁剪成1页 |
| TiktokShipping | 调 Tiktok API 获取 | 调 Tiktok API 获取，上传到七牛云 |
| 第三方物流（递四方、燕文等） | 在运单管理里向物流商申请 | 物流商提供 |
订单处理员在「运单管理」页面操作：选运单 → 点「一键下单」→ 点「获取跟踪号」→ 点「获取面单」。也可以批量操作。
如果创建运单失败，失败原因会显示在页面上，订单处理员修正后手动重试。
第七步：标记发货（回传平台）
包裹发出后，需要告诉销售平台「这个订单已经发了，跟踪号是这个」。系统自动完成这个动作。
| 平台 | 回传内容 | 方式 |
|---|---|---|
| Amazon | 跟踪号、承运商 | API 自动回传 |
| 速卖通 | 跟踪号、物流方式 | API 自动回传 |
| eBay | 跟踪号、承运商 | API 自动回传 |
| Wish | 跟踪号 | API 自动回传 |
| TEMU | 标记子订单已发货（含发货类型：单发/拆分/合并） | API 自动回传 |
| TiktokShipping | 平台面单的订单，平台自动知道 | 不需要额外回传 |
| Shopify | 跟踪号、物流方式 | API 自动回传 |
TEMU 标记发货的特殊逻辑
TEMU 的标记发货需要告诉平台是哪种发货类型：
| 发货类型 | 含义 | 什么时候用 |
|---|---|---|
| 单个运单发货（sendType=0） | 一个子订单对应一个运单 | 最常见的情况 |
| 拆分运单发货（sendType=1） | 一个子订单拆成多个运单 | 货物太大需要分多个包裹 |
| 合并发货（sendType=2） | 多个子订单合成一个运单 | 同一个买家的多个订单合并发货 |
第八步：物流运输与妥投
包裹交给物流商后：
- 系统定期同步物流状态
- 包裹妥投后订单完结
- 如果物流异常（延误、退回），系统会标记异常让订单处理员处理
四、中间可能遇到的问题
4.1 买家取消订单
flowchart TD
A["买家在平台取消或退款"] --> B["系统每30分钟同步平台状态"]
B --> C{"Creeks订单当前状态"}
C -->|"待审核/未知货主/不需要处理"| D["直接取消Creeks订单"]
C -->|"待发货"| E["取消Creeks订单和包裹"]
C -->|"已发货"| F["无法取消，需联系买家拒收或等退回"]
4.2 缺货
| 仓库类型 | 缺货处理 |
|---|---|
| 万邑通仓 | 如果长期缺货，店管取消 Creeks 包裹；但 TEMU 订单平台不允许卖家取消，只能联系买家取消，买家不取消就逾期罚款 |
| 自营仓 | 订单处理员可以转从其他仓库发货，或者等补货 |
| FBA 仓 | 不存在缺货问题，FBA 自己管库存 |
4.3 重新履行（Wish 特有）
Wish Post 发货的包裹可能因为以下原因被物流商退回：
- 买家收件地址变更
- 偏远地区，物流商送不到
- 包裹超重或超体积
退回后的处理：
| 时间条件 | 平台处理 | 我们的处理 |
|---|---|---|
| 25天内 | 订单状态从「已发货」变回「待发货」，更新剩余发货天数 | 系统识别后通知订单处理员，重新配货发货 |
| 25天后 | 平台自动退款给买家 | 订单关闭 |
4.4 组合品配货
有些商品是组合品（比如一套衣服 = 上衣 + 裤子），配货时需要拆解成子件分别匹配仓库里的货物。
4.5 eBay 认证仓
eBay 对从认证仓（万邑通是认证仓）发货的订单免除发货时效考核。为了享受这个待遇，派单给万邑通时需要带上 eBay 特有的字段：seller id、平台订单号、transaction id、item id。这样万邑通才能向 eBay 证明这些订单是从认证仓发出的。
五、基础数据配置（店管人员的日常工作）
在订单履行流程跑起来之前，店管人员需要先做好以下配置：
5.1 店铺授权
| 配置项 | 说明 |
|---|---|
| API 授权 | 各平台店铺的 API Token 授权，授权后系统才能自动拉单和回传跟踪号 |
| 授权方式 | 比如TEMU有 ECPP 和 Creeks 两种授权方式，选 Creeks 表示由 Creeks 直接对接 |
5.2 仓库配置
| 配置项 | 说明 |
|---|---|
| 店铺发货仓映射 | 把平台后台的仓库（如 Tiktok 的某个发货仓）映射到 Creeks 的实际仓库 |
| 仓库启用 | 启用哪些仓库用于发货 |
5.3 物流渠道配置
| 配置项 | 说明 |
|---|---|
| 物流商管理 | 在系统里建好物流商（万邑通、递四方等） |
| 物流渠道启用 | 为每个物流商启用可用的渠道 |
| 报价维护 | 各渠道的价格、时效、目的国 |
| 平台物流渠道映射 | 把平台的物流渠道（如 TEMU 的 USPS）映射到 Creeks 的渠道和万邑通的自提渠道 |
| 渠道时效关系 | 维护物流渠道与平台物流服务等级的对应关系 |
5.4 配货规则配置
| 配置项 | 说明 |
|---|---|
| 分仓规则 | 配置「什么条件的订单从哪个仓发货」的规则，按优先级排列 |
| 分物流规则 | 配置「什么条件的包裹走哪个物流渠道」的规则，按优先级排列 |
六、涉及的人员角色
flowchart TD
subgraph 店管人员
SA["管理店铺授权"]
SB["配置仓库和物流渠道"]
SC["配置配货规则"]
SD["月底平台核算"]
end
subgraph 订单处理员
OA["审核异常订单"]
OB["配货-分仓分物流"]
OC["管理运单-下单/获取跟踪号/面单"]
OD["处理缺货和取消"]
OE["处理发货异常"]
end
subgraph 仓库人员
WA["拣货"]
WB["打包"]
WC["贴面单"]
WD["交接物流商"]
end
各角色在流程中的参与
| 流程环节 | 店管人员 | 订单处理员 | 仓库人员 |
|---|---|---|---|
| 平台订单拉取 | 配置授权（一次性） | - | - |
| 订单审核 | - | 处理异常订单 | - |
| 配货（分仓分物流） | 配置规则（一次性） | 执行配货或处理配货失败 | - |
| 创建出库单 | - | 派单 | 接收出库单 |
| 获取跟踪号面单 | 配置物流渠道（一次性） | 操作运单管理 | - |
| 仓库发货 | - | - | 拣货打包贴单交接 |
| 标记发货 | - | 确认（大部分自动） | - |
| 异常处理 | 联系平台/买家 | 取消/重发/补发 | 退回件处理 |
七、各平台履行的差异要点
| 维度 | Amazon | 速卖通 | eBay | Wish | TEMU | TiktokShop |
|---|---|---|---|---|---|---|
| 物流选择 | 自由选择 | 自由选择，菜鸟物流需要传 ProductId | 自由选择，建议走认证仓 | 自由选择或 Wish Post | 必须用 TEMU 物流 | TiktokShipping（平台指定）或 SellerShipping（自选） |
| 平台仓 | 支持 FBA 多渠道配送 | 无 | 无 | 无 | 半托管有合作仓 | FBT 官方仓 |
| 跟踪号回传 | API 自动 | API 自动 | API 自动 | API 自动 | 标记发货 API | TiktokShipping 自动，其他 API 回传 |
| 特殊要求 | FBA 缺货可转 FBA 发货 | 菜鸟物流需传 ProductId | 认证仓需传 transaction id / item id | 重新释放订单需重新履行 | 不允许卖家取消订单 | US 站点需调 API 获取物流渠道 |
八、系统页面一览
订单处理员日常使用的系统页面：
| 页面 | 用途 |
|---|---|
| 订单池 | 查看所有平台的订单汇总 |
| 订单履行（新版） | 查看/搜索/导出需要履行的订单，查看订单详情 |
| 订单规则 | 配置分仓分物流的自动规则 |
| 履约单管理 | 查看包裹/履约单列表，执行配货操作 |
| 运单管理 | 一键下单、获取跟踪号、获取面单、取消运单 |
| 出库单管理（库存模块） | 查看出库单状态、跟踪号 |
| 商品管理 | 管理平台商品与系统产品的配对关系 |
| 仓库管理（库存模块） | 管理仓库、配置店铺发货仓映射 |
| 物流商管理（物流模块） | 管理物流商、物流渠道、报价 |