> Mejora continua de procesos > Purchase to Pay Requisition > Oracle Fusion Financials > Template de datos

Su Template de datos de Purchase to Pay - Requisition

Oracle Fusion Financials

Purchase to Pay - Requisition: Atributos (22) Purchase to Pay - Requisition: actividades (12) Guías de extracción (4)

Su Template de datos de Purchase to Pay - Requisition

Esta plantilla ofrece una hoja de ruta clara para recopilar los datos esenciales necesarios para analizar su proceso Purchase to Pay - Requisition. Describe los atributos clave que debe recopilar, las actividades críticas que debe supervisar y recomendaciones prácticas para extraer esta información de Oracle Fusion Financials. De este modo, podrá preparar eficazmente su Registro de eventos para realizar un Process Mining con información útil.

Atributos recomendados para recopilar
Actividades clave que debe supervisar
Guía de extracción para Oracle Fusion Financials

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

Descargar Template

Purchase to Pay - Requisition: Atributos

Estos son los campos de datos recomendados para incluir en su registro de eventos y realizar un análisis completo de Purchase to Pay - Requisition.

5 Obligatorio 7 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento de negocio que tuvo lugar en un momento específico del proceso de requisición.
Descripción La actividad representa un paso o hito concreto del ciclo de vida de una requisición de compra. Algunos ejemplos son «Requisition Created», «Approval Step Approved» o «Purchase Order Created». Estas actividades se derivan de cambios de estado, acciones de personas usuarias o eventos del sistema registrados en los registros de auditoría o las tablas de transacciones del sistema de origen. Este atributo es esencial para construir el mapa de procesos, que representa visualmente el flujo de las requisiciones. El análisis de la secuencia y la frecuencia de las actividades ayuda a identificar rutas habituales, cuellos de botella, ciclos de retrabajo y desviaciones del procedimiento estándar. Por qué es importante Constituye la base del mapa de procesos y permite visualizar y analizar el Workflow de requisiciones. Dónde obtenerlo Se deriva de los registros de cambios de estado de tablas como POR_REQUISITION_HEADERS_ALL, del historial de transacciones o de registros de auditoría del Workflow como FA_FUSION_SOAINFRA.WFTASK. Ejemplos Solicitud creadaPaso de aprobación aprobadoRequisición 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 hora exactas en que tuvo lugar una actividad específica. Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos dentro de un caso y procede de fechas de creación, fechas de última actualización o marcas de tiempo de acciones específicas del sistema. En el 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 fundamental para identificar cuellos de botella, medir el rendimiento frente a los SLA y comprender la dinámica temporal del proceso de requisición. 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 y los cuellos de botella del proceso. Dónde obtenerlo Normalmente procede de una columna «LAST_UPDATE_DATE» o «CREATION_DATE» asociada a la transacción o al cambio de estado, que suele encontrarse en tablas como POR_REQUISITION_HEADERS_ALL o en tablas del historial del Workflow. Ejemplos 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID de requisición de compra PurchaseRequisitionId	Identificador único de una requisición de compra, que actúa como ID de caso del proceso.
Descripción El ID de requisición de compra es el identificador central que vincula todas las actividades relacionadas con una solicitud específica de bienes o servicios. A cada requisición se le asigna un ID único al crearla, que permanece constante durante todo su ciclo de vida. En Process Mining, este atributo se utiliza para agrupar todos los eventos relacionados, como la creación, el envío, los pasos de aprobación y el cierre final, en un único caso. Esto permite analizar de principio a fin el recorrido de la requisición, visualizar mapas de procesos, calcular tiempos de ciclo y analizar las variantes de cada solicitud individual. Por qué es importante Es el atributo fundamental para realizar el seguimiento del ciclo de vida de una requisición de principio a fin, y permite todos los análisis a nivel de caso y los cálculos de KPI. Dónde obtenerlo Normalmente es la clave primaria de la tabla de cabecera de requisiciones, como 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, será siempre «Oracle Fusion Financials». En entornos con varios ERP o sistemas integrados, este campo es fundamental para el linaje de datos, la resolución de problemas y la garantía de la calidad de los datos. 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 para integrar datos de varios sistemas. Dónde obtenerlo Es un valor estático que se añade durante el proceso de extracción y transformación de datos para etiquetar el origen del conjunto de datos. Ejemplos Oracle Fusion Financials
	Última actualización de 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 hora en que los datos se extrajeron por última vez de Oracle Fusion Financials. Se aplica al conjunto de datos completo, no a eventos individuales. Las personas analistas utilizan esta información para conocer la actualidad de los datos y confirmar cuándo se incluyeron las transacciones más recientes. Es un elemento clave de metadatos para los informes del Dashboard y para garantizar que los análisis se basen en información actualizada. Por qué es importante Informa sobre la actualidad de los datos y garantiza que los análisis sean pertinentes y se basen en la información disponible más reciente. Dónde obtenerlo Esta marca de tiempo se genera y almacena durante el proceso de 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 la persona solicitante.
