> Mejora continua de procesos > Requisición de compra a pago > Microsoft Dynamics 365 > Template de datos

Su Template de datos para solicitudes de compra del proceso de compra a pago

Microsoft Dynamics 365

Atributos de las solicitudes de compra del proceso de compra a pago(17) Actividades de las solicitudes de compra del proceso de compra a pago(12) Guías de extracción(3)

Su Template de datos para solicitudes de compra del proceso de compra a pago

Este Template describe los atributos clave que debe recopilar y las actividades importantes que debe registrar para analizar en detalle el proceso de solicitud de compra. También ofrece orientación práctica para extraer estos datos y preparar de forma eficiente el Registro de eventos para un análisis detallado.

Atributos recomendados para recopilar
Actividades clave que debe registrar
Guía de extracción

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

Descargar Template

Atributos de las solicitudes de compra del proceso de compra a pago

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar de forma exhaustiva el proceso de solicitud de compra del ciclo de compra a pago.

5 Obligatorio 6 Recomendado 6 Opcional

	Nombre	Descripción
	Hora del evento EventTime	Marca de tiempo exacta en que tuvo lugar una actividad o un evento específico.
Descripción La hora del evento, o marca de tiempo, registra la fecha y la hora en que se anotó un evento de negocio en el sistema. Es la base temporal de todos los análisis de procesos relacionados con el tiempo. Este atributo es fundamental para calcular los tiempos de ciclo, las duraciones y los tiempos de espera entre actividades. Permite analizar el rendimiento del proceso, identificar cuellos de botella y supervisar el cumplimiento de los SLA. Las marcas de tiempo precisas son esenciales para que el análisis de Process Mining sea fiable. Por qué es importante Establece el orden cronológico de los eventos, necesario para calcular la duración de los procesos, identificar cuellos de botella y analizar el rendimiento a lo largo del tiempo. Dónde obtenerlo Se encuentra en el historial del flujo de trabajo o en las tablas de registro de documentos, a menudo en un campo 'CreatedDateTime' o 'ModifiedDateTime' asociado a cada cambio de estado o registro de evento. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	ID de solicitud de compra PurchaseRequisitionId	Identificador único de una solicitud de compra, que sirve como identificador principal del caso.
Descripción El ID de solicitud de compra es la clave central que vincula todas las actividades relacionadas con una misma solicitud de bienes o servicios. Cada solicitud, desde su creación hasta su aprobación final y cierre, se registra con este ID único. En Process Mining, este atributo es fundamental para reconstruir el recorrido completo de cada solicitud. Permite analizar las variantes del proceso, los tiempos de ciclo y el cumplimiento de cada caso, y ofrece una visión completa del ciclo de vida de la solicitud. Por qué es importante Es esencial para agrupar todos los eventos relacionados en una sola instancia del proceso y permitir un análisis completo del ciclo de vida de cada solicitud. Dónde obtenerlo Suele ser la clave principal de la tabla principal de encabezados de solicitudes de compra, como PurchReqTable en Microsoft Dynamics 365. Ejemplos Solicitud-001254Solicitud-001255Solicitud-001256
	Nombre de la actividad ActivityName	Nombre del evento o paso de negocio específico que tuvo lugar en el proceso de solicitud.
Descripción Este atributo registra el nombre de cada actividad realizada durante el ciclo de vida de una solicitud de compra. Algunos ejemplos son 'Solicitud creada', 'Paso de aprobación aprobado' y 'Orden de compra creada'. Estas actividades forman los nodos del mapa de procesos descubierto. El análisis de la secuencia, la frecuencia y la duración entre estas actividades es la base del Process Mining. Ayuda a identificar cuellos de botella, ciclos de trabajo repetido y desviaciones del flujo estándar, y aporta información sobre las ineficiencias operativas. Por qué es importante Este atributo define los pasos del mapa de procesos y permite visualizar, analizar y comprender el flujo de trabajo de las solicitudes. Dónde obtenerlo Suele obtenerse de registros de cambios de estado, tablas del historial del flujo de trabajo o tablas de eventos específicas de Microsoft Dynamics 365, como WorkflowTrackingStatusTable. Ejemplos Solicitud enviada para aprobaciónPaso de aprobación aprobadoSolicitud modificada
	Sistema de origen SourceSystemId	Sistema de registro del que se extrajeron los datos.
Descripción Este atributo identifica el sistema de origen de los datos de eventos. En este contexto, sería 'Microsoft Dynamics 365'. En entornos con varios sistemas integrados, este campo es esencial para conocer la procedencia y el contexto de los datos. En el análisis, ayuda a distinguir los procesos que abarcan varios sistemas o a confirmar que los datos proceden de una única fuente de verdad. Esto es importante para validar los datos y garantizar que el análisis se base en el conjunto de datos correcto. Por qué es importante Aporta contexto sobre el origen de los datos, algo esencial para la gobernanza y la validación de datos, así como en entornos donde se integran varios sistemas. Dónde obtenerlo Es un valor estático, 'Microsoft Dynamics 365', que se añade durante la extracción y transformación de datos. Ejemplos Microsoft Dynamics 365 F&OD365MSD365
	Última actualización de datos LastDataIngestionTimestamp	Marca de tiempo de la última extracción de datos y su carga en la herramienta de Process Mining.
