Meilleures pratiques de calculs configurables

Suivez ces meilleures pratiques lors de l'utilisation de calculs configurables.

Concepts de calcul

Voici les concepts essentiels pour la création de calculs :

  • Blocs de données

  • Format de script de base

  • Calculs ascendants ou descendants

  • Mode bloc et mode cellule

Blocs de données

La figure suivante représente un bloc de données tiré d'un exemple d'application.


Exemple de bloc de données

  • Les membres stockés de dimensions denses constituent un bloc de données. La taille de bloc pour l'exemple d'application ci-dessus est de 2 (Sales et Cash) x 8 octets = 16 octets.

  • Les combinaisons uniques de membres de dimensions dispersées constituent des index et pointent vers des blocs de données. Dans l'exemple d'application ci-dessus, il existe au total 2 (Actual, Budget) x 2 (FY17, FY18) x 2 (Jan, Feb)= 8 index.


Exemple d'index de règles

Dans les bases de données Essbase Block Storage Option (BSO), un bloc se compose des membres stockés d'une dimension dense. Dans Financial Consolidation and Close, par défaut, Compte est la seule dimension dense.

Dans cet exemple, la dimension Compte est dense et a 1 977 membres stockés. Cela indique qu'un seul bloc de consolidation de base de données BSO dispose de 1 977 cellules, chacune représentant un membre Compte.

La taille du bloc sera la suivante (en octets) :

  • Taille du bloc (octets) = nombre de membres stockés dans Compte * 8

  • Taille du bloc (octets) = 1 977 * 8 = 15 816 octets


Exemple de propriétés de base de données

Remarque : pour afficher les propriétés de base de données, à partir de Calculation Manager, sélectionnez Action, puis Propriétés de base de données.

Meilleures pratiques pour la création de blocs de données

Lorsqu'un calcul configurable qui écrit vers une cellule de données est exécuté, un bloc de données doit exister pour que les données puissent être écrites dans la base de données.

Les blocs de données sont des combinaisons de membres de dimensions dispersées et denses qui sont stockées.

Des blocs de données séparés sont créés pour chaque combinaison de dimensions dispersées stockées. Les membres d'une dimension dense constituent un bloc.

Lorsque vous créez des calculs configurables, vous devez peut-être créer des blocs supplémentaires pour stocker les résultats calculés et résoudre les problèmes de données manquantes.

Vous pouvez activer l'option Créer automatiquement des blocs pour que le système crée automatiquement les blocs manquants. Reportez-vous à la section Activation de l'option Créer automatiquement des blocs pour les calculs configurables.

Si vous utilisez un traitement ascendant dans vos calculs configurables, vous devez créer manuellement des blocs de données ou vérifier que ces blocs de données existent déjà.

Vous devez créer manuellement des blocs de données à l'aide de l'une des méthodes suivantes :

  • Affectation des données pendant le processus de chargement des données. Par exemple, écrivez un "zéro" sur une intersection de membre dense unique, puis écrivez "#missing" pour effacer ce "zéro" après la création du bloc.


    Exemple de script pour la création de blocs

  • A l'aide de la commande DATACOPY d'Essbase, dans laquelle tous les blocs de la source sont copiés vers la destination, y compris les cellules manquantes. Cette méthode peut cependant créer des blocs non nécessaires et ralentir le processus de consolidation.

Quand utiliser l'option Créer automatiquement des blocs

L'option Créer automatiquement des blocs permet de créer des blocs manquants durant un calcul configurable.

Ce paramètre a un impact important sur les performances car il utilise un algorithme de blocs potentiels pour rechercher des blocs sur la totalité de la base de données, et crée un bloc s'il en manque.

Utilisez ce paramètre uniquement si vous êtes sûr qu'aucune autre technique de création de blocs n'est appropriée.

