Kapitel 16

Integrierte Finanzplanung und Simulation

IN DIESEM KAPITEL

  • Ableitung der Bilanz aus GuV-Positionen
  • Aufbau einer integrierten Erfolgs- und Cashflow-Planung
  • Erfolgs- und Cashflow-Simulation

Für die Ist-Daten-Berechnung ist die Cashflow-Erzeugung in Kapitel 15 umgesetzt. Im Plan sieht es ein wenig anders aus. Ein paar Ausführungen zur grundsätzlichen Logik: Im Ist haben wir Bilanzpositionen übernommen. In der Planung werden viele Bilanzpositionen aber nicht geplant, sondern abgeleitet. So ergeben sich die Forderungen aus dem Umsatz und dem Zahlungsverhalten der Kunden. Genauso ist es mit den Verbindlichkeiten. Auch hier besteht eine Abhängigkeit zum eigenen Zahlungsverhalten. Wenn also Kunden insgesamt später zahlen, erhöhen sich die Forderungen. Deswegen ist die Kennzahl Forderungsreichweite oder DSO (Days Sales Outstanding) eine wichtige Grundlage für die Liquiditätsplanung.

Die Abhängigkeiten zwischen GuV, Bilanz und Finanzflussrechnung haben Sie jetzt umgesetzt, aber einige wichtige zahlungsrelevante Ableitungen wie

  • Entwicklung der Forderungen aus Umsätzen,
  • Entwicklung der Verbindlichkeiten aus Aufwendungen oder
  • Entwicklung der Steuerzahlungen aus Steuerverbindlichkeiten

müssen wir noch erläutern. Eine integrierte Erfolgs- und Finanzplanung kann auch noch weitere Positionen, wie Rückstellungen oder Anzahlungen, berücksichtigen.

Jede Ableitung, die durch eine Formel ersetzt werden kann, verringert Ihren Eingabeaufwand, vermeidet Inkonsistenzen und zeitaufwendige Abstimmungsarbeiten zwischen GuV, Bilanz und Cashflow.

An dieser Stelle wollen wir exemplarisch die Ableitung der Forderungen aus den Umsätzen darstellen. Diesen Ansatz können Sie ganz einfach auf andere Ableitungen, wie die Entwicklung der Verbindlichkeiten aus Aufwendungen, übertragen.

Dass Zahlungen häufig deutlich später als der dazugehörige Erfolgsstrom auftreten, erleben Sie täglich. Einer Ihrer Kunden zahlt beispielsweise erst 30 oder gar 60 Tage nach Erhalt der Rechnung. Ein sinnvoller Weg, aus Erfolgspositionen Zahlungspositionen zu generieren, ist die Verwendung von Verzögerungsfaktoren (sogenannten Geldwerdungsfaktoren) zwischen Erfolgs- und Zahlungsvorgang. Dabei werden einzelne Aufwands- und Ertragspositionen danach analysiert, wie viel Zeit vergeht, bis nach dem Erfolgsereignis ein Zahlungsstrom eintritt. Diese Zeitdifferenz können Sie auf zwei Wegen ermitteln:

  • durch Schätzen oder
  • durch statistische Betrachtungen von Daten aus Abrechnungssystemen.

Häufig verwendet man auch nur den DSO (Days of Sales Outstanding oder auf Deutsch Forderungsreichweite). Allerdings sind DSOs zum Teil eine zu starke Vereinfachung. Kunden gehen beispielsweise in Vorleistung und zahlen nach 15, 30, 45 oder mehr Tagen. Und beim Verkauf eines Produkts fällt in der Regel eine Mehrwertsteuerbelastung an. Das alles muss sich in der Bilanz niederschlagen.

Ein Beispiel: Da das Firmenkonto ständig leer ist, obwohl sich sein Unternehmen vor Aufträgen kaum retten kann, analysiert der Controller das Zahlungsverhalten seiner Kunden. Das Ergebnis:

  • 10 Prozent der Kunden zahlten noch im gleichen Monat.
  • 50 Prozent zahlten nach einem Monat.
  • 40 Prozent zahlten nach zwei Monaten.

Wenn der (geplante) Umsatz

  • im Mai 1 Mio
  • im Juni 1,2 Mio
  • im Juli 1,4 Mio

beträgt, ist der Zahlungseingang im Juli

  • 1,0 Mio * 0,4 + 1,2 * 0,5 + 1,4 Mio * 0,1 = 1,14 Mio, also niedriger als der Umsatz.

Genauso können wir die Forderungsveränderung berechnen, wenn wir den Anfangsbestand im Juli haben (3 Mio):

  • AB 3,0 Mio
  • Zugang 1,4 Mio
  • Abgang (durch Zahlung) 1,14
  • Endbestand 3,0 + 1,4 – 1,14 = 3,26

Der Forderungsbestand hat sich also erhöht. Nicht wirklich überraschend. Man muss sich vor Augen führen, dass in Wachstumsmärkten die Zahlungen den Umsätzen meistens hinterherlaufen.

Es ist zusätzlich auch die Mehrwertsteuer zu berücksichtigen. In der GuV arbeitet man üblicherweise netto, da die Mehrwertsteuer nur ein durchlaufender Posten ist.

Für unser Beispiel bedeutet dies, dass alle Beträge um 19 % höher sind. Der Zugang im Juli ist also nicht 1,4 Mio, sondern 1,4 Mio * 1,19. Der Abgang ist auch nicht 1,14, sondern 1,14 Mio * 1,19.

