850 Purchase Order

Ariba, Inc. cXML 1.
2: ANSI X12 004010 850 Purchase Order Implementation Guidelines
850 Purchase Order
Functional Group ID= PO

Introduction:
This Draft Standard for Trial Use contains the format and establishes the data contents of the Purchase Order
Transaction Set (850) for use within the context of an Electronic Data Interchange (EDI) environment. The
transaction set can be used to provide for customary and established business and industry practice relative to the
placement of purchase orders for goods and services. This transaction set should not be used to convey purchase
order changes or purchase order acknowledgment information.
Notes:
Ariba Network receives Purchase Orders from Ariba Buyer in the form of cXML OrderRequest documents.
Suppliers are able to select their preferred method of receiving Purchase Orders.
As a service to Suppliers preferring to transact via EDI, Ariba Network maps to the ANSI X12 004010 850 Purchase
Order document. Suppliers can select EDI as their preferred method for receiving Purchase Orders.
Now, suppliers can also select EDI as a method for receiving Change and Cancel Orders.
The separator characters normally used are:

Segment Terminator: ~ (tilde)
Element Separator: { (left brace)
Sub-Element Separator: } (right brace)
Suppliers can contact Ariba Network Technical Support to request standard separators if they prefer.
Ariba Network does not require or accept interchange acknowledgements (TA1), but does require a 997 to be
returned for each functional group received (other than type FA).
On returning a 997, the following points should be noted:
- Sending AK1/AK9 only is not supported at this time. You MUST send an AK2/AK5 group for each transaction set
received within the group.
- Detailed 997s are not required, but are accepted. You can send AK3/AK4 within an AK2 group if you wish.
- ISA14 is set to 0, so do not send a TA1. It is not supported and will cause an error.
AK5 acknowledgement codes:

- Code "A" constitutes acceptance. The Purchase Order will be marked as Acknowledged and visible to your
customer.
- Code "E" is an EDI Compliance error. This is accepted with errors noted. Currently it will update the Purchase
Order status to Acknowledged, similar to code A.
- Code "R" represents rejection. Currently, this is the only AK5 acknowledgement code that will mark the Purchase
Order as Failed.
AK9 acknowledgement codes:
- The above codes apply. Code "P" is possible if not all AK5's are code "A".
In reading this Implementation Guide, the following usage codes are used:
Copyright (c) 2007-2015 Ariba, Inc. 1 Revised 4 August 2015
Ariba, Inc. cXML 1.2: ANSI X12 004010 850 Purchase Order Implementation Guidelines
Status Segment Element

----------------------- ------------ -----------
Mandatory M M
Must Use Must Use M (Required)
Recommended A A (Advised)
Dependant D D
Not Recommended NR NR
Not Used X X
Mandatory means that X12 says it is mandatory, so the guideline is bound by that rule.
Must Use means that X12 says it is optional, but Ariba Network requires it.
Recommended means that X12 says it is optional, and Ariba Network considers it optional, but recommends that it
be used.
Dependant means that X12 has its usage dependant on other segments or elements, or by semantic notes, or that
Ariba Network describes semantics on which its dependency lies.
Not Recommended is the opposite of Recommended. The information might be technically allowed, but is probably
ignored.
Not Used segments and elements are not even shown in the guideline. In cases there they made need to be shown for
consistency, they are marked with an X.
Heading:
Page Pos. Seg. Base User Loop Notes and
No. No. ID Name Status Status Max.Use Repeat Comments
5 010 ST Transaction Set Header M M 1
6 020 BEG Beginning Segment for Purchase Order M M 1
9 040 CUR Currency O Must Use 1
10 050 REF Reference Identification O >1
11 060 PER Administrative Communications Contact O 3
14 080 FOB F.O.B Related Instructions O 1
17 110 CSH Sales Requirements O 1
LOOP ID - SAC 1
18 120 SAC Shipping Charges O 1
20 125 CUR Currency O 1
LOOP ID - SAC 22
21 120 SAC Modifications O 1
22 130 ITD Terms of Sale/Deferred Terms of Sale O >1

24 150 DTM Date/Time Reference O 10
30 150 DTM Date/Time Reference O 10
31 150 DTM Expiration Date/Time Reference O 10
25 285 TXI Tax Information O 1
LOOP ID - N9 1
26 295 N9 Reference Identification - Payment of O 1
Purchase Order
27 297 DTM Date/Time Reference O Must Use 1
LOOP ID - N9 1
28 295 N9 Reference Identification - Comments O 1

29 300 MSG Message Text O Must Use 1000
LOOP ID - N9 998
30 295 N9 Reference Identification - Extrinsics O 1
31 300 MSG Message Text O 1000
LOOP ID - N9
LOOP ID - N9
LOOP ID - N1 1
32 310 N1 Bill-To Name O 1
33 320 N2 Additional Name Information O 2
34 330 N3 Address Information O 2
35 340 N4 Geographic Location O 1
36 360 PER Administrative Communications Contact O >1
LOOP ID - N1 1
38 310 N1 Ship-To Name O 1
44 390 TD5 Transport Information O 12
46 410 TD4 Carrier Identifier O 5
LOOP ID - N1 10
47 310 N1 Detailed Contact Information - Name O 1
LOOP ID - N1 1
58 310 N1 Delivery Address O 1
Detail:
LOOP ID - PO1 100000
62 010 PO1 Baseline Item Data M M 1 n1
57 020 CUR Currency of Unit Price O 1
LOOP ID - PO1
73 030 PO3 Unit of Measure O 25
LOOP ID - PO1
74 040 CTP Pricing Information O 1
LOOP ID - PO1

LOOP ID – PO1
LOOP ID – PO1
LOOP ID – PO1
LOOP ID - PID 1000
58 050 PID Product/Item Description O 1
LOOP ID - PID 1000

60 050 PID Product/Item Description - Classification O 1
Details
62 100 REF Reference Identification - Requisition ID O 1
63 100 REF Reference Identification - Supplier ID O 1
LOOP ID - SAC 1
66 130 SAC Shipping Charge O 1
68 135 CUR Currency O Must Use 1
LOOP ID - SAC 22
17 130 SAC Modifications O 1
LOOP ID - SAC 20
60 130 SAC Account Distribution O 1
86 180 FOB F.O.B Related Instructions O 1
663 210 DTM Requested Delivery Date O 1

64 291 TXI Tax Information O 1
LOOP-ID-PO1
103 293 QTY Quantity Information O 1
LOOP-ID-PO1
104 293 QTY Quantity Information O 1
LOOP ID - N9 1
65 330 N9 Reference Identification - URL O 1
LOOP ID - N9 999
67 330 N9 Reference Identification - Comments O 1
LOOP ID – PO1
LOOP ID – PO1
LOOP ID - N9 999

LOOP ID - N1 1
71 350 N1 Ship-To Name O 1
LOOP ID - N1 10
77 350 N1 Name - Detailed Contact Information O 1
LOOP ID - N1 1
58 350 N1 Delivery Address O 1
Summary:
LOOP ID - CTT 1
84 010 CTT Transaction Totals O 1 n2
85 020 AMT Monetary Amount O Must Use 1 n3
86 030 SE Transaction Set Trailer M M 1
Transaction Set Notes

1. PO102 is required.
2. The number of line items (CTT01) is the accumulation of the number of PO1 segments. If used, hash total
(CTT02) is the sum of the value of quantities ordered (PO102) for each PO1 segment.
3. If AMT is used in the summary area, then AMT01 will = TT and AMT02 will indicate total transaction
amount as calculated by the sender.

Segment: ST Transaction Set Header

Position: 010
Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To indicate the start of a transaction set and to assign a control number
Syntax Notes:
Semantic Notes: 1 The transaction set identifier (ST01) is used by the translation routines of the
interchange partners to select the appropriate transaction set definition (e.g., 810
selects the Invoice Transaction Set).
Comments:
Notes: Example: ST*850*0065~
Data Element Summary

Ref. Data Base User
Des. Element Name Attributes Attributes
ST01 143 Transaction Set Identifier Code M ID 3/3 M
Code uniquely identifying a Transaction Set
850 Purchase Order
ST02 329 Transaction Set Control Number M AN 4/9 M
Identifying control number that must be unique within the transaction set functional group
assigned by the originator for a transaction set

Segment: BEG Beginning Segment for Purchase Order

Position: 020
Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To indicate the beginning of the Purchase Order Transaction Set and transmit identifying
numbers and dates
Syntax Notes:
Semantic Notes: 1 BEG05 is the date assigned by the purchaser to purchase order.
Comments:
Notes: Examples:
BEG*00*NE*DO364**20000415~ (new order)

BEG*00*BK*BPO543*yes*20130618~(Blanket Purchase Order)
BEG*05*KN*ERP64390-V2**20020928~ (change order)
BEG*05*IN*ERP64390-V3**20020928~ (change order - internal)
BEG*03*KN*R159116**20020719~ (cancel order)
<OrderRequest>
<OrderRequestHeader>

Ref. Data Base User
BEG01 353 Transaction Set Purpose Code M ID 2/2 M
Code identifying purpose of transaction set
Ariba sends purchase orders as either "new", "update", or "delete". Orders being updated
are replacing a previous order. Some updates are marked as information only
(BEG02='IN').
<OrderRequest>
type (new | update | delete) "new"
00 Original
type="new"
Note that BEG03 can store an order number containing 22

characters in length. Some orders from Ariba Buyer have long
order numbers, REF*PO (1/050) is populated with a second copy
of the order number up to 30 characters.
03 Delete
type="delete"
This is available only if EDI is selected for routing

"Change/Cancel Orders". If the customer sends a "Cancel Order"
from Ariba Buyer, then BEG01='03' and BEG03 contains the order
number to be deleted.
REF*PO (1/050) contains another copy of the purchase order

number, supporting up to 30 characters.
Code 03 for Delete is chosen to parallel the cXML type attribute

value "delete".
05 Replace
type="update"

This is available only if EDI is selected for routing
"Change/Cancel Orders". If the customer submits a change order
through Ariba Buyer, the effect is to copy all of the data and line
items from an existing order and then to create a new order having
the amendments.
The "Change Order" is not a manifest listing of changes, but is

rather a complete replacement of an earlier order. The new order
with the amendments (replacement of the original order) is
typically numbered using the original order number with a suffix,
such as "-V2".
Note that providing this suffix is a recommended practice and

Ariba Buyer or Ariba Network does not send an explicit version
number segment in the "Change Order".
Example:
Original order number:
BEG*00*NE*ERP64390~
New order (replacement of the original order) number:

BEG*05*KN*ERP64390-V2~
The attribute, BEG01='05', indicates that the original purchase

order has been replaced with a new purchase order.
The original order number being replaced is found in REF*PW

(1/050). At this time, Ariba Buyer does not send a revision
number.
Note that BEG03 contains an order number up to 22 characters in

length. Some orders from Ariba Buyer have had longer order
numbers, REF*PO (1/050) is populated with a second copy of the
order number with up to 30 characters.
Although the cXML type attribute value is "update", the code 05

for Replace is used to better represent the action being taken. It is
necessary to completely replace an order previously received.
BEG02 92 Purchase Order Type Code M ID 2/2 M

Code specifying the type of Purchase Order
Determines the purchase order type from Ariba. An order update can be marked as internal
by the customer. Internal orders are identified with BEG02='IN'.
type="new"
DS Dropship
Extrinsic name is OrderType and ExtrinsicData is 'DropShip'
then BEG02 is 'DS'
<Extrinsic name="OrderType">DropShip</Extrinsic>
IN Information Copy
Used with BEG01=05 only to indicate that this order update is for
information only. The buyer has made some internal changes to
their PO. Such a PO update is sent for record-keeping /
accountability only. There are no changes affecting fulfillment.
OrderRequestHeader
isInternalVersion (yes) #IMPLIED
KN Purchase Order
Procurement instrument within the small
purchasing threshold
Used with BEG01='03' or '05' only. When BEG01='00', this field
continues to use 'NE' for backward compatibility.
NE New Order
Used with BEG01='00' only to indicate a new purchase order.
RO Rush Order
Extrinsic name is OrderType and ExtrinsicData is

'RushOrder' then BEG02 is 'RO'
<Extrinsic
name="OrderType">RushOrder</Extrinsic>
BK Blanket Purchase Order
type=blanket
To specify a blanket purchase order
<OrderRequestHeader orderType="blanket" >
RL Release Order
type=release
To specify a release blanket purchase order from an existing
Master Agreement/Contract.
<OrderRequestHeader orderType="release" >

BEG03 324 Purchase Order Number M AN 1/22 M
Identifying number for Purchase Order assigned by the orderer/purchaser
Ariba sends the PO Number from the Buyer.
orderID %string; #REQUIRED
BEG04 328 Release Required X AN 1/30 O
Identifies if the blanket purchase order requires a purchase order before funds can be
released.
<OrderRequestHeader>.
releaseRequired (yes) #IMPLIED
BEG05 373 Date M DT 8/8 M
Date expressed as CCYYMMDD
Ariba sends the PO Date from the Buyer
orderDate %datetime.tz; #REQUIRED

Segment: CUR Currency

Position: 040
Loop:
Level: Heading
Usage: Optional (Must Use)
Max Use: 1
Purpose: To specify the currency (dollars, pounds, francs, etc.) used in a transaction
Syntax Notes: 1 If CUR08 is present, then CUR07 is required.
2 If CUR09 is present, then CUR07 is required.
3 If CUR10 is present, then at least one of CUR11 or CUR12 is required.
Semantic Notes:
Comments: 1 See Figures Appendix for examples detailing the use of the CUR segment.
Usage Notes: Mandatory
Notes: Example: CUR*BY*USD~
Ariba sends the default currency for the order. This currency specifically represents the
total amount of the order found in AMT[3/020]
<OrderRequest>
<Total>
<Money>
currency %isoCurrencyCode; #REQUIRED

