> Melhoria contínua de processos > Purchase to Pay Requisição > Oracle Fusion Financials > Template de dados

Seu Template de dados de Purchase to Pay - Requisition

Oracle Fusion Financials

Purchase to Pay - Requisição: atributos (22) Purchase to Pay - Requisição: atividades (12) Guias de extração (4)

Seu Template de dados de Purchase to Pay - Requisition

Este Template oferece um roteiro claro para coletar os dados essenciais necessários à análise do seu processo de Purchase to Pay - Requisition. Ele apresenta os principais atributos a coletar, as atividades críticas a acompanhar e orientações práticas para extrair essas informações do Oracle Fusion Financials. Com isso, você pode preparar seu Event Log de forma eficiente para obter insights de Process Mining.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações para extração no Oracle Fusion Financials

Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Baixar Template

Purchase to Pay - Requisição: atributos

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise completa do processo Purchase to Pay - Requisição.

5 Obrigatório 7 Recomendado 10 Opcional

	Nome	Descrição
	Atividade ActivityName	O nome do evento de negócio que ocorreu em um ponto específico do processo de requisição.
Descrição A atividade representa uma etapa ou um marco distinto no ciclo de vida da requisição de compra. Exemplos incluem 'Requisition Created', 'Approval Step Approved' e 'Purchase Order Created'. Essas atividades são derivadas de alterações de status, ações de usuários ou eventos do sistema registrados nos logs de auditoria ou nas tabelas de transações do sistema de origem. Esse atributo é essencial para construir o mapa de processo, que representa visualmente o fluxo das requisições. Analisar a sequência e a frequência das atividades ajuda a identificar caminhos comuns do processo, gargalos, ciclos de retrabalho e desvios do procedimento padrão. Por que isso importa Ele forma a base do mapa de processo, permitindo visualizar e analisar o Workflow da requisição. Onde obter Derivado de registros de alterações de status em tabelas como POR_REQUISITION_HEADERS_ALL, do histórico de transações ou de trilhas de auditoria do Workflow, como FA_FUSION_SOAINFRA.WFTASK. Exemplos Requisição criadaEtapa de aprovação aprovadaRequisição rejeitadaPedido de compra criado
	Horário do evento EventTime	O registro de data e hora que indica quando a atividade ocorreu.
Descrição O horário do evento registra a data e a hora exatas em que uma atividade específica ocorreu. Esse registro de data e hora é fundamental para ordenar cronologicamente os eventos dentro de um caso e é obtido a partir das datas de criação, das datas da última atualização ou dos registros de data e hora de ações específicas no sistema. Na análise, o horário do evento é usado para calcular todas as métricas baseadas em duração, como tempos de ciclo entre atividades, tempos de espera e duração total do caso. Ele é essencial para identificar gargalos, medir a performance em relação aos SLAs e entender a dinâmica temporal do processo de requisição. Por que isso importa Este atributo é essencial para calcular todos os KPIs relacionados a tempo, ordenar os eventos corretamente e analisar a performance e os gargalos do processo. Onde obter Normalmente, é obtido de uma coluna 'LAST_UPDATE_DATE' ou 'CREATION_DATE' associada à transação ou à alteração de status, geralmente encontrada em tabelas como POR_REQUISITION_HEADERS_ALL ou em tabelas de histórico do Workflow. Exemplos 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID da requisição de compra PurchaseRequisitionId	O identificador exclusivo de uma requisição de compra, usado como ID do caso no processo.
Descrição O ID da requisição de compra é o identificador central que conecta todas as atividades relacionadas a uma solicitação específica de bens ou serviços. Cada requisição recebe um ID exclusivo no momento da criação, que permanece constante durante todo o seu ciclo de vida. No Process Mining, esse atributo é usado para agrupar todos os eventos relacionados, como criação, envio, etapas de aprovação e encerramento final, em um único caso. Isso permite analisar a jornada da requisição de ponta a ponta, visualizar mapas de processo, calcular tempos de ciclo e analisar variantes de cada solicitação individual. Por que isso importa Este é o atributo fundamental para acompanhar o ciclo de vida de uma requisição do início ao fim, permitindo todas as análises no nível do caso e os cálculos de KPIs. Onde obter Normalmente, esta é a chave primária na tabela de cabeçalho da requisição, como POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID no Oracle Fusion Financials. Exemplos 100234810023491002350
	Sistema de origem SourceSystem	O sistema de informação do qual estes dados foram extraídos.
Descrição Este atributo identifica a origem dos dados do processo. Neste modelo de dados, ele será sempre 'Oracle Fusion Financials'. Em ambientes com vários ERPs ou sistemas integrados, esse campo é essencial para a linhagem dos dados, a solução de problemas e a garantia da qualidade dos dados. Ele fornece contexto sobre a fonte de verdade dos eventos do processo que estão sendo analisados. Por que isso importa Fornece um contexto essencial sobre a origem dos dados, o que é fundamental para a governança de dados e para a integração de dados de vários sistemas. Onde obter É um valor estático adicionado durante o processo de extração e transformação dos dados para identificar a origem do conjunto de dados. Exemplos Oracle Fusion Financials
	Última atualização dos dados LastDataUpdate	O registro de data e hora da atualização mais recente dos dados do sistema de origem.
Descrição Este atributo indica a data e a hora em que os dados foram extraídos pela última vez do Oracle Fusion Financials. Ele se aplica ao conjunto de dados inteiro, e não a eventos individuais. Os analistas usam essas informações para entender o nível de atualização dos dados e confirmar quando as transações mais recentes foram incluídas. Esse é um metadado importante para relatórios em Dashboard e para garantir que as análises usem informações atualizadas. Por que isso importa Informa aos usuários o quão recentes são os dados, garantindo que as análises sejam relevantes e baseadas nas informações mais recentes disponíveis. Onde obter Este registro de data e hora é gerado e armazenado durante o processo de extração dos dados, normalmente pela ferramenta de ETL ou pelo pipeline de dados. Exemplos 2023-10-27T02:00:00Z
	Data necessária RequiredByDate	A data até a qual o solicitante precisa dos bens ou serviços.
Descrição Essa data é informada pelo solicitante para indicar o prazo de recebimento dos itens solicitados. Ela funciona como uma meta de acordo de nível de serviço (SLA) interno para o processo de compras. Este atributo é a base do Dashboard 'Performance em relação à data necessária' e do KPI 'Taxa de cumprimento da data necessária'. Ao comparar essa data com a data real de criação do pedido de compra ou de recebimento dos bens, a análise pode mostrar o quanto o processo de compras atende às necessidades dos clientes internos e identificar atrasos sistêmicos. Por que isso importa É essencial para medir a performance do processo em relação aos prazos internos e entender se o processo de compras atende às necessidades do negócio no tempo esperado. Onde obter Normalmente, é armazenado no nível do item da linha da requisição, em tabelas como POR_REQUISITION_LINES_ALL, em um campo como 'NEED_BY_DATE'. Exemplos 2023-11-012023-12-152024-01-31
	Departamento DepartmentName	O departamento de negócio ao qual o solicitante pertence.
