Data Template: Purchase to Pay - Purchase Order

SAP ECC
Data Template: Purchase to Pay - Purchase Order

Your Purchase to Pay - Purchase Order Data Template

This template guides you through the essential data points required to analyze your Purchase to Pay - Purchase Order process in SAP ECC. It outlines the crucial attributes to collect, the key activities to track, and provides practical guidance on how to extract this information from your system. Use this resource to build a robust event log for your process mining initiatives.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance for SAP ECC

Purchase to Pay - Purchase Order Attributes

These are the essential data fields recommended for inclusion in your event log, enabling a comprehensive analysis of your Purchase to Pay - Purchase Order process.
3 Required 6 Recommended 13 Optional
NameDescription
Activity
Activity
The name of the specific business event or step that occurred within the purchase order lifecycle.
Description

This attribute describes a single step in the process, such as 'Purchase Order Created', 'Purchase Order Approved', or 'Goods Receipt Posted'. The sequence of these activities forms the process flow for each purchase order.

Analyzing the sequence, frequency, and duration between activities is the core of process mining. It helps identify bottlenecks, rework loops, and deviations from the standard process, enabling targeted improvements and standardization efforts.

Why it matters

Activities define the steps of the process. Analyzing their sequence and timing reveals the actual process flow, bottlenecks, and deviations.

Where to get

Derived from various SAP tables and transaction logs, such as CDHDR/CDPOS for changes, EKBE for GR/IR, and EBAN for requisitions. Often requires a custom logic or extraction program to generate.

Examples
Purchase Order CreatedPurchase Order ApprovedGoods Receipt Posted
Event Time
EventTime
The precise date and time when the activity occurred.
Description

This timestamp marks the exact moment an event took place, such as the time a PO was approved or when a goods receipt was posted. It provides the chronological order for all activities within a case.

Timestamps are fundamental for process mining as they enable all time-based analysis. This includes calculating cycle times between activities, identifying delays, analyzing process throughput, and measuring performance against service level agreements (SLAs).

Why it matters

This timestamp is critical for calculating all duration-based metrics, such as cycle times and bottlenecks, and for ordering events chronologically.

Where to get

Derived from various date and time fields in SAP tables, such as EKKO-AEDAT (Change Date), CDHDR-UDATE/UTIME (Change Log Timestamp), or EKBE-BUDAT (Posting Date).

Examples
2023-04-15T10:05:31Z2023-04-16T14:22:00Z2023-05-01T09:00:15Z
Purchase Order
PurchaseOrder
The unique identifier for the Purchase Order (PO) document, serving as the primary case for tracking the procurement process.
Description

The Purchase Order number is the central identifier that links all activities from its creation to final goods receipt and completion. Each unique PO number represents a single instance of the procurement process.

In process mining, this attribute is essential for reconstructing the end-to-end journey of each purchase. It allows for detailed analysis of cycle times, process variations, and compliance checks for every individual order, forming the foundation of the entire process model.

Why it matters

This is the core identifier that connects all related events, making it possible to analyze the complete lifecycle of each individual purchase order.

Where to get

Table: EKKO, Field: EBELN

Examples
450001762345000176244500017625
Company Code
CompanyCode
The identifier for the legal entity or company initiating the purchase.
Description

The Company Code represents an independent legal entity in SAP. All transactions are posted at the company code level, making it a fundamental organizational unit.

Analyzing the process by Company Code allows for comparison of procurement efficiency and compliance across different business units or countries. It helps identify best practices in one entity that could be replicated elsewhere, or pinpoint specific units that are struggling with the process.

Why it matters

Represents the legal entity, enabling process performance comparison and compliance checks across different parts of the organization.

Where to get

Table: EKKO, Field: BUKRS

Examples
10002100US01
Document Type
DocumentType
A code that classifies different types of purchase orders.
Description

The Document Type is a configuration in SAP that controls the number range, field selection, and overall process flow for a purchase order. For example, there might be different types for standard POs, service POs, or stock transport orders.

This attribute is a powerful dimension for analysis, as different document types often follow intentionally different processes. Filtering by document type allows for a more accurate, apples-to-apples comparison of cycle times and process flows.

Why it matters

Distinguishes between different kinds of purchasing processes (e.g., standard, service, return), which often have distinct paths and performance expectations.

