> Amélioration continue des processus > Du processus Purchase to Pay à la demande d’achat > SAP ECC > Modèle de données

Votre modèle de données pour les demandes d’achat, de l’achat au paiement

SAP ECC

Attributs des demandes d’achat, de l’achat au paiement(19) Activités des demandes d’achat, de l’achat au paiement(13) Guides d’extraction(2)

Votre modèle de données pour les demandes d’achat, de l’achat au paiement

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse de votre processus de demande d’achat, de l’achat au paiement. Il précise les champs à recueillir, les activités à suivre et les méthodes pratiques pour extraire ces informations de votre système source. Utilisez ces ressources pour préparer vos données à l’analyse par Process Mining.

Attributs recommandés à recueillir
Activités clés à suivre
Guide d’extraction pour SAP ECC

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs des demandes d’achat, de l’achat au paiement

Voici les champs recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de demande d’achat, de l’achat au paiement.

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 indique la date et l’heure précises auxquelles une activité donnée a eu lieu. Cet horodatage est indispensable à toutes les analyses temporelles en Process Mining, notamment au calcul des temps de cycle, à l’identification des goulots d’étranglement et à l’évaluation des performances du processus. Dans le processus de demande d’achat, cet attribut permet de calculer des KPI essentiels, tels que le « Temps 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 présentent 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 temps écoulé entre deux étapes du processus. Pourquoi est-ce important ? Cet horodatage est indispensable au calcul des durées, à l’analyse des performances du processus et à la détection des goulots d’étranglement liés au temps. Où trouver ces données 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é principale qui distingue chaque demande de biens ou de services dans SAP ECC. Il sert d’identifiant de cas central et relie toutes les activités et modifications associées à une demande, de sa création à sa résolution finale, par exemple sa conversion en bon de commande 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 de processus, mesurer les délais entre les étapes clés et comparer le traitement des différentes demandes. Ils obtiennent ainsi une vue cohérente de tout le parcours de chaque demande. Pourquoi est-ce important ? Cet identifiant central relie tous les événements associés au processus dans un même cas et rend possible l’analyse de bout en bout. Où trouver ces données Dans la table EBAN, champ BANFN. Exemples 100234567810023456791002345680
	Nom de l’activité ActivityName	Nom de l’activité métier réalisée à 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 « Bon de commande créé ». 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 est au fondement du process mining. Elle permet de découvrir les flux réels du processus, notamment les parcours habituels, les écarts et les goulots d’étranglement. Elle est essentielle pour créer des Dashboards, comme la carte de bout en bout du processus de demande d’achat, et calculer les indicateurs clés de performance liés aux reprises et à la conformité. Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser les cartes de processus et d’analyser les variations de flux. Où trouver ces données 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 d’achat crééeÉtape d’approbation approuvéeDemande d’achat rejetéeBon de commande créé
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données ou de leur dernière extraction du 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 à chaque chargement, qui sert de repère pour évaluer l’actualité de l’analyse. Pour prendre des décisions éclairées à partir d’un Dashboard ou d’une analyse de Process Mining, il est essentiel de connaître la date des données. Cet attribut permet à toutes les parties prenantes de savoir quelle période les données affichées couvrent et évite de tirer des conclusions à partir d’informations obsolètes. Pourquoi est-ce important ? Indique aux utilisateurs si les données sont à jour, un élément essentiel pour garantir la pertinence et la précision de l’analyse du processus. Où trouver ces données Cette valeur statique correspond à l’horodatage de l’extraction des données et est ajoutée lors du processus ETL. Exemples 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Système source SourceSystem	Indique le système source dont 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 d’apporter du contexte, notamment lorsque plusieurs systèmes sources sont utilisés. Dans l’analyse des processus, cet attribut permet de distinguer les données provenant de différentes sources et d’éviter que les résultats soient faussés par le mélange de données issues des environnements de production, de test ou de développement. Il constitue une métadonnée essentielle pour la gouvernance et la traçabilité des données. Pourquoi est-ce important ? Apporte un contexte essentiel sur l’origine des données, garantit leur traçabilité et permet l’analyse de plusieurs systèmes. Où trouver ces données Cette valeur statique est généralement ajoutée lors du processus d’extraction, de transformation et de chargement des données (ETL). 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 à l’origine 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 s’agit souvent d’un identifiant utilisateur. L’analyse par utilisateur permet de repérer les besoins de formation, d’évaluer les performances individuelles et de détecter d’éventuelles erreurs de saisie. Cet attribut est essentiel pour des Dashboards tels que « Volume de demandes d’achat créées par demandeur », ainsi que pour comprendre la répartition de la charge de travail et le respect des règles de séparation des tâches. Pourquoi est-ce important ? Associe les activités à des personnes précises et permet d’analyser les performances, la charge de travail, la conformité et les besoins de formation des utilisateurs. Où trouver ces données 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 désigne l’unité opérationnelle ou le service à l’origine de la demande d’achat. Il est souvent déterminé à partir du profil utilisateur du demandeur ou du centre de coûts associé au poste de la demande. L’analyse du processus par service est essentielle pour comprendre les écarts de performance au sein de l’organisation. Cet attribut constitue la principale dimension du Dashboard « Temps de cycle d’approbation des demandes d’achat » et du KPI « Écart du temps d’approbation entre les services ». Il aide à repérer les services dont les processus sont efficaces et ceux qui pourraient nécessiter des améliorations ou des ressources supplémentaires. Pourquoi est-ce important ? Permet de comparer les performances entre unités opérationnelles et de repérer les goulots d’étranglement et les écarts de processus propres à chaque service. Où trouver ces données Souvent déterminé en reliant le demandeur (EBAN-AFNAM) aux données de base des utilisateurs (SU01), ou à partir 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 de 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é », « Rejeté » ou « Clôturé ». Dans SAP, il est souvent représenté par un code de statut. Le suivi du statut est essentiel pour comprendre l’issue des demandes d’achat. Il alimente directement le Dashboard « Résultats et taux de rejet des demandes d’achat » et des KPI tels que le « Taux de rejet des demandes d’achat » et le « Taux de retrait des demandes d’achat ». L’analyse des transitions entre les statuts aide à repérer les inefficacités et les points de blocage du processus. Pourquoi est-ce important ? Détermine l’issue d’une demande d’achat, un élément essentiel pour analyser les taux de réussite, les motifs de rejet et les étapes finales du processus. Où trouver ces données Le statut de traitement figure dans la table EBAN, champ STATU. Le statut de validation figure dans EBAN-FRGZU. Exemples N (Non modifié)B (Commande d’achat créée)A (Demande de prix créée)K (Clôturé)
	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 définit plusieurs aspects d’une demande d’achat, notamment la plage de numérotation, la sélection des champs et le processus d’approvisionnement suivi. Parmi les exemples figurent « Demande d’achat standard », « Transfert de stock » et « Demande d’achat de services ». Cet attribut constitue une dimension d’analyse utile, car les différents types de documents suivent souvent des flux de processus et des règles d’approbation distincts. Il permet de segmenter les données et de comparer les performances des différents processus de demande d’achat, afin d’évaluer la conformité et de repérer les possibilités de standardisation ou de spécialisation. Pourquoi est-ce important ? Permet de répartir les demandes d’achat entre différentes catégories de processus et d’obtenir des analyses plus précises et pertinentes. Où trouver ces données 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 total de la demande d’achat. La valeur détermine souvent le circuit d’approbation requis : les demandes d’un montant élevé font généralement l’objet d’un examen plus approfondi et nécessitent davantage d’approbations. L’analyse par montant permet de comprendre comment l’incidence financière influe sur le déroulement du processus. Elle peut révéler si les demandes d’un montant élevé sont plus longues à approuver, plus souvent rejetées ou traitées selon des parcours différents. Il s’agit également d’une métrique fondamentale pour évaluer le volume financier traité par le processus d’approvisionnement. Pourquoi est-ce important ? Permet de mettre en relation le déroulement du processus et son incidence financière, un élément essentiel pour l’analyse des risques et la compréhension de la complexité des approbations. Où trouver ces données Somme des montants de tous les postes. Le montant d’un poste figure dans la table EBAN, champ GSWER. La devise est indiquée dans EBAN-WAERS. Exemples 1500.00250.50125000.00
	Comporte des reprises IsRework	Indicateur booléen précisant si la demande d’achat a fait l’objet d’une boucle de reprise, par exemple une modification après son envoi.
