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

Su Template de datos para la gestión del crédito y los cobros

Microsoft Dynamics 365

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

Su Template de datos para la gestión del crédito y los cobros

Este Template ofrece una guía completa para recopilar los datos necesarios para analizar el proceso de gestión del crédito y los cobros. Describe los atributos de datos esenciales, las actividades clave que conviene registrar y recomendaciones prácticas para extraer los datos. Utilice este recurso para agilizar la preparación de los datos y avanzar más rápido con Process Mining.

Atributos recomendados para un análisis completo
Actividades clave del proceso que debe registrar para descubrirlo con precisión
Recomendaciones prácticas para extraer datos de su sistema

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

Descargar Template

Atributos de gestión del crédito y cobros

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar en profundidad el proceso de gestión del crédito y los cobros.

3 Obligatorio 8 Recomendado 8 Opcional

	Nombre	Descripción
	Hora del evento EventTime	Marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específicos.
Descripción La hora del evento es la fecha y hora exactas en que se registró una actividad en el sistema. Es fundamental para Process Mining, ya que proporciona el orden cronológico necesario para crear 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 la hora de los eventos 'Factura generada' y 'Pago recibido' se utiliza para calcular los días pendientes de cobro (DSO), un KPI empresarial clave. 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 del proceso y calcular métricas de rendimiento, como los tiempos de ciclo y las duraciones. Dónde obtenerlo Este atributo se obtiene de distintos campos de fecha y hora de las tablas de D365, como 'CreatedDateTime' en 'CustInvoiceJour' o 'TransDate' en 'CustTrans', según la actividad. Ejemplos 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Nombre de la actividad ActivityName	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 del proceso de gestión de crédito y cobros, como 'Factura generada', 'Carta de cobro enviada' o 'Pago recibido'. Este atributo es fundamental para Process Mining, ya que define los nodos del mapa del proceso. Analizar la secuencia y la frecuencia de estas actividades permite conocer el flujo real del proceso e identificar ciclos de retrabajo, ineficiencias y rutas que no cumplen los estándares. También permite crear todas las visualizaciones del flujo del proceso y calcular el tiempo de ciclo entre sus distintas etapas. Por qué es importante Este atributo define los pasos del mapa del proceso y permite visualizar y analizar el ciclo de vida de la factura. Dónde obtenerlo Normalmente, este atributo se obtiene al asignar nombres de actividad estandarizados a eventos específicos del sistema, cambios de estado o fechas de creación de registros en distintas tablas, como 'CustInvoiceJour', 'CustTrans', 'CustCollectionLetterJour' y 'CustPaymPromise'. Ejemplos Factura contabilizada y enviadaCarta de reclamación generadaDisputa registradaPago recibido
	Número de factura InvoiceNumber	Identificador único de cada factura de cliente, que sirve como identificador principal del caso en 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 contabilización 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 en detalle su ciclo de vida. Al tratar cada factura como un caso independiente, las organizaciones pueden identificar rutas habituales, cuellos de botella y desviaciones del procedimiento estándar. Este atributo es la base para calcular métricas clave, como los días pendientes de cobro, y analizar las variantes del proceso. Por qué es importante Este es el ID del caso esencial que conecta todos los eventos del proceso y permite reconstruir y analizar el ciclo completo desde la factura hasta el cobro. Dónde obtenerlo Normalmente, corresponde al campo 'Invoice' de la tabla 'CustInvoiceJour' de Microsoft Dynamics 365 Finance. Ejemplos INV-0012345CIV-2023-8876SI-9510034
	Días de atraso DaysOverdue	Número de días transcurridos desde la fecha de vencimiento del pago de una factura.
Descripción Los días de atraso son una métrica calculada que mide el tiempo transcurrido desde la fecha de vencimiento del pago de una factura impagada. Se calculan restando la fecha de vencimiento del pago a la fecha actual. Es un indicador clave de rendimiento para el equipo de cobros, ya que ayuda a priorizar las facturas que requieren atención. Es la métrica principal del Dashboard 'Facturas vencidas por segmento' y resulta fundamental para evaluar el estado de las cuentas por cobrar y la eficacia de las gestiones de cobro. Por qué es importante Esta métrica operativa es fundamental para priorizar las gestiones de cobro y medir la gravedad de los retrasos en los pagos. Dónde obtenerlo Es un campo calculado. La lógica es: IF Invoice is unpaid THEN (Today() - PaymentDueDate) ELSE 0. Ejemplos 1532910
	Estado de la factura InvoiceStatus	Estado actual de la factura en su ciclo de vida.
