The Hudson Bay EDI 对接指南：零售商供应商电子数据交换全解析

The Hudson Bay 公司简介

The Hudson Bay（哈德逊湾公司）是北美历史最悠久的商业企业之一，总部位于加拿大，现为一家综合性零售控股集团，运营涵盖百货零售、电商及奢侈品卖场等多元业态。作为加拿大零售行业的重要参与者，The Hudson Bay 与全球数千家供应商保持着紧密的采购与供应链协作关系。随着零售业务数字化转型的深入，传统邮件、传真及人工录入的订单处理方式已无法满足高频、大批量的业务需求。通过 EDI（电子数据交换）与 The Hudson Bay 实现系统直连，供应商能够自动化处理采购订单、发货通知及汇款通知等核心业务单据，显著提升订单响应速度、降低人工差错率，并确保供应链数据的一致性与可追溯性。对于希望进入或深化与 The Hudson Bay 合作的供应商而言，建立稳定、合规的 EDI 连接已成为业务准入与持续运营的关键基础设施。

The Hudson Bay EDI 技术架构概览

The Hudson Bay 采用 ANSI X12 报文标准作为其 EDI 技术架构的核心规范，要求供应商具备完整的 X12 报文收发与解析能力。以下是与 The Hudson Bay 进行 EDI 对接所涉及的主要业务报文及其功能说明：

850 Purchase Order (PO)（采购订单）：作为 EDI 对接中最核心的 inbound 报文，850 承载了 The Hudson Bay 向供应商发出的正式采购指令。关键字段包括：

• PO1（订单行项目明细，含物料编号、数量）
• N1（名称与地址，标识收货方及账单方），HBC 850 报文通常包含两个 N1 循环：第一个用于 Ship-To（收货方），其 N104 包含 4 位数的仓库（DC）或门店代码；第二个用于标识 Consolidator（集运商）。如果是直接送货到门店（DTS），N104 会显示为 ’9999′
• DTM（请求交货日期），HBC 规范中会发送两个 DTM 段来定义交货窗口：限定符 ’064′ 表示“最早交付日期（Do Not Deliver Before）”，限定符 ’063′ 表示“最晚交付日期/取消日期（Do Not Deliver After）”
• BEG （报文开始）：订单的基础身份
  • BEG01：订单类型。’00′ 表示原始订单（Original），’06′ 表示确认订单（Confirmation）。
  • BEG03：PO 编号。常规商品为 11 位，大件商品（Big Ticket）为 7 位。
  • BEG05：订货日期。
• SDQ（目的地数量分配），如果一个 PO 包含多个门店的货量，HBC 会使用 SDQ 段。它可以在同一个行项目下，列出最多 10 个不同的门店及其对应的订单数量。供应商需根据此段进行店分（Pre-distribution）打包。

供应商系统需具备实时接收与解析 850 的能力，以确保订单及时进入 ERP 或 WMS 系统。

860 PO Change (Buyer)（采购订单变更）：当 The Hudson Bay 需要修改已下达订单的数量、交期或收货地址时，将通过 860 发送变更请求。关键字段包括：

• 变更的范围与颗粒度
  • 头部变更 vs. 行变更： 如果 860 报文中没有发送行明细（Line Detail），这通常表示商品项没有变化，仅是订单头部的段落（如 DTM 中的日期）发生了变更。
  • 价格调整： 除了数量和日期，860 还会用于修改商品的成本价（Cost）零售价（Retail），相关信息承载于 CTP 段。
• 复杂的收货地址变更（Ship-to Changes）
  • DC 转 DTS： 如果收货方从配送中心（DC）变更为直接送货至门店（DTS），HBC 通常会发送一个 860 报文取消原始订单，随后发送一个新的 850 订单请求 DTS。
  • 分仓拆单（Depot Split）： 对于大型订单，如果 HBC 决定将货物分散配送至多个地点，会发送 860 减少原始订单的数量，并针对不同地点发送多个新的 PO。
• 业务强制性要求与风险规避
  • 无法执行变更的处理： 如果供应商接收到 860 但因生产或物流状态无法执行变更，必须立即联系 HBC 供应链团队讨论，并将 PO 恢复至之前的版本。
  • ASN 匹配风险： 供应商必须确保最终发送的 ASN (856) 报文与 860 变更后的最新 PO 信息完全一致。如果未完成系统同步就发送 ASN，该报文极大概率会被 HBC 系统拒收（Rejected）。

