结论先行：
1. 
“报关字段”必须同时在订单（OMS/WMS）和物流系统里各存一份，但两份数据的定位、粒度、维护人不同；
2. 
订单/WMS 侧存的是“商品级主数据”，物流系统存的是“一次发运级的申报快照”；
3. 
不能只做在物流系统，否则无法提前做三单对碰、库存分配、合规校验，也无法支持换物流商重新申报。
下面给出可落地的分工与字段清单，方便你直接对照设计表结构。
一、三套系统各自存什么
表格
系统
存储目的
关键报关字段（示例）
维护方
生命周期
订单 OMS
① 交易合法性校验（三单对碰）② 商品主数据沉淀，后续任何物流渠道都可复用
商品名称、HS Code、品牌、型号、材质、申报单价、币种、原产国、销售链接、电商企业代码、订购人姓名/证件号
商品/运营
与 SKU 绑定，长期有效
仓储 WMS
① 出库环节能快速生成“核注清单”② 支持保税/非保库存区分
在 OMS 字段基础上，加：账册号、批次号、库位、是否保税、数量（实发）、毛重、净重、体积
仓库
与出库单同生命周期
物流 TMS
① 生成给船公司/快递/报关行的“申报快照”② 支持改单、换渠道重新申报
发运单号、总件数、总毛重、总净重、包装种类、运输工具、提运单号、运费、保费、成交方式、发货人/收货人地址、随附单据
物流/货代
与运单同生命周期，可多次版本
二、为什么订单/WMS 必须存
1. 
三单对碰：海关先收到“订单报文”，再比对支付单、运单。如果订单系统里没有报关字段，就无法提前推送，只能等物流商回传，延迟放行 [^0^]。
2. 
换物流商：A 渠道查验不过，需要换 B 渠道重新申报，此时若原始商品数据只在 A 的系统，则无法快速生成新申报文件 [^2^]。
3. 
库存合规：保税仓必须按“账册+HS+原产国”管理库存，出库即核注，WMS 没有字段就无法生成核注清单 [^4^]。
三、字段落地示例（可直接建表）
1. 
订单商品表 oms_order_item
sku_id, customs_name, hs_code, brand, model, declare_unit_price, currency, country_of_origin, seller_customs_code
2. 
仓库出库明细表 wms_outbound_item
outbound_no, sku_id, batch_no, hs_code, bonded_flag, account_book_no, qty, gross_weight, net_weight, volume
3. 
物流运单表 tms_shipment
shipment_no, waybill_no, total_packages, total_gross_wt, total_net_wt, freight, insurance, delivery_terms, exporter, importer, shipping_mark, attachment_list
四、协作流程
1. 
商品上架时，运营在 OMS 填/导一次报关主数据 → 长期有效。
2. 
订单生成后，OMS 把商品级报关数据下传给 WMS。
3. 
WMS 出库时，按实际拣货数量生成“核注清单”推海关，同时把“发货快照”回传 OMS。
4. 
OMS 把订单+支付单+运单三单推送海关，完成三单对碰 [^5^]。
5. 
若物流商需要特殊格式，TMS 再从 OMS/WMS 拉取主数据，按渠道模板生成“申报快照”，不影响原数据。
五、常见误区
× “让物流商自己维护报关资料，我们什么都不存”
→ 一旦换物流商、一单多箱、或遇到查验改单，需要重新提供商品资料，来回沟通至少 4-8 小时，延误船期 [^7^]。
× “只在 ERP 存一份，物流系统实时调接口拿”
→ 海关申报时要求“单证一致”，物流商必须本地留痕；实时接口一抖，资料对不上直接退单 [^9^]。
一句话总结
订单/仓储系统存“商品级主数据”，物流系统存“发运级申报快照”，两边缺一不可，才能既合规又高效。

SELECT DISTINCT
	t2.shipment_id 货件号,
	t5.sku_id,
	t5.sku_code,
	t5.sku_name,
	t5.size,
	t5.weight,
	t6.spu_name 
