VDA – ecosio Connections That Work Fri, 08 Aug 2025 12:41:06 +0000 en-US hourly 1 https://ecosio.com/app/uploads/2020/02/favicon-96x96-1.png VDA – ecosio 32 32 Using EDIFACT Parties Correctly – A Breakdown https://ecosio.com/en/blog/using-edifact-parties-correctly-a-breakdown/ Thu, 28 Oct 2021 16:41:42 +0000 https://ecosio.com/?p=28485 While maintaining master data is extremely important if a business is to experience streamlined B2B message exchange, it’s not always simple. The multitude of potential EDIFACT parties that can be involved in a transaction can be confusing and it’s imperative that certain processes are established and adhered to if costly errors are to be avoided. […]

Der Beitrag Using EDIFACT Parties Correctly – A Breakdown erschien zuerst auf ecosio.

]]>
While maintaining master data is extremely important if a business is to experience streamlined B2B message exchange, it’s not always simple. The multitude of potential EDIFACT parties that can be involved in a transaction can be confusing and it’s imperative that certain processes are established and adhered to if costly errors are to be avoided.

Why master data errors happen

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:

  • Always consult the respective EDI message implementation guideline and potentially accompanying documents, to check which partner role is required where.
  • Always cross check with other document types in the same process choreography, to spot potential interdependencies. E.g. an INVOIC usually must contain the same role identifiers (AKA party codes) as the underlying ORDERS and DESADV. It may of course also contain additional role identifiers, not contained in the underlying document types.

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).

3M Message Requirements

In such cases it is even easier for users to confuse EDIFACT parties.

The impact of master data errors

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…

White Paper - 7 Mistakes EDI Solution Buyers Make

Understanding EDIFACT and EDIFACT parties

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.

EDIFACT subset 1: EANCOM (D01B INVOIC)

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

EDIFACT subset 2: EDITEC (INVOIC 4.1)

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

EDIFACT subset 3: VDA (VDA 4938)

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

Want more information?

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.

]]>
EDI file formats explained: key standards and differences https://ecosio.com/en/blog/edi-file-formats-explained/ Mon, 10 Feb 2020 17:49:29 +0000 https://ecosio.com/?p=14104 🔍 TL;DR summary EDI file formats standardise how B2B documents are structured for automated exchange Popular formats include EDIFACT, TRADACOMS, X12, VDA, and UBL, each suited to specific industries Each format follows different rules, like delimiters or fixed-length fields When partners use different formats, conversion is essential and often handled by a managed EDI provider […]

Der Beitrag EDI file formats explained: key standards and differences erschien zuerst auf ecosio.

]]>
🔍 TL;DR summary

  • EDI file formats standardise how B2B documents are structured for automated exchange
  • Popular formats include EDIFACT, TRADACOMS, X12, VDA, and UBL, each suited to specific industries
  • Each format follows different rules, like delimiters or fixed-length fields
  • When partners use different formats, conversion is essential and often handled by a managed EDI provider

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!

Book a meeting

How EDI file formats work

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: 

  • Elements – The smallest part of a message, providing submitted values (e.g. “50” or “KGM” or “Potatoes”)
  • Segments – A collection of elements or values logically combined to provide an information (e.g. Quantity 50 kilograms of potatoes)
  • Transaction sets – A collection of segments, composing a message (e.g. an Invoice for the sale of 50 kilogram of potatoes)

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.

A brief history of EDI document standards

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.

Infographic - 5 Stepping Stones to Successful EDI

The 5 most used EDI file format standards:

1) UN/EDIFACT

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:

  • ORDERS (for purchase orders)
  • INVOIC (for invoices)
  • DESADV (for despatch advice)

All of these EDIFACT messages have the same basic structure, consisting of a sequence of segments:

  • UNA – separators, delimiters and special characters are defined for the interpreting software 
  • UNB – file header (with the file end UNZ this makes up the envelope, containing basic information)
  • UNG – group start
  • UNH – message header
  • UNT – message end
  • UNE – group end
  • UNZ – file end

Example EDIFACT order

EDIFACT Order - EDI File Formats

[segment tags shown in bold]

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.

2) TRADACOMS

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:

  • STX – Start of Interchange
  • MHD – Message start
  • MTR – Message end
  • END – End of Interchange

Example TRADACOMS order

TRADACOMS Order - EDI File Formats

[segment tags shown in bold]

3) ANSI ASC X12

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:

  • AIAG – Automotive Industry Action Group
  • CIDX – Chemical Industry Data Exchange
  • EIDX – Electronics Industry Data Exchange Group (CompTIA)
  • HIPAA – Health Insurance Portability and Accountability Act
  • PIDX – American Petroleum Institute
  • UCS – Uniform Communication Standard
  • VICS – Voluntary Interindustry Commerce Standards

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:

  • ISA – Start of interchange
  • GS – Start of functional group
  • ST – Start of transaction set
  • SE – End of transaction set
  • GE – End of functional group
  • IEA – End of Interchange

As with all EDI documents, these segments in turn are comprised of elements, as can be seen in the example X12 document below:

Example X12 order

X12 Order - EDI File Formats

[segment tags shown in bold]

For more information on the X12 format, please see our more recent article “EDI Standards Overview – Structure of an EDIFACT File”.

4) VDA

The Association of the Automotive Industry (Verband der Deutschen Auto­mobil­industrie 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. 

Example VDA delivery forecast

VDA - EDI File Formats

[segment tags shown in bold]

For more information on VDA standards, please see our dedicated VDA blog post for a more comprehensive explanation.

5) UBL

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.

Example XML order (ecosio ERPEL)

XML Order - EDI File Formats

How to exchange different EDI file formats with your trading partners

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!

Infographic - 5 Stepping Stones to Successful EDI

Der Beitrag EDI file formats explained: key standards and differences erschien zuerst auf ecosio.

]]>
Electronic Data Interchange (EDI) with the Help of VDA Standards https://ecosio.com/en/blog/electronic-data-interchange-edi-using-vda-standards/ Fri, 10 May 2019 00:00:00 +0000 https://ecosio.com/blog/electronic-data-interchange-edi-using-vda-standards/ Verband der Deutschen Auto­mobil­industrie (VDA) 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 […]

Der Beitrag Electronic Data Interchange (EDI) with the Help of VDA Standards erschien zuerst auf ecosio.

]]>
Verband der Deutschen Auto­mobil­industrie (VDA)

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
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.

The development of the VDA standards

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.

White Paper - 7 Mistakes EDI Solution Buyers Make

Numbering of the VDA messages

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.

Current development

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.

How are VDA standards being used?

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
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.

Are you looking to use VDA standards?

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.

List of VDA standards

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 Publi­cation
4900 Trans­mission of ODETTE mess­ages; EDIFACT pay­load Jan 91
4901 Enqu­iries/offer Oct 77
4902 Trans­port label (barcode enab­led) Sep 94
4903 Microfilm Apr 82
4904 Deli­very fore­cast May 83
4905 Trans­mission of call off Apr 96
4905/2 Trans­mission of call off based on ODETTE­-DELINS Ver­sion 3 Jan 91
4907 Trans­mission of remi­ttance advice Aug 93
4911 Trans­mission of price data Jan 89
4912 DFÜ goods slip Jan 91
4913 Trans­mission of deli­very notes and tran­sport data Mar 96
4914 File Tran­sfer Proto­col (FTP) – contains 4914/1 and 4914/2 Mar 88
4915 Trans­mission of detai­led call off (JIT) Apr 96
4916 Trans­mission of call off just­-in-­seque­nce May 91
4918 Trans­mission of vehicle identi­ficat­ion and trans­port data Apr 87
4919 Trans­mission of vehicle arrival and depar­ture notifi­cation; process descri­ption Apr 87
4920 Trans­mission of forward­ing instructi­ons (sender­/supplier to shi­pper) Apr 89
4921 Trans­mission of deli­very data (shipper to client/­goods receiver) Apr 89
4922 Form for the ship­ment of goods betw­een the suppl­ier, shipper and client – shipp­ing req­uest Jun 10
4923 Trans­mission of enqui­ries Jan 92
4924 Trans­mission of offer­/quotat­ion Jan 92
4926 Trans­mission of acknowl­edgment of order Sep 93
4927 Trans­mission of equip­ment state­ment and equip­ment move­ment Feb 97
4928 Check­list for produc­tion partners (system ­suppliers) with just in time deli­very in the inform­ation process­ing area; first publi­cation Aug 96
4929 AVIEXP: EDI for deli­very notes and trans­port data; VDA guide­line of the ODETTE subset AVIEXP V5R1 for UN/­EDIFACT message DESADV D96A Feb 98
4930 Trans­mission of inven­tory and stock move­ment informa­tion with exter­nal ware­housing Apr 93
4931 Packag­ing data sheet Apr 93
4932 INVOIC: EDI for invoices and credit notes data; VDA recom­menda­tion to ODETTE subset V5R1 for UN/­EDIFACT message INVOIC D97A May 99
4933 Standard­ised trans­port note/ shipping read­iness advice (inclu­ding labels) Jul 14
4936 Web EDI (part I) for the deploy­ment of call off data, the logg­ing and ship­ment of deli­very notes (ship­ment, trans­port and deliv­ery slip data), print­ing of the goods slip, and deploy­ment of the credit note data. Nov 01
4937 Auto­mated responses for deli­very notes part 0: process descript­ion and general infor­mati­on Mar 09
4937 P1 Auto­mated respo­nses for deli­very notes part 1: syntax and serv­ice report (EDIFACT CONTRL) Mar 09
4937 P2 Auto­mated responses for deli­very notes part 2: appli­cation error and confir­mation message (EDIFACT APERAK) Mar 09
4937 P3 Auto­mated respon­ses for deli­very notes part 3: receiv­ing advice notice (EDIFACT RECADV) Mar 09
4938 P1 Process frame­work for the exchange of elect­ronic invoi­ces with the use of EDIFACT without digi­tal sign­ature Apr 12
4938 P2 Global INVOIC appli­cation manual – data struc­ture (incl. labels) Jun 14
4938 P3 Elec­tronic invo­icing process with small and medium sized busi­nesses in the auto­motive industry (incl. labels) Dec 13
4938 P4 Freight invoice – data struc­ture for the exch­ange of invo­ice data for trans­port services. Dec 13
4939 Trans­port and shipping slips Dec 07
4940 Check­list for the deploy­ment of ODETTE mess­ages Aug 93
4941-1 Part 1: Packag­ing acc­ount over­view Feb 06
4941-2 Part 2: Packag­ing inven­tory report Feb 06
4941-3 Part 3: Packaging inventory discrepancy Feb 06
4942-4 Part 4: Packag­ing inven­tory correct­ion Feb 06
4942-5 Part 5: Packag­ing inven­tory delimitation Feb 06
4943 Packag­ing batch report Feb 06
4944 Packag­ing trans­port request Feb 06
4945 Packag­ing trans­port status Feb 06
4946 Packag­ing request acknow­ledg­ment Feb 06
4947 P1 Part 1: Packag­ing move­ment notice Feb 06
4947 P2 Part 2: Packag­ing recei­ving confir­mation Feb 06
4948 P0 Bypass/drop ship part 0: Pro­cess descri­ption and general infor­mation Oct 06
4948 P1 Bypass/drop ship part 1: order Oct 06
4948 P2 Bypass/drop ship part 2: order resp­onse Oct 06
4948 P3 Bypass/drop ship part 3: deli­very notice Oct 06
4949 Propo­sition about the standard­isation of the communi­cation for the except­ion handling of the supply chain in after­market May 07
4970 Trans­port preview for finished vehi­cles Jun 99
4971 Pick up order for fin­ished vehi­cles Mar 00
4972 Dispatch notice from plant­/base for fini­shed vehi­cles Mar 00
4973 Vehi­cle entry for fini­shed vehic­les Mar 00
4974 Vehi­cle exit for fini­shed vehic­les Mar 00
4975 Change/­informa­tion notice for fin­ished vehicles Feb 00
4976 Change/­informa­tion confirma­tion for fini­shed 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

Questions?

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.

]]>
What is a Tier supplier? https://ecosio.com/en/blog/what-is-a-tier-supplier/ Fri, 11 Jan 2019 00:00:00 +0000 https://ecosio.com/blog/what-is-a-tier-supplier/ 🔍 TL;DR summary Suppliers are categorised as Tier 1, Tier 2, Tier 3, Tier-n based on their distance from the OEM, reflecting the sub-supplier structure In the automotive industry, OEMs source modules from specialist suppliers, who assemble components from other suppliers, with individual parts supplied on the third tier Close links between OEMs and tier […]

Der Beitrag What is a Tier supplier? erschien zuerst auf ecosio.

]]>
🔍 TL;DR summary

  • Suppliers are categorised as Tier 1, Tier 2, Tier 3, Tier-n based on their distance from the OEM, reflecting the sub-supplier structure
  • In the automotive industry, OEMs source modules from specialist suppliers, who assemble components from other suppliers, with individual parts supplied on the third tier
  • Close links between OEMs and tier suppliers require fast and effective communication of required quantities to ensure the supply of modules, components and parts, particularly in just-in-time and just-in-sequence processes, supported by electronic data interchange

Structure of a supply pyramid

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.


Supply Pyramid
Supply Pyramid

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.

Webinar - Streamlining your supply chain

Tier supplier structure visualised – an example from the automotive industry

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
Supply pyramid in the automotive industry

Challenges along the supply chain

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.

Any questions?

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.

]]>
VDA 4938 – New standard for electronic invoices in the automotive industry https://ecosio.com/en/blog/vda-4938-new-standard-for-electronic-invoices-in-the-automotive-industry/ Fri, 14 Sep 2018 00:00:00 +0000 https://ecosio.com/blog/vda-4938-new-standard-for-electronic-invoices-in-the-automotive-industry/ Background of VDA and electronic invoicing 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 […]

Der Beitrag VDA 4938 – New standard for electronic invoices in the automotive industry erschien zuerst auf ecosio.

]]>
Background of VDA and electronic invoicing

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.

White Paper - E-invoicing in Europe

VDA 4938 – a standard for electronic invoicing

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
Overview of the VDA 4938 family of standards

The individual documents are available under the following links (in German):

  • 4938 T1 – Process framework for the exchange of electronic accounting documents, using EDIFACT without digital signatures
  • 4938 T2 – V 2.2 Global INVOIC Application Manual
  • 4938 T3 – Use of electronic accounting procedures for small and medium-sized companies in the automotive industry
  • 4938 T4 – Freight invoicing

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.

Any questions?

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.

]]>
The essential details of the VDA 4905 call off message https://ecosio.com/en/blog/the-essential-details-of-the-vda-4905-call-off-message/ Wed, 15 Aug 2018 00:00:00 +0000 https://ecosio.com/blog/the-essential-details-of-the-vda-4905-call-off-message/ VDA standards 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 […]

Der Beitrag The essential details of the VDA 4905 call off message erschien zuerst auf ecosio.

]]>
VDA standards

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.

VDA 4905 delivery call-off

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
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.

White Paper - B2B Connectivity and EDI Benchmark Report
Learn how to resolve the key issues facing IT decision makers today

VDA 4905 delivery call-off structure

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
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:

  • Customer factory
  • Customer material number
  • Order number
  • Unloading point

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:

  • 1 x 511
  • 1 x 512 plus sub-record types (material number a in factory x)
  • 1 x 512 plus sub-record types (material number a in factory y)
  • 1 x 512 plus sub-record types (material number b in factory x)
  • 1 x 512 plus sub-record types (material number b in factory y)
  • 1 x 519

Differences compared to EDIFACT

The VDA standard has several special features compared to EDIFACT, which we briefly discuss below.

Sequential numbering

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).

Customer and supplier identification

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.

Product identification

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.

Cumulative quantity received

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.

Record type version numbers

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.

A common standard for all?

“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 about VDA?

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.

]]>
What is a DESADV message? https://ecosio.com/en/blog/what-is-a-desadv-message/ Fri, 20 Jul 2018 00:00:00 +0000 https://ecosio.com/blog/what-is-a-desadv-message/ 🔍 TL;DR summary DESADV is the abbreviation for despatch advice, a document exchanged during procurement and distribution It serves as an EDIFACT document type, notifying the buyer about goods, quantity and delivery time to prepare inbound logistics In automotive, the designation ASN (advance shipping notice) is often used instead of DESADV, though both refer to […]

Der Beitrag What is a DESADV message? erschien zuerst auf ecosio.

]]>
🔍 TL;DR summary

  • DESADV is the abbreviation for despatch advice, a document exchanged during procurement and distribution
  • It serves as an EDIFACT document type, notifying the buyer about goods, quantity and delivery time to prepare inbound logistics
  • In automotive, the designation ASN (advance shipping notice) is often used instead of DESADV, though both refer to the same document
  • Common formats include EDIFACT DESADV D96A, D01B, and occasionally D93A in retail; VDA 4913 and 4987 in automotive; and ANSI 856 Ship Notice/Manifest in North America

Despatch advice

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
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.

Can Web EDI Transform My Supply Chain - White Paper

The need for notification of delivery

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
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 types of DESADV messages

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.

More questions about DESADV?

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.

]]>