> Amélioration continue des processus > Commande à encaissement : traitement des commandes client > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données pour le traitement des commandes, de la commande à l’encaissement

Microsoft Dynamics 365

← Retour au guide d’amélioration

Attributs du traitement des commandes, de la commande à l’encaissement(20) Activités du traitement des commandes, de la commande à l’encaissement(13) Guides d’extraction(2)

Votre modèle de données pour le traitement des commandes, de la commande à l’encaissement

Ce modèle présente de manière structurée les éléments de données essentiels à l’analyse du traitement des commandes, de la commande à l’encaissement, dans Microsoft Dynamics 365. Il précise les attributs à recueillir et les activités clés à suivre dans votre journal d’événements. Vous y trouverez également des conseils pratiques pour extraire efficacement ces données de votre système.

Attributs recommandés pour une analyse complète
Activités clés du processus à suivre
Conseils d’extraction des données pour Microsoft Dynamics 365

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du traitement des commandes, de la commande à l’encaissement

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le traitement des commandes, de la commande à l’encaissement, dans Microsoft Dynamics 365.

5 Obligatoire 5 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement métier ou de la tâche qui s’est produit à un moment donné du processus de commande client.
Description Cet attribut désigne une étape ou un événement distinct du cycle de vie d’une commande client, comme « Commande client créée », « Marchandises expédiées » ou « Paiement reçu ». La séquence de ces activités pour une commande donnée constitue le flux du processus. L’analyse de la séquence, de la fréquence et des transitions entre les activités est au cœur du process mining. Elle permet de visualiser la carte du processus, de repérer les variantes fréquentes ou rares, de détecter les goulots d’étranglement et de localiser les reprises ou les écarts de conformité. Cet attribut est fondamental pour comprendre ce qui se passe réellement dans le processus. Pourquoi est-ce important ? Cet attribut définit les étapes du processus et permet d’en construire et d’en visualiser le flux, ce qui constitue l’objectif principal du process mining. Où trouver ces données Cet attribut est défini en associant des événements système ou des changements de statut précis dans des tables comme « SalesTable », ainsi que dans les tables logistiques ou financières associées, à un nom d’activité standardisé. Exemples Commande client crééeMarchandises expédiéesFacture crééePaiement reçu
	Commande client SalesOrderNumber	Identifiant unique de chaque commande client, utilisé comme identifiant principal du cas dans le processus.
Description Le numéro de commande client est un code alphanumérique unique attribué à chaque commande client dans Microsoft Dynamics 365. Il sert d’identifiant de cas principal et relie toutes les activités et tous les événements associés, de la création à la clôture. En process mining, cet attribut est essentiel pour reconstituer le parcours de bout en bout de chaque commande client. Il permet aux analystes de suivre la séquence complète des activités, de mesurer la durée des cas et d’analyser les variations propres à chaque commande. Il constitue ainsi le fondement de l’ensemble de l’analyse du processus. Pourquoi est-ce important ? Cet identifiant est essentiel pour relier tous les événements associés et permettre une analyse complète, de bout en bout, du cycle de vie de chaque commande client. Où trouver ces données Situé dans la table « SalesTable », champ « SalesId ». Exemples SO-00102345SO-00102346SO-00102347
	Heure de début EventTime	Date et heure précises auxquelles une activité ou un événement s’est produit.
Description L’heure de l’événement, ou horodatage, indique le moment exact où une activité s’est produite. Chaque activité du journal d’événements est associée à un horodatage, ce qui permet de reconstituer chronologiquement le processus pour chaque cas. Cet attribut est essentiel à toutes les analyses temporelles en process mining. Il sert à calculer les temps de cycle entre les activités, à mesurer la durée totale d’un cas, à analyser les temps d’attente et à repérer les goulots d’étranglement qui retardent le processus. Il permet également de suivre les performances dans le temps, par exemple le débit par jour, par semaine ou par mois. Pourquoi est-ce important ? Cet horodatage est essentiel pour calculer les indicateurs de durée, comme les temps de cycle, et repérer les goulots d’étranglement, ainsi que pour classer les événements par ordre chronologique. Où trouver ces données Cet horodatage est calculé à partir de différents champs de date et d’heure associés à des transactions précises, comme « SalesTable.CreatedDateTime » pour la création d’une commande ou les dates de comptabilisation des journaux de paiement. Exemples 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation ou extraction des données depuis le système source.
Description Cet attribut enregistre la date et l’heure de la dernière extraction des données depuis Microsoft Dynamics 365. Il vous permet de vérifier si les données analysées sont à jour. Pour analyser un processus et prendre des décisions éclairées, il est essentiel de connaître l’ancienneté des données. Cet horodatage indique précisément à quel moment elles ont été mises à jour pour la dernière fois, afin que vous puissiez vous fier à des conclusions fondées sur des informations récentes. Pourquoi est-ce important ? Il permet de vérifier que les données sont à jour, un point essentiel pour garantir la pertinence et l’exactitude de l’analyse Process Mining. Où trouver ces données Cet horodatage est généré lors de l’extraction des données, puis ajouté à chaque enregistrement au moment de leur ingestion. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Système source SourceSystem	Identifie le système d’information d’où proviennent les données.
Description Cet attribut indique l’application source dans laquelle les données d’événement ont été enregistrées. Il s’agit généralement de « Microsoft Dynamics 365 ». Dans une analyse portant sur un seul système, cet attribut peut sembler redondant. Il devient toutefois essentiel lorsque vous regroupez des données issues de plusieurs systèmes, par exemple d’un CRM distinct ou d’un système de gestion d’entrepôt. Il assure la traçabilité des données et facilite le diagnostic des problèmes d’extraction en indiquant l’origine des enregistrements. Pourquoi est-ce important ? Cet attribut précise l’origine des données, notamment lorsqu’elles proviennent de plusieurs systèmes, et en assure la traçabilité. Où trouver ces données Cette valeur statique est généralement ajoutée lors de la transformation des données pour indiquer l’origine du jeu de données. Exemples Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
	Canal de vente SalesChannel	Canal par lequel la commande a été reçue, par exemple le Web, la vente directe ou un partenaire.
