Votre modèle de données pour le processus Achat au Paiement - Bon de Commande

SAP ECC
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

Ce modèle vous guide à travers les données clés nécessaires pour analyser votre processus « De l'achat au paiement » - Commande d'achat dans SAP ECC. Il décrit les attributs essentiels à collecter, les activités clés à suivre, et fournit des conseils pratiques sur la façon d'extraire ces informations de votre système. Utilisez cette ressource pour générer un journal d'événements fiable pour vos initiatives de Process Mining.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Directives d'extraction pour SAP ECC
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

De l'achat au paiement - Attributs des bons de commande

Ce sont les champs de données essentiels recommandés pour l'inclusion dans votre journal d'événements, pour une analyse complète de votre processus d'achat au paiement - commande d'achat.
3 Obligatoire 6 Recommandé 12 Facultatif
Nom Descriptionn
Activité
Activity
Le nom de l'événement métier ou de l'étape spécifique qui s'est produit dans le cycle de vie de la commande d'achat.
Descriptionn

Cet attribut décrit une seule étape du processus, telle que 'Commande d'achat créée', 'Commande d'achat approuvée' ou 'Réception de marchandises enregistrée'. La séquence de ces activités forme le flux de processus pour chaque commande d'achat.

L'analyse de la séquence, de la fréquence et de la durée entre les activités est l'essence du Process Mining. Elle aide à identifier les points de blocage, les boucles de reprise et les écarts par rapport au processus standard, permettant des améliorations ciblées et des efforts de standardisation.

Pourquoi est-ce important ? :

Les Activités définissent les étapes du processus. L'analyse de leur séquence et de leur déroulement temporel révèle le flux de processus réel, les points de blocage et les écarts.

Source des données :

Dérivé de diverses tables SAP et journaux de transactions, tels que CDHDR/CDPOS pour les modifications, EKBE pour la GR/IR et EBAN pour les demandes. Nécessite souvent une logique personnalisée ou un programme d'extraction pour être généré.

Exemples
Commande d'achat crééeCommande d'achat approuvéeRéception de marchandises enregistrée
Bon de commande
PurchaseOrder
L'identifiant unique pour le document de Commande d'achat (PO), servant de cas principal pour le suivi du processus d'approvisionnement.
Descriptionn

Le numéro de commande d'achat est l'identifiant central qui relie toutes les activités de sa création à la réception finale des marchandises et à son achèvement. Chaque numéro de commande d'achat unique représente une instance unique du processus d'approvisionnement.

En Process Mining, cet attribut est indispensable pour reconstruire le parcours complet de chaque achat. Il permet une analyse détaillée des temps de cycle, des variations de processus, et des vérifications de conformité pour chaque commande individuelle, formant ainsi la fondation de l'ensemble du modèle de processus.

Pourquoi est-ce important ? :

Il s'agit de l'identifiant principal qui relie tous les événements associés, permettant ainsi d'analyser le cycle de vie complet de chaque commande d'achat individuelle.

Source des données :

Table: EKKO, Champ : EBELN

Exemples
450001762345000176244500017625
Heure de l'événement
EventTime
La date et l'heure précises auxquelles l'activité s'est produite.
Descriptionn

Ce horodatage marque le moment exact où un event a eu lieu, comme l'heure à laquelle une commande d'achat a été approuvée ou une réception de marchandises a été enregistrée. Elle fournit l'ordre chronologique de toutes les activités au sein d'un cas.

Les horodatages sont fondamentaux pour le Process Mining car ils permettent toutes les analyses temporelles. Cela inclut le calcul des temps de cycle entre les activités, l'identification des retards, l'analyse du débit du processus et la mesure de la performance par rapport aux accords de niveau de service (SLA).

Pourquoi est-ce important ? :

Ce horodatage est indispensable pour calculer toutes les métriques basées sur la durée, telles que les temps de cycle et les points de blocage, et pour ordonner les événements chronologiquement.

Source des données :

Dérivé de divers champs de date et d'heure dans les tables SAP, tels que EKKO-AEDAT (Date de modification), CDHDR-UDATE/UTIME (Horodatage du journal des modifications) ou EKBE-BUDAT (Date de comptabilisation).

Exemples
2023-04-15T10:05:31Z2023-04-16T14:22:00Z2023-05-01T09:00:15Z
Code société
CompanyCode
L'identifiant de l'entité juridique ou de l'entreprise qui initie l'achat.
Descriptionn

