OMHU 公司简介

OMHU 是来自丹麦的家具设计与零售品牌，公司地址位于丹麦哥本哈根 Hejrevej 33C，业务覆盖 TEDDY 系列沙发、休闲椅、脚凳及家居配件等多个品类。对于 OMHU 供应商而言，订单接收、交期确认、商品信息核对及发货反馈都需要较高的数据准确性和响应效率。

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

知行软件可基于知行之桥 EDI 系统或知行之云 Web EDI 系统，帮助供应商完成 OMHU SFTP 通信、EDIFACT D.96A 报文解析、字段映射、格式转换及业务系统集成，快速满足 OMHU 的 EDI 对接要求。

OMHU EDI 需求概览

OMHU EDI 对接主要围绕采购订单处理、交付承诺与发货反馈展开，从 OMHU 下发采购订单 ORDERS 开始，到供应商通过 ORDRSP 回传订单回复，并在发货时发送 DESADV 发货通知，形成完整的业务闭环。

本次对接主要采用 SFTP 作为传输方式，并基于 EDIFACT D.96A 报文标准完成业务数据交换。涉及的核心业务单据如下：

在项目启动阶段，建议供应商优先确认 OMHU 最新 EDI 规范文件、SFTP 连接参数、每类单据的传输方向、测试场景及上线要求。SFTP 由本次项目输入明确；现有规范未提供主机、端口、认证方式、主机密钥、收发目录或文件命名约定，这些参数应在配置通道时逐项确认。

字段表与样例在 ORDRSP／DESADV 子集标识、部分币种类型码及行级参考限定符上存在差异。实施时应建立确认清单，通过测试文件确定采用值；不能直接将示例视为完整且已通过认证的生产报文。

采购订单

ORDERS 是 OMHU 向供应商发送的采购订单报文，通常包含订单号、订单日期、买方订单参考、交易方与收货地址、EAN、买方 SKU、款式／批次、数量、交期和价格等信息。供应商接收 ORDERS 后，需要核对交易方与商品主数据，保留原始订单号和行号，并将订单同步到 ERP、OMS 或 WMS，作为订单回复、生产备货与发货通知关联的基础。

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

ORDERS 的重点在于准确识别订单、买方商品编号与交货要求，并区分买方、收货方、账单方及当前接收方。实施时应确保 ORDERS 的订单号、行号、EAN 和买方 SKU 能够与 ORDRSP、DESADV 正确匹配，收货人与发票接收方信息分别保留，避免商品映射错误、将账单地址当作交货地址，或在后续报文中丢失订单关联。

订单回复

ORDRSP 是供应商向 OMHU 发送的订单回复报文，通常包含回复编号、回复日期、原始订单参考、交易方、商品行、交付数量、预计交货日期及价格等信息。OMHU 接收 ORDRSP 后，需要按原始订单与行号识别供应商反馈，更新交付安排并协调后续履约，作为订单状态更新、交期跟踪及发货衔接的基础。

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

ORDRSP 的重点在于按本项目的字段表组织订单回复，明确区分订单日期、要求交期和预计交期。实施时应确保 RFF+ON 及行级参考指向原始订单和原始行，数量单位与商品标识保持对应；子集标识与功能码按联调确认值发送，避免沿用其他交易伙伴的接受／拒绝编码，或将预计交期错误写为原订单要求交期。

发货通知

DESADV 是供应商向 OMHU 发送的发货通知报文，通常包含发货通知编号、单据日期、发货日期、原始订单与运输参考、跟踪链接、收货信息、承运方及商品发货数量等信息。OMHU 接收 DESADV 后，需要关联订单和商品明细，识别发货批次及物流跟踪信息，作为订单履约跟踪、收货准备和物流查询的基础。

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

DESADV 的重点在于将发货单、订单号、原始行号及实际发货数量关联起来，明确跟踪链接的字段语义与编码方式。实施时应确保行级订单参考与原始 ORDERS 对应，QTY+12 反映实际发货数量，日期和物流参考与本次发货一致，避免出现发货单无法匹配订单、发货数量失真或物流链接无法正确解析。

OMHU EDI 对接方案如何落地？

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

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

对于希望实现采购订单接收、订单回复及发货通知自动处理的供应商，推荐采用本地化部署方案。可基于知行之桥 EDI 系统，协助企业建立与 OMHU 的 SFTP 传输通道，实现 EDIFACT D.96A 报文与内部业务数据之间的自动转换。

EDIFACT D.96A 报文本身可读性较差，不适合业务系统直接处理。通过知行之桥，OMHU 与供应商之间往来的采购订单 ORDERS、订单回复 ORDRSP 和发货通知 DESADV 等报文，可以被转换为 ERP 更容易识别的 JSON 数据格式。这样，ERP 系统只需要处理清晰的业务字段，例如订单号、原始行号、EAN、买方 SKU、款式／批次信息、收货地址、数量、交期及物流跟踪链接等，不需要直接理解复杂的 EDIFACT D.96A 段结构。

下图采用本次提供的 OMHU 工作流截图。上方为 SFTP 接收 ORDERS，经 EDIFACT 解析、报文分流、字段映射后输出 JSON；下方为 ORDRSP 和 DESADV 各自从 JSON 输入，经字段映射后汇入 EDIFACT 生成与 SFTP 发送路径。

知行之桥 EDI 工作流示例：用户提供的 OMHU 实际界面截图，展示方案路径；连接参数、映射和联调结果仍需验证。

知行之桥会将 OMHU 发来的采购订单 ORDERS 报文自动解析并转换为业务 JSON，供 ERP、OMS 或 WMS 直接处理；内部系统生成订单回复 ORDRSP、发货通知 DESADV JSON 后，知行之桥再将其转换为 OMHU 要求的 EDIFACT D.96A 报文，并通过 SFTP 自动发送给 OMHU。

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

以下以采购订单 ORDERS 为例，依据项目规范构造一条商品行的模拟采购订单，包含买方订单参考、供应商与买方标识、收货信息、币种、商品、数量、要求交期和净价。所有业务标识、地址、联系信息及价格均为模拟值。

下图展示同一份模拟 EDI 与对应业务 JSON 的核心字段，完整 JSON 还保留交易方、运输信息、价格限定符和行级参考。金额、数量及编号以字符串保存，便于保留原始精度与标识格式；实际数据类型可按 ERP 接口约定调整。

ORDERS 模拟报文与对应业务 JSON 核心字段示例。此图展示数据映射关系，不代表软件运行结果或已通过 OMHU 认证的订单。

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

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

在知行之云 Web EDI 中，OMHU 发来的采购订单 ORDERS 会被转换为可读的网页单据，业务人员可以在线查看订单商品、数量、收货信息和要求交期，维护交付数量、预计交货日期、发货信息及跟踪链接，并生成订单回复 ORDRSP、发货通知 DESADV 等回传单据。

下图沿用模板提供的知行之云 Web EDI 通用产品截图，说明业务人员在网页中查看订单与处理相关单据的方式。截图当前交易伙伴为 Chewy，并非 OMHU 的实际业务环境；OMHU 的字段、校验和回复表单需依据项目规范配置。

知行之云 Web EDI 通用产品页面示例（模板素材，非 OMHU 实际页面）。本次范围仅涉及 ORDERS、ORDRSP、DESADV。

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

知行EDI方案选型建议

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

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

以上周期为模板参考，具体取决于 SFTP 参数准备、规范差异确认、字段映射、ERP 接口与测试安排。

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