Description Le canal de vente indique l’origine de la commande client. Il peut s’agir d’un site de commerce en ligne, d’une équipe commerciale, d’un magasin, d’un centre d’appels ou d’un réseau de partenaires. Dans Dynamics 365, cette dimension est souvent configurée en fonction des besoins de l’entreprise. L’analyse du processus par canal de vente permet de comparer les performances des différents canaux. Par exemple, les commandes en ligne peuvent être traitées plus rapidement et de façon plus automatisée que celles reçues par téléphone. Ces constats aident à optimiser les processus et à répartir les ressources en fonction de chaque canal. Ils peuvent alimenter des Dashboards tels que « Valeur des commandes par segment ». Pourquoi est-ce important ? Permet de comparer les performances des différents canaux de vente et de repérer les inefficacités ou les bonnes pratiques propres à la façon dont les commandes sont passées. Où trouver ces données Cette information figure généralement dans l’en-tête de la commande client. Consultez la documentation Microsoft Dynamics 365 pour connaître le champ concerné. Exemples WebVente directePartenaireVente au détail
	Date de livraison confirmée ConfirmedDeliveryDate	Date de livraison confirmée par l’entreprise et communiquée au client.
Description La date de livraison confirmée est celle à laquelle l’entreprise s’engage à livrer les marchandises au client. Elle est définie après les vérifications internes, notamment la disponibilité des stocks et les calendriers de production. Cet attribut est essentiel au calcul de l’indicateur « Taux de respect des dates de livraison », qui mesure le respect des engagements opérationnels. Il constitue une référence interne plus réaliste que la date initialement demandée par le client. L’analyse des écarts par rapport à cette date permet de repérer les défaillances internes en matière de logistique et d’exécution des commandes. Pourquoi est-ce important ? Représente l’engagement de l’entreprise envers le client et constitue une référence interne importante pour mesurer la fiabilité de l’exécution des commandes et les performances opérationnelles. Où trouver ces données Cette valeur figure dans les données des lignes de commande, souvent dans la table « SalesLine », dans un champ tel que « ConfirmedDlv ». Exemples 2023-05-122023-06-012023-05-28
	Date de livraison demandée RequestedDeliveryDate	Date à laquelle le client souhaite recevoir sa commande.
Description Cet attribut enregistre la date à laquelle le client a initialement demandé à recevoir ses marchandises. Elle est saisie lors de la création de la commande et sert de référence pour mesurer les performances de livraison du point de vue du client. Cette date est une donnée essentielle du Dashboard « Respect des dates de livraison ». La comparaison de « RequestedDeliveryDate » avec « ConfirmedDeliveryDate » et la date réelle de l’activité « Marchandises livrées » indique dans quelle mesure l’entreprise répond aux attentes des clients. Un écart important peut révéler des problèmes de planification, de stock ou de logistique. Pourquoi est-ce important ? Représente la date de livraison attendue par le client et fournit une référence essentielle pour mesurer sa satisfaction et la performance des livraisons dans les délais. Où trouver ces données Cette valeur figure dans la table « SalesTable », généralement dans un champ nommé « DeliveryDate » ou une variante similaire. Exemples 2023-05-102023-06-012023-05-25
	Nom du client CustomerName	Nom du client qui a passé la commande.
Description Cet attribut contient la raison sociale du client associé à la commande. Il est obtenu en reliant le numéro de compte client de la commande aux données de référence principales des clients. L’analyse du processus par client est essentielle pour comprendre les comportements et les niveaux de service propres à chacun. Elle permet de repérer les clients qui subissent le plus de retards, ceux dont les commandes font le plus souvent l’objet de reprises et ceux dont le parcours s’écarte du processus standard. Ces informations sont importantes pour améliorer la satisfaction client et gérer efficacement les comptes clés. Pourquoi est-ce important ? Permet d’analyser le processus du point de vue du client et de repérer les tendances, les retards ou les problèmes propres à certains clients, qui ont une incidence directe sur leur satisfaction. Où trouver ces données Cette valeur est recherchée dans « CustTable » à l’aide du champ « CustAccount » de « SalesTable ». Exemples Contoso LtdAdatum CorporationFabrikam Inc.
	Valeur de la commande OrderValue	Montant total de la commande client.