Ref. Data Base User
CUR01 98 Entity Identifier Code M ID 2/3 M
Code identifying an organizational entity, a physical location, property or an individual
BY Buying Party (Purchaser)
CUR02 100 Currency Code M ID 3/3 M
Code (Standard ISO) for country in whose currency the charges are specified
These currencies serve as examples; they are not the only codes used. The currency code is
ISO 4217 compliant and Ariba Network writes here whatever is collected from any Ariba
Procurement Platform.
X12 also expects ISO 4217 conformance here, the same as
%isoCurrencyCode;
See http://www.unece.org/trade/rec/rec09en.htm
CAD Canadian Dollars
GBP British Pound
USD US Dollars
XEU European Monetary Coop Fund

Segment: REF Reference Identification

Position: 050
Loop:
Level: Heading
Usage: Optional
Max Use: >1
Purpose: To specify identifying information
Syntax Notes: 1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
Semantic Notes: 1 REF04 contains data relating to the value cited in REF02.
Comments:
Usage Notes: Used/Optional
Ref. Data Base User
REF01 128 Reference Identification Qualifier M ID 2/3 M
Code qualifying the Reference Identification
0L Referenced By
0L is used to override the value of Transport Terms. This can be used
when a custom value of transport term is supplied.
Example:
REF*0L*My Terms~
<TransportTerms value=”Other”>My Terms</ TransportTerms>
Then, REF01 will be 0L and REF02 will be FOB05

PO Purchase Order Number
Example: REF*PO*DO364~
This is available to support purchase order numbers that are greater

than 22 characters. Some purchase orders coming from Ariba Buyer
have long numbers that are truncated in BEG03. The purchase order
number up to 30 characters is shown in this reference.
<OrderRequest>
orderNumber %string; #IMPLIED
PP Purchase Order Revision Number
Example: REF*PP*2~
Reserved for Ariba Buyer to be sending the PO revision number. Ariba

Buyer does not currently support this attribute. This is a placeholder for
it.
PW Prior purchase order number
Used only with BEG01='05' to state the purchase order number being
replaced.

RQ Purchase Requisition Number

Example: REF*RQ*R1492~
The buyer's system requisition id for this entire order. It might be the
same as orderID, and it might not be included at all. Must not be
included if requisitionID is specified at the line item level.
<OrderRequest>
requisitionID %string; #IMPLIED
EZ Electronic Data Interchange Agreement Number

Example :
REF*EZ**blanket-pagreementID1334729026145~
Used only if the order type is "blanket". This identifies the parent
blanket order if the current order is part of a hierarchy.
AH Agreement Number
Example:
REF*AH**BPO-agreementID4~
Identifies the associated agreement corresponding to the release order.

REF02 127 Reference Identification X AN 1/30 O
Reference information as defined for a particular Transaction Set or as specified by the
Reference Identification Qualifier
FOB05 Used to reference FOB05
This value is used only when reporting custom transport terms. All other
REF01 values will have their corresponding REF02 values.
REF03 352 Description X AN 1/80 O
A free-form description to specify the related data elements and their content
<TransportTerms> if value = "Other"
Parent Agreement ID X AN 1/80 O
It identifies the parent blanket order of current order (if any)
Agreement ID X AN 1/80 O
It identifies the agreement corresponding to release order.

Segment: PER Administrative Communications Contact

Position: 060
Loop:
Level: Heading
Usage: Optional
Max Use: 3
Purpose: To identify a person or office to whom administrative communications should be directed
Syntax Notes: 1 If either PER03 or PER04 is present, then the other is required.
2 If either PER05 or PER06 is present, then the other is required.
Semantic Notes:
Comments:
Notes: Example:
PER*BL*Tech Support*TE*18005551313*EM*tech.support@thebuyer.com~
PER*CR*Customer
Service*TE*18005551212*FX*13122842587*EM*customer.service@thebuyer.com~
Contact information from the Order Header is mapped here briefly. Contacts that involve
a PostalAddress or extensive details will appear in an N1 loop. We are limited here to
only three PER segments, so this section is reserved for short and quick contact
information.
All the cXML contact roles are not supported in EDI. In X12 850, the supported roles
are listed in PER01 and N101.
<OrderRequest>
<Contact>
<Email> .. <Phone> .. <Fax>

Ref. Data Base User
PER01 366 Contact Function Code M ID 2/2 M
Code identifying the major duty or responsibility of the person or group named
AE Corporate Purchasing Agent
role="purchasingAgent"
AM Administrator
role="administrator"
BD Buyer Name or Department
BL Technical Department
role="technicalSupport"
CN General Contact
role unspecified
CR Customer Relations
role="customerService"
EB Entered By
role="endUser"
SH Shipper Contact
SR Sales Representative or Department
role="sales"
SU Supplier Contact

PER02 93 Name O AN 1/60 M
Free-form name
Required Name tag.
<Contact>
<Name>
PER03 365 Communication Number Qualifier X ID 2/2 O
Code identifying the type of communication number
EM Electronic Mail
FX Facsimile
TE Telephone
UR Uniform Resource Locator (URL)
PER04 364 Communication Number X AN 1/80 O
Complete communications number including country or area code when applicable
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

Segment: FOB F.O.B. Related Instructions

Position: 80
Loop:
Level: Heading
Usage: Optional
Max Use: >1
Purpose: To specify transportation instructions relating to shipment.
Syntax Notes: 1 If FOB03 is present, then FOB02 is required.
2 If FOB04 is present, then FOB05 is required.
Semantic Notes: 1 FOB01 indicates which party will pay the carrier.
2 FOB02 is the code specifying transportation responsibility location.
3 FOB06 is the code specifying the title passage location.
4 FOB08 is the code specifying the point at which the risk of loss transfers. This may
be different than the location specified in FOB02/FOB03 and FOB06/FOB07.
Comments:
Notes: Example: FOB*DF*ZZ*PriceCondition *ZZ*FAS*ZZ*@TPTransport
description@TODDelivery at the doorstep*ZZ*Account~
This segment allows for Terms of Delivery.
The address information is depicted by a separate N1 segment with entity identifier code
(N101) qualifier as DA.
<OrderRequest>
<TermsOfDelivery>
<TermsOfDeliveryCode value="PriceCondition"/>
<ShippingPaymentMethod value="Account"/>
<TransportTerms value="FreeAlongsideShip/>
<Address>
<Name xml:lang="en-US">SNV</Name>
<PostalAddress name="default">
<Street>123 Anystreet</Street>
<City>Sunnyvale</City>
<State>AL</State>
<PostalCode>35762</PostalCode>
<Country isoCountryCode="US">United States</Country>
</PostalAddress>
</Address>
<Comments xml:lang="en-US" type="Transport">Transport
description</Comments>
<Comments xml:lang="en-US" type="TermsOfDelivery">Delivery at
the doorstep</Comments>
</TermsOfDelivery>

Ref. Data Base User
FOB01 146 Shipment Method of Payment M ID 2/2 M
Description: Code identifying payment terms for transportation charges
DF Account
CA AdvanceCollect
PA AdvancePrepaid
DF CashOnDeliveryServiceChargePaidByConsignee
DF CashOnDeliveryServiceChargePaidByConsignor
CC Collect
CF CollectFreightCreditedToPaymentCustomer
CD CollectOnDelivery
PB CustomerPick-UpOrBackhaul
DF DefinedByBuyerAndSeller
FO FobPortOfCall
HP HalfPrepaid
DF InformationCopy-NoPaymentDue
DF InsuranceCostsPaidByConsignee
DF InsuranceCostsPaidByConsignor
MX Mixed
NR NonRevenue
DF NotSpecified
BP PaidByBuyer
PS PaidBySupplierOrSeller
DF PayableElsewhere
DE PerContract
PU Pickup
PE PrepaidAndSummaryBill
PC PrepaidButChargedToCustomer
PD PrepaidByProcessor
PP Prepaid-BySeller
PL PrepaidLocalCollectOutstate
PO PrepaidOnly
RF ReturnContainerFreightFree
RC ReturnContainerFreightPaidByCustomer
RS ReturnContainerFreightPaidBySupplier
11 Rule11Shipment
NC ServiceFreight-NoCharge
TP ThirdPartyPay
DF Other
WC WeightCondition
FOB02 309 Location Qualifier X ID 1/2 Used
Description: Code identifying type of location
OF Other Unlisted Free On Board (FOB) Point
ZZ Mutually Defined
FOB03 352 Description O AN 1/80 Used
Description: A free-form description to specify the related data elements and their content
<OrderRequest>
<TermsOfDelivery>
Or
<OrderRequest>
<TermsOfDelivery>
<TermsOfDeliveryCode value="Other">MyCode</TermsOfDeliveryCode>
FOB04 334 Transportation Terms Qualifier Code O ID 2/2 Used
Description: Code identifying the source of the transportation terms
ZZ Mutually Defined
FOB05 335 Transportation Terms Code X ID 3/3 Used
Description: Code identifying the trade terms which apply to the shipment transportation
responsibility.
EXW Ex-Works
FCA Free-Carrier
FAS FreeAlongsideShip
FOB FreeOnBoard
CAF CostAndFreight
CIF Cost-InsuranceAndFreight
CPT CarriagePaidTo
CIP Carriage-InsurancePaidTo
DAF DeliveredAtFrontier
DES DeliveredEx-Ship
DEQ DeliveredEx-Quay
DDU DeliveredDutyUnpaid
DDP DeliveredDutyPaid
ZZZ Other
ZZ Mutually Defined
Description: A free-form description to specify the related data elements and their content.
Transport description and terms of delivery description is stored in this element. Both will be
concatenated together. Transport description will be prefixed by @TP and terms of delivery
description will be prefixed by @TOD.
eg: @TPTransport description @TODDelivery at the doorstep
FOB08 54 Risk of Loss Code O ID 2/2 Used
Description: Code specifying where responsibility for risk of loss passes
ZZ Mutually Defined
FOB09 352 Description X AN 1/80 Used
Value of OrderRequest/OrderRequestHeader/TermsOfDelivery/ShippingPaymentMethod

Segment: CSH Sales Requirements

Position: 110
Loop:
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To specify general conditions or requirements of the sale
Syntax Notes: 1 If CSH02 is present, then CSH03 is required.
2 If either CSH06 or CSH07 is present, then the other is required.
3 If either CSH09 or CSH10 is present, then the other is required.
Semantic Notes: 1 CSH03 is the maximum monetary amount value which the order must not exceed.
2 CSH04 is the account number to which the purchase amount is charged.
3 CSH05 is the date specified by the sender to be shown on the invoice.
4 CSH06 identifies the source of the code value in CSH07.
Comments:
Notes: Example: CSH*SC~
Present with CSH01="SC" if the Buyer has specified a "Ship Complete" requirement.
This implies that the Buyer is prepared to wait if necessary for complete fulfillment of an
order. Partial fulfillment will not be accepted.
<OrderRequest>
shipComplete(yes) #IMPLIED
="yes"

Ref. Data Base User
CSH01 563 Sales Requirement Code O ID 1/2 O
Code to identify a specific requirement or agreement of sale
SC Ship Complete

Segment: SAC Shipping Charges

Position: 120
Loop: SAC Optional
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To request or identify a service, promotion, allowance, or charge; to specify the amount
or percentage for the service, promotion, allowance, or charge
Syntax Notes: 1 At least one of SAC02 or SAC03 is required.
2 If either SAC03 or SAC04 is present, then the other is required.
5 If SAC11 is present, then SAC10 is required.
6 If SAC13 is present, then at least one of SAC02 or SAC04 is required.
Semantic Notes: 1 If SAC01 is "A" or "C", then at least one of SAC05, SAC07, or SAC08 is required.
2 SAC05 is the total amount for the service, promotion, allowance, or charge.
If SAC05 is present with SAC07 or SAC08, then SAC05 takes precedence.
3 SAC08 is the allowance or charge rate per unit.
4 SAC10 and SAC11 is the quantity basis when the allowance or charge quantity is
different from the purchase order or invoice quantity.
SAC10 and SAC11 used together indicate a quantity range, which could be a dollar
amount that is applicable to service, promotion, allowance, or charge.
5 SAC13 is used in conjunction with SAC02 or SAC04 to provide a specific reference
number as identified by the code used.
6 SAC14 is used in conjunction with SAC13 to identify an option when there is more
than one option of the promotion.
7 SAC16 is used to identify the language being used in SAC15.
Comments: 1 SAC04 may be used to uniquely identify the service, promotion, allowance, or
charge. In addition, it may be used in conjunction to further the code in SAC02.
2 In some business applications, it is necessary to advise the trading partner of the
actual dollar amount that a particular allowance, charge, or promotion was based on
to reduce ambiguity. This amount is commonly referred to as "Dollar Basis
Amount". It is represented in the SAC segment in SAC10 using the qualifier "DO" -
Dollars in SAC09.
Notes: Example: SAC*C*G830***4680********21428339882**Fed-Ex 2 day*en~
In the header section, this represents a shipping cost in the order to the supplier. There
can be one of these for the entire order, or one per line item. This context represents one
for the order.
<OrderRequest>
<Shipping>

Ref. Data Base User
SAC01 248 Allowance or Charge Indicator M ID 1/1 M
Code which indicates an allowance or charge for the service specified
C Charge
SAC02 1300 Service, Promotion, Allowance, or Charge Code X ID 4/4 O
Code identifying the service, promotion, allowance, or charge
G830 Shipping and Handling
SAC05 610 Amount O N2 1/15 M
Monetary amount
<Shipping>
<Money>
#PCDATA
SAC13 127 Reference Identification X AN 1/30 O
Reference information as defined for a particular transaction set or as specified by the
SAC15 352 Description X AN 1/80 M
Ariba Network can only accept one Description here. cXML allows for a ShortName to be
included with the Description. If the Description text is longer than 80 characters, and a
ShortName is available, then Ariba Network will map the ShortName here.
<Shipping>
<Description>
#PCDATA .. <ShortName>
SAC16 819 Language Code O ID 2/3 M
Code designating the language used in text, from a standard code list maintained by the
International Standards Organization (ISO 639)
<Shipping>
<Description>
xml:lang %isoLangCode; #REQUIRED


