> Mejora continua de procesos > Order to Cash: facturación y emisión de facturas > Microsoft Dynamics 365 > Template de datos

Su Template de datos de Order-to-Cash: facturación y emisión de facturas

Microsoft Dynamics 365

← Volver a la guía de mejora

Atributos de Order to Cash: facturación y emisión de facturas (18) Actividades de Order to Cash: facturación y emisión de facturas (12) Guías de extracción (2)

Su Template de datos de Order-to-Cash: facturación y emisión de facturas

Esta plantilla ofrece una hoja de ruta clara para recopilar los datos esenciales necesarios para analizar su proceso de Order-to-Cash: facturación y emisión de facturas. Encontrará los atributos recomendados para incluir en su Registro de eventos, las actividades clave que debe seguir y orientación práctica para extraer esta información. Está diseñada para ayudarle a preparar rápidamente sus datos para obtener información útil mediante Process Mining.

Atributos recomendados para recopilar
Actividades clave que debe seguir
Guía de extracción para Microsoft Dynamics 365

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

Descargar Template

Atributos de Order to Cash: facturación y emisión de facturas

Estos son los campos de datos recomendados para incluir en su registro de eventos y realizar un análisis completo de Order to Cash: 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 actúa como identificador principal del caso para el proceso de facturación.
Descripción Invoice Number es la clave central que agrupa todas las actividades relacionadas con un único 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 Case ID, 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 hacer un seguimiento de 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 Normalmente se encuentra en el módulo Sales and marketing, en tablas como CustInvoiceJour, en el campo InvoiceId, o se expone mediante entidades de datos como SalesInvoiceHeaderV2. Ejemplos CIV-001254INV-2023-9876US-004321
	Hora del evento EventTime	Marca de tiempo precisa que indica cuándo se produjo una actividad o evento específico.
