> Amélioration continue des processus > Purchase to Pay Requisition > SAP ECC > Modèle de données

Votre modèle de données Purchase to Pay, demandes d’achat

SAP ECC

Purchase to Pay - Requisition : attributs (19) Purchase to Pay - Requisition : activités (13) Guides d'extraction (2)

Votre modèle de données Purchase to Pay, demandes d’achat

Ce modèle fournit un guide complet pour recueillir les données essentielles à l’analyse de votre processus Purchase to Pay, demandes d’achat. Il précise les champs de données à collecter, les activités importantes à suivre et les recommandations pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour préparer vos données en vue d’un Process Mining efficace.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour SAP ECC

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Purchase to Pay - Requisition : attributs

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus Purchase to Pay Requisition.

5 Obligatoire 5 Recommandé 9 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage indiquant le moment où l’activité a eu lieu.
Description L’heure de l’événement enregistre la date et l’heure précises auxquelles une activité donnée s’est produite. Cet horodatage est fondamental pour toutes les analyses temporelles du Process Mining, notamment le calcul des temps de cycle, l’identification des goulots d’étranglement et l’évaluation de la performance du processus. Dans le contexte des demandes d’achat, cet attribut permet de calculer des KPI essentiels tels que le délai moyen d’approbation d’une demande d’achat et le délai de création d’une commande d’achat. Il alimente les Dashboards qui visualisent les durées, comme l’analyse du temps de cycle d’approbation des demandes d’achat, en fournissant les données nécessaires pour mesurer le délai entre deux étapes quelconques du processus. Pourquoi c’est important Cet horodatage est essentiel pour calculer toutes les durées, analyser la performance du processus et détecter les goulots d’étranglement liés au temps. Où les obtenir Présent dans la table d’en-tête des documents de modification CDHDR, champs UDATE et UTIME. Exemples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Identifiant de la demande d’achat PurchaseRequisitionId	Identifiant unique d’un document de demande d’achat.
Description L’identifiant de la demande d’achat est la clé primaire qui identifie de manière unique chaque demande de biens ou de services dans SAP ECC. Il sert d’identifiant central du cas et relie toutes les activités et modifications associées à une demande donnée, de sa création à sa résolution finale, par exemple sa conversion en commande d’achat ou sa clôture. Dans le Process Mining, cet identifiant est essentiel pour reconstituer le cycle de vie complet de chaque demande. En le suivant, les analystes peuvent visualiser l’ensemble du flux du processus, mesurer les durées entre les étapes clés et analyser les différences de traitement entre les demandes. Il offre une vue cohérente de l’ensemble du parcours de la demande d’achat. Pourquoi c’est important Il s’agit de l’identifiant central qui relie tous les événements associés à un même cas et rend possible l’analyse de bout en bout du processus. Où les obtenir Présent dans la table EBAN, champ BANFN. Exemples 100234567810023456791002345680
	Nom de l’activité ActivityName	Nom de l’activité métier survenue à un moment précis.
Description Cet attribut décrit une étape ou un événement précis du cycle de vie d’une demande d’achat, par exemple « Demande d’achat créée », « Approbation soumise » ou « Commande d’achat créée ». Ces activités sont généralement déduites des changements de statut, des journaux de flux de travail ou des documents de modification dans SAP. L’analyse de la séquence et de la fréquence des activités constitue le fondement du Process Mining. Elle permet de découvrir les flux réels du processus, notamment les parcours fréquents, les écarts et les goulots d’étranglement. Elle est essentielle pour créer des Dashboards tels que la carte de processus de demande d’achat de bout en bout et calculer les KPI liés aux reprises et à la conformité. Pourquoi c’est important Il définit les étapes du processus, ce qui permet de visualiser les cartes de processus et d’analyser les variations du flux. Où les obtenir Dérivé des tables de documents de modification CDHDR et CDPOS, des journaux de flux de travail ou de champs de statut tels que EBAN-STATU. Exemples Demande crééeÉtape d’approbation approuvéeDemande rejetéeCommande d’achat créée
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’actualisation ou de l’extraction la plus récente des données depuis le système source.
Description Cet attribut indique la date de la dernière mise à jour du jeu de données. Il s’agit d’un horodatage statique appliqué à l’ensemble du jeu de données lors de chaque chargement et servant de référence pour évaluer l’actualité de l’analyse. Pour tout Dashboard ou toute analyse de Process Mining, connaître la récence des données est essentiel pour prendre des décisions éclairées. Cet attribut permet à toutes les parties prenantes de connaître la période couverte par les données consultées et d’éviter de tirer des conclusions à partir d’informations obsolètes. Pourquoi c’est important Informe les utilisateurs sur l’actualité des données, un élément essentiel pour la pertinence et la précision de l’analyse des processus. Où les obtenir Il s’agit d’une valeur statique représentant l’horodatage de l’extraction des données, ajoutée lors du processus ETL. Exemples 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Système source SourceSystem	Identifie le système source depuis lequel les données ont été extraites.
Description Cet attribut précise l’origine des données du processus, par exemple « SAP ECC Production » ou « S4HANA QA ». Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données afin de fournir un contexte, notamment dans les environnements comportant plusieurs systèmes sources. Dans l’analyse des processus, il permet de distinguer les données provenant de différentes sources et d’éviter que les analyses ne soient faussées par le mélange de données issues des environnements de production, de test ou de développement. Il constitue un élément essentiel des métadonnées pour la gouvernance et la traçabilité des données. Pourquoi c’est important Fournit le contexte nécessaire sur l’origine des données, garantit leur traçabilité et permet l’analyse de plusieurs systèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) des données. Exemples SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Nom d’utilisateur User	Identifiant de l’utilisateur qui a effectué l’activité.
Description Cet attribut identifie l’utilisateur responsable d’un événement, par exemple la création d’une demande d’achat, l’approbation d’une étape ou la modification d’un document. Dans SAP, il est souvent enregistré sous la forme d’un identifiant utilisateur. L’analyse par utilisateur permet d’identifier les besoins de formation, la performance individuelle et les sources potentielles d’erreurs de saisie. Elle est essentielle pour les Dashboards tels que le volume de création des demandes d’achat par demandeur et pour comprendre la répartition de la charge de travail ainsi que le respect des règles de séparation des tâches. Pourquoi c’est important Attribue les activités à des personnes précises et permet ainsi d’analyser la performance, la charge de travail, la conformité et les besoins de formation des utilisateurs. Où les obtenir Présent dans la table d’en-tête des documents de modification CDHDR, champ USERNAME, pour les modifications, et dans EBAN, champ ERNAM, pour le créateur. Exemples SMITHJR.DOEUSER123
	Service Department	Service du demandeur ou centre de coûts associé à la demande d’achat.
Description Cet attribut représente l’unité opérationnelle ou le service à l’origine de la demande d’achat. Il est souvent dérivé du profil utilisateur du demandeur ou du centre de coûts affecté au poste de la demande. L’analyse du processus par service est essentielle pour comprendre les écarts de performance au sein de l’organisation. Il s’agit de la dimension principale du Dashboard sur le temps de cycle d’approbation des demandes d’achat et du KPI sur les écarts de délai d’approbation entre services. Elle aide à déterminer quels services disposent de processus efficaces et lesquels nécessitent des améliorations ou des ressources supplémentaires. Pourquoi c’est important Permet de comparer la performance des unités opérationnelles et de mettre en évidence les goulots d’étranglement ainsi que les incohérences entre services. Où les obtenir Souvent dérivé de la mise en relation du demandeur (EBAN-AFNAM) avec les données de référence des utilisateurs (SU01), ou de l’utilisation du centre de coûts (EBKN-KOSTL) associé à l’imputation de la demande d’achat. Exemples FinanceOpérations informatiquesMarketingProduction
	Statut de la demande d’achat RequisitionStatus	Statut actuel du traitement de la demande d’achat.