Position: 125
Loop: SAC Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:

Ref. Data Base User
See Note on Currency Codes with CUR[1/040].
Currency codes shown here are examples. Any ISO4217 code can be sent.
http://www.unece.org/trade/rec/rec09en.htm
GBP British Pound
USD US Dollars

Segment: SAC Modifications

Position: 120
Loop: SAC Optional
Level: Heading
Usage: Optional
Max Use: 1
Dollars in SAC09.
Notes: Example: SAC*N**ZZ*F050*2200**********Original Price*en~
CUR*BY*CAD~
SAC*A**ZZ*I530**6*5********Volume Discount*en~
CUR*BY*CAD*****196*20050504*101500*197*20050701*101500~
In the header section, this represents a modification in the order to the supplier. There can
be multiple modifications. Maximum number of modifications supported is 11.. This is an
example of a modification in an order.
<OrderRequest>
<Total>
<Money>……..
<Modifications>
<Modification>
<OriginalPrice>
<Money currency="CAD">22.00</Money>
</OriginalPrice>
<AdditionalDeduction>
<DeductionPercent percent="5"/>
</AdditionalDeduction>
<ModificationDetail endDate="2005-07-01T10:15:00-08:00" name="Volume
Discount" startDate="2005-05-04T10:15:00-08:00">
<Description xml:lang="en-US">Volume Discount</Description>

</ModificationDetail>
</Modification>

Ref. Data Base User
C Charge
A Allowance
N No Allowance or Charge
SAC03 559 Agency Qualifier Code X ID 2/2 M
Code identifying the agency assigning the code values
ZZ Mutually Defined
SAC04 1301 Agency Service, Promotion, Allowance, or Charge M AN 1/10 M
Code
F050 Other
H970 Allowance
B660 Contract Allowance
C310 Discount
C300 Discount-Special
I530 Volume Discount
A040 Access Charge
A050 AccountNumberCorrectionCharge
A060 AcidBattery
A170 Adjustment
A960 Carrier
A520 Charge
D240 Freight
D180 FreightBasedOnDollarMinimum
D500 Handling
D980 Insurance
G580 Royalties
G821 Shipping
G830 ShippingAndHandling
Description: Monetary amount
OriginalPrice/Money (For Original Price)
AdditionalCost/Money (For Charge)
AdditionalDeduction/DeductionAmount/Money (For Allowances)
SAC06 378 Allowance/Charge Percent Qualifier X ID 1/1 O
Description: Code indicating on what basis allowance or charge percent is calculated
6 Price Based Amount
SAC07 332 Percent X R 1/6 O
Description: Percent expressed as a percent

SAC14 770 Option Number O AN 1/20 O

Description: A unique number identifying available promotion or allowance options when more
than one is offered.
1 Used if SAC05 value is amount
2 Used if SAC05 value is price
Description: Code designating the language used in text, from a standard code list maintained
by the International Standards Organization (ISO 639).
<ModificationDetail endDate="2005-07-01T10:15:00-08:00" name="Volume Discount"
startDate="2005-05-04T10:15:00-08:00">


Position: 125
Loop: SAC Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
Notes: Example 1: CUR*BY*USD~
Example 2: CUR*BY*CAD*****196*20050504*101500*197*20050701*101500~

Ref. Data Base User
GBP British Pound
USD US Dollars
CUR07 374 Date/Time Qualifier X ID 3/3 O
Description: Code specifying type of date, time, or both date and time
196 Start
CUR08 373 Date O DT 8/8 O
Description: Date expressed as CCYYMMDD
CUR09 337 Time O TM 4/8 O
Description: Time expressed in 24-hour clock time as follows: HHMM, HHMMSS, HHMMSSD,
or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59)
and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and
DD = hundredths (00-99)


All valid standard codes are used. (Total Codes: 1112)
197 End
CUR11 373 Date X DT 8/8 O
CUR12 337 Time X TM 4/8 O
Description: Time expressed in 24-hour clock time as follows: HHMM, HHMMSS, HHMMSSD,
or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59)
and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and
DD = hundredths (00-99)

Segment: ITD Terms of Sale/Deferred Terms of Sale

Position: 130
Loop:
Level: Heading
Usage: Optional
Max Use: >1
Purpose: To specify the payment terms
Syntax Notes: 1 If ITD03 is present, then at least one of ITD04 ITD05 or ITD13 is required.
2 If ITD08 is present, then at least one of ITD04 ITD05 or ITD13 is required.
3 If ITD09 is present, then at least one of ITD10 or ITD11 is required.
Semantic Notes: 1 ITD15 is the percentage applied to a base amount used to determine a late payment
charge.
Comments: 1 If the code in ITD01 is "04", then ITD07 or ITD09 is required and either ITD10 or
ITD11 is required; if the code in ITD01 is "05", then ITD06 or ITD07 is required.
Notes: Payment Term information from the Order Header is mapped here briefly.
Net terms will be mapped to ITD*05..

Example:
<OrderRequest>
...
<PaymentTerm payInNumberOfDays="45"></PaymentTerm>
This information will be mapped to
ITD*05*03*****45********0
Discount Terms will be mapped to ITD*52.....

<OrderRequest>
...
<PaymentTerm payInNumberOfDays="30">
<Discount>
<DiscountPercent percent="15"/>
</Discount>
</PaymentTerm>
ITD*52*03*15**30

Ref. Data Base User
ITD01 336 Terms Type Code O ID 2/2 O
Code identifying type of payment terms
05 Discount Not Applicable
52 Discount with Prompt Pay
ITD02 333 Terms Basis Date Code O ID 1/2 O
Code identifying the beginning of the terms period
3 Invoice Date
ITD03 338 Terms Discount Percent O R 1/6 O
Terms discount percentage, expressed as a percent, available to the purchaser if an invoice
is paid on or before the Terms Discount Due Date
ITD04 370 Terms Discount Due Date X DT 8/8 O
Date payment is due if discount is to be earned expressed in format CCYYMMDD
ITD05 351 Terms Discount Days Due X N0 1/3 O
Number of days in the terms discount period by which payment is due if terms discount is
earned
ITD07 386 Terms Net Days O N0 1/3 O
Number of days until total invoice amount is due (discount not applicable)
ITD08 362 Terms Discount Amount O N2 1/10 O
Total amount of terms discount
ITD15 954 Percent O R 1/10 O
Percentage expressed as a decimal

Segment: DTM Date/Time Reference

Position: 150
Loop:
Level: Heading
Usage: Optional
Max Use: 10
Purpose: To specify pertinent dates and times
Syntax Notes: 1 At least one of DTM02 DTM03 or DTM05 is required.
2 If DTM04 is present, then DTM03 is required.
3 If either DTM05 or DTM06 is present, then the other is required.
Semantic Notes:
Comments:

Ref. Data Base User
DTM01 374 Date/Time Qualifier M ID 3/3 M
Code specifying type of date or time, or both date and time
004 Purchase Order
DTM02 373 Date X DT 8/8 O
DTM03 337 Time X TM 4/8 O
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD,
or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-
59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9)
and DD = hundredths (00-99)
DTM04 623 Time Code O ID 2/2 O
Code identifying the time. In accordance with International Standards Organization
standard 8601, time can be specified by a + or - and an indication in hours in relation to
Universal Time Coordinate (UTC) time; since + is a restricted character, + and - are
substituted by P and M in the codes that follow
Refer to 004010 Data Element Dictionary for acceptable code values.


Position: 150
Loop:
Level: Heading
Usage: Optional
Max Use: 10
Purpose: To specify effective dates and times
Semantic Notes:
Comments:
Example : DTM*007*20070725*000000*PD~

Ref. Data Base User
007 Effective Date

Segment: DTM Expiration Date/Time Reference

Position: 150
Loop:
Level: Heading
Usage: Optional
Max Use: 10
Purpose: To specify effective dates and times
Semantic Notes:
Comments:
Example : DTM*036*20081231*235959*PT~

Ref. Data Base User
036 Expiration Date

Segment: TXI Tax Information

Position: 285
Loop:
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To specify tax information
Syntax Notes: 1 At least one of TXI02 TXI03 or TXI06 is required.
2 If either TXI04 or TXI05 is present, then the other is required.
3 If TXI08 is present, then TXI03 is required.
Semantic Notes: 1 TXI02 is the monetary amount of the tax.
2 TXI03 is the tax percent expressed as a decimal.
3 TXI07 is a code indicating the relationship of the price or amount to the associated
segment.
Comments:
Notes: Example: TXI*TX*27.18~
cXML supplies tax information with an amount and a description. Ariba sends the tax
amount here. Taxes can be present at both the header and line item levels. Taxes at the
line item level are used to show a per line item breakdown.
<OrderRequest>
<Tax>

Ref. Data Base User
TXI01 963 Tax Type Code M ID 2/2 M
Code specifying the type of tax
TX All Taxes
Total of all applicable taxes
TXI02 782 Monetary Amount X R 1/18 M
Monetary amount

Segment: N9 Reference Identification - Payment of Purchase Order

Position: 295
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To transmit identifying information as specified by the Reference Identification Qualifier
Syntax Notes: 1 At least one of N902 or N903 is required.
2 If N906 is present, then N905 is required.
Semantic Notes: 1 N906 reflects the time zone which the time reflects.
2 N907 contains data relating to the value cited in N902.
Comments:
Notes: Example: N9*PSM*4510294818443233*Visa - Purchases~
Procurement card information is here. The expiry date goes in the DTM segment with
special formatting.
<OrderRequest>
<Payment>

Ref. Data Base User
N901 128 Reference Identification Qualifier M ID 2/3 M
PSM Credit Card
N902 127 Reference Identification X AN 1/30 M
<PCard>
number %number; #REQUIRED
N903 369 Free-form Description X AN 1/45 O
Free-form descriptive text
<PCard>
name %string; #IMPLIED


Position: 297
Loop: N9 Optional
Level: Heading
Max Use: 1
Semantic Notes:
Comments:
Notes: Example: DTM*036****UN*0432~
(This card expires in April 2032)

Procurement card expiry date is here. The expiration date is often used as a check on the
credit card number. They are traditionally stored as YYMM, but not necessarily. cXML
1.1 does not specify the syntax of the expiry date, so it will usually be "Unstructured"
(DTM05="UN"). Supplies should be able to submit DTM06 "as is" for verification
purposes.

Ref. Data Base User
036 Expiration
Date coverage expires
DTM05 1250 Date Time Period Format Qualifier X ID 2/3 M
Code indicating the date format, time format, or date and time format
Normally this will be "UN". If cXML specifies that the expiry date is specifically YYMM,
then DTM05 will be "YM".
UN Unstructured
YM Year and Month Expressed in Format YYMM
DTM06 1251 Date Time Period X AN 1/35 M
Expression of a date, a time, or range of dates, times or dates and times
Expiry date as YYMM
<PCard>
expiration %date; #REQUIRED

Segment: N9 Reference Identification - Comments

Position: 295
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1
Comments:
Notes: Example: N9*L1*Comment*en~
cXML provides one block of comments at the header level, which is mapped here. cXML
also has the ability to include an attachment here, but attachments are not mapped to X12
<OrderRequest>
<Comments>

Ref. Data Base User
L1 Letters or Notes
Always set to "Comment". Ariba writes a constant here because X12 requires that either
N902 or N903 is used, and the description is optional in cXML. By writing a constant,
Ariba avoids any compliance issues with X12.
This is the language code attribute sent by cXML to describe the language used for the
comment. The code is ISO 639 compliant. Note that this code is optional and can be
supplied in lower case.
Comments
xml:lang %xmlLangCode; #IMPLIED

Segment: MSG Message Text

Position: 300
Loop: N9 Optional
Level: Heading
Max Use: 1000
Purpose: To provide a free-form format that allows the transmission of text information
Syntax Notes: 1 If MSG03 is present, then MSG02 is required.
Semantic Notes: 1 MSG03 is the number of lines to advance before printing.
Comments: 1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
2 If MSG02 is "AA - Advance the specified number of lines before print" then MSG03
is required.
Notes: Example: MSG*Be sure printer ink cartridges are properly sealed to avoid spillage.~
The actual comment text. The X12 mapping will try to preserve the line breaks from the
cXML as best it can. Each line break will automatically incur a new MSG segment, with
the exception of a blank line. If one line goes over the capacity of MSG01 then the line is
word-broken and a new MSG segment is created to continue the line. If the number of
lines exceed the occurrence limit of MSG, then the remainder of the comment text will be
truncated.
Any imbedded Attachments will be dropped. However, Ariba might include a text
representation that it is present. For example:
MSG*See the attached word document. [Attachment "specs.doc"]~

<Comments>
#PCDATA
<Attachment>

Ref. Data Base User
MSG01 933 Free-Form Message Text M AN 1/264 M
Free-form message text
MSG02 934 Printer Carriage Control Code X ID 2/2 O
A field to be used for the control of the line feed of the receiving printer
If a line was broken by the limitation of MSG01, and a new segment is created for
continuation, then MSG02="LC", otherwise it is not used.
LC Line Continuation

Segment: N9 Reference Identification - Extrinsics

Position: 295
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1
Comments:
Notes: Example: N9*ZZ**Packing Instructions~
If the PO has attachment, then attachment detail is mapped to N9 with N904 as

AttachmentOnline
Example: N9*ZZ**AttachmentOnline
Extrinsic information is well-formed XML provided by the buyer to define extra