Description Cet attribut correspond au montant total de la commande client, taxes, frais et articles compris. Il s’agit d’une métrique financière importante associée à chaque cas. La valeur de la commande permet d’analyser le processus selon le montant des commandes. Vous pouvez ainsi vérifier si les commandes de montant élevé sont traitées différemment ou subissent davantage de retards que les commandes de faible montant. Ces éléments aident à prioriser les améliorations portant sur les cas les plus importants sur le plan financier et alimentent des Dashboards tels que « Valeur des commandes par segment ». Pourquoi est-ce important ? Permet de segmenter le processus selon des critères financiers, de prioriser les améliorations concernant les commandes de montant élevé et de comprendre les conséquences financières des écarts du processus. Où trouver ces données Cette valeur figure dans les données d’en-tête de la commande client. Consultez la documentation Microsoft Dynamics 365 pour connaître la table et le champ concernés. Elle est souvent calculée à partir des montants des lignes de commande. Exemples 5250.7512300.00899.50
	Comporte des reprises IsRework	Indicateur booléen précisant si la commande client a fait l’objet de reprises, par exemple si une activité a été répétée.
Description Cet attribut calculé repère les cas dont le parcours s’écarte du parcours nominal. Les reprises sont détectées à partir de séquences d’activités qui indiquent qu’une étape a été répétée, par exemple lorsqu’une commande est d’abord déconfirmée, puis confirmée à nouveau, ou lorsque des marchandises sont prélevées avant d’être remises en stock. Le repérage des cas comportant des reprises est essentiel au calcul de l’indicateur « Taux de reprises des commandes ». Les analystes peuvent isoler et examiner rapidement les parcours inefficaces pour en comprendre les causes, comme des erreurs de saisie, des problèmes de crédit ou des ruptures de stock. La réduction des reprises est un objectif fréquent des projets d’amélioration des processus. Pourquoi est-ce important ? Aide à mesurer les inefficacités du processus en repérant les cas où des étapes ont dû être répétées, afin de cibler les analyses et de réduire les pertes et les retards. Où trouver ces données L’outil Process Mining calcule cet attribut en analysant la séquence d’activités de chaque cas. Par exemple, la détection d’une séquence telle que (A -> B -> C -> B) signale un cas comportant des reprises. Exemples truefalse
	Date d’échéance du paiement PaymentDueDate	Date limite à laquelle le client doit régler la facture.
Description La date d’échéance du paiement est calculée à partir de la date de facture et des conditions de paiement convenues avec le client. Elle est enregistrée sur la facture client. Cet attribut est essentiel à l’analyse « Respect des échéances de paiement » et au calcul de l’indicateur « Taux de paiement dans les délais ». En comparant « PaymentDueDate » à la date réelle de l’activité « Paiement reçu », l’entreprise peut repérer les retards de paiement, analyser les comportements par segment de clientèle et prendre des mesures pour améliorer sa trésorerie et réduire le délai moyen de paiement client. Pourquoi est-ce important ? Cette date sert de référence pour mesurer les délais de paiement. Elle est essentielle à l’analyse de la trésorerie et à la gestion des comptes clients. Où trouver ces données Cette valeur figure dans la table « CustInvoiceJour », dans le champ « DueDate ». Exemples 2023-05-302023-06-152023-06-30
	Heure de fin EndTime	Date et heure précises auxquelles une activité a été achevée.
Description L’horodatage de l’heure de fin indique le moment où une activité s’achève. Lorsqu’il est disponible, il permet de mesurer sa durée avec plus de précision que si celle-ci était déduite de l’heure de début de l’activité suivante. En analyse, disposer des heures de début et de fin permet de calculer précisément la « Durée de traitement » de chaque activité et de la distinguer du « Temps d’attente » entre les activités. Vous pouvez ainsi repérer les tâches qui prennent du temps et les étapes du processus qui entraînent de longues attentes. Pourquoi est-ce important ? Permet de calculer précisément la durée de traitement de chaque activité et de distinguer le temps de travail effectif du temps d’attente. Où trouver ces données Comme l’heure de début, cette valeur est calculée à partir de différents champs de date et d’heure. Elle peut provenir d’un champ « ModifiedDateTime » ou de l’horodatage d’une mise à jour de statut dans des tables telles que « SalesTable » ou « WHSLoadTable ». Exemples 2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
	Livrée dans les délais OnTimeDelivery	Indicateur booléen précisant si les marchandises ont été livrées au plus tard à la date de livraison confirmée.
Description Cet attribut calculé compare l’horodatage de l’activité « Marchandises livrées » à « ConfirmedDeliveryDate » pour chaque commande client. Il prend la valeur « true » si la livraison a eu lieu à la date prévue ou avant, et « false » si elle a été effectuée en retard. Cet indicateur sert de base au calcul du « Taux de respect des dates de livraison ». Il facilite l’analyse en permettant de filtrer et de regrouper les commandes livrées dans les délais et celles livrées en retard. Vous pouvez ainsi repérer rapidement les facteurs associés aux retards, comme certains produits, clients, pays ou modes d’expédition. Pourquoi est-ce important ? Mesure directement les performances d’exécution par rapport aux engagements pris, un indicateur important de la satisfaction client et de la fiabilité de la chaîne d’approvisionnement. Où trouver ces données Calculé en comparant l’« EventTime » de l’activité « Marchandises livrées » à l’attribut « ConfirmedDeliveryDate ». Formule : (« Horodatage de Marchandises livrées » <= ConfirmedDeliveryDate). Exemples truefalse
	Mode d’expédition ShippingMethod	Mode de transport ou transporteur utilisé pour livrer les marchandises au client.