Dieser Ansatz muss konsequent für alle relevanten Bilanzpositionen umgesetzt werden. Bei nicht allen Bilanzpositionen ist es so einfach zu verstehen.

Wie ist es mit Anzahlungen? Auch diese müssen berücksichtigt werden. Anzahlungen von Kunden erscheinen auf der Passivseite. Hier gilt die gleiche Regel, nur dass eine Rückzahlung nicht erfolgt, sondern automatisch mit Rechnungserstellung aufgelöst wird.

Die Konteneigenschaften decken diese Regeln ab.

Modellerweiterungen

  1. Öffnen Sie das Modell ERFI und öffnen Sie den Editor für die Account-Dimension.

Da viele Eigenschaften definiert sind, ist die Tabelle recht breit. Beim Scrollen nach rechts verschwinden die Kontenbezeichnungen. Das lässt sich aber leicht verhindern. Fixieren Sie einfach die Spalte Beschreibung.

  1. Klicken Sie dazu auf den Spaltenkopf (allerdings nicht auf das Sortiersymbol) und klicken Sie anschließend auf die Nadel (Abbildung 16.2).
  2. Scrollen Sie nun nach rechts und sehen Sie sich das Konto B1310 an, Forderungen aus Lieferungen und Leistungen (Abbildung 16.3).

Das Cash-Referenzkonto ist T1100. Das Konto T1100 nimmt die Umsatzerlöse auf. T steht für temporär. Warum ist das notwendig? Die Umsätze errechnen sich durch die Multiplikation von Menge (Konto M3000) und Preis (Konto M2110). Allerdings ist diese Multiplikation als Kontenformel für M1100 Bruttoumsatz hinterlegt, das wieder über eine Verdichtung und Formel von der GuV-Position P1111 Umsatz gezogen wird. Nun können die erweiterten Formen in Datenaktionen nicht auf die Formelergebnisse zugreifen. Dies bedeutet, dass die Cashflow-Berechnung auch die Mengen-Preis-Multiplikation durchführen muss. Dieser Umsatzwert wird im Konto T1100 gespeichert.

Abbildung 16.2: Fixieren der Beschreibungsspalte

Abbildung 16.3: Cashflow-Berechnung über Attribute

Das Attrubut »Bilanzverarbeitung« (Abbildung 16.4) steuert die relevanten Datenaktionen (nächster Abschnitt). Es gibt spezielle Verarbeitungen für

  • BP (Balance Sheet Processing) für die Ermittlung von Forderungen, Verbindlichkeiten und so weiter aus den GuV-Vorgängen wie Umsatz und Kosten
  • PP (Prepayment) für mögliche Anzahlungen aus den gleichen Geschäftsvorgängen
  • TP (Tax Processing) für die Mehrwertsteuerberechnung aus Umsatz und Kosten

Abbildung 16.4: Konfiguration der Bilanzverarbeitung

Wir brauchen nun noch Liquiditätsfaktoren (siehe die Ausführungen am Anfang dieses Kapitels). Diese spiegeln das Zahlungsverhalten wider. Kunden erhalten eine Rechnung, zahlen aber häufig nicht sofort. Einige zahlen erst nach einem Monat, einige nach zwei Monaten und so weiter. Dies ist vergleichbar mit der sogenannten Forderungsreichweite (DSO), diese mittelt aber das gesamte Zahlungsverhalten. Die Angabe von Prozentwerten pro Monat ist differenzierter.

  1. Öffnen Sie Ihren Bericht aus Kapitel 15 im Bearbeitungsmodus und duplizieren Sie den GuV-Ist-Bericht (Abbildung 16.5).

    Abbildung 16.5: Duplizieren des GuV-Berichts

  2. Benennen Sie die neue Seite in Liquiditätsfaktoren um (Abbildung 16.6).

    Abbildung 16.6: Umbenennen der Seite

  3. Ändern Sie die Kontenhierarchie der Tabelle (über den Designer im Bereich Builder) zu Bilanzverarbeitung und wählen Sie Verarbeitung der Bilanz aus (Abbildung 16.7).

    Abbildung 16.7: Ändern der Hierarchie

  4. Ändern Sie die Datumsauswahl zu Dec (2025).

    Dies ist von uns als Speicherort für Parameter gewählt worden, die über mehrere Perioden gültig sind. Eigentlich kann jede Periode hierfür gewählt werden. Es sollte nur sichergestellt werden, dass diese Werte nicht versehentlich in andere Kalkulationen einfließen.

  5. Wählen Sie noch die Dimension Sonstiges als Spaltendimension aus (Abbildung 16.8).
  6. Um sicherzugehen, dass sich die Anteilswerte auf 1 addieren, können Sie auch gerne eine Spaltensumme angeben (Abbildung 16.9).

    Abbildung 16.8: Auswahl der Dimension »Sonstiges«

    Abbildung 16.9: Erstellen einer Summenspalte

    Was Sie hier sehen, sind die Liquiditätsfaktoren. Nehmen Sie beispielsweise das Konto »Forderungen aus Lieferungen und Leistungen«, das über Umsätze gefüllt wird. Hier gilt

    • 10 % der Kunden zahlen sofort (S + 0),
    • 50 % der Kunden zahlen nach einem Monat (S + 1) und
    • 30 % der Kunden zahlen nach zwei Monaten (S + 2).

    Das sind allerdings nur 90 %. Was ist mit dem Rest? Hier wird die Annahme getroffen, dass Kunden im Schnitt 10 % Anzahlungen einen Monat vor Fakturierung leisten (S – 1).