Descripción Este atributo indica la actualidad de los datos analizados. Muestra la fecha y la hora de la actualización más reciente desde el sistema de origen. No es un campo propio de Dynamics 365, sino metadatos que se añaden durante la incorporación de datos. Esta marca de tiempo es fundamental para que las personas usuarias sepan si la información está actualizada. Permite saber si se están consultando datos en tiempo real o una instantánea de un momento concreto, lo que influye en la relevancia de las conclusiones. Por qué es importante Informa sobre la actualidad de los datos y permite comprender el periodo que abarca el análisis y la relevancia de la información obtenida. Dónde obtenerlo Este valor se genera y se añade al conjunto de datos durante la incorporación de datos o el proceso ETL. Ejemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Departamento Department	Departamento de quien solicita o centro de costes asociado a la solicitud.
Descripción Este atributo especifica el departamento de negocio o el centro de costes que inició la solicitud de compra, como 'Marketing', 'TI' u 'Operaciones'. Esta información suele formar parte del encabezado de la solicitud. Segmentar el proceso por departamento es fundamental para realizar comparativas. Permite ver qué departamentos tienen los tiempos de ciclo más largos, las tasas de rechazo más altas o más modificaciones. Esta información ayuda a adaptar las mejoras del proceso a las necesidades de cada departamento. Por qué es importante Permite filtrar y comparar el rendimiento del proceso entre distintas unidades de negocio, y revela patrones, cuellos de botella o ineficiencias específicos de cada departamento. Dónde obtenerlo Esta información suele almacenarse en el encabezado de la solicitud de compra (PurchReqTable) y vincularse a la configuración de dimensiones financieras de Dynamics 365. Ejemplos Departamento de TIFinanzasOperaciones
	Estado de la solicitud RequisitionStatus	Estado actual o final de la solicitud de compra.
Descripción Este atributo indica el estado general de la solicitud de compra en un momento determinado, por ejemplo, «En revisión», «Aprobado», «Rechazado» o «Cerrado». Suele ser un atributo del caso que representa el resultado final. Analizar el estado final ayuda a comprender los resultados generales del proceso. Por ejemplo, un número elevado de solicitudes «Rechazadas» o «Retiradas» puede indicar problemas en la fase inicial de solicitud o un proceso de aprobación engorroso. Este dato es clave para medir las tasas de éxito y la eficiencia del proceso. Por qué es importante Ofrece un resultado claro para cada caso y permite analizar las tasas de aprobación, rechazo y retirada, que son indicadores clave del rendimiento. Dónde obtenerlo El campo de estado suele encontrarse en la tabla del encabezado de la solicitud de compra, PurchReqTable, y llamarse «Status» o «PurchReqStatus». Ejemplos AprobadoEn revisiónRechazadoBorrador
	Importe total de la solicitud RequisitionTotalAmount	Valor monetario total de la solicitud de compra.
Descripción Este atributo recoge el valor total de todas las líneas de una solicitud de compra. El importe suele influir en la complejidad del flujo de trabajo de aprobación: las solicitudes de mayor valor requieren más pasos de aprobación. En el análisis de procesos, este atributo es esencial para filtrar y analizar los datos según el valor. Ayuda a responder preguntas como «¿Las solicitudes de mayor valor tardan más en aprobarse?» o «¿Cuál es el valor de las solicitudes que están actualmente atascadas en el proceso?». Así, aporta contexto financiero al rendimiento del proceso. Por qué es importante Añade una dimensión financiera al análisis, permite priorizar los casos de mayor valor y ayuda a comprender cómo influye el importe en el comportamiento del proceso. Dónde obtenerlo Este valor suele encontrarse en la tabla del encabezado de la solicitud de compra o calcularse sumando los importes de las líneas de la tabla de líneas de solicitud de compra (PurchReqLine). Ejemplos 1500.0025000.50500.75
	Nivel de urgencia UrgencyLevel	Clasificación de la urgencia de la solicitud, por ejemplo, «Alta», «Media» o «Baja».
Descripción El nivel de urgencia o prioridad indica con qué rapidez se necesitan los bienes o servicios solicitados. Este atributo suele utilizarse para determinar la ruta de aprobación o priorizar el trabajo de quienes aprueban las solicitudes. Analizar este atributo ayuda a determinar si el sistema de prioridades es eficaz. Por ejemplo, puede comparar los tiempos de ciclo de las solicitudes de urgencia «Alta» con los de las solicitudes de urgencia «Baja». Si no hay una diferencia significativa, es posible que se esté ignorando o utilizando mal el campo de prioridad. Esta información es clave para el Dashboard «Análisis del impacto del nivel de urgencia». Por qué es importante Ayuda a evaluar si la configuración de prioridades acelera eficazmente las solicitudes críticas y permite detectar posibles usos indebidos de la clasificación de urgencia. Dónde obtenerlo Puede tratarse de un campo estándar o personalizado de PurchReqTable. Su existencia y nombre pueden variar según la configuración del sistema. Ejemplos AltaMediaBaja
	Paso de aprobación ApprovalStep	Nombre o etapa de un paso específico del flujo de trabajo de aprobación.
Descripción Este atributo identifica una etapa concreta del flujo de trabajo de aprobación, como «Aprobación del gerente» o «Aprobación de Finanzas». Ofrece más detalle que el nombre general de la actividad. Este atributo es esencial para el «Análisis de cuellos de botella en los pasos de aprobación». Al registrar el tiempo dedicado a cada paso de aprobación, es posible determinar exactamente qué etapas provocan demoras en el proceso general. Esto permite aplicar medidas específicas para mejorar la eficiencia del flujo de trabajo. Por qué es importante Permite analizar en detalle el flujo de trabajo de aprobación e identificar las etapas concretas que provocan cuellos de botella. Dónde obtenerlo Esta información se encuentra en las tablas del historial del flujo de trabajo, como WorkflowTrackingStatusTable, que detalla cada paso del flujo de trabajo configurado. Ejemplos Aprobación del gerenteAprobación de la dirección del departamentoRevisión de Finanzas
	Usuario User	ID o nombre del usuario que realizó la actividad.