Description Cet attribut calculé signale les activités ou les dossiers qui comportent des reprises. Par exemple, toute activité « Demande d’achat modifiée » survenant après « Approbation soumise » est considérée comme une reprise. Un événement de rejet qui renvoie le processus à une étape antérieure peut également déclencher cet indicateur. Cet indicateur est essentiel au Dashboard « Analyse des modifications et des reprises des demandes d’achat ». Il permet de filtrer et de quantifier facilement les reprises, afin d’évaluer leur incidence sur les temps de cycle globaux et d’identifier les causes profondes des inefficacités du processus. Un taux élevé de reprises signale souvent des problèmes de qualité des données ou des exigences peu claires. Pourquoi est-ce important ? Permet de mesurer la fréquence et l’incidence des reprises et de repérer et d’analyser facilement les inefficacités et les boucles du processus. Où trouver ces données Déduit du journal d’événements en repérant des séquences d’activités précises, par exemple une activité « Demande d’achat modifiée » après une activité d’approbation. Exemples truefalse
	Groupe d’acheteurs PurchasingGroup	Groupe d’acheteurs chargé de l’approvisionnement des articles demandés.
Description Le groupe d’acheteurs est une unité organisationnelle chargée d’activités d’approvisionnement précises. Il désigne l’équipe qui prend en charge la demande une fois celle-ci approuvée. Cet attribut permet d’analyser la charge de travail et les performances des différentes équipes d’achat. Il aide à repérer les groupes qui ralentissent la conversion des demandes en commandes ou ceux qui traitent plus efficacement certains types de demandes. Il constitue une dimension importante pour la gestion des ressources et des performances de la fonction achats. Pourquoi est-ce important ? Attribue la responsabilité des achats et permet d’analyser la charge de travail et de comparer les performances des différentes équipes. Où trouver ces données Présent dans la table EBAN, champ EKGRP. Exemples 001002P01
	Groupe de marchandises MaterialGroup	Groupe ou catégorie auxquels appartient le matériel ou le service demandé.