Descripción Event Time, 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 de ventas pendientes de cobro y el tiempo de generación de facturas. Por qué es importante Es el Atributo fundamental para todos los análisis de rendimiento y relacionados con el tiempo, ya que permite calcular tiempos de ciclo, duraciones y rendimiento para medir la eficiencia del proceso. Dónde obtenerlo Las marcas de tiempo proceden de distintos campos de fecha y hora de varias tablas de Dynamics 365, como CreatedDateTime en la tabla CustInvoiceJour para la generación de facturas o marcas de tiempo específicas del historial de Workflow. 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 se produjo 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 «Invoice Generated», «Invoice Approved» o «Customer Payment Received». La secuencia de estas actividades forma el flujo del proceso. Analizar las actividades es fundamental para el process mining, ya que permite descubrir modelos de proceso, identificar variantes y medir el rendimiento entre los distintos pasos. Por qué es importante Define los pasos del proceso, lo que permite visualizar mapas de proceso, 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 campos de cambio de estado, por ejemplo DocumentState, campos de fecha específicos que se han rellenado o registros del historial de Workflow en Microsoft Dynamics 365. Ejemplos Factura generadaFactura aprobadaPago del cliente recibidoNota 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 organizativo específico, como «Accounts Receivable» o «Sales». Permite obtener una visión del rendimiento del proceso a un nivel superior al del usuario individual. El análisis por departamento ayuda a comprender las transferencias entre funciones, comparar la eficiencia de los equipos e identificar cuellos de botella a nivel departamental, tal como requiere el panel «Billing Department Activity Load». Por qué es importante Permite analizar el rendimiento a nivel organizativo, comparar la eficiencia entre distintos equipos y comprender cómo afectan al proceso las transferencias entre departamentos. Dónde obtenerlo Normalmente no es un campo directo de la transacción de 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 ofrece una instantánea del estado actual de la factura. Indica si la factura aún está pendiente de pago, se ha pagado por completo, está vencida o se ha cancelado mediante una nota de crédito. Resulta útil para filtrar casos y analizar únicamente 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 visión rápida del estado actual de la factura, lo que resulta útil para filtrar casos y comprender los resultados de las distintas variantes del proceso. Dónde obtenerlo Puede obtenerse a partir del estado de pago de la factura, normalmente comprobando si el saldo del registro CustTrans relacionado es cero. No siempre existe un único campo «status». 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 campo de fecha fundamental que se calcula a partir de la fecha de la factura y las condiciones de pago del cliente. Sirve como referencia para medir la puntualidad de los pagos. Este atributo es esencial para el panel «Payment Terms Adherence Analysis» y para calcular KPI como «On-Time Payment Rate» y «Days Sales Outstanding». Comparar esta fecha con la fecha real de pago permite conocer el comportamiento de pago del cliente 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 del cliente. 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	Valor monetario total de la factura.
Descripción Este Atributo representa el importe total pendiente de pago de la factura. Es una métrica fundamental para el análisis financiero, ya que permite segmentar las facturas por valor. Por ejemplo, los analistas pueden centrarse en las facturas de mayor importe para comprender su comportamiento de pago o identificar si tardan más en aprobarse. También es esencial para calcular el valor total de las facturas pendientes y el DSO. Por qué es importante Permite analizar el impacto financiero, filtrar y segmentar los procesos por valor monetario, priorizar las facturas de mayor importe y comprender su comportamiento específico dentro del proceso. 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	Nombre del cliente al que se emitió la factura.
Descripción El nombre del cliente proporciona un identificador legible para la empresa o la persona a la que se factura. En el análisis de Process Mining, permite segmentar el proceso de facturación por cliente. Esto puede revelar qué clientes pagan sistemáticamente a tiempo, cuáles se retrasan con frecuencia o si determinados grupos de clientes experimentan variaciones o retrasos específicos en el proceso. Es fundamental para los Dashboards relacionados con el comportamiento de pago de los clientes y el análisis de Días pendientes de cobro. Por qué es importante Esto permite segmentar el análisis del proceso por cliente, lo que ayuda a identificar comportamientos específicos, patrones de pago o problemas del proceso asociados a cada cliente. Dónde obtenerlo Esta información se obtiene al combinar los datos de facturas con la tabla de datos maestros de clientes, normalmente CustTable, utilizando como referencia el número de cuenta del cliente. Ejemplos Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Usuario responsable UserResponsible	El usuario o empleado responsable de ejecutar una actividad específica.
Descripción Este atributo identifica a la persona que realizó una tarea concreta en el proceso de facturación, como aprobar una factura o aplicar un pago. Es fundamental para analizar la carga de trabajo, comparar el rendimiento e identificar necesidades de formación. Por ejemplo, el panel «Billing Department Activity Load» utiliza este atributo para comprobar si el trabajo se distribuye de forma equilibrada o si determinados 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 el proceso a nivel de recursos, identificar cuellos de botella, medir el rendimiento individual o del equipo y analizar la distribución de la carga de trabajo en el departamento de facturación. Dónde obtenerlo Puede obtenerse de los registros históricos del Workflow, como WorkflowTrackingStatusTable, o de campos de propiedad como Owner o ModifiedBy en las tablas correspondientes. Ejemplos John SmithAlicia BakerAdministrador del sistema
	Condiciones de pago PaymentTerms	Las condiciones acordadas para pagar una factura, por ejemplo, Net 30 o Net 60.
Descripción Las condiciones de pago definen 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 el comportamiento de pago. El panel «Payment Terms Adherence Analysis» utiliza este atributo para agrupar clientes y facturas y comprobar si determinadas condiciones de pago son más o menos eficaces o están asociadas a una mayor frecuencia de pagos atrasados. Por qué es importante Proporciona contexto sobre el motivo por el que una factura vence en una fecha determinada y permite segmentar el análisis para comprobar si ciertas condiciones de pago se relacionan con pagos atrasados. Dónde obtenerlo Normalmente se almacena en el registro maestro del cliente, pero se copia en la cabecera de la factura. Busque un campo Payment o PaymTermId en la tabla CustInvoiceJour. Ejemplos Neto 30Neto 60Vencimiento contra recepción
	Días de ventas pendientes de cobro DaysSalesOutstanding	El número de días transcurridos entre la generación de la factura y la recepción del pago del cliente.
