Best Practices für konfigurierbare Berechnungen

Nutzen Sie diese Best Practices, wenn Sie mit konfigurierbaren Berechnungen arbeiten.

Berechnungskonzepte

Die wichtigsten Konzepte zur Erstellung von Berechnungen lauten wie folgt:

Datenblöcke
Basisskriptformat
Bottom-up-Berechnungen im Vergleich zu Top-down-Berechnungen
Blockmodus im Vergleich zum Zellenmodus

Datenblöcke

Die folgende Abbildung zeigt einen Datenblock aus einer Beispielanwendung.

Gespeicherte Elemente von Dense-Dimensionen bilden einen Datenblock. Die Blockgröße für die oben aufgeführte Beispielanwendung ist 2 (Sales und Cash) x 8 Byte = 16 Byte.
Eindeutige Kombinationen aus Sparse-Dimensionselementen bilden Indizes und verweisen auf Datenblöcke. In der oben aufgeführten Beispielanwendung gibt es insgesamt 2 (Actual, Budget) x 2 (FY17, FY18) x 2 (Jan, Feb) = 8 Indizes.

In Essbase BSO-(Block Storage Option-)Datenbanken besteht ein Block aus gespeicherten Elementen einer Dense-Dimension. In Financial Consolidation and Close ist Account standardmäßig die einzige Dense-Dimension.

In diesem Beispiel ist die Account-Dimension dicht besetzt und verfügt über 1977 gespeicherte Elemente. Dies bedeutet, dass der Block einer einzelnen BSO-Datenbankkonsolidierung über 1977 Zellen verfügt, wobei jede Zelle ein Element der Account-Dimension darstellt.

Die Blockgröße in Byte beträgt:

Blockgröße (Byte) = Anzahl gespeicherter Elemente in Account-Dimension * 8
Blockgröße (Byte) = 1977 * 8 = 15.816 Byte

Hinweis: Zum Anzeigen der Datenbankeigenschaften wählen Sie in Calculation Manager Aktion, Datenbankeigenschaften aus.

Best Practices zum Erstellen von Datenblöcken

Wenn eine konfigurierbare Berechnung ausgeführt wird, mit der in eine Datenzelle geschrieben wird, muss für Daten, die in die Datenbank geschrieben werden sollen, ein Datenblock vorhanden sein.

Datenblöcke sind Kombinationen von Elementen aus gespeicherten Sparse- und Dense-Dimensionen.

Für jede Kombination aus gespeicherten Sparse-Dimensionen werden separate Datenblöcke erstellt. Die Elemente in einer Dense-Dimension entsprechen einem Block.

Wenn Sie konfigurierbare Berechnungen erstellen, müssen Sie möglicherweise zusätzliche Blöcke zum Speichern der berechneten Ergebnisse erstellen und Probleme aufgrund von fehlenden Daten beheben.

Sie können die Option "Blöcke automatisch erstellen" aktivieren, damit fehlende Blöcke automatisch erstellt werden. Informationen hierzu finden Sie unter Automatische Erstellung von Blöcken für konfigurierbare Berechnungen aktivieren.

Wenn Sie die Bottom-up-Verarbeitung in Ihren konfigurierbaren Berechnungen verwenden, müssen Sie Datenblöcke manuell erstellen oder sicherstellen, dass Datenblöcke bereits vorhanden sind.

Zur manuellen Erstellung von Datenblöcken können Sie eine der folgenden Methoden verwenden:

Daten während des Dataload-Prozesses zuweisen. Beispiel: Schreiben Sie einen Nullwert in die Elementschnittmenge einer Dense-Dimension und dann "#missing", um den Nullwert nach der Blockerstellung zu löschen.
Den Essbase-Befehl DATACOPY verwenden, bei dem alle Blöcke aus der Quelle in das Ziel geschrieben werden, einschließlich fehlende Zellen. Bei dieser Methode werden jedoch möglicherweise unnötige Blöcke geschrieben, und der Konsolidierungsprozess kann verlangsamt werden.

Verwendung der Einstellung "Blöcke automatisch erstellen"

Die Einstellung "Blöcke automatisch erstellen" wird bereitgestellt, um fehlende Blöcke bei einer konfigurierbaren Berechnung zu erstellen.

Diese Einstellung hat große Auswirkungen auf die Performance, da sie den Algorithmus für potenzielle Blöcke verwendet, um die gesamte Datenbank nach vorhandenen Blöcken zu durchsuchen und fehlende Blöcke bei Bedarf zu erstellen.