Description Cet attribut indique le statut global de la demande d’achat à un moment donné, par exemple « En cours de validation », « Approuvée », « Rejetée » ou « Clôturée ». Il est souvent représenté par un code de statut dans SAP. Le suivi du statut est essentiel pour comprendre l’issue des demandes d’achat. Il alimente directement le Dashboard sur les résultats et les taux de rejet des demandes d’achat, ainsi que des KPI tels que le taux de rejet et le taux de retrait des demandes d’achat. L’analyse des transitions entre les statuts permet d’identifier les inefficacités et les points d’échec du processus. Pourquoi c’est important Il définit l’issue d’une demande d’achat, ce qui est essentiel pour analyser les taux de réussite, les motifs de rejet et les points de fin du processus. Où les obtenir Le statut de traitement se trouve dans la table EBAN, champ STATU. Le statut de validation se trouve dans EBAN-FRGZU. Exemples N (Non modifiée)B (Bon de commande créé)A (Demande de devis créée)K (Clôturée)
	Type de document RequisitionDocumentType	Classification qui détermine le type et les caractéristiques de la demande d’achat.
Description Dans SAP, le type de document contrôle différents aspects d’une demande d’achat, notamment la plage de numérotation, la sélection des champs et le processus d’approvisionnement global suivi. Les exemples incluent « Demande d’achat standard », « Transfert de stock » ou « Demande d’achat de services ». Cet attribut constitue une dimension d’analyse importante, car les différents types de documents suivent souvent des flux et des exigences d’approbation distincts. Il permet aux analystes de segmenter les données afin de comparer la performance des différents processus de demande d’achat, ce qui est essentiel pour évaluer la conformité et repérer les possibilités de standardisation ou de spécialisation des processus. Pourquoi c’est important Permet de segmenter les demandes d’achat en différentes catégories de processus et d’obtenir ainsi des analyses plus précises et pertinentes. Où les obtenir Présent dans la table EBAN, champ BSART. Exemples NBUBRV
	Valeur totale de la demande d’achat TotalRequisitionValue	Valeur monétaire totale de tous les postes de la demande d’achat.
Description Cet attribut représente le montant financier total de la demande d’achat. Cette valeur joue souvent un rôle déterminant dans le choix du flux de travail d’approbation requis : les demandes d’un montant élevé font généralement l’objet d’un examen plus approfondi et de davantage d’étapes d’approbation. L’analyse par montant est essentielle pour comprendre l’incidence financière sur le fonctionnement du processus. Elle peut révéler si les demandes importantes prennent plus de temps à approuver, sont plus souvent rejetées ou suivent des parcours différents. Il s’agit également d’une métrique fondamentale pour évaluer le volume financier traité par le processus d’achat. Pourquoi c’est important Aide à mettre en relation le comportement du processus et son impact financier, ce qui est essentiel pour l’analyse des risques et la compréhension de la complexité des approbations. Où les obtenir Somme des valeurs de tous les postes. La valeur du poste se trouve dans la table EBAN, champ GSWER. La devise se trouve dans EBAN-WAERS. Exemples 1500.00250.50125000.00
	Groupe d’acheteurs PurchasingGroup	Groupe d’acheteurs responsable de l’acquisition des articles demandés.
Description Le groupe d’acheteurs est une unité organisationnelle responsable d’activités d’approvisionnement précises. Il représente l’équipe qui prendra en charge la demande d’achat après son approbation. Cet attribut permet d’analyser la charge de travail et la performance des différentes équipes d’achat. Il peut aider à déterminer si certains groupes d’acheteurs constituent un goulot d’étranglement lors de la conversion des demandes en commandes d’achat, ou s’ils traitent certains types de demandes plus efficacement que d’autres. Il constitue une dimension importante pour la gestion des ressources et de la performance de la fonction achats. Pourquoi c’est important Attribue la responsabilité de l’approvisionnement, permet d’analyser la charge de travail et de comparer la performance des différentes équipes d’achat. Où les obtenir Présent dans la table EBAN, champ EKGRP. Exemples 001002P01
	Groupe de marchandises MaterialGroup	Groupe ou catégorie auquel appartiennent le matériel ou le service demandé.
Description Le groupe de marchandises est une classification qui permet de regrouper les matériels ou services présentant des caractéristiques similaires. Il permet d’analyser les activités d’approvisionnement par catégorie. L’analyse par groupe de marchandises contribue à la stratégie d’achat et à l’analyse des dépenses. Dans le Process Mining, elle peut révéler si les demandes concernant certaines catégories, comme le matériel informatique ou les services professionnels, suivent des parcours différents ou connaissent des délais d’approbation plus longs. Cette analyse est utile pour le rapport sur la qualité des données des demandes d’achat et pour comprendre les variations du processus selon les biens ou services achetés. Pourquoi c’est important Permet d’analyser les dépenses et les processus par catégorie d’approvisionnement, de soutenir la stratégie d’achat et d’identifier les goulots d’étranglement propres à certaines catégories. Où les obtenir Présent dans la table EBAN, champ MATKL. Exemples 00101L001IT-SFTWR
	Identifiant de la commande d’achat PurchaseOrderId	Identifiant de la commande d’achat créée à partir de la demande.
Description Cet attribut relie une demande d’achat à la commande d’achat créée ensuite pour y répondre. Une même demande peut parfois donner lieu à plusieurs commandes d’achat. Ce lien est essentiel pour analyser le transfert entre les processus de demande d’achat et d’achat. Il est nécessaire au calcul du KPI sur le délai entre la demande d’achat et la création de la commande, ainsi qu’à l’alimentation du Dashboard sur le délai entre l’approbation de la demande et la création de la commande d’achat. Comprendre cette relation est essentiel pour mesurer l’efficacité de l’ensemble du cycle procure-to-pay. Pourquoi c’est important Relie le processus de demande d’achat au processus d’achat en aval et permet d’analyser les délais de transfert. Où les obtenir Le numéro de la commande d’achat est enregistré dans la table EBAN, champ EBELN, après sa création. Exemples 450001712345000171244500017125
	Identifiant du fournisseur VendorId	Identifiant unique du fournisseur suggéré ou imposé.
Description Cet attribut contient l’identifiant d’un fournisseur privilégié ou imposé par contrat pour l’article demandé. Il peut être prérempli ou suggéré par le demandeur. L’analyse des demandes par fournisseur peut aider à évaluer l’incidence de la présélection des fournisseurs sur le processus d’approvisionnement. Elle peut notamment montrer si les demandes associées à un fournisseur précis sont approuvées plus rapidement ou si certains fournisseurs sont liés à des taux de rejet plus élevés. Elle offre une visibilité sur l’implication des fournisseurs dès les premières étapes du processus. Pourquoi c’est important Fournit des analyses sur les relations avec les fournisseurs privilégiés et leur influence sur la rapidité et les résultats du traitement des demandes d’achat. Où les obtenir Présent dans la table EBAN, champ LIFNR (fournisseur imposé). Exemples 100030025V9876
	Indicateur de reprise IsRework	Indicateur booléen précisant si la demande d’achat a suivi une boucle de reprise, par exemple après une modification consécutive à sa soumission.
