Mejores prácticas de cálculos configurables

Use estas mejores prácticas al trabajar con cálculos configurables.

Conceptos de cálculo

Estos son los conceptos esenciales para crear cálculos:

  • Bloques de datos

  • Formato de script básico

  • Cálculos ascendentes frente a descendentes

  • Modo de bloque frente a modo de celda

Bloques de datos

En la figura siguiente aparece un bloque de datos de una aplicación de ejemplo.


Bloque de datos de muestra
  • Los miembros almacenados de dimensiones densas constituyen un bloque de datos. El tamaño de bloque de la aplicación de ejemplo anterior es 2 (Sales y Cash) x 8 bytes = 16 bytes.

  • Las combinaciones únicas de miembros de dimensión ligera constituyen índices (INDEX) y apuntan a bloques de datos. En la aplicación de ejemplo anterior, hay un total de 2 (Actual, Budget) x 2 (FY17, FY18) x 2 (Jan, Feb)= 8 índices.


Índice de las reglas de ejemplo

En las bases de datos de opción de almacenamiento de bloques (BSO) de Essbase, un bloque constituye miembros almacenados de una dimensión densa. En Financial Consolidation and Close, de forma predeterminada, Account es la única dimensión densa.

En este ejemplo, la dimensión Account es densa y tiene 1977 miembros almacenados. Esto indica que un solo bloque de consolidación de base de datos BSO tiene 1977 celdas, cada una de las cuales representa un miembro Account.

El tamaño de bloque, en bytes, será:

  • Tamaño de bloque (bytes) = Número de miembros almacenados en Account * 8

  • Tamaño de bloque (bytes) = 1977 * 8 = 15.816 bytes


Ejemplo de propiedades de la base de datos

Nota: Para ver las propiedades de la base de datos, en Calculation Manager, seleccione Acción y, a continuación, Propiedades de la base de datos.

Mejores prácticas para la creación de bloques de datos

Cuando se ejecuta un cálculo configurable que escribe en una celda de datos, debe existir un bloque de datos para que se escriban los datos en la base de datos.

Los bloques de datos son combinaciones de miembros de las dimensiones ligeras y densas almacenadas.

Los bloques de datos separados se han creado para cada combinación de las dimensiones ligeras almacenadas. Los miembros de una dimensión densa constituyen un bloque.

Al crear cálculos configurables, puede que necesite crear bloques adicionales para almacenar los resultados calculados y resolver los problemas con los datos que faltan.

Puede activar la opción Crear automáticamente bloques para que el sistema cree los bloques que faltan de forma automática. Consulte Activación de la creación automática de bloques para cálculos configurables.

Si está utilizando el procesamiento ascendente en sus cálculos configurables, debe crear bloques de datos manualmente o asegurarse de que dichos bloques de datos ya existen.

Puede crear bloques de datos manualmente mediante uno de los siguientes métodos:

  • Asignar los datos durante el proceso de carga de datos. Por ejemplo, escriba un "Cero" en una sola intersección de miembro densa y, a continuación, escriba "#missing" para borrar el "Cero" tras la creación del bloque.


    Script de ejemplo para la creación de bloques
  • Mediante el comando DATACOPY de Essbase, en el que todos los bloques del origen se copian en el destino, incluidas las celdas que faltan. Sin embargo, este método podría crear bloques innecesarios y retrasar el proceso de consolidación.

Cuándo usar bloques de creación automática

Crear automáticamente bloques es un valor proporcionado que permite crear bloques que faltan durante un cálculo configurable.

Esta opción tiene un gran impacto en el rendimiento, porque usa el algoritmo de bloque potencial para buscar en la base de datos completa la presencia de bloques y crea, de la forma necesaria, un bloque que falta si no existe uno.

Utilice solo este valor cuando esté completamente seguro de que ninguna de las otras técnicas de creación de bloques son adecuadas.

La función @CALCMODE(BOTTOMUP) (si se usa en un punto de inserción) y Crear automáticamente bloques se excluyen mutuamente.

