> Mejora continua de procesos > Gestión de crédito y cobros > Microsoft Dynamics 365 > Template de datos

Su plantilla de datos para la gestión de crédito y cobros

Microsoft Dynamics 365

Atributos de gestión de crédito y cobros (19) Actividades de gestión de crédito y cobros (12) Guías de extracción (2)

Su plantilla de datos para la gestión de crédito y cobros

Esta plantilla ofrece una guía completa para recopilar los datos necesarios para analizar su proceso de gestión de crédito y cobros. Incluye los atributos de datos esenciales, las actividades clave que debe supervisar y recomendaciones prácticas para extraer los datos. Utilice este recurso para agilizar la preparación de sus datos y avanzar más rápido en su recorrido de Process Mining.

Atributos recomendados para recopilar un análisis completo
Actividades clave del proceso que debe supervisar para obtener un descubrimiento preciso
Recomendaciones prácticas para extraer datos de su sistema

¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Descargar Template

Atributos de gestión de crédito y cobros

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para analizar exhaustivamente su proceso de gestión de crédito y cobros.

3 Obligatorio 8 Recomendado 8 Opcional

	Nombre	Descripción
	Hora del evento EventTime	La marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específico.
Descripción La hora del evento es la fecha y hora exactas en que se registró una actividad en el sistema. Es un elemento fundamental de Process Mining, ya que proporciona el orden cronológico necesario para construir el flujo del proceso y calcular todas las métricas basadas en el tiempo. Este atributo es esencial para analizar duraciones, identificar cuellos de botella y supervisar los SLA. Por ejemplo, la diferencia entre los eventos «Factura generada» y «Pago recibido» se utiliza para calcular los días de ventas pendientes de cobro (DSO), un KPI empresarial fundamental. Sin marcas de tiempo precisas, no es posible analizar el rendimiento ni identificar cuellos de botella. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, descubrir el mapa de procesos y calcular todas las métricas de rendimiento, como los tiempos de ciclo y las duraciones. Dónde obtenerlo Este atributo procede de varios campos de fecha y hora de las tablas de D365, como «CreatedDateTime» en «CustInvoiceJour» o «TransDate» en «CustTrans», según la actividad específica. Ejemplos 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Nombre de la actividad ActivityName	El nombre del evento o la tarea específicos que tuvieron lugar en un momento del ciclo de vida de la factura.
Descripción El nombre de la actividad describe un paso o evento específico dentro del proceso de crédito y cobro, como «Factura generada», «Carta de cobro enviada» o «Pago recibido». Este atributo es fundamental para Process Mining, ya que define los nodos del mapa de procesos. Analizar la secuencia y la frecuencia de estas actividades revela el flujo real del proceso y permite identificar bucles de retrabajo, ineficiencias y rutas que no cumplen las normas. También respalda directamente la creación de todas las visualizaciones del flujo del proceso y se utiliza para segmentar los cálculos del tiempo de ciclo entre las distintas etapas. Por qué es importante Este atributo define los pasos del mapa de procesos y permite visualizar y analizar el ciclo de vida de la factura. Dónde obtenerlo Normalmente, este atributo se obtiene asignando eventos específicos del sistema, cambios de estado o fechas de creación de registros de varias tablas, como «CustInvoiceJour», «CustTrans», «CustCollectionLetterJour» y «CustPaymPromise», a nombres de actividad estandarizados. Ejemplos Factura contabilizada y enviadaCarta de gestión de cobros generadaDisputa registradaPago recibido
	Número de factura InvoiceNumber	El identificador único de cada factura de cliente, que sirve como identificador principal del caso para el proceso de gestión de crédito.
Descripción El número de factura es un atributo fundamental que identifica de forma única cada transacción financiera con un cliente. Vincula todas las actividades relacionadas, desde la generación y el registro de la factura hasta el cobro y la liquidación final. En Process Mining, este número se utiliza para reconstruir el recorrido completo de cada factura y analizar detalladamente su ciclo de vida. Al realizar el seguimiento de cada factura como un caso independiente, las organizaciones pueden identificar rutas habituales del proceso, cuellos de botella y desviaciones del procedimiento estándar. Es la base para calcular métricas clave como los días de ventas pendientes de cobro y analizar las variantes del proceso. Por qué es importante Este es el Case ID esencial que conecta todos los eventos del proceso y permite reconstruir y analizar todo el ciclo de vida de factura a efectivo. Dónde obtenerlo Normalmente es el campo «Invoice» de la tabla «CustInvoiceJour» de Microsoft Dynamics 365 Finance. Ejemplos INV-0012345CIV-2023-8876SI-9510034
	Días de vencimiento DaysOverdue	El número de días que han transcurrido desde la fecha de vencimiento del pago de una factura.
