> Melhoria contínua de processos > Compra ao pagamento: requisição > Oracle Fusion Financials > Template de dados

Seu Template de dados para requisição de compra a pagamento

Oracle Fusion Financials

Atributos da requisição de compra a pagamento(22) Atividades da requisição de compra a pagamento(12) Guias de extração(4)

Seu Template de dados para requisição de compra a pagamento

Este Template oferece um roteiro claro para coletar os dados essenciais à análise do processo de requisição de compra a pagamento. Ele apresenta os principais atributos a coletar, as atividades importantes a acompanhar e orientações práticas para extrair essas informações do Oracle Fusion Financials. Com esses dados, você pode preparar seu Event Log para fazer a mineração de processos e obter insights relevantes.

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

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

Atributos da requisição de compra a pagamento

Estes são os campos de dados recomendados para incluir no Event Log e fazer uma análise completa do processo de requisição de compra a pagamento.

5 Obrigatório 7 Recomendado 10 Opcional

	Nome	Descrição
	Atividade ActivityName	Nome do evento de negócio ocorrido em um determinado momento do processo de requisição.
Descrição A Atividade representa uma etapa ou marco específico no ciclo de vida da requisição de compra. Alguns exemplos são 'Requisição criada', 'Etapa de aprovação aprovada' e 'Pedido de compra criado'. Essas atividades são identificadas a partir de mudanças 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 criar 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, gargalos, ciclos de retrabalho e desvios do procedimento padrão. Por que isso importa Esse atributo é a base do mapa de processo e permite visualizar e analisar o fluxo de trabalho das requisições. Onde encontrar Derivado de registros de alteração de status em tabelas como POR_REQUISITION_HEADERS_ALL, do histórico de transações ou de trilhas de auditoria do fluxo de trabalho, como FA_FUSION_SOAINFRA.WFTASK. Exemplos Requisição criadaEtapa de aprovação aprovadaRequisição rejeitadaPedido de compra criado
	Hora do evento EventTime	Data e hora que indicam quando a atividade ocorreu.
Descrição A Hora do evento registra a data e a hora exatas em que uma atividade específica ocorreu. Esse dado é fundamental para ordenar cronologicamente os eventos de um caso e pode vir de datas de criação, datas da última atualização ou registros de data e hora de ações específicas no sistema. Na análise, a Hora do evento é usada 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. Ela é 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 Esse atributo é essencial para calcular todos os KPIs relacionados a tempo, ordenar os eventos corretamente e analisar a performance e os gargalos do processo. Onde encontrar Em geral, esse dado vem de uma coluna 'LAST_UPDATE_DATE' ou 'CREATION_DATE' associada à transação ou à alteração de status, normalmente encontrada em tabelas como POR_REQUISITION_HEADERS_ALL ou em tabelas de histórico do fluxo de trabalho. Exemplos 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID da requisição de compra PurchaseRequisitionId	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 quando é criada, que permanece o mesmo durante todo o seu ciclo de vida. Em Process Mining, esse atributo é usado para agrupar todos os eventos relacionados, como criação, envio, etapas de aprovação e encerramento, em um único caso. Assim, é possível analisar toda a jornada da requisição, visualizar mapas de processo, calcular tempos de ciclo e analisar as variantes de cada solicitação. Por que isso importa Esse é o atributo fundamental para acompanhar a requisição do início ao fim e viabilizar todas as análises por caso e os cálculos de KPIs. Onde encontrar Em geral, essa é a chave primária da 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	Sistema de informação do qual os dados foram extraídos.
Descrição Esse atributo identifica a origem dos dados do processo. Neste modelo de dados, o valor será sempre 'Oracle Fusion Financials'. Em ambientes com vários ERPs ou sistemas integrados, esse campo é essencial para rastrear a linhagem dos dados, solucionar problemas e garantir a qualidade dos dados. Ele dá contexto sobre a fonte de verdade dos eventos do processo analisados. Por que isso importa Fornece contexto essencial sobre a origem dos dados, importante para a governança de dados e a integração de informações de vários sistemas. Onde encontrar É um valor estático adicionado durante a extração e a transformação dos dados para identificar a origem do conjunto de dados. Exemplos Oracle Fusion Financials
	Última atualização dos dados LastDataUpdate	Data e hora da atualização mais recente dos dados extraídos do sistema de origem.
Descrição Esse atributo indica a data e a hora da última extração de dados do Oracle Fusion Financials. Ele se aplica ao conjunto de dados inteiro, não a eventos individuais. Os analistas usam essa informação para verificar se os dados estão atualizados e confirmar quando as transações mais recentes foram incluídas. É um metadado importante para os relatórios do Dashboard e para garantir que as análises usem informações atualizadas. Por que isso importa Informa quando os dados foram atualizados, ajudando a garantir que as análises sejam relevantes e usem as informações mais recentes disponíveis. Onde encontrar Esse dado de data e hora é gerado e armazenado durante a extração dos dados, geralmente pela ferramenta de ETL ou pelo pipeline de dados. Exemplos 2023-10-27T02:00:00Z
	Data necessária RequiredByDate	Data limite em que o solicitante precisa receber os bens ou serviços.
