Your Order to Cash - Sales Order Processing Data Template

The Sales Order number uniquely identifies each customer order throughout its lifecycle. It acts as the central thread connecting all related activities, from initial creation and confirmation to fulfillment, invoicing, and final payment.

In process mining, this attribute is essential for grouping all related events into a single case. Analyzing the process by Sales Order allows for a complete end-to-end view, enabling the calculation of total cycle times, identification of process variants for individual orders, and tracking the journey of an order through different departments and systems.

This is the Case ID. It links all process events together, making it possible to trace the end-to-end journey of a single customer order.

This identifier is typically found in the header table for sales orders in Oracle Fusion, such as DOO_HEADERS_ALL. Consult Oracle Fusion Financials documentation.

This attribute describes the step that was executed at a specific point in time for a sales order, such as 'Sales Order Created', 'Goods Shipped', or 'Payment Received'. The sequence of these activities forms the process flow for each case.

Analyzing the ActivityName is fundamental to process mining. It allows for the visualization of the process map, discovery of different process variants, and identification of bottlenecks where cases accumulate. It is the basis for calculating transition times between steps and understanding the operational sequence of the Order to Cash process.

This attribute defines the steps in the process map, allowing for the visualization and analysis of the process flow.

This is a derived attribute, constructed by mapping transaction statuses or event types from various Oracle Fusion tables (e.g., order status, shipment status, invoice status) to a standardized list of activity names.

This attribute provides the date and time for each activity in the process, establishing the chronological sequence of events. It is the temporal backbone of the process analysis, recording exactly when each step happened.

In process mining, the EventTime is critical for calculating cycle times, durations between activities, and overall case lead times. It enables performance analysis, bottleneck detection based on waiting times, and monitoring compliance with service level agreements (SLAs) related to timeliness. All time-based KPIs and dashboards rely on the accuracy of this attribute.

This timestamp is essential for ordering events chronologically and calculating all time-based metrics, such as cycle times and durations.

This is a derived attribute, sourced from various timestamp fields across different Oracle Fusion tables, such as order creation date, shipment date, invoice date, and payment date.

This attribute records the final delivery date, which marks the completion of the fulfillment part of the process. It is the actual outcome against which planned or requested dates are measured.

This date is compared against the RequestedDeliveryDate to calculate on-time delivery performance. It is a critical input for the 'On-Time Delivery Rate' KPI and the 'Delivery SLA' dashboard, providing a clear measure of logistics and supply chain effectiveness.

This is the actual outcome date used to calculate on-time delivery rates and assess fulfillment performance against customer requests.

Sourced from shipping and delivery transaction tables in Oracle Fusion. Consult Oracle Fusion Financials documentation.

This attribute identifies the legal name of the customer account associated with the sales order. It is a key dimension for segmenting and analyzing the process from a customer-centric view.

Analyzing by customer helps identify if certain customers experience longer cycle times, more rework, or specific process deviations. This insight can be used to improve customer service, tailor processes for key accounts, and investigate issues affecting customer satisfaction.

Enables customer-centric analysis to identify process issues affecting specific customers and improve customer satisfaction.

Sourced from customer master data tables (e.g., HZ_PARTIES) and linked to the sales order via a customer ID.

This boolean attribute distinguishes between system-driven events (e.g., automated credit check, system-generated invoice) and manual user actions. It is typically derived based on the user name associated with an activity, where a generic system ID indicates automation.

Analyzing this attribute helps in measuring the level of automation in the process and is a direct input for the 'Manual Reworked Orders Percentage' KPI. It can highlight opportunities for further automation by showing which manual steps are most time-consuming or error-prone.

Helps quantify the level of automation in the process and identify opportunities to reduce costly manual interventions.

This is a derived field, often based on a rule applied to the UserName attribute. For example, if the user is 'SYSTEM' or 'BATCH', this flag is set to true.

The Payment Due Date is calculated based on the invoice date and the payment terms agreed upon with the customer. It sets the deadline for timely payment collection.

This attribute is crucial for the 'On-Time Payment Collection Rate' KPI. By comparing the PaymentDueDate with the actual payment receipt date, the system can determine if a payment was on-time or late, helping to monitor accounts receivable performance and manage cash flow.

Serves as the deadline for calculating on-time payment rates, which is a key measure of cash flow efficiency.

Found in accounts receivable or invoice tables within Oracle Fusion, such as AR_PAYMENT_SCHEDULES_ALL.

This attribute captures the date on which the customer wishes to receive the goods. It serves as a key performance target for the fulfillment part of the Order to Cash process.

