SAP Group Reporting – aníbal goicochea

Una CDS, cuatro miradas: el reporting de SAP Group Reporting… y casi cualquier otra fuente de SAP

Quien oye hablar de SAP Group Reporting por primera vez suele imaginar una batería de informes y consultas listas para usar. No es así. SAP Group Reporting es la herramienta de S/4HANA que automatiza el proceso de elaboración de los Estados Financieros consolidados.

El estándar incluye las CDS del modelo de datos virtual (VDM) sobre las que se construye el reporting. Estas CDS se pueden ampliar, o tomarse como base de otras nuevas, para incorporar dimensiones o datos maestros adicionales, estándar o custom. Las Best Practices y la instalación estándar aportan además algunos libros de Analysis for Office y varias aplicaciones Fiori. Pero todo esto no basta para cubrir el reporting básico que se pide en cualquier implantación o, simplemente, nada de eso resulta útil en la mayoría de las circunstancias.

NOTA: CDS (Core Data Services): Es una definición lógica de los datos y de su semántica (qué representan, cómo se relacionan y cómo se consumen). No almacena datos: el sistema la traduce a lenguaje SQL y ejecuta estas instrucciones directamente en la capa de la base de datos.

Alternativas para el reporting

En nuestra opinión, hay cuatro vías para cubrir los informes y las visualizaciones de los datos de consolidación (también aplicable sobre cualquier otra fuente SAP).

Herramienta	Facilidad de uso	Capacidad gráfica	Integración con Excel	Navegación por jerarquías	Uso recomendado
SAP Analysis for Office	●●●●●	●○○○○	●●●●●	●●●●●	Análisis operativo y conciliaciones
Aplicaciones Fiori	●●●○○	●●○○○	●●●○○	●●●●○	Consulta rápida integrada en S/4HANA
SAP Analytics Cloud (Live)	●●●○○	●●●●●	●●○○○	●●●●●	Informes de dirección, semestrales y anuales
Web Intelligence	●●●●○	●●●●○	●●●●○	●●●○○	Informes formateados y distribución masiva
Herramientas no SAP (Power BI, Tableau…)	●●●○○	●●●●●	●●●○○	●○○○○	Solo como referencia: suelen manejar mal todo tipo de jerarquías SAP

Escala de 1 a 5, según nuestra experiencia.

Nota: no se incluye SAC con Import Connection. Salvo que haya que combinar los datos de GR con otras fuentes, realizar cálculos complejos o que exista un problema de rendimiento por una granularidad elevada (número de dimensiones utilizadas), no se justifica replicar los datos en distintas plataformas.

Analysis for Office (AfO). Se adopta con facilidad porque funciona sobre Excel. Si defines jerarquías, se navega muy bien por ellas. Es práctico e inmediato. Tiene gráficos, pero de calidad limitada.

Aplicaciones Fiori. El estándar incluye varias aplicaciones analíticas basadas en consultas CDS, como Group Data Analysis, con y sin reglas de reporting. Para tus propias consultas, defines la CDS de tipo query y la localizas con el Explorador de consultas (Query Browser). Desde ahí la ejecutas y puedes crear un tile o mosaico en el Launchpad de Fiori, con acceso similar al de cualquier otra aplicación Fiori. Los gráficos son limitados y los datos se pueden exportar a Excel.

SAP Analytics Cloud. Hay que distinguir entre Live Connection e Import Connection.

Live: consume la misma query que AfO y Fiori, así que el modelo de datos y las jerarquías se comportan igual, con mucha agilidad. El rendimiento depende de la CDS, por lo que es recomendable diseñar una específica para SAC con las dimensiones, medidas y textos estrictamente necesarios.
Import: obliga a replicar el modelo, los datos y las jerarquías, lo que duplica el esfuerzo de construcción y mantenimiento.

La calidad gráfica es muy superior a la del resto. En cambio, es poco práctico para analizar al detalle la operativa de la consolidación. Encaja mejor en informes semestrales o anuales, donde pesan más los gráficos que las tablas.

Web Intelligence. Es la alternativa en la que menos se piensa hoy, pero es viable. La versión BI 2025 mejora la conectividad BICS, que permite consumir las consultas de CDS, e incorpora gráficos nuevos y más opciones de exportación. En formato de informe y exportación a Excel, WebI no tiene rival.

