Su Template de datos para el proceso de registro a informe: asientos contables
Su Template de datos para el proceso de registro a informe: asientos contables
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Recomendaciones prácticas para la extracción
Atributos del proceso de registro a informe: 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 «Asiento contable creado», «Asiento enviado para revisión» o «Asiento contable contabilizado». Estas actividades suelen obtenerse 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 del procedimiento estándar. También es fundamental para calcular métricas como la frecuencia de las actividades, los tiempos de espera entre pasos y las tasas de cumplimiento. Por qué es importante Define los pasos del proceso y permite visualizar los mapas de procesos y analizar los patrones de los flujos de trabajo. Dónde obtenerlo Se obtiene de diversas fuentes, como los campos de estado de las tablas de cabecera y partidas (por ejemplo, BKPF-BSTAT), los registros de documentos de cambio (CDHDR/CDPOS) y los registros del flujo de trabajo. Ejemplos Asiento contable creadoAsiento contable aparcadoAsiento enviado para revisiónAsiento contable aprobadoAsiento contable contabilizado | |||
| Hora del evento EventTime | Marca de tiempo que indica cuándo tuvo lugar una actividad específica 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, que permite ordenar cronológicamente los eventos. Este atributo es fundamental para todos los análisis de procesos basados 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 crear un modelo de proceso fiable y calcular indicadores clave de rendimiento, como el tiempo de 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 cronología del proceso. Dónde obtenerlo Se obtiene de los registros de documentos de cambio (CDHDR-UDATE, CDHDR-UTIME), los registros del flujo de trabajo 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 que sirve como identificador principal del caso en el proceso. | ||
| Descripción El ID del asiento contable es un número único que se asigna a cada documento contable cuando se crea en SAP S/4HANA. Este identificador es esencial para seguir todo el ciclo de vida del asiento, desde su creación o aparcamiento inicial, pasando por los flujos de trabajo 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 mismo 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 en cada transacción financiera. Es el atributo fundamental para crear la vista completa del proceso. Por qué es importante Este identificador conecta todos los pasos relacionados del proceso y permite analizar el recorrido completo de cada asiento contable. Dónde obtenerlo Se trata de una clave compuesta que normalmente se forma concatenando el código de empresa (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 | Fecha en que se registra el asiento contable en el libro mayor y que determina el periodo financiero al que afecta. | ||
| 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 clave para la contabilidad y puede diferir de la fecha en que se creó el documento o se introdujo en el sistema. En Process Mining, la fecha de contabilización se utiliza para analizar cohortes por periodo, por ejemplo, para comparar los procesos de cierre mensual o analizar las tendencias de rendimiento en distintos periodos fiscales. También permite medir el tiempo transcurrido entre la creación del asiento y su contabilización efectiva. Por qué es importante Es fundamental para entender el contexto financiero y 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 | Valor total del asiento contable expresado en la moneda local de la sociedad. | ||
| Descripción Este atributo representa el importe del asiento contable. Suele calcularse sumando los valores absolutos de todas las partidas del debe o del haber del documento y convirtiendo el resultado a la moneda local de la sociedad. Analizar los datos por importe permite segmentar el proceso según el impacto financiero. Por ejemplo, los asientos de importes elevados pueden seguir un proceso de aprobación más riguroso que los de importes bajos. Esto ayuda a priorizar las mejoras en las transacciones que implican mayor riesgo financiero. Por qué es importante Indica el valor financiero del asiento y permite analizar cómo cambia el comportamiento del proceso según el importe en juego. Dónde obtenerlo Se calcula sumando los importes de las partidas de la tabla BSEG (campo DMBTR) correspondientes a un asiento contable (BELNR) y convirtiendo el resultado en un valor positivo. Ejemplos 1500.75125000.0050.20 | |||
| Sociedad CompanyCode | Identificador único de la empresa o entidad jurídica a la que se imputa el asiento contable. | ||
| Descripción La sociedad es una unidad organizativa fundamental de SAP Financials y representa una entidad jurídica independiente para la que se generan estados financieros. Cada asiento contable se asigna a una sociedad concreta. Este atributo es clave para segmentar y comparar el rendimiento de los procesos en distintas partes de la organización. Los analistas pueden filtrar la vista del proceso por entidad jurídica, comparar las tasas de rechazo entre sociedades o identificar variaciones del proceso específicas de cada región. Por qué es importante Permite filtrar y comparar el proceso de registro de asientos 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 el registro de un 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 clasifica los documentos contables. Controla aspectos como el rango de números asignado al documento y los tipos de cuenta que se pueden utilizar en el registro. Analizar el proceso por tipo de asiento es fundamental para comprender los comportamientos propios de cada contexto. Por ejemplo, el proceso de aprobación de una periodificación sencilla (tipo SA) puede ser mucho más simple que el de una adquisición compleja de activos (tipo AA). Esta dimensión es clave para el Dashboard «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 en distintos tipos de transacciones financieras. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo BLART (tipo de documento). Ejemplos SAKRAA | |||
| Usuario que creó el asiento CreatedByUser | El ID de usuario de la persona que creó el asiento contable. | ||
| Descripción Este atributo almacena el identificador único de la persona que inició el proceso del asiento contable al crear el documento inicial. Puede tratarse de una persona del equipo de contabilidad, de otra área de la empresa o de un ID de sistema para los asientos automatizados. Analizar el proceso según quién lo creó ayuda a detectar patrones relacionados con personas o equipos concretos. Puede revelar necesidades de formación si algunas personas tienen más rechazos, o destacar a quienes obtienen mejores resultados. Es esencial para el Dashboard «Actividad y rendimiento de los usuarios». Por qué es importante Asigna las actividades del proceso a personas concretas para 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 | Código de transacción de SAP utilizado para crear o modificar el asiento contable. | ||
| Descripción El código de transacción (T-Code) es un acceso directo que identifica una función o un programa concretos de SAP. En los asientos contables, los distintos T-Code pueden indicar cómo se creó el asiento: por ejemplo, FB01 para contabilizaciones manuales en el libro mayor, FV50 para aparcar documentos o un código automatizado para los asientos generados por el sistema. Este atributo permite determinar si una actividad la realizó manualmente una persona o si la ejecutó el sistema de forma automática. 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. Es 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 | |||
| Contabilización manual IsManualPosting | Indicador booleano que señala si una persona contabilizó manualmente el asiento. | ||
| Descripción Este atributo identifica los asientos contables registrados mediante la intervención manual de una persona, en lugar de contabilizarse automáticamente mediante un proceso del sistema o una interfaz. Suele derivarse 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 de registro a informe. Al filtrar los asientos contabilizados manualmente, los analistas pueden identificar las situaciones que aún requieren intervención humana y evaluar su potencial de automatización. Por qué es importante Distingue las contabilizaciones realizadas por personas de las ejecutadas por el sistema. Es fundamental para medir el nivel de automatización e identificar oportunidades para aumentarlo. Dónde obtenerlo Es un atributo calculado a partir de TransactionCode. Se utiliza una lista predefinida de códigos de transacción manuales (por ejemplo, «FB01», «F-02») para establecer el indicador en «true». Ejemplos truefalse | |||
| Ejercicio fiscal FiscalYear | 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 tiene relevancia. En el análisis, se utiliza para estudiar tendencias a largo plazo y garantizar que el identificador del caso sea único. 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 Es un componente clave para identificar documentos de forma única y permite analizar el rendimiento del proceso de un año a otro. Dónde obtenerlo Tabla BKPF de SAP S/4HANA, campo GJAHR (ejercicio fiscal). Ejemplos 202320242022 | |||
| Estado del documento DocumentStatus | Estado actual de procesamiento del asiento contable, como aparcado, contabilizado o compensado. | ||
| Descripción El estado del documento indica en qué fase del ciclo de vida se encuentra el asiento contable. Por ejemplo, un documento «aparcado» está guardado, pero aún no se ha contabilizado en el libro mayor; un documento «contabilizado» ya está finalizado. Analizar el estado ayuda a comprender el flujo de trabajo e identificar cuellos de botella. Si muchos documentos permanecen durante mucho tiempo «aparcados» o «pendientes de aprobación», puede ser señal de ineficiencias en el proceso. El estado también es una fuente clave para derivar las actividades del proceso. Por qué es importante Muestra en qué fase del ciclo de vida se encuentra el 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 | Marca de tiempo que indica cuándo se completó la actividad. | ||
| Descripción La hora de finalización marca cuándo concluye una actividad. En muchos registros de eventos, la hora de inicio y la hora de finalización de una actividad coinciden, lo que representa un evento instantáneo. Sin embargo, en actividades con una duración medible, como la revisión activa de un documento por parte de una persona, este atributo permite registrar esa duración. Contar con una hora de finalización diferenciada permite calcular con mayor precisión el tiempo de procesamiento de las actividades y separarlo del tiempo de espera. Así se distingue el tiempo dedicado activamente a una tarea del tiempo que permanece inactiva en una cola. Por qué es importante Permite calcular con precisión el tiempo de procesamiento de las actividades y separar el tiempo de trabajo activo del tiempo de espera. Dónde obtenerlo Suele coincidir con StartTime en los eventos atómicos. En las actividades con duración, puede obtenerse de los registros del flujo de trabajo o calcularse a partir de eventos posteriores. Ejemplos 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Motivo de anulación ReversalReason | Código que indica por qué se anuló un asiento contable contabilizado. | ||
| Descripción Si un asiento contable contabilizado es incorrecto, no se puede eliminar: debe anularse mediante un documento nuevo. El código de motivo de anulación explica por qué se realizó esta acción, por ejemplo, por una fecha de contabilización o un importe incorrectos. Analizar los motivos de anulación ayuda a identificar las causas raíz de los errores en el proceso de registro a informe. La frecuencia elevada de un motivo concreto puede señalar problemas sistémicos, como una formación insuficiente o fallos en los controles, que conviene abordar para mejorar la calidad desde el primer intento. Por qué es importante Ayuda a diagnosticar las causas raíz de los errores que provocan anulaciones y aporta 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 anulación). Ejemplos 010205 | |||
| Requiere retrabajo IsRework | Indicador booleano que señala si el asiento contable requirió retrabajo, por ejemplo, si se corrigió después de un rechazo. | ||
| Descripción Este atributo calculado marca los asientos contables que se desviaron de la ruta ideal del proceso. Suele establecerse como verdadero si en el caso se produce una actividad como «Asiento contable rechazado» o «Asiento contable corregido». Este indicador facilita 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 de los casos con retrabajo y sin él. Identificar las causas del retrabajo es uno de los principales objetivos de muchas iniciativas de mejora de procesos. Por qué es importante Marca los casos que requirieron correcciones o pasos adicionales y facilita cuantificar 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 aparece una actividad como «Asiento contable rechazado». Ejemplos truefalse | |||
| Sistema de origen SourceSystem | Identifica el sistema de origen del que se extrajeron los datos del asiento contable. | ||
| 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 de los procesos entre distintos sistemas o filtrar los datos de una fuente concreta. Es importante para la gobernanza de datos y para comprender el contexto de los datos analizados. Por qué es importante Aporta contexto sobre el origen de los datos, algo fundamental para analizar y comparar procesos con precisión en entornos con varios sistemas. Dónde obtenerlo Suele ser un valor estático que se añade durante la extracción de datos e identifica la instancia concreta 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 | Tiempo transcurrido desde que se envía un asiento contable para su aprobación hasta que se aprueba o se rechaza. | ||
| Descripción Esta métrica calculada se centra 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 flujo de trabajo de aprobación. Un tiempo de ciclo de aprobación elevado puede retrasar considerablemente el proceso general. Analizar esta métrica por persona aprobadora, sociedad o tipo de asiento contable puede revelar áreas concretas que conviene mejorar. Por qué es importante Aísla la duración de la fase de aprobación para ayudar a localizar y resolver cuellos de botella en el flujo de trabajo de revisión y aprobación. Dónde obtenerlo Se calcula como 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 y 2 horas4 horas y 25 minutos5 días y 0 horas | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen. | ||
| Descripción Este atributo registra la fecha y la hora de la extracción o actualización más reciente de los datos desde el sistema de origen. Permite saber si los datos analizados están actualizados. Conocer la hora de la última actualización ayuda a determinar la vigencia del análisis del proceso. También permite interpretar correctamente los Dashboards y los KPI, ya que indica si se consultan datos casi en tiempo real o una instantánea de un periodo anterior. Por qué es importante Indica la vigencia de los datos para que se sepa cuán actual es el análisis del proceso. Dónde obtenerlo Es un atributo de metadatos que suele generarse y asignarse a 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 a la persona responsable de revisar y decidir sobre un asiento contable enviado. En un flujo de trabajo de aprobación con varios niveles, puede haber varias personas aprobadoras para un mismo asiento. Esta información es esencial para analizar en detalle el proceso de aprobación. Permite medir la carga de trabajo de cada persona aprobadora, calcular sus tiempos de aprobación e identificar cuellos de botella en la cadena de aprobación. También es fundamental para el Dashboard «Actividad y rendimiento de los usuarios». Por qué es importante Identifica a la persona responsable de aprobar y permite analizar la carga de trabajo, el rendimiento y los cuellos de botella en las aprobaciones. Dónde obtenerlo Se obtiene de los registros del flujo de trabajo (por ejemplo, SWW_WI2OBJ, SWWLOG) o de las tablas de documentos de modificación (CDHDR/CDPOS), identificando quién ejecutó el paso de aprobación. Ejemplos DMILLERFWHITEKCHEN | |||
Actividades del proceso de registro a informe: asientos contables
| Actividad | Descripción | ||
|---|---|---|---|
| Anulación de asiento contable procesada | 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 de 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 elevada de anulaciones puede señalar problemas subyacentes en el proceso de aprobación o en la calidad de la entrada de datos. Hacer un seguimiento de ellas 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 de número de documento anulado (STBLG). La fecha de contabilización del nuevo documento indica el momento del evento. Capturar Identifique los documentos en los que BKPF-STBLG tenga un valor. La marca de tiempo del evento corresponde a la fecha de contabilización del documento de anulación. Tipo de evento explicit | |||
| Asiento contable aprobado | Una persona gerente autorizada otorga la aprobación final del asiento contable y confirma su validez y precisión. Esta actividad es el último paso antes de que el documento pueda contabilizarse en el libro mayor. | ||
| Por qué es importante Este es un hito clave que pone fin al ciclo de aprobación. El tiempo necesario para llegar a este paso representa una parte importante de la duración total del proceso y es un indicador clave de la eficiencia de las personas aprobadoras. Dónde obtenerlo Este evento se infiere a partir de un registro del flujo de trabajo que muestra el paso de aprobación final o un cambio de estado del documento. El ID de usuario de quien aprueba y la marca de tiempo pueden obtenerse de los datos del flujo de trabajo o de los registros de cambios. Capturar Identifique la marca de tiempo del paso de aprobación final en los registros del flujo de trabajo o el cambio de estado a «Aprobado» en los documentos de cambio. Tipo de evento inferred | |||
| Asiento contable compensado | Una partida abierta de un asiento contable se compensa con otra contabilización, por ejemplo, cuando un pago compensa una factura. Esta actividad marca la conciliación de partidas específicas y las cierra. | ||
| Por qué es importante Para muchos asientos contables, en especial los relacionados con cuentas transitorias o gestionadas por partidas abiertas, esta actividad representa el paso final de conciliación. Analizar el tiempo transcurrido entre la contabilización y la compensación ayuda a medir la eficiencia de la conciliación. Dónde obtenerlo Este evento se infiere de la tabla de partidas (BSEG o la vista ACDOCA). Cuando se compensa una partida, se completan los campos de fecha de compensación (AUGDT) y documento de compensación (AUGBL) de esa partida. Capturar Use la fecha de compensación de la partida (BSEG-AUGDT) 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. En este momento, 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 de procesamiento principal. El rendimiento de los asientos contabilizados y el tiempo necesario para llegar a esta etapa son métricas fundamentales de Process Mining. Dónde obtenerlo Este evento explícito se identifica mediante la fecha de contabilización (BUDAT) de 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'). Capturar Use la fecha de contabilización (BKPF-BUDAT) y la fecha de entrada (BKPF-CPUDT) para asignar la marca de tiempo al evento. Si BKPF-BSTAT está en blanco, 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 aún no se ha contabilizado en el libro mayor. Este es el punto de partida del ciclo de vida del asiento. | ||
| 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 de ciclo total e identificar retrasos iniciales en la entrada de datos. Dónde obtenerlo Este evento puede capturarse directamente de la tabla BKPF de SAP mediante los campos de fecha de creación (CPUDT) y hora de creación (CPUTM) para un número de documento determinado (BELNR). Capturar Use BKPF-CPUDT y BKPF-CPUTM como marca de tiempo del evento. Tipo de evento explicit | |||
| Asiento enviado para revisión | La persona que creó el asiento contable envía formalmente el documento al flujo de trabajo de revisión y aprobación. Esta actividad marca el traspaso de la entrada de datos al proceso formal de control e inicia el ciclo de aprobación. | ||
| Por qué es importante Este evento marca el inicio del tiempo de ciclo de aprobación. Medir el tiempo desde este punto hasta la aprobación o el rechazo final ayuda a localizar los cuellos de botella en las etapas de revisión y aprobación. Dónde obtenerlo A menudo, este evento se obtiene de los registros del flujo de trabajo (tablas SWW_WIHEAD y SWWLOG) vinculados al objeto de negocio. También puede inferirse a partir de un cambio de estado en un campo personalizado de la cabecera del documento (BKPF). Capturar Marca de tiempo de creación del elemento del flujo de trabajo o de cambio de un campo de estado a «Enviado» o «En revisión». Tipo de evento inferred | |||
| Asiento contable aparcado | Un usuario guarda un asiento contable incompleto sin contabilizarlo, para completarlo o revisarlo más adelante. Esta acción explícita crea un registro de cabecera con el estado «aparcado» y mantiene el documento sin contabilizar. | ||
| Por qué es importante Aparcar el documento es un paso habitual antes de enviarlo. Medir cuánto tiempo permanece aparcado ayuda a detectar 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 corresponde a la fecha de creación (CPUDT). Capturar Filtre los documentos cuyo BKPF-BSTAT = 'V' en el momento de su creación. Tipo de evento explicit | |||
| Asiento contable corregido | El usuario modifica un asiento contable después de que se haya rechazado o devuelto para realizar cambios. Esta actividad representa el trabajo de retrabajo necesario para resolver los problemas detectados durante la revisión antes de volver a enviar el asiento. | ||
| Por qué es importante Esta actividad permite cuantificar los ciclos de retrabajo. Analizar la frecuencia y la duración de las correcciones ayuda a localizar las fuentes de ineficiencia y a detectar oportunidades de formación y de aclaración del proceso. Dónde obtenerlo Este evento puede inferirse mediante el seguimiento de la fecha de última modificación (AEDAT) en la tabla BKPF para un documento que antes estaba en estado «Rechazado». Los documentos de cambio ofrecen información más detallada sobre las modificaciones. Capturar Use la marca de tiempo de las cabeceras de los documentos de cambio (CDHDR-UDATE) para las modificaciones realizadas después del rechazo. Tipo de evento inferred | |||
| Asiento contable modificado después de contabilizarse | Un usuario modifica un conjunto limitado de campos de un asiento contable después de que ya se haya contabilizado en el libro mayor. Aunque la mayoría de los datos financieros no se pueden modificar después de la contabilización, sí es posible cambiar algunos campos, como el texto o las asignaciones. | ||
| Por qué es importante Esta actividad es una señal clave de cumplimiento. Los cambios posteriores a la contabilización pueden indicar intentos de alterar los registros, por lo que deben supervisarse de cerca para prevenir el fraude y garantizar la integridad de los datos. Dónde obtenerlo Este evento puede inferirse de forma fiable a partir de las tablas de documentos de cambio (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 que hubo una modificación posterior. Capturar Busque en CDHDR los registros 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 que se contabilice. Por lo general, el documento se devuelve a quien lo creó para que lo corrija, lo que inicia un ciclo de retrabajo. | ||
| Por qué es importante Registrar los rechazos es fundamental para comprender la calidad del proceso e identificar errores comunes. Una tasa de rechazo elevada indica problemas de precisión de los datos, comprensión de las políticas o documentación de respaldo insuficiente. Dónde obtenerlo Este evento se infiere a partir de un cambio de estado en un registro del flujo de trabajo o en un campo de estado personalizado del documento del asiento contable. Los registros de cambios del campo de estado correspondiente (CDHDR/CDPOS) pueden proporcionar la marca de tiempo. Capturar Identifique el cambio del campo de estado a «Rechazado» mediante los documentos de cambio (CDHDR/CDPOS) o los registros del flujo de trabajo. Tipo de evento inferred | |||
| Contabilización manual identificada | El asiento contable se contabilizó mediante un código de transacción manual, en lugar de 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 indica que hay oportunidades para agilizar los procesos mediante la integración de subsistemas o el uso de programas de contabilización automatizados. Dónde obtenerlo Este dato se calcula analizando el campo de código de transacción (TCODE) de la tabla de cabecera del documento (BKPF). Para clasificar el asiento, se utiliza una lista de códigos de transacción manuales conocidos, como FB01, F-02 y FB50. Capturar 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 de respaldo adjunta | Un usuario adjunta uno o varios documentos de respaldo, como facturas u hojas de cálculo, al asiento contable. Normalmente, se hace para aportar pruebas y contexto sobre la transacción financiera durante la revisión y la auditoría. | ||
| Por qué es importante Adjuntar la documentación antes de la revisión es fundamental para el cumplimiento y la eficiencia de las aprobaciones. Esta actividad permite medir el cumplimiento de las políticas de documentación y su impacto en los tiempos del ciclo de aprobación. Dónde obtenerlo Por lo general, este evento se infiere comprobando la marca de tiempo de creación de los archivos adjuntos vinculados mediante Generic Object Services (GOS). La tabla SRGBTBREL vincula el objeto de negocio, por ejemplo, un documento BKPF, con el archivo adjunto. Capturar Consulte las tablas de archivos adjuntos de GOS, como SRGBTBREL, para encontrar vínculos con el objeto BKPF y use la marca de tiempo de creación del archivo 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 e I_JournalEntryItem, y a las tablas CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ y SWWLOGHIST. Por lo general, el acceso se concede mediante un cliente de base de datos como SAP HANA Studio o DBeaver, o con SAP ABAP Development Tools (ADT) para Eclipse.
- Identifique las configuraciones específicas del sistema: Antes de ejecutar la consulta, identifique los códigos de tarea específicos que se utilizan en el flujo de aprobación de asientos contables. Consulte con el administrador de Workflow de SAP para encontrar los ID de tarea (por ejemplo, TS12345678) correspondientes a los eventos de envío, rechazo y aprobación. Los necesitará para completar los marcadores de posición de la consulta final.
- Prepare la consulta SQL: Copie la consulta SQL completa de 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 en la consulta y sustitúyalos por los valores correspondientes. Esto incluye configurar los parámetros
[YourCompanyCode],[StartDate]y[EndDate]. También debe sustituir los marcadores de posición de los ID de tarea de Workflow ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) por los valores que identificó 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 termine la consulta, examine las primeras filas del resultado para comprobar que todas las columnas, como JournalEntryId, ActivityName y EventTime, tengan los valores esperados. El conjunto de resultados debe contener una fila por cada evento empresarial distinto del ciclo de vida del asiento contable.
- Exporte los datos a CSV: Exporte todo el conjunto de resultados desde la herramienta SQL a un único archivo CSV. Asegúrese de que el archivo utilice codificación UTF-8 para evitar problemas con caracteres especiales.
- Prepare los datos para cargarlos: Antes de cargarlos en una herramienta de Process Mining, compruebe que el archivo CSV tenga los encabezados necesarios. Los datos ya están estructurados como un Registro de eventos, por lo que no debería ser necesario transformarlos ni reorganizarlos.
Configuración
- Vistas de Core Data Services (CDS): La extracción utiliza principalmente
I_JournalEntrypara los datos de cabecera eI_JournalEntryItempara los detalles de las partidas y los importes. Estas vistas ofrecen una interfaz simplificada y con abundante información semántica para el libro mayor universal (ACDOCA). - Tablas complementarias: Para obtener una visión completa del proceso, la consulta también combina varias tablas estándar de SAP:
CDHDRyCDPOSpara hacer un 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 flujo 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 por organización: Filtre siempre por
CompanyCodepara limitar la extracción a las entidades jurídicas pertinentes. Consultar todos los códigos de sociedad a la vez en un sistema grande puede prolongar mucho la ejecución. - ID de tarea de Workflow: La consulta incluye marcadores de posición para los ID de tarea de Workflow (por ejemplo,
[Workflow Approved Task ID]). Estos ID son únicos en cada instalación de SAP y deben configurarse correctamente para extraer las actividades del flujo de trabajo. Sin ellos, no se capturarán 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 de Workflow. Estos permisos no suelen estar asignados de forma predeterminada y deben concederse específicamente.
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 haya aprobado el acceso SQL directo a la base de datos SAP HANA y que el usuario de extracción tenga autorización de lectura para BKPF y ACDOCA, además de las fuentes de Workflow, archivos adjuntos, historial de cambios, compensaciones o reversiones que requiera su sistema. El acceso directo a la base de datos suele realizarse 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 expresamente 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 los campos disponibles, por lo que debe sustituir los marcadores entre corchetes de la consulta por campos verificados en su sistema.
- Identifique las fuentes autorizadas de los eventos de Workflow y de archivos adjuntos. BKPF y ACDOCA proporcionan datos de documentos contables y partidas, pero por sí solas no muestran de forma fiable todos los eventos de aparcamiento, envío, rechazo, corrección, aprobación o adjunto. 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 necesarios. 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. También se devuelven los atributos empresariales recomendados cuando están disponibles. Confirme que EventTime sea una marca de tiempo y que todas las filas tengan valores no vacíos en JournalEntryId y ActivityName.
- Concilie la población contable comparando los valores distintos de JournalEntryId con la población de BKPF prevista 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 tratamiento de duplicados. Las partidas múltiples de ACDOCA no deben generar eventos contables duplicados, salvo que el diseño del proceso requiera intencionadamente eventos por partida. Utilice la lógica de agregación de la consulta para generar un evento contable por asiento y tipo de evento, conservando los identificadores de los eventos de origen configurados cuando estén disponibles.
- Exporte el resultado como archivo CSV con codificación UTF-8 o en 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 en 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 un período de tres a seis meses. Utilice un intervalo más corto para probar el 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 jurídicas necesarias. No omita el filtro de 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 de Workflow: Configure [Workflow event source] y las correspondencias de tipos de evento para las actividades de envío, rechazo, corrección y aprobación. Confirme si las marcas de tiempo corresponden a la creación, ejecución o finalización de la acción de Workflow.
- Alcance de archivos adjuntos: Configure [Attachment event source] y el campo de relación que vincula un archivo adjunto con el asiento contable. Confirme si la fuente registra la creación, sustitución o eliminación de archivos adjuntos.
- Alcance de cambios: Configure [Change history source] para los cambios posteriores a la contabilización. Confirme que la fuente identifique el asiento contable y proporcione una marca de tiempo fiable del cambio.
- 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 al asiento contable 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. Cuando esa relación esté disponible, la consulta asigna la actividad de reversión al JournalEntryId original.
- Clasificación de contabilizaciones manuales: 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 partidas. La consulta agrega los importes en moneda local por asiento contable. Confirme la convención de signos y si deben incluirse las filas estadísticas, específicas del libro mayor o de libros mayores de extensión.
- Rendimiento: Seleccione solo las columnas necesarias, aplique los filtros desde el inicio, evite los análisis sin restricciones de ACDOCA y ejecute la consulta durante una ventana de generación de informes aprobada. Cuando sea posible, utilice la eliminación de particiones mediante filtros de mandante, ejercicio fiscal, código de sociedad y fecha de contabilización.
- Tratamiento 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 que sean realmente distintas.
- Requisitos previos: Autorizaciones de base de datos necesarias, conectividad aprobada con SAP HANA, 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.
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. Asigne un nombre al programa nuevo, por ejemplo,Z_PM_JE_EXTRACT, y haga clic en «Crear». Indique un título adecuado, establezca «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 opciones de selección que permitan filtrar los datos. Debe incluir un intervalo de fechas para la fecha de creación del asiento contable (
P_CPUDT_FR,P_CPUDT_TO), una opción de selección 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 SAP de las que se extraerán 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 (FORM) para cada actividad y mantenga el código organizado. Por ejemplo, cree un FORM para
get_created_events,get_parked_events,get_workflow_events, etc. - Seleccione los eventos «Creado» y «Contabilizado»: Lea la tabla BKPF según los criterios de la pantalla de selección del usuario. Una entrada en BKPF indica que se creó un documento. Se considera contabilizado un documento cuyo estado sea
BSTAT = ' '. Utilice la marca de tiempo de creación (CPUDT,CPUTM) como hora del evento. - Seleccione los eventos «Aparcado»: 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 aparcamiento.
- Seleccione los eventos de Workflow (enviado, aprobado, rechazado): Consulte tablas de Workflow como SWW_WI2OBJ (para vincular un objeto de asiento contable 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 Workflow para el envío, la aprobación y el rechazo en su sistema.
- Seleccione los eventos de «Cambio» y «Corrección»: Consulte las tablas de documentos de cambio CDHDR (cabecera) y CDPOS (partida) para
OBJECTCLAS = 'BELEG'. Para «Modificado después de la contabilización», filtre los cambios cuya marca de tiempo sea posterior a la fecha de contabilización del documento. Para «Corregido», filtre los cambios en documentos aparcados o rechazados. - Seleccione los eventos de «Reversión» y «Compensado»: Identifique las reversiones buscando documentos con el campo
STBLG(n.º de documento revertido) rellenado en BKPF. 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 partidas de un asiento contable determinado. - 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 termine 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 maestra ordenada en la ruta de archivo especificada en el servidor de aplicaciones SAP. El archivo debe estar en formato CSV e incluir una fila de encabezado. - Programe la ejecución: Para realizar extracciones periódicas, utilice el código de transacción
SM36para crear un trabajo en segundo plano que ejecute el programaZ_PM_JE_EXTRACTsegún un calendario definido, por ejemplo, semanal o mensual. De este modo, se automatiza la 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 del asiento contable (
CPUDT). Se recomienda extraer los datos en períodos manejables, por ejemplo, de 3 a 6 meses cada vez, para garantizar un buen rendimiento. - Código de sociedad (
BUKRS): Este filtro es fundamental para limitar la extracción a las entidades jurídicas pertinentes para el análisis de Process Mining. No se recomienda extraer datos de 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 asientos contables, como «SA» para contabilizaciones en cuentas de mayor o «KR» para facturas de proveedores. Esto puede reducir el volumen de datos y aumentar la pertinencia del conjunto de datos. - Ruta del archivo: El programa requiere una ruta 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 administrar y consultar los directorios del servidor. - ID de tarea de Workflow: La lógica para extraer eventos de Workflow (enviado, aprobado, rechazado) debe configurarse con los ID de tarea específicos que se utilizan en el flujo de aprobación de asientos contables de su organización. A menudo son personalizados y debe identificarlos un consultor o desarrollador de Workflow.
- Requisitos previos: El usuario o la cuenta del sistema que ejecute el programa necesita autorizaciones de desarrollo para crear y ejecutar programas ABAP (
S_DEVELOP), así como amplio acceso de lectura a las tablas financieras (BKPF, ACDOCA), las tablas de registro de cambios (CDHDR, CDPOS) y las tablas de Workflow (SWW*).
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. ¿Todo listo para comenzar?
Utilice este Template para preparar sus datos con confianza y obtener información clave sobre el proceso de registro a informe: asientos contables. Comience hoy mismo a mejorar sus procesos.
Agilice los asientos contables de registro a informe para alcanzar la máxima eficiencia
Transforme su proceso y reduzca un 30 % el tiempo de ciclo de los asientos contables de registro a informe.
No se requiere tarjeta de crédito. Configuración en minutos.