Seu Template de dados de compras, do pedido ao pagamento

Oracle Fusion Financials
Seu Template de dados de compras, do pedido ao pagamento

Seu Template de dados de compras, do pedido ao pagamento

Este Template oferece um roteiro claro para coletar os dados necessários à análise do processo de compras, do pedido ao pagamento. Ele apresenta os atributos de dados essenciais, as principais atividades a acompanhar e orientações práticas para extrair essas informações. Use-o para garantir que você capture todos os detalhes importantes para uma mineração de processos eficaz.
  • Atributos recomendados para uma coleta abrangente de dados
  • Principais atividades do processo para acompanhar e analisar
  • Orientações passo a passo para extrair dados do Oracle Fusion Financials
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos de compras, do pedido ao pagamento

Estes são os campos de dados recomendados para incluir no Event Log e analisar de forma abrangente o processo de compras, do pedido ao pagamento.
3 Obrigatório 7 Recomendado 11 Opcional
Nome Descrição
Atividade
ActivityName
Nome de um evento ou etapa de negócio específico ocorrido durante o ciclo de vida do pedido de compra.
Descrição

Esse atributo descreve uma tarefa específica ou uma mudança de status no processo, como 'Pedido de compra criado' ou 'Mercadorias recebidas'. Essas atividades formam a sequência de eventos que compõe o fluxo do processo.

Analisar a sequência e o momento dessas atividades é a base de Process Mining. Isso ajuda a visualizar o mapa do processo, identificar gargalos, descobrir desvios do procedimento padrão e medir a duração de etapas específicas.

Por que isso importa

As atividades são os elementos que compõem o mapa do processo. Acompanhar essas atividades permite visualizar e analisar o fluxo do processo, os gargalos e os desvios.

Onde encontrar

Derivado de mudanças de status em tabelas como PO_HEADERS_ALL e PO_ACTION_HISTORY ou de tabelas de transações específicas, como RCV_TRANSACTIONS, para recebimentos de mercadorias.

Exemplos
Pedido de compra criadoPedido de compra aprovadoMercadorias recebidas
Hora de início
EventTime
Data e hora que indicam quando uma atividade ou evento específico ocorreu.
Descrição

Esse atributo registra a data e a hora exatas de cada atividade do processo. Ele é fundamental para ordenar os eventos cronologicamente e realizar todas as análises baseadas em tempo.

Em Process Mining, a hora de início é usada para criar o Event Log, calcular os tempos de ciclo entre atividades, medir os tempos de espera e analisar a performance do processo em diferentes períodos. Ela é essencial para os Dashboards de tempo de ciclo e performance.

Por que isso importa

Essa data e hora são essenciais para ordenar corretamente os eventos e calcular todas as métricas de duração, como tempos de ciclo e gargalos.

Onde encontrar

Campos de data e hora, como CREATION_DATE e LAST_UPDATE_DATE, em várias tabelas, incluindo PO_HEADERS_ALL, PO_ACTION_HISTORY e RCV_SHIPMENT_LINES.

Exemplos
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
Pedido de compra
PurchaseOrder
Identificador exclusivo do documento de pedido de compra, usado como ID do caso principal para acompanhar o ciclo de compras.
Descrição

O número do pedido de compra é o identificador central que conecta todas as atividades relacionadas, da criação ao encerramento definitivo. Ele permite analisar de ponta a ponta um único caso de compra.

Em Process Mining, cada número exclusivo de pedido de compra representa uma instância do processo. Analisar os dados agrupados por esse identificador ajuda a entender as variações do processo, os tempos de ciclo e a conformidade de cada pedido.

Por que isso importa

Esse é o ID do caso essencial que conecta todos os eventos relacionados e permite reconstruir e analisar todo o ciclo de vida do pedido de compra.

Onde encontrar

Oracle Fusion Cloud SCM, módulo Procurement, tabela PO_HEADERS_ALL, coluna SEGMENT1.

Exemplos
100234510023461002347
Data de entrega solicitada
RequestedDeliveryDate
Data em que a parte solicitante espera receber as mercadorias ou os serviços.
Descrição

Essa data é especificada na linha do pedido de compra e informa ao fornecedor o prazo de entrega desejado. Ela serve de referência para medir a performance de entrega no prazo.

Esse atributo é essencial para calcular o KPI 'Taxa de entrega no prazo'. Ao comparar a data real de recebimento das mercadorias com a data de entrega solicitada, as organizações podem medir e acompanhar quantitativamente a confiabilidade dos fornecedores e identificar atrasos recorrentes na cadeia de suprimentos.