供应商需具备解析 860 并自动触发内部订单变更流程的能力，解析 860 时，应优先检查 BCH01 确定是取消还是变更，随后对比 DTM 日期和 POC 行项目差异，并在发货前确保 WMS 系统已同步最新的变更指令。

855 PO Acknowledgment（采购订单确认）：供应商在收到 850 后，需通过 855 向 The Hudson Bay 确认订单接受、拒绝或修改状态。关键字段包括：

• AK1（确认标识）：AK1 通常出现在 997（业务确认）报文中用于确认收到数据。在 855 中，BAK01 使用代码 ’16′ 表示“建议订单（Proposed Order）”，BAK02 使用 ‘AP’ 表示“产品补货（Product Replenishment）”。
• PO1（订单行项目确认）： HBC 要求 PO1 中必须包含：PO101（11 位行标识）、PO102（订购数量）、PO106/107（UPC 或 EAN 编码）此外，还需提供买方的款式编号（Style）、尺寸代码（Size）和颜色代码（Color）
• DTM（日期参考）：在 855 报文中，DTM 段用于传达请求发货日期（Requested Ship Date），限定符 DTM01 为 ’010′。
• SDQ（门店分配明细）：HBC 的 855 报文结构包含 SDQ 段，且在细节层级是强制性（Mandatory）的。供应商必须通过 SDQ 段确认每个门店的具体分配数量，每个 SDQ 段最多可指定 10 个门店及其对应数量。

856 Shipping Notice (ASN)（发货通知/提前装运通知）：供应商完成备货与发运后，通过 856 向 The Hudson Bay 发送货物明细及物流追踪信息。关键字段包括：

• HL（层级结构，标识订单-包装-物料层级关系）：HBC 的 ASN 采用多级嵌套结构：Shipment (S) -> Order (O) -> Tare (T) -> Pack (P) -> Item (I)，装运级（S）和订单级（O）是强制性的。对于托盘运输，Tare（托盘级）和 Pack（包装级）也是强制性的，必须包含各自的 UCC128 标识。
• TD1（运输详情，包装类型，装运数量）
• REF（提单号）：如果一辆货车装载了多个 ASN，则必须发送第二个 REF 段（REF01=MB）来标识主提单号（Master Bill of Lading）
• DTM（实际发货日期）：HBC 使用限定符 ’011′
• 托盘 ASN 的强制要求 (Pallet ASN)
  • HBC 现在要求托盘 ASN 必须同时包含 Tare（托盘）和 Pack（纸箱）层级。
  • 这意味着托盘 ASN 必须针对每个托盘级和每个纸箱级都提供对应的 UCC128 ID（SSCC 码）。
  • 每个托盘和纸箱上的物理标签必须与 ASN 报文中的数据完全对应
  • 准确的 ASN 数据是 The Hudson Bay 仓库实现越库作业（Cross-docking）与自动收货的前提。
• BSN 段：装运标识的限制
  • BSN02（装运标识号）： 必须是唯一的。
  • 特殊限制： 装运 ID 不得以字母“A”、“C”、“D”或“Z”开头，因为这些字母在 HBC 的应付账款系统中具有特殊含义。
  • BSN05： HBC 使用代码 ’0001′ 标识“拣货与包装（Pick & Pack）”结构。

注意：标签一致性： ASN 发送的时间必须在货物到达 DC 之前。如果 ASN 数据与物理纸箱上的 UCC-128 标签（Zone H 部分）不符，将导致收货失败。

820 Remittance Advice（汇款通知）：该报文用于 The Hudson Bay 向供应商传递付款信息，明确汇款金额、付款日期及对应发票的扣减明细。关键字段包括：

