> Mejora Continua de Procesos > De la Compra al Pago Procesamiento de Facturas > Microsoft Dynamics 365 > Plantilla de Datos

Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas

Microsoft Dynamics 365

← Volver a la Guía de Mejora

De la Compra al Pago - Atributos de Procesamiento de Facturas (23) De la Compra al Pago - Actividades de Procesamiento de Facturas (14) Guías de Extracción (4)

Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas

Esta plantilla proporciona una guía clara para extraer los datos esenciales necesarios para analizar su proceso de De la Compra al Pago - Procesamiento de Facturas en Microsoft Dynamics 365. Describe los atributos cruciales a recopilar, las actividades clave a seguir y una guía práctica para la extracción de datos. Utilice este recurso para asegurarse de recopilar toda la información necesaria para un análisis y optimización completos del proceso.

Atributos recomendados para recopilar para un análisis en profundidad
Actividades clave para seguir a lo largo del ciclo de vida del procesamiento de facturas
Guía para la extracción de `datos` de Microsoft Dynamics 365

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

Descargar Plantilla

De la Compra al Pago - Atributos de Procesamiento de Facturas

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis exhaustivo de su proceso de De la Compra al Pago - Procesamiento de Facturas.

5 Requerido 7 Recomendado 11 Opcional

	Nombre	Descripción
	Hora del Evento EventTime	La marca de tiempo precisa que indica cuándo ocurrió una actividad o evento específico.
Descripción `Event Time`, o el `timestamp`, registra la fecha y hora exactas en que tuvo lugar una actividad. Este es un componente crítico del `registro de eventos`, proporcionando la secuencia temporal necesaria para ordenar las actividades correctamente y calcular duraciones. En el análisis, este `timestamp` es la base de todas las métricas relacionadas con el tiempo. Se utiliza para calcular la duración de las actividades, el tiempo de ciclo entre diferentes pasos (por ejemplo, el tiempo de aprobación) y el tiempo total de procesamiento de extremo a extremo para cada factura. También permite el análisis de tendencias a lo largo del tiempo. Por qué es importante Esta marca de tiempo es esencial para ordenar eventos, calcular todos los tiempos de ciclo y duraciones, e identificar cuellos de botella del proceso. Dónde obtener Esto se obtiene de varios campos de fecha/hora en múltiples tablas, como los campos createdDateTime o modifiedDateTime en tablas como VendInvoiceInfoTable, VendTrans o tablas de historial de flujo de trabajo. Ejemplos 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Nombre de la Actividad ActivityName	El nombre del evento o tarea de negocio específico que ocurrió en un momento dado dentro del ciclo de vida del procesamiento de facturas.
Descripción El Nombre de la Actividad describe un paso específico o un cambio de estado en el proceso de la factura, como 'Factura Registrada', 'Factura Enviada para Aprobación' o 'Pago Ejecutado'. Estos datos son cruciales para construir el mapa de procesos y comprender la secuencia de eventos. Analizar este atributo revela el flujo del proceso, identifica las rutas comunes y destaca las desviaciones o los cuellos de botella. Se utiliza para calcular los tiempos de ciclo entre actividades, como la duración desde la aprobación hasta la contabilización, y para medir la frecuencia de eventos específicos como rechazos o bloqueos de pago. Por qué es importante Define los pasos en el mapa de procesos, permitiendo la visualización del flujo del proceso y el análisis de las transiciones entre diferentes actividades. Dónde obtener Este atributo se deriva típicamente de una combinación de campos de estado, tipos de transacción o entradas de registro de cambios dentro de varias tablas de Dynamics 365 relacionadas con el procesamiento de facturas. Ejemplos Factura enviada para aprobaciónDiscrepancia de Conciliación EncontradaPago Ejecutado
	Número de Factura InvoiceNumber	El identificador único para cada factura de proveedor, sirviendo como ID de caso principal para rastrear su ciclo de vida.
Descripción El Número de Factura es la clave única que vincula todas las actividades asociadas con una única factura de proveedor. Permite el seguimiento de extremo a extremo del recorrido de la factura, desde la recepción y el registro hasta la conciliación, aprobación y pago final. En el análisis de Process Mining, este atributo es fundamental. Define el caso, permitiendo la reconstrucción del flujo de proceso de cada factura. Esto permite el cálculo de los tiempos de ciclo totales, la identificación de variantes de proceso y el análisis de las características y resultados específicos de la factura. Por qué es importante Este es el Case ID esencial que conecta todos los eventos relacionados, haciendo posible analizar el ciclo de vida completo de cada factura individual. Dónde obtener Esto se encuentra típicamente en la tabla principal de facturas de proveedor, como VendInvoiceInfoTable, campo Num. Ejemplos INV-10056773245-AUS-001-98432
	Source System SourceSystem	El sistema de registro desde el cual se extrajeron los datos del evento.
Descripción Este atributo identifica la aplicación de origen donde se originaron los datos de la actividad. Para este proceso, típicamente será 'Microsoft Dynamics 365'. En entornos con múltiples sistemas, como una solución externa de OCR o captura, este campo ayuda a diferenciar dónde ocurre cada paso del proceso. Asegura que la línea de datos sea clara y ayuda a solucionar problemas de extracción de datos. Por qué es importante Proporciona un contexto crucial sobre el origen de los datos, lo cual es importante para la validación de datos y la comprensión del panorama de sistemas del proceso. Dónde obtener Este es un valor estático, 'Microsoft Dynamics 365', añadido durante la transformación de datos para etiquetar el origen del conjunto de datos. Ejemplos Microsoft Dynamics 365
	Última actualización de datos LastDataUpdate	La marca de tiempo que indica la última vez que se actualizaron los datos para este proceso desde el sistema de origen.
Descripción Este atributo registra cuándo el conjunto de datos fue extraído y actualizado por última vez desde Microsoft Dynamics 365. Típicamente es el mismo para todos los registros dentro de una única carga de datos. Esta información es vital para que los usuarios comprendan la actualidad de los datos que están analizando. Proporciona contexto sobre cuán actuales son las percepciones del proceso y es esencial para gestionar los programas de actualización de datos y validar los pipelines de datos. Por qué es importante Informa a los usuarios sobre la actualidad de los `datos`, asegurando que sepan qué tan reciente es el análisis y cuándo se espera la próxima actualización de `datos`. Dónde obtener Esta marca de tiempo es generada y estampada en el conjunto de datos por el proceso de extracción de datos o ETL en el momento de la ejecución. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	`Número de Proveedor` VendorNumber	El identificador único para el proveedor o suministrador que presentó la factura.
Descripción El Número de Proveedor es el código que identifica de forma única a un proveedor en los datos maestros. Vincula la transacción de la factura a un proveedor específico, permitiendo un análisis centrado en el proveedor. Este atributo es esencial para segmentar los datos del proceso por proveedor. Ayuda a responder preguntas como '¿Qué proveedores tienen los tiempos de aprobación más largos?' o '¿Las discrepancias de conciliación son más comunes con ciertos proveedores?'. Analizar el rendimiento por proveedor puede descubrir oportunidades de colaboración con proveedores y mejora de procesos. Por qué es importante Permite el filtrado y el análisis de la causa raíz por proveedor, ayudando a identificar problemas de rendimiento o patrones vinculados a proveedores específicos. Dónde obtener Esto se encuentra típicamente en la cabecera de la tabla de facturas de proveedor, como VendInvoiceInfoTable, vinculada a los datos maestros principales del proveedor en VendTable. Ejemplos V-1001V-2050V-8342
	Estado de la Factura InvoiceStatus	El estado actual de la factura en el momento de la extracción de datos.
