Your Purchase to Pay - Requisition Data Template

The Activity Name describes a single step or status change within the purchase requisition lifecycle. It provides a human-readable label for events such as 'Requisition Submitted', 'Approval Step Started', or 'Requisition Rejected', forming the building blocks of the process map.

This attribute is fundamental to process discovery and analysis. By sequencing these activities, process mining tools can visualize the actual process flow, identify deviations from the standard procedure, and pinpoint bottlenecks or rework loops. Consistent and meaningful activity names are key to creating an understandable and actionable process model.

It defines the individual steps of the process, which are essential for visualizing the process map and analyzing process flow.

Often derived from event logs, status change tables, or transaction codes associated with the requisition document.

Event Time, often called a timestamp, records the exact moment an activity took place. This data is critical for sequencing events correctly and for all time-based process analysis, including cycle time calculation, bottleneck identification, and performance monitoring.

In process mining, timestamps are used to order the activities within each case and to measure the duration between different steps. Analyzing these durations helps uncover delays, understand the causes of long cycle times, and evaluate whether service level agreements are being met. Accurate and complete timestamp data is a prerequisite for any meaningful performance analysis.

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

Typically recorded in system audit trails, event logs, or as a creation or change date on transaction records.

The Purchase Requisition ID is a unique key assigned to every requisition document when it is created. It acts as the central reference point for all activities, changes, and approvals associated with a single request from initiation to completion.

In process mining, this ID is crucial for case correlation. It allows the system to reconstruct the end-to-end journey of each requisition, connecting disparate events like 'Requisition Created', 'Approval Step Approved', and 'Purchase Order Created' into a coherent process flow. Analyzing process variants, cycle times, and outcomes is impossible without a consistent and unique case identifier.

This is the essential key for tracking a requisition's entire lifecycle, enabling the connection of all related events into a single process instance.

Typically found in the header data of the purchase requisition transaction or document table.

The Last Data Update timestamp indicates the freshness of the data being analyzed. It shows when the record was last extracted from the source system and loaded into the process mining environment.

This attribute is essential for operational monitoring and ensuring that analyses are based on current information. It helps users understand the potential lag between real-world events and their representation in the process model. Dashboards and KPIs that track ongoing operations rely on this information to provide timely and relevant insights.

It informs users about the timeliness of the data, which is critical for ensuring that analyses are relevant and up-to-date.

Typically added by the data integration or ETL (Extract, Transform, Load) tool during the data loading process.

The Source System attribute specifies the origin of the process data. In organizations with multiple systems, such as a central ERP and a specialized e-procurement tool, this field helps distinguish between data from different sources.

This information is valuable for data validation, troubleshooting, and understanding process variations that may be system-dependent. For instance, requisitions originating in one system might follow a different approval path or have a faster cycle time than those from another. Analyzing data by source system can reveal integration issues or opportunities for system consolidation.

It provides context about data origin, which is crucial for data validation and for analyzing process differences across multiple systems.

This is often a static value added during the data extraction process or can be found in technical metadata fields.

The Currency attribute specifies the unit of money for the Requisition Amount. For multinational organizations, requisitions may be created in various currencies depending on the location of the requester or supplier.

This field is essential for accurate financial reporting and analysis. It ensures that monetary values are interpreted correctly and allows for proper conversion when aggregating data across different regions. Any analysis involving requisition value must consider the currency to avoid comparing different monetary units directly.

It provides the necessary context for financial data, ensuring accurate interpretation and aggregation of requisition values across regions.

Typically located in the header data of the purchase requisition transaction, alongside the amount fields.

The Department attribute represents the organizational unit responsible for the purchase, such as 'Marketing', 'IT', or 'Finance'. It is a key piece of financial and organizational data used for budgeting and cost allocation.

In process mining, analyzing data by department is a common and powerful technique. It allows for performance comparison between different business units, helping to identify which departments are most efficient and which may need support. This analysis can uncover variations in cycle time, approval rates, or compliance that are specific to a department's purchasing habits or internal processes.

It enables performance benchmarking and cost analysis across different business units, revealing department-specific process behaviors.

Typically available in the header or line-item data of the purchase requisition, linked to the company's organizational structure.

The Purchase Order ID is the unique number of the PO document generated from an approved purchase requisition. This field links the requisition process to the subsequent procurement and payment processes.

This attribute is critical for analyzing the Requisition-to-PO conversion efficiency. It confirms that a requisition successfully resulted in a purchase order and allows measurement of the time taken for this conversion. By analyzing which requisitions have a corresponding PO, businesses can assess the effectiveness of the pre-procurement phase and identify requisitions that are approved but never fulfilled.

It links the requisition to the subsequent procurement process, enabling analysis of requisition-to-PO conversion rates and times.

Often found in the requisition document data after a PO has been created, sometimes in a related documents or document flow table.

Requester Name identifies the individual who initiated the purchasing request. This person is typically the business user who needs the goods or services.

Analyzing the process by requester can help identify patterns related to specific individuals or groups. For instance, it can reveal if certain requesters frequently submit incomplete or non-compliant requisitions that require rework. This information can be used to provide targeted training or to simplify the requisitioning process for common user groups, ultimately improving efficiency and compliance.

