BAHAG OSTRPT Status详解

BAHAG是一家总部位于德国的跨国零售巨头，主要经营五金、建材、园艺及家居用品。在数字化贸易中，BAHAG 不仅拥有庞大的线下实体店，还运营着高度自动化的在线商店，业务覆盖德国、奥地利、西班牙、荷兰、克罗地亚和斯洛文尼亚等多个欧洲国家。

BAHAG 与供应商之间广泛采用 Drop Shipment（直发业务） 模式，最终客户在 BAHAG 的在线商店下单，但 BAHAG 并不从自己的仓库发货，而是将订单信息转给供应商，供应商收到订单后，直接将货物发送给最终客户。

BAHAG与供应商之间，通常会采用 EDIFACT 报文标准进行关键业务数据的电子交换，常用的EDI业务报文有： ORDERS（订单）, DESADV（发货通知）, INVOIC（发票）等。

本文将重点介绍由供应商向BAHAG发送的 EDIFACT OSTRPT（订单状态报告）报文。

OSTRPT简介

OSTRPT是基于EDIFACT标准的订单状态报告（Order Status Report）报文。它并非普通的通知，而是BAHAG为其直发业务（Drop Shipment）模式设计的、供应商必须遵循的强制性状态同步协议。

其核心作用包括：

• 同步全程物流进度：为BAHAG及其最终客户提供从“发货安排”到“妥投签收/异常拒收”的全程物流状态透明视图。
• 自动触发业务流程：特定状态码将直接触发BAHAG系统内部的财务开票等自动化作业。
• 异常管理：报告库存短缺导致的订单取消或者客户拒收等异常情况

简而言之，OSTRPT是一份强制性的EDIFACT电子报文，要求供应商在订单履约的每个关键节点（如发货、交期变更、签收、退货、取消），必须主动、及时地向BAHAG系统发送指定的状态代码。它是支撑BAHAG直运业务供应链高效协同与实时可视化的核心数据链路。

OSTRPT常见状态类型

BAHAG 将状态码分为 MUST（必须发送，触发内部流程）和 CAN（可选发送，仅供信息参考）两类

1.发货与交付类（Delivery Status）

• Status 212 – Delivery Date Changed（交货期变更）： [DEPENDENT/MUST] 当发生送货日期变动时，必须通过此代码告知。注意：此代码通常由BAHAG要求改期引起，且仅适用于货运（Freight Forwarder）而非快递（Parcel）
• Status 24 – Goods Despatched（已发货/安排送货）： [MUST] 极其重要。它表示货物已由供应商发出。这是触发 BAHAG 内部结算系统（如开具发票）和向客户发送通知的关键环节
• Status 21 – Delivery Completed（送货完成）： [CAN] 表示客户已签收或确认收到货物

2.取消类（Cancellation Status）

• Status 275 – Cancellation Acknowledged（取消已确认）： [MUST] 用于确认收到了来自 BAHAG 客服的取消请求，确认后 BAHAG 才能在系统中关闭该订单。
• Status 56 – Cancellation Initiated by Supplier（供应商发起的取消）： [MUST] 仅在（Out of stock）缺货等特殊情况下由供应商发起，在发送前供应商必须先联系 BAHAG 的商店管理团队。

3.退货与拒收类（Return Status）

• Status 325 – Goods Not Accepted（货物拒收）： [CAN] 可选状态，表示最终客户拒绝接受货物
• Status 82 – Collection Pick up Completed / Returns Received（退货签收）： [MUST] 退货商品回到供应商仓库并完成验收后，供应商必须发送此代码以触发后续的退款或补发流程。

状态触发情形详解

1.Status 24

触发情形

供应商在完成发货安排（例如，货物已交给承运商并取得物流单号）后，必须立即发送状态码 24 来通知BAHAG。

触发规则

情况A：包裹快递服务（Parcel Service，如DHL, UPS, Hermes等）

• 规则：发送状态码 24 就是最后一个状态。
• 原因：快递有完善的在线跟踪系统，BAHAG和最终客户可以直接查询物流状态，无需供应商再确认签收。
• 操作：货物交给快递公司，拿到追踪号后，发24即可。

