Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

855 Purchase Order Acknowledgment PR

Functional Group ID=

Introduction: This Draft Standard for Trial Use contains the format and establishes the data contents of the Purchase Order Acknowledgment Transaction Set (855) 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 a seller's acknowledgment of a buyer's purchase order. This transaction set can also be used as notification of a vendor generated order. This usage advises a buyer that a vendor has or will ship merchandise as prearranged in their partnership.

Notes: Ariba SN allows Suppliers to send Order Confirmations to Buyers in the form of the cXML ConfirmationRequest. As a service to Suppliers preferring to transact via EDI, Ariba SN accepts the ANSI X12 004010 855 Purchase Order Acknowledgment document. On receiving the 855 (documented here), Ariba SN validates the EDI content, returns a 997 to the Supplier, and converts it to the cXML ConfirmationRequest. The final cXML document is internally posted to process the actual order confirmation. If an error arises at the application level, an email notification is sent to the Supplier, advising the failure and the reason. Ariba SN does not currently implement the 824 Application Advice. All separator characters within the ANSI X12 domain are allowed. You do not need to use the same separators that you receive on your 850. The recommended separators are: Segment Terminator: Element Separator: Sub-Element Separator:

~ (tilde) * (asterisk) > (greater than)

* Note that different VANs have different separator char requirements. They are usually modified in transit. These three chars are always written to all inbound interchanges to Ariba SN by Sterling Commerce. Needless to say, these three chars must not occur within your data itself. On the returning 997, the following points should be noted. Summary 997's are implemented, returning AK2/AK5 segments. Detailed 997's with AK3 and AK4 segments are not supported at this time. Interchanges are not acknowledged. Do not expect a TA1 segment. ISA14 should be set to 0, and is ignored. AK5 acknowledgement codes: - Code "A" constitutes acceptance. A cXML ConfirmationRequest was successfully prepared for submission to Ariba SN. This only means that it cleared the EDI gateway -- not that it passed all business rules in Ariba SN. - Code "E" is an EDI Compliance error. If you receive this in an AK5, it means that the 810 was not converted and did not make it past our EDI gateway. - Code "R" represents total rejection. Ariba SN EDI does not currently implement this code. AK9 acknowledgement codes: Copyright (c) 2000 - 2004, Ariba, Inc.

1

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

- 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: Status ----------------------Mandatory Must Use Recommended Dependant Not Recommended Not Used

Segment -----------M Must Use R D NR X

Element ----------M M (Required) R D NR 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 SN requires it. Recommended means that X12 says it is optional, and Ariba SN considers it optional, but recommends that it be used. Dependant means that X12 might have its usage dependant on other segments or elements, or by semantic notes, or that Ariba SN describes semantics on which its dependency lies. Not Recommended is the opposite of Recommended. The information may 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 No. 4

Pos. No. 010

Seg. ID ST

5

020

BAK

8

040

9

050

10

080

Base Status M

Name Transaction Set Header

User Status M M

Max.Use 1

M

CUR

Beginning Segment for Purchase Order Acknowledgment Currency

O

1

REF

Reference

O

3

FOB

F.O.B. Related Instructions

O

1

Notes and Comments

1

LOOP ID - SAC

2

12

120

SAC

Service, Promotion, Allowance, or Charge Information

O

15

150

DTM

O

19

275

TXI

Date/Time Reference - Acknowledgement Date Tax Information

1 Must Use

O

1 99

LOOP ID - N9

1

24

280

N9

Reference Identification - Comments

O

1

26

290

MSG

Message Text

O

99

27

280

N9

Reference Identification - Extrinsic

O

1

29

290

MSG

Message Text

O

99

LOOP ID - N9

99

LOOP ID - N1

99

30

300

N1

Contact Information - Name

O

31

310

N2

Additional Name Information

O

2

32

320

N3

Address Information

O

2

33

330

N4

Geographic Location

O

1

Copyright (c) 2000 - 2004, Ariba, Inc.

Loop Repeat

2

Rec

1

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines 36

350

PER

Administrative Communications Contact

O

99

Detail: Page No.

Pos. No.

Seg. ID

Base Status

39

010

PO1

Baseline Item Data

O

41

040

CTP

Pricing Information

O

42

270

ACK

Line Item Acknowledgment

O

Must Use

1

44

280

DTM

Date/Time Reference

O

Rec

1

Name LOOP ID - PO1

User Status D

Max.Use

Loop Repeat 100000

1

Notes and Comments n1

1

LOOP ID - ACK

104

LOOP ID - N1

99

47

370

N1

Name