Descripción El Estado de la Factura indica el estado actual de una factura dentro de su ciclo de vida, como 'Pendiente de Aprobación', 'Aprobada', 'Contabilizada' o 'Pagada'. Esto proporciona una instantánea del progreso de la factura. Este atributo se utiliza principalmente para crear dashboards operativos que muestran la carga de trabajo actual y el backlog. Ayuda a los gerentes a comprender cuántas facturas están en cada etapa del proceso, apoyando la asignación de recursos y la monitorización operativa. Es clave para el dashboard de 'Rendimiento y Estado del Procesamiento de Facturas'. Por qué es importante Proporciona una vista del estado actual de todas las facturas, esencial para la monitorización operativa, la gestión de la carga de trabajo y la identificación de cuellos de botella actuales. Dónde obtener Esto se deriva típicamente de campos de estado en la tabla principal de facturas, como VendInvoiceInfoTable. Ejemplos Pendiente de aprobaciónContabilizadoPagado
	Fecha de Vencimiento de Pago PaymentDueDate	La fecha en la que la factura debe ser pagada según los términos de pago acordados.
Descripción La Fecha de Vencimiento de Pago se calcula basándose en la fecha de la factura y los términos de pago del proveedor. Representa el plazo contractual para el pago. Esta fecha es crítica para medir el rendimiento financiero y la gestión de la relación con los proveedores. Es la línea de base utilizada para calcular el KPI de 'Tasa de Pago a Tiempo' comparándola con la fecha real de 'Pago Ejecutado'. Analizar esto ayuda a identificar problemas sistémicos que causan pagos atrasados, lo que puede llevar a relaciones dañadas con los proveedores o a la pérdida de descuentos por pronto pago. Por qué es importante Este es el punto de referencia para medir el rendimiento de pagos a tiempo, un KPI clave para la salud financiera y las relaciones con los proveedores. Dónde obtener Esta fecha a menudo es calculada por el sistema y almacenada en la tabla de transacciones de proveedor, como VendTrans, basándose en la fecha de la factura y los términos de pago. Ejemplos 2023-05-152023-06-302023-07-20
	Hora de Finalización EndTime	La marca de tiempo precisa que indica cuándo se completó una actividad o evento específico.
Descripción El End Time registra cuándo concluyó una actividad. Cuando se combina con el Start Time (EventTime), permite el cálculo preciso de cuánto tiempo tardó cada paso individual en completarse. Este atributo es esencial para calcular el 'ProcessingTime' para cada actividad, una métrica clave para el análisis de rendimiento. Ayuda a identificar exactamente qué pasos del proceso están consumiendo más tiempo, permitiendo esfuerzos de mejora dirigidos. Por ejemplo, puede medir la duración exacta de un paso manual de codificación o aprobación. Por qué es importante Permite el cálculo directo de los tiempos de procesamiento de actividad, lo cual es fundamental para identificar los pasos que consumen más tiempo en el proceso. Dónde obtener Al igual que StartTime, esto se obtiene de varios campos de fecha/hora. Para algunas actividades, podría ser el StartTime de la siguiente actividad. En otros casos, podría ser una marca de tiempo específica de 'completado el'. Ejemplos 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Importe de Factura InvoiceAmount	El valor monetario total de la factura.
Descripción Este atributo representa el importe total adeudado según lo indicado en la factura del proveedor. Es un punto de datos financiero fundamental para cada caso. El Importe de la Factura se utiliza ampliamente para la segmentación y el análisis. Puede revelar si las facturas de alto valor siguen un proceso de aprobación diferente y más riguroso o si tardan más en procesarse. También se utiliza en dashboards para analizar volúmenes de facturas por valor y se puede agregar para comprender el gasto total bajo análisis. Por qué es importante Permite el análisis basado en el valor financiero, ayudando a priorizar los esfuerzos de mejora de procesos en facturas de alto valor y a comprender los impulsores de costos. Dónde obtener Se encuentra en la tabla de encabezados de factura, por ejemplo, `VendInvoiceInfoTable`, en un campo como `InvoiceAmount` o `Amount`. Ejemplos 1500.00250.7512500.50
	Purchase Order Number PurchaseOrderNumber	El identificador de la Orden de Compra (PO) a la que está relacionada la factura.
Descripción El Número de Orden de Compra vincula una factura con el documento de adquisición original. Esto es crítico para procesos que implican conciliación de 2 o 3 vías entre la factura, la PO y la recepción de mercancías. Este atributo permite el análisis de facturas con PO frente a las sin PO, que a menudo siguen diferentes rutas de proceso. Es clave para comprender la efectividad del proceso de conciliación, investigar las discrepancias de conciliación y medir la tasa de procesamiento directo para facturas respaldadas por PO. Por qué es importante Distingue las facturas con orden de compra (PO) de las sin PO, que es un factor principal de variación del proceso y es crucial para el análisis de conciliación. Dónde obtener Ubicado en la tabla de cabecera de la factura, como VendInvoiceInfoTable, a menudo en un campo como PurchId. Ejemplos PO-001234PO-005678PO-009101
	Usuario User	El ID de usuario o el nombre de la persona que realizó la actividad.
Descripción Este atributo identifica al empleado o usuario del sistema responsable de ejecutar un paso de proceso específico. Para los pasos automatizados, esto podría ser una cuenta de sistema o servicio. Analizar el proceso por usuario ayuda a comprender la distribución de la carga de trabajo, identificar necesidades de capacitación y comparar el rendimiento entre individuos o equipos. Es crucial para analizar los bucles de retrabajo, donde el trabajo se pasa de un lado a otro entre usuarios, y para comprender las variaciones en cómo diferentes usuarios completan la misma tarea. Por qué es importante Permite el análisis del rendimiento y la carga de trabajo por usuario o equipo, y ayuda a identificar los niveles de automatización y las fuentes de retrabajo. Dónde obtener Obtenido de campos de ID de usuario en tablas de transacciones o de historial de flujo de trabajo, como los campos createdby o modifiedby. Esta información puede encontrarse en las tablas de seguimiento del flujo de trabajo. Ejemplos j.doea.smithAX_Admin
	Automatizado IsAutomated	Un indicador que señala si una actividad fue realizada automáticamente por el sistema o por un usuario humano.