Descripción Los días de vencimiento son una métrica calculada que mide el tiempo transcurrido desde la fecha de vencimiento del pago de una factura impagada. Se calculan como la fecha actual menos la fecha de vencimiento del pago. Es un indicador clave de rendimiento para el equipo de cobro, ya que ayuda a priorizar las facturas que requieren atención. Es la métrica principal del panel «Facturas vencidas por segmento» y resulta fundamental para evaluar la salud de las cuentas por cobrar y la eficacia de los esfuerzos de cobro. Por qué es importante Es una métrica operativa fundamental que se utiliza para priorizar los esfuerzos de cobro y medir la gravedad de los retrasos en los pagos. Dónde obtenerlo Es un campo calculado. La lógica es: IF la factura no está pagada THEN (Today() - PaymentDueDate) ELSE 0. Ejemplos 1532910
	Estado de la factura InvoiceStatus	El estado actual de la factura en su ciclo de vida.
Descripción El estado de la factura ofrece una visión del punto del proceso en el que se encuentra una factura, como «Abierta», «Pagada», «En disputa» o «Dada de baja». Aunque el registro de actividades proporciona un historial detallado, el estado actual es un atributo útil del caso para el filtrado y los informes de alto nivel. Permite a los analistas segmentar rápidamente los datos para centrarse solo en facturas abiertas y vencidas o analizar las características de todas las facturas dadas de baja. Es una forma sencilla pero eficaz de comprender el estado actual de las cuentas por cobrar. Por qué es importante Ofrece una forma rápida y sencilla de filtrar y analizar las facturas según su estado actual, por ejemplo, para centrarse en todos los casos abiertos o en disputa. Dónde obtenerlo Se deriva del estado de liquidación de las transacciones de la tabla «CustTrans». Una transacción abierta no está pagada, mientras que una cerrada está liquidada. Ejemplos AbiertaPagadaPagada parcialmenteDada de baja
	Fecha de vencimiento del pago PaymentDueDate	La fecha límite contractual para el pago de la factura.
Descripción La fecha de vencimiento del pago es un atributo de fecha fundamental definido por las condiciones de pago acordadas con el cliente. Sirve como referencia para determinar si una factura está vencida. Es el principal desencadenante de las actividades de cobro, como enviar recordatorios o iniciar un procedimiento formal de reclamación. En Process Mining, se utiliza para calcular la métrica «Días de vencimiento» y comprobar el cumplimiento de las políticas de reclamación, por ejemplo, verificando que se envió un recordatorio dentro de los X días posteriores al vencimiento. Por qué es importante Esta fecha sirve como referencia para medir la puntualidad de los pagos y desencadena todas las actividades relacionadas con vencimientos y cobros. Dónde obtenerlo Normalmente, se encuentra en el campo «DueDate» de las tablas «CustTrans» o «CustInvoiceJour». Ejemplos 2023-02-142023-03-312023-04-30
	Gestor de cobro asignado CollectorAssigned	El nombre de la persona gestora de cobro o del miembro del equipo responsable de gestionar la factura vencida.
Descripción Este atributo identifica a la persona empleada responsable de las actividades de cobro de una factura concreta. Es fundamental para analizar el rendimiento y la carga de trabajo. Al filtrar el mapa de procesos o los Dashboards por persona responsable del cobro, los responsables pueden evaluar la productividad individual, comparar estrategias de cobro e identificar oportunidades de formación. Este atributo es una dimensión clave para los Dashboards 'Collection Team Productivity' y 'Dispute Resolution Cycle Time', ya que permite atribuir los resultados del proceso a personas o equipos concretos. Por qué es importante Permite analizar el rendimiento del equipo de cobro, ayuda a equilibrar las cargas de trabajo e identifica buenas prácticas al comparar la eficacia de las personas gestoras de cobro. Dónde obtenerlo Consultar la documentación de Microsoft Dynamics 365. Este dato podría estar vinculado a un módulo de gestión de cobros o a campos de responsabilidad de la persona usuaria en los registros de clientes o transacciones. Ejemplos John SmithEmily JonesEquipo de cobros A
	Importe de la factura InvoiceAmount	El valor monetario total de la factura.
Descripción Invoice Amount representa el valor financiero total de los bienes o servicios facturados. Es un atributo fundamental para el análisis financiero del proceso. Permite segmentar los casos por valor para comprobar si las facturas de importe elevado siguen un proceso diferente o sufren retrasos más prolongados. Este atributo es esencial para los Dashboards 'Uncollectible Invoice Write-Offs' y 'Credit Limit Management Analysis', ya que ayuda a cuantificar el impacto financiero y evaluar el riesgo. Por qué es importante Permite analizar el impacto financiero, priorizar las facturas de importe elevado y comprender cómo afecta el valor de la factura al comportamiento del proceso. Dónde obtenerlo Probablemente sea el campo «InvoiceAmount» de la tabla «CustInvoiceJour». Ejemplos 1500.7525000.00549.99
	Nivel de reclamación DunningLevel	Indica la etapa o el nivel de gravedad actual del proceso de reclamación de cobro de una factura vencida.
