> Amélioration Continue des Processusus > Achats au paiement : demande d'achat > SAP ECC > Template de données

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

SAP ECC

Achats au paiement : attributs de demande d'achat (19) Achats au paiement – Activités de demande d'achat (13) Guides d'extraction (2)

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Ce template provides a comprehensive guide to collecting les essential data needed for analyzing votre processus Achats au paiement (P2P) Demande d'achat. Il outlines les crucial data fields to gather, les key activities to track, et practical guidance for extracting this information from votre source system. Utilisez cette ressource pour préparer vos données à un projet de Process Mining efficace.

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

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Achats au paiement : attributs de demande d'achat

Ce sont les recommended data fields to include dans votre journal d'événements pour comprehensive analysis de votre processus Achats au paiement (P2P) Demande d'achat.

5 Obligatoire 5 Recommandé 9 Facultatif

	Nom	Descriptionn
	Heure de l'événement EventTime	L'horodatage indiquant quand l'activité a eu lieu.
Descriptionn L'horodatage de l'événement enregistre la date et l'heure précises auxquelles une activité spécifique a eu lieu. Cet horodatage est indispensable pour toutes les analyses temporelles en Process Mining, y compris le calcul des temps de cycle, l'identification des points de blocage et la compréhension de la performance du processus. Dans le contexte des demandes d'achat, cet attribut permet le calcul d'indicateurs clés de performance (KPI) tels que le « Temps moyen d'approbation des demandes d'achat » et le « Temps de création de la commande d'achat ». Il alimente les dashboards qui visualisent les durées, telles que l'analyse du temps de cycle d'approbation des demandes, en fournissant les données brutes nécessaires pour mesurer le temps entre deux points quelconques du processus. Pourquoi est-ce important ? : Ce horodatage est essential pour calculating all durations, analyzing process performance, et discovering time-related points de blocage. Source des données : Trouvé dans la table d'en-tête du document de modification CDHDR (champs UDATE et UTIME). Exemples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	ID de la demande d'achat PurchaseRequisitionId	L'identifiant unique du document de demande d'achat.
Descriptionn Le Purchase Requisition ID est la clé primaire that uniquely identifies chaque request for goods or services within SAP ECC. Il sert de central case identifier, linking all activities and changes related to a specific requisition from its creation to its final resolution, such as conversion to a purchase order or closure. Dans le Process Mining, this ID est essential for reconstructing the complet lifecycle de chaque requisition. En tracking this identifier, les analysts peuvent visualiser le complete flux de processus, measure durations between milestones, et analyze variations in how different requisitions are handled. Il allows for a cohesive view of the entire requisition journey. Pourquoi est-ce important ? : Ceci est le core identifier that connects all related process events into a single case, making complet process analysis possible. Source des données : Trouvé dans la table EBAN, champ BANFN. Exemples 100234567810023456791002345680
	Nom de l'activité ActivityName	Le nom de l'activité commerciale qui s'est produite à un moment précis.