La fonction @CALCMODE(BOTTOMUP) (si utilisée dans un point d'insertion) et l'option Créer automatiquement des blocs s'excluent mutuellement.

Création de blocs de données cible pour les fonctions @SHIFT et @PRIOR

Lorsque vous utilisez la fonction @SHIFT ou @PRIOR dans des scripts de calcul, les blocs de données cible doivent exister pour que vous puissiez exécuter le calcul. Les blocs de données cible doivent exister dans le cadre d'un autre calcul ou chargement de données, ou être créés à l'aide de la fonction @CREATEBLOCK.

Exemple de cas d'utilisation :

Des données existent dans Actual, FY16, P12, ML_HFM. Les données sont extraites d'Oracle Hyperion Financial Management et n'ont pas été chargées dans Actual, FY16, P1, ML_HFM. Les données doivent être extraites de la période P12 de l'année précédente et une entrée d'extourne doit être affichée au niveau d'Actual, FY17, P1, ML_HFM_Calc.

Le script de calcul est le suivant :


Blocs de données - Exemple de script de calcul

Aucun journal n'a été imputé ("FCCS_Journal Input" dans P13). Le code doit utiliser le chemin suivant, "ML_HFM_Calc" étant l'ancrage de membre dispersé :

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

Ce dernier renvoie toutefois #MISSING.

Solution de contournement 1 :


Blocs de données - Solution de contournement 1

Solution de contournement 2 :


Blocs de données - Solution de contournement 2

Directives relatives à la règle ClearEmptyBlocks

La règle métier ClearEmptyBlocks permet de trouver les blocs de données vides dans le cube de consolidation. Les blocs de données vides peuvent être générés dans le cadre :

  • de l'exécution de la règle OnDemand qui génère des blocs vides (par exemple, avec la fonction @CREATEBLOCK, puis éventuellement un bloc de données qui n'a jamais été utilisé) ;

  • d'un code de point d'insertion (par exemple, FCCS_20) qui peut présenter des fuites de blocs dus à des calculs TOPDOWN, du fait éventuellement de l'assignation de #MISSING ; utilisation d'ancrages dispersés, au lieu de @CALCMODE(BOTTOM UP) ;

  • de calculs système Financial Consolidation and Close.

Pratique recommandée pour l'exécution de la règle ClearEmptyBlocks

  • Une meilleure pratique consiste à exécuter la règle après les tests de la règle OnDemand/du point d'insertion, lorsque le script est en phase de développement. La règle ClearEmptyBlocks permet de mesurer les statistiques des blocs avant et après l'exécution du calcul en phase de développement.

  • En phase de production, exécutez la règle après avoir terminé la consolidation d'une année complète pour une année donnée.

Un script EPM Automate peut être planifié pour fonctionner en dehors des heures de bureau, tous les week-ends :

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

Remarque : l'échéancier de cette activité doit maintenir un écart d'au moins trois à quatre heures avec le cycle de maintenance quotidien.

Format de script de base

La figure suivante illustre un exemple de format de script de calcul.


Format de script de calcul

Ecriture de calculs configurables

La figure suivante présente les règles de calcul configurable sur l'onglet Devise locale de Processus de consolidation.


Exemple d'écran de calculs configurables 1

La figure suivante présente les règles de calcul configurable correspondantes de l'onglet Devise locale de Processus de consolidation.


Exemple de calcul configurable 2

Un calcul configurable vous permet d'effectuer des calculs personnalisés avec trois catégories de données :

  • Données non converties : devise d'entité + (FCCS_Entity Input ou FCCS_Entity Consolidation)

  • Données converties : devise parent + (FCCS_Entity Input ou FCCS_Entity Consolidation)

  • Données éliminées : devise parent + FCCS_Elimination

Il est important de comprendre la combinaison de devise et de consolidation afin d'écrire un calcul configurable au sein du modèle correct de règle de calcul configurable, également connu en tant que point d'insertion.

Par exemple, FCCS_30_After Opening Balance Carry Forward_Translated doit être utilisé uniquement si la conversion par défaut FCCS et le calcul d'opération de change ont déjà traité les données qui ont besoin d'une attention particulière dans FCCS_30.

Exemples d'écriture de calculs configurables

Prenons un exemple de problème de création de blocs et les différentes approches pour résoudre ce même calcul.

