
在常见的采购业务中,供应商会接收 EDI 850 采购订单,再向采购方发送 EDI 856 发货通知和 EDI 810 发票。
但产品交给经销商或零售商后,品牌商还会关心 POS(Point of Sale,销售终端)环节产生的实际销售和退货数据,以及产品在渠道中的后续流向:
这些信息可以通过 EDI X12 867 传递。销售、退货等业务数据通常来自 POS、ERP、订单系统、库存系统或经销商的其他业务系统,再通过 EDI 867 按照双方约定的格式,定期发送给品牌商或制造商。
EDI X12 867 的全称是 Product Transfer and Resale Report,中文通常称为“产品转移与转售报告”。
它主要用来报告:
在常见的渠道销售业务中,867 通常由经销商、分销商或零售商发送给品牌商或制造商。
可以简单理解为:
EDI 850 告诉供应商“我要买什么”,EDI 867 告诉品牌商“这些产品后来卖到了哪里、卖了多少、退了多少”。
经销商或零售商从品牌商采购产品后,再通过门店、柜台或其他销售终端将产品卖给客户。相关交易通常先记录在 POS 系统中,包括销售时间、门店、商品、数量、金额和退货等信息。品牌商只看原始采购订单,无法了解这些实际销售结果。
经销商或零售商可以从 POS 系统提取相关数据,经过汇总和格式转换后定期发送 867,上报:
品牌商可以根据这些 POS 销售数据了解各地区、门店和客户的实际销售情况,并用于渠道分析、返利核算和补货预测。
这是 867 的典型应用之一。
例如,某产品的经销商采购价是 100 元。为了拿下指定客户,品牌商批准经销商按 80 元销售。经销商完成销售后,通过 867 上报客户、产品和实际销售数量。品牌商审核后,再补偿每件 20 元的差价。
在部分实施指南中,可以使用以下 PTD 段表示 Ship and Debit 销售:
PTD*SD~这里的 SD 表示 Ship and Debit Sale。
需要注意:867 主要用于上报销售事实和数量,并不是价格调整单。如果需要修改价格或处理借记、贷记,应按照双方约定使用 810、812 等合适的报文。
同一个报告周期内,可能同时存在发货、销售和退货数据。867 可以使用不同的数量代码分别上报,但发货数量不等同于终端销售数量,具体代码必须与实际业务含义一致。
例如,某交易伙伴的实施指南可能使用:
QTY*39*100*EA~
QTY*76*5*EA~39:Shipped Quantity,发货数量;76:Returns,退货数量;100 和 5:实际数量;EA:计量单位,表示“件”。这组数据表示发货 100 件、退货 5 件。如果双方约定退货数量可以在同一报告周期内从发货数量中扣减,业务系统可以计算出净数量为 95 件;否则应分别记录和处理,不能直接相减。
不同交易伙伴对数量代码的要求可能不同,实际项目必须以对方提供的 867 实施指南为准。
产品从一个仓库调拨到另一个仓库,或者从配送中心转移到门店时,也可以通过 867 上报:
这样,品牌商不仅能看到最初的出货记录,也能了解产品在渠道中的后续流向。
品牌商可以汇总不同经销商和门店发送的 867 数据,用于:
一份 867 通常包括三部分:
部分 | 主要内容 | 常见段 |
|---|---|---|
头部 | 报告编号、报告日期、交易双方 | ST、BPT、DTM、REF、N1 |
明细 | 客户或地点、产品、数量、单位、金额 | PTD、N1、QTY、LIN、UIT、AMT、PID、REF、DTM |
汇总 | 明细数量、汇总金额、报文结束信息 | CTT、AMT、SE |
不同交易伙伴和 X12 版本的要求可能不同。哪些字段必填、使用什么代码、每个段可以出现几次,都要以交易伙伴提供的实施指南为准。
ST*867*0001~867:表示这是一份产品转移与转售报告;0001:交易集控制号,需要与 SE 段中的控制号保持一致。BPT 是 867 的头部核心段,通常用来说明:
DTM 可以表示报告开始日期、结束日期、销售日期、发货日期或退货日期。
DTM 中的日期代码决定了这个日期的具体含义,因此不能只看日期值。实际使用什么代码,应以交易伙伴实施指南为准。
这些段用来标识业务中的参与方和地址,例如:
PTD 表示一组产品转移或转售数据的开始。一个 867 中可以有多个 PTD 循环,用来报告不同客户、地点或业务类型的数据。
QTY 用来传递发货、销售、退货或转移数量。
同一个 PTD 循环中可以出现多组 QTY,用来上报不同产品或不同类型的数量。
LIN 用来标识具体产品,可以传递:
双方需要提前确认使用哪一种产品编号作为匹配依据,否则可能出现产品无法识别、销售数据无法入账的问题。
UIT 可以传递计量单位和单价等信息。
例如,经销商按“箱”销售,但品牌商按“件”管理时,双方必须提前确认一箱有多少件,避免销售数量或返利金额计算错误。
AMT 可以传递销售金额或汇总金额。金额是否必填、是否含税、使用什么币种,都要以交易伙伴的要求为准。
REF 可以传递:
在 Ship and Debit 业务中,授权号非常重要。品牌商可以用它确认这笔销售是否符合已经批准的特价政策。
PID 可以补充产品名称、规格或描述。系统通常仍应使用 LIN 中的产品编号进行匹配,PID 更适合人工查看和排查问题。
CTT:通常用于记录明细数量;SE:表示交易集结束,并记录段数量和交易集控制号。SE 中的控制号必须与 ST 一致,段数量也必须正确。
下面的示例以 Ship and Debit 业务为例,上报经销商的发货和退货数量,用于帮助理解 867 的基本结构,并非通用的 POS 销售数量示例。该示例不能直接用于实际项目,真实项目必须按照交易伙伴的 X12 版本和实施指南调整。
ST*867*0001~
BPT*00*RPT20260810*20260810*SS~
N1*SU*BRAND COMPANY*92*SUP001~
PTD*SD~
N1*ST*END CUSTOMER*92*CUST001~
QTY*39*100*EA~
LIN**VP*ITEM001*UP*123456789012~
UIT*EA~
QTY*76*5*EA~
LIN**VP*ITEM001*UP*123456789012~
UIT*EA~
CTT*2~
SE*13*0001~这份示例表示:
RPT20260810;CUST001;ITEM001;示例中的 00、SS、SD、39、76、SU、ST、92、VP 和 UP 都是 X12 代码。实际项目不能直接照搬,必须先确认交易伙伴是否接受这些代码。
需要先确认是每笔销售发送,还是按日、周或月汇总发送。
需要确认是按客户、门店、仓库、地区还是产品汇总。
退货可能使用独立的数量代码、负数数量或单独的 PTD 类型。必须按交易伙伴的要求处理。
双方要确认使用供应商料号、客户料号还是 UPC/GTIN,并提前建立产品编号对应关系。
需要确认 EA(件)、CA(箱)、PK(包)等单位,以及不同包装之间如何换算。
系统可以根据报告编号、销售单号、日期、客户和产品等信息检查重复数据,避免重复计算销售数量或返利。
建议至少检查:
报文 | 主要用途 | 与 867 的区别 |
|---|---|---|
850 | 采购订单 | 说明需要采购什么,不是终端销售报告 |
846 | 库存查询或通知 | 重点报告库存,867 重点报告产品转移和销售 |
856 | 提前发货通知 | 说明一批货如何发运,867 说明产品后续如何转移或销售 |
810 | 发票 | 用于开票和结算,867 主要提供销售或转移数据 |
812 | 借记或贷记调整 | 用于财务调整,867 不能直接代替价格调整报文 |
EDI X12 867 用来连接“上游出货”和“下游 POS 实际销售”。POS 系统记录门店或经销商发生的销售与退货,EDI 867 负责将这些数据按照约定格式传递给品牌商。品牌商由此可以了解产品卖到了哪里、卖了多少、退了多少,以及产品在不同地点之间如何转移。
实施 867 时,最重要的不是简单完成格式转换,而是先把业务规则说清楚:
这些规则明确后,867 才能稳定进入自动化处理流程。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。