Su Template de datos para el procesamiento de facturas de cuentas por pagar
Su Template de datos para el procesamiento de facturas de cuentas por pagar
- Atributos recomendados para un análisis completo
- Actividades clave del proceso que conviene registrar
- Instrucciones paso a paso para extraer los datos
Atributos del procesamiento de facturas de cuentas por pagar
| Nombre | Descripción | ||
|---|---|---|---|
| Actividad ActivityName | Nombre de un evento o paso de negocio específico que tuvo lugar durante el procesamiento de una factura. | ||
| Descripción La actividad representa una etapa o acción concreta del proceso de cuentas por pagar, como «Factura recibida», «Factura contabilizada» o «Pago ejecutado». Estas actividades son los componentes básicos del mapa del proceso. El análisis de las actividades es fundamental en Process Mining. Permite visualizar el flujo del proceso, identificar las rutas más habituales, detectar desviaciones respecto al proceso estándar y medir la frecuencia y duración de cada paso. La secuencia de actividades de una factura conforma su recorrido por el proceso. Por qué es importante Define los pasos del proceso y permite visualizar y analizar su flujo, identificar cuellos de botella y detectar ciclos de retrabajo. Dónde obtenerlo Se obtiene de diversas fuentes, como cambios en el estado del documento (por ejemplo, BKPF-BSTAT), documentos de modificación (tablas CDHDR/CDPOS) o registros del flujo de trabajo. Por lo general, requiere una lógica de extracción personalizada. Ejemplos Factura recibidaFactura aprobadaPago ejecutadoFactura bloqueada para el pago | |||
| Factura Invoice | Identificador único de un documento de factura, que sirve como ID principal del caso en el proceso de cuentas por pagar. | ||
| Descripción La factura es el objeto central que conecta todas las actividades relacionadas, desde su recepción hasta el pago. En SAP S/4HANA, suele identificarse mediante una clave compuesta por la sociedad (BUKRS), un número de documento único (BELNR) y el ejercicio fiscal (GJAHR). Analizar el proceso por factura permite obtener una visión completa de su ciclo de vida. Esto es fundamental para calcular métricas clave, como el tiempo de ciclo total, detectar cuellos de botella en facturas concretas y comprender las distintas rutas que puede seguir una factura durante el proceso. Por qué es importante Identifica de forma única el recorrido de cada factura y permite seguir todo su ciclo de vida y analizar el rendimiento del proceso caso por caso. Dónde obtenerlo Es una clave compuesta que se obtiene de las tablas BKPF (cabecera del documento contable) o RBKP (cabecera del documento: recepción de factura), mediante los campos BUKRS, BELNR y GJAHR. Ejemplos 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Hora del evento EventTime | Fecha y hora exactas en que tuvo lugar la actividad. | ||
| Descripción La hora del evento es la marca de tiempo asociada a cada actividad y establece la secuencia cronológica de los eventos de una factura. Estos datos son esenciales para comprender el flujo del proceso y realizar análisis basados en el tiempo. En el análisis, la hora del evento permite ordenar correctamente las actividades, calcular los tiempos de ciclo entre pasos, identificar los tiempos de espera y analizar el rendimiento del proceso en distintos periodos (por ejemplo, mes a mes). Es la base de todos los KPI relacionados con la duración. Por qué es importante Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos y calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo y las duraciones, esenciales para Process Mining. Dónde obtenerlo Se obtiene de distintos campos de fecha y hora de las tablas de SAP, como la fecha de creación (BKPF-CPUDT), la fecha de contabilización (BKPF-BUDAT), la fecha de compensación (BSAK-AUGDT) o las marcas de tiempo del registro de cambios (CDHDR-UDATE/UTIME). Ejemplos 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Sistema de origen SourceSystem | Sistema del que se extrajeron los datos. | ||
| Descripción Este atributo identifica el origen de los datos del proceso. En esta vista, el valor suele ser «SAP S/4HANA». En entornos con varios ERP o sistemas integrados, este campo es fundamental para el linaje y la segmentación de los datos. Garantiza que el análisis se realice sobre el conjunto de datos correcto y ayuda a diagnosticar problemas de calidad al rastrearlos hasta su origen. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos, la resolución de problemas y los entornos con varios sistemas. Dónde obtenerlo Por lo general, es un valor estático que se añade durante la extracción de datos para identificar el origen del conjunto de datos. Ejemplos SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen. | ||
| Descripción Este atributo proporciona la fecha y hora de la extracción o actualización más reciente de datos desde SAP S/4HANA. Es un campo de metadatos fundamental para conocer la actualidad de los datos analizados. Esta información permite saber qué tan recientes son los datos del análisis del proceso. Ayuda a gestionar las expectativas sobre la latencia de los datos y es esencial para programar las actualizaciones y mantener su integridad. Por qué es importante Indica la actualidad de los datos para que se sepa qué tan reciente es el análisis del proceso. Dónde obtenerlo Este valor se genera y se asigna a cada registro al extraer los datos del sistema de origen. Ejemplos 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Fecha de vencimiento de la factura InvoiceDueDate | Fecha límite para pagar la factura al proveedor. | ||
| Descripción La fecha de vencimiento de la factura es la fecha límite para pagar al proveedor y evitar recargos por demora y mantener una buena relación comercial. Se calcula a partir de la fecha base de la factura y las condiciones de pago acordadas con el proveedor. Esta fecha es esencial para el Dashboard «Cumplimiento y antigüedad de los pagos» y el KPI «Porcentaje de pagos puntuales». Al comparar la fecha de vencimiento con la fecha real de pago, el análisis revela si los pagos se realizan a tiempo, antes o después, con consecuencias financieras y para la relación con el proveedor. Por qué es importante Es el principal factor para analizar los pagos puntuales y permite medir el rendimiento de los pagos y su impacto en las relaciones con los proveedores y los recargos por demora. Dónde obtenerlo Esta fecha suele calcularse. La fecha neta de vencimiento 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 la factura InvoiceAmount | Importe bruto total de la factura en la moneda original del documento. | ||
| Descripción Es el valor total de la factura presentada por el proveedor. Incluye el coste de los bienes o servicios, los impuestos y cualquier otro cargo, antes de aplicar deducciones o descuentos. El importe de la factura es un atributo financiero clave para diversos análisis. Ayuda a priorizar las facturas de mayor importe, comprender el impacto financiero de las demoras del proceso (por ejemplo, los recargos por demora en facturas elevadas) y segmentar el proceso (por ejemplo, «¿Las facturas de mayor importe siguen una ruta de aprobación distinta?»). También es esencial para detectar posibles pagos duplicados. Por qué es importante Aporta contexto financiero al proceso y permite realizar análisis por valor, priorizar las facturas de mayor importe y cuantificar el impacto financiero. Dónde obtenerlo Se encuentra en tablas como RBKP-RMWWR (importe bruto de la factura) para las facturas MM, o se calcula a partir de las partidas de BSEG (campo WRBTR) para las facturas FI. Ejemplos 1500.00250.7512345.50 | |||
| Nombre de usuario UserName | ID de usuario de la persona que realizó la actividad. | ||
| Descripción Este atributo registra el ID de usuario de SAP responsable de realizar una actividad concreta, como contabilizar, aprobar o compensar una factura. Vincula los pasos del proceso con cada persona usuaria. Analizar por nombre de usuario es esencial para comprender la distribución de la carga de trabajo, identificar a quienes obtienen mejores resultados y detectar quiénes podrían necesitar formación adicional. También es clave para analizar los cuellos de botella en las aprobaciones mediante Dashboards, ya que permite identificar qué personas aprobadoras concretas están causando demoras. Por qué es importante Asocia las actividades con personas concretas y permite analizar el rendimiento y la carga de trabajo de cada usuario, así como el cumplimiento de las políticas de segregación de funciones. Dónde obtenerlo Suele encontrarse en tablas de cabecera, como BKPF-USNAM (introducido por), o en tablas de documentos de modificación, como CDHDR-USERNAME (modificado por). Ejemplos ABROWNJSMITHAP_AUTOMATION | |||
| Nombre del proveedor VendorName | Nombre del proveedor que presentó la factura. | ||
| Descripción Este atributo contiene el nombre oficial del proveedor. Está vinculado mediante el número de proveedor almacenado en el documento de factura. El análisis de proveedores es fundamental para gestionar las relaciones con ellos e identificar problemas del proceso relacionados con proveedores concretos. Permite responder preguntas como «¿Qué proveedores presentan más facturas con discrepancias?» o «¿Pagamos puntualmente y de forma sistemática a ciertos proveedores estratégicos?». Junto con el número y el importe de la factura, también es un campo clave para detectar posibles pagos duplicados. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, detectar proveedores problemáticos y gestionar eficazmente las relaciones estratégicas con ellos. Dónde obtenerlo Se obtiene de la tabla de datos maestros de proveedores LFA1 (campo NAME1), mediante el número de proveedor (LIFNR) de BKPF o RBKP. Ejemplos Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Número de orden de compra PurchaseOrderNumber | Identificador único de la orden de compra asociada a la factura, si corresponde. | ||
| Descripción Este atributo vincula una factura con una orden de compra (PO) aprobada previamente. La presencia del número de orden de compra es la base de la conciliación tripartita (orden de compra, factura y recepción de mercancías). Este atributo es fundamental para analizar el cumplimiento y la eficiencia. Se utiliza para calcular el KPI «Porcentaje de facturas sin orden de compra», que mide el cumplimiento de las políticas de compras. También es esencial para el Dashboard «Rendimiento de la conciliación tripartita», que permite analizar la conciliación de las facturas asociadas a órdenes de compra. Por qué es importante Es fundamental para analizar la eficiencia de la conciliación tripartita y medir el cumplimiento de las políticas de compras mediante la identificación de facturas procesadas sin una orden de compra. Dónde obtenerlo Se encuentra en las tablas de partidas de factura, como RSEG-EBELN (para facturas MM) o BSEG-EBELN (para facturas FI). Ejemplos 45000012344500005678 | |||
| Sociedad CompanyCode | Unidad organizativa para la que se procesa la factura. | ||
| Descripción Una sociedad es la unidad organizativa más pequeña para la que se puede elaborar un conjunto completo e independiente de cuentas destinado a la presentación de informes externos. En el proceso de cuentas por pagar, representa la entidad jurídica que debe dinero al proveedor. Analizar por sociedad permite comparar el rendimiento del proceso entre distintas entidades jurídicas de la organización. Esto ayuda a identificar qué partes de la empresa siguen los procesos estándar y cuáles tienen mayor eficiencia, tiempos de ciclo más largos o más retrabajo. Por qué es importante Permite comparar el rendimiento del proceso entre distintas entidades jurídicas e identificar problemas y buenas prácticas específicos de cada región o unidad de negocio. Dónde obtenerlo Se encuentra en las tablas de cabecera del documento, principalmente en BKPF-BUKRS para las facturas FI y en RBKP-BUKRS para las facturas MM. Ejemplos 10001710US01DE01 | |||
| Automatizada IsAutomated | Indicador que señala si el sistema realizó la actividad automáticamente en lugar de una persona usuaria. | ||
| Descripción Este atributo booleano distingue las actividades iniciadas por personas de las ejecutadas por trabajos del sistema, flujos de trabajo o bots. Por ejemplo, una ejecución de pagos 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 grado de automatización del proceso de cuentas por pagar. Permite medir el éxito de las iniciativas de automatización, comparar la eficiencia de los pasos automatizados y manuales, e identificar nuevas oportunidades de automatización. Por qué es importante Ayuda a medir el grado de automatización del proceso, analizar su eficacia e identificar oportunidades para seguir mejorándolo. Dónde obtenerlo Se deduce del nombre de usuario (por ejemplo, ID de usuario del sistema como 'SAP_SYSTEM' o 'BATCHUSER') o de códigos de transacción específicos asociados a trabajos automatizados. Ejemplos truefalse | |||
| Condiciones de pago PaymentTerms | Condiciones acordadas con el proveedor para pagar una factura, que suelen incluir posibles descuentos. | ||
| Descripción Las condiciones de pago establecen las reglas para las fechas de vencimiento y los posibles descuentos por pronto pago. Por ejemplo, una condición como «Z001» podría corresponder a «Pago en un plazo de 30 días, con un descuento del 2 % si se paga en 10 días». Este atributo es la base del Dashboard «Tasa de descuentos por pronto pago aprovechados». Al analizar las condiciones de pago, es posible identificar todas las facturas que podían beneficiarse de un descuento. Comparar este dato con los descuentos aplicados permite detectar ahorros que se dejaron pasar y medir la eficiencia del proceso de pago. Por qué es importante Es fundamental para analizar las oportunidades de obtener descuentos por pronto pago, medir el rendimiento financiero del proceso de pago e identificar ahorros que se dejaron pasar. Dónde obtenerlo Se encuentra en las partidas de proveedores, en la tabla BSEG-ZTERM, o en la cabecera de la factura, en RBKP-ZTERM. Ejemplos Z0010001NT30 | |||
| Descuento aplicado DiscountTaken | Indicador booleano que señala si se aplicó correctamente un descuento por pronto pago. | ||
| Descripción Este atributo indica si se aplicó realmente un descuento por pronto pago al pagar la factura. Es un componente clave para medir la eficiencia financiera del proceso de cuentas por pagar. Este indicador es la base del KPI de tasa de descuentos por pronto pago aprovechados. Al filtrar las facturas que podían beneficiarse de un descuento según sus condiciones de pago y analizar este indicador, una empresa puede calcular con precisión cuánto dinero ahorró y cuántas oportunidades de ahorro dejó pasar. Así obtiene una medida clara y cuantificable del rendimiento de cuentas por pagar. Por qué es importante Mide directamente el éxito al aprovechar los descuentos por pronto pago disponibles, lo que repercute directamente en los resultados de la empresa. Dónde obtenerlo Se obtiene comprobando si el campo del importe del descuento (BSEG-SKNTO) es mayor que cero en el documento de pago. Ejemplos truefalse | |||
| Fecha de compensación ClearingDate | Fecha en que se realizó el pago y la factura se compensó en las partidas abiertas. | ||
| Descripción La fecha de compensación indica que la factura se ha liquidado financieramente. Es la fecha en que se produce la actividad «Pago compensado», que marca el último paso en la mayoría de los recorridos de factura completados correctamente. Esta fecha se utiliza para calcular la fecha real de pago y compararla con la fecha de vencimiento de la factura. Por eso, es fundamental para calcular el KPI de tasa de pagos puntuales y para cualquier análisis del rendimiento de los pagos. También marca el punto final para calcular el tiempo de ciclo de la factura de principio a fin. Por qué es importante Marca la liquidación final de una factura, sirve como punto final para calcular el tiempo de ciclo y es la base del análisis de pagos puntuales. Dónde obtenerlo 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 | Código de moneda del importe de la factura (por ejemplo, USD o EUR). | ||
| Descripción Este atributo especifica la moneda en la que se expresa el importe de la factura. Aporta un contexto esencial para interpretar cualquier valor financiero. En una organización multinacional, analizar las facturas sin tener en cuenta la moneda puede llevar a conclusiones erróneas. Este campo permite gestionar correctamente los datos financieros, ya sea convirtiendo todos los importes a una única moneda de presentación o segmentando el análisis por moneda para comprender la actividad financiera de cada región. Por qué es importante Aporta el contexto necesario para interpretar el importe de la factura y permite realizar análisis e informes financieros precisos, especialmente en organizaciones multinacionales. Dónde obtenerlo Se encuentra principalmente en las tablas de cabecera de documentos, en BKPF-WAERS o RBKP-WAERS. Ejemplos USDEURGBPJPY | |||
| Motivo del bloqueo BlockingReason | Motivo por el que se bloquea una factura para el pago, que indica una discrepancia. | ||
| Descripción Si una factura no supera una comprobación de validación durante la conciliación de tres vías u otros pasos de verificación, se bloquea para el pago. El motivo del bloqueo especifica la naturaleza del problema, como una discrepancia en la cantidad, una variación de precio o la falta de una entrada de mercancías. Este atributo es fundamental para el Dashboard «Análisis del retrabajo por discrepancias en facturas». Analizar la frecuencia de los distintos motivos de bloqueo ayuda a identificar las causas raíz de las ineficiencias del proceso. Por ejemplo, si «Variación de precio» es un motivo frecuente, podría indicar problemas con los datos maestros del sistema de compras. Por qué es importante Permite conocer directamente las causas raíz de las discrepancias en las facturas y del retrabajo, para orientar las iniciativas de mejora del proceso. Dónde obtenerlo Se almacena en tablas de partidas de factura como RSEG, en campos que comienzan por SPGR* (por ejemplo, SPGRP, SPGRQ, SPGRT). También puede encontrarse en RBKP_BLOCKED. Ejemplos Discrepancia de precioDiscrepancia de cantidadFalta la entrada de mercancías | |||
| Número de factura del proveedor VendorInvoiceNumber | Número de factura que el proveedor indica en su documento. | ||
| Descripción Es el número de referencia del sistema contable del proveedor, tal como aparece en la factura física o electrónica. Se introduce manualmente o se captura mediante OCR al recibir la factura. Este campo es muy importante para las operaciones y el análisis, en particular para el Dashboard «Posibles pagos duplicados de facturas». Un método habitual para detectar duplicados consiste en buscar varios documentos de factura internos que compartan el mismo nombre del proveedor, número de factura del proveedor e importe de factura. Es la principal referencia externa de una factura. Por qué es importante Es un campo clave para detectar posibles pagos duplicados y sirve como referencia externa principal al comunicarse con los proveedores. Dónde obtenerlo Se almacena en el campo «Referencia» de la cabecera del documento, normalmente en BKPF-XBLNR. Ejemplos INV-2023-9876733401120231015-001 | |||
| Pago atrasado IsLatePayment | Indicador booleano que señala si la factura se pagó después de la fecha de vencimiento. | ||
| Descripción Este atributo calculado es un indicador sencillo de verdadero o falso que señala si la factura se pagó después de su fecha de vencimiento oficial. Se obtiene comparando la fecha de compensación con la fecha de vencimiento de la factura. Este indicador simplifica el análisis en el Dashboard «Cumplimiento de pagos y antigüedad» y el cálculo del KPI de tasa de pagos puntuales. Permite filtrar y agregar datos fácilmente para contar los pagos atrasados, calcular el porcentaje de pagos puntuales e identificar proveedores o sociedades con una alta proporción de pagos atrasados. Por qué es importante Mide directamente el cumplimiento de las condiciones de pago, simplifica el cálculo del KPI de pagos puntuales y ayuda a identificar áreas con un bajo rendimiento en los pagos. Dónde obtenerlo Atributo calculado. La lógica es: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Ejemplos truefalse | |||
| Tipo de documento de factura InvoiceDocumentType | Clasificación del documento de factura que determina cómo se procesa en SAP. | ||
| Descripción El tipo de documento es un elemento clave de configuración en SAP que clasifica los documentos contables. Por ejemplo, «KR» suele utilizarse para las facturas de proveedores, «RE» para las facturas MM y «KG» para las notas de crédito de proveedores. Este tipo determina aspectos como el rango de números y los campos obligatorios. En el análisis del proceso, filtrar por tipo de documento permite comparar los flujos de trabajo de distintos tipos de factura. Por ejemplo, el proceso de aprobación de una nota de crédito puede diferir del de una factura estándar. Esto resulta útil para el Dashboard «Variantes de las rutas de aprobación de facturas». Por qué es importante Permite segmentar el proceso según cómo se gestionan los distintos tipos de factura y revela variaciones en las rutas de procesamiento y los tiempos de ciclo. Dónde obtenerlo Directamente de la tabla de cabecera del documento, campo BKPF-BLART. Ejemplos KRREKG | |||
Actividades del procesamiento de facturas de cuentas por pagar
| Actividad | Descripción | ||
|---|---|---|---|
| Factura anulada | El documento de factura se ha revertido, anulando así su efecto financiero. Es un estado final alternativo del proceso, que suele deberse a errores de registro o disputas con proveedores. | ||
| Por qué es importante El seguimiento de las anulaciones ayuda a identificar las causas de los fallos del proceso, como envíos duplicados o datos incorrectos en las facturas, que pueden señalar problemas en etapas anteriores. Dónde obtenerlo Se registra explícitamente cuando se crea un documento de reversión. La cabecera del documento original (BKPF) incluirá el número del documento de reversión (STBLG) y el motivo de la reversión. Capturar Identifique la fecha de contabilización del documento de reversión, vinculado en la cabecera del documento original (BKPF-STBLG). Tipo de evento explicit | |||
| Factura aprobada | La factura ha recibido todas las aprobaciones necesarias en el sistema de flujo de trabajo. A menudo, este es el último paso antes de contabilizar la factura o desbloquearla para el pago. | ||
| Por qué es importante Este hito clave marca el final del ciclo de aprobación. El tiempo transcurrido entre el envío y la aprobación es una métrica fundamental de eficiencia. Dónde obtenerlo Se registra en los logs de SAP Business Workflow como un paso de finalización o de aprobación definitiva. También puede deducirse de la eliminación de un bloqueo de pago después del envío. Capturar Extraiga los eventos de finalización del flujo de trabajo de los registros de SAP o identifique el evento final de «aprobación». Tipo de evento explicit | |||
| Factura bloqueada para el pago | El sistema ha bloqueado la factura, de forma automática o manual, e impide que se pague. Esto suele deberse a discrepancias en el precio o la cantidad, o a aprobaciones pendientes. | ||
| Por qué es importante Este es un indicador clave de problemas y retrabajo. Analizar los motivos y la duración de los bloqueos ayuda a identificar las causas de fondo de las demoras en los pagos y las ineficiencias del proceso. Dónde obtenerlo Este estado se registra explícitamente en el campo Clave de bloqueo de pago (ZLSPR) de la partida del proveedor en el documento contable (tabla BSEG). Capturar Se registra mediante documentos de modificación cuando se asigna un motivo de bloqueo al campo BSEG-ZLSPR. Tipo de evento explicit | |||
| Factura contabilizada | La factura se registra formalmente en el libro mayor y genera un pasivo financiero. Un documento aparcado pasa a ser un documento contabilizado, o bien se contabiliza directamente. | ||
| Por qué es importante Este es un hito financiero fundamental. Confirma la obligación de pago de la empresa y suele ser un requisito previo para programar el pago. Dónde obtenerlo Este evento se identifica mediante la fecha de contabilización (BUDAT) de la cabecera del documento (BKPF). En un documento contabilizado, el estado del documento (BKPF-BSTAT) está en blanco. Capturar Use la fecha de contabilización (BKPF-BUDAT) de los documentos que no estén aparcados (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 mediante una interfaz automatizada, como OCR/VIM. Por lo general, este evento se registra a partir de la fecha y hora de creación de la cabecera del documento contable. | ||
| Por qué es importante Como punto de partida del proceso, esta actividad es esencial para calcular el tiempo de ciclo integral de la factura y medir el rendimiento de todo el proceso de cuentas por pagar. Dónde obtenerlo Este evento se obtiene de la tabla de cabecera del documento contable (BKPF), a partir de la fecha de creación del documento (CPUDT) y la hora (CPUTM). Capturar Use la marca de tiempo de creación (BKPF-CPUDT, BKPF-CPUTM) del documento de factura. Tipo de evento explicit | |||
| Pago compensado | Esta actividad marca el cierre definitivo de la factura: el pago y la factura se compensan entre sí en el libro auxiliar. Esto indica que el proceso ha finalizado. | ||
| Por qué es importante Como punto final del proceso, esta actividad es esencial para calcular con precisión el tiempo de ciclo integral. Confirma que el pasivo está liquidado. Dónde obtenerlo Este evento explícito se registra cuando se completa el campo Fecha de compensación (AUGDT) en la partida del proveedor del documento de factura (tabla BSEG). Capturar Use la fecha de compensación (BSEG-AUGDT) de la partida de factura. Tipo de evento explicit | |||
| Pago ejecutado | Se ha efectuado el pago de la factura. Se registra cuando finaliza la ejecución de pagos y se crea y contabiliza un documento de pago. | ||
| Por qué es importante Esta actividad es fundamental para analizar el flujo de caja y medir el KPI «Porcentaje de pagos puntuales» al comparar esta fecha con la fecha de vencimiento de la factura. Dónde obtenerlo Se obtiene de la fecha de contabilización del documento de pago que compensa la factura. El número del documento de pago está vinculado en el campo del documento de compensación (AUGBL) de la partida de factura (BSEG). Capturar Identifique la fecha de contabilización (BUDAT) del documento de pago que compensa la partida de factura. Tipo de evento explicit | |||
| Discrepancia resuelta | Esta actividad indica que se investigó y resolvió un problema detectado anteriormente que probablemente había provocado un bloqueo del pago. Se registra cuando se elimina el bloqueo de pago de una factura. | ||
| Por qué es importante El seguimiento de este ciclo de retrabajo es fundamental para el Dashboard «Análisis del retrabajo por discrepancias en facturas». Permite cuantificar el tiempo y el esfuerzo dedicados a corregir errores. Dónde obtenerlo Se deduce de los documentos de modificación que muestran la eliminación de un bloqueo de pago. El registro de cambios del campo BSEG-ZLSPR es la fuente principal. Capturar Identifique los documentos de modificación de la tabla BSEG en los que el campo ZLSPR cambie de un valor a estar en blanco. Tipo de evento inferred | |||
| Factura aparcada | Representa una factura que se ha introducido en el sistema, pero aún no se ha contabilizado en el libro mayor. A menudo, se trata de un paso intencional para guardar un documento incompleto y procesarlo o aprobarlo más adelante. | ||
| Por qué es importante El seguimiento de las facturas aparcadas ayuda a detectar demoras antes de que comience el proceso formal de contabilización y puede revelar problemas de integridad de los datos o de validación inicial. Dónde obtenerlo Este estado se deduce del campo de estado del documento en la cabecera del documento contable (BKPF-BSTAT = 'V' para aparcado). El evento se produce cuando se asigna este estado. Capturar Identifique los documentos de modificación de la tabla BKPF en los que el campo BSTAT tenga el valor 'V' (Vor-erfasst/Pre-entered). Tipo de evento inferred | |||
| Factura enviada para aprobación | La factura se ha enviado a un flujo de trabajo para obtener las aprobaciones requeridas según las 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 «Tiempo medio de aprobación de facturas» y analizar los cuellos de botella en las aprobaciones. Dónde obtenerlo Puede obtenerse de los registros de SAP Business Workflow (tablas SWW*), que registran el inicio de una instancia de flujo de trabajo vinculada al objeto de factura (por ejemplo, BUS2081). Capturar Extraiga los eventos de inicio del flujo de trabajo de los registros de SAP (por ejemplo, de la tabla SWW_WIHEAD) vinculados al documento de factura. Tipo de evento explicit | |||
| Factura rechazada | Una persona aprobadora ha rechazado la factura durante el flujo de aprobación. Por lo general, esta acción devuelve la factura a quien la procesa para que la corrija o aclare. | ||
| Por qué es importante El seguimiento de los rechazos permite detectar ciclos de retrabajo en el proceso de aprobación y puede revelar problemas de cumplimiento de políticas o errores en la codificación de facturas. Dónde obtenerlo Se registra como un evento de resultado específico en los logs de SAP Business Workflow asociados a la factura. Capturar Extraiga de los registros de SAP los eventos de estado «rechazada» del flujo de trabajo. Tipo de evento explicit | |||
| Orden de compra conciliada | Esta actividad indica que la factura se ha conciliado correctamente con la orden de compra correspondiente. Es un paso fundamental en la conciliación tripartita de las facturas asociadas a compras. | ||
| Por qué es importante El análisis de esta actividad permite medir la eficiencia del proceso de conciliación y es fundamental para los KPI «Rendimiento de la conciliación tripartita» y «Porcentaje de facturas sin orden de compra». Dónde obtenerlo Se deduce cuando una partida de factura de la tabla BSEG o ACDOCA contiene un número de orden de compra (EBELN) y una posición (EBELP) válidos. Capturar Se deduce de la presencia de una referencia a una orden de compra (BSEG-EBELN) en el documento de factura al crearlo. Tipo de evento inferred | |||
| Propuesta de pago creada | La factura se ha incluido en una propuesta de pago como parte de una ejecución de pagos (por ejemplo, F110). Queda programada para el pago, a la espera de que finalice la ejecución. | ||
| Por qué es importante Esta actividad muestra el paso de un pasivo pendiente a una partida en preparación activa para el pago, lo que permite analizar la eficiencia de las operaciones de pago. Dónde obtenerlo Este evento se registra explícitamente en las tablas de datos de ejecución de pagos, en concreto REGUP (partidas procesadas por el programa de pagos) y REGUH (cabecera). Capturar Identifique cuándo aparece una factura en la tabla REGUP para una ejecución de pagos identificada en REGUH. Tipo de evento explicit | |||
| Recepción de mercancías conciliada | Esta actividad indica que las cantidades y los importes de la factura se han conciliado correctamente con el documento de recepción de mercancías correspondiente. Es la validación final de una conciliación tripartita. | ||
| Por qué es importante El seguimiento de esta actividad permite detectar ineficiencias en la conciliación tripartita e identificar discrepancias entre las mercancías recibidas y las facturadas por el proveedor. Dónde obtenerlo Se deduce de la presencia de una referencia al documento de material (recepción de mercancías) en la partida de factura, a menudo vinculada mediante el historial de posiciones de la orden de compra. Capturar Se deduce de la presencia de una referencia al documento de recepción de mercancías en la partida de factura (por ejemplo, en RSEG para las facturas MIRO). Tipo de evento inferred | |||
| Vencimiento de la factura superado | Evento calculado que indica que ha pasado la fecha neta de vencimiento de la factura sin que se haya compensado ningún pago. Esto significa que el pago está retrasado o vencido. | ||
| Por qué es importante Esta actividad es esencial para el Dashboard «Cumplimiento y antigüedad de los pagos»: ayuda a identificar y gestionar de forma proactiva las facturas vencidas y a analizar las causas de fondo de los retrasos. Dónde obtenerlo No es un evento explícito de SAP. Se calcula comparando la fecha actual del sistema con la fecha neta de vencimiento (calculada a partir de BSEG-ZFBDT o de la fecha base y las condiciones de pago). Capturar Evento calculado que se activa cuando la marca de tiempo del evento es posterior a la fecha neta de vencimiento de la factura. Tipo de evento calculated | |||
Guías de extracción
Pasos
- Requisitos previos y acceso: Asegúrese de contar con un usuario que tenga acceso de lectura al esquema de la base de datos de SAP S/4HANA (normalmente SAPABAP1 o similar) donde se encuentran las vistas CDS. Necesitará una herramienta cliente SQL que pueda conectarse a la base de datos SAP HANA, como SAP HANA Studio, DBeaver u otra herramienta de consulta de bases de datos.
- 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 la extracción. Para ello, establezca el identificador correcto del sistema de origen, el intervalo de fechas de las facturas (CreationDateTime) y los códigos de sociedad pertinentes.
- Prepare la consulta principal: Copie en su cliente SQL la consulta SQL completa que aparece en la sección correspondiente. La consulta utiliza expresiones de tabla comunes (CTE) para seleccionar primero un conjunto base de facturas y, después, crear un registro de eventos que reúne datos de 15 actividades distintas.
- Configure los parámetros de la consulta: Localice las variables de marcador de posición en la consulta SQL copiada. Sustituya '[YYYY-MM-DD]' por las fechas de inicio y fin del período de análisis. Sustituya '[Your Company Code 1]' y '[Your Company Code 2]' por la lista de códigos de sociedad de SAP que desea analizar.
- Ejecute la consulta de extracción: Ejecute la consulta SQL completa. Según el volumen de datos y el intervalo de fechas seleccionado, el proceso puede tardar desde varios minutos hasta varias horas.
- Revise los resultados preliminares: Cuando termine la consulta, revise las primeras centenas de filas del resultado. Compruebe la coherencia de los datos, confirme que todas las columnas estén completas según lo previsto y verifique que haya distintos valores de ActivityName.
- Exporte el registro de eventos: Exporte todo el conjunto de resultados desde su cliente SQL a un archivo CSV. Asegúrese de que el archivo esté codificado en UTF-8 para evitar problemas con los caracteres. Asígnele un nombre descriptivo, por ejemplo, sap_s4hana_ap_event_log.csv.
- Prepare la carga: Antes de cargar los datos en una herramienta de Process Mining, confirme que los encabezados de columna del archivo CSV coincidan exactamente con los nombres de atributos requeridos: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Cargue los datos en la herramienta de Process Mining: Cargue el archivo CSV generado en su plataforma de Process Mining y asigne las columnas correspondientes a los campos de ID del caso, actividad y marca de tiempo.
Configuración
- Vistas CDS clave: La extracción se basa en una combinación de vistas CDS estándar de S/4HANA. Las principales son:
- I_JournalEntry e I_JournalEntryItem: para los encabezados de documentos financieros, las partidas, los datos de contabilización y la información de compensación.
- I_SupplierInvoiceAPI01: para los detalles específicos de las facturas MM (Logistics), incluidas las referencias a pedidos de compra y los bloqueos de pago.
- I_ChangeDocument: para registrar la marca de tiempo exacta de los cambios, como la aplicación o eliminación de un bloqueo de pago.
- I_WorkflowStatusDetails: para extraer eventos relacionados con el flujo de trabajo de aprobación de facturas.
- I_PaymentProposalItem: para identificar cuándo se incluye una factura en una propuesta de ejecución de pagos.
- I_Supplier: para enriquecer los datos con información maestra de proveedores, como VendorName.
- Filtro por intervalo de fechas: Es fundamental aplicar un filtro de fechas para limitar el volumen de datos. La consulta proporcionada filtra por CreationDateTime en la CTE Invoices_Base. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses, a fin de mantener un rendimiento adecuado.
- Filtros obligatorios: Filtre siempre por CompanyCode. Analizar de una vez los datos de todos los códigos de sociedad puede ser muy lento y quizá no resulte útil para el negocio. Filtre también por JournalEntryType para seleccionar solo documentos relacionados con proveedores (por ejemplo, 'KR' y 'RE').
- Requisitos previos: El usuario de base de datos que ejecute la consulta debe tener autorización SELECT para todas las vistas CDS utilizadas y para el esquema HANA subyacente. El acceso a nivel de aplicación en SAP GUI no es suficiente.
- Consideraciones de rendimiento: Las consultas directas a I_ChangeDocument pueden consumir muchos recursos. La consulta proporcionada intenta reducir ese impacto filtrando primero las facturas. Para conjuntos de datos muy grandes, considere ejecutar la extracción fuera de las horas de mayor actividad o en lotes con intervalos de fechas más pequeños.
Consulta de ejemplo 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
- Confirme que dispone de acceso de lectura directo al esquema SAP HANA que contiene las tablas pertinentes de SAP S/4HANA. Obtenga la cadena de conexión, las credenciales, el nombre del esquema y las autorizaciones necesarias para leer BKPF, ACDOCA y cualquier otra tabla configurada para documentos preliminares, flujo de trabajo, compras, recepción de mercancías, propuestas de pago, compensaciones y anulaciones.
- Confirme el modelo técnico de datos del sistema de destino antes de ejecutar la consulta. Valide los nombres físicos, los campos clave y de marca de tiempo, las relaciones de anulación y pago, y la persistencia del flujo de trabajo que utiliza el sistema. Sustituya cada marcador de posición entre corchetes por el objeto o campo correspondiente del sistema. No dé por sentado que los datos del flujo de trabajo o de los documentos preliminares se almacenan en una única tabla universal.
- Configure los parámetros de extracción. Defina [Start date], [End date], [Company code filter], [Document type filter] y [Schema name]. Comience con un intervalo de tres a seis meses y amplíelo una vez validados el rendimiento y la integridad de los datos.
- Ejecute la consulta SQL en un cliente SQL de SAP HANA autorizado, como SAP HANA Database Explorer u otra herramienta de ejecución SQL aprobada. La consulta genera una fila por cada actividad extraída explícitamente y no depende de que ProcessMind infiera eventos.
- Valide el conjunto de resultados. Confirme que Invoice sea el identificador del caso, que ActivityName incluya los 15 nombres de actividad requeridos, que EventTime esté completo y presente una secuencia cronológica plausible, que SourceSystem identifique SAP S/4HANA y que LastDataUpdate contenga la marca de tiempo de actualización de la extracción. Revise los eventos duplicados, las relaciones de anulación y las uniones entre documentos antes de cargar los datos.
- Aplique las asignaciones específicas que requiera el sistema. Por ejemplo, asigne el origen configurado de documentos preliminares a Invoice Parked; el origen del flujo de trabajo configurado a Invoice Routed For Approval, Invoice Approved e Invoice Rejected; y el origen de pagos configurado a Payment Proposal Created y Payment Executed. Si necesita trazabilidad para auditorías, conserve los identificadores de origen en columnas adicionales.
- Exporte el resultado como archivo delimitado o conjunto de resultados de base de datos, con un evento por fila. Utilice codificación UTF-8, mantenga las marcas de tiempo en una zona horaria uniforme, conserve exactamente los nombres de columna Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber e InvoiceDueDate, y no agrupe las actividades por factura.
- Cargue el registro de eventos en ProcessMind y configure Invoice como identificador del caso, ActivityName como columna de actividad y EventTime como columna de hora del evento. Compruebe que los atributos opcionales estén asignados a los campos correspondientes. Como ProcessMind lee el registro de eventos tal como está, asegúrese de que cada actividad que quiera visualizar ya figure en una fila antes de cargar los datos.
Configuración
- Intervalo de fechas: Comience con un período de tres a seis meses. Según la actividad que extraiga, utilice la fecha de contabilización, la fecha de creación del documento o la fecha del evento de origen correspondiente. Amplíe el intervalo solo después de validar el tiempo de ejecución de la consulta y el período de retención del sistema de origen.
- Filtro por sociedad: Configure [Company code filter] para limitar la extracción a los códigos de sociedad necesarios. Si no necesita limitarla, utilice una selección controlada de todas las sociedades en lugar de ejecutar una consulta de producción sin restricciones.
- Filtro por tipo de documento: Configure [Document type filter] solo después de confirmar qué tipos de documento se utilizan para facturas de proveedores, notas de crédito, documentos preliminares, documentos de pago y anulaciones en el sistema de destino.
- Asignación de esquemas y objetos: Sustituya [Schema name] y cada objeto o campo de origen entre corchetes por valores verificados en el sistema SAP S/4HANA de destino. Una consulta directa a HANA debe adaptarse a las aplicaciones activadas, las extensiones, el diseño del flujo de trabajo y el modelo de datos del sistema.
- Gestión de marcas de tiempo: Normalice todas las marcas de tiempo de origen a una misma zona horaria. Si solo dispone de una fecha, utilice un componente de hora predeterminado y documentado, y registre esta limitación en el diccionario de datos.
- Semántica de los eventos: Extraiga cada actividad como una fila independiente. No agrupe varias actividades en un solo registro de factura ni espere que ProcessMind derive eventos de conciliación, aprobación, vencimiento o compensación.
- Evento de vencimiento: Genere Invoice Due Date Passed solo para las facturas cuya fecha de vencimiento sea anterior a la marca de tiempo de evaluación configurada y que no tengan un evento de compensación hasta ese momento. La consulta utiliza [Evaluation timestamp] para este cálculo.
- Rendimiento: Limite el período inicial y el alcance de sociedades, filtre por campos indexados o relevantes para la partición, evite seleccionar columnas innecesarias y ejecute la consulta durante una ventana de generación de informes aprobada. Si la consulta de producción supera el tiempo de ejecución acordado, considere preparar subconjuntos de datos de origen.
- Estrategia de actualización: Asigne a LastDataUpdate la marca de tiempo de ejecución de la extracción. Para las cargas incrementales, conserve un punto de control basado en la marca de tiempo de cambio pertinente del origen e incluya un período de revisión retrospectiva para captar actualizaciones tardías y anulaciones.
- Requisitos previos: Autorizaciones de base de datos necesarias, acceso aprobado al entorno de producción, conocimiento de la configuración del Universal Journal del sistema, acceso a los orígenes configurados de documentos preliminares, compras, recepción de mercancías, flujo de trabajo, pagos, compensaciones y anulaciones, y las aprobaciones de licencias de SAP o de gobernanza que correspondan.
Consulta de ejemplo sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Pasos
- Especificación y diseño: Antes de programar, colabore con los analistas de negocio para confirmar las condiciones exactas que activan cada una de las 15 actividades requeridas y sus campos de datos. Identifique las tablas SAP pertinentes, los tipos de documento (por ejemplo, 'KR' y 'RE') y los códigos de sociedad que se incluirán en el alcance.
- Cree el programa ABAP: Abra el editor ABAP mediante el código de transacción SE38. Cree un programa ejecutable nuevo, por ejemplo, Z_PM_AP_INVOICE_EXTRACT. Asígnele un título descriptivo y establezca la aplicación como 'Financial Accounting'.
- Defina la pantalla de selección: En el programa, defina una pantalla de selección (con las palabras clave PARAMETERS y SELECT-OPTIONS) para que los usuarios puedan especificar el intervalo de fechas de extracción (para la fecha de creación de la factura), los códigos de sociedad de destino (BUKRS) y los tipos de documento de factura pertinentes (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 final del registro de eventos (por ejemplo, TY_EVENT_LOG) e incluya todos los atributos obligatorios y recomendados. Declare tablas internas para almacenar los datos seleccionados de distintas tablas de origen 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) según los criterios de la pantalla de selección. Guarde las claves de estas facturas en una tabla interna para utilizarlas en las búsquedas posteriores.
- Extraiga las actividades en secuencia: Para cada factura del 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 detectar cambios en los bloqueos de pago, REGUH y REGUP para obtener datos de las ejecuciones de pago, y BKPF para consultar los detalles de los documentos de anulación. Añada un registro a la tabla final del registro de eventos por cada actividad encontrada.
- Lógica para los eventos calculados: Implemente lógica ABAP para las actividades que no se almacenan directamente en un campo de tabla. Para el evento 'Invoice Due Date Passed', utilice 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 recopile los datos de cada actividad, complete todos los atributos requeridos. Para ello, consulte los nombres de proveedores en LFA1, convierta las fechas y horas en una sola cadena de marca de tiempo (CONCATENATE...INTO...) y establezca el valor de SourceSystem.
- Genere el archivo de salida: Una vez procesadas todas las facturas y recopiladas sus actividades correspondientes en la tabla interna final, utilice las instrucciones 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.
- Descargue el archivo y prepárelo para cargarlo: Utilice el código de transacción CG3Y para descargar el archivo generado del servidor de aplicaciones a su equipo local. Asegúrese de guardarlo como archivo CSV codificado en UTF-8. Antes de cargarlo en la herramienta de Process Mining, compruebe que los encabezados de columna coincidan con los atributos requeridos (Invoice, ActivityName, EventTime, etc.).
Configuración
- Intervalo 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). Para el análisis inicial, se recomienda utilizar entre 6 y 12 meses de datos.
- Código de sociedad (P_BUKRS): 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, salvo que sea imprescindible.
- Tipo de documento de factura (P_BLART): Parámetro SELECT-OPTIONS para filtrar los tipos de documento de factura pertinentes. Entre los tipos habituales se encuentran 'KR' (factura de proveedor), 'KG' (nota de crédito de proveedor) y 'RE' (verificación de facturas logísticas).
- Modo de ejecución: Para procesar grandes volúmenes de datos, ejecute el programa como tarea en segundo plano (SM36/SM37) y evite los tiempos de espera en el proceso de diálogo en primer plano. Prográmelo para que se ejecute fuera de las horas de mayor actividad.
- Ruta del archivo de salida: Parámetro para especificar la ruta y el nombre del archivo en el servidor de aplicaciones SAP (por ejemplo, en el directorio /tmp/). El archivo se escribe allí antes de descargarlo.
- Requisitos previos: El usuario que ejecute el informe necesita autorización para leer las tablas FI, CO y MM (BKPF, BSEG, RBKP, RSEG, LFA1), las tablas de cambios en documentos (CDHDR, CDPOS) y las tablas del flujo de trabajo. También se requiere el objeto de autorización S_DATASET para escribir archivos en el servidor de aplicaciones.
Consulta de ejemplo 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. ¿Listo para comenzar?
Aproveche esta plantilla para poner en marcha su iniciativa de Process Mining y lograr mejoras importantes en las operaciones de cuentas por pagar. Comience hoy mismo a optimizar y agilizar el proceso.
Evite recargos por demora: optimice hoy el procesamiento de facturas de cuentas por pagar
Reduzca un 60 % los costes de procesamiento y elimine fácilmente los pagos duplicados.
No se requiere tarjeta de crédito. Comience en unos minutos.