En entornos SAP de alto volumen, el análisis de resultados no es sólo una actividad contable de fin de período, sino un mecanismo de control operativo diario.

Sin embargo, muchas organizaciones descubren que el modelo de ejecución estándar para transacciones KKAK nunca fue diseñado para la escala y la intensidad de las transacciones de las empresas modernas basadas en contratos.

Este post tiene como objetivo guiar Finanzas SAP expertos en implementar una solución innovadora para un cuello de botella de rendimiento común. Si bien los pasos técnicos son sencillos, esta guía está diseñada para ayudarlo a liderar el proyecto, potencialmente en colaboración con un ABAP desarrollador si decide no ejecutar los componentes técnicos solo. Al cerrar la brecha entre los requisitos funcionales y la ejecución técnica, puede lograr un ciclo de análisis de resultados (RA) de alto rendimiento que mantenga intacto el núcleo limpio.

El problema empresarial: análisis de resultados diarios a escala

En muchas organizaciones orientadas a la contratación y a los servicios, cada trabajo se representa como un contrato en SAP. Estas empresas a menudo operan en docenas o incluso cientos de sucursales en todo el país, y crean nuevos contratos diariamente, a menudo superando los mil por día. La huella operativa es grande, distribuida y cambia continuamente. En tales entornos, la visibilidad financiera no puede esperar hasta el final del período.

¿Por qué las empresas deben realizar análisis de resultados (RA) diariamente?

Realizar análisis de resultados diariamente no es un lujo, sino una necesidad operativa.

• Visibilidad del trabajo en progreso (WIP): Sin RA diario, los equipos de finanzas no pueden determinar qué valor se ha ganado pero aún no se ha facturado. Esto afecta directamente la preparación de facturación, la previsión del flujo de caja y el momento de los ingresos.
• Costo de ventas (COS) y salud del proyecto: RA es la base para reconocer los costos frente a los ingresos. Sin un costo de ventas actualizado, las organizaciones pierden visibilidad de la rentabilidad del proyecto, la erosión de los márgenes y las señales de alerta temprana sobre contratos de bajo rendimiento.
• El fin de mes es demasiado tarde: Esperar hasta el final del período para evaluar la realidad financiera crea un importante punto ciego para la organización. Los problemas financieros y operativos a menudo se identifican sólo después de que ya se han producido daños materiales, lo que deja poco margen para su reparación. Los sobrecostos del proyecto pueden permanecer ocultos durante semanas, lo que permite que el aumento de costos y la erosión de los márgenes pasen desapercibidos. Cuando estos problemas surgen a fin de mes, los equipos operativos ya han perdido la oportunidad de tomar medidas correctivas, ajustar las estrategias de ejecución o interactuar de manera proactiva con las partes interesadas. En entornos contractuales de gran volumen y de rápida evolución, esta visibilidad retrasada es especialmente perjudicial. La información financiera diaria proporciona un control de salud significativo y procesable que permite una toma de decisiones oportuna y un control financiero eficaz.

Por qué el KKAK estándar se vuelve inviable a escala

La ejecución de análisis de resultados estándar de SAP a través de la transacción KKAK está diseñada fundamentalmente para priorizar la integridad y la precisión contable. Sin embargo, cuando se aplica a entornos de gran volumen y gran escala, este mismo diseño se convierte en un cuello de botella en el rendimiento. De forma predeterminada, KKAK evalúa todos los contratos que no están en estado CERRADO o TECO, independientemente de si un contrato experimentó alguna actividad financiera u operativa el día de la ejecución. Por lo tanto, cada ejecución reprocesa una gran población de contratos activos, incluso cuando la mayoría permanece sin cambios.

En organizaciones que administran decenas o cientos de miles de contratos activos, con creación continua de contratos en múltiples ubicaciones y publicaciones operativas diarias, este enfoque genera tiempos de ejecución excesivos que a menudo se extienden hasta varias horas. A medida que crece el volumen de datos, el tiempo de ejecución de KKAK aumenta de forma no lineal, lo que rápidamente hace que la ejecución diaria sea operativamente poco práctica. Luego, los equipos de finanzas se ven obligados a aceptar una disyuntiva insostenible: retrasar el análisis de resultados y operar sin una visibilidad financiera oportuna, o programar KKAK como un trabajo prolongado durante la noche que consume recursos sustanciales del sistema y corre el riesgo de superponerse con otros procesos por lotes críticos.

La tensión central

