Su Template de datos de Record to Report - Asiento contable
Su Template de datos de Record to Report - Asiento contable
- Atributos recomendados que debe recopilar
- Actividades clave que debe seguir
- Recomendaciones prácticas para la extracción
Record to Report - Atributos de los asientos contables
| Nombre | Descripción | ||
|---|---|---|---|
| Actividad ActivityName | Nombre de la actividad empresarial que tuvo lugar en un momento concreto del proceso de asientos contables. | ||
| Descripción La actividad representa un paso o evento específico del ciclo de vida de un asiento contable, como «Journal Entry Created», «Journal Submitted For Review» o «Journal Entry Posted». Estas actividades suelen derivarse de registros de cambios, actualizaciones de estado o códigos de transacción registrados en el sistema. Analizar las actividades permite visualizar el flujo del proceso, identificar las rutas habituales y descubrir desviaciones respecto del procedimiento estándar. Es fundamental para calcular métricas como la frecuencia de las actividades, los tiempos de espera entre pasos y las tasas de conformidad. Por qué es importante Define los pasos del proceso y permite visualizar los mapas de procesos y analizar los patrones del Workflow. Dónde obtenerlo Se obtiene de diversas fuentes, incluidos los campos de estado de las tablas de cabecera y posiciones, como BKPF-BSTAT, los registros de documentos de cambios (CDHDR/CDPOS) y los registros del Workflow. Ejemplos Asiento contable creadoAsiento contable aparcadoAsiento contable enviado para revisiónAsiento contable aprobadoAsiento contable contabilizado | |||
| Hora del evento EventTime | Marca de tiempo que indica cuándo tuvo lugar una actividad concreta del asiento contable. | ||
| Descripción La hora del evento es la fecha y hora exactas en que una actividad empresarial se ejecutó y registró en el sistema. Cada actividad de un caso tiene su propia marca de tiempo, lo que crea una secuencia cronológica de eventos. Este Atributo es fundamental para todo análisis de procesos basado en el tiempo. Se utiliza para calcular tiempos de ciclo, duraciones entre actividades y tiempos de espera, así como para comprender la distribución temporal del trabajo. Las marcas de tiempo precisas son esenciales para construir un modelo de proceso fiable y calcular indicadores clave de rendimiento, como el tiempo del ciclo de aprobación. Por qué es importante Proporciona el orden cronológico de los eventos, esencial para calcular todas las métricas basadas en la duración y comprender la línea temporal del proceso. Dónde obtenerlo Se obtiene de los registros de documentos de cambios (CDHDR-UDATE, CDHDR-UTIME), los registros del Workflow o las marcas de tiempo de creación o entrada de tablas como BKPF (CPUDT, CPUTM). Ejemplos 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| ID del asiento contable JournalEntryId | Identificador único de un asiento contable financiero, que actúa como identificador principal del caso en el proceso. | ||
| Descripción El ID del asiento contable es un número único asignado a cada documento contable cuando se crea en SAP S/4HANA. Este identificador es esencial para realizar el seguimiento del ciclo de vida completo de un asiento contable, desde su creación o aparcamiento inicial, pasando por los Workflow de aprobación, hasta su contabilización final y una posible anulación o compensación. En el análisis de process mining, este ID se utiliza para vincular todas las actividades relacionadas en un único caso. Al agrupar los eventos bajo un ID de asiento contable común, las personas analistas pueden reconstruir el flujo integral del proceso, medir los tiempos de ciclo e identificar variaciones o cuellos de botella de cada transacción financiera. Es el Atributo fundamental para construir toda la vista del proceso. Por qué es importante Este identificador conecta todos los pasos relacionados del proceso y permite analizar el recorrido integral de cada asiento contable. Dónde obtenerlo Es una clave compuesta que normalmente se forma concatenando el código de sociedad (BKPF-BUKRS), el número de documento (BKPF-BELNR) y el ejercicio fiscal (BKPF-GJAHR). Ejemplos 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Fecha de contabilización PostingDate | La fecha en la que el asiento contable se registra en el libro mayor y que determina el periodo financiero. | ||
| Descripción La fecha de contabilización determina el periodo fiscal en el que la transacción aparecerá en los estados financieros. Es una fecha fundamental para la contabilidad y puede diferir de la fecha en la que se creó el documento o se introdujo en el sistema. En Process Mining, la fecha de contabilización se utiliza para realizar análisis de cohortes basados en el tiempo, como comparar los procesos de cierre de fin de mes o analizar las tendencias de rendimiento en distintos periodos financieros. También permite medir los retrasos entre la creación del asiento y su contabilización financiera efectiva. Por qué es importante Es fundamental para contextualizar la información financiera y permite analizar el rendimiento del proceso en periodos contables concretos, como el cierre mensual o anual. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo BUDAT (fecha de contabilización del documento). Ejemplos 2023-10-312023-11-012024-02-29 | |||
| Importe en moneda local AmountInLocalCurrency | El valor total del asiento contable expresado en la moneda local de la sociedad. | ||
| Descripción Este atributo representa la magnitud financiera del asiento contable. Normalmente corresponde a la suma de los valores absolutos de todas las posiciones de débito o crédito del documento, convertidos a la moneda local de la sociedad. Analizar los importes permite segmentar el proceso según su impacto financiero. Por ejemplo, los asientos de importe elevado pueden seguir un proceso de aprobación más riguroso que los de importe reducido. Esto ayuda a priorizar las iniciativas de mejora en las transacciones que presentan el mayor riesgo financiero. Por qué es importante Proporciona el valor financiero del asiento y permite analizar cómo cambia el comportamiento del proceso en función del importe en juego. Dónde obtenerlo Se calcula sumando los importes de la tabla de posiciones BSEG, campo DMBTR, para un asiento contable determinado, BELNR, y convirtiendo el resultado en un valor positivo. Ejemplos 1500.75125000.0050.20 | |||
| Sociedad CompanyCode | El identificador único de la empresa o entidad jurídica para la que se registra el asiento contable. | ||
| Descripción La sociedad es una unidad organizativa fundamental en SAP Financials y representa una entidad jurídica independiente para la que se elaboran estados financieros. Cada asiento contable se asigna a una sociedad específica. Este atributo es esencial para segmentar y comparar el rendimiento del proceso entre distintas partes de la organización. Los analistas pueden utilizarlo para filtrar la vista del proceso por una entidad jurídica concreta, comparar las tasas de rechazo entre sociedades o identificar variaciones del proceso específicas de una región. Por qué es importante Permite filtrar y comparar el proceso de asientos contables entre distintas entidades jurídicas o unidades de negocio de la organización. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo BUKRS (sociedad). Ejemplos 10001710US01 | |||
| Tipo de asiento contable JournalEntryType | Clasifica el asiento contable según su finalidad empresarial, como un registro de activo, una factura de proveedor o un asiento del libro mayor. | ||
| Descripción El tipo de asiento contable, denominado tipo de documento en la terminología de SAP, es una clave que categoriza los documentos contables. Controla aspectos como el rango de números asignado al documento y los tipos de cuenta permitidos para el registro. Analizar el proceso por tipo de asiento contable es fundamental para comprender comportamientos específicos del contexto. Por ejemplo, el proceso de aprobación de una periodificación sencilla, de tipo SA, puede ser mucho más simple que el de una adquisición compleja de activos, de tipo AA. Esta dimensión es clave para el panel «Cumplimiento por tipo de asiento». Por qué es importante Clasifica los asientos según su contexto empresarial y permite analizar las variaciones y el rendimiento del proceso para distintos tipos de transacciones financieras. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo BLART (tipo de documento). Ejemplos SAKRAA | |||
| Usuario creador CreatedByUser | El ID de usuario de la persona que creó el asiento contable. | ||
| Descripción Este atributo almacena el identificador único del usuario que inició el proceso del asiento contable al crear el documento inicial. Puede tratarse de un contable, un usuario de negocio o un ID de sistema para asientos automatizados. Analizar el proceso por creador ayuda a identificar patrones relacionados con usuarios o equipos concretos. Puede revelar necesidades de formación si determinados usuarios presentan tasas de rechazo más elevadas, o destacar a las personas con mejor rendimiento. Es esencial para el panel «Actividad y rendimiento de los usuarios». Por qué es importante Asigna las actividades del proceso a usuarios concretos, lo que permite analizar el rendimiento, equilibrar la carga de trabajo e identificar oportunidades de formación. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo USNAM (nombre de usuario). Ejemplos ABROWNCJONESBATCH_USER | |||
| Código de transacción TransactionCode | El código de transacción de SAP utilizado para crear o modificar el asiento contable. | ||
| Descripción El código de transacción, o T-Code, es un acceso directo que identifica una función o un programa específico de SAP. En los asientos contables, distintos T-Code pueden indicar cómo se creó el asiento, por ejemplo, FB01 para una contabilización manual en el libro mayor, FV50 para aparcar un documento o un código automatizado para asientos generados por el sistema. Este atributo es un indicador sólido de si una actividad la realizó manualmente un usuario o automáticamente el sistema. Es clave para calcular el KPI de tasa de contabilización manual e identificar oportunidades de automatización. Por qué es importante Indica cómo se procesó un asiento, por ejemplo, de forma manual o automática, algo clave para analizar la automatización y comprender las variaciones del proceso. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo TCODE (código de transacción). Ejemplos FB01FV50F-02 | |||
| Ejercicio fiscal FiscalYear | El ejercicio fiscal al que pertenece el asiento contable. | ||
| Descripción El ejercicio fiscal forma parte de la clave única de un asiento contable, junto con la sociedad y el número de documento. Representa el año financiero en el que el documento es relevante. En el análisis, el ejercicio fiscal se utiliza para analizar tendencias a largo plazo y garantizar la unicidad del identificador del caso. Comparar las métricas del proceso entre distintos ejercicios fiscales puede revelar mejoras o deterioros del rendimiento a lo largo del tiempo. Por qué es importante Aporta un componente esencial para identificar documentos de forma única y permite analizar el rendimiento del proceso interanual. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo GJAHR (ejercicio fiscal). Ejemplos 202320242022 | |||
| Es contabilización manual IsManualPosting | Un indicador booleano que señala si el asiento contable fue contabilizado manualmente por un usuario. | ||
| Descripción Este atributo identifica los asientos contables contabilizados mediante la intervención manual de un usuario, en lugar de hacerlo automáticamente un job del sistema o una interfaz. Normalmente se deriva del código de transacción utilizado para contabilizar el documento. Este indicador se utiliza para calcular el KPI de tasa de contabilización manual y ayuda a las organizaciones a seguir sus avances en la automatización del proceso Record to Report. Al filtrar los asientos contabilizados manualmente, los analistas pueden identificar los escenarios concretos que todavía requieren intervención humana y evaluar su potencial de automatización. Por qué es importante Distingue entre contabilizaciones realizadas por personas y por el sistema, algo fundamental para medir los niveles de automatización e identificar oportunidades de automatización. Dónde obtenerlo Es un atributo calculado a partir de TransactionCode. Una lista predefinida de códigos de transacción manuales, como «FB01» o «F-02», se utiliza para establecer el indicador en «true». Ejemplos truefalse | |||
| Es retrabajo IsRework | Un indicador booleano que señala si el asiento contable ha sido objeto de retrabajo, por ejemplo, si se corrigió después de un rechazo. | ||
| Descripción Este atributo calculado identifica los asientos contables que se han desviado del proceso ideal o «camino feliz». Normalmente se establece en true si dentro del caso se produce una actividad como «Asiento contable rechazado» o «Asiento contable corregido». Este indicador simplifica el análisis de la eficiencia del proceso. Permite calcular rápidamente el KPI de tasa de retrabajo y comparar directamente los tiempos de ciclo y los costes entre los casos con retrabajo y sin él. Identificar los factores que provocan retrabajo es un objetivo prioritario de muchas iniciativas de mejora de procesos. Por qué es importante Identifica los casos que requirieron correcciones o ciclos adicionales y permite cuantificar fácilmente las ineficiencias del proceso y analizar sus causas raíz. Dónde obtenerlo Es un atributo calculado a partir de la secuencia de actividades de un caso. Se marca como «true» si está presente una actividad como «Asiento contable rechazado». Ejemplos truefalse | |||
| Estado del documento DocumentStatus | El estado actual de procesamiento del asiento contable, como aparcado, contabilizado o compensado. | ||
| Descripción El estado del documento indica en qué punto de su ciclo de vida se encuentra el asiento contable. Por ejemplo, un documento «aparcado» se ha guardado, pero todavía no se ha contabilizado en el libro mayor, mientras que un documento «contabilizado» ya está finalizado. Analizar el estado ayuda a comprender el flujo de trabajo e identificar cuellos de botella. Un volumen elevado de documentos que permanecen durante mucho tiempo en estado «aparcado» o «pendiente de aprobación» puede indicar ineficiencias en el proceso. También es una fuente clave para derivar las actividades del proceso. Por qué es importante Ofrece una visión del punto del ciclo de vida en el que se encuentra un asiento contable y ayuda a identificar colas y cuellos de botella. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo BSTAT (estado del documento). Ejemplos VAB | |||
| Hora de finalización EndTime | La marca de tiempo que indica cuándo se completó la actividad. | ||
| Descripción La hora de finalización marca la conclusión de una actividad. En muchos registros de eventos, la hora de inicio y la hora de finalización de una actividad coinciden, ya que representan un evento instantáneo. Sin embargo, en actividades con una duración medible, como la revisión activa de un documento por parte de un usuario, este atributo puede registrar dicha duración. Contar con una hora de finalización diferenciada permite calcular con mayor precisión los tiempos de procesamiento de las actividades frente a los tiempos de espera. Así se distingue el tiempo durante el que se trabajó activamente en una tarea del tiempo que permaneció inactiva en una cola. Por qué es importante Permite calcular con precisión los tiempos de procesamiento de las actividades y separar el tiempo de trabajo activo del tiempo de espera inactivo. Dónde obtenerlo Normalmente coincide con StartTime en eventos atómicos. En actividades con duración, puede obtenerse de los registros del Workflow o calcularse a partir de eventos posteriores. Ejemplos 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Motivo de reversión ReversalReason | Un código que indica el motivo por el que se revirtió un asiento contable contabilizado. | ||
| Descripción Cuando un asiento contable contabilizado es incorrecto, no puede eliminarse, sino que debe revertirse mediante un documento nuevo. El código de motivo de reversión explica por qué se realizó esta acción, por ejemplo, debido a una fecha de contabilización o un importe incorrectos. Analizar los motivos de reversión ayuda a identificar las causas raíz de los errores en el proceso Record to Report. Una frecuencia elevada de un motivo concreto puede señalar problemas sistémicos, como una formación insuficiente o fallos de control, que deben abordarse para mejorar la calidad a la primera. Por qué es importante Ayuda a diagnosticar la causa raíz de los errores que provocan reversiones y proporciona información para reducir el retrabajo y mejorar la calidad del proceso. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo STGRD (motivo de reversión). Ejemplos 010205 | |||
| Sistema de origen SourceSystem | Identifica el sistema de origen del que se extrajeron los datos de los asientos contables. | ||
| Descripción Este atributo especifica el sistema de registro del que proceden los datos del asiento contable. En empresas con varias instancias de ERP o una combinación de sistemas heredados y modernos, permite diferenciar las fuentes de datos. En el análisis, puede utilizarse para comparar el rendimiento del proceso entre distintos sistemas o para filtrar los datos de un origen específico. Es importante para la gobernanza de datos y para garantizar que se comprenda el contexto de los datos. Por qué es importante Proporciona contexto sobre el origen de los datos, algo fundamental en entornos con varios sistemas para realizar análisis y comparaciones precisos del proceso. Dónde obtenerlo Normalmente es un valor estático que se añade durante la extracción de datos e identifica la instancia específica de SAP S/4HANA, por ejemplo, el SID o el nombre del sistema lógico. Ejemplos S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Tiempo de ciclo de aprobación ApprovalCycleTime | El tiempo transcurrido desde que se envió un asiento contable para su aprobación hasta que se aprobó o rechazó. | ||
| Descripción Esta métrica calculada se centra específicamente en la duración de la fase de aprobación. Mide el tiempo entre la actividad «Asiento contable enviado para revisión» y la actividad posterior «Asiento contable aprobado» o «Asiento contable rechazado». Este KPI es fundamental para identificar cuellos de botella en el Workflow de aprobación. Un tiempo de ciclo de aprobación elevado puede retrasar considerablemente el proceso general. Analizar esta métrica por aprobador, sociedad o tipo de asiento contable puede revelar áreas concretas de mejora. Por qué es importante Aísla la duración del paso de aprobación y ayuda a localizar y resolver cuellos de botella en el Workflow de revisión y aprobación. Dónde obtenerlo Se calcula obteniendo la diferencia de tiempo entre el evento «Asiento contable enviado para revisión» y el evento «Asiento contable aprobado» o «Asiento contable rechazado». Ejemplos 1 día 2 horas4 horas 25 minutos5 días 0 horas | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica la última vez que se actualizaron los datos de este registro desde el sistema de origen. | ||
| Descripción Este atributo registra la fecha y hora de la extracción o actualización más reciente de datos del sistema de origen. Proporciona transparencia sobre la actualidad de los datos analizados. Conocer la hora de la última actualización es importante para comprender la vigencia del análisis del proceso. Ayuda a interpretar correctamente los Dashboards y los KPI, ya que permite saber si se están consultando datos casi en tiempo real o una instantánea de un periodo anterior. Por qué es importante Indica la actualidad de los datos y permite saber hasta qué punto el análisis del proceso refleja la situación actual. Dónde obtenerlo Es un atributo de metadatos que normalmente se genera y se registra en cada registro durante el proceso de ingesta de datos. Ejemplos 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Usuario aprobador ApproverUser | El ID de usuario de la persona que aprobó o rechazó el asiento contable. | ||
| Descripción Este atributo identifica al usuario responsable de revisar y decidir sobre un asiento contable enviado. En un Workflow de aprobación multinivel, puede haber varios aprobadores para un mismo asiento contable. Esta información es esencial para analizar detalladamente el proceso de aprobación. Ayuda a medir la carga de trabajo de los distintos aprobadores, calcular sus tiempos individuales de aprobación e identificar cuellos de botella en la cadena de aprobación. Es compatible directamente con el panel «Actividad y rendimiento de los usuarios». Por qué es importante Identifica a la persona responsable de la aprobación y permite analizar la carga de trabajo, el rendimiento y los cuellos de botella de las aprobaciones. Dónde obtenerlo Se obtiene de los registros del Workflow, por ejemplo, SWW_WI2OBJ o SWWLOG, o de las tablas de documentos de modificación, CDHDR/CDPOS, mediante el seguimiento de quién ejecutó el paso de aprobación. Ejemplos DMILLERFWHITEKCHEN | |||
Record to Report - Actividades de los asientos contables
| Actividad | Descripción | ||
|---|---|---|---|
| Asiento contable aprobado | El asiento contable recibe la aprobación final de una persona responsable autorizada, que confirma su validez y exactitud. Esta actividad es el último control antes de que el documento pueda contabilizarse en el libro mayor. | ||
| Por qué es importante Este es un hito crítico que concluye el ciclo de aprobación. El tiempo necesario para llegar a este paso constituye una parte importante de la duración total del proceso y un indicador clave de la eficiencia de las personas aprobadoras. Dónde obtenerlo Este evento se infiere de un registro del Workflow que muestra el paso de aprobación final o un cambio de estado en el documento. El ID de usuario de la persona aprobadora y la marca de tiempo pueden obtenerse de los datos del Workflow o de los registros de cambios. Recopilar Identifique la marca de tiempo del paso de aprobación final en los registros del Workflow o el cambio de estado a «Approved» en los documentos de cambios. Tipo de evento inferred | |||
| Asiento contable compensado | Una posición abierta de un asiento contable se compensa con otra contabilización, como un pago que compensa una factura. Esta actividad marca la conciliación de posiciones concretas y las cierra efectivamente. | ||
| Por qué es importante Esta actividad representa el paso final de conciliación de muchos asientos contables, especialmente los relacionados con cuentas transitorias o gestionadas por posiciones abiertas. Analizar el tiempo transcurrido desde la contabilización hasta la compensación ayuda a medir la eficiencia de la conciliación. Dónde obtenerlo Este evento se infiere de la tabla de posiciones (BSEG o la vista ACDOCA). Cuando una posición se compensa, los campos de fecha de compensación (AUGDT) y documento de compensación (AUGBL) se completan para esa posición. Recopilar Utilice la fecha de compensación (BSEG-AUGDT) de la posición como marca de tiempo del evento. Tipo de evento inferred | |||
| Asiento contable contabilizado | El asiento contable se registra oficialmente en el libro mayor y afecta a los estados financieros de la empresa. Este es el momento en que el documento se convierte en un registro financiero permanente. | ||
| Por qué es importante Este es el principal hito de éxito y marca el final del ciclo central de procesamiento. Analizar el volumen de asientos contabilizados y el tiempo necesario para llegar a esta etapa son métricas fundamentales de process mining. Dónde obtenerlo Este es un evento explícito marcado por la fecha de contabilización (BUDAT) en la tabla BKPF. Un documento contabilizado tiene el estado del documento (BSTAT) en blanco, lo que lo distingue de los documentos aparcados («V») o retenidos («D»). Recopilar Utilice la fecha de contabilización (BKPF-BUDAT) y la fecha de entrada (BKPF-CPUDT) para asignar la marca de tiempo al evento. Un valor BKPF-BSTAT en blanco indica que el documento está contabilizado. Tipo de evento explicit | |||
| Asiento contable creado | Esta actividad marca la creación inicial de un documento de asiento contable en el sistema. El registro se crea en la tabla de cabecera (BKPF), pero todavía no se ha contabilizado en el libro mayor. Este es el punto de partida del ciclo de vida del asiento contable. | ||
| Por qué es importante Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde este evento hasta la contabilización es fundamental para medir el tiempo total del ciclo e identificar retrasos iniciales en la introducción de datos. Dónde obtenerlo Este evento puede capturarse explícitamente desde la tabla SAP BKPF mediante los campos de fecha de creación (CPUDT) y hora de creación (CPUTM) para un número de documento determinado (BELNR). Recopilar Utilice BKPF-CPUDT y BKPF-CPUTM para la marca de tiempo del evento. Tipo de evento explicit | |||
| Asiento contable enviado para revisión | La persona creadora del asiento contable envía formalmente el documento al Workflow de revisión y aprobación. Esta actividad representa el traspaso de la introducción de datos al proceso formal de control e inicia el ciclo de aprobación. | ||
| Por qué es importante Este punto marca el inicio del tiempo del ciclo de aprobación. Medir desde aquí hasta la aprobación o el rechazo final ayuda a aislar los cuellos de botella específicos de las etapas de revisión y aprobación. Dónde obtenerlo A menudo se captura a partir de los registros del Workflow, en las tablas SWW_WIHEAD y SWWLOG, vinculados al objeto empresarial. También puede inferirse de un cambio de estado en un campo personalizado de la cabecera del documento (BKPF). Recopilar Marca de tiempo de creación del elemento de Workflow o cambio de un campo de estado a «Submitted» o «In Review». Tipo de evento inferred | |||
| Proceso de anulación del asiento contable completado | Un asiento contable contabilizado previamente se anula mediante la creación de un nuevo documento con contabilizaciones inversas. Esta acción se realiza para corregir errores en documentos contabilizados y constituye una transacción explícita y auditable. | ||
| Por qué es importante Las anulaciones indican que se cometió un error en un documento contabilizado. Una tasa de anulación elevada sugiere problemas subyacentes en el proceso de aprobación o en la calidad de la introducción de datos, y su seguimiento ayuda a mejorar la precisión desde el primer intento. Dónde obtenerlo La anulación es un evento explícito. La cabecera (BKPF) del nuevo documento de anulación contiene una referencia al documento original en el campo Reversed Document No. (STBLG). La fecha de contabilización del nuevo documento es la hora del evento. Recopilar Identifique los documentos cuyo campo BKPF-STBLG esté cumplimentado. La marca de tiempo del evento es la fecha de contabilización del documento de anulación. Tipo de evento explicit | |||
| Asiento contable aparcado | Un usuario guarda un asiento contable incompleto sin contabilizarlo, lo que permite completarlo o revisarlo más adelante. Se trata de una acción explícita que crea un registro de cabecera del documento con estado «aparcado» y lo mantiene sin contabilizar. | ||
| Por qué es importante Aparcar el documento es un paso habitual antes del envío. Hacer un seguimiento de la duración del estado aparcado ayuda a identificar retrasos en la finalización y preparación de los datos antes de que comience el proceso formal de revisión y aprobación. Dónde obtenerlo En la tabla BKPF, un documento aparcado se identifica porque el campo de estado del documento (BSTAT) tiene el valor «V». La marca de tiempo del evento es la fecha de creación (CPUDT). Recopilar Filtre los documentos cuyo valor BKPF-BSTAT sea «V» en el momento de la creación. Tipo de evento explicit | |||
| Asiento contable corregido | El usuario modifica un asiento contable después de que haya sido rechazado o devuelto para realizar cambios. Esto representa el esfuerzo de retrabajo necesario para resolver los problemas identificados durante la revisión antes de volver a enviarlo. | ||
| Por qué es importante Esta actividad cuantifica los ciclos de retrabajo. Analizar la frecuencia y la duración de las correcciones ayuda a localizar las fuentes de ineficiencia y destaca oportunidades de formación y aclaración del proceso. Dónde obtenerlo Esto puede inferirse mediante el seguimiento de la fecha «Last Changed On» (AEDAT) en la tabla BKPF para un documento que anteriormente se encontrara en estado «Rejected». Los documentos de cambios proporcionan información más específica sobre lo que se modificó. Recopilar Utilice la marca de tiempo de las cabeceras de los documentos de cambios (CDHDR-UDATE) para las modificaciones realizadas después de un evento de rechazo. Tipo de evento inferred | |||
| Asiento contable modificado después de la contabilización | Un usuario modifica un conjunto limitado de campos de un asiento contable después de que este se haya contabilizado en el libro mayor. Aunque la mayoría de los datos financieros son inmutables después de la contabilización, algunos campos, como el texto o las asignaciones, pueden modificarse. | ||
| Por qué es importante Esta actividad es una señal crítica de cumplimiento. Los cambios posteriores a la contabilización pueden indicar intentos de alterar los registros y deben supervisarse atentamente para prevenir el fraude y garantizar la integridad de los datos. Dónde obtenerlo Esto puede inferirse de forma fiable a partir de las tablas de documentos de cambios (CDHDR y CDPOS). Una entrada en CDHDR para el número de documento con una fecha de cambio posterior a la fecha de contabilización indica una modificación posterior a la contabilización. Recopilar Busque registros en CDHDR cuya marca de tiempo de cambio (UDATE/UTIME) sea posterior a la fecha de contabilización del documento (BKPF-BUDAT). Tipo de evento inferred | |||
| Asiento contable rechazado | Una persona revisora o aprobadora rechaza el asiento contable e impide su contabilización. Normalmente, el documento se devuelve a la persona creadora para que lo corrija, lo que inicia un ciclo de retrabajo. | ||
| Por qué es importante Hacer un seguimiento de los rechazos es fundamental para comprender la calidad del proceso e identificar errores habituales. Una tasa de rechazo elevada indica problemas de precisión de los datos, comprensión de las políticas o documentación justificativa insuficiente. Dónde obtenerlo Este evento se infiere de un cambio de estado en un registro del Workflow o en un campo de estado personalizado del documento del asiento contable. Los registros de cambios de documentos (CDHDR/CDPOS) del campo de estado correspondiente pueden proporcionar la marca de tiempo. Recopilar Identifique el cambio del campo de estado a «Rejected» mediante los documentos de cambios (CDHDR/CDPOS) o los registros del Workflow. Tipo de evento inferred | |||
| Contabilización manual identificada | El asiento contable se contabilizó mediante un código de transacción manual, en lugar de utilizar una interfaz automatizada o un proceso por lotes. No se trata de un evento temporal, sino de una clasificación de la actividad de contabilización. | ||
| Por qué es importante Identificar las contabilizaciones manuales es fundamental para las iniciativas de automatización. Una proporción elevada de contabilizaciones manuales sugiere oportunidades para agilizar los procesos mediante la integración de subsistemas o el uso de programas de contabilización automatizados. Dónde obtenerlo Esto se calcula analizando el campo del código de transacción (TCODE) en la tabla de cabecera del documento (BKPF). Se utiliza una lista de T-Codes manuales conocidos, como FB01, F-02 y FB50, para clasificar el asiento. Recopilar Clasifique el evento según BKPF-TCODE y una lista predefinida de códigos de transacción manuales en el momento de la contabilización. Tipo de evento calculated | |||
| Documentación justificativa adjunta | Un usuario adjunta uno o varios documentos justificativos, como facturas u hojas de cálculo, al asiento contable. Normalmente se hace para aportar pruebas y contexto sobre la transacción financiera durante el proceso de revisión y auditoría. | ||
| Por qué es importante Garantizar que la documentación se adjunte antes de la revisión es fundamental para el cumplimiento y la eficiencia de las aprobaciones. Esta actividad ayuda a medir el cumplimiento de las políticas de documentación y su impacto en los tiempos del ciclo de aprobación. Dónde obtenerlo Normalmente, esto se infiere comprobando la marca de tiempo de creación de los adjuntos vinculados mediante Generic Object Services (GOS). La tabla SRGBTBREL vincula el objeto empresarial, por ejemplo, el documento BKPF, con el adjunto. Recopilar Consulte las tablas de adjuntos de GOS, como SRGBTBREL, para buscar vínculos con el objeto BKPF y utilice la marca de tiempo de creación del adjunto. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Requisitos previos y acceso: Asegúrese de contar con un usuario que tenga las autorizaciones necesarias para consultar la base de datos subyacente de SAP S/4HANA o ejecutar informes ABAP. Necesitará acceso de lectura a las vistas CDS I_JournalEntry, I_JournalEntryItem y a las tablas CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ y SWWLOGHIST. Normalmente, el acceso se concede mediante un cliente de base de datos como SAP HANA Studio o DBeaver, o mediante SAP ABAP Development Tools (ADT) para Eclipse.
- Identifique las configuraciones específicas del sistema: Antes de ejecutar la consulta, debe identificar los códigos de tarea específicos utilizados en su Workflow de aprobación de entradas de diario. Consulte al administrador de SAP Workflow para encontrar los ID de tarea, por ejemplo, TS12345678, correspondientes a los eventos de envío, rechazo y aprobación. Estos ID son necesarios para completar los marcadores de posición de la consulta final.
- Prepare la consulta SQL: Copie la consulta SQL completa proporcionada en la sección
queryen el cliente SQL o la herramienta de desarrollo que haya elegido. - Configure los parámetros de la consulta: Localice los marcadores de posición dentro de la consulta y sustitúyalos por sus valores específicos. Esto incluye configurar los parámetros
[YourCompanyCode],[StartDate]y[EndDate]. También debe sustituir los marcadores de posición de los ID de tarea del Workflow ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) por los valores identificados en el paso anterior. - Ejecute la consulta de extracción: Ejecute la consulta SQL modificada en la base de datos de SAP S/4HANA. Según el intervalo de fechas y el volumen de datos, la consulta puede tardar bastante en completarse. Se recomienda ejecutarla fuera de las horas de mayor actividad.
- Revise los resultados iniciales: Cuando finalice la consulta, examine las primeras filas de la salida para comprobar que todas las columnas, como JournalEntryId, ActivityName y EventTime, se hayan completado correctamente. El conjunto de resultados debe contener una fila por cada evento empresarial distinto del ciclo de vida de la entrada de diario.
- Exporte los datos a CSV: Exporte todo el conjunto de resultados desde su herramienta SQL a un único archivo CSV. Asegúrese de que el archivo utilice la codificación UTF-8 para evitar problemas con caracteres especiales.
- Prepárese para la carga: Antes de cargar el archivo en una herramienta de Process Mining, confirme que el archivo CSV contiene los encabezados necesarios. Los datos ya están estructurados como un Registro de eventos, por lo que no debería ser necesario realizar más transformaciones ni operaciones de transposición.
Configuración
- Vistas Core Data Services (CDS): La extracción utiliza principalmente
I_JournalEntrypara los datos de cabecera eI_JournalEntryItempara los detalles de las posiciones y los importes. Estas vistas ofrecen una interfaz simplificada y enriquecida semánticamente para el diario universal (ACDOCA). - Tablas de apoyo: Para obtener una visión completa del proceso, la consulta también combina varias tablas estándar de SAP:
CDHDRyCDPOSpara realizar el seguimiento de los cambios en los documentos.SRGBRELySOODpara identificar cuándo se vinculan archivos adjuntos mediante Generic Object Services (GOS).SWW_WI2OBJySWWLOGHISTpara extraer eventos clave del Workflow de aprobación.
- Filtrado por intervalo de fechas: Es fundamental filtrar los datos por un intervalo de fechas específico para controlar el rendimiento. Utilice el campo
I_JournalEntry.CreationDateTimeen la cláusulaWHERE. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses. - Filtrado organizativo: Filtre siempre por
CompanyCodepara limitar la extracción a las entidades legales relevantes. Consultar todos los códigos de sociedad a la vez en un sistema grande puede generar tiempos de ejecución extremadamente prolongados. - ID de tareas del Workflow: La consulta contiene marcadores de posición para los ID de tareas del Workflow, por ejemplo,
[Workflow Approved Task ID]. Estos ID son únicos para cada instalación de SAP y deben configurarse correctamente para extraer las actividades del Workflow. Sin ellos, no se capturarán los eventos de envío, aprobación ni rechazo. - Requisitos previos: El usuario que ejecute la consulta necesita amplias autorizaciones de lectura para las tablas financieras, del sistema y del Workflow. Estos permisos no son estándar y deben asignarse específicamente.
a Consulta de ejemplo sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Pasos
- Confirme que se ha aprobado el acceso SQL directo a la base de datos SAP HANA y que el usuario de extracción tiene autorización de lectura para BKPF y ACDOCA, además de cualquier fuente configurada de Workflow, archivos adjuntos, historial de cambios, compensación o reversión que requiera su sistema. El acceso directo a la base de datos normalmente se realiza con SAP HANA Database Explorer, SAP HANA Studio o un cliente SQL aprobado. No ejecute consultas de extracción en una transacción de una aplicación SAP, salvo que su sistema admita explícitamente ese acceso.
- Confirme el esquema físico de BKPF y ACDOCA, incluidos los campos de mandante, código de sociedad, ejercicio fiscal, número de documento, tipo de documento, fecha de contabilización, fecha de creación, hora de creación, usuario, importe en moneda local y cualquier campo de reversión o compensación. Las implementaciones de SAP S/4HANA pueden diferir en el esquema y en la disponibilidad de los campos, por lo que debe sustituir los marcadores de posición entre corchetes de la consulta por campos verificados en su sistema.
- Identifique las fuentes autorizadas para los eventos de Workflow y archivos adjuntos. BKPF y ACDOCA proporcionan datos de documentos contables y posiciones, pero por sí solas no exponen de forma fiable todos los eventos de aparcado, envío, rechazo, corrección, aprobación o adjuntos. Sustituya los marcadores de posición de las fuentes de Workflow y archivos adjuntos por vistas o tablas aprobadas de su implementación. Si una fuente no está disponible, no invente eventos. Configure la fuente correspondiente o excluya la actividad con la aprobación documentada.
- Configure los parámetros de extracción para el intervalo de fechas, los códigos de sociedad, los tipos de documento y el mandante requeridos. Para la validación inicial, se recomienda un intervalo de tres a seis meses. Utilice el intervalo de marcas de tiempo de los eventos operativos y el intervalo de fechas de contabilización de los eventos contables, según el alcance acordado del proceso.
- Ejecute la consulta SQL completa en el cliente SQL de HANA aprobado. La consulta crea una fila de evento por cada actividad extraída explícitamente. Utiliza BKPF y ACDOCA para los eventos contables y las vistas de origen configuradas para los eventos de Workflow, archivos adjuntos, cambios, compensaciones y reversiones. No infiere actividades a partir de la existencia de un documento.
- Revise el esquema de salida. JournalEntryId es el identificador del caso, ActivityName es la etiqueta de la actividad y EventTime es la marca de tiempo del evento. Los atributos empresariales recomendados se devuelven cuando están disponibles. Confirme que EventTime sea una marca de tiempo y que todas las filas tengan un JournalEntryId y un ActivityName no vacíos.
- Concilie la población contable comparando los valores distintos de JournalEntryId con la población esperada de BKPF para el mandante, los códigos de sociedad, los ejercicios fiscales y el intervalo de fechas seleccionados. Concilie por separado las poblaciones de Workflow y archivos adjuntos, ya que sus reglas de retención y marcas de tiempo pueden diferir de las de los datos contables.
- Valide el orden de los eventos y el comportamiento de los duplicados. Varias posiciones en ACDOCA no deben crear eventos contables duplicados, salvo que el diseño del proceso requiera deliberadamente eventos a nivel de posición. Utilice la lógica de agregación de la consulta para generar un evento contable por entrada de diario y tipo de evento, conservando los identificadores de eventos de origen configurados cuando estén disponibles.
- Exporte el resultado como CSV UTF-8 u otro formato tabular compatible con ProcessMind. Conserve exactamente los nombres de columna JournalEntryId, ActivityName y EventTime. Ordene el archivo por JournalEntryId y EventTime, y mantenga los atributos adicionales como columnas. Cargue el archivo en ProcessMind y configure JournalEntryId como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento.
Configuración
- Intervalo de fechas: Comience con tres a seis meses. Utilice un intervalo más corto para las pruebas de rendimiento y amplíelo solo después de validar el número de filas y la cobertura de eventos.
- Alcance de mandantes y sociedades: Configure [Client parameter] y limite CompanyCode a las entidades legales necesarias. No omita el predicado del mandante en un sistema con varios mandantes.
- Alcance contable: Configure [Document type filter] y, cuando corresponda, los filtros de ejercicio fiscal y fecha de contabilización. Incluya documentos contabilizados y no contabilizados solo si la fuente seleccionada los representa de forma fiable.
- Alcance del Workflow: Configure [Workflow event source] y sus correspondencias de tipos de evento para las actividades de envío, rechazo, corrección y aprobación. Confirme si las marcas de tiempo representan la creación, ejecución o finalización de la acción del Workflow.
- Alcance de archivos adjuntos: Configure [Attachment event source] y el campo de relación que vincula un archivo adjunto con la entrada de diario. Confirme si la fuente registra la creación, sustitución o eliminación del archivo adjunto.
- Alcance de cambios: Configure [Change history source] para los cambios posteriores a la contabilización. Confirme que la fuente identifique la entrada de diario y proporcione una marca de tiempo de cambio fiable.
- Alcance de compensaciones: Configure [Clearing source] y la relación entre el documento contable compensado y el documento de compensación. Decida si el evento debe asignarse a la entrada de diario original, al documento de compensación o a ambos.
- Alcance de reversiones: Configure [Reversal source] y la relación entre los documentos original y de reversión. La consulta asigna la actividad de reversión al JournalEntryId original cuando dicha relación está disponible.
- Clasificación de contabilización manual: Configure [Manual posting source] o un campo de origen de contabilización verificado. Manual Posting Identified es un evento de clasificación y debe utilizar de forma coherente la marca de tiempo de contabilización u otra marca de tiempo aprobada.
- Importe en moneda: ACDOCA se basa en posiciones. La consulta agrega los importes en moneda local por entrada de diario. Confirme la convención de signos y si deben incluirse las filas estadísticas, específicas del libro mayor o del libro mayor de extensión.
- Rendimiento: Seleccione solo las columnas necesarias, filtre al principio, evite los escaneos sin restricciones de ACDOCA y ejecute la consulta durante una ventana de generación de informes aprobada. Utilice la eliminación de particiones mediante predicados de mandante, ejercicio fiscal, código de sociedad y fecha de contabilización cuando sea compatible.
- Gestión de duplicados: Utilice los identificadores de eventos de origen cuando estén disponibles. Si una fuente puede contener registros técnicos repetidos, aplique la regla de deduplicación documentada sin combinar acciones de Workflow genuinamente independientes.
- Requisitos previos: Autorizaciones de base de datos necesarias, conectividad SAP HANA aprobada, acceso a las fuentes configuradas de Workflow y archivos adjuntos, configuración adecuada de SAP Financial Accounting y Workflow, y un formato de exportación compatible con ProcessMind.
a Consulta de ejemplo sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Pasos
- Cree el programa ABAP: Acceda al editor ABAP mediante el código de transacción
SE38. Introduzca un nombre para el nuevo programa, por ejemplo,Z_PM_JE_EXTRACT, y haga clic en «Crear». Proporcione un título adecuado, establezca el «Tipo» como «Programa ejecutable» y guárdelo como objeto local o dentro de un paquete. - Defina la pantalla de selección: En el programa, defina parámetros y select-options que permitan a los usuarios filtrar los datos. Debe incluir un intervalo de fechas para la fecha de creación de la entrada de diario (
P_CPUDT_FR,P_CPUDT_TO), un select-option para el código de sociedad (SO_BUKRS) y una ruta de archivo para la salida en el servidor de aplicaciones (P_FPATH). - Declare las estructuras de datos: Defina una estructura de tabla interna que coincida con el formato requerido del Registro de eventos. Esta estructura contendrá la salida final. Declare también tablas internas y áreas de trabajo para las tablas de SAP de las que seleccionará datos, como BKPF, ACDOCA, CDHDR, CDPOS y varias tablas de Workflow.
- Implemente la lógica de selección de datos: Escriba la lógica ABAP principal para recuperar los datos de cada una de las 12 actividades requeridas. Cree subrutinas independientes (FORMs) para cada actividad a fin de mantener el código organizado. Por ejemplo, cree un FORM para
get_created_events,get_parked_events,get_workflow_events, etc. - Seleccione los eventos «Created» y «Posted»: Lea la tabla BKPF según los criterios de la pantalla de selección del usuario. Una entrada en BKPF indica una creación. Un documento con el estado
BSTAT = ' 'se considera contabilizado. Utilice la marca de tiempo de creación (CPUDT,CPUTM) como hora del evento. - Seleccione los eventos «Parked»: Lea la tabla VBKPF, que almacena las cabeceras de los documentos aparcados. La marca de tiempo de creación de esta tabla representa el evento de aparcado.
- Seleccione los eventos de Workflow (Submitted, Approved, Rejected): Consulte tablas de Workflow como SWW_WI2OBJ, para vincular un objeto de entrada de diario con una instancia de Workflow, y SWWLOGHIST o SWWIHEAD, para obtener los detalles y la hora de pasos específicos. Deberá identificar los ID de tarea específicos de envío, aprobación y rechazo de su sistema.
- Seleccione los eventos «Change» y «Correction»: Consulte las tablas de documentos de modificación CDHDR (cabecera) y CDPOS (posición) para
OBJECTCLAS = 'BELEG'. Para «Changed After Posting», filtre los cambios cuya marca de tiempo sea posterior a la fecha de contabilización del documento. Para «Corrected», filtre los cambios realizados en documentos aparcados o rechazados. - Seleccione los eventos «Reversal» y «Cleared»: Identifique las reversiones buscando documentos cuyo campo
STBLG(n.º de documento revertido) de BKPF esté informado. La hora del evento de reversión es la hora de creación del documento de reversión. Identifique los eventos de compensación seleccionando la fecha de compensación más reciente (AUGDT) de la tabla ACDOCA para las posiciones de una entrada de diario determinada. - Combine y ordene los datos: A medida que seleccione los datos de cada actividad, añada los resultados a la tabla interna maestra final. Cuando haya completado todas las selecciones, ordene la tabla maestra por
JournalEntryIdyEventTimepara garantizar el orden cronológico de cada caso. - Genere el archivo de salida: Utilice las instrucciones
OPEN DATASET,LOOP AT... TRANSFERyCLOSE DATASETpara escribir el contenido de la tabla interna final ordenada en la ruta de archivo especificada del servidor de aplicaciones SAP. El archivo debe estar en formato CSV e incluir una fila de encabezados. - Programe la ejecución: Para realizar extracciones periódicas, utilice el código de transacción
SM36para crear un job en segundo plano que ejecute el programaZ_PM_JE_EXTRACTsegún un calendario definido, por ejemplo, semanal o mensual. Así automatizará el proceso de exportación de datos.
Configuración
- Intervalo de fechas: La pantalla de selección debe incluir un intervalo de fechas obligatorio para la fecha de creación de la entrada de diario (
CPUDT). Se recomienda extraer los datos en bloques manejables, como periodos de 3 a 6 meses, para garantizar un buen rendimiento. - Código de sociedad (
BUKRS): Este es un filtro fundamental para limitar la extracción a las entidades legales específicas relevantes para el análisis de Process Mining. No se recomienda extraer todos los códigos de sociedad a la vez. - Tipo de documento (
BLART): Puede añadir este filtro opcional para centrarse en tipos específicos de entradas de diario, como «SA» para contabilizaciones de cuentas de mayor o «KR» para facturas de proveedores. Esto puede reducir el volumen de datos y aumentar la relevancia del conjunto de datos. - Ruta de archivo: El programa requiere una ruta de archivo lógica en el servidor de aplicaciones SAP donde se escribirá el archivo de salida. Asegúrese de que la ruta sea válida y de que el usuario del sistema SAP tenga las autorizaciones de escritura necesarias para ese directorio. Utilice la transacción
AL11para gestionar y consultar los directorios del servidor. - ID de tareas del Workflow: La lógica para extraer los eventos de Workflow (Submitted, Approved, Rejected) debe configurarse con los ID de tarea específicos utilizados en el Workflow de aprobación de entradas de diario de su organización. A menudo son personalizados y deben identificarlos un consultor o desarrollador de Workflow.
- Requisitos previos: El usuario o la cuenta del sistema que ejecute el programa necesita autorizaciones de desarrollador para crear y ejecutar programas ABAP (
S_DEVELOP), así como amplio acceso de lectura a las tablas financieras (BKPF, ACDOCA), las tablas de registros de cambios (CDHDR, CDPOS) y las tablas de Workflow (SWW*).
a Consulta de ejemplo abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. ¿Listo para comenzar?
Utilice esta plantilla para preparar sus datos con confianza y obtener información clave sobre su proceso Record to Report - Journal Entry. Comience hoy su camino hacia la excelencia operativa.
Agilice Record to Report Journal Entry para alcanzar la máxima eficiencia
Transforme su proceso y reduzca un 30 % el tiempo de ciclo de las entradas de diario de Record to Report.
No necesita tarjeta de crédito. Configuración en minutos.