Description Le groupe de marchandises est une classification qui rassemble les matériels ou les 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. En Process Mining, elle peut révéler si les demandes portant sur certaines catégories, comme le « Matériel informatique » ou les « Services professionnels », suivent des parcours différents ou nécessitent davantage de temps pour être approuvées. Ces informations sont utiles au « Rapport sur la qualité des données des demandes d’achat » et permettent de comprendre les variations du processus selon les articles achetés. Pourquoi est-ce important ? Permet d’analyser les dépenses et les processus par catégorie d’approvisionnement, de soutenir la stratégie d’achat et de repérer les goulots d’étranglement propres à certaines catégories. Où trouver ces données 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 créée pour y répondre. Une même demande peut parfois donner lieu à plusieurs commandes d’achat. Ce lien est essentiel pour analyser le passage entre le processus de demande d’achat et celui des achats. Il est nécessaire au calcul du KPI « Délai entre la demande d’achat et la création de la commande » et alimente le Dashboard « Délai entre l’approbation de la demande d’achat et la création de la commande ». Comprendre ce lien permet d’évaluer l’efficacité de l’ensemble du cycle d’approvisionnement et de paiement. Pourquoi est-ce important ? Relie le processus de demande d’achat au processus d’achat qui lui fait suite et permet d’analyser les délais de transfert. Où trouver ces données Après sa création, le numéro de commande d’achat est enregistré dans la table EBAN, champ EBELN. Exemples 450001712345000171244500017125
	Identifiant du fournisseur VendorId	Identifiant unique du fournisseur proposé ou imposé.
Description Cet attribut contient l’identifiant d’un fournisseur privilégié ou imposé par contrat pour l’article demandé. Il peut être renseigné à l’avance ou proposé par le demandeur. L’analyse des demandes d’achat par fournisseur permet d’évaluer l’incidence de la présélection des fournisseurs sur le processus d’approvisionnement. Elle peut, par exemple, montrer si les demandes associées à un fournisseur précis sont approuvées plus rapidement ou si certains fournisseurs sont liés à un taux de rejet plus élevé. Elle donne un aperçu des relations avec les fournisseurs dès les premières étapes du processus. Pourquoi est-ce important ? Donne un aperçu des relations avec les fournisseurs privilégiés et de leur incidence sur la rapidité de traitement et l’issue des demandes d’achat. Où trouver ces données Présent dans la table EBAN, champ LIFNR (fournisseur imposé). Exemples 100030025V9876
	Motif du rejet RejectionReason	Motif indiqué lors du rejet d’une demande d’achat ou d’une étape d’approbation.