Where to get

Table: EKKO, Field: BSART

Examples
NBFOUB
Material Group
MaterialGroup
A classification for grouping materials or services with similar characteristics.
Description

The Material Group, or purchase category, is used to classify the type of goods or services being procured. Examples include 'IT Hardware', 'Office Supplies', or 'Professional Services'.

This attribute is crucial for spend analysis and understanding procurement patterns. It allows for filtering the process to analyze how different categories are handled, who approves them, and which vendors supply them. It is a key dimension in the 'Purchase Order Value Analysis' dashboard.

Why it matters

Allows for segmenting the process by product or service category, revealing different behaviors, cycle times, or vendors for different types of spend.

Where to get

Table: EKPO, Field: MATKL

Examples
00101IT_HWCONSULT
Order Amount
OrderAmount
The total monetary value of the purchase order line item.
Description

This attribute represents the total value of a specific line item on the purchase order, calculated as quantity multiplied by the net price. For a full PO value, item amounts need to be aggregated.

Analyzing the process by order amount is critical for identifying high-value transactions that may require more stringent controls or different approval paths. It powers the 'Purchase Order Value Analysis' dashboard and helps prioritize process improvement efforts on the most financially significant orders.

Why it matters

Quantifies the financial impact of each purchase, enabling value-based analysis to prioritize high-value orders or identify cost-saving opportunities.

Where to get

Table: EKPO, Field: NETWR (Net Order Value).

Examples
1500.00250.7512345.50
User Name
UserName
The user ID of the person who executed the activity.
Description

This attribute captures the SAP username of the employee who created, changed, or approved a document. For automated steps, it may show a system or batch user ID.

Analyzing by user helps identify training needs, high-performing individuals, or potential compliance issues. It is key for building dashboards related to workload distribution, approval matrix compliance, and understanding the performance of different teams or individuals.

Why it matters

Attributes user actions to specific individuals, enabling analysis of user performance, workload, and adherence to compliance protocols.

Where to get

Table: EKKO, Field: ERNAM (Created by); Table: CDHDR, Field: USERNAME (Changed by).

Examples
JSMITHMBROWNBATCH_USER
Vendor Number
VendorNumber
The unique identifier for the vendor or supplier.
Description

This is the code that uniquely identifies the supplier from whom the goods or services are being procured. It is a critical piece of master data in the procurement process.

This attribute is essential for vendor-centric analysis. It allows for the evaluation of vendor delivery performance, comparison of lead times across different suppliers, and analysis of spending patterns. It is the primary dimension for the 'Vendor Delivery Performance' dashboard.

Why it matters

Enables vendor performance analysis, helping to identify reliable suppliers and those causing delays or quality issues.

Where to get

Table: EKKO, Field: LIFNR

Examples
100345V-20598700112
Currency
Currency
The currency code for the purchase order amount.
Description

This attribute specifies the currency in which the purchase order value is denominated, such as USD, EUR, or GBP. It provides essential context for any monetary values.

For global organizations, currency is essential for correct financial analysis. It allows for proper aggregation and comparison of order values, and all monetary KPIs must be interpreted in the context of their currency.

Why it matters

Provides necessary context for all monetary values, ensuring accurate financial analysis, especially in multinational organizations.

Where to get

Table: EKKO, Field: WAERS

Examples
USDEURJPY
End-To-End Cycle Time
EndToEndCycleTime
The total time elapsed from the first activity to the last activity for a purchase order.
Description

This metric measures the total duration of the entire purchase order process, from the earliest recorded event (e.g., 'Purchase Requisition Created') to the final event (e.g., 'Purchase Order Completed').

This is a critical KPI for measuring overall process efficiency. It provides a high-level view of performance, and its analysis helps identify the longest running cases and general bottlenecks. It directly supports the 'End-to-End PO Cycle Time Analysis' dashboard and the 'Avg End-to-End PO Cycle Time' KPI.

Why it matters

Measures the overall speed and efficiency of the entire procurement process, providing a key health indicator.

Where to get

This is a calculated attribute, determined by subtracting the timestamp of the first event from the timestamp of the last event for each case.

Examples
10 days 4 hours22 days 1 hour5 days 8 hours
Is On-Time Delivery
IsOnTimeDelivery
A flag indicating if the goods were received on or before the requested delivery date.
Description