Le Code société représente une entité juridique indépendante dans SAP. Toutes les transactions sont enregistrées au niveau du code société, ce qui en fait une unité organisationnelle clée.

L'analyse du processus par Code société permet de comparer l'efficacité de l'approvisionnement et la conformité entre différentes unités commerciales ou pays. Elle aide à identifier les bonnes pratiques dans une entité qui pourraient être reproduites ailleurs, ou à cibler des unités spécifiques rencontrant des difficultés avec le processus.

Pourquoi est-ce important ? :

Représente l'entité juridique, permettant de comparer les performances des processus et d'effectuer des contrôles de conformité entre les différentes parties de l'organisation.

Source des données :

Table: EKKO, Champ : BUKRS

Exemples
10002100US01
Groupe de matériaux
MaterialGroup
Une classification pour regrouper des matériaux ou des services aux caractéristiques similaires.
Descriptionn

Le Groupe de marchandises, ou catégorie d'achat, est utilisé pour classifier le type de biens ou services achetés. Les exemples incluent 'Matériel informatique', 'Fournitures de bureau' ou 'Services professionnels'.

Cet attribut est impératif pour l'analyse des dépenses et la compréhension des modèles d'approvisionnement. Il permet de filtrer le processus pour analyser comment les différentes catégories sont gérées, qui les approuve, et quels fournisseurs les approvisionnent. C'est une dimension clé du tableau de bord 'Analyse de la valeur des commandes d'achat'.

Pourquoi est-ce important ? :

Permet de segmenter le processus par catégorie de produit ou de service, révélant différents comportements, temps de cycle ou fournisseurs pour différents types de dépenses.

Source des données :

Table: EKPO, Champ : MATKL

Exemples
00101IT_HWCONSULT
Montant de la commande
OrderAmount
La valeur monétaire totale du poste de la commande d'achat.
Descriptionn

Cet attribut représente la valeur totale d'un poste spécifique sur la commande d'achat, calculée comme la quantité multipliée par le prix net. Pour une valeur complète de commande d'achat, les montants des postes doivent être agrégés.

L'analyse du processus par montant de commande est indispensable pour identifier les transactions de grande valeur qui peuvent nécessiter des contrôles plus stricts ou des chemins d'approbation différents. Il alimente le tableau de bord 'Analyse de la valeur des commandes d'achat' et aide à prioriser les efforts d'amélioration des processus sur les commandes les plus financièrement importantes.

Pourquoi est-ce important ? :

Quantifie l'impact financier de chaque achat, permettant une analyse basée sur la valeur pour prioriser les commandes à forte valeur ou identifier les opportunités d'économies.

Source des données :

Table: EKPO, Champ : NETWR (Valeur nette de la commande).

Exemples
1500.00250.7512345.50
Nom d'utilisateur
UserName
L'ID utilisateur de la personne ayant exécuté l'activité.
Descriptionn

Cet attribut capture le nom d'utilisateur SAP de l'employé qui a créé, modifié ou approuvé un document. Pour les étapes automatisées, il peut afficher un identifiant d'utilisateur système ou de traitement par lots.

L'analyse par utilisateur aide à identifier les besoins en formation, les individus les plus performants ou d'éventuels problèmes de conformité. Elle est indispensablele pour créer des dashboards permettant d'analyser la répartition de la charge de travail, la conformité de la matrice d'approbation et les performances des différentes équipes ou individus.

Pourquoi est-ce important ? :

Attribue les actions des utilisateurs à des individus spécifiques, permettant l'analyse des performances des utilisateurs, de la charge de travail et du respect des protocoles de Conformité.

Source des données :

Table: EKKO, Champ : ERNAM (Créé par) ; Table: CDHDR, Champ : USERNAME (Modifié par).

Exemples
JSMITHMBROWNBATCH_USER
Numéro de fournisseur
VendorNumber
L'identifiant unique du fournisseur.
Descriptionn

Il s'agit du code qui identifie de manière unique le fournisseur auprès duquel les biens ou services sont acquis. C'est un élément essentiel de données de base dans le processus d'approvisionnement.

Cet attribut est impératif pour l'analyse centrée sur les fournisseurs. Il permet d'évaluer la performance de livraison des fournisseurs, de comparer les délais entre les différents prestataires et d'analyser les habitudes de dépenses. C'est la dimension principale du tableau de bord 'Vendor Delivery Performance'.

Pourquoi est-ce important ? :

