> Mejora continua de procesos > De la compra al pago: solicitud de compra > Oracle Fusion Financials > Template de datos

Su Template de datos para solicitudes de compra a pago

Oracle Fusion Financials

← Volver a la guía de mejora

Atributos de las solicitudes de compra a pago(22) Actividades de las solicitudes de compra a pago(12) Guías de extracción(4)

Su Template de datos para solicitudes de compra a pago

Este Template ofrece una guía clara para recopilar los datos esenciales que necesita para analizar el proceso de solicitudes de compra a pago. Indica qué atributos clave recopilar, qué actividades importantes registrar y cómo extraer esta información de Oracle Fusion Financials. Con estos datos, podrá preparar eficazmente el registro de eventos para realizar Process Mining.

Atributos recomendados para recopilar
Actividades clave que debe registrar
Guía para extraer datos de Oracle Fusion Financials

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos de las solicitudes de compra a pago

Estos son los campos de datos recomendados para incluir en el registro de eventos y realizar un análisis completo de las solicitudes de compra a pago.

5 Obligatorio 7 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento de negocio que tuvo lugar en un momento determinado del proceso de solicitud.
Descripción La Actividad representa un paso o hito específico del ciclo de vida de una solicitud de compra. Algunos ejemplos son «Solicitud creada», «Paso de aprobación aprobado» o «Orden de compra creada». Estas actividades se obtienen de los cambios de estado, las acciones de los usuarios o los eventos del sistema registrados en los registros de auditoría o las tablas de transacciones del sistema de origen. Este atributo es esencial para crear el mapa del proceso, que representa visualmente el flujo de las solicitudes. Analizar la secuencia y la frecuencia de las actividades ayuda a identificar las rutas habituales, los cuellos de botella, los ciclos de retrabajo y las desviaciones del procedimiento estándar. Por qué es importante Es la base del mapa del proceso y permite visualizar y analizar el flujo de trabajo de las solicitudes. Dónde obtenerlo Se obtiene de los registros de cambios de estado en tablas como POR_REQUISITION_HEADERS_ALL, del historial de transacciones o de los registros de auditoría del flujo de trabajo, como FA_FUSION_SOAINFRA.WFTASK. Ejemplos Solicitud creadaEtapa de aprobación aprobadaSolicitud rechazadaOrden de compra creada
	Hora del evento EventTime	Marca de tiempo que indica cuándo tuvo lugar la actividad.
Descripción La Hora del evento registra la fecha y la hora exactas en que tuvo lugar una actividad específica. Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos de un caso y se obtiene de las fechas de creación, las fechas de última actualización o las marcas de tiempo de acciones específicas del sistema. En los análisis, la Hora del evento se utiliza para calcular todas las métricas basadas en la duración, como los tiempos de ciclo entre actividades, los tiempos de espera y la duración total del caso. Es esencial para identificar cuellos de botella, medir el rendimiento frente a los SLA y comprender la dinámica temporal del proceso de solicitud. Por qué es importante Este atributo es esencial para calcular todos los KPI relacionados con el tiempo, ordenar correctamente los eventos y analizar el rendimiento del proceso y sus cuellos de botella. Dónde obtenerlo Suele obtenerse de una columna LAST_UPDATE_DATE o CREATION_DATE asociada a la transacción o al cambio de estado, que a menudo se encuentra en tablas como POR_REQUISITION_HEADERS_ALL o en tablas del historial del flujo de trabajo. Ejemplos 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID de solicitud de compra PurchaseRequisitionId	Identificador único de una solicitud de compra, que sirve como ID del caso del proceso.
Descripción El ID de la solicitud de compra es el identificador central que vincula todas las actividades relacionadas con una solicitud específica de bienes o servicios. Al crearla, se asigna a cada solicitud un ID único que se mantiene durante todo su ciclo de vida. En Process Mining, este atributo permite agrupar en un mismo caso todos los eventos relacionados, como la creación, el envío, las etapas de aprobación y el cierre final. Así se puede analizar el recorrido completo de la solicitud, visualizar mapas de procesos, calcular tiempos de ciclo y analizar las variantes de cada solicitud. Por qué es importante Este es el atributo fundamental para hacer un seguimiento de la solicitud desde el inicio hasta el final y realizar análisis a nivel de caso y cálculos de KPI. Dónde obtenerlo Suele ser la clave principal de la tabla de encabezados de solicitudes, por ejemplo, POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID en Oracle Fusion Financials. Ejemplos 100234810023491002350
	Sistema de origen SourceSystem	Sistema de información del que se extrajeron estos datos.
Descripción Este atributo identifica el origen de los datos del proceso. En este modelo de datos, el valor será siempre «Oracle Fusion Financials». En entornos con varios ERP o sistemas integrados, este campo es fundamental para conocer el linaje de los datos, resolver problemas y garantizar su calidad. Aporta contexto sobre la fuente de verdad de los eventos del proceso que se analizan. Por qué es importante Aporta contexto esencial sobre el origen de los datos, algo fundamental para la gobernanza de datos y la integración de datos procedentes de varios sistemas. Dónde obtenerlo Es un valor estático que se añade durante la extracción y transformación de los datos para identificar el origen del conjunto de datos. Ejemplos Oracle Fusion Financials
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la actualización más reciente de los datos desde el sistema de origen.
Descripción Este atributo indica la fecha y la hora de la última extracción de datos de Oracle Fusion Financials. Se aplica al conjunto de datos completo, no a eventos individuales. Los analistas utilizan esta información para conocer la antigüedad de los datos y confirmar cuándo se incluyeron las transacciones más recientes. Es un metadato clave para los informes de Dashboard y para garantizar que los análisis se basen en información actualizada. Por qué es importante Indica la actualidad de los datos para que los análisis sean pertinentes y se basen en la información más reciente disponible. Dónde obtenerlo Esta marca de tiempo se genera y almacena durante la extracción de datos, normalmente mediante la herramienta ETL o la canalización de datos. Ejemplos 2023-10-27T02:00:00Z
	Departamento DepartmentName	Departamento de la organización al que pertenece quien solicita.
Descripción Este atributo indica la unidad organizativa de la persona que creó la solicitud, como «Finanzas», «TI» o «Marketing». Por lo general, se obtiene del perfil de usuario de quien solicita en el sistema de RR. HH. Analizar los datos por departamento es una forma habitual y eficaz de segmentar los datos del proceso. Ayuda a detectar patrones específicos de cada departamento, como tasas de rechazo más altas o tiempos de ciclo más prolongados, que pueden orientar iniciativas de mejora específicas. Es una dimensión clave del Dashboard «Métricas de rendimiento de quienes solicitan». Por qué es importante Permite segmentar el análisis del proceso por unidad de negocio y revelar patrones, rendimiento y problemas de cumplimiento específicos de cada departamento. Dónde obtenerlo Suele obtenerse del perfil de quien solicita. A menudo es necesario unir la tabla de solicitudes con una tabla de RR. HH. o un directorio de usuarios que contenga la información del departamento. Ejemplos Tecnología de la informaciónFinanzasOperacionesMarketing
	Estado de la solicitud RequisitionStatus	Estado actual o final de la solicitud de compra.
