> Mejora Continua de Procesos > Pedido a Cobro Facturación y Emisión de Facturas > Microsoft Dynamics 365 > Plantilla de Datos

Su `Template` de `Datos` para Pedido a Cobro - Facturación y Emisión de Facturas

Microsoft Dynamics 365

← Volver a la Guía de Mejora

Atributos de Pedido a Cobro - Facturación y Emisión de Facturas (18) Actividades de Pedido a Cobro - Facturación y Emisión de Facturas (12) Guías de Extracción (2)

Su `Template` de `Datos` para Pedido a Cobro - Facturación y Emisión de Facturas

Esta `template` proporciona una hoja de ruta clara para recopilar los puntos de `datos` esenciales necesarios para analizar su proceso de Pedido a Cobro - Facturación y Emisión de Facturas. Encontrará `atributos` recomendados para incluir en su `event log`, actividades clave para rastrear, y orientación práctica sobre cómo extraer esta información. Está diseñado para ayudarle a configurar rápidamente sus `datos` para un `Process Mining` perspicaz.

Atributos recomendados para recopilar
Actividades clave para el seguimiento
Guía de extracción para Microsoft Dynamics 365

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de Pedido a Cobro - Facturación y Emisión de Facturas

Estos son los campos de `datos` recomendados para incluir en su `event log` para un análisis exhaustivo de Pedido a Cobro - Facturación y Emisión de Facturas.

3 Requerido 6 Recomendado 9 Opcional

	Nombre	Descripción
	Número de Factura InvoiceNumber	El identificador único para cada factura de cliente, sirviendo como el identificador principal del `case` para el proceso de facturación.
Descripción El "Invoice Number" es la clave central que agrupa todas las actividades relacionadas con un único documento de facturación. Permite un análisis completo, de principio a fin, del ciclo de vida de la factura, desde la generación y aprobación hasta el pago del cliente y el cierre final. Al usar esto como el `Case ID`, cada entrada del `event log` corresponde a una factura específica, lo que permite un análisis detallado de variantes, el cálculo del tiempo de ciclo y el monitoreo del rendimiento para cada transacción de facturación. Por qué es importante Este `atributo` es esencial para rastrear todo el ciclo de vida de una factura, permitiendo el análisis de la eficiencia del proceso, los `bottlenecks` y las desviaciones para cada documento de facturación individual. Dónde obtener Esto se encuentra típicamente en el módulo de Ventas y marketing, dentro de tablas como CustInvoiceJour (campo InvoiceId) o expuesto a través de entidades de `datos` como SalesInvoiceHeaderV2. Ejemplos CIV-001254INV-2023-9876US-004321
	Hora del Evento EventTime	La marca de tiempo precisa que indica cuándo ocurrió una actividad o evento específico.
Descripción `Event Time`, también conocido como `timestamp`, registra la fecha y hora exactas de cada actividad en el proceso. Estos datos son críticos 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 `case` y comprender el rendimiento del proceso a lo largo del tiempo. Los `timestamps` precisos y fiables son la base para KPIs como `Days Sales Outstanding` y `Invoice Generation Time`. Por qué es importante Este es el `atributo` fundamental para todos los análisis de rendimiento y relacionados con el tiempo, permitiendo el cálculo de tiempos de ciclo, duraciones y rendimiento para medir la eficiencia del proceso. Dónde obtener Los `timestamps` se obtienen de varios campos de `fecha` y hora en diferentes tablas de Dynamics 365, como CreatedDateTime en la tabla CustInvoiceJour para la generación de facturas, o `timestamps` específicos del historial de `workflow`. Ejemplos 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Nombre de la Actividad ActivityName	El nombre de la actividad o evento de negocio que ocurrió en un punto específico del ciclo de vida de la factura.
Descripción Este `atributo` describe un paso o hito específico dentro 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 `Process Mining`, ya que permite el descubrimiento de modelos de proceso, la identificación de variantes y la medición del rendimiento entre diferentes pasos. Por qué es importante Define los pasos del proceso, permitiendo la visualización de mapas de proceso, el análisis de variantes de proceso y la identificación de `bottlenecks` o desviaciones del procedimiento estándar. Dónde obtener Este `atributo` se deriva típicamente de múltiples fuentes, como campos de cambio de estado (ej., DocumentState), campos de `fecha` específicos que se rellenan, o registros de historial de `workflow` dentro de Microsoft Dynamics 365. Ejemplos Factura GeneradaFactura AprobadaPago de cliente recibidoNota de Crédito Emitida
	Departamento Department	El departamento de negocio asociado al usuario o a la actividad.
