Su Template de datos para el procesamiento de pagos de cuentas por pagar
Su Template de datos para el procesamiento de pagos de cuentas por pagar
- Atributos clave para analizar proveedores y pagos
- Hitos esenciales del ciclo de pagos
- Lógica de extracción específica para sistemas SAP S/4HANA
Atributos del procesamiento de pagos de cuentas por pagar
| Nombre | Descripción | ||
|---|---|---|---|
| Actividad Activity | La tarea específica o el cambio de estado del evento registrado para la factura. | ||
| Descripción Este atributo representa los distintos pasos del proceso que tienen lugar durante el ciclo de vida de la factura. Registra eventos como la creación, contabilización y bloqueo de la factura, su aprobación y la compensación del pago. Los nombres de las actividades se obtienen de los códigos de transacción, las entradas del registro de cambios o las actualizaciones del estado del flujo de trabajo en el sistema de origen. Este campo es fundamental para analizar las variantes del flujo del proceso. Permite al motor de Process Mining visualizar la secuencia de pasos, detectar ciclos de retrabajo y determinar en qué puntos el proceso se desvía de la ruta ideal estándar. Es un componente esencial del registro de eventos. Por qué es importante Define los nodos del mapa del proceso y permite visualizar el flujo de trabajo y los cuellos de botella. Dónde obtenerlo Obtenido de los códigos de transacción (TCODE) o de la cabecera (CDHDR) y las posiciones (CDPOS) del documento de cambios Ejemplos Factura contabilizadaBloqueo de pago aplicadoEjecución del ciclo de pagosFactura compensada | |||
| Hora del evento EventTime | La marca de tiempo exacta en que tuvo lugar la actividad. | ||
| Descripción La hora del evento registra la fecha y hora exactas en que se guardó una actividad en la base de datos de SAP. Proporciona la dimensión temporal necesaria para ordenar los eventos cronológicamente dentro de un caso. Esta marca de tiempo suele construirse combinando los campos de fecha y hora de CPU de los registros del sistema o de las cabeceras de los documentos. En el análisis, este atributo es esencial para calcular los tiempos de ciclo, la duración y el rendimiento. Permite medir los intervalos entre pasos, como el tiempo transcurrido entre la recepción de una factura y su aprobación final. Esto resulta fundamental para identificar cuellos de botella y evaluar el rendimiento de los KPI, como el tiempo medio de aprobación de facturas. Por qué es importante Establece el orden cronológico de los eventos y sirve de base para todos los cálculos de rendimiento relacionados con el tiempo. Dónde obtenerlo Tabla SAP BKPF, campos CPUDT (fecha de entrada) y CPUTM (hora de entrada), o campos UDATE y UTIME de CDHDR Ejemplos 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Número de factura InvoiceNumber | Identificador único de la factura del proveedor que se está procesando. | ||
| Descripción El número de factura es la clave principal para seguir el ciclo de vida de una partida por pagar en SAP S/4HANA. Se refiere específicamente al número de documento contable que se genera al contabilizar la factura en el libro mayor. En la terminología estándar de SAP, corresponde al número de documento (BELNR) dentro de un código de sociedad y un ejercicio fiscal determinados. En el análisis de procesos, este atributo funciona como ID del caso. Vincula todas las actividades, desde la recepción y el aparcamiento iniciales de la factura hasta los distintos bloqueos y modificaciones de aprobación, y la compensación final del pago. Al agrupar los eventos por este identificador, los analistas pueden reconstruir el historial completo de cada obligación de pago. Por qué es importante Funciona como el ID definitivo del caso y permite reconstruir de principio a fin el flujo del proceso de pago. Dónde obtenerlo Tabla SAP BKPF (cabecera del documento contable), campo BELNR, o tabla ACDOCA, campo BELNR Ejemplos 1900000523510000289119000006015100003002 | |||
| Sistema de origen SourceSystem | Identificador de la instancia de SAP S/4HANA de la que proceden los datos. | ||
| Descripción Este atributo identifica la instalación de ERP o el cliente específico del que se extrajeron los datos del proceso. En entornos con varias instancias de SAP o sistemas heredados en paralelo, este campo permite mantener la trazabilidad de los datos y comparar distintos sistemas. En el análisis, este campo funciona como filtro de alto nivel. Ayuda a los analistas a separar los datos al comparar el rendimiento de instalaciones regionales distintas o al validar la coherencia de los datos durante proyectos de migración de sistemas. También permite contextualizar correctamente las variaciones del proceso atribuibles a la configuración del sistema. Por qué es importante Distingue las fuentes de datos en entornos con varios sistemas y permite segmentarlos correctamente. Dónde obtenerlo ID del sistema (SY-SYSID) del contexto de instalación de SAP Ejemplos SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se extrajo o actualizó el registro por última vez. | ||
| Descripción La última actualización de datos indica cuándo se cargaron correctamente los datos en la plataforma de Process Mining. No refleja la hora del evento de negocio, sino la actualidad del conjunto de datos. Esto es fundamental para mantener la confianza en los Dashboards de análisis. En el análisis, este atributo ayuda a los usuarios a saber si la información que consultan está actualizada. Es especialmente importante al supervisar Dashboards casi en tiempo real, como el Análisis de bloqueos de pago, para que las decisiones se basen en el estado más reciente del sistema SAP S/4HANA. Por qué es importante Informa a los usuarios de la actualidad de los datos, algo fundamental para los Dashboards operativos. Dónde obtenerlo Generado por el proceso de ETL o extracción Ejemplos 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| ¿Pago atrasado? IsLatePayment | Indicador booleano que señala si el pago se realizó después de la fecha neta de vencimiento. | ||
| Descripción Este atributo calculado devuelve el valor verdadero si la fecha de compensación es posterior a la fecha neta de vencimiento. Funciona como clasificador binario del rendimiento del proceso. En el análisis, este indicador permite contar los casos que no cumplen los requisitos para el KPI de frecuencia de penalizaciones por pago tardío. También facilita la creación de Dashboards, ya que basta con contar los valores «Verdadero» en lugar de realizar cálculos complejos con fechas en la visualización. Por qué es importante Facilita el cálculo de los KPI de pagos puntuales. Dónde obtenerlo Calculado: Fecha de compensación > Fecha neta de vencimiento Ejemplos truefalse | |||
| Código de sociedad CompanyCode | Unidad organizativa para la que se elaboran el balance y la cuenta de pérdidas y ganancias. | ||
| Descripción El código de sociedad representa la entidad contable independiente dentro de la empresa. Es la unidad organizativa central de la contabilidad externa y se utiliza para estructurar los datos financieros. Cada factura se asigna a un único código de sociedad. En el análisis, este atributo permite segmentar los KPI por entidad jurídica o región. Se utiliza en los Dashboards para comparar la eficiencia de los equipos de cuentas por pagar de distintas filiales. Por ejemplo, ayuda a detectar si una sucursal concreta tiene más bloqueos manuales de pago que el estándar corporativo. Por qué es importante Segmenta el proceso por entidad jurídica y facilita las comparaciones internas. Dónde obtenerlo Tabla SAP BKPF, campo BUKRS Ejemplos US01DE1010002000 | |||
| Condiciones de pago PaymentTerms | Clave que representa las condiciones acordadas para los pagos y los descuentos. | ||
| Descripción Las condiciones de pago establecen cuándo vence una factura y si se aplican descuentos por pronto pago. Este código (por ejemplo, Z001) corresponde a reglas como «neto a 30 días» o «2 % a 10 días, neto a 30 días». Se copia de los datos maestros del proveedor a la factura, pero puede modificarse manualmente. En el análisis, este atributo es fundamental para los Dashboards Optimizador de descuentos por pronto pago y Cumplimiento de las condiciones de pago a proveedores. Permite al sistema calcular la fecha base de vencimiento e identificar si el pago se realizó dentro del plazo óptimo para aprovechar el ahorro. Por qué es importante Determina el plazo previsto y los incentivos financieros, aspectos clave para analizar los descuentos. Dónde obtenerlo Tabla SAP BSEG, campo ZTERM Ejemplos Z001NT300001 | |||
| Fecha de compensación ClearingDate | Fecha en que se compensó la factura mediante el pago. | ||
| Descripción La fecha de compensación registra cuándo se saldó la partida abierta del libro auxiliar de cuentas por pagar, normalmente mediante un ciclo de pagos o la contabilización manual de un pago. Esto marca, en la práctica, el fin del pasivo. En el análisis, este atributo se utiliza para calcular el tiempo de ciclo total del proceso. Es la marca de tiempo de la actividad Pago compensado y se compara con la fecha neta de vencimiento para determinar si el pago se realizó a tiempo. También alimenta directamente el Dashboard de eficiencia de compensación de pagos. Por qué es importante Marca la finalización del proceso de pago y permite determinar si el pago se realizó a tiempo. Dónde obtenerlo Tabla SAP BSEG o AUGDT, campo AUGDT Ejemplos 2023-11-012023-11-15 | |||
| Fecha neta de vencimiento NetDueDate | Fecha calculada antes de la cual debe pagarse la factura para evitar penalizaciones. | ||
| Descripción La fecha neta de vencimiento es la fecha límite definitiva para el pago. Se calcula sumando el plazo máximo de pago a la fecha base. Aunque a veces se almacena explícitamente, suele ser un campo calculado en las vistas de análisis. En el análisis, es el principal punto de referencia del Seguimiento de pagos atrasados y penalizaciones. Al comparar la fecha de compensación real con la fecha neta de vencimiento, se obtiene la métrica de días de retraso en el pago, que ayuda a cuantificar la eficiencia del equipo de cuentas por pagar y el riesgo de tensiones con los proveedores. Por qué es importante Es la fecha límite prevista del proceso; no cumplirla afecta a la calificación crediticia y genera costes. Dónde obtenerlo Calculada: fecha base + días máximos de las condiciones de pago (ZBD1T/ZBD2T/ZBD3T) Ejemplos 2023-11-302023-12-01 | |||
| Importe de la factura InvoiceAmount | Importe bruto total de la factura en la moneda del documento. | ||
| Descripción Este atributo refleja el valor financiero de la factura tal como figura en el documento de origen. Representa el pasivo que debe liquidarse con el proveedor. En SAP S/4HANA, suele almacenarse en el campo Importe en moneda del documento. En el análisis, el importe de la factura se utiliza para priorizar el trabajo. Dashboards como Distribución de puntos de intervención manual utilizan este campo para mostrar si se están dedicando tareas manuales que requieren mucho esfuerzo a facturas de bajo valor. Así, la organización puede centrar las iniciativas de optimización en transacciones de alto valor, donde los fallos del proceso conllevan un mayor riesgo financiero. Por qué es importante Indica el peso financiero del caso y es esencial para priorizar las ineficiencias del proceso que afectan a importes elevados. Dónde obtenerlo Tabla SAP BKPF o BSEG, campo WRBTR Ejemplos 1500.00250.5010000.00 | |||
| Motivo del bloqueo de pago PaymentBlockReason | Código que indica por qué se bloquea una factura para el pago. | ||
| Descripción Este atributo contiene el código del motivo específico aplicado a una factura que impide que el ciclo de pagos automático la incluya. Algunos ejemplos son A para bloqueo de pago, R para verificación de factura o bloqueos manuales establecidos por los usuarios. En el análisis, este campo es el principal indicador del Dashboard de análisis de bloqueos manuales de pago. Al agrupar la frecuencia de los distintos motivos de bloqueo, la organización puede diagnosticar problemas sistémicos, como diferencias de precio frecuentes o recepciones de mercancías pendientes, que retrasan el proceso de pago. Por qué es importante Identifica la causa concreta de las interrupciones del proceso y permite analizar sus causas raíz de forma específica. Dónde obtenerlo Tabla SAP BSEG, campo ZLSPR Ejemplos ABR* | |||
| Nombre de usuario UserName | ID del usuario que realizó la actividad específica. | ||
| Descripción El nombre de usuario registra el ID de inicio de sesión de la persona o del agente del sistema responsable de ejecutar un paso del proceso. Puede tratarse de una persona que introduce datos manualmente o del ID de un proceso en segundo plano (por ejemplo, BATCH_USER) que realiza tareas automatizadas. En el análisis, este atributo permite calcular la tasa de automatización de actividades. Al distinguir entre usuarios y cuentas del sistema, los analistas pueden medir el nivel de automatización del proceso. También se utiliza en el Dashboard de distribución de puntos de intervención manual para evaluar la carga de trabajo de los equipos. Por qué es importante Distingue el trabajo manual del automatizado y permite calcular la tasa de automatización. Dónde obtenerlo Tabla SAP BKPF, campo USNAM, o tabla CDHDR, campo USERNAME Ejemplos BSMITHWF-BATCHRJONES | |||
| Número de proveedor VendorNumber | Identificador único del proveedor asociado a la factura. | ||
| Descripción El número de proveedor corresponde a la cuenta del acreedor en el libro auxiliar de SAP. Vincula la factura con los datos maestros que contienen las condiciones de pago, los datos bancarios y la información de contacto. En S/4HANA, suele estar vinculado al concepto de socio comercial, aunque en muchas tablas se conserva el nombre del campo heredado LIFNR. En el análisis, este atributo es fundamental para el Dashboard de cumplimiento de las condiciones de pago a proveedores. Permite a los analistas agrupar el rendimiento del proceso por proveedor e identificar a aquellos que provocan bloqueos, diferencias de precio o retrasos de forma recurrente. También facilita las decisiones estratégicas de abastecimiento y la gestión de las relaciones con proveedores. Por qué es importante Permite agrupar el rendimiento por proveedor, algo fundamental para identificar las causas de los retrasos. Dónde obtenerlo Tabla SAP BKPF, campo LIFNR, o tabla ACDOCA, campo LIFNR Ejemplos 100050VEND-US-99200400 | |||
| Sin intervención manual IsTouchless | Indicador booleano que señala si la factura se procesó sin intervención manual. | ||
| Descripción Este atributo se calcula analizando el flujo de eventos de un caso. Si el caso contiene únicamente actividades automatizadas (por ejemplo, realizadas por el usuario «system» o mediante determinados TCODES en segundo plano) y no presenta cambios ni bloqueos manuales, se clasifica como procesado sin intervención manual. En el análisis, esta es la métrica principal del KPI de tasa de facturas procesadas sin intervención manual. Permite a la organización hacer seguimiento de los resultados de las iniciativas de automatización e identificar qué tipos de casos (por ejemplo, por proveedor o región) avanzan correctamente por el sistema sin intervención humana. Por qué es importante Es la medida principal de la automatización y la eficiencia del proceso. Dónde obtenerlo Calculado según la secuencia de actividades y los tipos de usuario Ejemplos truefalse | |||
| Tipo de documento DocumentType | Clasifica el documento contable (por ejemplo, factura de proveedor, pago o nota de crédito). | ||
| Descripción El tipo de documento es un código de dos caracteres de SAP que clasifica la transacción contable. Entre los tipos habituales están KR para facturas de proveedores, KZ para pagos a proveedores y RE para la recepción bruta de facturas. Determina el rango de números y el estado de los campos del documento. En el análisis, este atributo se utiliza para filtrar el alcance del proceso. Por ejemplo, un analista puede excluir las notas de crédito para centrarse únicamente en la eficiencia de los pagos salientes. También ayuda a identificar la combinación de tipos de transacción procesados y sirve de apoyo al Dashboard de complejidad de las variantes del proceso. Por qué es importante Clasifica el caso (factura o nota de crédito) y permite filtrar el análisis. Dónde obtenerlo Tabla SAP BKPF, campo BLART Ejemplos KRREKZKG | |||
| Días para el primer descuento por pronto pago CashDiscountDays1 | Número de días desde la fecha base durante los que está disponible el primer descuento por pronto pago. | ||
| Descripción Este atributo define el plazo para obtener las condiciones de pago más favorables (por ejemplo, el 10 en «2 % a 10 días, neto a 30 días»). Se obtiene de las condiciones almacenadas en la partida de la factura. En el análisis, ayuda a determinar la fecha objetivo del Optimizador de descuentos por pronto pago. Si la factura se compensa dentro de este plazo, se obtiene el descuento. Este campo permite medir el coste de oportunidad de los ciclos de procesamiento lentos. Por qué es importante Define el plazo para aprovechar el ahorro financiero. Dónde obtenerlo Tabla SAP BSEG, campo ZBD1T Ejemplos 10140 | |||
| Documento de compras PurchasingDocument | Número del pedido de compra asociado a la factura. | ||
| Descripción Este atributo vincula la factura con el proceso de compras previo. Contiene el número del pedido de compra (PO) con el que se coteja la factura. No todas las facturas, como las de gastos varios, tienen una referencia a un pedido de compra. En el análisis, este campo es esencial para el análisis de la tasa de cotejo de tres vías. Permite a los analistas separar las facturas vinculadas a pedidos de compra de las que no lo están, ya que suelen seguir flujos de aprobación muy distintos. También facilita el Process Mining de principio a fin al vincular los datos de cuentas por pagar con los de compras. Por qué es importante Vincula las cuentas por pagar con compras, permite analizar el cotejo de tres vías y ampliar el análisis del proceso. Dónde obtenerlo Tabla SAP BSEG, campo EBELN Ejemplos 45000012344500009876 | |||
| Ejercicio fiscal FiscalYear | Ejercicio fiscal al que pertenece la factura. | ||
| Descripción El ejercicio fiscal es un periodo utilizado para la presentación de informes financieros. Junto con el código de sociedad y el número de documento, forma la clave primaria compuesta de un documento financiero en SAP. En el análisis, es un requisito técnico para identificar los casos de forma única y también permite elaborar informes interanuales. Garantiza que el ID del caso Número de factura siga siendo único incluso al analizar décadas de datos históricos. Por qué es importante Requisito técnico para identificar casos de forma única en SAP FI. Dónde obtenerlo Tabla SAP BKPF, campo GJAHR Ejemplos 20232024 | |||
| Fecha base BaselineDate | Fecha a partir de la cual se aplican las condiciones de pago y se calculan los vencimientos. | ||
| Descripción La fecha base es el punto de partida para calcular la fecha neta de vencimiento y los periodos de descuento por pronto pago. Suele ser la fecha de factura o la fecha de contabilización, según la configuración y los datos maestros del proveedor. En el análisis, esta fecha es un requisito técnico para calcular el estado de pago atrasado. Los errores en la fecha base suelen provocar pagos anticipados (con impacto en el flujo de caja) o pagos atrasados (con posibles penalizaciones). Verificar que esta fecha sea correcta forma parte del análisis de cumplimiento de las condiciones de pago a proveedores. Por qué es importante Es el punto de referencia para calcular todas las fechas de vencimiento. Dónde obtenerlo Tabla SAP BSEG, campo ZFBDT Ejemplos 2023-10-012023-10-15 | |||
| Importe de descuentos perdidos DiscountLostAmount | Valor monetario de los descuentos por pronto pago disponibles que no se aprovecharon. | ||
| Descripción Este atributo calculado representa el dinero que se dejó de ahorrar. Se obtiene comprobando si el pago se realizó después de la fecha límite para obtener el descuento y, en ese caso, calculando el valor del porcentaje de descuento perdido sobre el importe de la factura. En el análisis, es una métrica financiera clave para el optimizador de descuentos por pronto pago. Cuantifica en términos monetarios el coste de la ineficiencia y aporta argumentos sólidos para mejorar el proceso. Por qué es importante Cuantifica la pérdida financiera directa causada por los retrasos del proceso. Dónde obtenerlo Calculado: si la fecha de compensación > fecha límite del descuento, entonces importe de la factura * porcentaje de descuento Ejemplos 30.000.00150.00 | |||
| Moneda Currency | Código de moneda asociado al importe de la factura. | ||
| Descripción El atributo Moneda especifica la divisa del importe de la factura, como USD, EUR o GBP. Permite interpretar correctamente los valores financieros y es esencial para agregar datos de distintos códigos de sociedad internacionales. En el análisis, este campo garantiza que los KPI financieros se calculen correctamente. A menudo se utiliza para convertir los valores a una moneda de presentación en los Dashboards globales. Sin este atributo, las métricas agregadas, como el gasto total o el importe medio de las facturas, carecerían de sentido en un entorno multidivisa. Por qué es importante Aporta contexto a los importes financieros y es esencial para elaborar informes globales precisos. Dónde obtenerlo Tabla SAP BKPF, campo WAERS Ejemplos USDEURGBPJPY | |||
| Porcentaje del primer descuento por pronto pago CashDiscountPercentage1 | Porcentaje de descuento disponible si se paga durante el primer periodo de descuento. | ||
| Descripción Este atributo representa el porcentaje del incentivo financiero que ofrece el proveedor por pagar antes de tiempo (por ejemplo, el 2 en «2 % a 10 días»). En el análisis, se utiliza para calcular el valor del descuento potencial por pronto pago. Al multiplicar este porcentaje por el importe de la factura, los Dashboards pueden mostrar el dinero que se deja de ahorrar debido a las ineficiencias del proceso y respaldar el caso de negocio para la automatización. Por qué es importante Cuantifica el ahorro potencial y es esencial para calcular el ROI. Dónde obtenerlo Tabla SAP BSEG, campo ZBD1P Ejemplos 2.03.00.0 | |||
Actividades del procesamiento de pagos de cuentas por pagar
| Actividad | Descripción | ||
|---|---|---|---|
| Bloqueo de pago aplicado | Indica que se ha aplicado un bloqueo de pago a la partida de la factura, lo que impide que se incluya en la ejecución de pagos. Se registra mediante el seguimiento de los cambios en el campo ZLSPR de la tabla BSEG a través de los documentos de modificación. | ||
| Por qué es importante Los bloqueos son la principal causa de los pagos atrasados y de las fricciones en el proceso, y afectan directamente al Dashboard de análisis de bloqueos manuales de pago. Dónde obtenerlo Tablas CDPOS y CDHDR (documentos de modificación), para buscar actualizaciones del campo BSEG-ZLSPR. Capturar Se registra cuando cambia el valor de ZLSPR en los registros de CDPOS Tipo de evento explicit | |||
| Bloqueo de pago eliminado | Indica que se ha levantado un bloqueo de pago aplicado anteriormente y que la factura queda habilitada para el pago. Se identifica cuando el campo ZLSPR de BSEG cambia de un valor a nulo o vacío. | ||
| Por qué es importante A menudo sirve como indicador de 'Factura aprobada' en sistemas sin registros explícitos del flujo de trabajo y marca el final del periodo de bloqueo. Dónde obtenerlo Tablas CDPOS y CDHDR, para buscar cambios que dejen vacío el campo BSEG-ZLSPR. Capturar Se registra cuando los registros de CDPOS indican que se ha eliminado ZLSPR Tipo de evento explicit | |||
| Documento de pago creado | Generación del documento contable que abona el banco y carga al proveedor. Se encuentra en BKPF con un tipo de documento de pago (por ejemplo, ZP o KZ). | ||
| Por qué es importante La materialización financiera del pago, utilizada para calcular los días pendientes de pago (DPO). Dónde obtenerlo Tabla BKPF, filtrada por el tipo de documento (BLART) específico de los pagos. Capturar Registrado al crear el documento de pago en BKPF Tipo de evento explicit | |||
| Ejecución del ciclo de pagos | Representa la ejecución del ciclo de pagos, durante la cual se generan las instrucciones de transferencia de fondos. Se registra mediante la actualización del estado en las tablas REGUH o REGUP. | ||
| Por qué es importante El compromiso operativo de pagar, fundamental para analizar la eficiencia del proceso de agrupación de pagos. Dónde obtenerlo Tabla REGUH, normalmente relacionada con la fecha y la identificación del ciclo. Capturar Registrado al actualizarse el estado del ciclo de pagos Tipo de evento explicit | |||
| Factura contabilizada | Representa el registro oficial de la obligación en el libro mayor. Esta actividad se obtiene de la marca de tiempo de creación de la tabla BKPF o de la fecha de entrada de la tabla ACDOCA. | ||
| Por qué es importante Es el punto de partida principal de la cronología financiera y establece la referencia para las fechas de vencimiento y el análisis de antigüedad. Dónde obtenerlo Tabla BKPF, con CPUDT (fecha de entrada) y CPUTM (hora de entrada). Capturar Se registra cuando se crea un registro en BKPF Tipo de evento explicit | |||
| Pago compensado | Marca la conciliación final, cuando la partida abierta de la cuenta del proveedor se compensa con el pago. Se captura en el campo AUGDT (fecha de compensación) de la tabla BSEG. | ||
| Por qué es importante El estado final del proceso, que indica que el ciclo de vida ha concluido y que los libros están equilibrados. Una tasa elevada de compensaciones manuales indica ineficiencias en la conciliación. Dónde obtenerlo Tabla BSEG, campo AUGDT (fecha de compensación). Capturar Registrado al completarse el campo AUGDT Tipo de evento explicit | |||
| Condiciones de pago modificadas | Registra una actualización de las condiciones de pago de una factura abierta, que modifica la fecha de vencimiento o la elegibilidad para descuentos. Se realiza un seguimiento mediante los registros de cambios del campo ZTERM de la tabla BSEG. | ||
| Por qué es importante Los cambios frecuentes pueden indicar errores en los datos maestros o modificaciones manuales que afectan a las previsiones de flujo de caja y al cumplimiento de las condiciones de pago de los proveedores. Dónde obtenerlo Tablas CDPOS y CDHDR, para buscar actualizaciones del campo BSEG-ZTERM. Capturar Se registra cuando cambia el valor de ZTERM en los registros de CDPOS Tipo de evento explicit | |||
| Descuento por pronto pago perdido | Evento calculado que marca la fecha en que vence el plazo para optar a un descuento por pronto pago. Se obtiene al comparar la fecha límite del descuento con la fecha actual o la fecha de pago. | ||
| Por qué es importante Es esencial para que el optimizador de descuentos por pronto pago muestre las oportunidades financieras perdidas. Dónde obtenerlo Calculado: BSEG-ZFBDT + BSEG-ZBD1T (días del primer descuento). Capturar Se obtiene al comparar la fecha con la fecha límite del descuento Tipo de evento calculated | |||
| Desviación de cantidad detectada | Actividad inferida que indica una discrepancia entre la cantidad facturada y la cantidad recibida. Se deduce al observar la aplicación de una clave de bloqueo de pago específica a la partida, normalmente 'M' para las desviaciones de cantidad. | ||
| Por qué es importante Es fundamental para analizar la eficiencia de la conciliación y la calidad de los datos de la cadena de suministro. Dónde obtenerlo Se infiere del valor 'M' de BSEG-ZLSPR (o de la configuración específica del sistema para los bloqueos por cantidad). Capturar Compare el valor de ZLSPR con 'M' Tipo de evento inferred | |||
| Desviación de precio detectada | Actividad inferida que indica una discrepancia entre el precio de la factura y el precio de la orden de compra. Se deduce al observar la aplicación automática de una clave de bloqueo de pago específica, normalmente 'R' para la verificación de facturas, al contabilizar. | ||
| Por qué es importante Identifica las causas raíz del retrabajo manual y contribuye al análisis de la tasa de conciliación de tres vías. Dónde obtenerlo Se infiere del valor 'R' de BSEG-ZLSPR (o de la configuración específica del sistema para los bloqueos por precio) en el momento de la contabilización. Capturar Compare el valor de ZLSPR con 'R' Tipo de evento inferred | |||
| Factura anulada | Indica que el documento de factura se anuló o canceló. Se captura comprobando que el campo STBLG (documento de anulación) de la tabla BKPF tenga un valor. | ||
| Por qué es importante Representa retrabajo y fallos del proceso, y permite identificar desperdicios y posibles duplicaciones de tareas. Dónde obtenerlo Tabla BKPF, el campo STBLG no está vacío. Capturar Registrado al completarse el campo STBLG Tipo de evento explicit | |||
| Factura aparcada | Indica que una factura se ha introducido en SAP, pero aún no se ha contabilizado en el libro mayor. Suele utilizarse para la entrada preliminar de datos. Se registra directamente en la tabla VBKPF o mediante la identificación de documentos con estado aparcado en BKPF antes de que pasen a contabilizados. | ||
| Por qué es importante El aparcamiento marca el inicio de la fase de entrada de datos y permite medir el tiempo transcurrido entre la recepción y el reconocimiento de la obligación financiera. Dónde obtenerlo Tabla VBKPF para los datos de cabecera de los documentos aparcados o BKPF con un estado de documento específico (BSTAT = V). Capturar Se registra cuando se crea una entrada en VBKPF Tipo de evento explicit | |||
| Factura vencida | Marca de tiempo calculada que representa el momento en que la factura alcanza su fecha de vencimiento neta. Se obtiene sumando los días de las condiciones de pago a la fecha base de la tabla BSEG. | ||
| Por qué es importante Sirve como referencia para el rendimiento de los pagos puntuales y el seguimiento de penalizaciones por pagos atrasados. Dónde obtenerlo Calculado: BSEG-ZFBDT (fecha base) + BSEG-ZBD1T/ZBD2T/ZBD3T (días). Capturar Se obtiene al comparar la fecha actual con la fecha de vencimiento neta Tipo de evento calculated | |||
| Propuesta de pago creada | Indica que la factura se ha incluido en una ejecución de propuesta de pago (F110), el primer paso del programa de pagos automatizado. Se registra a partir de la tabla REGUH, que almacena los datos de liquidación. | ||
| Por qué es importante Indica que la factura se ha seleccionado para el pago y ha superado las comprobaciones de validación del programa de pagos. Dónde obtenerlo Marca de tiempo de creación de la tabla REGUH (claves LAUFD y LAUFI). Capturar Registrado al crear el registro REGUH Tipo de evento explicit | |||
Guías de extracción
Pasos
Identifique las vistas CDS necesarias: Confirme que estén disponibles las vistas CDS estándar de SAP S/4HANA. Las vistas principales necesarias son I_JournalEntry (cabecera), I_OperationalAcctgDocItem (partidas, equivalente a BSEG), I_SupplierInvoice (logística), I_PaymentProposalItem (F110) e I_ChangeDocument (para los registros).
Configure los permisos de usuario: Asegúrese de que el usuario de la base de datos o el usuario técnico de servicio tenga permisos SELECT sobre las vistas SQL DDL asociadas a las entidades CDS. Esto suele gestionarse desde SAP HANA Studio o ABAP Development Tools para Eclipse (ADT).
Prepare el entorno SQL: Abra su interfaz SQL (por ejemplo, SAP HANA Studio, DBeaver conectado a HANA o un conector de Process Mining que admita SQL). Este método presupone acceso SQL directo a la capa HANA, donde las vistas CDS están expuestas como vistas.
Defina el alcance: Determine el código de sociedad (CompanyCode) y el intervalo de ejercicios fiscales para limitar el volumen de datos. Esto es fundamental para el rendimiento al consultar la vista de partidas de documentos contables operativos.
Implemente la lógica de actividades: Copie la consulta SQL que aparece a continuación. Esta consulta utiliza UNION ALL para combinar 14 bloques lógicos distintos en una única estructura de Registro de eventos. Cada bloque corresponde a una actividad concreta (por ejemplo, factura contabilizada o pago compensado).
Gestione los documentos de modificación: La consulta incluye secciones para los cambios en las condiciones de pago y la modificación de bloqueos. Estas utilizan la vista I_ChangeDocument. Si esta vista no está activa en su versión de S/4, quizá deba incluir las tablas subyacentes (CDHDR/CDPOS) en una vista CDS personalizada.
Revise los eventos calculados: Revise la lógica de los eventos «Factura vencida» y «Descuento por pronto pago perdido». Se calculan sumando días a la fecha base que figura en la vista de partidas operativas.
Ejecute la extracción: Ejecute la consulta. Para conjuntos de datos grandes, se recomienda encarecidamente dividir la extracción por ejercicio fiscal o código de sociedad para evitar que se agote la memoria.
Verifique los formatos de fecha: Asegúrese de que la columna EventTime tenga el formato YYYY-MM-DD HH:MM:SS. SAP HANA SQL devuelve marcas de tiempo que quizá deban convertirse según la aplicación de destino.
Exporte los datos: Guarde el conjunto de resultados como archivo CSV o Parquet. Compruebe que los encabezados coincidan con las columnas definidas en la instrucción SELECT final.
Transforme los datos para cargarlos: Si su herramienta de Process Mining requiere un formato CSV específico (por ejemplo, un formato concreto para las fechas), aplique estas transformaciones en un script posterior al procesamiento o mediante funciones TO_VARCHAR en SQL.
Realice la validación final: Cargue una muestra en ProcessMind y compruebe que el ID del caso (número de factura) agrupe correctamente todas las actividades, desde la contabilización hasta la compensación.
Configuración
- Filtro de código de sociedad: Limite la consulta a unidades organizativas específicas (CompanyCode = '1000') para mantener el contexto y el rendimiento.
- Intervalo de fechas: Aplique un filtro a PostingDate o CreationDate (por ejemplo, los últimos 12 meses) para controlar el volumen de datos.
- Tipo de cuenta: Filtre I_OperationalAcctgDocItem por FinancialAccountType = 'K' (proveedor) para excluir las partidas de cuentas de mayor y de clientes.
- Activación de vistas CDS: Asegúrese de que las vistas I_JournalEntry, I_OperationalAcctgDocItem e I_PaymentProposalItem estén activas y habilitadas para el acceso SQL.
- Rendimiento del registro de cambios: Consultar I_ChangeDocument puede consumir muchos recursos. Limite estas subconsultas por ObjectClass 'BELEG' y por nombres de campo específicos, como ZLSPR y ZTERM.
Consulta de ejemplo sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Pasos
- Confirme que dispone de acceso SQL directo al esquema de SAP HANA que contiene ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP y las tablas de documentos de modificación pertinentes. Sustituya [Your SAP HANA schema] y los datos de conexión por valores aprobados para su sistema.
- Confirme la población de facturas y el período del informe. Configure [Start date] y [End date] con el formato YYYYMMDD, y establezca [Company code filter] como un predicado SQL válido, por ejemplo, BUKRS IN ('1000','2000').
- Valide la versión de SAP y la configuración local de los documentos aparcados, los campos de estado del programa de pagos, los tipos de documento de pago y el almacenamiento de documentos de modificación. La consulta utiliza objetos de origen documentados y asignaciones de campos conservadoras, pero debe comprobar las extensiones locales y las diferencias entre versiones antes de usarla en producción.
- Ejecute la consulta en SAP HANA con un cliente SQL o un servicio de extracción aprobado. La consulta crea una fila de evento por cada actividad extraída de forma explícita. ProcessMind no inferirá actividades que no estén en los resultados.
- Revise los datos de origen y ajuste los predicados de configuración señalados para el estado de documentos aparcados, los tipos de documento de pago, el estado de las propuestas y ejecuciones de pago, y las clases de objeto de los documentos de modificación. No amplíe estos predicados sin conciliar los documentos contables duplicados o no relacionados.
- Valide las uniones con InvoiceNumber, CompanyCode, el ejercicio fiscal, el número de documento contable, el número de proveedor y la partida, cuando corresponda. Confirme que los números de documento de factura se representen de forma coherente en BKPF, BSEG, ACDOCA, REGUH y REGUP en el sistema de destino.
- Concilie los eventos calculados. «Factura vencida» se genera en la fecha neta de vencimiento calculada, y «Descuento por pronto pago perdido» se genera en la primera fecha límite aplicable para el descuento si no se realizó ningún pago antes de esa fecha. Son filas derivadas y deben distinguirse claramente de los eventos procedentes de registros de origen.
- Exporte el resultado como un archivo CSV plano con codificación UTF-8 o en otro formato tabular compatible con ProcessMind. Mantenga exactamente los nombres de columna InvoiceNumber, Activity, EventTime, SourceSystem y LastDataUpdate. Conserve una fila por evento y no agrupe las actividades por factura.
- Cargue el Registro de eventos en ProcessMind y asigne InvoiceNumber al identificador del caso, Activity al nombre de la actividad y EventTime a la marca de tiempo del evento. Asigne las demás columnas como atributos del evento o del caso según la configuración de importación de ProcessMind.
Configuración
- Intervalo de fechas: Para la extracción inicial, utilice un período móvil de 3 a 6 meses. Aplique de forma coherente los predicados de fecha de contabilización, fecha de modificación y fecha del programa de pagos. Amplíe el intervalo al validar condiciones de pago de larga duración.
- Esquema: Sustituya [Your SAP HANA schema] por el esquema que contiene los objetos de SAP. Confirme si el entorno expone objetos dependientes del mandante mediante el esquema seleccionado o si requiere un predicado explícito para el mandante.
- Filtro de sociedades: Configure [Company code filter] para limitar BUKRS a los códigos de sociedad necesarios. Aplique el mismo alcance a BKPF, BSEG, ACDOCA, REGUH, REGUP y las fuentes de documentos de modificación que dispongan de esos campos.
- Filtro de documentos: Revise el predicado para los tipos de documento de factura y el predicado para los tipos de documento de pago. La consulta incluye ejemplos comunes, pero los tipos de documento se pueden configurar y deben ajustarse al sistema de destino.
- Facturas aparcadas: Confirme cómo se representa el estado de los documentos aparcados en VBKPF o BKPF. La consulta utiliza un predicado configurable para este estado, ya que su codificación puede variar según la versión y la implementación.
- Modificaciones de pago: Confirme la clase de objeto, el nombre de la tabla, los nombres de campo y la representación de valores de BSEG-ZLSPR y BSEG-ZTERM en los documentos de modificación. Debe verificar el almacenamiento de estos documentos y los nombres de campo en el sistema de destino.
- Programa de pagos: Confirme qué campos de REGUH y REGUP se utilizan para el estado de las propuestas y ejecuciones, la fecha de ejecución, el identificador de ejecución y el vínculo con el documento contable. La configuración local del programa de pagos puede afectar los valores de estado disponibles.
- Rendimiento: Limite el intervalo de fechas y los códigos de sociedad, seleccione solo las columnas necesarias y aplique los filtros específicos de cada fuente antes de realizar las uniones. Para conjuntos de datos grandes, materialice subconjuntos de fuentes filtrados o utilice una vista de cálculo de HANA o un esquema de extracción aprobados.
- Autorizaciones: Se necesita acceso de lectura a los objetos pertinentes del esquema de SAP HANA y a las vistas que exponen datos contables, del programa de pagos y de documentos de modificación. Coordine el acceso con los equipos de seguridad de SAP y de gobernanza de datos.
- Requisitos funcionales: Deben estar activas y tener datos las funciones pertinentes de contabilidad financiera, cuentas por pagar, programa de pagos y documentos de modificación. Si la implementación no utiliza una tabla de origen, configure una alternativa aprobada conforme al diseño del sistema.
- Gestión de marcas de tiempo: BKPF y BSEG suelen proporcionar las fechas y horas en campos separados. La consulta los combina en una marca de tiempo. Confirme la zona horaria del sistema de origen y aplique la conversión necesaria antes de cargar los datos en ProcessMind.
- Protección de datos: Limite los datos de proveedores y contabilidad al alcance aprobado y aplique las políticas de conservación, enmascaramiento y acceso de la organización.
Consulta de ejemplo sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; ¿Todo listo para empezar?
Convierta sus datos financieros en información útil para la acción y empiece hoy a optimizar sus ciclos de pago. Nuestro equipo puede acompañarle en cada etapa de su recorrido con Process Mining.
Optimice el procesamiento de pagos de cuentas por pagar en SAP S/4HANA
Elimine cuellos de botella y reduzca el tiempo de ciclo un 30 %.
No se requiere tarjeta de crédito. Configuración en 5 minutos.