Descripción Este atributo indica la unidad organizativa de la persona que creó la requisición, como «Finanzas», «TI» o «Marketing». Normalmente se deriva del perfil de la persona solicitante en el sistema de RR. HH. El análisis por departamento es una forma habitual y eficaz de segmentar los datos del proceso. Ayuda a identificar comportamientos específicos de cada departamento, como tasas de rechazo más elevadas o tiempos de ciclo más largos, que pueden orientar iniciativas de mejora específicas. Es una dimensión clave del Dashboard «Métricas de rendimiento de las personas solicitantes». Por qué es importante Permite analizar el proceso por unidad de negocio y revelar patrones, rendimiento y problemas de cumplimiento específicos de cada departamento. Dónde obtenerlo Normalmente se deriva del perfil de la persona solicitante y suele requerir una unión entre la tabla de requisiciones y una tabla de RR. HH. o de directorio de personas usuarias que contenga la información del departamento. Ejemplos Tecnologías de la informaciónFinanzasOperacionesMarketing
	Estado de la requisición RequisitionStatus	Estado actual o final de la requisición de compra.
Descripción Este atributo indica el estado general de la requisición en un momento determinado o su resultado final, como «Approved», «Rejected», «In Process» o «Closed». A menudo es la fuente de la que se derivan muchas actividades del registro de eventos. Este atributo es clave para el Dashboard «Resumen del estado de las requisiciones», ya que ofrece una instantánea de la carga de trabajo y el backlog actuales. También se utiliza para calcular KPI basados en resultados, como la tasa de rechazo de requisiciones, 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 requisiciones y se utiliza para determinar los resultados finales de los cálculos de KPI. Dónde obtenerlo Se encuentra en la tabla de cabecera de la requisición, normalmente en un campo como «DOCUMENT_STATUS» o «APPROVAL_STATUS» de POR_REQUISITION_HEADERS_ALL. Ejemplos APROBADAEN PROCESORECHAZADARETIRADA
	Fecha requerida RequiredByDate	Fecha en la que la persona solicitante necesita los bienes o servicios.
Descripción La persona solicitante especifica esta fecha para indicar el plazo 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 puede mostrar hasta qué punto el proceso de compras satisface las necesidades internas e identificar retrasos sistémicos. Por qué es importante Es fundamental para medir el rendimiento del proceso frente a los plazos internos y comprender si el proceso de compras satisface las necesidades del negocio de manera oportuna. Dónde obtenerlo Normalmente se almacena en el nivel de línea de la requisición, 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 requisición RequisitionTotalAmount	Valor monetario total de la requisición de compra.
Descripción Este atributo representa la suma del valor de todas las líneas de una requisición de compra. Es un dato fundamental para comprender la importancia financiera de cada solicitud. En Process Mining, el importe total se utiliza para numerosos análisis. Puede servir para filtrar requisiciones de alto valor, que a menudo siguen rutas de aprobación diferentes o están sujetas a un mayor nivel de revisión. 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 requisición. Por qué es importante Aporta contexto financiero, permite realizar análisis basados en el valor para priorizar mejoras del proceso y ayuda a comprender cómo influye el valor de la requisición en el comportamiento del proceso. Dónde obtenerlo Se encuentra en la cabecera de la requisición, normalmente en un campo como REQUISITION_TOTAL de POR_REQUISITION_HEADERS_ALL. También puede calcularse sumando los importes de las líneas de POR_REQUISITION_LINES_ALL. Ejemplos 550.0012500.7599.99
	Motivo del rechazo RejectionReason	Motivo proporcionado por una persona aprobadora cuando se rechaza una requisición o un paso de aprobación.
Descripción Cuando se rechaza una requisición, la persona aprobadora normalmente proporciona un motivo, ya sea seleccionándolo de una lista predefinida o introduciendo texto libre. Este atributo recoge dicha justificación. Es un atributo fundamental para el análisis de las causas raíz de los fallos del proceso. Respalda directamente el Dashboard «Tendencias de modificaciones y rechazos» al aportar el «porqué» de los rechazos. El análisis de los motivos ayuda a identificar problemas habituales, como codificación incorrecta, excesos presupuestarios o incumplimientos de políticas, que posteriormente pueden abordarse mediante formación o controles del sistema. Por qué es importante Ofrece información directa sobre las causas de los rechazos de requisiciones, permite aplicar mejoras específicas para reducir el retrabajo y aumenta la tasa de procesamiento directo. Dónde obtenerlo Se obtiene de los comentarios del Workflow o de campos específicos de códigos de motivo del rechazo en el registro de auditoría del Workflow, posiblemente en tablas relacionadas con FA_FUSION_SOAINFRA.WFTASK o con el almacenamiento de comentarios asociado. Ejemplos Cuenta de mayor incorrectaSupera el presupuesto del centro de costosProveedor no preferente seleccionadoSolicitud duplicada
	Nombre de la persona solicitante RequesterName	Nombre de la persona empleada que creó y envió la requisición de compra.
Descripción Este atributo identifica a la persona que inició la solicitud de bienes o servicios. Normalmente, esta información se captura al principio del proceso, cuando se crea la requisición. Analizar el rendimiento del proceso por persona solicitante es fundamental para el Dashboard «Métricas de rendimiento de las personas solicitantes». Ayuda a identificar qué personas usuarias o grupos pueden necesitar formación adicional al poner de relieve tasas elevadas de modificaciones o rechazos, o tiempos de ciclo prolongados asociados a sus solicitudes. Ofrece una visión del proceso centrada en las personas. Por qué es importante Permite analizar el rendimiento por persona solicitante, identificar necesidades de formación y destacar a las personas usuarias o departamentos más eficientes. Dónde obtenerlo Se obtiene de los datos de la cabecera de la requisición, normalmente mediante la unión del ID de la persona solicitante con una tabla maestra de personas empleadas o personas usuarias. Busque campos relacionados con «PREPARER_ID» en POR_REQUISITION_HEADERS_ALL y únalos con PER_ALL_PEOPLE_F. Ejemplos John SmithJane DoeEmily Jones
	Unidad de negocio BusinessUnit	Unidad de negocio específica de la organización a la que pertenece la requisición.
