> Continuous Process Improvement > Purchase to Pay Requisition > SAP ECC > Data Template

Your Purchase to Pay - Requisition Data Template

SAP ECC

Purchase to Pay - Requisition Attributes (20) Purchase to Pay - Requisition Activities (13) Extraction Guides (2)

Your Purchase to Pay - Requisition Data Template

This template provides a comprehensive guide to collecting the essential data needed for analyzing your Purchase to Pay Requisition process. It outlines the crucial data fields to gather, the key activities to track, and practical guidance for extracting this information from your source system. Use this resource to prepare your data for effective process mining.

Recommended attributes to collect
Key activities to track
Extraction guidance for SAP ECC

New to event logs? Learn how to create a process mining event log.

Download Template

Purchase to Pay - Requisition Attributes

These are the recommended data fields to include in your event log for comprehensive analysis of your Purchase to Pay Requisition process.

5 Required 5 Recommended 10 Optional

	Name	Description
	Activity Name ActivityName	The name of the business activity that occurred at a specific point in time.
Description This attribute describes a specific step or event in the purchase requisition lifecycle, such as 'Requisition Created', 'Approval Submitted', or 'Purchase Order Created'. These activities are typically derived from status changes, workflow logs, or change documents within SAP. Analyzing the sequence and frequency of activities is the foundation of process mining. It allows for the discovery of the actual process flows, including common paths, deviations, and bottlenecks. This is crucial for building dashboards like the End-to-End Requisition Process Map and calculating KPIs related to rework and compliance. Why it matters It defines the steps in the process, enabling the visualization of process maps and the analysis of process flow variations. Where to get Derived from change document tables CDHDR and CDPOS, workflow logs, or status fields like EBAN-STATU. Examples Requisition CreatedApproval Step ApprovedRequisition RejectedPurchase Order Created
	Event Time EventTime	The timestamp indicating when the activity occurred.
Description Event Time records the precise date and time that a specific activity took place. This timestamp is fundamental for all time-based analysis in process mining, including calculating cycle times, identifying bottlenecks, and understanding process performance. In the context of requisitions, this attribute allows for the calculation of critical KPIs such as 'Average Requisition Approval Time' and 'Time to PO Creation'. It powers dashboards that visualize durations, such as the Requisition Approval Cycle Time analysis, by providing the raw data needed to measure the time between any two points in the process. Why it matters This timestamp is essential for calculating all durations, analyzing process performance, and discovering time-related bottlenecks. Where to get Found in change document header table CDHDR (fields UDATE and UTIME). Examples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Purchase Requisition ID PurchaseRequisitionId	The unique identifier for a purchase requisition document.
Description The Purchase Requisition ID is the primary key that uniquely identifies each request for goods or services within SAP ECC. It serves as the 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. In process mining, this ID is essential for reconstructing the end-to-end lifecycle of each requisition. By tracking this identifier, analysts can visualize the complete process flow, measure durations between milestones, and analyze variations in how different requisitions are handled. It allows for a cohesive view of the entire requisition journey. Why it matters This is the core identifier that connects all related process events into a single case, making end-to-end process analysis possible. Where to get Found in the EBAN table, field BANFN. Examples 100234567810023456791002345680
	Last Data Update LastDataUpdate	The timestamp of the most recent data refresh or extraction from the source system.
