4 gif-IDA Austauschformat

4.1 Allgemeines

Die Qualität der auszutauschenden Daten hängt im Wesentlichen von der Eindeutigkeit und Überprüfbarkeit definierter Regeln ab. Schon der Sender soll die Qualität der bereitgestellten Daten überprüfen bzw. gegen vereinbarte Regeln validieren können. Grundlegende Regeln müssen auf dieser Basis automatisiert und prüfbar sein. Insbesondere im Rahmen wiederkehrender Austauschprozesse (z.B. monatliches Berichtswesen) ist dieses Qualitätsmerkmal von sehr großer Bedeutung. Sender und Empfänger sollten sich jeweils auf ihre Kernaufgaben konzentrieren können, statt umfangreiche Ressourcen in Datenqualitätsprüfungen binden zu müssen. Auf Grund dessen hat sich die gif entschlossen, XML-Formate (Extensible Markup Language (engl. „erweiterbare Auszeichnungssprache“) für den Datenaustausch zu empfehlen. Darüber hinaus bieten XML-Dateien die Chance, umfassende Dateistrukturen in einem Dateicontainer plattform- und implementationsunabhängig auszutauschen.

Teil der vorliegenden Richtlinie sind XML-Schemen (beziehungsweise XSD für XML-Schema-Definition) je Subset, welche die Struktur der XML-Dokumente beschreiben. Alle zu berücksichtigenden Inhalte, Struktur- und Formatvorgaben sowie zulässige Ausprägungen werden über ein XML-Schema je Subset beschrieben. Mit jeder Version des Datenfeldgesamtkatalogs werden künftig die XML-Schemen aktualisiert Alle Versionen des Datenfeldgesamtkatalogs werden dauerhaft mit ihrem jeweiligen XML-Schema je Subset verfügbar sein.

XML-Formate sind nur mit spezialisierten Tools und entsprechenden Fachkenntnissen automatisiert interpretier- und validierbar. Daher sind sie als Quelle geeignet, von Softwareanbietern und versierten IT-Abteilungen aufgegriffen zu werden. Soweit der Austausch unter nicht zertifizierten Systemen erfolgen muss, kann der ICRED eine Transformation der jeweiligen Daten in das tabellarische CSV-Format (Comma-separated values) vornehmen, siehe auch Kapitel 4.4.

4.2 Formatierungsrichtlinien

4.2.1 Informationsobjekt und Identifikationsnummer

Jede im Datenaustausch zu berücksichtigende Entität benötigt eine eindeutige Identifikationsnummer. Die Identifikationsnummer ist jeweils fester Bestandteil jedes Subsets. Im Rahmen des Datenaustausches gemäß gif-IDA vereinbart der Sender und Empfänger einmalig, welches System führend für die Vergabe der Identifikationsnummern ist. Auch die redundante Übergabe der Sender und der Empfänger ID ist in einigen Subsets möglich. Beim wiederholten (z.B. monatlichen) Datenaustausch soll über die Vergabe der Identifikationsnummern, beziehungsweise die Kombination der Identifikationsnummern höherer Hierarchien, die Position der Entität im Datenmodell abgeleitet werden können.

In der Regel werden vom Empfänger die entsprechenden Identifikationsnummern zur Identifikation des Vermögens (z.B. Mandant) sowie die Identifikationsnummern der Wirtschaftseinheiten übergeben. Alle tieferen Entitätshierarchien (z.B. Mietvertragsnummern) werden vom Sender vorgegeben. Ausnahmen können bei der initialen Übernahme von Beständen, z.B. nach Verwaltungsübergang bestehen. Existiert die Immobilie bereits im Eigentum des Empfängers bevor der Sender mit der Verwaltung/dem Management beauftragt wurde, übernimmt der Sender initial alle Identifikationsnummern des Empfängers. Neue Identifikationsnummern für neue Entitäten (z.B. für neue Mietverträge, Flächen) werden vom Sender vergeben und vom Empfänger übernommen.

Abweichende Regelungen müssen zwischen Sender und Empfänger ausdrücklich vereinbart werden.

4.2.2 Gültigkeiten

Zu allen Informationsobjekten müssen folgende Angaben vorliegen:

Gültigkeitsbeginn: Zu allen zu importierenden Entitäten (Informationsobjekte) muss mindestens der Gültigkeitsbeginn angegeben werden.
Gültigkeitsende: Ein Gültigkeitsende ist ein Feld, das zu allen Entitäten (Informationsobjekte) geliefert wird (Wirtschaftseinheit, Gebäude, Grundstück und Mieteinheiten). Fehlen Angaben zum Gültigkeitsende, so wird eine unbefristete Laufzeit angenommen. Soweit die Gültigkeit der Entitäten (Informationsobjekte) unbefristet ist (z.B. unbefristeter Mietvertrag), ist das Datenfeld leer zu übergeben.
Datenbereich: Der Datenbereich gibt das Ziel bzw. den Zweck der zu importierenden Daten an beispielsweise Plan-, Forecast-, Ist-Daten. Optional kann zusätzlich ein Freitext als Bezeichnung angegeben werden.
Zusammenlegung von Wirtschaftseinheiten, Gebäuden, Mieteinheiten: Werden bestehende Entitäten (Informationsobjekte) (wie z.B. zwei Mieteinheiten) zusammengelegt, so ist das Gültigkeitsende für eines oder beide Entitäten (Informationsobjekte) im Quellsystem zu setzen. Es dürfen keine Entitäten (Informationsobjekte) im Quellsystem gelöscht werden, da im Rahmen des Datenaustauschs die Datenfelder im Zielsystem nicht entsprechend aktualisiert werden.

4.2.3 Formate

Es gelten für die unterschiedlichen Arten der Datenfelder folgende Formatierungsregeln:

Dezimalzahldarstellung: nach DIN EN ISO 80000: Trennzeichen ist der Punkt; es gibt keine Zifferngruppierung und Zahlen kleiner als 1 haben eine führende Null.
Beispiele: 0.55, 16332.63456, -44.673
Negative Werte: Minuszeichen links vor dem Zahlenwert
Beispiel: -200.00
Entitäts-/ Informationsobjektkennungen: Es müssen alle für das Informationsobjekt relevanten übergeordneten Informationsobjekte (z.B. Mandant) angegeben werden. Diese werden falls erforderlich vom Empfänger vorgegeben.
Sind für das Informationsobjekt bestimmte übergeordnete Strukturen (z.B. Objektgesellschaft/SPV) nicht relevant, bleibt der Kennungsbestandteil leer.
Nicht vorhandene Kennungsbestandteile werden mit `Füllnullen´ ergänzt. Informationsobjektkennungen sollen nur aus Großbuchstaben A bis Z, Zahlen und den Zeichen '_' oder '-' bestehen, Bsp.: MA0001, MA0001_DE. Insbesondere Sonderzeichen sind in der Kennung der Informationsobjekte nicht zugelassen. Zu neuen Informationsobjekten muss das Feld NAME immer gefüllt werden.
Die Formatierung der unterschiedlichen Werte von Datenfeldern folgt nach folgenden Regeln:
Prozentwerte: Ohne Prozentzeichen als absoluter Wert
Beispiele:
5% wird zu 0.05
62.75% wird zu 0.6275
110% wird zu 1.10
Geldbetrag: Angabe als Dezimalzahl zzgl. Währung nach ISO 4217 (Währungsangabe optional, sofern bereits für Entität oder übergeordneter Entität angegeben)
Länge/Fläche: Angabe als Dezimalzahl. Maßeinheit nach SI-System in „Meter“, optionale Angabe alternativer Maßeinheit nach Ausprägungsliste.
Datumswerte: Nach ISO 8601: YYYY (nur Jahr), YYYY-MM (Jahr und Monat), YYYY-MM-DD (taggenau)
Beispiel: 6. Dezember 2013 wird zu 2013-12-06
(Zeit-)Dauer: Nach ISO 8601
Beispiel: 1 Jahr und 3 Monate wird zu P1Y3M
Wahrheitswert: Nach https://www.w3.org/TR/xmlschema-2/#boolean True = 1, false = 0 Aussage trifft zu oder ist falsch Beispiel: 1
Land: Nach ISO 3166-1 ALPHA-3
Beispiele:
Deutschland wird zu DEU
Vereinigte Staaten von Amerika wird zu USA
Sprache: Nach RFC 1766
Beispiele: de-DE, de-AT, en-US, en-GB, etc.

4.3 Datenaustausch per XML-Dateien

Mit jeder Version des Datenfeldgesamtkataloges werden künftig XSD-Dateien veröffentlicht, welche das XML-Schema je Subset beinhalten. Das XML-Schema beschreibt in einer komplexen Schemasprache Datentypen, einzelne XML-Schema-Instanzen (Dokumente). Zukünftig werden zusätzlich XSD Vorgaben für Rule Sets veröffentlicht werden, welche als Filter auf die XSDs eines Subsets dienen. Eine detaillierte technische Beschreibung ist als Anlage H.3 Bestandteil der Richtlinie.

Technische Beschreibung zgif-Format Version "0"

4.3.1 Elemente des XML-Datenaustauschformates

Das gif-Austauschformat besteht aus folgenden Elementen:

Inhalts- und Strukturdaten: Informationen zu allen im Rahmen des Datenaustausches übergebenen Dateien, sowie der Stamm-/Metadaten zum eigentlichen Datenaustausch wie Erstell-/ Validierungsdatum, Version, Ersteller, Sprache, etc. (siehe Dateibeschreibung maniftest.xml, mimetype, type, meta.xml)
Datendateien: Gemäß der vorgegebenen Formatstruktur enthalten diese Elemente die eigentlichen Daten des Austausches. Werden mehrere Perioden ausgetauscht, stehen diese Dateien je Periode zur Verfügung (siehe Dateibeschreibung maindata.xml, periods.xml).
Dokumente: Optional können zu jedem Datum begleitende Dokumente (z.B. Mietverträge, Rechnungen,…) übergeben werden (siehe Beschreibung objects-Verzeichnis).
Schemata: Optional können zu jeder XML-Datei die jeweils gültigen Schemata übergeben werden.
Rule Sets: Etwaig vereinbarte Rule Sets sind ein festes Element des Datenaustauschformates.

Der Datenaustausch aller Elemente erfolgt über einen gezippten Datencontainer (zgif). Das gezippte gif-Datenaustauschformat (kurz: zgif) ist das zentrale Format zur Übertragung von prozessbezogenen Daten, wie es von der gif definiert wird. Die Dateiendung "zgif" wurde gewählt, vor allem da diese noch keine andere Bedeutung als Dateiendung in der IT besitzt. Somit ist eine Verwechselungsgefahr ausgeschlossen. Das "z" steht für "zip" - wodurch direkt klar wird, dass es sich um einen ZIP-Container handelt, welcher mit einem üblichen ZIP-Decoder entpackt werden kann. Der zweite Teil "gif" entspricht der Abkürzung der Herausgeberin des Formates, der gif.

4.3.2 Knowledge Base

- entfällt -

4.4 Tabellarischer Austausch per CSV-Dateien

Soweit der Austausch unter nicht zertifizierten Systemen erfolgen muss, sind die nachfolgenden Vorgaben für den tabellarischen Austausch per CSV (Comma-separated values) zu beachten. Hierzu stellt die gif einen separaten Converter zur Verfügung (ICRED). Eine detaillierte technische Beschreibung ist als Anlage H.4 Bestandteil der Richtlinie.

4.4.1 Übergabetabellen

Für den Austausch im CSV-Format können zur fachlichen Definition die mit jedem Subset übergebenen Exceltabellen genutzt werden. Führend bezüglich der technischen Datenfeldbezeichnungen ist die jeweilige XSD Vorgabe.

Folgende Tabellen sind Teil des CSV-basierten Datenaustausches:

Metadaten – META.csv
Periode – PERIOD.csv
Verbindung – CONNECTION.csv
Mandant – COM.csv
Immobilien/Wirtschaftseinheiten – PROP.csv
Grundstück – LAND.csv
Gebäude – BUILD.csv
Mieteinheit/Fläche – UNIT.csv
Mietvertrag – LEASE.csv
Vertragsobjekt/Kondition – TERM.csv
Partner – PARTNER.csv
Leistungsvertrag – CON.csv
Projekt – PROJ.csv
Darlehen – LOANS.csv
Buchungen – BOOK.csv
Belege – VOU.csv
Gutachten – VALUATION.csv
Wertpapiere – SHARES.csv

4.5 Datenaustausch per JSON.Datei

Neben dem XML-Format hat sich in den letzten Jahren das JSON-Format als Dateiformat für einen strukturierten Datenaustausch etabliert. Die gif empfiehlt dieses Format neben dem XML-Format als präferiertes Austauschformat zwischen Sender und Empfänger, soweit die Schnittstellen beim Exportieren und Importieren das Dateiformat verarbeiten können. Die Struktur entspricht nahezu der des XML-Formats in Kap. 4.3.

4.6 Commercial Digital Twin

Mit Version 3.0 dieser Richtlinie werden folgende Skripte zur Erstellung einer Datenbank gem. dem gif-Datenmodell zur Verfügung gestellt:

Skript “010 crt gif_twin tables”: Die Ausführung dieses Skripts erstellt die wichtigsten Entitäten (“Tabellen / Tables”), deren Beziehung untereinander (“Primärschlüssel” und “Fremdschlüssel”) und deren Felder. Die Ausprägungslisten werden als eigene Tabellen mit dem Präfix “gifcode” angelegt.
Skript “020 insert gifcode values”: Die Ausführung dieses Skripts befüllt die Ausprägungslisten-Tabellen mit den gültigen Ausprägungen.
Skript “040 crt example data”: Die Ausführung dieses Skripts erstellt einige Beispieldaten in der erzeugten.

Die Basis für einen “kaufmännischen digitalen Zwilling” wird damit gelegt. Basierend auf dem Datenmodell können insbesondere die kommerziell wichtigsten ESG-Datenfelder des Asset Managements, der Eigentümerstrukturen und Gesellschaften und der Buchführung dargestellt werden. Die Skripte basieren auf den Strukturen des Microsoft® SQL Server. Auf nachfolgender Abb. 7 einige Bildschirmausschnitte aus der entstandenen Datenbank.

Diese Strukturen mit den Echtdaten aus den Vorsystemen zu befüllen ist eine spezifische Aufgabe. Mit dem digitalen Zwilling ist aber eine harmonisierte Grundstruktur gegeben, an der sich weitere Fremdsysteme leicht anschließen können.