«Jerarquías basadas en el tiempo» de SAP BPC, un motivo más para cuando se diseñe informes no recurrir a otras herramientas

Las jerarquías basadas en el tiempo (Time-dependent Hierarchy – TDH) es un buen motivo para valorar un poco más el reporting utilizando los recursos propios de SAP BPC 10.0 (SAP Business Planning and Consolidation y SAP EPM Add-in for MS). A través de esta nueva funcionalidad incorporada a partir de la actualización SP9, los usuarios podrán elegir la versión de jerarquía a emplear cuando visualicen la información, siempre y cuando, las dimensiones de interés (dato maestro) estén configuradas para este fin.


Las jerarquías basadas en el tiempo (Time-dependent Hierarchy – TDH) es un buen motivo para valorar un poco más el reporting utilizando los recursos propios de SAP BPC 10.0 (SAP Business Planning and Consolidation y SAP EPM Add-in for MS).  A través de esta nueva funcionalidad incorporada a partir de la actualización SP9, los usuarios podrán elegir la versión de jerarquía a emplear cuando visualicen la información, siempre y cuando, las dimensiones de interés (dato maestro) estén configuradas para este fin.

Hasta ahora, para una dimensión BPC podemos tener más de una jerarquía (*), el criterio para definir una nueva jerarquía es si la estructura o enfoque es distinto a cualquiera otra jerarquía que existe actualmente, por ejemplo, para una dimensión que almacena sociedades de una organización (tipo Entity) podríamos tener una jerarquía por países y otra por tipo de servicio ofrecido.  Si las jerarquías varían en su contenido, por agregar o retirar elementos o nodos, perdíamos las “fotos” anteriores y sólo se contaba con la posibilidad de visualizar la “instantánea” actual.  Las “Jerarquías basadas en el tiempo” es la respuesta para contar con las diferentes “fotografías” que pueden llegar a tener esta estructura para ordenar los miembros de dimensión.

Antes de la versión 10.0 SP9 si se deseaba tener una versión anterior de una jerarquía se podría tener una copia de la misma, pero no resultaba una buena solución porque redunda en una pérdida de rendimiento de la plataforma.

Sugerimos la revisión de las siguientes notas (se requiere usuario y contraseña de SAP Marketplace): 1799271, 1826484, 1824985, 1874053  y post relacionado.

(*) Nota: Hasta la versión 10.0 SP4 el límite máximo de jerarquías permitidas por dimensión era 35 (ref. 1619013), versiones posteriores el límite es de 100 aproximadamente (Ref. 1565985), este número depende del  número y tamaño de las propiedades o atributos de cada dimensión.