Descrição Este atributo indica a unidade organizacional da pessoa que criou a requisição, como 'Financeiro', 'TI' ou 'Marketing'. Normalmente, ele é obtido do perfil do solicitante no sistema de RH. Analisar os dados por departamento é uma forma comum e eficiente de segmentar os dados do processo. Isso ajuda a identificar comportamentos específicos de cada departamento, como taxas de rejeição mais altas ou tempos de ciclo mais longos, orientando iniciativas direcionadas de melhoria de processos. Essa é uma dimensão importante para o Dashboard 'Métricas de performance do solicitante'. Por que isso importa Permite analisar o processo segmentado por unidade de negócio, revelando padrões, performance e problemas de conformidade específicos de cada departamento. Onde obter Normalmente, é obtido do perfil do solicitante, muitas vezes exigindo uma associação entre a tabela de requisições e uma tabela de RH ou diretório de usuários que contenha informações do departamento. Exemplos Tecnologia da InformaçãoFinançasOperaçõesMarketing
	Motivo da rejeição RejectionReason	O motivo informado por um aprovador quando uma requisição ou etapa de aprovação é rejeitada.
Descrição Quando uma requisição é rejeitada, o aprovador geralmente informa um motivo, selecionando uma opção de uma lista predefinida ou inserindo um texto livre. Este atributo registra essa justificativa. É um atributo essencial para a análise da causa raiz das falhas do processo. Ele dá suporte direto ao Dashboard 'Tendências de alterações e rejeições', fornecendo o motivo por trás das rejeições. Analisar os motivos das rejeições ajuda a identificar problemas comuns, como codificação incorreta, estouros de orçamento ou violações de políticas, que podem ser tratados com treinamento ou controles no sistema. Por que isso importa Fornece um insight direto sobre os motivos das rejeições de requisições, permitindo melhorias direcionadas para reduzir o retrabalho e aumentar a taxa de processamento direto. Onde obter Obtido nos comentários do Workflow ou em campos específicos de códigos de motivo da rejeição na trilha de auditoria do Workflow, possivelmente em tabelas relacionadas a FA_FUSION_SOAINFRA.WFTASK ou ao armazenamento de comentários associado. Exemplos Conta contábil incorretaExcede o orçamento do centro de custoFornecedor não preferencial selecionadoSolicitação duplicada
	Nome do solicitante RequesterName	O nome do funcionário que criou e enviou a requisição de compra.
Descrição Este atributo identifica a pessoa que iniciou a solicitação de bens ou serviços. Normalmente, essas informações são capturadas no início do processo, quando a requisição é criada. Analisar a performance do processo por solicitante é essencial para o Dashboard 'Métricas de performance do solicitante'. Isso ajuda a identificar quais usuários ou grupos podem precisar de treinamento adicional, destacando altas taxas de alterações, rejeições ou tempos de ciclo longos associados às suas solicitações. O atributo oferece uma visão do processo centrada nas pessoas. Por que isso importa Permite analisar a performance por solicitante, ajudando a identificar necessidades de treinamento e destacar usuários ou departamentos eficientes. Onde obter Obtido nos dados do cabeçalho da requisição, geralmente associando o ID do solicitante a uma tabela mestre de funcionários ou usuários. Procure campos relacionados a 'PREPARER_ID' em POR_REQUISITION_HEADERS_ALL e faça a associação com PER_ALL_PEOPLE_F. Exemplos John SmithJane DoeEmily Jones
	Status da requisição RequisitionStatus	O status atual ou final da requisição de compra.
Descrição Este atributo indica o estado geral da requisição em um determinado momento ou seu resultado final, como 'Approved', 'Rejected', 'In Process' ou 'Closed'. Muitas atividades do Event Log são derivadas desse atributo. Ele é essencial para o Dashboard 'Visão geral do status das requisições', fornecendo um retrato da carga de trabalho e do backlog atuais. Também é usado para calcular KPIs baseados no resultado, como a taxa de rejeição de requisições, filtrando os casos que terminam com um status específico. Por que isso importa Fornece um retrato do estado atual das requisições e é usado para determinar os resultados finais nos cálculos de KPIs. Onde obter Encontrado na tabela de cabeçalho da requisição, normalmente em um campo como 'DOCUMENT_STATUS' ou 'APPROVAL_STATUS' na tabela POR_REQUISITION_HEADERS_ALL. Exemplos APROVADAEM PROCESSOREJEITADARETIRADA
	Unidade de negócio BusinessUnit	A unidade de negócio específica da organização à qual a requisição pertence.
Descrição A unidade de negócio representa uma entidade jurídica ou funcional distinta dentro da empresa para a qual a requisição está sendo feita. Ela é um agrupamento organizacional de nível mais alto do que um departamento. Analisar os dados por unidade de negócio permite comparar a performance em alto nível entre diferentes partes da organização. Isso ajuda a liderança a entender se as ineficiências do processo estão localizadas ou disseminadas e onde concentrar os esforços de melhoria. É uma dimensão importante para filtrar praticamente todos os Dashboards e KPIs. Por que isso importa Fornece um contexto organizacional de alto nível, permitindo comparar a performance e realizar análises estratégicas entre diferentes partes da empresa. Onde obter Este é um campo organizacional fundamental no Oracle Fusion, normalmente disponível no cabeçalho da requisição em tabelas como POR_REQUISITION_HEADERS_ALL. Exemplos Unidade de negócio da América do NorteUnidade de negócio da EuropaSede corporativa
	Valor total da requisição RequisitionTotalAmount	O valor monetário total da requisição de compra.
Descrição Este atributo representa a soma do valor de todos os itens de uma única requisição de compra. É um dado essencial para entender a relevância financeira de cada solicitação. No Process Mining, o valor total é usado em vários tipos de análise. Ele pode ser usado para filtrar requisições de alto valor, que geralmente seguem caminhos de aprovação diferentes ou passam por uma análise mais rigorosa. Os Dashboards podem usar esse atributo para analisar como métricas do processo, como tempo de ciclo ou taxa de rejeição, se relacionam com o valor da requisição. Por que isso importa Fornece contexto financeiro, permitindo análises baseadas em valor para priorizar melhorias no processo e entender como o valor da requisição afeta o comportamento do processo. Onde obter Localizado no cabeçalho da requisição, geralmente em um campo como REQUISITION_TOTAL na tabela POR_REQUISITION_HEADERS_ALL. Também pode ser calculado somando os valores dos itens da tabela POR_REQUISITION_LINES_ALL. Exemplos 550.0012500.7599.99
	Caminho do Workflow de aprovação ApprovalWorkflowPath	A sequência predefinida de aprovadores ou grupos de aprovação necessária para a requisição.