Descripción La unidad de negocio representa una entidad jurídica o funcional diferenciada dentro de la empresa para la que se realiza la requisición. Es una agrupación organizativa de nivel superior al departamento. El análisis por unidad de negocio permite comparar el rendimiento a alto nivel entre distintas partes de la organización. Ayuda a la dirección a comprender si las ineficiencias del proceso están localizadas o generalizadas y dónde concentrar los esfuerzos de mejora. Es una dimensión clave para filtrar prácticamente todos los Dashboards y KPI. Por qué es importante Aporta contexto organizativo de alto nivel, permite comparar el rendimiento y facilita el análisis estratégico entre distintas áreas de la empresa. Dónde obtenerlo Es un campo organizativo fundamental de Oracle Fusion, normalmente disponible en la cabecera de la requisición, 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 requisición.
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 ofrece un contexto valioso para el análisis. Puede utilizarse en filtros para aislar requisiciones de tipos de compra específicos que quizá no queden recogidos en el tipo de requisición. Por ejemplo, una persona analista podría buscar todas las requisiciones que contengan «Licencia de software» para comprender su flujo de proceso y tiempo de ciclo específicos. Por qué es importante Ofrece un contexto detallado 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 requisición, 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
	Es automatizado IsAutomated	Indicador que señala si una actividad fue ejecutada automáticamente por el sistema.
Descripción Este atributo identifica los eventos del proceso ejecutados por un usuario del sistema o un agente automatizado, en lugar de una persona. Algunos ejemplos son los cambios de estado iniciados por el sistema o los pasos de aprobación automatizados para artículos de bajo valor. Analizar este atributo ayuda a cuantificar el nivel de automatización del proceso. También permite comparar la velocidad y la eficiencia de los pasos automatizados con las de los pasos manuales, así como identificar nuevas oportunidades de 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 identificadores de usuario del sistema conocidos. Ejemplos truefalse
	Es de procesamiento directo IsStraightThrough	Indicador que señala si la solicitud de compra se aprobó sin modificaciones ni rechazos.
Descripción Este indicador calculado identifica las solicitudes de compra que han pasado del envío a la aprobación sin ciclos de retrabajo, como modificaciones o rechazos. Representa un proceso ejecutado correctamente de principio a fin para un caso individual. Este atributo sirve de base para el KPI «Straight-Through Requisition Rate». Analizar las características de las solicitudes que siguen un flujo directo, como los departamentos, solicitantes o tipos más habituales, puede revelar buenas prácticas y oportunidades de automatización. Por el contrario, analizar las solicitudes que no siguen un flujo directo ayuda a localizar los principales factores de ineficiencia. Por qué es importante Mide directamente la eficiencia del proceso y sirve de base para el KPI Straight-Through Requisition Rate, lo que ayuda a identificar los factores que generan retrabajo. Dónde obtenerlo Este atributo se calcula durante la transformación de datos. Un caso se marca como verdadero si no contiene actividades «Requisition Amended» ni «Approval Step Rejected». Ejemplos truefalse
	Está modificada IsAmendedFlag	Indicador booleano que es verdadero si la requisición se modificó al menos una vez.
Descripción Este atributo calculado indica si una solicitud de compra ha sufrido cambios después de su envío inicial. Se obtiene comprobando si existe una actividad «Requisition Amended» en el historial del caso. Este indicador simplifica el análisis y el cálculo de KPI. Se utiliza directamente para calcular el KPI «Requisition Amendment Rate» y para identificar los casos que no siguen un flujo directo. 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 modificaciones y permite comparar fácilmente las solicitudes modificadas con las no modificadas. Dónde obtenerlo Este atributo no existe en el sistema de origen, sino que se calcula durante la transformación de datos a partir de la presencia de actividades relacionadas con modificaciones en el Registro de eventos. Ejemplos truefalse
	Moneda CurrencyCode	Código de moneda del importe de la requisición, como USD o EUR.
Descripción Este atributo especifica la moneda en la que se expresa el importe total de la requisición. En organizaciones internacionales, las requisiciones pueden crearse en distintas monedas. Es esencial para interpretar y agregar correctamente los datos financieros. En cualquier análisis que incluya valores monetarios, debe utilizarse el código de moneda para garantizar que los importes se comparen correctamente, ya sea filtrando 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 trabajan con varias monedas. Dónde obtenerlo Normalmente se encuentra en la tabla de cabecera de la requisición, junto a los campos de importe, por ejemplo, en POR_REQUISITION_HEADERS_ALL. Ejemplos USDEURGBPJPY
	Nombre de la persona usuaria UserName	Nombre de la persona usuaria que realizó una actividad específica, como una aprobación o una edición.
