Der Beitrag Using EDIFACT Parties Correctly – A Breakdown erschien zuerst auf ecosio.
]]>One of the most common sources of master data issues is the conflation of EDIFACT parties – i.e. the parties referenced in EDIFACT messages. To those inexperienced with EDI and EDIFACT, it may not seem like an issue to use certain EDIFACT parties interchangeably if the underlying information is the same for a certain transaction. However, just because Buyer and Ultimate consignee or Invoice recipient may be the same value in a B2B transaction with business partner A, for example, that doesn’t mean they always will be in all other B2B transactions with other business partners.
The two core principles one must adhere to here are:
Making the wrong assumptions and not cross-checking exactly with the requirements will ultimately lead to errors and the swift deterioration of your master data’s integrity.
Admittedly, setting up EDI connections with certain partners can be challenging, as you may encounter requirements, such as those 3M sends to their partners (pictured below).
In such cases it is even easier for users to confuse EDIFACT parties.
Without trained personnel and processes and procedures in place to protect the integrity of your master data (such as conducting a full master data sync before onboarding a new partner), data quality is likely to deteriorate over time. In such situations, the only solution is a time-consuming audit and correction process.
Meanwhile, in the short term even the smallest error can have significant repercussions. For example, large consumers will often reject an invoice, no matter how big, if the data on it does not align with their records.
To help you avoid making expensive mistakes, in the following sections we will explore the subject of EDIFACT parties in detail, looking at the three popular EDIFACT subsets (EANCOM, EDITEC and VDA).
Before diving into these subsets, however, let’s first look quickly at EDIFACT as a whole…
UN/EDIFACT stands for the United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport. It is a set of internationally agreed standards that was created to facilitate the exchange of structured data between business partners.
As UN/EDIFACT is used across many different industries, the list of UN/EDIFACT parties (also known as “party function code qualifiers” and by the code “3035”) that can be used in B2B exchanges is very long. The full list of UN/EDIFACT party codes in the D01B version of the standard, which are used for the NAD (name and address) segments of EDI messages, can be found here.
As no company would ever need to use all of these party codes (and maintaining so many master data fields accurately would be virtually impossible), UN/EDIFACT users rely on standard subsets instead. These subsets are tailored towards specific industries and reduce the various EDI messages to essential fields that are mandatory to specific business processes or for specific message types. As a result, companies are only required to recognise and use a fraction of the available EDIFACT party codes.
Now let’s look at the key parties in each of these subsets and how they differ from one another, using the example of an INVOIC (invoice) transaction in each case.
EANCOM is arguably one of the most popular subset of the UN/EDIFACT standard. Initially created for the retail industry, EANCOM is now also used by some other industries too.
The EANCOM standard currently includes about 50 different message types. For the purposes of this article look at one of these – the D01B INVOIC – as an example.
From the hundreds of parties available under the extensive UN/EDIFACT standard, the EANCOM D01B INVOIC guideline uses just 35. The most commonly used of these, and their descriptions, are listed below…
| Party code | Party | Party description |
| BY | Buyer | The party to which the merchandise/service is sold |
| DP | Delivery party | The party to which the goods should be delivered (if not the same as consignee/buyer) |
| IV | Invoicee | The party to which the invoice is issued |
| OB | Ordered by | The party that issued the order |
| PE | Payee | The credit party when not the beneficiary |
| PR | Payer | The party initiating payment |
| SF | Ship from | The party from where goods will be (or have been) shipped |
| SU | Supplier | The party supplying the goods or services |
| UC | Ultimate consignee | The party designated on the invoice or packing list as the final recipient of the stated merchandise |
In most EANCOM D01B INVOIC transactions you are unlikely to need to refer to any party outside the nine listed above. However, there are a number of others that may be required from time to time.
These less commonly used EDIFACT parties are listed below:
| Party code | Party | Party description |
| AB | Buyer’s agent / representative | The third party that arranged the purchase of merchandise on behalf of the buyer |
| BF | Beneficiary’s bank | The account servicer for the beneficiary or payee |
| CA | Carrier | The party undertaking or arranging transport of goods |
| CN | Consignee | The party to which goods are consigned |
| CO | Corporate office | The head office of a company |
| DL | Factor | A company offering a financial service whereby a firm sells or transfers title to its accounts receivable to the factoring company |
| DS | Distributor | The party distributing goods, financial payments or documents |
| FW | Freight forwarder | The party arranging the forwarding of goods |
| II | Issuer of invoice | The party issuing the invoice |
| ITO | Invoice recipient party (GS1 Code) | The party to which the invoice is sent and which processes the invoice on behalf of the invoicee (the invoicee can be different to the processing party) |
| LC | Party declaring the Value Added Tax (VAT) | The party responsible for declaring the Value Added Tax (VAT) on the sale of goods or services |
| LF | Buyer’s corporate office | The buyer’s head office |
| LG | Supplier’s corporate office | The supplier’s head office |
| LSP | Logistic Service Provider (GS1 Code) | A party providing logistic services for another party (e.g re-packing suppliers products) on products which may lead to added value for the product |
| MF | Manufacturer of goods | The party that manufactures the goods |
| MR | Message recipient | The party that receives a message |
| MS | Document / message issuer / sender | The party issuing a document and/or sending a message |
| N1 | Notify party no. 1 | The first party to be notified |
| N2 | Notify party no. 2 | The second party to be notified |
| NI | Notify party | The party to be notified of arrival of goods |
| PB | Paying financial institution | The financial institution designated to make payment |
| PW | Despatch party | The party where goods are collected or taken over by the carrier (if other than consignor) |
| RB | Receiving financial institution | The financial institution designated to receive payment |
| SF | Ship from | The party from where goods are being or have been shipped |
| SN | Store number | The number allocated to identify the store in question |
| SR | Supplier’s agent / representative | The party representing the seller for the purpose of the trade transaction |
| UD | Ultimate customer | The final recipient of the goods |
The EDITEC subset offers standards for the communication between the plumbing/heating/air conditioning industry (in German: SHK for Sanitär-Heizung-Klima) and the respective wholesale sector. This is also known as the Heating, Ventilation & Air Conditioning industry – better known as HVAC (although this does not include plumbing).
EDITEC’s INVOIC 4.1 standard uses six party function code qualifiers. These are listed below:
| Party code | Party | Party description |
| AB | Central regulator | The party, who settles the payment. Usually a central payment settlement company. |
| DP | Ship-to party | The party to which the goods should be shipped |
| IV | Invoice recipient | The party to which the invoice is issued |
| ST | Delivery address | The address the goods should be delivered to |
| SU | Manufacturer / Supplier (Industry) / Invoicing party | The supplier of the invoiced goods |
| WS | Wholesaler | The wholesaler |
VDA stands for “Verband der deutschen Automobilindustrie” (German Automobile Industry Association). Unsurprisingly, given its name, VDA is almost used exclusively by the German automotive industry.
Within VDA’s INVOIC standard (VDA 4938) the ten most commonly used EDIFACT parties, or party function code qualifiers, are…
| Party code | Party | Party description |
| BY | Buyer | The party to which the goods are sold |
| II | Invoice issuer | The party that issues the invoice |
| IV | Invoicee | The party to which the invoice is issued |
| LC | Party declaring the Value Added Tax (VAT) | The party responsible on the supplier’s side for declaring the Value Added Tax (VAT) on the sale of goods |
| LD | Party recovering the Value Added Tax (VAT) | The party responsible on the customer’s side for recovering the Value Added Tax (VAT) on the sale of goods |
| MF | Manufacturer | The manufacturer of goods |
| PE | Payee | The credit party |
| SE | Seller | The party selling the goods |
| SF | Ship from | The party from where goods will be (or have been) shipped |
| ST | Ship to | The party to which the goods should be shipped |
If you would like help or advice on using EDIFACT parties correctly, avoiding master data issues or any other EDI topics, please get in touch. We are always happy to help!
You can also find a wide selection of articles, webinars, white papers and infographics in our resources section.
Der Beitrag Using EDIFACT Parties Correctly – A Breakdown erschien zuerst auf ecosio.
]]>Der Beitrag EDI file formats explained: key standards and differences erschien zuerst auf ecosio.
]]>Document standards are an essential part of electronic data interchange (EDI). In short, EDI standards (aka EDI file formats) are the specific guidelines that govern the content and format of B2B documents such as orders, invoices and order responses. These documents are then sent via EDI protocols to the service provider / business partner.
For more information on ecosio EDI as a Service solution and to find out how we could help your business move to the next step, get in touch today or chat with our Sales team now!
Sending documents according to an EDI standard ensures that the machine receiving the message is able to interpret the information correctly as each data element is in its expected place. Without such standards the receiver’s system will be unable to identify what part of the message is what, making automated data exchange impossible.
Although EDI documents may seem like a random mix of letters and symbols, all EDI messages conform to very strict rules. Typically EDI standards are based on the following four principles:
Syntax
Syntax rules determine what characters can be used and in what order.
Codes
Codes are used to identify common information such as currencies, country names or date formats.
Message designs
The message design defines how a particular message type (e.g. invoice or purchase order) is structured and what subset of rules from the prescribed syntax it uses.
Identification values
The means by which values in an EDI file are identified, e.g. by its position in the file or via the use of separators. These changes from standard to standard.
Most EDI standards also include the following three components:
Essentially different formats are like different languages, with the elements and segments of a certain standard mirroring the words and sentences of a regular language.
In the very early days of EDI it quickly became evident that document standards were required to avoid confusion and improve the efficiency of even paper-based supply chain communication. Following the advent of file transfer between computers (FTP) becoming possible, in 1975 the very first EDI standards were published by the Transportation Data Coordinating Committee (an organisation formed by US automotive transport organisations in 1968). In 1981 the American National Standards Institute then published the first multi-industry national standard, X12. In turn this was followed by the creation by the UN of a global standard, EDIFACT, in 1985.
No one attempt to unify standards has ever been completely successful, however. As technology has evolved and industry specific needs have become increasingly disparate, new standards have steadily been introduced over the decades. Somewhat counterintuitively, therefore, today there is no such thing as a single all-encompassing EDI standard for every document type. Instead, businesses choose their preferred document standard from a number of options (usually opting for the one most widely used in their industry). When trading with partners using different standards, businesses then have to ensure that their messages are correctly converted to the recipient’s required format. This process is called mapping.
The most popular EDI file format standard today outside North America is UN/EDIFACT, which stands for United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport. These international B2B message guidelines are extremely widely used across many industries.
In fact, given the scope of EDIFACT’s adoption, several industries have developed subsets of the main standard which allow for automation of industry-specific information. One well-known subset is EANCOM, for example, which is used in the retail industry.
EDIFACT document file types are identified by a six letter reference. For example, three of the most common of these references are:
All of these EDIFACT messages have the same basic structure, consisting of a sequence of segments:
As well as transmission format, the EDIFACT standard also defines delivery requirements. EDIFACT provides set guidelines, for example, concerning the exact structure of specific message exchanges, which might themselves contain several individual EDIFACT files.
For a more detailed look at the structure of an EDIFACT file, see our blog post “EDI Standards Overview – Structure of an EDIFACT File” on this topic.
Despite being less widely-used than EDIFACT, the TRADACOMS standard was released several years before the UN standard. Designed primarily for UK domestic trade (and particularly popular in the retail industry), TRADACOMS is made up of a hierarchy of 26 messages. Like EDIFACT, each message is also given a six letter reference.
TRADACOMS does not use a single message format. Instead, a transmission to a trading partner will consist of a number of messages. For example, one purchase order will often contain an Order Header (ORDHDR), several Orders (ORDERS) and an Order Trailer (ORDTLR). Multiple individual order messages can repeat between the ORDHDR and the ORDTLR.
As with EDIFACT standards, the TRADACOMS standard uses segments for ease of translation. Below are four of the most common segments:
ANSI ASC X12 stands for American National Standards (ANSI) Accredited Standards Committee (ASC) X12, though (for obvious reasons) this is often abbreviated to just X12.
Though initially developed in 1979 to help achieve EDI document standardisation across North America, X12 has been adopted as the preferred standard by approaching half a million businesses worldwide.
Compared to other EDI standards organisations, X12 has a particularly comprehensive transaction set. There are over 300 X12 standards, all of which are identified by a three digit number (e.g. 810 for invoices) rather than the six letter code system used by EDIFACT and TRADACOMS. These EDI file format standards fall under X12’s different industry-based subsets:
With each containing slight variations, these subsets are used by different industries as appropriate (apparel retail businesses use VICS for example).
In addition, the hundreds of document types are divided into 16 helpful message series, from ‘order’ to ‘transportation’, with each containing the relevant individual message types.
As with Documents conforming to X12 standards are made up of several segments, some of which are optional and some mandatory. Below is a list of the mandatory segments:
As with all EDI documents, these segments in turn are comprised of elements, as can be seen in the example X12 document below:
For more information on the X12 format, please see our more recent article “EDI Standards Overview – Structure of an EDIFACT File”.
The Association of the Automotive Industry (Verband der Deutschen Automobilindustrie in German, or VDA for short) was established in 1901 by German automobile businesses.
The VDA was one of the first associations to develop EDI file formats in 1977, making VDA standards even older than EDIFACT.
Like X12 standards, every VDA message standard has a unique identification number (four digits long in this case). For example, VDA EDI file format 4905 is a delivery forecast.
As worldwide use was not expected when the standards were developed, all VDA standards were published in German – something that continues to this day. This can make interpretation difficult, particularly concerning German business terms. Likewise, as VDA also does not use a naming convention for each element, knowledge of German is required to identify them.
Unlike EDIFACT and X12 standards, VDA standards do not use segments or separators. Instead data elements with a constant length, known as fixed length format elements, are used. When the data to be transmitted is shorter than the required length, spaces are used to fill the gaps. Unfortunately, this fixed length format means that the amount of data that can be transmitted is limited, meaning conversion to/from other EDI standards can be difficult.
Because of these issues, VDA fixed length document standards are slowly being replaced by EDIFACT document types. Today, VDA standards are effectively a subset of the EDIFACT standards used extensively by the automotive industry (much like the EDIFACT subset CEFACT is used by retail businesses).
To aid those using their standards, the VDA have published suggestions regarding transition to EDIFACT.
For more information on VDA standards, please see our dedicated VDA blog post for a more comprehensive explanation.
The Universal Business Language, or UBL, is a library of standard XML-based business document formats. UBL is owned by Organisation for the Advancement of Structured Information Standards (OASIS), who have made it available to all businesses for free.
As UBL uses an XML structure it differs from other more traditional EDI document formats. Perhaps the biggest difference is the fact that XML-based transmissions are easier to read than other EDI file formats. However, XML file sizes are considerably larger than those of other EDI file formats, though this is no longer a problem following the advent of broadband internet.
When first established in 2003, UBL had seven EDI file format standards. By the time version 2.1 was released over a decade later this number had increased to 65, and the release of version 2.2 in 2018 further increased the number of document types to over 80.
Significantly CEN/TC434 recently named UBL as one of two EDI syntaxes which comply with new EU regulations regarding e-invoicing. As such, as the use of PEPPOL grows, so the use of UBL is also likely to increase.
Like X12, UBL message types are split into higher level categories. These categories include pre-award sourcing, post-award sourcing, procurement and transportation. UBL messages themselves, meanwhile, include validators, generators, parsers and authoring software.
Whilst each of the above document standards is widely used, particularly within certain industries, unfortunately no one set of document standards is universally used by all supply chain businesses. As a result, if you wish to grow your business and to automate B2B data exchange with your partner network to achieve the cost benefits of automation you will need the ability to translate data between numerous formats.
Given the amount of technical expertise EDI file format translation requires, the fastest and most efficient way to gain this capability is to enlist the help of a managed EDI solution provider such as ecosio. In addition to enabling you to transfer documents in any required format and over any EDI protocol via a single connection to the ecosio cloud-based EDI solution (our Integration Hub), ecosio’s managed services remove virtually all internal effort concerning EDI. For example, new onboardings are handled by a dedicated project manager who is experienced in liaising between both sides to achieve fast, hassle-free and successful connections. Similarly, ecosio’s unique API ensures users are able to send and receive data directly from their ERP’s existing user interface.
For more information on ecosio EDI as a Service solution and to find out how we could help your business move to the next step, get in touch today or chat with our Sales team now!
Der Beitrag EDI file formats explained: key standards and differences erschien zuerst auf ecosio.
]]>Der Beitrag Electronic Data Interchange (EDI) with the Help of VDA Standards erschien zuerst auf ecosio.
]]>The Association of the Automotive Industry was founded in 1901 and is an interest group of the German automotive industry and its suppliers. The headquarters are located in Berlin.

