> Melhoria contínua de processos > Purchase to Pay Requisição > Microsoft Dynamics 365 > Template de dados

Seu Template de dados de Purchase to Pay - Requisition

Microsoft Dynamics 365

Purchase to Pay - Requisição: atributos (17) Purchase to Pay - Requisição: atividades (12) Guias de extração (3)

Seu Template de dados de Purchase to Pay - Requisition

Este Template apresenta os principais atributos que devem ser coletados e as atividades essenciais que devem ser acompanhadas, permitindo uma análise aprofundada do seu processo de requisição. Ele também oferece orientações práticas para extrair esses dados e ajudar você a preparar seu Event Log com eficiência para uma análise detalhada.

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

Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Baixar Template

Purchase to Pay - Requisição: atributos

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise completa do processo Purchase to Pay - Requisição.

5 Obrigatório 6 Recomendado 6 Opcional

	Nome	Descrição
	Hora do evento EventTime	A data e hora exatas em que uma atividade ou evento específico ocorreu.
Descrição A hora do evento, ou o registro de data e hora, captura a data e a hora em que um evento de negócio foi registrado no sistema. Ela é a base temporal de todas as análises de processo orientadas por 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 a conformidade com SLAs. Registros de data e hora precisos são essenciais para uma análise confiável de process mining. Por que isso importa Ele fornece a ordem cronológica dos eventos, necessária para calcular as durações do processo, identificar gargalos e analisar a performance ao longo do tempo. Onde obter Encontrado em tabelas de histórico do Workflow ou de registros de documentos, geralmente no 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	O identificador exclusivo de uma requisição de compra, usado como identificador principal do caso.
Descrição O Purchase Requisition ID é a chave central que vincula todas as atividades relacionadas a uma única solicitação de bens ou serviços. Cada processo de requisição, da criação à aprovação final e ao encerramento, é rastreado por esse ID exclusivo. No process mining, esse atributo é fundamental para reconstruir a jornada de ponta a ponta de cada requisição. Ele permite analisar variantes do processo, tempos de ciclo e conformidade de casos individuais, oferecendo uma visão completa do ciclo de vida da requisição. Por que isso importa Ele é essencial para agrupar todos os eventos relacionados em uma única instância de processo, permitindo uma análise completa, de ponta a ponta, do ciclo de vida de cada requisição. Onde obter Normalmente, essa é a chave primária da tabela principal de cabeçalho das requisições de compra, como a PurchReqTable no Microsoft Dynamics 365. Exemplos PR-001254PR-001255PR-001256
	Nome da atividade ActivityName	O nome do evento ou da etapa específica de negócio 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. Os exemplos incluem 'Requisition Created', 'Approval Step Approved' e 'Purchase Order Created'. 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 é o núcleo do process mining. Isso ajuda a identificar gargalos, ciclos de retrabalho e desvios do fluxo padrão do processo, gerando insights sobre ineficiências operacionais. Por que isso importa Este atributo define as etapas do mapa de processo, permitindo visualizar, analisar e entender o Workflow de requisição. Onde obter Normalmente, ele é derivado de registros de mudanças de status, tabelas de histórico do Workflow 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	O sistema de registro do qual os dados foram extraídos.
Descrição Este atributo identifica o sistema de origem dos dados de eventos. Neste contexto, seria o 'Microsoft Dynamics 365'. Em ambientes com vários sistemas integrados, esse campo é essencial para a linhagem e o contexto dos dados. Na análise, ele ajuda a diferenciar processos que podem abranger vários sistemas ou confirma que os dados vêm de uma fonte única e confiável. Isso é importante para validar os dados e garantir que a análise se baseie no conjunto de dados correto. Por que isso importa Ele fornece contexto sobre a origem dos dados, algo essencial para a governança e a validação dos dados e para ambientes nos quais vários sistemas estão integrados. Onde obter 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	A data e hora em que os dados foram extraídos e carregados pela última vez na ferramenta de process mining.
Descrição Este atributo indica o nível de atualização dos dados analisados. Ele mostra a data e a hora da atualização mais recente dos dados do sistema de origem. Não é um campo do próprio Dynamics 365, mas sim um metadado adicionado durante a ingestão de dados. Esse registro de data e hora é essencial para que os usuários entendam a atualidade dos insights. Ele ajuda a saber se estão analisando dados em tempo real ou uma fotografia de um momento específico, o que afeta a relevância das conclusões. Por que isso importa Ele informa aos usuários o nível de atualização dos dados, garantindo que entendam o período da análise e a relevância dos insights. Onde obter Esse valor é gerado e anexado ao conjunto de dados durante o processo de ingestão de dados ou ETL. Exemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Departamento Department	O departamento do solicitante ou o centro de custo associado à requisição.
Descrição Este atributo especifica o departamento de negócio ou centro de custo que iniciou a requisição de compra, como 'Marketing', 'TI' ou 'Operações'. Essas informações geralmente fazem parte do cabeçalho da requisição. Segmentar o processo por departamento é essencial para análises comparativas. Isso permite identificar quais departamentos têm os ciclos mais longos, as maiores taxas de rejeição ou a maior frequência de alterações. Esses insights ajudam a adaptar as melhorias do processo às necessidades específicas de cada departamento. Por que isso importa Ele 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 obter Essas informações geralmente ficam armazenadas no cabeçalho da requisição de compra, na PurchReqTable, e vinculadas à configuração de dimensões financeiras do Dynamics 365. Exemplos Departamento de TIFinançasOperações
	Etapa de aprovação ApprovalStep	O nome ou estágio de uma etapa específica de aprovação no Workflow.
