Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Order Models Index | Supporting Documentation | Downloads | FAQs |
EIDX Order Models - Supporting Documentation

Data Element Usage Recommendations 

Special Notes:   

Identifying Order Type and Subtype

Blanket Purchase Orders are sent in the same ASC X12 transaction or UN-EDIFACT message, BOD, or PIP business document as Standalone (Discrete) Purchase Orders.  Typically, these two order types are processed differently, and many trading partners using different mappings for the different order types and process them in different applications.

Likewise, Changes to Blanket Purchase Orders are sent in the same X12 transaction or EDIFACT message as Changes to Standalone (Discrete) Purchase Orders.  Like the different order types, these change order types may be processed differently, and many trading partners using different mappings for the different order types and process them in different applications.

The ASC X12 and EDIFACT standards also allow releases to be sent in the same transaction/message as purchase orders or the same transaction/message as change orders.   Changes to Releases can be sent in the same transaction/message as change orders.  See Releases Against Blanket Purchase Orders - Non-Forecast Environment.

Some applications need to be able to distinguish order sub-type, i.e. whether or not the order is for a drop-shipment and/or whether the order is for consignment inventory. 

Ideally, the receiving application should be responsible for identifying which type of order or change order or release or change to release is being processed.  Identification of the type of transaction/message should be located at the beginning of the transaction/message.  No two applications are alike; for some applications, an order is an order is an order, and so is a release, and a change is a change.  For other applications, different order types are handled as distinctly different business documents or business processes, with separate interfaces.

Changes to BPO's and Releases Against BPO's can be distinguished by the Purchase Order Type Code in some standards.  However, in ASC X12 and EDIFACT, changes to a BPO and Changes to a Discrete (Stand-alone) PO both use the same Change Purchase Order Type Code.  If both types of orders are maintained in the application, then the application should be able to identify what's what by looking up the type of the original order (if different processing is required for different order types).

No two standards handle order type identification the same way.   Not all standards support identifying  both order type and order subtype.

Because the standard handle order typing so differently, separate tables are presented below for how each standard identifies order types.  Consignment and Drop Ship are covered separately in each table.

ASC X12

X12 BEG02/BCH02 (DE92)

X12 BEG01/BCH01 (DE353)

Meaning Comment

BE

00 or 06 Blanket Order / Estimated Quantities, Original or Confirmation May be used when BPO is issued for a total (not-to-exceed) dollar amount, and quantity sent in PO102 Quantity Ordered is based on total dollars divided by unit price.  Not all trading partners may be able to accommodate this code; in this case, trading partners may agree to use “BK” instead.
BK 00 or 06 Blanket Order (Quantity Firm), Original or Confirmation May be used when BPO is issued for a total (not-to-exceed) quantity.  For trading partners that cannot accommodate code “BE”, this code may be used, and the fact that the quantity is an estimate must be called out in the business agreement.
CP 00 or 06 Change to Purchase Order, Original or Confirmation For discrete (stand-alone) orders, used for all changes the purchase order, including cancellation.

Used when transmitting changes to the BPO other than new schedule releases; used also for changes to schedules that have already been released; used also when the original BPO was transmitted with pre-defined schedules and those schedules are being changed.

CP 01 Change to Purchase Order, Cancellation Used to cancel discrete purchase orders or blanket purchase orders.
CR 00 or 06 Change to Release (Blanket Order) / Call-Off Order, Original or Confirmation Used when transmitting a change to a previously transmitted release.
RL 00 or 06 Release (Blanket Order) / Call-Off Order, Original or Confirmation Used when transmitting new schedule releases in a non-forecast environment when the original BPO did not contain pre-defined schedules.

SA

00 or 06 Stand-alone (Discrete) Purchase Order, Original or Confirmation Used when transmitting new discrete, stand-alone purchase order.

X12 N101 (DE98)

Meaning Comment

DS

Drop-Ship Party Used to identify a drop-ship party; if a N1*DS segment is sent, the order is a de facto drop-ship order subtype.

X12 BEG12 (DE640)

Meaning Comment
C3 Consignment Normally, consignment orders are not explicitly identified.  Consignment is by pre-agreement between parties.  The buyer's and seller's applications should be be coded to automatically identify which products/parts are on consignment processes and which are not.

 

UN/EDIFACT

UN BGM01-1
(DE C002.1001)

UN BGM03
(DE 1225)

Meaning Comment
105 9 or 42 Stand-alone (Discrete) Purchase Order, Original or Confirmation Used when transmitting new discrete, stand-alone purchase order.
221 9 or 42 Blanket Order, Original or Confirmation Used for all Blanket Orders
226 9 or 42 Call-off Order, Original or Confirmation Used when transmitting new schedule releases in a non-forecast environment when the original BPO did not contain pre-defined schedules.
226 5 Call-off Order, Replace Used when transmitting changes to releases.  Automation of changes to releases are not recommended by EIDX or EDIFICE.
230 9 or 42 Purchase order change request, Original or Confirmation For discrete (stand-alone) orders, used for all changes the purchase order, including cancellation.

Used when transmitting changes to the BPO other than new schedule releases; used also when the original BPO was transmitted with pre-defined schedules and those schedules are being changed.

UN QTY01-1
(DE C186.6063)

Meaning Comment
21 Ordered Quantity May be used when BPO is issued for a total (not-to-exceed) quantity.  For trading partners that cannot accommodate code “99”, this code may be used, and the fact that the quantity is an estimate may be called out in the business agreement.
99 Estimated Quantity May be used when BPO is issued for a total (not-to-exceed) dollar amount.  Not all trading partners may be able to accommodate this code; in this case, trading partners may agree to use “21 instead if this is an estimated quantity, and this must be called out in the business agreement.