Description Il s’agit d’un attribut dérivé qui signale les activités ou les cas comportant une reprise. Par exemple, toute activité « Demande d’achat modifiée » survenant après « Approbation soumise » est considérée comme une reprise. L’indicateur peut également être déclenché par des événements de rejet qui renvoient le processus à une étape antérieure. Cet indicateur est essentiel pour le Dashboard d’analyse des modifications et des reprises des demandes d’achat. Il permet de filtrer et de quantifier facilement les reprises, de mesurer leur incidence sur les temps de cycle globaux et d’identifier les causes profondes des inefficacités du processus. Des taux élevés de reprise signalent souvent des problèmes de qualité des données ou des exigences mal définies. Pourquoi c’est important Aide à quantifier la fréquence et l’incidence des reprises et facilite l’identification ainsi que l’analyse des inefficacités et des boucles du processus. Où les obtenir Dérivé du journal d’événements en identifiant des séquences précises d’activités, par exemple lorsqu’une activité « Demande d’achat modifiée » survient après une activité d’approbation. Exemples truefalse
	Motif du rejet RejectionReason	Motif fourni lorsqu’une demande d’achat ou une étape d’approbation est rejetée.
Description Cet attribut enregistre la justification du rejet d’une demande d’achat. Ces informations sont généralement saisies en texte libre ou sélectionnées dans une liste prédéfinie de codes par l’approbateur lors de l’activité de rejet. L’analyse des motifs de rejet est essentielle à l’amélioration des processus. Elle fournit des indications concrètes sur les raisons des échecs des demandes, qui peuvent être liées au non-respect des politiques, à des données incorrectes ou à un budget insuffisant. Ces données sont essentielles pour le Dashboard sur les résultats et les taux de rejet des demandes d’achat et aident à identifier les causes profondes des inefficacités du processus. Pourquoi c’est important Fournit des informations précises sur les raisons du rejet des demandes d’achat et permet de cibler les améliorations du processus ainsi que la formation des utilisateurs. Où les obtenir Ces données sont généralement stockées dans les journaux de flux de travail ou dans le texte long associé à l’événement de rejet. Aucun champ standard n’existe dans EBAN. Exemples Centre de coûts incorrectBudget dépasséDemande en doubleNon conforme à la politique
	Nom du demandeur RequesterName	Nom de la personne qui a demandé les biens ou les services.
Description Cet attribut identifie la personne à l’origine de la demande d’achat. Il s’agit de la personne qui exprime le besoin métier concernant les articles demandés. Le suivi du demandeur permet d’analyser les habitudes de demande par personne ou par groupe. Le Dashboard sur le volume de création des demandes d’achat par demandeur s’appuie sur cet attribut pour identifier les utilisateurs intensifs, les utilisateurs ayant besoin d’une formation complémentaire ou les services ayant une activité d’approvisionnement élevée. Il offre une vision centrée sur les personnes à l’origine du processus. Pourquoi c’est important Identifie le responsable du processus, permet d’analyser les habitudes de création des demandes d’achat et aide à cibler la formation des utilisateurs. Où les obtenir Présent dans la table EBAN, champ AFNAM. Exemples Alice WilliamsBob JohnsonCharlie Brown
	Priorité Priority	Niveau d’urgence attribué à la demande d’achat.
Description Cet attribut indique la priorité de la demande d’achat, souvent classée comme « Urgente », « Élevée » ou « Normale ». Cet indicateur signale aux approbateurs et aux acheteurs qu’une demande doit être traitée en priorité. Cet attribut est essentiel pour le Dashboard sur la performance du traitement des demandes d’achat urgentes et pour le KPI sur l’efficacité de l’indicateur d’urgence. L’analyse vise à déterminer si les demandes marquées comme urgentes sont effectivement traitées plus rapidement que les demandes standard. Elle permet ainsi d’évaluer l’efficacité du système de priorisation et de garantir que les besoins essentiels de l’entreprise sont satisfaits rapidement. Pourquoi c’est important Permet de déterminer si les demandes urgentes sont traitées plus rapidement et d’évaluer ainsi l’efficacité des mécanismes de priorisation. Où les obtenir Il ne s’agit pas d’un champ standard de la table EBAN. Il est souvent implémenté sous la forme d’un champ personnalisé ou déduit du numéro de suivi de la demande (EBAN-BEDNR) ou d’un type de document précis. Exemples 123
	Site Plant	Site ou établissement de l’entreprise pour lequel les biens ou services sont demandés.
Description Le site est une unité organisationnelle de l’entreprise qui représente un emplacement physique, comme une usine, un entrepôt ou un bureau. La demande d’achat précise le site où les articles demandés sont nécessaires. L’analyse par site permet d’obtenir une vision géographique ou locale du processus de demande d’achat. Elle peut mettre en évidence des écarts de performance entre les sites, dus par exemple à des procédures locales, à des niveaux d’effectifs ou à des besoins métier différents. Il s’agit d’une dimension courante des Dashboards de performance régionale. Pourquoi c’est important Fournit un contexte géographique ou local pour l’analyse et aide à identifier les variations du processus et les écarts de performance entre les régions. Où les obtenir Présent dans la table EBAN, champ WERKS. Exemples 10002100DE01

Obligatoire Recommandé Facultatif

Purchase to Pay - Requisition : activités

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir et analyser précisément votre flux de travail de demandes d’achat.

6 Recommandé 7 Facultatif

	Activité	Description
	Approbation soumise	Cette activité indique que la demande d’achat est entrée dans le flux de travail d’approbation officiel. Elle est généralement déduite lorsque le statut de la demande change pour exiger une première action de validation ou d’approbation, conformément à la stratégie de validation configurée.
Pourquoi c’est important Cette étape marque le début du cycle d’approbation, un KPI essentiel pour mesurer l’efficacité du processus. La compréhension de ce point permet d’isoler les retards entre la création de la demande et le début des approbations formelles. Où les obtenir Déduite du premier changement de statut lié à la stratégie de validation dans la table EBAN, par exemple lorsque le champ FRGZU passe de son état initial à un état en attente, ou de la première entrée dans les journaux de flux de travail associés à la demande d’achat. Collecte Déduit de la première entrée du journal des modifications indiquant l’activation d’une stratégie de validation. Type d’événement inferred
	Commande d’achat créée	Cette activité marque la conversion réussie d’une demande d’achat approuvée en document de commande d’achat. L’événement est déduit pour la demande en recherchant un poste de commande d’achat correspondant qui la référence.
Pourquoi c’est important En tant que principal résultat positif, cette activité clôt le processus de demande d’achat et marque le début de la phase d’approvisionnement. Le délai entre « Demande d’achat approuvée » et cet événement constitue un KPI important pour mesurer l’efficacité du transfert. Où les obtenir Déduit de la présence d’un enregistrement dans la table EKPO (poste de commande d’achat), dont les champs BANFN et BNFPO correspondent au numéro et au poste de la demande d’achat dans la table EBAN. La date de création de la commande d’achat (EKKO.AEDAT) fournit l’horodatage. Collecte Déduit de la mise en relation des tables EBAN et EKPO et de l’utilisation de la date de création de la commande d’achat dans EKKO. Type d’événement inferred
	Demande approuvée	Cette activité jalon indique que la demande d’achat a franchi avec succès toutes les étapes d’approbation requises. Elle est déduite lorsque le dernier code de validation est appliqué et que l’indicateur global de validation (FRGZU) de la table EBAN passe à un état approuvé.
