Your Purchase to Pay - Requisition Data Template

The Activity Name describes a specific event or task that took place within the lifecycle of a purchase requisition. These activities are derived from system logs, such as change documents and workflow histories, and represent key process milestones like 'Requisition Created', 'Approval Step Started', or 'Purchase Order Created'.

Analyzing these activities allows for the visualization of the process flow, identification of bottlenecks, and measurement of time spent in different stages. Understanding the sequence and frequency of activities like 'Requisition Amended' or 'Requisition Rejected' is crucial for identifying process inefficiencies and areas for improvement.

It defines the steps in the process, forming the backbone of the process map and enabling analysis of process flow, variations, and bottlenecks.

This is a derived attribute, typically constructed by interpreting data from change document tables (CDHDR, CDPOS) and workflow logs (e.g., SWWLOGHIST).

Event Time is the timestamp that records when an activity took place. This data is critical for chronological ordering of events within a case and is the basis for all duration and performance calculations in process mining. For example, the time difference between the 'Requisition Submitted' and 'Requisition Approved' events determines the approval cycle time.

Accurate timestamps are essential for analyzing process performance, identifying delays, and monitoring adherence to service level agreements. This attribute enables dashboards that visualize cycle times, track stalled requisitions, and compare performance over different time periods.

This timestamp is essential for ordering events, calculating cycle times, and analyzing process performance and bottlenecks.

Timestamps are typically sourced from change document headers (CDHDR-UDATE, CDHDR-UTIME) or workflow event logs.

The Purchase Requisition ID is the primary key that uniquely identifies each request for goods or services within SAP S/4HANA. It serves as the central case identifier, linking all activities and changes related to a specific requisition from its creation to its final state, such as approval, rejection, or conversion into a purchase order.

In process mining, this attribute is fundamental for reconstructing the end-to-end lifecycle of each requisition. By grouping all related events under a single Purchase Requisition ID, analysts can accurately measure cycle times, track status changes, and analyze the different paths a requisition can take through the approval process.

This is the essential case identifier that connects all related process steps, enabling a complete and coherent view of the requisition lifecycle.

This attribute is the Purchase Requisition Number, found in table EBAN, field BANFN.

The Approver ID specifically identifies the user who completed an approval or rejection activity. This is distinct from the general User ID as it focuses solely on the decision-makers within the approval workflow. Capturing this information is vital for analyzing the approval process in detail.

This attribute allows for the analysis of approval behavior, such as identifying managers with long approval times or those who frequently reject requisitions. It is fundamental for dashboards focused on approval step cycle times and workflow bottleneck analysis, helping to pinpoint specific individuals or roles that may be causing delays.

Pinpoints the specific decision-maker in an approval step, enabling detailed analysis of approval cycle times and bottlenecks by individual or role.

This information is typically extracted from SAP Business Workflow tables like SWW_WI2OBJ and SWWLOGHIST, which link work items to the completing user.

The Department attribute, often represented by the Cost Center in SAP, identifies the business unit responsible for the requested purchase. It is a critical piece of financial and organizational information assigned at the line-item level of a requisition.

In process mining, this attribute is essential for departmental performance analysis. It enables dashboards that compare key metrics like cycle time, amendment rates, and rejection rates across different departments. This helps identify high-performing departments whose practices could be adopted elsewhere, as well as departments that may require additional training or process support.

Enables performance comparison across business units, highlighting variations in cycle times or rejection rates to identify best practices and areas for improvement.

This is the Cost Center, typically found in the account assignment table EBKN, field KOSTL.

The Requisition Amount represents the total estimated cost of the goods or services being requested. This value is often a key factor in determining the complexity and length of the approval workflow, with higher value requisitions typically requiring more levels of approval.

Analyzing this attribute allows for segmentation of the process based on value. It can help answer questions such as, 'Do high-value requisitions take longer to approve?' or 'What is the value of requisitions that are frequently rejected?'. It is a critical dimension for understanding the financial impact of process inefficiencies.

Helps segment the process by financial impact, often correlating with approval complexity and cycle time. It is vital for value-based process analysis.

The total value can be found in table EBAN, field GFWERT. Item-level value is in EBAN-PREIS.

The Requisition Status indicates the current state of the requisition within its lifecycle. In SAP, this is often represented by the Release Indicator, which shows whether a requisition is blocked, in approval, partially approved, or fully approved. This status changes as the requisition moves through the workflow.

Tracking the status over time is fundamental to understanding the process flow. It helps in identifying where requisitions are getting stuck and for how long. Analyzing transitions between statuses allows for a detailed view of the approval process and its variants.

