As a service to Suppliers preferring to transact via EDI, Ariba SN accepts the ANSI X12 004010 856 Ship Notice / Manifest document.

856 Ship Notice/Manifest Introduction: Functional Group ID=SH This Draft Standard for Trial Use contains the format and establishes the data contents of the Ship Notice/Manifest Transaction Set (856) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to list the contents of a shipment of goods as well as additional information relating to the shipment, such as order information, product description, physical characteristics, type of packaging, marking, carrier information, and configuration of goods within the transportation equipment. The transaction set enables the sender to describe the contents and configuration of a shipment in various levels of detail and provides an ordered flexibility to convey information. The sender of this transaction is the organization responsible for detailing and communicating the contents of a shipment, or shipments, to one or more receivers of the transaction set. The receiver of this transaction set can be any organization having an interest in the contents of a shipment or information about the contents of a shipment. Notes: Ariba SN allows Suppliers to send Ship Notices to Buyers in the form of the cxml ShipNoticeRequest. This is a fulfilment document to the cxml OrderRequest. As a service to Suppliers preferring to transact via EDI, Ariba SN accepts the ANSI X12 004010 856 Ship Notice / Manifest document. On receiving the 856 (documented here), Ariba SN validates the EDI content, returns a 997 to the Supplier, and converts it to the cxml ShipNoticeRequest. The final cxml document is internally posted to perform the actual fulfilment update. 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, but is ignored. AK5 acknowledgement codes: - Code "A" constitutes acceptance. A cxml ShipNoticeRequest was successfully prepared for submission to Ariba SN. - Code "E" is an EDI Compliance error. If you receive this in an AK5, it means that the 856 was not converted and did not make it past our EDI gateway. Copyright (c) 2000-2004, Ariba, Inc. 1 Revision 6, March 2004

- Code "R" represents total rejection. Ariba SN EDI does not currently implement this code. AK9 acknowledgement codes: - The above codes apply. Code "P" is possible if not all AK5's are code "A". Ariba SN Network Support is available to help resolve technical issues with EDI. Suppliers are requested to open cases if they need assistance. The ideal way to create a case is to complete the Network Support help form on supplier.ariba.com. Ariba Commerce Services Network: network_support@ariba.com Ariba Marketplace, Network Edition: marketned_support@ariba.com Main Support Phone: 888-89ARIBA / 888-892-7422 In reading this Implementation Guide, the following usage codes are used: Status Segment Element ----------------------- ------------ ----------- Mandatory M M Must Use Must Use M Recommended R R 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 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 Pos. Seg. Base User Loop Notes and No. No. ID Name Status Status Max.Use Repeat Comments 4 010 ST Transaction Set Header M M 1 5 020 BSN Beginning Segment for Ship Notice M M 1 7 040 DTM Date/Time Reference O 2 Detail: Page Pos. Seg. Base User Loop Notes and No. No. ID Name Status Status Max.Use Repeat Comments LOOP ID - HL 1 10 010 HL Hierarchical Level - Shipment M M 1 11 120 TD5 Carrier Details (Routing Sequence/Transit O 1 Time) LOOP ID - N1 200 13 220 N1 Name O 1 Copyright (c) 2000-2004, Ariba, Inc. 2 Revision 6, March 2004

15 230 N2 Additional Name Information O 2 16 240 N3 Address Information O 2 17 250 N4 Geographic Location O 1 20 270 PER Administrative Communications Contact O 3 LOOP ID - HL 200000 22 010 HL Hierarchical Level - Order M M 1 24 050 PRF Purchase Order Reference O Must Use 1 25 150 REF Reference Identification O 1 LOOP ID - N1 200 26 220 N1 Name O 1 27 230 N2 Additional Name Information O 2 28 240 N3 Address Information O 2 29 250 N4 Geographic Location O 1 30 270 PER Administrative Communications Contact O 3 LOOP ID - HL 200000 31 010 HL Hierarchical Level - Line Item M M 1 c1 32 030 SN1 Item Detail (Shipment) O Must Use 1 33 060 PO4 Item Physical Details O 1 Summary: Page Pos. Seg. Base User Loop Notes and No. No. ID Name Status Status Max.Use Repeat Comments 36 010 CTT Transaction Totals O 1 n1 37 020 SE Transaction Set Trailer M M 1 Transaction Set Notes 1. Number of line items (CTT01) is the accumulation of the number of HL segments. If used, hash total (CTT02) is the sum of the value of units shipped (SN102) for each SN1 segment. Transaction Set Comments 1. The HL segment is the only mandatory segment within the HL loop, and by itself, the HL segment has no meaning. Copyright (c) 2000-2004, Ariba, Inc. 3 Revision 6, March 2004

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*856*0001~ produces... <ShipNoticeRequest> ST01 143 Transaction Set Identifier Code M ID 3/3 M Code uniquely identifying a Transaction Set 856 Ship Notice/Manifest 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 Copyright (c) 2000-2004, Ariba, Inc. 4 Revision 6, March 2004