Descrição O solicitante informa essa data para indicar o prazo de recebimento dos itens solicitados. Ela funciona como uma meta interna de nível de serviço (SLA) para o processo de compras. Esse 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 mostra se o processo de compras está atendendo às demandas dos clientes internos e ajuda a 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 encontrar Geralmente armazenado no nível do item 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	Departamento da empresa ao qual o solicitante pertence.
Descrição Esse atributo indica a unidade organizacional da pessoa que criou a requisição, como 'Finanças', 'TI' ou 'Marketing'. Em geral, ele é obtido do perfil do solicitante no sistema de RH. Analisar os dados por departamento é uma forma comum e eficaz 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, e pode orientar iniciativas de melhoria direcionadas. Essa é uma dimensão importante do Dashboard 'Métricas de performance dos solicitantes'. Por que isso importa Permite segmentar a análise do processo por unidade de negócio e identificar padrões, performance e problemas de conformidade específicos de cada departamento. Onde encontrar Em geral, esse dado é obtido do perfil do solicitante. Normalmente, é preciso associar a tabela de requisições a uma tabela de RH ou de diretório de usuários que contenha informações sobre o departamento. Exemplos Tecnologia da informaçãoFinançasOperaçõesMarketing
	Motivo da rejeição RejectionReason	Motivo informado pelo aprovador ao rejeitar uma requisição ou etapa de aprovação.
Descrição Quando uma requisição é rejeitada, o aprovador geralmente informa um motivo, selecionando uma opção de uma lista predefinida ou escrevendo um comentário. Esse atributo registra a justificativa. Ele é essencial para a análise de causa raiz de falhas no processo. O atributo dá suporte direto ao Dashboard 'Tendências de alterações e rejeições', mostrando por que as requisições foram rejeitadas. Analisar os motivos ajuda a identificar problemas recorrentes, como classificação contábil incorreta, estouro de orçamento ou violação de políticas, que podem ser resolvidos com treinamento ou controles no sistema. Por que isso importa Mostra por que as requisições são rejeitadas e permite fazer melhorias direcionadas para reduzir o retrabalho e aumentar a taxa de processamento direto. Onde encontrar Obtido dos comentários do fluxo de trabalho ou de campos específicos de código do motivo da rejeição na trilha de auditoria do fluxo de trabalho, 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	Nome do funcionário que criou e enviou a requisição de compra.
Descrição Esse atributo identifica a pessoa que iniciou a solicitação de bens ou serviços. Em geral, essa informação é registrada 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 dos solicitantes'. Isso ajuda a identificar usuários ou grupos que podem precisar de treinamento adicional, destacando altas taxas de alterações, rejeições ou tempos de ciclo longos associados às solicitações. Assim, é possível entender o processo pela perspectiva das pessoas envolvidas. Por que isso importa Permite analisar a performance por solicitante, identificar necessidades de treinamento e destacar usuários ou departamentos eficientes. Onde encontrar Obtido dos 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 associe-os a PER_ALL_PEOPLE_F. Exemplos João SilvaMaria SouzaAna Oliveira
	Status da requisição RequisitionStatus	Status atual ou final da requisição de compra.
Descrição Esse atributo indica o estado geral da requisição em determinado momento ou o resultado final, como 'Aprovado', 'Rejeitado', 'Em andamento' ou 'Encerrado'. Muitas atividades do Event Log são derivadas desse atributo. Esse atributo é essencial para o Dashboard 'Visão geral do status das requisições', pois mostra um retrato da carga de trabalho e do backlog atuais. Ele também é usado para calcular KPIs baseados em resultados, como a taxa de rejeição de requisições, filtrando os casos que terminam com um status específico. Por que isso importa Mostra o estado atual das requisições e ajuda a determinar os resultados finais usados no cálculo de KPIs. Onde encontrar Encontrado na tabela de cabeçalho da requisição, geralmente em um campo como 'DOCUMENT_STATUS' ou 'APPROVAL_STATUS' em POR_REQUISITION_HEADERS_ALL. Exemplos APROVADOEM ANDAMENTOREJEITADORETIRADO
	Unidade de negócio BusinessUnit	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 da empresa para a qual a requisição é feita. É um agrupamento organizacional de nível superior ao departamento. Analisar os dados por Unidade de negócio permite comparar a performance em diferentes áreas da organização. Isso ajuda a liderança a entender se as ineficiências do processo estão concentradas em algumas áreas ou espalhadas pela empresa e onde direcionar os esforços de melhoria. Essa é uma dimensão importante para filtrar quase todos os Dashboards e KPIs. Por que isso importa Fornece uma visão geral da estrutura organizacional e permite comparar a performance e fazer análises estratégicas entre diferentes áreas da empresa. Onde encontrar Esse é um campo organizacional fundamental no Oracle Fusion, geralmente 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	Valor monetário total da requisição de compra.
