> Melhoria contínua de processos > Pedido ao recebimento: faturamento e emissão de faturas > Microsoft Dynamics 365 > Template de dados

Seu Template de dados de pedido ao recebimento, faturamento e emissão de faturas

Microsoft Dynamics 365

← Voltar ao guia de melhoria

Atributos de pedido ao recebimento, faturamento e emissão de faturas(18) Atividades de pedido ao recebimento, faturamento e emissão de faturas(12) Guias de extração(2)

Seu Template de dados de pedido ao recebimento, faturamento e emissão de faturas

Este Template apresenta um roteiro claro para coletar os dados essenciais à análise do processo de pedido ao recebimento, faturamento e emissão de faturas. Você encontrará atributos recomendados para incluir no Event Log, atividades importantes para acompanhar e orientações práticas para extrair essas informações. Ele ajuda você a preparar os dados rapidamente para uma análise de Process Mining mais esclarecedora.

Atributos recomendados para coleta
Atividades importantes para acompanhar
Orientações para extração de dados do Microsoft Dynamics 365

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

Baixar Template

Atributos de pedido ao recebimento, faturamento e emissão de faturas

Estes são os campos de dados recomendados para incluir no Event Log e fazer uma análise completa do processo de pedido ao recebimento, faturamento e emissão de faturas.

3 Obrigatório 6 Recomendado 9 Opcional

	Nome	Descrição
	Número da fatura InvoiceNumber	Identificador exclusivo de cada fatura de cliente, usado como identificador principal do caso no processo de faturamento.
Descrição O número da fatura é a chave central que agrupa todas as atividades relacionadas a um único documento de faturamento. Ele permite analisar todo o ciclo de vida da fatura, da geração e aprovação ao pagamento pelo cliente e ao encerramento. Ao usar esse número como ID do caso, cada registro de evento corresponde a uma fatura específica, permitindo analisar variantes em detalhes, calcular o tempo de ciclo e monitorar a performance de cada transação de faturamento. Por que isso importa Este atributo é essencial para acompanhar todo o ciclo de vida de uma fatura e analisar a eficiência do processo, os gargalos e os desvios de cada documento de faturamento. Onde encontrar Esse dado costuma estar no módulo de Vendas e marketing, em tabelas como CustInvoiceJour (campo InvoiceId), ou disponível por meio de entidades de dados como SalesInvoiceHeaderV2. Exemplos CIV-001254INV-2023-9876US-004321
	Data e hora do evento EventTime	Data e hora exatas em que uma atividade ou um evento específico ocorreu.
Descrição A data e hora do evento registram o momento exato de cada atividade do processo. Esses dados são essenciais para todas as análises de mineração de processos baseadas em tempo. Eles servem para calcular os tempos de ciclo entre atividades, medir a duração total de um caso e entender a performance do processo ao longo do tempo. Datas e horas precisas e confiáveis são a base de KPIs como o prazo médio de recebimento de vendas e o tempo de geração de faturas. Por que isso importa Este é o atributo fundamental para todas as análises de performance e tempo. Com ele, é possível calcular tempos de ciclo, durações e volume de processamento para medir a eficiência do processo. Onde encontrar Os registros de data e hora vêm de vários campos de data e hora em diferentes tabelas do Dynamics 365, como CreatedDateTime na tabela CustInvoiceJour, usado para gerar faturas, ou registros específicos do histórico do fluxo de trabalho. Exemplos 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Nome da atividade ActivityName	Nome da atividade de negócio ou do evento ocorrido em um momento específico do ciclo de vida da fatura.
Descrição Este atributo descreve uma etapa ou um marco específico do processo de faturamento, como 'Fatura gerada', 'Fatura aprovada' ou 'Pagamento do cliente recebido'. A sequência dessas atividades forma o fluxo do processo. Analisar as atividades é fundamental para a mineração de processos, pois permite descobrir modelos de processo, identificar variantes e medir a performance entre diferentes etapas. Por que isso importa Este atributo define as etapas do processo e permite visualizar mapas de processo, analisar variantes e identificar gargalos ou desvios do procedimento padrão. Onde encontrar Este atributo costuma ser derivado de várias fontes, como campos de alteração de status (por exemplo, DocumentState), campos de data específicos preenchidos ou registros do histórico de Workflow no Microsoft Dynamics 365. Exemplos Fatura geradaFatura aprovadaPagamento do cliente recebidoNota de crédito emitida
	Data de vencimento do pagamento PaymentDueDate	A data até a qual o cliente deve pagar a fatura.