Descripción Este atributo booleano (verdadero/falso) distingue entre eventos ejecutados por el sistema y tareas manuales de usuario. Por ejemplo, un paso de conciliación de facturas podría ser automatizado, mientras que la gestión de discrepancias es manual. Analizar este atributo es clave para comprender el nivel de automatización en el proceso. Ayuda a medir el éxito de las iniciativas de automatización, identifica los cuellos de botella manuales restantes y destaca oportunidades para una mayor automatización para mejorar la eficiencia y reducir errores. Por qué es importante Ayuda a medir el nivel de automatización en el proceso, identificando `bottlenecks` manuales y oportunidades para obtener ganancias de eficiencia. Dónde obtener Esto se deriva típicamente basándose en el atributo 'Usuario'. Si el usuario es una cuenta de sistema o servicio conocida, esta bandera se establece en verdadero. Ejemplos truefalse
	Condiciones de Pago PaymentTerms	El acuerdo de términos de pago con el proveedor, como 'Net 30' o '2% 10, Net 30'.
Descripción Los Términos de Pago definen las condiciones acordadas para pagar al proveedor, incluyendo el plazo y cualquier descuento potencial. Esta información generalmente se obtiene de los datos maestros del proveedor o de la orden de compra. Este atributo proporciona un contexto crucial para la Fecha de Vencimiento de Pago y el KPI de Tasa de Pago a Tiempo. Analizar si ciertos términos de pago están correlacionados con pagos atrasados puede revelar desafíos operativos. También ayuda en la planificación financiera y en la gestión efectiva del capital circulante. Por qué es importante Proporciona contexto para las fechas de vencimiento de pago y ayuda a analizar el impacto financiero de los tiempos de pago y las tasas de captura de descuentos. Dónde obtener Esta información se almacena en el maestro de proveedores (VendTable) y se copia a tablas de transacciones como VendInvoiceInfoTable. Ejemplos Neto 30Neto 602% 10, Net 30
	Departamento Department	El centro de costos o departamento al que se asignan los costos de la factura.
Descripción El Departamento identifica la unidad de negocio o centro de costos responsable del gasto en la factura. Esto generalmente se determina durante la actividad de codificación de la factura. Analizar el proceso por departamento es clave para comprender las diferencias departamentales en gastos, tiempos de aprobación y cumplimiento. Ayuda a identificar qué departamentos tienen la mayor cantidad de excepciones de facturas o los ciclos de aprobación más largos, proporcionando una base para la comunicación y capacitación dirigidas. Por qué es importante Permite el análisis de costos y procesos por departamento, destacando las variaciones en el rendimiento y el `cumplimiento` en toda la organización. Dónde obtener Obtenido de las dimensiones financieras vinculadas a las líneas o cabecera de la factura. Esto requiere consultar las estructuras de datos relacionadas con las dimensiones. Ejemplos VentasMarketingOperaciones de TI
	Moneda de la Factura InvoiceCurrency	El código de moneda para el importe de la factura (p. ej., USD, EUR).
Descripción La Moneda de la Factura especifica la moneda en la que se denomina el importe de la factura. Esto es importante para organizaciones multinacionales que tratan con proveedores de diferentes países. Este atributo proporciona el contexto necesario para el Importe de la Factura y se utiliza para filtrar y generar informes, especialmente en operaciones globales. Asegura que los valores financieros se interpreten correctamente y permite el análisis específico por moneda o la conversión a una moneda de informe estándar. Por qué es importante Proporciona un contexto esencial para los importes financieros, permitiendo una interpretación y análisis precisos de los valores de las facturas en diferentes regiones. Dónde obtener Ubicado en la tabla de cabecera de la factura junto al importe de la factura, por ejemplo, el campo CurrencyCode de VendInvoiceInfoTable. Ejemplos USDEURGBP
	Motivo de bloqueo de pago PaymentBlockReason	El código de motivo que explica por qué se aplicó un bloqueo de pago a una factura.
Descripción Un bloqueo de pago impide que se pague una factura. Este `atributo` registra el motivo del bloqueo, que suele ser un código estandarizado seleccionado por un usuario, como 'Cargos disputados' o 'Esperando recibo de mercancías'. Este `atributo` es esencial para el `dashboard` de 'Frecuencia y Duración del Bloqueo de Pagos'. Analizar las razones más comunes de los bloqueos de pago ayuda a identificar problemas subyacentes en el proceso P2P. Resolver estas causas raíz puede reducir significativamente los retrasos en los pagos y mejorar las relaciones con los proveedores. Por qué es importante Explica por qué los pagos se retrasan intencionalmente, ayudando a identificar y resolver problemas previos que causan bloqueos de pago. Dónde obtener Este suele ser un campo en el registro de la transacción o factura del proveedor, a menudo relacionado con el estado de bloqueo de pago. Busque en tablas como VendTrans. Ejemplos Disputa de calidadEsperando nota de créditoBloqueo manual
	Motivo de rechazo RejectionReason	El motivo proporcionado por un aprobador para rechazar una factura.
Descripción Cuando se rechaza una factura durante el flujo de aprobación, el aprobador suele indicar un motivo. Este atributo registra dicha explicación, que puede ser un código predefinido o texto libre. Este es un atributo crucial para el dashboard de 'Análisis de Rechazo de Facturas'. Proporciona la información cualitativa necesaria para comprender las causas raíz de los rechazos, como 'Número de Pedido Incorrecto', 'Factura Duplicada' o 'Discrepancia de Precio'. Analizar estos motivos ayuda a priorizar acciones para reducir la tasa de rechazo. Por qué es importante Proporciona información directa sobre por qué se rechazan las facturas, permitiendo acciones dirigidas para reducir el retrabajo y mejorar las tasas de acierto a la primera. Dónde obtener Típicamente encontrado en los comentarios o registros de historial de las tablas de procesamiento del flujo de trabajo. Ejemplos Cantidad incorrectaFactura duplicadaLímite de aprobación excedido
	Pago a Tiempo IsOnTimePayment	Un indicador calculado que señala si una factura se pagó en o antes de su fecha de vencimiento.
Descripción Este atributo booleano se deriva comparando la marca de tiempo de la actividad 'Pago Ejecutado' con la 'Fecha de Vencimiento de Pago'. Si la fecha de pago es menor o igual a la fecha de vencimiento, el valor es verdadero, de lo contrario es falso. Este atributo apoya directamente el KPI de 'Tasa de Pago a Tiempo' y el dashboard de 'Cumplimiento de Términos de Pago'. Simplifica el análisis al proporcionar un resultado binario claro para cada factura, facilitando el filtrado de pagos atrasados y la investigación de sus causas raíz por proveedor, departamento o país. Por qué es importante Mide directamente el `cumplimiento` de los términos de pago, simplificando el cálculo del KPI de Tasa de Pago a Tiempo y los análisis relacionados. Dónde obtener Este atributo se calcula en la capa de transformación de datos. La lógica es: (Marca de tiempo de la actividad 'Pago Ejecutado') <= (Fecha de Vencimiento de Pago). Ejemplos truefalse
	Sociedad CompanyCode	El identificador de la entidad legal o empresa dentro de la organización que procesa la factura.
