Caso práctico: data actions con los filtros de la story en SAC

En planificación con SAP Analytics Cloud hay una conversación que se repite en todos los proyectos: “en la story he filtrado todos los centros de coste menos los corporativos, pero la data action ha procesado todo”. Hasta ahora, los parámetros de las data actions solo entendían listas fijas de miembros: ni exclusiones, ni rangos de fechas dinámicos. Con la versión QRC3 de 2026 llega el data filter parameter, que lleva a la data action el filtro tal como lo ve el usuario. En este caso práctico lo ponemos a trabajar en un refresco de forecast y, de paso, en un cálculo que solo se ejecuta sobre lo que el usuario ha cambiado.

Qué vamos a construir

Al acabar tendrás:

1. Una data action DA_FCST_REFRESH que borra y vuelve a copiar el real en la versión Forecast, con el ámbito que llega de la story: un input control de centro de coste con exclusión y un filtro de fechas dinámico, los dos en un único parámetro DF_SCOPE.
2. Un starter en la story que pasa esos dos filtros a la data action sin una línea de script.
3. Una segunda data action, DA_SOC_SEC, que recalcula las cargas sociales solo en los centros de coste que el usuario ha modificado, gracias a un parámetro privado DF_CHANGED que se rellena solo.

La portada resume el montaje. Todos los nombres técnicos (PLN_OPEX, COST_CENTER, CC_9900…) son de ejemplo: usa los de tu convención.

Para que puedas reproducirlo desde cero, el caso empieza creando el modelo de planificación de gastos PLN_OPEX con dos CSV de ejemplo con datos ficticios en euros:

• PLN_OPEX_ACTUAL.csv: el real de enero a septiembre de 2026 (216 filas).
• PLN_OPEX_FORECAST.csv: el forecast de enero a diciembre de 2026 (288 filas).

Los dos tienen las mismas columnas: DATE (formato yyyymm), ACCOUNT y ACCOUNT_DESC (salarios, cargas sociales, viajes y alquiler), COST_CENTER y COST_CENTER_DESC (seis centros de coste) y AMOUNT. El centro CC_9900 agrupa los costes corporativos (servicios centrales: dirección general, jurídico, auditoría…). No se planifican en este proceso: los fija controlling central, así que el refresco no debe tocarlos. En el real, las cargas sociales rondan el 31,2 % de los salarios; en el forecast, el 30 %. Esa diferencia te servirá para ver qué recalcula cada data action.

Por qué merece la pena

El parámetro de tipo miembro tiene tres límites que conoce cualquiera que haya montado un starter. No acepta exclusiones (“todo menos…”). No acepta rangos ni filtros avanzados. Y, si lo rellenas por script, desde el Q2 de 2027 SAP bloqueará la ejecución cuando el parámetro pase de 1.000 miembros (en los tenants que nunca lo habían superado, el límite ya se aplica desde el Q2 de 2026). El resultado típico es una data action que procesa más datos de los necesarios o un script que construye listas enormes.

Aspecto	Parámetro de miembro	Data filter parameter
Dimensiones por parámetro	Una	Las que lleguen desde la story (hasta 100 filtros)
Exclusiones y rangos de fechas	No	Sí, con la semántica del filtro de la story
Límite de 1.000 miembros	Sí	No, porque no pasa una lista estática
Qué filtra se decide en…	La data action	El starter de cada story
Rellenarse con los cambios del usuario	No	Sí, con «auto-determined by version changes»

Mi lectura de consultor: el data filter parameter no sustituye a los parámetros de miembro cuando el valor es un objetivo (la versión destino, la cuenta a la que copias). Sustituye a los parámetros que solo servían para acotar el ámbito, que son la mayoría.

Paso a paso

