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 debe supervisar eficazmente
- Guía 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 empresarial específico que tuvo lugar durante el ciclo de vida del procesamiento de una factura. | ||
| Descripción La actividad representa una etapa o acción diferenciada dentro del proceso de Cuentas por pagar, como «Factura recibida», «Factura contabilizada» o «Pago ejecutado». Estos son los elementos básicos del mapa de procesos. Analizar las actividades es fundamental en Process Mining. Ayuda a visualizar el flujo del proceso, identificar las rutas habituales, detectar desviaciones respecto al proceso estándar y medir la frecuencia y duración de cada paso. La secuencia de estas actividades para una factura determinada forma su recorrido dentro del 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 deriva de diversas fuentes, incluidos los cambios de estado de los documentos, por ejemplo, BKPF-BSTAT, los documentos de modificación, tablas CDHDR/CDPOS, o los registros de Workflow. Normalmente requiere una lógica de extracción personalizada. Ejemplos Factura recibidaFactura aprobadaPago ejecutadoFactura bloqueada para pago | |||
| Factura Invoice | Identificador único de un documento de factura, que actúa como ID de caso principal del 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, normalmente se trata de una clave compuesta formada por el código de sociedad (BUKRS), un número de documento único (BELNR) y el ejercicio fiscal (GJAHR). Analizar por factura permite obtener una visión completa de su ciclo de vida de extremo a extremo. Esto es fundamental para calcular métricas clave, como el tiempo de ciclo total, identificar cuellos de botella en facturas individuales 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, lo que permite rastrear su ciclo de vida completo y analizar el rendimiento del proceso caso por caso. Dónde obtenerlo Es una clave compuesta derivada 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 las que tuvo lugar la actividad. | ||
| Descripción La hora del evento es la marca de tiempo asociada a cada actividad y proporciona la secuencia cronológica de eventos de 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, la hora del evento se utiliza para ordenar correctamente las actividades, calcular los tiempos de ciclo entre distintos pasos, identificar los tiempos de espera y analizar el rendimiento del proceso en diferentes periodos, por ejemplo, mes a mes. Es la base de todos los KPI basados en duraciones. 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 en Process Mining. Dónde obtenerlo Se obtiene de diversos 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 normalmente será «SAP S/4HANA». En entornos con varios ERP o sistemas integrados, este campo es fundamental para la trazabilidad y la segregación de los datos. Garantiza que el análisis se realice sobre el conjunto de datos correcto y ayuda a diagnosticar problemas de calidad rastreándolos 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 Normalmente es un valor estático que se añade durante la extracción de datos para etiquetar 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 comprender la actualidad de los datos analizados. Esta información ayuda a saber hasta qué punto está actualizado el análisis del proceso. También permite gestionar las expectativas sobre la latencia de los datos y resulta esencial para programar las actualizaciones y mantener la integridad de los datos. Por qué es importante Indica la actualidad de los datos y permite saber hasta qué punto está actualizado el análisis del proceso. Dónde obtenerlo Este valor se genera y se registra en cada registro en el momento de extraer los datos del sistema de origen. Ejemplos 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Código de sociedad CompanyCode | Unidad organizativa para la que se procesa la factura. | ||
| Descripción Un código de sociedad es la unidad organizativa más pequeña para la que puede elaborarse un conjunto completo e independiente de cuentas destinado a la presentación de información externa. En el contexto de Cuentas por pagar, representa la entidad jurídica que debe dinero al proveedor. Analizar por código de 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 presentan mayor eficiencia, tiempos de ciclo más largos o tasas de retrabajo más elevadas. Por qué es importante Permite comparar el rendimiento del proceso entre distintas entidades jurídicas y ayuda a identificar problemas y buenas prácticas específicos de una región o unidad de negocio. Dónde obtenerlo Se encuentra en las tablas de cabecera de documentos, principalmente en BKPF-BUKRS para facturas FI y RBKP-BUKRS para facturas MM. Ejemplos 10001710US01DE01 | |||
| Fecha de vencimiento de la factura InvoiceDueDate | Fecha límite en la que debe pagarse la factura al proveedor. | ||
| Descripción La fecha de vencimiento de la factura es el plazo límite para pagar al proveedor, evitar recargos por demora y mantener una buena relación con él. 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 de pagos y antigüedad» y el KPI «Porcentaje de pagos puntuales». Al comparar la fecha de vencimiento con la fecha real de pago, el análisis puede mostrar si los pagos se realizan a tiempo, antes o después de la fecha prevista, con consecuencias financieras y relacionales directas. 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 de 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 fundamental para numerosos análisis. Ayuda a priorizar las facturas de mayor valor, comprender el impacto financiero de los retrasos del proceso, por ejemplo, los recargos por demora en facturas de importes elevados, y segmentar el proceso, por ejemplo, «¿Las facturas de mayor valor siguen una ruta de aprobación diferente?». También es esencial para identificar posibles pagos duplicados. Por qué es importante Aporta contexto financiero al proceso y permite realizar análisis basados en el valor, priorizar facturas de importes elevados y cuantificar los impactos financieros. Dónde obtenerlo Se encuentra en tablas como RBKP-RMWWR (importe bruto de la factura) para facturas MM o se calcula a partir de las posiciones de BSEG, campo WRBTR, para 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 ejecutar una actividad concreta, como contabilizar, aprobar o compensar una factura. Vincula los pasos del proceso con usuarios individuales. Analizar por nombre de usuario es esencial para comprender la distribución de la carga de trabajo, identificar a los usuarios con mejor rendimiento y detectar a quienes podrían necesitar formación adicional. También es clave para analizar los cuellos de botella de aprobación en los Dashboards, ya que ayuda a identificar qué aprobadores concretos están provocando retrasos en el proceso. Por qué es importante Asigna las actividades a personas concretas, lo que permite analizar el rendimiento y la carga de trabajo de los usuarios, así como el cumplimiento de las políticas de segregación de funciones. Dónde obtenerlo Normalmente se encuentra 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. Analizar a los proveedores es fundamental para gestionar las relaciones con ellos e identificar problemas del proceso específicos de determinados proveedores. Puede ayudar a responder preguntas como «¿Qué proveedores presentan más facturas con discrepancias?» o «¿Pagamos puntualmente de forma constante a determinados proveedores estratégicos?». También es un campo clave, junto con el número y el importe de la factura, para detectar posibles pagos duplicados. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, identificar 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 un vínculo con el número de proveedor (LIFNR) encontrado en BKPF o RBKP. Ejemplos Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Número de Purchase Order PurchaseOrderNumber | Identificador único del pedido de compra asociado a la factura, si corresponde. | ||
| Descripción Este atributo vincula una factura con un pedido de compra (PO) aprobado previamente. La presencia de un número de PO es la base del proceso de conciliación a tres bandas (PO-factura-Goods Receipt). Es un atributo esencial para analizar el cumplimiento y la eficiencia. Se utiliza para calcular el KPI «Porcentaje de facturas sin pedido de compra», que mide el cumplimiento de las políticas de compras. También es fundamental para el Dashboard «Rendimiento de la conciliación a tres bandas», ya que permite analizar el proceso de conciliación de las facturas asociadas a un PO. Por qué es importante Es fundamental para analizar la eficiencia de la conciliación a tres bandas y medir el cumplimiento de las políticas de compras mediante la identificación de facturas procesadas sin PO. Dónde obtenerlo Se encuentra en las tablas de posiciones de factura, como RSEG-EBELN para facturas MM o BSEG-EBELN para facturas FI. Ejemplos 45000012344500005678 | |||
| ¿Es un pago atrasado? IsLatePayment | Indicador booleano que señala si la factura se pagó después de su fecha de vencimiento. | ||
| Descripción Este Atributo calculado es un indicador sencillo de verdadero/falso que señala si una factura se pagó después de su fecha de vencimiento oficial. Se obtiene comparando la «Clearing Date» con la «Invoice Due Date». Este indicador simplifica el análisis del Dashboard «Payment Compliance & Aging» y del KPI «On-Time Payment Rate». Permite filtrar y agregar fácilmente los datos para contar los pagos atrasados, calcular el porcentaje de pagos puntuales e identificar proveedores o códigos de empresa con tasas elevadas 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 rendimiento deficiente en los pagos. Dónde obtenerlo Atributo calculado. La lógica es: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Ejemplos truefalse | |||
| Condiciones de pago PaymentTerms | Condiciones acordadas con el proveedor para pagar una factura, que a menudo incluyen 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, 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 aprovechamiento de descuentos por pronto pago». Analizar las condiciones de pago permite identificar todas las facturas que podían beneficiarse de un descuento. Compararlas con los descuentos aplicados revela oportunidades de ahorro desaprovechadas y mide la eficiencia del proceso de pago. Por qué es importante Es esencial para analizar las oportunidades de descuento por pronto pago, medir el rendimiento financiero del proceso de pago e identificar ahorros desaprovechados. Dónde obtenerlo Se encuentra en las posiciones del proveedor, 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 fundamental para medir la eficiencia financiera del proceso de Cuentas por pagar. Este indicador constituye la base del KPI «Early Payment Discount Capture Rate». Al filtrar las facturas en las que era posible aplicar un descuento, según las condiciones de pago, y analizar después este indicador, una empresa puede calcular con precisión cuánto dinero 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 el aprovechamiento de 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 superior a cero en el documento de pago. Ejemplos truefalse | |||
| Es automática 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 entre las actividades iniciadas por una persona y las ejecutadas por trabajos del sistema, Workflows o bots. Por ejemplo, una ejecución automática de pagos o una contabilización de facturas generada por el sistema se marcaría como automática. Analizar este atributo ayuda a comprender el nivel de automatización del proceso de Cuentas por pagar. Puede utilizarse para medir el éxito de las iniciativas de automatización, comparar la eficiencia de los pasos automáticos y manuales e identificar nuevas oportunidades de automatización. Por qué es importante Ayuda a medir el grado de automatización del proceso, analizar la eficacia de la automatización e identificar oportunidades de mejora adicionales. Dónde obtenerlo Se deriva del nombre de usuario, por ejemplo, de ID de usuario del sistema como «SAP_SYSTEM» o «BATCHUSER», o de códigos de transacción específicos asociados a trabajos automáticos. Ejemplos truefalse | |||
| Fecha de compensación ClearingDate | La fecha en la que se realizó el pago y la factura se compensó de las partidas abiertas. | ||
| Descripción La fecha de compensación indica la liquidación financiera de la factura. Es la fecha en la que se produce la actividad «Payment Cleared», que marca el último paso de la mayoría de los recorridos de factura completados correctamente. Esta fecha se utiliza para calcular la fecha de pago real y compararla con la fecha de vencimiento de la factura. Por ello, es esencial para calcular el KPI «On-Time Payment Rate» y para cualquier análisis relacionado con el rendimiento de los pagos. También marca el punto final para calcular el tiempo de ciclo completo de la factura. Por qué es importante Marca la liquidación final de una factura, sirve como punto final para calcular el tiempo de ciclo y constituye 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 | El 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. Proporciona el contexto necesario para interpretar cualquier valor financiero. En una organización multinacional, analizar las facturas sin tener en cuenta su moneda puede inducir a error. 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 regional. Por qué es importante Proporciona el contexto necesario para interpretar el importe de la factura y permite realizar análisis e informes financieros precisos, especialmente en entornos multinacionales. Dónde obtenerlo Se encuentra en las tablas de cabecera de documentos, principalmente BKPF-WAERS o RBKP-WAERS. Ejemplos USDEURGBPJPY | |||
| Motivo del bloqueo BlockingReason | Motivo por el que una factura está bloqueada para el pago, lo que indica una discrepancia. | ||
| Descripción Cuando una factura no supera una validación durante la conciliación a tres bandas u otros pasos de verificación, se bloquea para el pago. El motivo del bloqueo especifica la naturaleza del problema, como una discrepancia de cantidad, una variación de precio o la falta de un Goods Receipt. Este atributo es fundamental para el Dashboard «Análisis del retrabajo por discrepancias de 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 la «Variación de precio» es un motivo frecuente, puede señalar problemas con los datos maestros del sistema de compras. Por qué es importante Proporciona información directa sobre las causas raíz de las discrepancias y el retrabajo de las facturas, lo que permite orientar las iniciativas de mejora del proceso. Dónde obtenerlo Se almacena en tablas de posiciones de factura como RSEG, en campos que comienzan por SPGR*, por ejemplo, SPGRP, SPGRQ y SPGRT. También puede encontrarse en RBKP_BLOCKED. Ejemplos Discrepancia de precioDiscrepancia de cantidadFalta el recibo de mercancías | |||
| Número de factura del proveedor VendorInvoiceNumber | El número de factura que el proveedor indica en su documento. | ||
| Descripción Es el número de referencia del sistema contable del propio proveedor, tal como aparece impreso 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, especialmente para el Dashboard «Potential Duplicate Invoice Payments». Un método habitual para detectar duplicidades 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 para comunicarse con los proveedores. Dónde obtenerlo Se almacena en el campo «Reference» de la cabecera del documento, normalmente BKPF-XBLNR. Ejemplos INV-2023-9876733401120231015-001 | |||
| Tipo de documento de factura InvoiceDocumentType | Clasificación del documento de factura que controla cómo se procesa en SAP. | ||
| Descripción El tipo de documento es un elemento de configuración clave en SAP que categoriza los documentos contables. Por ejemplo, «KR» suele utilizarse para facturas de proveedores, «RE» para facturas MM y «KG» para abonos de proveedores. Este tipo determina aspectos como el rango de numeración y los campos obligatorios. En el análisis del proceso, filtrar por tipo de documento permite comparar los flujos de proceso de distintos tipos de factura. Por ejemplo, el proceso de aprobación de un abono puede ser diferente del de una factura estándar. Esto resulta útil para el Dashboard «Variantes de la ruta de aprobación de facturas». Por qué es importante Permite segmentar el proceso según la forma en que 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 aprobada | La factura ha recibido todas las aprobaciones necesarias dentro del sistema de Workflow. 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 crítica de eficiencia. Dónde obtenerlo Se captura en los registros de SAP Business Workflow como un paso de finalización o liberación final. Como alternativa, puede inferirse a partir de la eliminación de un bloqueo de pago después del envío. Recopilar Extraiga los eventos de finalización del Workflow de los registros de SAP Workflow o identifique el evento final de «liberación». Tipo de evento explicit | |||
| Factura bloqueada para pago | El sistema ha aplicado un bloqueo automático o manual a la factura, lo que impide su pago. Normalmente se debe 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 raíz de los retrasos en los pagos y las ineficiencias del proceso. Dónde obtenerlo Es un estado explícito registrado en el campo Payment Block Key (ZLSPR) de la posición del proveedor en el documento contable, en la tabla BSEG. Recopilar Se registra mediante documentos de modificación cuando el campo BSEG-ZLSPR contiene un motivo de bloqueo. Tipo de evento explicit | |||
| Factura cancelada | El documento de factura se ha anulado, eliminando efectivamente su impacto financiero. Es un estado final alternativo del proceso, normalmente debido a registros incorrectos o disputas con el proveedor. | ||
| Por qué es importante El seguimiento de las cancelaciones ayuda a identificar las causas de los fallos del proceso, como envíos duplicados o datos incorrectos de la factura, que pueden señalar problemas en etapas anteriores. Dónde obtenerlo Se registra explícitamente cuando se crea un documento de anulación. La cabecera del documento original (BKPF) contendrá el número del documento de anulación (STBLG) y el motivo de anulación. Recopilar Identifique la fecha de contabilización del documento de anulación, vinculado en la cabecera del documento original (BKPF-STBLG). Tipo de evento explicit | |||
| Factura contabilizada | La factura se registra formalmente en el libro mayor, lo que crea un pasivo financiero. Un documento aparcado 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 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). Un documento contabilizado tiene vacío el estado del documento (BKPF-BSTAT). Recopilar Utilice la marca de tiempo de contabilización (BKPF-BUDAT) para los documentos que no estén aparcados (BKPF-BSTAT está vacío). Tipo de evento explicit | |||
| Factura recibida | Esta actividad marca la creación de un documento de factura en SAP, ya sea manualmente o mediante una interfaz automatizada como OCR/VIM. Normalmente, este evento se captura 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 total del ciclo de la factura y medir el rendimiento de todo el proceso de cuentas por pagar. Dónde obtenerlo Este evento se captura de la tabla de cabecera del documento contable (BKPF), utilizando la fecha (CPUDT) y la hora (CPUTM) de creación del documento. Recopilar Utilice 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, cuando el pago y la factura se concilian entre sí en el sublibro. Esto indica que el proceso ha finalizado. | ||
| Por qué es importante Como punto final definitivo del proceso, esta actividad es esencial para calcular con precisión el tiempo de ciclo de extremo a extremo. Confirma que el pasivo ha quedado liquidado. Dónde obtenerlo Es un evento explícito que se marca cuando el campo de fecha de compensación (AUGDT) contiene un valor en la posición del proveedor del documento de factura, en la tabla BSEG. Recopilar Utilice la fecha de compensación (BSEG-AUGDT) de la posición de factura. Tipo de evento explicit | |||
| Pago ejecutado | Se ha realizado un pago contra la factura. Se captura 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» comparando esta fecha con la fecha de vencimiento de la factura. Dónde obtenerlo Se captura a partir 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 posición de factura (BSEG). Recopilar Identifique la fecha de contabilización (BUDAT) del documento de pago que compensa la posición de factura. Tipo de evento explicit | |||
| Discrepancia resuelta | Esta actividad indica que se ha investigado y resuelto un problema identificado previamente, que probablemente había provocado un bloqueo de 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 de facturas». Ayuda a cuantificar el tiempo y el esfuerzo dedicados a corregir errores. Dónde obtenerlo Se infiere a partir de 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. Recopilar Identifique los documentos de modificación de la tabla BSEG en los que el campo ZLSPR cambie de un valor a vacío. Tipo de evento inferred | |||
| Factura enviada para aprobación | La factura se ha enviado a un Workflow para obtener las aprobaciones necesarias 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 de aprobación. Dónde obtenerlo Puede capturarse a partir de los registros de SAP Business Workflow, las tablas SWW*, que registran el inicio de una instancia de Workflow vinculada al objeto de factura, por ejemplo, BUS2081. Recopilar Extraiga los eventos de inicio del Workflow de los registros de SAP Workflow, 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 Workflow de aprobación. Normalmente, esta acción devuelve la factura a la persona encargada de procesarla para que la corrija o aclare. | ||
| Por qué es importante El seguimiento de los rechazos pone de manifiesto los ciclos de retrabajo del proceso de aprobación y puede indicar problemas de cumplimiento de las políticas o una codificación incorrecta de la factura. Dónde obtenerlo Se captura como un evento de resultado específico en los registros de SAP Business Workflow asociados a la factura. Recopilar Extraiga los eventos de estado «rechazado» del Workflow a partir de los registros de SAP Workflow. Tipo de evento explicit | |||
| Factura registrada provisionalmente | Representa una factura que se ha introducido en el sistema, pero que todavía no se ha contabilizado en el libro mayor. A menudo, este paso se utiliza intencionadamente para guardar un documento incompleto y procesarlo o aprobarlo más adelante. | ||
| Por qué es importante Supervisar las facturas registradas provisionalmente ayuda a identificar retrasos antes de que comience la contabilización formal y puede poner de manifiesto problemas de integridad de los datos o de validación inicial. Dónde obtenerlo Este estado se infiere del campo de estado del documento en la cabecera del documento contable (BKPF-BSTAT = 'V' para registrado provisionalmente). El evento se produce cuando se establece este estado. Recopilar Identifique los documentos de modificación de la tabla BKPF en los que el campo BSTAT esté establecido en 'V' (Vor-erfasst, introducido previamente). Tipo de evento inferred | |||
| Goods Receipt conciliado | Esta actividad indica que las cantidades y los importes de la factura se han conciliado correctamente con el documento de Goods Receipt correspondiente. Es la validación final en un escenario de conciliación a tres bandas. | ||
| Por qué es importante Su seguimiento ayuda a localizar ineficiencias en el proceso de conciliación a tres bandas e identificar discrepancias entre los bienes recibidos y los que el proveedor está facturando. Dónde obtenerlo Se infiere a partir de la presencia de una referencia a un documento de material (Goods Receipt) en la posición de factura, normalmente vinculada mediante el historial de posiciones del pedido de compra. Recopilar Se infiere a partir de la presencia de una referencia al documento de Goods Receipt en la posición de factura, por ejemplo, en RSEG para facturas MIRO. Tipo de evento inferred | |||
| Ha pasado la fecha de vencimiento de la factura | Evento calculado que indica que ha pasado la fecha neta de vencimiento de la factura sin que se haya compensado ningún pago. Esto indica una situación de pago atrasado o vencido. | ||
| Por qué es importante Esta actividad es esencial para el Dashboard «Cumplimiento de pagos y antigüedad». Ayuda a identificar y gestionar de forma proactiva las facturas vencidas y a analizar las causas raíz de los pagos atrasados. Dónde obtenerlo No es un evento explícito en 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. Recopilar 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 | |||
| Pedido de compra conciliado | Esta actividad indica que la factura se ha conciliado correctamente con el pedido de compra correspondiente. Es un paso fundamental del proceso de conciliación a tres bandas para las facturas basadas en compras. | ||
| Por qué es importante Analizar esta actividad ayuda a medir la eficiencia del proceso de conciliación y es fundamental para los KPI «Rendimiento de la conciliación a tres bandas» y «Porcentaje de facturas sin pedido de compra». Dónde obtenerlo Se infiere cuando una posición de factura en la tabla BSEG o ACDOCA contiene un número de Purchase Order válido (EBELN) y una posición (EBELP). Recopilar Se infiere a partir de la presencia de una referencia de Purchase Order (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. Ahora está prevista para el pago, pendiente de la ejecución final de la propuesta. | ||
| Por qué es importante Esta actividad muestra la transición de un pasivo abierto a una partida que se está preparando activamente para el pago, lo que ayuda a analizar la eficiencia de las operaciones de pago. Dónde obtenerlo Este evento se registra explícitamente en las tablas de datos de la ejecución de pagos, concretamente REGUP (partidas procesadas del programa de pagos) y REGUH (cabecera). Recopilar Identifique cuándo aparece una factura en la tabla REGUP para una ejecución de pagos identificada en REGUH. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Requisitos previos y acceso: Asegúrese de disponer de un usuario con acceso de lectura al esquema de la base de datos de SAP S/4HANA, normalmente SAPABAP1 o uno 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 similar.
- 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. Esto implica establecer el identificador correcto del sistema de origen, el intervalo de fechas de las facturas (CreationDateTime) y las sociedades relevantes.
- Prepare la consulta principal: Copie la consulta SQL completa proporcionada en la sección de consultas en su cliente SQL. La consulta utiliza Common Table Expressions (CTE) para seleccionar primero una población base de facturas y, después, crear un registro de eventos uniendo los datos de 15 actividades diferentes.
- Establezca los parámetros de la consulta: En la consulta SQL copiada, localice las variables de marcador de posición. Sustituya '[YYYY-MM-DD]' por las fechas de inicio y finalización del periodo 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 finalice la consulta, revise las primeras cientos de filas de resultados. Compruebe la coherencia de los datos, asegúrese de que todas las columnas estén completas según lo previsto y verifique que aparezcan 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 utilice codificación UTF-8 para evitar problemas con los caracteres. Asigne al archivo un nombre descriptivo, por ejemplo, sap_s4hana_ap_event_log.csv.
- Prepárese para la carga: Antes de cargar el archivo 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 el archivo en la herramienta de Process Mining: Cargue el archivo CSV generado en su plataforma de Process Mining y asigne las columnas a los campos correspondientes de identificador de 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 vistas principales son:
- I_JournalEntry e I_JournalEntryItem: para las cabeceras y posiciones de los documentos financieros principales, los detalles 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 PO y los bloqueos de pago.
- I_ChangeDocument: para rastrear la marca de tiempo exacta 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 se incluye una factura en una propuesta de ejecución de pagos.
- I_Supplier: para enriquecer los datos con información maestra del proveedor, como VendorName.
- Filtrado por intervalo de fechas: Es fundamental aplicar un filtro de intervalo de fechas para limitar el volumen de datos. La consulta proporcionada filtra por CreationDateTime en el CTE Invoices_Base. Se recomienda un intervalo de 3 a 6 meses para el análisis inicial, a fin de mantener un rendimiento manejable.
- Filtros obligatorios: Filtre siempre por CompanyCode. Analizar simultáneamente datos de todos los códigos de sociedad puede ser extremadamente lento y no resultar relevante para el negocio. Filtre también por JournalEntryType para seleccionar únicamente documentos relacionados con proveedores, por ejemplo, «KR» y «RE».
- Requisitos previos: La persona usuaria de la base de datos que ejecute la consulta debe tener autorización SELECT en todas las vistas CDS utilizadas y en el esquema HANA subyacente. El acceso a nivel de aplicación en SAP GUI no es suficiente.
- Consideraciones de rendimiento: Las consultas directas sobre I_ChangeDocument pueden consumir muchos recursos. La consulta proporcionada intenta mitigarlo filtrando primero las facturas. En conjuntos de datos muy grandes, considere ejecutar la extracción fuera de las horas punta o en lotes con intervalos de fechas más pequeños.
a 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 está disponible el acceso directo de lectura al esquema de SAP HANA que contiene las tablas relevantes 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 tabla adicional configurada para documentos aparcados, Workflow, compras, recepción de mercancías, propuestas de pago, compensación y datos de reversión.
- Confirme el modelo de datos técnico del sistema de destino antes de ejecutar el proceso. Valide los nombres físicos, los campos clave, los campos de marca de tiempo, las relaciones de reversión, las relaciones de pago y la persistencia de Workflow que utiliza el sistema. Sustituya cada marcador entre corchetes de la consulta por el objeto o campo correspondiente del sistema. No dé por hecho que los datos de Workflow o de documentos aparcados se almacenan en una única tabla universal.
- Configure los parámetros de extracción. Establezca [Start date], [End date], [Company code filter], [Document type filter] y [Schema name]. Utilice inicialmente un intervalo de tres a seis meses y amplíelo después de validar el rendimiento y la integridad de los datos.
- Ejecute la consulta SQL en un cliente SQL de SAP HANA aprobado, como SAP HANA Database Explorer u otra herramienta autorizada de ejecución de SQL. 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 es el identificador del caso, que ActivityName contiene los 15 nombres de actividad requeridos, que EventTime está informado y presenta una secuencia cronológica plausible, que SourceSystem identifica SAP S/4HANA y que LastDataUpdate contiene la marca de tiempo de actualización de la extracción. Revise los eventos duplicados, las relaciones de reversión y las uniones entre documentos antes de cargar los datos.
- Aplique las asignaciones específicas del sistema que sean necesarias. Por ejemplo, asigne la fuente configurada de documentos aparcados a Invoice Parked; la fuente de Workflow configurada a Invoice Routed For Approval, Invoice Approved e Invoice Rejected; y la fuente de pagos configurada a Payment Proposal Created y Payment Executed. Conserve los identificadores de origen en columnas adicionales si necesita garantizar la trazabilidad de auditoría.
- Exporte el resultado como un archivo delimitado o un conjunto de resultados de base de datos, con un evento por fila. Utilice codificación UTF-8, conserve las marcas de tiempo en una zona horaria coherente, mantenga exactamente los nombres de columna Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber e InvoiceDueDate, y no agregue 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 fecha y hora del evento. Verifique que los atributos opcionales estén asignados a sus campos correspondientes. Como ProcessMind lee el registro de eventos tal como está, asegúrese de que cada actividad que quiera visualizar ya esté presente como una fila antes de cargarlo.
Configuración
- Intervalo de fechas: Comience con tres a seis meses. Utilice la fecha de contabilización, la fecha de creación del documento o la fecha del evento de origen correspondiente, según la actividad que se extraiga. Amplíe el intervalo solo después de validar el tiempo de ejecución de la consulta y la retención de datos del origen.
- Filtrado por sociedad: Configure [Company code filter] para limitar la extracción a las sociedades necesarias. Si no se requiere ninguna restricción, utilice una selección controlada de todas las sociedades en lugar de una consulta de producción sin restricciones.
- Filtrado de documentos: Configure [Document type filter] solo después de confirmar los tipos de documento utilizados para facturas de proveedores, abonos, documentos aparcados, documentos de pago y reversiones 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 de Workflow y el modelo de datos del sistema.
- Gestión de marcas de tiempo: Normalice todas las marcas de tiempo de origen a una única zona horaria. Cuando solo exista una fecha, utilice un componente horario 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 único 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 únicamente 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 inicialmente el periodo y el alcance de sociedades, filtre los campos indexados o relevantes para la partición, evite proyecciones amplias innecesarias y ejecute la consulta durante una ventana de generación de informes aprobada. Considere preparar subconjuntos de datos de origen si la consulta de producción supera el tiempo de ejecución acordado.
- Estrategia de actualización: Establezca LastDataUpdate con la marca de tiempo de ejecución de la extracción. Para cargas incrementales, conserve una marca de agua basada en la marca de tiempo de cambio relevante del origen e incluya un periodo de revisión para capturar actualizaciones tardías y reversiones.
- Requisitos previos: Autorizaciones de base de datos necesarias, acceso aprobado a producción, conocimiento de la configuración de Universal Journal del sistema, acceso a las fuentes configuradas de documentos aparcados, compras, recepción de mercancías, Workflow, pagos, compensación y reversiones, así como las aprobaciones de licencias o gobierno de SAP que correspondan.
a 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 de activación y los campos de datos de cada una de las 15 actividades requeridas. Identifique las tablas SAP relevantes, los tipos de documento, por ejemplo, «KR» y «RE», y las sociedades que se incluirán en el alcance.
- Crear el programa ABAP: abra el editor ABAP mediante la transacción SE38. Cree un programa ejecutable nuevo, por ejemplo, Z_PM_AP_INVOICE_EXTRACT. Proporcione un título descriptivo y establezca la aplicación como «Financial Accounting».
- Definir la pantalla de selección: en el programa, defina una pantalla de selección mediante las palabras clave PARAMETERS y SELECT-OPTIONS para permitir que los usuarios especifiquen el intervalo de fechas de extracción, correspondiente a la fecha de creación de la factura, las sociedades de destino (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 final del registro de eventos, por ejemplo, TY_EVENT_LOG, incluidos todos los atributos obligatorios y recomendados. Declare tablas internas para almacenar los datos seleccionados de distintas tablas de origen 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) según los criterios de la pantalla de selección del usuario. Almacene las claves principales de las facturas en una tabla interna para utilizarlas en las búsquedas posteriores.
- Extraer las actividades secuencialmente: para cada factura del conjunto principal, realice una serie de selecciones para encontrar las marcas de tiempo y los detalles de cada actividad empresarial. Por ejemplo, consulte CDHDR y CDPOS para detectar cambios en los bloqueos de pago, REGUH y REGUP para obtener los datos de las ejecuciones de pago, y BKPF para obtener los detalles de los documentos de reversión. Añada un nuevo registro a la tabla final del registro de eventos por cada actividad encontrada.
- Lógica para eventos calculados: implemente la 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 obligatorios. Esto implica buscar los nombres de los proveedores en LFA1, convertir las fechas y horas en una única cadena de marca de tiempo (CONCATENATE...INTO...) y establecer el valor de SourceSystem.
- Generar el archivo de salida: una vez procesadas y recopiladas todas las facturas y 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 ubicado en la ruta del servidor de aplicaciones especificada en la pantalla de selección.
- Descargar y preparar la carga: utilice la transacción CG3Y para descargar el archivo generado del servidor de aplicaciones a su equipo local. Asegúrese de guardar el archivo en formato CSV con codificación UTF-8. Verifique que las cabeceras de columna coincidan con los atributos requeridos, como Invoice, ActivityName y EventTime, antes de cargarlo en la herramienta de Process Mining.
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). Se recomienda utilizar inicialmente entre 6 y 12 meses de datos.
- Sociedad (P_BUKRS): parámetro SELECT-OPTIONS obligatorio para filtrar sociedades específicas. No se recomienda procesar todas las sociedades a la vez, salvo que sea estrictamente necesario.
- Tipo de documento de factura (P_BLART): parámetro SELECT-OPTIONS para filtrar los tipos de documento de factura relevantes. Entre los tipos habituales se incluyen «KR» (factura de proveedor), «KG» (abono de proveedor) y «RE» (verificación de factura logística).
- Modo de ejecución: el programa debe ejecutarse como un job en segundo plano (SM36/SM37) cuando se trabaje con grandes volúmenes de datos, para evitar tiempos de espera agotados en el proceso de diálogo en primer plano. Prográmelo durante las horas de menor actividad.
- Ruta del archivo de salida: un PARAMETER 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 de FI, CO y MM (BKPF, BSEG, RBKP, RSEG, LFA1), las tablas de documentos de modificación (CDHDR, CDPOS) y las tablas de Workflow. Además, se necesita el objeto de autorización S_DATASET para escribir archivos en el servidor de aplicaciones.
a 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 este Template para poner en marcha su iniciativa de Process Mining y lograr mejoras significativas en sus operaciones de cuentas por pagar. Comience hoy su camino hacia un proceso más optimizado y ágil.
Evite los recargos por demora: optimice hoy el procesamiento de sus facturas de cuentas por pagar
Reduzca los costos de procesamiento en un 60 % y elimine fácilmente los pagos duplicados.
No necesita tarjeta de crédito. Comience en cuestión de minutos.