Pourquoi c’est important Il s’agit d’un jalon essentiel, qui marque la fin du cycle d’approbation et le début de la phase d’achat. Il est indispensable pour calculer le KPI du délai total d’approbation et mesurer les retards lors du transfert vers la création de la commande d’achat. Où les obtenir Déduit de l’horodatage de l’entrée du journal des modifications dans CDPOS pour la table EBAN et le champ FRGZU, lorsque celui-ci prend la valeur correspondant à l’approbation finale. Collecte Déduit du champ d’indicateur de validation final de la table EBAN lorsqu’il atteint le statut terminal « approved ». Type d’événement inferred
	Demande créée	Cette activité marque la création initiale et l’enregistrement d’une demande d’achat par un utilisateur. L’événement est enregistré explicitement lorsqu’un nouvel enregistrement est créé dans la table EBAN, avec la date et l’heure de création.
Pourquoi c’est important En tant que point de départ du processus, cette activité est essentielle pour calculer la durée totale du cycle de vie d’une demande et analyser le volume de créations. Elle permet d’identifier qui crée les demandes et à quel moment. Où les obtenir Cet événement est extrait de la table EBAN à partir des champs de date de création (ERDAT) et d’heure de création (UZEIT) associés à un identifiant de demande d’achat (BANFN). Collecte Horodatage issu des champs ERDAT et UZEIT de la table EBAN lors de l’enregistrement initial. Type d’événement explicit
	Demande d’achat retirée	Il s’agit d’une activité terminale au cours de laquelle le créateur ou un utilisateur autorisé annule le poste de la demande d’achat en définissant un indicateur de suppression. Cette action est explicitement enregistrée et indique que le besoin métier n’est plus valable ou que la demande a été créée par erreur.
Pourquoi c’est important Il s’agit d’un point d’échec important du processus, essentiel au calcul du taux de retrait. Des taux élevés peuvent indiquer des délais d’approbation trop longs, qui poussent les utilisateurs à abandonner leurs demandes, ou des problèmes systémiques liés à la planification de la demande. Où les obtenir Cette action explicite est capturée lorsque le champ « Deletion Indicator » (LOEKZ) de la table EBAN est renseigné pour le poste de la demande d’achat. La modification est enregistrée dans CDHDR et CDPOS. Collecte Entrée du journal des modifications lorsque l’indicateur de suppression (EBAN-LOEKZ) prend la valeur « L ». Type d’événement explicit
	Demande rejetée	Il s’agit d’une activité terminale au cours de laquelle la demande d’achat est définitivement rejetée et ne peut plus poursuivre son parcours. Elle est déduite lorsque l’indicateur de validation de la table EBAN passe à un état final de rejet par l’action d’un approbateur.
Pourquoi c’est important Cette activité constitue un point final essentiel du processus et est nécessaire au calcul du KPI du taux de rejet des demandes d’achat. L’analyse de ces cas aide à comprendre les raisons des échecs d’achat et du gaspillage associé. Où les obtenir Déduit de l’horodatage de l’entrée du journal des modifications dans CDPOS pour la table EBAN et le champ FRGZU, lorsque celui-ci prend la valeur correspondant au rejet final. Collecte Déduit du champ d’indicateur de validation final de la table EBAN lorsqu’il atteint le statut terminal « rejected ». Type d’événement inferred
	Approbation réinitialisée	Indique que l’ensemble du flux de travail d’approbation de la demande d’achat a été réinitialisé, souvent à la suite d’une modification importante. Cette situation est déduite lorsque le statut de validation est effacé après avoir été actif, ce qui oblige le processus d’approbation à reprendre depuis le début.
Pourquoi c’est important Les réinitialisations d’approbation sont des événements de reprise importants qui ont une forte incidence sur le temps de cycle. Leur identification met en évidence les inefficacités du processus et les effets en aval des modifications de demandes d’achat sur le flux de travail. Où les obtenir Déduit des journaux de modifications (CDHDR/CDPOS) de la table EBAN lorsque les champs de statut de validation, tels que FRGZU, passent d’un état en attente ou approuvé à un état initial ou vide. Collecte Déduit des journaux de modifications montrant que les champs de la stratégie de validation ont été effacés. Type d’événement inferred
	Demande bloquée	Représente l’action explicite consistant à bloquer un poste de demande d’achat afin d’empêcher sa conversion en commande d’achat. Le blocage est défini au moyen d’un indicateur spécifique du poste de la demande.
Pourquoi c’est important Le blocage indique un problème potentiel ou une suspension temporaire du processus d’approvisionnement. Le suivi de ces événements permet d’identifier les goulots d’étranglement lorsque les demandes d’achat sont approuvées, mais ne sont pas traitées immédiatement. Où les obtenir Capturé à partir d’une modification du champ « Blocking Indicator » (EBAKZ) dans la table EBAN. La modification est enregistrée dans CDHDR et CDPOS. Collecte Événement enregistré dans les tables de modifications lorsque le champ EBAN-EBAKZ est renseigné. Type d’événement explicit
	Demande d’achat clôturée	Représente la clôture définitive d’un poste de demande d’achat, indiquant qu’aucun traitement supplémentaire n’est prévu. Ce statut est déduit lorsque le poste a été entièrement converti en commande d’achat et exécuté, ou lorsqu’il a été manuellement marqué comme clôturé.
Pourquoi c’est important Ce statut fournit un point de fin définitif pour les demandes d’achat terminées, mais pas nécessairement supprimées. Il garantit un calcul précis de la durée du cycle de vie des demandes exécutées avec succès. Où les obtenir Déduit de l’indicateur « Closed » (EBAKZ avec la valeur « S » ou toute autre valeur configurée) dans la table EBAN. Ce statut est souvent défini automatiquement par le système après la conversion complète en commande d’achat et la réception des marchandises. Collecte Déduit de la modification du statut du champ EBAN-EBAKZ vers une valeur indiquant la clôture. Type d’événement inferred
	Demande modifiée	Représente toute modification apportée à une demande d’achat après sa création initiale, par exemple un changement de quantité, de prix ou de matériel. Ces changements sont enregistrés dans les tables de journal des modifications de SAP, qui fournissent une piste d’audit détaillée.
Pourquoi c’est important Le suivi des modifications est essentiel pour identifier les boucles de reprise et les problèmes de qualité des données. Une fréquence élevée de modifications peut révéler des exigences initiales imprécises ou des lacunes dans la formation des utilisateurs, et entraîner des retards dans le processus. Où les obtenir Extrait des tables de journal des modifications CDHDR (en-tête) et CDPOS (poste), lorsque la classe d’objet est EINKBELEG et que l’identifiant d’objet correspond au numéro de la demande d’achat. Les modifications de champs spécifiques peuvent être analysées. Collecte Événement enregistré dans les tables de modifications CDHDR et CDPOS pour le document de demande d’achat. Type d’événement explicit
	Étape d’approbation approuvée	Représente l’action explicite par laquelle un utilisateur autorisé approuve une étape de la stratégie de validation. Cette action est enregistrée comme une modification du statut de validation de la demande et rapproche celle-ci de l’approbation finale.
Pourquoi c’est important Le suivi des approbations individuelles est nécessaire pour mesurer la durée de chaque étape et analyser la performance des différents approbateurs. Il est indispensable pour comprendre la conformité du flux de travail. Où les obtenir Extrait des journaux de modifications (CDHDR/CDPOS) concernant les champs de statut de validation de la table EBAN. L’action de l’approbateur via la transaction ME54N ou un T-code similaire déclenche l’enregistrement de cette modification. Collecte Entrée du journal des modifications créée lorsqu’un approbateur exécute une transaction de validation. Type d’événement explicit
	Étape d’approbation démarrée	Indique que la demande d’achat attend désormais l’intervention d’un approbateur ou d’un groupe d’approbation précis, conformément à la stratégie de validation. Cet événement est déduit lorsque le statut de la demande indique qu’elle attend un code de validation particulier.