Descrição Esse atributo identifica o estágio específico no Workflow de aprovação, como “Aprovação do gerente” ou “Aprovação financeira”. Ele fornece um nível de detalhe maior do que o nome geral da atividade. Esse atributo é essencial para a “Análise de gargalos nas etapas de aprovação”. Ao acompanhar o tempo gasto em cada etapa distinta de aprovação, fica possível identificar exatamente quais estágios estão causando atrasos no processo como um todo. Assim, você pode implementar ações direcionadas para melhorar a eficiência do Workflow. Por que isso importa Ele permite uma análise detalhada do Workflow de aprovação, facilitando a identificação de estágios específicos que estão causando gargalos. Onde obter Essas informações estão nas tabelas de histórico do Workflow, como WorkflowTrackingStatusTable, que detalha cada etapa do Workflow configurado. Exemplos Aprovação do gerenteAprovação do responsável pelo departamentoAnálise financeira
	Nível de urgência UrgencyLevel	Uma 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 com que rapidez os bens ou serviços solicitados são necessários. Esse atributo costuma ser usado para influenciar o caminho de aprovação ou priorizar o trabalho dos aprovadores. Analisar esse atributo ajuda a determinar se o sistema de prioridades é eficaz. Por exemplo, você pode comparar os tempos de ciclo das requisições com urgência “Alta” e “Baixa”. Se não houver uma diferença significativa, isso pode indicar que o campo de prioridade está sendo ignorado ou usado incorretamente, 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 configurações de prioridade aceleram efetivamente as solicitações críticas e revela possíveis usos incorretos da classificação de urgência. Onde obter Esse pode ser um campo padrão ou personalizado da PurchReqTable. A existência e o nome 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 'In Review', 'Approved', 'Rejected' ou 'Closed'. Geralmente, é 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 'Rejected' ou 'Withdrawn' pode indicar problemas na etapa inicial da solicitação ou um processo de aprovação complicado. Esse atributo é essencial para medir as taxas de sucesso e a eficiência do processo. Por que isso importa Ele fornece um resultado claro para cada caso, permitindo analisar as taxas de aprovação, rejeição e retirada, que são indicadores importantes de performance. Onde obter O campo de status normalmente fica na tabela de cabeçalho da requisição de compra, PurchReqTable, geralmente com o nome 'Status' ou 'PurchReqStatus'. Exemplos AprovadoEm análiseRejeitadoRascunho
	Usuário User	O ID ou nome do usuário que realizou a atividade.
Descrição Este atributo identifica o colaborador 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 times de alta performance e a distribuição da carga de trabalho. Também é essencial para análises de conformidade, como a segregação de funções, e para entender como diferentes papéis de usuário interagem com o processo. Por que isso importa Ele permite analisar o comportamento, a carga de trabalho e a performance específicos de cada usuário, aspectos essenciais para a gestão de recursos e a identificação de oportunidades de treinamento. Onde obter Normalmente encontrado em tabelas de histórico do Workflow, como a WorkflowTrackingStatusTable, ou em tabelas de transações, como a PurchReqTable, vinculadas a uma tabela de usuários, como a UserInfo. Exemplos j.smitha.joness.patel
	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 de uma requisição de compra. O valor geralmente influencia a complexidade do Workflow de aprovação, e requisições de maior valor podem exigir mais etapas de aprovação. Na análise de processos, esse atributo é essencial para filtrar e analisar os dados por valor. Ele ajuda a responder perguntas como: 'Requisições de alto valor levam mais tempo para serem aprovadas?' ou 'Qual é o valor das requisições atualmente paradas no processo?'. Assim, você adiciona uma dimensão financeira à análise da performance do processo. Por que isso importa Ele adiciona 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 obter Esse valor normalmente fica na tabela de cabeçalho da requisição de compra ou é calculado como a soma dos valores dos itens na tabela de linhas da requisição de compra, PurchReqLine. Exemplos 1500.0025000.50500.75
	Aprovado na primeira passagem IsFirstPass	Um indicador que mostra se a requisição foi aprovada sem alterações ou rejeições anteriores.
