> Mejora continua de procesos > Proceso de pedido a cobro: gestión de órdenes de venta > Microsoft Dynamics 365 > Template de datos

Su Template de datos para el proceso de pedido a cobro: procesamiento de pedidos de venta

Microsoft Dynamics 365

← Volver a la guía de mejora

Atributos del proceso de pedido a cobro: procesamiento de pedidos de venta(20) Actividades del proceso de pedido a cobro: procesamiento de pedidos de venta(13) Guías de extracción(2)

Su Template de datos para el proceso de pedido a cobro: procesamiento de pedidos de venta

Este Template ofrece una descripción estructurada de los datos esenciales para analizar el proceso de pedido a cobro y el procesamiento de pedidos de venta en Microsoft Dynamics 365. Detalla los atributos importantes que debe recopilar y las actividades clave que debe registrar en el Registro de eventos. También encontrará instrucciones prácticas para extraer estos datos de su sistema de forma eficaz.

Atributos recomendados para un análisis completo
Actividades clave del proceso que debe registrar
Instrucciones específicas para extraer datos de Microsoft Dynamics 365

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

Descargar Template

Atributos del proceso de pedido a cobro: procesamiento de pedidos de venta

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar en detalle el proceso de pedido a cobro y el procesamiento de pedidos de venta en Microsoft Dynamics 365.

5 Obligatorio 5 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento de negocio o la tarea concreta que tuvo lugar en un momento determinado del proceso del pedido de venta.
Descripción Este atributo representa un paso o evento concreto del ciclo de vida del pedido de venta, como 'Pedido de venta creado', 'Productos enviados' o 'Pago recibido'. La secuencia de estas actividades para un pedido de venta determinado forma el flujo del proceso. Analizar la secuencia, la frecuencia y las transiciones entre actividades es fundamental en Process Mining. Permite visualizar el mapa del proceso, identificar las variantes habituales y poco frecuentes, detectar cuellos de botella y señalar áreas de retrabajo o incumplimiento. Este atributo es esencial para comprender lo que ocurre realmente en el proceso. Por qué es importante Define los pasos del proceso y permite construir y visualizar su flujo, que es el objetivo principal de Process Mining. Dónde obtenerlo Este atributo se obtiene conceptualmente al asignar un nombre de actividad estandarizado a eventos específicos del sistema o a cambios de estado en tablas como 'SalesTable' y en tablas relacionadas con la logística o las finanzas. Ejemplos Pedido de venta creadoProductos enviadosFactura creadaPago recibido
	Hora de inicio EventTime	Fecha y hora exactas en que tuvo lugar una actividad o un evento concreto.
Descripción La hora del evento, o marca de tiempo, registra el momento exacto en que tuvo lugar una actividad. Cada actividad del registro de eventos tiene una marca de tiempo asociada, que crea un registro cronológico del proceso para cada caso. Este atributo es fundamental para todos los análisis temporales de Process Mining. Se utiliza para calcular los tiempos de ciclo entre actividades, medir la duración total de un caso, analizar los tiempos de espera e identificar cuellos de botella que retrasan el proceso. También permite supervisar el rendimiento a lo largo del tiempo, por ejemplo, hacer un seguimiento del rendimiento por día, semana o mes. Por qué es importante Esta marca de tiempo es esencial para calcular todas las métricas de duración, como los tiempos de ciclo, y para ordenar cronológicamente los eventos e identificar cuellos de botella. Dónde obtenerlo Se obtiene de varios campos de fecha y hora asociados a transacciones concretas, como 'SalesTable.CreatedDateTime' para la creación de pedidos o las fechas de contabilización de los diarios de pago. Ejemplos 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Pedido de venta SalesOrderNumber	Identificador único de cada pedido de venta, que sirve como identificador principal del caso en el proceso.
Descripción El número del pedido de venta es un código alfanumérico único que se asigna a cada pedido de cliente en Microsoft Dynamics 365. Funciona como ID del caso principal y vincula todas las actividades y los eventos relacionados, desde la creación hasta el cierre. En Process Mining, este atributo es esencial para reconstruir el recorrido completo de cada pedido de venta. Permite a los analistas seguir la secuencia completa de actividades, medir la duración de cada caso y analizar las variaciones de cada pedido, lo que constituye la base de todo el análisis del proceso. Por qué es importante Este identificador es fundamental para relacionar todos los eventos vinculados y analizar cada pedido de venta de principio a fin. Dónde obtenerlo Se encuentra en la tabla 'SalesTable', en el campo 'SalesId'. Ejemplos SO-00102345SO-00102346SO-00102347
	Sistema de origen SourceSystem	Identifica el sistema de información del que proceden los datos.
Descripción Este atributo especifica la aplicación de origen en la que se registraron los datos de los eventos. En este contexto, suele ser «Microsoft Dynamics 365». Aunque en un análisis de un solo sistema pueda parecer redundante, resulta fundamental al combinar datos de varios sistemas, como un CRM independiente o un sistema de gestión de almacenes. Permite rastrear el origen de los datos y facilita la resolución de problemas de extracción al identificar de dónde proceden los registros. Por qué es importante Aporta contexto esencial sobre el origen de los datos, especialmente al integrar datos de varios sistemas, y permite rastrear claramente su procedencia. Dónde obtenerlo Es un valor estático que suele añadirse durante la transformación de datos para indicar el origen del conjunto de datos. Ejemplos Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
	Última actualización de datos LastDataUpdate	Marca de tiempo que indica cuándo se actualizaron o extrajeron los datos por última vez del sistema de origen.
Descripción Este atributo registra la fecha y hora de la extracción más reciente de datos de Microsoft Dynamics 365. Permite saber si los datos analizados están actualizados. Para analizar cualquier proceso, es fundamental conocer la antigüedad de los datos y tomar decisiones fundamentadas. Esta marca de tiempo indica cuándo se actualizaron los datos por última vez, lo que permite confiar en ellos y basar las conclusiones en información actual. Por qué es importante Permite saber si los datos están actualizados, algo fundamental para que el análisis de Process Mining sea pertinente y preciso. Dónde obtenerlo Se genera al extraer los datos y se añade a cada registro durante su ingesta. Ejemplos 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Canal de ventas SalesChannel	El canal por el que se recibió el pedido de venta, como la web, la venta directa o un socio.
Descripción El canal de ventas indica el origen del pedido del cliente. Puede ser un sitio de comercio electrónico, un equipo de ventas directas, una tienda minorista, un centro de llamadas o una red de socios. En Dynamics 365, esta dimensión suele configurarse según las necesidades de la empresa. Analizar el proceso por canal de ventas ayuda a detectar diferencias de rendimiento entre canales. Por ejemplo, los pedidos web podrían procesarse más rápido y de forma más automática que los recibidos por teléfono. Esta información permite optimizar cada canal y asignar los recursos correspondientes, además de crear Dashboards como «Valor del pedido de venta por segmento». Por qué es importante Permite comparar el rendimiento de los distintos canales de venta y detectar ineficiencias o buenas prácticas según la forma en que se inician los pedidos. Dónde obtenerlo Esta información suele almacenarse en la cabecera del pedido de venta. Consulte la documentación de Microsoft Dynamics 365 para identificar el campo específico. Ejemplos WebVenta directaSocioVenta minorista
	Fecha de entrega confirmada ConfirmedDeliveryDate	La fecha de entrega que la empresa confirmó y acordó con el cliente.
