Sugerencias para diseñar documentos WebI pensando en MS Excel

En ocasiones es inevitable que los documentos Web Intelligence (WebI) de SAP BusinessObjects BI terminen siendo exportados a MS Excel, porque entre otras cosas, el usuario se sienta más cómodo o se desconoce las posibilidades de WebI en la definición de fórmulas y otras características avanzadas que reducirían las veces en que se utilizaría esta herramienta analítica como un extractor de datos.


En ocasiones es inevitable que los documentos Web Intelligence (WebI) de SAP BusinessObjects BI terminen siendo exportados a MS Excel, porque entre otras cosas, el usuario se sienta más cómodo o se desconoce las posibilidades de WebI en la definición de fórmulas y otras características avanzadas que reducirían las veces en que se utilizaría esta herramienta analítica como un extractor de datos.

De WebI a MS Excel sin considerar las buenas prácticas de diseño de documentos pensando en la exportación

La exportación de un documento WebI a MS Excel puede generar hojas de cálculo que requerían ser ordenados por la generación innecesaria de columnas o datos mal tabulados. Dado que no podemos (o mejor dicho, no deberíamos) bloquear las exportaciones a Excel, si podemos hacer que esta tarea sea más fácil e inmediata.

Pautas básicas para diseñar documentos WebI pensando en MS Excel

En el documento de referencia se señalan unos lineamientos o buenas prácticas (best practices) para que los documentos WebI generen libros MS Excel más legibles:

  • Alinear los objetos contenidos en los informes utilizando la grid (Esta característica está disponible en la versión Rich Client y Java, dependiendo de la resolución de la pantalla puede no ser visible).
  • No utilizar márgenes asignándoles a los cuatro parámetros (izquierda, derecha, superior e inferior) el valor cero.
  • Alinear los datos a la izquierda, salvo los valores numéricos.
  • Evitar en celdas y tablas la activación de la propiedad de ancho y altura automático (Autofit width / Autofit height), utilizar tamaños fijos.  

Referencia: SAP Note 1969285

Importación de objetos BW para modelarlos en SAP HANA Studio

Si tenemos SAP NetWeaver Business Warehouse sobre una plataforma SAP HANA (BW on HANA) podríamos importar los denominados objetos BW para que sean accesibles desde la interfaz SAP HANA Studio y por consiguiente diseñar vistas de información que faciliten el acceso a los datos desde MS Excel o aplicaciones cliente tales como los componentes SAP BusinessObjects BI e inclusive…


Si tenemos SAP NetWeaver Business Warehouse sobre una plataforma SAP HANA (BW on HANA) podríamos importar los denominados objetos BW para que sean accesibles desde la interfaz SAP HANA Studio y por consiguiente diseñar vistas de información que faciliten el acceso a los datos desde MS Excel o aplicaciones cliente tales como los componentes SAP BusinessObjects BI e inclusive diseñar Universos para que los usuarios de aplicaciones como Lumira o Predictive Analysis pueda acceder a esta información dado que estas herramientas, por el momento, no pueden acceder directamente a consultas BEx.

Los objetos BW importados son presentados en la interfaz SAP HANA según la naturaleza del objeto, así un DataStore lo verámos como una vista analítica con el mimo nombre del objeto origen.  La importación de un cubo o también denominado infocubo generaría una vista analítica de uso interno con el prefijo _INTERNAL y una vista calculada la que podría ser utilizada por los usuarios. Una QuerySnapshot InfoProvider generaría una vista analítica. Un infoObjeto tipo Característica generaría una vista de atributos.

Para más información sobre la importación de objetos SAP NW BW para modelarlos en SAP HANA Studio consultar la nota 1764251 la cual puede presentar novedades en cualquier momento.

Utilizando IDT de BI4, salvado por un backup

Al estar usando intensivamente Information Design Tool (IDT) de SAP BusinessObjects BI 4.1 SP02 patch 01 (la penúltima actualización disponible) vemos con satisfacción varios pequeños detalles que se han ido incluyendo poco a poco en cada una de sus actualizaciones, detalles que en su conjunto facilitan el trabajo con esta herramienta para diseñar los denominados Universos, la capa semántica de BI4, fundamental para un BI Self Service.


Al estar usando intensivamente Information Design Tool (IDT) de SAP BusinessObjects BI 4.1 SP02 patch 01 (la penúltima actualización disponible) vemos con satisfacción varios pequeños detalles que se han ido incluyendo poco a poco en cada una de sus actualizaciones, detalles que en su conjunto facilitan el trabajo con esta herramienta para diseñar los denominados Universos, la capa semántica de BI4, fundamental para un BI Self Service.

