> Melhoria contínua de processos > Do pedido ao recebimento: faturamento e emissão de notas fiscais > Microsoft Dynamics 365 > Template de dados

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Microsoft Dynamics 365

← Voltar ao guia de melhoria

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

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Este Template oferece um roteiro claro para coletar os dados essenciais necessários à análise do seu processo de Order to Cash - Faturamento e emissão de faturas. Você encontrará os atributos recomendados para incluir no seu Event Log, as principais atividades a acompanhar e orientações práticas para extrair essas informações. Ele foi desenvolvido para ajudar você a preparar rapidamente seus dados para obter insights de Process Mining.

Atributos recomendados para coleta
Principais atividades a acompanhar
Orientações para extração no Microsoft Dynamics 365

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

Baixar Template

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise abrangente do faturamento e da emissão de notas fiscais, do pedido ao recebimento.

3 Obrigatório 6 Recomendado 9 Opcional

	Nome	Descrição
	Número da fatura InvoiceNumber	O identificador exclusivo de cada fatura do cliente, usado como principal identificador do caso no processo de faturamento.
Descrição O Invoice Number é a chave central que agrupa todas as atividades relacionadas a um único documento de faturamento. Ele permite uma análise completa, de ponta a ponta, do ciclo de vida da fatura, desde a geração e aprovação até o pagamento do cliente e o encerramento final. Ao usar esse valor como Case ID, cada entrada do Event Log corresponde a uma fatura específica, permitindo uma análise detalhada de variantes, o cálculo do tempo de ciclo e o monitoramento da performance de cada transação de faturamento. Por que isso importa Este atributo é essencial para acompanhar todo o ciclo de vida de uma fatura, permitindo analisar a eficiência do processo, os gargalos e os desvios de cada documento de faturamento. Onde obter Normalmente, ele é encontrado no módulo Sales and marketing, em tabelas como CustInvoiceJour, no campo InvoiceId, ou exposto por entidades de dados como SalesInvoiceHeaderV2. Exemplos CIV-001254INV-2023-9876US-004321
	Horário do evento EventTime	O timestamp preciso que indica quando uma atividade ou evento específico ocorreu.