Descripción El Código de Empresa representa la entidad legal específica que es financieramente responsable de la factura. En una organización multicompañía, este es un punto de datos crítico para la segmentación financiera. Este atributo permite que el análisis del proceso se filtre o compare entre diferentes entidades legales. Puede revelar si el rendimiento del proceso, las políticas o los cuellos de botella son específicos de ciertas empresas dentro del grupo, apoyando iniciativas de mejora de procesos localizadas. Por qué es importante Permite que el análisis del proceso se segmente por entidad legal, lo cual es crucial para organizaciones grandes y multiempresa. Dónde obtener Este es un campo estándar en la mayoría de las tablas financieras en Dynamics 365, a menudo llamado DataAreaId. Ejemplos USMFDEMFGBSI
	Tiempo de Ciclo Total TotalCycleTime	La duración total de extremo a extremo para procesar una sola factura, desde la recepción hasta el pago.
Descripción El Tiempo Total de Ciclo mide la duración completa que una factura pasa en el proceso. Se calcula como la diferencia de tiempo entre la primera actividad (por ejemplo, 'Factura Registrada') y la última actividad (por ejemplo, 'Pago Ejecutado') para un número de factura dado. Este es un KPI principal para medir la eficiencia general del proceso. Proporciona una visión de alto nivel del rendimiento y se utiliza en el dashboard de 'Tiempo de Ciclo de Factura de Extremo a Extremo'. Analizar las tendencias en esta métrica y segmentarla por atributos como proveedor o importe ayuda a identificar amplias oportunidades de mejora. Por qué es importante Representa el KPI clave de alto nivel para la velocidad y eficiencia general del proceso, resumiendo el rendimiento de cada factura. Dónde obtener Esto se calcula a nivel de caso dentro de la herramienta de Process Mining o durante la preparación de datos. Es la diferencia de tiempo entre la primera y la última marca de tiempo del evento para cada CaseId. Ejemplos P15DP22DT5H30MP7D
	Tiempo de Procesamiento ProcessingTime	La duración de una sola actividad, calculada como la diferencia entre su hora de finalización y su hora de inicio.
Descripción El Tiempo de Procesamiento mide el tiempo activo dedicado a una tarea específica. Se calcula restando el StartTime de un evento de su EndTime. También se conoce como duración de la actividad. Esta métrica es fundamental para el análisis de rendimiento. Ayuda a identificar qué actividades específicas son las que consumen más tiempo, a diferencia de los tiempos de espera entre actividades. Esto permite mejoras enfocadas, como proporcionar una mejor capacitación para acelerar la codificación manual u optimizar un paso del sistema que se ejecuta lentamente. Por qué es importante Mide la duración real del trabajo de las actividades, ayudando a identificar tareas ineficientes que están listas para la optimización o automatización. Dónde obtener Este no es un campo en el sistema de origen. Se calcula durante la transformación de datos utilizando la fórmula: EndTime - StartTime. Ejemplos PT1H30MP2DT4HPT5M15S
	Tipo de discrepancia MatchingDiscrepancyType	Categoriza el tipo de discrepancia encontrada durante el proceso de conciliación de factura y orden de compra (PO).
Descripción Cuando ocurre una discrepancia durante la conciliación de 2 o 3 vías, este atributo especifica la naturaleza del problema, por ejemplo, 'Discrepancia de Precio', 'Discrepancia de Cantidad' o 'Recepción de Mercancías Faltante'. Estos datos son centrales para el dashboard de 'Tiempo de Resolución de Discrepancias de Conciliación'. Al analizar la frecuencia de los diferentes tipos de discrepancias, la empresa puede identificar las causas raíz de las fallas de conciliación. Por ejemplo, las discrepancias frecuentes de precios pueden indicar problemas con datos maestros desactualizados, mientras que las discrepancias de cantidad podrían indicar problemas de envío. Por qué es importante Categoriza las fallas de conciliación, facilitando el análisis de causa raíz para reducir la tasa de discrepancias y mejorar el procesamiento directo. Dónde obtener Esto puede almacenarse en una tabla dedicada de registro de conciliación o excepción, o podría necesitar ser derivado de mensajes de estado o comentarios del flujo de trabajo. Ejemplos Discrepancia de PrecioDiscrepancia de CantidadFalta de Recepción de Mercancía

Requerido Recomendado Opcional

De la Compra al Pago - Actividades de Procesamiento de Facturas

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

6 Recomendado 8 Opcional

	Actividad	Descripción
	Factura Aprobada	Representa la aprobación final y exitosa de la factura dentro del flujo de trabajo, autorizándola para su contabilización y pago. Este es un evento explícito registrado por el motor del flujo de trabajo al finalizar.
Por qué es importante Este es un hito crítico que concluye el proceso de aprobación. El tiempo desde 'Factura Enviada para Aprobación' hasta este evento es una medida clave de la eficiencia de aprobación y ayuda a identificar cuellos de botella. Dónde obtener Este es un evento explícito registrado en las tablas de historial de flujo de trabajo (por ejemplo, WorkflowTrackingStatusTable) cuando el estado del flujo de trabajo cambia a 'Aprobado'. Capturar Marca de tiempo de la entrada de estado 'Aprobado' en el historial del flujo de trabajo. Tipo de evento explicit
	Factura conciliada con orden de compra	Representa la finalización exitosa del proceso de conciliación, donde los detalles de la factura se alinean con la orden de compra y la información de recepción de mercancías. Este evento se infiere cuando el estado de conciliación de la factura se actualiza a 'Aprobado'.
Por qué es importante La conciliación exitosa es un hito clave para las facturas respaldadas por PO, confirmando la validez del cargo antes del pago. Es esencial para el seguimiento de la eficiencia de la conciliación y las tasas de automatización. Dónde obtener Inferido a partir de la actualización del campo de estado de conciliación en el encabezado o las líneas de la factura del proveedor (por ejemplo, `VendInvoiceInfoTable`) a un valor 'Aprobado' o 'Conciliado con éxito'. Capturar Marca de tiempo del cambio de estado a 'Aprobado' en los detalles de validación de conciliación de facturas. Tipo de evento inferred
	Factura Contabilizada	Este es el evento contable formal donde la factura aprobada se registra en el Libro Mayor, creando una responsabilidad. Este es un evento explícito y transaccional en el sistema.
Por qué es importante La contabilización es el paso final antes del pago y es un punto de control financiero clave. El tiempo desde 'Factura Aprobada' hasta 'Factura Contabilizada' mide la eficiencia de los pasos contables finales. Dónde obtener Este es un evento explícito capturado de la creación de la transacción de proveedor contabilizada en tablas como VendTrans y los registros asociados GeneralJournalEntry y LedgerEntry. Capturar `Timestamp` de creación del registro en la tabla de transacciones de proveedor (`VendTrans`). Tipo de evento explicit
	Factura enviada para aprobación	Esta actividad marca la presentación formal de una factura en un flujo de trabajo para revisión y aprobación. El motor del flujo de trabajo de Dynamics 365 registra explícitamente este evento de envío.
