> Melhoria Contínua de Processos > Purchase to Pay Processamento de Faturas > Microsoft Dynamics 365 > Modelo de Dados

Seu Template de Dados de Purchase to Pay - Processamento de Faturas

Microsoft Dynamics 365

Purchase to Pay - Atributos de Processamento de Faturas (23) Purchase to Pay - Atividades de Processamento de Faturas (14) Guias de Extração (4)

Seu Template de Dados de Purchase to Pay - Processamento de Faturas

Este template oferece um guia claro para extrair os dados essenciais para analisar seu Purchase to Pay - Processamento de Faturas no Microsoft Dynamics 365. Ele descreve os atributos cruciais, as atividades principais a serem monitoradas e orientações práticas para a extração. Utilize este recurso para garantir que todas as informações necessárias para uma análise e otimização completas do processo sejam coletadas.

Atributos recomendados para coletar para uma análise aprofundada
Principais atividades para monitorar ao longo do ciclo de vida do processamento de faturas
Orientações sobre extração de dados do Microsoft Dynamics 365

É novo em event logs? Saiba como criar um event log para Process Mining.

Baixar Modelo

Purchase to Pay - Atributos de Processamento de Faturas

Estes são os campos de dados recomendados para incluir no seu log de eventos para uma análise completa do seu Purchase to Pay - Processamento de Faturas.

5 Obrigatório 7 Recomendado 11 Opcional

	Nome	Descrição
	Nome da Atividade ActivityName	O nome do evento de negócio ou tarefa específica que ocorreu em um determinado momento no ciclo de vida do processamento da fatura.
Descrição O Nome da Atividade descreve uma etapa específica ou mudança de status no processo da fatura, como 'Fatura Registrada', 'Fatura Enviada para Aprovação' ou 'Pagamento Executado'. Esses dados são essenciais para construir o mapa do processo e entender a sequência de eventos. A análise deste atributo revela o fluxo do processo, identifica caminhos comuns e destaca desvios ou gargalos. É utilizado para calcular tempos de ciclo entre atividades (como o tempo da aprovação ao lançamento) e para medir a frequência de eventos específicos, como rejeições ou bloqueios de pagamento. Por que é importante Define as etapas no mapa de processo, permitindo a visualização do fluxo e a análise das transições entre as diferentes atividades. Onde obter Este atributo é geralmente derivado de uma combinação de campos de status, tipos de transação ou entradas de log de alteração em várias tabelas do Dynamics 365 relacionadas ao processamento de faturas. Exemplos Fatura Enviada para AprovaçãoDivergência de Conciliação EncontradaPagamento Executado
	Número da fatura InvoiceNumber	O identificador exclusivo de cada fatura de fornecedor, servindo como o ID principal do caso para rastrear seu ciclo de vida.
Descrição O Número da Fatura é a chave única que vincula todas as atividades de uma mesma fatura de fornecedor. Ele permite rastrear a jornada completa, do recebimento e registro até a conciliação, aprovação e pagamento final. Na análise de Process Mining, este atributo é fundamental. Ele define o 'caso', permitindo reconstruir o fluxo de cada fatura. Isso possibilita o cálculo de tempos de ciclo totais, a identificação de variantes do processo e a análise de características e resultados específicos de cada fatura. Por que é importante Este é o ID de Caso essencial que conecta todos os eventos relacionados, permitindo analisar o ciclo de vida completo de cada fatura individual. Onde obter Geralmente encontrado na tabela principal de faturas de fornecedor, como a VendInvoiceInfoTable, no campo Num. Exemplos INV-10056773245-AUS-001-98432
	Tempo do Evento EventTime	O timestamp preciso que indica quando uma atividade ou evento específico ocorreu.
Descrição O Event Time, ou timestamp, registra a data e hora exatas de cada atividade. É um componente vital do log de eventos, garantindo a ordem cronológica para sequenciar atividades e calcular durações. Na análise, este campo é a base de todas as métricas temporais. Ele serve para calcular a duração das tarefas, o tempo de ciclo entre etapas (ex: tempo de aprovação) e o tempo total de processamento ponta a ponta, além de permitir análises de tendências ao longo do tempo. Por que é importante Este registro de data e hora é essencial para ordenar os eventos, calcular todos os tempos de ciclo e durações, e identificar gargalos no processo. Onde obter Extraído de vários campos de data/hora em múltiplas tabelas, como os campos createdDateTime ou modifiedDateTime na VendInvoiceInfoTable, VendTrans ou tabelas de histórico de workflow. Exemplos 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Sistema de Origem SourceSystem	O sistema de registro do qual os dados do evento foram extraídos.
Descrição Este atributo identifica o aplicativo de origem onde os dados da atividade foram gerados. Para este processo, normalmente será 'Microsoft Dynamics 365'. Em ambientes com múltiplos sistemas, como soluções externas de OCR ou captura, este campo ajuda a diferenciar onde cada etapa ocorre. Garante a clareza da linhagem dos dados e auxilia na resolução de problemas de extração. Por que é importante Fornece um contexto crucial sobre a origem dos dados, o que é importante para a validação e para entender o ecossistema de sistemas do processo. Onde obter Este é um valor estático, 'Microsoft Dynamics 365', adicionado durante a transformação de dados para identificar a origem do conjunto de dados. Exemplos Microsoft Dynamics 365
	Última Atualização de Dados LastDataUpdate	O registro de data/hora que indica a última vez que os dados deste processo foram atualizados a partir do sistema de origem.
Descrição Este atributo registra quando o conjunto de dados foi extraído e atualizado pela última vez do Microsoft Dynamics 365. Geralmente é o mesmo para todos os registros de uma mesma carga. Essa informação é vital para que os usuários saibam quão recentes são os dados analisados. Fornece contexto sobre a atualidade dos insights e é essencial para gerenciar cronogramas de atualização e validar pipelines de dados. Por que é importante Informa os usuários sobre a atualidade dos dados, garantindo que saibam quão recente é a análise e quando esperar a próxima atualização. Onde obter Este registro de data/hora é gerado e carimbado no conjunto de dados pelo processo de extração ou ETL no momento da execução. Exemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Data de Vencimento do Pagamento PaymentDueDate	A data limite para o pagamento da fatura, de acordo com as condições acordadas.
Descrição A Data de Vencimento é calculada com base na data da fatura e nas condições de pagamento do fornecedor. Representa o prazo contratual para o pagamento. Esta data é crítica para medir o desempenho financeiro e gerir a relação com fornecedores. É a base usada para calcular o KPI de 'Taxa de Pagamento Pontual', comparando-a com a data real do 'Pagamento Executado'. Analisar isso ajuda a identificar problemas sistêmicos que causam atrasos, evitando danos à relação com parceiros ou perda de descontos. Por que é importante Este é o referencial para medir o desempenho de pagamentos pontuais, um KPI essencial para a saúde financeira e relacionamento com fornecedores. Onde obter Esta data costuma ser calculada pelo sistema e armazenada na tabela de transações do fornecedor, como a VendTrans, baseada na data da fatura e nos termos de pagamento. Exemplos 2023-05-152023-06-302023-07-20
	End Time EndTime	O registro preciso de data e hora que indica quando uma atividade ou evento específico foi concluído.