Descrição Este é um atributo booleano calculado que vale “true” quando o caminho da requisição até a aprovação não inclui as atividades “Requisição alterada” ou “Etapa de aprovação rejeitada”. Caso contrário, ele vale “false”. Esse atributo dá suporte direto ao KPI “Taxa de aprovação de requisições na primeira passagem”. Ele simplifica a análise da eficiência do processo ao fornecer um indicador claro, no nível do caso, de retrabalho. Uma taxa baixa de aprovações na primeira passagem destaca problemas na qualidade dos dados iniciais ou requisitos pouco claros, sinalizando 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, dando suporte a KPIs focados em taxas de acerto na primeira vez. Onde obter Este é um atributo calculado. É necessário analisar a sequência completa de atividades de cada caso durante a transformação dos dados para verificar a ausência de atividades de retrabalho antes da aprovação. Exemplos truefalse
	Caminho do Workflow de aprovação ApprovalWorkflowPath	Uma representação da sequência de etapas de aprovação realizadas.
Descrição Esse atributo é um campo derivado que concatena a sequência de etapas de aprovação de uma determinada requisição, como “Aprovação do gerente -> Aprovação do chefe do departamento -> Aprovação financeira”. Ele resume efetivamente a variante do processo para o subprocesso de aprovação. Isso é essencial para o Dashboard “Monitor de desvios de Conformidade”. Ao comparar o caminho real do Workflow com um caminho padrão ou esperado predefinido, fica fácil sinalizar fluxos de processo fora de Conformidade ou incomuns, que podem representar violações de políticas ou riscos operacionais. Por que isso importa Ele simplifica a análise de Conformidade ao fornecer uma representação textual clara da variante do processo, facilitando a identificação de desvios dos procedimentos padrão. Onde obter Esse 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
	Contagem de alterações AmendmentCount	O número total de vezes que uma requisição foi alterada.
Descrição Este é um atributo numérico calculado que conta as ocorrências da atividade “Requisição alterada” em cada caso de requisição de compra. Esse atributo é essencial para o Dashboard “Frequência de alterações de requisições” e para o KPI “Índice de alterações de requisições”. Ele quantifica o retrabalho por caso, facilitando a identificação das requisições, departamentos ou usuários associados a altos níveis de alterações e ineficiência. Isso ajuda a direcionar os esforços para melhorar a qualidade das solicitações iniciais. Por que isso importa Ele quantifica o retrabalho dentro de um caso, facilitando a medição e a análise da frequência das alterações e do impacto delas na eficiência do processo. Onde obter Este é um atributo calculado. Ele é derivado durante a transformação dos dados, contando as atividades “Requisição alterada” para cada PurchaseRequisitionId exclusivo. Exemplos 013
	Grupo de aprovadores ApproverGroup	O grupo de usuários ou a função responsável por uma etapa de aprovação.
Descrição Esse atributo identifica o grupo, a função ou a fila responsável por uma tarefa específica de aprovação, por exemplo, “Aprovadores financeiros” 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 quais grupos podem estar com recursos insuficientes ou precisar de treinamento adicional. Isso dá suporte direto ao Dashboard “Análise de gargalos nas etapas de aprovação”, permitindo segmentar a performance pelas equipes responsáveis pelas aprovações. Por que isso importa Ele ajuda a identificar diferenças de performance entre as equipes de aprovação, destacando possíveis limitações de recursos ou necessidades de treinamento em grupos específicos. Onde obter Essas informações fazem parte do histórico do Workflow, por exemplo, WorkflowTrackingStatusTable, que registra o usuário ou grupo de usuários atribuído a cada tarefa. Exemplos Aprovadores financeirosGerentes de TIAlta liderança
	Moeda Currency	O código da moeda do valor da requisição.