Por qué es importante Este es el punto de partida para medir todo el ciclo de aprobación. Ayuda a identificar cuánto tiempo esperan las facturas antes de que comience el proceso de aprobación y es el disparador para los KPI relacionados con la aprobación. Dónde obtener Este es un evento explícito registrado en las tablas de historial de flujo de trabajo (por ejemplo, WorkflowTrackingStatusTable) cuando una factura se envía a un flujo de trabajo. Capturar `Timestamp` de creación del registro de envío de `workflow` en el historial del `workflow`. Tipo de evento explicit
	Factura Registrada	Esta es la entrada inicial de una factura en el sistema, creando un registro de marcador de posición antes de que se procesen los detalles completos. Esta actividad se captura cuando se crea un nuevo registro en el diario de registro de facturas de proveedor.
Por qué es importante Esta actividad marca el inicio oficial del ciclo de vida del procesamiento de facturas. Analizar el tiempo desde este punto ayuda a medir la duración total del procesamiento e identifica los retrasos en las primeras etapas. Dónde obtener Este es un evento explícito capturado de la creación de un registro en el registro de facturas de proveedor, típicamente en la VendInvoiceRegisterJournalTable o una tabla similar de facturas pendientes. Capturar `Timestamp` de creación del registro en el Diario de registro de facturas de proveedor. Tipo de evento explicit
	Pago Ejecutado	Esta es la actividad final, que representa la contabilización del asiento de pago que crea el pago y liquida la factura. Este es un evento transaccional explícito que cierra el ciclo de vida de la factura.
Por qué es importante Esta actividad marca el final exitoso del proceso de factura a pago. Es la base para medir la 'Tasa de Pago a Tiempo' y el tiempo total del ciclo de extremo a extremo. Dónde obtener Este es un evento explícito capturado de la contabilización del asiento de pago. La información de liquidación se registra en tablas como VendSettlement, vinculando el pago a la factura. Capturar Marca de tiempo de contabilización del asiento de pago que liquida la transacción del proveedor. Tipo de evento explicit
	Bloqueo de Pago Establecido	Esta actividad ocurre cuando se aplica una retención a una factura, impidiendo que sea pagada. Esto se captura mediante un cambio en el campo de bloqueo de pago o estado de retención en el registro de la factura contabilizada.
Por qué es importante Los bloqueos de pago son una causa principal de los pagos atrasados. Analizar cuándo y por qué se establecen es crucial para mejorar el rendimiento de los pagos a tiempo y las relaciones con los proveedores. Dónde obtener Inferido a partir de un cambio en el campo de retención o bloqueo de pago en la transacción de proveedor contabilizada (`VendTrans`). El registro de cambios se puede utilizar para capturar el `timestamp`. Capturar Marca de tiempo de la actualización que establece el campo de bloqueo de pago en la transacción del proveedor. Tipo de evento inferred
	Bloqueo de Pago Liberado	Representa la eliminación de una retención de pago, permitiendo que la factura proceda a la programación del pago. Esto se captura cuando el campo de bloqueo de pago se borra o se cambia a un estado desbloqueado.
Por qué es importante Mide el tiempo que se tarda en resolver los problemas que causan las retenciones de pago. Las largas duraciones entre el establecimiento y la liberación de un bloqueo indican procesos ineficientes de resolución de problemas. Dónde obtener Inferido a partir de un cambio que elimina el campo de retención o bloqueo de pago en la transacción de proveedor contabilizada (`VendTrans`). El registro de cambios puede proporcionar el `timestamp`. Capturar Marca de tiempo de la actualización que borra el campo de bloqueo de pago en la transacción del proveedor. Tipo de evento inferred
	Datos de Factura Capturados	Representa la finalización de la entrada de datos para la factura, incluyendo detalles de cabecera y línea, antes de ser enviada para conciliación o aprobación. Esto se infiere a menudo cuando el registro de la factura pasa de un estado 'nuevo' o 'registrado' a un estado de 'lista para procesar'.
Por qué es importante El seguimiento de esta actividad ayuda a medir la eficiencia del proceso de entrada de datos, ya sea manual o automatizado (OCR). Los retrasos aquí pueden repercutir en todo el proceso. Dónde obtener Inferido a partir de cambios de estado en el registro de factura pendiente de proveedor (por ejemplo, `VendInvoiceInfoTable`). El `evento` ocurre cuando todos los campos requeridos están poblados y la factura está lista para el siguiente paso. Capturar Detecta el cambio de estado en la tabla de facturas pendientes que indica la finalización de la entrada de `datos`. Tipo de evento inferred
	Discrepancia de Conciliación Encontrada	Esta actividad ocurre cuando el proceso de conciliación de facturas falla debido a desajustes entre la factura, la orden de compra o la recepción de mercancías. Se captura cuando el estado de conciliación de la factura se establece en 'Fallida' o 'Discrepancia'.
Por qué es importante Identificar cuándo y por qué ocurren las discrepancias es crucial para el KPI de 'Tasa de discrepancia de conciliación'. Esta actividad marca el inicio del proceso de resolución, que a menudo es una fuente de retrasos significativos. Dónde obtener Inferido a partir de la actualización del campo de estado de conciliación en la factura del proveedor (por ejemplo, `VendInvoiceInfoTable`) a un valor 'Fallido'. La razón del fallo a menudo también se registra. Capturar Marca de tiempo del cambio de estado a 'Fallida' o 'Discrepancia' durante la conciliación. Tipo de evento inferred
	Discrepancia de Conciliación Gestionada	Marca la resolución de una discrepancia de conciliación previamente identificada, permitiendo que la factura continúe. Esto se infiere cuando una factura con un estado de conciliación 'Fallida' se concilia de nuevo con éxito o se anula manualmente.
Por qué es importante Esta actividad concluye el subproceso de resolución de discrepancias. El tiempo entre 'Discrepancia de Conciliación Encontrada' y este evento es un KPI clave para medir la eficiencia de la resolución. Dónde obtener Inferido por un `evento` de conciliación exitoso ('Factura conciliada con orden de compra') que ocurre después de un `evento` de 'Discrepancia de conciliación encontrada' para la misma factura. Capturar Identificar un `timestamp` de estado de conciliación 'Aprobado' que sigue a un `timestamp` de estado 'Fallido'. Tipo de evento inferred
	Factura Codificada	Esta actividad significa que las distribuciones de cuentas del Libro Mayor se han asignado a las líneas de la factura. Se infiere típicamente por la creación o finalización de distribuciones de cuentas del libro mayor vinculadas a la factura.
Por qué es importante La codificación es un paso crítico para la precisión financiera. Medir el tiempo que lleva codificar las facturas ayuda a identificar `bottlenecks` en el proceso de revisión contable y respalda el KPI de 'Tiempo promedio de captura de datos a codificación'. Dónde obtener Inferido a partir de la creación y validación de registros en tablas de distribución contable (por ejemplo, `AccountingDistribution`) asociadas a la factura pendiente de proveedor. Capturar Marca de tiempo cuando se guardan y validan las distribuciones contables de la factura. Tipo de evento inferred
	Factura Rechazada	Indica que un aprobador ha rechazado la factura, deteniendo el proceso y típicamente enviándola de vuelta para su corrección. El motor de `workflow` registra explícitamente este `evento` de rechazo.
