> Melhoria contínua de processos > Compras ao pagamento, requisição > Microsoft Dynamics 365 > Template de dados

Seu Template de dados para requisições de compra

Microsoft Dynamics 365

Atributos de requisições de compra(17) Atividades de requisições de compra(12) Guias de extração(3)

Seu Template de dados para requisições de compra

Este Template apresenta os principais atributos a coletar e as atividades essenciais a acompanhar, permitindo uma análise detalhada do processo de requisição. Ele também traz orientações práticas para extrair esses dados e preparar seu Event Log para uma análise aprofundada.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações para extração

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

Atributos de requisições de compra

Estes são os campos de dados recomendados para incluir no Event Log e analisar de forma abrangente seu processo de requisição de compra.

5 Obrigatório 6 Recomendado 6 Opcional

	Nome	Descrição
	Data e hora do evento EventTime	Data e hora exatas em que uma atividade ou um evento específico ocorreu.
Descrição A data e hora do evento registram quando um evento de negócio foi registrado no sistema. Esse dado é a base temporal de todas as análises de processo relacionadas ao tempo. Este atributo é essencial para calcular tempos de ciclo, durações e tempos de espera entre atividades. Ele permite analisar a performance do processo, identificar gargalos e monitorar o cumprimento de SLAs. Datas e horas precisas são fundamentais para uma análise confiável de Process Mining. Por que isso importa Este atributo estabelece a ordem cronológica dos eventos, necessária para calcular a duração dos processos, identificar gargalos e analisar a performance ao longo do tempo. Onde encontrar Esse dado costuma estar nas tabelas de histórico do fluxo de trabalho ou de registros de documentos, geralmente em um campo 'CreatedDateTime' ou 'ModifiedDateTime' associado a cada mudança de status ou registro de evento. Exemplos 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	ID da requisição de compra PurchaseRequisitionId	Identificador exclusivo de uma requisição de compra, usado como identificador principal do caso.
Descrição O ID da requisição de compra é a chave central que vincula todas as atividades relacionadas a uma solicitação de produtos ou serviços. Cada processo de requisição, da criação à aprovação final e ao encerramento, é acompanhado por esse ID exclusivo. No Process Mining, esse atributo é fundamental para reconstruir a jornada completa de cada requisição. Ele permite analisar variantes do processo, tempos de ciclo e conformidade em cada caso, oferecendo uma visão completa do ciclo de vida da requisição. Por que isso importa Esse atributo é essencial para agrupar todos os eventos relacionados em uma única instância do processo e permitir uma análise completa, de ponta a ponta, do ciclo de vida de cada requisição. Onde encontrar Em geral, essa é a chave primária da tabela principal de cabeçalho das requisições de compra, como a PurchReqTable no Microsoft Dynamics 365. Exemplos RC-001254RC-001255RC-001256
	Nome da atividade ActivityName	Nome do evento ou da etapa de negócio específica que ocorreu no processo de requisição.
Descrição Este atributo registra o nome de cada atividade realizada durante o ciclo de vida da requisição de compra. Alguns exemplos são 'Requisição criada', 'Etapa de aprovação aprovada' e 'Pedido de compra criado'. Essas atividades formam os nós do mapa de processo descoberto. Analisar a sequência, a frequência e a duração entre essas atividades é a base do Process Mining. Isso ajuda a identificar gargalos, ciclos de retrabalho e desvios do fluxo de processo padrão, revelando ineficiências operacionais. Por que isso importa Este atributo define as etapas do mapa de processo e permite visualizar, analisar e entender o fluxo de trabalho das requisições. Onde encontrar Em geral, esse dado é obtido de registros de mudança de status, tabelas de histórico do fluxo de trabalho ou tabelas de eventos específicas do Microsoft Dynamics 365, como a WorkflowTrackingStatusTable. Exemplos Requisição enviada para aprovaçãoEtapa de aprovação aprovadaRequisição alterada
	Sistema de origem SourceSystemId	Sistema de registro de onde os dados foram extraídos.
Descrição Este atributo identifica o sistema de origem dos dados de eventos. Neste contexto, o valor seria 'Microsoft Dynamics 365'. Em ambientes com vários sistemas integrados, esse campo é essencial para rastrear a origem dos dados e entender seu contexto. Na análise, ele ajuda a diferenciar processos que podem passar por vários sistemas ou confirma que os dados vêm de uma única fonte oficial. Isso é importante para validar os dados e garantir que a análise use o conjunto de dados correto. Por que isso importa Este atributo informa a origem dos dados, algo essencial para a governança e a validação dos dados, especialmente em ambientes com vários sistemas integrados. Onde encontrar Este é um valor estático, 'Microsoft Dynamics 365', adicionado durante o processo de extração e transformação dos dados. Exemplos Microsoft Dynamics 365 F&OD365MSD365
	Última atualização dos dados LastDataIngestionTimestamp	Data e hora da última extração dos dados e do carregamento na ferramenta de Process Mining.