Descrição Este atributo define o processo de aprovação padrão esperado para uma determinada requisição com base nas políticas da empresa, considerando fatores como valor, tipo e departamento da requisição. Ele representa o modelo de processo 'to-be'. O caminho do Workflow de aprovação é fundamental para análises de conformidade e aderência. Ele dá suporte direto ao Dashboard 'Análise de conformidade e desvios' e ao KPI 'Índice de aderência da requisição', permitindo comparar diretamente as etapas reais de aprovação com o caminho prescrito. Desvios podem indicar violações de políticas ou ineficiências no processo. Por que isso importa Permite verificar a aderência comparando o fluxo real do processo com a hierarquia de aprovação necessária e destacando as requisições que não estão em conformidade. Onde obter Essas informações são configuradas no Oracle Fusion BPM Worklist ou no Approval Management Engine (AMX). Extrair o caminho definido para cada requisição pode ser complexo e exigir consultas às tabelas de configuração. Exemplos Gerente > Diretor > VP de FinançasResponsável pelo centro de custo > Segurança de TIGerente > Responsável pelo departamento
	Descrição do item ItemDescription	A descrição do produto ou serviço solicitado em uma linha da requisição.
Descrição Este atributo contém a descrição textual do item que está sendo comprado. Ele fornece detalhes específicos sobre os bens ou serviços solicitados. Embora geralmente não estruturada, a descrição do item oferece um contexto valioso para a análise. Ela pode ser usada em filtros para isolar requisições de tipos específicos de compra que talvez não sejam identificados pelo tipo de requisição. Por exemplo, um analista pode pesquisar todas as requisições que contenham 'Licença de software' para entender seu fluxo de processo e tempo de ciclo específicos. Por que isso importa Oferece um contexto detalhado sobre o que está sendo comprado, permitindo filtrar e analisar com mais granularidade bens ou serviços específicos. Onde obter Localizado na tabela de itens das linhas da requisição, POR_REQUISITION_LINES_ALL, em um campo como ITEM_DESCRIPTION. Exemplos Notebook de 15 polegadas, 16 GB de RAMServiços de consultoria - Projeto do 4º trimestreRenovação anual da manutenção de software
	É automatizado IsAutomated	Uma flag que indica se uma atividade foi executada automaticamente pelo sistema.
Descrição Este atributo identifica eventos do processo executados por um usuário de sistema ou agente automatizado, em vez de uma pessoa. Alguns exemplos são alterações de status feitas pelo sistema ou etapas de aprovação automatizadas para itens de baixo valor. Analisar este atributo ajuda a quantificar o nível de automação do processo. Ele pode ser usado para comparar a velocidade e a eficiência das etapas automatizadas com as etapas manuais e identificar oportunidades de ampliar a automação. Por que isso importa Ajuda a medir o nível de automação do processo e identificar oportunidades para automatizar tarefas manuais. Onde obter Derivado da verificação de que o usuário associado a uma atividade é uma conta de sistema ou de serviço. Isso exige uma lista de IDs de usuários de sistema conhecidos. Exemplos truefalse
	É direto, sem intervenção manual IsStraightThrough	Uma flag que indica se a requisição foi aprovada sem alterações ou rejeições.
Descrição Esta flag calculada identifica requisições que passaram pelo processo, do envio à aprovação, sem loops de retrabalho, como alterações ou rejeições. Ela representa um processo executado perfeitamente em um único caso. Este atributo é a base do KPI 'Straight-Through Requisition Rate'. Analisar as características das requisições que seguem um fluxo direto, como departamentos, solicitantes ou tipos mais comuns, pode revelar boas práticas e oportunidades de automação. Por outro lado, analisar as requisições que não seguem um fluxo direto ajuda a identificar os principais fatores de ineficiência. Por que isso importa Mede diretamente a eficiência do processo e serve de base para o KPI Straight-Through Requisition Rate, ajudando a identificar os fatores que geram retrabalho. Onde obter Este atributo é calculado durante a transformação dos dados. O caso recebe o valor true quando não há atividades 'Requisition Amended' ou 'Approval Step Rejected'. Exemplos truefalse
	Foi alterada IsAmendedFlag	Um indicador booleano que é verdadeiro quando a requisição foi alterada pelo menos uma vez.
Descrição Este atributo calculado indica se uma requisição sofreu alguma alteração após o envio inicial. Ele é derivado verificando a presença da atividade 'Requisition Amended' no histórico do caso. Essa flag simplifica a análise e o cálculo de KPIs. Ela é usada diretamente para calcular o KPI 'Requisition Amendment Rate' e identificar casos que não seguem um fluxo direto. Isso facilita a filtragem e a comparação das métricas do processo entre requisições alteradas e não alteradas. Por que isso importa Simplifica o cálculo da taxa de alterações e permite comparar facilmente requisições alteradas e não alteradas. Onde obter Este atributo não está no sistema de origem, mas é calculado durante a transformação dos dados com base na presença de atividades relacionadas a alterações no Event Log. Exemplos truefalse
	Moeda CurrencyCode	O código da moeda do valor da requisição, como USD ou EUR.
Descrição Este atributo especifica a moeda em que o valor total da requisição é expresso. Em organizações globais, as requisições podem ser criadas em várias moedas. Ele é essencial para interpretar e agregar corretamente os dados financeiros. Em qualquer análise que envolva valores monetários, o código da moeda deve ser usado para garantir que os valores sejam comparados com precisão, seja filtrando uma única moeda, seja convertendo todos os valores para uma moeda comum. Por que isso importa Garante análises e relatórios financeiros precisos, especialmente em organizações multinacionais que trabalham com várias moedas. Onde obter Normalmente, é encontrado na tabela de cabeçalho da requisição, junto aos campos de valor, por exemplo, em POR_REQUISITION_HEADERS_ALL. Exemplos USDEURGBPJPY
	Nome do fornecedor SupplierName	O nome do fornecedor sugerido ou pré-selecionado para os bens ou serviços.