1. Paso:Crea el modelo de planificación PLN_OPEX

   En el Modeler, pulsa + (nuevo modelo) y elige Start with an empty model. SAC crea un modelo con estructura abierta, capacidades de planificación activadas y las dimensiones Date y Version. Deja la planificación activada y no actives la conversión de moneda: este caso no la necesita.

   1. Date: selecciónala y, en el panel lateral, fija el intervalo de enero a diciembre de 2026 (From / To) con granularidad mes.
   2. Dimensiones: añade dos dimensiones genéricas y privadas, con tabla de dimensión: ACCOUNT y COST_CENTER. Uso una dimensión genérica para las cuentas, y no una de tipo Account, para no meter en el caso la prioridad de estructura entre cuentas y medidas.
   3. Medida: añade AMOUNT con tipo Decimal, 2 decimales, agregación Sum y, en Units & Currencies, tipo Currency con moneda fija EUR.

   Guarda el modelo como PLN_OPEX. Hazlo con calma: hay ajustes del modelo que ya no se pueden cambiar una vez guardado.

   Después, crea la versión de forecast. Selecciona la dimensión Version, abre Edit Dimension Table y añade una línea con la descripción Forecast y la categoría Forecast. El ID lo rellena el sistema a partir de la descripción. La versión Actual ya existe por defecto. Guarda.

   

2. Paso:Carga los datos de ejemplo

   Descarga los dos CSV. Abre PLN_OPEX, ve a la gestión de datos del modelo (Data Management) y elige Import Data from → File. Selecciona PLN_OPEX_ACTUAL.csv y pulsa Set up import.

   En la preparación de datos no hay nada que transformar. En el mapeo:

   • DATE → Date. En el paso Map to Facts, pulsa Review Settings en el destino Date y comprueba que el formato de origen es yyyymm.
   • ACCOUNT → ACCOUNT y COST_CENTER → COST_CENTER.
   • AMOUNT → AMOUNT.
   • Version: el fichero no trae columna de versión, así que usa Set Default Value y elige public.Actual.
   • Atributos, en el paso Map Properties: ACCOUNT_DESC como descripción de ACCOUNT y COST_CENTER_DESC como descripción de COST_CENTER. SAC te indicará cuántos miembros nuevos crea en cada dimensión: 4 cuentas y 6 centros de coste.

   Revisa la importación y ejecútala. Repite con PLN_OPEX_FORECAST.csv, esta vez con Forecast como versión por defecto.

   Comprueba los totales de AMOUNT antes de seguir: 3.392.486,60 en Actual y 4.588.128,00 en Forecast. Si no cuadran, mira el resumen de filas rechazadas de la importación; casi siempre es el formato de la fecha.

   

3. Paso:Crea el data filter parameter en la data action

   Crea la data action DA_FCST_REFRESH con PLN_OPEX como modelo por defecto. Abre la lista de parámetros con Show Parameters List y elige Create Parameter:

   • ID: DF_SCOPE (solo letras, números y guiones bajos).
   • Parameter Type: Data Filter.
   • Model: PLN_OPEX.
   • Visibility: Public, para que el starter pueda asignarle filtros.
   • Name for Prompt: “Ámbito de la story”.

   Fíjate en lo que no te pide: ni dimensión, ni jerarquía, ni miembros. Eso es lo que lo hace distinto. El parámetro es un “hueco” para filtros; qué filtros entran se decide luego en el starter de cada story. Así, la misma data action puede recibir solo centros de coste desde una story y centros de coste más fechas desde otra.

   

4. Paso:Usa el parámetro en el contexto de los pasos

   El parámetro se aplica en la zona de filtros (el contexto) de los pasos de copia, copia entre modelos, conversión de moneda, borrado y asignación estructurada. Aquí añadimos dos pasos:

   1. Paso de borrado “Limpiar forecast en ámbito”: ya trae el filtro Version = TargetVersion; con Add Filter, añade DF_SCOPE. Deja Delete Mode en Delete Facts. Borra los datos de la versión destino dentro del ámbito que llegue de la story.
   2. Paso de copia “Copiar real a forecast”: en Filters, filtra Version = Actual y añade DF_SCOPE. No necesitas reglas de copia: si filtras la versión de origen y no tocas el resto, los datos se copian a los mismos miembros en la versión destino (la que fija el parámetro TargetVersion).

   El orden importa. Si copias sin borrar antes, las combinaciones que tenían forecast y ya no tienen real se quedan “huérfanas” en Forecast. Y aquí está la gracia del caso: un paso de borrado es exactamente donde no quieres un ámbito aproximado. Con un parámetro de miembro tendrías que pasar todos los centros de coste uno a uno, salvo CC_9900. Con el data filter, la exclusión llega tal cual.

   