Descrição Este atributo indica o nível de atualização dos dados analisados. Ele mostra a data e hora da atualização mais recente dos dados do sistema de origem. Não é um campo do próprio Dynamics 365, mas metadados adicionados durante a ingestão dos dados. Essa informação é essencial para que os usuários entendam o quanto os insights são atuais. Ela ajuda a saber se os dados são em tempo real ou representam um instantâneo de um momento específico, o que afeta a relevância das conclusões. Por que isso importa Este atributo informa aos usuários o quanto os dados são atuais, ajudando a entender o período analisado e a relevância dos insights. Onde encontrar Este valor é gerado e adicionado ao conjunto de dados durante a ingestão ou o processo de ETL. Exemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Departamento Department	Departamento de quem solicitou ou centro de custo associado à requisição.
Descrição Este atributo especifica o departamento da empresa ou o centro de custo que iniciou a requisição de compra, como 'Marketing', 'TI' ou 'Operações'. Em geral, essa informação faz parte do cabeçalho da requisição. Segmentar o processo por departamento é essencial para fazer análises comparativas. Assim, você identifica quais departamentos têm os ciclos mais longos, as maiores taxas de rejeição ou mais alterações. Esses insights ajudam a adaptar as melhorias do processo às necessidades de cada departamento. Por que isso importa Este atributo permite filtrar e comparar a performance do processo entre diferentes unidades de negócio, revelando padrões, gargalos ou ineficiências específicos de cada departamento. Onde encontrar Essas informações costumam ficar no cabeçalho da requisição de compra (PurchReqTable) e vinculadas à configuração das dimensões financeiras no Dynamics 365. Exemplos Departamento de TIFinançasOperações
	Etapa de aprovação ApprovalStep	O nome ou a etapa de uma fase específica do fluxo de trabalho de aprovação.
Descrição Este atributo identifica uma etapa específica do fluxo de trabalho de aprovação, como 'Aprovação do gerente' ou 'Aprovação de Finanças'. Ele oferece mais detalhes do que o nome geral da atividade. Este atributo é essencial para a 'Análise de gargalos nas etapas de aprovação'. Ao acompanhar o tempo gasto em cada etapa, você consegue identificar exatamente quais fases estão causando atrasos no processo. Assim, fica mais fácil direcionar ações para melhorar a eficiência do fluxo de trabalho. Por que isso importa Ele permite analisar o fluxo de trabalho de aprovação em detalhes e identificar as etapas específicas que estão causando gargalos. Onde encontrar Essas informações estão nas tabelas de histórico do fluxo de trabalho, como WorkflowTrackingStatusTable, que detalha cada etapa do fluxo configurado. Exemplos Aprovação do gerenteAprovação do chefe do departamentoAnálise de Finanças
	Nível de urgência UrgencyLevel	Classificação da urgência da requisição, como 'Alta', 'Média' ou 'Baixa'.
Descrição O nível de urgência, ou prioridade, indica em quanto tempo os produtos ou serviços solicitados são necessários. Esse atributo costuma influenciar o caminho de aprovação ou a priorização do trabalho dos aprovadores. Analisar esse atributo ajuda a avaliar se o sistema de prioridades funciona. Por exemplo, você pode comparar os tempos de ciclo das requisições de urgência 'Alta' com os das requisições de urgência 'Baixa'. Se não houver uma diferença significativa, isso pode indicar que o campo de prioridade está sendo ignorado ou usado incorretamente. Esse é um insight importante para o Dashboard 'Análise do impacto do nível de urgência'. Por que isso importa Ele ajuda a avaliar se as prioridades definidas aceleram solicitações críticas e revela possíveis usos indevidos da classificação de urgência. Onde encontrar Pode ser um campo padrão ou personalizado na PurchReqTable. A existência e o nome do campo podem variar conforme a configuração do sistema. Exemplos AltaMédiaBaixa
	Status da requisição RequisitionStatus	O status atual ou final da requisição de compra.
Descrição Este atributo indica o status geral da requisição de compra em determinado momento, como 'Em análise', 'Aprovado', 'Rejeitado' ou 'Encerrado'. Em geral, é um atributo no nível do caso que representa o resultado final. Analisar o status final ajuda a entender os resultados gerais do processo. Por exemplo, um número elevado de requisições 'Rejeitadas' ou 'Retiradas' pode indicar problemas na etapa inicial da solicitação ou um processo de aprovação complexo. Esse atributo é essencial para medir as taxas de sucesso e a eficiência do processo. Por que isso importa Ele apresenta um resultado claro para cada caso e permite analisar as taxas de aprovação, rejeição e retirada, que são indicadores-chave de performance. Onde encontrar O campo de status geralmente fica na tabela de cabeçalho da requisição de compra, PurchReqTable, e costuma se chamar 'Status' ou 'PurchReqStatus'. Exemplos AprovadoEm análiseRejeitadoRascunho
	Usuário User	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 executar uma etapa específica do processo, como enviar uma requisição ou aprovar uma solicitação. Pode ser um ID de usuário, nome completo ou endereço de e-mail. Analisar as atividades por usuário ajuda a identificar necessidades de treinamento, pessoas ou equipes com alta performance e a distribuição da carga de trabalho. Também é essencial para a análise de conformidade, como a segregação de funções, e para entender como diferentes funções de usuário interagem com o processo. Por que isso importa Este atributo permite analisar o comportamento, a carga de trabalho e a performance de cada usuário, aspectos importantes para gerenciar recursos e identificar oportunidades de treinamento. Onde encontrar Em geral, esse dado está nas tabelas de histórico do fluxo de trabalho (por exemplo, WorkflowTrackingStatusTable) ou nas tabelas de transações (por exemplo, PurchReqTable), vinculadas a uma tabela de usuários (por exemplo, UserInfo). Exemplos j.silvaa.souzas.pereira
	Valor total da requisição RequisitionTotalAmount	O valor monetário total da requisição de compra.