Descrição Este atributo identifica o fornecedor do qual os bens ou serviços devem ser comprados. O fornecedor pode ser sugerido pelo solicitante ou determinado pelo sistema com base em catálogos ou acordos anteriores. Analisar os dados por fornecedor pode revelar padrões importantes de compras. Por exemplo, isso pode ajudar a identificar se as requisições de determinados fornecedores demoram mais para ser aprovadas ou apresentam taxas de rejeição mais altas. Essas informações podem ser valiosas para a gestão do relacionamento com fornecedores e para a estratégia de compras. Por que isso importa Permite analisar a performance do processo por fornecedor, ajudando na estratégia de fornecimento e na gestão do relacionamento com fornecedores. Onde obter Localizado na tabela de itens das linhas da requisição, POR_REQUISITION_LINES_ALL, geralmente associado por meio de VENDOR_ID a uma tabela mestre de fornecedores, como POZ_SUPPLIERS. Exemplos Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Nome do usuário UserName	O nome do usuário que realizou uma atividade específica, como um aprovador ou editor.
Descrição Enquanto o nome do solicitante identifica quem iniciou a solicitação, o nome do usuário especifica a pessoa que executou um evento específico do processo, como uma aprovação ou rejeição. Isso é especialmente importante em Workflows de aprovação com várias etapas, nos quais diferentes pessoas participam. Este atributo é essencial para analisar gargalos de aprovação e medir a performance de aprovadores ou equipes específicas. Ele dá suporte direto ao Dashboard 'Gargalos do Workflow de aprovação', permitindo analisar os tempos de processamento de cada usuário envolvido na cadeia de aprovação. Por que isso importa Identifica o responsável por cada evento, o que é essencial para analisar tempos de transferência, performance dos aprovadores e alocação de recursos. Onde obter Obtido em tabelas de histórico do Workflow ou de trilha de auditoria, como FA_FUSION_SOAINFRA.WFTASK, que registra o usuário associado à conclusão de cada tarefa. Exemplos David LeeSusan ChenMichael Brown
	Número do pedido de compra PurchaseOrderNumber	O identificador do pedido de compra criado a partir da requisição aprovada.
Descrição Este atributo conecta uma requisição de compra ao pedido de compra resultante. Depois que uma requisição é totalmente aprovada, ela normalmente é convertida em um ou mais pedidos de compra enviados a um fornecedor. Na análise, esse ID é essencial para acompanhar o processo após a requisição. Ele permite calcular o KPI 'Prazo entre requisição e pedido de compra' e dá suporte ao Dashboard 'Tempo de ciclo da requisição ao pedido de compra'. Também permite combinar os dados do processo de requisição com os processos posteriores de pedido de compra e faturamento, possibilitando uma análise de Purchase-to-Pay realmente de ponta a ponta. Por que isso importa Conecta a requisição ao pedido de compra subsequente, permitindo medir o tempo de ciclo da requisição ao pedido de compra e analisar o processo de ponta a ponta. Onde obter Essas informações são armazenadas depois que um pedido de compra é criado. Normalmente, elas são encontradas nas referências à requisição de origem nas tabelas de distribuição do pedido de compra, como PO_DISTRIBUTIONS_ALL, que faz a conexão com a linha da requisição. Exemplos PO-2023-5832PO-2023-5833PO-2023-5834
	Tipo de requisição RequisitionType	A categoria da requisição, como uma solicitação de bens ou serviços.
Descrição Este atributo classifica a requisição com base no que está sendo solicitado. Os tipos comuns incluem bens, serviços ou despesas de capital. O tipo pode influenciar o Workflow de aprovação necessário e a estratégia de compras. Na análise, o tipo de requisição funciona como uma dimensão importante para filtragem e comparação. Por exemplo, você pode analisar se as requisições de serviços têm um tempo de ciclo de aprovação maior do que as requisições de bens. Isso ajuda a entender se diferentes tipos de solicitação apresentam comportamentos ou gargalos distintos no processo. Por que isso importa Permite segmentar a análise para entender como o processo varia entre diferentes tipos de compra, como bens e serviços. Onde obter Normalmente, é determinado pelo tipo ou pela categoria do item selecionado durante a criação da requisição. Pode ser armazenado na tabela de linhas da requisição, POR_REQUISITION_LINES_ALL. Exemplos BensServiçosDespesa de capital

Obrigatório Recomendado Opcional

Purchase to Pay - Requisição: atividades

Estas são as principais etapas e marcos do processo que você deve registrar no seu Event Log para realizar uma descoberta precisa do processo Purchase to Pay - Requisição.

6 Recomendado 6 Opcional

	Atividade	Descrição
	Pedido de compra criado	Este evento ocorre quando uma linha de requisição aprovada é usada para gerar um pedido de compra. Ele conecta o processo de requisição ao processo de compras subsequente.
Por que isso importa Este é um marco crítico para medir o prazo entre a requisição e o pedido de compra. Atrasos nessa etapa indicam gargalos na transferência da aprovação para a área de compras. Onde obter Este é um evento explícito. A conexão entre a requisição e o pedido de compra é armazenada em tabelas como PO_LINE_LOCATIONS_ALL, que contêm uma referência ao ID da linha de requisição de origem. Captura Encontre a data de criação do pedido de compra que faz referência ao ID da requisição informado. Tipo de evento explicit
	Requisição aprovada	Marca a aprovação final da requisição de compra depois que ela passa com sucesso por todas as etapas do Workflow. Isso é inferido pela alteração do status geral da requisição para 'Approved'.
Por que isso importa Este é um marco importante que indica que a solicitação está pronta para a ação de compras. É o ponto final para medir o tempo total do ciclo de aprovação da requisição. Onde obter Inferido pela alteração do campo de status do documento na tabela POR_REQUISITION_HEADERS_ALL para 'APPROVED'. A data dessa alteração de status é o horário do evento. Captura Identifique o registro de data e hora em que o status do documento é definido pela primeira vez como 'Approved'. Tipo de evento inferred
	Requisição criada	Marca o início do processo de compras, quando um usuário salva uma nova requisição de compra pela primeira vez. Esse evento normalmente é registrado como uma criação explícita, com o respectivo registro de data e hora no sistema.
Por que isso importa Este é o principal evento de início do processo de requisições. Analisar o tempo entre a criação e o envio pode revelar atrasos na formalização da solicitação. Onde obter Este evento é registrado na tabela POR_REQUISITION_HEADERS_ALL, a partir da coluna creation_date, quando um novo ID de Requisition é gerado. Captura Use o registro de data e hora de criação do registro de cabeçalho da requisição. Tipo de evento explicit
	Requisição encerrada	Indica o encerramento final do ciclo de vida da requisição, o que significa que todas as suas linhas foram atendidas, por exemplo, convertidas em pedidos de compra, ou canceladas. Isso é inferido a partir de uma atualização de status final.
Por que isso importa Este é o principal evento de encerramento bem-sucedido do processo. Ele confirma que a requisição foi totalmente processada e que nenhuma ação adicional é necessária. Onde obter Inferido pela alteração do status do cabeçalho da requisição na tabela POR_REQUISITION_HEADERS_ALL para 'CLOSED'. Captura Identifique o registro de data e hora em que o status do documento da requisição muda para 'Closed'. Tipo de evento inferred
	Requisição enviada	Representa a ação do usuário de enviar a requisição preenchida para o Workflow de aprovação. Esse evento é registrado quando o status da requisição muda de 'Incomplete' ou 'Draft' para um status que indica que ela está aguardando aprovação.