VDA Headquarters in Berlin (Source: Wikimedia Commons
The VDA is publicly known through the Internationale Automobilausstellung (IAA, International Automotive Exhibition), since they operate as their organiser. In addition to the representation of interests, VDA also undertakes standardisation tasks, with recommendations for logistical processes in the automotive sector to be adopted. Those recommendations established themselves throughout the years as the de facto standard of the German automotive industry.
Already in 1977, before even UN/CEFACT started to develop the EDIFACT standards, the Verband der deutschen Automobilindustrie began, defining EDI message standards, which were dedicated to the automotive industry and its suppliers. In contrast to EDIFACT or ANSI ASC X12, no segments or separators are used, but instead elements with constant length, called the fixed length format are used. Every data element has a defined length, within which the information can be transmitted. If the information is shorter than the defined length, the rest is filled out with blank spaces.
Each VDA message type has a unique number, almost like a description. Message type 4905 describes for example a delivery forecast. At the end of this article you will find a list of the different VDA standards.
The current fixed length VDA standards are gradually being replaced by EDIFACT document types. Therefore, the VDA association releases recommendations, on how EDIFACT messages can represent VDA document types. Nevertheless, the current VDA message types are still very frequently used in the automotive industry and one can expect this to still be the case in the coming years.
Depending on the car manufacturer, different VDA standards can be used. The following scenario, depicted with a delivery forecast and despatch advice, as well as the paper documents which go with it, come up very frequently. This example is of a pump manufacturer, who sends goods to a car manufacturer.

An Example of the Use of VDA Standards
The car manufacturer forecasts the deliveries to the pump manufacturer with the help of a 4905 message. The pump manufacturer prepares the goods accordingly and confirms the delivery with a 4913 message. Next step is to ship the pumps, together with two paper documents: a barcode label 4902 together with the goods, which can be scanned with a barcode scanner and a paper-based goods slip 4912.
The use of VDA standards is now required by more and more car manufacturers and their pre-suppliers. However, the implementation of the corresponding electronic document types and the paper documents which go with it, including the correct barcodes, is not so simple. We are more than happy to help you with any questions you might have about VDA.
The list below gives you a (non-exhaustive) overview of the important standards, which the VDA association adopted (as of February 2015).
| Nr. | Description | First Publication |
|---|---|---|
| 4900 | Transmission of ODETTE messages; EDIFACT payload | Jan 91 |
| 4901 | Enquiries/offer | Oct 77 |
| 4902 | Transport label (barcode enabled) | Sep 94 |
| 4903 | Microfilm | Apr 82 |
| 4904 | Delivery forecast | May 83 |
| 4905 | Transmission of call off | Apr 96 |
| 4905/2 | Transmission of call off based on ODETTE-DELINS Version 3 | Jan 91 |
| 4907 | Transmission of remittance advice | Aug 93 |
| 4911 | Transmission of price data | Jan 89 |
| 4912 | DFÜ goods slip | Jan 91 |
| 4913 | Transmission of delivery notes and transport data | Mar 96 |
| 4914 | File Transfer Protocol (FTP) – contains 4914/1 and 4914/2 | Mar 88 |
| 4915 | Transmission of detailed call off (JIT) | Apr 96 |
| 4916 | Transmission of call off just-in-sequence | May 91 |
| 4918 | Transmission of vehicle identification and transport data | Apr 87 |
| 4919 | Transmission of vehicle arrival and departure notification; process description | Apr 87 |
| 4920 | Transmission of forwarding instructions (sender/supplier to shipper) | Apr 89 |
| 4921 | Transmission of delivery data (shipper to client/goods receiver) | Apr 89 |
| 4922 | Form for the shipment of goods between the supplier, shipper and client – shipping request | Jun 10 |
| 4923 | Transmission of enquiries | Jan 92 |
| 4924 | Transmission of offer/quotation | Jan 92 |
| 4926 | Transmission of acknowledgment of order | Sep 93 |
| 4927 | Transmission of equipment statement and equipment movement | Feb 97 |
| 4928 | Checklist for production partners (system suppliers) with just in time delivery in the information processing area; first publication | Aug 96 |
| 4929 | AVIEXP: EDI for delivery notes and transport data; VDA guideline of the ODETTE subset AVIEXP V5R1 for UN/EDIFACT message DESADV D96A | Feb 98 |
| 4930 | Transmission of inventory and stock movement information with external warehousing | Apr 93 |
| 4931 | Packaging data sheet | Apr 93 |
| 4932 | INVOIC: EDI for invoices and credit notes data; VDA recommendation to ODETTE subset V5R1 for UN/EDIFACT message INVOIC D97A | May 99 |
| 4933 | Standardised transport note/ shipping readiness advice (including labels) | Jul 14 |
| 4936 | Web EDI (part I) for the deployment of call off data, the logging and shipment of delivery notes (shipment, transport and delivery slip data), printing of the goods slip, and deployment of the credit note data. | Nov 01 |
| 4937 | Automated responses for delivery notes part 0: process description and general information | Mar 09 |
| 4937 P1 | Automated responses for delivery notes part 1: syntax and service report (EDIFACT CONTRL) | Mar 09 |
| 4937 P2 | Automated responses for delivery notes part 2: application error and confirmation message (EDIFACT APERAK) | Mar 09 |
| 4937 P3 | Automated responses for delivery notes part 3: receiving advice notice (EDIFACT RECADV) | Mar 09 |
| 4938 P1 | Process framework for the exchange of electronic invoices with the use of EDIFACT without digital signature | Apr 12 |
| 4938 P2 | Global INVOIC application manual – data structure (incl. labels) | Jun 14 |
| 4938 P3 | Electronic invoicing process with small and medium sized businesses in the automotive industry (incl. labels) | Dec 13 |
| 4938 P4 | Freight invoice – data structure for the exchange of invoice data for transport services. | Dec 13 |
| 4939 | Transport and shipping slips | Dec 07 |
| 4940 | Checklist for the deployment of ODETTE messages | Aug 93 |
| 4941-1 | Part 1: Packaging account overview | Feb 06 |
| 4941-2 | Part 2: Packaging inventory report | Feb 06 |
| 4941-3 | Part 3: Packaging inventory discrepancy | Feb 06 |
| 4942-4 | Part 4: Packaging inventory correction | Feb 06 |
| 4942-5 | Part 5: Packaging inventory delimitation | Feb 06 |
| 4943 | Packaging batch report | Feb 06 |
| 4944 | Packaging transport request | Feb 06 |
| 4945 | Packaging transport status | Feb 06 |
| 4946 | Packaging request acknowledgment | Feb 06 |
| 4947 P1 | Part 1: Packaging movement notice | Feb 06 |
| 4947 P2 | Part 2: Packaging receiving confirmation | Feb 06 |
| 4948 P0 | Bypass/drop ship part 0: Process description and general information | Oct 06 |
| 4948 P1 | Bypass/drop ship part 1: order | Oct 06 |
| 4948 P2 | Bypass/drop ship part 2: order response | Oct 06 |
| 4948 P3 | Bypass/drop ship part 3: delivery notice | Oct 06 |
| 4949 | Proposition about the standardisation of the communication for the exception handling of the supply chain in aftermarket | May 07 |
| 4970 | Transport preview for finished vehicles | Jun 99 |
| 4971 | Pick up order for finished vehicles | Mar 00 |
| 4972 | Dispatch notice from plant/base for finished vehicles | Mar 00 |
| 4973 | Vehicle entry for finished vehicles | Mar 00 |
| 4974 | Vehicle exit for finished vehicles | Mar 00 |
| 4975 | Change/information notice for finished vehicles | Feb 00 |
| 4976 | Change/information confirmation for finished vehicles | Mar 00 |
| 4977 | Damage report for finished vehicles | Mar 00 |
| 4978 | Repair start/end notice for finished vehicles | Mar 00 |
| 4979 | Shipping readiness notice for finished vehicles | Mar 00 |
| 4980 | Loading instructions for finished vehicles | Mar 00 |
| 4981 | Usage of portal agents in the portal applications of the automotive industry | Oct 11 |
| 4982 | Data exchange between the companies of the automotive industry and the logistic service providers to fulfil the requirements of the import control system ICS of the European Union. | Dec 11 |
| 4983 | Transmission of attachments and signatures with EDIFACT messages (including labels) | Mar 12 |
| 4984 | Transmission of delivery forecasts (incl. labels) | Jun 14 |
| 4985 | Transmission of JIT call offs (incl. labels) | Jan 13 |
| 4986 | Transmission of production synchronous (JIS) call offs | Jun 14 |
| 4987 | Transmission of delivery notes (incl. labels) | Jul 14 |
| 4988 | Transmission of remittance advice with EDI (incl. labels) | Dec 13 |
| 4989 | Transmission of arrival confirmation | Dec 13 |
| 4990 | Inventory and stock movement report | Feb 15 |
| 4991 | Transmission of shipping notes (incl. labels) | Apr 14 |
| 4993 | Activity fields for portal managers | Feb 15 |
| 4999 | Glossary | Mar 15 |
Electronic Data Interchange (EDI) with the Help of VDA Standards? Feel free to contact us, we would love to help you!
Der Beitrag Electronic Data Interchange (EDI) with the Help of VDA Standards erschien zuerst auf ecosio.
]]>Der Beitrag What is a Tier supplier? erschien zuerst auf ecosio.
]]>A supply pyramid describes the structure of a supply chain with the end product producer at the top. The end product producer is referred to as an OEM, which stands for Original Equipment Manufacturer. The suppliers of modules and systems are directly underneath the OEM. These suppliers are supplied by component suppliers who in turn buy their goods from parts suppliers.
Suppliers are referred to as Tier 1, Tier 2, Tier 3, Tier-n suppliers, depending on their distance from the OEM. This reflects the sub-supplier structure.
The automotive industry is characterized by complex and closely interlocked logistics chains. Instead of producing all their components in-house, automotive manufacturers procure the individual modules from specialist suppliers. These suppliers will in turn assemble components supplied by specialised component suppliers. The suppliers of individual parts are found on the third tier.
These boundaries are not always so clearly defined. A supplier may thus be both Tier 1 and Tier 2 – for example a business might deliver antenna modules to both OEMs and Tier 1 suppliers.
The following diagram illustrates an example of an automobile supply chain:

Supply pyramid in the automotive industry
Close links between OEMs and their individual tier suppliers pose special challenges to smooth process operation. The horizontal integration of many different suppliers and their own suppliers will, for instance, demand that required quantities are communicated fast and effectively if the supply of modules, components and individual parts is to be ensured. This is a critical factor in success especially with just-in-time and just-in-sequence processes. Electronic data interchange is used to ensure communication, whilst the concepts of delivery schedule and just-in-time deliveries may for instance be deployed. Standardisation organizations such as ODETTE and VDA have already developed many useful standards to allow efficient operation of automobile supply processes.
Apart from logistics messages such as delivery schedule, despatch advice, etc., continuous digital engineering is essential. This will, for instance, include the exchange of construction data such as CAD (Computer-aided design) drawings and the like.
If you have questions about logistics in the automotive industry or would like to learn more about implementing an EDI based process please contact us – we look forward to hearing from you!
You can also find more useful information on this and other relevant topics in our extensive resource centre and blog.
Der Beitrag What is a Tier supplier? erschien zuerst auf ecosio.
]]>Der Beitrag VDA 4938 – New standard for electronic invoices in the automotive industry erschien zuerst auf ecosio.
]]>The German Association of the Automotive Industry (VDA) has for many years been publishing standards for processes found in the automotive and associated industries. VDA is the acronym of the association’s German name Verband der Deutschen Automobilindustrie.
VDA has also, in addition to standards for logistics such as delivery call-offs, JIT delivery schedules, despatch advices, etc., published standards for electronic invoicing. The two familiar standards are VDA 4906 (EDI for invoices) and VDA 4908 (EDI for credit notes). Both standards are outdated today. VDA 4906 was passed in May 1993 and VDA 4908 in May 1996. The use of these standards is no longer recommended and the new e-invoicing standard VDA 4938 should be used instead.
VDA developed the VDA 4938 standard to meet current statutory and fiscal requirements for the automotive industry. The objective of VDA 4938 is a uniform design of electronic invoices and credit notes to allow the electronic exchange of information between companies using EDI (OEMs and tier suppliers etc.).
The VDA 4938 standard has four different parts, as listed below.