Descripción Este atributo identifica a la persona empleada o al usuario del sistema responsable de ejecutar un paso específico del proceso, como enviar una solicitud o aprobarla. Puede ser un ID de usuario, el nombre completo o una dirección de correo electrónico. Analizar las actividades por usuario ayuda a detectar necesidades de formación, identificar a las personas o los equipos con mejor rendimiento y comprender cómo se distribuye la carga de trabajo. También es esencial para el análisis de cumplimiento, por ejemplo, para comprobar la segregación de funciones y entender cómo interactúan los distintos roles de usuario con el proceso. Por qué es importante Permite analizar el comportamiento, la carga de trabajo y el rendimiento de cada usuario, aspectos clave para gestionar los recursos e identificar oportunidades de formación. Dónde obtenerlo Suele encontrarse en tablas del historial del flujo de trabajo (por ejemplo, WorkflowTrackingStatusTable) o en tablas de transacciones (por ejemplo, PurchReqTable) vinculadas a una tabla de usuarios (por ejemplo, UserInfo). Ejemplos j.smitha.joness.patel
	Aprobada en el primer intento IsFirstPass	Indicador que señala si una solicitud se aprobó sin modificaciones ni rechazos previos.
Descripción Este atributo booleano calculado tiene el valor «true» si la ruta de aprobación de una solicitud no incluye ninguna actividad «Solicitud modificada» ni «Paso de aprobación rechazado». En caso contrario, tiene el valor «false». Este atributo permite calcular directamente el KPI «Tasa de aprobación de solicitudes en el primer intento». Facilita el análisis de la eficiencia del proceso al indicar claramente, a nivel de caso, si hubo que repetir trabajo. Una tasa baja de aprobaciones en el primer intento pone de manifiesto problemas con la calidad inicial de los datos o con la claridad de los requisitos, y señala una oportunidad para mejorar el proceso. Por qué es importante Mide directamente la calidad y la eficiencia del proceso al identificar los casos que requirieron repetir trabajo, y permite calcular KPI centrados en la resolución correcta desde el primer intento. Dónde obtenerlo Es un atributo calculado. Durante la transformación de datos, es necesario analizar la secuencia completa de actividades de cada caso para comprobar que no haya actividades de repetición antes de la aprobación. Ejemplos truefalse
	Grupo de aprobación ApproverGroup	Grupo de usuarios o rol responsable de un paso de aprobación.
Descripción Este atributo identifica el grupo, rol o cola asignados para gestionar una tarea de aprobación específica, por ejemplo, «Aprobadores de Finanzas» o «Gerentes de TI». Analizar el rendimiento del proceso por grupo de aprobación es clave para comprender cómo se distribuye la carga de trabajo e identificar qué grupos podrían necesitar más recursos o formación adicional. También permite analizar por equipo responsable de las aprobaciones el rendimiento que muestra el Dashboard «Análisis de cuellos de botella en los pasos de aprobación». Por qué es importante Ayuda a identificar diferencias de rendimiento entre los equipos de aprobación y a detectar posibles limitaciones de recursos o necesidades de formación en grupos concretos. Dónde obtenerlo Esta información forma parte del historial del flujo de trabajo (por ejemplo, WorkflowTrackingStatusTable), que registra el usuario o grupo de usuarios asignado a cada tarea. Ejemplos Aprobadores de FinanzasGerentes de TIAlta dirección
	Moneda Currency	Código de moneda del importe de la solicitud.
Descripción Este atributo especifica la moneda, por ejemplo, USD, EUR o GBP, en la que se expresa el importe total de la solicitud. Es fundamental para el análisis financiero, sobre todo en organizaciones multinacionales que trabajan con varias monedas. El atributo de moneda permite gestionar y agregar correctamente los datos financieros. Garantiza que los valores monetarios se interpreten de forma adecuada y permite convertirlos a una moneda común para elaborar informes precisos y comparar distintas regiones o unidades de negocio. Por qué es importante Aporta el contexto necesario para interpretar los atributos financieros y agregar correctamente los valores monetarios en entornos con varias monedas. Dónde obtenerlo Este campo suele encontrarse en la tabla del encabezado de la solicitud de compra, PurchReqTable, junto a los campos de importe. Ejemplos USDEURGBP
	Número de modificaciones AmendmentCount	Número total de veces que se modificó una solicitud.
Descripción Este atributo numérico calculado cuenta las veces que se realiza la actividad «Solicitud modificada» en cada caso de solicitud de compra. Este atributo es esencial para el Dashboard «Frecuencia de modificación de solicitudes» y el KPI «Proporción de solicitudes modificadas». Cuantifica el trabajo repetido en cada caso y facilita la identificación de las solicitudes, los departamentos o los usuarios asociados a un alto nivel de cambios e ineficiencia. Esta información ayuda a orientar las iniciativas para mejorar la calidad de las solicitudes iniciales. Por qué es importante Cuantifica el trabajo repetido en un caso y facilita la medición y el análisis de la frecuencia de las modificaciones y su impacto en la eficiencia del proceso. Dónde obtenerlo Es un atributo calculado. Se obtiene durante la transformación de datos contando las actividades «Solicitud modificada» para cada PurchaseRequisitionId único. Ejemplos 013
	Número de orden de compra PurchaseOrderNumber	Identificador de la orden de compra creada a partir de la solicitud.