UN NAD01-1
(DE 3035)

Meaning Comment
DS Drop Ship Used to identify a drop-ship party; if a N1*DS segment is sent, the order is a de facto drop-ship order subtype.

UN BGM01-1
(DE C002.1001)

Meaning Comment
227 Consignment Order Used when transmitting new discrete, stand-alone purchase order or a blanket order that is for consignment business process.  Note:  the standard does not allow you to specify both “Standard” and “Consignment order” or both “Blanket” and “Consignment” order; partners will have to agree whether orders for consigned inventory are always ‘Standalone’ or always ‘Blanket’ or a mix of ‘Standalone’ and ‘Blanket’.
227 Consignment Order Normally, consignment orders are not explicitly identified.  Consignment is by pre-agreement between parties, and the buyer and seller systems should know which products/parts are on consignment processes and which are not.

 

OAGIS

OAGIS POTYPE

Meaning Comment

Use ASC X12
DE92
Code List

See X12 section. See X12 section.

OAGIS DROPSHIP

Meaning Comment
No Not a drop-ship order Used when order is for drop-ship to a party other than the buyer.   The field 'DROPSHIP' is not listed in the Purchase Order definition, but may be included in the 'USER AREA'
Yes Drop-ship order Drop-ship order.  The field 'DROPSHIP' is not listed in the Purchase Order definition, but may be included in the 'USER AREA'

OAG OWNRSHPCDE

Meaning Comment
?? Consignment The field 'OWNRSHIPCDE' is not listed in the Purchase Order definition, but may be included in the 'USER AREA'

 

<
RosettaNet

RN GlobalPurchaseOrderTypeCode

Meaning Comment
Blanket Blanket Order, Maximum Quantity Order quantity for blanket type purchase order is understood to be a blanket quantity maximum.  See also Business Document note.
Standard Stand-alone (Discrete) Purchase Order Used when transmitting new discrete, stand-alone purchase order that is not for consignment process.  Note:  This is an only an approximate equivalent, since not all Stand-alone orders are Standard orders.
Consigned order See comment. Used when transmitting new discrete, stand-alone purchase order or a blanket order that is for consignment process.  Note:  the standard does not allow you to specify both “Standard” and “Consignment order” or both “Blanket” and “Consignment” order; partners will have to agree whether orders for consigned inventory are always ‘Standalone’ or always ‘Blanket’ or a mix of ‘Standalone’ and ‘Blanket’.
RN isDropShipAffirmationIndicator Meaning Comment
No Not a drop-ship order Used when order is for drop-ship to a party other than the buyer.
Yes Drop-ship order Drop-ship order

 


Unit Price

Unit price should be sent even if it is specified in a TCA or pricing agreement.  Most systems are designed to read the price from individual purchase orders.  Unit price is used in matching acknowledgments, invoices, payments, and other related documents.

<toBeAdded>examples of situations where there is no price - price is tbd; distinguish between no price and price set to zero.</toBeAdded>


Conveying Delivery Schedules

In ASC X12, delivery schedules are sent at the detail level in SCH segments; the primary difference between actual delivery schedules and “dummy” delivery schedules is in the coding of the Date/Time Qualifier.  In UN-EDIFACT, delivery schedules are sent using the SCC, QTY and DTM segments in Segment Groups 48 and 49; the primary difference between actual delivery schedules and “dummy” delivery schedules is in the coding of the DTM segment.

<toBeAdded>OAG and RNet</toBeAdded>>
 

X12 SCH05 (DE374) / UN C507.2005

MEANING

COMMENT

002 / 2

Delivery Requested

Use for actual schedules, or for “dummy” schedule only per trading partner agreement

010 / 10

Requested Ship

017 / 17

Estimated Delivery

011 / 11

Shipped Used on order acknowledgments and re-acknowledgments; both open and closed (shipped) schedules need to be included for a line item, so that the entire line item quantity is accounted for.  See Schedules-What to Send in section on PO Responses/Acknowledgments.

036 / 36

Expiration (Date Coverage Expires)

On Blanket Purchase Orders (BPOs), use for “dummy” schedules if BPO has an expiration date; in the Quantity element, use the total line item quantity or zero, based on trading partner agreement; in the Date element, use the expiration date of the BPO.

038 / 38

Ship No Later

063 / 63

Do Not Deliver After

037 / 37

Do Not Ship Before

Use for “dummy” schedules if BPO is quantity-based with no set expiration date and no pre-defined schedules; in the Quantity element, use the total line item quantity or zero, based on trading partner agreement; in the Date element, use the effective date of the BPO.

064 / 64

Do Not Deliver Before

050 / 50

Received Used on Change Orders; both open and closed (received) schedules need to be included for a line item, so that the entire line item quantity is accounted for.  See Schedules-What to Send in section on Change Orders.

 


Buyer- vs. Seller-Initiated Changes

Sellers should set the Transaction Set Purpose Code (BCA01) to '00' in the 865 transaction when acknowledging buyer  initiated changes.

Sellers should set the Transaction Set Purpose Code (BCA01) to '19' in the 865 transaction when acknowledging seller initiated changes.  If the seller initiated changes conveyed in the acknowledgment 865 transaction are unacceptable to the buyer, an 860 transaction can be sent to request another set of dates.   If needed, further communications with the seller outside of the EDI process may be necessary.

Both buyer and seller initiated changes in any 865 transaction should be processed the similarly by the buyer’s system.  The major purpose of acknowledgments is to convey the scheduled ship or delivery date.  Supplier schedule dates are already established in the sales order system as noted in the 865 transaction.

Last updated 05 January 2003