Your Purchase to Pay - Requisition Data Template

NetSuite
Your Purchase to Pay - Requisition Data Template

Your Purchase to Pay - Requisition Data Template

This template provides a clear roadmap for collecting the essential data points needed to analyze your Purchase to Pay, Requisition process. It outlines the crucial attributes, defines the key activities to track, and offers practical guidance for extracting this information from your source system. Use this resource to prepare your event log for insightful process mining.
  • Recommended attributes to collect
  • Key activities to track for process discovery
  • Guidance for data extraction
New to event logs? Learn how to create a process mining event log.

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.
3 Required 4 Recommended 12 Optional
Name Description
Activity Name
ActivityName
The name of a specific business event or task that occurred within the purchase requisition lifecycle.
Description

The Activity Name describes a distinct step in the requisition process, such as 'Requisition Created', 'Approval Step Approved', or 'Purchase Order Created'. These activities are the building blocks of the process map, representing the work being done.

Analyzing these activities allows for the visualization of the process flow, identification of bottlenecks, and measurement of time spent in different stages. The sequence of activities for a given Purchase Requisition ID defines its journey, which can then be compared against standard procedures to identify deviations or inefficiencies.

Why it matters

It defines the steps in the process, allowing for the visualization of process maps, analysis of process variants, and identification of bottlenecks.

Where to get

This is typically derived from a combination of the transaction status, system log entries, workflow history, or custom event tracking within NetSuite.

Examples
Requisition CreatedApproval Step ApprovedRequisition AmendedPurchase Order Created
Event Time
EventTime
The precise date and time when the activity occurred.
Description

Event Time, or the timestamp, records the exact moment an activity took place. This temporal data is critical for understanding the dynamics of the requisition process, including its duration, sequencing of events, and timing.

In process analysis, timestamps are used to calculate cycle times, waiting times between activities, and adherence to service level agreements. They are the foundation for all time-based analysis, enabling the creation of dashboards like 'Requisition Approval Cycle Time' and KPIs such as 'Average Requisition Cycle Time'. Accurate timestamps are crucial for a reliable process model.

Why it matters

This timestamp is the foundation for all performance-related analysis, such as calculating cycle times, identifying delays, and measuring process efficiency.

Where to get

This information is captured in system-generated fields like 'Date Created' or in the timestamps available in the System Notes or workflow execution logs for each transaction.

Examples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Purchase Requisition ID
PurchaseRequisitionId
The unique identifier for each purchase requisition, serving as the primary case ID for process analysis.
Description

The Purchase Requisition ID is the central identifier that links all activities and events related to a specific request for goods or services. Each requisition is assigned a unique ID upon creation in NetSuite, which remains constant throughout its lifecycle.

In process mining, this attribute is fundamental for case correlation. It enables the reconstruction of the end-to-end journey of each requisition, from its initial creation through all approval steps, amendments, and final outcomes like approval, rejection, or conversion into a purchase order. Analyzing processes by this ID is essential for calculating lifecycle durations, tracking status changes, and identifying variations in process flows.

Why it matters

This is the essential key to trace the complete lifecycle of a single purchase requisition, making it possible to analyze process flows and calculate case-level metrics.

Where to get

This is the internal ID or transaction number of the Purchase Requisition record in NetSuite. It can typically be found in the 'tranid' field for the transaction.

Examples
PR-001254PR-001255PR-001256
Department
Department
The business department to which the requisition or requester belongs.
Description

The Department attribute represents the organizational unit associated with the purchase requisition, which is usually the department of the requester. This information provides a way to segment and analyze the process from an organizational standpoint.

It is a key dimension for many analyses, such as comparing approval cycle times across departments, understanding spending patterns, or identifying which departments have the highest rejection rates. This segmentation helps management allocate resources, tailor training, and streamline workflows for specific business units.

Why it matters

Enables powerful segmentation of the process data to compare performance, costs, and compliance across different business units.

Where to get

This information is often associated with the requester's employee record or can be set directly on the transaction header of the Purchase Requisition.

Examples
MarketingITFinanceOperations
Requester
Requester
The employee who created and submitted the purchase requisition.
Description

The Requester is the individual initiating the procurement process by creating the requisition. This is typically an employee needing specific goods or services to perform their job.

Analyzing data by requester is essential for identifying patterns in user behavior. It helps build dashboards like 'Requester Performance and Training Needs' by highlighting individuals with high rejection rates or frequent amendments. This insight can pinpoint areas where additional training or clearer guidelines might improve first-time submission quality and overall process efficiency.

Why it matters

Identifies the process initiator, which is crucial for analyzing user behavior, rejection rates by requester, and identifying training needs.