Description This attribute indicates when the dataset was last updated. It's a static timestamp applied to the entire dataset during each data load, serving as a reference point for the freshness of the analysis. For any process mining dashboard or analysis, knowing the data's recency is critical for making informed decisions. This attribute ensures that all stakeholders are aware of the time frame covered by the data they are viewing, preventing conclusions based on outdated information. Why it matters Informs users about the freshness of the data, which is crucial for the relevance and accuracy of the process analysis. Where to get This is a static value representing the timestamp of the data extraction, added during the ETL process. Examples 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Source System SourceSystem	Identifies the source system from which the data was extracted.
Description This attribute specifies the origin of the process data, for example, 'SAP ECC Production' or 'S4HANA QA'. It is typically a static value added during the data extraction process to provide context, especially in environments with multiple source systems. In process analysis, this helps differentiate data from various sources, ensuring that analyses are not skewed by mixing data from production, testing, or development environments. It is a fundamental piece of metadata for data governance and traceability. Why it matters Provides essential context for data origin, ensuring traceability and enabling multi-system analysis. Where to get This is a static value typically added during the data extraction, transformation, and loading (ETL) process. Examples SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Department Department	The department of the requester or the cost center associated with the requisition.
Description This attribute represents the business unit or department that initiated the purchase requisition. This is often derived from the requester's user profile or the cost center assigned to the requisition line item. Analyzing the process by department is critical for understanding performance variations across the organization. It is the primary dimension for the 'Requisition Approval Cycle Time' dashboard and the 'Departmental Approval Time Variance' KPI, helping to pinpoint which departments have efficient processes and which may require improvement or additional resources. Why it matters Enables performance comparison between business units, highlighting departmental bottlenecks and process inconsistencies. Where to get Often derived by linking the Requester (EBAN-AFNAM) to user master data (SU01) or by using the Cost Center (EBKN-KOSTL) associated with the requisition's account assignment. Examples FinanceIT OperationsMarketingManufacturing
	Document Type RequisitionDocumentType	A classification that determines the type and characteristics of the purchase requisition.
Description The Document Type in SAP controls various aspects of a purchase requisition, including the number range, field selection, and the overall procurement process it follows. Examples include 'Standard PR', 'Stock Transfer', or 'Service PR'. This attribute is a powerful dimension for analysis because different document types often have distinct process flows and approval requirements. It allows analysts to segment the data to compare the performance of different requisition processes, which is key for understanding compliance and identifying opportunities for process standardization or specialization. Why it matters Allows for the segmentation of requisitions into different process categories, enabling more precise and relevant analysis. Where to get Found in the EBAN table, field BSART. Examples NBUBRV
	Requisition Status RequisitionStatus	The current processing status of the purchase requisition.
Description This attribute indicates the overall status of the requisition at a given point in time, such as 'In Release', 'Approved', 'Rejected', or 'Closed'. This is often represented by a status code in SAP. Tracking the status is essential for understanding the outcome of requisitions. It directly supports the 'Requisition Outcome and Rejection Rates' dashboard and KPIs like 'Requisition Rejection Rate' and 'Requisition Withdrawal Rate'. Analyzing how requisitions transition between statuses helps identify process inefficiencies and failure points. Why it matters It defines the outcome of a requisition, which is crucial for analyzing success rates, rejection reasons, and process endpoints. Where to get The processing status is found in table EBAN, field STATU. The release status is in EBAN-FRGZU. Examples N (Not edited)B (PO created)A (RFQ created)K (Closed)
	Total Requisition Value TotalRequisitionValue	The total monetary value of all items in the purchase requisition.
Description This attribute represents the total financial amount of the purchase requisition. The value is often a key factor in determining the required approval workflow, with higher-value requisitions typically requiring more extensive scrutiny and more approval steps. Analyzing by value is critical for understanding how financial impact affects process behavior. It can reveal if high-value requisitions take longer to approve, are rejected more often, or follow different process paths. This is also a fundamental metric for assessing the financial throughput of the procurement process. Why it matters Helps correlate process behavior with financial impact, which is essential for risk analysis and understanding approval complexity. Where to get Sum of the value from all line items. Line item value is in table EBAN, field GSWER. The currency is in EBAN-WAERS. Examples 1500.00250.50125000.00
	User Name User	The ID of the user who performed the activity.
Description This attribute identifies the specific user responsible for an event, such as creating a requisition, approving a step, or amending a document. In SAP, this is often captured as a user ID. Analyzing by user helps identify training needs, user-specific performance, and potential sources of data entry errors. It is essential for dashboards like 'Requisition Creation Throughput by Requester' and for understanding workload distribution and compliance with segregation of duties policies. Why it matters Attributes activities to specific individuals, enabling analysis of user performance, workload, compliance, and training needs. Where to get Found in change document header table CDHDR (field USERNAME) for changes, and EBAN (field ERNAM) for the creator. Examples SMITHJR.DOEUSER123
	Approval Cycle Time ApprovalCycleTime	The total time elapsed from when a requisition is submitted for approval until it is finally approved.
