SHPORD message type — SHPORD IDoc Message Type for Shipping Orders

SHPORD carries a shipping order document from the shipper's SAP system to an external carrier, forwarding agent or logistics service provider. It represents the instruction to execute a specific leg of a shipment: what to pick up, from where, when, and where it needs to go. The IDoc is generated outbound, triggered by the shipment document once that shipment has been planned and checked in the transportation area, and it usually travels through an integration layer such as an EDI subsystem, SAP PI/PO, or SAP Integration Suite before reaching the carrier's own system or portal. It does not carry freight cost or billing information; that is handled through separate documents. The receiving party is always external to the sending system, so a successful send status in SAP confirms only that the message left SAP, not that the carrier acted on it.

The IDoc is built from the shipment document, so its segment structure mirrors what a shipping order needs to communicate to an external partner.

Outbound processing needs a partner profile with SHPORD listed in the outbound parameters for the carrier or forwarding agent's partner number, pointing to a process code that resolves to the function module responsible for building the IDoc from the shipment document. That output must actually be proposed on the shipment through output determination, which usually means an output type tied to a condition record and, in the background, a partner function on the forwarding agent's vendor master marked as EDI or output relevant. A port must exist: a file port if the receiver sits behind a traditional EDI subsystem, or an RFC/ALE-style port if the message passes through a middleware layer such as PI/PO or SAP Integration Suite. The partner profile also decides whether the IDoc is sent immediately or picked up by a scheduled collection job. If the flow terminates in another SAP system, a matching inbound partner profile and process code are needed on that side.

Work from the shipment document outward, not from the IDoc list inward, since the IDoc is usually a symptom of an upstream shipment or partner problem.

The functional transportation team owns shipment configuration, output determination and the partner master data behind it. Basis or integration owns the partner profile, port definition, RFC destinations and whatever middleware or BTP integration flow the IDoc passes through. Escalate a partner profile or port change, or a stuck ALE queue, to Basis or integration; escalate a missing output proposal or wrong partner function to the transportation functional consultant. ABAP involvement is only needed if the outbound function module itself dumps.

This message type is easy to misread because SAP's own status only covers half the journey.

The reflex is to reprocess the failed IDoc directly or to trigger the shipment output again by hand. This produces a second or third outbound IDoc carrying the same underlying problem, whether that is a missing partner function, an incomplete address, or a shipment that has not actually reached the checked status. The result is a noisier monitoring queue with several error records instead of one, and if the first attempt actually reached the carrier late, a duplicate shipping order on their side. The correct fix is upstream: correct the shipment or partner master data, then let output determination fire exactly once.