Descrição A data de vencimento do pagamento é um campo de data essencial, calculado com base na data da fatura e nas condições de pagamento do cliente. Ela serve de referência para medir a pontualidade dos pagamentos. Este atributo é essencial para o Dashboard "Análise de cumprimento das condições de pagamento" e para calcular KPIs como "Taxa de pagamentos em dia" e "Prazo médio de recebimento de vendas". Comparar essa data com a data efetiva do pagamento revela o comportamento de pagamento dos clientes e a eficácia do processo de cobrança. Por que isso importa Esta é a referência para medir a performance dos pagamentos. É essencial para calcular a taxa de pagamentos em dia e analisar o cumprimento das condições de pagamento dos clientes. Onde encontrar Geralmente encontrado na tabela CustInvoiceJour, em um campo como DueDate. Exemplos 2023-05-152023-06-302023-07-01
	Departamento Department	O departamento da empresa associado ao usuário ou à atividade.
Descrição Este atributo associa uma atividade ou um usuário a um departamento específico da organização, como "Contas a receber" ou "Vendas". Ele permite analisar a performance do processo em um nível mais amplo do que o individual. A análise por departamento ajuda a entender as transferências entre áreas, comparar a eficiência das equipes e identificar gargalos em cada departamento, conforme necessário para o Dashboard "Carga de atividades do departamento de faturamento". Por que isso importa Permite analisar a performance em nível organizacional, comparar a eficiência entre equipes e entender como as transferências entre departamentos afetam o processo. Onde encontrar Em geral, este não é um campo direto da transação da fatura. Ele é obtido ao combinar o ID de UserResponsible com o diretório de funcionários ou usuários, que contém as informações do departamento. Exemplos Contas a receberFinançasOperações de faturamento
	Nome do cliente CustomerName	O nome do cliente para quem a fatura foi emitida.
Descrição O nome do cliente é um identificador legível da empresa ou pessoa que está sendo cobrada. Na análise de Process Mining, ele permite segmentar o processo de faturamento por cliente. Assim, você pode identificar quais clientes pagam em dia com frequência, quais costumam atrasar ou se determinados grupos de clientes enfrentam variações ou atrasos específicos no processo. Esse atributo é essencial para Dashboards sobre comportamento de pagamento dos clientes e análise do prazo médio de recebimento de vendas. Por que isso importa Ele permite segmentar a análise do processo por cliente e identificar comportamentos, padrões de pagamento ou problemas específicos de cada cliente. Onde encontrar Esta informação é obtida ao combinar os dados da fatura com os dados mestres de clientes, geralmente na tabela CustTable, usando o número da conta do cliente. Exemplos Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Status da fatura InvoiceStatus	O status atual da fatura no ciclo de vida (por exemplo, em aberto, paga, cancelada).
Descrição Este atributo mostra a situação atual da fatura. Indica se ela ainda aguarda pagamento, se foi paga integralmente, se está vencida ou se foi cancelada por meio de uma nota de crédito. Ele é útil para filtrar casos e analisar apenas faturas em aberto ou confirmar o resultado final de uma fatura encerrada. Também ajuda a entender a carga de trabalho atual e a situação financeira das contas a receber. Por que isso importa Mostra rapidamente a situação atual da fatura, o que ajuda a filtrar casos e entender os resultados de diferentes variantes do processo. Onde encontrar Este status pode ser obtido a partir da situação do pagamento da fatura, verificando, por exemplo, se o saldo no registro CustTrans relacionado é zero. Nem sempre existe um único campo de "status". Exemplos Em abertoPagaVencidaCancelada
	Usuário responsável UserResponsible	O usuário ou funcionário responsável por executar uma atividade específica.
Descrição Este atributo identifica quem realizou uma tarefa específica no processo de faturamento, como aprovar uma fatura ou aplicar um pagamento. É essencial para analisar a carga de trabalho e a performance, além de identificar necessidades de treinamento. Por exemplo, o Dashboard "Carga de atividades do departamento de faturamento" usa este atributo para verificar se o trabalho está bem distribuído ou se alguns usuários estão se tornando gargalos. Ele também ajuda a entender a alocação de recursos e a eficiência. Por que isso importa Ele permite analisar os recursos e identificar gargalos, medir a performance individual ou da equipe e avaliar a distribuição da carga de trabalho no departamento de faturamento. Onde encontrar A informação pode vir dos registros do histórico do fluxo de trabalho (por exemplo, WorkflowTrackingStatusTable) ou de campos de propriedade, como Owner ou ModifiedBy, nas tabelas relevantes. Exemplos John SmithAlicia BakerAdministrador do sistema
	Valor da fatura InvoiceAmount	O valor monetário total da fatura.