Una única fuente

Las cuatro vías pueden convivir en la misma implantación y usar la misma fuente lógica: una CDS de tipo query. No hace falta replicar los datos en BW, SAC o Datasphere (salvo que exista la necesidad de ampliar o complementar la información).

Al activar la CDS, el sistema genera una query transitoria con el prefijo 2C más el nombre de su SQL view. Por ejemplo, si defino una CDS con el nombre ZGR_CONSO_MAT_10_SAC y el identificador de SQL view ZCCSMAT10SAC, se genera la query 2CZCCSMAT10SAC. Se llama transitoria porque no se persiste, es decir, no existe como un objeto físico, el motor analítico la construye al vuelo a partir de la CDS.

Fiori la localiza por el nombre de la CDS.
AfO, SAC Live y Webi la consumen por su nombre 2C*.

Por debajo, todas estas herramientas ejecutan exactamente la misma consulta.

Cómo viaja el dato: cinco capas

Presentación. Fiori, SAC, AfO o WebI muestran los datos y permiten navegar por ellos. Pueden añadir cálculos propios, como fórmulas en WebI, medidas calculadas en SAC o miembros locales en AfO, pero la lógica principal de la consulta la resuelve el motor analítico.
Protocolo. Transporta la petición: de tipo InA (HTTP y JSON) para Fiori y SAC, y de tipo BICS (RFC) para AfO y WebI.
Motor analítico (BW embebido). Ejecuta la query 2C*: jerarquías, agregaciones, cálculos, variables y autorizaciones.
ABAP CDS. Es el modelo semántico: la CDS de tipo query definida sobre otra CDS de tipo cube, en este ejemplo I_MatrixConsolidationReportC. Solo contiene definiciones, no datos.
Base de datos (HANA). Lee físicamente los datos a través de las vistas SQL encadenadas hasta la tabla ACDOCU.

Aviso práctico: no cambies el sqlViewName de una CDS en uso. Al cambiarlo cambia el nombre 2C*, y se rompen los libros de AfO y los modelos de SAC que apuntan a él.

Si el dato no necesita transformaciones ni combinarse con otras fuentes, la CDS es la mejor alternativa.

Conclusión

El reporting no viene resuelto con SAP Group Reporting: hay que diseñarlo. La clave no es elegir una herramienta, sino diseñar bien las CDS de tipo query desde el inicio, según lo que requiere el proyecto. Con una CDS sólida, se puede proponer una herramienta según el perfil del usuario:

El consolidador, AfO;
El controller, Fiori;
La dirección, SAC;
La distribución, Webi.

Y todos consultan la misma fuente.

Este enfoque no es exclusivo de SAP Group Reporting: cualquier dato de S/4HANA expuesto mediante una CDS de tipo query puede seguir el mismo camino.

Preparation Ledger de SAP S4GR: mapeo y realineación de datos

El mapeo entre cuentas contables y posiciones de consolidación es la pieza clave: fundamenta tanto la derivación en tiempo real como la realineación de los datos.

Preparation Ledger: mapeo y realineación de datos

En el post anterior comentábamos el uso del Preparation Ledger en SAP Group Reporting (GRPL). Conviene completar aquella explicación con dos aspectos prácticos: cómo se deriva la posición de consolidación correspondiente a cada cuenta contable y en qué situaciones es necesario realinear los datos.

El mapeo entre cuentas contables y posiciones de consolidación, definido inicialmente por los consultores y mantenido después, en muchos casos, por los propios usuarios, alimenta la derivación en tiempo real. Cuando el Preparation Ledger está activo, este mapeo determina qué posición de consolidación corresponde a cada cuenta contable en el momento de la contabilización.

Realineación de los datos del Preparation Ledger

La realineación resulta necesaria en dos situaciones: cuando el Preparation Ledger se activa después del inicio del ejercicio y cuando cambia el mapeo entre cuentas contables y posiciones de consolidación.

