PIP 3A7 — Notify of Purchase Order Update

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

PIP purpose

PIP 3A7 notifies the buyer of an update by the seller of an already accepted order: unit price change, confirmed quantity, delivery date. It is an indispensable PIP in semiconductors where allocation and dates fluctuate during the cycle.

Message structure

The 3A7 choreography follows the one-action (notification) RosettaNet model:

Action: Notify of Purchase Order Update Action
Signal: Receipt Acknowledgment

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-3A7.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>3A7</GlobalProcessIndicatorCode>
</ServiceHeader>

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

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

--RN-BOUNDARY-2026--

Simplified XML example

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

xml pip-3A7.xml

<?xml version="1.0" encoding="UTF-8"?>
<Pip3A7NotifyOfPurchaseOrderUpdate xmlns="http://www.rosettanet.org/PIP3A7">
  <fromRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>Seller</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </fromRole>
  <toRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>Buyer</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </toRole>
  <thisDocumentGenerationDateTime>
    <DateTimeStamp>20260515T101500Z</DateTimeStamp>
  </thisDocumentGenerationDateTime>
      <PurchaseOrderUpdate>
        <PurchaseOrderIdentifier>
          <ProprietaryDocumentIdentifier>PO-2026-987654</ProprietaryDocumentIdentifier>
        </PurchaseOrderIdentifier>
        <ProductLineItem>
          <LineNumber><FreeFormText>1</FreeFormText></LineNumber>
          <requestedQuantity>
            <ProductQuantity>45000</ProductQuantity>
            <unitOfMeasure>EA</unitOfMeasure>
          </requestedQuantity>
          <requestedShipDate>
            <DateStamp>20260712</DateStamp>
          </requestedShipDate>
        </ProductLineItem>
      </PurchaseOrderUpdate>
</Pip3A7NotifyOfPurchaseOrderUpdate>

Transport and acknowledgment

Asynchronous emission, RNIF V02.00 over HTTPS POST or AS2. The notification date (RFF in EDIFACT, NotificationDateTime here) is legally binding on the buyer side in many contracts.

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

A foundry informs its OEM customer that an order of 50,000 wafers is re-allocated to 45,000 units and the shipping date slips from late June to mid-July. PIP 3A7 carries the new line, its new parameters, and a coded reason.

Foundations

Standards

Flagship messages

Tools