Indicates the current state of a requisition, which is critical for tracking progress, identifying bottlenecks, and analyzing process flow.

The release status is often determined by the Release Indicator, found in table EBAN, field FRGZU.

The Requisition Type, also known as Document Type in SAP, is a key configuration field that categorizes purchase requisitions. Different types can trigger different approval workflows, have different field settings, and are used for different business purposes, such as standard stock items, external services, or asset purchases.

By analyzing the process based on Requisition Type, organizations can understand how different types of requests are handled. It allows for comparing performance, cycle times, and approval paths across categories, which can reveal if certain requisition types are more or less efficient and help tailor process improvements.

Categorizes requisitions to enable comparative analysis, helping to understand if different types of requests have different process flows, bottlenecks, or cycle times.

This is the Document Type field, found in table EBAN, field BSART.

The User ID identifies the employee or system user responsible for a particular event in the requisition's lifecycle. This can be the person who created the requisition, the manager who approved it, or the agent who amended it. In cases of automated steps, this might be a system or batch user ID.

Analyzing by User ID helps in understanding user-specific behavior, workload distribution, and performance. It is key for identifying training needs, recognizing high-performing individuals, and ensuring accountability within the process. It also supports departmental performance analysis when combined with user master data.

Enables analysis of user performance, workload distribution, and process compliance. It is crucial for identifying training opportunities and resource bottlenecks.

Found in EBAN-ERNAM for the creator. For subsequent changes, it's in CDHDR-USERNAME. For approvals, it's in workflow logs.

The Approval Step Name provides a human-readable description of a particular stage in the approval workflow, such as 'Manager Approval' or 'VP Finance Approval'. This is more descriptive than a generic 'Approval Step Completed' activity.

This attribute is critical for the Approval Step Cycle Time and Workflow Bottleneck Analysis dashboards. It allows for a granular view of the approval process, making it possible to pinpoint exactly which approval stages are causing the most significant delays and where work is accumulating. This level of detail is necessary for targeted interventions to streamline the approval chain.

Provides granular detail on approval stages, enabling precise identification of bottlenecks within the multi-level approval workflow.

This information is derived from the workflow task description, which can be found by linking the workflow log to task definition tables like T528T.

This attribute specifies the currency in which the requisition amount is denominated, for example, USD, EUR, or JPY. It provides the necessary context for the Requisition Amount attribute, especially in multinational organizations that operate with multiple currencies.

For accurate financial analysis and reporting, it is essential to consider the currency. When aggregating or comparing requisition values, all amounts should be converted to a common currency to ensure meaningful results. This attribute is a prerequisite for such conversions.

Provides essential context for the Requisition Amount, enabling accurate financial analysis and comparisons in multi-currency environments.

This is found in table EBAN, field WAERS.

EndTime is the timestamp that records when an activity was finished. While many system-generated events are instantaneous (meaning StartTime equals EndTime), human tasks like approvals may have a distinct start and end. This timestamp marks the completion of that work.

Having a separate EndTime allows for more accurate measurement of active processing time versus idle waiting time. It is used in conjunction with StartTime to calculate the ProcessingTime metric. This level of detail enhances the analysis of resource utilization and efficiency for manual tasks.

Marks the completion of an activity, enabling the calculation of active processing time and providing a more detailed view of task duration.

This is derived from workflow logs that may capture both when a work item was created (StartTime) and when it was completed (EndTime).

The Is Automated attribute is a boolean flag that is true if an activity was executed by a system or batch user, such as 'WF-BATCH' for workflow actions. This helps distinguish between manual and automated steps in the process.

This attribute is essential for measuring the level of automation in the requisition process and for calculating the 'Automated Approval Rate' KPI. By filtering for automated or manual steps, analysts can compare their efficiency and identify opportunities for further automation to reduce processing times and manual effort.

Distinguishes between human and system-driven activities, which is key for measuring automation rates and identifying opportunities to automate manual tasks.

This is a derived attribute, typically based on a rule that checks if the User ID for an event belongs to a list of known system or batch users.

Is Rework is a calculated boolean flag that identifies activities that represent non-value-added or repetitive work. A common example in this process is the 'Requisition Amended' activity occurring after the requisition has already been submitted for approval, forcing the approval process to restart.

This attribute is crucial for quantifying the amount of rework in the process and its impact on overall cycle times. The Requisition Amendment and Rework Rate dashboard relies on this flag to highlight process inefficiencies. Reducing rework is often a primary goal of process improvement initiatives as it directly translates to saved time and effort.

