Data Template: Purchase to Pay - Purchase Order
Your Purchase to Pay - Purchase Order Data Template
- Recommended data attributes
- Key process activities
- Coupa data extraction steps
Purchase to Pay - Purchase Order Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity
ActivityName
|
The name of the specific event or task that occurred at a point in time within the purchase order lifecycle. | ||
|
Description
The Activity Name describes a single step in the purchase-to-pay process, such as 'Purchase Order Approved' or 'Goods Receipt Posted'. This sequence of activities forms the process flow for each purchase order. This attribute is fundamental to process mining, as it is used to construct the process map, discover process variants, and analyze the frequency and sequence of events. It helps identify bottlenecks, rework loops, and deviations from the standard process flow. For example, analyzing the sequence of 'Purchase Order Changed' activities can reveal inefficiencies in order accuracy.
Why it matters
It defines the steps in the process, allowing for the visualization of the process flow and the identification of bottlenecks, rework, and deviations.
Where to get
Derived from event logs, audit trails, or status change records associated with Purchase Order objects in Coupa.
Examples
Purchase Requisition ApprovedPurchase Order SubmittedGoods Receipt PostedInvoice Received for PO
|
|||
|
Purchase Order
PurchaseOrderNumber
|
The unique identifier for a purchase order, serving as the primary case identifier for the process. | ||
|
Description
The Purchase Order number is the central case identifier that connects all activities from its initial request to the final confirmation of goods or services receipt. Each unique Purchase Order Number represents a single instance of the procurement process. In process mining analysis, this attribute is crucial for tracing the end-to-end journey of each purchase. It allows analysts to visualize process maps, identify variants, and calculate case-level KPIs, such as the total cycle time for an order. All events and related data are aggregated under this identifier to build a cohesive view of the process.
Why it matters
It is essential for tracking the complete lifecycle of each purchase, enabling the reconstruction of individual process instances for detailed analysis.
Where to get
This is a standard primary key field on the Purchase Order object within Coupa.
Examples
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Start Time
EventTime
|
The exact timestamp indicating when an activity or event occurred. | ||
|
Description
Event Time records the date and time that a specific activity was executed. For every activity in the process, there is a corresponding timestamp that marks its occurrence. This attribute is critical for all time-based analysis in process mining. It is used to calculate cycle times between activities, measure process duration, and identify delays. For instance, the time difference between the 'Purchase Order Drafted' and 'Purchase Order Approved' timestamps is used to calculate the PO Approval Cycle Time KPI.
Why it matters
It provides the temporal context for each event, which is essential for calculating cycle times, analyzing performance, and detecting bottlenecks.
Where to get
Located in the event logs or audit trails of Coupa, typically associated with each status change or action taken on a purchase order.
Examples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp indicating the last time the data for this process was refreshed. | ||
|
Description
This attribute records when the dataset was last updated from the source system. It is a metadata field that applies to the entire dataset rather than individual events. In any analytical dashboard, this timestamp is vital for users to understand the freshness of the data they are viewing. It provides confidence that the insights are based on recent information and helps manage user expectations about data currency. It is typically displayed prominently in dashboards.
Why it matters
Informs users about the timeliness of the data, ensuring they understand how current the process analysis and KPIs are.
Where to get
This timestamp is generated and stored by the data extraction and loading (ETL) pipeline when it runs.
Examples
2023-11-01T05:00:00Z
|
|||
|
Source System
SourceSystem
|
The system from which the process data was extracted. | ||
|
Description
This attribute identifies the originating information system where the event data was recorded. For this process, the value would consistently be 'Coupa'. In enterprise environments where data may come from multiple systems (e.g., Coupa for procurement, another ERP for invoicing), this attribute helps differentiate data sources. It ensures clarity in data lineage and can be used to filter analysis for a specific system's view of the process.
Why it matters
It provides crucial context about data origin, ensuring traceability and enabling proper data governance, especially in multi-system landscapes.
Where to get
This is a static value that is typically added during the data extraction and transformation process to label the dataset.
Examples
Coupa
|
|||
|
Department
Department
|
The business department or cost center to which the purchase order is charged. | ||
|
Description
The Department attribute specifies the organizational unit that initiated the purchase or will bear its cost. This is often linked to the requester or the cost center information on the purchase order line items. This dimension is essential for segmenting process analysis and KPIs. It allows managers to compare process efficiency, compliance, and spending patterns across different parts of the organization. For example, the 'Spend Analysis by Purchase Category' dashboard uses Department to show how different business units are spending their budgets.
Why it matters
It allows for process and spend analysis to be filtered and compared across different business units, revealing variations in efficiency and compliance.
Where to get
Available on the Purchase Order header or line items in Coupa, often linked to a Cost Center or organizational unit.
Examples
MarketingInformation TechnologyOperationsFinance
|
|||
|
Purchase Category
PurchaseCategory
|
The classification of the goods or services being purchased, such as IT Hardware or Professional Services. | ||
|
Description
Purchase Category, also known as Commodity or Material Group, is a classification used to group similar types of purchases. This structured data allows for systematic analysis of spending and procurement processes. In process mining, this attribute is a powerful dimension for filtering and segmentation. The 'Spend Analysis by Purchase Category' dashboard relies on it to break down spending patterns. It can also reveal if certain categories (e.g., complex services) have longer cycle times or higher change rates than others (e.g., standard office supplies).
Why it matters
It enables spend and process analysis by category, helping to identify procurement patterns, negotiate with vendors, and tailor process controls.
Where to get
Typically found at the Purchase Order line item level in Coupa, often linked to a commodity code or purchasing catalog.
Examples
IT HardwareOffice SuppliesProfessional ServicesMarketing Materials
|
|||
|
Total Order Amount
TotalOrderAmount
|
The total monetary value of the purchase order. | ||
|
Description
This attribute represents the total cost of all goods and services specified in the purchase order, expressed in a specific currency. It is a case-level attribute that applies to the entire order. This financial data is crucial for spend analysis and for prioritizing process improvement efforts. High-value orders may warrant more scrutiny or different approval paths. It is used directly in the 'Spend Analysis by Purchase Category' dashboard and is a component for calculating the 'Spend by Non-Preferred Vendor Ratio' KPI.
Why it matters
Provides the financial context for each purchase, enabling spend analysis, prioritization of high-value orders, and assessment of financial impact.
Where to get
Available on the Purchase Order header in Coupa, typically as 'Total' or 'Grand Total'.
Examples
1500.00250.7512500.50
|
|||
|
User
User
|
The user ID or name of the person who performed the activity, such as an approver or requester. | ||
|
Description
This attribute identifies the individual responsible for executing a specific event in the process. This could be the person who drafted the order, the manager who approved it, or the clerk who posted the goods receipt. Analyzing performance by user helps identify training needs, high-performing individuals, and workload distribution. For example, the 'PO Approval Cycle Time Performance' dashboard uses this attribute to break down approval times by specific approvers, highlighting who may be a bottleneck in the process.
Why it matters
It enables analysis of process performance by individual or role, helping to identify bottlenecks, training opportunities, and resource allocation issues.
Where to get
Associated with each event in the Purchase Order audit trail or history logs in Coupa. Fields like 'Created By', 'Approved By', or 'Updated By' are common sources.
Examples
j.doea.smithm.jones
|
|||
|
Vendor Name
VendorName
|
The name of the supplier or vendor from whom goods or services are being purchased. | ||
|
Description
The Vendor Name identifies the external party supplying the items on the purchase order. This information is fundamental to procurement analytics. Analyzing process performance by vendor is critical for supplier relationship management. It helps in evaluating 'Supplier Lead Time Performance', identifying delays in 'Goods Receipt Process Delays', and assessing supplier quality through 'Goods Return Rate'. This attribute is also key for calculating the 'Spend by Non-Preferred Vendor Ratio' KPI.
Why it matters
Enables supplier performance analysis, helping to optimize supplier selection, negotiate better terms, and identify high- or low-performing vendors.
Where to get
A standard field on the Purchase Order header in Coupa, linked to the Supplier Master Data.
Examples
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Change Reason
ChangeReason
|
The reason provided for a change made to a purchase order after its initial creation. | ||
|
Description
This attribute captures the justification for why a purchase order was modified, for example, 'Quantity updated' or 'Price correction'. This information is often recorded in the audit trail when a user executes a 'Purchase Order Changed' activity. Understanding why orders are changed is key to the 'Purchase Order Change Analysis' dashboard. It helps differentiate between unavoidable changes (e.g., vendor stock issues) and preventable ones (e.g., incorrect initial data entry), guiding efforts to improve order accuracy and reduce the 'Purchase Order Change Rate' KPI.
Why it matters
Explains the root causes of PO changes, enabling targeted actions to improve first-time order accuracy and reduce process rework.
Where to get
Often found in the audit logs or comments associated with the change events for a Purchase Order in Coupa.
Examples
Price update from vendorDelivery date adjustedCorrected item code
|
|||
|
Currency
Currency
|
The currency code for the monetary values on the purchase order. | ||
|
Description
This attribute specifies the currency (e.g., USD, EUR, GBP) in which the Total Order Amount is denominated. It is essential for correctly interpreting financial data in a global organization. For multinational companies, analyzing spend without considering currency can be misleading. This attribute allows for proper currency conversion and consistent financial reporting within dashboards, ensuring that values are compared on a like-for-like basis.
Why it matters
Ensures accurate financial analysis and reporting in multinational contexts by providing the necessary information for currency conversion.
Where to get
A standard field on the Purchase Order header in Coupa.
Examples
USDEURGBPJPY
|
|||
|
Is Delivery On Time
IsDeliveryOnTime
|
A calculated flag indicating if the goods were received on or before the requested delivery date. | ||
|
Description
This boolean attribute is calculated by comparing the timestamp of the 'Goods Receipt Posted' event with the 'RequestedDeliveryDate'. It is set to true if the receipt date is on or before the requested date. This flag directly supports the 'Supplier Delivery Date Adherence' KPI and the 'Delivery Date Variance and Returns' dashboard. It provides a clear, binary outcome for on-time performance that is easy to aggregate and visualize, helping to quickly identify performance issues with vendors or internal receiving processes.
Why it matters
Provides a clear, binary metric for delivery performance, simplifying the calculation of on-time delivery KPIs and trend analysis.
Where to get
Calculated during data transformation by comparing 'RequestedDeliveryDate' with the timestamp of the 'Goods Receipt Posted' activity.
Examples
truefalse
|
|||
|
Is First Pass Approval
IsFirstPassApproval
|
A calculated flag that is true if the PO was approved without any changes after being drafted. | ||
|
Description
This boolean flag is set to true if a purchase order's journey from 'Purchase Order Drafted' to 'Purchase Order Approved' does not contain any 'Purchase Order Changed' or 'Purchase Order Rejected' activities in between. This attribute directly measures the 'First-Pass PO Approval Rate' KPI. A high rate indicates efficient and accurate initial processing. Analyzing the cases where this flag is false can help uncover reasons for rework and improve the upfront data quality of purchase orders.
Why it matters
Directly measures the efficiency of the initial creation and approval process, highlighting the volume of orders that flow through without rework.
Where to get
Calculated during data transformation by analyzing the sequence of events for each PurchaseOrderNumber.
Examples
truefalse
|
|||
|
Is Preferred Vendor
IsPreferredVendor
|
A boolean flag indicating if the purchase was made from a preferred or strategic vendor. | ||
|
Description
This flag identifies whether the vendor on the purchase order is part of a pre-approved list of strategic suppliers. This is typically determined by cross-referencing the vendor name or ID with a master list of preferred vendors. This attribute is essential for strategic sourcing and spend management initiatives. It is used to calculate the 'Spend by Non-Preferred Vendor Ratio' KPI, which helps organizations monitor and control maverick buying and consolidate spend with key partners to leverage volume discounts and better terms.
Why it matters
Helps monitor procurement policy compliance and strategic sourcing goals by tracking spend with preferred versus non-preferred suppliers.
Where to get
This is often not a standard field in Coupa but is derived by comparing the Vendor ID on the PO with an external list of preferred vendors.
Examples
truefalse
|
|||
|
Is Rework
IsRework
|
A calculated flag that identifies if a purchase order has undergone a change activity. | ||
|
Description
This boolean flag is set to true for any purchase order that has at least one 'Purchase Order Changed' event in its history. It is a case-level attribute derived from the event log. This attribute simplifies the calculation of KPIs like the 'Purchase Order Change Rate'. It allows for easy filtering and segmentation of the data to compare processes for orders with and without rework, helping to quantify the impact of changes on cycle time and cost. It is a core component of the 'Purchase Order Change Analysis' dashboard.
Why it matters
Simplifies the analysis of rework by allowing easy filtering and aggregation for all purchase orders that have been changed at least once.
Where to get
Calculated during data transformation by checking for the existence of a 'Purchase Order Changed' activity for each PurchaseOrderNumber.
Examples
truefalse
|
|||
|
Processing Time
ProcessingTime
|
The duration of an activity, representing the time a user actively worked on a task. | ||
|
Description
Processing time, sometimes called 'service time', is the time spent actively working on a task. It is distinct from waiting time. For example, it could measure the time between when a user opens a PO approval task and when they submit the approval. This metric provides a more accurate view of user effort compared to cycle time, which includes waiting periods. Analyzing processing time helps in capacity planning, workload balancing, and identifying tasks that are inherently time-consuming. It requires both a start and end time for a single activity, which is not always available.
Why it matters
Helps distinguish between active work time and waiting time, providing better insights into resource efficiency and task complexity.
Where to get
Calculated if both start and end timestamps for a single activity are available in the Coupa audit logs. This is often not standard.
Examples
3600120900
|
|||
|
Purchase Requisition Number
PurchaseRequisitionNumber
|
The unique identifier for the purchase requisition that preceded the purchase order. | ||
|
Description
This attribute links a purchase order back to its originating purchase requisition. A single requisition may lead to one or more purchase orders. This linkage is essential for analyzing the full 'Requisition-to-Order' cycle time. By connecting the requisition's creation event with the purchase order's creation and sending events, organizations can measure the efficiency of their entire procurement initiation process, from request to fulfillment.
Why it matters
It connects the request and ordering phases of the process, enabling the analysis of the requisition-to-order cycle time and conversion rates.
Where to get
This is typically a reference field on the Purchase Order line items in Coupa, linking back to the source requisition.
Examples
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
Receiving Location
ReceivingLocation
|
The physical location, such as a warehouse or office, where the goods are to be delivered. | ||
|
Description
The Receiving Location specifies the destination for the goods ordered on the PO. This could be a specific warehouse, plant, or office address. This attribute is used to analyze logistics and receiving performance across different sites. The 'Goods Receipt Process Delays' dashboard can be filtered by this attribute to determine if certain locations are slower at processing incoming shipments, which can help pinpoint operational inefficiencies or resource constraints at specific sites.
Why it matters
Allows for location-based analysis of the receiving process, highlighting performance differences between warehouses, plants, or offices.
Where to get
This information is part of the 'Ship-To' address on the Purchase Order in Coupa.
Examples
Warehouse A - ChicagoBuilding 5 - London OfficeFrankfurt Plant
|
|||
|
Rejection Reason
RejectionReason
|
The reason provided when a purchase requisition or purchase order is rejected during an approval step. | ||
|
Description
When an approver rejects a purchase order, they often provide a reason for the rejection. This attribute captures that textual explanation, such as 'Incorrect budget code' or 'Exceeds spending limit'. Analyzing rejection reasons provides direct insight into the root causes of rework and process failures. This qualitative data can be used to identify common errors in the requisitioning process, leading to targeted training or system improvements to prevent future rejections and improve the first-pass approval rate.
Why it matters
Provides direct, actionable insights into why purchase orders are rejected, helping to address root causes of process rework and delays.
Where to get
Typically captured in the comments or notes field associated with the 'Purchase Order Rejected' or 'Purchase Requisition Rejected' activity in Coupa's approval workflow.
Examples
Duplicate requestBudget not approvedIncorrect vendor selected
|
|||
|
Requested Delivery Date
RequestedDeliveryDate
|
The date on which the requester has asked for the goods or services to be delivered. | ||
|
Description
This attribute is the target delivery date specified by the business user during the requisition process. It represents the business's expectation for when the order should be fulfilled. This date is a critical benchmark for measuring supplier and internal performance. It is directly used to calculate the 'Supplier Delivery Date Adherence' KPI by comparing it to the actual 'Goods Receipt Posted' date. The 'Delivery Date Variance and Returns' dashboard visualizes deviations between this requested date and the actual delivery, helping to manage expectations and improve forecasting.
Why it matters
Serves as a key performance baseline for measuring on-time delivery from vendors and the efficiency of the internal receiving process.
Where to get
A standard field on the Purchase Order line item in Coupa.
Examples
2023-11-152023-12-012024-01-10
|
|||
|
Requester Name
RequesterName
|
The name of the individual who initially requested the goods or services. | ||
|
Description
This attribute identifies the employee who created the purchase requisition that led to the purchase order. The requester is the business user with the need, who may be different from the buyer or approver. Analyzing process behavior by requester helps identify patterns related to specific users or departments. The 'Purchase Order Change Analysis' dashboard uses this to see if certain requesters have a higher frequency of order changes, which could indicate a need for better training on specification requirements.
Why it matters
Helps identify the business origin of a purchase, enabling analysis of procurement behavior and accuracy at the requester level.
Where to get
This information is usually stored on the source Purchase Requisition and carried over to the Purchase Order in Coupa.
Examples
Alice CooperBob DylanCharlie Parker
|
|||
Purchase to Pay - Purchase Order Activities
| Activity | Description | ||
|---|---|---|---|
|
Goods Receipt Posted
|
This is the formal confirmation that goods have been received, inspected, and accepted. This event updates inventory records and signals that the vendor's obligation for this delivery has been met. | ||
|
Why it matters
This critical milestone marks the end of the supplier lead time and is used to measure delivery date adherence. Delays in posting receipts can obscure visibility into actual inventory levels.
Where to get
This is a core transaction in Coupa, recorded on the Receipt object. The event is captured from the timestamp when the receipt's status becomes 'Posted' or 'Received'.
Capture
Logged when the goods receipt transaction is finalized in the system.
Event type
explicit
|
|||
|
Purchase Order Approved
|
This milestone signifies that the purchase order has completed its internal approval workflow and is authorized for issuance to the vendor. This is typically the final approval step in a multi-step process. | ||
|
Why it matters
This is a critical milestone for calculating PO approval cycle times and identifying approval bottlenecks. It also serves as a key compliance checkpoint.
Where to get
Captured from the Purchase Order's approval history log in Coupa. The timestamp of the final approval action provides the event time.
Capture
Logged in the approval history when the final approver completes their task.
Event type
explicit
|
|||
|
Purchase Order Canceled
|
This activity represents the cancellation of a purchase order before it was completed. A cancellation can occur at various stages, for example, if the request is no longer valid or if the PO was created in error. | ||
|
Why it matters
As an alternative process ending, tracking cancellations is important for understanding process fallout and identifying reasons for abandoned purchase requests.
Where to get
This is inferred from a status change on the Purchase Order object to 'Canceled'. The timestamp of this status change is used as the event time.
Capture
Derived from the timestamp of the status change to 'Canceled'.
Event type
inferred
|
|||
|
Purchase Order Closed
|
This is the final activity, signifying that the purchase order is complete. The PO is considered closed when it has been fully received and fully invoiced, and no further transactions are expected. | ||
|
Why it matters
This activity officially ends the PO lifecycle. Analyzing the time to close can reveal inefficiencies in final reconciliation and record-keeping.
Where to get
This is inferred from a status change on the Purchase Order object to 'Closed'. This status is often set automatically by Coupa based on business rules regarding receiving and invoicing tolerances.
Capture
Derived from the timestamp of the status change to 'Closed'.
Event type
inferred
|
|||
|
Purchase Order Sent to Vendor
|
This activity marks the point when the approved purchase order is officially transmitted to the vendor, for example, via email or through the Coupa Supplier Portal. This event transitions the PO from an internal document to an external commitment. | ||
|
Why it matters
This is a key milestone that concludes the internal Requisition-to-Order cycle and begins the supplier lead time. It is vital for measuring both internal efficiency and supplier performance.
Where to get
Often inferred from a status change on the PO to 'Ordered' or 'Sent'. Coupa may also have a specific 'last_exported_at' or 'sent_to_supplier_at' timestamp on the PO record.
Capture
Derived from the timestamp of the status change to 'Ordered' or a specific transmission timestamp field.
Event type
inferred
|
|||
|
Purchase Requisition Created
|
This activity marks the creation of a purchase requisition, which is the formal request for goods or services that precedes a purchase order. In Coupa, this is an explicit event captured when a user saves and submits a new requisition document. | ||
|
Why it matters
As the typical starting point of the procurement process, this activity is essential for measuring the full Requisition-to-Order cycle time and understanding upstream process efficiency.
Where to get
This event corresponds to the creation record in the Purchase Requisitions object or table in Coupa. The timestamp can be found in the 'created_at' or equivalent system-generated creation date field.
Capture
Directly logged upon creation of a new requisition record.
Event type
explicit
|
|||
|
Goods Receipt Initiated
|
This activity represents the start of the receiving process, such as when a receipt document is created in Coupa upon the physical arrival of goods. The goods have not yet been formally posted to inventory or confirmed as received. | ||
|
Why it matters
This event is the starting point for measuring the Goods Receipt Processing Time KPI. It helps differentiate between the time goods are waiting on the dock and the time spent on system processing.
Where to get
This can be inferred from the creation timestamp of a receipt document that is in a 'Draft' or 'Pending' status. It precedes the final posting of the receipt.
Capture
Derived from the creation timestamp of a receipt record in a non-posted state.
Event type
inferred
|
|||
|
Goods Returned
|
This activity is recorded when previously received goods are sent back to the vendor. This is typically due to quality issues, damage, or incorrect shipments. | ||
|
Why it matters
Tracking returns is essential for calculating the Goods Return Rate and identifying problems with supplier quality or order accuracy. High return rates often indicate costly process failures.
Where to get
This is captured from a 'Return to Supplier' transaction or a negative receipt transaction in Coupa. The timestamp of this transaction serves as the event time.
Capture
Logged when a return transaction linked to the original PO/receipt is created.
Event type
explicit
|
|||
|
Invoice Received for PO
|
This event marks the receipt and entry of a supplier's invoice that references the purchase order. It signifies the start of the invoice processing and payment phase of the P2P cycle. | ||
|
Why it matters
While part of the AP process, linking the invoice receipt to the PO provides an end-to-end view of the transaction lifecycle and helps analyze the gap between delivery and invoicing.
Where to get
Captured from the creation timestamp of the Invoice document in Coupa, where the invoice is matched against the corresponding Purchase Order number.
Capture
Logged upon creation of an invoice record linked to the PO.
Event type
explicit
|
|||
|
Purchase Order Changed
|
This event represents any modification made to the purchase order after it was initially drafted. In Coupa, changes are often tracked through versioning of the PO document. | ||
|
Why it matters
Tracking changes is crucial for KPIs like the Purchase Order Change Rate and Non-Conforming PO Rate. Frequent changes indicate process instability or inaccurate initial requests.
Where to get
Can be inferred by tracking different versions of a Purchase Order. Each new version number greater than the first indicates a change, with the creation date of the new version serving as the event timestamp.
Capture
Inferred from the creation timestamp of a new PO version.
Event type
inferred
|
|||
|
Purchase Order Drafted
|
This event represents the initial creation of the Purchase Order document in the system, often from an approved requisition. At this stage, the PO is an internal draft and has not yet been submitted for approval or sent to the vendor. | ||
|
Why it matters
This activity starts the clock for measuring the PO Approval Cycle Time KPI. It is the first formal step in the purchase order's own lifecycle.
Where to get
This corresponds to the creation timestamp of the Purchase Order record in Coupa, which is typically found in a field like 'created_at'.
Capture
Captured from the system-generated creation timestamp of the PO record.
Event type
explicit
|
|||
|
Purchase Order Rejected
|
This activity occurs when an approver rejects the purchase order during the approval workflow. The PO is then typically sent back to the creator for revision or cancellation. | ||
|
Why it matters
Analyzing rejections helps uncover issues with data quality, policy violations, or training gaps. It highlights rework loops that cause significant process delays.
Where to get
This is an explicit event captured in the Purchase Order's approval history log in Coupa. The log will show a 'Reject' action with a corresponding timestamp.
Capture
Logged in the approval history with a 'Reject' status.
Event type
explicit
|
|||
|
Purchase Order Submitted
|
After a purchase order is drafted, it is formally submitted into the approval workflow. This is a distinct user action that moves the PO from a draft state to a pending approval state. | ||
|
Why it matters
This event distinguishes the drafting time from the time the PO is actually awaiting approval. It provides a clearer picture of user behavior and process handoffs.
Where to get
Inferred from a status change on the Purchase Order object, for example from 'draft' to 'pending approval'. The timestamp of this specific status change is used.
Capture
Derived from the timestamp of the status change to 'pending approval'.
Event type
inferred
|
|||
|
Purchase Requisition Approved
|
A purchase requisition undergoes an approval workflow before it can be converted into a purchase order. This event signifies the final approval of the requisition, making it ready for ordering. | ||
|
Why it matters
Tracking requisition approvals helps identify bottlenecks in the pre-ordering phase. Delays here directly impact how quickly a purchase order can be issued.
Where to get
This is typically captured from the approval history of the requisition object in Coupa. The final approval action will have a corresponding timestamp and user.
Capture
Logged in the approval history when the final approver takes action.
Event type
explicit
|
|||
|
Quality Inspection Performed
|
This event indicates that a received item has undergone and passed a quality inspection. This may be a separate step after the initial goods receipt is posted, depending on the company's process. | ||
|
Why it matters
This activity is key to measuring the efficiency of the quality control process. Delays here can create bottlenecks between receiving and availability for use.
Where to get
This may be recorded as a status change on the receipt line item or through a separate inspection object in Coupa. Its availability depends on whether the quality module or a custom workflow is used.
Capture
Inferred from a status change on the receipt or a timestamp on a related inspection record.
Event type
inferred
|
|||
|
Services Confirmation Entered
|
For services-based purchase orders, this activity is the equivalent of a goods receipt. It confirms that a service has been rendered according to the terms of the PO. | ||
|
Why it matters
Tracking service confirmations is crucial for managing spend on services and ensuring that payments are only made for work that has been verified as complete.
Where to get
This event is captured from the creation or approval of a service receipt or service entry sheet linked to the Purchase Order in Coupa.
Capture
Logged upon the creation and approval of a service entry sheet.
Event type
explicit
|
|||
|
Vendor Acknowledged Order
|
This event signifies that the vendor has received and confirmed the purchase order. This confirmation is often captured electronically through a supplier portal like the Coupa Supplier Portal (CSP). | ||
|
Why it matters
Vendor acknowledgments provide certainty that an order is being processed, improving the accuracy of delivery forecasting and reducing supply chain uncertainty.
Where to get
This information is typically available on the Purchase Order if the vendor uses the Coupa Supplier Portal to perform an 'Acknowledge' action. The timestamp of this action is used.
Capture
Logged when a vendor performs the 'Acknowledge' action in the supplier portal.
Event type
explicit
|
|||