Por qué es importante El seguimiento de los rechazos ayuda a cuantificar el retrabajo e identificar las razones comunes de falla, como codificación incorrecta o violaciones de políticas. Esto apoya directamente el KPI de 'Tasa de Rechazo de Facturas'. Dónde obtener Este es un evento explícito registrado en las tablas de historial de flujo de trabajo (por ejemplo, WorkflowTrackingStatusTable) cuando el estado del flujo de trabajo cambia a 'Rechazado' o 'Cancelado'. Capturar Marca de tiempo de la entrada de estado 'Rechazado' en el historial del flujo de trabajo. Tipo de evento explicit
	Pago programado	Esta actividad ocurre cuando una factura contabilizada se incluye en una propuesta de pago o en un asiento de pago, pero antes de que se ejecute el pago. Es una acción explícita que crea una línea de asiento de pago.
Por qué es importante Esto marca la transición de Cuentas por Pagar a operaciones de Tesorería. Analizar este paso puede revelar retrasos entre la contabilización de la factura y el inicio del pago. Dónde obtener Este es un evento explícito capturado de la creación de una línea en un asiento de pago (LedgerJournalTrans) que liquida la transacción de proveedor contabilizada. Capturar `Timestamp` de creación de la línea de diario de pago que hace referencia a la factura. 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 Gestión de datos: Inicie sesión en Microsoft Dynamics 365 Finance. Use la barra de búsqueda para encontrar y navegar al espacio de trabajo de Gestión de datos.
Crear un nuevo proyecto de exportación: Dentro del espacio de trabajo, seleccione el mosaico Exportar para crear un nuevo proyecto de exportación de datos. Asigne un nombre significativo al proyecto, por ejemplo, ProcessMind_Invoice_Processing_Export.
Definir el proyecto de datos: En la pestaña General del nuevo proyecto, especifique el Formato de datos. CSV es un formato de uso común y recomendado. Configure otros parámetros según sea necesario.
Agregar entidades de datos requeridas: Vaya a la sección Entidades seleccionadas y haga clic en Agregar entidad. Busque y agregue las siguientes entidades principales una por una. Deberá especificar el formato de datos de destino para cada una.
- VendInvoiceInfoTableEntity (Encabezado de factura de proveedor)
- VendInvoiceTransEntity (Líneas de factura de proveedor)
- VendInvoiceRegisterHeaderEntity (Encabezado de diario de registro de facturas)
- WorkflowTrackingStatusTableEntity (Historial de workflow)
- AccountingDistributionEntity (Distribuciones de GL)
- VendInvoiceJour (Facturas de proveedor publicadas)
- VendTrans (Transacciones de proveedor, para bloqueos de pago)
- LedgerJournalTransVendPaymEntity (Líneas de diario de pago de proveedor)
- VendSettlement (Transacciones de liquidación de proveedor)
Aplicar filtros: Para cada entidad, es fundamental aplicar filtros para limitar el alcance de los datos. Seleccione una entidad y haga clic en Filtro. Como mínimo, filtre por Empresa (Entidad legal) y un rango de fechas específico en un campo de fecha relevante como CREATEDDATETIME o INVOICEDATE. Un rango típico para el análisis inicial es de los últimos 3 a 6 meses.
Configurar asignaciones de entidades: Para cada entidad, revise la asignación de origen a destino. Asegúrese de que todos los campos requeridos para el registro de eventos final se incluyan en la exportación. Normalmente no se necesitan cambios complejos de asignación en esta etapa.
Ejecutar el trabajo de exportación: Una vez que todas las entidades se hayan agregado y filtrado, haga clic en Exportar en el Panel de acciones para iniciar el trabajo. Puede ejecutarlo inmediatamente o programarlo para horas de menor actividad para minimizar la carga del sistema.
Descargar los datos exportados: Una vez que el trabajo de exportación se complete con éxito, navegue al historial de trabajos. Desde allí, puede descargar el paquete de datos exportados, que contendrá archivos separados para cada entidad de datos.
Transformar datos en un registro de eventos: Los archivos exportados son instantáneas de entidades, no un registro de eventos consolidado. Debe utilizar una herramienta externa como una base de datos, un script de Python o Power Query para procesar y combinar estos archivos. La consulta conceptual en la sección query proporciona la lógica completa para esta transformación.
Ejecutar la lógica de transformación: Cargue los archivos CSV exportados en su entorno de transformación elegido. Ejecute la consulta de transformación proporcionada, que une los datos de todos los archivos fuente para crear una única tabla de registro de eventos con una fila por actividad comercial.
Finalizar y cargar: Exporte los datos transformados finales a un único archivo CSV. Asegúrese de que los encabezados de las columnas coincidan con los requisitos, por ejemplo, InvoiceNumber, ActivityName, EventTime. Este archivo ya está listo para ser cargado en ProcessMind.

Configuración

Entidades de datos: El núcleo de la configuración es seleccionar el conjunto correcto de entidades para cubrir el ciclo de vida de la factura. Las entidades clave incluyen VendInvoiceInfoTableEntity, VendInvoiceJour y WorkflowTrackingStatusTableEntity.
Formato de datos de exportación: Seleccione CSV como formato de datos de destino para facilitar el procesamiento en pasos de transformación posteriores.
Filtrado por empresa: Es crucial filtrar cada entidad de datos por la entidad legal específica (Empresa) que esté analizando para evitar extraer datos irrelevantes.
Filtrado por rango de fechas: Aplique un filtro de rango de fechas consistente en todas las entidades relevantes, como VendInvoiceInfoTableEntity y VendInvoiceJour, basado en las fechas de creación o contabilización. Comience con un período reciente, por ejemplo, los últimos 6 meses, para gestionar el volumen de datos.
Extracción completa vs. Incremental: Para la extracción inicial, realice una extracción completa. Para las actualizaciones posteriores, puede configurar una exportación incremental para obtener solo los datos que hayan cambiado desde la última ejecución, lo que reduce el tiempo de procesamiento.
Requisitos previos: El usuario que realiza la exportación debe tener los roles de seguridad adecuados en Dynamics 365, que suelen incluir Data management administrator o un rol similar con permisos para acceder a las entidades de datos requeridas.

a Consulta de ejemplo config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Pasos