Description This is a calculated metric that measures the duration of the approval phase of the requisition lifecycle. It is calculated by finding the time difference between the 'Approval Submitted' activity and the final 'Requisition Approved' activity for each case. This is a primary KPI for measuring the efficiency of the approval workflow. It is used in the 'Requisition Approval Cycle Time' dashboard to visualize performance and identify bottlenecks. A high approval cycle time can significantly delay the entire procurement process. Why it matters Directly measures the efficiency of the approval workflow, a common source of delays in the requisition process. Where to get Calculated by subtracting the timestamp of the 'Approval Submitted' event from the timestamp of the 'Requisition Approved' event. Examples P2DPT8H30MP5DT12H
	Is Rework IsRework	A boolean flag indicating if the requisition has undergone a rework loop, such as an amendment after submission.
Description This is a derived attribute that flags activities or cases involving rework. For example, any 'Requisition Amended' activity that occurs after 'Approval Submitted' would be considered rework. It can also be triggered by rejection events that send the process back to an earlier stage. This flag is essential for the 'Requisition Amendment and Rework Analysis' dashboard. It allows for easy filtering and quantification of rework, helping to measure its impact on overall cycle times and identify the root causes of process inefficiencies. High rates of rework often point to issues with data quality or unclear requirements. Why it matters Helps quantify the frequency and impact of rework, making it easy to identify and analyze process inefficiencies and loops. Where to get Derived from the event log by identifying specific sequences of activities, such as 'Requisition Amended' occurring after an approval activity. Examples truefalse
	Material Group MaterialGroup	The group or category to which the requested material or service belongs.
Description The Material Group is a classification used to group together materials or services with similar characteristics. This allows for category-based analysis of procurement activities. Analyzing by material group helps in strategic sourcing and spend analysis. In process mining, it can reveal if requisitions for certain categories, like 'IT Hardware' or 'Professional Services', follow different process paths or experience longer approval times. This insight is valuable for the 'Requisition Data Quality Report' and for understanding process variations based on what is being purchased. Why it matters Allows for spend and process analysis by procurement category, supporting strategic sourcing and identifying category-specific bottlenecks. Where to get Found in the EBAN table, field MATKL. Examples 00101L001IT-SFTWR
	Plant Plant	The company location or plant for which the goods or services are requested.
Description The Plant is an organizational unit within a company, representing a physical location such as a factory, warehouse, or office. The requisition specifies the plant where the requested items are needed. Analyzing by plant allows for geographical or site-specific views of the requisition process. It can highlight performance differences between locations, which may be due to different local procedures, staffing levels, or business needs. This is a common dimension for regional performance dashboards. Why it matters Provides a geographical or location-based context for analysis, helping to identify regional process variations and performance differences. Where to get Found in the EBAN table, field WERKS. Examples 10002100DE01
	Priority Priority	The urgency level assigned to the purchase requisition.
Description This attribute indicates the priority of the requisition, often classifying it as 'Urgent', 'High', or 'Normal'. This flag is used to signal to approvers and buyers that a request requires expedited handling. This attribute is essential for the 'Urgent Requisition Processing Performance' dashboard and the 'Urgency Flag Effectiveness' KPI. Analysis focuses on whether requisitions marked as urgent are actually processed faster than standard ones, helping to validate the effectiveness of the prioritization system and ensure that business-critical needs are met promptly. Why it matters Enables analysis of whether urgent requests are processed faster, validating the effectiveness of prioritization mechanisms. Where to get This is not a standard field in EBAN. It is often implemented as a custom field or inferred from the Requirement Tracking Number (EBAN-BEDNR) or a specific document type. Examples 123
	Purchase Order ID PurchaseOrderId	The ID of the purchase order created from the requisition.
Description This attribute 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. This link is crucial for analyzing the handoff between the requisition and purchasing processes. It is required to calculate the 'Time to PO Creation from Requisition' KPI and to support the 'Approved Requisition to PO Creation Delay' dashboard. Understanding this connection is key to measuring the efficiency of the entire procure-to-pay cycle. Why it matters Connects the requisition process to the downstream purchasing process, enabling analysis of handoff delays. Where to get The purchase order number is stored in the EBAN table, field EBELN, after it has been created. Examples 450001712345000171244500017125
	Purchasing Group PurchasingGroup	The group of buyers responsible for procuring the requested items.