Descripción Este atributo indica el estado general de la solicitud en un momento determinado o su resultado final, como «Aprobado», «Rechazado», «En proceso» o «Cerrado». A menudo, es el origen de muchas de las actividades del registro de eventos. Este atributo es clave para el Dashboard «Resumen del estado de las solicitudes», que ofrece una instantánea de la carga de trabajo y las solicitudes pendientes. También se utiliza para calcular KPI basados en resultados, como la tasa de rechazo de solicitudes, mediante el filtrado de los casos que terminan con un estado específico. Por qué es importante Ofrece una instantánea del estado actual de las solicitudes y permite determinar los resultados finales para calcular los KPI. Dónde obtenerlo Se encuentra en la tabla del encabezado de la solicitud, normalmente en un campo como DOCUMENT_STATUS o APPROVAL_STATUS de POR_REQUISITION_HEADERS_ALL. Ejemplos APROBADOEN PROCESORECHAZADORETIRADO
	Fecha requerida RequiredByDate	Fecha en la que quien solicita necesita recibir los bienes o servicios.
Descripción Quien solicita indica esta fecha para establecer el plazo límite de recepción de los artículos solicitados. Sirve como objetivo interno de nivel de servicio (SLA) para el proceso de compras. Este atributo es la base del Dashboard «Rendimiento según la fecha requerida» y del KPI «Tasa de cumplimiento de la fecha requerida». Al comparar esta fecha con la fecha real de creación de la orden de compra o de recepción de los bienes, el análisis permite saber en qué medida el proceso de compras satisface las necesidades de los clientes internos e identificar retrasos sistemáticos. Por qué es importante Es fundamental para medir el rendimiento del proceso frente a los plazos internos y determinar si el proceso de compras satisface las necesidades del negocio a tiempo. Dónde obtenerlo Suele almacenarse en el nivel de las líneas de la solicitud, en tablas como POR_REQUISITION_LINES_ALL, en un campo como NEED_BY_DATE. Ejemplos 2023-11-012023-12-152024-01-31
	Importe total de la solicitud RequisitionTotalAmount	Valor monetario total de la solicitud de compra.
Descripción Este atributo representa la suma del valor de todas las líneas de una solicitud de compra. Es un dato fundamental para comprender la importancia financiera de cada solicitud. En Process Mining, el importe total permite realizar diversos análisis. Por ejemplo, se puede filtrar por solicitudes de alto valor, que suelen seguir rutas de aprobación distintas o estar sujetas a un mayor control. Los Dashboards pueden utilizar este atributo para analizar cómo se relacionan las métricas del proceso, como el tiempo de ciclo o la tasa de rechazo, con el valor de la solicitud. Por qué es importante Aporta contexto financiero y permite analizar los datos por valor para priorizar las mejoras del proceso y comprender cómo influye el importe de la solicitud en el comportamiento del proceso. Dónde obtenerlo Se encuentra en el encabezado de la solicitud, a menudo en un campo como REQUISITION_TOTAL de POR_REQUISITION_HEADERS_ALL. También se puede calcular sumando los importes de las líneas de POR_REQUISITION_LINES_ALL. Ejemplos 550.0012500.7599.99
	Motivo del rechazo RejectionReason	Motivo que indica quien aprueba cuando se rechaza una solicitud o una etapa de aprobación.
Descripción Cuando se rechaza una solicitud, quien la aprueba suele indicar el motivo, ya sea seleccionándolo de una lista predefinida o escribiéndolo. Este atributo recoge esa justificación. Es un atributo fundamental para analizar las causas raíz de los fallos del proceso. Contribuye directamente al Dashboard «Tendencias de modificaciones y rechazos», ya que permite conocer el motivo de los rechazos. Analizar estos motivos ayuda a detectar problemas habituales, como una codificación incorrecta, excesos de presupuesto o incumplimientos de políticas, que después se pueden abordar mediante formación o controles del sistema. Por qué es importante Permite conocer directamente por qué se rechazan las solicitudes y aplicar mejoras específicas para reducir el retrabajo y aumentar la tasa de procesamiento directo. Dónde obtenerlo Se obtiene de los comentarios del flujo de trabajo o de campos específicos con códigos de motivo de rechazo en el registro de auditoría del flujo de trabajo, posiblemente en tablas relacionadas con FA_FUSION_SOAINFRA.WFTASK o con el almacenamiento de comentarios asociado. Ejemplos Cuenta contable del libro mayor incorrectaSupera el presupuesto del centro de costesSe seleccionó un proveedor no preferenteSolicitud duplicada
	Nombre de quien solicita RequesterName	Nombre de la persona empleada que creó y envió la solicitud de compra.
Descripción Este atributo identifica a la persona que inició la solicitud de bienes o servicios. Por lo general, esta información se registra al comienzo del proceso, cuando se crea la solicitud. Analizar el rendimiento del proceso por persona solicitante es fundamental para el Dashboard «Métricas de rendimiento de quienes solicitan». Permite detectar qué usuarios o grupos podrían necesitar formación adicional al mostrar tasas elevadas de modificaciones o rechazos, o tiempos de ciclo prolongados en sus solicitudes. Ofrece una perspectiva centrada en las personas. Por qué es importante Permite analizar el rendimiento por persona solicitante, detectar necesidades de formación e identificar a los usuarios o departamentos más eficientes. Dónde obtenerlo Se obtiene de los datos del encabezado de la solicitud, a menudo vinculando el ID de quien la solicita con una tabla maestra de personas empleadas o usuarios. Busque campos relacionados con PREPARER_ID en POR_REQUISITION_HEADERS_ALL y únalos con PER_ALL_PEOPLE_F. Ejemplos Juan PérezAna GarcíaMaría López
	Unidad de negocio BusinessUnit	Unidad de negocio específica de la organización a la que corresponde la solicitud.
Descripción La Unidad de negocio representa una entidad jurídica o funcional específica de la empresa para la que se realiza la solicitud. Es una agrupación organizativa de nivel superior al departamento. Analizar los datos por Unidad de negocio permite comparar el rendimiento de distintas áreas de la organización a alto nivel. Esto ayuda a la dirección a determinar si las ineficiencias del proceso se limitan a ciertas áreas o están extendidas, y dónde conviene centrar las mejoras. Es una dimensión clave para filtrar casi todos los Dashboards y los KPI. Por qué es importante Aporta contexto organizativo de alto nivel y permite comparar el rendimiento y realizar análisis estratégicos entre distintas áreas de la empresa. Dónde obtenerlo Es un campo organizativo fundamental de Oracle Fusion que suele estar disponible en el encabezado de la solicitud, en tablas como POR_REQUISITION_HEADERS_ALL. Ejemplos Unidad de negocio de NorteaméricaUnidad de negocio de EuropaSede corporativa
	Descripción del artículo ItemDescription	Descripción del producto o servicio solicitado en una línea de la solicitud.
