> Mejora continua de procesos > Pedido a cobro: facturación y emisión de facturas > Microsoft Dynamics 365 > Template de datos

Su Template de datos para el proceso de pedido a cobro: facturación y emisión de facturas

Microsoft Dynamics 365

← Volver a la guía de mejora

Atributos del proceso de pedido a cobro: facturación y emisión de facturas(18) Actividades del proceso de pedido a cobro: facturación y emisión de facturas(12) Guías de extracción(2)

Su Template de datos para el proceso de pedido a cobro: facturación y emisión de facturas

Este Template ofrece una guía clara para recopilar los datos esenciales que necesita para analizar el proceso de pedido a cobro: facturación y emisión de facturas. Incluye los atributos recomendados para el Registro de eventos, las actividades clave que conviene seguir y pautas prácticas para extraer esta información. Está diseñado para ayudarle a preparar rápidamente los datos para el Process Mining.

Atributos recomendados para recopilar
Actividades clave que conviene seguir
Pautas para extraer datos de Microsoft Dynamics 365

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

Descargar Template

Atributos del proceso de pedido a cobro: facturación y emisión de facturas

Estos son los campos de datos recomendados para incluir en el Registro de eventos y realizar un análisis completo del proceso de pedido a cobro: facturación y emisión de facturas.

3 Obligatorio 6 Recomendado 9 Opcional

	Nombre	Descripción
	Número de factura InvoiceNumber	Identificador único de cada factura de cliente, que sirve como identificador principal del caso en el proceso de facturación.
Descripción El número de factura es la clave central que agrupa todas las actividades relacionadas con un mismo documento de facturación. Permite analizar de principio a fin el ciclo de vida de la factura, desde su generación y aprobación hasta el pago del cliente y el cierre final. Al utilizarlo como ID del caso, cada entrada del registro de eventos corresponde a una factura específica, lo que permite analizar las variantes en detalle, calcular los tiempos de ciclo y supervisar el rendimiento de cada transacción de facturación. Por qué es importante Este atributo es esencial para seguir todo el ciclo de vida de una factura y analizar la eficiencia del proceso, los cuellos de botella y las desviaciones de cada documento de facturación. Dónde obtenerlo Suele encontrarse en el módulo de Ventas y marketing, en tablas como CustInvoiceJour (campo InvoiceId), o estar disponible mediante entidades de datos como SalesInvoiceHeaderV2. Ejemplos CIV-001254INV-2023-9876US-004321
	Hora del evento EventTime	Marca de tiempo precisa que indica cuándo tuvo lugar una actividad o un evento específico.
Descripción La hora del evento, también conocida como marca de tiempo, registra la fecha y hora exactas de cada actividad del proceso. Estos datos son fundamentales para todos los análisis de Process Mining basados en el tiempo. Se utilizan para calcular los tiempos de ciclo entre actividades, medir la duración total de un caso y comprender el rendimiento del proceso a lo largo del tiempo. Las marcas de tiempo precisas y fiables son la base de KPI como los días pendientes de cobro y el tiempo de generación de facturas. Por qué es importante Este atributo es la base de todos los análisis de rendimiento y duración, ya que permite calcular los tiempos de ciclo, las duraciones y el rendimiento para medir la eficiencia del proceso. Dónde obtenerlo Las marcas de tiempo se obtienen de distintos campos de fecha y hora en varias tablas de Dynamics 365, como CreatedDateTime en la tabla CustInvoiceJour para la generación de facturas, o de marcas de tiempo específicas del historial del flujo de trabajo. Ejemplos 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Nombre de la actividad ActivityName	Nombre de la actividad empresarial o del evento que tuvo lugar en un momento concreto del ciclo de vida de la factura.
Descripción Este atributo describe un paso o hito específico del proceso de facturación, como «Factura generada», «Factura aprobada» o «Pago recibido del cliente». La secuencia de estas actividades conforma el flujo del proceso. Analizarlas es fundamental para Process Mining, ya que permite descubrir modelos de proceso, identificar variantes y medir el rendimiento entre las distintas etapas. Por qué es importante Define los pasos del proceso y permite visualizar mapas de procesos, analizar variantes e identificar cuellos de botella o desviaciones respecto al procedimiento estándar. Dónde obtenerlo Este atributo suele derivarse de varias fuentes, como los campos de cambio de estado (por ejemplo, DocumentState), la cumplimentación de campos de fecha específicos o los registros del historial del flujo de trabajo en Microsoft Dynamics 365. Ejemplos Factura generadaFactura aprobadaPago recibido del clienteNota de crédito emitida
	Departamento Department	El departamento de la empresa asociado al usuario o a la actividad.
