零担资料里的 PRO、提单号和托盘数，应保留各自字段名

收集零担运输资料时，客户发来的“货运号”可能对应不同字段。若把订单、跟踪、提单和承运人编号都收进一个没有说明的文本格，后续核对者即使拿到字符串，也未必知道它应与哪一份记录对应。公开接口文档中的字段结构，能帮助读者看清这种差别。

FedEx Supply Chain 的 Get Order 文档，在履约信息的 trackingDetails 内分别列出 trackNum、billOfLadingNumber 和 carrierProNumber。说明表依次将它们称为履约跟踪号、提单号和承运人 PRO 号；同一层还包含承运人、跟踪链接和发运日期。这里有多个标识，并非同一号码的不同排版。

托盘数则另列为 numberOfPallets，类型是数值，文档释义为订单中的托盘数量。编号负责指向记录，数量负责说明有多少；不能因为看见一个 PRO 字段，就认定只发了一个托盘。反过来，出现两个不同用途的编号，也不是多出了一票货的证据。本文不据这一页面规定所有承运人的编号分配方式。

原页的示例同时给出 numberOfPallets 为1，以及跟踪号、提单号和 PRO 号各自的示例值。它只能演示响应怎样组织，不能证明这些号码在2026年对应真实货物。页面中的历史日期、样例地址与金额也不是本次运输记录，整理资料时不应把示例值复制到实际业务台账里。

一个自拟的交接情境是：甲方发送一串字符并标为“PRO”，乙方回传另一串字符并标为“BOL”。在查清两者所指字段以前，直接把后一串覆盖前一串，可能丢掉原本各有用途的信息。更清楚的摘录是分别保留字段名、原值和所属订单，再说明哪些对应关系已经得到原记录支持。这个情境没有对应实际运输。

还有一层容易忽略：该文档描述的是 FedEx Supply Chain 订单接口，并非对整个零担行业单证规则的统一定义。它提供了“同份履约资料可以并列多个标识”的具体例子，不能据此推断每家货代都使用相同结构，更不能由字符串外观判断编号有效或已经完成交付。

本文于2026年10月12日核读字段表和示例，没有调用账户接口。实用的阅读重点是让字段名跟着数值一起传递：先说明拿到的是什么，再讨论它能与哪项记录对应，而不是把所有号码一律简称为货运号。