Kapitel 16
IN DIESEM KAPITEL
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
müssen wir noch erläutern. Eine integrierte Erfolgs- und Finanzplanung kann auch noch weitere Positionen, wie Rückstellungen oder Anzahlungen, berücksichtigen.
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:
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.
- 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.
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.
ERFI
und öffnen Sie den Editor für die Account-Dimension.
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
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.
Abbildung 16.5: Duplizieren des GuV-Berichts
Liquiditätsfaktoren
um (Abbildung 16.6).
Abbildung 16.6: Umbenennen der Seite
Builder
) zu Bilanzverarbeitung
und wählen Sie Verarbeitung der Bilanz
aus (Abbildung 16.7).
Abbildung 16.7: Ändern der Hierarchie
Ä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.
Sonstiges
als Spaltendimension aus (Abbildung 16.8).
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
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).
ERFI Planintegration
. Und vergessen Sie nicht das Speichern (Abbildung 16.10).
Abbildung 16.10: Datenaktion »ERFI Planintegration«
Startperiode
und Endperiode
). Damit können Sie die Cashflow-Berechnung zu einer ausgewählten Periode starten.Abbildung 16.11: Parameterkonfiguration
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
Abbildung 16.13: Kalkulationsschritte
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.
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.
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"))
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.
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.
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
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.
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
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
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
Jetzt kommt der schwierigste Teil: Bilanz, GuV und Cashflow-Rechnung müssen zusammengefügt werden:
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.
Abbildung 16.16: Persistieren der Ergebnisse
Von |
Nach |
---|---|
P1400 Einbehaltene Gewinne |
T1700 Einbehaltene Gewinne |
C1000 Nettoerhöhung / - verminderung Barmittel |
T1900 Nettobarmittel |
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
Jetzt, da wir ein funktionierendes Berichtssystem haben, sollte dieses an die Planungsebene angepasst werden.
GuV Ist
und duplizieren Sie es (Abbildung 16.18).GuV Plan
um.Actual (Abbildung 16.19)
.Öffentliche Versionen
(Abbildung 16.20).
Abbildung 16.18: Duplizieren der Seite
Abbildung 16.19: Aufruf der Versionsverwaltung
Abbildung 16.20: Neuanlage einer Version
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
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.
2023
und reißen Sie die Spaltendimension in Monate auf.Abbildung 16.23: Anlage des Planungstriggers
ERFI Copy Istdaten
zu (Abbildung 16.24).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.
Abbildung 16.25: Die gefüllte Plan-GuV
GuV Plan
in Bilanz Plan
.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
Plan CF
um.Nettoerhöhung /-verminderung Barmittel
aus (Abbildung 16.29).
Abbildung 16.29: Auswahl der Cashflow-Positionen
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.
ERFI Planintegration
zu. Setzen Sie Zielversion
und Fixed Value
auf die angegebenen Werte (Abbildung 16.31).
Abbildung 16.31: Parametrisierung des Planungstriggers
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.
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
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?
Guv Plan
und nennen Sie das neue Blatt Simulation
.Produkt
mit auf (Abbildung 16.34).
Abbildung 16.34: Hinzufügen einer Dimension zu den Berichtszeilen
Combi
aus und schieben Sie die Zeilendimension Produkt
über Konto
(Abbildung 16.35).
Abbildung 16.35: Produktauswahl
Menge
und DB 1
(Abbildung 16.36).Jetzt wollen wir eine Simulationsvariante erstellen.
Plan
in der Tabelle und erstellen Sie über die rechte Maustaste eine neue Version durch Auswahl von Version kopieren
(Abbildung 16.38).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).
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
Planintegration
auf der Seite Plan CF
starten. Sie sehen doch einige Veränderungen (Abbildung 16.41). Erstaunlich, oder?Abbildung 16.41: Ergebnis der Simulation
Wir können es aber auch einfacher mit der Analyse haben.
GuV Plan
und benennen Sie sie in Szenarienvergleich
um (Abbildung 16.42).Basis
und Plan
für die Vergleichsanalyse aus (Abbildung 16.43).Date
eine Position nach oben ziehen (Abbildung 16.44).
Abbildung 16.42: Neues Berichtsblatt
Abbildung 16.43: Auswahl der Vergleichsversionen
Abbildung 16.44: Spaltensortierung
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.
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
Umsatz
. Mit der rechten Maustaste kommen Sie zur Tabellenfixierung. Wählen Sie Bis Spalte
aus (Abbildung 16.48).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
Szenarienvergleich
.Cashflow
anstatt Wert
(Abbildung 16.51).
Abbildung 16.51: Auswahl der Cashflow-Kennzahl
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
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!