Descrição Este atributo especifica a moeda, por exemplo, USD, EUR ou GBP, na qual o valor total da requisição é denominado. Ele é essencial para a análise financeira, especialmente em organizações multinacionais que trabalham com várias moedas. Usar o atributo de moeda permite tratar e agregar corretamente os dados financeiros. Isso garante que os valores monetários sejam interpretados corretamente e possibilita conversões para uma moeda comum, facilitando relatórios precisos e comparações 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 precisas dos valores monetários em ambientes com várias moedas. Onde obter Esse campo geralmente está na tabela de cabeçalho da requisição de compra, PurchReqTable, junto aos campos de valor. Exemplos USDEURGBP
	Número do pedido de compra PurchaseOrderNumber	O identificador do pedido de compra criado a partir da requisição.
Descrição Esse atributo armazena o ID exclusivo do pedido de compra gerado a partir de uma requisição de compra aprovada. Ele funciona como o vínculo entre o processo de requisição e o processo de compras subsequente. Acompanhar esse número é essencial para analisar o “Tempo de conversão de requisição para PO”. Ele confirma que a requisição avançou com sucesso para a próxima etapa do ciclo Purchase-to-Pay e permite uma análise completa do processo, abrangendo requisições e pedidos de compra. Por que isso importa Ele conecta a requisição ao pedido de compra subsequente, permitindo analisar a conversão de requisição para PO e vincular diferentes etapas do processo P2P. Onde obter Essas informações geralmente estão na tabela de linhas da requisição de compra, PurchReqLine, depois que um PO é criado, fazendo o vínculo com a PurchTable. Exemplos PO-000987PO-000988PO-000989

Obrigatório Recomendado Opcional

Purchase to Pay - Requisição: atividades

Estas são as etapas e os marcos essenciais do processo que você deve registrar no seu Event Log para realizar uma descoberta e uma análise precisas do seu Workflow de requisições.

7 Recomendado 5 Opcional

	Atividade	Descrição
	Etapa de aprovação aprovada	Um aprovador conclui a tarefa atribuída, aprovando a requisição na sua etapa do processo. Isso move a requisição 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 as partes eficientes do Workflow. É um componente essencial da análise de variantes. Onde obter Registrada explicitamente na 'WorkflowTrackingStatusTable' quando um usuário conclui um item de trabalho com o resultado 'Approve'. Captura Identifique eventos 'WorkItemCompleted' com o resultado 'Approve' nos registros do histórico do Workflow. Tipo de evento explicit
	Pedido de compra criado	Uma linha de requisição de compra aprovada é convertida em uma linha de pedido de compra, sinalizando a transferência para a equipe de compras. Isso é capturado vinculando a linha da requisição à linha do pedido de compra.
Por que isso importa Este é um marco essencial que conecta a requisição ao processo de compras subsequente. É indispensável para medir o KPI 'Requisition to PO Conversion Time'. Onde obter Inferido pela localização de um registro na tabela 'PurchLine' que referencia o ID de uma 'PurchReqLine' associada ao caso da requisição. Captura Faça a junção de PurchReqLine com PurchLine usando o campo de referência de vínculo, por exemplo, PurchReqLineRefId. Tipo de evento inferred
	Requisição aprovada	A requisição passou com sucesso por todas as etapas de aprovação exigidas no Workflow. Esta atividade é capturada quando a instância do Workflow é concluída com status final aprovado.
Por que isso importa Este é um marco importante, que marca o fim do ciclo de aprovação e o início da etapa de compras. É o evento final do KPI 'Requisition Approval Cycle Time'. Onde obter Capturada explicitamente na 'WorkflowTrackingStatusTable' quando o Workflow é concluído. Isso também atualiza o campo 'Status' da 'PurchReqTable' para 'Approved'. Captura Filtre os eventos de 'Completion' do Workflow 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 em estado de rascunho. Ele é capturado identificando a data e hora de criação do cabeçalho da requisição de compra.
Por que isso importa Como início do processo, esta atividade é essencial para medir o tempo total do ciclo de vida da requisição e analisar os volumes diários processados. Onde obter Esta atividade é inferida do campo 'createdDateTime' da 'PurchReqTable' para cada novo Purchase Requisition ID. Captura 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, o que significa que todas as suas linhas foram 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 obter Esse status normalmente é calculado ou inferido. Ele ocorre quando todos os registros associados de 'PurchReqLine' alcançam um status terminal, como 'Closed' ou 'Cancelled'. Captura Derive este evento verificando se todos os registros filhos de 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 Workflow formal de aprovação. Essa é uma ação explícita registrada pelo mecanismo de Workflow do sistema.
Por que isso importa Esta atividade é um marco essencial que inicia o ciclo de aprovação. Ela é o ponto de partida para medir o 'Requisition Approval Cycle Time' e a 'First-Pass Approval Rate'. Onde obter Capturado na 'WorkflowTrackingStatusTable' ou em uma tabela semelhante de histórico do Workflow, na qual um evento de 'Submission' é registrado para a requisição de compra. Captura Filtre os registros do histórico do Workflow pelo tipo de evento 'Submission' ou 'Start' associado à requisição. Tipo de evento explicit
	Requisição rejeitada	A requisição foi rejeitada durante o Workflow de aprovação e não será processada novamente. Isso representa um estado terminal de falha da requisição.