This boolean attribute is true if the 'Goods Receipt Posted' activity's timestamp is on or before the 'Requested Delivery Date'. It provides a clear, binary outcome for delivery performance on each PO line item.

This attribute is the foundation for the 'On-Time Goods Receipt Rate' KPI. It simplifies the analysis of vendor performance and internal receiving efficiency by allowing for easy aggregation and filtering of on-time versus late deliveries.

Why it matters

Provides a clear success or failure metric for delivery timeliness, directly supporting vendor performance KPIs and dashboards.

Where to get

This is a calculated attribute derived by comparing the goods receipt posting date (EKBE-BUDAT) with the requested delivery date (EKPO-EINDT).

Examples
truefalse
Is Post-Approval Change
IsPostApprovalChange
A flag indicating if a PO change occurred after the initial approval.
Description

This boolean attribute is true if a 'Purchase Order Changed' activity is detected after a 'Purchase Order Approved' activity for the same PO. It helps isolate problematic changes that occur late in the process.

This calculated field directly supports the 'Post-Approval PO Change Rate' KPI and the 'Purchase Order Rework and Changes' dashboard. It helps quantify and highlight disruptive changes that can cause delays and require re-approval, pointing to issues in the initial specification or scoping process.

Why it matters

Directly measures rework after approval, a key KPI for process stability and efficiency. High rates indicate problems in the upstream requirements definition.

Where to get

This is a calculated attribute derived from the sequence of activities in the event log.

Examples
truefalse
Last Data Update
LastDataUpdate
The timestamp indicating when the data was last refreshed from the source system.
Description

This attribute records the date and time of the most recent data extraction or update. It provides context on the freshness of the data being analyzed.

Displaying this information in dashboards is vital for users to understand if the insights are based on near real-time data or a historical snapshot. It manages user expectations and ensures decisions are made based on data of a known age.

Why it matters

Informs users about the timeliness of the data, ensuring they understand if the analysis reflects the most current state of operations.

Where to get

This timestamp is generated and added by the data extraction or ETL process at the time of execution.

Examples
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Plant
Plant
The physical location or plant where the goods are to be delivered.
Description

The Plant is an organizational unit representing a production facility, warehouse, or other location where goods or services are received.

Analyzing by Plant helps understand geographical variations in the procurement process. It can reveal differences in vendor delivery times to certain locations or highlight specific plants that have inefficient receiving processes, supporting analysis of goods receipt timeliness.

Why it matters

Specifies the delivery location, which is useful for analyzing regional process differences and logistics performance.

Where to get

Table: EKPO, Field: WERKS

Examples
100011002000
Purchase Requisition
PurchaseRequisition
The identifier of the purchase requisition that preceded the purchase order.
Description

This attribute links the purchase order back to its originating purchase requisition. Not all POs will have a preceding requisition.

This link is vital for analyzing the 'Requisition to Order Conversion' dashboard and the 'PR to PO Conversion Rate' KPI. It allows for measuring the efficiency of the upstream process, from the initial request to the creation of a formal order, and for identifying non-compliant POs created without a requisition.

Why it matters

Links the PO to its source request, enabling analysis of the PR-to-PO conversion process and identifying POs created without a prior requisition.

Where to get

Table: EKPO, Field: BANFN

Examples
1001589010015891
Purchasing Group
PurchasingGroup
The specific buyer or group of buyers responsible for the procurement activity.
Description

The Purchasing Group represents the individual or team of buyers responsible for a certain purchasing activity. They are the main point of contact for vendors.

This attribute provides a more granular level of analysis than the Purchasing Organization. It helps in understanding workload distribution among buyers and identifying performance differences at the buyer level, which can inform resource allocation and training initiatives.

Why it matters

Provides a granular view of who is responsible for a purchase, allowing for detailed workload and performance analysis at the buyer or team level.

Where to get

Table: EKKO, Field: EKGRP

Examples
001002N01
Purchasing Organization
PurchasingOrganization
The organizational unit responsible for negotiating prices and procuring materials or services.
Description

The Purchasing Organization is a key organizational unit in SAP responsible for procurement activities. It can be centralized for the entire company or decentralized by plant or region.