Descripción Este atributo asigna una actividad o un usuario a un departamento específico de la organización, como «Cuentas por cobrar» o «Ventas». Permite obtener una visión del rendimiento del proceso más amplia que la que ofrece el análisis por usuario. El análisis por departamento ayuda a comprender los traspasos entre áreas, comparar la eficiencia de los equipos e identificar cuellos de botella a nivel departamental, como requiere el Dashboard «Carga de actividad del departamento de facturación». Por qué es importante Permite analizar el rendimiento a nivel de la organización, comparar la eficiencia de distintos equipos y comprender cómo afectan al proceso los traspasos entre departamentos. Dónde obtenerlo Por lo general, este dato no se encuentra directamente en la transacción de la factura. Se obtiene al combinar el ID de UserResponsible con el directorio de empleados o usuarios, que contiene la información del departamento. Ejemplos Cuentas por cobrarFinanzasOperaciones de facturación
	Estado de la factura InvoiceStatus	El estado actual de la factura en su ciclo de vida (por ejemplo, abierta, pagada o cancelada).
Descripción Este atributo muestra la situación actual de la factura. Indica si aún está pendiente de pago, si se ha pagado por completo, si está vencida o si se canceló mediante una nota de crédito. Permite filtrar los casos para analizar solo las facturas abiertas o confirmar el resultado final de una factura cerrada. También ayuda a comprender la carga de trabajo actual y la situación financiera de las cuentas por cobrar. Por qué es importante Ofrece una vista rápida del estado actual de la factura, útil para filtrar casos y comprender los resultados de las distintas variantes del proceso. Dónde obtenerlo Puede deducirse del estado de pago de la factura, por ejemplo, comprobando si el saldo del registro CustTrans relacionado es cero. No siempre existe un único campo de «estado». Ejemplos AbiertaPagadaVencidaCancelada
	Fecha de vencimiento del pago PaymentDueDate	La fecha límite en la que se espera que el cliente pague la factura.
Descripción La fecha de vencimiento del pago es un dato clave que se calcula a partir de la fecha de la factura y las condiciones de pago del cliente. Sirve de referencia para medir la puntualidad de los pagos. Este atributo es esencial para el Dashboard «Análisis del cumplimiento de las condiciones de pago» y para calcular KPI como «Porcentaje de pagos puntuales» y «Días pendientes de cobro». Al comparar esta fecha con la fecha real de pago, se puede conocer el comportamiento de pago de los clientes y la eficacia del proceso de cobro. Por qué es importante Es la referencia para medir el rendimiento de los pagos. Resulta esencial para calcular el porcentaje de pagos puntuales y analizar el cumplimiento de las condiciones de pago de los clientes. Dónde obtenerlo Normalmente se encuentra en la tabla CustInvoiceJour, en un campo como DueDate. Ejemplos 2023-05-152023-06-302023-07-01
	Importe de la factura InvoiceAmount	El importe monetario total de la factura.
Descripción Este atributo representa el importe total que se debe pagar por la factura. Es una métrica clave para el análisis financiero, ya que permite segmentar las facturas por importe. Por ejemplo, los analistas pueden centrarse en las facturas de mayor importe para conocer sus patrones de pago o determinar si tardan más en aprobarse. También es fundamental para calcular el importe total de las facturas pendientes y los Días pendientes de cobro. Por qué es importante Permite analizar el impacto financiero y filtrar y segmentar los procesos por importe para priorizar las facturas de mayor valor y comprender cómo se gestionan. Dónde obtenerlo Se encuentra en la tabla CustInvoiceJour, normalmente en un campo como InvoiceAmount. También está disponible en tablas de transacciones relacionadas. Ejemplos 5430.5012500.00750.25
	Nombre del cliente CustomerName	El nombre del cliente al que se emitió la factura.
Descripción El nombre del cliente permite identificar de forma clara a la empresa o persona a la que se factura. En el análisis de Process Mining, permite segmentar el proceso de facturación por cliente. Así se puede saber qué clientes suelen pagar a tiempo, cuáles se retrasan con frecuencia y si determinados grupos de clientes experimentan variaciones o demoras específicas en el proceso. Es fundamental para los Dashboards sobre patrones de pago de clientes y el análisis de los Días pendientes de cobro. Por qué es importante Permite segmentar el análisis del proceso por cliente e identificar comportamientos, patrones de pago o problemas específicos de cada cliente. Dónde obtenerlo Esta información se obtiene al combinar los datos de las facturas con la tabla maestra de clientes, normalmente CustTable, mediante el número de cuenta del cliente. Ejemplos Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Usuario responsable UserResponsible	El usuario o empleado responsable de realizar una actividad específica.
Descripción Este atributo identifica a la persona que realizó una tarea concreta del proceso de facturación, como aprobar una factura o registrar un pago. Es fundamental para analizar la carga de trabajo, comparar el rendimiento e identificar necesidades de formación. Por ejemplo, el Dashboard «Carga de actividad del departamento de facturación» utiliza este atributo para comprobar si el trabajo está bien distribuido o si algunos usuarios se convierten en cuellos de botella. También ayuda a comprender la asignación de recursos y la eficiencia. Por qué es importante Permite analizar los recursos, identificar cuellos de botella, medir el rendimiento individual o del equipo y estudiar cómo se distribuye la carga de trabajo en el departamento de facturación. Dónde obtenerlo Puede obtenerse de los registros del historial del flujo de trabajo (por ejemplo, WorkflowTrackingStatusTable) o de campos de propiedad como Owner o ModifiedBy en las tablas pertinentes. Ejemplos John SmithAlicia BakerAdministrador del sistema
	Condiciones de pago PaymentTerms	Las condiciones acordadas para pagar una factura (por ejemplo, a 30 o 60 días).