Por que isso importa Este evento final é essencial para analisar as taxas gerais de rejeição e entender o impacto financeiro ou operacional de solicitações malsucedidas. Onde obter Capturada explicitamente na 'WorkflowTrackingStatusTable' após a conclusão do Workflow com status 'Rejected', que atualiza o campo de status da 'PurchReqTable'. Captura Filtre os eventos de 'Completion' do Workflow 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 Workflow. Isso representa o início do tempo de espera ou processamento de um aprovador específico.
Por que isso importa Esta atividade é essencial para a 'Approval Step Bottleneck Analysis', permitindo medir os tempos de fila de etapas específicas de aprovação. Onde obter Capturada na 'WorkflowTrackingStatusTable' quando um novo item de trabalho é criado e atribuído à instância de Workflow da requisição. Captura Identifique eventos 'WorkItemCreated' ou semelhantes nos registros do histórico do Workflow da requisição específica. Tipo de evento explicit
	Etapa de aprovação rejeitada	Um aprovador rejeita a tarefa atribuída, normalmente enviando a requisição de volta ao solicitante para correção. Essa é uma ação explícita registrada pelo mecanismo de Workflow.
Por que isso importa Esta atividade é fundamental para calcular a 'Requisition Rejection Rate' e identificar em quais etapas as rejeições ocorrem com mais frequência, destacando áreas para melhoria do processo. Onde obter Registrada explicitamente na 'WorkflowTrackingStatusTable' quando um usuário conclui um item de trabalho com o resultado 'Reject'. Captura Identifique eventos 'WorkItemCompleted' com o resultado 'Reject' nos registros do histórico do Workflow. Tipo de evento explicit
	Linha da requisição encerrada	Um item individual da linha da requisição de compra é considerado totalmente processado. Isso normalmente ocorre depois que a linha é completamente convertida em um pedido de compra.
Por que isso importa Fornece detalhes granulares sobre o atendimento da requisição, ajudando a identificar se as requisições foram convertidas parcial ou totalmente em pedidos de compra. Onde obter Inferido do campo de status da tabela individual 'PurchReqLine'. Um status indicando que o item foi pedido ou recebido sinaliza o encerramento. Captura Monitore o campo de status da tabela PurchReqLine em busca de um valor terminal, como 'Invoiced' ou 'Closed'. Tipo de evento inferred
	Requisição alterada	Este evento ocorre quando um usuário recupera uma requisição enviada do Workflow para fazer alterações. A atividade normalmente é capturada identificando uma ação de recuperação seguida por um novo envio.
Por que isso importa Acompanhar alterações é essencial para identificar retrabalho, solicitações iniciais pouco claras e ineficiências do processo. Isso dá suporte ao Dashboard 'Requisition Amendment Frequency'. Onde obter Pode ser inferido do histórico do Workflow ('WorkflowTrackingStatusTable') detectando uma ação 'Recall' ou 'RequestChange'. Também pode ser inferido por alterações no campo 'modifiedDateTime' da 'PurchReqTable' após o envio. Captura Detecte eventos de recuperação do Workflow ou mudanças na versão do registro entre eventos de envio. Tipo de evento inferred
	Requisição retirada	O criador ou um usuário autorizado cancela a requisição depois que ela foi enviada. Essa ação encerra o Workflow e a solicitação.
