Bing Lee 公司简介

Bing Lee 是澳大利亚知名的家电及消费电子零售企业，总部位于澳大利亚新南威尔士州 Old Guildford，业务覆盖电视、冰箱、地面清洁电器、小家电等多个品类。对于 Bing Lee 供应商而言，订单接收、交货要求核对、订单回复及回执跟踪都需要较高的数据准确性和响应效率。

通过 EDI 对接 Bing Lee，供应商可以将原本依赖人工处理的业务单据，转为系统间自动传输与处理，减少人工下载订单、手工录入、重复核对及订单回复状态跟进等工作量，降低错单、漏单和沟通成本，提升整体供应链协同效率。

知行软件可基于知行之桥 EDI 系统或知行之云 Web EDI 系统，帮助供应商完成 Bing Lee EDI 通信（本文以 OFTP 为例）、EDIFACT 报文解析、字段映射、格式转换及业务系统集成，快速满足 Bing Lee 的 EDI 对接要求。

Bing Lee EDI 需求概览

Bing Lee EDI 对接主要围绕采购订单接收、订单回复与交换回执跟踪展开，从 Bing Lee 下发采购订单 ORDERS 开始，到供应商核对商品、数量、价格及交货要求，回传 ORDRSP 并跟踪 CONTRL 回执，形成完整的业务闭环。

本次方案暂以 OFTP 演示传输方式，实际协议待确认。已提供的 ORDERS 与 ORDRSP 规范基于 EANCOM 1997／UN/EDIFACT D.96A；CONTRL 的消息头则按其专用规范使用 CONTRL:2:2:UN:EAN002。供应商指南说明，往来 EDI 数据通过 SPS Commerce 处理。按本次项目输入，核心业务单据如下：

在项目启动阶段，建议供应商优先确认 Bing Lee 最新 EDI 规范文件、OFTP 连接参数、每类单据的传输方向、测试场景及上线要求。

采购订单

ORDERS 是 Bing Lee 向供应商发送的采购订单报文，通常包含采购订单号、订单创建时间、供应商代码、GTIN、商品编号、订购数量、未税单价及交货安排等信息。供应商接收 ORDERS 后，需要校验重复订单、核对业务数据，并将订单及分配明细同步到内部系统，作为生成订单回复及安排订单履约的基础。

实施时建议重点关注以下业务字段：

ORDERS 的重点在于区分门店／配送中心交货与客户直送两类场景，保留每个地点和交货批次的信息。实施时应确保原始订单号、行号、GTIN、门店 GLN 及 application reference number 能够在后续 ORDRSP 中正确关联，避免将同一商品在不同门店或不同日期的需求合并，造成交货数量、交期或回复关系错误。

语法与服务报告

CONTRL 是 Bing Lee 向供应商发送的交换级语法与服务回执（本次收方向用于确认 ORDRSP 的接收），通常包含被确认的交换控制号、原始交换发送方／接收方标识以及回执动作码等信息。供应商接收 CONTRL 后，需要按 UCI 关联原始 ORDRSP 交换，记录回执状态；未收到回执时排查并联系 SPS Commerce，作为确认交换接收情况和跟踪通信异常的基础。

实施时建议重点关注以下业务字段：

CONTRL 的重点在于区分交换接收确认与订单业务接受，建立回执与原始交换的关联。实施时应确保 UCI 中被确认的控制号和原始发送方／接收方与原始交换 UNB 一致；CONTRL 本身的 UNB／UNZ 也应配对，避免将技术回执当作业务订单接受，或漏掉对收到的 ORDERS 发送回执的要求。

订单回复

ORDRSP 是供应商向 Bing Lee 发送的订单业务回复报文，通常包含回复编号、原始采购订单号、回复日期、整单状态，以及适用时的行状态、承诺数量、差异原因、价格和地点分配等信息。Bing Lee 接收 ORDRSP 后，需要识别供应商对原始订单的业务承诺及差异，结合商品行和交货分配进行处理，作为更新订单业务状态及协调后续供货安排的基础。

实施时建议重点关注以下业务字段：