Descrição Esse atributo representa a soma dos valores de todos os itens de uma requisição de compra. É um dado essencial para entender a relevância financeira de cada solicitação. Em Process Mining, o valor total pode ser usado em várias análises. Por exemplo, você pode filtrar requisições de alto valor, que costumam seguir fluxos de aprovação diferentes ou passar por uma análise mais rigorosa. Os Dashboards também podem usar esse atributo para analisar a relação entre o valor da requisição e métricas do processo, como tempo de ciclo ou taxa de rejeição. Por que isso importa Fornece contexto financeiro para análises por valor, ajudando a priorizar melhorias no processo e entender como o valor da requisição afeta o comportamento do processo. Onde encontrar Encontrado no cabeçalho da requisição, geralmente em um campo como REQUISITION_TOTAL em POR_REQUISITION_HEADERS_ALL. Também pode ser calculado somando os valores dos itens em POR_REQUISITION_LINES_ALL. Exemplos 550.0012500.7599.99
	Caminho do fluxo de aprovação ApprovalWorkflowPath	Sequência predefinida de aprovadores ou grupos de aprovação necessária para a requisição.
Descrição Esse atributo define o processo de aprovação padrão esperado para uma requisição, de acordo com as políticas da empresa e considerando fatores como valor, tipo e departamento. Ele representa o modelo de processo futuro. O Caminho do fluxo de aprovação é essencial para a conformidade e a análise de conformidade. Ele dá suporte direto ao Dashboard 'Análise de conformidade e desvios' e ao KPI 'Índice de conformidade das requisições', permitindo comparar as etapas de aprovação realizadas com o caminho definido. Os desvios podem indicar violações de políticas ou ineficiências no processo. Por que isso importa Permite verificar a conformidade comparando o fluxo real do processo com a hierarquia de aprovação exigida e destacando as requisições fora de conformidade. Onde encontrar Essa informação é configurada 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 > Chefe do departamento
	Descrição do item ItemDescription	Descrição do produto ou serviço solicitado em uma linha da requisição.
Descrição Esse atributo contém a descrição textual do item que será comprado. Ele apresenta detalhes específicos sobre os bens ou serviços solicitados. Embora muitas vezes não siga uma estrutura predefinida, a Descrição do item oferece contexto valioso para a análise. Você pode usá-la em filtros para encontrar 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 o fluxo do processo e o tempo de ciclo específicos. Por que isso importa Fornece detalhes sobre o que está sendo comprado e permite filtrar e analisar bens ou serviços específicos com mais precisão. Onde encontrar Encontrado na tabela de 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
	É automatizada IsAutomated	Indicador que mostra se uma atividade foi realizada automaticamente pelo sistema.
Descrição Esse atributo identifica eventos do processo executados por um usuário do sistema ou por um agente automatizado, em vez de uma pessoa. Alguns exemplos são alterações de status iniciadas pelo sistema ou etapas de aprovação automatizadas para itens de baixo valor. Analisar esse atributo ajuda a quantificar o nível de automação do processo. Ele pode ser usado para comparar a velocidade e a eficiência de etapas automatizadas e manuais, além de identificar oportunidades para ampliar a automação. Por que isso importa Ajuda a medir o nível de automação do processo e a identificar oportunidades para automatizar tarefas manuais. Onde encontrar Derivado da verificação de que o usuário associado a uma atividade é uma conta de sistema ou de serviço. Para isso, é necessária uma lista de IDs de usuários de sistema conhecidos. Exemplos truefalse
	Foi alterada IsAmendedFlag	Indicador booleano que assume o valor verdadeiro se a requisição foi alterada pelo menos uma vez.
Descrição Esse atributo calculado indica se a requisição sofreu alterações após o envio inicial. Ele é derivado da presença da atividade 'Requisição alterada' no histórico do caso. Esse indicador simplifica a análise e o cálculo de KPIs. Ele é usado diretamente para calcular o KPI 'Taxa de alteração de requisições' e identificar casos que não foram processados diretamente. Também facilita a filtragem e a comparação de métricas do processo entre requisições alteradas e não alteradas. Por que isso importa Simplifica o cálculo da taxa de alteração e facilita a comparação entre requisições alteradas e não alteradas. Onde encontrar Esse atributo não existe no sistema de origem. Ele é calculado durante a transformação dos dados, com base na presença de atividades relacionadas a alterações no Event Log. Exemplos truefalse
	Foi processada diretamente IsStraightThrough	Indicador que mostra se a requisição foi aprovada sem alterações ou rejeições.