Por que isso importa Acompanhar retiradas ajuda a identificar problemas no planejamento da demanda ou processos excessivamente complexos. Isso dá suporte ao Dashboard 'Requisition Withdrawal Insights'. Onde obter Isso é inferido por uma mudança de status na 'PurchReqTable' para 'Cancelled' ou por um evento 'Cancel' na 'WorkflowTrackingStatusTable'. Captura Detecte a mudança de status para 'Cancelled' na PurchReqTable ou um evento de cancelamento do Workflow. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Microsoft Dynamics 365

Etapas

Acesse o espaço de trabalho de gerenciamento de dados: Faça login no Microsoft Dynamics 365 e navegue até o menu Workspaces. Selecione Data management para abrir o hub central das operações de importação e exportação de dados.
Crie um novo 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 detalhada e defina a Categoria do projeto como Project. Isso organiza suas tarefas de extração de dados.
Adicione entidades de dados: Adicione ao projeto as entidades de dados padrão necessárias. Clique em Add entity e pesquise cada uma das opções a seguir, adicionando-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 melhor performance e compatibilidade com ferramentas de transformação de dados.
Aplique filtros de dados: Selecione uma entidade e clique no botão Filtrar. Na guia Intervalo, especifique a Entidade legal (código da empresa) para garantir que os dados sejam extraídos da unidade de negócio correta. Também é essencial adicionar um filtro de data ao 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 o trabalho de exportação: Depois de configurar todas as entidades e os filtros, clique em Export no Action Pane. O sistema criará um pacote de trabalho e iniciará o processamento. Você pode acompanhar o andamento na seção Job history.
Baixe o pacote de dados: Depois que o trabalho de exportação for concluído com sucesso, acesse os detalhes de Job history e clique em Download package. Isso baixará um arquivo ZIP contendo os arquivos de dados separados de cada entidade.
Transforme os dados brutos em um Event Log: Os arquivos exportados representam tabelas brutas do sistema, não um Event Log final. Você deverá usar uma ferramenta externa, como Python, Power Query ou uma plataforma ETL, para combinar e remodelar os dados. Isso envolve:
- Fazer a junção dos arquivos de cabeçalho e de linhas.
- Fazer a junção dos dados de fluxo de trabalho com as 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 das tabelas de 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 para LastDataIngestionTimestamp.
Finalize e formate a saída: Verifique se o arquivo final é um único CSV em que cada linha representa um 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 devem ter uma função de segurança com permissões para o workspace Data management e acesso às entidades de dados específicas que serão exportadas, como Data management administrator ou uma função personalizada semelhante.
Principais entidades de dados:
- Purchase requisition headers: fornece o identificador principal do caso, o timestamp 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 Workflow, como envio, aprovação, rejeição e recall.
- Workflow work items: detalha as tarefas específicas atribuídas aos usuários durante o processo de aprovação.
- Purchase order lines V2: usada para encontrar o timestamp de criação do pedido de compra vinculado a uma linha da requisição.
Filtragem 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, recomenda-se um período de 3 a 6 meses, equilibrando o volume de dados e os insights do processo.
Filtragem por código da empresa: Sempre aplique um filtro para Legal entity para evitar a extração de dados de empresas não desejadas ou de teste. Isso reduz significativamente o tamanho dos dados e melhora a performance do trabalho.
Transformação dos dados: Este método exige uma etapa significativa de pós-processamento fora do Dynamics 365 para transformar as exportações brutas das entidades em um Event Log estruturado. Esteja preparado para usar uma ferramenta de script ou ETL.

a 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. Esse aplicativo será usado para autenticar na API do Dynamics 365. Anote o Application (client) ID e o Directory (tenant) ID.
Gere um segredo do cliente: No aplicativo recém-registrado no Azure, crie um novo segredo do cliente em “Certificates & secrets”. Copie o valor do segredo com segurança, pois ele não ficará visível 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 alternativa somente leitura mais restritiva. Conceda o consentimento do 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, Tenant ID, Client ID, Client Secret, período desejado e ID da empresa.
Entenda as entidades OData: O script consulta três entidades de dados principais: PurchaseRequisitionHeaders, para os detalhes principais da requisição; PurchaseRequisitionLines, para os detalhes das linhas, incluindo a conversão em pedidos de compra; e WorkflowTrackingStatusTable, para todos os eventos relacionados ao Workflow, como envios e aprovações.
Execute o script: Execute o script na linha de comando: python extract_d365_requisitions.py. O script fará a autenticação, buscará os dados de cada atividade e tratará automaticamente a paginação da API.
Transformação dos dados: O script processa os dados JSON brutos das 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. Esse arquivo é formatado para upload direto em uma ferramenta de Process Mining. Verifique se o arquivo está codificado em UTF-8.