information outside the scope of cXML's specifications. The content here is user-defined,
and in X12 should be regarded as comment information.
There are three rules to consider when looking at extrinsic information:

1. It is defined by the specific implementation of the Buyer and the Buyer's ERP system
to any Ariba B2B Procurement Platform. Two different Buyers might send the same
information in two distinct ways at this level. You cannot depend on the precise format.
2. Neither Ariba nor cXML control the exact content and formatting of Extrinsics. The
implementation is user-defined, and popular implementations thereof often migrate their
way into future versions of cXML. Treat this as comment information.
3. While every effort is made to preserve the integrity of Extrinsic information in the X12
implementation, it simply cannot be guaranteed. Non-printable characters cannot be
transported and any occurrences of our X12 control characters (i.e.. SegTerm, ElemSep,
CompSep) MUST BE TRANSLATED. Supplier side EDI Implementers should make
their respective departments aware of this.
<OrderRequest>
<Extrinsic>

Ref. Data Base User
ZZ Mutually Defined
Required name attribute to identify the Extrinsic.
<Extrinsic>
name %string; #REQUIRED


Position: 300
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1000
is required.
Notes: Example: MSG*<Packing><UnitsPerCarton>512</UnitsPerCarton></Packing>~
If the PO has attachment, then attachment URL is mapped to MSG. Suppliers must log in
to view attachments in their AN online Inboxes.
Example:
MSG*https://service.ariba.com/Supplier.aw/ad/orderDetail?community=2&poDocId=20
265850&anp=Ariba
MSG carries the actual Extrinsic data as accurately as possible. Where new lines are
started in cXML, new MSG segments are created (except for blank lines) in order to
preserve its integrity. If a line exceeds the capacity of MSG01, then a new MSG segment
is created and the Extrinsic text continues.
<Extrinsic>
ANY

Ref. Data Base User
Actual Extrinsic text.

If a line from cXML is broken by MSG01's limitation, a new MSG segment is created with
MSG02="LC"


Position: 295
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1
Comments:
Notes: You can use this extrinsic for blanket purchase orders with masked values. Buyers can
mask amount values in the blanket purchase order they send a supplier. If the blanket
purchase order contains masked values, then this extrinsic stores the “hideAmount”
value.
Example: N9*ZZ**hideAmount~
<OrderRequest>
< OrderRequestHeader >
<Extrinsic>
If “hideAmount” is available, the values in the Amount fields display 0.00.
For more information on the fields that a buyer can mask, see the section Masking Values
in Blanket Purchase Orders in the Ariba cXML Solutions Guide.

Ref. Data Base User
ZZ Mutually Defined
<Extrinsic>


Position: 300
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1000
is required.
Notes: Example: MSG*Yes~
Use this extrinsic for blanket purchase orders with masked values. The MSG element
stores the data available in the Extrinsic element. If the “hideAmount” value is present in
the extrinsic, the Message element displays the value “Yes.”
MSG*Yes~

Ref. Data Base User


Position: 295
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1
Comments:
mask unit price values in the blanket purchase order they send a supplier. If the blanket
purchase order contains masked values, then this extrinsic stores the “hideUnitPrice”
value. If the extrinsic is specified at the header level, the values are masked in the header-
level and all the line items of the blanket purchase order.
Example: N9*ZZ**hideUnitPrice ~
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<Extrinsic>
If “hideUnitPrice” is available, the values in the unit price fields display 0.00.

Ref. Data Base User
ZZ Mutually Defined
<Extrinsic>


Position: 300
Loop: N9 Optional
Level: Heading
Usage: Optional
Max Use: 1000
is required.
Notes: Example: MSG*Yes~
Use this extrinsic for blanket purchase orders with masked values. The MSG element
stores the data available in the Extrinsic element. If the “hideUnitPrice” value is present
in the extrinsic, the Message element displays the value “Yes.”
Example: N9*ZZ** hideUnitPrice~

MSG*Yes~

Ref. Data Base User

MSG02="LC"

Segment: N1 Bill-To Name

Position: 310
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To identify a party by type of organization, name, and code
2 If either N103 or N104 is present, then the other is required.
Semantic Notes:
Comments: 1 This segment, used alone, provides the most efficient method of providing
organizational identification. To obtain this efficiency the "ID Code" (N104) must
provide a key to the table maintained by the transaction processing party.
2 N105 and N106 further define the type of entity in N101.
Notes: Example: N1*BT*Corporate Office*92*001~
Header Level Bill-To Address Information
This is mandatory and sent only at the header level.

<OrderRequest>
<BillTo>

Ref. Data Base User
N101 98 Entity Identifier Code M ID 2/3 M
BT Bill-to-Party
N102 93 Name X AN 1/60 M
Free-form name
Name associated by Buyer to this BillTo Address
<BillTo>
<Address>
<Name>
N103 66 Identification Code Qualifier X ID 1/2 O
Code designating the system/method of code structure used for Identification Code (67)
92 Assigned by Buyer or Buyer's Agent
N104 67 Identification Code X AN 2/80 O
Code identifying a party or other code
Address ID sent by the Buyer to identify this Bill-To, if it is present.
<BillTo>
<Address>
addressID %string; #IMPLIED

Segment: N2 Additional Name Information

Position: 320
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Purpose: To specify additional names or those longer than 35 characters in length
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example:
N2*Roxanne Barber*Accounts Payable~

N2*The Buyer, Inc.~
In a PostalAddress, cXML considers DeliverTo to be optional, but can send many. Ariba
implements up to the first four here: two Name elements across two N2 segments.
The first two iterations of DeliverTo will occupy the first N2 segment and the third and
fourth iterations, if present, will occupy the second N2. Any further DeliverTo iterations
will be ignored.
<BillTo>
<Address>
<PostalAddress>
<DeliverTo>

Ref. Data Base User
N201 93 Name M AN 1/60 M
Free-form name
N202 93 Name O AN 1/60 O
Free-form name

Segment: N3 Address Information

Position: 330
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Purpose: To specify the location of the named party
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example: N3*1 Buyer Parkway~
Street address information.
cXML requires one <Street> tag but can send many. Like the N2 above, Ariba Network
implements up to the first four: two elements across two segments.
<BillTo>
<Address>
<PostalAddress>
<Street>

Ref. Data Base User
N301 166 Address Information M AN 1/55 M
Address information
N302 166 Address Information O AN 1/55 O
Address information

Segment: N4 Geographic Location

Position: 340
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To specify the geographic place of the named party
Syntax Notes: 1 If N406 is present, then N405 is required.
Semantic Notes:
Comments: 1 A combination of either N401 through N404, or N405 and N406 may be adequate to
specify a location.
2 N402 is required only if city name (N401) is in the U.S. or Canada.
Notes: Example: N4*Chicago*IL*35101*US~
Geographic information from the PostalAddress
cXML guarantees a City and Country. The State or Province code and the Postal Code
are optional.
<BillTo>
<Address>
<PostalAddress>
<City> .. <State> .. <PostalCode> .. <Country>

Ref. Data Base User
N401 19 City Name O AN 2/30 M
Free-form text for city name
N402 156 State or Province Code O ID 2/2 O
Code (Standard State/Province) as defined by appropriate government agency
http://www.usps.gov/ncsc/lookups/abbr_state.txt
http://www.canadapost.ca/CPC2/addrm/addrguide/prov_symbols.html
N403 116 Postal Code O ID 3/15 O
Code defining international postal zone code excluding punctuation and blanks (zip code
for United States)
A US Zip Code can be five or nine digits. There will not be a separator present if the full
nine digit code is sent. A Canadian Postal Code is always formatted "A9A9A9". There will
not be a separator in the middle.
N404 26 Country Code O ID 2/3 M
Code identifying the country
Country code is ISO-3166 compliant. You can see a list here along with their respective
currency codes:
<Country>
isoCountryCode %isoCountryCode; #REQUIRED


Position: 360
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: >1
Semantic Notes:
Comments:
Notes: Example:
PER*AP*AP Purchases
(Roxanne)*TE*13125551111*FX*13125552222*EM*Roxanne.Barber@thebuyer.com~
Contact information of Telephone, Fax, Email, and URL. cXML requires none, and only
one of each is allowed.
Each contact tag carries a name to identify itself. Where possible, Ariba Network groups
those with the same name together. If all four pieces are supplied, or if they carry distinct
names, then multiple PER segments are required.
The telephone number supplied with either Phone or Fax is broken down by components
by cXML. The number will be formatted appropriately here.
Note that a URL will be limited to the maximum length of the Communication Number
element.
<ShipTo>
<Address>
<Phone> .. <Fax> .. <Email> .. <URL>

Ref. Data Base User
AP Accounts Payable Department
PER02 93 Name O AN 1/60 O
Free-form name
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

EM Electronic Mail
FX Facsimile
TE Telephone

Segment: N1 Ship-To Name

Position: 310
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
Notes: Example: N1*ST*San Jose Office*92*152~
Header Level Ship-To Address Information
This is optional at the header level. Ariba will send ShipTo Information either at the
header OR at the line item level, but not both. If it is absent here then it is required at the
line item level.
<OrderRequest>
<ShipTo>

Ref. Data Base User
ST Ship To
N102 93 Name X AN 1/60 M
Free-form name
Name associated by Buyer to this ShipTo Address
<ShipTo>
<Address>
<Name>
Address ID sent by the Buyer to identify this ShipTo, if it is present.
<ShipTo>
<Address>
addressID %string; #IMPLIED


Position: 320
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example:
N2*Maria Valenzuela*B1-2462~
N2*The Buyer, Inc.~
implements up to the first four here: two Name elements across two N2 segments.
will be ignored.
<ShipTo>
<Address>
<PostalAddress>
<DeliverTo>

Ref. Data Base User
N201 93 Name M AN 1/60 M
Free-form name
N202 93 Name O AN 1/60 O
Free-form name


Position: 330
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example:
N3*1500 Buyer Way~

<ShipTo>
<Address>
<PostalAddress>
<Street>

Ref. Data Base User
Address information
Address information


Position: 340
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
specify a location.
Notes: Example: N4*San Jose*CA*951103492*US~
are optional.
<ShipTo>
<Address>
<PostalAddress>

Ref. Data Base User
for United States)
nine digit code is sent. Canadian postal codes are six characters with no space.
currency codes:
<Country>


Position: 360
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: >1
Semantic Notes:
Comments:
Notes: Example: PER*RE*Maria -
Primary*TE*14085551414*FX*14085551616*EM*Maria.Valenzuela@thebuyer.com~
element.
<ShipTo>
<Address>

Ref. Data Base User
RE Receiving Contact
Free-form name
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

EM Electronic Mail
FX Facsimile
TE Telephone

Segment: TD5 Carrier Details (Routing Sequence/Transit Time)

Position: 390
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: >1
Purpose: To specify the carrier and sequence of routing and provide transit time information
Syntax Notes: 1 At least one of TD502, TD504, TD505, TD506 or TD512 is required.
2 If TD502 is present, then TD503 is required.
Semantic Notes: 1 TD515 is the country where the service is to be performed.

Comments:
Notes: Example: TD5**ZZ*12345*J***ZZ*Instructions~
Transport information containing Route method, Shipping Contract number and Shipping
instructions.
Multiple (max 12) transport information is allowed.
<ShipTo>
<TransportInformation>
<Route method="motor"/>
<ShippingContractNumber>12345</ShippingContractNumber>
<ShippingInstructions>
<Description xml:lang="en-US">Instructions</Description>
</ShippingInstructions>
</TransportInformation>

Ref. Data Base User
TD502 66 Identification Code Qualifier X ID 1/2 R

Description: Code designating the system/method of code structure used for Identification
Code (67)
ZZ Mutually Defined
TD503 67 Identification Code X AN 2/80 R
Description: Code identifying a party or other code
<ShipTo>
<ShippingContractNumber>12345</ShippingContractNumber>
TD504 91 Transportation Method/Type Code X ID O
1/2
Description: Code specifying the method or type of transportation for the shipment
<ShipTo>
<Route method="motor"/>
A air
J motor
R rail
S Ship

TD507 309 Location Qualifier O ID R

1/2
ZZ Mutually Defined
TD508 310 Location Identifier X AN R
1/30
Description: Code which identifies a specific location
<ShipTo>
<ShippingInstructions>
<Description xml:lang="en-US">Instructions</Description>

Segment: TD4 Carrier Details (Special Handling, or Hazardous Materials, or Both)

Position: 410
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Purpose: To specify transportation special handling requirements, or hazardous materials
information, or both
Syntax Notes: 1 At least one of TD401, TD402 or TD404 is required
Semantic Notes: 1 TD405 identifies if a Material Safety Data Sheet (MSDS) exists for this product. A
"Y" indicates an MSDS exists for this product; an "N" indicates an MSDS does not
exist for this product.
Comments:

Notes: Example: TD4*ZZZ***UPS@domainXYZ~
This section allows for carrier Identifier and domain information.
<ShipTo>
<CarrierIdentifier domain="XYZ">UPS</CarrierIdentifier>

Ref. Data Base User
TD401 152 Special Handling Code X ID 2/3 Used

Description: Code specifying special transportation handling instructions
ZZZ Mutually Defined
TD404 352 Description X AN 1/80 Used
Concat <CarrierIdentifier >@domain<CarrierIdentifier domain>
UPS@domainXYZ

Segment: N1 Detailed Contact Information - Name

Position: 310
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
Notes: Example: N1*NG*Administration~
This section of N1 allows for detailed contact information, beyond what can be specified
in the PER[1/060] at the top, which is only intended for brief information.
Any contact that includes a PostalAddress must be specified here, along with contacts
requiring a variety of name tags for a specified role.
<OrderRequest>
<Contact>
<Name>

