Your Production Planning Data Template
Your Production Planning Data Template
- Recommended attributes for production planning analysis
- Key production planning activities to track
- Detailed data extraction guidance for SAP S/4HANA
Production Planning Attributes
| Name | Description | ||
|---|---|---|---|
| Activity Activity | The name of the specific event or task that occurred at a point in time within the production planning process. | ||
| Description This attribute records the distinct steps and milestones in the production order lifecycle. Examples include 'Production Order Created', 'Material Availability Checked', 'Production Started', and 'Order Financially Closed'. Each activity represents a specific action or status change documented in the system. Analyzing the sequence and frequency of these activities is the core of process mining. It helps visualize the process flow, identify deviations from the standard procedure, and pinpoint activities that cause delays or require frequent rework, such as 'Production Plan Adjusted'. Why it matters It defines the steps of the process, allowing for the discovery and visualization of the actual production workflow and its variations. Where to get Derived from status changes in tables like JEST and JCDS, transaction codes used (e.g., CO01 for create), or specific confirmation records in AFRU. Examples Production Order CreatedProduction Order ReleasedProduction StartedFinal Confirmation EnteredGoods Receipt Posted | |||
| Production Order ProductionOrder | The unique identifier for a production order, serving as the primary case identifier for the production planning process. | ||
| Description The Production Order number is a unique key generated by SAP S/4HANA to manage and track all activities related to the manufacturing of a specific product quantity. It links together all related events, from planning and release to execution and final settlement. In process mining, this attribute is essential for grouping all related events into a single end-to-end process instance. Analyzing processes by Production Order allows for the measurement of key performance indicators like cycle time, adherence to schedule, and identification of bottlenecks affecting specific production runs. Why it matters It is the fundamental attribute that connects all process steps, enabling a complete case-level analysis of the production lifecycle from start to finish. Where to get This is the Production Order number, typically found in SAP tables like AFKO (field AUFNR) and AFPO. Examples 100056710008341001299 | |||
| Start Time StartTime | The timestamp indicating when a specific activity or event began. | ||
| Description This attribute provides the date and time for every recorded event in the production process. It is the temporal foundation for all time-based process analysis. The Start Time is crucial for calculating durations between activities, measuring the total cycle time of a production order, and understanding the timing of events. It enables the analysis of bottlenecks, waiting times, and schedule adherence by comparing actual timestamps against planned dates. Why it matters It provides the chronological context for all events, making it possible to analyze process performance, durations, and bottlenecks. Where to get This information is typically found in change document tables (CDHDR/CDPOS) for status changes, confirmation tables (AFRU) for execution steps, and header tables (AFKO) for creation dates. Examples 2023-10-26T09:00:00Z2023-10-26T14:30:00Z2023-10-27T08:15:00Z | |||
| Last Data Update LastDataUpdate | The timestamp indicating when the data was last refreshed or extracted from the source system. | ||
| Description This attribute records the date and time of the most recent data pull. It is a critical piece of metadata that informs users about the freshness of the data they are analyzing. Knowing the last update time is essential for interpreting the analysis correctly. It helps users understand if they are viewing real-time information or a snapshot from a specific point in time, which affects the relevance of any findings and decisions made based on the data. Why it matters It ensures users are aware of the data's timeliness, which is critical for making accurate and relevant business decisions. Where to get This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process. Examples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z2024-05-23T02:00:00Z | |||
| Source System SourceSystem | The system from which the production planning data was extracted. | ||
| Description This attribute identifies the origin of the data, which is essential in environments with multiple integrated systems. For this process, it will typically be the specific SAP S/4HANA instance. In a broader data analysis context, knowing the source system helps ensure data integrity and allows for proper context when merging data from different sources. It is a fundamental piece of metadata for data governance and traceability. Why it matters It provides crucial metadata for data governance, ensuring the origin and context of the process data are clear. Where to get This is typically a static value added during the data extraction process to identify the SAP S/4HANA client and system ID (SID). Examples S4P_100S4H_PRD_200S4Q_300 | |||
| Material Number MaterialNumber | The unique identifier for the product being manufactured in the production order. | ||
| Description The Material Number specifies the item that the production order aims to produce. It links the production process to the master data of the material, including its bill of materials (BOM) and routing information. Analyzing the process by Material Number helps identify if certain products are more prone to delays, rework, or material shortages. This allows for product-specific process optimization, such as adjusting planning parameters or improving the supply chain for specific components. Why it matters It allows for filtering and analysis based on the product being made, revealing product-specific inefficiencies or bottlenecks. Where to get Found in the Production Order item table AFPO (field MATNR). Examples RM-1001FG-2050SA-3100-B | |||
| Order Status OrderStatus | The current processing status of the production order, such as Created, Released, or Technically Completed. | ||
| Description The Order Status indicates the overall stage of the production order in its lifecycle. It is a summary of the various system and user statuses applied to the order. Common statuses include CRTD (Created), REL (Released), CNF (Confirmed), TECO (Technically Completed), and CLSD (Closed). Analyzing the current status of orders is useful for understanding the work-in-progress landscape. In process mining, tracking the transitions between these statuses over time is what generates the activity log and allows for a detailed view of the process flow and durations spent in each stage. Why it matters It provides a high-level view of an order's lifecycle stage and is fundamental to deriving the sequence of activities for process mining. Where to get Derived from the system status stored in table JEST, linked via the object number in AFKO (field OBJNR). Examples CRTDRELTECOCLSD | |||
| Planned End Date PlannedEndDate | The scheduled completion date for the production order as per the initial plan. | ||
| Description The Planned End Date is the target date by which all production activities for an order are expected to be finished. This date is determined during the scheduling phase of production planning. This attribute is essential for measuring schedule adherence. By comparing the Planned End Date with the actual completion timestamp, organizations can calculate the Production Schedule Adherence Rate KPI and identify orders that are late. This analysis is critical for improving planning accuracy and customer satisfaction. Why it matters It serves as the baseline for measuring schedule adherence, helping to evaluate the accuracy of planning and the efficiency of execution. Where to get Found in the Production Order header table AFKO (field GLTRP). Examples 2023-11-152023-12-012024-01-20 | |||
| Plant Plant | The manufacturing facility or location where the production order is being executed. | ||
| Description The Plant is an organizational unit in SAP representing a production site or facility. Each production order is assigned to a specific plant where the manufacturing activities will take place. This attribute is critical for comparative analysis across different manufacturing locations. By segmenting the process data by Plant, organizations can benchmark performance, identify site-specific issues or best practices, and understand regional variations in efficiency, capacity, or adherence to standards. Why it matters It enables performance comparison between different production sites, helping to identify and share best practices or address location-specific issues. Where to get Found in the Production Order header table AFKO (field DWERK). Examples 100017102000 | |||
| Work Center WorkCenter | The specific machine, group of machines, or assembly area responsible for an operation. | ||
| Description A Work Center represents a specific operational unit within a plant where a production step is performed. It can be a single machine, a production line, or a group of employees. Analyzing process data by Work Center is key to identifying capacity bottlenecks and optimizing resource allocation. It helps answer questions about which work centers are overloaded, which are underutilized, and where delays are most frequently occurring during the production execution phase. This is vital for the Capacity Bottleneck Identification dashboard. Why it matters It helps pinpoint specific machines or production lines that are bottlenecks, enabling targeted improvements in capacity and resource utilization. Where to get Found in the operation data of a production order, table AFVC (field ARBPL). Examples WC-ASSEMBLY-01WC-MILLING-05WC-PACKING | |||
| Confirmed Quantity TotalConfirmedQuantity | The total quantity of the material that has been confirmed as produced for the order. | ||
| Description This attribute represents the cumulative quantity of finished or semi-finished goods that have been reported through production confirmations. It tracks the progress of the order toward its completion target. Comparing the confirmed quantity against the planned quantity helps in monitoring production progress and identifying yield issues or discrepancies. It is a fundamental measure of output and is used in various performance calculations, including scrap rates and efficiency. Why it matters It tracks the actual output of the production order, which is essential for monitoring progress, calculating yield, and identifying discrepancies. Where to get Aggregated from confirmation records in AFRU (field LMNGA for yield quantity). Examples 9801000501200 | |||
| End Time EndTime | The timestamp indicating when a specific activity or event was completed. | ||
| Description This attribute provides the completion date and time for every recorded event. It complements the Start Time to define the duration of activities. End Time is crucial for calculating the precise processing time of individual activities, which is a key input for capacity and resource utilization analysis. It helps differentiate between active work time and idle or wait time, leading to more accurate bottleneck identification. Why it matters It enables the calculation of precise activity durations, which is essential for analyzing resource efficiency and identifying process bottlenecks. Where to get Found in confirmation tables (AFRU) for execution steps. For other events, it might be the same as the Start Time if the event is instantaneous. Examples 2023-10-26T09:45:00Z2023-10-26T15:00:00Z2023-10-27T10:30:00Z | |||
| Is On Time IsOnTime | A flag indicating if the production order was completed on or before its planned end date. | ||
| Description This calculated boolean attribute directly measures schedule adherence by comparing the actual completion date with the planned end date. It provides a clear, binary outcome for each production order's timeliness. This attribute is the basis for the Production Schedule Adherence Rate KPI. It simplifies analysis by allowing for easy segmentation of on-time versus late orders, helping to identify common characteristics or process paths associated with delays. Why it matters It provides a clear and simple measure of schedule adherence for each order, facilitating analysis of the root causes of delays. Where to get Calculated field. Set to true if the timestamp of the 'Order Technically Completed' activity is less than or equal to the 'Planned End Date' attribute. Examples truefalse | |||
| Is Rework IsRework | A flag indicating if a production order involved rework or significant plan adjustments after starting. | ||
| Description This boolean attribute is derived to identify production orders that underwent corrective actions or plan changes after production was already underway. This could be triggered by an explicit rework activity or a 'Production Plan Adjusted' event occurring after 'Production Started'. This flag is crucial for calculating the Production Rework Rate KPI and for the Production Rework and Revisions dashboard. It allows for easy filtering and analysis of problematic cases, helping to uncover the root causes of quality issues or process deviations that lead to costly rework. Why it matters It isolates cases with rework, enabling targeted analysis to understand and reduce quality issues, process deviations, and associated costs. Where to get Calculated field. Set to true if a 'Production Plan Adjusted' activity occurs after a 'Production Started' activity within the same case, or if a specific rework order type is used. Examples truefalse | |||
| Material Availability Status MaterialAvailabilityStatus | Indicates whether all required materials for the production order are available. | ||
| Description This status reflects the result of the material availability check performed for a production order. It can indicate that all materials are available, some are missing, or the check has not been performed. A status of 'shortage' is a key trigger for potential delays. This attribute is critical for the Material Shortage Impact Analysis dashboard. It helps quantify the delays caused by material unavailability by correlating a shortage status with the time between order release and production start. Improving this metric is key to a smoother production flow. Why it matters It directly explains delays between order release and production start, helping to quantify the impact of supply chain issues on manufacturing. Where to get This is a status, often derived from the collective status of material components. It can be found in the system status (JEST) with statuses like 'MSPT' (Material shortage). Examples AvailableShortageNot Checked | |||
| Order Type OrderType | A classification of the production order that defines its purpose and controls its processing. | ||
| Description The Order Type is a key configuration element in SAP PP that determines how a production order is handled by the system. It controls number ranges, master data selection, costing parameters, and settlement rules. Examples include standard production orders, rework orders, or prototype orders. Analyzing the process by Order Type allows for comparing the performance and flow of different kinds of production processes. This can reveal if rework orders take significantly longer or if certain order types are more prone to planning adjustments, providing valuable insights for targeted process improvement. Why it matters It allows for the segmentation of analysis by the order's business purpose, enabling comparison between standard production, rework, and other processes. Where to get Found in the Production Order header table AFKO (field AUART). Examples PP01PP03ZP01 | |||
| Planned Start Date PlannedStartDate | The scheduled start date for the production order as per the initial plan. | ||
| Description The Planned Start Date is the target date by which production activities for an order are expected to begin. This is a key output of the scheduling process. This attribute provides the starting baseline for schedule adherence analysis. Comparing the Planned Start Date to the actual start time helps in understanding front-end delays, such as delays in material staging or order release, which can have a cascading effect on the entire production timeline. Why it matters It provides a baseline for measuring start-time adherence, which is crucial for identifying delays in pre-production stages like order release and material availability. Where to get Found in the Production Order header table AFKO (field GSTRP). Examples 2023-11-102023-11-252024-01-15 | |||
| Production Cycle Time ProductionCycleTime | The total time elapsed from the release of a production order to its technical completion. | ||
| Description This calculated metric measures the end-to-end duration of a production order's lifecycle in execution. It is a key performance indicator that reflects the overall efficiency of the production process. This attribute is the primary measure for the Production Order Lead Time Overview dashboard and the Average Production Order Cycle Time KPI. Analyzing its components, such as wait times versus processing times, helps identify the biggest opportunities for process acceleration and lead time reduction. Why it matters This is a critical KPI for measuring overall production efficiency and identifying opportunities to accelerate order fulfillment. Where to get Calculated by finding the duration between the 'Production Order Released' activity and the 'Order Technically Completed' activity for each Production Order. Examples P5DT12H30MP10DT2HP3D | |||
| Production Priority ProductionPriority | A code or value assigned to a production order to indicate its urgency or importance. | ||
| Description Production Priority is used by planners and schedulers to sequence and prioritize orders, especially when resources are constrained. A higher priority order should ideally be processed before a lower priority one. Analyzing this attribute helps to assess whether the assigned priorities are being followed on the shop floor. The Production Prioritization Consistency dashboard compares the processing sequence against the assigned priority to identify inconsistencies, which can lead to improved scheduling discipline and better alignment between planning and execution. Why it matters It helps determine if production scheduling follows business priorities, ensuring that critical orders are expedited as intended. Where to get This is often a custom field or based on other order parameters. A specific location is configuration-dependent. Examples HighMediumLow15 | |||
| User User | The system ID of the user who created, changed, or confirmed a production order event. | ||
| Description This attribute captures the SAP user ID associated with a specific transaction or status change, such as releasing an order or entering a confirmation. It provides traceability for actions taken within the system. Analyzing activities by User helps in understanding workload distribution, identifying training needs, and ensuring compliance with procedures. For example, it can highlight if certain users are frequently involved in plan adjustments or if delays are associated with specific teams. Why it matters It provides accountability and allows for analysis of workload, user-specific behavior, and potential training opportunities. Where to get Typically found in change document headers (CDHDR, field UNAME) or confirmation records (AFRU, field PERNR for personnel number). Examples CB9980000021JSMITHPLANNER01 | |||
Production Planning Activities
| Activity | Description | ||
|---|---|---|---|
| Final Confirmation Entered | This activity marks the confirmation of the last operation in the production order's routing. It signifies that all planned manufacturing steps have been completed on the shop floor. | ||
| Why it matters The final confirmation is a key milestone that indicates the end of physical production work. It is often used as a more precise endpoint for measuring shop floor cycle time before final goods receipt. Where to get Inferred from confirmation data in the AFRU table. It is identified as the confirmation record for the last operation sequence (AFVC-VPLNR) that has the 'final confirmation' indicator (AFRUD-AUERU) set. Capture Find the last operation confirmation in AFRU with the final confirmation flag set. Event type inferred | |||
| Goods Receipt Posted | This event records the receipt of the finished product from the production line into inventory. It formally increases the stock level of the produced material. | ||
| Why it matters This is a critical milestone representing the completion of the production output. It is often considered the end of the production cycle for measuring on-time delivery and overall lead time. Where to get This is an explicit financial posting recorded in the material document tables MSEG (item level) and MKPF (header level), typically with movement type 101. These documents are linked to the production order. Capture Find material document in MSEG linked to the order with movement type 101. Event type explicit | |||
| Order Technically Completed | This is an administrative closing step that prevents further logistical changes to the order, such as goods movements or confirmations. The order is considered complete from a logistics point of view. | ||
| Why it matters TECO is a definitive endpoint for the production process, crucial for calculating the total production order cycle time. It signals that all logistical activities are finished and the order is ready for financial settlement. Where to get This is triggered by a user setting the status to TECO (Technically Completed). The event is captured as a status change in the JCDS table with a corresponding timestamp. Capture Timestamp of the status change to 'TECO' in the JCDS table. Event type inferred | |||
| Production Order Created | This is the initial creation of the production order in the system, which serves as the formal request to produce a specified quantity of a product. This event is explicitly captured when a user saves a new order, setting its initial status to CRTD (Created). | ||
| Why it matters Marks the beginning of the production order lifecycle. Analyzing the time from creation to release helps identify administrative or planning delays before production is formally scheduled. Where to get This event is recorded in the AUFK table (Order Master Data) with the creation date (ERDAT). The creation status (CRTD) is logged in the JEST and JCDS tables, linked via the order's object number (OBJNR). Capture Timestamp from AUFK-ERDAT or status change log to 'CRTD' in JCDS. Event type explicit | |||
| Production Order Released | This is a key milestone where the production order is approved and made available for execution on the shop floor. The release allows for goods issues, confirmations, and other execution steps to begin. | ||
| Why it matters This event marks the official start of the executable production process and is a critical point for measuring lead times. The time between creation and release is a key KPI for pre-production efficiency. Where to get The release is explicitly triggered by a user or system job, resulting in the status REL. This status change is recorded with a timestamp in the JCDS table. The release date is also often stored in AFKO-FTRMI. Capture Timestamp of the status change to 'REL' in the JCDS table. Event type inferred | |||
| Production Plan Adjusted | Represents a significant change made to the production order after it has been released, such as a change in quantity, dates, or the bill of materials. This is captured by analyzing change documents. | ||
| Why it matters Frequent adjustments may indicate planning instability or volatile demand. This activity is the basis for the Production Plan Revision Rate KPI and helps identify sources of process variability. Where to get Inferred from change logs recorded in the CDHDR (Change document header) and CDPOS (Change document items) tables for the production order object (AUFK or AFPO). Changes made after the release date are considered adjustments. Capture Identify changes in CDHDR/CDPOS for key fields (e.g., quantity, dates) after the release event. Event type inferred | |||
| Production Started | Indicates the start of physical production activities for the order. This is typically inferred from the first shop floor confirmation or the first goods issue of components against the order. | ||
| Why it matters This activity marks the transition from planning to execution. It is essential for tracking schedule adherence by comparing the actual start date to the planned start date. Where to get This is an inferred event. It is typically derived from the earliest timestamp of a goods movement posting (MSEG table, movement type 261) or a time confirmation posting (AFRU table) associated with the order. Capture Earliest timestamp from AFRU (confirmations) or MSEG (goods movements) for the order. Event type inferred | |||
| Capacity Requirements Planned | This activity involves scheduling the production order's operations and checking for capacity availability at the required work centers. The system evaluates work center capacity loads and levels them if configured, determining the production dates. | ||
| Why it matters This step is critical for ensuring a feasible production schedule. Analyzing its duration and outcomes helps identify capacity bottlenecks and improves resource planning accuracy. Where to get This is generally inferred from the system status indicating the order has been scheduled, such as SETC (Scheduling carried out). The scheduled start and end dates (AUFK-GSTRP, AUFK-GLTRP) being populated also signals this activity's completion. Capture Inferred from population of scheduled dates in AUFK/AFKO or a scheduling-related status in JEST. Event type inferred | |||
| Material Availability Checked | Represents the system or user action of checking whether all required components for the production order are available in the required quantities and on time. This is typically an automated check upon order creation or release, or a manual check, which updates the order status. | ||
| Why it matters Early identification of material shortages is crucial for proactive planning. Tracking this activity helps understand how material availability impacts the ability to release orders and start production on time. Where to get Inferred from the order status. A status like MACM (Material committed) or a change in the material availability date (AFKO-MSERF) indicates a check has been performed. The absence of a material shortage status (MSPT) can also infer availability. Capture Inferred from status changes related to material commitment or execution of transaction COMAC. Event type inferred | |||
| Material Shortage Occurred | This event indicates that the production process was impacted or halted due to the unavailability of one or more required components. The system sets a specific status on the order to reflect this. | ||
| Why it matters Tracking material shortages is critical for the Material Shortage Impact Analysis. It helps quantify delays caused by supply chain issues and improve material planning. Where to get This is inferred from the activation of the 'MSPT' (Material shortage) status for the production order. The timestamp for this status change can be found in the JCDS table. Capture Timestamp of the status change to 'MSPT' in the JCDS table. Event type inferred | |||
| Order Financially Closed | The final closing step where the order is settled, and no further financial postings are possible. This signifies the end of the order's lifecycle from a controlling and accounting perspective. | ||
| Why it matters While often outside the scope of pure production analysis, this activity provides a complete end-to-end view. It can help analyze the time between logistical completion (TECO) and financial closing. Where to get This is triggered by a user setting the status to CLSD (Closed). The event is captured as a status change in the JCDS table with a corresponding timestamp. Capture Timestamp of the status change to 'CLSD' in the JCDS table. Event type inferred | |||
| Production Confirmation Entered | Represents the recording of progress for a specific operation within the production order. This includes logging quantities produced, scrap, and time spent at a work center. | ||
| Why it matters Confirmations provide real-time visibility into shop floor progress and are vital for tracking production status. Analyzing the frequency and timing of confirmations helps monitor flow and identify delays between operations. Where to get Each confirmation is explicitly recorded as an entry in the AFRU (Order Completion Confirmations) table with a timestamp (BUDAT, UZEIT) and details about the operation. Capture Recorded as a document in the AFRU table. Event type explicit | |||
| Production Order Cancelled | Represents the cancellation of a production order before its completion. This is an alternative, unsuccessful end state for the process. | ||
| Why it matters Analyzing cancelled orders can reveal issues in demand planning, master data, or the sales process. High cancellation rates may indicate systemic problems that need addressing. Where to get This is inferred from the system status CACL (Cancellation) being set in the JCDS table. Alternatively, a deletion flag (AUFK-LOEKZ) can also signify cancellation. Capture Timestamp of status change to 'CACL' in JCDS or setting of deletion flag in AUFK. Event type inferred | |||
| Unplanned Halt Occurred | This calculated event represents a significant idle period during the production execution phase. It is not an explicit system event but is derived by identifying long time gaps between consecutive production confirmations. | ||
| Why it matters Helps in monitoring for unplanned disruptions like machine breakdowns or quality issues. Identifying frequent or long halts is key to improving shop floor stability and throughput. Where to get This is calculated by analyzing the timestamps of consecutive 'Production Confirmation Entered' activities from the AFRU table. A gap exceeding a predefined threshold is flagged as an unplanned halt. Capture Calculate time difference between consecutive confirmation timestamps (AFRU-BUDAT/UZEIT). Event type calculated | |||
Extraction Guides
Steps
- Prerequisites Verification: Ensure you have a user in SAP S/4HANA with appropriate authorizations to access the required Core Data Services (CDS) views. The necessary views include
I_ProductionOrder,I_ProdOrdConfirmation,I_MaterialDocumentItem,I_ObjectStatus, andI_ChangeDocument. Access to an SQL execution environment connected to the SAP HANA database is also required, such as SAP HANA Studio, DBeaver, or an external ETL tool. - Identify System Details: Note the source system identifier you will use for the
SourceSystemattribute. This is a logical name you define to identify the origin of the data, for example,S4H_PROD. - Set Extraction Parameters: Before running the query, define the key parameters. This includes the start and end dates for the extraction period and any specific filters like
PlantorProductionOrderTypeto limit the data scope. - Prepare the SQL Query: Copy the complete SQL query provided in the
querysection into your chosen SQL client or data extraction tool. - Configure Placeholders: Replace the placeholder values in the query with your specific parameters. This includes
_StartDate,_EndDate, and the source system identifier. Adjust the threshold for theUnplanned Halt Occurredevent (e.g.,'24:00:00') to match your business context. - Execute the Extraction Query: Run the configured SQL script against the SAP S/4HANA system's database. For large datasets covering a long period, consider running the extraction in smaller chunks, for example, month by month, to avoid performance issues.
- Initial Data Review: Once the query execution is complete, perform a quick review of the output. Check the row count, ensure all columns are present, and verify that the
Activitycolumn contains a variety of the expected events. - Data Validation: Follow the steps outlined in the
validationStepssection to perform a more thorough validation. Cross-reference a few production orders with their details in the SAP system using transactionCO03to confirm the accuracy of the extracted event log. - Export to CSV: Export the final result set to a CSV file. Ensure the file encoding is UTF-8 to prevent character issues.
- Prepare for Upload: Confirm that the CSV column headers match the required attribute names:
ProductionOrder,Activity,StartTime,SourceSystem, andLastDataUpdate. Ensure theStartTimecolumn is in a standard timestamp format, like ISO 8601 (YYYY-MM-DDTHH:MM:SS), before uploading to the process mining tool.
Configuration
- Core CDS Views: The extraction primarily relies on a set of standard CDS views that provide a structured, business-oriented view of the underlying SAP tables. Key views include:
I_ProductionOrder: For header-level data and creation events.I_ProdOrdConfirmation: For all operation confirmations.I_MaterialDocumentItem: For goods movements like issues and receipts.I_ObjectStatus: To read the status changes of the production order.I_ChangeDocumentand associated views: To capture changes to key order fields.
- Date Range Filtering: It is critical to apply a date range filter to manage the data volume. The provided query uses the
CreationDateof the production order. A typical range for an initial analysis is 3 to 6 months of data. - Key Business Filters: To further refine the dataset, apply filters based on key organizational or master data attributes. Common filters include:
Plant: To analyze a specific manufacturing facility.ProductionOrderType: To focus on standard production, rework, or other order types.CompanyCode: To restrict data to a specific legal entity.
- Unplanned Halt Threshold: The query includes logic to derive
Unplanned Halt Occurredevents. This logic requires a time threshold to define what constitutes a significant gap between operations. This value should be configured based on typical production cycle times and business rules. - Authorization Prerequisites: The SAP user executing the query must have display authorization for all the CDS views and their underlying tables. Missing authorizations will result in an empty or incomplete result set.
a Sample Query sql
WITH BaseOrders AS (
SELECT
ProductionOrder,
Material AS MaterialNumber,
ProductionPlant AS Plant,
CreationDate,
CreationTime,
BasicEndDate AS PlannedEndDate,
TechnicalCompletionDate,
LastChangeDateTime
FROM I_ProductionOrder
-- P_CreationDateFrom and P_CreationDateTo are placeholders for your date range
WHERE CreationDate BETWEEN '[_StartDate]' AND '[_EndDate]'
-- Add other filters as needed, for example:
-- AND ProductionPlant IN ('[Your_Plant_1]', '[Your_Plant_2]')
-- AND ProductionOrderType = '[Your_Order_Type]'
)
SELECT
bo.ProductionOrder,
'Production Order Created' AS Activity,
TO_TIMESTAMP(bo.CreationDate || ' ' || LPAD(bo.CreationTime, 6, '0'), 'YYYYMMDD HH24MISS') AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
'CRTD' AS OrderStatus
FROM BaseOrders bo
UNION ALL
-- System status changes like Released, Technically Completed, Closed, Cancelled, Material Shortage
SELECT
os.ObjectInternalID AS ProductionOrder,
CASE os.SystemStatus
WHEN 'I0002' THEN 'Production Order Released'
WHEN 'I0043' THEN 'Material Availability Checked' -- Status: MACM (Material committed)
WHEN 'I0045' THEN 'Order Technically Completed'
WHEN 'I0046' THEN 'Order Financially Closed'
WHEN 'I0047' THEN 'Production Order Cancelled'
WHEN 'I0010' THEN 'Material Shortage Occurred' -- Status: MSPT (Material shortage)
END AS Activity,
os.StatusChangeDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
os.SystemStatus AS OrderStatus
FROM I_ObjectStatus AS os
JOIN BaseOrders AS bo ON os.ObjectInternalID = bo.ProductionOrder
WHERE os.SystemStatus IN ('I0002', 'I0043', 'I0045', 'I0046', 'I0047', 'I0010') AND os.StatusIsInactive = ''
UNION ALL
-- Production Started, inferred from the first goods issue or first confirmation
SELECT
s.ProductionOrder,
'Production Started' AS Activity,
s.StartEventTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
s.MaterialNumber,
s.Plant,
NULL AS WorkCenter,
s.PlannedEndDate,
NULL AS OrderStatus
FROM (
SELECT
bo.ProductionOrder,
bo.MaterialNumber,
bo.Plant,
bo.PlannedEndDate,
MIN(COALESCE(gm.PostingTime, cf.ConfirmationDateTime)) AS StartEventTime,
ROW_NUMBER() OVER(PARTITION BY bo.ProductionOrder ORDER BY MIN(COALESCE(gm.PostingTime, cf.ConfirmationDateTime))) as rn
FROM BaseOrders bo
LEFT JOIN I_MaterialDocumentItem gm ON bo.ProductionOrder = gm.ProductionOrder AND gm.GoodsMovementType IN ('261', '262') -- Goods Issue
LEFT JOIN I_ProdOrdConfirmation cf ON bo.ProductionOrder = cf.ProductionOrder
WHERE gm.ProductionOrder IS NOT NULL OR cf.ProductionOrder IS NOT NULL
GROUP BY bo.ProductionOrder, bo.MaterialNumber, bo.Plant, bo.PlannedEndDate
) s
WHERE s.rn = 1
UNION ALL
-- Production Confirmation Entered (for each confirmation)
SELECT
cf.ProductionOrder,
'Production Confirmation Entered' AS Activity,
cf.ConfirmationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
cf.WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
UNION ALL
-- Final Confirmation Entered
SELECT
cf.ProductionOrder,
'Final Confirmation Entered' AS Activity,
cf.ConfirmationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
cf.WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
WHERE cf.IsFinalConfirmation = 'X'
UNION ALL
-- Unplanned Halt Occurred (derived from gaps between confirmations)
SELECT
ProductionOrder,
'Unplanned Halt Occurred' AS Activity,
PreviousConfirmationTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
MaterialNumber,
Plant,
WorkCenter,
PlannedEndDate,
NULL AS OrderStatus
FROM (
SELECT
cf.ProductionOrder,
bo.MaterialNumber,
bo.Plant,
bo.PlannedEndDate,
cf.WorkCenter,
cf.ConfirmationDateTime,
LAG(cf.ConfirmationDateTime, 1) OVER (PARTITION BY cf.ProductionOrder ORDER BY cf.ConfirmationDateTime) AS PreviousConfirmationTime,
(SECONDS_BETWEEN(LAG(cf.ConfirmationDateTime, 1) OVER (PARTITION BY cf.ProductionOrder ORDER BY cf.ConfirmationDateTime), cf.ConfirmationDateTime) / 3600.0) as HoursDiff
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
) AS gaps
WHERE gaps.HoursDiff > 24 -- Configurable threshold in hours, e.g. 24 hours
UNION ALL
-- Goods Receipt Posted
SELECT
gm.ProductionOrder,
'Goods Receipt Posted' AS Activity,
gm.PostingTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_MaterialDocumentItem gm
JOIN BaseOrders bo ON gm.ProductionOrder = bo.ProductionOrder
WHERE gm.GoodsMovementType = '101'
UNION ALL
-- Capacity Requirements Planned (using Release event as a proxy)
SELECT
os.ObjectInternalID AS ProductionOrder,
'Capacity Requirements Planned' AS Activity,
os.StatusChangeDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
os.SystemStatus AS OrderStatus
FROM I_ObjectStatus AS os
JOIN BaseOrders AS bo ON os.ObjectInternalID = bo.ProductionOrder
WHERE os.SystemStatus = 'I0002' AND os.StatusIsInactive = '' -- Status 'REL' (Released)
UNION ALL
-- Production Plan Adjusted
SELECT
ch.ObjectValue AS ProductionOrder,
'Production Plan Adjusted' AS Activity,
ch.CreationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL as WorkCenter,
bo.PlannedEndDate,
NULL as OrderStatus
FROM I_ChangeDocument AS ch
JOIN BaseOrders bo ON ch.ObjectValue = bo.ProductionOrder
WHERE ch.ChangeDocumentObject = 'PRODORDER'
-- Monitoring changes in key fields like Total Quantity (GAMNG) or Basic Finish Date (GLTRP)
AND ch.FieldName IN ('GAMNG', 'GLTRP')
GROUP BY ch.ObjectValue, ch.CreationDateTime, bo.MaterialNumber, bo.Plant, bo.PlannedEndDate Steps
- Prerequisites Verification: Ensure you have a user in SAP S/4HANA with appropriate authorizations to access the required Core Data Services (CDS) views. The necessary views include
I_ProductionOrder,I_ProdOrdConfirmation,I_MaterialDocumentItem,I_ObjectStatus, andI_ChangeDocument. Access to an SQL execution environment connected to the SAP HANA database is also required, such as SAP HANA Studio, DBeaver, or an external ETL tool. - Identify System Details: Note the source system identifier you will use for the
SourceSystemattribute. This is a logical name you define to identify the origin of the data, for example,S4H_PROD. - Set Extraction Parameters: Before running the query, define the key parameters. This includes the start and end dates for the extraction period and any specific filters like
PlantorProductionOrderTypeto limit the data scope. - Prepare the SQL Query: Copy the complete SQL query provided in the
querysection into your chosen SQL client or data extraction tool. - Configure Placeholders: Replace the placeholder values in the query with your specific parameters. This includes
_StartDate,_EndDate, and the source system identifier. Adjust the threshold for theUnplanned Halt Occurredevent (e.g.,'24:00:00') to match your business context. - Execute the Extraction Query: Run the configured SQL script against the SAP S/4HANA system's database. For large datasets covering a long period, consider running the extraction in smaller chunks, for example, month by month, to avoid performance issues.
- Initial Data Review: Once the query execution is complete, perform a quick review of the output. Check the row count, ensure all columns are present, and verify that the
Activitycolumn contains a variety of the expected events. - Data Validation: Follow the steps outlined in the
validationStepssection to perform a more thorough validation. Cross-reference a few production orders with their details in the SAP system using transactionCO03to confirm the accuracy of the extracted event log. - Export to CSV: Export the final result set to a CSV file. Ensure the file encoding is UTF-8 to prevent character issues.
- Prepare for Upload: Confirm that the CSV column headers match the required attribute names:
ProductionOrder,Activity,StartTime,SourceSystem, andLastDataUpdate. Ensure theStartTimecolumn is in a standard timestamp format, like ISO 8601 (YYYY-MM-DDTHH:MM:SS), before uploading to the process mining tool.
Configuration
- Core CDS Views: The extraction primarily relies on a set of standard CDS views that provide a structured, business-oriented view of the underlying SAP tables. Key views include:
I_ProductionOrder: For header-level data and creation events.I_ProdOrdConfirmation: For all operation confirmations.I_MaterialDocumentItem: For goods movements like issues and receipts.I_ObjectStatus: To read the status changes of the production order.I_ChangeDocumentand associated views: To capture changes to key order fields.
- Date Range Filtering: It is critical to apply a date range filter to manage the data volume. The provided query uses the
CreationDateof the production order. A typical range for an initial analysis is 3 to 6 months of data. - Key Business Filters: To further refine the dataset, apply filters based on key organizational or master data attributes. Common filters include:
Plant: To analyze a specific manufacturing facility.ProductionOrderType: To focus on standard production, rework, or other order types.CompanyCode: To restrict data to a specific legal entity.
- Unplanned Halt Threshold: The query includes logic to derive
Unplanned Halt Occurredevents. This logic requires a time threshold to define what constitutes a significant gap between operations. This value should be configured based on typical production cycle times and business rules. - Authorization Prerequisites: The SAP user executing the query must have display authorization for all the CDS views and their underlying tables. Missing authorizations will result in an empty or incomplete result set.
a Sample Query sql
WITH BaseOrders AS (
SELECT
ProductionOrder,
Material AS MaterialNumber,
ProductionPlant AS Plant,
CreationDate,
CreationTime,
BasicEndDate AS PlannedEndDate,
TechnicalCompletionDate,
LastChangeDateTime
FROM I_ProductionOrder
-- P_CreationDateFrom and P_CreationDateTo are placeholders for your date range
WHERE CreationDate BETWEEN '[_StartDate]' AND '[_EndDate]'
-- Add other filters as needed, for example:
-- AND ProductionPlant IN ('[Your_Plant_1]', '[Your_Plant_2]')
-- AND ProductionOrderType = '[Your_Order_Type]'
)
SELECT
bo.ProductionOrder,
'Production Order Created' AS Activity,
TO_TIMESTAMP(bo.CreationDate || ' ' || LPAD(bo.CreationTime, 6, '0'), 'YYYYMMDD HH24MISS') AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
'CRTD' AS OrderStatus
FROM BaseOrders bo
UNION ALL
-- System status changes like Released, Technically Completed, Closed, Cancelled, Material Shortage
SELECT
os.ObjectInternalID AS ProductionOrder,
CASE os.SystemStatus
WHEN 'I0002' THEN 'Production Order Released'
WHEN 'I0043' THEN 'Material Availability Checked' -- Status: MACM (Material committed)
WHEN 'I0045' THEN 'Order Technically Completed'
WHEN 'I0046' THEN 'Order Financially Closed'
WHEN 'I0047' THEN 'Production Order Cancelled'
WHEN 'I0010' THEN 'Material Shortage Occurred' -- Status: MSPT (Material shortage)
END AS Activity,
os.StatusChangeDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
os.SystemStatus AS OrderStatus
FROM I_ObjectStatus AS os
JOIN BaseOrders AS bo ON os.ObjectInternalID = bo.ProductionOrder
WHERE os.SystemStatus IN ('I0002', 'I0043', 'I0045', 'I0046', 'I0047', 'I0010') AND os.StatusIsInactive = ''
UNION ALL
-- Production Started, inferred from the first goods issue or first confirmation
SELECT
s.ProductionOrder,
'Production Started' AS Activity,
s.StartEventTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
s.MaterialNumber,
s.Plant,
NULL AS WorkCenter,
s.PlannedEndDate,
NULL AS OrderStatus
FROM (
SELECT
bo.ProductionOrder,
bo.MaterialNumber,
bo.Plant,
bo.PlannedEndDate,
MIN(COALESCE(gm.PostingTime, cf.ConfirmationDateTime)) AS StartEventTime,
ROW_NUMBER() OVER(PARTITION BY bo.ProductionOrder ORDER BY MIN(COALESCE(gm.PostingTime, cf.ConfirmationDateTime))) as rn
FROM BaseOrders bo
LEFT JOIN I_MaterialDocumentItem gm ON bo.ProductionOrder = gm.ProductionOrder AND gm.GoodsMovementType IN ('261', '262') -- Goods Issue
LEFT JOIN I_ProdOrdConfirmation cf ON bo.ProductionOrder = cf.ProductionOrder
WHERE gm.ProductionOrder IS NOT NULL OR cf.ProductionOrder IS NOT NULL
GROUP BY bo.ProductionOrder, bo.MaterialNumber, bo.Plant, bo.PlannedEndDate
) s
WHERE s.rn = 1
UNION ALL
-- Production Confirmation Entered (for each confirmation)
SELECT
cf.ProductionOrder,
'Production Confirmation Entered' AS Activity,
cf.ConfirmationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
cf.WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
UNION ALL
-- Final Confirmation Entered
SELECT
cf.ProductionOrder,
'Final Confirmation Entered' AS Activity,
cf.ConfirmationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
cf.WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
WHERE cf.IsFinalConfirmation = 'X'
UNION ALL
-- Unplanned Halt Occurred (derived from gaps between confirmations)
SELECT
ProductionOrder,
'Unplanned Halt Occurred' AS Activity,
PreviousConfirmationTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
MaterialNumber,
Plant,
WorkCenter,
PlannedEndDate,
NULL AS OrderStatus
FROM (
SELECT
cf.ProductionOrder,
bo.MaterialNumber,
bo.Plant,
bo.PlannedEndDate,
cf.WorkCenter,
cf.ConfirmationDateTime,
LAG(cf.ConfirmationDateTime, 1) OVER (PARTITION BY cf.ProductionOrder ORDER BY cf.ConfirmationDateTime) AS PreviousConfirmationTime,
(SECONDS_BETWEEN(LAG(cf.ConfirmationDateTime, 1) OVER (PARTITION BY cf.ProductionOrder ORDER BY cf.ConfirmationDateTime), cf.ConfirmationDateTime) / 3600.0) as HoursDiff
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
) AS gaps
WHERE gaps.HoursDiff > 24 -- Configurable threshold in hours, e.g. 24 hours
UNION ALL
-- Goods Receipt Posted
SELECT
gm.ProductionOrder,
'Goods Receipt Posted' AS Activity,
gm.PostingTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_MaterialDocumentItem gm
JOIN BaseOrders bo ON gm.ProductionOrder = bo.ProductionOrder
WHERE gm.GoodsMovementType = '101'
UNION ALL
-- Capacity Requirements Planned (using Release event as a proxy)
SELECT
os.ObjectInternalID AS ProductionOrder,
'Capacity Requirements Planned' AS Activity,
os.StatusChangeDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
os.SystemStatus AS OrderStatus
FROM I_ObjectStatus AS os
JOIN BaseOrders AS bo ON os.ObjectInternalID = bo.ProductionOrder
WHERE os.SystemStatus = 'I0002' AND os.StatusIsInactive = '' -- Status 'REL' (Released)
UNION ALL
-- Production Plan Adjusted
SELECT
ch.ObjectValue AS ProductionOrder,
'Production Plan Adjusted' AS Activity,
ch.CreationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL as WorkCenter,
bo.PlannedEndDate,
NULL as OrderStatus
FROM I_ChangeDocument AS ch
JOIN BaseOrders bo ON ch.ObjectValue = bo.ProductionOrder
WHERE ch.ChangeDocumentObject = 'PRODORDER'
-- Monitoring changes in key fields like Total Quantity (GAMNG) or Basic Finish Date (GLTRP)
AND ch.FieldName IN ('GAMNG', 'GLTRP')
GROUP BY ch.ObjectValue, ch.CreationDateTime, bo.MaterialNumber, bo.Plant, bo.PlannedEndDate