Permet l'analyse des performances des fournisseurs, aidant à identifier les fournisseurs fiables et ceux qui causent des retards ou des problèmes de qualité.

Source des données :

Table: EKKO, Champ : LIFNR

Exemples
100345V-20598700112
Type de document
DocumentType
Un code qui classe les différents types de commandes d'achat.
Descriptionn

Le Type de document est une configuration dans SAP qui contrôle la plage de numéros, la sélection des champs et le flux de processus global pour une commande d'achat. Par exemple, il peut exister différents types pour les commandes d'achat standard, les commandes de services ou les ordres de transfert de stock.

Cet attribut est une dimension d'analyse puissante, car les différents types de document suivent souvent des processus intentionnellement distincts. Le filtrage par type de document permet une comparaison plus précise et équitable des temps de cycle et des flux de processus.

Pourquoi est-ce important ? :

Distingue entre différents types de processus d'achat (par exemple, standard, service, retour), qui ont souvent des chemins distincts et des attentes de performances différentes.

Source des données :

Table: EKKO, Champ : BSART

Exemples
NBFOUB
Date de livraison demandée
RequestedDeliveryDate
La date à laquelle l'entreprise a demandé au fournisseur de livrer les biens ou services.
Descriptionn

Il s'agit de la date de livraison cible spécifiée dans la commande d'achat. Elle sert de référence pour mesurer la performance de livraison réelle.

Cette date est indispensablele pour calculer le KPI du « Taux de réception de marchandises à temps ». En comparant la date de réception de marchandises réelle à cette date demandée, les organisations peuvent mesurer quantitativement la fiabilité des fournisseurs et l'efficacité de la réception interne, ce qui contribue directement au le tableau de bord 'Vendor Delivery Performance'.

Pourquoi est-ce important ? :

Il s'agit de la date cible de livraison, essentielle pour le calcul des KPI de respect des délais et l'évaluation de la fiabilité des fournisseurs.

Source des données :

Table: EKPO, Champ : EINDT

Exemples
2023-06-102023-07-222023-08-01
Demande d'achat
PurchaseRequisition
L'identifiant de la demande d'achat qui a précédé la commande d'achat.
Descriptionn

Cet attribut relie la commande d'achat à sa demande d'achat d'origine. Toutes les commandes d'achat n'auront pas de demande prélèvement.alable.

Ce lien est indispensable pour l'analyse du tableau de bord 'Conversion de la demande à la commande' et du KPI 'Taux de conversion PR vers PO'. Il permet de mesurer l'efficacité du processus en amont, de la demande initiale à la création d'une commande formelle, et d'identifier les commandes d'achat non conformes créées sans demande.

Pourquoi est-ce important ? :

Relie le bon de commande à sa demande d'origine, permettant d'analyser le processus de conversion de la demande d'achat en bon de commande et d'identifier les bons de commande créés sans demande prélèvement.alable.

Source des données :

Table: EKPO, Champ : BANFN

Exemples
1001589010015891
Dernière mise à jour des données
LastDataUpdate
L'horodatage indiquant la dernière actualisation des données depuis le système source.
Descriptionn

Cet attribut consigne la date et l'heure de la dernière extraction ou mise à jour des données. Il fournit un contexte sur la la réactualisation des données analysées.

L'affichage de ces informations dans les dashboards est indispensable à que les utilisateurs comprennent si les informations sont basées sur des données quasi-temps réel ou sur un instantané historique. Il gère les attentes des utilisateurs et garantit que les décisions sont prises sur la base de données d'un âge connu.

Pourquoi est-ce important ? :

Informe les utilisateurs sur la pertinence des données, s'assurant qu'ils comprennent si l'analyse reflète l'état le plus actuel des opérations.

Source des données :

Ce horodatage est généré et ajouté par le processus d'extraction de données ou ETL au moment de l'exécution.

Exemples
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Devise
Currency
Le code de devise pour le montant de la commande d'achat.
Descriptionn

Cet attribut spécifie la devise dans laquelle la valeur de la commande d'achat est libellée, telle que USD, EUR ou GBP. Il fournit un contexte essentiel pour toutes les valeurs monétaires.

Pour les organisations mondiales, la devise est indispensablele pour une analyse financière correcte. Elle permet une agrégation et une comparaison appropriées des valeurs de commande, et tous les KPI monétaires doivent être interprétés dans le contexte de leur devise.

Pourquoi est-ce important ? :

