> Mejora continua de procesos > Purchase to Pay Requisition > Microsoft Dynamics 365 > Template de datos

Su Template de datos de Purchase to Pay - Requisition

Microsoft Dynamics 365

Purchase to Pay - Requisition: Atributos (17) Purchase to Pay - Requisition: actividades (12) Guías de extracción (3)

Su Template de datos de Purchase to Pay - Requisition

Esta plantilla describe los atributos clave que debe recopilar y las actividades esenciales que debe registrar para analizar en profundidad su proceso de solicitudes. También ofrece orientación práctica para extraer estos datos y preparar eficazmente su 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 de Process Mining.

Descargar Template

Purchase to Pay - Requisition: Atributos

Estos son los campos de datos recomendados para incluir en su registro de eventos y realizar un análisis completo de su proceso Purchase to Pay - Requisition.

5 Obligatorio 6 Recomendado 6 Opcional

	Nombre	Descripción
	Hora del evento EventTime	La marca de tiempo exacta en la que tuvo lugar una actividad o evento específico.
Descripción La hora del evento, o marca de tiempo, registra la fecha y la hora en que se registró un evento empresarial en el sistema. Constituye la base temporal de todos los análisis de procesos basados en 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 realizar un análisis de process mining fiable. Por qué es importante Proporciona 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 tablas del historial de Workflow o de registros 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 la solicitud de compra PurchaseRequisitionId	El identificador único de una requisición de compra, que actúa como identificador principal del caso.
Descripción Purchase Requisition ID es la clave central que vincula todas las actividades relacionadas con una única solicitud de bienes o servicios. Cada proceso de requisición, desde su creación hasta la aprobación final y el cierre, se rastrea mediante este ID único. En process mining, este atributo es fundamental para reconstruir el recorrido completo de cada requisición. 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 requisición. Por qué es importante Es esencial para agrupar todos los eventos relacionados en una única instancia del proceso y permitir un análisis completo, de principio a fin, del ciclo de vida de cada requisición. Dónde obtenerlo Normalmente es la clave principal de la tabla de cabecera de requisiciones de compra, como PurchReqTable en Microsoft Dynamics 365. Ejemplos PR-001254PR-001255PR-001256
	Nombre de la actividad ActivityName	El nombre del evento empresarial o paso específico que tuvo lugar en el proceso de requisiciones.
Descripción Este atributo registra el nombre de cada actividad realizada durante el ciclo de vida de la requisición de compra. Algunos ejemplos son 'Requisition Created', 'Approval Step Approved' y 'Purchase Order Created'. Estas actividades forman los nodos del mapa de procesos descubierto. Analizar la secuencia, la frecuencia y la duración entre estas actividades constituye el núcleo del process mining. Ayuda a identificar cuellos de botella, ciclos de retrabajo y desviaciones del flujo de proceso estándar, y proporciona 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 Workflow de requisiciones. Dónde obtenerlo Normalmente se obtiene de registros de cambios de estado, tablas del historial de Workflow o tablas de eventos específicas de Microsoft Dynamics 365, como WorkflowTrackingStatusTable. Ejemplos Requisición enviada para aprobaciónPaso de aprobación aprobadoRequisición modificada
	Sistema de origen SourceSystemId	El sistema de registro del que se extrajeron los datos.
Descripción Este atributo identifica el sistema de origen del que proceden los datos de eventos. En este contexto, sería 'Microsoft Dynamics 365'. En entornos con varios sistemas integrados, este campo es fundamental para la trazabilidad y el contexto de los datos. En el análisis, ayuda a diferenciar procesos que pueden abarcar varios sistemas o confirma que los datos proceden de una fuente única y autorizada. 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 Proporciona contexto sobre el origen de los datos, algo fundamental para la gobernanza y validación de datos y para los entornos en los que se integran varios sistemas. Dónde obtenerlo Es un valor estático, 'Microsoft Dynamics 365', que se añade durante el proceso de extracción y transformación de datos. Ejemplos Microsoft Dynamics 365 F&OD365MSD365
	Última actualización de datos LastDataIngestionTimestamp	La marca de tiempo en la que los datos se extrajeron y cargaron por última vez 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 de los datos desde el sistema de origen. No es un campo propio de Dynamics 365, sino metadatos añadidos durante la incorporación de datos. Esta marca de tiempo es fundamental para que los usuarios comprendan la vigencia de la información. Les permite saber si están consultando datos en tiempo real o una instantánea de un momento concreto, lo que afecta a la relevancia de sus conclusiones. Por qué es importante Informa a los usuarios sobre la actualidad de los datos y garantiza que comprendan el periodo del 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 el proceso de incorporación de datos o ETL. Ejemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Departamento Department	El departamento de la persona solicitante o el centro de costos asociado a la requisición.