Descripción Este atributo contiene la descripción textual del artículo que se va a adquirir. Aporta detalles específicos sobre los bienes o servicios solicitados. Aunque a menudo no está estructurada, la Descripción del artículo aporta contexto valioso para el análisis. Se puede utilizar en filtros para encontrar solicitudes de tipos de compra específicos que quizá no queden reflejados en el Tipo de solicitud. Por ejemplo, un analista podría buscar todas las solicitudes que incluyan «Licencia de software» para comprender su flujo de proceso y su tiempo de ciclo. Por qué es importante Aporta información detallada sobre lo que se compra y permite filtrar y analizar con mayor precisión bienes o servicios específicos. Dónde obtenerlo Se encuentra en la tabla de líneas de solicitud POR_REQUISITION_LINES_ALL, en un campo como ITEM_DESCRIPTION. Ejemplos Portátil de 15 pulgadas, 16 GB de RAMServicios de consultoría - Proyecto del cuarto trimestreRenovación anual del mantenimiento de software
	Moneda CurrencyCode	Código de moneda del importe de la solicitud, como USD o EUR.
Descripción Este atributo especifica la moneda en la que se expresa el Importe total de la solicitud. En las organizaciones globales, las solicitudes pueden crearse en distintas monedas. Es esencial para interpretar y agregar correctamente los datos financieros. En cualquier análisis que incluya valores monetarios, se debe utilizar el código de moneda para comparar los importes con precisión, ya sea filtrando por una sola moneda o convirtiendo todos los importes a una moneda común. Por qué es importante Garantiza la precisión de los análisis y los informes financieros, especialmente en organizaciones multinacionales que manejan varias monedas. Dónde obtenerlo Suele encontrarse en la tabla del encabezado de la solicitud, junto a los campos de importe, por ejemplo, en POR_REQUISITION_HEADERS_ALL. Ejemplos USDEURGBPJPY
	Nombre de usuario UserName	Nombre de la persona que realizó una actividad específica, como una aprobación o una edición.
Descripción Mientras que el Nombre de quien solicita identifica a la persona que inició el proceso, el Nombre de usuario indica quién realizó un evento concreto, como una aprobación o un rechazo. Esto es especialmente importante en los flujos de trabajo de aprobación con varias etapas, en los que participan distintas personas. Este atributo es fundamental para analizar los cuellos de botella en las aprobaciones y medir el rendimiento de quienes aprueban o de los equipos. Contribuye directamente al Dashboard «Cuellos de botella en el flujo de trabajo de aprobación», ya que permite analizar los tiempos de procesamiento de cada persona que participa en la cadena de aprobación. Por qué es importante Identifica a la persona responsable de cada evento, algo esencial para analizar los tiempos de traspaso, el rendimiento de quienes aprueban y la asignación de recursos. Dónde obtenerlo Se obtiene de las tablas del historial del flujo de trabajo o de los registros de auditoría, como FA_FUSION_SOAINFRA.WFTASK, que registra al usuario asociado a la finalización de cada tarea. Ejemplos Carlos LópezLaura ChenMiguel Brown
	Nombre del proveedor SupplierName	Nombre del proveedor sugerido o preseleccionado para los bienes o servicios.
Descripción Este atributo identifica al proveedor al que se prevé comprar los bienes o servicios. Quien solicita puede sugerirlo, o el sistema puede determinarlo a partir de catálogos o acuerdos anteriores. Analizar los datos por proveedor puede revelar patrones importantes en las compras. Por ejemplo, permite detectar si las solicitudes de ciertos proveedores tardan más en aprobarse o tienen tasas de rechazo más altas. Esta información puede ser útil para gestionar las relaciones con proveedores y definir la estrategia de compras. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, lo que puede contribuir a definir la estrategia de abastecimiento y gestionar las relaciones con proveedores. Dónde obtenerlo Se encuentra en la tabla de líneas de solicitud POR_REQUISITION_LINES_ALL y suele vincularse mediante VENDOR_ID con una tabla maestra de proveedores, como POZ_SUPPLIERS. Ejemplos Suministros de oficina S. A.Soluciones tecnológicas globalesAgencia de marketing creativo
	Número de orden de compra PurchaseOrderNumber	Identificador de la orden de compra creada a partir de la solicitud aprobada.
Descripción Este atributo vincula una solicitud de compra con la orden de compra resultante. Una vez aprobada por completo, la solicitud suele convertirse en una o varias órdenes de compra que se envían a un proveedor. En los análisis, este ID es esencial para hacer un seguimiento de las etapas posteriores a la solicitud. Permite calcular el KPI «Tiempo desde la solicitud hasta la orden de compra» y es compatible con el Dashboard «Tiempo de ciclo desde la solicitud hasta la orden de compra». También permite combinar los datos del proceso de solicitud con los procesos posteriores de órdenes de compra y facturación para analizar de principio a fin el proceso de compra a pago. Por qué es importante Vincula la solicitud con la orden de compra posterior y permite medir el tiempo de ciclo entre ambas y analizar el proceso de principio a fin. Dónde obtenerlo Esta información se almacena cuando se crea una orden de compra. Suele encontrarse consultando las referencias a la solicitud de origen en las tablas de distribución de órdenes de compra, como PO_DISTRIBUTIONS_ALL, que remite a la línea de la solicitud. Ejemplos OC-2023-5832OC-2023-5833OC-2023-5834
	Ruta del flujo de trabajo de aprobación ApprovalWorkflowPath	Secuencia predefinida de personas o grupos que deben aprobar la solicitud.
Descripción Este atributo define el proceso de aprobación estándar previsto para una solicitud según las políticas de la empresa y factores como el importe, el tipo y el departamento. Representa el modelo de proceso previsto. La Ruta del flujo de trabajo de aprobación es fundamental para el cumplimiento y el análisis de conformidad. Contribuye directamente al Dashboard «Análisis de cumplimiento y desviaciones» y al KPI «Índice de conformidad de las solicitudes», ya que permite comparar directamente las etapas de aprobación reales con la ruta establecida. Las desviaciones pueden indicar incumplimientos de políticas o ineficiencias del proceso. Por qué es importante Permite comprobar la conformidad al comparar el flujo real del proceso con la jerarquía de aprobación requerida e identificar las solicitudes que no cumplen los requisitos. Dónde obtenerlo Esta información se configura en Oracle Fusion BPM Worklist o en Approval Management Engine (AMX). Extraer la ruta definida para cada solicitud puede ser complejo y quizá requiera consultar tablas de configuración. Ejemplos Gerente > Director > Vicepresidente de FinanzasResponsable del centro de costes > Seguridad de TIGerente > Responsable del departamento
	Se automatizó IsAutomated	Indicador que señala si el sistema realizó una actividad automáticamente.