Fournit le contexte nécessaire pour toutes les valeurs monétaires, garantissant une analyse financière précise, en particulier dans les organisations multinationales.

Source des données :

Table: EKKO, Champ : WAERS

Exemples
USDEURJPY
Est-ce un changement post-approbation
IsPostApprovalChange
Un indicateur signalant si une modification de la commande d'achat (PO) est survenue après l'approbation initiale.
Descriptionn

Cet attribut booléen est vrai si une activité 'Commande d'achat modifiée' est détectée après une activité 'Commande d'achat approuvée' pour la même commande d'achat. Il aide à isoler les modifications problématiques qui surviennent tard dans le processus.

Ce champ calculé alimente directement le KPI 'Taux de modification des commandes d'achat post-approbation' et le tableau de bord 'Retravail et modifications des commandes d'achat'. Il aide à quantifier et à mettre en évidence les changements perturbateurs qui peuvent entraîner des retards et nécessiter une nouvelle approbation, pointant vers des problèmes dans le processus de spécification ou de définition initial.

Pourquoi est-ce important ? :

Mesure directement les reprises après approbation, un KPI clé pour la stabilité et l'efficacité des processus. Des taux élevés indiquent des problèmes dans la définition des exigences en amont.

Source des données :

Il s'agit d'un attribut calculé dérivé de la séquence des activités dans le journal d'événements.

Exemples
truefaux
Groupe d'Achats
PurchasingGroup
L'acheteur spécifique ou le groupe d'acheteurs responsable de l'activité d'approvisionnement.
Descriptionn

Le Groupe d'achats représente l'individu ou l'équipe d'acheteurs responsable d'une certaine activité d'achat. Ils sont le principal point de contact pour les fournisseurs.

Cet attribut offre un niveau d'analyse plus granulairesre que l'Organisation d'achats. Il aide à comprendre la répartition de la charge de travail parmi les acheteurs et à identifier les différences de performance au niveau de l'acheteur, ce qui peut éclairer l'allocation des ressources et les initiatives de formation.

Pourquoi est-ce important ? :

Offre une vue granulaire de la personne responsable d'un achat, permettant une analyse détaillée de la charge de travail et de la performance au niveau de l'acheteur ou de l'équipe.

Source des données :

Table: EKKO, Champ : EKGRP

Exemples
001002N01
Livraison à temps
IsOnTimeDelivery
Un indicateur signalant si les marchandises ont été reçues à la date de livraison demandée ou avant.
Descriptionn

Cet attribut booléen est vrai si l'horodatage de l'activité 'Réception de marchandises enregistrée' est à la date ou avant la 'Date de livraison demandée'. Il fournit un résultat clair et binaire pour la performance de livraison sur chaque poste de commande d'achat.

Cet attribut est la base du KPI 'Taux de réception de marchandises à temps'. Il simplifie l'analyse de la performance des fournisseurs et de l'efficacité de la réception interne en permettant une agrégation et un filtrage faciles des livraisons à temps ou en retard.

Pourquoi est-ce important ? :

Fournit un indicateur clair de succès ou d'échec pour la ponctualité des livraisons, soutenant directement les KPI de performance des fournisseurs et les dashboards.

Source des données :

Il s'agit d'un attribut calculé, obtenu en comparant la date d'enregistrement de la réception de marchandises (EKBE-BUDAT) avec la date de livraison demandée (EKPO-EINDT).

Exemples
truefaux
Motif de refus
RejectionReason
Le code motif ou le texte expliquant pourquoi une demande ou commande d'achat a été rejetée.
Descriptionn

Cet attribut capture la raison spécifique fournie lorsqu'une commande d'achat est rejetée pendant le workflow d'approbation. Cette information est indispensablele pour comprendre les causes profondes du retrabail et des retards.

L'analyse des raisons de rejet aide à identifier les problèmes courants tels qu'une tarification incorrecte, des dépassements de budget ou une sélection de fournisseur non conforme. Ces informationsns permettent à l'entreprise de s'attaquer aux causes profondes, d'améliorer la qualité de la création initiale des commandes d'achat et de rationaliser le processus d'approbation.

Pourquoi est-ce important ? :

Fournit un aperçu direct des raisons pour lesquelles les approbations échouent, permettant des améliorations ciblées pour réduire les reprises et raccourcir les temps de cycle d'approbation.

Source des données :

Ces informationsns peuvent être difficiles à localiser. Elles peuvent être stockées dans des champs de texte long ou dépendre d'une configuration de workflow personnalisée. Cela nécessite souvent une connaissance spécifique de l'implémentation.