Descripción Las condiciones de pago establecen cuándo se espera que el cliente pague una factura. Este atributo se utiliza para calcular la fecha de vencimiento del pago y es una dimensión clave para analizar los patrones de pago. El Dashboard «Análisis del cumplimiento de las condiciones de pago» utiliza este atributo para agrupar clientes y facturas y determinar si ciertas condiciones de pago son más o menos eficaces o se asocian con más retrasos. Por qué es importante Explica por qué una factura vence en una fecha determinada y permite segmentar el análisis para comprobar si ciertas condiciones de pago se relacionan con retrasos. Dónde obtenerlo Normalmente se almacena en el registro maestro del cliente y se copia en el encabezado de la factura. Busque un campo Payment o PaymTermId en la tabla CustInvoiceJour. Ejemplos A 30 díasA 60 díasPagadero al recibir la factura
	Días pendientes de cobro DaysSalesOutstanding	El número de días entre la emisión de la factura y la recepción del pago del cliente.
Descripción Los Días pendientes de cobro (DSO) son una métrica financiera clave que mide el promedio de días que tarda una empresa en cobrar después de realizar una venta. Este atributo calculado determina ese periodo para cada factura. Es la métrica principal del Dashboard «Análisis de tendencias de los días pendientes de cobro» y del KPI «DSO». Analizar los DSO ayuda a gestionar el flujo de caja y evaluar la eficiencia de las funciones de crédito y cobro. Por qué es importante Es un KPI clave para medir la salud del flujo de caja de una empresa y la eficiencia de su proceso de cobro. Cuantifica la rapidez con la que los ingresos se convierten en efectivo. Dónde obtenerlo Este atributo no está disponible en el sistema de origen. Se calcula como el tiempo transcurrido entre la actividad «Factura generada» y la actividad «Pago recibido del cliente». Ejemplos 284592
	Es retrabajo IsRework	Indicador de si el proceso de facturación incluyó actividades de retrabajo, como varias aprobaciones.
Descripción Este atributo booleano calculado identifica las facturas que han pasado por retrabajo. El retrabajo puede definirse como la presencia de varios eventos «Factura aprobada» o de reversiones de pagos. Este atributo está diseñado específicamente para el Dashboard «Análisis del retrabajo de facturas» y el KPI «Tasa de retrabajo de facturas». Al aislar estos casos, los analistas pueden investigar las causas del retrabajo, que suelen estar relacionadas con ineficiencias del proceso, problemas de calidad de los datos o falta de formación. Por qué es importante Este indicador cuantifica directamente las ineficiencias del proceso al identificar casos con acciones repetidas o correctivas, lo que ayuda a localizar las causas del desperdicio y los retrasos. Dónde obtenerlo Este atributo no está disponible en el sistema de origen. Se calcula en la capa de transformación de datos mediante la detección de actividades repetidas o patrones específicos de retrabajo en cada caso. Ejemplos truefalse
	Moneda Currency	El código de moneda del importe de la factura (por ejemplo, USD o EUR).
Descripción Este atributo especifica la moneda en la que está expresado el importe de la factura. Es esencial para las organizaciones multinacionales que operan con distintas monedas. Sin este dato, no tendría sentido sumar ni comparar los importes de las facturas. Permite convertir las monedas correctamente y elaborar informes y análisis financieros precisos en distintas regiones. Por qué es importante Aporta el contexto necesario para interpretar métricas financieras como el importe de la factura, evita sumas incorrectas y permite realizar análisis precisos en entornos con varias monedas. Dónde obtenerlo Se encuentra en la tabla CustInvoiceJour, normalmente en un campo como CurrencyCode. Ejemplos USDEURGBP
	Número de pedido de venta SalesOrderNumber	El identificador del pedido de venta que dio origen a la factura.