Si bien el negocio requiere un análisis de resultados diario para mantener una visibilidad financiera y un control operativo precisos, el modelo de ejecución estándar no está diseñado para escalar de manera eficiente a volúmenes diarios en entornos de alta transacción. Esta desconexión entre la necesidad financiera y la viabilidad técnica es donde muchas organizaciones luchan, creando una tensión continua entre las expectativas comerciales y las limitaciones del sistema. Para abordar esta brecha se requiere una optimización específica, un enfoque que preserve la integridad contable y al mismo tiempo permita que el análisis de resultados se ejecute a la velocidad y escala que exigen las operaciones modernas de gran volumen.

El camino del alto rendimiento: selección quirúrgica

El análisis de resultados sólo es pertinente para objetos de costo que han experimentado un cambio en el valor monetario desde el ciclo de análisis anterior. En consecuencia, el proceso debe restringirse a objetos de costo que hayan incurrido en contabilizaciones financieras o CO reales dentro de un período de tiempo específico. En esta discusión, exploramos la necesidad de realizar análisis de resultados diariamente.

Sin embargo, surge un desafío importante: ¿realmente vale la pena o es prudente introducir código personalizado en una solución SAP estándar? En las siguientes secciones, demostraremos cómo implementar un proceso de análisis de resultados diario sin agregar ninguna mejora personalizada a la transacción estándar KKAK.

Pasos para implementar la solución

La solución se centra en un trabajo en segundo plano de varios pasos diseñado para automatizar el proceso de selección.

Paso 1: recopilación de datos y actualización de variables

El primer paso del trabajo consiste en recopilar los objetos de coste relevantes. En el ejemplo de código que se proporciona más adelante en esta sección, identificamos los contratos específicos que requieren análisis. Luego, esta lista se actualiza en una variable de selección (TVARVC), a la que llamaremos ZCONTRACT_LIST_KKAK.

Identificación de contratos relevantes

Para recuperar la lista de contratos activos, nos centramos en los documentos con actividad reciente. Si bien el siguiente ejemplo demuestra la selección de datos de la tabla COBK, los sistemas que utilizan completamente la arquitectura SAP S/4HANA y Universal Journal deben aprovechar la tabla ACDOCA para un rendimiento óptimo. Es necesario crear un nuevo programa ejecutable con las siguientes especificaciones.

1. Seleccione documentos publicados hoy: Primero, identifique todos los documentos publicados dentro de la sociedad CO relevante para la fecha actual.

SELECT * FROM cobk
  WAQUÍ kokrs = 'PRUEBA'
Y cpudt = @sy-datum
  ORDER BY PRIMARY KEY
EN LA MESA @it_cobk.

2. Filtrar por tipo de objeto de costo: A partir de este conjunto de datos, filtre los documentos que pertenecen a códigos de empresa específicos (si es necesario) que se publicaron en un contrato o en una orden de servicio. En escenarios donde un contrato de documento de ventas sirve como objeto de costo principal, los ingresos generalmente se contabilizan en el contrato mientras que los costos se capturan en la orden de servicio. Por lo tanto, es esencial comparar las publicaciones con ambos tipos de objetos para garantizar un análisis completo de los resultados.

3. Extracción de detalles del objeto de costo: Una vez identificados los documentos de encabezado, recuperamos los detalles de los artículos en línea para aislar los documentos de ventas específicos (contratos) u órdenes internas involucradas.

*------------------------------------------------------------------*

* Retrieve line items for the identified CO documents

*------------------------------------------------------------------*

SELECT * FROM coep

FOR ALL ENTRIES IN @it_cobk

WHERE kokrs = ‘TEST’

    AND belnr = @it_cobk_belnr

    AND gjahr = @it_cobk_gjahr

    AND ( accasty = ‘VB’ OR accasty = ‘OR’ ) “ Sales Document (VB) or Order (OR)

    AND bukrs = ‘TEST’

ORDER BY PRIMARY KEY

INTO TABLE @DATA(it_coep).

4. Asignación de órdenes a contratos principales: Debido a que los costos pueden contabilizarse en una orden de servicio mientras que el análisis de resultados debe ejecutarse a nivel de contrato, utilizamos un bucle para resolver la relación «orden a contrato».

LOOP AT it_coep INTO DATA(ls_coep).

    CASE ls_coep-accasty.

        WHEN ‘VB’.

            “ Direct assignment if the posting is already on the Contract

            gs_data-contract = |{ ls_coep-vbeln ALPHA = OUT }|

        WHEN ‘OR’.

            “ If posted to an Order, find the associated Sales Document from AUFK

            SELECT SINGLE kdauf FROM aufk

                WHERE aufnr = @ls_coep-aufnr

                INTO @DATA(lv_kdauf).

            gs_data-contract = |{ lv_kdauf ALPHA = OUT }|.

        WHEN OTHERS.

            CONTINUE.

    ENDCASE.

    APPEND gs_data TO gt_data.

    CLEAR gs_data.

