Votre modèle de données Commande à l'encaissement : Traitement des facturess factures fournisseurs factures fournisseurs commandes de vente
Votre modèle de données Commande à l'encaissement : Traitement des facturess factures fournisseurs factures fournisseurs commandes de vente
- Attributs recommandés pour une analyse détaillée
- Activités clés du processus à suivre
- Directives spécifiques d'extraction de données pour Microsoft Dynamics 365
De la commande au paiement - Attributs de Traitement des facturess factures fournisseurs factures fournisseurs commandes clients
| Nom | Descriptionn | ||
|---|---|---|---|
|
Activité
ActivityName
|
Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit à un moment donné du processus de commande client. | ||
|
Descriptionn
Cet attribut représente une étape ou un événement distinct dans le cycle de vie de la commande client, tel que 'Commande client créée', 'Marchandises expédiées' ou 'Paiement reçu'. La séquence de ces activités pour une commande client donnée forme le flux de processus. L'analyse de la séquence, de la fréquence et des transitions entre les activités est l'essence du Process Mining. Elle aide à visualiser la cartographie des processus, à identifier les variantes de processus courantes et rares, à détecter les points de blocage et à cibler les zones de retouche ou de non-conformité. Cet attribut est indispensable pour comprendre ce qui se passe réellement dans le processus.
Pourquoi est-ce important ? :
Il définit les étapes du processus, rendant possible la construction et la visualisation du flux de processus, ce qui est l'objectif principal du Process Mining.
Source des données :
Cet attribut est dérivé conceptuellement en mappant des événements système ou des changements de statut spécifiques dans des tables comme 'SalesTable' et des 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
|
L'identifiant unique pour chaque commande de vente, servant d'identifiant de dossier principal pour le processus. | ||
|
Descriptionn
Le 'Numéro de commande de vente' est un code alphanumérique unique attribué à chaque commande client dans Microsoft Dynamics 365. Il fonctionne comme l'ID de cas principal, reliant toutes les activités et événements connexes de la création à la clôture. En process mining, cet attribut est indispensable pour reconstituer le parcours complet de chaque commande de vente individuelle. Il permet aux analystes de retracer la séquence complète des activités, de mesurer les durées des cas et d'analyser les variations pour chaque commande spécifique, constituant ainsi la base de l'analyse complète du processus.
Pourquoi est-ce important ? :
Cet identifiant est impératif pour corréler tous les événements liés, pour une analyse complète complet du cycle de vie de chaque commande client.
Source des données :
Situé dans la table 'SalesTable', champ 'SalesId'.
Exemples
SO-00102345SO-00102346SO-00102347
|
|||
|
Heure de début
EventTime
|
La date et l'heure précises auxquelles une activité ou un événement spécifique s'est produit. | ||
|
Descriptionn
L'horodatage de l'événement, ou horodatage, enregistre le moment exact où une activité a eu lieu. Chaque activité dans le journal d'événements est associée à un horodatage, créant un enregistrement chronologique du processus pour chaque cas. Cet attribut est indispensable pour toutes les analyses temporelles en Process Mining. Il est utilisé pour calculer les temps de cycle entre les activités, mesurer la durée totale d'un cas, analyser les temps d'attente et identifier les points de blocage où le processus est retardé. Il permet également un suivi de la performance au fil du temps, comme le suivi du débit par jour, semaine ou mois.
Pourquoi est-ce important ? :
Ce horodatage est indispensable pour le calcul de toutes les métriques basées sur la durée, telles que les temps de cycles et les points de blocage, et pour l'ordonnancement chronologique des événements.
Source des données :
Cela est dérivé de divers champs de date/heure associés à des transactions spécifiques, tels que "SalesTable.CreatedDateTime" pour la création de commande ou les dates de validation du journal de paiement pour les paiements.
Exemples
2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L'horodatage indiquant la dernière fois que les données ont été actualisées ou extraites du système source. | ||
|
Descriptionn
Cet attribut consigne la date et l'heure de la dernière extraction de données de Microsoft Dynamics 365. Il offre une transparence sur la la réactualisation des données analysées. Pour toute analyse de processus, comprendre la réactualisation des données est indispensable pour prendre des décisions éclairées. Ce horodatage aide les utilisateurs à faire confiance aux données en indiquant précisément quand elles ont été mises à jour pour la dernière fois, garantissant que les conclusions sont basées sur des informations actuelles.
Pourquoi est-ce important ? :
Il garantit que les utilisateurs sont conscients de la la réactualisation des données, ce qui est indispensable pour la pertinence et la précision de l'analyse de Process Mining.
Source des données :
Cela est généré au moment de l'extraction de données et ajouté à chaque enregistrement pendant le processus d'ingestion de données.
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. | ||
|
Descriptionn
Cet attribut spécifie l'application source où les données d'événement ont été enregistrées. Dans ce contexte, il s'agira typiquement de 'Microsoft Dynamics 365'. Bien que cela puisse sembler redondant dans une analyse mono-système, cela devient crucial lors de la fusion de données provenant de plusieurs systèmes, tels qu'un CRM distinct ou un système de gestion d'entrepôt. Cela assure la traçabilité des données et aide à résoudre les problèmes d'extraction de données en identifiant l'origine des enregistrements.
Pourquoi est-ce important ? :
Il fournit un contexte essentiel sur l'origine des données, en particulier lors de l'intégration de données provenant de multiples systèmes, assurant une traçabilité des données claire.
Source des données :
Il s'agit d'une valeur statique, généralement ajoutée pendant le processus de transformation des données pour étiqueter l'origine du jeu de données.
Exemples
Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Ventes
|
|||
|
Canal de vente
SalesChannel
|
Le canal par lequel la commande client a été reçue, tel que Web, Ventes directes ou Partenaire. | ||
|
Descriptionn
Le 'Canal de vente' indique l'origine de la commande client. Il peut s'agir d'un site e-commerce, d'une équipe de vente directe, d'un magasin de détail, d'un centre d'appels ou d'un réseau de partenaires. Cette dimension est souvent configurée en fonction des besoins métiers dans Dynamics 365. L'analyse du processus par canal de vente aide à découvrir les différences de performance entre les canaux. Par exemple, les commandes web pourraient être traitées plus rapidement et plus automatiquement que les commandes prises par téléphone. Cette information permet une optimisation des processus spécifiques aux canaux et une allocation des ressources, alimentant des dashboards tels que 'Valeur des commandes de vente par segment'.
Pourquoi est-ce important ? :
Permet de comparer les performances entre différents canaux de vente, révélant ainsi les inefficacités ou les meilleures pratiques liées à la manière dont les commandes sont initiées.
Source des données :
Ces informationsns sont généralement stockées dans l'en-tête de la commande client. Veuillez consulter la documentation de Microsoft Dynamics 365 pour le champ spécifique.
Exemples
WebDirectPartenaireCommerce de détail
|
|||
|
Date de livraison confirmée
ConfirmedDeliveryDate
|
La date de livraison que l'entreprise a confirmée et s'est engagée à respecter envers le client. | ||
|
Descriptionn
La 'Date de livraison confirmée' est la date que l'organisation vendeuse promet au client pour la livraison des marchandises. Cette date est définie après que les vérifications internes, telles que la disponibilité des stocks et les calendriers de production, sont terminées. Cet attribut est indispensable pour calculer le KPI 'Taux de résolutionpect de la date de livraison' d'un point de vue d'engagement opérationnel. Il fournit une référence interne plus réaliste pour la paiement à temps que la demande initiale du client. L'analyse des écarts par rapport à cette date aide à identifier les défaillances des processus internes en logistique et en exécution.
Pourquoi est-ce important ? :
Représente l'engagement de l'entreprise envers le client, ce qui en fait un indicateur interne essentiel pour mesurer la fiabilité de l'exécution et la performance opérationnelle.
Source des données :
Situé dans les données de ligne de commande client, souvent dans la table 'SalesLine' avec un nom de champ comme 'ConfirmedDlv'.
Exemples
2023-05-122023-06-012023-05-28
|
|||
|
Date de livraison demandée
RequestedDeliveryDate
|
La date de livraison de la commande telle que demandée par le client. | ||
|
Descriptionn
Cet attribut stocke la date à laquelle le client a initialement demandé à recevoir ses marchandises. Cette date est enregistrée au moment de la création de la commande et sert de référence pour mesurer la performance de livraison du point de vue du client. Cette date est une contribution essentielle pour le tableau de bord "Respect des Délais de Livraison". La comparaison de la 'RequestedDeliveryDate' avec la 'ConfirmedDeliveryDate' et la date réelle de 'Goods Delivered' révèle dans quelle mesure l'organisation répond aux attentes des clients. Des écarts importants peuvent indiquer des problèmes de planification, d'inventaire ou de logistique.
Pourquoi est-ce important ? :
Sert d'attente du client en matière de livraison, fournissant une référence clé pour mesurer la satisfaction client et la performance de paiement à temps.
Source des données :
Situé dans la table 'SalesTable', communément nommé 'DeliveryDate' ou une variante similaire.
Exemples
2023-05-102023-06-012023-05-25
|
|||
|
Nom du client
CustomerName
|
Le nom du client ayant passé la commande de vente. | ||
|
Descriptionn
Cet attribut contient la raison sociale du client associée à la commande client. Il est dérivé en liant le numéro de compte client de la commande aux données de base client principales. L'analyse du processus par client est clée pour comprendre les comportements spécifiques des clients et les niveaux de service. Elle permet d'identifier quels clients subissent le plus de retards, quels sont ceux qui présentent les taux de retouches les plus élevés, ou ceux qui suivent des chemins de processus non standard. Ceci est indispensable à améliorer la satisfaction client et gérer efficacement les comptes clés.
Pourquoi est-ce important ? :
Permet une analyse orientée client.ur identifier les schémas, les retards ou les problèmes spécifiques à certains clients, impactant directement la satisfaction client.
Source des données :
Recherché dans la table 'CustTable' en utilisant le champ 'CustAccount' de la table 'SalesTable'.
Exemples
Contoso LtdAdatum CorporationFabrikam Inc.
|
|||
|
Valeur de commande
OrderValue
|
La valeur monétaire totale de la commande de vente. | ||
|
Descriptionn
Cet attribut représente le montant financier total de la commande client, incluant tous les articles, taxes et frais. C'est un indicateur financier clé associé à chaque cas. La Valeur de la commande est indispensable pour l'analyse de processus basée sur la valeur. Elle permet de segmenter le processus pour voir si les commandes de grande valeur sont traitées différemment ou subissent plus de retards que les commandes de faible valeur. Cela aide à prioriser les efforts d'amélioration des processus sur les cas financièrement les plus significatifs et alimente des dashboards comme "Valeur des commandes clients par segment".
Pourquoi est-ce important ? :
Permet une segmentation financière du processus, ce qui aide à prioriser les améliorations pour les commandes de grande valeur et à comprendre les implications financières des écarts de processus.
Source des données :
Situé dans les données d'en-tête de commande client. Consultez la documentation de Microsoft Dynamics 365 pour la table et le champ spécifiques, souvent calculé à partir des montants des lignes de vente.
Exemples
5250.7512300.00899.50
|
|||
|
Date d'échéance du paiement
PaymentDueDate
|
La date à laquelle le client est tenu d'effectuer le paiement de la facture. | ||
|
Descriptionn
La 'Date d'échéance du paiement' est calculée en fonction de la date de facture et des conditions de paiement convenues avec le client. Cette date est enregistrée sur la facture client. Cet attribut est indispensable pour l'analyse de la 'Conformité aux dates d'échéance de paiement' et le KPI 'Taux de paiement ponctuel'. En comparant la 'PaymentDueDate' avec la date réelle de 'Paiement reçu', l'entreprise peut identifier les retards de paiement, analyser le comportement de paiement par segment de clientèle et prendre des mesures proactives pour améliorer la trésorerie et réduire le nombre de jours de créances client (DSO).
Pourquoi est-ce important ? :
Il s'agit du benchmark pour mesurer la performance des paiements, ce qui est indispensable pour analyser les flux de trésorerie et gérer efficacement les comptes clients.
Source des données :
Situé dans la table 'CustInvoiceJour', champ 'DueDate'.
Exemples
2023-05-302023-06-152023-06-30
|
|||
|
Est un reprises
IsRework
|
Un indicateur booléen signalant si une commande client a fait l'objet d'un reprises, par exemple une activité répétée. | ||
|
Descriptionn
Cet attribut calculé identifie les dossiers ayant dévié du flux standard (« happy path »). Le reprises est détecté par l'identification de séquences d'activités montrant qu'une étape a été répétée, comme une commande annulée puis reconfirmée, ou des articles prélevés puis remis en stock. Identifier les cas de reprises est indispensable pour le KPI « Taux de reprises des commandes client ». Cela permet aux analystes d'isoler et d'analyser rapidement les flux inefficaces pour en comprendre les causes profondes, qu'il s'agisse d'erreurs de saisie, de problèmes de crédit ou de gestion de stock. La réduction du reprises est au cœur de nombreux projets d'optimisation des processus.
Pourquoi est-ce important ? :
Aide à quantifier l'inefficacité des processus en signalant les cas qui ont nécessité des étapes répétées, permettant une analyse ciblée pour réduire le gaspillage et les retards.
Source des données :
Cela est calculé par l'outil de Process Mining en analysant la séquence d'activités pour chaque cas. Par exemple, la détection d'un modèle comme (A -> B -> C -> B) marquerait le cas comme reprises.
Exemples
truefaux
|
|||
|
Heure de fin
EndTime
|
La date et l'heure précises auxquelles une activité a été achevée. | ||
|
Descriptionn
L'horodatage 'Heure de fin' enregistre le moment où une activité se termine. Lorsqu'il est disponibleble, il offre une mesure plus précise de la durée d'une activité par rapport à l'inférence à partir de l'heure de début de l'activité suivante. En analyse, disposer à la fois d'une heure de début et d'une heure de fin permet le calcul précis du 'Temps de traitement' pour chaque activité, le distinguant du 'Temps d'attente' entre les activités. Ceci est très utile pour identifier quelles tâches spécifiques sont chronophages et quelles étapes de processus impliquent de longs retards.
Pourquoi est-ce important ? :
Permet le calcul précis des temps de traitement d'activités individuelles, distinguant le temps de travail actif du temps d'attente inactif.
Source des données :
Comme l'heure de début, ceci est dérivé de divers champs de date/heure. Il peut s'agir d'un champ 'ModifiedDateTime' ou d'un horodatage de mise à jour de statut spécifique dans des tables comme 'SalesTable' ou 'WHSLoadTable'.
Exemples
2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
|
|||
|
Livraison à temps
OnTimeDelivery
|
Un indicateur booléen signalant si les marchandises ont été livrées à la date de livraison confirmée ou avant. | ||
|
Descriptionn
Cet attribut calculé compare l'horodatage de l'activité 'Marchandises livrées' avec la 'ConfirmedDeliveryDate' pour chaque commande client. Il est défini à 'vrai' si la livraison a été effectuée à l'heure ou en avance, et à 'faux' si elle a été en retard. Cet indicateur est la base du calcul du KPI "Taux de résolutionpect des délais de livraison". Il simplifie l'analyse en permettant un filtrage et une agrégation faciles des commandes à l'heure par rapport aux commandes en retard. Cela aide à identifier rapidement les facteurs corrélés aux livraisons tardives, tels que des produits spécifiques, des clients, des régions ou des méthodes d'expédition.
Pourquoi est-ce important ? :
Mesure directement la performance de l'exécution par rapport à l'engagement, ce qui est impératif pour surveiller la satisfaction client et la fiabilité de la chaîne d'approvisionnement.
Source des données :
Calculé en comparant le (EventTime) de l'activité 'Marchandises livrées' avec l'attribut 'ConfirmedDeliveryDate'. Formule : ('Marchandises livrées' Horodatage <= ConfirmedDeliveryDate).
Exemples
truefaux
|
|||
|
Méthode d'expédition
ShippingMethod
|
La méthode ou le transporteur utilisé pour expédier les marchandises au client. | ||
|
Descriptionn
Cet attribut spécifie le service de transport utilisé pour la livraison, tel que 'Expédition terrestre', 'Fret aérien', ou le nom d'un transporteur spécifique. Il est sélectionné lors du traitement de la commande en fonction de la préférence du client, du coût et de la vitesse de livraison. Pour le tableau de bord "Performance des méthodes d'expédition", cette dimension est indispensablele. L'analyse des temps de cycle, de 'Marchandises emballées' à 'Marchandises livrées', ventilée par méthode d'expédition, aide à identifier quels transporteurs sont plus rapides, plus fiables ou plus sujets aux retards. Cette perspective permet une meilleure planification logistique et une sélection optimisée des transporteurs.
Pourquoi est-ce important ? :
Permet l'analyse des performances de différents transporteurs et options d'expédition, aidant à optimiser la logistique en termes de coût, de rapidité et de fiabilité.
Source des données :
Ces informationsns sont généralement stockées dans l'en-tête de la commande client ou dans les enregistrements de traitement associés. Veuillez consulter la documentation de Microsoft Dynamics 365.
Exemples
FedEx GroundUPS Next Day AirDHL Express
|
|||
|
Nom d'utilisateur
UserName
|
Le nom de l'utilisateur qui a exécuté l'activité. | ||
|
Descriptionn
Cet attribut identifie l'employé ou l'utilisateur système spécifique responsable de l'exécution d'une tâche donnée, comme la confirmation d'une commande ou la création d'une facture. Il est généralement lié à un ID utilisateur dans Microsoft Dynamics 365. L'analyse de la performance par utilisateur permet d'identifier les besoins en formation, de reconnaître les meilleurs collaborateurs les plus performants et d'assurer une répartition adéquate de la charge de travail. Elle est également essentielle à des fins de conformité et d'audit, permettant une responsabilité claire pour chaque action entreprise dans le processus.
Pourquoi est-ce important ? :
Il permet l'analyse de la performance des processus par individu ou par équipe, permettant d'identifier les opportunités de formation, les déséquilibres de charge de travail et les points de blocage liés aux ressources.
Source des données :
Dérivé des champs d'ID utilisateur comme 'CreatedBy' ou 'ModifiedBy' sur diverses tables de transactions, qui sont ensuite joints à la table utilisateur principale (ex : 'UserInfo') pour obtenir le nom complet.
Exemples
Alice JohnsonRobert BrownAdministrateur système
|
|||
|
Numéro d'article
ItemNumber
|
L'identifiant unique d'un produit ou service sur la commande de vente. | ||
|
Descriptionn
Le 'Numéro d'article' identifie le produit spécifique vendu. Comme une commande de vente peut contenir plusieurs produits, cet attribut est généralement associé aux données d'événements au niveau de la ligne d'article. L'analyse du processus par produit aide à découvrir des problèmes spécifiques aux produits. Par exemple, certains produits peuvent être associés à des délais d'exécution plus longs, des taux de retouches plus élevés ou des maintiens de crédit plus fréquents. Cela permet des améliorations ciblées dans la gestion des stocks, la configuration des données produit ou les processus d'exécution pour des articles spécifiques.
Pourquoi est-ce important ? :
Permet une analyse au niveau du produit, ce qui révèle si certains articles sont liés à des retards de processus, à des retouches ou à d'autres inefficacités.
Source des données :
Situé dans la table 'SalesLine', champ 'ItemId'.
Exemples
PROD-00123PROD-00548SVC-00045
|
|||
|
Paiement à temps
OnTimePayment
|
Un indicateur booléen signalant si le paiement a été reçu à la date d'échéance ou avant. | ||
|
Descriptionn
Cet attribut calculé compare l'horodatage de l'activité 'Paiement reçu' avec la 'PaymentDueDate'. Il est défini à 'vrai' si le paiement a été effectué à l'heure et à 'faux' s'il a été en retard. Cet indicateur est le composant principal du KPI "Taux de paiement à l'heure". Il permet une segmentation rapide des clients en payeurs 'à l'heure' et 'en retard'. Cette analyse peut éclairer les politiques de crédit, les stratégies de recouvrement et la gestion de la relation client en identifiant les clients qui paient systématiquement en retard.
Pourquoi est-ce important ? :
Mesure le comportement de paiement des clients par rapport aux conditions convenues, ce qui est indispensable pour gérer la trésorerie et évaluer le risque de crédit.
Source des données :
Calculé en comparant le (EventTime) de l'activité 'Paiement reçu' avec l'attribut 'PaymentDueDate'. Formule : ('Paiement reçu' Horodatage <= PaymentDueDate).
Exemples
truefaux
|
|||
|
Pays
CountryRegion
|
Le pays de l'adresse de livraison du client. | ||
|
Descriptionn
Cet attribut indique le pays de destination de l'expédition de la commande client. Il est dérivé des informations d'adresse de livraison du client stockées dans Dynamics 365. L'analyse de la performance du processus par pays est importante pour identifier les variations régionales. Les expéditions internationales peuvent impliquer des étapes supplémentaires comme le dédouanement, entraînant des temps de cycle plus longs. Cette analyse aide à comprendre et à optimiser la logistique pour différents marchés géographiques.
Pourquoi est-ce important ? :
Facilite l'analyse géographique, permettant d'identifier les points de blocage régionaux, les problèmes de conformité ou les variations de performance dans la chaîne d'approvisionnement.
Source des données :
Dérivé de l'adresse de livraison du client, qui est liée à la commande client. Les informations de pays se trouvent généralement dans la table 'LogisticsPostalAddress', jointes via le lien d'adresse de livraison sur la 'SalesTable'.
Exemples
États-UnisDEUCANGBR
|
|||
|
Statut de la commande client
SalesOrderStatus
|
Le statut actuel de la commande de vente au moment de l'extraction des données. | ||
|
Descriptionn
Cet attribut reflète le statut global de la commande client, tel que 'Commande ouverte', 'Facturée', 'Annulée' ou 'Livrée'. Il s'agit d'un statut récapitulatif maintenu sur l'en-tête de la commande client. Alors que le journal d'activités offre une vue dynamique du processus, le statut final est utile pour le filtrage et la segmentation. Il permet aux analystes d'isoler facilement toutes les commandes ouvertes pour avoir une vue de la charge de travail actuelle, ou de séparer les commandes traitées avec succès de celles annulées pour analyser les raisons de l'annulation.
Pourquoi est-ce important ? :
Offre un aperçu instantané de l'état de la commande, permettant de filtrer l'analyse par commandes ouvertes, clôturées ou annulées, ce qui est utile pour la gestion de la charge de travail et l'analyse des résultats.
Source des données :
Situé dans la table 'SalesTable', champ 'SalesStatus'.
Exemples
Commande en souffranceLivréFacturéAnnulé
|
|||
De la commande au paiement - Activités de Traitement des facturess factures fournisseurs factures fournisseurs commandes clients
| Activité | Descriptionn | ||
|---|---|---|---|
|
Commande client créée
|
Cet événement marque la création initiale de la commande client dans le système par un représentant commercial ou via un canal automatisé. Il est capturé explicitement lorsqu'un nouvel enregistrement est créé et sauvegardé dans la table principale des commandes clients. | ||
|
Pourquoi est-ce important ? :
Cette activité est le point de départ universel pour tous les cas de commandes clients. Elle fournit l'horodatage initial nécessaire au calcul du temps de cycle global de la commande client et à l'analyse du débit.
Source des données :
Il s'agit d'un événement explicite capturé à partir du champ "Date et heure de création" sur l'enregistrement d'en-tête SalesTable dans Microsoft Dynamics 365.
Capture
Lit l'horodatage de création de l'entité SalesTable.
Type d'événement
explicit
|
|||
|
Commande Clôturée
|
Le statut final d'une commande de vente traitée avec succès, indiquant qu'elle a été entièrement expédiée, facturée et qu'aucune autre transaction n'est attendue. Cela marque l'achèvement réussi du processus. | ||
|
Pourquoi est-ce important ? :
Cette activité constitue le point d'arrivée principal pour les cas traités avec succès. Elle est indispensablele pour le calcul des temps de cycle complet et du débit.
Source des données :
Cela est déduit des champs de statut sur la SalesTable. Une commande est considérée comme clôturée lorsque le "Statut de vente" est "Facturé" et que les statuts des lignes sont également "Facturés".
Capture
Déduire des champs de statut de la SalesTable qui passent à 'Facturé'. L'horodatage est généralement la dernière date de transaction associée, comme la facturation ou le paiement.
Type d'événement
inferred
|
|||
|
Commande Confirmée
|
Cette activité signifie la confirmation formelle de la commande client, engageant la livraison des biens ou services spécifiés. Dans Dynamics 365, il s'agit d'une action utilisateur explicite qui génère un journal de confirmation. | ||
|
Pourquoi est-ce important ? :
La confirmation est une étape clé qui lance officiellement le processus d'exécution. Mesurer le temps entre la création et la confirmation révèle l'efficacité du traitement en front-office.
Source des données :
Il s'agit d'un événement explicite capturé à partir de la date de validation du journal de "Confirmation de Commande Client" (SalesConfirmJour). L'horodatage peut être lié à la SalesTable.
Capture
Capture l'horodatage de publication du journal de confirmation de commande client.
Type d'événement
explicit
|
|||
|
Facture créée
|
Cela représente la génération et la validation de la facture client pour les biens ou services expédiés. Il s'agit d'une transaction financière essentielle qui enregistre formellement 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 indispensable pour le KPI "Temps de Cycle de Génération de Facture" et a un impact sur les flux de trésorerie.
Source des données :
Il s'agit d'une transaction financière explicite. L'événement est capturé à partir de la date et de l'heure de validation du journal de facturation client (CustInvoiceJour).
Capture
Capture l'horodatage de publication du journal des factures de vente.
Type d'événement
explicit
|
|||
|
Marchandises expédiées
|
Cet événement signifie que les marchandises emballées pour la commande ont été expédiées et ont quitté l'entrepôt. Dans Dynamics 365, cela est formalisé par la validation du Packing Slip. | ||
|
Pourquoi est-ce important ? :
Il s'agit d'un jalon critique marquant la fin du processus d'exécution interne et le début de la phase de livraison. C'est un horodatage clé pour le calcul des performances d'expédition à temps.
Source des données :
Il s'agit d'un événement très clair et explicite, capturé à partir de la date et de l'heure de validation du journal de Packing Slip (CustPackingSlipJour).
Capture
Capture l'horodatage de publication du journal des bordereaux d'expédition.
Type d'événement
explicit
|
|||
|
paiement reçu
|
Cette activité indique que le paiement du client pour la facture a été reçu et appliqué. Cet événement se produit dans le module des comptes clients et est lié à la facture d'origine. | ||
|
Pourquoi est-ce important ? :
Il s'agit d'un jalon critique pour l'analyse du cycle de conversion de la trésorerie. Il est indispensable pour mesurer le KPI du "Taux de paiement ponctuel" et identifier les retards de recouvrement des paiements.
Source des données :
Il s'agit d'un événement explicite du module Comptes Clients. Il est capturé à partir de la date de transaction du règlement de paiement client (CustSettlement) qui clôture la transaction de facture (CustTrans).
Capture
Capture la date de règlement de la table CustSettlement, en la rattachant à la facture et à la commande client.
Type d'événement
explicit
|
|||
|
Commande Annulée
|
Cet événement représente l'annulation d'une commande client avant qu'elle ne soit entièrement expédiée et facturée. Il s'agit d'une fin de processus alternative et infructueuse. | ||
|
Pourquoi est-ce important ? :
Le suivi des annulations permet d'identifier les raisons des ventes perdues ou des échecs de processus. L'analyse du moment et des raisons pour lesquelles les commandes sont annulées peut mener à des améliorations de processus.
Source des données :
Cela est déduit du champ "Statut de vente" sur la SalesTable passant à "Annulé". L'horodatage correspondrait au moment où ce changement de statut a été enregistré.
Capture
Déduire du champ de statut de la SalesTable qui passe à 'Annulé'.
Type d'événement
inferred
|
|||
|
Libéré vers l'entrepôt
|
Marque le moment où la commande client est officiellement transmise à l'entrepôt pour les opérations de prélèvement.lèvement et d'expédition. C'est une étape distincte dans les environnements utilisant le module Gestion d'entrepôt (WMS). | ||
|
Pourquoi est-ce important ? :
Cette activité sépare le traitement des commandes de l'exécution physique. L'analyse du temps d'attente d'une commande avant sa libération peut révéler des problèmes de planification des ressources ou d'intégration système.
Source des données :
Il s'agit d'un événement explicite capturé à partir des enregistrements de sortie d'entrepôt (WHSLoadTable, WHSShipmentTable) associés à la commande client.
Capture
Capture l'horodatage de création du chargement d'entrepôt ou de l'expédition correspondant.
Type d'événement
explicit
|
|||
|
Marchandises emballées
|
Cette activité marque l'achèvement du processus d'emballage, où les articles préparés sont consolidés et prêts à être expédiés. Dans D365, cela peut coïncider avec la génération d'un bon de livraison. | ||
|
Pourquoi est-ce important ? :
Le temps entre le prélèvement et l'emballage peut révéler des points de blocage dans les stations d'emballage. C'est un sous-processus clé au sein du temps de cycle global d'exécution.
Source des données :
Il peut s'agir d'un événement explicite issu de l'achèvement du conditionnement des conteneurs dans le module WMS ou inféré de la génération du journal de Packing Slip (CustPackingSlipJour), qui marque souvent la fin du conditionnement.
Capture
Déduire de l'achèvement du travail d'emballage ou de la date de création du journal des bons de livraison.
Type d'événement
inferred
|
|||
|
Marchandises livrées
|
Indique que l'expédition a été livrée avec succès à l'adresse spécifiée par le client. Cette information est souvent mise à jour à partir du système d'un transporteur externe ou par une confirmation manuelle. | ||
|
Pourquoi est-ce important ? :
Cette activité est indispensablele pour mesurer le KPI de "Respect des Délais de Livraison" et comprendre le temps de cycle réel du point de vue client. Elle contribue à évaluer la performance des transporteurs.
Source des données :
Cela n'est pas nativement suivi comme un événement explicite dans D365 standard. Il est généralement déduit en recevant une mise à jour d'une intégration de transporteur ou via une mise à jour manuelle du statut sur l'enregistrement de la commande client ou de l'expédition.
Capture
Déduire d'un flux de données de transporteur intégré ou d'une mise à jour manuelle d'un champ de statut.
Type d'événement
inferred
|
|||
|
Marchandises prélevées
|
Représente la finalisation du prélèvement physique de tous les articles pour la commande depuis leurs emplacements d'entrepôt. Ceci est généralement enregistré lorsqu'un préparateur finalise une liste de prélèvement.lèvement ou un ordre de travail dans le module WMS. | ||
|
Pourquoi est-ce important ? :
Le suivi du temps d'achèvement de la préparation est indispensable pour analyser l'efficacité de l'entrepôt. Les retards à ce stade ont un impact direct sur le temps total d'expédition.
Source des données :
Il s'agit d'un événement explicite enregistré dans le module de gestion d'entrepôt. Il est capturé à partir du horodatage d'achèvement du travail d'entrepôt (WHSWorkTable) lié à la préparation de la commande client.
Capture
Capture l'horodatage lorsque le statut 'Work' de la préparation est mis à jour en 'Closed'.
Type d'événement
explicit
|
|||
|
Stock Réservé
|
Cet événement indique que l'inventaire requis pour les lignes de commande client a été réservé physiquement ou automatiquement dans le système. Cela garantit la disponibilité des articles pour la préparation et l'exécution. | ||
|
Pourquoi est-ce important ? :
Le suivi de la réservation d'inventaire aide à analyser les retards entre la confirmation de commande et le début des opérations d'entrepôt. Il est impératif pour le KPI du "Délai d'Allocation d'Inventaire".
Source des données :
Cela peut être déduit de la création ou de la mise à jour des enregistrements de transactions d'inventaire (InventTrans) liés aux lignes de commande client, lorsque le statut indique une réservation (par exemple, "En commande", "Réservé physiquement").
Capture
Déduire du horodatage lorsque les transactions d'inventaire (InventTrans) pour la commande sont marquées comme réservées.
Type d'événement
inferred
|
|||
|
Vérification de Crédit Effectuée
|
Représente la finalisation d'une vérification de crédit pour le client associé à la commande client. Il peut s'agir d'une vérification système automatisée ou d'un examen manuel, entraînant 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 contrôles de crédit permet d'identifier les points de blocage dans le processus d'approbation des commandes. Des mises en attente fréquentes ou des délais d'approbation longs peuvent retarder considérablement l'exécution des commandes.
Source des données :
Généralement déduit des changements de statut liés à la gestion du crédit sur la SalesTable, comme le passage de "En attente" avec une raison de crédit à "Ouvert". Il peut également être enregistré dans les tables de gestion du crédit si le module avancé est utilisé.
Capture
Déduire de l'historique des changements de statut sur la SalesTable ou les tables de blocage de crédit associées.
Type d'événement
inferred
|
|||