Descrição Este atributo registra o valor total de todos os itens da requisição de compra. Esse valor costuma influenciar a complexidade do fluxo de trabalho de aprovação: requisições de maior valor podem exigir mais etapas de aprovação. Na análise de processos, este atributo é essencial para filtrar e analisar os dados por valor. Ele ajuda a responder perguntas como: 'Requisições de alto valor demoram mais para ser aprovadas?' ou 'Qual é o valor das requisições atualmente paradas no processo?'. Assim, você entende o contexto financeiro da performance do processo. Por que isso importa Ele acrescenta uma dimensão financeira à análise, permitindo priorizar casos de alto valor e entender como o valor monetário afeta o comportamento do processo. Onde encontrar Esse valor geralmente está na tabela de cabeçalho da requisição de compra ou é calculado pela soma dos valores dos itens na tabela de linhas da requisição (PurchReqLine). Exemplos 1500.0025000.50500.75
	Aprovada na primeira tentativa IsFirstPass	Indicador que mostra se uma requisição foi aprovada sem alterações ou rejeições anteriores.
Descrição Este atributo booleano calculado é 'true' quando o caminho da requisição até a aprovação não inclui as atividades 'Requisição alterada' nem 'Etapa de aprovação rejeitada'. Caso contrário, é 'false'. Este atributo dá suporte direto ao KPI 'Taxa de aprovação de requisições na primeira tentativa'. Ele simplifica a análise da eficiência do processo ao indicar retrabalho no nível do caso. Uma taxa baixa de aprovações na primeira tentativa destaca problemas na qualidade dos dados iniciais ou falta de clareza nos requisitos, indicando uma oportunidade de melhoria do processo. Por que isso importa Ele mede diretamente a qualidade e a eficiência do processo ao identificar casos que exigiram retrabalho e dá suporte a KPIs que acompanham a taxa de acerto na primeira tentativa. Onde encontrar Este atributo é calculado. Durante a transformação dos dados, é preciso analisar a sequência completa de atividades de cada caso e verificar se houve retrabalho antes da aprovação. Exemplos truefalse
	Caminho do fluxo de trabalho de aprovação ApprovalWorkflowPath	Representação da sequência de etapas de aprovação realizadas.
Descrição Este atributo é um campo derivado que concatena a sequência de etapas de aprovação de uma requisição, como 'Aprovação do gerente -> Aprovação do chefe do departamento -> Aprovação de Finanças'. Ele resume a variante do processo para o subprocesso de aprovação. Esse atributo é essencial para o Dashboard 'Monitor de desvios de conformidade'. Ao comparar o caminho real do fluxo de trabalho com um caminho padrão ou esperado, fica mais fácil sinalizar fluxos fora de conformidade ou incomuns, que podem indicar violações de políticas ou riscos operacionais. Por que isso importa Ele simplifica a análise de conformidade ao apresentar a variante do processo em um formato claro, facilitando a identificação de desvios dos procedimentos padrão. Onde encontrar Este atributo não é um campo padrão. Ele deve ser derivado pela concatenação dos valores de 'ApprovalStep' em ordem cronológica para cada caso, durante a transformação dos dados. Exemplos Gerente -> DiretorGerente -> Diretor -> VP de FinançasGerente -> Aprovado automaticamente
	Grupo de aprovadores ApproverGroup	O grupo de usuários ou a função responsável por uma etapa de aprovação.
Descrição Este atributo identifica o grupo, a função ou a fila responsável por uma tarefa de aprovação específica, como 'Aprovadores de Finanças' ou 'Gerentes de TI'. Analisar a performance do processo por grupo de aprovadores é essencial para entender a distribuição da carga de trabalho e identificar grupos com poucos recursos ou que precisam de treinamento adicional. O atributo também dá suporte direto ao Dashboard 'Análise de gargalos nas etapas de aprovação', permitindo segmentar a performance por equipe responsável pelas aprovações. Por que isso importa Ele ajuda a identificar diferenças de performance entre as equipes de aprovação e destaca possíveis limitações de recursos ou necessidades de treinamento em grupos específicos. Onde encontrar Essas informações fazem parte do histórico do fluxo de trabalho, por exemplo, da WorkflowTrackingStatusTable, que registra o usuário ou grupo de usuários designado para cada tarefa. Exemplos Aprovadores de FinançasGerentes de TIAlta liderança
	Moeda Currency	O código da moeda usada no valor da requisição.
Descrição Este atributo especifica a moeda, como USD, EUR ou GBP, em que o valor total da requisição está expresso. Ele é essencial para a análise financeira, especialmente em organizações multinacionais que trabalham com várias moedas. O atributo de moeda permite tratar e agregar os dados financeiros corretamente. Ele garante que os valores monetários sejam interpretados de forma adequada e possibilita convertê-los para uma moeda comum, facilitando relatórios e comparações precisas entre diferentes regiões ou unidades de negócio. Por que isso importa Ele fornece o contexto necessário para os atributos financeiros, garantindo a interpretação e a agregação corretas dos valores monetários em ambientes com várias moedas. Onde encontrar Esse campo geralmente fica na tabela de cabeçalho da requisição de compra, PurchReqTable, junto aos campos de valor. Exemplos USDEURGBP
	Número de alterações AmendmentCount	O número total de vezes que uma requisição foi alterada.