Prerrequisito: Configurar BYOD: Asegúrese de que la función "Traiga su propia base de datos" (Bring Your Own Database) esté configurada para su entorno de Microsoft Dynamics 365 Finance and Operations. Esto implica configurar una base de datos de Azure SQL y configurar D365 para exportar datos a ella.
Identificar entidades de datos: En D365, navegue al espacio de trabajo de Gestión de datos. El núcleo de esta extracción se basa en la exportación de entidades de datos específicas. Asegúrese de que las siguientes entidades estén incluidas en un trabajo de exportación dirigido a su base de datos BYOD: Diario de factura de proveedor, Líneas de factura de proveedor, Registro de documentos de factura de proveedor, Tabla de estado de seguimiento de workflow, Líneas de diario de pago de proveedor, Liquidaciones de proveedor y Distribuciones contables.
Crear y programar trabajo de exportación: En el espacio de trabajo de Gestión de datos, cree un nuevo proyecto de exportación. Agregue las entidades enumeradas anteriormente al proyecto. Configure el formato de datos de destino para que sea su base de datos BYOD. Establezca un programa recurrente para el trabajo de exportación, por ejemplo, diario u horario, para mantener los datos de su BYOD actualizados.
Verificar datos en Azure SQL: Conéctese a su base de datos de Azure SQL utilizando una herramienta como SQL Server Management Studio (SSMS) o Azure Data Studio. Verifique que las tablas correspondientes a las entidades de D365 se hayan creado y estén pobladas con datos.
Preparar consulta SQL: Copie la consulta SQL proporcionada. Esta consulta está diseñada para ejecutarse directamente contra las tablas creadas por el proceso de exportación de BYOD en su base de datos de Azure SQL.
Conectar y ejecutar: Abra una nueva ventana de consulta en su cliente SQL conectado al BYOD. Pegue la consulta SQL copiada en la ventana.
Establecer parámetros de consulta: Localice las variables de marcador de posición en la parte superior del script. Reemplace {StartDate}, {EndDate} y {CompanyCode} con la fecha de inicio, fecha de finalización y el identificador de entidad legal deseados, respectivamente. Por ejemplo, SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Ejecutar la consulta: Ejecute el script SQL completo. La consulta recopilará y unirá datos de varias tablas para construir un registro de eventos cronológico para cada factura.
Revisar los resultados: La salida será una única tabla que contendrá el registro de eventos con columnas para InvoiceNumber, ActivityName, EventTime y otros atributos especificados. Revise los resultados para asegurarse de que parecen correctos y completos.
Exportar el registro de eventos: Exporte los resultados de la consulta a un archivo CSV. La mayoría de los clientes SQL tienen una función incorporada para guardar los resultados en un archivo. Asegúrese de que el archivo se guarde con codificación UTF-8.
Preparar para la carga: Antes de cargar en una herramienta de Process Mining, confirme que el archivo CSV tiene los encabezados exactos como se especifica en la consulta (InvoiceNumber, ActivityName, etc.). No se necesita ninguna otra transformación de la estructura del archivo.

Configuración

Entidades de datos clave: La extracción se basa en que varias entidades de datos de D365 se exporten al BYOD. Las entidades críticas incluyen: VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution y VendTrans.
Filtrado por rango de fechas: La consulta proporcionada incluye los parámetros @StartDate y @EndDate. Se recomienda empezar con un rango de fechas limitado, como 3-6 meses de datos, para garantizar el rendimiento. El filtro se aplica a la fecha de contabilización o creación de la factura.
Filtrado por código de empresa: El parámetro @DataAreaId es crucial para entornos multiempresa. Siempre filtre por una entidad legal específica (Código de empresa) para asegurar que el contexto de los datos sea correcto.
Frecuencia de actualización de BYOD: La actualidad de los datos depende completamente del programa del trabajo de exportación de D365. Para un análisis casi en tiempo real, se requiere una alta frecuencia (por ejemplo, cada hora), lo que puede tener implicaciones de rendimiento y costo tanto en D365 como en Azure.
Requisitos previos: Este método requiere una suscripción activa de Azure, una base de datos de Azure SQL aprovisionada y acceso a nivel de administrador en D365 para configurar el espacio de trabajo de Gestión de datos.

a Consulta de ejemplo sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

Pasos

Configuración de prerrequisitos: Asegúrese de tener Python 3.6 o posterior instalado en su sistema. Instale las bibliotecas necesarias usando pip: pip install pandas requests msal. Estas bibliotecas son para la manipulación de datos, la realización de solicitudes HTTP a la API y el manejo de la autenticación de la plataforma de identidad de Microsoft.
Registrar una aplicación en Azure Active Directory: Para autenticarse con la API de Dynamics 365, debe registrar una aplicación en el inquilino de Azure AD de su organización. Cree un nuevo registro de aplicación (App Registration), genere un secreto de cliente y tome nota del ID de aplicación (cliente), el ID de directorio (inquilino) y el valor del secreto de cliente.
Otorgar permisos de API: Dentro del registro de aplicación recién creado en Azure AD, navegue a Permisos de API. Agregue un permiso para 'Dynamics ERP' o 'Dynamics 365 Business Central' (según su licencia), y otorgue el permiso delegado user_impersonation. Un administrador debe otorgar el consentimiento del administrador para estos permisos.
Crear un usuario de aplicación en Dynamics 365: En su entorno de Dynamics 365, navegue a Administración del sistema > Usuarios > Usuarios. Cree un nuevo usuario e ingrese el ID de aplicación (cliente) del registro de aplicación de Azure en el campo ID de aplicación. Asigne roles de seguridad apropiados a este usuario, como 'Administrador del sistema' o un rol más restringido que tenga acceso de lectura a todas las entidades de datos requeridas.
Configurar el script de Python: Copie el script de Python proporcionado en un archivo, por ejemplo extract_invoices.py. Abra el archivo y actualice las variables de marcador de posición en la parte superior con la URL específica de su entorno de Dynamics 365, el ID de inquilino, el ID de cliente, el secreto de cliente y el código de empresa (dataAreaId) de los que desea extraer datos.
Establecer el rango de fechas: Ajuste las variables START_DATE y END_DATE en el script para definir la ventana de tiempo para la extracción de datos. Se recomienda comenzar con un rango más pequeño, como un mes, para probar el script y verificar los resultados.
Ejecutar el script: Ejecute el script desde su línea de comandos o terminal usando el comando: python extract_invoices.py. El script se autenticará, consultará los diferentes endpoints OData para cada actividad y procesará los datos.
Supervisar la ejecución: El script imprimirá mensajes de progreso en la consola a medida que obtiene datos para cada actividad. Esto puede llevar una cantidad significativa de tiempo dependiendo del rango de fechas y el volumen de datos. Busque cualquier mensaje de error que pueda indicar problemas con la autenticación o el acceso a la API.
Revisar el archivo de salida: Una vez que el script se complete con éxito, generará un archivo CSV llamado d365_invoice_event_log.csv en el mismo directorio. Este archivo contiene el registro de eventos consolidado.
Preparar para la carga: Abra el archivo CSV para asegurarse de que esté correctamente formateado. Verifique que todas las columnas requeridas (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) estén presentes y pobladas. El archivo ya está listo para ser cargado en ProcessMind.

Configuración