Descripción La fecha de entrega confirmada es la fecha en que la empresa vendedora se compromete a entregar los productos al cliente. Se establece después de realizar comprobaciones internas, como verificar la disponibilidad del inventario y los calendarios de producción. Este atributo es esencial para calcular el KPI «Tasa de cumplimiento de la fecha de entrega» desde la perspectiva del compromiso operativo. Ofrece una referencia interna más realista que la fecha solicitada inicialmente por el cliente. Analizar las desviaciones respecto a esta fecha ayuda a detectar fallos internos en la logística y la gestión de pedidos. Por qué es importante Representa el compromiso de la empresa con el cliente y constituye una referencia interna clave para medir la fiabilidad de la gestión de pedidos y el rendimiento operativo. Dónde obtenerlo Se encuentra en los datos de las líneas del pedido de venta, a menudo en la tabla «SalesLine», en un campo como «ConfirmedDlv». Ejemplos 2023-05-122023-06-012023-05-28
	Fecha de entrega solicitada RequestedDeliveryDate	La fecha de entrega que solicitó el cliente para el pedido.
Descripción Este atributo almacena la fecha en que el cliente solicitó inicialmente recibir sus productos. Se registra al crear el pedido y sirve como referencia para medir el rendimiento de las entregas desde la perspectiva del cliente. Esta fecha es un dato clave para el Dashboard «Cumplimiento de la fecha de entrega». Comparar «RequestedDeliveryDate» con «ConfirmedDeliveryDate» y con la fecha real de «Goods Delivered» permite evaluar hasta qué punto la organización cumple las expectativas del cliente. Las diferencias importantes pueden indicar problemas de planificación, inventario o logística. Por qué es importante Representa la expectativa de entrega del cliente y sirve como referencia clave para medir su satisfacción y el rendimiento de las entregas a tiempo. Dónde obtenerlo Se encuentra en la tabla «SalesTable», normalmente en un campo llamado «DeliveryDate» o una variante similar. Ejemplos 2023-05-102023-06-012023-05-25
	Nombre del cliente CustomerName	El nombre del cliente que realizó el pedido de venta.
Descripción Este atributo contiene el nombre legal del cliente asociado al pedido de venta. Se obtiene al vincular el número de cuenta del cliente en el pedido con los datos maestros de clientes. Analizar el proceso por cliente es fundamental para comprender sus comportamientos y niveles de servicio. Ayuda a identificar qué clientes sufren más demoras, cuáles tienen más retrabajo o cuáles siguen rutas de proceso no estándar. Esta información es esencial para mejorar la satisfacción del cliente y gestionar eficazmente las cuentas clave. Por qué es importante Permite analizar el proceso desde la perspectiva del cliente e identificar patrones, demoras o problemas específicos que afectan directamente a su satisfacción. Dónde obtenerlo Se consulta en «CustTable» mediante el campo «CustAccount» de «SalesTable». Ejemplos Contoso LtdAdatum CorporationFabrikam Inc.
	Valor del pedido OrderValue	El valor monetario total del pedido de venta.
Descripción Este atributo representa el importe financiero total del pedido de venta, incluidos todos los artículos, impuestos y cargos. Es una métrica financiera clave asociada a cada caso. El valor del pedido es fundamental para analizar el proceso según su valor económico. Permite segmentar el proceso y comprobar si los pedidos de mayor valor reciben un tratamiento distinto o sufren más demoras que los de menor valor. Así, puede priorizar las mejoras en los casos de mayor impacto financiero y crear Dashboards como «Valor del pedido de venta por segmento». Por qué es importante Permite segmentar el proceso por valor económico, priorizar las mejoras en los pedidos de mayor valor y comprender el impacto de las desviaciones del proceso en los costes. Dónde obtenerlo Se encuentra en los datos de cabecera del pedido de venta. Consulte la documentación de Microsoft Dynamics 365 para identificar la tabla y el campo específicos; a menudo se calcula a partir de los importes de las líneas del pedido. Ejemplos 5250.7512300.00899.50
	Entrega a tiempo OnTimeDelivery	Indicador booleano que señala si los productos se entregaron en la fecha de entrega confirmada o antes.
Descripción Este atributo calculado compara la marca de tiempo de la actividad «Goods Delivered» con «ConfirmedDeliveryDate» para cada pedido de venta. Se establece en «true» si la entrega se realizó a tiempo o antes, y en «false» si se realizó tarde. Este indicador sirve de base para calcular el KPI «Tasa de cumplimiento de la fecha de entrega». Facilita el análisis al permitir filtrar y agrupar fácilmente los pedidos entregados a tiempo y los atrasados. Así, es más sencillo detectar los factores relacionados con las entregas tardías, como determinados productos, clientes, regiones o métodos de envío. Por qué es importante Mide directamente el rendimiento de la gestión de pedidos frente al compromiso de entrega, algo esencial para supervisar la satisfacción del cliente y la fiabilidad de la cadena de suministro. Dónde obtenerlo Se calcula comparando «EventTime» de la actividad «Goods Delivered» con el atributo «ConfirmedDeliveryDate». Fórmula: («Goods Delivered» Timestamp <= ConfirmedDeliveryDate). Ejemplos truefalse
	Es retrabajo IsRework	Indicador booleano que señala si un pedido de venta ha requerido retrabajo, por ejemplo, si se ha repetido una actividad.
Descripción Este atributo calculado identifica los casos que se han desviado de una ruta ideal y directa del proceso. El retrabajo se detecta al identificar secuencias de actividades que indican que se repitió un paso, como cuando se cancela la confirmación de un pedido y luego se vuelve a confirmar, o cuando se recoge un producto y después se devuelve al inventario. Marcar los casos con retrabajo es esencial para calcular el KPI «Tasa de retrabajo de pedidos de venta». Permite aislar e investigar rápidamente los flujos de proceso ineficientes y comprender las causas del retrabajo, que pueden ser errores de entrada de datos, problemas de crédito o dificultades con el inventario. Reducir el retrabajo es uno de los principales objetivos de muchos proyectos de mejora de procesos. Por qué es importante Ayuda a cuantificar las ineficiencias del proceso al marcar los casos que requirieron repetir pasos, lo que permite analizar cómo reducir el desperdicio y las demoras. Dónde obtenerlo La herramienta de Process Mining lo calcula analizando la secuencia de actividades de cada caso. Por ejemplo, si detecta un patrón como (A -> B -> C -> B), marca el caso como retrabajo. Ejemplos truefalse
	Estado del pedido de venta SalesOrderStatus	El estado actual del pedido de venta en el momento de extraer los datos.