Descripción Este atributo identifica los eventos del proceso que ejecutó una cuenta del sistema o un agente automatizado, en lugar de una persona. Algunos ejemplos son los cambios de estado iniciados por el sistema o las etapas de aprobación automatizadas para artículos de bajo valor. Analizar este atributo ayuda a cuantificar el nivel de automatización del proceso. Permite comparar la velocidad y la eficiencia de las etapas automatizadas con las manuales, e identificar oportunidades para ampliar la automatización. Por qué es importante Ayuda a medir el nivel de automatización del proceso e identificar oportunidades para automatizar tareas manuales. Dónde obtenerlo Se obtiene comprobando si el usuario asociado a una actividad es una cuenta del sistema o de servicio. Para ello, se necesita una lista de los ID de usuario del sistema conocidos. Ejemplos truefalse
	Se modificó IsAmendedFlag	Indicador booleano que es verdadero si la solicitud se modificó al menos una vez.
Descripción Este atributo calculado indica si la solicitud se modificó después de enviarse por primera vez. Se obtiene comprobando si en el historial del caso aparece la actividad «Solicitud modificada». Este indicador simplifica el análisis y el cálculo de KPI. Se utiliza directamente para calcular el KPI «Tasa de modificación de solicitudes» e identificar los casos que no se procesan de principio a fin sin intervención. Permite filtrar y comparar fácilmente las métricas del proceso entre solicitudes modificadas y no modificadas. Por qué es importante Simplifica el cálculo de la tasa de modificación y permite comparar fácilmente las solicitudes modificadas con las que no se modificaron. Dónde obtenerlo Este atributo no está en el sistema de origen; se calcula durante la transformación de datos según la presencia de actividades relacionadas con modificaciones en el registro de eventos. Ejemplos truefalse
	Se procesó de principio a fin IsStraightThrough	Indicador que señala si la solicitud se aprobó sin modificaciones ni rechazos.
Descripción Este indicador calculado identifica las solicitudes que completaron el proceso desde el envío hasta la aprobación sin ciclos de retrabajo, como modificaciones o rechazos. Indica que el proceso se completó correctamente en un caso concreto. Este atributo es la base del KPI «Tasa de solicitudes procesadas de principio a fin». Analizar las características de estas solicitudes, como los departamentos, las personas solicitantes o los tipos más habituales, puede revelar buenas prácticas y oportunidades de automatización. Por otro lado, analizar las solicitudes que no se procesaron de principio a fin ayuda a identificar las principales causas de ineficiencia. Por qué es importante Mide directamente la eficiencia del proceso y sirve de base para el KPI «Tasa de solicitudes procesadas de principio a fin», lo que ayuda a identificar las causas del retrabajo. Dónde obtenerlo Este atributo se calcula durante la transformación de datos. El caso se marca como verdadero si no contiene actividades «Solicitud modificada» ni «Paso de aprobación rechazado». Ejemplos truefalse
	Tipo de solicitud RequisitionType	Categoría de la solicitud, por ejemplo, si se solicitan bienes o servicios.
Descripción Este atributo clasifica la solicitud según lo que se pide. Entre los tipos habituales se encuentran bienes, servicios o gastos de capital. El tipo puede influir en el flujo de trabajo de aprobación requerido y en la estrategia de compras. En los análisis, el Tipo de solicitud sirve como dimensión para filtrar y comparar. Por ejemplo, se puede analizar si las solicitudes de servicios tardan más en aprobarse que las de bienes. Ayuda a comprender si los distintos tipos de solicitudes presentan comportamientos o cuellos de botella diferentes. Por qué es importante Permite segmentar el análisis para comprender cómo varía el proceso según el tipo de compra, por ejemplo, entre bienes y servicios. Dónde obtenerlo A menudo se determina según el tipo o la categoría de la línea seleccionada al crear la solicitud. Puede almacenarse en la tabla de líneas de solicitud POR_REQUISITION_LINES_ALL. Ejemplos BienesServiciosGastos de capital

Obligatorio Recomendado Opcional

Actividades de las solicitudes de compra a pago

Estos son los pasos clave y los hitos del proceso que debe registrar en el registro de eventos para descubrir con precisión el proceso de solicitudes de compra a pago.

6 Recomendado 6 Opcional

	Actividad	Descripción
	Orden de compra creada	Este evento se produce cuando se utiliza una línea de solicitud aprobada para generar una orden de compra. Conecta el proceso de solicitudes con la etapa posterior de compras.
Por qué es importante Este es un hito clave para medir el tiempo de entrega desde la solicitud hasta la orden de compra. Las demoras en esta etapa indican cuellos de botella en el traspaso de la aprobación a compras. Dónde obtenerlo Este evento se registra explícitamente. La relación entre la solicitud y la orden de compra se almacena en tablas como PO_LINE_LOCATIONS_ALL, que contiene una referencia al ID de la línea de solicitud de origen. Capturar Busque la fecha de creación de la orden de compra que hace referencia al ID de solicitud correspondiente. Tipo de evento explicit
	Solicitud aprobada	Marca la aprobación final de la solicitud de compra, una vez que ha superado correctamente todas las etapas del flujo de trabajo. Se infiere cuando el estado general de la solicitud cambia a «Approved».
Por qué es importante Este hito clave indica que la solicitud está lista para iniciar las compras. Es el punto final para medir el tiempo total del ciclo de aprobación de solicitudes. Dónde obtenerlo Se infiere cuando el campo de estado del documento en la tabla POR_REQUISITION_HEADERS_ALL cambia a «APPROVED». La fecha de este cambio de estado es la fecha y hora del evento. Capturar Identifique la fecha y hora en que el estado del documento se establece por primera vez en «Approved». Tipo de evento inferred
	Solicitud cerrada	Indica el cierre definitivo del ciclo de vida de una solicitud: todas sus líneas se han completado, por ejemplo, al convertirse en órdenes de compra, o se han cancelado. Se infiere a partir de una actualización del estado final.
Por qué es importante Este es el evento de fin principal del proceso cuando se completa correctamente. Confirma que la solicitud se ha procesado por completo y que no se requieren más acciones. Dónde obtenerlo Se infiere cuando el estado del encabezado de la solicitud en POR_REQUISITION_HEADERS_ALL cambia a «CLOSED». Capturar Identifique la fecha y hora en que el estado del documento de la solicitud cambia a «Closed». Tipo de evento inferred
	Solicitud creada	Marca el inicio del proceso de compras, cuando un usuario guarda por primera vez una solicitud de compra nueva. Normalmente, el sistema registra este evento como la creación explícita de un registro con la fecha y hora correspondientes.