Descrição O End Time registra quando uma atividade foi concluída. Combinado com o Start Time (EventTime), permite calcular com precisão quanto tempo cada etapa levou. Este atributo é essencial para calcular o 'Tempo de Processamento' de cada atividade, uma métrica-chave para análise de desempenho. Ajuda a identificar exatamente quais etapas estão consumindo mais tempo, permitindo esforços de melhoria focados — por exemplo, medindo a duração exata de uma codificação manual ou de uma etapa de aprovação. Por que é importante Permite o cálculo direto dos tempos de processamento das atividades, fundamental para identificar as etapas mais demoradas. Onde obter Assim como o StartTime, este campo é extraído de vários campos de data/hora. Para algumas atividades, pode ser o StartTime da atividade seguinte. Em outros casos, pode ser um registro específico de conclusão (timestamp). Exemplos 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Número do fornecedor VendorNumber	O identificador exclusivo do fornecedor que enviou a fatura.
Descrição O Número do Fornecedor é o código que identifica de forma única um fornecedor nos dados mestres. Ele vincula a transação da fatura a um fornecedor específico, permitindo análises focadas nele. Este atributo é essencial para segmentar os dados do processo por fornecedor. Ajuda a responder perguntas como 'Quais fornecedores têm os tempos de aprovação mais longos?' ou 'Divergências de conciliação são mais comuns com quais fornecedores?'. Analisar o desempenho por fornecedor pode revelar oportunidades de colaboração e melhoria mútua de processos. Por que é importante Permite filtrar e analisar a causa raiz por fornecedor, ajudando a identificar problemas de desempenho ou padrões ligados a fornecedores específicos. Onde obter Geralmente encontrado no cabeçalho da tabela de faturas de fornecedor, como a VendInvoiceInfoTable, vinculado aos dados mestres do fornecedor na VendTable. Exemplos V-1001V-2050V-8342
	Número do Pedido de Compra PurchaseOrderNumber	O identificador do Pedido de Compra (PO) ao qual a fatura está relacionada.
Descrição O Número do Pedido de Compra vincula uma fatura ao documento de aquisição original. É fundamental para processos que envolvem conciliação de 2 ou 3 vias (2-way ou 3-way matching) entre fatura, pedido e recebimento. Este atributo permite analisar faturas com pedido versus faturas sem pedido, que geralmente seguem caminhos diferentes. É essencial para entender a eficácia da conciliação, investigar divergências e medir a taxa de processamento direto para faturas baseadas em pedidos. Por que é importante Distingue faturas vinculadas a pedidos de compra (PO) de faturas sem pedido, que é um dos principais motivos de variação no processo e essencial para a análise de conciliação. Onde obter Localizado na tabela de cabeçalho da fatura, como a VendInvoiceInfoTable, geralmente em um campo como o PurchId. Exemplos PO-001234PO-005678PO-009101
	Status da Fatura InvoiceStatus	O status atual da fatura no momento da extração dos dados.
Descrição O Status da Fatura indica o estado atual da fatura no seu ciclo de vida, como 'Aprovação Pendente', 'Aprovada', 'Lançada' ou 'Paga'. Oferece um retrato do progresso da fatura. Este atributo é usado principalmente para criar Dashboards operacionais que mostram a carga de trabalho atual e o backlog. Ajuda os gestores a entender quantas faturas estão em cada estágio, apoiando a alocação de recursos e o monitoramento. É essencial para o dashboard de 'Volume e Status do Processamento de Faturas'. Por que é importante Fornece uma visão do estado atual de todas as faturas, essencial para o monitoramento operacional, gestão da carga de trabalho e identificação de gargalos imediatos. Onde obter Geralmente derivado de campos de status na tabela principal de faturas, como a VendInvoiceInfoTable. Exemplos Pendente de AprovaçãoLançadoPago
	Utilizador User	O ID do usuário ou nome da pessoa 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. Para etapas automatizadas, pode ser uma conta de sistema ou de serviço. Analisar o processo por usuário ajuda a entender a distribuição de carga de trabalho, identificar necessidades de treinamento e comparar o desempenho entre pessoas ou equipes. É fundamental para analisar loops de retrabalho e entender variações na forma como diferentes usuários concluem a mesma tarefa. Por que é importante Permite analisar o desempenho e a carga de trabalho por usuário ou equipe, além de ajudar a identificar níveis de automação e fontes de retrabalho. Onde obter Extraído de campos de ID de usuário em tabelas de transação ou histórico de workflow, como os campos createdby ou modifiedby. Essas informações podem estar nas tabelas de acompanhamento do workflow. Exemplos j.doea.smithAX_Admin
	Valor da Fatura InvoiceAmount	O valor monetário total da fatura.
Descrição Este atributo representa o valor total devido, conforme indicado na fatura do fornecedor. É um ponto de dado financeiro fundamental para cada caso. O Valor da Fatura é amplamente utilizado para segmentação e análise. Pode revelar se faturas de alto valor seguem processos de aprovação diferentes e mais rigorosos ou se demoram mais para serem processadas. Também é usado em dashboards para analisar volumes por valor e entender o gasto total sob análise. Por que é importante Permite análises baseadas em valor financeiro, ajudando a priorizar melhorias em faturas de alto valor e entender os drivers de custo. Onde obter Encontrado na tabela de cabeçalho da fatura, como VendInvoiceInfoTable, em campos de valor ou montante. Exemplos 1500.00250.7512500.50
	Código da Empresa CompanyCode	O identificador da entidade legal ou empresa dentro da organização que está processando a fatura.
