eORDERS; V 2.0   <<< back

Introduction

1. How the eORDERS guideline is organized

The eORDERS recommendation is based on the framework of EANCOM^® 2002, the EDI standard from GS1 within the GS1 system. The aim of the recommendation in hand is to offer documentation describing the exchange of ordering data between business partners in Europe.

The basis of this elaboration is the international standard EANCOM^® 2002. The message type ORDERS D01B EAN010 is used to transmit relevant data. Please be aware, however, that this documentation does not replace the complete specifications in the original chapters, or other relevant instructions within the EANCOM^® 2002 documentation. Instead, it deals with the description of segments, data elements and codes to be used for a specific task.

So far, the following countries have contributed to this recommendation:

• Austria

• Belgium/Luxembourg

• Czech Republic

• Denmark

• Finland

• France

• Germany

• Ireland

• Italy

• Netherlands

• Poland

• Portugal

• Spain

• Sweden

• Switzerland

• United Kingdom

Also users have contributed to this recommendation:

• Carrefour

• Metro

• Procter & Gamble

All relevant information content i.e. business terms of each country has been created. The total of all of the business terms used by those countries compromise the set of business terms used in the European profile.

2. How to navigate

This guideline provides various options for navigation. We provide two profiles: When selecting the core profile, only the information used in most business contexts is displayed. When selecting the European (all) profile also the information that only is used in specific business contexts is displayed. Generally, all information is provided in English.

Further information regarding the use of EANCOM^®/EDIFACT can be obtained from Appendix 1 (chapter 5) of Part 1 of the EANCOM^®-manual.

The eORDERS message implementation guideline is divided into four sections:

Section 1, "Alphabetic list of Business Terms"
In this section the Business Terms which are used in the selected profile are listed in alphabetic order. Within this Business Term list is a harmonised definition of each Business Term and, if applicable, additional comments and/or dependency notes are provided.

Within the table, the Status of each Business Term in each profile is provided. This status information is linked to the relevant segment in the Segments Layout. The following abbreviations are used for status indication:

R = Required
O = Optional
D = Depending
N = Not Used

By clicking on the 'core' and 'all' buttons, the profiles can be selected.

Section 2, "Message Structure Chart"
The message structure chart is a list of all segments used, in the same sequence as they are defined in the EANCOM^® message. In general, for each piece of information, a single segment is provided. Exceptions may arise when the occurrence of a segment is limited and can contain alternative information (e.g., segment BGM). By clicking on the 'core' and 'all' buttons, the profiles can be selected.

Section 3, "Branching Diagram"
The branching diagram is a hierarchical graphic depiction of all segments used, in the same sequence as they are defined in the EANCOM^® message. However, every segment is shown only once. By clicking on the 'core' and 'all' buttons, the profiles can be selected.

Section 4, "Segments Layout"
The segments layout provides an illustration that has been chosen to match the Business Terms with the elements from the EANCOM^® syntax.

In the right-hand column "description" the Business Term, the definition and the comments /dependency notes are provided. The Business Term is linked to the Business Term List. The "Legend" is linked to this chapter of the introduction. Further information on applying EANCOM^®/EDIFACT messages, e.g. status indicators, conventions, field length etc. can be obtained from Appendix 1 (chapter 5) of Part 1 of the EANCOM^®-manual.

By clicking on the 'core' and 'all' buttons, the profiles can be selected, if the relevant segment is part of the chosen profile. The segment notes show the status of all order types.

In general, code names are represented in red; these must be understood as being restricted. If codes are given as examples, they are represented in blue (e.g., measurement units). In this case, all codes contained in the relevant code list can be used. By clicking on the codes or the data element/code list number, the codes which are used in this guideline are displayed.

The ORDERS message is divided into three sections:

1. Heading section
Specification of parties, dates, references, payment terms, allowances/charges, transport conditions etc.

2. Detail section
Specification of GTIN to identify goods and/or services, their quantity, price etc.

3. Summary section
The summary section contains number the of line items in the document.

3. General aspects

3.1 Identification of trade items

A basic element of EANCOM^® is the GS1 System. Each trade item, "item" being defined in the widest possible sense, is uniquely identified by a Global Trade Item Number (GTIN). This number is part of the common vocabulary adopted by the partners who are exchanging standard messages.

The format and use of a GTIN is explained in the GS1 General Specifications.

3.2 Identification of parties and locations

The identification of the trading partners is a critical issue when using Electronic Data Interchange. It is even more important to identify locations precisely and unambiguously with EDI than with traditional paper documents.

