Common use of Validation of completeness Clause in Contracts

Validation of completeness. The metadata checksum file is part of the files to be submitted. For each entity type, the required type of checksum is listed. For now, no checksum is requested, only, a logical row count is requested for each entity type. This count indicates the number of instances of an entity type that is appropriate to this entity type in accordance with the logical data model. Please note that this concerns the entities in the logical data model and not only those in the physical data deliveries: the logical data model also requires a row count and checksum for those entity types that do not have a corresponding .csv file to be delivered. 2.6.6.1 Example of a check on a physical delivery E.g. the bank must deliver exactly 100,000 bank accounts. The bank_account.csv file contains 100,000 rows. The row count for the logical entity is 100,000. The entity type delivery lists a row count of 100,000 for the "bank account" entity type. DNB checks that 100000 = 100000 and accepts the delivery. 2.6.6.2 Example of a check on a logical delivery The entity types "non blocked bank account" and “blocked bank account” do not have their own specific features, and therefore do not require physical delivery. However, the logical checksum and/or rowcount of “non blocked bank account” and “blocked bank account” must be delivered. For example, the bank must deliver exactly 100,000 bank accounts, 1,500 of which are blocked bank accounts and 98,500 are non blocked bank accounts (100,000-1,500). Only one file must be reported: 1. bank_account.csv with 100,000 records Altough, three records must be reported in the entity type delivery: Bank account 100,000 Blocked bank account 1,500 Non blocked bank account 98,500 DNB checks if bank_account.csv contains 100,000 rows and if 1,500 rows and 98,500 rows in bank_account.csv logically consist of respectively blocked bank accounts and non blocked bank accounts. An example of the entity_type_delivery content can be found in Apendix C. 2.6.6.3 Check on primary key The LDM has entity types that allow DNB to ask for checks on combinations of attributes. This mechanism is primarily meant to check the integrity of primary keys of the entity types in the logical data model. Currently, no checks of these types are foreseen, since DNB will rely instead on the hashing of the csv files themselves, in combination of the checks on the referential integrity as specified in the logical data model. This entails that the file attribute_combination_delivery.csv must be reported as an empty file. Nevertheless, as for all .csv files, the header is mandatory.