La activación del Preparation Ledger no tiene por qué coincidir con el inicio del ejercicio. En una implementación on-premise puede ponerse en marcha a mitad de ejercicio, aunque hasta ese momento se haya utilizado la integración clásica; posteriormente, es posible realinear la información de los periodos contabilizados sin la funcionalidad activa. En la edición Cloud, en cambio, SAP indica que el paso de la integración clásica al Preparation Ledger solo puede realizarse con el cambio de ejercicio.
Si cambia el mapeo entre cuentas contables y posiciones de consolidación, también será necesario ejecutar de nuevo la realineación para que los datos ya contabilizados reflejen la nueva correspondencia.

En ambos casos, la realineación se ejecuta como un proceso en lote y conviene programarla en franjas de baja actividad. Si la organización gestiona un volumen elevado de información, el proceso puede dividirse en bloques, por periodos e incluso por sociedades, para controlar mejor el consumo de recursos del sistema.

Preparation Ledger en SAP Group Reporting: beneficios, impacto y criterios de adopción

El Preparation Ledger de SAP Group Reporting incorpora al Diario Universal, en el momento de contabilizar, la información que necesita la consolidación: unidad de consolidación, posición de consolidación y sociedad contraparte. Analizamos sus beneficios reales, como el acceso en tiempo real a los datos con visión de consolidación, el tratamiento correcto de los periodos especiales y las reglas de validación, junto con su impacto técnico y los criterios para decidir si la organización está preparada para adoptarlo

El artículo está pensado para dos tipos de lectores: el consultor funcional, responsable de la parametrización, y el responsable financiero, que necesita consultar los datos en tiempo real desde una perspectiva de consolidación. La decisión es técnica, pero el beneficio es de negocio.

La configuración de SAP Group Reporting se apoya en numerosas tablas, muchas de ellas gestionadas mediante transacciones que actúan como vistas de mantenimiento. Entre ellas destacan las que contienen los parámetros globales: valores que, una vez establecidos, determinan el comportamiento general de la plataforma y condicionan la parametrización de todo el módulo.

PREPARATION LEDGER

El Preparation Ledger es uno de esos parámetros globales y se activa fijando el ejercicio a partir del cual entra en funcionamiento. Desde ese momento, al contabilizar cada documento se determinan datos relevantes para la consolidación, como la unidad de consolidación, la posición de consolidación y la sociedad contraparte, y se registran en tiempo real en el Diario Universal (ACDOCA).

Aunque SAP indica que los parámetros globales no pueden modificarse una vez establecidos, en la práctica algunos ajustes pueden gestionarse mediante SAP Support. Quien conozca en profundidad el funcionamiento de estos parámetros y la relación entre las tablas implicadas también puede identificar y actualizar las tablas correspondientes mediante vistas de mantenimiento creadas específicamente para ello. Esta alternativa no está soportada, debe aplicarse bajo la propia responsabilidad y, siempre que sea posible, conviene validarla previamente con SAP Support.

BENEFICIOS DEL PREPARATION LEDGER

El beneficio principal es disponer en tiempo real de los datos necesarios para la consolidación. En el momento de la contabilización, las cuentas contables quedan vinculadas a las posiciones de consolidación, las sociedades a las unidades de consolidación y las contrapartes a las sociedades contraparte. Una vista CDS permitiría consultar estos datos de inmediato en la herramienta de reporting elegida, sin esperar a ejecutar el volcado a consolidación.
Otro beneficio relevante afecta al tratamiento de los periodos especiales. Sin el Preparation Ledger, los importes contabilizados en los periodos del trece al dieciséis se vuelcan a consolidación agrupados en el periodo doce, un resultado que no siempre responde a las necesidades del proceso. Con el Preparation Ledger activado, la información se traslada al periodo en el que se contabilizó originalmente, por lo que se conserva el detalle temporal.
Un tercer beneficio es la posibilidad de establecer reglas de validación y sustitución sobre el Diario Universal. Por ejemplo, en función de la sociedad, la cuenta contable u otros criterios, estas reglas podrían exigir que se informe la sociedad contraparte o impedir la contabilización de determinadas combinaciones de datos maestros. No obstante, no recomendaría gestionar estas reglas desde el Preparation Ledger, ya que podrían solaparse con las validaciones definidas en FI y generar redundancias o incluso contradicciones entre ambos módulos.

CONCLUSIÓN

El Preparation Ledger no es solo un cambio técnico de configuración: adelanta el momento en que la información adquiere significado para la consolidación. Este enriquecimiento deja de ejecutarse como un paso posterior durante el cierre y pasa a incorporarse al dato desde el momento de su contabilización.

