Su Plantilla de Datos de Pedido a Cobro - Facturación y Cobranza
Su Plantilla de Datos de Pedido a Cobro - Facturación y Cobranza
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de Extracción para SAP S/4HANA
Atributos de Order to Cash (Pedido a Cobro) - Facturación
| Nombre | Descripción | ||
|---|---|---|---|
| Número de Factura InvoiceNumber | El identificador único para un documento de facturación, que sirve como identificador principal del `case` para el proceso de facturación. | ||
| Descripción El Número de Factura, conocido como Número de Documento de Facturación en SAP, identifica de forma única cada transacción de facturación. Actúa como la clave central que vincula todas las actividades relacionadas, desde la creación y contabilización de la factura hasta la recepción y conciliación del pago. En Por qué es importante Es el identificador fundamental que conecta todas las actividades de facturación relacionadas en un único caso, haciendo posible el análisis de procesos de principio a fin. Dónde obtener SAP Table: VBRK, Field: VBELN Ejemplos 900012349000567890009012 | |||
| Hora del Evento EventTime | El `timestamp` preciso que indica cuándo ocurrió una actividad o `event`. | ||
| Descripción Event Time (Tiempo del Evento) proporciona la fecha y hora de cada actividad, formando la columna vertebral cronológica del proceso. Esta marca de tiempo es crucial para calcular duraciones, tiempos de ciclo y tiempos de espera entre diferentes pasos en el proceso de facturación. En el análisis, Event Time se utiliza para ordenar actividades secuencialmente, calcular indicadores clave de rendimiento (KPI) como los Días de Ventas Pendientes de Cobro y el Tiempo de Ciclo de Generación de Facturas, e identificar cuellos de botella basados en el tiempo. Permite una vista dinámica del proceso, mostrando cómo cambia el rendimiento con el tiempo y cuánto tarda cada etapa del ciclo de facturación. Por qué es importante Proporciona la secuencia cronológica de eventos, lo cual es esencial para calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo y las duraciones. Dónde obtener Extraído de varios campos de fecha y hora según la actividad, como fecha y hora de creación (VBRK-ERDAT, VBRK-ERZET), marcas de tiempo de cambio (CDHDR-UDATE, CDHDR-UTIME) o fecha de contabilización (BKPF-BUDAT). Ejemplos 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Nombre de la Actividad ActivityName | El nombre de la actividad o `event` de negocio que ocurrió dentro del proceso de facturación, como 'Factura Generada' o 'Pago Recibido'. | ||
| Descripción El Nombre de la Actividad describe un paso o hito específico en el ciclo de vida de la facturación. Estas actividades se derivan de varios Analizar la secuencia y frecuencia de estas actividades es el núcleo del Por qué es importante Este Dónde obtener Derivado de varias fuentes, incluyendo códigos de transacción (SY-TCODE), estados de documentos de cambio (tablas CDHDR/CDPOS) o registros de flujo de trabajo de negocio (por ejemplo, SWW_WI2OBJ). Ejemplos Factura GeneradaFactura Contabilizada en ContabilidadPago de cliente recibidoFactura Anulada | |||
| Fecha de Factura InvoiceDate | La fecha oficial en que la factura fue emitida al cliente. | ||
| Descripción La Fecha de Factura, también conocida como fecha de facturación en SAP, sirve como punto de partida para muchos cálculos financieros. Es la fecha a partir de la cual se determinan las condiciones de pago, las fechas de vencimiento y la antigüedad de la cuenta por cobrar. Esta fecha es un Por qué es importante Es la fecha principal para los cálculos financieros, actuando como punto de partida para el DSO, las fechas de vencimiento de pago y el análisis de antigüedad de facturas. Dónde obtener SAP Table: VBRK, Field: FKDAT Ejemplos 2023-03-202023-04-012023-05-18 | |||
| Fecha de Vencimiento de Pago PaymentDueDate | La fecha en la que se espera que el cliente pague la factura. | ||
| Descripción La Fecha de Vencimiento de Pago se calcula basándose en la fecha de la factura y las condiciones de pago acordadas. Representa la fecha límite para recibir el pago sin que la factura se convierta en vencida. Este Por qué es importante Establece la fecha límite para el pago del cliente, lo que lo hace crucial para calcular las tasas de pago a tiempo y gestionar las cuentas por cobrar. Dónde obtener Esta fecha no se almacena directamente, sino que se calcula basándose en la Fecha de Factura (VBRK-FKDAT) y la clave de Condiciones de Pago (VBRK-ZTERM) utilizando las funciones estándar de determinación de fechas de SAP. Ejemplos 2023-04-192023-05-012023-06-17 | |||
| Hora de Finalización EndTime | El `timestamp` preciso que indica cuándo se completó una actividad o `event`. | ||
| Descripción La Hora de Finalización marca la culminación de una actividad. En Este Por qué es importante Permite el cálculo de la duración exacta (tiempo de procesamiento) de cada actividad, lo cual es fundamental para el análisis de cuellos de botella. Dónde obtener Este es un Ejemplos 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Importe de Factura InvoiceAmount | El valor neto total de la factura. | ||
| Descripción Este El Importe de la Factura se utiliza en una amplia gama de análisis. Permite la segmentación del proceso por valor, por ejemplo, para ver si las facturas de alto valor se procesan de manera diferente o experimentan más retrasos. También es la base para la presentación de informes financieros y para calcular el valor total de las cuentas por cobrar pendientes. Por qué es importante Cuantifica el valor financiero de cada factura, permitiendo un análisis basado en el valor, la priorización de los cobros y la evaluación del impacto financiero. Dónde obtener SAP Table: VBRK, Field: NETWR Ejemplos 1500.0025000.50125.75 | |||
| Nombre de Usuario UserName | El ID de usuario del empleado que ejecutó la actividad. | ||
| Descripción Este Analizar por Nombre de Usuario ayuda a identificar individuos de alto rendimiento, necesidades de capacitación o desequilibrios en la distribución de la carga de trabajo. También es crucial para el análisis de Por qué es importante Vincula las actividades del proceso a usuarios específicos, permitiendo el análisis de la carga de trabajo, el rendimiento y el cumplimiento a nivel individual o de equipo. Dónde obtener Para eventos de creación, esto se encuentra en VBRK-ERNAM. Para cambios posteriores, se encuentra en tablas de historial de cambios como CDHDR-USERNAME o en logs de workflow. Ejemplos `CBURNS`HSIMPSONLLEONARD | |||
| Nombre del Cliente CustomerName | El nombre del cliente al que se emitió la factura. | ||
| Descripción Este Analizar el proceso por cliente permite identificar patrones específicos de ciertas cuentas. Por ejemplo, puede revelar qué clientes pagan tarde consistentemente, cuáles presentan más disputas o para quién el proceso de facturación es más ineficiente. Esto permite una gestión de relaciones con el cliente dirigida y estrategias de cobro personalizadas. Por qué es importante Permite un análisis centrado en el cliente, ayudando a identificar comportamientos de pago, frecuencias de disputas e ineficiencias de proceso para cuentas específicas. Dónde obtener Obtenido de la tabla de datos maestros de cliente KNA1 (Campo: NAME1), vinculado a través del ID de Pagador en la cabecera de la factura (VBRK-KUNRG). Ejemplos Springfield Power PlantKwik-E-MartCyberdyne Systems | |||
| Región Region | La región geográfica del cliente. | ||
| Descripción El Este Por qué es importante Permite la comparación del rendimiento de la facturación entre diferentes áreas geográficas, ayudando a identificar disparidades regionales y a estandarizar procesos. Dónde obtener Obtenido de la tabla de datos maestros de cliente KNA1 (Campo: REGIO), vinculado a través del ID de Pagador en la cabecera de la factura (VBRK-KUNRG). Ejemplos CANYTXBA | |||
| ¿Se pagó a tiempo? IsPaidOnTime | Un indicador booleano que señala si la factura se pagó en o antes de su fecha de vencimiento. | ||
| Descripción Este es un Este indicador simplifica el cálculo y la visualización del KPI de Tasa de Pago a Tiempo. Permite un filtrado y segmentación fáciles para analizar las características de las facturas que se pagan tarde frente a las que se pagan a tiempo. Esto puede ayudar a descubrir patrones relacionados con clientes, regiones o condiciones de pago específicas que conducen a pagos atrasados. Por qué es importante Simplifica la medición del rendimiento al etiquetar claramente cada factura como 'a tiempo' o 'tardía', apoyando directamente el KPI de Tasa de Pago a Tiempo. Dónde obtener Este es un campo calculado. La lógica compara el Ejemplos truefalse | |||
| Condiciones de Pago PaymentTerms | El código que define las condiciones de pago, como el período permitido para el pago. | ||
| Descripción Las Condiciones de Pago son condiciones predefinidas acordadas con un cliente que establecen cuándo vence el pago de una factura. Ejemplos incluyen 'Neto 30' (pago a 30 días) o '2/10 Neto 30' (un 2% de descuento si se paga en 10 días, de lo contrario, vence en 30 días). Analizar por condiciones de pago ayuda a evaluar su efectividad. Al correlacionar diferentes condiciones de pago con el tiempo real que se tarda en recibir el pago, una empresa puede determinar qué condiciones son más exitosas para fomentar el pago puntual y optimizar sus términos para mejorar el flujo de caja. Por qué es importante Define el calendario de pagos acordado, permitiendo el análisis de qué condiciones son más efectivas para asegurar el pago puntual de los clientes. Dónde obtener SAP Table: VBRK, Field: ZTERM Ejemplos Z030Z060ZB60 | |||
| Estado de Pago PaymentStatus | El estado actual del pago de la factura, como Abierto, Pagado o Vencido. | ||
| Descripción El Estado de Pago ofrece una visión general de la situación de una factura en su ciclo de cobro. No es un campo único en SAP, sino que se obtiene verificando el estado de compensación del documento contable correspondiente. Este atributo es fundamental para el Por qué es importante Proporciona una vista clara y rápida del estado de cobro de una factura, lo cual es vital para gestionar las cuentas por cobrar y priorizar los esfuerzos de cobro. Dónde obtener Derivado al verificar el estado de compensación del documento contable (VBRK-BELNR) en tablas financieras como BSID (partidas abiertas) y BSAD (partidas compensadas). Ejemplos AbiertoPagadoVencidoParcialmente Pagado | |||
| Moneda Currency | El código de moneda para el importe de la factura. | ||
| Descripción Este En una organización global, la moneda es esencial para un análisis e informes financieros correctos. Permite la agregación adecuada de Por qué es importante Proporciona contexto esencial para todos los valores monetarios, asegurando un análisis financiero y una presentación de informes precisos, especialmente en operaciones multinacionales. Dónde obtener SAP Table: VBRK, Field: WAERK Ejemplos USDEURGBP | |||
| Motivo de la Nota de Crédito CreditMemoReason | El código de motivo que indica por qué se emitió una nota de crédito. | ||
| Descripción Cuando una factura es incorrecta y necesita ser abonada, normalmente se asigna un motivo al documento de nota de crédito. Esto proporciona una forma estructurada de categorizar las fuentes de errores de facturación. Este Por qué es importante Categoriza los motivos para emitir crédito, lo que ayuda a identificar las fuentes más frecuentes de errores de facturación e impulsa mejoras en la calidad. Dónde obtener Tabla SAP: VBRK, Campo: AUGRU (Motivo de Pedido). Este campo se utiliza en solicitudes de nota de crédito/débito que luego se facturan. Ejemplos 001 - Diferencia de Precio002 - Mala Calidad005 - Devolución del Cliente | |||
| Número de Pedido de Venta SalesOrderNumber | El identificador del pedido de venta original que dio lugar a la factura. | ||
| Descripción El Número de Pedido de Venta vincula el documento de facturación con las actividades de venta precedentes. Un solo pedido de venta puede resultar en una o varias facturas, y este vínculo proporciona el flujo de documentos completo. Este Por qué es importante Vincula la factura al pedido de venta original, lo que permite una visión más amplia y de extremo a extremo del proceso Order to Cash (Pedido a Cobro) más allá de la simple facturación. Dónde obtener Tabla SAP: VBRP (Datos de Posición de Documento de Facturación), Campo: AUBEL Ejemplos 100001231000045610000789 | |||
| Razón de Disputa CustomerDisputeReason | El motivo proporcionado por un cliente para disputar una factura. | ||
| Descripción Cuando un cliente impugna una factura, el motivo de la disputa suele registrarse. Esto podría deberse a errores de precio, cantidades incorrectas o mercancía dañada. Esta información puede almacenarse en el módulo de Gestión de Disputas de SAP o como notas de texto. Analizar los motivos de las disputas es fundamental para el KPI de Tasa de Error de Facturación y el análisis de errores asociado. Ayuda a identificar las causas raíz de las imprecisiones en la facturación, permitiendo a la empresa abordar problemas sistémicos en los procesos anteriores, mejorar la calidad de las facturas y aumentar la satisfacción del cliente. Por qué es importante Explica por qué se disputan las facturas, proporcionando una visión directa de las causas raíz de los errores de facturación y la insatisfacción del cliente. Dónde obtener Si se utiliza SAP Dispute Management, esta información se puede encontrar en tablas como UDM_DISPUTE. De lo contrario, puede derivarse de códigos de motivo en documentos relacionados o campos de texto. Ejemplos Precio IncorrectoDiscrepancia de CantidadBienes Dañados Recibidos | |||
| Sociedad CompanyCode | La unidad organizativa para la cual se registra la transacción financiera. | ||
| Descripción La Sociedad (Company Code) es una entidad organizativa fundamental en SAP Financials, que representa una empresa legalmente independiente para la cual se crean los estados financieros. Cada documento de facturación se asigna a una sociedad específica. Analizar por Sociedad es esencial en organizaciones multiempresariales para comparar el rendimiento del proceso, métricas financieras como el DSO y la Por qué es importante Permite segmentar el análisis de procesos por entidad legal, posibilitando la comparación de rendimiento y la consolidación financiera en toda la organización. Dónde obtener SAP Table: VBRK, Field: BUKRS Ejemplos 10002000US01 | |||
| Source System SourceSystem | Identifica el sistema fuente específico del que se extrajeron los datos. | ||
| Descripción Este En el análisis, ayuda a diferenciar procesos y rendimiento entre diferentes sistemas o entidades organizativas. Asegura la trazabilidad de la Por qué es importante Proporciona un contexto crucial sobre el origen de los datos, asegurando claridad en entornos multisistema y apoyando la gobernanza de datos. Dónde obtener Este es típicamente un valor estático definido durante la extracción de Ejemplos S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Tiempo de Procesamiento ProcessingTime | La duración de una actividad, calculada desde su hora de inicio hasta su hora de finalización. | ||
| Descripción El Tiempo de Procesamiento mide el tiempo dedicado activamente a una tarea, a diferencia del tiempo de espera entre tareas. Se calcula como la diferencia entre la Hora de Finalización y la Hora de Inicio de una actividad. Esta métrica calculada es una piedra angular del análisis de rendimiento. Se utiliza en Por qué es importante Mide la duración activa de los pasos del proceso, ayudando a identificar actividades ineficientes que son candidatas principales para la optimización o la automatización. Dónde obtener Métrica calculada, derivada al restar el 'StartTime' del 'EndTime' durante el proceso de transformación de datos. Ejemplos PT30MPT5MPT1H15M | |||
| Tipo de Documento de Facturación BillingDocumentType | Un código que clasifica el documento de facturación, como una factura, nota de crédito o anulación. | ||
| Descripción El Tipo de Documento de Facturación es un campo clave que categoriza las transacciones dentro del proceso de facturación. Controla cómo se procesa el documento, incluyendo su rango de números y reglas de contabilización contable. Este Por qué es importante Clasifica las transacciones, permitiendo un análisis enfocado en flujos de documentos específicos como facturas estándar, notas de crédito o anulaciones. Dónde obtener SAP Table: VBRK, Field: FKART Ejemplos F2G2S1L2 | |||
| Última actualización de datos LastDataUpdate | El `timestamp` que indica cuándo se extrajo o actualizó por última vez la `data` para este `event`. | ||
| Descripción Este Esta información se utiliza para validar la actualidad del análisis y para gestionar los programas de actualización de Por qué es importante Indica la actualidad de los datos, lo cual es vital para confiar en el análisis y comprender su relevancia para el estado actual de las operaciones. Dónde obtener Este Ejemplos 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
Actividades de Order to Cash (Pedido a Cobro) - Facturación
| Actividad | Descripción | ||
|---|---|---|---|
| Efectivo Aplicado/Conciliado | Representa el momento en que el pago entrante del cliente se empareja y se utiliza para compensar el asiento abierto de la factura en el sublibro de cuentas por cobrar. Esta actividad completa la transacción desde una perspectiva financiera. | ||
| Por qué es importante Mide la eficiencia del proceso de aplicación de efectivo. Los retrasos aquí pueden tergiversar el estado real de las cuentas de los clientes y crear trabajo innecesario para los equipos de cobros. Dónde obtener Este Capturar Capturado del campo de fecha de compensación (AUGDT) en la tabla BSEG/ACDOCA para la partida individual de la factura. Tipo de evento explicit | |||
| Factura Cerrada | Esta actividad significa el estado final de una factura pagada con éxito. Funcionalmente es lo mismo que 'Efectivo Aplicado/Conciliado' e indica que el proceso para esta factura está completo. | ||
| Por qué es importante Sirve como el Dónde obtener Inferido del estado de la partida individual del cliente en el documento contable. Una partida se cierra o 'compensa' cuando se rellenan los campos de fecha de compensación (BSEG-AUGDT) y documento de compensación (BSEG-AUGBL). Capturar Inferido de la población de la fecha de compensación (AUGDT) en la tabla BSEG/ACDOCA para la partida individual de la factura. Tipo de evento inferred | |||
| Factura Contabilizada en Contabilidad | Representa el registro exitoso del documento de facturación en el módulo de contabilidad financiera. Este es un hito crítico donde la factura se convierte en un asiento oficial de cuentas por cobrar, creando entradas en el libro mayor general. | ||
| Por qué es importante Esta actividad confirma que la factura es un documento financiero legal. El tiempo entre la generación y la contabilización es un indicador clave de rendimiento, que destaca la eficiencia interna del procesamiento. Dónde obtener Este Capturar Capturado de la fecha de contabilización (BUDAT) del documento contable en la tabla BKPF vinculado al documento de facturación. Tipo de evento explicit | |||
| Factura Generada | Esta actividad marca la creación del documento de facturación en el sistema. Es un `event` explícito capturado cuando un usuario ejecuta una transacción como VF01 o cuando un trabajo en segundo plano crea la factura, resultando en una nueva entrada en la tabla de cabecera del documento de facturación. | ||
| Por qué es importante Este es el Dónde obtener Registrado en la tabla VBRK de SAP S/4HANA (Documento de Facturación: Datos de Cabecera) en el momento de la creación. La fecha de creación (VBRK-ERDAT) y la hora (VBRK-ERZET) sirven como Capturar El evento se captura de la marca de tiempo de creación del registro del documento de facturación en la tabla VBRK. Tipo de evento explicit | |||
| Pago de cliente recibido | Esta actividad marca el registro de un pago entrante de un cliente en el sistema financiero. Es posible que el pago aún no se haya aplicado a una factura específica en esta etapa, pero los fondos han sido registrados. | ||
| Por qué es importante Un hito crucial para calcular los Días de Ventas Pendientes de Cobro (DSO). Significa que se ha recibido efectivo, incluso si la conciliación aún está pendiente. Dónde obtener Capturado de la fecha de contabilización (BKPF-BUDAT) del documento de pago del cliente (típicamente tipo de documento 'DZ' en la tabla BKPF). Capturar El evento se basa en la creación del documento de pago en BKPF/BSEG. Tipo de evento explicit | |||
| Contabilización de Factura Bloqueada | Este `event` ocurre si se crea una factura pero se bloquea automáticamente para su contabilización en contabilidad financiera debido a diversas razones, como verificaciones de crédito o inconsistencias de `data`. Este estado se infiere del campo de estado de contabilización en el documento de facturación. | ||
| Por qué es importante Identifica cuellos de botella donde las facturas se crean pero no se liberan inmediatamente a finanzas, retrasando todo el ciclo de cobro de efectivo. Es un indicador clave de problemas de calidad de datos o de gestión de crédito. Dónde obtener Inferido del campo de estado de contabilización en la tabla de cabecera del documento de facturación (VBRK-RFBSK). Un estado como 'A' (Documento de facturación bloqueado para ser reenviado a FI) indica un bloqueo. Capturar Inferido al verificar el valor del campo de estado de contabilización (VBRK-RFBSK) inmediatamente después de que se genera la factura. Tipo de evento inferred | |||
| Disputa de Cliente Abierta | Esta actividad ocurre cuando un cliente presenta una disputa contra una factura, que luego se registra formalmente en el sistema. Esto requiere el uso del módulo de Gestión de Disputas de SAP. | ||
| Por qué es importante Destaca problemas con la precisión de la facturación, la calidad del producto o la entrega del servicio que conducen a retrasos en los pagos. El análisis de los motivos de las disputas puede ayudar a abordar las causas raíz y mejorar la satisfacción del cliente. Dónde obtener Registrado al crearse un caso de disputa en las tablas de Gestión de Disputas (por ejemplo, UDM_CASE), el cual está vinculado a la partida individual del documento contable. Capturar Capturado de la marca de tiempo de creación del registro del caso de disputa vinculado a la factura. Tipo de evento explicit | |||
| Factura Anulada | Ocurre cuando se anula una factura previamente creada, lo que generalmente implica la creación de un documento de anulación correspondiente. Esto revierte efectivamente la factura original y su impacto contable. | ||
| Por qué es importante Indica reprocesos, correcciones o errores de facturación. Una alta frecuencia de anulaciones señala problemas significativos en la entrada de pedidos de venta o en la configuración de la facturación. Dónde obtener Capturado cuando se crea un documento de facturación de anulación (por ejemplo, tipo de documento 'S1'). Este nuevo documento en VBRK hará referencia al número de factura original en el campo VBRK-SFAKN. Capturar El evento se captura de la fecha de creación del documento de anulación en VBRK que hace referencia a la factura original. Tipo de evento explicit | |||
| Factura enviada al cliente | Esta actividad marca cuándo la factura fue transmitida al cliente, por ejemplo, a través de impresión, correo electrónico o EDI. El mecanismo de captura depende de la configuración de gestión de salida en SAP. | ||
| Por qué es importante El inicio oficial del reloj de pago desde la perspectiva del cliente. Los retrasos en el envío de la factura impactan directamente los Días de Cartera (DSO) y el flujo de caja. Dónde obtener Puede registrarse explícitamente en las tablas de control de salida (como NAST para métodos antiguos o su equivalente en S/4HANA). Si no se registra explícitamente, a menudo se infiere que ocurre al mismo tiempo que 'Invoice Posted To Accounting'. Capturar Verifique los registros de procesamiento en las tablas de gestión de salidas para una marca de tiempo asociada con el tipo de salida de la factura. Tipo de evento explicit | |||
| Fecha de Vencimiento de Pago Alcanzada | Un evento calculado que representa la fecha oficial de vencimiento del pago de la factura, según las condiciones de pago acordadas. No es un evento transaccional, sino que se deriva de los datos de la factura. | ||
| Por qué es importante Esto proporciona una base crítica para medir el rendimiento de pago a tiempo y analizar el comportamiento de pago del cliente. Ayuda a distinguir entre pagos a tiempo y pagos vencidos. Dónde obtener Calculado a partir de la fecha base para el pago (BSEG-ZFBDT) y las condiciones de pago almacenadas en la partida individual del cliente del documento contable. Capturar Derivado al sumar los días de las condiciones de pago a la fecha base de pago encontrada en la partida individual del documento contable (BSEG). Tipo de evento calculated | |||
| Nota de Crédito Creada | Esta actividad representa la creación de una nota de crédito, que se emite a un cliente para corregir un cargo excesivo o proporcionar un crédito por bienes devueltos. A menudo está vinculada a una factura original. | ||
| Por qué es importante Destaca problemas que resultan en ajustes financieros después de la facturación. El análisis de las notas de crédito puede descubrir errores de precios, problemas de productos u otras causas raíz de la fuga de ingresos. Dónde obtener Creado explícitamente como un nuevo documento de facturación (en VBRK) con un tipo de facturación específico para notas de crédito (por ejemplo, 'G2'). A menudo hace referencia al pedido de venta o factura original. Capturar Capturado de la creación de un documento de facturación en VBRK con un tipo de facturación de nota de crédito. Tipo de evento explicit | |||
| Recordatorio de Pago Emitido | Representa el envío de un recordatorio de pago o una notificación de reclamación a un cliente por una factura vencida. Este es un `event` explícito generado por el procedimiento de reclamación automatizado. | ||
| Por qué es importante Permite el análisis de la efectividad del proceso de reclamación de pagos. Ayuda a determinar si los recordatorios aceleran los pagos y qué niveles de reclamación son más impactantes. Dónde obtener Registrado en las tablas de historial de reclamación (MAHNV, MHND) cuando se ejecuta la ejecución de reclamación (Transacción F150) para el asiento abierto de la factura. Capturar Capturado de la fecha de ejecución del aviso de reclamación registrado en las tablas de historial de reclamaciones. Tipo de evento explicit | |||
| Reproceso de Facturación Identificado | Un evento calculado que identifica un bucle de reproceso donde una factura fue cancelada y luego se generó una nueva para el mismo pedido de venta. No es una transacción única, sino un patrón de eventos. | ||
| Por qué es importante Apoya directamente el KPI de Tasa de Reproceso de Facturación cuantificando las instancias de corrección. Esto ayuda a identificar ineficiencias y a medir el costo de la mala calidad en el proceso de facturación. Dónde obtener Este patrón se calcula identificando un Capturar Derivado al detectar una secuencia de 'Invoice Cancelled' y 'Invoice Generated' para la misma referencia de pedido de venta. Tipo de evento calculated | |||
Guías de Extracción
Pasos
- Requisitos Previos: Asegúrese de tener una cuenta de usuario en SAP S/4HANA con las autorizaciones necesarias para consultar las vistas de Core Data Services (CDS). Específicamente, necesita acceso de lectura a vistas como I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase y I_DunningHistory.
- Acceso a la Herramienta de Extracción de Datos: Inicie sesión en su sistema SAP S/4HANA. Puede utilizar diversas herramientas para ejecutar consultas SQL contra vistas CDS, como SAP HANA Studio, DBeaver conectado a través del cliente SAP HANA, o el complemento SAP Analysis for Microsoft Excel. Para esta guía, asumiremos un cliente SQL estándar.
- Identificar Parámetros del Sistema: Antes de ejecutar la consulta, identifique las Sociedades (Company Codes) específicas y el rango de fechas relevante para su análisis. Se recomienda comenzar con un alcance limitado, por ejemplo, los últimos 3 a 6 meses de datos, para asegurar tiempos de ejecución de consulta manejables.
- Preparar la Consulta SQL: Copie la consulta SQL completa proporcionada en la sección 'query' de este documento en su cliente SQL elegido.
- Personalizar Marcadores de Posición: Modifique los valores de los marcadores de posición en la consulta. Reemplace
'YYYY-MM-DD'con sus fechas de inicio y fin deseadas. Reemplace'XXXX'con su(s) Sociedad(es) (Company Code(s)) objetivo. Es posible que también necesite ajustar el marcador de posición para los tipos de documento de nota de crédito, por ejemplo,'G2', según la configuración de su sistema. - Ejecutar la Consulta: Ejecute la consulta SQL modificada contra la base de datos SAP S/4HANA. El tiempo de ejecución variará dependiendo del volumen de datos dentro de su rango de fechas seleccionado.
- Revisar los Resultados: Una vez que la consulta finalice, revise la salida. El conjunto de resultados debe ser una tabla plana donde cada fila represente una única actividad en el proceso de facturación. Este es su registro de eventos.
- Transformación de Datos (si es necesario): La consulta está diseñada para producir un formato de registro de eventos limpio. Sin embargo, verifique el formato de la marca de tiempo para asegurarse de que sea compatible con su herramienta de Process Mining. La consulta utiliza
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpara convertir a una marca de tiempo UTC estándar, que debería ser ampliamente compatible. - Exportar el Registro de Eventos: Exporte el conjunto completo de resultados de su cliente SQL a un archivo CSV. Asegúrese de que el archivo esté codificado en UTF-8 para evitar problemas de caracteres.
- Cargar a ProcessMind: Cargue el archivo CSV generado a la plataforma ProcessMind, mapeando las columnas del archivo, como InvoiceNumber, ActivityName y EventTime, a los campos correspondientes en la herramienta.
Configuración
- Rango de Fechas: Establezca las fechas de inicio y fin en la cláusula
WHEREde la Common Table Expression (CTE) inicial. Se recomienda un rango de 3 a 6 meses para un análisis inicial, buscando un equilibrio entre el volumen de datos y el rendimiento. El filtro se aplica enBillingDocumentDate. - Sociedad: Filtre por uno o varios valores de
CompanyCodepara restringir la extracción a las entidades legales pertinentes. Este es un filtro crítico para gestionar el alcance de los datos. - Tipos de Documento: La consulta incluye lógica para identificar notas de crédito basándose en el
BillingDocumentType. Debe configurar el marcador de posición, por ejemplo,('G2', 'CR'), con los tipos de documento específicos utilizados para las notas de crédito en su organización. - Requisitos Previos: Es obligatorio el acceso a las vistas CDS subyacentes. Esto requiere roles y autorizaciones específicas asignadas por su equipo de seguridad de SAP. Además, para actividades como 'Customer Dispute Opened' o 'Payment Reminder Issued', los módulos SAP respectivos, SAP Dispute Management y SAP Financials Dunning, deben estar en uso activo en su sistema.
- Rendimiento: La consulta utiliza múltiples joins y unions. Para conjuntos de datos muy grandes, por ejemplo, varios años de datos, considere ejecutarla durante horas de baja actividad o aplicar filtros más restrictivos para limitar la extracción inicial de datos.
a Consulta de ejemplo sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Pasos
- Requisitos Previos: Asegúrese de tener una cuenta de usuario en SAP S/4HANA con las autorizaciones necesarias para consultar las vistas de Core Data Services (CDS). Específicamente, necesita acceso de lectura a vistas como I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase y I_DunningHistory.
- Acceso a la Herramienta de Extracción de Datos: Inicie sesión en su sistema SAP S/4HANA. Puede utilizar diversas herramientas para ejecutar consultas SQL contra vistas CDS, como SAP HANA Studio, DBeaver conectado a través del cliente SAP HANA, o el complemento SAP Analysis for Microsoft Excel. Para esta guía, asumiremos un cliente SQL estándar.
- Identificar Parámetros del Sistema: Antes de ejecutar la consulta, identifique las Sociedades (Company Codes) específicas y el rango de fechas relevante para su análisis. Se recomienda comenzar con un alcance limitado, por ejemplo, los últimos 3 a 6 meses de datos, para asegurar tiempos de ejecución de consulta manejables.
- Preparar la Consulta SQL: Copie la consulta SQL completa proporcionada en la sección 'query' de este documento en su cliente SQL elegido.
- Personalizar Marcadores de Posición: Modifique los valores de los marcadores de posición en la consulta. Reemplace
'YYYY-MM-DD'con sus fechas de inicio y fin deseadas. Reemplace'XXXX'con su(s) Sociedad(es) (Company Code(s)) objetivo. Es posible que también necesite ajustar el marcador de posición para los tipos de documento de nota de crédito, por ejemplo,'G2', según la configuración de su sistema. - Ejecutar la Consulta: Ejecute la consulta SQL modificada contra la base de datos SAP S/4HANA. El tiempo de ejecución variará dependiendo del volumen de datos dentro de su rango de fechas seleccionado.
- Revisar los Resultados: Una vez que la consulta finalice, revise la salida. El conjunto de resultados debe ser una tabla plana donde cada fila represente una única actividad en el proceso de facturación. Este es su registro de eventos.
- Transformación de Datos (si es necesario): La consulta está diseñada para producir un formato de registro de eventos limpio. Sin embargo, verifique el formato de la marca de tiempo para asegurarse de que sea compatible con su herramienta de Process Mining. La consulta utiliza
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpara convertir a una marca de tiempo UTC estándar, que debería ser ampliamente compatible. - Exportar el Registro de Eventos: Exporte el conjunto completo de resultados de su cliente SQL a un archivo CSV. Asegúrese de que el archivo esté codificado en UTF-8 para evitar problemas de caracteres.
- Cargar a ProcessMind: Cargue el archivo CSV generado a la plataforma ProcessMind, mapeando las columnas del archivo, como InvoiceNumber, ActivityName y EventTime, a los campos correspondientes en la herramienta.
Configuración
- Rango de Fechas: Establezca las fechas de inicio y fin en la cláusula
WHEREde la Common Table Expression (CTE) inicial. Se recomienda un rango de 3 a 6 meses para un análisis inicial, buscando un equilibrio entre el volumen de datos y el rendimiento. El filtro se aplica enBillingDocumentDate. - Sociedad: Filtre por uno o varios valores de
CompanyCodepara restringir la extracción a las entidades legales pertinentes. Este es un filtro crítico para gestionar el alcance de los datos. - Tipos de Documento: La consulta incluye lógica para identificar notas de crédito basándose en el
BillingDocumentType. Debe configurar el marcador de posición, por ejemplo,('G2', 'CR'), con los tipos de documento específicos utilizados para las notas de crédito en su organización. - Requisitos Previos: Es obligatorio el acceso a las vistas CDS subyacentes. Esto requiere roles y autorizaciones específicas asignadas por su equipo de seguridad de SAP. Además, para actividades como 'Customer Dispute Opened' o 'Payment Reminder Issued', los módulos SAP respectivos, SAP Dispute Management y SAP Financials Dunning, deben estar en uso activo en su sistema.
- Rendimiento: La consulta utiliza múltiples joins y unions. Para conjuntos de datos muy grandes, por ejemplo, varios años de datos, considere ejecutarla durante horas de baja actividad o aplicar filtros más restrictivos para limitar la extracción inicial de datos.
a Consulta de ejemplo sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;