Instead of a data type, the format of an AFD attribute can also be based on a codelist. With a codelist, the number of permitted values of an attribute can be limited further than is the case if a generic data type is used. For example, the attribute tripPurpose is of the ADNDRS type (“purpose of the trip”). The possible values of tripPurpose are therefore limited to six values, namely the six codes of the codelist. Each code has a corresponding description, which can be found in AFD Online.

Example codelist

List Code Description
ADNDRS Purpose of the trip
1 Commercieel
2 Stage / studie
3 Vakantie / rondreis
4 Administratief / toezichthouder
5 Au pair
99 Anders

Example usage

"tripPurpose": "2"

External codelists

AFD attributes may also refer to an external codelist, not maintained by SIVI. In such cases, the associated code values are not included in the AFD data catalog. An example is the ISOLAN codelist (“ISO country table”).

Adding codelists and/or code values to the data catalog

Insurers and intermediaries affiliated with SIVI, and suppliers cooperating with SIVI (suppliers authorized to use the AFD), can submit a formal request to SIVI for adding a codelist to the AFD, or adding (one or more) code values to an existing codelist. Requests can be made with the form ‘Aanvraag uitbreiding AFD 2.0’. A working link to the form will follow shortly.

Hierarchical codelists

Defining a hierarchy makes it possible to distinguish and record different levels or groups of code values within codelists. For example neuro surgeon as sub-level of doctor. See the chapter about hierarchical codelists for more information and explanatory examples.

Defining codelist subsets with Schemas

For these restrictions, AFD-definitions can be used in 2.0 (see also the chapter on the AFD-definition Standard). The following is an example of such a restriction in JSON Schema, and a matching sample message that validates against this Schema.

Example JSON Schema:

{
	...,
	"party": {
		"type": "array",
		"items": {
			"type": "object",
			"properties": {
				"entityType": {
					"description": "Unique identification of an entity.",
					"type": "string",
					"enum": ["company"]
				},
				"countryWhereTaxable": {
					"description": "Taxable country",
					"type": "string",
					"enum": ["NL", "BE", "FR"]
				}
			},
			"required": [ "entityType"]
		}
	}
	...
}

Example JSON message that complies with the Schema above:

{
	"party": [ {
		"entityType": "company",
		"countryWhereTaxable": "NL"
	} ]
}

Feedback

Thanks for your feedback.

Post your comment on this topic.

Post Comment