Data Template: Order to Cash - Sales Order Processing

SAP ECC
Data Template: Order to Cash - Sales Order Processing

Your Order to Cash - Sales Order Processing Data Template

This template provides a clear roadmap for collecting the essential data required to analyze your Order to Cash - Sales Order Processing in SAP ECC. It outlines the crucial attributes to collect, the key activities to track, and offers practical guidance for data extraction. Use this resource to ensure you gather all necessary information for comprehensive process analysis.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance for SAP ECC

Order to Cash - Sales Order Processing Attributes

These are the recommended data fields to include in your event log for comprehensive Order to Cash - Sales Order Processing analysis.
5 Required 8 Recommended 5 Optional
NameDescription
Sales Order
SalesOrder
The unique identifier for a sales order document, which serves as the primary case for tracking the entire Order-to-Cash process.
Description

The Sales Order is the central document in the sales process, representing a customer's request for goods or services. It contains all the information needed to process the customer's request from start to finish.

In process mining, this attribute is used as the Case ID. Each unique Sales Order number represents one end-to-end process instance. Analyzing processes by Sales Order allows for tracking the complete lifecycle, measuring cycle times, and identifying variations for each individual customer order.

Why it matters

It is the essential key to link all related activities and events, enabling a complete end-to-end analysis of each customer order's journey.

Where to get

Found in the Sales Document Header Data table (VBAK) as the field VBELN.

Examples
900001234590000123469000012347
Activity
Activity
The name of a specific business step or event that occurred within the sales order process.
Description

This attribute describes a single step in the Order-to-Cash process, such as 'Sales Order Created', 'Delivery Created', or 'Payment Received'. These activities are the building blocks used to reconstruct the process flow for each sales order.

Analyzing the sequence and timing of these activities is the core of process mining. It helps to visualize the process map, identify bottlenecks, discover process variants, and check for compliance against a standard model. Activities are typically derived from a combination of document creation events, status changes, or specific transaction codes recorded in the system.

Why it matters

Activities form the backbone of the process map, allowing for visualization and analysis of the process flow, deviations, and bottlenecks.

Where to get

This is a derived attribute, typically generated during data extraction by mapping SAP transaction codes (T-Codes), document status changes (e.g., from tables VBUK, VBUP), or change document logs (tables CDHDR, CDPOS) to user-friendly activity names.

Examples
Sales Order CreatedDelivery CreatedGoods IssuedInvoice CreatedPayment Received
Last Data Update
LastDataUpdate
Timestamp indicating when the data for this record was last refreshed from the source system.
Description

This attribute records the date and time of the most recent data extraction or update for a given event or case. It provides transparency into the freshness of the data being analyzed.

In dashboards and reports, this information is crucial for users to understand the timeliness of the insights. It helps confirm if the analysis reflects the most current state of operations or if it is based on older data, managing user expectations about the data's recency.

Why it matters

Ensures users are aware of the data's freshness, which is critical for making timely and informed decisions based on the process mining analysis.

Where to get

This is a metadata attribute populated by the data extraction tool or process at the time of data ingestion. It is not stored in the source SAP tables.

Examples
2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z
Source System
SourceSystem
Identifies the source system from which the data was extracted.
Description

This attribute specifies the originating system, for example, a specific SAP ECC instance name or client number. It provides context for the data, especially in environments with multiple production systems or data from legacy systems.

In analysis, it's used to filter or segment data based on its origin. This is particularly useful for comparing processes across different systems or during system migration projects to ensure data integrity and consistency.

Why it matters

Provides essential context, especially in multi-system landscapes, allowing for process comparison and ensuring data lineage is clear.

Where to get

This value is typically added during the data extraction process and is often a static value representing the SAP System ID (SAPSID) or client (MANDT).

Examples
ECC_PROD_800SAP_ERP_EU1ECC_QAS_300
Start Time
StartTime
The timestamp indicating when an activity or event began.
Description

