The Party document, Party-v2009.1.xml, contains general information about the parties involved in the B2B transactions that the parties wish to share with each other. Each party, also called a trading partner, creates a Party document.

The Party document contains public identifying information about one trading partner. However, for added flexibility, multiple trading locations for the partner may be specified in the same document. These locations might be such things as different branch offices, product warehouses, or shipping destinations. Each party and each location includes a unique ID, which may be in GLN (Global Location Number) or NAMM format, plus the partner entity’s name, address, phone, email, and other contact information.

The Item document, Item-v2015.1.xml, essentially contains a catalog of items available for sale. The supplier creates this document and provides it to prospective buyers.

The Item document structure is reasonably “flat”, presenting salable items in a simple hierarchy with few levels. Each item has many possible descriptive characteristics, most of which are optional, but which provide ease of description for virtually any product, including packaging, origin, and warranty information.

The Functional Acknowledgement document, FunAck-v2009.1.xml, is a simple notification from party to party acknowledging the receipt of another transaction such as an item document, purchase order, advanced shipment notice, or invoice. It may also provide information indicating the status of the transactional document. This document is used repeatedly throughout the supply chain.

The Price Book document, Pricebook-v2015.1.xml, contains pricing information for various items offered by the supplier. It can specify price changes (breaks) at different purchase tiers (e.g., 1-100 units, 101-500 units, etc.) as well as indicate units of measure (UOM) for the tiers.

This document is optional, and is in beta testing as of this writing.

The Purchase Order document, PO_v2015.1.xml, contains a list of items the buyer has selected for purchase from the supplier.

The Purchase Order document first provides basic information about the proposed sale, such as buyer, billing, and supplier data. It then provides overall sale specifics, such as terms and shipping instructions. Finally, it provides a shipping location and a list of ordered items.

The Purchase Order Status Request document, POStatusRequest-v2015.1.xml, requests from the supplier the status of an outstanding Purchase Order. In fact, the status of multiple Purchase Orders may be requested in one transaction, thus obviating the need for multiple requests. This document is in beta testing as of this writing.

As evidenced by its name, the Purchase Order Status / Detail Acknowledgement document, POStatus_v2015.1.xml, is a dual-purpose transactional document. It may be transmitted from supplier to buyer as a detailed acknowledgement of a submitted Purchase Order (in lieu of a Functional Acknowledgment as shown in step 7, above). It may also be sent as a status report for a buyer's Purchase Orders, generated either periodically or in specific response to a Purchase Order Status Request, This document is in beta testing as of this writing.

The Advanced Shipping Notice document, ASN_v2015.1.xml, contains detailed information about one or more orders in progress from supplier to buyer. It may be requested via the Purchase Order document, and provides specific partial or full order shipment details, enabling the buyer to reconcile items ordered with those actually received.

The Invoice document, Invoice-v2009.2.xml, is a supplier’s request for payment from the buyer. It contains information about the supplier, payee, and buyer, as well as invoice terms and detailed information about the referenced purchase, down to the individual items.

The Sell Through document, SellThrough-v2012.1.xml, is an optional post-transaction report sent by the buyer to the supplier, indicating what products have been sold, to which locations, for what price, etc. This document is discretionary and informational only, and thus does not trigger any further action, acknowledgement, or event.