Su Plantilla de Datos para Pedido a Cobro - Procesamiento de Órdenes de Venta
Su Plantilla de Datos para Pedido a Cobro - Procesamiento de Órdenes de Venta
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía práctica de extracción de datos
Pedido a Cobro - Atributos de Procesamiento de Pedidos de Venta
| Nombre | Descripción | ||
|---|---|---|---|
| Pedido de Venta SalesOrder | El identificador único para un pedido de venta, que sirve como caso principal para el proceso de Pedido a Cobro. | ||
| Descripción El número de Pedido de Venta identifica de forma única cada pedido del cliente a lo largo de su ciclo de vida. Actúa como el hilo conductor central que conecta todas las actividades relacionadas, desde la creación inicial y la confirmación 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 permite una vista completa de principio a fin, posibilitando el cálculo de los tiempos de ciclo totales, la identificación de variantes de proceso para pedidos individuales y el seguimiento del recorrido de un pedido a través de diferentes departamentos y sistemas. Por qué es importante Este es el Case ID. Vincula todos los eventos del proceso, haciendo posible rastrear el recorrido de principio a fin de un solo pedido del cliente. Dónde obtener Este identificador se encuentra típicamente en la tabla de encabezado para pedidos de venta en 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 ocurrió una actividad o evento específico para un pedido de venta. | ||
| Descripción Este atributo proporciona la fecha y hora de cada actividad en el proceso, estableciendo la secuencia cronológica de los eventos. Es la columna vertebral temporal del análisis de procesos, registrando exactamente cuándo ocurrió cada paso. En Process Mining, el EventTime es crítico para calcular los tiempos de ciclo, las duraciones entre actividades y los tiempos de entrega generales de los casos. Permite el análisis de rendimiento, la detección de cuellos de botella basada en los tiempos de espera y el monitoreo del cumplimiento de los acuerdos de nivel de servicio (SLAs) 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 los eventos cronológicamente y calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo y las duraciones. Dónde obtener Este es un atributo derivado, obtenido de varios campos de timestamp a través de diferentes 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 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 o tarea de negocio específico que ocurrió dentro del proceso de pedido de venta. | ||
| Descripción Este atributo describe el paso que se ejecutó en un momento específico para un pedido de venta, como 'Pedido de Venta Creado', 'Mercancía Enviada' o 'Pago Recibido'. La secuencia de estas actividades forma el flujo del proceso para cada caso. Analizar el ActivityName es fundamental para Process Mining. Permite la visualización del mapa de procesos, el descubrimiento de diferentes variantes de proceso y la identificación de 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 de Pedido a Cobro. Por qué es importante Este atributo define los pasos en el mapa de procesos, permitiendo la visualización y el análisis del flujo del proceso. Dónde obtener Este es un atributo derivado, construido mapeando estados de transacción o tipos de evento de varias tablas de Oracle Fusion (p. ej., estado de pedido, estado de envío, estado de factura) a una lista estandarizada de nombres de actividad. Ejemplos Pedido de Venta CreadoMercancía EnviadaFactura CreadaPago Recibido | |||
| Automatizado 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 (p. ej., verificación de crédito automatizada, factura generada por el sistema) y acciones manuales del usuario. Típicamente se deriva basándose en el nombre de usuario asociado a una actividad, donde un ID de sistema genérico indica automatización. Analizar este atributo ayuda a medir el nivel de automatización en el proceso y es una entrada directa para el KPI 'Porcentaje de Pedidos Retrabajados Manualmente'. Puede resaltar oportunidades para una mayor automatización mostrando qué pasos manuales son los que más tiempo consumen o son más propensos a errores. Por qué es importante Ayuda a cuantificar el nivel de automatización en el proceso e identificar oportunidades para reducir costosas intervenciones manuales. Dónde obtener Este es un campo derivado, a menudo basado en una regla aplicada al atributo UserName. Por ejemplo, si el usuario es 'SYSTEM' o 'BATCH', este indicador se establece en verdadero. Ejemplos truefalse | |||
| Canal de Ventas SalesChannel | El canal a través del cual se recibió el pedido de venta. | ||
| Descripción Este atributo categoriza el origen del pedido de venta, como 'Web', 'Ventas Directas', 'Socio' o 'EDI'. Proporciona contexto sobre cómo el pedido ingresó a la organización. Segmentar el proceso por canal de ventas es crítico para el Dashboard 'Resumen de Rendimiento del Canal de Ventas'. Ayuda a comparar la eficiencia, los tiempos de ciclo y las tasas de error de diferentes canales para identificar cuáles son más efectivos y cuáles pueden requerir mejoras en el proceso o mayor automatización. Por qué es importante Apoya el análisis de rendimiento por canal, ayudando a identificar los canales más y menos eficientes para el procesamiento de pedidos. Dónde obtener Esta información puede almacenarse en un campo dedicado en el encabezado del pedido de venta. Consulte la documentación de Oracle Fusion Financials. Ejemplos Ventas directasPortal webEDIRevendedor | |||
| Fecha de Entrega Real ActualDeliveryDate | La fecha en que la mercancía fue realmente entregada al cliente. | ||
| Descripción Este atributo registra la fecha de entrega final, que marca la finalización de la parte de cumplimiento del proceso. Es el resultado real contra el cual se miden las fechas planificadas o solicitadas. Esta fecha se compara con la RequestedDeliveryDate para calcular el rendimiento de entrega a tiempo. Es una entrada crítica para el KPI 'Tasa de Entrega a Tiempo' y el Dashboard 'SLA de Entrega', proporcionando una medida clara de la eficacia de la logística y la cadena de suministro. Por qué es importante Esta es la fecha de resultado real utilizada para calcular las tasas de entrega a tiempo y evaluar el rendimiento de cumplimiento frente a las solicitudes del cliente. Dónde obtener Obtenido de las tablas de transacciones de envío y entrega en 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 captura la fecha en la que el cliente desea recibir la mercancía. Sirve como un objetivo clave de rendimiento para la parte de cumplimiento del proceso de Pedido a Cobro. Esta fecha es esencial para calcular el KPI 'Tasa de Entrega a Tiempo' y para soportar el Dashboard del 'Acuerdo de Nivel de Servicio (SLA) de Entrega'. Al comparar esta fecha con la ActualDeliveryDate, la organización puede medir su capacidad para satisfacer las expectativas del cliente e identificar las causas raíz de los retrasos en la entrega. Por qué es importante Actúa como la línea de base para medir el rendimiento de la entrega a tiempo y el cumplimiento de los acuerdos de nivel de servicio (SLA) con el cliente. Dónde obtener Típicamente se encuentra en las tablas de líneas de pedido de venta en Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos 2023-05-202023-06-012023-05-25 | |||
| Fecha de Vencimiento de Pago PaymentDueDate | La fecha límite para que el cliente realice el pago de la factura. | ||
| Descripción La Fecha de Vencimiento de Pago se calcula en función de la fecha de la factura y los términos de pago acordados con el cliente. Establece la fecha límite para el cobro de pagos a tiempo. Este atributo es crucial para el KPI 'Tasa de Cobro de Pagos a Tiempo'. Al comparar la PaymentDueDate con la fecha real de recepción del pago, el sistema puede determinar si un pago fue a tiempo o tardío, ayudando a monitorear el rendimiento de las cuentas por cobrar y a gestionar el flujo de caja. Por qué es importante Sirve como fecha límite para calcular las tasas de pago a tiempo, que es una medida clave de la eficiencia del flujo de caja. Dónde obtener Encontrado en las tablas de cuentas por cobrar o de facturas dentro 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 cargado al cliente por todo el pedido de venta. Incluye la suma de todos los artículos de línea, impuestos y otros cargos, antes de aplicar cualquier descuento. En el análisis de procesos, este atributo es crucial para el Process Mining basado en valor. Permite segmentar los pedidos por valor (p. ej., pedidos de alto valor frente a pedidos de bajo valor) para ver si siguen diferentes rutas de proceso o tienen diferentes tiempos de ciclo. También ayuda a priorizar los esfuerzos de mejora del proceso en los casos más significativos financieramente. Por qué es importante Permite el análisis del impacto financiero, ayudando a priorizar las mejoras de procesos en pedidos de alto valor y a comprender los factores de costo. Dónde obtener Típicamente se encuentra en las tablas del encabezado del pedido de venta en 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 a nivel de usuario, la distribución de la carga de trabajo y la adherencia a los procedimientos estándar. Analizar por usuario ayuda a identificar necesidades de capacitación, reconocer individuos o equipos de alto rendimiento e investigar desviaciones causadas por usuarios específicos. También es valioso para fines de cumplimiento y auditoría para rastrear quién realizó qué acciones. Por qué es importante Permite el análisis del rendimiento por usuario, la distribución de la carga de trabajo y la identificación de patrones de retrabajo manual vinculados a individuos. Dónde obtener Típicamente obtenido de campos como CREATED_BY o LAST_UPDATED_BY en tablas de transacciones de Oracle Fusion, a menudo vinculado 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 la razón social de la cuenta de cliente vinculada al pedido de venta. Es una dimensión esencial para segmentar y analizar el proceso con un enfoque centrado en el cliente. El análisis por cliente ayuda a detectar si existen cuentas con tiempos de ciclo más elevados, mayor volumen de reprocesos o desviaciones particulares. Esta información permite mejorar la atención al cliente, personalizar los procesos para cuentas estratégicas y solucionar incidencias que impacten en la satisfacción del usuario. Por qué es importante Permite un análisis centrado en el cliente para identificar problemas de proceso que afectan a clientes específicos y mejorar la satisfacción del cliente. Dónde obtener Obtenido de las tablas maestras de datos de clientes (p. ej., HZ_PARTIES) y vinculado al pedido de venta a través de un ID de cliente. Ejemplos Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| ¿Factura Corregida? IsInvoiceCorrected | Una bandera que indica si una factura ha sido corregida o revisada después de su creación inicial. | ||
| Descripción Este atributo booleano es verdadero si una factura pasó por un bucle de corrección, indicado por la presencia de una actividad 'Factura Corregida'. Marca los casos que implicaron retrabajo en la etapa de facturación. Esta es una entrada clave para el Dashboard 'Análisis de Precisión y Retrabajo de Facturas' y el KPI 'Tasa de Retrabajo de Facturas'. Ayuda a cuantificar la extensión de los errores de facturación y permite el análisis de causa raíz para identificar por qué son necesarias las correcciones, con el objetivo de reducir el trabajo manual y los retrasos en los pagos. Por qué es importante Identifica el retrabajo de facturas, que es un indicador clave de ineficiencia del proceso, problemas de calidad de datos y posibles retrasos en el pago. Dónde obtener Este es un campo calculado, típicamente establecido como verdadero para un caso si existe una actividad 'Factura Corregida' en su registro de eventos. Ejemplos falsetrue | |||
| Condiciones de Pago PaymentTerms | Los términos acordados para el pago del cliente. | ||
| Descripción Este atributo especifica las condiciones bajo las cuales se espera que un cliente pague su factura, por ejemplo, 'Neto 30' o 'Neto 60'. Estos términos son la base para calcular la PaymentDueDate. En el análisis, la segmentación por términos de pago puede ayudar a explicar las variaciones en los tiempos de ciclo de pago. Proporciona contexto para el KPI 'Tasa de Pago a Tiempo', ya que diferentes términos naturalmente conducen a diferentes comportamientos de pago. Esto puede informar la política de crédito y la previsión de flujo de caja. Por qué es importante Proporciona un contexto crucial para el análisis del comportamiento de pago y ayuda a explicar las variaciones en los tiempos de ciclo de factura a pago. Dónde obtener Disponible a nivel de pedido de venta o cuenta de cliente dentro de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos Neto 30Neto 60Vencimiento al Recibo | |||
| Es Entrega a Tiempo IsOnTimeDelivery | Una bandera calculada que es verdadera si la entrega real fue en o antes de la fecha de entrega solicitada. | ||
| Descripción Este atributo booleano se deriva comparando la ActualDeliveryDate con la RequestedDeliveryDate. Proporciona un indicador simple, a nivel de caso, del rendimiento de la entrega. Esta bandera es la base para calcular el KPI agregado 'Tasa de Entrega a Tiempo'. Simplifica el filtrado y el análisis, permitiendo a los usuarios aislar rápidamente todos los pedidos tardíos para realizar un análisis de causa raíz sobre los factores que contribuyen a los retrasos. Por qué es importante Mide directamente el rendimiento del cumplimiento frente a las expectativas del cliente y simplifica el análisis de los pedidos tardíos. Dónde obtener Este es un campo calculado. La lógica es: ActualDeliveryDate <= RequestedDeliveryDate. Ejemplos truefalse | |||
| Es Pago Atrasado IsLatePayment | Una bandera calculada que es verdadera si el pago se recibió después de la fecha de vencimiento del pago. | ||
| Descripción Este atributo booleano se deriva comparando la fecha real de recepción del pago con la PaymentDueDate. Proporciona un indicador claro de si una factura se pagó a tiempo. Este atributo se utiliza para calcular el KPI 'Tasa de Pago a Tiempo'. Permite una fácil segmentación de pagos a tiempo versus pagos tardíos para analizar las características de los clientes que pagan tarde, las razones comunes de los retrasos y el impacto financiero en el capital de trabajo. Por qué es importante Mide directamente la efectividad de la recaudación de pagos y simplifica el análisis de los pagos atrasados. Dónde obtener Este es un campo calculado. La lógica es: PaymentReceivedDate > PaymentDueDate. Ejemplos falsetrue | |||
| Método de Envío ShippingMethod | El método o transportista utilizado para el envío de la mercancía al cliente. | ||
| Descripción Este atributo detalla el transportista logístico o el nivel de servicio utilizado para la entrega, como 'Carga Terrestre', 'Envío Aéreo Express' o 'Mensajería Local'. Esta información es esencial para el Dashboard 'Cumplimiento de Entrega por Método de Envío'. Permite comparar el rendimiento de entrega a tiempo y los costos de envío entre diferentes métodos y transportistas, helping 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 la comparación del rendimiento de diferentes transportistas y métodos de envío. Dónde obtener Disponible en las tablas de envío y cumplimiento dentro de Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos FedEx GroundUPS Next Day AirDHL International | |||
| Nombre de Producto ProductName | El nombre del producto o servicio que se vende. | ||
| Descripción Este atributo especifica el artículo en la línea del pedido de venta. Si un pedido tiene varias líneas, el caso podría analizarse a nivel de artículo de línea, o este atributo podría agregarse a nivel de encabezado. Analizar por producto ayuda a comprender si ciertos productos están asociados con flujos de proceso más complejos o problemáticos, como frecuentes retrasos en la entrega o problemas de pago. Esto puede informar las estrategias de gestión de productos y cadena de suministro. Por qué es importante Permite el análisis del rendimiento del proceso para diferentes productos, destacando los artículos que pueden tener rutas de cumplimiento o facturación complejas. Dónde obtener Obtenido de las tablas de líneas de pedido de venta y unido a una tabla maestra de productos. Consulte la documentación de Oracle Fusion Financials. Ejemplos Standard Widget X1Paquete de Servicio PremiumComponent Y2-B | |||
| Número de Factura InvoiceNumber | El identificador único para 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 venta y cumplimiento con la parte de liquidación financiera del proceso. Si bien el Pedido de Venta es el ID de caso principal, el Número de Factura es crítico para analizar los subprocesos de facturación y pago. Es esencial para rastrear correcciones de facturas, disputas y el estado de pago, soportando Dashboards como 'Análisis de Precisión y Retrabajo de Facturas'. Por qué es importante Proporciona un vínculo crucial con el proceso de cuentas por cobrar y es necesario para analizar el retrabajo de facturas y los ciclos de pago. Dónde obtener Disponible en las tablas de transacciones de cuentas por cobrar en Oracle Fusion, como RA_CUSTOMER_TRX_ALL. Ejemplos INV-93485INV-93486INV-93487 | |||
| País del Cliente CustomerCountry | El país donde se encuentra el cliente. | ||
| Descripción Este atributo proporciona 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 es valioso para comprender el impacto de las regulaciones locales, los desafíos logísticos y las condiciones del mercado en el proceso de Pedido a Cobro. Por qué es importante Permite el análisis geográfico para identificar variaciones regionales en la eficiencia del proceso, el cumplimiento y el comportamiento del cliente. Dónde obtener Obtenido de las tablas maestras de datos de clientes (HZ_LOCATIONS, HZ_PARTY_SITES) vinculadas al pedido de venta. Ejemplos EE. UU.AlemaniaJapón | |||
| Source System SourceSystemIdentifier | Identifica el sistema de origen del cual se extrajeron los datos del evento. | ||
| Descripción Este atributo especifica el origen de los datos, lo cual es particularmente útil en entornos donde múltiples sistemas están involucrados en el proceso de Pedido a Cobro. Por ejemplo, los datos del pedido podrían provenir de Oracle Fusion, mientras que los datos de envío podrían originarse de un sistema logístico de terceros. En el análisis, esto ayuda a comprender el linaje de los datos y puede usarse para filtrar la vista del proceso para eventos de sistemas específicos. Es crucial para la validación de datos y para identificar la fragmentación del proceso en diferentes panoramas de TI. Por qué es importante Proporciona contexto sobre el origen de los datos, lo cual es crucial para la gobernanza de datos y la resolución de problemas en entornos multisistema. Dónde obtener Este es típicamente un valor estático añadido durante el proceso de extracción y transformación de datos para etiquetar el origen del dataset. Ejemplos Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Tipo de Pedido OrderType | Una clasificación para el 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 propósito comercial. Los tipos comunes incluyen ventas estándar, pedidos de servicio, autorizaciones de devolución de material (RMA) y pedidos internos. Analizar el proceso por tipo de pedido es importante porque los diferentes tipos a menudo tienen flujos de proceso y objetivos de rendimiento distintos. Esta segmentación ayuda a comprender las variaciones del proceso que son intencionales y esperadas, evitando que se malinterpreten como desviaciones. Por qué es importante Permite la segmentación de diferentes flujos de proceso legítimos (por ejemplo, estándar vs. devoluciones) para asegurar un análisis justo y preciso. Dónde obtener Típicamente disponible como un campo en la tabla del encabezado del pedido de venta en Oracle Fusion. Consulte la documentación de Oracle Fusion Financials. Ejemplos Pedido de Venta EstándarAutorización de DevoluciónOrden de Servicio | |||
| Última actualización de datos LastUpdateDate | El timestamp 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 en el conjunto de datos de Process Mining. Proporciona transparencia sobre la actualidad de los datos que se analizan. Esta información es vital para que los usuarios comprendan cuán actual es el análisis del proceso. Ayuda a gestionar las expectativas sobre la puntualidad de los datos y es importante para establecer y monitorear las programaciones de actualización de datos. Por qué es importante Indica la frescura de los datos, asegurando que los usuarios estén al tanto de cuán actualizado está su análisis de proceso. Dónde obtener Este valor se genera y se estampa en el 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 dentro de la empresa que posee la transacción. Permite la comparación de rendimiento entre diferentes partes de la organización. Segmentar el proceso por unidad de negocio ayuda a identificar variaciones en eficiencia, costo y cumplimiento en toda la empresa. Este análisis puede revelar mejores prácticas en unidades de alto rendimiento que pueden compartirse, o resaltar unidades de bajo rendimiento que requieren mejoras de proceso dirigidas. Por qué es importante Permite la evaluación comparativa del rendimiento y el análisis de la consistencia del proceso en diferentes unidades organizativas. Dónde obtener Típicamente disponible en el encabezado del pedido de venta y vinculado a la estructura organizacional definida en Oracle Fusion. Ejemplos BU-NorteaméricaBU-EMEAServicios Globales | |||
Pedido a Cobro - Actividades de Procesamiento de Pedidos de Venta
| Actividad | Descripción | ||
|---|---|---|---|
| Factura Creada | Esta actividad representa la creación de la factura del cliente en el módulo de Cuentas por Cobrar, típicamente desencadenada 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 de Factura a Pago' y la eficiencia general del flujo de caja. Dónde obtener Este es un evento explícito en Cuentas por Cobrar de Oracle (AR). Se crea un registro de factura en la tabla RA_CUSTOMER_TRX_ALL con una fecha de transacción. Capturar Capturado de la fecha de creación de la transacción de factura en el módulo de Cuentas por Cobrar (AR). Tipo de evento explicit | |||
| Mercancía Enviada | Esta actividad marca el punto en que la mercancía ha sido despachada del almacén y está 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 crítico que significa la finalización de la parte de cumplimiento del proceso y desencadena la facturación. Es esencial para medir los tiempos de envío a tiempo y los plazos de entrega. Dónde obtener Este es un evento explícito registrado en Ejecución de Envíos de Oracle. La transacción de confirmación de envío crea un registro en tablas de envío como WSH_DELIVERY_DETAILS con una fecha de envío. Capturar Capturado de la marca de tiempo de la 'fecha de envío real' en el registro de detalle de entrega asociado con la línea del pedido. Tipo de evento explicit | |||
| Pago Recibido | Esta actividad significa que el pago del cliente ha sido recibido y aplicado a la factura en Cuentas por Cobrar. Esto se captura cuando se contabiliza una aplicación de recibo de caja. | ||
| Por qué es importante Este es un hito crítico para medir el 'Tiempo de Ciclo Total de Pedido a Cobro' y la 'Tasa de Pago a Tiempo'. Representa la conversión de la venta en efectivo. Dónde obtener Este es un evento explícito en Cuentas por Cobrar de Oracle. Se registra en tablas de recibos de caja como AR_RECEIVABLE_APPLICATIONS_ALL cuando un recibo se aplica a una factura. Capturar Capturado de la marca de tiempo de la 'fecha de aplicación' del registro de aplicación de recibo de efectivo en Cuentas por Cobrar (AR). Tipo de evento explicit | |||
| Pedido Cerrado | La actividad final del proceso, que indica que todas las líneas del pedido de venta han sido cumplidas, facturadas y cerradas. El estado del encabezado del pedido se actualiza a 'Cerrado'. | ||
| Por qué es importante Esta actividad marca el final exitoso del ciclo de vida del pedido de venta. Es esencial para calcular las duraciones del proceso de principio a fin e identificar pedidos 'zombie' que nunca se cierran. Dónde obtener Inferido del cambio de estado del encabezado del pedido de venta a 'Cerrado' en la tabla DOO_HEADERS_ALL. La marca de tiempo de este cambio de estado final sirve como la hora del evento. Capturar Derivado de la marca de tiempo del cambio de estado a 'Cerrado' en el encabezado del pedido de venta. Tipo de evento inferred | |||
| Pedido Confirmado | Este hito clave significa que el pedido de venta ha superado todas las verificaciones iniciales, incluida la aprobación de crédito, y ahora está comprometido para su cumplimiento. Típicamente se infiere cuando el estado del pedido avanza a un estado como 'Esperando Envío' o 'Programado'. | ||
| Por qué es importante Esta actividad es un hito crítico para calcular el 'Tiempo Promedio de Confirmación de Pedido' y marca el traspaso desde la entrada de pedidos al proceso de cumplimiento. Dónde obtener Inferido de un cambio en el estado del encabezado o línea del pedido de venta a un valor que indica que está listo para el cumplimiento (por ejemplo, 'En Espera de Envío'). Verifique las columnas de estado en DOO_HEADERS_ALL o DOO_FULFILL_LINES_ALL. Capturar Derivado de la marca de tiempo cuando 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 de pedido de venta, representando el momento en que se introduce un nuevo pedido de venta en Oracle Fusion. Este evento se captura típicamente de forma explícita cuando un usuario guarda un nuevo registro de pedido en el módulo de Gestión de Pedidos. | ||
| Por qué es importante Como inicio del proceso, esta actividad es esencial para medir el tiempo total del ciclo de Pedido a Cobro y analizar los volúmenes de entrada de pedidos. Dónde obtener Registrado explícitamente al crear un registro de pedido de venta en la Nube de Gestión de Pedidos. Busque las marcas de tiempo de creación en la tabla DOO_HEADERS_ALL. Capturar Capturado de la marca de tiempo de creación del registro del encabezado del pedido de venta. Tipo de evento explicit | |||
| Factura Corregida | Ocurre cuando una factura creada previamente es modificada, reemitida o acreditada debido a errores o disputas con el cliente. Esto se suele registrar mediante la creación de una nota de crédito o una nueva versión de la factura. | ||
| Por qué es importante El seguimiento de las correcciones de factura es clave para el KPI 'Tasa de Retrabajo de Facturas', destacando problemas en el proceso de facturación que pueden retrasar los pagos y aumentar los costos administrativos. Dónde obtener Inferido por la creación de una nota de crédito (vinculada a la factura original) o una versión posterior de la misma factura en la tabla RA_CUSTOMER_TRX_ALL. Capturar Derivado al identificar 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 la línea del pedido de venta. El sistema compromete un stock específico, asegurando que esté disponible cuando el pedido esté listo para ser preparado. | ||
| Por qué es importante El seguimiento de esto ayuda a analizar el KPI 'Tiempo de Entrega de Asignación de Inventario' e identifica retrasos entre la confirmación del pedido y el aseguramiento de la mercancía. Dónde obtener Este evento a menudo se captura en módulos de inventario o de ejecución de la cadena de suministro. Puede inferirse de las actualizaciones de estado en la línea de cumplimiento que indican que el inventario ha sido detallado o reservado. Capturar Inferido de los cambios de estado de la línea de cumplimiento relacionados con la reserva o programación de inventario. Tipo de evento inferred | |||
| Línea de Pedido Cerrada | Representa el cierre final de una línea de pedido de venta individual, indicando que ha sido completamente enviada, facturada y no se esperan más transacciones. El sistema actualiza el estado de la línea a 'Cerrada'. | ||
| Por qué es importante El cierre de las líneas de pedido significa la finalización de todas las obligaciones contractuales para ese artículo. Analizar esto ayuda a identificar pedidos que permanecen abiertos mucho después del cumplimiento y el pago. Dónde obtener Inferido del cambio de estado de la línea de cumplimiento a 'Cerrado' en la tabla DOO_FULFILL_LINES_ALL. La marca de tiempo de este cambio de estado marca el evento. Capturar Derivado de la marca de tiempo del cambio de estado a 'Cerrado' en la línea de cumplimiento. Tipo de evento inferred | |||
| Mercancía Entregada | Indica que el cliente ha recibido el envío. Esta información a menudo proviene de un transportista externo y se actualiza en Oracle Fusion, o puede inferirse basándose en un tiempo de tránsito estándar desde la fecha de envío. | ||
| Por qué es importante Esta actividad es crucial para calcular el KPI 'Tasa de Entrega a Tiempo' y medir con precisión los niveles de servicio al cliente. Dónde obtener Este a menudo no es un evento nativo de Oracle. Puede capturarse si existe integración con transportistas, o calcularse añadiendo un tiempo de tránsito estándar a la fecha de 'Mercancía Enviada'. Requiere análisis del sistema. Capturar Inferido de las transmisiones de datos del transportista o calculado en función de la fecha de envío más un tiempo de tránsito promedio. Tipo de evento inferred | |||
| Mercancía Recogida | Representa la recogida física de la mercancía del almacén para cumplir el pedido. Este es un paso clave en el proceso logístico y se registra usualmente en el módulo de gestión de almacén o de envíos. | ||
| Por qué es importante Esta actividad proporciona visibilidad sobre las operaciones del almacén. Los retrasos entre la reserva de inventario y la preparación pueden indicar cuellos de botella de recursos o de proceso en el almacén. Dónde obtener Capturado dentro de los módulos de Oracle Fusion Cloud SCM (Supply Chain Management). Puede inferirse del cambio de estado de una onda de picking o un albarán de picking asociado con la línea del pedido de venta. Capturar Inferido de la marca de tiempo de finalización de la transacción de picking en los módulos SCM. Tipo de evento inferred | |||
| Pedido Cancelado | Representa la cancelación de un pedido de venta antes de que haya sido enviado por completo. Esto puede ocurrir por diversas razones y resulta en un estado final de 'Cancelado'. | ||
| Por qué es importante Esta es una ruta de excepción crítica. Analizar los pedidos cancelados ayuda a identificar las causas raíz, como roturas de stock, problemas de precios o cambio de opinión del cliente, lo que puede informar mejoras en el proceso. Dónde obtener Inferido del cambio de estado del encabezado o línea del pedido de venta a un estado 'Cancelado'. La marca de tiempo de este cambio de estado se utiliza para registrar el evento. Capturar Derivado de la marca de tiempo del cambio de estado a 'Cancelado' en el encabezado o línea del pedido. Tipo de evento inferred | |||
| Retención de Crédito Aplicada | Esta actividad ocurre cuando un pedido de venta se retiene automáticamente o manualmente debido a una verificación de crédito fallida o a otro problema relacionado con el crédito. Esto se captura generalmente 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 crucial para identificar las razones detrás de los retrasos en el procesamiento de pedidos y para medir la eficiencia del proceso de liberación de retención por crédito. Dónde obtener Inferido de la aplicación de una retención en el pedido de venta. Esto se registra típicamente en tablas relacionadas con retenciones como DOO_HOLDS_ALL, vinculadas al pedido de venta. Capturar Inferido de la creación de un registro en la tabla de retención de pedidos con un tipo de retención de 'Crédito'. Tipo de evento inferred | |||
| Verificación de Crédito Realizada | Representa la ejecución de una verificación de crédito contra la cuenta del cliente para evaluar su solvencia. Este suele ser un paso automatizado o manual dentro del flujo de trabajo de procesamiento de pedidos, y su finalización se registra típicamente como una actualización de estado o una tarea completada. | ||
| Por qué es importante Analizar el tiempo que tardan las verificaciones de crédito ayuda a identificar cuellos de botella en la aprobación de pedidos. Es fundamental para el KPI de 'Tiempo de Verificación de Crédito a Confirmación'. Dónde obtener Puede inferirse de los cambios de estado en el pedido de venta, como pasar a un estado de 'Aprobación de Crédito Pendiente', o de un registro de eventos explícito en la funcionalidad de gestión de crédito. Capturar Inferido de cambios en el estado del pedido o marcas de tiempo asociadas con tareas de revisión de crédito. Tipo de evento inferred | |||
Guías de Extracción
Pasos
- Navegar a Oracle BI Publisher: Inicie sesión en su entorno Oracle Fusion con un usuario que tenga privilegios de BI Administrator o BI Author. Use el menú Navegador para ir a Herramientas > Informes y Análisis. Haga clic en el botón 'Explorar Catálogo' para abrir el Catálogo de Inteligencia de Negocio.
- Crear un Nuevo Modelo de Datos: En el Catálogo de BI, navegue a una carpeta adecuada (por ejemplo, Shared Folders > Custom). Haga clic en el menú desplegable 'Nuevo' y seleccione 'Modelo de Datos'.
- Definir el Conjunto de Datos de Consulta SQL: En el editor del Modelo de Datos, haga clic en el icono '+' para crear un nuevo conjunto de datos y seleccione 'Consulta SQL'. Aparecerá un cuadro de diálogo. Nombre el conjunto de datos (por ejemplo, 'OrderToCash_EventLog'), seleccione 'Oracle BI EE' como Fuente de Datos y elija 'SQL Estándar' como tipo de SQL.
- Introducir la Consulta SQL: Copie la consulta SQL completa proporcionada en la sección 'query' de este documento y péguela en el área de texto de la Consulta SQL. La consulta incluye parámetros para la fecha de inicio y fin (:p_start_date y :p_end_date) que serán reconocidos automáticamente por BI Publisher.
- Configurar Propiedades del Modelo de Datos: Después de pegar la consulta, haga clic en 'OK'. Navegue a la sección 'Propiedades' en el panel izquierdo del editor del modelo de datos. Asegúrese de que 'Incluir Etiquetas de Parámetros' esté marcado. También puede establecer valores predeterminados para los parámetros de fecha si lo desea.
- Ver y Guardar el Modelo de Datos: Haga clic en la pestaña 'Datos'. Es posible que se le pida que introduzca valores para los parámetros de fecha. Introduzca un rango de fechas pequeño para probar. Haga clic en 'Ver' para ver una muestra de los datos. Si los datos aparecen correctamente, guarde el modelo de datos haciendo clic en el icono de guardar y dándole un nombre descriptivo (por ejemplo, 'OrderToCash_EventLog_DM').
- Crear un Informe a partir del Modelo de Datos: Con el modelo de datos guardado, haga clic en el botón 'Crear Informe' en la esquina superior derecha. Esto abrirá el asistente de creación de informes.
- Configurar el Informe: En el asistente, seleccione la opción 'Usar Modelo de Datos'. El asistente le guiará a través de la configuración del diseño. Para una exportación CSV simple, puede elegir el diseño de 'Tabla'. Arrastre y suelte todas las columnas en la tabla. Haga clic en 'Siguiente' y luego desmarque 'Mostrar Fila de Totales Generales'. Haga clic en 'Finalizar' para guardar el informe. Asigne un nombre como 'OrderToCash_EventLog_Report'.
- Ejecutar el Informe: Abra el informe recién creado. Se le pedirá que introduzca las fechas de inicio y fin para la extracción. Proporcione el rango de fechas deseado.
- Exportar los Datos: Una vez que se ejecute el informe, haga clic en el menú desplegable 'Ver' y seleccione una opción de vista diferente, como 'Ver Informe'. Luego, busque el enlace o icono 'Exportar' y elija 'CSV' como formato de exportación. Esto descargará el archivo de registro de eventos.
- Preparar para la Carga: Abra el archivo CSV descargado. Verifique que los encabezados de las columnas coincidan con los atributos requeridos: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate e IsAutomated. El archivo ahora está listo para ser cargado en la herramienta de Process Mining.
Configuración
- Privilegios de Usuario: Debe tener un rol con privilegios de creación de modelos de datos e informes de 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 una configuración especial.
- Parámetros de Rango de Fechas: La consulta utiliza dos parámetros, :p_start_date y :p_end_date, para filtrar los datos. Se recomienda encarecidamente extraer datos en lotes manejables, como de 3 a 6 meses a la vez, para evitar tiempos de espera de informes y problemas de rendimiento.
- Filtrado por Unidad de Negocio: Para limitar el alcance de la extracción, puede añadir una cláusula WHERE a la CTE BaseOrders en la consulta para filtrar por una ID de Unidad de Negocio específica (por ejemplo, AND dhead.SUBMITTING_BU_ID IN ([Su ID de Unidad de Negocio])).
- Filtrado por Tipo de Pedido: También puede filtrar por tipos de pedidos de venta específicos añadiendo una condición en dhead.SOURCE_ORDER_TYPE_CODE en la CTE BaseOrders.
- Rendimiento: Para conjuntos de datos muy grandes que abarcan varios años, este enfoque de consulta única puede ser lento. Considere ejecutarlo durante horas de menor actividad 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
- Acceder a la Consola BICC: Inicie sesión en su instancia de Oracle Fusion Applications con un usuario que tenga el rol BICC_ADMINISTRATOR. Navegue a Herramientas y seleccione Business Intelligence Cloud Connector del menú.
- Crear una Nueva Oferta: Dentro de la consola BICC, haga clic en Configurar Almacenamiento Externo para establecer su destino, que puede ser Oracle Universal Content Management (UCM) o un bucket de OCI Object Storage. Asegúrese de que sus detalles de conexión y credenciales sean correctos.
- Iniciar un Nuevo Trabajo de Extracción: Navegue a la sección Administrar Trabajos de Extracción. Haga clic en el icono + para crear un nuevo trabajo. Asigne un nombre descriptivo, por ejemplo, ProcessMind_O2C_SalesOrder_Extract.
- Seleccionar Almacenes de Datos (PVOs): En la configuración del trabajo, busque y añada los Public View Objects (PVOs) necesarios para capturar el ciclo de vida del pedido de venta. Necesitará añadir múltiples PVOs, incluyendo FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice y FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configurar Columnas para cada PVO: Para cada PVO seleccionado, haga clic en el menú Acciones y elija Seleccionar Columnas. 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 consulta para obtener una lista detallada de las columnas requeridas de cada PVO.
- Aplicar Filtros para Cargas Incrementales: Para gestionar el volumen de datos, aplique un filtro a cada PVO basado en la columna LastUpdateDate. Para la ejecución inicial, puede seleccionar un rango de fechas amplio. Para las ejecuciones programadas posteriores, este filtro debe configurarse para extraer solo los registros actualizados desde la última ejecución del trabajo.
- Programar el Trabajo de Extracción: Navegue a la sección Administrar Programación. Cree una nueva programación para su trabajo. Se recomienda ejecutar el trabajo durante las horas de menor actividad, por ejemplo, diariamente durante la noche, para minimizar el impacto en el rendimiento del sistema.
- Enviar y Monitorear el Trabajo: Una vez configurado, envíe el trabajo. Puede monitorear su progreso desde la pantalla Administrar Trabajos de Extracción. Una vez completado con éxito, los archivos de datos estarán disponibles en su ubicación de almacenamiento en la nube configurada en formato CSV comprimido.
- Transformar Datos Crudos en un Registro de Eventos: Descargue los archivos CSV extraídos. BICC proporciona datos de tablas crudas, no un registro de eventos formateado. Debe usar una herramienta externa (como Python, un script de base de datos o una plataforma ETL) para procesar estos archivos. Esto implica:
- Unir datos de diferentes archivos (por ejemplo, vincular datos de facturas al encabezado del pedido de venta).
- Pivotar las columnas de fecha en filas de actividad distintas. Por ejemplo, del archivo FscmTopModelAM.DooTopAM.Header, cree una fila para Pedido de Venta Creado usando CreationDate y otra para Pedido Cerrado usando ClosedDate.
- Mapear 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.
- Formato para 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 ahora está listo para ser cargado en ProcessMind.
Configuración
- Selección de PVO: La precisión del registro de eventos depende totalmente de la selección de los PVO correctos. Los PVO clave incluyen FscmTopModelAM.DooTopAM.Header (para creación y cierre de pedidos), FscmTopModelAM.ScmTopAM.ShipmentLine (para eventos de envío) y FscmTopModelAM.ArTopAM.ReceivableInvoice (para facturación).
- Extracción Incremental: Utilice siempre el filtro LastUpdateDate para extracciones recurrentes. Esto es crítico para el rendimiento y evita extraer el mismo conjunto de datos de varios gigabytes repetidamente. La carga completa inicial debe establecer una línea de base, con ejecuciones posteriores que capturen solo los cambios.
- Rango de Fechas: Para la primera carga histórica, extraiga un período representativo, como los últimos 3 a 6 meses de datos, para equilibrar la exhaustividad con un volumen de datos manejable. Las ejecuciones posteriores serán incrementales.
- Configuración de Almacenamiento: BICC puede exportar a UCM de Oracle o a OCI Object Storage. Generalmente, se recomienda usar 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 comercial para evitar cualquier posible degradación del rendimiento en el sistema transaccional de Oracle Fusion Financials.
- Prerrequisitos: Los usuarios que configuren el trabajo necesitan el rol BICC_ADMINISTRATOR. Debe tener credenciales de almacenamiento en la nube preconfiguradas y una comprensión clara de la lógica de transformación de datos requerida 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