Descrição O Código da Empresa representa a entidade legal específica financeiramente responsável pela fatura. Em organizações com múltiplas empresas, este é um dado crucial para segmentação financeira. Este atributo permite que a análise do processo seja filtrada ou comparada entre diferentes entidades. Ele pode revelar se o desempenho, as políticas ou os gargalos do processo são específicos de certas empresas do grupo, apoiando iniciativas de melhoria localizadas. Por que é importante Permite segmentar a análise por entidade legal, o que é crucial para organizações grandes e com múltiplas empresas. Onde obter Este é um campo padrão na maioria das tabelas financeiras do Dynamics 365, geralmente chamado de DataAreaId. Exemplos USMFDEMFGBSI
	Condições de Pagamento PaymentTerms	O acordo de condições de pagamento com o fornecedor, como '30 dias' ou '2% de desconto para 10 dias, líquido em 30'.
Descrição As Condições de Pagamento definem os termos acordados com o fornecedor, incluindo prazos e possíveis descontos. Essas informações geralmente vêm do cadastro do fornecedor ou do pedido de compra. Este atributo fornece um contexto crucial para a Data de Vencimento e para o KPI de Taxa de Pagamento Pontual. Analisar se certas condições de pagamento estão correlacionadas a atrasos pode revelar desafios operacionais, além de auxiliar no planejamento financeiro e na gestão eficiente do capital de giro. Por que é importante Fornece contexto para as datas de vencimento e ajuda a analisar o impacto financeiro do timing dos pagamentos e das taxas de aproveitamento de descontos. Onde obter Esta informação é armazenada no cadastro do fornecedor (VendTable) e copiada para tabelas de transação como a VendInvoiceInfoTable. Exemplos Líquido 30Líquido 602% 10, Net 30
	Departamento Department	O centro de custo ou departamento para o qual os custos da fatura são alocados.
Descrição O Departamento identifica a unidade de negócio ou centro de custo responsável pela despesa da fatura. Geralmente, isso é definido durante a etapa de codificação. Analisar o processo por departamento é fundamental para entender as diferenças de gastos, tempos de aprovação e conformidade entre as áreas. Isso ajuda a identificar quais departamentos possuem mais exceções ou ciclos de aprovação mais longos, servindo de base para treinamentos e comunicações direcionadas. Por que é importante Permite a análise de custos e processos por departamento, destacando variações de desempenho e conformidade em toda a empresa. Onde obter Extraído das dimensões financeiras vinculadas às linhas ou ao cabeçalho da fatura. Requer consulta às estruturas de dados relacionadas a dimensões. Exemplos VendasMarketingOperações de TI
	É Automatizado IsAutomated	Um indicador que mostra se uma atividade foi realizada automaticamente pelo sistema ou por um usuário humano.
Descrição Este atributo booleano (verdadeiro/falso) distingue eventos executados pelo sistema de tarefas manuais de usuários. Por exemplo, uma etapa de conciliação pode ser automática, enquanto o tratamento de divergências é manual. Analisar este atributo é a chave para entender o nível de automação do processo. Ajuda a medir o sucesso de iniciativas de automação, identifica gargalos manuais remanescentes e destaca oportunidades para novas automações visando reduzir erros e aumentar a eficiência. Por que é importante Ajuda a medir o nível de automação, identificando gargalos manuais e oportunidades de ganho de eficiência. Onde obter Geralmente derivado do atributo 'Usuário'. Se o usuário for uma conta de sistema ou de serviço conhecida, este sinalizador é definido como verdadeiro. Exemplos verdadeirofalse
	É Pagamento em Dia IsOnTimePayment	Indicador calculado que mostra se uma fatura foi paga até a data de vencimento.
Descrição Este atributo booleano é derivado da comparação entre o timestamp da atividade 'Pagamento Executado' e a 'Data de Vencimento'. Se o pagamento ocorreu no prazo ou antes, o valor é verdadeiro; caso contrário, falso. Este atributo sustenta diretamente o KPI de 'Taxa de Pagamento Pontual' e o dashboard de 'Conformidade de Termos de Pagamento'. Ele simplifica a análise ao fornecer um resultado binário claro, facilitando o filtro de pagamentos atrasados e a investigação de suas causas raiz por fornecedor, departamento ou país. Por que é importante Mede diretamente a conformidade com os prazos de pagamento, facilitando o cálculo do KPI de Taxa de Pagamento em Dia. Onde obter Este atributo é calculado na camada de transformação de dados. A lógica é: (Timestamp da atividade 'Pagamento Executado') <= (Data de Vencimento). Exemplos verdadeirofalse
	Moeda da Fatura InvoiceCurrency	O código da moeda para o valor da fatura (por exemplo, USD, EUR).
Descrição A Moeda da Fatura especifica a unidade monetária do valor faturado. É fundamental para multinacionais que lidam com fornecedores de diversos países. Este atributo fornece o contexto necessário para o Valor da Fatura e é usado para filtros e relatórios em operações globais. Ele garante que os valores financeiros sejam interpretados corretamente e permite análises por moeda ou conversão para uma moeda padrão de relatório. Por que é importante Fornece o contexto essencial para valores financeiros, permitindo a interpretação precisa e a análise dos valores das faturas em diferentes regiões. Onde obter Localizado na tabela de cabeçalho da fatura junto ao valor, por exemplo, no campo CurrencyCode da VendInvoiceInfoTable. Exemplos USDEURGBP
	Motivo da Rejeição RejectionReason	O motivo fornecido por um aprovador para rejeitar uma fatura.
Descrição Quando uma fatura é rejeitada durante o workflow de aprovação, o aprovador geralmente fornece um motivo. Esse atributo captura essa explicação, que pode ser um código predefinido ou um texto livre. Este atributo é fundamental para o dashboard de "Análise de Rejeição de Faturas". Ele fornece o insight qualitativo necessário para entender as causas raiz das rejeições, como "Número de OC Incorreto", "Fatura Duplicada" ou "Divergência de Preço". Analisar esses motivos ajuda a priorizar ações para reduzir a taxa de rejeição. Por que é importante Oferece insights diretos sobre o motivo da rejeição das faturas, permitindo ações focadas para reduzir o retrabalho e melhorar as taxas de acerto na primeira tentativa (first-time-right). Onde obter Geralmente encontrado nos comentários ou logs de histórico das tabelas de processamento de workflow. Exemplos Quantidade incorretaFatura duplicadaLimite de aprovação excedido
	Razão de Bloqueio de Pagamento PaymentBlockReason	O código de motivo que explica por que um bloqueio de pagamento foi aplicado a uma fatura.