Where to get

This is typically the 'Employee' or 'Created By' field on the Purchase Requisition transaction record.

Examples
John SmithJane DoePeter Jones
Requisition Status
RequisitionStatus
Indicates the current state of the requisition in its lifecycle.
Description

Requisition Status provides a snapshot of where a purchase requisition is in its process at any given time. Common statuses include 'Pending Approval', 'Fully Approved', 'Rejected', and 'Closed'.

This attribute is crucial for creating dashboards like 'Requisition Status and Aging', which tracks active requisitions and how long they have been in their current state. Analyzing status transitions is a key part of process discovery, helping to understand both the happy paths and the exceptions. It is also used to determine the final outcome of a case.

Why it matters

Provides a snapshot of a case's progress, enabling analysis of aging requisitions and identifying where cases get stuck.

Where to get

This is the 'Status' or 'Approval Status' field on the Purchase Requisition transaction header.

Examples
Pending ApprovalFully ApprovedRejectedClosed
Total Amount
TotalAmount
The total monetary value of the purchase requisition.
Description

This attribute captures the total cost of all items listed on the purchase requisition. It is a critical financial data point that often influences the process itself, for example, by triggering different approval workflows based on value thresholds.

Analyzing the Total Amount helps in understanding spending patterns and financial impact. It allows for filtering requisitions by value, correlating process deviations with high-value requests, and prioritizing analysis on financially significant cases. It's a fundamental attribute for any financial or compliance-related process analysis.

Why it matters

Provides financial context, allowing for analysis based on value, which often dictates approval paths and business priority.

Where to get

This is a standard field on the Purchase Requisition record, often named 'Total' or a similar variant.

Examples
500.001250.7525000.00
Approval Workflow Path
ApprovalWorkflowPath
A representation of the sequence of approval steps a requisition has gone through.
Description

The Approval Workflow Path is a derived attribute that concatenates the sequence of approval activities or statuses for a given requisition, such as 'Submitted -> Manager Approval -> Finance Approval'. This creates a unique signature for the path each case followed.

This attribute is the foundation for conformance checking and variant analysis. It directly supports the 'Non-Compliant Requisition Pathways' and 'Approval Workflow Path Compliance' dashboards by making it easy to filter and group cases by their exact process flow. By comparing actual paths to predefined standard paths, organizations can quantify compliance and investigate the root causes of deviations.

Why it matters

Enables powerful variant analysis and conformance checking by summarizing the exact sequence of approval steps for each case.

Where to get

This is a derived attribute, calculated by concatenating the 'ActivityName' values in chronological order for each 'PurchaseRequisitionId'.

Examples
Created > Submitted > ApprovedCreated > Submitted > Rejected > Amended > Submitted > ApprovedCreated > Submitted > Approved > Withdrawn
Approver
Approver
The employee or user responsible for approving or rejecting an approval step.
Description

The Approver is the individual assigned to review and act upon a purchase requisition at a specific stage in the approval workflow. There may be multiple approvers for a single requisition, each associated with a different approval activity.

This attribute is essential for analyzing the performance of the approval process itself. It helps build dashboards like 'Approval Step Cycle Time Distribution', which can pinpoint individual or group bottlenecks. By tracking who performs approvals, organizations can ensure accountability, balance workloads, and identify delays caused by specific approvers.

Why it matters

Identifies the user performing approval tasks, which is key to analyzing approver performance, workload, and identifying bottlenecks.

Where to get

This information is often found in the workflow execution log or System Notes associated with approval status changes. It may also be stored in custom record fields related to the approval workflow.

Examples
Sarah JenkinsDavid ChenFinance Approval Group
Currency
Currency
The currency code for the requisition's total amount.
Description

The Currency attribute specifies the currency in which the requisition's financial values are denominated, such as USD, EUR, or GBP. This is particularly important for multinational organizations that operate with multiple currencies.

This field ensures that financial data is interpreted correctly. In process mining, it allows for proper aggregation and comparison of monetary values, either by converting all amounts to a single base currency or by segmenting the analysis by currency. It prevents inaccurate financial reporting and ensures clarity in global operations.

Why it matters

Essential for accurate financial analysis in multi-national organizations, ensuring monetary values are correctly interpreted and aggregated.

Where to get

This is a standard 'Currency' field on the Purchase Requisition transaction record, especially in multi-currency NetSuite instances.

Examples
USDEURGBP
Cycle Time
CycleTime
The total time elapsed from the creation to the final resolution of a requisition.
Description

