SAP PaPM, ese gran desconocido, héroe del reparto


¿Cómo repartimos los costes y cómo explicamos la rentabilidad? Ante esta necesidad, seguro que inmediatamente, pensamos en una solución a medida con ABAP, BW o, más recientemente, Datasphere o SAC.

Hay otra opción que conviene valorar: SAP Profitability and Performance Management (PaPM). Es una aplicación para modelar cálculos y procesos de negocio complejos, con funcionalidades específicas de asignación de costes y análisis de rentabilidad. Su alcance incluye también escenarios fiscales y de precios de transferencia operativos (los importes que unas sociedades de un grupo cobran a otras por productos o servicios).

Un ejemplo: repartir los costes centrales de una constructora entre sus proyectos según empleados, insumos, maquinaria o servicios consumidos, y analizar cómo cambia el margen de cada uno.

No es un producto nuevo. La versión 1.0 salió en 2015 y la 3.0 en 2018 (versión vigente en on-premise). Además, toma el relevo funcional de SAP BusinessObjects Profitability and Cost Management (PCM) en costes y rentabilidad, incluido el cálculo basado en actividades. PCM 10.0 está en mantenimiento específico de cliente desde enero de 2024, y SAP recomienda PaPM como alternativa. Incluso proporciona contenido para migrar reglas de PCM a PaPM.

¿Qué opciones existen hoy?

  • PaPM 3.0 on-premise (add-on NXI 300): se instala sobre NetWeaver 7.50, S/4HANA, BW/4HANA o ERP 6.0 EHP8, siempre sobre SAP HANA Database. Su mantenimiento sigue al de la plataforma que lo contiene.
  • PaPM Cloud: disponible desde 2021, ofrece dos aplicaciones de modelado: Standard Model, orientado a repartos con grandes volúmenes, y Universal Model, que requiere una activación específica.

On-premise sigue evolucionando. La SP28, publicada en septiembre de 2026, incorpora un Runtime Analysis Cockpit, nuevos tipos de particionado (Hash y Hash-Range), soporte de CDS View entities en conexiones y carga masiva de instancias de proceso desde Excel.

Sin embargo, el roadmap concentra las innovaciones más destacadas en Cloud, con fuerte apuesta por la IA. Está previsto, por ejemplo:

  • Asistencia en el mantenimiento de reglas de derivación en Universal (Q4 2026).
  • Asistencia en la configuración de funciones de reparto en Standard (Q2 2027).
  • Un LLM entrenado por SAP para este dominio (Q3 2027).

Son funcionalidades previstas y sujetas a cambios.

Alternativas SAP y no-SAP

Dentro de SAP, según la complejidad de los requisitos, existen alternativas con alcances distintos: Universal Allocation en S/4HANA y los repartos de SAC Planning. También pueden construirse soluciones a medida con ABAP, BW, SAC o Datasphere. En ese caso, hay que valorar bien su coste de diseño y mantenimiento.

Fuera de SAP destacan Oracle Enterprise Profitability and Cost Management y CCH Tagetik Profitability Analysis, ambas con capacidades específicas de asignación de costes y análisis de rentabilidad.

Antes de desarrollar otro reparto a medida, contrasta tus reglas, volúmenes y necesidades de trazabilidad con las soluciones disponibles. Y pregúntate: ¿la solución propuesta ayudará a explicar el negocio hoy y mañana?

Fuentes oficiales

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

  1. 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.
  2. 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.
  3. 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.

¿Qué hay después de la consolidación?

Tras implantar un módulo de consolidación, las empresas suelen disponer de informes estándar de Estados Financieros (Balance y Cuenta de Resultados). Sin embargo, esto no elimina la necesidad de tareas manuales para generar informes adicionales requeridos por análisis, auditoría o financiación.

Por ello, es clave complementar la consolidación con soluciones que permitan crear “Reporting Packages” (memorias, notas e informes periódicos), integrando múltiples fuentes de datos y automatizando cálculos.

Además, se podrían incluir la automatización de documentación oficial, como informes para el Registro Mercantil (incluyendo XML) y formularios para la Administración tributaria.


Suele ocurrir que, como resultado final de la implantación de un módulo de consolidación, los usuarios disponen de una batería de informes de Estados Financieros (EEFF), generalmente estructurados en torno al Balance y la Cuenta de Resultados, incluyendo distintas variantes en los ejes de filas y columnas, comparativas, filtros y jerarquías de cuentas contables (o posiciones de consolidación).

Sin embargo, limitarse a este punto implica, en muchos casos, un impacto reducido en la optimización del trabajo del usuario, ya que continúan existiendo tareas manuales para la elaboración de informes complementarios. Estos informes son necesarios para cubrir requerimientos de análisis, atender exigencias del área de auditoría o dar soporte a la presentación de información ante entidades de financiación. Además de los saldos individuales y los EEFF consolidados, suelen requerir la integración de otras fuentes de información y la aplicación de cálculos o procesos adicionales.

En este contexto, surge la necesidad de construir baterías de informes periódicos —anuales o intermedios— comúnmente denominados “Reporting Packages”, “Memorias” o “Notas”.

Asimismo, en esta categoría de soluciones complementarias a la consolidación incluimos la automatización de la generación de documentación requerida para el Registro Mercantil (como la memoria y los ficheros en formato XML), así como la preparación de formularios para su presentación ante la Administración tributaria.

Reporting Package, Memorias o Notas

Con una periodicidad anual o trimestral, toda organización requiere una batería de informes adicionales a los tradicionales basados en la estructura de los Estados Financieros (EEFF). Estos documentos se caracterizan por proporcionar un mayor nivel de detalle sobre los principales epígrafes, aportando una visión más profunda de la evolución y situación del negocio.

Entre estos informes, se podrían señalar los siguientes:

Registro Mercantil

En España, toda sociedad está obligada a formular y depositar las cuentas anuales —incluida la memoria— en el Registro Mercantil. Para ello, esta institución pone a disposición aplicaciones específicas que permiten la cumplimentación de formularios y plantillas normalizadas para la presentación de la información.

Este proceso puede realizarse de forma manual o mediante la carga de ficheros generados automáticamente, habitualmente en formato XML para la información económico-financiera, así como documentos en formato Word o PDF en el caso de la memoria.

Si la mayor parte de la información requerida ya se encuentra disponible en los sistemas de consolidación —complementada, en su caso, con datos adicionales como los relativos al personal— es posible automatizar este proceso. De este modo, se reduce significativamente el esfuerzo manual necesario para cumplir con esta obligación, al tiempo que se mejora la consistencia, trazabilidad y fiabilidad de la información reportada

Retorno de la Inversión Asegurado

Si se tiene en cuenta que, durante el cierre contable de un período —especialmente al cierre anual—, los ajustes contables se producen con elevada frecuencia, y que esta información se utiliza para la elaboración de informes complementarios como los descritos, la ausencia de mecanismos automáticos que reflejen dichos ajustes en tiempo real puede derivar en el siguiente escenario:

  • Elevada inversión de tiempo en la elaboración manual de informes.
  • Riesgo significativo de errores debido al uso de procedimientos basados en “copy & paste”.

Nuestra experiencia en la implantación de soluciones de este tipo ha demostrado un alto grado de satisfacción por parte de los usuarios, al reducir significativamente el tiempo necesario para la elaboración de informes, disponer de información permanentemente actualizada y mejorar la fiabilidad e integridad de los datos. Este impacto es especialmente relevante en entornos con un número elevado de filiales, donde se requiere la generación de estos informes de forma individualizada para cada una de ellas.

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