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 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
- Confirm that direct read access to the SAP HANA schema containing the production order data is available, and identify the schema owner, client handling, timestamp conventions, and authorization model. Use SAP HANA Database Explorer or an approved SQL client. Validate the relevant SAP S/4HANA release and activated production planning scope before finalizing the query.
- Configure the connection string, credentials, schema name, client value, extraction start date, extraction end date, and company specific filters. The query below uses AUFK, AFPO, JEST, and JCDS, and also references AFKO, AFVC, AFRU, RESB, MSEG, CDHDR, and CDPOS. Confirm the availability and field definitions of these objects in your system before execution, because extensions, compatibility views, and release specific differences can apply.
- Execute the query in SAP HANA Database Explorer or your approved SQL execution tool. The query creates one row for each explicitly extracted activity and combines the activity rows with UNION ALL. It does not rely on ProcessMind to infer events.
- Review the source data and adapt the marked system specific expressions where required. In particular, confirm the status codes used for material availability, capacity planning, technical completion, financial closure, and cancellation. Confirm the change document object and field names used to identify production plan adjustments.
- Validate timestamp conversion and client filtering. SAP systems can store dates and times in separate fields, and some installations use UTC while others use local plant or system time. Ensure that the resulting StartTime values use one consistent timezone and that invalid or initial SAP dates are excluded.
- Export the result as a flat file supported by ProcessMind, preferably CSV or UTF 8 delimited text. Preserve the exact output column names ProductionOrder, Activity, StartTime, SourceSystem, LastDataUpdate, MaterialNumber, Plant, WorkCenter, PlannedEndDate, and OrderStatus.
- Sort the exported rows by ProductionOrder and StartTime, with a deterministic secondary ordering for equal timestamps if your upload process supports it. Keep one row per event, including repeated confirmations and repeated status changes when they represent separate source records.
- Upload the file to ProcessMind and map ProductionOrder as the case identifier, Activity as the activity, and StartTime as the event timestamp. Map the remaining columns as event or case attributes according to the ProcessMind import configuration. Confirm that all 14 activity labels are retained exactly as produced by the query.
Configuration
- Date range: Start with a rolling three to six month period. Use a shorter period for initial testing and expand only after validating row counts and query performance.
- Extraction parameters: Replace [Your schema name], [Your client], [Extraction start date], [Extraction end date], and [Your source system name] with values from your environment. Apply company specific filters only after confirming the relevant organizational fields and values.
- Status configuration: Verify the exact SAP status codes and status object identifiers used in your system for CRTD, release, material availability, capacity planning, technical completion, financial closure, and cancellation. Status profiles and custom enhancements can change the available codes.
- Change documents: Confirm the production order change document object, table names, field names, and value formats used for quantity, dates, BOM, and routing changes. The query treats matching CDHDR and CDPOS records as plan adjustment evidence.
- Timestamp handling: Standardize all source timestamps to one timezone. Confirm whether date and time fields are stored separately, whether timestamps are local or UTC, and how initial dates are represented.
- Performance: Restrict the extraction by order creation date or another indexed production order date, filter by client, select only required columns, and execute during an appropriate reporting window. For large datasets, extract by month or by production order range and persist results incrementally.
- Database objects: Confirm that AUFK, AFPO, JEST, JCDS, AFKO, AFVC, AFRU, RESB, MSEG, CDHDR, and CDPOS are available and readable in the selected schema. If a view or field differs in your release, replace it with the corresponding released or approved object.
- Authorizations: Required access includes read authorization to the selected SAP HANA schema and objects, plus permission to execute SQL. SAP application authorizations may also be required by your governance process.
- Functional scope: Production planning and execution data, inventory movement data, status history, and change documents must be retained for the selected period. Archived or deleted records will not be returned.
- ProcessMind mapping: Configure ProductionOrder as the case identifier, Activity as the activity, and StartTime as the event timestamp. Do not expect ProcessMind to derive missing activities from attributes.
a Sample Query sql
WITH
params AS (
SELECT
'[Your client]' AS mandt,
TO_DATE('[Extraction start date]', 'YYYY-MM-DD') AS date_from,
TO_DATE('[Extraction end date]', 'YYYY-MM-DD') AS date_to,
'[Your source system name]' AS source_system,
CURRENT_UTCTIMESTAMP AS last_data_update
FROM DUMMY
),
orders AS (
SELECT
a.mandt,
LTRIM(a.aufnr, '0') AS production_order,
a.aufnr AS production_order_raw,
a.erdat AS order_created_date,
a.erfzeit AS order_created_time,
a.auart AS order_type,
a.werks AS plant,
a.objnr AS object_number,
a.ktext AS order_text,
p.matnr AS material_number,
p.psmng AS planned_quantity,
p.wemng AS delivered_quantity,
k.gstrp AS planned_start_date,
k.gltrp AS planned_end_date,
k.ftrmi AS release_date,
k.ftrmp AS release_time,
k.gamng AS total_order_quantity,
k.plnbez AS header_material_number,
k.plnty AS task_list_type,
k.plnnr AS task_list_group,
k.plnal AS task_list_group_counter
FROM [Your schema name].AUFK a
LEFT JOIN [Your schema name].AFPO p
ON p.mandt = a.mandt
AND p.aufnr = a.aufnr
LEFT JOIN [Your schema name].AFKO k
ON k.mandt = a.mandt
AND k.aufnr = a.aufnr
CROSS JOIN params x
WHERE a.mandt = x.mandt
AND a.erdat >= x.date_from
AND a.erdat < ADD_DAYS(x.date_to, 1)
),
status_history AS (
SELECT
o.*,
j.stat,
j.inact,
j.chgnr,
j.udate AS status_date,
j.utime AS status_time,
c.usnam AS status_user,
c.chind AS status_change_indicator
FROM orders o
INNER JOIN [Your schema name].JEST j
ON j.mandt = o.mandt
AND j.objnr = o.object_number
LEFT JOIN [Your schema name].JCDS c
ON c.mandt = j.mandt
AND c.objnr = j.objnr
AND c.stat = j.stat
AND c.chgnr = j.chgnr
WHERE COALESCE(j.inact, '') <> 'X'
),
operations AS (
SELECT
o.production_order,
o.mandt,
v.vornr,
v.arbid,
v.steus,
v.ltxa1,
v.aufpl,
v.aplzl,
cr.name1 AS work_center
FROM orders o
LEFT JOIN [Your schema name].AFVC v
ON v.mandt = o.mandt
AND v.aufpl = (SELECT MAX(k2.aufpl) FROM [Your schema name].AFKO k2 WHERE k2.mandt = o.mandt AND k2.aufnr = o.production_order_raw)
LEFT JOIN [Your schema name].CRHD cr
ON cr.mandt = v.mandt
AND cr.objty = 'A'
AND cr.objid = v.arbid
),
confirmations AS (
SELECT
o.production_order,
o.mandt,
r.rmzhl,
r.vornr,
r.budat AS confirmation_date,
r.ersda AS entry_date,
r.erzet AS entry_time,
r.ism01,
r.ism02,
r.ism03,
r.ism04,
r.ism05,
r.ism06,
r.xmnga,
r.stzhl,
r.stzhl AS reversal_counter,
r.lmnga AS confirmed_quantity,
r.xmnge AS scrap_quantity,
r.aufpl,
r.aplzl,
op.work_center
FROM orders o
INNER JOIN [Your schema name].AFRU r
ON r.mandt = o.mandt
AND r.aufnr = o.production_order_raw
LEFT JOIN operations op
ON op.production_order = o.production_order
AND op.mandt = r.mandt
AND op.vornr = r.vornr
),
first_confirmation AS (
SELECT production_order, MIN(TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS start_time
FROM confirmations
GROUP BY production_order
),
last_confirmation AS (
SELECT production_order, MAX(TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS final_time
FROM confirmations
GROUP BY production_order
),
first_goods_issue AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(m.budat_mkpf, 'YYYYMMDD') || LPAD(TO_VARCHAR(m.cputm_mkpf), 6, '0'), 'YYYYMMDDHH24MISS')) AS start_time
FROM orders o
INNER JOIN [Your schema name].MSEG m
ON m.mandt = o.mandt
AND m.aufnr = o.production_order_raw
AND m.bwart IN ('261', '262')
GROUP BY o.production_order
),
first_receipt AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(m.budat_mkpf, 'YYYYMMDD') || LPAD(TO_VARCHAR(m.cputm_mkpf), 6, '0'), 'YYYYMMDDHH24MISS')) AS receipt_time
FROM orders o
INNER JOIN [Your schema name].MSEG m
ON m.mandt = o.mandt
AND m.aufnr = o.production_order_raw
AND m.bwart IN ('101', '102')
GROUP BY o.production_order
),
plan_changes AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(h.udate, 'YYYYMMDD') || LPAD(TO_VARCHAR(h.utime), 6, '0'), 'YYYYMMDDHH24MISS')) AS adjustment_time
FROM orders o
INNER JOIN [Your schema name].CDHDR h
ON h.mandant = o.mandt
AND h.objectid = o.production_order_raw
INNER JOIN [Your schema name].CDPOS p
ON p.mandant = h.mandant
AND p.objectclas = h.objectclas
AND p.objectid = h.objectid
AND p.changenr = h.changenr
WHERE h.objectclas IN ('ORDER', 'PP_ORDER')
AND p.tabname IN ('AFKO', 'AFPO', 'AFVC', 'RESB')
AND p.fname IN ('GAMNG', 'PSMNG', 'GSTRP', 'GLTRP', 'MATNR', 'BDMNG', 'VORNR')
GROUP BY o.production_order
),
status_times AS (
SELECT
production_order,
MIN(CASE WHEN stat IN ('I0001', 'CRTD') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS created_status_time,
MIN(CASE WHEN stat IN ('I0002', 'REL') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS released_time,
MIN(CASE WHEN stat IN ('I0003', 'MATC', 'MANC') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS material_available_time,
MIN(CASE WHEN stat IN ('I0004', 'CAPC', 'CAPA') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS capacity_planned_time,
MIN(CASE WHEN stat IN ('I0045', 'TECO') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS technically_completed_time,
MIN(CASE WHEN stat IN ('I0046', 'CLSD') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS financially_closed_time,
MIN(CASE WHEN stat IN ('I0076', 'DLFL', 'CANC') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS cancelled_time
FROM status_history
GROUP BY production_order
),
material_shortages AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(j.status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(j.status_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS shortage_time
FROM status_history j
INNER JOIN orders o
ON o.production_order = j.production_order
WHERE j.stat IN ('I0042', 'MANC', 'MSHT')
GROUP BY o.production_order
),
capacity_times AS (
SELECT
production_order,
MIN(COALESCE(released_time, created_status_time)) AS capacity_time
FROM status_times
GROUP BY production_order
),
base_attributes AS (
SELECT
o.production_order,
o.material_number,
o.plant,
COALESCE(op.work_center, '') AS work_center,
o.planned_end_date,
COALESCE(st.stat, '') AS current_status
FROM orders o
LEFT JOIN status_history st
ON st.production_order = o.production_order
AND st.inact = ''
LEFT JOIN operations op
ON op.production_order = o.production_order
AND op.vornr = (SELECT MIN(op2.vornr) FROM operations op2 WHERE op2.production_order = o.production_order)
),
events AS (
SELECT o.production_order, 'Production Order Created' AS activity, COALESCE(st.created_status_time, TO_TIMESTAMP(TO_VARCHAR(o.order_created_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(o.order_created_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS start_time FROM orders o LEFT JOIN status_times st ON st.production_order = o.production_order
UNION ALL
SELECT production_order, 'Material Availability Checked', material_available_time FROM status_times WHERE material_available_time IS NOT NULL
UNION ALL
SELECT production_order, 'Capacity Requirements Planned', capacity_time FROM capacity_times WHERE capacity_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Order Released', released_time FROM status_times WHERE released_time IS NOT NULL
UNION ALL
SELECT o.production_order, 'Production Started', LEAST(COALESCE(fc.start_time, TO_TIMESTAMP('99991231235959', 'YYYYMMDDHH24MISS')), COALESCE(fg.start_time, TO_TIMESTAMP('99991231235959', 'YYYYMMDDHH24MISS'))) FROM orders o LEFT JOIN first_confirmation fc ON fc.production_order = o.production_order LEFT JOIN first_goods_issue fg ON fg.production_order = o.production_order WHERE fc.start_time IS NOT NULL OR fg.start_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Confirmation Entered', TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS') FROM confirmations
UNION ALL
SELECT production_order, 'Material Shortage Occurred', shortage_time FROM material_shortages WHERE shortage_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Plan Adjusted', adjustment_time FROM plan_changes WHERE adjustment_time IS NOT NULL
UNION ALL
SELECT c.production_order, 'Unplanned Halt Occurred', ADD_SECONDS(c.confirmation_time, 1) FROM (SELECT production_order, TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS') AS confirmation_time, LEAD(TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS')) OVER (PARTITION BY production_order ORDER BY entry_date, entry_time, rmzhl) AS next_confirmation_time FROM confirmations) c WHERE c.next_confirmation_time IS NOT NULL AND SECONDS_BETWEEN(c.confirmation_time, c.next_confirmation_time) >= 86400
UNION ALL
SELECT production_order, 'Final Confirmation Entered', final_time FROM last_confirmation WHERE final_time IS NOT NULL
UNION ALL
SELECT production_order, 'Goods Receipt Posted', receipt_time FROM first_receipt WHERE receipt_time IS NOT NULL
UNION ALL
SELECT production_order, 'Order Technically Completed', technically_completed_time FROM status_times WHERE technically_completed_time IS NOT NULL
UNION ALL
SELECT production_order, 'Order Financially Closed', financially_closed_time FROM status_times WHERE financially_closed_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Order Cancelled', cancelled_time FROM status_times WHERE cancelled_time IS NOT NULL
)
SELECT
e.production_order AS "ProductionOrder",
e.activity AS "Activity",
e.start_time AS "StartTime",
p.source_system AS "SourceSystem",
p.last_data_update AS "LastDataUpdate",
b.material_number AS "MaterialNumber",
b.plant AS "Plant",
NULLIF(b.work_center, '') AS "WorkCenter",
b.planned_end_date AS "PlannedEndDate",
b.current_status AS "OrderStatus"
FROM events e
INNER JOIN base_attributes b
ON b.production_order = e.production_order
CROSS JOIN params p
WHERE e.start_time IS NOT NULL
ORDER BY e.production_order, e.start_time, e.activity; Ready to Get Started?
Take the first step towards transforming your production planning efficiency. Prepare your data with this template and unlock valuable insights for optimization.
Start Optimizing Your Production Planning Today
Identify and eliminate bottlenecks, reduce production cycle time by 30%.
No credit card required