Template de dados: Procure to Pay (P2P) - Pedido de Compra
Seu Template de dados de Purchase to Pay - Pedido de Compra
- Atributos de dados recomendados
- Atividades-chave do processo
- Etapas de extração de dados no Coupa
Purchase to Pay - Atributos de Pedido de compra
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome do evento ou tarefa específica que ocorreu em um momento dentro do ciclo de vida do pedido de compra. | ||
|
Descrição
O Nome da Atividade descreve uma etapa específica no processo de Purchase to Pay (P2P), como 'Pedido de compra aprovado' ou 'Entrada de mercadorias registrada'. Essa sequência de atividades forma o fluxo de cada pedido de compra. Esse atributo é fundamental para 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. Por exemplo, analisar a sequência de atividades 'Pedido de compra alterado' pode revelar ineficiências na precisão dos pedidos.
Por que é importante
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 mudança de status associados a objetos de Pedido de Compra no Coupa.
Exemplos
Requisição de compra aprovadaPedido de compra enviado para aprovaçãoRecebimento lançadoFatura recebida para o PO
|
|||
|
Hora de Início
EventTime
|
O timestamp exato que indica quando uma atividade ou evento ocorreu. | ||
|
Descrição
Event Time 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. Esse atributo é fundamental para todas as análises baseadas em tempo no Process Mining. Ele é usado para calcular 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 de Aprovação do PO.
Por que é importante
Fornece o contexto temporal de cada evento, essencial para calcular tempos de ciclo, analisar performance e detectar gargalos.
Onde obter
Localizados nos Event Logs ou trilhas de auditoria do Coupa, geralmente associados a cada mudança de status ou ação realizada em um pedido de compra.
Exemplos
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Pedido de Compra
PurchaseOrderNumber
|
O identificador único de um Pedido de Compra, que funciona como o principal identificador de caso do processo. | ||
|
Descrição
O número do Pedido de Compra é o identificador de caso central que conecta todas as atividades, da solicitação inicial à confirmação final do recebimento de bens ou serviços. Cada Pedido de Compra, com seu número único, representa uma instância do processo de compras. Na análise de Process Mining, esse atributo é essencial para rastrear a jornada de ponta a ponta de cada compra. Ele permite visualizar mapas do processo, identificar variantes e calcular KPIs no nível do caso, como o tempo de ciclo total de um pedido. Todos os eventos e dados relacionados são agregados sob esse identificador para formar uma visão coesa do processo.
Por que é importante
É essencial para rastrear todo o ciclo de vida de cada compra, permitindo reconstruir instâncias individuais do processo para análise detalhada.
Onde obter
Este é um campo de chave primária padrão no objeto Purchase Order dentro 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
Esse atributo identifica o sistema de informação de origem onde os dados do evento foram registrados. Para este processo, o valor será sempre 'Coupa'. Em ambientes corporativos nos quais os dados podem vir de vários sistemas (ex.: Coupa para compras, outro ERP para faturamento), esse atributo ajuda a diferenciar as fontes de dados. Ele garante clareza na linhagem dos dados e pode ser usado para filtrar a análise para a visão de um sistema específico do processo.
Por que é importante
Fornece contexto crucial sobre a origem dos dados, garantindo rastreabilidade e permitindo a governança de dados adequada, especialmente em ambientes com múltiplos sistemas.
Onde obter
Este é um valor estático normalmente adicionado durante o processo de extração e transformação de dados para identificar o conjunto de dados.
Exemplos
Coupa
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O carimbo de data e hora que indica a última vez 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 inteiro, não a eventos individuais. Em qualquer dashboard analítico, esse timestamp é vital para que os usuários entendam a atualidade dos dados exibidos. Ele dá confiança de que os insights se baseiam em informações recentes e ajuda a definir expectativas sobre a atualização dos dados. Normalmente é exibido em destaque nos dashboards.
Por que é importante
Informa os usuários sobre a atualização dos dados, garantindo que entendam quão recentes são as análises de processo e os KPIs.
Onde obter
Esse timestamp é gerado e armazenado pelo pipeline de extração e carga de dados (ETL) quando é executado.
Exemplos
2023-11-01T05:00:00Z
|
|||
|
Categoria de compra
PurchaseCategory
|
A classificação dos bens ou serviços adquiridos, como hardware de TI ou serviços profissionais. | ||
|
Descrição
Categoria de compra, também chamada de Commodity ou Grupo de Materiais, é a classificação usada para agrupar tipos semelhantes de compras. Esse dado estruturado permite analisar gastos e processos de compras de forma sistemática. Em Process Mining, esse atributo é uma dimensão poderosa para filtragem e segmentação. O dashboard 'Spend Analysis by Purchase Category' se apoia nele para detalhar padrões de gasto. Ele também pode revelar se certas categorias (por exemplo, serviços complexos) têm tempos de ciclo maiores ou taxas de alteração mais altas do que outras (por exemplo, materiais de escritório).
Por que é importante
Permite analisar gastos e processo por categoria, ajudando a identificar padrões de compra, negociar com fornecedores e ajustar controles do processo.
Onde obter
Normalmente encontrado no nível do item do Pedido de Compra no Coupa, muitas vezes vinculado a um código de commodity ou a um catálogo de compras.
Exemplos
Hardware de TIMateriais de escritórioServiços profissionaisMateriais de marketing
|
|||
|
Departamento
Department
|
A área ou o centro de custo ao qual o pedido de compra será lançado. | ||
|
Descrição
O atributo Departamento especifica a unidade organizacional que iniciou a compra ou que arcará com seu custo. Geralmente ele está vinculado ao solicitante ou ao centro de custo informado nos itens do pedido de compra. Essa dimensão é essencial para segmentar a análise de processos e os KPIs. Ela permite comparar eficiência, conformidade e padrões de gastos entre diferentes áreas da organização. Por exemplo, o Dashboard 'Análise de Gastos por Categoria de Compra' usa o atributo Departamento para mostrar como as unidades de negócio estão usando seus orçamentos.
Por que é importante
Permite filtrar e comparar a análise de processo e de gastos entre diferentes unidades de negócio, revelando variações de eficiência e conformidade.
Onde obter
Disponível no cabeçalho ou nas linhas do Pedido de Compra no Coupa, muitas vezes 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 adquiridos. | ||
|
Descrição
O Nome do Fornecedor identifica a empresa que fornece os itens do Pedido de Compra. Essa informação é fundamental para a análise de compras. Analisar o desempenho do processo por fornecedor é crucial para a gestão de relacionamento com fornecedores. Ajuda a avaliar o 'Supplier Lead Time Performance', identificar atrasos em 'Goods Receipt Process Delays' e medir a qualidade do fornecedor por meio do 'Goods Return Rate'. Esse atributo também é essencial para calcular o KPI 'Spend by Non-Preferred Vendor Ratio'.
Por que é importante
Permite analisar o desempenho de fornecedores, ajudando a otimizar a seleção, negociar melhores condições e identificar fornecedores de alto ou baixo desempenho.
Onde obter
Campo padrão no cabeçalho do Pedido de Compra no Coupa, vinculado ao cadastro mestre de fornecedores.
Exemplos
Suprimentos de Escritório GlobaisTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Utilizador
User
|
O ID de usuário ou o nome de quem executou a atividade, como um aprovador ou solicitante. | ||
|
Descrição
Esse atributo identifica a pessoa responsável por executar um evento específico no processo. Pode ser quem redigiu o pedido, o gerente que aprovou ou o analista que lançou o recebimento. Analisar o desempenho por usuário ajuda a identificar necessidades de treinamento, profissionais de alto desempenho e a distribuição de carga de trabalho. Por exemplo, o dashboard 'PO Approval Cycle Time Performance' usa esse atributo para detalhar os tempos de aprovação por aprovador, destacando quem pode ser um gargalo no processo.
Por que é importante
Viabiliza a análise de performance do processo por pessoa ou por 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 logs de histórico do Pedido de Compra no Coupa. Campos como "Created By", "Approved By" e "Updated By" são fontes comuns.
Exemplos
j.doea.smithm.jones
|
|||
|
Valor total do Pedido de Compra
TotalOrderAmount
|
O valor total do Pedido de Compra. | ||
|
Descrição
Este atributo representa o valor total de todos os bens e serviços especificados no pedido de compra, expresso em uma determinada moeda. É um atributo no nível do caso que se aplica ao pedido como um todo. Esse dado financeiro é crucial para a análise de gastos e para priorizar esforços de melhoria de processos. Pedidos de alto valor podem exigir uma análise mais detalhada ou fluxos de aprovação diferentes. Ele é usado diretamente no dashboard 'Análise de Gastos por Categoria de Compras' e compõe o cálculo do KPI 'Percentual de Gastos com Fornecedores Não Preferenciais'.
Por que é importante
Fornece o contexto financeiro de cada compra, permitindo análise de gastos, priorização de pedidos de alto valor e avaliação do impacto financeiro.
Onde obter
Disponível no cabeçalho do Pedido de Compra no Coupa, geralmente como "Total" ou "Grand Total".
Exemplos
1500.00250.7512500.50
|
|||
|
Aprovação na primeira tentativa
IsFirstPassApproval
|
Um indicador calculado que é verdadeiro se o pedido de compra (PO) foi aprovado sem nenhuma alteração após ser criado. | ||
|
Descrição
Este indicador booleano é definido como verdadeiro quando a trajetória do pedido de compra de 'Purchase Order Drafted' até 'Purchase Order Approved' não contém atividades 'Purchase Order Changed' ou 'Purchase Order Rejected' entre esses pontos. Esse atributo mede diretamente o KPI 'Taxa de Aprovação do Pedido de Compra na Primeira Submissão'. Uma taxa alta indica processamento inicial eficiente e preciso. Analisar os casos em que esse indicador é falso ajuda a revelar causas de retrabalho e a melhorar a qualidade dos dados já na criação do pedido.
Por que é importante
Mede diretamente a eficiência da criação e da aprovação iniciais, destacando o volume de pedidos que passam sem retrabalho.
Onde obter
Calculado durante a transformação dos dados, analisando a sequência de eventos para cada PurchaseOrderNumber.
Exemplos
verdadeirofalse
|
|||
|
Data de entrega solicitada
RequestedDeliveryDate
|
A data em que o solicitante solicitou a entrega dos bens ou serviços. | ||
|
Descrição
Esse atributo é a data de entrega desejada informada pelo usuário de negócio durante o processo de requisição. Representa a expectativa do negócio sobre quando o pedido deve ser atendido. Essa data é um parâmetro crítico para medir o desempenho interno e dos fornecedores. Ela é usada diretamente para calcular o KPI 'Supplier Delivery Date Adherence', comparando-a à data real de 'Goods Receipt Posted'. O dashboard 'Delivery Date Variance and Returns' visualiza os desvios entre a data solicitada e a entrega real, ajudando a ajustar expectativas e melhorar o planejamento.
Por que é importante
Serve como linha de base de desempenho para medir a entrega no prazo dos fornecedores e a eficiência do processo interno de recebimento.
Onde obter
Campo padrão na linha do Pedido de Compra no Coupa.
Exemplos
2023-11-152023-12-012024-01-10
|
|||
|
É fornecedor preferencial
IsPreferredVendor
|
Um indicador booleano que informa se a compra foi feita de um fornecedor preferencial ou estratégico. | ||
|
Descrição
Este indicador identifica se o fornecedor do pedido de compra faz parte de uma lista pré-aprovada de fornecedores estratégicos. Normalmente isso é determinado cruzando o nome ou o ID do fornecedor com uma lista mestre de fornecedores preferenciais. Esse atributo é essencial para iniciativas de Strategic Sourcing e gestão de gastos. Ele é usado para calcular o KPI 'Percentual de Gastos com Fornecedores Não Preferenciais', que ajuda as organizações a monitorar e conter compras fora de política e a consolidar gastos com parceiros-chave para aproveitar descontos por volume e melhores condições.
Por que é importante
Ajuda a monitorar a Conformidade com as políticas de compras e metas de Strategic Sourcing ao acompanhar gastos com fornecedores preferenciais versus não preferenciais.
Onde obter
Geralmente não é um campo padrão no Coupa; é derivado comparando o Vendor ID do PO com uma lista externa de fornecedores preferenciais.
Exemplos
verdadeirofalse
|
|||
|
É Retrabalho
IsRework
|
Um indicador calculado que identifica se um pedido de compra passou por alguma atividade de alteração. | ||
|
Descrição
Este indicador booleano é definido como verdadeiro para todo pedido de compra que tenha pelo menos um evento 'Purchase Order Changed' em seu 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'. Permite filtrar e segmentar os dados com facilidade para comparar processos de pedidos com e sem retrabalho, ajudando a quantificar o impacto de mudanças no tempo de ciclo e no custo. É um componente central do dashboard 'Análise de Alterações no Pedido de Compra'.
Por que é importante
Simplifica a análise de retrabalho ao permitir filtrar e agregar com facilidade 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 da atividade "Purchase Order Changed" para cada PurchaseOrderNumber.
Exemplos
verdadeirofalse
|
|||
|
Entrega no prazo
IsDeliveryOnTime
|
Um indicador calculado que aponta se as mercadorias foram recebidas até a data de entrega solicitada. | ||
|
Descrição
Este atributo booleano é calculado comparando o timestamp do evento 'Goods Receipt Posted' com o 'RequestedDeliveryDate'. É definido como verdadeiro quando a data de recebimento ocorre na data solicitada ou antes. Esse indicador sustenta diretamente o KPI 'Aderência à Data de Entrega do Fornecedor' e o dashboard 'Variação da Data de Entrega e Devoluções'. Ele fornece um resultado binário e claro sobre pontualidade, fácil de agregar e visualizar, ajudando a identificar rapidamente problemas de desempenho de fornecedores ou do processo interno de recebimento.
Por que é importante
Fornece uma métrica clara e binária de desempenho de entrega, facilitando 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 "Goods Receipt Posted".
Exemplos
verdadeirofalse
|
|||
|
Local de recebimento
ReceivingLocation
|
O local físico, como um depósito ou escritório, onde as mercadorias devem ser entregues. | ||
|
Descrição
O Local de Recebimento especifica o destino dos itens pedidos no PO. Pode ser um depósito específico, uma planta (fábrica) ou um endereço de escritório. Esse atributo é usado para analisar logística e desempenho de recebimento entre diferentes locais. O dashboard 'Goods Receipt Process Delays' pode ser filtrado por esse atributo para identificar se certos locais são mais lentos para processar remessas recebidas, ajudando a apontar ineficiências operacionais ou restrições de recursos em locais específicos.
Por que é importante
Permite análise do processo de recebimento por localidade, evidenciando diferenças de performance entre centros de distribuição, fábricas ou escritórios.
Onde obter
Essa informação faz parte do endereço 'Ship-To' no Pedido de Compra no Coupa.
Exemplos
Armazém A - ChicagoBuilding 5 - London OfficeFrankfurt Plant
|
|||
|
Moeda
Currency
|
O código da moeda para os valores monetários no pedido de compra. | ||
|
Descrição
Este atributo indica a moeda (por exemplo, USD, EUR, GBP) na qual o Valor Total do Pedido está denominado. É essencial para interpretar corretamente dados financeiros em uma organização global. Em empresas multinacionais, analisar gastos sem considerar a moeda pode levar a conclusões equivocadas. Esse atributo permite a conversão de moeda adequada e relatórios financeiros consistentes nos dashboards, garantindo que os valores sejam comparados de forma equivalente.
Por que é importante
Garante análises e relatórios financeiros precisos em contextos multinacionais ao fornecer as informações necessárias para conversão de moeda.
Onde obter
Campo padrão no cabeçalho do Pedido de Compra 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 modificação de um Pedido de Compra, por exemplo, 'Quantity updated' ou 'Price correction'. Essa informação geralmente fica registrada na trilha de auditoria quando um usuário executa a atividade 'Purchase Order Changed'. Entender por que os pedidos são alterados é fundamental para o dashboard 'Purchase Order Change Analysis'. Isso ajuda a diferenciar mudanças inevitáveis (ex.: problemas de estoque no fornecedor) das evitáveis (ex.: erro no cadastro inicial), orientando esforços para melhorar a precisão dos pedidos e reduzir o KPI 'Purchase Order Change Rate'.
Por que é importante
Explica as causas raiz das alterações no Pedido de Compra, possibilitando ações direcionadas para melhorar o acerto de primeira e reduzir retrabalho no processo.
Onde obter
Geralmente encontrado nos logs de auditoria ou nos comentários associados aos eventos de alteração de um Pedido de Compra no Coupa.
Exemplos
Atualização de preço pelo 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 em uma etapa de aprovação. | ||
|
Descrição
Quando um aprovador rejeita um Pedido de Compra, geralmente informa um motivo. Este atributo registra essa justificativa textual, como "Código orçamentário incorreto" ou "Excede o limite de gasto". Analisar os motivos de rejeição dá visibilidade direta sobre as causas raiz de retrabalho e falhas de processo. Esses dados qualitativos ajudam a identificar erros comuns na etapa de requisição, orientando treinamentos direcionados ou melhorias no sistema para evitar novas rejeições e aumentar a taxa de aprovação na primeira submissão.
Por que é importante
Traz insights diretos e acionáveis sobre por que os Pedidos de Compra são rejeitados, ajudando a atacar as causas raiz de retrabalho e atrasos.
Onde obter
Geralmente capturado no campo de comentários ou notas associado à atividade "Purchase Order Rejected" ou "Purchase Requisition Rejected" no Workflow de aprovações do Coupa.
Exemplos
Solicitação duplicadaOrçamento não aprovadoFornecedor selecionado incorretamente
|
|||
|
Nome do solicitante
RequesterName
|
O nome da pessoa que inicialmente solicitou os bens ou serviços. | ||
|
Descrição
Esse atributo identifica o colaborador que criou a Requisição de Compra que originou o Pedido de Compra. O solicitante é o usuário de negócio com a necessidade, que pode ser diferente do comprador ou do aprovador. Analisar o comportamento do processo por solicitante ajuda a identificar padrões relacionados a usuários ou a áreas específicas. O dashboard 'Purchase Order Change Analysis' usa isso para verificar se certos solicitantes têm maior frequência de alterações no pedido, o que pode indicar necessidade de melhor treinamento sobre requisitos de especificação.
Por que é importante
Ajuda a identificar a área de negócio de origem da compra, permitindo analisar o comportamento de compras e a acurácia no nível do solicitante.
Onde obter
Essa informação geralmente é armazenada na Requisição de Compra de origem e é copiada para o Pedido de Compra no Coupa.
Exemplos
Alice CooperBob DylanCharlie Parker
|
|||
|
Número da requisição de compra
PurchaseRequisitionNumber
|
O identificador único da Requisição de Compra que antecedeu o Pedido de Compra. | ||
|
Descrição
Este atributo conecta um pedido de compra à requisição de compra que lhe deu origem. Uma única requisição pode resultar em um ou mais pedidos de compra. Essa ligação é essencial para analisar o tempo de ciclo completo de 'Requisição para Pedido'. Ao relacionar o evento de criação da requisição com os eventos de criação e envio do pedido de compra, as organizações conseguem medir a eficiência de toda a fase inicial do processo de compras, da solicitação ao atendimento.
Por que é importante
Conecta as fases de requisição e pedido do processo, permitindo analisar o tempo de ciclo da requisição ao pedido e as taxas de conversão.
Onde obter
Geralmente é um campo de referência nos itens do Pedido de Compra (PO) no Coupa, que referencia a requisição de origem.
Exemplos
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
Tempo de Processamento
ProcessingTime
|
A duração de uma atividade, representando o tempo em que um usuário trabalhou ativamente em uma tarefa. | ||
|
Descrição
Tempo de processamento, também chamado de 'tempo de serviço', é o período gasto trabalhando ativamente em uma tarefa. Difere do tempo de espera. Por exemplo, pode medir o intervalo entre o momento em que o usuário abre uma tarefa de aprovação de PO e o envio da aprovação. Essa métrica oferece uma visão mais precisa do esforço do usuário em comparação ao tempo de ciclo, que inclui períodos de espera. Analisar o tempo de processamento ajuda no planejamento de capacidade, no balanceamento da carga de trabalho e na identificação de tarefas inerentemente demoradas. Ela exige registros de início e fim de uma única atividade, algo que nem sempre está disponível.
Por que é importante
Ajuda a diferenciar o tempo de trabalho ativo do tempo de espera, oferecendo melhores insights sobre a eficiência de recursos e a complexidade das tarefas.
Onde obter
Calculado se os timestamps de início e fim de uma mesma atividade estiverem disponíveis nos logs de auditoria do Coupa. Isso geralmente não é padrão.
Exemplos
3600120900
|
|||
Purchase to Pay - Atividades de Pedido de compra
| Atividade | Descrição | ||
|---|---|---|---|
|
Pedido de Compra aprovado
|
Esse marco indica que o Pedido de Compra concluiu o Workflow interno de aprovações e está autorizado para emissão ao fornecedor. Geralmente é a etapa final em um processo com várias aprovações. | ||
|
Por que é importante
Este é um marco crítico para calcular o tempo de ciclo de aprovação do PO e identificar gargalos de aprovação. Também funciona como um ponto-chave de conformidade.
Onde obter
Capturado no log de histórico de aprovação do Pedido de Compra no Coupa. O timestamp da aprovação final fornece a data e hora do evento.
Captura
Registrado no histórico de aprovações quando o aprovador final conclui sua tarefa.
Tipo de evento
explicit
|
|||
|
Pedido de Compra cancelado
|
Essa atividade representa o cancelamento de um Pedido de Compra antes de sua conclusão. O cancelamento pode ocorrer em várias etapas, por exemplo, se a solicitação deixou de ser necessária ou se o PO foi criado por engano. | ||
|
Por que é importante
Como término alternativo do processo, acompanhar cancelamentos é essencial para entender desistências no fluxo e identificar os motivos de requisições de compra abandonadas.
Onde obter
Isso é inferido a partir da alteração de status do objeto Purchase Order para 'Canceled'. O timestamp dessa mudança de status é usado como hora do evento.
Captura
Derivado do timestamp da mudança de status para 'Canceled'.
Tipo de evento
inferred
|
|||
|
Pedido de Compra encerrado
|
Esta é a atividade final, indicando que o pedido de compra está concluído. O PO é considerado fechado quando foi totalmente recebido e totalmente faturado, sem expectativa de novas transações. | ||
|
Por que é importante
Essa atividade encerra oficialmente o ciclo de vida do PO. Analisar o tempo de fechamento pode revelar ineficiências na conciliação final e no arquivamento.
Onde obter
Isso é inferido a partir da alteração de status do objeto Purchase Order para 'Closed'. Esse status costuma ser definido automaticamente pelo Coupa com base em regras de negócio sobre tolerâncias de recebimento e faturamento.
Captura
Derivado do timestamp da mudança de status para 'Closed'.
Tipo de evento
inferred
|
|||
|
Pedido de compra enviado ao fornecedor
|
Essa atividade marca o momento em que o Pedido de Compra aprovado é oficialmente enviado ao fornecedor, por exemplo, por e-mail ou pelo Coupa Supplier Portal. Esse evento transforma o PO de um documento interno em um compromisso externo. | ||
|
Por que é importante
Este é um marco importante que conclui o ciclo interno de 'Requisição para Pedido' e inicia o lead time do fornecedor. É vital para medir tanto a eficiência interna quanto o desempenho dos fornecedores.
Onde obter
Geralmente inferido a partir de uma mudança de status do PO para 'Ordered' ou 'Sent'. O Coupa também pode ter um carimbo de data e hora específico, 'last_exported_at' ou 'sent_to_supplier_at', no registro do PO.
Captura
Derivado do timestamp da mudança de status para 'Ordered' ou de um campo específico de timestamp de transmissão.
Tipo de evento
inferred
|
|||
|
Recebimento lançado
|
Esta é a confirmação formal de que as mercadorias foram recebidas, inspecionadas e aceitas. Esse evento atualiza os registros de estoque e indica que a obrigação do fornecedor com esta entrega foi cumprida. | ||
|
Por que é importante
Este marco crítico sinaliza o fim do lead time do fornecedor e é usado para medir a aderência à data de entrega. Atrasos no lançamento dos recebimentos podem prejudicar 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 recibo muda para 'Posted' ou 'Received'.
Captura
Registrado quando a transação de recebimento de mercadorias é finalizada no sistema.
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. No Coupa, é um evento explícito capturado quando um usuário salva e envia uma nova requisição. | ||
|
Por que é importante
Por ser o ponto de partida típico do processo de compras, essa atividade é essencial para medir o tempo de ciclo completo da Requisição ao Pedido e avaliar a eficiência das etapas iniciais.
Onde obter
Esse evento corresponde ao registro de criação no objeto ou tabela de Requisições de Compra no Coupa. O timestamp pode ser encontrado no campo 'created_at' ou equivalente gerado pelo sistema.
Captura
Registrado automaticamente na criação de uma nova requisição.
Tipo de evento
explicit
|
|||
|
Confirmação de serviços registrada
|
Para Pedidos de Compra de serviços, essa atividade é equivalente a um recebimento de materiais. Ela confirma que o serviço foi prestado conforme os termos do Pedido de Compra. | ||
|
Por que é importante
Acompanhar confirmações de serviço é crucial para controlar o gasto com serviços e garantir que os pagamentos só ocorram após a validação da conclusão do serviço.
Onde obter
Esse evento é capturado a partir da criação ou aprovação de um recibo de serviço ou de uma folha de lançamento de serviços vinculada ao Pedido de Compra no Coupa.
Captura
Registrado na criação e aprovação de um Service Entry Sheet.
Tipo de evento
explicit
|
|||
|
Fatura recebida para o PO
|
Esse evento marca o recebimento e o lançamento de uma fatura do fornecedor que referencia o pedido de compra. Ele indica o início da fase de processamento de faturas e pagamento do ciclo P2P. | ||
|
Por que é importante
Embora faça parte do processo de Contas a Pagar (AP), vincular o recebimento da fatura ao Pedido de Compra oferece uma visão ponta a ponta do ciclo 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 da Fatura (Invoice) no Coupa, onde a fatura é conciliada com o número do Pedido de Compra correspondente.
Captura
Registrado na criação de um registro de fatura vinculado ao PO.
Tipo de evento
explicit
|
|||
|
Fornecedor confirmou o Pedido de Compra
|
Esse evento indica que o fornecedor recebeu e confirmou o pedido de compra. Essa confirmação costuma ser registrada eletronicamente por meio de um portal de fornecedores, como o Coupa Supplier Portal (CSP). | ||
|
Por que é importante
Confirmações do fornecedor dão segurança de que o pedido está sendo processado, melhoram a precisão da previsão de entrega e reduzem a incerteza na cadeia de suprimentos.
Onde obter
Essa informação normalmente está disponível no Pedido de Compra quando o fornecedor usa o Coupa Supplier Portal para realizar a ação 'Acknowledge'. O timestamp dessa ação é utilizado.
Captura
Registrado quando o fornecedor executa a ação 'Acknowledge' no portal do fornecedor.
Tipo de evento
explicit
|
|||
|
Inspeção de qualidade realizada
|
Esse evento indica que um item recebido passou por inspeção de qualidade e foi aprovado. Dependendo do processo da empresa, pode ser uma etapa separada após o registro inicial do recebimento de mercadorias. | ||
|
Por que é importante
Essa atividade é fundamental para medir a eficiência do processo de controle de qualidade. Atrasos aqui podem gerar gargalos entre o recebimento e a disponibilidade para uso.
Onde obter
Isso pode ser registrado como uma alteração de status no item do 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 por uma mudança de status no recebimento ou pelo timestamp em um registro de inspeção relacionado.
Tipo de evento
inferred
|
|||
|
Materiais devolvidos
|
Essa atividade é registrada quando itens já recebidos são devolvidos ao fornecedor. Normalmente ocorre por problemas de qualidade, danos ou remessas incorretas. | ||
|
Por que é importante
Monitorar devoluções é essencial para calcular a Taxa de Devolução de Mercadorias e identificar problemas de qualidade do fornecedor ou de acurácia do pedido. Taxas altas de devolução costumam indicar falhas de processo onerosas.
Onde obter
Este evento é capturado a partir de uma transação 'Return to Supplier' ou de um recebimento negativo no Coupa. O timestamp dessa transação serve como hora do evento.
Captura
Registrado quando é criada uma transação de devolução vinculada ao PO/recebimento original.
Tipo de evento
explicit
|
|||
|
Pedido de Compra alterado
|
Esse evento representa qualquer modificação feita no pedido de compra após sua elaboração inicial. No Coupa, as mudanças geralmente são acompanhadas por meio do versionamento do documento do PO. | ||
|
Por que é importante
Acompanhar as alterações é fundamental para KPIs como Taxa de Alteração de Pedido de Compra e Taxa de Pedido de Compra Não Conforme. Mudanças frequentes indicam instabilidade do processo ou requisições iniciais imprecisas.
Onde obter
Pode ser inferido acompanhando diferentes versões de um Pedido de Compra. Cada novo número de versão maior que o inicial indica uma alteração, usando a data de criação da nova versão como timestamp do evento.
Captura
Inferido pelo timestamp de criação de uma nova versão do PO.
Tipo de evento
inferred
|
|||
|
Pedido de compra enviado para aprovação
|
Depois que um Pedido de Compra é elaborado, ele é submetido formalmente ao workflow de aprovação. Essa é uma ação do usuário que move o pedido do estado de rascunho para "pendente de aprovação". | ||
|
Por que é importante
Esse evento separa o tempo de elaboração do tempo em que o pedido de fato aguarda aprovação. Traz uma visão mais clara do comportamento dos usuários e das transferências entre áreas no processo.
Onde obter
Inferido a partir de uma mudança de status no objeto Pedido de Compra, por exemplo, de 'draft' para 'pending approval'. Usa-se o timestamp dessa mudança específica de status.
Captura
Derivado do timestamp da mudança de status para 'pending approval'.
Tipo de evento
inferred
|
|||
|
Pedido de Compra rejeitado
|
Essa atividade ocorre quando um aprovador rejeita o Pedido de Compra durante o workflow de aprovação. O PO normalmente é devolvido ao criador para revisão ou cancelamento. | ||
|
Por que é importante
Analisar rejeições ajuda a descobrir problemas de qualidade dos dados, violações de políticas ou lacunas de treinamento. Isso evidencia ciclos de retrabalho que geram atrasos relevantes no processo.
Onde obter
Este é um evento explícito capturado no log do histórico de aprovações do Purchase Order no Coupa. O log exibirá uma ação 'Reject' com o timestamp correspondente.
Captura
Registrado no histórico de aprovações com status 'Reject'.
Tipo de evento
explicit
|
|||
|
Rascunho de Pedido de Compra criado
|
Esse evento representa a criação inicial do documento de Pedido de Compra no sistema, muitas vezes a partir de uma requisição aprovada. Nessa etapa, o PO é um rascunho interno e ainda não foi enviado para aprovação nem encaminhado ao fornecedor. | ||
|
Por que é importante
Essa atividade inicia a contagem para medir o KPI de Tempo de Ciclo de Aprovação do PO. É o primeiro passo formal do ciclo de vida do próprio Pedido de Compra.
Onde obter
Corresponde ao timestamp de criação do registro de Pedido de Compra no Coupa, geralmente disponível em um campo como 'created_at'.
Captura
Capturado a partir do timestamp de criação gerado pelo sistema para o registro do Pedido de Compra.
Tipo de evento
explicit
|
|||
|
Recebimento iniciado
|
Essa atividade representa o início do processo de recebimento, como quando um documento de recebimento é criado no Coupa na chegada física dos itens. Os itens ainda não foram formalmente lançados no estoque nem confirmados como recebidos. | ||
|
Por que é importante
Esse evento é o ponto de partida para medir o KPI 'Tempo de Processamento do Recebimento de Mercadorias'. Ele ajuda a diferenciar o tempo em que os materiais ficam aguardando na doca do tempo gasto no processamento no sistema.
Onde obter
Isso pode ser inferido a partir do timestamp de criação de um documento de recebimento nos status 'Draft' ou 'Pending'. Esse momento antecede o lançamento final do recebimento.
Captura
Derivado do timestamp de criação de um registro de recebimento ainda não lançado.
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 um pedido de compra. Este evento indica a aprovação final da requisição, deixando-a pronta para gerar o pedido. | ||
|
Por que é importante
Acompanhar as aprovações de requisição ajuda a identificar gargalos na fase anterior ao pedido. Atrasos aqui impactam diretamente a velocidade de emissão do Pedido de Compra.
Onde obter
Normalmente é capturado no histórico de aprovações da requisição no Coupa. A aprovação final terá um timestamp e um usuário correspondentes.
Captura
Registrado no histórico de aprovações quando o aprovador final realiza a ação.
Tipo de evento
explicit
|
|||