Description Cet attribut indique le service de transport utilisé pour la livraison, par exemple « Transport terrestre », « Fret aérien » ou le nom d’un transporteur. Le mode d’expédition est choisi lors du traitement de la commande en fonction des préférences du client, du coût et du délai de livraison. Cette dimension est essentielle au Dashboard « Performances des modes d’expédition ». L’analyse des temps de cycle entre les activités « Marchandises emballées » et « Marchandises livrées », ventilée par mode d’expédition, permet de repérer les transporteurs les plus rapides et les plus fiables, ainsi que ceux qui entraînent le plus de retards. Ces constats facilitent la planification logistique et le choix des transporteurs. Pourquoi est-ce important ? Permet d’analyser les performances des transporteurs et des options d’expédition afin d’optimiser la logistique en matière de coût, de rapidité et de fiabilité. Où trouver ces données Cette information figure généralement dans l’en-tête de la commande client ou dans les enregistrements associés à son exécution. Consultez la documentation Microsoft Dynamics 365. Exemples FedEx GroundUPS Next Day AirDHL Express
	Nom d’utilisateur UserName	Nom de l’utilisateur qui a exécuté l’activité.
Description Cet attribut identifie l’employé ou l’utilisateur système qui a effectué une tâche, par exemple confirmer une commande ou créer une facture. Il est généralement associé à un ID utilisateur dans Microsoft Dynamics 365. L’analyse des performances par utilisateur permet de repérer les besoins de formation, de reconnaître les personnes les plus performantes et de mieux répartir la charge de travail. Elle est également essentielle pour la conformité et les audits, car elle permet d’établir clairement qui a effectué chaque action. Pourquoi est-ce important ? Permet d’analyser les performances du processus par personne ou par équipe et de repérer les besoins de formation, les déséquilibres de charge de travail et les goulots d’étranglement liés aux ressources. Où trouver ces données Cette valeur est issue de champs d’ID utilisateur tels que « CreatedBy » ou « ModifiedBy » dans différentes tables de transactions. Ces champs sont ensuite associés à la table principale des utilisateurs, par exemple « UserInfo », pour obtenir le nom complet. Exemples Alice JohnsonRobert BrownAdministrateur système
	Numéro d’article ItemNumber	Identifiant unique d’un produit ou d’un service figurant sur la commande client.
Description Le numéro d’article identifie le produit vendu. Une commande pouvant contenir plusieurs produits, cet attribut est généralement associé aux données d’événement au niveau de chaque ligne. L’analyse du processus par produit permet de repérer les problèmes propres à certains produits. Par exemple, certains articles peuvent être associés à des délais d’exécution plus longs, à davantage de reprises ou à des blocages de crédit plus fréquents. Ces constats permettent de cibler les améliorations de la gestion des stocks, du paramétrage des données produit ou des processus d’exécution pour les articles concernés. Pourquoi est-ce important ? Permet d’analyser le processus au niveau des produits et de repérer les articles associés à des retards, à des reprises ou à d’autres inefficacités. Où trouver ces données Cette valeur figure dans la table « SalesLine », dans le champ « ItemId ». Exemples PROD-00123PROD-00548SVC-00045
	Paiement dans les délais OnTimePayment	Indicateur booléen précisant si le paiement a été reçu au plus tard à la date d’échéance.
Description Cet attribut calculé compare l’horodatage de l’activité « Paiement reçu » à « PaymentDueDate ». Il prend la valeur « true » si le paiement a été effectué dans les délais et « false » s’il a été effectué en retard. Cet indicateur est au cœur du calcul du « Taux de paiement dans les délais ». Il permet de répartir rapidement les clients entre ceux qui paient à temps et ceux qui paient en retard. Cette analyse peut orienter les politiques de crédit, les stratégies de recouvrement et la gestion de la relation client, en repérant les clients qui paient régulièrement en retard. Pourquoi est-ce important ? Mesure le respect des conditions de paiement convenues et aide à gérer la trésorerie et à évaluer le risque de crédit. Où trouver ces données Calculé en comparant l’« EventTime » de l’activité « Paiement reçu » à l’attribut « PaymentDueDate ». Formule : (« Horodatage de Paiement reçu » <= PaymentDueDate). Exemples truefalse
	Pays CountryRegion	Pays de l’adresse de livraison du client.
Description Cet attribut indique le pays de destination de l’expédition associée à la commande client. Il est déterminé à partir de l’adresse de livraison du client enregistrée dans Dynamics 365. L’analyse des performances du processus par pays permet de repérer les différences régionales. Les expéditions internationales peuvent nécessiter des étapes supplémentaires, comme le dédouanement, et entraîner des temps de cycle plus longs. Cette analyse aide à comprendre et à optimiser la logistique sur les différents marchés géographiques. Pourquoi est-ce important ? Facilite l’analyse géographique et permet de repérer les goulots d’étranglement régionaux, les problèmes de conformité ou les écarts de performance dans la chaîne d’approvisionnement. Où trouver ces données Cette valeur est issue de l’adresse de livraison du client, associée à la commande. Les informations sur le pays figurent généralement dans la table « LogisticsPostalAddress », reliée à « SalesTable » par le lien vers l’adresse de livraison. Exemples USADEUCANGBR
	Statut de la commande client SalesOrderStatus	Statut de la commande client au moment de l’extraction des données.