Descrição Este atributo representa o valor total devido na fatura. É uma métrica essencial para a análise financeira, pois permite segmentar as faturas por valor. Por exemplo, analistas podem se concentrar nas faturas de alto valor para entender os padrões de pagamento ou identificar se elas levam mais tempo para serem aprovadas. O atributo também é fundamental para calcular o valor total das faturas em aberto e o prazo médio de recebimento de vendas. Por que isso importa Ele permite analisar o impacto financeiro e filtrar e segmentar os processos por valor monetário, priorizando faturas de alto valor e ajudando a entender como elas percorrem o processo. Onde encontrar Encontrado na tabela CustInvoiceJour, geralmente em um campo como InvoiceAmount. Também está disponível em tabelas de transações relacionadas. Exemplos 5430.5012500.00750.25
	Condições de pagamento PaymentTerms	As condições acordadas para o pagamento da fatura (por exemplo, 30 dias, 60 dias).
Descrição As condições de pagamento definem quando o cliente deve pagar uma fatura. Este atributo é usado para calcular a data de vencimento do pagamento e é uma dimensão importante na análise do comportamento de pagamento. O Dashboard "Análise de cumprimento das condições de pagamento" usa este atributo para agrupar clientes e faturas e verificar se determinadas condições de pagamento são mais ou menos eficazes ou estão associadas a mais atrasos. Por que isso importa Ele explica por que uma fatura vence em determinada data e permite segmentar a análise para verificar se algumas condições de pagamento estão relacionadas a atrasos. Onde encontrar Geralmente, esta informação fica no registro mestre do cliente e é copiada para o cabeçalho da fatura. Procure um campo Payment ou PaymTermId na tabela CustInvoiceJour. Exemplos 30 dias60 diasPagamento no recebimento
	Exige intervenção manual RequiresManualIntervention	Indicador que mostra se um pagamento exigiu ajuste manual durante a aplicação do pagamento.
Descrição Este atributo booleano sinaliza os pagamentos que exigiram intervenção ou correção manual durante o processo de aplicação do pagamento. Ele é essencial para o KPI "Taxa de divergências na aplicação de pagamentos", pois ajuda a quantificar a precisão e o nível de automação do registro de pagamentos. Identificar os motivos da intervenção manual, como informações de remessa ausentes ou divergências nos pagamentos, pode levar a melhorias no processo, aumentando a taxa de processamento direto. Por que isso importa Este atributo ajuda a identificar atritos e imprecisões na etapa de aplicação de pagamentos, algo essencial para aumentar a automação e reduzir o trabalho manual. Onde encontrar Esta informação pode ser inferida a partir do usuário que registrou o pagamento, caso não seja um usuário do sistema, ou de códigos de motivo específicos usados durante a conciliação do pagamento. Consulte a documentação do Microsoft Dynamics 365. Exemplos truefalse
	Houve retrabalho IsRework	Indicador que mostra se o processo da fatura envolveu atividades de retrabalho, como várias aprovações.
Descrição Este atributo booleano calculado sinaliza as faturas que passaram por retrabalho. O retrabalho pode ser definido pela ocorrência de vários eventos de "Fatura aprovada" ou por estornos de pagamentos. Este atributo foi criado para dar suporte ao Dashboard "Análise de retrabalho de faturas" e ao KPI "Taxa de retrabalho de faturas". Ao isolar esses casos, analistas podem investigar as causas raiz do retrabalho, que muitas vezes apontam para ineficiências no processo, problemas na qualidade dos dados ou lacunas de treinamento. Por que isso importa Este indicador quantifica diretamente a ineficiência do processo ao identificar casos com ações repetidas ou corretivas, ajudando a encontrar as causas raiz de desperdícios e atrasos. Onde encontrar Este atributo não está disponível no sistema de origem. Ele é calculado na camada de transformação dos dados, verificando atividades repetidas ou padrões específicos de retrabalho em cada caso. Exemplos truefalse
	Moeda Currency	O código da moeda usada no valor da fatura (por exemplo, USD, EUR).
Descrição Este atributo especifica a moeda em que o valor da fatura está expresso. É essencial para organizações multinacionais que trabalham com diferentes moedas. Sem esse contexto, não faz sentido agregar ou comparar valores de faturas. O atributo permite converter moedas corretamente e fazer análises e relatórios financeiros precisos entre diferentes regiões. Por que isso importa Ele fornece o contexto necessário para métricas financeiras como Valor da fatura, evita agregações incorretas e permite análises precisas em ambientes com várias moedas. Onde encontrar Encontrado na tabela CustInvoiceJour, geralmente em um campo como CurrencyCode. Exemplos USDEURGBP
	Número do pedido de venda SalesOrderNumber	O identificador do pedido de venda que deu origem à fatura.