FROM
	ec_lingxing_amazon_shipment t2
	INNER JOIN ec_lingxing_amazon_shipment_item t3 ON t3.main_id = t2.id
	INNER JOIN ec_bd_listing t4 ON t4.sid = t3.sid 
	AND t4.seller_sku = t3.msku 
	AND t4.fnsku = t3.fnsku
	INNER JOIN bd_product_sku t5 ON t5.sku_id = t4.sku_id
	LEFT
	JOIN bd_product_spu t6 ON t6.deleted = 0 
	AND t6.spu_id = t5.spu_id 
WHERE
	t2.shipment_id = 'FBA1957JTN9Y'
	
	
	
	
	
	SELECT DISTINCT
	t2.shipment_id 货件号,
	t5.sku_id,
	t5.sku_code,
	t5.sku_name,
	t5.size,
	t5.weight,
	t6.spu_name
FROM
	ec_lingxing_amazon_shipment t2
	INNER JOIN ec_lingxing_amazon_shipment_item t3 ON t3.main_id = t2.id
	INNER JOIN ec_lx_amz_sta_shipment elass ON t2.shipment_id = elass.shipment_confirmation_id
	INNER JOIN ec_lx_amz_sta_item_pair pair ON elass.sid = pair.sid 
	AND elass.inbound_plan_id = pair.inbound_plan_id
	LEFT JOIN bd_product_sku t5 ON t5.deleted = 0 
	AND t5.sku_id = pair.sku_id 
	LEFT JOIN bd_product_spu t6 ON t6.deleted = 0 
	AND t6.spu_id = t5.spu_id 
	WHERE t2.shipment_id = 'FBA1957JTN9Y'    这两SQL有什么区别

两段 SQL 的目标都是“列出同一个货件（FBA1957JTN9Y）里到底有哪些 SKU”，但数据来源、关联路径、对 SKU 的识别逻辑完全不同——这是它们唯一的、也是根本的区别。
1. 
关联路径一句话概括
 
第一段： shipment → shipment_item → listing → sku/spu
“按 FNSKU 找 listing，再反查 SKU”
 
第二段： shipment → lx_amz_sta_shipment → lx_amz_sta_item_pair → sku/spu
“按 STA 计划里的配对关系直接找 SKU”
2. 
差异逐条对照
表格
维度
第一段
第二段
中间桥接表
ec_lingxing_amazon_shipment_item（ shipment_item ）
ec_lx_amz_sta_item_pair（ STA 配对表 ）
SKU 识别键
t4.sku_id（listing 表）
pair.sku_id（配对表）
是否会漏 SKU
如果某 shipment_item 在 listing 表找不到对应 FNSKU，整行丢失
如果 STA 配对表没维护，整行丢失
是否会多 SKU
不会，listing 与 shipment_item 1:1
不会，pair 与 shipment 1:1
依赖前置数据
必须提前把 listing 的 FNSKU 与 SKU 绑定好
必须提前把 STA 计划里的 SKU 配对维护好
典型场景
日常运营以 listing 维度为主，FNSKU 即库存
使用 STA 发货计划，以计划维度为主
3. 
用一句白话翻译
 
第一段： “看亚马逊实际收了多少个 FNSKU，再反查这些 FNSKU 对应什么 SKU。”
 
第二段： “看 STA 计划里本来打算发哪些 SKU，不管实际亚马逊收到啥。”
4. 
你该用哪条？
 
对账“实物 vs 系统” → 用第一段（listing 维度）。
 
对账“计划 vs 实物” → 两段都得跑，再 diff。
 
只想拉“计划发了啥” → 用第二段即可，速度更快（少 join 一层 listing）。

在咱们 ERP/货代语境里，STA 计划 = Send to Amazon 计划，是亚马逊 2024-09-01 起强制使用的全新 FBA 建货流程，俗称“STA 流程”或“STA 计划”。  

一句话：

先建 STA → 亚马逊告诉你分几个仓 → 按仓生成 shipment（货件号）→ 仓库按 shipment 出库。  

所以表里出现的 `ec_lx_amz_sta_shipment`、`ec_lx_amz_sta_item_pair` 就是“STA 计划”对应的头和行，保存的是“亚马逊分仓前的计划维度数据”；而 `ec_lingxing_amazon_shipment` 是“分仓后生成的真实货件维度数据”。