Exemples
Prix incorrectBudget dépasséDemande en double
Nom du fournisseur
VendorName
La raison sociale du fournisseur.
Descriptionn

Le nom descriptif du fournisseur, plus convivial que le numéro de fournisseur. Il provient généralement des données de base fournisseur.

Bien que le Numéro de fournisseur soit utilisé pour les jointures et l'identification unique, le Nom du fournisseur est impératif pour les dashboards et les rapports destinés aux utilisateurs. Il rend les analyses plus intuitives et accessibles aux utilisateurs métiers qui ne sont pas familiers avec les codes fournisseur.

Pourquoi est-ce important ? :

Fournit un nom de fournisseur compréhensible par l'utilisateur, rendant les dashboards et les rapports beaucoup plus faciles à comprendre pour les utilisateurs métiers.

Source des données :

Table: LFA1, Champ : NAME1. Cela nécessite une jointure de EKKO-LIFNR à LFA1-LIFNR.

Exemples
Staples Inc.Global Tech SolutionsSociété de fournitures de bureau
Organisation d'Achats
PurchasingOrganization
L'unité organisationnelle responsable de la négociation des prix et de l'acquisition des matériaux ou des services.
Descriptionn

L'Organisation d'achats est une unité organisationnelle clé dans SAP responsable des activités d'approvisionnement. Elle peut être centralisée pour l'ensemble de l'entreprise ou décentralisée par établissement ou région.

L'analyse de la performance du processus par Organisation d'achats aide à identifier quelles équipes d'approvisionnement sont les plus efficaces. Elle permet de comparer des indicateurs tels que le temps de cycle, les taux de retouches et les coûts entre différentes unités organisationnelles, en soulignant les bonnes pratiques et les domaines nécessitant un soutien.

Pourquoi est-ce important ? :

Identifie l'équipe d'approvisionnement responsable, permettant des comparaisons de performance et des analyses entre les différentes unités organisationnelles.

Source des données :

Table: EKKO, Champ : EKORG

Exemples
1000US01DE01
Système source
SourceSystem
Le système d'où les données ont été extraites.
Descriptionn

Cet attribut identifie l'origine des données, qui est généralement un identifiant d'instance SAP ECC (par exemple, 'ECC_PROD_100'). Dans les environnements multi-systèmes, il aide à différencier les sources de données.

Pour la gouvernance et la traçabilité des données, connaître le système source est impératif. Il assure l'intégrité des données et aide à la résolution des problèmes d'extraction ou de qualité des données, surtout lorsque les données sont fusionnées à partir de différents systèmes ou modules ERP.

Pourquoi est-ce important ? :

Identifie l'origine des données, ce qui est impératif pour la gouvernance des données, la validation et la gestion des analyses sur plusieurs systèmes.

Source des données :

Il s'agit typiquement d'une valeur statique ajoutée pendant le processus d'extraction de données pour étiqueter l'ensemble de données avec son système d'origine.

Exemples
SAP_ECC_PRODECC_EU_100S4H_FIN
Usine
Plant
L'emplacement physique ou l'usine où les marchandises doivent être livrées.
Descriptionn

L'Établissement est une unité organisationnelle représentant une installation de production, un entrepôt ou un autre emplacement où les biens ou services sont réceptionnés.

L'analyse par Établissement aide à comprendre les variations géographiques dans le processus d'approvisionnement. Elle peut révéler des différences dans les délais de livraison des fournisseurs à certains emplacements ou mettre en évidence des établissements spécifiques ayant des processus de réception inefficaces, soutenant ainsi l'analyse de la ponctualité de la réception des marchandises.

Pourquoi est-ce important ? :

Spécifie le lieu de livraison, ce qui est utile pour analyser les différences de processus régionales et la performance logistique.

Source des données :

Table: EKPO, Champ : WERKS

Exemples
100011002000
Obligatoire Recommandé Facultatif

De l'achat au paiement - Activités des bons de commande

Ce sont les étapes de processus et les jalons critiques à capturer dans votre journal d'événements, offrant le fondement pour une découverte de processus précise et une identification des points de blocage.
6 Recommandé 8 Facultatif
Activité Descriptionn
Bon de commande achevé
Indique qu'un article de commande d'achat est considéré comme entièrement livré. C'est un événement inféré, généralement dérivé de l'indicateur 'Livraison effectuée' défini automatiquement ou manuellement sur l'article de commande d'achat.
Pourquoi est-ce important ? :