Descripción El nivel de reclamación representa el paso dentro de un procedimiento estructurado de cobro, por ejemplo, «Nivel 1: recordatorio cordial», «Nivel 2: aviso formal» o «Nivel 3: advertencia final». Hacer un seguimiento de este atributo es esencial para evaluar el éxito de la estrategia de cobro. El panel «Eficacia de la estrategia de reclamación» utiliza este atributo para mostrar qué porcentaje de facturas se paga después de alcanzar cada nivel. Esto ayuda a las empresas a perfeccionar sus flujos de trabajo de reclamación para conseguir pagos con mayor eficacia y mantener las relaciones con los clientes. Por qué es importante Es fundamental para medir la eficacia de la estrategia de reclamación y comprender en qué etapa es más probable que paguen los clientes. Dónde obtenerlo Esta información se encontraría en tablas relacionadas con cobros y cartas de reclamación, como «CustCollectionLetterJour». Ejemplos 123 - FinalAcción legal
	Nombre del cliente CustomerName	El nombre legal del cliente al que se emitió la factura.
Descripción El nombre del cliente identifica al cliente específico asociado a una factura. Este atributo es una dimensión principal para el filtrado y la segmentación. Analizar el proceso por cliente ayuda a identificar clientes problemáticos que pagan tarde de forma habitual, plantean disputas o requieren grandes esfuerzos de cobro. Es un atributo clave para el panel «Tiempo de ciclo de resolución de disputas» y para cualquier análisis detallado de cuentas de clientes concretas. Por qué es importante Permite analizar el proceso por cliente, identificar patrones y gestionar las relaciones con cuentas clave o problemáticas. Dónde obtenerlo Normalmente, esta información se incorpora desde «CustTable» utilizando el número de cuenta del cliente presente en «CustInvoiceJour». Ejemplos Contoso Ltd.Adventure WorksFabrikam Inc.
	Segmento de clientes CustomerSegment	Una clasificación del cliente, por ejemplo, según su tamaño, sector o importancia estratégica.
Descripción Customer Segment es un atributo categórico que se utiliza para agrupar clientes en cohortes relevantes, por ejemplo, 'Strategic Accounts', 'SMB' o 'Government'. Esta segmentación es fundamental para el análisis estratégico. Ayuda a responder preguntas como: «¿Las cuentas estratégicas tienen un DSO menor?» o «¿Las cancelaciones contables son más frecuentes en un segmento industrial concreto?». Se utiliza directamente en los Dashboards 'Days Sales Outstanding Trend', 'Uncollectible Invoice Write-Offs' y 'Overdue Invoices By Segment' para ofrecer conclusiones de nivel superior, más allá de los clientes individuales. Por qué es importante Permite realizar análisis agregados por grupos de clientes para identificar tendencias estratégicas y adaptar las estrategias de cobro a cada segmento. Dónde obtenerlo A menudo, es un campo personalizado o se deriva de atributos de «CustTable», la tabla maestra de clientes. Ejemplos Empresa grandeEmpresa medianaSector públicoSocio
	Código de moneda CurrencyCode	La moneda de la factura, por ejemplo, USD o EUR.
Descripción El código de moneda especifica la moneda de la transacción correspondiente al importe de la factura. Es un atributo contextual importante, especialmente para organizaciones multinacionales. Es necesario para interpretar correctamente los valores financieros y puede utilizarse para analizar si los ciclos de pago o los problemas están relacionados con monedas específicas, lo que podría deberse a la complejidad del cambio de divisas o del procesamiento de pagos internacionales. Por qué es importante Proporciona el contexto esencial para todos los valores monetarios y permite analizar procesos que utilizan varias monedas. Dónde obtenerlo Normalmente, se encuentra en el campo «CurrencyCode» de la tabla «CustInvoiceJour». Ejemplos USDEURGBPCAD
	Está en disputa IsDisputed	Un indicador booleano que señala si una factura ha estado alguna vez en disputa.
Descripción Es un indicador calculado que se establece en true si un caso de factura contiene la actividad 'Dispute Registered'. Simplifica el análisis, ya que permite filtrar o comparar fácilmente los flujos de proceso de las facturas con disputas y sin disputas. Por ejemplo, permite comparar fácilmente el DSO medio de las facturas con disputas con el de las facturas sin disputas para cuantificar el impacto de las disputas en el flujo de caja. Es un atributo útil para crear Dashboards de alto nivel y realizar comparativas. Por qué es importante Simplifica el análisis y el filtrado al permitir comparar fácilmente las poblaciones de facturas en disputa y sin disputa. Dónde obtenerlo Es un campo calculado. La lógica es: IF el caso contiene una actividad «Disputa registrada» THEN true ELSE false. Ejemplos truefalse
	Límite de crédito CreditLimit	El importe máximo de crédito aprobado para el cliente.