Description The Purchasing Group is an organizational unit responsible for specific procurement activities. It represents the team of buyers who will handle the requisition once it is approved. This attribute is useful for analyzing the workload and performance of different buying teams. It can help identify if certain purchasing groups are bottlenecks in the conversion of requisitions to purchase orders, or if they handle specific types of requisitions more efficiently than others. It provides a key dimension for resource and performance management within the procurement function. Why it matters Assigns responsibility for procurement, enabling workload analysis and performance comparison across different buying teams. Where to get Found in the EBAN table, field EKGRP. Examples 001002P01
	Rejection Reason RejectionReason	The reason provided when a requisition or an approval step is rejected.
Description This attribute captures the justification for rejecting a purchase requisition. This information is typically entered as free text or selected from a predefined list of codes by the approver during the rejection activity. Analyzing rejection reasons is crucial for process improvement. It provides direct, actionable feedback on why requisitions fail, which could be due to policy violations, incorrect data, or unavailable budget. This data is key for the 'Requisition Outcome and Rejection Rates' dashboard and helps identify root causes of process inefficiencies. Why it matters Provides direct insights into why requisitions are rejected, enabling targeted process improvements and user training. Where to get This data is typically stored in workflow logs or long text associated with the rejection event. There is no standard field in EBAN. Examples Incorrect Cost CenterBudget ExceededDuplicate RequestNot compliant with policy
	Requester Name RequesterName	The name of the person who requested the goods or services.
Description This attribute identifies the individual who initiated the purchase requisition. This is the person who has the business need for the requested items. Tracking the requester allows for analysis of requisition patterns by individual or group. The 'Requisition Creation Throughput by Requester' dashboard relies on this attribute to identify power users, users who may need additional training, or departments with high procurement activity. It provides a human-centric view of the process start point. Why it matters Identifies the process owner, enabling analysis of requisition creation patterns and helping to target user training. Where to get Found in the EBAN table, field AFNAM. Examples Alice WilliamsBob JohnsonCharlie Brown
	Vendor ID VendorId	The unique identifier for the suggested or fixed vendor.
Description This attribute contains the ID of a preferred or contractually fixed vendor for the item being requested. It may be pre-populated or suggested by the requester. Analyzing requisitions by vendor can help assess the impact of pre-selecting suppliers on the procurement process. For example, it can show whether requisitions with a specified vendor are approved faster or if certain vendors are associated with higher rates of rejection. It provides a view into early-stage supplier engagement. Why it matters Provides insights into preferred supplier relationships and their impact on requisition processing speed and outcomes. Where to get Found in the EBAN table, field LIFNR (Fixed vendor). Examples 100030025V9876

Required Recommended Optional

Purchase to Pay - Requisition Activities

These are the key process steps and milestones to capture in your event log for accurate discovery and analysis of your requisition workflow.

6 Recommended 7 Optional

	Activity	Description
	Approval Submitted	This activity signifies that the requisition has entered the formal approval workflow. It is typically inferred when the requisition's status changes to require an initial release or approval action based on the configured release strategy.
Why it matters This marks the beginning of the approval cycle time, a critical KPI for measuring process efficiency. Understanding this point helps isolate delays between creation and the start of formal approvals. Where to get Inferred from the first status change related to the release strategy in table EBAN (e.g., field FRGZU changes from initial to a pending state) or the first entry in workflow logs associated with the requisition. Capture Inferred from the first change log entry indicating the activation of a release strategy. Event type inferred
	Purchase Order Created	This activity marks the successful conversion of an approved purchase requisition into a purchase order document. The event is inferred for the requisition by finding a corresponding purchase order item that references it.
Why it matters As the primary successful outcome, this activity concludes the requisition process and begins the procurement phase. The time between 'Requisition Approved' and this event is a key KPI for measuring handoff efficiency. Where to get Inferred by finding a record in the EKPO (PO Item) table where the fields BANFN and BNFPO match the purchase requisition number and item from the EBAN table. The PO creation date (EKKO.AEDAT) provides the timestamp. Capture Inferred by linking EBAN to EKPO tables and using the PO creation date from EKKO. Event type inferred
	Requisition Approved	This milestone activity signifies that the purchase requisition has successfully passed all required approval steps. It is inferred when the final release code is applied and the overall release indicator (FRGZU) in the EBAN table is set to an approved state.