Por qué es importante Este es el evento de inicio principal del proceso de solicitudes. Analizar el tiempo transcurrido entre la creación y el envío puede revelar demoras en la formalización de las solicitudes. Dónde obtenerlo Este evento se registra en la tabla POR_REQUISITION_HEADERS_ALL y se obtiene de la columna creation_date cuando se genera un nuevo ID de solicitud. Capturar Utilice la fecha y hora de creación del registro de encabezado de la solicitud. Tipo de evento explicit
	Solicitud enviada	Representa la acción del usuario de enviar la solicitud completa al flujo de aprobación. Se registra cuando el estado de la solicitud cambia de «Incomplete» o «Draft» a un estado que indica que está pendiente de aprobación.
Por qué es importante Esta actividad inicia el ciclo de aprobación. Es un hito clave para medir el tiempo del ciclo de aprobación de solicitudes y los tiempos de entrega generales. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla POR_REQUISITION_HEADERS_ALL, por ejemplo, cuando el estado pasa a «PENDING APPROVAL». A menudo, la fecha de envío también se almacena de forma explícita. Capturar Identifique la fecha y hora en que el campo de estado del documento cambia por primera vez a «Pending Approval». Tipo de evento inferred
	Solicitud rechazada	Representa el rechazo definitivo de la solicitud, que pone fin al proceso para esta petición. Se infiere cuando el estado general de la solicitud cambia a «Rejected».
Por qué es importante Esta actividad es el punto final de las solicitudes que no prosperan. Analizar estos casos es fundamental para comprender el KPI del porcentaje de solicitudes rechazadas y las causas de los fallos. Dónde obtenerlo Se infiere cuando el estado del documento en la tabla POR_REQUISITION_HEADERS_ALL cambia a «REJECTED». Capturar Identifique la fecha y hora en que el estado del documento se establece por primera vez en «Rejected». Tipo de evento inferred
	Etapa de aprobación aprobada	Representa la acción de una persona aprobadora de aprobar la solicitud en la etapa que tiene asignada dentro del flujo de trabajo. El evento queda registrado explícitamente en el historial de aprobaciones.
Por qué es importante El seguimiento de cada etapa de aprobación permite trazar la ruta real de aprobación y medir el tiempo de procesamiento en cada nivel de la jerarquía. Dónde obtenerlo Se obtiene del historial de acciones de aprobación de la solicitud, que suele almacenarse en tablas de flujo de trabajo (WF) o de Human Capital Management (HCM) que gestionan las jerarquías de aprobación. Capturar Utilice la fecha y hora de la acción «APPROVE» en el registro del historial de acciones del flujo de trabajo. Tipo de evento explicit
	Etapa de aprobación devuelta	Una persona aprobadora devuelve la solicitud a quien la preparó para que aporte información adicional o realice correcciones menores, sin rechazarla formalmente. Normalmente, se trata de una acción explícita en el sistema de flujo de trabajo.
Por qué es importante Esto indica que se necesita una aclaración y genera un ciclo de retrabajo que alarga el tiempo de ciclo. Distinguir las devoluciones de los rechazos permite comprender mejor las fricciones del proceso. Dónde obtenerlo Se obtiene del historial de acciones de aprobación de la solicitud. El sistema de flujo de trabajo registra una acción «RETURN» o similar con su fecha y hora. Capturar Utilice la fecha y hora de la acción «RETURN» o «Request for Information» en el historial del flujo de trabajo. Tipo de evento explicit
	Etapa de aprobación rechazada	Una persona aprobadora rechaza la solicitud, lo que normalmente la devuelve a quien la preparó para que la corrija o pone fin a la solicitud. Esta acción queda registrada explícitamente en el historial del flujo de trabajo.
Por qué es importante Esta actividad es una de las principales causas de retrabajo y demoras. Analizar los rechazos ayuda a identificar problemas de cumplimiento, presupuestarios o de justificación. Dónde obtenerlo Se obtiene del historial de acciones de aprobación de la solicitud. El sistema de flujo de trabajo registra una acción «REJECT» con su fecha y hora. Capturar Utilice la fecha y hora de la acción «REJECT» en el registro del historial de acciones del flujo de trabajo. Tipo de evento explicit
	Inicio de etapa de aprobación	Marca el momento en que se asigna una solicitud a una persona aprobadora o a un grupo de aprobación específico dentro del flujo de trabajo. Se obtiene del registro de transacciones del motor de flujo de trabajo.
Por qué es importante Esta actividad es fundamental para calcular el tiempo de espera de cada etapa de aprobación. Ayuda a localizar cuellos de botella causados por personas aprobadoras o niveles de aprobación concretos. Dónde obtenerlo Se obtiene de las tablas de flujo de trabajo de Oracle Fusion, que registran las tareas asignadas a los usuarios. Se utiliza la fecha y hora de asignación de la tarea de aprobación. Capturar Utilice la fecha y hora de creación de la tarea en el historial del flujo de trabajo de la solicitud correspondiente. Tipo de evento explicit
	Solicitud modificada	Este evento indica que un usuario modificó una solicitud después de enviarla por primera vez, lo que a menudo obliga a reiniciar el proceso de aprobación. Se infiere al detectar cambios en campos de datos clave o la creación de una nueva versión de la solicitud.
Por qué es importante Las modificaciones frecuentes indican problemas con la calidad de los datos o cambios en los requisitos, y generan retrabajo y demoras en el proceso. Este evento contribuye directamente al KPI «Porcentaje de solicitudes modificadas». Dónde obtenerlo Se infiere mediante el seguimiento de los números de versión de la solicitud o la detección de cambios de estado a «Incomplete» después del envío. Los registros de cambios o las tablas de auditoría también pueden recoger estas modificaciones. Capturar Identifique las fechas y horas de creación de nuevas versiones para el mismo ID de solicitud después de su envío. Tipo de evento inferred
	Solicitud retirada	Se produce cuando el solicitante cancela o retira una solicitud enviada antes de que se apruebe por completo. Normalmente, se trata de una acción explícita del usuario que cambia el estado.
Por qué es importante El seguimiento de las retiradas ayuda a identificar las causas de la finalización prematura, como cambios en las necesidades del negocio o correcciones de errores que los usuarios realizan después del envío. Dónde obtenerlo Se infiere a partir de un cambio de estado a «WITHDRAWN» en la tabla POR_REQUISITION_HEADERS_ALL. La acción queda registrada en el historial de acciones de la solicitud. Capturar Detecte la fecha y hora en que el estado de la solicitud cambia a «Withdrawn». Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Oracle Fusion Financials

Pasos