Así como vemos muchas mejoras, nuestro “éxtasis” por esta plataforma de BI no nos ciega para identificar cosas que esperábamos superadas, más aún cuando encontramos notas que así lo señalan. Debemos reconocer que sentimos algunos minutos de “pánico” cuando al validar la integridad de nuestro diseño de Universo observamos varios errores con un texto similar al siguiente: “The calculated column referenced in the table contains ivalid sql” y al tratar de editar la gran cantidad de columnas calculadas que habíamos definido recibíamos como respuesta “Failed to edit calculated column”.

No tenemos certeza absoluta del origen del problema, pero este se produce en la denominada Data Foundation dónde observaremos que varias tablas del esquema no figuran como seleccionadas en la lista de tablas de la conexión, por lo que todos los alias y columnas calculadas generan errores al validar el “business layer” o la “data foundation”.

Después de probar varias opciones nos resignamos a recurrir a una copia seguridad, pero sólo restituimos, en otro proyecto, el fichero .dtx del «data foundation», conservando el fichero .blx del “business layer” y el acceso directo de la conexión. Otra opción hubiera sido recuperar la versión publicada en el repositorio de la plataforma, para luego realizar los cambios que estuviesen faltando.

A pesar del tiempo transcurrido SAP BusinessObjects BI nos puede seguir dando algunas sorpresas no muy gratas, por lo que en la fase de desarrollo o diseño de un proyecto de BI resulta muy aconsejable las copias de seguridad diarias.

SAP EPM y SAP BI para apoyar el «Cierre Financiero»

Se denomina “Cierre financiero” al proceso por el cual una organización periódicamente finaliza sus procesos contables y genera información financiera, útil y necesaria para apoyar la gestión interna y elaborar los informes legales y reglamentarios exigidos por instituciones externas.


Financial excellence is achieved when resources, people, and technology are combined to optimize and streamline financial processes, decrease operating costs, manage working capital and cash flow, and maximize profitability (ISBN 978-59229-422-0)

Se denomina “Cierre financiero” al proceso por el cual una organización periódicamente finaliza sus procesos contables y genera información financiera, útil y necesaria para apoyar la gestión interna y elaborar los informes legales y reglamentarios exigidos por instituciones externas.

Los continuos cambios en los procesos, datos y necesidades, complican las operaciones de cierre financiero, por lo que las organizaciones, con ambición y visión competitiva, ven en la tecnología el mejor mecanismo para asegurar la calidad y agilidad en estas operaciones.

Gama de Soluciones SAP EPM para la gestión de Cierres Financieros

En los portfolios o carteras de productos Enterprise Performance Management (EPM) y de Business Intelligence & Analytics de SAP las organizaciones puede encontrar un amplio abanico de productos que podrían ayudarle a mejorar la ejecución de sus procesos financieros contables, incluyendo los siempre críticos “cierres mensuales”.

Optar por estas soluciones debe corresponder a un plan alineado a objetivos tales como disminuir los tiempos de las tareas operativas para favorecer las tareas de análisis, mejorar la calidad e integridad de los datos, aumentar la flexibilidad y agilidad para la adopción de nuevas necesidades de gestión.

Un dato, dos historias. Otro ejemplo de mal uso de las escalas en los gráficos

En entradas pasadas hemos señalado cómo, con o sin intención, podemos diseñar visualizaciones que transmiten de manera inexacta la información. El poder del «primer impacto» que tienen los gráficos debería ser utilizado para conducir a la creación de conclusiones correctas. La siguiente estadística corresponde a las veces en que sale un número en una lotería que premia el acierto de tres dígitos.


En entradas pasadas hemos señalado cómo, con o sin intención, podemos diseñar visualizaciones que transmiten de manera inexacta la información (aquí o aquí).  El poder del «primer impacto» que tienen los gráficos debería ser utilizado para conducir a la creación de conclusiones correctas.  La siguiente estadística corresponde a las veces en que sale un número en una lotería que premia el acierto de tres dígitos.

Ejemplo, Numero de extracciones de un número en un sorteo

La diferencia en la frecuencia entre cada número, no da lugar a considerar la existencia de un «número mágico», pero viendo la siguiente gráfica daría esta falsa impresión:

Imagen gráifca con un mensaje inexacto sobre la realidad

El principal motivo de este mensaje incorrecto es iniciar la escala (eje Y) con un valor distinto de cero. Por otro lado, según sea el caso, se debe seleccionar el indicador más adecuada para motivar la comparación, para este ejemplo, quizás lo más acertado sería comparar a través el porcentaje de veces en que sale un número.

Representaciones gráficas más fieles a la realidad

Los visualizaciones tienen mayor impacto que cualquier otro medio para transmitir la información, antes de dar por válidos cualquier visualización debemos observar este tipo de detalles.

Referencia: ISBN 978-84-329-0157-7