Description Cet attribut indique le statut général de la commande client, par exemple « Commande ouverte », « Facturée », « Annulée » ou « Livrée ». Il s’agit d’un statut récapitulatif enregistré dans l’en-tête de la commande. Le journal des activités donne une vue dynamique du processus, tandis que le statut final facilite le filtrage et la segmentation. Les analystes peuvent ainsi isoler les commandes ouvertes pour connaître la charge de travail en cours, ou distinguer les commandes terminées de celles qui ont été annulées afin d’en analyser les motifs. Pourquoi est-ce important ? Donne un aperçu de l’état de la commande et permet de filtrer l’analyse selon les commandes ouvertes, clôturées ou annulées. Cette information est utile pour gérer la charge de travail et analyser les résultats. Où trouver ces données Cette valeur figure dans la table « SalesTable », dans le champ « SalesStatus ». Exemples En reliquatLivréeFacturéeAnnulée

Obligatoire Recommandé Facultatif

Activités du traitement des commandes, de la commande à l’encaissement

Voici les étapes clés du processus et les jalons importants à consigner dans votre journal d’événements pour découvrir et analyser avec précision le traitement de vos commandes.

6 Recommandé 7 Facultatif

	Activité	Description
	Commande client créée	Cet événement correspond à la création initiale de la commande client dans le système, par un représentant commercial ou par un canal automatisé. Il est enregistré explicitement lorsqu’un nouvel enregistrement est créé et sauvegardé dans la table principale des commandes client.
Pourquoi est-ce important ? Cette activité constitue le point de départ commun à tous les cas de commande client. Son horodatage initial permet de calculer le temps de cycle global des commandes et d’analyser le débit du processus. Où trouver ces données Cet événement explicite est enregistré à partir du champ « Created date and time » de l’enregistrement d’en-tête SalesTable dans Microsoft Dynamics 365. Données à recueillir Lire l’horodatage de création dans l’entité SalesTable. Type d’événement explicit
	Commande clôturée	Statut final d’une commande client traitée avec succès : elle a été entièrement expédiée et facturée, et aucune autre transaction n’est attendue. Cette étape marque la fin du processus.
Pourquoi est-ce important ? Cette activité constitue le principal point de fin des cas traités avec succès. Elle est essentielle au calcul des temps de cycle de bout en bout et du débit du processus. Où trouver ces données Cet événement est déduit des champs de statut de SalesTable. Une commande est considérée comme clôturée lorsque le champ « Sales status » indique « Invoiced » et que le statut de ses lignes indique également « Invoiced ». Données à recueillir Déduire l’événement lorsque les champs de statut de SalesTable passent à « Invoiced ». L’horodatage correspond généralement à la date de la dernière transaction associée, par exemple la facturation ou le paiement. Type d’événement inferred
	Commande confirmée	Cette activité correspond à la confirmation officielle de la commande client, qui engage l’entreprise à livrer les marchandises ou les services indiqués. Dans Dynamics 365, il s’agit d’une action explicite de l’utilisateur qui génère un journal de confirmation.
Pourquoi est-ce important ? La confirmation est une étape clé qui marque le début de l’exécution de la commande. Mesurer le délai entre sa création et sa confirmation permet d’évaluer l’efficacité du traitement par les équipes commerciales. Où trouver ces données Cet événement explicite est enregistré à partir de la date de comptabilisation du journal de confirmation de commande client (SalesConfirmJour). L’horodatage peut être associé à SalesTable. Données à recueillir Enregistrer l’horodatage de comptabilisation du journal de confirmation de commande client. Type d’événement explicit
	Facture créée	Cette activité correspond à la création et à la comptabilisation de la facture de vente pour les marchandises ou les services expédiés. Cette transaction financière essentielle enregistre officiellement la dette du client.
Pourquoi est-ce important ? Cette activité marque le début de la phase de règlement financier du processus. Le délai entre l’expédition et la création de la facture est essentiel au KPI « Temps de cycle de création des factures » et influe sur la trésorerie. Où trouver ces données Il s’agit d’une transaction financière explicite. L’événement est enregistré à partir de la date et de l’heure de comptabilisation du journal de facture client (CustInvoiceJour). Données à recueillir Enregistrer l’horodatage de comptabilisation du journal de facture client. Type d’événement explicit
	Marchandises expédiées	Cet événement indique que les marchandises emballées ont été expédiées et ont quitté l’entrepôt. Dans Dynamics 365, cette étape est officialisée par la comptabilisation du bordereau d’expédition.
Pourquoi est-ce important ? Cette étape marque la fin de l’exécution interne de la commande et le début de la livraison. Son horodatage est essentiel pour calculer le taux d’expéditions à temps. Où trouver ces données Cet événement explicite est enregistré à partir de la date et de l’heure de comptabilisation du journal de bordereau d’expédition (CustPackingSlipJour). Données à recueillir Enregistrer l’horodatage de comptabilisation du journal de bordereau d’expédition. Type d’événement explicit
	Paiement reçu	Cette activité indique que le paiement du client a été reçu et affecté à la facture. Elle se produit dans le module Comptes clients et est associée à la facture d’origine.
