Data types

In AFD 2.0, data types and format restrictions are separated. As a result, AFD 2.0 only has seven native data types: integer, decimal, string, date, time, timestamp and boolean. The inclusion of boolean instead of ADNLOG implements a much-anticipated wish from the industry. In terms of format, time and date are adapted to the applicable standards within XML and JSON: date is written as CCYY-MM-DD (with dashes) within AFD 2.0, time as hh: mm: ss (with colon).

AFD data type Description XML JSON
integer Number without decimal places integer integer
decimal Number with decimal places decimal number
string Alphanumeric field string string
date Date of format CCYY-MM-DD date string¹
time Time of format hh:mm:ss time string²
boolean True or false boolean boolean
timestamp Timestamp following the ISO 8601-format (yyyy-mm-ddThh:mm:ss[.sss]Z),
for example 2018-12-10T13:49:51.141Z
dateTime string³

¹ Note that JSON considers the date format a subset of the string data type. From JSON Schema 7.0 on, specific date formats can be validated of type CCYY-MM-DD.
² Note that JSON considers the time format a subset of the string data type. From JSON Schema 7.0 on, specific time formats can be validated of type hh:mm:ss.
³ Note that JSON considers the timestamp format a subset of the string data type. From JSON Schema 7.0 on, specific datetime formats can be validated of type yyyy-mm-ddThh:mm:ss[.sss]Z.

The data catalog of AFD 2.0 defines the data type of an attribute but does not limit the string-length or number of decimals. If a supplier wants to apply extra restrictions, he can add these in AFD-definitions. It is easy to set up these restrictions through AOS.

In AFD 2.0 Online you can find the data type of each attribute. More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI AFS.


Another innovation is the addition of arrays. By reducing the number of entities in AFD 2.0, entities increasingly occur repeatedly in a message or function. With the newly introduced support from JSON, a syntax has been chosen that intrinsically supports arrays, as opposed to XML. Therefore, all entities in AFD 2.0 are arrays by default, even if only one instance is defined within the message. Building on this development, and also regarding eliminating redundancy in the data catalog, some attributes are also used as array. Example attributes are coverageAreaCode (_GEBIED) and companyTypeSpecification (_SBISPCC): a coverage can apply to multiple areas (codelist ADNDKG) and a company can have multiple company types from the corresponding codelist (ADNABS). In XML, arrays will be represented as an xs:list.

Attributes used as an array always contain an array of one specific data type or codelist. In the data catalog this is indicated by square brackets; coverageAreaCode is of type [ADNDKG] for example. The following is a (non-exhaustive) list of attributes used as Array, and their respective attributes in AFD 1.0.

Examples of attributes used as Array

Attribute Description Codelist Data type Corresponding attribute(s) in AFD 1.0
calculationFactor Collection of calculation factors. [string] FACTORS, RFCTR1, RFCTR2, etc.
companyTypeSpecification Coded specification of company type. This is an additional specification on the SBI code. The code is company specific. [ADNABS] [string] SBISPCC
previousFundType Types of old/previous funds. [ADNFON] [string] FNDCDO
surchargeAmount Amounts of surcharges. [decimal] TOEWR1, TOEWR2, etc.

Example message using Array

	"party" : [ {
		"entityType": "company",
		"companyTypeSpecification": ["1006", "1007"],
		"ceaCode": "1234567",
	} ],

Note: array attributes that have only one value within the message are still written as array (in JSON with square brackets). In the example above that would be "companyTypeSpecification": ["1006"].


Thanks for your feedback.

Post your comment on this topic.

Post Comment