2.6. Unique identifiers and referrals

Defining entities uniquely within the context of a message

It must be possible for every instance of an entity to be uniquely identified within an AFD message, structure or function. This can be done in two ways: with functional and/or technical identifiers. With functional identifiers, entities can be uniquely identified based on attributes that have value in the outside world. For example: the licensePlate of an object, or the contractNumber of a policy or mortgage. These types of identifiers are not explicitly designated as such in the model, but can of course be used as such in certain contexts.

Defining entities uniquely outside the context of a message

It must also be possible for every instance of an entity to be uniquely identified outside an AFD message, structure or function: for example when data is stored in internal databases, and data from future AFD messages needs to be linked to stored information. Again, both functional and/or technical identifiers can be used. To ensure uniqueness over multiple messages, AFD 2.0 introduces the (optional) refKey attribute: a technical identifier which – when used – must be unique over multiple messages, and is mainly intended for the purpose of data storage.
Along with refKey, the refKeySource attribute has also been added to the AFD 2.0 data model. With refKeySource you can indicate from which application and/or application the used refKey originates.

Referrals

New in AFD 2.0 is the possibility to explicitly refer to another entity. For example, within a policy component, an explicit reference can be made to the corresponding package policy. In this way, the relationship no longer needs to be implicitly derived from the hierarchy. New attributes for these references are included in the data catalog. For example, within a policy component, the explicit reference to the relevant masterAgreement entity can be established using the masterAgreementRef attribute.

Example

The example below shows multiple coverages and objects. The same message would become unclear with hierarchies: both motorVehicle objects must refer to the same coverage entity. In AFD 2.0 this is solved by referring explicitly in the relevant coverage entity to the refKey of the relevant object entities, via the objectRef array.

See AFD 2.0 Online for the complete and up-to-date data catalog with all available entity types and associated attributes. More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI AFS.

{
	"policy": [ {
		"entityType": "policyDetails",
		"refKey": "P20190101010",
		"porCompany": "M088",
		"contractNumber": "P20190101-010",
		"party": [ {
			"entityType": "policyHolder",
			"refKey": "9082315781",
			"firstName": "Maria",
			"surname": "de Jong"
		} ],
		"object": [ {
			"entityType": "motorVehicle",
			"refKey": "SIVI20",
			"licensePlate": "SIVI20",
			"carManufacturer": "Fiat",
			"type": "Panda"
		},
		{
			"entityType": "motorVehicle",
			"refKey": "VISI40",
			"licensePlate": "VISI40",
			"carManufacturer": "Citroen",
			"type": "DS"
		},
		{
			"entityType": "building",
			"refKey": "building1208935",
			"propertyType": "00001",
			"constructionYear": "1954"
		} ],
		"coverage": [ {
			"entityType": "hullVehicle",
			"refKey": "78927127",
			"coverageCode": "2002",
			"deductibleAmount": "799.85",
			"objectRef": ["SIVI20", "VISI40"]
		},
		{
			"entityType": "building",
			"refKey": "089251376",
			"coverageCode": "5001",
			"deductibleAmount": "15990",
			"objectRef": ["building1208935"]
		} ]
	} ]
}