RosettaNet PIPs vs X12: which one your partner will demand

X12 is the North American default for retail, distribution, transport and most manufacturing: numbered transaction sets over AS2, SFTP or a VAN. RosettaNet came out of the high-tech supply chain, where component makers, contract manufacturers and their distributors wanted messages shaped like a business process rather than a flat transaction set, and it has stayed largely inside that industry. If your customers are retailers and distributors you will meet X12. If they make or move electronics you will meet PIPs, and often both at once, from different customers, in the same week.

A PIP, a Partner Interface Process, is an XML message plus the choreography around it, numbered by cluster, segment and process. The order-to-cash set lines up with X12 closely enough to map between them in your head:

• 3A4 Request Purchase Order answers to the 850, and its response carries the acceptance an 855 would
• 3A7, 3A8 and 3A9 cover order updates, changes and cancellations, where X12 has the 860 and 865
• 3B2 Notify of Advance Shipment is the 856; 4B2 Notify of Shipment Receipt is the receiving confirmation that X12 handles with the 861, or with the 944 for a 3PL
• 3C3 Notify of Invoice is the 810, and 3C6 Notify of Remittance Advice is the 820
• 3B11 and 3B13, the shipping order and its confirmation, are the warehouse pair, standing where the 940 and 945 stand in X12
• 4C1 Distribute Inventory Report is the 846, and 0A1 Notification of Failure is the framework's own error signal, the nearest thing to a 997

The difference is in the detail. A PIP carries more structure than its X12 counterpart, more of it required, and a choreography that expects a reply inside a defined time, so the mapping is rarely one field to one field.

RosettaNet messages travel inside the RosettaNet Implementation Framework, RNIF, most often version 2.0: a multipart envelope with a preamble, a delivery header and a service header wrapped around the PIP content, signed and optionally encrypted, carried over HTTPS. Some partners run PIPs over ebXML messaging instead. Either way, a translator built for X12 over AS2 does not handle it. The envelope, the signals and the retry rules are different, and an acknowledgement is a message in its own right rather than a 997.

In practice that means a second connector beside the AS2 one, certificates for it, and a process that knows a PIP has a timeout and an expected reply, which a flat file never had.

The mistake is building two order flows, one per standard. The flow is the same in both: an order arrives, is acknowledged, is picked and shipped, is confirmed and invoiced. Put a canonical order in the middle, in your own system's shape, and translate at the edges: X12 in and out on one side, PIPs in and out on the other. Each new partner is then one mapping to the canonical order plus one transport, whichever standard they named.

Validation lives in the middle as well. Quantity, unit of measure, ship-to and item checks run once, on the canonical order, so a bad 3A4 and a bad 850 are caught by the same code and reported the same way.

• Which PIPs, which versions of each, and which RNIF version or ebMS profile; their implementation guide names all three
• Their endpoint, their certificates, their test environment, and whether they expect synchronous or asynchronous replies
• The timeout and retry rules per PIP, because a late reply is a failure in RosettaNet in a way a late 997 is not
• Which identifiers they use for parts and locations, since high-tech partners lean on their own part numbers and DUNS numbers rather than GTINs and GLNs
• Whether they also run X12 for any document, which some do for invoices and remittances

Both standards are mapped by the same people here. The EDI integration page lists the PIPs we meet most beside the X12 sets, and a partner on either standard is brought live through the EDI and trading-partner row of our logistics page.