> Melhoria contínua de processos > Gestão de crédito e cobrança > Microsoft Dynamics 365 > Template de dados

Seu Template de dados de gestão de crédito e cobranças

Microsoft Dynamics 365

Atributos de gestão de crédito e cobranças(19) Atividades de gestão de crédito e cobranças(12) Guias de extração(2)

Seu Template de dados de gestão de crédito e cobranças

Este Template orienta você na coleta dos dados necessários para analisar o processo de gestão de crédito e cobranças. Ele apresenta os atributos de dados essenciais, as principais atividades a acompanhar e orientações práticas para extrair os dados. Use este material para simplificar a preparação dos dados e acelerar sua jornada de Process Mining.

Atributos recomendados para uma análise completa
Principais atividades do processo a acompanhar para uma descoberta precisa
Orientações práticas para extrair dados do seu sistema

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

Baixar Template

Atributos de gestão de crédito e cobranças

Estes são os campos de dados recomendados para incluir no Event Log e analisar de forma completa o processo de gestão de crédito e cobranças.

3 Obrigatório 8 Recomendado 8 Opcional

	Nome	Descrição
	Horário do evento EventTime	Data e hora que indicam quando uma atividade ou um evento específico ocorreu.
Descrição O horário do evento é a data e a hora exatas em que uma atividade foi registrada no sistema. É essencial para o Process Mining, pois fornece a ordem cronológica necessária para montar o fluxo do processo e calcular todas as métricas baseadas em tempo. Esse atributo é indispensável para analisar durações, identificar gargalos e monitorar SLAs. Por exemplo, a diferença entre os eventos 'Fatura gerada' e 'Pagamento recebido' é usada para calcular o prazo médio de recebimento de vendas (DSO), um KPI importante para o negócio. Sem datas e horários precisos, não é possível analisar a performance nem identificar gargalos. Por que isso importa Essas datas e horários são essenciais para ordenar os eventos, descobrir o mapa do processo e calcular métricas de performance, como tempos de ciclo e durações. Onde encontrar Esse atributo vem de vários campos de data e hora nas tabelas do D365, como 'CreatedDateTime' em 'CustInvoiceJour' ou 'TransDate' em 'CustTrans', dependendo da atividade. Exemplos 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Nome da atividade ActivityName	Nome do evento ou da tarefa específica que ocorreu em determinado momento do ciclo de vida da fatura.
Descrição O nome da atividade descreve uma etapa ou um evento específico do processo de crédito e cobrança, como 'Fatura gerada', 'Carta de cobrança enviada' ou 'Pagamento recebido'. Esse atributo é fundamental para o Process Mining, pois define os nós do mapa do processo. Analisar a sequência e a frequência dessas atividades revela o fluxo real do processo e ajuda a identificar ciclos de retrabalho, ineficiências e caminhos que não estão em conformidade. Ele dá suporte direto à criação de todas as visualizações do fluxo do processo e é usado para segmentar os cálculos do tempo de ciclo entre diferentes etapas. Por que isso importa Este atributo define as etapas do mapa do processo e permite visualizar e analisar o ciclo de vida da fatura. Onde encontrar Esse atributo geralmente é obtido pelo mapeamento de eventos específicos do sistema, alterações de status ou datas de criação de registros em várias tabelas, como 'CustInvoiceJour', 'CustTrans', 'CustCollectionLetterJour' e 'CustPaymPromise', para nomes de atividades padronizados. Exemplos Fatura contabilizada e enviadaCarta de cobrança geradaControvérsia registradaPagamento recebido
	Número da fatura InvoiceNumber	Identificador exclusivo de cada fatura de cliente, usado como identificador principal do caso no processo de gestão de crédito.
Descrição O número da fatura é um atributo essencial que identifica exclusivamente cada transação financeira com um cliente. Ele conecta todas as atividades relacionadas, da geração e do lançamento da fatura à cobrança do pagamento e à liquidação final. No Process Mining, esse número é usado para reconstruir a jornada completa de cada fatura e analisar seu ciclo de vida em detalhes. Ao acompanhar cada fatura como um caso separado, as organizações podem identificar caminhos recorrentes, gargalos e desvios do procedimento padrão. Esse atributo é a base para calcular métricas importantes, como o prazo médio de recebimento de vendas, e analisar variantes do processo. Por que isso importa Este é o ID do caso essencial que conecta todos os eventos do processo e permite reconstruir e analisar todo o ciclo da emissão da fatura ao recebimento. Onde encontrar Geralmente, é o campo 'Invoice' da tabela 'CustInvoiceJour' no Microsoft Dynamics 365 Finance. Exemplos INV-0012345CIV-2023-8876SI-9510034
	Data de vencimento do pagamento PaymentDueDate	Data-limite contratual para o pagamento da fatura.