Cycle Time is a calculated metric that measures the total duration of the purchase requisition process for a single case. It is typically calculated as the time difference between the first activity (e.g., 'Requisition Created') and the last terminal activity (e.g., 'Requisition Fully Approved' or 'Requisition Finally Rejected').

This is a primary key performance indicator for overall process efficiency. It is used to calculate the 'Average Requisition Cycle Time' KPI and helps identify trends, outliers, and the impact of process improvement initiatives. Analyzing cycle time distribution can reveal long-tail requisitions that significantly drag down average performance.

Why it matters

Directly measures the end-to-end efficiency of the process, which is a core metric for identifying delays and assessing overall performance.

Where to get

This is a calculated attribute, derived by subtracting the timestamp of the first event from the timestamp of the last event for each 'PurchaseRequisitionId'.

Examples
25920060480086400
Is Rework
IsRework
A boolean flag that indicates if the requisition underwent a rejection and resubmission cycle.
Description

Is Rework is a derived boolean attribute that is set to true if a purchase requisition was rejected at any point and subsequently amended or resubmitted for approval. It identifies cases that required additional work and handling beyond the standard 'happy path'.

This attribute simplifies the analysis of process inefficiency. It is used to calculate the 'Approval Rejection Cycle Count' KPI and helps quantify the impact of rejections on the overall process. By filtering for cases where Is Rework is true, analysts can isolate problematic process variants and investigate the root causes of the initial rejections, such as poor data quality or policy misunderstandings.

Why it matters

Helps quantify the frequency and impact of rework loops, which are a major source of process inefficiency and delay.

Where to get

This is a calculated attribute. The logic checks if a 'Requisition Submitted for Approval' activity occurs after an 'Approval Step Rejected' activity for the same case.

Examples
truefalse
Item Category
ItemCategory
The category of the goods or services being requested on the requisition.
Description

Item Category classifies the items on a purchase requisition into logical groups like 'IT Hardware', 'Office Supplies', or 'Professional Services'. This can be derived from the item records linked to the requisition lines.

This attribute allows for deeper, more granular analysis of the requisition process. It helps answer questions like, 'Do requisitions for IT hardware take longer to approve than those for office supplies?'. By segmenting the process by Item Category, businesses can uncover domain-specific bottlenecks, analyze spending by category, and tailor procurement strategies accordingly.

Why it matters

Enables analysis of the process based on what is being purchased, helping to identify category-specific bottlenecks or compliance issues.

Where to get

This information is derived from the 'Item' records linked on the line-item level of the Purchase Requisition. The category itself may be a standard or custom field on the Item record.

Examples
IT HardwareSoftware LicensesOffice SuppliesMarketing Services
Last Data Update
LastDataUpdate
The timestamp indicating when the data was last extracted or refreshed from the source system.
Description

This attribute records the date and time of the most recent data pull from NetSuite. It is a critical piece of metadata for any process mining dashboard or analysis.

This timestamp provides context for the freshness of the data, allowing users to understand if they are viewing real-time information or a snapshot from a specific point in time. It is crucial for data validation and for communicating the timeliness of the insights generated from the process analysis to stakeholders.

Why it matters

Informs users about the timeliness of the data, ensuring they understand how current the process insights are.

Where to get

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

Examples
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
Purchase Order ID
PurchaseOrderId
The identifier of the purchase order that was created from the approved requisition.
Description

The Purchase Order ID is the unique identifier for the purchase order generated as a result of an approved requisition. This attribute serves as a crucial link between the requisition process and the subsequent procurement activities.

In process analysis, this link is vital for end-to-end P2P analysis. It enables the calculation of the 'PO Creation Lead Time' KPI by measuring the time between requisition approval and PO creation. It also helps calculate the 'Requisition-to-PO Conversion Rate', providing insight into how effectively requisitions are converted into actionable orders.

Why it matters

Links the requisition to the resulting purchase order, enabling measurement of PO creation lead time and end-to-end process analysis.

Where to get

This is found on the Purchase Requisition record, often on a related records subtab or a 'Created From' link on the Purchase Order itself.

Examples
PO-005432PO-005433PO-005434
Rejection Reason
RejectionReason
The explanation provided by an approver when a requisition is rejected.
Description

The Rejection Reason is a text attribute where an approver can state why a purchase requisition did not meet the requirements for approval. This provides qualitative context to the 'Approval Step Rejected' activity.

This information is invaluable for root cause analysis. It powers dashboards like 'Requisition Rejection Rate Analysis' by not just showing what was rejected, but why. Common reasons might include 'Incorrect GL Account', 'Budget Exceeded', or 'Insufficient Detail'. Analyzing these reasons helps identify systemic issues, improve user training, and refine submission guidelines to reduce rework and rejection rates.