• BPR Begin Payment Remittance，标识付款方式与金额：如 BPR04 为 ‘CHK’ 表示支票，实际生效日期/付款日期（BPR16，格式为 ccyymmdd）
• REF 参考编号，在报文头用于标识付款人的追踪编号（如支票号或电子传送号）；在细节层级（Detail Area）用于标识相关的 PO 编号（REF01=PO）或 ASN 编号（REF01=SI）
• DTM（日期/时间参考，存放实际付款日期或预计到账日期）。供应商需准确解析该报文以完成财务对账。
• RMR 发票与金额匹配的核心，用于传达未结清项目或帐面付款信息
  • 参考关联： RMR02 的参考编号会匹配对应 ASN 上的供应商参考号，如果没有，则匹配 ASN 编号
  • 金额差异（含税处理）：RMR04： 该特定订单的实付金额，包含销售税（GST）；RMR05： 供应商声称的装运金额，不包含 GST。如果两者存在差异，通常预示着存在争议或扣款。
  • 折扣： RMR06 标识所提取的折扣金额（仅限常规商品）
• ADX 解析扣减扣款（Adjustment），调整原因代码 (ADX02)： 常见代码包括：
  • ‘BA’, ‘BB’, ‘BC’： 分别代表加拿大 GST、魁北克 QST 和调和税 HST。
  • ‘L2′： 折扣（Discount）。
  • ‘L3′： 费用或罚款（Charges or Penalty）。
  • ‘L7′： 贷记（Credit），例如 ASN 上的数量多于实际到货数量。
  • ‘L8′： 借记（Debit），例如 ASN 上的数量少于实际到货数量。

建议：在对账时，务必将 RMR04（实付金额）与对应的 PO 及 ASN 进行三单匹配，并重点通过 ADX02 代码解析所有非全额付款的原因。

997 FA 功能性确认（Functional Acknowledgment）：作为 X12 标准的底层控制报文，997 用于确认收到报文的语法合规性。The Hudson Bay 要求供应商具备双向收发 997 的能力，即收到任意报文后立即回复 997，同时对接收自 The Hudson Bay 的 997 进行监控，以确保传输链路的可靠性。

The Hudson Bay EDI 对接流程

阶段一：获取 EDI 相关资料，梳理 EDI 需求

供应商需首先与 The Hudson Bay 的 EDI 团队建立联系，确认本次项目使用的传输协议（通常为 AS2）、报文标准版本（X12）、需要传输的单据类型及方向，并索取 The Hudson Bay 最新的 EDI 规范文件（Implementation Guide）。该规范文件详细定义了各报文的 segment 使用规则、必填字段、代码集取值及业务校验逻辑，是后续系统配置的唯一权威依据。

阶段二：EDI 连接配置

The Hudson Bay 的 EDI 团队将通过邮件向供应商提供其 AS2 连接参数，包括 AS2 ID、接收 URL、签名证书、加密算法要求及 MDN（Message Disposition Notification）回执配置。供应商需同步提供自身的 AS2 连接信息，知行软件的 EDI 顾问将协助用户完成证书交换、防火墙白名单配置及 AS2 连通性预检。

阶段三：联通性与报文测试

• 连接测试：验证双方 AS2 传输通道的可用性，确保测试文件能够成功发送、接收并返回有效的 MDN 回执。
• 结构测试：供应商需成功解析 The Hudson Bay 发来的 850、860、820 报文，并生成符合规范的 855、856 报文。同时，必须验证 997 功能性确认的自动收发逻辑，确保每份业务报文均触发对应的 997 响应。

如何基于知行之桥 EDI 系统实现 The Hudson Bay 的 EDI 对接需求？

知行之桥 EDI 系统是知行软件自主研发的本地化部署型数据交换平台，专为解决企业间 B2B 电子数据交换的复杂性而设计。针对与 The Hudson Bay 这类大型零售商的 EDI 对接场景，知行之桥有效解决了传统对接方式中协议配置繁琐、报文格式转换困难、人工处理易出错及缺乏可视化监控等痛点。系统支持在浏览器中直接访问，提供美观易用且功能丰富的 Web 管理界面，用户可实时查看报文流转状态、端口运行日志及数据映射结果。作为一款低代码、高可视化程度的 EDI 系统，知行之桥通过拖拽式流程设计器即可搭建完整的 EDI 工作流，大幅降低技术门槛与实施周期。

部署 EDI 系统须知

搭建 The Hudson Bay EDI 对接工作流时，需在知行之桥中配置收发双向的数据处理链路。以下为基于知行之桥的标准对接方案：

接收流程（The Hudson Bay → 供应商）