Verwenden Sie diese Einstellung nur, wenn Sie ganz sicher sind, dass sich keines der anderen Blockerstellungsverfahren eignet.

Die Funktion @CALCMODE(BOTTOMUP) (falls am Einfügepunkt verwendet) und die Option "Blöcke automatisch erstellen" schließen sich gegenseitig aus.

Zieldatenblöcke für @SHIFT- und @PRIOR-Funktionen erstellen

Wenn Sie die @SHIFT- oder @PRIOR-Funktionen in Berechnungsskripten verwenden, müssen die Zieldatenblöcke vorhanden sein, bevor Sie die Berechnung ausführen können. Die Zieldatenblöcke müssen entweder als Teil einer anderen Berechnung oder eines Dataloads vorhanden sein oder mit der @CREATEBLOCK-Funktion erstellt werden.

Beispielanwendungsfall:

In Ist, FY16, P12, ML_HFM sind Daten vorhanden. Die Daten werden aus Oracle Hyperion Financial Management abgerufen und wurden nicht in Ist, FY16, P1, ML_HFM geladen. Die Daten müssen aus der P12-Periode des Vorjahres stammen, und in Ist, FY17, P1, ML_HFM_Calc muss ein Rückbuchungseintrag erfolgen.

Das Berechnungsskript lautet wie folgt:

Beispielberechnungsskript für Datenblock

In P13 wurden keine Journale aktiviert ("FCCS_Journal Input"). Es wird erwartet, dass der Code den folgenden Pfad annimmt, mit "ML_HFM_Calc" als Anker für das Sparse-Element:

@SHIFT("P12"->"ML_HFM", -1, @CHILDREN("Years"));

Es wird jedoch #MISSING zurückgegeben.

Workaround 1:

Workaround 2:

Richtlinien für die ClearEmptyBlocks-Regel

Mit der ClearEmptyBlocks-Geschäftsregel können Sie den Cube "Consol" nach leeren Datenblöcken durchsuchen. Leere Datenblöcke können aus folgenden Gründen generiert worden sein:

On-Demand-Regelausführung, die leere Blöcke generiert. Beispiel: mit der @CREATEBLOCK-Funktion. Ein generierter leerer Datenblock wird dann möglicherweise nie verwendet.
Ein Einfügepunktcode (z.B. FCCS_20), der aufgrund von TOPDOWN-Berechnungen möglicherweise Blocklöcher aufweist, ggf. durch Zuweisung von #MISSING; Verwendung von Sparse-Ankern anstelle von @CALCMODE(BOTTOM UP)
Financial Consolidation and Close-Systemberechnungen

Empfohlene Vorgehensweise zum Ausführen der ClearEmptyBlocks-Regel

Als Best Practice wird empfohlen, die Regel nach dem Beenden der On-Demand-Regel/-Einfügepunkttests auszuführen, wenn sich das Skript in der Entwicklungsphase befindet. Mit der ClearEmptyBlocks-Regel können Blockstatistiken vor und nach der Ausführung der Berechnung in der Entwicklungsphase erstellt werden.
Führen Sie die Regel in der Produktionsphase für ein angegebenes Jahr aus, nachdem eine Konsolidierung für ein vollständiges Jahr abgeschlossen ist.

Sie können auch die Ausführung eines EPM Automate-Skripts nach den Geschäftszeiten planen, z.B. jedes Wochenende:

call epmautomate runbusinessrule ClearEmptyBlocks Scenario ="<Scenario>" Year = "<Particular Year>"
Period = "ILv10Descendants(YearTotal)"
call epmautomate restructurecube Consol

Hinweis: Im Zeitplan muss für diese Aktivität mindestens ein Abstand von drei bis vier Stunden zum täglichen Wartungszyklus eingehalten werden.

Basisskriptformat

Das folgende Beispiel zeigt ein Beispielformat für das Berechnungsskript.

Konfigurierbare Berechnungen schreiben

Die folgende Abbildung zeigt die Regeln für konfigurierbare Berechnungen in der Registerkarte "Lokale Währung" unter "Konsolidierung: Verarbeitung".

Beispiel 1 für Fenster mit konfigurierbaren Berechnungen

Die folgende Abbildung zeigt die entsprechenden Regeln für konfigurierbare Berechnungen in der Registerkarte "Lokale Währung" unter "Konsolidierung: Verarbeitung".

Beispiel 2 für konfigurierbare Berechnung

Mit einer konfigurierbaren Berechnung können Sie angepasste Berechnungen durchführen, die drei Kategorien von Daten umfassen:

Nicht umgerechnete Daten: Entitywährung + (FCCS_Entity Input oder FCCS_Entity Consolidation)
Umgerechnete Daten: Übergeordnete Währung + (FCCS_Entity Input oder FCCS_Entity Consolidation)
Eliminierte Daten: Übergeordnete Währung + FCCS_Elimination

Es ist wichtig, die Kombination aus Währung und Konsolidierung zu verstehen, um eine konfigurierbare Berechnung in der richtigen Vorlage für Regeln für konfigurierbare Berechnungen zu schreiben, auch als "Einfügepunkt" bekannt.

Beispiel: FCCS_30_After Opening Balance Carry Forward_Translated soll nur verwendet werden, wenn die FCCS-Standardumrechnung und -Fremdwährungsberechnung bereits für die Daten verarbeitet wurde, die in FCCS_30 besonderer Aufmerksamkeit bedürfen.

Beispiele zum Schreiben konfigurierbarer Berechnungen

Im Folgenden finden Sie ein Beispiel für ein Problem bei der Blockerstellung und für die verschiedenen Ansätze zum Lösen derselben Berechnung.

Anwendungsfall:

Werte in zwei Konten hinzufügen: Warehouse_Stock und Showroom_Stock, die in FCCS_Managed Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP und No Product geladen sind
Ergebnis der Berechnung in Account Inventory_Stock unter FCCS_Other Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP und No Product speichern
Konfigurierbare Berechnung FCCS_10 verwenden

Ansatz 1: Keinen Elementblock (Anker) verwenden

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("FCCS_Other Data", "FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "No Product",
"FCCS_Local GAAP")
3.      " Inventory_Stock " = "FCCS_Managed Data"->" Warehouse_Stock " + "FCCS_Managed Data"->
"Showroom_Stock ";

4.      ENDFIX
5.      ENDFIX

Nachteile dieses Ansatzes:

Hierbei handelt es sich um eine Dense-Berechnung, da Inventory_Stock ein Konto auf der linken Seite ist. Auch wenn die Berechnung richtig geschrieben ist, wird das Ergebnis der Berechnung nicht angezeigt, wenn kein vorheriger Block unter FCCS_Other Data und keine zugehörigen sonstigen FIX-Elemente für das Ergebnis vorhanden sind.
Einschränkungen für die bedingte Berechnung, wie z.B. IF..ELSE..ENDIF, können nicht erzwungen werden.
Ein Workaround ist erforderlich, um Nulldatenblöcke manuell in die obige Schnittmenge aufzunehmen.

Ansatz 2: Dense-Elementblock (Anker) verwenden

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("FCCS_Other Data", "FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "FCCS_No Intercompany",
"FCCS_Local GAAP")

3.      " Inventory_Stock "(
4.      "FCCS_Managed Data"->" Warehouse_Stock " + "FCCS_Managed Data"->" Showroom_Stock ";
5.      )
6.      ENDFIX
7.      ENDFIX

Nachteile dieses Ansatzes:

Hierbei handelt es sich um eine Dense-Berechnung, da der Elementblock Inventory_Stock ein Konto ist. Auch wenn die Berechnung richtig geschrieben ist, wird das Ergebnis der Berechnung nicht angezeigt, wenn kein vorheriger Block unter FCCS_Other Data und keine zugehörigen sonstigen FIX-Elemente vorhanden sind.
Ein Workaround ist erforderlich, um Nulldatenblöcke manuell in die obige Schnittmenge aufzunehmen.

Ansatz 3: Sparse-Elementblock (Anker) verwenden

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Other Data" (
4.      " Inventory_Stock " = "FCCS_Managed Data"->" Warehouse_Stock " + "FCCS_Managed Data"->
"Showroom_Stock ";

5.      )
6.      ENDFIX
7.      ENDFIX

Vorteil dieses Ansatzes:

Hierbei handelt es sich um eine Sparse-Berechnung, da der Elementblock FCCS_Other Data Data Source ist, eine Sparse-Dimension. Die Berechnung führt zu einem Block.

Nachteil dieses Ansatzes:

Für den Elementblock wird eine Top-down-Berechnung ausgeführt, da ein dimensionsübergreifender Operator verwendet wird.

Ansatz 4: Sparse-Elementblock und Bottom-up-Berechnung verwenden

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ( "FCCS_Mvmts_NetIncome", "FCCS_No Intercompany", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Managed Data"(@CALCMODE(BOTTOMUP);
4.      "FCCS_Other Data"-> "Inventory_Stock " = " Warehouse_Stock " + " Showroom_Stock "; 5.        )
6.      ENDFIX
7.      ENDFIX