Descripción Este `atributo` asigna una actividad o un usuario a un departamento organizacional específico, como 'Cuentas por Cobrar' o 'Ventas'. Permite una visión de alto nivel del rendimiento del proceso superior al nivel de usuario individual. Analizar por departamento ayuda a comprender las transferencias interfuncionales, comparar la eficiencia entre equipos e identificar `bottlenecks` a nivel de departamento, como lo requiere el `dashboard` 'Billing Department Activity Load'. Por qué es importante Permite el análisis de rendimiento a nivel organizacional, comparando la eficiencia entre diferentes equipos y comprendiendo cómo las transferencias interdepartamentales impactan el proceso. Dónde obtener Esto típicamente no es un campo directo en la transacción de la factura. Se deriva uniendo el ID de UserResponsible con el directorio de empleados o usuarios que contiene información del departamento. Ejemplos Cuentas por CobrarFinanzasBilling Operations
	Estado de la Factura InvoiceStatus	El estado actual de la factura en su ciclo de vida (ej., Abierta, Pagada, Cancelada).
Descripción Este `atributo` proporciona una instantánea del estado actual de la factura. Indica si una factura aún está pendiente de pago, ha sido totalmente pagada, está vencida o ha sido cancelada mediante una nota de crédito. Esto es útil para filtrar `cases` para analizar solo facturas abiertas o para confirmar el resultado final de una factura cerrada. Ayuda a comprender la carga de trabajo actual y el estado financiero de las cuentas por cobrar. Por qué es importante Proporciona una instantánea rápida del estado actual de la factura, lo cual es útil para filtrar `cases` y comprender los resultados de diferentes variantes de proceso. Dónde obtener Esto se puede derivar del estado de pago de la factura, a menudo verificando si el saldo en el registro relacionado de CustTrans es cero. No siempre existe un único campo de 'estado'. Ejemplos AbiertoPagadoVencidoCancelado
	Fecha de Vencimiento de Pago PaymentDueDate	La `fecha` en la que se espera que el cliente pague la factura.
Descripción La "Payment Due Date" es un campo de `fecha` crítico calculado en función de la `fecha` de la factura y las condiciones de pago del cliente. Sirve como línea base para medir la puntualidad del pago. Este `atributo` es esencial para el `dashboard` 'Payment Terms Adherence Analysis' y para calcular KPIs como 'On-Time Payment Rate' y 'Days Sales Outstanding'. Comparar esta `fecha` con la `fecha` de pago real revela el comportamiento de pago del cliente y la efectividad del proceso de cobros. Por qué es importante Este es el punto de referencia para medir el rendimiento de los pagos. Es esencial para calcular las tasas de pago a tiempo y analizar el Cumplimiento de las condiciones de pago del cliente. Dónde obtener Esto se encuentra típicamente en la tabla CustInvoiceJour en un campo como DueDate. Ejemplos 2023-05-152023-06-302023-07-01
	Importe de Factura InvoiceAmount	El valor monetario total de la factura.