Creación de bloques de datos de destino para las funciones @SHIFT y @PRIOR

Cuando se utilizan las funciones @SHIFT o @PRIOR en los scripts de cálculo, deben existir previamente los bloques de datos de destino para poder ejecutar el cálculo. Los bloques de datos de destino deben existir como una parte de otro cálculo o carga de datos, o bien se deben crear mediante la función @CREATEBLOCK.

Ejemplo de caso de uso:

Los datos existen en Real, FY16, P12, ML_HFM. Los datos se extraen de Oracle Hyperion Financial Management y aún no se han cargado en Real, FY16, P1, ML_HFM. Los datos se deben recuperar del periodo P12 del año anterior y se debe reflejar una entrada de reversión en Real, FY17, P1, ML_HFM_Calc.

El script de cálculo es el siguiente:


Ejemplo de script de cálculo de bloque de datos

No se ha contabilizado ningún asiento ("FCCS_Journal Input" en P13. Se espera que el código utilice la siguiente ruta, con "ML_HFM_Calc" como anclaje del miembro ligero:

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

Sin embargo, devuelve #MISSING.

Solución alternativa 1:


Solución alternativa de bloque de datos 1

Solución alternativa 2:


Solución alternativa de bloque de datos 2

Directrices de la regla ClearEmptyBlocks

La regla de negocio ClearEmptyBlocks le ayuda a limpiar del cubo de consolidación los bloques de datos vacíos. Se podrían generar bloques de datos vacíos como parte de:

  • La ejecución de la regla OnDemand que genera bloques vacíos. Por ejemplo, al utilizar la función @CREATEBLOCK, un bloque de datos vacío generado posiblemente nunca se utilice.

  • Un código de punto de inserción (por ejemplo, FCCS_20) que posiblemente tenga pérdidas de bloques debido a cálculos TOPDOWN, puede ser debido a la asignación de valores #MISSING; el uso de fijaciones ligeras, en lugar de al uso de @CALCMODE(BOTTOM UP)

  • Cálculos del sistema de Financial Consolidation and Close

Práctica recomendada para ejecutar la regla ClearEmptyBlocks

  • Una mejor práctica consiste en ejecutar la regla tras finalizar cualquier prueba de punto de inserción/regla de OnDemand, cuando el script esté en fase de desarrollo. La regla ClearEmptyBlocks ayuda a medir las estadísticas de bloques antes y después de la ejecución del cálculo en desarrollo.

  • En la fase de producción, ejecute la regla tras finalizar una consolidación de año completo para un determinado año.

Se podría programar un script de EPM Automate para que se ejecutara después del horario laboral, todos los fines de semana:

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

Nota: La programación de esta actividad debe mantener al menos un intervalo de entre tres y cuatro horas con el ciclo de mantenimiento diario.

Formato de script básico

En la siguiente figura se muestra un formato de script de cálculo de ejemplo.


Formato del script de cálculo

Escritura de cálculos configurables

En la siguiente figura se muestran las reglas de cálculo configurables en el separador Moneda local de Consolidación: proceso.


Ejemplo de la pantalla de cálculos de configuración 1

En la siguiente figura se muestran las reglas de cálculo configurables correspondientes en el separador Moneda local de Consolidación: proceso.


Ejemplo 2 de cálculos configurables

Un cálculo configurable le permite realizar cálculos personalizados que implican tres categorías de datos:

  • Datos no convertidos: Moneda de entidad + (FCCS_Entrada de entidad o FCCS_Consolidación de entidad)

  • Datos convertidos: Moneda padre + (FCCS_Entity Input o FCCS_Entity Consolidation)

  • Datos eliminados: Moneda padre + FCCS_Elimination

Es importante conocer la combinación de moneda y consolidación, para escribir un cálculo configurable en la plantilla de regla de cálculo configurable correcta, también conocido como punto de inserción.

Como ejemplo, se supone que se usa FCCS_30_After Opening Balance Carry Forward_Translated, si y solo si la conversión predeterminada de FCCS y el cálculo de FX ya han procesado los datos que necesitan una atención especial en FCCS_30.

Ejemplos de escritura de cálculos configurables

Tenga en cuenta un ejemplo de un problema de creación de bloques y los distintos enfoques para solucionar el mismo cálculo.

Caso de uso:

  • Agregue valores en dos cuentas: Warehouse_Stock y Showroom_Stock cargadas en FCCS_Managed Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP y No Product

  • Almacenamiento del resultado del cálculo en la cuenta Inventory_Stock de FCCS_Other Data, FCCS_Mvmts_NetIncome, FCCS_Local GAAP y No Product

  • Uso del cálculo configurable FCCS_10

Enfoque 1: Uso del bloque sin miembros (anclaje)

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

Desventajas de este enfoque:

  1. Este es un cálculo denso, teniendo en cuenta que Inventory_Stock es una cuenta en la parte izquierda. Si bien el cálculo se escribe de forma correcta, el resultado no se verá si existe un bloque anterior en FCCS_Other Data y está asociado a otros miembros FIX para incluir el resultado.

  2. No se pueden aplicar restricciones de cálculo condicionales, por ejemplo, IF..ELSE..ENDIF.

  3. Se necesita una solución para introducir manualmente cero bloques de datos en la intersección anterior.

Enfoque 2: Uso del bloque de miembros denso (anclaje)

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

Desventajas de este enfoque:

  1. Este es un cálculo denso, porque el bloque de miembros Inventory_Stock es una cuenta. Si bien el cálculo se escribe de forma correcta, el resultado no se verá si no existe un bloque anterior en FCCS_Other Data y está asociado a otros miembros FIX.

  2. Se necesita una solución para introducir manualmente cero bloques de datos en la intersección anterior.

Enfoque 3: Uso del bloque de miembros ligero (anclaje)

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

Ventaja de este enfoque:

Se trata de un cálculo ligero, porque el bloque de miembros FCCS_Other Data es un origen de datos que es una dimensión ligera. El cálculo produce un bloque.

Desventaja de este enfoque:

El cálculo de bloques de miembros se ejecuta de forma descendente, conforme se usa el operador de dimensión cruzada.

Enfoque 4: Uso del bloque de miembros ligero y del cálculo ascendente

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

Ventajas de este enfoque:

  1. Se trata de un cálculo ligero, porque el bloque de miembros FCCS_Managed Data es un origen de datos, una dimensión ligera.

  2. El cálculo del bloque de miembros ejecuta BottomUp.

  3. FCCS_Managed Data es el origen de este cálculo. El bloque resultante se crea en FCCS_Other Data, si y solo si existe el bloque de datos en el origen.

  4. No se necesita ningún operador de dimensión cruzada en la parte derecha del cálculo.

  5. No es necesario especificar de forma explícita el cálculo como Ascendente, porque existe un operador de dimensión cruzada en la parte izquierda de esta asignación.

Cálculos de modo de bloques frente a modo de celda

  • Modo de bloques: (modo predeterminado) en este modo de cálculo, Essbase agrupa las celdas en un bloque y calcula simultáneamente las celdas de cada grupo.

  • El modo de cálculo de bloques es rápido, pero tiene que tener en cuenta detenidamente las dependencias de datos en el bloque para garantizar que los datos resultantes sean precisos.

  • Modo de celda: en este modo de cálculo, Essbase calcula cada celda de forma secuencial, siguiendo el orden de cálculo, que se basa en el esquema.

  • El modo de cálculo de celda es más lento por motivos obvios. Sin embargo, garantiza la obtención de unos resultados precisos cuando haya dependencias de datos.

  • Cuando Essbase compila una fórmula, imprime un mensaje en el archivo log de la aplicación, donde se explica el modo de ejecución de la fórmula similar al siguiente mensaje:

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

Essbase usa el modo de bloques al calcular una fórmula, a menos que use funciones como:

  • @ANCEST

  • @CURRMBR

  • @ISMBR on a dense member

  • @MDANCESTVAL

  • @MDPARENTVAL

  • @MDSHIFT

  • @NEXT

  • @PARENT

  • @PARENTVAL

  • @PRIOR

  • @SANCESTVAL

  • @SPARENTVAL

  • @SHIFT

  • @XWRITE

Para activar manualmente el modo de bloques, utilice @CALCMODE(BLOCK). Asegúrese de que no haya dependencias de datos en el bloque denso.

Ejemplo de modo de bloques

Realice el siguiente cálculo, basado en el mes:

  • Enero: Sales Synergies es la suma de los hijos de Returns and Allowances
  • Febrero: Sales Synergies es la suma de los hijos de Returns and Allowances multiplicada por el 20%
  • Resto de meses: Sales Synergies es la suma de los hijos de Returns and Allowances multiplicada por el 10%

Modo de bloques

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

Modo de celda frente a modo de bloques forzado

Realice el siguiente cálculo, basado en el mes:

Enero: Sales Synergies es la suma de los hijos de Returns and Allowances

Febrero: Sales Synergies es la suma de los hijos de Returns and Allowances multiplicada por el 20 %

Resto de meses: Sales Synergies es la suma de los hijos de Returns and Allowances más el valor del periodo anterior de Sales Synergies. Multiplique todo el resultado por el 10%.

Modo de celda

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

Modo de bloques

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

Caso de uso del cliente A

  • Nueva clasificación de datos gestionadas cargados desde FDMEE para cuentas de cuenta de resultados en un miembro de origen de datos calculados distinto, en función de los ajustes de asientos

  • El rendimiento ha sido bajo: 180 minutos para un año completo

Cliente A - Ejemplo de script


Caso de uso del cliente A

Cliente A - Mejoras del script

  • Utilice @REMOVE para eliminar Account en lugar de utilizar la comprobación @ISMBR en la dimensión densa Account

  • Procesamiento ascendente

  • Utilice @ISLEV booleano en lugar de @LEV y @CURRMEMBER

  • El rendimiento ha mejorado en un 90%

Caso de uso del cliente B

  • Objetivo: mover los datos de algunas entidades de origen a una entidad de destino

  • Los datos no se estaban calculando

  • El rendimiento ha sido bajo: 3,5 horas

Cliente B - Ejemplo de script


Caso de uso del cliente B

Cliente B - Mejoras del script

  • Uso de Copiar para crear el bloque de destino

  • El cálculo se mantiene como descendente

  • El cálculo solo se debe realizar en un miembro de la dimensión Custom de destino

  • Utilice @LIKE para crear el script genérico

  • La duración se reduce de 3,5 horas a unos pocos minutos

Caso de uso del cliente C

  • Nueva clasificación de movimientos basada en FCCS_Closing_Balance_Input introducidos mediante la interfaz de usuario

  • El rendimiento ha sido bajo: 15 minutos


Caso de uso del cliente C

Cliente C - Ejemplo de script (continuación)


Caso de uso del cliente C (continuación)

Cliente C - Mejoras del script

  • Elimine los miembros restringidos de FIX

  • Procesamiento ascendente

  • Compruebe los casos de posición

  • Compruebe primero los casos comunes

  • El rendimiento ha mejorado en un 40%

Caso de uso del cliente D

  • Vuelva a clasificar los datos extraídos de Hyperion Financial Management, el origen de datos ML_HFM y almacénelos en el miembro de origen de datos ML_HFM_Calc

  • El rendimiento ha sido bajo: 24 horas para un solo periodo

  • Los datos no eran los previstos, ya que los bloques no se estaban creando según lo previsto

Cliente D - Ejemplo de script


Caso de uso del cliente D

Caso de uso del cliente D (continuación)

Cliente D - Mejoras del script

  • Utilice @REMOVE para eliminar Account en lugar de utilizar la comprobación @ISMBR en la dimensión densa Account

  • Procesamiento ascendente

  • Utilice @ISLEV booleano en lugar de @LEV y @CURRMEMBER

  • El rendimiento ha mejorado en un 90%

Caso de uso del cliente E

  • El método de consolidación ha cambiado en el periodo actual, con lo que se deseaba eliminar todos los tratamientos de eliminación y CTA acumulativos de los periodos anteriores

  • El rendimiento ha sido bajo: 90 minutos


Caso de uso del cliente E

Cliente E - Mejoras del script

  • Utilice Data_Input en el destino para evitar el error de validación sobre la escritura en FCCS_Intercompany_Eliminations

  • Utilice Ascendente en los miembros ICP de recorrido con una entrada de balance de cierre

  • La duración se reduce de 90 minutos a 11 minutos

Resumen de mejores prácticas

  • Procesamiento ascendente

  • Utilice @REMOVE para eliminar Account en lugar de utilizar la comprobación @ISMBR en la dimensión densa Account

  • Utilice @ISLEV booleano en lugar de @LEV y @CURRMBR

  • Elimine los miembros restringidos de FIX

  • Utilice Copy para crear los bloques de destino si no funciona el enfoque de anclaje

  • El cálculo solo se debe realizar en un miembro de la dimensión Custom de destino

  • Utilice @LIKE para crear el script genérico

  • Evite la creación de bloques automáticos

  • Compruebe los casos de posición

  • Compruebe primero los casos comunes

Mejores prácticas para el rendimiento

Varias pasadas a Essbase

Cuando se utiliza la sentencia FIX en una regla, cada FIX dispara una pasada distinta a la base de datos. Por razones de rendimiento, sería mejor evitar varias pasadas a Essbase, no incluyendo demasiadas sentencias FIX distintas.

Ejemplo - Varias pasadas a Essbase

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

ENDFIX

Ejemplo: Cambios sugeridos para evitar varias pasadas con 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

Ejemplo: Cambios sugeridos para evitar varias pasadas con bloques de miembros

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

Ejemplo: Varias sentencias FIX anidadas distintas que provocan varias pasadas en 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*/

Ejemplo: Reescritura para evitar varias pasadas

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

Escritura en miembros restringidos

En este ejemplo, supongamos que quiere volver a clasificar "FCCS_Eliminaciones intercompañía" > "FCCS_Eliminaciones" > "Mvmts_NuevaEmpresa" a "Entrada de datos" > "FCCS_Eliminaciones" > "Reclasificación de Mvmts".

Sin embargo, como "FCCS_Eliminaciones intercompañía" es un miembro restringido para la dimensión Origen de datos, si intenta utilizar FIX en este miembro, el sistema devolverá un error.

Puede escribir las siguientes sentencias para que el sistema utilice el procesamiento descendente.

Ejemplo: Trabajar con miembros restringidos al usar el procesamiento descendente

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

Ejemplo: Reescritura de las sentencias con el procesamiento ascendente

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

En este ejemplo, tiene FIX en "FCCS_Eliminaciones intercompañía", pero lo reemplaza por "Entrada de datos" en el bloque de miembros, y el sistema no devolverá un error durante la validación.

Introducción de datos en la entrada del balance de cierre y cálculo de movimientos basados en atributos definidos por el usuario

En este ejemplo, suponga que desea mover la entrada del balance de cierre a un miembro de movimiento específico. Podría escribir un cálculo personalizado con estos requisitos:

  • Elemento FIX en combinaciones de miembros de dimensiones ligeras de forma conjunta para el procesamiento ascendente. El procesamiento ascendente está relacionado con los bloques, y las dimensiones ligeras definen un bloque.

  • Los atributos definidos por el usuario (UDA) se procesan mejor conjuntamente con un elemento FIX en las cuentas de atributos definidos por el usuario para realizar el mismo cálculo.

  • En el ejemplo siguiente se asume que todos los atributos definidos por el usuario que se hayan especificado se definen en los tipos de cuenta ACTIVO/PASIVO/PATRIMONIO.

  • Elemento FIX en miembros de dimensión Cuenta de nivel cero en relación con FCCS_Ingresos netos

  • Use una función booleana en lugar de calcular el nivel del miembro con @LEV para la mejora del rendimiento

  • Use la función booleana @ISDESC para comprobar si el miembro es un descendiente. Siempre será un miembro hoja.

Ejemplo: Introducción de datos en la entrada del balance de cierre y cálculo de movimientos basados en atributos definidos por el usuario


Ejemplo de cálculo configurable para la entrada de balance de cierre con atributos definidos por el usuario

La mejor forma de utilizar la condición IF

A continuación se muestra un ejemplo común de la escritura de sentencias condicionales con IF. En este ejemplo, desea realizar un proceso específico en enero, pero el resto de meses quiere hacer algo diferente. Si el cálculo se escribe como se muestra a continuación, el sistema realizará la comprobación 12 veces para todos los periodos que no sean enero, ya que siempre comprobará enero en primer lugar y, a continuación, deriva a la cláusula ELSE.

Ejemplo: Sentencia 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

Ejemplo: Reescritura con NOT IF

Puede reescribir la sentencia IF para que 11 de 12 periodos se ejecuten con la cláusula IF y salgan de la rama condicional. Enero solo se ejecutará una vez en la cláusula 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

Uso de la opción de cálculo del sistema de miembro personalizado superior con dimensionalidad ampliada

En el caso de dimensiones personalizadas definidas por el usuario, los administradores del servicio pueden optar por procesar cálculos del sistema con el miembro superior de la dimensión personalizada, en lugar de con todos los miembros de nivel 0, para conseguir un rendimiento más rápido. Puede seleccionar dimensiones personalizadas específicas para las que se aplicaría la opción. Consulte Cálculos del sistema.

Si está utilizando un entorno de dimensionalidad ampliada, para asegurarse de que el uso del miembro superior personalizado no ralentice el rendimiento, puede crear un bloque vacío en "NoCustomX" al principio de la consolidación en función de los datos de Entrada de entidades y Moneda de entidad, y usar ese bloque para realizar todos los cálculos. Por ejemplo, si tiene 1000 miembros personalizados en la dimensión personalizada del producto, puede crear un bloque @"Sin producto", FIX en "Sin producto" y usar el procesamiento ascendente. Tras esto, el sistema no tiene que pasar por los 1000 miembros de la dimensión Producto, y puede usar "Total de producto" para el valor total para mejorar el rendimiento general.

En el ejemplo siguiente se muestra un script de cálculo de ejemplo:


Ejemplo de cálculo configurable para el miembro superior personalizado

Cálculo de bloques de miembros FCCS_10 con procesamiento ascendente

  1. Use @CALCMODE(BOTTOMUP) y combine los cálculos de bloques de miembros.

  2. Combine los cálculos en varios FIX...ENDFIX en un solo FIX...ENDFIX si los miembros FIX son iguales en todos los cálculos.

    Evite FIX en FIX si es simplemente un cálculo único.

En los siguientes ejemplos se muestra la ejecución del cálculo con el procesamiento descendente y, a continuación, un ejemplo modificado con el procesamiento ascendente para mejorar el procesamiento de consultas en el lado derecho.

Ejemplo: Ejecución de FCCS_20 C1_Validation con procesamiento descendente
Ejemplo de cálculo configurable C1 descendente

Ejemplo: Ejecución de FCCS_20 C1_Validation con procesamiento descendente


Ejemplo de cálculo configurable C1 ascendente

Dependencia de cálculos

Debe evitar las dependencias entre las entidades cuando se realicen cálculos en cálculos configurables (puntos de inserción) y reglas a petición. Si intenta hacer referencia al valor de la Entidad A en el cálculo y si la Entidad A aún no se ha calculado, la Entidad A no tendría ningún valor.

Por ejemplo, si intenta volver a clasificar datos de "Entidad A" > "ICP_B" > "Moneda de entidad" (origen) a "Entidad B" > "ICP_A" > "Moneda de entidad" (destino), puede que los datos de Entidad A (origen) no estén disponibles, ya que puede que no se hayan calculado, debido a que la Entidad A y la Entidad B se calculan en paralelo.

En estos casos, la reclasificación se debe intentar en primer lugar calculando la Entidad A y, a continuación, la Entidad B dependiente.