Pourquoi c’est important Cette activité permet d’analyser en détail chaque étape de la chaîne d’approbation. Elle aide à déterminer quels approbateurs ou quelles étapes sont à l’origine des délais les plus longs. Où les obtenir Déduit du suivi de la séquence des modifications apportées aux champs de statut de validation dans la table EBAN. Chaque passage à un nouvel état d’attente marque le début d’une nouvelle étape d’approbation. Collecte Déduit des changements de statut indiquant qu’un nouveau code de validation est actif et attend une approbation. Type d’événement inferred
	Étape d’approbation rejetée	Un utilisateur autorisé a explicitement rejeté une étape de la stratégie de validation, ce qui renvoie généralement la demande à son créateur pour modification. Cette action est enregistrée comme une modification du statut de validation de la demande.
Pourquoi c’est important Les rejets sont une cause majeure de reprises et de retards dans le processus. L’analyse de leur fréquence et de leurs motifs permet d’identifier les incompréhensions liées aux politiques, les problèmes de qualité des données ou les étapes d’approbation inefficaces. Où les obtenir Extrait des journaux de modifications (CDHDR/CDPOS) concernant les champs de statut de validation de la table EBAN. Une action de rejet via la transaction ME54N ou une transaction similaire déclenche le changement de statut correspondant. Collecte Entrée du journal des modifications créée lorsqu’un approbateur exécute une action de rejet. Type d’événement explicit

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données de SAP ECC

Étapes