Cas d'utilisation :

  • Ajoutez des valeurs à deux comptes : Warehouse_Stock et Showroom_Stock chargés dans FCCS_Managed Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP et No Product

  • Stockez le résultat du calcul dans le compte Inventory_Stock dans FCCS_Other Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP et No Product

  • Utilisez le calcul configurable FCCS_10

Approche 1 : sans bloc de membres (ancrage)

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

Inconvénients de cette approche :

  1. Il s'agit d'un calcul dense, étant donné qu'Inventory_Stock est un compte sur le côté gauche. Bien que le calcul soit bien écrit, le résultat ne sera pas visible si aucun bloc précédent n'existe au niveau de FCCS_Other Data et d'autres membres FIX associés pour contenir le résultat.

  2. Il est impossible d'appliquer des restrictions de calcul conditionnelles, par exemple, IF..ELSE..ENDIF.

  3. Une solution de contournement est requise pour introduire manuellement des blocs de données égales à zéro à au croisement au-dessus.

Approche 2 : utilisation d'un bloc de membres denses (ancrage)

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

Inconvénients de cette approche :

  1. Il s'agit d'un calcul dense car le bloc de membres Inventory_Stock est un compte. Bien que le calcul soit bien écrit, le résultat ne sera pas visible si aucun bloc précédent n'existe au niveau de FCCS_Other Data et d'autres membres FIX associés.

  2. Une solution de contournement est requise pour introduire manuellement des blocs de données égales à zéro à au croisement au-dessus.

Approche 3 : utilisation d'un bloc de membres dispersés (ancrage)

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

Avantage de cette approche :

Il s'agit d'un calcul dispersé car le bloc de membres FCCS_Other Data est la source de données, qui est une dimension dispersée. Le calcul génère un bloc.

Inconvénient de cette approche :

Le calcul de bloc de membres s'effectue de manière descendante car un opérateur inter-dimensionnel est utilisé.

Approche 4 : utilisation d'un bloc de membres dispersés et du calcul ascendant

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

Avantages de cette approche :

  1. Il s'agit d'un calcul dispersé car le bloc de membres FCCS_Managed Data est la source de données, une dimension dispersée.

  2. Le calcul de bloc de membres s'effectue de manière ascendante.

  3. FCCS_Managed Data est la source de ce calcul. Le bloc en résultant est créé au niveau de FCCS_Other Data uniquement si le bloc de données existe à la source.

  4. Aucun opérateur inter-dimensionnel n'est requis sur le côté droit du calcul.

  5. Il faut indiquer explicitement que le calcul est ascendant car il existe un opérateur inter-dimensionnel sur le côté gauche de cette affectation.

Calculs en mode cellule ou en mode bloc

  • Mode bloc : (mode par défaut) dans ce mode de calcul, Essbase regroupe les cellules dans un bloc et les calcule simultanément dans chaque groupe.

  • Ce mode de calcul est rapide, mais vous devez bien tenir compte des dépendances de données au sein du bloc afin que le résultat soit correct.

  • Mode cellule : dans ce mode de calcul, Essbase calcule chaque cellule de manière séquentielle, en suivant l'ordre de calcul basé sur l'outline.

  • Ce mode de calcul est plus lent, pour des raisons évidentes. Toutefois, il permet d'obtenir des résultats précis, notamment lorsqu'il existe des dépendances de données.

  • Lorsqu'Essbase compile une formule, un message est imprimé dans le fichier journal de l'application pour expliquer le mode d'exécution de la formule. Ce message s'apparente au message suivant :

    Formula on member Profit % will be executed in CELL and TOPDOWN mode.

Essbase utilise le mode bloc lors du calcul d'une formule, sauf si des fonctions telles que les suivantes sont utilisées :

  • @ANCEST

  • @CURRMBR

  • @ISMBR on a dense member

  • @MDANCESTVAL

  • @MDPARENTVAL

  • @MDSHIFT

  • @NEXT

  • @PARENT

  • @PARENTVAL

  • @PRIOR

  • @SANCESTVAL

  • @SPARENTVAL

  • @SHIFT

  • @XWRITE