Ref. Data
Des. Element Name Attributes
N101 98 Entity Identifier Code M ID 2/3
Code identifying an organizational entity, a physical location, property or an
individual
40 Receiver
Entity to accept transmission
role="correspondent"
60 Salesperson
Identification of individual that sold the product e.g. SSN,
salesperson id, etc.
role="sales"
A9 Sales Office
A business entity whose main activity is, or a location at
which, the sale of goods or services takes place
role="buyerCorporate"
CA Carrier
role="carrierCorporate"
EN End User
role="endUser"
KY Technical Office

L5 Contact
role unspecified
NG Administrator
PD Purchaser's Department Buyer
RI Remit To
role="remitTo"
SE Selling Party
role="supplierAccount"
SF Ship From
role="shipFrom"
SO Sold To If Different From Bill To
role="soldTo"
SU Supplier/Manufacturer
role="supplierCorporate"
N102 93 Name X AN 1/60
Free-form name


Position: 320
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example: N2*Elmira Gulch*2nd floor~
Ariba Network accepts up to four DeliverTo tags from cXML: two elements across two
segments.
<Contact>
<PostalAddress>
<DeliverTo>

Ref. Data Base User
N201 93 Name M AN 1/60 M
Free-form name
N202 93 Name O AN 1/60 O
Free-form name


Position: 330
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: N3*The Buyer, Inc.*1 Buyer Parkway~
In cXML, Street is required if PostalAddress is present. Ariba Network maps a maximum
of four Street tags here: two elements across two segments.
<Contact>
<PostalAddress>
<Street>

Ref. Data Base User
Address information
Address information


Position: 340
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
specify a location.
Notes: N4*Chicago*IL*34592*US~
Geographic part of the address
<Contact>
<PostalAddress>

Ref. Data Base User
<Contact>
<PostalAddress>
<City>
<Contact>
<PostalAddress>
<State>
for United States)
<Contact>
<PostalAddress>
<PostalCode>
currency codes:
<Contact>
<PostalAddress>
<Country>


Position: 360
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: >1
Semantic Notes:
Comments:
Notes: Example:
PER*AM*Elmira - Admin*TE*18005551515*EM*Elmira.Gulch@thebuyer.com~
PER*AM**TE*18005552727*UR*http://admin.thebuyer.com~
Several PER's are allowed. The contact communications fragments are merged according
to their name attributes. Those with the same name are placed in the same segment.
<OrderRequest>
<Contact>
<Email> .. <Phone> .. <Fax> .. <URL>

Ref. Data Base User
The code used here depends on the role specified in N101.

AM Administrator
BD Buyer Name or Department
CN General Contact
role unspecified
EB Entered By
role="endUser"
SH Shipper Contact
role="sales"
SU Supplier Contact
Free-form name
<Contact>

EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

Segment: N1 Delivery Address

Position: 310
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
Comments: 1 This segment when used alone provides the most efficient method of providing
Notes: Example: N1*DA*SNVS~
This section of N1 allows entering the delivery address from terms of delivery.
<OrderRequest>
<TermsOfDelivery>
<Address>

Ref. Data
DA Delivery Address
N102 93 Name X AN 1/60
Free-form name


Position: 330
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: N3*123 Anystreet~
In cXML, Street is required if PostalAddress is present.
<OrderRequest>
<TermsOfDelivery>
<Address>

Ref. Data Base User
Address information


Position: 340
Loop: N1 Optional
Level: Heading
Usage: Optional
Max Use: 1
Semantic Notes:
specify a location.
Notes: N4*Sunnyvale*AL*35762*US~
<OrderRequest>
<TermsOfDelivery>
<Address>
<State>AL</State>
</PostalAddress>
</Address>

Ref. Data Base User
<OrderRequest>
<TermsOfDelivery>
<Address>
<OrderRequest>
<TermsOfDelivery>
<Address>
<State>AL</State>
for United States)
<OrderRequest>
<TermsOfDelivery>
<Address>


Country code is ISO-3166 compliant. For a list of country codes and their respective
currency codes, see :
<OrderRequest>
<TermsOfDelivery>
<Address>

Segment: PO1 Baseline Item Data

Position: 010
Loop: PO1 Mandatory
Level: Detail
Usage: Mandatory
Max Use: 1
Purpose: To specify basic and most frequently used line item data
Syntax Notes: 1 If PO103 is present, then PO102 is required.
2 If PO105 is present, then PO104 is required.
3 If either PO106 or PO107 is present, then the other is required.
Semantic Notes:
Comments: 1 See the Data Element Dictionary for a complete list of IDs.
2 PO101 is the line item identification.
3 PO106 through PO125 provide for ten different product/service IDs per each item.
For example: Case, Color, Drawing No., U.P.C. No., ISBN No., Model No., or SKU.
Notes: Example: PO1*5*25*RO*.64**VP*26409*MG*YZ323*MF*3M*C3*31201512~
Each <ItemOut> in the cXML <OrderRequest> incurs a PO1 loop. The minimum
information is the Quantity Ordered and the Supplier Part ID. You can receive that in a
single PO1 segment and nothing more. Additional details are optionally supplied by the
Buyer.
<OrderRequest>
<ItemOut>

Ref. Data Base User
PO101 350 Assigned Identification O AN 1/20 O
Alphanumeric characters assigned for differentiation within a transaction set
Position (counting from 1) of this item in an order. Used to maintain a reference between
items in create and update OrderRequest documents. Its use is recommended in
OrderRequest documents and no two lines can have the same lineNumber.
<ItemOut>
lineNumber %uint; #IMPLIED
Note: The maximum value for a line number in a purchase order Ariba Network supports is
2,147,483,647. Ensure that the number of characters does not exceed 10.
PO102 330 Quantity Ordered X R 1/15 O

Quantity ordered
Number of units being ordered by the Buyer.
<ItemOut>
quantity %r8; #REQUIRED
PO103 355 Unit or Basis for Measurement Code O ID 2/2 O
Code specifying the units in which a value is being expressed, or manner in which a
measurement has been taken
The UnitOfMeasure is required if ItemDetail is supplied by the Buyer. If it is not specified
in the cXML OrderRequest, Ariba does not map it. If it is not specified then the Buyer is
asserting that the Unit of Measure is not relevant to the item being ordered, and they simply
wish to buy (quantity) "whatevers".

All X12 codes are allowed here. The code from cXML is UN/CEFACT compliant, and is
translated by Ariba Network to an X12 equivalent.
<ItemOut>
<ItemDetail>
<UnitOfMeasure>
PO104 212 Unit Price X R 1/17 O
Price per unit of product, service, commodity, etc.
This is the price per unit that the Buyer is prepared to pay. It is required only if ItemDetail
is supplied by the Buyer. If it is not supplied, then a supplier will be expected to honour a
previously agreed upon price; for example, a price advertised in a catalogue.
<ItemOut>
<ItemDetail>
<UnitPrice>
PO106 235 Product/Service ID Qualifier X ID 2/2 O
Code identifying the type/source of the descriptive number used in Product/Service ID
(234)
C3 Classification
One Item Classification code, mapped here for convenience, if
ItemDetail is supplied.
<ItemOut>
<ItemDetail>
<Classification>
- first occurrence only
MF Manufacturer
<ItemOut>
<ItemDetail>
<ManufacturerName>
MG Manufacturer's Part Number
This is optional, but can identify the item from another vantage
point.
<ItemOut>
<ItemDetail>
<ManufacturerPartID>
VP Vendor's (Seller's) Part Number
SupplierPartID is mandatory. cXML guarantees this information
from the Buyer. You can specify SupplierPartID either with a
value or as “Not Available”. You must specify SupplierPartID
or/and set isAdhoc flag to “yes”.
<ItemOut isAdhoc=“yes”>
<ItemID>
<SupplierPartID> ABC124</SupplierPartID>
VS Supplier Part Auxiliary ID
SupplierPartAuxiliaryID is mapped if it is provided in the itemID.
<ItemOut>
<ItemID>
<SupplierPartAuxiliaryID>
PO107 234 Product/Service ID X AN 1/48 O
Identifying number for a product or service
(234)
C3 Classification
MF Manufacturer
(234)
C3 Classification
MF Manufacturer
(234)
C3 Classification
MF Manufacturer
(234)
C3 Classification
MF Manufacturer

Segment: CUR Currency of Unit Price

Position: 020
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
Specifies the currency of the Unit Price (optionally) supplied by the Buyer. In cXML,
currency is a required attribute of the Money tag, from UnitPrice. UnitPrice is required if
ItemDetail is supplied.
<OrderRequest>
<ItemOut>
<ItemDetail>
<UnitPrice>
<Money>
currency %isoCurrencyCode; #REQUIRED

Ref. Data Base User
ISO 4217 compliant and Ariba writes here whatever is collected from any Ariba B2B
X12 also expects ISO 4217 conformance here, the same as %isoCurrencyCode;

Segment: PO3 Unit of Measure

Position: 030
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 25
Purpose: To specify additional item-related data involving variations in normal price/quantity
structure
Syntax Notes: If PO304 is present, then at least one of PO303 or PO305 is required.
Semantic Notes:
Comments: Some examples of price/quantity variations are: price in different units from the PO1
segment, price changes by date, or price changes by quantity (break and level).
PO307 defines the unit of measure for PO306.
poUsage Notes: Used/Optional
Notes: Example: PO3*ZZ****ST**EA~
Specifies the unit of measure supplied by the Buyer..
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<UnitOfMeasure>

Ref. Data Base User
PO301 371 Change Reason Code M ID 2/2 M
Code specifying the reason for price or quantity change
ZZ Mutually Defined
PO305 639 Basis of Unit Price Code D ID 3/3 M
Code identifying the type of unit price for an item.
ST Standard
PO307 355 Unit or Basis for Measurement Code M ID 2/2 M

Segment: CTP Pricing Information

Position: 040
Loop: PO1/CTP Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Purpose: To specify pricing information
Syntax Notes: 1. If either CTP04 or CTP05 is present, then the other is required.
2. If CTP06 is present, then CTP07 is required.
Semantic Notes: CTP07 is a multiplier factor to arrive at a final discounted price. A multiplier of .90
would be the factor if a 10% discount is given.
CTP08 is the rebate amount.
Comments: See Figures Appendix for an example detailing the use of CTP03 and CTP04.
See Figures Appendix for an example detailing the use of CTP03, CTP04 and CTP07.
Notes: Example: CTP*WS***2*BX*CSD*1~
<OrderRequest>
<ItemOut>
<ItemDetail>
<PriceBasisQuantity quantity="2" conversionFactor="1">
<UnitOfMeasure>BX</UnitOfMeasure>
<PriceBasisQuantity>

Ref. Data Base User
CTP01 687 Class of Trade Code O ID 2/2 O
Code indicating class of trade
WS User
CTP04 380 Quantity D ID 1/1 D
Numeric value of quantity.
ST Standard
CTP05/ 355 Unit or Basis for Measurement Code M ID 2/2 M
C001/01
CTP06 648 Price Multiplier Qualifier O ID 3/3 O
Code indicating the type of price multiplier.
CSD Cost Makeup Multiplier-Original Cost
CTP07 649 Multiplier D R 1/10 R
Value to be used as a multiplier to obtain a new value.


Position: 040
Level: Detail
Usage: Optional
Max Use: 1
Notes: Example: CTP*PY***10*EA*CSD*8.33~
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<PriceBasisQuantity>

Ref. Data Base User
PY Private Label
CTP04 380 Quantity D ID 1/1 D
ST Standard
CTP05/ 355 Unit or Basis for Measurement Code M ID 2/2 M
C001/01
CTP06 648 Price Multiplier Qualifier O ID 3/3 O
Code indicating the type of price multiplier.
CSD Cost Makeup Multiplier-Original Cost
CTP07 649 Multiplier D R 1/10 R
Value to be used as a multiplier to obtain a new value.


Position: 040
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Notes: Example: CTP*TR*MAX*3000.00~
CUR*BY*USD~
Specifies the maximum amount supplied by the buyer.
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<MaxAmount>

Ref. Data Base User
TR General Trade
CTP02 236 Price Identifier Code D ID 3/3 D
Code identifying pricing specification
MAX Maximum Order Quantity Price
CTP03 212 Unit Price D ID 1/17 D
BY Buying Party
Code specifying the Standard ISO code for country in whose currency the charges are
specified


Position: 040
Loop: PO1 Mandatory
Level: Detail
Max Use: 1
Semantic Notes:

Ref. Data Base User
GBP British Pound
USD US Dollars


Position: 040
Level: Detail
Usage: Optional
Max Use: 1
Notes: Example: CTP*TR*MIN*200.00~
CUR*BY*USD~
Specifies the minimum amount supplied by the buyer
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<MinAmount>

Ref. Data Base User
TR General Trade
MIN Minimum Order Quantity Price
BY Buying Party
specified


Position: 040
Loop: PO1 Mandatory
Level: Detail
Max Use: 1
Semantic Notes:

Ref. Data Base User
GBP British Pound
USD US Dollars


Position: 040
Level: Detail
Usage: Optional
Max Use: 1
Notes: Example: CTP*TR*UCP*34.00~
CUR*BY*USD~
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<UnitPrice>

Ref. Data Base User
TR General Trade
UCP Unit Cost Price
BY Buying Party
specified


Position: 040
Loop: PO1 Mandatory
Level: Detail
Max Use: 1
Semantic Notes:

Ref. Data Base User
GBP British Pound
USD US Dollars

Segment: PID Product/Item Description