Overview of the VDA 4938 family of standards
The individual documents are available under the following links (in German):
Part 1 deals with the process framework for electronic invoicing. This includes a process recommendation, technical guidelines, and guidelines for the involvement of service providers. Agreement templates and checklists for VDA 4938 users are also included.
Part 2 contains the EDI definition, the so-called EDIFACT Message Implementation Guideline – MIG for short, based on EDIFACT INVOIC D07A.
Part 3 contains the invoicing specification developed by auto-gration, an EU-funded project aimed at supporting small and medium-sized enterprises in their participation in global automotive industry supply chains. The result of this project is an XML specification for electronic invoicing, now included as Part 3 of VDA 4938.
Part 4 contains specifications for the display of freight invoices based on EDIFACT INVOIC D13A.
You have further questions in regard to VDA standards, or would you like to introduce a VDA 4938 based solution? Please do contact us or use our chat — we’re more than happy to help!
Der Beitrag VDA 4938 – New standard for electronic invoices in the automotive industry erschien zuerst auf ecosio.
]]>Der Beitrag The essential details of the VDA 4905 call off message erschien zuerst auf ecosio.
]]>VDA standards are maintained by the German Association of the Automotive Industry and represent one of the important families of standards used by that industry. VDA is the acronym of Verband der deutschen Automobilindustrie.
Standard definitions are given for a variety of applications, referring not only to the structure of electronic documents, but also specifying, for instance, labels and shipping documentation.
Delivery call-offs represent a key means of communication in the automotive industry, since tightly linked processes involving customers, suppliers, and upstream suppliers demand that changing supply chain dates and requirements must continuously be communicated “back up the chain”.
The principle is illustrated in the diagram below.

