Su Template de datos para compra a pago: procesamiento de facturas
Su Template de datos para compra a pago: procesamiento de facturas
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía de extracción para SAP S/4HANA
Atributos del proceso de compra a pago: procesamiento de facturas
| Nombre | Descripción | ||
|---|---|---|---|
| Número de factura InvoiceNumber | Identificador único del documento de factura del proveedor, que sirve como identificador principal del caso en el proceso. | ||
| Descripción El número de factura es el identificador único que se asigna a cada factura de proveedor en SAP S/4HANA. Vincula todas las actividades relacionadas, como la creación, el aparcamiento, la aprobación y el pago, en una única instancia del proceso. En Process Mining, este atributo es fundamental para hacer un seguimiento del recorrido completo de cada factura. Permite reconstruir todo el flujo del proceso, desde la recepción hasta el pago final, y analizar los tiempos de ciclo, los cuellos de botella y las variaciones del proceso para cada factura. Por qué es importante Es la clave esencial para conectar todos los eventos relacionados y seguir el ciclo de vida completo de una factura en el sistema. Dónde obtenerlo Es el número de documento contable, que se encuentra en la tabla BKPF, campo BELNR. Ejemplos 190000000119000000451900000132 | |||
| Hora del evento EventTime | Fecha y hora exactas en que se produjo la actividad. | ||
| Descripción La hora del evento es la marca de tiempo que registra el momento exacto en que se produjo una actividad concreta. Estos datos son esenciales para calcular las duraciones, los tiempos de ciclo y los tiempos de espera entre los distintos pasos del proceso. En el análisis de Process Mining, las marcas de tiempo precisas permiten medir KPI de rendimiento como «Tiempo medio del ciclo de facturación» y «Tiempo del ciclo de aprobación de facturas». Al analizar el tiempo transcurrido entre actividades, las organizaciones pueden localizar los cuellos de botella que retrasan las facturas e identificar oportunidades para agilizar el proceso. Por qué es importante Esta marca de tiempo es la base de todos los análisis temporales, incluido el seguimiento del rendimiento, la identificación de cuellos de botella y el control de los SLA. Dónde obtenerlo Por lo general, se obtiene de las tablas de documentos de modificación CDHDR (cabecera) y CDPOS (partida), mediante los campos UDATE y UTIME. Para algunos eventos, puede proceder de las fechas de creación o entrada de tablas como BKPF (CPUDT, CPUTM). Ejemplos 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Nombre de la actividad ActivityName | Nombre de la actividad de negocio o del evento que tuvo lugar en un momento determinado para una factura. | ||
| Descripción El nombre de la actividad describe un paso concreto o un cambio de estado durante el ciclo de procesamiento de la factura. Algunos ejemplos son «Documento de factura creado», «Factura enviada para aprobación», «Bloqueo de pago establecido» y «Pago ejecutado». Este atributo es fundamental para crear el mapa del proceso, que representa visualmente el flujo de actividades. Analizar la secuencia, la frecuencia y la duración entre estas actividades ayuda a identificar cuellos de botella, ciclos de reproceso y variaciones del proceso que no cumplen los estándares. Es la base de cualquier análisis de Process Mining. Por qué es importante Define los pasos del proceso y permite visualizar los mapas de procesos y analizar los flujos y las variaciones. Dónde obtenerlo Se obtiene de una combinación de códigos de transacción de SAP (SY-TCODE), estados de objetos de documentos de modificación (CDHDR/CDPOS) y valores de campos específicos que indican cambios de estado. Ejemplos Factura aparcadaFactura aprobadaPago ejecutado | |||
| Fecha de vencimiento del pago PaymentDueDate | Fecha límite para pagar la factura y evitar que quede vencida. | ||
| Descripción La fecha de vencimiento del pago es la fecha calculada en que debe pagarse al proveedor, según la fecha de la factura y las condiciones de pago acordadas. Es un plazo fundamental del proceso. Este atributo es esencial para el KPI de «Tasa de pagos puntuales» y el Dashboard de «Rendimiento de los pagos a proveedores». Al comparar la fecha real de pago con la fecha de vencimiento, una empresa puede medir su capacidad para cumplir sus obligaciones de pago, lo que afecta a las relaciones con los proveedores y a su reputación financiera. Por qué es importante Es la referencia principal para medir el cumplimiento de los plazos de pago, algo crucial para mantener buenas relaciones con los proveedores y evitar cargos por demora. Dónde obtenerlo Esta fecha suele estar disponible directamente en la partida del proveedor de la tabla BSEG, campo ZFBDT (fecha base para calcular el vencimiento). La fecha neta de vencimiento se calcula a partir de esta fecha base y las condiciones de pago. Ejemplos 2023-05-302023-06-152023-07-01 | |||
| Importe de la factura AmountInCompanyCodeCurrency | Importe bruto total de la factura en la moneda local de la sociedad. | ||
| Descripción Este atributo representa el valor total de la factura. Es una métrica clave para comprender el impacto financiero y la escala de la operación de procesamiento de facturas. Analizar los importes de las facturas ayuda a priorizar las de mayor valor para procesarlas más rápido, detectar tendencias de gasto y relacionar los problemas del proceso con su impacto financiero. Por ejemplo, permite investigar si las facturas de mayor importe tienen más probabilidades de bloquearse o tardan más en aprobarse. Por qué es importante Aporta contexto financiero al proceso y permite analizarlo según el valor monetario, por ejemplo, para determinar si las facturas de mayor importe se procesan de otra manera. Dónde obtenerlo Este valor suele obtenerse de la suma de las partidas pertinentes de la tabla BSEG, campo WRBTR (importe en moneda local). Ejemplos 1500.75125000.00850.20 | |||
| Motivo del bloqueo de pago PaymentBlockReason | Código que indica por qué se ha bloqueado una factura para el pago. | ||
| Descripción Cuando se bloquea una factura para el pago, este atributo indica el motivo concreto, como «Diferencia en la cantidad» o «Diferencia de precio». Estos motivos se configuran en SAP para estandarizar la gestión de excepciones. Este atributo es fundamental para el Dashboard de «Frecuencia y duración de los bloqueos de pago». Analizar la frecuencia de los distintos motivos de bloqueo ayuda a identificar las causas raíz de los retrasos en los pagos, como problemas con determinados proveedores, materiales o procesos internos, y permite tomar medidas correctivas específicas. Por qué es importante Indica la causa raíz concreta de los bloqueos de pago y permite analizarla para reducir los retrasos y mejorar el procesamiento correcto desde el primer intento. Dónde obtenerlo Se encuentra en la partida del proveedor de la tabla BSEG, campo ZLSPR (clave de bloqueo de pago). Ejemplos RIA | |||
| Nombre de usuario UserName | ID de usuario de SAP de la persona o el sistema que realizó la actividad. | ||
| Descripción Este atributo identifica al usuario que ejecutó una transacción concreta o creó un documento. Puede ser el ID de una persona o el ID de un sistema que ejecuta trabajos por lotes automatizados. El análisis por usuario ayuda a comprender la distribución de la carga de trabajo, detectar necesidades de formación e identificar comportamientos inusuales. Por ejemplo, puede mostrar qué usuarios gestionan excepciones con frecuencia o qué facturas se procesan automáticamente (por ejemplo, el usuario «BATCHUSER»), un dato clave para calcular el KPI de «Tasa de automatización de facturas». Por qué es importante Asocia las actividades del proceso con usuarios o cuentas del sistema específicos, lo que permite analizar la carga de trabajo, comparar el rendimiento y detectar la automatización. Dónde obtenerlo Se obtiene de campos como BKPF-USNAM (introducido por) o CDHDR-USERNAME (modificado por). Ejemplos SMITHJMUELLERTWF-BATCH | |||
| Número de proveedor VendorNumber | Identificador único del proveedor que presentó la factura. | ||
| Descripción El número de proveedor identifica al proveedor o acreedor asociado a la factura. Vincula la transacción de la factura con los datos maestros del proveedor. Este atributo es fundamental para analizar los procesos desde la perspectiva del proveedor, por ejemplo, para evaluar el «Rendimiento de los pagos a proveedores» o identificar a quienes presentan con frecuencia facturas problemáticas que generan excepciones o bloqueos de pago. Ayuda a gestionar las relaciones con los proveedores y a evaluar su fiabilidad. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, detectar patrones, gestionar relaciones y evaluar problemas relacionados con los proveedores. Dónde obtenerlo Suele encontrarse en la tabla de partidas del documento contable BSEG, campo LIFNR. Ejemplos 100345700012V9832 | |||
| Pedido de compra PurchasingDocument | Número del pedido de compra relacionado con la factura. | ||
| Descripción El número del documento de compras vincula la factura del proveedor con el pedido de compra (PO) original. Este vínculo es fundamental para la conciliación a tres vías, que verifica la factura con el pedido de compra y la recepción de mercancías. Analizar este atributo ayuda a comprender los problemas relacionados con las facturas asociadas a pedidos de compra y las que no lo están. Es clave para investigar discrepancias de conciliación y entender la eficiencia de la parte de compras del proceso. Por qué es importante Vincula la factura con el proceso de compras, algo esencial para analizar discrepancias de conciliación y el cumplimiento de los pedidos de compra. Dónde obtenerlo Esta información suele encontrarse en la tabla de partidas de documentos BSEG, campo EBELN (número de documento de compras). Ejemplos 450000123445000056784500009012 | |||
| Sociedad CompanyCode | Unidad organizativa que representa una empresa jurídicamente independiente para la que se elaboran estados financieros. | ||
| Descripción La sociedad es una unidad organizativa fundamental en SAP Finance. Cada factura se asigna a una sociedad específica, que determina la entidad jurídica responsable de la transacción. En Process Mining, filtrar o comparar por sociedad es esencial para analizar el rendimiento de los procesos entre distintas unidades de negocio, entidades jurídicas o países. Ayuda a detectar diferencias regionales en eficiencia, cumplimiento y niveles de automatización, y permite orientar las iniciativas de mejora. Por qué es importante Permite segmentar y comparar el rendimiento del procesamiento de facturas entre distintas entidades jurídicas o ubicaciones geográficas de la organización. Dónde obtenerlo Es un campo estándar de la tabla de cabecera de documentos BKPF, campo BUKRS. Ejemplos 1000US01DE01 | |||
| Tipo de documento DocumentType | Código que clasifica los distintos tipos de documentos contables, como facturas de proveedores o notas de crédito. | ||
| Descripción SAP utiliza el tipo de documento para distinguir entre distintas transacciones de negocio. Por ejemplo, «KR» suele representar una factura estándar de proveedor, mientras que «KG» puede corresponder a una nota de crédito de proveedor. El análisis por tipo de documento permite segmentar el proceso para comprender cómo se gestionan los distintos tipos de transacciones. Por ejemplo, el proceso de una nota de crédito puede diferir considerablemente del de una factura estándar. Esta segmentación proporciona información más precisa y pertinente sobre el proceso. Por qué es importante Ayuda a distinguir entre distintos tipos de transacciones financieras, como las facturas estándar y las notas de crédito, que suelen seguir rutas de proceso diferentes. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo BLART. Ejemplos KRREKG | |||
| Condiciones de pago PaymentTerms | Código que define las condiciones de pago acordadas con el proveedor, como las fechas de vencimiento y los periodos de descuento. | ||
| Descripción Las condiciones de pago definen las reglas para pagar una factura, incluidos los posibles descuentos por pronto pago. Por ejemplo, «Z030» puede significar «Pago neto en un plazo de 30 días». Este atributo es esencial para la planificación financiera y la optimización del capital de trabajo. En Process Mining, se utiliza para calcular la «Fecha de vencimiento del pago» y determinar si se pueden aplicar descuentos por pronto pago, lo que contribuye directamente al KPI de «Tasa de descuentos por pronto pago aprovechados». Por qué es importante Define las reglas para las fechas de vencimiento y los descuentos, e influye directamente en los KPI de pagos puntuales y en la gestión del capital de trabajo. Dónde obtenerlo Se encuentra en la partida del proveedor de la tabla BSEG, campo ZTERM (clave de condiciones de pago). Ejemplos 0001Z030NT60 | |||
| Es automatizada IsAutomated | Indicador que señala si una actividad fue realizada por un usuario de sistema automatizado. | ||
| Descripción Este atributo booleano es verdadero si el usuario asociado a una actividad es una cuenta de sistema o de procesamiento por lotes conocida, como «WF-BATCH» o «SAP_SYSTEM». Ayuda a distinguir los pasos manuales de los automatizados. Este atributo es esencial para calcular el KPI de «Tasa de automatización de facturas». Al analizar qué partes del proceso están automatizadas, las organizaciones pueden medir el éxito de sus iniciativas de automatización e identificar otras oportunidades para reducir el trabajo manual y mejorar la eficiencia. Por qué es importante Distingue las actividades manuales de las realizadas por el sistema, algo fundamental para medir las tasas de automatización e identificar oportunidades para automatizar más tareas. Dónde obtenerlo Se obtiene del atributo UserName. Se crea una asignación o regla para clasificar determinados ID de usuario como «automatizados». Ejemplos truefalse | |||
| Es reproceso IsRework | Indicador que señala si una factura ha pasado por actividades de reproceso, como el rechazo de una aprobación o la eliminación de un bloqueo de pago. | ||
| Descripción Este atributo marca las facturas que han pasado por uno o más ciclos de reproceso. El reproceso se identifica mediante secuencias de actividades específicas, por ejemplo, «Factura aprobada» después de «Factura rechazada» o «Bloqueo de pago eliminado» después de «Bloqueo de pago establecido». Este atributo simplifica el cálculo del KPI de «Tasa de reproceso de facturas». Permite a quienes analizan los datos aislar e investigar fácilmente los casos con reprocesos para comprender las causas raíz de la ineficiencia y del trabajo manual repetido. Por qué es importante Identifica los flujos de proceso ineficientes en los que hay que repetir el trabajo, lo que ayuda a cuantificar el desperdicio y localizar las causas raíz de las excepciones del proceso. Dónde obtenerlo Se calcula a partir de la secuencia de actividades del registro de eventos. Por ejemplo, si «Factura rechazada» aparece en el recorrido de una factura, este indicador se establece como verdadero. Ejemplos truefalse | |||
| Fecha de la factura InvoiceDate | Fecha en que el proveedor emitió la factura. | ||
| Descripción La fecha de la factura, también llamada fecha del documento, es la que indica el proveedor en la factura. Se utiliza como punto de partida para calcular la fecha de vencimiento del pago según las condiciones acordadas. En el análisis, esta fecha es fundamental para los cálculos financieros, como determinar la antigüedad de las facturas y si pueden acogerse a descuentos por pronto pago. Es un dato clave para el KPI de «Tasa de descuentos por pronto pago aprovechados». Por qué es importante Sirve de base para calcular las condiciones y las fechas de vencimiento del pago, algo esencial para gestionar el capital de trabajo y aprovechar los descuentos. Dónde obtenerlo Se encuentra en la tabla de cabecera de documentos BKPF, campo BLDAT (fecha del documento). Ejemplos 2023-04-122023-05-152023-06-20 | |||
| ID del sistema de origen SourceSystemId | Identificador del sistema SAP S/4HANA de origen del que se extrajeron los datos. | ||
| Descripción Este atributo especifica el sistema de origen, por ejemplo, «S4H_PROD» o «ERP_EU». Es especialmente importante en entornos con varias instancias de ERP o una combinación de sistemas antiguos y modernos. El análisis permite comparar el rendimiento de los procesos entre distintos sistemas o regiones. También garantiza la trazabilidad del origen de los datos y es fundamental para la gobernanza de datos y la resolución de problemas cuando se combinan datos de varias fuentes en una plataforma central de Process Mining. Por qué es importante Indica el origen de los datos, algo esencial para la gobernanza de datos y para comparar procesos entre distintos sistemas o ubicaciones de la empresa. Dónde obtenerlo Este valor suele obtenerse del ID del sistema SAP (sy-sysid) durante la extracción de datos o configurarse como un valor estático en el flujo ETL. Ejemplos S4PS4H_PROD_100ECC_EU | |||
| Marca de tiempo de extracción ExtractionTimestamp | Fecha y hora en que se extrajeron los datos del sistema de origen. | ||
| Descripción Este atributo registra la marca de tiempo de la extracción de datos e indica qué tan actualizados están los datos analizados en la herramienta de Process Mining. En el análisis, permite conocer la antigüedad de la información obtenida. Es fundamental para los Dashboards de seguimiento operativo, ya que ayuda a garantizar que las decisiones se basen en información actualizada y a gestionar eficazmente los ciclos de actualización de datos. Por qué es importante Indica qué tan actualizados están los datos y garantiza que el análisis y los informes se basen en la información más reciente disponible. Dónde obtenerlo No es un campo de SAP. La herramienta de extracción de datos o el proceso ETL lo genera y añade al extraer los datos. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Motivo de anulación ReversalReason | Código que indica por qué se anuló un documento de factura. | ||
| Descripción Si una factura se contabiliza incorrectamente, suele anularse. El código de motivo de anulación explica por qué se tomó esta medida, por ejemplo, «Fecha de contabilización incorrecta» o «Error de introducción de datos». Analizar los motivos de anulación ayuda a detectar patrones de error en el proceso de contabilización de facturas. Esta información puede servir para mejorar la formación, reforzar los controles del sistema o resolver problemas recurrentes que generan reprocesos financieros y carga administrativa. Por qué es importante Explica por qué se anularon las facturas y aporta información directa sobre las fuentes de errores y reprocesos en el proceso de contabilización. Dónde obtenerlo Se encuentra en la cabecera del documento original de la tabla BKPF, campo STGRD (motivo de anulación). Ejemplos 010205 | |||
| N.º de documento de compensación. ClearingDocumentNumber | Número del documento que compensa la factura, que suele corresponder al documento de pago. | ||
| Descripción El número del documento de compensación vincula una partida de factura abierta con la transacción que la compensa, que casi siempre es el documento de pago. Esto confirma que la factura se ha pagado. Este atributo establece el vínculo definitivo entre una factura y su pago. Se utiliza para identificar la actividad «Pago ejecutado» y su marca de tiempo correspondiente, algo esencial para calcular el tiempo total del ciclo y la tasa de pagos puntuales. Por qué es importante Confirma que se ha pagado una factura y la vincula con la transacción de pago correspondiente, algo fundamental para analizar el tiempo de ciclo y el rendimiento de los pagos. Dónde obtenerlo Se encuentra en la tabla de partidas de documentos BSEG, campo AUGBL (número de documento de compensación). Ejemplos 150000000115000000231500000088 | |||
| Número de ciclos de aprobación ApprovalCycleCount | Número de veces que se envió una factura para su aprobación. | ||
| Descripción Esta métrica cuenta cuántas veces se produce la actividad «Factura enviada para aprobación» para una misma factura. Un valor superior a uno indica que la factura se rechazó o devolvió al menos una vez y necesitó otro ciclo de aprobación. Este atributo contribuye directamente al KPI de «Tasa de aprobación al primer intento». Al analizar las facturas con un número elevado de ciclos de aprobación, las organizaciones pueden identificar los motivos de los rechazos, como la falta de información o una codificación incorrecta, y tomar medidas para mejorar el proceso. Por qué es importante Cuantifica el reproceso dentro del subproceso de aprobación, lo que ayuda a medir la tasa de resolución correcta al primer intento e identificar los motivos de los rechazos. Dónde obtenerlo Se calcula contando cuántas veces aparece la actividad «Factura enviada para aprobación» para cada valor único de InvoiceNumber. Ejemplos 123 | |||
| Pagada a tiempo IsPaidOnTime | Indicador que es verdadero si la factura se pagó en la fecha de vencimiento o antes. | ||
| Descripción Este atributo booleano se obtiene al comparar la fecha real de pago (la marca de tiempo de la actividad «Pago ejecutado») con la «Fecha de vencimiento del pago». Proporciona un resultado claro, de sí o no, para el estado de pago de cada factura. Este es el cálculo principal del KPI de «Tasa de pagos puntuales». Permite filtrar y analizar fácilmente las características de los pagos atrasados, como los proveedores, las sociedades o los importes de factura que suelen asociarse a los retrasos. Por qué es importante Mide directamente el cumplimiento de las condiciones de pago, un KPI fundamental para gestionar las relaciones con los proveedores y las operaciones financieras. Dónde obtenerlo Se calcula comparando la hora del evento de la actividad «Pago ejecutado» con el atributo PaymentDueDate. (Payment Date <= PaymentDueDate). Ejemplos truefalse | |||
Actividades del proceso de compra a pago: procesamiento de facturas
| Actividad | Descripción | ||
|---|---|---|---|
| Documento de factura creado | Este es el primer evento y marca la creación de un documento de factura en SAP. Puede registrarse cuando una persona guarda un documento de factura nuevo, que puede quedar aparcado o pendiente de contabilización. | ||
| Por qué es importante Esta actividad marca el inicio del ciclo de vida del procesamiento de facturas. Analizar el tiempo transcurrido desde este evento hasta los siguientes es fundamental para medir el tiempo de entrega total del procesamiento. Dónde obtenerlo Este evento se obtiene de la fecha y hora de creación (CPUDT, CPUTM) en la tabla de cabecera del documento, normalmente BKPF o RBKP en el caso de las facturas logísticas. El código de transacción (BKPF-TCODE), como FB60, MIRO o MIR7, indica el método de creación. Capturar Utilice la fecha y hora de creación de BKPF-CPUDT y BKPF-CPUTM para el documento de factura. Tipo de evento explicit | |||
| Factura anulada | Actividad que representa la anulación de un documento de factura contabilizado anteriormente. Es un evento final para una factura incorrecta, que suele volver a introducirse con los datos correctos. | ||
| Por qué es importante Las anulaciones indican errores críticos que no se detectaron antes en el proceso. Hacer un seguimiento de su frecuencia y causas raíz es esencial para mejorar el proceso y reducir las imprecisiones financieras. Dónde obtenerlo La anulación se identifica cuando se crea un documento de anulación. La cabecera del documento original (BKPF) contiene el número del documento de anulación (BKPF-STBLG), y viceversa. La fecha de contabilización del documento de anulación es la hora del evento. Capturar Identifique los documentos que tengan un valor en el campo BKPF-STBLG y use la fecha de contabilización del documento de anulación. Tipo de evento explicit | |||
| Factura aprobada | Esta actividad indica que la autoridad designada ha aprobado la factura. Se registra cuando el flujo de trabajo de aprobación finaliza correctamente o se establece un indicador de liberación. | ||
| Por qué es importante Este es un hito crítico que habilita la factura para el pago. Las demoras en las aprobaciones son un cuello de botella habitual. Hacer un seguimiento de esta actividad ayuda a localizar a quienes tardan en aprobar o los pasos que ralentizan el proceso. Dónde obtenerlo Puede inferirse a partir del paso final de liberación en un flujo de trabajo de SAP o mediante el seguimiento de los cambios en los campos de estado de liberación de las tablas asociadas a la factura o a su documento de compras. Capturar Infiera este evento a partir de la finalización del flujo de trabajo o de los cambios en el campo de estado de liberación del documento. Tipo de evento inferred | |||
| Factura contabilizada | Este es un evento financiero clave: la factura aparcada o aprobada se contabiliza formalmente en el libro mayor. Esta acción reconoce la obligación con el proveedor. | ||
| Por qué es importante La contabilización es un hito importante que marca el paso de la captura y aprobación de datos a la fase de liquidación financiera. El tiempo transcurrido desde la creación de la factura hasta su contabilización es un indicador clave de la eficiencia del procesamiento interno. Dónde obtenerlo Este evento se identifica mediante la fecha de contabilización (BKPF-BUDAT) de la cabecera del documento. Si primero se aparca el documento, el cambio a estado contabilizado proporciona la marca de tiempo del evento. Capturar Use la fecha de contabilización (BKPF-BUDAT) como marca de tiempo del evento. Tipo de evento explicit | |||
| Pago ejecutado | Esta es la última actividad del proceso estándar: se realiza el pago y se compensa la factura. Esto indica que los fondos se han transferido al proveedor. | ||
| Por qué es importante Este evento marca el final del ciclo de vida de la factura de compra a pago (P2P). Es esencial para calcular el tiempo total del ciclo de principio a fin y medir el porcentaje de pagos puntuales con respecto a la fecha de vencimiento. Dónde obtenerlo Este evento se obtiene de la información del documento de compensación en la partida del proveedor. La fecha de compensación (BSEG-AUGDT) y el documento de compensación (BSEG-AUGBL) indican que se ha realizado el pago. Capturar Use la fecha de compensación (BSEG-AUGDT) de la partida compensada del proveedor. Tipo de evento explicit | |||
| Bloqueo de pago establecido | Actividad en la que se bloquea deliberadamente una factura para impedir su pago. Suele deberse a discrepancias de precio o cantidad, o a una nota de crédito pendiente. | ||
| Por qué es importante Los bloqueos de pago son una de las principales causas de los retrasos en los pagos y las disputas con proveedores. Analizar su frecuencia, duración y motivos es fundamental para mejorar la puntualidad de los pagos. Dónde obtenerlo Este evento se registra mediante el seguimiento de los cambios en el campo de clave de bloqueo de pago (BSEG-ZLSPR) de la posición de la factura. Los registros de cambios de CDHDR y CDPOS indican la fecha, la hora y la persona que estableció el bloqueo. Capturar Identifique cuándo se completa el campo BSEG-ZLSPR mediante los documentos de modificación (CDHDR/CDPOS). Tipo de evento explicit | |||
| Bloqueo de pago retirado | Representa la resolución de un problema mediante la retirada de un bloqueo de pago establecido previamente. Esto vuelve a habilitar la factura para el pago. | ||
| Por qué es importante El tiempo transcurrido entre el establecimiento y la retirada de un bloqueo representa el tiempo de resolución de una excepción del proceso. Reducirlo es fundamental para mejorar la eficiencia y las relaciones con los proveedores. Dónde obtenerlo Este evento se registra cuando se borra el campo de clave de bloqueo de pago (BSEG-ZLSPR). El cambio queda registrado en las tablas CDHDR y CDPOS, que proporcionan la fecha y hora de la retirada. Capturar Identifique cuándo se borra el campo BSEG-ZLSPR mediante los documentos de modificación (CDHDR/CDPOS). Tipo de evento explicit | |||
| Datos de la factura actualizados | Esta actividad refleja un cambio realizado en el documento de factura después de su creación inicial. Es habitual durante los ciclos de retrabajo posteriores a un rechazo o para corregir errores. | ||
| Por qué es importante Las actualizaciones frecuentes indican retrabajo y posibles problemas de calidad de los datos en el momento de la entrada. Hacer un seguimiento de estos cambios ayuda a cuantificar el esfuerzo dedicado a las correcciones e identificar errores comunes. Dónde obtenerlo Los cambios en campos clave se registran en las tablas de documentos de modificación de SAP: CDHDR (cabecera) y CDPOS (posición). Se pueden generar eventos filtrando los cambios del objeto de factura pertinente. Capturar Extraiga los eventos de modificación del objeto de factura de las tablas CDHDR y CDPOS. Tipo de evento explicit | |||
| Factura aparcada | Es una factura que se ha introducido en el sistema, pero aún no se ha contabilizado en el libro mayor. El aparcamiento permite guardar facturas incompletas o dejarlas pendientes de revisión antes de contabilizarlas. | ||
| Por qué es importante El aparcamiento indica una pausa deliberada en el proceso. Hacer un seguimiento de la duración y la frecuencia de las facturas aparcadas ayuda a identificar las causas de las demoras antes de que comience el ciclo formal de contabilización y aprobación. Dónde obtenerlo Puede identificarse mediante documentos creados con transacciones de aparcamiento, como MIR7 o FV60, o consultando campos de estado específicos de la tabla BKPF o tablas específicas de documentos aparcados, como VBKPF. Capturar Identifique los documentos creados mediante transacciones de aparcamiento o compruebe si tienen el estado de documento aparcado. Tipo de evento explicit | |||
| Factura enviada para aprobación | Esta actividad marca el inicio del flujo de trabajo formal de aprobación de la factura. Suele inferirse cuando el estado de la factura cambia a «pendiente de aprobación» o se genera un elemento de flujo de trabajo. | ||
| Por qué es importante Este es el punto de partida para medir el tiempo de ciclo de aprobación. Saber cuándo comienzan las aprobaciones es fundamental para identificar cuellos de botella en el propio flujo de trabajo de aprobación. Dónde obtenerlo Suele inferirse a partir del inicio de un SAP Business Workflow (tabla SWW_WI2OBJ) vinculado al objeto de factura, por ejemplo BUS2081, o de un cambio en un campo de estado personalizado de la cabecera del documento. Capturar Infiera este evento a partir de la creación de un elemento de flujo de trabajo relacionado con el documento de factura. Tipo de evento inferred | |||
| Factura rechazada | Representa el rechazo de una factura durante el proceso de aprobación. Este evento genera retrabajo, ya que es necesario corregir la factura y volver a enviarla. | ||
| Por qué es importante El rechazo de facturas es un indicador clave de ineficiencias del proceso y problemas de calidad de los datos. Analizar la frecuencia y los motivos de los rechazos ayuda a identificar oportunidades de mejora y formación. Dónde obtenerlo Se infiere a partir de actualizaciones de estado específicas en un flujo de trabajo de SAP, como el estado «rechazado», o de eventos que cancelan el flujo de trabajo de aprobación actual y devuelven la factura a la persona encargada de procesarla. Capturar Infiera este evento a partir de los cambios en el estado del flujo de trabajo que indiquen un rechazo. Tipo de evento inferred | |||
| Pago ejecutado con retraso | Este evento calculado se produce cuando el pago de una factura se ejecuta después de su fecha de vencimiento calculada. Se obtiene comparando dos campos de fecha. | ||
| Por qué es importante Esta actividad contribuye directamente a los KPI de pagos puntuales y ayuda a identificar proveedores o unidades de negocio con pagos atrasados frecuentes, lo que puede perjudicar las relaciones con los proveedores y generar penalizaciones. Dónde obtenerlo Se calcula comparando la fecha de compensación (BSEG-AUGDT) con la fecha neta de vencimiento. Esta última se calcula a partir de la fecha base (BSEG-ZFBDT) y las condiciones de pago (BSEG-ZTERM). Capturar Se obtiene comparando BSEG-AUGDT > (BSEG-ZFBDT + días del plazo de pago). Tipo de evento calculated | |||
| Propuesta de pago creada | La factura se selecciona y se incluye en una propuesta de pago como parte de una ejecución de pagos. Este es el primer paso del proceso de pago automatizado. | ||
| Por qué es importante Esta actividad indica la intención de pagar. Los retrasos entre este paso y la ejecución final del pago pueden revelar problemas en la ejecución de pagos, las aprobaciones o la comunicación con el banco. Dónde obtenerlo Esta información se encuentra en las tablas de ejecución de pagos, en concreto en REGUP, que contiene las partidas incluidas en una propuesta de pago. La fecha de ejecución de la tabla REGUH correspondiente proporciona la marca de tiempo. Capturar Identifique cuándo aparece una factura en la tabla REGUP a partir de una ejecución de propuesta de pago. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Requisitos previos y autorizaciones: Asegúrese de que el usuario que ejecuta la extracción tenga las autorizaciones necesarias en SAP S/4HANA para acceder a las vistas de Core Data Services (CDS) requeridas. Entre las vistas clave se incluyen
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemyI_PaymentProposalItem. El usuario también necesitará permisos para ejecutar consultas mediante la interfaz elegida, como un servicio OData o una conexión SQL directa. - Identifique el método de conexión: Determine cómo se conectará al sistema SAP S/4HANA para ejecutar la consulta SQL. Entre los métodos habituales se incluyen SAP Data Services, SAP Data Intelligence, una herramienta ETL de terceros con un conector de SAP o una conexión SQL directa a la base de datos SAP HANA, si las políticas de seguridad de su organización lo permiten.
- Defina los parámetros de extracción: Antes de ejecutar la consulta, defina los parámetros clave. Especifique el intervalo de fechas de extracción, por ejemplo,
CreationDateentre'YYYY-MM-DD'y'YYYY-MM-DD'. Identifique también los valores deCompanyCodeque desea incluir para limitar el alcance de la extracción de datos. - Personalice la consulta SQL: Copie la consulta SQL proporcionada en el cliente SQL o la herramienta de extracción de datos que haya elegido. Revise con atención los marcadores de posición, como
'{StartDate}','{EndDate}'y('{CompanyCode1}', '{CompanyCode2}'). Sustitúyalos por los valores reales que definió en el paso anterior. También puede que deba ajustar los nombres de los campos del estado del flujo de trabajo según la configuración específica de SAP. - Ejecute la consulta: Ejecute la consulta SQL completa en la base de datos SAP S/4HANA o a través de la capa de servicios correspondiente. La consulta está diseñada para abarcar todos los datos necesarios y, según el volumen de datos y el intervalo de fechas seleccionado, puede tardar bastante. Supervise la ejecución para detectar posibles errores o tiempos de espera agotados.
- Revise los resultados iniciales: Cuando termine la consulta, revise rápidamente los resultados. Compruebe que las columnas
InvoiceNumber,ActivityNameyEventTimecontengan datos. Verifique que la columnaActivityNameincluya distintas actividades y no solo 'Documento de factura creado'. - Revise la transformación de datos: La consulta está estructurada para generar un Registro de eventos limpio. Aun así, asegúrese de que la columna
EventTimeutilice un formato de marca de tiempo uniforme, comoYYYY-MM-DDTHH:MM:SS. Cuando es necesario, la consulta combina los campos de fecha y hora en una sola marca de tiempo. - Exporte los datos: Exporte el conjunto final de resultados de la herramienta a un archivo CSV (valores separados por comas). Este formato es compatible con las herramientas de Process Mining, incluido ProcessMind.
- Prepare la carga: Antes de cargar el archivo, confirme que utiliza la codificación UTF-8 para evitar problemas con los caracteres. Asegúrese de que los encabezados de las columnas coincidan exactamente con los atributos requeridos:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Cargue los datos en ProcessMind: Cargue el archivo CSV preparado en su proyecto de Process Mining. Asigne las columnas del archivo a los campos correspondientes de ID del caso, nombre de la actividad y marca de tiempo en la configuración del modelo de datos de la herramienta.
Configuración
- Vistas CDS utilizadas: Las principales fuentes de datos son las vistas CDS estándar de SAP. Entre las vistas clave se encuentran
I_InvoiceDocumentpara los datos de cabecera,I_OperationalAcctgDocItempara los detalles de contabilización financiera y compensación, eI_ChangeDocumentjunto conI_ChangeDocumentItempara seguir los cambios históricos en atributos de facturas, como los bloqueos de pago y el estado del flujo de trabajo. - Filtrado por intervalo de fechas: Es fundamental filtrar los datos por un intervalo de fechas específico para controlar el rendimiento. La consulta proporcionada utiliza un marcador de posición para
CreationDateen la vistaI_InvoiceDocument. Se recomienda comenzar con datos de un período de 3 a 6 meses. - Filtro por código de sociedad: Para que la extracción sea pertinente y manejable, filtre siempre por uno o varios valores de
CompanyCode. La consulta incluye el marcador de posiciónWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')para este fin. - Filtro por tipo de documento: Puede delimitar aún más la extracción filtrando por
InvoiceDocumentType. Por ejemplo, puede incluir facturas estándar de proveedores (RE) y excluir notas de crédito. Puede añadir este filtro a la cláusulaWHEREde la CTE inicial. - Requisitos previos: El usuario que ejecute la consulta necesita autorizaciones de visualización adecuadas para los documentos financieros y de compras de los códigos de sociedad especificados. El acceso a la base de datos HANA subyacente mediante un cliente SQL no es estándar y requiere permisos especiales.
- Consideraciones de rendimiento: La extracción de datos de las tablas de documentos de modificación (
I_ChangeDocument,I_ChangeDocumentItem) puede exigir muchos recursos. Es esencial aplicar filtros estrictos por fecha, código de sociedad y clase de objeto (INCOMINGINVOICE) para evitar tiempos de ejecución prolongados.
Consulta de ejemplo sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Pasos
- Confirme que se haya aprobado el acceso de solo lectura directo al inquilino de SAP HANA o al esquema de la base de datos y obtenga un usuario de base de datos de solo lectura con autorización para acceder a las tablas SAP necesarias y a las tablas aprobadas de historial de cambios o de flujo de trabajo. Utilice SAP HANA Database Explorer, SAP HANA Studio o un cliente SQL aprobado. No utilice acceso de escritura en producción.
- Confirme los nombres físicos de las tablas y columnas en el sistema S/4HANA de destino. ACDOCA, BKPF y RBKP son puntos de partida estándar, pero los objetos de flujo de trabajo, registro provisional, propuesta de pago, ejecución de pagos, historial de cambios e historial de bloqueos de pago pueden variar según la versión o el cliente. Sustituya cada marcador de posición entre corchetes de la consulta por objetos verificados en el catálogo del sistema y que correspondan a la semántica empresarial pertinente.
- Defina el período de extracción con [Marca de tiempo inicial] y [Marca de tiempo final]. Extraiga un período suficientemente amplio de documentos y eventos, normalmente de tres a seis meses, y amplíelo si las fechas de vencimiento o los pagos atrasados pueden quedar fuera del período de creación de las facturas.
- Identifique los casos de factura mediante la clave de factura configurada. La consulta utiliza InvoiceNumber como identificador del caso y, cuando es necesario, lo combina internamente con el código de sociedad y el ejercicio fiscal para evitar duplicados. Confirme si la definición empresarial requiere incluir el ejercicio fiscal o el código de sociedad como clave adicional en el identificador del caso de ProcessMind.
- Asigne los datos de facturas contabilizadas de RBKP, BKPF y ACDOCA. Utilice RBKP para la información de cabecera de la factura, BKPF para las marcas de tiempo y los usuarios de los documentos contables, y ACDOCA para los datos disponibles de proveedores, importes, documentos de compra, compensación y contabilización de pagos. No dé por sentado que todos los campos se completan en todos los escenarios de contabilización.
- Asigne los eventos de registro provisional, aprobación, rechazo, actualización, bloqueo de pago, reversión, propuesta y ejecución de pagos a las fuentes verificadas específicas del sistema. Sustituya las vistas de origen de ejemplo por vistas o tablas aprobadas que expongan las marcas de tiempo de los eventos, las referencias de facturas, los usuarios, los estados y los valores anteriores y nuevos. Debe generar cada actividad como una fila de evento explícita, ya que ProcessMind no infiere eventos.
- Ejecute la consulta SQL completa en una sesión de solo lectura o en un entorno que no sea de producción. Revise los planes de ejecución y limite la consulta por código de sociedad, tipo de documento, ejercicio fiscal y marca de tiempo del evento cuando corresponda. Evite las uniones sin restricciones entre tablas grandes de diarios e historiales.
- Valide los resultados con las comprobaciones descritas a continuación. Confirme que estén presentes todas las columnas requeridas, que
EventTimetenga un valor para cada evento, queInvoiceNumbertenga un valor para cada caso y que aparezcan los 13 nombres de actividad cuando existan los datos de origen correspondientes. - Exporte los resultados como un archivo delimitado compatible con ProcessMind, preferiblemente CSV con codificación UTF-8, con una fila por evento y las columnas InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason y PurchasingDocument. Mantenga las marcas de tiempo en una zona horaria uniforme y conserve los ceros iniciales de los identificadores.
- Cargue el Registro de eventos en ProcessMind y configure InvoiceNumber como identificador del caso, ActivityName como columna de actividad y EventTime como columna de marca de tiempo. Si la configuración de ProcessMind admite claves de caso adicionales, aplique la misma política de clave compuesta que utilizó durante la extracción.
Configuración
- Intervalo de fechas: Para la extracción inicial, utilice un período móvil de tres a seis meses. Incluya más historial si los eventos de aprobación, pago, compensación, reversión o pago atrasado pueden producirse después del período de creación de la factura.
- Alcance de sociedades: Filtre por [Filtro de código de sociedad] y compruebe que las sociedades seleccionadas estén autorizadas para la extracción.
- Alcance de documentos: Filtre por [Filtro de tipo de documento] e incluya los tipos de documento que representan facturas de proveedores, notas de crédito, facturas registradas provisionalmente y reversiones en el proceso de destino.
- Identificador del caso: Utilice InvoiceNumber, tal como lo requiere la definición del proceso. Si los números de factura no son únicos a nivel global, conserve el código de sociedad y el ejercicio fiscal en los resultados de origen o configure una clave de caso compuesta según el modelo de ProcessMind.
- Fuentes de eventos: Verifique las fuentes físicas de los cambios de estado del flujo de trabajo, las decisiones de aprobación, el registro provisional, el historial de cambios, los bloqueos de pago, las propuestas de pago y la ejecución de pagos. Estas fuentes varían según la versión de S/4HANA, el alcance activado, el diseño del flujo de trabajo y las extensiones del cliente.
- Política de marcas de tiempo: Seleccione la marca de tiempo del evento empresarial, no la de extracción. Documente la zona horaria y convierta todas las marcas de tiempo de los eventos de manera uniforme antes de cargarlas.
- Política de importes: Utilice el importe en la moneda del código de sociedad y confirme si la fuente seleccionada almacena de forma coherente los signos de débito y crédito. No sume las líneas del diario a menos que se haya validado la regla de agregación para el caso de factura.
- Política de pagos: Defina si «Pago ejecutado» significa compensación, contabilización del documento de pago, ejecución bancaria u otro hito empresarial. Utilice la fuente que corresponda a la definición acordada del proceso.
- Pago atrasado: Genere «Pago atrasado ejecutado» solo cuando «Pago ejecutado» se produzca después de PaymentDueDate. La consulta calcula este evento de forma explícita y no depende de inferencias de ProcessMind.
- Rendimiento: Limite las lecturas de origen por fecha, código de sociedad, tipo de documento y ejercicio fiscal pertinente. Seleccione solo las columnas necesarias, revise los planes de consulta y materialice las vistas intermedias aprobadas si el historial de origen es extenso.
- Requisitos previos: Conectividad directa con SAP HANA, autorización de lectura para todos los objetos seleccionados, permiso para consultar metadatos y acceso a los datos pertinentes de cuentas por pagar, libro mayor, compras, flujo de trabajo y pagos. Confirme que estén vigentes las licencias de SAP necesarias, las políticas de acceso a la base de datos y las aprobaciones de protección de datos.
- Seguridad: Utilice un usuario técnico de solo lectura, proteja los datos de proveedores y pagos, y siga las políticas de transporte, auditoría, enmascaramiento y gestión de credenciales de la organización.
Consulta de ejemplo sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Pasos
- Acceda al editor ABAP: Inicie sesión en su sistema SAP S/4HANA. Abra la transacción
SE38(editor ABAP). - Cree el programa: Introduzca un nombre para el nuevo programa en el campo Programa, por ejemplo,
Z_PM_INVOICE_EXTRACT, y haga clic en el botón «Crear». Asígnele un título, establezca el tipo como «Programa ejecutable» y guárdelo en un paquete adecuado. - Defina la estructura del programa y la pantalla de selección: En el editor, defina las estructuras de datos para el resultado final del Registro de eventos. A continuación, cree una pantalla de selección que permita introducir parámetros como el intervalo de fechas de entrada de la factura, los códigos de sociedad y los tipos de documento. Así, el programa será reutilizable y flexible.
- Implemente la lógica de selección de datos: Escriba las instrucciones SQL de ABAP principales para seleccionar datos de las distintas tablas SAP. El programa consultará secuencialmente los datos de cada una de las 13 actividades requeridas.
- Extraiga los datos de cabecera y de posición: Para eventos básicos como «Documento de factura creado» y «Factura contabilizada», seleccione los datos de tablas principales como
RBKP(cabecera de factura logística) yBKPF(cabecera de documento contable). - Extraiga los datos de documentos de modificación: Para actividades como «Bloqueo de pago establecido» y «Bloqueo de pago eliminado», consulte las tablas de documentos de modificación
CDHDR(cabecera del documento de modificación) yCDPOS(posiciones del documento de modificación). Deberá identificar los cambios en campos específicos, por ejemplo,ZLSPRen la tablaBSEG. - Extraiga los datos de pago: Para registrar actividades relacionadas con pagos, consulte tablas como
REGUP(posiciones procesadas por el programa de pagos) para las propuestas de pago yBSAK(posiciones de proveedor compensadas) para los pagos ejecutados. Distinga «Pago atrasado ejecutado» comparando la fecha de compensación (AUGDT) con la fecha de vencimiento neta (ZFBDT). - Extraiga los datos del flujo de trabajo: Para las actividades de aprobación, consulte tablas de SAP Business Workflow como
SWW_WI2OBJpara vincular los elementos del flujo de trabajo con los objetos de factura. Esta parte depende en gran medida de la configuración específica del flujo de trabajo y puede requerir adaptaciones importantes. - Unifique los datos en el formato del Registro de eventos: Para cada actividad seleccionada, dé formato a los datos en una estructura de tabla interna común. Cada fila de esta tabla representa un evento y debe incluir el identificador del caso (
InvoiceNumber),ActivityNameyEventTime, además de otros atributos recomendados. - Genere el archivo de salida: Utilice las instrucciones ABAP
OPEN DATASET,TRANSFERyCLOSE DATASETpara escribir el contenido de la tabla interna final en un archivo plano del servidor de aplicaciones SAP. Se recomienda el formato CSV (valores separados por comas). - Programe y ejecute el programa: Ejecute el programa en primer plano para probarlo (con
F8). Para las ejecuciones en producción, prográmelo como un trabajo en segundo plano mediante la transacciónSM36, durante las horas de menor actividad, para evitar afectar el rendimiento del sistema. - Recupere el archivo y cárguelo: Utilice la transacción
AL11para acceder al directorio del servidor de aplicaciones donde se guardó el archivo. Descárguelo en su sistema local. Antes de cargarlo en la herramienta de Process Mining, asegúrese de que esté codificado en UTF-8 y tenga el formato correcto.
Configuración
- Intervalo de fechas: Defina un intervalo de fechas específico para la extracción según la fecha de entrada de la factura (
RBKP-CPUDT) o la fecha de contabilización (BKPF-BUDAT). Para el análisis inicial, se recomienda un período de 3 a 6 meses, a fin de mantener un volumen de datos manejable. - Código de sociedad (BUKRS): Es fundamental filtrar por uno o varios códigos de sociedad. Extraer datos de todos los códigos de sociedad de una organización grande puede generar tiempos de ejecución muy prolongados y archivos de gran tamaño.
- Tipo de documento (BLART): Filtre por los tipos de documento pertinentes para aislar las facturas de proveedores. Entre los tipos habituales se incluyen «RE» (factura, importe bruto) y «KR» (factura de proveedor). Esto permite excluir del análisis los documentos que no son pertinentes.
- Cuenta del proveedor (LIFNR): El programa puede incluir un filtro opcional para números de proveedor específicos, útil para realizar análisis dirigidos o pruebas.
- Configuración del archivo de salida: El programa debe incluir parámetros para definir la ruta del archivo de salida en el servidor de aplicaciones y el delimitador de campos, por ejemplo, una coma o un punto y coma.
- Requisitos previos: El usuario o la cuenta del sistema que ejecute este programa necesita acceso de desarrollo para crear y ejecutar programas ABAP (mediante
SE38), así como amplias autorizaciones de lectura para las tablas de FI, MM y Basis, incluidasBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSy las tablas del flujo de trabajo.
Consulta de ejemplo abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. ¿Listo para comenzar?
Comience hoy mismo a optimizar el procesamiento de facturas. Este Template es el primer paso para lograr mejoras operativas importantes y una mayor eficiencia.
Optimice ahora el procesamiento de facturas P2P en SAP S/4HANA
Localice cuellos de botella y reduzca un 30 % o más el tiempo del ciclo de las facturas.
No se requiere tarjeta de crédito. Configuración en minutos.