Position: 050
Loop: PID Optional
Level: Detail
Usage: Optional
Max Use: 1
Purpose: To describe a product or process in coded or free-form format
Syntax Notes: 1 If PID04 is present, then PID03 is required.
2 At least one of PID04 or PID05 is required.
3 If PID07 is present, then PID03 is required.
Semantic Notes: 1 Use PID03 to indicate the organization that publishes the code list being referred to.
2 PID04 should be used for industry-specific product description codes.
3 PID08 describes the physical characteristics of the product identified in PID04. A
"Y" indicates that the specified attribute applies to this item; an "N" indicates it does
not apply. Any other value is indeterminate.
4 PID09 is used to identify the language being used in PID05.
Comments: 1 If PID01 equals "F", then PID05 is used. If PID01 equals "S", then PID04 is used. If
PID01 equals "X", then both PID04 and PID05 are used.
2 Use PID06 when necessary to refer to the product surface or layer being described in
the segment.
3 PID07 specifies the individual code list of the agency specified in PID03.
Notes: Example for a purchase order::
PID*F*GEN***3M Brand Scotch Tape****en~
PID*F****A cellophane strip bearing an adhesive coating on one side and wound
tightly****en~
PID*F****onto a roll. A frame surrounds the roll with a tearing edge protruding about
one****en~
PID*F****inch from the center of the roll's rotational axis.****en~
* Note that our PID looping group allows 1000 iterations in total. This can be divided any
way between Item Descriptions and Classifications. But 1000 is the combined limit.
The product description is required if ItemDetail is supplied by the Buyer. Each
<Description> tag can be interspersed with its own #PCDATA and <ShortName> tags.
The recommended practice is to put <ShortName> either at the beginning or at the end, if
it is present. But there is no rule in cXML enforcing that. The description text itself can
be quite long. ShortName is an optional child element which provides a short description
of fifty characters or less. Any ShortName will always produce its own PID segment,
with PID02="GEN". The regular description text does not mark PID02.
<OrderRequest>
<ItemOut>
<ItemDetail>
<Description>
The Description segment is also used for blanket purchase orders.
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<Description>
Example for a blanket purchase order:
PID*F****Adapter SUN Monitor 4-BNCF/13W3MAdapter SUN Monitor 4-

BNCF/13W3MAdapter SUN Moni****EN~
PID*F****tor 4-BNCF/13W3M****EN~

Ref. Data Base User
PID01 349 Item Description Type M ID 1/1 M
Code indicating the format of a description
F Free-form
PID02 750 Product/Process Characteristic Code O ID 2/3 O
Code identifying the general class of a product or process characteristic
Set to "GEN" for a ShortName, unused for regular description text.
GEN General Description
PID05 352 Description X AN 1/80 O
A free-form description to clarify the related data elements and their content
Description text or the ShortName contents
<Description>
PID09 819 Language Code O ID 2/3 O
<Description>
xml:lang %xmlLangCode; #REQUIRED

Segment: PID Product/Item Description - Classification Details

Position: 050
Loop: PID Optional
Level: Detail
Usage: Optional
Max Use: 1
Purpose: To describe a product or process in coded or free-form format
Syntax Notes: 1 If PID04 is present, then PID03 is required.
2 At least one of PID04 or PID05 is required.
Semantic Notes: 1 Use PID03 to indicate the organization that publishes the code list being referred to.
2 PID04 should be used for industry-specific product description codes.
3 PID08 describes the physical characteristics of the product identified in PID04. A
"Y" indicates that the specified attribute applies to this item; an "N" indicates it does
not apply. Any other value is indeterminate.
4 PID09 is used to identify the language being used in PID05.
Comments: 1 If PID01 equals "F", then PID05 is used. If PID01 equals "S", then PID04 is used. If
PID01 equals "X", then both PID04 and PID05 are used.
2 Use PID06 when necessary to refer to the product surface or layer being described in
the segment.
3 PID07 specifies the individual code list of the agency specified in PID03.
Notes: Example for a purchase order:
PID*S*MAC*UN*31201512***SPSC~
* Note that our PID looping group allows 1000 iterations in total. This can be divided any
way between Item Descriptions and Classifications. But 1000 is the combined limit.
Item classifications are required by cXML 1.1 to adhere to the UN/SPSC standard
(www.unspsc.org). If <ItemDetail> is supplied, then at least one <Classification> tag is
required. The first classification is mapped to PO1 for convenience. Multiple
classifications are required to be unique.
<OrderRequest>
<ItemOut>
<ItemDetail>
<Classification>
You can specify the Classification segment for blanket purchase orders.
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<Classification>
Example for a blanket purchase order:
PID*S*MAC*UN*432118***SPSC~

Ref. Data Base User
PID01 349 Item Description Type M ID 1/1 M
Code indicating the format of a description
S Structured (From Industry Code List)
PID02 750 Product/Process Characteristic Code O ID 2/3 M
Code identifying the general class of a product or process characteristic
MAC Material Classification

Class of material, e.g. prime, secondary, etc.
PID03 559 Agency Qualifier Code X ID 2/2 M
AS Assigned by Seller
Used if domain attribute does not equal "UNSPSC"
UN United Nations (UN)
Used if domain attribute equals "UNSPSC"
PID04 751 Product Description Code X AN 1/12 M
A code from an industry code list which provides specific data about a product
characteristic
Classification data
<Classification>
#PCDATA
PID07 822 Source Subqualifier O AN 1/15 M
A reference that indicates the table or text maintained by the Source Qualifier
If domain attribute equals "UNSPSC" (which it should), then this is "SPSC", so that the
PID03/PID07 combination make up "UN/SPSC". If domain does not equal "UNSPSC",
then PID07 contains the domain attribute value sent by the buyer and assigned by the
seller.

Segment: REF Reference Identification - Requisition ID

Position: 100
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Comments:
Notes: Example: REF*RQ*4592782~
The line item level Requisition Id is an optional attribute of <ItemOut>. It can be
specified in the order header, or at the line item level, but not both.
<OrderRequest>
<ItemOut>
requisitionID %string; #IMPLIED

Ref. Data Base User
RQ Purchase Requisition Number
REF02 127 Reference Identification X AN 1/30 M
Requisition Id value

Segment: REF Reference Identification - Supplier ID

Position: 100
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Comments:
Notes: Example: REF*ZA*352948107*DUNS~
Supplier identification is optionally provided for completeness. Since a supplier is
receiving the Purchase Order, this value should always be their own recognized
identification. EDI Implementers can use this as a second verification that the PO was
truly intended for this supplier.
<OrderRequest>
<ItemOut>
<SupplierID>

Ref. Data Base User
ZA Supplier
Supplier identification
<SupplierID>
#PCDATA
Required domain attribute value to indicate what this identification represents.
<SupplierID>
domain %string; #REQUIRED

Segment: REF Reference Identification – Parent Line Item Number

Position: 100
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Comments:
Notes: Example: REF*FL*2*item~
REF*FL**composite~
Use this segment to specify if the line item is a parent or child line item. You can also
specify the corresponding line number for the line item. This is an optional segment.
<ItemOut lineNumber="6001" parentLineNumber="1" itemType="item">

Ref. Data Base User
FL Fine Line Classification
This value will store the parent line item number value. This is only used if the
parentLineNumber value exists.
OrderRequest/ItemOut/@parentLineNumber
A free-form description to specify the related data elements and their content.
Required domain attribute values to indicate what this identification represents.
item To identify a child item
composite To identify a parent item
OrderRequest/ItemOut/@itemType

Segment: REF Reference Identification

Position: 100
Loop: PO1
Level: Detail
Usage: Optional
Max Use: >1
Comments:
Ref. Data Base User
0L Referenced By
0L is used to override the value of Transport Terms. This can be
used when a custom value of transport term is supplied.
Example:
REF*0L*My Terms~
<TransportTerms value=”Other”>My Terms</ TransportTerms>
Then, REF01 will be 0L and REF02 will be FOB05

FOB05 Used to reference FOB05
This value is used only when reporting custom transport terms. All
other REF01 values will have their corresponding REF02 values.
<TransportTerms> if value = "Other"


Position: 110
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 3
Semantic Notes:
Comments:
Notes: PER*BL*Tech Support*TE*18005553737*EM*tech.support@thebuyer.com~
PER*CR*Customer
Service*TE*18005554141*FX*13125551827*EM*customer.service@thebuyer.com~
* Refer to implementation notes for PER[1/060]; they are almost identical.

Contact information from the Line Item is mapped here briefly. Contacts that involve a
PostalAddress or extensive details will appear in an N1 loop. We are limited here to only
three PER segments, so this section is reserved for short and quick contact information.
<OrderRequest>
<ItemOut>
<Contact>

Ref. Data Base User
AM Administrator
CN General Contact
(role unspecified)
EB Entered By
role="endUser"
role="sales"
Free-form name
Required Name tag. Where possible, contact information will be grouped with a matching
name.
EM Electronic Mail

FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

Segment: SAC Shipping Charge

Position: 130
Loop: SAC Optional
Level: Detail
Usage: Optional
Max Use: 1
Dollars in SAC09.
Notes: Example: SAC*C*G830***4680********4812489789**2 day express*en~
In the detail section, this represents a shipping cost for this one line item to the supplier.
There can be one of these for the entire order, or one per line item. This context
represents one for the line item.
Shipping charges can be applied either at the header, for the entire order, or at the line
item level. But not both.
<OrderRequest>
<ItemOut>
<Shipping>

Ref. Data Base User
C Charge
SAC02 1300 Service, Promotion, Allowance, or Charge Code X ID 4/4 O
G830 Shipping and Handling

SAC05 610 Amount O N2 1/15 O

Monetary amount
<Shipping>
<Money>
#PCDATA
SAC13 127 Reference Identification X AN 1/30 O
SAC15 352 Description X AN 1/80 O
A free-form description to clarify specify the related data elements and their content
Ariba Network accepts only one Description here. cXML allows for a ShortName to be
included with the Description. If the Description text is longer than 80 characters, and a
ShortName is available, then Ariba Network maps the ShortName here.
<Shipping>
<Description>
SAC16 819 Language Code O ID 2/3 O
<Shipping>
<Description>
xml:lang %isoLangCode; #REQUIRED


Position: 135
Loop: SAC Optional
Level: Detail
Max Use: 1
Semantic Notes:

Ref. Data Base User
GBP British Pound
USD US Dollars

Segment: SAC Modifications

Position: 130
Loop: SAC Optional
Level: Detail
Usage: Optional
Max Use: 1
Dollars in SAC09.
Notes: Example: SAC*N**ZZ*F050*2200**********Original Price*en~
CUR*BY*CAD~
SAC*A**ZZ*I530**6*5********Volume Discount*en~
CUR*BY*CAD*****196*20050504*101500*197*20050701*101500~
In the header section, this represents a modification in the order to the supplier. There can
be multiple modifications. Maximum number of modifications supported is 11. This is an
example of a modification in an order.
<OrderRequest>
<Total>
<Money>……..
<Modifications>
<Modification>
<OriginalPrice>
<Money currency="CAD">22.00</Money>
</OriginalPrice>
<AdditionalDeduction>
<DeductionPercent percent="5"/>
</AdditionalDeduction>
<ModificationDetail endDate="2005-07-01T10:15:00-08:00" name="Volume
Discount" startDate="2005-05-04T10:15:00-08:00">
</ModificationDetail>
</Modification>

Ref. Data Base User
C Charge
A Allowance
SAC03 559 Agency Qualifier Code X ID 2/2 M
ZZ Mutually Defined
SAC04 1301 Agency Service, Promotion, Allowance, or Charge M AN 1/10 M
Code
F050 Other
H970 Allowance
B660 Contract Allowance
C310 Discount
C300 Discount-Special
I530 Volume Discount
A040 Access Charge
A050 AccountNumberCorrectionCharge
A060 AcidBattery
A170 Adjustment
A960 Carrier
A520 Charge
D240 Freight
D180 FreightBasedOnDollarMinimum
D500 Handling
D980 Insurance
G580 Royalties
G821 Shipping
G830 ShippingAndHandling
Description: Monetary amount
OriginalPrice/Money (For Original Price)
AdditionalCost/Money (For Charge)
AdditionalDeduction/DeductionAmount/Money (For Allowances)
SAC06 378 Allowance/Charge Percent Qualifier X ID 1/1 O
Description: Code indicating on what basis allowance or charge percent is calculated
6 Price Based Amount
SAC07 332 Percent X R 1/6 O
Description: Percent expressed as a percent
SAC14 770 Option Number O AN 1/20 O
Description: A unique number identifying available promotion or allowance options when more than one
is offered

1 Used if SAC05 value is amount

2 Used if SAC05 value is price
Description: Code designating the language used in text, from a standard code list maintained by the
<ModificationDetail endDate="2005-07-01T10:15:00-08:00" name="Volume Discount"
startDate="2005-05-04T10:15:00-08:00">


Position: 135
Loop: SAC Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
Notes: Example 1: CUR*BY*USD~
Example 2: CUR*BY*CAD*****196*20050504*101500*197*20050701*101500~

Ref. Data Base User
GBP British Pound
USD US Dollars
196 Start
CUR08 373 Date O DT 8/8 O
CUR09 337 Time O TM 4/8 O
Description: Time expressed in 24-hour clock time as follows: HHMM, HHMMSS, HHMMSSD, or
HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD =
decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-
99)


Description: Code specifying type of date or time, or both date and time
All valid standard codes are used. (Total Codes: 1112)
197 End
CUR11 373 Date X DT 8/8 O
CUR12 337 Time X TM 4/8 O
Description: Time expressed in 24-hour clock time as follows: HHMM, HHMMSS, HHMMSSD, or
HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD =
decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-
99)

Segment: SAC Account Distribution

Position: 130
Loop: SAC Optional
Level: Detail
Usage: Optional
Max Use: 1
amount, that is applicable to service, promotion, allowance, or charge.
Dollars in SAC09.
Notes: Example:
SAC*N*B840***9800********07-D84-422-E11*1*Project: 07, Cost Center: D84,