Descripción Este atributo especifica el departamento empresarial o centro de costos que inició la requisición de compra, como 'Marketing', 'TI' u 'Operaciones'. Esta información suele formar parte de la cabecera de la requisición. Segmentar el proceso por departamento es fundamental para realizar análisis comparativos. Permite ver qué departamentos tienen los ciclos más largos, las tasas de rechazo más altas o las modificaciones más frecuentes. Esta información ayuda a adaptar las mejoras del proceso a las necesidades específicas 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 la cabecera de la requisición de compra, PurchReqTable, y vincularse a la configuración de dimensiones financieras de Dynamics 365. Ejemplos Departamento de TIFinanzasOperaciones
	Estado de la requisición RequisitionStatus	El estado actual o final de la requisición de compra.
Descripción Este atributo indica el estado general de la requisición de compra en un momento determinado, como 'In Review', 'Approved', 'Rejected' o 'Closed'. A menudo es un atributo a nivel de 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 requisiciones 'Rejected' o 'Withdrawn' puede indicar problemas en la fase de solicitud inicial o un proceso de aprobación engorroso. Es un elemento clave para medir las tasas de éxito y la eficiencia del proceso. Por qué es importante Proporciona un resultado claro para cada caso y permite analizar las tasas de aprobación, rechazo y retiro, que son indicadores clave de rendimiento. Dónde obtenerlo El campo de estado suele encontrarse en la tabla de cabecera de la requisición de compra, PurchReqTable, y normalmente se denomina 'Status' o 'PurchReqStatus'. Ejemplos AprobadaEn revisiónRechazadaBorrador
	Importe total de la requisición RequisitionTotalAmount	El valor monetario total de la requisición de compra.
Descripción Este atributo registra el valor total de todas las líneas de una requisición de compra. El importe suele influir en la complejidad del Workflow de aprobación, ya que las requisiciones de mayor valor requieren más pasos de aprobación. En el análisis de procesos, este atributo es esencial para filtrar y analizar por valor. Ayuda a responder preguntas como «¿Las requisiciones de alto valor tardan más en aprobarse?» o «¿Cuál es el valor de las requisiciones que están actualmente atascadas en el proceso?». Esto aporta una perspectiva financiera al rendimiento del proceso. Por qué es importante Añade una dimensión financiera al análisis, permite priorizar los casos de alto valor y ayuda a comprender cómo influye el valor monetario en el comportamiento del proceso. Dónde obtenerlo Este valor suele encontrarse en la tabla de cabecera de la requisición de compra o calcularse como la suma de los importes de las líneas de la tabla de líneas de requisiciones de compra, PurchReqLine. Ejemplos 1500.0025000.50500.75
	Nivel de urgencia UrgencyLevel	Clasificación de la urgencia de la solicitud, como «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 influir en la ruta de aprobación o para priorizar el trabajo de las personas aprobadoras. El análisis de este atributo ayuda a determinar si el sistema de prioridades es eficaz. Por ejemplo, puede comparar los tiempos de ciclo de las solicitudes con urgencia «Alta» y «Baja». Si no existe una diferencia significativa, podría indicar que el campo de prioridad se ignora o se utiliza de forma incorrecta. Esta es una conclusión 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 incorrectos de la clasificación de urgencia. Dónde obtenerlo Podría ser 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 Workflow de aprobación.
Descripción Este atributo identifica la etapa concreta del Workflow de aprobación, como «Aprobación del gerente» o «Aprobación de Finanzas». Proporciona un nivel de detalle mayor que el nombre general de la actividad. Este atributo es esencial para el «Análisis de cuellos de botella de los pasos de aprobación». Al registrar el tiempo empleado en cada paso de aprobación, es posible identificar con precisión qué etapas provocan retrasos en el proceso general. Esto permite aplicar medidas específicas para mejorar la eficiencia del Workflow. Por qué es importante Permite analizar con detalle el Workflow 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 Workflow, como WorkflowTrackingStatusTable, que detalla cada paso del Workflow configurado. Ejemplos Aprobación del gerenteAprobación del responsable del departamentoRevisión de Finanzas
	Usuario User	El ID o nombre de la persona que realizó la actividad.