Kalkulation

  1. Erstellen Sie eine Datenaktion und nennen Sie sie ERFI Planintegration. Und vergessen Sie nicht das Speichern (Abbildung 16.10).

    Abbildung 16.10: Datenaktion »ERFI Planintegration«

  2. Erstellen Sie zwei Parameter für Start und Ende der Kalkulation (Startperiode und Endperiode). Damit können Sie die Cashflow-Berechnung zu einer ausgewählten Periode starten.
  3. Füllen Sie die Felder wie abgebildet aus (Abbildung 16.11). Speichern Sie die Datenaktion.

    Abbildung 16.11: Parameterkonfiguration

  4. Erstellen Sie noch einen zweiten Parameter Endperiode durch Kopieren von Startperiode. Überschreiben Sie ID und Name für Eingabeaufforderung.

Das Ergebnis sollte wie in Abbildung 16.12 aussehen.

Abbildung 16.12: Parameter für Start und Ende

  1. Erstellen Sie nun 9 Kalkulationsschritte. Alle Module sind Skripts. Klicken Sie also jeweils auf das rechte Icon (Abbildung 16.13) und wählen Sie die Bezeichnungen wie in der Abbildung. Bei den Bezeichnungen kommt es nicht auf letzte Genauigkeit an.

    Abbildung 16.13: Kalkulationsschritte

  2. Klicken Sie auf BASISBERECHNUNG und auf SKRIPT und löschen Sie den Standardinhalt (Abbildung 16.14).

    Abbildung 16.14: Generischer Code

Es erfolgt eine Erläuterung der Kalkulationen. Diese ist relativ umfangreich, aber eine integrierte Erfolgs- und Finanzplanung ist ja auch kein triviales Beispiel.

Im Folgenden ist einiger Code abzutippen. Wir haben Ihnen aber den Code in der Datei SACFuerDummiesKap16Scripting.txt bereitgestellt.

Basisberechnung

Der erste Schritt betrifft die Kalkulation von Deckungsbeitragspositionen, die dynamisch über Formeln errechnet werden. Dieser Schritt ist notwendig, um berechnete Werte für die Zielkonten (Nettoumsatz und Produktionskosten) zu erhalten. Die Werte der kalkulierten Konten können nicht im Scripting verwendet werden. Nettoumsatz und Produktionskosten werden durch einfache Multiplikation berechnet.

Hierzu wird eine einfache Kombination aus DATA() und RESULTLOOKUP() verwendet. Weitere Dimensionen werden nicht verwendet. DATA() schreibt die Werte in die Faktentabelle. RESULTLOOKUP() liest die notwendigen Werte aus.

Die Ausführung wird über MEMBERSET() auf die Kennzahl Wert eingeschränkt.

Zwei zusätzliche Konten »T1100 Nettoumsatz« und »T1200 Produktionskosten« werden mit den Ergebnissen der Berechnungen gefüllt. Aus den Stückwerten und der abgesetzten Mengen können diese berechnet werden.

MEMBERSET [d/Measures] = "Wert"
// Berechnung des Nettoumsatzes und der Produktionskosten

DATA([d/Konto]= "T1100") = // Nettoumsatz
(-1) * (RESULTLOOKUP([d/Konto]="M2110") // Preis
- RESULTLOOKUP([d/Konto]="M2120")) // Rabatt pro Stück
* RESULTLOOKUP([d/Konto]="M3000") // Menge

DATA([d/Konto]= "T1200") = // Produktionskosten
RESULTLOOKUP([d/Konto]="M2200" ) // Produktionskosten pro Stück
* RESULTLOOKUP([d/Konto]="M3000") // Menge

Warum erfolgt eine Vorzeichenumkehr beim Nettoumsatz T1100? Der Preis steht zwar negativ im Datenbestand, wird aber positiv zurückgeliefert, wie er auch in Stories dargestellt wird.

Obwohl Sie in manchen Stellen im Editor die Bezeichnung sehen, werden im Skript ausschließlich IDs verwendet. Dies erhöht die Lesbarkeit nicht gerade, es sei denn, Sie haben ein besonderes Verhältnis zu Kontonummern, was so manchem Buchhalter nachgesagt wird.

Bilanzableitung

Einige der Bilanzpositionen sind ursprünglich nicht geplant, sondern aus den Gewinn-und-Verlust-Rechnungen abgeleitet. Zum Beispiel die Forderungen. Der Forderungsbestand ermittelt sich aufgrund von Umsätzen. Steigt der Umsatz, steigen auch die Forderungen in einem ähnlichen Verhältnis.

Nun erfolgt die eigentliche Bilanzableitung dieser Konten. Das ist auch das umfangreichste Skript. Es erfolgt eine Einschränkung über alle Konten, die in der Hierarchie BP zugeordnet sind. Wichtig ist, dass Sie die Hierarchie zur Verarbeitung der Bilanz mit CONFIG.HIERARCHY auswählen.

Umsätze und Kosten werden pro Produkt ermittelt. Allerdings wird eine GuV in der Regel nicht für einzelne Produkte erstellt (und eine Bilanz schon gar nicht). Deswegen ist es sinnvoll, die Produktdimension zu verdichten und die Ergebnisse auf das unspezifizierte Element »#« zu schreiben. Das wird mit dem Befehlspaar AGGREGATE_DIMENSIONS und AGGREGATE_WRITETO erreicht.