Descripción El número de pedido de venta conecta el proceso de facturación con el proceso de ventas anterior. Esta relación es muy útil para realizar un análisis integral de pedido a cobro. Permite investigar cómo los problemas en el proceso de ventas y cumplimiento, como los cambios en los pedidos o los retrasos en los envíos, pueden afectar al ciclo de facturación. Por ejemplo, ayuda a responder preguntas como «¿Tardan más en pagarse las facturas de pedidos de venta complejos?». Por qué es importante Este atributo conecta el proceso de facturación con el proceso de ventas anterior y permite realizar un análisis integral de pedido a cobro para identificar las causas de los problemas de facturación. Dónde obtenerlo Se encuentra en el encabezado o en las líneas de la factura y remite al pedido de venta. Busque un campo como SalesId en la tabla CustInvoiceJour. Ejemplos SO-009876SO-010234US-SO-00543
	Pago puntual IsOnTimePayment	Indicador de si el pago del cliente se recibió en la fecha de vencimiento o antes.
Descripción Este atributo booleano calculado compara la marca de tiempo de «Pago recibido del cliente» con la «Fecha de vencimiento del pago». Indica si cada factura se pagó a tiempo o con retraso. Es el componente principal para calcular el KPI «Porcentaje de pagos puntuales» y se utiliza ampliamente en el Dashboard «Análisis del cumplimiento de las condiciones de pago». Ofrece un resultado claro, con dos opciones, sobre la puntualidad del pago, lo que simplifica el análisis y la elaboración de informes. Por qué es importante Mide directamente si los clientes cumplen las condiciones de pago y sirve de base para el KPI «Porcentaje de pagos puntuales», lo que simplifica el análisis de la eficacia de los cobros. Dónde obtenerlo Este atributo no está disponible en el sistema de origen. Se calcula durante la transformación de los datos comparando la fecha de pago con PaymentDueDate. Ejemplos truefalse
	Requiere intervención manual RequiresManualIntervention	Indicador de si un pago requirió un ajuste manual durante su aplicación.
Descripción Este atributo booleano identifica los pagos que necesitaron intervención o corrección manual durante el proceso de aplicación de pagos. Es clave para el KPI «Tasa de discrepancias en la aplicación de pagos», ya que ayuda a cuantificar la precisión y el nivel de automatización del registro de pagos. Identificar los motivos de la intervención manual, como la falta de información sobre el pago o las discrepancias en los importes, puede impulsar mejoras en el proceso y aumentar la tasa de procesamiento directo. Por qué es importante Este atributo ayuda a identificar obstáculos e imprecisiones en la aplicación de pagos, algo fundamental para mejorar la automatización y reducir el trabajo manual. Dónde obtenerlo Esta información puede deducirse del usuario que registró el pago, si no es un usuario del sistema, o de los códigos de motivo específicos utilizados durante la conciliación de pagos. Consulte la documentación de Microsoft Dynamics 365. Ejemplos truefalse
	Sistema de origen SourceSystem	El sistema del que se extrajeron los datos.
Descripción Este atributo identifica el origen de los datos del proceso. En este caso, indica que los datos proceden de Microsoft Dynamics 365. Esto es importante en entornos con varios sistemas, ya que permite diferenciar las fuentes de datos y mantener clara su trazabilidad, lo que facilita la validación y la resolución de problemas. Por qué es importante Aporta información esencial sobre el origen de los datos, necesaria para la gobernanza y la validación, así como para combinar datos de varios sistemas empresariales. Dónde obtenerlo Es un valor estático que se añade durante la extracción y transformación de los datos para identificar el origen del conjunto de datos. Ejemplos Microsoft Dynamics 365 FinanceD365 F&O
	Última actualización de los datos LastDataUpdate	La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este evento desde el sistema de origen.
Descripción Este atributo registra cuándo se extrajeron o actualizaron por última vez los datos de Microsoft Dynamics 365. Es un campo de metadatos esencial para conocer la actualidad de los datos analizados. Ayuda a analistas y usuarios de negocio a saber si consultan la información más reciente y resulta fundamental para gestionar las actualizaciones de datos y garantizar la fiabilidad del análisis. Por qué es importante Permite conocer la antigüedad de los datos, algo fundamental para la gobernanza, la gestión de las actualizaciones de los Dashboards y la confianza en la actualidad de la información obtenida. Dónde obtenerlo Este atributo se genera y se incorpora al conjunto de datos durante el proceso de extracción, transformación y carga (ETL). Ejemplos 2023-06-20T05:00:00Z2023-06-21T05:00:00Z

Obligatorio Recomendado Opcional

Actividades del proceso de pedido a cobro: facturación y emisión de facturas

Estos son los pasos clave y los hitos del proceso que debe incluir en el Registro de eventos para descubrir y analizar el proceso con precisión.

7 Recomendado 5 Opcional

	Actividad	Descripción
	Factura aprobada	Marca la finalización de la revisión interna y la aprobación formal de la factura. El sistema de flujo de trabajo de Dynamics 365 registra este evento, que indica que la factura está lista para enviarse al cliente.