Descripción Este atributo identifica al empleado o usuario del sistema responsable de ejecutar un paso específico del proceso, como enviar una requisición o aprobar una solicitud. Puede ser un ID de usuario, el nombre completo o una dirección de correo electrónico. Analizar las actividades por usuario ayuda a identificar necesidades de capacitación, personas o equipos con un rendimiento destacado y la distribución de la carga de trabajo. También es esencial para el análisis de cumplimiento, por ejemplo, la segregación de funciones, y para comprender 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 específicos de cada usuario, aspectos clave para gestionar los recursos e identificar oportunidades de capacitación. Dónde obtenerlo Normalmente se encuentra en tablas del historial de Workflow, por ejemplo, WorkflowTrackingStatusTable, o en tablas de transacciones, como PurchReqTable, vinculadas a una tabla de usuarios, como 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 Es un atributo booleano calculado que vale «true» si la ruta de aprobación de una solicitud no incluye las actividades «Solicitud modificada» ni «Paso de aprobación rechazado». En caso contrario, vale «false». Este atributo respalda directamente el KPI «Tasa de aprobación de solicitudes en el primer intento». Simplifica el análisis de la eficiencia del proceso al proporcionar un indicador claro, a nivel de caso, del retrabajo. Una tasa baja de aprobaciones en el primer intento pone de manifiesto problemas en la calidad inicial de los datos o en la claridad de los requisitos, y señala una oportunidad de mejora del proceso. Por qué es importante Mide directamente la calidad y eficiencia del proceso al identificar los casos que requirieron retrabajo y respalda los KPI centrados en las tasas de aprobación correcta a la primera. Dónde obtenerlo Es un atributo calculado. Requiere analizar la secuencia completa de actividades de cada caso durante la transformación de datos para comprobar la ausencia de actividades de retrabajo antes de la aprobación. Ejemplos truefalse
	Grupo de personas aprobadoras ApproverGroup	Grupo de usuarios o rol responsable de un paso de aprobación.
Descripción Este atributo identifica el grupo, rol o cola asignado para gestionar una tarea de aprobación específica, por ejemplo, «Personas aprobadoras de Finanzas» o «Gerentes de TI». Analizar el rendimiento del proceso por grupo de personas aprobadoras es fundamental para comprender la distribución de la carga de trabajo e identificar qué grupos podrían tener recursos insuficientes o necesitar formación adicional. También respalda directamente el Dashboard «Análisis de cuellos de botella de los pasos de aprobación», ya que permite segmentar el rendimiento por los equipos responsables de las aprobaciones. Por qué es importante Ayuda a identificar diferencias de rendimiento entre los equipos de aprobación y pone de relieve posibles limitaciones de recursos o necesidades de formación en grupos concretos. Dónde obtenerlo Esta información forma parte del historial del Workflow, 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	El código de moneda del importe de la requisición.
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, especialmente en organizaciones multinacionales que trabajan con varias monedas. El uso del 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 Proporciona el contexto necesario para los atributos financieros y garantiza la interpretación y agregación precisas de los valores monetarios en entornos multidivisa. Dónde obtenerlo Este campo suele encontrarse en la tabla de encabezados de solicitudes 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 Es un atributo numérico calculado que cuenta las apariciones de la actividad «Solicitud modificada» en cada caso de solicitud de compra. Este atributo es esencial para el Dashboard «Frecuencia de modificaciones de solicitudes» y el KPI «Proporción de modificaciones de solicitudes». Cuantifica el retrabajo por caso y facilita identificar qué solicitudes, departamentos o usuarios están asociados con altos niveles de cambios e ineficiencia. Esto ayuda a orientar las iniciativas para mejorar la calidad de las solicitudes iniciales. Por qué es importante Cuantifica el retrabajo dentro de un caso y facilita medir y analizar 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» de 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 identificador único de la orden de compra generada a partir de una solicitud de compra aprobada. Actúa como vínculo entre el proceso de solicitud y el proceso de compras posterior. Registrar este número es esencial para analizar el «Tiempo de conversión de solicitud a OC». Confirma que la solicitud ha avanzado correctamente a la siguiente etapa del ciclo Purchase-to-Pay y permite realizar un análisis integral que abarque tanto las solicitudes como las órdenes de compra. Por qué es importante Conecta la solicitud con la orden de compra posterior, permite analizar la conversión de solicitud a OC y vincula distintas etapas del proceso P2P. Dónde obtenerlo Esta información suele encontrarse en la tabla de líneas de solicitudes de compra, PurchReqLine, después de crear una OC, con un vínculo a PurchTable. Ejemplos PO-000987PO-000988PO-000989
	Ruta del Workflow 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 determinada, como «Aprobación del gerente -> Aprobación del responsable del departamento -> Aprobación de Finanzas». Resume eficazmente la variante del proceso correspondiente al subproceso de aprobación. Es fundamental para el Dashboard «Monitor de desviaciones de Cumplimiento». Al comparar la ruta real del Workflow con una ruta estándar o esperada predefinida, resulta sencillo señalar los flujos de proceso no conformes o inusuales que podrían representar incumplimientos de políticas o riesgos operativos. Por qué es importante Simplifica el análisis de Cumplimiento al proporcionar una representación textual clara de la variante del proceso, lo que facilita detectar desviaciones respecto de los procedimientos estándar. Dónde obtenerlo No es un campo estándar. Debe derivarse 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

