Seu Template de dados de Purchase to Pay - Purchase Order
Seu Template de dados de Purchase to Pay - Purchase Order
- Atributos de dados recomendados
- Atividades principais do processo
- Etapas para extrair dados do Coupa
Purchase to Pay - Atributos do pedido de compra
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome do evento ou da tarefa específica que ocorreu em determinado momento do ciclo de vida da Purchase Order. | ||
|
Descrição
O nome da atividade descreve uma única etapa do processo de purchase-to-pay, como “Purchase Order Approved” ou “Goods Receipt Posted”. Essa sequência de atividades forma o fluxo do processo de cada Purchase Order. Este atributo é fundamental para o Process Mining, pois é usado para construir o mapa do processo, descobrir variantes e analisar a frequência e a sequência dos eventos. Ele ajuda a identificar gargalos, ciclos de retrabalho e desvios do fluxo padrão do processo. Por exemplo, analisar a sequência de atividades “Purchase Order Changed” pode revelar ineficiências na precisão dos pedidos.
Por que isso importa
Ele define as etapas do processo, permitindo visualizar o fluxo e identificar gargalos, retrabalho e desvios.
Onde obter
Derivado de Event Logs, trilhas de auditoria ou registros de alterações de status associados aos objetos Purchase Order no Coupa.
Exemplos
Requisição de compra aprovadaPurchase Order enviada para aprovaçãoRecebimento de produtos registradoFatura recebida para a PO
|
|||
|
Hora de início
EventTime
|
O timestamp exato que indica quando uma atividade ou evento ocorreu. | ||
|
Descrição
O horário do evento registra a data e a hora em que uma atividade específica foi executada. Para cada atividade do processo, há um timestamp correspondente que marca sua ocorrência. Este atributo é essencial para todas as análises baseadas em tempo no Process Mining. Ele é usado para calcular os tempos de ciclo entre atividades, medir a duração do processo e identificar atrasos. Por exemplo, a diferença entre os timestamps de “Purchase Order Drafted” e “Purchase Order Approved” é usada para calcular o KPI de tempo do ciclo de aprovação da PO.
Por que isso importa
Ele fornece o contexto temporal de cada evento, essencial para calcular tempos de ciclo, analisar a performance e detectar gargalos.
Onde obter
Localizado nos Event Logs ou nas trilhas de auditoria do Coupa, normalmente associado a cada alteração de status ou ação realizada em uma Purchase Order.
Exemplos
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Pedido de compra
PurchaseOrderNumber
|
O identificador exclusivo de uma Purchase Order, que funciona como o identificador principal do caso no processo. | ||
|
Descrição
O número da Purchase Order é o identificador central do caso que conecta todas as atividades, desde a solicitação inicial até a confirmação final do recebimento de produtos ou serviços. Cada número exclusivo de Purchase Order representa uma única instância do processo de compras. Na análise de Process Mining, este atributo é essencial para acompanhar a jornada completa de cada compra. Ele permite que os analistas visualizem mapas de processo, identifiquem variantes e calculem KPIs no nível do caso, como o tempo total de ciclo de um pedido. Todos os eventos e dados relacionados são agregados sob esse identificador para criar uma visão integrada do processo.
Por que isso importa
Ele é essencial para acompanhar o ciclo de vida completo de cada compra, permitindo reconstruir instâncias individuais do processo para uma análise detalhada.
Onde obter
Este é um campo de chave primária padrão no objeto Purchase Order do Coupa.
Exemplos
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Sistema de origem
SourceSystem
|
O sistema do qual os dados do processo foram extraídos. | ||
|
Descrição
Este atributo identifica o sistema de informação de origem no qual os dados do evento foram registrados. Para este processo, o valor seria sempre “Coupa”. Em ambientes corporativos nos quais os dados podem vir de vários sistemas, como o Coupa para compras e outro ERP para faturamento, este atributo ajuda a diferenciar as fontes de dados. Ele garante clareza sobre a linhagem dos dados e pode ser usado para filtrar a análise pela visão de um sistema específico sobre o processo.
Por que isso importa
Ele fornece um contexto essencial sobre a origem dos dados, garantindo rastreabilidade e permitindo uma governança adequada, especialmente em ambientes com vários sistemas.
Onde obter
Este é um valor estático normalmente adicionado durante o processo de extração e transformação dos dados para identificar o conjunto de dados.
Exemplos
Coupa
|
|||
|
Última atualização dos dados
LastDataUpdate
|
O timestamp que indica a última vez em que os dados deste processo foram atualizados. | ||
|
Descrição
Este atributo registra quando o conjunto de dados foi atualizado pela última vez a partir do sistema de origem. É um campo de metadados que se aplica ao conjunto de dados inteiro, e não a eventos individuais. Em qualquer Dashboard analítico, esse timestamp é essencial para que os usuários entendam o quanto os dados visualizados estão atualizados. Ele dá confiança de que os insights se baseiam em informações recentes e ajuda a alinhar as expectativas dos usuários sobre a atualidade dos dados. Normalmente, é exibido em destaque nos Dashboards.
Por que isso importa
Informa aos usuários o quanto os dados são recentes, garantindo que entendam a atualidade da análise do processo e dos KPIs.
Onde obter
Este timestamp é gerado e armazenado pelo pipeline de extração e carregamento de dados (ETL) durante sua execução.
Exemplos
2023-11-01T05:00:00Z
|
|||
|
Categoria de compra
PurchaseCategory
|
A classificação dos bens ou serviços que estão sendo comprados, como hardware de TI ou serviços profissionais. | ||
|
Descrição
A Categoria de compra, também conhecida como Commodity ou Grupo de materiais, é uma classificação usada para agrupar tipos semelhantes de compras. Esses dados estruturados permitem analisar sistematicamente os gastos e os processos de compras. No Process Mining, esse atributo é uma dimensão importante para filtragem e segmentação. O Dashboard "Análise de gastos por categoria de compra" usa esse atributo para detalhar os padrões de gastos. Ele também pode revelar se determinadas categorias, como serviços complexos, têm tempos de ciclo mais longos ou taxas de alteração mais altas do que outras, como materiais de escritório padrão.
Por que isso importa
Permite analisar gastos e processos por categoria, ajudando a identificar padrões de compras, negociar com fornecedores e adaptar os controles do processo.
Onde obter
Normalmente encontrado no nível do item de linha do Purchase Order no Coupa, geralmente vinculado a um código de commodity ou catálogo de compras.
Exemplos
Hardware de TIMateriais de escritórioServiços profissionaisMateriais de marketing
|
|||
|
Departamento
Department
|
O departamento de negócio ou centro de custo ao qual a Purchase Order é atribuída. | ||
|
Descrição
O atributo Departamento especifica a unidade organizacional que iniciou a compra ou assumirá seu custo. Ele costuma estar vinculado ao solicitante ou às informações do centro de custo nos itens de linha da Purchase Order. Essa dimensão é essencial para segmentar a análise do processo e dos KPIs. Ela permite que os gestores comparem a eficiência do processo, a conformidade e os padrões de gastos entre diferentes áreas da organização. Por exemplo, o Dashboard de análise de gastos por categoria de compra usa o Departamento para mostrar como diferentes unidades de negócio estão usando seus orçamentos.
Por que isso importa
Ele permite filtrar e comparar a análise do processo e dos gastos entre diferentes unidades de negócio, revelando variações de eficiência e conformidade.
Onde obter
Disponível no cabeçalho do Purchase Order ou nos itens de linha no Coupa, geralmente vinculado a um Centro de Custo ou unidade organizacional.
Exemplos
MarketingTecnologia da InformaçãoOperaçõesFinanças
|
|||
|
Nome do fornecedor
VendorName
|
O nome do fornecedor de quem os bens ou serviços estão sendo comprados. | ||
|
Descrição
O Nome do fornecedor identifica a parte externa que fornece os itens do pedido de compra. Essas informações são fundamentais para a análise de compras. Analisar a performance do processo por fornecedor é essencial para a gestão do relacionamento com fornecedores. Isso ajuda a avaliar a "Performance do prazo de entrega do fornecedor", identificar atrasos no "Processo de atrasos no recebimento de mercadorias" e avaliar a qualidade do fornecedor por meio da "Taxa de devolução de mercadorias". Esse atributo também é importante para calcular o KPI "Proporção de gastos com fornecedores não preferenciais".
Por que isso importa
Permite analisar a performance dos fornecedores, ajudando a otimizar a seleção, negociar condições melhores e identificar fornecedores com performance alta ou baixa.
Onde obter
Um campo padrão no cabeçalho do Purchase Order no Coupa, vinculado aos dados mestres do fornecedor.
Exemplos
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Usuário
User
|
O ID ou nome do usuário que realizou a atividade, como um aprovador ou solicitante. | ||
|
Descrição
Este atributo identifica a pessoa responsável por executar um evento específico do processo. Pode ser a pessoa que elaborou o pedido, o gerente que o aprovou ou o funcionário que registrou o recebimento dos produtos. Analisar a performance por usuário ajuda a identificar necessidades de treinamento, pessoas com alta performance e a distribuição da carga de trabalho. Por exemplo, o Dashboard de performance do tempo do ciclo de aprovação da PO usa este atributo para detalhar os tempos de aprovação por aprovador, destacando quem pode estar causando um gargalo no processo.
Por que isso importa
Ele permite analisar a performance do processo por pessoa ou função, ajudando a identificar gargalos, oportunidades de treinamento e problemas de alocação de recursos.
Onde obter
Associado a cada evento na trilha de auditoria ou nos registros de histórico da Purchase Order no Coupa. Campos como “Created By”, “Approved By” ou “Updated By” são fontes comuns.
Exemplos
j.doea.smithm.jones
|
|||
|
Valor total do pedido
TotalOrderAmount
|
O valor monetário total do pedido de compra. | ||
|
Descrição
Esse atributo representa o custo total de todos os bens e serviços especificados no pedido de compra, expresso em uma moeda específica. É um atributo no nível do caso que se aplica ao pedido inteiro. Esses dados financeiros são essenciais para a análise de gastos e para priorizar iniciativas de melhoria de processos. Pedidos de alto valor podem exigir uma análise mais detalhada ou fluxos de aprovação diferentes. Eles são usados diretamente no Dashboard "Análise de gastos por categoria de compra" e fazem parte do cálculo do KPI "Proporção de gastos com fornecedores não preferenciais".
Por que isso importa
Fornece o contexto financeiro de cada compra, permitindo analisar gastos, priorizar pedidos de alto valor e avaliar o impacto financeiro.
Onde obter
Disponível no cabeçalho do Purchase Order no Coupa, normalmente como "Total" ou "Total geral".
Exemplos
1500.00250.7512500.50
|
|||
|
Data de entrega solicitada
RequestedDeliveryDate
|
A data em que o solicitante pediu que os bens ou serviços fossem entregues. | ||
|
Descrição
Esse atributo é a data de entrega desejada especificada pelo usuário de negócio durante o processo de requisição. Ela representa a expectativa da empresa sobre quando o pedido deve ser atendido. Essa data é uma referência essencial para medir a performance do fornecedor e das equipes internas. Ela é usada diretamente para calcular o KPI "Aderência à data de entrega do fornecedor", comparando-a com a data real de "Recebimento de mercadorias registrado". O Dashboard "Variação da data de entrega e devoluções" mostra as diferenças entre a data solicitada e a entrega real, ajudando a alinhar expectativas e melhorar as previsões.
Por que isso importa
Serve como uma referência importante para medir a entrega pontual dos fornecedores e a eficiência do processo interno de recebimento.
Onde obter
Um campo padrão no item de linha do Purchase Order no Coupa.
Exemplos
2023-11-152023-12-012024-01-10
|
|||
|
É aprovação na primeira tentativa
IsFirstPassApproval
|
Um indicador calculado que recebe o valor true quando o PO é aprovado sem alterações após ser criado. | ||
|
Descrição
Esse indicador booleano recebe o valor true quando a jornada de um pedido de compra entre "Pedido de compra criado" e "Pedido de compra aprovado" não contém nenhuma atividade de "Pedido de compra alterado" ou "Pedido de compra rejeitado" nesse intervalo. Esse atributo mede diretamente o KPI "Taxa de aprovação de PO na primeira tentativa". Uma taxa alta indica um processamento inicial eficiente e preciso. Analisar os casos em que esse indicador é false pode ajudar a descobrir os motivos do retrabalho e melhorar a qualidade dos dados inseridos inicialmente nos pedidos de compra.
Por que isso importa
Mede diretamente a eficiência do processo inicial de criação e aprovação, destacando o volume de pedidos que seguem sem retrabalho.
Onde obter
Calculado durante a transformação dos dados, analisando a sequência de eventos de cada PurchaseOrderNumber.
Exemplos
truefalse
|
|||
|
É entrega no prazo
IsDeliveryOnTime
|
Um indicador calculado que informa se os bens foram recebidos na data de entrega solicitada ou antes dela. | ||
|
Descrição
Esse atributo booleano é calculado comparando o timestamp do evento "Recebimento de mercadorias registrado" com o "RequestedDeliveryDate". Ele recebe o valor true quando a data de recebimento é igual ou anterior à data solicitada. Esse indicador dá suporte direto ao KPI "Aderência à data de entrega do fornecedor" e ao Dashboard "Variação da data de entrega e devoluções". Ele fornece um resultado binário claro para a performance no prazo, fácil de agregar e visualizar, ajudando a identificar rapidamente problemas de performance com fornecedores ou nos processos internos de recebimento.
Por que isso importa
Fornece uma métrica binária clara para a performance de entrega, simplificando o cálculo de KPIs de entrega no prazo e a análise de tendências.
Onde obter
Calculado durante a transformação dos dados, comparando "RequestedDeliveryDate" com o timestamp da atividade "Recebimento de mercadorias registrado".
Exemplos
truefalse
|
|||
|
É fornecedor preferencial
IsPreferredVendor
|
Um indicador booleano que informa se a compra foi feita de um fornecedor preferencial ou estratégico. | ||
|
Descrição
Esse indicador identifica se o fornecedor do pedido de compra faz parte de uma lista pré-aprovada de fornecedores estratégicos. Normalmente, isso é determinado comparando o nome ou ID do fornecedor com uma lista mestre de fornecedores preferenciais. Esse atributo é essencial para iniciativas de sourcing estratégico e gestão de gastos. Ele é usado para calcular o KPI "Proporção de gastos com fornecedores não preferenciais", que ajuda as organizações a monitorar e controlar compras fora da política e a concentrar os gastos em parceiros estratégicos para aproveitar descontos por volume e condições melhores.
Por que isso importa
Ajuda a monitorar a conformidade com as políticas de compras e as metas de sourcing estratégico, acompanhando os gastos com fornecedores preferenciais e não preferenciais.
Onde obter
Geralmente não é um campo padrão no Coupa, mas é derivado comparando o ID do fornecedor no PO com uma lista externa de fornecedores preferenciais.
Exemplos
truefalse
|
|||
|
É retrabalho
IsRework
|
Um indicador calculado que identifica se um pedido de compra passou por uma atividade de alteração. | ||
|
Descrição
Esse indicador booleano recebe o valor true para qualquer pedido de compra que tenha pelo menos um evento de "Pedido de compra alterado" no histórico. É um atributo no nível do caso, derivado do Event Log. Esse atributo simplifica o cálculo de KPIs como a "Taxa de alteração de pedidos de compra". Ele permite filtrar e segmentar facilmente os dados para comparar processos de pedidos com e sem retrabalho, ajudando a quantificar o impacto das alterações no tempo de ciclo e no custo. É um componente essencial do Dashboard "Análise de alterações em pedidos de compra".
Por que isso importa
Simplifica a análise de retrabalho ao permitir filtrar e agregar facilmente todos os pedidos de compra que foram alterados pelo menos uma vez.
Onde obter
Calculado durante a transformação dos dados, verificando a existência de uma atividade de "Pedido de compra alterado" para cada PurchaseOrderNumber.
Exemplos
truefalse
|
|||
|
Local de recebimento
ReceivingLocation
|
O local físico, como um armazém ou escritório, onde os bens devem ser entregues. | ||
|
Descrição
O Local de recebimento especifica o destino dos bens pedidos no PO. Pode ser um armazém, uma fábrica ou um endereço de escritório específico. Esse atributo é usado para analisar a performance logística e de recebimento em diferentes locais. O Dashboard "Atrasos no processo de recebimento de mercadorias" pode ser filtrado por esse atributo para determinar se determinados locais são mais lentos no processamento de remessas recebidas, ajudando a identificar ineficiências operacionais ou restrições de recursos em unidades específicas.
Por que isso importa
Permite analisar o processo de recebimento por local, destacando diferenças de performance entre armazéns, fábricas ou escritórios.
Onde obter
Essas informações fazem parte do endereço "Enviar para" do Purchase Order no Coupa.
Exemplos
Armazém A - ChicagoPrédio 5 - Escritório de LondresFábrica de Frankfurt
|
|||
|
Moeda
Currency
|
O código da moeda dos valores monetários no pedido de compra. | ||
|
Descrição
Esse atributo especifica a moeda, como USD, EUR ou GBP, na qual o Valor total do pedido é denominado. Ele é essencial para interpretar corretamente os dados financeiros em uma organização global. Para empresas multinacionais, analisar os gastos sem considerar a moeda pode levar a conclusões equivocadas. Esse atributo permite fazer a conversão correta e manter relatórios financeiros consistentes nos Dashboards, garantindo que os valores sejam comparados em uma base equivalente.
Por que isso importa
Garante análises e relatórios financeiros precisos em contextos multinacionais, fornecendo as informações necessárias para a conversão de moedas.
Onde obter
Um campo padrão no cabeçalho do Purchase Order no Coupa.
Exemplos
USDEURGBPJPY
|
|||
|
Motivo da alteração
ChangeReason
|
O motivo informado para uma alteração feita em um pedido de compra após sua criação inicial. | ||
|
Descrição
Esse atributo registra a justificativa para a alteração de um pedido de compra, por exemplo, "Quantidade atualizada" ou "Correção de preço". Essas informações geralmente são registradas na trilha de auditoria quando um usuário executa uma atividade de "Pedido de compra alterado". Entender por que os pedidos são alterados é essencial para o Dashboard "Análise de alterações em pedidos de compra". Isso ajuda a diferenciar alterações inevitáveis, como problemas de estoque do fornecedor, das que poderiam ser evitadas, como a inserção incorreta dos dados iniciais, orientando ações para melhorar a precisão dos pedidos e reduzir o KPI "Taxa de alteração de pedidos de compra".
Por que isso importa
Explica as causas-raiz das alterações nos POs, permitindo ações direcionadas para melhorar a precisão dos pedidos na primeira tentativa e reduzir o retrabalho do processo.
Onde obter
Frequentemente encontrado nos logs de auditoria ou comentários associados aos eventos de alteração de um Purchase Order no Coupa.
Exemplos
Atualização de preço do fornecedorData de entrega ajustadaCódigo do item corrigido
|
|||
|
Motivo da rejeição
RejectionReason
|
O motivo informado quando uma requisição de compra ou um pedido de compra é rejeitado durante uma etapa de aprovação. | ||
|
Descrição
Quando um aprovador rejeita um pedido de compra, geralmente informa o motivo da rejeição. Esse atributo registra essa explicação textual, como "Código de orçamento incorreto" ou "Excede o limite de gastos". Analisar os motivos de rejeição fornece insights diretos sobre as causas-raiz do retrabalho e das falhas do processo. Esses dados qualitativos podem ser usados para identificar erros comuns no processo de requisição, levando a treinamentos direcionados ou melhorias no sistema para evitar rejeições futuras e aumentar a taxa de aprovação na primeira tentativa.
Por que isso importa
Fornece insights diretos e acionáveis sobre os motivos de rejeição dos pedidos de compra, ajudando a tratar as causas-raiz do retrabalho e dos atrasos no processo.
Onde obter
Normalmente registrado no campo de comentários ou observações associado à atividade "Pedido de compra rejeitado" ou "Requisição de compra rejeitada" no Workflow de aprovação do Coupa.
Exemplos
Solicitação duplicadaOrçamento não aprovadoFornecedor incorreto selecionado
|
|||
|
Nome do solicitante
RequesterName
|
O nome da pessoa que solicitou inicialmente os bens ou serviços. | ||
|
Descrição
Esse atributo identifica o funcionário que criou a requisição de compra que resultou no pedido de compra. O solicitante é o usuário de negócio que tem a necessidade e pode ser diferente do comprador ou aprovador. Analisar o comportamento do processo por solicitante ajuda a identificar padrões relacionados a usuários ou departamentos específicos. O Dashboard "Análise de alterações em pedidos de compra" usa esse atributo para verificar se determinados solicitantes têm uma frequência maior de alterações nos pedidos, o que pode indicar a necessidade de um treinamento melhor sobre os requisitos das especificações.
Por que isso importa
Ajuda a identificar a origem de negócio de uma compra, permitindo analisar o comportamento e a precisão das compras no nível do solicitante.
Onde obter
Essas informações geralmente ficam armazenadas na Requisição de compra de origem e são transferidas para o Purchase Order no Coupa.
Exemplos
Alice CooperBob DylanCharlie Parker
|
|||
|
Número da requisição de compra
PurchaseRequisitionNumber
|
O identificador exclusivo da requisição de compra que precedeu o pedido de compra. | ||
|
Descrição
Esse atributo vincula um pedido de compra à requisição de compra que o originou. Uma única requisição pode resultar em um ou mais pedidos de compra. Esse vínculo é essencial para analisar o tempo de ciclo completo de "Requisição até pedido". Ao conectar o evento de criação da requisição aos eventos de criação e envio do pedido de compra, as organizações conseguem medir a eficiência de todo o processo de início das compras, da solicitação ao atendimento.
Por que isso importa
Conecta as etapas de solicitação e pedido do processo, permitindo analisar o tempo de ciclo e as taxas de conversão de requisição até pedido.
Onde obter
Normalmente é um campo de referência nos itens de linha do Purchase Order no Coupa, vinculado à requisição de origem.
Exemplos
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
Purchase to Pay - Atividades do pedido de compra
| Atividade | Descrição | ||
|---|---|---|---|
|
Purchase Order aprovada
|
Este marco indica que a Purchase Order concluiu seu Workflow interno de aprovação e está autorizada para ser emitida ao fornecedor. Normalmente, esta é a etapa final de aprovação em um processo com várias etapas. | ||
|
Por que isso importa
Este é um marco crítico para calcular o tempo do ciclo de aprovação da PO e identificar gargalos de aprovação. Também funciona como um ponto de controle importante de conformidade.
Onde obter
Capturado no registro do histórico de aprovações da Purchase Order no Coupa. O timestamp da ação de aprovação final fornece o horário do evento.
Captura
Registrado no histórico de aprovações quando o aprovador final conclui sua tarefa.
Tipo de evento
explicit
|
|||
|
Purchase Order cancelada
|
Esta atividade representa o cancelamento de uma Purchase Order antes de sua conclusão. O cancelamento pode ocorrer em diferentes etapas, por exemplo, quando a solicitação deixa de ser válida ou quando a PO foi criada por engano. | ||
|
Por que isso importa
Como um encerramento alternativo do processo, acompanhar os cancelamentos é importante para entender as perdas no processo e identificar os motivos de solicitações de compra abandonadas.
Onde obter
Inferido a partir de uma alteração de status no objeto Purchase Order para “Canceled”. O timestamp dessa alteração de status é usado como horário do evento.
Captura
Derivado do timestamp da alteração de status para “Canceled”.
Tipo de evento
inferred
|
|||
|
Purchase Order encerrada
|
Esta é a atividade final, indicando que a Purchase Order foi concluída. A PO é considerada encerrada quando foi totalmente recebida e faturada, sem expectativa de novas transações. | ||
|
Por que isso importa
Esta atividade encerra oficialmente o ciclo de vida da PO. Analisar o tempo até o encerramento pode revelar ineficiências na reconciliação final e na manutenção dos registros.
Onde obter
Inferido a partir de uma alteração de status no objeto Purchase Order para “Closed”. Esse status costuma ser definido automaticamente pelo Coupa com base em regras de negócio relacionadas às tolerâncias de recebimento e faturamento.
Captura
Derivado do timestamp da alteração de status para “Closed”.
Tipo de evento
inferred
|
|||
|
Purchase Order enviada ao fornecedor
|
Esta atividade marca o momento em que a Purchase Order aprovada é transmitida oficialmente ao fornecedor, por exemplo, por e-mail ou pelo Coupa Supplier Portal. O evento transforma a PO de um documento interno em um compromisso externo. | ||
|
Por que isso importa
Este é um marco importante que encerra o ciclo interno de requisição até pedido e inicia o prazo de entrega do fornecedor. Ele é essencial para medir tanto a eficiência interna quanto a performance do fornecedor.
Onde obter
Frequentemente inferido a partir de uma alteração de status da PO para “Ordered” ou “Sent”. O Coupa também pode ter um timestamp específico “last_exported_at” ou “sent_to_supplier_at” no registro da PO.
Captura
Derivado do timestamp da alteração de status para “Ordered” ou de um campo específico de timestamp da transmissão.
Tipo de evento
inferred
|
|||
|
Recebimento de produtos registrado
|
Esta é a confirmação formal de que os produtos foram recebidos, inspecionados e aceitos. O evento atualiza os registros de estoque e indica que a obrigação do fornecedor referente a essa entrega foi cumprida. | ||
|
Por que isso importa
Este marco crítico encerra o prazo de entrega do fornecedor e é usado para medir a aderência à data de entrega. Atrasos no registro dos recebimentos podem ocultar a visibilidade dos níveis reais de estoque.
Onde obter
Esta é uma transação central no Coupa, registrada no objeto Receipt. O evento é capturado a partir do timestamp em que o status do recebimento muda para “Posted” ou “Received”.
Captura
Registrado quando a transação de recebimento de produtos é finalizada no sistema.
Tipo de evento
explicit
|
|||
|
Requisição de compra criada
|
Esta atividade marca a criação de uma requisição de compra, que é a solicitação formal de produtos ou serviços que antecede uma Purchase Order. No Coupa, este é um evento explícito registrado quando um usuário salva e envia uma nova requisição. | ||
|
Por que isso importa
Como ponto de partida típico do processo de compras, esta atividade é essencial para medir o tempo total do ciclo de requisição até pedido e entender a eficiência do processo nas etapas anteriores.
Onde obter
Este evento corresponde ao registro de criação no objeto ou na tabela Purchase Requisitions do Coupa. O timestamp pode ser encontrado no campo “created_at” ou em um campo equivalente de data de criação gerado pelo sistema.
Captura
Registrado diretamente no momento da criação de uma nova requisição.
Tipo de evento
explicit
|
|||
|
Confirmação de serviços registrada
|
Para Purchase Orders de serviços, esta atividade equivale ao recebimento de produtos. Ela confirma que um serviço foi prestado de acordo com os termos da PO. | ||
|
Por que isso importa
Acompanhar as confirmações de serviços é essencial para gerenciar os gastos com serviços e garantir que os pagamentos sejam feitos apenas por trabalhos verificados como concluídos.
Onde obter
Este evento é capturado a partir da criação ou aprovação de um recebimento de serviço ou de uma folha de registro de serviços vinculada à Purchase Order no Coupa.
Captura
Registrado após a criação e aprovação de uma folha de registro de serviços.
Tipo de evento
explicit
|
|||
|
Fatura recebida para a PO
|
Este evento marca o recebimento e o registro de uma fatura do fornecedor que faz referência à Purchase Order. Ele indica o início da fase de processamento e pagamento da fatura no ciclo P2P. | ||
|
Por que isso importa
Embora faça parte do processo de Contas a Pagar, vincular o recebimento da fatura à PO oferece uma visão de ponta a ponta do ciclo de vida da transação e ajuda a analisar o intervalo entre a entrega e o faturamento.
Onde obter
Capturado a partir do timestamp de criação do documento Invoice no Coupa, no qual a fatura é associada ao número correspondente da Purchase Order.
Captura
Registrado após a criação de um registro de fatura vinculado à PO.
Tipo de evento
explicit
|
|||
|
Inspeção de qualidade realizada
|
Este evento indica que um item recebido passou por uma inspeção de qualidade e foi aprovado. Dependendo do processo da empresa, esta pode ser uma etapa separada após o registro inicial do recebimento de produtos. | ||
|
Por que isso importa
Esta atividade é essencial para medir a eficiência do processo de controle de qualidade. Atrasos nessa etapa podem criar gargalos entre o recebimento e a disponibilidade para uso.
Onde obter
Pode ser registrada como uma alteração de status no item da linha de recebimento ou por meio de um objeto de inspeção separado no Coupa. A disponibilidade depende do uso do módulo de qualidade ou de um Workflow personalizado.
Captura
Inferido a partir de uma alteração de status no recebimento ou de um timestamp em um registro de inspeção relacionado.
Tipo de evento
inferred
|
|||
|
Pedido reconhecido pelo fornecedor
|
Este evento indica que o fornecedor recebeu e confirmou a Purchase Order. Essa confirmação costuma ser registrada eletronicamente por meio de um portal de fornecedores, como o Coupa Supplier Portal (CSP). | ||
|
Por que isso importa
As confirmações dos fornecedores dão segurança de que o pedido está sendo processado, melhorando a precisão da previsão de entrega e reduzindo a incerteza na cadeia de suprimentos.
Onde obter
Essas informações normalmente estão disponíveis na Purchase Order quando o fornecedor usa o Coupa Supplier Portal para executar a ação “Acknowledge”. Usa-se o timestamp dessa ação.
Captura
Registrado quando o fornecedor executa a ação “Acknowledge” no portal de fornecedores.
Tipo de evento
explicit
|
|||
|
Produtos devolvidos
|
Esta atividade é registrada quando produtos recebidos anteriormente são devolvidos ao fornecedor. Isso normalmente ocorre devido a problemas de qualidade, danos ou envios incorretos. | ||
|
Por que isso importa
Acompanhar as devoluções é essencial para calcular a taxa de devolução de produtos e identificar problemas de qualidade do fornecedor ou de precisão do pedido. Taxas altas de devolução geralmente indicam falhas de processo dispendiosas.
Onde obter
Capturado a partir de uma transação “Return to Supplier” ou de uma transação de recebimento negativa no Coupa. O timestamp dessa transação funciona como horário do evento.
Captura
Registrado quando uma transação de devolução vinculada à PO ou ao recebimento original é criada.
Tipo de evento
explicit
|
|||
|
Purchase Order alterada
|
Este evento representa qualquer alteração feita na Purchase Order depois de sua elaboração inicial. No Coupa, as alterações costumam ser acompanhadas por meio do versionamento do documento PO. | ||
|
Por que isso importa
Acompanhar as alterações é essencial para KPIs como a taxa de alterações em Purchase Orders e a taxa de POs fora de conformidade. Alterações frequentes indicam instabilidade do processo ou imprecisão nas solicitações iniciais.
Onde obter
Pode ser inferido acompanhando diferentes versões de uma Purchase Order. Cada novo número de versão maior que o primeiro indica uma alteração, e a data de criação da nova versão funciona como timestamp do evento.
Captura
Inferido a partir do timestamp de criação de uma nova versão da PO.
Tipo de evento
inferred
|
|||
|
Purchase Order elaborada
|
Este evento representa a criação inicial do documento Purchase Order no sistema, geralmente a partir de uma requisição aprovada. Nesta etapa, a PO é um rascunho interno e ainda não foi enviada para aprovação nem encaminhada ao fornecedor. | ||
|
Por que isso importa
Esta atividade inicia a contagem do tempo do KPI de tempo do ciclo de aprovação da PO. É a primeira etapa formal do ciclo de vida da Purchase Order.
Onde obter
Isso corresponde ao timestamp de criação do registro Purchase Order no Coupa, normalmente encontrado em um campo como “created_at”.
Captura
Capturado a partir do timestamp de criação gerado pelo sistema para o registro da PO.
Tipo de evento
explicit
|
|||
|
Purchase Order enviada para aprovação
|
Depois de elaborada, a Purchase Order é enviada formalmente para o Workflow de aprovação. Esta é uma ação distinta do usuário, que muda o estado da PO de rascunho para aguardando aprovação. | ||
|
Por que isso importa
Este evento diferencia o tempo de elaboração do momento em que a PO passa efetivamente a aguardar aprovação. Isso oferece uma visão mais clara do comportamento dos usuários e das transferências entre etapas.
Onde obter
Inferido a partir de uma alteração de status no objeto Purchase Order, por exemplo, de “draft” para “pending approval”. Usa-se o timestamp dessa alteração específica de status.
Captura
Derivado do timestamp da alteração de status para “pending approval”.
Tipo de evento
inferred
|
|||
|
Purchase Order rejeitada
|
Esta atividade ocorre quando um aprovador rejeita a Purchase Order durante o Workflow de aprovação. Em seguida, a PO normalmente retorna ao criador para revisão ou cancelamento. | ||
|
Por que isso importa
Analisar as rejeições ajuda a revelar problemas de qualidade dos dados, violações de políticas ou lacunas de treinamento. Isso evidencia ciclos de retrabalho que causam atrasos significativos no processo.
Onde obter
Este é um evento explícito capturado no registro do histórico de aprovações da Purchase Order no Coupa. O registro mostrará uma ação “Reject” com o timestamp correspondente.
Captura
Registrado no histórico de aprovações com o status “Reject”.
Tipo de evento
explicit
|
|||
|
Recebimento de produtos iniciado
|
Esta atividade representa o início do processo de recebimento, por exemplo, quando um documento de recebimento é criado no Coupa após a chegada física dos produtos. Os produtos ainda não foram registrados formalmente no estoque nem confirmados como recebidos. | ||
|
Por que isso importa
Este evento é o ponto de partida para medir o KPI de tempo de processamento do recebimento de produtos. Ele ajuda a diferenciar o tempo em que os produtos ficam aguardando na doca do tempo gasto no processamento no sistema.
Onde obter
Pode ser inferido a partir do timestamp de criação de um documento de recebimento com status “Draft” ou “Pending”. Ele ocorre antes do registro final do recebimento.
Captura
Derivado do timestamp de criação de um registro de recebimento em estado não registrado.
Tipo de evento
inferred
|
|||
|
Requisição de compra aprovada
|
Uma requisição de compra passa por um Workflow de aprovação antes de ser convertida em uma Purchase Order. Este evento indica a aprovação final da requisição, deixando-a pronta para o pedido. | ||
|
Por que isso importa
Acompanhar as aprovações de requisições ajuda a identificar gargalos na fase anterior ao pedido. Os atrasos nessa etapa afetam diretamente a rapidez com que uma Purchase Order pode ser emitida.
Onde obter
Normalmente, este evento é capturado no histórico de aprovações do objeto de requisição no Coupa. A ação de aprovação final terá um timestamp e um usuário correspondentes.
Captura
Registrado no histórico de aprovações quando o aprovador final toma uma decisão.
Tipo de evento
explicit
|
|||
Guias de extração
Pronto para começar?
Use este Template para preparar seus dados para Process Mining e obter insights acionáveis. Comece hoje a otimizar seu processo de Purchase to Pay - Purchase Order.
Otimize seus Purchase Orders de P2P e aumente a eficiência hoje
Reduza em 30% o tempo de ciclo do seu P2P e comece a ver resultados rapidamente.
Não é necessário cartão de crédito. Configure em poucos minutos.