Descripción Days Sales Outstanding (DSO) es una métrica financiera clave que mide el número medio de días que tarda una empresa en cobrar después de realizar una venta. Este atributo calculado determina esa duración para cada factura. Es la métrica principal del panel «Days Sales Outstanding Trend Analysis» y del KPI «DSO». Analizar el 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 fundamental 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 se encuentra en el sistema de origen. Se calcula como la duración entre la actividad «Invoice Generated» y la actividad «Customer Payment Received». Ejemplos 284592
	Es retrabajo IsRework	Un indicador que señala si el proceso de la factura 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 existencia de varios eventos «Invoice Approved» o de reversiones de pagos. Este atributo está diseñado específicamente para respaldar el panel «Invoice Rework Analysis» y el KPI «Invoice Rework Rate». Al aislar estos casos, los analistas pueden investigar las causas raíz del retrabajo, que suelen apuntar a ineficiencias del proceso, problemas de calidad de datos o carencias de formación. Por qué es importante Este indicador cuantifica directamente la ineficiencia del proceso al identificar casos con acciones repetitivas o correctivas, lo que ayuda a localizar las causas raíz del desperdicio y las demoras. 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 comprobación de actividades repetidas o patrones específicos de retrabajo dentro de un caso. Ejemplos truefalse
	Es un pago puntual IsOnTimePayment	Un indicador que señala 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 «Customer Payment Received» con la «Payment Due Date». Clasifica cada factura como pagada a tiempo o con retraso. Es el componente principal para calcular el KPI «On-Time Payment Rate» y se utiliza ampliamente en el panel «Payment Terms Adherence Analysis». Proporciona un resultado binario claro sobre el rendimiento de los pagos, lo que simplifica el análisis y los informes. Por qué es importante Mide directamente el cumplimiento de las condiciones de pago por parte del cliente y constituye la base del KPI On-Time Payment Rate, lo que simplifica el análisis de la eficacia del proceso de cobro. Dónde obtenerlo Este atributo no se encuentra en el sistema de origen. Se calcula durante la transformación de datos comparando la fecha de pago con PaymentDueDate. Ejemplos truefalse
	Moneda Currency	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á denominado el importe de la factura. Es esencial para las organizaciones multinacionales que trabajan con distintas monedas. Sin este contexto, agregar o comparar importes de facturas no tendría sentido. Permite realizar conversiones de moneda adecuadas y elaborar informes y análisis financieros precisos en distintas regiones. Por qué es importante Proporciona el contexto esencial para cualquier métrica financiera, como Invoice Amount, evita agregaciones incorrectas y permite realizar análisis precisos en entornos multidivisa. 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 originó la factura.
Descripción El número de pedido de venta conecta el proceso de facturación con el proceso de ventas anterior. Esta conexión resulta muy valiosa para realizar un análisis integral de Order-to-Cash. Permite investigar cómo pueden afectar al ciclo de facturación los problemas del proceso de ventas y cumplimiento, como los cambios en los pedidos o las demoras en los envíos. Por ejemplo, ayuda a responder preguntas como «¿Las facturas de pedidos de venta complejos tardan más en pagarse?». 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 más completo de Order-to-Cash para identificar las causas raíz de los problemas de facturación. Dónde obtenerlo Se encuentra en la cabecera de la factura o en los detalles de las líneas y enlaza con el pedido de venta. Busque un campo como SalesId en la tabla CustInvoiceJour. Ejemplos SO-009876SO-010234US-SO-00543
	Requiere intervención manual RequiresManualIntervention	Un indicador que señala si un pago requirió un ajuste manual durante la aplicación del efectivo.
Descripción Este atributo booleano identifica los pagos que necesitaron intervención o corrección manual durante el proceso de aplicación del efectivo. Es fundamental para el KPI «Cash Application Discrepancy Rate», 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 de remesa o las discrepancias en los pagos, puede impulsar mejoras del proceso que aumenten las tasas de procesamiento directo. Por qué es importante Este atributo ayuda a identificar fricciones e imprecisiones en el paso de aplicación del efectivo, algo esencial para mejorar la automatización y reducir el esfuerzo manual. Dónde obtenerlo Esta información puede inferirse a partir del usuario que registró el pago, si no se trata de un usuario del sistema, o de 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	Sistema del que se extrajeron los datos.
Descripción Este Atributo identifica el origen de los datos del proceso. En este contexto, especifica que los datos proceden de Microsoft Dynamics 365. Es importante en entornos con varios sistemas para diferenciar las fuentes de datos y garantizar la trazabilidad, lo que facilita la validación de datos y la resolución de problemas. Por qué es importante Proporciona un contexto esencial sobre el origen de los datos, necesario para la gobernanza y validación de datos y para combinar datos de varios sistemas empresariales. Dónde obtenerlo Es un valor estático que se añade durante el proceso de extracción y transformación de datos para identificar el origen del conjunto de datos. Ejemplos Microsoft Dynamics 365 FinanceD365 F&O
	Última actualización de datos LastDataUpdate	Marca de tiempo que indica la última vez que se actualizaron 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 desde Microsoft Dynamics 365. Es un campo de metadatos fundamental para conocer la actualidad de los datos analizados. Ayuda a analistas y usuarios de negocio a saber si están consultando la información más reciente y resulta esencial para gestionar las programaciones de actualización y garantizar la fiabilidad del análisis. Por qué es importante Garantiza que los usuarios comprendan la actualidad de los datos, algo fundamental para la gobernanza de datos, la gestión de las actualizaciones del Dashboard y la confianza en la vigencia 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 de Order to Cash: facturación y emisión de facturas

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