Purchase to Pay - Requisition: actividades

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

7 Recomendado 5 Opcional

	Actividad	Descripción
	Orden de compra creada	Una línea de requisición de compra aprobada se convierte en una línea de orden de compra, lo que indica la transferencia al equipo de compras. Se captura vinculando la línea de requisición con una línea de orden de compra.
Por qué es importante Este es un hito fundamental que conecta la requisición con el proceso de compras posterior. Es esencial para medir el KPI 'Requisition to PO Conversion Time'. Dónde obtenerlo Se infiere al encontrar un registro en la tabla 'PurchLine' que haga referencia al ID de una 'PurchReqLine' asociada al caso de la requisición. Recopilar Una PurchReqLine con PurchLine mediante el campo de referencia de vinculación, por ejemplo, PurchReqLineRefId. Tipo de evento inferred
	Paso de aprobación aprobado	La persona aprobadora completa la tarea asignada y aprueba la requisición para su etapa del proceso. Esto mueve la requisición al paso siguiente 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 eficientes del Workflow. 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'. Recopilar Identifique eventos 'WorkItemCompleted' con el resultado 'Approve' en los registros del historial de Workflow. Tipo de evento explicit
	Requisición aprobada	La requisición ha superado correctamente todos los pasos de aprobación requeridos en el Workflow. Esta actividad se captura cuando la instancia de Workflow finaliza con un estado de aprobación final.
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 final del KPI 'Requisition Approval Cycle Time'. Dónde obtenerlo Se captura explícitamente desde 'WorkflowTrackingStatusTable' cuando finaliza el Workflow. Esto también actualiza el campo 'Status' de 'PurchReqTable' a 'Approved'. Recopilar Filtre los eventos de 'Completion' del Workflow con estado 'Approved' o haga un seguimiento del cambio de estado en PurchReqTable. Tipo de evento explicit
	Requisición cerrada	La requisición de compra completa se considera finalizada, lo que significa que todas sus líneas se han procesado en ó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 requisición. Es el punto final para medir la duración total del proceso de principio a fin. Dónde obtenerlo Este estado normalmente se calcula o se infiere. Se produce cuando todos los registros 'PurchReqLine' asociados alcanzan un estado terminal, por ejemplo, 'Closed' o 'Cancelled'. Recopilar Derive este evento comprobando si todos los registros secundarios PurchReqLine de un PurchReqTable tienen un estado final. Tipo de evento calculated
	Requisición creada	Este evento marca la creación inicial del registro de la requisición de compra en estado de borrador. Se captura identificando la marca de tiempo de creación de la cabecera de la requisición.
Por qué es importante Como inicio del proceso, esta actividad es esencial para medir la duración total del ciclo de vida de las requisiciones y analizar el volumen diario de requisiciones procesadas. Dónde obtenerlo Esta actividad se infiere a partir del campo 'createdDateTime' de 'PurchReqTable' para cada nuevo Purchase Requisition ID. Recopilar Utilice la marca de tiempo de creación del registro en PurchReqTable. Tipo de evento inferred
	Requisición enviada para aprobación	El usuario envía la requisición completada, lo que inicia el Workflow formal de aprobación. El motor de Workflow del sistema registra explícitamente esta acción.
Por qué es importante Esta actividad es un hito fundamental que inicia el ciclo de aprobación. Constituye el punto de partida para medir el 'Requisition Approval Cycle Time' y la 'First-Pass Approval Rate'. Dónde obtenerlo Se captura desde 'WorkflowTrackingStatusTable' o desde una tabla similar del historial de Workflow, donde se registra un evento de 'Submission' asociado a la requisición. Recopilar Filtre los registros del historial de Workflow por el tipo de evento 'Submission' o 'Start' asociado a la requisición. Tipo de evento explicit
	Requisición rechazada	La requisición ha sido rechazada durante el Workflow de aprobación y no seguirá procesándose. Esto representa un estado terminal de fallo para la requisición.