Descrição Este atributo numérico calculado conta quantas vezes a atividade 'Requisição alterada' ocorre em cada caso de requisição de compra. Este atributo é essencial para o Dashboard 'Frequência de alterações em requisições' e para o KPI 'Taxa de alterações em requisições'. Ele quantifica o retrabalho por caso e facilita a identificação de requisições, departamentos ou usuários associados a muitas alterações e à ineficiência. Assim, você pode direcionar esforços para melhorar a qualidade das solicitações iniciais. Por que isso importa Ele quantifica o retrabalho em cada caso e facilita a medição e a análise da frequência das alterações e de seu impacto na eficiência do processo. Onde encontrar Este atributo é calculado durante a transformação dos dados, contando as atividades 'Requisição alterada' para cada PurchaseRequisitionId exclusivo. Exemplos 013
	Número do pedido de compra PurchaseOrderNumber	O identificador do pedido de compra criado a partir da requisição.
Descrição Este atributo armazena o ID exclusivo do pedido de compra gerado a partir de uma requisição aprovada. Ele conecta o processo de requisição à etapa seguinte do processo de compras. Acompanhar esse número é essencial para analisar o 'Tempo de conversão de requisição em pedido de compra'. Ele confirma que a requisição avançou para a próxima etapa do ciclo de compras e pagamentos e permite analisar o processo de ponta a ponta, abrangendo requisições e pedidos de compra. Por que isso importa Ele conecta a requisição ao pedido de compra correspondente, permitindo analisar a conversão de requisição em pedido e relacionar diferentes etapas do processo de compras e pagamentos. Onde encontrar Depois que um pedido de compra é criado, essas informações geralmente ficam na tabela de linhas da requisição de compra (PurchReqLine), vinculadas à PurchTable. Exemplos PO-000987PO-000988PO-000989

Obrigatório Recomendado Opcional

Atividades de requisições de compra

Estas são as etapas e os marcos essenciais do processo a registrar no Event Log para descobrir e analisar com precisão o fluxo de trabalho de requisições.

7 Recomendado 5 Opcional

	Atividade	Descrição
	Etapa de aprovação aprovada	O responsável conclui a tarefa atribuída e aprova a requisição naquela etapa do processo. A requisição segue para a próxima etapa ou para a aprovação final.
Por que isso importa Mede o tempo de processamento de cada etapa de aprovação e ajuda a identificar os trechos mais eficientes do fluxo de trabalho. É um componente importante da análise de variantes. Onde encontrar O evento é registrado explicitamente na 'WorkflowTrackingStatusTable' quando um usuário conclui um item de trabalho com o resultado 'Approve'. Coleta Identifique nos registros do histórico do fluxo de trabalho os eventos 'WorkItemCompleted' com o resultado 'Approve'. Tipo de evento explicit
	Pedido de compra criado	Uma linha aprovada da requisição de compra é convertida em uma linha de pedido de compra, marcando a transferência para a equipe de compras. O evento é identificado pela associação entre a linha da requisição e a linha do pedido de compra.
Por que isso importa Este é um marco importante que conecta a requisição ao processo de compras subsequente. É essencial para medir o KPI 'Tempo de conversão de requisição em pedido de compra'. Onde encontrar O evento é inferido pela identificação de um registro na tabela 'PurchLine' que referencia o ID de uma 'PurchReqLine' associada ao caso da requisição. Coleta Faça a junção de PurchReqLine com PurchLine pelo campo de referência que as vincula (por exemplo, PurchReqLineRefId). Tipo de evento inferred
	Requisição aprovada	A requisição passou por todas as etapas de aprovação exigidas no fluxo de trabalho. Esta atividade é registrada quando a instância do fluxo de trabalho é concluída com status de aprovação final.
Por que isso importa Este é um marco importante: encerra o ciclo de aprovação e dá início à etapa de compras. É o evento final do KPI 'Tempo do ciclo de aprovação da requisição'. Onde encontrar O evento é registrado explicitamente na 'WorkflowTrackingStatusTable' quando o fluxo de trabalho é concluído. Isso também atualiza o campo 'Status' da 'PurchReqTable' para 'Approved'. Coleta Filtre os eventos de 'Completion' do fluxo de trabalho com status 'Approved' ou acompanhe a mudança de status na PurchReqTable. Tipo de evento explicit
	Requisição criada	Este evento marca a criação inicial do registro da requisição de compra, com status de rascunho. Ele é identificado pela data e hora de criação do cabeçalho da requisição.
Por que isso importa Como início do processo, esta atividade é essencial para medir o tempo total do ciclo de vida das requisições e analisar o volume diário de requisições processadas. Onde encontrar Esta atividade é inferida do campo 'createdDateTime' da tabela 'PurchReqTable' para cada novo ID de requisição de compra. Coleta Use a data e hora de criação do registro na PurchReqTable. Tipo de evento inferred
	Requisição encerrada	A requisição de compra inteira é considerada concluída quando todas as linhas são processadas em pedidos de compra ou canceladas. Este é um estado final de sucesso.
Por que isso importa Esta atividade marca a conclusão bem-sucedida do ciclo de vida da requisição. É o ponto final para medir a duração total do processo de ponta a ponta. Onde encontrar Em geral, esse status é calculado ou inferido. Ele ocorre quando todos os registros 'PurchReqLine' associados atingem um status final, como 'Closed' ou 'Cancelled'. Coleta Derive este evento verificando se todos os registros filhos PurchReqLine de uma PurchReqTable têm um status final. Tipo de evento calculated
	Requisição enviada para aprovação	O usuário envia a requisição preenchida, iniciando o fluxo formal de aprovação. O mecanismo de Workflow do sistema registra essa ação explícita.