Descripción El estado de la factura muestra en qué punto del proceso se encuentra, por ejemplo, 'Abierta', 'Pagada', 'Impugnada' o 'Dada de baja'. Aunque el registro de actividades ofrece un historial detallado, el estado actual es un atributo útil del caso para filtrar y elaborar informes generales. Permite segmentar rápidamente los datos para centrarse solo en las facturas abiertas y vencidas o analizar las características de todas las facturas dadas de baja. Es una forma sencilla de conocer el estado actual de las cuentas por cobrar. Por qué es importante Permite filtrar y analizar fácilmente las facturas según su estado actual, por ejemplo, centrándose en todos los casos abiertos o impugnados. Dónde obtenerlo Se obtiene del estado de liquidación de las transacciones en la tabla 'CustTrans'. Una transacción abierta no está pagada; una cerrada está liquidada. Ejemplos AbiertaPagadaPagada parcialmenteDada de baja
	Fecha de vencimiento del pago PaymentDueDate	Fecha límite contractual para pagar 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 de referencia para determinar si una factura está vencida y 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 los días de atraso y comprobar el cumplimiento de las políticas de reclamación; por ejemplo, para verificar que se haya enviado un recordatorio dentro de los X días posteriores al vencimiento. Por qué es importante Esta fecha sirve de referencia para medir la puntualidad de los pagos y desencadena todas las actividades relacionadas con los vencimientos y los 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 cobros asignado CollectorAssigned	Nombre del agente de cobros o del miembro del equipo responsable de gestionar la factura vencida.
Descripción Este atributo identifica a la persona responsable de las actividades de cobro de una factura específica. Es fundamental para analizar el rendimiento y la carga de trabajo. Al filtrar el mapa del proceso o los Dashboards por gestor de cobros, los responsables pueden evaluar la productividad individual, comparar estrategias de cobro e identificar oportunidades de formación. Este atributo es una dimensión clave de los Dashboards 'Productividad del equipo de cobros' y 'Tiempo de ciclo de resolución de disputas', ya que permite atribuir los resultados del proceso a personas o equipos concretos. Por qué es importante Permite analizar el rendimiento del equipo de cobros, equilibrar las cargas de trabajo e identificar buenas prácticas al comparar la eficacia de cada gestor. Dónde obtenerlo Consulte 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 del usuario en los registros de clientes o transacciones. Ejemplos John SmithEmily JonesEquipo de cobros A
	Importe de la factura InvoiceAmount	Valor monetario total de la factura.
Descripción El importe de la factura 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 importe y comprobar si las facturas de mayor valor siguen un proceso distinto o sufren retrasos más largos. Este atributo es esencial para los Dashboards 'Bajas de facturas incobrables' y 'Análisis de la gestión de límites de crédito', 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 mayor valor y entender cómo influye el importe de la factura en el comportamiento del proceso. Dónde obtenerlo Probablemente, corresponde al 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 una factura vencida.
Descripción El nivel de reclamación representa la etapa de un procedimiento estructurado, 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 la eficacia de la estrategia de cobro. El Dashboard '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 mejorar sus flujos de trabajo de reclamación para cobrar con mayor eficacia y mantener las relaciones con los clientes. Por qué es importante Es clave para medir la eficacia de la estrategia de reclamación y entender en qué etapa es más probable que paguen los clientes. Dónde obtenerlo Esta información se encontraría en tablas relacionadas con los cobros y las cartas de reclamación, como 'CustCollectionLetterJour'. Ejemplos 123 - FinalAcción legal
	Nombre del cliente CustomerName	Nombre legal del cliente al que se emitió la factura.
