Attribute Value Pairs – AVP

Return to Table of Contents

Structure of the AVP component
Applying an AVP to the instance file
Validation of the AVP values

Attribute Value Pairs – AVP

Starting from release 3.2 of GS1 XML GS1 EDI standard, every message contains placeholders for temporary message components, called Attribute Value Pair – AVP. The reason for adding the AVP was to lower the barrier for implementation. The maintenance releases (minor versions) of GS1 XML standard are published every two years. Such intervals are meant ensure the stability of standards, while providing necessary flexibility in supporting new requirements. In some cases, however, two years publication cycle is not sufficient.
Any urgent requirements can be supported on exceptional basis by adding temporary AVP components to the existing messages that can be used until the nearest GS1 EDI Maintenance Release. The actual attributes and values allowed are stored in the Global Data Dictionary.
In the nearest Maintenance Release the AVPs will be added to the basic message structure, so they should be considered as a temporary solution applied in exceptional cases.
The AVPs may only be implemented for backward compatible changes, thus no AVP will be added for requests leading to a new Major Release.
The details of the AVP management are specified in the document: “GS1 EDI AVP Management rules”.

Structure of the AVP component

The AVP placeholder consists of:

  • a string field – place for the actual data
  • attribute name
  • 3 optional qualifiers – to be used if needed

The AVPs are placed at three levels of the GS1 schemas:

  • document level – via ‘EcomDocumentType’, placed in ‘eComCommon’
  • line item level – if present in the message
  • line item detail level – if present in the message

The list of AVPs published in GDD specifies at which level of the message it can be placed.

Applying an AVP to the instance file

In the instance file, all the AVP should be placed within the ‘avpList’ element, which content conforms to the definition and the attribute name from the AVP list published in the GDD.
Simple example:
In the simplest scenario, an AVP will consist only of the attribute name and data:

  • attributeName – nextDateOfDelivery
  • value – 13052016

Complex example:

In the more complex scenario, an AVP will consist of the attribute name, 3 qualifiers and data:

  • attributeName – yetAnotherTaxAmount
  • qualifierCodeName – EUR
  • qualifierCodeList – CurrencyCode
  • qualifierCodeListVersion – 2011
  • value – 70

In this example, the attribute value must be qualified by a code value taken from the code list, here – CurrencyCode list. It may also be needed to specify the code list version – here it is the ISO list 2011.

The code list can be either the one already used in the standard and stored in the GDD or a new one, also defined as a part of the AVP.

Validation of the AVP values

Only the structure of the AVPs (names and cardinality of attributes) is checked during validation.
The AVPs are defined outside of the schema, therefore their values cannot be validated. The data types of the attribute values are not specified in the schema, so they cannot be checked either. Thus, the dates, amounts, etc. will be treated as a string.


Which of the following best describes the primary purpose of your visit?


Thank you for your feedback!

Were you able to find the information you were looking for on our website?


Thank you for your feedback!