Por que isso importa

Serve de referência para medir a performance de entrega no prazo, um KPI importante para avaliar a confiabilidade dos fornecedores e a eficiência da cadeia de suprimentos.

Onde encontrar

Localizado no nível da linha de entrega, na tabela PO_LINE_LOCATIONS_ALL, coluna NEED_BY_DATE.

Exemplos
2023-05-202023-06-152023-07-01
Departamento
DepartmentName
Nome do departamento que iniciou o pedido de compra ou é responsável por ele.
Descrição

Esse atributo especifica a unidade organizacional associada à compra, como 'Finanças', 'TI' ou 'Manufatura'. Ele é usado para alocação de custos e relatórios organizacionais.

Em Process Mining, segmentar o processo por departamento é essencial para comparar a performance, identificar gargalos específicos de cada departamento e entender as variações na execução do processo em toda a organização. Esse atributo dá suporte direto a Dashboards como 'Análise do tempo de ciclo de aprovação de pedidos de compra' e 'Tendências de alteração de pedidos de compra'.

Por que isso importa

Permite filtrar e comparar a performance do processo entre diferentes unidades de negócio, revelando problemas específicos de cada departamento ou boas práticas.

Onde encontrar

Derivado das informações do centro de custo em tabelas como PO_DISTRIBUTIONS_ALL, que se conecta aos dados mestres dos departamentos.

Exemplos
Operações de TIMarketingPesquisa e desenvolvimento
Hora de término
EndTime
Data e hora em que uma atividade foi concluída. Em geral, são iguais à hora de início para eventos atômicos.
Descrição

Para atividades com duração, esse campo indica o horário de conclusão. Em eventos instantâneos, normalmente corresponde à hora de início. É essencial para calcular o tempo de processamento de cada atividade.

Ter uma hora de término distinta permite analisar a duração das atividades com mais precisão, que pode ser diferente do tempo de espera entre elas. Isso ajuda a separar o tempo de trabalho ativo do tempo ocioso e dá suporte à análise da carga de trabalho dos recursos e da eficiência.

Por que isso importa

Permite calcular com precisão o tempo de processamento das atividades, essencial para analisar a eficiência dos recursos e identificar tarefas demoradas.

Onde encontrar

Pode ser igual à hora de início para eventos atômicos ou ser derivada das datas e horas de eventos posteriores. Algumas atividades podem ter um campo separado para registrar a conclusão.

Exemplos
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
Nome do aprovador
ApproverName
Nome do usuário que aprovou ou rejeitou o pedido de compra.
Descrição

Esse atributo identifica a pessoa responsável por uma etapa de aprovação no fluxo de trabalho. Essas informações costumam ser armazenadas em uma tabela de histórico de ações ou de registro do fluxo de trabalho associada ao pedido de compra.

Analisar os dados por aprovador é essencial para os Dashboards 'Análise do tempo de ciclo de aprovação de pedidos de compra' e 'Carga de trabalho dos recursos de aprovação'. Isso ajuda a identificar gargalos entre os aprovadores ou grupos de aprovação, permite avaliar a distribuição da carga de trabalho com equilíbrio e pode revelar oportunidades de delegação ou reformulação do processo.

Por que isso importa

Identifica as pessoas na cadeia de aprovação e permite analisar gargalos, carga de trabalho e tempos de ciclo por aprovador.

Onde encontrar

Usuário que realizou a ação, identificado em PO_ACTION_HISTORY.ACTION_PERFORMED_BY e vinculado a uma tabela de usuários para obter o nome completo.

Exemplos
susan.managerdavid.directoremily.finance
Nome do fornecedor
VendorName
Nome do fornecedor de quem as mercadorias ou os serviços estão sendo comprados.
Descrição

Esse atributo identifica o fornecedor externo do pedido de compra. É um dado mestre essencial vinculado ao cabeçalho do pedido.

A análise de fornecedores é uma parte importante de Process Mining em P2P. Ao filtrar ou segmentar por fornecedor, as empresas podem analisar a 'Performance de entrega dos fornecedores', comparar as taxas de entrega no prazo e investigar a 'Taxa de devolução de mercadorias' para identificar fornecedores com melhor ou pior performance. Esses dados são essenciais para gerenciar o relacionamento com fornecedores e as compras estratégicas.

Por que isso importa

Essencial para analisar a performance dos fornecedores, permitindo comparar prazos de entrega, taxas de devolução e confiabilidade geral.