Descrição Um bloqueio de pagamento impede que uma fatura seja paga. Este atributo captura o motivo do bloqueio, que geralmente é um código padronizado como 'Cobranças contestadas' ou 'Aguardando recebimento de mercadorias'. Este atributo é essencial para o dashboard de 'Frequência e Duração de Bloqueios de Pagamento'. Analisar os motivos mais comuns ajuda a identificar problemas subjacentes no processo P2P. Resolver essas causas raiz pode reduzir drasticamente os atrasos de pagamento e melhorar o relacionamento com fornecedores. Por que é importante Explica por que os pagamentos são retidos intencionalmente, ajudando a resolver problemas anteriores que causam bloqueios. Onde obter Geralmente é um campo no registro de transação do fornecedor ou da fatura, relacionado ao status de bloqueio de pagamento. Verifique em tabelas como a VendTrans. Exemplos Disputa de qualidadeAguardando nota de créditoBloqueio manual
	Tempo de ciclo total TotalCycleTime	A duração total de ponta a ponta para processar uma única fatura, do recebimento ao pagamento.
Descrição O Tempo de Ciclo Total mede a duração completa de uma fatura no processo. É calculado pela diferença de tempo entre a primeira atividade (ex: 'Fatura Registrada') e a última atividade (ex: 'Pagamento Executado') para um determinado número de fatura. Este é o KPI principal para medir a eficiência geral do processo. Ele oferece uma visão macro do desempenho e alimenta o dashboard de 'Tempo de Ciclo de Ponta a Ponta'. Analisar tendências nesta métrica e segmentá-la por atributos como fornecedor ou valor ajuda a identificar amplas oportunidades de melhoria. Por que é importante Representa o KPI principal de alto nível para a velocidade e eficiência geral do processo, resumindo o desempenho de cada fatura. Onde obter Isso é calculado no nível do caso dentro da ferramenta de process mining ou durante a preparação dos dados. É a diferença de tempo entre o primeiro e o último registro (timestamp) de cada CaseId. Exemplos P15DP22DT5H30MP7D
	Tempo de Processamento ProcessingTime	A duração de uma única atividade, calculada como a diferença entre o horário de término e de início.
Descrição O Tempo de Processamento mede o tempo ativo gasto em uma tarefa específica. É calculado subtraindo o StartTime de um evento do seu EndTime, também conhecido como duração da atividade. Essa métrica é fundamental para a análise de desempenho. Ela ajuda a identificar quais atividades consomem mais tempo, diferenciando-as dos tempos de espera entre elas. Isso permite melhorias focadas, como treinamentos específicos para agilizar a codificação manual ou a otimização de etapas do sistema que estejam lentas. Por que é importante Mede a duração real de trabalho das atividades, ajudando a identificar tarefas ineficientes que podem ser otimizadas ou automatizadas. Onde obter Este não é um campo do sistema de origem. Ele é calculado durante a transformação de dados usando a fórmula: EndTime - StartTime. Exemplos PT1H30MP2DT4HPT5M15S
	Tipo de Discrepância MatchingDiscrepancyType	Categoriza o tipo de divergência encontrada durante a conciliação entre fatura e pedido de compra (PO).
Descrição Quando ocorre uma divergência na conciliação (2-way ou 3-way matching), este atributo especifica a natureza do problema, como 'Divergência de Preço', 'Divergência de Quantidade' ou 'Recebimento de Mercadoria Ausente'. Estes dados são centrais para o dashboard de 'Tempo de Resolução de Divergências de Conciliação'. Ao analisar a frequência dos tipos de divergência, a empresa pode identificar as causas raiz das falhas. Por exemplo, divergências frequentes de preço podem indicar dados mestres desatualizados, enquanto divergências de quantidade podem apontar problemas no envio das mercadorias. Por que é importante Categoriza falhas de conciliação, permitindo a análise da causa raiz para reduzir as divergências e aumentar o processamento direto (straight-through processing). Onde obter Pode estar armazenado em uma tabela dedicada de logs de conciliação ou exceções, ou pode precisar ser derivado de mensagens de status ou comentários de workflow. Exemplos Divergência de PreçoDivergência de QuantidadeEntrada de Mercadoria Ausente

Obrigatório Recomendado Opcional

Purchase to Pay - Atividades de Processamento de Faturas

Estas são as etapas e marcos chave do processo a serem capturados no seu log de eventos para uma descoberta e análise precisas do seu workflow de processamento de faturas.

6 Recomendado 8 Opcional

	Atividade	Descrição
	Fatura Aprovada	Representa a aprovação final e bem-sucedida da fatura no workflow, autorizando seu lançamento e pagamento. Este é um evento explícito registrado pelo motor de workflow na conclusão.
Por que é importante Este é um marco crítico que encerra o processo de aprovação. O tempo decorrido desde 'Fatura Enviada para Aprovação' até este evento é uma medida essencial da eficiência da aprovação e ajuda a identificar gargalos. Onde obter Este é um evento explícito registrado nas tabelas de histórico de workflow (ex: WorkflowTrackingStatusTable) quando o status muda para 'Aprovado'. Captura Registro de data/hora da entrada do status 'Aprovado' no histórico do workflow. Tipo de evento explicit
	Fatura Conciliada com PO	Representa a conclusão bem-sucedida do processo de conciliação, onde os detalhes da fatura coincidem com o pedido de compra e as informações de recebimento de mercadorias. Este evento é inferido quando o status de conciliação da fatura é atualizado para 'Aprovado'.
Por que é importante A conciliação bem-sucedida é um marco essencial para faturas com pedido, confirmando a validade da cobrança antes do pagamento. É fundamental para monitorar a eficiência da conciliação e as taxas de automação. Onde obter Inferido pela atualização do status de conciliação no cabeçalho ou linhas da fatura para 'Sucesso'. Captura Registro de data/hora da mudança de status para 'Aprovado' nos detalhes de validação da conciliação. Tipo de evento inferred
	Fatura Enviada para Aprovação	Esta atividade marca o envio formal de uma fatura para um workflow de revisão e aprovação. O motor de workflow do Dynamics 365 registra explicitamente este evento de submissão.