1. AS2 端口：配置 The Hudson Bay 提供的 AS2 ID、URL、公钥证书及加密参数，建立安全传输通道，实时接收来自 The Hudson Bay 的 850、860、820 及 997 报文。
2. X12 解析端口：将接收到的标准 X12 报文解析为系统内部的 XML 标准格式，自动处理 segment 分隔符、元素分隔符及换行规则，确保数据结构标准化。
3. XMLMap 端口：执行报文映射逻辑，通过可视化映射编辑器将 X12 XML 中的业务字段（如 PO1、N1、DTM 等）转换为目标 XML 格式，匹配供应商后端系统的数据 schema。
4. JSON 端口：将目标 XML 文件转换为 JSON 格式，便于通过 REST API 与 ERP、WMS 或中台系统实现无缝对接。

发送流程（供应商 → The Hudson Bay）

1. JSON 端口：接收来自 ERP 系统的 JSON 格式出库及订单确认数据，作为 outbound 流程的数据源入口。
2. XMLMap 端口：将业务数据映射为 855、856 报文所需的 XML 结构，依据 The Hudson Bay 的 EDI 规范配置字段映射关系、代码集转换及业务校验规则。
3. X12 端口：将 XML 转换为符合 ANSI X12 标准的 EDI 报文，自动添加 ISA/GE 信封头、控制编号及 segment 终止符。
4. AS2 发送端口：通过 AS2 协议将 855、856 报文发送至 The Hudson Bay 指定接收地址，等待 The Hudson Bay EDI 团队及业务部门完成语法与业务内容验证。

说明：知行之桥中的端口（Port）可理解为功能模块，每个端口负责特定的数据处理任务（如接收、解析、映射、转换等）。通过可视化连线配置即可实现 997 自动回复流转逻辑，无需消耗额外端口资源，系统会在接收到业务报文后自动触发对应的 997 功能性确认。

为什么选择知行之桥 EDI 系统？

知行之桥 EDI 系统作为一款本地部署、低代码、可试用的 EDI 软件，其核心优势在于完全自主知识产权的中文界面、丰富的预置端口库以及高度灵活的集成能力。系统支持 70 余种基于真实项目的开源工作流模板，用户可一键导入并复用，显著缩短项目启动周期。知行之桥提供基于浏览器的管理界面，支持 PC、平板及移动端访问，可实时监控数据流状态及端口运行日志，满足企业 IT 运维的可视化需求。

对于没有本地部署需求或希望快速上线的中小型供应商，知行软件还提供 知行之云 LIP 系统，一套基于 SaaS 模式的 Web EDI 解决方案，同样支持试用。知行之云通过网页表单、邮件通知及 SFTP 文件传输等方式降低操作门槛，业务人员无需具备专业技术背景即可完成 EDI 报文的录入与发送。

以下是两种方案的对比：

维度	知行之云 LIP (SaaS)	知行之桥 (本地部署/集成)
适用对象	中小型供应商、业务人员直接操作	中大型企业、追求高度自动化的用户
部署方式	网页登录（无服务器需求）	部署在用户私有服务器（本地/云端）
集成能力	网页可视化操作 / 手动录入	自动集成 SAP、Oracle、用友、金蝶等
对接方式	门户化管理	中间数据库、API、WebService、CSV
实施周期	3-7 天	2-8 周

总结与行动建议

与 The Hudson Bay 建立 EDI 连接是供应商融入其数字化供应链体系的必要步骤。为确保项目顺利推进，建议供应商按以下路径行动：

1. 寻找专业的 EDI 供应商，如知行软件，获取具备 X12 标准支持及 AS2 传输能力的技术平台与实施服务。
2. 联系 The Hudson Bay EDI 团队，确认具体的报文需求清单、传输协议细节，并索取最新的 EDI 连接参数及规范文档（Implementation Guide）。
3. 启动知行之桥试用或知行之云评估，结合企业 IT 基础与业务规模选择最合适的部署方案，在正式生产环境上线前完成完整的连接测试与报文验证。

知行软件成立于 2008 年，深耕 EDI 领域十余年，已成功协助众多零售、汽车及制造行业企业完成与大型 Trading Partner 的 EDI 对接。如需进一步了解 The Hudson Bay EDI 对接的技术细节或申请产品试用，请联系我们的 EDI 顾问团队。

了解更多 EDI 信息，请参阅: EDI 是什么？

注：文案部分图片及内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。