Why it matters This is a critical milestone that marks the end of the approval cycle and the start of the procurement phase. It's essential for calculating the total approval time KPI and measuring handoff delays to PO creation. Where to get Inferred from the timestamp of the change log entry in CDPOS for table EBAN, field FRGZU, when it changes to the value representing final approval. Capture Inferred from the final release indicator field in EBAN reaching a terminal 'approved' status. Event type inferred
	Requisition Created	This activity marks the initial creation and saving of a purchase requisition by a user. The event is captured explicitly when a new record is generated in the EBAN table, with the creation date and time recorded.
Why it matters As the starting point of the process, this activity is essential for calculating the total requisition lifecycle duration and analyzing creation throughput. It helps identify who is creating requisitions and when. Where to get This event is captured from the EBAN table using the creation date (ERDAT) and creation time (UZEIT) fields for a given Purchase Requisition ID (BANFN). Capture Timestamp from EBAN table fields ERDAT and UZEIT upon initial record save. Event type explicit
	Requisition Rejected	This is a terminal activity where the purchase requisition is definitively rejected and cannot proceed further. It is inferred when the release indicator in the EBAN table is set to a final rejected state by an approver.
Why it matters This activity is a key process endpoint and crucial for calculating the Requisition Rejection Rate KPI. Analyzing these cases helps understand reasons for procurement failure and waste. Where to get Inferred from the timestamp of the change log entry in CDPOS for table EBAN, field FRGZU, when it changes to the value representing final rejection. Capture Inferred from the final release indicator field in EBAN reaching a terminal 'rejected' status. Event type inferred
	Requisition Withdrawn	This is a terminal activity where the creator or an authorized user cancels the requisition item by setting a deletion flag. This action is explicitly recorded and indicates the business need is no longer valid or was created in error.
Why it matters This is a key failure endpoint for the process, essential for calculating the withdrawal rate. High rates may indicate long approval times forcing users to abandon requests, or systemic issues with demand planning. Where to get This explicit action is captured when the 'Deletion Indicator' (LOEKZ) field in the EBAN table is set for the requisition item. The change is logged in CDHDR and CDPOS. Capture Change log entry when the Deletion Indicator (EBAN-LOEKZ) is set to 'L'. Event type explicit
	Approval Reset	Indicates that the entire approval workflow for the requisition has been reset, often due to a significant amendment. This is inferred when the release status is cleared after previously being active, forcing the approval process to restart from the beginning.
Why it matters Approval resets are significant rework events that heavily impact cycle time. Identifying them highlights process inefficiencies and the downstream effect of requisition amendments on the workflow. Where to get Inferred from change logs (CDHDR/CDPOS) for the EBAN table where release status fields (like FRGZU) are changed from a pending or approved state back to an initial or blank state. Capture Inferred from change logs showing the release strategy fields being cleared. Event type inferred
	Approval Step Approved	Represents the explicit action of an 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.
Why it matters Tracking individual approvals is necessary to measure the duration of each step and analyze the performance of different approvers. It is fundamental for understanding workflow conformance. Where to get Captured from change logs (CDHDR/CDPOS) on the release status fields of the EBAN table. The approver's action via transaction ME54N or a similar T-code triggers this logged change. Capture Change log entry created when an approver executes a release transaction. Event type explicit
	Approval Step Rejected	An authorized user has explicitly rejected a single step in the release strategy, typically sending the requisition back to the creator for amendment. This action is logged as a change to the requisition's release status.
Why it matters Rejections are a primary cause of process rework and delays. Analyzing their frequency and cause helps identify policy misunderstandings, data quality problems, or inefficient approval steps. Where to get Captured from change logs (CDHDR/CDPOS) on the release status fields in the EBAN table. A rejection action via transaction ME54N or similar will trigger a corresponding status change. Capture Change log entry created when an approver executes a rejection action. Event type explicit
	Approval Step Started	Indicates that the requisition is now pending action from a specific approver or approval group as defined in the release strategy. This event is inferred when the requisition's status indicates it is awaiting a particular release code.
Why it matters This activity allows for detailed analysis of each individual step in the approval chain. It helps pinpoint which approvers or stages are causing the longest delays in the process. Where to get Inferred by tracking the sequence of changes to the release status fields in table EBAN. Each change to a new pending state signifies the start of a new approval step. Capture Inferred from status changes indicating a new release code is now active and awaiting approval. Event type inferred
	Requisition Amended	Represents 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 of modifications.
