4 gif-IDA exchange format
The quality of the data to be exchanged primarily depends on the defined rules being unique and verifiable. The sender should already be able to check the quality of the data provided or validate it against agreed rules. Underlying rules must be automated on this basis and verifiable. In recurring exchange processes in particular (e.g., monthly reporting), this sign of quality is extremely important. The sender and recipient should be able to focus on their key tasks, instead of having to involve extensive resources in carrying out data quality checks. For this reason, gif has decided to recommend XML formats (Extensible Markup Language) for exchanging data. Furthermore, XML files provide the option of exchanging sizeable file structures in one file container irrespective of the platform and implementation, in particular via the internet.
XML schemas (or XSD for XML Schema Definition) form part of this guideline per subset, describing the structure of the XML documents. All content, structure and format specifications, and reliable attributes are described via an XML schema per subset. The XML schemas will be updated with each new version of the complete data field catalog, and the corresponding validation programs will be provided. All versions of the complete data field catalog are permanently available with their respective XML schema per subset.
XML formats can only be interpreted with specialist tools and the corresponding expertise. So they are generally suitable for use by software vendors and experienced IT departments. The gif certificate for compliant data exchange per subset is only issued for XML-based data exchange formats. If it is necessary to exchange data between non-certified systems, please refer to the specifications for the tabulated exchange of data via CSV (comma-separated values) in section 4.4.
4.2 Formatting guidelines
Data object and identification number
Each data object requires a unique identification number (ID). The ID is formed from the assigned identification numbers of the sender's lead system. The recipient's identification number can also be stored and exchanged. References to other asset attributes (e.g., client) can be made by the sender and accepted by the recipient.
The following information must be present with all data objects:
- Start of validity: The start of validity at least must be specified for all data objects to be imported.
- End of validity: The end of validity is a field delivered with all data objects (asset, building, land, and rental units). If information on the end of validity is missing, it is assumed that validity is unlimited. If the validity of the data object is unlimited (e.g., unlimited lease contract), this data field is transferred empty.
- Data area: The data area specifies the aim or purpose of the data to be imported - for example, budget data, forecast data, actual data. As an option, a description can also be provided as free text.
- Combination of assets, buildings, rental units: If existing data objects (such as two rental units) are combined, the end of validity for one or both of the data objects is set in the delivery system. No data objects may be deleted in the delivery system, as the data fields in the target system are not updated as part of the data exchange.
The following formatting rules are applicable for the various types of data field:
- Decimal display: In accordance with DIN EN ISO 80000: The period is the separating character; there is no digit grouping, and numbers less than 1 have a leading zero.
Examples: 0.55, 16332.63456, -44.673
- Negative values: Minus sign to the left of the numerical amount
- Data object identifiers: It is necessary to indicate all higher-level data objects of relevance for the data object (e.g., company). If required, these are indicated by the recipient.
If certain higher-level structures are not relevant for the data object (e.g., property company/ SPV), the identifier component remains empty.
Unavailable identifier components are supplemented with "filler zeros".
Data object identifiers should only comprise capital letters A to Z, digits, and the characters '_' or '-', e.g.: MA0001, MA0001_DE. In particular, special characters are not allowed in the data object identifiers.
The NAME field must always be completed for new data objects.
The various amounts in data fields are formatted in accordance with the following rules:
- Percentage values: Without percentage sign as absolute valueExamples:
5% becomes 0.05
62.75% becomes 0.6275
110% becomes 1.10
- Amount of money: Indicated as a decimal number plus currency in accordance with ISO 4217 (currency indicator is optional, provided it has already been specified for the entity or higher-level entity)
- Length/ area: Indicated as a decimal number. Measuring unit based on SI system in "meters", alternative measuring units can optionally be indicated based on list of attributes.
- Date values: In accordance with ISO 8601: YYYY (year only), YYYY-MM (year and month), YYYY-MM-DD (for exact day)
Example: December 6, 2013 becomes 2013-12-06
- Duration (of time): In accordance with ISO 8601
Example: 1 year and 3 months becomes P1Y3M
- Boolean value: Statement is true or false
Example: true/ false
- Country: In accordance with ISO 3166-1 ALPHA-3
Germany becomes DEU
The United States becomes USA
- Language: In accordance with RFC 1766
Examples: de-DE, de-AT, en-US, en-GB, etc.
4.3 Data exchange via XML files
With each version of the complete data field catalog, XSD files will be published containing the XML schema per subset. The XML schema describes data types in a complex schema language - individual XML schema instances (documents). In future, XSD requirements for rule sets will also be published; they will serve as filters on the XSDs of a subset. A detailed technical description, which forms part of this guideline, can be found in Annex H.3.
4.3.1 Elements of XML data exchange format
The gif exchange format comprises the following elements:
- Content and structural data Information on all files transferred within the data exchange process, as well as the master/ meta data on the actual data exchange, such as date created, validation date, version, created by, language, etc. (see file description of maniftest.xml, mimetype, type, meta.xml)
- Data files: These elements contain the actual data on the exchange in accordance with the specified format structure. If more than one period is exchanged, these files are available per period (see file description of maindata.xml, periods.xml).
- Documents: As an option, accompanying documents (e.g., lease contracts, invoices, etc.) can be transferred on any date (see description of objects directory).
- Schemas: As an option, the schema applicable for each XML file can also be transferred.
- Rule sets: Any rule sets agreed are an integral element of the data exchange format.
The data exchange process for all elements is carried out via a zipped data container (zgif). The zipped gif data exchange format (zgif for short) is the central format for transmitting process-related data, as defined by gif. The "zgif" file suffix was chosen primarily because it does not yet have any other significance as a file suffix in IT terms. This prevents any risk of confusion. The "z" stands for "zip" - so it is immediately clear that it is a ZIP container, which can be decompressed using a standard ZIP decoder. The second part of the suffix "gif" corresponds to the abbreviation of the format publisher, i.e., gif.
4.3.2 Online Wiki
The entire XML format is described in detail in the knowledge base of gif e.V. It can be accessed free of charge at www.zgif.org. The detailed information that is available includes the following:
- Specifications on reading zgif files
- Example downloads
• API programs to support the reading and writing of zgif files. It provides object-oriented access to the entities and their data fields.
4.4 Tabular exchange via CSV files
If it is necessary to exchange data between non-certified systems, please refer to the following specifications for the tabulated exchange of data via CSV (comma-separated
values). gif provides a separate converter for this purpose (ICRED). A detailed technical description, which forms part of this guideline, can be found in Annex H.4.
4.4.1 Transfer tables
To exchange data in CSV format, the Excel tables transferred with each subset can be used for the technical definition. The lead for the technical data field names is provided by the respective XSD definition.
The following tables form part of the CSV-based data exchange process:
- Metadata – META.csv
- Period – PERIOD.csv
- Connection – CONNECTION.csv
- Currency – CURRENCY.csv
- Client - COM.csv
- Property/ assets – PROP.csv
- Land – LAND.csv
- Building – BUILD.csv
- Rental unit/ space – UNIT.csv
- Lease contract – LEASE.csv
- Contract object/ term – TERM.csv
- Contracting party – PARTNER.csv
- Service contract – CON.csv
- Project – PROJ.csv
- Loan – LOANS.csv
- Book entries – BOOK.csv
- Records – VOU.csv
- Valuations – VALUATION.csv
- Securities – SHARES.csv