Descripción Mientras que el nombre de la persona solicitante identifica a quien inició la solicitud, el nombre de la persona usuaria especifica quién ejecutó un evento concreto del proceso, como una aprobación o un rechazo. Esto es especialmente importante en los Workflows de aprobación de varios pasos, en los que intervienen distintas personas. Este atributo es fundamental para analizar los cuellos de botella de aprobación y medir el rendimiento de personas aprobadoras o equipos específicos. Respaldа directamente el Dashboard «Cuellos de botella del Workflow de aprobación», ya que permite analizar los tiempos de procesamiento de cada persona implicada 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 transferencia, el rendimiento de las personas aprobadoras y la asignación de recursos. Dónde obtenerlo Se obtiene de las tablas del historial del Workflow o de los registros de auditoría, como FA_FUSION_SOAINFRA.WFTASK, que registra la persona usuaria asociada a la finalización de cada tarea. Ejemplos David LeeSusan ChenMichael 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. La persona solicitante puede sugerirlo o el sistema puede determinarlo a partir de catálogos o acuerdos anteriores. El análisis por proveedor puede revelar patrones importantes de compras. Por ejemplo, puede ayudar a identificar si las requisiciones de determinados proveedores tardan más en aprobarse o presentan tasas de rechazo más elevadas. Esta información puede ser útil para la gestión de relaciones con proveedores y la estrategia de compras. Por qué es importante Permite analizar el rendimiento del proceso por proveedor, lo que puede ayudar en la estrategia de abastecimiento y la gestión de relaciones con proveedores. Dónde obtenerlo Se encuentra en la tabla de líneas de requisición, POR_REQUISITION_LINES_ALL, normalmente vinculada mediante VENDOR_ID a una tabla maestra de proveedores como POZ_SUPPLIERS. Ejemplos Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Número de orden de compra PurchaseOrderNumber	Identificador de la orden de compra creada a partir de la requisición aprobada.
Descripción Este atributo vincula una requisición de compra con la orden de compra resultante. Una vez aprobada por completo, la requisición normalmente se convierte en una o varias órdenes de compra que se envían a un proveedor. En el análisis, este ID es esencial para realizar el seguimiento del proceso posterior a la requisición. Permite calcular el KPI «Plazo desde la requisición hasta la orden de compra» y respalda el Dashboard «Tiempo de ciclo de requisición a orden de compra». También permite combinar los datos del proceso de requisición con los procesos posteriores de órdenes de compra y facturación para realizar un análisis de Purchase-to-Pay realmente integral. Por qué es importante Vincula la requisición con la orden de compra posterior, permite medir el tiempo de ciclo desde la requisición hasta la orden de compra y facilita el análisis integral del proceso. Dónde obtenerlo Esta información se almacena cuando se crea una orden de compra. Normalmente se encuentra consultando las referencias de la requisición de origen en las tablas de distribución de la orden de compra, como PO_DISTRIBUTIONS_ALL, que enlaza con la línea de requisición. Ejemplos PO-2023-5832PO-2023-5833PO-2023-5834
	Ruta del Workflow de aprobación ApprovalWorkflowPath	Secuencia predefinida de personas aprobadoras o grupos de aprobación necesaria para la requisición.
Descripción Este atributo define el proceso de aprobación estándar previsto para una requisición determinada según las políticas de la empresa, teniendo en cuenta factores como el importe, el tipo y el departamento de la requisición. Representa el modelo de proceso «to-be». La ruta del Workflow de aprobación es fundamental para el análisis de cumplimiento y conformidad. Respalda directamente el Dashboard «Análisis de cumplimiento y desviaciones» y el KPI «Índice de conformidad de requisiciones», ya que permite comparar directamente los pasos 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 y destacar las requisiciones que no cumplen las normas. 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 requisición puede ser complejo y requerir consultas a las tablas de configuración. Ejemplos Gerente > Director > Vicepresidente de FinanzasResponsable del centro de costos > Seguridad de TIGerente > Responsable del departamento
	Tipo de requisición RequisitionType	Categoría de la requisición, como una solicitud de bienes o servicios.
Descripción Este atributo clasifica la requisición según lo que se solicita. Entre los tipos habituales se incluyen bienes, servicios o gastos de capital. El tipo puede influir en el Workflow de aprobación requerido y en la estrategia de compras. En el análisis, el tipo de requisición es una dimensión eficaz para filtrar y comparar. Por ejemplo, puede analizarse si las requisiciones de servicios tienen un ciclo de aprobación más largo 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 a partir del tipo o la categoría de línea seleccionada al crear la requisición. Puede almacenarse en la tabla de líneas de requisición, POR_REQUISITION_LINES_ALL. Ejemplos BienesServiciosGasto de capital

Obligatorio Recomendado Opcional

Purchase to Pay - Requisition: actividades

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir con precisión su proceso Purchase to Pay - Requisition.

6 Recomendado 6 Opcional

	Actividad	Descripción
	Orden de compra creada	Este evento ocurre cuando una línea de requisición aprobada se utiliza para generar una orden de compra. Conecta el proceso de requisición con el proceso de compras posterior.
Por qué es importante Es un hito crítico para medir el plazo desde la requisición hasta la orden de compra. Los retrasos en este punto indican cuellos de botella en la transferencia de la aprobación a compras. Dónde obtenerlo Es un evento explícito. El vínculo entre la requisición y la orden de compra se almacena en tablas como PO_LINE_LOCATIONS_ALL, que contienen una referencia al ID de la línea de requisición de origen. Recopilar Busque la fecha de creación de la orden de compra que hace referencia al ID de requisición indicado. Tipo de evento explicit
	Requisición aprobada	Marca la aprobación final de la requisición de compra después de superar correctamente todos los pasos del Workflow. Se infiere cuando el estado general de la requisición cambia a «Approved».