Description Cet attribut consigne le motif du rejet d’une demande d’achat. Lors de l’activité de rejet, l’approbateur saisit généralement ce motif en texte libre ou le sélectionne dans une liste de codes prédéfinis. L’analyse des motifs de rejet est essentielle à l’amélioration du processus. Elle indique directement pourquoi les demandes échouent, par exemple en raison d’un non-respect des règles, de données incorrectes ou d’un budget insuffisant. Ces données alimentent le Dashboard « Résultats et taux de rejet des demandes d’achat » et aident à repérer les causes profondes des inefficacités du processus. Pourquoi est-ce important ? Indique directement pourquoi les demandes d’achat sont rejetées et permet de cibler les améliorations du processus et les formations des utilisateurs. Où trouver ces données Ces données sont généralement enregistrées dans les journaux de flux de travail ou dans le texte long associé à l’événement de rejet. La table EBAN ne comporte pas de champ standard à cet effet. Exemples Centre de coûts incorrectBudget dépasséDemande en doubleNon conforme aux règles
	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, c’est-à-dire celle qui a besoin des articles demandés. Le suivi du demandeur permet d’analyser les habitudes de demande par personne ou par groupe. Le Dashboard « Volume de demandes d’achat créées par demandeur » s’appuie sur cet attribut pour repérer les utilisateurs les plus actifs, ceux qui pourraient avoir besoin d’une formation complémentaire ou les services dont l’activité d’approvisionnement est élevée. Il donne une vision du processus centrée sur les personnes qui en sont à l’origine. Pourquoi est-ce important ? Identifie le responsable du processus, permet d’analyser les habitudes de création des demandes d’achat et aide à cibler les formations destinées aux utilisateurs. Où trouver ces données 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 ». Il signale aux approbateurs et aux acheteurs qu’une demande doit être traitée en priorité. Cet attribut est essentiel au Dashboard « Performance de traitement des demandes d’achat urgentes » et au KPI « Efficacité du signalement des urgences ». L’analyse consiste à vérifier si les demandes signalé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 s’assurer que les besoins prioritaires de l’entreprise sont satisfaits rapidement. Pourquoi est-ce important ? Permet de vérifier si les demandes urgentes sont traitées plus rapidement et d’évaluer l’efficacité des mécanismes de priorisation. Où trouver ces données Il ne s’agit pas d’un champ standard de la table EBAN. Cet attribut est souvent ajouté sous forme de champ personnalisé ou déduit du numéro de suivi des besoins (EBAN-BEDNR) ou d’un type de document particulier. Exemples 123
	Site Plant	Site ou établissement de l’entreprise pour lequel les biens ou les services sont demandés.
Description Le site est une unité organisationnelle de l’entreprise qui correspond à un lieu 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’examiner le processus de demande d’achat selon la zone géographique ou le lieu concerné. Elle peut mettre en évidence des écarts de performance entre les sites, liés par exemple aux procédures locales, aux effectifs ou aux besoins de l’activité. Cette dimension est couramment utilisée dans les Dashboards de performance régionale. Pourquoi est-ce important ? Apporte un contexte géographique ou lié au lieu et aide à repérer les variations du processus et les écarts de performance entre les régions. Où trouver ces données Présent dans la table EBAN, champ WERKS. Exemples 10002100DE01

Obligatoire Recommandé Facultatif

Activités des demandes d’achat, de l’achat au paiement

Voici les principales étapes et les jalons du processus à consigner dans votre journal d’événements pour découvrir et analyser avec précision le flux de travail des 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 d’approbation officiel. Elle est généralement déduite du changement de statut de la demande, qui nécessite une première libération ou approbation selon la stratégie de libération configurée.
Pourquoi est-ce important ? Cette activité marque le début du temps de cycle d’approbation, un indicateur clé pour mesurer l’efficacité du processus. Ce repère permet d’isoler les retards entre la création de la demande et le début des approbations officielles. Où trouver ces données Événement déduit du premier changement de statut lié à la stratégie de libération 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. Données à recueillir Événement déduit de la première entrée du journal des modifications indiquant l’activation d’une stratégie de libération. Type d’événement inferred
	Bon de commande créé	Cette activité marque la conversion réussie d’une demande d’achat approuvée en document de bon de commande. L’événement est déduit pour la demande en recherchant un poste de bon de commande correspondant qui y fait référence.
