Votre modèle de données Purchase to Pay, commande d’achat
Votre modèle de données Purchase to Pay, commande d’achat
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d’extraction pour SAP ECC
Purchase to Pay - Purchase Order : attributs
| Nom | Description | ||
|---|---|---|---|
| Activité Activity | Nom de l’événement ou de l’étape métier précis qui s’est produit au cours du cycle de vie de la commande d’achat. | ||
| Description Cet attribut décrit une étape particulière du processus, telle que « Commande d’achat créée », « Commande d’achat approuvée » ou « Réception des marchandises enregistrée ». La séquence de ces activités forme le flux du 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 constitue le cœur du Process Mining. Elle aide à identifier les goulots d’étranglement, les boucles de reprise et les écarts par rapport au processus standard, afin de mettre en place des améliorations ciblées et des actions de standardisation. Pourquoi c’est important Les activités définissent les étapes du processus. L’analyse de leur séquence et de leur durée révèle le flux réel du processus, les goulots d’étranglement et les écarts. Où les obtenir Dérivé de différentes tables SAP et de journaux de transactions, notamment CDHDR/CDPOS pour les modifications, EKBE pour les réceptions et factures, et EBAN pour les demandes d’achat. La génération de cet attribut nécessite souvent une logique personnalisée ou un programme d’extraction. Exemples Commande d’achat crééeCommande d’achat approuvéeRéception de marchandises enregistrée | |||
| Commande d’achat PurchaseOrder | Identifiant unique du document de commande d’achat, qui sert de cas principal pour suivre le 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 à l’achèvement de la commande. Chaque numéro de commande unique représente une instance du processus d’approvisionnement. Dans le 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 les contrôles de conformité pour chaque commande, constituant ainsi le fondement de l’ensemble du modèle de processus. Pourquoi c’est important Il s’agit de l’identifiant principal qui relie tous les événements associés et permet d’analyser le cycle de vie complet de chaque commande d’achat. Où les obtenir 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 l’enregistrement d’une réception de marchandises. Il fournit l’ordre chronologique de toutes les activités d’un cas. Les horodatages sont fondamentaux pour le Process Mining, car ils permettent toutes les analyses temporelles. Il s’agit notamment de calculer les durées de cycle entre les activités, d’identifier les retards, d’analyser le débit du processus et de mesurer la performance par rapport aux accords de niveau de service (SLA). Pourquoi c’est important Cet horodatage est essentiel pour calculer toutes les métriques fondées sur la durée, comme les temps de cycle et les goulots d’étranglement, et pour classer les événements par ordre chronologique. Où les obtenir 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 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 | Identifiant de l’entité juridique ou de la société à l’origine de l’achat. | ||
| Description Le code société représente une entité juridique indépendante dans SAP. 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é et la conformité des approvisionnements entre différentes unités opérationnelles ou différents pays. Elle aide à repérer les bonnes pratiques d’une entité qui pourraient être reproduites ailleurs, ou à identifier les unités rencontrant des difficultés dans le processus. Pourquoi c’est important Représente l’entité juridique et permet de comparer la performance des processus et d’effectuer des contrôles de conformité entre les différentes composantes de l’organisation. Où les obtenir Table : EKKO, champ : BUKRS Exemples 10002100US01 | |||
| Groupe de marchandises MaterialGroup | Classification permettant de regrouper des marchandises ou des services présentant des caractéristiques similaires. | ||
| Description Le groupe de marchandises, ou catégorie d’achat, sert à classer le type de biens ou de services achetés. Il peut s’agir, par exemple, de « matériel informatique », de « fournitures de bureau » ou de « services professionnels ». Cet attribut est essentiel à l’analyse des dépenses et à la compréhension des habitudes d’approvisionnement. Il permet de filtrer le processus afin d’analyser le traitement des différentes catégories, les personnes qui les approuvent et les fournisseurs qui les proposent. Il constitue une dimension clé du Dashboard « Analyse de la valeur des commandes d’achat ». Pourquoi c’est important Permet de segmenter le processus par catégorie de produit ou de service et de révéler les comportements, les durées de cycle ou les fournisseurs propres à chaque type de dépense. Où les obtenir 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 donné de la commande d’achat, calculée en multipliant la quantité par le prix net. Pour obtenir la valeur totale d’une commande, les montants des postes doivent être agrégés. L’analyse du processus par montant de commande est essentielle pour identifier les transactions de grande valeur susceptibles de 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 fort impact financier. Pourquoi c’est important Quantifie l’impact financier de chaque achat et permet de prioriser les commandes de grande valeur ou d’identifier des possibilités de réduction des coûts. Où les obtenir 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 enregistre le nom d’utilisateur SAP du collaborateur qui a créé, modifié ou approuvé un document. Pour les étapes automatisées, il peut afficher l’identifiant d’un utilisateur système ou d’un utilisateur de traitement par lots. L’analyse par utilisateur aide à identifier les besoins de formation, les collaborateurs les plus performants ou d’éventuels problèmes de conformité. Elle est essentielle pour créer des Dashboards liés à la répartition de la charge de travail, au respect de la matrice d’approbation et à la performance des différentes équipes ou personnes. Pourquoi c’est important Attribue les actions des utilisateurs à des personnes précises, ce qui permet d’analyser leur performance, leur charge de travail et leur respect des protocoles de conformité. Où les obtenir 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 Il s’agit du code qui identifie de manière unique le fournisseur auprès duquel les biens ou services sont achetés. C’est un élément essentiel des données de référence du processus d’approvisionnement. Cet attribut est indispensable à l’analyse centrée sur les fournisseurs. Il permet d’évaluer leur performance de livraison, de comparer les délais entre différents fournisseurs et d’analyser les habitudes de dépenses. Il constitue la dimension principale du Dashboard « Performance de livraison des fournisseurs ». Pourquoi c’est important Permet d’analyser la performance des fournisseurs et d’identifier ceux qui sont fiables ainsi que ceux qui sont à l’origine de retards ou de problèmes de qualité. Où les obtenir Table : EKKO, champ : LIFNR Exemples 100345V-20598700112 | |||
| Type de document DocumentType | Code permettant de classer les différents types de commandes d’achat. | ||
| Description Le type de document est un paramètre de configuration SAP qui contrôle la plage de numérotation, la sélection des champs et le flux global du processus d’une commande d’achat. Il peut, par exemple, exister des types différents pour les commandes standard, les commandes de services ou les commandes de transfert de stock. Cet attribut constitue une dimension d’analyse particulièrement utile, car les différents types de documents suivent souvent des processus volontairement distincts. Le filtrage par type de document permet de comparer plus précisément les durées de cycle et les flux de processus. Pourquoi c’est 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ù les obtenir 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 la performance réelle de la livraison. Cette date est essentielle pour calculer le KPI de taux de réception des marchandises dans les délais. En comparant la date réelle de réception à la date demandée, les organisations peuvent mesurer quantitativement la fiabilité des fournisseurs et l’efficacité interne de la réception, ce qui contribue directement au Dashboard « Performance de livraison des fournisseurs ». Pourquoi c’est important Il s’agit de la date cible de livraison, essentielle au calcul des KPI de ponctualité et à l’évaluation de la fiabilité des fournisseurs. Où les obtenir 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 d’achat. | ||
| Description Cet attribut relie la commande d’achat à la demande d’achat dont elle est issue. Toutes les commandes d’achat ne sont pas précédées d’une demande. Ce lien est essentiel pour analyser le Dashboard « Conversion des demandes en commandes » et le KPI de 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 formelle, et d’identifier les commandes non conformes créées sans demande préalable. Pourquoi c’est important Relie la commande d’achat à la demande à son origine et permet d’analyser le processus de conversion des demandes en commandes ainsi que d’identifier les commandes créées sans demande préalable. Où les obtenir Table : EKPO, champ : BANFN Exemples 1001589010015891 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant le moment où les données ont été actualisées pour la dernière fois depuis le système source. | ||
| Description Cet attribut enregistre la date et l’heure de l’extraction ou de la mise à jour la plus récente des données. Il fournit un contexte sur leur fraîcheur au moment de l’analyse. L’affichage de cette information dans les Dashboards est essentiel pour permettre aux utilisateurs de savoir si les analyses reposent sur des données quasi en temps réel ou sur un instantané historique. Il permet de gérer les attentes et de garantir que les décisions s’appuient sur des données dont l’ancienneté est connue. Pourquoi c’est important Informe les utilisateurs sur l’actualité des données et leur permet de savoir si l’analyse reflète l’état le plus récent des opérations. Où les obtenir Cet horodatage est généré et ajouté par le processus d’extraction des données ou le processus ETL au moment de son exécution. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Code devise du montant de la commande d’achat. | ||
| Description Cet attribut précise la devise dans laquelle la valeur de la commande d’achat est exprimée, 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 correcte. Elle permet d’agréger et de comparer convenablement les valeurs des commandes, et tous les KPI financiers doivent être interprétés en tenant compte de leur devise. Pourquoi c’est important Fournit le contexte nécessaire à l’interprétation de tous les montants et garantit une analyse financière exacte, notamment dans les organisations internationales. Où les obtenir Table : EKKO, champ : WAERS Exemples USDEURJPY | |||
| Groupe d’acheteurs PurchasingGroup | Acheteur ou groupe d’acheteurs précisément responsable de l’activité d’approvisionnement. | ||
| Description Le groupe d’acheteurs représente la personne ou l’équipe chargée d’une activité d’achat donnée. Il constitue le principal interlocuteur des fournisseurs. Cet attribut offre un niveau d’analyse plus détaillé que l’organisation d’achat. Il aide à comprendre la répartition de la charge de travail entre les acheteurs et à identifier les écarts de performance à leur niveau, afin d’éclairer l’allocation des ressources et les actions de formation. Pourquoi c’est important Fournit une vue détaillée de la personne responsable d’un achat et permet d’analyser précisément la charge de travail et la performance au niveau de l’acheteur ou de l’équipe. Où les obtenir Table : EKKO, champ : EKGRP Exemples 001002N01 | |||
| Livraison dans les délais IsOnTimeDelivery | Indicateur signalant si les marchandises ont été réceptionnées à la date de livraison demandée ou avant celle-ci. | ||
| Description Cet attribut booléen vaut true si l’horodatage de l’activité « Goods Receipt Posted » est antérieur ou égal à la « Requested Delivery Date ». Il fournit un résultat binaire clair sur la performance de livraison de chaque poste de bon de commande. Cet attribut constitue la base du KPI « On-Time Goods Receipt Rate ». Il simplifie l’analyse de la performance des fournisseurs et de l’efficacité de la réception interne en facilitant l’agrégation et le filtrage des livraisons effectuées dans les délais ou en retard. Pourquoi c’est important Fournit une mesure claire de réussite ou d’échec concernant le respect des délais de livraison et alimente directement les KPI et Dashboards de performance fournisseurs. Où les obtenir Il s’agit d’un attribut calculé en comparant 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 modification du bon de commande est intervenue après l’approbation initiale. | ||
| Description Cet attribut booléen vaut true si une activité « Purchase Order Changed » est détectée après une activité « Purchase Order Approved » pour le même bon de commande. Il permet d’isoler les modifications problématiques intervenant tardivement dans le processus. Ce champ calculé alimente directement le KPI « 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, révélant ainsi des problèmes dans la spécification initiale ou le cadrage du besoin. Pourquoi c’est important Mesure directement les reprises après approbation, un KPI essentiel pour évaluer la stabilité et l’efficacité du processus. Des taux élevés indiquent des problèmes dans la définition des besoins en amont. Où les obtenir Il s’agit d’un attribut calculé à partir de la séquence des activités dans l’Event Log. Exemples truefalse | |||
| Motif du rejet RejectionReason | Code ou texte expliquant pourquoi une demande d’achat ou un bon de commande a été rejeté. | ||
| Description Cet attribut enregistre le motif précis fourni lorsqu’une commande d’achat est rejetée pendant le flux de travail d’approbation. Ces informations sont essentielles pour comprendre les causes profondes des reprises et des retards. L’analyse des motifs de rejet aide à identifier les problèmes fréquents, comme un prix incorrect, un dépassement budgétaire ou une sélection de fournisseur non conforme. L’entreprise peut ainsi traiter les causes profondes, améliorer la qualité de la création initiale des PO et optimiser le processus d’approbation. Pourquoi c’est important Fournit une visibilité directe sur les raisons des échecs d’approbation et permet de cibler les améliorations afin de réduire les reprises et de raccourcir les délais du cycle d’approbation. Où les obtenir Ces informations peuvent être difficiles à trouver. Elles peuvent être stockées dans des champs de texte longs ou dépendre d’une configuration personnalisée du flux de travail. Leur identification nécessite souvent des connaissances spécifiques de l’implémentation. Exemples Prix incorrectBudget dépasséDemande en double | |||
| Nom du fournisseur VendorName | Dénomination légale du fournisseur. | ||
| Description Nom descriptif du fournisseur, plus facile à utiliser que son numéro. Il provient généralement des données de référence des fournisseurs. Alors que le numéro de fournisseur sert aux jointures et à l’identification unique, le nom du fournisseur est essentiel dans les Dashboards et rapports destinés aux utilisateurs. Il rend les analyses plus intuitives et accessibles aux utilisateurs métier qui ne connaissent pas nécessairement les codes fournisseurs. Pourquoi c’est important Fournit un nom lisible pour le fournisseur et facilite ainsi la compréhension des Dashboards et des rapports par les utilisateurs métier. Où les obtenir 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’achat PurchasingOrganization | Unité organisationnelle chargée de négocier les prix et d’acheter les marchandises ou les services. | ||
| Description L’organisation d’achat est une unité organisationnelle SAP essentielle, responsable des activités d’approvisionnement. Elle peut être centralisée pour l’ensemble de l’entreprise ou décentralisée par site ou par région. L’analyse de la performance des processus par organisation d’achat aide à identifier les équipes d’approvisionnement les plus efficaces. Elle permet de comparer des indicateurs tels que la durée de cycle, les taux de reprise et les coûts entre différentes unités organisationnelles, afin de mettre en évidence les bonnes pratiques et les domaines nécessitant un soutien. Pourquoi c’est important Identifie l’équipe d’approvisionnement responsable et permet de comparer les performances et d’analyser les résultats entre différentes unités organisationnelles. Où les obtenir 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 représentant une installation de production, un entrepôt ou tout autre lieu où les biens ou services sont reçus. L’analyse par site aide à comprendre les variations géographiques du processus d’approvisionnement. Elle peut révéler des différences dans les délais de livraison des fournisseurs vers certains lieux ou mettre en évidence des sites dont les processus de réception sont inefficaces, ce qui facilite l’analyse de la ponctualité des réceptions. Pourquoi c’est important Précise le lieu de livraison et permet d’analyser les différences régionales entre les processus ainsi que la performance logistique. Où les obtenir Table : EKPO, champ : WERKS Exemples 100011002000 | |||
| Système source SourceSystem | Système à partir duquel les données ont été extraites. | ||
| Description Cet attribut identifie l’origine des données, généralement l’identifiant d’une instance SAP ECC, par exemple « ECC_PROD_100 ». Dans les environnements comportant plusieurs systèmes, il permet de différencier les sources de données. Pour la gouvernance et la traçabilité des données, il est essentiel de connaître le système source. Cela garantit l’intégrité des données et facilite le diagnostic des problèmes d’extraction ou de qualité, notamment lorsque les données sont fusionnées à partir de différents systèmes ERP ou modules. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour la gouvernance et la validation des données, ainsi que pour la gestion des analyses sur plusieurs systèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données afin d’indiquer le système d’origine du jeu de données. Exemples SAP_ECC_PRODECC_EU_100S4H_FIN | |||
Purchase to Pay - Purchase Order : activités
| Activité | Description | ||
|---|---|---|---|
| Commande d’achat approuvée | Représente l’approbation finale de la commande d’achat, qui autorise son envoi au fournisseur. Cette étape clé est généralement déduite du passage du statut de validation de la commande à l’état « entièrement validée » ou « approuvée ». | ||
| Pourquoi c’est important Cette activité est essentielle au calcul de l’indicateur de temps de cycle d’approbation de la PO et à l’identification des goulots d’étranglement du 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ù les obtenir Déduit du suivi des journaux de modifications, CDHDR/CDPOS, de la table d’en-tête des commandes d’achat, EKKO, afin de déterminer quand le code de validation final est appliqué ou quand l’indicateur de statut global de validation, EKKO-FRGKE, prend la valeur « validée ». Collecte Identifiez l’horodatage auquel le statut global de validation de la commande d’achat, EKKO-FRGKE, passe à l’état final approuvé. Type d’événement inferred | |||
| Commande d’achat créée | Cette activité indique la création d’un document formel 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 sauvegarde une commande d’achat, par exemple avec la transaction ME21N, ce qui entraîne la création d’entrées dans les tables EKKO et EKPO. | ||
| Pourquoi c’est important Elle marque le début officiel du cycle de vie de la commande d’achat. Elle constitue une étape clé pour mesurer à la fois le délai de conversion d’une demande d’achat en commande et le délai global d’exécution de la commande. Où les obtenir Capturé à partir 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. Collecte 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 le moment où la commande d’achat approuvée est officiellement transmise au fournisseur, par exemple par EDI, e-mail ou impression. 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 c’est important Il s’agit d’une étape clé qui déclenche le délai de livraison du fournisseur. L’analyse du délai entre cet événement et la réception des marchandises est essentielle pour évaluer la performance du fournisseur et le respect des délais de livraison. Où les obtenir Enregistré dans la table des statuts de messages, NAST. L’horodatage peut être extrait de NAST-DATVR et NAST-UHRVR lorsque le statut de traitement, NAST-VSTAT, vaut « 1 », c’est-à-dire lorsque le traitement a réussi pour le type de message de sortie concerné de la commande d’achat. Collecte 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é. Il s’agit d’un événement déduit, généralement à partir de l’activation automatique ou manuelle de l’indicateur « Livraison terminée » sur le poste de commande. | ||
| Pourquoi c’est important Cette activité constitue le point final logique de la partie exécution de la commande. Elle est essentielle pour calculer la durée du cycle global de la commande d’achat, de sa création à son achèvement. Où les obtenir Déduit des documents de modification, CDHDR/CDPOS, qui enregistrent le moment où l’indicateur « Livraison terminée », EKPO-ELIKZ, prend la valeur « X » pour un poste de commande. Le dernier poste marqué comme terminé peut signifier l’achèvement de l’ensemble de la commande. Collecte Identifiez l’horodatage des documents de modification au moment où l’indicateur EKPO-ELIKZ est activé. Type d’événement inferred | |||
| Demande d’achat créée | Cette activité marque la création d’une demande formelle de biens ou de services. Il s’agit d’un événement explicite enregistré lorsqu’un utilisateur sauvegarde un nouveau document de demande d’achat, par exemple avec la transaction ME51N, ce qui génère un enregistrement unique dans la table EBAN. | ||
| Pourquoi c’est important Il s’agit du principal point de départ 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 transformée en commandes concrètes. Où les obtenir Enregistré lors de la création d’une entrée dans la table d’en-tête des demandes d’achat, EBAN. La date de création (EBAN-BADAT) et l’heure servent d’horodatage pour cet événement. Collecte Identifiez les nouvelles entrées de la table EBAN en fonction de leur date de création. Type d’événement explicit | |||
| Réception de marchandises enregistrée | Cette activité indique la réception physique de marchandises provenant d’un fournisseur pour une commande d’achat donnée. L’enregistrement de la réception des marchandises est une action explicite, effectuée par exemple avec la transaction MIGO, qui crée un document article et met à jour les stocks. | ||
| Pourquoi c’est important Il s’agit d’une étape clé pour suivre la performance de livraison du fournisseur et le début du processus de vérification des factures. Elle sert à calculer les taux de livraison dans les délais et la ponctualité de l’enregistrement des réceptions. Où les obtenir Enregistré lors de la création d’un document article. L’horodatage de l’événement 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, reliée à la commande d’achat par la table des postes, MSEG. Collecte 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 configurée. Cet événement est déduit lorsque la stratégie de validation est déclenchée et que la commande passe au statut d’approbation en attente. | ||
| Pourquoi c’est important La distinction entre la création de la PO et le début du processus d’approbation permet de mesurer précisément l’indicateur de temps de cycle d’approbation. Elle met en évidence tout délai survenant avant le démarrage du flux de travail d’approbation. Où les obtenir Déduit des documents de modification, CDHDR/CDPOS, de la commande d’achat, objet EINKBELEG, qui indiquent la définition initiale d’un statut de validation, ou lorsque le statut global de validation, EKKO-FRGKE, prend pour la première fois une valeur indiquant qu’un processus d’approbation est actif. Collecte Identifiez 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 | Représente toute modification apportée à une commande d’achat après sa création initiale, par exemple une modification de la quantité, du prix ou des dates de livraison. Ces changements sont enregistrés explicitement dans le système de documents de modification de SAP. | ||
| Pourquoi c’est important Des modifications fréquentes, en particulier après l’approbation, indiquent des inefficacités dans le processus, une planification initiale insuffisante ou une dérive du périmètre. Cette activité est essentielle pour le Dashboard « Reprises et modifications des commandes d’achat » et les KPI associés. Où les obtenir Enregistré explicitement dans les tables d’en-tête et de postes des documents de modification, CDHDR et CDPOS, pour l’objet de commande d’achat, EINKBELEG. Chaque modification crée une nouvelle entrée avec un horodatage. Collecte 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 pendant le 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 libération de la PO, indiquant qu’un rejet a eu lieu. | ||
| Pourquoi c’est important Le suivi des rejets aide à identifier les problèmes de qualité des données de commande, les non-conformités aux politiques ou les dysfonctionnements de la matrice d’approbation. Il entraîne souvent des reprises et augmente la durée globale du cycle. Où les obtenir 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. Collecte Surveillez les journaux de modifications afin de détecter l’annulation d’un code de validation ou un changement de statut indiquant un rejet. Type d’événement inferred | |||
| Commande d’achat supprimée | Représente l’annulation ou la suppression logique d’un poste de commande d’achat, empêchant la poursuite du traitement, notamment les réceptions de marchandises ou la facturation. Il s’agit d’un événement déduit, enregistré lorsque l’indicateur de suppression est défini sur le poste de commande. | ||
| Pourquoi c’est important Il s’agit d’une activité terminale indiquant 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ù les obtenir 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. Collecte Identifiez l’horodatage des documents de modification au moment où l’indicateur EKPO-LOEKZ est activé. Type d’événement inferred | |||
| Confirmation de services saisie | Pour les commandes d’achat de services, cette activité représente la confirmation de la réalisation des services. 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 c’est important Il s’agit de l’équivalent d’une réception de marchandises pour les services et d’un élément essentiel pour suivre l’exécution des commandes de services. Elle déclenche le processus financier de paiement des services. Où les obtenir Capturé à partir de la date de création, ESSR-ERDAT, dans la table d’en-tête des feuilles de saisie des services, ESSR. Le lien vers la commande d’achat se trouve dans la table ESLL. Collecte Utilisez l’horodatage de création de la table ESSR pour les feuilles de saisie des services liées à la commande d’achat. Type d’événement explicit | |||
| Demande d’achat approuvée | Représente l’approbation officielle d’une demande d’achat, qui autorise sa conversion en commande d’achat. Cet événement est déduit des changements apportés aux champs de statut de libération des données de la demande d’achat, suivis par le flux de travail de stratégie de libération de SAP. | ||
| Pourquoi c’est important Le suivi des approbations est essentiel pour identifier les goulots d’étranglement lors de la phase précédant la commande et garantir le respect des politiques d’approbation. Les retards à ce stade ont une incidence directe sur le temps de cycle global des achats. Où les obtenir Déduit des journaux de modifications de la table des demandes d’achat, EBAN, en surveillant notamment les changements apportés aux champs de statut de validation, par exemple EBAN-FRGZU, ou en analysant les documents de modification dans CDHDR/CDPOS pour l’objet EBAN. Collecte Surveillez les documents de modification des champs de statut de validation d’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 qualité. Cette activité est généralement déduite lorsqu’un lot d’inspection, créé au moment de la réception des marchandises, fait l’objet d’une décision d’utilisation dans le module Quality Management. | ||
| Pourquoi c’est important Dans les secteurs où la qualité est essentielle, cette activité aide à analyser la durée et les résultats du processus d’inspection. Les retards à ce stade peuvent créer des goulots d’étranglement entre la réception des marchandises et leur mise à disposition. Où les obtenir Déduit du module Quality Management. Un lot d’inspection est créé dans la table QALS lors de la réception des marchandises, puis l’activité est marquée par la création d’une décision d’utilisation dans la table QAVE, qui contient un horodatage. Collecte Identifiez l’horodatage de la décision d’utilisation dans la table QAVE pour le lot d’inspection associé au document article. Type d’événement inferred | |||
| Marchandises retournées | Représente le 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é par la comptabilisation d’un document article avec un type de mouvement spécifique aux retours. | ||
| Pourquoi c’est 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 pour calculer le KPI de taux d’écart des réceptions de marchandises. Où les obtenir Enregistré dans les tables des documents articles, MKPF/MSEG, lorsqu’un type de mouvement de retour, par exemple « 122 » pour un retour au fournisseur, est utilisé. La date de comptabilisation, MKPF-BUDAT, sert d’horodatage. Collecte Identifiez les documents articles utilisant un type de mouvement de retour, par exemple 122, et faisant référence à la commande d’achat d’origine. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Créer le programme ABAP : ouvrez l’éditeur ABAP à l’aide du code de transaction SE38. Saisissez un nom pour votre nouveau programme, par exemple Z_PM_PO_EXTRACT, puis cliquez sur « Create ». Donnez-lui un titre tel que « Process Mining PO Data Extraction » et définissez le type « Executable Program ».
- Définir l’écran de sélection : dans le programme, définissez les paramètres de l’écran de sélection. Les utilisateurs pourront ainsi filtrer les données à extraire. Les principaux paramètres sont la plage de dates de création des bons de commande, le code société (BUKRS) et le type de document d’achat (BSART).
- Définir les structures de données : déclarez une structure de table interne correspondant au format final de l’Event Log. Elle doit inclure tous les attributs requis et recommandés : PurchaseOrder, Activity, EventTime, UserName, VendorNumber, OrderAmount, MaterialGroup, CompanyCode et DocumentType.
- Implémenter 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. Cette étape consiste à interroger plusieurs tables SAP, notamment EKKO, EKPO, EKBE, EBAN, CDHDR, CDPOS et NAST. Utilisez une sous-routine distincte (PERFORM) pour chaque activité afin de conserver un code organisé.
- Sélectionner les données des demandes d’achat : interrogez la table EBAN pour les événements « Purchase Requisition Created » et reliez-les aux bons de commande via la table EKPO. Utilisez les tables de journal des modifications (CDHDR, CDPOS) pour identifier les événements « Purchase Requisition Approved » en suivant les modifications des champs de statut de validation.
- Sélectionner les événements principaux des bons de commande : interrogez les tables EKKO et EKPO pour l’événement « Purchase Order Created ». Utilisez les tables de journal des modifications (CDHDR, CDPOS) sur l’objet EINKBELEG pour extraire les événements « Purchase Order Changed », « Purchase Order Approved », « Purchase Order Rejected », « Purchase Order Completed » et « Purchase Order Deleted », en fonction des modifications apportées à des champs précis tels que les indicateurs de validation et les indicateurs de suppression.
- Sélectionner les événements de communication des bons de commande : interrogez la table NAST pour trouver les enregistrements indiquant que le bon de commande a été transmis avec succès et enregistrer l’activité « Purchase Order Sent to Vendor ».
- Sélectionner les événements liés aux marchandises et aux services : interrogez la table EKBE pour identifier les comptabilisations de documents matières et les activités « Goods Receipt Posted » et « Goods Returned » en fonction de la catégorie de type de mouvement. Interrogez ESSR et ESLL pour les feuilles de saisie des services afin d’enregistrer « 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 identifier la décision d’utilisation prise pour un lot de contrôle associé à un bon de commande, ce qui correspond à l’activité « Quality Inspection Performed ».
- Combiner et formater les données : regroupez les données issues de toutes les sélections dans une table interne finale unique. Veillez à ce que le champ EventTime soit formaté de manière cohérente, par exemple YYYY-MM-DDTHH:MI:SS.
- Implémenter le téléchargement du fichier : ajoutez une fonctionnalité permettant de télécharger la table interne finale sous forme de fichier. Le format recommandé est un fichier séparé par des tabulations ou un fichier CSV, qui peut être généré à l’aide du module 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 exécutez le rapport. Lorsque le système vous le demande, enregistrez le fichier de sortie sur votre ordinateur local avec l’extension .csv, afin de pouvoir le charger.
Configuration
- Plage de dates : il est essentiel de définir une plage de dates précise pour l’extraction, généralement fondée sur la date de création du bon de commande (EKKO-AEDAT). Une période de 3 à 6 mois constitue souvent un bon point de départ pour trouver un équilibre entre le volume de données et la visibilité sur le processus.
- Code société (BUKRS) : filtrez sur un ou plusieurs codes société afin de limiter l’extraction aux entités juridiques concernées. Il s’agit d’un paramètre important pour les performances et la pertinence de l’analyse.
- Type de document d’achat (BSART) : filtrez sur des types de document précis, par exemple « NB » pour un bon de commande standard, afin de vous concentrer sur les processus courants et d’exclure si nécessaire les types d’achat particuliers.
- Granularité des données : l’extraction est conçue au niveau du poste de bon de commande. Le Case ID correspond au numéro du bon de commande (EBELN). Tous les événements, y compris ceux qui concernent les postes, comme les réceptions de marchandises, sont rattachés à cet identifiant de cas principal.
- Considérations relatives aux performances : pour les volumes importants, planifiez l’exécution du programme comme tâche d’arrière-plan (SM36) afin d’éviter les erreurs d’expiration. Vérifiez que des index de base de données existent sur les champs clés utilisés dans les clauses WHERE, en particulier pour 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 disposer des droits nécessaires pour développer 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.
a 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 et les informations de connexion, à savoir le nom d’hôte, le port et le nom de la base de données SAP ECC sous-jacente. Vérifiez que les outils clients nécessaires, tels que DBeaver, SQL Developer ou SSMS, sont installés.
- Identifier le schéma SAP : connectez-vous à la base de données et identifiez le schéma SAP principal dans lequel se trouvent 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 utilisé par défaut pour votre utilisateur, vous devrez préfixer tous les noms de tables de la requête avec son nom.
- Examiner la requête SQL : ouvrez le script SQL fourni dans votre outil client. Cette requête complète est conçue pour extraire 14 activités distinctes du processus Purchase to Pay en reliant plusieurs tables SAP.
- Personnaliser les paramètres de la requête : repérez la Common Table Expression (CTE) PO_BASE au début du script. Modifiez 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é d’appliquer le filtre au champ AEDAT (modifié le).
- [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 bon de commande à inclure.
- [Your SAP Schema] : remplacez cet espace réservé par le nom réel de votre schéma SAP dans l’ensemble du script.
- Exécuter la requête : exécutez 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.
- Contrôler les résultats : une fois la requête terminée, effectuez une vérification rapide de la sortie. Contrôlez que le nombre de lignes est cohérent et que les colonnes clés, telles que 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 vers un fichier CSV. Utilisez l’encodage UTF-8 pour éviter les problèmes de caractères.
- Préparer le chargement : vérifiez que les en-têtes de colonnes de votre fichier CSV correspondent exactement aux noms d’attributs requis : PurchaseOrder, Activity, EventTime, UserName, VendorNumber, OrderAmount, MaterialGroup, CompanyCode et DocumentType.
- Charger les données dans l’outil de Process Mining : chargez le fichier CSV final dans votre application de Process Mining pour l’analyse et la visualisation.
Configuration
- Prérequis : un accès direct en lecture seule à la base de données SAP ECC sous-jacente est requis. 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 : il est essentiel d’appliquer un filtre de plage de dates afin de limiter le volume de données. Filtrer sur EKKO.AEDAT (date de modification du bon de commande) pour une période de 3 à 6 mois constitue un point de départ courant. Des plages plus longues peuvent entraîner des durées d’exécution extrêmement importantes.
- Filtres de données clés : pour garantir une analyse ciblée, filtrez toujours sur EKKO.BUKRS (code société) et EKKO.BSART (type de document). Vous limitez ainsi le périmètre aux entités juridiques et aux processus concernés.
- Considérations relatives aux performances : la requête relie plusieurs tables volumineuses, notamment les tables d’historique des modifications (CDHDR, CDPOS). Cette opération peut mobiliser beaucoup de ressources. Il est vivement recommandé d’exécuter l’extraction en dehors des heures de pointe ou sur une base répliquée hors production afin de ne pas affecter les performances du système.
- Journalisation des documents de modification : 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.
a 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 tiers dispose du connecteur certifié SAP, installé et sous licence. Dans la console d’administration de votre outil ETL, configurez une nouvelle connexion à votre système SAP ECC. Vous aurez besoin de l’hôte du serveur d’application, du numéro du système, de l’identifiant client et d’un utilisateur SAP dédié disposant des autorisations RFC et des droits de lecture des tables appropriés.
- Identifier 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 du bon de commande), EKPO (poste du bon de commande), EBAN (demande d’achat), CDHDR (en-tête du document de modification), CDPOS (poste du document de modification), MSEG (segment du document : matière), MKPF (en-tête du document matière), 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 selon le périmètre organisationnel, par exemple BUKRS pour le code société et BSART pour le type de document. Mappez EKKO.EBELN vers PurchaseOrder, « Purchase Order Created » vers Activity, puis combinez AEDAT et ERZET pour EventTime. Mappez les autres attributs requis.
- Extraire « Goods Receipt Posted » : créez un flux de données distinct à partir de MSEG et reliez-le à MKPF via MBLNR et MJAHR. Filtrez les types de mouvement concernés, tels que « 101 ». Mappez MSEG.EBELN vers PurchaseOrder, « Goods Receipt Posted » vers Activity et utilisez MKPF.CPUDT et MKPF.CPUTM pour EventTime.
- Extraire les événements fondés sur les modifications, approbations, changements et suppressions : créez un flux de données à partir de CDHDR et CDPOS, reliées via CHANGENR. Cette source unique peut servir à 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 autres modifications de champs pertinentes, en excluant les champs de statut spécifiques utilisés pour les autres activités.
- Pour tous ces événements, utilisez CDHDR.UDATE et CDHDR.UTIME pour EventTime.
- Extraire les événements des demandes d’achat : créez un flux de données à partir d’EBAN pour « Purchase Requisition Created ». Pour relier cet événement à un cas PurchaseOrder, reliez EBAN à EKPO à l’aide du numéro de demande (BANFN) et du poste (BNFPO). Pour « Purchase Requisition Approved », utilisez CDHDR/CDPOS avec OBJECTCLAS = « BANF ». Un mappage précis est nécessaire pour associer l’événement au bon de commande finalement créé.
- Extraire « PO Sent to Vendor » : créez un flux de données à partir de la table NAST. Filtrez OBJECTKEY, qui contient le numéro du bon de commande, le type de sortie concerné (KSCHL) et le statut de traitement réussi (VSTAT = « 1 »). Utilisez ERDAT et UHR pour EventTime.
- Combiner les flux d’activités : utilisez une transformation « Union » ou « Merge » dans votre outil ETL pour regrouper les sorties de tous les flux de données créés aux étapes précédentes. Vérifiez que les noms et les types de données des colonnes sont cohérents dans tous les flux, notamment PurchaseOrder, Activity et EventTime.
- Convertir les types et les formats de données : vérifiez que la colonne EventTime est convertie dans un format d’horodatage cohérent, par exemple YYYY-MM-DD HH:MM:SS. Convertissez OrderAmount dans un format décimal standard.
- Définir la destination cible : configurez une cible ou un « sink » pour votre flux de données combiné. Il s’agit généralement d’un fichier plat, tel qu’un fichier CSV ou Parquet. Configurez le séparateur, les qualificateurs de texte et les options d’en-tête.
- Exécuter et valider : exécutez la tâche ETL complète. Effectuez des contrôles de validation sur le fichier de sortie afin de vérifier que les 14 activités sont présentes, que le nombre de lignes est cohérent et que les attributs clés sont correctement renseignés.
- Planifier et exporter : une fois la validation terminée, planifiez l’exécution périodique de la tâche ETL, par exemple chaque nuit, afin de maintenir les données à jour. Le fichier généré peut alors être chargé dans votre outil de Process Mining.
Configuration
- Prérequis : Un outil ETL commercial, par exemple Informatica PowerCenter, Talend ou SAP Data Services, avec le SAP Certified Connector correspondant pour ECC. Un utilisateur de dialogue ou utilisateur système SAP 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 afin de 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. Ce filtre doit être appliqué à la source pour éviter d'extraire un volume excessif de données depuis SAP.
- Filtres de périmètre organisationnel : Filtrez toujours selon EKKO.BUKRS (code société) et envisagez un filtrage selon EKPO.WERKS (division) ou EKKO.EKORG (organisation d'achats) afin de limiter l'analyse à une unité opérationnelle donnée.
- 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 depuis les tables de documents de modification (CDHDR, CDPOS) peut être lente. Vérifiez que des filtres sont appliqués à OBJECTCLAS, OBJECTID et UDATE. Ajustez le paramètre « Packet Size » dans le connecteur SAP afin d'optimiser les débits de transfert. Pour les systèmes très volumineux, envisagez un premier chargement historique, suivi de chargements delta planifiés.
a 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 le plan nécessaire pour optimiser votre processus Purchase to Pay, commandes d’achat, dans SAP ECC. Commencez dès aujourd’hui à utiliser vos données pour révéler les possibilités d’amélioration et accroître l’efficacité.
Optimisez vos bons de commande P2P : démarrez l’essai gratuit dès aujourd’hui
Éliminer les goulots d’étranglement et réduire le temps de cycle de 30 % ou plus.
Aucune carte bancaire requise, commencez en quelques minutes