Onde encontrar

Vinculado de PO_HEADERS_ALL.VENDOR_ID a POZ_SUPPLIERS.VENDOR_NAME.

Exemplos
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
Usuário
UserName
ID ou nome da pessoa que realizou a atividade.
Descrição

Esse atributo identifica o funcionário ou usuário do sistema responsável por determinado evento, como criar uma requisição, aprovar um pedido de compra ou registrar um recebimento de mercadorias. Normalmente, os dados vêm de campos como 'Criado por' ou 'Última atualização por'.

Analisar o processo por usuário ajuda a entender a distribuição da carga de trabalho, a performance individual e as necessidades de treinamento. Esse atributo é fundamental para o Dashboard 'Carga de trabalho dos recursos de aprovação' e para investigar problemas de conformidade relacionados às ações dos usuários.

Por que isso importa

Associa as ações dos usuários a pessoas específicas, permitindo analisar a carga de trabalho, avaliar a performance e identificar oportunidades de treinamento.

Onde encontrar

Faça a junção com as tabelas de usuários usando os IDs de campos como CREATED_BY ou LAST_UPDATED_BY em tabelas como PO_HEADERS_ALL e PO_ACTION_HISTORY.

Exemplos
john.doejane.smithsystem.batch
Valor total do pedido de compra
PurchaseOrderTotalAmount
Valor monetário total do pedido de compra.
Descrição

Esse atributo representa o custo total de todos os itens do pedido de compra na moeda especificada. É uma métrica financeira importante para entender o valor das transações que passam pelo processo.

Analisar o valor total do pedido de compra ajuda a priorizar iniciativas de melhoria do processo. Por exemplo, pedidos de alto valor podem seguir um processo de aprovação mais rigoroso. Esse atributo também permite analisar o impacto financeiro, como calcular o valor dos pedidos que sofrem alterações frequentes ou atrasos.

Por que isso importa

Dá contexto financeiro ao processo e permite analisar os dados por valor monetário, por exemplo, priorizando pedidos de alto valor ou entendendo o impacto financeiro dos atrasos.

Onde encontrar

Calculado pela soma dos valores de PO_LINES_ALL para determinado cabeçalho de pedido de compra ou obtido do total no cabeçalho, se disponível.

Exemplos
5250.00120000.50750.99
A aprovação está em conformidade
IsApprovalCompliant
Indica se o pedido de compra foi aprovado antes de ser enviado ao fornecedor.
Descrição

Este é um atributo booleano calculado que verifica o cumprimento de um controle interno importante: um pedido de compra deve ser aprovado antes de ser enviado ao fornecedor. O valor é verdadeiro se a atividade 'Pedido de compra aprovado' ocorrer antes da atividade 'Pedido de compra enviado ao fornecedor'.

Esse atributo é essencial para o Dashboard 'Auditoria de conformidade do processo de pedidos de compra' e para o KPI 'Taxa de conformidade das aprovações de pedidos de compra'. Ele oferece uma maneira simples de identificar e quantificar violações de conformidade, ajudando a aplicar as políticas de compras e reduzir os riscos de gastos não autorizados.

Por que isso importa

Mede diretamente o KPI 'Taxa de conformidade das aprovações de pedidos de compra' e destaca violações críticas de controles internos, como pedidos enviados aos fornecedores antes da aprovação.

Onde encontrar

Campo calculado. Definido como 'verdadeiro' se o timestamp de 'Pedido de compra aprovado' for anterior ou igual ao timestamp de 'Pedido de compra enviado ao fornecedor'.

Exemplos
truefalse
Categoria de compra
PurchaseCategory
Classificação das mercadorias ou dos serviços comprados, como 'Equipamentos de TI' ou 'Materiais de escritório'.
Descrição

Esse atributo classifica os itens do pedido de compra em uma hierarquia de compras. Essa classificação é usada na análise de gastos e na gestão de fornecedores.

Em Process Mining, segmentar o processo por categoria de compra pode revelar diferenças de comportamento ou de performance. Por exemplo, o processo de aprovação de despesas de capital pode levar mais tempo do que o de materiais operacionais. Esse atributo dá suporte direto ao Dashboard 'Taxa e motivos de devolução de mercadorias', permitindo analisar quais categorias são devolvidas com mais frequência.

Por que isso importa

Permite analisar o processo por tipo de gasto e identificar diferenças nos caminhos do processo, nos gargalos ou nas taxas de devolução entre categorias de mercadorias.