Por que é importante Este é o ponto de partida para medir todo o ciclo de aprovação. Ajuda a identificar quanto tempo as faturas esperam antes mesmo do início da aprovação e serve como gatilho para os KPIs relacionados. Onde obter Este é um evento explícito registrado nas tabelas de histórico de workflow (ex: WorkflowTrackingStatusTable) quando uma fatura é submetida a um fluxo. Captura Timestamp de criação do registro de submissão no histórico de workflow. Tipo de evento explicit
	Fatura Lançada	Este é o evento contábil formal onde a fatura aprovada é registrada no Livro Razão, criando um passivo. É um evento transacional explícito no sistema.
Por que é importante O lançamento é a etapa final antes do pagamento e um ponto de controle financeiro essencial. O tempo decorrido entre 'Fatura Aprovada' e 'Fatura Lançada' mede a eficiência das etapas contábeis finais. Onde obter Este é um evento explícito capturado a partir da criação da transação lançada do fornecedor em tabelas como VendTrans e nos registros GeneralJournalEntry e LedgerEntry associados. Captura Timestamp de criação do registro na tabela de transações do fornecedor (VendTrans). Tipo de evento explicit
	Fatura Registrada	Esta é a entrada inicial de uma fatura no sistema, criando um registro temporário antes do processamento dos detalhes completos. Esta atividade é capturada quando um novo registro é criado no diário de registro de faturas de fornecedor.
Por que é importante Esta atividade marca o início oficial do ciclo de processamento da fatura. Analisar o tempo a partir deste ponto ajuda a medir a duração total e identifica atrasos nas etapas iniciais. Onde obter Este é um evento explícito capturado a partir da criação de um registro no registro de faturas de fornecedor, geralmente na tabela VendInvoiceRegisterJournalTable ou similar. Captura Timestamp de criação do registro no Diário de Registro de Faturas de Fornecedores. Tipo de evento explicit
	Pagamento Executado	Esta é a atividade final, que representa o lançamento do diário de pagamentos, criando o pagamento e liquidando a fatura. É um evento transacional explícito que encerra o ciclo de vida da fatura.
Por que é importante Esta atividade marca o encerramento bem-sucedido do processo de fatura ao pagamento. É a base para medir a 'Taxa de Pagamento Pontual' e o tempo total do ciclo de ponta a ponta. Onde obter Este é um evento explícito capturado a partir do lançamento do diário de pagamentos. As informações de liquidação são gravadas em tabelas como VendSettlement, vinculando o pagamento à fatura. Captura Registro da data/hora (timestamp) do lançamento do diário de pagamentos que liquida a transação do fornecedor. Tipo de evento explicit
	Bloqueio de Pagamento Ativado	Esta atividade ocorre quando uma retenção é aplicada a uma fatura, impedindo seu pagamento. Isso é capturado por uma alteração no campo de bloqueio de pagamento ou status de retenção no registro da fatura lançada.
Por que é importante Bloqueios de pagamento são uma das principais causas de atrasos. Analisar quando e por que eles ocorrem é essencial para melhorar a pontualidade dos pagamentos e o relacionamento com fornecedores. Onde obter Inferido a partir da alteração no campo de retenção ou bloqueio de pagamento na transação do fornecedor lançada (VendTrans). Captura Registro de data/hora da atualização que define o campo de bloqueio de pagamento na transação do fornecedor. Tipo de evento inferred
	Bloqueio de Pagamento Liberado	Representa a remoção de uma retenção de pagamento, permitindo que a fatura prossiga para o agendamento do pagamento. É capturado quando o campo de bloqueio de pagamento é limpo ou alterado para um estado desbloqueado.
Por que é importante Mede o tempo necessário para resolver problemas que causam retenções de pagamento. Intervalos longos entre a criação e a liberação de um bloqueio indicam processos ineficientes de resolução de problemas. Onde obter Inferido a partir da limpeza do campo de retenção ou bloqueio de pagamento na transação do fornecedor lançada (VendTrans). Captura Registro de data/hora da atualização que limpa o campo de bloqueio de pagamento na transação do fornecedor. Tipo de evento inferred
	Dados da Fatura Capturados	Representa a conclusão da entrada de dados da fatura, incluindo detalhes de cabeçalho e linhas, antes de ser submetida para conciliação ou aprovação. Geralmente é inferido quando o registro da fatura muda de status 'novo' ou 'registrado' para 'pronto para processamento'.
Por que é importante Monitorar esta atividade ajuda a medir a eficiência da entrada de dados, seja ela manual ou automatizada (OCR). Atrasos aqui podem impactar todo o restante do processo. Onde obter Inferido a partir de mudanças de status no registro da fatura pendente. O evento ocorre quando os campos obrigatórios são preenchidos e a fatura está pronta. Captura Detecta a mudança de status na tabela de faturas pendentes, indicando a conclusão da entrada de dados. Tipo de evento inferred
	Divergência de Conciliação Encontrada	Esta atividade ocorre quando o processo de conciliação da fatura falha por divergências entre fatura, pedido de compra ou recebimento de mercadoria. É capturada quando o status de conciliação é definido como 'Falha' ou 'Divergência'.
Por que é importante Identificar quando e por que as divergências ocorrem é vital para o KPI de 'Taxa de Discrepância de Conciliação'. Esta atividade marca o início da resolução, que costuma ser foco de grandes atrasos. Onde obter Inferido pela atualização do campo de status de conciliação para 'Falha'. O motivo da falha costuma ser registrado também. Captura Registro de data/hora da mudança de status para 'Falha' ou 'Divergência' durante a conciliação. Tipo de evento inferred
	Divergência de Conciliação Tratada	Marca a resolução de uma divergência de conciliação identificada anteriormente, permitindo que a fatura prossiga. Isso é inferido quando uma fatura com status de conciliação 'Falha' é conciliada novamente com sucesso ou sofre uma intervenção manual.
Por que é importante Esta atividade encerra o sub-processo de resolução de divergências. O tempo entre 'Divergência de Conciliação Encontrada' e este evento é um KPI essencial para medir a eficiência da resolução. Onde obter Inferido por um evento de conciliação bem-sucedido que ocorre após um evento de discrepância encontrada para a mesma fatura. Captura Identifica o timestamp de um status de conciliação 'Aprovado' que segue um status de 'Falha'. Tipo de evento inferred
	Fatura Codificada	Esta atividade indica que as distribuições contábeis do Livro Razão foram atribuídas às linhas da fatura. Geralmente é inferida pela criação ou finalização das distribuições de contas vinculadas à fatura.
Por que é importante A codificação é crucial para a precisão financeira. Medir o tempo gasto nessa etapa ajuda a identificar gargalos na revisão contábil e sustenta o KPI de 'Tempo Médio da Captura à Codificação'. Onde obter Inferido a partir da criação e validação de registros nas tabelas de distribuição contábil associadas à fatura pendente. Captura Registro de data/hora de quando as distribuições contábeis da fatura são salvas e validadas. Tipo de evento inferred
	Fatura Rejeitada	Indica que um aprovador rejeitou a fatura, interrompendo o fluxo e enviando-a de volta para correção. O motor de workflow registra esse evento explicitamente.
Por que é importante O rastreamento de rejeições ajuda a quantificar o retrabalho e identificar motivos comuns de falha, como codificação incorreta ou violação de políticas. Isso sustenta diretamente o KPI de 'Taxa de Rejeição de Faturas'. Onde obter Este é um evento explícito registrado nas tabelas de histórico de workflow (ex: WorkflowTrackingStatusTable) quando o status muda para 'Rejeitado' ou 'Cancelado'. Captura Registro de data/hora da entrada do status 'Rejeitado' no histórico do workflow. Tipo de evento explicit
	Pagamento Agendado	Esta atividade ocorre quando uma fatura lançada é incluída em uma proposta de pagamento ou em um diário de pagamentos, mas antes da execução do pagamento. É uma ação explícita que cria uma linha no diário de pagamentos.
Por que é importante Marca a transição do Contas a Pagar para as operações de Tesouraria. Analisar esta etapa pode revelar atrasos entre o lançamento da fatura e o início do pagamento. Onde obter Este é um evento explícito capturado a partir da criação de uma linha em um diário de pagamentos (LedgerJournalTrans) que liquida a transação lançada do fornecedor. Captura Timestamp de criação da linha do diário de pagamento que referencia a fatura. Tipo de evento explicit

Recomendado Opcional

Guias de Extração

Como obter os seus dados do Microsoft Dynamics 365

Etapas

Acesse o Workspace de Gestão de Dados: Faça login no Microsoft Dynamics 365 Finance. Use a barra de busca para encontrar e navegar até o workspace Data management.
Crie um Novo Projeto de Exportação: No workspace, selecione o bloco Export para criar um novo projeto. Dê um nome significativo, como ProcessMind_Invoice_Processing_Export.
Defina o Projeto de Dados: Na aba General, especifique o Data format. Recomendamos o formato CSV. Configure os outros parâmetros conforme necessário.
Adicione as Entidades de Dados Necessárias: Vá para a seção Selected entities e clique em Add entity. Busque e adicione as seguintes entidades principais, uma por uma, especificando o formato de destino:
- VendInvoiceInfoTableEntity (Cabeçalho da fatura do fornecedor)
- VendInvoiceTransEntity (Linhas da fatura do fornecedor)
- VendInvoiceRegisterHeaderEntity (Cabeçalho do diário de registro de faturas)
- WorkflowTrackingStatusTableEntity (Histórico de workflow)
- AccountingDistributionEntity (Distribuições contábeis)
- VendInvoiceJour (Faturas de fornecedor lançadas)
- VendTrans (Transações de fornecedor, para bloqueios de pagamento)
- LedgerJournalTransVendPaymEntity (Linhas do diário de pagamento de fornecedor)
- VendSettlement (Transações de liquidação de fornecedor)
Aplique os Filtros: Para cada entidade, é fundamental filtrar o escopo dos dados. Selecione a entidade e clique em Filter. No mínimo, filtre por Company (Entidade Legal) e um intervalo de datas em um campo relevante como CREATEDDATETIME ou INVOICEDATE. O ideal para análise inicial são os últimos 3 a 6 meses.
Configure os Mapeamentos: Revise o mapeamento de origem para destino de cada entidade. Garanta que todos os campos necessários para o log de eventos final estejam incluídos. Geralmente, não são precisas mudanças complexas nesta etapa.
Execute o Job de Exportação: Com tudo configurado, clique em Export no Painel de Ações. Você pode executar agora ou agendar para horários de menor pico.
Baixe os Dados Exportados: Quando o job for concluído com sucesso, acesse o histórico do trabalho e baixe o pacote de dados, que conterá arquivos separados para cada entidade.
Transforme os Dados em um Log de Eventos: Os arquivos exportados são snapshots, não um log consolidado. Use uma ferramenta externa (banco de dados, script Python ou Power Query) para combinar esses arquivos. A lógica está detalhada na seção query.
Execute a Lógica de Transformação: Carregue os CSVs no seu ambiente de transformação. Execute a query fornecida para unir os dados e criar uma tabela única com uma linha por atividade de negócio.
Finalize e Faça o Upload: Exportre o resultado final para um único arquivo CSV. Verifique se os cabeçalhos das colunas estão corretos (ex: InvoiceNumber, ActivityName, EventTime). O arquivo agora está pronto para o ProcessMind.

Configuração

Entidades de Dados: O cerne da configuração é selecionar o conjunto correto de entidades para cobrir o ciclo de vida da fatura. As principais entidades incluem VendInvoiceInfoTableEntity, VendInvoiceJour e WorkflowTrackingStatusTableEntity.
Formato de Exportação de Dados: Selecione CSV como o formato de dados de destino para facilitar o processamento nas etapas de transformação subsequentes.
Filtragem por Empresa: É crucial filtrar cada entidade de dados pela entidade legal específica (Empresa) que você está analisando para evitar a extração de dados irrelevantes.
Filtragem por Intervalo de Datas: Aplique um filtro de intervalo de datas consistente em todas as entidades relevantes, como VendInvoiceInfoTableEntity e VendInvoiceJour, com base nas datas de criação ou lançamento. Comece com um período recente, por exemplo, os últimos 6 meses, para gerenciar o volume de dados.
Carga total vs. Incremental: Para a extração inicial, realize uma carga total (full push). Para atualizações subsequentes, você pode configurar uma exportação incremental para buscar apenas os dados que mudaram desde a última execução, reduzindo o tempo de processamento.
Pré-requisitos: O usuário que executa a exportação deve ter as funções de segurança apropriadas no Dynamics 365, normalmente incluindo Data management administrator ou uma função semelhante com permissões para acessar as entidades de dados necessárias.

a Consulta de Exemplo config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Etapas

