PIP 3A4 — Request Purchase Order

RosettaNet choreography in cluster 3 (Order Management), covering the XML exchange between Buyer ↔ Seller. Operational unit for order management on RNIF V02.00.

PIP purpose

PIP 3A4 is the reference purchase order of the standard. The buyer transmits an XML PurchaseOrder to the seller: header (buyer, seller, dates, terms), lines (identified product, requested quantity, negotiated price), and logistics conditions (Incoterm, delivery location). The choreography expects a Purchase Order Confirmation in return.

Message structure

The 3A4 choreography follows the two-action (request / response) RosettaNet model:

Primary action: Purchase Order Request Action
Signal: Receipt Acknowledgment
Response action: Purchase Order Confirmation Action

Each action is wrapped in a multipart MIME RNIF V02.00 envelope signed with S/MIME. Here is a condensed view of the envelope:

text rnif-envelope-3A4.eml

MIME-Version: 1.0
Content-Type: multipart/related; type="application/xml";
  boundary="RN-BOUNDARY-2026"

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: RN-Preamble.xml

<Preamble xmlns="http://www.rosettanet.org/RNIF/V02.00">
  <standardName>RosettaNet</standardName>
  <standardVersion>V02.00</standardVersion>
</Preamble>

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: RN-ServiceHeader.xml

<ServiceHeader xmlns="http://www.rosettanet.org/RNIF/V02.00">
  <GlobalProcessIndicatorCode>3A4</GlobalProcessIndicatorCode>
</ServiceHeader>

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: Pip3A4PurchaseOrderRequest.xml

<!-- payload PIP 3A4 ci-dessus -->

--RN-BOUNDARY-2026--

Simplified XML example

Minimal PIP 3A4 payload for didactic purposes. The structural elements (fromRole, toRole, thisDocumentGenerationDateTime, and the PIP-specific business block) are required in any conformant implementation.

xml pip-3A4.xml

<?xml version="1.0" encoding="UTF-8"?>
<Pip3A4PurchaseOrderRequest xmlns="http://www.rosettanet.org/PIP3A4">
  <fromRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>Buyer</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </fromRole>
  <toRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>Seller</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </toRole>
  <thisDocumentGenerationDateTime>
    <DateTimeStamp>20260515T101500Z</DateTimeStamp>
  </thisDocumentGenerationDateTime>
      <PurchaseOrder>
        <GlobalPurchaseOrderTypeCode>Standard</GlobalPurchaseOrderTypeCode>
        <PurchaseOrderIdentifier>
          <ProprietaryDocumentIdentifier>PO-2026-987654</ProprietaryDocumentIdentifier>
        </PurchaseOrderIdentifier>
        <ProductLineItem>
          <LineNumber><FreeFormText>1</FreeFormText></LineNumber>
          <ProductIdentification>
            <GlobalProductIdentifier>00614141999996</GlobalProductIdentifier>
          </ProductIdentification>
          <requestedQuantity>
            <ProductQuantity>50000</ProductQuantity>
            <unitOfMeasure>EA</unitOfMeasure>
          </requestedQuantity>
        </ProductLineItem>
      </PurchaseOrder>
</Pip3A4PurchaseOrderRequest>

Transport and acknowledgment

Core of the standard: HTTPS POST to partner endpoint or AS2. S/MIME signature and Receipt Acknowledgment systematic. The confirmation is often sent asynchronously (seller internal queue).

The transport channel is typically AS2 or direct HTTPS (RNIF over HTTP). For a reference of the security layers in use, see the AS2 on ediverse page.

Use case

TSMC orders 50,000 wafers from AMD on the RosettaNet flow: PIP 3A4 sent to the AMD portal, S/MIME signed, transported over RNIF V02.00 on HTTPS. AMD synchronously answers with a PIP 3A4 confirmation (accepted lines, confirmed dates) or later issues a PIP 3A7 if the order is updated.

Foundations

Standards

Flagship messages

Tools