Descrição O número do pedido de venda conecta o processo de faturamento ao processo de vendas anterior. Essa conexão é valiosa para uma análise completa de ponta a ponta do processo de pedido ao recebimento. Ela permite investigar como problemas nas etapas de vendas e atendimento, como alterações no pedido ou atrasos no envio, podem afetar o ciclo de faturamento. Por exemplo, ajuda a responder perguntas como: "As faturas de pedidos de venda complexos demoram mais para serem pagas?" Por que isso importa Este atributo conecta o processo de faturamento ao processo de vendas anterior, permitindo uma análise completa de ponta a ponta do processo de pedido ao recebimento e ajudando a identificar as causas raiz dos problemas de faturamento. Onde encontrar Encontrado no cabeçalho ou nos detalhes das linhas da fatura, com referência ao pedido de venda. Procure um campo como SalesId na tabela CustInvoiceJour. Exemplos SO-009876SO-010234US-SO-00543
	Pagamento em dia IsOnTimePayment	Indicador que mostra se o pagamento do cliente foi recebido até a data de vencimento.
Descrição Este atributo booleano calculado compara o registro de data e hora de "Pagamento do cliente recebido" com a "Data de vencimento do pagamento". Ele indica se cada fatura foi paga em dia ou com atraso. É o componente principal do KPI "Taxa de pagamentos em dia" e é muito usado no Dashboard "Análise de cumprimento das condições de pagamento". O resultado binário facilita a análise e a elaboração de relatórios sobre a performance dos pagamentos. Por que isso importa Mede diretamente se os clientes cumprem as condições de pagamento e serve de base para o KPI de taxa de pagamentos em dia, simplificando a análise da eficácia da cobrança. Onde encontrar Este atributo não existe no sistema de origem. Ele é calculado durante a transformação dos dados, comparando a data do pagamento com PaymentDueDate. Exemplos truefalse
	Prazo médio de recebimento de vendas DaysSalesOutstanding	O número de dias entre a emissão da fatura e o recebimento do pagamento do cliente.
Descrição O prazo médio de recebimento de vendas (DSO) é uma métrica financeira importante que mede, em média, quantos dias uma empresa leva para receber o pagamento após uma venda. Este atributo calculado determina esse prazo para cada fatura. É a principal métrica do Dashboard "Análise de tendências do prazo médio de recebimento de vendas" e do KPI "DSO". Analisar o DSO ajuda a gerenciar o fluxo de caixa e avaliar a eficiência das funções de crédito e cobrança. Por que isso importa Este é um KPI essencial para medir a saúde do fluxo de caixa de uma empresa e a eficiência do processo de cobrança. Ele quantifica a rapidez com que a receita se transforma em caixa. Onde encontrar Este atributo não existe no sistema de origem. Ele é calculado como o intervalo entre a atividade "Fatura emitida" e a atividade "Pagamento do cliente recebido". Exemplos 284592
	Sistema de origem SourceSystem	O sistema de onde os dados foram extraídos.
Descrição Este atributo identifica a origem dos dados do processo. Neste contexto, indica que os dados vêm do Microsoft Dynamics 365. Isso é importante em ambientes com vários sistemas, pois permite diferenciar as fontes de dados e manter clara a linhagem dos dados, facilitando a validação e a solução de problemas. Por que isso importa Ele fornece um contexto essencial sobre a origem dos dados, importante para a governança e a validação dos dados e para combinar dados de vários sistemas corporativos. Onde encontrar Este é um valor estático, adicionado durante a extração e transformação dos dados para identificar a origem do conjunto de dados. Exemplos Microsoft Dynamics 365 FinanceD365 F&O
	Última atualização dos dados LastDataUpdate	Registro de data e hora que indica quando os dados deste evento foram atualizados pela última vez a partir do sistema de origem.
Descrição Este atributo registra quando os dados foram extraídos ou atualizados pela última vez no Microsoft Dynamics 365. É um campo de metadados essencial para entender o nível de atualização dos dados analisados. Assim, analistas e usuários de negócios podem saber se estão consultando as informações mais recentes. Também é fundamental para gerenciar a frequência de atualização dos dados e garantir a confiabilidade da análise. Por que isso importa Ele ajuda os usuários a entenderem a atualidade dos dados, algo essencial para a governança dos dados, o gerenciamento da atualização do Dashboard e a confiança na pontualidade dos insights. Onde encontrar Este atributo é gerado e incluído no conjunto de dados durante o processo de extração, transformação e carregamento (ETL). Exemplos 2023-06-20T05:00:00Z2023-06-21T05:00:00Z

Obrigatório Recomendado Opcional

Atividades de pedido ao recebimento, faturamento e emissão de faturas

Estas são as principais etapas e marcos do processo que você deve registrar no Event Log para descobrir e analisar o processo com precisão.

7 Recomendado 5 Opcional

	Atividade	Descrição
	Data de vencimento do pagamento atingida	Evento calculado que ocorre quando a fatura chega à data de vencimento sem que o pagamento tenha sido totalmente aplicado. Esta atividade não corresponde a uma transação no sistema, mas é derivada dos dados existentes.