Por qué es importante Este evento final es fundamental para analizar las tasas generales de rechazo y comprender el impacto financiero u operativo de las solicitudes fallidas. Dónde obtenerlo Se captura explícitamente desde 'WorkflowTrackingStatusTable' al finalizar el Workflow con estado 'Rejected', lo que actualiza el campo de estado de 'PurchReqTable'. Recopilar Filtre los eventos de 'Completion' del Workflow con estado 'Rejected' o haga un seguimiento del cambio de estado en PurchReqTable. Tipo de evento explicit
	Línea de requisición cerrada	Una línea individual de la requisición de compra se considera completamente procesada. Esto suele ocurrir después de que la línea se haya convertido por completo en una orden de compra.
Por qué es importante Proporciona información detallada sobre el cumplimiento de las requisiciones y ayuda a identificar si se convierten parcial o totalmente en órdenes de compra. Dónde obtenerlo Se infiere a partir del campo de estado de la tabla individual 'PurchReqLine'. Un estado que indique que la línea se ha pedido o recibido señalaría el cierre. Recopilar Supervise el campo de estado de la tabla PurchReqLine para detectar un valor terminal como 'Invoiced' o 'Closed'. Tipo de evento inferred
	Paso de aprobación iniciado	Se asigna una tarea de aprobación individual a un usuario o grupo como parte del Workflow. Esto representa el inicio del tiempo de espera o procesamiento de una persona aprobadora específica.
Por qué es importante Esta actividad es fundamental para el 'Approval Step Bottleneck Analysis', ya que permite medir los tiempos de espera en etapas de aprobación específicas. Dónde obtenerlo Se captura desde 'WorkflowTrackingStatusTable' cuando se crea y asigna un nuevo elemento de trabajo para la instancia de Workflow de la requisición. Recopilar Identifique eventos 'WorkItemCreated' o similares en los registros del historial de Workflow de la requisición específica. Tipo de evento explicit
	Paso de aprobación rechazado	La persona aprobadora rechaza la tarea asignada y normalmente devuelve la requisición a quien la originó para que la corrija. El motor de Workflow registra explícitamente esta acción.
Por qué es importante Esta actividad es fundamental para calcular la 'Requisition Rejection Rate' e identificar en qué etapas se producen más rechazos, lo que permite localizar áreas 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'. Recopilar Identifique eventos 'WorkItemCompleted' con el resultado 'Reject' en los registros del historial de Workflow. Tipo de evento explicit
	Requisición modificada	Este evento ocurre cuando un usuario recupera una requisición enviada desde el Workflow para realizar cambios. Normalmente se captura identificando una acción de recuperación seguida de un nuevo envío posterior.
Por qué es importante El seguimiento de las modificaciones es clave para identificar retrabajos, solicitudes iniciales poco claras e ineficiencias del proceso. También respalda directamente el Dashboard 'Requisition Amendment Frequency'. Dónde obtenerlo Puede inferirse del historial de Workflow ('WorkflowTrackingStatusTable') al detectar una acción 'Recall' o 'RequestChange'. También puede inferirse a partir de cambios en el campo 'modifiedDateTime' de 'PurchReqTable' después del envío. Recopilar Detecte eventos de recuperación del Workflow o cambios de versión del registro entre eventos de envío. Tipo de evento inferred
	Requisición retirada	La persona creadora o un usuario autorizado cancela la requisición después de que se haya enviado. Esta acción termina el Workflow y la solicitud.