Descrição Event Time, também conhecido como timestamp, registra a data e o horário exatos de cada atividade do processo. Esses dados são essenciais para todas as análises de process mining baseadas em tempo. Eles são usados 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. Timestamps precisos e confiáveis são a base de KPIs como Days Sales Outstanding e Invoice Generation Time. Por que isso importa Este é o atributo fundamental para todas as análises relacionadas a performance e tempo, permitindo calcular tempos de ciclo, durações e throughput para medir a eficiência do processo. Onde obter Os timestamps são obtidos de vários campos de data e hora em diferentes tabelas do Dynamics 365, como CreatedDateTime na tabela CustInvoiceJour para a geração da fatura ou timestamps específicos do histórico de Workflow. Exemplos 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Nome da atividade ActivityName	O nome da atividade ou do evento de negócio que ocorreu em um ponto 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 'Invoice Generated', 'Invoice Approved' ou 'Customer Payment Received'. A sequência dessas atividades forma o fluxo do processo. Analisar as atividades é fundamental para o process mining, pois permite descobrir modelos de processo, identificar variantes e medir a performance entre diferentes etapas. Por que isso importa Ele define as etapas do processo, permitindo visualizar mapas de processo, analisar variantes e identificar gargalos ou desvios em relação ao procedimento padrão. Onde obter Este atributo normalmente é 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 Payment Due Date é um campo de data essencial, calculado com base na data da fatura e nas condições de pagamento do cliente. Ela serve como referência para medir a pontualidade dos pagamentos. Esse atributo é fundamental para o Dashboard 'Payment Terms Adherence Analysis' e para calcular KPIs como 'On-Time Payment Rate' e 'Days Sales Outstanding'. Comparar essa data com a data real do pagamento revela o comportamento de pagamento dos clientes e a eficácia do processo de cobrança. Por que isso importa Essa é a referência para medir a performance dos pagamentos. Ela é essencial para calcular as taxas de pagamento em dia e analisar a aderência às condições de pagamento dos clientes. Onde obter Normalmente, esse dado está 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 Esse atributo associa uma atividade ou um usuário a um departamento organizacional específico, como 'Contas a Receber' ou 'Vendas'. Ele permite ter uma visão mais ampla da performance do processo do que a análise no nível de cada usuário. A análise por departamento ajuda a entender as transferências entre áreas, comparar a eficiência entre times e identificar gargalos no nível departamental, conforme necessário para o Dashboard 'Billing Department Activity Load'. Por que isso importa Permite analisar a performance no nível organizacional, comparar a eficiência entre diferentes times e entender como as transferências entre departamentos afetam o processo. Onde obter Normalmente, esse não é um campo direto da transação da fatura. Ele é obtido unindo o ID de UserResponsible ao 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 fornece um identificador legível para a empresa ou pessoa que está sendo faturada. Na análise de Process Mining, isso permite segmentar o processo de faturamento por cliente. Assim, você pode descobrir quais clientes pagam sempre em dia, quais atrasam com frequência ou se determinados grupos de clientes enfrentam variações ou atrasos específicos no processo. Esse dado é essencial para Dashboards relacionados ao comportamento de pagamento dos clientes e à análise de Days Sales Outstanding. Por que isso importa Isso permite segmentar a análise do processo por cliente, ajudando a identificar comportamentos específicos, padrões de pagamento ou problemas no processo relacionados a cada cliente. Onde obter Essas informações são obtidas unindo os dados das faturas à tabela de dados mestres de clientes, normalmente a CustTable, com base no número da conta do cliente. Exemplos Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Status da fatura InvoiceStatus	O status atual da fatura em seu ciclo de vida, como Open, Paid ou Canceled.
Descrição Esse atributo mostra a situação atual da fatura. Ele indica se a fatura ainda está aguardando pagamento, foi totalmente paga, está vencida ou foi cancelada por meio de uma nota de crédito. Isso é útil para filtrar casos e analisar apenas faturas em aberto ou confirmar o resultado final de uma fatura encerrada. Ele ajuda a entender a carga de trabalho atual e a situação financeira dos recebíveis. Por que isso importa Fornece uma visão rápida do estado atual da fatura, sendo útil para filtrar casos e entender os resultados de diferentes variantes do processo. Onde obter Esse dado pode ser obtido a partir do status de pagamento da fatura, geralmente verificando se o saldo no registro CustTrans relacionado é zero. Nem sempre existe um único campo de 'status'. Exemplos Em abertoPagoEm atrasoCancelado
	Usuário responsável UserResponsible	O usuário ou funcionário responsável por executar uma atividade específica.
Descrição Esse atributo identifica a pessoa que executou uma determinada tarefa no processo de faturamento, como aprovar uma fatura ou aplicar um pagamento. Ele é essencial para analisar a carga de trabalho, comparar a performance e identificar necessidades de treinamento. Por exemplo, o Dashboard 'Billing Department Activity Load' usa esse atributo para verificar se o trabalho está sendo distribuído de forma equilibrada ou se determinados 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, ajudando a identificar gargalos, medir a performance individual ou do time e analisar a distribuição da carga de trabalho no departamento de faturamento. Onde obter Esses dados podem vir dos logs do histórico do Workflow, como a 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, permitindo segmentar as faturas por valor. Por exemplo, os analistas podem se concentrar em faturas de alto valor para entender seu comportamento de pagamento ou identificar se faturas maiores enfrentam tempos de aprovação mais longos. Ele também é fundamental para calcular o valor total das faturas em aberto e o DSO. Por que isso importa Ele permite analisar o impacto financeiro, filtrando e segmentando os processos por valor monetário para priorizar faturas de alto valor e entender seus comportamentos específicos no processo. Onde obter Encontrado na tabela CustInvoiceJour, normalmente 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, como Net 30 ou Net 60.
Descrição As Payment Terms definem as regras para determinar quando o cliente deve pagar uma fatura. Esse atributo é usado para calcular a Payment Due Date e é uma dimensão importante na análise do comportamento de pagamento. O Dashboard 'Payment Terms Adherence Analysis' usa esse 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 taxas maiores de atraso. Por que isso importa Ele explica por que uma fatura vence em determinada data e permite segmentar a análise para verificar se certas condições de pagamento estão relacionadas a atrasos. Onde obter Normalmente, esse dado é armazenado no registro mestre do cliente, mas é copiado para o cabeçalho da fatura. Procure um campo como Payment ou PaymTermId na tabela CustInvoiceJour. Exemplos Líquido em 30 diasLíquido em 60 diasVencimento na entrega
	É pagamento em dia IsOnTimePayment	Um indicador que mostra se o pagamento do cliente foi recebido na data de vencimento ou antes dela.
Descrição Esse atributo booleano calculado compara o timestamp de 'Customer Payment Received' com a 'Payment Due Date'. Ele classifica cada fatura como paga em dia ou atrasada. Esse é o componente principal para calcular o KPI 'On-Time Payment Rate' e é amplamente usado no Dashboard 'Payment Terms Adherence Analysis'. Ele fornece um resultado binário claro sobre a performance do pagamento, simplificando a análise e os relatórios. Por que isso importa Mede diretamente a aderência do cliente às condições de pagamento e serve de base para o KPI On-Time Payment Rate, simplificando a análise da eficácia da cobrança. Onde obter Esse atributo não está no sistema de origem. Ele é calculado durante a transformação dos dados, comparando a data do pagamento com a PaymentDueDate. Exemplos truefalse
	É retrabalho IsRework	Um indicador que mostra se o processo da fatura envolveu atividades de retrabalho, como várias aprovações.
Descrição Esse é um atributo booleano calculado que sinaliza as faturas que passaram por retrabalho. O retrabalho pode ser definido pela ocorrência de vários eventos 'Invoice Approved' ou por estornos de pagamentos. Esse atributo foi criado especificamente para apoiar o Dashboard 'Invoice Rework Analysis' e o KPI 'Invoice Rework Rate'. Ao isolar esses casos, você pode investigar as causas-raiz do retrabalho, que geralmente apontam para ineficiências no processo, problemas de qualidade dos dados ou lacunas de treinamento. Por que isso importa Esse indicador quantifica diretamente a ineficiência do processo ao identificar casos com ações repetitivas ou corretivas, ajudando a localizar as causas-raiz de desperdícios e atrasos. Onde obter Esse atributo não está disponível no sistema de origem. Ele é calculado na camada de transformação de dados, verificando atividades repetidas ou padrões específicos de retrabalho dentro de um caso. Exemplos truefalse
	Moeda Currency	O código da moeda do valor da fatura, por exemplo, USD ou EUR.
Descrição Este atributo especifica a moeda na qual o valor da fatura é denominado. É essencial para organizações multinacionais que trabalham com diferentes moedas. Sem esse contexto, agregar ou comparar valores de faturas não teria significado. Ele permite fazer a conversão correta de moedas e gerar relatórios e análises financeiras precisos em diferentes regiões. Por que isso importa Ele fornece o contexto essencial para métricas financeiras como Invoice Amount, evitando agregações incorretas e permitindo análises precisas em ambientes com várias moedas. Onde obter Encontrado na tabela CustInvoiceJour, normalmente em um campo como CurrencyCode. Exemplos USDEURGBP
	Número do pedido de venda SalesOrderNumber	O identificador do pedido de venda que originou a fatura.
Descrição O Sales Order Number conecta o processo de faturamento ao processo de vendas anterior. Essa conexão é muito valiosa para uma análise mais ampla e de ponta a ponta de Order-to-Cash. Ela permite investigar como problemas no processo 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 ser pagas?'. Por que isso importa Esse atributo conecta o processo de faturamento ao processo de vendas anterior, permitindo uma análise mais completa e de ponta a ponta de Order-to-Cash para identificar as causas-raiz dos problemas de faturamento. Onde obter É encontrado no cabeçalho da fatura ou nos detalhes das linhas, fazendo a ligação com o pedido de venda. Procure um campo como SalesId na tabela CustInvoiceJour. Exemplos SO-009876SO-010234US-SO-00543
	Prazo médio de recebimento de vendas DaysSalesOutstanding	O número de dias entre a geração da fatura e o recebimento do pagamento do cliente.
Descrição Days Sales Outstanding (DSO) é uma métrica financeira importante que mede o número médio de dias que uma empresa leva para receber o pagamento depois de realizar uma venda. Esse atributo calculado determina essa duração para cada fatura. Ele é a principal métrica do Dashboard 'Days Sales Outstanding Trend Analysis' 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 Esse é 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 velocidade com que a receita é convertida em caixa. Onde obter Esse atributo não está no sistema de origem. Ele é calculado como a duração entre a atividade 'Invoice Generated' e a atividade 'Customer Payment Received'. Exemplos 284592
	Requer intervenção manual RequiresManualIntervention	Um indicador que mostra se um pagamento exigiu ajuste manual durante a aplicação do pagamento.
Descrição Esse 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 'Cash Application Discrepancy Rate', pois ajuda a quantificar a precisão e o nível de automação do registro dos pagamentos. Identificar os motivos da intervenção manual, como informações de remessa ausentes ou divergências no pagamento, pode gerar melhorias no processo, aumentar as taxas de processamento direto e reduzir o trabalho manual. Por que isso importa Esse atributo ajuda a identificar atritos e imprecisões na etapa de aplicação do pagamento, algo essencial para melhorar a automação e reduzir o esforço manual. Onde obter Essas informações podem ser inferidas 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 reconciliação do pagamento. Consulte a documentação do Microsoft Dynamics 365. Exemplos truefalse
	Sistema de origem SourceSystem	O sistema do qual os dados foram extraídos.
Descrição Este atributo identifica a origem dos dados do processo. Neste contexto, ele especifica que os dados vêm do Microsoft Dynamics 365. Isso é importante em ambientes com vários sistemas para diferenciar as fontes de dados e garantir uma linhagem de dados clara, o que ajuda na validação e na solução de problemas. Por que isso importa Ele fornece um contexto essencial sobre a origem dos dados, fundamental para a governança e a validação dos dados e para combinar dados de vários sistemas corporativos. Onde obter Este é um valor estático adicionado durante o processo de 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	O timestamp que indica a última vez em que os dados desse evento foram atualizados 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 a atualidade dos dados analisados. Ele ajuda analistas e usuários de negócio a saber se estão consultando as informações mais recentes e é fundamental para gerenciar agendas de atualização e garantir a confiabilidade da análise. Por que isso importa Ele garante que os usuários entendam a atualidade dos dados, algo essencial para a governança de dados, o gerenciamento da atualização de Dashboards e a confiança na pontualidade dos insights. Onde obter Este atributo é gerado e gravado 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 faturamento e emissão de notas fiscais, do pedido ao recebimento

Estas são as principais etapas e os marcos do processo que devem ser registrados no seu Event Log para uma descoberta e análise precisas do processo.

7 Recomendado 5 Opcional

	Atividade	Descrição
	Data de vencimento do pagamento atingida	Um evento calculado que ocorre quando a data de vencimento da fatura é atingida sem que um pagamento tenha sido totalmente aplicado. Essa atividade não corresponde a uma transação no sistema, mas é derivada dos dados existentes.
Por que isso importa Este evento é essencial para analisar as taxas de pagamento em dia e identificar faturas que estão ficando vencidas. Ele funciona como ponto de acionamento para atividades de cobrança e envio de lembretes. Onde obter Não é registrado como um evento. Ele é calculado usando o campo DueDate da tabela CustInvoiceJour. O timestamp do evento é a própria data de vencimento. Captura Crie um evento cujo timestamp seja o valor do campo CustInvoiceJour.DueDate. Tipo de evento calculated
	Fatura aprovada	Marca a conclusão do processo de revisão interna, quando a fatura é formalmente aprovada. Esse evento é registrado pelo sistema de Workflow do Dynamics 365 e indica que a fatura está pronta para ser enviada ao cliente.
Por que isso importa Este é um marco importante para medir o tempo do ciclo de aprovação. Atrasos nessa etapa podem aumentar diretamente o tempo total para receber o pagamento do cliente. Onde obter Registrado nas tabelas de histórico do Workflow, como WorkflowTrackingStatusTable, como uma etapa de conclusão ou aprovação da instância específica do Workflow da fatura. Captura Extraia os Event Logs do Workflow cujo status seja 'Approved' ou 'Completed'. Tipo de evento explicit
	Fatura encerrada	Esta atividade marca o estado final de uma fatura, quando seu saldo é zero porque foi totalmente paga ou liquidada com notas de crédito. Não se trata de uma transação direta, mas de um estado inferido com base no status financeiro da fatura.
Por que isso importa Este evento indica a conclusão bem-sucedida do ciclo Order to Cash de uma única fatura. O tempo necessário para chegar a esse estado é uma medida principal da eficiência geral do processo. Onde obter Inferido ao verificar se a transação da fatura na tabela CustTrans tem saldo restante igual a zero. Isso é determinado comparando o valor da fatura com o valor total liquidado contra ela. Captura Derive dos registros CustTrans em que AmountCur é igual a SettleAmountCur. O timestamp é a data da última liquidação. Tipo de evento inferred
	Fatura enviada ao cliente	Esta atividade representa o momento em que a fatura foi transmitida ao cliente, por meio eletrônico ou físico. No Dynamics 365, pode ser um evento explícito quando o envio ocorre pelo e-mail do sistema ou pode ser inferido como o momento do lançamento, caso nenhum rastreamento específico esteja habilitado.
Por que isso importa Mede a eficiência do processo de entrega da fatura. Um atraso entre a aprovação e o envio prolonga desnecessariamente o ciclo de pagamento. Onde obter Pode ser capturado explicitamente nos registros de e-mail, como SysOutgoingEmailTable, quando os recursos de e-mail do D365 são usados. Caso contrário, geralmente é inferido como igual ao horário de lançamento da fatura na CustInvoiceJour. Captura Use o timestamp do registro de e-mail, se disponível; caso contrário, use o timestamp de 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. Trata-se de uma transação explícita no Dynamics 365 que cria um documento legal e lançamentos financeiros no razão auxiliar 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 Days Sales Outstanding (DSO) e a duração geral do processo. Onde obter Capturado a partir do timestamp de criação do registro da fatura de venda lançada na tabela CustInvoiceJour. As transações financeiras correspondentes são criadas nas tabelas GeneralJournalEntry e LedgerEntry durante o lançamento. Captura 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 da fatura. Esta é uma etapa distinta no Dynamics 365 que vincula a transação de 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 de aplicação de pagamentos. Ele marca o momento em que o pagamento é totalmente conciliado com o valor faturado. Onde obter Registrado na tabela CustSettlement. O campo de data de liquidação dessa tabela fornece o timestamp de quando um pagamento específico foi aplicado a uma transação de fatura específica. Captura 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 de diário para registrar um pagamento recebido de um cliente. Isso significa 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 lead time de aplicação do pagamento. Ele diferencia o recebimento do dinheiro da conciliação efetiva com as faturas em aberto. Onde obter Capturado a partir da criação ou do lançamento de um diário de pagamento do cliente. Isso é registrado em tabelas como LedgerJournalTrans, que depois cria uma transação do cliente em CustTrans durante o lançamento. Captura Use o timestamp de lançamento do diário de pagamento do cliente em LedgerJournalTable. Tipo de evento explicit
	Fatura enviada para aprovação	Esta atividade indica que uma fatura gerada foi enviada para um Workflow formal de aprovação. Isso é comum em organizações com controles que exigem uma revisão gerencial antes do envio da fatura ao cliente. Essa etapa é registrada como um passo específico no mecanismo de Workflow do D365.
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. É o primeiro passo para analisar a eficiência dos processos internos de revisão e controle. Onde obter Capturado nas tabelas de histórico do Workflow, como WorkflowTrackingStatusTable, filtrando o evento de envio relacionado ao documento da fatura. Captura Extraia os Event Logs do Workflow cujo status seja 'Submitted'. Tipo de evento explicit
	Lembrete de pagamento enviado	Representa o envio de uma carta de cobrança ou aviso de cobrança 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. Isso permite analisar quantos lembretes são necessários antes que um pagamento seja recebido. Onde obter Este é um evento explícito capturado a partir da data de criação do diário de carta de cobrança na tabela CustCollectionLetterJour, vinculada à transação da fatura vencida. Captura Use o timestamp 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 ou crédito, normalmente para corrigir um erro de faturamento, conceder um ajuste de preço ou contabilizar produtos devolvidos. Uma nota de crédito é, essencialmente, uma fatura negativa.
Por que isso importa Notas de crédito frequentes podem indicar problemas sistêmicos no processo de atendimento de pedidos ou faturamento. Analisar por que as notas de crédito são emitidas é essencial para melhorar o processo e reduzir perdas de receita. Onde obter Esta é uma transação explícita, registrada como uma nova fatura lançada com valor negativo na tabela CustInvoiceJour. Ela geralmente é vinculada à fatura original por meio de um campo de referência. Captura Identifique os registros em 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 ocorre devido a erros, como lançamento incorreto, fundos insuficientes ou outras falhas de pagamento.
Por que isso importa Estornos de pagamentos destacam erros operacionais ou problemas nos pagamentos dos clientes. Analisar sua frequência ajuda a identificar causas-raiz e melhorar a precisão do processo de aplicação de pagamentos. Onde obter Capturado como um estorno de transação no razão geral. Um diário estornado pode ser identificado em GeneralJournalEntry, geralmente por meio de um indicador específico ou de sua relação com a transação original. Captura Identifique lançamentos de diário com um indicador 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 foram prestados para um pedido de venda, acionando o processo de faturamento. Normalmente, ela é inferida a partir do lançamento de um packing slip ou documento de entrega no Microsoft Dynamics 365, que altera o status das linhas relacionadas do pedido de venda.
Por que isso importa Esse evento serve como ponto de partida para medir o tempo do ciclo de geração da fatura. Entender o atraso entre o atendimento do pedido e o faturamento ajuda a identificar gargalos administrativos que podem afetar o fluxo de caixa. Onde obter Inferido a partir da data de criação de um lançamento de diário de packing slip vinculado ao pedido de venda. Isso envolve tabelas como CustPackingSlipJour e CustPackingSlipTrans, relacionadas ao pedido de venda no qual a fatura se baseia. Captura Identifique a data mais recente de lançamento do packing slip para o pedido de venda associado à fatura. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como obter seus dados do Microsoft Dynamics 365

Etapas

Acesse o Workspace de gerenciamento de dados: Faça login no Microsoft Dynamics 365 Finance and Operations. Use a barra de pesquisa para localizar e acessar o Workspace Data management. Esse é o hub central para todas as operações de importação e exportação de dados.
Crie um novo projeto de exportação: No Workspace Data management, clique no bloco Export para criar um novo projeto de exportação de dados. Dê ao projeto um nome significativo, como ProcessMind_O2C_Billing_Export, e inclua uma descrição.
Selecione o formato de dados de destino: Na configuração do projeto, especifique o 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. Você adicionará 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 as seguintes 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 a um escopo relevante, aplique filtros às entidades. No mínimo, filtre Sales invoice headers V2 por InvoiceDate para um período específico, como os últimos 6 meses. Filtre também pelas entidades legais específicas, ou empresas, que você deseja analisar.
Execute o job de 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 job e começará a processar a extração dos dados em segundo plano.
Monitore e baixe os dados: Você pode acompanhar o progresso do job na seção Job history. Quando o job for concluído com sucesso, baixe o pacote de dados exportado. O pacote será um arquivo ZIP contendo arquivos CSV separados para cada entidade de dados.
Descompacte o pacote: Extraia o conteúdo do arquivo ZIP baixado para uma pasta local. Agora você terá vários arquivos CSV, um para cada entidade.
Transforme e combine os dados: Os arquivos brutos precisam ser transformados em um único Event Log. Use uma ferramenta de preparação de dados, como Power Query, Python ou uma área de staging de banco de dados. Para cada arquivo de origem, crie as colunas necessárias: InvoiceNumber (Case ID), ActivityName (um valor fixo que representa o evento, como 'Invoice Generated') 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. Isso cria o Event Log final e unificado, em que cada linha representa uma atividade no ciclo de vida da fatura.
Formate o arquivo para upload: Verifique se o arquivo CSV final tem os cabeçalhos corretos (InvoiceNumber, ActivityName, EventTime etc.) e se a coluna EventTime está em um formato de timestamp consistente, como YYYY-MM-DD HH:MI:SS. O arquivo estará pronto para upload no ProcessMind.

Configuração