Pré-requisito: Configurar o BYOD: Certifique-se de que o recurso "Bring Your Own Database" esteja configurado em seu ambiente Dynamics 365. Isso envolve configurar um Banco de Dados SQL do Azure e apontar o D365 para exportar dados para ele.
Identificar Entidades de Dados: No D365, vá até o workspace Data management. A extração depende da exportação de entidades específicas. Garanta que as seguintes entidades estejam no job de exportação para seu BYOD: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements e Accounting distributions.
Criar e Agendar o Job de Exportação: No workspace Data management, crie um projeto de exportação. Adicione as entidades citadas e defina o formato de destino como seu banco de dados BYOD. Configure um agendamento recorrente (diário ou por hora) para manter os dados atualizados no Azure SQL.
Verificar Dados no Azure SQL: Conecte-se ao seu banco usando ferramentas como o SSMS ou Azure Data Studio. Verifique se as tabelas correspondentes às entidades do D365 foram criadas e estão povoadas.
Preparar a Query SQL: Copie a consulta SQL fornecida. Ela foi desenhada para rodar diretamente nas tabelas geradas pelo processo de exportação do BYOD no seu banco de dados.
Conectar e Executar: Abra uma nova janela de consulta no seu cliente SQL conectado ao BYOD e cole o código.
Definir Parâmetros da Consulta: Localize as variáveis no topo do script. Substitua {StartDate}, {EndDate} e {CompanyCode} pelo período desejado e o identificador da entidade legal. Exemplo: SET @StartDate = '2023-01-01';, SET @CompanyCode = 'USMF';.
Rodar a Query: Execute o script SQL completo. A query unirá os dados de várias tabelas para construir um log de eventos cronológico para cada fatura.
Revisar os Resultados: A saída será uma tabela única com colunas como InvoiceNumber, ActivityName, EventTime, etc. Verifique se os dados parecem corretos e completos.
Exportar o Log de Eventos: Exporte os resultados para um arquivo CSV. A maioria dos clientes SQL tem essa função integrada. Salve o arquivo com codificação UTF-8.
Preparar para Upload: Antes de subir para a ferramenta de process mining, confirme se o CSV possui os cabeçalhos exatos conforme especificado na query. Nenhuma transformação adicional é necessária.

Configuração

Principais Entidades de Dados: A extração depende da exportação de várias entidades de dados do D365 para o BYOD. As entidades críticas incluem: VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution e VendTrans.
Filtragem por Intervalo de Datas: A consulta fornecida inclui os parâmetros @StartDate e @EndDate. Recomendamos começar com um intervalo de datas limitado, como 3 a 6 meses de dados, para garantir o desempenho. O filtro é aplicado à data de lançamento ou data de criação da fatura.
Filtragem por Código da Empresa: O parâmetro @DataAreaId é crucial para ambientes multi-empresa. Sempre filtre por uma entidade legal específica (Código da Empresa) para garantir que o contexto dos dados esteja correto.
Frequência de Atualização do BYOD: A atualidade dos dados depende inteiramente do agendamento do job de exportação do D365. Para análises em tempo quase real, é necessária uma alta frequência (ex: de hora em hora), o que pode ter implicações de desempenho e custo tanto no D365 quanto no Azure.
Pré-requisitos: Este método requer uma assinatura ativa do Azure, um Banco de Dados SQL do Azure provisionado e acesso de nível de administrador no D365 para configurar o workspace de Data management.

a Consulta de Exemplo sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

Etapas

Configuração dos Pré-requisitos: Certifique-se de ter o Python 3.6 ou superior instalado. Instale as bibliotecas necessárias via pip: pip install pandas requests msal. Elas são usadas para manipular dados, fazer requisições HTTP e gerenciar a autenticação na plataforma de identidade da Microsoft.
Registrar um Aplicativo no Azure Active Directory: Para autenticar na API do Dynamics 365, você deve registrar um aplicativo no locatário (tenant) do Azure AD da sua empresa. Crie um novo Registro de Aplicativo, gere um segredo do cliente e anote o ID do Aplicativo (cliente), o ID do Diretório (tenant) e o valor do segredo.
Conceder Permissões de API: No Registro de Aplicativo criado, acesse as permissões de API. Adicione a permissão para 'Dynamics ERP' e conceda a permissão delegada user_impersonation. Um administrador deve fornecer o consentimento para essas permissões.
Criar um Usuário de Aplicativo no Dynamics 365: No seu ambiente Dynamics 365, vá em Administração do sistema > Usuários > Usuários. Crie um novo usuário e insira o ID do Aplicativo (cliente) do Azure no campo ID do Aplicativo. Atribua as funções de segurança necessárias (ex: Administrador do sistema ou uma função de leitura para as entidades de dados).
Configurar o Script Python: Copie o script Python fornecido em um arquivo, por exemplo, extract_invoices.py. Atualize as variáveis no topo do arquivo com a URL do seu ambiente, ID do tenant, ID do cliente, segredo do cliente e o código da empresa (dataAreaId).
Definir o Intervalo de Datas: Ajuste as variáveis START_DATE e END_DATE no script. Recomendamos começar com um período curto, como um mês, para testar e validar os resultados.
Executar o Script: Rode o script pelo seu terminal ou linha de comando: python extract_invoices.py. O script fará a autenticação, consultará os endpoints OData para cada atividade e processará os dados.
Monitorar a Execução: O script exibirá mensagens de progresso no console enquanto busca os dados de cada atividade. O tempo total depende do volume de dados. Fique atento a mensagens de erro de autenticação ou acesso à API.
Revisar o Arquivo de Saída: Após a conclusão, um arquivo CSV chamado d365_invoice_event_log.csv será gerado no mesmo diretório, contendo o log de eventos consolidado.
Preparar para Upload: Abra o CSV para garantir que a formatação está correta. Verifique se colunas como InvoiceNumber, ActivityName e EventTime estão preenchidas. O arquivo está pronto para ser enviado ao ProcessMind.

Configuração