VBA for SAP EPM Add-in: No olvides «comprimir» los libros MS Excel (#VBAforEPMAddin)

Cuando editamos un libro MS Excel, a medida que lo modifiquemos en diversas sesiones de trabajo, su tamaño puede incrementarse considerablemente a pesar que su contenido sea casi el mismo. Nos referimos al comportamiento que podemos observar similar al de una base de datos MS Access: agregamos algunos registros, eliminamos otros o modificamos otros tantos, al final, la base de datos aumenta su tamaño, resultando recomendable comprimirlo.


Cuando editamos un libro MS Excel, a medida que lo modifiquemos en diversas sesiones de trabajo, su tamaño puede incrementarse considerablemente a pesar que su contenido sea casi el mismo.  Nos referimos al comportamiento que podemos observar similar al de una base de datos MS Access: agregamos algunos registros, eliminamos otros o modificamos otros tantos, al final, la base de datos aumenta su tamaño, resultando recomendable comprimirlo.

Tener libros de MS Excel de gran tamaño, ralentiza su apertura, consume innecesariamente la memoria y dificulta su publicación como un formulario SAP EPM add-in.  Lamentablemente no tenemos una opción de compresión en MS Excel, la acción equivalente es eliminar todas las filas vacías por debajo del área de datos que tengamos definida en todas las páginas de un libro.

Referencia: SAP Note 1602804

VBA for SAP EPM Add-in: Mejor una megaformula antes que varias fórmulas intermedias (#VBAforEPMAddin)

Cuando diseñemos formularios con el EPM Add-in, tal vez algún dato requerirá un tratamiento adicional y para lograr el resultado deseado, quizás se requiera más de una operación intermedia. Por ejemplo, recuperamos un ID y se desea uniformizar la longitud de cada porción que lo conforma y se opta por la siguiente solución:


Cuando diseñemos formularios con el EPM Add-in, tal vez algún dato requerirá un tratamiento adicional y para lograr el resultado deseado, quizás se requiera más de una operación intermedia.  Por ejemplo, recuperamos un ID y se desea uniformizar la longitud de cada porción que lo conforma y se opta por la siguiente solución:

En este ejemplo utilizamos 5 fórmulas intermedias

Las fórmulas utilizadas resultan legibles, pero a costa de mayor tiempo de recálculo e incremento considerable del tamaño del libro, lo que deriva en un incremento importante del tiempo de apertura

La definición anterior resulta clara para la gran mayoría, pero dependiendo de la cantidad de filas que se recuperen y/o si se almacena con todos los datos, la apertura del libro y su recalculo, demandará más tiempo que si se opta por una solución basada en evitar las fórmulas intermedias y definir una sola fórmula que realice todos los cálculos, la cual pasaría a denominarse, según la terminología MS Excel, megafórmula.

Las 5 fórmulas intermedias serían sustituidas por una megaformula, obtenemos menor tiempo de actualización y un libro de menor tamañoLa sugerencia final es evitar la definición de fórmulas o local members que no tendrán uso real para el usuario, que a menudo se definen para cálculos internos o intermedios y terminan ocultándose. Dependiendo del vólumen de datos que se esté procesando, valorar si mayor eficiencia se logrará con una sola fórmula, aunque su diseño y comprensión resulte un poco más complejo.

VBA for SAP EPM Add-in: Declaración de variables indispensable (#VBAforEPMAddin)

En VBA, como en muchos otros lenguajes de programación, tenemos la “libertad” de hacer muchas cosas pero algunas de ellas resultan poco recomendables. Uno de los casos más frecuentes, relacionados a este tema, es el uso de variables.


En VBA, como en muchos otros lenguajes de programación, tenemos la “libertad” de hacer muchas cosas pero algunas de ellas resultan poco recomendables. Uno de los casos más frecuentes, relacionados a este tema, es el uso de variables.

En VBA tenemos la opción por defecto de utilizar variables sin declararlas.  Los programas declarando todas las variables que se utilizarán, señalando el tipo de datos adecuado es muy probable que obtenga el mismo resultado si codificamos sin declarar las variables a emplear. Entre uno y otro estilo redundará en el tiempo de procesamiento. 

Por ejemplo, con la siguiente rutina, dependiendo de las características del ordenador, su ejecución con las variables correctamente tipificadas tardó 15 segundos y retirando la declaración de variables (comentando estas líneas) esta rutina tardo 55 segundos (pruebas realizadas en una máquina virtual con 1 CPU (2.4GHz) y 2 GB de memoria).

Rutina para comprobar la eficiencia que se logra en VBA al declarar adecuadamente todas las variables que se utilizarán(aquí código)

Una buena práctica es utilizar Option Explicit a nivel de módulo para no olvidar la declaración de variables en ninguna parte de cada proyecto.  Por defecto, cualquier variable no declarada, será de tipo Variant, la cual ocupa más espacio en memoria e internamente para VBA requiere mayor tratamiento.

Eficiencia de formularios EPM Add-in = Últimas versiones de componentes SAP BPC + VBA (#VBAforEPMAddin)

Nuestro nuevo interés por VBA (Visual Basic for Applications o Macros para MS Office) es porque tiene un uso necesario y casi inevitable al diseñar formularios e informes en SAP EPM Add-in, el complemento para MS Excel, MS Word y MS PowerPoint que actúa como interfaz cliente para la gran mayoría de productos del portfolio SAP EPM (Enterprise Performance Management), entre los que destaca SAP BPC (Business Planning and Consolidation).


Nuestro nuevo interés por VBA (Visual  Basic for Applications o Macros para MS Office) es porque tiene un uso necesario y casi inevitable al diseñar formularios e informes en SAP EPM Add-in, el complemento para MS Excel, MS Word y MS PowerPoint que actúa como interfaz cliente para la gran mayoría de productos del portfolio SAP EPM (Enterprise Performance Management), entre los que destaca SAP BPC (Business Planning and Consolidation).

Nos parece, que después de Java, Visual Basic y VBA son los lenguajes de programación que más información obtendremos en Internet. Quizás por este motivo encontremos que con bastante facilidad muchas personas incursionan en la automatización de rutinas en este lenguaje. No se necesita ni una interfaz en particular o documentación especializada, todo está relativamente accesible.

Pero dependiendo de la complejidad de lo que se esté implementando, el resultado puede ser no muy satisfactorio para el usuario, especialmente porque los tiempos de procesamiento son relativamente elevados.

Con SAP EPM Add-in la eficiencia de nuestros desarrollos para SAP BPC dependerá en parte por el tiempo de acceso a los datos, el cual está en manos de este componente y del servidor de SAP BPC. Pero por otra parte, si utilizamos VBA, la calidad de la codificación también influirá en la velocidad que finalmente percibirá el usuario al utilizar los formularios que diseñemos.

Para la mejora de la velocidad en el acceso de datos, SAP va presentando mejoras como la que comentábamos en una entrada anterior, por lo que resulta siempre recomendable utilizar las últimas actualizaciones del servidor y cliente de SAP BPC.  Para el caso de mejorar la eficiencia de VBA hay una serie de buenas prácticas que habríamos aplicado en el desarrollo de cualquier otra aplicación Visual Basic que son totalmente recomendables también con SAP EPM Add-in, algunas de ellas iremos revisando en próximas entradas.