先说结论：面单创建只代表系统生成了标签和追踪号，不代表包裹已经交给承运商。 先核对仓库出库记录和交接凭证，再查看承运商官网是否已经出现接收状态，最后才判断是首扫问题还是数据回传问题。
FedEx 说明，标签创建后要等包裹被扫描，追踪页面才会出现实际位置和运输更新；UPS 对 Label Created 的解释也是已收到发件资料，但尚未表示包裹已经进入其网络；USPS 的 Shipping Label Created, USPS Awaiting Item 同样表示标签已经创建、包裹尚未交给 USPS。
先看现象，再决定查哪里
| 看到的现象 | 更可能卡在哪一段 | 先核对什么 |
|---|---|---|
| 单票一直停在预报状态 | 订单映射、作废重打、贴标或单票交接 | 追踪号对应关系、标签版本、条码质量、出库和交接记录 |
| 同一批多票都没有首扫 | 批次出库或交接 | 出库清单、提货时间、交接数量和批次凭证 |
| 仓库记录为已交接，官网仍是预报 | 交接证据与逐票接收之间 | 提货或投递凭证、渠道名称、处理编号和官网当前状态 |
| 承运商官网已有轨迹，仓库系统仍无更新 | 状态轮询、Webhook 或追踪号映射 | 官网轨迹、回传日志、最后同步时间和内部订单号 |
| 官网已经显示在途，只是中间暂时没有新扫描 | 已不是“未首扫”问题 | 按对应承运商的在途轨迹和查询流程处理 |
这张表适合先做分流。单票异常与整批异常通常不是同一种问题；承运商官网已经有轨迹、只有客户系统没有更新时，也不应继续催仓库找“首扫”。
先把四个状态分开
- 面单已生成：系统已经返回面单和追踪号。
- 仓库已出库：包裹完成复核、贴标并离开操作位。
- 仓库记录为已交接：仓库留有提货、投递或批次交接记录，但这仍不自动等于承运商已完成逐票接收扫描。
- 承运商已首扫：官方轨迹明确显示包裹进入承运商或合作网络。
不同承运商的官方入网状态名称不同，例如 FedEx 的 We have your package、UPS 的 Shipped/On the Way、USPS 的 USPS in Possession of Item。应以对应承运商官网的实际轨迹为准，而不是只看仓库系统里的自定义状态。
前两个状态来自仓库或打单系统，第三个状态来自仓库留存的交接记录，第四个状态才由承运商轨迹支持。只看“面单创建成功”，无法判断包裹是否真的完成交货。
单票没有首扫，先查这些
- 内部订单号与追踪号是否对应，面单有没有被作废或重新生成。
- 包裹上的条码是否清晰、平整，是否跨越纸箱接缝或被胶带反光遮挡。
- 标签日期与实际交货安排是否一致。
- 包裹是否混在未交货、错分区或等待复核的货物中。
- 当天是否留有提货单、投递凭证或其他可核对的交接记录。
FedEx 的标签说明建议把面单贴在包裹较大的平面上，避免条码跨过接缝或被胶带覆盖，因为褶皱和反光可能影响扫描。其他渠道也应按对应产品的包装与贴标要求操作。需要从文件格式、纸张比例和打印设备开始排查时，可以使用海外仓面单打印与贴标检查表。
一批货都没有首扫，重点查交接
如果同一批、同一天或同一渠道有多票一起停在预报状态，优先核对批次清单、提货时间、箱数和交接方，而不是逐票重复查询。可以按以下顺序排查：
- 导出当天已生成面单的订单清单。
- 与仓库实际出库清单核对，找出“有面单但未出库”的订单。
- 将已出库订单与提货或投递记录核对，确认交接批次和数量。
- 把仍未首扫的追踪号单独列出，记录渠道、交货时间和当前官方状态。
- 按最终确认的渠道流程提交查询，并保留处理编号和后续结果。
USPS 的 Shipment Received, Package Acceptance Pending 有一个容易误解的地方：它可能表示包含多票包裹的容器或托盘已经到达 USPS 设施，但逐票处理仍未完成。批次已到，不等于每票已经出现独立接收扫描。 如果实际交接方式支持 USPS SCAN Form，可把扫描后的表单作为批次交接记录，但每票轨迹仍要用各自的追踪号核对。
不要为所有渠道设置一个统一的“几小时必须首扫”承诺。提货班次、交货方式、周末和服务产品不同，合理的内部检查时间应根据仓库自己的截单与交接安排设定。
官网有轨迹，系统没有时怎么查
如果承运商官网已经显示接收或在途，而 WMS、ERP 或客户查询页仍停在预报状态，问题通常已经从仓库交接转到数据回传。建议依次核对：
- 内部订单是否绑定了最终使用的追踪号，而不是已作废或重打前的号码。
- 状态轮询任务或 Webhook 是否有报错、超时或签名校验失败。
- 承运商原始状态是否已经保存，系统映射规则是否把新状态错误归到“待揽收”。
- 最后一次成功同步时间是否早于官网首条轨迹。
- 修复后是否只补拉受影响的订单，避免无范围地重复刷新全部数据。
需要从订单映射、幂等和异常日志开始整理时，可以继续查看尾程面单 API 准备清单和表格批量打单与 API 对接。
系统里至少保留哪些记录
- 内部订单号、面单创建时间和追踪号。
- 实际出库时间、操作批次与复核人员或工位。
- 提货、投递或交接时间，以及可核对的批次凭证。
- 首条承运商轨迹出现的时间和状态。
- 面单作废、重打、换渠道及异常处理记录。
表格流程可以增加“出库批次、交接时间、官网首扫状态”三列；API 流程则应让内部订单号、最终追踪号和状态回传能够关联。
可直接复制的排查记录
不要只在群里发一串追踪号。每次异常至少按同一格式保留以下信息，后续才能判断是个别标签、整批交接还是系统回传问题：
内部订单号：
最终追踪号：
承运商与服务名称：
面单创建时间：
仓库出库时间：
交接或投递时间：
交接凭证或批次编号：
官网首条轨迹时间与状态：
仓库系统当前状态：
处理负责人 / 查询编号：内部排查表不需要复制完整收件人姓名、电话和详细街道地址；对外咨询时也不要发送生产系统密钥。
对客户怎么说更准确
仓库可以把通知拆成“面单已生成”“仓库已交货”“承运商已接收”“运输中”，不要在只有电子预报时直接说“承运商已经收件”。这样出现异常时，客户和仓库会在同一个节点上排查，也能减少把交货问题误当成运输延误。
如果想先判断现有流程在哪一段缺少证据，可以查看美国尾程面单服务了解我们通常先核对的资料。需要协助判断一批未首扫订单时，请整理仓库城市、渠道名称、面单创建时间、实际交货时间、受影响票数和交接凭证；首次联系咨询时不要发送真实收件人信息或生产系统密钥。