The Start Time, also known as the event timestamp, records the precise date and time that a specific activity occurred. For example, it would capture when a sales order was created, when goods were issued, or when an invoice was posted.

This timestamp is fundamental for all time-based analysis in process mining. It is used to calculate cycle times between activities, measure the total duration of a case, and identify delays or bottlenecks. Accurate timestamps are critical for performance analysis dashboards, such as those monitoring on-time delivery or fulfillment lead times.

Why it matters

This is a critical attribute for calculating all performance metrics, such as cycle times and durations, which are essential for identifying bottlenecks.

Where to get

This is a composite attribute, typically derived by combining a date field (e.g., ERDAT) and a time field (e.g., ERZET) from various SAP tables like VBAK (Sales Order), LIKP (Delivery), and VBRK (Invoice).

Examples
2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z
Customer Number
CustomerNumber
The unique identifier for the customer who placed the sales order.
Description

This attribute represents the 'Sold-to Party', the primary customer account associated with the sales order. It links the transaction to a specific customer in the master data.

Analyzing by customer number allows for segmenting the process to understand customer-specific behaviors and performance. It helps answer questions like which customers have the longest cycle times, highest rework rates, or most frequent order changes. This is crucial for improving customer relationship management and service levels.

Why it matters

Enables customer-centric analysis, helping to identify process issues affecting specific customers and to measure customer-specific performance.

Where to get

Found in the Sales Document Header Data table (VBAK) as the field KUNNR.

Examples
100234100567200112
Delivery Block
DeliveryBlock
A code indicating if a sales order is blocked for delivery, preventing the creation of a delivery document.
Description

The Delivery Block is a status set on a sales order (at header or item level) to temporarily halt the process before the delivery step. Blocks can be set manually by a user or automatically by the system due to reasons like credit limit failure or incomplete data.

This attribute is critical for the 'Sales Order Blockage and Rework Analysis' dashboard. Analyzing the frequency, duration, and reasons for delivery blocks helps identify major bottlenecks in the fulfillment process. Reducing these blocks is key to improving on-time delivery and overall cycle time.

Why it matters

Directly identifies bottlenecks in the fulfillment process. Analyzing why and how often orders are blocked is crucial for improving flow efficiency.

Where to get

Found in the Sales Document Header Data table (VBAK) as the field LIFSK.

Examples
0102Z1
Material Number
MaterialNumber
The unique identifier for a product or service being sold.
Description

The Material Number identifies the specific item on a sales order line. Since a single sales order can contain multiple materials, this attribute is typically analyzed at the item level.

Analyzing the process by Material Number helps uncover product-specific issues. It can reveal if certain products are associated with longer fulfillment times, higher rates of delivery blocks, or more frequent invoice discrepancies. This is crucial for supply chain and product management to optimize the process for different product lines.

Why it matters

Allows for product-based process analysis, revealing which products are associated with process inefficiencies like delays, blocks, or rework.

Where to get

Found in the Sales Document Item Data table (VBAP) as the field MATNR.

Examples
FG-1001-ARAW-205BSERV-INSTALL
Net Amount
NetAmount
The total value of the sales order, excluding taxes and discounts at the header level.
Description

Net Amount represents the monetary value of the sales order. It is a key financial metric associated with each process instance.

This attribute is essential for value-based process mining. It allows for prioritizing process improvement initiatives by focusing on high-value orders. Analysts can correlate process issues, such as delays or rework, with financial impact, helping to build a stronger business case for change. For example, it can be used to analyze if high-value orders are processed more or less efficiently than low-value ones.

Why it matters

Enables value-based analysis, helping to prioritize improvement efforts on orders that have the most significant financial impact on the company.

Where to get

Found in the Sales Document Header Data table (VBAK) as the field NETWR.

Examples
1500.0012550.75850.50
Rejection Reason
RejectionReason
A code indicating the reason why a sales order item was rejected or cancelled.
Description

