Template de Dados: Procure to Pay - Pedido de Compra
Seu Template de dados de Compra a Pagamento - Pedido de Compra
- Atributos recomendados para uma coleta de dados completa
- Principais atividades do processo para acompanhar e analisar
- Guia passo a passo de extração no Oracle Fusion Financials
Compra a Pagamento - Atributos do Pedido de Compra
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome de um evento de negócio ou de uma etapa específica que ocorreu no ciclo de vida do Pedido de Compra (PO). | ||
|
Descrição
Esse atributo descreve uma tarefa específica ou mudança de status no processo, como 'Purchase Order Created' ou 'Goods Received'. Essas atividades compõem a sequência de eventos que formam o fluxo do processo. Analisar a sequência e os tempos dessas atividades é o coração do 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 é importante
As atividades são a base do mapa do processo. Acompanhá-las permite visualizar e analisar o fluxo do processo, seus gargalos e desvios.
Onde obter
Derivado de alterações de status em tabelas como PO_HEADERS_ALL e PO_ACTION_HISTORY, ou em tabelas de transação específicas, como RCV_TRANSACTIONS, para recebimento de mercadorias.
Exemplos
Pedido de compra criadoPedido de compra aprovadoMercadorias Recebidas
|
|||
|
Hora de Início
EventTime
|
O timestamp que indica quando uma atividade ou evento específico ocorreu. | ||
|
Descrição
Este atributo registra a data e hora exatas de cada atividade do processo. É fundamental para a ordenação cronológica dos eventos e para todas as análises baseadas em tempo. No Process Mining, a data/hora de início é usada para construir o Event Log, calcular o tempo de ciclo entre atividades, medir tempos de espera e analisar a performance do processo em diferentes períodos. É essencial para dashboards relacionados a tempo de ciclo e performance.
Por que é importante
Este timestamp é crítico para sequenciar os eventos corretamente e calcular todas as métricas baseadas em duração, como tempos de ciclo e gargalos.
Onde obter
Campos de timestamp como CREATION_DATE e LAST_UPDATE_DATE de 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
|
O identificador único da PO, que funciona como o ID do caso principal para acompanhar o ciclo de compras. | ||
|
Descrição
O número do Pedido de Compra (PO) é o identificador central que conecta todas as atividades, da criação ao encerramento. Ele permite analisar, de ponta a ponta, um único caso de compras. Em Process Mining, cada número único de PO representa uma instância do processo. Analisar os dados agrupados por esse identificador ajuda a entender variações do processo, tempos de ciclo e conformidade de cada pedido.
Por que é importante
Este é o Case ID essencial que conecta todos os eventos relacionados, permitindo reconstruir e analisar todo o ciclo de vida do Pedido de Compra (PO).
Onde obter
Oracle Fusion Cloud SCM, módulo Procurement, tabela PO_HEADERS_ALL, coluna SEGMENT1.
Exemplos
100234510023461002347
|
|||
|
Data de entrega solicitada
RequestedDeliveryDate
|
A data em que o solicitante espera receber os bens ou serviços. | ||
|
Descrição
Essa data é informada na linha do pedido de compra e comunica ao fornecedor o prazo desejado de entrega. Ela serve como referência para medir o desempenho de entrega no prazo. Este atributo é crítico 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 conseguem medir e acompanhar quantitativamente a confiabilidade dos fornecedores e identificar atrasos sistêmicos na cadeia de suprimentos.
Por que é importante
Serve como base para medir o desempenho de entrega no prazo, um KPI-chave para avaliar a confiabilidade do fornecedor e a eficiência da cadeia de suprimentos.
Onde obter
No nível de localização da linha, na tabela PO_LINE_LOCATIONS_ALL, coluna NEED_BY_DATE.
Exemplos
2023-05-202023-06-152023-07-01
|
|||
|
Departamento
DepartmentName
|
O nome do departamento que iniciou ou é responsável pelo Pedido de Compra (PO). | ||
|
Descrição
Este atributo especifica a unidade organizacional associada à compra, como 'Finance', 'IT' ou 'Manufacturing'. É usado para rateio de custos e para relatórios gerenciais. No contexto de Process Mining, segmentar o processo por departamento é crucial para comparar desempenho, identificar gargalos específicos de cada área e entender variações na execução do processo na organização. Dá suporte direto a dashboards como 'Análise do Tempo de Ciclo de Aprovação de PO' e 'Tendências de Modificações em Pedidos de Compra'.
Por que é importante
Permite filtrar e comparar a performance do processo entre unidades de negócio, revelando problemas específicos de cada área ou boas práticas.
Onde obter
Derivado das informações do centro de custo em tabelas como PO_DISTRIBUTIONS_ALL, que se vinculam aos dados mestres de departamentos.
Exemplos
Operações de TIMarketingPesquisa e Desenvolvimento
|
|||
|
End Time
EndTime
|
A data e hora em que uma atividade foi concluída. Geralmente igual ao Start Time para eventos atômicos. | ||
|
Descrição
Para atividades que têm duração, indica o horário de conclusão. Para eventos instantâneos, normalmente é o mesmo da Hora de Início. É essencial para calcular o tempo de processamento de atividades individuais. Ter uma Hora de Término distinta permite uma análise mais precisa das durações das atividades, que podem ser diferentes do tempo de espera entre elas. Isso ajuda a diferenciar tempo de trabalho ativo de tempo ocioso, apoiando a análise de carga de trabalho e eficiência dos recursos.
Por que é importante
Permite calcular com precisão os tempos de processamento das atividades, essencial para avaliar a eficiência dos recursos e identificar tarefas que consomem mais tempo.
Onde obter
Pode ser igual ao horário de início para eventos atômicos ou derivado de timestamps de eventos subsequentes. Para algumas atividades, pode existir um timestamp de conclusão separado.
Exemplos
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
Nome do Aprovador
ApproverName
|
Nome do usuário que realizou uma ação de aprovação ou rejeição na PO. | ||
|
Descrição
Esse atributo registra quem é o responsável por uma etapa de aprovação no Workflow. Normalmente, essa informação fica em uma tabela de histórico de ações ou log de Workflow associada à PO. Analisar os dados por aprovador é fundamental para os dashboards 'PO Approval Cycle Time Analysis' e 'Approval Resource Workload'. Isso ajuda a identificar quais aprovadores ou grupos de aprovação são gargalos, permite avaliar a carga de trabalho de forma justa e aponta oportunidades de delegação ou redesenho do processo.
Por que é importante
Identifica as pessoas na cadeia de aprovação, possibilitando analisar gargalos de aprovação, carga de trabalho e tempos de ciclo por aprovador.
Onde obter
O usuário que executou a ação, disponível em PO_ACTION_HISTORY.ACTION_PERFORMED_BY, vinculado a uma tabela de usuários para o nome completo.
Exemplos
susan.managerdavid.directoremily.finance
|
|||
|
Nome do Fornecedor
VendorName
|
Nome do fornecedor de quem os bens ou serviços estão sendo adquiridos. | ||
|
Descrição
Esse atributo identifica o fornecedor externo da PO. É um dado mestre crítico vinculado ao cabeçalho da PO. A análise por fornecedor é parte central do Process Mining em P2P. Ao filtrar ou segmentar por fornecedor, as empresas podem analisar 'Vendor Delivery Performance', comparar taxas de entrega no prazo e investigar 'Goods Return Rate' para identificar fornecedores com melhor ou pior desempenho. Esses dados são essenciais para a gestão de relacionamento com fornecedores e para o sourcing estratégico.
Por que é importante
Essencial para a análise de desempenho de fornecedores, possibilitando comparar prazos de entrega, taxas de devolução e confiabilidade geral entre fornecedores.
Onde obter
Vinculado de PO_HEADERS_ALL.VENDOR_ID a POZ_SUPPLIERS.VENDOR_NAME.
Exemplos
Suprimentos de Escritório GlobaisTech Solutions Inc.Advanced Logistics Co.
|
|||
|
Utilizador
UserName
|
O ID do usuário ou nome da pessoa que realizou a atividade. | ||
|
Descrição
Esse atributo identifica o colaborador ou usuário do sistema responsável por um determinado evento, como criar uma requisição, aprovar uma PO ou registrar um recebimento de mercadorias. Normalmente vem de campos como 'Created By' ou 'Last Updated By'. Analisar o processo por usuário ajuda a entender a distribuição de trabalho, o desempenho individual e a identificar necessidades de treinamento. É fundamental para o dashboard 'Approval Resource Workload' e para investigar questões de conformidade relacionadas a ações de usuários.
Por que é importante
Atribui ações de usuários a pessoas específicas, permitindo análise de carga de trabalho, avaliação de performance e identificação de oportunidades de treinamento.
Onde obter
Relacione às tabelas de usuários pelos IDs em 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
|
O valor total da PO. | ||
|
Descrição
Este atributo representa o custo total de todos os itens do Pedido de Compra na moeda especificada. É uma métrica financeira essencial para entender o valor das transações que percorrem o processo. Analisar o Valor Total do PO ajuda a priorizar iniciativas de melhoria do processo. Por exemplo, pedidos de alto valor podem seguir um fluxo de aprovação mais rigoroso. Também possibilita análises de impacto financeiro, como calcular o valor de POs frequentemente modificados ou atrasados.
Por que é importante
Traz contexto financeiro ao processo, permitindo análises por valor monetário, como priorizar pedidos de alto valor ou entender os impactos financeiros de atrasos.
Onde obter
Calculado somando os valores da tabela PO_LINES_ALL para um determinado cabeçalho do Pedido de Compra, ou obtido de um total no nível de cabeçalho, quando disponível.
Exemplos
5250.00120000.50750.99
|
|||
|
Aprovação em conformidade
IsApprovalCompliant
|
Um indicador que mostra se o Pedido de Compra foi aprovado antes de ser enviado ao fornecedor. | ||
|
Descrição
Este é um atributo booleano calculado que verifica a conformidade com um controle interno crítico: um Pedido de Compra (PO) deve ser aprovado antes de ser enviado ao fornecedor. O valor é verdadeiro quando a atividade 'Purchase Order Approved' ocorre antes da atividade 'Purchase Order Sent to Vendor'. Este atributo é essencial para o dashboard 'PO Process Compliance Audit' e para o KPI 'PO Approval Compliance Rate'. Ele oferece uma forma direta de identificar e quantificar violações de conformidade, ajudando a reforçar as políticas de compras e a mitigar riscos de gastos não autorizados.
Por que é importante
Mede diretamente o KPI 'Taxa de Conformidade de Aprovação de PO', destacando violações críticas de controle interno, quando pedidos são enviados aos fornecedores antes da aprovação.
Onde obter
Campo calculado. Definido como 'true' se o timestamp de 'Purchase Order Approved' for menor ou igual ao timestamp de 'Purchase Order Sent to Vendor'.
Exemplos
verdadeirofalse
|
|||
|
Categoria de compra
PurchaseCategory
|
A classificação dos bens ou serviços comprados, como 'Hardware de TI' ou 'Materiais de escritório'. | ||
|
Descrição
Esse atributo categoriza os itens da PO em uma hierarquia de compras. Essa classificação é usada para análise de gastos e gestão de fornecedores. Em Process Mining, segmentar o processo por categoria de compra pode revelar comportamentos ou desempenhos diferentes. Por exemplo, o processo de aprovação para investimentos (CAPEX) pode ser mais longo do que para suprimentos operacionais. Ele dá suporte direto ao dashboard 'Goods Return Rate & Reasons', permitindo analisar quais categorias são devolvidas com maior frequência.
Por que é importante
Permite analisar o processo por tipo de despesa, revelando caminhos diferentes, gargalos ou taxas de devolução distintas por categoria de produto.
Onde obter
Vinculado de PO_LINES_ALL.CATEGORY_ID à view EGP_CATEGORIES_VL.
Exemplos
IT.Hardware.LaptopsOffice.Supplies.StationeryProfessional.Services.Consulting
|
|||
|
É Retrabalho
IsRework
|
Um indicador que mostra se o Pedido de Compra foi modificado após sua criação inicial. | ||
|
Descrição
Este é um atributo booleano calculado definido como verdadeiro quando um caso de PO contém a atividade 'Purchase Order Changed'. Ajuda a identificar rapidamente pedidos que exigiram correções ou ajustes. Esse indicador simplifica o cálculo do KPI 'PO Modification Rate' e permite filtrar e analisar com facilidade pedidos retrabalhados. Entender as características desses pedidos — como os fornecedores ou as áreas envolvidas — ajuda a apontar causas raiz de dados imprecisos ou de mudanças de requisitos.
Por que é importante
Dá suporte direto ao KPI 'Taxa de Modificação de PO' e simplifica a análise de instabilidade do processo ao sinalizar todos os pedidos que sofreram alterações.
Onde obter
Campo calculado. Definido como 'true' se o Event Log do caso contiver a atividade 'Purchase Order Changed'; caso contrário, 'false'.
Exemplos
verdadeirofalse
|
|||
|
Entrega atrasada
IsLateDelivery
|
Um indicador que mostra se o recebimento final ocorreu após a data de entrega solicitada. | ||
|
Descrição
Este atributo booleano calculado é verdadeiro quando o carimbo de data e hora da atividade 'Goods Received' é posterior ao valor do atributo 'Requested Delivery Date' para um determinado Pedido de Compra. Esse indicador é a base do KPI 'Taxa de Entrega no Prazo'. Ele permite segmentar e analisar com facilidade pedidos atrasados versus no prazo, ajudando a investigar as causas raiz dos atrasos, sejam elas relacionadas a fornecedores, locais ou categorias de produto.
Por que é importante
Dá suporte direto ao KPI 'Taxa de Entrega no Prazo', permitindo analisar com clareza o desempenho dos fornecedores e a confiabilidade das entregas.
Onde obter
Campo calculado. Definido como 'true' se o timestamp da atividade 'Goods Received' for posterior ao atributo 'RequestedDeliveryDate'.
Exemplos
verdadeirofalse
|
|||
|
Local de Entrega
DeliveryLocation
|
Local físico ou endereço onde os bens devem ser entregues. | ||
|
Descrição
Este atributo especifica o endereço de entrega (ship-to) dos itens do Pedido de Compra. É uma informação logística essencial. Para Process Mining, analisar por local de entrega dá suporte ao dashboard 'Eficiência do Processamento de Recebimento'. Isso ajuda a identificar se determinados armazéns ou unidades estão mais lentos no processo de recebimento, apontando possíveis problemas de recursos ou de processo em locais específicos.
Por que é importante
Permite analisar o desempenho por localização geográfica, ajudando a identificar gargalos regionais ou por local no processo de recebimento de mercadorias.
Onde obter
Vinculado de PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID à view HR_LOCATIONS_ALL.
Exemplos
Armazém Principal - Doca APrédio 3 - RecepçãoEscritório SF - 10º andar
|
|||
|
Requisição de compra
PurchaseRequisitionNumber
|
O identificador da requisição de compra que precedeu e autorizou o pedido de compra. | ||
|
Descrição
A Requisição de Compra é o documento interno usado para solicitar a aquisição de bens ou serviços. Esse atributo vincula a PO à solicitação que a originou. Incluir o número da requisição permite uma análise mais ampla do processo de compras, começando pela solicitação e não apenas pela PO. Isso ajuda a medir o tempo de ciclo da solicitação até o pedido e a entender como os detalhes da requisição impactam a fase seguinte da PO.
Por que é importante
Conecta o Pedido de Compra (PO) à solicitação inicial, permitindo uma visão ponta a ponta mais completa, da requisição ao pagamento.
Onde obter
Vinculado por meio da tabela PO_DISTRIBUTIONS_ALL, que contém REQ_DISTRIBUTION_ID, que remete à tabela POR_REQUISITION_LINES_ALL.
Exemplos
PR-2023-05-001PR-2023-05-002PR-2023-05-003
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema de informação do qual esses dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados, algo especialmente útil em ambientes com vários sistemas integrados. Para este processo, normalmente é 'Oracle Fusion Financials'. Embora muitas vezes seja um valor estático para um determinado conjunto de dados, é essencial para governança de dados, solução de problemas e garantir a linhagem dos dados. Em análises que combinam dados de múltiplas fontes, permite filtrar e segmentar pelo sistema de origem.
Por que é importante
Identifica a origem dos dados, o que é crucial para governança, contexto e integração com outros sistemas.
Onde obter
Normalmente é um valor constante definido e incluído 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
|
O status atual do documento de pedido de compra. | ||
|
Descrição
Este atributo indica o status atual do Pedido de Compra (PO) no seu ciclo de vida, como 'Open', 'Approved', 'Finally Closed' ou 'Canceled'. Ele oferece um retrato do andamento do PO. Embora o Process Mining se concentre na sequência de atividades, o status atual é valioso para filtrar casos. Por exemplo, é possível analisar apenas POs abertos para entender a carteira atual, ou POs encerrados para avaliar instâncias concluídas do processo. É essencial para o dashboard 'Fluxo e Status do Pedido de Compra'.
Por que é importante
Mostra a situação atual de um pedido de compra, permitindo filtrar a análise por pedidos ativos, concluídos ou cancelados.
Onde obter
Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, colunas AUTHORIZATION_STATUS ou DOCUMENT_STATUS.
Exemplos
OPENAPPROVEDFINALLY_CLOSEDCANCELED
|
|||
|
Tempo de Ciclo de Aprovação
ApprovalCycleTime
|
A duração desde a criação do pedido de compra até sua aprovação final. | ||
|
Descrição
Esta é uma métrica de duração calculada que mede o tempo entre a atividade 'Purchase Order Created' e a atividade 'Purchase Order Approved' para um único caso. Este atributo alimenta diretamente o KPI 'Average PO Approval Cycle Time'. Analisar sua distribuição ajuda a entender a eficiência do workflow de aprovação, identificar valores atípicos e medir o impacto de iniciativas de melhoria focadas em reduzir atrasos na aprovação.
Por que é importante
Quantifica o gargalo de aprovação, medindo diretamente o KPI 'Average PO Approval Cycle Time' e destacando atrasos no workflow.
Onde obter
Campo calculado. Diferença entre os timestamps das atividades 'Purchase Order Approved' e 'Purchase Order Created'.
Exemplos
P2DPT8H30MP5DT12H
|
|||
|
Tipo de Pedido de Compra
PurchaseOrderType
|
O tipo de PO, como 'Standard', 'Blanket' ou 'Contract'. | ||
|
Descrição
Esse atributo classifica a PO conforme a finalidade de compra. Diferentes tipos de PO costumam seguir regras e ciclos distintos. Uma PO 'Standard' é uma compra pontual, enquanto uma PO 'Blanket' é um acordo de longo prazo com um fornecedor. Analisar o processo por Tipo de PO oferece uma visão mais fiel do desempenho, pois comparar o tempo de ciclo de uma PO standard com um acordo blanket seria enganoso. Isso viabiliza comparações equivalentes.
Por que é importante
Diferencia cenários de compra distintos, permitindo comparações justas, em bases equivalentes, do desempenho do processo entre tipos de pedidos semelhantes.
Onde obter
Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, coluna TYPE_LOOKUP_CODE.
Exemplos
STANDARDBLANKETCONTRACT
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
A data e hora da última extração ou atualização dos dados a partir do sistema de origem. | ||
|
Descrição
Este atributo indica quão recentes são os dados analisados. Ele registra a data e a hora da extração mais recente do Oracle Fusion Financials. Essa informação é fundamental para o usuário entender quão atuais são a análise e os dashboards. Esclarece o quão atualizados estão os insights do processo e alinha expectativas sobre a inclusão de transações muito recentes.
Por que é importante
Garante transparência sobre a atualidade dos dados, deixando claro quão recente é a análise do processo.
Onde obter
Este é um timestamp gerado e incluído 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
|
A unidade de negócio da organização que está realizando a compra. | ||
|
Descrição
A Unidade de Negócio representa uma entidade de negócios distinta dentro da empresa, muitas vezes com seu próprio livro contábil e relatórios financeiros. É um dos principais mecanismos de segregação de dados no Oracle Fusion. Analisar o desempenho do processo por Unidade de Negócio é crucial em corporações grandes e multinacionais. Isso permite comparar eficiência de compras, conformidade e custos entre diferentes partes da organização, destacando boas práticas e áreas de melhoria.
Por que é importante
Crucial para organizações grandes compararem a eficiência e a conformidade do processo entre diferentes divisões operacionais.
Onde obter
O contexto da unidade de negócios normalmente está no cabeçalho do PO, PO_HEADERS_ALL.PRC_BU_ID, que referencia a view FUN_ALL_BUSINESS_UNITS_V.
Exemplos
Unidade de Negócio dos EUAEMEA VisionAPAC Services
|
|||
Compra a Pagamento - Atividades de Pedido de Compra
| Atividade | Descrição | ||
|---|---|---|---|
|
Mercadorias Recebidas
|
As mercadorias físicas foram recebidas, conferidas e registradas na PO. É um evento transacional que atualiza o estoque e o status da PO. | ||
|
Por que é importante
Marco-chave para medir a pontualidade de entrega do fornecedor e o lead time total. Também dispara atividades seguintes, como inspeção de qualidade e conciliação de fatura.
Onde obter
Evento explícito registrado na tabela RCV_TRANSACTIONS. A transação é identificada por TRANSACTION_TYPE igual a 'RECEIVE'.
Captura
Use o TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'RECEIVE'.
Tipo de evento
explicit
|
|||
|
Pedido de compra aprovado
|
A PO recebeu todas as aprovações necessárias e está autorizada para envio ao fornecedor. Esse é um marco importante, registrado explicitamente no histórico de ações do documento. | ||
|
Por que é importante
Este é um marco crítico que condiciona o envio do PO ao fornecedor. É essencial para medir o tempo de ciclo de aprovação e garantir conformidade com as políticas de gastos.
Onde obter
Esse evento é registrado na tabela PO_ACTION_HISTORY, normalmente com ACTION_CODE 'APPROVE' ou quando o status do documento na PO_HEADERS_ALL muda para um estado aprovado.
Captura
Filtre PO_ACTION_HISTORY pela ação final 'APPROVE'.
Tipo de evento
explicit
|
|||
|
Pedido de compra cancelado
|
A PO foi cancelada de forma definitiva e não são esperadas novas transações. É uma ação explícita que define o status final do documento. | ||
|
Por que é importante
Essa atividade representa um desfecho negativo do processo. Analisar cancelamentos pode revelar problemas como pedidos duplicados, alterações de orçamento ou mudanças nos requisitos do projeto.
Onde obter
Essa ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE 'CANCEL', e o status da PO em PO_HEADERS_ALL é atualizado em conformidade.
Captura
Filtre PO_ACTION_HISTORY com ACTION_CODE = 'CANCEL'.
Tipo de evento
explicit
|
|||
|
Pedido de compra criado
|
Este é o início oficial do ciclo de vida do Pedido de Compra (PO), quando um documento de PO é gerado em status de rascunho ou incompleto. O sistema captura esse evento registrando o timestamp de criação do novo registro de cabeçalho do PO. | ||
|
Por que é importante
Como evento inicial principal do caso de Pedido de Compra, esta atividade é fundamental para todos os cálculos de tempo de ciclo. Ela serve de base para medir a eficiência das etapas seguintes, como aprovação e comunicação com o fornecedor.
Onde obter
Este é um evento explícito baseado no campo CREATION_DATE da tabela PO_HEADERS_ALL para um determinado Purchase Order ID (PO_HEADER_ID).
Captura
Use o timestamp de criação da tabela PO_HEADERS_ALL.
Tipo de evento
explicit
|
|||
|
Pedido de compra encerrado em definitivo
|
A PO é considerada concluída quando foi totalmente recebida e/ou faturada, e não há mais atividades previstas. É uma ação explícita que define um status final na PO. | ||
|
Por que é importante
Essa atividade indica a conclusão bem-sucedida do ciclo de vida da PO. É o principal desfecho positivo, e acompanhá-la é essencial para medir o desempenho global do processo e as taxas de conclusão.
Onde obter
Esse evento é registrado na tabela PO_ACTION_HISTORY com ACTION_CODE 'FINALLY CLOSE'. O status do PO na PO_HEADERS_ALL também é atualizado para 'Finally Closed'.
Captura
Filtre PO_ACTION_HISTORY com ACTION_CODE = 'FINALLY CLOSE'.
Tipo de evento
explicit
|
|||
|
Pedido de compra enviado ao fornecedor
|
O pedido de compra aprovado é comunicado oficialmente ao fornecedor, por exemplo, por e-mail ou EDI. Esse evento geralmente é inferido por uma mudança de status ou pelo carimbo de data e hora no registro de comunicação do pedido. | ||
|
Por que é importante
Marca o início do lead time do fornecedor. É um ponto crucial para medir a performance do fornecedor, da confirmação até a entrega final.
Onde obter
Isso pode ser inferido quando o status do documento do PO muda para 'Open' e a data de comunicação é preenchida. O campo específico costuma ser PO_HEADERS_ALL.communicated_date ou por um status relacionado.
Captura
Identifique pelo timestamp o momento em que o status de comunicação do PO é atualizado para 'Communicated'.
Tipo de evento
inferred
|
|||
|
Inspeção de qualidade realizada
|
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 é importante
Essa atividade é crucial para a gestão da qualidade. Analisar a duração das inspeções ajuda a simplificar o processo de controle de qualidade e reduzir atrasos na disponibilização dos materiais para uso.
Onde obter
Registrado na tabela RCV_TRANSACTIONS. É identificado por transações com TRANSACTION_TYPE 'ACCEPT' ou 'REJECT' que ocorrem após a transação de recebimento.
Captura
Use o TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'ACCEPT' ou 'REJECT'.
Tipo de evento
explicit
|
|||
|
Mercadorias Devolvidas ao Fornecedor
|
Mercadorias já recebidas são devolvidas ao fornecedor, geralmente por defeitos, avarias ou envio incorreto. Isso é registrado como uma transação específica de devolução no módulo de recebimento. | ||
|
Por que é importante
Acompanhar devoluções é essencial para avaliar a qualidade do fornecedor e a acurácia dos pedidos. Taxas altas de devolução por fornecedor podem indicar problemas sistêmicos que precisam ser tratados.
Onde obter
Evento explícito registrado na tabela RCV_TRANSACTIONS com TRANSACTION_TYPE igual a 'RETURN TO VENDOR'.
Captura
Use o TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'RETURN TO VENDOR'.
Tipo de evento
explicit
|
|||
|
Pedido de compra alterado
|
Foi feita uma alteração no Pedido de Compra após a aprovação inicial, como mudança de quantidade, preço ou data de entrega. O Oracle Fusion registra isso criando uma nova revisão do documento. | ||
|
Por que é importante
Alterações em Pedidos 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 mudanças ajuda a identificar oportunidades para melhorar a eficiência do processo.
Onde obter
Esse evento é capturado explicitamente quando uma nova revisão do documento é criada. Isso pode ser identificado por um incremento no campo REVISION_NUM na tabela PO_HEADERS_ALL.
Captura
Identifique cada ocorrência em que o REVISION_NUM de um PO_HEADER_ID aumenta.
Tipo de evento
explicit
|
|||
|
Pedido de compra confirmado
|
O fornecedor confirmou o recebimento e a aceitação dos termos da PO. Esse evento costuma ser registrado manualmente pela equipe de Compras com base na comunicação do fornecedor ou por meio de uma confirmação eletrônica. | ||
|
Por que é importante
A confirmação do fornecedor dá certeza de que o pedido foi recebido e está sendo processado. Monitorar isso ajuda a organizar a comunicação com o fornecedor e a identificar, de forma proativa, possíveis problemas de atendimento.
Onde obter
Normalmente é inferido por uma mudança nos campos de status de confirmação no cabeçalho ou nas linhas do PO, como quando PO_HEADERS_ALL.acceptance_status muda para 'Accepted'.
Captura
Identifique por meio das atualizações nos campos de status de confirmação do PO.
Tipo de evento
inferred
|
|||
|
Pedido de compra enviado para aprovação
|
O pedido de compra criado é submetido ao workflow de aprovação. O Oracle Fusion registra explicitamente essa ação, capturando o usuário e o carimbo de data e hora do envio. | ||
|
Por que é importante
Essa atividade marca o início do ciclo de aprovações. Analisar o tempo entre o envio e a aprovação é fundamental para identificar gargalos no processo interno de aprovação.
Onde obter
Essa ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE 'SUBMIT' para o PO_HEADER_ID correspondente.
Captura
Filtre PO_ACTION_HISTORY com ACTION_CODE = 'SUBMIT'.
Tipo de evento
explicit
|
|||
|
Pedido de compra rejeitado
|
Um aprovador rejeitou o Pedido de Compra e o devolveu ao criador para revisão. Esse é um evento explícito registrado no histórico de ações, indicando uma quebra no fluxo padrão do processo. | ||
|
Por que é importante
Rejeições geram retrabalho e atrasos no processo. Acompanhar essa atividade ajuda a identificar motivos recorrentes de rejeição, necessidades de treinamento ou requisitos de aprovação pouco claros.
Onde obter
Essa ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE 'REJECT' para o PO_HEADER_ID correspondente.
Captura
Filtre PO_ACTION_HISTORY com ACTION_CODE = 'REJECT'.
Tipo de evento
explicit
|
|||
|
Recebimento de Mercadorias Criado
|
Um documento de recebimento é iniciado no sistema em preparação para a chegada física das mercadorias. Essa atividade marca o início do processo interno de recebimento. | ||
|
Por que é importante
Marca a transição de compras para logística. Analisar o tempo deste ponto até o lançamento definitivo do recebimento ajuda a identificar ineficiências no armazém ou na área de recebimento.
Onde obter
Evento explícito capturado pelo timestamp de criação de um novo registro na tabela RCV_SHIPMENT_HEADERS vinculada ao Pedido de Compra (PO).
Captura
Use a data de criação do registro correspondente em RCV_SHIPMENT_HEADERS.
Tipo de evento
explicit
|
|||
|
Requisição de compra aprovada
|
A Requisição de Compra (PR) foi aprovada pela autoridade designada, autorizando a área de Compras a criar um Pedido de Compra. Esse evento fica registrado explicitamente no histórico de ações da requisição. | ||
|
Por que é importante
Este marco indica o fim do processo interno de aprovação da solicitação. Atrasos aqui impactam diretamente todo o cronograma de compras; por isso, monitorar sua duração é fundamental.
Onde obter
Esse evento é registrado no histórico de ações associado à requisição, normalmente rastreado por tabelas de workflow ou por campos específicos de status de aprovação no documento da requisição.
Captura
Registrado como uma ação de aprovação no histórico do workflow do documento de requisição.
Tipo de evento
explicit
|
|||
|
Requisição de compra criada
|
Essa atividade marca a criação de uma Requisição de Compra, a solicitação formal de bens ou serviços que antecede o Pedido de Compra. Ela é capturada quando um novo registro é criado na tabela de cabeçalho de requisições no Oracle Fusion. | ||
|
Por que é importante
Analisar essa atividade ajuda a entender a fase em que a demanda surge. Medir o tempo da requisição até a criação do Pedido de Compra revela possíveis atrasos na conversão da demanda interna em pedidos de compra efetivos.
Onde obter
Evento explícito gerado ao salvar uma nova requisição. Pode ser localizado acompanhando o timestamp de criação na tabela POR_REQUISTION_HEADERS_ALL.
Captura
O evento é baseado na data de criação do registro na tabela POR_REQUISITION_HEADERS_ALL.
Tipo de evento
explicit
|
|||
|
Serviços entregues confirmados
|
Para pedidos de compra baseados em serviços, esta atividade marca a confirmação de que os serviços foram prestados conforme acordado. Essa confirmação costuma ser registrada manualmente ou por meio de um registro de entrada de serviço. | ||
|
Por que é importante
É o equivalente ao recebimento de mercadorias para serviços e uma etapa crítica antes que a fatura possa ser paga. Atrasos nessa confirmação podem gerar pagamentos em atraso e desgastar o relacionamento com o fornecedor.
Onde obter
Normalmente é capturado como um recebimento vinculado a uma linha de serviço do PO. Pode envolver campos específicos ou recebimentos complexos que acompanham o andamento ou a conclusão dos serviços.
Captura
Identifique transações de recebimento (RCV_TRANSACTIONS) vinculadas a linhas de PO baseadas em serviços.
Tipo de evento
explicit
|
|||