Su Template de datos de Purchase to Pay: procesamiento de facturas
Su Template de datos de Purchase to Pay: procesamiento de facturas
- Atributos recomendados para recopilar
- Actividades clave que debe supervisar
- Guía de extracción para SAP S/4HANA
Purchase to Pay - Atributos del procesamiento de facturas
| Nombre | Descripción | ||
|---|---|---|---|
| Número de factura InvoiceNumber | El identificador único del documento de factura del proveedor, que actúa como identificador principal del caso en el proceso. | ||
| Descripción El número de factura es el identificador único asignado 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 de proceso coherente. En Process Mining, este atributo es fundamental para realizar el 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 a nivel de cada factura. Por qué es importante Es la clave esencial para conectar todos los eventos relacionados y permitir un seguimiento completo del ciclo de vida de una factura en el sistema. Dónde obtenerlo Es el número del documento contable, que se encuentra en la tabla BKPF, campo BELNR. Ejemplos 190000000119000000451900000132 | |||
| Hora del evento EventTime | La fecha y hora exactas en que tuvo lugar la actividad. | ||
| Descripción La hora del evento es la marca de tiempo que registra exactamente cuándo ocurrió 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 se utilizan para medir KPI de rendimiento como «Tiempo medio del ciclo de la factura» y «Tiempo del ciclo de aprobación de la factura». Al analizar el tiempo transcurrido entre actividades, las organizaciones pueden localizar cuellos de botella en los que las facturas se retrasan e identificar oportunidades para acelerar el proceso. Por qué es importante Esta marca de tiempo es la base de todos los análisis basados en el tiempo, incluidos la supervisión del rendimiento, la identificación de cuellos de botella y el seguimiento de SLA. Dónde obtenerlo Normalmente procede 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 introducción 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 | El nombre de la actividad empresarial o del evento que tuvo lugar en un momento concreto para una factura. | ||
| Descripción El nombre de la actividad describe un paso específico o un cambio de estado dentro del ciclo de vida del procesamiento de una factura. Algunos ejemplos son «Documento de factura creado», «Factura enviada para aprobación», «Bloqueo de pago establecido» y «Pago ejecutado». Este atributo es crucial para construir 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 retrabajo y variaciones del proceso que no cumplen las normas. Constituye la base de cualquier análisis de Process Mining. Por qué es importante Define los pasos del proceso, lo que permite visualizar los mapas de proceso y analizar los flujos y las variaciones del proceso. Dónde obtenerlo Se deriva 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 | La fecha en la que debe pagarse la factura para evitar que quede vencida. | ||
| Descripción La fecha de vencimiento del pago es la fecha calculada en la que debe realizarse el pago al proveedor, según la fecha de la factura y las condiciones de pago acordadas. Constituye un plazo crítico del proceso. Este atributo es esencial para el KPI «Tasa de pagos puntuales» y el Dashboard «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 el principal punto de referencia para medir el rendimiento de los pagos puntuales, algo crucial para mantener buenas relaciones con los proveedores y evitar recargos 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 el cálculo del vencimiento). La fecha neta de vencimiento se calcula a partir de esta fecha base y de las condiciones de pago. Ejemplos 2023-05-302023-06-152023-07-01 | |||
| Importe de la factura AmountInCompanyCodeCurrency | El importe bruto total de la factura en la moneda local de la sociedad. | ||
| Descripción Este atributo representa el valor total de la factura. Es una métrica clave para comprender el impacto financiero y la escala de la operación de procesamiento de facturas. Analizar los importes de las facturas ayuda a priorizar las facturas de alto valor para procesarlas más rápidamente, identificar tendencias de gasto y relacionar los problemas del proceso con el valor financiero. Por ejemplo, permite investigar si las facturas de alto valor tienen más probabilidades de bloquearse o de presentar tiempos de aprobación más largos. Por qué es importante Proporciona contexto financiero al proceso y permite analizarlo según el valor monetario, por ejemplo, para identificar si las facturas de alto valor se procesan de forma diferente. Dónde obtenerlo Este valor suele derivarse de la suma de las partidas relevantes de la tabla BSEG, campo WRBTR (importe en moneda local). Ejemplos 1500.75125000.00850.20 | |||
| Motivo del bloqueo de pago PaymentBlockReason | Un código que indica por qué una factura está bloqueada para el pago. | ||
| Descripción Cuando una factura se bloquea para el pago, este atributo proporciona el motivo específico del bloqueo, como «Discrepancia de cantidad» o «Diferencia de precio». Estos motivos se configuran en SAP para estandarizar la gestión de excepciones. Este atributo es crucial para el Dashboard «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 relacionados con determinados proveedores, materiales o procesos internos, y permite aplicar medidas correctivas específicas. Por qué es importante Proporciona la causa raíz específica de los bloqueos de pago, lo que permite realizar análisis específicos 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 | El ID de usuario de SAP de la persona o el sistema que realizó la actividad. | ||
| Descripción Este atributo identifica al usuario que ejecutó una transacción concreta o creó un documento. Puede ser el ID de una persona o el ID de un sistema para trabajos por lotes automatizados. Analizar los datos por usuario ayuda a comprender la distribución de la carga de trabajo, identificar necesidades de formación y detectar comportamientos inusuales. Por ejemplo, puede mostrar qué usuarios gestionan excepciones con frecuencia o qué facturas se procesan automáticamente, como las gestionadas por el usuario «BATCHUSER», algo clave para calcular el KPI «Tasa de automatización de facturas». Por qué es importante Asigna las actividades del proceso a usuarios o cuentas del sistema concretos, lo que permite analizar la carga de trabajo, comparar el rendimiento y detectar la automatización. Dónde obtenerlo Procede de campos como BKPF-USNAM (introducido por) o CDHDR-USERNAME (modificado por). Ejemplos SMITHJMUELLERTWF-BATCH | |||
| Número de proveedor VendorNumber | El identificador único del proveedor que presentó la factura. | ||
| Descripción El número de proveedor identifica al proveedor o acreedor asociado a la factura. Vincula la transacción de la factura con los datos maestros del proveedor. Este atributo es fundamental para el análisis centrado en proveedores, como la evaluación del «Rendimiento de los pagos a proveedores» o la identificación de proveedores que presentan con frecuencia facturas problemáticas que generan excepciones o bloqueos de pago. Ayuda a gestionar las relaciones con los proveedores y evaluar su fiabilidad. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, identificar patrones, gestionar relaciones y evaluar problemas relacionados con los proveedores. Dónde obtenerlo Normalmente se encuentra en la tabla de segmentos de documentos contables BSEG, campo LIFNR. Ejemplos 100345700012V9832 | |||
| Pedido de compra PurchasingDocument | El número del pedido de compra al que está relacionada la factura. | ||
| Descripción El número del documento de compras vincula la factura del proveedor con el pedido de compra original (PO). Este vínculo es fundamental para el proceso de cotejo de 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 respaldadas por pedidos de compra frente a las facturas sin pedido. Es clave para investigar discrepancias de cotejo y comprender 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 las discrepancias de cotejo y el cumplimiento de los pedidos de compra. Dónde obtenerlo Esta información suele encontrarse en la tabla de segmentos de documentos BSEG, campo EBELN (número del documento de compras). Ejemplos 450000123445000056784500009012 | |||
| Sociedad CompanyCode | La unidad organizativa que representa a 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 concreta, 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 del proceso entre distintas unidades de negocio, entidades jurídicas o países. Ayuda a identificar diferencias regionales en eficiencia, cumplimiento y niveles de automatización, y facilita iniciativas de mejora específicas. 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 | Un código que clasifica distintos tipos de documentos contables, como facturas de proveedores o notas de crédito. | ||
| Descripción El tipo de documento se utiliza en SAP para distinguir entre distintas transacciones empresariales. Por ejemplo, «KR» suele representar una factura estándar de proveedor, mientras que «KG» puede representar una nota de crédito de proveedor. Analizar 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 ser muy diferente del de una factura estándar. Esta segmentación proporciona insights del proceso más precisos y relevantes. Por qué es importante Ayuda a diferenciar varios tipos de transacciones financieras, como facturas estándar y notas de crédito, que a menudo siguen 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 | El 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 descuentos disponibles por pronto pago. Por ejemplo, «Z030» podría significar «pagadero en un plazo neto de 30 días». Este atributo es esencial para la planificación financiera y la optimización del capital circulante. En Process Mining, se utiliza para calcular la «Fecha de vencimiento del pago» y determinar la elegibilidad para descuentos por pronto pago, y respalda directamente el KPI «Tasa de captación de descuentos por pronto pago». Por qué es importante Define las reglas de las fechas de vencimiento y los descuentos, e influye directamente en los KPI de pagos puntuales y en la gestión del capital circulante. 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 | Un indicador que señala si una actividad fue realizada por un usuario del 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 entre pasos manuales y automatizados del proceso. Este atributo es esencial para calcular el KPI «Tasa de automatización de facturas». Al analizar qué partes del proceso están automatizadas, las organizaciones pueden medir el éxito de sus iniciativas de automatización e identificar nuevas oportunidades para reducir el esfuerzo manual y mejorar la eficiencia. Por qué es importante Distingue entre actividades manuales y actividades impulsadas por el sistema, algo fundamental para medir las tasas de automatización e identificar oportunidades de automatización adicional. Dónde obtenerlo Se deriva del atributo UserName. Se crea una asignación o regla para clasificar determinados ID de usuario como «automatizados». Ejemplos truefalse | |||
| Es retrabajo IsRework | Un indicador que señala si una factura ha pasado por actividades de retrabajo, como una aprobación rechazada o la eliminación de un bloqueo de pago. | ||
| Descripción Este atributo marca las facturas que han experimentado uno o más ciclos de retrabajo. El retrabajo se identifica mediante secuencias específicas de actividades, por ejemplo, «Factura aprobada» después de «Factura rechazada» o «Bloqueo de pago eliminado» después de «Bloqueo de pago establecido». Este atributo simplifica el cálculo del KPI «Tasa de retrabajo de facturas». Permite a los analistas aislar e investigar fácilmente los casos con retrabajo para comprender las causas raíz de la ineficiencia y del esfuerzo manual repetido. Por qué es importante Identifica flujos de proceso ineficientes en los que es necesario 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 seguimiento de una factura, este indicador se establece como verdadero. Ejemplos truefalse | |||
| Fecha de la factura InvoiceDate | La fecha en la que el proveedor emitió el documento de factura. | ||
| Descripción La fecha de la factura, también conocida como fecha del documento, es la fecha que el proveedor indica en la factura. Se utiliza como punto de partida para calcular la fecha de vencimiento del pago según las condiciones de pago acordadas. En el análisis, esta fecha es fundamental para los cálculos financieros, como determinar la antigüedad de las facturas y su elegibilidad para descuentos por pronto pago. Es un dato clave para el KPI «Tasa de captación de descuentos por pronto pago». Por qué es importante Sirve de base para calcular las condiciones de pago y las fechas de vencimiento, algo esencial para gestionar el capital circulante 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 | El 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 heredados y modernos. Para el análisis, permite comparar el rendimiento del proceso entre distintos sistemas o regiones. Garantiza la procedencia 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 Proporciona contexto sobre 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 derivarse 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 | La fecha y hora en que se extrajeron los datos del sistema de origen. | ||
| Descripción Este atributo registra la marca de tiempo del evento de extracción de datos. Refleja la actualidad de los datos que se analizan en la herramienta de Process Mining. En el análisis, se utiliza para comprender la actualidad de las conclusiones generadas. Es fundamental para los Dashboards de supervisión operativa, ya que garantiza que las decisiones se basen en información actualizada y permite gestionar eficazmente los ciclos de actualización de datos. Por qué es importante Indica la actualidad de 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 en el momento de extraer los datos. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Motivo de la anulación ReversalReason | Un código que indica por qué se anuló un documento de factura. | ||
| Descripción Si una factura se contabiliza incorrectamente, a menudo se anula. El código de motivo de la anulación explica por qué se realizó esta acción, por ejemplo, «Fecha de contabilización incorrecta» o «Error de introducción de datos». Analizar los motivos de anulación ayuda a identificar patrones de errores en el proceso de contabilización de facturas. Estos insights pueden utilizarse para mejorar la formación, reforzar los controles del sistema o abordar problemas recurrentes que generan retrabajo financiero y sobrecarga administrativa. Por qué es importante Explica por qué se cancelaron las facturas y proporciona información directa sobre las fuentes de errores y retrabajo en el proceso de contabilización. Dónde obtenerlo Se encuentra en la cabecera del documento original, en la tabla BKPF, campo STGRD (motivo de la anulación). Ejemplos 010205 | |||
| N.º de documento de compensación. ClearingDocumentNumber | El número del documento que compensa la factura, normalmente el 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 es 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 del ciclo de extremo a extremo y la tasa de pagos puntuales. Por qué es importante Confirma que una factura se ha pagado y la vincula con la transacción de pago específica, algo fundamental para analizar el tiempo de ciclo y el rendimiento de los pagos. Dónde obtenerlo Se encuentra en la tabla de segmentos de documentos BSEG, campo AUGBL (número del documento de compensación). Ejemplos 150000000115000000231500000088 | |||
| Número de ciclos de aprobación ApprovalCycleCount | El número de veces que una factura se envió para aprobación. | ||
| Descripción Esta métrica cuenta cuántas veces aparece la actividad «Factura enviada para aprobación» para una misma factura. Un número superior a uno indica que la factura se rechazó o se devolvió al menos una vez y requirió un nuevo ciclo de aprobación. Este atributo respalda directamente el KPI «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 las aprobaciones fallidas, como información insuficiente o codificación incorrecta, y tomar medidas para mejorar el proceso. Por qué es importante Cuantifica el retrabajo dentro del subproceso de aprobación, lo que ayuda a medir la tasa de resultados correctos al primer intento e identificar los motivos de los rechazos de aprobación. Dónde obtenerlo Se calcula contando las apariciones de la actividad «Factura enviada para aprobación» para cada InvoiceNumber único. Ejemplos 123 | |||
| Pagada a tiempo IsPaidOnTime | Un indicador que es verdadero si la factura se pagó en la fecha de vencimiento o antes. | ||
| Descripción Este atributo booleano resulta de comparar la fecha real de pago, es decir, la marca de tiempo de la actividad «Pago ejecutado», con la «Fecha de vencimiento del pago». Proporciona un resultado binario claro para el estado de pago de cada factura. Este es el cálculo principal del KPI «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 crítico para la gestión de las relaciones con los proveedores y las operaciones financieras. Dónde obtenerlo Se calcula comparando EventTime de la actividad «Pago ejecutado» con el atributo PaymentDueDate. (Payment Date <= PaymentDueDate). Ejemplos truefalse | |||
Purchase to Pay - Actividades de 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 capturarse cuando una persona usuaria guarda un documento de factura nuevo, que puede encontrarse en estado aparcado o contabilizado previamente. | ||
| Por qué es importante Esta actividad marca el inicio del ciclo de vida del procesamiento de la factura. Analizar el tiempo transcurrido desde este evento hasta otros resulta fundamental para medir el plazo total de procesamiento. Dónde obtenerlo Este evento se captura a partir de la fecha y hora de creación (CPUDT, CPUTM) de la tabla de cabecera del documento, normalmente BKPF o RBKP para facturas logísticas. El código de transacción (BKPF-TCODE), como FB60, MIRO o MIR7, indica el método de creación. Recopilar Utilice la marca de tiempo 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. Este es un evento terminal para una factura incorrecta, que a menudo se vuelve a introducir correctamente. | ||
| 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 sus causas raíz es esencial para mejorar el proceso y reducir las imprecisiones financieras. Dónde obtenerlo Una 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. Recopilar Identificar los documentos que tienen un valor en el campo BKPF-STBLG y utilizar 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 captura cuando el Workflow de aprobación finaliza correctamente o se establece un indicador de liberación. | ||
| Por qué es importante Este es un hito crítico que desbloquea la factura para el pago. Los retrasos en las aprobaciones son un cuello de botella habitual, y hacer un seguimiento de esta actividad ayuda a localizar a las personas aprobadoras o los pasos del proceso que ralentizan el flujo. Dónde obtenerlo Puede inferirse a partir del paso final de liberación en un Workflow 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. Recopilar Infiera este evento a partir de los eventos de finalización del Workflow 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 en el que 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 separa la introducción y aprobación de datos de la fase de liquidación financiera. El tiempo transcurrido desde la creación de la factura hasta su contabilización es una medida 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. En los documentos que primero se aparcan, la transición al estado contabilizado proporciona la marca de tiempo del evento. Recopilar Utilizar la fecha de contabilización (BKPF-BUDAT) como marca de tiempo del evento. Tipo de evento explicit | |||
| Pago ejecutado | Esta es la actividad final del proceso estándar, en la que se realiza el pago y se compensa la factura. Esto indica que los fondos se han desembolsado al proveedor. | ||
| Por qué es importante Esto marca el final del ciclo de vida de la factura P2P. Es esencial para calcular el tiempo total del ciclo de extremo a extremo y medir el cumplimiento de los pagos puntuales con respecto a la fecha de vencimiento. Dónde obtenerlo Este evento se captura a partir de la información del documento de compensación de 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. Recopilar Utilizar la fecha de compensación (BSEG-AUGDT) de la partida compensada del proveedor. Tipo de evento explicit | |||
| Bloqueo de pago eliminado | Representa la resolución de un problema: se elimina un bloqueo de pago establecido anteriormente y la factura vuelve a ser apta para el pago. | ||
| Por qué es importante El tiempo transcurrido entre la aplicación y la eliminación de un bloqueo representa el tiempo de resolución de una excepción del proceso. Reducir esta duración es clave para mejorar la eficiencia y las relaciones con los proveedores. Dónde obtenerlo Este evento se registra cuando se borra el campo Payment Block Key (BSEG-ZLSPR). Este cambio queda registrado en las tablas CDHDR y CDPOS, que proporcionan una marca de tiempo para la eliminación. Recopilar Identificar cuándo se borra el campo BSEG-ZLSPR mediante los documentos de modificación (CDHDR/CDPOS). Tipo de evento explicit | |||
| Bloqueo de pago establecido | Actividad mediante la que se aplica intencionadamente un bloqueo a una factura para impedir su pago. Esto suele deberse a discrepancias en el precio o la cantidad, o a una nota de crédito pendiente. | ||
| Por qué es importante Los bloqueos de pago son una de las principales causas de pagos atrasados y disputas con proveedores. Analizar su frecuencia, duración y causas es fundamental para mejorar las tasas de pago puntual. Dónde obtenerlo Este evento se captura mediante el seguimiento de los cambios en el campo clave de bloqueo de pago (BSEG-ZLSPR) de la posición de la factura. Los registros de cambios de CDHDR y CDPOS proporcionan la marca de tiempo y la persona usuaria correspondientes al momento en que se estableció el bloqueo. Recopilar Identifique cuándo se rellena el campo BSEG-ZLSPR mediante los documentos de modificación (CDHDR/CDPOS). Tipo de evento explicit | |||
| Datos de factura actualizados | Esta actividad refleja un cambio realizado en el documento de factura después de su creación inicial. 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 punto de 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, de cabecera, y CDPOS, de posición. Pueden generarse eventos filtrando los cambios del objeto de factura correspondiente. Recopilar Extraiga los eventos de modificación de las tablas CDHDR y CDPOS para el objeto de factura. Tipo de evento explicit | |||
| Factura aparcada | Representa una factura introducida en el sistema, pero que todavía no se ha contabilizado en el libro mayor. El aparcamiento se utiliza para guardar facturas incompletas o revisarlas posteriormente 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 los retrasos 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 comprobando campos de estado específicos en la tabla BKPF o en tablas específicas de documentos aparcados, como VBKPF. Recopilar 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 de un Workflow formal de aprobación de la factura. A menudo se infiere cuando el estado de la factura cambia a «pendiente de aprobación» o se genera un elemento de Workflow. | ||
| Por qué es importante Este es el punto de partida para medir el tiempo del ciclo de aprobación. Comprender cuándo comienzan las aprobaciones es esencial para identificar cuellos de botella en el propio Workflow de aprobación. Dónde obtenerlo Normalmente se infiere a partir del inicio de un SAP Business Workflow, en la tabla SWW_WI2OBJ, vinculado al objeto de la factura, como BUS2081, o de un cambio en un campo de estado personalizado de la cabecera del documento. Recopilar Infiera este evento a partir de la creación de un elemento de Workflow relacionado con el documento de factura. Tipo de evento inferred | |||
| Factura rechazada | Representa el rechazo de una factura durante el proceso de aprobación. Este evento activa un retrabajo que requiere corregir y volver a enviar la factura. | ||
| Por qué es importante Los rechazos de facturas son un indicador clave de ineficiencias del proceso y problemas de calidad de los datos. Analizar la frecuencia y las causas de los rechazos ayuda a identificar oportunidades de mejora y necesidades de formación. Dónde obtenerlo Se infiere a partir de actualizaciones de estado específicas en un Workflow de SAP, como un estado «rechazado», o de eventos que cancelan el Workflow de aprobación actual y devuelven la factura a la persona encargada de procesarla. Recopilar Infiera este evento a partir de cambios en el estado del Workflow que indiquen un rechazo. Tipo de evento inferred | |||
| Pago atrasado ejecutado | Este es un evento calculado que 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 respalda directamente 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. La fecha de vencimiento se calcula a partir de la fecha base (BSEG-ZFBDT) y las condiciones de pago (BSEG-ZTERM). Recopilar Derivar comparando BSEG-AUGDT > (BSEG-ZFBDT + días de las condiciones 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 el proceso de 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, concretamente 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. Recopilar Identificar 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 autorización: Asegúrese de que el usuario que ejecuta la extracción tenga las autorizaciones necesarias en SAP S/4HANA para acceder a las vistas Core Data Services (CDS) requeridas. Entre las vistas clave se incluyen
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_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 la extracción, por ejemplo,
CreationDateentre'YYYY-MM-DD'y'YYYY-MM-DD'. Identifique también los valores específicos deCompanyCodeque desea incluir para limitar el alcance de la extracción. - Personalice la consulta SQL: Copie la consulta SQL proporcionada en el cliente SQL o la herramienta de extracción que haya elegido. Revise cuidadosamente los marcadores de posición, como
'{StartDate}','{EndDate}'y('{CompanyCode1}', '{CompanyCode2}'). Sustituya estos marcadores por los valores reales que definió en el paso anterior. También puede ser necesario ajustar los nombres de los campos del estado del Workflow 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 mediante la capa de servicios correspondiente. La consulta está diseñada para ser exhaustiva y puede tardar bastante en ejecutarse, según el volumen de datos y el intervalo de fechas seleccionado. Supervise la ejecución para detectar posibles errores o tiempos de espera agotados.
- Revise los resultados iniciales: Cuando finalice la consulta, revise rápidamente los resultados. Compruebe que las columnas
InvoiceNumber,ActivityNameyEventTimeestén completas. Verifique que la columnaActivityNamecontenga distintas actividades y no solo «Invoice Document Created». - Gestione la transformación de datos: La consulta está estructurada para producir un formato de registro de eventos limpio. No obstante, asegúrese de que la columna
EventTimeutilice un formato de marca de tiempo coherente, comoYYYY-MM-DDTHH:MM:SS. La consulta proporcionada combina los campos de fecha y hora en una sola marca de tiempo cuando es necesario. - Exporte los datos: Exporte el conjunto de resultados final desde su herramienta a un archivo CSV (valores separados por comas). Este formato es compatible de forma universal con las herramientas de Process Mining, incluido ProcessMind.
- Prepárese para la carga: Antes de cargar el archivo, confirme que utiliza codificación UTF-8 para evitar problemas con los caracteres. Asegúrese de que los encabezados de columna 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 de caso, nombre de actividad y marca de tiempo en la configuración del modelo de datos de la herramienta.
Configuración
- Vistas CDS utilizadas: Las principales fuentes de datos son vistas CDS estándar de SAP. Las vistas clave son
I_InvoiceDocumentpara los datos de cabecera,I_OperationalAcctgDocItempara los detalles de contabilización y compensación financiera, eI_ChangeDocumentjunto conI_ChangeDocumentItempara realizar el seguimiento de los cambios históricos en atributos de las facturas, como los bloqueos de pago y el estado del Workflow. - 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 un periodo de datos de 3 a 6 meses. - Filtro por código de empresa: Para garantizar 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 acotar 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. Este filtro puede añadirse a la cláusulaWHEREdel 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 empresa 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 empresa y clase de objeto (INCOMINGINVOICE) para evitar tiempos de ejecución prolongados.
a Consulta de ejemplo sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Pasos
- Confirme que el acceso directo de lectura al tenant o esquema de base de datos de SAP HANA está aprobado y obtenga un usuario de base de datos de solo lectura con autorización para las tablas SAP necesarias y para cualquier tabla aprobada de historial de cambios o Workflow. 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 Workflow, aparcamiento, propuesta de pago, ejecución de pagos, historial de cambios e historial de bloqueos de pago pueden variar según la versión o la personalización del cliente. Sustituya cada marcador entre corchetes de la consulta por objetos verificados en el catálogo del sistema y por los objetos que correspondan a la semántica empresarial.
- Defina el periodo de extracción mediante [Marca de tiempo inicial] y [Marca de tiempo final]. Extraiga un periodo de documentos y eventos suficientemente amplio, normalmente de tres a seis meses, y amplíelo cuando las fechas de vencimiento o los pagos atrasados puedan quedar fuera del periodo de creación de la factura.
- Identifique los casos de factura mediante la clave de factura configurada. La consulta utiliza InvoiceNumber como identificador del caso y lo combina internamente con el código de empresa y el ejercicio fiscal cuando es necesario para evitar colisiones. Confirme si la definición empresarial requiere añadir el ejercicio fiscal o el código de empresa al identificador de caso de ProcessMind.
- Asigne los datos de facturas contabilizadas desde RBKP, BKPF y ACDOCA. Utilice RBKP para la información de cabecera de la factura, BKPF para las marcas de tiempo y los usuarios del documento contable, y ACDOCA para el proveedor, el importe, el documento de compras, la compensación y la información contable relacionada con el pago, cuando esté disponible. No dé por hecho que todos los campos estarán completos en todos los escenarios de contabilización.
- Asigne los eventos de facturas aparcadas, aprobaciones, rechazos, actualizaciones, bloqueos de pago, propuestas y ejecuciones de pago desde las fuentes verificadas del sistema. Sustituya las vistas o tablas de origen de marcador de posición por vistas o tablas aprobadas que expongan las marcas de tiempo de los eventos, las referencias de factura, los usuarios, los estados y los valores anteriores y nuevos. Cada actividad debe emitirse como una fila de evento explícita, ya que ProcessMind no infiere eventos.
- Ejecute la consulta SQL completa en una sesión de no producción o de solo lectura. Revise los planes de ejecución y limite la consulta por código de empresa, 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 el resultado mediante las comprobaciones descritas a continuación. Confirme que todas las columnas obligatorias estén presentes, que EventTime tenga un valor para cada evento, que InvoiceNumber tenga un valor para cada caso y que aparezcan los 13 nombres de actividad cuando existan datos de origen correspondientes.
- Exporte el resultado como un archivo delimitado compatible con ProcessMind, preferiblemente un 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 coherente 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, utilice la misma política de clave compuesta aplicada durante la extracción.
Configuración
- Intervalo de fechas: Utilice un periodo móvil de tres a seis meses para la extracción inicial. Incluya historial adicional cuando los eventos de aprobación, pago, compensación, reversión o pago atrasado puedan producirse después del periodo de creación de la factura.
- Alcance de empresas: Filtre por [filtro de código de empresa] y valide que los códigos de empresa seleccionados estén autorizados para la extracción.
- Alcance de documentos: Filtre por [filtro de tipo de documento] e incluya los tipos de documento que representen facturas de proveedores, notas de crédito, facturas aparcadas y reversiones en el proceso de destino.
- Identificador del caso: Utilice InvoiceNumber según lo requiera la definición del proceso. Cuando los números de factura no sean únicos globalmente, conserve el código de empresa y el ejercicio fiscal en el resultado 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 Workflow, las decisiones de aprobación, el aparcamiento, 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 Workflow 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 eventos de forma coherente antes de cargarlas.
- Política de importes: Utilice el importe en la moneda del código de empresa y confirme si la fuente seleccionada almacena de forma coherente los signos de débito y crédito. Evite sumar líneas del diario salvo que se haya validado la regla de agregación para el caso de factura.
- Política de pagos: Defina si Payment Executed significa compensación, contabilización del documento de pago, ejecución bancaria u otro hito empresarial. Utilice la fuente que coincida con la definición acordada del proceso.
- Pago atrasado: Emita Late Payment Executed solo cuando Payment Executed se produzca después de PaymentDueDate. La consulta calcula este evento explícitamente y no depende de una inferencia de ProcessMind.
- Rendimiento: Limite las lecturas de las fuentes por fecha, código de empresa, 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 grande.
- Requisitos previos: Conectividad directa con SAP HANA, autorización de lectura para todos los objetos seleccionados, permiso para inspeccionar metadatos y acceso a los datos pertinentes de Cuentas por pagar, Libro mayor, compras, Workflow y pagos. Confirme que estén vigentes las licencias 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 su organización.
a 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». Proporcione un título, establezca el tipo como «Programa ejecutable» y guárdelo en el paquete correspondiente. - 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 empresa y los tipos de documento. Esto hará que el programa sea 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 cada una de las 13 actividades requeridas.
- Extraiga los datos de cabecera y posición: Para eventos fundamentales como «Invoice Document Created» e «Invoice Posted», seleccione datos de tablas principales como
RBKP(cabecera de factura logística) yBKPF(cabecera del documento contable). - Extraiga los datos de documentos de modificación: Para actividades como «Payment Block Set» y «Payment Block Removed», 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 pagos: Para capturar actividades relacionadas con pagos, consulte tablas como
REGUP(posiciones procesadas del programa de pagos) para las propuestas de pago yBSAK(posiciones de proveedores compensadas) para los pagos ejecutados. Diferencie «Late Payment Executed» comparando la fecha de compensación (AUGDT) con la fecha neta de vencimiento (ZFBDT). - Extraiga los datos del Workflow: Para las actividades de aprobación, consulte tablas de SAP Business Workflow como
SWW_WI2OBJpara vincular los elementos de Workflow con los objetos de factura. Esta parte depende en gran medida de su configuración específica de Workflow y puede requerir una adaptación considerable. - Unifique los datos en formato de 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 único evento y debe contener el identificador del caso (
InvoiceNumber),ActivityNameyEventTime, junto con 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. - Programe y ejecute: Ejecute el programa en primer plano para realizar pruebas mediante
F8. Para las ejecuciones de producción, prográmelo como un trabajo en segundo plano mediante la transacciónSM36, durante horas de baja actividad para evitar afectar al rendimiento del sistema. - Recupere y cargue el archivo: Utilice la transacción
AL11para acceder al directorio del servidor de aplicaciones donde se guardó el archivo. Descárguelo en su sistema local. Asegúrese de que el archivo esté codificado en UTF-8 y tenga el formato correcto antes de cargarlo en la herramienta de Process Mining.
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 periodo de 3 a 6 meses a fin de mantener un volumen de datos manejable. - Código de empresa (BUKRS): Es fundamental filtrar por uno o varios códigos de empresa. Extraer datos de todos los códigos de empresa de una organización grande puede generar tiempos de ejecución extremadamente largos 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 ayuda a excluir documentos irrelevantes del análisis.
- Cuenta del proveedor (LIFNR): El programa puede incluir un filtro opcional para números de proveedor específicos, útil para 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 desarrollador para crear y ejecutar programas ABAP mediante
SE38, además de amplias autorizaciones de lectura para las tablas FI, MM y Basis, incluidasBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSy las tablas de Workflow.
a Consulta de ejemplo abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. ¿Listo para comenzar?
Comience hoy mismo a optimizar el procesamiento de sus facturas. Este Template es el primer paso para lograr mejoras operativas significativas y una mayor eficiencia.
Optimice ahora el procesamiento de facturas P2P en SAP S/4HANA
Localice cuellos de botella y reduzca en un 30 % o más el tiempo del ciclo de las facturas.
No se requiere tarjeta de crédito. Configuración en minutos.