Department: 422, Account: E11~
SAC*N*B840***2700********07-G18-422-E11*2*Project: 07, Cost Center: G18,
Department: 422, Account: E11~
Here the buyer has requested a two way split on the charges. The buyer's account number
is comprised of four segments. For reference purposes, Ariba Network expands the
account number with the account segment names in the description element, SAC15, as
space allows. The Option Number element, SAC14, shows the sequential occurrence of
<Distribution> tags.
Out of the $125 total, $98 is to be charged to one account and $27 to another. The
account number segmentation is implied by the buyer's internal system.
Buyers can optionally specify a list of accounts showing how they want the charges for
this line item distributed on their invoice. If present, suppliers are expected to invoice
according to these accounting guidelines.
<OrderRequest>
<ItemOut>
<Distribution>

Ref. Data Base User
SAC02 1300 Service, Promotion, Allowance, or Charge Code X ID 4/4 M
B840 Customer Account Identification
G/L Account

Monetary amount
Specific amount of extended price to be applied to this account.
<Distribution>
<Charge>
<Money>
SAC13 127 Reference Identification X AN 1/30 M
Whole account number. This is all account segment id's concatenated together.
This number is used to designate the administrative budget center against which the
transaction is to be charged in the Buying Organization's accounting classification coding
structure. In some organizations this field will contain an account number, a department
code, a project number and/or a cost center.
<Distribution>
<Accounting>
<AccountingSegment> .. <Segment>
id %string; #REQUIRED
* The "id" attribute from all <Segment> or <AccountingSegment> tags

enumerated under Accounting are concatenated to form a complete
account number.
SAC14 770 Option Number O AN 1/20 M
A unique number identifying available promotion or allowance options when more than
one is offered
Integer representing the sequential occurrence of the <Distribution> tag for this line item.
This number is not explicitly stated in the cXML body, but rather is implied by tag
sequencing. This number is generated by the EDI mapping process.
= "LISA" (Line Item Split Accounting)


Position: 135
Loop: SAC Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:

Ref. Data Base User

Segment: FOB F.O.B. Related Instructions

Position: 180
Loop: PO1
Level: Detail
Usage: Optional
Max Use: >1
Purpose: To specify transportation instructions relating to shipment.
Syntax Notes: 1 If FOB03 is present, then FOB02 is required.
Semantic Notes: 1 FOB01 indicates which party will pay the carrier.
2 FOB02 is the code specifying transportation responsibility location.
3 FOB06 is the code specifying the title passage location.
4 FOB08 is the code specifying the point at which the risk of loss transfers. This may
be different than the location specified in FOB02/FOB03 and FOB06/FOB07.
Comments:
Notes: Example: FOB*DF*ZZ*PriceCondition *ZZ*FAS*ZZ*@TPTransport
description@TODDelivery at the doorstep*ZZ*Account~
This segment allows you to enter the Terms of Delivery.
The address information is depicted by a separate N1 segment with entity identifier code
(N101) qualifier as DA.
<OrderRequest>
<TermsOfDelivery>
<ShippingPaymentMethod value="Account"/>
<TransportTerms value="FreeAlongsideShip/>
<Address>
<State>AL</State>
</PostalAddress>
</Address>
<Comments xml:lang="en-US" type="Transport">Transport
description</Comments>
<Comments xml:lang="en-US" type="TermsOfDelivery">Delivery at
the doorstep</Comments>
</TermsOfDelivery>

Ref. Data Base User
FOB01 146 Shipment Method of Payment M ID 2/2 M
Description: Code identifying payment terms for transportation charges
DF Account
CA AdvanceCollect
PA AdvancePrepaid
DF CashOnDeliveryServiceChargePaidByConsignee
DF CashOnDeliveryServiceChargePaidByConsignor
CC Collect
CF CollectFreightCreditedToPaymentCustomer
CD CollectOnDelivery
PB CustomerPick-UpOrBackhaul
DF DefinedByBuyerAndSeller
FO FobPortOfCall
HP HalfPrepaid
DF InformationCopy-NoPaymentDue
DF InsuranceCostsPaidByConsignee
DF InsuranceCostsPaidByConsignor
MX Mixed
NR NonRevenue
DF NotSpecified
BP PaidByBuyer
PS PaidBySupplierOrSeller
DF PayableElsewhere
DE PerContract
PU Pickup
PE PrepaidAndSummaryBill
PC PrepaidButChargedToCustomer
PD PrepaidByProcessor
PP Prepaid-BySeller
PL PrepaidLocalCollectOutstate
PO PrepaidOnly
RF ReturnContainerFreightFree
RC ReturnContainerFreightPaidByCustomer
RS ReturnContainerFreightPaidBySupplier
11 Rule11Shipment
NC ServiceFreight-NoCharge
TP ThirdPartyPay
DF Other
WC WeightCondition
OF Other Unlisted Free On Board (FOB) Point
ZZ Mutually Defined
<OrderRequest>
<TermsOfDelivery>
Or
<OrderRequest>
<TermsOfDelivery>
<TermsOfDeliveryCode value="Other">MyCode</TermsOfDeliveryCode>
FOB04 334 Transportation Terms Qualifier Code O ID 2/2 Used
Description: Code identifying the source of the transportation terms
ZZ Mutually Defined
FOB05 335 Transportation Terms Code X ID 3/3 Used
Description: Code identifying the trade terms which apply to the shipment transportation
responsibility.
EXW Ex-Works
FCA Free-Carrier
FAS FreeAlongsideShip
FOB FreeOnBoard
CAF CostAndFreight
CIF Cost-InsuranceAndFreight
CPT CarriagePaidTo
CIP Carriage-InsurancePaidTo
DAF DeliveredAtFrontier
DES DeliveredEx-Ship
DEQ DeliveredEx-Quay
DDU DeliveredDutyUnpaid
DDP DeliveredDutyPaid
ZZZ Other
ZZ Mutually Defined
Transport description and terms of delivery description is stored in this element. Both will be
concatenated together. Transport description will be prefixed by @TP and terms of delivery
description will be prefixed by @TOD.
eg: @TPTransport description @TODDelivery at the doorstep
FOB08 54 Risk of Loss Code O ID 2/2 Used
Description: Code specifying where responsibility for risk of loss passes
ZZ Mutually Defined
FOB09 352 Description X AN 1/80 Used
Value of OrderRequest/OrderRequestHeader/TermsOfDelivery/ShippingPaymentMethod

Segment: DTM Requested Delivery Date

Position: 210
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
Comments:
Notes: Example: DTM*002*20000415~
Requested delivery date is an optional attribute of the <ItemOut> tag from cXML. It
represents the "Need-By" date in any Ariba B2B Procurement Platform. It will be
mapped here if it is supplied.
<OrderRequest>
<ItemOut>
requestedDeliveryDate %date; #IMPLIED

Ref. Data Base User
002 Delivery Requested
Requested delivery date

Segment: TXI Tax Information

Position: 291
Loop: PO1 Mandatory
Level: Detail
Usage: Optional
Max Use: 1
Purpose: To specify tax information
Syntax Notes: 1 At least one of TXI02 TXI03 or TXI06 is required.
2 If either TXI04 or TXI05 is present, then the other is required.
3 If TXI08 is present, then TXI03 is required.
Semantic Notes: 1 TXI02 is the monetary amount of the tax.
2 TXI03 is the tax percent expressed as a decimal.
3 TXI07 is a code indicating the relationship of the price or amount to the associated
segment.
Comments:
Notes: Example: TXI*TX*27.18~
cXML supplies tax information with an amount and a description. Ariba sends the tax
amount here. Taxes can be present at both the header and line item levels. Taxes at the
line item level are used to show a per line item breakdown.
If specific tax information is not present, then suppliers are expected to calculate and
apply required taxes. If buyers are specifying tax amounts, then they have done this
calculation on their side, and an error might result in an acknowledgment either
recalculating this properly or non-fulfillment pending correction.
<OrderRequest>
<ItemOut>
<Tax>

Ref. Data Base User
TXI01 963 Tax Type Code M ID 2/2 M
Code specifying the type of tax
TX All Taxes
Total of all applicable taxes
TXI02 782 Monetary Amount X R 1/18 M
Monetary amount

Segment: QTY Quantity Information

Position: 293
Loop: PO1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Purpose: To specify quantity information
Syntax Notes: 1 At least one of QTY02 or QTY04 is required.
2 Only one of QTY02 or QTY04 may be present.
Semantic Notes: QTY04 is used when the quantity is non-numeric.
Comments:
Notes: Specifies the maximum quantity for a line Item in the blanket purchase order.
This segment displays this value if the blanket purchase order contains the MaxQuantity
value,
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<MaxQuantity>
Example: QTY*7D*30~

Ref. Data Base User
QTY01 673 Quantity Qualifier M ID 2/2 M
Code specifying the type of quantity
7D Range Maximum
QTY02 380 Quantity D R 1/15 D


Segment: QTY Quantity Information

Position: 293
Loop: PO1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Purpose: To specify quantity information
Syntax Notes: 1 At least one of QTY02 or QTY04 is required.
2 Only one of QTY02 or QTY04 may be present.
Semantic Notes: QTY04 is used when the quantity is non-numeric.
Comments:
Notes: Specifies the minimum quantity for a line Item in the blanket purchase order.
This segment displays this value if the blanket purchase order contains the MinQuantity
value,
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<MinQuantity>
Example: QTY*7E*5~

Ref. Data Base User
QTY01 673 Quantity Qualifier M ID 2/2 M
Code specifying the type of quantity
7E Range Minimum
QTY02 380 Quantity D R 1/15 D

Segment: N9 Reference Identification - URL

Position: 330
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1
Comments:
Notes: Example: N9*URL*URL*Catalog Entry~
If ItemDetail is supplied, there is one optional URL the Buyer can send to reference the
item. What the URL refers to, if specified, is mapped in N903. The URL itself is mapped
to the MSG segment.
<OrderRequest>
<ItemOut>
<ItemDetail>
<URL>

Ref. Data Base User
URL Uniform Resource Locator
Ariba writes constant "URL" here because either element 2 or 3 is required, and our data
for element 3 is optional. This is to prevent an X12 compliance error.
Application Value List:
URL
"name" attribute value, if present.
<URL>


Position: 340
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1000
is required.
Notes: Example: MSG*http://www.thesupplier.com/catalog?itemid=26409~
<OrderRequest>
<ItemOut>
<ItemDetail>
<URL>
#PCDATA

Ref. Data Base User
URL data value

Segment: N9 Reference Identification - Comments

Position: 330
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1
Comments:
Notes: Example: N9*L1*Comment*en~
cXML provides one block of comments at the header level, which is mapped here. cXML
also has the ability to include an attachment here, but attachments are not mapped to X12
<OrderRequest>
<ItemOut>
<Comments>

Ref. Data Base User
L1 Letters or Notes
N902 127 Reference Identification X AN 1/30 O
Always set to "Comment". Ariba writes a constant here because X12 requires that either
N902 or N903 is used, and the description is optional in cXML. By writing a constant,
Ariba avoids any compliance issues with X12.
Application Value List:
Comment
This is the language code attribute sent by cXML to describe the language used for the
comment. The code is ISO 639 compliant. Note that this code is optional and can be
supplied in lower case.
<Comments>
xml:lang %xmlLangCode; #IMPLIED


Position: 340
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1000
is required.
Notes: Example:
MSG*Do not wrap with adhesive tape;~

MSG*It leaves a sticky residue*LC~
(LC was shown here for demonstration. It wouldn't actually be used on two short lines,
but only when a line exceeds the 264 char limit of MSG01.)
The actual comment text. The X12 mapping will try to preserve the line breaks from the
cXML as best it can. Each line break will automatically incur a new MSG segment, with
the exception of a blank line. If one line goes over the capacity of MSG01 then the line is
word-broken and a new MSG segment is created to continue the line. If the number of
lines exceed the occurrence limit of MSG, then the remainder of the comment text will be
truncated.
Any imbedded Attachments will be dropped. However, Ariba might include a text
representation that it is present. For example:
MSG*See the attached word document. [Attachment "specs.doc"]~
<OrderRequest>
<ItemOut>
<Comments>
#PCDATA .. <Attachment>

Ref. Data Base User
If a line was broken by the limitation of MSG01, and a new segment is created for
continuation, then MSG02="LC", otherwise it is not used.


Position: 330
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1
Comments:
Notes: Example: N9*ZZ**Size Information~
Extrinsic information is well-formed XML provided by the buyer to define extra

information outside the scope of cXML's specifications. The content here is user-defined,
and in X12 should be regarded as comment information.
There are three rules to consider when looking at extrinsic information:

1. It is defined by the specific implementation of the Buyer and the Buyer's ERP system
to any Ariba B2B Procurement Platform. Two different Buyers might send the same
information in two distinct ways at this level. You cannot depend on the precise format.
2. Neither Ariba nor cXML control the exact content and formatting of Extrinsics. The
implementation is user-defined, and popular implementations thereof often migrate their
way into future versions of cXML. Treat this as comment information.
3. While every effort is made to preserve the integrity of Extrinsic information in the X12
implementation, it simply cannot be guaranteed. Non-printable characters cannot be
transported and any occurrences of our X12 control characters (i.e.. SegTerm, ElemSep,
CompSep) MUST BE TRANSLATED. Supplier side EDI Implement ors should make
their respective departments aware of this.
<OrderRequest>
<ItemOut>
<ItemDetail>
<Extrinsic>

Ref. Data Base User
ZZ Mutually Defined
<Extrinsic>


Position: 340
Loop: N9 Optional
Level: Detail
Max Use: 1000
is required.
Notes: Example:
MSG*<Size UnitOfMeasure="cm">~
MSG* <Height>14</Height>~
MSG* <Width>23</Width>~
MSG* <Depth>12.4</Depth>~
MSG*</Size>~
MSG carries the actual Extrinsic data as accurately as possible. Where new lines are
started in cXML, new MSG segments are created (except for blank lines) in order to
is created and the Extrinsic text continues.
<OrderRequest>
<ItemOut>
<ItemDetail>
<Extrinsic>
ANY