Por qué es importante Es un hito clave que indica que la solicitud está lista para la acción de compras. Constituye el punto final para medir el tiempo total del ciclo de aprobación de la requisición. Dónde obtenerlo Se infiere a partir del cambio del campo de estado del documento a «APPROVED» en la tabla POR_REQUISITION_HEADERS_ALL. La fecha de este cambio de estado corresponde al momento del evento. Recopilar Identifique la marca de tiempo en la que el estado del documento se establece por primera vez en «Approved». Tipo de evento inferred
	Requisición cerrada	Indica el cierre definitivo del ciclo de vida de una requisición, lo que significa que todas sus líneas se han atendido, 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 Es el principal evento final satisfactorio del proceso. Confirma que la requisición se ha procesado por completo y que no se requiere ninguna acción adicional. Dónde obtenerlo Se infiere a partir del cambio del estado de la cabecera de la requisición a «CLOSED» en POR_REQUISITION_HEADERS_ALL. Recopilar Identifique la marca de tiempo en la que el estado del documento de la requisición cambia a «Closed». Tipo de evento inferred
	Requisición rechazada	Representa el rechazo final de la requisición, que termina el proceso de esta solicitud. Se infiere cuando el estado general de la requisición se actualiza a «Rejected».
Por qué es importante Esta actividad es el punto final de las solicitudes no satisfactorias. El análisis de estos casos es esencial para comprender el KPI de tasa de rechazo de requisiciones y las causas de los fallos. Dónde obtenerlo Se infiere a partir del cambio del estado del documento a «REJECTED» en la tabla POR_REQUISITION_HEADERS_ALL. Recopilar Identifique la marca de tiempo en la que el estado del documento se establece por primera vez en «Rejected». Tipo de evento inferred
	Solicitud creada	Marca el inicio del proceso de adquisición cuando un usuario guarda por primera vez una nueva solicitud de compra. Este evento suele capturarse como la creación explícita de un registro con su correspondiente marca de tiempo en el sistema.
Por qué es importante Este es el evento de inicio principal del proceso de solicitudes. Analizar el tiempo transcurrido desde la creación hasta el envío puede revelar retrasos en la formalización de la solicitud. Dónde obtenerlo Este evento se registra en la tabla POR_REQUISITION_HEADERS_ALL, a partir de la columna creation_date cuando se genera un nuevo identificador de Requisition. Recopilar Utilice la marca de tiempo de creación del registro de cabecera de la solicitud. Tipo de evento explicit
	Solicitud enviada	Representa la acción del usuario de enviar la solicitud completada al Workflow de aprobación. Se captura 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 activa el ciclo de aprobación. Es un hito crítico para medir el tiempo del ciclo de aprobación de la requisición y los plazos 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 cambia a «PENDING APPROVAL». La fecha de envío también suele almacenarse de forma explícita. Recopilar Identifique la marca de tiempo en la que el campo de estado del documento cambia por primera vez a «Pending Approval». Tipo de evento inferred
	Inicio del paso de aprobación	Marca el momento en que una requisición se asigna a una persona aprobadora o a un grupo de aprobación específico dentro del Workflow. Esta información se captura en el registro de transacciones del motor de Workflow.
Por qué es importante Esta actividad es fundamental para calcular el tiempo de espera de cada paso de aprobación. Ayuda a localizar cuellos de botella causados por personas aprobadoras o niveles de aprobación específicos. Dónde obtenerlo Se obtiene de las tablas de Workflow de Oracle Fusion, que registran las tareas asignadas a las personas usuarias. Se utiliza la marca de tiempo de asignación de la tarea de aprobación. Recopilar Utilice la marca de tiempo de creación de la tarea en el historial del Workflow correspondiente a la requisición. Tipo de evento explicit
	Paso de aprobación aprobado	Representa la acción de una persona aprobadora individual al aprobar la requisición en el paso que le corresponde dentro del Workflow. El evento queda registrado explícitamente en el historial de aprobaciones.
Por qué es importante El seguimiento de cada paso de aprobación ayuda a trazar la ruta de aprobación real y a medir el tiempo de procesamiento en cada nivel de la jerarquía. Dónde obtenerlo Se captura del historial de acciones de aprobación de la requisición, que normalmente se almacena en tablas de Workflow (WF) o de Human Capital Management (HCM) que gestionan las jerarquías de aprobación. Recopilar Utilice la marca de tiempo de la acción «APPROVE» en el registro del historial de acciones del Workflow. Tipo de evento explicit
	Paso de aprobación devuelto	Una persona aprobadora devuelve la requisición a quien la preparó para solicitar información adicional o correcciones menores, sin rechazarla formalmente. Normalmente, se trata de una acción explícita en el sistema de Workflow.
Por qué es importante Esto indica que se necesita una aclaración y crea un ciclo de retrabajo que prolonga el tiempo del ciclo. Diferenciar las devoluciones de los rechazos ofrece una visión más profunda de las fricciones del proceso. Dónde obtenerlo Se captura del historial de acciones de aprobación de la requisición. El sistema de Workflow registra una acción «RETURN» o similar con su marca de tiempo. Recopilar Utilice la marca de tiempo de la acción «RETURN» o «Request for Information» en el historial del Workflow. Tipo de evento explicit
	Paso de aprobación rechazado	Una persona aprobadora rechaza la requisición, lo que normalmente la devuelve a quien la preparó para que la corrija o termina la solicitud. Esta acción queda registrada explícitamente en el historial del Workflow.
