Su plantilla de datos de Order to Cash: procesamiento de pedidos de venta
Su plantilla de datos de Order to Cash: procesamiento de pedidos de venta
- Atributos recomendados para recopilar
- Actividades clave que debe supervisar
- Orientación práctica para extraer datos
Atributos del procesamiento de pedidos de venta de Order to Cash
| Nombre | Descripción | ||
|---|---|---|---|
| Pedido de venta SalesOrder | El identificador único de un pedido de venta, que actúa como caso principal del proceso Order to Cash. | ||
| Descripción El número de pedido de venta identifica de forma única cada pedido del cliente durante todo su ciclo de vida. Actúa como hilo conductor que conecta todas las actividades relacionadas, desde la creación y confirmación iniciales hasta la preparación, la facturación y el pago final. En Process Mining, este atributo es esencial para agrupar todos los eventos relacionados en un único caso. Analizar el proceso por pedido de venta permite obtener una visión completa de principio a fin, calcular los tiempos totales del ciclo, identificar variantes del proceso para cada pedido y seguir el recorrido de un pedido por distintos departamentos y sistemas. Por qué es importante Este es el Case ID. Vincula todos los eventos del proceso y permite rastrear el recorrido completo de un único pedido de cliente. Dónde obtenerlo Este identificador suele encontrarse en la tabla de cabecera de los pedidos de venta de Oracle Fusion, como DOO_HEADERS_ALL. Consulte la documentación de Oracle Fusion Financials. Ejemplos SO-100567SO-100568SO-100569 | |||
| Hora del evento EventTime | La marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específicos para un pedido de venta. | ||
| Descripción Este atributo proporciona la fecha y hora de cada actividad del proceso y establece la secuencia cronológica de los eventos. Es la base temporal del análisis del proceso, ya que registra exactamente cuándo ocurrió cada paso. En Process Mining, EventTime es fundamental para calcular los tiempos de ciclo, las duraciones entre actividades y los tiempos de entrega generales de los casos. Permite analizar el rendimiento, detectar cuellos de botella según los tiempos de espera y supervisar el cumplimiento de los acuerdos de nivel de servicio (SLA) relacionados con la puntualidad. Todos los KPI y Dashboards basados en el tiempo dependen de la precisión de este atributo. Por qué es importante Esta marca de tiempo es esencial para ordenar cronológicamente los eventos y calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo y las duraciones. Dónde obtenerlo Es un atributo derivado, obtenido de varios campos de marca de tiempo de distintas tablas de Oracle Fusion, como la fecha de creación del pedido, la fecha de envío, la fecha de factura y la fecha de pago. Ejemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Nombre de la actividad ActivityName | El nombre del evento empresarial o la tarea específicos que tuvieron lugar dentro del proceso del pedido de venta. | ||
| Descripción Este atributo describe el paso ejecutado en un momento concreto para un pedido de venta, como «Sales Order Created», «Goods Shipped» o «Payment Received». La secuencia de estas actividades forma el flujo del proceso de cada caso. Analizar ActivityName es fundamental para Process Mining. Permite visualizar el mapa de procesos, descubrir distintas variantes del proceso e identificar cuellos de botella donde se acumulan los casos. Es la base para calcular los tiempos de transición entre pasos y comprender la secuencia operativa del proceso Order to Cash. Por qué es importante Este atributo define los pasos del mapa de procesos y permite visualizar y analizar el flujo del proceso. Dónde obtenerlo Es un atributo derivado, construido mediante la asignación de estados de transacción o tipos de evento de varias tablas de Oracle Fusion, como el estado del pedido, el estado del envío y el estado de la factura, a una lista estandarizada de nombres de actividades. Ejemplos Pedido de venta creadoProductos enviadosFactura creadaPago recibido | |||
| Canal de ventas SalesChannel | El canal a través del cual se recibió el pedido de venta. | ||
| Descripción Este atributo clasifica el origen del pedido de venta, como «Web», «Ventas directas», «Socio» o «EDI». Proporciona contexto sobre cómo entró el pedido en la organización. Segmentar el proceso por canal de ventas es fundamental para el Dashboard «Resumen del rendimiento por canal de ventas». Ayuda a comparar la eficiencia, los tiempos de ciclo y las tasas de error de los distintos canales para identificar cuáles son más eficaces y cuáles pueden requerir mejoras o una mayor automatización. Por qué es importante Facilita el análisis del rendimiento por canal y ayuda a identificar los canales más y menos eficientes para procesar pedidos. Dónde obtenerlo Esta información puede almacenarse en un campo específico de la cabecera del pedido de venta. Consulte la documentación de Oracle Fusion Financials. Ejemplos Ventas directasPortal webEDIRevendedor | |||
| Es automática IsAutomated | Un indicador que señala si una actividad fue realizada automáticamente por el sistema o manualmente por un usuario. | ||
| Descripción Este atributo booleano distingue entre eventos impulsados por el sistema, como una comprobación de crédito automatizada o una factura generada por el sistema, y acciones manuales de los usuarios. Normalmente se deriva del nombre de usuario asociado a una actividad, cuando un ID de sistema genérico indica automatización. Analizar este atributo ayuda a medir el nivel de automatización del proceso y sirve como entrada directa para el KPI «Porcentaje de pedidos retrabajados manualmente». Puede revelar oportunidades de automatización adicional al mostrar qué pasos manuales consumen más tiempo o son más propensos a errores. Por qué es importante Ayuda a cuantificar el nivel de automatización del proceso e identificar oportunidades para reducir las costosas intervenciones manuales. Dónde obtenerlo Es un campo derivado, normalmente basado en una regla aplicada al atributo UserName. Por ejemplo, si el usuario es «SYSTEM» o «BATCH», este indicador se establece en true. Ejemplos truefalse | |||
| Fecha de entrega real ActualDeliveryDate | La fecha en la que los productos se entregaron realmente al cliente. | ||
| Descripción Este atributo registra la fecha final de entrega, que marca la finalización de la parte de preparación del proceso. Es el resultado real con el que se comparan las fechas planificadas o solicitadas. Esta fecha se compara con RequestedDeliveryDate para calcular el rendimiento de las entregas puntuales. Es un dato fundamental para el KPI «Tasa de entregas puntuales» y el Dashboard «SLA de entrega», ya que proporciona una medida clara de la eficacia logística y de la cadena de suministro. Por qué es importante Es la fecha real del resultado utilizada para calcular las tasas de entrega puntual y evaluar el rendimiento de la preparación frente a las solicitudes del cliente. Dónde obtenerlo Se obtiene de las tablas de transacciones de envío y entrega de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos 2023-05-202023-06-032023-05-25 | |||
| Fecha de entrega solicitada RequestedDeliveryDate | La fecha de entrega del pedido solicitada por el cliente. | ||
| Descripción Este atributo registra la fecha en la que el cliente desea recibir los productos. Sirve como objetivo de rendimiento clave para la parte de preparación del proceso Order to Cash. Esta fecha es esencial para calcular el KPI «Tasa de entregas puntuales» y respaldar el Dashboard «Acuerdo de nivel de servicio de entrega (SLA)». Al comparar esta fecha con ActualDeliveryDate, la organización puede medir su capacidad para cumplir las expectativas del cliente e identificar las causas raíz de los retrasos en la entrega. Por qué es importante Sirve como referencia para medir el rendimiento de las entregas puntuales y el cumplimiento del acuerdo de nivel de servicio (SLA) con el cliente. Dónde obtenerlo Normalmente se encuentra en las tablas de líneas de pedido de venta de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos 2023-05-202023-06-012023-05-25 | |||
| Fecha de vencimiento del pago PaymentDueDate | La fecha límite en la que el cliente debe realizar el pago de la factura. | ||
| Descripción La fecha de vencimiento del pago se calcula a partir de la fecha de la factura y las condiciones de pago acordadas con el cliente. Establece el plazo para cobrar puntualmente. Este atributo es fundamental para el KPI «Tasa de cobros puntuales». Al comparar PaymentDueDate con la fecha real de recepción del pago, el sistema puede determinar si el pago se realizó a tiempo o con retraso, lo que ayuda a supervisar el rendimiento de las cuentas por cobrar y gestionar el flujo de caja. Por qué es importante Sirve como fecha límite para calcular las tasas de pago puntual, una medida clave de la eficiencia del flujo de caja. Dónde obtenerlo Se encuentra en las tablas de cuentas por cobrar o de facturas de Oracle Fusion, como AR_PAYMENT_SCHEDULES_ALL. Ejemplos 2023-06-192023-07-012023-06-25 | |||
| Importe total del pedido de venta SalesOrderTotalAmount | El valor monetario total del pedido de venta. | ||
| Descripción Este atributo representa el importe total cobrado al cliente por el pedido de venta completo. Incluye la suma de todas las líneas, los impuestos y otros cargos, antes de aplicar descuentos. En el análisis de procesos, este atributo es fundamental para realizar Process Mining basado en el valor. Permite segmentar los pedidos por importe, por ejemplo, pedidos de alto y bajo valor, para comprobar si siguen rutas de proceso diferentes o tienen distintos tiempos de ciclo. También ayuda a priorizar las mejoras en los casos con mayor relevancia financiera. Por qué es importante Permite analizar el impacto financiero, priorizar las mejoras de procesos en los pedidos de alto valor y comprender los factores que impulsan los costes. Dónde obtenerlo Normalmente se encuentra en las tablas de cabecera de pedidos de venta de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos 5250.00125000.75980.50 | |||
| Nombre de usuario UserName | El nombre o ID del usuario que realizó la actividad. | ||
| Descripción Este atributo identifica al empleado o usuario del sistema responsable de ejecutar un paso específico del proceso. Puede utilizarse para analizar el rendimiento individual, la distribución de la carga de trabajo y el cumplimiento de los procedimientos estándar. Analizar los datos por usuario ayuda a identificar necesidades de formación, reconocer a las personas o equipos con mejor rendimiento e investigar desviaciones causadas por usuarios concretos. También resulta valioso para el cumplimiento y las auditorías, ya que permite saber quién realizó cada acción. Por qué es importante Permite analizar el rendimiento por usuario, la distribución de la carga de trabajo e identificar patrones de retrabajo manual asociados a determinadas personas. Dónde obtenerlo Normalmente se obtiene de campos como CREATED_BY o LAST_UPDATED_BY en las tablas de transacciones de Oracle Fusion, a menudo vinculados a una tabla maestra de usuarios como FND_USER. Ejemplos john.smithjane.doesystem_batch_user | |||
| Nombre del cliente CustomerName | El nombre del cliente que realizó el pedido de venta. | ||
| Descripción Este atributo identifica el nombre legal de la cuenta del cliente asociada al pedido de venta. Es una dimensión clave para segmentar y analizar el proceso desde la perspectiva del cliente. Analizar los datos por cliente ayuda a identificar si determinados clientes experimentan tiempos de ciclo más largos, más retrabajos o desviaciones específicas del proceso. Esta información puede utilizarse para mejorar el servicio al cliente, adaptar los procesos para cuentas estratégicas e investigar problemas que afectan a la satisfacción del cliente. Por qué es importante Permite analizar el proceso desde la perspectiva del cliente, identificar problemas que afectan a clientes concretos y mejorar su satisfacción. Dónde obtenerlo Se obtiene de las tablas maestras de clientes, como HZ_PARTIES, y se vincula al pedido de venta mediante un ID de cliente. Ejemplos Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Condiciones de pago PaymentTerms | Las condiciones acordadas para el pago del cliente. | ||
| Descripción Este atributo especifica las condiciones en las que se espera que el cliente pague su factura, por ejemplo, «Net 30» o «Net 60». Estas condiciones son la base para calcular PaymentDueDate. En el análisis, segmentar por condiciones de pago puede ayudar a explicar las variaciones en los tiempos del ciclo de pago. Proporciona contexto para el KPI «On-Time Payment Rate», ya que distintas condiciones generan naturalmente comportamientos de pago diferentes. Esta información puede orientar la política de crédito y las previsiones de flujo de caja. Por qué es importante Proporciona un contexto fundamental para analizar el comportamiento de pago y ayuda a explicar las variaciones en los tiempos del ciclo entre la factura y el pago. Dónde obtenerlo Disponible en el nivel del pedido de venta o de la cuenta del cliente en Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos Neto 30Neto 60Vencimiento al recibir | |||
| Factura corregida IsInvoiceCorrected | Un indicador que señala si una factura se corrigió o revisó después de su creación inicial. | ||
| Descripción Este atributo booleano es verdadero si una factura pasó por un ciclo de corrección, indicado por la presencia de la actividad «Invoice Corrected». Señala los casos que implicaron retrabajo en la etapa de facturación. Es un dato de entrada clave para el panel «Invoice Accuracy & Rework Analysis» y el KPI «Invoice Rework Rate». Ayuda a cuantificar el alcance de los errores de facturación y permite realizar un análisis de causa raíz para identificar por qué son necesarias las correcciones, con el objetivo de reducir el trabajo manual y las demoras en los pagos. Por qué es importante Identifica el retrabajo de facturas, un indicador clave de ineficiencia del proceso, problemas de calidad de datos y posibles demoras en los pagos. Dónde obtenerlo Es un campo calculado que normalmente se establece en verdadero para un caso si su registro de eventos contiene una actividad «Invoice Corrected». Ejemplos falsetrue | |||
| La entrega se realiza a tiempo IsOnTimeDelivery | Un indicador calculado que es verdadero si la entrega real se realizó en la fecha solicitada o antes. | ||
| Descripción Este atributo booleano se obtiene al comparar ActualDeliveryDate con RequestedDeliveryDate. Proporciona un indicador sencillo del rendimiento de la entrega a nivel de caso. Este indicador es la base para calcular el KPI agregado «On-Time Delivery Rate». Simplifica el filtrado y el análisis, ya que permite identificar rápidamente todos los pedidos retrasados y realizar un análisis de causa raíz de los factores que contribuyen a las demoras. Por qué es importante Mide directamente el rendimiento del cumplimiento de pedidos frente a las expectativas del cliente y simplifica el análisis de los pedidos retrasados. Dónde obtenerlo Es un campo calculado. La lógica es: ActualDeliveryDate <= RequestedDeliveryDate. Ejemplos truefalse | |||
| Método de envío ShippingMethod | El método o transportista utilizado para enviar los productos al cliente. | ||
| Descripción Este atributo detalla el transportista logístico o el nivel de servicio utilizado para la entrega, como «Transporte terrestre», «Envío aéreo exprés» o «Mensajería local». Esta información es esencial para el Dashboard «Cumplimiento de las entregas por método de envío». Permite comparar el rendimiento de las entregas puntuales y los costes de envío de distintos métodos y transportistas, lo que ayuda a optimizar la estrategia logística y la selección de proveedores. Por qué es importante Apoya directamente el análisis logístico al permitir comparar el rendimiento de distintos transportistas y métodos de envío. Dónde obtenerlo Disponible en las tablas de envíos y cumplimiento de pedidos de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos FedEx GroundUPS Next Day AirDHL International | |||
| Nombre del producto ProductName | El nombre del producto o servicio que se vende. | ||
| Descripción Este atributo especifica el artículo de la línea del pedido de venta. Si un pedido tiene varias líneas, el caso puede analizarse en el nivel de línea, o este atributo puede agregarse en el nivel de cabecera. Analizar los datos por producto ayuda a comprender si determinados productos están asociados a flujos de proceso más complejos o problemáticos, como retrasos frecuentes en las entregas o problemas de pago. Esta información puede orientar las estrategias de gestión de productos y de la cadena de suministro. Por qué es importante Permite analizar el rendimiento del proceso para distintos productos y destacar los artículos que pueden tener rutas complejas de preparación o facturación. Dónde obtenerlo Se obtiene de las tablas de líneas de pedidos de venta y se combina con una tabla maestra de productos. Consulte la documentación de Oracle Fusion Financials. Ejemplos Standard Widget X1Paquete de servicios premiumComponent Y2-B | |||
| Número de factura InvoiceNumber | El identificador único de la factura del cliente. | ||
| Descripción Este atributo es el número único asignado a la factura generada a partir de la orden de venta. Vincula las actividades de ventas y cumplimiento con la parte de liquidación financiera del proceso. Aunque la orden de venta es el ID del caso principal, el número de factura es fundamental para analizar los subprocesos de facturación y pagos. Es esencial para hacer seguimiento de las correcciones de facturas, las disputas y el estado de los pagos, y respalda Dashboards como «Precisión de facturas y análisis de retrabajo». Por qué es importante Proporciona un vínculo fundamental con el proceso de cuentas por cobrar y es necesario para analizar el retrabajo de facturas y los ciclos de pago. Dónde obtenerlo Disponible en las tablas de transacciones de cuentas por cobrar de Oracle Fusion, como RA_CUSTOMER_TRX_ALL. Ejemplos INV-93485INV-93486INV-93487 | |||
| Pago atrasado IsLatePayment | Un indicador calculado que es verdadero si el pago se recibió después de la fecha de vencimiento. | ||
| Descripción Este atributo booleano se obtiene al comparar la fecha real de recepción del pago con PaymentDueDate. Proporciona un indicador claro de si una factura se pagó a tiempo. Este atributo se utiliza para calcular el KPI «On-Time Payment Rate». Permite segmentar fácilmente los pagos puntuales y atrasados para analizar las características de los clientes que pagan tarde, las causas habituales de las demoras y el impacto financiero en el capital circulante. Por qué es importante Mide directamente la eficacia del cobro de pagos y simplifica el análisis de los pagos vencidos. Dónde obtenerlo Es un campo calculado. La lógica es: PaymentReceivedDate > PaymentDueDate. Ejemplos falsetrue | |||
| País del cliente CustomerCountry | El país donde se encuentra el cliente. | ||
| Descripción Este atributo indica el país de la dirección de envío o facturación del cliente. Es una dimensión clave para el análisis geográfico. Segmentar el proceso por país puede revelar diferencias regionales en el rendimiento del proceso, los tiempos de ciclo o el comportamiento de pago. Esto resulta útil para comprender el impacto de las normativas locales, los desafíos logísticos y las condiciones del mercado en el proceso Order to Cash. Por qué es importante Permite realizar análisis geográficos para identificar variaciones regionales en la eficiencia del proceso, el cumplimiento y el comportamiento del cliente. Dónde obtenerlo Se obtiene de las tablas de datos maestros de clientes (HZ_LOCATIONS, HZ_PARTY_SITES) vinculadas al pedido de venta. Ejemplos USAAlemaniaJapón | |||
| Sistema de origen SourceSystemIdentifier | Identifica el sistema de origen del que se extrajeron los datos del evento. | ||
| Descripción Este atributo especifica el origen de los datos, lo que resulta especialmente útil en entornos donde intervienen varios sistemas en el proceso Order to Cash. Por ejemplo, los datos del pedido pueden proceder de Oracle Fusion, mientras que los datos del envío pueden originarse en un sistema logístico de terceros. En el análisis, ayuda a comprender la trazabilidad de los datos y permite filtrar la vista del proceso para mostrar eventos de sistemas específicos. Es fundamental para validar los datos e identificar la fragmentación del proceso en distintos entornos de TI. Por qué es importante Proporciona contexto sobre el origen de los datos, algo fundamental para la gobernanza de datos y la resolución de problemas en entornos con varios sistemas. Dónde obtenerlo Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos para etiquetar el origen del conjunto de datos. Ejemplos Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Tipo de pedido OrderType | Una clasificación del pedido de venta, como «Standard Order» o «Return Order». | ||
| Descripción Order Type se utiliza para categorizar los pedidos de venta según su finalidad empresarial. Entre los tipos habituales se incluyen las ventas estándar, los pedidos de servicio, las autorizaciones de devolución de materiales (RMA) y los pedidos internos. Analizar el proceso por tipo de pedido es importante porque cada tipo suele tener flujos de proceso y objetivos de rendimiento diferentes. Esta segmentación ayuda a comprender las variaciones del proceso que son intencionadas y esperadas, y evita interpretarlas erróneamente como desviaciones. Por qué es importante Permite segmentar distintos flujos de proceso legítimos, por ejemplo, pedidos estándar y devoluciones, para garantizar un análisis justo y preciso. Dónde obtenerlo Normalmente está disponible como campo en la tabla de cabecera de pedidos de venta de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos Pedido de venta estándarAutorización de devoluciónPedido de servicio | |||
| Última actualización de datos LastUpdateDate | La marca de tiempo que indica la última vez que se actualizaron los datos de este evento desde el sistema de origen. | ||
| Descripción Este atributo registra cuándo se extrajeron o actualizaron por última vez los datos del conjunto de datos de Process Mining. Proporciona transparencia sobre la actualidad de los datos analizados. Esta información es esencial para que los usuarios comprendan hasta qué punto está actualizado el análisis del proceso. Ayuda a gestionar las expectativas sobre la vigencia de los datos y es importante para configurar y supervisar las programaciones de actualización. Por qué es importante Indica la actualidad de los datos y garantiza que los usuarios sepan hasta qué punto está actualizado su análisis del proceso. Dónde obtenerlo Este valor se genera y se asigna al conjunto de datos durante cada ciclo de extracción y transformación de datos. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Unidad de negocio BusinessUnitName | El nombre de la unidad de negocio interna responsable del pedido de venta. | ||
| Descripción Este atributo representa la división o unidad operativa específica de la empresa propietaria de la transacción. Permite comparar el rendimiento entre distintas partes de la organización. Segmentar el proceso por unidad de negocio ayuda a identificar variaciones de eficiencia, costes y cumplimiento en toda la empresa. Este análisis puede revelar buenas prácticas en las unidades con mejor rendimiento para compartirlas, o destacar unidades con bajo rendimiento que requieren mejoras específicas. Por qué es importante Permite comparar el rendimiento y analizar la coherencia de los procesos entre distintas unidades de la organización. Dónde obtenerlo Normalmente está disponible en la cabecera del pedido de venta y vinculado a la estructura organizativa definida en Oracle Fusion. Ejemplos BU-North AmericaBU-EMEAServicios globales | |||
Actividades del procesamiento de pedidos de venta de Order to Cash
| Actividad | Descripción | ||
|---|---|---|---|
| Factura creada | Esta actividad representa la creación de la factura del cliente en el módulo Accounts Receivable, normalmente activada por el evento de confirmación de envío. Se genera un registro de factura con un número único y una fecha de creación. | ||
| Por qué es importante Marca el inicio oficial del ciclo de cobro. Es la base para medir el «Tiempo desde la factura hasta el pago» y la eficiencia general del flujo de caja. Dónde obtenerlo Es un evento explícito en Oracle Accounts Receivable (AR). Se crea un registro de factura en la tabla RA_CUSTOMER_TRX_ALL con una fecha de transacción. Recopilar Se captura a partir de la fecha de creación de la transacción de factura en el módulo AR. Tipo de evento explicit | |||
| Pago recibido | Esta actividad indica que se ha recibido el pago del cliente y se ha aplicado a la factura en Accounts Receivable. Se captura cuando se contabiliza la aplicación de un cobro. | ||
| Por qué es importante Es un hito fundamental para medir el «Tiempo total del ciclo Order to Cash» y la «Tasa de pagos puntuales». Representa la conversión de la venta en efectivo. Dónde obtenerlo Es un evento explícito en Oracle Accounts Receivable. Se registra en tablas de cobros como AR_RECEIVABLE_APPLICATIONS_ALL cuando un cobro se aplica a una factura. Recopilar Se captura a partir de la marca de tiempo «apply date» del registro de aplicación del cobro en AR. Tipo de evento explicit | |||
| Pedido cerrado | La actividad final del proceso indica que todas las líneas del pedido de venta se han preparado, facturado y cerrado. El estado de la cabecera del pedido se actualiza a «Closed». | ||
| Por qué es importante Esta actividad marca el final satisfactorio del ciclo de vida del pedido de venta. Es esencial para calcular las duraciones integrales del proceso e identificar pedidos zombis que nunca se cierran. Dónde obtenerlo Se infiere a partir del cambio del estado de la cabecera del pedido de venta a «Closed» en la tabla DOO_HEADERS_ALL. La marca de tiempo de este cambio de estado final sirve como hora del evento. Recopilar Se obtiene de la marca de tiempo del cambio de estado a «Closed» en la cabecera del pedido de venta. Tipo de evento inferred | |||
| Pedido confirmado | Este hito clave indica que el pedido de venta ha superado todas las comprobaciones iniciales, incluida la aprobación de crédito, y ya está comprometido para su preparación. Normalmente se infiere cuando el estado del pedido avanza a un estado como «Awaiting Shipping» o «Scheduled». | ||
| Por qué es importante Esta actividad es un hito fundamental para calcular el «Tiempo medio de confirmación del pedido» y marca el traspaso de la entrada del pedido al proceso de preparación. Dónde obtenerlo Se infiere a partir del cambio del estado de la cabecera o de la línea del pedido de venta a un valor que indica que está listo para su preparación, por ejemplo, «Awaiting Shipping». Compruebe las columnas de estado en DOO_HEADERS_ALL o DOO_FULFILL_LINES_ALL. Recopilar Se obtiene de la marca de tiempo en la que el estado del pedido cambia a un estado confirmado o programado. Tipo de evento inferred | |||
| Pedido de venta creado | Esta actividad marca el inicio del proceso del pedido de venta y representa el momento en que se introduce un nuevo pedido en Oracle Fusion. Normalmente se registra de forma explícita cuando un usuario guarda un nuevo registro de pedido en el módulo Order Management. | ||
| Por qué es importante Como inicio del proceso, esta actividad es esencial para medir el tiempo total del ciclo Order to Cash y analizar el volumen de pedidos recibidos. Dónde obtenerlo Se registra explícitamente al crear un registro de pedido de venta en Order Management Cloud. Busque las marcas de tiempo de creación en la tabla DOO_HEADERS_ALL. Recopilar Se captura a partir de la marca de tiempo de creación del registro de cabecera del pedido de venta. Tipo de evento explicit | |||
| Productos enviados | Esta actividad marca el momento en que los productos salen del almacén y se encuentran en tránsito hacia el cliente. Se captura cuando se procesa una transacción de confirmación de envío en Oracle Shipping. | ||
| Por qué es importante Este es un hito fundamental que indica la finalización de la parte de preparación del proceso y activa la facturación. Es esencial para medir los plazos de envío y entrega puntuales. Dónde obtenerlo Es un evento explícito registrado en Oracle Shipping Execution. La transacción de confirmación de envío crea un registro en tablas de envíos como WSH_DELIVERY_DETAILS, con una fecha de envío. Recopilar Se captura a partir de la marca de tiempo «actual ship date» del registro de detalle de entrega asociado a la línea del pedido. Tipo de evento explicit | |||
| Comprobación de crédito realizada | Representa la ejecución de una comprobación de crédito sobre la cuenta del cliente para evaluar su solvencia. Suele ser un paso automatizado o manual dentro del Workflow de procesamiento de pedidos, y normalmente se registra como una actualización de estado o una tarea completada. | ||
| Por qué es importante Analizar el tiempo empleado en las comprobaciones de crédito ayuda a identificar cuellos de botella en la aprobación de pedidos. Es fundamental para el KPI «Tiempo desde la comprobación de crédito hasta la confirmación». Dónde obtenerlo Puede inferirse a partir de cambios de estado del pedido de venta, como el paso al estado «Pendiente de aprobación de crédito», o de un Registro de eventos explícito en la funcionalidad de gestión de crédito. Recopilar Se infiere a partir de cambios de estado del pedido o de las marcas de tiempo asociadas a las tareas de revisión de crédito. Tipo de evento inferred | |||
| Factura corregida | Ocurre cuando una factura creada previamente se modifica, se vuelve a emitir o se abona debido a errores o disputas con el cliente. Normalmente se captura mediante la creación de una nota de crédito o de una nueva versión de la factura. | ||
| Por qué es importante El seguimiento de las correcciones de facturas es clave para el KPI «Tasa de retrabajo de facturas», ya que permite detectar problemas en el proceso de facturación que pueden retrasar los pagos y aumentar los costes administrativos. Dónde obtenerlo Se infiere a partir de la creación de una nota de crédito vinculada a la factura original o de una versión posterior de la misma factura en la tabla RA_CUSTOMER_TRX_ALL. Recopilar Se obtiene identificando notas de crédito o facturas que hagan referencia a una transacción de factura anterior. Tipo de evento inferred | |||
| Inventario reservado | Esta actividad representa la asignación o reserva de inventario físico para preparar la línea del pedido de venta. El sistema compromete existencias específicas para garantizar su disponibilidad cuando el pedido esté listo para la recogida. | ||
| Por qué es importante Su seguimiento ayuda a analizar el KPI «Tiempo de aprovisionamiento de la asignación de inventario» e identificar retrasos entre la confirmación del pedido y la reserva de los productos. Dónde obtenerlo Este evento suele capturarse en los módulos de inventario o de ejecución de la cadena de suministro. Puede inferirse a partir de actualizaciones de estado en la línea de preparación que indiquen que el inventario se ha detallado o reservado. Recopilar Se infiere a partir de cambios de estado en la línea de preparación relacionados con la reserva o programación del inventario. Tipo de evento inferred | |||
| Línea del pedido cerrada | Representa el cierre definitivo de una línea individual del pedido de venta e indica que se ha enviado y facturado por completo y que no se esperan más transacciones. El sistema actualiza el estado de la línea a «Closed». | ||
| Por qué es importante El cierre de las líneas del pedido indica que se han completado todas las obligaciones contractuales de ese artículo. Analizarlo ayuda a identificar pedidos que permanecen abiertos mucho después de la preparación y el pago. Dónde obtenerlo Se infiere a partir del cambio del estado de la línea de preparación a «Closed» en la tabla DOO_FULFILL_LINES_ALL. La marca de tiempo de este cambio de estado marca el evento. Recopilar Se obtiene de la marca de tiempo del cambio de estado a «Closed» en la línea de preparación. Tipo de evento inferred | |||
| Pedido cancelado | Representa la cancelación de un pedido de venta antes de que se haya enviado por completo. Puede ocurrir por diversos motivos y da lugar al estado terminal «Cancelled». | ||
| Por qué es importante Esta es una ruta de excepción crítica. Analizar los pedidos cancelados ayuda a identificar causas raíz, como falta de existencias, problemas de precios o un cambio de decisión del cliente, y permite orientar las mejoras del proceso. Dónde obtenerlo Se infiere a partir del cambio del estado de la cabecera o de la línea del pedido de venta a «Cancelled». La marca de tiempo de este cambio de estado se utiliza para registrar el evento. Recopilar Se obtiene de la marca de tiempo del cambio de estado a «Cancelled» en la cabecera o la línea del pedido. Tipo de evento inferred | |||
| Productos entregados | Indica que el cliente ha recibido el envío. Esta información suele proceder de un transportista externo y actualizarse en Oracle Fusion, o puede inferirse a partir de un tiempo de tránsito estándar desde la fecha de envío. | ||
| Por qué es importante Esta actividad es fundamental para calcular el KPI «Tasa de entregas puntuales» y medir con precisión los niveles de servicio al cliente. Dónde obtenerlo A menudo no es un evento nativo de Oracle. Puede capturarse si existe una integración con el transportista o calcularse sumando un tiempo de tránsito estándar a la fecha de «Productos enviados». Requiere un análisis del sistema. Recopilar Se infiere a partir de los datos del transportista o se calcula según la fecha de envío más un tiempo medio de tránsito. Tipo de evento inferred | |||
| Productos recogidos | Representa la recogida física de los productos en el almacén para preparar el pedido. Es un paso clave del proceso logístico y normalmente se registra en el módulo de gestión de almacenes o de envíos. | ||
| Por qué es importante Esta actividad proporciona visibilidad sobre las operaciones del almacén. Los retrasos entre la reserva del inventario y la recogida pueden indicar problemas de recursos o cuellos de botella en los procesos del almacén. Dónde obtenerlo Se captura en los módulos Oracle Fusion Cloud SCM (Supply Chain Management). Puede inferirse a partir del cambio de estado de una ola de recogida o de una lista de recogida asociada a la línea del pedido de venta. Recopilar Se infiere a partir de la marca de tiempo de finalización de la transacción de recogida en los módulos SCM. Tipo de evento inferred | |||
| Retención por crédito aplicada | Esta actividad ocurre cuando un pedido de venta se retiene de forma automática o manual debido a una comprobación de crédito fallida u otro problema relacionado con el crédito. Por lo general, se captura mediante un cambio en el estado de retención del pedido dentro del sistema. | ||
| Por qué es importante El seguimiento de las retenciones por crédito es fundamental para identificar las causas de los retrasos en el procesamiento de pedidos y medir la eficiencia del proceso de liberación de dichas retenciones. Dónde obtenerlo Se infiere a partir de la aplicación de una retención al pedido de venta. Normalmente se registra en tablas relacionadas con las retenciones, como DOO_HOLDS_ALL, vinculadas al pedido de venta. Recopilar Se infiere a partir de la creación de un registro en la tabla de retenciones de pedidos con el tipo de retención «Credit». Tipo de evento inferred | |||
Guías de extracción
Pasos
- Acceda a Oracle BI Publisher: Inicie sesión en su entorno de Oracle Fusion con un usuario que tenga privilegios de BI Administrator o BI Author. Utilice el menú Navigator para ir a Tools > Reports and Analytics. Haga clic en el botón 'Browse Catalog' para abrir el catálogo de Business Intelligence.
- Cree un nuevo modelo de datos: En el catálogo de BI, vaya a una carpeta adecuada, por ejemplo, Shared Folders > Custom. Haga clic en el menú desplegable 'New' y seleccione 'Data Model'.
- Defina el conjunto de datos de la consulta SQL: En el editor de Data Model, haga clic en el icono '+' para crear un conjunto de datos nuevo y seleccione 'SQL Query'. Aparecerá un cuadro de diálogo. Asigne un nombre al conjunto de datos, por ejemplo, 'OrderToCash_EventLog', seleccione 'Oracle BI EE' como fuente de datos y elija 'Standard SQL' como tipo de SQL.
- Introduzca 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 de SQL Query. La consulta incluye parámetros para la fecha inicial y final (:p_start_date y :p_end_date), que BI Publisher reconocerá automáticamente.
- Configure las propiedades del modelo de datos: Después de pegar la consulta, haga clic en 'OK'. Vaya a la sección 'Properties' del panel izquierdo del editor del modelo de datos. Asegúrese de que la opción 'Include Parameter Tags' esté marcada. Si lo desea, también puede establecer valores predeterminados para los parámetros de fecha.
- Consulte y guarde el modelo de datos: Haga clic en la pestaña 'Data'. Es posible que se le solicite introducir valores para los parámetros de fecha. Introduzca un intervalo corto para realizar una prueba. Haga clic en 'View' para consultar una muestra de los datos. Si los datos aparecen correctamente, guarde el modelo haciendo clic en el icono de guardado y asígnele un nombre descriptivo, por ejemplo, 'OrderToCash_EventLog_DM'.
- Cree un informe a partir del modelo de datos: Con el modelo de datos guardado, haga clic en el botón 'Create Report' de la esquina superior derecha. Se abrirá el asistente de creación de informes.
- Configure el informe: En el asistente, seleccione la opción 'Use Data Model'. El asistente le guiará por la configuración del diseño. Para una exportación CSV sencilla, puede elegir el diseño 'Table'. Arrastre todas las columnas a la tabla. Haga clic en 'Next' y desmarque 'Show Grand Totals Row'. Haga clic en 'Finish' para guardar el informe. Asígnele un nombre como 'OrderToCash_EventLog_Report'.
- Ejecute el informe: Abra el informe recién creado. Se le solicitará introducir las fechas inicial y final de la extracción. Indique el intervalo de fechas deseado.
- Exporte los datos: Cuando se ejecute el informe, haga clic en el menú desplegable 'View' y seleccione otra opción de visualización, como 'View Report'. A continuación, busque el enlace o icono 'Export' y elija 'CSV' como formato de exportación. Se descargará el archivo de registro de eventos.
- Prepare la carga: Abra el archivo CSV descargado. Compruebe que los encabezados de columna coincidan con los atributos requeridos: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate e IsAutomated. El archivo ya está listo para cargarse en la herramienta de Process Mining.
Configuración
- Privilegios de usuario: Debe tener un rol con privilegios para crear modelos de datos e informes en BI Publisher, como 'BI Administrator' o 'BI Author'.
- Fuente de datos: La consulta está diseñada para la fuente de datos estándar de la aplicación 'Oracle BI EE', que se conecta a la base de datos transaccional, Fusion Apps. Normalmente no se necesita ninguna configuración especial.
- Parámetros del intervalo de fechas: La consulta utiliza dos parámetros, :p_start_date y :p_end_date, para filtrar los datos. Se recomienda encarecidamente extraer los datos en lotes manejables, por ejemplo, de 3 a 6 meses cada vez, para evitar tiempos de espera y problemas de rendimiento en los informes.
- Filtrado por unidad de negocio: Para limitar el alcance de la extracción, puede añadir una cláusula WHERE al CTE BaseOrders de la consulta y filtrar por un ID de unidad de negocio específico, por ejemplo, AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtrado por tipo de pedido: También puede filtrar tipos específicos de pedidos de venta añadiendo una condición sobre dhead.SOURCE_ORDER_TYPE_CODE en el CTE BaseOrders.
- Rendimiento: En conjuntos de datos muy grandes que abarcan varios años, este enfoque de una sola consulta puede ser lento. Considere ejecutarlo fuera de las horas punta o dividir la extracción en lotes mensuales más pequeños. Asegúrese de que la propiedad 'Enable SQL Pruning' no esté seleccionada en el modelo de datos, ya que puede interferir con consultas UNION complejas.
a Consulta de ejemplo sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' Pasos
- Acceda a la consola de BICC: Inicie sesión en su instancia de Oracle Fusion Applications con un usuario que tenga el rol BICC_ADMINISTRATOR. Vaya a Tools y seleccione Business Intelligence Cloud Connector en el menú.
- Cree una nueva oferta: Dentro de la consola de BICC, haga clic en Configure External Storage para configurar el destino. Puede ser Oracle Universal Content Management (UCM) o un bucket de OCI Object Storage. Compruebe que los datos de conexión y las credenciales sean correctos.
- Inicie un nuevo trabajo de extracción: Vaya a la sección Manage Extract Jobs. Haga clic en el icono + para crear un trabajo nuevo. Asígnele un nombre descriptivo, por ejemplo, ProcessMind_O2C_SalesOrder_Extract.
- Seleccione los almacenes de datos (PVO): En la configuración del trabajo, busque y añada los Public View Objects (PVO) necesarios para capturar el ciclo de vida del pedido de venta. Deberá añadir varios PVO, incluidos FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice y FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configure las columnas de cada PVO: Para cada PVO seleccionado, haga clic en el menú Actions y elija Select Columns. Seleccione cuidadosamente las columnas necesarias para generar el registro de eventos, como HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate e identificadores de usuario. Consulte el manifiesto de la consulta para obtener la lista detallada de columnas requeridas de cada PVO.
- Aplique filtros para las cargas incrementales: Para gestionar el volumen de datos, aplique a cada PVO un filtro basado en la columna LastUpdateDate. En la ejecución inicial, puede seleccionar un intervalo de fechas amplio. En las ejecuciones programadas posteriores, configure este filtro para extraer únicamente los registros actualizados desde la última ejecución del trabajo.
- Programe el trabajo de extracción: Vaya a la sección Manage Schedule. Cree una programación nueva para su trabajo. Se recomienda ejecutarlo fuera de las horas punta, por ejemplo, durante la noche, para minimizar el impacto en el rendimiento del sistema.
- Envíe y supervise el trabajo: Una vez configurado, envíe el trabajo. Puede supervisar su progreso desde la pantalla Manage Extract Jobs. Cuando finalice correctamente, los archivos de datos estarán disponibles en la ubicación de almacenamiento en la nube configurada, en formato CSV comprimido.
- Transforme los datos sin procesar en un registro de eventos: Descargue los archivos CSV extraídos. BICC proporciona datos de tablas sin procesar, no un registro de eventos con formato. Debe utilizar una herramienta externa, como Python, un script de base de datos o una plataforma ETL, para procesar estos archivos. Esto incluye:
- Unir datos de distintos archivos, por ejemplo, vincular los datos de facturas con el encabezado del pedido de venta.
- Convertir las columnas de fecha en filas de actividades diferenciadas. Por ejemplo, a partir del archivo FscmTopModelAM.DooTopAM.Header, cree una fila para Sales Order Created usando CreationDate y otra para Order Closed usando ClosedDate.
- Asignar códigos de estado o indicadores a actividades específicas, como Order Confirmed u Order Cancelled.
- Combinar todos los datos transformados en un único archivo con las columnas requeridas: SalesOrder, ActivityName y EventTime.
- Dé formato para la carga: Asegúrese de que el archivo transformado final sea un único CSV, con columnas que coincidan con los atributos requeridos y recomendados. El archivo ya está listo para cargarse en ProcessMind.
Configuración
- Selección de PVO: La precisión del registro de eventos depende por completo de seleccionar los PVO correctos. Entre los PVO clave se incluyen FscmTopModelAM.DooTopAM.Header, para la creación y el cierre de pedidos; FscmTopModelAM.ScmTopAM.ShipmentLine, para los eventos de envío; y FscmTopModelAM.ArTopAM.ReceivableInvoice, para la facturación.
- Extracción incremental: Utilice siempre el filtro LastUpdateDate para las extracciones recurrentes. Es fundamental para el rendimiento y evita extraer repetidamente el mismo conjunto de datos de varios gigabytes. La carga completa inicial debe establecer una línea base y las ejecuciones posteriores deben capturar únicamente los cambios.
- Intervalo de fechas: Para la primera carga histórica, extraiga un periodo representativo, como los últimos 3 a 6 meses de datos, para equilibrar la integridad con un volumen manejable. Las ejecuciones posteriores serán incrementales.
- Configuración del almacenamiento: BICC puede exportar datos a UCM de Oracle o a OCI Object Storage. En general, se recomienda OCI Object Storage para escenarios de datos masivos y una integración más sencilla con herramientas ETL posteriores.
- Programación de trabajos: Programe los trabajos de extracción fuera del horario laboral para evitar posibles reducciones de rendimiento en el sistema transaccional de Oracle Fusion Financials.
- Requisitos previos: Las personas que configuren el trabajo necesitan el rol BICC_ADMINISTRATOR. Debe contar con credenciales de almacenamiento en la nube previamente configuradas y comprender claramente la lógica de transformación de datos necesaria después de la extracción.
a Consulta de ejemplo config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering ¿Listo para comenzar?
Utilice esta plantilla para agilizar la recopilación de datos y dar los primeros pasos en su recorrido de Process Mining. Empiece hoy mismo a optimizar el procesamiento de pedidos de venta de Order to Cash.
Optimice hoy el procesamiento de pedidos de venta de Order to Cash
Identifique los cuellos de botella y reduzca fácilmente en un 30 % el tiempo del ciclo de Order to Cash.
No necesita tarjeta de crédito. Prueba gratuita de 14 días.