ORDRSP 的重点在于为每张原始订单生成业务回复；整单接受可省略商品明细，整单拒绝或变更则需回传原订单全部行及适用的门店分配。实施时应确保 RFF+ON 引用原始订单号；包含明细时保留原始行号及商品标识，门店回复中的 application reference number 与 ORDERS 一致，避免只回复变化行、错误关联门店批次，或混用整单状态与商品行状态。

Bing Lee EDI 对接方案如何落地？

在明确 Bing Lee 的 EDI 需求后，供应商需要选择合适的落地方式。

方案一：本地化部署 + ERP 系统无缝集成

对于希望实现订单接收、订单回复和回执状态自动处理的供应商，推荐采用本地化部署方案。可基于知行之桥 EDI 系统，按最终确认的协议协助企业建立 EDI 传输通道（此处以 OFTP 为例），实现 EDIFACT 报文与内部业务数据之间的自动转换。

EDIFACT 报文本身可读性较差，不适合业务系统直接处理。通过知行之桥，Bing Lee 与供应商之间往来的采购订单 ORDERS、订单回复 ORDRSP 和语法与服务报告 CONTRL 等报文，可以被转换为 ERP 更容易识别的 JSON 数据格式。这样，ERP 系统只需要处理清晰的业务字段，例如订单号、原始行号、GTIN、供应商代码、门店 GLN、分配数量、交期及未税价格等，不需要直接理解复杂的 EDIFACT 段结构。

下图为本次提供的 Bing Lee 工作流截图，展示了 ORDERS／CONTRL 的接收分流，以及 ORDRSP 从业务 JSON 转换为 EDIFACT 后，通过 OFTP 发送的路径。

知行之桥会将 Bing Lee 发来的采购订单 ORDERS报文自动解析并转换为业务 JSON，供 ERP、OMS 或 WMS 直接处理；内部系统生成订单回复 ORDRSP JSON 后，知行之桥再将其转换为 Bing Lee 要求的 EDIFACT 报文，在 OFTP 示例方案中自动发送；正式上线采用与 Bing Lee／SPS Commerce 确认后的协议和连接参数。

这一示例工作流覆盖 OFTP 通信、EDIFACT 解析、字段映射、JSON 转换和报文发送，内部系统只需处理清晰的业务 JSON，减少对 EDIFACT 复杂结构的理解和开发成本。

以下以采购订单 ORDERS 为例，将一个商品行、一个门店交货分配的订单，转换为业务 JSON 的结果。

方案二：暂不集成 ERP，直接使用知行之云 Web EDI

对于暂时没有 ERP 集成计划，或订单量尚未达到自动化集成规模的供应商，可以选择知行之云 Web EDI 方案。该方案无需在本地部署服务器，也不需要企业自行开发 ERP 接口，业务人员可直接通过网页处理 Bing Lee 的 EDI 单据。

在知行之云 Web EDI 中，Bing Lee 发来的采购订单 ORDERS会被转换为可读的网页单据，业务人员可以在线查看订单明细、门店或客户交货要求及回执状态，维护订单接受、拒绝或变更信息，并生成订单回复 ORDRSP 等回传单据。 

当后续订单量增加、单据处理频率提升，或企业希望进一步提升自动化程度时，也可以从知行之云 Web EDI 逐步升级到知行之桥本地化部署方案，实现与 ERP、WMS、OMS 等系统的深度集成。

知行EDI方案选型建议

本地化部署知行之桥 EDI 系统更适合对数据安全、系统集成和长期运维有较高要求的企业。企业可将系统部署在本地服务器或私有云环境中，将订单、库存、客户地址、价格、发货、发票等业务数据保留在可控范围内，便于满足内部数据管理、安全审计和合规要求。

如果企业暂时不需要本地化部署，也暂不对接ERP等内部系统，建议直接开通 知行之云 LIP 系统，一套基于 SaaS 模式的 Web EDI 解决方案，同样支持试用。业务人员可通过网页处理配置范围内的业务单据；本次以 Bing Lee 采购订单、订单回复及相关回执为范围，更适合中小型供应商快速推进 EDI 对接。

如果你正在准备与 Bing Lee 进行 EDI 对接，欢迎联系知行软件，获取 Bing Lee EDI 对接方案、测试流程、报文映射建议及示例工作流，快速推进项目测试与上线。