Por qué es importante El seguimiento de los retiros ayuda a identificar problemas de planificación de la demanda o procesos excesivamente complejos. Esto respalda el Dashboard 'Requisition Withdrawal Insights'. Dónde obtenerlo Se infiere a partir de un cambio de estado de 'PurchReqTable' a 'Cancelled' o de un evento 'Cancel' en 'WorkflowTrackingStatusTable'. Recopilar Detecte el cambio de estado a 'Cancelled' en PurchReqTable o un evento de cancelación del Workflow. 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 gestión de datos: Inicie sesión en Microsoft Dynamics 365 y vaya al menú Workspaces. Seleccione Data management para abrir el centro principal de las operaciones de importación y exportación de datos.
Cree un proyecto de exportación nuevo: En el espacio de trabajo de gestión de datos, haga clic en el mosaico Export. Proporcione un Nombre del Group único, una Descripción descriptiva y establezca Project category en Project. Esto organiza las tareas de extracción de datos.
Añada entidades de datos: Añada al proyecto las entidades de datos estándar necesarias. Haga clic en Add entity y busque cada una de las siguientes entidades para añadirlas 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 añadida, 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 de datos: Seleccione una entidad y haga clic en el botón 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 añadir un filtro de fecha en el campo Created date and time de la entidad Purchase requisition headers para limitar el volumen de datos. Se recomienda comenzar con un periodo de 3 a 6 meses.
Ejecute el trabajo de exportación: Cuando haya configurado 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 supervisar el progreso en la sección Job history.
Descargue el paquete de datos: Cuando el trabajo de exportación finalice correctamente, vaya a los detalles de Job history y haga clic en Download package. Se descargará un archivo ZIP que contiene los archivos de datos independientes de cada entidad.
Transforme los datos sin procesar en un Registro de eventos: Los archivos exportados representan tablas sin procesar del sistema, no un Registro de eventos final. Debe utilizar una herramienta externa, como Python, Power Query o una plataforma ETL, para combinar y reorganizar los datos. Esto incluye:
- Combinar los archivos de cabecera y de líneas.
- Combinar los datos del flujo de trabajo con las solicitudes mediante CorrelationId y el RecId de la cabecera de la solicitud de compra.
- Convertir los cambios de estado y los eventos del flujo de trabajo de las tablas de flujo de trabajo en filas de actividad independientes (Requisition Submitted, Approval Step Approved, etc.).
- Crear una fila nueva para 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. Establezca un valor estático para SourceSystemId, por ejemplo, 'D365_F&O', y utilice la hora de ejecución del script para LastDataIngestionTimestamp.
Finalice 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 necesaria del Registro de eventos, incluidas 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 similar.
Entidades de datos clave:
- Purchase requisition headers: Proporciona el identificador principal del caso, la marca de tiempo de creación y el estado general.
- Purchase requisition lines: Contiene los detalles de 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 Workflow, como el envío, la aprobación, el rechazo y la recuperación.
- Workflow work items: Detalla las tareas específicas asignadas a los usuarios durante el proceso de aprobación.
- Purchase order lines V2: Se utiliza para encontrar la marca de tiempo de creación de la orden de compra vinculada a una línea de solicitud.
Filtrado por intervalo de fechas: Es fundamental aplicar un filtro de intervalo de fechas al campo Created date and time de la entidad Purchase requisition headers. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses a fin de equilibrar el volumen de datos y la información obtenida.
Filtrado por código de empresa: Aplique siempre un filtro para Legal entity con el fin de evitar extraer datos de empresas no previstas o de prueba. Esto reduce considerablemente el tamaño de los datos y mejora el rendimiento del trabajo.
Transformación de datos: Este método requiere un procesamiento posterior considerable fuera de Dynamics 365 para transformar las exportaciones sin procesar de las entidades en un Registro de eventos estructurado. Prepárese para utilizar una herramienta de scripting o ETL.

a 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 de Azure Active Directory: Vaya al portal de Azure y registre una aplicación nueva. Esta aplicación se utilizará para autenticarse con la API de Dynamics 365. Anote el ID de aplicación (cliente) y el ID de directorio (inquilino).
Genere un secreto de cliente: En la aplicación recién registrada en Azure, cree un secreto de cliente nuevo en «Certificates & secrets». Copie el valor del secreto y guárdelo de forma segura, ya que no volverá a estar visible.
Conceda permisos de API: En la sección «API permissions» de la aplicación, añada un permiso para «Dynamics ERP». Seleccione «Delegated permissions» y conceda Financials.ReadWrite.All o una alternativa de solo lectura más restrictiva. Conceda el consentimiento del administrador para los permisos.
Instale las bibliotecas de Python: Asegúrese de tener Python instalado. Después, instale las bibliotecas necesarias mediante 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 situadas al principio del script: la URL de Dynamics 365, el ID del inquilino, el ID de cliente, el secreto de cliente, el intervalo de fechas deseado y el ID de la empresa.
Comprenda las entidades OData: El script consulta tres entidades de datos principales: PurchaseRequisitionHeaders para los detalles principales de la solicitud, PurchaseRequisitionLines para los detalles de las líneas, incluida la conversión en órdenes de compra, y WorkflowTrackingStatusTable para todos los eventos relacionados con el Workflow, como envíos y aprobaciones.
Ejecute el script: Ejecute el script 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. Reestructura los datos recorriendo los registros y creando una fila independiente para cada una de las 12 actividades de negocio, asignando los campos de origen a las columnas estándar del Registro de eventos, como PurchaseRequisitionId, ActivityName y EventTime.
Combine y estandarice los eventos: Todos los eventos generados se recopilan en una única lista y después se convierten en un DataFrame de pandas. El script añade 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. Este archivo está preparado para cargarse directamente en una herramienta de Process Mining. Compruebe que el archivo utilice codificación UTF-8.

