Su Template de datos de gestión de crédito y cobros
Su Template de datos de gestión de crédito y cobros
- Atributos recomendados para un análisis completo
- Actividades clave que debe supervisar para descubrir el proceso
- Guía paso a paso para extraer los datos
Atributos de gestión de crédito y cobros
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | La fecha y hora exactas en que tuvo lugar la actividad, que actúan como marca de tiempo del evento. | ||
| Descripción La hora del evento, o marca de tiempo, registra el momento exacto en que tuvo lugar una actividad. Es esencial para ordenar cronológicamente los eventos y crear un flujo de proceso preciso. Sin marcas de tiempo exactas, no es posible determinar correctamente la secuencia de los eventos. En el análisis, este atributo se utiliza para calcular las duraciones y los tiempos de ciclo entre actividades, algo fundamental para medir el rendimiento. Por ejemplo, permite calcular KPI como el tiempo de ciclo de resolución de disputas o el tiempo de ciclo de pago de facturas. También permite analizar las tendencias de rendimiento del proceso en distintos periodos. Por qué es importante Esta marca de tiempo es esencial para ordenar eventos, calcular tiempos de ciclo y duraciones, y analizar el rendimiento del proceso a lo largo del tiempo. Dónde obtenerlo Se deriva de diversos campos de fecha de las tablas de Oracle Fusion Financials, como TRX_DATE en RA_CUSTOMER_TRX_ALL para la creación de facturas o la fecha de creación de una acción de cobro. Ejemplos 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Nombre de la actividad ActivityName | El nombre del evento empresarial o la tarea concreta que tuvo lugar en un momento determinado dentro del proceso de gestión de crédito. | ||
| Descripción Este atributo describe un único paso del ciclo de vida de la factura, como «Factura generada», «Procedimiento de gestión de morosidad iniciado» o «Pago recibido». Cada actividad representa un evento distinto que hace avanzar el caso. Analizar la secuencia y la frecuencia de las actividades es la base de Process Mining. Ayuda a descubrir el flujo real del proceso, identificar cuellos de botella en los que los casos quedan bloqueados, detectar ciclos de retrabajo en los que se repiten actividades y comparar el proceso real con el proceso diseñado o ideal. El nombre de la actividad es fundamental para crear mapas de procesos y calcular los tiempos de transición entre pasos. Por qué es importante Este atributo define los pasos del mapa de procesos y permite visualizar y analizar el ciclo de vida de la factura de principio a fin. Dónde obtenerlo Es un campo conceptual derivado de diversos eventos empresariales de Oracle Fusion Financials. A menudo se construye mediante la asignación de estados de transacción, fechas de eventos o acciones concretas de módulos como Receivables (AR) y Advanced Collections. Ejemplos Factura generadaProcedimiento de gestión de morosidad iniciadoPago recibidoDisputa registrada | |||
| Número de factura InvoiceNumber | Identificador único de cada factura del cliente, que actúa como identificador principal del caso para el proceso de gestión de crédito. | ||
| Descripción El número de factura es la clave central que vincula todos los eventos y actividades relacionados con una única cuenta por cobrar, desde su creación hasta su liquidación final o baja. Permite obtener una visión completa, de principio a fin, del ciclo de vida de la factura. En el análisis de Process Mining, este atributo se utiliza para reconstruir el recorrido de cada factura. Al agrupar todas las actividades relacionadas bajo un único número de factura, los analistas pueden visualizar los flujos del proceso, identificar rutas habituales y desviadas, y medir los tiempos de ciclo del proceso completo o de etapas concretas, como la resolución de disputas o la contabilización de pagos. Por qué es importante Este es el Case ID esencial que conecta todos los pasos relacionados del proceso y permite reconstruir y analizar el recorrido de cada factura desde su emisión hasta su cierre. Dónde obtenerlo Este identificador suele encontrarse en la tabla RA_CUSTOMER_TRX_ALL como TRX_NUMBER en Oracle Fusion Financials. Ejemplos INV-1005679884321AR-2023-04-112 | |||
| Sistema de origen SourceSystem | El sistema del que proceden los datos. | ||
| Descripción Este atributo identifica la aplicación de origen en la que se registraron los datos del evento. En un entorno de TI complejo, pueden intervenir varios sistemas en un único proceso de principio a fin. Especificar el sistema de origen es importante para la gobernanza de datos, la resolución de problemas y la comprensión del contexto de los datos. Ayuda a diferenciar los eventos procedentes de distintos sistemas cuando se combinan en una única vista del proceso y garantiza la trazabilidad clara de los datos. Por qué es importante Aporta claridad sobre el origen de los datos, algo fundamental para validarlos, aplicar la gobernanza y comprender el contexto tecnológico del proceso. Dónde obtenerlo Normalmente es un valor estático que se añade durante la extracción de datos para identificar el origen de los registros. Ejemplos Oracle Fusion FinancialsOracle AROracle Collections | |||
| Última actualización de los datos LastDataUpdate | La marca de tiempo que indica cuándo se actualizaron o extrajeron por última vez los datos de este evento del sistema de origen. | ||
| Descripción Este atributo registra la fecha y hora de la extracción de datos más reciente. Es un campo de metadatos que no forma parte del proceso empresarial, pero resulta fundamental para comprender la actualidad de los datos analizados. Las personas analistas utilizan esta marca de tiempo para confirmar que trabajan con información actualizada y para conocer el momento de corte de los datos. Es esencial para la gobernanza de datos y para gestionar las expectativas de las personas usuarias sobre la vigencia de la información en los Dashboards y los informes. Por qué es importante Indica la actualidad de los datos y garantiza que los analistas y las partes interesadas conozcan su vigencia y relevancia. Dónde obtenerlo Este valor se genera y se registra en cada registro durante el proceso de extracción y carga de datos (ETL). Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Fecha de vencimiento DueDate | La fecha límite para pagar la factura. | ||
| Descripción La fecha de vencimiento es un atributo de fecha fundamental acordado contractualmente para el pago. Es la referencia con la que se mide la puntualidad del pago. Este atributo es esencial para identificar las facturas vencidas y calcular cuántos días lleva vencida una factura. Es el dato principal para determinar cuándo deben iniciarse los procedimientos de gestión de morosidad y se utiliza para calcular KPI como los días de ventas pendientes (DSO). También es imprescindible para crear informes de antigüedad que clasifiquen la deuda pendiente. Por qué es importante Actúa como referencia para determinar si una factura está vencida, activar las actividades de cobro y permitir el análisis de antigüedad. Dónde obtenerlo Está disponible en la tabla AR_PAYMENT_SCHEDULES_ALL como DUE_DATE. Ejemplos 2023-05-302023-06-152023-07-01 | |||
| Importe de la factura InvoiceAmount | El valor monetario total de la factura. | ||
| Descripción Invoice Amount representa el valor total de los bienes o servicios facturados al cliente. Es un atributo financiero fundamental para comprender el impacto monetario del proceso. En el análisis, Invoice Amount se utiliza para priorizar los esfuerzos de cobro, centrándose en las facturas vencidas de importe elevado. También permite analizar los comportamientos de pago según el valor de la transacción y calcular el impacto financiero de las cancelaciones contables. Dashboards como Invoice Write-Off Rate Analysis utilizan este valor para evaluar la magnitud de las pérdidas financieras. Por qué es importante Aporta contexto financiero al proceso y permite priorizar las facturas de mayor valor y analizar el impacto monetario de las ineficiencias del proceso. Dónde obtenerlo Esta información puede derivarse de la tabla AR_PAYMENT_SCHEDULES_ALL, que almacena el importe pendiente de una factura. Ejemplos 5000.001250.75250000.00 | |||
| Nivel de gestión de morosidad DunningLevel | La etapa o el nivel del procedimiento de gestión de morosidad aplicado a la factura. | ||
| Descripción El nivel de gestión de morosidad indica la intensidad del recordatorio de cobro, que normalmente aumenta con el tiempo. Por ejemplo, el nivel 1 puede consistir en un recordatorio cordial por correo electrónico, mientras que el nivel 3 puede incluir una carta formal o una llamada telefónica. Analizar el proceso por nivel de gestión de morosidad ayuda a evaluar la eficacia de la estrategia de reclamación. El Dashboard de eficacia de la gestión de morosidad utiliza este atributo para visualizar las tasas de conversión de cada paso de reclamación a pago. Esto permite determinar qué acciones son más eficaces y ajustar el momento y el contenido de los recordatorios para maximizar los cobros. Por qué es importante Registra la etapa de escalamiento de los esfuerzos de cobro, algo fundamental para evaluar la eficacia de la estrategia de gestión de morosidad. Dónde obtenerlo Estos datos se gestionan en el módulo Oracle Advanced Collections. Pueden encontrarse en tablas relacionadas con el historial de gestión de morosidad, como IEX_DUNNINGS. Ejemplos Nivel 1: RecordatorioNivel 2: AdvertenciaNivel 3: Aviso final | |||
| Número de cliente CustomerNumber | Identificador único del cliente asociado a la factura. | ||
| Descripción El número de cliente vincula una factura con una cuenta de cliente concreta. Esto permite segmentar y analizar el proceso de gestión de crédito y cobro según los atributos del cliente. Al incluir el número de cliente, los analistas pueden investigar si determinados clientes pagan tarde de forma habitual, presentan más disputas o requieren mayores esfuerzos de cobro. Esta información es fundamental para crear estrategias de cobro específicas para cada cliente, ajustar las condiciones de crédito e identificar segmentos de clientes de alto riesgo. También respalda directamente análisis como el análisis de la tasa de bajas de facturas por segmento de clientes. Por qué es importante Permite segmentar el proceso por cliente y ayuda a identificar patrones, riesgos y oportunidades para diseñar estrategias de cobro adaptadas. Dónde obtenerlo Suele encontrarse en la tabla RA_CUSTOMER_TRX_ALL como BILL_TO_CUSTOMER_ID, que se vincula con HZ_CUST_ACCOUNTS. Ejemplos CUST-0012389455ACME-CORP-US | |||
| Persona encargada del cobro Collector | El nombre o ID de la persona encargada del cobro asignada a la factura. | ||
| Descripción La persona encargada del cobro es quien, individualmente o como parte de un equipo, gestiona las actividades de cobro de una factura vencida. Esta asignación es un paso clave del Workflow de cobro. Este atributo es fundamental para gestionar el rendimiento y asignar recursos dentro del departamento de cobro. Al analizar los resultados por persona encargada, los responsables pueden evaluar su eficacia, identificar necesidades de formación y equilibrar las cargas de trabajo. El Dashboard de eficacia de la asignación de cobros depende directamente de este atributo para comparar las tasas de éxito y los tiempos de ciclo entre distintas personas encargadas. Por qué es importante Permite analizar el rendimiento de las personas o equipos encargados del cobro, lo que ayuda a optimizar la asignación de recursos y mejorar la eficiencia general del cobro. Dónde obtenerlo Esta información suele almacenarse en el módulo Oracle Advanced Collections, a menudo en tablas como IEX_CASES_ALL_B o en tablas de asignación relacionadas. Ejemplos John SmithJane DoeEquipo de cobros A | |||
| Segmento de clientes CustomerSegment | La clasificación del cliente en un grupo definido, por ejemplo, según su tamaño, sector o importancia estratégica. | ||
| Descripción Customer Segment es un atributo categórico que agrupa a los clientes según características comunes. Los segmentos pueden definirse por factores como 'Strategic', 'SMB' o 'Enterprise', o por sectores como 'Manufacturing' o 'Retail'. Este atributo es muy útil para realizar comparativas. Permite comparar el rendimiento del proceso entre distintos segmentos para comprobar, por ejemplo, si uno presenta una mayor tasa de disputas o un ciclo de pago más largo. Esta información ayuda a adaptar las políticas de crédito y las estrategias de cobro a las necesidades y los riesgos específicos de cada segmento, y permite utilizar Dashboards como Invoice Write-Off Rate Analysis. Por qué es importante Permite realizar análisis comparativos detallados y revela cómo varían el rendimiento y los riesgos del proceso entre distintos grupos de clientes. Dónde obtenerlo A menudo se gestiona en los datos maestros de clientes, en HZ_CUST_ACCOUNTS o en tablas relacionadas, o se deriva de atributos del cliente como los ingresos o el sector. Ejemplos Gran empresaPequeña y mediana empresaAdministración públicaSocio estratégico | |||
| Usuario User | El ID de usuario o del sistema que realizó la actividad. | ||
| Descripción Este atributo identifica al empleado concreto o al usuario del sistema automatizado responsable de ejecutar una actividad, como aprobar un límite de crédito, contabilizar un pago o resolver una disputa. Analizar las actividades por usuario es esencial para comprender la distribución de la carga de trabajo, el rendimiento individual y el cumplimiento. En el caso de las actividades automatizadas, ayuda a hacer seguimiento de la intervención de los procesos del sistema. También puede utilizarse para identificar necesidades de formación o posibles actividades fraudulentas mediante la supervisión del comportamiento de los usuarios. Por qué es importante Asigna las actividades del proceso a personas concretas o sistemas automatizados para facilitar el seguimiento del rendimiento, el análisis de la carga de trabajo y las auditorías. Dónde obtenerlo Se obtiene de las columnas 'CREATED_BY' o 'LAST_UPDATED_BY' de varias tablas de transacciones e historial de Oracle Fusion Financials. Ejemplos jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Condiciones de pago PaymentTerms | Las condiciones acordadas que especifican cuándo debe realizarse el pago. | ||
| Descripción Las condiciones de pago definen los términos en los que se espera que pague el cliente, por ejemplo, «Net 30» o «Net 60». Estas condiciones se utilizan para calcular la fecha de vencimiento de la factura. Analizar el rendimiento de los pagos según las condiciones de pago puede revelar patrones interesantes. Por ejemplo, los clientes con plazos más cortos podrían tener una mayor probabilidad de pagar tarde. Esta información puede utilizarse para revisar y optimizar las políticas de crédito y segmentar a los clientes para aplicar distintas estrategias de cobro. Aporta un contexto valioso para comprender por qué determinadas facturas vencen. Por qué es importante Aporta contexto sobre el calendario de pagos acordado y permite analizar el comportamiento de pago con distintas condiciones de crédito. Dónde obtenerlo Se almacena en la tabla RA_TERMS y se vincula con la transacción de la factura. Ejemplos Neto a 30 díasNeto a 60 díasVencimiento al recibir | |||
| Días de vencimiento DaysOverdue | Número de días que han transcurrido desde la fecha de vencimiento de una factura. | ||
| Descripción Esta métrica calculada cuantifica el retraso de una factura impagada. Se calcula como la diferencia entre la fecha actual, para las facturas abiertas, o la fecha de pago, para las facturas cerradas, y la fecha de vencimiento. Los días de vencimiento son una medida fundamental para analizar la antigüedad y priorizar las gestiones de cobro. Constituyen la métrica principal del Dashboard de antigüedad y estado de facturas vencidas, donde las facturas se agrupan por intervalos de antigüedad, por ejemplo, de 1 a 30 días y de 31 a 60 días. Esto ayuda al equipo de cobros a centrarse en las deudas más antiguas y de mayor riesgo. Por qué es importante Cuantifica el alcance de los retrasos en los pagos y sirve como métrica clave para priorizar los cobros y realizar análisis de antigüedad. Dónde obtenerlo Es un campo calculado. La lógica es: CurrentDate - DueDate para las facturas abiertas, o PaymentDate - DueDate para las facturas cerradas. Ejemplos 1545920 | |||
| Está vencida IsOverdue | Indicador booleano que señala si la factura ha superado su fecha de vencimiento. | ||
| Descripción Es un atributo derivado que proporciona una indicación sencilla, verdadera o falsa, del estado de vencimiento de una factura. Normalmente se calcula comparando la fecha actual, o la fecha de pago, con la fecha de vencimiento de la factura. Este indicador resulta muy útil para filtrar y segmentar los análisis. Permite aislar rápidamente el conjunto de facturas vencidas para estudiar sus recorridos de proceso, la eficacia de las actividades de cobro y otras características. Simplifica la creación de Dashboards y KPI centrados en la gestión de la deuda vencida, como el Dashboard Overdue Invoice Aging & Status. Por qué es importante Proporciona un indicador sencillo y claro para identificar y analizar todas las facturas vencidas, que constituyen el principal foco del proceso de cobro. Dónde obtenerlo Es un campo calculado. La lógica es: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Ejemplos truefalse | |||
| Estado de la factura InvoiceStatus | El estado actual de la factura dentro de su ciclo de vida. | ||
| Descripción El estado de la factura ofrece una instantánea de su situación actual en el proceso. Entre los estados habituales se incluyen «Open», «Paid», «Disputed», «Past Due» o «Written Off». Este atributo proporciona una visión general del estado de las cuentas por cobrar. En Process Mining, este atributo resulta útil para filtrar casos y centrarse en poblaciones concretas, como todas las facturas vencidas abiertas. Es una dimensión clave del Dashboard de antigüedad y estado de facturas vencidas, ya que ofrece visibilidad inmediata sobre el estado actual de la cartera de facturas y ayuda a priorizar las actividades de cobro. Por qué es importante Ofrece una visión rápida del estado actual de una factura y facilita el filtrado y la priorización de los esfuerzos de cobro. Dónde obtenerlo Normalmente está disponible en la tabla AR_PAYMENT_SCHEDULES_ALL, en un campo denominado STATUS. Ejemplos AbiertaCerradaDisputadaEn cobro | |||
| Fecha de promesa de pago PromiseToPayDate | La fecha en la que el cliente se ha comprometido a realizar un pago. | ||
| Descripción Durante las actividades de cobro, un cliente puede comprometerse a realizar un pago en una fecha futura. Esta «fecha de promesa de pago» se registra para hacer seguimiento de dicho compromiso. Este atributo es importante para gestionar los Workflows de cobro y evaluar la fiabilidad de los compromisos de los clientes. Al comparar la fecha de promesa de pago con la fecha real de recepción del pago, las personas encargadas del cobro pueden evaluar la tasa de cumplimiento de estas promesas. Esto ayuda a prever el flujo de caja con mayor precisión y a decidir cuándo intensificar los esfuerzos de cobro si no se cumple una promesa. Por qué es importante Registra los compromisos de pago de los clientes, ayuda a prever las entradas de efectivo y permite gestionar la eficacia de las negociaciones de cobro. Dónde obtenerlo Se almacena en el módulo Oracle Advanced Collections, probablemente en tablas como IEX_PROMISES_T. Ejemplos 2023-06-102023-06-252023-07-05 | |||
| Hora de finalización EndTime | Marca de tiempo que indica cuándo se completó una actividad con duración. | ||
| Descripción En las actividades que tienen un inicio y un fin diferenciados, este atributo registra la hora de finalización. Aunque muchos eventos de Process Mining son instantáneos, algunos, como 'Dispute Investigation', pueden prolongarse durante un periodo de tiempo. Disponer de una hora de finalización independiente permite calcular con precisión los tiempos de procesamiento de las actividades. Es más exacto que inferir la duración a partir de la hora de inicio de la actividad siguiente, especialmente cuando existen periodos de inactividad. Esto resulta esencial para analizar el uso de los recursos e identificar qué pasos concretos del proceso requieren más tiempo. Por qué es importante Permite calcular con precisión cuánto duran determinadas actividades y ofrece una visión más profunda de los cuellos de botella y del uso de los recursos. Dónde obtenerlo A menudo se trata de un atributo conceptual. Puede obtenerse de una marca de tiempo de 'last updated' o de un campo específico de 'close date' en las tablas de origen correspondientes a la actividad. Ejemplos 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Importe del límite de crédito CreditLimitAmount | Importe máximo de crédito aprobado para el cliente. | ||
| Descripción El importe del límite de crédito representa la exposición crediticia total que una empresa está dispuesta a asumir con un cliente concreto. Se determina durante el proceso de revisión crediticia. Este atributo es esencial para el Dashboard de impacto de las decisiones sobre límites de crédito. Al relacionar el límite de crédito aprobado con el comportamiento de pago posterior y las bajas contables, la empresa puede evaluar la eficacia de sus políticas de riesgo crediticio. El análisis puede revelar si unos límites de crédito excesivamente altos contribuyen a un aumento de la deuda incobrable y ayudar a perfeccionar el proceso de aprobación de crédito. Por qué es importante Es fundamental para evaluar la eficacia de las políticas de riesgo crediticio al relacionar el límite de crédito aprobado con los resultados de pago y las bajas contables. Dónde obtenerlo Se gestiona en Oracle Credit Management y normalmente se almacena en tablas relacionadas con los perfiles de crédito de los clientes, como HZ_CUST_PROFILE_AMTS. Ejemplos 10000.0050000.00250000.00 | |||
| Moneda de la factura InvoiceCurrency | La moneda en la que se expresa el importe de la factura. | ||
| Descripción Este atributo especifica la moneda de la factura, como USD, EUR o GBP. En las organizaciones multinacionales, las facturas suelen emitirse en distintas monedas. El análisis de datos con varias monedas requiere un tratamiento cuidadoso. Este atributo permite filtrar la vista del proceso por moneda o aplicar los tipos de cambio correctos para los informes financieros consolidados. Garantiza que los valores monetarios se interpreten correctamente y que las comparaciones de importes se realicen sobre una base homogénea. Por qué es importante Es esencial para interpretar correctamente los datos financieros en un entorno multidivisa y garantizar un análisis financiero preciso. Dónde obtenerlo Suele encontrarse en la tabla RA_CUSTOMER_TRX_ALL como INVOICE_CURRENCY_CODE. Ejemplos USDEURGBPJPY | |||
| Motivo de la disputa DisputeReason | El motivo que proporciona el cliente para impugnar una factura. | ||
| Descripción Cuando un cliente impugna una factura, normalmente proporciona un motivo, como «Precio incorrecto», «Mercancía dañada» o «Factura duplicada». Este atributo registra dicho motivo. Analizar los motivos de las disputas es clave para identificar sus causas raíz. Ayuda a detectar problemas recurrentes en procesos anteriores, como la gestión de pedidos o la facturación, que provocan retrasos en los pagos. Al categorizar y hacer seguimiento de la frecuencia de los distintos motivos, la empresa puede aplicar medidas específicas para corregir esas causas raíz, lo que contribuye a reducir el tiempo de ciclo de resolución de disputas. Por qué es importante Ayuda a identificar las causas raíz de las disputas de facturas y permite mejorar de forma proactiva los procesos anteriores para prevenir futuras disputas. Dónde obtenerlo Esta información suele capturarse en los módulos Oracle Advanced Collections u Oracle Channel Revenue Management cuando la gestión de disputas está formalizada. Puede residir en tablas como AR_DISPUTE_HISTORY. Ejemplos Cantidad incorrectaDiferencia de precioMercancía dañadaServicio no prestado | |||
| Se ha dado de baja IsWrittenOff | Indicador booleano que señala si la factura se ha dado de baja como deuda incobrable. | ||
| Descripción Es un indicador derivado que identifica las facturas que la empresa considera incobrables y ha retirado de sus cuentas por cobrar activas. Normalmente representa el resultado final y no deseado de una factura. Este atributo es esencial para calcular el KPI de tasa de bajas de facturas y para el Dashboard de análisis asociado. Permite aislar el conjunto de cobros fallidos e identificar características comunes, como el segmento del cliente o el importe de la factura, que podrían estar relacionadas con un mayor riesgo de baja. Esta información se utiliza para mejorar las políticas de crédito y las estrategias de cobro. Por qué es importante Identifica claramente los casos de cobro fallido, algo esencial para analizar las causas raíz de la deuda incobrable y calcular las tasas de baja. Dónde obtenerlo Es un campo calculado que se obtiene comprobando si existe una actividad 'Invoice Written Off' para el caso o si el estado de la factura es 'Written Off'. Ejemplos truefalse | |||
| Unidad de negocio BusinessUnit | La unidad de negocio o entidad organizativa concreta que emitió la factura. | ||
| Descripción En las organizaciones grandes, las operaciones suelen dividirse en varias unidades de negocio. Este atributo identifica la unidad de negocio asociada a la factura. Analizar el proceso por unidad de negocio permite comparar el rendimiento entre distintas partes de la organización. Puede poner de manifiesto incoherencias en la aplicación de las políticas de crédito y cobro, y revelar qué unidades de negocio gestionan mejor sus cuentas por cobrar. Esto ayuda a compartir buenas prácticas y estandarizar los procesos cuando sea necesario. Por qué es importante Permite comparar el rendimiento entre distintas unidades organizativas y ayuda a identificar buenas prácticas y áreas de mejora. Dónde obtenerlo Está disponible en la tabla RA_CUSTOMER_TRX_ALL mediante el campo ORG_ID, que se vincula con la estructura organizativa. Ejemplos BU North AmericaBU EMEADivisión de servicios globales | |||
Actividades de gestión de crédito y cobros
| Actividad | Descripción | ||
|---|---|---|---|
| Factura dada de baja | Representa la decisión formal de poner fin a los esfuerzos de cobro y asumir el importe de la factura como deuda incobrable. Es una transacción financiera explícita que ajusta el saldo de la factura a cero. | ||
| Por qué es importante Este es un punto final crítico de fallo del proceso de cobro. Analizar las bajas por segmento de clientes, región o límite de crédito ayuda a perfeccionar las políticas crediticias y las estrategias de cobro para minimizar las pérdidas. Dónde obtenerlo Se captura explícitamente a partir de la creación de un ajuste en la tabla AR_ADJUSTMENTS_ALL con un RECEIVABLES_TRX_ID que apunta a una actividad de deuda incobrable o baja. Recopilar Fecha de creación de un registro en AR_ADJUSTMENTS_ALL con un tipo de actividad de baja. Tipo de evento explicit | |||
| Factura generada | Marca la creación del registro de transacción de la factura en Oracle Fusion Financials. Es el inicio oficial del ciclo de vida de la factura en el módulo de cuentas por cobrar y sirve como punto de partida principal para el análisis. | ||
| Por qué es importante Este es el evento inicial fundamental del recorrido de la factura. Todos los cálculos posteriores del tiempo de ciclo, como el Days Sales Outstanding (DSO) y el tiempo de ciclo de pago de la factura, dependen de esta marca de tiempo inicial. Dónde obtenerlo Es un evento explícito capturado de la columna CREATION_DATE o TRX_DATE de la tabla RA_CUSTOMER_TRX_ALL para un TRX_NUMBER específico (Invoice Number). Recopilar La marca de tiempo del evento corresponde a CREATION_DATE de la tabla RA_CUSTOMER_TRX_ALL. Tipo de evento explicit | |||
| Pago aplicado | Representa la aplicación de un pago recibido a una factura concreta, lo que reduce el saldo pendiente de la factura. Este es el paso que vincula formalmente un pago con una factura. | ||
| Por qué es importante Esta actividad es fundamental para reconocer que una factura se ha pagado. Es el verdadero punto final del cálculo de los días de ventas pendientes (DSO) y del ciclo de contabilización del pago. Dónde obtenerlo Es un evento explícito capturado a partir de APPLY_DATE en la tabla AR_RECEIVABLE_APPLICATIONS_ALL, que vincula un recibo de efectivo con una transacción del cliente (factura). Recopilar APPLY_DATE de AR_RECEIVABLE_APPLICATIONS_ALL para la factura correspondiente. Tipo de evento explicit | |||
| Pago recibido | Marca la recepción de fondos de un cliente, que todavía puede no haberse aplicado a una factura concreta. Se captura cuando se crea una transacción de recibo de efectivo en el sistema. | ||
| Por qué es importante Este es un hito importante del proceso de cobro, ya que indica que se ha recibido el efectivo. El tiempo transcurrido entre este evento y la aplicación del pago mide la eficiencia del procesamiento interno. Dónde obtenerlo Se captura explícitamente a partir de RECEIPT_DATE en la tabla AR_CASH_RECEIPTS_ALL. Después, el recibo puede vincularse a la factura a la que se aplicó mediante AR_RECEIVABLE_APPLICATIONS_ALL. Recopilar RECEIPT_DATE de AR_CASH_RECEIPTS_ALL, vinculado mediante las tablas de aplicación. Tipo de evento explicit | |||
| Procedimiento de gestión de morosidad iniciado | Representa el inicio formal del proceso de gestión de morosidad de una factura vencida y suele incluir el envío de la primera carta oficial de reclamación. Normalmente se registra cuando se ejecuta un proceso por lotes de gestión de morosidad que incluye la factura. | ||
| Por qué es importante El seguimiento de esta actividad es fundamental para medir la eficacia de la gestión de morosidad y el cumplimiento de sus políticas. Proporciona una base para medir cuánto tiempo tarda este proceso en generar un pago. Dónde obtenerlo Se registra en el módulo Oracle Advanced Collections. La fecha de creación de un registro de gestión de morosidad en tablas como IEX_DUNNINGS, vinculado al ID de la transacción, marca este evento. Recopilar Fecha de creación del registro en la tabla IEX_DUNNINGS asociado a la factura. Tipo de evento explicit | |||
| Vencimiento de la fecha límite de pago | Evento calculado que ocurre cuando la fecha actual supera la fecha de vencimiento de la factura sin que esta se haya pagado por completo. Este evento marca la transición de la factura del estado «vigente» al estado «vencida». | ||
| Por qué es importante Este es un hito clave que activa los procesos de cobro y gestión de morosidad. Analizar el volumen y el valor de las facturas que superan su fecha de vencimiento es esencial para gestionar el capital circulante y evaluar el riesgo crediticio. Dónde obtenerlo Este evento se calcula comparando la fecha actual del sistema con DUE_DATE en la tabla AR_PAYMENT_SCHEDULES_ALL para las facturas cuyo STATUS es «OP» (Open). Recopilar Evento calculado: ocurre cuando SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Tipo de evento calculated | |||
| Acción de cobro completada | Representa una acción manual realizada por una persona encargada del cobro, como hacer una llamada telefónica, enviar un correo electrónico o registrar una nota de interacción. Estas acciones se registran como «actividades» o «interacciones» en el módulo de cobro. | ||
| Por qué es importante Supervisar las acciones de cobro ayuda a medir la eficiencia y la eficacia del Workflow manual de cobro. Permite analizar la frecuencia de las actividades y su correlación con el éxito del pago. Dónde obtenerlo Se captura del historial de interacciones o actividades de Oracle Advanced Collections, por ejemplo, de JTF_IH_ACTIVITIES, vinculado al cliente y, posiblemente, a la factura concreta. Recopilar Marca de tiempo de creación de los registros en JTF_IH_ACTIVITIES con un código de resultado o motivo relevante. Tipo de evento explicit | |||
| Disputa registrada | Indica que el cliente ha impugnado formalmente la factura, de forma parcial o total. Normalmente se captura mediante un cambio de estado en el calendario de pagos de la factura. | ||
| Por qué es importante Esta actividad marca el inicio del proceso de resolución de la disputa. Analizar el tiempo transcurrido desde el registro hasta la resolución es fundamental para identificar cuellos de botella que retrasan el cobro. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla AR_PAYMENT_SCHEDULES_ALL, cuando el campo STATUS cambia a «DS» (Disputed). La marca de tiempo puede obtenerse de tablas de auditoría o de la fecha de la última actualización. Recopilar Detectar cuándo AR_PAYMENT_SCHEDULES_ALL.STATUS cambia a «DS» para la factura. Tipo de evento inferred | |||
| Disputa resuelta | Indica que se ha investigado una disputa registrada y se ha alcanzado una resolución. Se captura cuando se elimina el estado de disputa de la factura. | ||
| Por qué es importante Este evento marca el final del ciclo de resolución de la disputa. La duración entre «Disputa registrada» y este evento es un KPI clave para medir la eficiencia operativa y su impacto en el flujo de caja. Dónde obtenerlo Se infiere cuando STATUS en AR_PAYMENT_SCHEDULES_ALL cambia de «DS» (Disputed) a «OP» (Open) o a «CL» (Closed) después de una nota de crédito o un ajuste. Recopilar Detectar cuándo AR_PAYMENT_SCHEDULES_ALL.STATUS cambia de «DS» a otro estado. Tipo de evento inferred | |||
| Estrategia de cobro asignada | Ocurre cuando se asigna una estrategia automatizada de cobro a la factura o al cliente moroso. Esto define la serie de pasos y actividades que seguirá el sistema o la persona encargada del cobro. | ||
| Por qué es importante Este evento ofrece información sobre el grado de automatización del proceso de cobro. Analizar qué estrategias se asignan y cuáles son sus resultados ayuda a optimizar los enfoques de cobro para distintos segmentos de clientes. Dónde obtenerlo Se registra en el módulo Oracle Advanced Collections. Normalmente se identifica consultando la fecha de creación de una asignación de estrategia en tablas como IEX_STRATEGIES u otros objetos relacionados. Recopilar Fecha de creación del elemento de trabajo de la estrategia en las tablas de cobro vinculadas al cliente o a la transacción. Tipo de evento explicit | |||
| Factura cerrada | Ocurre cuando el saldo pendiente de la factura llega a cero, ya sea mediante un pago, la aplicación de una nota de crédito o un ajuste. Esto marca la finalización satisfactoria del ciclo de vida de la factura. | ||
| Por qué es importante Este evento constituye uno de los principales puntos finales satisfactorios del proceso. Supervisar el cierre de las facturas es fundamental para comprender la salud general de la cartera de cuentas por cobrar. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla AR_PAYMENT_SCHEDULES_ALL, cuando STATUS cambia a «CL» (Closed). La marca de tiempo corresponde a LAST_UPDATE_DATE de este cambio. Recopilar Detectar cuándo AR_PAYMENT_SCHEDULES_ALL.STATUS pasa a «CL» para la factura. Tipo de evento inferred | |||
| Factura enviada al cliente | Indica que la factura se ha entregado formalmente al cliente, ya sea por medios electrónicos o impresa. Este evento puede registrarse explícitamente mediante un módulo de entrega o inferirse a partir de la fecha de impresión de la factura. | ||
| Por qué es importante Esta actividad marca el inicio del plazo de pago del cliente. Su seguimiento ayuda a calcular con precisión los días de retraso y a analizar cualquier demora entre la generación de la factura y la notificación al cliente. Dónde obtenerlo Puede capturarse a partir de LAST_PRINTED_DATE en RA_CUSTOMER_TRX_ALL. Como alternativa, puede inferirse de los registros de integración con sistemas de entrega de correo electrónico u otras plataformas de comunicación. Recopilar Utilice LAST_PRINTED_DATE de RA_CUSTOMER_TRX_ALL o el estado de un registro de entrega. Tipo de evento inferred | |||
| Promesa de pago creada | Representa un acuerdo formal registrado en el sistema por el que un cliente se compromete a realizar un pago en una fecha concreta. Es uno de los resultados clave de las actividades de cobro. | ||
| Por qué es importante El seguimiento de las promesas de pago y de sus tasas de cumplimiento es un indicador clave del rendimiento de las personas encargadas del cobro. Ayuda a prever el flujo de caja procedente de las cuentas por cobrar vencidas y a evaluar la eficacia del cobro. Dónde obtenerlo Se crea explícitamente en Oracle Advanced Collections. La fecha de creación se captura de la tabla IEX_PROMISE_DETAILS. Recopilar Fecha de creación de la tabla IEX_PROMISE_DETAILS para la factura correspondiente. Tipo de evento explicit | |||
| Revisión de crédito completada | Representa la finalización de una evaluación crediticia para el cliente asociado a la factura. Este evento suele inferirse relacionando la fecha de creación de la factura con la fecha más reciente de finalización de la revisión de crédito de esa cuenta de cliente, lo que proporciona una referencia para el análisis relacionado con el crédito. | ||
| Por qué es importante Analizar el tiempo transcurrido desde la revisión de crédito hasta la colocación del pedido ayuda a identificar retrasos en las etapas iniciales del ciclo de pedido a cobro. Es fundamental para medir el KPI del tiempo de ciclo de aprobación de crédito y comprender el impacto de las decisiones crediticias. Dónde obtenerlo Se infiere consultando HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE para el cliente de la factura (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). La marca de tiempo del evento es LAST_CREDIT_REVIEW_DATE, siempre que preceda a CREATION_DATE de la factura. Recopilar Vincular la factura con la fecha de la revisión de crédito más reciente del cliente anterior a la creación de la factura. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Acceder a Oracle BI Publisher: Inicie sesión en su entorno de Oracle Fusion Financials. Acceda al área Reports and Analytics haciendo clic en el icono Navigator y seleccionando Tools > Reports and Analytics.
- Crear un nuevo modelo de datos: En el panel Reports and Analytics, haga clic en el botón «Browse Catalog». En el catálogo, haga clic en el menú desplegable «New» y seleccione «Data Model».
- Definir el conjunto de datos de consulta SQL: En el editor de Data Model, haga clic en el icono «+» para añadir un nuevo conjunto de datos y seleccione «SQL Query».
- Configurar el origen de datos: En la ventana del nuevo conjunto de datos, asígnele un nombre descriptivo, por ejemplo, «CreditCollectionsEventLog». Seleccione «FSCM» o la base de datos de la aplicación Oracle Fusion correspondiente como Data Source. Establezca el tipo de SQL en «Standard SQL».
- Introducir la consulta SQL: Copie la consulta SQL completa proporcionada en la sección «query» de este documento y péguela en el área de texto SQL Query.
- Definir los parámetros de la consulta: La consulta utiliza parámetros como
:P_START_DATEy:P_END_DATEpara filtrar el intervalo de fechas. BI Publisher los detectará automáticamente. Puede configurarlos como indicaciones para el usuario y establecer su tipo de datos en «Date». - Guardar y probar el modelo de datos: Guarde el modelo de datos en una carpeta compartida o personalizada. Para verificar que la consulta funciona, acceda a la pestaña «Data», introduzca valores de ejemplo para los parámetros, como un intervalo de fechas reciente, y haga clic en «View» para consultar una muestra de los datos de salida. Compruebe que todas las columnas aparecen correctamente.
- Crear un nuevo informe: Vuelva al catálogo, haga clic en el menú desplegable «New» y seleccione «Report». En el cuadro de diálogo «Create Report», seleccione la opción «Use Data Model» y localice el modelo de datos que acaba de guardar.
- Configurar las propiedades del informe: En el editor del informe, basta con un diseño de tabla sencillo para extraer los datos. Establezca el formato de salida predeterminado. Para Process Mining, se recomienda CSV. Para ello, haga clic en «View a List», busque «CSV» en la lista «Output Formats» y marque la casilla correspondiente. Puede desmarcar los demás formatos para simplificar la experiencia de usuario.
- Guardar el informe: Guarde el informe en la misma carpeta que el modelo de datos.
- Programar la extracción: Para automatizar la extracción, puede programar el informe. Abra el informe, haga clic en «Actions» y seleccione «Schedule». Configure la frecuencia, por ejemplo, diaria, especifique CSV como formato de salida y defina el destino de entrega, como un directorio de un servidor de contenido o un servidor externo mediante FTP.
Configuración
- Requisitos previos: La persona que cree y ejecute el informe debe tener los roles de BI adecuados, por ejemplo, «BI Administrator» o «BI Author», y permisos de seguridad sobre los datos para acceder a las tablas subyacentes de Financials (AR, IEX, HZ, JTF).
- Origen de datos: La consulta debe ejecutarse en la base de datos principal de la aplicación, normalmente denominada «FSCM».
- Parámetros del intervalo de fechas: Es fundamental utilizar los parámetros
:P_START_DATEy:P_END_DATEpara limitar el volumen de datos. Para las pruebas iniciales, utilice un intervalo corto, como un mes. En producción, lo habitual es utilizar un periodo móvil de 3 a 6 meses. - Filtrado: En organizaciones grandes, considere la posibilidad de añadir un parámetro para
BU_NAME(nombre de la unidad de negocio) a la cláusulaWHEREde la expresión de tabla comúninvoices_base, con el fin de procesar los datos de una unidad de negocio cada vez. - Consideraciones de rendimiento: La consulta combina varias tablas transaccionales grandes. Ejecutarla para un intervalo amplio sin filtros puede provocar tiempos de ejecución prolongados o interrupciones por tiempo de espera en BI Publisher. Programe el informe para que se ejecute fuera de las horas de mayor actividad.
- Formato de salida: Asegúrese de que el formato de salida predeterminado o programado sea CSV. Esto proporciona un archivo delimitado y limpio que las herramientas de Process Mining pueden utilizar fácilmente. Revise las propiedades de salida CSV para confirmar que el delimitador y la codificación de caracteres están configurados correctamente.
a Consulta de ejemplo sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' ¿Listo para comenzar?
Utilice este Template para preparar sus datos para el análisis y descubrir información valiosa sobre su proceso de gestión de crédito y cobros. Comience hoy su camino hacia la optimización del proceso.
Comience hoy a optimizar su gestión de crédito y cobros
Reduzca el tiempo de ciclo un 30 % y mejore su salud financiera en Oracle Fusion.
No necesita tarjeta de crédito. Comience en cuestión de minutos.