Descripción El nombre del cliente identifica al cliente asociado a una factura. Es una dimensión principal para filtrar y segmentar los datos. Analizar el proceso por cliente ayuda a identificar a quienes pagan tarde de forma habitual, presentan disputas o requieren un esfuerzo considerable de cobro. Es un atributo clave para el Dashboard 'Tiempo de ciclo de resolución de disputas' y para analizar en detalle cuentas de clientes específicas. 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 obtiene de 'CustTable' mediante una unión con el número de cuenta del cliente presente en 'CustInvoiceJour'. Ejemplos Contoso Ltd.Adventure WorksFabrikam Inc.
	Segmento de clientes CustomerSegment	Clasificación del cliente según criterios como el tamaño, el sector o la importancia estratégica.
Descripción El segmento de clientes es un atributo categórico que agrupa a los clientes en grupos relevantes, como 'Cuentas estratégicas', 'Pymes' o 'Administración pública'. Esta segmentación es fundamental para el análisis estratégico. Ayuda a responder preguntas como «¿Tienen las cuentas estratégicas menos días pendientes de cobro?» o «¿Son más frecuentes las bajas en algún sector en particular?». Se utiliza directamente en los Dashboards 'Tendencia de los días pendientes de cobro', 'Bajas de facturas incobrables' y 'Facturas vencidas por segmento' para obtener conclusiones generales que van más allá de cada cliente. Por qué es importante Permite analizar grupos de clientes en conjunto, identificar tendencias estratégicas y adaptar las estrategias de cobro a cada segmento. Dónde obtenerlo A menudo, se trata de un campo personalizado o se obtiene de atributos de 'CustTable' (la tabla maestra de clientes). Ejemplos EmpresasMercado medioSector públicoSocio
	Código de moneda CurrencyCode	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, sobre todo para las organizaciones multinacionales. Permite interpretar correctamente los valores financieros y analizar si los ciclos de pago o las incidencias se relacionan con monedas específicas, lo que podría deberse a la complejidad del cambio de divisas o de los pagos internacionales. Por qué es importante Proporciona el contexto necesario para interpretar 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á impugnada IsDisputed	Indicador booleano que señala si una factura se ha impugnado alguna vez.
Descripción Este indicador calculado se establece en true si el caso de una factura contiene una actividad 'Disputa registrada'. Simplifica el análisis, ya que permite filtrar o comparar fácilmente los flujos del proceso de las facturas impugnadas y no impugnadas. Por ejemplo, permite comparar el promedio de días pendientes de cobro de las facturas impugnadas con el de las no impugnadas para cuantificar el impacto de las disputas en el flujo de caja. Es un atributo útil para crear Dashboards generales y realizar análisis comparativos. Por qué es importante Simplifica el análisis y el filtrado, ya que permite comparar fácilmente las facturas impugnadas con las que no lo están. Dónde obtenerlo Es un campo calculado. La lógica es: IF the case contains a 'Dispute Registered' activity THEN true ELSE false. Ejemplos truefalse
	Límite de crédito CreditLimit	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 de riesgos. El Dashboard 'Análisis de la gestión de límites de crédito' compara este valor con los importes de las facturas de cuentas morosas o dadas de baja. El análisis ayuda a determinar si los límites de crédito son adecuados y se aplican correctamente, y si los clientes que incumplen sus pagos suelen haber recibido aumentos recientes de límite. Así se pueden detectar posibles deficiencias en el proceso de aprobación de crédito. Por qué es importante Este atributo es esencial para evaluar el riesgo y ayuda a analizar si las bajas se relacionan con límites de crédito inadecuados o mal gestionados. 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	Motivo que indica el cliente para impugnar una factura.