Descripción Este atributo almacena el ID único de la orden de compra generada a partir de una solicitud de compra aprobada. Vincula el proceso de solicitud con el proceso de compras posterior. Registrar este número es esencial para analizar el «Tiempo de conversión de solicitud a orden de compra». Confirma que la solicitud ha pasado correctamente a la siguiente etapa del ciclo de compra a pago y permite analizar de principio a fin tanto las solicitudes como las órdenes de compra. Por qué es importante Vincula la solicitud con la orden de compra posterior, permite analizar la conversión de solicitud a orden de compra y conecta distintas etapas del proceso de compra a pago. Dónde obtenerlo Esta información suele encontrarse en la tabla de líneas de solicitud de compra (PurchReqLine) una vez creada la orden de compra, con un vínculo a PurchTable. Ejemplos OC-000987OC-000988OC-000989
	Ruta del flujo de trabajo de aprobación ApprovalWorkflowPath	Representación de la secuencia de pasos de aprobación realizados.
Descripción Este atributo es un campo derivado que concatena la secuencia de pasos de aprobación de una solicitud, por ejemplo, «Aprobación del gerente -> Aprobación de la dirección del departamento -> Aprobación de Finanzas». Resume la variante del proceso del subproceso de aprobación. Es fundamental para el Dashboard «Monitor de desviaciones de cumplimiento». Al comparar la ruta real del flujo de trabajo con una ruta estándar o prevista, resulta fácil señalar los flujos de proceso que no cumplen los requisitos o son inusuales y que podrían indicar incumplimientos de políticas o riesgos operativos. Por qué es importante Simplifica el análisis de cumplimiento al representar claramente la variante del proceso en una cadena de texto, lo que facilita detectar desviaciones de los procedimientos estándar. Dónde obtenerlo No es un campo estándar. Debe obtenerse concatenando los valores de «ApprovalStep» en orden cronológico para cada caso durante la transformación de datos. Ejemplos Gerente -> DirectorGerente -> Director -> Vicepresidente de FinanzasGerente -> Aprobación automática

Obligatorio Recomendado Opcional

Actividades de las solicitudes de compra del proceso de compra a pago

Estos son los pasos y los hitos esenciales del proceso que debe registrar en el Registro de eventos para descubrir y analizar con precisión el flujo de trabajo de solicitud de compra.

7 Recomendado 5 Opcional

	Actividad	Descripción
	Orden de compra creada	Una línea aprobada de la solicitud de compra se convierte en una línea de orden de compra, lo que indica el traspaso al equipo de compras. Se registra vinculando la línea de solicitud con una línea de orden de compra.
Por qué es importante Este es un hito clave que conecta la solicitud con el proceso de compras posterior. Es esencial para medir el KPI de tiempo de conversión de solicitud a orden de compra. Dónde obtenerlo Se infiere al encontrar en la tabla 'PurchLine' un registro que haga referencia al ID de una 'PurchReqLine' asociada al caso de solicitud. Capturar Una PurchReqLine con PurchLine mediante el campo de referencia que las vincula (por ejemplo, PurchReqLineRefId). Tipo de evento inferred
	Paso de aprobación aprobado	La persona aprobadora completa la tarea asignada y aprueba la solicitud en esa etapa del proceso. La solicitud pasa entonces al siguiente paso o a la aprobación final.
Por qué es importante Mide el tiempo de procesamiento de cada etapa de aprobación y ayuda a localizar las partes más eficientes del flujo de trabajo. Es un componente clave del análisis de variantes. Dónde obtenerlo Se registra explícitamente en 'WorkflowTrackingStatusTable' cuando un usuario completa un elemento de trabajo con el resultado 'Approve'. Capturar Identifique en los registros del historial del flujo de trabajo los eventos 'WorkItemCompleted' con el resultado 'Approve'. Tipo de evento explicit
	Solicitud aprobada	La solicitud ha superado correctamente todos los pasos de aprobación requeridos en el flujo de trabajo. Esta actividad se registra cuando la instancia del flujo de trabajo finaliza con el estado de aprobación correspondiente.
Por qué es importante Este es un hito importante: marca el final del ciclo de aprobación y el inicio de la fase de compras. Es el evento de fin del KPI de tiempo de ciclo de aprobación de solicitudes. Dónde obtenerlo Se registra explícitamente en 'WorkflowTrackingStatusTable' cuando finaliza el flujo de trabajo. También actualiza el campo 'Status' de 'PurchReqTable' a 'Approved'. Capturar Filtre los eventos 'Completion' del flujo de trabajo con estado 'Approved' o haga un seguimiento de los cambios de estado en PurchReqTable. Tipo de evento explicit
	Solicitud cerrada	La solicitud de compra completa se considera finalizada cuando todas sus líneas se han procesado como órdenes de compra o se han cancelado. Este es un estado final satisfactorio.
Por qué es importante Esta actividad marca la finalización satisfactoria del ciclo de vida de la solicitud. Es el punto final para medir la duración total del proceso de principio a fin. Dónde obtenerlo Este estado suele calcularse o inferirse. Se produce cuando todos los registros 'PurchReqLine' asociados alcanzan un estado final, como 'Closed' o 'Cancelled'. Capturar Derive este evento comprobando si todos los registros secundarios PurchReqLine de una PurchReqTable tienen un estado final. Tipo de evento calculated
	Solicitud creada	Este evento marca la creación inicial del registro de solicitud de compra, que queda en estado de borrador. Se registra a partir de la marca de tiempo de creación del encabezado de la solicitud.
Por qué es importante Como inicio del proceso, esta actividad es esencial para medir la duración total del ciclo de vida de las solicitudes y analizar el volumen diario de solicitudes procesadas. Dónde obtenerlo Esta actividad se infiere del campo 'createdDateTime' de 'PurchReqTable' para cada ID de solicitud de compra nuevo. Capturar Utilice la marca de tiempo de creación del registro en PurchReqTable. Tipo de evento inferred
	Solicitud enviada para aprobación	El usuario envía la solicitud completada, lo que inicia el flujo de trabajo formal de aprobación. El motor de flujo de trabajo del sistema registra esta acción explícita.