Vaya a Reports and Analytics: Inicie sesión en Oracle Fusion Financials. Abra el menú Navigator, vaya a Tools y seleccione Reports and Analytics. Este es el espacio central para las actividades de generación de informes.
Cree un análisis: En el área de trabajo Reports and Analytics, haga clic en el botón 'Create' y seleccione 'Analysis' en el menú desplegable. Se abrirá el editor de análisis de Oracle Transactional Business Intelligence (OTBI) en una pestaña nueva.
Seleccione el área temática: Se le pedirá que seleccione un área temática. Escriba 'Procurement - Requisitions Real Time' en el cuadro de búsqueda y selecciónela en la lista. Esta área temática contiene los datos necesarios sobre los eventos del ciclo de vida de las solicitudes.
Prepare el análisis de eventos de solicitud: En este paso, debe combinar varias consultas para capturar cada evento por separado. Como la interfaz de OTBI no incluye una función UNION ALL para distintos tipos de eventos, deberá crear un único informe que reúna todos los campos pertinentes de fecha y estado. En la pestaña 'Criteria', arrastre las columnas indicadas en la sección de consulta desde el panel 'Subject Areas' de la izquierda hasta el área 'Selected Columns'. Incluya, entre otras, las columnas de fecha de creación, fecha de envío, fecha de aprobación y fecha de creación de la orden de compra.
Añada el historial de acciones de la solicitud: Para capturar los pasos detallados de aprobación (Aprobado, Rechazado, Devuelto, Retirado), incluya campos de la carpeta 'Requisition Action History' del área temática. Arrastre 'Action Date', 'Action' y 'Performer' a las columnas seleccionadas.
Configure los filtros: Vaya a la pestaña 'Prompts' para crear filtros para el análisis. Es fundamental filtrar por un intervalo de fechas para controlar el volumen de datos. Cree un filtro en 'Requisition Header'.'Requisition Creation Date' y defina un intervalo, por ejemplo, los últimos 6 meses. También puede añadir filtros para 'Business Unit' o 'Requester Name' para acotar los datos.
Ejecute y revise el informe: Vaya a la pestaña 'Results' para ejecutar el análisis y obtener una vista previa de los datos. El resultado será una tabla «ancha», con una fila por línea de solicitud o acción de aprobación y varias columnas de fecha y estado.
Exporte los datos sin procesar: Cuando la vista previa sea satisfactoria, haga clic en el enlace 'Export', que suele estar al final de la página de resultados. Seleccione 'Data' > 'CSV File' como formato. Se descargarán los datos sin procesar del análisis.
Transforme los datos al formato de registro de eventos: El archivo CSV exportado tendrá un formato ancho. Utilice una herramienta externa, como un script de Python, Power Query en Excel u otra herramienta de preparación de datos, para transformarlo. El proceso consiste en convertir las columnas de fecha en una sola columna 'EventTime' y crear una columna 'ActivityName' correspondiente para cada tipo de evento, por ejemplo, 'Requisition Created' y 'Requisition Submitted'.
Finalice el archivo y prepárelo para cargarlo: Después de la transformación, compruebe que el archivo incluya las columnas necesarias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate. Guarde el registro de eventos final como archivo CSV para cargarlo en ProcessMind.

Configuración

Área temática: El área temática principal es 'Procurement - Requisitions Real Time'. Contiene la información esencial sobre las cabeceras y líneas de solicitud, las distribuciones y el historial de aprobaciones.
Intervalo de fechas: Aplique siempre un filtro de fechas obligatorio para limitar el volumen de datos y mejorar el rendimiento. Un buen punto de partida es filtrar 'Requisition Header'.'Requisition Creation Date' para incluir los últimos 3 a 6 meses.
Filtros clave: Considere añadir filtros para 'Requisition Header'.'Business Unit' y 'Requisition Header'.'Requisition Status' a fin de centrarse en las unidades organizativas pertinentes y excluir estados irrelevantes, como 'Canceled', si no se necesitan para el análisis.
Selección de columnas: Seleccione cuidadosamente las columnas que añade al análisis. Incluir demasiadas, sobre todo de distintas carpetas (dimensiones), puede afectar negativamente al rendimiento. Céntrese en los campos necesarios para el registro de eventos.
Permisos: La persona que ejecute la extracción debe tener un rol con los permisos necesarios para acceder al área de trabajo Reports and Analytics y al área temática 'Procurement - Requisitions Real Time'. Normalmente, roles como 'BI Author' o 'Procurement Analyst' cuentan con estos privilegios.

Consulta de ejemplo sql

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

Pasos

Inicie sesión en Oracle Fusion Financials con un usuario que tenga privilegios de BI Author o similares.
Vaya al área de trabajo Reports and Analytics: haga clic en el icono Navigator y seleccione Tools > Reports and Analytics.
Haga clic en el botón "Browse Catalog" para abrir el catálogo de Business Intelligence Publisher.
En la interfaz de BI Publisher, haga clic en "New" y seleccione "Data Model" en el menú desplegable.
En las propiedades del modelo de datos, puede indicar un nombre y una descripción. Haga clic en el icono "+" para añadir un conjunto de datos y seleccione "SQL Query".
En el cuadro de diálogo del nuevo conjunto de datos, indique un nombre, por ejemplo, Requisition_Event_Log, seleccione la fuente de datos adecuada para sus datos financieros, como ApplicationDB_FSCM, y establezca el tipo de SQL en "Standard SQL".
Copie el script SQL completo de la sección "query" de este documento y péguelo en el área de texto SQL Query.
La consulta incluye los parámetros :p_start_date y :p_end_date. BI Publisher los reconocerá automáticamente. Si lo desea, puede definir valores predeterminados.
Guarde el modelo de datos en una carpeta adecuada del catálogo, por ejemplo, Shared Folders/Custom.
Para exportar los datos, vuelva al catálogo, haga clic en "New" y seleccione "Report". Vincule el nuevo informe al modelo de datos que acaba de crear.
Ejecute el informe e indique los parámetros de fecha de inicio y fin. Cuando aparezcan los datos, utilice la función "Export" para descargarlos como archivo CSV.
Compruebe que el archivo CSV final esté guardado con codificación UTF-8 y contenga los encabezados necesarios para cargarlo en su herramienta de Process Mining.

Configuración

Fuente de datos: La fuente de datos de BI Publisher, que suele llamarse 'ApplicationDB_FSCM' o algo similar, debe estar configurada con un usuario que tenga acceso de lectura a todas las tablas de la consulta, incluidas las de Procurement (POR, PO), Human Capital Management (PER, HR) y Financials (FUN).
Filtro por intervalo de fechas: La consulta incluye los parámetros de fecha obligatorios (:p_start_date y :p_end_date), que filtran por fecha de creación de la solicitud. Para las primeras extracciones o en sistemas grandes, es fundamental extraer los datos en lotes manejables, por ejemplo, de 3 a 6 meses, para evitar que se agote el tiempo de espera del sistema.
Filtro por unidad de negocio: La cláusula WHERE de la consulta incluye un filtro para el nombre de la unidad de negocio, dentro de una sección comentada. Se recomienda quitar los comentarios y configurar este filtro para limitar los datos a las unidades de negocio pertinentes para el análisis, lo que puede mejorar considerablemente el rendimiento.
Requisitos previos: La persona que cree y ejecute el informe necesita un rol con privilegios de BI Publisher, como 'BI Administrator Role' o 'BI Author Role'. También necesita los permisos de seguridad de datos necesarios para acceder a los datos de compras.