Por que isso importa Este evento é essencial para analisar os pagamentos feitos no prazo e identificar faturas que estão ficando vencidas. Ele marca o início das ações de cobrança e envio de notificações. Onde encontrar Este evento não é registrado diretamente. Ele é calculado com base no campo DueDate da tabela CustInvoiceJour. A data e hora do evento correspondem à própria data de vencimento. Coleta Crie um evento cuja data e hora correspondam ao valor do campo CustInvoiceJour.DueDate. Tipo de evento calculated
	Fatura aprovada	Marca a conclusão da revisão interna, quando a fatura é aprovada formalmente. O sistema de Workflow do Dynamics 365 registra esse evento, que indica que a fatura está pronta para ser enviada ao cliente.
Por que isso importa Este é um marco importante para medir o tempo de ciclo da aprovação. Atrasos nesta etapa podem aumentar diretamente o tempo total até o recebimento do pagamento do cliente. Onde encontrar Registrado nas tabelas de histórico do Workflow, como WorkflowTrackingStatusTable, como etapa de conclusão ou aprovação da instância específica do Workflow da fatura. Coleta Extraia os registros de eventos do Workflow em que o status é 'Aprovado' ou 'Concluído'. Tipo de evento explicit
	Fatura encerrada	Esta atividade marca o estado final de uma fatura, quando o saldo chega a zero após o pagamento integral ou a liquidação com notas de crédito. Não é uma transação direta, mas um estado inferido com base na situação financeira da fatura.
Por que isso importa Este evento indica a conclusão bem-sucedida do ciclo de pedido ao recebimento para uma única fatura. O tempo até chegar a esse estado é uma das principais medidas da eficiência geral do processo. Onde encontrar Inferido ao verificar se o saldo restante da transação da fatura na tabela CustTrans é zero. Isso é determinado comparando o valor da fatura com o valor total liquidado. Coleta Derive o evento dos registros de CustTrans em que AmountCur é igual a SettleAmountCur. A data e hora correspondem à data da última liquidação. Tipo de evento inferred
	Fatura enviada ao cliente	Esta atividade representa o momento em que a fatura foi enviada ao cliente, por meio eletrônico ou físico. No Dynamics 365, pode ser um evento explícito quando o envio é feito por e-mail pelo sistema. Se não houver rastreamento específico, pode ser inferido a partir do momento do lançamento.
Por que isso importa Mede a eficiência do processo de envio da fatura. Um atraso entre a aprovação e o envio prolonga desnecessariamente o ciclo de pagamento. Onde encontrar O envio pode ser registrado explicitamente nos logs de e-mail, como SysOutgoingEmailTable, se você usar os recursos de e-mail do D365. Caso contrário, costuma-se considerar o mesmo horário do lançamento da fatura registrado em CustInvoiceJour. Coleta Use a data e hora do log de e-mail, se disponível. Caso contrário, use a data e hora do lançamento da fatura. Tipo de evento inferred
	Fatura gerada	Representa a criação e o lançamento do documento de fatura de venda no sistema. Esta é uma transação explícita no Dynamics 365 que cria um documento legal e lançamentos financeiros no subrazão de contas a receber.
Por que isso importa Este é o início oficial do ciclo de faturamento de uma fatura. É um evento essencial para acompanhar o prazo médio de recebimento de vendas (DSO) e a duração total do processo. Onde encontrar Registrado a partir da data e hora de criação do registro da fatura de venda lançada na tabela CustInvoiceJour. No lançamento, as transações financeiras correspondentes são criadas nas tabelas GeneralJournalEntry e LedgerEntry. Coleta Use o campo CreatedDateTime da tabela CustInvoiceJour para a fatura lançada. Tipo de evento explicit
	Pagamento aplicado à fatura	Representa a liquidação de um pagamento do cliente contra uma fatura específica, reduzindo o saldo em aberto. Esta é uma etapa distinta no Dynamics 365, que vincula a transação do pagamento à transação da fatura.
Por que isso importa Este é um marco essencial para calcular o DSO com precisão e entender a eficiência da equipe responsável pela aplicação dos pagamentos. Ele marca o momento em que o pagamento é totalmente conciliado com o valor faturado. Onde encontrar Registrado na tabela CustSettlement. O campo de data de liquidação dessa tabela fornece a data e hora em que um pagamento específico foi aplicado a uma transação de fatura específica. Coleta Use TransDate ou CreatedDateTime da tabela CustSettlement. Tipo de evento explicit
	Pagamento do cliente recebido	Esta atividade marca a criação de um lançamento contábil para registrar um pagamento recebido de um cliente. Indica que o dinheiro foi recebido, mas ainda não foi aplicado a uma fatura específica.
Por que isso importa Este é o ponto de partida para medir o tempo de aplicação do pagamento. Ele diferencia o recebimento do dinheiro da conciliação efetiva com as faturas em aberto. Onde encontrar Registrado a partir da criação ou do lançamento de um diário de pagamentos de clientes. Isso é registrado em tabelas como LedgerJournalTrans e, após o lançamento, cria uma transação do cliente em CustTrans. Coleta Use a data e hora do lançamento do diário de pagamentos do cliente na LedgerJournalTable. Tipo de evento explicit
	Fatura enviada para aprovação	Esta atividade indica que uma fatura gerada foi enviada para um fluxo formal de aprovação. Isso é comum em empresas que exigem uma revisão da gestão antes do envio da fatura ao cliente. O mecanismo de Workflow do D365 registra essa etapa específica.
Por que isso importa Acompanhar o envio para aprovação ajuda a separar o tempo de criação da fatura do tempo de espera pela aprovação. Esta é a primeira etapa para analisar a eficiência dos processos internos de revisão e controle. Onde encontrar Registrado nas tabelas de histórico do Workflow, como WorkflowTrackingStatusTable, filtrando o evento de envio relacionado ao documento da fatura. Coleta Extraia os registros de eventos do Workflow em que o status é 'Enviado'. Tipo de evento explicit
	Lembrete de pagamento enviado	Representa o envio de uma carta de cobrança ou notificação ao cliente sobre uma fatura vencida. O Dynamics 365 tem um processo formal de cobrança que gera e registra essas comunicações.
Por que isso importa Acompanhar os lembretes ajuda a avaliar a eficácia do processo de cobrança e permite analisar quantos são necessários até o recebimento do pagamento. Onde encontrar Este é um evento explícito, registrado a partir da data de criação do lançamento da carta de cobrança na tabela CustCollectionLetterJour, vinculada à transação da fatura vencida. Coleta Use a data e hora de criação da tabela CustCollectionLetterJour. Tipo de evento explicit
	Nota de crédito emitida	Representa a criação de uma nota de crédito, geralmente para corrigir um erro de faturamento, conceder um ajuste de preço ou registrar a devolução de mercadorias. Na prática, uma nota de crédito equivale a uma fatura negativa.
Por que isso importa A emissão frequente de notas de crédito pode indicar problemas sistêmicos no atendimento de pedidos ou no faturamento. Entender por que elas são emitidas é essencial para melhorar o processo e reduzir a perda de receita. Onde encontrar Esta é uma transação explícita, registrada como uma nova fatura lançada com valor negativo na tabela CustInvoiceJour. Muitas vezes, ela é vinculada à fatura original por um campo de referência. Coleta Identifique os registros da tabela CustInvoiceJour com valor total negativo e vincule-os à fatura original. Tipo de evento explicit
	Pagamento estornado	Esta atividade indica o estorno de um pagamento de cliente lançado anteriormente. Isso pode ocorrer por erros, como lançamento incorreto, falta de fundos ou outras falhas no pagamento.
Por que isso importa Os estornos de pagamento apontam erros operacionais ou problemas nos pagamentos dos clientes. Analisar a frequência desses casos ajuda a identificar as causas raiz e melhorar a precisão do processo de aplicação de pagamentos. Onde encontrar Registrado como estorno de transação no razão geral. Um diário estornado pode ser identificado em GeneralJournalEntry, geralmente por uma sinalização específica ou pela relação com a transação original. Coleta Identifique os lançamentos contábeis com uma sinalização de estorno ou uma referência a uma transação estornada. Tipo de evento explicit
	Pedido de venda atendido	Esta atividade marca o momento em que os produtos foram enviados ou os serviços prestados para um pedido de venda, dando início ao faturamento. No Microsoft Dynamics 365, esse momento costuma ser identificado pelo lançamento de uma guia de remessa ou nota de entrega, que altera o status das linhas do pedido de venda relacionado.
Por que isso importa Este evento marca o início da medição do tempo de ciclo para gerar a fatura. Entender o intervalo entre o atendimento do pedido e o faturamento ajuda a identificar gargalos administrativos que podem afetar o fluxo de caixa. Onde encontrar Identificado pela data de criação do lançamento da guia de remessa vinculada ao pedido de venda. Isso envolve tabelas como CustPackingSlipJour e CustPackingSlipTrans, relacionadas ao pedido de venda que serve de base para a fatura. Coleta Identifique a data mais recente de lançamento da guia de remessa do pedido de venda associado à fatura. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como extrair seus dados do Microsoft Dynamics 365

Etapas

Acesse o espaço de trabalho Data Management: Entre no Microsoft Dynamics 365 Finance and Operations. Use a barra de pesquisa para localizar e abrir o espaço de trabalho Data management. Esse é o local central para todas as operações de importação e exportação de dados.
Crie um novo projeto de exportação: No espaço de trabalho Data management, clique no bloco Export para criar um projeto de exportação de dados. Dê ao projeto um nome descritivo, como ProcessMind_O2C_Billing_Export, e inclua uma descrição.
Selecione o formato de destino dos dados: Na configuração do projeto, especifique Target data format. Para garantir compatibilidade com a maioria das ferramentas de transformação de dados, selecione CSV. Configure as opções de formato conforme necessário, usando um delimitador e um qualificador de texto comuns.
Adicione as entidades de dados necessárias: Esta é a etapa mais importante. Adicione várias entidades de dados padrão ao projeto para capturar todas as atividades necessárias. Para cada entidade, clique em Add entity e pesquise o nome listado na seção Query/Script. Adicione ao projeto estas entidades: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement e Dunning history letters.
Aplique filtros às entidades: Para limitar os dados ao escopo relevante, aplique filtros às entidades. No mínimo, filtre Sales invoice headers V2 pelo campo InvoiceDate, selecionando um período específico, como os últimos 6 meses. Filtre também pelas entidades legais (empresas) que você quer analisar.
Execute a exportação: Depois de adicionar todas as entidades e aplicar os filtros, clique no botão Export no painel de ações. O sistema criará um pacote de trabalho e começará a processar a extração dos dados em segundo plano.
Acompanhe e baixe os dados: Você pode acompanhar o andamento do trabalho na seção Job history. Quando a execução for concluída com sucesso, baixe o pacote de dados exportado. O pacote será um arquivo ZIP com arquivos CSV separados para cada entidade de dados.
Descompacte o pacote: Extraia o conteúdo do arquivo ZIP baixado para uma pasta local. Você terá vários arquivos CSV, um para cada entidade.
Transforme e combine os dados: É necessário transformar os arquivos brutos em um único Event Log. Use uma ferramenta de preparação de dados, como Power Query ou Python, ou uma área de preparação em um banco de dados. Para cada arquivo de origem, crie as colunas necessárias: InvoiceNumber (ID do caso), ActivityName (um valor fixo que representa o evento, como 'Fatura gerada') e EventTime (o campo de data relevante do arquivo de origem). Mapeie outros atributos, como InvoiceAmount e CustomerName.
Una todos os dados transformados: Combine os dados transformados de todos os arquivos de origem em uma única tabela usando uma operação de união ou anexação. Assim, você cria o Event Log final e unificado, em que cada linha representa uma atividade no ciclo de vida da fatura.
Formate o arquivo para carregamento: Verifique se o arquivo CSV final tem os cabeçalhos de coluna corretos (InvoiceNumber, ActivityName, EventTime etc.) e se a coluna EventTime usa um formato consistente de data e hora (por exemplo, AAAA-MM-DD HH:MI:SS). O arquivo estará pronto para ser carregado no ProcessMind.

Configuração

Entidades de dados: A extração usa um conjunto de entidades de dados padrão do D365. Entre as principais estão Sales invoice headers V2 (faturas e notas de crédito), Sales packing slip headers (atendimento de pedidos), CustPaymentJournalLineEntity (pagamentos), Customer settlement (baixa de recebimentos) e Workflow tracking status table (aprovações).
Formato de exportação: O formato de destino recomendado é CSV, por sua ampla compatibilidade com ferramentas de transformação de dados.
Filtro por período: É fundamental aplicar um filtro de período às entidades principais, especialmente a Sales invoice headers V2, usando o campo InvoiceDate. Recomendamos um período de 3 a 6 meses para manter a exportação gerenciável e, ao mesmo tempo, obter dados suficientes para a análise.
Filtro por empresa: A exportação deve ser filtrada pela entidade legal ou pelo código da empresa que você está analisando. Isso garante a relevância dos dados e reduz o tamanho da exportação.
Preparação e transformação dos dados: É necessário fazer um pós-processamento fora do Dynamics 365. Os arquivos exportados precisam ser combinados e reorganizados em um único formato de Event Log. Em geral, isso é feito com ferramentas como Power BI (Power Query), Python ou SQL.
Pré-requisitos: O usuário que executar a exportação precisa ter as funções de segurança adequadas no Dynamics 365, incluindo, normalmente, permissões para o espaço de trabalho Data management e acesso às entidades de dados necessárias.

Consulta de exemplo config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Etapas