Why it matters Tracking amendments is crucial for identifying rework loops and data quality issues. A high frequency of amendments can indicate unclear initial requirements or user training gaps, leading to process delays. Where to get Captured from change log tables CDHDR (header) and CDPOS (item) where the object class is EINKBELEG and the object ID is the Purchase Requisition number. Specific field changes can be analyzed. Capture Event logged in change tables CDHDR and CDPOS for the purchase requisition document. Event type explicit
	Requisition Blocked	Represents an explicit action to block a purchase requisition item, preventing it from being converted into a purchase order. The block is set via a specific indicator on the requisition item.
Why it matters Blocking indicates a potential issue or a temporary hold on procurement. Tracking these events helps identify bottlenecks where requisitions are approved but not actioned immediately. Where to get Captured from a change to the 'Blocking Indicator' field (EBAKZ) in the EBAN table. The change is logged in CDHDR and CDPOS. Capture Event logged in change tables when the EBAN-EBAKZ field is set. Event type explicit
	Requisition Closed	Represents the final closure of a requisition item, indicating that no further processing is expected. This status is inferred when the item has been fully converted to a PO and fulfilled, or manually flagged as closed.
Why it matters This provides a definitive end point for requisitions that are completed but not necessarily deleted. It ensures accurate lifecycle duration calculations for successfully fulfilled requests. Where to get Inferred from the 'Closed' indicator (EBAKZ with value 'S' or other configured value) in the EBAN table. This status is often set automatically by the system upon full PO conversion and goods receipt. Capture Inferred from status change in the EBAN-EBAKZ field to a 'closed' value. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from SAP ECC

Steps

Grant Database Access: Before starting, ensure you have read-only access to the underlying SAP ECC database. This requires specific credentials (username, password, host, port) and is a non-standard level of access that must be approved by your SAP basis and security teams.
Identify SAP Schema: Connect to the database with a standard SQL client, such as DBeaver, Toad, or SQL Developer. You will need to identify the correct SAP schema where the tables are stored, which is commonly named SAPSR3 or SAPR3.
Prepare the SQL Query: Use the complete SQL query provided in this document. This query is designed to extract all required activities and attributes by joining master data and change log tables.
Set Query Parameters: Locate the placeholder values within the query. You must replace them with your specific system and business requirements. Key placeholders include '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}', and '{document_types}'.
Adjust Database-Specific Syntax: The provided query uses common SQL syntax. However, functions for timestamp creation, like TO_TIMESTAMP, or string manipulation may need minor adjustments based on your specific database system, for example Oracle, SQL Server, DB2, or HANA.
Execute the Extraction: Run the customized query in your SQL client. For large datasets, it is highly recommended to run this during off-peak hours to avoid impacting system performance.
Review Preliminary Results: Once the query finishes, briefly scan the output to ensure it contains the expected columns (PurchaseRequisitionId, ActivityName, EventTime, etc.) and that rows are being returned for various activities.
Export to CSV: Export the entire result set from your SQL client to a CSV file. Ensure the file uses UTF-8 encoding to prevent issues with special characters.
Prepare for Upload: Confirm the CSV column headers exactly match the aliases defined in the SQL query. The file should be a clean, tabular representation of the event log.
Upload to ProcessMind: Upload the final CSV file to your ProcessMind project for analysis and visualization.

Configuration

Database Connection: A direct connection to the SAP ECC database is required. You will need the hostname, port, database name, and appropriate user credentials.
SAP Schema: The name of the schema containing the SAP tables must be known, for example, SAPSR3. The query must be executed within the context of this schema.
Date Range: To manage performance and data volume, it is critical to filter by a specific date range. We recommend starting with a period of 3 to 6 months. Set the '{start_date}' and '{end_date}' placeholders in the format YYYYMMDD.
Organizational Filters: For more targeted analysis, filter the data by Company Code (BUKRS) and Purchase Requisition Document Type (BSART). Replace the '{company_codes}' and '{document_types}' placeholders with comma-separated lists of values, for example, '1000','2000'.
Prerequisites: This method requires SAP Basis and Security team approval to obtain direct database credentials. It is not a standard end-user activity.
Performance Considerations: The query joins on change log tables (CDHDR, CDPOS), which can be very large. Without proper filtering, the query can be slow and consume significant system resources. Always execute with a restrictive date range and other filters.

