none
Analysis Services: GuV als Cube RRS feed

  • Frage

  • Hi Forum,

    lässt sich eine GuV (Gewinn und Verlustrechnung) als Cube darstellen?

    Normalerweise bildet man ja über eine Hierarchie Aggregationen, die pro Measure einheitlich ist.

    In einer GuV haben ich beispielhaft die nachstehende Struktur

      Konto A
      Konto B
      Konto C
    Umsatz (Summe Konto A,C)
      Konto D
      Konto D1
    Sonstige Erträge (Summe Konto D,D1 + Umsatz)
    Gesamtleistung (Umsatz + Sonstige Erträge)
      -Konto E
      -Konto F
    DB1 (Summe Konto E,F)
      -Konto G
      -Konto H
    DB2 (Summe Konto G,H + DB1)
      Konto I
      Konto I2
    Personalaufwand (Summe Konto I,I2)
      Konto J
      Konto J1
    Sonstiger Aufwand (Summe Konto J,J1)
    Ergebnis vor Abschreibung (DB2 + Personalaufwand + Sonstiger Aufwand)

    Lässt sich so etwas abbilden. Das Problem ist ja auch, dass in der ersten Aggregationsebene mal nur Summen der Konten gebildet werden (zB. DB1) und mal zu dieser Summe noch eine oder mehrere andere Blöcke addiert werden zB DB2)

    Alex

    Donnerstag, 19. Juli 2012 11:33

Antworten

  • Hallo Alex,

    eine Cube baut man normalerweise gemäß dem Datenmodell auf, also hier nach Konten / Zeit / Umsatzzahlen, um später die Anforderungn (Fragen) erfüllen zu können; wie es später im Frontend dargestellt werden soll, ist da eher zweitrangig.

    Oder anders formuliert: Mit einer MDX Abfrage wirst Du das Ergebnis so ohne weiteres nicht erhalten.

    Man würde hier eher einen Bericht als Frontend verwenden, der die einzelnen Werte aus dem Cube abfragt und dann entsprechend grafisch aufgebaut anzeigt.
    Zudem gibt es neben der GuV meistens auch noch weitere individuelle BWA's und Bilanzen, die alle eigentlich auf den gleichen Daten (Cube) basieren, aber immer einen anderen Aufbau haben; das kann man eben über unterschiedlich aufgebaute Reports statt unterschiedlichen Cube umsetzen.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Donnerstag, 19. Juli 2012 15:30
  • Hallo Alex,

    hast Du den AdventureWorks Cube, um das Beispiel nachzuvollziehen? Wenn nicht, das gibt es bei http://www.codeplex.com

    Hier habe ich mal als Beispiel Produkte genommen; betrachte sie einfach als "Sachkonten". Über die With Set Anweisung habe ich zunächst zusammen gehörende Produkte definiert; quasi die Konten einer GuV Position. Zu jeden dieser Named Sets habe ich dann noch mit der With Member Anweisung mit einer Aggregation hinzugefügt; diese werden dann in der MDX Abfrage für die Summenpositionen verwendet.

    In der Select Anweisung selektiere ich dann erst die Sets, um die Einzelwerte zu erhalten und im Anschluß dann eben die Members für die Gruppensumme.

    WITH 
        SET [Set Prod A] AS {[Product].[Product].&[486] : [Product].[Product].&[225]}
        SET [Set Prod C] AS {[Product].[Product].&[447] : [Product].[Product].&[471]}
        MEMBER [Product].[Product].[Sum Prod A] AS 
               AGGREGATE([Set Prod A], [Measures].CURRENTMEMBER)
        MEMBER [Product].[Product].[Sum Prod C] AS 
               AGGREGATE([Set Prod C], [Measures].CURRENTMEMBER)
    SELECT
        {
            [Measures].[Internet Sales Amount]
        } ON  0,
        {
            [Set ProD A]
           ,[Product].[Product].[Sum Prod A]
           ,[Set ProD C]
           ,[Product].[Product].[Sum Prod C]       
        } ON 1
    FROM [Adventure Works]

    Es geht in einem bestimmten Rahmen schon, sich einen GuV Ähnlichen Aufbau zu erstellen, aber in MS Excel würde es so erst mal nicht gehen.

    Du könntest noch mit m:n Beziehungen experimentieren, also das Du ein Konto mehrere Positionen (der Einzelposition und der Zwischensumme) zuordnen kannst.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing


    Montag, 30. Juli 2012 10:40

Alle Antworten

  • Hallo Alex,

    eine Cube baut man normalerweise gemäß dem Datenmodell auf, also hier nach Konten / Zeit / Umsatzzahlen, um später die Anforderungn (Fragen) erfüllen zu können; wie es später im Frontend dargestellt werden soll, ist da eher zweitrangig.

    Oder anders formuliert: Mit einer MDX Abfrage wirst Du das Ergebnis so ohne weiteres nicht erhalten.

    Man würde hier eher einen Bericht als Frontend verwenden, der die einzelnen Werte aus dem Cube abfragt und dann entsprechend grafisch aufgebaut anzeigt.
    Zudem gibt es neben der GuV meistens auch noch weitere individuelle BWA's und Bilanzen, die alle eigentlich auf den gleichen Daten (Cube) basieren, aber immer einen anderen Aufbau haben; das kann man eben über unterschiedlich aufgebaute Reports statt unterschiedlichen Cube umsetzen.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Donnerstag, 19. Juli 2012 15:30
  • Hallo Olaf,

    ich hab so eine Antwort schon befürchtet. Ziel in meinem Projekt ist nämlich auch die GUV über die verschiedensten Dimensionen herunterzubrechen. Da würde sich Excel als Frontend natürlich besser anbieten als ein Report, weil es flexibler ist.

    Wie sieht denn das "so ohne weiteres nicht erhalten" aus?

    Alex

    Freitag, 20. Juli 2012 10:22
  • Hallo Alex,

    hast Du den AdventureWorks Cube, um das Beispiel nachzuvollziehen? Wenn nicht, das gibt es bei http://www.codeplex.com

    Hier habe ich mal als Beispiel Produkte genommen; betrachte sie einfach als "Sachkonten". Über die With Set Anweisung habe ich zunächst zusammen gehörende Produkte definiert; quasi die Konten einer GuV Position. Zu jeden dieser Named Sets habe ich dann noch mit der With Member Anweisung mit einer Aggregation hinzugefügt; diese werden dann in der MDX Abfrage für die Summenpositionen verwendet.

    In der Select Anweisung selektiere ich dann erst die Sets, um die Einzelwerte zu erhalten und im Anschluß dann eben die Members für die Gruppensumme.

    WITH 
        SET [Set Prod A] AS {[Product].[Product].&[486] : [Product].[Product].&[225]}
        SET [Set Prod C] AS {[Product].[Product].&[447] : [Product].[Product].&[471]}
        MEMBER [Product].[Product].[Sum Prod A] AS 
               AGGREGATE([Set Prod A], [Measures].CURRENTMEMBER)
        MEMBER [Product].[Product].[Sum Prod C] AS 
               AGGREGATE([Set Prod C], [Measures].CURRENTMEMBER)
    SELECT
        {
            [Measures].[Internet Sales Amount]
        } ON  0,
        {
            [Set ProD A]
           ,[Product].[Product].[Sum Prod A]
           ,[Set ProD C]
           ,[Product].[Product].[Sum Prod C]       
        } ON 1
    FROM [Adventure Works]

    Es geht in einem bestimmten Rahmen schon, sich einen GuV Ähnlichen Aufbau zu erstellen, aber in MS Excel würde es so erst mal nicht gehen.

    Du könntest noch mit m:n Beziehungen experimentieren, also das Du ein Konto mehrere Positionen (der Einzelposition und der Zwischensumme) zuordnen kannst.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing


    Montag, 30. Juli 2012 10:40
  • Hallo Alex Vary,

    Ich gehe davon aus, dass die Antworten Dir weitergeholfen haben.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert


    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Dienstag, 14. August 2012 14:38
    Moderator