Vorteile dieses Ansatzes:

Hierbei handelt es sich um eine Sparse-Berechnung, da der Elementblock FCCS_Managed Data Data Source ist, eine Sparse-Dimension.
Für den Elementblock wird eine Bottom-up-Berechnung ausgeführt.
FCCS_Managed Data ist die Quelle dieser Berechnung. Der resultierende Block wird unter FCCS_Other Data nur erstellt, wenn der Datenblock in der Quelle vorhanden ist.
Auf der rechten Seite der Berechnung ist kein dimensionsübergreifender Operator erforderlich.
Die Berechnung muss explizit als "Bottom-up" angegeben werden, da ein dimensionsübergreifender Operator auf der linken Seite dieser Zuweisung vorhanden ist.

Berechnungen im Blockmodus im Vergleich zum Zellenmodus

Blockmodus: (Standardmodus) In diesem Berechnungsmodus gruppiert Essbase die Zellen in einem Block und berechnet gleichzeitig die Zellen in den einzelnen Gruppen.
Der Blockberechnungsmodus ist schnell, Sie müssen im Hinblick auf die Datenabhängigkeiten innerhalb des Blocks jedoch besonders sorgfältig sein, um sicherzustellen, dass die resultierenden Daten richtig sind.
Zellenmodus: In diesem Berechnungsmodus berechnet Essbase die einzelnen Zellen sequenziell entsprechend der Berechnungsreihenfolge, die auf der Modellstruktur basiert.
Der Zellenberechnungsmodus ist entsprechend langsamer. Dadurch werden jedoch genaue Ergebnisse sichergestellt, bei denen Datenabhängigkeiten berücksichtigt werden.
Wenn Essbase eine Formel kompiliert, wird in der Anwendungslogdatei eine Meldung ähnlich der folgenden erfasst, um den Ausführungsmodus zu erläutern:

Formula on member Profit % will be executed in CELL and TOPDOWN mode. (Formel in Element "Gewinn %" wird im Zellen- und im Top-down-Modus ausgeführt.)

Essbase verwendet den Blockmodus beim Berechnen einer Formel, sofern nicht Funktionen wie die folgenden verwendet werden:

@ANCEST
@CURRMBR
@ISMBR on a dense member
@MDANCESTVAL
@MDPARENTVAL
@MDSHIFT
@NEXT
@PARENT
@PARENTVAL
@PRIOR
@SANCESTVAL
@SPARENTVAL
@SHIFT
@XWRITE

Um den Blockmodus manuell auszulösen, verwenden Sie @CALCMODE(BLOCK). Stellen Sie sicher, dass keine Datenabhängigkeiten innerhalb des Dense-Blocks vorhanden sind.

Beispiel für Blockmodus

Führen Sie die folgende Berechnung je nach Monat aus:

Januar - Sales Synergies ist die Summe der untergeordneten Elemente von Returns and Allowances.
Februar - Sales Synergies ist die Summe der untergeordneten Elemente von Returns and Allowances - multiplizieren Sie mit 20 %.
Restliche Monate - Sales Synergies ist die Summe der untergeordneten Elemente von Returns and Allowances - multiplizieren Sie mit 10 %.

Blockmodus

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("Sales Synergies", "FCCS_No Intercompany", "FCCS_Managed Data", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Mvmts_NetIncome" (
4.      IF (@ISMBR("Jan"))
5.      @SUM(@Children("Returns and Allowances"));
6.      ELSEIF (@ISMBR("Feb"))
7.      @SUM(@Children("Returns and Allowances")) * 0.2;
8.      ELSE
9.      @SUM(@Children("Returns and Allowances")) * 0.1;
10.     ENDIF
11.     )
12.     ENDFIX
13.     ENDFIX

Zellenmodus im Vergleich zum ausgelösten Blockmodus

Führen Sie die folgende Berechnung je nach Monat aus:

Januar - Sales Synergies ist die Summe der untergeordneten Elemente von Returns and Allowances.

Februar - Sales Synergies ist die Summe der untergeordneten Elemente von Returns and Allowances - multiplizieren Sie mit 20 %.

Restliche Monate - Sales Synergies ist die Summe der untergeordneten Elemente von Returns and Allowances plus Sales Synergies der vorherigen Periode. Multiplizieren Sie das gesamte Ergebnis mit 10 %.