Consulta de ejemplo sql

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

Pasos

Requisitos previos y configuración del entorno: Compruebe que Python 3 esté instalado en su sistema. Instale la biblioteca requests necesaria con este comando en la terminal: pip install requests. También necesitará las credenciales de API (nombre de usuario y contraseña) de un usuario de Oracle Fusion con permisos suficientes para leer los datos de solicitudes de compra, además de la URL base de su instancia de Oracle Fusion.
Guarde el script de Python: Guarde el código Python completo de la sección 'query' en un archivo, por ejemplo, extract_requisitions.py.
Configure los parámetros del script: Abra el archivo del script en un editor de texto. Modifique los valores de marcador de posición al principio del archivo. Asigne a FUSION_URL, USERNAME y PASSWORD los datos de su entorno de Oracle Fusion. Ajuste START_DATE y END_DATE para definir el período de extracción.
Revise los endpoints y campos de la API: El script utiliza el recurso de la API REST purchaseRequisitions. El parámetro fields solicita únicamente los datos necesarios, incluidas colecciones anidadas como lines (para la información de las órdenes de compra) y actionHistory (para los eventos de aprobación), lo que mejora el rendimiento.
Ejecute el script: Ejecútelo desde la terminal con el comando python extract_requisitions.py. El script se autenticará en la API, comenzará a obtener los datos y mostrará el progreso en la consola, incluido el número de solicitudes procesadas.
Gestione la paginación: El script gestiona la paginación automáticamente. La API REST de Oracle Fusion devuelve los datos en bloques (páginas). El script comprueba el indicador hasMore en cada respuesta y repite las solicitudes con un valor actualizado de offset hasta recuperar todas las solicitudes del intervalo de fechas especificado.
Lógica de transformación de datos: Para cada solicitud recuperada de la API, el script genera varias filas en el registro de eventos. Crea el evento 'Solicitud creada' a partir de CreationDate, el evento 'Solicitud enviada' a partir de SubmittedDate y recorre la colección actionHistory para crear eventos detallados de cada paso de aprobación (Iniciado, Aprobado, Rechazado, Devuelto).
Deduzca los eventos de estado final: El script captura los eventos del resultado final, como 'Solicitud aprobada' y 'Solicitud rechazada', comprobando el valor final de DocumentStatus y utilizando LastUpdateDate como marca de tiempo del evento.
Genere el evento de orden de compra: El script revisa cada línea de solicitud. Si una línea tiene un valor PoHeaderId, significa que se creó una orden de compra. Se genera una entrada en el registro de eventos para esta actividad, que vincula la solicitud con el proceso de compras posterior.
Revise el archivo de salida: Al finalizar, el script creará un archivo CSV llamado oracle_fusion_requisitions_event_log.csv en el mismo directorio. Este archivo contiene el registro de eventos extraído.
Prepare el archivo para cargarlo: Abra el archivo CSV generado en una hoja de cálculo para verificar su contenido. Compruebe que las columnas y los formatos de datos cumplan los requisitos de su herramienta de Process Mining. El archivo ya está listo para cargarse en ProcessMind.

Configuración

Credenciales de API: Se requiere una cuenta de integración específica con un rol que conceda acceso de solo lectura a la API REST de solicitudes de compra. Algunos ejemplos de roles son Procurement Manager o un rol de integración personalizado.
Endpoint de la API REST: El script está configurado para utilizar el endpoint .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Compruebe que el número de versión de la URL coincida con su entorno de Oracle Fusion.
Filtro por intervalo de fechas: El script incluye las variables START_DATE y END_DATE. Se recomienda extraer los datos en lotes manejables, por ejemplo, de 3 a 6 meses, para evitar que se agote el tiempo de espera de la API y otros problemas de rendimiento. El filtro se aplica a CreationDate de las solicitudes.
Selección de campos: El parámetro fields del script es fundamental para el rendimiento. Limita la respuesta a los atributos necesarios para el registro de eventos, lo que reduce el tráfico de red y el tiempo de procesamiento. No elimine campos obligatorios como RequisitionId, CreationDate, actionHistory o lines.
Límite de paginación: El parámetro limit está establecido en 100, un valor seguro para la mayoría de los entornos. Puede probar con 200 o 500 para acelerar potencialmente la extracción, pero tenga en cuenta que un valor demasiado alto puede causar problemas de memoria o alcanzar los límites de la API.

Consulta de ejemplo python

import requests
import csv
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

if __name__ == class="hl-string">"__main__":
    get_requisitions_data()

Pasos