Por qué es importante Esta actividad es una de las principales causas de retrabajo y retrasos. El análisis de los rechazos ayuda a identificar problemas de cumplimiento, dificultades presupuestarias o justificaciones poco claras. Dónde obtenerlo Se captura del historial de acciones de aprobación de la requisición. El sistema de Workflow registra una acción «REJECT» con su marca de tiempo. Recopilar Utilice la marca de tiempo de la acción «REJECT» en el registro del historial de acciones del Workflow. Tipo de evento explicit
	Requisición modificada	Este evento indica que una persona usuaria ha modificado una requisición después de su envío inicial, lo que a menudo exige 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 requisición.
Por qué es importante Las modificaciones frecuentes indican problemas de calidad de datos o cambios en los requisitos, lo que provoca retrabajo y retrasos en el proceso. Esto respalda directamente el KPI «Tasa de modificación de requisiciones». Dónde obtenerlo Se infiere mediante el seguimiento de los números de versión de la requisición o la identificació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. Recopilar Identifique las marcas de tiempo de creación de nuevas versiones para el mismo ID de requisición después de su envío. Tipo de evento inferred
	Requisición retirada	Ocurre cuando la persona solicitante cancela o retira una requisición enviada antes de que se apruebe por completo. Normalmente, se trata de una acción explícita de la persona usuaria que provoca un cambio de estado.
Por qué es importante El seguimiento de las retiradas ayuda a identificar las causas de la terminación prematura, como cambios en las necesidades del negocio o la corrección de errores 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 requisición. Recopilar Detecte la marca de tiempo en la que el estado de la requisición se actualiza 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. Utilice el menú Navigator para ir a Tools y seleccione Reports and Analytics. Este es el centro de todas las actividades de generación de informes.
Cree un análisis nuevo: 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: El sistema le pedirá que seleccione un Subject Area. En el cuadro de búsqueda, escriba «Procurement - Requisitions Real Time» y selecciónelo en la lista. Esta área temática contiene todos los datos necesarios sobre los eventos del ciclo de vida de las solicitudes.
Cree el análisis de eventos de solicitudes: En este paso debe crear una unión de varias consultas para capturar cada evento distinto. Como la interfaz de OTBI no dispone de una función UNION ALL directa para distintos tipos de eventos, deberá crear un único informe que extraiga todos los campos relevantes 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 PO.
Añada el historial de acciones de la solicitud: Para capturar los pasos de aprobación detallados, como Approved, Rejected, Returned y Withdrawn, incluya los campos de la carpeta «Requisition Action History» dentro del área temática. Arrastre «Action Date», «Action» y «Performer» hasta las columnas seleccionadas.
Configure los filtros: Cambie a la pestaña «Prompts» para crear filtros para el análisis. Es esencial 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 indicadores para «Business Unit» o «Requester Name» con el fin de acotar los datos.
Ejecute y revise el informe: Vaya a la pestaña «Results» para ejecutar el análisis y previsualizar 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 esté satisfecho con la vista previa, haga clic en el enlace «Export», normalmente situado en la parte inferior de la página de resultados. Seleccione «Data» > «CSV File» como formato. Esto descargará los datos sin procesar del análisis.
Transforme los datos al formato de Registro de eventos: El CSV exportado tendrá un formato ancho. Deberá utilizar 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, como «Requisition Created» y «Requisition Submitted».
Finalice y prepare la carga: Después de la transformación, compruebe que el archivo contiene las columnas obligatorias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate. Guarde el Registro de eventos final como archivo CSV para cargarlo posteriormente en ProcessMind.

Configuración

Subject Area: El área temática principal que debe utilizar es «Procurement - Requisitions Real Time». Contiene toda la información principal de la cabecera y las líneas de la 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 filtro en «Requisition Header».«Requisition Creation Date» para los últimos 3 a 6 meses es un buen punto de partida.
Filtros clave: Considere añadir filtros para «Requisition Header».«Business Unit» y «Requisition Header».«Requisition Status» con el fin de centrar la extracción en las unidades organizativas relevantes y excluir estados innecesarios, como «Canceled», si no se requieren para el análisis.
Selección de columnas: Seleccione cuidadosamente las columnas que añade al análisis. Incluir demasiadas columnas, especialmente de muchas carpetas o dimensiones distintas, puede perjudicar el rendimiento. Céntrese únicamente 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.

a 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 haciendo clic en el icono Navigator y seleccionando 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 la lista 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 nuevo Data Set y seleccione «SQL Query».
En el cuadro de diálogo del nuevo Data Set, indique un nombre, por ejemplo, Requisition_Event_Log, seleccione el Data Source adecuado para sus datos de Financials, por ejemplo, ApplicationDB_FSCM, y establezca el tipo de SQL como «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 establecer valores predeterminados.
Guarde el Data Model 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 este nuevo informe al Data Model que acaba de crear.
Ejecute el informe e indique los parámetros de fecha inicial y final. Cuando el informe muestre los datos, utilice la función «Export» para descargar los resultados como archivo CSV.
Compruebe que el archivo CSV final se guarda con codificación UTF-8 y contiene las cabeceras necesarias para incorporarlo a su herramienta de Process Mining.

Configuración

