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 seguir
- Guía de extracción para SAP ECC
Purchase to Pay - Atributos del procesamiento de facturas
| Nombre | Descripción | ||
|---|---|---|---|
| Actividad Activity | El nombre de un paso de negocio específico o de un evento que tuvo lugar durante el ciclo de vida del procesamiento de facturas. | ||
| Descripción El atributo Activity representa una etapa o acción diferenciada dentro del Workflow de procesamiento de facturas. Estas actividades se derivan de diversos eventos del sistema, como la creación de documentos, los cambios de estado, las aprobaciones o las acciones de usuarios registradas en los registros de cambios de SAP. El análisis de las actividades es el núcleo del Process Mining. Permite visualizar mapas de procesos, identificar cuellos de botella, por ejemplo, largas esperas después de «Invoice Sent For Approval», detectar ciclos de retrabajo, como repeticiones de «Payment Block Set» y «Payment Block Released», y encontrar desviaciones de cumplimiento. La secuencia y la frecuencia de las actividades revelan el flujo real del proceso, tal como se ejecuta. Por qué es importante Define los pasos del mapa de procesos, lo que permite visualizar los flujos de proceso, descubrir cuellos de botella e identificar retrabajos. Dónde obtenerlo Este atributo suele derivarse de varias fuentes, incluidos los códigos de transacción (SY-TCODE), los campos de estado de tablas como RBKP, por ejemplo, RBSTAT, y los eventos de cambio de las tablas CDHDR y CDPOS. Ejemplos Factura aparcadaFactura enviada para aprobaciónFactura aprobadaFactura contabilizadaFactura compensada | |||
| Hora del evento EventTime | La marca de tiempo exacta, incluida la fecha y la hora, en la que tuvo lugar una actividad. | ||
| Descripción Event Time registra el momento exacto en que se ejecutó y registró una actividad empresarial en el sistema de origen. Esta marca de tiempo constituye la base cronológica del proceso, ya que ordena todas las actividades de cada factura en una secuencia coherente. En el análisis, Event Time es esencial para calcular todas las métricas basadas en la duración, como los tiempos de ciclo, los tiempos de espera y los tiempos de procesamiento entre actividades. Permite crear Dashboards como «Invoice End-to-End Cycle Time» y «Payment Block Resolution Duration», ya que proporciona los datos necesarios para medir el tiempo transcurrido entre dos puntos del proceso. Las marcas de tiempo precisas son fundamentales para identificar retrasos y cuellos de botella de rendimiento. Por qué es importante Esta marca de tiempo es esencial para ordenar correctamente los eventos y calcular todas las métricas de rendimiento, como los tiempos de ciclo y la duración de los cuellos de botella. Dónde obtenerlo Normalmente se obtiene combinando la fecha de cambio (UDATE) y la hora de cambio (UTIME) de la tabla de cabecera de documentos de cambio, CDHDR. Para eventos de creación específicos, puede corresponder a la fecha y hora de creación de tablas como RBKP (ERNAM, ERZET). Ejemplos 2023-03-15T10:30:00Z2023-03-16T14:05:21Z2023-03-28T09:00:00Z | |||
| Número de factura InvoiceNumber | Identificador único del documento de factura de proveedor. | ||
| Descripción El número de factura actúa como identificador único del caso durante todo el recorrido de procesamiento de la factura. Cada número corresponde a una única factura recibida de un proveedor, lo que permite realizar el seguimiento de todas las actividades relacionadas, desde la captura de datos hasta el pago final, como parte de una misma instancia de proceso. En el análisis de process mining, este atributo es fundamental para reconstruir el ciclo de vida completo de cada factura. Permite conectar en una secuencia cronológica los distintos eventos registrados en SAP, como aparcar, contabilizar, bloquear y compensar. Así se obtiene una visión clara de cómo se gestiona cada factura, cuánto tiempo requiere y dónde se producen desviaciones respecto al proceso estándar. Por qué es importante Es la clave principal que vincula todos los eventos relacionados con una única factura, por lo que constituye la base esencial para el análisis de procesos y la exploración de variantes. Dónde obtenerlo Normalmente es el número de documento de la tabla SAP RBKP, campo BELNR, a menudo concatenado con el código de sociedad (BUKRS) y el ejercicio fiscal (GJAHR) para garantizar una unicidad absoluta. Ejemplos 510004567851000456795100045680 | |||
| Fecha de compensación ClearingDate | La fecha en la que se efectuó el pago y la factura se compensó en cuentas por pagar. | ||
| Descripción Clearing Date marca el último paso del ciclo de vida de la factura: el pago. Es la fecha en la que una partida abierta de factura se compensa mediante un documento de pago en el sistema. Representa el momento real de ejecución del pago. Este atributo es el punto final de muchos KPI importantes, incluidos «Average Invoice Cycle Time» y «On-Time Payment Rate». Se compara con Payment Due Date para medir el rendimiento de los pagos. En el análisis de descuentos por pronto pago, se compara con el periodo de descuento para comprobar si el pago se realizó a tiempo para aprovecharlo. Por qué es importante Marca la finalización del proceso y sirve de base para calcular el tiempo de ciclo total, las tasas de pagos puntuales y la materialización de descuentos por pronto pago. Dónde obtenerlo Para las partidas compensadas, es el campo «Clearing Date» (AUGDT) de la tabla de partidas de proveedores compensadas, BSAK. Ejemplos 2023-04-152023-05-022023-05-20 | |||
| Fecha de contabilización PostingDate | La fecha en la que la factura se contabilizó oficialmente en los libros contables. | ||
| Descripción Posting Date es una fecha clave del proceso contable. Determina el periodo fiscal en el que se reconoce el gasto de la factura en el libro mayor. Normalmente la establece la persona responsable de cuentas por pagar durante el procesamiento de la factura. En el análisis de procesos, la actividad «Invoice Posted», marcada por esta fecha, es un hito importante. La duración desde la recepción de la factura hasta Posting Date es un componente crítico del tiempo de ciclo total. Esta fecha también es fundamental para la elaboración de informes financieros y el análisis del rendimiento, como el seguimiento del volumen de facturas contabilizadas por semana o mes. Por qué es importante Marca un hito crítico del proceso, determina el periodo financiero de la transacción y es un componente clave del cálculo del tiempo de ciclo. Dónde obtenerlo Es el campo «Posting Date» (BUDAT) de la tabla de cabecera del documento de factura, RBKP. Ejemplos 2023-03-202023-04-052023-04-11 | |||
| Fecha de vencimiento del pago PaymentDueDate | La fecha límite en la que debe pagarse la factura al proveedor, según las condiciones de pago. | ||
| Descripción Payment Due Date se calcula a partir de la fecha base de la factura y las condiciones de pago acordadas. Representa el plazo para efectuar el pago y evitar retrasos, posibles penalizaciones o un deterioro de la relación con el proveedor. Este atributo es fundamental para KPI de rendimiento y cumplimiento como «On-Time Payment Rate» y «Cash Discount Opportunity Loss». Al comparar la fecha de pago real (Clearing Date) con Payment Due Date, el análisis puede determinar automáticamente si el pago se realizó a tiempo, antes o después del vencimiento. Es un elemento básico del panel Payment Terms Adherence. Por qué es importante Sirve como referencia para medir el rendimiento de los pagos puntuales e identificar oportunidades de aprovechar descuentos por pronto pago. Dónde obtenerlo Esta fecha suele calcularse. La fecha base del pago (ZFBDT) se encuentra en la tabla BSEG. La lógica de vencimiento también depende de las condiciones de pago (BSEG-ZTERM). Ejemplos 2023-04-192023-05-052023-05-11 | |||
| Importe de la factura InvoiceAmount | El importe bruto total de la factura en la moneda original del documento. | ||
| Descripción Invoice Amount representa el valor total de la factura presentada por el proveedor. Es una métrica financiera clave para cada caso de factura. En Process Mining, este atributo es esencial para el análisis basado en el valor. Permite filtrar y segmentar el proceso según el importe de la factura, que a menudo se relaciona con la complejidad del proceso y los requisitos de aprobación. Por ejemplo, las facturas de importe elevado pueden seguir una ruta de aprobación diferente y más estricta. También se utiliza en el análisis de cumplimiento, por ejemplo, para comprobar si las facturas de importe elevado omiten pasos de aprobación obligatorios. Por qué es importante Permite analizar el proceso según el valor, priorizar las facturas de importe elevado y comprender cómo influye el importe de la factura en el flujo del proceso y el cumplimiento. Dónde obtenerlo Es el campo «Gross invoice amount» (RMWWR) de la tabla de cabecera del documento de factura, RBKP. Ejemplos 1500.7512500.00850.20 | |||
| Motivo del bloqueo de pago PaymentBlockReason | Un código que indica el motivo por el que una factura está bloqueada para el pago. | ||
| Descripción Cuando una factura presenta una discrepancia o requiere una investigación adicional, se aplica un bloqueo de pago. El código Payment Block Reason especifica por qué se estableció el bloqueo, por ejemplo, debido a una diferencia de cantidad, una diferencia de precio o un bloqueo manual. Este atributo es esencial para el panel «Payment Block Resolution Duration». Analizar la frecuencia y la duración de los bloqueos por motivo ayuda a identificar las causas raíz de los retrasos en los pagos. Por ejemplo, si «Price Discrepancy» es el motivo más habitual de los bloqueos prolongados, puede indicar un problema en los datos maestros o en el proceso de órdenes de compra que debe resolverse. Por qué es importante Explica por qué se retrasan las facturas, permite analizar las causas raíz de los bloqueos de pago y ayuda a priorizar las iniciativas de mejora del proceso. Dónde obtenerlo El motivo del bloqueo de pago puede encontrarse en el nivel de posición, en la tabla RSEG (campo SPGRS), o en la tabla de documentos contables BSEG (campo ZLSPR). Ejemplos RIM | |||
| Nombre de usuario UserName | El ID de usuario de SAP de la persona que ejecutó la actividad. | ||
| Descripción El atributo User Name identifica a la persona concreta responsable de ejecutar una actividad determinada del proceso. Normalmente corresponde al nombre de usuario de SAP registrado con la transacción o el evento de cambio. Este atributo es fundamental para analizar el rendimiento a nivel de usuario o equipo. Ayuda a responder preguntas como «¿Quiénes son las personas aprobadoras más rápidas?» o «¿Qué usuarios generan más retrabajo?». Se utiliza en los Dashboards para analizar la distribución de la carga de trabajo, identificar necesidades de formación y comprender las diferencias de rendimiento entre las distintas personas empleadas. Por qué es importante Permite analizar el rendimiento y la carga de trabajo por persona o equipo, así como identificar a quienes tienen un mejor rendimiento, oportunidades de formación y desequilibrios en los recursos. Dónde obtenerlo Es el campo «Changed By» (USERNAME) de la tabla de cabecera de documentos de cambio, CDHDR. Para los eventos de creación, puede ser el campo «Entered by» (ERNAM) de tablas como RBKP. Ejemplos JSMITHBWILSONCHEN | |||
| Número de orden de compra PurchaseOrderNumber | El identificador de la orden de compra (PO) con la que se coteja la factura. | ||
| Descripción Purchase Order Number vincula una factura con el documento de compras original. Es fundamental para la comparación a tres bandas (PO, Goods Receipt, Invoice) y para analizar la eficiencia del proceso de facturas respaldadas por una PO. Este atributo es fundamental para Dashboards como «Invoice-PO Matching Discrepancy Rate». Permite segmentar el proceso entre facturas con PO y facturas sin PO, que suelen seguir rutas de procesamiento y presentar niveles de complejidad muy diferentes. Analizar los problemas relacionados con determinadas PO puede ayudar a diagnosticar problemas en fases anteriores del proceso de compras. Por qué es importante Conecta la factura con el proceso de compras, permite analizar las facturas con PO y sin PO e identificar discrepancias de conciliación. Dónde obtenerlo Normalmente se encuentra en el nivel de posición. «Purchase Order Number» (EBELN) está en la tabla de posiciones de factura, RSEG. Puede ser necesario agregarlo al nivel de cabecera. Ejemplos 450001756345000175644500017565 | |||
| Número de proveedor VendorNumber | Un identificador único del proveedor que presentó la factura. | ||
| Descripción Vendor Number es la clave de los datos maestros que identifica al proveedor. Vincula la transacción de factura con un socio comercial específico y permite analizarla según las características del proveedor. El análisis del proceso por Vendor Number puede revelar información importante sobre las relaciones y el rendimiento de los proveedores. Por ejemplo, puede ayudar a identificar qué proveedores presentan de forma habitual facturas problemáticas que provocan bloqueos de pago o discrepancias, o qué facturas de proveedores se procesan con mayor eficiencia. Esta información es valiosa para la gestión de proveedores y las iniciativas de abastecimiento estratégico. Por qué es importante Permite analizar cada proveedor y ayuda a identificar patrones, problemas o eficiencias asociados con proveedores concretos. Dónde obtenerlo Es el campo «Invoicing Party» (LIFNR) de la tabla de cabecera del documento de factura, RBKP. Ejemplos 100345100876200112 | |||
| ¿Está vencida? IsOverdue | Un indicador calculado que señala si la factura se pagó después de su fecha de vencimiento. | ||
| Descripción Se trata de un atributo booleano que se calcula comparando «Clearing Date» (la fecha de pago real) con «Payment Due Date». Si la fecha de compensación es posterior a la fecha de vencimiento, la marca es verdadera; de lo contrario, es falsa. Esto proporciona una medida sencilla y directa del rendimiento de los pagos puntuales de cada factura. Este atributo simplifica el análisis y la visualización en los Dashboards. Permite filtrar y agregar datos fácilmente para calcular el KPI «On-Time Payment Rate». Puede segmentar rápidamente el proceso para comparar los flujos de las facturas vencidas con los de las facturas pagadas a tiempo y, potencialmente, revelar los patrones del proceso que provocan pagos atrasados. Por qué es importante Simplifica el análisis del rendimiento de los pagos puntuales y permite comparar fácilmente los procesos de facturas pagadas a tiempo y con retraso. Dónde obtenerlo Este atributo no existe en SAP. Se calcula durante la transformación de datos mediante la fórmula: ClearingDate > PaymentDueDate. Ejemplos truefalse | |||
| ¿Se ha perdido el descuento por pronto pago? IsCashDiscountLost | Un indicador calculado que señala si no se aprovechó un descuento por pronto pago disponible. | ||
| Descripción Es un atributo booleano que se calcula a partir de las condiciones de pago y la fecha de pago real. Se establece como verdadero si Payment Terms ofrecía un descuento por pronto pago y Clearing Date era posterior al vencimiento del periodo de descuento. Mide directamente la pérdida financiera causada por ineficiencias del proceso. Este atributo es la base del panel «Cash Discount Opportunity Loss». Permite cuantificar fácilmente el impacto financiero de los retrasos en el procesamiento. Al filtrar los casos en los que este indicador es verdadero, los analistas pueden investigar las variantes del proceso y los cuellos de botella que provocan con mayor frecuencia la pérdida de descuentos, lo que proporciona una sólida justificación para mejorar el proceso. Por qué es importante Cuantifica directamente la pérdida financiera derivada de los retrasos del proceso y refuerza la necesidad de optimizar el Workflow de procesamiento de facturas. Dónde obtenerlo Este atributo no existe en SAP. Se calcula durante la transformación de datos interpretando «PaymentTerms» y comparando «ClearingDate» con la fecha de vencimiento del descuento. Ejemplos truefalse | |||
| Condiciones de pago PaymentTerms | El código que define las condiciones de pago acordadas con el proveedor, como los periodos de descuento y las fechas de vencimiento. | ||
| Descripción Payment Terms define las reglas sobre cuándo debe pagarse una factura y los descuentos por pronto pago disponibles, si los hay. Algunos ejemplos son «Net 30 days» o «2% 10, Net 30», que significa un descuento del 2 % si se paga en 10 días; de lo contrario, el importe total vence en 30 días. Este atributo es la base del panel «Cash Discount Opportunity Loss» y del KPI «Cash Discount Capture Rate». El análisis utiliza las condiciones de pago junto con las fechas de contabilización y de pago para determinar si había un descuento disponible y si se aplicó correctamente. También es clave para el panel Payment Terms Adherence. Por qué es importante Es esencial para analizar las tasas de aprovechamiento de descuentos por pronto pago y comprender el impacto financiero de los retrasos del proceso. Dónde obtenerlo Es el campo «Terms of Payment Key» (ZTERM) de la tabla de cabecera del documento de factura, RBKP. Ejemplos Z0010001NT30 | |||
| Cuenta de libro mayor GeneralLedgerAccount | El número de la cuenta de mayor en la que se contabiliza el gasto o coste de la factura. | ||
| Descripción General Ledger (G/L) Account es la cuenta de destino del plan contable en la que se registra el impacto financiero de la factura. Es un dato fundamental para los informes financieros y la gestión de costes. En Process Mining, el análisis de la cuenta de mayor aporta una dimensión financiera al flujo del proceso. El panel «General Ledger Account Usage Analysis» puede revelar patrones de gasto, identificar posibles errores de codificación de facturas y garantizar que los costes se asignen a los departamentos o proyectos correctos. Ayuda a conectar la ejecución del proceso con su impacto financiero. Por qué es importante Añade una dimensión financiera al proceso y permite analizar la asignación de costes, los patrones de gasto y posibles errores de codificación de facturas. Dónde obtenerlo Se encuentra en el nivel de posición. «G/L Account Number» (HKONT) está en la tabla de posiciones de factura RSEG para facturas con PO o en BSEG para facturas directas de FI. Ejemplos 630000655100741000 | |||
| Hora de finalización EndTime | La marca de tiempo que indica cuándo se completó una actividad. En los eventos instantáneos, coincide con la Start Time. | ||
| Descripción El atributo End Time marca la finalización de una actividad específica. En muchos eventos de SAP, que se registran como puntos únicos en el tiempo, End Time es idéntico a Start Time. Sin embargo, en actividades con una duración medible, como una etapa de aprobación en curso, puede representar la conclusión de ese trabajo. En el análisis de procesos, disponer de una End Time diferenciada permite medir el tiempo de procesamiento de una actividad por separado del tiempo de espera que la precede. Esto ayuda a distinguir cuánto tarda en ejecutarse una actividad de cuánto tiempo espera un caso antes de que comience, lo que proporciona una visión más profunda de la eficiencia de los recursos. Por qué es importante Permite calcular el tiempo de procesamiento de las actividades, diferenciarlo del tiempo de espera entre actividades y mejorar el análisis de cuellos de botella. Dónde obtenerlo A menudo coincide con Start Time y se obtiene de CDHDR-UDATE y CDHDR-UTIME. En algunos casos, puede derivarse de registros de Workflow que registran explícitamente el inicio y el final de una Task. Ejemplos 2023-03-15T10:35:10Z2023-03-16T14:10:00Z2023-03-28T09:02:45Z | |||
| Moneda Currency | El código de moneda del importe de la factura. | ||
| Descripción El atributo Currency especifica la moneda en la que está expresado el importe de la factura, por ejemplo, USD, EUR o JPY. Este atributo aporta un contexto esencial para Invoice Amount. Permite interpretar y agregar correctamente los datos financieros, especialmente en organizaciones internacionales que trabajan con varias monedas. El análisis puede filtrarse por moneda para comparar la eficiencia del procesamiento o los problemas entre distintas zonas monetarias. Para realizar agregaciones financieras significativas, puede ser necesario convertir los importes a una única moneda de presentación. Por qué es importante Aporta el contexto necesario para cualquier importe financiero, garantiza una interpretación precisa y permite filtrar y analizar los datos por moneda. Dónde obtenerlo Es el campo «Currency Key» (WAERS) de la tabla de cabecera del documento de factura, RBKP. Ejemplos USDEURGBP | |||
| Motivo del rechazo RejectionReason | Un código o texto que explica por qué se rechazó una factura durante el Workflow de aprobación. | ||
| Descripción Cuando una persona aprobadora rechaza una factura, lo ideal es que indique el motivo. Puede tratarse de un código estandarizado o de un comentario de texto libre que señale problemas como «Número de PO incorrecto», «Factura duplicada» o «Importe incorrecto». Estos datos son fundamentales para el panel «Invoice Rejection Reasons & Trends». Al analizar la frecuencia de los distintos motivos de rechazo, la empresa puede identificar problemas habituales y aplicar medidas correctivas. Por ejemplo, si «Número de PO incorrecto» aparece con frecuencia, puede indicar la necesidad de mejorar la comunicación con los proveedores o la formación del personal que introduce los datos. Este análisis es clave para reducir el retrabajo del proceso. Por qué es importante Proporciona la causa raíz de los rechazos, permite aplicar mejoras específicas al proceso, reducir el retrabajo y mejorar las tasas de acierto a la primera. Dónde obtenerlo Esta información a menudo no se almacena en un único campo estándar. Puede encontrarse en los registros del contenedor de Workflow, en campos de texto largo asociados al documento o en campos específicos de una solución de Workflow personalizada. Ejemplos DUPLICATE_INVWRONG_AMTNO_PO_MATCH | |||
| Sistema de origen SourceSystem | Identifica el sistema de origen específico del que se extrajeron los datos. | ||
| Descripción El atributo Source System indica el origen de los datos de eventos, por ejemplo, el nombre de una instancia concreta de SAP ECC. Es especialmente importante en entornos con varios sistemas ERP o cuando se combinan datos de distintas fuentes. En el análisis, este atributo ayuda a diferenciar los procesos y el rendimiento entre sistemas, regiones o unidades de negocio que pueden ejecutarse en instancias independientes. Garantiza la trazabilidad de los datos y permite aplicar filtros y análisis específicos de cada sistema. Por qué es importante Aporta un contexto esencial en entornos con varios sistemas, ya que permite separar correctamente los datos y analizar el rendimiento de cada sistema. Dónde obtenerlo Normalmente es un valor estático que se añade durante la extracción de datos y representa el ID del sistema SAP (TADIR-SRCSYSTEM) o un identificador asignado manualmente a la instancia específica de SAP. Ejemplos SAPECC_PROD_EUECC_US_FINSAP_ERP_6_EHP8 | |||
| Sociedad CompanyCode | El identificador de la entidad jurídica o sociedad para la que se procesa la factura. | ||
| Descripción Company Code es una unidad organizativa fundamental en SAP Financials que representa una entidad jurídica independiente. Todas las transacciones financieras, incluidas las facturas, se contabilizan en un código de empresa específico. Este atributo permite segmentar el análisis del proceso por entidad jurídica. Es fundamental para comparar el rendimiento, el cumplimiento y la eficiencia del proceso entre las distintas empresas de un grupo corporativo. Los Dashboards pueden filtrarse por Company Code para ofrecer una vista específica de los KPI de procesamiento de facturas de cada empresa. Por qué es importante Permite comparar procesos y establecer referencias de rendimiento entre distintas entidades jurídicas de una organización. Dónde obtenerlo Es el campo «Company Code» (BUKRS) de la tabla de cabecera del documento de factura, RBKP. Ejemplos 10002000US01 | |||
| Tipo de documento DocumentType | Un código que clasifica el documento contable, por ejemplo, como una factura de proveedor o una nota de crédito. | ||
| Descripción Document Type se utiliza para categorizar distintos tipos de transacciones comerciales en SAP. En el procesamiento de facturas, los tipos habituales incluyen «RE» para facturas estándar o «KG» para notas de crédito de proveedores. El tipo de documento controla aspectos de la contabilización, como el rango de números utilizado. En el análisis, este atributo permite filtrar el proceso por tipos de transacción específicos. Por ejemplo, el proceso de gestión de una nota de crédito puede ser muy diferente del de una factura estándar. Separar estos flujos mediante Document Type proporciona una visión del proceso más precisa y significativa. Por qué es importante Permite separar y analizar distintas transacciones comerciales, como facturas y notas de crédito, que siguen procesos diferentes. Dónde obtenerlo Es el campo «Document Type» (BLART) de la tabla de cabecera del documento de factura, RBKP. Ejemplos REKRKG | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se actualizaron por última vez los datos del proceso desde el sistema de origen. | ||
| Descripción Este atributo registra la fecha y hora de la extracción o actualización de datos más reciente. Se aplica al conjunto de datos completo, no a eventos individuales, y proporciona una indicación clara de la actualidad de los datos. Se trata de un atributo de metadatos fundamental para quienes utilizan Dashboards y para las personas analistas. Les ayuda a comprender el periodo que abarca el análisis y garantiza que toman decisiones basadas en información actualizada. Normalmente se muestra de forma destacada en los Dashboards para informar sobre la antigüedad de los datos. Por qué es importante Informa sobre la actualidad de los datos y garantiza que el análisis y las decisiones se basen en información actualizada. Dónde obtenerlo La herramienta de extracción de datos o ETL genera e incorpora este valor al conjunto de datos cuando se actualizan los datos. Ejemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z | |||
Purchase to Pay - Actividades de procesamiento de facturas
| Actividad | Descripción | ||
|---|---|---|---|
| Bloqueo de pago establecido | Esta actividad se produce cuando se aplica un bloqueo a una posición de factura, lo que impide efectuar el pago. Los bloqueos pueden establecerse automáticamente debido a discrepancias en la conciliación de 3 vías o manualmente por diversos motivos. | ||
| Por qué es importante Este evento es fundamental para medir la duración de la resolución de bloqueos de pago e identificar las causas raíz de los retrasos en los pagos. Pone de manifiesto problemas de precio, cantidad o aprobaciones necesarias. Dónde obtenerlo Es un evento explícito que puede rastrearse mediante los registros de documentos de modificación, en las tablas CDHDR y CDPOS, para la tabla BSEG y el campo ZLSPR (clave de bloqueo de pago). Recopilar Marca de tiempo de los documentos de modificación (CDHDR) cuando el valor de BSEG-ZLSPR cambia de vacío a no vacío. Tipo de evento explicit | |||
| Datos de factura capturados | Indica la creación inicial del documento de factura en SAP, ya sea como documento aparcado o contabilizado por completo. Normalmente es el primer evento registrado en el sistema durante el ciclo de vida de una factura y sirve como hora de inicio del proceso. | ||
| Por qué es importante Esta actividad es el punto de inicio principal para medir el tiempo de ciclo de procesamiento de facturas de principio a fin. Analizar la duración desde este punto ayuda a identificar retrasos en la introducción inicial de datos y en la fase de creación del documento. Dónde obtenerlo La marca de tiempo de creación se registra en la tabla SAP BKPF, en los campos CPUDT (fecha en la que se introdujo el documento contable) y CPUTM (hora de entrada). Recopilar Utilice la marca de tiempo de creación del encabezado de la tabla BKPF (CPUDT). Tipo de evento explicit | |||
| Factura anulada | Representa la cancelación de un documento de factura contabilizado. Se crea un documento de anulación para neutralizar el impacto financiero de la factura original. | ||
| Por qué es importante Esta actividad pone de relieve una excepción importante y una ruta de retrabajo. Analizar la frecuencia y los motivos de las anulaciones puede revelar problemas sistémicos en el proceso de validación y contabilización de facturas. Dónde obtenerlo Es un evento explícito registrado en la tabla de encabezados de documentos BKPF. El encabezado del documento anulado contiene el número del documento de anulación (STBLG) y el ejercicio fiscal (STJAH). Recopilar Identifique los documentos cuyo campo BKPF-STBLG esté cumplimentado. La marca de tiempo del evento es la fecha de contabilización del documento de anulación. Tipo de evento explicit | |||
| Factura compensada | Esta actividad marca el último paso de un ciclo de vida de factura completado correctamente: el pasivo abierto se compensa mediante un documento de pago. Indica que el pago se ha ejecutado. | ||
| Por qué es importante Como evento final principal, es fundamental para calcular el tiempo total de ciclo de principio a fin. Confirma la finalización correcta del proceso y se utiliza para medir el rendimiento de los pagos puntuales. Dónde obtenerlo Es un evento explícito registrado en la tabla de posiciones de factura BSEG. La fecha de compensación se almacena en el campo AUGDT y el número del documento de compensación, en AUGBL. Recopilar Utilice la fecha de compensación (BSEG-AUGDT) de la posición del documento de factura. Tipo de evento explicit | |||
| Factura contabilizada | Es un evento financiero clave en el que la factura se registra oficialmente en el libro mayor y crea un pasivo. El documento pasa de un estado temporal, aparcado, a un asiento contable permanente. | ||
| Por qué es importante La contabilización es un hito importante que confirma la validez de la factura. Es un requisito previo para el pago y un indicador clave del rendimiento del procesamiento. Dónde obtenerlo Es un evento explícito registrado en la tabla de encabezados de documentos BKPF. La marca de tiempo es la fecha de contabilización, BKPF-BUDAT. El documento ya no tendrá estado «aparcado». Recopilar Utilice la fecha de contabilización (BKPF-BUDAT) para los documentos que no estén aparcados (BKPF-BSTAT está vacío o contiene « »). Tipo de evento explicit | |||
| Bloqueo de pago liberado | Representa la eliminación de un bloqueo de pago de una posición de factura, lo que permite que continúe hasta la ejecución del pago. Indica que se ha resuelto un problema identificado anteriormente. | ||
| Por qué es importante Esta actividad concluye la medición de la duración del bloqueo. Analizar el tiempo transcurrido entre el establecimiento y la liberación de un bloqueo revela la eficiencia del proceso de resolución de incidencias. Dónde obtenerlo Este evento se registra mediante los registros de documentos de modificación, en las tablas CDHDR y CDPOS, para la tabla BSEG y el campo ZLSPR (clave de bloqueo de pago), cuando se elimina el bloqueo. Recopilar Marca de tiempo de los documentos de modificación (CDHDR) cuando el valor de BSEG-ZLSPR cambia de no vacío a vacío. Tipo de evento explicit | |||
| Factura aparcada | Indica que una factura se ha introducido en SAP, pero todavía no se ha contabilizado en el libro mayor. Es un estado temporal que permite revisar, corregir o aprobar la factura antes de contabilizarla. | ||
| Por qué es importante Registrar cuándo se aparcan las facturas y durante cuánto tiempo permite identificar cuellos de botella en el proceso de validación y aprobación previo a la contabilización. También separa el tiempo de introducción de datos del tiempo de procesamiento financiero. Dónde obtenerlo Este evento se infiere del estado del documento en la tabla BKPF, campo BSTAT. Un valor «V» (documento aparcado) o «W» (documento aparcado con liberación de cambios) indica un estado aparcado. Recopilar Identifique los documentos cuyo campo de estado BKPF-BSTAT sea «V». La marca de tiempo del evento es la fecha de creación BKPF-CPUDT. Tipo de evento inferred | |||
| Factura aprobada | Indica que la autoridad designada ha aprobado formalmente la factura, lo que permite continuar con su contabilización y pago. A menudo es el paso final de un Workflow. | ||
| Por qué es importante Este hito concluye la medición del tiempo de ciclo de aprobación. Desbloquea el proceso, permite efectuar el pago a tiempo y ayuda a analizar la distribución de la carga de trabajo entre las personas aprobadoras. Dónde obtenerlo Normalmente se captura en las tablas de SAP Business Workflow mediante la identificación de la finalización de una tarea de aprobación. Como alternativa, puede inferirse a partir de la liberación de un bloqueo de pago relacionado con la aprobación. Recopilar Marca de tiempo del paso de aprobación completado en los registros del Workflow o de la eliminación de un bloqueo de pago específico. Tipo de evento inferred | |||
| Factura enviada para aprobación | Representa el momento en que una factura se envía a un Workflow formal de aprobación. El mecanismo de captura depende en gran medida de la implementación específica de SAP Workflow o del sistema de terceros. | ||
| Por qué es importante Esta actividad inicia el contador del KPI de tiempo de ciclo de aprobación de facturas. Es esencial para identificar retrasos en la cadena de aprobación y analizar el rendimiento de las personas aprobadoras. Dónde obtenerlo Este evento suele capturarse en las tablas de SAP Business Workflow, como SWW_WI2OBJ y SWWLOG, mediante la identificación del inicio de una tarea de aprobación específica. En escenarios más sencillos, puede inferirse a partir de un cambio de estado en un campo personalizado. Recopilar Requiere analizar los registros de SAP Workflow o los campos de estado personalizados vinculados al documento de factura. Tipo de evento inferred | |||
| Factura rechazada | Indica que una factura ha sido rechazada durante el proceso de aprobación. Esta acción suele requerir una corrección y un nuevo envío, lo que crea un ciclo de retrabajo. | ||
| Por qué es importante Registrar los rechazos es fundamental para identificar los motivos habituales de fallo, como datos incorrectos o incumplimientos de políticas. Ayuda a cuantificar el retrabajo y a localizar áreas de mejora del proceso o de formación para proveedores. Dónde obtenerlo Este evento suele encontrarse en los registros de SAP Business Workflow como un paso de rechazo. También puede inferirse a partir de cambios de estado específicos o notas añadidas al documento de factura. Recopilar Marca de tiempo del paso de rechazo en los registros del Workflow o de un cambio de estado del documento que indique el rechazo. Tipo de evento inferred | |||
| La factura vence | Es un evento calculado que se produce cuando la fecha actual supera la fecha neta de vencimiento de la factura y esta todavía no se ha pagado. La fecha de vencimiento se determina a partir de las condiciones de pago y la fecha base. | ||
| Por qué es importante Esta actividad es esencial para supervisar el KPI de tasa de pagos puntuales. Señala de forma proactiva las facturas con riesgo de pago tardío, lo que puede perjudicar las relaciones con los proveedores y generar sanciones. Dónde obtenerlo Este evento se calcula comparando la fecha actual con la fecha neta de vencimiento. La fecha de vencimiento se obtiene de la fecha base (BSEG-ZFBDT) y las condiciones de pago (BSEG-ZTERM). Recopilar El evento se activa cuando Tipo de evento calculated | |||
Guías de extracción
Pasos
- Cree el programa ABAP: Utilice la transacción
SE38oSE80para crear un programa ejecutable nuevo, por ejemplo,Z_PM_INVOICE_EXTRACT. Proporcione un título adecuado y establezca el tipo como «Executable Program». - Defina la pantalla de selección: Defina en el programa una pantalla de selección que permita filtrar los datos. Los parámetros clave deben incluir Company Code (
BUKRS), Fiscal Year (GJAHR), Posting Date Range (BUDAT) y un parámetro para la ruta del archivo de salida en el servidor de aplicaciones. - Declare las estructuras de datos: Defina una estructura de tabla interna que contenga el registro de eventos final. Esta estructura debe incluir todos los atributos obligatorios y recomendados:
InvoiceNumber,Actividad,EventTime,UserName,VendorNumber,PurchaseOrderNumber,InvoiceAmount,PostingDate,PaymentDueDate,PaymentBlockReasonyClearingDate. - Implemente la lógica de selección de datos: Escriba la lógica ABAP principal para seleccionar los datos de las facturas. El enfoque implica varias selecciones que se combinan en la tabla final del registro de eventos.
- Primero, seleccione los datos de cabecera y posición de las tablas principales de facturas
BKPF,BSEG,RBKPyRSEGsegún los criterios de la pantalla de selección. - Para cada factura, genere los eventos base «Invoice Data Captured» (a partir de la marca de tiempo de creación) y «Invoice Posted» (a partir de la marca de tiempo de contabilización).
- Consulte las tablas de documentos de modificación
CDHDRyCDPOSpara encontrar cambios relacionados con bloqueos de pago (campoZLSPRenBSEG). Para cada cambio relevante, cree los eventos «Payment Block Set» y «Payment Block Released». - Identifique los eventos «Invoice Cleared» comprobando si existen un documento de compensación (
AUGBL) y una fecha de compensación (AUGDT) en la tablaBSEG. - Identifique los eventos «Invoice Reversed
comprobando si existe un documento de anulación (STBLG) en la cabeceraBKPF`. - Implemente una lógica personalizada para capturar eventos del flujo de trabajo («Invoice Sent For Approval», «Approved», «Rejected»). Esta parte depende en gran medida de cada cliente y requiere adaptar el código a las tablas o los campos de estado de su flujo de trabajo.
- Primero, seleccione los datos de cabecera y posición de las tablas principales de facturas
- Genere eventos calculados: Calcule en la lógica del programa el evento
Invoice Becomes Overdue. Se obtiene comparando la fecha de vencimiento del pago de la factura (PaymentDueDate) con la fecha actual para todas las facturas impagadas. Si la fecha de vencimiento ya ha pasado, cree un evento conEventTimeestablecido en la fecha de vencimiento. - Complete la tabla del registro de eventos: A medida que recopile los datos de cada factura desde las distintas fuentes, déles formato y añada nuevas filas a la tabla interna final del registro de eventos, una fila por actividad.
- Exporte los datos a un archivo: Utilice las instrucciones
OPEN DATASET,TRANSFERyCLOSE DATASETpara escribir el contenido de la tabla interna final en un archivo plano en la ruta del servidor de aplicaciones SAP especificada en la pantalla de selección. Utilice un separador coherente, como un punto y coma o un tabulador, para crear un archivo CSV. - Programe la extracción: Para realizar extracciones periódicas, cree una variante del programa con los criterios de selección deseados y prográmela como un job en segundo plano mediante la transacción
SM36. - Recupere el archivo de salida: Acceda al directorio del servidor de aplicaciones SAP mediante la transacción
AL11para localizar el archivo generado. Utilice la transacciónCG3Ypara descargarlo del servidor de aplicaciones a su equipo local. - Prepárese para la carga: Antes de cargar el archivo en una herramienta de Process Mining, ábralo para verificar que las cabeceras sean correctas, que el formato de los datos sea coherente, especialmente el de las marcas de tiempo, y que el separador sea el esperado. Asegúrese de guardar el archivo con codificación UTF-8.
Configuración
- Criterios de selección: El informe ABAP debe incluir una pantalla de selección completa. Los filtros más importantes son:
Sociedad (BUKRS): para limitar la extracción a entidades jurídicas específicas.Fecha de contabilización (BUDAT): para definir el periodo de extracción. Se recomienda extraer los datos en bloques manejables, por ejemplo, de 3 a 6 meses cada vez.Tipo de documento (BLART): para incluir únicamente los tipos de documento de factura relevantes, como 'RE' para facturas logísticas y 'KR' para facturas de proveedores.
- Ruta del archivo de salida: Parámetro obligatorio para especificar la ruta completa y el nombre del archivo en el servidor de aplicaciones SAP donde se creará el archivo de salida. El usuario que ejecute el informe debe tener autorización de escritura en este directorio.
- Consideraciones de rendimiento: Para grandes volúmenes de datos, el informe debe ejecutarse como job en segundo plano durante las horas de menor actividad para evitar una degradación del rendimiento del sistema. La lógica debe seleccionar únicamente los campos necesarios de las tablas y utilizar, siempre que sea posible, los índices estándar de la base de datos SAP.
- Requisitos previos y autorizaciones: El usuario o la cuenta de servicio que ejecute esta extracción necesita:
- Permisos para ejecutar informes ABAP, incluidos en
S_PROGRAM. - Acceso de lectura a las tablas financieras y logísticas, incluidas
BKPF,BSEG,RBKP,RSEG,CDHDRyCDPOS. - Autorización para escribir archivos en el directorio especificado del servidor de aplicaciones (
S_DATASET). - Acceso a las transacciones
SE38,SM36,AL11yCG3Ypara el desarrollo, la programación y la recuperación de archivos.
- Permisos para ejecutar informes ABAP, incluidos en
a Consulta de ejemplo abap
REPORT Z_PM_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables for Selection Screen
*&---------------------------------------------------------------------*
TABLES: BKPF, RBKP.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
InvoiceNumber TYPE belnr_v,
Activity TYPE string,
EventTime TYPE timestamp,
UserName TYPE uname,
VendorNumber TYPE lifnr,
PurchaseOrderNumber TYPE ebeln,
InvoiceAmount TYPE wrbtr,
PostingDate TYPE budat,
PaymentDueDate TYPE faedt,
PaymentBlockReason TYPE rstgr,
ClearingDate TYPE augdt,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_bkpf TYPE bkpf,
lt_bseg TYPE TABLE OF bseg,
ls_bseg TYPE bseg.
DATA: lt_rbkp TYPE TABLE OF rbkp,
ls_rbkp TYPE rbkp.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_gjahr FOR bkpf-gjahr OBLIGATORY,
s_budat FOR bkpf-budat.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/tmp/invoice_events.csv'.
*&---------------------------------------------------------------------*
*& Start of Program Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Select FI Invoices (e.g., Doc Type KR)
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND gjahr IN s_gjahr
AND budat IN s_budat
AND blart = 'KR'.
" Select MM Invoices
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND gjahr IN s_gjahr
AND budat IN s_budat.
* --- Process FI Invoices ---
LOOP AT lt_bkpf INTO ls_bkpf.
CLEAR gs_event_log.
gs_event_log-InvoiceNumber = ls_bkpf-belnr.
gs_event_log-PostingDate = ls_bkpf-budat.
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = ls_bkpf-bukrs
AND belnr = ls_bkpf-belnr
AND gjahr = ls_bkpf-gjahr
AND koart = 'K'. " Vendor Line Item
IF sy-subrc = 0.
gs_event_log-VendorNumber = ls_bseg-lifnr.
gs_event_log-InvoiceAmount = ls_bseg-wrbtr.
gs_event_log-ClearingDate = ls_bseg-augdt.
" Calculate Due Date
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_bseg = ls_bseg
IMPORTING
e_faedt = gs_event_log-PaymentDueDate.
ENDIF.
" Activity: Invoice Data Captured
gs_event_log-Activity = 'Invoice Data Captured'.
CONVERT DATE ls_bkpf-cpudt TIME ls_bkpf-cputm INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Parked (if BSTAT = 'V')
IF ls_bkpf-bstat = 'V'.
gs_event_log-Activity = 'Invoice Parked'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Posted
gs_event_log-Activity = 'Invoice Posted'.
CONVERT DATE ls_bkpf-budat TIME ls_bkpf-cputm INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Cleared
IF ls_bseg-augbl IS NOT INITIAL.
gs_event_log-Activity = 'Invoice Cleared'.
CONVERT DATE ls_bseg-augdt INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bseg-usnam_cl.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Becomes Overdue
IF gs_event_log-PaymentDueDate IS NOT INITIAL AND gs_event_log-PaymentDueDate < sy-datum AND ls_bseg-augbl IS INITIAL.
gs_event_log-Activity = 'Invoice Becomes Overdue'.
CONVERT DATE gs_event_log-PaymentDueDate INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = 'SYSTEM'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Reversed
IF ls_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE budat, usnam FROM bkpf INTO ls_rev_bkpf
WHERE belnr = ls_bkpf-stblg AND bukrs = ls_bkpf-bukrs AND gjahr = ls_bkpf-gjahr.
IF sy-subrc = 0.
gs_event_log-Activity = 'Invoice Reversed'.
CONVERT DATE ls_rev_bkpf-budat INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_rev_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDLOOP.
* --- NOTE: The logic for MM invoices (from lt_rbkp) would be similar, joining RBKP with RSEG.
* --- NOTE: The logic for Payment Blocks and Workflow events requires reading change documents (CDHDR/CDPOS)
* --- or custom workflow tables. Below is a conceptual example for payment blocks.
* --- Conceptual Example for 'Payment Block Set' / 'Released' using Change Docs
* DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_cdhdr TYPE cdhdr,
* lt_cdpos TYPE TABLE OF cdpos, ls_cdpos TYPE cdpos.
* SELECT * FROM cdhdr INTO TABLE lt_cdhdr
* WHERE objectclas = 'BELEG' AND objectid IN (SELECT belnr FROM bkpf WHERE ...).
* LOOP AT lt_cdhdr.
* SELECT * FROM cdpos INTO TABLE lt_cdpos
* WHERE changenr = ls_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
* LOOP AT lt_cdpos.
* "... logic to create 'Payment Block Set' (if VALUE_NEW is not blank)
* "... or 'Payment Block Released' (if VALUE_NEW is blank) events.
* ENDLOOP.
* ENDLOOP.
* --- Conceptual Example for Workflow events ('Sent For Approval', 'Approved', 'Rejected')
* --- This part MUST be customized based on your specific workflow implementation (e.g., OpenText VIM, SAP WF).
* --- You would query the relevant workflow tables or status change tables here.
*&---------------------------------------------------------------------*
*& Write to File
*&---------------------------------------------------------------------*
END-OF-SELECTION.
DATA: lv_string TYPE string,
lv_header TYPE string.
" Create Header
lv_header = 'InvoiceNumber;Activity;EventTime;UserName;VendorNumber;PurchaseOrderNumber;InvoiceAmount;PostingDate;PaymentDueDate;PaymentBlockReason;ClearingDate'.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
TRANSFER lv_header TO p_fpath.
LOOP AT gt_event_log INTO gs_event_log.
CONCATENATE gs_event_log-InvoiceNumber
gs_event_log-Activity
gs_event_log-EventTime
gs_event_log-UserName
gs_event_log-VendorNumber
gs_event_log-PurchaseOrderNumber
gs_event_log-InvoiceAmount
gs_event_log-PostingDate
gs_event_log-PaymentDueDate
gs_event_log-PaymentBlockReason
gs_event_log-ClearingDate
INTO lv_string SEPARATED BY ';'.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
ELSE.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF. ¿Listo para comenzar?
Al seguir este Template, podrá obtener información valiosa y lograr mejoras significativas en su proceso Purchase to Pay de procesamiento de facturas. Comience hoy mismo a extraer sus datos y transforme sus operaciones.
Optimice hoy su procesamiento de facturas Purchase to Pay
Identifique las ineficiencias y reduzca un 30 % el tiempo del ciclo de facturación.
No necesita tarjeta de crédito. Configuración en minutos.