Descripción Cuando un cliente impugna una factura, normalmente indica 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 encontrar las causas raíz. Ayuda a identificar problemas recurrentes en el proceso de pedido a cobro, como incidencias en los departamentos de ventas, envíos o facturación. Resolver las disputas desde su origen es un resultado clave de este análisis y repercute directamente en los días pendientes de cobro, ya que evita retrasos en los pagos. Por qué es importante Proporciona datos fundamentales para encontrar las causas raíz de los retrasos en los pagos e identificar y resolver problemas anteriores del proceso que provocan disputas sobre las facturas. Dónde obtenerlo Consulte la documentación de Microsoft Dynamics 365. Este dato formaría parte de las funciones de gestión de disputas o de casos. Ejemplos Error de precioCantidad insuficienteProducto no recibidoServicio distinto al descrito
	País Country	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 por país los KPI del proceso, como los días pendientes de cobro o las tasas de bajas, 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 zona geográfica o a distintas condiciones de pago para determinadas regiones. Por qué es importante Permite analizar los datos por zona geográfica e identificar tendencias regionales en el comportamiento de pago y el rendimiento del proceso de cobro. Dónde obtenerlo Se obtiene mediante una unión entre el registro maestro del cliente ('CustTable') y su registro de dirección principal, que suele estar 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 caso, sería 'Microsoft Dynamics 365'. Aunque en un análisis de un solo sistema pueda parecer un dato estático, es fundamental para la gobernanza de datos, la resolución de problemas y las futuras integraciones. Si se incorporaran datos de otros sistemas, como un CRM independiente o un portal de una agencia de cobros, este campo permitiría distinguirlos y entender 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, se añade un valor estático durante la extracción de datos para indicar el origen de los registros. Ejemplos Microsoft Dynamics 365D365 F&O
	Tiempo de resolución de disputas DisputeResolutionTime	Tiempo que se tarda en resolver una disputa de un cliente desde que se registra por primera vez.
Descripción El tiempo de resolución de disputas 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 los pagos y afectar negativamente a la satisfacción del cliente. Analizar esta métrica por gestor de cobros o motivo de disputa ayuda a identificar cuellos de botella y oportunidades 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 frecuente 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	Fecha y hora de la última actualización o carga de datos.
Descripción Este atributo indica cuándo se actualizó por última vez el conjunto de datos desde el sistema de origen. Es un metadato fundamental para quienes analizan los procesos, ya que permite saber qué tan recientes son los datos. Conocer hasta qué fecha están actualizados ayuda a tomar decisiones fundamentadas y a entender el alcance de los resultados. 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, permite entender el periodo que abarcan los análisis y evita tomar decisiones basadas en información desactualizada. Dónde obtenerlo El proceso ETL o de datos genera este valor y lo añade al conjunto de datos durante su ejecución. Ejemplos 2023-04-01T02:00:00Z2023-04-02T02:00:00Z

Obligatorio Recomendado Opcional

Actividades de gestión del crédito y cobros

Estos son los pasos y los hitos clave que conviene registrar en el Registro de eventos para descubrir con precisión el flujo de trabajo de gestión del crédito y los cobros.

9 Recomendado 3 Opcional

	Actividad	Descripción
	Carta de reclamación generada	Indica que se ha creado una carta formal de reclamación o cobro para la factura vencida. Se registra al ejecutar el proceso periódico de reclamación en Dynamics 365, que genera registros de cartas para las facturas correspondientes.
Por qué es importante Permite hacer un seguimiento del inicio y la frecuencia de las gestiones formales de cobro. Es esencial para medir la eficacia de las reclamaciones y el cumplimiento de las políticas internas de cobro. Dónde obtenerlo Se crea un registro explícito en la tabla Dunning History (CustCollectionLetterJour). La fecha de creación del diario de cartas de reclamación es la marca de tiempo. Capturar Extraiga los eventos de creación de la tabla CustCollectionLetterJour y relaciónelos con la factura correspondiente. Tipo de evento explicit
	Disputa registrada	Indica que el cliente ha impugnado formalmente la factura y que su estado se ha actualizado en consecuencia. Normalmente, esto se registra cuando un usuario 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. Hacer un seguimiento permite medir la frecuencia de las disputas y el tiempo que se tarda en resolverlas, factores que afectan a la satisfacción del cliente y al 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 la fecha y hora de cada cambio de estado. Capturar 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 fundamental, ya que marca oficialmente el inicio del plazo de pago y del cálculo de antigüedad. Los retrasos 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 en Customer Invoice Journal (CustInvoiceJour) o de un cambio de estado a «Posted». La marca de tiempo de contabilización es el dato clave. Capturar Utilice la marca de tiempo de contabilización de Customer Invoice Journal (CustInvoiceJour). Tipo de evento inferred
	Factura dada de baja	Se considera que la factura es incobrable y se da de baja formalmente como deuda incobrable. Esta acción explícita la realiza un usuario autorizado, que elimina la cuenta por cobrar y contabiliza la pérdida.