情况B：货运代理/零担物流（Forwarder / Freight Delivery，如大件货物运输）

• 规则：发送状态码 24 后，可以（且建议）再发送一个可选的状态码 21。
• 原因：大件物流的末端签收信息可能不会自动同步。在客户签署回执后，可选触发 Status 21，21表示“客户已签收”，为BAHAG提供额外的交付确认。
• 操作：安排发货后发24 → 得知客户签收后，可补发21。

特殊规则

关于配置器ID（Configurator ID）的特殊规则

如果BAHAG发送的原始订单中包含配置 ID（RFF+ACD 段）,在回传24状态时必须在报文中包含相同的 RFF+ACD 段和ID。否则系统无法匹配订单

总结

Status 24 代表 “已安排送货”或 “货物已发出”，是一个强制性发送状态，收到此状态后，BAHAG 系统会自动启动开票流程，并通知最终客户货物已在途中。

2.Status 212

触发情形

当BAHAG发起要求更改交货日期时，供应商必须使用状态码 212 来响应这个变更，作为临时通知。

触发规则

• 仅当客户（BAHAG）主动要求改期时才使用。如果是供应商自己导致的延误，不能用212。
• 仅限大件货运代理交付（Freight Forwarding），不能用于包裹快递服务（parcel delivery），快递包裹的交货变更可以通过物流商提供的查询链接直接追踪，无需通过 EDI 报文进行中间同步

注意

• 严禁用于包裹递送
• 一旦发生客户要求改期这件事，你就必须 发这个状态来履行流程。本身这个状态码在报文中是可选（OPTIONAL） 的，但OPTIONAL ≠ 可以不按规则发，而是 只有发生该业务场景时才需要发。
• 发送Status 212之后，还需在发货后发送强制性的Status 24（交货已安排），用于触发财务结算等。212只是告知日期变了，24才是正式确认“已按新日期安排发货”。

总结

只有在大件货运且客户主动要求改期的情况下才使用 Status 212

3.Status 21

触发情形

状态码 21 是一个可选状态，用于在货运代理交付后，向BAHAG提供货物已由最终客户签收的额外确认。

触发规则

• 必须发生在状态24之后： 只能在已经发送过 Status 24（交货已安排） 之后，才能发送Status 21。21是24的后续补充信息。
• 主要用于货运代理交付：21主要用在非包裹快递的交付中（例如通过物流公司运送的大件货物）。因为这类物流的末端签收证明可能不会自动同步给BAHAG，需要供应商手动确认。

特殊规则

关于配置器ID（Configurator ID）的特殊规则：如果BAHAG发送的原始订单中包含配置 ID（RFF+ACD 段）,在回传21状态时必须在报文中包含相同的 RFF+ACD 段和ID。否则系统无法匹配订单

总结

在发送状态24后，可选择发送状态21，用于告知BAHAG货物已由最终客户签收，一般不用于包裹快递。

4.Status 275

触发情形

当供应商收到BAHAG客户中心发出的“取消请求”邮件后，必须使用Status 275 进行回复确认。这是BAHAG客服在其系统中关闭订单的必要依据。

触发规则

• 供应商必须首先收到BAHAG客户服务中心发出的正式 “Widerruf-Anfrage”（取消请求） 邮件。不能主动或随意发送此状态。
• 仅限发货前，只有在供应商尚未发送 Status 24（已发货）报文的情况下，才能确认取消订单。
• 如果发货流程已经处理完成（已发送 Status 24），则不能再发送 275，而必须转为退货流程处理

特殊规则

关于配置器ID（Configurator ID）的特殊规则

如果BAHAG发送的原始订单中包含配置 ID（RFF+ACD 段）,在回传275状态时必须在报文中包含相同的 RFF+ACD 段和ID。否则系统无法匹配订单

总结

状态码 275 是供应商对BAHAG“取消请求”的正式EDI回执，在收到取消请求邮件后，且还未发送Staus24，则必须发送Status275进行确认。

5.Status 56

触发情形