This date is essential for calculating the 'On-Time Delivery Rate' KPI and supporting the 'Delivery Service Level Agreement (SLA)' dashboard. By comparing this date with the ActualDeliveryDate, the organization can measure its ability to meet customer expectations and identify the root causes of delivery delays.

Acts as the baseline for measuring on-time delivery performance and customer service level agreement (SLA) compliance.

Typically located in the sales order line item tables in Oracle Fusion. Consult Oracle Fusion Financials documentation.

This attribute categorizes the origin of the sales order, such as 'Web', 'Direct Sales', 'Partner', or 'EDI'. It provides context on how the order entered the organization.

Segmenting the process by sales channel is critical for the 'Sales Channel Performance Overview' dashboard. It helps in comparing the efficiency, cycle times, and error rates of different channels to identify which ones are most effective and which may require process improvements or further automation.

Supports performance analysis by channel, helping to identify the most and least efficient channels for order processing.

This information may be stored in a dedicated field on the sales order header. Consult Oracle Fusion Financials documentation.

This attribute represents the total amount charged to the customer for the entire sales order. It includes the sum of all line items, taxes, and other charges, before any discounts are applied.

In process analysis, this attribute is crucial for value-based process mining. It allows for segmenting orders by value (e.g., high-value vs. low-value orders) to see if they follow different process paths or have different cycle times. It also helps prioritize process improvement efforts on the most financially significant cases.

Allows for financial impact analysis, helping to prioritize process improvements on high-value orders and understand cost drivers.

Typically found in sales order header tables in Oracle Fusion. Consult Oracle Fusion Financials documentation.

This attribute identifies the employee or system user responsible for executing a specific process step. It can be used to analyze user-level performance, workload distribution, and adherence to standard procedures.

Analyzing by user helps in identifying training needs, recognizing high-performing individuals or teams, and investigating deviations caused by specific users. It is also valuable for compliance and audit purposes to track who performed which actions.

Enables analysis of performance by user, workload distribution, and identification of manual rework patterns tied to individuals.

Typically sourced from fields like CREATED_BY or LAST_UPDATED_BY in Oracle Fusion transaction tables, often linked to a user master table like FND_USER.

This attribute represents the specific division or operational unit within the company that owns the transaction. It allows for performance comparison across different parts of the organization.

Segmenting the process by business unit helps identify variations in efficiency, cost, and compliance across the company. This analysis can reveal best practices in high-performing units that can be shared, or highlight underperforming units that require targeted process improvements.

Enables performance benchmarking and process consistency analysis across different organizational units.

Typically available on the sales order header and linked to the organization structure defined in Oracle Fusion.

This attribute provides the country from the customer's shipping or billing address. It is a key dimension for geographical analysis.

Segmenting the process by country can reveal regional differences in process performance, cycle times, or payment behavior. This is valuable for understanding the impact of local regulations, logistics challenges, and market conditions on the Order to Cash process.

Enables geographical analysis to identify regional variations in process efficiency, compliance, and customer behavior.

Sourced from customer master data tables (HZ_LOCATIONS, HZ_PARTY_SITES) linked to the sales order.

This attribute is the unique number assigned to the invoice generated from the sales order. It links the sales and fulfillment activities to the financial settlement part of the process.

While the Sales Order is the primary case ID, the Invoice Number is critical for analyzing the invoicing and payment sub-processes. It is essential for tracking invoice corrections, disputes, and payment status, supporting dashboards like 'Invoice Accuracy & Rework Analysis'.

Provides a crucial link to the accounts receivable process and is necessary for analyzing invoice rework and payment cycles.

Available in the accounts receivable transaction tables in Oracle Fusion, such as RA_CUSTOMER_TRX_ALL.

This boolean attribute is true if an invoice underwent a correction loop, indicated by the presence of an 'Invoice Corrected' activity. It flags cases that involved rework in the invoicing stage.

This is a key input for the 'Invoice Accuracy & Rework Analysis' dashboard and the 'Invoice Rework Rate' KPI. It helps quantify the extent of invoicing errors and allows for root cause analysis to identify why corrections are needed, aiming to reduce manual work and payment delays.

Identifies invoice rework, which is a key indicator of process inefficiency, data quality issues, and potential delays in payment.

This is a calculated field, typically set to true for a case if an 'Invoice Corrected' activity exists in its event log.

This boolean attribute is derived by comparing the actual payment receipt date with the PaymentDueDate. It provides a clear indicator of whether an invoice was paid on time.