Pré-requisitos: Verifique se você tem o Python 3.6 ou posterior instalado, além das bibliotecas requests e pandas. Você também precisará das credenciais de uma entidade de serviço (registro de aplicativo) no Azure Active Directory com acesso ao ambiente do Dynamics 365 Finance & Operations.
Registro do aplicativo: No Azure AD, registre um novo aplicativo. Crie um segredo do cliente e anote o ID do aplicativo (cliente), o ID do diretório (ambiente) e o segredo do cliente. No Dynamics 365, adicione o ID do aplicativo em System administration > Setup > Azure Active Directory applications e atribua as permissões de usuário adequadas para leitura das entidades de dados necessárias.
Configure o script: Abra o script Python fornecido. Preencha as variáveis de configuração no início do script, incluindo d365_url, tenant_id, client_id, client_secret, company, start_date e end_date. O valor de d365_url deve ser a URL base do seu ambiente Dynamics 365, por exemplo, https://your-d365-instance.operations.dynamics.com.
Autenticação: O script contém uma função get_access_token que usa suas credenciais automaticamente para solicitar um token de acesso OAuth2 à plataforma de identidade da Microsoft. Esse token é necessário para autorizar as chamadas de API seguintes.
Extração de dados: Execute o script no terminal com o comando python your_script_name.py. Primeiro, o script buscará todas as faturas de venda lançadas (CustInvoiceJour) dentro do período especificado. Em seguida, fará chamadas adicionais à API para cada fatura e obterá dados relacionados a pagamentos, baixas, notas de crédito e histórico do Workflow.
Geração de atividades: O script processa os dados brutos de vários endpoints da API e gera explicitamente uma linha para cada uma das 12 atividades necessárias. Por exemplo, usa a entidade CustInvoiceJour para o evento 'Fatura gerada' e consulta a entidade CustSettlement para criar eventos de 'Recebimento aplicado à fatura'.
Eventos calculados: Eventos como 'Data de vencimento do pagamento atingida' e 'Fatura encerrada' não correspondem a transações diretas no Dynamics 365. O script os deriva da data de vencimento, do status e do histórico de baixas da fatura e cria os registros correspondentes no Event Log.
Paginação: A função auxiliar fetch_all_data processa a paginação automaticamente. As APIs OData do Dynamics 365 retornam um número limitado de registros por página. Por isso, a função segue o link @odata.nextLink fornecido na resposta da API para recuperar o conjunto de dados completo.
Transformação e saída dos dados: Depois de coletar todos os eventos, o script os reúne em uma única lista, converte a lista em um DataFrame do pandas e padroniza os nomes das colunas para InvoiceNumber, ActivityName, EventTime e outros atributos necessários.
Exportação para CSV: Por fim, o script salva o DataFrame resultante em um arquivo CSV chamado d365_billing_event_log.csv. O arquivo está formatado e pronto para ser carregado no ProcessMind ou em outra ferramenta de Process Mining.

Configuração

URL do D365: A URL base da sua instância do Dynamics 365 Finance & Operations. Esse é o endpoint principal para todas as chamadas de API.
Credenciais do Azure AD: São necessários client_id, client_secret e tenant_id para autenticação. Eles devem pertencer a um aplicativo com acesso de leitura às entidades relevantes do D365.
Empresa: Especifique o DataAreaId, que corresponde à entidade legal do Dynamics 365 da qual você quer extrair dados (por exemplo, 'USMF').
Período: Defina start_date e end_date para limitar o escopo da extração. Para uma análise inicial, recomendamos um período de 3 a 6 meses. Assim, o conjunto de dados fica mais fácil de gerenciar e ainda inclui variações suficientes do processo.
Principais entidades OData: O script consulta principalmente estas entidades: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours e WorkflowTrackingStatusTables. Verifique se o usuário configurado tem permissão de leitura para todas elas.
Performance: A extração de um período longo ou de uma empresa muito grande pode ser lenta, pois envolve várias chamadas sequenciais à API. Recomendamos executar o script fora dos horários de pico e começar com um período menor para estimar o tempo total de execução.

Consulta de exemplo python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
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 = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

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

Pronto para começar?

Comece a otimizar o faturamento e a emissão de faturas usando este Template. Dê ao seu time os insights necessários para aumentar a eficiência e melhorar o fluxo de caixa.

Voltar ao guia de melhoria

Baixar Template

Acabe com os atrasos no faturamento: otimize hoje o processo de pedido ao recebimento e a emissão de faturas

Reduza em 30% o tempo do ciclo de faturamento e tenha mais clareza financeira em menos tempo.

Começar o teste grátis

Não é necessário informar cartão de crédito. Teste grátis por 14 dias.

Seu Template de dados de pedido ao recebimento, faturamento e emissão de faturas

Seu Template de dados de pedido ao recebimento, faturamento e emissão de faturas

Atributos de pedido ao recebimento, faturamento e emissão de faturas

Atividades de pedido ao recebimento, faturamento e emissão de faturas

Guias de extração

Exportação de entidades de dados do Microsoft Dynamics 365

Etapas

Configuração

Consulta de exemplo config

Script Python usando a API Web OData do Dynamics 365

Etapas

Configuração

Consulta de exemplo python

Pronto para começar?

Acabe com os atrasos no faturamento: otimize hoje o processo de pedido ao recebimento e a emissão de faturas