Analyzing process performance by Purchasing Organization helps identify which procurement teams are most efficient. It allows for comparing metrics like cycle time, rework rates, and costs across different organizational units, highlighting best practices and areas needing support.

Why it matters

Identifies the procurement team responsible, enabling performance comparisons and analysis across different organizational units.

Where to get

Table: EKKO, Field: EKORG

Examples
1000US01DE01
Rejection Reason
RejectionReason
The reason code or text explaining why a purchase requisition or order was rejected.
Description

This attribute captures the specific reason provided when a purchase order is rejected during the approval workflow. This information is crucial for understanding the root causes of rework and delays.

Analyzing rejection reasons helps identify common issues such as incorrect pricing, budget overruns, or non-compliant vendor selection. This insight allows the business to address the root causes, improve the quality of initial PO creation, and streamline the approval process.

Why it matters

Provides direct insight into why approvals fail, enabling targeted improvements to reduce rework and shorten approval cycle times.

Where to get

This information can be difficult to locate. It may be stored in long text fields or depend on custom workflow configuration. Often requires specific implementation knowledge.

Examples
Incorrect priceBudget exceededDuplicate request
Requested Delivery Date
RequestedDeliveryDate
The date on which the business requested the vendor to deliver the goods or services.
Description

This is the target delivery date specified in the purchase order. It serves as the baseline against which actual delivery performance is measured.

This date is essential for calculating the 'On-Time Goods Receipt Rate' KPI. By comparing the actual goods receipt date to this requested date, organizations can quantitatively measure vendor reliability and internal receiving efficiency, which directly supports the 'Vendor Delivery Performance' dashboard.

Why it matters

This is the target date for delivery, essential for calculating on-time performance KPIs and evaluating vendor reliability.

Where to get

Table: EKPO, Field: EINDT

Examples
2023-06-102023-07-222023-08-01
Source System
SourceSystem
The system from which the data was extracted.
Description

This attribute identifies the origin of the data, which is typically an SAP ECC instance identifier (e.g., 'ECC_PROD_100'). In environments with multiple systems, it helps differentiate data sources.

For governance and data lineage, knowing the source system is crucial. It ensures data integrity and helps in troubleshooting data extraction or quality issues, especially when data is merged from different ERP systems or modules.

Why it matters

Identifies the data's origin, which is crucial for data governance, validation, and managing analyses across multiple systems.

Where to get

This is typically a static value added during the data extraction process to label the dataset with its system of origin.

Examples
SAP_ECC_PRODECC_EU_100S4H_FIN
Vendor Name
VendorName
The legal name of the vendor or supplier.
Description

The descriptive name of the vendor, which is more user-friendly than the vendor number. This is typically sourced from the vendor master data.

While the Vendor Number is used for joins and unique identification, the Vendor Name is crucial for user-facing dashboards and reports. It makes analyses more intuitive and accessible to business users who may not be familiar with the vendor codes.

Why it matters

Provides a human-readable name for the vendor, making dashboards and reports much easier for business users to understand.

Where to get

Table: LFA1, Field: NAME1. This requires a join from EKKO-LIFNR to LFA1-LIFNR.

Examples
Staples Inc.Global Tech SolutionsOffice Supply Co.
Required Recommended Optional

Purchase to Pay - Purchase Order Activities

These are the critical process steps and milestones to capture in your event log, providing the foundation for accurate process discovery and bottleneck identification.
6 Recommended 8 Optional
ActivityDescription
Goods Receipt Posted
This activity signifies the physical receipt of goods from a vendor against a specific purchase order. Posting the goods receipt is an explicit action (e.g., via transaction MIGO) that creates a material document and updates inventory.
Why it matters

This is a critical milestone for tracking vendor delivery performance and the start of the invoice verification process. It is used to calculate on-time delivery rates and goods receipt timeliness.

Where to get

Recorded upon the creation of a material document. The event timestamp is the posting date (MKPF-BUDAT) or creation date (MKPF-CPUDT) from the material document header table (MKPF), linked to the PO via the item table (MSEG).

Capture

Use the posting/creation timestamp from the MKPF table for material documents referencing the PO.

Event type explicit
Purchase Order Approved
Represents the final approval of the purchase order, authorizing it to be sent to the vendor. This key milestone is typically inferred from a change in the PO's release status to a 'fully released' or 'approved' state.
Why it matters