Why it matters

Provides critical context for why rejections occur, enabling root cause analysis to reduce future rejection rates and improve first-time quality.

Where to get

This is often captured in a 'Memo' field during the rejection action or a custom field added to the approval workflow. It can also be found in the System Notes.

Examples
Budget exceededIncorrect vendor selectedMissing item detailsDuplicate request
Source System
SourceSystem
Identifies the source system from which the data was extracted.
Description

This attribute specifies the originating system for the process data, which in this case is NetSuite. It is particularly useful in environments where data from multiple systems is being combined for a holistic process view.

While it may seem static in a single-system analysis, it provides essential context and is a best practice for data governance and traceability. It helps confirm the data's origin and ensures that any system-specific logic or transformations are correctly understood during analysis.

Why it matters

Provides crucial context about the data's origin, ensuring clarity and proper governance, especially in multi-system environments.

Where to get

This is a static value, 'NetSuite', that should be added during the data extraction and transformation process.

Examples
NetSuiteNetSuite SuitePeopleNetSuite ERP
Urgency Level
UrgencyLevel
A classification of the requisition's priority, such as Standard or Urgent.
Description

Urgency Level is a categorical attribute that indicates the business priority of a purchase requisition. This allows employees to flag requests that require expedited handling due to critical business needs.

This attribute is specifically designed to support the 'Urgent Request Handling Performance' dashboard and the 'Urgent Requisition Handling Time' KPI. By filtering the process data based on this attribute, analysts can compare the cycle times and process paths of urgent requests versus standard ones to determine if priority handling is effective or if bottlenecks still cause delays.

Why it matters

Allows for the comparison of process performance for high-priority versus standard requests, ensuring critical needs are met efficiently.

Where to get

This would typically be a custom transaction body field on the Purchase Requisition form.

Examples
HighMediumLow
Vendor Name
VendorName
The name of the suggested or preferred vendor for the requisition.
Description

The Vendor Name attribute identifies the supplier from whom the goods or services are intended to be purchased. While a requisition is an internal document, a preferred vendor is often specified.

Analyzing this attribute can reveal patterns related to supplier management. It helps to track which vendors are most frequently requested, whether requisitions for certain vendors face longer approval times, and to ensure compliance with preferred supplier agreements. This information can be a valuable input for strategic sourcing and vendor relationship management.

Why it matters

Helps in analyzing procurement patterns by supplier, ensuring compliance with preferred vendor lists, and identifying vendor-specific process variations.

Where to get

This can be a header-level 'Vendor' field or specified on the line items of the Purchase Requisition record.

Examples
Dell Inc.StaplesMcKinsey & Company
Required Recommended Optional

Purchase to Pay - Requisition Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and bottleneck identification.
5 Recommended 6 Optional
Activity Description
Purchase Order Created
A purchase order (PO) is generated from the fully approved requisition, officially committing funds to a vendor. This is an explicit event marked by the creation of a new PO transaction that links back to the source requisition.
Why it matters

This is the primary outcome of a successful requisition and a key hand-off in the Purchase to Pay process. The time between approval and PO creation is a critical KPI for procurement efficiency.

Where to get

Identified by finding a Purchase Order record where the 'Created From' or a similar linking field references the Purchase Requisition ID. The creation date of that PO is the timestamp for this activity.

Capture

Find PO where 'Created From' field equals the Requisition ID and use PO 'Date Created'.

Event type explicit
Requisition Closed
The requisition is formally closed, indicating that no further action is expected on it. This often happens automatically after all quantities on the requisition have been ordered via linked purchase orders.
Why it matters

This activity marks the definitive end of the requisition's lifecycle. It confirms that the business need has been addressed and the record is finalized.

Where to get

Inferred from the System Notes subtab by identifying the timestamp when the line-level or header-level 'Status' field is updated to 'Closed'.

Capture

Timestamp of 'Status' field changing to 'Closed'.

Event type inferred
Requisition Created
A user initiates the procurement process by creating and saving a new purchase requisition record. This is the first event in the requisition's lifecycle and is captured when the transaction record is first saved in NetSuite.
Why it matters

This activity marks the official start of the procurement process for a specific need. Analyzing the time from creation to submission can reveal delays in data entry or initial request formulation.

Where to get

This event is captured from the creation date timestamp of the Purchase Requisition transaction record. It can be found in the record's main header or in the System Notes subtab which logs the 'Create' action.

Capture

Use the 'Date Created' field on the Purchase Requisition record.