Pourquoi est-ce important ? Cette activité marque la principale issue favorable du processus de demande d’achat et le début de la phase d’approvisionnement. Le délai entre « Demande d’achat approuvée » et cet événement est un indicateur clé de l’efficacité de la transmission. Où trouver ces données Événement déduit de la recherche d’un enregistrement dans la table EKPO (poste de bon de commande), où 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 du bon de commande (EKKO.AEDAT) fournit l’horodatage. Données à recueillir Événement déduit en reliant les tables EBAN et EKPO et en utilisant la date de création du bon de commande dans EKKO. Type d’événement inferred
	Demande d’achat approuvée	Cette étape clé indique que la demande d’achat a passé avec succès toutes les étapes d’approbation requises. Elle est déduite lorsque le code de libération final est appliqué et que l’indicateur global de libération (FRGZU) de la table EBAN passe à l’état approuvé.
Pourquoi est-ce important ? Cette étape clé marque la fin du cycle d’approbation et le début de la phase d’approvisionnement. Elle est essentielle pour calculer l’indicateur du temps total d’approbation et mesurer les retards avant la création du bon de commande. Où trouver ces données Événement déduit de l’horodatage de l’entrée du journal des modifications dans CDPOS pour la table EBAN, champ FRGZU, lorsque sa valeur correspond à l’approbation finale. Données à recueillir Événement déduit lorsque le champ de l’indicateur de libération finale de la table EBAN atteint l’état final « approuvé ». Type d’événement inferred
	Demande d’achat créée	Cette activité correspond à la création et à l’enregistrement initial 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 est-ce important ? Point de départ du processus, cette activité est essentielle pour calculer la durée totale du cycle de vie des demandes d’achat et analyser le volume de créations. Elle permet de savoir qui crée les demandes et à quel moment. Où trouver ces données 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), pour un identifiant de demande d’achat donné (BANFN). Données à recueillir Horodatage extrait des champs ERDAT et UZEIT de la table EBAN lors de l’enregistrement initial. Type d’événement explicit
	Demande d’achat rejetée	Cette activité marque le rejet définitif de la demande d’achat, qui ne peut alors plus être traitée. Elle est déduite lorsque l’indicateur de libération de la table EBAN passe à l’état final de rejet à la suite de l’intervention d’un approbateur.
Pourquoi est-ce important ? Cette activité marque une issue importante du processus et permet de calculer l’indicateur du taux de rejet des demandes d’achat. L’analyse de ces cas aide à comprendre les causes d’échec et les efforts inutiles dans le processus d’approvisionnement. Où trouver ces données Événement déduit de l’horodatage de l’entrée du journal des modifications dans CDPOS pour la table EBAN, champ FRGZU, lorsque sa valeur correspond au rejet final. Données à recueillir Événement déduit lorsque le champ de l’indicateur de libération finale de la table EBAN atteint l’état final « rejeté ». Type d’événement inferred
	Demande d’achat retirée	Cette activité marque l’annulation du poste de demande d’achat par son créateur ou un utilisateur autorisé, au moyen d’un indicateur de suppression. L’action est enregistrée explicitement et indique que le besoin n’est plus d’actualité ou que la demande a été créée par erreur.
Pourquoi est-ce important ? Cette activité marque une issue défavorable importante du processus et permet de calculer le taux de retrait. Un taux élevé peut indiquer que les longs délais d’approbation poussent les utilisateurs à abandonner leurs demandes, ou révéler des problèmes de planification des besoins. Où trouver ces données Cette action explicite est enregistrée lorsque le champ « Indicateur de suppression » (LOEKZ) de la table EBAN est activé pour le poste de la demande. La modification est consignée dans CDHDR et CDPOS. Données à recueillir Entrée du journal des modifications créée lorsque l’indicateur de suppression (EBAN-LOEKZ) prend la valeur « L ». Type d’événement explicit
	Approbation réinitialisée	Indique que l’ensemble du flux d’approbation de la demande a été réinitialisé, souvent à la suite d’une modification importante. Cet événement est déduit lorsque le statut de libération est effacé après avoir été activé, ce qui oblige à reprendre le processus d’approbation depuis le début.