Configuração

Pré-requisitos: Acesso a uma assinatura do Azure para registrar um aplicativo. Application (client) ID, Client Secret e Tenant ID do Azure Active Directory. O usuário que executar o script precisa de credenciais que concedam acesso aos endpoints da API OData do Dynamics 365 Finance and Operations.
Configuração do endpoint da API: O script exige a URL base do seu ambiente Dynamics 365, normalmente no formato https://[your-environment-name].operations.dynamics.com.
Período: Defina as variáveis START_DATE e END_DATE no script para estabelecer a janela de extração. Para a análise inicial, recomenda-se um período 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 performance: O script busca apenas as colunas necessárias para o Event Log usando $select nas consultas OData, o que melhora a performance. Ele também trata a paginação para gerenciar grandes conjuntos de dados sem sobrecarregar a API. Para cargas históricas muito grandes, considere executar o script em lotes com períodos menores.

a 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 Workflow, os dados da requisição e os dados relacionados ao pedido de compra.
No Power BI Desktop, selecione Obter dados, escolha o conector do 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 Navigator, selecione as entidades de cabeçalho e linha da requisição de compra, as entidades de histórico ou rastreamento do Workflow, as entidades de usuário e organização e as entidades de pedido de compra necessárias para sua implementação. Os nomes das entidades e os campos disponíveis variam conforme o ambiente. Use os metadados das entidades e substitua cada placeholder na consulta pela entidade e pelo campo correspondente expostos 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 parâmetros para [Start date] e [End date] e mantenha os registros cujo timestamp do evento esteja dentro do período selecionado. Inclua registros criados antes da data inicial quando eles tiverem eventos de Workflow ou encerramento dentro do período, para manter o histórico completo dos casos.
Padronize os identificadores e os timestamps. Converta o identificador da requisição de compra em texto, converta todos os timestamps dos eventos para um fuso horário UTC ou empresarial consistente e preserve a precisão do timestamp de origem. Garanta que o identificador do cabeçalho da requisição esteja disponível em todas as linhas de eventos. Quando os registros do Workflow contiverem apenas um identificador de correlação do Workflow, faça a junção com o cabeçalho da requisição usando o relacionamento documentado e configurado no seu ambiente.
Crie uma consulta de eventos para cada atividade necessária. As consultas de eventos devem retornar explicitamente linhas para Requisition Created, Requisition Submitted for Approval, Requisition Amended, Approval Step Started, Approval Step Approved, Approval Step Rejected, Requisition Approved, Requisition Rejected, Requisition Withdrawn, Purchase Order Created, Requisition Line Closed e Requisition Closed. Não dependa do ProcessMind para inferir qualquer atividade a partir de mudanças de status ou da ordem dos eventos.
Para Requisition Amended, aplique a lógica documentada de recall e reenvio do histórico do Workflow. Uma ação de recall seguida por um envio posterior deve gerar um evento de alteração no timestamp do recall ou no timestamp da alteração exposto pela entidade de origem. Não crie uma linha de alteração apenas com base em uma mudança no status da requisição, a menos que o sistema de origem registre explicitamente essa mudança como uma alteração.
Para eventos de linhas e pedidos de compra, faça a junção das linhas da requisição com as linhas do pedido de compra usando o relacionamento de origem documentado. Se o Event Log for baseado em casos com PurchaseRequisitionId, agregue ou mantenha os eventos no nível da linha como linhas separadas com o mesmo identificador de caso. Preserve os identificadores das linhas em colunas adicionais quando disponíveis, mesmo que eles não sejam atributos obrigatórios.
Adicione as colunas de saída obrigatórias PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId e LastDataIngestionTimestamp. Adicione as colunas recomendadas User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel e ApprovalStep. Preencha valores indisponíveis com null em vez de valores inventados e use um valor de origem consistente, como Dynamics 365 Finance, para SourceSystemId.
Anexe todas as consultas de atividades usando UNION ALL, remova as linhas sem identificadores de caso ou timestamps de evento, e ordene por PurchaseRequisitionId e EventTime. Preserve eventos duplicados quando eles representarem tarefas distintas do Workflow ou linhas distintas da requisição. Remova duplicidades somente quando os registros de origem forem comprovadamente extratos duplicados.
Valide o Event Log resultante usando as verificações descritas abaixo. Confirme se todas as atividades obrigatórias estão representadas por linhas explícitas, se os timestamps estão dentro do período selecionado e se 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 timestamp do evento. Mantenha SourceSystemId e LastDataIngestionTimestamp como atributos do evento e preserve todos os atributos recomendados quando 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. Os nomes das entidades e dos campos devem ser confirmados nos metadados do Navigator para a implementação específica.
Entidades obrigatórias: Selecione as entidades de cabeçalho e linha da requisição de compra, as entidades de rastreamento ou histórico do Workflow, as entidades de cabeçalho e linha do pedido de compra e as entidades de usuário ou organização necessárias para o enriquecimento. Use placeholders [Your entity name] até confirmar as entidades exatas.
Período: Comece com dados de três a seis meses. Inclua cabeçalhos históricos de requisições para os casos que tenham eventos de Workflow, pedido de compra, fechamento de linha ou fechamento da requisição durante o período selecionado.
Filtros de empresa e documento: Filtre por [Your company or legal entity filter] e [Your document type filter], quando aplicável. Confirme se o identificador da requisição é globalmente exclusivo ou se é exclusivo apenas dentro de uma empresa.
Escopo do Workflow: Inclua ações de envio, recall, reenvio, atribuição de tarefas, aprovação, rejeição, retirada, conclusão e cancelamento. Configure os mapeamentos de ações e status do Workflow com base nos valores usados no ambiente.
Semântica dos eventos: Cada atividade deve ser emitida 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 de timestamps: Padronize todos os timestamps em um único fuso horário. Documente se os timestamps de origem estão armazenados em UTC ou no horário local da empresa. Use o timestamp de origem com a maior precisão disponível.
Atualização incremental: Para extrações recorrentes, use um watermark baseado no maior timestamp de modificação ou de evento da origem, com uma janela de sobreposição para capturar registros de Workflow que chegarem atrasados. Reconcilie a sobreposição antes de carregar o Event Log final.
Performance: Filtre as entidades de origem antes das junções, selecione apenas as colunas necessárias, evite carregar registros históricos de Workflow desnecessários e use query folding quando houver suporte. Extraia separadamente cabeçalhos, linhas, eventos do Workflow e relacionamentos de 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 Workflow. Confirme se as funcionalidades relevantes de compras e Workflow estão habilitadas e se o Power BI Desktop, o conector, a configuração do gateway, quando aplicável, e as políticas de segurança organizacional permitem a extração.
Moeda e valores: Confirme a moeda representada por RequisitionTotalAmount. Se as requisições puderem conter várias moedas, inclua a moeda de origem como um atributo adicional e não converta os valores silenciosamente.
Tratamento de nulos: Os atributos recomendados podem ser null quando a origem não armazena um valor, quando o valor é restrito por segurança ou quando o relacionamento não pode ser resolvido. Os valores obrigatórios de caso, atividade e timestamp do evento devem ser validados antes da exportação.