O

1

48

380

N2

Additional Name Information

O

2

49

390

N3

Address Information

O

2

50

400

N4

Geographic Location

O

1

51

420

PER

Administrative Communications Contact

O

3

Summary: Page No.

Pos. No.

Seg. ID

Base Status

52

010

CTT

Transaction Totals

O

53

020

AMT

Monetary Amount

O

54

030

SE

Transaction Set Trailer

M

Name LOOP ID - CTT

User Status Must Use

M

Max.Use

Loop Repeat 1

Notes and Comments

1

n2

1

n3

1

Transaction Set Notes 1. 2. 3.

PO102 is required. 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. If AMT is used in the summary area, then AMT01 will = TT and AMT02 will indicate total transaction amount as calculated by the sender.

Copyright (c) 2000 - 2004, Ariba, Inc.

3

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

Segment: Position: Loop: Level: Usage: Max Use: Purpose: Syntax Notes: Semantic Notes: Comments: Notes:

ST Transaction Set Header 010 Heading Mandatory 1 To indicate the start of a transaction set and to assign a control number 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).

Example: ST*855*0001~ produces... Data Element Summary

Ref. Des. ST01

Data Element 143

ST02

329

Base User Name Attributes Attributes Transaction Set Identifier Code M ID 3/3 M Code uniquely identifying a Transaction Set 855 Purchase Order Acknowledgment 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

Copyright (c) 2000 - 2004, Ariba, Inc.

4

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

Segment: Position: Loop: Level: Usage: Max Use: Purpose: Syntax Notes: Semantic Notes: Comments: Notes:

BAK Beginning Segment for Purchase Order Acknowledgment 020 Heading Mandatory 1 To indicate the beginning of the Purchase Order Acknowledgment Transaction Set and transmit identifying numbers and dates 1 2 3

BAK04 is the date assigned by the purchaser to purchase order. BAK08 is the seller's order number. BAK09 is the date assigned by the sender to the acknowledgment.

Example: BAK*00*AC*D-0115-1612h*20010111****ORDSP4125874*20010110~ produces... ... * The order number and order date supplied by BAK were combined with the buyer's id and cross-referenced in the AN database. The complete orderDate and payloadID were then retrieved and filled in. Mapping target: ...

Data Element Summary Ref. Des. BAK01

Data Element 353

Name Transaction Set Purpose Code Code identifying purpose of transaction set

Base Attributes M ID 2/2

User Attributes M

M

M

operation (new | update) 00 (Original) --> "new" 05 (Replace) --> "update"

BAK02

587

00 Original 05 Replace Acknowledgment Type Code specifying the type of acknowledgment

type (accept | detail | except | reject)

ID 2/2

#REQUIRED

"AC" --> "detail", "AE" --> "except", "AT" --> "accept", "RJ" --> "reject" Copyright (c) 2000 - 2004, Ariba, Inc.

5

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

AC

AE

Acknowledge - With Detail and Change type="detail" A separate line item (PO1 group) is required in the 855 to confirm each individual line item in the purchase order. Acknowledge - With Exception Detail Only type="except" Very useful for large purchase orders with few exceptions. You provide a PO1 group for each PO line item that is not accepted "as is". (i.e. backordered, rejected, etc.) Any PO line item not referenced with an 855 line item will be marked as "confirmed as is".

AT

Ack type AE with no line items is equivalent to ack type AT. Ack type AE with all line items is equivalent to ack type AC. Accepted type="accept" Sets the entire purchase order to confirmed "as is". Line items (PO1 groups) are allowed in the 855, but the only allowed status type is "accept" (ACK01="IA"). With this status type, you may still fill in the shipment and delivery dates for individual line items.

RJ

Every line item in the order will be set to confirmed, whether it has a PO1 group in the 855 or not. Rejected - No Detail type="reject" Total rejection of the entire purchase order. This is the opposite of ack type AT. No line item (PO1 groups) are allowed in the 855, and every line item in the PO will be marked as rejected.

BAK03

324

You may use the N9 group to provide comments as to the reason why, if you wish. Purchase Order Number M AN 1/22 M Identifying number for Purchase Order assigned by the orderer/purchaser Purchase Order Number, copied from the 850's BEG03 orderID %string;

BAK04

373

#IMPLIED

Date Date expressed as CCYYMMDD Purchase Order date, copied from the 850's BEG05 orderDate %datetime.tz;

M

DT 8/8

M

#IMPLIED

Note that only the date portion is available to be mapped.

BAK08

127

Reference Identification O AN 1/30 M Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier

