Su Template de datos para el proceso de pedido a cobro: gestión de pedidos de venta
Su Template de datos para el proceso de pedido a cobro: gestión de pedidos de venta
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Indicaciones prácticas para extraer datos
Atributos del proceso de pedido a cobro: gestión de pedidos de venta
| Nombre | Descripción | ||
|---|---|---|---|
| Pedido de venta SalesOrder | Identificador único de un pedido de venta, que sirve como caso principal del proceso de pedido a cobro. | ||
| Descripción El número del pedido de venta identifica de forma única cada pedido de cliente durante todo su ciclo de vida. Es el hilo conductor que conecta todas las actividades relacionadas, desde la creación y confirmación iniciales hasta el cumplimiento, 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 ofrece una visión integral, permite calcular los tiempos de ciclo totales, identificar las variantes del proceso de cada pedido y seguir su recorrido por distintos departamentos y sistemas. Por qué es importante Este es el ID del caso. Vincula todos los eventos del proceso y permite seguir de principio a fin el recorrido de un pedido de cliente. Dónde obtenerlo Este identificador suele encontrarse en la tabla de cabecera de 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 | Marca de tiempo que indica cuándo ocurrió una actividad o un evento específico de 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 el momento exacto en que ocurrió cada paso. En Process Mining, EventTime es fundamental para calcular los tiempos de ciclo, la duración entre actividades y el tiempo total de cada caso. Permite analizar el rendimiento, detectar cuellos de botella a partir de los tiempos de espera y supervisar el cumplimiento de los acuerdos de nivel de servicio (SLA) relacionados con la puntualidad. La precisión de este atributo es esencial para todos los KPI y Dashboards basados en el tiempo. 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 que se obtiene de distintos campos de marca de tiempo de las tablas de Oracle Fusion, como la fecha de creación del pedido, la fecha de envío, la fecha de la factura y la fecha del pago. Ejemplos 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Nombre de la actividad ActivityName | Nombre del evento de negocio o la tarea específica que tuvo lugar en el proceso del pedido de venta. | ||
| Descripción Este atributo describe el paso ejecutado en un momento determinado del proceso de un pedido de venta, como «Pedido de venta creado», «Mercancía enviada» o «Pago recibido». La secuencia de estas actividades conforma el flujo del proceso de cada caso. Analizar ActivityName es fundamental en Process Mining. Permite visualizar el mapa del proceso, descubrir distintas variantes e identificar cuellos de botella donde se acumulan los casos. También sirve de base para calcular los tiempos entre pasos y comprender la secuencia operativa del proceso de pedido a cobro. Por qué es importante Este atributo define los pasos del mapa del proceso y permite visualizar y analizar el flujo del proceso. Dónde obtenerlo Es un atributo derivado que se obtiene al asignar los estados de las transacciones o los tipos de evento de distintas tablas de Oracle Fusion, como el estado del pedido, del envío o de la factura, a una lista estandarizada de nombres de actividades. Ejemplos Pedido de venta creadoProductos enviadosFactura creadaPago recibido | |||
| Canal de ventas SalesChannel | Canal por el que se recibió el pedido de venta. | ||
| Descripción Este atributo clasifica el origen del pedido de venta, por ejemplo, «Web», «Ventas directas», «Socio» o «EDI». Indica cómo llegó el pedido a la organización. Segmentar el proceso por canal de ventas es fundamental para el Dashboard «Resumen del rendimiento por canal de ventas». Permite comparar la eficiencia, los tiempos de ciclo y las tasas de error de los distintos canales, identificar los más eficaces y detectar cuáles podrían necesitar mejoras o más automatización. Por qué es importante Permite analizar el rendimiento por canal e identificar los 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 automatizada IsAutomated | Indicador que señala si el sistema realizó una actividad automáticamente o si la realizó una persona usuaria de forma manual. | ||
| Descripción Este atributo booleano distingue entre eventos ejecutados por el sistema, como una comprobación de crédito automatizada o una factura generada por el sistema, y acciones manuales de usuarios. Suele derivarse del nombre de usuario asociado a una actividad: un ID de sistema genérico indica que se trata de una automatización. Analizar este atributo ayuda a medir el nivel de automatización del proceso y es un dato directo para el KPI «Porcentaje de pedidos retrabajados manualmente». Puede revelar oportunidades para automatizar más pasos al mostrar cuáles requieren 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 que suele basarse 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 | Fecha en que se entregó realmente la mercancía al cliente. | ||
| Descripción Este atributo registra la fecha final de entrega, que marca la finalización de la etapa de cumplimiento 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 a tiempo. Es un dato fundamental para el KPI «Tasa de entregas a tiempo» y el Dashboard «SLA de entrega», ya que permite medir con claridad la eficacia de la logística y la cadena de suministro. Por qué es importante Es la fecha real que se utiliza para calcular la tasa de entregas a tiempo y evaluar el rendimiento del cumplimiento frente a las solicitudes de los clientes. 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 | Fecha en que el cliente solicitó recibir el pedido. | ||
| Descripción Este atributo registra la fecha en que el cliente desea recibir la mercancía. Es un objetivo de rendimiento clave para la etapa de cumplimiento del proceso de pedido a cobro. Esta fecha es esencial para calcular el KPI «Tasa de entregas a tiempo» y respaldar el Dashboard «Acuerdo de nivel de servicio de entrega (SLA)». Al compararla 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 las entregas. Por qué es importante Sirve de referencia para medir el rendimiento de las entregas a tiempo y el cumplimiento del acuerdo de nivel de servicio (SLA) con el cliente. Dónde obtenerlo Suele encontrarse 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 | Fecha límite en la que el cliente debe pagar 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 la fecha límite para cobrar a tiempo. Este atributo es fundamental para el KPI «Tasa de cobro a tiempo». Al comparar PaymentDueDate con la fecha real de recepción del pago, el sistema puede determinar si el pago se recibió a tiempo o con retraso. Esto ayuda a supervisar el rendimiento de las cuentas por cobrar y a gestionar el flujo de efectivo. Por qué es importante Sirve como fecha límite para calcular la tasa de pagos a tiempo, una medida clave de la eficiencia del flujo de efectivo. 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 | Valor monetario total del pedido de venta. | ||
| Descripción Este atributo representa el importe total que se cobra 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 del proceso, este atributo es fundamental para Process Mining basado en el valor. Permite segmentar los pedidos por importe, por ejemplo, de valor alto o bajo, y comprobar si siguen rutas distintas o tienen diferentes tiempos de ciclo. También ayuda a priorizar las mejoras del proceso en los casos con mayor impacto financiero. Por qué es importante Permite analizar el impacto financiero, priorizar las mejoras del proceso en los pedidos de mayor valor y comprender los factores que generan costes. Dónde obtenerlo Suele encontrarse 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 | Nombre o ID de la persona que realizó la actividad. | ||
| Descripción Este atributo identifica a la persona empleada o al usuario del sistema responsable de ejecutar un paso específico del proceso. Permite analizar el rendimiento por usuario, la distribución de la carga de trabajo y el cumplimiento de los procedimientos estándar. El análisis por usuario ayuda a detectar necesidades de formación, reconocer a las personas o los equipos con mejor rendimiento e investigar desviaciones asociadas a usuarios específicos. También es útil 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 y la distribución de la carga de trabajo, así como identificar patrones de retrabajo manual asociados a determinadas personas. Dónde obtenerlo Suele obtenerse 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 | Nombre del cliente que realizó el pedido de venta. | ||
| Descripción Este atributo identifica la razón social 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. El análisis por cliente ayuda a identificar si algunos clientes tienen tiempos de ciclo más largos, más retrabajo o desviaciones específicas del proceso. Esta información puede servir para mejorar la atención al cliente, adaptar los procesos a las cuentas clave 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 específicos y mejorar su satisfacción. Dónde obtenerlo Se obtiene de tablas maestras de datos 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 | |||
| ¿Se corrigió la factura? IsInvoiceCorrected | Indicador que señala si una factura se corrigió o modificó después de su creación inicial. | ||
| Descripción Este atributo booleano es verdadero si la factura pasó por un ciclo de corrección, lo que se indica con la actividad 'Factura corregida'. Señala los casos que requirieron retrabajo durante la facturación. Es un dato clave para el Dashboard 'Análisis de precisión y retrabajo de facturas' y el KPI 'Tasa de retrabajo de facturas'. Ayuda a cuantificar el alcance de los errores de facturación y permite analizar sus causas raíz para determinar por qué se necesitan correcciones, con el objetivo de reducir el trabajo manual y los retrasos en los pagos. Por qué es importante Identifica el retrabajo en la facturación, un indicador clave de ineficiencia del proceso, problemas de calidad de los datos y posibles retrasos en los pagos. Dónde obtenerlo Este es un campo calculado. Por lo general, se establece como verdadero para un caso si su registro de eventos contiene la actividad 'Factura corregida'. Ejemplos falsetrue | |||
| Condiciones de pago PaymentTerms | Condiciones de pago acordadas con el cliente. | ||
| Descripción Este atributo especifica las condiciones en las que se espera que el cliente pague la factura, por ejemplo, «30 días netos» o «60 días netos». Estas condiciones sirven de base para calcular PaymentDueDate. En el análisis, segmentar por condiciones de pago ayuda a explicar las diferencias en los tiempos de ciclo de pago. Aporta contexto al KPI «Tasa de pagos a tiempo», ya que las distintas condiciones suelen dar lugar a diferentes comportamientos de pago. Esta información puede orientar la política de crédito y las previsiones de flujo de efectivo. Por qué es importante Aporta contexto fundamental para analizar el comportamiento de pago y ayuda a explicar las diferencias en los tiempos de ciclo entre la factura y el pago. Dónde obtenerlo Está 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 30 días netos60 días netosVencimiento al recibir | |||
| Entrega a tiempo IsOnTimeDelivery | 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 entrega para cada caso. Este indicador es la base para calcular el KPI agregado «Tasa de entregas a tiempo». Simplifica el filtrado y el análisis, ya que permite identificar rápidamente todos los pedidos con retraso y analizar las causas raíz de las demoras. Por qué es importante Mide directamente el rendimiento del cumplimiento frente a las expectativas de los clientes y simplifica el análisis de los pedidos con retraso. Dónde obtenerlo Es un campo calculado. La lógica es: ActualDeliveryDate <= RequestedDeliveryDate. Ejemplos truefalse | |||
| Método de envío ShippingMethod | Método o transportista utilizado para enviar la mercancía al cliente. | ||
| Descripción Este atributo detalla el transportista o el nivel de servicio logístico 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 entregas por método de envío». Permite comparar el rendimiento de las entregas a tiempo y los costes de envío entre distintos métodos y transportistas, lo que ayuda a optimizar la estrategia logística y la selección de proveedores. Por qué es importante Facilita el análisis logístico al permitir comparar el rendimiento de distintos transportistas y métodos de envío. Dónde obtenerlo Está disponible en las tablas de envío y cumplimiento de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos FedEx GroundUPS Next Day AirDHL International | |||
| Nombre del producto ProductName | 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 por artículo o el atributo puede agregarse en el nivel de cabecera. El análisis por producto ayuda a determinar si algunos productos están asociados a flujos de proceso más complejos o problemáticos, por ejemplo, por retrasos frecuentes en las entregas o problemas con los pagos. Esta información puede orientar la gestión de productos y las estrategias 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 de cumplimiento o facturación complejas. Dónde obtenerlo Se obtiene de las tablas de líneas de pedido de venta y se combina con una tabla maestra de productos. Consulte la documentación de Oracle Fusion Financials. Ejemplos Standard Widget X1Premium Service PackageComponent Y2-B | |||
| Número de factura InvoiceNumber | Identificador único de la factura del cliente. | ||
| Descripción Este atributo es el número único asignado a la factura generada a partir del pedido de venta. Vincula las actividades de ventas y cumplimiento con la etapa de liquidación financiera del proceso. Aunque el pedido de venta es el ID del caso principal, el número de factura es fundamental para analizar los subprocesos de facturación y pago. Permite hacer un seguimiento de las correcciones de facturas, las disputas y el estado de los pagos, y respalda Dashboards como «Análisis de precisión y retrabajo de facturas». 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 Está 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 | 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. Indica claramente si una factura se pagó a tiempo. Este atributo se utiliza para calcular el KPI «Tasa de pagos a tiempo». Permite segmentar fácilmente los pagos puntuales y atrasados para analizar las características de los clientes que pagan tarde, los motivos habituales de los retrasos y el impacto financiero en el capital de trabajo. Por qué es importante Mide directamente la eficacia del cobro y facilita el análisis de los pagos atrasados. Dónde obtenerlo Este es un campo calculado. La lógica es: PaymentReceivedDate > PaymentDueDate. Ejemplos falsetrue | |||
| País del cliente CustomerCountry | 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, los tiempos de ciclo o el comportamiento de pago. Esto ayuda a comprender cómo afectan al proceso de pedido a cobro las normativas locales, los retos logísticos y las condiciones del mercado. Por qué es importante Permite realizar análisis geográficos para identificar diferencias regionales en la eficiencia del proceso, el cumplimiento y el comportamiento de los clientes. Dónde obtenerlo Se obtiene de tablas maestras de datos de clientes, como HZ_LOCATIONS y 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, algo especialmente útil cuando intervienen varios sistemas en el proceso de pedido a cobro. Por ejemplo, los datos del pedido pueden proceder de Oracle Fusion y los datos del envío, de 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 entre 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 Suele ser un valor estático que se añade durante la extracción y transformación de los datos para indicar el origen del conjunto de datos. Ejemplos Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Tipo de pedido OrderType | Clasificación del pedido de venta, como «Pedido estándar» o «Pedido de devolución». | ||
| Descripción El tipo de pedido se utiliza para clasificar los pedidos de venta según su finalidad comercial. Entre los tipos habituales se encuentran 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 distintos. Esta segmentación ayuda a comprender las variaciones previstas y legítimas del proceso, y evita interpretarlas como desviaciones. Por qué es importante Permite segmentar distintos flujos de proceso legítimos, como los pedidos estándar y las devoluciones, para garantizar un análisis justo y preciso. Dónde obtenerlo Suele estar 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 los datos LastUpdateDate | 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. Permite saber si los datos analizados están actualizados. Esta información es fundamental para que quienes usan los datos comprendan cuán reciente es el análisis del proceso. Ayuda a establecer expectativas sobre la actualidad de los datos y es importante para definir y supervisar los calendarios de actualización. Por qué es importante Indica cuán actualizados están los datos para que quienes analizan el proceso sepan si cuentan con información reciente. Dónde obtenerlo Este valor se genera y se incorpora al conjunto de datos en cada ciclo de extracción y transformación. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Unidad de negocio BusinessUnitName | 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 responsable de la transacción. Permite comparar el rendimiento entre distintas áreas de la organización. Segmentar el proceso por unidad de negocio ayuda a identificar diferencias de eficiencia, costes y cumplimiento en toda la empresa. El análisis puede revelar buenas prácticas en las unidades con mejor rendimiento que se pueden compartir, o señalar las que necesitan mejoras específicas en sus procesos. 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 Suele estar disponible en la cabecera del pedido de venta y vinculado a la estructura organizativa definida en Oracle Fusion. Ejemplos BU-North AmericaBU-EMEAGlobal Services | |||
Actividades del proceso de pedido a cobro: gestión de pedidos de venta
| Actividad | Descripción | ||
|---|---|---|---|
| Factura creada | Esta actividad representa la creación de la factura del cliente en el módulo Accounts Receivable, que suele activarse al confirmar el envío. El sistema 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 Este evento se registra explícitamente en Oracle Accounts Receivable (AR). Se crea un registro de factura en la tabla RA_CUSTOMER_TRX_ALL con una fecha de transacción. Capturar Se obtiene 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 recibió el pago del cliente y se aplicó a la factura en Cuentas por cobrar. Se registra cuando se contabiliza la aplicación de un recibo de efectivo. | ||
| Por qué es importante Este es un hito clave para medir el «Tiempo de ciclo total de pedido a cobro» y la «Tasa de pagos a tiempo». 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 recibos de efectivo, como AR_RECEIVABLE_APPLICATIONS_ALL, cuando se aplica un recibo a una factura. Capturar Se obtiene de la marca de tiempo del campo «apply date» del registro de aplicación del recibo de efectivo 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 entregado, 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 la duración integral del proceso e identificar pedidos zombi que nunca se cierran. Dónde obtenerlo Se infiere cuando el estado de la cabecera del pedido de venta cambia a «Closed» en la tabla DOO_HEADERS_ALL. La marca de tiempo de este cambio de estado final se utiliza como hora del evento. Capturar Se obtiene de la marca de tiempo del cambio de estado de la cabecera del pedido de venta a «Closed». 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 está listo para su cumplimiento. Por lo general, se deduce cuando el estado del pedido cambia a uno como «Pendiente de envío» o «Programado». | ||
| Por qué es importante Esta actividad es un hito fundamental para calcular el «Tiempo medio de confirmación de pedidos» y marca el paso de la entrada del pedido al proceso de cumplimiento. Dónde obtenerlo Se deduce de un cambio en el estado de la cabecera o de las líneas del pedido de venta a un valor que indica que está listo para el cumplimiento, como «Pendiente de envío». Consulte las columnas de estado de DOO_HEADERS_ALL o DOO_FULFILL_LINES_ALL. Capturar Se obtiene de la marca de tiempo en que el estado del pedido cambia a confirmado o programado. Tipo de evento inferred | |||
| Pedido de venta creado | Esta actividad marca el inicio del proceso de pedidos de venta: el momento en que se registra un nuevo pedido en Oracle Fusion. Por lo general, el sistema registra este evento cuando un usuario guarda un nuevo pedido en el módulo Order Management. | ||
| Por qué es importante Como inicio del proceso, esta actividad es esencial para medir el tiempo de ciclo total del proceso de pedido al cobro y analizar el volumen de pedidos recibidos. Dónde obtenerlo Se registra explícitamente al crear un pedido de venta en Order Management Cloud. Busque las marcas de tiempo de creación en la tabla DOO_HEADERS_ALL. Capturar Se obtiene 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 comienzan su traslado al cliente. Se registra cuando se procesa una transacción de confirmación de envío en Oracle Shipping. | ||
| Por qué es importante Este hito clave indica que ha finalizado la parte de cumplimiento del proceso y activa la facturación. Es esencial para medir la puntualidad de los envíos y los tiempos de entrega. Dónde obtenerlo Este evento se registra explícitamente en Oracle Shipping Execution. La transacción de confirmación de envío crea un registro con la fecha de envío en tablas como WSH_DELIVERY_DETAILS. Capturar Se obtiene de la marca de tiempo de «fecha real de envío» del registro de detalles de entrega asociado a la línea del pedido. Tipo de evento explicit | |||
| Comprobación de crédito realizada | Representa la comprobación de la solvencia del cliente mediante una consulta a su cuenta. Suele ser un paso automatizado o manual del flujo de trabajo de procesamiento de pedidos, y su finalización normalmente queda registrada como una actualización de estado o una tarea completada. | ||
| Por qué es importante Analizar el tiempo que llevan las comprobaciones de crédito ayuda a identificar cuellos de botella en la aprobación de pedidos. Este dato es fundamental para el KPI «Tiempo desde la comprobación de crédito hasta la confirmación». Dónde obtenerlo Puede deducirse de los 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. Capturar Se deduce de los 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 | Se produce cuando se modifica, se vuelve a emitir o se abona una factura creada anteriormente debido a errores o reclamaciones de clientes. Por lo general, queda registrado al crear una nota de crédito o 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», que pone de manifiesto 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. Capturar Se obtiene identificando las notas de crédito o facturas que hacen 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 cumplir una línea del pedido de venta. El sistema compromete existencias específicas y garantiza que estén disponibles cuando el pedido esté listo para prepararse. | ||
| Por qué es importante Hacer seguimiento de esta actividad ayuda a analizar el KPI «Tiempo de asignación de inventario» e identificar los retrasos entre la confirmación del pedido y la reserva de los productos. Dónde obtenerlo Este evento suele registrarse en los módulos de inventario o ejecución de la cadena de suministro. Puede deducirse de las actualizaciones de estado de la línea de cumplimiento que indican que el inventario se ha detallado o reservado. Capturar Se deduce de los cambios de estado de la línea de cumplimiento relacionados con la reserva o programación del inventario. Tipo de evento inferred | |||
| Línea de pedido cerrada | Representa el cierre definitivo de una línea de pedido de venta, lo que indica que se envió e facturó 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 de pedido indica que se han cumplido todas las obligaciones contractuales correspondientes a ese artículo. Analizarlo ayuda a identificar pedidos que siguen abiertos mucho después de haberse completado la entrega y el pago. Dónde obtenerlo Se infiere cuando el estado de la línea de cumplimiento cambia a «Closed» en la tabla DOO_FULFILL_LINES_ALL. La marca de tiempo de este cambio de estado señala el momento del evento. Capturar Se obtiene de la marca de tiempo del cambio de estado de la línea de cumplimiento a «Closed». 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 final «Cancelled». | ||
| Por qué es importante Esta es una ruta de excepción clave. Analizar los pedidos cancelados ayuda a identificar las causas raíz, como la falta de existencias, problemas de precios o un cambio de opinión del cliente, y permite orientar las mejoras del proceso. Dónde obtenerlo Se infiere cuando el estado de la cabecera o de la línea del pedido de venta cambia a «Cancelled». La marca de tiempo de este cambio de estado se utiliza para registrar el evento. Capturar Se obtiene de la marca de tiempo del cambio de estado de la cabecera o la línea del pedido a «Cancelled». Tipo de evento inferred | |||
| Pedido retenido por crédito | Esta actividad se produce 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, queda registrada como un cambio en el estado de retención del pedido en el sistema. | ||
| Por qué es importante Hacer 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. Dónde obtenerlo Se deduce 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. Capturar Se deduce 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 | |||
| Productos entregados | Indica que el cliente ha recibido el envío. Esta información suele proceder de un transportista externo y se actualiza en Oracle Fusion. También puede deducirse a partir de un tiempo de tránsito estándar contado 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, este evento no forma parte de las funciones nativas de Oracle. Puede registrarse si hay una integración con el transportista o calcularse sumando un tiempo de tránsito estándar a la fecha de «Productos enviados». Requiere analizar el sistema. Capturar Se deduce de los datos proporcionados por el transportista o se calcula a partir de la fecha de envío más el tiempo medio de tránsito. Tipo de evento inferred | |||
| Productos preparados | Representa la preparación física de los productos en el almacén para cumplir el pedido. Es un paso clave del proceso logístico y suele registrarse en el módulo de gestión de almacenes o de envíos. | ||
| Por qué es importante Esta actividad permite ver las operaciones del almacén. Los retrasos entre la reserva del inventario y la preparación de los productos pueden indicar cuellos de botella de recursos o del proceso en el almacén. Dónde obtenerlo Se registra en los módulos Oracle Fusion Cloud SCM (Supply Chain Management). Puede deducirse del cambio de estado de una ola de preparación o de una lista de preparación asociada a la línea del pedido de venta. Capturar Se deduce de la marca de tiempo de finalización de la transacción de preparación en los módulos SCM. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Vaya 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. En el menú Navigator, vaya a Tools > Reports and Analytics. Haga clic en el botón 'Browse Catalog' para abrir Business Intelligence Catalog.
- Cree un modelo de datos: En BI Catalog, 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 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 de la sección 'query' de este documento y péguela en el área de texto SQL Query. La consulta incluye los parámetros de fecha de inicio y fin (: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. Compruebe que esté seleccionada la opción 'Include Parameter Tags'. 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. Indique un intervalo corto para realizar una prueba. Haga clic en 'View' para ver una muestra de los datos. Si los datos se muestran correctamente, guarde el modelo haciendo clic en el icono de guardar y asígnele un nombre descriptivo (por ejemplo, 'OrderToCash_EventLog_DM').
- Cree un informe a partir del modelo de datos: Una vez guardado el modelo, haga clic en el botón 'Create Report', situado en 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 de la disposición. Para exportar un archivo CSV sencillo, puede elegir la disposición '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 que acaba de crear. Se le solicitará que indique las fechas de inicio y fin de la extracción. Introduzca el intervalo deseado.
- Exporte los datos: Cuando se ejecute el informe, haga clic en el menú desplegable 'View' y seleccione otra opció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 del registro de eventos.
- Prepare los datos para cargarlos: 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). Por lo general, 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 que los informes agoten el tiempo de espera y tener problemas de rendimiento.
- Filtro por unidad de negocio: Para limitar el alcance de la extracción, puede añadir una cláusula WHERE a la 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])).
- Filtro 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 la CTE BaseOrders.
- Rendimiento: Si los datos abarcan varios años y son muy voluminosos, este método de consulta única puede ser lento. Considere ejecutarlo fuera de las horas de mayor actividad o dividir la extracción en lotes mensuales más pequeños. Compruebe que la propiedad 'Enable SQL Pruning' no esté seleccionada en Data Model, ya que puede interferir con consultas UNION complejas.
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 oferta: En la consola de BICC, haga clic en Configure External Storage para configurar el destino, que 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 trabajo de extracción: Vaya a la sección Manage Extract Jobs. Haga clic en el icono + para crear un trabajo. 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 registrar el ciclo de vida de los pedidos de venta. Deberá añadir varios PVO, entre ellos 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 ver la lista detallada de las columnas necesarias 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 primera ejecución, puede seleccionar un intervalo de fechas amplio. En las ejecuciones programadas posteriores, configure el filtro para extraer solo los registros actualizados desde la última ejecución del trabajo.
- Programe el trabajo de extracción: Vaya a la sección Manage Schedule y cree una programación para el trabajo. Se recomienda ejecutarlo fuera de las horas de mayor actividad, por ejemplo, durante la noche, para reducir al mínimo el impacto en el rendimiento del sistema.
- Envíe y supervise el trabajo: Una vez configurado, envíe el trabajo. Puede supervisar su progreso en la pantalla Manage Extract Jobs. Cuando finalice correctamente, los archivos de datos estarán disponibles en la ubicación de almacenamiento en la nube que haya configurado, en formato CSV comprimido.
- Transforme los datos sin procesar en un registro de eventos: Descargue los archivos CSV extraídos. BICC proporciona datos sin procesar de las tablas, 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. El proceso incluye:
- Combinar datos de distintos archivos (por ejemplo, vincular los datos de las facturas con el encabezado del pedido de venta).
- Convertir las columnas de fecha en filas de actividad independientes. Por ejemplo, a partir del archivo FscmTopModelAM.DooTopAM.Header, cree una fila para Pedido de venta creado con CreationDate y otra para Pedido cerrado con ClosedDate.
- Asignar códigos de estado o indicadores a actividades específicas, como Pedido confirmado o Pedido cancelado.
- Combinar todos los datos transformados en un solo archivo con las columnas requeridas: SalesOrder, ActivityName y EventTime.
- Prepare el archivo para cargarlo: Compruebe que el archivo transformado final sea un único CSV y que sus columnas 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 que se seleccionen los PVO correctos. Entre los PVO clave se encuentran 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 referencia; las ejecuciones posteriores solo deben capturar los cambios.
- Intervalo de fechas: Para la primera carga histórica, extraiga un período representativo, como los últimos 3 a 6 meses de datos, a fin de equilibrar la cobertura 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 para facilitar la integración con herramientas ETL posteriores.
- Programación de trabajos: Programe las extracciones fuera del horario laboral para evitar posibles problemas de rendimiento en el sistema transaccional de Oracle Fusion Financials.
- Requisitos previos: Quienes configuren el trabajo necesitan el rol BICC_ADMINISTRATOR. También deben estar configuradas las credenciales del almacenamiento en la nube y debe conocerse con claridad la lógica de transformación de datos necesaria después de la extracción.
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 este Template para agilizar la recopilación de datos y dar los primeros pasos en Process Mining. Comience hoy mismo a optimizar el proceso de pedido a cobro: gestión de pedidos de venta.
Optimice hoy el proceso de pedido a cobro: gestión de pedidos de venta
Identifique cuellos de botella y reduzca fácilmente un 30 % el tiempo de ciclo del proceso de pedido a cobro.
No se requiere tarjeta de crédito. Prueba gratuita de 14 días.