Zellenmodus

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("Sales Synergies", "FCCS_No Intercompany", "FCCS_Managed Data", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Mvmts_NetIncome" (
4.      IF (@ISMBR("Jan"))
5.      @SUM(@Children("Returns and Allowances"));
6.      ELSEIF (@ISMBR("Feb"))
7.      @SUM(@Children("Returns and Allowances")) * 0.2;
8.      ELSE
9.      (@SUM(@Children("Returns and Allowances")) + @PRIOR("Sales Synergies")) * 0.1;
10.     ENDIF
11.     )
12.     ENDFIX
13.     ENDFIX

Blockmodus

1.   FIX ("FCCS_Entity Input", "Entity Currency")
2.      FIX ("Sales Synergies", "FCCS_No Intercompany", "FCCS_Managed Data", "No Product", "FCCS_Local GAAP")
3.      "FCCS_Mvmts_NetIncome" (@CALCMODE(BLOCK);
4.      IF (@ISMBR("Jan"))
5.      @SUM(@Children("Returns and Allowances"));
6.      ELSEIF (@ISMBR("Feb"))
7.      @SUM(@Children("Returns and Allowances")) * 0.2;
8.      ELSE
9.      (@SUM(@Children("Returns and Allowances")) + @PRIOR("Sales Synergies")) * 0.1;
10.     ENDIF
11.     )
12.     ENDFIX
13.     ENDFIX

Anwendungsfall Kunde A

Aus FDMEE geladene verwaltete Daten für Erfolgsrechnungskonten neu klassifizieren in einem anderen berechneten Element der Data Source-Dimension, basierend auf Journalanpassungen
Langsame Performance: 180 Minuten für ein gesamtes Jahr

Kunde A - Skriptbeispiel

Kunde A - Skriptverbesserungen

@REMOVE verwenden, um das Konto zu entfernen, anstatt die @ISMBR-Prüfung in der dicht besetzten Account-Dimension zu verwenden
Bottom-up-Verarbeitung
Boolesche @ISLEV-Funktion anstelle von @LEV und @CURRMEMBER verwenden
Performanceverbesserung um 90 %

Anwendungsfall Kunde B

Ziel - die Daten aus einigen Quellentitys in eine Zielentity verschieben
Daten wurden nicht berechnet
Langsame Performance - 3,5 Stunden

Kunde B - Skriptbeispiel

Kunde B - Skriptverbesserungen

Zielblock durch Kopieren erstellen
Top-down-Berechnung wird beibehalten
Die Berechnung wird nur für ein Zielelement der Custom-Dimension durchgeführt
Verwenden Sie @LIKE, um das Skript generisch zu machen
Dauer reduziert von 3,5 Stunden auf wenige Minuten

Anwendungsfall Kunde C

Bewegungen basierend auf dem über die Benutzeroberfläche eingegebenen Element "FCCS_Closing_Balance_Input" neu klassifizieren
Langsame Performance - 15 Minuten

Kunde C - Skriptbeispiel (Fortsetzung)

Kunde C - Skriptverbesserungen

Entfernen Sie eingeschränkte Elemente aus dem FIX-Ausdruck
Bottom-up-Verarbeitung
Prüfen Sie, ob es Grenzfälle gibt
Prüfen Sie zuerst auf häufige Fälle.
Performanceverbesserung um 40 %

Anwendungsfall Kunde D

Aus Hyperion Financial Management (Datenquelle ML_HFM) abgerufene Daten neu klassifizieren und im Element ML_HFM_Calc der Data Source-Dimension speichern
Langsame Performance - 24 Stunden für eine einzelne Periode
Datenabgleich nicht erfolgreich, da Blöcke nicht wie erwartet erstellt wurden

Kunde D - Skriptbeispiel

Kunde D - Skriptverbesserungen

@REMOVE verwenden, um das Konto zu entfernen, anstatt die @ISMBR-Prüfung in der dicht besetzten Account-Dimension zu verwenden
Bottom-up-Verarbeitung
Boolesche @ISLEV-Funktion anstelle von @LEV und @CURRMEMBER verwenden
Performanceverbesserung um 90 %

Anwendungsfall Kunde E

Konsolidierungsmethode wurde in der aktuellen Periode geändert, alle kumulativen Umrechnungsdifferenzen und Eliminierungsbehandlungen früherer Perioden sollten entfernt werden
Langsame Performance - 90 Minuten

Kunde E - Skriptverbesserungen