Event type explicit
Requisition Finally Rejected
The purchase requisition is definitively rejected and will not be processed further. This event is inferred when the requisition's final 'Approval Status' is updated to 'Rejected'.
Why it matters

This activity is a critical end point for unsuccessful requisitions. Understanding why and when requisitions are finally rejected provides insights into policy compliance and budget issues.

Where to get

Inferred from the System Notes subtab by identifying the timestamp when the 'Approval Status' field is set to its final 'Rejected' state.

Capture

Timestamp of 'Approval Status' changing to 'Rejected'.

Event type inferred
Requisition Fully Approved
The purchase requisition successfully completes all required steps in the approval workflow. This is inferred when the final 'Approval Status' of the record changes to 'Approved'.
Why it matters

This is a major milestone that signifies the requisition is ready to be converted into a purchase order. It marks the end of the approval cycle and the start of the procurement fulfillment phase.

Where to get

Inferred from the System Notes subtab by identifying the timestamp when the 'Approval Status' field is set to its final 'Approved' state.

Capture

Timestamp of 'Approval Status' changing to 'Approved'.

Event type inferred
Approval Step Approved
An authorized user approves their assigned step in the workflow, moving the requisition closer to final approval. NetSuite's SuiteApprovals platform explicitly records this action with user and timestamp details.
Why it matters

This activity represents positive progress in the approval chain. Analyzing the time between approval steps helps understand the efficiency of the workflow and individual approvers.

Where to get

Captured from the SuiteApprovals log or the System Notes subtab, which records the approval action, the approver, and the exact timestamp of the event.

Capture

Identify approval actions in the SuiteApprovals log or System Notes.

Event type explicit
Approval Step Rejected
An approver rejects their assigned step, typically sending the requisition back to the requester for correction. This action is explicitly logged by the SuiteApprovals workflow engine.
Why it matters

This event is a key indicator of rework and process inefficiency. Analyzing rejection points helps identify common reasons for failure, such as policy violations or incorrect data.

Where to get

Captured from the SuiteApprovals log or the System Notes subtab, which records the rejection action, the user who rejected it, and the timestamp.

Capture

Identify rejection actions in the SuiteApprovals log or System Notes.

Event type explicit
Approval Step Started
The requisition enters a specific stage in the approval workflow, waiting for action from a designated approver or group. This is typically inferred when the workflow assigns the requisition to the next approver in the sequence.
Why it matters

This activity marks the beginning of the wait time for each individual approval step. It is essential for pinpointing bottlenecks within the approval hierarchy and identifying slow approvers.

Where to get

Inferred from workflow execution logs or changes in a 'Current Approver' or workflow state field. The SuiteApprovals platform tracks the active approval step.

Capture

Infer from workflow logs or when the record is assigned to a new approver.

Event type inferred
Requisition Amended
A user modifies any field on the purchase requisition after its initial creation, often in response to a rejection or a change in requirements. This event is captured directly from NetSuite's audit trail feature.
Why it matters

Tracking amendments is critical for identifying rework loops and data quality issues. High amendment frequency can indicate unclear initial requirements or training needs for requesters.

Where to get

Captured from the System Notes subtab on the Purchase Requisition record. Each entry with a 'Type' of 'Change' or 'Edit' on a relevant field represents an amendment.

Capture

Log an event for each 'Change' type entry in the System Notes log.

Event type explicit
Requisition Submitted for Approval
The requester formally submits the completed requisition into the designated approval workflow. This is often inferred from a status change on the requisition record, for example from 'Draft' or 'Pending Submission' to 'Pending Approval'.
Why it matters

This activity triggers the approval cycle and is a crucial starting point for measuring approval lead times. It helps identify how long requisitions wait before the formal approval process begins.

Where to get

Inferred from the System Notes subtab by identifying the timestamp when the 'Approval Status' field changes to a value like 'Pending Approval' for the first time.

Capture

Identify first timestamp where 'Approval Status' field changes to 'Pending Approval'.

Event type inferred
Requisition Withdrawn
The original requester or an administrator cancels the requisition before it is fully approved or converted to a PO. This is typically inferred from a status change to 'Cancelled' or 'Withdrawn'.
Why it matters

This activity represents an exception or termination of the process initiated by the requester. Analyzing withdrawals can highlight changes in business needs or requisitions that are no longer valid.

Where to get

Inferred from the System Notes subtab by tracking the timestamp when the 'Approval Status' field is updated to a value like 'Cancelled' or a custom withdrawn status.

Capture

Timestamp of 'Approval Status' changing to 'Cancelled' or 'Withdrawn'.

Event type inferred
Recommended Optional

Extraction Guides

How to get your data from NetSuite