MEMBERSET [d/Date] = %Startperiode% TO %Endperiode%
MEMBERSET [d/Konto].[p/BP] = "BP"
AGGREGATE_DIMENSIONS = [d/Produkt]
AGGREGATE_WRITETO [d/Produkt] = "#"

Der Zugang ermittelt sich aus dem GuV-Konto (beispielsweise Umsatzerlöse) abzüglich der Anzahlungen, multipliziert mit der Mehrwertsteuer. Der Zugang wird für alle Konten, die dem Hierarchieknoten »BP« zugeordnet sind, ausgeführt. Hier sind insbesondere Forderungen aus Lieferungen und Leistungen (B1310) und Verbindlichkeiten aus Lieferungen und Leistungen zugeordnet.

Den Mehrwertsteuersatz erhalten Sie über das Attribut [d/Konto].[p/VAT]. Im Forderungskonto (B1310) sind beispielsweise 19 % eingetragen.

Über [d/Konto]/[p/CR] erhalten Sie den Wert des im Attribut eingetragenen Kontos. Bei Forderungen aus Lieferungen und Leistungen ist es in der Regel das Umsatzkonto, das über T1100 ermittelt wurde.

Und schließlich müssen mögliche Anzahlungen abgezogen werden. Hier greifen Sie zum ersten Mal auf die Liquiditätsfaktoren zu, die in der Periode 202512 in der Version »Actual« gespeichert worden sind. Da wir diese Faktoren nicht landesspezifisch abgelegt haben, muss die Region auf das generische Element »#« fixiert werden. Für die Produkte ist das nicht notwendig, da in der Konfiguration bereits eine Aggregation AGGREGATE_DIMENSIONS über Produkte vorgenommen worden ist.

DATA([d/Measures]= "Zugang" ) =
RESULTLOOKUP([d/Konto]=[d/Konto].[p/CR],[d/Measures]="Wert")
* (1 + ATTRIBUTE([d/Konto].[p/VAT]))
* (1 - RESULTLOOKUP([d/Sonstiges]="S-1",[d/Date]="202512",
[d/Region]="#",[d/Version]="public.Actual",[d/Measures]="Wert"))

Planung und Mehrwertsteuer? In der Erfolgsplanung kümmert man sich eigentlich nicht um die Mehrwertsteuer. Sie ist quasi ein durchlaufender Posten. Allerdings ist die Mehrwertsteuer zahlungswirksam. Wenn der Umsatz 1.000,- Euro beträgt, ist die Umsatzzahlung 1.190,- Euro bei 19 % Mehrwertsteuer. Es geht also mehr Geld ein. Blöd ist nur, wenn die Kunden später zahlen, Ihre Verbindlichkeit gegenüber dem Finanzamt aber mit der Fakturierung entsteht. Und der Fiskus gibt kein langes Zahlungsziel.

Die Kalkulation des Abgangs ist etwas aufwendiger, da ja nun das Rückzahlungsverhalten für das jeweilige Konto verwendet werden muss. Es wird also der Prozentfaktor mit dem GuV-Kontenwert der jeweiligen Periode gezogen. Beim Liquiditätsfaktor »S + 0« wird die aktuelle Periode genommen, beim Liquiditätsfaktor »S + 1« wird die vorherige Periode genommen und so weiter. Hierzu kann die Datumsfunktion PREVIOUS() verwendet werden. Sie erlaubt die Verwendung eines Offsets.

Zugang und Abgang werden übrigens für jedes Konto in eigenen Kennzahlen gespeichert. Das wäre nicht unbedingt nötig. Man könnte direkt in Wert schreiben. Aber die Vorgehensweise erleichtert die Nachvollziehbarkeit und ist deswegen zu empfehlen.

Data( [d/Measures]="Abgang" ) =
(

RESULTLOOKUP([d/Sonstiges]="S+0",[d/Date]="202512",[d/Region]="#",
[d/Version]="public.Actual",[d/Measures]="Wert")
*
RESULTLOOKUP([d/Konto]=[d/Konto].[p/CR],[d/Measures]="Wert")

+
RESULTLOOKUP([d/Sonstiges]="S+1",[d/Date]="202512",[d/Region]="#",

[d/Version]="public.Actual",[d/Measures]="Wert")
*
RESULTLOOKUP([d/Konto]=[d/Konto].[p/CR],[d/Measures]="Wert",

[d/Date]=PREVIOUS(1,"Month"))
+
RESULTLOOKUP([d/Sonstiges]="S+2",[d/Date]="202512",[d/Region]="#",

[d/Version]="public.Actual",[d/Measures]="Wert")
*
RESULTLOOKUP([d/Konto]=[d/Konto].[p/CR],[d/Measures]="Wert",

[d/Date]=PREVIOUS(2,"Month"))
)
* (1+ ATTRIBUTE([d/Konto].[p/VAT]))

Und schließlich muss die Bestandsgleichung für die Bilanz berechnet werden. Hierzu kann das Konstrukt FOREACH verwendet werden. FOREACH [d/Date] ist deswegen notwendig, weil die Reihenfolge der Berechnung notwendig ist. Dies ist bei einer Fortschreibung über Perioden immer der Fall. Die Kennzahl Wert benötigt den kalkulierten Wert der Vorperiode.

Die Vorzeichen sind wichtig. In Abhängigkeit des Kontentyps werden daher unterschiedliche Kalkulationen verwendet. Der Umsatz wird zum Beispiel negativ gespeichert, der Forderungszugang soll allerdings positiv dargestellt werden.

Eine IFELSE()-Funktion werden Sie in der SAP Analytics Cloud vergeblich suchen. Es gibt nur das prozedurale IF / ELSE.