Descrição Esse indicador calculado identifica requisições que passaram pelo processo, do envio à aprovação, sem ciclos de retrabalho, como alterações ou rejeições. Ele representa um processo executado sem desvios para um único caso. Esse atributo é a base do KPI 'Taxa de requisições processadas diretamente'. Analisar as características dessas requisições, 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 foram processadas diretamente ajuda a identificar as principais causas de ineficiência. Por que isso importa Mede diretamente a eficiência do processo e serve de base para o KPI de taxa de requisições processadas diretamente, ajudando a identificar as causas do retrabalho. Onde encontrar Esse atributo é calculado durante a transformação dos dados. Um caso recebe o valor verdadeiro se não tiver atividades 'Requisição alterada' nem 'Etapa de aprovação rejeitada'. Exemplos truefalse
	Moeda CurrencyCode	Código da moeda do valor da requisição, como USD ou EUR.
Descrição Esse atributo especifica a moeda em que o Valor total da requisição está expresso. Em organizações globais, as requisições podem ser criadas em diferentes moedas. Ele é essencial para interpretar e agregar corretamente os dados financeiros. Em qualquer análise que envolva valores monetários, use o código da moeda para garantir comparações precisas, filtrando uma única moeda ou convertendo todos os valores para uma moeda comum. Por que isso importa Garante a precisão das análises e dos relatórios financeiros, especialmente em organizações multinacionais que trabalham com várias moedas. Onde encontrar Em geral, 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	Nome do fornecedor sugerido ou pré-selecionado para os bens ou serviços.
Descrição Esse atributo identifica o fornecedor de quem se pretende comprar os bens ou serviços. O solicitante pode sugerir o fornecedor, ou o sistema pode selecioná-lo com base em catálogos ou acordos anteriores. Analisar os dados por fornecedor pode revelar padrões importantes nas compras. Por exemplo, isso ajuda a identificar se as requisições para determinados fornecedores levam mais tempo para serem aprovadas ou têm taxas de rejeição mais altas. Essas informações podem ser úteis 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 e pode ajudar na estratégia de compras e na gestão do relacionamento com fornecedores. Onde encontrar Encontrado na tabela de linhas da requisição, POR_REQUISITION_LINES_ALL, geralmente associado pelo campo VENDOR_ID a uma tabela mestre de fornecedores, como POZ_SUPPLIERS. Exemplos Suprimentos para Escritório Ltda.Soluções Globais de TecnologiaAgência de Marketing Criativo
	Nome do usuário UserName	Nome do usuário que realizou uma atividade específica, como um aprovador ou editor.
Descrição Enquanto Nome do solicitante identifica quem iniciou o processo, Nome do usuário indica quem executou um evento específico, como uma aprovação ou rejeição. Isso é especialmente importante em fluxos de trabalho com várias etapas de aprovação, que envolvem pessoas diferentes. Esse atributo é essencial para analisar gargalos na aprovação e medir a performance de aprovadores ou equipes específicas. Ele dá suporte direto ao Dashboard 'Gargalos no fluxo de aprovação', permitindo analisar os tempos de processamento de cada usuário envolvido na cadeia de aprovação. Por que isso importa Identifica quem realizou cada evento, informação essencial para analisar tempos de transferência, performance dos aprovadores e alocação de recursos. Onde encontrar Obtido do histórico do fluxo de trabalho ou de tabelas de trilha de auditoria, como FA_FUSION_SOAINFRA.WFTASK, que registra o usuário associado à conclusão de cada tarefa. Exemplos Carlos LimaFernanda CostaRafael Santos
	Número do pedido de compra PurchaseOrderNumber	Identificador do pedido de compra criado a partir da requisição aprovada.
Descrição Esse atributo conecta uma requisição de compra ao pedido de compra resultante. Depois de totalmente aprovada, a requisição costuma ser convertida em um ou mais pedidos de compra, que são enviados ao fornecedor. Na análise, esse ID é essencial para acompanhar as etapas posteriores à requisição. Ele permite calcular o KPI 'Tempo da requisição ao 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 subsequentes de pedido de compra e faturamento para uma análise completa de Purchase-to-Pay. Por que isso importa Conecta a requisição ao pedido de compra subsequente, permitindo medir o tempo de ciclo entre eles e analisar o processo de ponta a ponta. Onde encontrar Essa informação é armazenada quando um pedido de compra é criado. Em geral, ela pode ser encontrada nas referências à requisição de origem nas tabelas de distribuição do pedido, como PO_DISTRIBUTIONS_ALL, que se conecta à linha da requisição. Exemplos PC-2023-5832PC-2023-5833PC-2023-5834
	Tipo de requisição RequisitionType	Categoria da requisição, como solicitação de bens ou serviços.
Descrição Esse atributo classifica a requisição de acordo com o que está sendo solicitado. Os tipos mais comuns incluem bens, serviços ou despesas de capital. O tipo pode influenciar o fluxo de aprovação necessário e a estratégia de compras. Na análise, o Tipo de requisição é uma dimensão útil para filtrar e comparar dados. Por exemplo, você pode verificar se requisições de serviços levam mais tempo para serem aprovadas do que 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 tipos de compra, como bens e serviços. Onde encontrar Geralmente determinado pelo tipo ou pela categoria do item selecionado durante a criação da requisição. Pode estar armazenado na tabela de linhas da requisição, POR_REQUISITION_LINES_ALL. Exemplos BensServiçosDespesas de capital