Autenticação: O script utiliza o fluxo de credenciais de cliente OAuth 2.0. Você deve configurar um Registro de Aplicativo no Azure AD e conceder permissões de API para o Dynamics 365. Um usuário de aplicativo com as funções de segurança apropriadas deve ser criado no próprio Dynamics 365.
API Endpoint: A URL base para a API OData do Dynamics 365 Finance and Operations. O formato é geralmente https://[seu-ambiente-d365].operations.dynamics.com.
Intervalo de Datas: O script inclui as variáveis START_DATE e END_DATE. Elas são usadas para filtrar registros com base em suas datas de criação ou modificação para gerenciar o volume de dados. Para extrações iniciais, recomenda-se um período de 3 a 6 meses.
Filtro de Empresa: Os dados devem ser filtrados por uma entidade legal ou empresa específica. Isso é feito especificando o dataAreaId no filtro de consulta da API, que é uma configuração obrigatória no script.
Principais Entidades de Dados: O script consulta várias entidades OData padrão do Dynamics 365, incluindo VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines e VendSettlements. Entidades personalizadas podem ser necessárias se o processo padrão for muito modificado.
Paginação: O script lida automaticamente com respostas paginadas da API usando a propriedade @odata.nextLink para garantir que todos os registros do período especificado sejam recuperados.

a Consulta de Exemplo python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].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]"
COMPANY_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

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

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

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

Etapas

Acesse o Workspace de Gestão de Dados: Faça login no Microsoft Dynamics 365 Finance. Use a barra de busca para encontrar e navegar até o workspace Data management.
Crie um Novo Projeto de Exportação: No workspace, selecione o bloco Export para criar um novo projeto. Dê um nome significativo, como ProcessMind_Invoice_Processing_Export.
Defina o Projeto de Dados: Na aba General, especifique o Data format. Recomendamos o formato CSV. Configure os outros parâmetros conforme necessário.
Adicione as Entidades de Dados Necessárias: Vá para a seção Selected entities e clique em Add entity. Busque e adicione as seguintes entidades principais, uma por uma, especificando o formato de destino:
- VendInvoiceInfoTableEntity (Cabeçalho da fatura do fornecedor)
- VendInvoiceTransEntity (Linhas da fatura do fornecedor)
- VendInvoiceRegisterHeaderEntity (Cabeçalho do diário de registro de faturas)
- WorkflowTrackingStatusTableEntity (Histórico de workflow)
- AccountingDistributionEntity (Distribuições contábeis)
- VendInvoiceJour (Faturas de fornecedor lançadas)
- VendTrans (Transações de fornecedor, para bloqueios de pagamento)
- LedgerJournalTransVendPaymEntity (Linhas do diário de pagamento de fornecedor)
- VendSettlement (Transações de liquidação de fornecedor)
Aplique os Filtros: Para cada entidade, é fundamental filtrar o escopo dos dados. Selecione a entidade e clique em Filter. No mínimo, filtre por Company (Entidade Legal) e um intervalo de datas em um campo relevante como CREATEDDATETIME ou INVOICEDATE. O ideal para análise inicial são os últimos 3 a 6 meses.
Configure os Mapeamentos: Revise o mapeamento de origem para destino de cada entidade. Garanta que todos os campos necessários para o log de eventos final estejam incluídos. Geralmente, não são precisas mudanças complexas nesta etapa.
Execute o Job de Exportação: Com tudo configurado, clique em Export no Painel de Ações. Você pode executar agora ou agendar para horários de menor pico.
Baixe os Dados Exportados: Quando o job for concluído com sucesso, acesse o histórico do trabalho e baixe o pacote de dados, que conterá arquivos separados para cada entidade.
Transforme os Dados em um Log de Eventos: Os arquivos exportados são snapshots, não um log consolidado. Use uma ferramenta externa (banco de dados, script Python ou Power Query) para combinar esses arquivos. A lógica está detalhada na seção query.
Execute a Lógica de Transformação: Carregue os CSVs no seu ambiente de transformação. Execute a query fornecida para unir os dados e criar uma tabela única com uma linha por atividade de negócio.
Finalize e Faça o Upload: Exportre o resultado final para um único arquivo CSV. Verifique se os cabeçalhos das colunas estão corretos (ex: InvoiceNumber, ActivityName, EventTime). O arquivo agora está pronto para o ProcessMind.

Configuração

Entidades de Dados: O cerne da configuração é selecionar o conjunto correto de entidades para cobrir o ciclo de vida da fatura. As principais entidades incluem VendInvoiceInfoTableEntity, VendInvoiceJour e WorkflowTrackingStatusTableEntity.
Formato de Exportação de Dados: Selecione CSV como o formato de dados de destino para facilitar o processamento nas etapas de transformação subsequentes.
Filtragem por Empresa: É crucial filtrar cada entidade de dados pela entidade legal específica (Empresa) que você está analisando para evitar a extração de dados irrelevantes.
Filtragem por Intervalo de Datas: Aplique um filtro de intervalo de datas consistente em todas as entidades relevantes, como VendInvoiceInfoTableEntity e VendInvoiceJour, com base nas datas de criação ou lançamento. Comece com um período recente, por exemplo, os últimos 6 meses, para gerenciar o volume de dados.
Carga total vs. Incremental: Para a extração inicial, realize uma carga total (full push). Para atualizações subsequentes, você pode configurar uma exportação incremental para buscar apenas os dados que mudaram desde a última execução, reduzindo o tempo de processamento.
Pré-requisitos: O usuário que executa a exportação deve ter as funções de segurança apropriadas no Dynamics 365, normalmente incluindo Data management administrator ou uma função semelhante com permissões para acessar as entidades de dados necessárias.

a Consulta de Exemplo config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Seu Template de Dados de Purchase to Pay - Processamento de Faturas

Seu Template de Dados de Purchase to Pay - Processamento de Faturas

Purchase to Pay - Atributos de Processamento de Faturas

Purchase to Pay - Atividades de Processamento de Faturas

Guias de Extração

Exportação do Data Management Framework do Dynamics 365

Etapas

Configuração

a Consulta de Exemplo config

Consulta SQL Direta via Bring Your Own Database (BYOD)

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 via Microsoft Power Platform Dataflow

Etapas

Configuração

a Consulta de Exemplo config

Pronto para Começar?

Comece a otimizar seu processo de Purchase to Pay hoje mesmo

Seu Template de Dados de Purchase to Pay - Processamento de Faturas

Seu Template de Dados de Purchase to Pay - Processamento de Faturas

Purchase to Pay - Atributos de Processamento de Faturas

Purchase to Pay - Atividades de Processamento de Faturas

Guias de Extração

Exportação do Data Management Framework do Dynamics 365

Etapas

Configuração

a Consulta de Exemplo config

Consulta SQL Direta via Bring Your Own Database (BYOD)

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 via Microsoft Power Platform Dataflow

Etapas

Configuração

a Consulta de Exemplo config

Valorizamos sua privacidade

Pronto para Começar?

Comece a otimizar seu processo de Purchase to Pay hoje mesmo