Pourquoi est-ce important ? Cette étape est essentielle pour analyser le cycle de conversion de trésorerie. Elle permet de mesurer le KPI « Taux de paiements à temps » et de repérer les retards de recouvrement. Où trouver ces données Cet événement explicite provient du module Comptes clients. Il est enregistré à partir de la date de transaction du règlement du paiement client (CustSettlement) qui clôt la transaction de facture (CustTrans). Données à recueillir Enregistrer la date de règlement depuis la table CustSettlement, puis l’associer à la facture et à la commande client. Type d’événement explicit
	Commande annulée	Cet événement correspond à l’annulation d’une commande client avant son expédition et sa facturation complètes. Il s’agit d’une autre issue, qui marque l’échec du processus.
Pourquoi est-ce important ? Le suivi des annulations permet de repérer les causes de pertes de ventes ou d’échecs du processus. Analyser le moment et les raisons des annulations peut aider à améliorer le processus. Où trouver ces données Cet événement est déduit lorsque le champ « Sales status » de SalesTable passe à « Canceled ». L’horodatage correspond au moment où ce changement de statut a été enregistré. Données à recueillir Déduire l’événement lorsque le champ de statut de SalesTable passe à « Canceled ». Type d’événement inferred
	Commande transmise à l’entrepôt	Cette étape marque le moment où la commande client est officiellement transmise à l’entrepôt pour le prélèvement et l’expédition. Elle est distincte dans les environnements qui utilisent le module Warehouse Management (WMS).
Pourquoi est-ce important ? Cette activité marque la transition entre le traitement de la commande et son exécution physique. L’analyse du délai d’attente avant la transmission à l’entrepôt peut révéler des problèmes de planification des ressources ou d’intégration des systèmes. Où trouver ces données Cet événement explicite est enregistré à partir des enregistrements de transmission à l’entrepôt (WHSLoadTable, WHSShipmentTable) associés à la commande client. Données à recueillir Enregistrer l’horodatage de création du chargement ou de l’expédition correspondant. Type d’événement explicit
	Marchandises emballées	Cette activité marque la fin de l’emballage : les articles prélevés sont regroupés et préparés pour l’expédition. Dans D365, cette étape peut coïncider avec la génération d’un bordereau d’expédition.
Pourquoi est-ce important ? Le délai entre le prélèvement et l’emballage peut révéler des goulots d’étranglement aux postes d’emballage. Il s’agit d’une sous-étape importante du temps de cycle global d’exécution de la commande. Où trouver ces données Cet événement peut être enregistré explicitement à la fin de l’emballage des conteneurs dans le module WMS ou déduit de la génération du journal de bordereau d’expédition (CustPackingSlipJour), qui marque souvent la fin de l’emballage. Données à recueillir Déduire l’événement de la fin du travail d’emballage ou de la date de création du journal de bordereau d’expédition. Type d’événement inferred
	Marchandises livrées	Cet événement indique que l’expédition a bien été livrée à l’adresse indiquée par le client. L’information est souvent mise à jour depuis le système d’un transporteur externe ou à la suite d’une confirmation manuelle.
Pourquoi est-ce important ? Cette activité est essentielle pour mesurer le KPI « Respect des dates de livraison » et connaître le temps de cycle réel du point de vue du client. Elle permet également d’évaluer les performances des transporteurs. Où trouver ces données Dans la version standard de D365, cet événement n’est pas suivi explicitement. Il est généralement déduit d’une mise à jour reçue par l’intermédiaire d’une intégration avec un transporteur ou d’une modification manuelle du statut de la commande client ou de l’expédition. Données à recueillir Déduire l’événement d’un flux de données intégré du transporteur ou de la mise à jour manuelle d’un champ de statut. Type d’événement inferred
	Marchandises prélevées	Cette activité correspond à la fin du prélèvement physique de tous les articles de la commande dans leurs emplacements d’entrepôt. Elle est généralement enregistrée lorsque la personne chargée du prélèvement clôt une liste de prélèvement ou un ordre de travail dans le module WMS.
Pourquoi est-ce important ? Le suivi du délai de fin de prélèvement est essentiel pour analyser l’efficacité de l’entrepôt. Les retards à cette étape ont un effet direct sur le délai d’expédition global. Où trouver ces données Cet événement explicite est enregistré dans le module Warehouse Management, à partir de l’horodatage de fin du travail d’entrepôt (WHSWorkTable) associé au prélèvement de la commande client. Données à recueillir Enregistrer l’horodatage auquel le statut « Work » du prélèvement passe à « Closed ». Type d’événement explicit
	Stock réservé	Cet événement indique que le stock nécessaire aux lignes de la commande client a été réservé dans le système, manuellement ou automatiquement. Les articles sont ainsi disponibles pour le prélèvement et l’exécution de la commande.
Pourquoi est-ce important ? Le suivi des réservations de stock permet d’analyser les délais entre la confirmation de la commande et le début des opérations en entrepôt. Cet indicateur est essentiel au KPI « Délai d’allocation du stock ». Où trouver ces données Cet événement peut être déduit de la création ou de la mise à jour des enregistrements de transactions de stock (InventTrans) associés aux lignes de commande, lorsque leur statut indique une réservation, par exemple « On order » ou « Reserved physical ». Données à recueillir Déduire l’événement de l’horodatage auquel les transactions de stock (InventTrans) de la commande sont marquées comme réservées. Type d’événement inferred
	Vérification de crédit effectuée	Cette activité correspond à la fin de la vérification de crédit du client associé à la commande. Il peut s’agir d’un contrôle automatisé par le système ou d’une vérification manuelle, qui entraîne souvent une modification du statut de crédit de la commande.