Obrigatório Recomendado Opcional

Atividades da requisição de compra a pagamento

Estas são as principais etapas e marcos do processo que você deve registrar no Event Log para descobrir com precisão como funciona o processo de requisição de compra a pagamento.

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 à etapa seguinte do processo de compras.
Por que isso importa Este é um marco importante para medir o prazo entre a requisição e o pedido de compra. Atrasos nessa etapa indicam gargalos na transferência entre a aprovação e a compra. Onde encontrar Este evento é registrado explicitamente. A relação entre a requisição e o pedido de compra fica armazenada em tabelas como PO_LINE_LOCATIONS_ALL, que contém uma referência ao ID da linha de requisição de origem. Coleta Encontre a data de criação do pedido de compra que faz referência ao ID de requisição correspondente. Tipo de evento explicit
	Requisição aprovada	Marca a aprovação final da requisição de compra, após a conclusão de todas as etapas do fluxo de trabalho. O evento é inferido quando o status geral da requisição muda para Approved.
Por que isso importa Este é um marco importante que indica que a solicitação está pronta para seguir para compras. É o ponto final para medir o tempo total do ciclo de aprovação da requisição. Onde encontrar Inferido quando o campo de status do documento na tabela POR_REQUISITION_HEADERS_ALL muda para APPROVED. A data dessa mudança de status é a data e hora do evento. Coleta Identifique a data e hora em que o status do documento muda pela primeira vez para 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. Em geral, esse evento é registrado explicitamente no sistema, com a data e hora correspondentes.
Por que isso importa Este é o evento de início principal do processo de requisição. Analisar o tempo entre a criação e o envio pode revelar atrasos na formalização da solicitação. Onde encontrar Este evento é registrado na tabela POR_REQUISITION_HEADERS_ALL, usando a coluna creation_date quando um novo ID de requisição é gerado. Coleta Use a data e hora de criação do registro do cabeçalho da requisição. Tipo de evento explicit
	Requisição encerrada	Indica o encerramento final do ciclo de vida da requisição, ou seja, todas as linhas foram atendidas, por exemplo, convertidas em pedidos de compra, ou canceladas. O evento é inferido a partir de uma atualização final de status.
Por que isso importa Este é o principal evento de encerramento bem-sucedido do processo. Ele confirma que a requisição foi totalmente processada e não exige outras ações. Onde encontrar Inferido quando o status do cabeçalho da requisição na tabela POR_REQUISITION_HEADERS_ALL muda para CLOSED. Coleta Identifique a 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 fluxo de trabalho de aprovação. O evento é registrado quando o status da requisição muda de Incomplete ou Draft para um status que indica aprovação pendente.
Por que isso importa Esta atividade inicia o ciclo de aprovação. É um marco importante para medir o tempo de ciclo de aprovação da requisição e os prazos totais. Onde encontrar Inferido a partir de uma mudança de status na tabela POR_REQUISITION_HEADERS_ALL, por exemplo, quando o status passa para PENDING APPROVAL. A data de envio também costuma ser armazenada explicitamente. Coleta Identifique a 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. O evento é inferido quando o status geral da requisição muda para Rejected.
Por que isso importa Esta atividade é o ponto final de 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 encontrar Inferido quando o status do documento na tabela POR_REQUISITION_HEADERS_ALL muda para REJECTED. Coleta Identifique a data e hora em que o status do documento muda pela primeira vez para 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 fluxo de trabalho. 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 encontrar Capturado no histórico de ações de aprovação da requisição, geralmente armazenado em tabelas de fluxo de trabalho (WF) ou de Human Capital Management (HCM), que gerenciam as hierarquias de aprovação. Coleta Use a data e hora da ação APPROVE no registro do histórico de ações do fluxo de trabalho. Tipo de evento explicit
	Etapa de aprovação devolvida	Um aprovador devolve a requisição ao responsável pela preparação para solicitar informações adicionais ou pequenas correções, sem rejeitá-la formalmente. Em geral, essa ação é registrada explicitamente no sistema de fluxo de trabalho.
Por que isso importa Isso indica que são necessários esclarecimentos e cria um ciclo de retrabalho que aumenta o tempo de ciclo. Diferenciar devoluções de rejeições oferece uma visão mais aprofundada dos atritos no processo. Onde encontrar Capturado no histórico de ações de aprovação da requisição. O sistema de fluxo de trabalho registra uma ação RETURN ou semelhante, com a data e hora correspondentes. Coleta Use a data e hora da ação RETURN ou Request for Information no histórico do fluxo de trabalho. 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 no fluxo de trabalho. O evento é capturado no registro de transações do mecanismo de fluxo de trabalho.
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 encontrar Obtido nas tabelas de fluxo de trabalho do Oracle Fusion, que registram as tarefas atribuídas aos usuários. É usada a data e hora de atribuição da tarefa de aprovação. Coleta Use a data e hora de criação da tarefa no histórico do fluxo de trabalho da requisição correspondente. Tipo de evento explicit
	Etapa de aprovação rejeitada	Um aprovador individual rejeita a requisição, que normalmente volta para o responsável pela preparação para correção ou encerra a solicitação. Essa ação é registrada explicitamente no histórico do fluxo de trabalho.