Por qué es importante Esta actividad es un hito clave que da inicio al ciclo de aprobación. Es el punto de partida para medir el tiempo de ciclo de aprobación de solicitudes y la tasa de aprobación en el primer intento. Dónde obtenerlo Se registra en 'WorkflowTrackingStatusTable' o en una tabla similar del historial del flujo de trabajo, donde se anota un evento 'Submission' asociado a la solicitud de compra. Capturar Filtre los registros del historial del flujo de trabajo por el tipo de evento 'Submission' o 'Start' asociado a la solicitud. Tipo de evento explicit
	Solicitud rechazada	La solicitud se ha rechazado durante el flujo de trabajo de aprobación y no seguirá procesándose. Esto representa un estado de fallo terminal para la solicitud.
Por qué es importante Este evento de fin es esencial para analizar la tasa general de rechazos y comprender el impacto financiero u operativo de las solicitudes rechazadas. Dónde obtenerlo Se registra explícitamente en 'WorkflowTrackingStatusTable' cuando el flujo de trabajo finaliza con el estado 'Rejected', lo que actualiza el campo de estado de 'PurchReqTable'. Capturar Filtre los eventos 'Completion' del flujo de trabajo con estado 'Rejected' o haga un seguimiento de los cambios de estado en PurchReqTable. Tipo de evento explicit
	Línea de solicitud cerrada	Se considera que una línea individual de la solicitud de compra se ha procesado por completo. Esto suele ocurrir cuando la línea se ha convertido íntegramente en una orden de compra.
Por qué es importante Ofrece información detallada sobre el cumplimiento de las solicitudes y ayuda a determinar si se convierten parcial o totalmente en órdenes de compra. Dónde obtenerlo Se infiere del campo de estado de la tabla individual 'PurchReqLine'. Un estado que indique que el artículo se ha pedido o recibido señalaría el cierre. Capturar Supervise el campo de estado de la tabla PurchReqLine para detectar un valor final, como 'Invoiced' o 'Closed'. Tipo de evento inferred
	Paso de aprobación iniciado	Como parte del flujo de trabajo, se asigna una tarea de aprobación individual a un usuario o grupo. Esto marca el inicio del tiempo de espera o de procesamiento de una persona aprobadora específica.
Por qué es importante Esta actividad es esencial para el análisis de cuellos de botella en los pasos de aprobación, ya que permite medir los tiempos de espera en cada etapa. Dónde obtenerlo Se registra en 'WorkflowTrackingStatusTable' cuando se crea un nuevo elemento de trabajo y se asigna a la instancia del flujo de trabajo de la solicitud. Capturar Identifique los eventos 'WorkItemCreated' o similares en los registros del historial del flujo de trabajo de la solicitud correspondiente. Tipo de evento explicit
	Paso de aprobación rechazado	La persona aprobadora rechaza la tarea asignada y, por lo general, devuelve la solicitud a quien la inició para que la corrija. El motor de flujo de trabajo registra esta acción explícita.
Por qué es importante Esta actividad es fundamental para calcular la tasa de rechazo de solicitudes e identificar las etapas en las que se producen más rechazos, lo que permite detectar oportunidades de mejora del proceso. Dónde obtenerlo Se registra explícitamente en 'WorkflowTrackingStatusTable' cuando un usuario completa un elemento de trabajo con el resultado 'Reject'. Capturar Identifique en los registros del historial del flujo de trabajo los eventos 'WorkItemCompleted' con el resultado 'Reject'. Tipo de evento explicit
	Solicitud modificada	Este evento ocurre cuando un usuario retira del flujo de trabajo una solicitud enviada para modificarla. Por lo general, se identifica mediante una acción de retirada seguida de un nuevo envío posterior.
Por qué es importante Registrar las modificaciones es fundamental para detectar el trabajo repetido, las solicitudes iniciales poco claras y las ineficiencias del proceso. Esta información alimenta directamente el Dashboard de frecuencia de modificación de solicitudes. Dónde obtenerlo Puede inferirse del historial del flujo de trabajo ('WorkflowTrackingStatusTable') al detectar una acción 'Recall' o 'RequestChange'. También puede inferirse de los cambios en el campo 'modifiedDateTime' de 'PurchReqTable' después del envío. Capturar Detecte los eventos de retirada del flujo de trabajo o los cambios de versión del registro entre envíos. Tipo de evento inferred
	Solicitud retirada	La persona que creó la solicitud o un usuario autorizado la cancela después de su envío. Esta acción pone fin al flujo de trabajo y a la solicitud.
Por qué es importante El seguimiento de las retiradas ayuda a detectar problemas en la planificación de la demanda o procesos demasiado complejos. Esta información alimenta el Dashboard de análisis de retiradas de solicitudes. Dónde obtenerlo Se infiere de un cambio de estado a 'Cancelled' en 'PurchReqTable' o de un evento 'Cancel' en 'WorkflowTrackingStatusTable'. Capturar Detecte los cambios de estado a 'Cancelled' en PurchReqTable o los eventos de cancelación del flujo de trabajo. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Microsoft Dynamics 365

Pasos