VDA 4905 delivery call-off principle
A new delivery call-off will fully override the previous delivery call-offs. Current requirements can therefore always be communicated back to the previous link in the logistics chain and up-to-date requirements are availabe to all business partners involved.

Learn how to resolve the key issues facing IT decision makers today
Similar to many other VDA standards, VDA 4905 delivery call-offs have a fixed dataset length of 128 characters. Adding a line break after every dataset will produce a sequence of rows. Each row starts with a three-character record type.
The diagram below illustrates the structure of a VDA 4905 message. The first three digits define the record type. M means, that the dataset is mandatory. K means, that the dataset is optional. M derives from the German muss, meaning must. K derives from the German kann, meaning can.
The last character indicates how often the dataset is allowed to be repeated, where n stands for as often as needed and 1..n for at least 1 to n times.

Structure of a VDA 4905 delivery call-off
The nested structure also indicates datasets, that can be repeated after a first dataset. The diagram shows, that transmission of delivery call-off data starts with record type 511 and will always end with record type 519.
A transmission must always contain record type 512 with the corresponding subordinate record types for every sorting parameter combination. In the VDA context, the sorting parameter combination includes the following parameters:
If, for instance, material number number a and number b and customer factory factory x and factory y are given and a call-off is required for both material numbers and both factories, the result will be as follows:
material number a in factory x)material number a in factory y)material number b in factory x)material number b in factory y)The VDA standard has several special features compared to EDIFACT, which we briefly discuss below.
EDIFACT file transmissions are clearly identified by interchange references (provided in the UNB segment). Interchange references are issued by the sender and are numbered sequentially ascending. Using the interchange reference an EDIFACT transmission is easy to trace. In addition the message creation date and time in the UNB segment help with correctly identifying a transmission. Thus, wrong messages may, for instance, be traced and re-transmitted without a problem.
VDA has a different approach. A new transmission number and an old transmission number are transmitted for each transmission. New and old transmission numbers are unique references for the current and previous transmissions, respectively. No sequential numbering of the transmitted numbers is therefore required. Transmissions may furthermore be numbered differently, for instance in accordance with technical areas (e.g., orders for regular products as opposed to orders for spare parts).
It is customary in the trade that parties interchanging data (supplier, customer, invoice recipient, place of delivery, etc.) are identified by Global Location Numbers – GLN.
The automotive sector instead uses numbers that were exchanged bilaterally in advance. These may, for instance, include customer number, supplier number, customer’s factory number and unloading point.
It is also customary in the trade that exchanged products are identified by a Global Trade Identification Number (GTIN). The GTIN is a number the producer assigns to his products. A consumer will recognise the GTIN as the number under the bar code, which can be found on almost all products in a supermarket shelf.
The automotive sector generally uses material numbers instead of GTINs. The supplier maintains his own list of individual customer material numbers, enabling him to assign them to his internal material numbers.
The cumulative quantity received comprises all negative or positive deliveries recorded by the customer, from a specific point in time. The quantity in transit will be the difference between cumulative delivery quantity by the supplier and cumulative quantity received at the customer.
The customer may also reset the cumulative quantity to 0 by sending a reset date in a delivery call-off. This date will then apply to all the parts of the supplier. Thus, the first call-off transmission after the reset shall contain all parts of the supplier relevant to the specific customer, allowing to start a new sequence.
Within the framework of VDA messaging (including VDA 4905) it is possible to assign version numbers to individual record types. EDIFACT does not provide for such version control on the record type level –- the only comparison would be EDIFACT directory version control -– e.g. EDIFACT EANCOM D96A vs. EDIFACT EANCOM D01B.
“The entire automotive industry relies on the VDA standard. Good news for all suppliers –- all companies in the automotive industry will be able to receive delivery call-offs using the same standard.”
Not quite, unfortunately…
Similar to EDIFACT, where the global EDIFACT standard (used in its pure form only by a few) has many subsets that are specific to certain industries and companies, the VDA also has versions that are specific to some companies.
This means, for instance, that German OEMs may have slightly different requirements under the VDA standard, that upstream suppliers will need to take into account.
More questions on the topic of delivery call-off or other VDA standards? Please do contact us or use our chat — we’re more than happy to help!
Der Beitrag The essential details of the VDA 4905 call off message erschien zuerst auf ecosio.
]]>Der Beitrag What is a DESADV message? erschien zuerst auf ecosio.
]]>DESADV is the abbreviation for despatch advice. A despatch advice is a type of document that is exchanged in the course of procurement and distribution processes. DESADV is also the name of the corresponding EDIFACT document type of a despatch advice. The designation ASN (advance shipping notice) is often used in the automotive industry, instead of DESADV. Both terms, however, mean the same.
The following illustration provides an overview of the various documents in a procurement process occurring in the retail industry and illustrates the use of a despatch advice.