The identification of parties and locations within EDI messages is the primary application for the Global Location Number (GLN). Within EANCOM^® a message and a number of segments exist for the purpose of identifying parties.

The GLN is explained in detail in the GS1 General Specifications.

3.3 Data alignment

Data which do not vary between transactions such as terms of delivery, shipping, and payment agreements, prices, clear text for Global Location Number (GLN) and Global Trade Item Number (GTIN) should be part of the underlying business contract and accessible by the respective party's business application, for use as appropriate. Each trade item must be numbered (and bar-coded) with its Global Trade Item Number, GTIN. In some cases, however, additional information such as article text may be provided, if the master data is not available - e.g. where a central payment service provider is involved.

3.4 Message number

Order Number assigned by document sender. The order number must be unique by document. It is recommended that the length of document number be restricted to a maximum of 17 characters.

3.5 Reference number

The effective use of EANCOM^® depends on the use of referencing to reduce the quantity of data required to be transmitted in any message. Referencing provides the opportunity to link messages with multiple pieces of external information which may or may not have been transmitted using EDI. The RFF segment allows references to other documents to be transmitted without a need to transmit the actual documents.

Within EANCOM^® messages several references exist which can be used to link the information exchanged between the trading partners with the physical movement of goods or data.

The only method available within EANCOM^® to uniquely identify a previous EANCOM^® message is to put the message number (generated in DE 1004 of the BGM segment of the original message) in data element 1154 of the RFF segment. Should it be required to identify an individual line (identified by Line Item Number data element 1082 in the LIN segment of the original message), then this should be put in data element 1156 alongside the message number in data element 1154 of the RFF segment.

4. Recommendations for ordering

Within the working group, some general recommendations regarding the ordering and the application of EANCOM^® messages have been elaborated.

The recommended information flow for ordering is based on best practice and should be applied as follows:

4.1 General recommendation for orders types

Order
A message specifying details for goods or services ordered under conditions agreed between the seller and the buyer.

In Europe this kind of order is normally used, but other types of the order are also implemented as:

Blanket order
Usage of document/message for general order purposes with later split into quantities and delivery dates and maybe delivery locations.

Rush order
Document/message for urgent ordering.

Call off order
Document/message to provide split quantities and delivery dates referring to a previous blanket order.

Standing order
An order to supply fixed quantities of products at fixed regular intervals.

Consignment order
Order to deliver goods into stock with agreement on payment when goods are sold out of this stock.

Repair order
Document/message to order repair of goods.

4.1.1 Direct store deliveries

In a direct store delivery approach each store orders separately. The direct store order has the same business requirement and information as an order sent from buyer to supplier. The goods are supplied directly to store and not through a distribution centre or a warehouse.

A direct store delivery is identified in the ALI-Segment (Code 148). If the store is not identical with the buyer it must be indicated in an additional NAD Segment (NAD+DP).

4.1.2 Recommendation for Transshipment and Cross Docking Orders

Transshipment order
An order requesting the supply of products packed according to the final delivery point which will be moved across a dock in a distribution centre (DC) without further handling.

Cross docking order
An order requesting the supply of products which will be de-consolidated in the distribution centre (DC) and re-consolidated according to final delivery location.

4.1.3 Vendor Managed Orders, Co Managed Orders

Vendor Managed Inventory (VMI)
When the supplier maintains the replenishment system, sales and inventory information must be transmitted by the buyer to the supplier as often as the replenishment system is executed; this information is used by the supplier's replenishment system as historical data for future requirement calculations and adjustments to the next production cycle. (Source: GS1 "Continuous replenishment")

Co Managed Inventory (CMI)
When the replenishment system is co-managed, sales and inventory information must be transmitted by the buyer to the supplier as often as the replenishment system is executed; this information is used by the supplier's replenishment system as historical data for future requirement calculations and adjustments to the next production cycle. (Source: GS1 "Continuous replenishment")

4.2 Dates and formats

4.2.1 Type of dates

Message section
The table hereafter indicated for each information date, if it is indicated at the header and/or line level of the European orders:

If an information date is indicated at the header section then the specification of the heading section can be overwritten at the detail level.

Status
The table hereafter indicated the status for each information date in the European Order and the European VMI and CMI order:

Dependencies
The table hereafter summarises which dates can be indicated with other dates in the European orders:

4.2.2 Format

The choice of the format date must mutually defined between the partners according the list proposed in this guide.

© GS1 in Europe