5. Paso:Prepara la story: input control con exclusión y fechas dinámicas

   Crea una story sobre PLN_OPEX con una tabla para validar y dos input controls de página, que son los filtros que pasaremos a la data action:

   • Tabla: COST_CENTER en filas y, en columnas, Measures y Version. PLN_OPEX es un modelo con medidas, así que la tabla pide una medida explícita: añade AMOUNT. Ojo con un detalle: al insertar la tabla, SAC le pone un filtro de tabla Version = Actual («1 Filter» en la cabecera). Quítalo para ver Actual y Forecast.
   • Centros de coste: Insert → Input Control → Dimensions → COST_CENTER → Filter by Member. Marca All Members y desmarca CC_9900 (Corporate overhead). Así el filtro queda definido como exclusión, no como lista de miembros. El control seguirá mostrando «(All)», pero la exclusión se aplica: Corporate overhead desaparece de la tabla.
   • Fechas: Insert → Input Control → Add Time Filters → Current → To Previous Date → Year. El control queda como «Current Year». En su diálogo, Set Date Range for Date, verás la definición: Ranges Type Dynamic, Range Type Standard, Granularity Current Year y End at Previous Month (las otras opciones son Previous Year y Previous Quarter), con la jerarquía Year, Quarter, Month. Es decir, desde enero hasta el mes anterior al actual.

   Con los datos de ejemplo, el rango debe ser enero–septiembre de 2026. Si sigues el caso en otra fecha, fija una fecha actual personalizada: en ese mismo diálogo, en Date Type, elige + Create Custom Date… (Custom Date / Time Interval, granularidad Day, 1 de octubre de 2026). El rango queda «Current Year (Jan, 2026 - Sep, 2026)».

   Para la validación necesitarás publicar o descartar los datos de la versión: el botón Publish Data está en la barra de herramientas ampliada de la story y su desplegable incluye Revert Data.

   

   

6. Paso:Configura el starter y asigna los filtros al parámetro

   Añade el starter con Insert → (+) → Starters → Data Action Starter, ponle la etiqueta “Refrescar forecast con real” y, en el panel Builder, selecciona DA_FCST_REFRESH:

   • Default strategy if target version isn’t in edit mode: Automatic Planning Area.
   • Publish to target version after execution: Do not publish. Yo lo dejaría así: el planificador revisa el resultado y publica él.
   • En Parameters, Target Version: Input Fixed Value y valor public.Forecast.

   En el parámetro “Ámbito de la story” (DF_SCOPE), Add Filter abre el diálogo Select Filters con los input controls de la página: marca COST_CENTER y Date. Un único parámetro recibe los dos filtros; el starter admite hasta 100 filtros de story o de input control por parámetro.

   Si la data action va dentro de una multi action, hay un paso más: crea en la multi action su propio parámetro de tipo data filter y enlázalo con DF_SCOPE en el paso de data action. Si no, el filtro no llega.

   

7. Paso:Crea un parámetro privado que detecte lo modificado

   Segunda parte del caso. Crea la data action DA_SOC_SEC sobre PLN_OPEX y un parámetro nuevo:

   • ID: DF_CHANGED.
   • Parameter Type: Data Filter.
   • Visibility: Private.
   • Con Add Filter, elige COST_CENTER → Auto-determined by version changes.

   El token del filtro queda como «Based on changes in “TargetVersion”»: por defecto se fija en la versión destino. Puedes cambiarla seleccionando el token. Al arrancar la data action, SAC mira qué centros de coste tienen cambios en esa versión y los pasa al parámetro.

   No añadas más dimensiones “por si acaso”. Si pones COST_CENTER y ACCOUNT, el ámbito es el producto cartesiano de los miembros modificados de cada una. Y si el total de miembros modificados es demasiado grande, SAC para la ejecución. Elige dimensiones en las que el usuario suele tocar pocos miembros.

   