IF [d/Konto].[p/accType] = "AST" THEN
DATA([d/Measures]="Zugang") = RESULTLOOKUP([d/Measures]="Zugang")*-1
ELSE
DATA([d/Measures]="Abgang") = RESULTLOOKUP([d/Measures]="Abgang")*-1
ENDIF

FOREACH [d/Date]
DATA( [d/Measures]="Wert" ) = // Bestandskontenfortschreibung

RESULTLOOKUP([d/Date]=Previous(),[d/Measures]="Wert")
+ RESULTLOOKUP([d/Measures]="Zugang")
+ RESULTLOOKUP([d/Measures]="Abgang")
ENDFOR

Die FOREACH-Schleife ließe sich auch durch die CARRYFORWARD-Funktion abbilden. Hierzu ist zusätzlich noch eine Kennzahl Anfangsbestand anzulegen. Zum Zeitpunkt des Tests funktionierte diese aber noch nicht richtig. Die Funktion muss dann wie folgt parametrisiert werden:

DATA() = CARRYFORWARD([d/Measures] ,"Anfangsbestand" ,
"Wert" ,"Anfangsbestand"+"Zugang"-"Abgang")

Die FOREACH-Schleife kann dann rausgenommen werden.

Damit werden die Bilanzkonten korrekt abgeleitet. Das erscheint ein wenig aufwendig, aber in der Anwendung recht komfortabel, da die betroffenen Bilanzkonten nicht geplant werden müssen. Das gesamte Bilanzskript ist in Abbildung 16.5 dargestellt.

Beachten Sie aber auch, dass im Skript keine Konten direkt angesprochen werden. Alle Konten werden über Hierarchien und Attribut-Referenzen angesprochen. Auch das ist »Best Practice«. Wenn ein neues Konto abgeleitet werden muss, bleibt das Skript wartungsfrei. Es muss nur das Konto angelegt und die Attribute und Hierarchien befüllt werden.

Berechnung der Mehrwertsteuer

Wir müssen uns auch noch der korrekten Steuerverbuchung widmen. Das Finanzamt will die Mehrwertsteuer bereits überwiesen bekommen, auch wenn die Zahlung möglicherweise noch gar nicht eingegangen ist. Es entsteht eine Verbindlichkeit, also ist ein Bestandskonto notwendig. Im Beispiel nehmen wir einfach 30 Tage Zahlungsziel an. Auch hier werden die Werte wieder auf Zugang und Abgang zur besseren Nachvollziehbarkeit gespeichert.

Über ATTRIBUTE([d/Konto].[p/VAT] kann auf den Mehrwertsteuersatz zugegriffen werden. Sehr häufig ist die Mehrwertsteuerberechnung an das Konto gebunden. So könnte es ein Konto mit 19 % und ein Konto mit 7 % geben.

MEMBERSET [d/Konto].[p/BP] = "TP"
MEMBERSET [d/Date] = %Startperiode% TO %Endperiode%
AGGREGATE_DIMENSIONS = [d/Produkt]
AGGREGATE_WRITETO [d/Produkt] = "#"
FOREACH [d/Date]
DATA([d/Measures] = "Zugang") = RESULTLOOKUP([d/Konto] =
d/Konto].[p/CR], [d/Measures] = "Wert")
* (ATTRIBUTE([d/Konto].[p/VAT]))

DATA([d/Measures] = "Abgang") = RESULTLOOKUP([d/Konto] =
d/Konto].[p/CR], [d/Measures] = "Wert",
d/Date] = PREVIOUS(1, "Month")) * ATTRIBUTE([d/Konto].[p/VAT])

DATA([d/Measures] = "Wert") =
RESULTLOOKUP([d/Date] = PREVIOUS(), [d/Measures] = "Wert")
+ RESULTLOOKUP([d/Measures] = "Zugang")
- RESULTLOOKUP([d/Measures] = "Abgang")

ENDFOR

Ermittlung der Anzahlungen

Und schließlich müssen wir uns noch den Anzahlungen widmen. Das Prinzip ist das gleiche wie bei der Forderungs- und Verbindlichkeitenableitung. Nur mit umgekehrter Berechnungslogik. Das Anzahlungskonto wird von nachfolgenden Perioden gesteuert. Mit der Rechnungsstellung wird die Anzahlung automatisch aufgelöst.

MEMBERSET [d/Date] = %Startperiode% TO %Endperiode%
MEMBERSET [d/Konto].[p/BP] = "PP"
AGGREGATE_DIMENSIONS = [d/Produkt]
AGGREGATE_WRITETO [d/Produkt] = "#"

FOREACH [d/Date]
DATA([d/Measures]= "Zugang" ) =
RESULTLOOKUP([d/Konto]=[d/Konto].[p/CR],
[d/Measures]="Wert",[d/Date]=NEXT(1))

* ( 1+ ATTRIBUTE([d/Konto].[p/VAT]))
* RESULTLOOKUP([d/Sonstiges]="S-1",
[d/Date]="202512",[d/Region]="#",


[d/Version]="public.Actual",[d/Measures]="Wert")
Data( [d/Measures]="Abgang" ) =
RESULTLOOKUP([d/Konto]=[d/Konto].[p/CR],
[d/Measures]="Wert")

* ( 1+ ATTRIBUTE([d/Konto].[p/VAT]))
* RESULTLOOKUP([d/Sonstiges]="S-1",
[d/Date]="202512",[d/Region]="#",


[d/Version]="public.Actual",[d/Measures]="Wert")
DATA( [d/Measures]="Wert" ) =
RESULTLOOKUP([d/Date]=Previous(),[d/Measures]="Wert")
+ RESULTLOOKUP([d/Measures]="Zugang")
- RESULTLOOKUP([d/Measures]="Abgang")
ENDFOR

Cashflow

Die Cashflow-Ermittlung ist einfach eine Kopie der Datenaktion für den Cashflow, die wir bereits für die Ist-Werte verwendet haben.

MEMBERSET [d/Date] = %Startperiode% TO %Endperiode%
MEMBERSET [d/Measures] = "Cashflow"
IF [d/Konto].[p/accType]="EXP" or [d/Konto].[p/accType] = "INC"
or [d/Konto].[p/accType] = "NFIN" THEN
DATA() = RESULTLOOKUP([d/Measures]="Wert")
ELSE
DATA() = RESULTLOOKUP([d/Measures]="Wert")
- RESULTLOOKUP([d/Measures]="Wert",[d/Date]=PREVIOUS())
ENDIF

Kopierschritt

Jetzt kommt der schwierigste Teil: Bilanz, GuV und Cashflow-Rechnung müssen zusammengefügt werden:

  • Der (einbehaltene) Gewinn einer Periode führt zu einer Veränderung der Kapitalrücklagen.
  • Die Veränderung der Barmittel führt zu einer Veränderung der Zahlungsmittel.

Diese Fortschreibungen müssen gemacht werden. Und zum Schluss muss Aktiva auch noch gleich Passiva sein. Los geht’s.

Zwar können Sie in den erweiterten Formeln nicht auf berechnete Werte zugreifen, was natürlich schade ist. Aber Sie können über Kopieren diese Werte in temporäre Konten speichern.

  1. Legen Sie einen Kopierschritt an (Abbildung 16.16).

    Abbildung 16.16: Persistieren der Ergebnisse

  2. Tragen Sie die Konten entsprechend der Regel ein. Damit werden die Ergebnisse von Gewinn-und-Verlust-Rechnung und Cashflow in temporäre Konten ohne Formel übertragen.

    Von

    Nach

    P1400 Einbehaltene Gewinne

    T1700 Einbehaltene Gewinne

    C1000 Nettoerhöhung / - verminderung Barmittel

    T1900 Nettobarmittel

Bilanzfortschreibung

Und im letzten Schritt werden die Bilanzkonten fortgeschrieben. Die temporären Konten werden auf den Zugang gebucht und schließlich wird das Konto fortgeschrieben.

MEMBERSET [d/Date] = %Startperiode% TO %Endperiode%
FOREACH [d/Date]
DATA([d/Konto]="B2120",[d/Measures]="Zugang") =
RESULTLOOKUP([d/Konto]= "T1700",[d/Measures]="Wert")
DATA([d/Konto]="B2120",[d/Measures]="Wert") =
RESULTLOOKUP([d/Date]=PREVIOUS(),[d/Konto]="B2120", [d/Measures]="Wert")
+ RESULTLOOKUP([d/Konto]="B2120",[d/Measures]="Zugang")

DATA([d/Konto]="B1350",[d/Measures]="Zugang") =
RESULTLOOKUP([d/Konto]="T1900",[d/Measures]="Cashflow")
DATA([d/Konto]="B1350",[d/Measures]="Wert") =
RESULTLOOKUP([d/Date]=PREVIOUS(), [d/Konto]="B1350", [d/Measures]="Wert")
+ RESULTLOOKUP([d/Konto]="B1350",[d/Measures]="Zugang")
ENDFOR

Validieren Sie die Datenaktion. Wenn kein Fehler vorliegt, speichern Sie die Datenaktion (Abbildung 16.17).

Abbildung 16.17: Speichern der Datenaktion

Planung / Simulation

Jetzt, da wir ein funktionierendes Berichtssystem haben, sollte dieses an die Planungsebene angepasst werden.

  1. Öffnen Sie Ihre bestehende Story. Wechseln Sie in den Bearbeitungsmodus. Wählen Sie das Blatt GuV Ist und duplizieren Sie es (Abbildung 16.18).
  2. Benennen Sie das neue Blatt in GuV Plan um.
  3. Erstellen Sie eine neue Version für die Plandaten. Klicken Sie dazu im Tabellen-Widget auf Actual (Abbildung 16.19).
  4. Klicken Sie auf das » + «-Symbol neben Öffentliche Versionen (Abbildung 16.20).

    Abbildung 16.18: Duplizieren der Seite

    Abbildung 16.19: Aufruf der Versionsverwaltung

    Abbildung 16.20: Neuanlage einer Version

  5. Nennen Sie die Version Plan und wählen Sie die Kategorie Planung aus (Abbildung 16.21).

    Mit Auswahl der Kategorie geben Sie dem System einen Hinweis auf die Formatierung in Tabellen und Diagrammen gemäß der IBCS (International Business Communication Standards).

    Abbildung 16.21: Attribute einer neuen Version

  6. Schließen Sie die Versionsverwaltung.
  7. Deselektieren Sie in der Tabelle Actual und wählen Sie Plan aus (Abbildung 16.22). Vorher müssen Sie allerdings wieder Nicht gebuchte Elemente anzeigen aktivieren, da ja noch keine Planwerte vorhanden sind und somit standardseitig die neue Version nicht zur Auswahl angeboten wird.

    Abbildung 16.22: Dimensionsansicht eines Modells

    Das Tabellen-Widget ist leer, wir haben ja noch keine Plandaten.

  8. Wählen Sie als Datumselemente 2023 und reißen Sie die Spaltendimension in Monate auf.
  9. Justieren Sie das Widget so, dass alle Spalten sichtbar sind. Reservieren Sie etwas Platz für die noch anzuzeigenden Zeilen.
  10. Erstellen Sie nun einen Auslöser für Planungen (eine gekonnte Wortwahl) und wählen Sie die Unterkategorie AUSLÖSER FÜR PLANUNGEN (Abbildung 16.23).

    Abbildung 16.23: Anlage des Planungstriggers

  11. Der Auslöser braucht nun einige Parameter. Ordnen Sie die Datenaktion ERFI Copy Istdaten zu (Abbildung 16.24).
  12. Und schließlich muss noch festgelegt werden, welche Version verwendet wird.

    Abbildung 16.24: Einbinden der Kopierfunktion

    Bei verschiedenen Szenarien kann man den Anwender entscheiden lassen. Wir haben nur eine Planversion (bis jetzt) und daher können Sie die Version fest eintragen.

  13. Positionieren Sie den Planungstrigger im Blatt, wo er Ihnen am besten gefällt. Sie können auch die Höhe und Breite verringern.
  14. Führen Sie die Kalkulation aus. Und schon sollten Daten vorhanden sein (Abbildung 16.25).

    Abbildung 16.25: Die gefüllte Plan-GuV

  15. Duplizieren Sie nun die Seite GuV Plan in Bilanz Plan.
  16. Wählen Sie den Kontenfilter (Abbildung 16.26), entfernen Sie das Häkchen bei Einbehaltene Gewinne und wählen Sie Aktiva und Passiva (Abbildung 16.27).

    Abbildung 16.26: Anpassung des Kontenfilters

    Abbildung 16.27: Auswahl der Bilanzpositionen

    Das Ergebnis sollte in etwa wie in Abbildung 16.28 aussehen.

    Abbildung 16.28: Dimensionsansicht eines Modells

  17. Duplizieren Sie wieder die Seite und benennen Sie das Ergebnis in Plan CF um.
  18. Wählen Sie im Kontenfilter Nettoerhöhung /-verminderung Barmittel aus (Abbildung 16.29).

    Abbildung 16.29: Auswahl der Cashflow-Positionen

  19. Ändern Sie wieder den Spaltenfilter für die Kennzahlen auf Cash Flow (Abbildung 16.30).

    Abbildung 16.30: Auswahl der Cashflow-Kennzahl

    Alle Werte sind weg. Immerhin besser als falsche Werte.

    Wir müssen noch eine Berechnung durchführen.

  20. Markieren Sie den AUSLÖSER FÜR DATENAKTIONEN und ordnen Sie die Datenaktion ERFI Planintegration zu. Setzen Sie Zielversion und Fixed Value auf die angegebenen Werte (Abbildung 16.31).

    Abbildung 16.31: Parametrisierung des Planungstriggers

  21. Lassen Sie nun kalkulieren. Es dauert ein wenig, schließlich ist das Skript ja auch etwas länger.

    Vergleichen Sie Ihr Ergebnis mit dem von Abbildung 16.32.

  22. Führen Sie erneut einen Vergleich durch. Sind die Werte korrekt (Abbildung 16.33)?

    Wenn Sie es genau machen wollen, brauchen Sie Excel oder einen Taschenrechner. Aber das hier sieht gut aus.

Abbildung 16.32: Die vollständige Cashflow-Sicht

Abbildung 16.33: Die Bilanzsicht zur Abstimmung

Simulation

Das war eine ganze Menge Arbeit. Aber was haben wir jetzt gewonnen? Wir haben eine integrierte Planung, bei der GuV, Bilanz und Cashflow immer abgestimmt ist. Damit sehen Sie bei Entscheidungen immer, welche Konsequenzen diese auf Erfolg und Liquidität hat.

Ein typisches Szenario könnte sein: Wir rechnen mit einem größeren Auftrag im Mai. Statt 240 werden wir 300 Stück absetzen. Die Erfolgskonsequenzen können wir noch ganz gut abschätzen, wenn wir uns Preis und Stückkosten ansehen. Aber wie hoch ist der Liquiditätseffekt?

  1. Duplizieren Sie das Blatt  Guv Plan und nennen Sie das neue Blatt Simulation.
  2. Nehmen Sie in die Zeilendefinition der Tabelle auch das Produkt mit auf (Abbildung 16.34).

    Abbildung 16.34: Hinzufügen einer Dimension zu den Berichtszeilen

  3. Wählen Sie das Produkt Combi aus und schieben Sie die Zeilendimension Produkt über Konto (Abbildung 16.35).

    Abbildung 16.35: Produktauswahl

  4. Wählen Sie nun noch die Elemente Menge und DB 1 (Abbildung 16.36).
  5. Vergleichen Sie wieder Ihre Ergebnisse (Abbildung 16.37).

Jetzt wollen wir eine Simulationsvariante erstellen.

  1. Markieren Sie Plan in der Tabelle und erstellen Sie über die rechte Maustaste eine neue Version durch Auswahl von  Version kopieren (Abbildung 16.38).
  2. Die neue Version soll Basis heißen und nimmt den aktuellen Planstand auf (Abbildung 16.39).

Abbildung 16.36: Auswahl der Kontenelemente

Abbildung 16.37: Neue Planungsmaske

Abbildung 16.38: Kopieren der Version

Abbildung 16.39: Sichern der Ausgangsbasis in eine neue Version.

Es ergibt sich nun eine Änderung der Menge im Mai von 240 auf 300. Dies könnte ein Zusatzauftrag sein (Abbildung 16.40).

Sie sehen, dass die Monatswerte alle gleich sind. Dies ist eine Vereinfachung, die Ihnen helfen soll, die Veränderungen besser abschätzen zu können.

Aber können Sie die Effekte ohne Weiteres abschätzen? Der Umsatz erhöht sich, indem Sie Menge * Preis berechnen: 60 * 8562. Die Produktkosten lassen sich analog abschätzen: 60 * 5.200,-. Von der Gewinnveränderung nach Steuern von 201.720,- muss noch der Steueranteil von 45 % abgezogen werden.

Der Zahlungseffekt ist deutlich schwieriger abzuschätzen. Wir erhalten im April 10 % des Betrags zuzüglich Mehrwertsteuer. Dann werden die Zahlungen angewendet. Gut, dass dies das System für uns tut.

Abbildung 16.40: Simulationsanpassung

  1. Berechnen Sie die Planungsdaten, indem Sie Planintegration auf der Seite Plan CF starten. Sie sehen doch einige Veränderungen (Abbildung 16.41). Erstaunlich, oder?
    • Anzahlungen erhöhen sich im April (10 %) und werden im Mai wieder ausgebucht.
    • Die Mehrwertsteuerverbindlichkeit erhöht sich im Mai und wird im Juni ausgeglichen.
    • Da die Menge auch die Herstellkosten beeinflussen, haben wir auch einen Effekt auf die Verbindlichkeiten und damit auch auf die Vorsteuer.
    • Aufgrund unserer Steuer- und Ausschüttungsregel entstehen weitere Zahlungsverpflichtungen.

    Abbildung 16.41: Ergebnis der Simulation

    Wir können es aber auch einfacher mit der Analyse haben.

  2. Erstellen Sie eine neue Registerkarte durch Duplizieren von GuV Plan und benennen Sie sie in Szenarienvergleich um (Abbildung 16.42).
  3. Wählen Sie nun aus den Measures Basis und Plan für die Vergleichsanalyse aus (Abbildung 16.43).
  4. Ändern Sie die Spaltenreihenfolge, indem Sie Date eine Position nach oben ziehen (Abbildung 16.44).

    Abbildung 16.42: Neues Berichtsblatt

    Abbildung 16.43: Auswahl der Vergleichsversionen

    Abbildung 16.44: Spaltensortierung

  5. Markieren Sie die Spaltentitel Basis und Plan. Fügen Sie eine Spaltenberechnung hinzu (Prozentualer Unterschied). Wählen Sie Wiederkehrend aus (Abbildung 16.45).

    Die Abweichung stimmt nicht ganz. Das Vorzeichen ist ungewöhnlich. Aber alles kein Problem mit der SAP Analytics Cloud.

  6. Aktivieren Sie die FORMELLEISTE (Abbildung 16.46).
  7. Ändern Sie die Formelleiste wie in Abbildung 16.47 dargestellt.

    Wenn Sie jetzt eine monatliche Vergleichsanalyse machen wollen, wird Ihnen auffallen, dass der Bericht sehr breit wird. Wenn Sie nach rechts scrollen, verschwinden die Zeilenbezeichnungen. Das ist nicht sehr zweckmäßig. Aber Sie können Spalten fixieren.

    Abbildung 16.45: Erstellung einer Berichtskalkulation

    Abbildung 16.46: Aktivieren der Formelleiste

    Abbildung 16.47: Modifikation der Berichtsformel

  8. Klicken Sie auf die erste Spalte, vielleicht auf die Position Umsatz. Mit der rechten Maustaste kommen Sie zur Tabellenfixierung. Wählen Sie Bis Spalte aus (Abbildung 16.48).
  9. Nach dem Motto »Unser Bericht soll schöner werden« wählen Sie die Zellendiagramm-Darstellung aus (Abbildung 16.49).

    Der Bericht sollte nun wie in Abbildung 16.50 dargestellt, aussehen.

    Abbildung 16.48: Fixieren der Zeilennamen

    Abbildung 16.49: Auswahl Zellendiagramm

    Abbildung 16.50: Abweichungsanalyse der GuV

  10. Duplizieren Sie das Blatt Szenarienvergleich.
  11. Wählen Sie den Maßnahmenfilter und wählen Sie Cashflow anstatt Wert (Abbildung 16.51).

    Abbildung 16.51: Auswahl der Cashflow-Kennzahl

  12. Wählen Sie aus dem Kontenfilter nun noch den Knoten Nettoerhöhung / -verminderung Barmittel (Abbildung 16.52).

    Die Ansicht sieht nicht ganz so schön aus. Eine Division durch 0 erzeugt einen Anzeigefehler (Abbildung 16.53).

    Abbildung 16.52: Auswahl der Cashflow-Positionen

    Abbildung 16.53: Divisionsfehler im Cashflow-Bericht

  13. Das kann man aber ändern. Fügen Sie eine kleine kosmetische Änderung in die Formel ein (Abbildung 16.54).

    Abbildung 16.54: Anpassung der Abweichungsformel

Dem Mathematiker ein Grauen, dem BWLer hilft’s … Das Ergebnis sollte wie in Abbildung 16.55 ausschauen.

Abbildung 16.55: Darstellung der Cashflow-Abweichungen

Eine vollständige Erfolgs- und Finanzplanung und Simulation. Gratulation, wenn Sie so lange durchgehalten haben!