Votre modèle de données Purchase to Pay, commandes d’achat
Votre modèle de données Purchase to Pay, commandes d’achat
- Attributs recommandés à recueillir
- Activités clés à suivre
- Guide d’extraction pour SAP ECC
Attributs des commandes d’achat Purchase to Pay
| Nom | Description | ||
|---|---|---|---|
| Activité Activity | Nom de l’événement ou de l’étape métier qui s’est produit dans le cycle de vie de la commande d’achat. | ||
| Description Cet attribut décrit une étape du processus, par exemple « Commande d’achat créée », « Commande d’achat approuvée » ou « Entrée de marchandises comptabilisée ». La succession de ces activités forme le flux du processus pour chaque commande d’achat. L’analyse de leur ordre, de leur fréquence et du temps écoulé entre elles est au cœur du Process Mining. Elle permet de repérer les goulots d’étranglement, les boucles de reprise et les écarts par rapport au processus standard, afin de cibler les améliorations et les efforts de standardisation. Pourquoi est-ce important ? Les activités définissent les étapes du processus. L’analyse de leur ordre et de leur durée révèle le déroulement réel du processus, les goulots d’étranglement et les écarts. Où trouver ces données Cet attribut est dérivé de différentes tables et journaux de transactions SAP, notamment CDHDR/CDPOS pour les modifications, EKBE pour les entrées de marchandises et les factures, et EBAN pour les demandes d’achat. Sa génération nécessite souvent une logique personnalisée ou un programme d’extraction. Exemples Commande d’achat crééeCommande d’achat approuvéeEntrée de marchandises comptabilisée | |||
| Commande d’achat PurchaseOrder | Identifiant unique du document de commande d’achat, qui sert de dossier principal pour le suivi du processus d’approvisionnement. | ||
| Description 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 unique correspond à une instance du processus d’approvisionnement. En Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque achat. Il permet d’analyser en détail les durées de cycle, les variations du processus et le respect des règles pour chaque commande, et constitue le fondement de l’ensemble du modèle de processus. Pourquoi est-ce important ? Cet identifiant central relie tous les événements associés et permet d’analyser le cycle de vie complet de chaque commande d’achat. Où trouver ces données Table : EKKO, champ : EBELN Exemples 450001762345000176244500017625 | |||
| Heure de l’événement EventTime | Date et heure précises auxquelles l’activité s’est produite. | ||
| Description Cet horodatage indique le moment exact où un événement s’est produit, par exemple l’approbation d’une commande d’achat ou la comptabilisation d’une entrée de marchandises. Il permet de remettre toutes les activités d’un dossier dans l’ordre chronologique. Les horodatages sont indispensables au Process Mining, car ils rendent possibles toutes les analyses temporelles : calcul des durées de cycle entre les activités, détection des retards, analyse du débit du processus et mesure de la performance au regard des accords de niveau de service (SLA). Pourquoi est-ce important ? Cet horodatage est indispensable au calcul des indicateurs fondés sur une durée, comme les temps de cycle et les goulots d’étranglement, ainsi qu’au classement chronologique des événements. Où trouver ces données Cet attribut est dérivé de différents champs de date et d’heure des tables SAP, notamment EKKO-AEDAT (date de modification), CDHDR-UDATE/UTIME (horodatage du journal de modification) ou EKBE-BUDAT (date de comptabilisation). Exemples 2023-04-15T10:05:31Z2023-04-16T14:22:00Z2023-05-01T09:00:15Z | |||
| Code société CompanyCode | Identifiant de l’entité juridique ou de la société à l’origine de l’achat. | ||
| Description Dans SAP, le code société représente une entité juridique indépendante. Toutes les transactions sont comptabilisées au niveau du code société, ce qui en fait une unité organisationnelle fondamentale. L’analyse du processus par code société permet de comparer l’efficacité des achats et le respect des règles entre différentes unités opérationnelles ou différents pays. Elle aide à repérer les bonnes pratiques à reproduire dans d’autres entités et les unités qui rencontrent des difficultés. Pourquoi est-ce important ? Représente l’entité juridique et permet de comparer la performance des processus et le respect des règles entre les différentes parties de l’organisation. Où trouver ces données Table : EKKO, champ : BUKRS Exemples 10002100US01 | |||
| Groupe de marchandises MaterialGroup | Classification permettant de regrouper les marchandises ou les services présentant des caractéristiques similaires. | ||
| Description Le groupe de marchandises, ou catégorie d’achat, sert à classer les biens ou les services achetés. Il peut s’agir, par exemple, de « matériel informatique », de « fournitures de bureau » ou de « services professionnels ». Cet attribut est important pour analyser les dépenses et comprendre les pratiques d’approvisionnement. Il permet de filtrer le processus afin d’étudier le traitement des différentes catégories, les personnes qui les approuvent et les fournisseurs concernés. Il constitue une dimension importante du Dashboard « Analyse de la valeur des commandes d’achat ». Pourquoi est-ce important ? Permet de segmenter le processus par catégorie de produits ou de services et de comparer les comportements, les temps de cycle et les fournisseurs selon le type de dépenses. Où trouver ces données Table : EKPO, champ : MATKL Exemples 00101IT_HWCONSULT | |||
| Montant de la commande OrderAmount | Valeur monétaire totale du poste de commande d’achat. | ||
| Description Cet attribut représente la valeur totale d’un poste précis de la commande d’achat, calculée en multipliant la quantité par le prix net. Pour obtenir la valeur totale de la commande, il faut additionner les montants des postes. L’analyse du processus par montant de commande permet de repérer les transactions de grande valeur qui peuvent nécessiter des contrôles plus stricts ou des circuits d’approbation différents. Elle alimente le Dashboard « Analyse de la valeur des commandes d’achat » et aide à prioriser les améliorations portant sur les commandes ayant le plus d’incidence financière. Pourquoi est-ce important ? Quantifie l’incidence financière de chaque achat et permet de prioriser les commandes de grande valeur ou de repérer des possibilités de réduction des coûts. Où trouver ces données Table : EKPO, champ : NETWR (valeur nette de la commande). Exemples 1500.00250.7512345.50 | |||
| Nom d’utilisateur UserName | Identifiant de l’utilisateur ayant exécuté l’activité. | ||
| Description Cet attribut indique le nom d’utilisateur SAP de la personne qui a créé, modifié ou approuvé un document. Pour les étapes automatisées, il peut correspondre à un identifiant système ou de traitement par lots. L’analyse par utilisateur permet de repérer les besoins de formation, les personnes les plus performantes ou d’éventuels problèmes de conformité. Elle est essentielle à la création de Dashboards sur la répartition de la charge de travail, le respect de la matrice d’approbation et la performance des équipes ou des personnes. Pourquoi est-ce important ? Associe les actions des utilisateurs à des personnes précises afin d’analyser leur performance, leur charge de travail et leur respect des règles de conformité. Où trouver ces données Table : EKKO, champ : ERNAM (créé par) ; table : CDHDR, champ : USERNAME (modifié par). Exemples JSMITHMBROWNBATCH_USER | |||
| Numéro de fournisseur VendorNumber | Identifiant unique du fournisseur. | ||
| Description Ce code identifie de manière unique le fournisseur auprès duquel les biens ou services sont achetés. Il s’agit d’une donnée de référence importante pour le processus d’approvisionnement. Cet attribut est indispensable à l’analyse par fournisseur. Il permet d’évaluer la performance des livraisons, de comparer les délais entre fournisseurs et d’analyser les dépenses. C’est la principale dimension du Dashboard « Performance des livraisons des fournisseurs ». Pourquoi est-ce important ? Permet d’analyser la performance des fournisseurs et de repérer ceux qui sont fiables ainsi que ceux qui entraînent des retards ou des problèmes de qualité. Où trouver ces données Table : EKKO, champ : LIFNR Exemples 100345V-20598700112 | |||
| Type de document DocumentType | Code permettant de classer les différents types de commandes d’achat. | ||
| Description Dans SAP, le type de document détermine la plage de numéros, la sélection des champs et le déroulement général du processus de commande d’achat. Il peut, par exemple, distinguer les commandes standard, les commandes de services et les commandes de transfert de stock. Cet attribut constitue une dimension d’analyse utile, car les différents types de documents suivent souvent des processus distincts. Le filtrage par type de document permet de comparer plus justement les temps de cycle et les flux de processus. Pourquoi est-ce important ? Distingue les différents types de processus d’achat, par exemple standard, service ou retour, qui suivent souvent des parcours et répondent à des attentes de performance distincts. Où trouver ces données Table : EKKO, champ : BSART Exemples NBFOUB | |||
| Date de livraison demandée RequestedDeliveryDate | Date à laquelle l’entreprise a demandé au fournisseur de livrer les biens ou les services. | ||
| Description Il s’agit de la date de livraison cible indiquée dans la commande d’achat. Elle sert de référence pour mesurer les délais de livraison réels. Cette date est indispensable au calcul du KPI « Taux de réception des marchandises à temps ». En comparant la date réelle de réception à la date demandée, les organisations peuvent mesurer la fiabilité des fournisseurs et l’efficacité de leurs opérations de réception. Cette analyse alimente directement le Dashboard « Performance des livraisons des fournisseurs ». Pourquoi est-ce important ? Cette date cible de livraison est indispensable au calcul des KPI de respect des délais et à l’évaluation de la fiabilité des fournisseurs. Où trouver ces données Table : EKPO, champ : EINDT Exemples 2023-06-102023-07-222023-08-01 | |||
| Demande d’achat PurchaseRequisition | Identifiant de la demande d’achat à l’origine de la commande. | ||
| Description Cet attribut relie la commande d’achat à la demande dont elle est issue. Certaines commandes ne sont précédées d’aucune demande d’achat. Ce lien est essentiel à l’analyse du Dashboard « Conversion des demandes en commandes » et du KPI « Taux de conversion des demandes d’achat en commandes ». Il permet de mesurer l’efficacité du processus en amont, de la demande initiale à la création d’une commande officielle, et de repérer les commandes non conformes créées sans demande préalable. Pourquoi est-ce important ? Relie la commande d’achat à la demande initiale, ce qui permet d’analyser le processus de conversion et de repérer les commandes créées sans demande préalable. Où trouver ces données Table : EKPO, champ : BANFN Exemples 1001589010015891 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation des données depuis le système source. | ||
| Description Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données. Il renseigne sur leur fraîcheur au moment de l’analyse. L’affichage de cette information dans les Dashboards permet aux utilisateurs de savoir si les analyses reposent sur des données presque en temps réel ou sur un instantané historique. Il clarifie les attentes et aide à prendre des décisions en connaissance de l’ancienneté des données. Pourquoi est-ce important ? Indique aux utilisateurs si les données sont à jour, afin qu’ils sachent si l’analyse reflète l’état le plus récent des opérations. Où trouver ces données Cet horodatage est généré et ajouté par le processus d’extraction des données ou ETL lors de son exécution. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Code de devise du montant de la commande d’achat. | ||
| Description Cet attribut indique la devise dans laquelle est exprimée la valeur de la commande d’achat, par exemple USD, EUR ou GBP. Il fournit le contexte nécessaire à l’interprétation des montants. Pour les organisations internationales, la devise est indispensable à une analyse financière exacte. Elle permet d’agréger et de comparer correctement les valeurs des commandes. Tous les KPI monétaires doivent être interprétés en tenant compte de la devise utilisée. Pourquoi est-ce important ? Fournit le contexte nécessaire à l’interprétation des montants et garantit la justesse des analyses financières, en particulier dans les organisations internationales. Où trouver ces données Table : EKKO, champ : WAERS Exemples USDEURJPY | |||
| Groupe d’acheteurs PurchasingGroup | Acheteur ou groupe d’acheteurs responsable de l’activité d’approvisionnement. | ||
| Description Le groupe d’acheteurs désigne la personne ou l’équipe chargée d’une activité d’achat donnée. Il constitue le principal interlocuteur des fournisseurs. Cet attribut permet une analyse plus détaillée que celle par organisation d’achats. Il aide à comprendre la répartition de la charge de travail entre les acheteurs et à repérer les différences de performance individuelles, afin d’orienter l’affectation des ressources et les formations. Pourquoi est-ce important ? Fournit une vue détaillée des personnes responsables des achats, afin d’analyser la charge de travail et les performances par acheteur ou par équipe. Où trouver ces données Table : EKKO, champ : EKGRP Exemples 001002N01 | |||
| Livraison dans les délais IsOnTimeDelivery | Indicateur signalant si les marchandises ont été reçues à la date de livraison demandée ou avant. | ||
| Description Cet attribut booléen prend la valeur true si l’horodatage de l’activité « Goods Receipt Posted » est antérieur ou égal à la « Requested Delivery Date ». Il indique clairement, pour chaque poste de commande d’achat, si la livraison a été effectuée dans les délais. Cet attribut sert de base à l’indicateur « On-Time Goods Receipt Rate ». Il simplifie l’analyse des performances des fournisseurs et de l’efficacité de la réception en interne, en facilitant le regroupement et le filtrage des livraisons ponctuelles et tardives. Pourquoi est-ce important ? Fournit une mesure claire de la ponctualité des livraisons, en indiquant si elles ont été effectuées dans les délais. Cet indicateur alimente directement les KPI et les Dashboards sur les performances des fournisseurs. Où trouver ces données Cet attribut calculé compare la date de comptabilisation de la réception des marchandises (EKBE-BUDAT) à la date de livraison demandée (EKPO-EINDT). Exemples truefalse | |||
| Modification après approbation IsPostApprovalChange | Indicateur signalant si une commande d’achat a été modifiée après son approbation initiale. | ||
| Description Cet attribut booléen prend la valeur true si l’activité « Purchase Order Changed » est détectée après l’activité « Purchase Order Approved » pour la même commande d’achat. Il permet d’isoler les modifications problématiques intervenant tard dans le processus. Ce champ calculé alimente directement l’indicateur « Post-Approval PO Change Rate » et le Dashboard « Purchase Order Rework and Changes ». Il permet de quantifier et de mettre en évidence les modifications perturbatrices, susceptibles d’entraîner des retards et de nécessiter une nouvelle approbation. Elles peuvent révéler des problèmes dans la définition initiale des besoins ou du périmètre. Pourquoi est-ce important ? Mesure directement les reprises après approbation, un indicateur clé de la stabilité et de l’efficacité du processus. Un taux élevé signale des problèmes dans la définition des besoins en amont. Où trouver ces données Cet attribut calculé est dérivé de la séquence d’activités du journal d’événements. Exemples truefalse | |||
| Motif du rejet RejectionReason | Code ou texte expliquant le rejet d’une demande d’achat ou d’une commande d’achat. | ||
| Description Cet attribut indique le motif précis fourni lorsqu’une commande d’achat est rejetée au cours du flux de travail d’approbation. Cette information est essentielle pour comprendre les causes des reprises et des retards. L’analyse des motifs de rejet permet de repérer les problèmes récurrents, comme un prix incorrect, un dépassement de budget ou le choix d’un fournisseur non conforme. L’entreprise peut alors s’attaquer aux causes profondes, améliorer la qualité des commandes d’achat initiales et simplifier le processus d’approbation. Pourquoi est-ce important ? Indique directement les raisons des échecs d’approbation et permet de cibler les améliorations pour réduire les reprises et raccourcir les cycles d’approbation. Où trouver ces données Cette information peut être difficile à trouver. Elle peut être stockée dans des champs de texte long ou dépendre d’une configuration personnalisée du flux de travail. Sa recherche nécessite souvent une connaissance précise de l’implémentation. Exemples Prix incorrectBudget dépasséDemande en double | |||
| Nom du fournisseur VendorName | Raison sociale du fournisseur. | ||
| Description Nom du fournisseur, plus facile à lire que son numéro. Il provient généralement des données de référence des fournisseurs. Le numéro de fournisseur sert aux jointures et à l’identification unique, tandis que son nom est essentiel dans les Dashboards et les rapports destinés aux utilisateurs. Il rend les analyses plus intuitives et accessibles aux équipes métier qui ne connaissent pas nécessairement les codes fournisseurs. Pourquoi est-ce important ? Fournit un nom lisible du fournisseur, ce qui facilite la compréhension des Dashboards et des rapports par les équipes métier. Où trouver ces données Table : LFA1, champ : NAME1. Une jointure entre EKKO-LIFNR et LFA1-LIFNR est nécessaire. Exemples Staples Inc.Global Tech SolutionsOffice Supply Co. | |||
| Organisation d’achats PurchasingOrganization | Unité organisationnelle chargée de négocier les prix et d’acheter des marchandises ou des services. | ||
| Description Dans SAP, l’organisation d’achats est une unité organisationnelle clé, responsable des activités d’approvisionnement. Elle peut être centralisée pour toute l’entreprise ou décentralisée par site ou par région. L’analyse de la performance par organisation d’achats permet de repérer les équipes les plus efficaces. Elle permet de comparer des indicateurs comme le temps de cycle, le taux de reprises et les coûts entre différentes unités, afin de mettre en évidence les bonnes pratiques et les besoins d’assistance. Pourquoi est-ce important ? Indique quelle équipe est responsable des achats et permet de comparer la performance entre différentes unités organisationnelles. Où trouver ces données Table : EKKO, champ : EKORG Exemples 1000US01DE01 | |||
| Site Plant | Lieu physique ou site où les marchandises doivent être livrées. | ||
| Description Le site est une unité organisationnelle qui représente une usine, un entrepôt ou un autre lieu de réception de marchandises ou de services. L’analyse par site permet de comprendre les différences géographiques dans le processus d’approvisionnement. Elle peut révéler des écarts dans les délais de livraison des fournisseurs selon les lieux ou mettre en évidence des sites où la réception est inefficace, afin d’évaluer la ponctualité de la réception des marchandises. Pourquoi est-ce important ? Indique le lieu de livraison, une information utile pour analyser les différences régionales entre les processus et les performances logistiques. Où trouver ces données Table : EKPO, champ : WERKS Exemples 100011002000 | |||
| Système source SourceSystem | Système depuis lequel les données ont été extraites. | ||
| Description Cet attribut indique l’origine des données, généralement identifiée par une instance SAP ECC (par exemple, « ECC_PROD_100 »). Dans un environnement comprenant plusieurs systèmes, il permet de distinguer les sources de données. Pour assurer la gouvernance et la traçabilité des données, il est important de connaître le système source. Cela contribue à préserver leur intégrité et à résoudre les problèmes d’extraction ou de qualité, en particulier lorsque les données proviennent de plusieurs systèmes ou modules ERP. Pourquoi est-ce important ? Indique l’origine des données, une information importante pour leur gouvernance et leur validation, ainsi que pour la gestion des analyses couvrant plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données pour indiquer le système dont provient le jeu de données. Exemples SAP_ECC_PRODECC_EU_100S4H_FIN | |||
Activités des commandes d’achat Purchase to Pay
| Activité | Description | ||
|---|---|---|---|
| Commande d’achat approuvée | Cet événement correspond à l’approbation finale de la commande d’achat, qui autorise son envoi au fournisseur. Ce jalon important est généralement déduit du passage du statut de validation de la commande à l’état « entièrement validée » ou « approuvée ». | ||
| Pourquoi est-ce important ? Cette activité est indispensable au calcul du KPI de durée du cycle d’approbation de la commande d’achat et à la détection des goulots d’étranglement dans le flux de travail d’approbation. Elle constitue un préalable à la plupart des activités suivantes, comme l’envoi de la commande au fournisseur. Où trouver ces données L’événement est déduit du suivi des journaux de modification (CDHDR/CDPOS) de la table d’en-tête des commandes d’achat (EKKO), afin de repérer l’application du code de validation final ou le passage de l’indicateur de statut global de validation (EKKO-FRGKE) à l’état « validée ». Données à recueillir Repérez l’horodatage auquel le statut global de validation de la commande d’achat (EKKO-FRGKE) passe à l’état final d’approbation. Type d’événement inferred | |||
| Commande d’achat créée | Cette activité correspond à la création d’un document officiel de commande d’achat, qui constitue un contrat contraignant avec un fournisseur. Il s’agit d’un événement explicite, enregistré lorsqu’un utilisateur crée et enregistre une commande d’achat, par exemple avec la transaction ME21N. Des entrées sont alors ajoutées aux tables EKKO et EKPO. | ||
| Pourquoi est-ce important ? Cet événement marque le début officiel du cycle de vie de la commande d’achat. Il constitue un jalon important pour mesurer le délai de conversion d’une demande d’achat en commande ainsi que le délai total d’exécution de la commande. Où trouver ces données L’événement est extrait de la date de création (EKKO-AEDAT) dans la table d’en-tête des commandes d’achat (EKKO), pour le numéro de commande correspondant (EKKO-EBELN). Données à recueillir Utilisez l’horodatage de création de la table EKKO pour chaque nouvelle commande d’achat. Type d’événement explicit | |||
| Commande d’achat envoyée au fournisseur | Cette activité marque l’envoi officiel de la commande d’achat approuvée au fournisseur, par exemple par EDI, par courriel ou sur papier. Il s’agit d’un événement explicite, enregistré dans les tables de contrôle des messages lorsqu’un message de sortie est traité avec succès. | ||
| Pourquoi est-ce important ? Ce jalon important marque le début du délai de livraison du fournisseur. L’analyse du temps écoulé entre cet événement et la réception des marchandises permet d’évaluer la performance du fournisseur et le respect des délais de livraison. Où trouver ces données L’événement est enregistré 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 message de sortie correspondant à la commande d’achat. Données à recueillir 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 terminée | Indique qu’un poste de commande d’achat est considéré comme entièrement livré. Cet événement est déduit, généralement à partir de l’activation automatique ou manuelle de l’indicateur « Livraison terminée » sur le poste de la commande. | ||
| Pourquoi est-ce important ? Cette activité marque la fin logique de la partie du processus consacrée à l’exécution de la commande. Elle est essentielle au calcul de la durée totale du cycle de la commande d’achat, de sa création à son achèvement. Où trouver ces données L’événement est déduit des documents de modification (CDHDR/CDPOS), qui indiquent quand l’indicateur « Livraison terminée » (EKPO-ELIKZ) est défini sur « X » pour un poste de commande d’achat. Le dernier poste marqué comme terminé peut signaler l’achèvement de toute la commande. Données à recueillir Repérez dans les documents de modification l’horodatage auquel l’indicateur EKPO-ELIKZ est défini. Type d’événement inferred | |||
| Demande d’achat créée | Cette activité marque la création d’une demande officielle de biens ou de services. Il s’agit d’un événement explicite, enregistré lorsqu’un utilisateur crée et enregistre un nouveau document de demande d’achat, par exemple avec la transaction ME51N. Cette opération génère un enregistrement unique dans la table EBAN. | ||
| Pourquoi est-ce important ? C’est le point de départ principal du processus d’approvisionnement. L’analyse du délai entre cet événement et la création de la commande d’achat permet de mesurer l’efficacité avec laquelle la demande interne est convertie en commandes concrètes. Où trouver ces données L’événement est enregistré à la création d’une entrée dans la table d’en-tête des demandes d’achat (EBAN). La date (EBAN-BADAT) et l’heure de création servent d’horodatage. Données à recueillir Repérez les nouvelles entrées de la table EBAN à partir de leur date de création. Type d’événement explicit | |||
| Entrée de marchandises comptabilisée | Cette activité correspond à la réception physique de marchandises d’un fournisseur au titre d’une commande d’achat précise. La comptabilisation de l’entrée de marchandises est une action explicite, effectuée par exemple avec la transaction MIGO. Elle crée un document article et met à jour le stock. | ||
| Pourquoi est-ce important ? Ce jalon est important pour suivre la performance des livraisons des fournisseurs et le début du processus de vérification des factures. Il sert à calculer le taux de livraisons à temps et les délais de réception des marchandises. Où trouver ces données L’événement est enregistré à la création d’un document article. Son horodatage correspond à la date de comptabilisation (MKPF-BUDAT) ou à la date de création (MKPF-CPUDT) de la table d’en-tête des documents articles (MKPF). Le lien avec la commande d’achat est établi par la table des postes (MSEG). Données à recueillir Utilisez l’horodatage de comptabilisation ou de création de la table MKPF pour les documents articles faisant référence à la commande d’achat. Type d’événement explicit | |||
| Approbation de la commande d’achat demandée | Indique qu’une commande d’achat créée ou modifiée a été soumise à approbation conformément à sa stratégie de validation. Cet événement est déduit du déclenchement de cette stratégie et du passage de la commande au statut d’approbation en attente. | ||
| Pourquoi est-ce important ? Distinguer la création de la commande d’achat du début de son processus d’approbation permet de mesurer précisément le KPI de durée du cycle d’approbation. Cela met en évidence tout délai avant le lancement du flux de travail d’approbation. Où trouver ces données L’événement est déduit des documents de modification (CDHDR/CDPOS) de la commande d’achat (objet EINKBELEG), qui indiquent la première définition d’un statut de validation, ou de la première attribution à l’indicateur de statut global de validation (EKKO-FRGKE) d’une valeur signalant qu’un processus d’approbation est en cours. Données à recueillir Repérez la première entrée de document de modification qui déclenche la stratégie de validation de la commande d’achat. Type d’événement inferred | |||
| Commande d’achat modifiée | Cet événement correspond à toute modification apportée à une commande d’achat après sa création initiale, par exemple un changement de quantité, de prix ou de date de livraison. Ces modifications sont enregistrées explicitement dans le système de documents de modification de SAP. | ||
| Pourquoi est-ce important ? Des modifications fréquentes, en particulier après approbation, peuvent révéler des inefficacités, une planification initiale insuffisante ou une dérive du périmètre. Cette activité est essentielle au Dashboard des reprises et modifications des commandes d’achat et aux KPI associés. Où trouver ces données L’événement est enregistré explicitement dans les tables d’en-tête (CDHDR) et de postes (CDPOS) des documents de modification de l’objet commande d’achat (EINKBELEG). Chaque modification crée une nouvelle entrée horodatée. Données à recueillir Extrayez les événements de modification et leurs horodatages des tables CDHDR et CDPOS associées 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 au cours du flux de travail d’approbation. Il s’agit d’un événement déduit d’un changement de statut dans les données de stratégie de validation de la commande, qui signale un rejet. | ||
| Pourquoi est-ce important ? Le suivi des rejets permet de repérer les problèmes de qualité des données de commande, les manquements aux règles ou les lacunes de la matrice d’approbation. Un rejet entraîne souvent des reprises et allonge la durée totale du cycle. Où trouver ces données L’événement est déduit des documents de modification (CDHDR/CDPOS) du statut de validation de la commande d’achat. Un rejet est généralement enregistré lorsqu’un code de validation est annulé ou qu’un statut de rejet spécifique est défini. Données à recueillir Surveillez les journaux de modification pour repérer l’annulation d’un code de validation ou un changement de statut signalant un rejet. Type d’événement inferred | |||
| Commande d’achat supprimée | Cet événement correspond à l’annulation ou à la suppression logique d’un poste de commande d’achat, qui empêche la poursuite du traitement, notamment la réception des marchandises ou la facturation. Il est déduit de l’activation de l’indicateur de suppression sur le poste de commande. | ||
| Pourquoi est-ce important ? Cette activité terminale indique qu’une commande a été annulée. L’analyse des raisons et du moment de la suppression des commandes peut révéler des problèmes de planification de la demande ou de sélection des fournisseurs. Où trouver ces données L’événement est déduit des documents de modification (CDHDR/CDPOS), qui indiquent que l’indicateur de suppression (EKPO-LOEKZ) a été défini sur « L » pour un poste de commande d’achat. Données à recueillir Repérez dans les documents de modification l’horodatage auquel l’indicateur EKPO-LOEKZ est défini. Type d’événement inferred | |||
| Confirmation de service saisie | Pour les commandes d’achat de services, cette activité correspond à la confirmation de la réalisation des prestations. Il s’agit d’un événement explicite, enregistré lors de la création d’une feuille de saisie des services, par exemple avec la transaction ML81N. | ||
| Pourquoi est-ce important ? Pour les services, cette activité équivaut à une entrée de marchandises et permet de suivre l’exécution des commandes de services. Elle déclenche le processus financier de paiement des services. Où trouver ces données L’événement est extrait de la date de création (ESSR-ERDAT) dans la table d’en-tête des feuilles de saisie des services (ESSR). Le lien avec la commande d’achat figure dans la table ESLL. Données à recueillir Utilisez l’horodatage de création de la table ESSR pour les feuilles de saisie des services associées à la commande d’achat. Type d’événement explicit | |||
| Contrôle qualité effectué | Indique que les marchandises reçues ont fait l’objet d’un contrôle qualité. Cette activité est généralement déduite lorsqu’un lot de contrôle, créé au moment de la réception des marchandises, fait l’objet d’une décision d’utilisation dans le module de gestion de la qualité. | ||
| Pourquoi est-ce important ? Dans les secteurs où la qualité est essentielle, cette activité permet d’analyser la durée et les résultats du contrôle. Les retards à cette étape peuvent créer des goulots d’étranglement entre la réception des marchandises et leur mise à disposition. Où trouver ces données L’événement est déduit du module de gestion de la qualité. Un lot de contrôle est créé dans la table QALS à la réception des marchandises. L’activité est ensuite marquée par la création d’une décision d’utilisation dans la table QAVE, qui comprend un horodatage. Données à recueillir Repérez l’horodatage de la décision d’utilisation dans la table QAVE pour le lot de contrôle associé au document article. Type d’événement inferred | |||
| Demande d’achat approuvée | Cet événement correspond à l’approbation officielle d’une demande d’achat, qui autorise sa conversion en commande d’achat. Il est déduit des modifications apportées aux champs de statut de validation des données de la demande d’achat, conformément au flux de travail de stratégie de validation de SAP. | ||
| Pourquoi est-ce important ? Le suivi des approbations permet de repérer les goulots d’étranglement avant la commande et de vérifier le respect des règles d’approbation. Les retards à cette étape ont une incidence directe sur la durée totale du cycle d’approvisionnement. Où trouver ces données L’événement est déduit des journaux de modification de la table des demandes d’achat (EBAN), en particulier des changements apportés aux champs de statut de validation (par exemple, EBAN-FRGZU), ou de l’analyse des documents de modification CDHDR/CDPOS pour l’objet EBAN. Données à recueillir Surveillez les documents de modification des champs de statut de validation EBAN pour déterminer l’horodatage de l’approbation finale. Type d’événement inferred | |||
| Marchandises retournées | Cet événement correspond au retour au fournisseur de marchandises précédemment reçues, souvent en raison de problèmes de qualité ou d’une livraison incorrecte. Il s’agit d’un événement explicite, enregistré lors de la comptabilisation d’un document article avec un type de mouvement propre aux retours. | ||
| Pourquoi est-ce important ? Cette activité met en évidence les problèmes de qualité du fournisseur ou d’exactitude de la commande et constitue un indicateur important des reprises dans le processus. Elle est essentielle au calcul du KPI de taux d’écart des entrées de marchandises. Où trouver ces données L’événement est enregistré dans les tables des documents articles (MKPF/MSEG) lorsqu’un type de mouvement de retour est utilisé, par exemple « 122 » pour un retour de livraison au fournisseur. La date de comptabilisation (MKPF-BUDAT) sert d’horodatage. Données à recueillir Repérez les documents articles associés à la commande d’achat initiale et comportant un type de mouvement de retour, par exemple 122. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Créer un programme ABAP : ouvrez l’éditeur ABAP à l’aide du code de transaction SE38. Saisissez un nom pour le nouveau programme, par exemple Z_PM_PO_EXTRACT, puis cliquez sur « Create ». Donnez-lui un titre, par exemple « Process Mining PO Data Extraction », et sélectionnez le type « Executable Program ».
- Définir l’écran de sélection : définissez les paramètres de l’écran de sélection dans le programme. Ils permettent aux utilisateurs de filtrer les données à extraire. Les principaux paramètres sont la plage de dates de création des commandes d’achat, le code société (BUKRS) et le type de document d’achat (BSART).
- Définir les structures de données : déclarez une table interne dont la structure correspond au format final du journal d’événements. Elle doit inclure tous les attributs requis et recommandés : PurchaseOrder, Activity, EventTime, UserName, VendorNumber, OrderAmount, MaterialGroup, CompanyCode et DocumentType.
- Mettre en œuvre la logique de sélection des données : écrivez la logique ABAP principale pour sélectionner les données correspondant à chacune des 14 activités requises. Vous devrez interroger plusieurs tables SAP, notamment EKKO, EKPO, EKBE, EBAN, CDHDR, CDPOS et NAST. Utilisez une sous-routine distincte (PERFORM) pour chaque activité afin de structurer le code.
- Sélectionner les données des demandes d’achat : interrogez la table EBAN pour repérer les événements « Purchase Requisition Created » et associez-les aux commandes d’achat via la table EKPO. Utilisez les tables de journal des modifications (CDHDR, CDPOS) pour repérer les événements « Purchase Requisition Approved » en suivant les changements des champs de statut de validation.
- Sélectionner les événements principaux des commandes d’achat : interrogez les tables EKKO et EKPO pour l’événement « Purchase Order Created ». Utilisez les tables de journal des modifications (CDHDR, CDPOS) pour l’objet EINKBELEG afin d’extraire les événements « Purchase Order Changed », « Purchase Order Approved », « Purchase Order Rejected », « Purchase Order Completed » et « Purchase Order Deleted », en fonction des changements apportés à des champs précis, comme les indicateurs de validation et de suppression.
- Sélectionner les événements de communication des commandes d’achat : interrogez la table NAST pour trouver les enregistrements indiquant que la commande d’achat a bien été transmise. Vous pourrez ainsi consigner l’activité « Purchase Order Sent to Vendor ».
- Sélectionner les événements liés aux marchandises et aux services : interrogez la table EKBE pour repérer les écritures de documents article et identifier les activités « Goods Receipt Posted » et « Goods Returned » selon la catégorie de type de mouvement. Interrogez les tables ESSR et ESLL pour repérer les feuilles de saisie des services et consigner l’activité « Services Confirmation Entered ».
- Sélectionner les événements de gestion de la qualité : si le module de gestion de la qualité est utilisé, interrogez les tables QALS et QAVE pour repérer la prise d’une décision d’utilisation concernant un lot de contrôle lié à une commande d’achat. Cela correspond à l’activité « Quality Inspection Performed ».
- Combiner et formater les données : regroupez les données issues de toutes les sélections dans une seule table interne finale. Veillez à formater le champ EventTime de manière uniforme, par exemple YYYY-MM-DDTHH:MI:SS.
- Mettre en place le téléchargement du fichier : ajoutez une fonction permettant de télécharger la table interne finale dans un fichier. Le format recommandé est un fichier à valeurs séparées par des tabulations ou un fichier CSV, que vous pouvez générer avec le module de fonction GUI_DOWNLOAD.
- Exécuter et enregistrer : exécutez le programme à l’aide de la transaction SE38 ou SA38. Renseignez les critères de sélection et lancez le rapport. Lorsque le système vous y invite, enregistrez le fichier de sortie sur votre ordinateur avec l’extension .csv. Il sera alors prêt à être importé.
Configuration
- Plage de dates : définissez une plage de dates précise pour l’extraction, généralement à partir de la date de création de la commande d’achat (EKKO-AEDAT). Une période de 3 à 6 mois constitue souvent un bon point de départ pour équilibrer le volume de données et la pertinence de l’analyse.
- Code société (BUKRS) : filtrez les données par un ou plusieurs codes société pour limiter l’extraction aux entités juridiques concernées. Ce paramètre est important pour les performances et la pertinence des résultats.
- Type de document d’achat (BSART) : filtrez par type de document, par exemple « NB » pour une commande d’achat standard, afin de vous concentrer sur les processus habituels et d’exclure, si nécessaire, les types d’achat particuliers.
- Granularité des données : l’extraction porte sur les postes de commande d’achat. L’ID de cas correspond au numéro de commande d’achat (EBELN). Tous les événements, y compris ceux associés à un poste comme les réceptions de marchandises, sont rattachés à cet ID de cas principal.
- Performances : pour les grands jeux de données, planifiez l’exécution du programme en arrière-plan (SM36) afin d’éviter les erreurs de délai d’attente. Vérifiez la présence d’index de base de données sur les champs clés utilisés dans les clauses WHERE, en particulier dans les tables CDHDR et CDPOS.
- Prérequis : l’utilisateur qui exécute le rapport doit être autorisé à accéder à l’environnement de développement ABAP (SE38) et à exécuter le programme. Il doit également disposer d’un accès en lecture à toutes les tables sous-jacentes, notamment EKKO, EKPO, EKBE, CDHDR, CDPOS, EBAN, NAST, ESSR et les tables QM.
Exemple de requête abap
REPORT Z_PM_PO_EXTRACT.
TABLES: ekko, ekpo, eban.
*&---------------------------------------------------------------------*
*& Data Structures for Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
purchaseorder TYPE ebeln,
activity TYPE string,
eventtime TYPE timestamp,
username TYPE ernam,
vendornumber TYPE lifnr,
orderamount TYPE netwr_ak,
materialgroup TYPE matkl,
companycode TYPE bukrs,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_aedat FOR ekko-aedat OBLIGATORY, " PO Creation Date
s_bukrs FOR ekko-bukrs, " Company Code
s_bsart FOR ekko-bsart, " PO Document Type
s_ebeln FOR ekko-ebeln. " PO Number
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_po_headers.
IF gt_event_log IS NOT INITIAL.
PERFORM get_pr_created.
PERFORM get_pr_approved.
PERFORM get_po_created.
PERFORM get_po_release_events. " Approved, Rejected, Approval Requested
PERFORM get_po_sent_to_vendor.
PERFORM get_po_changed.
PERFORM get_goods_receipt_posted.
PERFORM get_services_confirmed.
PERFORM get_quality_inspection.
PERFORM get_goods_returned.
PERFORM get_po_completed.
PERFORM get_po_deleted.
PERFORM download_to_csv.
ELSE.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'I'.
ENDIF.
*&---------------------------------------------------------------------*
*& Form GET_PO_HEADERS (Base data)
*&---------------------------------------------------------------------*
FORM get_po_headers.
SELECT h~ebeln, h~lifnr, h~bukrs, h~bsart, p~netwr, p~matkl
FROM ekko AS h
INNER JOIN ekpo AS p ON h~ebeln = p~ebeln
INTO TABLE @DATA(lt_po_base)
WHERE h~aedat IN @s_aedat
AND h~bukrs IN @s_bukrs
AND h~bsart IN @s_bsart
AND h~ebeln IN @s_ebeln.
SORT lt_po_base BY ebeln.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PR_CREATED
*&---------------------------------------------------------------------*
FORM get_pr_created.
DATA: lt_pr_events TYPE TABLE OF ty_event_log.
SELECT p~ebeln AS purchaseorder,
'Purchase Requisition Created' AS activity,
b~erdat AS event_date,
'000000' AS event_time,
b~ernam AS username,
h~lifnr AS vendornumber,
p~netwr AS orderamount,
p~matkl AS materialgroup,
h~bukrs AS companycode,
h~bsart AS documenttype
FROM ekpo AS p
JOIN eban AS b ON p~banfn = b~banfn AND p~bnfpo = b~bnfpo
JOIN ekko AS h ON p~ebeln = h~ebeln
WHERE p~ebeln IN @s_ebeln
AND p~banfn IS NOT NULL AND p~banfn <> ''
AND h~aedat IN @s_aedat
AND h~bukrs IN @s_bukrs
AND h~bsart IN @s_bsart
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created ASSIGNING FIELD-SYMBOL(<fs_pr>).
DATA(ls_event) = CORRESPONDING ty_event_log(<fs_pr>).
CONCATENATE <fs_pr>-event_date <fs_pr>-event_time INTO DATA(lv_ts).
CONVERT DATE <fs_pr>-event_date TIME '000000' INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PR_APPROVED
*&---------------------------------------------------------------------*
FORM get_pr_approved.
DATA: lt_pr_list TYPE TABLE OF eban-banfn.
SELECT DISTINCT p~banfn FROM ekpo AS p
JOIN ekko AS h ON p~ebeln = h~ebeln
WHERE h~aedat IN @s_aedat
AND h~bukrs IN @s_bukrs
AND p~banfn IS NOT NULL AND p~banfn <> ''
INTO TABLE @lt_pr_list.
IF lt_pr_list IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectid = p~objectid AND h~changenr = p~changenr
FOR ALL ENTRIES IN @lt_pr_list
WHERE h~objectclas = 'BANF'
AND h~objectid = @lt_pr_list-table_line
AND p~tabname = 'EBAN'
AND p~fname = 'FRGZU'
INTO TABLE @DATA(lt_cd_pr).
LOOP AT lt_cd_pr ASSIGNING FIELD-SYMBOL(<fs_cd>) WHERE <fs_cd>-value_new = 'X'.
SELECT SINGLE p~ebeln, p~netwr, p~matkl, h~lifnr, h~bukrs, h~bsart
FROM ekpo AS p
JOIN ekko AS h ON p~ebeln = h~ebeln
WHERE p~banfn = @<fs_cd>-objectid(10)
INTO @DATA(ls_po_info).
IF sy-subrc = 0.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = ls_po_info-ebeln
activity = 'Purchase Requisition Approved'
username = <fs_cd>-username
vendornumber = ls_po_info-lifnr
orderamount = ls_po_info-netwr
materialgroup = ls_po_info-matkl
companycode = ls_po_info-bukrs
documenttype = ls_po_info-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_CREATED
*&---------------------------------------------------------------------*
FORM get_po_created.
LOOP AT lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>).
SELECT SINGLE aedat, ernam FROM ekko INTO @DATA(ls_ekko)
WHERE ebeln = @<fs_po>-ebeln.
IF sy-subrc = 0.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Created'
username = ls_ekko-ernam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE ls_ekko-aedat TIME '000000' INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_RELEASE_EVENTS
*&---------------------------------------------------------------------*
FORM get_po_release_events.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime, p~value_new
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectid = p~objectid AND h~changenr = p~changenr
WHERE h~objectclas = 'EINKBELEG'
AND h~objectid IN lt_ebeln
AND p~tabname = 'EKKO'
AND p~fname = 'FRGKE'
INTO TABLE @DATA(lt_cd_po).
LOOP AT lt_cd_po ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
CASE <fs_cd>-value_new.
WHEN '2' OR 'R'. " Final Release
ls_event-activity = 'Purchase Order Approved'.
WHEN '1'. " Blocked
ls_event-activity = 'Purchase Order Rejected'.
WHEN OTHERS. " Any other change implies a pending state
ls_event-activity = 'Purchase Order Approval Requested'.
ENDCASE.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_SENT_TO_VENDOR
*&---------------------------------------------------------------------*
FORM get_po_sent_to_vendor.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT objky, erdat, eruhr, ernam
FROM nast
WHERE kapol = 'EF' AND objky IN lt_ebeln AND vstat = '1'
INTO TABLE @DATA(lt_nast).
LOOP AT lt_nast ASSIGNING FIELD-SYMBOL(<fs_nast>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_nast>-objky.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Sent to Vendor'
username = <fs_nast>-ernam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_nast>-erdat TIME <fs_nast>-eruhr INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_CHANGED
*&---------------------------------------------------------------------*
FORM get_po_changed.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT DISTINCT objectid, username, udate, utime
FROM cdhdr
WHERE objectclas = 'EINKBELEG' AND objectid IN lt_ebeln AND tcode <> 'ME21N' AND tcode <> 'ME22'
INTO TABLE @DATA(lt_cdhdr_chg).
LOOP AT lt_cdhdr_chg ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Changed'
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_GOODS_RECEIPT_POSTED
*&---------------------------------------------------------------------*
FORM get_goods_receipt_posted.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT k~ebeln, m~cpudt, m~cputm, m~usnam, k~bewtp
FROM ekbe AS k JOIN mkpf AS m ON k~belnr = m~mblnr AND k~gjahr = m~mjahr
WHERE k~ebeln IN lt_ebeln AND k~bewtp = 'E' AND k~shkzg = 'S'
INTO TABLE @DATA(lt_gr).
LOOP AT lt_gr ASSIGNING FIELD-SYMBOL(<fs_gr>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_gr>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Goods Receipt Posted'
username = <fs_gr>-usnam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_gr>-cpudt TIME <fs_gr>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_SERVICES_CONFIRMED
*&---------------------------------------------------------------------*
FORM get_services_confirmed.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT l~ebeln, h~erdat, h~eruhr, h~ernam
FROM essr AS h JOIN esll AS l ON h~lblni = l~lblni
WHERE l~ebeln IN lt_ebeln
INTO TABLE @DATA(lt_ses).
LOOP AT lt_ses ASSIGNING FIELD-SYMBOL(<fs_ses>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_ses>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Services Confirmation Entered'
username = <fs_ses>-ernam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_ses>-erdat TIME <fs_ses>-eruhr INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_QUALITY_INSPECTION
*&---------------------------------------------------------------------*
FORM get_quality_inspection.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT q~ebeln, v~vdatum, v~vzeit, v~vname
FROM qals AS q JOIN qave AS v ON q~prueflos = v~prueflos
WHERE q~ebeln IN lt_ebeln
INTO TABLE @DATA(lt_qm).
LOOP AT lt_qm ASSIGNING FIELD-SYMBOL(<fs_qm>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_qm>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Quality Inspection Performed'
username = <fs_qm>-vname
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_qm>-vdatum TIME <fs_qm>-vzeit INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_GOODS_RETURNED
*&---------------------------------------------------------------------*
FORM get_goods_returned.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT k~ebeln, m~cpudt, m~cputm, m~usnam
FROM ekbe AS k JOIN mkpf AS m ON k~belnr = m~mblnr AND k~gjahr = m~mjahr
WHERE k~ebeln IN lt_ebeln AND k~bwart = '122'
INTO TABLE @DATA(lt_ret).
LOOP AT lt_ret ASSIGNING FIELD-SYMBOL(<fs_ret>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_ret>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Goods Returned'
username = <fs_ret>-usnam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_ret>-cpudt TIME <fs_ret>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_COMPLETED
*&---------------------------------------------------------------------*
FORM get_po_completed.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime
FROM cdhdr AS h JOIN cdpos AS p ON h~changenr = p~changenr AND h~objectid = p~objectid
WHERE h~objectclas = 'EINKBELEG' AND h~objectid IN lt_ebeln AND p~tabname = 'EKPO' AND p~fname = 'ELIKZ' AND p~value_new = 'X'
INTO TABLE @DATA(lt_cd_comp).
LOOP AT lt_cd_comp ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Completed'
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_DELETED
*&---------------------------------------------------------------------*
FORM get_po_deleted.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime
FROM cdhdr AS h JOIN cdpos AS p ON h~changenr = p~changenr AND h~objectid = p~objectid
WHERE h~objectclas = 'EINKBELEG' AND h~objectid IN lt_ebeln AND p~tabname = 'EKPO' AND p~fname = 'LOEKZ' AND p~value_new = 'L'
INTO TABLE @DATA(lt_cd_del).
LOOP AT lt_cd_del ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Deleted'
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form DOWNLOAD_TO_CSV
*&---------------------------------------------------------------------*
FORM download_to_csv.
DATA: lv_filename TYPE string.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'PurchaseOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'EventTime' TO lt_fieldnames.
APPEND 'UserName' TO lt_fieldnames.
APPEND 'VendorNumber' TO lt_fieldnames.
APPEND 'OrderAmount' TO lt_fieldnames.
APPEND 'MaterialGroup' TO lt_fieldnames.
APPEND 'CompanyCode' TO lt_fieldnames.
APPEND 'DocumentType' TO lt_fieldnames.
DATA(lv_header) = REDUCE string( INIT h = '' FOR f IN lt_fieldnames NEXT h = h && f && cl_abap_char_utilities=>horizontal_tab ).
REPLACE LAST OCCURRENCE OF cl_abap_char_utilities=>horizontal_tab IN lv_header WITH cl_abap_char_utilities=>cr_lf.
DATA(lv_file_content) = lv_header.
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_log>).
DATA lv_line TYPE string.
DATA lv_eventtime_str TYPE string.
lv_eventtime_str = |{ <fs_log>-eventtime TIMESTAMP = ISO }|.
lv_line = <fs_log>-purchaseorder && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-activity && cl_abap_char_utilities=>horizontal_tab &&
lv_eventtime_str && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-username && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-vendornumber && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-orderamount && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-materialgroup && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-companycode && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-documenttype && cl_abap_char_utilities=>cr_lf.
CONCATENATE lv_file_content lv_line INTO lv_file_content.
ENDLOOP.
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lv_file_content. Étapes
- Établir la connexion à la base de données : obtenez des identifiants en lecture seule ainsi que les informations de connexion à la base de données sous-jacente de SAP ECC (nom d’hôte, port et nom de la base). Vérifiez que les outils clients nécessaires, comme DBeaver, SQL Developer ou SSMS, sont installés.
- Repérer le schéma SAP : connectez-vous à la base de données et identifiez le schéma SAP principal qui contient les tables. Il s’agit souvent de SAPSR3, SAPHANADB ou d’un nom propre au système. Si ce schéma n’est pas celui par défaut de votre utilisateur, vous devrez le préfixer à tous les noms de tables dans la requête.
- Examiner la requête SQL : ouvrez le script SQL fourni dans votre outil client. Cette requête complète extrait 14 activités distinctes du processus Purchase to Pay en joignant plusieurs tables SAP.
- Personnaliser les paramètres de la requête : repérez l’expression de table commune (CTE) PO_BASE au début du script. Remplacez les valeurs fictives pour définir le périmètre de l’extraction :
- [START_DATE] et [END_DATE] : définissez la plage de dates de l’analyse, par exemple « 20230101 » et « 20230630 ». Il est recommandé de filtrer sur le champ AEDAT (date de modification).
- [COMPANY_CODE_1], [COMPANY_CODE_2] : indiquez les codes société SAP à inclure.
- [DOC_TYPE_1], [DOC_TYPE_2] : indiquez les types de document de commande d’achat à inclure.
- [Your SAP Schema] : remplacez ce texte par le nom réel de votre schéma SAP dans l’ensemble du script.
- Exécuter la requête : lancez le script SQL personnalisé sur la base de données SAP. La durée d’exécution dépendra de la plage de dates, du volume de données et des performances de la base.
- Vérifier les résultats : une fois la requête terminée, examinez rapidement les résultats. Vérifiez que le nombre de lignes est cohérent et que les colonnes clés, comme PurchaseOrder, Activity et EventTime, sont renseignées comme prévu.
- Exporter les données au format CSV : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Utilisez l’encodage UTF-8 pour éviter les problèmes de caractères.
- Préparer l’importation : vérifiez que les en-têtes de colonnes du fichier CSV correspondent exactement aux noms d’attributs requis : PurchaseOrder, Activity, EventTime, UserName, VendorNumber, OrderAmount, MaterialGroup, CompanyCode et DocumentType.
- Importer les données dans l’outil de Process Mining : importez le fichier CSV final dans votre application de Process Mining pour analyser et visualiser les données.
Configuration
- Prérequis : un accès direct en lecture seule à la base de données sous-jacente de SAP ECC est nécessaire. Les utilisateurs doivent disposer des autorisations suffisantes pour interroger des tables telles que EKKO, EKPO, EKBE, EBAN, CDHDR, CDPOS et NAST.
- Filtrage par plage de dates : appliquez un filtre de dates pour limiter le volume de données. Filtrer sur EKKO.AEDAT (date de modification de la commande d’achat) sur une période de 3 à 6 mois constitue un point de départ courant. Une plage plus étendue peut entraîner des temps d’exécution très longs.
- Filtres de données clés : pour cibler l’analyse, filtrez toujours sur EKKO.BUKRS (code société) et EKKO.BSART (type de document). Vous limiterez ainsi le périmètre aux entités juridiques et aux processus concernés.
- Performances : la requête joint plusieurs grandes tables, notamment les tables d’historique des modifications (CDHDR, CDPOS), ce qui peut mobiliser beaucoup de ressources. Il est fortement recommandé d’effectuer l’extraction en dehors des heures de pointe ou sur une base de données répliquée hors production, afin de ne pas affecter les performances du système.
- Journalisation des modifications de documents : l’exactitude des activités telles que « Approved », « Rejected », « Completed » et « Changed » dépend de l’activation de la journalisation des modifications pour les champs concernés dans SAP. Vérifiez auprès de votre administrateur SAP que cette journalisation est activée (via la transaction SCDO).
Exemple de requête sql
WITH PO_BASE AS (
SELECT
H.EBELN, -- Purchase Order Number
I.EBELP, -- Purchase Order Item
H.LIFNR, -- Vendor Number
H.BUKRS, -- Company Code
H.BSART, -- Document Type
I.NETWR, -- Order Amount (Item Level)
I.MATKL, -- Material Group
I.BANFN, -- Purchase Requisition Number
I.BNFPO -- Purchase Requisition Item
FROM [Your SAP Schema].EKKO AS H
JOIN [Your SAP Schema].EKPO AS I ON H.EBELN = I.EBELN
WHERE H.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' -- Filter on PO Change Date, e.g., '20230101' and '20231231'
AND H.BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]') -- Specify Company Codes
AND H.BSART IN ('[DOC_TYPE_1]', '[DOC_TYPE_2]') -- Specify PO Document Types
)
-- 1. Purchase Requisition Created
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Requisition Created' AS "Activity",
TO_TIMESTAMP(CONCAT(pr.ERDAT, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime", -- Time is not available in EBAN
pr.ERNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EBAN pr ON po.BANFN = pr.BANFN AND po.BNFPO = pr.BNFPO
WHERE po.BANFN IS NOT NULL AND po.BANFN <> ''
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Requisition Approved' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'BANF' AND ch.OBJECTID = po.BANFN
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EBAN' AND cp.FNAME = 'FRGZU' AND cp.VALUE_NEW = 'X' -- Release indicator set to 'released'
UNION ALL
-- 3. Purchase Order Created
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Created' AS "Activity",
TO_TIMESTAMP(CONCAT(ekko.ERDAT, ' ', ekko.ERZET), 'YYYYMMDD HH24MISS') AS "EventTime",
ekko.ERNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKKO ekko ON po.EBELN = ekko.EBELN
UNION ALL
-- 4. Purchase Order Approval Requested / 5. Approved / 6. Rejected (from Change Docs)
SELECT
po.EBELN AS "PurchaseOrder",
CASE
WHEN cp.VALUE_NEW > cp.VALUE_OLD THEN 'Purchase Order Approval Requested'
WHEN cp.VALUE_NEW = ekko.FRGKE AND ekko.FRGKE = 'R' THEN 'Purchase Order Approved'
ELSE 'Purchase Order Rejected' -- Simplified logic, may need adjustment
END AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKKO ekko ON po.EBELN = ekko.EBELN
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID = po.EBELN
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EKKO' AND cp.FNAME = 'FRGZU' -- Release status
UNION ALL
-- 7. Purchase Order Sent to Vendor
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Sent to Vendor' AS "Activity",
TO_TIMESTAMP(CONCAT(na.ERDAT, ' ', na.ERUHR), 'YYYYMMDD HH24MISS') AS "EventTime",
na.USNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].NAST na ON na.OBJKY = po.EBELN AND na.KSCHL = '[Your PO Output Type]' -- e.g., 'NEU'
WHERE na.VSTAT = '1' -- Successfully processed
UNION ALL
-- 8. Purchase Order Changed
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Changed' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID = po.EBELN
WHERE ch.TCODE IN ('ME22', 'ME22N') -- Filter for change transactions
UNION ALL
-- 9. Goods Receipt Posted
SELECT
ekbe.EBELN AS "PurchaseOrder",
'Goods Receipt Posted' AS "Activity",
TO_TIMESTAMP(CONCAT(mkpf.CPUDT, ' ', mkpf.CPUTM), 'YYYYMMDD HH24MISS') AS "EventTime",
mkpf.USNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM [Your SAP Schema].EKBE AS ekbe
JOIN [Your SAP Schema].MKPF AS mkpf ON ekbe.BELNR = mkpf.MBLNR AND ekbe.GJAHR = mkpf.MJAHR
JOIN PO_BASE AS po ON ekbe.EBELN = po.EBELN AND ekbe.EBELP = po.EBELP
WHERE ekbe.BEWTP = 'E' -- Goods Receipt
AND ekbe.SHKZG = 'S' -- Debit/Credit Indicator: Goods Receipt
UNION ALL
-- 10. Services Confirmation Entered
SELECT
po.EBELN AS "PurchaseOrder",
'Services Confirmation Entered' AS "Activity",
TO_TIMESTAMP(CONCAT(essr.ERDAT, ' ', essr.ERZET), 'YYYYMMDD HH24MISS') AS "EventTime",
essr.ERNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKBE ekbe ON po.EBELN = ekbe.EBELN AND po.EBELP = ekbe.EBELP
JOIN [Your SAP Schema].ESSR essr ON ekbe.LBLNI = essr.LBLNI
WHERE ekbe.BEWTP = 'L' -- Service Entry Sheet
UNION ALL
-- 11. Quality Inspection Performed
SELECT
po.EBELN AS "PurchaseOrder",
'Quality Inspection Performed' AS "Activity",
TO_TIMESTAMP(CONCAT(qave.VDATUM, ' ', qave.VZEIT), 'YYYYMMDD HH24MISS') AS "EventTime",
qave.VNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKBE ekbe ON po.EBELN = ekbe.EBELN AND po.EBELP = ekbe.EBELP
JOIN [Your SAP Schema].QALS qals ON qals.MBLNR = ekbe.BELNR AND qals.MJAHR = ekbe.GJAHR
JOIN [Your SAP Schema].QAVE qave ON qals.PRUEFLOS = qave.PRUEFLOS
WHERE ekbe.BEWTP = 'E' -- Linked to a Goods Receipt
UNION ALL
-- 12. Goods Returned
SELECT
ekbe.EBELN AS "PurchaseOrder",
'Goods Returned' AS "Activity",
TO_TIMESTAMP(CONCAT(mkpf.CPUDT, ' ', mkpf.CPUTM), 'YYYYMMDD HH24MISS') AS "EventTime",
mkpf.USNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM [Your SAP Schema].EKBE AS ekbe
JOIN [Your SAP Schema].MKPF AS mkpf ON ekbe.BELNR = mkpf.MBLNR AND ekbe.GJAHR = mkpf.MJAHR
JOIN PO_BASE AS po ON ekbe.EBELN = po.EBELN AND ekbe.EBELP = po.EBELP
WHERE ekbe.BEWTP = 'E' -- Goods Movement
AND ekbe.SHKZG = 'H' -- Debit/Credit Indicator: Return
AND ekbe.BWART = '122' -- Movement type for return to vendor
UNION ALL
-- 13. Purchase Order Completed
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Completed' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID LIKE CONCAT(po.EBELN, po.EBELP, '%')
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EKPO' AND cp.FNAME = 'ELIKZ' AND cp.VALUE_NEW = 'X' -- Delivery completed indicator
UNION ALL
-- 14. Purchase Order Deleted
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Deleted' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID LIKE CONCAT(po.EBELN, po.EBELP, '%')
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EKPO' AND cp.FNAME = 'LOEKZ' AND cp.VALUE_NEW = 'L'; -- Deletion indicator Étapes
- Prérequis et connexion : vérifiez que votre outil ETL dispose d’un connecteur certifié SAP installé et sous licence. Dans la console d’administration de l’outil ETL, configurez une nouvelle connexion à votre système SAP ECC. Vous aurez besoin de l’hôte du serveur d’applications, du numéro de système, de l’ID client et d’un compte utilisateur SAP dédié disposant des autorisations RFC et de lecture des tables nécessaires.
- Repérer les tables sources : dans votre tâche ETL ou votre flux de données, définissez les tables SAP requises comme sources de données. Les principales tables sont EKKO (en-tête de commande d’achat), EKPO (poste de commande d’achat), EBAN (demande d’achat), CDHDR (en-tête du document de modification), CDPOS (poste du document de modification), MSEG (segment de document article), MKPF (en-tête du document article), NAST (statut du message), ESSR (en-tête de la feuille de saisie des services) et QALS (lot de contrôle).
- Extraire « Purchase Order Created » : créez un flux de données à partir de la table EKKO. Filtrez les enregistrements selon la plage de dates souhaitée, par exemple à l’aide de AEDAT, et le périmètre organisationnel, par exemple BUKRS pour le code société et BSART pour le type de document. Associez EKKO.EBELN à PurchaseOrder, « Purchase Order Created » à Activity, puis combinez AEDAT et ERZET pour renseigner EventTime. Associez également les autres attributs requis.
- Extraire « Goods Receipt Posted » : créez un flux de données distinct à partir de MSEG, avec une jointure à MKPF sur MBLNR et MJAHR. Filtrez les types de mouvement pertinents, par exemple « 101 ». Associez MSEG.EBELN à PurchaseOrder, « Goods Receipt Posted » à Activity, puis utilisez MKPF.CPUDT et MKPF.CPUTM pour renseigner EventTime.
- Extraire les événements liés aux modifications (approbations, changements, suppressions) : créez un flux de données à partir de CDHDR et CDPOS, avec une jointure sur CHANGENR. Cette source unique permet de dériver plusieurs activités.
- Filtrez OBJECTCLAS = 'EINKBELEG' et TABNAME = 'EKPO'.
- Pour « Purchase Order Approved », filtrez les modifications du champ de statut de validation, par exemple FNAME = 'FRGZU', lorsque la nouvelle valeur (VALUE_NEW) indique l’approbation finale.
- Pour « Purchase Order Deleted », filtrez les modifications de l’indicateur de suppression (FNAME = 'LOEKZ') lorsque la nouvelle valeur est 'L'.
- Pour « Purchase Order Changed », filtrez les modifications d’autres champs pertinents, à l’exclusion des champs de statut utilisés pour les autres activités.
- Pour tous ces événements, utilisez CDHDR.UDATE et CDHDR.UTIME pour renseigner EventTime.
- Extraire les événements des demandes d’achat : créez un flux de données à partir d’EBAN pour l’événement « Purchase Requisition Created ». Pour rattacher cet événement à un cas de commande d’achat, joignez EBAN à EKPO à l’aide du numéro de demande (BANFN) et du poste (BNFPO). Pour l’événement « Purchase Requisition Approved », utilisez CDHDR/CDPOS avec OBJECTCLAS = 'BANF'. Associez soigneusement les données afin de rattacher l’événement à la commande d’achat correspondante.
- Extraire « PO Sent to Vendor » : créez un flux de données à partir de la table NAST. Filtrez sur OBJECTKEY, qui contient le numéro de commande d’achat, le type de sortie pertinent (KSCHL) et le statut de traitement réussi (VSTAT = '1'). Utilisez ERDAT et UHR pour renseigner EventTime.
- Combiner les flux d’activités : utilisez une transformation « Union » ou « Merge » dans votre outil ETL pour regrouper les résultats de tous les flux de données créés aux étapes précédentes. Vérifiez que les noms et les types de colonnes sont cohérents dans tous les flux (PurchaseOrder, Activity, EventTime, etc.).
- Convertir les types et les formats de données : convertissez la colonne EventTime dans un format d’horodatage uniforme, par exemple YYYY-MM-DD HH:MM:SS. Convertissez OrderAmount dans un format décimal standard.
- Définir la destination : configurez une destination, ou « sink », pour le flux de données combiné. Il s’agit généralement d’un fichier plat, comme un fichier CSV ou Parquet. Définissez le séparateur, les délimiteurs de texte et les options d’en-tête.
- Exécuter et valider : exécutez la tâche ETL complète. Vérifiez le fichier de sortie pour confirmer la présence des 14 activités, la cohérence du nombre de lignes et le bon renseignement des attributs clés.
- Planifier et exporter : une fois les données validées, planifiez l’exécution périodique de la tâche ETL, par exemple chaque nuit, afin de les maintenir à jour. Le fichier généré est alors prêt à être importé dans votre outil de Process Mining.
Configuration
- Prérequis : un outil ETL commercial (par exemple, Informatica PowerCenter, Talend ou SAP Data Services) avec le connecteur certifié SAP correspondant pour ECC. Un utilisateur de dialogue SAP ou un utilisateur système disposant des autorisations S_RFC et S_TABU_DIS pour les tables requises.
- Connexion SAP : le connecteur doit être configuré avec le serveur d’applications SAP, le numéro de système, le mandant, l’utilisateur et le mot de passe. L’utilisation de Secure Network Communications (SNC) est recommandée.
- Filtre de plage de dates : il est essentiel d’appliquer un filtre de plage de dates pour limiter le volume de données. Il est courant de filtrer EKKO.AEDAT (date de création de la commande d’achat) sur les 3 à 12 derniers mois. Appliquez ce filtre à la source afin d’éviter d’extraire un volume excessif de données depuis SAP.
- Filtres de périmètre organisationnel : filtrez toujours sur EKKO.BUKRS (code société) et envisagez également un filtre sur EKPO.WERKS (division) ou EKKO.EKORG (organisation d’achats) pour limiter l’analyse à une unité opérationnelle précise.
- Filtre de type de document : utilisez EKKO.BSART pour inclure uniquement les types de commandes d’achat pertinents et exclure les transferts de stock ou autres documents internes qui ne relèvent pas du processus P2P standard.
- Optimisation des performances : l’extraction des tables de documents de modification (CDHDR, CDPOS) peut être lente. Veillez à appliquer des filtres sur OBJECTCLAS, OBJECTID et UDATE. Ajustez le paramètre « Packet Size » du connecteur SAP pour optimiser les débits de transfert. Pour les systèmes de très grande taille, envisagez un chargement initial de l’historique, suivi de chargements différentiels planifiés.
Exemple de requête sql
/*
This is a logical representation of the transformations performed within the ETL tool.
The tool's graphical interface will be used to configure these separate data flows, which are then combined with a UNION transformation.
Placeholders like [Your ETL Tool Functions] and [Filter Values] must be configured in the tool.
*/
-- 1. Purchase Requisition Created
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Requisition Created' AS Activity,
[Your ETL Tool Functions].DateTime(eban.ERDAT, eban.ERZET) AS EventTime,
eban.ERNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM EBAN AS eban
INNER JOIN EKPO AS ekpo ON eban.BANFN = ekpo.BANFN AND eban.BNFPO = ekpo.BNFPO
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 2. Purchase Requisition Approved (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Requisition Approved' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EBAN AS eban ON cdhdr.OBJECTID = eban.BANFN
INNER JOIN EKPO AS ekpo ON eban.BANFN = ekpo.BANFN AND eban.BNFPO = ekpo.BNFPO
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE cdhdr.OBJECTCLAS = 'BANF' AND cdpos.TABNAME = 'EBAN' AND cdpos.FNAME = 'FRGZU' AND cdpos.VALUE_NEW = '[Final Release Indicator for PR]'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 3. Purchase Order Created
SELECT
EBELN AS PurchaseOrder,
'Purchase Order Created' AS Activity,
[Your ETL Tool Functions].DateTime(AEDAT, ERZET) AS EventTime,
ERNAM AS UserName,
LIFNR AS VendorNumber,
NULL AS OrderAmount, -- Amount is at item level
NULL AS MaterialGroup, -- Attribute is at item level
BUKRS AS CompanyCode,
BSART AS DocumentType
FROM EKKO
WHERE AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 4. Purchase Order Approval Requested / 5. Approved / 6. Rejected (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
CASE
WHEN cdpos.VALUE_NEW = '[Final Release Code]' THEN 'Purchase Order Approved'
WHEN cdpos.VALUE_NEW = '[Rejection Release Code]' THEN 'Purchase Order Rejected'
ELSE 'Purchase Order Approval Requested'
END AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKKO AS ekko ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekko.EBELN
INNER JOIN EKPO AS ekpo ON ekko.EBELN = ekpo.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.TABNAME = 'EKKO' AND cdpos.FNAME = 'FRGKE'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 7. Purchase Order Sent to Vendor
SELECT
ekko.EBELN AS PurchaseOrder,
'Purchase Order Sent to Vendor' AS Activity,
[Your ETL Tool Functions].DateTime(nast.ERDAT, nast.UHR) AS EventTime,
nast.USNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM NAST AS nast
INNER JOIN EKKO AS ekko ON nast.OBJKY = ekko.EBELN
INNER JOIN EKPO AS ekpo ON ekko.EBELN = ekpo.EBELN
WHERE nast.KAPPL = 'EF' AND nast.VSTAT = '1' AND nast.KSCHL IN ([Your PO Output Types])
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 8. Purchase Order Changed (inferred from change documents, simplified example)
SELECT DISTINCT
ekko.EBELN AS PurchaseOrder,
'Purchase Order Changed' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKKO AS ekko ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekko.EBELN
INNER JOIN EKPO AS ekpo ON ekko.EBELN = ekpo.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.FNAME NOT IN ('FRGKE', 'FRGZU', 'LOEKZ', 'ELIKZ')
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 9. Goods Receipt Posted
SELECT
mseg.EBELN AS PurchaseOrder,
'Goods Receipt Posted' AS Activity,
[Your ETL Tool Functions].DateTime(mkpf.CPUDT, mkpf.CPUTM) AS EventTime,
mkpf.USNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM MSEG AS mseg
INNER JOIN MKPF AS mkpf ON mseg.MBLNR = mkpf.MBLNR AND mseg.MJAHR = mkpf.MJAHR
INNER JOIN EKPO AS ekpo ON mseg.EBELN = ekpo.EBELN AND mseg.EBELP = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE mseg.BWART = '101' AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 10. Services Confirmation Entered
SELECT
essr.EBELN AS PurchaseOrder,
'Services Confirmation Entered' AS Activity,
[Your ETL Tool Functions].DateTime(essr.ERDAT, essr.ERZET) AS EventTime,
essr.ERNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM ESSR AS essr
INNER JOIN EKKO AS ekko ON essr.EBELN = ekko.EBELN
INNER JOIN EKPO AS ekpo ON essr.EBELN = ekpo.EBELN AND essr.EBELP = ekpo.EBELP
WHERE ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 11. Quality Inspection Performed
SELECT
qals.EBELN AS PurchaseOrder,
'Quality Inspection Performed' AS Activity,
[Your ETL Tool Functions].DateTime(qals.PASTRTERM, '000000') AS EventTime, -- Time is often not available
qals.PRUEFER AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM QALS AS qals
INNER JOIN EKKO AS ekko ON qals.EBELN = ekko.EBELN
INNER JOIN EKPO AS ekpo ON qals.EBELN = ekpo.EBELN AND qals.EBELP = ekpo.EBELP
WHERE qals.VCODE <> '' -- A usage decision code exists
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 12. Goods Returned
SELECT
mseg.EBELN AS PurchaseOrder,
'Goods Returned' AS Activity,
[Your ETL Tool Functions].DateTime(mkpf.CPUDT, mkpf.CPUTM) AS EventTime,
mkpf.USNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM MSEG AS mseg
INNER JOIN MKPF AS mkpf ON mseg.MBLNR = mkpf.MBLNR AND mseg.MJAHR = mkpf.MJAHR
INNER JOIN EKPO AS ekpo ON mseg.EBELN = ekpo.EBELN AND mseg.EBELP = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE mseg.BWART = '122' AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 13. Purchase Order Completed (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Order Completed' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKPO AS ekpo ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekpo.EBELN AND SUBSTRING(cdhdr.OBJECTID, 11, 5) = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.TABNAME = 'EKPO' AND cdpos.FNAME = 'ELIKZ' AND cdpos.VALUE_NEW = 'X'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 14. Purchase Order Deleted (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Order Deleted' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKPO AS ekpo ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekpo.EBELN AND SUBSTRING(cdhdr.OBJECTID, 11, 5) = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.TABNAME = 'EKPO' AND cdpos.FNAME = 'LOEKZ' AND cdpos.VALUE_NEW = 'L'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]); Prêt à commencer ?
Ce modèle vous fournit une base pour optimiser votre processus Purchase to Pay, commandes d’achat, dans SAP ECC. Commencez dès aujourd’hui à utiliser vos données pour repérer les possibilités d’amélioration et gagner en efficacité.
Optimisez les commandes d’achat P2P : démarrez votre essai gratuit dès aujourd’hui
Éliminez les goulots d’étranglement et réduisez le temps de cycle de 30 % ou plus.
Aucune carte bancaire requise. Commencez en quelques minutes.