Descripción Este atributo refleja el estado general del pedido de venta, por ejemplo, «Pedido abierto», «Facturado», «Cancelado» o «Entregado». Es un estado resumido que se mantiene en la cabecera del pedido. El registro de actividades ofrece una vista dinámica del proceso, mientras que el estado final resulta útil para filtrar y segmentar los datos. Permite aislar fácilmente todos los pedidos abiertos para consultar la carga de trabajo actual o separar los pedidos completados correctamente de los cancelados y analizar los motivos de cancelación. Por qué es importante Ofrece una instantánea del estado del pedido y permite filtrar el análisis por pedidos abiertos, cerrados o cancelados. Esto resulta útil para gestionar la carga de trabajo y analizar los resultados. Dónde obtenerlo Se encuentra en la tabla «SalesTable», en el campo «SalesStatus». Ejemplos Pendiente de entregaEntregadoFacturadoCancelado
	Fecha de vencimiento del pago PaymentDueDate	La fecha límite en que el cliente debe pagar la factura.
Descripción La fecha de vencimiento del pago se calcula a partir de la fecha de la factura y las condiciones de pago acordadas con el cliente. Esta fecha se registra en la factura del cliente. Este atributo es fundamental para analizar el «Cumplimiento de la fecha de vencimiento del pago» y calcular el KPI «Tasa de pagos a tiempo». Al comparar «PaymentDueDate» con la fecha real de «Payment Received», la empresa puede detectar pagos atrasados, analizar el comportamiento de pago por segmento de clientes y tomar medidas proactivas para mejorar el flujo de caja y reducir los días pendientes de cobro. Por qué es importante Sirve como referencia para medir el rendimiento de los pagos, algo fundamental para analizar el flujo de caja y gestionar eficazmente las cuentas por cobrar. Dónde obtenerlo Se encuentra en la tabla «CustInvoiceJour», en el campo «DueDate». Ejemplos 2023-05-302023-06-152023-06-30
	Hora de finalización EndTime	La fecha y hora exactas en que se completó una actividad.
Descripción La marca de tiempo de la hora de finalización registra el momento en que concluye una actividad. Cuando está disponible, permite medir su duración con más precisión que si se calcula a partir de la hora de inicio de la actividad siguiente. En el análisis, disponer de las horas de inicio y finalización permite calcular con precisión el «Tiempo de procesamiento» de cada actividad y distinguirlo del «Tiempo de espera» entre actividades. Esto resulta muy útil para identificar qué tareas requieren mucho tiempo y en qué pasos del proceso se producen demoras prolongadas. Por qué es importante Permite calcular con precisión el tiempo de procesamiento de cada actividad y distinguir el tiempo de trabajo activo del tiempo de espera. Dónde obtenerlo Al igual que la hora de inicio, se obtiene de varios campos de fecha y hora. Puede proceder de un campo «ModifiedDateTime» o de una marca de tiempo de actualización de estado en tablas como «SalesTable» o «WHSLoadTable». Ejemplos 2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
	Método de envío ShippingMethod	El método o transportista utilizado para enviar los productos al cliente.
Descripción Este atributo especifica el servicio de transporte utilizado para la entrega, como «Envío terrestre», «Transporte aéreo» o el nombre de un transportista específico. Se selecciona durante la gestión del pedido según las preferencias del cliente, el coste y la rapidez de entrega. Esta dimensión es esencial para el Dashboard «Rendimiento del método de envío». Analizar los tiempos de ciclo desde «Goods Packed» hasta «Goods Delivered» por método de envío ayuda a identificar qué transportistas son más rápidos y fiables, y cuáles suelen causar demoras. Esta información permite mejorar la planificación logística y la selección de transportistas. Por qué es importante Permite analizar el rendimiento de los distintos transportistas y opciones de envío para optimizar la logística en función del coste, la rapidez y la fiabilidad. Dónde obtenerlo Esta información suele almacenarse en la cabecera del pedido de venta o en los registros relacionados con la gestión de pedidos. Consulte la documentación de Microsoft Dynamics 365. Ejemplos FedEx GroundUPS Next Day AirDHL Express
	Nombre de usuario UserName	El nombre de la persona usuaria que realizó la actividad.
Descripción Este atributo identifica a la persona empleada o usuaria del sistema responsable de realizar una tarea, como confirmar un pedido o crear una factura. Suele estar vinculado a un ID de usuario en Microsoft Dynamics 365. Analizar el rendimiento por usuario ayuda a detectar necesidades de formación, reconocer a quienes obtienen mejores resultados y distribuir adecuadamente la carga de trabajo. También es esencial para el cumplimiento y las auditorías, ya que permite atribuir claramente cada acción realizada en el proceso. Por qué es importante Permite analizar el rendimiento del proceso por persona o equipo y detectar oportunidades de formación, desequilibrios en la carga de trabajo y cuellos de botella relacionados con los recursos. Dónde obtenerlo Se obtiene de campos de ID de usuario como «CreatedBy» o «ModifiedBy» en distintas tablas de transacciones. Después, estos campos se vinculan con la tabla principal de usuarios, por ejemplo, «UserInfo», para obtener el nombre completo. Ejemplos Alice JohnsonRobert BrownAdministrador del sistema
	Número de artículo ItemNumber	El identificador único de un producto o servicio incluido en el pedido de venta.
Descripción El número de artículo identifica el producto específico que se vende. Como un pedido de venta puede incluir varios productos, este atributo suele asociarse a los datos de eventos de cada línea. Analizar el proceso por producto ayuda a detectar problemas específicos. Por ejemplo, algunos productos pueden estar asociados a tiempos de gestión más largos, más retrabajo o retenciones de crédito más frecuentes. Esto permite introducir mejoras específicas en la gestión del inventario, la configuración de los datos de producto o los procesos de gestión de pedidos. Por qué es importante Permite analizar el proceso por producto y detectar si determinados artículos están asociados a demoras, retrabajo u otras ineficiencias. Dónde obtenerlo Se encuentra en la tabla «SalesLine», en el campo «ItemId». Ejemplos PROD-00123PROD-00548SVC-00045
	Pago a tiempo OnTimePayment	Indicador booleano que señala si el pago se recibió en la fecha de vencimiento o antes.
Descripción Este atributo calculado compara la marca de tiempo de la actividad «Payment Received» con «PaymentDueDate». Se establece en «true» si el pago se realizó a tiempo y en «false» si se realizó tarde. Este indicador es el componente principal del KPI «Tasa de pagos a tiempo». Permite segmentar rápidamente a los clientes entre quienes pagan a tiempo y quienes se retrasan. Este análisis puede orientar las políticas de crédito, las estrategias de cobro y la gestión de las relaciones con los clientes, al identificar a quienes suelen pagar tarde. Por qué es importante Mide el comportamiento de pago del cliente con respecto a las condiciones acordadas, algo fundamental para gestionar el flujo de caja y evaluar el riesgo crediticio. Dónde obtenerlo Se calcula comparando «EventTime» de la actividad «Payment Received» con el atributo «PaymentDueDate». Fórmula: («Payment Received» Timestamp <= PaymentDueDate). Ejemplos truefalse
	País CountryRegion	El país de la dirección de envío del cliente.