Configuración

Requisitos previos: Acceso a una suscripción de Azure para registrar una aplicación. Necesitará un ID de aplicación (cliente), un secreto de cliente y un ID de inquilino de Azure Active Directory. El usuario que ejecute el script debe disponer de credenciales que permitan acceder a los endpoints de la API OData de Dynamics 365 Finance and Operations.
Configuración del endpoint de la API: El script requiere la URL base de su entorno de Dynamics 365, normalmente con el formato https://[your-environment-name].operations.dynamics.com.
Intervalo de fechas: Establezca las variables START_DATE y END_DATE del script para definir el periodo de extracción. Para el análisis inicial, se recomienda un periodo de 3 a 6 meses a fin de equilibrar el volumen de datos y la información obtenida.
Filtro por empresa: El script está configurado para filtrar una entidad legal específica mediante la variable COMPANY_ID. 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 obtiene únicamente las columnas necesarias para el Registro de eventos mediante $select en las consultas OData, lo que mejora el rendimiento. También gestiona la paginación para trabajar con grandes conjuntos de datos sin sobrecargar la API. Para cargas históricas muy grandes, considere ejecutar el script por lotes con intervalos de fechas más cortos.

a 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 el usuario tiene autorización para acceder a las entidades de datos, el historial del Workflow, los datos de requisiciones y los datos relacionados de órdenes de compra necesarios.
En Power BI Desktop, seleccione Obtener datos, elija el conector de Microsoft Dynamics 365 Finance e introduzca la URL de la instancia de Dynamics 365 Finance. Autentíquese 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 cabecera y líneas de requisición de compra, las entidades de historial o seguimiento del Workflow, las entidades de usuarios y organización, y las entidades de órdenes de compra necesarias para su implementación. Los nombres de las entidades y los campos disponibles varían según el entorno. Utilice 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 según la entidad jurídica o empresa, el tipo de documento y el periodo de extracción necesarios. Utilice parámetros para [Start date] y [End date], y conserve los registros cuya marca de tiempo del evento se encuentre dentro del periodo seleccionado. Incluya los registros creados antes de la fecha de inicio cuando tengan eventos de Workflow o de cierre dentro del periodo, para que el historial de los casos permanezca completo.
Estandarice los identificadores y las marcas de tiempo. Convierta a texto el identificador de la requisición de compra, convierta todas las marcas de tiempo de eventos a una zona horaria UTC o empresarial coherente y conserve la precisión de la marca de tiempo de origen. Asegúrese de que el identificador de la cabecera de requisición esté disponible en cada fila de evento. Cuando los registros del Workflow solo contengan un identificador de correlación del Workflow, únalos a la cabecera de requisición mediante la relación documentada configurada en su entorno.
Cree una consulta de eventos para cada actividad necesaria. Las consultas de eventos 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 inferir ninguna actividad a partir de cambios de estado u orden de los eventos.
Para Requisition Amended, aplique la lógica documentada de recuperación y reenvío del historial de su Workflow. Una acción de recuperación seguida de un envío posterior debe generar un evento de modificación en la marca de tiempo de la recuperación o en la marca de tiempo de modificación expuesta por la entidad de origen. No cree una fila de modificación únicamente a partir de un cambio en 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 orden de compra mediante la relación de origen documentada. Si el registro de eventos utiliza PurchaseRequisitionId como identificador de caso, agregue o conserve los eventos a nivel de línea como filas independientes con el mismo identificador de caso. Conserve los identificadores de línea en columnas adicionales cuando estén disponibles, 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. Asigne null a los valores no disponibles en lugar de inventarlos y utilice un valor de origen coherente, como Dynamics 365 Finance, para SourceSystemId.
Añada todas las consultas de actividades mediante UNION ALL, elimine las filas sin identificador de caso o marca de tiempo del evento y ordene por PurchaseRequisitionId y EventTime. Conserve los eventos duplicados cuando representen tareas de Workflow independientes o líneas de requisición independientes. Elimine duplicados únicamente cuando los registros de origen sean claramente extracciones duplicadas.
Valide el registro de eventos resultante mediante las comprobaciones descritas a continuación. Confirme que cada actividad obligatoria esté representada por filas explícitas, que las marcas de tiempo se encuentren dentro del periodo seleccionado y que las uniones no multipliquen los eventos de forma inesperada.
Cargue o exporte la tabla final en CSV u otro formato de registro de eventos compatible con ProcessMind. Asigne PurchaseRequisitionId como identificador de caso, ActivityName como actividad y EventTime como marca de tiempo del evento. Mantenga SourceSystemId y LastDataIngestionTimestamp como Atributos de evento y conserve todos los Atributos recomendados cuando 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. Los nombres y campos de las entidades deben confirmarse en los metadatos de Navigator para la implementación específica.
Entidades obligatorias: Seleccione las entidades de cabecera y líneas de requisición de compra, las entidades de seguimiento o historial del Workflow, las entidades de cabecera y líneas de órdenes de compra y las entidades de usuarios u organización necesarias para el enriquecimiento. Utilice marcadores de posición como [Your entity name] hasta confirmar las entidades exactas.
Intervalo de fechas: Comience con entre tres y seis meses de datos. Incluya las cabeceras históricas de requisiciones correspondientes a casos que tengan eventos de Workflow, órdenes de compra, cierre de líneas o cierre de requisición durante el periodo seleccionado.
Filtros de empresa y documento: Filtre por [Your company or legal entity filter] y [Your document type filter] cuando corresponda. Confirme si el identificador de requisición es único globalmente o solo dentro de una empresa.
Alcance del Workflow: Incluya las acciones de envío, recuperación, reenvío, asignación de tareas, aprobación, rechazo, retirada, finalización y cancelación. Configure las correspondencias entre acciones y estados del Workflow a partir de los valores utilizados en el entorno.
Semántica de eventos: Cada actividad debe emitirse como una fila de evento explícita. ProcessMind no infiere 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 se almacenan 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 extracciones periódicas, utilice una marca de agua basada en la mayor marca de tiempo de modificación o de evento de origen, con una ventana de solapamiento para capturar registros de Workflow que lleguen tarde. Concilie el solapamiento antes de cargar el registro de eventos final.
Rendimiento: Filtre las entidades de origen antes de realizar las uniones, seleccione únicamente las columnas necesarias, evite cargar registros históricos de Workflow innecesarios y utilice el plegado de consultas cuando sea compatible. Extraiga por separado las cabeceras, las líneas, los eventos de Workflow y las relaciones de órdenes de compra antes de combinarlos.
Autorizaciones y requisitos previos: La cuenta necesita acceso de lectura a las entidades de datos de Dynamics 365 Finance seleccionadas y a los datos del Workflow. Confirme que las funciones pertinentes de compras y Workflow estén habilitadas y que Power BI Desktop, el conector, la configuración de la puerta de enlace cuando corresponda y las políticas de seguridad de la organización permitan la extracción.
Moneda e importes: Confirme la moneda representada por RequisitionTotalAmount. Si las requisiciones pueden contener varias monedas, incluya la moneda de origen como Atributo adicional y no convierta los importes de forma silenciosa.
Gestión de valores nulos: Los Atributos recomendados pueden ser null cuando el origen no almacena un valor, cuando el valor está restringido por la seguridad o cuando no se puede resolver la relación. Los valores obligatorios de caso, actividad y marca de tiempo del evento deben validarse antes de la exportación.