Por que isso importa Esta atividade inicia o ciclo de aprovação. Ela é um marco crítico para medir o tempo do ciclo de aprovação da requisição e os prazos gerais. Onde obter Inferido a partir de uma alteração de status na tabela POR_REQUISITION_HEADERS_ALL, por exemplo, quando o status muda para 'PENDING APPROVAL'. A data de envio também costuma ser armazenada explicitamente. Captura Identifique o registro de data e hora em que o campo de status do documento muda pela primeira vez para 'Pending Approval'. Tipo de evento inferred
	Requisição rejeitada	Representa a rejeição final da requisição, encerrando o processo dessa solicitação. Isso é inferido quando o status geral da requisição é atualizado para 'Rejected'.
Por que isso importa Esta atividade é um ponto final para solicitações malsucedidas. Analisar esses casos é essencial para entender o KPI de taxa de rejeição de requisições e os motivos das falhas. Onde obter Inferido pela alteração do status do documento na tabela POR_REQUISITION_HEADERS_ALL para 'REJECTED'. Captura Identifique o registro de data e hora em que o status do documento é definido pela primeira vez como 'Rejected'. Tipo de evento inferred
	Etapa de aprovação aprovada	Representa a ação de um aprovador individual ao aprovar a requisição na etapa designada do Workflow. O evento é registrado explicitamente no histórico de aprovações.
Por que isso importa Acompanhar cada etapa de aprovação ajuda a mapear o caminho real de aprovação e medir o tempo de processamento em cada nível da hierarquia. Onde obter Capturado no histórico de ações de aprovação da requisição, normalmente armazenado em tabelas de Workflow (WF) ou de Human Capital Management (HCM) que gerenciam as hierarquias de aprovação. Captura Use o registro de data e hora da ação 'APPROVE' no log do histórico de ações do Workflow. Tipo de evento explicit
	Etapa de aprovação devolvida	Um aprovador devolve a requisição ao preparador para obter informações adicionais ou fazer pequenas correções, sem rejeitá-la formalmente. Normalmente, essa é uma ação explícita no sistema de Workflow.
Por que isso importa Isso indica a necessidade de esclarecimentos e cria um ciclo de retrabalho que aumenta o tempo do ciclo. Diferenciar devoluções de rejeições oferece um insight mais profundo sobre os pontos de atrito do processo. Onde obter Capturado no histórico de ações de aprovação da requisição. O sistema de Workflow registra uma ação 'RETURN' ou semelhante com um registro de data e hora. Captura Use o registro de data e hora da ação 'RETURN' ou 'Request for Information' no histórico do Workflow. Tipo de evento explicit
	Etapa de aprovação iniciada	Marca o momento em que uma requisição é atribuída a um aprovador específico ou a um grupo de aprovação dentro do Workflow. Essa informação é capturada no log de transações do mecanismo de Workflow.
Por que isso importa Esta atividade é essencial para calcular o tempo de espera de cada etapa de aprovação. Ela ajuda a identificar gargalos causados por aprovadores específicos ou níveis de aprovação. Onde obter Obtido das tabelas de Workflow do Oracle Fusion, que registram as tarefas atribuídas aos usuários. É usado o registro de data e hora da atribuição da tarefa de aprovação. Captura Use o registro de data e hora da criação da tarefa no histórico do Workflow para a requisição informada. Tipo de evento explicit
	Etapa de aprovação rejeitada	Um aprovador individual rejeita a requisição, o que normalmente a envia de volta ao preparador para correção ou encerra a solicitação. Essa ação é registrada explicitamente no histórico do Workflow.
Por que isso importa Esta atividade é uma das principais causas de retrabalho e atrasos. Analisar as rejeições ajuda a identificar problemas de conformidade, questões orçamentárias ou justificativas pouco claras. Onde obter Capturado no histórico de ações de aprovação da requisição. O sistema de Workflow registra uma ação 'REJECT' com um registro de data e hora. Captura Use o registro de data e hora da ação 'REJECT' no log do histórico de ações do Workflow. Tipo de evento explicit
	Requisição alterada	Este evento indica que um usuário modificou uma requisição após o envio inicial, o que geralmente exige o reinício do processo de aprovação. Isso é inferido pela detecção de alterações em campos de dados importantes ou pela criação de uma nova versão da requisição.
Por que isso importa Alterações frequentes indicam problemas na qualidade dos dados ou mudanças nos requisitos, gerando retrabalho e atrasos no processo. Isso dá suporte direto ao KPI 'Taxa de alterações de requisições'. Onde obter Inferido pelo acompanhamento dos números de versão da requisição ou pela identificação de alterações de status de volta para 'Incomplete' após o envio. Logs de alterações ou tabelas de trilha de auditoria também podem registrar essas modificações. Captura Identifique os registros de data e hora da criação de novas versões para o mesmo ID da requisição após o envio. Tipo de evento inferred
	Requisição retirada	Ocorre quando o solicitante cancela ou retira uma requisição enviada antes que ela seja totalmente aprovada. Normalmente, essa é uma ação explícita do usuário que resulta em uma alteração de status.
Por que isso importa Acompanhar as retiradas ajuda a identificar os motivos da encerramento prematuro, como mudanças nas necessidades do negócio ou correções feitas pelos usuários após o envio. Onde obter Inferido a partir de uma alteração de status para 'WITHDRAWN' na tabela POR_REQUISITION_HEADERS_ALL. A ação é registrada no histórico de ações da requisição. Captura Detecte o registro de data e hora em que o status da requisição é atualizado para 'Withdrawn'. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Oracle Fusion Financials

Etapas