This attribute is used to calculate the 'On-Time Payment Rate' KPI. It allows for easy segmentation of on-time vs. late payments to analyze the characteristics of late-paying customers, common reasons for delays, and the financial impact on working capital.

Directly measures payment collection effectiveness and simplifies the analysis of delinquent payments.

This is a calculated field. The logic is: PaymentReceivedDate > PaymentDueDate.

This boolean attribute is derived by comparing the ActualDeliveryDate with the RequestedDeliveryDate. It provides a simple, case-level indicator of delivery performance.

This flag is the foundation for calculating the aggregate 'On-Time Delivery Rate' KPI. It simplifies filtering and analysis, allowing users to quickly isolate all late orders to perform root cause analysis on the factors contributing to delays.

Directly measures fulfillment performance against customer expectations and simplifies the analysis of late orders.

This is a calculated field. The logic is: ActualDeliveryDate <= RequestedDeliveryDate.

This attribute records when the data was last extracted or updated in the process mining dataset. It provides transparency on the freshness of the data being analyzed.

This information is vital for users to understand how current the process analysis is. It helps manage expectations about the data's timeliness and is important for setting up and monitoring data refresh schedules.

Indicates the freshness of the data, ensuring users are aware of how up-to-date their process analysis is.

This value is generated and stamped onto the dataset during each data extraction and transformation cycle.

This calculated attribute measures the end-to-end cycle time of the Order to Cash process for a single case. It represents the total duration from the first event ('Sales Order Created') to the final event ('Payment Received').

This metric is a direct measure of the overall health and efficiency of the entire process. It is the basis for the 'Overall Order to Cash Cycle Time' KPI and helps in high-level performance monitoring and benchmarking.

Represents the total end-to-end cycle time, providing a high-level KPI for overall process efficiency and cash conversion speed.

This is a calculated field. The logic is: Timestamp of 'Payment Received' - Timestamp of 'Sales Order Created'.

Order Type is used to categorize sales orders based on their business purpose. Common types include standard sales, service orders, return material authorizations (RMAs), and internal orders.

Analyzing the process by order type is important because different types often have distinct process flows and performance targets. This segmentation helps in understanding process variations that are intentional and expected, preventing them from being misinterpreted as deviations.

Allows for the segmentation of different, legitimate process flows (e.g., standard vs. returns) to ensure a fair and accurate analysis.

Typically available as a field on the sales order header table in Oracle Fusion. Consult Oracle Fusion Financials documentation.

This attribute specifies the conditions under which a customer is expected to pay their invoice, for example, 'Net 30' or 'Net 60'. These terms are the basis for calculating the PaymentDueDate.

In analysis, segmenting by payment terms can help explain variations in payment cycle times. It provides context for the 'On-Time Payment Rate' KPI, as different terms naturally lead to different payment behaviors. This can inform credit policy and cash flow forecasting.

Provides crucial context for payment behavior analysis and helps explain variations in invoice-to-payment cycle times.

Available on the sales order or customer account level within Oracle Fusion. Consult Oracle Fusion Financials documentation.

This attribute specifies the item on the sales order line. If an order has multiple lines, the case might be analyzed at the line item level, or this attribute could be aggregated at the header level.

Analyzing by product helps to understand if certain products are associated with more complex or problematic process flows, such as frequent delivery delays or payment issues. This can inform product management and supply chain strategies.

Allows for analysis of process performance for different products, highlighting items that may have complex fulfillment or invoicing paths.

Sourced from the sales order line item tables and joined with a product master table. Consult Oracle Fusion Financials documentation.

This attribute details the logistics carrier or service level used for delivery, such as 'Ground Freight', 'Air Express', or 'Local Courier'.

This information is essential for the 'Shipping Method Delivery Compliance' dashboard. It allows for the comparison of on-time delivery performance and shipping costs across different methods and carriers, helping to optimize logistics strategy and vendor selection.

Directly supports logistics analysis by allowing performance comparison of different shipping carriers and methods.

Available in the shipping and fulfillment tables within Oracle Fusion. Consult Oracle Fusion Financials documentation.

This attribute specifies the origin of the data, which is particularly useful in environments where multiple systems are involved in the Order to Cash process. For example, order data might come from Oracle Fusion, while shipping data could originate from a third-party logistics system.

In analysis, this helps in understanding data lineage and can be used to filter the process view for events from specific systems. It is crucial for data validation and for identifying process fragmentation across different IT landscapes.

Provides context about data origin, which is crucial for data governance and troubleshooting in multi-system environments.

This is typically a static value added during the data extraction and transformation process to label the dataset's origin.