This activity is critical for calculating the PO Approval Cycle Time KPI and identifying bottlenecks in the approval workflow. It is a prerequisite for most subsequent activities like sending the order to the vendor.

Where to get

Inferred by tracking the change logs (CDHDR/CDPOS) for the Purchase Order header table (EKKO) to find when the final release code is applied or when the overall release status indicator (EKKO-FRGKE) is set to 'released'.

Capture

Identify the timestamp when the PO's overall release status (EKKO-FRGKE) changes to the final approved state.

Event type inferred
Purchase Order Completed
Indicates that a purchase order item is considered fully delivered. This is an inferred event, typically derived from the 'Delivery Completed' indicator being automatically or manually set on the purchase order item.
Why it matters

This activity serves as a logical end point for the order fulfillment part of the process. It is essential for calculating the end-to-end PO cycle time from creation to completion.

Where to get

Inferred from the change documents (CDHDR/CDPOS) that record when the 'Delivery Completed' indicator (EKPO-ELIKZ) is set to 'X' for a PO item. The last item being marked as complete can signify the completion of the whole PO.

Capture

Identify the timestamp from change documents when the EKPO-ELIKZ flag is set.

Event type inferred
Purchase Order Created
This activity signifies the creation of a formal purchase order document, which is a binding contract with a vendor. This is an explicit event, logged when a user creates and saves a PO (e.g., via transaction ME21N), resulting in entries in the EKKO and EKPO tables.
Why it matters

Marks the official start of the purchase order lifecycle. It serves as a key milestone for measuring both the PR-to-PO conversion time and the end-to-end order fulfillment time.

Where to get

Captured from the creation date (EKKO-AEDAT) in the Purchase Order header table (EKKO) for the corresponding PO number (EKKO-EBELN).

Capture

Use the creation timestamp from the EKKO table for each new Purchase Order.

Event type explicit
Purchase Order Sent to Vendor
This activity marks the point at which the approved purchase order is officially transmitted to the vendor, for example, via EDI, email, or print. It is an explicit event captured in the message control tables when an output message is successfully processed.
Why it matters

This is a critical milestone that starts the clock on vendor lead time. Analyzing the time from this event to goods receipt is key for evaluating vendor performance and delivery timeliness.

Where to get

Recorded in the message status table (NAST). The timestamp can be taken from NAST-DATVR and NAST-UHRVR when the processing status (NAST-VSTAT) is '1' (successfully processed) for the relevant PO output type.

Capture

Use the processing timestamp from the NAST table for the PO's output message.

Event type explicit
Purchase Requisition Created
This activity marks the creation of a formal request for goods or services. It is an explicit event captured when a user saves a new purchase requisition document (using transactions like ME51N), which generates a unique record in the EBAN table.
Why it matters

This is the primary starting point for the procurement process. Analyzing the time from this event to purchase order creation helps measure the efficiency of converting internal demand into actionable orders.

Where to get

Recorded upon the creation of an entry in the Purchase Requisition header table (EBAN). The creation date (EBAN-BADAT) and time serve as the timestamp for this event.

Capture

Identify new entries in the EBAN table based on creation date.

Event type explicit
Goods Returned
Represents the return of previously received goods to the vendor, often due to quality issues or incorrect shipments. This is an explicit event captured by posting a material document with a return-specific movement type.
Why it matters

This activity highlights problems with vendor quality or order accuracy and is a key indicator of process rework. It is crucial for calculating the Goods Receipt Variance Rate KPI.

Where to get

Recorded in the material document tables (MKPF/MSEG) when a return movement type (e.g., '122' for Return Delivery to Vendor) is used. The posting date (MKPF-BUDAT) serves as the timestamp.

Capture

Identify material documents with a return movement type (e.g., 122) that reference the original PO.

Event type explicit
Purchase Order Approval Requested
Indicates that a created or changed purchase order has been submitted for approval according to its configured release strategy. This event is inferred when the release strategy is triggered and the PO enters a pending approval status.
Why it matters

Differentiating between PO creation and the start of the approval process helps to precisely measure the approval cycle time KPI. It highlights any lag before the approval workflow begins.

Where to get

