IDL DataMart. IDL Workplace Server 2014 Update 3 IDL.KONSIS.FORECAST A

Transkript

1 IDL Workplace Server 2014 Update 3 IDL.KONSIS.FORECAST A

2 Inhaltsverzeichnis Abbildungsverzeichnis... 4 Tabellenverzeichnis... 5 Glossar Grundlagen Was ist IDL DATAMART Star-Schema Fakten SSAS-Modell Unterschiede zwischen IDL DATAMART und MISPAR Datenbanken IDL.KONSIS OLAP-Datenbanken Licensing und Bereitstellung Customizing Fachlicher Umfang Mehrsprachigkeit Views SSAS-Modell Reihenfolge Software-Voraussetzungen Prozess IDL.KONSIS-Schritte MISPAR-Parametrisierung OLAP-Zuordnungen Konzernstrukturen und Datenarten IDL Workplace Server Schritte IDL.KONSIS-Verbindung im IDL Portal Bereitstellung im IDL Portal Berechnungen und Rules Bereitstellung ohne IDL Workplace Server Dimensionen Kontenstruktur Wechselkonten Berechnungen Standard Sets Konzern Definition Historisierung Reporttechnische Konzerne Gesellschaft IC-Gesellschaft IDL GmbH Mitte

3 3.5 Datenart Aufriss Konsolidierungsart Konsolidierungsverarbeitung Spiegel Währung Geschäftsbereich Zeit Jahresabschluss Abweichendes Geschäftsjahr Monat Hierarchie Zeitart Zeitvergleich Controlling-Dimensionen Views SSAS-Modell Visualisierung Measure Groups und Cubes Finance Cube Konzernreporting Gesellschaftsreporting Beteiligung Datenübersicht Granularität und Aufrisse (DrillThrough) Rules und Berechnungen Bilanzgewinn Kapitalflussrechnung (KFR) Cube Betrieb Performance Inkrementelles Laden/Prozessieren Datenaktualisierung Autorisierung Historisierung Konzernstruktur Daten Customizing Customizing des SSAS-Modells Komplett individuelle OLAP-Landschaft Release-Sicherheit (Updates) und Wartung FAQ...28 IDL GmbH Mitte 3

4 Abbildungsverzeichnis Abbildung 1: IDL DATAMART Datenfluss 7 Abbildung 2: MISPAR vs DATAMART Lösung 9 Abbildung 3: MISPAR-Parameter Version (04) DataMart 12 Abbildung 4: Normale vs. OLAP-Zuordnungen 12 Abbildung 5: Standard OLAP-Zuordnungen 13 Abbildung 6: OLAP-Kontenstruktur 14 Abbildung 7: Datenarten 15 Abbildung 8: IDL.KONSIS-Verbindung im IDL Portal 16 Abbildung 9: Bereitstellung im IDL Portal 16 Abbildung 10: Datenfluss der relevanten Views für Salden 23 Abbildung 11: Datenfluss der relevanten Views für Buchungen/Spiegel 23 Abbildung 12: IDL.DESIGNER Beispiel mit Beteiligungen und Datenübersicht 25 Abbildung 13: Datenberechtigungen (AS Rollen) im IDL Portal 27 4 IDL GmbH Mitte

5 Tabellenverzeichnis Tabelle 1: Fachlicher Umfang Tabelle 2: Software Voraussetzungen für 2014 Update Tabelle 3: Die Aufriss Dimension Tabelle 4: Die Konsolidierungsart Dimension Tabelle 5: Die Zeitart Dimension Tabelle 6: Die Zeitvergleich Dimension Tabelle 7: Quelle für Konzernreports Tabelle 8: Quelle für Gesellschaftsreports IDL GmbH Mitte 5

6 Glossar SSAS SQL Server Analysis Services MG Measure Group SSDT Microsoft SQL Server Data Tools SSMS Microsoft SQL Server Management Studio 6 IDL GmbH Mitte