Por que isso importa Esta atividade é um marco importante que dá início ao ciclo de aprovação. Ela é o ponto de partida para medir o 'Tempo do ciclo de aprovação da requisição' e a 'Taxa de aprovação na primeira tentativa'. Onde encontrar O evento é registrado na 'WorkflowTrackingStatusTable' ou em uma tabela semelhante de histórico do fluxo de trabalho, quando uma 'Submission' é associada à requisição de compra. Coleta Filtre os registros do histórico do fluxo de trabalho pelo tipo de evento 'Submission' ou 'Start' associado à requisição. Tipo de evento explicit
	Requisição rejeitada	A requisição foi rejeitada durante o fluxo de aprovação e não será processada. Isso representa um estado final de falha para a requisição.
Por que isso importa Este evento final é essencial para analisar a taxa geral de rejeição e entender o impacto financeiro ou operacional das solicitações não aprovadas. Onde encontrar O evento é registrado explicitamente na 'WorkflowTrackingStatusTable' quando o fluxo de trabalho é concluído com status 'Rejected', o que atualiza o campo de status da 'PurchReqTable'. Coleta Filtre os eventos de 'Completion' do fluxo de trabalho com status 'Rejected' ou acompanhe a mudança de status na PurchReqTable. Tipo de evento explicit
	Etapa de aprovação iniciada	Uma tarefa individual de aprovação é atribuída a um usuário ou grupo como parte do fluxo de trabalho. Isso marca o início do tempo de espera ou processamento de um responsável específico.
Por que isso importa Esta atividade é essencial para a 'Análise de gargalos nas etapas de aprovação', pois permite medir o tempo de espera em cada etapa específica. Onde encontrar O evento é registrado na 'WorkflowTrackingStatusTable' quando um novo item de trabalho é criado e atribuído à instância do fluxo de trabalho da requisição. Coleta Identifique eventos 'WorkItemCreated' ou semelhantes nos registros do histórico do fluxo de trabalho da requisição. Tipo de evento explicit
	Etapa de aprovação rejeitada	O responsável rejeita a tarefa atribuída, geralmente devolvendo a requisição à pessoa que a criou para correção. O mecanismo de Workflow registra essa ação explícita.
Por que isso importa Esta atividade é fundamental para calcular a 'Taxa de rejeição de requisições' e identificar em quais etapas as rejeições ocorrem com mais frequência, apontando oportunidades de melhoria no processo. Onde encontrar O evento é registrado explicitamente na 'WorkflowTrackingStatusTable' quando um usuário conclui um item de trabalho com o resultado 'Reject'. Coleta Identifique nos registros do histórico do fluxo de trabalho os eventos 'WorkItemCompleted' com o resultado 'Reject'. Tipo de evento explicit
	Linha da requisição encerrada	Um item individual da requisição de compra é considerado totalmente processado. Isso costuma ocorrer depois que a linha é convertida integralmente em um pedido de compra.
Por que isso importa Oferece detalhes sobre o atendimento das requisições e ajuda a identificar se elas foram convertidas parcial ou totalmente em pedidos de compra. Onde encontrar O evento é inferido do campo de status da tabela individual 'PurchReqLine'. Um status que indique que o item foi pedido ou recebido sinaliza o encerramento. Coleta Monitore o campo de status da tabela PurchReqLine em busca de um valor final, como 'Invoiced' ou 'Closed'. Tipo de evento inferred
	Requisição alterada	Este evento ocorre quando um usuário retira do fluxo de trabalho uma requisição enviada para fazer alterações. Em geral, a atividade é identificada por uma ação de retirada seguida de um novo envio.
Por que isso importa Acompanhar as alterações é essencial para identificar retrabalho, solicitações iniciais pouco claras e ineficiências no processo. Isso contribui diretamente para o Dashboard 'Frequência de alterações nas requisições'. Onde encontrar O evento pode ser inferido do histórico do fluxo de trabalho ('WorkflowTrackingStatusTable'), identificando uma ação 'Recall' ou 'RequestChange'. Também pode ser inferido por alterações no campo 'modifiedDateTime' da 'PurchReqTable' após o envio. Coleta Identifique eventos de retirada do fluxo de trabalho ou mudanças na versão do registro entre os envios. Tipo de evento inferred
	Requisição cancelada	A pessoa que criou a requisição ou um usuário autorizado a cancela após o envio. Essa ação encerra o fluxo de trabalho e a solicitação.
Por que isso importa Acompanhar os cancelamentos ajuda a identificar problemas no planejamento da demanda ou processos complexos demais. Isso contribui para o Dashboard 'Insights sobre cancelamentos de requisições'. Onde encontrar O cancelamento pode ser inferido pela mudança do status da 'PurchReqTable' para 'Cancelled' ou por um evento 'Cancel' na 'WorkflowTrackingStatusTable'. Coleta Identifique a mudança de status para 'Cancelled' na PurchReqTable ou um evento de cancelamento no fluxo de trabalho. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como extrair seus dados do Microsoft Dynamics 365

Etapas