Onde encontrar

Vinculado de PO_LINES_ALL.CATEGORY_ID à visualização EGP_CATEGORIES_VL.

Exemplos
TI.Hardware.LaptopsEscritório.Materiais.PapelariaServiços.Profissionais.Consultoria
É entrega atrasada
IsLateDelivery
Indica se o recebimento final das mercadorias ocorreu após a data de entrega solicitada.
Descrição

Este atributo booleano calculado é verdadeiro quando o timestamp da atividade 'Mercadorias recebidas' é posterior ao valor do atributo 'Data de entrega solicitada' para determinado pedido de compra.

Essa sinalização é a base do KPI 'Taxa de entregas no prazo'. Ela facilita a segmentação e a análise de pedidos atrasados e entregues no prazo, ajudando a investigar as causas raiz dos atrasos, sejam elas relacionadas a fornecedores, locais ou categorias de produtos específicos.

Por que isso importa

Dá suporte direto ao KPI 'Taxa de entregas no prazo', permitindo analisar com clareza o desempenho dos fornecedores e a confiabilidade das entregas.

Onde encontrar

Campo calculado. Definido como 'verdadeiro' se o timestamp da atividade 'Mercadorias recebidas' for posterior ao atributo 'RequestedDeliveryDate'.

Exemplos
truefalse
É retrabalho
IsRework
Indica se o pedido de compra foi alterado após a criação inicial.
Descrição

Este é um atributo booleano calculado, definido como verdadeiro quando um caso de pedido de compra contém a atividade 'Pedido de compra alterado'. Ele ajuda a identificar rapidamente pedidos que precisaram de correções ou alterações.

Essa sinalização simplifica o cálculo do KPI 'Taxa de alteração de pedidos de compra' e facilita a filtragem e a análise de pedidos retrabalhados. Entender as características desses pedidos, como os fornecedores ou departamentos envolvidos, pode ajudar a identificar as causas raiz de dados imprecisos ou de mudanças nos requisitos.

Por que isso importa

Dá suporte direto ao KPI 'Taxa de alteração de pedidos de compra' e simplifica a análise da instabilidade do processo, sinalizando todos os pedidos que passaram por alterações.

Onde encontrar

Campo calculado. Definido como 'verdadeiro' se o Event Log de um caso contiver a atividade 'Pedido de compra alterado'; caso contrário, como 'falso'.

Exemplos
truefalse
Local de entrega
DeliveryLocation
Local físico ou endereço para onde as mercadorias devem ser entregues.
Descrição

Esse atributo especifica o endereço de entrega dos itens do pedido de compra. É uma informação logística importante.

Em Process Mining, analisar os dados por local de entrega dá suporte ao Dashboard 'Eficiência do processamento de recebimentos de mercadorias'. Isso ajuda a identificar se determinados armazéns ou unidades demoram mais para receber as mercadorias, indicando possíveis problemas de recursos ou de processo nesses locais.

Por que isso importa

Permite analisar a performance por localização geográfica e identificar gargalos regionais ou específicos de cada unidade no processo de recebimento de mercadorias.

Onde encontrar

Vinculado de PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID à visualização HR_LOCATIONS_ALL.

Exemplos
Armazém principal - Doca APrédio 3 - RecepçãoEscritório de São Francisco - 10º andar
Requisição de compra
PurchaseRequisitionNumber
Identificador da requisição de compra que antecedeu e autorizou o pedido de compra.
Descrição

A requisição de compra é o documento interno usado para solicitar a compra de mercadorias ou serviços. Esse atributo vincula o pedido de compra à solicitação que o originou.

Incluir o número da requisição permite analisar o processo de compras de forma mais ampla, desde a solicitação inicial, e não apenas a partir do pedido de compra. Isso ajuda a analisar o tempo de ciclo entre a solicitação e o pedido e a entender como os detalhes da requisição influenciam as etapas seguintes do processo.

Por que isso importa

Vincula o pedido de compra à solicitação inicial e permite ter uma visão mais completa do processo de ponta a ponta, da requisição ao pagamento.

Onde encontrar

Vinculado por meio da tabela PO_DISTRIBUTIONS_ALL, que contém REQ_DISTRIBUTION_ID e permite rastrear os dados até a tabela POR_REQUISITION_LINES_ALL.

Exemplos
PR-2023-05-001PR-2023-05-002PR-2023-05-003
Sistema de origem
SourceSystem
Sistema de informação do qual esses dados foram extraídos.
Descrição