Por qué es importante Este es el principal punto de finalización no satisfactoria del proceso. Hacer un seguimiento de las bajas es fundamental para entender el riesgo crediticio, los fallos en la gestión de cobros y las pérdidas financieras. Dónde obtenerlo Se registra 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 contabilización del diario de bajas sirve como marca de tiempo. Capturar Identifique los asientos del diario que tengan un perfil de contabilización específico para bajas y hagan referencia a la factura. Tipo de evento explicit
	Factura generada	Indica que se ha creado en el sistema un registro de factura de venta, antes de contabilizarlo oficialmente. Esta actividad suele registrarse como un evento explícito cuando un usuario finaliza un pedido de venta y genera el documento de factura correspondiente.
Por qué es importante Este es el evento de inicio principal del ciclo de vida de la factura. Analizar el tiempo transcurrido desde este momento hasta el pago es fundamental para medir los días pendientes de cobro (DSO). Dónde obtenerlo Se registra en la tabla Sales Invoice Header (SalesInvoiceHeader) o Sales Table (SalesTable) al crear la factura. La marca de tiempo de creación del registro sirve como hora del evento. Capturar Capture la marca de tiempo de creación del registro de la factura de venta. Tipo de evento explicit
	Factura liquidada	La factura está pagada en su totalidad 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 de finalización satisfactoria del proceso de crédito a cobro. Analizar las rutas que conducen a este punto permite identificar las mejores prácticas y las variantes más eficientes del proceso. Dónde obtenerlo Se infiere 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. Capturar Identifique la fecha de liquidación más reciente asociada a la transacción de factura que deja su saldo en cero. Tipo de evento inferred
	Pago contabilizado	Representa la contabilización oficial del pago del cliente en el libro mayor y su aplicación para liquidar una factura. Se registra a partir de la fecha de contabilización del diario de pagos de clientes.
Por qué es importante Concluye la parte del proceso correspondiente al pago. El tiempo entre la recepción y la contabilización del pago, es decir, el retraso en la aplicación del efectivo, es una métrica clave de eficiencia para el departamento de finanzas. Dónde obtenerlo Se registra a partir de la fecha y hora de contabilización del diario de pagos de clientes (LedgerJournalTrans). Esto confirma que el pago se ha procesado por completo en el libro mayor. Capturar Utilice la fecha de contabilización del diario de pagos de clientes contabilizado. Tipo de evento explicit
	Pago recibido	Indica que se ha recibido un pago de un cliente y que se ha registrado en el sistema, normalmente mediante un diario de pagos. Este evento precede al registro definitivo y a la aplicación del efectivo a la factura correspondiente.
Por qué es importante Este es un hito fundamental para calcular los días pendientes de cobro y entender el flujo de caja. El tiempo transcurrido entre este evento y el registro del pago permite detectar cuellos de botella en el proceso de aplicación de cobros. Dónde obtenerlo Evento explícito que se registra a partir de la fecha de creación de una línea del diario de pagos de clientes (LedgerJournalTrans), antes de contabilizarla. Representa la fecha en que se registró la recepción del pago. Capturar Utilice la fecha de transacción de las líneas del diario de pagos de clientes. Tipo de evento explicit
	Vencimiento de la fecha límite de pago	Evento calculado que se produce cuando la fecha actual supera la fecha de vencimiento de la factura. No corresponde a una acción directa del usuario, sino que se obtiene al comparar la fecha del sistema con el campo 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 reclamaciones, y sirve de apoyo a KPI como el cumplimiento de las políticas de cobro. Dónde obtenerlo Se calcula comparando la marca de tiempo actual con el campo «DueDate» de la tabla Customer Transactions (CustTrans). La marca de tiempo del evento es la propia DueDate. Capturar Cree un evento cuando «NOW()» sea posterior a DueDate de la factura. Tipo de evento calculated
	Actividad de cobro registrada	Representa una acción manual de cobro, como una llamada telefónica o un correo electrónico, registrada en la cuenta del cliente o en la factura. Se registra cuando un agente de cobros utiliza la función Activities del espacio de trabajo de cobros para anotar sus interacciones.