Por qué es importante Este hito es clave para medir el tiempo de ciclo de aprobación. Las demoras en esta etapa pueden aumentar directamente el tiempo total que tarda el cliente en pagar. Dónde obtenerlo Se registra en las tablas del historial del flujo de trabajo, como WorkflowTrackingStatusTable, como un paso de finalización o aprobación de la instancia del flujo de trabajo de la factura correspondiente. Capturar Extraiga los registros de eventos del flujo de trabajo cuyo estado sea «Aprobado» o «Completado». Tipo de evento explicit
	Factura cerrada	Esta actividad marca el estado final de una factura, cuyo saldo llega a cero tras el pago completo o la liquidación mediante notas de crédito. No corresponde a una transacción directa, sino que se infiere a partir del estado financiero de la factura.
Por qué es importante Este evento indica que el ciclo de pedido a cobro de una factura ha finalizado correctamente. El tiempo que se tarda en llegar a este estado es una medida clave de la eficiencia general del proceso. Dónde obtenerlo Se infiere al comprobar si la transacción de la factura en la tabla CustTrans tiene un saldo pendiente igual a cero. Para determinarlo, se compara el importe de la factura con el importe total liquidado. Capturar Derívelo de los registros de CustTrans en los que AmountCur sea igual a SettleAmountCur. La marca de tiempo corresponde a la fecha de la última liquidación. Tipo de evento inferred
	Factura enviada al cliente	Esta actividad indica el momento en que se envió la factura al cliente, ya sea por medios electrónicos o físicos. En Dynamics 365, puede registrarse como un evento explícito si se envía mediante el correo electrónico del sistema. Si no hay un seguimiento específico, puede inferirse que ocurrió al contabilizar la factura.
Por qué es importante Permite medir la eficiencia del proceso de entrega de facturas. Una demora entre la aprobación y el envío prolonga innecesariamente el ciclo de pago. Dónde obtenerlo Si se utilizan las funciones de correo electrónico de D365, el envío puede registrarse explícitamente en los registros de correo, como SysOutgoingEmailTable. De lo contrario, suele inferirse que ocurrió al mismo tiempo que la contabilización de la factura en CustInvoiceJour. Capturar Utilice la marca de tiempo del registro de correo electrónico, si está disponible; de lo contrario, utilice la marca de tiempo de contabilización de la factura. Tipo de evento inferred
	Factura generada	Representa la creación y contabilización del documento de factura de venta en el sistema. Es una transacción explícita de Dynamics 365 que genera un documento legal y asientos financieros en el submayor de cuentas por cobrar.
Por qué es importante Este evento marca el inicio oficial del ciclo de facturación. Es fundamental para hacer un seguimiento de los días pendientes de cobro (DSO) y de la duración total del proceso. Dónde obtenerlo Se registra a partir de la marca de tiempo de creación del registro de la factura de venta contabilizada en la tabla CustInvoiceJour. Al contabilizarla, se crean las transacciones financieras correspondientes en las tablas GeneralJournalEntry y LedgerEntry. Capturar Utilice el campo CreatedDateTime de la tabla CustInvoiceJour para la factura contabilizada. Tipo de evento explicit
	Fecha de vencimiento alcanzada	Evento calculado que se produce cuando llega la fecha de vencimiento de la factura y aún no se ha aplicado el pago completo. Esta actividad no corresponde a una transacción del sistema, sino que se deriva de los datos existentes.
Por qué es importante Este evento es fundamental para analizar los pagos puntuales e identificar las facturas que empiezan a acumular retrasos. Marca el momento en que pueden iniciarse las gestiones de cobro y reclamación de pagos. Dónde obtenerlo No se registra como evento. Se calcula a partir del campo DueDate de la tabla CustInvoiceJour. La marca de tiempo del evento corresponde a la fecha de vencimiento. Capturar Cree un evento cuya marca de tiempo corresponda al valor del campo CustInvoiceJour.DueDate. Tipo de evento calculated
	Pago aplicado a la factura	Representa la liquidación de un pago del cliente contra una factura específica, lo que reduce el saldo pendiente de esta. En Dynamics 365, es un paso independiente que vincula la transacción del pago con la transacción de la factura.
Por qué es importante Este hito es fundamental para calcular con precisión el DSO y comprender la eficiencia del equipo encargado de aplicar los pagos. Marca el momento en que el pago queda totalmente conciliado con el importe facturado. Dónde obtenerlo Se registra en la tabla CustSettlement. El campo de fecha de liquidación de esta tabla proporciona la marca de tiempo de aplicación de un pago a una transacción de factura específica. Capturar Utilice TransDate o CreatedDateTime de la tabla CustSettlement. Tipo de evento explicit
	Pago recibido del cliente	Esta actividad marca la creación de un asiento de diario para registrar un pago recibido de un cliente. Indica que se ha recibido el dinero, pero que aún no se ha aplicado a una factura específica.