Descrição A data de vencimento do pagamento é um atributo de data essencial, definido pelas condições de pagamento acordadas com o cliente. Ela serve de referência para determinar se uma fatura está vencida e é o principal gatilho para iniciar atividades de cobrança, como enviar lembretes ou começar um procedimento formal de cobrança. No Process Mining, é usada para calcular a métrica 'Dias em atraso' e verificar a conformidade com as políticas de cobrança, por exemplo, confirmando se um lembrete foi enviado até X dias após o vencimento. Por que isso importa Essa data é a referência para medir a pontualidade dos pagamentos e aciona todas as atividades relacionadas a atrasos e cobranças. Onde encontrar Geralmente, é o campo 'DueDate' nas tabelas 'CustTrans' ou 'CustInvoiceJour'. Exemplos 2023-02-142023-03-312023-04-30
	Dias em atraso DaysOverdue	Número de dias desde o vencimento da fatura.
Descrição Dias em atraso é uma métrica calculada que mede o tempo decorrido desde a data de vencimento do pagamento de uma fatura não paga. O cálculo é feito subtraindo a data de vencimento do pagamento da data atual. Esse é um indicador de performance importante para a equipe de cobrança, pois ajuda a priorizar as faturas que precisam de atenção. É a principal métrica do Dashboard 'Faturas vencidas por segmento' e é fundamental para avaliar a situação das contas a receber e a eficácia das cobranças. Por que isso importa Essa métrica operacional é essencial para priorizar as cobranças e medir a gravidade dos atrasos nos pagamentos. Onde encontrar Este é um campo calculado. A lógica é: SE a fatura não foi paga, ENTÃO (Hoje() - DataDeVencimentoDoPagamento); CASO CONTRÁRIO, 0. Exemplos 1532910
	Nível de cobrança DunningLevel	Indica a etapa atual ou a gravidade do processo de cobrança de uma fatura vencida.
Descrição O nível de cobrança representa a etapa de um procedimento estruturado, como 'Nível 1: lembrete cordial', 'Nível 2: aviso formal' ou 'Nível 3: aviso final'. Acompanhar esse atributo é essencial para avaliar o sucesso da estratégia de cobrança. O Dashboard 'Eficácia da estratégia de cobrança' usa esse atributo para mostrar qual porcentagem das faturas é paga após atingir cada nível. Isso ajuda as empresas a aprimorar seus fluxos de trabalho de cobrança, aumentando a eficácia na obtenção dos pagamentos sem prejudicar o relacionamento com os clientes. Por que isso importa Esse atributo é essencial para medir a eficácia da estratégia de cobrança e entender em que etapa os clientes têm maior probabilidade de pagar. Onde encontrar Essas informações podem estar em tabelas relacionadas a cobranças e cartas de cobrança, como 'CustCollectionLetterJour'. Exemplos 123 - FinalAção judicial
	Nome do cliente CustomerName	Nome legal do cliente para quem a fatura foi emitida.
Descrição O nome do cliente identifica o cliente associado a uma fatura. Esse atributo é uma dimensão importante para filtros e segmentações. Analisar o processo por cliente ajuda a identificar aqueles que pagam com atraso com frequência, contestam faturas ou exigem muito esforço de cobrança. É um atributo importante para o Dashboard 'Tempo de ciclo da resolução de contestações' e para análises detalhadas de contas específicas. Por que isso importa Permite analisar o processo por cliente, ajudando a identificar padrões e gerenciar o relacionamento com contas importantes ou problemáticas. Onde encontrar Essas informações geralmente são obtidas por meio de uma junção com 'CustTable', usando o número da conta do cliente presente em 'CustInvoiceJour'. Exemplos Contoso Ltd.Adventure WorksFabrikam Inc.
	Responsável pela cobrança atribuído CollectorAssigned	Nome do agente de cobrança ou integrante da equipe responsável por gerenciar a fatura vencida.
Descrição Esse atributo identifica o funcionário responsável pelas atividades de cobrança de uma fatura específica. É essencial para analisar a performance e a carga de trabalho. Ao filtrar o mapa do processo ou os Dashboards por responsável pela cobrança, os gestores podem avaliar a produtividade individual, comparar estratégias de cobrança e identificar oportunidades de orientação. Esse atributo é uma dimensão importante para os Dashboards 'Produtividade da equipe de cobrança' e 'Tempo de ciclo da resolução de contestações', pois ajuda a relacionar os resultados do processo a pessoas ou equipes específicas. Por que isso importa Permite analisar a performance da equipe de cobrança, ajuda a equilibrar a carga de trabalho e identifica boas práticas ao comparar a eficácia dos responsáveis pela cobrança. Onde encontrar Consulte a documentação do Microsoft Dynamics 365. Esse dado pode estar vinculado a um módulo de gestão de cobranças ou aos campos de responsabilidade do usuário nos registros de clientes ou transações. Exemplos John SmithEmily JonesEquipe de cobrança A
	Segmento do cliente CustomerSegment	Classificação do cliente por porte, setor ou importância estratégica, por exemplo.