Esse atributo identifica a origem dos dados, o que é especialmente útil em ambientes com vários sistemas integrados. Para esse processo, o valor normalmente seria 'Oracle Fusion Financials'.

Embora muitas vezes seja um valor estático para determinado conjunto de dados, ele é essencial para a governança de dados, a solução de problemas e a garantia da linhagem dos dados. Em análises que combinam dados de várias fontes, permite filtrar e segmentar por sistema de origem.

Por que isso importa

Identifica a origem dos dados, essencial para a governança de dados, o contexto e a integração com outros sistemas.

Onde encontrar

Normalmente, é um valor constante definido e adicionado durante o processo de extração e transformação de dados (ETL).

Exemplos
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
Status do pedido de compra
PurchaseOrderStatus
Status atual do documento de pedido de compra.
Descrição

Esse atributo indica o estado atual do pedido de compra no ciclo de vida, como 'Aberto', 'Aprovado', 'Encerrado definitivamente' ou 'Cancelado'. Ele mostra o andamento do pedido naquele momento.

Embora Process Mining se concentre na sequência de atividades, o status atual é útil para filtrar os casos. Por exemplo, a análise pode se concentrar apenas nos pedidos abertos para entender o fluxo atual ou nos pedidos encerrados para analisar instâncias concluídas do processo. Esse atributo é essencial para o Dashboard 'Fluxo e status dos pedidos de compra'.

Por que isso importa

Mostra o estado atual do pedido de compra e permite filtrar a análise por pedidos ativos, concluídos ou cancelados.

Onde encontrar

Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, colunas AUTHORIZATION_STATUS ou DOCUMENT_STATUS.

Exemplos
OPENAPPROVEDFINALLY_CLOSEDCANCELED
Tipo de pedido de compra
PurchaseOrderType
Tipo de pedido de compra, como 'Padrão', 'Aberto' ou 'Contrato'.
Descrição

Esse atributo classifica o pedido de compra de acordo com sua finalidade. Diferentes tipos de pedidos costumam seguir regras e ciclos de vida distintos.

Um pedido 'Padrão' é uma compra única, enquanto um pedido 'Aberto' é um acordo de longo prazo com um fornecedor. Analisar o processo por tipo de pedido de compra permite avaliar a performance com mais precisão, pois comparar o tempo de ciclo de um pedido padrão com o de um acordo aberto pode levar a conclusões equivocadas. Assim, é possível comparar pedidos semelhantes.

Por que isso importa

Diferencia os vários cenários de compra e permite comparar com mais precisão a performance do processo entre pedidos do mesmo tipo.

Onde encontrar

Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, coluna TYPE_LOOKUP_CODE.

Exemplos
STANDARDBLANKETCONTRACT
Última atualização dos dados
LastDataUpdate
Data e hora da última extração ou atualização dos dados do sistema de origem.
Descrição

Esse atributo indica o grau de atualização dos dados analisados. Ele registra a data e a hora da extração mais recente do Oracle Fusion Financials.

Essa informação é essencial para que as pessoas entendam a atualidade da análise e dos Dashboards. Ela esclarece até que ponto os insights sobre o processo estão atualizados e ajuda a alinhar as expectativas sobre a inclusão de transações muito recentes.

Por que isso importa

Mostra com transparência o grau de atualização dos dados, para que você saiba quão atual é a análise do processo.

Onde encontrar

Essa data e hora são geradas e adicionadas durante o processo de extração e transformação de dados (ETL).

Exemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Unidade de negócio
BusinessUnitName
Unidade de negócio específica da organização que está realizando a compra.
Descrição

A unidade de negócio representa uma entidade distinta dentro da empresa, muitas vezes com seu próprio livro contábil e relatórios financeiros. No Oracle Fusion, é um dos principais mecanismos de segregação de dados.

Analisar a performance do processo por unidade de negócio é essencial em grandes empresas multinacionais. Isso permite comparar a eficiência das compras, a conformidade e os custos entre diferentes áreas da organização, destacando boas práticas e oportunidades de melhoria.

Por que isso importa

Essencial para que grandes organizações comparem a eficiência e a conformidade do processo entre diferentes divisões operacionais.

Onde encontrar

O contexto da unidade de negócio costuma estar no cabeçalho do pedido de compra, em PO_HEADERS_ALL.PRC_BU_ID, que se vincula à visualização FUN_ALL_BUSINESS_UNITS_V.