The Rejection Reason provides context for why a sales order or a specific line item was not fulfilled. This could be due to customer cancellation, product unavailability, or other business reasons.

This attribute is essential for the 'Sales Order Cancellation Trends' dashboard. By analyzing the most common rejection reasons, a business can identify root causes for lost sales. This insight can drive improvements in inventory management, pricing strategy, or customer communication to reduce the order cancellation rate.

Why it matters

Provides the 'why' behind order cancellations, enabling root cause analysis to reduce lost sales and improve forecast accuracy.

Where to get

Found in the Sales Document Item Data table (VBAP) as the field ABGRU.

Examples
0215Z5
Sales Order Cycle Time
SalesOrderCycleTime
The total duration from the creation of the sales order to its final closure or payment.
Description

This calculated metric measures the end-to-end processing time for a single sales order. It is typically calculated as the difference between the timestamp of the very first activity ('Sales Order Created') and the very last activity (e.g., 'Payment Received' or 'Order Item Closed').

This attribute is the primary measure for the 'Sales Order End-to-End Cycle Time' dashboard and the Sales Order Fulfillment Cycle Time KPI. It provides a high-level view of process efficiency and is a critical metric for identifying long-running orders and overall process health. Analyzing the distribution of this metric helps to set benchmarks and track the impact of improvement initiatives over time.

Why it matters

This is the primary KPI for measuring overall process velocity and efficiency, providing a critical baseline for improvement initiatives.

Where to get

This is a calculated metric derived from the event log by taking the difference between the maximum and minimum StartTime for a given SalesOrder.

Examples
10 days 4 hours25 days 11 hours5 days 2 hours
Sales Organization
SalesOrganization
The organizational unit responsible for the sale of products or services.
Description

A Sales Organization is a key organizational entity in SAP that structures the company according to its sales requirements. It is responsible for negotiating sales conditions and distributing goods and services.

In process mining, this attribute is a critical dimension for analysis. It allows for comparing process performance, efficiency, and compliance across different sales units, regions, or divisions. This helps identify best practices in high-performing organizations and areas for improvement in others.

Why it matters

Allows for organizational benchmarking, enabling comparison of process efficiency and compliance across different business units or regions.

Where to get

Found in the Sales Document Header Data table (VBAK) as the field VKORG.

Examples
100025003100
User
User
The user ID of the employee who created or last changed the document or performed the activity.
Description

This attribute captures the SAP user ID responsible for a particular event in the process. For example, it identifies the sales clerk who created the order or the warehouse staff who posted the goods issue.

Analyzing the process by user helps to understand workload distribution, identify training needs, and detect variations in how different users perform the same task. It is essential for dashboards focusing on resource performance, compliance, and identifying manual interventions.

Why it matters

Provides visibility into resource performance and workload, helps identify user-specific process deviations, and is key for compliance and automation analysis.

Where to get

Found in many SAP header tables as the 'Created by' field (ERNAM) or 'Changed by' field (AENAM), such as in VBAK, LIKP, VBRK.

Examples
CBURKEJSMITHRWILLIAMS
Confirmed Delivery Date
ConfirmedDeliveryDate
The date on which the delivery of the goods or services has been confirmed to the customer.
Description

This is the committed delivery date given to the customer, based on material availability and scheduling. It serves as the baseline for measuring delivery performance.

This attribute is the foundation for the 'On-Time Delivery Performance' dashboard and the On-Time Delivery Rate KPI. By comparing the Confirmed Delivery Date with the actual 'Goods Issued' date, the analysis can determine whether an order was delivered on time, early, or late. This is a primary measure of supply chain reliability and customer satisfaction.

Why it matters

This is the benchmark for measuring on-time delivery performance, a critical KPI for customer satisfaction and supply chain efficiency.

Where to get

Found in the Sales Document Schedule Line table (VBEP) as the field EDATU.

Examples
2023-05-102023-06-202023-07-01
Credit Check Status
CreditCheckStatus
Indicates the status of the credit check for the sales document.
Description