7 Recomendado 5 Opcional

	Actividad	Descripción
	Efectivo aplicado a la factura	Representa la liquidación de un pago de cliente contra una factura concreta, lo que reduce el saldo pendiente de la factura. Es un paso diferenciado en Dynamics 365 que vincula la transacción de pago con la transacción de la factura.
Por qué es importante Este es un hito fundamental para calcular con precisión el DSO y comprender la eficiencia del equipo de aplicación de efectivo. Marca el momento en que el pago se concilia por completo 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 del momento en que un pago concreto se aplicó a una transacción de factura específica. Recopilar Utilice TransDate o CreatedDateTime de la tabla CustSettlement. Tipo de evento explicit
	Factura aprobada	Marca la finalización del proceso de revisión interna, cuando la factura se aprueba formalmente. Este evento lo registra el sistema de Workflow de Dynamics 365 e indica que la factura está lista para enviarse al cliente.
Por qué es importante Este es un hito clave para medir el tiempo del ciclo de aprobación. Los retrasos en esta etapa pueden aumentar directamente el tiempo total necesario para recibir el pago del cliente. Dónde obtenerlo Se registra en las tablas del historial de Workflow, como WorkflowTrackingStatusTable, como paso de finalización o aprobación de la instancia de Workflow específica de la factura. Recopilar Extraiga los registros de eventos de Workflow cuyo estado sea «Approved» o «Completed». Tipo de evento explicit
	Factura cerrada	Esta actividad marca el estado final de una factura, cuyo saldo es cero porque se ha pagado por completo o se ha liquidado con notas de crédito. No es una transacción directa, sino un estado inferido a partir del estado financiero de la factura.
Por qué es importante Este evento indica la finalización satisfactoria del ciclo Order to Cash para una factura individual. El tiempo necesario para alcanzar este estado es una medida principal de la eficiencia general del proceso. Dónde obtenerlo Se infiere comprobando si la transacción de factura de la tabla CustTrans tiene un saldo restante igual a cero. Esto se determina comparando el importe de la factura con el importe total liquidado contra ella. Recopilar Se deriva de los registros de CustTrans donde AmountCur es igual a SettleAmountCur. La marca de tiempo es la fecha de la última liquidación. Tipo de evento inferred
	Factura enviada al cliente	Esta actividad representa el momento en que la factura se transmite al cliente, por vía electrónica o física. En Dynamics 365, puede ser un evento explícito si se envía mediante el correo electrónico del sistema, o puede inferirse que ocurre en el momento del registro si no se ha activado un seguimiento específico.
Por qué es importante Mide la eficiencia del proceso de entrega de facturas. Un retraso entre la aprobación y el envío de la factura prolonga innecesariamente el ciclo de pago. Dónde obtenerlo Puede capturarse explícitamente en registros de correo electrónico como SysOutgoingEmailTable si se utilizan las capacidades de correo electrónico de D365. De lo contrario, a menudo se infiere que coincide con la hora de registro de la factura en CustInvoiceJour. Recopilar Utilice la marca de tiempo del registro de correo electrónico si está disponible; de lo contrario, utilice la marca de tiempo de registro de la factura. Tipo de evento inferred
	Factura generada	Representa la creación y el registro del documento de factura de venta en el sistema. Se trata de una transacción explícita en Dynamics 365 que crea un documento legal y asientos financieros en el submayor de cuentas por cobrar.
