Votre modèle de données pour le processus Achat au Paiement - Bon de Commande
Votre modèle de données pour le processus Achat au Paiement - Bon de Commande
- Attributs de données recommandés
- Activités clés du processus
- Étapes d'extraction des données Coupa
De l'achat au paiement - Attributs des bons de commande
| Nom | Descriptionn | ||
|---|---|---|---|
|
Activité
ActivityName
|
Le nom de l'événement ou de la tâche spécifique qui s'est produit à un moment donné du cycle de vie du bon de commande. | ||
|
Descriptionn
Le nom de l'activité décrit une étape unique du processus Achats au paiement (P2P), telle que 'Commande d'achat approuvée' ou 'Réception de marchandises enregistrée'. Cette séquence d'activités constitue le flux de processus pour chaque commande d'achat. Cet attribut est indispensable pour le Process Mining, car il est utilisé pour construire la cartographie des processus, découvrir les variantes de processus et analyser la fréquence et la séquence des événements. Il aide à identifier les points de blocage, les boucles de reprise et les écarts par rapport au flux de processus standard. Par exemple, l'analyse de la séquence des activités 'Commande d'achat modifiée' peut révéler des inefficacités dans la précision des commandes.
Pourquoi est-ce important ? :
Elle définit les étapes du processus, facilite la visualisation du flux et l'identification des points de blocage, du reprises et des écarts.
Source des données :
Dérivé des journaux d'événements, des pistes d'audit ou des enregistrements de changement de statut associés aux objets bon de commande dans Coupa.
Exemples
Demande d'achat approuvéeCommande d'achat soumiseRéception de marchandises enregistréeFacture reçue pour le bon de commande
|
|||
|
Bon de commande
PurchaseOrderNumber
|
L'identifiant unique pour un bon de commande, servant d'identifiant de dossier principal pour le processus. | ||
|
Descriptionn
Le numéro de bon de commande est l'identifiant de cas central qui relie toutes les activités de sa demande initiale à la confirmation finale de la réception des biens ou services. Chaque numéro de bon de commande unique représente une instance individuelle du processus d'approvisionnement. Dans l'analyse par Process Mining, cet attribut est impératif pour retracer le parcours de chaque achat complet. Il permet aux analystes de visualiser les cartes de processus, d'identifier les variantes et de calculer des KPIs au niveau du cas, tels que le temps de cycle total d'une commande. Tous les événements et les données associées sont regroupées sous cet identifiant pour construire une vue cohérente du processus.
Pourquoi est-ce important ? :
Indispensable pour suivre le cycle de vie complet de chaque achat, elle permet de reconstituer les instances de processus pour une analyse détaillée.
Source des données :
Ceci est un champ de clé primaire standard sur l'objet Bon de commande dans Coupa.
Exemples
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Heure de début
EventTime
|
L'horodatage exact indiquant quand une activité ou un événement s'est produit. | ||
|
Descriptionn
L'horodatage de l'événement enregistre la date et l'heure auxquelles une activité spécifique a été exécutée. Pour chaque activité du processus, il existe un horodatage correspondant qui marque son occurrence. 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 du processus et identifier les retards. Par exemple, la différence de temps entre les horodatages « Bon de commande rédigé » et « Bon de commande approuvé » est utilisée pour calculer le KPI de temps de cycle d'approbation des bons de commande.
Pourquoi est-ce important ? :
Elle fournit le contexte temporel de chaque événement, indispensable pour calculer les temps de cycle, analyser la performance et détecter les points de blocage.
Source des données :
Présent dans les journaux d'événements ou les pistes d'audit de Coupa, généralement associé à chaque changement de statut ou action effectuée sur un bon de commande.
Exemples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L'horodatage indiquant la dernière fois que les données de ce processus ont été actualisées. | ||
|
Descriptionn
Cet attribut enregistre la dernière date de mise à jour du jeu de données depuis le système source. C'est un champ de métadonnées qui s'applique à l'ensemble du jeu de données plutôt qu'à des événements individuels. Dans tout tableau de bord analytique, ce horodatage est indispensable pour que les utilisateurs comprennent la la réactualisation des données qu'ils consultent. Il donne l'assurance que les aperçus sont basés sur des informations récentes et aide à gérer les attentes des utilisateurs concernant la réactualisation des données. Il est généralement affiché clairement dans les dashboards.
Pourquoi est-ce important ? :
Informe les utilisateurs de la la réactualisation des données afin qu'ils sachent dans quelle mesure l'analyse des processus et les KPI sont à jour.
Source des données :
Cet horodatage est généré et stocké par le pipeline d'extraction et de chargement (ETL) lorsqu'il s'exécute.
Exemples
2023-11-01T05:00:00Z
|
|||
|
Système source
SourceSystem
|
Le système d'où les données du processus ont été extraites. | ||
|
Descriptionn
Cet attribut identifie le système d'information d'origine où les données d'événement ont été enregistrées. Pour ce processus, la valeur serait systématiquement « Coupa ». Dans les environnements d'entreprise où les données peuvent provenir de multiples systèmes (par exemple, Coupa pour l'approvisionnement, un autre ERP pour la facturation), cet attribut aide à différencier les sources de données. Il assure la clarté de la traçabilité des données et peut être utilisé pour filtrer l'analyse afin d'obtenir une vue du processus spécifique à un système.
Pourquoi est-ce important ? :
Elle apporte un contexte essentiel sur l'origine des données, garantit la traçabilité et facilite une bonne gouvernance des données, surtout dans des environnements multi-systèmes.
Source des données :
Il s'agit d'une valeur statique qui est généralement ajoutée durant le processus d'extraction et de transformation des données pour étiqueter le jeu de données.
Exemples
Coupa
|
|||
|
Catégorie d'achat
PurchaseCategory
|
La classification des biens ou services achetés, tels que le Matériel informatique ou les Services professionnels. | ||
|
Descriptionn
La catégorie d'achat, également appelée famille d'achats ou groupe de marchandises, est une classification utilisée pour regrouper des types d'achats similaires. Ces données structurées permettent d'analyser systématiquement les dépenses et les processus d'approvisionnement. En Process Mining, cet attribut est une dimension essentielle pour le filtrage et la segmentation. Le tableau de bord « Analyse des dépenses par catégorie d'achat » l'utilise pour ventiler les habitudes d'achat. Il permet aussi d'identifier si certaines catégories (ex : services complexes) ont des temps de cycle plus longs ou des taux de modification plus élevés que d'autres (ex : fournitures de bureau).
Pourquoi est-ce important ? :
Elle permet l'analyse des dépenses et du processus par catégorie, afin d'identifier les tendances d'achat, de négocier avec les fournisseurs et d'adapter les contrôles du processus.
Source des données :
Généralement trouvé au niveau des lignes du Bon de Commande dans Coupa, souvent lié à un code de marchandise ou à un catalogue d'achat.
Exemples
Matériel informatiqueFournitures de bureauServices professionnelsMatériel marketing
|
|||
|
Département
Department
|
Le service métier ou le centre de coûts auquel la commande d'achat est imputée. | ||
|
Descriptionn
L'attribut Département spécifie l'unité organisationnelle qui a initié l'achat ou qui en assumera le coût. Ceci est souvent lié au demandeur ou aux informations du centre de coûts sur les lignes de la commande d'achat. Cette dimension est indispensablele pour segmenter l'analyse de processus et les KPI. Elle permet aux responsables de comparer l'efficacité des processus, la conformité et les modèles de dépenses à travers les différentes parties de l'organisation. Par exemple, le tableau de bord 'Analyse des dépenses par catégorie d'achat' utilise Département pour montrer comment les différentes unités commerciales dépensent leurs budgets.
Pourquoi est-ce important ? :
Elle permet de filtrer et de comparer l'analyse des processus et des dépenses entre différentes entités, pour révéler les écarts d'efficacité et de conformité.
Source des données :
Disponible dans l'en-tête du bon de commande ou sur les lignes d'articles dans Coupa, souvent lié à un centre de coûts ou à une unité organisationnelle.
Exemples
MarketingTechnologies de l'InformationOpérationsFinance
|
|||
|
Montant total de la commande
TotalOrderAmount
|
La valeur monétaire totale du bon de commande. | ||
|
Descriptionn
Cet attribut représente le coût total de tous les biens et services spécifiés dans le bon de commande, exprimé dans une devise spécifique. C'est un attribut au niveau du cas qui s'applique à l'ensemble de la commande. Ces données financières sont cruciales pour l'analyse des dépenses et pour la priorisation des efforts d'amélioration des processus. Les commandes de grande valeur peuvent justifier une surveillance accrue ou des parcours d'approbation différents. Elles sont utilisées directement dans le tableau de bord 'Analyse des dépenses par catégorie d'achat' et sont un élément clé pour le calcul du KPI 'Ratio de dépenses avec des fournisseurs non privilégiés'.
Pourquoi est-ce important ? :
Fournit le contexte financier de chaque achat, permettant l'analyse des dépenses, la priorisation des commandes de grande valeur et l'évaluation de l'impact financier.
Source des données :
Disponible dans l'en-tête du bon de commande dans Coupa, généralement sous les libellés 'Total' ou 'Grand Total'.
Exemples
1500.00250.7512500.50
|
|||
|
Nom du fournisseur
VendorName
|
Le nom du fournisseur ou du vendeur auprès duquel les biens ou services sont achetés. | ||
|
Descriptionn
Le Nom du fournisseur identifie la partie externe fournissant les articles du bon de commande. Cette information est clée pour les analyses d'approvisionnement. L'analyse de la performance des processus par fournisseur est indispensablele pour la gestion des relations fournisseurs. Elle aide à évaluer la « Performance des délais fournisseurs », à identifier les retards dans les « Retards du processus de réception des marchandises » et à évaluer la qualité des fournisseurs via le « Taux de retour des marchandises ». Cet attribut est également essentiel pour calculer le KPI du « Ratio de dépenses par fournisseur non privilégié ».
Pourquoi est-ce important ? :
Permet l'analyse des performances des fournisseurs, aidant à optimiser la sélection des fournisseurs, à négocier de meilleures conditions et à identifier les fournisseurs très ou peu performants.
Source des données :
Un champ standard dans l'en-tête du bon de commande de Coupa, lié aux données de base du fournisseur.
Exemples
Global Office SuppliesTech Solutions Inc.Pièces industrielles avancéesCreative Marketing Agency
|
|||
|
Utilisateur
User
|
L'ID utilisateur ou le nom de la personne qui a effectué l'activité, tel qu'un approbateur ou un demandeur. | ||
|
Descriptionn
Cet attribut identifie l'individu responsable de l'exécution d'un événement spécifique dans le processus. Il peut s'agir de la personne qui a rédigé la commande, du manager qui l'a approuvée, ou de l'employé qui a enregistré la réception des marchandises. L'analyse de la performance par utilisateur aide à identifier les besoins en formation, les individus très performants et la répartition de la charge de travail. Par exemple, le tableau de bord « Performance du temps de cycle d'approbation des bons de commande » utilise cet attribut pour décomposer les temps d'approbation par approbateur spécifique, mettant en évidence qui peut constituer un goulot d'étranglement dans le processus.
Pourquoi est-ce important ? :
Elle permet d'analyser les performances du processus par personne ou par rôle, pour repérer les points de blocage, les besoins de formation et les problèmes d'allocation des ressources.
Source des données :
Associé à chaque événement dans le journal d'audit des bons de commande ou les journaux d'historique dans Coupa. Les champs tels que 'Created By', 'Approved By' ou 'Updated By' sont des sources courantes.
Exemples
j.doea.smithm.jones
|
|||
|
Approbation du premier passage
IsFirstPassApproval
|
Un indicateur calculé qui est vrai si la commande d'achat a été approuvée sans aucune modification après sa rédaction. | ||
|
Descriptionn
Cet indicateur booléen est défini à vrai si le parcours d'un bon de commande, de l'événement 'Bon de commande en brouillon' à l'événement 'Bon de commande approuvé', ne contient aucune activité 'Bon de commande modifié' ou 'Bon de commande rejeté' entre ces deux étapes. Cet attribut mesure directement le KPI 'Taux d'approbation des bons de commande du premier coup'. Un taux élevé indique un traitement initial efficace et précis. L'analyse des cas où cet indicateur est faux peut aider à découvrir les raisons des reprises et à améliorer la qualité des données initiales des bons de commande.
Pourquoi est-ce important ? :
Mesure directement l'efficacité du processus initial de création et d'approbation, soulignant le volume de commandes qui transitent sans reprises.
Source des données :
Calculé lors de la transformation des données en analysant la séquence d'événements pour chaque PurchaseOrderNumber.
Exemples
truefaux
|
|||
|
Date de livraison demandée
RequestedDeliveryDate
|
La date à laquelle le demandeur a demandé la livraison des biens ou services. | ||
|
Descriptionn
Cet attribut représente la date de livraison souhaitée, spécifiée par l'utilisateur métier durant le processus de demande d'achat. Il reflète l'attente de l'entreprise concernant la date d'exécution de la commande. Cette date est un repère essentiel pour mesurer la performance des fournisseurs et de l'entreprise en interne. Elle est directement utilisée pour calculer l'indicateur de performance (KPI) 'Adhérence à la date de livraison fournisseur' en la comparant à la date de réception des marchandises enregistrée. Le tableau de bord 'Écarts de date de livraison et retours' visualise les écarts entre cette date demandée et la livraison réelle, aidant ainsi à gérer les attentes et à améliorer les prévisions.
Pourquoi est-ce important ? :
Sert de référence de performance clé pour mesurer la paiement à temps des fournisseurs et l'efficacité du processus de réception interne.
Source des données :
Un champ standard sur la ligne d'article du bon de commande dans Coupa.
Exemples
2023-11-152023-12-012024-01-10
|
|||
|
Devise
Currency
|
Le code de devise pour les valeurs monétaires sur la commande d'achat. | ||
|
Descriptionn
Cet attribut spécifie la devise (ex: USD, EUR, GBP) dans laquelle le Montant total de la commande est exprimé. Il est indispensable pour interpréter correctement les données financières au sein d'une organisation mondiale. Pour les entreprises multinationales, analyser les dépenses sans tenir compte de la devise peut être trompeur. Cet attribut permet une conversion des devises appropriée et un reporting financier cohérent danss dashboards, garantissant ainsi que les valeurs sont comparées sur une base comparable.
Pourquoi est-ce important ? :
Assure une analyse financière et un reporting précis dans des contextes multinationaux en fournissant les informations nécessaires pour la conversion des devises.
Source des données :
Un champ standard dans l'en-tête du bon de commande de Coupa.
Exemples
USDEURGBPJPY
|
|||
|
Est un fournisseur privilégié
IsPreferredVendor
|
Un indicateur booléen signalant si l'achat a été effectué auprès d'un fournisseur privilégié ou stratégique. | ||
|
Descriptionn
Cet indicateur identifie si le fournisseur du bon de commande fait partie d'une liste pré-approuvée de fournisseurs stratégiques. Cela est généralement déterminé en recoupant le nom ou l'ID du fournisseur avec une liste maîtresse de fournisseurs privilégiés. Cet attribut est indispensable pour l'approvisionnement stratégique et les initiatives de gestion des dépenses. Il est utilisé pour calculer le KPI 'Ratio de dépenses avec des fournisseurs non privilégiés', ce qui aide les organisations à surveiller et contrôler les achats sauvages, et à consolider les dépenses avec des partenaires clés afin de utilisers remises sur volume et de meilleures conditions.
Pourquoi est-ce important ? :
Aide à surveiller la conformité aux politiques d'approvisionnement et les objectifs d'approvisionnement stratégique en suivant les dépenses avec les fournisseurs préférés par rapport aux non-préférés.
Source des données :
Il ne s'agit souvent pas d'un champ standard dans Coupa, mais cette information est dérivée en comparant l'ID du fournisseur sur le Bon de Commande avec une liste externe de fournisseurs privilégiés.
Exemples
truefaux
|
|||
|
Est un reprises
IsRework
|
Un indicateur calculé qui identifie si une commande d'achat a subi une activité de modification. | ||
|
Descriptionn
Cet indicateur booléen est défini à vrai pour tout bon de commande ayant au moins un événement 'Bon de commande modifié' dans son historique. C'est un attribut au niveau du cas dérivé du journal d'événements. Cet attribut simplifie le calcul de KPI tels que le 'Taux de modification des bons de commande'. Il permet un filtrage et une segmentation aisés des données pour comparer les processus des commandes avec et sans reprise, aidant à quantifier l'impact des changements sur le temps de cycle et les coûts. C'est un élément clé du tableau de bord 'Analyse des modifications de bons de commande'.
Pourquoi est-ce important ? :
Simplifie l'analyse du reprises en permettant un filtrage et une agrégation faciles pour toutes les commandes d'achat ayant été modifiées au moins une fois.
Source des données :
Calculé lors de la transformation des données en vérifiant l'existence d'une activité « Bon de commande modifié » pour chaque PurchaseOrderNumber.
Exemples
truefaux
|
|||
|
Lieu de Réception
ReceivingLocation
|
L'emplacement physique, tel qu'un entrepôt ou un bureau, où les biens doivent être livrés. | ||
|
Descriptionn
L'emplacement de réception spécifie la destination des biens commandés sur le bon de commande. Cela peut être un entrepôt, une usine ou une adresse de bureau spécifique. Cet attribut est utilisé pour analyser la performance logistique et de réception sur différents sites. Le tableau de bord « Retards du processus de réception des marchandises » peut être filtré par cet attribut pour déterminer si certains emplacements sont plus lents à traiter les livraisons entrantes, ce qui peut aider à identifier les inefficacités opérationnelles ou les contraintes de ressources sur des sites spécifiques.
Pourquoi est-ce important ? :
Permet une analyse basée sur la localisation du processus de réception, mettant en évidence les différences de performance entre les entrepôts, les usines ou les bureaux.
Source des données :
Cette information fait partie de l'adresse de livraison sur le bon de commande dans Coupa.
Exemples
Entrepôt A - ChicagoBâtiment 5 - Bureau de LondresUsine de Francfort
|
|||
|
Livraison dans les délais
IsDeliveryOnTime
|
Un indicateur calculé indiquant si les marchandises ont été reçues à la date de livraison demandée ou avant. | ||
|
Descriptionn
Cet attribut booléen est calculé en comparant l'horodatage de l'événement 'Réception des marchandises enregistrée' avec la RequestedDeliveryDate. Il est défini à vrai si la date de réception est égale ou antérieure à la date demandée. Cet indicateur contribue directement au KPI 'Adhérence à la date de livraison fournisseur' et au tableau de bord 'Écarts de date de livraison et retours'. Il fournit un résultat binaire clair pour le respect des délais qui est facile à agréger et à visualiser, aidant ainsi à identifier rapidement les problèmes de performance avec les fournisseurs ou les processus de réception internes.
Pourquoi est-ce important ? :
Fournit une métrique binaire claire pour la performance de livraison, simplifiant le calcul des KPI de paiement à temps et l'analyse des tendances.
Source des données :
Calculé lors de la transformation des données en comparant la date de livraison demandée (RequestedDeliveryDate) avec l'horodatage de l'activité « Réception de marchandises enregistrée ».
Exemples
truefaux
|
|||
|
Motif de refus
RejectionReason
|
La raison fournie lorsqu'une demande d'achat ou un bon de commande est rejeté lors d'une étape d'approbation. | ||
|
Descriptionn
Lorsqu'un approbateur rejette un bon de commande, il fournit souvent une raison de rejet. Cet attribut capture cette explication textuelle, telle que 'Code budgétaire incorrect' ou 'Dépasse la limite de dépenses'. L'analyse des raisons de rejet fournit un aperçu direct des causes profondes du reprises et des défaillances de processus. Ces données qualitatives peuvent être utilisées pour identifier les erreurs courantes dans le processus de demande d'achat, menant à des formations ciblées ou des améliorations de système pour prévenir les rejets futurs et améliorer le taux d'approbation dès la première soumission.
Pourquoi est-ce important ? :
Fournit des informations directes et exploitables sur les raisons du rejet des bons de commande, aidant à aborder les causes profondes du remaniement des processus et des retards.
Source des données :
Généralement capturé dans le champ de commentaires ou de notes associé à l'activité 'Bon de Commande Rejeté' ou 'Demande d'Achat Rejetée' dans le workflow d'approbation de Coupa.
Exemples
Demande en doubleBudget non approuvéSélection du mauvais fournisseur
|
|||
|
Motif du changement
ChangeReason
|
La raison fournie pour une modification apportée à un bon de commande après sa création initiale. | ||
|
Descriptionn
Cet attribut saisit la justification de la modification d'un bon de commande, par exemple, « Quantité mise à jour » ou « Correction de prix ». Cette information est souvent enregistrée dans la piste d'audit lorsqu'un utilisateur exécute une activité « Bon de commande modifié ». Comprendre pourquoi les commandes sont modifiées est indispensable pour le tableau de bord « Analyse des modifications de bons de commande ». Cela aide à différencier les changements inévitables (par exemple, les problèmes de stock fournisseur) des changements évitables (par exemple, une saisie de données initiale incorrecte), orientant les efforts pour améliorer la précision des commandes et réduire le KPI du « Taux de modification des bons de commande ».
Pourquoi est-ce important ? :
Explique les causes profondes des modifications des bons de commande, permettant des actions ciblées pour améliorer la précision des commandes dès la première fois et réduire les reprises du processus.
Source des données :
Souvent trouvé dans les journaux d'audit ou les commentaires associés aux événements de modification d'un bon de commande dans Coupa.
Exemples
Mise à jour des prix du fournisseurDate de livraison ajustéeCode d'article corrigé
|
|||
|
Nom du Demandeur
RequesterName
|
Le nom de la personne qui a initialement demandé les biens ou services. | ||
|
Descriptionn
Cet attribut identifie l'employé qui a créé la demande d'achat ayant mené au bon de commande. Le demandeur est l'utilisateur métier ayant le besoin, qui peut être différent de l'acheteur ou de l'approbateur. L'analyse du comportement du processus par demandeur permet d'identifier des modèles liés à des utilisateurs ou des départements spécifiques. Le tableau de bord « Analyse des modifications de bons de commande » l'utilise pour voir si certains demandeurs ont une fréquence plus élevée de modifications de commande, ce qui pourrait indiquer un besoin de meilleure formation sur les exigences de spécification.
Pourquoi est-ce important ? :
Aide à identifier l'origine commerciale d'un achat, permettant l'analyse du comportement d'achat et de la précision au niveau du demandeur.
Source des données :
Cette information est généralement stockée sur la demande d'achat source et reportée sur le bon de commande dans Coupa.
Exemples
Alice CooperBob DylanCharlie Parker
|
|||
|
Numéro de demande d'achat
PurchaseRequisitionNumber
|
L'identifiant unique de la demande d'achat qui a précédé le bon de commande. | ||
|
Descriptionn
Cet attribut relie un bon de commande à sa demande d'achat d'origine. Une seule demande d'achat peut donner lieu à un ou plusieurs bons de commande. Ce lien est indispensable pour l'analyse complète du temps de cycle 'De la demande à la commande'. En connectant l'événement de création de la demande d'achat aux événements de création et d'envoi du bon de commande, les organisations peuvent mesurer l'efficacité de l'ensemble de leur processus d'initiation des achats, de la demande à l'exécution.
Pourquoi est-ce important ? :
Elle relie les phases de demande et de commande, ce qui permet d'analyser le temps de cycle de la demande à la commande et les taux de conversion.
Source des données :
Il s'agit généralement d'un champ de référence sur les lignes de Bon de Commande dans Coupa, renvoyant à la demande d'achat d'origine.
Exemples
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
De l'achat au paiement - Activités des bons de commande
| Activité | Descriptionn | ||
|---|---|---|---|
|
Bon de commande annulé
|
Cette activité représente l'annulation d'un bon de commande avant sa finalisation. Une annulation peut survenir à diverses étapes, par exemple, si la demande n'est plus valide ou si le bon de commande a été créé par erreur. | ||
|
Pourquoi est-ce important ? :
En tant que fin de processus alternative, le suivi des annulations est important pour comprendre les défaillances du processus et identifier les raisons des demandes d'achat abandonnées.
Source des données :
Ceci est déduit d'un changement de statut sur l'objet Bon de commande à 'Annulé'. L'horodatage de ce changement de statut est utilisé comme temps d'événement.
Capture
Dérivé de l'horodatage du changement de statut à « Annulé ».
Type d'événement
inferred
|
|||
|
Bon de commande envoyé au fournisseur
|
Cette activité marque le moment où le bon de commande approuvé est officiellement transmis au fournisseur, par exemple, par e-mail ou via le Portail Fournisseur Coupa. Cet événement fait passer le bon de commande d'un document interne à un engagement externe. | ||
|
Pourquoi est-ce important ? :
Ceci est un jalon clé qui conclut le cycle interne 'De la demande à la commande' et débute le délai fournisseur. Il est indispensable à mesurer à la fois l'efficacité interne et la performance des fournisseurs.
Source des données :
Souvent déduit d'un changement de statut du bon de commande à 'Commandé' ou 'Envoyé'. Coupa peut également avoir un horodatage spécifique 'last_exported_at' ou 'sent_to_supplier_at' dans l'enregistrement du bon de commande.
Capture
Dérivé de l'horodatage du changement de statut à « Commandé » ou d'un champ d'horodatage de transmission spécifique.
Type d'événement
inferred
|
|||
|
Commande d'achat approuvée
|
Ce jalon signifie que le bon de commande a terminé son workflow d'approbation interne et est autorisé à être émis au fournisseur. Il s'agit généralement de l'étape d'approbation finale d'un processus en plusieurs étapes. | ||
|
Pourquoi est-ce important ? :
Ceci est un jalon critique pour le calcul des temps de cycle d'approbation des bons de commande et l'identification des points de blocage d'approbation. Il sert également de point de contrôle essentiel pour la conformité.
Source des données :
Capturé à partir du journal d'historique d'approbation du bon de commande dans Coupa. L'horodatage de l'action d'approbation finale fournit l'heure de l'événement.
Capture
Comptabilisé dans l'historique des approbations lorsque l'approbateur final termine sa tâche.
Type d'événement
explicit
|
|||
|
Commande d'achat clôturée
|
C'est l'activité finale, signalant que le bon de commande est complet. Le Bon de Commande est considéré comme clos lorsqu'il a été entièrement réceptionné et facturé, et qu'aucune autre transaction n'est prévue. | ||
|
Pourquoi est-ce important ? :
Cette activité met officiellement fin au cycle de vie du bon de commande. L'analyse du temps de clôture peut révéler des inefficacités dans la réconciliation finale et la tenue des registres.
Source des données :
Cette information est déduite d'un changement de statut de l'objet Bon de Commande à 'Fermé'. Ce statut est souvent défini automatiquement par Coupa, selon des règles métier liées aux tolérances de réception et de facturation.
Capture
Dérivé de l'horodatage du changement de statut à « Clôturé ».
Type d'événement
inferred
|
|||
|
Demande d'achat créée
|
Cette activité marque la création d'une demande d'achat, qui est la requête formelle de biens ou services précédant un bon de commande. Dans Coupa, il s'agit d'un événement explicite capturé lorsqu'un utilisateur enregistre et soumet un nouveau document de demande. | ||
|
Pourquoi est-ce important ? :
En tant que point de départ typique du processus d'approvisionnement, cette activité est indispensablele pour mesurer le temps de cycle complet de la demande à la commande et comprendre l'efficacité du processus en amont.
Source des données :
Cet événement correspond à l'enregistrement de création dans l'objet ou la table des Demandes d'achat dans Coupa. L'horodatage peut être trouvé dans le champ 'created_at' ou un champ de date de création équivalent généré par le système.
Capture
Comptabilisé directement lors de la création d'un nouveau dossier de demande.
Type d'événement
explicit
|
|||
|
Réception de marchandises enregistrée
|
C'est la confirmation formelle que les marchandises ont été reçues, inspectées et acceptées. Cet événement met à jour les registres d'inventaire « what-if »gnale que l'obligation du fournisseur pour cette livraison a été remplie. | ||
|
Pourquoi est-ce important ? :
Ce jalon critique marque la fin du délai fournisseur et est utilisé pour mesurer l'adhérence à la date de livraison. Les retards dans l'enregistrement des réceptions peuvent masquer la visibilité sur les niveaux de stock réels.
Source des données :
Ceci est une transaction clé dans Coupa, enregistrée sur l'objet Réception. L'événement est capturé à partir du horodatage lorsque le statut de la réception devient 'Comptabilisée' ou 'Reçue'.
Capture
Comptabilisé lorsque la transaction de réception de marchandises est finalisée dans le système.
Type d'événement
explicit
|
|||
|
Bon de commande en brouillon
|
Cet événement représente la création initiale du document de bon de commande dans le système, souvent à partir d'une demande d'achat approuvée. À ce stade, le bon de commande est un brouillon interne et n'a pas encore été soumis pour approbation ou envoyé au fournisseur. | ||
|
Pourquoi est-ce important ? :
Cette activité déclenche le chronomètre pour mesurer le KPI du temps de cycle d'approbation des bons de commande. C'est la première étape formelle du cycle de vie propre au bon de commande.
Source des données :
Ceci correspond au horodatage de création de l'enregistrement du bon de commande dans Coupa, que l'on trouve généralement dans un champ tel que 'created_at'.
Capture
Capturé à partir de l'horodatage de création du BC généré par le système.
Type d'événement
explicit
|
|||
|
Commande confirmée par le fournisseur
|
Cet événement signifie que le fournisseur a reçu et confirmé le bon de commande. Cette confirmation est souvent capturée électroniquement via un portail fournisseur comme le Coupa Supplier Portal (CSP). | ||
|
Pourquoi est-ce important ? :
Les accusés de réception des fournisseurs apportent la certitude qu'une commande est en cours de traitement, améliorant ainsi la précision des prévisions de livraison et réduisant l'incertitude de la chaîne d'approvisionnement.
Source des données :
Cette information est généralement disponible sur le bon de commande si le fournisseur utilise le Coupa Supplier Portal pour effectuer une action d'accusé de réception. L'horodatage de cette action est utilisé.
Capture
Comptabilisé lorsque le fournisseur effectue l'action 'Acknowledge' dans le portail fournisseurs.
Type d'événement
explicit
|
|||
|
Commande d'achat modifiée
|
Cet événement représente toute modification apportée au bon de commande après sa rédaction initiale. Dans Coupa, les modifications sont souvent suivies via le versionnement du document de bon de commande. | ||
|
Pourquoi est-ce important ? :
Le suivi des modifications est impératif pour des KPI tels que le Taux de modification des Bons de Commande et le Taux de Bons de Commande non conformes. Des changements fréquents indiquent une instabilité du processus ou des demandes initiales inexactes.
Source des données :
Peut être déduit en suivant les différentes versions d'un bon de commande. Chaque nouveau numéro de version supérieur au premier indique un changement, la date de création de la nouvelle version servant d'horodatage de l'événement.
Capture
Déduit de l'horodatage de création d'une nouvelle version du bon de commande.
Type d'événement
inferred
|
|||
|
Commande d'achat rejetée
|
Cette activité se produit lorsqu'un approbateur rejette le bon de commande pendant le workflow d'approbation. Le bon de commande est alors généralement renvoyé au créateur pour révision ou annulation. | ||
|
Pourquoi est-ce important ? :
L'analyse des rejets permet de découvrir les problèmes liés à la qualité des données, aux violations de politiques ou aux lacunes en matière de formation. Elle met en évidence les cycles de reprises qui entraînent des retards de processus importants.
Source des données :
Ceci est un événement explicite capturé dans le journal d'historique d'approbation du bon de commande dans Coupa. Le journal affichera une action de 'Rejet' avec un horodatage correspondant.
Capture
Comptabilisé dans l'historique des approbations avec le statut 'Reject'.
Type d'événement
explicit
|
|||
|
Commande d'achat soumise
|
Après l'établissement d'un bon de commande, celui-ci est formellement soumis au workflow d'approbation. Il s'agit d'une action utilisateur distincte qui fait passer le BC d'un état de brouillon à un état d'approbation en attente. | ||
|
Pourquoi est-ce important ? :
Cet événement distingue le temps de rédaction du moment où le bon de commande est réellement en attente d'approbation. Il fournit une image plus claire du comportement de l'utilisateur et des transferts de processus.
Source des données :
Déduit d'un changement de statut sur l'objet Bon de commande, par exemple de 'draft' à 'pending approval'. L'horodatage de ce changement précis est utilisé.
Capture
Dérivé de l'horodatage du changement de statut à « en attente d'approbation ».
Type d'événement
inferred
|
|||
|
Confirmation des Services Saisie
|
Pour les bons de commande basés sur des services, cette activité est l'équivalent d'une réception de marchandises. Elle confirme qu'un service a été rendu conformément aux termes du bon de commande. | ||
|
Pourquoi est-ce important ? :
Le suivi des confirmations de service est impératif pour gérer les dépenses de services et s'assurer que les paiements ne sont effectués que pour les travaux dont l'achèvement a été vérifié.
Source des données :
Cet événement est capturé à partir de la création ou de l'approbation d'un accusé de réception de service ou d'une feuille de saisie de services liés au bon de commande dans Coupa.
Capture
Comptabilisé lors de la création et de l'approbation d'une feuille de saisie de services.
Type d'événement
explicit
|
|||
|
Demande d'achat approuvée
|
Une demande d'achat passe par un workflow d'approbation avant de pouvoir être convertie en commande d'achat. Cet événement signifie l'approbation finale de la demande, la rendant prête pour la commande. | ||
|
Pourquoi est-ce important ? :
Le suivi des approbations de demande d'achat permet d'identifier les points de blocage dans la phase de prélèvement.-commande. Les retards à ce stade impactent directement la rapidité d'émission d'un bon de commande.
Source des données :
Cette information est généralement capturée à partir de l'historique d'approbation de la demande d'achat dans Coupa. L'action d'approbation finale aura un horodatage et un utilisateur associés.
Capture
Comptabilisé dans l'historique des approbations lorsque l'approbateur final intervient.
Type d'événement
explicit
|
|||
|
Facture reçue pour le bon de commande
|
Cet événement marque la réception et l'enregistrement d'une facture fournisseur qui référence le bon de commande. Il signifie le début de la phase de traitement et de paiement des factures du cycle Purchase-to-Pay. | ||
|
Pourquoi est-ce important ? :
Bien que faisant partie du processus de comptabilité fournisseurs, le lien entre la réception de la facture et le bon de commande offre une vue complet du cycle de vie de la transaction et aide à analyser l'écart entre la livraison et la facturation.
Source des données :
Capturé à partir de l'horodatage de création du document de facture dans Coupa, où la facture est mise en correspondance avec le numéro de bon de commande correspondant.
Capture
Comptabilisé lors de la création d'un enregistrement de facture lié au bon de commande.
Type d'événement
explicit
|
|||
|
Inspection qualité effectuée
|
Cet événement indique qu'un article reçu a subi et réussi une inspection qualité. Cela peut être une étape distincte après l'enregistrement initial de la réception des marchandises, selon le processus de l'entreprise. | ||
|
Pourquoi est-ce important ? :
Cette activité est indispensablele pour mesurer l'efficacité du processus de contrôle qualité. Des retards à ce stade peuvent créer des points de blocage entre la réception et la disponibilité pour utilisation.
Source des données :
Cela peut être enregistré comme un changement de statut sur la ligne de réception ou via un objet d'inspection distinct dans Coupa. Sa disponibilité dépend de l'utilisation d'un module de qualité ou d'un workflow personnalisé.
Capture
Déduit d'un changement de statut sur la réception ou d'un horodatage dans un enregistrement d'inspection lié.
Type d'événement
inferred
|
|||
|
Marchandises retournées
|
Cette activité est enregistrée lorsque des marchandises précédemment reçues sont renvoyées au fournisseur. Cela est généralement dû à des problèmes de qualité, des dommages ou des livraisons incorrectes. | ||
|
Pourquoi est-ce important ? :
Le suivi des retours est indispensable pour calculer le Taux de retour des marchandises et identifier les problèmes liés à la qualité des fournisseurs ou à l'exactitude des commandes. Des taux de retour élevés indiquent souvent des défaillances coûteuses du processus.
Source des données :
Ceci est capturé à partir d'une transaction 'Retour au fournisseur' ou d'une transaction de réception négative dans Coupa. L'horodatage de cette transaction sert de temps d'événement.
Capture
Comptabilisé lorsqu'une transaction de retour liée au bon de commande ou à la réception d'origine est créée.
Type d'événement
explicit
|
|||
|
Réception de marchandises initiée
|
Cette activité représente le début du processus de réception, par exemple lorsqu'un document de réception est créé dans Coupa dès l'arrivée physique des marchandises. Les marchandises n'ont pas encore été officiellement enregistrées dans l'inventaire ni confirmées comme reçues. | ||
|
Pourquoi est-ce important ? :
Cet événement est le point de départ pour mesurer le KPI 'Temps de traitement de la réception des marchandises'. Il aide à différencier le temps d'attente des marchandises sur le quai du temps passé au traitement système.
Source des données :
Cela peut être déduit du horodatage de création d'un document de réception en statut 'Brouillon' ou 'En attente'. Il précède l'enregistrement final de la réception.
Capture
Dérivé de l'horodatage de création d'un enregistrement de reçu dans un état non validé.
Type d'événement
inferred
|
|||