This attribute shows the outcome of the automated or manual credit check performed on a sales order. Common statuses include 'Approved', 'Rejected', or 'Blocked'.

This is a key attribute for the 'Credit Check Processing Time Analysis' dashboard. Delays or blocks at the credit check stage can significantly impact the overall order fulfillment cycle time. Analyzing this status helps to understand the efficiency of the credit management process and its impact on sales velocity.

Why it matters

Directly impacts order processing speed. Analyzing this status helps identify bottlenecks in credit management that delay order fulfillment.

Where to get

Found in the Sales Document Header Status table (VBUK) or directly in VBAK as the credit status field (e.g., CMGST).

Examples
ABD
Is On-Time Delivery
IsOnTimeDelivery
A boolean flag that indicates whether the goods were shipped on or before the confirmed delivery date.
Description

This calculated attribute compares the actual goods issue date with the 'ConfirmedDeliveryDate' for a sales order. If the goods issue date is on or before the confirmed date, it is marked as true, otherwise false.

This attribute simplifies the creation of the 'On-Time Delivery Performance' dashboard and the calculation of the On-Time Delivery Rate KPI. It allows for easy aggregation and visualization of performance without needing to perform date comparisons on the fly within every analysis or chart. This provides a clear, at-a-glance measure of delivery reliability.

Why it matters

Provides a clear and simple measure of delivery performance, making it easy to calculate the overall On-Time Delivery Rate KPI.

Where to get

This is a calculated attribute. The logic compares the timestamp of the 'Goods Issued' activity with the value from the 'ConfirmedDeliveryDate' attribute.

Examples
truefalse
Is Rework
IsRework
A boolean flag indicating if a sales order has undergone a significant change or rework activity after initial creation.
Description

This calculated attribute identifies process instances that have experienced rework, such as one or more 'Sales Order Changed' activities. The specific logic for what constitutes rework, for example, a change to price, quantity, or delivery date, is defined during the project setup.

This attribute is vital for the 'Sales Order Rework and Change Frequency' dashboard and the Sales Order Rework Rate KPI. It simplifies the analysis by allowing for direct filtering and comparison between orders that followed a 'straight-through' path versus those that required manual changes. This helps quantify the impact of rework on cycle times and costs.

Why it matters

Directly quantifies the frequency of rework, allowing for analysis of its causes and its impact on overall process efficiency and cycle time.

Where to get

This is a calculated attribute derived from the event log. The logic checks for the presence of 'Sales Order Changed' activities or specific change events from tables CDHDR/CDPOS.

Examples
truefalse
Shipping Conditions
ShippingConditions
Defines the general shipping strategy for the delivery of goods to the customer.
Description

Shipping Conditions determine how an order will be shipped, for example, 'Standard', 'Express', or 'Pickup'. This is agreed with the customer and influences logistics planning.

This attribute is used in the 'Shipping Method Efficiency & Cost' analysis. By segmenting the process by shipping conditions, companies can analyze if certain methods are more prone to delays or have longer cycle times. This data helps optimize logistics and manage customer expectations regarding delivery times.

Why it matters

Enables analysis of logistics performance, helping to determine if certain shipping methods correlate with delays or higher efficiency.

Where to get

Found in the Sales Document Header Data table (VBAK) as the field VSBED.

Examples
011020
Required Recommended Optional

Order to Cash - Sales Order Processing Activities

These are the key process steps and milestones to capture in your event log for accurate Order to Cash - Sales Order Processing discovery.
6 Recommended 8 Optional
ActivityDescription
Goods Issued
A critical event where ownership of the goods transfers and they officially leave the warehouse. This is an explicit financial posting that creates a material document and updates inventory.
Why it matters

This is the 'shipping' event and a key milestone for measuring on-time delivery and fulfillment lead times. It triggers financial updates and is a point of no return in the physical fulfillment process.

Where to get

Creation of a material document (MKPF/MSEG) with a goods issue movement type (e.g., 601), which is linked to the delivery document.