Pour déclencher manuellement le mode bloc, utilisez @CALCMODE(BLOCK). Vérifiez qu'il n'y a aucune dépendance de données au sein du bloc dense.

Exemple de mode bloc

Effectuez le calcul suivant, selon le mois :

  • Janvier : Sales Synergies est la somme des enfants de Returns and Allowances
  • Février : Sales Synergies est la somme des enfants de Returns and Allowances . Multipliez cette valeur par 20 %.
  • Mois restants : Sales Synergies est la somme des enfants de Returns and Allowances. Multipliez cette valeur par 10 %.

Mode bloc

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

Mode cellule ou mode bloc déclenché

Effectuez le calcul suivant, selon le mois :

Janvier : Sales Synergies est la somme des enfants de Returns and Allowances

Février : Sales Synergies est la somme des enfants de Returns and Allowances. Multipliez cette valeur par 20 %.

Mois restants : Sales Synergies est la somme des enfants de Returns and Allowances ajoutée à la valeur Sales Synergies de la période précédente. Multipliez le résultat total par 10 %.

Mode cellule

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

Mode bloc

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

Cas d'utilisation du client A

  • Reclassez les données gérées à partir de FDMEE pour les comptes de résultat vers un autre membre de source de données calculé, en fonction des écritures de retraitement

  • Les performances étaient altérées : 180 minutes pour une année entière

Client A : exemple de script


Cas d'utilisation du client A

Client A : améliorations du script

  • Plutôt que d'utiliser la vérification @ISMBR sur la dimension dense Compte, utilisez @REMOVE pour enlever le compte

  • Traitement ascendant

  • Utilisez la fonction booléenne @ISLEV au lieu de @LEV et @CURRMEMBER

  • Les performances ont été améliorées de 90 %

Cas d'utilisation du client B

  • Objectif : déplacer les données de certaines entités source vers une entité cible

  • Les données n'étaient pas calculées

  • Les performances étaient altérées : 3,5 heures

Client B : exemple de script


Cas d'utilisation du client B

Client B : améliorations du script

  • Utilisez la fonction de copie pour créer le bloc cible

  • Le calcul reste descendant

  • Le calcul n'est effectué que pour un membre de dimension libre cible

  • Utilisez @LIKE pour rendre le script générique

  • Délai réduit de 3,5 heures à quelques minutes

Cas d'utilisation du client C

  • Reclassez les mouvements en fonction de la valeur FCCS_Closing_Balance_Input saisie via l'interface utilisateur

  • Les performances étaient altérées : 15 minutes


Cas d'utilisation du client C

Client C : suite de l'exemple de script


Suite du cas d'utilisation du client C

Client C : améliorations du script

  • Enlevez les membres restreints de l'instruction FIX

  • Traitement ascendant

  • Recherchez les exceptions

  • Recherchez d'abord les cas courants.

  • Les performances ont été améliorées de 40 %

Cas d'utilisation du client D

  • Reclassez les données extraites de Hyperion Financial Management, avec la source de données ML_HFM, et stockez ces données au niveau du membre de source de données ML_HFM_Calc

  • Les performances étaient altérées : 24 heures pour une seule période

  • Les données n'étaient pas liées car les blocs n'étaient pas créés comme prévu

Client D : exemple de script


Cas d'utilisation du client D

Suite du cas d'utilisation du client D

Client D : améliorations du script

  • Plutôt que d'utiliser la vérification @ISMBR sur la dimension dense Compte, utilisez @REMOVE pour enlever le compte

  • Traitement ascendant

  • Utilisez la fonction booléenne @ISLEV au lieu de @LEV et @CURRMEMBER

  • Les performances ont été améliorées de 90 %

Cas d'utilisation du client E

  • La méthode de consolidation a évolué dans la période en cours, l'ensemble des traitements d'élimination et d'ajustement de la conversion cumulée des périodes précédentes doivent être supprimés

  • Les performances étaient altérées : 90 minutes


Cas d'utilisation du client E