Cette activité sert de point final logique pour la partie exécution de la commande du processus. Elle est indispensablele pour le calcul du temps de cycle de commande d'achat complet, de la création à l'achèvement.

Source des données :

Inféré à partir des documents de modification (CDHDR/CDPOS) qui enregistrent lorsque l'indicateur 'Livraison effectuée' (EKPO-ELIKZ) est défini sur 'X' pour un article de commande d'achat. Le dernier article marqué comme terminé peut signifier l'achèvement de l'ensemble de la commande d'achat.

Capture

Identifier l'horodatage des documents de modification lorsque l'indicateur EKPO-ELIKZ est activé.

Type d'événement inferred
Bon de commande envoyé au fournisseur
Cette activité marque le point auquel la commande d'achat approuvée est officiellement transmise au fournisseur, par exemple, via EDI, e-mail ou impression. C'est un événement explicite capturé dans les tables de contrôle de messages lorsqu'un message de sortie est traité avec succès.
Pourquoi est-ce important ? :

Il s'agit d'une étape clé cruciale qui marque le début du délai fournisseur. L'analyse du temps écoulé entre cet événement et la réception des marchandises est indispensablele pour évaluer la performance des fournisseurs et la ponctualité des livraisons.

Source des données :

Comptabilisé dans la table des statuts de message (NAST). L' horodatage peut être extrait de NAST-DATVR et NAST-UHRVR lorsque le statut de traitement (NAST-VSTAT) est '1' (traité avec succès) pour le type de sortie de commande d'achat pertinent.

Capture

Utilisez l'horodatage de traitement de la table NAST pour le message de sortie de la commande d'achat.

Type d'événement explicit
Commande d'achat approuvée
Représente l'approbation finale de la commande d'achat, l'autorisant à être transmise au fournisseur. Ce jalon clé est généralement inféré d'une modification du statut de déblocage de la commande d'achat vers un état 'complètement débloqué' ou 'approuvé'.
Pourquoi est-ce important ? :

Cette activité est indispensable pour le calcul du KPI du temps de cycle d'approbation de la commande d'achat et l'identification des points de blocage dans le workflow d'approbation. C'est une condition préalable à la plupart des activités ultérieures, comme l'envoi de la commande au fournisseur.

Source des données :

Inféré en suivant les journaux de modification (CDHDR/CDPOS) pour la table d'en-tête de la commande d'achat (EKKO) afin de trouver quand le code de diffusion final est appliqué ou lorsque l'indicateur de statut de diffusion global (EKKO-FRGKE) est défini sur 'released'.

Capture

Identifier l'horodatage lorsque le statut de diffusion global de la commande d'achat (EKKO-FRGKE) passe à l'état finalement approuvé.

Type d'événement inferred
Commande d'achat créée
Cette activité signifie la création d'un document de commande d'achat formel, qui est un contrat contraignant avec un fournisseur. C'est un événement explicite, enregistré lorsqu'un utilisateur crée et enregistre une commande d'achat (PO) (par exemple, via la transaction ME21N), ce qui entraîne des entrées dans les tables EKKO et EKPO.
Pourquoi est-ce important ? :

Marque le début officiel du cycle de vie du bon de commande. C'est un jalon clé pour mesurer à la fois le temps de conversion de la demande d'achat en bon de commande et le temps total d'exécution de la commande.

Source des données :

Saisi à partir de la date de création (EKKO-AEDAT) dans la table d'en-tête de la commande d'achat (EKKO) pour le numéro de commande d'achat (PO) correspondant (EKKO-EBELN).

Capture

Utilisez l'horodatage de création de la table EKKO pour chaque nouvelle Commande d'achat.

Type d'événement explicit
Demande d'achat créée
Cette activité marque la création d'une demande formelle de biens ou services. C'est un événement explicite capturé lorsqu'un utilisateur enregistre un nouveau document de demande d'achat (en utilisant des transactions comme ME51N), ce qui génère un enregistrement unique dans la table EBAN.
Pourquoi est-ce important ? :

Il s'agit du point de départ principal du processus d'approvisionnement. L'analyse du temps écoulé entre cet event et la création de la commande d'achat aide à mesurer l'efficacité de la transformation de la demande interne en commandes exécutables.

Source des données :