8. Paso:Úsalo en una advanced formula

   Añade un paso de advanced formula “Cargas sociales”. En las advanced formulas, el data filter parameter se declara con dos líneas CONFIG antes de la fórmula: qué parámetros se activan y qué dimensiones de esos parámetros se aplican. La segunda hace el papel de un MEMBERSET sobre COST_CENTER.

   CONFIG.DATA_FILTER_PARAMETERS = %DF_CHANGED%
   CONFIG.DATA_FILTER_DIMENSIONS = [d/COST_CENTER]
   
   MEMBERSET [d/ACCOUNT] = ("SALARIES", "SOC_SEC")
   
   DATA([d/ACCOUNT] = "SOC_SEC") = RESULTLOOKUP([d/ACCOUNT] = "SALARIES") * 0.30

   El 30 % es un tipo de ejemplo; en un proyecto real vendría de una cuenta de supuestos o de un parámetro numérico. Dos detalles de la documentación que conviene saber:

   • A diferencia de los pasos de copia o de borrado, que aplican todas las dimensiones que llegan en el filtro, la advanced formula solo aplica las que declares en CONFIG.DATA_FILTER_DIMENSIONS.
   • La advanced formula usa la jerarquía por defecto de la dimensión, sea cual sea la del filtro. Si haces referencia a miembros de esa dimensión en DATA() o RESULTLOOKUP(), o el filtro es asimétrico, configura también CONFIG.HIERARCHY.

   Pulsa Validate: la fórmula debe validar sin errores («No errors found»).

   

   Añade un starter “Recalcular cargas sociales” en la story con la versión destino Forecast. DF_CHANGED es privado, así que el usuario no ve ninguna pregunta.

Validación

No des el caso por bueno hasta comprobar estas cosas, en este orden:

1. La exclusión se respeta. Ejecuta “Refrescar forecast con real”. Para los centros incluidos, el Forecast de enero a septiembre debe ser igual al Actual. El de CC_9900 no debe cambiar ni un céntimo, y tampoco los meses de octubre a diciembre. Con los datos de ejemplo (enero–septiembre de 2026, AMOUNT):

   Centro de coste	Actual	Forecast antes	Forecast después
   CC_1000	756.782,29	769.608,00	756.782,29
   CC_1100	595.614,38	598.032,00	595.614,38
   CC_2000	454.847,73	459.990,00	454.847,73
   CC_3000	678.741,84	687.636,00	678.741,84
   CC_4000	354.445,43	364.536,00	354.445,43
   CC_9900	552.054,93	561.294,00	561.294,00
   Total	3.392.486,60	3.441.096,00	3.401.725,67

   

2. El Job Monitor cuenta lo mismo. Abre la ejecución en el Job Monitor. En Steps, «Limpiar forecast en ámbito» debe mostrar 180 registros y «Copiar real a forecast», otros 180: 5 centros × 4 cuentas × 9 meses. Esa es la prueba objetiva de que la exclusión y el rango de fechas llegaron a la data action. En Parameters, «Ámbito de la story» muestra COST_CENTER (All) y Date Current Year: el Job Monitor enseña la etiqueta del control, no la lista de miembros, así que no te fíes de ese «(All)». La prueba de verdad son los 180 registros.

   

3. Publica antes de seguir. Comprobados los datos, publica la versión Forecast con Publish Data. Si no lo haces, lo que acaba de escribir el refresco cuenta como cambios de la versión y la siguiente prueba no te dirá nada (mira el recuadro de abajo).

4. Solo se recalcula lo modificado. Vas a cambiar en CC_3000 los salarios de octubre de 2026 de 55.080,00 a 60.000,00, y eso no se puede hacer en la tabla de la primera página. Esa tabla muestra el total de enero–septiembre por centro de coste, sin Date ni ACCOUNT, y su filtro de fechas deja fuera octubre. Si escribieras ahí, SAC repartiría el importe entre todas las cuentas y meses del ámbito. Y no conviene tocar ese filtro, porque es el que usa el starter del refresco. Por eso yo añadí una segunda página con una tabla sin esos filtros: COST_CENTER y ACCOUNT en filas (filtrando IT y Corporate overhead) y Version y Date en columnas. En Date, clic derecho → Select Hierarchy → «Show only leaves in widget» para ver los meses sin subtotales. Pon Forecast en edición y cambia ahí la celda de salarios de octubre.

   Ejecuta “Recalcular cargas sociales”. En el Job Monitor, en Parameters, la sección Auto-determined by version changes debe mostrar solo CC_3000, y el paso «Cargas sociales», 12 registros. En ese centro, SOC_SEC de octubre pasa de 16.524,00 a 18.000,00. Fíjate también en enero–septiembre: pasa de 151.091,47 (el 31,2 % que venía del real) a 145.280,22. Como solo rastreamos el centro de coste, se recalculan todos los meses de CC_3000, no solo octubre. Si quieres acotar también el mes, añade Date al filtro de cambios, con el producto cartesiano en mente. Los demás centros no se tocan: en la tabla principal, el Forecast de enero–septiembre de IT queda en 672.930,59.

   

   