7 1 Grundlagen 1.1 Was ist IDL DATAMART IDL DATAMART ist kein Produkt, sondern eine technische Komponente des IDL Workplace Servers um Reporting und Analyse von IDL.KONSIS Daten zu ermöglichen. IDL.KONSIS ist ein transaktionales System mit dem Ziel, eine Konzern-Konsolidierung schnell und einfach durchzuführen. Das IDL.KONSIS-Datenmodell ist allerdings für Analyse wenig geeignet. Eine Analyse ist über ein multidimensionales Modell perfomanter und intuitiver durchführbar. IDL DATAMART automatisiert die Datenflüsse zwischen IDL.KONSIS und einem multidimensionalen Modell, das auf Microsoft SQL Server Analysis Services (SSAS) basiert. Dieses SSAS-Modell ist das Herzstück der neuen IDL-Reporting-Plattform die das Erstellen, Verteilen und Administrieren von Berichten und Dashboards ermöglicht. IDL DATAMART besteht aus folgenden Hauptkomponenten: Star Schema: Relationale Views, die sämtliche Salden, Buchungen und Bewegungen zur Verfügung stellen SSAS-Modell: Ein vorgefertigtes SSAS-Modell, das in der IDL-Reporting-Plattform nutzbar ist Abbildung 1: IDL DATAMART Datenfluss IDL GmbH Mitte 7