Comptabilisé lors de la création d'une entrée dans la table d'en-tête de demande d'achat (EBAN). La date de création (EBAN-BADAT) et l'heure servent d' horodatage pour cet événement.

Capture

Identifier les nouvelles entrées dans la table EBAN basées sur la date de création.

Type d'événement explicit
Réception de marchandises enregistrée
Cette activité signifie la réception physique de marchandises d'un fournisseur contre une commande d'achat spécifique. L'enregistrement de la réception des marchandises est une action explicite (par exemple, via la transaction MIGO) qui crée un document matière et met à jour l'inventaire.
Pourquoi est-ce important ? :

Il s'agit d'une étape clé cruciale pour suivre la performance de livraison des fournisseurs et le début du processus de vérification des factures. Elle est utilisée pour calculer les taux de paiement à temps et la ponctualité de la réception des marchandises.

Source des données :

Comptabilisé lors de la création d'un document article. L' horodatage de l' événement est la date de comptabilisation (MKPF-BUDAT) ou la date de création (MKPF-CPUDT) de la table d'en-tête de document article (MKPF), liée à la commande d'achat via la table des postes (MSEG).

Capture

Utilisez l'horodatage d'enregistrement/de création de la table MKPF pour les documents de matériel référençant la commande d'achat.

Type d'événement explicit
Approbation du bon de commande demandée
Indique qu'une commande d'achat créée ou modifiée a été soumise pour approbation selon sa stratégie de diffusion configurée. Cet événement est inféré lorsque la stratégie de diffusion est déclenchée et que la commande d'achat entre dans un statut d'approbation en attente.
Pourquoi est-ce important ? :

Différencier la création de la commande d'achat (PO) du début du processus d'approbation aide à mesurer précisément le KPI du temps de cycle d'approbation. Cela met en évidence tout décalage avant le début du Workflow d'approbation.

Source des données :

Inféré à partir des documents de modification (CDHDR/CDPOS) pour la commande d'achat (objet EINKBELEG) qui montrent la définition initiale d'un statut de diffusion, ou lorsque le statut de diffusion global (EKKO-FRGKE) est initialement défini à une valeur indiquant qu'un processus d'approbation est actif.

Capture

Identifier la première entrée de document de modification qui déclenche la stratégie de diffusion pour la commande d'achat.

Type d'événement inferred
Bon de commande supprimé
Représente l'annulation ou la suppression logique d'un poste de commande d'achat, empêchant tout traitement ultérieur comme les réceptions de marchandises ou la facturation. Il s'agit d'un événement inféré, capturé lorsque l'indicateur de suppression est activé sur le poste de commande d'achat.
Pourquoi est-ce important ? :

Il s'agit d'une activité terminale qui indique qu'une commande a été annulée. L'analyse des raisons et du moment de l'annulation des commandes peut révéler des problèmes de planification de la demande ou de sélection des fournisseurs.

Source des données :

Inféré à partir des documents de modification (CDHDR/CDPOS) qui montrent l'indicateur de suppression (EKPO-LOEKZ) défini sur 'L' pour un article de commande d'achat.

Capture

Identifier l'horodatage des documents de modification lorsque l'indicateur EKPO-LOEKZ est activé.

Type d'événement inferred
Commande d'achat modifiée
Représente toute modification apportée à une commande d'achat après sa création initiale, telles que des changements de quantité, de prix ou de dates de livraison. Ces modifications sont explicitement enregistrées dans le système de documents de modification de SAP.
Pourquoi est-ce important ? :

Des modifications fréquentes, surtout après approbation, indiquent des inefficacités de processus, une mauvaise planification initiale ou un glissement de périmètre. Cette activité est indispensablele pour le tableau de bord des retouches et modifications de commandes d'achat et les KPI associés.

Source des données :

Explicitement enregistré dans les tables d'en-tête (CDHDR) et d'articles (CDPOS) des documents de modification pour l'objet Commande d'achat (EINKBELEG). Chaque modification crée une nouvelle entrée avec un horodatage.

Capture

Extrayez les événements de modification et les horodatages des tables CDHDR et CDPOS liés au numéro de commande d'achat.

Type d'événement explicit
Commande d'achat rejetée
Cette activité se produit lorsqu'un approbateur rejette une commande d'achat pendant le workflow d'approbation. C'est un événement inféré, dérivé d'un changement de statut dans les données de la stratégie de libération de la commande d'achat (PO), indiquant qu'un rejet a eu lieu.
Pourquoi est-ce important ? :

