去年冬天我帮一家做家居品类的跨境卖家做履约复盘，他们有 6 个店铺分布在亚马逊、Shopify 和 TikTok Shop，ERP 后台显示当天 1,842 单“同步成功”，但仓库实际只发货了 1,536 单，物流商只回传了 1,297 条轨迹。剩下那 306 单，客户在催、客服在查、仓库说没收到、ERP 说已经推了。这就是我想写这篇文章的原因：订单同步和跨境物流衔接，从来不是两个模块的事，而是一条状态链上的同一件事。
把“抓单”当成同步、把“拿面单”当成物流衔接，是跨境 ERP 规划里最贵的一个认知错误。下面这些内容，来自我过去几年做跨境系统选型和实施时踩过的坑，也有我自己跑数据核对出来的观察。
如果你只看一句话，我希望是这句：ERP 在跨境履约里的核心职责，是把平台订单状态、ERP 内部状态、仓库作业状态、物流轨迹状态这四个原本互不相通的状态体系，映射成一条可追溯、可告警、可对账的统一状态流。订单同步是这条流的入口，物流衔接是这条流的出口，中间任何一段断裂，都会以客诉的形式在出口爆发。
判断一：同步成功率是最容易造假的一个指标。很多 ERP 的“同步成功率 99.9%”只统计了 API 调用是否返回 200，不统计订单是否真的完成了后续动作。返回 200 但字段缺失、返回 200 但被下游规则拦截、返回 200 但重复推送了三次，都不计入失败。我在一次排查中发现，某 ERP 报的同步成功率是 99.7%，但仓库实际可执行订单率只有 83.4%，中间 16.3 个百分点的差距全部藏在“同步成功但不可执行”里。
判断二：物流衔接的难点不在发货，在回传。获取面单是一次性动作，轨迹回传是持续性动作。面单失败你能立刻看到，轨迹断流往往要等客户来问才知道。我统计过一家卖家的客诉来源，物流相关客诉里 68% 属于“轨迹超过 72 小时没有更新”，而不是“发不出去”。
判断三：规划顺序错了，后面全是返工。先接平台、再选物流商、最后补异常处理，这个顺序看起来很自然，但等到补异常处理时，你会发现状态字段根本不够用，只能推倒重来。正确的顺序是：先定义状态模型，再定义接口，最后定义异常和指标。
我把这条链拆成 11 个状态节点，你可以对照自己现在的系统检查，看哪几个节点在你的 ERP 里是“黑盒”。
这 11 个节点里，第 3 到第 7 属于订单同步的范畴，第 7 到第 11 属于物流衔接的范畴，而第 4 和第 7 之间的“校验，占库存，拣货”恰恰是绝大多数断点发生的地方。原因很简单：这段路跨越了三个系统（ERP、WMS、物流商），但没有一个系统天然拥有完整的状态视图。
我做过国内电商的 ERP 项目，也做过跨境电商的，两者最大的差别不是语言，而是链路的长度和不确定性。国内订单从下单到签收基本是一个闭环比，跨境订单要经过报关、干线、目的国清关、尾程派送，中间至少跨两个监管区、三个服务商。
（1）报关与申报数据段。国内发货不需要 HS Code、申报价值、原产地这些字段，跨境必须有，而且这些字段往往不在平台订单里，要靠商品主数据补齐。我见过最典型的问题是新品类上架后忘记维护 HS Code，结果一批货卡在面单获取环节，一卡就是三天。
（2）干线运输段。国内快递基本是单段运输，跨境至少是“揽收，出口报关，干线，进口清关，尾程”五段。每一段的承运方可能不同，轨迹格式也不同，有的给标准事件码，有的只给一段自由文本。
（3）清关不确定性段。这是跨境独有的一段“不可控时间”。同一批货，同样的申报信息，A 口岸三天放行，B 口岸可能七天。ERP 如果不把清关状态单独建模，你就无法回答“这批货到底是卡在物流还是卡在海关”。
（4）尾程与退货段。目的国尾程服务商可能是本地邮政、也可能是商业快递，签收方式差异很大。退货更麻烦，跨境退货成本高，很多卖家选择“不退货只退款”，这又带来一个新状态：资金已退但货权未清，ERP 如果不记录，库存账永远对不上。
那次排查的过程值得完整写下来，因为它几乎覆盖了订单同步与物流衔接之间所有的典型缝隙。
第一步，我在 ERP 里筛选“已同步未发货”的订单，找到 306 单。第二步，我把这 306 单的订单号导出，去平台后台逐个核对状态，发现其中 121 单在平台侧是“Unshipped”，正常；剩下 185 单，平台侧其实已经变成了“Canceled”或“Refunded”，但 ERP 里的状态还停在“待发货”。
第三步，我检查库存占用表，发现这 185 单里有 94 单占用了一批已经被合单消耗掉的库存，形成了幽灵占用。第四步，剩下 91 单，问题出在物流商适配层：它们的面单请求返回了失败，但错误码被 ERP 归类成了“未知异常”，没有触发任何告警，直接沉在日志里。
最后一算，306 单里真正的“同步失败”只有 31 单，其余 275 单全部是状态映射缺失、异常未告警、库存占用不释放这三类问题。这就是为什么我说同步成功率和履约完成率是两个完全不同的数字。
接下来这部分，我按“错误认知 → 表象 → 真实后果 → 正确做法”的结构来讲，方便你对号入座。
表象是“我们已经对接了六个平台”。真实后果是，订单进来了，但没有统一模型，字段各说各话。亚马逊的 ShippingAddress 是结构化对象，某些平台可能只是一段拼接文本；亚马逊有 MarketplaceId，独立站没有；TikTok Shop 的订单号规则和亚马逊完全不同。
正确做法是先定义统一订单模型，再谈对接。我通常会要求先落一份字段映射表，把订单号、店铺、站点、币种、SKU、数量、单价、运费、税费、折扣、收件人、地址、电话、邮编、承诺发货时间、物流方式这十几项字段做成强约束。
表象是“面单打印正常”。真实后果是轨迹不回传、状态不映射、费用不对账。物流衔接至少包含四件事：渠道选择、面单获取、轨迹回传、费用回传。只做前两件，你的 ERP 就只是一个面单打印机。
正确做法是把物流商接口抽象成四组标准能力：createLabel、getTracking、getFee、cancelLabel。任何一家新物流商接入，只实现这四组能力，核心代码不动。
表象是“ERP 里能打单、能拣货”。真实后果是多仓、多货主、批次效期、库位管理全部崩掉。ERP 的强项是订单中台和规则中枢，WMS 的强项是库内作业。让 ERP 干 WMS 的活，短期省了钱，长期一定在库存准确率上还回来。
我的经验边界是：单仓、SKU 少于 500、无批次管理的小卖家可以用 ERP 自带的简易发货功能；一旦涉及多仓、海外仓、FBA 中转、组合品拆装，就必须上独立 WMS，并把 ERP 和 WMS 的库存占用接口做严格定义。
表象是“主流程跑通了”。真实后果是所有异常都靠人工发现。我统计过一家年 GMV 约 8,000 万的卖家，他们售后团队 70% 的工作量集中在六类异常：面单失败、轨迹停滞、地址不可达、清关扣关、拒收退货、重复发货。
正确做法是在规划阶段就把异常分类、告警规则、处理动作、责任人和 SLA 一次性定义清楚。异常流程不是上线后再补的，它就是规划的一部分。
表象是“开发快”。真实后果是换物流商等于重做一次项目。我见过一家卖家因为某条线路时效崩了要换承运商，结果发现 ERP 里写死了那家承运商的字段和错误码，重构花了六周，期间只能手工导单。
讲了这么多问题，接下来讲方法。我给人做跨境 ERP 履约规划时，习惯用四张地图来推进：状态地图、接口地图、异常地图、指标地图。四张图缺一不可，而且必须按这个顺序做。
状态地图的核心动作，是列出平台状态、ERP 状态、WMS 状态、物流状态四列，然后逐行连线，明确哪些状态可以自动映射、哪些需要人工确认、哪些是一对多。
这里最容易出问题的是“一对多”。比如平台的“Canceled”可能对应 ERP 的“已取消”“已退款未取消”“部分退款”，也对应 WMS 的“拣货中需拦截”“已出库无法拦截”。如果不把这些组合穷举，取消订单就会变成一场灾难。
接口地图我一般画四条主干，每条主干标注方向、频率、协议、幂等键和失败处理方式。
以订单同步的幂等设计为例，我通常要求消息体里必须带一个稳定的业务键，处理端先查后写：
{
"idempotency_key": "SHOP_A:112-3456789-0123456:v1",
"shop_id": "SHOP_A",
"platform_order_no": "112-3456789-0123456",
"version": 1,
"event_type": "ORDER_PAID",
"event_time": "2026-01-12T08:31:22Z",
"payload": {
"items": [
{ "sku": "HM-CH-001", "qty": 2, "unit_price": 39.9, "currency": "USD" }
],
"ship_to": { "country": "US", "state": "CA", "zip": "90001" },
"promise_ship_deadline": "2026-01-14T23:59:59Z"
}
}
处理逻辑我一般写成三步：第一步用 idempotency_key 查幂等表，命中则直接返回上次结果；第二步做业务校验，校验失败进异常队列而不是抛错；第三步写订单主表并投递到下游队列。关键是第二步的失败不能当成接口失败，它应该是一个可被运营处理的业务异常。
异常地图的产出是一张表，四列：异常类型、触发条件、处理动作、责任人与 SLA。我列几条我常用的规则作为示例。
指标地图我放在最后，因为它是验收标准。没有指标地图，项目上线就是“看起来能跑”，出了问题无法量化。我常用的核心指标有七个，后面第八节会给出完整基线表。
前面讲的都是方法，这一节讲我实际怎么做观察。我的习惯是，不管用什么系统，一定要有一层独立于执行系统的数据核对层。ERP 负责执行，但执行系统的报表往往站在自己的视角看问题，看不到跨系统的缝隙。
原因很直接：ERP 的日志记录的是“我做了什么”，而数据核对层要回答“最终结果是什么”。这两者经常不一致。比如 ERP 日志显示面单请求成功，但物流商侧压根没有这个单号；ERP 显示已回传平台，但平台侧状态还是未发货。这类问题只能通过跨系统数据比对发现。
我在做这类核对时，用过数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。它的定位不是执行系统，而是把多平台订单数据和物流数据拉到一起做对账和监控。这个思路我觉得是对的：执行归 ERP，核对归数据层，两个视角互不替代。
（1）订单-轨迹双边核对。把平台订单表和物流轨迹表按运单号关联，找出“有订单无轨迹”“有轨迹无订单”“轨迹首扫时间晚于平台承诺发货时间”三类记录。我第一次跑这个核对时，在一个 6 店铺的账号里找出 214 条异常记录，其中 91 条是“面单已出但物流商从未揽收”。
（2）时效率分布观察。不看平均值，看分位数。平均时效 5.2 天听起来还行，但 P90 可能是 14 天，这 10% 的订单贡献了大部分客诉。我一般会把履约时长按 P50、P75、P90、P95 四个分位拉出来看，再按目的地国家和物流渠道分组。
（3）成本与渠道交叉核对。把物流商月度账单和 ERP 里的预估运费做差异比对，找出差异率超过 5% 的渠道。差异往往来自体积重计算方式、偏远地区附加费、退件费这几个不透明项。
这是我今年年初做的一次观察，样本是某家居品类卖家的 30 天数据，共 5.1 万单。我把关键指标和行业常见的“宣传口径”做了对比，差异非常明显。
| 指标 | ERP 后台显示 | 跨系统核对结果 | 差异原因 |
|---|---|---|---|
| 订单同步成功率 | 99.71% | 96.4% | 后台只统计 API 返回码，未统计业务校验通过率 |
| 面单获取成功率 | 99.12% | 97.3% | 未统计重试后成功的次数与最终失败次数差异 |
| 轨迹回传覆盖率 | 未提供 | 88.6% | ERP 无此指标，靠物流侧数据反查得出 |
| 发货回传平台及时率 | 98.5% | 94.1% | 未区分“回传成功”与“在承诺时间内回传” |
| 履约时长 P90 | 未提供 | 11.8 天 | 后台仅提供平均值，掩盖了长尾 |
| 物流异常率 | 2.1% | 5.7% | 清关扣关与轨迹停滞未计入 ERP 异常口径 |
这张表的重点不是数字本身，而是口径差异。你会发现，凡是“对自己不利”的指标，执行系统的后台往往不提供，或者用了更宽松的口径。这不一定是故意的，更多是系统设计视角的局限。
方法讲完了，但方法不能一刀切。我按业务规模分三档给建议，每档的优先级差别很大。判断自己属于哪一档，看的不只是 GMV，还要看店铺数、SKU 数、发货仓数量和团队技术能力。
这一档的核心建议是：不要自研，也不要追求全自动，用 SaaS ERP 的标准能力加一张核对表就够了。
优先做的事有三件。第一，把地址校验和 SKU 映射做扎实，这两件事能解决大部分同步类异常。第二，选定 1 到 2 家物流商，重点确认轨迹回传能力，而不是价格。第三，每周做一次订单-轨迹核对，找出异常单人工跟进。
不建议做的事：不要接五家以上物流商，管理成本会超过收益；不要做智能路由，数据量不够，规则调不准。
这一档是问题最集中的区间。规模上来了，但团队还没有专职的系统岗，ERP 用着但总是“感觉哪里不对”。
优先做的事：第一，建立统一订单模型和状态映射表，这一步必须做，跳过它后面所有优化都无效。第二，引入物流适配层，哪怕只是在 ERP 里做一层配置表，也要把承运商解耦。第三，定义异常分类和责任人，把异常从“靠人发现”变成“靠规则告警”。第四，搭建独立的订单-物流数据核对层，用于监控和验收。
我通常会把这一档的规划周期定为 8 到 12 周，分两次上线：第一次解决同步和状态映射，第二次解决物流适配和异常闭环。
这一档的问题不再是“能不能跑通”，而是“能不能稳定、能不能扩展、能不能对账”。
优先做的事：第一，ERP、WMS、物流 TMS 三层职责清晰切分，接口标准化。第二，建立多仓库存分配规则和拆合单规则，并且把规则可配置化而不是写死在代码里。第三，把清关状态单独建模，和普通运输轨迹分开。第四，做自动对账，包括运费对账和库存对账。第五，指标看板化，按渠道、国家、仓库维度下钻。
规划的本质是做取舍，而不是把所有能力都堆上去。这一节我讲四个最常见的取舍，每个都给出我的判断依据。
我的判断标准是“变更频率”。如果某个环节的业务规则半年以上不变，优先采购；如果变更频率高，且直接影响竞争差异，优先自研。
举个具体例子：面单获取能力半年不变，几乎每家的需求都一样，采购或调用标准接口即可。但订单分配和拆合单规则往往跟卖家的仓网结构、品类特性、平台政策强相关，而且会随业务变化调整，就值得自研或者至少掌握在自己手里。
全量同步实现简单，但对平台 API 压力大，容易触发限流，而且订单量上万后每天跑一次全量非常耗时。增量同步效率高，但需要处理漏单和对账。
我的做法是混合：用增量做日常同步，用全量做每日或每周对账兜底。这样既能保证效率，又能发现增量过程中漏掉的订单。这个兜底机制非常重要，我见过太多因为 Webhook 丢失导致漏单，最后靠客户投诉才发现的情况。
很多人的直觉是渠道越多越好，可以比价、可以备份。但实际情况是，每增加一家物流商，就要增加一套接口适配、一套异常规则、一套对账流程。超过 5 家之后，管理成本上升速度远超收益。
我的建议是：主渠道 2 到 3 家覆盖 85% 以上订单，备份渠道 1 到 2 家只用于特定线路或应急。选择主渠道时，把轨迹回传质量和异常响应速度的权重提到价格之上。
自动化不是越早越好。规则没稳定就自动化，等于把错误自动化放大。我的一般原则是：一个异常类型连续两个月人工处理规则稳定、且月发生量超过 50 次，才值得自动化。
比如清关扣关处理，很多卖家第一反应是自动化跟进。但清关场景差异极大，前期更适合人工积累判断逻辑，等归类稳定后再自动化。
规划做完了，怎么验收？我通常会给出一套基线表，并且强调：基线不是行业标准，而是你自己连续三个月的真实数据。先测出基线，再定目标，才有意义。
| 指标 | 计算口径 | 建议基线 | 低于基线时的优先排查点 |
|---|---|---|---|
| 订单同步成功率 | 业务校验通过订单 ÷ 平台已付款订单 | ≥ 97% | 地址校验规则、SKU 映射完整度、授权有效期 |
| 同步延迟 P95 | 平台付款到 ERP 接收的时间差 P95 | ≤ 15 分钟 | Webhook 是否稳定、轮询频率、限流处理 |
| 面单获取成功率 | 首次或重试后成功的订单 ÷ 发货订单 | ≥ 98% | 申报字段完整度、渠道限重限品、余额与授权 |
| 轨迹回传覆盖率 | 有有效轨迹的运单 ÷ 已出库运单 | ≥ 93% | 承运商事件码覆盖、揽收频次、接口拉取频率 |
| 发货回传及时率 | 承诺发货时间内回传成功的订单 ÷ 发货订单 | ≥ 96% | 回传重试机制、平台接口波动、时区处理 |
| 履约时长 P90 | 付款到签收时间差 P90 | 按渠道设目标 | 清关时效、尾程服务商、揽收等待 |
| 物流异常率 | 存在停滞、扣关、拒收、退件的订单 ÷ 发货订单 | ≤ 4% | 清关申报合规性、地址质量、承运商稳定性 |
（1）取消与退款并发场景。同一订单在极短时间窗口内先获取面单、再被平台取消，系统必须能正确拦截或正确回滚。这个场景我几乎每次验收都会测。
（2）接口超时与重试场景。人为让物流商接口超时，验证系统是否进入重试、重试是否幂等、三次失败后是否告警。这个场景能测出大部分“看起来成功实际失败”的问题。
（3）库存占用与释放场景。构造取消、部分退款、合单、拆单四种情况，验证库存是否精确释放。建议用 20 单做压力验证，然后逐单对账。
最后给一条我自己用过的推进路线，按三个阶段走，每个阶段 4 到 8 周。
目标是单平台、单物流商跑通全链路，并且状态可追溯。交付物包括：统一订单模型定义、状态映射表、幂等与重试机制、基础日志。这一阶段不要追求自动化，重点是让每一步都看得见。
目标是支持多平台、多物流商、多仓。交付物包括：物流适配层四组标准能力、异常分类与告警规则、库存占用与释放的完整测试用例、独立数据核对层。这一阶段最容易超期，因为异常场景的梳理比想象中耗时。
目标是降低人工介入比例。交付物包括：渠道智能路由、运费自动对账、库存自动对账、异常预测与主动跟进、按维度下钻的指标看板。这一阶段的前提是前两阶段的数据足够干净，否则自动化只会放大噪声。
回到最开始那个数字：1,842 单显示同步成功，1,219 单最终签收。中间那 623 单不是被某个技术难题吃掉的，是被状态定义不清、异常无人负责、口径各说各话这三件事吃掉的。
所以我的核心观点是：跨境 ERP 的订单同步与物流衔接，本质上不是接口工程，而是状态工程和口径工程。接口只是载体，真正决定成败的是你有没有把四套状态体系对齐、有没有给每个异常指定归属人、有没有一层独立的数据核对来验证执行系统的自述。
如果你只记三句话，我希望是这三句。第一，同步成功率不等于履约完成率，先定义口径再谈优化。第二，面单不是终点，轨迹回传和费用回传才是物流衔接的后半段。第三，执行系统和核对层要分开，前者负责动作，后者负责真相。
具体到下一步，我建议你今天就做一件事：拉出过去 30 天的已付款订单、已出库运单、物流轨迹这三张表，按运单号做一次关联，数一数“有订单无轨迹”和“有轨迹无订单”各有多少条。这个数字就是你现在真实的履约断点规模。把它作为基线，再按第九节的三阶段路线推进，你会比大多数只盯着 ERP 功能清单的人走得更稳。
如果你已经有 ERP、也已经接了物流商，但说不清具体卡在哪一层，那么先别急着换系统。把状态地图先画出来，很多问题不需要换系统，只需要把状态补全、把告警打开、把回滚逻辑写对，就能回收相当一部分损失。
我做亚马逊和独立站，后台订单量一上来就发现，ERP里显示订单已经同步成功，但仓库那边没收到发货指令，物流也没有轨迹，客户已经在催了。我一直以为订单同步做完，物流这块再接一下就行，但实际好像完全不是这样。
不是一回事，不能分开规划。订单同步解决的是平台订单进入ERP并保持状态一致，物流衔接解决的是ERP把发货指令交给承运商、再把面单和轨迹回传给ERP和平台。两者共用同一套订单状态机和同一个订单主键，如果先做完订单同步再补物流，通常会出现ERP状态和平台状态对不上、重复发货、单号回传失败等问题。
判断标准很简单：平台订单号、ERP内部单号、仓库出库单号、物流运单号这四个号能不能一一对应并可追溯，如果对不上，说明两块是割裂的。落地时建议先定义统一订单状态（待付款、待发货、已发货、已签收、取消、退款、异常），再让订单同步和物流回传都往这套状态上映射，而不是各自维护一套状态。
我同时做亚马逊、Shopify和TikTok Shop，每个平台的订单字段名、状态定义、金额口径都不一样，有的含税有的不含税，有的地址格式还是当地的。之前想直接抓过来用，结果SKU对不上、地址发不出去，想问问到底该怎么设计字段映射。
核心原则是先建平台无关的内部订单模型，再做平台字段到内部字段的映射，而不是让内部模型去迁就某一个平台。需要统一的字段至少包括：平台订单号、店铺标识、买家信息、收件地址、SKU与数量、商品金额、运费、税费、优惠、币种、下单时间、支付状态、履约状态。
状态不能直接照搬平台文案，要建立映射表，比如平台的Pending、Unfulfilled、Fulfilled分别映射到内部的待付款、待发货、已发货。
判断字段设计是否合格，看三点：换一个新平台接入时是否需要改动核心表结构、同一个SKU在不同平台能否归一到同一个内部SKU、税费和优惠能否还原到平台原始口径用于对账。地址建议保留原始地址字段再额外做一层标准化解析，不要只存解析后的结果，否则出错时无法回溯。
我们做促销的时候遇到过同一个订单被同步了两次，仓库发了两遍货，还有一次是库存没及时回传导致超卖，最后只能赔钱取消。我一直在想，这种问题是靠ERP功能解决，还是要在规划阶段就设计好。
要在规划阶段解决，不能指望事后补救。重复发货的根因通常是同步没有幂等性，做法是给每条订单消息定义唯一幂等键，一般用平台订单号加店铺标识，ERP处理前先判断该键是否已处理，处理结果落库后再返回；同时用消息队列保证至少一次投递的情况下业务只执行一次。
超卖要分两层：一层是库存占用，订单同步进来后立即在ERP侧预占库存并设置占用超时释放；另一层是库存回传，ERP的可用库存要按固定频率或事件触发回传平台，回传延迟要纳入监控。判断是否做到位，看两个口径：同一幂等键重复投递N次后，ERP内订单记录数和发货指令数是否仍为1；
促销期间库存回传延迟是否控制在可接受范围内，并明确超卖发生时以哪个系统的库存为准。这两件事必须在接入第一个平台时就设计好，后补成本极高。
我们接了好几家物流商，有的轨迹能实时更新，有的到了清关之后就没动静了，客户一直问。我分不清到底是物流商接口不行，还是我们ERP没接好，每次排查都要来回问好几方，特别耗时间。
先分层排查，不要直接归因。标准做法是建一个物流适配层，把面单、轨迹、费用、取消这几类能力抽象成统一接口，每个物流商单独实现。轨迹断了以后按顺序查：第一，看物流商API或Webhook是否真的推送了该事件，可以在适配层记录每次原始报文和时间戳；第二，看ERP是否成功接收并解析，检查解析异常日志；
第三，看是否成功映射成内部统一状态并回传平台，检查回传平台的成功率。如果原始报文里就没有这个事件，是物流商或承运环节的问题；如果报文有但ERP没入库，是解析或接收问题；如果入库了但平台没更新，是回传环节问题。判断依据建议用三个指标：面单成功率、轨迹事件及时率、轨迹回传平台成功率。
只有把这三段拆开监控，才能明确责任边界，也才能在对接新物流商时快速定位。
读者评论
我们做跨境客服最怕的就是轨迹断流，客户一问三不知。文中说物流客诉68%来自72小时没更新，很真实。ERP规划时确实要把清关、揽收、尾程拆成独立状态，并设置超时告警，不然客服只能反复问物流商。
从仓库实施角度看，幽灵占用和库存不释放是高频断点。ERP和WMS接口必须明确占用超时、拆合单回滚、取消单释放规则，否则后台显示同步成功，仓库却找不到可执行订单，最后全压在异常处理上。
作为产品经理，我认同先定义统一订单模型和状态机，再做平台对接。很多项目一上来就接六个平台，字段语义不统一，后面异常码、轨迹映射、费用对账都会返工。物流商接口抽象成创单、轨迹、费用、取消四组能力很实用。
中小卖家选型时容易把ERP当WMS用。单仓少SKU还能凑合，多仓、海外仓或FBA中转后库存准确率一定出问题。另外同步成功率要看可执行订单率，不能只看API返回200，否则运营指标好看但履约完成率很低。