Descrição O segmento do cliente é um atributo categórico usado para agrupar clientes em grupos relevantes, como 'Contas estratégicas', 'Pequenas e médias empresas' ou 'Governo'. Essa segmentação é essencial para a análise estratégica. Ela ajuda a responder perguntas como 'As contas estratégicas têm um prazo médio de recebimento menor?' ou 'As baixas são mais comuns em algum setor específico?'. Esse atributo é usado diretamente nos Dashboards 'Tendência do prazo médio de recebimento de vendas', 'Baixas de faturas incobráveis' e 'Faturas vencidas por segmento' para gerar insights mais abrangentes do que os obtidos ao analisar clientes individualmente. Por que isso importa Permite analisar grupos de clientes de forma agregada, identificar tendências estratégicas e adaptar as estratégias de cobrança a cada segmento. Onde encontrar Geralmente, é um campo personalizado ou derivado de atributos da 'CustTable' (tabela mestre de clientes). Exemplos EnterpriseMercado intermediárioSetor públicoParceiro
	Status da fatura InvoiceStatus	Status atual da fatura no ciclo de vida.
Descrição O status da fatura mostra em que etapa do processo ela está, como 'Em aberto', 'Paga', 'Contestada' ou 'Baixada como perda'. Embora o registro de atividades forneça um histórico detalhado, o status atual é um atributo útil no nível do caso para filtros e relatórios gerais. Ele permite que os analistas segmentem rapidamente os dados para se concentrar apenas nas faturas vencidas em aberto ou analisar as características de todas as faturas baixadas como perda. É uma forma simples de entender a situação atual das contas a receber. Por que isso importa Facilita a filtragem e a análise de faturas com base no status atual, por exemplo, para se concentrar em todos os casos em aberto ou contestados. Onde encontrar Derivado do status de liquidação das transações na tabela 'CustTrans'. Uma transação em aberto não foi paga; uma transação encerrada foi liquidada. Exemplos Em abertoPagaParcialmente pagaBaixada como perda
	Valor da fatura InvoiceAmount	Valor monetário total da fatura.
Descrição O valor da fatura representa o valor financeiro total dos bens ou serviços cobrados. É um atributo fundamental para a análise financeira do processo. Ele permite segmentar os casos por valor e verificar se as faturas de maior valor seguem um processo diferente ou enfrentam atrasos maiores. Esse atributo é essencial para os Dashboards 'Baixas de faturas incobráveis' e 'Análise da gestão de limites de crédito', pois ajuda a quantificar o impacto financeiro e avaliar riscos. Por que isso importa Permite analisar o impacto financeiro, priorizar faturas de maior valor e entender como o valor da fatura afeta o comportamento do processo. Onde encontrar Provavelmente, é o campo 'InvoiceAmount' da tabela 'CustInvoiceJour'. Exemplos 1500.7525000.00549.99
	Código da moeda CurrencyCode	Moeda da fatura, como USD ou EUR.
Descrição O código da moeda especifica a moeda da transação referente ao valor da fatura. Esse atributo contextual é importante, especialmente para organizações multinacionais. Ele é necessário para interpretar corretamente os valores financeiros e pode ser usado para analisar se os ciclos ou problemas de pagamento estão relacionados a moedas específicas, o que pode indicar complexidades cambiais ou no processamento de pagamentos internacionais. Por que isso importa Fornece contexto essencial para todos os valores monetários e permite analisar processos que envolvem várias moedas. Onde encontrar Geralmente, é o campo 'CurrencyCode' da tabela 'CustInvoiceJour'. Exemplos USDEURGBPCAD
	Foi contestada IsDisputed	Indicador booleano que mostra se uma fatura já foi contestada.
Descrição Este é um indicador calculado, definido como verdadeiro se o caso da fatura contiver a atividade 'Controvérsia registrada'. Ele simplifica a análise, permitindo filtrar ou comparar facilmente os fluxos de faturas contestadas e não contestadas. Por exemplo, é possível comparar a média do prazo de recebimento de vendas das faturas contestadas com a das não contestadas e quantificar o impacto das contestações no fluxo de caixa. É um atributo útil para Dashboards gerais e análises comparativas. Por que isso importa Simplifica a análise e a filtragem, facilitando a comparação entre faturas contestadas e não contestadas. Onde encontrar Este é um campo calculado. A lógica é: SE o caso contiver a atividade 'Controvérsia registrada', ENTÃO verdadeiro; CASO CONTRÁRIO, falso. Exemplos truefalse
	Limite de crédito CreditLimit	Valor máximo de crédito aprovado para o cliente.
Descrição O limite de crédito é o valor total da dívida que um cliente está autorizado a acumular. Esse atributo é essencial para a gestão de riscos. O Dashboard 'Análise da gestão de limites de crédito' compara esse valor com os valores das faturas de contas inadimplentes ou baixadas como perda. Essa análise ajuda a determinar se os limites de crédito estão definidos corretamente e são respeitados, além de verificar se clientes inadimplentes tiveram aumentos recentes nos limites, o que pode revelar fragilidades no processo de aprovação de crédito. Por que isso importa Essencial para avaliar riscos, esse atributo ajuda a analisar se as baixas estão relacionadas a limites de crédito inadequados ou mal gerenciados. Onde encontrar Esse valor geralmente fica armazenado no registro mestre do cliente em 'CustTable'. Exemplos 10000.0050000.000.00
	Motivo da contestação DisputeReason	Motivo informado pelo cliente para contestar uma fatura.
Descrição Quando contesta uma fatura, o cliente geralmente informa um motivo, como 'Preço incorreto', 'Mercadoria danificada' ou 'Cobrança duplicada'. Esse atributo registra o motivo. Analisar os motivos das contestações é essencial para a análise de causa raiz. Isso ajuda a identificar problemas recorrentes no processo do pedido ao recebimento, como falhas nas áreas de vendas, expedição ou faturamento. Reduzir as contestações desde a origem é um resultado importante dessa análise e afeta diretamente o prazo médio de recebimento de vendas, pois evita atrasos nos pagamentos. Por que isso importa Fornece dados essenciais para a análise de causa raiz dos atrasos nos pagamentos e ajuda a identificar e corrigir problemas anteriores no processo que levam a contestações de faturas. Onde encontrar Consulte a documentação do Microsoft Dynamics 365. Esse dado faz parte dos recursos de gestão de contestações ou de casos. Exemplos Erro de preçoQuantidade inferior à solicitadaProduto não recebidoServiço diferente do descrito
	País Country	País do endereço de cobrança do cliente.
Descrição Esse atributo especifica o país associado à conta do cliente. É uma dimensão comum para análises geográficas. Segmentar KPIs do processo, como o prazo médio de recebimento ou as taxas de baixa, por país pode revelar diferenças regionais no comportamento de pagamento dos clientes, na eficácia das cobranças ou nas condições econômicas. Com isso, é possível adaptar as estratégias de cobrança a cada região ou definir condições de pagamento diferentes para determinados locais. Por que isso importa Permite análises geográficas para identificar tendências regionais no comportamento de pagamento e na performance do processo de cobrança. Onde encontrar Esse dado é obtido por meio de uma junção do registro mestre do cliente ('CustTable') com o registro do endereço principal, geralmente em 'LogisticsPostalAddress'. Exemplos USADEUGBRCAN
	Sistema de origem SourceSystem	Identifica o sistema de origem dos dados.
Descrição Esse atributo especifica o aplicativo de origem em que os dados do evento foram registrados. Neste caso, seria 'Microsoft Dynamics 365'. Embora possa parecer um dado fixo em uma análise de um único sistema, ele é essencial para a governança de dados, a solução de problemas e futuras integrações. Se forem incluídos dados de outros sistemas, como um CRM separado ou um portal de uma agência de cobrança, esse campo será essencial para diferenciá-los e entender o processo completo entre sistemas. Por que isso importa Oferece rastreabilidade clara dos dados e é essencial para manter a qualidade dos dados e permitir análises entre vários sistemas integrados. Onde encontrar Geralmente, é um valor fixo adicionado durante a extração dos dados para identificar a origem dos registros. Exemplos Microsoft Dynamics 365D365 F&O
	Tempo de resolução da contestação DisputeResolutionTime	Tempo necessário para resolver uma contestação do cliente, contado a partir do primeiro registro.
Descrição O tempo de resolução da contestação mede a eficiência do processo de tratamento de contestações. Ele é calculado pela duração entre as atividades 'Controvérsia registrada' e 'Controvérsia resolvida'. Tempos longos de resolução podem atrasar o pagamento e prejudicar a satisfação do cliente. Analisar essa métrica por responsável pela cobrança ou motivo da contestação ajuda a identificar gargalos e oportunidades de melhoria no fluxo de trabalho de gestão de contestações. Por que isso importa Mede a eficiência do processo de tratamento de contestações, uma causa comum de atrasos significativos nos pagamentos. Onde encontrar Calculado pela duração entre as datas e horas das atividades 'Controvérsia registrada' e 'Controvérsia resolvida'. Exemplos 7.215.83.5
	Última atualização dos dados LastDataUpdate	Data e hora da última atualização ou recarga dos dados.
Descrição Esse atributo indica quando os dados foram atualizados pela última vez a partir do sistema de origem. É um metadado essencial para quem usa a análise de Process Mining, pois informa o nível de atualização dos dados. Saber até que momento os dados estão atualizados ajuda os analistas a tomar decisões fundamentadas e entender o alcance das conclusões. Normalmente, esse atributo é aplicado ao conjunto de dados inteiro durante o processo de ingestão. Por que isso importa Informa aos usuários o nível de atualização dos dados, garantindo que as análises considerem um período conhecido e evitando decisões baseadas em informações desatualizadas. Onde encontrar Esse valor é gerado e registrado no conjunto de dados pelo pipeline de ETL/dados durante a execução. Exemplos 2023-04-01T02:00:00Z2023-04-02T02:00:00Z

Obrigatório Recomendado Opcional

Atividades de gestão de crédito e cobranças

Estas são as principais etapas e os marcos do processo que você deve registrar no Event Log para identificar com precisão o fluxo de trabalho de gestão de crédito e cobranças.

9 Recomendado 3 Opcional

	Atividade	Descrição
	Carta de cobrança gerada	Indica que uma carta formal de cobrança foi criada para a fatura vencida. O evento é registrado quando o processo periódico de cobrança é executado no Dynamics 365 e gera registros de cartas para as faturas relevantes.
Por que isso importa Acompanha o início e a frequência das ações formais de cobrança. É essencial para medir a eficácia das cobranças e a conformidade com as políticas internas. Onde encontrar Um registro explícito é criado na tabela de histórico de cobranças (CustCollectionLetterJour). A data de criação do diário da carta de cobrança é a data e hora do evento. Coleta Extraia os eventos de criação da tabela CustCollectionLetterJour e relacione-os à fatura correspondente. Tipo de evento explicit
	Controvérsia registrada	Indica que o cliente contestou formalmente a fatura e que o status foi atualizado. Isso geralmente é registrado quando um usuário altera o status da fatura para 'Contestado' no módulo de gestão de cobranças.
Por que isso importa Este é o ponto de partida do processo de resolução de contestações. Acompanhar esse evento ajuda a medir a frequência das contestações e o tempo necessário para resolvê-las, fatores que afetam a satisfação do cliente e o fluxo de caixa. Onde encontrar Inferido a partir de uma alteração de status na transação do cliente (CustTrans) ou em uma tabela relacionada à gestão de contestações (smmCaseDetail). É necessário um registro com data e hora da alteração de status. Coleta Identifique quando o campo de status da contestação de uma transação de fatura é preenchido ou alterado para 'Contestado'. Tipo de evento inferred
	Fatura baixada como perda	A fatura foi considerada incobrável e baixada formalmente como perda por inadimplência. Essa ação explícita é realizada por um usuário autorizado, que baixa o recebível e registra a perda.
Por que isso importa Este é o principal ponto de conclusão malsucedida do processo. Acompanhar as baixas é essencial para entender o risco de crédito, as falhas na cobrança e as perdas financeiras. Onde encontrar Registrado a partir de uma transação específica do diário geral usada para baixar perdas por inadimplência e vinculada à fatura original. A data de lançamento do diário de baixa é registrada como data e hora do evento. Coleta Identifique lançamentos do diário com um perfil específico de lançamento de baixa que façam referência à fatura. Tipo de evento explicit
	Fatura contabilizada e enviada	Representa o registro oficial da fatura no razão geral, que a transforma em um valor formal a receber. Esse evento costuma coincidir com o envio da fatura ao cliente e é registrado quando a rotina de contabilização é concluída no Dynamics 365.
Por que isso importa Este é um marco crítico que inicia oficialmente a contagem dos prazos de pagamento e do vencimento. Atrasos entre a geração e a contabilização podem ocultar ineficiências no processo de faturamento. Onde encontrar Inferido a partir da data de contabilização no diário de faturas de clientes (CustInvoiceJour) ou de uma mudança de status para “Contabilizada”. A data e hora da contabilização são o dado principal. Coleta Use a data e hora de contabilização do diário de faturas de clientes (CustInvoiceJour). Tipo de evento inferred
	Fatura gerada	Indica a criação de um registro de fatura de venda no sistema, antes da contabilização oficial. Essa atividade costuma ser registrada como um evento explícito quando um usuário finaliza um pedido de venda e gera o documento da fatura correspondente.
Por que isso importa Este é o principal evento de início do ciclo de vida da fatura. Analisar o tempo entre esse momento e o pagamento é essencial para medir o prazo médio de recebimento de vendas (DSO). Onde encontrar Registrado na tabela de cabeçalho da fatura de venda (SalesInvoiceHeader) ou na tabela de vendas (SalesTable) quando a fatura é criada. A data e hora de criação do registro servem como horário do evento. Coleta Registre a data e hora de criação do registro da fatura de venda. Tipo de evento explicit
	Fatura quitada	A fatura foi totalmente paga e seu saldo é zero, o que marca a conclusão bem-sucedida do processo. Esse status é inferido quando a soma dos pagamentos aplicados corresponde ao valor total da fatura.
Por que isso importa Este é o principal ponto de conclusão bem-sucedida do processo de crédito ao recebimento. Analisar os caminhos que levam até aqui ajuda a identificar boas práticas e variantes eficientes do processo. Onde encontrar Inferido a partir da data de liquidação na tabela de liquidações de clientes (CustSettlement). Isso ocorre quando a soma dos campos 'AmountCur' e 'SettleAmountCur' da fatura em CustTrans é zero. Coleta Identifique a data de liquidação mais recente associada à transação da fatura que zera o saldo. Tipo de evento inferred
	Pagamento lançado	Representa o lançamento oficial do pagamento do cliente no razão geral e sua aplicação para quitar uma fatura. Esse evento é registrado a partir da data de lançamento do diário de pagamentos de clientes.
Por que isso importa Conclui a etapa de pagamento do processo. O intervalo entre o recebimento e o lançamento do pagamento, chamado de atraso na aplicação de recebimentos, é uma métrica importante de eficiência para a área financeira. Onde encontrar Registrado a partir do horário de lançamento do diário de pagamentos de clientes (LedgerJournalTrans). Isso confirma que o pagamento foi totalmente processado no razão. Coleta Use a data de lançamento do diário de pagamentos de clientes lançado. Tipo de evento explicit
	Pagamento recebido	Indica que um pagamento do cliente foi recebido e registrado no sistema, geralmente por meio de um diário de pagamentos. Esse evento ocorre antes do lançamento final e da aplicação do valor à fatura específica.
Por que isso importa Este é um marco importante para calcular o prazo médio de recebimento de vendas e entender o fluxo de caixa. O intervalo entre esse evento e o lançamento do pagamento revela gargalos no processo de aplicação de recebimentos. Onde encontrar Evento explícito registrado a partir da data de criação de uma linha do diário de pagamentos de clientes (LedgerJournalTrans), antes do lançamento. Representa a data em que o pagamento foi registrado como recebido. Coleta Use a data da transação nas linhas do diário de pagamentos de clientes. Tipo de evento explicit
	Prazo de pagamento vencido	Evento calculado que ocorre quando a data atual ultrapassa a data de vencimento da fatura. Essa atividade não corresponde a uma ação direta do usuário; ela é identificada pela comparação entre a data do sistema e o campo de vencimento da fatura.
Por que isso importa Este evento dá início a todas as atividades de cobrança. Ele permite analisar o volume de faturas vencidas e a pontualidade das ações de cobrança, apoiando KPIs como a adesão à política de cobrança. Onde encontrar Calculado pela comparação entre a data e hora atuais e o campo “DueDate” da tabela de transações de clientes (CustTrans). A data e hora do evento correspondem à própria DueDate. Coleta Crie um evento quando “NOW()” for posterior à DueDate da fatura. Tipo de evento calculated
	Atividade de cobrança registrada	Representa uma ação manual de cobrança, como uma ligação ou um e-mail, registrada para o cliente ou a fatura. O evento é registrado quando um agente usa o recurso de atividades no espaço de trabalho de cobrança para documentar as interações.
Por que isso importa Oferece visibilidade sobre o trabalho manual da equipe de cobrança. Analisar essas atividades em relação ao sucesso dos pagamentos ajuda a medir a produtividade da equipe e a eficácia dos diferentes canais de contato. Onde encontrar Registrado nas tabelas de atividades (smmActivities) ou em tabelas relacionadas à gestão de casos associadas à conta do cliente. Se possível, é necessário relacionar a atividade a uma fatura específica. Coleta Registre a criação de registros de atividade do tipo “Ligação telefônica” ou “E-mail” relacionados à cobrança. Tipo de evento explicit
	Controvérsia resolvida	Marca o fim do processo de contestação, quando uma solução é alcançada e documentada. Esse evento é registrado quando um usuário atualiza o status da contestação de uma fatura para 'Resolvido' ou encerra o caso de contestação associado.
Por que isso importa Esta atividade encerra o subprocesso de contestação. O tempo entre o registro e a resolução da contestação é um KPI importante para medir a eficiência da equipe responsável. Onde encontrar Inferido a partir de uma alteração de status na transação do cliente (CustTrans) ou do encerramento do caso de contestação relacionado (smmCaseDetail). O horário dessa alteração de status é o horário do evento. Coleta Identifique quando o campo de status da contestação de uma fatura é apagado ou alterado para 'Resolvido'. Tipo de evento inferred
	Promessa de pagamento registrada	O cliente se comprometeu a fazer um pagamento em uma data futura específica, e essa promessa foi registrada no sistema. O evento é registrado explicitamente quando um agente de cobrança insere os detalhes da promessa de pagamento no módulo de cobrança.
Por que isso importa Acompanha acordos informais de pagamento e suas taxas de cumprimento. Comparar as promessas com os pagamentos realizados pode ajudar a prever o fluxo de caixa e avaliar a confiabilidade dos clientes. Onde encontrar Provavelmente registrado em tabelas relacionadas ao espaço de trabalho de cobrança ou à gestão de casos, especificamente às funcionalidades de promessa de pagamento. A data de criação do registro da promessa é a data e hora do evento. Coleta Capture os eventos de criação em uma tabela de detalhes de casos de promessa de pagamento ou cobrança. Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Microsoft Dynamics 365

Etapas

Verifique os pré-requisitos: Confirme se sua organização tem o Microsoft Dynamics 365 Finance e se o recurso Bring Your Own Database (BYOD) está configurado para exportar entidades de dados ativamente para um Azure SQL Database. Você precisa de credenciais com acesso de leitura a esse Azure SQL Database.
Identifique as entidades de dados: Confirme se as entidades de dados necessárias estão sendo exportadas do Dynamics 365 para seu BYOD. Entre as principais entidades deste processo estão: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment e CustDispute. Se alguma estiver faltando, configure sua exportação no espaço de trabalho Data Management do Dynamics 365.
Conecte-se ao banco de dados BYOD: Use um cliente SQL, como SQL Server Management Studio (SSMS) ou Azure Data Studio, para se conectar ao Azure SQL Database usado como destino do BYOD.
Prepare a consulta SQL: Copie a consulta T-SQL completa fornecida na seção query deste documento para seu cliente SQL. Ela foi criada para reunir todas as atividades e os atributos necessários em um único formato de Event Log.
Defina os parâmetros da consulta: Localize os placeholders no início da consulta. Substitua '{CompanyCode}' pelo ID da entidade legal do Dynamics 365 que você quer analisar, como 'USMF'. Substitua '{StartDate}' e '{EndDate}' pelo período desejado, no formato 'YYYY-MM-DD'.
Execute a consulta: Rode a consulta modificada no banco de dados BYOD. O tempo de execução varia conforme o volume de dados no período selecionado.
Confira os resultados: Quando a consulta terminar, o painel de resultados exibirá o Event Log. Cada linha representa uma atividade específica no ciclo de vida de crédito e cobranças de uma fatura. Verifique se os dados estão completos e corretos.
Exporte o Event Log: Exporte os resultados da consulta para um arquivo CSV. A maioria dos clientes SQL tem uma função integrada para exportar resultados. Clique com o botão direito na grade de resultados e procure uma opção como 'Salvar resultados como' ou 'Exportar'.
Prepare os dados para carregamento: Confira se o arquivo CSV exportado usa codificação UTF-8 e se os cabeçalhos das colunas correspondem aos atributos obrigatórios: InvoiceNumber, ActivityName, EventTime e os atributos recomendados que você incluiu. O arquivo estará pronto para ser carregado no ProcessMind.

Configuração

Pré-requisitos: Acesso a uma instância do Microsoft Dynamics 365 for Finance com o recurso Bring Your Own Database (BYOD) configurado e em execução. É necessário ter permissão de leitura no Azure SQL Database de destino.
Entidades de dados: A extração depende da exportação de várias entidades de dados padrão para o BYOD. Inclua pelo menos CustInvoiceJour, CustTrans, CustTable e CustSettlement no trabalho de exportação do BYOD. Outras entidades, como CustCollectionLetterJour, são necessárias para atividades específicas.
Período: É essencial filtrar a consulta por um período específico para controlar a performance. Para uma análise inicial, recomendamos de 3 a 6 meses de dados. A consulta fornecida usa os placeholders '{StartDate}' e '{EndDate}' para definir o período.
Filtro por empresa: A consulta deve ser filtrada por uma entidade legal específica (código da empresa) para manter a consistência dos dados. Use o placeholder '{CompanyCode}' para indicar a empresa que você está analisando.
Considerações de performance: Consultas a conjuntos de dados muito grandes, que abrangem vários anos ou empresas, podem demorar bastante. Considere executar a consulta em horários de menor movimento ou aplicar filtros adicionais para limitar o escopo dos dados. Confira se há índices adequados nas colunas de data e nas colunas-chave das tabelas BYOD.

Consulta de exemplo sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

Etapas