Le suivi des rejets aide à identifier les problèmes liés à la qualité des données des commandes d'achat, à la non-conformité aux politiques ou aux difficultés dans la matrice d'approbation. Cela entraîne souvent des retouches et augmente le temps de cycle global.

Source des données :

Inféré à partir des documents de modification (CDHDR/CDPOS) pour le statut de diffusion de la commande d'achat. Un rejet est généralement enregistré lorsqu'un code de diffusion est annulé ou qu'un statut de rejet spécifique est défini.

Capture

Surveiller les journaux de modifications pour l'annulation d'un code de libération ou un changement de statut indiquant un rejet.

Type d'événement inferred
Confirmation des Services Saisie
Pour les commandes d'achat basées sur des services, cette activité représente la confirmation que les services ont été rendus. C'est un événement explicite capturé par la création d'une feuille de saisie de services (par exemple, via la transaction ML81N).
Pourquoi est-ce important ? :

Il s'agit de l'équivalent d'une réception de marchandises pour les services et est indispensable pour suivre l'exécution des commandes de service. Cela déclenche le processus financier de paiement des services.

Source des données :

Saisi à partir de la date de création (ESSR-ERDAT) dans la table d'en-tête de la feuille de saisie de services (ESSR). Le lien vers la commande d'achat se trouve dans la table ESLL.

Capture

Utilisez l'horodatage de création de la table ESSR pour les feuilles de saisie de services liées à la commande d'achat.

Type d'événement explicit
Demande d'achat approuvée
Représente l'approbation formelle d'une demande d'achat, l'autorisant à être convertie en commande d'achat. Cet événement est inféré des modifications dans les champs du statut de déblocage danss données de la demande d'achat, tels que suivis par le workflow de la stratégie de déblocage de SAP.
Pourquoi est-ce important ? :

Le suivi des approbations est impératif pour identifier les points de blocage dans la phase de prélèvement.-commande et assurer la conformité avec les politiques d'approbation. Les retards à ce niveau impactent directement le temps de cycle global d'approvisionnement.

Source des données :

Inféré des journaux de modification pour la table de demande d'achat (EBAN), surveillant spécifiquement les modifications des champs de statut de diffusion (par exemple, EBAN-FRGZU) ou en analysant les documents de modification dans CDHDR/CDPOS pour l'objet EBAN.

Capture

Surveiller les documents de modification pour les champs de statut de libération EBAN afin d'identifier l'horodatage de l'approbation finale.

Type d'événement inferred
Inspection qualité effectuée
Indique que les marchandises reçues ont fait l'objet d'une inspection de qualité. Cette activité est généralement inférée lorsqu'un lot d'inspection, créé au moment de la réception des marchandises, a une décision d'utilisation prise à son sujet dans le module de gestion de la qualité.
Pourquoi est-ce important ? :

Pour les industries où la qualité est indispensablele, cette activité permet d'analyser la durée et les résultats du processus d'inspection. Les retards à ce niveau peuvent créer des points de blocage entre la réception des marchandises et leur disponibilité pour utilisation.

Source des données :

Inféré du module de gestion de la qualité. Un lot d'inspection est créé (table QALS) lors de la réception des marchandises, et l'activité est marquée par la création d'une décision d'utilisation (table QAVE), qui comprend un horodatage.

Capture

Identifier l'horodatage de la décision d'utilisation dans la table QAVE pour le lot d'inspection lié au document de matériel.

Type d'événement inferred
Marchandises retournées
Représente le retour des marchandises précédemment reçues au fournisseur, souvent en raison de problèmes de qualité ou d'expéditions incorrectes. Il s'agit d'un événement explicite capturé par la comptabilisation d'un document article avec un type de mouvement spécifique au retour.
Pourquoi est-ce important ? :

Cette activité met en évidence des problèmes de qualité du fournisseur ou de prélèvement.cision de la commande et constitue un indicateur clé de reprises de processus. Elle est indispensablele pour le calcul du KPI du Taux d'Écart de Réception des Marchandises.

Source des données :

Comptabilisé dans les tables de documents articles (MKPF/MSEG) lorsqu'un type de mouvement de retour (par exemple, '122' pour le retour de livraison au fournisseur) est utilisé. La date de comptabilisation (MKPF-BUDAT) sert d' horodatage.

Capture

Identifier les documents de matériel avec un type de mouvement de retour (par exemple, 122) qui référencent la commande d'achat d'origine.

Type d'événement explicit
Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données de SAP ECC