Exemplos
Unidade de negócio dos EUAVisão EMEAServiços APAC
Obrigatório Recomendado Opcional

Atividades de compras, do pedido ao pagamento

Estas são as principais etapas e os marcos do processo que devem ser registrados no Event Log para descobrir com precisão o processo de compras, do pedido ao pagamento.
6 Recomendado 10 Opcional
Atividade Descrição
Mercadorias recebidas
As mercadorias foram recebidas fisicamente, contadas e registradas no pedido de compra. Esse evento transacional atualiza o estoque e o status do pedido.
Por que isso importa

Esse é um marco importante para medir a performance de entrega no prazo dos fornecedores e o tempo de atravessamento total. Também dá início a atividades posteriores, como a inspeção de qualidade e a conciliação de faturas.

Onde encontrar

Esse evento explícito é registrado na tabela RCV_TRANSACTIONS. A transação específica pode ser identificada pelo valor 'RECEIVE' em TRANSACTION_TYPE.

Coleta

Use TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'RECEIVE'.

Tipo de evento explicit
Pedido de compra aprovado
O pedido de compra recebeu todas as aprovações necessárias e está autorizado para ser enviado ao fornecedor. Este é um marco importante, registrado explicitamente no histórico de ações do documento.
Por que isso importa

Este é um marco crítico que impede o envio do pedido de compra ao fornecedor até que a aprovação seja concluída. Ele é essencial para medir os tempos do ciclo de aprovação e garantir a conformidade com as políticas de gastos.

Onde encontrar

Este evento é registrado na tabela PO_ACTION_HISTORY, normalmente com ACTION_CODE igual a 'APPROVE', ou quando o status do documento na tabela PO_HEADERS_ALL muda para aprovado.

Coleta

Filtre PO_ACTION_HISTORY pela ação final 'APPROVE'.

Tipo de evento explicit
Pedido de compra cancelado
O pedido de compra foi cancelado definitivamente e não são esperadas novas transações. Essa ação explícita altera o status final do documento.
Por que isso importa

Essa atividade representa um estado final negativo do processo. Analisar os cancelamentos pode revelar problemas como pedidos duplicados, mudanças no orçamento ou alterações nos requisitos do projeto.

Onde encontrar

Essa ação é registrada na tabela PO_ACTION_HISTORY com o valor 'CANCEL' em ACTION_CODE, e o status do pedido em PO_HEADERS_ALL é atualizado de acordo.

Coleta

Filtre PO_ACTION_HISTORY por ACTION_CODE = 'CANCEL'.

Tipo de evento explicit
Pedido de compra criado
Este é o início oficial do ciclo de vida do pedido de compra, quando um documento de pedido de compra é gerado com status de rascunho ou incompleto. O sistema registra o evento com a data e hora de criação do novo registro de cabeçalho do pedido.
Por que isso importa

Como evento inicial principal do caso do pedido de compra, esta atividade é fundamental para todos os cálculos de tempo de ciclo. Ela serve de referência para medir a eficiência das etapas seguintes, como aprovação e comunicação com o fornecedor.

Onde encontrar

Este é um evento explícito, baseado no campo CREATION_DATE da tabela PO_HEADERS_ALL para um determinado ID do pedido de compra (PO_HEADER_ID).

Coleta

Use a data e hora de criação da tabela PO_HEADERS_ALL.

Tipo de evento explicit
Pedido de compra encerrado definitivamente
O pedido de compra é considerado concluído: foi recebido e/ou faturado integralmente, e não são esperadas novas atividades. Essa ação explícita define um status final para o pedido.
Por que isso importa

Essa atividade marca a conclusão bem-sucedida do ciclo de vida do pedido de compra. É o principal estado final positivo, e acompanhá-la é essencial para medir o volume total processado e as taxas de conclusão do processo.

Onde encontrar

Esse evento é registrado na tabela PO_ACTION_HISTORY com o valor 'FINALLY CLOSE' em ACTION_CODE. O status do pedido em PO_HEADERS_ALL também é atualizado para 'Finally Closed'.

Coleta

Filtre PO_ACTION_HISTORY por ACTION_CODE = 'FINALLY CLOSE'.

Tipo de evento explicit
Pedido de compra enviado ao fornecedor
O pedido de compra aprovado é enviado oficialmente ao fornecedor, por exemplo, por e-mail ou EDI. Muitas vezes, esse evento é inferido a partir de uma mudança de status ou de uma data e hora no registro de comunicação do pedido.
Por que isso importa