Segment: BSN Beginning Segment for Ship Notice Position: 020 Loop: Level: Heading Usage: Mandatory Max Use: 1 Purpose: To transmit identifying numbers, dates, and other basic data relating to the transaction set Syntax Notes: 1 If BSN07 is present, then BSN06 is required. Semantic Notes: 1 BSN03 is the date the shipment transaction set is created. 2 BSN04 is the time the shipment transaction set is created. 3 BSN06 is limited to shipment related codes. Comments: 1 BSN06 and BSN07 differentiate the functionality of use for the transaction set. Notes: Example: BSN*00*843-2187-5193*20010903*121844*0004~ produces... <ShipNoticeRequest> <ShipNoticeHeader shipmentid="843-2187-5193" operation="new" noticedate="2001-09-03t12:18:44-0000"...> BSN01 353 Transaction Set Purpose Code M ID 2/2 M Code identifying purpose of transaction set The (optional) operational mode of ship notice document. An "update" ship notice (BSN01='05') allows a supplier to correct an error in a ship notice or to add additional information learned later. In either case, an "update" document must be complete: All data from the original should be discarded by the recipient. A "delete" ship notice (BSN01='03') removes the changes described in the previous ShipNoticeRequest (either original or a previous replacement) from the state of the shipment. This operation should be used only when the supplier discards a planned shipment or incorrectly sends a ShipNoticeRequest about a shipment that will not take place. An "replace" or "delete" ship notice must have the same Shipment Identifier (BSN02) as the previous version of the notice. This provides an unambiguous and direct connection between all versions of the ship notice. * Note that the 856 supports Delete and Replace options here, to map into similar cxml operation values. However, the AN35 release does not yet support this. <ShipNoticeHeader operation=bsn01> operation (new update delete) "new" #REQUIRED 00 Original <ShipNoticeHeader operation="new"> 03 Delete <ShipNoticeHeader operation="delete"> * Reserved for future use - not supported by AN 05 Replace <ShipNoticeHeader operation="update"> * Reserved for future use - not supported by AN Copyright (c) 2000-2004, Ariba, Inc. 5 Revision 6, March 2004

BSN02 396 Shipment Identification M AN 2/30 M A unique control number assigned by the original shipper to identify a specific shipment An identifier for this particular shipment assigned by the supplier. This value does not vary as a particular ship notice is updated. That is, BSN01="03" or BSN01="05" documents describing the same shipment must share a shipmentid with the original (BSN01="00") Ship Notice. <ShipNoticeHeader shipmentid=bsn02> shipmentid %string; #REQUIRED BSN03 373 Date M DT 8/8 M Date expressed as CCYYMMDD The date this ship notice was created. <ShipNoticeHeader noticedate=bsn03+bsn04> BSN04 337 Time M TM 4/8 M 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) The time this ship notice was created. <ShipNoticeHeader noticedate=bsn03+bsn04> BSN05 1005 Hierarchical Structure Code O ID 4/4 O Code indicating the hierarchical application structure of a transaction set that utilizes the HL segment to define the structure of the transaction set 0004 Shipment, Order, Item Copyright (c) 2000-2004, Ariba, Inc. 6 Revision 6, March 2004

Segment: DTM Date/Time Reference Position: 040 Loop: Level: Heading Usage: Optional Max Use: 2 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: Usage Notes: Used/Optional Notes: Example: DTM*011*20010903*0830*ED~ DTM*017*20010904*0900*20~ produces... <ShipNoticeHeader... shipmentdate="2001-09-03t08:30:00-0400" deliverydate="2001-09-04t09:00:00-0500"> * DTM04="ED" represents Eastern Daylight Time, which is UTC-0400 DTM04="20" represents ISO M05, which is -05, hence UTC-0500 Specify the Shipment Date and/or Estimated Delivery Date. Both are optional, but the Shipment Date is recommended. Note that a complete date/time/zone is recommended. Timestamps in cxml are represented as a date with a time, and an offset to UTC. If you do not specify a time, it may be taken as midnight on the date specified. If you do not specify the time code (zone), then it will be defaulted. <ShipNoticeHeader shipmentdate %datetime.tz; #IMPLIED = DTM02 + DTM03 + DTM04 where DTM01 = "011" > deliverydate %datetime.tz; #IMPLIED = DTM02 + DTM03 + DTM04 where DTM01 = "017" DTM01 374 Date/Time Qualifier M ID 3/3 M Code specifying type of date or time, or both date and time 011 Shipped 017 Estimated Delivery DTM02 373 Date X DT 8/8 M Date expressed as CCYYMMDD DTM03 337 Time X TM 4/8 R TM 4/6 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 R Code identifying the time. In accordance with International Standards Organization Copyright (c) 2000-2004, Ariba, Inc. 7 Revision 6, March 2004

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 Note that the LT code is not available. This is because Ariba SN does not currently have a way to make a context-sensitive assumption on the time zone. The ISO codes are favorable because you have direct control over the output, but they do not support half hour zones as in Newfoundland. (If you need Newfoundland time, NS & NT map to -0330, ND maps to -0230) 01 Equivalent to ISO P01 02 Equivalent to ISO P02 03 Equivalent to ISO P03 04 Equivalent to ISO P04 05 Equivalent to ISO P05 06 Equivalent to ISO P06 07 Equivalent to ISO P07 08 Equivalent to ISO P08 09 Equivalent to ISO P09 10 Equivalent to ISO P10 11 Equivalent to ISO P11 12 Equivalent to ISO P12 13 Equivalent to ISO M12 14 Equivalent to ISO M11 15 Equivalent to ISO M10 16 Equivalent to ISO M09 17 Equivalent to ISO M08 18 Equivalent to ISO M07 19 Equivalent to ISO M06 20 Equivalent to ISO M05 21 Equivalent to ISO M04 22 Equivalent to ISO M03 23 Equivalent to ISO M02 24 Equivalent to ISO M01 AD Alaska Daylight Time AS Alaska Standard Time AT Alaska Time CD Central Daylight Time CS Central Standard Time CT Central Time ED Eastern Daylight Time ES Eastern Standard Time ET Eastern Time GM Greenwich Mean Time HD Hawaii-Aleutian Daylight Time HS Hawaii-Aleutian Standard Time HT Hawaii-Aleutian Time MD Mountain Daylight Time MS Mountain Standard Time MT Mountain Time ND Newfoundland Daylight Time NS Newfoundland Standard Time NT Newfoundland Time Copyright (c) 2000-2004, Ariba, Inc. 8 Revision 6, March 2004