Accorder l'accès à la base de données : avant de commencer, vérifiez que vous disposez d'un accès en lecture seule à la base de données sous-jacente de SAP ECC. Cet accès nécessite des identifiants spécifiques (nom d'utilisateur, mot de passe, hôte et port) et constitue un niveau d'accès non standard qui doit être approuvé par les équipes SAP Basis et Sécurité.
Identifier le schéma SAP : connectez-vous à la base de données avec un client SQL standard, tel que DBeaver, Toad ou SQL Developer. Vous devrez identifier le schéma SAP approprié dans lequel les tables sont stockées, généralement nommé SAPSR3 ou SAPR3.
Préparer la requête SQL : utilisez la requête SQL complète fournie dans ce document. Elle est conçue pour extraire toutes les activités et tous les Attributs requis en reliant les données de référence aux tables du journal des modifications.
Définir les paramètres de la requête : repérez les valeurs fictives dans la requête. Vous devez les remplacer par les exigences propres à votre système et à votre activité. Les principales valeurs concernées sont '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' et '{document_types}'.
Adapter la syntaxe au système de base de données : la requête fournie utilise une syntaxe SQL courante. Toutefois, les fonctions de création d'horodatage, telles que TO_TIMESTAMP, ou de manipulation des chaînes peuvent nécessiter de légères adaptations selon votre système de base de données, par exemple Oracle, SQL Server, DB2 ou HANA.
Exécuter l'extraction : exécutez la requête personnalisée dans votre client SQL. Pour les volumes importants, il est vivement recommandé de lancer cette opération en dehors des heures de pointe afin de préserver les performances du système.
Vérifier les résultats préliminaires : une fois la requête terminée, examinez brièvement le résultat pour vérifier qu'il contient les colonnes attendues (PurchaseRequisitionId, ActivityName, EventTime, etc.) et que des lignes sont renvoyées pour différentes activités.
Exporter au format CSV : exportez l'ensemble des résultats depuis votre client SQL vers un fichier CSV. Vérifiez que le fichier utilise l'encodage UTF-8 afin d'éviter les problèmes liés aux caractères spéciaux.
Préparer le chargement : vérifiez que les en-têtes de colonnes du fichier CSV correspondent exactement aux alias définis dans la requête SQL. Le fichier doit présenter l'Event Log sous une forme tabulaire claire.
Charger dans ProcessMind : chargez le fichier CSV final dans votre projet ProcessMind pour l'analyser et le visualiser.

Configuration

Connexion à la base de données : une connexion directe à la base de données SAP ECC est requise. Vous aurez besoin du nom d'hôte, du port, du nom de la base de données et des identifiants utilisateur appropriés.
Schéma SAP : vous devez connaître le nom du schéma contenant les tables SAP, par exemple SAPSR3. La requête doit être exécutée dans le contexte de ce schéma.
Plage de dates : pour maîtriser les performances et le volume de données, il est essentiel de filtrer sur une plage de dates précise. Nous vous recommandons de commencer par une période de 3 à 6 mois. Définissez les valeurs '{start_date}' et '{end_date}' au format YYYYMMDD.
Filtres organisationnels : pour une analyse plus ciblée, filtrez les données selon le code société (BUKRS) et le type de document de la demande d'achat (BSART). Remplacez les valeurs '{company_codes}' et '{document_types}' par des listes séparées par des virgules, par exemple '1000','2000'.
Prérequis : cette méthode nécessite l'approbation des équipes SAP Basis et Sécurité afin d'obtenir des identifiants d'accès direct à la base de données. Il ne s'agit pas d'une opération standard pour les utilisateurs finaux.
Considérations relatives aux performances : la requête effectue des jointures avec les tables du journal des modifications (CDHDR, CDPOS), qui peuvent être très volumineuses. Sans filtrage approprié, elle peut être lente et consommer beaucoup de ressources système. Exécutez-la toujours avec une plage de dates restrictive et d'autres filtres.

a Exemple de requête sql

WITH REQUISITION_BASE AS (
    SELECT 
        EBAN.MANDT,
        EBAN.BANFN,
        EBAN.BNFPO,
        EBAN.BSART AS RequisitionDocumentType,
        EBAN.ERNAM,
        EBAN.ERDAT,
        EBAN.ERZET,
        EBAN.FRGZU AS CurrentRequisitionStatus,
        EBAKN.KOSTL AS Department,
        EBAKN.GSWRT
    FROM EBAN
    LEFT JOIN EBAKN ON EBAN.MANDT = EBAKN.MANDT AND EBAN.BANFN = EBAKN.BANFN AND EBAN.BNFPO = EBAKN.BNFPO
    WHERE EBAN.ERDAT BETWEEN '{start_date}' AND '{end_date}'
      AND EBAN.BUKRS IN ('{company_codes}')
      AND EBAN.BSART IN ('{document_types}')
),
REQUISITION_AGG AS (
    SELECT 
        MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department,
        SUM(GSWRT) AS TotalRequisitionValue
    FROM REQUISITION_BASE
    GROUP BY MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department
)
-- 1. Requisition Created
SELECT
    R.BANFN AS PurchaseRequisitionId,
    'Requisition Created' AS ActivityName,
    TO_TIMESTAMP(R.ERDAT || R.ERZET, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    R.ERNAM AS User,
    R.Department AS Department,
    R.CurrentRequisitionStatus AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM REQUISITION_AGG R

UNION ALL

-- 2. Requisition Amended, Approval Steps, Status Changes from Change Logs
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    CASE 
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW > C.VALUE_OLD THEN 'Approval Step Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW < C.VALUE_OLD THEN 'Approval Step Rejected'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_approval_status_code}' THEN 'Requisition Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_rejection_status_code}' THEN 'Requisition Rejected'
        WHEN C.FNAME = 'FRGSX' AND C.VALUE_OLD IS NOT NULL AND C.VALUE_NEW IS NULL THEN 'Approval Reset'
        WHEN C.FNAME = 'FRGZU' AND C.CHNGIND = 'U' AND C.TCODE LIKE 'ME54%' THEN 'Approval Submitted' 
        WHEN C.FNAME = 'LOEKZ' AND C.VALUE_NEW IN ('L', 'X') THEN 'Requisition Withdrawn'
        WHEN C.FNAME = 'EBAKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Blocked'
        WHEN C.FNAME = 'STATU' AND C.VALUE_NEW = 'B' THEN 'Purchase Order Created'
        WHEN C.FNAME = 'EREKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Closed'
        ELSE 'Requisition Amended'
    END AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    C.VALUE_NEW AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF'
  AND C.UDATE || C.UTIME <> R.ERDAT || R.ERZET -- Exclude changes made at the exact time of creation
  AND NOT (C.TCODE IN ('ME51', 'ME51N') AND C.UDATE = R.ERDAT) -- Exclude initial creation events from being amendments

UNION ALL

-- 3. Approval Step Started (Inferred)
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    'Approval Step Started' AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    P.VALUE_OLD AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF' AND P.FNAME = 'FRGZU' AND P.CHNGIND = 'U'
  AND P.VALUE_OLD IS NOT NULL AND P.VALUE_NEW IS NOT NULL AND P.VALUE_NEW > P.VALUE_OLD; -- This logic infers that a step starts just before it is approved

Étapes

Configurer l’environnement Python : Vérifiez que Python 3.6 ou une version ultérieure est installé. Créez un dossier de projet et configurez un environnement virtuel pour gérer les dépendances. Installez les bibliothèques nécessaires avec pip : pip install pyrfc pandas numpy
SAP RFC SDK : Téléchargez le SAP NetWeaver RFC SDK depuis le SAP Support Portal. Extrayez son contenu et placez les fichiers de bibliothèque, par exemple sapnwrfc.dll sous Windows et libsapnwrfc.so sous Linux, dans un répertoire accessible depuis le chemin système ou votre script Python.
Configurer la connexion SAP : Ouvrez le script Python fourni. Repérez la section consacrée aux paramètres de connexion SAP et remplacez les valeurs d’exemple (ashost, sysnr, client, user, passwd) par les identifiants réels de votre système SAP. Vérifiez que l’utilisateur dispose des autorisations nécessaires pour exécuter des appels RFC et accéder aux tables.
Définir les paramètres d’extraction : Dans le script, définissez les variables date_from et date_to afin de préciser la plage de dates souhaitée pour l’extraction. Il est recommandé de commencer par une période plus courte, par exemple un mois, pour tester le processus d’extraction.
Exécuter le script Python : Exécutez le script depuis votre terminal avec la commande python your_script_name.py. Le script se connecte à SAP via RFC, appelle RFC_READ_TABLE pour chacune des tables requises (EBAN, EKKO, EKPO, CDHDR, CDPOS) et télécharge les données.
Récupérer les données : Le script extrait les données brutes des demandes d’achat, des bons de commande et des documents de modification. Il utilise des critères de filtrage, tels que les plages de dates et les classes d’objets, afin de limiter le volume de données transférées.
Transformer les données localement : Une fois les données téléchargées, le script utilise la bibliothèque pandas pour effectuer toutes les transformations en local. Il traite les données brutes des tables afin de générer des entrées distinctes dans le journal d’événements pour chacune des 13 activités requises, telles que « Requisition Created », « Approval Step Approved » et « Purchase Order Created ».
Générer le journal d’événements : Le script regroupe les événements générés à partir de chaque table dans un DataFrame unique et unifié. Il calcule les horodatages des événements, associe les noms des utilisateurs et structure les données selon le format requis pour l’identifiant du cas, l’activité et l’horodatage.
Associer les attributs : Les attributs clés tels que PurchaseRequisitionId, ActivityName, EventTime, Utilisateur et TotalRequisitionValue sont associés aux colonnes correspondantes du DataFrame final.
Exporter au format CSV : Le script enregistre le journal d’événements final dans un fichier CSV nommé event_log_pr.csv, dans le même répertoire. Ce fichier est formaté pour être importé directement dans ProcessMind.
Vérifier et importer : Ouvrez le fichier CSV généré afin de vérifier l’exhaustivité et l’exactitude des données. Une fois la validation terminée, vous pouvez importer le fichier dans votre projet ProcessMind.

Configuration

Connexion SAP : le script nécessite les informations d'une connexion RFC directe au système SAP ECC, notamment le serveur d'applications, le numéro de système, le client, l'utilisateur et le mot de passe. L'utilisateur indiqué doit disposer des autorisations nécessaires pour les appels RFC et d'un accès en affichage aux tables EBAN, EKPO, EKKO, CDHDR et CDPOS.
Plage de dates : l'extraction est régie par les paramètres de date de début et de fin définis dans le script. Pour les premières exécutions et afin de maîtriser les performances, il est recommandé d'extraire une période de 3 à 6 mois.
Filtres sur les tables : lorsque cela est possible, le filtrage est appliqué dans les appels RFC. Par exemple, les demandes sont filtrées selon leur date de création (EBAN-ERDAT) et les documents de modification selon la date (CDHDR-UDATE) et la classe d'objet (CDHDR-OBJECTCLAS = 'BANF').
Bibliothèques Python : le script utilise pyrfc pour la connexion à SAP et pandas pour la manipulation des données. Vérifiez que ces bibliothèques sont installées dans votre environnement Python.
Performances : l'extraction via RFC_READ_TABLE peut être lente pour les volumes très importants, car les données sont récupérées séquentiellement, table par table. Il est conseillé d'exécuter l'extraction en dehors des heures de pointe afin de limiter la charge du système.
Types de document : par défaut, le script extrait tous les types de document de demande d'achat. Pour réduire le périmètre, vous pouvez ajouter un filtre après extraction dans le DataFrame pandas, à partir de la colonne BSART de la table EBAN.

a Exemple de requête python

import pandas as pd
from pyrfc import Connection
import datetime

class=class="hl-string">"hl-comment"># --- 1. Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your SAP system connection details
SAP_CONNECTION_PARAMS = {
    class="hl-string">"ashost": class="hl-string">"your_sap_host",      class=class="hl-string">"hl-comment"># Application server host
    class="hl-string">"sysnr": class="hl-string">"00",                 class=class="hl-string">"hl-comment"># System number
    class="hl-string">"client": class="hl-string">"100",               class=class="hl-string">"hl-comment"># Client
    class="hl-string">"user": class="hl-string">"your_rfc_user",       class=class="hl-string">"hl-comment"># RFC user
    class="hl-string">"passwd": class="hl-string">"your_password"      class=class="hl-string">"hl-comment"># Password
}

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYYMMDD format)
date_from = class="hl-string">'20230101'
date_to = class="hl-string">'20231231'

source_system = class="hl-string">"SAP ECC"
last_data_update = datetime.datetime.now().isoformat()

class=class="hl-string">"hl-comment"># --- 2. Helper function for RFC_READ_TABLE ---
def rfc_read_table(conn, table_name, fields, options):
    class="hl-string">"""Fetches data from an SAP table using RFC_READ_TABLE."""
    try:
        result = conn.call(class="hl-string">'RFC_READ_TABLE',
                           QUERY_TABLE=table_name,
                           DELIMITER=class="hl-string">',',
                           FIELDS=fields,
                           OPTIONS=options)
        
        data = result[class="hl-string">'DATA']
        if not data:
            return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

        records = [row[class="hl-string">'WA'].strip().split(class="hl-string">',') for row in data]
        df = pd.DataFrame(records, columns=[field[class="hl-string">'FIELDNAME'] for field in fields])
        class=class="hl-string">"hl-comment"># Trim whitespace from all cells
        df = df.apply(lambda x: x.str.strip() if x.dtype == class="hl-string">"object" else x)
        return df
    except Exception as e:
        print(fclass="hl-string">"Error reading table {table_name}: {e}")
        return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

class=class="hl-string">"hl-comment"># --- 3. Main Extraction Logic ---
def main():
    print(class="hl-string">"Starting SAP data extraction...")
    try:
        conn = Connection(**SAP_CONNECTION_PARAMS)
    except Exception as e:
        print(fclass="hl-string">"Failed to connect to SAP: {e}")
        return

    class=class="hl-string">"hl-comment"># --- EBAN (Purchase Requisitions) ---
    print(class="hl-string">"Extracting EBAN...")
    eban_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'BSART'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERNAM'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERDAT'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERFZEIT'}, {class="hl-string">'FIELDNAME': class="hl-string">'PREIS'}, {class="hl-string">'FIELDNAME': class="hl-string">'MENGE'}, {class="hl-string">'FIELDNAME': class="hl-string">'KOSTL'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGZU'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGSX'}]
    eban_options = [fclass="hl-string">"ERDAT >= '{date_from}' AND ERDAT <= '{date_to}'"]
    df_eban = rfc_read_table(conn, class="hl-string">'EBAN', eban_fields, eban_options)
    if df_eban.empty:
        print(class="hl-string">"No requisitions found in EBAN for the given date range. Exiting.")
        conn.close()
        return

    df_eban[class="hl-string">'PREIS'] = pd.to_numeric(df_eban[class="hl-string">'PREIS'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'MENGE'] = pd.to_numeric(df_eban[class="hl-string">'MENGE'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'TotalRequisitionValue'] = df_eban[class="hl-string">'PREIS'] * df_eban[class="hl-string">'MENGE']
    df_eban_grouped = df_eban.groupby(class="hl-string">'BANFN').agg(
        TotalRequisitionValue=(class="hl-string">'TotalRequisitionValue', class="hl-string">'sum'),
        RequisitionDocumentType=(class="hl-string">'BSART', class="hl-string">'first'),
        Department=(class="hl-string">'KOSTL', class="hl-string">'first')
    ).reset_index()
    df_eban = df_eban.merge(df_eban_grouped, on=class="hl-string">'BANFN', suffixes=(class="hl-string">'', class="hl-string">'_agg'))

    class=class="hl-string">"hl-comment"># --- EKPO/EKKO (Purchase Orders) ---
    print(class="hl-string">"Extracting EKPO and EKKO...")
    banfn_list = class="hl-string">"'" + class="hl-string">"', '".join(df_eban[class="hl-string">'BANFN'].unique()) + class="hl-string">"'"
    ekpo_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}]
    ekpo_options = [fclass="hl-string">"BANFN IN ({banfn_list})"]
    df_ekpo = rfc_read_table(conn, class="hl-string">'EKPO', ekpo_fields, ekpo_options)

    ekko_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}, {class="hl-string">'FIELDNAME': class="hl-string">'AEDAT'}]
    if not df_ekpo.empty:
        ebeln_list = class="hl-string">"'" + class="hl-string">"', '".join(df_ekpo[class="hl-string">'EBELN'].unique()) + class="hl-string">"'"
        ekko_options = [fclass="hl-string">"EBELN IN ({ebeln_list})"]
        df_ekko = rfc_read_table(conn, class="hl-string">'EKKO', ekko_fields, ekko_options)
        df_po = pd.merge(df_ekpo, df_ekko, on=class="hl-string">'EBELN')
    else:
        df_po = pd.DataFrame(columns=[class="hl-string">'BANFN', class="hl-string">'BNFPO', class="hl-string">'EBELN', class="hl-string">'AEDAT'])

    class=class="hl-string">"hl-comment"># --- CDHDR/CDPOS (Change Documents) ---
    print(class="hl-string">"Extracting CDHDR and CDPOS...")
    cdhdr_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'OBJECTID'}, {class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'USERNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'UDATE'}, {class="hl-string">'FIELDNAME': class="hl-string">'UTIME'}]
    cdhdr_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND UDATE >= '{date_from}' AND UDATE <= '{date_to}'"]
    df_cdhdr = rfc_read_table(conn, class="hl-string">'CDHDR', cdhdr_fields, cdhdr_options)
    
    df_cdpos = pd.DataFrame()
    if not df_cdhdr.empty:
        class=class="hl-string">"hl-comment"># Process changenr in chunks to avoid overly long SQL queries
        changenr_chunks = [df_cdhdr[class="hl-string">'CHANGENR'][i:i + 100] for i in range(0, df_cdhdr.shape[0], 100)]
        cdpos_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'TABNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'FNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_NEW'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_OLD'}]
        cdpos_frames = []
        for chunk in changenr_chunks:
            changenr_list = class="hl-string">"'" + class="hl-string">"', '".join(chunk) + class="hl-string">"'"
            cdpos_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND CHANGENR IN ({changenr_list}) AND TABNAME = 'EBAN'"]
            cdpos_frames.append(rfc_read_table(conn, class="hl-string">'CDPOS', cdpos_fields, cdpos_options))
        if cdpos_frames:
            df_cdpos = pd.concat(cdpos_frames, ignore_index=True)

    conn.close()
    print(class="hl-string">"Extraction from SAP complete. Starting transformation...")

    class=class="hl-string">"hl-comment"># --- 4. Event Log Generation ---
    events = []

    class=class="hl-string">"hl-comment"># Activity: Requisition Created
    df_created = df_eban[[class="hl-string">'BANFN', class="hl-string">'ERNAM', class="hl-string">'ERDAT', class="hl-string">'ERFZEIT', class="hl-string">'RequisitionDocumentType', class="hl-string">'TotalRequisitionValue', class="hl-string">'Department']].drop_duplicates(subset=[class="hl-string">'BANFN'])
    for _, row in df_created.iterrows():
        events.append({
            class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': fclass="hl-string">"{row['ERDAT']} {row['ERFZEIT']}",
            class="hl-string">'User': row[class="hl-string">'ERNAM'],
            class="hl-string">'RequisitionDocumentType': row[class="hl-string">'RequisitionDocumentType'],
            class="hl-string">'TotalRequisitionValue': row[class="hl-string">'TotalRequisitionValue'],
            class="hl-string">'Department': row[class="hl-string">'Department'],
            class="hl-string">'RequisitionStatus': class="hl-string">'Created'
        })

    class=class="hl-string">"hl-comment"># Merge change documents
    df_changes = pd.DataFrame()
    if not df_cdhdr.empty and not df_cdpos.empty:
        df_changes = pd.merge(df_cdhdr, df_cdpos, on=class="hl-string">'CHANGENR')
        df_changes[class="hl-string">'PurchaseRequisitionId'] = df_changes[class="hl-string">'OBJECTID'].str[:10]
        df_changes[class="hl-string">'EventTime'] = pd.to_datetime(df_changes[class="hl-string">'UDATE'] + class="hl-string">' ' + df_changes[class="hl-string">'UTIME'], format=class="hl-string">'%Y%m%d %H%M%S')

    if not df_changes.empty:
        class=class="hl-string">"hl-comment"># Activities from Change Logs
        for _, row in df_changes.iterrows():
            activity = None
            status = None

            class=class="hl-string">"hl-comment"># Approval-related activities
            if row[class="hl-string">'FNAME'] in [class="hl-string">'FRGZU', class="hl-string">'FRGSX']:
                if row[class="hl-string">'VALUE_OLD'].strip() == class="hl-string">'' and row[class="hl-string">'VALUE_NEW'].strip() != class="hl-string">'':
                    activity = class="hl-string">'Approval Submitted'
                    status = class="hl-string">'In Approval'
                elif row[class="hl-string">'VALUE_OLD'] != class="hl-string">'' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'':
                    activity = class="hl-string">'Approval Reset'
                    status = class="hl-string">'In Progress'
                else:
                    class=class="hl-string">"hl-comment"># Logic to differentiate approve/reject might need config specifics
                    activity = class="hl-string">'Approval Step Approved' if row[class="hl-string">'VALUE_NEW'] > row[class="hl-string">'VALUE_OLD'] else class="hl-string">'Approval Step Rejected'
                    status = class="hl-string">'In Approval'
            class=class="hl-string">"hl-comment"># Final Approval/Rejection
            elif row[class="hl-string">'FNAME'] == class="hl-string">'FRGZU':
                 class=class="hl-string">"hl-comment"># This logic assumes specific final approval/rejection codes. Adjust if needed.
                 if row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'X', class="hl-string">'Y', class="hl-string">'Z']: class=class="hl-string">"hl-comment"># Placeholder for final approval states
                     activity = class="hl-string">'Requisition Approved'
                     status = class="hl-string">'Approved'
                 elif row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'R', class="hl-string">'S']: class=class="hl-string">"hl-comment"># Placeholder for final rejection states
                     activity = class="hl-string">'Requisition Rejected'
                     status = class="hl-string">'Rejected'
            class=class="hl-string">"hl-comment"># Other Amendments
            elif row[class="hl-string">'FNAME'] not in [class="hl-string">'FRGZU', class="hl-string">'FRGSX', class="hl-string">'LOEKZ', class="hl-string">'EBAKZ']:
                activity = class="hl-string">'Requisition Amended'
                status = class="hl-string">'Amended'
            class=class="hl-string">"hl-comment"># Blocked
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'B':
                activity = class="hl-string">'Requisition Blocked'
                status = class="hl-string">'Blocked'
            class=class="hl-string">"hl-comment"># Withdrawn
            elif row[class="hl-string">'FNAME'] == class="hl-string">'LOEKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Withdrawn'
                status = class="hl-string">'Withdrawn'
            class=class="hl-string">"hl-comment"># Closed
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Closed'
                status = class="hl-string">'Closed'

            if activity:
                events.append({
                    class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'PurchaseRequisitionId'],
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': row[class="hl-string">'EventTime'].strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'User': row[class="hl-string">'USERNAME'],
                    class="hl-string">'RequisitionStatus': status
                })

    class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
    if not df_po.empty:
        df_po_first = df_po.sort_values(class="hl-string">'AEDAT').drop_duplicates(class="hl-string">'BANFN', keep=class="hl-string">'first')
        for _, row in df_po_first.iterrows():
            events.append({
                class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': fclass="hl-string">"{row['AEDAT']} 00:00:00", class=class="hl-string">"hl-comment"># EKKO only has date
                class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User info not directly in EKKO/EKPO for this event
                class="hl-string">'RequisitionStatus': class="hl-string">'PO Created'
            })
            
    class=class="hl-string">"hl-comment"># Dummy activities for Approval Step Started (inferred before approval)
    class=class="hl-string">"hl-comment"># This is a simplified inference. Real logic can be much more complex.
    approval_events = [e for e in events if e[class="hl-string">'ActivityName'] == class="hl-string">'Approval Step Approved']
    for event in approval_events:
        event_time = pd.to_datetime(event[class="hl-string">'EventTime'])
        class=class="hl-string">"hl-comment"># Infer class="hl-string">'started' event one minute before class="hl-string">'approved' for demonstration
        start_time = event_time - datetime.timedelta(minutes=1)
        events.append({
            class="hl-string">'PurchaseRequisitionId': event[class="hl-string">'PurchaseRequisitionId'],
            class="hl-string">'ActivityName': class="hl-string">'Approval Step Started',
            class="hl-string">'EventTime': start_time.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
            class="hl-string">'User': None, class=class="hl-string">"hl-comment"># Approver user is not known until they approve
            class="hl-string">'RequisitionStatus': class="hl-string">'In Approval'
        })

    class=class="hl-string">"hl-comment"># --- 5. Final Formatting ---
    if not events:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df_event_log = pd.DataFrame(events)
    df_event_log = df_event_log.merge(df_eban_grouped, left_on=class="hl-string">'PurchaseRequisitionId', right_on=class="hl-string">'BANFN', how=class="hl-string">'left')
    df_event_log[class="hl-string">'EventTime'] = pd.to_datetime(df_event_log[class="hl-string">'EventTime'])
    df_event_log = df_event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Fill forward attributes within each case
    df_event_log[class="hl-string">'RequisitionDocumentType'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'RequisitionDocumentType_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'TotalRequisitionValue'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'TotalRequisitionValue_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'Department'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'Department_agg'].transform(lambda x: x.ffill().bfill())

    class=class="hl-string">"hl-comment"># Add standard columns
    df_event_log[class="hl-string">'SourceSystem'] = source_system
    df_event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and rename final columns
    final_columns = {
        class="hl-string">'PurchaseRequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName': class="hl-string">'ActivityName',
        class="hl-string">'EventTime': class="hl-string">'EventTime',
        class="hl-string">'SourceSystem': class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate': class="hl-string">'LastDataUpdate',
        class="hl-string">'User': class="hl-string">'User',
        class="hl-string">'Department': class="hl-string">'Department',
        class="hl-string">'RequisitionStatus': class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionDocumentType': class="hl-string">'RequisitionDocumentType',
        class="hl-string">'TotalRequisitionValue': class="hl-string">'TotalRequisitionValue'
    }
    df_event_log = df_event_log[final_columns.keys()].rename(columns=final_columns)
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df_event_log.to_csv(class="hl-string">'event_log_pr.csv', index=False)
    print(class="hl-string">"Event log successfully created: event_log_pr.csv")