Sequence of electronic documents in a procurement process in the retail industry
A buyer uses an order message to place an order at a supplier. The supplier sends an order confirmation message to confirm the order. The supplier will then send a dispatch advice to the buyer before shipping the actual goods. This will inform the buyer about the nature of the goods, the quantity and the time of delivery, allowing him to prepare his inbound logistics. The goods will then be despatched. The buyer may optionally acknowledge the receipt of goods with a receipt confirmation message. The last step is the submission of an invoice message.
The process described above serves just as an example. Different types of documents may be used, depending on participating partners and the industry. Amazon, for instance, attaches great importance to order confirmation messages. Inventory Report (INVRPT) or Sales Report (SLSRPT) documents play an important role in the textile sector.
Commercial enterprises such as Tesco face enormous logistic challenges every day. Goods are ordered from many different suppliers for delivery either to warehouse locations (cross-docking) or to individual branches directly (drop-shipping).
Overviews of pending deliveries must be available at all times to ensure that cross-docking and drop-shipping logistics remain efficient. Using the despatch information sent by the suppliers the retail stores may plan and optimize their inbound logistics.

Loading and unloading in a warehouse
Incoming goods must be offloaded and stored in their designated place as quickly as possible. In the case of refrigerated and deep-frozen goods, adequate storage capacities must be ready, to avoid interruption of the cold chain.
To ensure efficient warehouse administration all suppliers must transmit electronic despatch advice messages to announce upcoming deliveries. The despatch advice will contain the date and time of the delivery and the details of the delivered goods. Depending on the given industry, this may comprise basic product designations as well as information about the itemised packaging means and their hierarchy on a pallet. Gross and net weights may also be given.
Different EDI standards may be used for the exchange of electronic exchange of despatch information, depending on the industry. The EDIFACT EANCOM format is primarily used in the retail industry in Europe. Thereby, the two most widely used document types are: EDIFACT DESADV D96A and EDIFACT DESADV D01B. The older EDIFACT DESADV D93A may also occasionally occur.
VDA standards are mostly used in the automotive industry. The two VDA despatch advice standards are VDA 4913 (the older, flat text-based standard) and VDA 4987 (the newer, EDIFACT-based standard).
ANSI ASC X12 standards are commonly used in North America. The ANSI despatch advice standard is 856 Ship Notice/Manifest.
You have further questions in regard to DESADV? You would like to use DESADV messages with a customer or supplier of yours? Please do contact us or use our chat – we’re more than happy to help!
Der Beitrag What is a DESADV message? erschien zuerst auf ecosio.
]]>