Descripción El límite de crédito es el importe total de deuda que un cliente está autorizado a acumular. Este atributo es fundamental para la gestión del riesgo. El panel «Análisis de la gestión de límites de crédito» compara este valor con los importes de las facturas de cuentas en mora o dadas de baja. Este análisis ayuda a determinar si los límites de crédito están establecidos correctamente, si se aplican y si los clientes que incumplen suelen haber recibido aumentos recientes de sus límites, lo que puede revelar debilidades en el proceso de aprobación del crédito. Por qué es importante Esencial para evaluar el riesgo, este atributo ayuda a analizar si las bajas están relacionadas con límites de crédito de clientes mal gestionados o insuficientes. Dónde obtenerlo Normalmente, este valor se almacena en el registro maestro del cliente, en «CustTable». Ejemplos 10000.0050000.000.00
	Motivo de la disputa DisputeReason	El motivo que proporciona el cliente para disputar una factura.
Descripción Cuando un cliente disputa una factura, normalmente proporciona un motivo, como «Precio incorrecto», «Mercancía dañada» o «Facturación duplicada». Este atributo registra ese motivo. Analizar los motivos de las disputas es fundamental para el análisis de causas raíz. Ayuda a identificar problemas recurrentes en el proceso de pedido a efectivo, como incidencias en los departamentos de ventas, envíos o facturación. Reducir las disputas desde el origen es un resultado clave de este análisis y afecta directamente al DSO al evitar retrasos en los pagos. Por qué es importante Proporciona datos fundamentales para analizar las causas raíz de los retrasos en los pagos y ayuda a identificar y corregir problemas anteriores que provocan disputas de facturas. Dónde obtenerlo Consultar la documentación de Microsoft Dynamics 365. Este dato formaría parte de la funcionalidad de gestión de disputas o de casos. Ejemplos Error de precioCantidad insuficienteProducto no recibidoServicio no conforme con la descripción
	País Country	El país de la dirección de facturación del cliente.
Descripción Este atributo especifica el país asociado a la cuenta del cliente. Es una dimensión habitual para el análisis geográfico. Segmentar los KPI del proceso, como el DSO o las tasas de baja, por país puede revelar diferencias regionales en el comportamiento de pago de los clientes, la eficacia de los cobros o las condiciones económicas. Esto puede dar lugar a estrategias de cobro adaptadas a cada región o a condiciones de pago diferentes para determinadas zonas. Por qué es importante Permite realizar análisis geográficos para identificar tendencias regionales en el comportamiento de pago y el rendimiento del proceso de cobro. Dónde obtenerlo Se obtiene uniendo el registro maestro del cliente («CustTable») con su registro de dirección principal, normalmente en «LogisticsPostalAddress». Ejemplos USADEUGBRCAN
	Sistema de origen SourceSystem	Identifica el sistema del que proceden los datos.
Descripción Este atributo especifica la aplicación de origen en la que se registraron los datos del evento. En este contexto, sería «Microsoft Dynamics 365». Aunque pueda parecer estático en un análisis de un solo sistema, es fundamental para la gobernanza de datos, la resolución de problemas y futuras integraciones. Si se incluyeran datos de otros sistemas, como un CRM independiente o el portal de una agencia de cobro, este campo sería esencial para distinguirlos y comprender el proceso completo entre sistemas. Por qué es importante Proporciona una trazabilidad clara de los datos y es esencial para mantener su calidad y permitir el análisis en varios sistemas integrados. Dónde obtenerlo Normalmente, es un valor estático que se añade durante la extracción de datos para indicar el origen de los registros. Ejemplos Microsoft Dynamics 365D365 F&O
	Tiempo de resolución de la disputa DisputeResolutionTime	El tiempo necesario para resolver una disputa del cliente desde el momento en que se registró por primera vez.
Descripción El tiempo de resolución de la disputa mide la eficiencia del proceso de gestión de disputas. Se calcula como la duración entre las actividades «Disputa registrada» y «Disputa resuelta». Los tiempos de resolución prolongados pueden retrasar el pago y afectar negativamente a la satisfacción del cliente. Analizar esta métrica, segmentada por persona gestora de cobro o motivo de disputa, ayuda a identificar cuellos de botella y áreas de mejora en el flujo de trabajo de gestión de disputas. Por qué es importante Mide la eficiencia del proceso de gestión de disputas, una causa habitual de retrasos importantes en los pagos. Dónde obtenerlo Se calcula como la duración entre las marcas de tiempo de las actividades «Disputa registrada» y «Disputa resuelta». Ejemplos 7.215.83.5
	Última actualización de datos LastDataUpdate	La marca de tiempo de la última actualización o carga de datos.
Descripción Este atributo indica la última vez que se actualizó el conjunto de datos desde el sistema de origen. Es un elemento de metadatos fundamental para quienes utilizan el análisis de Process Mining, ya que proporciona contexto sobre la actualidad de los datos. Saber que los datos están actualizados hasta un momento concreto ayuda a los analistas a tomar decisiones fundamentadas y a comprender el alcance de sus conclusiones. Normalmente, se aplica a todo el conjunto de datos durante el proceso de ingesta. Por qué es importante Informa sobre la actualidad de los datos, garantiza que los análisis se basen en un periodo conocido y evita tomar decisiones a partir de información obsoleta. Dónde obtenerlo Este valor lo genera y registra en el conjunto de datos la canalización de ETL o de datos en el momento de la ejecución. Ejemplos 2023-04-01T02:00:00Z2023-04-02T02:00:00Z