当供应商因库存短缺等自身原因，预知无法履行订单时，必须主动使用状态码 56 通知BAHAG取消订单。并需同步通过邮件通知店铺管理团队。

触发规则

• 供应商预先识别到网店商品即将缺货，无法按约定交付时，供应商必须使用状态码 56通知BAHAG

特殊规则

• 关于配置器ID（Configurator ID）的特殊规则

如果BAHAG发送的原始订单中包含配置 ID（RFF+ACD 段）,在回传56状态时必须在报文中包含相同的 RFF+ACD 段和ID。否则系统无法匹配订单

• RFF+ABO（取消原因）

这是本状态的核心信息。必须提供用去说明取消的具体原因

RFF+ABO:1 = 代表无货 (Not available)。
RFF+ABO:2 = 代表未通知后续送货 (No subsequent delivery notified)。

注意

• 缺货情况应属于例外，不要频繁使用状态56.
• 发送状态码56 不能取代邮件通知，供应商在发送状态码56后必须同步进行邮件通知

总结

Status 56代表 “供应商发起取消”， 这是一个强制性发送的状态码，用于供应商在发现无法履行订单（如缺货）时主动告知 BAHAG。

6.Status 82

触发情形

当客户退回的货物抵达供应商仓库，并完成验收后，供应商必须使用Status82 向BAHAG确认“退货已完成接收”。同时，必须明确告知BAHAG客户对此次退货的最终诉求（是退款还是换货）。

触发规则

• 被退回的货物（无论是客户拒收还是其他原因）已实际送达供应商的仓库
• 供应商已检查并确认收到了该退货

特殊规则

• 关于配置器ID（Configurator ID）的特殊规则

如果BAHAG发送的原始订单中包含配置 ID（RFF+ACD 段）,在回传56状态时必须在报文中包含相同的 RFF+ACD 段和ID。否则系统无法匹配订单

• RFF+ZZZ（处理意向）

这是本状态的核心信息。 供应商必须在与BAHAG客户服务中心沟通后，在 RFF+ZZZ 段中标明客户的处理要求：

RFF+ZZZ:1 = 客户要求退货。
RFF+ZZZ:2 = 客户要求换货/补发

总结

状态码82 表示退货流程的终结，主要用于告知客户退货货物已完成实物接收与初步验收，以及明确客户端的最终处置要求（退款或换货），会直接触发 BAHAG 内部的财务结算流程。

7.Status 325

触发情形

当最终客户拒绝签收货物时，供应商可以（非必须）使用状态码 325 来预先通知BAHAG。

触发规则

• 当物流公司尝试投递货物，但客户出于各种原因（如外箱破损、错发或单纯改变主意）在现场拒绝签收时，供应商应发送此状态
• 无论你是否发送了325，一旦拒收的货物被退回你的仓库并完成验收，你都必须发送强制性Status 82（退货收货确认）

特殊规则

• 关于配置器ID（Configurator ID）的特殊规则

如果BAHAG发送的原始订单中包含配置 ID（RFF+ACD 段）,在回传56状态时必须在报文中包含相同的 RFF+ACD 段和ID。否则系统无法匹配订单

总结

状态码 325 是一个友好的“提前通知”，告诉BAHAG货物被客户拒收了。

325 状态被视为中间信息。在其之后，必须发送强制性的 Status 82（退货签收） 状态，才能完成业务闭环。

OSTRPT（Order Status Report，订单状态报告）是 BAHAG 针对直发业务（Drop Shipment）在线订单定义的 EDIFACT D01B 标准报文，用于供应商向 BAHAG 实时回传订单处理进度。

BAHAG 对报文字段的长度和类型有极其严格的要求。如果供应商发送的字段不符合规范（例如追踪号长度错误或货号不匹配），系统将报错并将该报文置为无效，这可能导致订单处理停滞或结算延迟。

每张订单都必须通过 OSTRPT 进行回复。 供应商必须针对每个状态变更至少发送一条 OSTRPT 消息，且每条消息只能引用一个订单号。如果未能按规范发送，BAHAG 将无法处理后续流程（如开票或通知客户），报文甚至会被视为未收到。

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