Por tanto, la cuestión no es si el Preparation Ledger aporta beneficios, sino si la organización está preparada para integrar la consolidación en la operativa diaria. Adoptarlo implica tratar la consolidación no solo como una actividad de cierre, sino como un proceso continuo que exige reglas de derivación fiables y coordinación entre los equipos implicados.

Apuntes técnicos:

En SAP S/4HANA Cloud, según las funcionalidades utilizadas, la activación del Preparation Ledger puede dejar de ser opcional (KBA 3542410).
No hemos identificado incidencias atribuibles a la duplicidad de la información: los datos con visión de consolidación residen en ACDOCA y, tras el volcado a SAP Group Reporting, también en ACDOCU. En el Diario Universal, además, el incremento de almacenamiento no se debe a la creación de nuevos registros, sino a la incorporación de campos en las líneas existentes.

Group Reporting, la revolución en la Consolidación Financiera de SAP

A partir de la edición 1809 de S/4 HANA Finance, se incluye Group Reporting como componente de Central Finance, la suite que permite aglutinar los datos necesarios para obtener los informes financieros – contables que requiera una organización. (La solución de Group Reporting, ya estaba incluida en la versión Cloud de S/4 HANA, la cual suele ir por delante en la innovación de funcionalidades).

Al parecer, ahora le toca a la Consolidación de SAP. Después de más de una década de SAP BusinessObjects Planning and Consolidation (SAP BPC), en la que han surgido, no tan sólo nuevas versiones, sino también variantes de la plataforma, estás últimas han ido afectando, principalmente, a la rama de la Planificación y Presupuestos, en la forma de implementar este tipo de soluciones.

Por variantes de SAP BPC, nos referimos a la Estándar, Embedded y a la Optimizada para S/4 HANA, cada una ellas con principios comunes, pero con arquitecturas diferentes y recursos particulares que repercuten en el diseño y desarrollo de cada solución.

La otra rama o categoría de soluciones de SAP BPC son las de Consolidación. Las tres variantes o ediciones de este producto, de algún modo, han mantenido los principios básicos del modelado de soluciones de Consolidación SAP BPC, bueno, hasta ahora.

Group Reporting, tomando lo mejor de cada herramienta.

A partir de la edición 1809 de S/4 HANA Finance, se incluye Group Reporting como componente de Central Finance, la suite que permite aglutinar los datos necesarios para obtener los informes financieros – contables que requiera una organización. (La solución de Group Reporting, ya estaba incluida en la versión Cloud de S/4 HANA, la cual suele ir por delante en la innovación de funcionalidades).

Group Reporting, está llamado a ser, según un comunicado de SAP (por lo pronto, sólo lo he encontrado en Alemán), la herramienta que permita diseñar soluciones de Consolidación, que aglutinará las mejores funcionalidades de todas las herramientas de consolidación ofrecidas hasta ahora por este fabricante: SAP Enterprise Controlling Consolidation System (SAP EC-CS), SAP Strategic Enterprise Management Business Consolidation System (SAP SEM-BCS), SAP Financial Consolidation y SAP Business Planning & Consolidation (SAP BPC).

Group Reporting, implicaría ahorros

S/4 HANA se afirma como la base sobre la cual se constituirán los componentes que brinden a los negocios la gestión de sus transacciones del día a día y la analítica tradicional o avanzada, que con inmediatez, facilidad y de manera centralizada tendrán acceso los usuarios. En esta línea, Group Reporting, para la implementación de una solución de Consolidación, implicaría, de manera clara, lo siguiente:

Reducción de infraestructuras, al utilizarse el mismo servidor o instalación.
Minimización o eliminación de procesos de carga de datos ETL, al utilizarse el Universal Journal de S/4, brindando mayor rapidez e integridad en los datos de origen.

Group Reporting en Central Finance ejecutaría los pasos de la consolidación para derivar los Estados Financieros consolidados, incluidas la conversión monetaria y las eliminaciones de operaciones entre las compañías del grupo.

Group Reporting es un cambio importante que deberemos observar al considerar un nuevo desarrollo o migración de versiones de SAP BPC.

Referencia: SAP News