Por qué es importante Ofrece visibilidad del trabajo manual del equipo de cobros. Analizar estas actividades junto con los pagos recibidos 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 tablas relacionadas con la gestión de casos y asociadas a la cuenta del cliente. Si es posible, vincule la actividad a una factura específica. Capturar Capture la creación de registros de Activity cuyo tipo sea «Phone Call» o «Email» y que estén relacionados con los cobros. Tipo de evento explicit
	Compromiso de pago creado	El cliente se ha comprometido a realizar un pago en una fecha futura concreta y el compromiso queda registrado en el sistema. Este evento se registra explícitamente cuando un agente de cobros introduce los detalles de un compromiso de pago en el módulo de cobros.
Por qué es importante Permite hacer un seguimiento de los acuerdos informales de pago y de su tasa de cumplimiento. Comparar los compromisos con los pagos reales puede ayudar a prever el flujo de caja y evaluar la fiabilidad de los clientes. Dónde obtenerlo Es probable que se registre en tablas relacionadas con el espacio de trabajo de cobros o la gestión de casos, en particular las que corresponden a la función de compromisos de pago. La fecha de creación del registro del compromiso es la hora del evento. Capturar Capture los eventos de creación a partir de una tabla de detalles de casos de promesa de pago o de cobro. Tipo de evento explicit
	Disputa resuelta	Marca el final del proceso de disputa, cuando se ha alcanzado y documentado una resolución. Este evento se registra cuando un usuario 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. El tiempo transcurrido 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 Se infiere a partir de un cambio de estado en la transacción del cliente (CustTrans) o del cierre del caso de disputa relacionado (smmCaseDetail). La fecha y hora de este cambio de estado corresponden a la hora del evento. Capturar Identifique cuándo se borra el campo de estado de disputa de una factura o cuándo cambia a 'Resolved'. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Microsoft Dynamics 365

Pasos

Compruebe los requisitos previos: Asegúrese de que su organización utiliza Microsoft Dynamics 365 Finance y tiene configurada la función Bring Your Own Database (BYOD), con exportación activa de entidades de datos a una base de datos Azure SQL. Necesitará credenciales con acceso de lectura a esta base de datos.
Identifique las entidades de datos: Confirme que las entidades de datos necesarias se exportan desde Dynamics 365 a BYOD. Entre las principales para este proceso se incluyen CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment y CustDispute. Si falta alguna, configúrela para la exportación en el espacio de trabajo Data Management 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 sirve como destino de BYOD.
Prepare la consulta SQL: Copie en su cliente SQL la consulta T-SQL completa que aparece en la sección query de este documento. La consulta reúne las actividades y los atributos necesarios en un único formato de Registro de eventos.
Defina los parámetros de la consulta: Localice los marcadores de posición al principio de la consulta. Sustituya '{CompanyCode}' por el ID de la entidad jurídica de Dynamics 365 que corresponda, 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 dependerá del volumen de datos del intervalo seleccionado.
Revise los resultados: Cuando termine la consulta, el panel de resultados mostrará el Registro de eventos. Cada fila representa una actividad concreta del ciclo de gestión del crédito y los cobros de una factura. Compruebe que los datos 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 para exportar resultados. Haga clic con el botón derecho en la cuadrícula de resultados y busque una opción como «Save Results As» o «Export».
Prepare los datos para cargarlos: Compruebe que el archivo CSV exportado utilice la codificación UTF-8 y que los encabezados de columna coincidan con los atributos requeridos: InvoiceNumber, ActivityName, EventTime y los atributos recomendados que haya incluido. Ya podrá cargar el archivo 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 necesitan permisos de lectura para la base de datos Azure SQL de destino.
Entidades de datos: La extracción requiere que se exporten varias entidades de datos estándar a BYOD. Asegúrese de incluir como mínimo CustInvoiceJour, CustTrans, CustTable y CustSettlement en el trabajo de exportación de BYOD. Para determinadas actividades se necesitan entidades adicionales, como CustCollectionLetterJour.
Intervalo de fechas: Es fundamental filtrar la consulta por un intervalo de fechas específico para controlar el rendimiento. Para el análisis inicial, se recomienda utilizar datos de entre 3 y 6 meses. La consulta proporcionada utiliza los marcadores de posición '{StartDate}' y '{EndDate}' para este fin.
Filtro de empresa: La consulta debe limitarse a una entidad jurídica específica (código de empresa) para garantizar la coherencia de los datos. Utilice el marcador de posición '{CompanyCode}' para indicar la empresa que analiza.
Consideraciones de rendimiento: Las consultas sobre conjuntos de datos muy grandes que abarcan varios años o empresas pueden tardar bastante en ejecutarse. Considere ejecutarlas en horas de menor actividad 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 clave.

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 con 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: Abra el portal de Azure Active Directory. Registre una aplicación nueva para obtener un Client ID y un Tenant ID. Cree un secreto de cliente en la sección «Certificates & secrets» de la aplicación. Guarde de forma segura el Client ID, el Tenant ID y el Client Secret.
Conceda permisos de API: En la configuración «API permissions» de la aplicación registrada en Azure AD, añada un permiso. Seleccione «Dynamics ERP» o una opción similar para Dynamics 365 y conceda el permiso delegado «user_impersonation». Otorgue el consentimiento de administrador para su organización.
Cree un usuario de Dynamics 365: Cree un usuario de aplicación dedicado en Dynamics 365 Finance and Operations. Asócielo al Client ID de su aplicación de Azure AD. Asígnele 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 al principio del script con la URL de su entorno D365, el Tenant ID, el Client ID, el Client Secret y la empresa predeterminada (dataAreaId).
Defina los parámetros de extracción: Ajuste las variables start_date y end_date del script para definir el periodo de extracción de datos. Para el análisis inicial, se recomienda un periodo de entre 3 y 6 meses.
Ejecute el script: Ejecute el script desde la terminal con el comando python extract_d365_collections.py. El script se autenticará, consultará los endpoints de OData para cada una 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 y registro de facturas, reclamaciones de pago, pagos y otros eventos clave. Cada consulta se dirige a una entidad de datos específica y selecciona solo 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. Convierte los datos en una tabla estructurada, normaliza 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 corresponde a un registro directo del sistema. El script calcula este evento recorriendo todas las facturas vencidas dentro del intervalo especificado y generando una fila para cada una.
Exporte el Registro de eventos: Una vez procesados y combinados todos los datos, el script guarda el Registro de eventos final en un archivo CSV llamado d365_collections_event_log.csv, en el mismo directorio. El archivo está listo para cargarse en una herramienta de Process Mining.

