Plantilla de Datos: Procesamiento de Facturas de Cuentas por Pagar
Su Plantilla de Datos para el Procesamiento de Facturas de Cuentas por Pagar
- Atributos recomendados para un análisis integral
- Actividades clave del proceso para un seguimiento eficaz
- Guía paso a paso para la extracción de datos
Atributos del Procesamiento de Facturas de Cuentas por Pagar
| Nombre | Descripción | ||
|---|---|---|---|
Actividad ActivityName | El nombre de un evento de negocio o paso específico que ocurrió en el ciclo de vida del procesamiento de facturas. | ||
Descripción La Actividad representa una etapa o acción distinta dentro del proceso de Cuentas por Pagar, como 'Factura Recibida', 'Factura Contabilizada' o 'Pago Ejecutado'. Estos son los bloques fundamentales del mapa de procesos. El análisis de actividades es fundamental para el process mining. Ayuda a visualizar el flujo del proceso, identificar rutas comunes, detectar desviaciones del proceso estándar y medir la frecuencia y duración de cada paso. La secuencia de estas actividades para una factura determinada forma su trayectoria en el proceso. Por qué es importante Define los pasos del proceso, permitiendo la visualización y el análisis del flujo del proceso, la identificación de cuellos de botella y la detección de bucles de retrabajo. Dónde obtener Derivado de varias fuentes, incluyendo cambios de estado de documento (ej., BKPF-BSTAT), documentos de cambio (tablas CDHDR/CDPOS) o logs de workflow. Esto suele requerir una lógica de extracción personalizada. Ejemplos Factura RecibidaFactura AprobadaPago EjecutadoFactura Bloqueada para Pago | |||
Factura Invoice | El identificador único de un documento de factura, que sirve como ID de caso principal para el proceso de Cuentas por Pagar. | ||
Descripción La Factura es el objeto central que conecta todas las actividades relacionadas, desde la recepción hasta el pago. En SAP S/4HANA, suele ser una clave compuesta por el Código de Sociedad (BUKRS), un Número de Documento único (BELNR) y el Año Fiscal (GJAHR). Analizar por Factura permite una vista completa de extremo a extremo del ciclo de vida de la factura. Esto es fundamental para calcular métricas clave como el tiempo total de ciclo, identificar cuellos de botella para facturas individuales y comprender las diferentes rutas que una factura puede seguir a través del proceso. Por qué es importante Identifica de forma única el recorrido de cada factura, lo que permite rastrear su ciclo de vida completo y analizar el rendimiento del proceso caso por caso. Dónde obtener Esta es una clave compuesta derivada de las tablas BKPF (Cabecera de Documento Contable) o RBKP (Cabecera de Documento: Recepción de Factura) utilizando los campos BUKRS, BELNR y GJAHR. Ejemplos 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
Tiempo del Evento EventTime | La fecha y hora exactas en que ocurrió la actividad. | ||
Descripción Event Time es el timestamp asociado a cada actividad, proporcionando la secuencia cronológica de eventos para una factura. Estos datos son esenciales para comprender el flujo del proceso y realizar cualquier análisis basado en el tiempo. En el análisis, Event Time se utiliza para ordenar las actividades correctamente, calcular los tiempos de ciclo entre diferentes pasos, identificar los tiempos de espera y analizar el rendimiento del proceso en distintos períodos (p. ej., mes a mes). Es la base de todos los KPIs basados en la duración. Por qué es importante Este timestamp es crítico para ordenar los eventos cronológicamente y calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo y las duraciones, que son fundamentales para el Process Mining. Dónde obtener Obtenido de varios campos de fecha/hora en diferentes tablas de SAP, como Fecha de Creación (BKPF-CPUDT), Fecha de Contabilización (BKPF-BUDAT), Fecha de Compensación (BSAK-AUGDT), o timestamps del registro de cambios (CDHDR-UDATE/UTIME). Ejemplos 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
Sistema Fuente SourceSystem | El sistema del que se extrajo la data. | ||
Descripción Este atributo identifica el origen de los datos del proceso. Para esta vista, el valor será típicamente 'SAP S/4HANA'. En entornos con múltiples ERP o sistemas integrados, este campo es crucial para la trazabilidad y la segregación de datos. Asegura que el análisis se realice sobre el conjunto de datos correcto y ayuda a diagnosticar problemas de calidad de datos rastreándolos hasta la fuente. Por qué es importante Identifica el origen de los datos, lo cual es crucial para la gobernanza de datos, la resolución de problemas y en entornos multisistema. Dónde obtener Este es normalmente un valor estático que se añade durante el proceso de extracción de datos para etiquetar el origen del dataset. Ejemplos SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
Última Actualización de Datos LastDataUpdate | El timestamp que indica cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen. | ||
Descripción Este atributo proporciona la fecha y hora de la extracción o actualización de datos más reciente desde SAP S/4HANA. Es un campo de metadata crítico para comprender la actualidad de los datos que se analizan. Esta información es importante para que los usuarios sepan cuán actual es el análisis del proceso. Ayuda a gestionar las expectativas sobre la latencia de los datos y es vital para programar las actualizaciones de datos y mantener la integridad de los mismos. Por qué es importante Indica la frescura de los datos, asegurando que los usuarios estén al tanto de cuán actualizado está su análisis de proceso. Dónde obtener Este valor se genera y se registra en cada registro en el momento de la extracción de datos del sistema de origen. Ejemplos 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
Fecha de Vencimiento de Factura InvoiceDueDate | La fecha en la que vence el pago de la factura al proveedor. | ||
Descripción La Fecha de Vencimiento de la Factura es el plazo máximo para pagar al proveedor y así evitar recargos por mora y mantener una buena relación con este. Esta fecha se calcula basándose en la fecha base de la factura y las condiciones de pago acordadas con el proveedor. Esta fecha es esencial para el dashboard de 'Cumplimiento de Pagos y Antigüedad' y el KPI de 'Tasa de Pagos a Tiempo'. Al comparar la fecha de vencimiento con la fecha de pago real, el análisis puede revelar si los pagos se realizan a tiempo, anticipadamente o con retraso, lo que tiene consecuencias financieras y relacionales directas. Por qué es importante Este es el principal impulsor para el análisis de pagos a tiempo, lo que permite medir el rendimiento de los pagos y su impacto en las relaciones con los proveedores y los recargos por mora. Dónde obtener Esta fecha a menudo se calcula. La fecha de vencimiento neta se encuentra en el campo BSEG-NETDT. También puede derivarse de la fecha base para el pago (BSEG-ZFBDT) y las condiciones de pago (BSEG-ZTERM). Ejemplos 2023-10-312023-11-152024-01-10 | |||
Importe de Factura InvoiceAmount | El importe bruto total de la factura en la moneda original del documento. | ||
Descripción Este es el valor total de la factura tal como la presenta el proveedor. Incluye el coste de bienes o servicios, impuestos y cualquier otro cargo, antes de cualquier deducción o descuento. El Monto de la Factura es un atributo financiero crítico utilizado para una amplia gama de análisis. Ayuda a priorizar las facturas de alto valor, comprender el impacto financiero de los retrasos del proceso (por ejemplo, recargos por mora en facturas grandes) y segmentar el proceso (por ejemplo, '¿Las facturas de alto valor siguen una ruta de aprobación diferente?'). También es esencial para identificar posibles pagos duplicados. Por qué es importante Proporciona contexto financiero al proceso, permitiendo un análisis basado en el valor, la priorización de facturas de alto valor y la cuantificación de los impactos financieros. Dónde obtener Se encuentra en tablas como RBKP-RMWWR (importe bruto de la factura) para facturas MM o se calcula a partir de las partidas individuales en BSEG (campo WRBTR) para facturas FI. Ejemplos 1500.00250.7512345.50 | |||
Nombre de Usuario UserName | El ID de usuario de la persona que realizó la actividad. | ||
Descripción Este atributo registra el ID de usuario de SAP responsable de ejecutar una actividad específica, como contabilizar, aprobar o compensar una factura. Vincula los pasos del proceso con usuarios individuales. El análisis por Nombre de Usuario es esencial para comprender la distribución de la carga de trabajo, identificar a los de mayor rendimiento y señalar a los usuarios que puedan requerir capacitación adicional. También es clave para analizar los cuellos de botella en las aprobaciones dentro de los dashboards, ya que ayuda a identificar qué aprobadores específicos están causando retrasos en el proceso. Por qué es importante Atribuye actividades a individuos específicos, permitiendo analizar el rendimiento del usuario, la carga de trabajo y el cumplimiento de las políticas de segregación de funciones. Dónde obtener Normalmente se encuentra en tablas de cabecera como BKPF-USNAM (Registrado por) o en tablas de documentos de cambio CDHDR-USERNAME (Modificado por). Ejemplos ABROWNJSMITHAP_AUTOMATION | |||
Nombre del Proveedor VendorName | El nombre del proveedor que envió la factura. | ||
Descripción Este atributo contiene el nombre oficial del proveedor. Se vincula a través del Número de Proveedor almacenado en el documento de factura. El análisis de proveedores es crucial para gestionar las relaciones con ellos e identificar problemas de proceso específicos de ciertos proveedores. Puede ayudar a responder preguntas como '¿Qué proveedores presentan la mayor cantidad de facturas con discrepancias?' o '¿Estamos pagando consistentemente a ciertos proveedores estratégicos a tiempo?'. También es un campo clave, junto con el número de factura y el importe, para detectar posibles pagos duplicados. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, lo que ayuda a identificar proveedores problemáticos y a gestionar eficazmente las relaciones estratégicas con ellos. Dónde obtener Se obtiene de la tabla de datos maestros de proveedor LFA1 (campo NAME1), enlazando a través del Número de Proveedor (LIFNR) que se encuentra en BKPF o RBKP. Ejemplos Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
Número de Orden de Compra PurchaseOrderNumber | El identificador único del pedido de compra asociado a la factura, si corresponde. | ||
Descripción Este atributo vincula una factura a un pedido de compra (PO) preaprobado. La presencia de un número de PO es la base para el proceso de cotejo de tres vías (PO-Factura-Recepción de Mercancías). Este es un atributo vital para el análisis de cumplimiento y eficiencia. Se utiliza para calcular el KPI de 'Porcentaje de Facturas Sin PO', que mide la adhesión a las políticas de adquisición. También es fundamental para el dashboard de 'Rendimiento de Cotejo de Tres Vías', permitiendo el análisis del proceso de cotejo para facturas respaldadas por PO. Por qué es importante Fundamental para analizar la eficiencia de la conciliación a tres vías y para medir el cumplimiento de las políticas de compras, al identificar las facturas procesadas sin una orden de compra. Dónde obtener Se encuentra en las tablas de partidas individuales de factura, como RSEG-EBELN (para facturas MM) o BSEG-EBELN (para facturas FI). Ejemplos 45000012344500005678 | |||
Sociedad CompanyCode | La unidad organizativa para la cual se procesa la factura. | ||
Descripción Un Código de Sociedad es la unidad organizativa más pequeña para la cual se puede elaborar un conjunto completo e independiente de cuentas para informes externos. En el contexto de Cuentas por Pagar (AP), representa la entidad legal que debe dinero al proveedor. El análisis por Código de Sociedad permite comparar el rendimiento del proceso entre diferentes entidades legales dentro de la organización. Esto ayuda a identificar qué partes del negocio siguen procesos estándar y cuáles son más eficientes, tienen tiempos de ciclo más largos o tasas de retrabajo más elevadas. Por qué es importante Permite comparar el rendimiento de los procesos entre diferentes entidades legales, ayudando a identificar problemas específicos de cada región o unidad de negocio y a detectar las mejores prácticas. Dónde obtener Se encuentra en las tablas de cabecera de documentos, principalmente BKPF-BUKRS para facturas FI y RBKP-BUKRS para facturas MM. Ejemplos 10001710US01DE01 | |||
Condiciones de Pago PaymentTerms | Las condiciones acordadas con el proveedor para el pago de una factura, a menudo incluyendo oportunidades de descuento. | ||
Descripción Las Condiciones de Pago definen las reglas para las fechas de vencimiento y los posibles descuentos por pronto pago. Por ejemplo, un término como 'Z001' podría corresponder a 'Pagadero en 30 días, con un 2% de descuento si se paga en 10 días'. Este atributo es la base para el dashboard de 'Tasa de Captura de Descuentos por Pronto Pago'. Al analizar las condiciones de pago, es posible identificar todas las facturas elegibles para un descuento. Comparar esto con los descuentos realmente tomados revela oportunidades de ahorro perdidas y mide la eficiencia del proceso de pago. Por qué es importante Es esencial para analizar oportunidades de descuento por pronto pago, medir el rendimiento financiero del proceso de pago e identificar ahorros perdidos. Dónde obtener Se encuentra en las partidas individuales de proveedor, tabla BSEG-ZTERM, o en la cabecera de la factura en RBKP-ZTERM. Ejemplos Z0010001NT30 | |||
Descuento Aprovechado DiscountTaken | Un indicador booleano que indica si se aplicó correctamente un descuento por pronto pago. | ||
Descripción Este atributo indica si se aplicó un descuento por pronto pago al abonar la factura. Es un componente crítico para medir la eficiencia financiera en el proceso de Cuentas por Pagar. Este indicador es el centro del KPI de 'Tasa de Captura de Descuentos por Pronto Pago'. Al filtrar las facturas donde era posible un descuento (según las Condiciones de Pago) y luego analizar este indicador, una empresa puede calcular con precisión cuánto dinero se ahorró y cuántas oportunidades de ahorro se perdieron. Esto proporciona una medida clara y cuantificable del rendimiento de Cuentas por Pagar. Por qué es importante Mide directamente el éxito en la captura de los descuentos por pronto pago disponibles, lo que tiene un impacto directo en el resultado final de la empresa. Dónde obtener Se deriva verificando si el campo del importe de descuento (BSEG-SKNTO) es mayor que cero en el documento de pago. Ejemplos truefalse | |||
Es Pago Atrasado IsLatePayment | Un indicador booleano que indica si la factura se pagó después de su fecha de vencimiento. | ||
Descripción Este atributo calculado es un simple indicador de verdadero/falso que señala si el pago de una factura se realizó después de su fecha de vencimiento oficial. Se deriva al comparar la 'Fecha de Compensación' con la 'Fecha de Vencimiento de la Factura'. Este indicador simplifica el análisis para el dashboard de 'Cumplimiento y Antigüedad de Pagos' y el KPI de 'Tasa de Pago a Tiempo'. Permite un fácil filtrado y agregación para contar el número de pagos atrasados, calcular el porcentaje de pagos a tiempo e identificar proveedores o códigos de sociedad con altas tasas de pagos tardíos. Por qué es importante Mide directamente el cumplimiento de las condiciones de pago, simplifica el cálculo del KPI de pagos a tiempo y ayuda a identificar áreas con bajo rendimiento de pago. Dónde obtener Atributo calculado. La lógica es: SI ClearingDate > InvoiceDueDate ENTONCES verdadero SINO falso. Ejemplos truefalse | |||
Está Automatizado IsAutomated | Un indicador que indica si la actividad fue realizada automáticamente por el sistema y no por un usuario humano. | ||
Descripción Este atributo booleano distingue entre actividades iniciadas por humanos y aquellas ejecutadas por trabajos del sistema, workflows o bots. Por ejemplo, una ejecución de pago automatizada o una contabilización de factura generada por el sistema se marcaría como automatizada. El análisis de este atributo ayuda a comprender el nivel de automatización en el proceso de Cuentas por Pagar. Se puede utilizar para medir el éxito de las iniciativas de automatización, comparar la eficiencia de los pasos automatizados frente a los manuales, e identificar nuevas oportunidades de automatización. Por qué es importante Ayuda a medir el grado de automatización en el proceso, lo que permite analizar la eficacia de la automatización e identificar oportunidades de mejora continua. Dónde obtener Derivado a partir del nombre de usuario (ej., IDs de usuario del sistema como 'SAP_SYSTEM' o 'BATCHUSER') o códigos de transacción específicos asociados con trabajos automatizados. Ejemplos truefalse | |||
Fecha de Compensación ClearingDate | La fecha en que se realizó un pago y la factura fue compensada de las partidas abiertas. | ||
Descripción La Fecha de Compensación significa la liquidación financiera de la factura. Es la fecha en que ocurre la actividad 'Pago Compensado', marcando el paso final para la mayoría de las trayectorias exitosas de las facturas. Esta fecha se utiliza para calcular la fecha de pago real y compararla con la Fecha de Vencimiento de la Factura. Por lo tanto, es esencial para calcular el KPI de 'Tasa de Pagos a Tiempo' y para cualquier análisis relacionado con el rendimiento de pagos. También marca el punto final para calcular el tiempo de ciclo de la factura de extremo a extremo. Por qué es importante Marca la liquidación final de una factura, sirviendo como punto final para los cálculos del tiempo de ciclo y la base para el análisis de pagos a tiempo. Dónde obtener Se encuentra en las tablas de partidas compensadas, como BSAK-AUGDT para proveedores. Ejemplos 2023-10-282023-11-142024-01-09 | |||
Moneda de la Factura InvoiceCurrency | El código de moneda para el importe de la factura (ej., USD, EUR). | ||
Descripción Este atributo especifica la moneda en la que se denomina el importe de la factura. Proporciona un contexto esencial para cualquier valor financiero. En una organización multinacional, analizar las facturas sin considerar su moneda puede ser engañoso. Este campo permite un manejo adecuado de los datos financieros, ya sea convirtiendo todos los importes a una única moneda de informe o segmentando el análisis por moneda para comprender las actividades financieras regionales. Por qué es importante Proporciona el contexto necesario para el Importe de la Factura, permitiendo un análisis financiero y una elaboración de informes precisos, especialmente en contextos multinacionales. Dónde obtener Se encuentra en las tablas de cabecera de documentos, principalmente BKPF-WAERS o RBKP-WAERS. Ejemplos USDEURGBPJPY | |||
Motivo de Bloqueo BlockingReason | El motivo por el cual una factura está bloqueada para el pago, lo que indica una discrepancia. | ||
Descripción Cuando una factura no supera una verificación de validación durante el cotejo triple (3-way match) u otros pasos de verificación, se bloquea para el pago. El Motivo de Bloqueo especifica la naturaleza del problema, como una discrepancia de cantidad, una variación de precio o una entrada de mercancías faltante. Este atributo es crítico para el dashboard de 'Análisis de retrabajo por discrepancias en facturas'. Analizar la frecuencia de diferentes motivos de bloqueo ayuda a identificar las causas raíz de las ineficiencias del proceso. Por ejemplo, si la 'Variación de precio' es un motivo común, puede señalar problemas con los datos maestros en el sistema de compras. Por qué es importante Proporciona una visión directa de las causas raíz de las discrepancias en facturas y los reprocesos, lo que permite esfuerzos de mejora de procesos dirigidos. Dónde obtener Almacenado en tablas de partidas individuales de factura como RSEG, en campos que comienzan con SPGR* (ej., SPGRP, SPGRQ, SPGRT). También puede encontrarse en RBKP_BLOCKED. Ejemplos Discrepancia de PrecioDiscrepancia de CantidadFalta de Recepción de Mercancía | |||
Número de Factura del Proveedor VendorInvoiceNumber | El número de factura proporcionado por el proveedor en su documento. | ||
Descripción Este es el número de referencia del sistema contable propio del proveedor, tal como aparece impreso en el documento de factura físico o electrónico. Se introduce manualmente o se captura mediante OCR durante la recepción de la factura. Este campo es de suma importancia para fines operativos y de análisis, especialmente para el dashboard de 'Pagos potenciales duplicados de facturas'. Un método común para detectar duplicados es buscar múltiples documentos de factura internos que compartan el mismo Nombre del Proveedor, Número de Factura del Proveedor y Monto de la Factura. Es la referencia externa principal de una factura. Por qué es importante Es un campo clave para detectar posibles pagos duplicados y sirve como referencia externa principal para la comunicación con los proveedores. Dónde obtener Almacenado en el campo 'Referencia' en la cabecera del documento, típicamente BKPF-XBLNR. Ejemplos INV-2023-9876733401120231015-001 | |||
Tiempo de Procesamiento ProcessingTime | La duración de una única actividad. | ||
Descripción El Tiempo de Procesamiento, o duración de la actividad, es el tiempo transcurrido entre el inicio y el fin de una actividad. Esta métrica se calcula a partir de los datos del event log. Esta medida calculada es crucial para el dashboard 'Mapa de Calor de Duración de Actividad y Reprocesos'. Ayuda a identificar qué pasos específicos del proceso consumen más tiempo. Analizar los tiempos de procesamiento puede resaltar ineficiencias, como largos pasos de aprobación o actividades prolongadas de resolución de discrepancias, guiando los esfuerzos de mejora específicos. Por qué es importante Cuantifica el tiempo dedicado a actividades individuales, ayudando a identificar los pasos que más tiempo consumen y los cuellos de botella en el proceso. Dónde obtener Calculado al obtener la diferencia entre el EventTime de la actividad actual y el EventTime de la actividad subsiguiente para la misma factura. Ejemplos P2DT3H4MPT5HP7D | |||
Tipo de Documento de Factura InvoiceDocumentType | Una clasificación del documento de factura que controla cómo se procesa en SAP. | ||
Descripción El Tipo de Documento es un elemento clave de configuración en SAP que categoriza los documentos contables. Por ejemplo, 'KR' se utiliza típicamente para facturas de proveedor, 'RE' para facturas de MM y 'KG' para notas de crédito de proveedor. Este tipo determina elementos como el rango de numeración y los campos obligatorios. En el análisis de procesos, filtrar por Tipo de Documento permite comparar los flujos de proceso para diferentes tipos de facturas. Por ejemplo, el proceso de aprobación para una nota de crédito podría ser diferente al de una factura estándar. Esto es útil para el dashboard de 'Variantes de Enrutamiento de Aprobación de Facturas'. Por qué es importante Permite segmentar el proceso basándose en cómo se gestionan los diferentes tipos de factura, revelando variaciones en las rutas de procesamiento y los tiempos de ciclo. Dónde obtener Directamente de la tabla de cabecera de documento, campo BKPF-BLART. Ejemplos KRREKG | |||
Actividades del Procesamiento de Facturas de Cuentas por Pagar
| Actividad | Descripción | ||
|---|---|---|---|
Factura Anulada | El documento de factura ha sido revertido, anulando efectivamente su impacto financiero. Este es un estado final alternativo para el proceso, a menudo debido a entradas incorrectas o disputas con proveedores. | ||
Por qué es importante El seguimiento de las cancelaciones ayuda a identificar las razones de los fallos del proceso, como envíos duplicados o datos de factura incorrectos, lo que puede señalar problemas en etapas anteriores. Dónde obtener Esto se registra explícitamente cuando se crea un documento de anulación. La cabecera del documento original (BKPF) contendrá el número de documento de anulación (STBLG) y el motivo de anulación. Capturar Identifica la fecha de contabilización del documento de anulación, que está vinculado en la cabecera del documento original (BKPF-STBLG). Tipo de evento explicit | |||
Factura Aprobada | La factura ha recibido todas las aprobaciones necesarias dentro del sistema de workflow. Este es a menudo el paso final antes de que una factura pueda ser contabilizada o desbloqueada para el pago. | ||
Por qué es importante Este hito clave marca el final del ciclo de aprobación. El tiempo entre el enrutamiento y la aprobación es una métrica crítica para la eficiencia. Dónde obtener Se obtiene de los logs de SAP Business Workflow como un paso de finalización o liberación final. Alternativamente, puede inferirse de la eliminación de un bloqueo de pago posterior al enrutamiento. Capturar Extrae eventos de finalización de workflow de los logs de workflow de SAP o identifica el evento final de 'liberación'. Tipo de evento explicit | |||
Factura Bloqueada para Pago | El sistema ha bloqueado la factura, de forma automática o manual, impidiendo su pago. Esto se debe típicamente a discrepancias en el precio, la cantidad o a la falta de aprobaciones. | ||
Por qué es importante Este es un indicador clave de problemas y retrabajos. Analizar los motivos y la duración de los bloqueos ayuda a identificar las causas raíz de los retrasos en los pagos y las ineficiencias del proceso. Dónde obtener Este es un estado explícito registrado en el campo Clave de bloqueo de pago (ZLSPR) en la posición de acreedor del documento contable (tabla BSEG). Capturar Registrado a través de documentos de cambio cuando el campo BSEG-ZLSPR se rellena con un motivo de bloqueo. Tipo de evento explicit | |||
Factura Contabilizada | La factura se registra formalmente en el Libro Mayor, creando una obligación financiera. Un documento preliminar se convierte en un documento contabilizado, o se realiza una contabilización directa. | ||
Por qué es importante Este es un hito financiero crítico. Confirma la obligación de pago de la empresa y, a menudo, es un requisito previo para programar el abono. Dónde obtener Este evento se identifica por la Fecha de Contabilización (BUDAT) en la cabecera del documento (BKPF). Un documento contabilizado tiene un estado de documento (BKPF-BSTAT) en blanco. Capturar Utilice el timestamp de contabilización (BKPF-BUDAT) para documentos que no están 'parked' (BKPF-BSTAT está en blanco). Tipo de evento explicit | |||
Factura Recibida | Esta actividad marca la creación de un documento de factura en SAP, ya sea de forma manual o a través de una interfaz automatizada como OCR/VIM. Este evento se suele registrar a partir de la fecha y hora de creación de la cabecera del documento contable. | ||
Por qué es importante Al ser el punto de partida del proceso, esta actividad es esencial para calcular el tiempo de ciclo de la factura de extremo a extremo y para medir el rendimiento general del proceso de Cuentas por Pagar. Dónde obtener Este evento se registra a partir de la tabla de cabecera de documentos contables (BKPF), utilizando la fecha (CPUDT) y la hora (CPUTM) de creación del documento. Capturar Utilice el timestamp de creación (BKPF-CPUDT, BKPF-CPUTM) para el documento de factura. Tipo de evento explicit | |||
Pago Ejecutado | Se ha realizado un pago contra la factura. Esto se registra cuando se completa la ejecución del pago y se crea y contabiliza un documento de pago. | ||
Por qué es importante Esta actividad es crucial para el análisis del flujo de caja y para medir el KPI de 'Tasa de Pago a Tiempo' comparando esta fecha con la fecha de vencimiento de la factura. Dónde obtener Esto se captura desde la fecha de contabilización del documento de pago que compensa la factura. El número de documento de pago se vincula en el campo de documento de compensación (AUGBL) de la posición de factura (BSEG). Capturar Identifica la fecha de contabilización (BUDAT) del documento de pago que compensa la partida individual de la factura. Tipo de evento explicit | |||
Pago Liquidado | Esta actividad marca el cierre final de la factura, donde el pago y la factura se concilian entre sí en el submayor. Esto significa que el proceso ha finalizado. | ||
Por qué es importante Al ser el fin definitivo del proceso, esta actividad es esencial para el cálculo preciso del tiempo de ciclo de extremo a extremo. Confirma que la obligación ha sido saldada. Dónde obtener Este es un evento explícito que ocurre cuando la fecha de compensación (AUGDT) se rellena en la posición de acreedor del documento de factura (tabla BSEG). Capturar Utilice la fecha de compensación (BSEG-AUGDT) de la posición de factura. Tipo de evento explicit | |||
Discrepancia Resuelta | Esta actividad indica que un problema previamente identificado, que probablemente causó un bloqueo de pago, ha sido investigado y resuelto. Esto se registra cuando se elimina un bloqueo de pago de una factura. | ||
Por qué es importante El seguimiento de este bucle de retrabajo es crucial para el dashboard de 'Análisis de retrabajo por discrepancias en facturas'. Ayuda a cuantificar el tiempo y el esfuerzo dedicados a corregir errores. Dónde obtener Esto se infiere de los documentos de cambio que muestran la eliminación de un bloqueo de pago. El log de cambios para el campo BSEG-ZLSPR es la fuente principal. Capturar Identifica los documentos de cambio para la tabla BSEG donde el campo ZLSPR cambia de un valor a vacío. Tipo de evento inferred | |||
Entrada de Mercancías Conciliada | Esta actividad significa que las cantidades y valores de la factura se han cotejado con éxito con un documento de entrada de mercancías correspondiente. Esta es la validación final en un escenario de cotejo de tres vías. | ||
Por qué es importante El seguimiento de esto ayuda a identificar ineficiencias en el proceso de cotejo triple (3-way matching) y a detectar discrepancias entre las mercancías recibidas y lo que el proveedor está facturando. Dónde obtener Esto se infiere de la presencia de una referencia de documento de material (entrada de mercancías) en la posición de factura, a menudo vinculada a través del historial de la posición del pedido de compra. Capturar Se infiere de la presencia de una referencia de documento de Entrada de Mercancías en la partida individual de la factura (p. ej., en RSEG para facturas MIRO). Tipo de evento inferred | |||
Factura Enviada para Aprobación | La factura ha sido enviada a un workflow para las aprobaciones requeridas basadas en reglas de negocio. Esto marca el inicio del subproceso de aprobación. | ||
Por qué es importante Esta actividad es el punto de partida para medir el KPI de 'Tiempo Promedio de Aprobación de Facturas' y analizar los cuellos de botella en las aprobaciones. Dónde obtener Se puede extraer de los logs de SAP Business Workflow (tablas SWW*) que registran el inicio de una instancia de workflow vinculada al objeto de factura (ej., BUS2081). Capturar Extrae eventos de inicio de workflow de los logs de workflow de SAP (p. ej., tabla SWW_WIHEAD) vinculados al documento de factura. Tipo de evento explicit | |||
Factura Preliminar | Representa una factura que ha sido ingresada en el sistema, pero que aún no ha sido contabilizada en el libro mayor. Este es a menudo un paso intencional para guardar un documento incompleto para su procesamiento o aprobación posterior. | ||
Por qué es importante El seguimiento de las facturas 'parked' ayuda a identificar retrasos antes de que comience el proceso formal de contabilización y puede resaltar problemas de completitud de datos o de validación inicial. Dónde obtener Este estado se infiere del campo de estado del documento en la cabecera del documento contable (BKPF-BSTAT = 'V' para 'Parked'). El evento ocurre cuando se establece el estado. Capturar Identifica los documentos de cambio para la tabla BKPF donde el campo BSTAT esté configurado como 'V' (Vor-erfasst/Pre-registrado). Tipo de evento inferred | |||
Factura Rechazada | Un aprobador ha rechazado la factura durante el workflow de aprobación. Esta acción generalmente devuelve la factura al procesador para su corrección o aclaración. | ||
Por qué es importante El seguimiento de los rechazos resalta los bucles de retrabajo dentro del proceso de aprobación y puede indicar problemas con el cumplimiento de políticas o una codificación incorrecta de la factura. Dónde obtener Esto se registra como un evento de resultado específico dentro de los logs del SAP Business Workflow asociados a la factura. Capturar Extrae eventos de workflow con estado 'rechazado' de los logs de workflow de SAP. Tipo de evento explicit | |||
Fecha de Vencimiento de Factura Superada | Un evento calculado que indica que la fecha de vencimiento neta de la factura ha pasado sin que se haya liquidado un pago. Esto indica una situación de pago tardío o vencido. | ||
Por qué es importante Esencial para el dashboard de 'Cumplimiento y Antigüedad de Pagos', esta actividad ayuda a identificar y gestionar proactivamente las facturas vencidas y a analizar las causas raíz de los pagos tardíos. Dónde obtener Este no es un evento explícito en SAP. Se calcula comparando la fecha actual del sistema con la fecha de vencimiento neta (calculada a partir de BSEG-ZFBDT o la fecha base y las condiciones de pago). Capturar Evento calculado que se activa cuando el timestamp del evento es posterior a la fecha de vencimiento neta de la factura. Tipo de evento calculated | |||
Orden de Compra Coincidente | Esta actividad significa que la factura se ha cotejado con éxito con un pedido de compra correspondiente. Este es un paso crítico en el proceso de cotejo de tres vías para facturas basadas en compras. | ||
Por qué es importante El análisis de esta actividad es clave para medir la eficiencia del proceso de conciliación y es fundamental para los KPIs de 'Rendimiento de Conciliación a Tres Vías' y 'Porcentaje de Facturas sin Pedido de Compra'. Dónde obtener Esto se infiere cuando una posición de factura en la tabla BSEG o ACDOCA contiene un número de pedido de compra (EBELN) y una posición (EBELP) válidos. Capturar Se infiere de la presencia de una referencia de Pedido (BSEG-EBELN) en el documento de factura al momento de su creación. Tipo de evento inferred | |||
Propuesta de Pago Creada | La factura ha sido incluida en una propuesta de pago como parte de una ejecución de pago (ej., F110). Ahora está programada para el pago, a la espera de la ejecución final de dicha operación. | ||
Por qué es importante Esta actividad muestra la transición de un pasivo abierto a un elemento que se está preparando activamente para el pago, lo que ayuda a analizar la eficiencia de las operaciones de pago. Dónde obtener Este evento se registra explícitamente en las tablas de datos de ejecución de pagos, específicamente REGUP (Elementos Procesados del Programa de Pago) y REGUH (Cabecera). Capturar Identifica cuándo una factura aparece en la tabla REGUP para una ejecución de pago identificada en REGUH. Tipo de evento explicit | |||
Guías de Extracción
Pasos
- Requisitos Previos y Acceso: Asegúrese de tener un usuario con acceso de lectura al esquema de la base de datos de SAP S/4HANA (típicamente SAPABAP1 o similar) donde residen las vistas CDS. Necesitará una herramienta cliente SQL que pueda conectarse a la base de datos SAP HANA, como SAP HANA Studio, DBeaver, o herramientas de consulta de bases de datos similares.
- Identifique las Vistas CDS Principales: Las vistas CDS principales para esta extracción son I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails e I_PaymentProposalItem. Familiarícese con sus campos clave.
- Defina el Alcance de la Consulta: Abra su cliente SQL y conéctese a la base de datos SAP HANA. Antes de ejecutar la consulta completa, defina el alcance de su extracción. Esto implica establecer el identificador correcto del sistema de origen, el rango de fechas para las facturas (CreationDateTime) y los códigos de sociedad relevantes.
- Prepare la Consulta Principal: Copie la consulta SQL completa proporcionada en la sección query en su cliente SQL. La consulta utiliza Common Table Expressions (CTEs) para seleccionar primero una población base de facturas y luego construye un event log uniendo datos de 15 actividades diferentes.
- Configure los Parámetros de la Consulta: En la consulta SQL copiada, localice las variables de marcador de posición. Reemplace '[YYYY-MM-DD]' con las fechas de inicio y fin de su período de análisis. Reemplace '[Your Company Code 1]', '[Your Company Code 2]' con la lista de códigos de sociedad SAP que desea analizar.
- Ejecute la Consulta de Extracción: Ejecute la consulta SQL completa. Dependiendo del volumen de datos y el rango de fechas seleccionado, esto puede tardar desde varios minutos hasta varias horas en completarse.
- Revise los Resultados Preliminares: Una vez finalizada la consulta, revise las primeras cientos de filas del resultado. Verifique la consistencia de los datos, asegúrese de que todas las columnas estén completas como se espera y compruebe que los diferentes valores de ActivityName estén presentes.
- Exporte el Event Log: Exporte el conjunto de resultados completo desde su cliente SQL a un archivo CSV. Asegúrese de que el archivo esté codificado en UTF-8 para evitar problemas de caracteres. Asigne un nombre descriptivo al archivo, por ejemplo, sap_s4hana_ap_event_log.csv.
- Prepare para la Carga: Antes de cargar a una herramienta de Process Mining, confirme que los encabezados de columna en el archivo CSV coinciden exactamente con los nombres de atributo requeridos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Cargue a la Herramienta de Process Mining: Cargue el archivo CSV generado a su plataforma de Process Mining, mapeando las columnas a los campos correspondientes de case ID, activity y timestamp.
Configuración
- Vistas CDS Clave: La extracción se basa en una combinación de vistas CDS estándar de S/4HANA. Las vistas principales son:
- I_JournalEntry & I_JournalEntryItem: Para cabeceras de documentos financieros centrales, partidas, detalles de contabilización e información de compensación.
- I_SupplierInvoiceAPI01: Para detalles específicos de facturas de MM (Logística), incluyendo referencias a órdenes de compra (PO) y bloqueos de pago.
- I_ChangeDocument: Para rastrear el timestamp exacto de los cambios, como el establecimiento o la eliminación de un bloqueo de pago.
- I_WorkflowStatusDetails: Para extraer eventos relacionados con el workflow de aprobación de facturas.
- I_PaymentProposalItem: Para identificar cuándo una factura se incluye en una propuesta de ejecución de pagos.
- I_Supplier: Para enriquecer los datos con datos maestros del proveedor, como VendorName.
- Filtrado por Rango de Fechas: Es fundamental aplicar un filtro de rango de fechas para limitar el volumen de datos. La consulta proporcionada filtra por CreationDateTime en la CTE Invoices_Base. Se recomienda un rango de 3 a 6 meses para un análisis inicial, lo que asegura un rendimiento manejable.
- Filtros Obligatorios: Siempre filtre por CompanyCode. Analizar datos de todos los CompanyCode a la vez puede ser extremadamente lento y puede no ser relevante para el negocio. Además, filtre por JournalEntryType para seleccionar solo documentos relacionados con proveedores (p. ej., 'KR', 'RE').
- Requisitos Previos: El usuario de base de datos que ejecuta la consulta debe tener autorización SELECT sobre todas las vistas CDS utilizadas en la consulta y sobre el esquema HANA subyacente. El acceso a nivel de aplicación en el SAP GUI no es suficiente.
- Consideraciones de Rendimiento: Las consultas directas sobre I_ChangeDocument pueden consumir muchos recursos. La consulta proporcionada intenta mitigar esto prefiltrando las facturas primero. Para conjuntos de datos muy grandes, considere ejecutar la extracción durante las horas de menor actividad o en lotes con rangos de fechas más pequeños.
a Consulta de ejemplo sql
`sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X';
`Pasos
- Requisitos Previos y Acceso: Asegúrese de tener un usuario con acceso de lectura al esquema de la base de datos de SAP S/4HANA (típicamente SAPABAP1 o similar) donde residen las vistas CDS. Necesitará una herramienta cliente SQL que pueda conectarse a la base de datos SAP HANA, como SAP HANA Studio, DBeaver, o herramientas de consulta de bases de datos similares.
- Identifique las Vistas CDS Principales: Las vistas CDS principales para esta extracción son I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails e I_PaymentProposalItem. Familiarícese con sus campos clave.
- Defina el Alcance de la Consulta: Abra su cliente SQL y conéctese a la base de datos SAP HANA. Antes de ejecutar la consulta completa, defina el alcance de su extracción. Esto implica establecer el identificador correcto del sistema de origen, el rango de fechas para las facturas (CreationDateTime) y los códigos de sociedad relevantes.
- Prepare la Consulta Principal: Copie la consulta SQL completa proporcionada en la sección query en su cliente SQL. La consulta utiliza Common Table Expressions (CTEs) para seleccionar primero una población base de facturas y luego construye un event log uniendo datos de 15 actividades diferentes.
- Configure los Parámetros de la Consulta: En la consulta SQL copiada, localice las variables de marcador de posición. Reemplace '[YYYY-MM-DD]' con las fechas de inicio y fin de su período de análisis. Reemplace '[Your Company Code 1]', '[Your Company Code 2]' con la lista de códigos de sociedad SAP que desea analizar.
- Ejecute la Consulta de Extracción: Ejecute la consulta SQL completa. Dependiendo del volumen de datos y el rango de fechas seleccionado, esto puede tardar desde varios minutos hasta varias horas en completarse.
- Revise los Resultados Preliminares: Una vez finalizada la consulta, revise las primeras cientos de filas del resultado. Verifique la consistencia de los datos, asegúrese de que todas las columnas estén completas como se espera y compruebe que los diferentes valores de ActivityName estén presentes.
- Exporte el Event Log: Exporte el conjunto de resultados completo desde su cliente SQL a un archivo CSV. Asegúrese de que el archivo esté codificado en UTF-8 para evitar problemas de caracteres. Asigne un nombre descriptivo al archivo, por ejemplo, sap_s4hana_ap_event_log.csv.
- Prepare para la Carga: Antes de cargar a una herramienta de Process Mining, confirme que los encabezados de columna en el archivo CSV coinciden exactamente con los nombres de atributo requeridos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Cargue a la Herramienta de Process Mining: Cargue el archivo CSV generado a su plataforma de Process Mining, mapeando las columnas a los campos correspondientes de case ID, activity y timestamp.
Configuración
- Vistas CDS Clave: La extracción se basa en una combinación de vistas CDS estándar de S/4HANA. Las vistas principales son:
- I_JournalEntry & I_JournalEntryItem: Para cabeceras de documentos financieros centrales, partidas, detalles de contabilización e información de compensación.
- I_SupplierInvoiceAPI01: Para detalles específicos de facturas de MM (Logística), incluyendo referencias a órdenes de compra (PO) y bloqueos de pago.
- I_ChangeDocument: Para rastrear el timestamp exacto de los cambios, como el establecimiento o la eliminación de un bloqueo de pago.
- I_WorkflowStatusDetails: Para extraer eventos relacionados con el workflow de aprobación de facturas.
- I_PaymentProposalItem: Para identificar cuándo una factura se incluye en una propuesta de ejecución de pagos.
- I_Supplier: Para enriquecer los datos con datos maestros del proveedor, como VendorName.
- Filtrado por Rango de Fechas: Es fundamental aplicar un filtro de rango de fechas para limitar el volumen de datos. La consulta proporcionada filtra por CreationDateTime en la CTE Invoices_Base. Se recomienda un rango de 3 a 6 meses para un análisis inicial, lo que asegura un rendimiento manejable.
- Filtros Obligatorios: Siempre filtre por CompanyCode. Analizar datos de todos los CompanyCode a la vez puede ser extremadamente lento y puede no ser relevante para el negocio. Además, filtre por JournalEntryType para seleccionar solo documentos relacionados con proveedores (p. ej., 'KR', 'RE').
- Requisitos Previos: El usuario de base de datos que ejecuta la consulta debe tener autorización SELECT sobre todas las vistas CDS utilizadas en la consulta y sobre el esquema HANA subyacente. El acceso a nivel de aplicación en el SAP GUI no es suficiente.
- Consideraciones de Rendimiento: Las consultas directas sobre I_ChangeDocument pueden consumir muchos recursos. La consulta proporcionada intenta mitigar esto prefiltrando las facturas primero. Para conjuntos de datos muy grandes, considere ejecutar la extracción durante las horas de menor actividad o en lotes con rangos de fechas más pequeños.
a Consulta de ejemplo sql
`sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X';
`Pasos
- Especificación y Diseño: Antes de programar, colabore con los analistas de negocio para confirmar las condiciones exactas de activación y los campos de datos para cada una de las 15 actividades requeridas. Identifique las tablas SAP relevantes, los tipos de documento (p. ej., 'KR', 'RE') y las sociedades a incluir en el alcance.
- Crear Programa ABAP: Inicie el editor ABAP utilizando la transacción SE38. Cree un nuevo programa ejecutable, por ejemplo, Z_PM_AP_INVOICE_EXTRACT. Proporcione un título descriptivo y configure la aplicación en 'Contabilidad Financiera'.
- Definir Pantalla de Selección: Dentro del programa, defina una pantalla de selección (utilizando las palabras clave PARAMETERS y SELECT-OPTIONS) para permitir a los usuarios especificar el rango de fechas de extracción (para la fecha de creación de la factura), las sociedades objetivo (BUKRS) y los tipos de documento de factura relevantes (BLART). Incluya también un parámetro para la ruta del archivo de salida en el servidor de aplicaciones.
- Declaraciones de Datos: Defina una estructura de tabla interna que coincida con el formato del registro de eventos final (p. ej., TY_EVENT_LOG), incluyendo todos los atributos requeridos y recomendados. Declare tablas internas para almacenar datos seleccionados de varias tablas fuente de SAP como BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS y REGUH.
- Selección Principal de Datos: Inicie la lógica de extracción seleccionando el conjunto principal de facturas de RBKP (Facturas Logísticas) y BKPF (Facturas Financieras) basándose en los criterios de la pantalla de selección del usuario. Almacene estas claves de factura primarias en una tabla interna para impulsar búsquedas posteriores de datos.
- Extraer Actividades Secuencialmente: Para cada factura en el conjunto principal, realice una serie de selecciones para encontrar las marcas de tiempo y los detalles de cada actividad de negocio. Por ejemplo, consulte CDHDR y CDPOS para cambios en el bloqueo de pagos, consulte REGUH y REGUP para datos de ejecución de pagos, y consulte BKPF para detalles de documentos de anulación. Añada un nuevo registro a la tabla final del registro de eventos para cada actividad encontrada.
- Lógica para Eventos Calculados: Implemente la lógica ABAP para actividades que no se almacenan directamente en un campo de tabla. Para el evento 'Fecha de Vencimiento de Factura Superada', use la fecha de vencimiento de la factura (BSEG-ZFBDT + condiciones de pago) y la fecha de compensación (BSEG-AUGDT). Si la fecha de compensación es posterior a la fecha de vencimiento, cree un nuevo registro de evento con la marca de tiempo establecida en la fecha de vencimiento.
- Transformación y Enriquecimiento de Datos: A medida que recopila datos para cada actividad, rellene todos los atributos requeridos. Esto implica buscar nombres de proveedores en LFA1, convertir fechas y horas en una única cadena de marca de tiempo (CONCATENATE...INTO...), y establecer el valor de SourceSystem.
- Generar Archivo de Salida: Una vez que todas las facturas y sus actividades correspondientes han sido procesadas y recopiladas en la tabla interna final, utilice las sentencias OPEN DATASET, LOOP AT ... TRANSFER y CLOSE DATASET para escribir los datos en un archivo en la ruta del servidor de aplicaciones especificada en la pantalla de selección.
- Descargar y Preparar para Cargar: Utilice la transacción CG3Y para descargar el archivo generado desde el servidor de aplicaciones a su máquina local. Asegúrese de que el archivo se guarde en formato CSV codificado en UTF-8. Verifique que los encabezados de columna coincidan con los atributos requeridos (Invoice, ActivityName, EventTime, etc.) antes de cargar a la herramienta de Process Mining.
Configuración
- Rango de fechas: Defina la opción de selección P_CPUDT para la fecha de creación de la factura (BKPF-CPUDT o RBKP-CPUDT). Se recomienda un rango de 6 a 12 meses de datos para un análisis inicial.
- Código de Sociedad (P_BUKRS): Un parámetro SELECT-OPTIONS obligatorio para filtrar códigos de sociedad específicos. No se recomienda procesar todos los códigos de sociedad a la vez, a menos que sea absolutamente necesario.
- Tipo de Documento de Factura (P_BLART): Un parámetro SELECT-OPTIONS para filtrar tipos de documentos de factura relevantes. Los tipos comunes incluyen 'KR' (Factura de Proveedor), 'KG' (Nota de Crédito de Proveedor), 'RE' (Verificación de Factura Logística).
- Modo de Ejecución: El programa debe ejecutarse en segundo plano (SM36/SM37) para grandes volúmenes de datos y así evitar tiempos de espera en el proceso de diálogo en primer plano. Prográmelo para que se ejecute durante las horas de menor actividad.
- Ruta del Archivo de Salida: Un Parámetro para especificar la ruta y el nombre del archivo en el servidor de aplicaciones SAP (p. ej., en el directorio /tmp/). El archivo se escribe aquí antes de ser descargado.
- Requisitos Previos: El usuario que ejecuta el informe necesita autorización para leer de las tablas FI, CO y MM (BKPF, BSEG, RBKP, RSEG, LFA1), tablas de documentos de cambio (CDHDR, CDPOS), y tablas de workflow. Además, se requiere el objeto de autorización S_DATASET para escribir archivos en el servidor de aplicaciones.
a Consulta de ejemplo abap
`abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM.
`