Descriptionn Cet attribut décrit une étape ou un événement spécifique du cycle de vie de la demande d'achat, tel que 'Demande créée', 'Approbation soumise' ou 'Commande créée'. Ces activités sont généralement dérivées des changements de statut, des journaux de workflow ou des documents de modification dans SAP. Analyzing the sequence et frequency of activities est le foundation de Process Mining. Il allows for the discovery des actual flux de processuss, including common paths, deviations, et points de blocage. This est impératif for building dashboards like the End-to-End Requisition Process Map et calculating KPIs related to reprises et Conformité. Pourquoi est-ce important ? : Il définit les étapes du processus, pour visualiser des cartes de processus et l'analyse des variations de flux de processus. Source des données : Dérivé des tables de documents de modification CDHDR et CDPOS, des journaux de flux de travail ou des champs de statut comme EBAN-STATU. Exemples Demande d'achat crééeÉtape d'approbation approuvéeDemande rejetéeCommande d'achat créée
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation des données ou de l'extraction du système source.
Descriptionn Cet attribut indicates when le dataset was last updated. It's a static horodatage applied to the entire dataset during each data load, serving as a reference point pour la freshness de l'analysis. Pour tout Process Mining tableau de bord ou analysis, connaître la récence des données est primordial pour prendre des décisions éclairées. Cet attribut garantit que toutes les parties prenantes connaissent la période couverte par les données, évitant ainsi des conclusions basées sur des informations obsolètes. Pourquoi est-ce important ? : Informe les utilisateurs de la la réactualisation des données, ce qui est impératif pour la pertinence et la précision de l'analyse des processus. Source des données : Ceci est une static value representing l'horodatage de les données extraction, 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 d'où les données ont été extraites.
Descriptionn Cet attribut specifies l'origin du process data, for example, 'SAP ECC Production' ou 'S4HANA QA'. Il est typically a static value added during le data extraction process pour provide context, especially dans les environments with multiple source systems. Dans le process analysis, this helps differentiate data from various sources, ensuring that les analyses sont not skewed by mixing data from production, testing, ou development environments. Il est une fundamental piece de metadata pour les données governance et la traceability. Pourquoi est-ce important ? : Fournit le essential context pour les données origin, assurant la traçabilité et enabling multi-system analysis. Source des données : Ceci est une static value typically added during le data extraction, transformation, et loading (ETL) process. Exemples SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Département Department	Le service du demandeur ou le centre de coûts associé à la demande d'achat.
Descriptionn Cet attribut represents the business unit ou department that initiated the purchase requisition. This est often derived from the requester's user profile ou le cost center assigned to the requisition line item. L'analyse du processus par département est fondamentale pour comprendre les variations de performance dans l'organisation. Il est la primary dimension pour le 'Requisition Approval Cycle Time' tableau de bord et le 'Departmental Approval Time Variance' KPI, helping to pinpoint which departments have efficient processes et which may require improvement ou additional resources. Pourquoi est-ce important ? : Permet la comparaison des performances entre les unités commerciales, mettant en évidence les points de blocage départementaux et les incohérences de processus. Source des données : Souvent dérivé en liant le Requester (EBAN-AFNAM) aux données de base utilisateur (SU01) ou en utilisant le Centre de Coûts (EBKN-KOSTL) associé à l'imputation de la demande. Exemples FinanceOpérations ITMarketingFabrication
	Nom d'utilisateur User	L'ID de l'utilisateur ayant effectué l'activité.
Descriptionn Cet attribut identifie l'utilisateur spécifique responsable d'un événement, comme la création d'une demande, une approbation ou la modification d'un document. Dans SAP, this est often captured as a ID utilisateur. Analyzing by user helps identify training needs, user-specific performance, et potential sources de données entry errors. Il est essential pour les dashboards like 'Requisition Creation Throughput by Requester' et pour understanding workload distribution et Conformité with segregation of duties policies. Pourquoi est-ce important ? : Attribue les activités à des individus spécifiques, permettant l'analyse de la performance des utilisateurs, de la charge de travail, de la conformité et des besoins en formation. Source des données : Trouvé dans la table d'en-tête du document de modification CDHDR (champ USERNAME) pour les modifications, et EBAN (champ ERNAM) pour le créateur. Exemples SMITHJR.DOEUSER123
	Statut de la demande RequisitionStatus	Le statut actuel de traitement de la demande d'achat.