Acceda al espacio de trabajo de administración de datos: Inicie sesión en Microsoft Dynamics 365 y vaya al menú Workspaces. Seleccione Data management para abrir el centro de operaciones de importación y exportación de datos.
Cree un proyecto de exportación: En el espacio de trabajo de administración de datos, haga clic en el mosaico Export. Indique un Nombre del Group único, una Descripción y establezca Project category en Project. Así podrá organizar las tareas de extracción de datos.
Agregue entidades de datos: Añada al proyecto las entidades de datos estándar necesarias. Haga clic en Add entity, busque cada una de las siguientes entidades y agréguelas una por una:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Defina el formato de exportación: Para cada entidad agregada, seleccione un Target data format, como CSV o Excel. Por lo general, se recomienda CSV por su rendimiento y compatibilidad con las herramientas de transformación de datos.
Aplique filtros a los datos: Seleccione una entidad y haga clic en Filtrar. En la pestaña Rango, especifique la Legal entity (código de empresa) para asegurarse de extraer datos de la unidad de negocio correcta. También es fundamental filtrar por fecha el campo Created date and time de la entidad Purchase requisition headers para limitar el volumen de datos. Se recomienda comenzar con un período de 3 a 6 meses.
Ejecute la exportación: Una vez configuradas todas las entidades y los filtros, haga clic en Export en el panel de acciones. El sistema creará un paquete de trabajo y comenzará a procesarlo. Puede consultar el avance en la sección Job history.
Descargue el paquete de datos: Cuando la exportación termine correctamente, vaya a los detalles de Job history y haga clic en Download package. Se descargará un archivo ZIP con archivos de datos separados para cada entidad.
Transforme los datos sin procesar en un registro de eventos: Los archivos exportados contienen tablas sin procesar del sistema, no un registro de eventos listo para usar. Utilice una herramienta externa, como Python, Power Query o una plataforma ETL, para combinar y reorganizar los datos. Para ello:
- Una los archivos de encabezados y líneas.
- Una los datos del flujo de trabajo con las requisiciones mediante CorrelationId y el RecId del encabezado de la requisición de compra.
- Convierta los cambios de estado y los eventos del flujo de trabajo de las tablas correspondientes en filas de actividad independientes (Requisition Submitted, Approval Step Approved, etc.).
- Cree una fila por cada actividad con los valores correctos de ActivityName, EventTime y PurchaseRequisitionId.
Calcule y asigne los atributos: Durante la transformación, asigne las columnas de origen a los atributos necesarios, como Usuario y Departamento. Calcule atributos derivados, como RequisitionTotalAmount, sumando los importes de las líneas. Asigne un valor estático a SourceSystemId (por ejemplo, 'D365_F&O') y utilice la hora de ejecución del script para LastDataIngestionTimestamp.
Prepare y dé formato al resultado: Asegúrese de que el archivo final sea un único CSV en el que cada fila represente un evento del proceso. Las columnas deben coincidir con la estructura requerida del registro de eventos, incluidos PurchaseRequisitionId, ActivityName y EventTime.

Configuración

Permisos necesarios: Los usuarios deben tener un rol de seguridad con permisos para acceder al espacio de trabajo Data management y a las entidades de datos específicas que se exportarán, como Data management administrator o un rol personalizado equivalente.
Entidades de datos clave:
- Purchase requisition headers: proporciona el identificador principal del caso, la fecha y hora de creación y el estado general.
- Purchase requisition lines: contiene información sobre cada artículo solicitado, incluidos los importes y los vínculos con las órdenes de compra.
- Workflow tracking status table: es la fuente principal de eventos del flujo de trabajo, como el envío, la aprobación, el rechazo y la retirada.
- Workflow work items: detalla las tareas específicas asignadas a los usuarios durante el proceso de aprobación.
- Purchase order lines V2: permite obtener la fecha y hora de creación de la orden de compra vinculada a una línea de requisición.
Filtro por período: Es fundamental aplicar un filtro de fechas al campo Created date and time de la entidad Purchase requisition headers. Para el análisis inicial, se recomienda un período de 3 a 6 meses, a fin de equilibrar el volumen de datos y la información que ofrece el proceso.
Filtro por código de empresa: Aplique siempre un filtro para Legal entity y así evitar extraer datos de empresas no previstas o de prueba. Esto reduce considerablemente el tamaño de los datos y mejora el rendimiento de la tarea.
Transformación de datos: Este método requiere un paso importante de posprocesamiento fuera de Dynamics 365 para convertir las exportaciones de entidades sin procesar en un registro de eventos estructurado. Necesitará una herramienta de scripting o ETL.

Consulta de ejemplo sql

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Pasos

Registre una aplicación en Azure Active Directory: Vaya al portal de Azure y registre una aplicación nueva. Esta aplicación se utilizará para autenticarse en la API de Dynamics 365. Anote el identificador de aplicación (cliente) y el identificador de directorio (inquilino).
Genere un secreto de cliente: En la aplicación recién registrada en Azure, cree un secreto de cliente en 'Certificates & secrets'. Guarde el valor del secreto en un lugar seguro, ya que no volverá a estar disponible.
Conceda permisos de API: En la sección 'API permissions' de la aplicación, agregue un permiso para 'Dynamics ERP'. Seleccione 'Delegated permissions' y conceda Financials.ReadWrite.All o un permiso equivalente más restrictivo, de solo lectura. Conceda el consentimiento de administrador para los permisos.
Instale las bibliotecas de Python: Compruebe que Python esté instalado. Después, instale las bibliotecas necesarias con pip: pip install requests pandas.
Configure el script de Python: Copie el script de Python proporcionado en un archivo, por ejemplo, extract_d365_requisitions.py. Complete las variables de marcador de posición al principio del script: URL de Dynamics 365, identificador de inquilino, identificador de cliente, secreto de cliente, período deseado e identificador de empresa.
Revise las entidades OData: El script consulta tres entidades de datos principales: PurchaseRequisitionHeaders, con los detalles generales de las requisiciones; PurchaseRequisitionLines, con los datos de cada línea, incluida su conversión en órdenes de compra; y WorkflowTrackingStatusTable, con los eventos del flujo de trabajo, como envíos y aprobaciones.
Ejecute el script: Ejecútelo desde la línea de comandos: python extract_d365_requisitions.py. El script se autenticará, obtendrá los datos de cada actividad y gestionará automáticamente la paginación de la API.
Transforme los datos: El script procesa los datos JSON sin procesar de las llamadas a la API. Reorganiza los datos recorriendo los registros y creando una fila independiente para cada una de las 12 actividades empresariales. Asigna los campos de origen a las columnas estándar del registro de eventos, como PurchaseRequisitionId, ActivityName y EventTime.
Combine y estandarice los eventos: El script reúne todos los eventos generados en una sola lista y la convierte en un DataFrame de pandas. También agrega columnas estáticas, como SourceSystemId y LastDataIngestionTimestamp.
Exporte a CSV: El DataFrame final se exporta a un archivo CSV llamado d365_purchase_requisition_log.csv. El archivo está preparado para cargarse directamente en una herramienta de Process Mining. Compruebe que esté codificado en UTF-8.