Fuente de datos: La fuente de datos de BI Publisher, normalmente denominada «ApplicationDB_FSCM» o similar, debe configurarse 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).
Filtrado por intervalo de fechas: La consulta utiliza los parámetros de fecha obligatorios (:p_start_date y :p_end_date) para filtrar por la fecha de creación de la solicitud. En las extracciones iniciales o en sistemas grandes, es fundamental extraer los datos en lotes manejables, por ejemplo, de 3 a 6 meses cada vez, para evitar tiempos de espera del sistema.
Filtrado por unidad de negocio: La cláusula WHERE de la consulta incluye, en una sección comentada, un filtro para el nombre de la unidad de negocio. Se recomienda encarecidamente quitar los comentarios y configurar este filtro para limitar los datos a las unidades de negocio relevantes para el análisis, lo que puede mejorar significativamente 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». Además, debe contar con las concesiones de seguridad de datos necesarias para acceder a los datos de compras.

a 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: Asegúrese de tener Python 3 instalado en su sistema. Instale la biblioteca requests necesaria ejecutando el siguiente comando en el terminal: pip install requests. También necesitará las credenciales de la API, es decir, nombre de usuario y contraseña, de un usuario de Oracle Fusion con permisos suficientes para leer 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 proporcionado en la sección «query» como 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 situados al principio del script. Establezca FUSION_URL, USERNAME y PASSWORD según los datos de su entorno de Oracle Fusion. Ajuste START_DATE y END_DATE para definir el periodo de extracción.
Comprenda los endpoints y campos de la API: El script utiliza el recurso de la API REST purchaseRequisitions. Usa el parámetro fields para solicitar únicamente los datos necesarios, incluidas colecciones anidadas como lines, para obtener información de las PO, y actionHistory, para obtener eventos de aprobación, lo que mejora el rendimiento.
Ejecute el script: Ejecute el script desde el terminal con el comando python extract_requisitions.py. El script se autenticará en la API, comenzará a obtener datos y mostrará actualizaciones de progreso en la consola, incluido el número de solicitudes procesadas.
Gestione la paginación: El script gestiona automáticamente la paginación. La API REST de Oracle Fusion devuelve los datos en bloques o páginas. El script comprueba el indicador hasMore en cada respuesta y repite las solicitudes con un parámetro offset actualizado 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 un evento «Requisition Created» a partir de CreationDate, un evento «Requisition Submitted» a partir de SubmittedDate y recorre la colección actionHistory para crear eventos detallados de cada paso de aprobación: Started, Approved, Rejected y Returned.
Infiera los eventos del estado final: El script captura eventos de resultado final, como «Requisition Approved» y «Requisition Rejected», comprobando el DocumentStatus final de la solicitud y utilizando LastUpdateDate como marca de tiempo del evento.
Genere el evento de orden de compra: El script examina cada línea de la solicitud. Si una línea contiene un PoHeaderId, significa que se creó una orden de compra. Se genera una entrada en el Registro de eventos para esta actividad, vinculando la solicitud con el proceso de compras posterior.
Revise el archivo de salida: Cuando finalice el script, creará un archivo CSV denominado oracle_fusion_requisitions_event_log.csv en el mismo directorio. Este archivo contiene el Registro de eventos extraído.
Prepare la carga: Abra el archivo CSV generado en un programa de hojas de cálculo para verificar su contenido. Compruebe que las columnas y los formatos de datos cumplen los requisitos de su herramienta de Process Mining. El archivo ya estará listo para cargarlo en ProcessMind.

Configuración

Credenciales de la API: Se necesita una cuenta de usuario de integración específica con un rol que conceda acceso de solo lectura a la API REST de Purchase Requisitions. Algunos roles de ejemplo 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. Asegúrese de que el número de versión de la URL coincide con el de su entorno de Oracle Fusion.
Filtro de intervalo de fechas: El script incluye las variables START_DATE y END_DATE. Se recomienda encarecidamente extraer los datos en lotes manejables, por ejemplo, de 3 a 6 meses cada vez, para evitar tiempos de espera y problemas de rendimiento de la API. 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 únicamente 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 a aumentarlo a 200 o 500 para acelerar potencialmente la extracción, pero tenga en cuenta los posibles problemas de memoria o los límites de la API si lo establece demasiado alto.

