Integration Advisor – VDA Message Standard

Joerg_Ackermann

I am extremely happy to share with you one more update to the B2B offerings of Integration Advisor and Cloud Integration (of SAP Integration Suite): VDA Message Standard is now supported. In this blog post, I want to give you a short overview of this message standard and explain how to use it.

VDA Library in Integration Advisor

The VDA Message Standard consists of the early VDA messages and codelists which were defined by VDA in the 1980s and 1990s and were used in the German automotive industry.

Our offering includes 20 messages across 13 distinct message types:

The latest versions of message types VDA4906, VDA4907, VDA4908, VDA4911, VDA4915, VDA4916, VDA4918, VDA4919, VDA4920, and VDA4921
Versions 3 and 4 of the VDA4905 message type
Versions 3, 4, and 5 of the VDA4913 message type
Five distinct variants (all version 3) of the DA4927 message type.

The message type VDA4927 is a special case because VDA has published different variants. These variants are structurally similar. Each variant is used in a different business context. These variants only differ in details such as documentation and mandatory or optional declarations. If you are not sure which variant to use, you should select message type VDA4927_1 because it is the most generic option.

SAP Process Integration & SAP Process Orchestration (SAP PI/PO) offered 10 message types (all of them in one version / variant). Our content includes a reference that shows which VDA message in Integration Advisor corresponds best to which VDA message from SAP PI/PO. Please note that the details are not always the same. For example, data elements have different identifiers in Integration Advisor compared to SAP PI/PO (for example, 512_02 versus VNR).

One additional piece of information: Since the mid-1990s, VDA recommends using the newer VDA messages. These messages are based directly on UN/EDIFACT and form an Edifact subset. You can find these newer messages in Integration Advisor as a separate B2B Library called VDA EDIFACT.

Versioning of VDA Messages

The VDA versioning strategy is different from the Edifact release strategy.

Edifact publishes release versions (for example, D.01B or D.16A) that contain all artifacts (messages, segments, data elements, and codelists) from a given time. Each release forms a complete content package, and single artefacts (like messages) may or may not have changed compared to the previous release.

The VDA Message Standard, however, versioned all messages and segments separately, similarly to Odette and Tradacoms. For example, in the screenshot above, VDA4905:4 represents the message VDA4905 in version 4.

Due to this versioning strategy and the fact that no updates for the VDA messages are expected, all definitions are grouped in one version called All. This version contains 20 messages.

The VDA organization also versioned segments explicitly, similar to messages. For example, 713:03 represents segment 713 in version 03. The data elements were not explicitly versioned. However, Integration Advisor shows a version annotation for data elements that are needed in different versions, such as 713_02:03.

Additional Semantic Details for VDA Messages

We provide additional semantic details for all VDA messages and hope that these details help Integration Advisor users. For example, see the blue boxes in next screenshot.

The following explains these semantic details:

Position indicates where a data element starts in the VDA EDI flat-file. The count begins from the start of the segment.
Syntax Data Type describes how the VDA standardization organization classified the data type. The letter A stands for alphanumeric, and N stands for numeric. The number shows the number of characters in the EDI flat-file. For example, A14 means alphanumeric with a length of 14, and N6 means numeric with a length of 6.
Primitive Type shows the data type used in Integration Advisor. It refers to the data type in the XML representation of a VDA payload (ICA format). For numeric data types (N), Integration Advisor distinguishes between semantic variants such as Integer, Decimal, Date, Time, or Numeric identifiers.
Length / Digits refers to the minimum length and maximum length, or total digits and fraction digits, of the XML representation. A data element in your VDA-XML payload does not need to use the full length defined by the VDA specification. The EDI Converter flow steps automatically handle trailing blanks (by padding and trimming) and leading zeros (by padding only). Therefore, the minimum length can be smaller than the maximum length in the VDA-XML payload. However, the VDA-EDI payload always uses the full length defined by the VDA Data Type.

In the next table you find a few more details how the VDA Data Types are represented in Integration Advisor.

VDA Data Type	AND extra rule	Explanation	IA Primitive Type	XSD Data Type	Length / Digits	Further settings
An		Alpha-numeric (Text/String)	String	xsd:string	Min Length = 0 Max Length = n
N3	First element of a segment	Segment name	NumericChar	xsd:token	Min Length = 3 Max Length = 3	Fixed=“xxx“ XSDPattern="\d*"
N2	Second element of a segment	Segment version	NumericChar	xsd:token	Min Length = 2 Max Length = 2	Fixed=“yy“ XSDPattern="\d*"
Nn	Has a codelist	Numeric Code values	NumericChar	xsd:token	Min Length = 0 Max Length = n	XSDPattern="\d*"
N8		Numeric Identifier	NumericChar	xsd:token	Min Length = 0 Max Length = 8	XSDPattern="\d*"
N6	Format=YYMMDD	Date	Date	xsd:token	Min Length = 6 Max Length = 6	dateTimeFormat=“YYMMDD“ XSDPattern="\d*"
N4	Format=HHMM	Time	Time	xsd:token	Min Length = 4 Max Length = 4	dateTimeFormat=“hhmm“ XSDPattern="\d*"
Nn	None of above	Integer	Integer	xsd:integer	Total Digits = n
Nn.m		Decimal	Decimal	xsd:decimal	Total Digits = n+m Fraction Digits = m