Configuración

URL del endpoint de la API: URL base de su entorno Dynamics 365 Finance and Operations. Debe tener el formato https://[your-environment-name].operations.dynamics.com.
Credenciales de autenticación: El script requiere un Tenant ID, un Client ID y un Client Secret de una aplicación registrada en Azure Active Directory. La aplicación debe tener permisos para acceder a la API de Dynamics 365.
Filtro de empresa (dataAreaId): Dynamics 365 admite varias empresas. El script está configurado para consultar una empresa específica mediante el filtro dataAreaId. Asegúrese de que la variable default_company tenga 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 empezar con un periodo reciente de entre 3 y 6 meses para controlar el volumen de datos y completar la extracción a tiempo. El filtro se aplica principalmente a la fecha de creación de la factura.
Consideraciones de rendimiento: La extracción de conjuntos de datos muy grandes mediante la API OData puede tardar bastante y estar sujeta a limitaciones de solicitudes de Microsoft. Si surgen problemas de rendimiento, pruebe con intervalos de fechas más cortos o ejecute la extracción en horas de menor actividad.
Requisitos previos: Se necesita un entorno Python 3.8 o posterior con las bibliotecas pandas, requests y msal. El usuario asociado de Dynamics 365 debe tener acceso de lectura a los módulos de gestión financiera, ventas y cobros, en particular a las entidades mencionadas en el script.

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 empezar?

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

Volver a la guía de mejora

Descargar Template

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

Mejore el flujo de caja al agilizar el ciclo desde el crédito hasta el cobro y reducir el tiempo de ciclo un 30 %.

Comience su prueba gratuita

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

Su Template de datos para la gestión del crédito y los cobros

Su Template de datos para la gestión del crédito y los cobros

Atributos de gestión del crédito y cobros

Actividades de gestión del crédito y cobros

Guías de extracción

Consulta SQL directa mediante Bring Your Own Database (BYOD)

Pasos

Configuración

Consulta de ejemplo sql

Script de Python con la API REST OData de Dynamics 365

Pasos

Configuración

Consulta de ejemplo python

¿Listo para empezar?

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