Configuración

Requisitos previos: Acceso a una suscripción de Azure para registrar una aplicación. Necesitará un identificador de aplicación (cliente), un secreto de cliente y un identificador de inquilino de Azure Active Directory. La persona que ejecute el script necesita credenciales con acceso a los puntos de conexión de la API OData de Dynamics 365 Finance and Operations.
Configuración del punto de conexión de la API: El script necesita la URL base de su entorno de Dynamics 365, que suele tener el formato https://[your-environment-name].operations.dynamics.com.
Período: Defina el período de extracción mediante las variables START_DATE y END_DATE del script. Para el análisis inicial, se recomienda un período de 3 a 6 meses, a fin de equilibrar el volumen de datos y la información obtenida.
Filtro por empresa: El script utiliza la variable COMPANY_ID para filtrar una entidad jurídica específica. Para extraer datos de todas las empresas, quizá deba modificar el filtro OData e incluir cross-company=true en los encabezados de la solicitud.
Consideraciones de rendimiento: El script utiliza $select en las consultas OData para obtener solo las columnas necesarias para el registro de eventos, lo que mejora el rendimiento. También gestiona la paginación para procesar conjuntos de datos grandes sin sobrecargar la API. Para cargas históricas muy grandes, considere ejecutar el script por lotes con períodos más cortos.

Consulta de ejemplo python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

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

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

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

Pasos

Confirme que el conector nativo de Microsoft Dynamics 365 Finance esté disponible en Power BI Desktop y que la cuenta tenga autorización para acceder a las entidades de datos necesarias, al historial del flujo de trabajo, a los datos de requisiciones y a los datos relacionados de órdenes de compra.
En Power BI Desktop, seleccione Get data, elija el conector de Microsoft Dynamics 365 Finance e indique la URL de la instancia de Dynamics 365 Finance. Inicie sesión con una cuenta autorizada para leer las entidades necesarias. Sustituya [Your Dynamics 365 Finance instance URL] por la URL de la instancia de su entorno.
En Navigator, seleccione las entidades de encabezados y líneas de requisiciones de compra, las entidades del historial o seguimiento del flujo de trabajo, las entidades de usuarios y organización, y las entidades de órdenes de compra que requiera su implementación. Los nombres de las entidades y los campos disponibles varían según el entorno. Consulte los metadatos de las entidades y sustituya cada marcador de posición de la consulta por la entidad y el campo correspondientes que exponga su sistema.
Cargue las entidades seleccionadas en Power Query. Filtre los datos por la entidad jurídica o empresa, el tipo de documento y el período de extracción requeridos. Utilice los parámetros [Start date] y [End date], y conserve los registros cuya marca de tiempo del evento esté dentro del período seleccionado. Incluya los registros creados antes de la fecha inicial si tienen eventos del flujo de trabajo o de cierre dentro del período, para mantener completo el historial de los casos.
Estandarice los identificadores y las marcas de tiempo. Convierta el identificador de la requisición de compra en texto, convierta todas las marcas de tiempo de eventos a una misma zona horaria, UTC o la zona horaria empresarial, y conserve la precisión original. Asegúrese de que el identificador del encabezado de la requisición esté disponible en cada fila de evento. Si los registros del flujo de trabajo solo contienen un identificador de correlación, únalos al encabezado de la requisición mediante la relación documentada y configurada en su entorno.
Cree una consulta de eventos para cada actividad requerida. Las consultas deben devolver explícitamente filas para Requisition Created, Requisition Submitted for Approval, Requisition Amended, Approval Step Started, Approval Step Approved, Approval Step Rejected, Requisition Approved, Requisition Rejected, Requisition Withdrawn, Purchase Order Created, Requisition Line Closed y Requisition Closed. No dependa de ProcessMind para deducir actividades a partir de cambios de estado o del orden de los eventos.
Para Requisition Amended, aplique la lógica documentada de retirada y reenvío del historial del flujo de trabajo. Una acción de retirada seguida de un envío posterior debe generar un evento de modificación en la marca de tiempo de la retirada o en la marca de tiempo de modificación que exponga la entidad de origen. No cree una fila de modificación únicamente porque haya cambiado el estado de la requisición, salvo que el sistema de origen registre explícitamente ese cambio como una modificación.
Para los eventos de líneas y órdenes de compra, una las líneas de requisición con las líneas de órdenes de compra mediante la relación de origen documentada. Si el registro de eventos se basa en casos identificados por PurchaseRequisitionId, agregue los eventos de línea o conserve cada uno en una fila independiente con el mismo identificador de caso. Cuando estén disponibles, conserve los identificadores de línea en columnas adicionales, aunque no sean atributos obligatorios.
Añada las columnas de salida obligatorias PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId y LastDataIngestionTimestamp. Añada las columnas recomendadas User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel y ApprovalStep. Si un valor no está disponible, utilice null en lugar de inventarlo. Para SourceSystemId, utilice un valor de origen uniforme, como Dynamics 365 Finance.
Combine todas las consultas de actividades con UNION ALL, elimine las filas sin identificador de caso o marca de tiempo del evento y ordene los resultados por PurchaseRequisitionId y EventTime. Conserve los eventos duplicados si corresponden a tareas distintas del flujo de trabajo o a líneas de requisición diferentes. Elimine duplicados solo cuando se haya confirmado que los registros de origen son extracciones duplicadas.
Valide el registro de eventos con las comprobaciones que se describen a continuación. Confirme que cada actividad requerida aparezca en filas explícitas, que las marcas de tiempo estén dentro del período seleccionado y que las uniones no multipliquen eventos de forma inesperada.
Cargue o exporte la tabla final en formato CSV o en otro formato de registro de eventos compatible con ProcessMind. Asigne PurchaseRequisitionId como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento. Mantenga SourceSystemId y LastDataIngestionTimestamp como atributos del evento y conserve todos los atributos recomendados que estén disponibles.