Acesse o espaço de trabalho de gerenciamento de dados: Entre no Microsoft Dynamics 365 e acesse o menu Workspaces. Selecione Data management para abrir o hub central de importação e exportação de dados.
Crie um projeto de exportação: No espaço de trabalho de gerenciamento de dados, clique no bloco Export. Informe um Nome do grupo exclusivo, uma Descrição e defina Project category como Project. Assim, você organiza as tarefas de extração de dados.
Adicione entidades de dados: Inclua no projeto as entidades de dados padrão necessárias. Clique em Add entity, pesquise cada uma das opções a seguir e adicione-as uma por vez:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Defina o formato de exportação: Para cada entidade adicionada, selecione um Target data format, como CSV ou Excel. Em geral, o CSV é recomendado por oferecer bom desempenho e compatibilidade com ferramentas de transformação de dados.
Aplique filtros aos dados: Selecione uma entidade e clique em Filtrar. Na guia Intervalo, especifique a Legal entity (código da empresa) para garantir que os dados sejam extraídos da unidade de negócio correta. Também é essencial filtrar o campo Created date and time da entidade Purchase requisition headers para limitar o volume de dados. Recomendamos começar com um período de 3 a 6 meses.
Execute a exportação: Depois de configurar todas as entidades e os filtros, clique em Export no painel de ações. O sistema criará um pacote de trabalho e iniciará o processamento. Acompanhe o andamento na seção Job history.
Baixe o pacote de dados: Quando a exportação for concluída com sucesso, acesse os detalhes de Job history e clique em Download package. Será baixado um arquivo ZIP com arquivos de dados separados para cada entidade.
Transforme os dados brutos em um Event Log: Os arquivos exportados contêm tabelas brutas do sistema, não um Event Log pronto. Use uma ferramenta externa, como Python, Power Query ou uma plataforma ETL, para combinar e reorganizar os dados. Isso inclui:
- Combinar os arquivos de cabeçalho e de linhas.
- Associar os dados do fluxo de trabalho às requisições usando CorrelationId e o RecId do cabeçalho da requisição de compra.
- Transformar as alterações de status e os eventos do fluxo de trabalho em linhas de atividade distintas (Requisition Submitted, Approval Step Approved etc.).
- Criar uma nova linha para cada atividade, com os valores corretos de ActivityName, EventTime e PurchaseRequisitionId.
Calcule e mapeie os atributos: Durante a transformação, mapeie as colunas de origem para os atributos necessários, como Usuário e Departamento. Calcule atributos derivados, como RequisitionTotalAmount, somando os valores das linhas. Defina um valor estático para SourceSystemId (por exemplo, 'D365_F&O') e use o horário de execução do script em LastDataIngestionTimestamp.
Finalize e formate o resultado: Garanta que o arquivo final seja um único CSV, com uma linha para cada evento do processo. As colunas devem corresponder à estrutura exigida para o Event Log, incluindo PurchaseRequisitionId, ActivityName e EventTime.

Configuração

Permissões necessárias: Os usuários precisam de uma função de segurança com permissões para acessar o espaço de trabalho Data management e as entidades de dados exportadas, como Data management administrator ou uma função personalizada equivalente.
Principais entidades de dados:
- Purchase requisition headers: fornece o identificador principal do caso, o horário de criação e o status geral.
- Purchase requisition lines: contém detalhes de cada item solicitado, incluindo valores e vínculos com pedidos de compra.
- Workflow tracking status table: é a principal fonte de eventos do fluxo de trabalho, como envio, aprovação, rejeição e retirada.
- Workflow work items: detalha as tarefas específicas atribuídas aos usuários durante o processo de aprovação.
- Purchase order lines V2: permite localizar o horário de criação do pedido de compra vinculado a uma linha da requisição.
Filtro por período: É essencial aplicar um filtro de período ao campo Created date and time da entidade Purchase requisition headers. Para a análise inicial, recomendamos um período de 3 a 6 meses, equilibrando o volume de dados e os insights sobre o processo.
Filtro por código da empresa: Sempre filtre por Legal entity para evitar a extração de dados de empresas não desejadas ou de teste. Isso reduz significativamente o volume de dados e melhora o desempenho da tarefa.
Transformação de dados: Este método exige uma etapa considerável de pós-processamento fora do Dynamics 365 para transformar as exportações brutas das entidades em um Event Log estruturado. Prepare-se para usar uma ferramenta de script ou ETL.

Consulta de exemplo sql

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Etapas

Registre um aplicativo no Azure Active Directory: Acesse o portal do Azure e registre um novo aplicativo. Ele será usado para autenticar na API do Dynamics 365. Anote o ID do aplicativo (cliente) e o ID do diretório (ambiente).
Gere um segredo do cliente: No aplicativo recém-registrado no Azure, crie um segredo do cliente em 'Certificates & secrets'. Copie o valor do segredo e guarde-o em local seguro, pois ele não será exibido novamente.
Conceda permissões à API: Na seção 'API permissions' do aplicativo, adicione uma permissão para 'Dynamics ERP'. Selecione 'Delegated permissions' e conceda Financials.ReadWrite.All ou uma permissão equivalente, mais restrita e somente para leitura. Conceda consentimento de administrador para as permissões.
Instale as bibliotecas Python: Verifique se o Python está instalado. Em seguida, instale as bibliotecas necessárias usando pip: pip install requests pandas.
Configure o script Python: Copie o script Python fornecido para um arquivo, por exemplo, extract_d365_requisitions.py. Preencha as variáveis de espaço reservado no início do script: URL do Dynamics 365, ID do ambiente, ID do cliente, segredo do cliente, período desejado e ID da empresa.
Entenda as entidades OData: O script consulta três entidades de dados principais: PurchaseRequisitionHeaders, com os detalhes da requisição; PurchaseRequisitionLines, com informações das linhas, incluindo a conversão em pedidos de compra; e WorkflowTrackingStatusTable, com todos os eventos relacionados ao fluxo de trabalho, como envios e aprovações.
Execute o script: Execute o script pela linha de comando: python extract_d365_requisitions.py. O script fará a autenticação, buscará os dados de cada atividade e cuidará automaticamente da paginação da API.
Transforme os dados: O script processa os dados JSON brutos retornados pelas chamadas à API. Ele reorganiza os dados percorrendo os registros e criando uma linha distinta para cada uma das 12 atividades de negócio, mapeando os campos de origem para as colunas padrão do Event Log, como PurchaseRequisitionId, ActivityName e EventTime.
Combine e padronize os eventos: Todos os eventos gerados são reunidos em uma única lista e convertidos em um DataFrame do pandas. O script adiciona colunas estáticas, como SourceSystemId e LastDataIngestionTimestamp.
Exporte para CSV: O DataFrame final é exportado para um arquivo CSV chamado d365_purchase_requisition_log.csv. O arquivo está formatado para ser carregado diretamente em uma ferramenta de Process Mining. Confira se ele está codificado em UTF-8.