Capture

Creation of a material document (MKPF/MSEG) with a goods issue movement type, linked to the delivery.

Event type explicit
Invoice Created
Marks the creation of the customer invoice or billing document. This is an explicit event that generates a new document in the system, initiating the payment part of the process.
Why it matters

This is a crucial milestone that starts the clock on the 'Invoice to Payment Cycle Time'. Delays in invoicing directly impact cash flow.

Where to get

Recorded in the VBRK table (Billing Document: Header Data) based on its creation date (ERDAT). The link to the sales order or delivery is in the VBFA table.

Capture

Event based on creation timestamp (ERDAT) in VBRK table.

Event type explicit
Order Confirmed
This activity signifies that the sales order has passed all initial checks and is confirmed for fulfillment. It is typically inferred when the order is no longer blocked and has confirmed quantities in its schedule lines.
Why it matters

This is a major milestone that separates order entry from fulfillment. It is the starting point for measuring fulfillment lead times and on-time delivery performance.

Where to get

Can be inferred when schedule lines in VBEP have a confirmed quantity (BMENG > 0) and the order is not blocked for delivery (e.g., VBUK-LIFSK is empty).

Capture

Inferred from schedule line confirmation (VBEP-BMENG > 0) and removal of header-level blocks.

Event type inferred
Order Item Closed
This activity marks the final closure of a sales order item, indicating it is fully delivered, invoiced, and considered complete. This is inferred from the item's overall status.
Why it matters

Serves as the successful end event for the process. Analyzing when items close helps understand the end-to-end process duration and identify orders that remain open unnecessarily.

Where to get

Inferred from the overall status field in the VBUP table (Sales Document: Item Status) for the item. When VBUP-GBSTA is 'C' (Completely processed), the item is closed.

Capture

Inferred from item status (VBUP-GBSTA) changing to 'C' (Completely processed).

Event type inferred
Payment Received
This event signifies that the customer's payment has been received and applied to the invoice, clearing the open accounts receivable item. This is an accounting event, inferred from the clearing of a financial document.
Why it matters

This is the final step in realizing cash from the sale. It is the end point for measuring the 'Invoice to Payment Cycle Time' and overall 'Sales Order Fulfillment Cycle Time'.

Where to get

Inferred from the clearing document information in the BSEG table for the customer line item. When BSEG-AUGBL (Clearing Document) and BSEG-AUGDT (Clearing Date) are populated, payment is received.

Capture

Inferred from clearing date (AUGDT) population in the BSEG table for the AR line item.

Event type inferred
Sales Order Created
Marks the creation of a new sales order document. This is an explicit event captured when a user saves a new order, typically via transaction VA01 in SAP.
Why it matters

This is the primary start event for the Order-to-Cash process. Analyzing its timing is crucial for measuring overall cycle time and order intake rates.

Where to get

Recorded in the VBAK table (Sales Document Header Data) using the creation date (ERDAT) and time (ERZET). The transaction code is stored in VBAK-TCODE.

Capture

Event based on creation timestamp (ERDAT, ERZET) in VBAK table.

Event type explicit
Credit Check Performed
Indicates the completion of the automatic or manual credit check for the customer on the sales order. This is typically inferred from a change in the overall credit status of the document.
Why it matters

The credit check is often a critical bottleneck. Measuring the time taken for this step is essential for the 'Credit Check Processing Time Analysis' and for accelerating order processing.

Where to get

Inferred from the credit status fields in the VBUK table (Sales Document: Header Status). A change in VBUK-CMGST from blocked to released marks this activity.

Capture

Inferred from changes to the overall credit status field (VBUK-CMGST).

Event type inferred
Delivery Block Set
Represents an action where a delivery block is applied to the sales order, preventing the creation of a delivery document. This can be captured explicitly from change logs or inferred from status tables.
Why it matters

This activity directly relates to the 'Sales Order Blockage Rate' KPI. Identifying why and how often blocks are set helps uncover reasons for fulfillment delays.