It helps identify user-specific behaviors, enabling targeted training and process improvements for individuals or teams.

Found in the header data of the purchase requisition, often linked to the employee master data.

Requisition Amount represents the total financial value of all items and services requested in the purchase requisition. This is a key financial metric used throughout the procurement process.

In process analysis, this attribute is vital for value-based filtering and analysis. It allows for the segmentation of requisitions into categories like high-value and low-value, which often have different approval workflows and risk profiles. Analyzing cycle times or rejection rates based on requisition amount can reveal that high-value requests take significantly longer to approve or are rejected more often, providing a starting point for process improvement.

It allows for value-based analysis, helping to prioritize high-value requisitions and understand how financial value impacts process behavior.

Typically found in the header data of the purchase requisition transaction or document table.

Requisition Status indicates the state of the requisition at a given point in time or its final outcome. Common statuses include 'In Progress', 'Pending Approval', 'Approved', 'Rejected', and 'Closed'.

This attribute is essential for outcome analysis and operational monitoring. It allows analysts to filter for requisitions based on their final state to calculate metrics like rejection rates or PO conversion rates. In an operational context, it helps teams understand the current workload, such as the number of requisitions pending approval, enabling them to prioritize work and manage resources effectively.

It provides a clear view of requisition outcomes, enabling the calculation of key metrics like rejection rates and supporting operational workload management.

Usually found in the header status field of the purchase requisition document.

Requisition Type classifies the purchase request based on its nature or purpose. Examples include requests for standard materials, services, capital expenditures, or from a specific catalog. This classification often determines the approval workflow and accounting treatment.

Analyzing the process by requisition type helps to understand if different types of requests follow different paths or experience different levels of efficiency. For example, capital expense requisitions might have longer cycle times due to additional approval layers, while requests for standard catalog items may be highly automated. This analysis helps in designing and optimizing type-specific process variants.

It allows for analysis of different process paths, as the type of requisition often dictates the required approval workflow and complexity.

This information is typically stored as a document type or category code in the requisition header data.

Approver Name identifies the individual, role, or group that performed an approval or rejection step in the workflow. This is distinct from the requester or the general user who might perform other activities.

This attribute is key for analyzing the approval process itself. It helps measure approver performance, such as the average time an approver takes to make a decision. It can also identify workload distribution, showing if certain approvers are bottlenecks in the process. This analysis supports better resource allocation and performance management within the approval chain.

It allows for detailed analysis of the approval workflow, including approver workload, performance, and identification of bottlenecks.

Recorded in the event or audit log for approval-related activities. It may require joining with employee master data.

The Rejection Reason is a text field or code explaining why a requisition was denied. Approvers provide this information to give feedback to the requester, who may need to amend and resubmit the request.

This attribute is invaluable for root cause analysis of process failures. By categorizing and analyzing rejection reasons, organizations can identify common issues like 'Incorrect GL Code', 'Budget Exceeded', or 'Non-compliant Supplier'. These insights can drive targeted improvements, such as better training for requesters, clearer policy communication, or system enhancements to prevent common errors.

It provides direct insight into why requisitions fail, enabling root cause analysis to reduce rework and improve first-time approval rates.

Typically captured in a comments or notes field associated with the 'Rejected' activity or status change.

The Required By Date is specified by the requester to indicate the deadline for fulfillment. This date serves as a target for the entire procurement process, from requisition approval to final delivery.

This attribute is important for analyzing process timeliness and its alignment with business needs. By comparing the Required By Date with the actual Purchase Order creation date or delivery date, organizations can measure their ability to meet internal service level agreements. It helps answer critical questions, such as whether the procurement process is fast enough to meet business deadlines.

It provides a benchmark for measuring process performance against business deadlines and assessing on-time fulfillment capabilities.

Typically entered by the user during requisition creation and stored in the requisition header or line item details.

Urgency Level, sometimes called Priority, is a field used by requesters to indicate how quickly the requested goods or services are needed. This classification can influence how the requisition is routed and prioritized by the procurement team and approvers.

Analyzing process performance by urgency level helps determine if the process is responsive to business needs. For example, one can verify if 'High' urgency requests are actually processed faster than 'Low' urgency ones. If not, it may indicate a bottleneck or a failure in the prioritization mechanism that needs to be addressed.

It helps evaluate if the process effectively prioritizes urgent requests and if stated urgency aligns with actual processing speed.

Usually an optional or mandatory field on the requisition creation form, stored in the requisition header.

User Name identifies the individual responsible for any given activity in the process log. This is a general attribute that can capture the requester, an editor, an approver, or anyone else who interacts with the requisition.

This attribute is fundamental for resource and automation analysis. It helps in understanding the 'four-eyes principle' (handoffs between different users) and can be used to calculate automation rates by identifying activities performed by system or batch users. Analyzing activities by user helps to understand how different roles interact with the process.

This attribute is essential for understanding user handoffs, analyzing automation, and attributing specific process steps to the correct actor.

Found in the audit trail or event log data for each transaction, often stored as a User ID.