Configuração

Pré-requisitos: Acesso a uma assinatura do Azure para registrar um aplicativo. Você também precisa do ID do aplicativo (cliente), do segredo do cliente e do ID do ambiente do Azure Active Directory. O usuário que executar o script precisa ter credenciais com acesso aos endpoints da API OData do Dynamics 365 Finance and Operations.
Configuração do endpoint da API: O script precisa da URL base do seu ambiente do Dynamics 365, geralmente no formato https://[your-environment-name].operations.dynamics.com.
Período: Defina as variáveis START_DATE e END_DATE no script para especificar o período de extração. Para a análise inicial, recomendamos de 3 a 6 meses, equilibrando o volume de dados e os insights.
Filtro por empresa: O script está configurado para filtrar uma entidade legal específica usando a variável COMPANY_ID. Para extrair dados de todas as empresas, talvez seja necessário modificar o filtro OData e incluir cross-company=true nos cabeçalhos da solicitação.
Considerações de desempenho: O script busca apenas as colunas necessárias para o Event Log usando $select nas consultas OData, o que melhora o desempenho. Ele também gerencia a paginação para processar grandes conjuntos de dados sem sobrecarregar a API. Para cargas históricas muito grandes, considere executar o script em lotes com períodos menores.

Consulta de exemplo python

import requests
import pandas as pd
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    if not events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

if __name__ == class="hl-string">"__main__":
    main()

Etapas

Confirme se o conector nativo do Microsoft Dynamics 365 Finance está disponível no Power BI Desktop e se o usuário tem autorização para acessar as entidades de dados necessárias, o histórico do fluxo de trabalho, os dados das requisições e os dados relacionados aos pedidos de compra.
No Power BI Desktop, selecione Obter dados, escolha o conector Microsoft Dynamics 365 Finance e informe a URL da instância do Dynamics 365 Finance. Autentique-se com uma conta autorizada a ler as entidades necessárias. Substitua [Your Dynamics 365 Finance instance URL] pela URL da instância do seu ambiente.
No Navegador, selecione as entidades de cabeçalho e linhas das requisições de compra, as entidades de histórico ou acompanhamento do fluxo de trabalho, as entidades de usuários e organização e as entidades de pedidos de compra necessárias à sua implementação. Os nomes das entidades e os campos disponíveis variam conforme o ambiente. Consulte os metadados das entidades e substitua cada espaço reservado na consulta pela entidade e pelo campo correspondentes disponibilizados pelo seu sistema.
Carregue as entidades selecionadas no Power Query. Filtre os dados pela entidade legal ou empresa, pelo tipo de documento e pelo período de extração necessários. Use os parâmetros [Start date] e [End date] e mantenha os registros cujo horário do evento esteja dentro do período selecionado. Inclua registros criados antes da data inicial quando houver eventos do fluxo de trabalho ou de encerramento dentro do período, para manter o histórico completo dos casos.
Padronize os identificadores e os horários. Converta o identificador da requisição de compra em texto, ajuste todos os horários dos eventos para um único fuso, UTC ou o fuso comercial, e preserve a precisão do horário de origem. Garanta que o identificador do cabeçalho da requisição esteja disponível em cada linha de evento. Se os registros do fluxo de trabalho contiverem apenas um identificador de correlação, associe-os ao cabeçalho da requisição usando a relação documentada e configurada no seu ambiente.
Crie uma consulta de evento para cada atividade necessária. As consultas devem retornar explicitamente linhas para Requisição criada, Requisição enviada para aprovação, Requisição alterada, Etapa de aprovação iniciada, Etapa de aprovação aprovada, Etapa de aprovação rejeitada, Requisição aprovada, Requisição rejeitada, Requisição retirada, Pedido de compra criado, Linha da requisição encerrada e Requisição encerrada. Não dependa do ProcessMind para inferir atividades com base em alterações de status ou na ordem dos eventos.
Para Requisição alterada, aplique a lógica documentada de retirada e reenvio com base no histórico do fluxo de trabalho. Uma ação de retirada seguida de um novo envio deve gerar um evento de alteração no horário da retirada ou no horário da alteração disponibilizado pela entidade de origem. Não crie uma linha de alteração apenas porque o status da requisição mudou, a menos que o sistema de origem registre explicitamente essa mudança como uma alteração.
Para eventos de linhas e pedidos de compra, associe as linhas da requisição às linhas do pedido de compra usando a relação documentada na origem. Se o Event Log usar PurchaseRequisitionId como identificador do caso, agregue os eventos de linha ou mantenha-os como linhas separadas com o mesmo identificador de caso. Quando disponíveis, preserve os identificadores das linhas em colunas adicionais, embora não sejam atributos obrigatórios.
Adicione as colunas de saída obrigatórias: PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId e LastDataIngestionTimestamp. Inclua também as colunas recomendadas: User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel e ApprovalStep. Preencha valores indisponíveis com nulo, em vez de inventá-los, e use um valor de origem consistente, como Dynamics 365 Finance, em SourceSystemId.
Combine todas as consultas de atividade com UNION ALL, remova linhas sem identificador de caso ou horário do evento e ordene por PurchaseRequisitionId e EventTime. Preserve eventos duplicados quando representarem tarefas distintas do fluxo de trabalho ou linhas diferentes da requisição. Remova duplicatas somente quando os registros de origem forem comprovadamente extrações duplicadas.
Valide o Event Log resultante usando as verificações descritas abaixo. Confirme que cada atividade necessária aparece em linhas explícitas, que os horários estão dentro do período selecionado e que as junções não multiplicam eventos de forma inesperada.
Carregue ou exporte a tabela final em CSV ou em outro formato de Event Log compatível com o ProcessMind. Mapeie PurchaseRequisitionId como identificador do caso, ActivityName como atividade e EventTime como horário do evento. Mantenha SourceSystemId e LastDataIngestionTimestamp como atributos do evento e inclua todos os atributos recomendados que estiverem disponíveis.