Descripción Este atributo indica el país de destino del envío del pedido de venta. Se obtiene de la información de la dirección de entrega del cliente almacenada en Dynamics 365. Analizar el rendimiento del proceso por país es importante para detectar diferencias regionales. Los envíos internacionales pueden requerir pasos adicionales, como el despacho de aduanas, y prolongar los tiempos de ciclo. Este análisis ayuda a comprender y optimizar la logística en distintos mercados geográficos. Por qué es importante Facilita el análisis geográfico y ayuda a detectar cuellos de botella regionales, problemas de cumplimiento o diferencias de rendimiento en la cadena de suministro. Dónde obtenerlo Se obtiene de la dirección de entrega del cliente, vinculada al pedido de venta. La información del país suele estar en la tabla «LogisticsPostalAddress», vinculada mediante la dirección de entrega de «SalesTable». Ejemplos USADEUCANGBR

Obligatorio Recomendado Opcional

Actividades del proceso de pedido a cobro: procesamiento de pedidos de venta

Estos son los pasos clave del proceso y los hitos importantes que debe registrar en el Registro de eventos para descubrir y analizar con precisión el procesamiento de sus pedidos de venta.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Factura creada	Indica la generación y contabilización de la factura de venta de los productos o servicios enviados. Se trata de una transacción financiera esencial que registra formalmente la deuda del cliente.
Por qué es importante Esta actividad marca el inicio de la etapa de liquidación financiera del proceso. El tiempo entre el envío y la creación de la factura es clave para el KPI 'Tiempo de ciclo de generación de facturas' y afecta al flujo de caja. Dónde obtenerlo Se trata de una transacción financiera explícita. El evento se registra a partir de la fecha y hora de contabilización del diario de factura de venta (CustInvoiceJour). Capturar Registre la marca de tiempo de contabilización del diario de factura de venta. Tipo de evento explicit
	Pago recibido	Esta actividad indica que se ha recibido y aplicado el pago del cliente correspondiente a la factura. El evento se produce en el módulo de cuentas por cobrar y se vincula con la factura original.
Por qué es importante Este hito es clave para analizar el ciclo de conversión de efectivo. Es esencial para medir el KPI 'Tasa de pagos puntuales' e identificar retrasos en el cobro. Dónde obtenerlo Este evento explícito procede del módulo de cuentas por cobrar. Se registra a partir de la fecha de transacción de la liquidación del pago del cliente (CustSettlement) que cierra la transacción de la factura (CustTrans). Capturar Registre la fecha de liquidación de la tabla CustSettlement y vincúlela con la factura y el pedido de venta. Tipo de evento explicit
	Pedido cerrado	Estado final de un pedido de venta procesado correctamente, que indica que se ha enviado y facturado por completo y que no se esperan más transacciones. Marca la finalización satisfactoria del proceso.
Por qué es importante Esta actividad es el principal punto final de los casos completados correctamente. Es esencial para calcular los tiempos de ciclo de principio a fin y el rendimiento. Dónde obtenerlo Se infiere a partir de los campos de estado de SalesTable. Se considera que un pedido está cerrado cuando el 'Sales status' es 'Invoiced' y los estados de las líneas también son 'Invoiced'. Capturar Infiera el evento a partir de los campos de estado de SalesTable cuando cambian a 'Invoiced'. La marca de tiempo suele corresponder a la fecha de la última transacción relacionada, como la facturación o el pago. Tipo de evento inferred
	Pedido confirmado	Esta actividad indica la confirmación formal del pedido de venta y el compromiso de entregar los productos o servicios especificados. En Dynamics 365, se trata de una acción explícita del usuario que genera un diario de confirmación.
Por qué es importante La confirmación es un hito clave que marca el inicio oficial del proceso de cumplimiento del pedido. Medir el tiempo entre la creación y la confirmación permite evaluar la eficiencia del procesamiento en la etapa inicial de ventas. Dónde obtenerlo Este evento explícito se registra a partir de la fecha de contabilización del diario de confirmación del pedido de venta (SalesConfirmJour). La marca de tiempo puede vincularse con SalesTable. Capturar Registre la marca de tiempo de contabilización del diario de confirmación del pedido de venta. Tipo de evento explicit
	Pedido de venta creado	Este evento marca la creación inicial del pedido de venta en el sistema, ya sea por parte de un representante de ventas o mediante un canal automatizado. Se registra explícitamente cuando se crea y guarda un nuevo registro en la tabla principal de pedidos de venta.
Por qué es importante Esta actividad es el punto de partida común a todos los casos de pedidos de venta. Proporciona la marca de tiempo inicial necesaria para calcular el tiempo de ciclo total del pedido y analizar el rendimiento. Dónde obtenerlo Este evento explícito se registra a partir del campo 'Created date and time' del registro de encabezado de SalesTable en Microsoft Dynamics 365. Capturar Lea la marca de tiempo de creación de la entidad SalesTable. Tipo de evento explicit
	Productos enviados	Este evento indica que los productos embalados del pedido se han despachado y han salido del almacén. En Dynamics 365, esto se formaliza al contabilizar el albarán de embalaje.
Por qué es importante Este hito clave marca el fin del proceso interno de cumplimiento del pedido y el inicio de la fase de entrega. Es una marca de tiempo esencial para calcular el rendimiento de los envíos puntuales. Dónde obtenerlo Este evento explícito y claro se registra a partir de la fecha y hora de contabilización del diario de albarán de embalaje (CustPackingSlipJour). Capturar Registre la marca de tiempo de contabilización del diario de albarán de embalaje. Tipo de evento explicit
	Artículos embalados	Esta actividad marca la finalización del embalaje, cuando los artículos recogidos se agrupan y preparan para el envío. En D365, puede coincidir con la generación de un albarán de embalaje.
Por qué es importante El tiempo entre la recogida y el embalaje puede revelar cuellos de botella en las estaciones de embalaje. Es una subetapa clave del tiempo de ciclo total de cumplimiento del pedido. Dónde obtenerlo Puede tratarse de un evento explícito que indique la finalización del embalaje de contenedores en el módulo WMS, o inferirse a partir de la generación del diario de albarán de embalaje (CustPackingSlipJour), que suele marcar el fin del embalaje. Capturar Infiera el evento a partir de la finalización del trabajo de embalaje o de la fecha de creación del diario de albarán de embalaje. Tipo de evento inferred
	Artículos recogidos	Indica que se ha completado la recogida física de todos los artículos del pedido en sus ubicaciones del almacén. Por lo general, se registra cuando el personal del almacén finaliza una lista de recogida o una orden de trabajo en el módulo WMS.
Por qué es importante Registrar el tiempo de finalización de la recogida es esencial para analizar la eficiencia del almacén. Los retrasos en esta etapa afectan directamente al tiempo total hasta el envío. Dónde obtenerlo Este evento explícito se registra en el módulo Warehouse Management. Se obtiene de la marca de tiempo de finalización del trabajo de almacén (WHSWorkTable) relacionado con la recogida del pedido de venta. Capturar Registre la marca de tiempo en que el estado 'Work' de la recogida cambia a 'Closed'. Tipo de evento explicit
	Comprobación de crédito realizada	Indica que se ha completado una comprobación de crédito del cliente asociado al pedido de venta. Puede tratarse de una comprobación automática del sistema o de una revisión manual, que a menudo da lugar a un cambio en el estado de crédito del pedido.