if __name__ == class="hl-string">'__main__':
    main()

Prêt à commencer ?

Utilisez ce modèle pour structurer correctement vos données en vue du Process Mining et obtenir des analyses détaillées de votre processus Purchase to Pay, demandes d’achat. Commencez dès aujourd’hui à optimiser vos processus !

Retour au guide d’amélioration Télécharger le modèle

Améliorez l'efficacité de vos demandes d'achat P2P, démarrez votre essai dès maintenant

Repérez et résolvez les goulots d'étranglement P2P, et réduisez la durée des cycles de 30 % ou plus.

Démarrer l'essai gratuit

Aucune carte bancaire requise, accès gratuit pendant 14 jours

Votre modèle de données Purchase to Pay, demandes d’achat

Votre modèle de données Purchase to Pay, demandes d’achat

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d'extraction

Requête SQL directe sur la base de données sous-jacente de SAP ECC

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant SAP RFC pour l'extraction de tables

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Améliorez l'efficacité de vos demandes d'achat P2P, démarrez votre essai dès maintenant

Votre modèle de données Purchase to Pay, demandes d’achat

Votre modèle de données Purchase to Pay, demandes d’achat

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d'extraction

Requête SQL directe sur la base de données sous-jacente de SAP ECC

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant SAP RFC pour l'extraction de tables

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Améliorez l'efficacité de vos demandes d'achat P2P, démarrez votre essai dès maintenant

Nous attachons de l’importance à votre confidentialité

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités