PORDCR message type — PORDCR IDoc Message Type for Purchase Order Collaboration

PORDCR moves a purchase order document out of SAP ERP or S/4HANA procurement toward an external supplier-facing collaboration system, most commonly SAP Supply Network Collaboration (SNC/ICH) or an Ariba Network connection reached through middleware such as SAP Cloud Integration or SAP PI/PO. The direction is always outbound from the buying system. It is generated when a purchase order is created or changed in a purchasing organization that has vendor collaboration switched on, as an alternative to sending the order as a classic EDI ORDERS message straight to a vendor mailbox. The receiving side uses the data to publish the order to the supplier portal, trigger vendor-managed inventory replenishment logic, or start subcontracting component visibility. The supplier's acknowledgment typically returns as a separate confirmation message rather than a direct reply IDoc.

PORDCR and PORDCR2 do not reuse the classic E1EDK/E1EDP segment family from ORDERS; they carry their own segment set built for collaboration fields, so segment names look unfamiliar to consultants who only know classic purchasing IDocs. Describing them by function rather than exact technical name is safer than guessing the spelling.

The outbound partner profile (transaction WE20) for the vendor or the logical system representing SNC/Ariba must carry an outbound parameter for PORDCR or PORDCR2, pointing to the correct message type version, IDoc basic type, and a process code that triggers the collaboration mapping. The port (WE21) must reference the correct RFC destination or XML port toward the middleware, not a generic file port left over from a classic EDI setup. On the trigger side, purchase order output determination (whether classic NAST-based output types or the newer condition-based output management) must have an output type configured to fire PORDCR/PORDCR2 for the relevant purchasing document type and partner function, with the medium set to EDI or XML rather than print or fax. If the output type exists but is not proposed on the purchase order, the output determination procedure or access sequence is the first suspect, not the partner profile.

Work from the document outward rather than from the IDoc inward; a healthy-looking IDoc status can still mean the wrong data reached the supplier.

Purchasing/MM functional owns output determination, the confirmation control key, and whether the purchasing document type is enabled for collaboration. Basis owns the port, RFC destination, and middleware connectivity. Hand over to the integration or PI/PO/Cloud Integration team when the IDoc leaves ECC/S4 cleanly but the collaboration platform reports a mapping or content rejection, since that failure lives in the interface layer, not in purchasing configuration.

PORDCR is misleading in several ways that trip up consultants used to classic EDI purchasing.

The reflex is to select the failed IDoc in BD87 and reprocess it immediately. If the cause is a missing collaboration partner setup on the SNC or Ariba side, or an item category the receiving system does not support, reprocessing produces the identical error and burns time without narrowing the cause. It also risks creating a duplicate order on the supplier side if the first attempt partially succeeded before failing, which then requires manual cleanup on both ends.