EDIFACT-Subsets
EDIFACT stands for Electronic Data Interchange for Administration, Commerce and Transport and has been in constant development by the United Nations since 1986. This standard is known under the name UN/EDIFACT. Whilst working on standardising the UN/EDIFACT format, numerous requirements from all industries needed consideration. However, although this may have helped broaden the UN/EDIFACT standard and make it more flexible, it also complicated its actual use.
A simple invoice may, for instance, include many optional elements and different identifiers may be used for the identification of the involved companies and products, etc. Before they can create an actual EDIFACT invoice, the sender and receiver need to agree on the subset of segments they will be invoked when exchanging files. If it were the case, that both parties always needed to agree on a specific subset, this would inevitably lead to a huge and unnecessary number of different subsets, and therefore reduce the benefits of EDI through the time needed to make the subsets compliant.
It is therefore advisable to agree on certain standard EDIFACT-subsets. These EDIFACT subsets are derived from the EDIFACT standard and were tailored to suit a specific user group. Mandatory elements are defined according to the EDIFACT subset and additional specifications laid down (e.g. identifiers to use, date formats, code lists, etc.).
These subsets apply to whole industries (e.g. paper, steel or consumer goods industry), including at the corporate level.
The diagram below illustrates the subset approach.
Individual subsets based on the UN/EDIFACT standard were defined for different industries. The globally most used EDIFACT subset is EANCOM (abbreviation of EAN + Communication) and GS1 is continuing its development for the consumer goods industry. Other subsets include, for instance, EDIGAS (gas industry) or EDIFICE (high-tech industry).
EANCOM exists today in three different versions (D93A, D96A and D01B). Major companies such as REWE or Metro are also defining their own subsets based on the EANCOM subset.
EANCOM-Subset
EANCOM is being developed by the GS1 organisation for global standards and is a 100% subset of the UN/EDIFACT standard for the consumer goods industry. Since the EANCOM standard is highly popular, it is by now also used in other industries, such as the health sector. As opposed to the very extensive UN/EDIFACT standard, EANCOM reduces the various EDI messages to essential fields that are mandatory to specific business processes or for specific message types. The EANCOM standard currently includes about 50 different message types.
As the name suggests already, the EANCOM standard is based on the GS1 identification system (GLN, GTIN,SSCC, etc.). The use of globally unique GS1 identification allows effective and uniform processing of EDI messages. Every sender and recipient will, for instance, be uniquely identified by it’s GLN – thus excluding confusion caused by proprietary identifiers. The same applies to product identification using GTINs and identification of packages using SSCCs.
EANCOM also defines the logical sequence of messages used in a specific business area. The diagram below illustrates message flows that may be depicted with EANCOM. In addition to buyers and sellers, communication between logistics service providers and banks is also included.
EANCOM – Participating Companies
The individual EANCOM message types may be roughly classified into the following four categories:
- Master data reconciliation
These message types are used for the exchange of master data for products and for involved trading partners. The master data is therefore stored in the systems of the involved partners and used for message transactions afterwards. This will, for instance, ensure that only the most recent product identifiers and prices will be used. - Transactions
These message types are used to order goods, organise their transportation and pay for goods received. - Reporting and planning
These message types are used for the exchange of data allowing future planning. Examples include Sales Reports or Inventory Reports, used to communicate current product sales figures to a supplier. The supplier may use this information to plan his own production. - Miscellaneous
The message types in this category serve various purposes, such as the exchange of additional information required by the different industries.
Overview of EANCOM message types
The diagram below offers an overview of the most important EANCOM message types and the order of the message exchange.
The three most important message types by far are ORDERS (order), DESADV (despatch advice) and INVOIC (invoice).
Price list/Catalogue (PRICAT)
A supplier will send a PRICAT message with a list of all relevant product data to his customers. A supplier will send a PRICAT message to customers whenever the product range changes.
Order (ORDERS)
A customer will transmit an ORDERS message to a supplier to order products and services. An order will typically also include the required quantity, date and place of delivery. The GTIN codes for the ordered products and services and the GLNs used will typically have been received via a previous PRICAT message.
It is also possible to leave out the master data reconciliation using PRICAT, if the parties have exchanged beforehand the lists with the product codes, e.g. on an Excel sheet. However, this might present a few drawbacks, such as input errors due to media faults, etc…
Transport order (IFTMIN)
A supplier will transmit an IFTMIN message to a logistics service provider to order transportation of goods.
Despatch message (DESADV)
Suppliers will send a DESADV message to notify customers of impending deliveries, prior to arrival of the goods at the customer. DESADV messages are particularly relevant to large companies since DESADV messages will allow coordination of their own goods receipt logistics (such as cross-docking warehouses).
Transport status (IFTSTA)
Logistics service providers will use IFTSTA messages to confirm shipment of an order to their client (in this case the supplier). The time of sending this message will be agreed on between the shipping agent and supplier. An IFTSTA message may, for instance, be sent once every day, at the time a shipment is executed, etc.
Arrival message (IFTMAN)
A shipping agent may send an IFTMAN message to the recipient of the goods (in this case the customer) to notify of imminent delivery. Similar to a DESADV, the purpose would be better planning of goods receipt logistic by the customer.
Goods receipt notification (RECADV)
Customers may send a RECADV message to confirm receipt of a specific shipment. This will allow the customer to, for instance, notify the supplier of deviations of quantities supplied or of his rejection of specific shipments.
Invoice (INVOIC)
The supplier may use an INVOIC message to transmit an invoice to his customer.
Banker’s order (PAYMUL)
The customer may use a PAYMUL message to transmit payment instructions to his bank. The bank will on receipt of this message pay the invoice amount to the account of the supplier.
Credit note (CREMUL)
A bank will use a CREMUL message to inform the supplier of payments made by his customer.
Questions?
Do you have any more questions about EANCOM? Please do contact us or use our chat – we’re more than happy to help!