Client E : améliorations du script

  • Utilisez Data_Input dans la cible pour éviter l'erreur de validation concernant l'écriture dans FCCS_Intercompany_Eliminations

  • Utilisez le traitement ascendant sur les membres ICP de parcours avec une entrée de solde de clôture

  • Délai réduit de 90 minutes à 11 minutes

Récapitulatif des meilleures pratiques

  • Traitement ascendant

  • Plutôt que d'utiliser la vérification @ISMBR sur la dimension dense Compte, utilisez @REMOVE pour enlever le compte

  • Utilisez la fonction booléenne @ISLEV au lieu de @LEV et @CURRMBR

  • Enlevez les membres restreints de l'instruction FIX

  • Utilisez l'option Copier pour créer le bloc cible si l'approche d'ancrage ne fonctionne pas

  • Le calcul n'est effectué que pour un membre de dimension libre cible

  • Utilisez @LIKE pour rendre le script générique

  • Evitez la création de blocs automatiques

  • Recherchez les exceptions

  • Recherchez d'abord les cas courants.

Meilleures pratiques pour les performances

Plusieurs passes dans Essbase

Chaque fois que l'instruction FIX est utilisée dans une règle, elle déclenche une passe distincte dans la base de données. Pour des raisons de performances, évitez les passes multiples dans Essbase en n'incluant pas trop d'instructions FIX distinctes.

Exemple : plusieurs passes dans Essbase

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

ENDFIX

Exemple : modifications suggérées pour éviter plusieurs passes à l'aide de IF...ENDIF

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

Exemple : modifications suggérées pour éviter plusieurs passes à l'aide de blocs de membres

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

Exemple : plusieurs instructions FIX imbriquées distinctes entraînant plusieurs passes dans Essbase

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*/

Exemple : réécriture pour éviter plusieurs passes

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

Ecriture dans les membres restreints

Dans cet exemple, supposons que vous souhaitez reclasser "FCCS_Intercompany Eliminations" > "FCCS_Eliminations" > "Mvmts_NewBusiness" en "Data Input" > "FCCS_Eliminations" > "Mvmts Reclass."

Cependant, étant donné que "FCCS_Intercompany Eliminations" est un membre restreint de la dimension de source de données, si vous essayez d'utiliser une instruction FIX sur ce membre, le système renvoie une erreur.

Vous pouvez essayer d'écrire les instructions suivantes qui forcent le système à utiliser le traitement descendant.

Exemple : utilisation des membres restreints avec le traitement descendant

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

Exemple : réécriture des instructions avec le traitement ascendant

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

Dans cet exemple, vous avez une instruction FIX sur "FCCS_Intercompany Eliminations", mais vous l'avez remplacée par "Data Input" dans le bloc de membres, et le système ne renverra pas d'erreur lors de la validation.

Saisie de données dans l'entrée du solde de clôture et calcul des mouvements basés sur les UDA

Dans cet exemple, supposez que vous voulez déplacer l'entrée du solde de clôture dans un membre de mouvement spécifique. Vous pouvez écrire un calcul personnalisé avec les exigences suivantes :

  • Instruction FIX sur les combinaisons associées de membres de dimensions dispersées pour le traitement ascendant. Le traitement ascendant est associé aux blocs et les dimensions dispersées définissent un bloc.

  • Les attributs définis par l'utilisateur sont mieux traités ensemble avec une instruction FIX sur les comptes UDA, pour effectuer le même calcul.

  • L'exemple ci-dessous suppose que tous les UDA indiqués soient définis sur des types de compte ASSET/LIABILITY/EQUITY.

  • Instruction FIX sur les membres de dimensions de compte de niveau zéro relatifs à FCCS_Net Income

  • Utilisez une fonction booléenne au lieu de calculer le niveau du membre avec @LEV pour améliorer les performances

  • Utilisez une fonction booléenne @ISDESC pour vérifier si le membre est un descendant. Il s'agira toujours d'un membre feuille.

Exemple : Saisie de données dans l'entrée du solde de clôture et calcul des mouvements basés sur les UDA