Acesse Reports and Analytics: faça login no Oracle Fusion Financials. Use o menu Navigator para acessar Tools e selecione Reports and Analytics. Esse é o ponto central de todas as atividades de geração de relatórios.
Crie uma nova análise: na área de trabalho Reports and Analytics, clique no botão 'Create' e selecione 'Analysis' no menu suspenso. O editor de análise do Oracle Transactional Business Intelligence (OTBI) será aberto em uma nova aba.
Selecione a Subject Area: você deverá selecionar uma Subject Area. Na caixa de pesquisa, digite 'Procurement - Requisitions Real Time' e selecione-a na lista. Essa Subject Area contém todos os dados necessários para os eventos do ciclo de vida da requisição.
Crie a análise dos eventos da requisição: nesta etapa, você precisa criar uma união de várias consultas para capturar cada evento distinto. Como a interface do OTBI não oferece um recurso UNION ALL direto para diferentes tipos de evento, você criará um único relatório com todos os campos relevantes de data e status. Na aba 'Criteria', arraste as colunas listadas na seção de consulta do painel 'Subject Areas' à esquerda para a área 'Selected Columns'. Isso inclui colunas de data de criação, data de envio, data de aprovação, data de criação do PO, entre outras.
Adicione o histórico de ações da requisição: para capturar etapas detalhadas de aprovação, como Approved, Rejected, Returned e Withdrawn, inclua campos da pasta 'Requisition Action History' dentro da Subject Area. Arraste 'Action Date', 'Action' e 'Performer' para as colunas selecionadas.
Configure os filtros: acesse a aba 'Prompts' para criar filtros para sua análise. É essencial filtrar por um intervalo de datas para controlar o volume de dados. Crie um filtro em 'Requisition Header'.'Requisition Creation Date' e defina um intervalo, por exemplo, os últimos 6 meses. Você também pode adicionar prompts para 'Business Unit' ou 'Requester Name' para restringir os dados.
Execute e revise o relatório: acesse a aba 'Results' para executar a análise e visualizar uma prévia dos dados. O resultado será uma tabela 'ampla', com uma linha por linha de requisição ou ação de aprovação, contendo várias colunas de data e status.
Exporte os dados brutos: quando estiver satisfeito com a prévia, clique no link 'Export', normalmente localizado na parte inferior da página de resultados. Escolha 'Data' > 'CSV File' como formato. Isso fará o download dos dados brutos da sua análise.
Transforme os dados no formato de Event Log: o CSV exportado estará em formato amplo. Você deverá usar uma ferramenta externa, como um script Python, o Power Query do Excel ou outra ferramenta de preparação de dados, para transformar esses dados. O processo envolve fazer o 'unpivot' das colunas de data em uma única coluna 'EventTime' e criar uma coluna 'ActivityName' correspondente para cada tipo de evento, como 'Requisition Created' e 'Requisition Submitted'.
Finalize e prepare para o upload: após a transformação, confirme se o arquivo contém as colunas obrigatórias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Salve o Event Log final como um arquivo CSV para fazer o upload no ProcessMind.

Configuração

Subject Area: a principal Subject Area a ser usada é 'Procurement - Requisitions Real Time'. Ela contém todas as informações essenciais do cabeçalho e das linhas da requisição, além da distribuição e do histórico de aprovações.
Intervalo de datas: sempre aplique um filtro de data obrigatório para limitar o volume de dados e melhorar a performance. Um filtro em 'Requisition Header'.'Requisition Creation Date' para os últimos 3 a 6 meses é um bom ponto de partida.
Principais filtros: considere adicionar filtros para 'Requisition Header'.'Business Unit' e 'Requisition Header'.'Requisition Status' para concentrar a extração nas unidades organizacionais relevantes e excluir status que não interessam, como 'Canceled', caso não sejam necessários para a análise.
Seleção de colunas: seja seletivo com as colunas adicionadas à análise. Incluir colunas demais, especialmente de muitas pastas diferentes, ou dimensões, pode prejudicar a performance. Concentre-se apenas nos campos necessários para o Event Log.
Permissões: o usuário que executar a extração deve ter uma função com as permissões necessárias para acessar a área de trabalho Reports and Analytics e a Subject Area 'Procurement - Requisitions Real Time'. Normalmente, funções como 'BI Author' ou 'Procurement Analyst' têm esses privilégios.

a Consulta de exemplo 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'

Etapas

Faça login no Oracle Fusion Financials com um usuário que tenha privilégios de BI Author ou semelhantes.
Acesse a área de trabalho Reports and Analytics clicando no ícone Navigator e selecionando Tools > Reports and Analytics.
Clique no botão "Browse Catalog" para abrir o catálogo do Business Intelligence Publisher.
Na interface do BI Publisher, clique em "New" e selecione "Data Model" no menu suspenso.
Nas propriedades do Data Model, informe um nome e uma descrição. Clique no ícone "+" para adicionar um novo Data Set e selecione "SQL Query".
Na caixa de diálogo do novo Data Set, informe um nome, como Requisition_Event_Log, selecione a Data Source adequada para seus dados do Financials, como ApplicationDB_FSCM, e defina o tipo de SQL como "Standard SQL".
Copie o script SQL completo da seção "query" deste documento e cole-o na área de texto SQL Query.
A consulta inclui os parâmetros :p_start_date e :p_end_date. Eles serão reconhecidos automaticamente pelo BI Publisher. Você pode definir valores padrão, se desejar.
Salve o Data Model em uma pasta adequada do catálogo, como Shared Folders/Custom.
Para exportar os dados, volte ao catálogo, clique em "New" e selecione "Report". Vincule esse novo relatório ao Data Model que você acabou de criar.
Execute o relatório informando os parâmetros de data inicial e final. Quando o relatório exibir os dados, use a funcionalidade "Export" para baixar os resultados como um arquivo CSV.
Confirme se o arquivo CSV final está salvo com codificação UTF-8 e contém os cabeçalhos necessários para a ingestão na sua ferramenta de Process Mining.

Configuração

Fonte de dados: a fonte de dados do BI Publisher, normalmente chamada 'ApplicationDB_FSCM' ou algo semelhante, deve ser configurada com um usuário que tenha acesso de leitura a todas as tabelas usadas na query, incluindo as tabelas de Procurement (POR, PO), Human Capital Management (PER, HR) e Financials (FUN).
Filtragem por período: a query foi desenvolvida com parâmetros obrigatórios de data (:p_start_date e :p_end_date) que filtram pela data de criação da requisição. Para extrações iniciais ou sistemas grandes, é fundamental extrair os dados em lotes gerenciáveis, por exemplo, de 3 a 6 meses por vez, para evitar timeouts do sistema.
Filtragem por unidade de negócio: há um filtro pelo nome da unidade de negócio em uma seção comentada da cláusula WHERE da query. É altamente recomendável remover o comentário e configurar esse filtro para limitar os dados às unidades de negócio relevantes para sua análise, o que pode melhorar significativamente a performance.
Pré-requisitos: o usuário que cria e executa o relatório precisa de uma função com privilégios do BI Publisher, como 'BI Administrator Role' ou 'BI Author Role'. Além disso, esse usuário precisa das concessões de segurança de dados necessárias para acessar os dados de Procurement.

a Consulta de exemplo 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'

Etapas