Pourquoi est-ce important ? La réinitialisation d’une approbation entraîne des reprises importantes et allonge fortement le temps de cycle. La repérer permet de mettre en évidence les inefficacités du processus et les conséquences des modifications de demandes sur le flux de travail. Où trouver ces données Événement déduit des journaux de modifications (CDHDR/CDPOS) de la table EBAN lorsque les champs de statut de libération, comme FRGZU, passent d’un état en attente ou approuvé à un état initial ou vide. Données à recueillir Événement déduit des journaux de modifications qui montrent que les champs de la stratégie de libération ont été effacés. Type d’événement inferred
	Demande d’achat bloquée	Correspond au blocage explicite d’un poste de demande d’achat, qui ne peut alors pas être converti en bon de commande. Le blocage est activé au moyen d’un indicateur spécifique sur le poste de la demande.
Pourquoi est-ce important ? Un blocage signale un problème potentiel ou une suspension temporaire de l’approvisionnement. Le suivi de ces événements aide à repérer les goulots d’étranglement où des demandes approuvées ne sont pas traitées immédiatement. Où trouver ces données Événement extrait d’une modification du champ « Indicateur de blocage » (EBAKZ) dans la table EBAN. La modification est enregistrée dans CDHDR et CDPOS. Données à recueillir Événement enregistré dans les tables de modifications lorsque le champ EBAN-EBAKZ est activé. Type d’événement explicit
	Demande d’achat clôturée	Correspond à la clôture définitive d’un poste de demande d’achat, qui ne devrait alors plus être traité. Ce statut est déduit lorsque le poste a été entièrement converti en bon de commande et satisfait, ou qu’il a été marqué manuellement comme clôturé.
Pourquoi est-ce important ? Cette activité marque la fin définitive des demandes d’achat terminées, même si elles n’ont pas été supprimées. Elle permet de calculer avec précision la durée du cycle de vie des demandes satisfaites. Où trouver ces données Événement déduit de l’indicateur « Clôturé » (EBAKZ avec la valeur « S » ou une autre valeur configurée) dans la table EBAN. Le système définit souvent ce statut automatiquement après la conversion complète en bon de commande et la réception des marchandises. Données à recueillir Événement déduit du changement du champ EBAN-EBAKZ vers une valeur indiquant la clôture. Type d’événement inferred
	Demande d’achat modifiée	Correspond à 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 modifications sont enregistrées dans les tables de journal des modifications de SAP, qui fournissent une piste d’audit détaillée.
Pourquoi est-ce important ? Le suivi des modifications permet de repérer les boucles de reprise et les problèmes de qualité des données. Des modifications fréquentes peuvent révéler des exigences initiales imprécises ou un manque de formation des utilisateurs, et entraîner des retards. Où trouver ces données Événement extrait des tables du journal des modifications CDHDR (en-tête) et CDPOS (poste), lorsque la classe d’objet est EINKBELEG et que l’ID d’objet correspond au numéro de la demande d’achat. Les modifications de champs spécifiques peuvent être analysées. Données à recueillir É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	Correspond à l’approbation explicite d’une étape de la stratégie de libération par un utilisateur autorisé. Cette action est enregistrée comme une modification du statut de libération de la demande et la rapproche de l’approbation finale.
Pourquoi est-ce important ? Le suivi des approbations individuelles est nécessaire pour mesurer la durée de chaque étape et analyser les résultats des différents approbateurs. Il permet aussi de vérifier le respect du flux d’approbation. Où trouver ces données Événement extrait des journaux de modifications (CDHDR/CDPOS) des champs de statut de libération de la table EBAN. L’action de l’approbateur dans la transaction ME54N ou une transaction similaire déclenche l’enregistrement de cette modification. Données à recueillir Entrée du journal des modifications créée lorsqu’un approbateur exécute une transaction de libération. Type d’événement explicit
	Étape d’approbation commencé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 libération. Cet événement est déduit lorsque le statut de la demande indique qu’elle attend un code de libération particulier.