Por qué es importante Este es el inicio oficial del ciclo de facturación de una factura. Es un evento fundamental para hacer un seguimiento de los días de ventas pendientes de cobro (DSO) y de la duración total del proceso. Dónde obtenerlo Se captura a partir de la marca de tiempo de creación del registro de factura de venta registrada en la tabla CustInvoiceJour. Las transacciones financieras correspondientes se crean en las tablas GeneralJournalEntry y LedgerEntry al registrar la factura. Recopilar Utilice el campo CreatedDateTime de la tabla CustInvoiceJour para la factura registrada. Tipo de evento explicit
	Fecha de vencimiento del pago alcanzada	Evento calculado que se produce cuando llega la fecha de vencimiento de la factura sin que se haya aplicado íntegramente ningún pago. 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 las tasas de pago puntual e identificar las facturas que están pasando a estar vencidas. Actúa como punto de activación de las actividades de cobro y gestión de morosidad. Dónde obtenerlo No se registra como evento. Se calcula utilizando el campo DueDate de la tabla CustInvoiceJour. La marca de tiempo del evento es la propia fecha de vencimiento. Recopilar Cree un evento cuya marca de tiempo sea el valor del campo CustInvoiceJour.DueDate. Tipo de evento calculated
	Pago del cliente recibido	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 efectivo, pero que todavía no se ha aplicado a una factura concreta.
Por qué es importante Este es el punto de partida para medir el tiempo de ciclo de la aplicación de efectivo. Permite diferenciar entre recibir el dinero y conciliarlo realmente con las facturas pendientes. Dónde obtenerlo Se captura a partir de la creación o el registro de un diario de pagos de clientes. Se registra en tablas como LedgerJournalTrans, que al registrarse crea una transacción de cliente en CustTrans. Recopilar Utilice la marca de tiempo de registro 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 Workflow formal de aprobación. Es habitual en organizaciones cuyos controles exigen una revisión de la dirección antes de enviar la factura al cliente. Se registra como un paso específico en el motor de Workflow de D365.
Por qué es importante Hacer un seguimiento del envío para aprobación ayuda a separar el tiempo de creación de la factura del tiempo de espera de la aprobación. Es el primer paso para analizar la eficiencia de los procesos internos de revisión y control. Dónde obtenerlo Se captura a partir de las tablas del historial de Workflow, como WorkflowTrackingStatusTable, filtrando el evento de envío relacionado con el documento de factura. Recopilar Extraiga los registros de eventos de Workflow cuyo estado sea «Submitted». Tipo de evento explicit
	Nota de crédito emitida	Representa la creación de una nota de crédito o abono, normalmente para corregir un error de facturación, conceder un ajuste de precio o contabilizar la devolución de productos. Una nota de crédito es, en esencia, una factura negativa.
Por qué es importante La emisión frecuente de notas de crédito puede indicar problemas sistémicos en el proceso de cumplimiento de pedidos o facturación. Analizar por qué se emiten es clave para mejorar el proceso y reducir las fugas de ingresos. Dónde obtenerlo Es una transacción explícita, registrada como una nueva factura registrada con un importe negativo en la tabla CustInvoiceJour. A menudo se vincula a la factura original mediante un campo de referencia. Recopilar Identifique los registros de CustInvoiceJour con un importe total 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 registrado previamente. Puede producirse por errores como un registro incorrecto, fondos insuficientes u otros fallos del 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 raíz y mejorar la precisión del proceso de aplicación de efectivo. Dónde obtenerlo Se captura como una reversión de transacción en el libro mayor. Un diario revertido puede identificarse en GeneralJournalEntry, normalmente mediante un indicador específico o por su relación con la transacción original. Recopilar Identifique los asientos de diario con un indicador de reversión o una referencia a una transacción revertida. Tipo de evento explicit
	Pedido de venta completado	Esta actividad marca el momento en que se han enviado los productos o se han prestado los servicios correspondientes a un pedido de venta, lo que activa el proceso de facturación. Normalmente se infiere a partir del registro de un albarán de preparación o una nota de entrega en Microsoft Dynamics 365, que modifica el estado de las líneas del pedido de venta relacionado.
Por qué es importante Este evento sirve como punto de partida para medir el tiempo del ciclo de generación de facturas. Comprender el retraso entre la finalización del pedido y la facturación ayuda a identificar cuellos de botella administrativos que pueden afectar al flujo de caja. Dónde obtenerlo Se infiere a partir de la fecha de creación de un registro de diario de albarán de preparación vinculado al pedido de venta. Esto implica tablas como CustPackingSlipJour y CustPackingSlipTrans, relacionadas con el pedido de venta en el que se basa la factura. Recopilar Identifique la fecha más reciente de registro del albarán de preparación correspondiente al pedido de venta asociado a la factura. Tipo de evento inferred
	Recordatorio de pago emitido	Representa el envío de una carta de cobro o notificación de cobro a un cliente en relación con una factura vencida. Dynamics 365 cuenta con un proceso formal de gestión de cobros que genera y registra estas comunicaciones.