Descripción Este `atributo` representa el importe total adeudado en la factura. Es una métrica crítica para el análisis financiero, permitiendo la segmentación de facturas por valor. Por ejemplo, los analistas pueden centrarse en facturas de alto valor para comprender sus comportamientos de pago o identificar si las facturas más grandes enfrentan tiempos de aprobación más largos. También es fundamental para calcular el valor total de las facturas pendientes y para los cálculos de DSO. Por qué es importante Permite el análisis de impacto financiero, lo que le permite filtrar y segmentar procesos por valor monetario para priorizar facturas de alto valor y comprender sus comportamientos de proceso específicos. Dónde obtener Se encuentra en la tabla CustInvoiceJour, típicamente en un campo como InvoiceAmount. También 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 proporciona un identificador legible para humanos para la empresa o el individuo al que se factura. En el análisis de `Process Mining`, esto permite segmentar el proceso de facturación por cliente. Esto puede revelar qué clientes pagan consistentemente a tiempo, cuáles se retrasan con frecuencia, o si ciertos grupos de clientes experimentan variaciones o retrasos únicos en el proceso. Es clave para los `dashboards` relacionados con el comportamiento de pago del cliente y el análisis de Días de Venta Pendientes de Cobro. Por qué es importante Esto permite que el análisis de procesos se segmente por cliente, ayudando a identificar comportamientos específicos del cliente, patrones de pago o problemas de proceso. Dónde obtener Esta información se recupera uniendo los `datos` de la factura con la tabla maestra de `datos` del cliente, típicamente CustTable, basándose en 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 al individuo que realizó una tarea particular en el proceso de facturación, como aprobar una factura o aplicar efectivo. Es crucial para el análisis de la carga de trabajo, la comparación del rendimiento y la identificación de necesidades de capacitación. Por ejemplo, el `dashboard` 'Billing Department Activity Load' se basa en este `atributo` para ver si el trabajo se distribuye uniformemente o si ciertos usuarios son `bottlenecks`. También ayuda a comprender la asignación de recursos y la eficiencia. Por qué es importante Permite el análisis a nivel de recursos, ayudando a identificar `bottlenecks`, 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 obtener Esto puede obtenerse de los registros de historial de `workflow` (ej., WorkflowTrackingStatusTable) o campos de propiedad como Owner o ModifiedBy en tablas relevantes. Ejemplos John SmithAlicia BakerAdministrador del Sistema
	¿Es Retrabajo? IsRework	Un indicador que señala si el proceso de facturación implicó actividades de reelaboración, como múltiples aprobaciones.
Descripción Este es un `atributo` booleano calculado que marca las facturas que han sido objeto de reelaboración. La reelaboración puede definirse como tener múltiples `events` 'Invoice Approved' o reversiones de pagos. Este `atributo` está específicamente diseñado para soportar el `dashboard` 'Invoice Rework Analysis' y el KPI 'Invoice Rework Rate'. Al aislar estos `cases`, los analistas pueden investigar las causas raíz de la reelaboración, que a menudo apuntan a ineficiencias de proceso, problemas de calidad de los `datos` o deficiencias en la capacitación. Por qué es importante Esta bandera cuantifica directamente la ineficiencia del proceso identificando `cases` con acciones repetitivas o correctivas, ayudando a identificar las causas raíz del desperdicio y el retraso. Dónde obtener Este `atributo` no está disponible en el sistema de origen. Se calcula en la capa de transformación de `datos` al verificar actividades repetidas o patrones específicos de reelaboración dentro de un `case`. Ejemplos truefalse
	Condiciones de Pago PaymentTerms	Las condiciones acordadas para el pago de la factura (ej., Net 30, Net 60).
Descripción Las Condiciones de Pago definen las reglas para cuándo se espera que un cliente pague una factura. Este `atributo` se utiliza para calcular la "Payment Due Date" y es una dimensión clave para analizar el comportamiento de pago. El `dashboard` 'Payment Terms Adherence Analysis' utiliza este `atributo` para agrupar clientes y facturas para ver si ciertas condiciones de pago son más o menos efectivas o si están asociadas con mayores tasas de pagos atrasados. Por qué es importante Proporciona contexto sobre por qué una factura vence en una fecha determinada y permite segmentar el análisis para ver si ciertas condiciones de pago se correlacionan con pagos atrasados. Dónde obtener Esto se almacena típicamente en el registro maestro del cliente pero se copia al encabezado de la factura. Busque un campo Payment o PaymTermId en la tabla CustInvoiceJour. Ejemplos Neto 30Neto 60Vencimiento al recibir
	Días de Cobro Pendiente DaysSalesOutstanding	El número de días 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 promedio de días que tarda una empresa en cobrar un pago después de realizar una venta. Este `atributo` calculado computa esta duración para cada factura individual. Es la métrica principal para el `dashboard` 'Days Sales Outstanding Trend Analysis' y el KPI 'DSO'. Analizar el DSO ayuda a gestionar el flujo de caja y a evaluar la eficiencia de la función de crédito y cobros. Por qué es importante Este es un KPI crítico para medir la salud del flujo de caja de una empresa y la eficiencia de su proceso de cobros. Cuantifica la rapidez con la que los ingresos se convierten en efectivo. Dónde obtener Este `atributo` no está en el sistema de origen. Se calcula como la duración entre la actividad 'Invoice Generated' y la actividad 'Customer Payment Received'. Ejemplos 284592
	Moneda Currency	El código de moneda para el importe de la factura (p. ej., USD, EUR).