Este evento marca o início do prazo de entrega do fornecedor. É um ponto essencial para medir o desempenho do fornecedor, desde a confirmação até a entrega final.

Onde encontrar

Este evento pode ser inferido quando o status do documento do pedido de compra muda para 'Open' e uma data de comunicação é preenchida. O campo específico costuma ser PO_HEADERS_ALL.communicated_date ou um status relacionado.

Coleta

Infira o evento pela data e hora em que o status de comunicação do pedido de compra é atualizado para 'Communicated'.

Tipo de evento inferred
Entrega de serviços confirmada
Em pedidos de compra de serviços, essa atividade registra a confirmação de que os serviços foram prestados conforme o combinado. Essa confirmação costuma ser registrada manualmente ou por meio de uma folha de entrada de serviços.
Por que isso importa

Esse evento equivale ao recebimento de mercadorias no caso de serviços e é uma etapa essencial antes do pagamento de uma fatura. Atrasos na confirmação dos serviços podem levar a pagamentos fora do prazo e prejudicar o relacionamento com os fornecedores.

Onde encontrar

Esse evento costuma ser registrado como um recebimento vinculado a uma linha de serviço do pedido de compra. Ele pode envolver campos específicos ou recebimentos complexos que acompanham o andamento ou a conclusão dos serviços.

Coleta

Identifique as transações de recebimento (RCV_TRANSACTIONS) vinculadas às linhas de pedidos de compra de serviços.

Tipo de evento explicit
Inspeção de qualidade realizada
As mercadorias que exigem controle de qualidade foram inspecionadas e aceitas ou rejeitadas. Essa atividade ocorre após o recebimento inicial e é registrada como uma transação distinta.
Por que isso importa

Essa atividade é essencial para a gestão da qualidade. Analisar a duração das inspeções ajuda a agilizar o processo de controle de qualidade e reduzir atrasos na liberação das mercadorias para uso.

Onde encontrar

Esse evento é registrado na tabela RCV_TRANSACTIONS. Ele é identificado por transações com o valor 'ACCEPT' ou 'REJECT' em TRANSACTION_TYPE, realizadas após uma transação de recebimento.

Coleta

Use TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'ACCEPT' ou 'REJECT'.

Tipo de evento explicit
Mercadorias devolvidas ao fornecedor
Mercadorias recebidas anteriormente são devolvidas ao fornecedor, geralmente por defeitos, danos ou envio incorreto. Essa ocorrência é registrada como uma transação específica de devolução no módulo de recebimento.
Por que isso importa

Acompanhar as devoluções é essencial para avaliar a qualidade dos fornecedores e a precisão dos pedidos. Uma taxa alta de devoluções para um fornecedor pode indicar problemas recorrentes que precisam ser resolvidos.

Onde encontrar

Esse evento explícito é registrado na tabela RCV_TRANSACTIONS com o valor 'RETURN TO VENDOR' em TRANSACTION_TYPE.

Coleta

Use TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'RETURN TO VENDOR'.

Tipo de evento explicit
Pedido de compra alterado
O pedido de compra foi alterado após a aprovação inicial, por exemplo, com mudanças na quantidade, no preço ou na data de entrega. O Oracle Fusion registra a alteração criando uma nova revisão do documento.
Por que isso importa

Alterações no pedido de compra representam retrabalho e podem indicar problemas na precisão do pedido inicial ou mudanças nas necessidades do negócio. Analisar a frequência e a natureza dessas alterações ajuda a identificar oportunidades para melhorar a eficiência do processo.

Onde encontrar

Esse evento é registrado explicitamente quando uma nova revisão do documento é criada. Ele pode ser identificado pelo aumento do campo REVISION_NUM na tabela PO_HEADERS_ALL.

Coleta

Identifique cada ocorrência em que o valor de REVISION_NUM aumenta para um PO_HEADER_ID.

Tipo de evento explicit
Pedido de compra confirmado pelo fornecedor
O fornecedor confirmou o recebimento do pedido de compra e aceitou seus termos. Muitas vezes, a equipe de compras registra esse evento manualmente com base na comunicação do fornecedor ou por meio de uma confirmação eletrônica.
Por que isso importa

A confirmação do fornecedor dá a certeza de que o pedido foi recebido e está sendo processado. Acompanhar essa etapa ajuda a gerenciar a comunicação com o fornecedor e identificar proativamente possíveis problemas no atendimento do pedido.

Onde encontrar

