去年黑五前一周，我陪一个做家居品类的跨境卖家做ERP上线前的最后验收。接口测试全绿，成功率99.8%，物流商那边也确认对接完成，双方在验收单上签了字。结果大促当天下午三点，系统在27分钟内连续发出1400多次取号请求，同一个订单被重复取号3次，仓库打印机吐出了3张贴着不同面单号的标签，库存被锁定却迟迟不释放，客服电话在半小时内被打爆。当天晚上复盘，问题不在物流商的API，而在这套ERP的取号流程没有幂等设计，也没有任何异常兜底。
这件事之后，我把"物流对接"从验收清单里的一个技术项，提到了流程设计质量评估的第一入口。下面这套检查方法，是我在十多个跨境项目里反复打磨出来的：怎么通过物流对接这条链路，反向体检一套跨境电商ERP的流程设计到底扎不扎实，哪些地方是能用钱解决的，哪些地方是设计缺陷、必须返工的。
大多数团队评估ERP，看的是功能清单：能不能对接物流商、支不支持多平台、有没有API。这份清单几乎没有区分度，因为功能可以演示，流程却藏不住。我见过的真实情况是，功能演示阶段相差无几的两套系统，在大促峰值下的表现能差出三倍以上。
物流对接的特殊之处在于，它是ERP唯一一条同时穿过订单、库存、仓储、财务、客服五个模块的链路。任何一个模块的流程设计偷懒，都会在这条链路上留下痕迹。你不需要把整套ERP翻个底朝天，只要沿着取号、面单、交运、轨迹、对账这五个节点走一遍，就能判断出七八成。
它不是代码质量，也不是接口数量，而是一套系统在面对不完整信息、不稳定依赖、不规则输入时，仍然能保持状态一致、责任清晰、可追溯、可恢复的能力。物流对接恰好把这三类压力同时施加给ERP。
信息不完整，指的是物流商回传的轨迹字段缺失、经纬度为空、城市名用了当地语言；依赖不稳定，指的是物流商API限流、超时、偶发502；输入不规则，指的是同一个买家拆成三单、申报价值随手填、收件地址写了半截。流程设计好的ERP能把这三种情况都收得住，设计差的系统会在这些地方集体崩盘。
回到开头那个项目。技术团队最初的判断是"物流商限流了"，理由是错误码里出现了大量429。但我们把27分钟内的请求日志按订单号去重后发现，实际订单只有480单，请求量却是1470次，重复率超过3倍。
根因是流程设计：取号请求发出后，系统只等待2秒；超过2秒没有响应就重试，重试不记录"已发起"状态，也不复用上一次的请求键。物流商那边其实每次都成功返回了面单，只是响应慢了1到3秒。结果是买家收到一次货，仓库打了三张面单，财务被计了三次取号费，库存锁定了三次但只释放了一次。
这不是接口问题，是流程问题。一个合格的取号流程，至少要有幂等键、超时熔断、结果补偿三个设计点。我后来把这套判断整理成了一个可以复用的检查逻辑：
key = md5(tenant_id + order_no + carrier_code + warehouse_id) if redis.set(key, "LOCKED", nx=True, ex=120) is False: return cached_result(key) # 返回上次结果，绝不重复向物流商取号 try: label = carrier.get_label(payload) except Timeout: schedule_compensation(key, delay=30) # 进入补偿队列，由查询任务收敛 raise else: redis.set(key, label, ex=86400) write_shipment_event(order_no, tracking_no, "LABEL_CREATED")
注意最后一行。取号成功只是开始，写入状态事件才是流程闭环。 我见过太多系统取号成功了，但没有把tracking_no和订单状态机绑定，导致后续轨迹回传找不到归属订单，只能靠人工在Excel里对。
第二个项目做的是东南亚市场，卖家反馈有大约200单显示"已揽收"，但买家端查不到任何物流信息，客服每天要手工回复几十条"包裹在哪里"。
排查下来是两个设计缺陷叠加。第一，ERP把物流商回传的"已揽收"事件当作终态直接落库，没有做事件去重和时间戳排序，导致后到的"派送中"事件被旧状态覆盖。第二，轨迹事件的字段解析是硬编码的，只认识英文状态码，物流商在部分地区回传的是泰文和越南文，系统识别不了就静默丢弃。
这类问题在功能演示时完全看不出来，因为它只在特定国家、特定物流商、特定字段组合下触发。我给团队的判断标准很简单：轨迹完整率低于90%的ERP，基本可以判定状态机设计不够健壮。
正常的履约链路，从下单到签收，每个节点的转化率都应该是一个可观测的数字。当某个节点突然掉5个百分点以上，而接口成功率没有任何变化，问题几乎一定出在状态处理而不是网络层。
第三个项目是一个多店铺卖家，月均出单4万左右。财务对账时发现物流商账单比ERP预估运费多了8.6万元，比例约3.2%。这个数字本身不算离谱，但查了三天都没查出原因，最后是我用SQL把两边数据拉平才定位到。
问题不在金额，在口径。ERP用的是实际重量算运费，物流商用体积重和实重取大者；ERP没有维护燃油附加费费率表，物流商按周浮动加收；退件费在ERP里没有科目，被归到了"其他支出"；还有一部分汇率折算差，来自系统按月初汇率固定折算。
这四类差异加起来正好解释了那8.6万元。也就是说，这不是财务算错账，而是ERP的运费试算模型在设计时就没有为对账留接口。
我把上面三个场景的教训归纳成一个总纲：任何一套跨境电商ERP，最终都要接受四本账的检验，订单账、物流账、库存账、财务账。四本账能对齐，说明流程闭环；对不上，说明中间至少有一环在做表面处理。
| 账本 | 核心核对内容 | 常见不一致表现 | 暴露的流程缺陷 |
|---|---|---|---|
| 订单账 | 平台订单数、ERP订单数、发货订单数 | 平台已发货但ERP仍是待发货 | 状态回写单向、缺少对账补偿任务 |
| 物流账 | 取号数、面单数、揽收数、签收数 | 取号成功但无轨迹、重复取号 | 幂等缺失、事件去重缺失 |
| 库存账 | 锁定库存、在途库存、可售库存 | 订单取消后库存未释放 | 缺少超时释放与逆向回补机制 |
| 财务账 | 预估运费、实际运费、附加费、退款 | 差异率长期高于2%且无法归因 | 计费模型未建、附加项未建模 |
这张表是我做项目体检时最先拿出来的一张。只要四本账里有任何一本对不上，就不需要继续看功能清单了，先把对账逻辑补上。
接口成功率是一个技术运维指标，它回答的是"请求有没有得到响应"，而不是"业务有没有正确完成"。这两个问题之间隔着状态一致性、幂等性、异常闭环三道关卡。
我曾经跟踪过一个卖家的月度数据：1月到4月，接口成功率从98.1%稳步提升到99.7%，技术团队每周都在报喜。但同期客服工单数从420单涨到了640单，涨幅超过50%。原因很简单，技术团队把大量异常请求改成了"降级返回成功"，接口好看了，异常全部堆到了客服那里。
物流对接涉及至少四个部门的真实利益：仓库关心面单能不能打、运营关心渠道选择对不对、客服关心轨迹查不查得到、财务关心账单能不能对。如果这个项目由研发单独推进，验收标准就会自然退化成"接口通了"。
我的经验是，物流对接项目的验收会必须让财务参加。只要财务在场，对账口径、附加费建模、汇率折算这三个问题就绕不过去，而这三个问题恰恰是流程设计里最容易偷工减料的地方。
我统计过自己经手的六个项目，测试用例里正向流程平均占82%，异常流程占14%，逆向（退换货、理赔）只占4%。而线上真实发生的工单里，异常和逆向加起来占到了六成以上。
这个比例失衡，直接导致很多流程缺陷在验收阶段被完美隐藏。我建议的测试用例配比是：正向50%、异常35%、逆向15%。逆向流程必须单独设计用例，包括买家拒收、清关退件、二次派送、理赔申请四条路径。
异常件的类型分布本身就很有信息量。如果一个ERP的异常类型只有"其他"一个选项，说明异常分类根本没做设计。
我在需求评审会上最怕听到的一句话是"这个流程全自动，不需要人工"。跨境物流的不确定性太高，任何声称零人工的设计，最后都会变成零告警的静默失败。
正确的设计目标不是全自动，而是自动为主、人工兜底、全程留痕。系统应该清楚知道自己在哪些情况下必须停下来找人，并且把停下来这件事本身变成一个有记录、有分派、有SLA的事件。
上面讲的都是现象。要把现象变成可复用的判断工具，我把它压成了三层结构：连通层、流程层、经营层。每一层三个检查项，合计九检。这个框架的好处是，你不需要懂技术细节也能用它做判断，而且三层之间是递进关系，前一层不过关，后一层没有意义。
这一层看三件事。第一是鉴权与限流策略，系统是否区分了物流商的QPS上限、是否有独立的令牌桶、超限后是排队还是直接失败。第二是错误码语义，物流商返回的几百个错误码，ERP有没有映射成业务可读的分类，比如"可重试""需人工""需换渠道"。第三是环境隔离，有没有沙箱环境，灰度发布怎么做的。
这一层的判断标准很直接：如果错误日志里出现的是物流商的原始错误码，说明连通层还没做完。 业务人员看不懂的错误，等于没有错误处理。
流程层是三层里最关键的一层，也是最能区分ERP水平的一层。核心是三件事：状态机一致性、幂等与重试、异常闭环。
状态机一致性指的是ERP订单状态与物流状态的双向映射。这里必须有一张显式的映射表，而不是散落在代码的if-else里。一张合格的映射表长这样：
{
"carrier_state": "PICKED_UP",
"erp_order_status": "SHIPPED",
"inventory_effect": "DEDUCT_LOCKED",
"finance_effect": "ACCRUE_FREIGHT",
"customer_notice": "SHIP_CONFIRMED",
"idempotent_key": "carrier_code + tracking_no + event_code + event_time",
"conflict_rule": "只接受 event_time 晚于当前状态时间的事件"
}
这张表把状态变更和库存、财务、通知的副作用绑在一起，是流程设计成熟的标志。如果一套ERP的状态变更只改订单状态，库存和财务各自异步处理，那四账迟早会对不上。
幂等与重试看的是失败恢复能力，我在第三节已经给了具体做法。异常闭环看的是系统能不能自己发现问题、分派人、跟到底。判断标准是：异常件从产生到闭环，是否全程在系统内可追踪，而不是在微信群里追。
经营层是最容易被忽略的一层，因为很多团队认为"技术验收完就结束了"。但没有经营层的指标，前两层做得再好也无法证明价值。
我通常在经营层放五个指标：订单履约时效（下单到交运的小时数）、运费偏差率（预估与实际）、异常闭环平均时长、单均物流成本、因物流问题产生的退款率。这五个数字如果每个月都在改善，说明流程设计是活的；如果三个月没有变化，说明系统只是在跑，没有在优化。
把九检做成评分卡，每项1到5分，总分45分。我的经验阈值是：低于25分基本不可用于多国多渠道场景；25到34分可以用，但必须配套人工对账；35分以上才具备规模化的基础。
评分时最容易出现的偏差是"被演示打动"。我建议的规避方法是不看演示，直接要沙箱账号，自己用异常单去测。测三件事就够了：同一个订单连点五次取号、把面单请求的超时时间调到500毫秒、手动构造一条乱序的轨迹事件。
前文提到的黑五案例，最终的处理方式不是改接口超时时间，而是重建了整个取号流程。我们在两周内做了三件事：引入基于订单维度的幂等键并写入Redis；把同步取号改成"同步尝试加异步补偿"，同步等1秒，超时的一律进补偿队列，由后台任务在30秒后查询结果；库存锁定增加15分钟的自动释放定时器。
上线后的第一次大促，取号请求量下降到接近订单数，重复取号率从3.1倍降到1.02倍，库存超卖从17单降到0单。这里最关键的判断是：超时的正确反应不是重试，而是查询。 因为绝大多数超时并不是请求没到，而是响应没回来。
东南亚那个项目的改造方案是两条。第一，轨迹事件落库前先按event_time排序去重，只接受时序上更晚的事件，乱序事件进入待人工确认队列。第二，建立轨迹字段映射表，把各物流商的多语言状态码统一映射到内部八种状态：已下单、已揽收、干线运输中、到达目的国、清关中、派送中、已签收、异常。
改造后的效果是轨迹完整率从76%升到93%，"包裹在哪里"这类工单下降约六成。这个案例让我更确信一个判断：轨迹最大的价值不是给买家看，而是给客服和财务提供一个可以自动判断的事实依据。
回到那8.6万元的差异。我做的事情其实很简单，把ERP的发货记录、物流商的对账单、平台结算单三份数据拉到同一张表里，按tracking_no做全外连接，然后把差异按类型打标。核心的查询逻辑大致是这样：
SELECT
o.order_no,
o.estimated_fee AS erp_fee,
b.freight_amount AS carrier_fee,
o.chargeable_weight_kg AS erp_weight,
b.chargeable_weight_kg AS carrier_weight,
b.freight_amount - o.estimated_fee AS diff_amount
FROM erp_shipment o
FULL OUTER JOIN carrier_bill b
ON o.tracking_no = b.tracking_no
WHERE ABS(b.freight_amount - o.estimated_fee) > 5
ORDER BY diff_amount DESC;这一步只是把差异捞出来，真正有价值的是后面的归因。我把差异分成了五类，逐类核对之后，8.6万元的构成完全清晰了。
需要说明的是，做这类跨系统对账，用Excel处理4万条记录会很吃力，公式一多就容易出错。我后来改用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）这类面向跨境场景的数据分析工具来做。我的用法是把ERP导出的发货明细、物流商的月度账单、平台结算单分别接入，统一tracking_no的口径后做全连接比对，再用差异类型字段做分组汇总。
它对我的实际价值有三点：一是把原来两天的人工核对压缩到半天以内；二是差异可以按物流商、按国家、按渠道做下钻，很容易看出是哪一条线路的口径出了问题；三是每个月的数据留痕，可以看到差异率是在收敛还是在扩大。当然它不解决ERP本身的设计问题，它解决的是"你知不知道问题在哪里"，这两件事必须分开看。
我把六个常用物流商的接口表现和订单结果放在一起看，发现一个在选型阶段很少被提及的规律：接口P95响应时延超过2000毫秒的物流商，其对应订单的当日取消率明显更高。这不是因为物流商慢，而是因为慢导致ERP取号超时、订单卡在待发货、买家等不及取消。
这个观察的实际意义是：物流商的技术能力应该成为选型指标之一，而不是只看价格和时效。 一个报价便宜5%但接口P95常年3000毫秒的渠道，可能因为取消率和客服成本把这点差价全部吃掉。
不要看功能演示，直接申请沙箱账号，用我前面说的三个动作去测：同一订单连续取号五次、把超时阈值调到500毫秒、构造一条乱序轨迹事件。这三个测试加起来不超过半天，但能筛掉大部分流程设计不成熟的系统。
另外，一定要问供应商一个问题："你们的运费试算模型，支持体积重和实重取大吗？支持燃油附加费按周同步吗？"如果对方答不上来，说明这套ERP的对账模块大概率是空的，后续所有对账工作都会落到财务的Excel上。
把验收会拆成两场。第一场是技术验收，看接口、错误码、监控；第二场是流程验收，必须让仓库、客服、财务三个部门各出一个验收人，并且每人出一道他们最怕遇到的问题作为验收用例。
我自己的做法是在流程验收会上只问一个问题："如果这个环节出错了，系统会怎么通知你？"如果答案是"我打电话问技术"或者"我看微信群"，那这个环节的流程设计就是不完整的。
优先补三样东西：幂等键、状态映射表、异常分级规则。这三样的建设成本不高，但对流程质量的提升最明显。特别是状态映射表，它应该以配置而不是代码的形式存在，因为物流商的状态码是会长年变化的。
另外，请务必为每个物流商保留接口调用的快照，包括请求时间、请求参数、响应内容、错误码。这不是为了排查问题，而是为了对账时能证明"当时系统发出的请求是什么"。没有快照，对账就只能靠猜。
建立月度三件事的例行机制：跑一次四账核对、复盘一次异常件归因、更新一次物流商评分。这三件事加起来每月不超过两天工时，但能让流程问题在变成事故之前被看见。
对账口径要白纸黑字写下来，包括计费重规则、附加费清单、汇率折算方式、退件费归属。我见过太多团队每年都在为同样的几个科目吵架，原因就是口径从来没有被正式确认过。
如果按这个节奏推进，90天内可以看到一批指标的系统性变化。下面这张图是我在项目里常用的目标设定方式。
如果物流渠道少于5个、单量在日均千单以下，采购成熟ERP的对接模块通常更划算，因为自研的隐性成本主要在长期维护：物流商改字段、改限流、改计费规则，你需要有人一直跟着。
如果渠道超过10个、存在大量定制路由规则、或者物流本身就是你的核心竞争力，自研才有意义。判断标准是：你的物流策略是否会成为差异化优势？ 如果答案是否定的，不要把研发资源投在这里。
我的建议是分层处理。常规异常（地址格式、面单重打、二次派送）走全自动，因为这些场景的处理逻辑稳定、可枚举。涉及金额或买家体验的异常（理赔、退件、清关扣货）必须走人工确认，因为错误成本太高。
判断边界可以简化成一句话：处理错了能不能自动回滚？能就自动，不能就人工。
多平台、多国家、多物流商的覆盖能力是选型的重要维度，但覆盖广度和单点深度往往此消彼长。我见过一套ERP号称支持30个国家，结果每个国家的税务和申报模板都只是通用版本，实际用起来还是靠人工改。
如果年销售额低于一定规模，我倾向于选覆盖3到5个主力市场但每个市场都做得扎实的系统。后期再扩市场时，把新市场当作一次新的对接项目来做，而不是指望一套通用配置跑遍全球。
轨迹事件的实时回传体验更好，但对ERP的状态处理能力要求更高，容易触发乱序和并发冲突。我通常建议对"已揽收""已签收"这两个关键节点做实时处理，其余中间节点走批量同步，每15分钟一次。
这样既保证了买家感知最强的两个节点是准的，又降低了状态机的并发压力。取舍的本质是：不是所有状态都需要实时，只有会触发业务动作的状态才需要。
| 取舍维度 | 自研对接 | 采购标准ERP | 混合方案 |
|---|---|---|---|
| 首年建设成本 | 高，需2到4人半年 | 低，以订阅费为主 | 中，核心自研加外围采购 |
| 上线周期 | 4到8个月 | 1到3个月 | 3到6个月 |
| 流程可控性 | 最高，可深度定制 | 受限，只能适应标准流程 | 较高，关键环节可控 |
| 对账能力 | 取决于自建质量 | 依赖供应商roadmap | 可自建对账层补齐 |
| 长期维护成本 | 高，需持续投入 | 低，由供应商承担 | 中 |
| 适用场景 | 渠道多、策略差异化强 | 渠道少、单量中等 | 多渠道但研发资源有限 |
物流对接不是一项技术工作，而是一次流程设计的压力测试。它用一根链路同时压住订单、库存、仓储、财务、客服五个模块，任何一处偷懒都会留下痕迹。你不需要看懂代码，只需要看四本账对不对得上、异常件有没有闭环、对账差异能不能归因。
这套方法最反常识的地方在于：它不追求把系统测得多完美，而是追求把问题暴露得足够早。一个在沙箱里就能暴露幂等缺陷的系统，比一个在双十一当天才暴露的系统，价值高出一百倍。
如果你只有半天时间，我建议你做这件事：找一条最近出问题的物流订单，把它从下单到签收的每一个状态变更、每一次接口调用、每一笔费用记录全部拉出来，画在一条时间线上。
你会在这条线上看到两样东西：系统的实际行为，和你以为的系统行为。这两者之间的差距，就是你这套ERP流程设计需要补的地方。这个方法不需要任何工具，但比任何一份功能清单都有用。
我们公司去年换ERP，供应商演示的时候接口都通，我也就没多想。结果上个月大促爆单，取号超时把库存锁死了两百多单，客服被投诉到爆，我才意识到自己根本没做过流程层面的评估。现在想补一次系统性的检查，但不知道从哪里下手。
先画链路再谈检查，顺序是审单、拆合单、仓库分配、渠道选择、取号、面单与申报、预报交运、轨迹回传、异常件、签收、退换货、对账，一共十二个节点，每个节点都要能回答三个问题：失败了会不会丢单、失败后谁负责、失败后多久能被发现。三个问题里有一个答不上来，这个节点的流程设计就是不合格的。
资料准备只要四份：物流商开放平台的接口文档和限流规则、你们自己的业务SOP、近三个月异常件工单导出、对账规则表。有了这四份，评估就不靠感觉了。
然后按沙箱跑正常单和边界单、灰度放真实订单、再做限流和超时演练三轮走完，最后按影响面乘发生概率乘可修复性排整改优先级，先修会丢单的，再修会算错钱的，最后修体验问题。
我们运维每周给我一张报表，接口成功率99.6%，看着挺漂亮，但仓库天天喊缺面单、财务天天喊对不上账。我一度怀疑是报表口径有问题，可又说不清楚该看什么，业务和技术互相甩锅。
不够，接口成功率是调用维度的，会掩盖订单维度的长尾问题。建议至少同时看五个指标，并且明确区分调用维度和订单维度。一是一次取号成功率，口径是首次调用成功且无需人工干预的订单数除以总取号订单数，这个数通常会明显低于接口成功率。二是P95响应时延，平均值没有意义，卡顿都发生在尾部。
三是轨迹完整率，口径是签收件中关键节点齐全的件数除以签收件总数，关键节点由你们自己定义，比如揽收、离港、清关放行、派送、签收五个。四是异常闭环率，从异常被识别到状态被更新或理赔结案的完成比例。五是对账差异率，差异金额除以账单总金额，且必须能追溯到具体单据。
另外设两个硬阈值当告警线：取号超过三十分钟未成功直接告警，物流状态回传超过二十四小时无更新直接进人工核查队列。指标口径一旦定下来就写进周报，别每次换一种算法，否则趋势没法比。
我们同时跑五家物流商、七个店铺，不同国家走的渠道还不一样。上次出现一个订单明明已经签收，ERP里还显示运输中，客服照着系统话术去催件，被买家截图挂到评价区，特别尴尬。我想知道这种状态不一致到底该怎么测出来。
分两步，先看路由是不是配置化，再看状态机是不是双向一致。路由这块，检查能不能按国家、重量段、时效等级、成本上限、店铺白名单这些维度组合出规则，能不能在不改代码的前提下调整优先级，能不能对某个渠道临时熔断。如果一个渠道出问题要发版才能切走，那就是流程设计问题而不是运维问题。
状态一致性这块，重点是回传事件的处理逻辑，核心要求是幂等加不允许回退。测试手法很土但很有效：把同一条轨迹事件重复回传五次、把事件顺序打乱回传、把字段故意留空、把中间节点跳过只回传签收，看系统会不会重复扣库存、会不会把已签收的订单退回运输中。
幂等键建议至少包含店铺、订单号、物流单号、事件类型和事件版本，缺一个都可能出问题。再补一条兜底规则：任何订单的物流状态超过设定时长没有推进，必须自动进异常看板并指派到人，而不是等客服自己去发现。
我最怕的就是异常件，出了事全靠群里吼，谁看到谁处理。退货更乱，退回的货有时候进了库存有时候没进，退款金额也各说各话。到了月底对账，财务拿物流商账单跟系统比，差个几千块只能认了。我想知道这三块有没有可执行的检查办法。
把这三块当成同一条闭环来查，不要分开看。异常件检查四点：是否能自动识别并分类、是否自动分派到责任人、是否有处理时限SLA、处理结果是否回写订单状态，四条缺一条就不算闭环。
逆向物流检查退货单能不能从买家申请一路串到入库和退款，重点看退回地址规则、退款触发条件、库存回补时点、理赔流程是不是在同一套系统里，如果退货走线下表格，那库存和财务一定对不上。对账用四账一致来验：订单账、物流商账单、库存账、财务账，四本账在同一个订单号下能对上。
核对时优先查最容易出错的四类费用：计费重与体积重的取值口径、燃油附加费、偏远地区附加费、退件费，这几项差异通常占总差异的大头。给个可执行的判断依据：凡是还需要人工拉Excel核对的环节，就认定为流程设计缺陷，先把它写进整改清单，再定月度对账差异率目标并逐月追踪。
差异不能只记录金额，必须能追溯到具体单据和原因分类，否则下个月还会差同样的钱。
读者评论
文章把接口成功率99.8%和异常闭环率31%放在一起对比，这个角度很扎心。我们公司验收ERP时就卡在连通率上，大促照样爆仓，现在回头看确实是只测了正常路径。
取号幂等那段代码写得挺实在，但中小卖家未必有Redis和补偿队列的资源。更现实的做法可能是先在上线前压测重复请求，看系统会不会重复取号，成本低很多。
四账对账那张表可以直接拿来做验收清单。我们去年就是物流账对不上，查了半个月才发现是体积重和实重取大者的口径没建模，跟文里说的一模一样。
轨迹完整率低于90%就判定状态机不健壮，这个阈值是不是有点绝对？东南亚部分小物流商本身就回传不全，可能得先分物流商看基线，再判断是ERP的问题还是数据源的问题。