Pourquoi est-ce important ? L’analyse de la durée et des résultats des vérifications de crédit permet de repérer les goulots d’étranglement dans le processus d’approbation des commandes. Les mises en attente fréquentes ou les délais d’approbation prolongés peuvent retarder considérablement leur exécution. Où trouver ces données Cet événement est généralement déduit des changements de statut liés à la gestion du crédit dans SalesTable, par exemple lorsque le statut passe de « On hold » avec un motif lié au crédit à « Open ». Il peut également être enregistré dans les tables de gestion du crédit si le module avancé est utilisé. Données à recueillir Déduire l’événement de l’historique des changements de statut dans SalesTable ou dans les tables associées aux mises en attente pour motif de crédit. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365

Étapes

Configurez l’exportation vers Azure Data Lake : Dans votre environnement Dynamics 365 Finance and Operations, vérifiez que le module complémentaire « Export to Azure Data Lake » est installé et configuré. Vous devez relier D365 à un abonnement Azure et à un compte Azure Data Lake Storage Gen2 de destination.
Sélectionnez les tables à exporter : Dans Dynamics 365, accédez à l’espace de travail « Export to Data Lake ». Recherchez et ajoutez les tables suivantes à la configuration d’exportation : SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable et CustTable. Activez l’exportation pour toutes les tables sélectionnées.
Configurez Azure Synapse Analytics : Dans le portail Azure, déployez un espace de travail Azure Synapse Analytics. Accordez-lui les autorisations nécessaires, par exemple « Storage Blob Data Contributor », sur le compte Data Lake où sont stockées les données D365.
Créez une base de données SQL serverless : Dans Synapse Studio, accédez au hub « Data ». Créez une base de données SQL serverless pour interroger les données de votre lac à l’aide de T-SQL.
Créez des vues pour les tables D365 : Pour simplifier les requêtes, créez dans votre base de données serverless des vues SQL qui pointent vers les données répliquées des tables D365 dans le lac de données. Vous masquerez ainsi les chemins et formats de fichiers sous-jacents. Exemple : CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
Préparez la requête SQL : Ouvrez un nouveau script SQL dans Synapse Studio et connectez-vous à votre base de données serverless. Copiez dans l’éditeur de script la requête SQL complète fournie dans cette documentation.
Personnalisez les paramètres de la requête : Repérez les espaces réservés au début de la requête. Remplacez '{YourDataAreaId}' par le code société à analyser. Modifiez les espaces réservés '{StartDate}' et '{EndDate}' pour définir la période d’extraction souhaitée.
Exécutez la requête : Lancez le script SQL complet. La requête recueillera les événements de différentes tables et les réunira dans un journal d’événements unique au format normalisé.
Vérifiez et exportez les résultats : Une fois la requête terminée, vérifiez les résultats dans le volet correspondant de Synapse Studio pour vous assurer qu’ils sont complets et correctement formatés. Utilisez la fonction d’exportation intégrée pour enregistrer les résultats dans un fichier CSV.
Préparez l’importation : Ouvrez le fichier CSV exporté et vérifiez qu’il est encodé en UTF-8. Assurez-vous que les en-têtes de colonnes correspondent exactement aux attributs requis, par exemple SalesOrderNumber, ActivityName, EventTime, etc.
Importez les données dans ProcessMind : Importez le fichier CSV final validé dans votre projet ProcessMind pour l’analyser et le visualiser.

Configuration

Prérequis : Cette méthode nécessite un abonnement Azure actif et le module « Export to Azure Data Lake » configuré pour votre instance Dynamics 365 F&O. Vous devez disposer des autorisations appropriées dans Azure (pour gérer Synapse et Storage) et dans D365 (pour configurer les exportations de données).
Modules D365 requis : Pour recueillir tous les événements, notamment ceux liés à l’entrepôt, vous devez utiliser le module Warehouse Management (WMS). Les événements principaux dépendent des modules Sales and Marketing et Accounts Receivable.
Sélection des tables : Il est essentiel d’activer l’exportation de toutes les tables référencées dans la requête : SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable et CustTable. Toute table manquante entraînera l’absence des activités correspondantes.
Filtrage par période : La requête utilise les paramètres {StartDate} et {EndDate} pour filtrer les données selon une période. Pour les premières extractions, il est recommandé de limiter la période, par exemple à 3 à 6 mois, afin de maîtriser la durée d’exécution des requêtes.
Filtrage par société (DataAreaId) : Vous devez configurer l’espace réservé '{YourDataAreaId}' pour cibler une entité juridique précise de votre environnement D365. La requête n’est pas conçue pour analyser plusieurs sociétés en une seule exécution.
Performances : Les performances des requêtes sur un pool SQL serverless peuvent varier avec les très grands volumes de données. Envisagez de programmer l’extraction en dehors des heures de pointe. Si vous effectuez des extractions fréquentes, vous pouvez matérialiser le journal d’événements final dans une nouvelle table du lac de données afin d’améliorer les performances des traitements ultérieurs.

Exemple de requête 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'

Étapes