Pourquoi est-ce important ? Cette activité permet d’analyser en détail chaque étape de la chaîne d’approbation. Elle aide à repérer les approbateurs ou les étapes qui entraînent les retards les plus longs. Où trouver ces données Événement déduit du suivi de la séquence des changements apportés aux champs de statut de libération dans la table EBAN. Chaque passage à un nouvel état d’attente marque le début d’une étape d’approbation. Données à recueillir Événement déduit des changements de statut indiquant qu’un nouveau code de libération est actif et en attente d’approbation. Type d’événement inferred
	Étape d’approbation rejetée	Un utilisateur autorisé a explicitement rejeté une étape de la stratégie de libération, renvoyant généralement la demande à son créateur pour modification. Cette action est enregistrée comme une modification du statut de libération de la demande.
Pourquoi est-ce important ? Les rejets sont une cause majeure de reprises et de retards. L’analyse de leur fréquence et de leurs motifs aide à repérer les incompréhensions des règles, les problèmes de qualité des données ou les étapes d’approbation inefficaces. Où trouver ces données Événement extrait des journaux de modifications (CDHDR/CDPOS) des champs de statut de libération de la table EBAN. Un rejet effectué dans la transaction ME54N ou une transaction similaire déclenche un changement de statut correspondant. Données à recueillir Entrée du journal des modifications créée lorsqu’un approbateur rejette une demande. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de SAP ECC

Étapes

Obtenez un 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. Vous aurez besoin d’identifiants spécifiques (nom d’utilisateur, mot de passe, hôte et port). Ce niveau d’accès n’est pas standard et doit être approuvé par les équipes SAP Basis et sécurité.
Repérez le schéma SAP : connectez-vous à la base de données à l’aide d’un client SQL standard, tel que DBeaver, Toad ou SQL Developer. Vous devrez identifier le schéma SAP qui contient les tables, généralement nommé SAPSR3 ou SAPR3.
Préparez la requête SQL : utilisez la requête SQL complète fournie dans ce document. Elle extrait 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éfinissez les paramètres de la requête : repérez les valeurs de remplacement dans la requête et remplacez-les par les valeurs correspondant à votre système et à vos besoins métier. Les principaux paramètres sont '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' et '{document_types}'.
Adaptez la syntaxe à votre base de données : la requête fournie utilise une syntaxe SQL courante. Certaines fonctions de création d’horodatage, comme TO_TIMESTAMP, ou de manipulation de chaînes peuvent toutefois nécessiter de légères adaptations selon votre base de données, par exemple Oracle, SQL Server, DB2 ou HANA.
Exécutez l’extraction : lancez la requête personnalisée dans votre client SQL. Pour les grands volumes de données, il est vivement recommandé de l’exécuter en dehors des heures de pointe afin de ne pas affecter les performances du système.
Vérifiez les premiers résultats : une fois la requête terminée, parcourez rapidement les résultats pour vérifier la présence des colonnes attendues (PurchaseRequisitionId, ActivityName, EventTime, etc.) et des lignes correspondant aux différentes activités.
Exportez au format CSV : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 pour éviter les problèmes liés aux caractères spéciaux.
Préparez l’importation : 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 le journal d’événements sous forme de tableau clair.
Importez le fichier dans ProcessMind : importez 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 nécessaire. 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 qui contient les tables SAP, par exemple SAPSR3. La requête doit être exécutée dans le contexte de ce schéma.
Période : pour maîtriser les performances et le volume de données, il est essentiel de filtrer sur une période précise. Nous recommandons de commencer par une période de 3 à 6 mois. Renseignez les paramètres '{start_date}' et '{end_date}' au format YYYYMMDD.
Filtres organisationnels : pour cibler l’analyse, filtrez les données par code société (BUKRS) et type de document de demande d’achat (BSART). Remplacez '{company_codes}' et '{document_types}' par des listes de valeurs 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é pour 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.
Performances : la requête relie les tables du journal des modifications (CDHDR, CDPOS), qui peuvent être très volumineuses. Sans filtres adaptés, son exécution peut être lente et mobiliser d’importantes ressources système. Utilisez toujours une période restreinte et d’autres filtres pertinents.

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