Por qué es importante Analizar la duración y los resultados de las comprobaciones de crédito ayuda a identificar cuellos de botella en el proceso de aprobación de pedidos. Las retenciones frecuentes o los largos tiempos de aprobación pueden retrasar considerablemente el cumplimiento de los pedidos. Dónde obtenerlo Por lo general, se infiere a partir de los cambios de estado relacionados con la gestión de crédito en SalesTable, como el paso de 'On hold' con un motivo de crédito a 'Open'. También puede registrarse en las tablas de gestión de crédito si se utiliza el módulo avanzado. Capturar Infiera el evento a partir del historial de cambios de estado de SalesTable o de las tablas relacionadas con las retenciones de crédito. Tipo de evento inferred
	Inventario reservado	Este evento indica que el inventario necesario para las líneas del pedido de venta se ha reservado en el sistema, de forma física o automática. Así se garantiza que los artículos estén disponibles para su preparación y entrega.
Por qué es importante Hacer un seguimiento de las reservas de inventario permite analizar los retrasos entre la confirmación del pedido y el inicio de las operaciones de almacén. Es un dato esencial para el KPI 'Tiempo de asignación del inventario'. Dónde obtenerlo Puede inferirse a partir de la creación o actualización de los registros de transacciones de inventario (InventTrans) vinculados a las líneas del pedido de venta, cuando el estado indica una reserva (por ejemplo, 'On order' o 'Reserved physical'). Capturar Infiera el evento a partir de la marca de tiempo en que las transacciones de inventario (InventTrans) del pedido aparecen como reservadas. Tipo de evento inferred
	Pedido cancelado	Este evento representa la cancelación de un pedido de venta antes de que se haya enviado y facturado por completo. Es un final alternativo y no satisfactorio del proceso.
Por qué es importante Hacer un seguimiento de las cancelaciones ayuda a identificar las causas de las ventas perdidas o los fallos del proceso. Analizar cuándo y por qué se cancelan los pedidos puede ayudar a mejorar el proceso. Dónde obtenerlo Se infiere a partir del campo 'Sales status' de SalesTable cuando cambia a 'Canceled'. La marca de tiempo corresponde al momento en que se registró el cambio de estado. Capturar Infiera el evento a partir del cambio del campo de estado de SalesTable a 'Canceled'. Tipo de evento inferred
	Pedido enviado al almacén	Marca el momento en que el pedido de venta se envía formalmente al almacén para preparar y despachar los artículos. Es un paso diferenciado en los entornos que utilizan el módulo Warehouse Management (WMS).
Por qué es importante Esta actividad separa el procesamiento del pedido de su cumplimiento físico. Analizar cuánto tiempo espera un pedido antes de enviarse al almacén puede revelar problemas de planificación de recursos o de integración de sistemas. Dónde obtenerlo Este evento explícito se registra a partir de los registros de envío al almacén (WHSLoadTable, WHSShipmentTable) asociados al pedido de venta. Capturar Registre la marca de tiempo de creación de la carga o el envío correspondiente al almacén. Tipo de evento explicit
	Productos entregados	Indica que el envío se ha entregado correctamente en la dirección especificada por el cliente. Esta información suele actualizarse desde el sistema de un transportista externo o mediante una confirmación manual.
Por qué es importante Esta actividad es esencial para medir el KPI 'Cumplimiento de la fecha de entrega' y conocer el tiempo de ciclo real desde la perspectiva del cliente. También permite evaluar el rendimiento del transportista. Dónde obtenerlo D365 estándar no registra este evento de forma nativa y explícita. Por lo general, se infiere a partir de una actualización recibida mediante la integración con el transportista o de una actualización manual del estado del pedido de venta o del registro del envío. Capturar Infiera el evento a partir de los datos integrados del transportista o de la actualización manual de un campo de estado. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Microsoft Dynamics 365

Pasos

Configure la exportación a Azure Data Lake: En su entorno de Dynamics 365 Finance and Operations, asegúrese de que el complemento 'Export to Azure Data Lake' esté instalado y configurado. Para ello, debe vincular D365 a una suscripción de Azure y a una cuenta de destino de Azure Data Lake Storage Gen2.
Seleccione las tablas que se exportarán: Vaya al espacio de trabajo 'Export to Data Lake' en Dynamics 365. Busque y añada las siguientes tablas a la configuración de exportación: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable y CustTable. Active la exportación de todas las tablas seleccionadas.
Configure Azure Synapse Analytics: En el portal de Azure, implemente un espacio de trabajo de Azure Synapse Analytics. Otórguele los permisos necesarios, como 'Storage Blob Data Contributor', en la cuenta de Data Lake donde se almacenan los datos de D365.
Cree una base de datos SQL sin servidor: En Synapse Studio, vaya al centro 'Data'. Cree una base de datos SQL sin servidor para consultar los datos del Data Lake mediante T-SQL.
Cree vistas para las tablas de D365: Para simplificar las consultas, cree vistas SQL en la base de datos sin servidor que apunten a los datos replicados de las tablas de D365 en el Data Lake. Así se abstraen las rutas y los formatos de los archivos subyacentes. Por ejemplo: CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
Prepare la consulta SQL: Abra un nuevo script SQL en Synapse Studio y conéctese a la base de datos sin servidor. Copie en el editor de scripts la consulta SQL completa que se proporciona en esta documentación.
Personalice los parámetros de la consulta: Busque los marcadores de posición al principio de la consulta. Sustituya '{YourDataAreaId}' por el código de empresa que desea analizar. Ajuste los marcadores '{StartDate}' y '{EndDate}' para definir el período de extracción.
Ejecute la consulta: Ejecute el script SQL completo. La consulta recopilará eventos de varias tablas y los combinará en un único formato estandarizado de Registro de eventos.
Revise y exporte los resultados: Cuando termine la consulta, revise los resultados en el panel de resultados de Synapse Studio para comprobar que estén completos y tengan el formato correcto. Utilice la función de exportación integrada para guardarlos como archivo CSV.
Prepare los datos para cargarlos: Abra el archivo CSV exportado y compruebe que esté codificado en UTF-8. Confirme que los encabezados de columna coincidan exactamente con los atributos requeridos, por ejemplo, SalesOrderNumber, ActivityName, EventTime, etc.
Cargue los datos en ProcessMind: Cargue el archivo CSV final validado en su proyecto de ProcessMind para analizar y visualizar el proceso.

Configuración

Requisitos previos: Este método requiere una suscripción activa de Azure y que la función 'Export to Azure Data Lake' esté configurada para su instancia de Dynamics 365 F&O. También se necesitan los permisos adecuados tanto en Azure (para administrar Synapse y Storage) como en D365 (para configurar las exportaciones de datos).
Módulos de D365 necesarios: Para capturar todos los eventos, especialmente los de almacén, se requiere el módulo Warehouse Management (WMS). Los eventos principales dependen de los módulos Sales and Marketing y Accounts Receivable.
Selección de tablas: Es fundamental habilitar la exportación de todas las tablas mencionadas en la consulta, incluidas SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable y CustTable. Si falta alguna tabla, también faltarán actividades.
Filtro por intervalo de fechas: La consulta está diseñada para filtrar por intervalo de fechas mediante los parámetros {StartDate} y {EndDate}. Para las extracciones iniciales, se recomienda utilizar un intervalo limitado, por ejemplo, de 3 a 6 meses, para que la consulta se ejecute en un tiempo razonable.
Filtro por empresa (DataAreaId): Debe configurar el marcador '{YourDataAreaId}' para seleccionar una entidad jurídica específica de su entorno de D365. La consulta no está diseñada para analizar varias empresas en una sola ejecución.
Consideraciones de rendimiento: El rendimiento de las consultas en un grupo de SQL sin servidor puede variar con conjuntos de datos muy grandes. Considere programar la extracción para horas de menor actividad. Si realiza extracciones frecuentes, puede materializar el Registro de eventos final como una nueva tabla en el Data Lake para mejorar el rendimiento de los procesos posteriores.