Data_Input im Ziel verwenden, um den Validierungsfehler zum Schreiben in FCCS_Intercompany_Eliminations zu vermeiden
Bottom-up beim Durchlaufen von ICP-Elementen mit Endsaldoeingabe verwenden
Dauer reduziert von 90 Minuten auf 11 Minuten

Übersicht der Best Practices

Bottom-up-Verarbeitung
@REMOVE verwenden, um das Konto zu entfernen, anstatt die @ISMBR-Prüfung in der dicht besetzten Account-Dimension zu verwenden
Verwenden Sie die boolesche @ISLEV-Funktion anstelle von @LEV und @CURRMBR
Entfernen Sie eingeschränkte Elemente aus dem FIX-Ausdruck
Verwenden Sie "Kopieren", um den Zielblock zu erstellen, wenn der Ankeransatz nicht funktioniert
Die Berechnung wird nur für ein Zielelement der Custom-Dimension durchgeführt
Verwenden Sie @LIKE, um das Skript generisch zu machen
Automatische Erstellung von Blöcken vermeiden
Prüfen Sie, ob es Grenzfälle gibt
Prüfen Sie zuerst auf häufige Fälle.

Best Practices für die Performance

Mehrere Übergaben an Essbase

Jedes Mal, wenn die FIX-Anweisung in einer Regel verwendet wird, löst jeder FIX eine separate Übergabe an die Datenbank aus. Aus Performancegründen wäre es besser, mehrere Übergaben an Essbase durch nicht zu viele separate FIX-Anweisungen zu vermeiden.

Beispiel: Mehrere Übergaben an Essbase

FIX("Entity Currency", "FCCS_Entity Input", …..)
        FIX("FCCS_Data Input", … )
                //Calculations;
        ENDFIX
        
        FIX("FCCS_Other Data", … )
                //Calculations;
        ENDFIX

ENDFIX

Beispiel: Vorgeschlagene Änderungen, um mehrere Übergaben unter Verwendung von IF...ENDIF zu vermeiden