Configurez 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
Installez le SDK SAP RFC : Téléchargez le SDK SAP NetWeaver RFC depuis le portail d’assistance SAP. Extrayez les fichiers et placez les bibliothèques, par exemple sapnwrfc.dll sous Windows ou libsapnwrfc.so sous Linux, dans un répertoire accessible depuis le chemin système ou votre script Python.
Configurez la connexion SAP : Ouvrez le script Python fourni. Repérez la section des paramètres de connexion SAP et remplacez les valeurs fictives (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éfinissez les paramètres d’extraction : Dans le script, renseignez les variables date_from et date_to pour définir la période d’extraction souhaitée. Il est recommandé de commencer par une période plus courte, par exemple un mois, afin de tester l’extraction.
Exécutez le script Python : Lancez 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 chaque table requise (EBAN, EKKO, EKPO, CDHDR, CDPOS) et télécharge les données.
Récupérez les données : Le script extrait les données brutes relatives aux demandes d’achat, aux commandes d’achat et aux documents de modification. Il applique des critères de filtrage, comme les plages de dates et les classes d’objets, afin de limiter le volume transféré.
Transformez 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 créer des entrées distinctes dans le journal d’événements pour chacune des 13 activités requises, telles que « Demande d’achat créée », « Étape d’approbation approuvée » et « Commande d’achat créée ».
Générez le journal d’événements : Le script regroupe les événements générés à partir de chaque table dans un DataFrame unique. Il calcule les horodatages des événements, associe les noms d’utilisateur et structure les données selon le format requis pour l’ID de cas, l’activité et l’horodatage.
Associez les attributs : Les principaux attributs, tels que PurchaseRequisitionId, ActivityName, EventTime, Utilisateur et TotalRequisitionValue, sont associés aux colonnes correspondantes du DataFrame final.
Exportez 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 prêt à être importé directement dans ProcessMind.
Vérifiez et importez le fichier : Ouvrez le fichier CSV généré pour vérifier que les données sont complètes et exactes. Une fois cette vérification effectuée, vous pouvez importer le fichier dans votre projet ProcessMind.

Configuration

Connexion SAP : le script nécessite les informations de 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 être autorisé à effectuer des appels RFC et à consulter les tables EBAN, EKPO, EKKO, CDHDR et CDPOS.
Période : l’extraction est définie par les dates de début et de fin indiquées 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 : dans la mesure du possible, les appels RFC appliquent des filtres. Par exemple, les demandes sont filtrées par date de création (EBAN-ERDAT) et les documents de modification par date (CDHDR-UDATE) et classe d’objet (CDHDR-OBJECTCLAS = 'BANF').
Bibliothèques Python : le script utilise pyrfc pour se connecter à SAP et pandas pour manipuler les données. Vérifiez que ces bibliothèques sont installées dans votre environnement Python.
Performances : l’extraction avec RFC_READ_TABLE peut être lente pour les très grands volumes de données, 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 documents de demande d’achat. Pour restreindre le périmètre, vous pouvez ajouter un filtre après l’extraction dans le DataFrame pandas, à partir de la colonne BSART de la table EBAN.

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 vos données en vue du Process Mining et mieux comprendre votre processus de demande d’achat, de l’achat au paiement. Commencez dès aujourd’hui à optimiser vos processus.

Retour au guide d’amélioration

Télécharger le modèle

Améliorez l’efficacité des demandes d’achat, démarrez votre essai dès maintenant

Repérez et résolvez les goulots d’étranglement des demandes d’achat, et réduisez le temps de cycle de 30 % ou plus.

Démarrez l’essai gratuit

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

Votre modèle de données pour les demandes d’achat, de l’achat au paiement

Votre modèle de données pour les demandes d’achat, de l’achat au paiement

Attributs des demandes d’achat, de l’achat au paiement

Activités des demandes d’achat, de l’achat au paiement

Guides d’extraction

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

Étapes

Configuration

Exemple de requête sql

Script Python utilisant SAP RFC pour extraire les tables

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Améliorez l’efficacité des demandes d’achat, démarrez votre essai dès maintenant

Votre modèle de données pour les demandes d’achat, de l’achat au paiement

Votre modèle de données pour les demandes d’achat, de l’achat au paiement

Attributs des demandes d’achat, de l’achat au paiement

Activités des demandes d’achat, de l’achat au paiement

Guides d’extraction

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

Étapes

Configuration

Exemple de requête sql

Script Python utilisant SAP RFC pour extraire les tables

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Améliorez l’efficacité des demandes d’achat, démarrez votre essai dès maintenant

Prêt à commencer ?