PD Pacific Daylight Time PS Pacific Standard Time PT Pacific Time TD Atlantic Daylight Time TS Atlantic Standard Time TT Atlantic Time UT Universal Time Coordinate ="Z" or "-00:00" This is Coordinated Universal Time, or UTC. The correct ISO zone extension for UTC is simply Z. However this release of Ariba SN does not support Z, so it renders as "-00:00", to distinguish it from GMT which uses "+00:00". Copyright (c) 2000-2004, Ariba, Inc. 9 Revision 6, March 2004

Segment: HL Hierarchical Level - Shipment Position: 010 Loop: HL Mandatory Level: Detail Usage: Mandatory Max Use: 1 Purpose: To identify dependencies among and the content of hierarchically related groups of data segments Syntax Notes: Semantic Notes: Comments: 1 The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to lineitem data. The HL segment defines a top-down/left-right ordered structure. 2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction. 3 HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate. 4 HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information. 5 HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment. Notes: Example: HL*1**S*1~ At the Shipment level, we specify information concerning the shipment as a whole. This includes carrier and route information. HL01 628 Hierarchical ID Number M AN 1/12 M A unique number assigned by the sender to identify a particular data segment in a hierarchical structure HL02 734 Hierarchical Parent ID Number O AN 1/12 NR Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to Since Shipment is the root of the hierarchical tree, it has no parent id. The Shipment level only should leave this element as null. (Marked NR here for consistency only). HL03 735 Hierarchical Level Code M ID 1/2 M Code defining the characteristic of a level in a hierarchical structure S Shipment HL04 736 Hierarchical Child Code O ID 1/1 O Code indicating if there are hierarchical child data segments subordinate to the level being described 1 Additional Subordinate HL Data Segment in This Hierarchical Structure. Copyright (c) 2000-2004, Ariba, Inc. 10 Revision 6, March 2004

Segment: TD5 Carrier Details (Routing Sequence/Transit Time) Position: 120 Loop: HL Mandatory Level: Detail 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. 3 If TD507 is present, then TD508 is required. 4 If TD510 is present, then TD511 is required. 5 If TD513 is present, then TD512 is required. 6 If TD514 is present, then TD513 is required. 7 If TD515 is present, then TD512 is required. Semantic Notes: 1 TD515 is the country where the service is to be performed. Comments: 1 When specifying a routing sequence to be used for the shipment movement in lieu of specifying each carrier within the movement, use TD502 to identify the party responsible for defining the routing sequence, and use TD503 to identify the actual routing sequence, specified by the party identified in TD502. Usage Notes: Used/Optional Notes: Example: TD5**2*NSTY*J*Nasty Express**ZZ*DEA24597281772****ND~ produces... <ShipNoticeRequest> <ShipNoticeHeader...> <ServiceLevel xml:lang="en">next Day Air</ServiceLevel>... </ShipNoticeHeader> <ShipControl> <CarrierIdentifier domain="scac">nsty</carrieridentifier> <CarrierIdentifier domain="companyname">nasty Express</CarrierIdentification> <ShipmentIdentifier>DEA24597281772</ShipmentIdentifier> <Route method="motor" /> <ShipControl>... Carrier and routing information is summed in a single TD5 segment. In this release, only one carrier for the shipment is supported. If carrier information is being supplied here, Ariba SN requires identification of the carrier. Both the coded identification (TD502-03) and the carrier name (TD505) are required. It is possible to merge complete carrier company contact information with N1*CA (1/220, this level) by matching TD502-03 with N103-04. TD502 66 Identification Code Qualifier X ID 1/2 M Code designating the system/method of code structure used for Identification Code (67) Elements 2 and 3 are used to identify the carrier. Note the element id's: 66 & 67. They must match N103 and N104 (also 66 & 67) for N101='CA' to provide full carrier contact information. The Standard Carrier Alpha Code (SCAC) is recommended (TD502='2'). <ShipControl> <CarrierIdentifier domain=td502>td503</carrieridentifier> Copyright (c) 2000-2004, Ariba, Inc. 11 Revision 6, March 2004

