Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas
Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de Extracción para SAP S/4HANA
Purchase to Pay - Atributos de Procesamiento de Facturas
| Nombre | Descripción | ||
|---|---|---|---|
| Número de Factura InvoiceNumber | El identificador único para el documento de factura del proveedor, que sirve como identificador principal del case para el proceso. | ||
| Descripción El Número de Factura es el identificador único asignado a cada factura de proveedor dentro de SAP S/4HANA. Vincula todas las actividades relacionadas, como la creación, el "estacionamiento", la aprobación y el pago, en una única instancia de proceso cohesiva. En Process Mining, este atributo es fundamental para rastrear el recorrido de principio a fin de cada factura. Permite la reconstrucción de todo el flujo del proceso, desde la recepción hasta el pago final, posibilitando el análisis de los tiempos de ciclo, bottlenecks y variaciones del proceso a nivel de factura individual. Por qué es importante Es la clave esencial para conectar todos los eventos relacionados, permitiendo un seguimiento completo del ciclo de vida de una factura a través del sistema. Dónde obtener Este es el Número de Documento Contable, que se encuentra en la tabla BKPF, campo BELNR. Ejemplos 190000000119000000451900000132 | |||
| Hora del Evento EventTime | La fecha y hora precisas en que ocurrió la actividad. | ||
| Descripción Event Time es la marca de tiempo que registra exactamente cuándo ocurrió una actividad específica. Estos datos son esenciales para calcular duraciones, tiempos de ciclo y tiempos de espera entre diferentes pasos del proceso. En el análisis de process mining, las marcas de tiempo precisas se utilizan para medir KPIs de rendimiento como 'Tiempo Promedio del Ciclo de Facturación' y 'Tiempo del Ciclo de Aprobación de Facturas'. Al analizar el tiempo transcurrido entre actividades, las organizaciones pueden identificar cuellos de botella donde las facturas se retrasan y detectar oportunidades para acelerar el proceso. Por qué es importante Este timestamp es la base para todo análisis basado en el tiempo, incluyendo el monitoreo de rendimiento, la identificación de bottlenecks y el seguimiento de SLA. Dónde obtener Típicamente obtenido de las tablas de documentos de cambio CDHDR (Cabecera) y CDPOS (Item), utilizando los campos UDATE y UTIME. Para algunos events, puede provenir de fechas de creación o entrada en tablas como BKPF (CPUDT, CPUTM). Ejemplos 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Nombre de la Actividad ActivityName | El nombre de la actividad o event de negocio que ocurrió en un punto específico en el tiempo para una factura. | ||
| Descripción El Activity Name describe un paso específico o un cambio de estado dentro del ciclo de vida del procesamiento de facturas. Ejemplos incluyen 'Factura Creada', 'Factura Enviada para Aprobación', 'Bloqueo de Pago Establecido' y 'Pago Ejecutado'. Este atributo es crucial para construir el mapa de procesos, que representa visualmente el flujo de actividades. Analizar la secuencia, frecuencia y duración entre estas actividades ayuda a identificar bottlenecks, ciclos de retrabajo y variaciones de proceso no conformes. Forma la columna vertebral de cualquier análisis de Process Mining. Por qué es importante Define los pasos del proceso, lo que permite la visualización de mapas de procesos y el análisis de los flujos y variaciones del proceso. Dónde obtener Derivado de una combinación de códigos de transacción SAP (SY-TCODE), estados de objetos de documentos de cambio (CDHDR/CDPOS) y valores de campos específicos que indican cambios de estado. Ejemplos Factura AparcadaFactura AprobadaPago Ejecutado | |||
| `Número de Proveedor` VendorNumber | El identificador único del proveedor que presentó la factura. | ||
| Descripción El Número de Proveedor identifica al proveedor o acreedor asociado con la factura. Vincula la transacción de la factura con los datos maestros del proveedor. Este atributo es crítico para el análisis centrado en el proveedor, como evaluar el 'Rendimiento de Pagos a Proveedores' o identificar proveedores que frecuentemente envían facturas problemáticas que conducen a excepciones o bloqueos de pago. Ayuda en la gestión de las relaciones con los proveedores y en la evaluación de la fiabilidad del proveedor. Por qué es importante Permite el análisis del rendimiento del proceso por proveedor, ayudando a identificar patrones, gestionar relaciones y evaluar problemas relacionados con los proveedores. Dónde obtener Típicamente encontrado en la tabla de segmento de documento contable BSEG, campo LIFNR. Ejemplos 100345700012V9832 | |||
| Fecha de Vencimiento de Pago PaymentDueDate | La fecha límite en la que la factura debe ser pagada para evitar que esté vencida. | ||
| Descripción La Fecha de Vencimiento de Pago es la fecha calculada en la que vence el pago al proveedor, basándose en la fecha de la factura y las condiciones de pago acordadas. Sirve como una fecha límite crítica en el proceso. Este atributo es esencial para el KPI 'Tasa de Pagos a Tiempo' y el dashboard de 'Rendimiento de Pagos a Proveedores'. Al comparar la fecha de pago real con la fecha de vencimiento, una empresa puede medir su capacidad para cumplir con las obligaciones de pago, lo que afecta las relaciones con los proveedores y la reputación financiera. Por qué es importante Es el principal punto de referencia para medir el rendimiento de los pagos a tiempo, lo cual es crucial para mantener buenas relaciones con los proveedores y evitar cargos por pagos atrasados. Dónde obtener Esta fecha a menudo está directamente disponible en la partida individual del proveedor en la tabla BSEG, campo ZFBDT (Fecha base para el cálculo de la fecha de vencimiento). La fecha de vencimiento neta se calcula a partir de esta fecha base y las condiciones de pago. Ejemplos 2023-05-302023-06-152023-07-01 | |||
| Importe de Factura AmountInCompanyCodeCurrency | El importe bruto total de la factura en la moneda local de la sociedad. | ||
| Descripción Este atributo representa el valor total de la factura. Es una métrica clave para comprender el impacto financiero y la escala de la operación de procesamiento de facturas. Analizar los importes de las facturas ayuda a priorizar las facturas de alto valor para un procesamiento más rápido, identificar tendencias en el gasto y correlacionar problemas del proceso con el valor financiero. Por ejemplo, se puede utilizar para investigar si las facturas de alto valor tienen más probabilidades de ser bloqueadas o de tener tiempos de aprobación más largos. Por qué es importante Proporciona contexto financiero al proceso, permitiendo análisis basados en valor monetario, como identificar si las facturas de alto valor se procesan de manera diferente. Dónde obtener Este valor se deriva típicamente de la suma de las partidas individuales relevantes en la tabla BSEG, campo WRBTR (Importe en moneda local). Ejemplos 1500.75125000.00850.20 | |||
| Motivo de bloqueo de pago PaymentBlockReason | Un código que indica el motivo por el cual una factura está bloqueada para su pago. | ||
| Descripción Cuando una factura está bloqueada para el pago, este atributo proporciona el motivo específico del bloqueo, como 'Discrepancia de Cantidad' o 'Discrepancia de Precio'. Estos motivos se configuran en SAP para estandarizar el manejo de excepciones. Este atributo es crucial para el dashboard 'Ocurrencia y Duración de Bloqueos de Pago'. Analizar la frecuencia de diferentes motivos de bloqueo ayuda a identificar las causas raíz de los retrasos en los pagos, como problemas con proveedores específicos, materiales o procesos internos, lo que permite acciones correctivas dirigidas. Por qué es importante Proporciona la causa raíz específica de los bloqueos de pago, lo que permite un análisis dirigido para reducir los retrasos y mejorar el procesamiento "a la primera". Dónde obtener Situado en la partida de proveedor en la tabla BSEG, campo ZLSPR (Clave de Bloqueo de Pago). Ejemplos RIA | |||
| Nombre de Usuario UserName | El ID de usuario de SAP de la persona o el sistema que realizó la actividad. | ||
| Descripción Este atributo identifica al usuario que ejecutó una transacción específica o creó un documento. Puede ser el ID de usuario de un individuo o un ID de sistema para trabajos por lotes automatizados. Analizar por usuario ayuda a comprender la distribución de la carga de trabajo, identificar necesidades de capacitación y detectar comportamientos de usuario inusuales. Por ejemplo, puede destacar qué usuarios manejan frecuentemente excepciones o qué facturas se procesan automáticamente (por ejemplo, el usuario 'BATCHUSER'), lo cual es clave para calcular el KPI 'Tasa de Automatización de Facturas'. Por qué es importante Atribuye las actividades del proceso a usuarios o cuentas de sistema específicos, lo que permite el análisis de la carga de trabajo, la comparación del rendimiento y la detección de la automatización. Dónde obtener Obtenido de campos como BKPF-USNAM (Registrado por) o CDHDR-USERNAME (Modificado por). Ejemplos SMITHJMUELLERTWF-BATCH | |||
| Orden de Compra PurchasingDocument | El número de orden de compra al que está relacionada la factura. | ||
| Descripción El Número de Documento de Compra vincula la factura del proveedor con la orden de compra (PO) original. Este enlace es fundamental para el proceso de conciliación de tres vías, que verifica la factura contra la PO y la entrada de mercancías. Analizar por este atributo ayuda a comprender los problemas relacionados con las facturas respaldadas por PO frente a las no respaldadas por PO. Es clave para investigar las discrepancias de conciliación y comprender la eficiencia de la parte de adquisición del proceso. Por qué es importante Vincula la factura al proceso de adquisiciones, lo cual es esencial para analizar las discrepancias de conciliación y el cumplimiento de las órdenes de compra. Dónde obtener Esta información se encuentra típicamente en la tabla de segmento de documento BSEG, campo EBELN (Número de Documento de Compra). Ejemplos 450000123445000056784500009012 | |||
| Sociedad CompanyCode | La unidad organizativa que representa una empresa legalmente independiente para la cual se crean estados financieros. | ||
| Descripción El Código de Sociedad es una unidad organizativa fundamental en SAP Finanzas. Cada factura se asigna a un código de sociedad específico, que determina la entidad legal responsable de la transacción. En Process Mining, filtrar o comparar por Código de Sociedad es esencial para analizar el rendimiento de los procesos en diferentes unidades de negocio, entidades legales o países. Ayuda a identificar diferencias regionales en eficiencia, cumplimiento y niveles de automatización, apoyando iniciativas de mejora dirigidas. Por qué es importante Permite segmentar y comparar el rendimiento del procesamiento de facturas entre diferentes entidades legales o ubicaciones geográficas dentro de la organización. Dónde obtener Este es un campo estándar en la tabla de cabecera de documento BKPF, campo BUKRS. Ejemplos 1000US01DE01 | |||
| Tipo de Documento DocumentType | Un código que clasifica diferentes tipos de documentos contables, como facturas de proveedor o abonos. | ||
| Descripción El Document Type se utiliza en SAP para distinguir entre diferentes transacciones comerciales. Por ejemplo, 'KR' representa típicamente una factura de proveedor estándar, mientras que 'KG' podría ser una nota de crédito de proveedor. Analizar por tipo de documento permite segmentar el proceso para comprender cómo se manejan los diferentes tipos de transacciones. Por ejemplo, el proceso para una nota de crédito puede ser significativamente diferente al de una factura estándar. Esta segmentación proporciona insights de proceso más precisos y relevantes. Por qué es importante Ayuda a diferenciar entre varios tipos de transacciones financieras, como facturas estándar y notas de crédito, que a menudo siguen diferentes rutas de proceso. Dónde obtener Se encuentra en la tabla de cabecera de documento BKPF, campo BLART. Ejemplos KRREKG | |||
| ¿Es Retrabajo? IsRework | Un indicador que señala si una factura ha pasado por actividades de reproceso, como una aprobación rechazada o un bloqueo de pago eliminado. | ||
| Descripción Este atributo marca las facturas que han experimentado uno o más ciclos de retrabajo. El retrabajo se identifica por secuencias específicas de actividades, por ejemplo, 'Factura Aprobada' después de 'Factura Rechazada', o 'Bloqueo de Pago Eliminado' después de 'Bloqueo de Pago Establecido'. Este atributo simplifica el cálculo del KPI 'Tasa de Retrabajo de Facturas'. Permite a los analistas aislar e investigar fácilmente los cases con retrabajo para comprender las causas raíz de la ineficiencia y el esfuerzo manual repetido. Por qué es importante Identifica flujos de proceso ineficientes donde el trabajo debe repetirse, ayudando a cuantificar el desperdicio y a señalar las causas raíz de las excepciones del proceso. Dónde obtener Calculado basándose en la secuencia de actividades en el registro de eventos. Por ejemplo, si 'Factura Rechazada' ocurre en el seguimiento de una factura, este indicador se establecería como verdadero. Ejemplos truefalse | |||
| ¿Se pagó a tiempo? IsPaidOnTime | Un indicador que es verdadero si la factura se pagó en o antes de su fecha de vencimiento. | ||
| Descripción Este atributo booleano es el resultado de comparar la fecha de pago real (el timestamp de la actividad 'Pago Ejecutado') con la 'Fecha de Vencimiento de Pago'. Proporciona un resultado claro y binario para el estado de pago de cada factura. Este es el cálculo central para el KPI 'Tasa de Pagos a Tiempo'. Permite un filtrado y análisis sencillos para comprender las características de los pagos atrasados, como proveedores comunes, códigos de sociedad o importes de factura asociados con los retrasos. Por qué es importante Mide directamente el cumplimiento de las condiciones de pago, lo cual es un KPI crítico para la gestión de relaciones con proveedores y operaciones financieras. Dónde obtener Calculado comparando el EventTime de la actividad 'Pago Ejecutado' con el atributo PaymentDueDate. (Fecha de Pago <= PaymentDueDate). Ejemplos truefalse | |||
| `Timestamp` de Extracción ExtractionTimestamp | La fecha y hora en que los datos fueron extraídos del sistema de origen. | ||
| Descripción Este atributo registra el timestamp del event de extracción de datos. Refleja la frescura de los datos que se analizan en la herramienta de Process Mining. En el análisis, esto se utiliza para comprender la actualidad de los insights generados. Es crítico para los dashboards de monitoreo operativo asegurar que las decisiones se basen en información actualizada y para gestionar eficazmente los ciclos de actualización de datos. Por qué es importante Indica la frescura de los datos, asegurando que el análisis y los informes se basen en la información más actualizada disponible. Dónde obtener Este no es un campo de SAP. Se genera y añade por la herramienta de extracción de datos o el proceso ETL en el momento de la extracción de datos. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Automatizado IsAutomated | Un indicador que señala si una actividad fue realizada por un usuario de sistema automatizado. | ||
| Descripción Este atributo booleano es verdadero si el usuario asociado a una actividad es una cuenta de sistema o de lote conocida, como 'WF-BATCH' o 'SAP_SYSTEM'. Ayuda a distinguir entre pasos de proceso manuales y automatizados. Este atributo es esencial para calcular el KPI 'Tasa de Automatización de Facturas'. Al analizar qué partes del proceso están automatizadas, las organizaciones pueden medir el éxito de sus iniciativas de automatización e identificar nuevas oportunidades para reducir el esfuerzo manual y mejorar la eficiencia. Por qué es importante Distingue entre actividades manuales y actividades impulsadas por el sistema, lo cual es fundamental para medir las tasas de automatización e identificar oportunidades para una mayor automatización. Dónde obtener Derivado del atributo UserName. Se crea un mapeo o regla para clasificar IDs de usuario específicos como 'automatizados'. Ejemplos truefalse | |||
| Condiciones de Pago PaymentTerms | El código que define las condiciones de pago acordadas con el proveedor, como fechas de vencimiento y períodos de descuento. | ||
| Descripción Las Condiciones de Pago definen las reglas para pagar una factura, incluyendo cualquier descuento disponible por pronto pago. Por ejemplo, 'Z030' podría significar 'Pagadero a 30 días netos'. Este atributo es esencial para la planificación financiera y la optimización del capital de trabajo. En Process Mining, se utiliza para calcular la 'Fecha de Vencimiento de Pago' y para determinar la elegibilidad para descuentos por pronto pago, apoyando directamente el KPI de 'Tasa de Captura de Descuentos por Pronto Pago'. Por qué es importante Define las reglas para las fechas de vencimiento de pago y los descuentos, impactando directamente en los KPIs de pago a tiempo y la gestión del capital de trabajo. Dónde obtener Se encuentra en la partida de proveedor en la tabla BSEG, campo ZTERM (Clave de Condiciones de Pago). Ejemplos 0001Z030NT60 | |||
| Fecha de Factura InvoiceDate | La fecha en que el proveedor emitió el documento de factura. | ||
| Descripción La Fecha de Factura, también conocida como fecha de documento, es la fecha proporcionada por el proveedor en la factura. Se utiliza como punto de partida para calcular la fecha de vencimiento de pago basándose en las condiciones de pago acordadas. En el análisis, esta fecha es fundamental para los cálculos financieros, como la determinación del envejecimiento de las facturas y la elegibilidad para descuentos por pronto pago. Es una entrada clave para el KPI 'Tasa de Captura de Descuentos por Pronto Pago'. Por qué es importante Sirve como base para calcular las condiciones y fechas de vencimiento de pago, lo cual es esencial para gestionar el capital de trabajo y capturar descuentos. Dónde obtener Se encuentra en la tabla de cabecera de documento BKPF, campo BLDAT (Fecha de Documento). Ejemplos 2023-04-122023-05-152023-06-20 | |||
| ID del Sistema de Origen SourceSystemId | El identificador del sistema SAP S/4HANA de origen desde el que se extrajeron los datos. | ||
| Descripción Este atributo especifica el sistema de origen, por ejemplo, 'S4H_PROD' o 'ERP_EU'. Es particularmente importante en entornos con múltiples instancias de ERP o una mezcla de sistemas heredados y modernos. Para el análisis, permite comparar el rendimiento del proceso en diferentes sistemas o regiones. Asegura la procedencia de los datos y es crucial para la gobernanza de datos y la resolución de problemas cuando los datos de múltiples fuentes se combinan en una plataforma central de Process Mining. Por qué es importante Proporciona contexto sobre el origen de los datos, lo cual es esencial para la gobernanza de datos y para comparar procesos entre diferentes sistemas o ubicaciones de la empresa. Dónde obtener Este valor se deriva típicamente del ID de sistema SAP (sy-sysid) durante la extracción de datos o se configura como un valor estático en el pipeline ETL. Ejemplos S4PS4H_PROD_100ECC_EU | |||
| Motivo de Reversión ReversalReason | Un código que indica el motivo por el cual se anuló un documento de factura. | ||
| Descripción Si una factura se contabiliza incorrectamente, a menudo se anula. El código de Motivo de Anulación explica por qué se tomó esta acción, por ejemplo, 'Fecha de contabilización incorrecta' o 'Error de entrada de datos'. Analizar los motivos de anulación ayuda a identificar patrones de errores en el proceso de contabilización de facturas. Esta información puede utilizarse para mejorar la capacitación, reforzar los controles del sistema o abordar problemas recurrentes que conllevan a retrabajos financieros y gastos administrativos. Por qué es importante Explica por qué se anularon las facturas, proporcionando una visión directa de las fuentes de error y el retrabajo en el proceso de contabilización. Dónde obtener Se encuentra en la cabecera del documento original en la tabla BKPF, campo STGRD (Motivo de anulación). Ejemplos 010205 | |||
| Número de Documento de Compensación ClearingDocumentNumber | El número de documento que compensa la factura, típicamente representando el documento de pago. | ||
| Descripción El Número de Documento de Compensación vincula un item de factura abierta con la transacción que lo compensa, que casi siempre es el documento de pago. Esto confirma que la factura ha sido pagada. Este atributo es el enlace definitivo entre una factura y su pago. Se utiliza para identificar la actividad 'Pago Ejecutado' y su timestamp correspondiente, lo cual es esencial para calcular el tiempo de ciclo de principio a fin y la tasa de pago a tiempo. Por qué es importante Confirma que una factura ha sido pagada y la vincula a la transacción de pago específica, lo cual es crítico para el tiempo de ciclo y el análisis del rendimiento del pago. Dónde obtener Se encuentra en la tabla de segmento de documento BSEG, campo AUGBL (Número de Documento de Compensación). Ejemplos 150000000115000000231500000088 | |||
| Recuento de Ciclos de Aprobación ApprovalCycleCount | Un recuento de cuántas veces se envió una factura para aprobación. | ||
| Descripción Esta métrica cuenta el número de veces que la actividad 'Factura Enviada para Aprobación' ocurre para una sola factura. Un conteo mayor a uno indica que la factura fue rechazada o devuelta al menos una vez, requiriendo un nuevo ciclo de aprobación. Este atributo apoya directamente el KPI 'Tasa de Aprobación en Primera Instancia'. Al analizar las facturas con altos conteos de ciclos de aprobación, las organizaciones pueden identificar las razones de las aprobaciones fallidas, como información insuficiente o codificación incorrecta, y tomar medidas para mejorar el proceso. Por qué es importante Cuantifica el retrabajo dentro del subproceso de aprobación, ayudando a medir la tasa de aprobación "a la primera" e identificar las razones de los rechazos de aprobación. Dónde obtener Calculado contando las ocurrencias de la actividad 'Factura Enviada para Aprobación' para cada InvoiceNumber único. Ejemplos 123 | |||
| Tiempo de Procesamiento de Facturas InvoiceProcessingTime | El tiempo total transcurrido desde la primera actividad hasta la última actividad de una factura. | ||
| Descripción Esta métrica calcula la duración total del procesamiento de una sola factura, típicamente desde la creación o recepción de la factura hasta el pago final. Proporciona un resumen a nivel de case del tiempo de ciclo de principio a fin. Este atributo calculado es la base para el KPI 'Tiempo Promedio de Ciclo de Factura' y el dashboard 'Tiempo de Ciclo de Factura de Principio a Fin'. Permite una rápida identificación de los cases de mayor duración y el análisis de los factores que contribuyen a tiempos de procesamiento extendidos. Por qué es importante Mide la eficiencia de principio a fin del proceso para cada factura, destacando los casos con duraciones excepcionalmente largas que requieren investigación. Dónde obtener Calculado tomando la diferencia entre la marca de tiempo del último evento y el primer evento para cada InvoiceNumber único. Ejemplos 10 días 4 horas25 días 1 hora5 días 8 horas | |||
Purchase to Pay - Actividades de Procesamiento de Facturas
| Actividad | Descripción | ||
|---|---|---|---|
| Documento de Factura Creado | Este es el primer event, que marca la creación de un documento de factura en SAP. Puede capturarse cuando un usuario guarda un nuevo documento de factura, que podría estar en un estado estacionado o pre-contabilizado. | ||
| Por qué es importante Esta actividad marca el inicio del ciclo de vida del procesamiento de facturas. Analizar el tiempo desde este event hasta otros es crucial para medir el tiempo de entrega general del procesamiento. Dónde obtener Este event se captura a partir de la fecha y hora de creación (CPUDT, CPUTM) en la tabla de cabecera del documento, típicamente BKPF o RBKP para facturas de logística. El código de transacción (BKPF-TCODE) como FB60, MIRO o MIR7 indica el método de creación. Capturar Utilice el timestamp de creación de BKPF-CPUDT y BKPF-CPUTM para el documento de factura. Tipo de evento explicit | |||
| Factura Aprobada | Esta actividad significa que la factura ha sido aprobada por la autoridad designada. Esto se captura cuando el workflow de aprobación concluye con éxito o se establece un indicador de liberación. | ||
| Por qué es importante Este es un hito crítico que desbloquea la factura para el pago. Los retrasos en las aprobaciones son un bottleneck común, y el seguimiento de esta actividad ayuda a identificar aprobadores o pasos del proceso lentos. Dónde obtener Esto puede inferirse del paso final de liberación en un workflow de SAP o rastreando cambios en los campos de estado de liberación en tablas asociadas con la factura o su documento de compra. Capturar Inferir de eventos de finalización de workflow o cambios en el campo de estado de liberación de un documento. Tipo de evento inferred | |||
| Factura Contabilizada | Este es un event financiero clave donde la factura estacionada o aprobada se contabiliza formalmente en el Libro Mayor. Esta acción reconoce la responsabilidad hacia el proveedor. | ||
| Por qué es importante La contabilización es un hito importante que separa la entrada de datos y la aprobación de la fase de liquidación financiera. El tiempo desde la creación hasta la contabilización de la factura es una medida clave de la eficiencia interna del procesamiento. Dónde obtener Este event se identifica por la Fecha de Contabilización (BKPF-BUDAT) en la cabecera del documento. Para los documentos que se "estacionan" primero, la transición a un estado contabilizado proporciona el timestamp del event. Capturar Utilice la fecha de contabilización (BKPF-BUDAT) como timestamp del event. Tipo de evento explicit | |||
| Factura Revertida | Una actividad que representa la anulación de un documento de factura previamente contabilizado. Este es un evento final para una factura incorrecta, que a menudo se vuelve a introducir correctamente. | ||
| Por qué es importante Las reversiones indican errores críticos que no fueron detectados en etapas anteriores del proceso. Rastrear su frecuencia y causas raíz es esencial para la mejora del proceso y la reducción de imprecisiones financieras. Dónde obtener Una anulación se identifica cuando se crea un documento de anulación. La cabecera del documento original (BKPF) contendrá el número de documento de anulación (BKPF-STBLG) y viceversa. La fecha de contabilización del documento de anulación es el tiempo del evento. Capturar Identifique documentos que tengan un valor en el campo BKPF-STBLG y utilice la fecha de contabilización del documento de anulación. Tipo de evento explicit | |||
| Pago Ejecutado | Esta es la actividad final en el proceso estándar, donde se realiza el pago y la factura es compensada. Esto significa que los fondos han sido desembolsados al proveedor. | ||
| Por qué es importante Esto marca el final del ciclo de vida de la factura P2P. Es esencial para calcular el tiempo de ciclo total de principio a fin y para medir el rendimiento del pago a tiempo frente a la fecha de vencimiento. Dónde obtener Este event se captura a partir de la información del documento de compensación en la partida individual del proveedor. La Fecha de Compensación (BSEG-AUGDT) y el Documento de Compensación (BSEG-AUGBL) indican que se ha realizado el pago. Capturar Utilice la fecha de compensación (BSEG-AUGDT) de la partida individual del proveedor compensada. Tipo de evento explicit | |||
| Bloqueo de Pago Eliminado | Representa la resolución de un problema, donde se elimina un bloqueo de pago previamente establecido. Esto hace que la factura sea elegible para el pago nuevamente. | ||
| Por qué es importante El tiempo entre la activación y la eliminación de un bloqueo representa el tiempo de resolución de una excepción de proceso. Acortar esta duración es clave para mejorar la eficiencia y las relaciones con los proveedores. Dónde obtener Este event se captura cuando se borra el campo Clave de Bloqueo de Pago (BSEG-ZLSPR). Este cambio se registra en las tablas CDHDR y CDPOS, proporcionando un timestamp para la eliminación. Capturar Identifique cuándo se borra el campo BSEG-ZLSPR a través de documentos de cambio (CDHDR/CDPOS). Tipo de evento explicit | |||
| Bloqueo de Pago Establecido | Una actividad donde se coloca intencionalmente un bloqueo en una factura para evitar su pago. Esto se debe a menudo a discrepancias en precio o cantidad, o a un abono pendiente. | ||
| Por qué es importante Los bloqueos de pago son una causa principal de pagos atrasados y disputas con proveedores. Analizar la frecuencia, duración y motivos de los bloqueos es crucial para mejorar las tasas de pago a tiempo. Dónde obtener Este event se captura rastreando los cambios en el campo Clave de Bloqueo de Pago (BSEG-ZLSPR) en la partida individual de la factura. Los logs de cambios en CDHDR y CDPOS proporcionan el timestamp y el usuario de cuando se estableció el bloqueo. Capturar Identifique cuándo se rellena el campo BSEG-ZLSPR a través de documentos de cambio (CDHDR/CDPOS). Tipo de evento explicit | |||
| Datos de Factura Actualizados | Esta actividad refleja un cambio realizado en el documento de factura después de su creación inicial. Esto es común durante los ciclos de retrabajo después de un rechazo o para corregir errores. | ||
| Por qué es importante Las actualizaciones frecuentes señalan reprocesos y posibles problemas de calidad de datos en el punto de entrada. El seguimiento de estos cambios ayuda a cuantificar el esfuerzo dedicado a las correcciones y a identificar errores comunes. Dónde obtener Los cambios en los campos clave se registran en las tablas de documentos de cambio de SAP, CDHDR (cabecera) y CDPOS (posición). Los eventos pueden generarse filtrando los cambios en el objeto de factura relevante. Capturar Extraiga eventos de cambio de las tablas CDHDR y CDPOS para el objeto de factura. Tipo de evento explicit | |||
| Factura Aparcada | Representa una factura que ha sido introducida en el sistema pero aún no ha sido contabilizada en el libro mayor. El "estacionamiento" se utiliza para guardar facturas incompletas o para su revisión posterior antes de la contabilización. | ||
| Por qué es importante El 'estacionamiento' (parking) de una factura indica una pausa deliberada en el proceso. Rastrear la duración y frecuencia de las facturas estacionadas ayuda a identificar las razones de los retrasos antes de que comience el ciclo formal de contabilización y aprobación. Dónde obtener Esto se puede identificar mediante documentos creados a través de transacciones de "estacionamiento" (por ejemplo, MIR7, FV60) o verificando campos de estado específicos en la tabla BKPF o tablas de documentos "estacionados" dedicadas como VBKPF. Capturar Identifique documentos creados mediante transacciones de estacionamiento o verifique el estado de un documento estacionado. Tipo de evento explicit | |||
| Factura Enviada para Aprobación | Esta actividad marca el inicio de un workflow de aprobación formal para la factura. Esto se infiere a menudo cuando el estado de la factura cambia a 'pendiente de aprobación' o se genera un item de workflow. | ||
| Por qué es importante Este es el punto de partida para medir el tiempo del ciclo de aprobación. Comprender cuándo comienzan las aprobaciones es esencial para identificar bottlenecks en el propio workflow de aprobación. Dónde obtener Esto se infiere típicamente del inicio de un Workflow de Negocio de SAP (tabla SWW_WI2OBJ) vinculado al objeto de factura (por ejemplo, BUS2081) o un cambio en un campo de estado personalizado en la cabecera del documento. Capturar Inferir de la creación de un elemento de workflow relacionado con el documento de factura. Tipo de evento inferred | |||
| Factura Rechazada | Representa el rechazo de una factura durante el proceso de aprobación. Este event desencadena un retrabajo, que requiere corrección y reenvío. | ||
| Por qué es importante Los rechazos de facturas son un indicador clave de ineficiencia de proceso y problemas de calidad de datos. El análisis de la frecuencia y los motivos de rechazo ayuda a identificar oportunidades de mejora y capacitación. Dónde obtener Esto se infiere de actualizaciones de estado específicas en un workflow de SAP, como un estado de 'rechazado', o de events que cancelan el workflow de aprobación actual, devolviéndolo al procesador. Capturar Inferir de cambios en el estado del workflow que indican rechazo. Tipo de evento inferred | |||
| Pago Tardío Ejecutado | Este es un event calculado que ocurre cuando el pago de una factura se ejecuta después de su fecha de vencimiento calculada. Se deriva comparando dos campos de fecha. | ||
| Por qué es importante Esta actividad apoya directamente los KPI de pago a tiempo y ayuda a identificar proveedores o unidades de negocio con pagos atrasados frecuentes, lo que puede dañar las relaciones con los proveedores y generar penalizaciones. Dónde obtener Esto se calcula comparando la Fecha de Compensación (BSEG-AUGDT) con la Fecha de Vencimiento Neta. La fecha de vencimiento se calcula a partir de la Fecha Base (BSEG-ZFBDT) y las condiciones de pago (BSEG-ZTERM). Capturar Derivar comparando BSEG-AUGDT > (BSEG-ZFBDT + días de condición de pago). Tipo de evento calculated | |||
| Propuesta de Pago Creada | La factura es seleccionada e incluida en una propuesta de pago como parte de una ejecución de pago. Este es el primer paso en el proceso de pago automatizado. | ||
| Por qué es importante Esta actividad indica la intención de pagar. Los retrasos entre este paso y la ejecución final del pago pueden revelar problemas con el proceso de ejecución de pagos, las aprobaciones o la comunicación bancaria. Dónde obtener Esto se puede encontrar en las tablas de ejecución de pagos, específicamente REGUP, que contiene los items incluidos en una propuesta de pago. La fecha de ejecución en la tabla REGUH correspondiente proporciona el timestamp. Capturar Identifique cuándo una factura aparece en la tabla REGUP de una ejecución de propuesta de pago. Tipo de evento explicit | |||
Guías de Extracción
Pasos
- Requisitos Previos y Autorización: Asegúrese de que el usuario que ejecuta la extracción tenga las autorizaciones necesarias en SAP S/4HANA para acceder a las vistas de
Core Data Services(CDS) requeridas. Las vistas clave incluyenI_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. El usuario también necesitará permisos para ejecutar consultas a través de la interfaz elegida, como un servicio OData o una conexión SQL directa. - Identifique su Método de Conexión: Determine cómo se conectará al sistema SAP S/4HANA para ejecutar la consulta SQL. Los métodos comunes incluyen el uso de SAP Data Services, SAP Data Intelligence, una herramienta ETL de terceros con un conector SAP, o una conexión SQL directa a la base de datos SAP HANA si lo permiten las políticas de seguridad de su organización.
- Defina los Parámetros de Extracción: Antes de ejecutar la consulta, defina los parámetros clave. Especifique el rango de fechas para la extracción, por ejemplo,
CreationDateentre'YYYY-MM-DD'y'YYYY-MM-DD'. Además, identifique los valores específicos deCompanyCodeque desea incluir para limitar el alcance de la extracción de datos. - Personalice la Consulta SQL: Copie la consulta SQL proporcionada en su cliente SQL o herramienta de extracción de datos elegida. Revise cuidadosamente los marcadores de posición, como
'{StartDate}','{EndDate}'y('{CompanyCode1}', '{CompanyCode2}'). Reemplace estos marcadores de posición con los valores reales que definió en el paso anterior. También es posible que necesite ajustar los nombres de campo para el estado delworkflowsegún su configuración específica de SAP. - Ejecute la Consulta: Ejecute la consulta SQL completa contra la base de datos SAP S/4HANA o a través de la capa de servicio apropiada. La consulta está diseñada para ser exhaustiva y puede tardar una cantidad significativa de tiempo en ejecutarse, dependiendo del volumen de datos y el rango de fechas seleccionado. Supervise la ejecución para detectar posibles errores o tiempos de espera agotados.
- Revise los Resultados Iniciales: Una vez que la consulta se complete, realice una revisión rápida de la salida. Verifique que las columnas
InvoiceNumber,ActivityNameyEventTimeestén pobladas. Compruebe que ve una variedad de actividades diferentes en la columnaActivityName, no solo 'Invoice Document Created'. - Aborde la Transformación de Datos: La consulta está estructurada para producir un formato de registro de eventos limpio. Sin embargo, asegúrese de que la columna
EventTimeesté en un formato de marca de tiempo consistente, comoYYYY-MM-DDTHH:MM:SS. La consulta proporcionada combina los campos de fecha y hora en una única marca de tiempo cuando es necesario. - Exporte los Datos: Exporte el conjunto de resultados final de su herramienta a un archivo CSV (valores separados por comas). Este formato es universalmente compatible con las herramientas de
process mining, incluyendo ProcessMind. - Prepare para la Carga: Antes de cargar, confirme que el archivo CSV utiliza codificación UTF-8 para evitar problemas de caracteres. Asegúrese de que los encabezados de columna en el archivo coincidan exactamente con los atributos requeridos:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Cargue a ProcessMind: Cargue el archivo CSV preparado en su proyecto de
process mining. Asigne las columnas de su archivo a los campos correspondientes de ID de caso, nombre de actividad y marca de tiempo en la configuración del modelo de datos de la herramienta.
Configuración
- Vistas CDS Utilizadas: Las fuentes de datos principales son vistas CDS estándar de SAP. Las vistas clave son
I_InvoiceDocumentpara datos de cabecera,I_OperationalAcctgDocItempara detalles de contabilización y compensación financiera, yI_ChangeDocumentconI_ChangeDocumentItempara el seguimiento de cambios históricos en atributos de factura como bloqueos de pago y estado de workflow. - Filtrado por Rango de Fechas: Es fundamental filtrar los datos por un rango de fechas específico para gestionar el rendimiento. La consulta proporcionada utiliza un marcador de posición para la
CreationDateen la vistaI_InvoiceDocument. Un punto de partida recomendado es un período de datos de 3 a 6 meses. - Filtro por Sociedad: Para asegurar que la extracción sea relevante y manejable, filtre siempre por una o más
CompanyCode. La consulta incluye un marcador de posiciónWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para este fin. - Filtro por Tipo de Documento: Puede refinar aún más la extracción filtrando por
InvoiceDocumentType. Por ejemplo, puede que desee incluir facturas de proveedor estándar (RE) pero excluir notas de crédito. Esto se puede añadir a la cláusulaWHEREdel CTE inicial. - Requisitos Previos: El usuario que ejecuta la consulta necesita las autorizaciones de visualización adecuadas para documentos financieros y de compras dentro de las sociedades especificadas. El acceso a la base de datos HANA subyacente a través de un cliente SQL no es estándar y requiere permisos especiales.
- Consideraciones de Rendimiento: La extracción de datos de las tablas de documentos de cambio (
I_ChangeDocument,I_ChangeDocumentItem) puede consumir muchos recursos. Es esencial aplicar filtros estrictos por fecha, sociedad y clase de objeto (INCOMINGINVOICE) para evitar tiempos de ejecución prolongados.
a Consulta de ejemplo sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Pasos
- Requisitos Previos y Autorización: Asegúrese de que el usuario que ejecuta la extracción tenga las autorizaciones necesarias en SAP S/4HANA para acceder a las vistas de
Core Data Services(CDS) requeridas. Las vistas clave incluyenI_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. El usuario también necesitará permisos para ejecutar consultas a través de la interfaz elegida, como un servicio OData o una conexión SQL directa. - Identifique su Método de Conexión: Determine cómo se conectará al sistema SAP S/4HANA para ejecutar la consulta SQL. Los métodos comunes incluyen el uso de SAP Data Services, SAP Data Intelligence, una herramienta ETL de terceros con un conector SAP, o una conexión SQL directa a la base de datos SAP HANA si lo permiten las políticas de seguridad de su organización.
- Defina los Parámetros de Extracción: Antes de ejecutar la consulta, defina los parámetros clave. Especifique el rango de fechas para la extracción, por ejemplo,
CreationDateentre'YYYY-MM-DD'y'YYYY-MM-DD'. Además, identifique los valores específicos deCompanyCodeque desea incluir para limitar el alcance de la extracción de datos. - Personalice la Consulta SQL: Copie la consulta SQL proporcionada en su cliente SQL o herramienta de extracción de datos elegida. Revise cuidadosamente los marcadores de posición, como
'{StartDate}','{EndDate}'y('{CompanyCode1}', '{CompanyCode2}'). Reemplace estos marcadores de posición con los valores reales que definió en el paso anterior. También es posible que necesite ajustar los nombres de campo para el estado delworkflowsegún su configuración específica de SAP. - Ejecute la Consulta: Ejecute la consulta SQL completa contra la base de datos SAP S/4HANA o a través de la capa de servicio apropiada. La consulta está diseñada para ser exhaustiva y puede tardar una cantidad significativa de tiempo en ejecutarse, dependiendo del volumen de datos y el rango de fechas seleccionado. Supervise la ejecución para detectar posibles errores o tiempos de espera agotados.
- Revise los Resultados Iniciales: Una vez que la consulta se complete, realice una revisión rápida de la salida. Verifique que las columnas
InvoiceNumber,ActivityNameyEventTimeestén pobladas. Compruebe que ve una variedad de actividades diferentes en la columnaActivityName, no solo 'Invoice Document Created'. - Aborde la Transformación de Datos: La consulta está estructurada para producir un formato de registro de eventos limpio. Sin embargo, asegúrese de que la columna
EventTimeesté en un formato de marca de tiempo consistente, comoYYYY-MM-DDTHH:MM:SS. La consulta proporcionada combina los campos de fecha y hora en una única marca de tiempo cuando es necesario. - Exporte los Datos: Exporte el conjunto de resultados final de su herramienta a un archivo CSV (valores separados por comas). Este formato es universalmente compatible con las herramientas de
process mining, incluyendo ProcessMind. - Prepare para la Carga: Antes de cargar, confirme que el archivo CSV utiliza codificación UTF-8 para evitar problemas de caracteres. Asegúrese de que los encabezados de columna en el archivo coincidan exactamente con los atributos requeridos:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Cargue a ProcessMind: Cargue el archivo CSV preparado en su proyecto de
process mining. Asigne las columnas de su archivo a los campos correspondientes de ID de caso, nombre de actividad y marca de tiempo en la configuración del modelo de datos de la herramienta.
Configuración
- Vistas CDS Utilizadas: Las fuentes de datos principales son vistas CDS estándar de SAP. Las vistas clave son
I_InvoiceDocumentpara datos de cabecera,I_OperationalAcctgDocItempara detalles de contabilización y compensación financiera, yI_ChangeDocumentconI_ChangeDocumentItempara el seguimiento de cambios históricos en atributos de factura como bloqueos de pago y estado de workflow. - Filtrado por Rango de Fechas: Es fundamental filtrar los datos por un rango de fechas específico para gestionar el rendimiento. La consulta proporcionada utiliza un marcador de posición para la
CreationDateen la vistaI_InvoiceDocument. Un punto de partida recomendado es un período de datos de 3 a 6 meses. - Filtro por Sociedad: Para asegurar que la extracción sea relevante y manejable, filtre siempre por una o más
CompanyCode. La consulta incluye un marcador de posiciónWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para este fin. - Filtro por Tipo de Documento: Puede refinar aún más la extracción filtrando por
InvoiceDocumentType. Por ejemplo, puede que desee incluir facturas de proveedor estándar (RE) pero excluir notas de crédito. Esto se puede añadir a la cláusulaWHEREdel CTE inicial. - Requisitos Previos: El usuario que ejecuta la consulta necesita las autorizaciones de visualización adecuadas para documentos financieros y de compras dentro de las sociedades especificadas. El acceso a la base de datos HANA subyacente a través de un cliente SQL no es estándar y requiere permisos especiales.
- Consideraciones de Rendimiento: La extracción de datos de las tablas de documentos de cambio (
I_ChangeDocument,I_ChangeDocumentItem) puede consumir muchos recursos. Es esencial aplicar filtros estrictos por fecha, sociedad y clase de objeto (INCOMINGINVOICE) para evitar tiempos de ejecución prolongados.
a Consulta de ejemplo sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Pasos
- Acceda al Editor ABAP: Inicie sesión en su sistema SAP S/4HANA. Abra la transacción
SE38(Editor ABAP). - Cree el Programa: Introduzca un nombre para su nuevo programa en el campo Programa, por ejemplo,
Z_PM_INVOICE_EXTRACT, y haga clic en el botón 'Crear'. Proporcione un título, establezca el Tipo en 'Programa Ejecutable' y guárdelo en un paquete adecuado. - Defina la Estructura del Programa y la Pantalla de Selección: En el editor, defina las estructuras de datos para la salida del registro de eventos final. Luego, cree una pantalla de selección para permitir a los usuarios introducir parámetros como un rango de fechas para la fecha de entrada de la factura, sociedades y tipos de documento. Esto hace que el programa sea reutilizable y flexible.
- Implemente la Lógica de Selección de Datos: Escriba las sentencias SQL ABAP principales para seleccionar datos de las diversas tablas SAP. El programa consultará secuencialmente cada una de las 13 actividades requeridas.
- Extraiga Datos de Cabecera y Posición: Para eventos fundamentales como 'Documento de Factura Creado' y 'Factura Contabilizada', seleccione datos de tablas primarias como
RBKP(Cabecera de Factura Logística) yBKPF(Cabecera de Documento Contable). - Extraiga Datos de Documentos de Cambio: Para actividades como 'Bloqueo de Pago Establecido' y 'Bloqueo de Pago Eliminado', consulte las tablas de documentos de cambio
CDHDR(Cabecera de documento de cambio) yCDPOS(Posiciones de documento de cambio). Necesitará identificar cambios en campos específicos, por ejemplo,ZLSPRen la tablaBSEG. - Extraiga Datos de Pago: Para capturar actividades relacionadas con el pago, consulte tablas como
REGUP(Posiciones procesadas del programa de pagos) para propuestas de pago yBSAK(Partidas de Proveedor Compensadas) para pagos ejecutados. Diferencie 'Pago Tardío Ejecutado' comparando la fecha de compensación (AUGDT) con la fecha de vencimiento neta (ZFBDT). - Extraiga Datos de Workflow: Para actividades de aprobación, consulte tablas de
SAP Business WorkflowcomoSWW_WI2OBJpara vincular elementos de workflow a objetos de factura. Esta parte depende en gran medida de su configuración específica de workflow y puede requerir una adaptación significativa. - Unifique los Datos en Formato de Registro de Eventos: Para cada actividad seleccionada, formatee los datos en una estructura de tabla interna común. Cada fila de esta tabla representa un único evento y debe contener el identificador de caso (
InvoiceNumber),ActivityNameyEventTime, junto con otros atributos recomendados. - Genere el Archivo de Salida: Utilice las sentencias ABAP
OPEN DATASET,TRANSFERyCLOSE DATASETpara escribir el contenido de la tabla interna final en un archivo plano en el servidor de aplicaciones SAP. Se recomienda el formato de valores separados por comas (CSV). - Programe y Ejecute: Ejecute el programa en primer plano para pruebas (usando
F8). Para ejecuciones en producción, prográmelo como unjoben segundo plano utilizando la transacciónSM36para que se ejecute durante las horas de menor actividad y evitar afectar el rendimiento del sistema. - Recupere y Cargue: Utilice la transacción
AL11para navegar al directorio del servidor de aplicaciones donde se guardó el archivo. Descargue el archivo a su sistema local. Asegúrese de que el archivo esté codificado en UTF-8 y formateado correctamente antes de cargarlo a la herramienta deprocess mining.
Configuración
- Rango de Fechas: Defina un rango de fechas específico para la extracción basado en la fecha de entrada de la factura (
RBKP-CPUDT) o la fecha de contabilización (BKPF-BUDAT). Para el análisis inicial, se recomienda un período de 3 a 6 meses para asegurar un volumen de datos manejable. - Sociedad (BUKRS): Es fundamental filtrar por una o más sociedades. La extracción de datos para todas las sociedades en una organización grande puede resultar en tiempos de ejecución extremadamente largos y archivos voluminosos.
- Tipo de Documento (BLART): Filtre por tipos de documento relevantes para aislar las facturas de proveedor. Los tipos comunes incluyen 'RE' (Factura - Bruta) y 'KR' (Factura de Proveedor). Esto ayuda a excluir documentos irrelevantes del análisis.
- Cuenta de Proveedor (LIFNR): El programa puede incluir un filtro opcional para números de proveedor específicos, lo cual es útil para análisis o pruebas dirigidas.
- Configuración del Archivo de Salida: El programa debe tener parámetros para definir la ruta del archivo de salida en el servidor de aplicaciones y el delimitador de campo, por ejemplo, una coma o un punto y coma.
- Requisitos Previos: El usuario o la cuenta del sistema que ejecuta este programa requiere acceso de desarrollador para crear y ejecutar programas ABAP (a través de
SE38) y amplias autorizaciones de lectura para las tablas de FI, MM y Basis, incluyendoBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSy tablas de workflow.
a Consulta de ejemplo abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path.