Obligatorio Recomendado Opcional

Actividades de gestión de crédito y cobros

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir con precisión su Workflow de gestión de crédito y cobros.

9 Recomendado 3 Opcional

	Actividad	Descripción
	Carta de gestión de cobros generada	Indica que se ha creado una carta formal de gestión de cobros para la factura vencida. Se registra cuando se ejecuta el proceso periódico de gestión de cobros en Dynamics 365, que genera registros de cartas para las facturas correspondientes.
Por qué es importante Registra el inicio y la frecuencia de las acciones formales de cobro. Es esencial para medir la eficacia de la gestión de cobros y el cumplimiento de las políticas internas de cobro. Dónde obtenerlo Se crea un registro explícito en la tabla de historial de gestión de cobros (CustCollectionLetterJour). La fecha de creación del diario de la carta de gestión de cobros es la marca de tiempo. Recopilar Extraiga los eventos de creación de la tabla CustCollectionLetterJour y vincúlelos con la factura. Tipo de evento explicit
	Disputa registrada	Indica que el cliente ha disputado formalmente la factura y que su estado se ha actualizado en consecuencia. Normalmente se captura cuando una persona usuaria cambia el estado de la factura a «Disputed» en el módulo de gestión de cobros.
Por qué es importante Este es el punto de partida del proceso de resolución de disputas. Su seguimiento ayuda a medir la frecuencia de las disputas y el tiempo necesario para resolverlas, lo que influye en la satisfacción del cliente y el flujo de caja. Dónde obtenerlo Se infiere a partir de un cambio de estado en la transacción del cliente (CustTrans) o en una tabla relacionada con la gestión de disputas (smmCaseDetail). Se necesita un registro con marca de tiempo del cambio de estado. Recopilar Identifique cuándo se completa el campo de estado de disputa de una transacción de factura o cuándo cambia a «Disputed». Tipo de evento inferred
	Factura contabilizada y enviada	Representa el registro oficial de la factura en el libro mayor, que la convierte en una cuenta por cobrar formal. Este evento suele coincidir con el envío de la factura al cliente y se registra cuando finaliza la rutina de contabilización en Dynamics 365.
Por qué es importante Este es un hito crítico que inicia oficialmente el cómputo de los plazos de pago y la antigüedad. Las demoras entre la generación y la contabilización pueden ocultar ineficiencias en el proceso de facturación. Dónde obtenerlo Se infiere a partir de la fecha de contabilización del diario de facturas de clientes (CustInvoiceJour) o de un cambio de estado a «Posted». La marca de tiempo de contabilización es el dato clave. Recopilar Utilice la marca de tiempo de contabilización del diario de facturas de clientes (CustInvoiceJour). Tipo de evento inferred
	Factura dada de baja	La factura se considera incobrable y se da de baja formalmente como deuda incobrable. Se trata de una acción explícita realizada por una persona usuaria autorizada, que elimina la cuenta por cobrar y registra la pérdida.
Por qué es importante Este es el principal punto final no satisfactorio del proceso. Hacer un seguimiento de las bajas es fundamental para comprender el riesgo de crédito, los fallos de cobro y las pérdidas financieras. Dónde obtenerlo Se captura a partir de una transacción específica del diario general utilizada para dar de baja una deuda incobrable y vinculada a la factura original. La fecha de registro del diario de baja sirve como marca de tiempo. Recopilar Identificar los asientos del diario con un perfil de registro de baja específico que hagan referencia a la factura. Tipo de evento explicit
	Factura generada	Indica la creación de un registro de factura de venta en el sistema, antes de su contabilización oficial. Esta actividad suele ser un evento explícito que se registra cuando una persona usuaria finaliza un pedido de venta y genera el documento de factura correspondiente.
Por qué es importante Este es el evento inicial principal del ciclo de vida de la factura. Analizar el tiempo transcurrido desde este momento hasta el pago es fundamental para medir los DSO. Dónde obtenerlo Se registra en la tabla de encabezados de facturas de venta (SalesInvoiceHeader) o en la tabla de ventas (SalesTable) al crear la factura. La marca de tiempo de creación del registro sirve como hora del evento. Recopilar Capture la marca de tiempo de creación del registro de la factura de venta. Tipo de evento explicit
	Factura liquidada	La factura se ha pagado por completo y su saldo es cero, lo que marca la finalización satisfactoria del proceso. Este estado se infiere cuando la suma de los pagos aplicados equivale al importe total de la factura.