ENDLOOP.

      “ Cleanse the list to ensure unique contract entries

      SORT gt_data BY contract.

      DELETE ADJACENT DUPLICATES FROM gt_data COMPARING contract.

Para actualizar la tabla TVARVC, debemos manejar los datos como una «opción de selección» (Signo, Opción, Bajo, Alto). Dado que gt_data contiene una lista de contratos individuales, completaremos la tabla con varias filas bajo el mismo nombre de variable, usando la lógica I (incluir) y EQ (igual).

*-------------------------------------------------------------------*

* Update TVARVC variable with the list of identified contracts

*-------------------------------------------------------------------*

DELETE FROM tvarvc WHERE name = ‘ZCONTRACT_LIST_KKAK’ AND type = ‘S’.

IF gt_data[] IS NOT INITIAL.

    LOOP AT gt_data INTO DATA(ls_data).

        DATA(ls_tvarvc) = VALUE tvarvc(

            mandt = sy-mandt

            name = ‘ZCONTRACT_LIST_KKAK’

            type = ‘S’                  “ S = Selection Option

            numb = sy-tabix

            sign = ‘I’                  “ I = Include

            opti = ‘EQ’                 “ EQ = Equal

            low = ls_data_contract

        ).

        INSERT tvarvc FROM ls_tvarvc.

    ENDLOOP.

    COMMIT WORK.

ENDIF.

Información estratégica: optimización de la selección con TVARVC

Al implementar esta lógica, hay tres consideraciones técnicas críticas que se deben tener en cuenta para garantizar que la solución siga siendo sólida y eficaz:

• Utilización del tipo 'S': Usamos el tipo 'S' (opción de selección) en la tabla TVARVC porque la pantalla de selección estándar para la transacción KKAK (programa SAPKKA02BG) utiliza opciones de selección para el campo Documento de ventas. Esto permite que el sistema digiera una lista de múltiples valores individuales.
• La necesidad de limpieza: La declaración DELETE al inicio de la rutina es vital. Garantiza que la variable se elimine de los datos del día anterior. Sin esto, la lista crecería acumulativamente, provocando eventualmente que el trabajo procese registros obsoletos que ya no requieren un análisis diario.
• Valores discretos frente a rangos: Es una elección arquitectónica deliberada completar la lista con números de contrato discretos en lugar de un rango (alto/bajo). En muchos entornos SAP, los números de contrato no son secuenciales o pueden estar distribuidos en un vasto espacio numérico. El uso de un rango capturaría inadvertidamente miles de contratos inactivos, lo que obligaría al sistema a evaluarlos innecesariamente. Al aprobar solo los contratos específicos con publicaciones diarias, mantenemos el trabajo ágil y de alto rendimiento, cumpliendo directamente nuestro objetivo de una ejecución quirúrgica basada en actividades.

Paso 2: Ejecutar la transacción KKAK

En el segundo paso del mismo trabajo en segundo plano, la variable ZCONTRACT_LIST_KKAK se pasa al campo del documento de ventas (VBELN) en la pantalla de selección. Esto se gestiona mediante una variante específica del programa SAPKKA02BG (el programa ejecutable para la transacción KKAK).

Configuración de la variante de selección para KKAK

Una vez que el programa ABAP completa la variable ZCONTRACT_LIST_KKAK, se debe indicar al programa de análisis de resultados estándar que busque allí sus entradas.

1. Crea la variante: Vaya a la transacción KKAK (o SE38 para el programa SAPKKA02BG) y defina una nueva variante. En la pantalla de selección, busque el campo Documento de ventas (VBELN).

2. Vincular la variable dinámica: En lugar de ingresar números de contrato, haga clic en el botón de selección de variable (generalmente la pantalla de atributos de la variante). Para el campo del documento de ventas, cambie el tipo de variable de selección a 'T' (variable de tabla de TVARVC). En la columna de nombre de variable, seleccione nuestra variable personalizada: ZCONTRACT_LIST_KKAK.

Paso 3: Coordinar el trabajo en segundo plano (SM36)

La última pieza del rompecabezas es la programación. Para que la solución sea perfecta, ambos pasos deben ejecutarse en una sola unidad de trabajo.

1. Programe su programa ABAP personalizado (el que identifica la actividad y actualiza TVARVC).
2. Programe el programa estándar SAPKKA02BG utilizando la variante creada en el paso anterior.

Así es como se ven los pasos del trabajo en segundo plano.

Conclusión

Al aprovechar un recopilador personalizado simple y las capacidades variables dinámicas estándar de la pantalla de selección de SAP, hemos creado un proceso de análisis de resultados diario automatizado y de alto rendimiento. Lo más importante es que lo hemos hecho manteniendo intacta la filosofía central limpia, evitando cualquier modificación al código estándar de SAP.