8 1.2 Star-Schema Das IDL DATAMART Star-Schema besteht aus Views, die innerhalb der IDL.KONSIS-Datenbank persistent bereitgestellt werden. Im Gegensatz zur MIS-OLAP-Bereitstellungsfunktion (kurz (MISPAR) ist es nicht erforderlich, einen Prozess zur Befüllung der neuen Views anzustoßen Fakten IDL DATAMART stellt 2 Arten von Fakten-Views zur Verfügung. Die Views OLAP_DW_XXX liefern Daten ohne Report-Bezug, d.h. sie enthalten sämtliche Konten für die gewählte Datenart und Periode. Die Views OLAP_Fact_XXX haben einen direkten Kontenstruktur(Report)-Bezug. Beispiel: Ein Konto, das in 2 Berichten vorkommt, erscheint 1-mal in den Views OLAP_DW_XXX und 2-mal in den Views OLAP_Fact_XXX. Mehr dazu im Kapitel Measure Groups und Cubes. 1.3 SSAS-Modell Das IDL DATAMART SSAS Modell ist ein fertiges, vollständiges SSAS-Modell, das ohne Erweiterungen bereitgestellt werden kann. Das Modell besteht aus folgenden Dimensionen: Aufriss Datenart Geschäftsbereich Gesellschaft IC-Gesellschaft Kontenstruktur Konzern Konsolidierungsverarbeitung Konsolidierungsart Spiegel Währung Zeit Zeitart Zeitvergleich Controlling Dimensionen (falls definiert) IDL DATAMART ist eine Standardlösung. Trotzdem kann das SSAS-Modell individuell angepasst werden, um weitere, kundenspezifische Dimensionen hinzuzufügen oder die definierten Dimensionen anzupassen. 1.4 Unterschiede zwischen IDL DATAMART und MISPAR IDL DATAMART verfolgt ein ähnliches Ziel wie die MISPAR-Schnittstelle, nämlich Strukturen und Daten aus IDL.KONSIS für Datenbanken zur Verfügung zu stellen, die auf Analyse- und Reporting ausgerichtet sind. Die Hauptunterschiede zwischen IDL DATAMART und MISPAR sind: MISPAR erstellt fixe Tabellen, deren Befüllung angestoßen werden muss. IDL DATAMART basiert auf relationalen Views, die jederzeit mit den aktuellen Zahlen konsumierbar sind. 8 IDL GmbH Mitte

9 IDL DATAMART enthält ein SSAS-Modell, MISPAR dagegen ist eine relationale Schnittstelle. IDL DATAMART stellt nicht nur das Konzern- sondern auch das Gesellschaftsreporting zur Verfügung. Abbildung 2: MISPAR vs DATAMART Lösung 1.5 Datenbanken IDL.KONSIS IDL DATAMART ist im Release 2014.A für SQL Server und Oracle freigegeben OLAP-Datenbanken Es wird eine SSAS OLAP-Datenbank im Multidimensional Modus angelegt. Der Tabular Modus von SSAS wird nicht unterstützt. IBM TM1 oder Infor ION BI OLAP-Datenbanken werden nicht unterstützt. Allerdings ist das IDL DATAMART SSAS-Modell auf diese Datenbanken übertragbar. 1.6 Licensing und Bereitstellung Obwohl IDL DATAMART technisch betrachtet unabhängig von MISPAR ist, läuft die Lizenzierung über MISPAR. D.h. die relationalen Views können nur dann erstellt werden, wenn MISPAR lizenziert wird. Über MISPAR werden die Parameter für den Aufbau der Views gesetzt. IDL GmbH Mitte 9

10 1.7 Customizing DATAMART stellt die Basis für ein Standard IDL-Modell zur Verfügung. Das SSAS Model kann erweitert bzw. geändert werden, um individuelle Anforderungen abzubilden. Mehr dazu im Kapitel Customizing. 1.8 Fachlicher Umfang MISPAR Tabelle 1: Fachlicher Umfang Konzernreporting x x Gesellschaftsreporting - x IDL DATAMART DW Schnittstelle On Demand Immer Verfügbar OLAP Cubes Individuelles BI Projekt Out of the box, mit Übersetzungen, Zeitliche Intelligenz. Customizing möglich. Hier eine Liste von nicht unterstützten IDL.KONSIS Berichten bzw. Funktionalitäten: UKV (Umsatzkostenverfahren)-Berichte (ab 2016 möglich) Segment-Berichte IN/EX Speicher Berechnungslogik 1.9 Mehrsprachigkeit Views Die IDL DATAMART-Views liefern die Bezeichnungen der in MISPAR gewählten Sprachen SSAS-Modell Das SSAS-Model (Dimensionsnamen) ist auf Englisch angelegt. Die Mehrsprachigkeit wird über Attribute gepflegt. Standardmäßig sind Deutsch und Französisch gepflegt. Für weitere Sprachen müssen neue zusätzliche Attribute angelegt werden Reihenfolge Die Reihenfolge der angelegten Attribute funktioniert richtig, wenn DEU als erste, ENG als zweite und FRA als dritte Sprache in der MISPAR ausgewählt ist, wie in der Abbildung 3 zu sehen ist. 10 IDL GmbH Mitte

11 1.10 Software-Voraussetzungen Tabelle 2: Software Voraussetzungen für 2014 Update 3 Produkt Version SQL Server (mit Analysis Services) ab 2008R2 Standard Edition IDL.KONSIS.FORECAST A 2 Prozess Folgende Schritte müssen erfolgen, um IDL DATAMART zur Verfügung zu stellen: 2.1 IDL.KONSIS-Schritte MISPAR-Parametrisierung Eine aktive MISPAR-Parametrisierung ist notwendig für IDL DATAMART. Ohne einen aktiven Datensatz liefern die Views keine Daten. Aus Performance-Gründen sollte die Auswahl der Parameter die bereitgestellte Datenmenge so weit wie möglich begrenzen. Die Parametrisierung erfolgt auf die gleiche Weise wie bislang in der MISPAR: Datenart Konzernstruktur Datenperiode Reports (Kontenstrukturen) Bei DataMart muss die Version (04) DataMart ausgewählt sein, wie in Abbildung 3 zu sehen ist. Die MISPAR-Parameter können entweder in der MISPAR-Anwendung oder (ab 2014.A) im IDL PORTAL gepflegt werden. IDL GmbH Mitte 11

12 Abbildung 3: MISPAR-Parameter Version (04) DataMart OLAP-Zuordnungen IDL DATAMART stellt die in MISPAR gewählten Kontenstrukturen (Reports) zur Verfügung. Dabei müssen die OLAP-Zuordnungen der Report-Positionen gepflegt sein (Anwendung REPZEI oder REPDEF). Positionen ohne OLAP-Zuordnung werden nicht berücksichtigt Normale vs. OLAP-Zuordnungen Wie man in Abbildung 4 sehen kann, sind die normalen und die OLAP-Zuordnungen nicht identisch. Die normalen Zuordnungen betreffen nur die IDL.KONSIS-Berichte, wobei die OLAP-Zuordnungen nur die IDL DATAMART-Strukturen. Abbildung 4: Normale vs. OLAP-Zuordnungen 12 IDL GmbH Mitte

13 Standard-Generierung der OLAP-Zuordnungen in der Anwendung REPDEF Um die Generierung der OLAP-Zuordnungen zu beschleunigen, wurde mit eine neue Funktion Standardzuordnung setzen eingeführt (siehe Abbildung 5). Diese Funktion pflegt die OLAP-Zuordnungen nach einer gewissen Logik. Die mit der neuen Funktion Standardzuordnungen setzen erzeugte OLAP-Zuordnungen können im Anschluss manuell angepasst werden. Abbildung 5: Standard OLAP-Zuordnungen Logik der OLAP-Zuordnungen Die OLAP-Zuordnungen steuern, ob und wie die Reportzeilen (Positionen) in IDL DATAMART berücksichtigt werden. Dabei gilt folgendes: Standardmäßig erscheint der Name des Reports als Top Level-Knoten (siehe BS oder KREDIT oder PL). Das geschieht unabhängig von den OLAP-Zuordnungen. Wenn die OLAP-Zuordnung fehlt, dann wird die Position ignoriert (z.b. die Position HANDELSBILANZ oder die Position Summe Immaterielle Vermögensgegenstände ). Wenn die OLAP-Zuordnung der Position gleicht (z.b. AKTIVA), dann wird daraus ein Kind des Top Level-Elements. Ansonsten gilt eine klassische Parent/Child-Beziehung. IDL GmbH Mitte 13

14 Abbildung 6: OLAP-Kontenstruktur Konzernstrukturen und Datenarten Die Konzernstrukturen müssen in IDL.KONSIS gepflegt sein (Anwendung KTKGES). Wenn die Konzernstruktur für eine Periode/Datenart fehlt, dann werden die Daten dieser Periode ignoriert, es sei denn die Ex-Datenart ist gepflegt. Wenn eine Ex-Datenart gepflegt ist (Anwendung FAC), wird die Konzernstruktur der Ex-Datenart und nicht der Datenart relevant. In dem Beispiel der Abbildung 7 ist für I2 keine Ex-Datenart gepflegt, deswegen wird die Kostenstruktur der Datenart I2 relevant. Für I3 dagegen wird die Kontenstruktur der Datenart I4 relevant. I3 Daten werden berücksichtigt auch wenn keine I3 Struktur vorhanden ist, weil die Ex- Datenart führend ist. 14 IDL GmbH Mitte

15 Abbildung 7: Datenarten 2.2 IDL Workplace Server Schritte Die folgenden Schritte sind notwendig, um eine automatische Generierung von IDL DATAMART im Portal anzustoßen IDL.KONSIS-Verbindung im IDL Portal Wie in Abbildung 8 zu sehen ist, muss im IDL Portal eine IDL.KONSIS-Verbindung eingerichtet werden. IDL GmbH Mitte 15

16 Abbildung 8: IDL.KONSIS-Verbindung im IDL Portal Bereitstellung im IDL Portal Nachdem die IDL.KONSIS-Verbindung angelegt wurde, kann man die Bereitstellung anstoßen (siehe Abbildung 9). Nach einer erfolgreichen Bereitstellung steht das IDL DATAMART SSAS- Modell zur Verfügung. Abbildung 9: Bereitstellung im IDL Portal 16 IDL GmbH Mitte

17 2.3 Berechnungen und Rules Berechnete Elemente wie z.b. eine Summe, werden bei SSAS über MDX Rules abgebildet. Normalerweise wird für die Bilanz der Bilanzgewinn über ein MDX-Rule berechnet. 2.4 Bereitstellung ohne IDL Workplace Server Für PoC (Proof of Concept) Zwecke kann man IDL DATAMART auch ohne den IDL Workplace Server bereitstellen und mit einem beliebigen Frontend (z.b. Excel) zugreifen. In so einem Fall ist die XMLA Beschreibung (DATAMART.xmla) von IDL DATAMART notwendig. Die XMLA Beschreibung ist auf Anfrage verfügbar. Folgendes muss dabei berücksichtigt werden: IDL DATAMART ist kein Standalone-Produkt. Die Release-Sicherheit kann nur über den IDL Workplace Server sichergestellt werden. Bei der Bereitstellung über den IDL Workplace Server wird das SSAS Model anhand der IDL.KONSIS Daten angepasst: z.b.: Wenn keine Geschäftsbereiche gepflegt sind, wird die Dimension entfernt. Das gleiche gilt für Controlling Dimensionen. Ohne IDL Workplace Server müssen solche Schritte manuell erfolgen. 3 Dimensionen 3.1 Kontenstruktur Die Dimension Kontenstruktur enthält sämtliche Kontenstrukturen. Die obersten Knoten der Dimension sind die Report-Namen. Der Reportname wird immer als Präfix verwendet. Somit können Konten in mehreren Reports (Strukturen) enthalten sein. Die Eindeutigkeit wird über das Präfix sichergestellt. Innerhalb eines Reports kann eine Position mehrmals vorkommen. Das wird über ein Suffix sichergestellt (Suffix ist die Zeilennummer). Wechselkonten bekommen ein weiteres Suffix (_S/_H für Soll/Haben). Davon Positionen werden berücksichtigt. Alle Konten (unabhängig vom Kontenplan) die einer (P) Position zugeordnet sind, werden berücksichtigt Wechselkonten Wechselkonten werden als 2 separate physische Elemente mit entsprechendem Suffix angelegt. Beispiel: Das Konto (Vorsteuer) erscheint einmal als IFRSBG_KON _S in den AKTIVA und einmal als IFRSBG_KON _H in den PASSIVA. Die Views sorgen dafür, dass die Daten in den richtigen Elementen landen (Soll/Haben Steuerung). IDL GmbH Mitte 17

18 3.1.2 Berechnungen Positionen vom Zeilen-Typ E werden nicht automatisiert in OLAP-Berechnungen übersetzt. Sie müssen manuell im OLAP Modell mittels MDX-Rules nachgepflegt werden Standard Sets Die Standard Report-Sets vereinfachen und beschleunigen den Aufbau von Bilanz- und GuV- Berichten. Eine aufbereitete Bilanz- und GuV Struktur kann per Drag & Drop in die Zeilen einer Tabelle gezogen werden. 3.2 Konzern Definition Die Dimension Konzern ist eine Parent/Child-Dimension und liefert die Konzernstruktur der in MISPAR gewählten Konzernperiode/Datenart. Die Daten werden von der View OLAP_DIM_GroupID bereitgestellt Historisierung Die View OLAP_DIM_GroupID_Company liefert eine Historisierung der Konzernstruktur aus dem Zeitraum, der in MISPAR angegeben ist, d.h. wenn in der MISPAR 2 Monate und 2 Datenarten gewählt sind, dann ergeben sich 4 Konzernstrukturen. Die Historisierung der Konzernstruktur ist im OLAP-Modell implizit berücksichtigt: Für jede Datenart und Periode werden die Daten der jeweils relevanten Gesellschaften (nach KTKGES) importiert. Im OLAP-Modell gibt es 2 Dimensionen: die Dimension Konzern (Parent/Child) und die Dimension Gesellschaft (flache Liste). Änderungen in Bezug auf Teilkonzerne werden allerdings nicht berücksichtigt, z.b. wenn ein Teilkonzern nur in der Vergangenheit relevant war. Im OLAP-Modell wird die Konzernstruktur der in der MISPAR gewählten Periode/Datenart gebaut Reporttechnische Konzerne Reporttechnische Konzerne werden unterstützt. 3.3 Gesellschaft Die Dimension Gesellschaft ist eine flache Liste der in IDL.KONSIS definierten Gesellschaften. 18 IDL GmbH Mitte

19 3.4 IC-Gesellschaft Die IC-Gesellschaft ist technisch identisch mit der Gesellschaft. Sie wird verwendet, um die Aufrisse der Kontensalden nach IC-Gesellschaften abzubilden. 3.5 Datenart Die Dimension Datenart ist eine flache Liste der in MISPAR gewählten Datenarten. 3.6 Aufriss Die Dimension Aufriss ist eine vordefinierte Dimension mit den folgenden Elementen: Tabelle 3: Die Aufriss Dimension ID Element 1 Ohne Aufriss 2 Controlling Aufriss 3 IC Aufriss Die Dimension Aufriss vereinheitlicht Daten und Aufrisse. Wenn die Aufrisse nicht relevant sind, wird standardmäßig Element 1 verwendet. 3.7 Konsolidierungsart Die Dimension Konsolidierungsart ist eine flache Liste der Konsolidierungsarten mit den folgenden Elementen: ID Tabelle 4: Die Konsolidierungsart Dimension Element 1 At-Equity 2 Keine Einbeziehung/nur Anteilsbesitz 3 Quotenkonsolidierung 4 Vollkonsolidierung 3.8 Konsolidierungsverarbeitung Die Dimension Konsolidierungsverarbeitung enthält 2 Hierarchien: Hierarchie Referenz Hierarchie Bericht IDL GmbH Mitte 19

20 3.9 Spiegel Die Dimension Spiegel enthält sämtliche Spiegel-Informationen Währung Die Dimension Währung enthält sämtliche Währungen. Es werden Konzernwährung, Landeswährung und Parallelwährung unterstützt Geschäftsbereich Geschäftsbereiche werden, sofern vorhanden, berücksichtigt. Die Dimension Geschäftsbereich ist eine Parent-Child Hierarchie, weil sie die in der UBRUBR definierten Hierarchien berücksichtigt Zeit Die Zeit ist eine vordefinierte Dimension. Die Anforderungen in Bezug auf die Zeitlogik sind bei den meisten BI-Projekten leicht unterschiedlich. Deswegen kann die Dimension Zeit (wie alle andere Dimensionen) individuell angepasst werden. Dabei muss beachtet werden, dass die MDX-Skripte ggf. angepasst werden müssen (siehe Kapitel 7) Jahresabschluss Abweichendes Geschäftsjahr Die IDL.KONSIS-Tabelle OLAP_DW_Fiscal enthält den letzten Monat des Jahres (Abschlussmonat). Der Standardwert ist 12. Im Falle eines vom Kalenderjahr abweichenden Geschäftsjahres muss dieser Wert angepasst werden, damit die Zeitlogik (z.b. Dekumulierung) funktioniert. Wenn z.b. der Juni (6) als Abschlussmonat gewählt ist,sieht die Zeit Dimension folgendermaßen aus: 2014 Q Q IDL GmbH Mitte

21 Q Q Monat Hierarchie Neben der Haupthierarchie Periode, gibt es die Hierarchie Monat. Somit ist es möglich die Jahre und Monate in den Zeilen und Spalten einer Tabelle gegenüberzustellen Zeitart Die Dimension Zeitart ist eine vordefinierte Dimension. Tabelle 5: Die Zeitart Dimension ID Element 1 IST (Dekumuliert) 2 YTD / Kumuliert MDX Berechnung Letzte 12 Monate MDX Berechnung Durchschnitt MDX Berechnung Hochrechnung Die IDL DATAMART-Views liefern die Daten kumuliert und werden direkt auf das Element 2 geladen. Die Dekumulierung findet über MDX-Rules statt. Die Dekumulierung ist kontenübergreifend und somit für Bilanzkonten nicht sinnvoll. Im Finance Cube gibt es weitere Elemente in Bezug auf die Zeitart. Diese Elemente sind eher für GuV Zahlen relevant. Letzte 12 Monate: Kumulierte Wert der letzten 12 Monate Durchschnitt: Durchschnittswert je nachdem was in der Zeit Dimension gewählt ist (Jahr oder Quartal). IDL GmbH Mitte 21

22 Hochrechnung: Klassische Hochrechnung bis zum Abschlussmonat 3.14 Zeitvergleich Die Dimension Zeitvergleich ist eine vordefinierte Dimension, die eine generische, Cubeübergreifende Lösung zum Thema Vorperiodenvergleich bietet. Eine Periode kann ein Jahr, Quartal, Monat oder Tag sein, also der Vergleich ist für jedes Element der Zeit-Dimension möglich. Dadurch entfällt das dezidierte Anlegen von solchen Berechnungen für bestimmte Measures/Kennzahlen. Tabelle 6: Die Zeitvergleich Dimension ID Element Parent 1 Aktuelle Periode Abweichung zum Vorjahr 2 Vorjahr Abweichung zum Vorjahr 3 Abweichung Vorjahr in % Abweichung zum Vorjahr 101 Aktuelle Periode Abweichung zur Vorperiode 102 Vorperiode Abweichung zur Vorperiode 103 Abweichung zur Vorperiode in % Abweichung zur Vorperiode 3.15 Controlling-Dimensionen Views In IDL.KONSIS kann man bis zu 10 Controlling-Dimensionen anlegen. Die IDL DATAMART-Views enthalten je eine Spalte für alle 10 Controlling-Dimensionen, egal ob sie gepflegt sind oder nicht SSAS-Modell Im standardmäßig generierten OLAP-Modell werden die ersten 3 Controlling-Dimensionen unterstützt. Weitere können manuell angelegt werden Visualisierung Für Controlling Aufrisse im Finance Cube muss das Element Controlling DetailDegree (Aufriss) ausgewählt werden (das Default Element ist Ohne ). in der Dimension 22 IDL GmbH Mitte

23 4 Measure Groups und Cubes 4.1 Finance Cube Das SSAS-Model enthält einen Cube namens Finance, der mehrere Measure Groups (MG) enthält. Prinzipiell gibt es wie in IDL.KONSIS eine Unterscheidung zwischen Konzern- und Gesellschaftsreporting. Abbildung 10: Datenfluss der relevanten Views für Salden Abbildung 11: Datenfluss der relevanten Views für Buchungen/Spiegel Konzernreporting Im Konzernreporting werden nur die Gesellschaften des Konsolidierungskreises einbezogen. Dabei ist die Konsolidierungsart (Vollkonsolidierung, Quotenkonsolidierung, Equity-Konsolidierung) entscheidend. IDL GmbH Mitte 23

24 Tabelle 7: Quelle für Konzernreports MG View/Quelle Begrenzung Konzernabschluss OLAP_FactB CalcedValueQuota IS NOT NULL Konzernabschluss Buchungen Konzernabschluss Spiegel OLAP_FactPG OLAP_Fact_TransactionDev elop * Gesellschaftsreporting Im Gesellschaftsreporting werden sämtliche Gesellschaften einbezogen, unabhängig von der Konsolidierungsart. Beteiligungsverhältnisse sind nicht relevant. Tabelle 8: Quelle für Gesellschaftsreports MG View/Quelle Begrenzung Einzelabschluss OLAP_FactB CalcedValue IS NOT NULL Einzelabschluss - Buchungen OLAP_FactPC Einzelabschluss - Spiegel OLAP_Fact_TransactionDevelop * Beteiligung Die Measure Group Beteiligung bildet die Beteiligungsverhältnisse innerhalb eines Konzerns ab. Über das Measure Buchwert sind die Anteilsbesitzbewegungen abbildbar. 24 IDL GmbH Mitte

25 Abbildung 12: IDL.DESIGNER Beispiel mit Beteiligungen und Datenübersicht Datenübersicht Die MG Beteiligung visualisiert, ob Daten für eine bestimmte Kombination Datenart/Periode vorhanden sind. Daten sind vorhanden, wenn mindestens ein Kontensaldo vorhanden ist Granularität und Aufrisse (DrillThrough) IDL DATAMART enthält die Daten auf unterster Ebene, um Aufrisse von jeder Zelle zu ermöglichen. Die Aufrisse sind über vordefinierte SSAS DrillThrough-Aktionen möglich. 4.2 Rules und Berechnungen Der Finance Cube enthält MDX-Skripte (Rules), die für die Zeitlogik (Dekumulierung, Periodenvergleich) notwendig sind. 4.3 Bilanzgewinn Berechnete Elemente (KONSIS) werden nicht in DataMart unterstützt. Um den Bilanzgewinn zu berechnen gibt es 3 Alternativen: 1. Die Bilanzgewinn-Position muss als Zeilentyp/Wertkennzeichen S2 definiert sein (REPDEF oder REPZEI). Eine S2 Position wird als die Summe aller der Bilanz zugeordneten Konten mit BilGuV Kennzeichen 1 minus der Summe aller der Bilanz zugeordneten Konten mit BilGuV Kennzeichen 2 berechnet. IDL GmbH Mitte 25

26 2. Das E-Konto muss der Bilanzgewinn-Position zugeordnet sein. 3. Über eine individuelle MDX Rule, die den Bilanzgewinn kopiert. Die MDX Rules sind zwar vordefiniert, können allerdings erweitert werden, siehe Customizing. Es ist wichtig sich für nur eine der 3 Alternativen zu entscheiden. Eine gleichzeitige Verwendung von 2 oder 3 davon führt zur Problemen. Die automatische Bilanzgewinn-Berechnung für S2 Positionen wurde erweitert um den Fall abzudecken in dem alle Konten (auch die unter PASSIVA) mit dem Bil/GuV Kennzeichen "1" (statt 2 ) versehen sind. Wenn alle Konten (auch die unter PASSIVA) mit dem Bil/GuV Kennzeichen "1" (statt 2 ) versehen sind, funktioniert die S2 Berechnung trotzdem. Voraussetzung dafür ist das die unter PASSIVA Positionen mit dem Bil/GuV Kennzeichen "2" sind. 4.4 Kapitalflussrechnung (KFR) Cube Die KFR wird aus sowohl technischen als auch fachlichen Gründen separat behandelt. Berichte vom Typ F landen im KFR -Cube, alle andere im Finanzen -Cube. 5 Betrieb 5.1 Performance Die Performance von IDL DATAMART hängt von der Datenmenge, die in MISPAR eingestellt ist, ab. Je mehr Perioden, Datenarten und Reports gewählt sind, desto länger dauert der Prozess. 5.2 Inkrementelles Laden/Prozessieren Das inkrementelle Laden bzw. Prozessieren von IDL DATAMART Cubes ist nicht möglich. Beim Prozessieren werden die Cubes neu erstellt, d.h. es gibt nicht die Möglichkeit nur einen Teil (z.b. nur eine Periode) zu prozessieren und den Rest nicht. 5.3 Datenaktualisierung Wie in der Abbildung 9 zu sehen ist (Deploy-Knopf in der App-Bar), ist die manuelle Aktualisierung der Daten möglich. Für eine automatisierte Aktualisierung der Daten (Scheduling) muss ein entsprechender Job in SSMS angelegt werden (nicht Bestandteil des Standards). 26 IDL GmbH Mitte

27 5.4 Autorisierung IDL DATAMART zieht die in IDL.KONSIS definierten Datenberechtigungen (Anwendungen) und erstellt automatisch die entsprechenden Rollen im SSAS. In der Abbildung 13 sieht man die Rollen IDLADMIN, IDLEE und IDLKON. Abbildung 13: Datenberechtigungen (AS Rollen) im IDL Portal 6 Historisierung 6.1 Konzernstruktur Die Tabelle OLAP_DIM_GroupID_Company enthält die Konzernstruktur für jede Periode/Datenart, wie in beschrieben. 6.2 Daten IDL DATAMART basiert auf relationalen Views und liefert dementsprechend immer den aktuellen Datenstand. Um die Daten zu historisieren, muss ein Data Warehouse aufgebaut werden und die Historisierung der Daten individuell abgebildet werden. 7 Customizing 7.1 Customizing des SSAS-Modells Die Generierung der IDL DATAMART-Cubes ist standardisiert. Trotzdem gibt es die Möglichkeit, das Standard-Modell anzupassen oder zu erweitern, um kundenspezifische Anforderungen zu IDL GmbH Mitte 27

28 adressieren. Die (multidimensionale) Modelldefinition ist eine XMLA-Beschreibung. Im IDL Portal kann eine angepasste XMLA-Definition hochgeladen werden. Die Anpassung von IDL DATAMART ist nur mit Microsoft SSDT bzw. SSMS möglich. Eine Anpassung mit dem IDL.IMPORTER ist nicht möglich. Prozessschritte: 1. Die IDL DATAMART SSAS DB mit SSDT öffnen 2. Anpassungen durchführen 3. Die XMLA Definition der (angepassten) DB in SSMS erstellen 4. Diese im IDL Portal (im Administrationsbereich) hochladen 7.2 Komplett individuelle OLAP-Landschaft Alternativ kann man ein komplett individuelles multidimensionales Modell aufbauen. In diesem Fall gibt es keine Einschränkung in Bezug auf das ETL-Werkzeug oder die OLAP-Datenbank (d.h. es muss nicht SSAS sein), weil nur die relationalen Views von IDL DATAMART relevant sind. Die in IDL.KONSIS zur Verfügung stehenden Views können für den Aufbau des kundenindividuellen OLAP-Modells verwendet werden. 7.3 Release-Sicherheit (Updates) und Wartung IDL DATAMART wird als normale technische Komponente Produkt entwickelt und gewartet. Im Falle einer individuellen Anpassung entsteht eine klassische Projekt-Lösung und dementsprechend muss folgendes berücksichtigt werden: Keine Produkt-Wartung kann gewährleistet werden. Unterstützung in diesem Bereich ist im Rahmen klassischer Beratung möglich. IDL DATAMART ist ein relativ komplexes System. Anpassungen erfordern ein tiefes Verständnis diverser Vorgänge und werden in den meisten Fällen klassische Beratung erfordern. Man profitiert von der Weiterentwicklung von IDL DATAMART (neue Views/Cubes, Optimierungen) nicht (direkt) 8 FAQ Die Views liefern überhaupt keine Daten, was kann man tun? Siehe Kapitel 2. Sind alle notwendigen Schritte erfolgt? In der Kontenstruktur fehlen Positionen, was kann man tun? Sind die OLAP-Zuordnungen in der REPZEI/REPDEF gepflegt? Der Cube enthält Daten, aber nicht für alle Perioden oder Datenarten. Siehe Kapitel Sind alle notwendigen Schritte erfolgt? Wo finde ich die Controlling-Aufrisse? Siehe Kapitel IDL GmbH Mitte