Su plantilla de datos de Record to Report - Journal Entry
Su plantilla de datos de Record to Report - Journal Entry
- Atributos recomendados para un análisis completo
- Actividades clave de Journal Entry que debe supervisar
- Recomendaciones prácticas para extraer datos de SAP ECC
Record to Report - Atributos de los asientos contables
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | Marca de tiempo que indica cuándo tuvo lugar una actividad o evento específico del asiento contable. | ||
| Descripción La hora del evento proporciona la fecha y hora exactas de cada actividad del proceso de asiento contable. Estos datos son fundamentales para calcular todas las métricas basadas en el tiempo, como tiempos de ciclo, duraciones de procesamiento y retrasos entre pasos. La fuente de esta marca de tiempo varía según la actividad: puede ser la fecha y hora de creación del documento (CPUDT/CPUTM) o las marcas de tiempo de cambios de los registros (CDHDR-UDATE/UTIME). En el análisis, la hora del evento se utiliza para ordenar cronológicamente los eventos y constituye la base del mapa de procesos. Es esencial para calcular todos los KPI relacionados con el tiempo, como el tiempo medio de ciclo del asiento contable, el tiempo medio de aprobación y el tiempo entre la aprobación y el registro. Por qué es importante Esta marca de tiempo es la base de todos los análisis relacionados con el tiempo y permite calcular tiempos de ciclo, duraciones y cuellos de botella. Dónde obtenerlo Se obtiene de distintos campos según la actividad, principalmente de la marca de tiempo de creación (CPUDT, CPUTM) de BKPF o de las marcas de tiempo de cambios (UDATE, UTIME) de CDHDR. Ejemplos 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| ID del asiento contable JournalEntryId | Identificador único de un documento de contabilidad financiera, que combina la sociedad, el número de documento y el ejercicio fiscal. | ||
| Descripción El ID del asiento contable es el identificador principal del caso para realizar el seguimiento del ciclo de vida de un asiento contable. Es una clave compuesta, formada normalmente por la concatenación de la sociedad (BUKRS), el número de documento (BELNR) y el ejercicio fiscal (GJAHR), para garantizar su unicidad en todo el sistema SAP. En el análisis de procesos, este ID vincula todas las actividades relacionadas, como la creación, el aparcamiento, el envío, la aprobación, el rechazo y el registro. Al rastrear este identificador, podemos reconstruir el recorrido completo de cada asiento contable, medir los tiempos de ciclo e identificar desviaciones del proceso o cuellos de botella en asientos específicos. Por qué es importante Es la clave esencial para realizar el seguimiento de un asiento contable desde su creación hasta su registro final, lo que permite analizar el proceso de principio a fin y comparar variantes. Dónde obtenerlo Es un Atributo derivado, normalmente obtenido al concatenar campos de la tabla BKPF: sociedad (BUKRS), número de documento (BELNR) y ejercicio fiscal (GJAHR). Ejemplos 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nombre de la actividad ActivityName | Nombre de la actividad empresarial o del evento que tuvo lugar en un momento específico del proceso de asiento contable. | ||
| Descripción Activity Name describe un paso concreto del ciclo de vida del asiento contable, como «Asiento contable creado», «Asiento contable aprobado» o «Asiento contable contabilizado». Este atributo suele derivarse de varias fuentes de SAP, incluidos los códigos de transacción (TCODE), los registros de documentos de modificación (tablas CDHDR y CDPOS) y los campos de estado del documento. Analizar las actividades es el núcleo de Process Mining. Permite visualizar mapas de procesos, calcular los tiempos de transición entre pasos e identificar bucles de retrabajo, por ejemplo, «Asiento contable rechazado» seguido de «Asiento contable corregido». Estos datos son fundamentales para los Dashboards relacionados con los tiempos de ciclo, las tasas de retrabajo y las variantes del proceso. Por qué es importante Define los pasos del mapa de procesos, lo que permite visualizar, analizar y optimizar el Workflow de asientos contables. Dónde obtenerlo Se deriva de varias fuentes, incluidos los códigos de transacción de BKPF (TCODE), el estado del documento y los registros del Workflow en tablas como SWW_WI2OBJ, o los documentos de cambios en CDHDR y CDPOS. Ejemplos Asiento contable creadoAsiento contable aprobadoAsiento contable rechazadoAsiento contable registrado | |||
| Sistema de origen SourceSystem | Sistema del que se extrajeron los datos del proceso. | ||
| Descripción Este Atributo identifica el origen de los datos, que en este caso es una instancia específica de SAP ECC. Normalmente es un valor estático que se añade durante el proceso de extracción de datos. Aunque es sencillo, este Atributo es importante en entornos con varios ERP o fuentes de datos. Garantiza una trazabilidad clara de los datos y permite filtrar o segmentar el análisis por sistema de origen. Por qué es importante Proporciona una trazabilidad clara de los datos y es esencial para realizar un seguimiento de su calidad, especialmente en entornos con varios sistemas de origen. Dónde obtenerlo Normalmente es un valor estático añadido durante el proceso de transformación de datos que identifica la instancia específica de SAP ECC, por ejemplo, «ECC_PROD_100». Ejemplos SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se extrajeron o actualizaron por última vez los datos del sistema de origen. | ||
| Descripción Este Atributo registra la fecha y hora de la extracción más reciente de datos de SAP ECC. Es un campo de metadatos fundamental para comprender la actualidad y vigencia de los datos analizados. En cualquier panel o análisis de Process Mining, conocer la hora de la última actualización es crucial para que los usuarios confíen en los datos y tomen decisiones informadas. Ayuda a responder a la pregunta: «¿Hasta qué fecha está actualizada esta información?». Por qué es importante Informa a los usuarios sobre la actualidad de los datos, para que comprendan el periodo del análisis y puedan confiar en los resultados. Dónde obtenerlo Es un campo de metadatos generado y almacenado por la herramienta de extracción de datos o el proceso ETL en el momento de actualizar los datos. Ejemplos 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| ¿Está anulado? IsReversed | Indicador booleano que señala si el asiento contable ha sido anulado. | ||
| Descripción Este indicador identifica los asientos contables que posteriormente han sido anulados por otro documento contable. En SAP, el documento anulado se vincula al documento de anulación, lo que proporciona un registro de auditoría claro. Este Atributo es fundamental para el panel «Análisis de anulaciones de asientos contables» y el KPI «Tasa de anulaciones de asientos contables». Permite aislar los asientos anulados para investigar sus causas raíz, como errores de introducción de datos o tratamientos contables incorrectos, con el objetivo de reducir la frecuencia de las anulaciones. Por qué es importante Apoya directamente el análisis de anulaciones al señalar los asientos que se deshicieron posteriormente, lo que ayuda a identificar las causas raíz de los errores y mejorar la integridad de los datos. Dónde obtenerlo Se deriva del campo de número del documento de anulación (STBLG) de la tabla BKPF. Si STBLG no está vacío, el indicador es verdadero. Ejemplos truefalse | |||
| Código de transacción TransactionCode | Código de transacción de SAP utilizado para crear o procesar el asiento contable. | ||
| Descripción El código de transacción (T-Code) es un identificador único de una función o programa específico de SAP. En los asientos contables, indica cómo se creó el asiento: manualmente (FB01, F-02), mediante aparcamiento (FV50) o a través de una interfaz automatizada. Este Atributo es muy valioso para el panel «Optimización de actividades manuales». Al analizar el T-Code, podemos distinguir entre actividades manuales y automatizadas, identificar qué procesos manuales consumen más tiempo y detectar oportunidades de automatización para reducir el esfuerzo manual y mejorar la eficiencia. Por qué es importante Ayuda a diferenciar entre procesos manuales y automatizados, e identifica oportunidades de automatización y estandarización del proceso. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo TCODE. Ejemplos FB01F-02FV50FBD1 | |||
| Fecha de registro PostingDate | Fecha en la que la transacción se registra en el libro mayor y afecta al periodo financiero. | ||
| Descripción La fecha de registro determina el periodo fiscal en el que se contabiliza el asiento contable. Es un campo de fecha crítico desde la perspectiva financiera y de Cumplimiento, ya que debe ajustarse a los calendarios de cierre contable y a la normativa. En Process Mining, esta fecha se utiliza para supervisar el Cumplimiento. El panel «Supervisión del cumplimiento» y el KPI «Tasa de conformidad normativa» utilizan este Atributo para comprobar si los asientos se registran en el periodo correcto. También puede utilizarse para analizar las tendencias del volumen de asientos contables a lo largo del tiempo. Por qué es importante Esencial para los informes financieros y el análisis de Cumplimiento, ya que garantiza que los asientos se registren en el periodo contable correcto. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo BUDAT. Ejemplos 2023-10-312023-11-302024-01-15 | |||
| Sociedad CompanyCode | Unidad organizativa que representa una entidad jurídica independiente para la que se preparan estados financieros. | ||
| Descripción La sociedad es una unidad organizativa fundamental en SAP Financials. Representa una empresa jurídicamente independiente y es un campo clave de la cabecera del documento de asiento contable. Este Atributo es esencial para segmentar el análisis del proceso por entidad jurídica. Permite comparar el rendimiento del proceso, las tasas de Cumplimiento y los resultados de los KPI entre distintas partes de la empresa. Por ejemplo, ayuda a identificar si los retrasos de aprobación o las altas tasas de anulación se concentran en determinadas sociedades. Por qué es importante Permite filtrar y comparar el rendimiento del proceso entre distintas entidades jurídicas o unidades de negocio de la organización. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo BUKRS. Ejemplos 10002000US01DE01 | |||
| Tipo de documento DocumentType | Clasificación de los documentos contables que controla cómo se procesan y almacenan. | ||
| Descripción El tipo de documento distingue distintas clases de transacciones empresariales, como un registro en el libro mayor (SA), una factura de proveedor (KR) o un registro de activo (AA). Se define durante la configuración del sistema y se asigna a cada asiento contable. Este es un Atributo crítico para el análisis, ya que permite segmentar el proceso según la naturaleza de la transacción. El panel «Rendimiento de asientos contables por tipo» y el KPI «Tiempo medio de ciclo por tipo de asiento contable» dependen directamente de este campo. Ayuda a descubrir si determinados tipos de asientos son más propensos a sufrir retrasos, correcciones o anulaciones. Por qué es importante Permite segmentar el análisis por tipo de transacción y ayuda a identificar si los problemas del proceso se limitan a determinados tipos de asientos contables. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo BLART. Ejemplos SAKRREAA | |||
| Usuario User | ID de usuario de SAP de la persona que creó o modificó el asiento contable. | ||
| Descripción Este Atributo registra el nombre de usuario de SAP responsable de una actividad determinada, como crear, aparcar o registrar un documento. Se obtiene directamente de la cabecera del documento o de las tablas de registros de cambios. Analizar el Atributo Usuario es clave para comprender el rendimiento de los equipos y de cada persona. Permite alimentar el panel de productividad de usuarios mediante el seguimiento del volumen de actividades y los tiempos de procesamiento por usuario. También ayuda a identificar quién participa en ciclos de corrección, anulaciones o desviaciones de Cumplimiento, lo que facilita orientar la formación o las mejoras del proceso. Por qué es importante Identifica al usuario responsable de cada actividad y permite analizar el rendimiento de los usuarios, la distribución de la carga de trabajo y los patrones de corrección. Dónde obtenerlo Normalmente procede de la tabla BKPF (campo USNAM para el creador) o de la tabla CDHDR (campo USERNAME para quien realiza el cambio). Ejemplos ABROWNCJONESDSMITH | |||
| Centro de coste CostCenter | Unidad organizativa dentro de un área de controlling que representa una ubicación donde se generan costes. | ||
| Descripción El centro de coste es un elemento clave de los datos maestros del módulo Controlling (CO), que suele asignarse en el nivel de posición del asiento contable. Se utiliza para realizar un seguimiento de los costes de un departamento, función o ubicación específicos. Incluir el centro de coste permite analizar con mayor detalle el proceso de asientos contables. Puede ayudar a determinar si ciertos departamentos generan más retrabajo, tienen ciclos más largos o son responsables de un mayor volumen de asientos manuales. Esto permite analizar la eficiencia del proceso por departamento. Por qué es importante Permite analizar el rendimiento del proceso por departamento o área funcional y ayuda a localizar ineficiencias específicas. Dónde obtenerlo Se encuentra en la tabla de posiciones del documento BSEG, campo KOSTL. Ejemplos 4100CC_FINANCE_US10010101 | |||
| Clave de moneda CurrencyKey | Código de moneda de los importes registrados en el asiento contable. | ||
| Descripción Este Atributo especifica la moneda del asiento contable, como USD, EUR o JPY. Proporciona contexto para todos los importes financieros asociados al documento. Aunque no siempre es una dimensión principal del análisis, es crucial para interpretar correctamente los valores monetarios. También puede utilizarse para segmentar el análisis en organizaciones globales y comprobar si los procesos difieren entre asientos en moneda extranjera y en moneda local. Por qué es importante Proporciona el contexto necesario para todos los valores monetarios y garantiza un análisis e interpretación financieros precisos. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo WAERS. Ejemplos USDEURGBPJPY | |||
| Es retrabajo IsRework | Indicador booleano que señala si un asiento contable ha pasado por un ciclo de retrabajo, por ejemplo, si se ha rechazado y después corregido. | ||
| Descripción Este indicador identifica los casos que se han desviado de la «ruta ideal» y han requerido una acción correctiva. Normalmente se establece en true cuando se observa una secuencia de actividades como «Journal Entry Rejected» seguida de «Journal Entry Corrected» para un asiento contable determinado. Este atributo es esencial para calcular el KPI «Journal Entry Rework Rate» y para analizar el Dashboard «Rework and Rejection Rate». Ayuda a cuantificar el grado de ineficiencia del proceso y proporciona una base para investigar las causas raíz del retrabajo, como requisitos poco claros o documentación insuficiente. Por qué es importante Señala los asientos que requirieron corrección, lo que permite cuantificar el retrabajo y analizar sus causas raíz para mejorar la tasa de aciertos a la primera. Dónde obtenerlo Es un atributo calculado, derivado del análisis de la secuencia de actividades de un caso. Se identifica un ciclo de retrabajo cuando se produce una actividad de rechazo o corrección. Ejemplos truefalse | |||
| Está aparcado IsParked | Indicador booleano que señala si el asiento contable se guardó como documento aparcado antes de contabilizarse. | ||
| Descripción Aparcar un documento permite que un usuario guarde un asiento contable incompleto sin que afecte a los saldos financieros. Después, otro usuario puede completarlo o revisarlo antes de contabilizarlo. Este indicador identifica los asientos que han pasado por un paso de aparcamiento. Analizar este atributo ayuda a comprender el uso de la función de aparcamiento. Puede revelar si se utiliza como una etapa informal de revisión y si está provocando retrasos. También permite analizar el tiempo de ciclo de extremo a extremo y distinguir entre los asientos contabilizados directamente y los que se aparcan primero. Por qué es importante Identifica los asientos que utilizan la función de aparcamiento, que puede ser una fuente de retrasos o un indicador de un proceso informal de revisión. Dónde obtenerlo Se deriva del campo de estado del documento (BSTAT) de la tabla BKPF. Una «V» indica un documento aparcado. Ejemplos truefalse | |||
| Importe total del documento TotalDocumentAmount | Valor total del asiento contable en la moneda del documento. | ||
| Descripción Este Atributo representa el valor financiero total del asiento contable. Normalmente se calcula sumando los valores absolutos de todas las posiciones de débito o crédito asociadas al documento. Analizar el proceso según el valor financiero puede revelar patrones importantes. Por ejemplo, los asientos de importe elevado pueden seguir una ruta de aprobación distinta y más estricta. Este Atributo puede utilizarse para filtrar o segmentar el análisis y comprobar si los tiempos de ciclo, las tasas de rechazo o los retrasos de aprobación se correlacionan con el importe del asiento. Por qué es importante Permite analizar el impacto financiero, por ejemplo, relacionando los tiempos de procesamiento o las tasas de rechazo con el valor monetario de los asientos contables. Dónde obtenerlo Es un campo calculado que se obtiene agregando el campo de importe (WRBTR o DMBTR) de todas las posiciones de la tabla BSEG correspondientes a un asiento contable. Ejemplos 1500.0025000.75125.50 | |||
| Motivo de anulación ReversalReason | Código que indica el motivo por el que se anuló un asiento contable. | ||
| Descripción Cuando se revierte un documento, SAP permite que el usuario especifique un código de motivo. Este código proporciona información estructurada sobre la razón de la reversión, por ejemplo, una fecha de contabilización incorrecta o un error de introducción de datos. Este atributo es un dato clave para el Dashboard «Journal Entry Reversal Analysis». Al analizar los motivos de reversión más frecuentes, las organizaciones pueden identificar problemas sistémicos en sus procesos o carencias de capacitación, y aplicar medidas específicas para prevenir futuros errores y reducir la tasa de reversión. Por qué es importante Proporciona información directa sobre las causas de las reversiones, lo que permite realizar un análisis específico de las causas raíz para reducir futuros errores. Dónde obtenerlo Se encuentra en la tabla de cabecera del documento BKPF, campo STGRD. Ejemplos 010205 | |||
| Tiempo de aprobación ApprovalTime | 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 mide la duración del subproceso de aprobación, que suele contribuir de forma significativa al tiempo de ciclo total. Se calcula como la diferencia entre la actividad «Journal Entry Submitted» y la actividad correspondiente «Journal Entry Approved» o «Journal Entry Rejected». El tiempo de aprobación es la métrica principal del Dashboard «Journal Entry Approval Performance» y del KPI «Average Journal Entry Approval Time». Analizar esta duración ayuda a identificar cuellos de botella en el Workflow de aprobación, medir el rendimiento de las personas aprobadoras y justificar cambios en el proceso, como ajustar los umbrales de aprobación. Por qué es importante Cuantifica la duración de la etapa de aprobación y ayuda a localizar y resolver retrasos en el Workflow de revisión y aprobación. Dónde obtenerlo Se calcula restando la marca de tiempo del evento «Journal Entry Submitted» de la del evento «Journal Entry Approved» o «Journal Entry Rejected». Ejemplos P1DT2HPT4H15MP3D | |||
Record to Report - Actividades de los asientos contables
| Actividad | Descripción | ||
|---|---|---|---|
| Asiento contable aparcado | Esta actividad marca la creación inicial de un asiento contable en estado preliminar, antes de registrarlo oficialmente en el libro mayor. SAP la captura explícitamente cuando un usuario guarda un documento mediante una transacción de aparcamiento y establece el estado del documento como «aparcado». | ||
| Por qué es importante Este es un evento de inicio crítico para los procesos que incluyen revisión y aprobación. Analizar el tiempo entre el aparcamiento y el registro ayuda a identificar retrasos en las fases previas al registro y de aprobación. Dónde obtenerlo Este evento se identifica en la tabla de cabecera de documentos BKPF. Un documento se considera aparcado cuando se crea con el estado BKPF-BSTAT = «V». La marca de tiempo del evento corresponde a la fecha y hora de creación, BKPF-CPUDT y BKPF-CPUTM. Recopilar Identificar la creación del documento en BKPF cuando BKPF-BSTAT es «V». Tipo de evento explicit | |||
| Asiento contable aprobado | Esta actividad marca la aprobación final de un asiento contable dentro de un Workflow, lo que lo habilita para su registro. El evento se captura en el registro del Workflow cuando se completa el último paso de «liberar» o «aprobar». | ||
| Por qué es importante Este es un hito clave que concluye el proceso de aprobación. La duración hasta esta actividad es un KPI crítico de la eficiencia de aprobación, mientras que el tiempo entre este evento y el registro mide el retraso posterior a la aprobación. Dónde obtenerlo Se infiere a partir de la marca de tiempo de finalización del último paso de aprobación en el registro de SAP Business Workflow. Esta es la última acción de aprobación antes de que el documento se registre o quede listo para registrarse. Recopilar Identificar la finalización del último paso de «liberar» o «aprobar» en los registros del Workflow. Tipo de evento inferred | |||
| Asiento contable enviado | Esta actividad indica que el creador ha finalizado un asiento contable aparcado y que ahora está listo para su revisión y aprobación. Normalmente se captura mediante el inicio de una tarea de SAP Business Workflow asociada al documento aparcado. | ||
| Por qué es importante Esto marca la transferencia del creador al aprobador y pone en marcha el cómputo de los KPI del tiempo del ciclo de aprobación. Es un hito clave para medir la eficiencia del Workflow de aprobación. Dónde obtenerlo Se infiere a partir de la hora de inicio de la instancia del Workflow de aprobación vinculada al objeto del documento financiero. Para ello, es necesario analizar tablas de registros del Workflow, como SWW_WI2OBJ, y localizar el Workflow iniciado para la sociedad, el número de documento y el ejercicio fiscal específicos. Recopilar Identificar el evento de inicio del Workflow para el objeto del documento aparcado. Tipo de evento inferred | |||
| Asiento contable registrado | Esta es la actividad central en la que el asiento contable se registra oficialmente en el libro mayor y afecta a los estados financieros. El evento se captura explícitamente cuando el estado del documento se establece como «registrado» y se asigna una fecha de registro. | ||
| Por qué es importante Este es el hito más importante, ya que indica que el asiento contable se ha procesado correctamente. El tiempo de ciclo de principio a fin suele medirse hasta este punto, que también es un evento clave para analizar el cierre financiero. Dónde obtenerlo Se identifica cuando un documento de la tabla BKPF tiene una fecha de registro, BKPF-BUDAT. En los documentos aparcados, esto corresponde al momento en que el estado BKPF-BSTAT cambia de «V» a vacío. La marca de tiempo del registro es la fecha de entrada BKPF-CPUDT. Recopilar Identificar cuándo BKPF-BSTAT cambia de «V» a vacío o, en los registros directos, el evento de creación. Tipo de evento explicit | |||
| Proceso de anulación del asiento contable completado | Esta actividad marca la anulación de un asiento contable registrado previamente. Una anulación es un nuevo documento contable que cancela el asiento original. | ||
| Por qué es importante Este es un evento crítico para medir la calidad de los datos y la precisión del proceso. Una tasa elevada de anulaciones apunta a problemas sistémicos en las fases iniciales de introducción o aprobación de datos, y cada anulación representa una corrección. Dónde obtenerlo Este evento se identifica en la cabecera del documento original, en la tabla BKPF. Cuando se anula un documento, SAP rellena el número del documento de anulación (BKPF-STBLG) y el motivo de anulación (BKPF-STGRD). La marca de tiempo del evento es la fecha de registro del nuevo documento de anulación. Recopilar Identificar cuándo se rellena BKPF-STBLG en el documento original; la marca de tiempo es la fecha de registro del documento de anulación. Tipo de evento explicit | |||
| Asiento contable aparcado eliminado | Representa la eliminación de un asiento contable aparcado que nunca se registró. Puede ocurrir después de un rechazo o si el asiento se creó por error. | ||
| Por qué es importante Esta actividad marca un final no satisfactorio del proceso. Analizar por qué se eliminan los documentos aparcados puede revelar problemas como asientos duplicados o malentendidos sobre el proceso. Dónde obtenerlo Este evento se captura cuando cambia el estado de un documento aparcado en la tabla BKPF. El campo de estado BKPF-BSTAT se actualiza a «Z» (documento aparcado eliminado). La marca de tiempo del cambio puede encontrarse en los registros de cambios del documento (CDHDR). Recopilar Identificar cuándo BKPF-BSTAT se actualiza a «Z». Tipo de evento explicit | |||
| Asiento contable corregido | Esta actividad indica que el creador original ha modificado un asiento contable aparcado después de que se le devolviera para realizar cambios. Se infiere detectando cambios en el documento posteriores a un evento de «Cambios solicitados». | ||
| Por qué es importante El seguimiento de las correcciones ayuda a cuantificar el esfuerzo dedicado a las correcciones. El tiempo entre la solicitud de cambio y la corrección pone de manifiesto los retrasos en la resolución de problemas de los asientos enviados. Dónde obtenerlo Se infiere analizando los registros de cambios de documentos, las tablas CDHDR y CDPOS, del documento aparcado. Un cambio registrado después de un evento de rechazo en el Workflow indica que se ha realizado una corrección. La marca de tiempo procede de la tabla CDHDR. Recopilar Identificar una entrada del registro de cambios en CDHDR/CDPOS posterior a un evento de rechazo. Tipo de evento inferred | |||
| Asiento contable creado | Representa la creación de un asiento contable que se registra directamente, sin un paso previo de aparcamiento. SAP captura este evento cuando se crea un documento mediante una transacción de registro directo. | ||
| Por qué es importante Esta actividad sirve como punto de inicio alternativo para procesos de asientos contables más sencillos que no requieren un Workflow de aprobación. Ayuda a diferenciar los registros directos simples de los asientos aparcados más complejos. Dónde obtenerlo Este evento corresponde a la creación de un documento en la tabla BKPF cuando el estado BKPF-BSTAT está vacío (registrado). La marca de tiempo del evento es la fecha de creación, BKPF-CPUDT. En estos documentos, los eventos «Creado» y «Registrado» ocurren simultáneamente. Recopilar Identificar la creación del documento en BKPF cuando BKPF-BSTAT está vacío. Tipo de evento explicit | |||
| Asiento contable rechazado | Esta actividad indica el rechazo final de un asiento contable, tras el cual no se registrará. Normalmente es un estado terminal en un Workflow de aprobación y conduce a la eliminación posterior del documento aparcado. | ||
| Por qué es importante El seguimiento de los rechazos es fundamental para la gestión de la calidad. Analizar sus motivos y frecuencia ayuda a mejorar la tasa de asientos contables correctos desde el primer intento. Dónde obtenerlo Este resultado se captura en el registro de SAP Business Workflow y representa una decisión final del usuario de «rechazar» que termina el proceso. Posteriormente, el documento aparcado puede eliminarse. Recopilar Identificar el estado terminal de «rechazado» en el registro del Workflow del documento. Tipo de evento inferred | |||
| Cambios solicitados en el asiento contable | Representa un punto del Workflow en el que un aprobador ha revisado el asiento contable y lo ha devuelto al creador para que lo corrija. Este evento se captura en los registros del Workflow cuando se registra una decisión del usuario de «rechazar» o «devolver». | ||
| Por qué es importante Esta actividad es esencial para identificar ciclos de corrección, una fuente principal de ineficiencia y desviaciones del proceso. Una alta frecuencia de este evento indica problemas de calidad del asiento o requisitos poco claros. Dónde obtenerlo Este evento se infiere a partir de la marca de tiempo de un paso de decisión específico del usuario en el registro de SAP Business Workflow, correspondiente a una acción de «rechazar» o «enviar para corrección». Recopilar Identificar la marca de tiempo de la decisión de «rechazo» o «corrección» en los registros del Workflow. Tipo de evento inferred | |||
| Documentación adjunta | Esta actividad representa el momento en que un usuario adjunta documentos de respaldo, como facturas u hojas de cálculo, al asiento contable. Este evento no se registra explícitamente como un evento contable estándar y normalmente se infiere comprobando la creación de archivos adjuntos vinculados al objeto de documento contable. | ||
| Por qué es importante El seguimiento de esta actividad ayuda a verificar el Cumplimiento de las políticas que exigen documentación. Los retrasos en la adjunción de documentos pueden ser una causa raíz de ciclos de aprobación prolongados. Dónde obtenerlo Es difícil capturar este evento de forma fiable con una marca de tiempo. Potencialmente puede inferirse analizando las tablas de archivos adjuntos de Generic Object Services (GOS), como SOOD, y vinculando la marca de tiempo de creación del archivo adjunto con la clave del objeto del asiento contable. Recopilar Inferir a partir de la marca de tiempo de creación de los objetos vinculados en las tablas de GOS, por ejemplo, SOOD. Tipo de evento inferred | |||
| Entrada manual identificada | Esta actividad identifica si un asiento contable se creó mediante una transacción manual en línea o mediante una interfaz automatizada o un proceso por lotes. No es una acción del usuario, sino un Atributo calculado del asiento derivado de los datos del sistema. | ||
| Por qué es importante Distinguir entre asientos manuales y automatizados es clave para orientar la mejora del proceso. Los procesos manuales suelen ser el foco de las iniciativas de estandarización y automatización. Dónde obtenerlo Se calcula analizando campos de la tabla de cabecera de documentos BKPF. Los códigos de transacción (BKPF-TCODE), como «FB01», «FB50» o «FV50», indican una entrada manual, mientras que otros códigos T o nombres específicos de entrada por lotes (BKPF-AWKEY) sugieren automatización. Recopilar Derivar de BKPF-TCODE u otros indicadores del sistema de origen en la cabecera del documento. Tipo de evento calculated | |||
| Posición del asiento contable compensada | Esta actividad representa la conciliación de una posición de una cuenta de mayor gestionada por partidas abiertas, como una cuenta de compensación bancaria. Ocurre cuando una posición se cruza con otra y se cierra. | ||
| Por qué es importante En procesos como la conciliación bancaria, el tiempo necesario para compensar las partidas es un KPI crucial. Esta actividad ayuda a analizar la eficiencia de los procedimientos de conciliación y cierre mensual. Dónde obtenerlo Este evento se captura en la tabla de posiciones BSEG. Cuando se compensa una posición, se rellenan los campos de fecha de compensación (BSEG-AUGDT) y documento de compensación (BSEG-AUGBL). La marca de tiempo del evento es la fecha de compensación. Recopilar Identificar cuándo se rellena la fecha de compensación (BSEG-AUGDT) de una posición. Tipo de evento explicit | |||
| Registro entre sociedades identificado | Actividad calculada que señala un asiento contable que afecta a más de una sociedad. Se determina analizando las posiciones de un único documento financiero. | ||
| Por qué es importante Las transacciones entre sociedades pueden tener requisitos de procesamiento y aprobación más complejos. Identificarlas permite analizar por separado sus tiempos de ciclo y rutas de proceso para encontrar cuellos de botella específicos. Dónde obtenerlo Se calcula examinando la tabla de posiciones BSEG para un número de documento determinado (BELNR). Si las posiciones contienen más de un código de sociedad distinto (BSEG-BUKRS), el asiento es un registro entre sociedades. Recopilar Comprobar si existen varios valores únicos de BSEG-BUKRS para un único BKPF-BELNR. Tipo de evento calculated | |||
Guías de extracción
Pasos
- Crear el programa ABAP: En el sistema SAP, vaya al código de transacción SE38 (ABAP Editor). Introduzca un nombre para el nuevo programa, por ejemplo, Z_PM_JE_EXTRACTION, y haga clic en Crear. Proporcione un título adecuado y establezca el tipo de programa como «Executable Program».
- Definir la pantalla de selección: En el código fuente del programa, defina la pantalla de selección. Esto permite especificar parámetros como un intervalo de fechas para la creación de documentos, sociedades y tipos de documento con el fin de limitar el volumen de datos que se extraerá.
- Declarar las estructuras de datos: Defina una estructura de tabla interna que contenga los datos finales del registro de eventos. Esta estructura debe incluir todos los campos obligatorios: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate y cualquier atributo recomendado, como User, CompanyCode y PostingDate.
- Implementar la lógica de selección de datos: Escriba las consultas SQL de ABAP principales para extraer datos de cada una de las 14 actividades obligatorias. Esto implica seleccionar datos de tablas principales como BKPF (cabecera) y BSEG (posición), tablas de registro de cambios CDHDR y CDPOS, tablas de Workflow como SWWLOGHIST y tablas de compensación como BSAS y BSAK.
- Extraer documentos aparcados y contabilizados: Para los eventos «Journal Entry Parked», seleccione en BKPF los documentos cuyo estado (BSTAT) sea «V». Para los eventos «Journal Entry Created» y «Journal Entry Posted», seleccione en BKPF los documentos cuyo estado esté vacío, lo que indica un documento normal contabilizado.
- Extraer eventos de cambio y eliminación: Consulte las tablas de documentos de cambio CDHDR y CDPOS para la clase de objeto «BELEG». Filtre por la clave del documento para encontrar cambios correspondientes a las actividades «Journal Entry Corrected» o «Parked Journal Entry Deleted».
- Extraer eventos de Workflow: Para capturar actividades como «Journal Entry Submitted», «Approved», «Rejected» y «Changes Requested», consulte las tablas de Workflow. Utilice la tabla SWW_WI2OBJ para vincular el documento contable con una instancia de Workflow y, después, lea SWWLOGHIST para obtener decisiones específicas de usuarios o cambios de estado.
- Identificar eventos calculados: Para «Manual Entry Identified», compruebe el código de transacción (BKPF-TCODE) frente a una lista de códigos de transacción manuales conocidos. Para «Cross-Company Posting Identified», analice las posiciones de BSEG de un documento para comprobar si intervienen varias sociedades.
- Consolidar y transformar los datos: A medida que seleccione los datos de cada actividad, transfórmelos a la estructura final del registro de eventos. Concatene Company Code, Document Number y Fiscal Year para crear JournalEntryId. Convierta las fechas y horas de SAP en una única marca de tiempo EventTime. Añada los resultados de cada consulta a la tabla interna final.
- Implementar la exportación de archivos: Utilice instrucciones de gestión de archivos de ABAP, como OPEN DATASET, LOOP AT, TRANSFER y CLOSE DATASET, para escribir la tabla interna consolidada en un archivo CSV o plano en el directorio del servidor de aplicaciones SAP, visible mediante la transacción AL11.
- Programar como tarea en segundo plano: Vaya a la transacción SM36 (Definir tarea en segundo plano). Cree una tarea nueva, defina un paso que ejecute su programa ABAP y establezca una programación, por ejemplo, nocturna o semanal fuera del horario punta, para automatizar la extracción.
- Recuperar y dar formato al archivo: Utilice la transacción CG3Y o trabaje con la persona administradora del sistema para descargar el archivo generado del servidor de aplicaciones a su equipo local. Asegúrese de que la codificación y el formato del archivo sean adecuados para cargarlo en su herramienta de process mining.
Configuración
- Intervalo de fechas: Es fundamental definir un intervalo de fechas para gestionar el rendimiento. Utilice la fecha de creación del documento (BKPF-CPUDT) como filtro principal. Para un análisis inicial, se recomienda un periodo de 3 a 6 meses. Para las pruebas, utilice un intervalo de unos pocos días en el que sepa que existen datos.
- Filtro de sociedad: Filtre siempre por sociedad (BKPF-BUKRS). Extraer datos de todas las sociedades a la vez puede consumir muchos recursos. Comience con una sociedad o un grupo pequeño de sociedades relevantes.
- Filtro de tipo de documento: Utilice el filtro de tipo de documento (BKPF-BLART) para limitar el alcance a tipos específicos de asientos contables, como «SA» para documentos de mayor, si no necesita analizar todos los tipos de documento.
- ID de tareas de Workflow: La lógica para extraer eventos de Workflow depende de los ID de tarea específicos que utilice su sistema para las aprobaciones, los rechazos y los envíos. Estos ID deben configurarse en el código fuente del programa según las definiciones de Workflow de su empresa.
- Consideraciones de rendimiento: El programa combina varias tablas grandes, especialmente CDPOS y las tablas del historial de Workflow. Ejecutarlo durante el horario laboral punta puede afectar al rendimiento del sistema. Prográmelo siempre como una tarea en segundo plano fuera del horario punta. Considere la posibilidad de crear índices secundarios en la base de datos si el rendimiento es un problema recurrente.
- Requisitos previos: Este método requiere una persona usuaria con autorizaciones de desarrollo ABAP (para SE38) y permisos para crear y gestionar tareas en segundo plano (para SM36). La persona usuaria o la tarea también necesita acceso de lectura a todas las tablas financieras, de Workflow y del sistema pertinentes (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST, etc.).
a Consulta de ejemplo abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Pasos
- Establecer la conexión con la base de datos: Obtenga credenciales de solo lectura para la base de datos de SAP ECC. Utilice un cliente SQL estándar, como DBeaver, SAP HANA Studio o SQL Server Management Studio, para conectarse a la base de datos.
- Preparar la consulta SQL: Copie la consulta SQL completa proporcionada en la sección «query» de este documento en su cliente SQL.
- Configurar los parámetros de extracción: Antes de ejecutarla, configure los marcadores de posición de la consulta. Sustituya
'[START_DATE]'y'[END_DATE]'por el intervalo de fechas deseado en formato'YYYYMMDD'. Sustituya'[COMPANY_CODE_1]', '[COMPANY_CODE_2]'por los códigos de sociedad de SAP específicos que desea analizar. - Definir el sistema de origen: En la instrucción
SELECTprincipal, sustituya el marcador de posición'[Your SAP System ID]'por el ID real del sistema SAP (SID) para identificar correctamente el origen de los datos. - Ejecutar la consulta: Ejecute la consulta SQL configurada en la base de datos de SAP. El tiempo de ejecución variará según el intervalo de fechas y el tamaño de las tablas de su base de datos.
- Revisar los resultados iniciales: Cuando finalice la consulta, revise brevemente las filas devueltas para comprobar que los datos se han cargado correctamente. Verifique que haya distintas actividades y que campos clave como
JournalEntryIdyEventTimeno estén vacíos. - Gestionar las marcas de tiempo: La consulta concatena los campos de fecha y hora en una cadena con formato
YYYYMMDDHHMMSS. Asegúrese de que su sistema de destino o el procesamiento posterior puedan interpretar este formato, o ajuste la función SQLCONCATa un formato ISO 8601 comoYYYY-MM-DDTHH:MI:SSsi su base de datos lo admite. - Exportar los datos: Exporte el conjunto completo de resultados desde su cliente SQL a un archivo CSV. Utilice la codificación UTF-8 para evitar problemas con caracteres especiales.
- Preparar la carga: Antes de cargar los datos en una herramienta de Process Mining, confirme que los encabezados de columna coincidan con el esquema de datos requerido.
JournalEntryId,ActivityNameyEventTimeson campos críticos. Añada la columnaLastDataUpdatee indique en ella la marca de tiempo de la extracción. - Validación final: Siga los pasos descritos en la sección «validationSteps» para comprobar que los datos extraídos estén completos y sean precisos antes de iniciar el análisis.
Configuración
- Autorizaciones de la base de datos: El usuario de la base de datos necesita acceso de lectura a las siguientes tablas de SAP: BKPF, BSEG, CDHDR, CDPOS, T001 y V_USERNAME. Para las actividades relacionadas con Workflow, también se necesita acceso a SWW_WI2OBJ y SWWLOGHIST. Este nivel de acceso suele concederse únicamente a equipos técnicos especializados.
- Filtrado por intervalo de fechas: Es fundamental filtrar los datos por un intervalo de fechas específico para garantizar el rendimiento de la consulta. La consulta proporcionada utiliza marcadores de posición para las fechas inicial y final, que se aplican a la fecha de creación del documento (
BKPF.CPUDT). Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses. - Filtrado por entidad: Para gestionar el volumen de datos y centrar el análisis, filtre siempre por código de sociedad (
BKPF.BUKRS). También puede filtrar por tipo de documento (BKPF.BLART) para incluir únicamente los tipos de asientos relevantes, por ejemplo, «SA» para documentos de mayor, y excluir documentos operativos como facturas o pagos si quedan fuera del alcance. - Consideraciones de rendimiento: Las consultas directas a tablas principales como BSEG y CDPOS pueden consumir muchos recursos. Se recomienda encarecidamente ejecutar esta extracción fuera del horario de mayor actividad para evitar afectar al rendimiento del sistema para las personas usuarias. Evite extraer datos de más de un año en una sola ejecución.
- ID de tareas de Workflow: La consulta contiene marcadores de posición como
'[WF_TASK_ID_SUBMIT]'y'[WF_TASK_ID_APPROVE]'. Debe sustituirlos por los ID de tarea reales de la configuración específica del Workflow de asientos de su sistema. Puede identificarlos con la ayuda de una persona especialista en SAP Workflow o analizando la definición técnica del Workflow en la transacción PFTC.
a Consulta de ejemplo sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Pasos
- Establezca la conexión con SAP: En su herramienta ETL de terceros, configure una conexión de origen nueva con su sistema SAP ECC. Normalmente necesitará los datos del servidor de aplicaciones, el cliente, el número de sistema y una cuenta de Usuario de SAP dedicada con las autorizaciones RFC necesarias.
- Defina las fuentes de datos: En su proyecto de extracción, añada las tablas SAP necesarias como fuentes de datos. Las tablas principales incluyen BKPF (encabezado del documento contable), BSEG (segmento del documento contable), VBSEGK (encabezado del documento aparcado), CDHDR (encabezado del documento de modificación), CDPOS (posiciones del documento de modificación), SWW_WI2OBJ (enlaces entre el flujo de trabajo y el objeto), SWWLOGHIST (registro del flujo de trabajo) y SRGBTBREL (relaciones de los archivos adjuntos de GOS).
- Extraiga los eventos base, creados y aparcados: Cree el primer flujo de datos para extraer los eventos iniciales. Para «Journal Entry Parked», utilice VBSEGK como fuente. Para «Journal Entry Created», utilice BKPF y filtre los documentos que no sean reversiones ni se hayan aparcado inicialmente. Puede hacerlo mediante una combinación antijoin con VBSEGK.
- Extraiga los eventos del flujo de trabajo: Cree un flujo de datos que combine BKPF con SWW_WI2OBJ mediante la clave de objeto, formada por el código de empresa, el número de documento y el ejercicio fiscal, para encontrar el ID de instancia del flujo de trabajo. Combine este resultado con SWWLOGHIST para extraer eventos como «Submitted», «Approved», «Rejected» y «Changes Requested» según los resultados de las tareas del flujo de trabajo y las decisiones de las personas usuarias registradas en el historial.
- Extraiga los eventos de modificación y eliminación: Utilice las tablas CDHDR y CDPOS para identificar modificaciones. Para «Journal Entry Corrected», filtre las modificaciones realizadas en documentos aparcados, con la clase de objeto «FIPP». Para «Parked Journal Entry Deleted», busque marcadores de eliminación en los registros de modificaciones de los documentos aparcados.
- Extraiga los eventos de archivos adjuntos: Para capturar «Documentation Attached», combine BKPF con SRGBTBREL cuando el tipo de objeto sea «BKPF» y la relación sea «[Your attachment relationship type]». La fecha de creación del enlace sirve como hora del evento.
- Extraiga los eventos de compensación y reversión: Para «Journal Entry Line Item Cleared», consulte la tabla BSEG cuando el campo del documento de compensación (AUGBL) esté completo. La hora del evento es la fecha de contabilización del documento de compensación (AUGDT). Para «Journal Entry Reversal Processed», consulte BKPF en busca de documentos que sean reversiones, identificados porque contienen un valor en el campo del documento revertido (STBLG).
- Derive los eventos calculados: Cree bloques de lógica independientes para los eventos calculados. Para «Manual Entry Identified», filtre BKPF según una lista de códigos de transacción manuales, como FB01, FB50 y F-02. Para «Cross-Company Posting Identified», agrupe la tabla BSEG por ID de documento e identifique los documentos que tengan más de un código de empresa distinto.
- Combine todos los flujos de eventos: Utilice una transformación UNION en su herramienta ETL para combinar las salidas de todos los flujos de eventos individuales, como Created, Parked y Approved, en una única tabla de registro de eventos. Asegúrese de que los nombres y tipos de datos de las columnas sean coherentes en todos los flujos.
- Asigne el esquema final: Asigne los datos combinados a la estructura requerida del registro de eventos y cree
JournalEntryId,ActivityName,EventTime,Usuarioy los demás atributos requeridos y recomendados. Añada columnas estáticas comoSourceSystemy utilice la hora de ejecución del trabajo ETL paraLastDataUpdate. - Configure la carga incremental: Para las extracciones continuas, configure una estrategia de carga incremental. Utilice la última fecha de creación o modificación, como BKPF.CPUDT o CDHDR.UDATE, como marca de agua para extraer únicamente los registros nuevos o actualizados desde la última ejecución.
- Exporte para ProcessMind: Programe el trabajo de extracción y configure el paso de salida final para guardar el registro de eventos como un archivo CSV o Parquet en una ubicación accesible para que ProcessMind pueda cargarlo.
Configuración
- Requisitos previos: Una herramienta ETL de terceros con licencia, por ejemplo, Theobald Xtract Universal, Informatica o Talend, y un conector específico para SAP. Una cuenta de usuario de SAP con acceso RFC y autorizaciones para leer tablas financieras, como S_TABU_DIS para los grupos de tablas F_00 y F_WF, además de datos de Workflow y logs de cambios.
- Parámetros de conexión: Necesitará la dirección IP o el nombre de host del servidor de aplicaciones SAP, el número de sistema y el ID de cliente. Debe utilizar una gestión segura de credenciales para el nombre de usuario y la contraseña de SAP.
- Filtros clave: Aplique siempre filtros sobre la sociedad (BKPF.BUKRS) y el ejercicio fiscal (BKPF.GJAHR) en el origen para limitar el volumen de datos. Se recomienda especialmente filtrar por la fecha de creación del documento (BKPF.CPUDT) para definir un periodo de extracción concreto, por ejemplo, los últimos 6 meses.
- Selección del intervalo de fechas: Para la carga inicial, seleccione un periodo representativo de entre 3 y 6 meses. Para las cargas delta posteriores, utilice una marca de agua sobre un campo de fecha y hora como
CPUDTpara obtener únicamente los registros nuevos. - Consideraciones de rendimiento: Las combinaciones con BSEG, CDPOS y las tablas de Workflow pueden ser muy lentas. Asegúrese de que su herramienta ETL envíe los filtros al origen SAP siempre que sea posible. Extraiga los datos en bloques o paquetes más pequeños si la herramienta lo permite, especialmente en cargas históricas grandes.
- Personalización de Workflow: La lógica para identificar actividades de Workflow como «Aprobado» o «Rechazado» depende en gran medida de sus Templates de Workflow específicos. Deberá identificar en su sistema los ID correctos de las tareas de Workflow y las claves de decisión de los usuarios para utilizarlos en los filtros.
a Consulta de ejemplo sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 ¿Listo para empezar?
Utilice esta plantilla de datos para iniciar su recorrido de process mining en Record to Report - Journal Entry. Obtenga información más profunda y mejore la eficiencia de sus operaciones financieras.
Optimice ahora su Record to Report - Journal Entry
Reduzca un 30 % el tiempo de ciclo de Journal Entry y garantice informes impecables.
No necesita tarjeta de crédito. Empiece a mejorar hoy mismo.