Por qué es importante Este es el principal punto final satisfactorio del proceso de crédito a efectivo. Analizar las rutas que conducen hasta aquí permite identificar buenas prácticas y variantes eficientes del proceso. Dónde obtenerlo Inferido a partir de la fecha de liquidación de la tabla de liquidaciones de clientes (CustSettlement). Esto ocurre cuando los campos «AmountCur» y «SettleAmountCur» de la factura en CustTrans suman cero. Recopilar Identificar la fecha de liquidación más reciente asociada a la transacción de la factura que deja su saldo en cero. Tipo de evento inferred
	Ha pasado la fecha de vencimiento del pago	Es un evento calculado que ocurre cuando la fecha actual supera la fecha de vencimiento de la factura. Esta actividad no corresponde a una acción directa de una persona usuaria, sino que se obtiene al comparar la fecha del sistema con el campo de fecha de vencimiento de la factura.
Por qué es importante Este evento activa todas las actividades de cobro. Permite analizar el volumen de facturas vencidas y la puntualidad de las acciones de gestión de cobros, y respalda KPI como el cumplimiento de la política de gestión de cobros. Dónde obtenerlo Se calcula comparando la marca de tiempo actual con el campo «DueDate» de la tabla de transacciones de clientes (CustTrans). La marca de tiempo del evento es la propia DueDate. Recopilar Cree un evento cuando «NOW()» sea posterior a la DueDate de la factura. Tipo de evento calculated
	Pago recibido	Indica que se ha recibido un pago de un cliente y se ha registrado en el sistema, normalmente mediante un diario de pagos. Este evento precede al registro final y la aplicación del efectivo a la factura específica.
Por qué es importante Este es un hito crucial para calcular el DSO y comprender el flujo de efectivo. El intervalo entre este evento y Payment Posted revela cuellos de botella en el proceso de aplicación de efectivo. Dónde obtenerlo Evento explícito capturado a partir de la fecha de creación de una línea del diario de pagos del cliente (LedgerJournalTrans), antes de su registro. Representa la fecha en que se registró la recepción del pago. Recopilar Utilizar la fecha de transacción de las líneas del diario de pagos del cliente. Tipo de evento explicit
	Pago registrado	Representa el registro oficial del pago del cliente en el libro mayor y su aplicación para liquidar una factura. Se captura a partir de la fecha de registro del diario de pagos del cliente.
Por qué es importante Finaliza la parte de pagos del proceso. El tiempo entre la recepción y el registro del pago, es decir, el retraso en la aplicación de efectivo, es una métrica clave de eficiencia para el departamento financiero. Dónde obtenerlo Se captura a partir de la marca de tiempo de registro del diario de pagos del cliente (LedgerJournalTrans). Esto confirma que el pago se ha procesado por completo en el libro mayor. Recopilar Utilizar la fecha de registro del diario de pagos del cliente registrado. Tipo de evento explicit
	Actividad de cobro registrada	Representa una acción manual de cobro, como una llamada telefónica o un correo electrónico, registrada para el cliente o la factura. Se captura cuando un gestor de cobro utiliza la función Activities del espacio de trabajo de cobros para registrar sus interacciones.
Por qué es importante Ofrece visibilidad del esfuerzo manual del equipo de cobros. Analizar estas actividades junto con el éxito de los pagos ayuda a medir la productividad del equipo y la eficacia de los distintos métodos de contacto. Dónde obtenerlo Se registra en Activities (smmActivities) o en las tablas relacionadas con la gestión de casos asociadas a la cuenta del cliente. Si es posible, es necesario vincular la actividad con una factura concreta. Recopilar Capture la creación de registros de Activity cuyo tipo sea «Phone Call» o «Email» y estén relacionados con el cobro. Tipo de evento explicit
	Disputa resuelta	Marca la conclusión del proceso de disputa, cuando se ha alcanzado y documentado una resolución. Este evento se captura cuando una persona usuaria actualiza el estado de disputa de una factura a «Resolved» o cierra el caso de disputa asociado.
Por qué es importante Esta actividad concluye el subproceso de disputa. La duración entre el registro y la resolución de la disputa es un KPI clave para medir la eficiencia del equipo de resolución. Dónde obtenerlo Inferido a partir de un cambio de estado en la transacción del cliente (CustTrans) o cuando se cierra el caso de disputa relacionado (smmCaseDetail). La marca de tiempo de este cambio de estado es la hora del evento. Recopilar Identificar cuándo se borra el campo de estado de disputa de una factura o cambia a «Resuelta». Tipo de evento inferred
	Promesa de pago creada	Un cliente se ha comprometido a realizar un pago en una fecha futura concreta y la promesa queda registrada en el sistema. Este evento se registra explícitamente cuando un agente de cobros introduce los detalles de una promesa de pago en el módulo de cobros.
Por qué es importante Registra los acuerdos informales de pago y sus tasas de cumplimiento. Comparar las promesas con los pagos reales puede ayudar a prever el flujo de caja y evaluar la fiabilidad de los clientes. Dónde obtenerlo Probablemente se registra en tablas relacionadas con el espacio de trabajo de cobros o la gestión de casos, específicamente para la funcionalidad de promesas de pago. La fecha de creación del registro de la promesa es la hora del evento. Recopilar Capture los eventos de creación de una tabla de detalles de promesas de pago o de casos de cobro. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Microsoft Dynamics 365