Copyright (c) 2000 - 2004, Ariba, Inc.

6

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

Supplier's order number. This is used for the confirmation identifier. confirmID %string;

BAK09

373

#IMPLIED

Date O DT 8/8 O Date expressed as CCYYMMDD Order date is accepted, but is ignored. The required noticeDate for the acknowledgment is preferred from DTM*ACK at 1/150 to allow complete date/time/zone specification.

Copyright (c) 2000 - 2004, Ariba, Inc.

7

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

Segment: Position: Loop: Level: Usage: Max Use: Purpose: Syntax Notes:

Semantic Notes: Comments: Usage Notes: Notes:

CUR Currency 040 Heading Optional 1 To specify the currency (dollars, pounds, francs, etc.) used in a transaction 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. 4 If CUR11 is present, then CUR10 is required. 5 If CUR12 is present, then CUR10 is required. 6 If CUR13 is present, then at least one of CUR14 or CUR15 is required. 7 If CUR14 is present, then CUR13 is required. 8 If CUR15 is present, then CUR13 is required. 9 If CUR16 is present, then at least one of CUR17 or CUR18 is required. 10 If CUR17 is present, then CUR16 is required. 11 If CUR18 is present, then CUR16 is required. 12 If CUR19 is present, then at least one of CUR20 or CUR21 is required. 13 If CUR20 is present, then CUR19 is required. 14 If CUR21 is present, then CUR19 is required. 1 See Figures Appendix for examples detailing the use of the CUR segment. Used/Optional Example: CUR*BY*USD~ produces... Mapping target: currency %isoCurrencyCode;

#REQUIRED

Data Element Summary Ref. Des. CUR01

Data Element 98

CUR02

100

Base User Name Attributes Attributes Entity Identifier Code M ID 2/3 M Code identifying an organizational entity, a physical location, property or an individual BY Buying Party (Purchaser) Currency Code M ID 3/3 M Code (Standard ISO) for country in whose currency the charges are specified

Copyright (c) 2000 - 2004, Ariba, Inc.

8

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

Segment: Position: Loop: Level: Usage: Max Use: Purpose: Syntax Notes: Semantic Notes: Comments: Usage Notes: Notes:

REF Reference 050 Heading Optional 3 To specify identifying information 1 At least one of REF02 or REF03 is required. 2 If either C04003 or C04004 is present, then the other is required. 3 If either C04005 or C04006 is present, then the other is required. 1 REF04 contains data relating to the value cited in REF02. Used/Optional Example: REF*IL*1234567~ REF*IV*INV34572~ produces... * Note - REF*IL is used internally by the EDI system. It has no cXML counterpart. Mapping target:

Data Element Summary Ref. Des. REF01

Data Element 128

REF02

127

Base User Name Attributes Attributes Reference Identification Qualifier M ID 2/3 M Code qualifying the Reference Identification IL Internal Order Number Ariba SN Internal Order Number This is the internal order number used by Ariba SN. It positively and unambiguously identifies an order. A future version of the 850 will supply this number which suppliers can simply echo. IV Seller's Invoice Number If the supplier already has an invoice number assigned to the order, Reference Identification X AN 1/30 O Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier

Copyright (c) 2000 - 2004, Ariba, Inc.

9

Revision 7, March 2004

Ariba, Inc. cXML 1.2: ANSI X12 004010 855 PO Acknowledgment Implementation Guidelines

Segment: Position: Loop: Level: Usage: Max Use: Purpose: Syntax Notes:

Semantic Notes:

Comments: Usage Notes: Notes:

FOB F.O.B. Related Instructions 080 Heading Optional 1 To specify transportation instructions relating to shipment 1 If FOB03 is present, then FOB02 is required. 2 If FOB04 is present, then FOB05 is required. 3 If FOB07 is present, then FOB06 is required. 4 If FOB08 is present, then FOB09 is required. 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. Used/Optional Example: FOB*DE***01*CFR~ produces... Data Element Summary

Ref. Des. FOB01

Data Element 146

FOB04

334

FOB05

335

Base User Name Attributes Attributes Shipment Method of Payment M ID 2/2 M Code identifying payment terms for transportation charges DE Per Contract Destination with exceptions as agreed between buyer and seller Transportation Terms Qualifier Code O ID 2/2 M Code identifying the source of the transportation terms 01 Incoterms Transportation Terms Code X ID 3/3 M Code identifying the trade terms which apply to the shipment transportation responsibility The cXML incoTerms attribute requires that the code here be translated to lowercase. For example: incoTerms="cfr" where FOB05="CFR" Mapping target: