Inverse Formel
Im folgenden werden die Laufzeitaspekte inverser Formeln erläutert. Wir setzen voraus, dass Sie eingabebereite und inverse Formeln im Query Designer anlegen können (siehe Inverse Formel definieren)
Beispiel 1: Durchschnittspreis
Wie in der Dokumentation zur Definition inverser Formeln im Query Designer beginnen wir mit dem Beispiel Durchschnittspreis. Wir nehmen an, dass Umsatz (Sales) und Menge (Sales Quantity) eingeschränkte Kennzahlen sind (wobei für Umsatz die Währung auf einen Wert eingeschränkt und eine initiale Mengeneinheit festgelegt ist und für Menge umgekehrt). Beide eingeschränkte Kennzahlen verwenden im Query Designer unter Planung auf Summen die Einstellung Eingegebenen Wert disaggregieren.
Eine Datenscheibe schützt die Produkte Comes after C++ und MMIX by D.E. Knuth.
Wie das folgende Bild zeigt, ist die Summenzeile Werkzeuge (Tools) nicht eingabebereit, weder für die eingeschränkten Kennzahlen Menge und Umsatz noch für die (eingabebereite) Formel Durchschnittspreis (Avg. Price). Die Formel Durchschnittspreis ist hier nicht eingabebereit, da alle Operanden dieser Formel nicht eingabebereit sind.
Eingabebereite Formeln, inverse Formeln und Formelgruppen
Eingabebereite berechnete Kennzahlen können Sie sowohl im BEx Analyzer als auch im BEx Web Analyzer verwenden.
Beachten Sie, dass das Fixieren von Zellen allerdings nur im BEx Web Analyzer möglich ist.
Eingabebereitschaft von Formeln
Berechnete Kennzahlen erben ihre Eingabebereitschaft von ihren Operanden: Wenn Sie im Query Designer eine eingabebereite Formel F = F(op1, …, opn) definiert haben, prüft das System zur Laufzeit, ob mindestens ein Operand eingabebereit ist. Wenn das nicht der Fall ist, ist auch die Formel F nicht eingabebereit. Falls ein Operand opi = G ebenfalls eine eingabebereite Formel ist, gilt dieselbe Regel für G.
Reihenfolge der Berechnungen
Die Berechnung inverser Formeln kann man als eine Art “Umkehrung” des Reportings betrachten. Da die BI Integrierte Planung eingabebereite Queries für die manuelle Planung verwendet, berechnet das System die Reporting-Formeln für das Resultset, das an das Frontend geschickt wird. In ABAP-Dynpro-Terminologie werden Reporting-Formeln also im PBO (process before output) berechnet. Nachdem Daten in eingabebereiten Zellen der Query manuell geändert wurden, wird ein Server-Roundtrip angestoßen, ein sogenannter PAI (process after input). Zu diesem Zeitpunkt werden inverse Formeln berechnet. Änderungen in eingabebereiten Formeln werden auf die Basiskennzahlen zurückgeführt, wobei ggf. auch Disaggregationseinstellungen berücksichtigt werden. Dadurch entstehen neue Deltasätze, die im Deltabuffer abgelegt werden. Im nächsten PBO liest der OLAP-Prozessor die Deltasätze aus, um seinen internen Zustand und das Resultset aufzufrischen. Dabei werden die Reporting-Formeln erneut berechnet.
Für die inversen Formeln ergibt sich daraus, dass diese tatsächliche Umkehrungen der eingabebereiten Formeln im mathematischen Sinne sein müssen. Andernfalls würde eine Änderung in einer eingabebereiten Formel nach einem vollendeten PAI-PBO-Zyklus im nächsten PBO überschrieben.
Der folgende Abschnitt erläutert die allgemeinen Regeln des implementierten Rechenmodells im einzelnen.
Allgemeine Regeln
Die Berechnung von inversen Formeln wird vom System nur dann angestoßen, wenn Zellenwerte für eingabebereite berechnete Kennzahlen geändert wurden bzw. wenn diese fixiert waren und andere Operanden von eingabebereiten Kennzahlen geändert wurden.
Angenommen F = F(op1,..., opn) ist eine eingabebereite Formel, wobei die Operanden op1,..., opk mit k < n ebenfalls eingabebereit sind. Im Query Designer wurden dann k inverse Formeln angelegt, um die Operanden op1,..., opn zu berechnen:
Fi = Fi(F, op1,…, opi-1, opi+1, … , opk, … , opn) für i = 1,…, k |
Wenn z.B. F geändert wurde, muss das System die ‘beste’ inverse Formel Fi für deren Berechnung finden. Das Ergebnis von Fi wird an opi weitergegeben. Dann kann der neue Wert von opi weitere Berechnungen oder eine Disaggregation anstoßen.
Die folgenden Regeln wendet das System für die Formelinversion an:
...
1. Formelinversionen werden auf der Grundlage von Datensätzen durchgeführt. Hier bestimmen die Werte der Merkmale im Aufriss den Datensatz. Die Berechnung der inversen Formeln findet pro Datensatz für die im Query Designer definierten Strukturbestandteile statt; diese Berechnungen werden von anderen Datensätzen nicht beeinflusst.
2. Eingabebereite Formeln werden auf eingabebereite Basis- oder eingeschränkte Kennzahlen zurückgerechnet, ggf. durch Inversion anderer eingabebereiter Formeln, wenn es ineinander geschachtelte Formelgruppen gibt. Diese Änderungen stoßen eine Disaggregation an, sofern Kennzahlen eine der Disaggregationseinstellungen verwenden.
3. In einem Server-Roundtrip wird pro Formelgruppe höchstens eine inverse Formel gerechnet. Nach dieser Berechnung sind alle Elemente dieser Formelgruppe temporär fixiert, d.h. während dieses Server-Roundtrips können die Elemente einer bereits berechneten Formelgruppe nicht durch Berechnungen aus anderen Formelgruppen überschrieben werden.
4. Um diejenige inverse Formel herauszufinden, die berechnet werden muss, sammelt das System zuerst die Elemente, die Berechnungen auslösen, d.h. geänderte oder fixierte Zellwerte von eingabebereiten Formeln (für jeden Datensatz). Wenn ein Operand der Formelgruppe in einem früheren Schritt berechnet wurde, wird auch dieser Operand als fix für die neue Berechnung behandelt, d.h. er wird als eine bekannte Quelle betrachtet. Mögliche Ziele für die Berechnung sind die eingabebereiten Operanden der aktuellen Formelgruppe, die nicht geändert, fixiert oder berechnet wurden. Falls daraus nicht eindeutig eine der inversen Formeln als zu berechnen hervorgeht, nimmt das System die inverse Formel mit der (im Query Designer festgelegten) höchsten Formelpriorität.
5. An den durch manuelle Änderungen oder fixierte Zellwerte ausgelösten Berechnungen können mehrere Formelgruppen beteiligt sein. Da sich die Festlegung der Formelpriorität auf eine Formelgruppe bezieht, ist nicht eindeutig bestimmt, welche Formelgruppe als erste zu berechnen ist. Das System berechnet die Formelgruppen in aufsteigender Reihenfolge nach der Anzahl der „Freiheitsgrade“. Der aktuelle Freiheitsgrad wird durch die Differenz von Anzahl der Operanden minus der Anzahl von bereits bekannten Operanden (d.h. Konstanten, fixierte, manuell geänderte oder in einem früheren Schritt berechnete Operanden) festgelegt. Falls sogar der aktuelle Freiheitsgrad der Formelgruppen derselbe ist, ist die Reihenfolge der Berechnung undefiniert.
6. In Hinsicht auf die Formelinversion werden neue Zeilen wie bestehende behandelt. Wenn es die Zeile bereits gibt, werden geänderte oder zurückgerechnete Werte von Basis-Kennzahlen aggregiert.
Beachten Sie, dass das System nicht versucht, irgendeine Lösung für das Rechenproblem zu finden, welches aufgrund manueller Eingaben und aller Arten von Customizing eingabebereiter Queries entsteht. Das System wendet zur Lösungsfindung die oben genannten Regeln an. Wenn dies nicht zum Erfolg führt, weist das System mit entsprechenden Fehlermeldungen darauf hin.
Beispiel 2: Durch manuelle Änderungen angestoßene Formelinversion
Wir verdeutlichen die allgemeinen Regeln am Beispiel der berechneten eingabebereiten Kennzahl Durchschnittspreis (siehe oben Beispiel 1).
Hier ist der Durchschnittspreis Träger der Formelgruppe, die aus folgenden Elementen besteht: Durchschnittspreis, Umsatz und Menge. Im Query Designer sind die folgenden beiden inversen Formeln definiert worden (siehe Inverse Formel definieren):
... 1. ‘Umsatz’ = ‘Durchschnittspreis’ * ‘Menge’ 2. ‘Menge’ = NDIV0(‘Umsatz’ / ‘Durchschnittspreis’) |
a. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde. Beide inverse Formeln können für die Formelinversion verwendet werden; das System nimmt die Formel mit der höchsten Formelpriorität, in diesem Falle die Umsatz-Formel.
b. Wir nehmen an, dass die Werte für den Durchschnittspreis und den Umsatz geändert wurden. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
c. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert und die Zelle Umsatz fixiert wurde. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
d. Wir nehmen an, dass der Wert für den Durchschnittspreis geändert wurde und die Zelle Umsatz nicht eingabebereit ist, z.B. weil diese Kennzahl durch eine Datenscheibe geschützt ist. In diesem Fall ist es eindeutig, dass das System die Menge-Formel berechnen muss.
e. Wir nehmen an, dass die Werte für den Umsatz oder Menge geändert wurden. Dann spielen inverse Formeln keine Rolle. Das System berechnet den Durchschnittspreis.
f. Wir nehmen an, dass der Wert für den Umsatz geändert und die Zelle Durchschnittspreis fixiert. In diesem Fall ist es eindeutig, dass das System die Umsatz-Formel berechnen muss.
Beispiel 3: Sich überlappende Formelgruppen
In diesem Beispiel nutzen wir drei eingeschränkte Kennzahlen: Umsatz geplant, Umsatz Prognose, Umsatz aktuell. Wir möchten auch die prozentuale Abweichung des geplanten vom vorausberechneten sowie des geplanten vom aktuellen Umsatz planen. Daher legen wir zwei eingabebereite Formeln und die entsprechenden inversen Formeln an.
Die eingabebereite Formel zur Berechnung der prozentuale Abweichung des geplanten vom aktuellen Umsatz lautet:
%Dev (P,A) = NDIV0( ‘Umsatz geplant’ % ‘Umsatz aktuell’ ) |
Diese Formelgruppe hat als Elemente: ‘%Dev(P,A)’, Umsatz geplant und Umsatz aktuell.
Die eingabebereite Formel zur Berechnung der prozentuale Abweichung des geplanten vom prognostizierten Umsatz lautet:
%Dev (P,F) = NDIV0( ‘Umsatz geplant’ % ‘Umsatz Prognose’ ) |
Diese Formelgruppe hat als Elemente: ‘%Dev(P,F)’, Umsatz geplant und Umsatz Prognose.
Beide Formelgruppen enthalten das Element Umsatz geplant. Wir nehmen an, dass Umsatz aktuell und Umsatz Prognose nicht eingabebereit sind, z.B. weil die Vorausberechnung vom Planungsadministrator vorbereitet wurde. In diesem Fall sind eingabebereit: Umsatz geplant, ‘%Dev(P,A)’ und ‘%Dev(P,F)’. Das System braucht nur Inversionen von ‘%Dev(P,A)’ auf Umsatz geplant und von ‘%Dev(P,F)’ auf Umsatz geplant.
Produkt |
%Dev (P,F) |
%Dev (P,A) |
Umsatz geplant |
Umsatz Prognose |
Umsatz aktuell |
PC Medium |
0 |
10 ® 20 |
110 |
110 |
100 |
PC Small |
0 ® 10 |
10 |
220 |
220 |
200 |
PC High End |
0 ® 10 |
10 ® 20 |
330 Error |
330 |
300 |
Gesamt |
0 |
10 |
660 |
660 |
600 |
Die manuelle Eingabe ist in der Tabelle dargestellt durch den Pfeil ‘®’. Für eine bessere Übersichtlichkeit enthält diese Tabelle gleich alle drei im folgenden näher erklärten Beispiele. Das soll aber nicht bedeuten, dass die Änderungen in einem einzigen Interaktionsschritt durchgeführt wurden.
...
1. Wenn man ‘%Dev(P,A)’ für ‘PC Medium’ ändert, errechnet das System zuerst im PAI (process after input) den Umsatz geplant und dann im PBO (process before output) die prozentuale Abweichung ‘%Dev(P,F)’.
2. Wenn man ‘%Dev(P,F)’ für ‘PC Small’ ändert, errechnet das System zuerst im PAI den Umsatz geplant und dann im PBO die prozentuale Abweichung ‘%Dev(P,A)’.
3. Wenn man ‘%Dev(P,A)’ und ‘%Dev(P,F)’ in einem Schritt für ‘PC High End’ ändert, versucht das System, Umsatz geplant zu berechnen. Das ist für eine Formelgruppe möglich, bei der anderen aber versucht das System, zugleich auch Umsatz geplant abzugleichen. Dieses Verhalten führt zu einem Fehler, da die anderen Kennzahlen nicht eingabebereit sind und daher nicht über die Berechnung inverser Formeln geändert werden.
Ohne den unter 3. beschriebenen Fehlerfall erhält man folgendes Ergebnis:
Produkt |
%Dev (P,F) |
%Dev (P,A) |
Umsatz geplant |
Umsatz Prognose |
Umsatz aktuell |
PC Medium |
9.09 |
20 |
120 |
110 |
100 |
PC Small |
21.00 |
10 |
242 |
220 |
200 |
PC High End |
0.00 |
10 |
330 |
330 |
300 |
Gesamt |
4.84 |
15.34 |
692 |
660 |
600 |
Beispiel 4: Ineinander geschachtelte Formelgruppen
In diesem Beispiel möchten wir Kosten einiger Kostenstellen planen. Wir nehmen an, wir haben zwei Kennzahlen Fixe Kosten and Variable Kosten. Fixe Kosten ist nicht eingabebereit, da wir in diesem Beispiel annehmen, dass wir diese Kosten nicht beeinflussen können. Variable Kosten werden geplant. Die Gesamtkosten sind die fixen Kosten zuzüglich der variablen Kosten. Vom vergangenen Jahr haben wir bereits die Gesamtkosten in einer eingeschränkten Kennzahl Kosten LY; hiervon interessieren uns die fixen und die variablen Kostenanteile nicht. Wir möchten allerdings die prozentuale Abweichung der Gesamtkosten von den Gesamtkosten des Vorjahres planen. Diese Überlegungen zusammenfassend, können wir zwei eingabebereite Formeln bilden:
‘Gesamtkosten’ = ‘Variable Kosten’ + ‘Fixe Kosten’ |
Diese Formelgruppe hat als Elemente: Gesamtkosten, Variable Kosten und Fixe Kosten.
Die andere eingabebereite Formel ist:
‘%Dev(T, LY) = ‘Gesamtkosten’ % ‘Kosten LY’ |
Diese Formelgruppe hat als Elemente: ‘%Dev(T,LY)l’, Gesamtkosten und Kosten LY.
Die beiden Formelgruppen sind ineinander geschachtelt, da die Formel Gesamtkosten auch in der Formel ‘%Dev(T,LY)’ verwendet wird.
Kostenstelle |
%Dev (T,LY) |
Gesamtkosten |
Variable Kosten |
Fixe Kosten |
Kosten LY |
4711 |
10 |
110 ® 120 |
100 |
10 |
100 |
4712 |
10 ® 20 |
220 |
200 |
20 |
200 |
4713 |
10 ® 20 |
330 ® 400 |
300 Error |
30 |
300 |
Gesamt |
10 |
660 |
600 |
60 |
600 |
Die manuelle Eingabe ist in der Tabelle dargestellt durch den Pfeil ‘®’. Für eine bessere Übersichtlichkeit enthält diese Tabelle gleich alle drei im folgenden näher erklärten Beispiele. Das soll aber nicht bedeuten, dass die Änderungen in einem einzigen Interaktionsschritt durchgeführt wurden.
...
1. Wenn man die Gesamtkosten für die Kostenstelle 4711 ändert, errechnet das System zuerst im PAI die Variablen Kosten und rechnet dann im PBO zurück auf die Gesamtkosten und die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’.
2. Wenn man die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’ für die Kostenstelle 4712 ändert, errechnet das System zuerst im PAI die Gesamtkosten , weil die Formel eingabebereit ist. Diese implizite Änderung stößt die nächste Formelinversion an. Im Ergebnis berechnet das System auch die Variablen Kosten im PAI. Im PBO rechnet das System dann zurück auf die Gesamtkosten und auf die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’.
3. Wenn man die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’ und die Gesamtkosten für die Kostenstelle 4713 in einem Schritt ändert, wurde zugleich auch der einzige eingabebereite Operand der Formel ‘%Dev(T,LY)’ geändert. Damit ist eine Formelinversion für die prozentuale Abweichung zum Vorjahr ‘%Dev(T,LY)’ nicht möglich. Das System weist mit entsprechenden Fehlermeldungen darauf hin.
Ohne den unter 3. beschriebenen Fehlerfall erhält man folgendes Ergebnis:
Kostenstelle |
%Dev (T,LY) |
Gesamtkosten |
Variable Kosten |
Fixe Kosten |
Kosten LY |
4711 |
20 |
120 |
110 |
10 |
100 |
4712 |
20 |
240 |
220 |
20 |
200 |
4713 |
10 |
330 |
300 |
30 |
300 |
Gesamt |
15 |
690 |
630 |
60 |
600 |
Beispiel 5: Berechnung inverser Formeln und Disaggregation
Im folgenden zeigen wir ein noch komplexeres Beispiel, indem wir mehrere Werte auf verschiedenen Ebenen des Result-Sets in einem Schritt ändern. Wir nehmen an, die folgende Formel hat die höchste Priorität:
‘Menge’ = NDIV0( ‘Umsatz’ / ‘Durchschnittspreis’ ) |
Wie durch die Pfeile ‘ ® ’ angezeigt, wurden in der folgenden Tabelle einige Zahlen auf verschiedenen Summationsstufen in einem Schritt geändert. Beachten Sie, dass das System hier zuerst die inversen Formeln aller Ebenen berechnet und dann geänderte oder berechnete Werte auf die Basiskennzahlen disaggregiert.
Produkt |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 |
3 |
1333.33 ® 800 |
PC Small |
4000.00 |
4 ® 3 |
1000.00 ® 500 |
PC High End |
4000.00 |
3 |
1333.33 |
Gesamt |
12000.00 |
10 |
1200.00 ® 1000 |
Diese Änderungen stoßen die folgenden Berechnungen an:
Produkt |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 (zeitweilig fixiert) |
4000.00 / 800 (Priorität) |
1333.33 ® 800 |
PC Small |
3 * 500 |
4 ® 3 |
1000.00 ® 500 |
PC High End |
4000.00 |
3 |
1333.33 |
Gesamt |
12000.00 (zeitweilig fixiert) |
12000.00 / 1000 (Priorität) |
1200.00 ® 1000 |
Das Zwischenergebnis ist folgendes:
Produkt |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 (zeitweilig fixiert) |
5 (berechnet) |
800 (geändert) |
PC Small |
1500 (berechnet) |
3 (geändert) |
500 (geändert) |
PC High End |
4000.00 |
3 |
1333.33 |
Gesamt |
12000.00 (zeitweilig fixiert) |
12 (berechnet) |
1000 (geändert) |
Die Mengen-Spalte enthält einen geänderten Gesamt -Wert und Änderungen von Werten auf niedrigeren Ebenen. Das System beginnt daher die Disaggregation von 12 – ( 5 + 3 ) = 4 für den einzigen unveränderten Wert des Produktes ‘PC High End’.
Die Umsatz-Spalte enthält (durch Berechnungen in den jeweiligen Zeilen) zeitweilig fixierte Werte und einen geänderten Wert. Das System beginnt daher die Disaggregation von 12000 – ( 4000 + 1500 ) = 6500 für den einzigen unveränderten Wert des Produktes ‘PC High End’.
Das Ergebnis der Berechnung der inversen Formeln und der Disaggregation ist folgendes:
Product |
Umsatz |
Menge |
Durchschnittspreis |
PC Medium |
4000.00 |
5 |
800.00 |
PC Small |
1500.00 |
3 |
500.00 |
PC High End |
6500.00 |
4 |
1625.00 |
Total |
12000.00 |
12 |
1000.00 |
Fehlerbehandlung
Wenn das System keine inverse Formel zur Berechnung findet, ist die Benutzereingabe ungültig. Das System generiert Meldungen, die auf die Ursachen des Problems – wie z.B. zu viele manuelle Änderungen oder zu viele Einschränkungen aufgrund fixierter Werte - hinweisen.
Es gibt Fälle, in denen sämtliche Formelinversionen möglich sind, aber nicht die anschließende Disaggregation der Werte, wenn z.B. sämtliche Einzelwerte einer Teilsumme, einer Gesamtsumme oder eines Hierarchieknotens und die Teilsumme, Gesamtsumme oder der Hierarchieknoten selbst geändert oder berechnet wurden. Das System generiert entsprechende Meldungen.
Rundungsregeln
Kennzahlwerte werden in der Datenbank mit einer begrenzten Anzahl von Dezimalstellen gespeichert. Bei der Berechnung von Formeln treten im allgemeinen Rundungseffekte auf. Durch inverse Formeln können Kennzahlwerte berechnet werden, die auf der Datenbank abgelegt werden. Für solche Kennzahlen wird daher jeder berechnete oder durch Disaggregation entstandene Kennzahlwert auf die Datenbank-Dezimalen gerundet. Wenn das System aggregierte Werte durch inverse Formeln berechnet und die berechneten Werte disaggregiert, können Rundungsfehler erheblich werden. Beachten Sie daher, dass ein Wert, der manuell geändert wurde, nach der Berechnung der Formelinversion und der Aktualisierung des Result-Sets von dem eingegebenen Wert abweichen kann. Dasselbe gilt auch für fixierte Werte.
Wir empfehlen daher, für alle Operanden von inversen Formeln dieselbe Anzahl von Datenbankdezimalstellen zu verwenden.
Empfehlungen
Wir empfehlen, ineinander geschachtelte eingabebereite Formeln zu vermeiden. Modellieren Sie eingabebereite Formeln und Formelinversionen möglichst so, dass es nicht zu viele Varianten für mögliche Berechnungen gibt. Die zur Laufzeit ausgeführten Berechnungen sind dann leichter zu verstehen.
Um bei Quotienten als eingabebereiten Formeln, z.B. bei dem Durchschnittspreis, formale Divisionsfehler wie Division durch Null zu vermeiden, verwenden Sie den Operator NDIV0. Wenn z.B. noch keine Daten geplant sind und für einige Merkmale unter Zugriffsart für Ergebniswerte die Einstellung Stammdaten oder Merkmalsbeziehungen verwendet wird, entstehen im allgemeinen viele leere Datenzellen. Ohne die Nutzung der Datenfunktion NDIV0 wären dann die Zellen für Durchschnittspreis nicht eingabebereit. Wenn Sie jedoch NDIV0 verwenden, ergibt die Berechnung NDIV0( 0 / 0 ) = 0 für solche Zellen und der Durchschnittspreis kann geändert werden.
Die Prozentfunktion %GT zur Laufzeit
Wir erläutern zuerst die Laufzeitaspekte des Beispiels Prozentualer Anteil (siehe Inverse Formel definieren, Beispiel 2) und beschreiben anschließend die allgemeinen Regeln.
Beispiel: Prozentualer Anteil %GT
Wir nehmen an, dass der Betrag eine Basis-Kennzahl mit der Verteilungsart für Disaggregation Analogverteilung (zu sich selbst) ist.
Eine Datenscheibe schützt die Produkte Comes after C++ und MMIX by D.E. Knuth.
Wie das folgende Bild zeigt, ist die Summe der Spalte Prozentualer Anteil des Betrages in Hinsicht auf die Gesamtsumme (% Contribution) nicht eingabebereit, da der entsprechende Wert immer 100% ist. Alle übrigen Zellen sind eingabebereit mit Ausnahme der Werte für die Produkte Comes after C++ und MMIX by D.E. Knuth und die Teilsummen für diese Produkte. Die Basis-Kennzahl Betrag (Amount) wird durch eine Datenscheibe geschützt. Im Ergebnis ist auch die Eingabebereitschaft für Prozentualer Anteil (% Contribution) ausgeschaltet: Die Eigenschaft “nicht eingabebereit” wurde durch die Formel %GT von dem Operanden Betrag (Amount) geerbt. Zusätzlich wurde die Eigenschaft “nicht eingabebereit” von der Teilsumme Tools geerbt, da alle Kinder dieses Hierarchieknotens nicht eingabebereit sind.
Weitere Informationen über allgemeine Regeln, wie die Eigenschaft “nicht eingabebereit” für Teilsummen, Summen und Hierarchieknoten vererbt wird, finden Sie im SAP-Hinweis 994853.
Allgemeine Regeln für die Prozentfunktion %GT
Eingabebereite Formeln mit der Prozentfunktion %GT (“Prozentualer Anteil an der Gesamtsumme”) können sowohl im BEx Analyzer als auch im BEx Web Analyzer verwendet werden.
Beachten Sie allerdings, dass das Fixieren der Zellen nur im BEx Web Analyzer zur Verfügung steht.
Zur Laufzeit kann eine eingabebereite %GT(op)-Formel nur dann wirklich eingabebereit sein, wenn der Operand op zur Laufzeit eingabebereit ist.
Der Wert von %GT für die Gesamtsumme ist immer 100%; daher ist das Gesamtergebnis nicht eingabebereit. So bleibt der Wert für %GT auch 100%, wenn man z.B. einen Filter (auf der Achse) für Personal Computer verwendet. Berechnungen mit %GT sind noch möglich, wenn keine Teilsummen, Summen oder Hierarchieknoten angezeigt werden. Es ist auch möglich, die Kennzahl op, in unserem Beispiel Betrag (Amount), auszublenden; der Operand op, hier Betrag (Amount), muss dann aber eingabebereit sein.
Wenn beide, sowohl der Operand op, in unserem Beispiel Betrag (Amount), als auch %GT für dieselbe Ebene in einem einzigen Interaktionsschritt geändert werden, weist das system darauf mit Fehlermeldungen hin. Möglich ist hingegen, das Gesamtergebnis für op, d.h. Betrag (Amount), und die Werte für %GT auf einer tieferen Ebene zu ändern. In diesem Fall nimmt das System den neuen Wert für das Gesamtergebnis und den geänderten Wert %GT, um den neuen Wert für den Operanden op, d.h. Betrag (Amount), auf der tieferen Ebene zu berechnen. Diese beiden Änderungen stoßen eine Disaggregation für den Operanden op, d.h. Betrag (Amount), an.
Das Gesamtergebnis für Betrag (Amount) darf nicht gleich Null sein. Falls das nicht der Fall ist, sind %GT-Zellen nicht eingabebereit.
Werte für %GT können auch außerhalb des Bereichs von 0 bis 100 liegen; im allgemeinen wird dies – nach Disaggregation – zu negativen Werten für den Operanden, d.h. Betrag (Amount), führen.
Berechnung der Prozentfunktion %GT in neuen Zeilen
Das System führt Berechnungen inverser Formeln auch in neuen Zeilen durch. Dies führt zu geänderten Werten der Basis-Kennzahlen. Falls Zeilen bereits vorhanden waren, addiert das System die geänderten Werte auf die bestehenden Werte. Es gibt keine speziellen Prüfungen für neue Zeilen.