Pasos

Verifique los requisitos previos: Asegúrese de que su organización dispone de Microsoft Dynamics 365 Finance y de que la función Bring Your Own Database (BYOD) está configurada y exporta activamente entidades de datos a una base de datos Azure SQL. Debe disponer de credenciales con acceso de lectura a esta base de datos Azure SQL.
Identifique las entidades de datos: Confirme que las entidades de datos necesarias se exportan desde Dynamics 365 a su BYOD. Entre las entidades principales de este proceso se incluyen: CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment y CustDispute. Si falta alguna, configúrela para su exportación en el área de trabajo Gestión de datos de Dynamics 365.
Conéctese a la base de datos BYOD: Utilice un cliente SQL, como SQL Server Management Studio (SSMS) o Azure Data Studio, para conectarse a la base de datos Azure SQL que actúa como destino de BYOD.
Prepare la consulta SQL: Copie en su cliente SQL la consulta T-SQL completa incluida en la sección query de este documento. Esta consulta está diseñada para reunir todas las actividades y atributos obligatorios en un único formato de registro de eventos.
Establezca los parámetros de la consulta: Localice los marcadores de posición situados al principio de la consulta. Sustituya '{CompanyCode}' por el ID de la entidad jurídica de Dynamics 365 que desea analizar, por ejemplo, «USMF». Sustituya '{StartDate}' y '{EndDate}' por el intervalo de fechas deseado, con el formato «YYYY-MM-DD».
Ejecute la consulta: Ejecute la consulta modificada en la base de datos BYOD. El tiempo de ejecución variará según el volumen de datos del intervalo seleccionado.
Revise los resultados: Cuando finalice la consulta, el panel de resultados mostrará el registro de eventos. Cada fila representa una actividad concreta del ciclo de vida de crédito y cobros de una factura. Revise los datos para comprobar que estén completos y sean correctos.
Exporte el registro de eventos: Exporte los resultados de la consulta a un archivo CSV. La mayoría de los clientes SQL incluyen una función integrada para exportar los resultados. Haga clic con el botón derecho en la cuadrícula de resultados y busque una opción como «Guardar resultados como» o «Exportar».
Prepare la carga: Asegúrese de que el archivo CSV exportado utilice codificación UTF-8 y que los encabezados de columna coincidan con los atributos obligatorios: InvoiceNumber, ActivityName, EventTime y cualquier atributo recomendado que haya incluido. El archivo ya está listo para cargarlo en ProcessMind.

Configuración

Requisitos previos: Acceso a una instancia de Microsoft Dynamics 365 for Finance con la función Bring Your Own Database (BYOD) configurada y en funcionamiento. Se requieren permisos de lectura para la base de datos Azure SQL de destino.
Entidades de datos: La extracción depende de que varias entidades de datos estándar se exporten a BYOD. Como mínimo, asegúrese de incluir CustInvoiceJour, CustTrans, CustTable y CustSettlement en el trabajo de exportación de BYOD. Se necesitan entidades adicionales, como CustCollectionLetterJour, para actividades específicas.
Intervalo de fechas: Es fundamental filtrar la consulta por un intervalo de fechas concreto para controlar el rendimiento. Para el análisis inicial se recomienda un periodo de entre 3 y 6 meses. La consulta proporcionada utiliza los marcadores '{StartDate}' y '{EndDate}' con este fin.
Filtro de empresa: La consulta debe filtrarse por una entidad jurídica específica, es decir, el código de empresa, para garantizar la coherencia de los datos. Utilice el marcador '{CompanyCode}' para indicar la empresa que desea analizar.
Consideraciones de rendimiento: En conjuntos de datos muy grandes que abarcan varios años o empresas, el tiempo de ejecución de la consulta puede ser considerable. Considere ejecutarla fuera de las horas punta o aplicar filtros adicionales para limitar el alcance de los datos. Compruebe que las tablas BYOD tengan índices adecuados en las columnas de fecha y en las columnas clave.

a Consulta de ejemplo 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.

Pasos