a 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;

¿Listo para comenzar?

Con esta plantilla tiene todo lo necesario para comenzar a optimizar su proceso Purchase to Pay - Requisition. Empiece hoy mismo a descubrir información valiosa.

Volver a la guía de mejora Descargar Template

Optimice Purchase to Pay - Requisition para obtener aprobaciones más rápidas

Elimine los retrasos y consiga tiempos de ciclo un 30 % más rápidos en Dynamics 365.

Inicie su prueba gratuita

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

Su Template de datos de Purchase to Pay - Requisition

Su Template de datos de Purchase to Pay - Requisition

Purchase to Pay - Requisition: Atributos

Purchase to Pay - Requisition: actividades

Guías de extracción

Exportación mediante el marco de gestión de datos de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Extracción mediante el conector nativo de Microsoft Power BI

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Optimice Purchase to Pay - Requisition para obtener aprobaciones más rápidas

Su Template de datos de Purchase to Pay - Requisition

Su Template de datos de Purchase to Pay - Requisition

Purchase to Pay - Requisition: Atributos

Purchase to Pay - Requisition: actividades

Guías de extracción

Exportación mediante el marco de gestión de datos de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Extracción mediante el conector nativo de Microsoft Power BI

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Optimice Purchase to Pay - Requisition para obtener aprobaciones más rápidas

Valoramos su privacidad