Autenticación: El script utiliza el flujo de credenciales de cliente de OAuth 2.0. Debe configurar un registro de aplicación de Azure AD y otorgarle permisos de API para Dynamics 365. Se debe crear un usuario de aplicación con roles de seguridad adecuados en el propio Dynamics 365.
API Endpoint: La URL base para la API OData de Dynamics 365 Finance and Operations. El formato suele ser https://[your-d365-environment-name].operations.dynamics.com.
Rango de fechas: El script incluye las variables START_DATE y END_DATE. Estas se utilizan para filtrar registros según sus fechas de creación o modificación y así gestionar el volumen de datos. Para las extracciones iniciales, se recomienda un período de 3 a 6 meses.
Filtro por empresa: Los datos deben filtrarse por una entidad legal o empresa específica. Esto se hace especificando el dataAreaId en el filtro de consulta de la API, lo cual es una configuración obligatoria en el script.
Entidades de datos clave: El script consulta varias entidades OData estándar de Dynamics 365, incluidas VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines y VendSettlements. Es posible que se requieran entidades personalizadas si el proceso estándar está muy modificado.
Paginación: El script maneja automáticamente las respuestas paginadas de la API utilizando la propiedad @odata.nextLink para asegurar que se recuperen todos los registros del período especificado.

a Consulta de ejemplo python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"
COMPANY_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

    if not all_events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

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

Pasos

Navegar al espacio de trabajo de Gestión de datos: Inicie sesión en Microsoft Dynamics 365 Finance. Use la barra de búsqueda para encontrar y navegar al espacio de trabajo de Gestión de datos.
Crear un nuevo proyecto de exportación: Dentro del espacio de trabajo, seleccione el mosaico Exportar para crear un nuevo proyecto de exportación de datos. Asigne un nombre significativo al proyecto, por ejemplo, ProcessMind_Invoice_Processing_Export.
Definir el proyecto de datos: En la pestaña General del nuevo proyecto, especifique el Formato de datos. CSV es un formato de uso común y recomendado. Configure otros parámetros según sea necesario.
Agregar entidades de datos requeridas: Vaya a la sección Entidades seleccionadas y haga clic en Agregar entidad. Busque y agregue las siguientes entidades principales una por una. Deberá especificar el formato de datos de destino para cada una.
- VendInvoiceInfoTableEntity (Encabezado de factura de proveedor)
- VendInvoiceTransEntity (Líneas de factura de proveedor)
- VendInvoiceRegisterHeaderEntity (Encabezado de diario de registro de facturas)
- WorkflowTrackingStatusTableEntity (Historial de workflow)
- AccountingDistributionEntity (Distribuciones de GL)
- VendInvoiceJour (Facturas de proveedor publicadas)
- VendTrans (Transacciones de proveedor, para bloqueos de pago)
- LedgerJournalTransVendPaymEntity (Líneas de diario de pago de proveedor)
- VendSettlement (Transacciones de liquidación de proveedor)
Aplicar filtros: Para cada entidad, es fundamental aplicar filtros para limitar el alcance de los datos. Seleccione una entidad y haga clic en Filtro. Como mínimo, filtre por Empresa (Entidad legal) y un rango de fechas específico en un campo de fecha relevante como CREATEDDATETIME o INVOICEDATE. Un rango típico para el análisis inicial es de los últimos 3 a 6 meses.
Configurar asignaciones de entidades: Para cada entidad, revise la asignación de origen a destino. Asegúrese de que todos los campos requeridos para el registro de eventos final se incluyan en la exportación. Normalmente no se necesitan cambios complejos de asignación en esta etapa.
Ejecutar el trabajo de exportación: Una vez que todas las entidades se hayan agregado y filtrado, haga clic en Exportar en el Panel de acciones para iniciar el trabajo. Puede ejecutarlo inmediatamente o programarlo para horas de menor actividad para minimizar la carga del sistema.
Descargar los datos exportados: Una vez que el trabajo de exportación se complete con éxito, navegue al historial de trabajos. Desde allí, puede descargar el paquete de datos exportados, que contendrá archivos separados para cada entidad de datos.
Transformar datos en un registro de eventos: Los archivos exportados son instantáneas de entidades, no un registro de eventos consolidado. Debe utilizar una herramienta externa como una base de datos, un script de Python o Power Query para procesar y combinar estos archivos. La consulta conceptual en la sección query proporciona la lógica completa para esta transformación.
Ejecutar la lógica de transformación: Cargue los archivos CSV exportados en su entorno de transformación elegido. Ejecute la consulta de transformación proporcionada, que une los datos de todos los archivos fuente para crear una única tabla de registro de eventos con una fila por actividad comercial.
Finalizar y cargar: Exporte los datos transformados finales a un único archivo CSV. Asegúrese de que los encabezados de las columnas coincidan con los requisitos, por ejemplo, InvoiceNumber, ActivityName, EventTime. Este archivo ya está listo para ser cargado en ProcessMind.

Configuración

Entidades de datos: El núcleo de la configuración es seleccionar el conjunto correcto de entidades para cubrir el ciclo de vida de la factura. Las entidades clave incluyen VendInvoiceInfoTableEntity, VendInvoiceJour y WorkflowTrackingStatusTableEntity.
Formato de datos de exportación: Seleccione CSV como formato de datos de destino para facilitar el procesamiento en pasos de transformación posteriores.
Filtrado por empresa: Es crucial filtrar cada entidad de datos por la entidad legal específica (Empresa) que esté analizando para evitar extraer datos irrelevantes.
Filtrado por rango de fechas: Aplique un filtro de rango de fechas consistente en todas las entidades relevantes, como VendInvoiceInfoTableEntity y VendInvoiceJour, basado en las fechas de creación o contabilización. Comience con un período reciente, por ejemplo, los últimos 6 meses, para gestionar el volumen de datos.
Extracción completa vs. Incremental: Para la extracción inicial, realice una extracción completa. Para las actualizaciones posteriores, puede configurar una exportación incremental para obtener solo los datos que hayan cambiado desde la última ejecución, lo que reduce el tiempo de procesamiento.
Requisitos previos: El usuario que realiza la exportación debe tener los roles de seguridad adecuados en Dynamics 365, que suelen incluir Data management administrator o un rol similar con permisos para acceder a las entidades de datos requeridas.

a Consulta de ejemplo config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas

Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas

De la Compra al Pago - Atributos de Procesamiento de Facturas

De la Compra al Pago - Actividades de Procesamiento de Facturas

Guías de Extracción

Exportación del Marco de Gestión de Datos de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo config

Consulta SQL Directa a través de Bring Your Own Database (BYOD)

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python utilizando la API REST OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Microsoft Power Platform Dataflow Extraction

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Comience a Optimizar su Proceso de De la Compra al Pago - Procesamiento de Facturas Hoy

Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas

Su Plantilla de Datos para el Proceso De la Compra al Pago - Procesamiento de Facturas

De la Compra al Pago - Atributos de Procesamiento de Facturas

De la Compra al Pago - Actividades de Procesamiento de Facturas

Guías de Extracción

Exportación del Marco de Gestión de Datos de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo config

Consulta SQL Directa a través de Bring Your Own Database (BYOD)

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python utilizando la API REST OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Microsoft Power Platform Dataflow Extraction

Pasos

Configuración

a Consulta de ejemplo config

Valoramos su privacidad

¿Listo para comenzar?

Comience a Optimizar su Proceso de De la Compra al Pago - Procesamiento de Facturas Hoy