Where to get

Can be found in change logs (CDHDR/CDPOS) for field VBAK-LIFSK. Alternatively, it's inferred by observing when the VBAK-LIFSK field is populated.

Capture

Event from change documents for field VBAK-LIFSK or VBAP-LIFSP.

Event type explicit
Delivery Created
This event marks the creation of the outbound delivery document, which is the instruction to the warehouse to begin picking and shipping activities. This is an explicit event captured from the document flow.
Why it matters

This is the first step in the physical fulfillment process. The time between order confirmation and delivery creation indicates how quickly the logistics process is initiated.

Where to get

The creation of a record in the LIKP table (SD Document: Delivery Header Data). The link to the sales order is maintained in the document flow table VBFA.

Capture

Event based on creation timestamp in LIKP table, linked via VBFA table.

Event type explicit
Invoice Cancelled
Represents the reversal of a previously created billing document. This is an explicit transaction that creates a new cancellation document to offset the original.
Why it matters

Tracking invoice cancellations helps identify issues with pricing, shipping discrepancies, or data errors. This supports the 'Invoice Discrepancy Rate' KPI.

Where to get

An explicit event captured by the creation of a cancellation billing document (VBRK-VBTYP = 'N' or 'O'). The original invoice is referenced in VBRK-SFAKN.

Capture

Creation of a cancellation document in VBRK, referencing the original invoice.

Event type explicit
Order Cancelled
Indicates that a sales order has been cancelled before fulfillment. This is typically captured by applying a 'reason for rejection' to all relevant items on the order.
Why it matters

This is a critical failure endpoint that directly supports the 'Order Cancellation Rate' KPI. Understanding when and why orders are cancelled provides insights into sales process issues.

Where to get

Inferred from the VBAP-ABGRU (Reason for rejection) field being populated for all active items on a sales order. The date of the change can be found in CDHDR/CDPOS.

Capture

Inferred by population of the 'Reason for Rejection' field (VBAP-ABGRU) on all items.

Event type inferred
Picking Completed
Signifies that all items for the delivery have been physically picked from the warehouse. If Warehouse Management (WM) is used, this can be inferred from the status of the Transfer Order.
Why it matters

Analyzing picking time helps optimize warehouse operations. Delays here directly impact the overall shipping timeline and fulfillment cycle.

Where to get

Inferred from the picking status of the delivery item in table LIPS-KOSTA changing to 'C' (fully picked). If WM is active, it can be inferred from Transfer Order confirmation (LTAK/LTAP tables).

Capture

Inferred from change in picking status (LIPS-KOSTA) or WM Transfer Order confirmation.

Event type inferred
Proof Of Delivery Confirmed
This activity represents the confirmation that the customer has received the goods. It is captured when the proof of delivery is recorded in the system, often updating the delivery document status.
Why it matters

This event provides the actual delivery date, which is essential for accurately measuring the 'On-Time Delivery Rate' against the promised date.

Where to get

Inferred from the proof of delivery status (VBUK-PODAT) being set to 'C' (Confirmed). The confirmation date is stored in VLPOD-PODAT. This is not always implemented.

Capture

Inferred from POD status update on the delivery (VBUK-PODAT) or VLPOD table entry.

Event type inferred
Sales Order Changed
Represents a modification made to an existing sales order after its initial creation. These changes are captured in dedicated change log tables (CDHDR, CDPOS) when fields like quantity, price, or dates are altered.
Why it matters

Tracking changes helps identify rework, process instability, and data quality issues. A high frequency of changes can indicate problems in the initial order entry process, leading to delays.

Where to get

Retrieved from change document tables CDHDR (header) and CDPOS (item) for OBJECTCLAS = 'VERKBELEG'. The timestamp and changed field can be identified.

Capture

Event from change document tables (CDHDR, CDPOS) for sales document objects.

Event type explicit
Recommended Optional

Extraction Guides

How to get your data from SAP ECC