Exemple de calcul configurable pour l'entrée du solde de clôture à l'aide des UDA

Meilleure façon d'utiliser la condition IF

Vous trouverez ci-dessous un exemple commun d'écriture d'instructions conditionnelles avec IF. Dans cet exemple, vous souhaitez réaliser un processus particulier pour janvier, mais effectuer une autre opération pour les autres mois. Si le calcul est écrit comme ci-dessous, le système effectuera 12 fois la vérification de toutes les périodes autres que janvier, dans la mesure où il vérifie toujours janvier en premier, puis se ramifie vers la clause ELSE.

Exemple : Instruction IF

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

Exemple : Réécriture à l'aide de NOT IF

Vous pouvez réécrire l'instruction IF de sorte que 11 périodes sur 12 s'exécutent avec la clause IF, puis abandonner le branchement conditionnel. Seul janvier sera exécuté une fois dans la clause ELSE.

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

Utilisation de l'option de calcul système du membre libre supérieur avec la dimensionnalité étendue

Pour les dimensions libres définies par l'utilisateur, les administrateurs de service peuvent choisir d'effectuer les calculs système à l'aide du membre supérieur de la dimension libre, au lieu de tous les membres de niveau 0, pour obtenir des performances plus rapides. Vous pouvez sélectionner des dimensions libres spécifiques pour lesquelles l'option s'applique. Reportez-vous à la section Calculs système.

Si vous utilisez un environnement de dimensionnalité étendue, afin de vous assurer que le membre libre supérieur ne ralentit pas les performances, vous pouvez créer un bloc vide à "NoCustomX" au début de la consolidation basée sur les données Entrée d'entité et Devise d'entité, et utiliser ce bloc pour effectuer tous les calculs. Par exemple, si vous possédez 1 000 membres libres dans la dimension libre Produit, vous pouvez créer un bloc @"No Product", avec une instruction FIX sur "No Product", et utiliser le traitement ascendant. Le système n'a pas besoin de parcourir la totalité des 1 000 membres de la dimension Produit et vous pouvez utiliser "Total du produit" pour la valeur totale afin d'améliorer les performances globales.

L'exemple suivant illustre un exemple de script de calcul :


Exemple de calcul configurable pour le membre libre supérieur

Calcul des blocs de membre FCCS_10 à l'aide du traitement ascendant

  1. Utilisez @CALCMODE(BOTTOMUP) et combinez les calculs de blocs de membres.

  2. Combinez les calculs dans plusieurs FIX...ENDFIX en un seul FIX...ENDFIX, si les membres FIX sont les mêmes dans les différents calculs.

    Evitez d'utiliser une instruction FIX dans une instruction FIX, s'il s'agit d'un calcul unique.

Les exemples suivants illustrent l'exécution des calculs à l'aide d'un traitement descendant, puis un exemple modifié avec le traitement ascendant afin d'améliorer le traitement des requêtes sur le côté droit.

Exemple : Exécution FCCS_20 C1_Validation à l'aide d'un traitement descendant
Exemple de calcul configurable C1 avec traitement descendant

Exemple : Exécution FCCS_20 C1_Validation à l'aide d'un traitement ascendant


Exemple de calcul configurable C1 avec traitement ascendant

Dépendance de calcul

Vous devez éviter les dépendances entre entités lorsque des calculs sont effectués dans des calculs configurables (points d'insertion) et des règles à la demande. Si vous essayez de référencer la valeur de l'entité A dans le calcul mais que cette dernière n'a pas encore été calculée, elle n'aura aucune valeur.

Par exemple, si vous essayez de reclasser les données pour "Entité A" > "ICP_B" > "Devise d'entité" (source) en "Entité B" > "ICP_A" > "Devise d'entité" (destination), les données dans l'entité A (source) peuvent ne pas être disponibles dans la mesure où elle n'a peut-être pas été calculée, puisque les entités A et B sont calculées en parallèle.

Dans de tels cas, la reclassification doit être effectuée en calculant d'abord l'entité A puis l'entité B dépendante.