Por que isso importa Esta atividade é uma das principais causas de retrabalho e atrasos. Analisar as rejeições ajuda a identificar problemas de conformidade, orçamento ou justificativas pouco claras. Onde encontrar Capturado no histórico de ações de aprovação da requisição. O sistema de fluxo de trabalho registra uma ação REJECT com a data e hora correspondentes. Coleta Use a data e hora da ação REJECT no registro do histórico de ações do fluxo de trabalho. 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 muitas vezes exige reiniciar o processo de aprovação. Ele é inferido pela detecção de mudanças 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. Este evento dá suporte direto ao KPI de taxa de alterações de requisições. Onde encontrar Inferido pelo acompanhamento dos números de versão da requisição ou pela identificação de mudanças de status para Incomplete após o envio. Os registros de alterações ou as tabelas de trilha de auditoria também podem registrar essas modificações. Coleta Identifique as datas e horas de criação de novas versões para o mesmo ID de 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 da aprovação completa. Em geral, é uma ação explícita do usuário que altera o status.
Por que isso importa Acompanhar as retiradas ajuda a identificar os motivos do encerramento antecipado, como mudanças nas necessidades do negócio ou correções feitas pelos usuários após o envio. Onde encontrar Inferido a partir da mudança de status para WITHDRAWN na tabela POR_REQUISITION_HEADERS_ALL. A ação fica registrada no histórico de ações da requisição. Coleta Detecte a data e hora em que o status da requisição muda 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: Entre no Oracle Fusion Financials. No menu Navigator, acesse Tools e selecione Reports and Analytics. Esse é o espaço central para 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 área de assunto: Você precisará selecionar uma área de assunto. Na caixa de pesquisa, digite 'Procurement - Requisitions Real Time' e selecione essa opção na lista. Essa área contém todos os dados necessários sobre os eventos do ciclo de vida das requisições.
Crie a análise dos eventos de requisição: Nesta etapa, você precisa combinar várias consultas para capturar cada evento. Como a interface do OTBI não oferece uma função UNION ALL direta para diferentes tipos de evento, crie um único relatório que reúna 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'. Inclua colunas como data de criação, data de envio, data de aprovação e data de criação do pedido de compra.
Adicione o histórico de ações da requisição: Para capturar as etapas detalhadas de aprovação (aprovada, rejeitada, devolvida, retirada), inclua campos da pasta 'Requisition Action History' na área de assunto. 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 período 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 os dados. O resultado será uma tabela 'ampla', com uma linha por item da requisição ou ação de aprovação e várias colunas de data e status.
Exporte os dados brutos: Quando estiver satisfeito com a prévia, clique no link 'Export', geralmente localizado na parte inferior da página de resultados. Escolha 'Data' > 'CSV File' como formato. Isso fará o download dos dados brutos da análise.
Transforme os dados no formato de Event Log: O arquivo CSV exportado estará em formato amplo. Use uma ferramenta externa, como um script Python, o Power Query no Excel ou outra ferramenta de preparação de dados, para transformá-lo. O processo envolve converter as colunas de data em linhas, reunindo-as em uma única coluna 'EventTime' e criando uma coluna 'ActivityName' correspondente para cada tipo de evento, como 'Requisition Created' e 'Requisition Submitted'.
Finalize e prepare o arquivo para carregamento: Após a transformação, confira se o arquivo contém as colunas obrigatórias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Salve o Event Log final como arquivo CSV para carregá-lo no ProcessMind.

Configuração

Área de assunto: A principal área de assunto a usar é 'Procurement - Requisitions Real Time'. Ela contém as informações essenciais sobre cabeçalhos e linhas de requisição, distribuições e histórico de aprovações.
Período: Sempre aplique um filtro obrigatório de data para limitar o volume de dados e melhorar a performance. Um bom ponto de partida é filtrar 'Requisition Header'.'Requisition Creation Date' para os últimos 3 a 6 meses.
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 desnecessários, como 'Canceled', se não forem necessários para a análise.
Seleção de colunas: Escolha com cuidado as colunas que você adiciona à análise. Incluir colunas demais, especialmente de várias pastas (dimensões), pode prejudicar a performance. Concentre-se apenas nos campos necessários para o Event Log.
Permissões: O usuário que executa a extração precisa ter uma função com as permissões necessárias para acessar a área de trabalho Reports and Analytics e a área de assunto 'Procurement - Requisitions Real Time'. Funções como 'BI Author' ou 'Procurement Analyst' geralmente têm esses privilégios.

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