Descriptionn Cet attribut indicates the overall status de la requisition at a given point in time, such as 'In Release', 'Approved', 'Rejected', ou 'Closed'. This est often represented by un status code dans SAP. Tracking le status est essential pour understanding the outcome de requisitions. Il directly supports le 'Requisition Outcome and Rejection Rates' tableau de bord et les KPIs like 'Requisition Rejection Rate' et 'Requisition Withdrawal Rate'. Analyzing how requisitions transition between statuses helps identify process inefficiencies et failure points. Pourquoi est-ce important ? : Il définit le résultat d'une demande d'achat, ce qui est impératif pour analyser les taux de succès, les raisons de rejet et les points de fin de processus. Source des données : Le processing status est found in table EBAN, field STATU. The release status est in EBAN-FRGZU. Exemples N (Non modifié)B (Commande d'achat créée)A (Demande de prix créée)K (Fermée)
	Total Requisition Value TotalRequisitionValue	La total monetary value de all items in the purchase requisition.
Descriptionn Cet attribut represents the total financial amount de la purchase requisition. La value est often a key factor in determining le required approval workflow, with higher-value requisitions typically requiring plus extensive scrutiny et plus approval steps. Analyzing by value est critical pour understanding how financial impact affects process behavior. Il can reveal if high-value requisitions take longer to approve, sont rejected more often, ou follow different process paths. This est also a fundamental metric for assessing le financial débit du achats process. Pourquoi est-ce important ? : Aide à corréler le comportement du processus avec l'impact financier, ce qui est indispensable pour l'analyse des risques et la compréhension de la complexité des approbations. Source des données : Sum of the value from all line items. Line item value is in table EBAN, field GSWER. The currency est in EBAN-WAERS. Exemples 1500.00250.50125000.00
	Type de document RequisitionDocumentType	Une classification qui détermine le type et les caractéristiques de la demande d'achat.
Descriptionn Le Document Type dans SAP controls various aspects d'une purchase requisition, including le number range, field selection, et le overall achats process it follows. Examples include 'Standard PR', 'Stock Transfer', ou 'Service PR'. Cet attribut est une powerful dimension pour l'analysis parce que different document types often have distinct flux de processuss et approval requirements. It allows analysts to segment the data pour comparer la performance de different requisition processes, which est key pour understanding Conformité et identifying opportunities for process standardization ou specialization. Pourquoi est-ce important ? : Permet la segmentation des demandes d'achat en différentes catégories de processus, facilitant ainsi une analyse plus précise et pertinente. Source des données : Trouvé dans la table EBAN, champ BSART. Exemples NBUBRV
	Est un reprises IsRework	Un indicateur booléen signalant si la demande d'achat a subi un cycle de reprises, comme une modification après soumission.
Descriptionn Ceci est un derived attribut that flags activities ou cases involving reprises. For example, any 'Requisition Amended' activity that occurs after 'Approval Submitted' would be considered reprises. Il can also be triggered by rejection events that send le process back to an earlier stage. Ce flag est essential pour le 'Requisition Amendment and Rework Analysis' tableau de bord. Il allows for easy filtering et quantification du reprises, helping to measure its impact on overall temps de cycles et identify les root causes de process inefficiencies. High rates de reprises often point to issues with data quality ou unclear requirements. Pourquoi est-ce important ? : Aide à quantifier la fréquence et l'impact du reprises, facilitant l'identification et l'analyse des inefficacités et des boucles de processus. Source des données : Dérivé du journal d'événements en identifiant des séquences spécifiques d'activités, telles qu'une « demande d'achat modifiée » survenant après une activité d'approbation. Exemples truefaux
	Groupe d'Achats PurchasingGroup	Le group of buyers responsible for procuring the requested items.
Descriptionn Le Purchasing Group est une organizational unit responsible for specific achats activities. Il represents the team of buyers who will handle the requisition once it est approved. Cet attribut est useful for analyzing the workload et performance de different buying teams. Il peut help identify if certain purchasing groups sont des points de blocage dans la conversion des requisitions en purchase orders, ou if they handle specific types de requisitions plus efficiently than others. Il provides a key dimension for resource et performance management within the achats function. Pourquoi est-ce important ? : Attribue la responsabilité de l'approvisionnement, permettant l'analyse de la charge de travail et la comparaison des performances entre les différentes équipes d'achat. Source des données : Trouvé dans la table EBAN, champ EKGRP. Exemples 001002P01
	Groupe de matériaux MaterialGroup	Le group ou category to which the requested material or service belongs.
Descriptionn Le Material Group est une classification utilisée pour group together materials ou services with similar characteristics. This allows for category-based analysis de achats activities. Analyzing by material group helps in strategic sourcing et spend analysis. Dans le Process Mining, il peut reveal if requisitions pour certain categories, like 'Matériel informatique' ou 'Professional Services', follow different process paths ou experience longer approval times. Cet insight est valuable pour le 'Requisition Data Quality Report' et pour understanding process variations based on what est being purchased. Pourquoi est-ce important ? : Permet l'analyse des dépenses et des processus par catégorie d'approvisionnement, supportant l'approvisionnement stratégique et l'identification des points de blocage spécifiques à chaque catégorie. Source des données : Trouvé dans la table EBAN, champ MATKL. Exemples 00101L001IT-SFTWR
	ID du bon de commande PurchaseOrderId	L'ID du purchase order created from the requisition.
Descriptionn Cet attribut links a purchase requisition to the subsequent purchase order that was created to fulfill it. A single requisition can sometimes lead to multiple purchase orders. Ce link est impératif pour analyzing le handoff between the requisition et purchasing processes. Il est required to calculate le 'Time to PO Creation from Requisition' KPI et to support le 'Approved Requisition to PO Creation Delay' tableau de bord. Understanding this connection est key pour measuring l'efficiency du entire de l'achat au paiement cycle. Pourquoi est-ce important ? : Connecte le processus de demande d'achat au processus d'approvisionnement en aval, permettant l'analyse des retards de transfert. Source des données : Le purchase order number est stored in the EBAN table, field EBELN, after it has been created. Exemples 450001712345000171244500017125
	ID fournisseur VendorId	Le unique identifier pour le suggested ou fixed vendor.
Descriptionn Cet attribut contains l'ID d'un preferred ou contractually fixed vendor pour l'item being requested. It may be pre-populated ou suggested by the requester. Analyzing requisitions by vendor can help assess the impact de pre-selecting suppliers sur le achats process. For example, il can show whether requisitions with a specified vendor sont approved faster ou if certain vendors are associated with higher rates of rejection. Il provides a view into early-stage supplier engagement. Pourquoi est-ce important ? : Fournit des insights sur les preferred supplier relationships et leur impact sur la requisition processing speed et les outcomes. Source des données : Trouvé dans la table EBAN, champ LIFNR (Fournisseur fixe). Exemples 100030025V9876
	Motif de refus RejectionReason	La reason provided when a requisition or an approval step est rejected.
Descriptionn Cet attribut captures the justification pour rejecting a purchase requisition. This information est typically entered as free text ou selected from a predefined list of codes by the approver during the rejection activity. Analyzing rejection reasons est impératif for process improvement. It provides direct, actionable feedback on why requisitions fail, which could be due to policy violations, incorrect data, ou unavailable budget. This data est key pour le 'Requisition Outcome and Rejection Rates' tableau de bord et helps identify root causes de process inefficiencies. Pourquoi est-ce important ? : Fournit des insights directs sur les raisons du rejet des demandes, permettant des processus improvements ciblées et une user training. Source des données : Ces data sont typically stored in workflow logs ou long text associated with the rejection event. There est no standard field in EBAN. Exemples Centre de coûts incorrectBudget dépasséDemande en doubleNon conforme à la politique
	Nom du Demandeur RequesterName	Le name de la person who requested the goods or services.
Descriptionn Cet attribut identifies l'individual who initiated the purchase requisition. This est la person who has the business need for the requested items. Tracking le requester allows for analysis de requisition patterns by individual ou group. Le 'Requisition Creation Throughput by Requester' tableau de bord relies on this attribut pour identify power users, users who may need additional training, ou departments with high achats activity. Il provides a human-centric view du process start point. Pourquoi est-ce important ? : Identifie le propriétaire du processus, permettant l'analyse des modèles de création de demandes d'achat et aidant à cibler la formation des utilisateurs. Source des données : Trouvé dans la table EBAN, champ AFNAM. Exemples Alice WilliamsBob JohnsonCharlie Brown
	Priorité Priority	Le urgency level assigned to the purchase requisition.
Descriptionn Cet attribut indicates the priority de la requisition, often classifying it as 'Urgent', 'High', ou 'Normal'. This flag est used to signal aux approvers et buyers that a request requires expedited handling. Cet attribut est essential pour le 'Urgent Requisition Processing Performance' tableau de bord et le 'Urgency Flag Effectiveness' KPI. L'Analysis focuses on whether requisitions marked as urgent are actually processed faster than standard ones, helping to validate l'effectiveness du prioritization system et ensure that business-critical needs are met promptly. Pourquoi est-ce important ? : Permet d'analyser si les demandes urgentes sont traitées plus rapidement, validant ainsi l'efficacité des mécanismes de priorisation. Source des données : Ceci est not a standard field in EBAN. Il est often implemented as a custom field ou inferred from the Requirement Tracking Number (EBAN-BEDNR) ou un specific document type. Exemples 123
	Usine Plant	L'company location ou plant pour which the goods or services are requested.
Descriptionn Le Plant est une organizational unit within a company, representing a physical location such as a factory, warehouse, ou office. The requisition specifies the plant where the requested items are needed. Analyzing by plant allows for geographical ou site-specific views du requisition process. It can highlight performance differences entre les locations, which may be due to different local procedures, staffing levels, ou business needs. This est une common dimension pour les regional performance dashboards. Pourquoi est-ce important ? : Fournit un contexte géographique ou location-based pour l'analyse, aidant à identifier les regional process variations et les performance differences. Source des données : Trouvé dans la table EBAN, champ WERKS. Exemples 10002100DE01

Obligatoire Recommandé Facultatif

Achats au paiement – Activités de demande d'achat

Ce sont les key process steps et milestones to capture dans votre journal d'événements pour accurate discovery et analysis de votre requisition workflow.

6 Recommandé 7 Facultatif

	Activité	Descriptionn
	Approbation soumise	Cette activity signifies that the requisition has entered le formal approval workflow. It est typically inferred when the requisition's status changes to require un initial release or approval action based on the configured release strategy.
Pourquoi est-ce important ? : Ceci marks the beginning de l'approval temps de cycle, un critical KPI pour measuring process efficiency. Understanding this point helps isolate delays between creation et le start de formal approvals. Source des données : Inférencié à partir du premier changement de statut lié à la stratégie de libération dans la table EBAN (par exemple, le champ FRGZU passe de l'é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. Capture Inférencié à partir de la première entrée du journal de modifications indiquant l'activation d'une stratégie de libération. Type d'événement inferred
	Commande d'achat créée	Cette activity marks le successful conversion d'une approved purchase requisition into a purchase order document. L'event est inferred for the requisition by finding a corresponding purchase order item that references it.
Pourquoi est-ce important ? : En tant que résultat principal réussi, cette activité conclut le processus de demande d'achat et initie la phase d'approvisionnement. Le temps entre « Demande d'achat approuvée » et cet événement est un indicateur clé pour mesurer l'efficacité du transfert. Source des données : Inférencié en trouvant un enregistrement dans la table EKPO (Poste de commande d'achat) où les champs BANFN et BNFPO correspondent au numéro et à l'article de la demande d'achat de la table EBAN. La date de création de la commande d'achat (EKKO.AEDAT) fournit l'horodatage. Capture Inférencié en liant les tables EBAN à EKPO et en utilisant la date de création de la commande d'achat de EKKO. Type d'événement inferred
	Demande approuvée	Cette milestone activity signifies that the purchase requisition has successfully passed all required approval steps. Il est inferred when le final release code est applied et le overall release indicator (FRGZU) dans la EBAN table est set to an approved state.
Pourquoi est-ce important ? : Ceci est un critical milestone that marks the end de l'approval cycle et le start du achats phase. It's essential for calculating le total approval time KPI et measuring handoff delays to PO creation. Source des données : Inférencié à partir de l'horodatage de l'entrée du journal de modifications dans CDPOS pour la table EBAN, champ FRGZU, lorsqu'il change pour la valeur représentant l'approbation finale. Capture Inférencié à partir du champ de l'indicateur de libération finale dans EBAN atteignant un statut « approuvé » terminal. Type d'événement inferred
	Demande d'achat créée	Cette activity marks l'initial creation et saving d'une purchase requisition by a user. L'event est captured explicitly when a new record est generated dans la EBAN table, with the creation date et time recorded.
Pourquoi est-ce important ? : En tant que point de départ du processus, cette activité est indispensablele pour calculer la durée totale du cycle de vie de la demande d'achat et analyser le débit de création. Elle aide à identifier qui crée les demandes et quand. Source des données : Cet event est captured from the EBAN table using the creation date (ERDAT) et creation time (UZEIT) fields pour un given Purchase Requisition ID (BANFN). Capture Horodatage from EBAN table fields ERDAT et UZEIT upon initial record save. Type d'événement explicit
	Demande rejetée	Ceci est une terminal activity where the purchase requisition est definitively rejected et cannot proceed further. Il est inferred when le release indicator dans la EBAN table est set to a final rejected state by an approver.
Pourquoi est-ce important ? : Cette activity est un key process endpoint et essentiel pour calculating le Requisition Rejection Rate KPI. Analyzing these cases helps understand reasons for achats failure et waste. Source des données : Inférencié à partir de l'horodatage de l'entrée du journal de modifications dans CDPOS pour la table EBAN, champ FRGZU, lorsqu'il change pour la valeur représentant le rejet final. Capture Inférencié à partir du champ de l'indicateur de libération finale dans EBAN atteignant un statut « rejeté » terminal. Type d'événement inferred
	Demande retirée	Ceci est une terminal activity where the creator ou un authorized user cancels le requisition item by setting a deletion flag. This action est explicitly recorded et indicates the business need est no longer valid ou was created in error.
Pourquoi est-ce important ? : Ceci est un key failure endpoint pour le processus, essential for calculating le withdrawal rate. High rates may indicate long approval times forcing users to abandon requests, ou systemic issues with demand planning. Source des données : Cet explicit action est captured when le 'Deletion Indicator' (LOEKZ) field dans la EBAN table est set pour le requisition item. Le change est logged in CDHDR et CDPOS. Capture Entrée de journal de modifications lorsque l'indicateur de suppression (EBAN-LOEKZ) est défini sur 'L'. Type d'événement explicit
	Demande clôturée	Représente le final closure d'un requisition item, indiquant que no further processing est expected. This status est inferred when the item has been fully converted to a PO and fulfilled, or manually flagged as closed.
Pourquoi est-ce important ? : Ceci provides a definitive end point for requisitions that sont completed but not necessarily deleted. Il ensures accurate lifecycle duration calculations for successfully fulfilled requests. Source des données : Inférencié à partir de l'indicateur « Fermé » (EBAKZ avec la valeur « S » ou une autre valeur configurée) dans la table EBAN. Ce statut est souvent défini automatiquement par le système lors de la conversion complète de la commande d'achat et de la réception des marchandises. Capture Inférencié à partir du changement de statut dans le champ EBAN-EBAKZ vers une valeur « fermée ». Type d'événement inferred
	Demande modifiée	Représente any modification made to a purchase requisition after its initial creation, such as changing quantity, price, or material. These changes are recorded in SAP's change log tables, providing a detailed audit trail de modifications.
Pourquoi est-ce important ? : Tracking amendments est impératif pour identifying reprises loops et data quality issues. A high frequency of amendments can indicate unclear initial requirements ou user training gaps, leading to process delays. Source des données : Capturé à partir des tables de journal de modifications CDHDR (en-tête) et CDPOS (poste) où la classe d'objet est EINKBELEG et l'ID d'objet est le numéro de demande d'achat. Des modifications de champs spécifiques peuvent être analysées. Capture É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 le explicit action d'un authorized user approving a single step in the release strategy. This action is recorded as a change to the requisition's release status, moving it closer to final approval.
Pourquoi est-ce important ? : Tracking individual approvals est necessary to measure the duration de chaque step et analyze the performance de different approvers. Il est fundamental for understanding workflow Conformité. Source des données : Capturé à partir des journaux de modifications (CDHDR/CDPOS) sur les champs de statut de libération de la table EBAN. L'action de l'approbateur via la transaction ME54N ou un code T similaire déclenche cette modification enregistrée. Capture Entrée de journal de modifications créée lorsqu'un approbateur exécute une transaction de libération. Type d'événement explicit
	Étape d'approbation démarrée	Indique que la demande d'achat est maintenant en attente d'une action de la part d'un approbateur ou d'un groupe d'approbation spécifique, tel que défini dans 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 activity allows for detailed analysis de chaque individual step dans la approval chain. It helps pinpoint which approvers ou stages sont causing the longest delays dans le process. Source des données : Inférencié en suivant la séquence des modifications apportées aux champs de statut de libération dans la table EBAN. Chaque changement vers un nouvel état en attente signifie le début d'une nouvelle étape d'approbation. Capture Inférencié à partir des changements de statut indiquant qu'un nouveau code de libération est maintenant actif et en attente d'approbation. Type d'événement inferred
	Étape d'approbation rejetée	Un utilisateur autorisé a explicitement rejeté une étape unique de la stratégie de libération, renvoyant généralement la demande d'achat à 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 rejections sont une primary cause de process reprises et delays. Analyzing their frequency and cause helps identify policy misunderstandings, data quality problems, ou inefficient approval steps. Source des données : Capturé à partir des journaux de modifications (CDHDR/CDPOS) sur les champs de statut de libération dans la table EBAN. Une action de rejet via la transaction ME54N ou similaire déclenchera un changement de statut correspondant. Capture Entrée de journal de modifications créée lorsqu'un approbateur exécute une action de rejet. Type d'événement explicit
	Réinitialisation de l'approbation	Indique que l'ensemble du flux de travail d'approbation pour la demande d'achat a été réinitialisé, souvent en raison d'une modification significative. Cela est déduit lorsque le statut de libération est effacé après avoir été précédemment actif, forçant le processus d'approbation à redémarrer depuis le début.
Pourquoi est-ce important ? : Les réinitialisations d'approbation sont des événements de reprises importants qui impactent fortement le temps de cycle. Les identifier met en évidence les inefficacités du processus et l'effet en aval des modifications de demande d'achat sur le flux de travail. Source des données : Inférencié à partir des journaux de modifications (CDHDR/CDPOS) pour la table EBAN où les champs de statut de libération (comme FRGZU) sont modifiés d'un état en attente ou approuvé vers un état initial ou vide. Capture Inférencié à partir des journaux de modifications montrant que les champs de la stratégie de libération sont effacés. Type d'événement inferred
	Requisition Blocked	Représente un explicit action pour bloquer un purchase requisition item, empêchant qu'il soit converted into a purchase order. Le block est set via un specific indicator sur le requisition item.
Pourquoi est-ce important ? : Le blocage indique un problème potentiel ou une suspension temporaire de l'approvisionnement. Le suivi de ces événements aide à identifier les points de blocage où les demandes d'achat sont approuvées mais non traitées immédiatement. Source des données : Capturé à partir d'une modification du champ « Indicateur de blocage » (EBAKZ) dans la table EBAN. La modification est enregistrée dans CDHDR et CDPOS. Capture Événement enregistré dans les tables de modifications lorsque le champ EBAN-EBAKZ est défini. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

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

Étapes

Accorder l'accès à la base de données : Avant de commencer, assurez-vous d'avoir un accès en lecture seule à la base de données SAP ECC sous-jacente. Cela nécessite des identifiants spécifiques (nom d'utilisateur, mot de passe, hôte, port) et constitue un niveau d'accès non standard qui doit être approuvé par vos é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 correct où les tables sont stockées, qui est généralement nommé SAPSR3 ou SAPR3.
Préparer la requête SQL : Utilisez la requête SQL complète fournie dans ce document. Cette requête est conçue pour extraire toutes les activités et attributs requis en joignant les données de base et les tables de journal de modifications.
Définir les paramètres de la requête : Localisez les valeurs de remplacement dans la requête. Vous devez les remplacer par les exigences spécifiques de votre système et de votre entreprise. Les principaux espaces réservés incluent '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' et '{document_types}'.
Adapter la syntaxe spécifique à la base de données : La requête fournie utilise une syntaxe SQL commune. Cependant, les fonctions de création d'horodatages, comme TO_TIMESTAMP, ou de manipulation de chaînes de caractères peuvent nécessiter des ajustements mineurs en fonction de votre système de base de données spécifique, 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 grands ensembles de données, il est fortement recommandé de l'exécuter pendant les heures creuses afin d'éviter d'impacter les performances du système.
Examiner les résultats préliminaires : Une fois la requête terminée, parcourez rapidement la sortie pour vous assurer qu'elle contient les colonnes attendues (PurchaseRequisitionId, (ActivityName), (EventTime), etc.) et que des lignes sont retournées pour diverses activités.
Exporter en CSV : Exportez l'ensemble du jeu de résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes avec les caractères spéciaux.
Préparer le téléchargement : Confirmez que les en-têtes de colonne CSV correspondent exactement aux alias définis dans la requête SQL. Le fichier doit être une représentation tabulaire propre du journal d'événements.
Télécharger vers ProcessMind : Téléchargez le fichier CSV final vers votre projet ProcessMind pour analyse et visualisation.

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 d'utilisateur appropriés.
Schéma SAP : Le nom du schéma contenant les tables SAP doit être connu, par exemple, SAPSR3. La requête doit être exécutée dans le contexte de ce schéma.
Plage de dates : Pour gérer les performances et le volume de données, il est impératif de filtrer par une plage de dates spécifique. Nous recommandons de commencer par une période de 3 à 6 mois. Définissez les espaces réservés '{start_date}' et '{end_date}' au format YYYYMMDD.
Filtres organisationnels : Pour une analyse plus ciblée, filtrez les données par Code Société (BUKRS) et Type de Document de Demande d'Achat (BSART). Remplacez les espaces réservés '{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 directs à la base de données. Ce n'est pas une activité utilisateur final standard.
Considérations sur les performances : La requête effectue des jointures sur les tables de journal de modifications (CDHDR, CDPOS), qui peuvent être très volumineuses. Sans un filtrage approprié, la requête peut être lente et consommer des ressources système significatives. Exécutez 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 : Assurez-vous d'avoir Python 3.6 ou plus récent installé. Créez un dossier de projet et configurez un environnement virtuel pour gérer les dépendances. Installez les bibliothèques nécessaires à l'aide de pip : pip install pyrfc pandas numpy
SDK SAP RFC : Téléchargez le SDK SAP NetWeaver RFC depuis le portail de support SAP. Extrayez le contenu et placez les fichiers de bibliothèque (par exemple, sapnwrfc.dll sur Windows, libsapnwrfc.so sur Linux) dans un répertoire accessible par le chemin de votre système ou votre script Python.
Configurer la connexion SAP : Ouvrez le script Python fourni. Localisez la section des paramètres de connexion SAP et remplacez les valeurs de remplacement (ashost, sysnr, client, user, passwd) par les identifiants réels de votre système SAP. Assurez-vous que l'utilisateur dispose des autorisations requises pour l'exécution RFC et l'accès aux tables.
Définir les paramètres d'extraction : Dans le script, définissez les variables date_from et date_to pour définir la plage de temps 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 en utilisant la commande python your_script_name.py. Le script se connectera à SAP via RFC, appellera RFC_READ_TABLE pour chaque table requise (EBAN, EKKO, EKPO, CDHDR, CDPOS) et téléchargera les données.
Récupération des données : Le script récupère les données brutes des demandes d'achat, des commandes d'achat et des documents de modification. Il utilise des critères de filtrage, tels que des plages de dates et des classes d'objets, pour limiter la quantité de données transférées.
Transformation locale des données : Une fois les données téléchargées, le script utilise la bibliothèque pandas pour effectuer toutes les transformations localement. Il traite les données brutes des tables pour générer des entrées de journal d'événements distinctes 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érer le journal d'événements : Le script combine les événements générés à partir de chaque table dans un seul DataFrame unifié. Il calcule les horodatages des événements, mappe les noms d'utilisateurs et structure les données dans le format requis d'ID de cas, d'activité et d'horodatage.
Mappage des attributs : Les attributs clés comme PurchaseRequisitionId, (ActivityName), (EventTime), User et TotalRequisitionValue sont associés à leurs colonnes respectives dans le DataFrame final.
Exporter en CSV : Le script enregistre le journal d'événements final sous forme de fichier CSV nommé event_log_pr.csv dans le même répertoire. Ce fichier est formaté pour un téléchargement direct dans ProcessMind.
Examiner et télécharger : Ouvrez le fichier CSV généré pour examiner les données afin de vérifier leur exhaustivité et leur exactitude. Une fois validé, vous pouvez procéder au téléchargement du fichier vers votre projet ProcessMind.

Configuration

Connexion SAP : Le script nécessite des détails de connexion RFC directs au système SAP ECC, y compris le serveur d'applications, le numéro de système, le client, l'utilisateur et le mot de passe. L'utilisateur spécifié doit disposer des autorisations pour les appels RFC et de l'accès en affichage aux tables EBAN, EKPO, EKKO, CDHDR et CDPOS.
Plage de dates : L'extraction est régie par des paramètres de date de début et de fin au sein du script. Pour les exécutions initiales et pour gérer les performances, il est recommandé d'extraire une plage de données de 3 à 6 mois.
Filtres de table : Le filtrage est appliqué danss appels RFC lorsque cela est possible. Par exemple, les demandes d'achat sont filtrées par date de création (EBAN-ERDAT), et les documents de modification sont filtrés par date (CDHDR-UDATE) et classe d'objet (CDHDR-OBJECTCLAS = 'BANF').
Bibliothèques Python : Le script s'appuie sur pyrfc pour la connectivité SAP et pandas pour la manipulation des données. Assurez-vous que ces bibliothèques sont installées dans votre environnement Python.
Performance : L'extraction de données via RFC_READ_TABLE peut être lente pour de très grands ensembles de données, car les données sont extraites séquentiellement table par table. Il est conseillé d'exécuter l'extraction pendant les heures creuses pour minimiser la charge du système.
Types de document : Le script extrait tous les types de document de demande d'achat par défaut. Pour affiner la portée, vous pouvez ajouter un filtre post-extraction dans le DataFrame pandas basé sur 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()

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Achats au paiement : attributs de demande d'achat

Achats au paiement – Activités de demande d'achat

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 Table Extraction

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Boostez l'efficacité de vos demandes d'achat P2P, commencez votre essai gratuit

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Achats au paiement : attributs de demande d'achat

Achats au paiement – Activités de demande d'achat

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 Table Extraction

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Boostez l'efficacité de vos demandes d'achat P2P, commencez votre essai gratuit