Configuración

Conector y origen: Utilice el conector nativo de Microsoft Dynamics 365 Finance en Power BI Desktop. Sustituya [Your Dynamics 365 Finance instance URL] por la URL del entorno. Confirme los nombres de las entidades y los campos en los metadatos de Navigator para la implementación específica.
Entidades necesarias: Seleccione las entidades de encabezados y líneas de requisiciones de compra, las entidades de seguimiento o historial del flujo de trabajo, las entidades de encabezados y líneas de órdenes de compra y las entidades de usuarios u organización necesarias para enriquecer los datos. Utilice los marcadores de posición [Your entity name] hasta confirmar los nombres exactos de las entidades.
Período: Comience con entre tres y seis meses de datos. Incluya los encabezados históricos de requisiciones que tengan eventos del flujo de trabajo, de órdenes de compra, de cierre de línea o de cierre de requisición durante el período seleccionado.
Filtros de empresa y documento: Aplique los filtros [Your company or legal entity filter] y [Your document type filter], cuando corresponda. Confirme si el identificador de requisición es único en todo el sistema o solo dentro de una empresa.
Alcance del flujo de trabajo: Incluya las acciones de envío, retirada, reenvío, asignación de tareas, aprobación, rechazo, retiro, finalización y cancelación. Configure las correspondencias entre acciones y estados del flujo de trabajo según los valores utilizados en el entorno.
Semántica de eventos: Cada actividad debe aparecer como una fila de evento explícita. ProcessMind no deduce eventos de aprobación, modificación, cierre o conversión a partir de otras filas.
Gestión de marcas de tiempo: Estandarice todas las marcas de tiempo en una sola zona horaria. Documente si las marcas de tiempo de origen están almacenadas en UTC o en la hora local de la empresa. Utilice la marca de tiempo de origen con la mayor precisión disponible.
Actualización incremental: Para las extracciones periódicas, utilice como marca de control la fecha y hora más reciente de modificación o evento de origen, junto con un período de solapamiento que permita capturar registros tardíos del flujo de trabajo. Concilie los datos del período de solapamiento antes de cargar el registro de eventos final.
Rendimiento: Filtre las entidades de origen antes de unirlas, seleccione solo las columnas necesarias, evite cargar registros históricos innecesarios del flujo de trabajo y utilice el plegado de consultas cuando sea compatible. Extraiga por separado los encabezados, las líneas, los eventos del flujo de trabajo y las relaciones con las órdenes de compra antes de combinarlos.
Autorizaciones y requisitos previos: La cuenta necesita acceso de lectura a las entidades de datos y a los datos del flujo de trabajo seleccionados de Dynamics 365 Finance. Confirme que estén habilitadas las funciones de compras y del flujo de trabajo pertinentes, y que las políticas de seguridad de la organización permitan la extracción mediante Power BI Desktop, el conector y la configuración de la puerta de enlace, si corresponde.
Moneda e importes: Confirme qué moneda representa RequisitionTotalAmount. Si las requisiciones pueden incluir varias monedas, añada la moneda de origen como atributo adicional y no convierta los importes sin indicarlo.
Gestión de valores nulos: Los atributos recomendados pueden tener valores nulos si el sistema de origen no almacena el valor, si el acceso está restringido por seguridad o si no se puede resolver la relación. Valide los valores obligatorios de caso, actividad y marca de tiempo del evento antes de exportar.

Consulta de ejemplo sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

¿Todo listo para comenzar?

Con este Template, tiene todo lo necesario para empezar a optimizar el proceso de solicitud de compra del ciclo de compra a pago. Empiece hoy mismo a descubrir información valiosa.

Volver a la guía de mejora

Descargar Template

Optimice el proceso de Compra a pago: requisiciones para agilizar las aprobaciones

Elimine demoras y reduzca un 30 % los tiempos de ciclo en Dynamics 365.

Comience hoy su prueba gratuita.

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

Su Template de datos para solicitudes de compra del proceso de compra a pago

Su Template de datos para solicitudes de compra del proceso de compra a pago

Atributos de las solicitudes de compra del proceso de compra a pago

Actividades de las solicitudes de compra del proceso de compra a pago

Guías de extracción

Exportación desde el marco de administración de datos de Dynamics 365

Pasos

Configuración

Consulta de ejemplo sql

Script de Python con la API REST OData de Dynamics 365

Pasos

Configuración

Consulta de ejemplo python

Extracción mediante el conector nativo de Microsoft Power BI

Pasos

Configuración

Consulta de ejemplo sql

¿Todo listo para comenzar?

Optimice el proceso de Compra a pago: requisiciones para agilizar las aprobaciones