Entre 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, você pode informar um nome e uma descrição. Clique no ícone "+" para adicionar um Data Set e selecione "SQL Query".
Na caixa de diálogo do novo Data Set, informe um nome, como Requisition_Event_Log, selecione a Fonte de dados 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. O BI Publisher os reconhecerá automaticamente. Se quiser, você pode definir valores padrão.
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 o 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 os dados forem exibidos, use a função "Export" para baixar os resultados como arquivo CSV.
Confira se o arquivo CSV final está salvo com codificação UTF-8 e contém os cabeçalhos necessários para carregar os dados na sua ferramenta de Process Mining.

Configuração

Fonte de dados: A Fonte de dados do BI Publisher, geralmente chamada 'ApplicationDB_FSCM' ou algo semelhante, deve estar configurada com um usuário que tenha acesso de leitura a todas as tabelas da consulta, incluindo as de Procurement (POR, PO), Human Capital Management (PER, HR) e Financials (FUN).
Filtro de período: A consulta foi criada com parâmetros de data obrigatórios (:p_start_date e :p_end_date) que filtram pela data de criação da requisição. Nas extrações iniciais ou em sistemas grandes, é essencial extrair os dados em lotes gerenciáveis, por exemplo, de 3 a 6 meses por vez, para evitar que o sistema exceda o tempo limite.
Filtro por unidade de negócio: A cláusula WHERE da consulta inclui um filtro para o nome da unidade de negócio, atualmente comentado. Recomendamos remover os comentários e configurar esse filtro para limitar os dados às unidades de negócio relevantes para sua análise, o que pode melhorar bastante a performance.
Pré-requisitos: O usuário que cria e executa o relatório precisa ter uma função com privilégios do BI Publisher, como 'BI Administrator Role' ou 'BI Author Role'. Além disso, precisa das permissões de segurança de dados necessárias para acessar os dados de compras.

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: Confira se o Python 3 está instalado no seu sistema. Instale a biblioteca requests necessária executando o comando a seguir no terminal: pip install requests. Você também precisará das credenciais da API (nome de usuário e senha) de um usuário do Oracle Fusion com permissões suficientes para ler os 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 exemplo no início do script. Defina FUSION_URL, USERNAME e PASSWORD de acordo com 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 consulta o recurso da API REST purchaseRequisitions. Ele usa o parâmetro fields para solicitar apenas os dados necessários, incluindo coleções aninhadas como lines (para informações do pedido de compra) e actionHistory (para eventos de aprovação), o que melhora a performance.
Execute o script: No terminal, execute 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, indicando quantas requisições foram processadas.
Trate a paginação: O script trata a paginação automaticamente. A API REST do Oracle Fusion retorna os dados em blocos (páginas). O script verifica o indicador hasMore em cada resposta e envia novas solicitações com o parâmetro offset atualizado até recuperar todas as requisições do período especificado.
Lógica de transformação dos dados: Para cada requisição recuperada pela 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 (iniciada, aprovada, rejeitada, devolvida).
Identifique os eventos de status final: O script captura os eventos de resultado final, como 'Requisition Approved' e 'Requisition Rejected', verificando o DocumentStatus final da requisição e usando LastUpdateDate como data e hora do evento.
Gere o evento de 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 de evento é gerada 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 o arquivo para carregamento: Abra o arquivo CSV gerado em um programa de planilhas e confira o conteúdo. Verifique se as colunas e os formatos de dados atendem aos 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 para leitura à API REST de requisições de compra. Entre as funções possíveis estão Procurement Manager ou uma função de integração personalizada.
Endpoint da API REST: O script está configurado para usar o endpoint .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Confira se o número da versão na URL corresponde ao seu ambiente Oracle Fusion.
Filtro de período: O script inclui as variáveis START_DATE e END_DATE. Recomendamos extrair os dados em lotes gerenciáveis, como períodos de 3 a 6 meses, para evitar que a API exceda o tempo limite e problemas de performance. O filtro é aplicado a CreationDate das requisições.
Seleção de campos: O parâmetro fields do script é essencial para a performance. Ele limita a 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 acelerar a extração, mas valores muito altos podem causar problemas de memória ou atingir os limites da API.

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 compras 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 dos itens de navegação variam conforme a versão do Oracle. Use a área de administração do BICC correspondente ao seu ambiente.
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 disponibilizam linhas de requisição, histórico de status, histórico do fluxo de aprovação e referências a pedidos de compra. Não presuma que um único PVO contenha o histórico do fluxo de trabalho ou o histórico de criação de pedidos de compra. Registre os nomes exatos dos PVOs e os atributos disponíveis no seu ambiente.
Configure um job do BICC para uma extração incremental ou histórica em lote. Defina o período de extração com [Start date parameter] e [End date parameter] e configure o job para enviar arquivos CSV ao local de armazenamento em nuvem aprovado. Para a carga inicial, use um período histórico suficientemente amplo. Nas cargas recorrentes, use períodos sobrepostos para incluir atualizações atrasadas e, em seguida, elimine duplicidades usando o identificador do caso, a atividade, a data e hora 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, solicitante, departamento, valor, status, data necessária, unidade de negócio, motivo da rejeição, datas e horas de criação e atualização, datas e horas de transição de status, atribuição e ação de aprovação, ação de aprovação, referência do pedido de compra e data e hora de atualização do BICC. Use os nomes exatos dos atributos disponibilizados 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 de origem e o nome do arquivo, normalize as datas e horas para um único fuso horário acordado e interprete os valores de data e hora do Oracle de forma consistente. Trate os identificadores como texto 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. Inclua 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 o registro de criação 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, uma atribuição no fluxo de trabalho para Approval Step Started e ações explícitas no 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. Para Purchase Order Created, use um registro explícito de criação do pedido de compra ou uma data e hora de criação vinculada à requisição.
Aplique a eliminação determinística de duplicidades. Se várias linhas de origem representarem o mesmo evento, mantenha uma linha usando a data e hora de evento mais específica e um identificador de origem estável, quando disponível. Não agrupe etapas de aprovação distintas só porque têm o mesmo identificador de requisição. Preserve eventos de aprovação separados para diferentes aprovadores ou etapas do fluxo de trabalho.
Valide o Event Log resultante. Confirme se todas as atividades obrigatórias estão representadas, se cada evento tem um identificador de caso e uma data e hora, se as datas e horas estão dentro do período de extração ou se as atualizações atrasadas estão explicadas e se os atributos recomendados estão preenchidos quando a origem os fornece. Compare as contagens de requisições e os vínculos com pedidos de compra com as 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 exatamente os nomes de coluna PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate, além dos atributos recomendados. Carregue o CSV no ProcessMind e configure PurchaseRequisitionId como identificador do caso, ActivityName como atividade e EventTime como data e hora do evento.

