Votre modèle de données Purchase to Pay - Purchase Order
Votre modèle de données Purchase to Pay - Purchase Order
- Attributs recommandés à recueillir
- Activités clés à suivre pour la cartographie du processus
- Conseils pratiques pour l'extraction des données
Purchase to Pay - Attributs des commandes d’achat
| Nom | Description | ||
|---|---|---|---|
|
Bon de commande
PurchaseOrderNumber
|
Identifiant unique du bon de commande, utilisé comme dossier principal pour l'analyse du processus. | ||
|
Description
Le numéro de commande d’achat est l’identifiant central qui relie toutes les activités associées, du brouillon initial à l’achèvement ou à l’annulation. Chaque numéro unique représente une instance du processus de commande d’achat. Dans le Process Mining, cet attribut sert à reconstituer le parcours de bout en bout de chaque commande d’achat. L’analyse du processus à partir de cet identifiant offre une vue détaillée de l’ensemble du cycle de vie et aide à repérer les chemins fréquents, les écarts et les goulots d’étranglement propres à chaque commande.
Pourquoi c’est important
Il s'agit de la clé fondamentale pour reconstituer le flux du processus et analyser le parcours de chaque bon de commande, du début à la fin.
Où les obtenir
Il s'agit de la clé primaire de la table d'en-tête des bons de commande, généralement PurchTable, avec le nom de champ PurchId dans Microsoft Dynamics 365.
Exemples
PO-001245PO-001246PO-001247
|
|||
|
Heure de l'événement
EventTime
|
Date et heure précises auxquelles une activité ou un événement donné s'est produit. | ||
|
Description
Cet horodatage indique le moment où chaque activité du processus de commande d’achat a eu lieu. Il constitue la trame chronologique du processus et permet d’ordonner correctement les événements. Dans l’analyse des processus, les horodatages des événements sont indispensables pour calculer les temps de cycle, les durées entre les activités et la durée globale du cas. Ils servent à repérer les goulots d’étranglement, à mesurer les performances par rapport aux SLA et à comprendre la dynamique temporelle du processus. Ils permettent notamment de calculer le délai entre « Purchase Order Created » et « Purchase Order Approved ».
Pourquoi c’est important
Les horodatages sont essentiels au calcul de toutes les métriques de performance fondées sur le temps, notamment les temps de cycle et les durées, qui permettent d’identifier les goulots d’étranglement du processus.
Où les obtenir
Extrait de différents champs de date et d'heure répartis dans plusieurs tables, tels que CreatedDateTime dans PurchTable ou les dates d'enregistrement des journaux associés.
Exemples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
|
|||
|
Nom de l'activité
ActivityName
|
Nom de l'événement métier ou de l'étape précise survenue au cours du cycle de vie du bon de commande. | ||
|
Description
Cet attribut décrit une étape du processus de bon de commande, telle que « Bon de commande créé », « Bon de commande approuvé » ou « Réception des marchandises enregistrée ». La séquence de ces activités forme le flux du processus pour chaque bon de commande. L'analyse des activités constitue le cœur du Process Mining. Elle permet de visualiser la carte du processus, de découvrir les variantes et d'identifier les activités fréquemment répétées ou à l'origine de retards. Comprendre la séquence et la fréquence des activités est essentiel pour optimiser le processus.
Pourquoi c’est important
Cet attribut est essentiel pour créer la carte du processus et comprendre la séquence des événements qui composent le cycle de vie du bon de commande.
Où les obtenir
Dérivé de la logique métier fondée sur les changements de statut dans des tables telles que PurchTable et PurchReqTable, ainsi que dans les journaux d'enregistrement associés, comme VendPackingSlipJour ou VendInvoiceJour.
Exemples
Purchase Order crééPurchase Order approuvéRéception de marchandises enregistréePurchase Order facturé
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage indiquant la dernière actualisation des données de ce processus. | ||
|
Description
Cet attribut enregistre la date et l'heure de l'extraction la plus récente des données depuis le système source. Il indique le degré d'actualité des données analysées. Connaître l'heure de la dernière mise à jour permet aux utilisateurs de savoir s'ils consultent les données de processus les plus récentes. Cela aide à évaluer la pertinence de l'analyse et à planifier les actualisations régulières des données.
Pourquoi c’est important
Garantit la transparence quant à l'actualité des données et permet aux utilisateurs de savoir dans quelle mesure leur analyse du processus est à jour.
Où les obtenir
Il s'agit d'un attribut de métadonnées généré et enregistré lors de l'ingestion des données.
Exemples
2024-05-21T05:00:00Z
|
|||
|
Système source
SourceSystem
|
Indique le système depuis lequel les données ont été extraites. | ||
|
Description
Cet attribut identifie l'application source dont proviennent les données des bons de commande. Pour ce modèle de données, la valeur sera généralement « Microsoft Dynamics 365 ». Dans les grandes organisations, les processus d'approvisionnement peuvent s'étendre sur plusieurs systèmes. Cet attribut contribue à la gouvernance des données et garantit que leur origine est clairement établie, ce qui est particulièrement important lors de la fusion de données provenant de différentes sources.
Pourquoi c’est important
Fournit un contexte essentiel sur l'origine des données, indispensable à leur gouvernance et à leur validation, ainsi qu'à la compréhension de l'environnement technologique du processus.
Où les obtenir
Il s'agit d'une valeur statique ajoutée lors de l'extraction et de la transformation des données afin d'identifier le jeu de données.
Exemples
Microsoft Dynamics 365 F&OD365
|
|||
|
Date de livraison demandée
RequestedDeliveryDate
|
Date à laquelle l'entreprise a demandé au fournisseur de livrer les marchandises ou les services. | ||
|
Description
Cette date est indiquée sur le bon de commande et communique au fournisseur le calendrier de livraison souhaité. Elle sert de référence pour mesurer la performance de livraison du fournisseur. Cet attribut est essentiel au Dashboard « Respect des délais de livraison des fournisseurs » et à l'indicateur « taux de livraison dans les délais ». En comparant RequestedDeliveryDate à la date réelle de réception des marchandises, les entreprises peuvent mesurer la fiabilité des fournisseurs et repérer les retards récurrents dans la chaîne d'approvisionnement.
Pourquoi c’est important
Il constitue la référence pour mesurer la performance des livraisons dans les délais, un indicateur essentiel pour évaluer la fiabilité des fournisseurs et l'efficacité de la chaîne d'approvisionnement.
Où les obtenir
Se trouve généralement dans PurchTable, au niveau de l'en-tête, ou dans PurchLine, au niveau de la ligne, sous le nom DeliveryDate.
Exemples
2023-11-152023-12-012024-01-20
|
|||
|
Montant total du bon de commande
PurchaseOrderTotalAmount
|
Valeur monétaire totale du bon de commande. | ||
|
Description
Cet attribut représente le coût total de tous les articles et services inclus dans le bon de commande. Il s'agit d'un indicateur financier clé du processus d'approvisionnement. L'analyse du processus selon le montant total peut révéler des éléments importants. Par exemple, les bons de commande de valeur élevée peuvent suivre un parcours d'approbation différent et plus strict, ou présenter des temps de cycle plus longs. Le montant sert également aux rapports financiers et au classement des bons de commande par tranches de valeur.
Pourquoi c’est important
Permet d'analyser financièrement le processus d'approvisionnement et de comprendre comment la valeur de la commande influence le comportement du processus, notamment les délais et les parcours d'approbation.
Où les obtenir
Cette valeur peut être calculée à partir de la table PurchLine en additionnant LineAmount pour un PurchId donné, ou être récupérée dans les champs de montant de l'en-tête de PurchTable.
Exemples
5250.00120.50150000.00
|
|||
|
Nom d'utilisateur
UserName
|
Nom de l'utilisateur ayant effectué une activité donnée. | ||
|
Description
Cet attribut identifie la personne responsable de l'exécution d'un événement, par exemple la création, l'approbation ou la modification d'un bon de commande. Il peut s'agir d'un identifiant utilisateur système ou d'un nom complet. L'analyse de l'activité des utilisateurs aide à comprendre la répartition de la charge de travail, à identifier les besoins de formation et à repérer les personnes ou les équipes associées aux écarts du processus. Elle est essentielle pour les Dashboards consacrés à la performance des approbateurs et permet de filtrer le processus selon les activités effectuées par des utilisateurs précis.
Pourquoi c’est important
Il permet d’analyser les performances par utilisateur, d’identifier les goulots d’étranglement liés à certaines personnes et d’établir la répartition des responsabilités pour les étapes du processus.
Où les obtenir
Peut être trouvé dans des champs tels que CreatedBy ou ModifiedBy de tables comme PurchTable. Les informations utilisateur sont généralement stockées dans la table UserInfo.
Exemples
Alice JohnsonBob WilliamsSysAdmin
|
|||
|
Nom du fournisseur
VendorName
|
Nom du fournisseur pour lequel le bon de commande est créé. | ||
|
Description
Cet attribut contient le nom du fournisseur externe qui fournit les marchandises ou les services. Il constitue une dimension essentielle pour analyser les activités d'approvisionnement. La segmentation du processus par nom de fournisseur est essentielle pour évaluer la performance des fournisseurs. Elle permet d'analyser, pour chacun d'eux, les taux de livraison dans les délais, de retour des marchandises et les résultats des contrôles qualité. Cette analyse aide à distinguer les partenaires fiables de ceux qui peuvent être à l'origine de retards ou de problèmes de qualité.
Pourquoi c’est important
Cet attribut est essentiel à la gestion de la performance des fournisseurs et permet d'analyser les délais de livraison, les taux de retour et la fiabilité globale de chaque fournisseur.
Où les obtenir
Le compte fournisseur est stocké dans PurchTable, dans le champ OrderAccount. Le nom est récupéré en effectuant une jointure avec VendTable.
Exemples
Contoso Office SuppliesFabrikam RoboticsNorthwind Traders
|
|||
|
Statut du bon de commande
PurchaseOrderStatus
|
Statut actuel du bon de commande dans son cycle de vie. | ||
|
Description
Cet attribut indique l'état global du bon de commande à un moment donné, par exemple « Open order », « Received », « Invoiced » ou « Canceled ». Il représente le résultat de la dernière activité. Le suivi du statut permet de comprendre l'état actuel de tous les bons de commande ouverts. Dans le Process Mining, il peut servir à analyser les résultats des dossiers, par exemple en filtrant tous les bons de commande dont l'état final est « Canceled » afin d'en rechercher les raisons.
Pourquoi c’est important
Fournit un aperçu de l'état actuel du bon de commande, utile pour filtrer les dossiers et analyser les résultats du processus, notamment les taux d'achèvement ou d'annulation.
Où les obtenir
Se trouve dans PurchTable. Les principaux champs de statut sont DocumentState et PurchStatus.
Exemples
Commande ouverteReçueFacturéeAnnulée
|
|||
|
Bon de commande modifié
IsPurchaseOrderChanged
|
Indicateur booléen précisant si le bon de commande a été modifié après son approbation initiale. | ||
|
Description
Cet attribut calculé prend la valeur « true » si une activité « Bon de commande modifié » survient après l'activité « Bon de commande approuvé » pour un dossier donné. Il simplifie l'analyse des reprises et des modifications. Cet indicateur est essentiel au calcul de l'indicateur « taux de modification des bons de commande après approbation » et au Dashboard « Tendances des modifications des bons de commande ». Il permet d'isoler et d'analyser facilement les bons de commande ayant nécessité une reprise, afin d'identifier les causes profondes de ces changements.
Pourquoi c’est important
Simplifie la mesure des reprises et de la fréquence des modifications, qui sont des indicateurs importants de l'instabilité et de l'inefficacité du processus.
Où les obtenir
Il s'agit d'un attribut calculé à partir de la séquence des activités du journal d'événements.
Exemples
truefalse
|
|||
|
Catégorie d'achat
PurchaseCategory
|
Classification de l'article ou du service acheté, par exemple « Matériel informatique » ou « Fournitures de bureau ». | ||
|
Description
Cet attribut permet de regrouper les articles des bons de commande en catégories logiques. Cette classification aide à analyser les habitudes de dépenses et les variations du processus selon les différents types d'approvisionnement. Dans l'analyse des processus, le filtrage par catégorie d'achat peut révéler des comportements différents. Par exemple, le processus d'approvisionnement lié aux dépenses d'investissement peut être plus long et plus complexe que celui des fournitures courantes. Cet attribut est utilisé dans les Dashboards pour analyser les tendances de modification et les taux de retour par catégorie.
Pourquoi c’est important
Permet de segmenter le processus selon le type de marchandises ou de services achetés et de révéler les différences de comportement entre les catégories de dépenses.
Où les obtenir
Les catégories d'articles sont associées aux produits commercialisés, dans InventTable, qui sont ensuite utilisés dans PurchLine. Les informations de catégorie sont stockées dans les tables de gestion des catégories.
Exemples
Matériel informatiqueFournitures de bureauServices professionnelsMatières premières
|
|||
|
Code société
CompanyCode
|
Identifiant de l'entité juridique ou de la société qui passe le bon de commande. | ||
|
Description
Dans un environnement multi-entreprises, cet attribut indique quelle entité juridique effectue l'achat. Il s'agit d'une donnée organisationnelle fondamentale. Cet attribut permet de comparer le processus P2P entre les différentes entités juridiques d'une même organisation. Il peut mettre en évidence des écarts d'efficacité, de conformité et de gestion des fournisseurs d'une société à l'autre, et soutenir les efforts de standardisation.
Pourquoi c’est important
Essentiel aux organisations composées de plusieurs entités pour comparer et standardiser le processus d'approvisionnement entre les différentes entités juridiques.
Où les obtenir
Il s'agit du champ DataAreaId, présent dans presque toutes les tables de Dynamics 365, y compris PurchTable.
Exemples
USMFDEMFGBSI
|
|||
|
Demande d'achat
PurchaseRequisitionNumber
|
Identifiant de la demande d'achat qui a précédé le bon de commande. | ||
|
Description
Cet attribut relie un bon de commande à la demande interne initiale, c'est-à-dire la demande d'achat. Tous les bons de commande ne proviennent pas d'une demande d'achat. Ce lien est essentiel pour analyser l'ensemble du processus « de la demande d'achat au bon de commande ». Il permet de mesurer l'indicateur « vitesse de conversion de la demande d'achat en bon de commande » et de comprendre à quelle vitesse la demande interne est transformée en commande externe. Il contribue également à l'analyse de la conformité, par exemple en identifiant les bons de commande créés sans demande d'achat officielle.
Pourquoi c’est important
Relie le bon de commande à la demande initiale, ce qui permet d'analyser le temps de cycle entre la demande et la commande et de vérifier la conformité du processus.
Où les obtenir
Se trouve dans la table PurchLine, dans le champ PurchReqId, qui renvoie à PurchReqTable.
Exemples
PR-000871PR-000872PR-000873
|
|||
|
Lieu de livraison
DeliveryLocation
|
Site, entrepôt ou adresse précise où les marchandises doivent être livrées. | ||
|
Description
Cet attribut indique le lieu physique de livraison des articles de la commande d’achat. Il peut s’agir d’un entrepôt, d’un bureau précis ou d’un site de projet. L’analyse du processus par lieu de livraison peut aider à repérer les goulots d’étranglement régionaux ou propres à un site, notamment lors de la réception des marchandises. Le Dashboard « Goods Receipt Processing Time » peut utiliser cet attribut pour comparer l’efficacité entre différents lieux.
Pourquoi c’est important
Aide à identifier les variations ou les retards propres à certains lieux, notamment lors des étapes de réception des marchandises et de contrôle qualité.
Où les obtenir
Les informations relatives à l'adresse et au lieu de livraison sont stockées dans PurchTable et peuvent être renseignées par défaut à partir des paramètres de l'entreprise ou du fournisseur.
Exemples
Entrepôt principal ABureau du bâtiment CCentre de distribution de la côte Ouest
|
|||
|
Livraison dans les délais
IsOnTimeDelivery
|
Indicateur booléen précisant si les marchandises ont été réceptionnées à la date de livraison demandée ou avant celle-ci. | ||
|
Description
Cet attribut calculé compare l'horodatage de l'activité « Réception des marchandises enregistrée » à RequestedDeliveryDate. Il prend la valeur « true » si la date de réception est antérieure ou égale à la date demandée. Cet indicateur contribue directement au calcul de l'indicateur « taux de livraison dans les délais ». Il simplifie l'analyse de la performance des fournisseurs et permet de filtrer et de visualiser facilement les livraisons dans les délais et les livraisons en retard, au cœur du Dashboard « Respect des délais de livraison des fournisseurs ».
Pourquoi c’est important
Fournit un résultat binaire clair pour la performance des livraisons et simplifie le calcul des indicateurs de livraison dans les délais ainsi que des fiches d'évaluation des fournisseurs.
Où les obtenir
Il s'agit d'un attribut calculé en comparant RequestedDeliveryDate à EventTime de l'activité « Réception des marchandises enregistrée ».
Exemples
truefalse
|
|||
|
Motif du retour
ReturnReason
|
Motif indiqué lorsque les marchandises d'un bon de commande sont retournées au fournisseur. | ||
|
Description
Lorsqu'une activité « Marchandises retournées au fournisseur » se produit, cet attribut enregistre la justification du retour, par exemple « Marchandises endommagées », « Article incorrect » ou « Qualité insuffisante ». Ces données sont très utiles pour le Dashboard « Taux de retour des bons de commande ». L'analyse des motifs de retour aide à identifier les causes profondes des retours, qu'elles soient liées à la qualité du fournisseur, à des erreurs de commande internes ou à des problèmes d'expédition. Elle permet ainsi de prendre des mesures ciblées pour réduire le taux de retour.
Pourquoi c’est important
Fournit des informations sur les raisons des retours et aide à diagnostiquer les problèmes liés à la qualité du fournisseur, à l'exactitude des commandes ou à la logistique.
Où les obtenir
Les motifs de retour sont généralement enregistrés dans les transactions de retour ou au moyen de codes motif associés aux journaux de réception négatifs.
Exemples
Endommagé pendant le transportMauvais article livréÉchec du contrôle qualité
|
|||
|
Nom de l'approbateur
ApproverName
|
Nom de l’utilisateur qui a approuvé la commande d’achat ou une étape du flux de travail d’approbation. | ||
|
Description
Cet attribut identifie le responsable ou l’utilisateur qui a officiellement approuvé la commande d’achat, permettant ainsi son traitement. Dans les flux de travail d’approbation à plusieurs niveaux, une même commande d’achat peut avoir plusieurs approbateurs. Le suivi de l’approbateur est essentiel pour les Dashboards « PO Approval Cycle Time Analysis » et « Approver Performance Metrics ». Il permet de mesurer le temps pris par chaque approbateur, d’identifier les goulots d’étranglement dans la chaîne d’approbation et d’évaluer la répartition de la charge ainsi que l’efficacité.
Pourquoi c’est important
Il permet d’analyser le processus d’approbation, d’identifier les goulots d’étranglement et de mesurer les performances ainsi que la charge de travail des différents approbateurs.
Où les obtenir
Les informations d’approbation sont généralement stockées dans les tables de suivi des flux de travail, et non directement dans PurchTable. Elles nécessitent l’interrogation de l’historique du flux de travail associé à la commande d’achat.
Exemples
Charles GreenDiana PrinceEdward Nigma
|
|||
|
Service
DepartmentName
|
Nom du service à l'origine de la demande d'achat ou du bon de commande. | ||
|
Description
Cet attribut identifie l'unité opérationnelle ou le service interne responsable de l'achat. Il est souvent déduit de la personne ayant créé la demande d'achat. L'analyse du processus par service est essentielle pour comprendre comment les différentes composantes de l'organisation utilisent le processus d'approvisionnement. Elle peut mettre en évidence les services dont les cycles d'approbation sont plus longs, qui modifient davantage leurs bons de commande ou qui présentent des habitudes d'achat particulières. Ces informations permettent de cibler les initiatives d'amélioration du processus.
Pourquoi c’est important
Il permet de comparer les performances du processus entre différentes unités opérationnelles et d’identifier les comportements, les goulots d’étranglement ou les inefficacités propres à chaque service.
Où les obtenir
Ces informations sont souvent associées au demandeur ou au créateur de la demande d'achat, dans PurchReqTable, ou du bon de commande, dans PurchTable, ainsi qu'à son service correspondant dans le module RH.
Exemples
FinanceInformatiqueProductionMarketing
|
|||
Purchase to Pay - Activités liées aux commandes d’achat
| Activité | Description | ||
|---|---|---|---|
|
Demande d’achat créée
|
Cette activité correspond à la création d’une demande d’achat, c’est-à-dire la demande officielle de biens ou de services. Elle est enregistrée lorsqu’un nouvel enregistrement est créé dans la table des demandes d’achat, ce qui marque le début du besoin d’approvisionnement. | ||
|
Pourquoi c’est important
Il s’agit du déclencheur initial du processus de Purchase Order. L’analyse du délai entre cet événement et la création du PO permet de mesurer l’efficacité du processus interne et sa réactivité face à la demande.
Où les obtenir
Cet événement correspond à la création d’un enregistrement dans PurchReqTable. L’horodatage de création (createdDateTime) de l’enregistrement indique l’heure de l’événement.
Collecte
Extrayez l’horodatage de création de PurchReqTable pour chaque demande d’achat.
Type d’événement
explicit
|
|||
|
Purchase Order approuvé
|
Marque l’approbation finale de la commande d’achat, qui autorise son envoi au fournisseur. Cet événement est généralement déduit d’un changement de statut de la commande ou enregistré directement dans l’historique du flux de travail. | ||
|
Pourquoi c’est important
Il s’agit d’une étape déterminante, car aucune action supplémentaire ne peut être engagée tant que le PO n’est pas approuvé. Elle est indispensable pour analyser les goulots d’étranglement des approbations et mesurer le KPI « PO Approval Cycle Time ».
Où les obtenir
L’événement est déduit du passage du champ DocumentState de PurchTable à « Approved ». Il peut également être extrait de l’horodatage d’achèvement de la dernière étape d’approbation dans WorkflowTrackingStatusTable.
Collecte
Identifiez l’horodatage auquel DocumentState de PurchTable passe à « Approved ».
Type d’événement
inferred
|
|||
|
Purchase Order créé
|
Cette activité correspond à la création d’un document Purchase Order à l’état de brouillon dans le système. Elle est extraite de l’horodatage de création de l’en-tête du Purchase Order, généralement après l’approbation d’une demande d’achat. | ||
|
Pourquoi c’est important
Cette étape marque le passage d’une demande interne à un document d’achat officiel. Elle constitue un point de départ important pour mesurer les délais de traitement et d’approbation des PO.
Où les obtenir
Cet événement correspond à la création d’un enregistrement dans PurchTable. Le champ createdDateTime de cette table fournit l’horodatage de l’activité.
Collecte
Extrayez l’horodatage de création de PurchTable pour chaque Purchase Order.
Type d’événement
explicit
|
|||
|
Purchase Order envoyé au fournisseur
|
Cette activité indique que le Purchase Order approuvé a été communiqué au fournisseur. Elle est enregistrée lorsque le PO est confirmé, ce qui génère un journal de confirmation et déclenche généralement l’envoi du document. | ||
|
Pourquoi c’est important
Il s’agit de la première étape tournée vers l’extérieur et du point de départ du délai fournisseur. Elle est essentielle au suivi de la performance des fournisseurs et du KPI « On-Time Delivery Rate ».
Où les obtenir
L’événement est marqué par la création d’un enregistrement dans la table PurchPurchaseOrderJour, qui correspond au journal de confirmation du PO. La date de création de ce journal sert d’horodatage à l’activité.
Collecte
Utilisez l’horodatage de création du premier enregistrement PurchPurchaseOrderJour pour le PO.
Type d’événement
explicit
|
|||
|
Purchase Order terminé
|
Indique la conclusion réussie du cycle de vie du bon de commande, lorsque toutes les marchandises ont été réceptionnées et facturées. Cette conclusion est généralement déduite lorsque le statut du bon de commande est mis à jour et passe à un état final clôturé. | ||
|
Pourquoi c’est important
Cette activité définit la fin réussie d'une instance de processus. Mesurer le « temps de cycle global du bon de commande » entre sa création et son achèvement fournit une vue d'ensemble de l'efficacité du processus.
Où les obtenir
Déduit des champs de statut de PurchTable, notamment lorsque DocumentState est « Invoiced » et que les statuts des lignes indiquent une réception et une facturation complètes.
Collecte
Identifiez l'horodatage auquel les statuts de l'en-tête et des lignes du bon de commande sont mis à jour et passent à un état final clôturé, par exemple « Invoiced ».
Type d’événement
inferred
|
|||
|
Réception de marchandises enregistrée
|
Marque l’enregistrement officiel des marchandises reçues pour le Purchase Order dans le système. Cet événement est enregistré lorsqu’un journal de réception de produits est validé. | ||
|
Pourquoi c’est important
Il s’agit d’une étape déterminante qui met à jour les stocks et marque le début du rapprochement des factures. Elle constitue le point final pour mesurer le « On-Time Delivery Rate » et le délai fournisseur.
Où les obtenir
L’événement est extrait de la création du journal de réception des produits, enregistré dans VendPackingSlipJour. Le champ createdDateTime ou PackingSlipDate de cette table indique la date à laquelle les marchandises ont été officiellement reçues.
Collecte
Utilisez l’horodatage de création ou de validation de l’enregistrement VendPackingSlipJour associé au PO.
Type d’événement
explicit
|
|||
|
Bon de commande annulé
|
Représente l'arrêt d'un bon de commande avant son achèvement complet. Cet événement est enregistré par une modification spécifique du statut du document de commande. | ||
|
Pourquoi c’est important
Les annulations constituent un cas d'exception important. L'analyse de leur fréquence et de leurs motifs peut mettre en évidence des problèmes de planification ou de fiabilité des fournisseurs.
Où les obtenir
Déduit de la mise à jour du champ DocumentState de PurchTable, qui passe à « Canceled ». L'horodatage de cette modification de statut marque l'événement.
Collecte
Identifiez l'horodatage auquel DocumentState de PurchTable est défini sur « Canceled ».
Type d’événement
inferred
|
|||
|
Demande d’achat approuvée
|
Représente l’approbation officielle d’une demande d’achat par un responsable habilité. Cet événement est généralement enregistré dans l’historique du flux de travail ou déduit d’un changement de statut de la demande. | ||
|
Pourquoi c’est important
L’approbation constitue une étape déterminante, car elle permet de convertir la demande en Purchase Order. Tout retard à ce stade affecte directement l’ensemble du calendrier des achats.
Où les obtenir
L’événement peut être extrait de WorkflowTrackingStatusTable, associée à la demande d’achat, ou déduit du passage du champ de statut de PurchReqTable à l’état « Approved ».
Collecte
Utilisez l’horodatage d’achèvement de la dernière étape d’approbation dans l’historique du flux de travail de la demande.
Type d’événement
explicit
|
|||
|
Inspection qualité effectuée
|
Représente l’achèvement d’une inspection qualité des marchandises reçues. Cet événement est souvent géré dans le module Quality Management ou au moyen d’une mise à jour de statut. | ||
|
Pourquoi c’est important
Cette activité peut constituer un goulot d’étranglement important entre la réception des marchandises et leur mise à disposition. L’analyse de sa durée aide à améliorer le KPI « Quality Inspection Cycle Time ».
Où les obtenir
L’événement peut être déduit de l’achèvement d’un Quality Order (InventQualityOrderTable) associé à la réception du Purchase Order. L’horodatage du passage du statut à « Passed » ou « Failed » marque l’événement.
Collecte
Suivez l’horodatage d’achèvement du statut dans InventQualityOrderTable, associé à la ligne du PO.
Type d’événement
inferred
|
|||
|
Marchandises retournées au fournisseur
|
Indique que des marchandises précédemment reçues ont été retournées au fournisseur en raison de dommages ou d’articles incorrects, par exemple. L’événement est enregistré lors de la validation d’une transaction de retour. | ||
|
Pourquoi c’est important
Les retours révèlent des défaillances du processus et des coûts supplémentaires. Le suivi de cette activité permet de calculer le « Purchase Order Return Rate » et d’identifier les problèmes liés aux fournisseurs ou aux produits.
Où les obtenir
L’événement est déduit de la création d’un Purchase Order avec une quantité négative ou d’un document de retour précis faisant référence au PO d’origine. La date de transaction de la validation du retour correspond à l’heure de l’événement.
Collecte
Identifiez la validation d’un Purchase Order de retour ou d’une note de débit associée au PO d’origine.
Type d’événement
explicit
|
|||
|
Purchase Order confirmé par le fournisseur
|
Représente l’accusé de réception et la confirmation par le fournisseur des détails du Purchase Order. Il s’agit souvent d’une saisie manuelle effectuée à partir des échanges avec le fournisseur. | ||
|
Pourquoi c’est important
La confirmation du fournisseur garantit que la commande est en cours de traitement. Les retards ou les écarts à cette étape peuvent signaler des problèmes potentiels d’exécution.
Où les obtenir
L’événement est généralement déduit du renseignement de champs de date ou de statut liés à la confirmation dans PurchTable, tels que les dates de confirmation de livraison. Il peut ne pas correspondre à un événement distinct.
Collecte
Déduisez l’événement du renseignement d’un champ de date de confirmation précis dans PurchTable ou PurchLine.
Type d’événement
inferred
|
|||
|
Purchase Order facturé
|
Cette activité marque le moment où une facture fournisseur a été reçue et enregistrée pour le Purchase Order. Elle relie le processus d’achat au processus de paiement. | ||
|
Pourquoi c’est important
Il s’agit de la dernière étape avant le paiement et d’un élément essentiel pour calculer le coût final de l’achat. Elle fournit le point final de l’analyse du rapprochement à trois niveaux.
Où les obtenir
L’événement est extrait de la validation d’un journal de facture fournisseur (VendInvoiceJour) rapproché avec le Purchase Order. Le champ InvoiceDate ou la date de validation de cet enregistrement fournit l’horodatage.
Collecte
Utilisez l’horodatage de validation de la table VendInvoiceJour associée à l’enregistrement PurchTable.
Type d’événement
explicit
|
|||
|
Purchase Order modifié
|
Cette activité enregistre toute modification apportée à un Purchase Order après son approbation. Dynamics 365 peut suivre les différentes versions du PO et permettre ainsi d’identifier les changements. | ||
|
Pourquoi c’est important
Le suivi des modifications est essentiel pour repérer les reprises, comprendre l’instabilité du processus et mesurer le KPI « PO Modification Rate ». Les changements peuvent entraîner des retards et des variations de coûts.
Où les obtenir
L’événement est déduit de la comparaison des différentes versions du Purchase Order conservées dans les tables d’archivage ou de gestion des versions, par exemple PurchTableHistory. L’augmentation du numéro de version indique une modification.
Collecte
Identifiez les enregistrements pour lesquels le numéro de version de PurchTable a augmenté après l’approbation.
Type d’événement
inferred
|
|||
|
Purchase Order soumis pour approbation
|
Représente le moment où une commande d’achat à l’état de brouillon est officiellement soumise au flux de travail d’approbation. Il s’agit généralement d’une action explicite de l’utilisateur, enregistrée dans les journaux du flux de travail. | ||
|
Pourquoi c’est important
Cette activité marque officiellement le début du cycle d’approbation du PO. Son suivi permet de mesurer précisément le temps d’attente avant approbation ainsi que la durée totale de l’approbation.
Où les obtenir
L’événement est extrait de WorkflowTrackingStatusTable pour le Purchase Order, qui enregistre la soumission et son horodatage.
Collecte
Identifiez l’événement « Submitted » dans l’historique du flux de travail associé à l’enregistrement PurchTable.
Type d’événement
explicit
|
|||
Guides d'extraction
Prêt à commencer ?
Avec ce modèle, vous disposez de tout ce qu’il vous faut pour commencer à optimiser votre processus Purchase to Pay, Purchase Order. Commencez dès aujourd’hui à transformer vos opérations d’approvisionnement.
Améliorez dès maintenant l'efficacité de votre processus Purchase to Pay, Purchase Order
Identifiez les inefficacités et réduisez jusqu'à 30 % la durée du cycle P2P.
Aucune carte bancaire requise, configuration en quelques minutes