Consulta de ejemplo sql

WITH SalesOrderBase AS (
    SELECT
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME AS CustomerName,
        ST.SHIPPINGDATECONFIRMED AS ConfirmedDeliveryDate,
        ST.DELIVERYDATE AS RequestedDeliveryDate,
        ST.PURCHORDERFORMNUM AS SalesChannel, -- Example mapping, adjust if you use a different field for Sales Channel
        SUM(SL.LINEAMOUNT) AS OrderValue
    FROM dbo.SALESTABLE ST
    LEFT JOIN dbo.SALESLINE SL ON ST.SALESID = SL.SALESID AND ST.DATAREAID = SL.DATAREAID
    LEFT JOIN dbo.CUSTTABLE CT ON ST.CUSTACCOUNT = CT.ACCOUNTNUM AND ST.DATAREAID = CT.DATAREAID
    WHERE ST.DATAREAID = '{YourDataAreaId}'
      AND ST.CREATEDDATETIME >= '{StartDate}' AND ST.CREATEDDATETIME < '{EndDate}'
    GROUP BY
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME,
        ST.SHIPPINGDATECONFIRMED,
        ST.DELIVERYDATE,
        ST.PURCHORDERFORMNUM
)
-- 1. Sales Order Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Sales Order Created' AS ActivityName,
    ST.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID

UNION ALL

-- 2. Credit Check Performed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Credit Check Performed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime, -- This assumes a status change date reflects the credit check time
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.CREDITLIMITTYPE > 0 -- Example condition for a credit check being done. Adjust based on your configuration.

UNION ALL

-- 3. Order Confirmed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Confirmed' AS ActivityName,
    CJ.CONFIRMDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTCONFIRMJOUR CJ ON SO.SALESID = CJ.SALESID AND SO.DATAREAID = CJ.DATAAREAID

UNION ALL