Pré-requisitos e configuração do ambiente: Instale o Python 3.8 ou uma versão mais recente. Instale as bibliotecas necessárias com pip: pip install pandas requests msal. Você também precisará das credenciais de uma entidade de serviço com acesso ao ambiente do Dynamics 365.
Registre o aplicativo no Azure AD: Acesse o portal do Azure Active Directory. Registre um novo aplicativo para obter um Client ID e um Tenant ID. Crie um novo segredo do cliente na seção 'Certificados e segredos' do aplicativo. Armazene com segurança o Client ID, o Tenant ID e o Client Secret.
Conceda permissões à API: Nas configurações de 'Permissões de API' do aplicativo registrado no Azure AD, adicione uma permissão. Selecione 'Dynamics ERP' ou uma opção semelhante para o Dynamics 365 e conceda a permissão delegada 'user_impersonation'. Conceda consentimento de administrador para sua organização.
Crie um usuário do Dynamics 365: Crie um usuário de aplicativo dedicado no Dynamics 365 Finance and Operations. Associe esse usuário ao Client ID do aplicativo Azure AD. Atribua a ele uma função de segurança com permissões de leitura para todas as entidades de dados necessárias, como CustInvoiceJour, CustCollectionLetterJour, CustSettlements e smmActivities.
Configure o script Python: Copie o script Python fornecido para um arquivo, por exemplo, extract_d365_collections.py. Preencha as variáveis placeholder no início do script com a URL do ambiente D365, o Tenant ID, o Client ID, o Client Secret e a empresa padrão (dataAreaId).
Defina os parâmetros de extração: Ajuste as variáveis start_date e end_date no script para definir o período de extração dos dados. Para a análise inicial, recomendamos um período de 3 a 6 meses.
Execute o script: Rode o script no terminal com o comando python extract_d365_collections.py. O script fará a autenticação, consultará os endpoints OData das 12 atividades e tratará automaticamente a paginação da API.
Obtenha os dados de cada atividade: O script fará chamadas sequenciais à API para buscar dados de geração e lançamento de faturas, cobranças, pagamentos e outros eventos importantes. Cada consulta acessa uma entidade de dados específica e seleciona apenas os campos necessários para otimizar a performance.
Transforme e combine os dados: O script usa a biblioteca pandas para processar a resposta JSON de cada chamada à API. Ele transforma os dados em uma tabela estruturada, padroniza os nomes das colunas e combina os dados de todas as atividades em um único Event Log.
Calcule os eventos derivados: A atividade 'Data de vencimento do pagamento ultrapassada' não é registrada diretamente no sistema. O script percorre todas as faturas vencidas no período especificado e gera uma linha correspondente para cada uma.
Exporte o Event Log: Depois de processar e combinar todos os dados, o script salva o Event Log final como um arquivo CSV chamado d365_collections_event_log.csv no mesmo diretório. O arquivo está formatado e pronto para ser carregado em uma ferramenta de Process Mining.

Configuração

URL do endpoint da API: A URL base do seu ambiente Dynamics 365 Finance and Operations. Use o formato https://[your-environment-name].operations.dynamics.com.
Credenciais de autenticação: O script precisa do Tenant ID, do Client ID e do Client Secret de um aplicativo registrado no Azure Active Directory. Esse aplicativo deve ter permissão para acessar a API do Dynamics 365.
Filtro por empresa (dataAreaId): O Dynamics 365 é um sistema multiempresa. O script consulta uma empresa específica usando o filtro dataAreaId. Defina a variável default_company com a entidade legal correta, como 'USMF'.
Período: Os parâmetros start_date e end_date definem o período de extração. Para controlar o volume de dados e concluir a extração em tempo hábil, recomendamos começar com um período recente de 3 a 6 meses. O filtro é aplicado principalmente à data de criação da fatura.
Considerações de performance: A extração de conjuntos de dados muito grandes pela API OData pode demorar e estar sujeita à limitação de chamadas da API pela Microsoft. Se houver problemas de performance, considere extrair períodos menores ou executar o processo em horários de menor movimento.
Pré-requisitos: É necessário ter um ambiente Python 3.8 ou superior com as bibliotecas pandas, requests e msal. O usuário associado do Dynamics 365 precisa ter acesso de leitura aos módulos de gestão financeira, vendas e cobranças, especialmente às entidades mencionadas no script.

Consulta de exemplo python

import requests
import pandas as pd
import msal
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

Pronto para começar?

Use este Template para preparar seus dados com eficiência e encontrar insights valiosos sobre as operações de gestão de crédito e cobranças. Comece hoje a otimizar seu processo para acelerar o fluxo de caixa.

Voltar ao guia de melhoria

Baixar Template

Otimize crédito e cobranças para acelerar os recebimentos

Melhore o fluxo de caixa simplificando o ciclo de crédito ao recebimento e reduzindo o tempo de ciclo em 30%.

Comece o teste grátis

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

Seu Template de dados de gestão de crédito e cobranças

Seu Template de dados de gestão de crédito e cobranças

Atributos de gestão de crédito e cobranças

Atividades de gestão de crédito e cobranças

Guias de extração

Consulta SQL direta pelo Bring Your Own Database (BYOD)

Etapas

Configuração

Consulta de exemplo sql

Script Python usando a API REST OData do Dynamics 365

Etapas

Configuração

Consulta de exemplo python

Pronto para começar?

Otimize crédito e cobranças para acelerar os recebimentos