Por qué es importante Este es el punto de partida para medir el tiempo de aplicación del pago. Permite distinguir entre la recepción del dinero y su conciliación con las facturas pendientes. Dónde obtenerlo Se registra a partir de la creación o contabilización de un diario de pagos de clientes. El registro se realiza en tablas como LedgerJournalTrans y, al contabilizarlo, se crea una transacción del cliente en CustTrans. Capturar Utilice la marca de tiempo de contabilización del diario de pagos del cliente en LedgerJournalTable. Tipo de evento explicit
	Factura enviada para aprobación	Esta actividad indica que una factura generada se ha enviado a un flujo de aprobación formal. Es habitual en organizaciones que exigen una revisión de la dirección antes de enviar la factura al cliente. El motor de flujo de trabajo de D365 registra este paso específico.
Por qué es importante Hacer un seguimiento del envío para aprobación permite distinguir el tiempo de creación de la factura del tiempo de espera para su aprobación. Es el primer paso para analizar la eficiencia de los procesos internos de revisión y control. Dónde obtenerlo Se registra en las tablas del historial del flujo de trabajo, como WorkflowTrackingStatusTable, filtrando el evento de envío relacionado con el documento de factura. Capturar Extraiga los registros de eventos del flujo de trabajo cuyo estado sea «Enviado». Tipo de evento explicit
	Nota de crédito emitida	Representa la creación de una nota de crédito, normalmente para corregir un error de facturación, aplicar un ajuste de precio o contabilizar la devolución de productos. En esencia, una nota de crédito es una factura con importe negativo.
Por qué es importante La emisión frecuente de notas de crédito puede indicar problemas sistémicos en el proceso de preparación de pedidos o de facturación. Analizar los motivos de su emisión es clave para mejorar el proceso y reducir las pérdidas de ingresos. Dónde obtenerlo Es una transacción explícita que se registra como una nueva factura contabilizada con un importe negativo en la tabla CustInvoiceJour. A menudo se vincula a la factura original mediante un campo de referencia. Capturar Identifique los registros de CustInvoiceJour cuyo importe total sea negativo y vincúlelos a la factura original. Tipo de evento explicit
	Pago revertido	Esta actividad indica la reversión de un pago de cliente contabilizado anteriormente. Puede deberse a errores de contabilización, fondos insuficientes u otros problemas con el pago.
Por qué es importante Las reversiones de pagos ponen de manifiesto errores operativos o problemas con los pagos de los clientes. Analizar su frecuencia ayuda a identificar las causas de fondo y a mejorar la precisión del proceso de aplicación de pagos. Dónde obtenerlo Se registra como una reversión de transacción en el libro mayor. Una entrada de diario revertida puede identificarse en GeneralJournalEntry, normalmente mediante un indicador específico o su relación con la transacción original. Capturar Identifique los asientos de diario que tengan un indicador de reversión o una referencia a una transacción revertida. Tipo de evento explicit
	Pedido de venta completado	Esta actividad indica que los productos de un pedido de venta se han enviado o que los servicios se han prestado, lo que da inicio al proceso de facturación. En Microsoft Dynamics 365, suele inferirse a partir de la contabilización de un albarán, que modifica el estado de las líneas del pedido de venta correspondiente.
Por qué es importante Este evento marca el inicio de la medición del tiempo de ciclo de generación de facturas. Conocer la demora entre la finalización del pedido y la facturación ayuda a detectar cuellos de botella administrativos que pueden afectar al flujo de caja. Dónde obtenerlo Se infiere a partir de la fecha de creación del asiento del diario del albarán vinculado al pedido de venta. Para ello se utilizan tablas como CustPackingSlipJour y CustPackingSlipTrans, relacionadas con el pedido de venta en el que se basa la factura. Capturar Identifique la fecha de contabilización más reciente del albarán correspondiente al pedido de venta asociado a la factura. Tipo de evento inferred
	Recordatorio de pago enviado	Representa el envío al cliente de una carta de reclamación de pago o un aviso de cobro por una factura vencida. Dynamics 365 cuenta con un proceso formal de reclamación de pagos que genera y registra estas comunicaciones.
Por qué es importante El seguimiento de los recordatorios permite evaluar la eficacia del proceso de reclamación de pagos y analizar cuántos se necesitan antes de recibir el pago. Dónde obtenerlo Es un evento explícito que se registra a partir de la fecha de creación del diario de cartas de cobro en la tabla CustCollectionLetterJour, vinculada a la transacción de la factura vencida. Capturar Utilice la marca de tiempo de creación de la tabla CustCollectionLetterJour. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Microsoft Dynamics 365

Pasos

