Muchas necesidades de reporting y de creación de informes que parecen distintas comparten una misma respuesta: consultas personalizadas y reglas para informes en SAP Group Reporting. Antes de diseñar un nuevo desarrollo, merece la pena explorar hasta dónde llega el estándar.
El punto de partida
Con frecuencia, SAP Group Reporting se percibe solo como la herramienta que se usa cada mes para consolidar o, peor aún, cada trimestre o una vez al año. En el mejor de los casos, se consolida y después se extrae la información a otra plataforma. En otros, se usa de forma esporádica para cumplir obligaciones legales o fiscales, o incluso se deja de usar.
Mientras tanto, el negocio sigue pidiendo informes cuyas líneas dependen de algo más que la cuenta contable. En ocasiones, la respuesta es llevar los datos a BW, montar procesos de carga en Datasphere o construir lógicas en SAC. Son soluciones válidas, pero a menudo sobredimensionadas para ciertas necesidades, costosas de mantener y muy dependientes del área de sistemas.
Cuatro necesidades habituales
- Estado de flujos de efectivo (o flujo de caja). Cada línea combina posiciones, tipos de movimiento y otros atributos.
- Estado de cambios en el patrimonio neto (ECPN). Exige distinguir resultados, operaciones con propietarios y otros movimientos patrimoniales.
- Cuenta de resultados por función. Presenta los gastos según su destino, apoyándose en el área funcional y no solo en la naturaleza. Si la contabilidad ya registra el área funcional y SAP Group Reporting recibe bien esa información, esta necesidad también encaja en este enfoque.
- Estructura NIIF (IFRS) o de otra normativa. Agrupa las mismas posiciones de otra manera, sin crear otro plan de cuentas ni duplicar datos.
En todos ellos, una jerarquía de posiciones por sí sola no basta para expresar la lógica de cada línea.
Una misma arquitectura
Consideramos que estos cuatro casos, y seguro que hay más, se resuelven con la combinación de funcionalidades que vimos en el post anterior:
- Reglas para informes (Define Reporting Rules, FINCS_RRULE): una variante de reglas asigna a cada posición de reporting sus criterios, como rangos de posiciones, atributos, nodos de jerarquía, subposiciones, tipos de documento o inversión de signo.
- Consultas personalizadas (Custom Analytical Queries, F1572): organizan filas, columnas y características libres sobre una CDS de tipo CUBE y aplican la variante de reglas.
- Datos maestros comunes: posiciones de consolidación, jerarquías y atributos.
Cada informe es una variante de reglas distinta sobre los mismos datos. La consulta se consume en Fiori, SAC y Analysis for Office con las mismas cifras.
Ajustes, reclasificaciones y eliminaciones
Si el informe necesita algo más que los datos de origen, SAP Group Reporting también lo cubre con funcionalidad estándar:
- Ajustes adicionales: asientos manuales o carga de datos, con un tipo de documento propio.
- Reclasificaciones y eliminaciones: los métodos estándar de reclasificación y eliminación.
- Control en el informe: las reglas pueden incluir o excluir esos ajustes filtrando por tipo de documento.
SAP Group Reporting como fuente única
El planteamiento de este post es sencillo: SAP Group Reporting puede ser la fuente única del reporting financiero, tanto de saldos individuales como consolidados. Los datos ya están ahí, con su calidad, su trazabilidad y sus ajustes. No hace falta trasladar la lógica de tratamiento de datos a otra plataforma.
Conclusión
Esta arquitectura reduce el coste de construcción y, sobre todo, el de mantenimiento. Además, da autonomía al negocio: una vez implantadas, las reglas pueden mantenerlas los usuarios funcionales, por ejemplo añadiendo una nueva posición a una condición.
No es una solución universal. Habrá requerimientos con cálculos complejos, datos externos o transformaciones previas que justifiquen otras plataformas. Pero, antes de construir un nuevo modelo, conviene preguntarse si podemos resolverlo con SAP Group Reporting.