Ref. Data Base User

MSG02="LC"


Position: 330
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1
Comments:
mask amount values in the blanket purchase order they send a supplier. If the blanket
purchase order contains masked values, then this extrinsic stores the “hideAmount”
value.
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<Extrinsic>
If “hideAmount” is available, the values in the Amount fields display 0.00.

Ref. Data Base User
ZZ Mutually Defined
<Extrinsic>


Position: 340
Loop: N9 Optional
Level: Detail
Max Use: 1000
is required.
Notes: Example:
MSG*Yes~
The MSG element stores the actual Extrinsic data as accurately as possible. When new
lines are added in cXML, new MSG segments are created (except for blank lines) in
order to preserve its integrity. If a line exceeds the capacity of MSG01, then a new MSG
segment is created and the Extrinsic text is carried forward.

Ref. Data Base User


Position: 330
Loop: N9 Optional
Level: Detail
Usage: Optional
Max Use: 1
Comments:
mask unit price values in the blanket purchase order they send a supplier. If the blanket
purchase order contains masked values, then this extrinsic stores the “hideUnitPrice”
value.
If the extrinsic is specified at the header level, the values are masked in the header-level
and all the line items of the blanket purchase order.
Example: N9*ZZ**hideUnitPrice~
<OrderRequest>
<ItemOut>
<BlanketItemDetail>
<Extrinsic>
If “hideUnitPrice” is available, the values in the unit price fields display 0.00.

Ref. Data Base User
ZZ Mutually Defined
<Extrinsic>


Position: 340
Loop: N9 Optional
Level: Detail
Max Use: 1000
is required.
Notes: Example:
MSG*Yes~
The MSG stores the actual Extrinsic data as accurately as possible. Where new lines are
added in cXML, new MSG segments are created (except for blank lines) in order to
is created and the Extrinsic text is carried forward.

Ref. Data Base User

Segment: N1 Ship-To Name

Position: 350
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
Notes: Example: N1*ST*San Jose Office*92*152~
Line Item Level Ship-To Address Information
This is optional at the line item level. Ariba will send ShipTo Information either at the
header OR at the line item level, but not both. If it is absent here then it is required at the
header level.
<OrderRequest>
<ItemOut>
<ShipTo>

Ref. Data Base User
ST Ship To
N102 93 Name X AN 1/60 O
Free-form name


Position: 360
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example:
N2*Maria Valenzuela*B1-2462~
N2*The Buyer, Inc.~
Network implements up to the first four here: two Name elements across two N2
segments.
will be ignored.
<ShipTo>
<Address>
<PostalAddress>
<DeliverTo>

Ref. Data Base User
N201 93 Name M AN 1/60 M
Free-form name
N202 93 Name O AN 1/60 O
Free-form name


Position: 370
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: N3*1500 Buyer Way~
<ShipTo>
<Address>
<PostalAddress>
<Street>

Ref. Data Base User
Address information
Address information


Position: 380
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
specify a location.
Notes: Example: N4*San Jose*CA*95110*US~
are optional.
<ShipTo>
<Address>
<PostalAddress>

Ref. Data Base User
<PostalAddress>
<City>
<PostalAddress>
<State>
for United States)
nine digit code is sent. A Canadian Postal Code is always formatted "A9A9A9". There will
not be a separator in the middle.
<PostalAddress>
<PostalCode>
currency codes:
<PostalAddress>
<Country>


Position: 400
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 3
Semantic Notes:
Comments:
Notes: Example: PER*RE*Maria -
Primary*TE*14085551824*FX*14085552001*EM*Maria.Valenzuela@thebuyer.com~
element.
<ShipTo>
<Address>

Ref. Data Base User
RE Receiving Contact
Free-form name
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

EM Electronic Mail
FX Facsimile
TE Telephone

Segment: N1 Name - Detailed Contact Information

Position: 350
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
Notes: Example: N1*A9*Devereux~
This section of N1 allows for detailed contact information, beyond what can be specified
in the PER[2/110] at the top, which is only intended for brief information.
Any contact that includes a PostalAddress must be specified here, along with contacts
requiring a variety of name tags for a specified role.
<OrderRequest>
<ItemOut>
<Contact>

Ref. Data Base User
60 Salesperson
Identification of individual that sold the product e.g. SSN,
salesperson id, etc.
role="sales"
A9 Sales Office
A business entity whose main activity is, or a location at which, the
sale of goods or services takes place
CA Carrier
EN End User
role="endUser"
KY Technical Office
L5 Contact
(role unspecified)
NG Administrator
PD Purchaser's Department Buyer
RI Remit To
SF Ship From

SO Sold To If Different From Bill To
SU Supplier/Manufacturer
N102 93 Name X AN 1/60 O
Free-form name


Position: 360
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example: N2*Stefanie Devereux*Executive Sales Manager~
Ariba Network accepts up to four DeliverTo tags from cXML: two elements across two
segments.
<OrderRequest>
<ItemOut>
<Contact>
<PostalAddress>
<DeliverTo>

Ref. Data Base User
N201 93 Name M AN 1/60 M
Free-form name
N202 93 Name O AN 1/60 O
Free-form name


Position: 370
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: N3*The Buyer, Inc.*1 Buyer Parkway~
In cXML, Street is required if PostalAddress is present. Ariba Network maps a maximum
of four Street tags here: two elements across two segments.
<OrderRequest>
<ItemOut>
<Contact>
<PostalAddess>
<Street>

Ref. Data Base User
Address information
Address information


Position: 380
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
specify a location.
Notes: Example: N4*Chicago*IL*34592*US~
<OrderHeader>
<ItemOut>
<Contact>
<PostalAddress>

Ref. Data Base User
<PostalAddress>
<City>
<PostalAddress>
<State>
for United States)
A US Zip Code can be five or nine digits. A Canadian Postal Code is always formatted
"A9A9A9".
<PostalAddress>
<PostalCode>
<PostalAddress>
<Country>
isoCountryCode %isoCountryCode #REQUIRED


Position: 400
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 3
Semantic Notes:
Comments:
Notes: Example:
PER*CR*Stefanie - Sales*TE*18005552429*EM*Stefanie.Devereux@thebuyer.com~
PER*CR**TE*18005558288*UR*http://www.thebuyer.com/Sales/~
Several PER's are allowed. The contact communications fragments are merged according
to their name attributes. Those with the same name are placed in the same segment.
<OrderRequest>
<ItemOut>
<Contact>

Ref. Data Base User
AM Administrator
CN General Contact
EB Entered By
Free-form name
EM Electronic Mail
FX Facsimile
TE Telephone
EM Electronic Mail
FX Facsimile
TE Telephone

EM Electronic Mail
FX Facsimile
TE Telephone

Segment: N1 Delivery Address

Position: 350
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
Comments: 1 This segment used alone provides the most efficient method of providing
Notes: Example: N1*DA*SNVS~
This section of N1 allows you to enter the delivery address from terms of delivery.
<OrderRequest>
<TermsOfDelivery>
<Address>

Ref. Data
DA Delivery Address
N102 93 Name X AN 1/60
Free-form name


Position: 370
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 2
Syntax Notes:
Semantic Notes:
Comments:
Notes: N3*123 Anystreet~
In cXML, Street is required if PostalAddress is present.
<OrderRequest>
<TermsOfDelivery>
<Address>

Ref. Data Base User
Address information


Position: 380
Loop: N1 Optional
Level: Detail
Usage: Optional
Max Use: 1
Semantic Notes:
specify a location.
Notes: N4*Sunnyvale*AL*35762*US~
<OrderRequest>
<TermsOfDelivery>
<Address>
<State>AL</State>
</PostalAddress>
</Address>

Ref. Data Base User
<OrderRequest>
<TermsOfDelivery>
<Address>
<OrderRequest>
<TermsOfDelivery>
<Address>
<State>AL</State>
for United States)
<OrderRequest>
<TermsOfDelivery>
<Address>


Country code is ISO-3166 compliant. For a list of country codes their respective currency
codes:
<OrderRequest>
<TermsOfDelivery>
<Address>

Segment: CTT Transaction Totals

Position: 010
Loop: CTT Optional
Level: Summary
Usage: Optional
Max Use: 1
Purpose: To transmit a hash total for a specific element in the transaction set
Syntax Notes: 1 If either CTT03 or CTT04 is present, then the other is required.
2 If either CTT05 or CTT06 is present, then the other is required.
Semantic Notes:
Comments: 1 This segment is intended to provide hash totals to validate transaction completeness
and correctness.
Notes: Example: CTT*15*151~

Ref. Data Base User
CTT01 354 Number of Line Items M N0 1/6 M
Total number of line items in the transaction set
CTT02 347 Hash Total O R 1/10 O
Sum of values of the specified data element. All values in the data element will be summed
without regard to decimal points (explicit or implicit) or signs. Truncation will occur on the
left most digits if the sum is greater than the maximum size of the hash total of the data
element. Example: -.0018 First occurrence of value being hashed. .18 Second occurrence of
value being hashed. 1.8 Third occurrence of value being hashed. 18.01 Fourth occurrence
of value being hashed. --------- 1855 Hash total prior to truncation. 855 Hash total after
truncation to three-digit field.

Segment: AMT Monetary Amount

Position: 020
Loop: CTT Optional
Level: Summary
Max Use: 1
Purpose: To indicate the total monetary amount
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example: AMT*TT*322.18~
Transaction total for the entire Purchase Order. This is what the Buyer is expecting to
pay.
<OrderRequest>
<Total>
<Money>
#PCDATA

Ref. Data Base User
AMT01 522 Amount Qualifier Code M ID 1/3 M
Code to qualify amount
TT Total Transaction Amount
AMT02 782 Monetary Amount M R 1/18 M
Monetary amount

Segment: SE Transaction Set Trailer

Position: 030
Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Purpose: To indicate the end of the transaction set and provide the count of the transmitted
segments (including the beginning (ST) and ending (SE) segments)
Syntax Notes:
Semantic Notes:
Comments: 1 SE is the last segment of each transaction set.

Ref. Data Base User
SE01 96 Number of Included Segments M N0 1/10 M
Total number of segments included in a transaction set including ST and SE segments
SE02 329 Transaction Set Control Number M AN 4/9 M
Identifying control number that must be unique within the transaction set functional group
assigned by the originator for a transaction set

850 Purchase Order

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

850 Purchase Order

Uploaded by

Copyright:

Available Formats

Ariba, Inc. cXML 1.

2: ANSI X12 004010 850 Purchase Order Implementation Guidelines

850 Purchase Order

Functional Group ID= PO

The separator characters normally used are:

On returning a 997, the following points should be noted:

AK5 acknowledgement codes:

AK9 acknowledgement codes:

Status Segment Element

22 130 ITD Terms of Sale/Deferred Terms of Sale O >1

Copyright (c) 2007-2015 Ariba, Inc. 2 Revised 4 August 2015

Copyright (c) 2007-2015 Ariba, Inc. 3 Revised 4 August 2015

LOOP ID - PID 1000

663 210 DTM Requested Delivery Date O 1

Copyright (c) 2007-2015 Ariba, Inc. 4 Revised 4 August 2015

86 030 SE Transaction Set Trailer M M 1

Transaction Set Notes

Copyright (c) 2007-2015 Ariba, Inc. 5 Revised 4 August 2015

Segment: ST Transaction Set Header

Data Element Summary

Copyright (c) 2007-2015 Ariba, Inc. 6 Revised 4 August 2015

Segment: BEG Beginning Segment for Purchase Order

BEG*00*NE*DO364**20000415~ (new order)

Data Element Summary

Note that BEG03 can store an order number containing 22

This is available only if EDI is selected for routing

REF*PO (1/050) contains another copy of the purchase order

Code 03 for Delete is chosen to parallel the cXML type attribute

Copyright (c) 2007-2015 Ariba, Inc. 7 Revised 4 August 2015

The "Change Order" is not a manifest listing of changes, but is

Note that providing this suffix is a recommended practice and

New order (replacement of the original order) number:

The attribute, BEG01='05', indicates that the original purchase

The original order number being replaced is found in REF*PW

Note that BEG03 contains an order number up to 22 characters in

Although the cXML type attribute value is "update", the code 05

BEG02 92 Purchase Order Type Code M ID 2/2 M

Extrinsic name is OrderType and ExtrinsicData is

<OrderRequestHeader orderType="blanket" >

<OrderRequestHeader orderType="release" >

Copyright (c) 2007-2015 Ariba, Inc. 9 Revised 4 August 2015

Segment: CUR Currency

Data Element Summary

Copyright (c) 2007-2015 Ariba, Inc. 10 Revised 4 August 2015

Segment: REF Reference Identification

Then, REF01 will be 0L and REF02 will be FOB05

This is available to support purchase order numbers that are greater

Reserved for Ariba Buyer to be sending the PO revision number. Ariba

Copyright (c) 2007-2015 Ariba, Inc. 11 Revised 4 August 2015

RQ Purchase Requisition Number

EZ Electronic Data Interchange Agreement Number

Identifies the associated agreement corresponding to the release order.

Copyright (c) 2007-2015 Ariba, Inc. 12 Revised 4 August 2015

Segment: PER Administrative Communications Contact

Data Element Summary

Copyright (c) 2007-2015 Ariba, Inc. 13 Revised 4 August 2015

Copyright (c) 2007-2015 Ariba, Inc. 14 Revised 4 August 2015

Segment: FOB F.O.B. Related Instructions

Data Element Summary

Copyright (c) 2007-2015 Ariba, Inc. 17 Revised 4 August 2015

Segment: CSH Sales Requirements

Data Element Summary

Copyright (c) 2007-2015 Ariba, Inc. 18 Revised 4 August 2015

BEG00NE*DO364**20000415~ (new order)