Confirme que Oracle BI Cloud Connector, el contenido de compras necesario de Oracle Fusion Financials y el acceso a las vistas públicas pertinentes estén disponibles en su entorno. Compruebe que el usuario de BICC o la cuenta de integración tenga autorización para extraer datos de solicitudes, historial de aprobaciones y órdenes de compra. Los nombres exactos de los roles y las etiquetas de navegación varían según la versión de Oracle; utilice el área de administración de BICC correspondiente a su inquilino.
Identifique y habilite los PVO necesarios para la extracción. Utilice RequisitionHeaderPVO, o el PVO de cabecera de solicitud correspondiente en su entorno, junto con los PVO que exponen las líneas de solicitud, el historial de estados, el historial del flujo de trabajo de aprobación y las referencias a órdenes de compra. No dé por sentado que un único PVO contiene el historial del flujo de trabajo o el historial de creación de órdenes de compra. Registre los nombres exactos de los PVO y los atributos disponibles en su inquilino.
Configure un trabajo de BICC para una extracción masiva incremental o histórica. Defina el período de extracción con [Start date parameter] y [End date parameter], y configure el trabajo para que entregue archivos CSV en la ubicación de almacenamiento en la nube aprobada. Para la carga inicial, utilice un intervalo histórico suficientemente amplio. En las cargas recurrentes, use períodos superpuestos para tener en cuenta las actualizaciones tardías y, después, elimine los duplicados de eventos mediante el identificador del caso, la actividad, la marca de tiempo del evento y el identificador del evento de origen, cuando esté disponible.
Configure las columnas de extracción. Incluya el identificador de la solicitud, los identificadores de cabecera y línea, la persona solicitante, el departamento, el importe, el estado, la fecha requerida, la unidad de negocio, el motivo del rechazo, las marcas de tiempo de creación y actualización, las marcas de tiempo de los cambios de estado, las marcas de tiempo de asignación y acción de aprobación, la acción de aprobación, la referencia a la orden de compra y la marca de tiempo de actualización de BICC. Utilice los nombres exactos de los atributos que exponen los PVO seleccionados. Si un atributo no está disponible, asígnele [Configure based on your system] y documente la limitación en lugar de sustituirlo por un campo cuya validez no se haya comprobado.
Extraiga los archivos CSV de origen y conserve los originales. Cargue cada archivo en un área de preparación, mantenga el nombre del PVO de origen y el nombre del archivo, normalice las marcas de tiempo a una zona horaria acordada y analice de forma coherente los valores de fecha y hora de Oracle. Trate los identificadores como cadenas para evitar perder ceros iniciales o precisión.
Reestructure los datos de origen en una tabla de eventos con una fila por cada evento de negocio explícito. El resultado debe incluir PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate. Añada los atributos recomendados cuando estén disponibles. No dependa de ProcessMind para deducir eventos a partir de cambios de estado o de campos. La transformación debe crear explícitamente filas para las doce actividades indicadas en la consulta.
Genere las filas de eventos a partir de las evidencias de origen adecuadas. Utilice la evidencia de creación del registro para Solicitud creada, una transición explícita de envío para Solicitud enviada, una acción o transición explícita de retirada para Solicitud retirada, una modificación detectada después del envío o una nueva versión para Solicitud modificada, la asignación del flujo de trabajo para Paso de aprobación iniciado y las acciones explícitas del historial de aprobaciones para Paso de aprobación aprobado, Paso de aprobación rechazado y Paso de aprobación devuelto. Utilice una transición explícita del estado general para Solicitud aprobada, Solicitud rechazada y Solicitud cerrada. Para Orden de compra creada, utilice un registro explícito de creación de orden de compra o una marca de tiempo de creación vinculada a la solicitud.
Aplique una deduplicación determinista. Si varias filas de origen representan el mismo evento, conserve una sola utilizando la marca de tiempo del evento más específica y un identificador de origen estable, cuando esté disponible. No combine pasos de aprobación distintos solo porque compartan el identificador de solicitud. Conserve los eventos de aprobación por separado cuando correspondan a diferentes personas aprobadoras o pasos del flujo de trabajo.
Valide el registro de eventos resultante. Confirme que estén representadas todas las actividades obligatorias, que cada evento tenga un identificador de caso y una marca de tiempo, que las marcas de tiempo estén dentro del período de extracción o que las actualizaciones tardías estén justificadas, y que los atributos recomendados estén completos cuando los proporcione el origen. Concilie el número de solicitudes y los vínculos con órdenes de compra con las extracciones de origen.
Exporte el registro de eventos final como CSV UTF-8, con una fila de encabezado y un evento por fila. Utilice exactamente los nombres de columna PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate, además de los atributos recomendados. Cargue el CSV en ProcessMind y configure PurchaseRequisitionId como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento.

Configuración

Método de extracción: extracción masiva de datos con Oracle BI Cloud Connector, entregada como archivos CSV en la ubicación de almacenamiento en la nube configurada.
Objetos de origen: utilice RequisitionHeaderPVO y los PVO correspondientes de líneas de solicitud, historial de estados, historial del flujo de trabajo de aprobación y referencias a órdenes de compra disponibles en el inquilino. Confirme en el entorno los nombres exactos de los PVO y sus atributos.
Columnas obligatorias de salida: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate.
Columnas recomendadas de salida: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason y BusinessUnit.
Intervalo de fechas: utilice de tres a seis meses para el análisis habitual. Si es necesario, use un período histórico más amplio para la carga inicial. En las extracciones recurrentes, utilice períodos superpuestos para capturar las actualizaciones tardías y elimine después los duplicados.
Filtros: aplique [Company-specific filter], [Document Type filter], [Business Unit filter] y [Date range filter] solo si estos atributos están disponibles en los PVO seleccionados. Confirme si el filtro se aplica a la fecha de creación, la fecha de actualización, la fecha de cambio de estado u otra fecha de origen.
Extracción incremental: priorice una marca de tiempo de actualización o un mecanismo de extracción incremental compatible que exponga BICC. Conserve la marca de agua de la última extracción correcta e incluya un pequeño período superpuesto en la siguiente ejecución.
Integridad de los eventos: configure extracciones de origen independientes cuando las cabeceras de solicitud no expongan el historial de aprobaciones, los cambios de estado, las modificaciones o la creación de órdenes de compra. Una extracción de cabeceras con el estado actual no permite reconstruir de forma fiable los eventos históricos.
Rendimiento: limite el intervalo de fechas y las columnas seleccionadas, divida las extracciones grandes en particiones cuando sea posible, evite atributos descriptivos innecesarios y procese los archivos CSV por lotes. Conserve los archivos de origen para poder conciliarlos.
Almacenamiento: configure una ubicación de almacenamiento en la nube aprobada con capacidad, retención, cifrado y controles de acceso suficientes. Compruebe que la cuenta de extracción pueda escribir archivos y que el proceso de transformación pueda leerlos.
Requisitos previos: disponibilidad de BICC, acceso a los datos de compras y aprobaciones pertinentes de Oracle Fusion, autorizaciones de integración adecuadas, acceso a los PVO seleccionados y cualquier suscripción o derecho de uso de Oracle necesario. Los nombres exactos de los roles, las licencias y las rutas de navegación dependen de la versión de Oracle y de la configuración del inquilino.
Gestión de fechas y horas: normalice todas las marcas de tiempo de origen a una zona horaria documentada y conserve la marca de tiempo original cuando sea necesario para la auditabilidad.
Gestión de casos: utilice PurchaseRequisitionId como identificador del caso. No utilice el identificador de línea de solicitud como identificador del caso, salvo que el proceso se modele intencionadamente a nivel de línea.

Consulta de ejemplo sql

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

¿Listo para comenzar?

Utilice este Template para empezar a optimizar el proceso de solicitudes de compra a pago y lograr una mayor eficiencia. Prepárese para transformar sus operaciones de compras.

Volver a la guía de mejora

Descargar Template

Procese las solicitudes de compra a pago un 30 % más rápido

Agilice las solicitudes P2P de Oracle y reduzca el tiempo de ciclo un 30 %.

Iniciar la prueba gratuita

No se requiere tarjeta de crédito. La configuración toma solo unos minutos.

Su Template de datos para solicitudes de compra a pago

Su Template de datos para solicitudes de compra a pago

Atributos de las solicitudes de compra a pago

Actividades de las solicitudes de compra a pago

Guías de extracción

Exportación de Oracle Transactional Business Intelligence (OTBI)

Pasos

Configuración

Consulta de ejemplo sql

Extracción de datos mediante un modelo SQL de Oracle BI Publisher

Pasos

Configuración

Consulta de ejemplo sql

Script de Python mediante la API REST de Oracle Fusion

Pasos

Configuración

Consulta de ejemplo python

Extracción masiva de datos con Oracle BI Cloud Connector (BICC)

Pasos

Configuración

Consulta de ejemplo sql

¿Listo para comenzar?

Procese las solicitudes de compra a pago un 30 % más rápido