a 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 de Oracle Fusion Financials necesario y el acceso a los Public View Objects relevantes están disponibles en su entorno. Confirme que el usuario o la cuenta de integración de BICC tiene 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, por lo que debe utilizar el área de administración de BICC correspondiente de su tenant.
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 de la solicitud, el historial del Workflow de aprobación y las referencias de órdenes de compra. No dé por hecho que un único PVO contiene el historial del Workflow o el historial de creación de órdenes de compra. Registre los nombres exactos de los PVO y los atributos disponibles en su tenant.
Configure un trabajo de BICC para una extracción masiva incremental o histórica. Establezca la ventana de extracción con [Start date parameter] y [End date parameter], y configure el trabajo para entregar archivos CSV en la ubicación de almacenamiento en la nube aprobada. Para una carga inicial, utilice un intervalo histórico suficientemente amplio. Para las cargas recurrentes, use ventanas superpuestas para tener en cuenta las actualizaciones tardías y, después, elimine los duplicados 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 de la solicitud, el 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 transición de estado, las marcas de tiempo de asignación y acción de aprobación, la acción de aprobación, la referencia de la orden de compra y la marca de tiempo de actualización de BICC. Utilice los nombres exactos de los atributos expuestos por los PVO seleccionados. Si un atributo no está disponible, asígnelo a [Configure based on your system] y documente la limitación en lugar de sustituirlo por un campo no verificado.
Extraiga los archivos CSV de origen y conserve los archivos originales. Cargue cada archivo en un área de preparación, conserve el nombre del PVO de origen y el nombre del archivo, normalice las marcas de tiempo a una única 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 empresarial explícito. El resultado debe contener PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate. Añada los atributos recomendados cuando estén disponibles. No dependa de ProcessMind para inferir eventos a partir de cambios de estado o de campos. La transformación debe crear explícitamente filas para las doce actividades enumeradas en la consulta.
Cree las filas de eventos a partir de la evidencia de origen adecuada. Utilice la evidencia de creación del registro para Requisition Created, una transición de envío explícita para Requisition Submitted, una acción o transición de retirada explícita para Requisition Withdrawn, una modificación posterior al envío o una nueva versión detectada para Requisition Amended, la asignación del Workflow para Approval Step Started y las acciones explícitas del historial de aprobaciones para Approval Step Approved, Approval Step Rejected y Approval Step Returned. Utilice una transición explícita del estado general para Requisition Approved, Requisition Rejected y Requisition Closed. Para Purchase Order Created, utilice un registro explícito de creación de la orden de compra o una marca de tiempo de creación vinculada a la solicitud.
Aplique una eliminación de duplicados determinista. Si varias filas de origen representan el mismo evento, conserve una sola fila utilizando la marca de tiempo del evento más específica y un identificador de origen estable, cuando esté disponible. No agrupe pasos de aprobación distintos solo porque compartan el mismo identificador de solicitud. Conserve los eventos de aprobación separados correspondientes a distintos aprobadores o pasos del Workflow.
Valide el Registro de eventos resultante. Confirme que todas las actividades obligatorias están representadas, que cada evento tiene un identificador de caso y una marca de tiempo, que las marcas de tiempo se encuentran dentro de la ventana de extracción o que las actualizaciones tardías están justificadas, y que los atributos recomendados están completos cuando la fuente los proporciona. Concilie el número de solicitudes y los vínculos con las órdenes de compra con las extracciones de origen.
Exporte el Registro de eventos final como CSV UTF-8, con una fila de cabecera y un evento por fila. Utilice los nombres exactos 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 mediante 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 requisición, historial de estados, historial del Workflow de aprobación y referencias de órdenes de compra disponibles en el tenant. Los nombres exactos de los PVO y sus atributos deben confirmarse en el entorno.
Columnas de salida obligatorias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem y LastDataUpdate.
Columnas de salida recomendadas: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason y BusinessUnit.
Intervalo de fechas: utilice de tres a seis meses para el análisis habitual. Cuando sea necesario, utilice un intervalo más amplio para la carga histórica inicial. En las extracciones recurrentes, utilice ventanas de extracción superpuestas para capturar actualizaciones tardías y, después, elimine los duplicados.
Filtros: aplique [Company-specific filter], [Document Type filter], [Business Unit filter] y [Date range filter] únicamente cuando 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 transición de estado u otra fecha de origen.
Extracción incremental: priorice una marca de tiempo de actualización o el mecanismo de extracción incremental compatible que exponga BICC. Conserve la marca de agua de la última extracción correcta e incluya una pequeña superposición en la siguiente ejecución.
Integridad de los eventos: configure extracciones de origen independientes cuando las cabeceras de requisición no expongan el historial de aprobaciones, las transiciones 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, particione las extracciones grandes cuando sea posible, evite atributos descriptivos innecesarios y procese los archivos CSV por lotes. Conserve los archivos de origen para la conciliación.
Almacenamiento: configure una ubicación de almacenamiento en la nube aprobada, con capacidad, retención, cifrado y controles de acceso suficientes. Confirme 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 pertinentes de compras y aprobaciones 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 tenant.
Gestión del tiempo: 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 un identificador de línea de requisición como identificador del caso, salvo que el proceso se modele intencionadamente a nivel de línea.

a 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 esta plantilla para iniciar el camino hacia la optimización de su proceso Purchase to Pay - Requisition y desbloquear nuevas eficiencias. Prepárese para transformar sus operaciones de compras.

Volver a la guía de mejora Descargar Template

Logre un proceso Purchase to Pay - Requisition un 30 % más rápido

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

Inicie su prueba gratuita

No necesita tarjeta de crédito; la configuración tarda solo unos minutos.

Su Template de datos de Purchase to Pay - Requisition

Su Template de datos de Purchase to Pay - Requisition

Purchase to Pay - Requisition: Atributos

Purchase to Pay - Requisition: actividades

Guías de extracción

Exportación de Oracle Transactional Business Intelligence (OTBI)

Pasos

Configuración

a Consulta de ejemplo sql

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

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Oracle Fusion

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Logre un proceso Purchase to Pay - Requisition un 30 % más rápido

Su Template de datos de Purchase to Pay - Requisition

Su Template de datos de Purchase to Pay - Requisition

Purchase to Pay - Requisition: Atributos

Purchase to Pay - Requisition: actividades

Guías de extracción

Exportación de Oracle Transactional Business Intelligence (OTBI)

Pasos

Configuración

a Consulta de ejemplo sql

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

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Oracle Fusion

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Logre un proceso Purchase to Pay - Requisition un 30 % más rápido

Valoramos su privacidad