Flags activities that represent wasted effort or repetition, allowing for the direct measurement of rework and its impact on process efficiency.

This is a calculated attribute. The logic would typically flag any 'Requisition Amended' activity that occurs after the first 'Requisition Submitted For Approval' activity as rework.

This attribute records the date and time of the most recent data extraction or update from the source system. It is a critical piece of metadata for understanding the freshness of the data being analyzed. Analysts and business users rely on this timestamp to know if the process data reflects the most current state of operations.

In any process analysis, knowing the currency of the data is fundamental for making informed decisions. This attribute helps manage user expectations and ensures that conclusions are drawn from data that is as up-to-date as required for the specific analysis.

Indicates the freshness of the data, which is crucial for trusting the analysis and making timely business decisions.

This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process.

Processing Time measures the time it took to complete a single activity. It is calculated as the difference between the end time and the start time of an event. For many events in SAP, the start and end times are the same, resulting in a processing time of zero. However, for approval steps, it can represent the time an approver spent working on the task.

This calculated metric is useful for understanding the effort involved in different process steps. It can help distinguish between the time a case is waiting (wait time) and the time it is actively being worked on (processing time), providing a more nuanced view of process performance.

Measures the active work time for an activity, helping to distinguish between time spent working versus time spent waiting, which is key for resource analysis.

This is a calculated attribute, typically derived as EndTime minus StartTime for each event in the event log.

The Purchase Order Number is the identifier of the official purchasing document created from an approved requisition. The creation of a purchase order is often the final, successful outcome for a requisition, signifying that the request has been converted into a formal order with a supplier.

This attribute is crucial for measuring the Requisition to Purchase Order Lead Time KPI and the overall conversion rate. It links the requisitioning process with the downstream procurement process, enabling a broader, end-to-end view of the entire Purchase-to-Pay cycle.

Links the requisition to the subsequent procurement document, enabling measurement of the requisition-to-PO conversion rate and lead time.

Found in table EBAN, field EBELN, once a PO has been created from the requisition item.

The Rejection Reason explains why an approver decided to reject a purchase requisition. Reasons might include budget exceedance, incorrect information, non-compliance with policy, or duplication of another request. This information provides crucial context for understanding process failures.

Analyzing rejection reasons helps identify the root causes of process inefficiencies and rework. For example, if 'Incorrect Cost Center' is a common reason, it points to a need for better user training or system validation. This attribute is the key to the Requisition Rejection Analysis dashboard and is vital for targeted process improvement.

Provides the root cause for process failures, enabling targeted improvements to reduce rework and increase the first-time-right rate of requisitions.

This is often not a standard field. It may be captured in workflow container elements, long text associated with the requisition, or custom fields.

The Required By Date, or Delivery Date in SAP, specifies when the goods or services on the requisition line item are needed. This date is set by the requester and serves as a target for the entire procurement process.

This attribute is essential for calculating the 'On-Time Requisition Completion Rate' KPI. By comparing the Required By Date with the final approval or PO creation date, the organization can measure its ability to meet internal service levels and business needs. Analyzing requisitions that miss this date can highlight systemic delays in the procurement process.

Defines the target completion date for a request, allowing for the measurement of on-time delivery and adherence to internal service levels.

This is the Delivery Date, found at the item level in table EBAN, field LFDAT.

The Source System attribute indicates the originating system where the process data was generated. In organizations with multiple SAP instances, such as different systems for development, quality assurance, and production, or separate systems for different regions, this field is crucial for data governance and context.

It ensures that data from different sources can be distinguished, preventing incorrect aggregation and enabling system-specific analysis. It is a mandatory attribute for maintaining data lineage and ensuring the traceability of the process data.

Provides essential context for data origin and governance, especially in landscapes with multiple systems, ensuring data traceability.

This is typically the SAP System ID (SID), which can be retrieved from system variables or configuration tables.

The Urgency Level indicates the priority of the purchase request. While not a standard dedicated field, some organizations use fields like the Requirement Tracking Number to capture this information. This allows requesters to flag critical needs that may require expedited processing.

Analyzing the impact of urgency is important for evaluating whether the process effectively prioritizes critical requests. The Urgency Level Impact Analysis dashboard uses this attribute to compare cycle times and approval rates for urgent versus standard requisitions, helping to determine if priority handling is working as intended.

Allows for analysis of how process performance differs for high-priority requests, helping to validate if urgent items are truly expedited.

There is no standard urgency field. Some companies use the Requirement Tracking Number (EBAN-BEDAR) for this purpose. It may also be a custom field.