Vaya al espacio de trabajo de administración de datos: Inicie sesión en Microsoft Dynamics 365 Finance and Operations. Use la barra de búsqueda para encontrar y abrir el espacio de trabajo Data management. Este es el centro desde el que se gestionan todas las operaciones de importación y exportación de datos.
Cree un proyecto de exportación: En el espacio de trabajo Data management, haga clic en el mosaico Export para crear un proyecto de exportación de datos. Asígnele un nombre descriptivo, como ProcessMind_O2C_Billing_Export, y añada una descripción.
Seleccione el formato de destino: En la configuración del proyecto, indique el Target data format. Para que sea compatible con la mayoría de las herramientas de transformación de datos, seleccione CSV. Configure las opciones de formato según sea necesario y asegúrese de usar un delimitador y un calificador de texto habituales.
Añada las entidades de datos necesarias: Este es el paso más importante. Añada al proyecto varias entidades de datos estándar para recopilar todas las actividades necesarias. Para cada entidad, haga clic en Add entity y busque el nombre que aparece en la sección Query/Script. Añada estas entidades: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement y Dunning history letters.
Aplique filtros a las entidades: Para limitar los datos a un ámbito pertinente, aplique filtros a las entidades. Como mínimo, filtre Sales invoice headers V2 por InvoiceDate para un periodo concreto, por ejemplo, los últimos 6 meses. Filtre también por las entidades jurídicas (empresas) que desea analizar.
Ejecute la exportación: Una vez añadidas todas las entidades y aplicados los filtros, haga clic en el botón Export del panel de acciones. El sistema creará un paquete de trabajo y empezará a extraer los datos en segundo plano.
Supervise y descargue los datos: Puede consultar el progreso en la sección Job history. Cuando el trabajo termine correctamente, descargue el paquete de datos exportados. El paquete será un archivo ZIP con un archivo CSV independiente para cada entidad de datos.
Descomprima el paquete: Extraiga el contenido del archivo ZIP descargado en una carpeta local. Obtendrá varios archivos CSV, uno por cada entidad.
Transforme y combine los datos: Debe transformar los archivos sin procesar en un único Registro de eventos. Utilice una herramienta de preparación de datos como Power Query, Python o un área de preparación de una base de datos. Para cada archivo de origen, cree las columnas necesarias: InvoiceNumber (ID del caso), ActivityName (un valor fijo que represente el evento, como 'Invoice Generated') y EventTime (el campo de fecha pertinente del archivo de origen). Asigne también otros atributos, como InvoiceAmount y CustomerName.
Una todos los datos transformados: Combine los datos transformados de todos los archivos de origen en una sola tabla mediante una operación de unión o anexado. Así se crea el Registro de eventos unificado, en el que cada fila representa una actividad del ciclo de vida de la factura.
Dé formato a los datos para cargarlos: Asegúrese de que el archivo CSV final tenga los encabezados de columna correctos (InvoiceNumber, ActivityName, EventTime, etc.) y de que la columna EventTime use un formato de fecha y hora coherente (por ejemplo, YYYY-MM-DD HH:MI:SS). El archivo estará listo para cargarse en ProcessMind.

Configuración

Entidades de datos: La extracción utiliza un conjunto de entidades de datos estándar de D365. Entre las principales se encuentran Sales invoice headers V2 (facturas y notas de crédito), Sales packing slip headers (cumplimiento de pedidos), CustPaymentJournalLineEntity (pagos), Customer settlement (aplicación de cobros) y Workflow tracking status table (aprobaciones).
Formato de exportación: Se recomienda usar CSV como formato de destino por su amplia compatibilidad con las herramientas de transformación de datos.
Filtro por intervalo de fechas: Es fundamental aplicar un filtro de fechas a las entidades principales, especialmente a Sales invoice headers V2 mediante el campo InvoiceDate. Se recomienda un intervalo de 3 a 6 meses para que la exportación sea manejable y, a la vez, contenga datos suficientes para el análisis.
Filtro por empresa: Filtre la exportación por la entidad jurídica o el código de empresa que analiza para mantener la pertinencia de los datos y reducir el tamaño de la exportación.
Preparación y transformación de datos: Después de la extracción, es necesario procesar los datos fuera de Dynamics 365. Combine y reorganice los archivos exportados para crear un único Registro de eventos. Para ello, suelen utilizarse herramientas como Power BI (Power Query), Python o SQL.
Requisitos previos: La persona que ejecute la exportación debe tener asignados los roles de seguridad adecuados en Dynamics 365. Por lo general, se necesita un rol con permisos para acceder al espacio de trabajo Data management y a las entidades de datos requeridas.

Consulta de ejemplo config

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

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

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

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

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

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

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

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

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

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

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

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

Pasos