a Sample Query 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

Steps

Set up Python Environment: Ensure you have Python 3.6 or newer installed. Create a project folder and set up a virtual environment to manage dependencies. Install the necessary libraries using pip: pip install pyrfc pandas numpy
SAP RFC SDK: Download the SAP NetWeaver RFC SDK from the SAP Support Portal. Extract the contents and place the library files (e.g., sapnwrfc.dll on Windows, libsapnwrfc.so on Linux) into a directory that is accessible by your system's path or your Python script.
Configure SAP Connection: Open the provided Python script. Locate the section for SAP connection parameters and replace the placeholder values (ashost, sysnr, client, user, passwd) with your actual SAP system credentials. Ensure the user has the required authorizations for RFC execution and table access.
Define Extraction Parameters: In the script, set the date_from and date_to variables to define the desired time range for the extraction. It is recommended to start with a smaller period, for example, one month, to test the extraction process.
Execute the Python Script: Run the script from your terminal using the command python your_script_name.py. The script will connect to SAP via RFC, call RFC_READ_TABLE for each required table (EBAN, EKKO, EKPO, CDHDR, CDPOS), and download the data.
Data Retrieval: The script fetches raw data for requisitions, purchase orders, and change documents. It uses filtering criteria, such as date ranges and object classes, to limit the amount of data transferred.
Local Data Transformation: Once the data is downloaded, the script uses the pandas library to perform all transformations locally. It processes the raw table data to generate distinct event log entries for each of the 13 required activities, such as 'Requisition Created', 'Approval Step Approved', and 'Purchase Order Created'.
Generate Event Log: The script combines the events generated from each table into a single, unified DataFrame. It calculates event timestamps, maps user names, and structures the data into the required case ID, activity, and timestamp format.
Attribute Mapping: Key attributes like PurchaseRequisitionId, ActivityName, EventTime, User, and TotalRequisitionValue are mapped to their respective columns in the final DataFrame.
Export to CSV: The script saves the final event log as a CSV file named event_log_pr.csv in the same directory. This file is formatted for direct upload into ProcessMind.
Review and Upload: Open the generated CSV file to review the data for completeness and correctness. Once validated, you can proceed to upload the file to your ProcessMind project.

Configuration

SAP Connection: The script requires direct RFC connection details to the SAP ECC system, including application server, system number, client, user, and password. The specified user must have authorizations for RFC calls and display access to tables EBAN, EKPO, EKKO, CDHDR, and CDPOS.
Date Range: The extraction is governed by start and end date parameters within the script. For initial runs and to manage performance, it is recommended to extract a data range of 3 to 6 months.
Table Filters: Filtering is applied within the RFC calls where possible. For instance, requisitions are filtered by creation date (EBAN-ERDAT), and change documents are filtered by date (CDHDR-UDATE) and object class (CDHDR-OBJECTCLAS = 'BANF').
Python Libraries: The script relies on pyrfc for SAP connectivity and pandas for data manipulation. Ensure these libraries are installed in your Python environment.
Performance: Extracting data via RFC_READ_TABLE can be slow for very large datasets, as data is pulled sequentially table by table. Running the extraction during off-peak hours is advisable to minimize system load.
Document Types: The script extracts all purchase requisition document types by default. To narrow the scope, you can add a post,extraction filter in the pandas DataFrame based on the BSART column from the EBAN table.

a Sample Query 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()

Your Purchase to Pay - Requisition Data Template

Your Purchase to Pay - Requisition Data Template

Purchase to Pay - Requisition Attributes

Purchase to Pay - Requisition Activities

Extraction Guides

Direct SQL Query on SAP ECC Underlying Database

Steps

Configuration

a Sample Query sql

Python Script using SAP RFC for Table Extraction

Steps

Configuration

a Sample Query python

Ready to Get Started?

Unlock P2P Requisition Efficiency, Start Your Trial Now

Your Purchase to Pay - Requisition Data Template

Your Purchase to Pay - Requisition Data Template

Purchase to Pay - Requisition Attributes

Purchase to Pay - Requisition Activities

Extraction Guides

Direct SQL Query on SAP ECC Underlying Database

Steps

Configuration

a Sample Query sql

Python Script using SAP RFC for Table Extraction

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Unlock P2P Requisition Efficiency, Start Your Trial Now