Special Situations in VDA Content

When we prepared the VDA content for Integration Advisor, we found some special situations where data elements were not defined in the "expected" way. In some cases, we decided to deviate from the original VDA specification - this was particularly done to avoid problems at runtime. In other cases, we only documented the special circumstances.

List of special cases:

The data element numbers 733_04 and 755_03 are missing on purpose. The VDA specification originally included a table or composite at this position, but these were removed later. To keep compatibility, VDA did not change the following numbers. This resulted in a gap.
Segment 715 was extended in message 4905:4 compared to 4905:3. To keep data element identifiers compatible, we use 515_14 to represent the last data element (Empty) in both versions. Segment 715 in message 4905:4 has two additional data elements, 515_12 and 515_13. In segment 715 for message 4905:3, the data element 515_11 is followed by the last data element 515_14 - data elements 515_12 and 515_13 are not present in this version.
A similar situation occurs for message type VDA4913. Data elements 711_11, 712_17, and 713_20 are not present in message version VDA4913:3. They were added later in version VDA4913:4.
According to the VDA Syntax Rules, alphanumeric data elements (type A) are left-justified and filled with trailing blanks (if needed). Numeric data elements (type N) are right-justified and filled with leading zeros (if needed). Unfortunately, some data elements have contradictory specifications:
- VDA classified three data elements (512_04, 512_06, and 662_18) as type N. In contrast to this, the VDA documentation explicitly states these data elements are left-justified. We reviewed multiple real-life payloads - letters and/or blanks were frequently used for these fields. Therefore, we classified these three data elements as type A.
- VDA classified three more data elements (733_05, 733_07, and 733_09) as type N1 and left-justified. Here we kept the classification as type N. The reason for this decision: these fields are one character long and come with a codelist that allows only numeric values.
- VDA classified about 25 data elements as type A and right-justified. We kept the type A classification for many of these data elements because the evidence in real-life payloads was not conclusive, and because type A covers the more general case.
- For data elements 755_04 to 755_18, however, we changed the classification to type N. Evidence from payloads and SAP Process Integration (SAP PI/PO) support this classification.
Many VDA Codelists allow empty code values (= blank in flat-file representation). The VDA organization classified most of these data elements as alphanumeric (A). However, a few data elements (713_09, 752_07, and 753_08) were classified as numeric (N). An empty or blank value is only allowed for alphanumeric types. Therefore, we changed these data elements to alphanumeric (A).
Some data elements (715_03, 612_03, and all Call-Off Dates in segments 713 and 714) refer to a codelist, but according to the documentation, other values are also allowed. By default, these data elements have the Integration Advisor property NoValidation = true. This means, detailed MIG validation does not consider the code values. To validate the code values, set this property to false.
Special behavior for all Call-off fields (Call-off Dates and Call-off Quantities) in segments 713 and 714: The VDA organization classified these fields as numeric (N) and requires blank values for unused fields. This is contradicting and would result in errors in the MIG payload validation. Therefore, we modeled these fields as NumericChar (xsd:token with XSD pattern = \d*) and set the minimum length to 0. This allows an empty value in the XML representation.

As a general rule, SAP Integration Advisor publishes new B2B Libraries (Type Systems) as provided by the standardization organization. We change the content only if we identify clear errors or inconsistencies. We also make changes if the original content would cause errors or add complexity at runtime.

VDA Usage in SAP Cloud Integration

Cloud Integration now supports processing VDA Messages as well. All relevant EDI Flow Steps offer a fourth configuration option, VDA, in addition to previous options X12, EDIFACT and TRADACOMS. (Please note: As of June 2026 (takt 2604), EDI-To-XML and XML-To-EDI Converters are available - EDI Splitter and EDI Extractor will be added soon.)

In these EDI Flow Steps within your Integration Flow, you need to refer to the XSD for your VDA message. Integration Advisor creates these XSDs as part of the Runtime Export. The file names of these XSDs follow a standard naming convention. For example, VDA4905:4 message is exported as VDA_VDA4905_4.xsd.

VDA payloads do not include explicit information on the message version. As a result, EDI Flow Steps can identify the VDA message (such as VDA4905), but cannot identify the correct message version (such as VDA4905:3 versus VDA4905:4), or the correct message variant (such as VDA4927_1:3 versus VDA4927_4:3). Therefore, your EDI Flow Steps should refer to only one XSD for the same VDA message. For example, your EDI Flow Step can use VDA_VDA4905_4.xsd and VDA_VDA4906_2.xsd, but should not use VDA_VDA4905_3.xsd and VDA_VDA4905_4.xsd at the same time.

Conclusion

With this newest update we now support the VDA Message Standard. You have an end-to-end solution where you can view and customize VDA messages in Integration Advisor and convert these messages in Cloud Integration.

By Category

Related Content

Activity Groups

Industry Groups

Influence and Feedback Groups

Interest Groups

Location Groups

Customer Only Groups

Forums

Related Resources

Products

Learning and Support

About

My SAP Profile

My SAP Profile