Configuração

Método de extração: extração de dados em lote pelo Oracle BI Cloud Connector, com entrega de arquivos CSV no local de armazenamento em nuvem configurado.
Objetos de origem: use RequisitionHeaderPVO e os PVOs correspondentes de linhas de requisição, histórico de status, histórico do fluxo de aprovação e referências a pedidos de compra disponíveis no ambiente. Confirme no ambiente os nomes exatos dos PVOs e dos atributos.
Colunas obrigatórias de saída: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate.
Colunas recomendadas de saída: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason e BusinessUnit.
Período: use de três a seis meses para análises de rotina. Quando necessário, use um período mais amplo para a carga histórica inicial. Nas extrações recorrentes, use períodos sobrepostos para capturar atualizações atrasadas e depois elimine as 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 uma data e hora de atualização ou um mecanismo de extração incremental compatível disponibilizado pelo BICC. Mantenha o marcador da última extração bem-sucedida e inclua um pequeno período de sobreposição na execução seguinte.
Completude dos eventos: configure extrações de origem separadas quando os cabeçalhos das requisições não disponibilizarem o histórico de aprovações, as transições de status, as alterações ou a criação de pedidos de compra. Uma extração apenas do estado atual do cabeçalho não permite reconstruir o histórico de eventos com confiabilidade.
Performance: restrinja o período e as colunas selecionadas, divida extrações grandes em partições quando houver suporte, evite atributos descritivos desnecessários e processe os arquivos CSV em lotes. Preserve os arquivos de origem para conferência.
Armazenamento: configure um local de armazenamento em nuvem aprovado 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 de compras e aprovações relevantes do Oracle Fusion, autorizações de integração adequadas, acesso aos PVOs selecionados e qualquer assinatura ou licença de recurso exigida pela Oracle. As funções, licenças e etapas de navegação exatas dependem da versão do Oracle e da configuração do ambiente.
Tratamento de datas e horas: normalize todas as datas e horas de origem para um fuso horário documentado e mantenha os valores originais quando a auditabilidade for necessária.
Identificação de casos: use PurchaseRequisitionId como identificador do caso. Não use o identificador de uma linha de requisição como identificador do caso, a menos que o processo seja modelado intencionalmente no nível da linha.

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 começar a otimizar seu processo de requisição de compra a pagamento e encontrar novas oportunidades de eficiência. Prepare-se para transformar suas operações de compras.

Voltar ao guia de melhoria

Baixar Template

Conclua o processo de requisição de compra a pagamento 30% mais rápido

Simplifique as requisições P2P no Oracle e reduza o tempo de ciclo em 30%.

Começar o teste grátis

Não é necessário cartão de crédito. A configuração leva poucos minutos.

Seu Template de dados para requisição de compra a pagamento

Seu Template de dados para requisição de compra a pagamento

Atributos da requisição de compra a pagamento

Atividades da requisição de compra a pagamento

Guias de extração

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

Etapas

Configuração

Consulta de exemplo sql

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

Etapas

Configuração

Consulta de exemplo sql

Script Python pela API REST do Oracle Fusion

Etapas

Configuração

Consulta de exemplo python

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

Etapas

Configuração

Consulta de exemplo sql

Pronto para começar?

Conclua o processo de requisição de compra a pagamento 30% mais rápido