The structure of EDI messages is a recursive (embedded) structure, standardised at several levels. When creating messages those involved in the standardisation project reviewed which data could possibly occur in a given document and at which levels of message organisation. This review resulted in a so-called “super-set” of data, whose elements could be organised into a previously standardised recursive structure. Actual EDI connections generally use a partial set of the data super-set, the so-called data sub-set. However, the position of sub-set data is pre-defined in the standard of the message structure. This way instead of having to reconcile the message structures (as has to be done with schemes in the case of XML, for example), only the data found in the sub-set have to be compared. The data reconciliation phase of EDI development concerns this data comparison at sub-set level. EDI also uses standard documents, the so-called Message Implementation Guidelines (MIGs) for data reconciliation, which constitute the second range of documents mentioned under the planning of EDI. Manufacturers or buyers use these documents to inform their suppliers of the data they wish to use in connection with a specific EDI message document.

Under our EDI service our clients can use the data exchanged in the file format used by their own business management software. The conversion between the EDI and the client’s (in-house) format structures is performed by our EDI service, but the business management system of our client must be capable of handling the range of sub-set data exchanged in the messages. (for example, it must be able to generate the invoice data required by the partner).

Several message types may be involved in the implementation of EDI at the client, possibly including referential data. Billing, for example, is generally based on the data of delivery notifications and receipts. During the exchange of the message a so-called message scenario is created, which the electronic document management system of our client must also take into account.

This means considerable data reconciliation activities between the partner and the systems administrator of our client, a burden that we take off their shoulders.

The business management system of our client may use any type of internal format. The most common formats are XML, CSV, and TXT.

Our services can connect at application level to the following widely used business management systems:

• SAP
• SAP Business One
• ORACLE
• MS Dynamics AX (Axapta)
• MS Dynamics NAV (Navision)
• Apolló (Multi Kft)
• Kulcs-Soft Kft
• etc.

The use of EDI messages generally differs across the various industries with regard to the type and data content structure of messages. Accordingly, different industries are characterised by different message scenarios.

Common messages in manufacturing scenarios:

Forecasts: DELFOR, VDA 4905
Call-ups: DELJIT, VDA 491C
Delivery notifications: DESADV, VDA 4913
Invoicing: INVOIC, VDA 4906

Message use in the scenario of the automotive industry

In this scenario there is a great number of forecasts (DELFOR) depending on what is considered a forecast and what an order. In such mixed cases the transmission of a direct call-up (DELJIT) is usually omitted. A very important message is the dispatch notification, which almost all clients expect to receive. Large automotive companies often use reverse billing (self-billing). In such cases clients simply issue the invoice to themselves and settle it. This is to avoid disruptions to their cyclical, automatic processes due to the date on which the supplier sends its invoice. In both regular and self-billing invoice data are based on the data of call-ups and delivery notifications.

Common messages in general commercial scenarios:

Orders: ORDERS
Delivery notifications: DESADV
Receipts: RECADV
Invoices: INVOIC

Message use in the general commercial scenario

In very rare cases the scenario can also include the order confirmation (ORDRSP) message. The inclusion of the inventory report (INVRPT) message is more frequent, primarily in the case of central
warehouses. In general, a single invoice is associated with each order. Invoice data are based on the data of the order, the delivery notification, and the receipt (if there is one).

Common messages in consignment scenarios:

Sales report: SLSRPT
Invoice: INVOIC
Delivery notification: DESADV
Inventory report: INVRPT

Message use in the consignment scenario

In this business structure, after the initial stock-up of the warehouse the products are on consignment with the buyer of the supplier, who in most cases is a distributor. Payment is due after the sale (INVOIC), and the sale automatically launches the resupply of the product sold (DESADV). The supplier is usually informed of the sale from daily sales reports (SLSRPT). For the purposes of taking inventory and updating stocks with new products weekly, monthly, or even quarterly inventory reports (INVRPT) are sent to inform suppliers.