Prérequis et configuration : Vérifiez que Python 3.6 ou une version ultérieure est installé. Installez les bibliothèques Python nécessaires en exécutant la commande suivante dans votre terminal : pip install pandas requests msal.
Inscrivez une application dans Azure AD : Dans le portail Azure, inscrivez une nouvelle application dans Azure Active Directory. Elle servira à l’authentification auprès de l’API Dynamics 365. Notez l’ID d’application (client) et l’ID de répertoire (locataire).
Créez un secret client : Dans l’application Azure AD que vous venez d’inscrire, créez un secret client sous « Certificates & secrets ». Copiez immédiatement sa valeur, car elle ne sera plus affichée. Il s’agit de votre CLIENT_SECRET.
Accordez les autorisations d’API : Dans les paramètres de l’application Azure AD, accédez à « API permissions ». Ajoutez une autorisation pour « Dynamics ERP » ou « Dynamics 365 for Finance and Operations ». Sélectionnez « Delegated permissions » et accordez user_impersonation. Ajoutez ensuite la même autorisation une seconde fois, sélectionnez « Application permissions » et accordez Financials.ReadWrite.All ou une autorisation en lecture seule plus restreinte, si elle est disponible et suffisante. Accordez le consentement administrateur pour ces autorisations.
Créez un utilisateur d’application dans Dynamics 365 : Dans votre environnement Dynamics 365, accédez à « System administration » > « Users » > « Users ». Créez un utilisateur et associez-le à l’ID d’application de votre inscription Azure AD. Attribuez-lui un rôle de sécurité, par exemple « System administrator » (accès complet) ou un rôle personnalisé donnant accès en lecture aux entités de données requises (SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders, SalesInvoiceHeadersV2, etc.).
Configurez le script Python : Ouvrez le script Python fourni dans un éditeur. Dans la section de configuration en haut du fichier, remplacez les valeurs fictives de D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE et END_DATE par les informations propres à votre environnement.
Définissez les associations d’entités (facultatif) : Vérifiez les noms d’entités et de champs utilisés dans le script. Si votre organisation utilise des entités ou des champs personnalisés pour suivre certaines activités, vous devrez peut-être adapter les requêtes OData du script.
Exécutez le script d’extraction : Lancez le script depuis la ligne de commande avec la commande python your_script_name.py. Le script s’authentifiera, interrogera l’API OData de Dynamics 365 pour chaque activité et traitera les données. L’avancement s’affichera dans la console.
Vérifiez le fichier de sortie : Une fois l’exécution terminée, le script génère dans le même répertoire un fichier CSV nommé d365_order_to_cash_event_log.csv. Ouvrez-le pour vérifier que le journal d’événements extrait est exact et complet.
Importez les données dans ProcessMind : Le fichier CSV généré respecte le schéma requis et peut être importé directement dans ProcessMind pour analyser le processus.

Configuration

D365_URL : URL de base de votre environnement Dynamics 365 Finance and Operations. Elle doit ressembler à https://[your-d365-environment-name].operations.dynamics.com.
TENANT_ID : ID de répertoire (locataire) de votre instance Azure Active Directory. Vous le trouverez sur la page de présentation de l’inscription de votre application Azure AD.
CLIENT_ID : ID d’application (client) de l’application inscrite dans Azure AD.
CLIENT_SECRET : Valeur du secret client créé pour l’application Azure AD.
COMPANY_FILTER : Indique l’entité juridique Dynamics 365 (par exemple, 'USMF') dont les données doivent être extraites. Ce filtre est obligatoire pour interroger les données de la bonne société.
START_DATE / END_DATE : Définissent la période d’extraction au format 'YYYY-MM-DD'. Pour une première analyse, une période de 3 à 6 mois permet de trouver un équilibre entre le volume de données et la qualité de l’analyse. Notez qu’une période étendue peut augmenter considérablement la durée de l’extraction.
Prérequis : Vous devez pouvoir accéder à Azure AD pour inscrire une application et lui accorder des autorisations. Vous devez également disposer d’un compte Dynamics 365 autorisé à créer un utilisateur d’application et à lui attribuer des rôles de sécurité. Le rôle attribué doit donner un accès en lecture à toutes les entités interrogées par le script.

Exemple de requête 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()

Prêt à commencer ?

Préparez vos données à l’aide de ce modèle, puis importez-les dans notre plateforme pour obtenir des analyses utiles et améliorer le traitement de vos commandes. Commencez dès aujourd’hui !

Retour au guide d’amélioration

Télécharger le modèle

Optimisez dès maintenant le traitement des commandes, de la commande à l’encaissement

Repérez les inefficacités et réduisez le temps de cycle de 30 % pour accélérer l’exécution des commandes.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données pour le traitement des commandes, de la commande à l’encaissement

Votre modèle de données pour le traitement des commandes, de la commande à l’encaissement

Attributs du traitement des commandes, de la commande à l’encaissement

Activités du traitement des commandes, de la commande à l’encaissement

Guides d’extraction

Requête SQL dans Azure Data Lake avec Synapse Analytics

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API Web OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le traitement des commandes, de la commande à l’encaissement

Votre modèle de données pour le traitement des commandes, de la commande à l’encaissement

Votre modèle de données pour le traitement des commandes, de la commande à l’encaissement

Attributs du traitement des commandes, de la commande à l’encaissement

Activités du traitement des commandes, de la commande à l’encaissement

Guides d’extraction

Requête SQL dans Azure Data Lake avec Synapse Analytics

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API Web OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le traitement des commandes, de la commande à l’encaissement

Prêt à commencer ?