/17 分钟/6 阅读/0 评论
跨境电商 ERP 全链路业务全景
Creeks ERP 是集团内部使用的**全链路跨境电商管理系统**，覆盖**商品主数据 → 订单拉取 → 订单履约 → 仓储物流 → 财务核算 → 数据分析**全业务流程，为以下部门提供服务： 所有平台遵循统一范式： 两种授权路径： 一个
本文档从业务视角梳理 Creeks 跨境电商 ERP 系统的全链路业务体系，用于面试时的项目概述、公司背景介绍，以及简历中的业务经历提炼。
一、ERP 系统定位
1.1 公司背景
小蝌蚪众创电商科技（广州）有限公司，2021.08 至今，跨境电商企业，面向北美/欧洲/东南亚/拉美等多国市场，在 Amazon/eBay/TikTok Shop/Shopee/Shopify/Temu/Walmart/AliExpress 等 12+ 平台 上运营多个店铺。
1.2 系统定位
Creeks ERP 是集团内部使用的全链路跨境电商管理系统，覆盖商品主数据 → 订单拉取 → 订单履约 → 仓储物流 → 财务核算 → 数据分析全业务流程，为以下部门提供服务：
| 部门 | 核心诉求 | ERP 提供的能力 |
|---|---|---|
| 数据维护 | 产品信息管理 | SPU/SKU 管理，作为 ERP 产品主数据基础 |
| 销售/运营 | 开店、拉取订单、商品上架 | 店铺授权、平台数据拉取（订单/商品/库存/库龄）、商品认领 |
| 店管 | 订单履约全链路 | 订单拉取 → 履约单 → 分仓分物流 → 派单 → 标记发货 → 回传平台 |
| 物流/仓储 | 仓库管理、调拨、物流对接 | 仓库调拨、自营 WMS + 第三方 WMS 对接、平台仓业务 |
⚠️ ERP 不做刊登功能（刊登在第三方 ERP 或平台后台完成），刊登后回到 ERP 进行商品认领。
1.3 核心业务流
商品主数据
│
▼
平台开店 → 店铺授权 → 平台数据拉取（订单/商品/库存/库龄）
│
▼
订单履约 ←── SKU 匹配 ←── 订单进入 ERP
│
├── 审核（自动/人工）
├── 分仓分物流（39 种规则引擎）
├── 包裹创建 → 派单 → 仓库出库
└── 标记发货 → 回传平台（完成"标记发货"）
│
▼
仓储物流 ←── 仓间调拨 ←── 库存管理
│
├── FBA/FBT/万邑通/YT自营仓
├── 验货/装箱/打标/贴唛
└── 在途跟踪/收货入库
│
▼
财务核算 ←── Amazon Finance API 对账 ←── BI 报表
│
├── 13 种财务事件类型
├── 订单数据对账
└── 多维度销量统计/毛利计算
二、业务全景图
┌─────────────────────────────────────────────────────────────────────────────┐
│ 平台域（esync） │
│ 12+ 平台对接: Amazon/eBay/TikTok/Shopee/Shopify/Temu/Walmart/... │
│ 数据拉取: 订单/商品/库存/库龄/财务/广告 │
│ 授权模式: OAuth / SP-API / MWS / App Key │
└──────────────────────────┬──────────────────────────────────────────────────┘
│ Kafka 消息
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 订单域（fulfillment） │
│ 订单拉取 → SKU匹配 → 审核 → 分仓分物流 → 包裹创建 → 派单 → 标记发货 │
│ 15 步状态机，支持拆单/合单/取消/拦截 │
└──────────────────────────┬──────────────────────────────────────────────────┘
│ Feign / Kafka
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 库存域（inventory） │
│ 10+ 仓库类型: FBA/FBT/万邑通/YT自营仓/WFS/FBC/... │
│ 库存体系: 逻辑库存 / 物理库存 / 在途库存 / 可用库存 │
│ 库存台账: 定时拉取 + 填充，FBA/万邑通/YT 三方对接 │
│ 库龄管理 / 验货流程 / 标签获取 / 仓库打标 │
└──────────────────────────┬──────────────────────────────────────────────────┘
│ Feign / Kafka
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 调拨域（allocation） │
│ 创建调拨单 → 提交 → 配货 → 装箱 → 提交仓库 → 验货 → 交运 → 入库 │
│ 5 个状态机，支持拼单/合箱/预约 Booking │
└──────────────────────────┬──────────────────────────────────────────────────┘
│ Feign / Kafka
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 财务域（finance/statistics） │
│ Amazon Finance: 13 种事件类型（销售/退款/调整/广告/优惠券...） │
│ 对账: Amazon 财务数据 vs 订单数据 → ClickHouse 结算宽表 │
│ BI 报表: 15+ 报表维度（每日业绩/毛利/退货率/库存周转/广告...） │
└─────────────────────────────────────────────────────────────────────────────┘
三、平台对接域（esync 服务）
3.1 对接平台清单
| 平台 | 对接模块 | 数据能力 | 授权模式 |
|---|---|---|---|
| Amazon | esync-amazon | 订单(MFN/FBA)、FBA库存、库龄、财务、广告、结算报告 | SP-API (OAuth) |
| eBay | esync-ebay | 订单、GSP国际物流 | Trading API / Token |
| TikTok Shop | esync-tiktokshop | 订单、FBT库存、发货、商品 | Open API / App Key |
| Shopee | esync-shopee | 订单 | OAuth |
| Shopify | esync-shopify | 订单 | API Key |
| Temu | esync-temu | 订单 | App Key |
| Walmart | esync-walmart | 订单 | OAuth |
| AliExpress | esync-aliexpress | 订单 | OAuth |
| Wish | esync-wish | 订单、FBW履约 | OAuth |
| Joom | esync-joom | 订单 | API Key |
| Cdiscount | esync-cdiscount | 订单 | OAuth |
| SHEIN | esync-shein | 订单 | API Key |
3.2 数据拉取模式
所有平台遵循统一范式：
定时任务 → 获取 Token → 调用平台 API → 数据存入 MongoDB → 发送 Kafka → fulfillment 消费
Amazon 示例（最复杂的平台）：
- 订单拉取：SP-API OrdersV0，仅拉 MFN（自发货）未发货订单，FBA 由 Amazon 履约
- 库存拉取：FBA 库存 + 库龄报告 + 库存明细账本 + 库存汇总
- 财务拉取：13 种事件类型 + 结算报告，增量同步 + 补偿机制
- 广告拉取：SP/SB/SD 广告数据
补偿机制：补偿拉取最近 8 小时内遗漏的未发货订单，防止漏单。
3.3 授权体系
两种授权路径：
- ECPP 授权：早期授权方式
- Creekshub 授权：新的统一授权网关
一个店铺可同时支持两种授权方式，系统按优先级选择可用授权。
四、订单履行域（fulfillment 服务）
4.1 订单生命周期（15 步）
[1] 平台产生订单
↓
[2] esync 拉取订单（Amazon SP API / eBay API / TikTok API ...）
↓
[3] esync 持久化到 MongoDB（记录拉取状态，支持补偿和重试）
↓
[4] esync 发 Kafka 消息（topic: sync.order.{platform}）
↓
[5] fulfillment Consumer 消费（解析、转换、SKU匹配、货主绑定）
↓
[6] 订单进入履行系统
状态: examining(待审核) 或 unknown(未知货主) 或 improve_recipient_info(待完善收货人)
↓
[7] 自动/人工审核（AutoApproveRuleChain 责任链：无买家留言 + 地址校验）
↓
[8] 分仓分物流（39 种规则匹配 → 分配仓库 + 物流渠道）
↓
[9] 包裹创建（状态: Package Confirmation / 待配货）
↓
[10] 申请运单号（调用物流商 API 获取 tracking_number）
↓
[11] 派单至仓库（待配货 → 已配货 → 待仓库确认 → 仓库处理中）
↓
[12] 仓库出库（状态: Shipped / 已发货）
↓
[13] 自动标记发货（Kafka markship topic → BaseShipService）
↓
[14] 回传平台（Amazon ConfirmDelivery / eBay CompleteSale / TikTok Ship API）
↓
[15] 订单完成（状态: shipped / 已发货）
4.2 订单状态机
| 状态 | 说明 | 正常流转 |
|---|---|---|
unknown |
未知货主（商品未匹配到系统SKU） | ❌ 需人工处理 |
examining |
待审核 | ✅ → unship |
unship |
待发货 | ✅ → partship / shipped |
partship |
部分发货 | ✅ → shipped |
shipped |
已发货 | ✅ 终态 |
cancelled |
已取消 | ✅ 终态 |
improve_recipient_info |
待完善收货人信息 | ❌ 需人工补充 |
shippedException |
发货异常 | ❌ 需人工处理 |
4.3 分仓分物流规则引擎
39 种规则，涵盖：
| 维度 | 规则示例 |
|---|---|
| 买家/平台 | 物流买家指定、平台/账号、国家站点 |
| 收货地址 | 收货国家、省/州、邮编/邮编前缀 |
| 商品属性 | 平台SKU、店铺SKU、SKU前缀/包含/后缀、指定商品、长宽高区间、产品数量 |
| 订单属性 | 总金额、总运费、单价、总重量、单重量 |
| 物流属性 | Wish 妥投/A+/DDP/FBW、Amazon FBA |
| 组织属性 | 指定发货仓、指定企业、指定分类 |
规则按优先级排序，第一个命中的规则决定仓库和物流渠道。
4.4 多渠道发货（Amazon FBA/FBM/SFP）
| 渠道 | 全称 | 履约方 | ERP 参与环节 |
|---|---|---|---|
| FBM | Fulfilled by Merchant | 卖家自发货 | 全链路（分仓→派单→发货→标记） |
| FBA | Fulfilled by Amazon | Amazon 履约 | 创建 FBA 出库单 + 跟踪履约报告 |
| SFP | Seller Fulfilled Prime | 卖家发货但 Prime 标识 | 同 FBM，额外满足 Prime 时效 |
| FBW | Fulfilled by Wish | Wish 履约 | 类似 FBA，Wish 平台仓 |
| Wish 妥投 | Wish Delivery Confirm | Wish 国际物流 | 自动标记发货 |
FBM 流程（ERP 主流程）：
订单拉取 → SKU匹配 → 审核 → 分仓分物流 → 包裹创建 → 派单 → 仓库出库 → 标记发货
FBA 流程（Amazon 履约，ERP 辅助）：
Amazon SP API 拉取 FBA 订单 → ERP 创建 FBA 出库单 → 调用 Amazon CreateFulfillmentOrder
→ 定时拉取 FBA 履约报告 → 更新订单状态
五、仓库与库存域（inventory 服务）
5.1 10+ 仓库类型体系
| 仓库类型 | 代码 | 说明 | 对接方式 |
|---|---|---|---|
| 自营仓 | SELF(1) | YT仓（壹拓仓），公司自建中国仓 | YT API 对接 |
| 万邑通 | WINIT(2) | 第三方海外仓（美国/英国/德国等） | 万邑通 SDK |
| Amazon FBA | FBA(3) | Amazon 全球仓 | Amazon SP API |
| 百世云仓 | BEST(4) | 第三方国内仓 | 百世 API |
| Walmart WFS | WFS(5) | Walmart 履约仓 | Walmart API |
| Cdiscount FBC | FBC(6) | Cdiscount 法国仓 | Cdiscount API |
| MercadoLibre FULL | FULL(7) | 美客多拉美仓 | MercadoLibre API |
| Allegro | ALLEGRO(8) | 波兰平台仓 | Allegro API |
| 速卖通 | SMT(10) | 阿里速卖通仓 | AliExpress API |
| TEMU | TEMU(11) | Temu 平台仓 | Temu API |
| TikTok FBT | FBT(12) | TikTok 履约仓 | TikTok Open API |
物理仓 vs 逻辑仓：
- 物理仓：实际存在的第三方仓库或自营仓库
- 逻辑仓：虚拟层，一个逻辑仓可映射到一个物理仓，用于多销售渠道的库存虚拟化分配
5.2 库存体系
┌───────────────────────────────────────────────────────┐
│ 库存三维模型 │
│ │
│ 可用库存 (available_quantity) │
│ = 可被调拨/销售使用的库存 │
│ │
│ 待出库库存 (pend_quantity) │
│ = 已锁定但未出库的库存（已配货但仓库未发） │
│ │
│ 在途库存 (transit_quantity) │
│ = 已在调拨运输途中但尚未入库的库存 │
│ │
│ 不可用库存 (unusable_quantity) │
│ = 残次品/报废品/冻结库存 │
│ │
│ 总库存 = 可用 + 待出库 + 不可用 │
└───────────────────────────────────────────────────────┘
5.3 库存台账与同步
| 仓库类型 | 同步方式 | 同步频率 | 数据源 |
|---|---|---|---|
| FBA | 定时拉取 + Kafka 事件 | 实时/定时 | Amazon SP API |
| 万邑通 | 定时拉取库存变动日志 | 定时 | 万邑通 SDK |
| YT自营仓 | 定时拉取变更日志 | 定时 | YT API |
| 在途调拨 | 调拨出库时自动记录 | 实时 | 内部系统 |
台账填充流程：
数据源拉取 → 解析入库/出库/调整事件 → 写入库存台账 → 更新逻辑库存
5.4 库龄管理
- 数据来源：Amazon SP-API 库龄报告（Inventory Age Report）
- 统计维度：企业 / 仓库 / SKU / 销售 / 品类
- 同步状态判断：如果
pullTime早于当日凌晨，标记为异常
5.5 验货流程（万邑通专属）
仓库处理中 → 标记为待验货
│
├── 系统验货：待上传箱唛 → 仓库贴标 → 验货中 → 验货成功/失败
└── 人工验货：直接流转至待交运
验货成功 → 确认发货 → 触发 Booking
验货失败 → 飞书/钉钉通知 → 支持重新验货
5.6 货物标签与仓库打标
销售创建调拨单 → 上传外箱标签 + 货物标签
↓
提交仓库 → 标签随出库单推送至仓库
↓
万邑通：仓库贴标 → 系统/人工验货
YT自营仓：无需贴标，直接处理
FBA：系统生成标签 PDF → 按调拨明细生成新标签
六、仓间调拨域（allocation 服务）
6.1 完整调拨流程（9 步）
[销售端]
[1] 创建调拨单（PENDING / 待提交）
- 选择企业/发货仓/目的仓/物流渠道
- 上传标签文件（外箱标签、货物标签）
- 填写调拨明细（货物及数量）
[2] 提交调拨单（WAITING_DISTRIBUTE / 待配货）
- 锁定逻辑库存
- 生成调拨履约单（FA+日期+序号）
[3] 配货/装箱（WAIT_PACK → PACKING → PACKED）
- 仓库确认装箱信息
- 审核装箱单
[仓库端 - inventory]
[4] 提交仓库（WAREHOUSE_PROCESS / 仓库处理中）
- 推送出库单至仓库
- 仓库处理配货
[5] 仓库完成配货（PENDING_INSPECTION / 待验货）
[万邑通：上传外箱标签 → 仓库贴标 → 系统/人工验货]
[YT自营仓：跳过验货，直接流转]
[物流端]
[6] 待交运（WAITING_TRANSPORT）
- 生成 Booking（交运预约）
- 生成 Shipment（货件）
[7] 交运（PART_TRANSPORTED → TRANSPORTED）
- 标记交运时间
- 物流跟踪
[目的仓]
[8] 目的仓收货入库
- 万邑通：入库单确认
- FBA：Amazon 货件接收
- YT自营仓：入库单审核
[9] 在途库存转为目的仓可用库存
- 台账记录调拨入库流水
- 逻辑库存更新：在途 → 可用
6.2 调拨单状态机
PENDING(待提交)
→ WAITING_DISTRIBUTE(待配货)
→ WAREHOUSE_PROCESS(仓库处理中)
├── 待审核装箱信息 → 已审核装箱信息
└── 仓库完成配货
→ PENDING_INSPECTION(待验货) ← 仅万邑通
→ WAITING_TRANSPORT(待交运)
→ PART_TRANSPORTED(部分交运)
→ TRANSPORTED(已交运)
并行分支：
→ WAIT_CANCEL(待取消) → CANCELED(已取消)
→ CANCELLED_AFTER_MERGE(拼单已作废)
6.3 拼单业务
调拨单拼单是将多个调拨单合并为一个履约单：
- 选择多个待提交调拨单 → 合并生成新调拨单 A003
- 新调拨单创建出库单 → 推送至仓库
- 原调拨单标记为"已合并"
- 分布式事务：创建新单 + 标记旧单 + 创建出库单必须在同一事务中
七、财务与 BI 域（finance/statistics 服务）
7.1 Amazon Finance API 13 种事件
| 事件类型 | 业务含义 |
|---|---|
| ShipmentEvent | 订单发货：商品售价、配送费、礼品包装费、促销折扣、佣金、FBA费用 |
| RefundEvent | 退款：退款金额、退款费用调整、退款税费 |
| AdjustmentEvent | 费用调整：Amazon 对历史费用的修正 |
| ChargebackEvent | 拒付：买家信用卡拒付 |
| RetrochargeEvent | 追溯收费：Amazon 事后补收的费用（如佣金差额） |
| DebtRecoveryEvent | 债务恢复：Amazon 追讨欠款的扣款与恢复 |
| RemovalShipmentEvent | 移除/退仓：FBA 库存移除产生的费用 |
| ServiceFeeEvent | 服务费：月租费、计划服务费 |
| ProductAdsPaymentEvent | 广告付费：SP/SB/SD 广告花费 |
| CouponPaymentEvent | 优惠券：优惠券折扣及 Amazon 补贴 |
| GuaranteeClaimEvent | 保障索赔：A-to-Z 索赔等 |
| SellerDealPaymentEvent | 卖家交易付款 |
| RemovalShipmentAdjustmentEvent | 退仓费用调整 |
7.2 对账流程
[数据采集] esync-amazon 拉取 Finance Events + Settlement Report
↓ MongoDB
[消息通知] FinanceChangeEvent → Kafka
↓
[数据入仓] creeks-statistics 消费 → 写入 ClickHouse amazon_payment_detail
↓
[SKU 匹配] 关联 mall_goods_snapshot（商品快照表）
↓
[维度关联] 店铺 + 企业 + 品牌 + 核算分类 + 汇率
↓
[结算宽表] amazon_settlement_detail
├── Amazon 财务数据：销售额、FBA费用、佣金、广告费...
└── 内部业务数据：采购成本、头程成本、运费...
↓
[对账校验] exceptionTag 标记异常数据
7.3 BI 报表体系（15+ 报表）
| 报表 | 统计维度 | 核心指标 |
|---|---|---|
| 每日业绩统计表 | SKU + 日 + 企业 + 平台 | 销售额、销量、退款额、采购成本、头程成本、广告费、毛利额/率 |
| Amazon 结算明细 | 结算单 + SKU | 商品售价、FBA费用、佣金、促销折扣、采购价、头程价 |
| 退货率报表 | SKU/SKC/SPU 维度 | 退货率、退货原因分布 |
| 广告日报/周报 | 广告活动 + 日/周 | 广告花费、ACOS、ROAS |
| 库存周转率 | SKU + 仓库 | 周转天数、周转率 |
| 月度毛利统计 | 企业 + 月 | 毛利额、毛利率、各项成本占比 |
| 月度库存成本 | 企业 + 月 | FBA仓储费、长期仓储费 |
| FBA 库龄分析 | 仓库 + SKU + 库龄段 | 库龄分布、滞销预警 |
| 近7天日均销量 | SKU | 7天平均销量、趋势 |
| 商品销量统计 | 商品维度 | 累计销量、销售额 |
7.4 毛利计算模型
毛利额 = 销售净额 - 所有成本
成本项包括：
├── 采购成本 = 采购单价 × 销量
├── 头程成本 = 头程单价 × 重量 × 销量
├── 广告费 = 按企业费用占比分摊
├── FBA 配送费
├── 销售佣金
├── FBA 弃置费
├── FBA 赔偿费
├── FBA 仓储费 + 长期仓储费
├── 直邮费 + 尾程费
├── 店铺服务费
├── 收款服务费
├── VAT 税费
└── 其他公共费用（按企业费用占比规则分摊）
毛利率 = 毛利额 / 销售净额
八、数据权限体系
8.1 权限层级
用户 (UmsUser)
→ 所属企业 (enterpriseId)
→ 所属业务单元 (businessUnit)
→ 管理的店铺 (storeName)
→ 站点 (nationName)
8.2 数据隔离策略
| 层级 | 隔离维度 | 实现方式 |
|---|---|---|
| 企业级 | 用户只能看到所属企业的数据 | 报表按 enterpriseId 分区生成 |
| 业务单元级 | 同一企业内不同 BU 的数据隔离 | 查询参数过滤 |
| 店铺级 | 用户只能管理授权的店铺 | 店铺授权关系表 |
| 报表级 | 不同角色的报表查看权限不同 | 角色权限控制 |
8.3 企业费用占比配置
每个企业可配置独立的费用分摊规则：
- 支持按平台、站点、核算分类三个维度设置默认分摊比例
- 用于将公共费用（仓储费、广告费等）分摊到各 SKU
- 支持手动调整单个 SKU 的分摊比例
九、业务难点与解决思路
难点一：SKU 匹配的多对多映射
业务问题：平台 SKU（sellerSku）与系统 SKU（productCode）不是一一对应的。同一个产品在不同平台有不同 SKU，同一平台不同店铺也可能不同。
解决方案：
- 建立平台 SKU → 系统 SKU 的映射关系表
- 订单进入时通过
storeName + sellerSku + productId三重匹配 - 匹配失败则标记为
unknown（未知货主），需人工认领
难点二：多渠道发货的差异化履约
业务问题：Amazon FBA 由 Amazon 履约，FBM 需要 ERP 派单发货，FBW 类似 FBA 但在 Wish 平台，SFP 需要满足 Prime 时效要求。每种渠道的履约流程完全不同。
解决方案：
- 订单类型标识（1=平台订单、2=手工订单、3=FBA、4=FBW）
- 每种类型走不同的履约子流程
- 策略模式：每个平台一个
BaseShipService实现，差异化标记发货逻辑
难点三：多仓库库存一致性
业务问题：同一 SKU 在 FBA（3个仓库）、万邑通（2个仓库）、YT自营仓各有库存，如何保证全局库存准确？
解决方案：
- 逻辑仓虚拟层：将物理仓映射为逻辑仓
- 库存台账：定时拉取各仓库变动日志，按 SKU 汇总
- 在途库存记录：调拨出库时自动记录，入库时自动转正
- 对账机制：每日比对台账余额与物理仓余额，差异自动告警
难点四：财务对账的数据完整性
业务问题：Amazon Finance 事件是按结算周期分批返回的，一次结算可能分多次拉取，如何确保数据完整？
解决方案：
- 结算报告完整性校验：总金额必须等于明细金额之和
- FinanceGroup 状态机：OPEN → CLOSED，CLOSED 后不再重复拉取
- 数据保留策略：超过 2 年的 Group 自动标记跳过
- 增量同步：记录 lastFinanceSyncEndTime，每次从上次结束点继续
难点五：调拨单拼单的分布式事务
业务问题：拼单需要同时操作调拨单（allocation 服务）和出库单（inventory 服务），任一失败需全部回滚。
解决方案：
- Seata AT 分布式事务，
@GlobalTransactional保证原子性 - 前置校验：先检查所有原调拨单状态是否允许合并
- 锁机制：拼单过程中对原调拨单加分布式锁，防止并发修改
@GlobalLock解决脏读：拼单完成前，其他请求查不到新调拨单
十、个人业务贡献
10.1 参与的业务域
| 业务域 | 涉及服务 | 参与程度 |
|---|---|---|
| 平台对接 | esync（12+ 平台） | 全流程：数据拉取、授权管理、数据建模 |
| 订单履行 | fulfillment | 全流程：SKU匹配、审核、分仓、派单、标记发货 |
| 仓库管理 | inventory + yt | 全流程：库存台账、库龄、验货、标签、三方对接 |
| 仓间调拨 | allocation | 全流程：调拨单、履约、装箱、交运、入库 |
| 财务对账 | finance + statistics | 全流程：Finance API对接、对账、BI报表 |
| 数据权限 | creekson-api | 企业/业务单元/店铺三级权限隔离 |
| 多渠道发货 | fulfillment + esync-amazon | Amazon FBA/FBM/SFP 差异化履约 |
10.2 解决的关键业务问题
- 从 0 到 1 搭建订单履行链路：实现从平台订单拉取到最终标记发货的完整闭环
- 多平台统一对接框架：12+ 平台共用一套数据拉取 → Kafka → 消费的架构
- 10+ 仓库类型统一管理：FBA/FBT/万邑通/YT 等不同类型的库存、验货、入库统一建模
- 财务对账体系搭建：Amazon Finance 13 种事件类型对接，15+ 报表维度生成
- 分布式事务落地：跨 fulfillment → inventory 的 Seata AT 模式，18 处全局事务保证数据一致性
10.3 业务规模
- 平台覆盖：12+ 跨境电商平台
- 仓库类型：10+ 种仓库类型
- 订单处理：日均处理订单数万级
- 报表维度：15+ 种 BI 报表
- 财务事件：Amazon 13 种事件类型全覆盖
十一、简历提炼版
版本 A：一句话概述（适合简历项目介绍）
参与跨境电商 ERP 系统全链路业务开发，覆盖主流电商平台（Amazon/eBay/TikTok 等）的数据对接、订单履行全生命周期（拉取→审核→分仓→派单→发货→回传平台）、多类型海外仓（FBA/FBT/万邑通/自营仓）的库存与调拨管理、Amazon 财务对账与多维 BI 报表生成。
版本 B：三段式（适合简历核心模块）
- 订单履约：参与订单从平台拉取到标记发货的完整链路，实现 SKU 匹配、自动化审核、多维度分仓分物流规则引擎、多渠道发货（FBM/FBA/SFP），全流程自动化流转
- 仓储与调拨：管理 Amazon FBA、TikTok FBT、万邑通海外仓、自营 YT 仓等多种仓库类型的库存体系（逻辑/物理/在途/可用），参与仓间调拨从创建、装箱、验货、交运到入库的完整业务流程
- 财务对账与 BI：对接 Amazon Finance API 实现销售/退款/广告/调整等多类财务事件的自动对账，生成涵盖销售额、成本拆分、毛利核算、退货率、库存周转等多维度报表，为运营决策提供数据支撑
十二、面试话术参考
版本 A：1 分钟标准版（"介绍一下你们的项目"）
"我参与的是一个跨境电商 ERP 系统，主要服务集团内多个事业部的跨境业务。简单说，就是帮运营人员把从平台接单到发货回传的整个流程自动化。
订单这边，我们从 Amazon、eBay、TikTok 这些平台定时拉取订单，进入系统后自动匹配商品 SKU、审核，然后根据一套规则引擎决定从哪个仓发、走哪个物流渠道，最后派单给仓库出库，自动标记发货回传平台。
仓库方面比较杂，有 Amazon 的 FBA 仓、TikTok 的 FBT 仓、万邑通这种第三方海外仓，还有我们自己搭建的 YT 仓。每种仓库的库存管理方式、对接的 API、验货流程都不一样。仓间调拨也是核心业务，从一个仓调到另一个仓，中间要经过装箱、验货、交运、入库好几个环节。
财务这块，我们对接了 Amazon 的 Finance API，把销售、退款、广告费、佣金调整这些财务数据拉回来，跟订单数据做对账，最终生成多维度的 BI 报表，运营能看到每个 SKU 的毛利额、毛利率、各项成本占比，方便他们判断哪些品值得继续做。"
版本 B：3 分钟深入版（面试官追问"你具体做了什么"）
"我主要负责的是订单履行和仓储调拨这两块业务。
订单履行这块，核心要解决的是订单进来之后怎么高效处理的问题。平台拉过来的订单，商品 SKU 不一定能跟我们对上，这时候要做匹配，匹配不上的标记出来让人工认领。匹配上了之后走审核流程，审核通过就进入分仓分物流——这块我们做了一套规则引擎，根据收货地址、商品属性、订单金额这些条件，自动决定从哪个仓发、走哪个物流。分好之后创建包裹，申请运单号，推送给仓库，仓库出库后自动标记发货回传平台。
仓储调拨这块，业务复杂度比较高。不同仓库的管理模式差异很大——FBA 是 Amazon 全托管的，我们主要通过 API 拉库存和库龄数据；万邑通是第三方海外仓，需要走他们的 API 对接验货、入库这些流程；YT 仓是我们自营的，对接的是壹拓的 WMS 系统。仓间调拨的流程比较长，从销售创建调拨单开始，要经过配货、装箱、提交仓库、验货、交运，最后目的仓收货入库。万邑通还要额外走贴标和验货的流程，FBA 还要生成货件。
财务对账这块我也有参与，主要是 Amazon Finance API 的对接。Amazon 的财务事件分很多种——订单销售、退款、费用调整、广告费、A-to-Z 索赔等等，我们要把这些数据拉回来跟订单系统的数据做对账，确认没问题了再生成报表。报表维度也挺多的，最核心的是每日业绩统计，按 SKU 维度把销售额、各项成本、毛利额毛利率都算出来，运营每天看这个判断经营状况。"
版本 C：关键业务点速查（面试官随机问）
| 面试官可能问的问题 | 关键回答要点 |
|---|---|
| "你们订单量大概多少？" | 日均数万级订单，涉及多个平台多个店铺 |
| "分仓分物流是怎么分的？" | 规则引擎，按收货地址、商品属性、金额、重量等维度匹配，命中第一条规则就决定仓库和物流 |
| "SKU 匹配怎么做的？" | 平台 SKU + 店铺 + 产品 ID 三重匹配，匹配不上标记为未知货主，人工认领后建立映射关系 |
| "库存怎么管理的？" | 逻辑仓虚拟层 + 物理仓实际库存，逻辑库存分可用/待出库/在途/不可用四个维度，定时从各仓库同步台账 |
| "调拨是什么场景？" | 不同仓之间补货，比如 FBA 缺货了从 YT 仓调一批过去，中间要经过装箱、验货、交运、入库 |
| "财务对账怎么做的？" | 拉 Amazon Finance 事件数据 + Settlement Report，跟订单数据关联比对，差异标记异常，对齐后生成毛利报表 |
| "BI 报表主要看什么？" | 最核心的是每个 SKU 的毛利额和毛利率，拆开来看销售额、采购成本、头程成本、FBA 费用、广告费占比等 |
| "多渠道发货是什么意思？" | Amazon 有 FBA（Amazon 发货）和 FBM（自己发），FBM 走 ERP 履约流程，FBA 调 Amazon API 创建出库单 |