Seu Template de dados de compras, do pedido ao pagamento
Seu Template de dados de compras, do pedido ao pagamento
- 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
Atributos de compras, do pedido ao pagamento
| 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
|
|||
Atividades de compras, do pedido ao pagamento
| 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
|
|||
Guias de extração
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.
Não é necessário informar o cartão de crédito. Comece a otimizar hoje.