Descripción Este `atributo` especifica la moneda en la que se denomina el importe de la factura. Es esencial para organizaciones multinacionales que operan con diferentes monedas. Sin este contexto, agregar o comparar importes de facturas no tendría sentido. Permite una conversión de moneda adecuada y una presentación de informes y análisis financieros precisos en diferentes regiones. Por qué es importante Proporciona un contexto esencial para cualquier métrica financiera como "Invoice Amount", evitando agregaciones incorrectas y permitiendo un análisis preciso en entornos de múltiples divisas. Dónde obtener Se encuentra en la tabla CustInvoiceJour, típicamente 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 "Sales Order Number" vincula el proceso de facturación con el proceso de ventas precedente. Esta conexión es invaluable para un análisis más amplio y de principio a fin de `Order-to-Cash`. Permite a los analistas investigar cómo los problemas en el proceso de ventas y cumplimiento, como cambios de pedidos o retrasos en el envío, podrían impactar el ciclo de facturación. Por ejemplo, puede ayudar a responder preguntas como '¿Las facturas de pedidos de venta complejos tardan más en cobrarse?'. Por qué es importante Este `atributo` conecta el proceso de facturación con el proceso de ventas anterior, permitiendo un análisis más completo de `Order-to-Cash` de principio a fin para identificar las causas raíz de los problemas de facturación. Dónde obtener Se encuentra en el encabezado de la factura o en los detalles de la línea, vinculado al pedido de venta. Busque un campo como SalesId en la tabla CustInvoiceJour. Ejemplos SO-009876SO-010234US-SO-00543
	Pago a Tiempo 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 el `timestamp` 'Customer Payment Received' con la 'Payment Due Date'. Marca cada factura como pagada a tiempo o con retraso. Este es el componente central para calcular el KPI 'On-Time Payment Rate' y se utiliza intensamente en el `dashboard` 'Payment Terms Adherence Analysis'. Proporciona un resultado claro y binario para el rendimiento de pago, simplificando el análisis y la elaboración de informes. Por qué es importante Mide directamente la adhesión del cliente a los términos de pago y es la base para el KPI de Tasa de Pago a Tiempo, simplificando el análisis de la efectividad de la cobranza. Dónde obtener Este `atributo` no está en el sistema de origen. Se calcula durante la transformación de `datos` comparando la `fecha` de pago con la "PaymentDueDate". Ejemplos truefalse
	Requiere Intervención Manual RequiresManualIntervention	Un indicador que señala si un pago requirió un ajuste manual durante la aplicación de efectivo.
