SHPCON message type — SHPCON IDoc Shipping Confirmation Message Type

SHPCON moves a shipping confirmation for an outbound delivery. The typical flow is inbound to SAP: an external decentralized warehouse management system, a transport execution platform, or a third-party logistics provider confirms that a delivery has been picked, packed and loaded, and sends that confirmation back so SAP can post the goods issue. The document referenced is an existing outbound delivery created earlier in the sales or stock transfer process, not a new business object. The IDoc effectively closes the loop between physical execution outside SAP and the financial and inventory posting inside SAP. It is distinct from a despatch advice sent to a customer to announce a shipment; SHPCON is the internal confirmation that execution actually happened, and it is consumed rather than issued by SAP in most deployments.

The main header segment carries the delivery number, shipping point, and the actual date and time of the goods movement that the external system is confirming, along with means-of-transport or shipment reference data where relevant. An item-level segment carries the delivery item number, material, plant and storage location, and the quantity actually confirmed as picked or loaded, which may differ from the planned delivery quantity. Where batch or serial management is active, a further segment carries the batch number or serial numbers being confirmed against the item. Header and item segment field names beyond this description should be confirmed against the active IDoc extension in the system, since custom extensions frequently add carrier, handling-unit or tracking fields on top of the base structure.

Inbound processing needs a partner profile for the sending partner with SHPCON registered as an inbound message type, a process code that routes the IDoc to the function module handling goods issue posting from delivery confirmation, and a port matching however the external system connects, whether file, tRFC, or a middleware queue. The partner is usually modeled as a logical system if the sender is another SAP-adjacent system, or as a vendor/customer partner type if the sender is a genuine external 3PL. Because SHPCON is almost always inbound rather than output-determined, there is normally no condition-technique output type to configure on the SAP side for it; the trigger to send lives in the external system. Where SAP is expected to generate an outbound SHPCON as part of a non-standard integration, that would require its own output determination setup and should be treated as a bespoke build, not a standard flow.

Work from the IDoc status backward to the delivery, not the other way around.

Functional logistics execution owns the delivery, quantity tolerance, and batch determination rules that decide whether a confirmation posts cleanly. ABAP gets involved only if the inbound function module needs enhancement for custom segment fields. Basis owns the port, RFC destination, and connectivity to the external warehouse or 3PL system, and should be the first call when IDocs never arrive rather than when they arrive and fail.

SHPCON's biggest trap is that it looks like a simple status message but it performs a real inventory posting, so errors here are stock errors, not just interface errors.

The reflex is to mass-reprocess failed SHPCON IDocs in BD87 or to post the goods issue manually in VL02N to make the delivery look complete, then let the IDoc sit in error. Both hide the mismatch instead of resolving it. Manual posting creates a delivery state the external system does not know about, so its next confirmation attempt fails against an already-issued delivery, generating a second error that looks unrelated to the first. Reprocessing without checking the delivery status risks a duplicate goods movement if the confirmation was in fact already applied through a different channel.