5. Sin cambios, sin ejecución útil. Publica la versión y vuelve a ejecutar DA_SOC_SEC. Sin cambios en la versión, el Job Monitor muestra DF_CHANGED «(No change detected)» y el paso escribe 0 registros. Es el comportamiento esperado, no un error.

   

Errores habituales

Síntoma	Causa	Solución
El starter avisa de que el filtro no es compatible	El parámetro es de miembro: no admite exclusiones, rangos ni más de 100 miembros	Cambia el parámetro a Data Filter y vuelve a asignar los filtros en el starter
Aviso o error por superar 1.000 miembros	Un script pasa una lista grande a un parámetro de miembro	Asigna el input control a un data filter parameter, que no tiene ese límite
En una multi action la data action procesa todo	El data filter de la data action no está enlazado con un parámetro de la multi action	Crea el parámetro data filter en la multi action y enlázalo en el paso
DA_SOC_SEC recalcula centros que el usuario no ha tocado	La versión tiene cambios sin publicar de otra data action (por ejemplo, el refresco)	Publica la versión antes de empezar a introducir datos, o revisa en el Job Monitor qué miembros llegaron en Auto-determined by version changes
DA_SOC_SEC no hace nada	No hay cambios en la versión de referencia (o se publicó antes de ejecutar)	Comprueba la versión del filtro y revisa la sección del Job Monitor
La ejecución se para por demasiados miembros	Demasiadas dimensiones en el filtro de cambios: el ámbito es el producto cartesiano	Deja solo las dimensiones con pocos miembros modificados (centro de coste, producto…)
La advanced formula escribe en nodos inesperados	Usa la jerarquía por defecto, no la del filtro	Declara CONFIG.HIERARCHY para esa dimensión
La importación rechaza filas	El formato de DATE no se ha leído como yyyymm o la versión no está asignada	Revisa el formato en Review Settings del mapeo y la versión por defecto

Siguiente paso

Haz inventario de tus starters y scripts: cada parámetro de miembro que solo sirve para acotar el ámbito es candidato a pasar a data filter. Empezaría por dos tipos: los que hoy obligan al usuario a reseleccionar a mano lo que ya ha filtrado en la story y los scripts que construyen listas largas de miembros, que tienen fecha de caducidad en el Q2 de 2027. El filtro de cambios lo reservaría para cálculos caros que el usuario lanza después de introducir datos. Ahí es donde se nota en tiempos.

Fuentes

• Create a Model from Scratch (SAP Help Portal)
• Add, Delete, and Edit Dimensions and Measures (SAP Help Portal)
• Import and Prepare Fact Data in a Standard Model (SAP Help Portal)
• About Date and Time Range Filters (SAP Help Portal)
• About the Filter By Member Dialog for Story and Page Filters (SAP Help Portal)
• Add Parameters to Your Data Actions and Multi Actions (SAP Help Portal, Q3 2026)
• Set Up Starters (SAP Help Portal)
• Add Steps to Your Data Actions (SAP Help Portal)
• Understand General Rules for Advanced Formula Calculations for Planning (SAP Help Portal)
• What’s New – 2026 Releases (SAP Help Portal)
• Improved Data Action scoping with the new Data Filter Parameter type (SAP Community)
• Context Aware Data Action Scoping (SAP Community)
• Upcoming Change: Member Limit Enforcement for Data Action Parameters (SAP Community)
• The release cycle of SAP Analytics Cloud in 2026 (McCoy & Partners)