Configuração

Conector e origem: Use o conector nativo do Microsoft Dynamics 365 Finance no Power BI Desktop. Substitua [Your Dynamics 365 Finance instance URL] pela URL do ambiente. Confirme os nomes das entidades e dos campos nos metadados do Navegador para a implementação específica.
Entidades necessárias: Selecione as entidades de cabeçalho e linhas das requisições de compra, as entidades de acompanhamento ou histórico do fluxo de trabalho, as entidades de cabeçalho e linhas dos pedidos de compra e as entidades de usuários ou organização necessárias para enriquecer os dados. Use espaços reservados como [Your entity name] até confirmar as entidades exatas.
Período: Comece com três a seis meses de dados. Inclua cabeçalhos históricos de requisições para casos com eventos de fluxo de trabalho, pedido de compra, encerramento de linha ou encerramento da requisição durante o período selecionado.
Filtros de empresa e documento: Quando aplicável, filtre por [Your company or legal entity filter] e [Your document type filter]. Confirme se o identificador da requisição é exclusivo globalmente ou apenas dentro de uma empresa.
Escopo do fluxo de trabalho: Inclua ações de envio, retirada, reenvio, atribuição de tarefa, aprovação, rejeição, retirada da requisição, conclusão e cancelamento. Configure os mapeamentos de ações e status do fluxo de trabalho com base nos valores usados no ambiente.
Semântica dos eventos: Cada atividade deve ser registrada como uma linha de evento explícita. O ProcessMind não infere eventos de aprovação, alteração, encerramento ou conversão a partir de outras linhas.
Tratamento dos horários: Padronize todos os horários para um único fuso. Registre se os horários de origem estão em UTC ou no horário comercial local. Use o horário de origem com a maior precisão disponível.
Atualização incremental: Para extrações recorrentes, use como referência o maior horário de modificação ou de evento na origem e inclua um período de sobreposição para capturar registros do fluxo de trabalho que chegarem com atraso. Reconcilie esse período antes de carregar o Event Log final.
Desempenho: Filtre as entidades de origem antes das junções, selecione apenas as colunas necessárias, evite carregar registros históricos desnecessários do fluxo de trabalho e use o dobramento de consulta quando disponível. Extraia separadamente cabeçalhos, linhas, eventos do fluxo de trabalho e relações com pedidos de compra antes de combiná-los.
Autorizações e pré-requisitos: A conta precisa ter acesso de leitura às entidades de dados selecionadas do Dynamics 365 Finance e aos dados do fluxo de trabalho. Confirme se os recursos de compras e de fluxo de trabalho relevantes estão habilitados e se o Power BI Desktop, o conector, a configuração do gateway, quando aplicável, e as políticas de segurança da organização permitem a extração.
Moeda e valores: Confirme qual moeda está representada em RequisitionTotalAmount. Se as requisições puderem incluir várias moedas, adicione a moeda de origem como atributo e não converta os valores sem informar.
Tratamento de nulos: Os atributos recomendados podem ficar nulos quando a origem não armazena um valor, quando o acesso ao valor é restrito por segurança ou quando não é possível resolver a relação. Valide os valores obrigatórios de caso, atividade e horário do evento antes da exportação.

Consulta de exemplo sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Pronto para começar?

Com este Template, você tem tudo de que precisa para começar a otimizar seu processo de requisição de compra. Comece hoje a descobrir insights valiosos.

Voltar ao guia de melhoria

Baixar Template

Otimize as requisições de compra ao pagamento e acelere as aprovações

Elimine atrasos e reduza em 30% o tempo de ciclo no Dynamics 365.

Comece seu teste grátis

Não é necessário informar cartão de crédito. Configure em poucos minutos.

Seu Template de dados para requisições de compra

Seu Template de dados para requisições de compra

Atributos de requisições de compra

Atividades de requisições de compra

Guias de extração

Exportação pelo framework de gerenciamento de dados do Dynamics 365

Etapas

Configuração

Consulta de exemplo sql

Script Python usando a API REST OData do Dynamics 365

Etapas

Configuração

Consulta de exemplo python

Extração pelo conector nativo do Microsoft Power BI

Etapas

Configuração

Consulta de exemplo sql

Pronto para começar?

Otimize as requisições de compra ao pagamento e acelere as aprovações