Pré-requisitos e configuração do ambiente: confirme se o Python 3 está instalado no seu sistema. Instale a biblioteca requests necessária executando o seguinte comando no terminal: pip install requests. Você também precisará das credenciais da API, como nome de usuário e senha, de um usuário do Oracle Fusion com permissões suficientes para ler dados de requisições de compra, além da URL base da sua instância do Oracle Fusion.
Salve o script Python: salve o código Python completo fornecido na seção 'query' como um arquivo, por exemplo, extract_requisitions.py.
Configure os parâmetros do script: abra o arquivo do script em um editor de texto. Altere os valores de placeholder no início do script. Defina FUSION_URL, USERNAME e PASSWORD de acordo com os dados do seu ambiente Oracle Fusion. Ajuste START_DATE e END_DATE para definir o período da extração.
Entenda os endpoints e campos da API: o script usa o recurso da REST API purchaseRequisitions. Ele utiliza o parâmetro fields para solicitar apenas os dados necessários, incluindo coleções aninhadas como lines, para informações do PO, e actionHistory, para eventos de aprovação, melhorando a performance.
Execute o script: execute o script no terminal usando o comando: python extract_requisitions.py. O script fará a autenticação na API, começará a buscar os dados e exibirá atualizações de progresso no console, mostrando quantas requisições foram processadas.
Trate a paginação: o script trata a paginação automaticamente. A REST API do Oracle Fusion retorna os dados em blocos, ou páginas. O script verifica a flag hasMore em cada resposta e faz novas requisições repetidamente com um parâmetro offset atualizado até recuperar todas as requisições dentro do intervalo de datas especificado.
Lógica de transformação dos dados: para cada requisição recuperada da API, o script gera várias linhas no Event Log. Ele cria um evento 'Requisition Created' a partir de CreationDate, um evento 'Requisition Submitted' a partir de SubmittedDate e percorre a coleção actionHistory para criar eventos detalhados de cada etapa de aprovação, como Started, Approved, Rejected e Returned.
Infira os eventos de status final: o script captura eventos de resultado final, como 'Requisition Approved' e 'Requisition Rejected', verificando o DocumentStatus final da requisição e usando LastUpdateDate como timestamp do evento.
Gere o evento do pedido de compra: o script verifica cada linha da requisição. Se uma linha tiver um PoHeaderId, isso indica que um pedido de compra foi criado. Uma entrada é gerada no Event Log para essa atividade, vinculando a requisição ao processo de compras subsequente.
Revise o arquivo de saída: quando o script terminar, ele criará um arquivo CSV chamado oracle_fusion_requisitions_event_log.csv no mesmo diretório. Esse arquivo contém o Event Log extraído.
Prepare para o upload: abra o arquivo CSV gerado em um programa de planilhas para verificar seu conteúdo. Confirme se as colunas e os formatos dos dados estão de acordo com os requisitos da sua ferramenta de Process Mining. O arquivo estará pronto para ser carregado no ProcessMind.

Configuração

Credenciais da API: é necessária uma conta de usuário de integração dedicada, com uma função que conceda acesso somente leitura à REST API de Purchase Requisitions. Exemplos de funções incluem Procurement Manager ou uma função de integração personalizada.
Endpoint da REST API: o script está configurado para usar o endpoint .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Confirme se o número da versão na URL corresponde ao seu ambiente Oracle Fusion.
Filtro por intervalo de datas: o script inclui as variáveis START_DATE e END_DATE. É altamente recomendável extrair os dados em lotes gerenciáveis, como 3 a 6 meses por vez, para evitar timeouts da API e problemas de performance. O filtro é aplicado à CreationDate das requisições.
Seleção de campos: o parâmetro fields do script é fundamental para a performance. Ele limita o payload da resposta aos atributos necessários para o Event Log, reduzindo o tráfego de rede e o tempo de processamento. Não remova campos obrigatórios como RequisitionId, CreationDate, actionHistory ou lines.
Limite de paginação: o parâmetro limit está definido como 100, um valor seguro para a maioria dos ambientes. Você pode tentar aumentá-lo para 200 ou 500 para obter uma extração potencialmente mais rápida, mas fique atento a problemas de memória ou limites da API se o valor for alto demais.

a Consulta de exemplo 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()

Etapas

Confirme se o Oracle BI Cloud Connector, o conteúdo de Procurement necessário do Oracle Fusion Financials e o acesso aos Public View Objects relevantes estão disponíveis no seu ambiente. Confirme se o usuário ou a conta de integração do BICC tem autorização para extrair dados de requisições, histórico de aprovações e pedidos de compra. Os nomes exatos das funções e os rótulos de navegação variam conforme a versão do Oracle. Por isso, use a área de administração do BICC correspondente no seu tenant.
Identifique e habilite os PVOs necessários para a extração. Use RequisitionHeaderPVO, ou o PVO de cabeçalho de requisição correspondente no seu ambiente, junto com os PVOs que expõem as linhas da requisição, o histórico de status da requisição, o histórico do Workflow de aprovação e as referências de pedidos de compra. Não presuma que um único PVO contenha o histórico do Workflow ou o histórico de criação de pedidos de compra. Registre os nomes exatos dos PVOs e os atributos disponíveis no seu tenant.
Configure um job do BICC para uma extração em massa incremental ou histórica. Defina a janela de extração com [Start date parameter] e [End date parameter] e configure o job para entregar arquivos CSV no local aprovado de armazenamento em nuvem. Para a carga inicial, use um intervalo histórico suficientemente amplo. Para cargas recorrentes, use janelas sobrepostas para considerar atualizações atrasadas e depois elimine duplicidades usando o identificador do caso, a atividade, o timestamp do evento e o identificador do evento de origem, quando disponível.
Configure as colunas da extração. Inclua o identificador da requisição, os identificadores do cabeçalho e das linhas da requisição, o solicitante, o departamento, o valor, o status, a data necessária, a unidade de negócio, o motivo da rejeição, os timestamps de criação e atualização, os timestamps das transições de status, os timestamps de atribuição e ação da aprovação, a ação de aprovação, a referência do pedido de compra e o timestamp de atualização do BICC. Use os nomes exatos dos atributos expostos pelos PVOs selecionados. Se um atributo não estiver disponível, mapeie-o para [Configure based on your system] e documente a limitação, em vez de substituí-lo por um campo não verificado.
Extraia os arquivos CSV de origem e preserve os arquivos originais. Carregue cada arquivo em uma área de preparação, mantenha o nome do PVO e do arquivo de origem, normalize os timestamps para um único fuso horário acordado e analise os valores de data e timestamp do Oracle de forma consistente. Trate os identificadores como strings para evitar a perda de zeros à esquerda ou de precisão.
Reestruture os dados de origem em uma tabela de eventos com uma linha por evento de negócio explícito. A saída deve conter PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Adicione os atributos recomendados quando estiverem disponíveis. Não dependa do ProcessMind para inferir eventos a partir de alterações de status ou de campos. A transformação deve criar explicitamente linhas para todas as doze atividades listadas na consulta.
Crie as linhas de eventos com base nas evidências de origem apropriadas. Use a evidência de criação do registro para Requisition Created, uma transição explícita de envio para Requisition Submitted, uma ação ou transição explícita de retirada para Requisition Withdrawn, uma alteração detectada após o envio ou uma nova versão para Requisition Amended, a atribuição no Workflow para Approval Step Started e ações explícitas do histórico de aprovações para Approval Step Approved, Approval Step Rejected e Approval Step Returned. Use uma transição explícita do status geral para Requisition Approved, Requisition Rejected e Requisition Closed. Use um registro explícito de criação do pedido de compra ou um timestamp de criação vinculado à requisição para Purchase Order Created.
Aplique a eliminação determinística de duplicidades. Se várias linhas de origem representarem o mesmo evento, mantenha uma linha usando o timestamp de evento mais específico e um identificador de origem estável, quando disponível. Não agrupe etapas de aprovação distintas apenas porque elas compartilham o mesmo identificador de requisição. Preserve eventos de aprovação separados para aprovadores ou etapas de Workflow diferentes.
Valide o Event Log resultante. Confirme se todas as atividades obrigatórias estão representadas, se cada evento tem um identificador de caso e um timestamp de evento, se os timestamps estão dentro da janela de extração ou são explicados por atualizações recebidas posteriormente e se os atributos recomendados estão preenchidos quando a origem os fornece. Faça a conciliação das contagens de requisições e dos vínculos com pedidos de compra em relação às extrações de origem.
Exporte o Event Log final como CSV UTF-8, com uma linha de cabeçalho e um evento por linha. Use os nomes exatos das colunas PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate, além dos atributos recomendados. Faça o upload do CSV no ProcessMind e configure PurchaseRequisitionId como identificador do caso, ActivityName como atividade e EventTime como timestamp do evento.