Por qué es importante Hacer un seguimiento de los recordatorios ayuda a evaluar la eficacia del proceso de cobro. Permite analizar cuántos recordatorios se necesitan antes de recibir un pago. Dónde obtenerlo Es un evento explícito que se captura 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. Recopilar 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 Data Management: Inicie sesión en Microsoft Dynamics 365 Finance and Operations. Utilice la barra de búsqueda para localizar y abrir el espacio de trabajo Data management. Este es el centro principal para todas las operaciones de importación y exportación de datos.
Cree un nuevo proyecto de exportación: En el espacio de trabajo Data management, haga clic en el mosaico Export para crear un nuevo proyecto de exportación de datos. Asigne al proyecto un nombre descriptivo, como ProcessMind_O2C_Billing_Export, y añada una descripción.
Seleccione el formato de datos de destino: En la configuración del proyecto, especifique Target data format. Para garantizar la compatibilidad 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 utilizar un delimitador y un calificador de texto comunes.
Añada las entidades de datos necesarias: Este es el paso más importante. Añadirá varias entidades de datos estándar al proyecto para capturar todas las actividades necesarias. Para cada entidad, haga clic en Add entity y busque el nombre indicado en la sección Query/Script. Añada al proyecto las siguientes 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 alcance relevante, aplique filtros a las entidades. Como mínimo, filtre Sales invoice headers V2 por InvoiceDate para un periodo específico, por ejemplo, los últimos 6 meses. Filtre también por las entidades jurídicas específicas que desea analizar.
Ejecute el trabajo de 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 comenzará a procesar la extracción de datos en segundo plano.
Supervise y descargue los datos: Puede supervisar el progreso del trabajo en la sección Job history. Cuando el trabajo finalice correctamente, podrá descargar el paquete de datos exportado. El paquete será un archivo ZIP que contendrá archivos CSV independientes para cada entidad de datos.
Descomprima el paquete: Extraiga el contenido del archivo ZIP descargado en una carpeta local. Ahora tendrá varios archivos CSV, uno por cada entidad.
Transforme y combine los datos: Los archivos sin procesar deben transformarse 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 (Case ID), ActivityName (un valor fijo que represente el evento, como «Invoice Generated») y EventTime (el campo de fecha correspondiente del archivo de origen). Asigne otros atributos, como InvoiceAmount y CustomerName.
Una todos los datos transformados: Combine los datos transformados de todos los archivos de origen en una única tabla mediante una operación de unión o anexado. Así creará el Registro de eventos final y unificado, en el que cada fila representa una actividad del ciclo de vida de la factura.
Aplique el formato final para la carga: Asegúrese de que el archivo CSV final tenga las cabeceras de columna correctas (InvoiceNumber, ActivityName, EventTime, etc.) y de que la columna EventTime utilice un formato de marca de tiempo coherente, por ejemplo, YYYY-MM-DD HH:MI:SS. El archivo ya estará listo para cargarse en ProcessMind.

Configuración

Entidades de datos: La extracción se basa en un conjunto de entidades de datos estándar de D365. Entre las entidades principales se incluyen Sales invoice headers V2 (para facturas y notas de crédito), Sales packing slip headers (para el cumplimiento de pedidos), CustPaymentJournalLineEntity (para pagos), Customer settlement (para la aplicación del efectivo) y Workflow tracking status table (para aprobaciones).
Formato de exportación: Se recomienda utilizar CSV como formato de datos de destino por su amplia compatibilidad con las herramientas de transformación de datos.
Filtrado por intervalo de fechas: Es fundamental aplicar un filtro de intervalo de fechas a las entidades principales, especialmente a Sales invoice headers V2 en el campo InvoiceDate. Se recomienda un intervalo de 3 a 6 meses para mantener la exportación bajo control y disponer de datos suficientes para el análisis.
Filtrado por empresa: La exportación debe filtrarse por la entidad jurídica o el código de empresa específicos que está analizando, para garantizar la relevancia de los datos y reducir el tamaño de la exportación.
Preparación y transformación de datos: Es necesario realizar un paso de posprocesamiento fuera de Dynamics 365. Los archivos exportados deben combinarse y reorganizarse en un único formato de Registro de eventos. Normalmente se utilizan herramientas como Power BI (Power Query), Python o SQL.
Requisitos previos: El usuario que ejecute la exportación debe tener asignados los roles de seguridad adecuados en Dynamics 365, normalmente un rol con permisos para el espacio de trabajo Data management y acceso a las entidades de datos necesarias.