FIX("Entity Currency", ...)
        FIX( @List("FCCS_Data Input", "FCCS_Other Data"), … )
                "FCCS_Entity Input"( @CALCMODE(BOTTOMUP);
                        IF(@ISMBR("FCCS_Data Input")
                                //Calculations for "FCCS_Data Input";
                        ELSE                    
                                //Calculations "FCCS_Other Data";
                        ENDIF   
                )
        ENDFIX
ENDFIX

Beispiel: Vorgeschlagene Änderungen, um mehrere Übergaben unter Verwendung von Elementblöcken zu vermeiden

FIX("Entity Currency", ...)
        FIX( @List("FCCS_Data Input", "FCCS_Other Data"), … )
                "FCCS_Entity Input"( @CALCMODE(BOTTOMUP);
                        IF(@ISMBR("FCCS_Data Input")
                                //Calculations for "FCCS_Data Input";
                        ELSE                    
                                //Calculations "FCCS_Other Data";
                        ENDIF   
                )
        ENDFIX
ENDFIX

Beispiel: Mehrere separate verschachtelte Korrekturbefehle (FIX), die mehrere Übergaben an Essbase zur Folge haben

FIX("FCCS_Elimination")
        FIX("No Movement")
                Fix(@Relative("ICP_Category",0))
                "Custom_Elimination" (
                        "InterSales"="Other_InterAcct"->"FCCS_Intercompany Eliminations";
                )
                ENDFIX  /*Intercompany*/
        ENDFIX  /*Movement*/
 ENDFIX  /*Consolidation*/

Beispiel: Umschreiben, um mehrere Übergaben zu vermeiden

FIX ("FCCS_Elimination",@Relative("ICP_Category A",0), "No Movement")
        "Custom_Elimination" ( @CALCMODE(BOTTOMUP);
                "640102" = "WA_Intercompany Account"->"FCCS_Intercompany Eliminations";
        )
ENDFIX

Schreibvorgänge in eingeschränkte Elemente

Nehmen Sie in diesem Beispiel an, dass Sie "FCCS_Intercompany Eliminations" > "FCCS_Eliminations" > "Mvmts_NewBusiness" in "Data Input" > "FCCS_Eliminations" > "Mvmts Reclass" neu klassifizieren möchten.

Da "FCCS_Intercompany Eliminations" jedoch ein eingeschränktes Element für die Data Source-Dimension ist, wird beim Versuch, eine FIX-Anweisung für dieses Element zu verwenden, ein Fehler zurückgegeben.

Sie können versuchen, die folgenden Anweisungen zu schreiben, mit denen die Top-down-Verarbeitung im System erzwungen wird.

Beispiel: Mit eingeschränkten Elementen unter Verwendung der Top-down-Verarbeitung arbeiten

FIX("Data Input", … ) 
        "FCCS_Elimination" (
                 "Mvmts_Reclass" = -1 * "FCCS_Intercompany Eliminations"->"Mvmts_NewBusiness" ; 
        )               
ENDFIX

Beispiel: Anweisungen zum Verwenden der Bottom-up-Verarbeitung umschreiben

FIX("FCCS_IntercomanyEliminations", "Mvmts_NewBusiness", … )
        "FCCS_Elimination" ( @CALCMODE(BOTTOMUP);
                 "Mvmts_Reclass"->"Data Input" = -1 * "Mvmts_NewBusiness" ; 
        )               
ENDFIX

Beachten Sie, dass in diesem Beispiel eine FIX-Anweisung für "FCCS_Intercompany Eliminations" vorhanden ist, diese jedoch mit "Data Input" im Elementblock überschrieben wird und das System bei der Validierung keinen Fehler zurückgibt.

Basierend auf benutzerdefinierten Attributen Daten für Endsalden eingeben und Bewegungen berechnen

Angenommen, Sie möchten in diesem Beispiel die Eingabe von Endsalden in ein bestimmtes Element der Movement-Dimension verschieben. Sie können eine benutzerdefinierte Berechnung mit den folgenden Anforderungen schreiben:

FIX für Kombinationen von Elementen aus Sparse-Dimensionen für Bottom-up-Verarbeitung. Die Bottom-up-Verarbeitung bezieht sich auf Blöcke, und Sparse-Dimensionen definieren einen Block.
Benutzerdefinierte Attribute (UDAs) werden am besten zusammen mit einer FIX-Anweisung für UDA-Konten verarbeitet, um dieselbe Berechnung auszuführen.
Im folgenden Beispiel wird angenommen, dass alle angegebenen UDAs für die Kontentypen "Aktiva", "Passiva" oder "Eigenkapital" definiert sind.
FIX für Elemente der Ebene 0 für die Account-Dimension, bezogen auf FCCS_Net Income.
Verwenden Sie zur Verbesserung der Performance eine boolesche Funktion, anstatt die Ebene des Elements mit @LEV zu berechnen.
Verwenden Sie die boolesche Funktion @ISDESC, um zu prüfen, ob das Element ein Nachkomme ist. Es ist immer ein Blattelement.

Beispiel: Basierend auf benutzerdefinierten Attributen Daten für Endsalden eingeben und Bewegungen berechnen

Beispiel zu einer konfigurierbaren Berechnung für die Eingabe von Endsalden mit benutzerdefinierten Attributen

Beste Verwendung von IF-Bedingungen

Nachfolgend finden Sie ein allgemeines Beispiel für das Schreiben von bedingten Anweisungen mit IF. In diesem Beispiel möchten Sie eine bestimmte Verarbeitung im Januar vornehmen, in den anderen Monaten jedoch andere Vorgänge durchführen. Wenn die Berechnung wie unten stehend geschrieben ist, führt das System die Prüfung 12 Mal für alle Perioden außer Januar aus, da es immer zuerst den Monat Januar prüft, und fährt anschließend mit der ELSE-Klausel fort.

Beispiel: IF-Anweisung

FIX ("Entity Currency", "FCCS_Entity Input" … )
        "Mvmt_Increase01" ( @CALCMODE(BOTTOMUP);
                IF(@ISMBR("Jan"))
                                "FCCS_ClosingBalance_Input" - @PRIOR("FCCS_ClosingBalance_Input"->                   "Dec", 1, @RELATIVE("Years", 0));
                ELSE
                                "FCCS_ClosingBalance_Input" - "FCCS_TotalOpeningBalance";
                ENDIF
        )
ENDFIX

Beispiel: Umschreiben mit NOT IF

Sie können die IF-Anweisung so umschreiben, dass 11 von 12 Perioden mit der IF-Klausel ausgeführt werden und anschließend den Bedingungszweig verlassen. Nur der Monat Januar wird in der ELSE-Klausel einmalig ausgeführt.

FIX ("Entity Currency", "FCCS_Entity Input", …)         
        "FCCS_ClosingBalance_Input"(@CALCMODE(BOTTOMUP);
        IF (NOT @ISMBR("Jan"))
                "Mvmt_Increase01" = "FCCS_ClosingBalance_Input" - "FCCS_TotalOpeningBalance";
        ELSE
                IF(NOT @ISMBR(@MEMBERAT(@CHILDREN("Years"),1)))
              "Mvmt_Increase01" = "FCCS_ClosingBalance_Input" - "FCCS_ClosingBalance_Input"->"Dec"->            @MEMBER(@PREVSIBLING(@CURRMBR("Years")));
                  ENDIF;
         ENDIF;
        )
ENDFIX

Option "Systemberechnung" für oberste Elemente von Custom-Dimensionen mit erweiterter Dimensionalität verwenden

Für benutzerdefinierte Custom-Dimensionen können Serviceadministratoren auswählen, dass Systemberechnungen mit dem obersten Element der Custom-Dimension anstatt allen Elementen der Ebene 0 verarbeitet werden sollen, um eine bessere Performance zu erzielen. Sie können bestimmte Custom-Dimensionen auswählen, für die die Option gelten soll. Informationen hierzu finden Sie unter Systemberechnungen.

Wenn Sie eine Umgebung mit erweiterter Dimensionalität verwenden und sicherstellen möchten, dass die Performance durch die Verwendung des obersten Elements der Custom-Dimension nicht beeinträchtigt wird, können Sie einen leeren Block für "NoCustomX" am Anfang der Konsolidierung basierend auf den Daten für die Entityeingabe und Entitywährung erstellen und diesen Block zum Ausführen aller Berechnungen verwenden. Beispiel: Wenn in der Custom-Dimension "Product" 1000 benutzerdefinierte Elemente vorhanden sind, können Sie einen Block @"No Product" und eine FIX-Anweisung für "No Product" erstellen und die Bottom-up-Verarbeitung verwenden. Das System muss dann nicht alle 1000 Elemente der Product-Dimension als Schleife durchlaufen, und Sie können die Gesamtzahl für die Product-Dimension als Gesamtwert verwenden, um die Gesamtperformance zu verbessern.

Das folgende Beispiel zeigt ein Beispielberechnungsskript:

Beispiel zu einer konfigurierbaren Berechnung für das oberste Element der Custom-Dimension

FCCS_10 Elementblöcke mit Bottom-up-Verarbeitung berechnen

Verwenden Sie @CALCMODE(BOTTOMUP), und kombinieren Sie Berechnungen von Elementblöcken.
Kombinieren Sie Berechnungen aus mehreren FIX...ENDFIX-Anweisungen in einer einzelnen FIX...ENDFIX-Anweisung, wenn die Elemente in der FIX-Anweisung für alle Berechnungen identisch sind.

Vermeiden Sie eine FIX-Anweisung innerhalb einer anderen FIX-Anweisung, wenn es sich nur um eine einzelne Berechnung handelt.

Die folgenden Beispiele zeigen die Ausführung der Berechnung mit der Top-down-Verarbeitung. Im nachfolgenden geänderten Beispiel wird die Bottom-up-Verarbeitung verwendet, um die Verarbeitung von Abfragen auf der rechten Seite zu verbessern.

Beispiel: FCCS_20 C1_Validation mit Top-down-Verarbeitung ausführen
Beispiel zu einer konfigurierbaren Berechnung C1 mit Top-down-Verarbeitung

Beispiel: FCCS_20 C1_Validation mit Bottom-up-Verarbeitung ausführen

Beispiel zu einer konfigurierbaren Berechnung C1 mit Bottom-up-Verarbeitung

Berechnungsabhängigkeit

Vermeiden Sie Abhängigkeiten zwischen Entitys, wenn Berechnungen in konfigurierbaren Berechnungen (Einfügepunkte) oder On-Demand-Regeln erfolgen. Wenn Sie versuchen, den Wert von Entity A in der Berechnung zu referenzieren, und wenn Entity A noch nicht berechnet wurde, weist Entity A keinen Wert auf.

Beispiel: Wenn Sie versuchen, Daten aus "Entity A" > "ICP_B" > "Entitywährung" (Quelle) in "Entity B" > "ICP_A" > "Entitywährung" (Ziel) neu zu klassifizieren, sind die Daten in Entity A (Quelle) möglicherweise nicht verfügbar, da sie eventuell noch nicht berechnet wurden, wenn sowohl Entity A als auch Entity B gleichzeitig berechnet werden.

In solchen Fällen sollte die Neuklassifizierung durchgeführt werden, indem zuerst Entity A und anschließend die abhängige Entity B berechnet wird.