Descripción Este `atributo` booleano marca los pagos que requirieron intervención manual o corrección durante el proceso de aplicación de efectivo. Esto es clave para el KPI 'Cash Application Discrepancy Rate', ya que ayuda a cuantificar la precisión y el nivel de automatización de la contabilización de pagos. Identificar las razones de la intervención manual, como información de remesa faltante o discrepancias de pago, puede conducir a mejoras de proceso que aumenten las tasas de procesamiento directo. Por qué es importante Este `atributo` ayuda a identificar la fricción del proceso y las inexactitudes en el paso de aplicación de efectivo, lo cual es crucial para mejorar la automatización y reducir el esfuerzo manual. Dónde obtener Esta información podría inferirse del usuario que contabilizó el pago (si no es 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
	Source System SourceSystem	El sistema del cual se extrajo la data.
Descripción Este `atributo` identifica el origen de los `datos` del proceso. En este contexto, especifica que los `datos` provienen de Microsoft Dynamics 365. Esto es importante en entornos multisistema para diferenciar las fuentes de `datos` y asegurar que el linaje de los `datos` sea claro, lo que ayuda en la validación de `datos` y la resolución de problemas. Por qué es importante Proporciona un contexto crucial sobre el origen de los `datos`, lo cual es esencial para la gobernanza de `datos`, la validación y al fusionar `datos` de múltiples sistemas empresariales. Dónde obtener Este es un valor estático agregado durante el proceso de extracción y transformación de datos para etiquetar el origen del conjunto de datos. Ejemplos Microsoft Dynamics 365 FinanceD365 F&O
	Última actualización de datos LastDataUpdate	El `timestamp` 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 los `datos` por última vez de Microsoft Dynamics 365. Es un campo de metadatos crucial para comprender la actualidad de los `datos` que se analizan. Esto ayuda a los analistas y usuarios de negocio a saber si están viendo la información más reciente y es vital para gestionar los programas de actualización de `datos` y asegurar la fiabilidad del análisis. Por qué es importante Asegura que los usuarios comprendan la actualidad de los `datos`, lo cual es fundamental para la gobernanza de `datos`, la gestión de actualización del `dashboard` y la confianza en la puntualidad de los `insights`. Dónde obtener Este `atributo` se genera y se estampa en el conjunto de `datos` durante el proceso de extracción, transformación y carga de `datos` (ETL). Ejemplos 2023-06-20T05:00:00Z2023-06-21T05:00:00Z

Requerido Recomendado Opcional

Actividades de Pedido a Cobro - Facturación y Emisión de Facturas

Estos son los pasos clave del proceso y los hitos a capturar en su Registro de eventos para un descubrimiento y análisis precisos del proceso.

7 Recomendado 5 Opcional

	Actividad	Descripción
	Efectivo Aplicado a Factura	Representa la liquidación de un pago de cliente contra una factura específica, reduciendo el saldo pendiente de la factura. Este es un paso distinto 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 crítico para calcular con precisión el DSO y comprender la eficiencia del equipo de aplicación de efectivo. Marca el punto en que el pago se concilia completamente con lo facturado. Dónde obtener Registrado en la tabla CustSettlement. El campo de `fecha` de liquidación en esta tabla proporciona el `timestamp` de cuándo se aplicó un pago específico a una transacción de factura específica. Capturar Use el TransDate o CreatedDateTime de la tabla CustSettlement. Tipo de evento explicit
	Factura Aprobada	Marca la finalización del proceso de revisión interna, donde la factura es aprobada formalmente. Este `event` es registrado por el sistema de `workflow` de Dynamics 365 y significa que la factura está lista para ser enviada 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 para recibir el pago del cliente. Dónde obtener Registrado en las tablas de historial de `workflow`, como WorkflowTrackingStatusTable, como un paso de finalización o aprobación para la instancia de `workflow` de factura específica. Capturar Extraer `event logs` del `workflow` donde el estado es 'Approved' o 'Completed'. Tipo de evento explicit
	Factura Cerrada	Esta actividad marca el estado final de una factura, donde su saldo es cero ya que ha sido totalmente pagada o liquidada con notas de crédito. Esto no es una transacción directa, sino un estado inferido basado en el estado financiero de la factura.
Por qué es importante Este `event` significa la finalización exitosa del ciclo de Pedido a Cobro para una sola factura. El tiempo que lleva alcanzar este estado es una medida principal de la eficiencia general del proceso. Dónde obtener Se infiere al verificar si la transacción de la factura en la tabla CustTrans tiene un saldo restante de cero. Esto se determina comparando el importe de la factura con el importe total liquidado contra ella. Capturar Derivado de los registros de CustTrans donde AmountCur es igual a SettleAmountCur. La `timestamp` 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 fue transmitida al cliente, ya sea electrónicamente o físicamente. En Dynamics 365, esto puede ser un `event` explícito si se envía por correo electrónico del sistema, o se infiere que ocurre en el momento de la contabilización si no hay seguimiento específico habilitado.
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 extiende innecesariamente el ciclo de pago. Dónde obtener Puede capturarse explícitamente de 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 es el mismo que el tiempo de contabilización de la factura de CustInvoiceJour. Capturar Use el `timestamp` del registro de correo electrónico si está disponible; de lo contrario, use el `timestamp` 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. Esta es 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 vida de facturación de una factura. Es un `event` crítico para el seguimiento de los Días de Venta Pendientes de Cobro (DSO) y la duración total del proceso. Dónde obtener Capturado de la marca de tiempo de creación del registro de factura de venta contabilizada en la tabla CustInvoiceJour. Las transacciones financieras correspondientes se crean en las tablas GeneralJournalEntry y LedgerEntry al contabilizar. Capturar Use el campo CreatedDateTime de la tabla CustInvoiceJour para la factura contabilizada. Tipo de evento explicit
	Fecha de Vencimiento Alcanzada	Un evento calculado que ocurre cuando la fecha de vencimiento de la factura se alcanza sin que se haya aplicado el pago completo. Esta actividad no corresponde a una transacción en el sistema, sino que se deriva de datos existentes.
Por qué es importante Este `event` es crucial para analizar las tasas de pago a tiempo e identificar facturas que están venciendo. Actúa como un punto de activación para las actividades de cobro y gestiones. Dónde obtener Esto no se registra como un `event`. Se calcula utilizando el campo DueDate de la tabla CustInvoiceJour. El `timestamp` del `event` es la `fecha` de vencimiento en sí. Capturar Crear un evento donde la `timestamp` es el valor del campo CustInvoiceJour.DueDate. Tipo de evento calculated
	Pago de cliente recibido	Esta actividad marca la creación de un asiento de diario para registrar un pago recibido de un cliente. Significa que se ha recibido efectivo, pero 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 entrega de la aplicación de efectivo. Diferencia entre recibir el dinero y realmente conciliarlo con las facturas pendientes. Dónde obtener Capturado de la creación o contabilización de un diario de pago de cliente. Esto se registra en tablas como LedgerJournalTrans, que luego crea una transacción de cliente en CustTrans al contabilizar. Capturar Use el `timestamp` de contabilización del diario de pagos del cliente de LedgerJournalTable. Tipo de evento explicit
	Factura enviada para aprobación	Esta actividad indica que una factura generada ha sido enviada a un `workflow` de aprobación formal. Esto es común en organizaciones con controles que requieren revisión de la gerencia antes de que una factura sea enviada a un cliente. Esto se registra como un paso específico en el motor de `workflow` de D365.
Por qué es importante El seguimiento de la presentación para aprobación ayuda a separar el tiempo de creación de la factura del tiempo de espera de aprobación. Es el primer paso para analizar la eficiencia de los procesos internos de revisión y control. Dónde obtener Capturado de las tablas de historial del `workflow`, como WorkflowTrackingStatusTable, filtrando por el evento de envío relacionado con el documento de la factura. Capturar Extraer `event logs` del `workflow` donde el estado es 'Submitted'. Tipo de evento explicit
	Nota de Crédito Emitida	Representa la creación de una nota de crédito o `credit memo`, típicamente para corregir un error de facturación, otorgar un ajuste de precio o registrar bienes devueltos. Una nota de crédito es esencialmente una factura negativa.
Por qué es importante Las notas de crédito frecuentes pueden indicar problemas sistémicos en el proceso de cumplimiento de pedidos o facturación. Analizar por qué se emiten las notas de crédito es clave para la mejora del proceso y la reducción de la pérdida de ingresos. Dónde obtener Esta es una transacción explícita, registrada 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 en CustInvoiceJour con un importe total negativo y vincúlelos a la factura original. Tipo de evento explicit
	Pago Revertido	Esta actividad significa la reversión de un pago de cliente previamente contabilizado. Esto ocurre debido a errores como una contabilización incorrecta, fondos insuficientes u otras fallas de pago.
Por qué es importante Las reversiones de pago destacan 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 obtener Capturado como una reversión de transacción en el libro mayor. Un asiento invertido puede identificarse en GeneralJournalEntry, a menudo con un indicador específico o por su relación con la transacción original. Capturar 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 Satisfecho	Esta actividad marca el punto en que se han enviado `bienes` o prestado `servicios` para un pedido de venta, desencadenando el proceso de facturación. Típicamente se infiere de la contabilización de un albarán o nota de entrega en Microsoft Dynamics 365, lo que cambia el estado de las líneas de pedido de venta relacionadas.
Por qué es importante Este `event` sirve como punto de partida para medir el tiempo de ciclo de generación de facturas. Comprender el retraso entre la entrega y la facturación ayuda a identificar `bottlenecks` administrativos que pueden impactar el flujo de caja. Dónde obtener Se infiere de la fecha de creación de una entrada de diario de albarán vinculada al pedido de venta. Esto implica tablas como CustPackingSlipJour y CustPackingSlipTrans, que están relacionadas con el pedido de venta en el que se basa la factura. Capturar Identifique la fecha de contabilización del albarán más reciente para el 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 aviso de cobranza a un cliente con respecto a una factura vencida. Dynamics 365 tiene un proceso formal de cobro que genera y registra estas comunicaciones.
Por qué es importante El seguimiento de los recordatorios ayuda a evaluar la efectividad del proceso de cobro. Permite analizar cuántos recordatorios se necesitan antes de recibir un pago. Dónde obtener Este es un `event` explícito capturado de la `fecha` de creación del diario de cartas de cobro en la tabla CustCollectionLetterJour, que está vinculado a la transacción de factura vencida. Capturar Use el `timestamp` 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

Navegar al espacio de trabajo de Data management: Inicie sesión en Microsoft Dynamics 365 Finance and Operations. Use la barra de búsqueda para encontrar y navegar al espacio de trabajo de Data management. Este es el centro neurálgico para todas las operaciones de importación y exportación de datos.
Crear un nuevo proyecto de exportación: Dentro del espacio de trabajo de Data management, haga clic en el mosaico Export para crear un nuevo proyecto de exportación de datos. Asigne al proyecto un nombre significativo, como ProcessMind_O2C_Billing_Export, y una descripción.
Seleccionar formato de datos de destino: En la configuración del proyecto, especifique el Target data format. Para compatibilidad con la mayoría de las herramientas de transformación de datos, seleccione CSV. Configure las opciones de formato según sea necesario, asegurando un delimitador y un calificador de texto comunes.
Agregar entidades de datos requeridas: Este es el paso más crítico. Agregará varias entidades de datos estándar a su proyecto para capturar todas las actividades requeridas. Para cada entidad, haga clic en Add entity y busque el nombre de la entidad que aparece en la sección Query/Script. Agregue cada una de las siguientes entidades a su proyecto: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement y Dunning history letters.
Aplicar filtros de entidad: Para limitar los datos a un alcance relevante, aplique filtros a sus entidades. Como mínimo, filtre Sales invoice headers V2 por InvoiceDate para un período específico, por ejemplo, los últimos 6 meses. Además, filtre por las entidades legales (empresas) específicas que desea analizar.
Ejecutar el trabajo de exportación: Una vez que todas las entidades estén agregadas y los filtros aplicados, haga clic en el botón Export en el panel de acciones. El sistema creará un paquete de trabajo y comenzará a procesar la extracción de datos en segundo plano.
Monitorear y descargar los datos: Puede monitorear el progreso del trabajo en la sección Job history. Una vez que el trabajo se complete con éxito, puede descargar el paquete de datos exportado. El paquete será un archivo ZIP que contiene archivos CSV separados para cada entidad de datos.
Descomprimir el paquete: Extraiga el contenido del archivo ZIP descargado a una carpeta local. Ahora tendrá varios archivos CSV, uno para cada entidad.
Transformar y combinar datos: Los archivos sin procesar deben transformarse en un único registro de eventos. Use una herramienta de preparación de datos como Power Query, Python o un área de preparación de base de datos. Para cada archivo de origen, cree las columnas requeridas: InvoiceNumber (Case ID), ActivityName (un valor codificado que representa el evento, como 'Invoice Generated') y EventTime (el campo de fecha relevante del archivo de origen). Asigne otros atributos como InvoiceAmount y CustomerName.
Unir todos los datos transformados: Combine los datos transformados de todos los archivos de origen en una sola tabla utilizando una operación de unión o anexión. Esto crea el registro de eventos final y unificado donde cada fila representa una actividad en el ciclo de vida de la factura.
Formato final para la carga: Asegúrese de que el archivo CSV final tenga los encabezados de columna correctos (InvoiceNumber, ActivityName, EventTime, etc.) y que la columna EventTime tenga un formato de marca de tiempo consistente (por ejemplo, AAAA-MM-DD HH:MI:SS). Este archivo ya está 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. Las entidades clave incluyen Sales invoice headers V2 (para facturas y notas de crédito), Sales packing slip headers (para cumplimiento de pedidos), CustPaymentJournalLineEntity (para pagos), Customer settlement (para aplicación de efectivo) y Workflow tracking status table (para aprobaciones).
Formato de exportación: El formato de datos de destino recomendado es CSV por su amplia compatibilidad con herramientas de transformación de datos.
Filtrado por rango de fechas: Es crucial aplicar un filtro de rango de fechas a las entidades primarias, especialmente a Sales invoice headers V2 en el campo InvoiceDate. Se recomienda un rango de 3 a 6 meses para mantener la exportación manejable y proporcionar datos suficientes para el análisis.
Filtrado por empresa: La exportación debe filtrarse por la entidad legal o el código de empresa específico 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: Se requiere un paso de postprocesamiento fuera de Dynamics 365. Los archivos exportados deben combinarse y reformatearse en un único formato de registro de eventos. Esto generalmente implica el uso de herramientas como Power BI (Power Query), Python o SQL.
Requisitos previos: El usuario que ejecuta la exportación debe tener los roles de seguridad adecuados asignados en Dynamics 365, que normalmente incluyen un rol con permisos para el espacio de trabajo de Data management y acceso a las entidades de datos requeridas.

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 Python 3.6+ instalado con las bibliotecas requests y pandas. También necesitará credenciales para un service principal (Registro de Aplicación) en Azure Active Directory al que se le haya otorgado acceso al entorno de Dynamics 365 Finance & Operations.
Registro de Aplicación: En Azure AD, registre una nueva aplicación. Cree un client secret y anote el Application (client) ID, Directory (tenant) ID y el client secret. En Dynamics 365, agregue este application ID en Administración del sistema > Configuración > Aplicaciones de Azure Active Directory y asígnele los derechos de usuario apropiados para leer las entidades de datos requeridas.
Configurar el script: Abra el script de Python proporcionado. Rellene las variables de configuración en la parte superior del script, incluyendo d365_url, tenant_id, client_id, client_secret, company, start_date y end_date. La 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 desde la plataforma de identidad de Microsoft. Este token es necesario para autorizar las llamadas API posteriores.
Extracción de datos: Ejecute el script desde su terminal usando python your_script_name.py. El script comenzará extrayendo todas las facturas de venta contabilizadas (CustInvoiceJour) dentro del rango de fechas especificado. Para cada factura, luego realizará llamadas API adicionales para recuperar datos relacionados con actividades como pagos, liquidaciones, notas de crédito e historial de workflow.
Generación de actividades: El script procesa los datos sin procesar de múltiples endpoints API. 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 deriva estos eventos basándose en la fecha de vencimiento, el estado y el historial de liquidación de una factura, creando entradas correspondientes en el event log.
Manejo de paginación: La función auxiliar fetch_all_data está diseñada para manejar 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 @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 sola lista, la convierte en un pandas DataFrame y estandariza los nombres de las columnas a InvoiceNumber, ActivityName, EventTime y otros atributos requeridos.
Exportar a CSV: Finalmente, el script guarda el DataFrame resultante en un archivo CSV llamado d365_billing_event_log.csv. Este archivo está formateado y listo para ser cargado en ProcessMind o en otra herramienta de Process Mining.

Configuración

D365 URL: La URL base de su instancia de Dynamics 365 Finance & Operations. Este es el punto de conexión principal para todas las llamadas a la API.
Credenciales de Azure AD: Se requieren client_id, client_secret y tenant_id para la autenticación. Estos deben pertenecer a una aplicación con acceso de lectura a las entidades relevantes de D365.
Empresa: Especifique el DataAreaId, que corresponde a la entidad legal en Dynamics 365 de la que desea extraer datos (por ejemplo, 'USMF').
Rango de fechas: Defina una start_date y una end_date para limitar el alcance de la extracción. Para un análisis inicial, se recomienda un período de 3 a 6 meses para asegurar un tamaño de dataset manejable mientras se capturan 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 para leer de todas estas entidades.
Rendimiento: La extracción de datos durante un período prolongado o de una empresa muy grande puede ser lenta debido a la naturaleza de realizar múltiples llamadas API secuenciales. Es aconsejable ejecutar el script durante las horas de menor actividad y comenzar con un rango de fechas más pequeño 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()

Su `Template` de `Datos` para Pedido a Cobro - Facturación y Emisión de Facturas

Su `Template` de `Datos` para Pedido a Cobro - Facturación y Emisión de Facturas

Atributos de Pedido a Cobro - Facturación y Emisión de Facturas

Actividades de Pedido a Cobro - Facturación y Emisión de Facturas

Guías de Extracción

Exportación de Entidad de Datos de Microsoft Dynamics 365

Pasos

Configuración

a Consulta de ejemplo config

Script de Python usando la API Web OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Termine con los retrasos en la facturación: Optimice Orden a Efectivo y Cobranza hoy

Su Template de Datos para Pedido a Cobro - Facturación y Emisión de Facturas

Su Template de Datos para Pedido a Cobro - Facturación y Emisión de Facturas

Atributos de Pedido a Cobro - Facturación y Emisión de Facturas

Actividades de Pedido a Cobro - Facturación y Emisión de Facturas

Guías de Extracción

Exportación de Entidad de Datos de Microsoft Dynamics 365

Pasos

Configuración

a Consulta de ejemplo config

Script de Python usando la API Web OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Valoramos su privacidad

¿Listo para comenzar?

Termine con los retrasos en la facturación: Optimice Orden a Efectivo y Cobranza hoy

Su `Template` de `Datos` para Pedido a Cobro - Facturación y Emisión de Facturas

Su `Template` de `Datos` para Pedido a Cobro - Facturación y Emisión de Facturas