Em geral, este evento é inferido a partir de uma mudança nos campos de status de confirmação do cabeçalho ou das linhas do pedido de compra, como quando PO_HEADERS_ALL.acceptance_status muda para 'Accepted'.

Coleta

Infira o evento a partir das atualizações nos campos de status de confirmação do pedido de compra.

Tipo de evento inferred
Pedido de compra enviado para aprovação
O pedido de compra criado é enviado ao fluxo de aprovação. O Oracle Fusion registra explicitamente essa ação, incluindo o usuário e a data e hora do envio.
Por que isso importa

Esta atividade marca o início do ciclo de aprovação. Analisar o tempo entre o envio e a aprovação é essencial para identificar gargalos no processo interno de aprovação.

Onde encontrar

Esta ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE igual a 'SUBMIT' para o PO_HEADER_ID correspondente.

Coleta

Filtre PO_ACTION_HISTORY por ACTION_CODE = 'SUBMIT'.

Tipo de evento explicit
Pedido de compra rejeitado
Uma pessoa aprovadora rejeitou o pedido de compra e o devolveu para quem o criou fazer as alterações necessárias. Este evento explícito é registrado no histórico de ações e indica uma interrupção no fluxo padrão do processo.
Por que isso importa

As rejeições geram retrabalho e atrasos no processo. Acompanhar esta atividade ajuda a identificar motivos recorrentes para rejeições, necessidades de treinamento ou requisitos de aprovação pouco claros.

Onde encontrar

Esta ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE igual a 'REJECT' para o PO_HEADER_ID correspondente.

Coleta

Filtre PO_ACTION_HISTORY por ACTION_CODE = 'REJECT'.

Tipo de evento explicit
Recebimento de mercadorias criado
Um documento de recebimento é iniciado no sistema para preparar a chegada física das mercadorias. Essa atividade marca o início do processo interno de recebimento.
Por que isso importa

Esse evento marca a transição de compras para logística. Analisar o tempo entre esse ponto e o registro final do recebimento ajuda a identificar ineficiências no armazém ou no departamento de recebimento.

Onde encontrar

Esse evento explícito é registrado pela data e hora de criação de um novo registro na tabela RCV_SHIPMENT_HEADERS vinculado ao pedido de compra.

Coleta

Use a data de criação do registro correspondente em RCV_SHIPMENT_HEADERS.

Tipo de evento explicit
Requisição de compra aprovada
A autoridade designada aprovou a requisição de compra, autorizando a equipe de compras a criar um pedido de compra. Esse evento é registrado explicitamente no histórico de ações da requisição no sistema.
Por que isso importa

Este marco representa o fim do processo interno de aprovação da solicitação. Atrasos nesta etapa podem afetar diretamente todo o cronograma de compras, por isso é essencial monitorar sua duração.

Onde encontrar

Este evento é registrado no histórico de ações associado à requisição e costuma ser acompanhado por meio de tabelas de fluxo de trabalho ou campos específicos de status de aprovação no documento da requisição.

Coleta

Registrado como uma ação de aprovação no histórico do fluxo de trabalho do documento de requisição correspondente.

Tipo de evento explicit
Requisição de compra criada
Esta atividade registra a criação de uma requisição de compra, o pedido formal de mercadorias ou serviços que antecede um pedido de compra. O evento é registrado quando uma nova entrada é criada na tabela de cabeçalho de requisições do Oracle Fusion.
Por que isso importa

A análise desta atividade ajuda a entender a etapa em que a demanda se origina. Acompanhar o tempo entre a criação da requisição e a do pedido de compra revela possíveis atrasos na conversão da demanda interna em pedidos de compra acionáveis.

Onde encontrar

Este é um evento explícito, registrado quando uma nova requisição é salva. Ele pode ser identificado pelo acompanhamento da data e hora de criação na tabela POR_REQUISITION_HEADERS_ALL.

Coleta

O evento se baseia na data de criação do registro na tabela POR_REQUISITION_HEADERS_ALL.

Tipo de evento explicit
Recomendado Opcional

Guias de extração

Como obter seus dados do Oracle Fusion Financials

Pronto para começar?

Use este Template para simplificar a coleta de dados e começar a descobrir insights sobre seu processo de compras, do pedido ao pagamento. Comece a otimizar suas operações hoje.

Otimize hoje seu processo de compras, do pedido ao pagamento

Identifique gargalos que geram custos e reduza o tempo de ciclo em 30% com facilidade.

Começar o teste grátis

Não é necessário informar o cartão de crédito. Comece a otimizar hoje.