-- 4. Inventory Reserved (approximated by first line item reservation)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Inventory Reserved' AS ActivityName,
    MIN(SL.CREATEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESLINE SL ON SO.SALESID = SL.SALESID AND SO.DATAREAID = SL.DATAREAID
WHERE SL.RESERVATION > 0 -- Identifies lines with a reservation status
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 5. Released To Warehouse
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Released To Warehouse' AS ActivityName,
    WLT.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSLOADTABLE WLT ON SO.SALESID = WLT.SALESID AND SO.DATAREAID = WLT.DATAAREAID

UNION ALL

-- 6. Goods Picked (approximated by last pick work closure)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Picked' AS ActivityName,
    MAX(WWT.MODIFIEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSWORKTABLE WWT ON SO.SALESID = WWT.ORDERNUM AND SO.DATAREAID = WWT.DATAAREAID
WHERE WWT.WORKTYPE = 'Pick' AND WWT.WORKSTATUS = 'Closed'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 7. Goods Packed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Packed' AS ActivityName,
    PSJ.CREATEDDATETIME AS EventTime, -- Using creation time of packing slip as proxy
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 8. Goods Shipped
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Shipped' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 9. Goods Delivered (placeholder, often requires custom fields)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Delivered' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime, -- Placeholder, using shipment date. True delivery requires external data.
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID
WHERE 1 = 2 -- This will return no rows unless logic is added to read from a custom field with actual delivery dates

UNION ALL

-- 10. Invoice Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Invoice Created' AS ActivityName,
    CIJ.INVOICEDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID

UNION ALL

-- 11. Payment Received (approximated by last settlement date)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Payment Received' AS ActivityName,
    MAX(CT.SETTLEMENTDATE) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID
JOIN dbo.CUSTTRANS CT ON CIJ.INVOICEID = CT.INVOICE AND CIJ.DATAAREAID = CT.DATAAREAID
WHERE CT.TRANSTYPE = 'Payment'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 12. Order Closed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Closed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 4 -- Status for 'Invoiced'

UNION ALL

-- 13. Order Cancelled
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Cancelled' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 3; -- Status for 'Canceled'

Pasos

Requisitos previos y configuración: Asegúrese de tener instalada la versión 3.6 o posterior de Python. Instale las bibliotecas necesarias de Python ejecutando este comando en la terminal: pip install pandas requests msal.
Registre una aplicación en Azure AD: Vaya al portal de Azure y registre una nueva aplicación en Azure Active Directory. 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).
Cree un secreto de cliente: En la aplicación de Azure AD que acaba de registrar, cree un secreto de cliente en 'Certificates & secrets'. Copie el valor del secreto de inmediato, ya que no volverá a estar visible. Este es su CLIENT_SECRET.
Conceda permisos de API: En la configuración de la aplicación de Azure AD, vaya a 'API permissions'. Añada un permiso para 'Dynamics ERP' o 'Dynamics 365 for Finance and Operations'. Seleccione 'Delegated permissions' y conceda user_impersonation. A continuación, vuelva a añadir el mismo permiso, pero seleccione 'Application permissions' y conceda Financials.ReadWrite.All o, si está disponible y es suficiente, un permiso de solo lectura más restringido. Conceda el consentimiento de administrador para estos permisos.
Cree un usuario de aplicación en Dynamics 365: En su entorno de Dynamics 365, vaya a 'System administration' > 'Users' > 'Users'. Cree un usuario y asígnele el ID de aplicación del registro de aplicaciones de Azure AD. Asígnele un rol de seguridad, como 'System administrator' (para acceso completo), o un rol personalizado con acceso de lectura a las entidades de datos necesarias (SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders, SalesInvoiceHeadersV2, etc.).
Configure el script de Python: Abra el script de Python proporcionado en un editor. Busque la sección de configuración al principio del archivo y sustituya los valores de marcador de posición de D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE y END_DATE por los datos específicos de su entorno.
Defina las asignaciones de entidades (opcional): Revise los nombres de entidades y campos que utiliza el script. Si su organización utiliza entidades o campos personalizados para registrar ciertas actividades, quizá deba ajustar las consultas OData del script.
Ejecute el script de extracción: Ejecute el script desde la línea de comandos con el comando python your_script_name.py. El script se autenticará, consultará la API OData de Dynamics 365 para cada actividad y procesará los datos. Mostrará el avance en la consola.
Revise el archivo de salida: Si la ejecución se completa correctamente, el script generará un archivo CSV llamado d365_order_to_cash_event_log.csv en el mismo directorio. Abra el archivo para comprobar que el Registro de eventos extraído sea correcto y esté completo.
Cargue los datos en ProcessMind: El archivo CSV generado tiene el esquema requerido y está listo para cargarse directamente en ProcessMind y analizar el proceso.

Configuración

D365_URL: URL base de su entorno de Dynamics 365 Finance and Operations. Debe tener un formato similar a https://[your-d365-environment-name].operations.dynamics.com.
TENANT_ID: ID de directorio (inquilino) de su instancia de Azure Active Directory. Puede encontrarlo en la página de información general del registro de aplicaciones de Azure AD.
CLIENT_ID: ID de aplicación (cliente) de la aplicación que registró en Azure AD.
CLIENT_SECRET: Valor del secreto de cliente que generó para la aplicación de Azure AD.
COMPANY_FILTER: Especifica la entidad jurídica de Dynamics 365 (por ejemplo, 'USMF') de la que se extraerán los datos. Este filtro es obligatorio para consultar los datos de la empresa correcta.
START_DATE / END_DATE: Define el intervalo de fechas de la extracción con el formato 'YYYY-MM-DD'. Para el análisis inicial, se recomienda un período de 3 a 6 meses para equilibrar el volumen de datos y la información obtenida. Tenga en cuenta que los intervalos amplios pueden aumentar considerablemente el tiempo de extracción.
Requisitos previos: Se necesita acceso a Azure AD para registrar una aplicación y conceder permisos. También se requiere una cuenta de usuario de Dynamics 365 con permisos para crear un usuario de aplicación y asignar roles de seguridad. El rol asignado debe permitir el acceso de lectura a todas las entidades consultadas por el script.

Consulta de ejemplo python

import requests
import pandas as pd
import msal
import json
import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your D365 environment and Azure AD App details
D365_URL = class="hl-string">"https://[your-d365-environment-name].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your-Azure-AD-Tenant-ID]"
CLIENT_ID = class="hl-string">"[Your-Azure-AD-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Azure-AD-Client-Secret]"

class=class="hl-string">"hl-comment"># --- EXTRACTION PARAMETERS ---
COMPANY_FILTER = class="hl-string">"[Your-Company-Code]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SCRIPT --- 

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

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD and returns an access token."""
    app = msal.ConfidentialClientApplication(
        client_id=CLIENT_ID,
        client_credential=CLIENT_SECRET,
        authority=AUTHORITY_URL
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        raise Exception(class="hl-string">"Could not authenticate.")

def execute_odata_query(access_token, entity, select_fields, filter_query, expand_fields=None):
    class="hl-string">"""Executes an OData query against a D365 entity and handles pagination."""
    all_results = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.maxpagesize=1000' class=class="hl-string">"hl-comment"># Request pagination
    }
    
    query_url = fclass="hl-string">"{API_ENDPOINT}/{entity}?$select={select_fields}&$filter={filter_query}&cross-company=true"
    if expand_fields:
        query_url += fclass="hl-string">"&$expand={expand_fields}"
    
    print(fclass="hl-string">"Querying {entity}...")
    while query_url:
        try:
            response = requests.get(query_url, headers=headers)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_results.extend(data.get(class="hl-string">'value', []))
            query_url = data.get(class="hl-string">'@odata.nextLink') class=class="hl-string">"hl-comment"># Get URL for the next page
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error for {entity}: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            return [] class=class="hl-string">"hl-comment"># Return empty list on error
        except json.JSONDecodeError:
            print(fclass="hl-string">"JSON Decode Error for {entity}. Response was not valid JSON.")
            print(fclass="hl-string">"Response text: {response.text}")
            return []

    print(fclass="hl-string">"...found {len(all_results)} records for {entity}.")
    return all_results

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    try:
        token = get_access_token()
    except Exception as e:
        print(e)
        return

    all_events = []
    now_utc = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for most queries
    base_select_fields = class="hl-string">"SalesOrderNumber,TotalInvoiceAmount,SalesOrderOriginCode,RequestedShippingDate,ConfirmedShippingDate,CustomerAccount"
    base_expand_fields = class="hl-string">"CustomerV3(CustomerName)"

    class=class="hl-string">"hl-comment"># Common date filter for creation/modification timestamps
    date_filter = fclass="hl-string">"(CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z)"

    class=class="hl-string">"hl-comment"># 1. Sales Order Created
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},CreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {date_filter}", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Created',
            class="hl-string">'EventTime': record.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 2. Credit Check Performed (based on status change)
    class=class="hl-string">"hl-comment"># This assumes a credit check is reflected by the CreditLimitApprovalStatus. This logic may need adjustment.
    class=class="hl-string">"hl-comment"># We look for orders modified in the period, then check the status.
    modified_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},ModifiedDateTime,CreditLimitApprovalStatus", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {modified_date_filter} and CreditLimitApprovalStatus ne 'NoCheck'", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Credit Check Performed',
            class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime'), class=class="hl-string">"hl-comment"># Using ModifiedDateTime as a proxy
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 3. Order Confirmed
    confirmation_date_filter = fclass="hl-string">"(ConfirmationDate ge {START_DATE} and ConfirmationDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesConfirmationHeaders', class="hl-string">"SalesOrderNumber,ConfirmationDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {confirmation_date_filter}")
    class=class="hl-string">"hl-comment"># We need to get details from the SalesOrderHeader
    order_numbers = class="hl-string">"'" + class="hl-string">"','".join([rec[class="hl-string">'SalesOrderNumber'] for rec in data if rec.get(class="hl-string">'SalesOrderNumber')]) + class="hl-string">"'"
    if order_numbers != class="hl-string">"''":
        header_data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', base_select_fields, fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({order_numbers})", base_expand_fields)
        header_map = {h[class="hl-string">'SalesOrderNumber']: h for h in header_data}
        for record in data:
            header = header_map.get(record.get(class="hl-string">'SalesOrderNumber'))
            if header:
                all_events.append({
                    class="hl-string">'SalesOrderNumber': header.get(class="hl-string">'SalesOrderNumber'),
                    class="hl-string">'ActivityName': class="hl-string">'Order Confirmed',
                    class="hl-string">'EventTime': str(record.get(class="hl-string">'ConfirmationDate')) + class="hl-string">'T12:00:00Z', class=class="hl-string">"hl-comment"># Date only field, adding midday time
                    class="hl-string">'OrderValue': header.get(class="hl-string">'TotalInvoiceAmount'),
                    class="hl-string">'CustomerName': header.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
                    class="hl-string">'SalesChannel': header.get(class="hl-string">'SalesOrderOriginCode'),
                    class="hl-string">'RequestedDeliveryDate': header.get(class="hl-string">'RequestedShippingDate'),
                    class="hl-string">'ConfirmedDeliveryDate': header.get(class="hl-string">'ConfirmedShippingDate')
                })
    
    class=class="hl-string">"hl-comment"># 4 & 5. Inventory Reserved & Released To Warehouse (WMS)
    class=class="hl-string">"hl-comment"># These are complex. This is a proxy based on Warehouse Work creation time.
    work_date_filter = fclass="hl-string">"(WorkCreatedDateTime ge {START_DATE}T00:00:00Z and WorkCreatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WarehouseWorkHeaders', class="hl-string">"OrderNumber,WorkCreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {work_date_filter} and WorkType eq 'SalesOrders'")
    for record in data:
        class=class="hl-string">"hl-comment"># Assuming reservation happens just before release to warehouse
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Inventory Reserved', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Released To Warehouse', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})

    class=class="hl-string">"hl-comment"># 6 & 7. Goods Picked & Goods Packed (WMS)
    class=class="hl-string">"hl-comment"># Proxy using Shipment status updates. This logic may need refinement based on specific WMS setup.
    shipment_date_filter = fclass="hl-string">"(ShipmentStatusLastUpdatedDateTime ge {START_DATE}T00:00:00Z and ShipmentStatusLastUpdatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WHSShipmentTables', class="hl-string">"SalesOrderNumber,ShipmentStatus,ShipmentStatusLastUpdatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {shipment_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Picked', class="hl-string">'Loaded', class="hl-string">'Shipped']:
             all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Picked', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Loaded', class="hl-string">'Shipped']:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Packed', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})

    class=class="hl-string">"hl-comment"># 8. Goods Shipped (Posting Packing Slip)
    packslip_date_filter = fclass="hl-string">"(ShippingDate ge {START_DATE} and ShippingDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ShippingDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Shipped', class="hl-string">'EventTime': str(record.get(class="hl-string">'ShippingDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 9. Goods Delivered
    class=class="hl-string">"hl-comment"># This is often not a standard field. We use ModifiedDateTime on Packing Slip as a placeholder.
    packslip_mod_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ModifiedDateTime,DeliveryMode", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_mod_date_filter} and DeliveryMode eq '[Your-Delivered-Status-Code]'")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Delivered', class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})

    class=class="hl-string">"hl-comment"># 10. Invoice Created
    invoice_date_filter = fclass="hl-string">"(InvoiceDate ge {START_DATE} and InvoiceDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesInvoiceHeadersV2', class="hl-string">"SalesOrderNumber,InvoiceDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': str(record.get(class="hl-string">'InvoiceDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 11. Payment Received
    class=class="hl-string">"hl-comment"># This requires looking at customer payments and settling them to invoices, then to sales orders.
    class=class="hl-string">"hl-comment"># This is a simplified proxy using the ClosedDate of the invoice.
    invoice_closed_date_filter = fclass="hl-string">"(ClosedDate ge {START_DATE} and ClosedDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'CustomerInvoices', class="hl-string">"SalesOrderNumber,ClosedDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_closed_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ClosedDate') and record.get(class="hl-string">'SalesOrderNumber'):
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Received', class="hl-string">'EventTime': str(record.get(class="hl-string">'ClosedDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 12 & 13. Order Closed & Order Cancelled
    class=class="hl-string">"hl-comment"># These are statuses on the Sales Order Header.
    status_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', class="hl-string">"SalesOrderNumber,SalesOrderStatus,ModifiedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {status_date_filter} and (SalesOrderStatus eq 'Invoiced' or SalesOrderStatus eq 'Canceled')")
    for record in data:
        activity = class="hl-string">''
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Invoiced': activity = class="hl-string">'Order Closed'
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Canceled': activity = class="hl-string">'Order Cancelled'
        if activity:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})


    class=class="hl-string">"hl-comment"># --- Final Processing ---
    if not all_events:
        print(class="hl-string">"No events found. Exiting.")
        return

    df = pd.DataFrame(all_events)
    print(fclass="hl-string">"Total events created: {len(df)}")

    class=class="hl-string">"hl-comment"># Drop events without a case ID or timestamp
    df.dropna(subset=[class="hl-string">'SalesOrderNumber', class="hl-string">'EventTime'], inplace=True)
    print(fclass="hl-string">"Events after dropping nulls: {len(df)}")

    class=class="hl-string">"hl-comment"># Fill in missing recommended attributes by merging back header details
    print(class="hl-string">"Enriching data with header attributes...")
    unique_orders = class="hl-string">"'" + class="hl-string">"','".join(df[class="hl-string">'SalesOrderNumber'].unique()) + class="hl-string">"'"
    if unique_orders != class="hl-string">"''":
        header_data_final = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields}", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({unique_orders})", base_expand_fields)
        header_df = pd.DataFrame(header_data_final)
        if not header_df.empty:
            header_df = header_df.rename(columns={
                class="hl-string">'TotalInvoiceAmount': class="hl-string">'OrderValue',
                class="hl-string">'SalesOrderOriginCode': class="hl-string">'SalesChannel',
                class="hl-string">'RequestedShippingDate': class="hl-string">'RequestedDeliveryDate',
                class="hl-string">'ConfirmedShippingDate': class="hl-string">'ConfirmedDeliveryDate'
            })
            class=class="hl-string">"hl-comment"># Extract nested customer name
            header_df[class="hl-string">'CustomerName'] = header_df[class="hl-string">'CustomerV3'].apply(lambda x: x.get(class="hl-string">'CustomerName') if isinstance(x, dict) else None)
            df = df.merge(header_df[[class="hl-string">'SalesOrderNumber', class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']], on=class="hl-string">'SalesOrderNumber', how=class="hl-string">'left', suffixes=(class="hl-string">'', class="hl-string">'_y'))
            class=class="hl-string">"hl-comment"># Fill NaNs from merge
            for col in [class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']:
                if col + class="hl-string">'_y' in df.columns:
                    df[col] = df[col].fillna(df[col + class="hl-string">'_y'])
                    df.drop(columns=[col + class="hl-string">'_y'], inplace=True)

    class=class="hl-string">"hl-comment"># Add required static columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataUpdate'] = now_utc

    class=class="hl-string">"hl-comment"># Ensure required columns exist
    final_cols = [class="hl-string">'SalesOrderNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
                  class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']
    for col in final_cols:
        if col not in df.columns:
            df[col] = None
    
    class=class="hl-string">"hl-comment"># Reorder and save
    df = df[final_cols]
    df.to_csv(class="hl-string">'d365_order_to_cash_event_log.csv', index=False)
    print(class="hl-string">"Successfully created d365_order_to_cash_event_log.csv")

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

¿Todo listo para comenzar?

Utilice este Template para preparar sus datos y, después, cárguelos en nuestra plataforma para obtener información útil y mejorar la eficiencia del procesamiento de sus pedidos de venta. ¡Comience a optimizar hoy mismo!

Volver a la guía de mejora

Descargar Template

Optimice ahora el proceso de pedido a cobro: procesamiento de pedidos de venta

Detecte ineficiencias y reduzca el tiempo de ciclo un 30 % para completar los pedidos más rápido.

Comience su prueba gratuita

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

Su Template de datos para el proceso de pedido a cobro: procesamiento de pedidos de venta

Su Template de datos para el proceso de pedido a cobro: procesamiento de pedidos de venta

Atributos del proceso de pedido a cobro: procesamiento de pedidos de venta

Actividades del proceso de pedido a cobro: procesamiento de pedidos de venta

Guías de extracción

Consulta SQL de Azure Data Lake con Synapse Analytics

Pasos

Configuración

Consulta de ejemplo sql

Script de Python con la API web OData de Dynamics 365

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

Optimice ahora el proceso de pedido a cobro: procesamiento de pedidos de venta