a 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 (App Registration) en Azure Active Directory a la que se haya concedido acceso al entorno de Dynamics 365 Finance & Operations.
Registro de la aplicación: En Azure AD, registre una nueva aplicación. 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 este ID de aplicación en System administration > Setup > Azure Active Directory applications y asígnele los derechos de usuario adecuados para leer las entidades de datos necesarias.
Configure el script: Abra el script de Python proporcionado. Rellene las variables de configuración situadas al principio 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 contiene 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 es necesario para autorizar las llamadas posteriores a la API.
Extracción de datos: Ejecute el script desde el terminal mediante python your_script_name.py. El script comenzará a obtener todas las facturas de venta registradas (CustInvoiceJour) dentro del intervalo de fechas especificado. A continuación, realizará llamadas adicionales a la API para recuperar datos relacionados con actividades como pagos, liquidaciones, notas de crédito e historial del Workflow.
Generación de actividades: El script procesa los datos sin procesar de varios endpoints de la API. Genera explícitamente una fila para cada una de las 12 actividades necesarias. 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 obtiene estos eventos 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 está diseñada para gestionar automáticamente la paginación. Las API OData de Dynamics 365 devuelven un número limitado de registros por página, por lo que esta función sigue el @odata.nextLink proporcionado en la respuesta de la API para recuperar el conjunto de datos completo.
Transformación y salida de datos: Después de recopilar todos los eventos, el script los compila en una única lista, la convierte en un DataFrame de pandas y estandariza los nombres de las columnas a InvoiceNumber, ActivityName, EventTime y otros atributos necesarios.
Exportación a CSV: Por último, el script guarda el DataFrame resultante en un archivo CSV llamado d365_billing_event_log.csv. El archivo está formateado y 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. Este es el endpoint principal para todas las llamadas a la API.
Credenciales de Azure AD: Se requieren un client_id, un client_secret y un tenant_id para la autenticación. Deben corresponder a una aplicación con acceso de lectura a las entidades de D365 pertinentes.
Empresa: Especifique el DataAreaId, que corresponde a la entidad jurídica de Dynamics 365 desde la que desea extraer datos, por ejemplo, «USMF».
Intervalo de fechas: Defina un start_date y un end_date para limitar el alcance de la extracción. Para un análisis inicial, se recomienda un periodo de 3 a 6 meses, a fin de mantener un volumen de datos manejable y, al mismo tiempo, capturar suficientes variaciones del proceso.
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 estas entidades.
Rendimiento: Extraer datos de un periodo extenso o de una empresa muy grande puede ser lento debido a la naturaleza de las múltiples llamadas secuenciales a la API. Se recomienda ejecutar el script fuera de las horas punta y comenzar con un intervalo de fechas más corto para estimar el tiempo total de ejecución.

a 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()

¿Listo para comenzar?

Comience su camino hacia una facturación y una emisión de facturas optimizadas utilizando esta plantilla. Proporcione a su equipo la información necesaria para impulsar la eficiencia y mejorar el flujo de caja.

Volver a la guía de mejora Descargar Template

Elimine las demoras de facturación: optimice hoy su proceso de Order-to-Cash y emisión de facturas

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

Inicie su prueba gratuita

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

Su Template de datos de Order-to-Cash: facturación y emisión de facturas

Su Template de datos de Order-to-Cash: facturación y emisión de facturas

Atributos de Order to Cash: facturación y emisión de facturas

Actividades de Order to Cash: 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

a Consulta de ejemplo config

Script de Python mediante la API web OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Elimine las demoras de facturación: optimice hoy su proceso de Order-to-Cash y emisión de facturas

Su Template de datos de Order-to-Cash: facturación y emisión de facturas

Su Template de datos de Order-to-Cash: facturación y emisión de facturas

Atributos de Order to Cash: facturación y emisión de facturas

Actividades de Order to Cash: 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

a Consulta de ejemplo config

Script de Python mediante la API web OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Elimine las demoras de facturación: optimice hoy su proceso de Order-to-Cash y emisión de facturas

Valoramos su privacidad