a 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 Purchase to Pay - Requisition. Comece hoje mesmo a descobrir insights valiosos.

Voltar ao guia de melhoria Baixar Template

Otimize Purchase to Pay - Requisition para aprovações mais rápidas agora

Elimine atrasos e alcance tempos de ciclo 30% menores no Dynamics 365.

Comece seu teste grátis

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

Seu Template de dados de Purchase to Pay - Requisition

Seu Template de dados de Purchase to Pay - Requisition

Purchase to Pay - Requisição: atributos

Purchase to Pay - Requisição: atividades

Guias de extração

Exportação pelo Data Management Framework do Dynamics 365

Etapas

Configuração

a Consulta de exemplo sql

Script Python usando a API REST OData do Dynamics 365

Etapas

Configuração

a Consulta de exemplo python

Extração pelo conector nativo do Microsoft Power BI

Etapas

Configuração

a Consulta de exemplo sql

Pronto para começar?

Otimize Purchase to Pay - Requisition para aprovações mais rápidas agora

Seu Template de dados de Purchase to Pay - Requisition

Seu Template de dados de Purchase to Pay - Requisition

Purchase to Pay - Requisição: atributos

Purchase to Pay - Requisição: atividades

Guias de extração

Exportação pelo Data Management Framework do Dynamics 365

Etapas

Configuração

a Consulta de exemplo sql

Script Python usando a API REST OData do Dynamics 365

Etapas

Configuração

a Consulta de exemplo python

Extração pelo conector nativo do Microsoft Power BI

Etapas

Configuração

a Consulta de exemplo sql

Pronto para começar?

Otimize Purchase to Pay - Requisition para aprovações mais rápidas agora

Valorizamos sua privacidade