Seu Template de dados de compras ao pagamento: pedido de compra
Seu Template de dados de compras ao pagamento: pedido de compra
- 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
Purchase to Pay - Pedido de compra: atributos
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome de um evento ou etapa de negócio específico que ocorreu durante o ciclo de vida do Pedido de compra. | ||
|
Descrição
Este atributo descreve uma tarefa específica ou uma alteração de status no processo, como 'Pedido de compra criado' ou 'Produtos recebidos'. Essas atividades formam a sequência de eventos que compõe o fluxo do processo. Analisar a sequência e o momento dessas atividades é o núcleo 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 isso importa
As atividades são os blocos fundamentais do mapa do processo. Acompanhá-las permite visualizar e analisar o fluxo do processo, os gargalos e os desvios.
Onde obter
Derivada de alterações 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 produtos.
Exemplos
Pedido de compra criadoPedido de compra aprovadoProdutos recebidos
|
|||
|
Hora de início
EventTime
|
O carimbo de data e hora que indica quando uma atividade ou evento específico ocorreu. | ||
|
Descrição
Este atributo registra a data e a hora exatas de cada atividade no processo. Ele é fundamental para ordenar cronologicamente os eventos e realizar todas as análises baseadas em tempo. No Process Mining, a hora de início é usada para construir o Event Log, calcular os tempos de ciclo entre atividades, medir tempos de espera e analisar a performance do processo em diferentes períodos. Ela é essencial para Dashboards relacionados a tempo de ciclo e performance.
Por que isso importa
Este carimbo de data e hora é essencial para sequenciar corretamente os eventos e calcular todas as métricas baseadas em duração, como tempos de ciclo e gargalos.
Onde obter
Campos de carimbo de data e hora, 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 exclusivo do documento do Pedido de compra, usado como o principal ID do caso para acompanhar o ciclo de vida da aquisição. | ||
|
Descrição
O número do Pedido de compra é o identificador central que conecta todas as atividades relacionadas, desde a criação até o encerramento final. Ele permite analisar de ponta a ponta um único caso de aquisição. No Process Mining, cada número exclusivo de Pedido de compra representa uma única 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 isso importa
Este é o Case ID essencial que conecta todos os eventos relacionados, permitindo reconstruir e analisar todo o ciclo de vida do Pedido de compra.
Onde obter
Oracle Fusion Cloud SCM, módulo de compras, tabela PO_HEADERS_ALL, coluna SEGMENT1.
Exemplos
100234510023461002347
|
|||
|
Data de entrega solicitada
RequestedDeliveryDate
|
A data até a qual a parte solicitante espera que os produtos ou serviços sejam entregues. | ||
|
Descrição
Essa data é especificada na linha do pedido de compra e comunica ao fornecedor o prazo de entrega desejado. Ela serve como referência para medir a performance das entregas no prazo. Esse atributo é essencial para calcular o KPI “Taxa de entregas no prazo”. Comparando a data real do 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 isso importa
Serve como referência para medir a performance das entregas no prazo, um KPI importante para avaliar a confiabilidade dos fornecedores e a eficiência da cadeia de suprimentos.
Onde obter
Localizado no nível da 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. | ||
|
Descrição
Este atributo especifica a unidade organizacional, como 'Financeiro', 'TI' ou 'Manufatura', associada à compra. Ele é usado para alocação de custos e relatórios organizacionais. No contexto de 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 apoia diretamente Dashboards como 'PO Approval Cycle Time Analysis' e 'Purchase Order Modification Trends'.
Por que isso importa
Permite filtrar e comparar a performance do processo entre diferentes unidades de negócio, revelando problemas ou boas práticas específicos de cada departamento.
Onde obter
Derivado das informações do centro de custo em tabelas como PO_DISTRIBUTIONS_ALL, que se relaciona aos dados mestres dos departamentos.
Exemplos
Operações de TIMarketingPesquisa e desenvolvimento
|
|||
|
Hora de término
EndTime
|
O carimbo de data e hora em que uma atividade foi concluída. Em geral, é igual à hora de início para eventos atômicos. | ||
|
Descrição
Para atividades que têm duração, este campo indica o momento da conclusão. Para eventos instantâneos, normalmente é igual à hora de início. Ele é essencial para calcular o tempo de processamento de atividades individuais. Ter uma hora de término distinta permite analisar com mais precisão a duração das atividades, que pode ser diferente do tempo de espera entre atividades. Isso ajuda a diferenciar o tempo de trabalho ativo do tempo ocioso, apoiando a análise da carga de trabalho e da eficiência dos recursos.
Por que isso importa
Permite calcular com precisão os tempos de processamento das atividades, algo essencial para analisar a eficiência dos recursos e identificar tarefas que consomem muito tempo.
Onde obter
Pode ser igual à hora de início para eventos atômicos ou ser derivada dos carimbos de data e hora de eventos posteriores. Para algumas atividades, pode existir um carimbo de data e hora de conclusão separado.
Exemplos
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
Nome do aprovador
ApproverName
|
O nome do usuário que realizou uma ação de aprovação ou rejeição no pedido de compra. | ||
|
Descrição
Esse atributo identifica a pessoa responsável por uma etapa de aprovação no Workflow. Normalmente, essas informações são armazenadas em uma tabela de histórico de ações ou de registro do Workflow associada ao pedido de compra. Analisar os dados por aprovador é essencial para os Dashboards “Análise do tempo do ciclo de aprovação do pedido de compra” e “Carga de trabalho dos recursos de aprovação”. Isso ajuda a identificar quais aprovadores ou grupos de aprovação são gargalos, permite avaliar a carga de trabalho de forma justa e pode revelar oportunidades de delegação ou redesenho do processo.
Por que isso importa
Identifica as pessoas na cadeia de aprovação, permitindo analisar gargalos, carga de trabalho e tempos de ciclo de aprovação por aprovador.
Onde obter
O usuário que realizou a ação, encontrado 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
|
O nome do fornecedor de quem os produtos ou serviços estão sendo comprados. | ||
|
Descrição
Este atributo identifica o fornecedor externo do Pedido de compra. É um dado mestre essencial vinculado ao cabeçalho da PO. A análise de fornecedores é uma parte importante do Process Mining de P2P. Ao filtrar ou segmentar por fornecedor, as empresas conseguem analisar a 'Vendor Delivery Performance', comparar as taxas de entrega no prazo e investigar a 'Goods Return Rate' para identificar fornecedores com performance alta ou baixa. Esses dados são essenciais para gerenciar relacionamentos com fornecedores e o strategic sourcing.
Por que isso importa
Essencial para analisar a performance dos fornecedores, permitindo comparar tempos 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
Materiais de escritório globaisTech Solutions Inc.Advanced Logistics Co.
|
|||
|
Usuário
UserName
|
O ID ou nome do usuário que realizou a atividade. | ||
|
Descrição
Este atributo identifica o funcionário ou usuário do sistema responsável por um determinado evento, como criar uma requisição, aprovar uma PO ou registrar um recebimento de produtos. Normalmente, ele é obtido de campos como 'Created By' ou 'Last Updated By'. 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 'Approval Resource Workload' e para investigar problemas de Conformidade relacionados às ações dos usuários.
Por que isso importa
Relaciona 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 obter
Faça a junção com as tabelas de usuários com base nos 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 da PO
PurchaseOrderTotalAmount
|
O valor monetário total do Pedido de compra. | ||
|
Descrição
Este 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 da PO ajuda a priorizar os esforços 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 das POs que são alteradas ou atrasadas com frequência.
Por que isso importa
Fornece contexto financeiro ao processo, permitindo análises baseadas em valor monetário, como focar em pedidos de alto valor ou entender os impactos financeiros dos atrasos.
Onde obter
Calculado pela soma dos valores de PO_LINES_ALL para um determinado cabeçalho de PO ou obtido de um total no nível do cabeçalho, quando disponível.
Exemplos
5250.00120000.50750.99
|
|||
|
A aprovação está em conformidade
IsApprovalCompliant
|
Um indicador que mostra se o pedido de compra foi aprovado antes de ser enviado ao fornecedor. | ||
|
Descrição
Esse é um atributo booleano calculado que verifica a adesão a um controle interno essencial: um pedido de compra deve ser aprovado antes de ser enviado ao fornecedor. Ele recebe o valor true quando a atividade “Purchase Order Approved” ocorre antes da atividade “Purchase Order Sent to Vendor”. Esse atributo é essencial para o Dashboard “Auditoria da conformidade do processo de pedidos de compra” e para o KPI “Taxa de conformidade das aprovações de pedidos de compra”. Ele oferece uma forma simples de identificar e quantificar violações de conformidade, ajudando a aplicar as políticas de compras e reduzir os riscos associados a gastos não autorizados.
Por que isso importa
Mede diretamente o KPI “Taxa de conformidade das aprovações de pedidos de compra”, destacando violações críticas de controles internos em que os pedidos são enviados aos fornecedores antes da aprovação.
Onde obter
Campo calculado. Recebe o valor “true” quando o timestamp de “Purchase Order Approved” é menor ou igual ao timestamp de “Purchase Order Sent to Vendor”.
Exemplos
truefalse
|
|||
|
A entrega está atrasada
IsLateDelivery
|
Um indicador que mostra se o recebimento final das mercadorias ocorreu depois da data de entrega solicitada. | ||
|
Descrição
Esse atributo booleano calculado recebe o valor true quando o timestamp da atividade “Goods Received” é posterior ao valor do atributo “Requested Delivery Date” para determinado pedido de compra. Esse indicador é a base do KPI “Taxa de entregas no prazo”. Ele permite segmentar e analisar facilmente pedidos atrasados e pedidos entregues no prazo, ajudando a investigar as causas-raiz dos atrasos, estejam 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 a performance dos fornecedores e a confiabilidade das entregas.
Onde obter
Campo calculado. Recebe o valor “true” quando o timestamp da atividade “Goods Received” é posterior ao atributo “RequestedDeliveryDate”.
Exemplos
truefalse
|
|||
|
Categoria de compra
PurchaseCategory
|
A classificação dos bens ou serviços adquiridos, como “Hardware de TI” ou “Materiais de escritório”. | ||
|
Descrição
Esse atributo categoriza 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. No Process Mining, segmentar o processo por categoria de compra pode revelar comportamentos ou níveis de performance diferentes. Por exemplo, o processo de aprovação de despesas de capital pode ser mais longo que o de materiais operacionais. Esse atributo também 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, revelando diferentes caminhos do processo, gargalos ou taxas de devolução entre as categorias de bens.
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 depois da criação inicial. | ||
|
Descrição
Esse é um atributo booleano calculado que recebe o valor true quando o caso do pedido de compra contém a atividade “Purchase Order Changed”. Ele ajuda a identificar rapidamente os pedidos que exigiram correções ou modificações. Esse indicador simplifica o cálculo do KPI “Taxa de modificações 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 modificações de pedidos de compra” e simplifica a análise da instabilidade do processo ao sinalizar todos os pedidos que passaram por alterações.
Onde obter
Campo calculado. Recebe o valor “true” quando o Event Log de um caso contém a atividade “Purchase Order Changed”; caso contrário, recebe “false”.
Exemplos
truefalse
|
|||
|
Local de entrega
DeliveryLocation
|
O local físico ou endereço onde os bens devem ser entregues. | ||
|
Descrição
Esse atributo especifica o endereço de entrega dos itens do pedido de compra. É uma informação logística essencial. No Process Mining, analisar os dados por local de entrega dá suporte ao Dashboard “Eficiência do processamento do recebimento de mercadorias”. Isso ajuda a identificar se determinados armazéns ou unidades estão mais lentos no recebimento, apontando possíveis problemas de recursos ou de processo em locais específicos.
Por que isso importa
Permite analisar a performance por localização geográfica, ajudando a identificar gargalos regionais ou específicos de cada unidade 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 de São Francisco - 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 o pedido de compra à solicitação de origem. Incluir o número da requisição permite uma análise mais ampla do processo de compras, começando pela solicitação inicial, em vez de considerar apenas o 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 o processo posterior do pedido de compra.
Por que isso importa
Vincula o pedido de compra à solicitação inicial, permitindo uma visão mais abrangente do processo de ponta a ponta, da requisição ao pagamento.
Onde obter
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
|
O sistema de informação do qual estes dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados, o que é especialmente útil em ambientes com vários sistemas integrados. Para este processo, normalmente seria 'Oracle Fusion Financials'. Embora geralmente seja um valor estático para um 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, ele permite filtrar e segmentar os dados pelo sistema de origem.
Por que isso importa
Identifica a origem dos dados, algo essencial para a governança de dados, o contexto e a integração com outros sistemas.
Onde obter
Normalmente, este é 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 da PO
PurchaseOrderStatus
|
O status atual do documento do Pedido de compra. | ||
|
Descrição
Este atributo indica o estado atual do Pedido de compra em seu ciclo de vida, como 'Open', 'Approved', 'Finally Closed' ou 'Canceled'. Ele fornece uma visão instantânea do progresso da PO. Embora o Process Mining se concentre na sequência de atividades, o status atual é útil para filtrar casos. Por exemplo, a análise pode se concentrar apenas em POs abertas para entender o pipeline atual ou em POs encerradas para analisar instâncias de processo concluídas. Esse atributo é essencial para o Dashboard 'Purchase Order Flow & Status'.
Por que isso importa
Fornece uma visão atual do estado 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
ABERTOAPROVADOFECHADO_FINALMENTECANCELADO
|
|||
|
Tipo de pedido de compra
PurchaseOrderType
|
O tipo de pedido de compra, como “Padrão”, “Guarda-chuva” ou “Contrato”. | ||
|
Descrição
Esse atributo classifica o pedido de compra de acordo com sua finalidade de aquisição. Diferentes tipos de pedidos geralmente seguem regras e ciclos de vida distintos. Um pedido “Padrão” é uma compra pontual, enquanto um pedido “Guarda-chuva” é um acordo de longo prazo com um fornecedor. Analisar o processo por tipo de pedido de compra permite obter uma visão mais precisa da performance, pois comparar o tempo de ciclo de um pedido padrão com o de um acordo guarda-chuva seria enganoso. Assim, você consegue fazer comparações equivalentes.
Por que isso importa
Diferencia os diversos cenários de compras, permitindo comparações mais precisas, entre situações equivalentes, da performance do processo para tipos semelhantes de pedidos.
Onde obter
Oracle Fusion Cloud SCM, tabela PO_HEADERS_ALL, coluna TYPE_LOOKUP_CODE.
Exemplos
PADRÃOABRANGENTECONTRATO
|
|||
|
Última atualização dos dados
LastDataUpdate
|
O carimbo de data e hora em que os dados foram extraídos ou atualizados pela última vez a partir do sistema de origem. | ||
|
Descrição
Este atributo indica o nível de atualização dos dados analisados. Ele registra a data e a hora da extração mais recente de dados do Oracle Fusion Financials. Essas informações são essenciais para que os usuários entendam a atualidade da análise e dos Dashboards. Elas esclarecem o quanto os insights do processo estão atualizados e ajudam a gerenciar as expectativas sobre a inclusão de transações muito recentes.
Por que isso importa
Oferece transparência sobre a atualização dos dados, garantindo que os usuários entendam o quanto a análise do processo está atualizada.
Onde obter
Este é um carimbo de data e hora gerado e adicionado 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 específica da organização que está realizando a compra. | ||
|
Descrição
A unidade de negócio representa uma entidade distinta dentro da empresa, geralmente com seu próprio livro contábil e relatórios financeiros. No Oracle Fusion, ela é 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, a conformidade e os custos de compras entre diferentes áreas da organização, destacando boas práticas e oportunidades de melhoria.
Por que isso importa
É essencial para grandes organizações compararem a eficiência e a conformidade dos processos entre diferentes divisões operacionais.
Onde obter
O contexto da unidade de negócio normalmente fica no cabeçalho do pedido de compra, em PO_HEADERS_ALL.PRC_BU_ID, que se vincula à view FUN_ALL_BUSINESS_UNITS_V.
Exemplos
Unidade de negócios dos EUAVisão EMEAServiços APAC
|
|||
Purchase to Pay - Pedido de compra: atividades
| Atividade | Descrição | ||
|---|---|---|---|
|
Pedido de compra aprovado
|
O Pedido de compra recebeu todas as aprovações necessárias e agora 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 autoriza o envio da PO ao fornecedor. Ele é essencial para medir os tempos do ciclo de aprovação e garantir a Conformidade com as políticas de gastos.
Onde obter
Este evento é registrado na tabela PO_ACTION_HISTORY, normalmente com ACTION_CODE igual a 'APPROVE', ou quando o status do documento em 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
|
O Pedido de compra foi cancelado permanentemente e não são esperadas novas transações. Esta é uma ação explícita que altera o status final do documento. | ||
|
Por que isso importa
Esta atividade representa um estado final negativo do processo. Analisar os cancelamentos pode revelar problemas como pedidos duplicados, alterações no orçamento ou mudanças nos requisitos do projeto.
Onde obter
Esta ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE igual a 'CANCEL', e o status da PO em PO_HEADERS_ALL é atualizado de acordo.
Captura
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 PO é gerado com status de rascunho ou incompleto. O sistema captura esse evento registrando o carimbo de data e hora de criação do novo registro de cabeçalho da PO. | ||
|
Por que isso importa
Como principal evento inicial do caso de PO, esta atividade é fundamental para todos os cálculos de tempo de ciclo. Ela fornece a 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 ID do Pedido de compra (PO_HEADER_ID).
Captura
Use o carimbo de 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, o que significa que foi totalmente recebido e/ou faturado e não são esperadas novas atividades. Esta é uma ação explícita que define um status final para a PO. | ||
|
Por que isso importa
Esta atividade marca a conclusão bem-sucedida do ciclo de vida do Pedido de compra. É o principal estado final positivo, e acompanhá-lo é essencial para medir o throughput geral do processo e as taxas de conclusão.
Onde obter
Este evento é registrado na tabela PO_ACTION_HISTORY com ACTION_CODE igual a 'FINALLY CLOSE'. O status da PO em PO_HEADERS_ALL também é atualizado para 'Finally Closed'.
Captura
Filtre PO_ACTION_HISTORY por 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 a partir de uma alteração de status ou de um carimbo de data e hora no registro de comunicação da PO. | ||
|
Por que isso importa
Este evento marca o início do prazo de entrega do fornecedor. É um ponto essencial para medir a performance do fornecedor, desde a confirmação de recebimento até a entrega final.
Onde obter
Isso pode ser inferido quando o status do documento da PO muda para 'Open' e uma data de comunicação é preenchida. O campo específico geralmente é PO_HEADERS_ALL.communicated_date ou um status relacionado.
Captura
Infira o evento a partir do carimbo de data e hora em que o status de comunicação da PO é atualizado para 'Communicated'.
Tipo de evento
inferred
|
|||
|
Produtos recebidos
|
Os produtos foram recebidos fisicamente, contados e registrados contra o Pedido de compra. Este é um evento transacional que atualiza o estoque e o status da PO. | ||
|
Por que isso importa
Este é um marco importante para medir a performance de entrega no prazo do fornecedor e o prazo total de entrega. Ele também aciona atividades posteriores, como inspeção de qualidade e conferência de faturas.
Onde obter
Este é um evento explícito registrado na tabela RCV_TRANSACTIONS. A transação específica pode ser identificada por TRANSACTION_TYPE igual a 'RECEIVE'.
Captura
Use TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'RECEIVE'.
Tipo de evento
explicit
|
|||
|
Documento de recebimento criado
|
Um documento de recebimento é iniciado no sistema como preparação para a chegada física dos produtos. Esta atividade representa o início do processo interno de recebimento. | ||
|
Por que isso importa
Este evento marca a transição de compras para logística. Analisar o tempo entre este ponto e o registro final do recebimento ajuda a identificar ineficiências no armazém ou no departamento de recebimento.
Onde obter
Este é um evento explícito, capturado pelo carimbo de data e hora de criação de um novo registro na tabela RCV_SHIPMENT_HEADERS vinculado ao Pedido de compra.
Captura
Use a data de criação do registro correspondente em RCV_SHIPMENT_HEADERS.
Tipo de evento
explicit
|
|||
|
Entrega de serviços confirmada
|
Para Pedidos de compra baseados em serviços, esta atividade registra a confirmação de que os serviços foram prestados conforme acordado. Essa confirmação geralmente é registrada manualmente ou por meio de uma folha de registro de serviços. | ||
|
Por que isso importa
Este é o equivalente ao recebimento de produtos para serviços e uma etapa crítica antes que uma fatura possa ser paga. Atrasos na confirmação do serviço podem resultar em pagamentos atrasados e relações desgastadas com fornecedores.
Onde obter
Isso normalmente é registrado como um recebimento contra uma linha de serviço da PO. Pode envolver campos específicos ou recebimentos complexos que acompanham o progresso ou a conclusão dos serviços.
Captura
Identifique as transações de recebimento (RCV_TRANSACTIONS) vinculadas às linhas de POs baseadas em serviços.
Tipo de evento
explicit
|
|||
|
Inspeção de qualidade realizada
|
Os produtos que exigem controle de qualidade foram inspecionados e aceitos ou rejeitados. Esta atividade ocorre após o recebimento inicial e é registrada como uma transação distinta. | ||
|
Por que isso importa
Esta atividade é essencial 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 produtos para uso.
Onde obter
Isso é registrado na tabela RCV_TRANSACTIONS. O evento é identificado por transações com TRANSACTION_TYPE igual a 'ACCEPT' ou 'REJECT' que ocorrem após uma transação de recebimento.
Captura
Use TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'ACCEPT' ou 'REJECT'.
Tipo de evento
explicit
|
|||
|
Pedido de compra alterado
|
Uma alteração foi feita no Pedido de compra após sua aprovação inicial, como uma mudança na quantidade, no preço ou na data de entrega. O Oracle Fusion acompanha isso criando uma nova revisão do documento. | ||
|
Por que isso importa
As alterações na PO 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 obter
Este evento é capturado explicitamente quando uma nova revisão do documento é criada. Ele pode ser identificado pelo aumento do 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 do Pedido de compra. Esse evento geralmente é registrado manualmente pela equipe de compras 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 garante que o pedido foi recebido e está sendo processado. Acompanhar esse evento ajuda a gerenciar a comunicação com fornecedores e identificar proativamente possíveis problemas no atendimento do pedido.
Onde obter
Isso normalmente é inferido a partir de uma alteração nos campos de status de confirmação do cabeçalho ou das linhas da PO, como a mudança de PO_HEADERS_ALL.acceptance_status para 'Accepted'.
Captura
Infira o evento a partir das atualizações nos campos de status de confirmação da PO.
Tipo de evento
inferred
|
|||
|
Pedido de compra enviado para aprovação
|
O Pedido de compra criado é enviado para o Workflow de aprovação. O Oracle Fusion registra explicitamente essa ação, incluindo o usuário e o carimbo de 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 obter
Esta ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE igual a 'SUBMIT' para o PO_HEADER_ID correspondente.
Captura
Filtre PO_ACTION_HISTORY por ACTION_CODE = 'SUBMIT'.
Tipo de evento
explicit
|
|||
|
Pedido de compra rejeitado
|
Um aprovador rejeitou o Pedido de compra, devolvendo-o ao criador para revisão. Este é um evento explícito registrado no histórico de ações, indicando uma interrupção no fluxo padrão do processo. | ||
|
Por que isso importa
As rejeições introduzem retrabalho e atrasos no processo. Acompanhar esta atividade ajuda a identificar motivos recorrentes de rejeição, necessidades de treinamento ou requisitos de aprovação pouco claros.
Onde obter
Esta ação é registrada na tabela PO_ACTION_HISTORY com ACTION_CODE igual a 'REJECT' para o PO_HEADER_ID correspondente.
Captura
Filtre PO_ACTION_HISTORY por ACTION_CODE = 'REJECT'.
Tipo de evento
explicit
|
|||
|
Produtos devolvidos ao fornecedor
|
Produtos recebidos anteriormente são devolvidos ao fornecedor, geralmente devido a defeitos, danos ou envios incorretos. Isso é registrado 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 do fornecedor e a precisão dos pedidos. Taxas altas de devolução para um fornecedor podem indicar problemas sistêmicos que precisam ser resolvidos.
Onde obter
Este é um evento explícito registrado na tabela RCV_TRANSACTIONS com TRANSACTION_TYPE igual a 'RETURN TO VENDOR'.
Captura
Use TRANSACTION_DATE de RCV_TRANSACTIONS quando TRANSACTION_TYPE for 'RETURN TO VENDOR'.
Tipo de evento
explicit
|
|||
|
Requisição de compra aprovada
|
A requisição de compra foi aprovada pela autoridade designada, autorizando o departamento 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 nessa etapa podem afetar diretamente todo o cronograma de aquisição, por isso é essencial monitorar sua duração.
Onde obter
Este evento é registrado no histórico de ações associado à requisição, normalmente por meio de tabelas de Workflow ou de 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 específico.
Tipo de evento
explicit
|
|||
|
Requisição de compra criada
|
Esta atividade registra a criação de uma requisição de compra, que é a solicitação formal de produtos ou serviços que antecede um Pedido de compra. Ela é capturada quando uma nova entrada é criada na tabela de cabeçalho de requisições do Oracle Fusion. | ||
|
Por que isso importa
Analisar esta atividade ajuda a entender a etapa de origem da demanda. Acompanhar o tempo entre a requisição e a criação do Pedido de compra revela possíveis atrasos na conversão da demanda interna em pedidos de aquisição acionáveis.
Onde obter
Este é um evento explícito, registrado quando uma nova requisição é salva. Ele pode ser identificado acompanhando o carimbo de data e hora de criação na tabela POR_REQUISITION_HEADERS_ALL.
Captura
O evento é baseado 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 ao pagamento: pedido de compra. Comece a otimizar suas operações hoje.
Otimize hoje seu processo de compras ao pagamento: pedido de compra
Identifique gargalos que geram custos e reduza o tempo de ciclo em 30% com facilidade.
Não é necessário cartão de crédito. Comece a otimizar hoje.