Entidades de dados: A extração depende de um conjunto de entidades de dados padrão do D365. As principais incluem Sales invoice headers V2 (para faturas e notas de crédito), Sales packing slip headers (para atendimento dos pedidos), CustPaymentJournalLineEntity (para pagamentos), Customer settlement (para aplicação de pagamentos) e Workflow tracking status table (para aprovações).
Formato de exportação: O formato de dados de destino recomendado é CSV, devido à ampla compatibilidade com ferramentas de transformação de dados.
Filtro por período: É essencial aplicar um filtro de período às entidades principais, especialmente a Sales invoice headers V2, no campo InvoiceDate. Recomenda-se um período de 3 a 6 meses para manter a exportação gerenciável e, ao mesmo tempo, fornecer 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, garantindo a relevância dos dados e reduzindo o tamanho da exportação.
Staging e transformação dos dados: É necessária uma etapa de pós-processamento fora do Dynamics 365. Os arquivos exportados precisam ser combinados e reorganizados em um único formato de Event Log. Normalmente, isso envolve 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 atribuídas no Dynamics 365, normalmente incluindo uma função com permissões para o Workspace Data management e acesso às entidades de dados necessárias.

a 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: confirme que o Python 3.6 ou superior está instalado, com as bibliotecas requests e pandas. Você também precisará das credenciais de uma entidade de serviço, ou App Registration, no Azure Active Directory, com acesso concedido 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, ou client ID, o ID do diretório, ou tenant ID, e o segredo do cliente. No Dynamics 365, adicione o ID do aplicativo em System administration > Setup > Azure Active Directory applications e atribua os direitos de usuário adequados para ler as 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 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 automaticamente suas credenciais 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 dos dados: execute o script no terminal usando python your_script_name.py. O script começará buscando todas as faturas de venda registradas (CustInvoiceJour) dentro do período especificado. Para cada fatura, ele fará chamadas de API adicionais para recuperar dados relacionados a atividades como pagamentos, liquidações, notas de crédito e histórico do Workflow.
Geração das atividades: o script processa os dados brutos de vários endpoints de API. Ele gera explicitamente uma linha para cada uma das 12 atividades necessárias. Por exemplo, usa a entidade CustInvoiceJour para o evento 'Invoice Generated' e consulta a entidade CustSettlement para criar eventos 'Cash Applied to Invoice'.
Eventos calculados: observe que eventos como 'Payment Due Date Reached' e 'Invoice Closed' não são transações diretas no Dynamics 365. O script deriva esses eventos com base na data de vencimento, no status e no histórico de liquidações da fatura, criando as entradas correspondentes no Event Log.
Tratamento da paginação: a função auxiliar fetch_all_data foi desenvolvida para tratar a paginação automaticamente. As APIs OData do Dynamics 365 retornam um número limitado de registros por página. Por isso, essa função segue o @odata.nextLink fornecido na resposta da API para recuperar o conjunto completo de dados.
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. Esse arquivo é formatado e está pronto para upload 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 um client_id, um client_secret e um tenant_id para a 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 no Dynamics 365 da qual você quer extrair dados, por exemplo, 'USMF'.
Período: defina uma start_date e uma end_date para limitar o escopo da extração. Para uma análise inicial, recomenda-se um período de 3 a 6 meses, garantindo um volume de dados gerenciável e capturando variações suficientes do processo.
Principais entidades OData: o script consulta principalmente as seguintes entidades: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours e WorkflowTrackingStatusTables. Verifique se o usuário configurado tem permissão para ler todas essas entidades.
Performance: extrair dados de um período longo ou de uma empresa muito grande pode ser demorado devido à realização de várias chamadas de API sequenciais. Recomenda-se 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.

a 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 sua jornada rumo a um faturamento e uma emissão de faturas mais eficientes 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 Order to Cash e a emissão de faturas hoje

Reduza o tempo do ciclo de faturamento em 30% e alcance clareza financeira mais rapidamente.

Começar o teste grátis

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

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento

Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento

Guias de extração

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

Etapas

Configuração

a Consulta de exemplo config

Script Python usando a API Web OData do Dynamics 365

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Acabe com os atrasos no faturamento: otimize Order to Cash e a emissão de faturas hoje

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Seu Template de dados de Order to Cash - Faturamento e emissão de faturas

Atributos de faturamento e emissão de notas fiscais, do pedido ao recebimento

Atividades de faturamento e emissão de notas fiscais, do pedido ao recebimento

Guias de extração

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

Etapas

Configuração

a Consulta de exemplo config

Script Python usando a API Web OData do Dynamics 365

Etapas

Configuração

a Consulta de exemplo python

Pronto para começar?

Acabe com os atrasos no faturamento: otimize Order to Cash e a emissão de faturas hoje

Valorizamos sua privacidade