Requisitos previos: Asegúrese de tener instalado Python 3.6 o una versión posterior, junto con las bibliotecas requests y pandas. También necesitará las credenciales de una entidad de servicio (registro de aplicación) en Azure Active Directory con acceso al entorno de Dynamics 365 Finance & Operations.
Registro de la aplicación: En Azure AD, registre una aplicación nueva. Cree un secreto de cliente y anote el ID de aplicación (cliente), el ID de directorio (inquilino) y el secreto de cliente. En Dynamics 365, añada el ID de la aplicación en System administration > Setup > Azure Active Directory applications y asígnele los permisos de usuario necesarios para leer las entidades de datos requeridas.
Configure el script: Abra el script de Python proporcionado. Complete las variables de configuración al inicio del script, incluidas d365_url, tenant_id, client_id, client_secret, company, start_date y end_date. d365_url debe ser la URL base de su entorno de Dynamics 365, por ejemplo, https://your-d365-instance.operations.dynamics.com.
Autenticación: El script incluye una función get_access_token que utiliza automáticamente sus credenciales para solicitar un token de acceso OAuth2 a la plataforma de identidad de Microsoft. Este token autoriza las llamadas posteriores a la API.
Extracción de datos: Ejecute el script desde la terminal con python your_script_name.py. Primero, el script obtendrá todas las facturas de venta contabilizadas (CustInvoiceJour) dentro del intervalo de fechas especificado. Después, realizará llamadas adicionales a la API para recuperar datos relacionados con actividades como pagos, liquidaciones, notas de crédito y el historial del flujo de trabajo.
Generación de actividades: El script procesa los datos sin procesar de varios endpoints de la API y genera explícitamente una fila para cada una de las 12 actividades requeridas. Por ejemplo, utiliza la entidad CustInvoiceJour para el evento 'Invoice Generated' y consulta la entidad CustSettlement para crear eventos 'Cash Applied to Invoice'.
Eventos calculados: Tenga en cuenta que eventos como 'Payment Due Date Reached' e 'Invoice Closed' no son transacciones directas en Dynamics 365. El script los deduce a partir de la fecha de vencimiento, el estado y el historial de liquidaciones de la factura, y crea las entradas correspondientes en el Registro de eventos.
Gestión de la paginación: La función auxiliar fetch_all_data gestiona la paginación automáticamente. Las API OData de Dynamics 365 devuelven un número limitado de registros por página, por lo que esta función sigue el enlace @odata.nextLink incluido en la respuesta de la API para recuperar el conjunto de datos completo.
Transformación y salida de datos: Una vez recopilados todos los eventos, el script los reúne en una sola lista, la convierte en un DataFrame de pandas y normaliza los nombres de columna a InvoiceNumber, ActivityName, EventTime y otros atributos requeridos.
Exportación a CSV: Por último, el script guarda el DataFrame resultante en un archivo CSV llamado d365_billing_event_log.csv. El archivo queda listo para cargarse en ProcessMind o en otra herramienta de Process Mining.

Configuración

URL de D365: La URL base de su instancia de Dynamics 365 Finance & Operations. Es el endpoint principal para todas las llamadas a la API.
Credenciales de Azure AD: Se necesitan client_id, client_secret y tenant_id para la autenticación. Deben corresponder a una aplicación con acceso de lectura a las entidades pertinentes de D365.
Empresa: Indique el DataAreaId, que corresponde a la entidad jurídica de Dynamics 365 de la que desea extraer datos (por ejemplo, 'USMF').
Intervalo de fechas: Defina start_date y end_date para limitar el alcance de la extracción. Para un análisis inicial, se recomienda un periodo de 3 a 6 meses, que permite obtener datos suficientes sobre las variaciones del proceso sin que el conjunto de datos sea demasiado grande.
Entidades OData clave: El script consulta principalmente las siguientes entidades: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours y WorkflowTrackingStatusTables. Asegúrese de que el usuario configurado tenga permisos de lectura para todas ellas.
Rendimiento: La extracción de datos de un periodo largo o de una empresa muy grande puede tardar, ya que requiere varias llamadas secuenciales a la API. Se recomienda ejecutar el script fuera de las horas de mayor actividad y empezar con un intervalo de fechas más corto para calcular el tiempo total de ejecución.

Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Todo listo para empezar?

Empiece a optimizar la facturación y la emisión de facturas con este Template. Proporcione a su equipo la información que necesita para mejorar la eficiencia y el flujo de caja.

Volver a la guía de mejora

Descargar Template

Ponga fin a los retrasos de facturación: optimice hoy el proceso de pedido a cobro y emisión de facturas

Reduzca un 30 % el tiempo del ciclo de facturación y obtenga claridad financiera más rápido.

Comience su prueba gratuita

No se requiere tarjeta de crédito. Prueba gratuita de 14 días.

Su Template de datos para el proceso de pedido a cobro: facturación y emisión de facturas

Su Template de datos para el proceso de pedido a cobro: facturación y emisión de facturas

Atributos del proceso de pedido a cobro: facturación y emisión de facturas

Actividades del proceso de pedido a cobro: facturación y emisión de facturas

Guías de extracción

Exportación de entidades de datos de Microsoft Dynamics 365

Pasos

Configuración

Consulta de ejemplo config

Script de Python con la API web OData de Dynamics 365

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para empezar?

Ponga fin a los retrasos de facturación: optimice hoy el proceso de pedido a cobro y emisión de facturas