Configuração

Método de extração: extração em massa de dados pelo Oracle BI Cloud Connector, entregue como arquivos CSV no local de armazenamento em nuvem configurado.
Objetos de origem: use RequisitionHeaderPVO e os PVOs correspondentes de linha da requisição, histórico de status, histórico do Workflow de aprovação e referência do pedido de compra disponíveis no tenant. Os nomes exatos dos PVOs e os atributos devem ser confirmados no ambiente.
Colunas de saída obrigatórias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate.
Colunas de saída recomendadas: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason e BusinessUnit.
Período: use de três a seis meses para análises de rotina. Use um período mais amplo para uma carga histórica inicial, quando necessário. Para extrações recorrentes, use janelas de extração sobrepostas para capturar atualizações tardias e depois eliminar duplicidades.
Filtros: aplique [Company-specific filter], [Document Type filter], [Business Unit filter] e [Date range filter] somente quando esses atributos estiverem disponíveis nos PVOs selecionados. Confirme se o filtro se aplica à data de criação, à data de atualização, à data de transição de status ou a outra data de origem.
Extração incremental: prefira um carimbo de data e hora de atualização ou um mecanismo de extração incremental compatível disponibilizado pelo BICC. Mantenha o watermark da última extração bem-sucedida e inclua uma pequena sobreposição na próxima execução.
Completude dos eventos: configure extrações de origem separadas quando os cabeçalhos das requisições não expuserem o histórico de aprovações, as transições de status, as alterações ou a criação do pedido de compra. Uma extração apenas do estado atual do cabeçalho não permite reconstruir eventos históricos com confiabilidade.
Performance: restrinja o período e as colunas selecionadas, particione extrações grandes quando houver suporte, evite atributos descritivos desnecessários e processe os arquivos CSV em lotes. Preserve os arquivos de origem para reconciliação.
Armazenamento: configure um local aprovado de armazenamento em nuvem com capacidade, retenção, criptografia e controles de acesso suficientes. Confirme se a conta de extração pode gravar arquivos e se o processo de transformação pode lê-los.
Pré-requisitos: disponibilidade do BICC, acesso aos dados relevantes de compras e aprovações do Oracle Fusion, autorizações de integração adequadas, acesso aos PVOs selecionados e qualquer assinatura ou direito de uso necessário do Oracle. Os nomes exatos das funções, licenças e caminhos de navegação dependem da versão do Oracle e da configuração do tenant.
Tratamento de horários: normalize todos os carimbos de data e hora de origem para um fuso horário documentado e mantenha o carimbo original quando a auditabilidade for necessária.
Tratamento de casos: use PurchaseRequisitionId como identificador do caso. Não use o identificador da linha da requisição como identificador do caso, a menos que o processo seja modelado intencionalmente no nível da linha.

a Consulta de exemplo 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;

Pronto para começar?

Use este Template para iniciar sua jornada rumo à otimização do processo de Purchase to Pay - Requisition e desbloquear novas eficiências. Prepare-se para transformar suas operações de compras.

Voltar ao guia de melhoria Baixar Template

Alcance um Purchase to Pay - Requisition 30% mais rápido

Simplifique seu Purchase to Pay - Requisition no Oracle e reduza o tempo de ciclo em 30%.

Comece seu teste grátis

Não é necessário cartão de crédito. Configure em poucos minutos.

Seu Template de dados de Purchase to Pay - Requisition

Seu Template de dados de Purchase to Pay - Requisition

Purchase to Pay - Requisição: atributos

Purchase to Pay - Requisição: atividades

Guias de extração

Exportação do Oracle Transactional Business Intelligence (OTBI)

Etapas

Configuração

a Consulta de exemplo sql

Extração de modelo de dados baseado em SQL do Oracle BI Publisher

Etapas

Configuração

a Consulta de exemplo sql

Script Python via Oracle Fusion REST API

Etapas

Configuração

a Consulta de exemplo python

Extração em massa de dados com o Oracle BI Cloud Connector (BICC)

Etapas

Configuração

a Consulta de exemplo sql

Pronto para começar?

Alcance um Purchase to Pay - Requisition 30% mais rápido

Seu Template de dados de Purchase to Pay - Requisition

Seu Template de dados de Purchase to Pay - Requisition

Purchase to Pay - Requisição: atributos

Purchase to Pay - Requisição: atividades

Guias de extração

Exportação do Oracle Transactional Business Intelligence (OTBI)

Etapas

Configuração

a Consulta de exemplo sql

Extração de modelo de dados baseado em SQL do Oracle BI Publisher

Etapas

Configuração

a Consulta de exemplo sql

Script Python via Oracle Fusion REST API

Etapas

Configuração

a Consulta de exemplo python

Extração em massa de dados com o Oracle BI Cloud Connector (BICC)

Etapas

Configuração

a Consulta de exemplo sql

Pronto para começar?

Alcance um Purchase to Pay - Requisition 30% mais rápido

Valorizamos sua privacidade