Requisitos previos y configuración del entorno: Asegúrese de tener instalada la versión 3.8 o posterior de Python. Instale las bibliotecas necesarias mediante pip: pip install pandas requests msal. También necesitará las credenciales de una entidad de servicio con acceso al entorno de Dynamics 365.
Registre la aplicación en Azure AD: Vaya al portal de Azure Active Directory. Registre una aplicación nueva para obtener un ID de cliente y un ID de inquilino. Cree un secreto de cliente nuevo en la sección «Certificados y secretos» de la aplicación. Guarde de forma segura el ID de cliente, el ID de inquilino y el secreto de cliente.
Conceda permisos de API: En la configuración «Permisos de API» de la aplicación registrada en Azure AD, añada un permiso. Seleccione «Dynamics ERP» o una entrada similar para Dynamics 365 y conceda el permiso delegado user_impersonation. Conceda el consentimiento del administrador para su organización.
Cree un usuario de Dynamics 365: Cree un usuario de aplicación específico en Dynamics 365 Finance and Operations. Asocie este usuario al ID de cliente de su aplicación de Azure AD. Asigne al usuario un rol de seguridad con permisos de lectura para todas las entidades de datos necesarias, como CustInvoiceJour, CustCollectionLetterJour, CustSettlements y smmActivities.
Configure el script de Python: Copie el script de Python proporcionado en un archivo, por ejemplo, extract_d365_collections.py. Complete las variables de marcador de posición situadas al principio del script con la URL de su entorno D365, el ID de inquilino, el ID de cliente, el secreto de cliente y la empresa predeterminada (dataAreaId).
Establezca los parámetros de extracción: Ajuste las variables start_date y end_date del script para definir el periodo de extracción. Para el análisis inicial se recomienda un periodo de entre 3 y 6 meses.
Ejecute el script: Ejecute el script desde el terminal con el comando python extract_d365_collections.py. El script se autenticará, consultará los endpoints OData de las 12 actividades y gestionará automáticamente la paginación de la API.
Obtenga los datos de cada actividad: El script realiza llamadas secuenciales a la API para obtener datos de generación de facturas, contabilización, gestión de cobro, pagos y otros eventos clave. Cada consulta se dirige a una entidad de datos específica y selecciona únicamente los campos necesarios para optimizar el rendimiento.
Transforme y combine los datos: El script utiliza la biblioteca pandas para procesar la respuesta JSON de cada llamada a la API. Transforma los datos en una tabla estructurada, estandariza los nombres de las columnas y combina los datos de todas las actividades en un único registro de eventos.
Calcule los eventos derivados: La actividad «Payment Due Date Passed» no es un registro directo del sistema. El script calcula este evento recorriendo todas las facturas vencidas dentro del intervalo especificado y generando una fila correspondiente para cada una.
Exporte el registro de eventos: Cuando se hayan procesado y combinado todos los datos, el script guardará el registro de eventos final como un archivo CSV llamado d365_collections_event_log.csv en el mismo directorio. El archivo tendrá el formato adecuado y estará listo para cargarlo en una herramienta de Process Mining.

Configuración

URL del endpoint de la API: La URL base de su entorno de Dynamics 365 Finance and Operations. Debe proporcionarse con el formato https://[your-environment-name].operations.dynamics.com.
Credenciales de autenticación: El script requiere un ID de inquilino, un ID de cliente y un secreto de cliente procedentes del registro de una aplicación de Azure Active Directory. Esta aplicación debe tener permisos para acceder a la API de Dynamics 365.
Filtro de empresa (dataAreaId): Dynamics 365 es un sistema multiempresa. El script está configurado para consultar una empresa específica mediante el filtro dataAreaId. Asegúrese de establecer la variable default_company en la entidad jurídica correcta, por ejemplo, «USMF».
Intervalo de fechas: Los parámetros start_date y end_date controlan el periodo de extracción. Se recomienda comenzar con un periodo reciente de entre 3 y 6 meses para controlar el volumen de datos y garantizar una extracción puntual. El filtro se aplica principalmente a la fecha de creación de la factura.
Consideraciones de rendimiento: La extracción mediante la API OData de conjuntos de datos muy grandes puede tardar y estar sujeta a limitaciones de frecuencia de Microsoft. Si encuentra problemas de rendimiento, considere ejecutar la extracción para intervalos más cortos o fuera de las horas punta.
Requisitos previos: Se requiere un entorno Python 3.8 o posterior con las bibliotecas pandas, requests y msal. El usuario de Dynamics 365 asociado debe tener acceso de lectura a los módulos de gestión financiera, ventas y cobros, concretamente a las entidades mencionadas en el script.

a Consulta de ejemplo 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.")

¿Listo para comenzar?

Utilice esta plantilla para preparar sus datos de forma eficaz y obtener información valiosa sobre sus operaciones de gestión de crédito y cobros. Empiece hoy a optimizar su proceso para acelerar el flujo de caja.

Volver a la guía de mejora Descargar Template

Optimice hoy su gestión de crédito y cobros para acelerar el flujo de caja

Mejore el flujo de caja agilizando el ciclo de crédito a cobro y reduciendo el tiempo del ciclo en un 30 %.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Configuración en minutos.

Su plantilla de datos para la gestión de crédito y cobros

Su plantilla de datos para la gestión de crédito y cobros

Atributos de gestión de crédito y cobros

Actividades de gestión de crédito y cobros

Guías de extracción

Consulta SQL directa mediante Bring Your Own Database (BYOD)

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy su gestión de crédito y cobros para acelerar el flujo de caja

Su plantilla de datos para la gestión de crédito y cobros

Su plantilla de datos para la gestión de crédito y cobros

Atributos de gestión de crédito y cobros

Actividades de gestión de crédito y cobros

Guías de extracción

Consulta SQL directa mediante Bring Your Own Database (BYOD)

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy su gestión de crédito y cobros para acelerar el flujo de caja

Valoramos su privacidad