Inferred from change documents (CDHDR/CDPOS) for the Purchase Order (object EINKBELEG) that show the initial setting of a release status, or when the overall release status (EKKO-FRGKE) is first set to a value indicating an approval process is active.

Capture

Identify the first change document entry that triggers the release strategy for the PO.

Event type inferred
Purchase Order Changed
Represents any modification made to a purchase order after its initial creation, such as changes to quantity, price, or delivery dates. These changes are explicitly logged in SAP's change document system.
Why it matters

Frequent changes, especially after approval, indicate process inefficiencies, poor initial planning, or scope creep. This activity is essential for the PO Rework and Changes dashboard and related KPIs.

Where to get

Explicitly logged in the change document header (CDHDR) and item (CDPOS) tables for the Purchase Order object (EINKBELEG). Each change creates a new entry with a timestamp.

Capture

Extract change events and timestamps from CDHDR and CDPOS tables linked to the Purchase Order number.

Event type explicit
Purchase Order Deleted
Represents the cancellation or logical deletion of a purchase order item, preventing further processing like goods receipts or invoicing. This is an inferred event, captured when the deletion indicator is set on the PO item.
Why it matters

This is a terminal activity that indicates an order was cancelled. Analyzing why and when orders are deleted can uncover issues in demand planning or vendor selection.

Where to get

Inferred from change documents (CDHDR/CDPOS) that show the deletion indicator (EKPO-LOEKZ) being set to 'L' for a purchase order item.

Capture

Identify the timestamp from change documents when the EKPO-LOEKZ flag is set.

Event type inferred
Purchase Order Rejected
This activity occurs when an approver rejects a purchase order during the approval workflow. It is an inferred event, derived from a status change in the PO's release strategy data, indicating a rejection has occurred.
Why it matters

Tracking rejections helps identify issues with PO data quality, policy non-compliance, or problems within the approval matrix. It often leads to rework and increases overall cycle time.

Where to get

Inferred from change documents (CDHDR/CDPOS) for the purchase order release status. A rejection is typically recorded when a release code is cancelled or a specific rejection status is set.

Capture

Monitor change logs for the cancellation of a release code or a status change indicating rejection.

Event type inferred
Purchase Requisition Approved
Represents the formal approval of a purchase requisition, authorizing it to be converted into a purchase order. This event is inferred from changes in the release status fields within the purchase requisition data, as tracked by SAP's release strategy workflow.
Why it matters

Tracking approvals is crucial for identifying bottlenecks in the pre-ordering phase and ensuring compliance with approval policies. Delays here directly impact the overall procurement cycle time.

Where to get

Inferred from the change logs for the Purchase Requisition table (EBAN), specifically monitoring changes to the release status fields (e.g., EBAN-FRGZU) or by analyzing change documents in CDHDR/CDPOS for the EBAN object.

Capture

Monitor change documents for EBAN release status fields to identify the timestamp of the final approval.

Event type inferred
Quality Inspection Performed
Indicates that received goods have undergone a quality inspection. This activity is typically inferred when an inspection lot, created at the time of goods receipt, has a usage decision made against it in the Quality Management module.
Why it matters

For industries where quality is critical, this activity helps analyze the duration and outcomes of the inspection process. Delays here can create bottlenecks between goods receipt and availability for use.

Where to get

Inferred from the Quality Management module. An inspection lot is created (QALS table) upon goods receipt, and the activity is marked by the creation of a usage decision (QAVE table), which includes a timestamp.

Capture

Identify the timestamp of the usage decision in table QAVE for the inspection lot linked to the material document.

Event type inferred
Services Confirmation Entered
For service-based purchase orders, this activity represents the confirmation that services have been rendered. It is an explicit event captured through the creation of a Service Entry Sheet (e.g., via transaction ML81N).
Why it matters

This is the equivalent of a goods receipt for services and is essential for tracking the fulfillment of service orders. It triggers the financial process for service payment.

Where to get

Captured from the creation date (ESSR-ERDAT) in the Service Entry Sheet header table (ESSR). The link to the purchase order is in the ESLL table.

Capture

Use the creation timestamp from the ESSR table for service entry sheets linked to the PO.

Event type explicit
Recommended Optional

Extraction Guides

How to get your data from SAP ECC