1 D-U-N-S Number, Dun & Bradstreet 2 Standard Carrier Alpha Code (SCAC) 4 International Air Transport Association (IATA) TD503 67 Identification Code X AN 2/80 M Code identifying a party or other code TD504 91 Transportation Method/Type Code X ID 1/2 O Code specifying the method or type of transportation for the shipment <ShipControl> <Route method=td504> method (air motor rail ship) #REQUIRED A Air method="air" J Motor method="motor" R Rail method="rail" S Ocean method="ship" TD505 387 Routing X AN 1/35 M Free-form description of the routing or requested routing for shipment, or the originating carrier's identity Carrier's company name. Note that full carriercorporate contact information can be supplied in an N1, in which N103 and N104 match TD502 and TD503. This level of detail is optional. If such an N1 is supplied, and N102 is provided, then N102 takes precedance over TD505. The carrier company name is required, so if you're not providing full carrier contact information with N102, then TD505 is required. <ShipControl> <CarrierIdentifier role="companyname">td505</carrieridentifier> TD507 309 Location Qualifier O ID 1/2 M Code identifying type of location ZZ Mutually Defined TD508 310 Location Identifier X AN 1/30 M Code which identifies a specific location Carrier assigned reference / tracking id for their part of the shipment. Identifier that appears on this shipment and through which additional detail about the shipment may be retrieved. Defined by the carrier. Conceptually, this is a tracking number. Different carriers have different names for shipment identifiers. Some call it a way bill number, others call it a pro number, and still others call it a bill of lading. They all represent tracking numbers. <ShipmentIdentification>TD508</ShipmentIdentification> TD512 284 Service Level Code X ID 2/2 O Code indicating the level of transportation service or the billing service offered by the transportation carrier All ANSI X12 defined codes are allowed here. The description from the ANSI Standard is mapped into the <ServiceLevel> element. Refer to 004010 Data Element Dictionary for acceptable code values. Copyright (c) 2000-2004, Ariba, Inc. 12 Revision 6, March 2004

Segment: N1 Name Position: 220 Loop: N1 Optional Level: Detail Usage: Optional Max Use: 1 Purpose: To identify a party by type of organization, name, and code Syntax Notes: 1 At least one of N102 or N103 is required. 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. Usage Notes: 2 N105 and N106 further define the type of entity in N101. Used/Optional Notes: Example: N1*CA*Nasty Express*2*NSTY~ produces... <Contact role="carriercorporate"> <Name xml:lang="en">nasty Express</Name>... High level contact information regarding the shipment. It is not generally necessary to copy information from the Purchase Order: Contacts here should be used primarily to add information to that known about an order. Suppliers may optionally include contact information for their EDI Administrator under N101=SU with a PER01=EA. If you are entering a Postal Address, the <PostalAddress> structure in cxml mandates at least one <Street>, a <City> and a <Country>. Therefore, N3 and N4 become mandatory. <ShipNoticeRequest> <ShipNoticeHeader> <Contact> N101 98 Entity Identifier Code M ID 2/3 M Code identifying an organizational entity, a physical location, property or an individual <Contact role=n101> 60 Salesperson Identification of individual that sold the product e.g. SSN, salesperson id, etc. <Contact role="sales"> A9 BY CA Sales Office A business entity whose main activity is, or a location at which, the sale of goods or services takes place <Contact role="customerservice"> Buying Party (Purchaser) <Contact role="buyercorporate"> Carrier Copyright (c) 2000-2004, Ariba, Inc. 13 Revision 6, March 2004

<Contact role="carriercorporate"> KY SF ST Technical Office <Contact role="technicalsupport"> Ship From <Contact role="shipfrom"> (starting point for this shipment) <Contact role="shipfrom"> Ship To <Contact role="shipto"> (Should echo ShipTo (N101="ST") from Purchase Order) <Contact role="shipto"> SU Supplier/Manufacturer <Contact role="suppliercorporate"> N102 93 Name X AN 1/60 M Free-form name <Name> is a required element for any contact. <Contact> <Name> N103 66 Identification Code Qualifier X ID 1/2 O Code designating the system/method of code structure used for Identification Code (67) N103 and N104 are required only if N101='CA', and in this case must match their counterparts in TD502 and TD503 to provide carrier contact information. 1 D-U-N-S Number, Dun & Bradstreet 2 Standard Carrier Alpha Code (SCAC) 4 International Air Transport Association (IATA) N104 67 Identification Code X AN 2/80 O Code identifying a party or other code Copyright (c) 2000-2004, Ariba, Inc. 14 Revision 6, March 2004

Segment: N2 Additional Name Information Position: 230 Loop: N1 Optional Level: Detail Usage: Optional Max Use: 2 Purpose: To specify additional names or those longer than 35 characters in length Syntax Notes: Semantic Notes: Comments: Usage Notes: Used/Optional Notes: Example: N2*Shipping Dept.~ produces... <DeliverTo>Shipping Dept.</DeliverTo> * Note that the <DeliverTo> element is just a textual name. It is still used even if the role is Ship From, despite the apparent word dissimilation. N201 93 Name M AN 1/60 M Free-form name N202 93 Name O AN 1/60 O Free-form name Copyright (c) 2000-2004, Ariba, Inc. 15 Revision 6, March 2004

Segment: N3 Address Information Position: 240 Loop: N1 Optional Level: Detail Usage: Optional Max Use: 2 Purpose: To specify the location of the named party Syntax Notes: Semantic Notes: Comments: Usage Notes: Used/Optional Notes: Example: N3*123 Anywhere St.*Suite C~ produces... <Street>123 Anywhere St.</Street> <Street>Suite C</Street> N301 166 Address Information M AN 1/55 M Address information N302 166 Address Information O AN 1/55 O Address information Copyright (c) 2000-2004, Ariba, Inc. 16 Revision 6, March 2004

Segment: N4 Geographic Location Position: 250 Loop: N1 Optional Level: Detail 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. Usage Notes: 2 N402 is required only if city name (N401) is in the U.S. or Canada. Used/Optional Notes: Example: N4*Dallas*TX*75216*US~ produces... <PostalAddress>... <City>Dallas</City> <State>TX</State> <PostalCode>75216</PostalCode> <Country isocountrycode="us">united STATES</Country> * The Country name is resolved by the EDI inbound process using a lookup on the ISO- 3166 country code in N404. An invalid country code may throw a compliance error. 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 D Code (Standard State/Province) as defined by appropriate government agency For addresses in the United States or Canada, use the two letter digraph recognized by the United States Postal Service or Canada Post. Official State and Territory codes are published by the US Postal Service here: http://www.usps.gov/ncsc/lookups/abbr_state.txt All codes for US and Canada are listed here for convenience. Ariba SN may fail a document if N402 and N404 contradict <Contact> <PostalAddress> <State> AB Alberta AK Alaska AL Alabama AR Arkansas AS American Samoa AZ Arizona BC British Columbia Copyright (c) 2000-2004, Ariba, Inc. 17 Revision 6, March 2004

CA California CO Colorado CT Connecticut DC District of Columbia DE Delaware FL Florida FM Federated States of Micronesia GA Georgia GU Guam HI Hawaii IA Iowa ID Idaho IL Illinois IN Indiana KS Kansas KY Kentucky LA Louisiana MA Massachusetts MB Manitoba MD Maryland ME Maine MH Marshall Islands MI Michigan MN Minnesota MO Missouri MP Northern Mariana Islands MS Mississippi MT Montana NB New Brunswick NC North Carolina ND North Dakota NE Nebraska NF Newfoundland NH New Hampshire NJ New Jersey NM New Mexico NS Nova Scotia NT Northwest Territories NU Nunavut NV Nevada NY New York OH Ohio OK Oklahoma ON Ontario OR Oregon PA Pennsylvania PE Prince Edward Island PR Puerto Rico PW Palau QC Quebec Copyright (c) 2000-2004, Ariba, Inc. 18 Revision 6, March 2004

RI Rhode Island SC South Carolina SD South Dakota SK Saskatchewan TN Tennessee TX Texas UT Utah VA Virginia VI Virgin Islands VT Vermont WA Washington WI Wisconsin WV West Virginia WY Wyoming YT Yukon N403 116 Postal Code O ID 3/15 R Code defining international postal zone code excluding punctuation and blanks (zip code for United States) Zip codes will be either five or nine digits with no separator. Canadian postal codes must be formatted A9A9A9, with no separator. Ariba SN may validate a Zip/Postal code to correspond to the State or Province code in N402, if N404="US" or "CA", and cause the document to fail if it is obviously wrong. <Contact> <PostalAddress> <PostalCode> 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: http://www.unece.org/trade/rec/rec09en.htm Copyright (c) 2000-2004, Ariba, Inc. 19 Revision 6, March 2004

Segment: PER Administrative Communications Contact Position: 270 Loop: N1 Optional Level: Detail 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. 3 If either PER07 or PER08 is present, then the other is required. Semantic Notes: Comments: Usage Notes: Used/Optional Notes: Example: PER*CN*Lucille Winters*TE*18005551212*EM*lucyw@thesupplier.org~ produces... <Contact>... <Phone name="lucille Winters"> <TelephoneNumber> <CountryCode isocountrycode="us">1</countrycode> <AreaOrCityCode>800</AreaOrCityCode> <Number>5551212</Number> <TelephoneNumber> </Phone> <Email name="lucille Winters">lucyw@thesupplier.org</Email> Breaking down telephone numbers is obviously complex due to the cxml requirements. In processing, any separator characters are removed and the number is scanned from left to right using telephony techniques. It is recommended that numbers in the NANP (North American Numbering Plan) domain, that is US and Canada, start with a 1. If exactly ten digits are present without a leading 1, then a leading 1 is assumed. If the number has a leading 1 and is longer than eleven digits, then the overflow goes into the <Extension> element. Incomplete telephone numbers, even seven digit numbers, may cause compliance errors or confusing results to the buyer. * Since the isocountrycode is required in the final mapping, N404 may be used if it is available to resolve the US / CA ambiguity. PER01 366 Contact Function Code M ID 2/2 M Code identifying the major duty or responsibility of the person or group named CN General Contact Use for all regular contacts. PER02 93 Name O AN 1/60 O Free-form name * Note: The example here shows a person's name. It is perfectly acceptable to put a category in PER02, such as "work", "mobile", "home", etc. In fact, that is the intended Copyright (c) 2000-2004, Ariba, Inc. 20 Revision 6, March 2004

purpose of the "name" attribute in cxml. A suggestion here is that if N102 identifies a person, then categories are appropriate here. Furthermore, PER02 and the "name" attribute are purely optional. 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 PER05 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) PER06 364 Communication Number X AN 1/80 O Complete communications number including country or area code when applicable PER07 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) PER08 364 Communication Number X AN 1/80 O Complete communications number including country or area code when applicable Copyright (c) 2000-2004, Ariba, Inc. 21 Revision 6, March 2004

Segment: HL Hierarchical Level - Order Position: 010 Loop: HL Mandatory Level: Detail Usage: Mandatory Max Use: 1 Purpose: To identify dependencies among and the content of hierarchically related groups of data segments Syntax Notes: Semantic Notes: Comments: 1 The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to lineitem data. The HL segment defines a top-down/left-right ordered structure. 2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction. 3 HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate. 4 HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information. 5 HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment. Notes: Example: HL*2*1*O*1~ produces... <ShipNoticePortion> At the Order level, you can supply reference information about each order included in the shipment. It is allowable to only go as deep as the order level and just omit item specific information. This implies that the entire order is included in the shipment. This simplified method also avoids entering packaging information. * Note that although the 856 and <ShipNoticeRequest> allow multiple orders per shipment notice, the current release of Ariba SN does not. This will be enhanced in a future release. Presently, only one order can be cited in a ship notice. If multiple orders are part of the same shipment, then separate 856 documents, with matching BSN02 are required. HL01 628 Hierarchical ID Number M AN 1/12 M A unique number assigned by the sender to identify a particular data segment in a hierarchical structure HL02 734 Hierarchical Parent ID Number O AN 1/12 M Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to Copyright (c) 2000-2004, Ariba, Inc. 22 Revision 6, March 2004

Must be the Hierarchical ID Number (DE0628) of the Shipment level (typically = 1) HL03 735 Hierarchical Level Code M ID 1/2 M Code defining the characteristic of a level in a hierarchical structure O Order HL04 736 Hierarchical Child Code O ID 1/1 M Code indicating if there are hierarchical child data segments subordinate to the level being described Must explicitly state whether or not an item level is present. 0 No Subordinate HL Segment in This Hierarchical Structure. No child level here implies that you are including the whole order in the shipment and not providing any packaging detail. 1 Additional Subordinate HL Data Segment in This Hierarchical Structure. Copyright (c) 2000-2004, Ariba, Inc. 23 Revision 6, March 2004

Segment: PRF Purchase Order Reference Position: 050 Loop: HL Mandatory Level: Detail Usage: Optional (Must Use) Max Use: 1 Purpose: To provide reference to a specific purchase order Syntax Notes: Semantic Notes: 1 PRF04 is the date assigned by the purchaser to purchase order. Comments: Usage Notes: Mandatory Notes: Example: PRF*ORD6592***20010829~ produces... <ShipNoticePortion> <OrderReference orderid="ord6592" orderdate="2001-08-29t08:39:52-0500"> <DocumentReference payloadid="original-order-payload-id" /> </OrderReference>... The original PO is cross referenced using the Buyer's Ariba Network ID (from GS03), the Purchase Order Number (PRF01) and the Order Date (PRF04). The full date, and the payloadid, as required by cxml, are retrieved from the Ariba SN database. Only Purchase Orders that were routed by Ariba SN can be referenced. Any PO originating from the Buyer through Ariba SN "can" be referenced. It does not necessarily have to be one that was routed as an EDI 850. PRF01 324 Purchase Order Number M AN 1/22 M Identifying number for Purchase Order assigned by the orderer/purchaser Copy from BEG03 of the Purchase Order you are fulfilling. PRF04 373 Date O DT 8/8 M Date expressed as CCYYMMDD Copy from BEG05 of the Purchase Order you are fulfilling. Copyright (c) 2000-2004, Ariba, Inc. 24 Revision 6, March 2004

Segment: REF Reference Identification Position: 150 Loop: HL Mandatory Level: Detail 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. 3 If either C04005 or C04006 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 Notes: Example: REF*IL*1234567~ (not mapped to cxml) This optional special segment may be used to echo an REF*IL segment from the 850, if it is present. In this, REF02 contains the internal PO Id used by Ariba SN. This allows the EDI inbound process to make an exact link to a Purchase Order. This gives better reliability than making a "best match" on the Buyer, Order Number, and Order Date. If present, REF02 is used conclusively. An error is thrown if it is invalid, or if the Order Number and Order Date do not match. * Tech Note - This is an integer value, typically seven or eight digits in length. The recommended reference that cxml compliant suppliers must use is the payloadid. This is a string up to 250 chars in length. It may be made available in a future release of the 850. However, due to its length it cannot reliably be stored in REF03. An N9/MSG structure would be used and that structure is not always available in fulfilment documents. Therefore, the internal PO Id is chosen as something more EDI friendly. REF01 128 Reference Identification Qualifier M ID 2/3 M Code qualifying the Reference Identification IL Internal Order Number Ariba SN PO Id 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 Copyright (c) 2000-2004, Ariba, Inc. 25 Revision 6, March 2004

Segment: N1 Name Position: 220 Loop: N1 Optional Level: Detail Usage: Optional Max Use: 1 Purpose: To identify a party by type of organization, name, and code Syntax Notes: 1 At least one of N102 or N103 is required. 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. Usage Notes: 2 N105 and N106 further define the type of entity in N101. Used/Optional Notes: Order level contact infomation is available here. It is not necessary (though not prohibited) to echo all contacts, BillTo, ShipTo, etc. from the Purchase Order. This group is provided to supplement the information from the Purchase Order with additional information filled in by the supplier. * See notes on Shipment level N1 group. All the same rules apply, except that there is no carrier address. <ShipNoticeRequest> <ShipNoticePortion> <Contact> N101 98 Entity Identifier Code M ID 2/3 M Code identifying an organizational entity, a physical location, property or an individual 60 Salesperson Identification of individual that sold the product e.g. SSN, salesperson id, etc. A9 Sales Office A business entity whose main activity is, or a location at which, the sale of goods or services takes place BT Bill-to-Party BY Buying Party (Purchaser) KY Technical Office RI Remit To SF Ship From ST Ship To SU Supplier/Manufacturer N102 93 Name X AN 1/60 M Free-form name Copyright (c) 2000-2004, Ariba, Inc. 26 Revision 6, March 2004

Segment: N2 Additional Name Information Position: 230 Loop: N1 Optional Level: Detail Usage: Optional Max Use: 2 Purpose: To specify additional names or those longer than 35 characters in length Syntax Notes: Semantic Notes: Comments: Usage Notes: Used/Optional N201 93 Name M AN 1/60 M Free-form name N202 93 Name O AN 1/60 O Free-form name Copyright (c) 2000-2004, Ariba, Inc. 27 Revision 6, March 2004

Segment: N3 Address Information Position: 240 Loop: N1 Optional Level: Detail Usage: Optional Max Use: 2 Purpose: To specify the location of the named party Syntax Notes: Semantic Notes: Comments: Usage Notes: Used/Optional N301 166 Address Information M AN 1/55 M Address information N302 166 Address Information O AN 1/55 O Address information Copyright (c) 2000-2004, Ariba, Inc. 28 Revision 6, March 2004

Segment: N4 Geographic Location Position: 250 Loop: N1 Optional Level: Detail 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. Usage Notes: 2 N402 is required only if city name (N401) is in the U.S. or Canada. Used/Optional 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 N403 116 Postal Code O ID 3/15 O Code defining international postal zone code excluding punctuation and blanks (zip code for United States) N404 26 Country Code O ID 2/3 M Code identifying the country Copyright (c) 2000-2004, Ariba, Inc. 29 Revision 6, March 2004

Segment: PER Administrative Communications Contact Position: 270 Loop: N1 Optional Level: Detail 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. 3 If either PER07 or PER08 is present, then the other is required. Semantic Notes: Comments: Usage Notes: Used/Optional PER01 366 Contact Function Code M ID 2/2 M Code identifying the major duty or responsibility of the person or group named CN General Contact PER02 93 Name O AN 1/60 O Free-form 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 PER05 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) PER06 364 Communication Number X AN 1/80 O Complete communications number including country or area code when applicable PER07 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) PER08 364 Communication Number X AN 1/80 O Complete communications number including country or area code when applicable Copyright (c) 2000-2004, Ariba, Inc. 30 Revision 6, March 2004

Segment: HL Hierarchical Level - Line Item Position: 010 Loop: HL Mandatory Level: Detail Usage: Mandatory Max Use: 1 Purpose: To identify dependencies among and the content of hierarchically related groups of data segments Syntax Notes: Semantic Notes: Comments: 1 The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to lineitem data. The HL segment defines a top-down/left-right ordered structure. 2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction. 3 HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate. 4 HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information. 5 HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment. Notes: Example: HL*3*2*I*0~ produces... <ShipNoticeItem> The Line Item level is simply a manifest of what Items from Purchase Orders you are actually shipping. Packaging information at this level is limited to only a general description of the packaging form and its physical dimensions, so no separate packaging level is required. HL01 628 Hierarchical ID Number M AN 1/12 M A unique number assigned by the sender to identify a particular data segment in a hierarchical structure HL02 734 Hierarchical Parent ID Number O AN 1/12 M Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to Hierarchical ID Number of the parent Order. HL03 735 Hierarchical Level Code M ID 1/2 M Code defining the characteristic of a level in a hierarchical structure I Item HL04 736 Hierarchical Child Code O ID 1/1 M Code indicating if there are hierarchical child data segments subordinate to the level being described 0 No Subordinate HL Segment in This Hierarchical Structure. Copyright (c) 2000-2004, Ariba, Inc. 31 Revision 6, March 2004

Segment: SN1 Item Detail (Shipment) Position: 030 Loop: HL Mandatory Level: Detail Usage: Optional (Must Use) Max Use: 1 Purpose: To specify line-item detail relative to shipment Syntax Notes: 1 If either SN105 or SN106 is present, then the other is required. Semantic Notes: 1 SN101 is the ship notice line-item identification. Comments: 1 SN103 defines the unit of measurement for both SN102 and SN104. Usage Notes: Mandatory Notes: SN1*1*8*DZ~ produces... <ShipNoticeItem quantity="8" linenumber="1"> <UnitOfMeasure>DZN</UnitOfMeasure> * SN103 goes through a translation table to convert it to the ISO Unit of Measure code required by cxml. SN101 350 Assigned Identification O AN 1/20 M Alphanumeric characters assigned for differentiation within a transaction set Must match PO101 from a received 850. SN102 382 Number of Units Shipped M R 1/10 M Numeric value of units shipped in manufacturer's shipping units for a line item or transaction set SN103 355 Unit or Basis for Measurement Code M ID 2/2 M Code specifying the units in which a value is being expressed, or manner in which a measurement has been taken Refer to 004010 Data Element Dictionary for acceptable code values. Copyright (c) 2000-2004, Ariba, Inc. 32 Revision 6, March 2004

Segment: PO4 Item Physical Details Position: 060 Loop: HL Mandatory Level: Detail Usage: Optional Max Use: 1 Purpose: To specify the physical qualities, packaging, weights, and dimensions relating to the item Syntax Notes: 1 If either PO402 or PO403 is present, then the other is required. 2 If PO405 is present, then PO406 is required. 3 If either PO406 or PO407 is present, then the other is required. 4 If either PO408 or PO409 is present, then the other is required. 5 If PO410 is present, then PO413 is required. 6 If PO411 is present, then PO413 is required. 7 If PO412 is present, then PO413 is required. 8 If PO413 is present, then at least one of PO410 PO411 or PO412 is required. 9 If PO417 is present, then PO416 is required. 10 If PO418 is present, then PO404 is required. Semantic Notes: 1 PO415 is used to indicate the relative layer of this package or range of packages within the layers of packaging. Relative Position 1 (value R1) is the innermost package. 2 PO416 is the package identifier or the beginning package identifier in a range of identifiers. 3 PO417 is the ending package identifier in a range of identifiers. 4 PO418 is the number of packages in this layer. Comments: 1 PO403 - The "Unit or Basis for Measure Code" in this segment position is for purposes of defining the pack (PO401) /size (PO402) measure which indicates the quantity in the inner pack unit. For example: If the carton contains 24 12-Ounce packages, it would be described as follows: Data element 356 = "24"; Data element 357 = "12"; Data element 355 = "OZ". Usage Notes: 2 PO413 defines the unit of measure for PO410, PO411, and PO412. Used/Optional Notes: Example: PO4*12*1*JR*CAS**32.8*KG*0.16*CR*0.8*0.5*0.4*MR~ produces... <ShipNoticeItem...> <Packaging> <PackagingCode xml:lang="en">case</packagingcode> <Dimension quantity="32.8" type="weight"> <UnitOfMeasure>KGM</UnitOfMeasure> </Dimension> <Dimension quantity="0.16" type="volume"> <UnitOfMeasure>MTQ</UnitOfMeasure> </Dimension> <Dimension quantity="0.8" type="length"> <UnitOfMeasure>MTR</UnitOfMeasure> </Dimension> <Dimension quantity="0.5" type="width"> <UnitOfMeasure>MTR</UnitOfMeasure> </Dimension> <Dimension quantity="0.4" type="height"> <UnitOfMeasure>MTR</UnitOfMeasure> </Dimension> </Packaging> </ShipNoticeItem> A single PO4 completes the optional cxml <Packaging> section. Complete physical Copyright (c) 2000-2004, Ariba, Inc. 33 Revision 6, March 2004