> Continuous Process Improvement > Quality Management > Oracle Quality Management > Data Template

Your Quality Management Data Template

Oracle Quality Management

Quality Management Attributes (21) Quality Management Activities (14) Extraction Guides (3)

Your Quality Management Data Template

This template provides a comprehensive guide to the essential data attributes and process activities needed for effective Quality Management analysis. It also includes practical guidance on how to extract this critical information from your Oracle Quality Management system. Use this resource to ensure you capture all necessary data for deep insights and process optimization.

Recommended attributes to collect
Key activities to track
Extraction guidance

New to event logs? Learn how to create a process mining event log.

Download Template

Quality Management Attributes

These are the recommended data fields and contextual information to include in your event log for comprehensive quality management analysis and insight.

3 Required 8 Recommended 10 Optional

	Name	Description
	Activity Name ActivityName	The name of the specific task or step that occurred within the quality management process.
Description This attribute describes a single event or action taken as part of managing a quality event. The sequence of these activities, ordered by their timestamps, forms the process flow for each case. Analyzing the Activity Name is central to process mining. It allows for the discovery of the actual process model, comparison against a desired model for conformance checking, and identification of bottlenecks or rework loops between specific activities. For example, it helps measure the time spent between 'Investigation Initiated' and 'Root Cause Analysis Performed'. Why it matters This attribute is fundamental for mapping the process flow, identifying deviations, and understanding how work is actually performed. Where to get This information is typically derived from event logs, status change records, or action history tables within the Oracle Quality Management module. Examples Quality Issue IdentifiedInvestigation InitiatedCorrective Action Plan ApprovedFinal Review and Closure
	Event Start Time EventStartTime	The timestamp indicating when an activity or event began.
Description This attribute provides the precise date and time that a specific process step started. It is the primary temporal element used to order events chronologically and build the process sequence for each quality event case. In analysis, the Event Start Time is crucial for calculating cycle times, durations, and waiting times between activities. It enables the identification of bottlenecks by highlighting long delays between consecutive steps and is used to track performance against time-based KPIs, such as Root Cause Analysis Lead Time. Why it matters This timestamp is the backbone of the process analysis, enabling all time-based calculations and the correct ordering of activities. Where to get This timestamp is typically found in transaction logs or history tables associated with quality actions and collection plans, often named CREATION_DATE or similar. Examples 2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
	Quality Event QualityEventId	The unique identifier for a single quality event, such as a non-conformance, complaint, or deviation.
Description The Quality Event ID serves as the primary case identifier, grouping all related activities from initial reporting to final closure. Each quality incident is assigned a unique ID, creating a complete historical record of the investigation and resolution process. In process mining analysis, this attribute is fundamental for reconstructing the end-to-end journey of each quality event. It allows for the calculation of overall cycle times, the identification of process variants, and the analysis of how different types of events are handled. By linking every activity log to a specific Quality Event ID, analysts can visualize the complete process flow and identify systemic bottlenecks or compliance issues. Why it matters This ID is essential as it defines the scope of a single case, enabling accurate tracking of quality events and calculation of end-to-end performance metrics. Where to get This is typically the primary key in the main quality event or collection plan tables within Oracle Quality Management, such as QA_RESULTS. Examples NC-2023-00123CAPA-45892QE-500-A
	Assigned User AssignedUser	The individual user assigned to perform an activity or own the quality event.
Description This attribute specifies the person responsible for a particular task or for the overall management of the quality event. It provides a more granular level of detail than the responsible department. Analyzing by user helps in understanding individual workloads, identifying training needs, and recognizing top performers. It can also reveal patterns such as work being consistently reassigned or tasks stalling with specific individuals. This level of detail is useful for performance management and detailed resource optimization. Why it matters It allows for granular analysis of individual workload and performance, helping to identify resource constraints or training opportunities. Where to get Consult Oracle Quality Management documentation. User assignment information is typically stored in action or workflow tables associated with the quality event. Examples j.smitha.jonesr.williams
	Current Status CurrentStatus	The current status of the quality event case.
Description This attribute indicates the present state of the quality event in its lifecycle, such as 'Open', 'Under Investigation', 'Pending Approval', or 'Closed'. It provides a snapshot of where the case is in the process at the time of data extraction. This is a critical attribute for operational monitoring, directly supporting the 'Open Quality Events & Status Overview' dashboard. It allows managers to quickly see the current pipeline of quality issues and prioritize resources. In process mining, filtering by the final status helps in analyzing the outcomes of different process paths. Why it matters It provides a real-time view of the quality event pipeline, enabling effective operational management and prioritization of active cases. Where to get This information is usually available in the main header table for quality events, reflecting the last known state of the event. Examples OpenIn ProgressAwaiting ApprovalClosed
	Event End Time EventEndTime	The timestamp indicating when an activity or event was completed.
Description The Event End Time marks the completion of a specific activity. When paired with the Event Start Time, it defines the processing time for that activity. For some systems, an activity may be instantaneous, in which case the start and end times are the same. This attribute is essential for detailed duration analysis. It allows analysts to differentiate between active processing time (the duration between start and end time) and waiting time (the duration between the end of one activity and the start of the next). This is key for identifying where resources are actively engaged and where handoffs cause delays. Why it matters It enables the precise calculation of activity processing times, which helps pinpoint inefficient tasks versus long waiting periods. Where to get This may be available in the same transaction or history tables as the start time, sometimes as a LAST_UPDATE_DATE or a specific completion timestamp. It might also be inferred from the start time of the subsequent event. Examples 2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
	Processing Time ProcessingTime	The duration of time spent actively working on an activity.
Description Processing Time is the duration calculated between the Event Start Time and the Event End Time for a single activity. It represents the active work time, as opposed to waiting time between activities. This metric is a core component of detailed performance analysis. By summing the processing times of all activities in a case, one can understand the total touch time. Comparing total touch time to the overall case cycle time reveals how much of the process is value-added work versus idle waiting time, a key insight for Lean and Six Sigma improvement efforts. Why it matters It isolates active work time from idle waiting time, helping to identify which specific tasks are time-consuming. Where to get This metric is calculated from the EventStartTime and EventEndTime attributes during data transformation. Examples PT15M30SPT2HP1D
	Responsible Department ResponsibleDepartment	The department or functional area responsible for the quality event or the current activity.
Description This attribute identifies the team or department assigned to handle the quality event. This could be Quality Assurance, Engineering, Production, or another group, and it may change as the event progresses through its lifecycle. In process mining, analyzing by Responsible Department is key to understanding workload distribution, identifying departmental bottlenecks, and comparing performance across different teams. It supports the 'Quality Event Resource Allocation' dashboard by showing which departments are involved in which types of activities, helping to optimize resource management. Why it matters It enables analysis of workload, performance, and bottlenecks by department, which is crucial for resource planning and organizational improvement. Where to get Consult Oracle Quality Management documentation. This may be stored in tables related to quality actions or assignments, linked to the quality event. Examples Quality EngineeringManufacturing OperationsSupplier QualityDesign Engineering
	Root Cause Category RootCauseCategory	The classification of the determined root cause of the quality issue.
Description After a root cause analysis is performed, the findings are often categorized into predefined groups like 'Equipment Failure', 'Human Error', or 'Design Flaw'. This attribute stores that final classification. Analyzing the process by Root Cause Category is extremely powerful. It helps shift the focus from fixing individual symptoms to addressing the underlying systemic problems. For example, a high number of events with a 'Training Issue' root cause can inform the need for better employee training programs, a key goal of preventive action. Why it matters This attribute is key to moving from reactive to proactive quality management by enabling analysis of the fundamental causes of failures. Where to get Consult Oracle Quality Management documentation. This is likely a user-defined element in a collection plan, populated after the 'Root Cause Analysis Performed' activity. Examples Equipment MalfunctionMaterial DefectHuman ErrorProcedure Not Followed
	Severity Level SeverityLevel	A classification of the quality event's impact, such as critical, major, or minor.
Description The Severity Level is an assessment, usually made during triage, of the potential impact of the quality issue on customers, compliance, or business operations. This classification helps in prioritizing resources and defining the urgency of the required response. In process mining, this attribute is crucial for segmentation. Analysts can compare the process flows, cycle times, and outcomes for high-severity events versus low-severity ones. This supports the 'Quality Event Triage Consistency' dashboard and the 'Severity-Based Resolution Rate' KPI by revealing if critical issues are indeed being handled more quickly and effectively. Why it matters It allows for prioritization and segmentation of analysis, ensuring that high-impact quality events are managed effectively and efficiently. Where to get Consult Oracle Quality Management documentation. This is often a configurable element within a quality collection plan. Examples 1 - Critical2 - Major3 - Minor4 - Informational
	Target Resolution Date TargetResolutionDate	The planned or expected date for the final closure of the quality event.
Description This attribute represents the deadline by which a quality event is expected to be fully resolved. It serves as a service level agreement (SLA) or internal target, often determined based on the event's severity or type. This date is fundamental for performance monitoring and is used directly in calculating the 'CAPA Impl. On-Time Rate' KPI. By comparing the actual completion dates of activities against this target, analysts can measure timeliness, identify events at risk of being late, and track trends in on-time performance. This supports efforts to reduce resolution cycle times. Why it matters It provides a benchmark for measuring on-time performance and is essential for calculating timeliness KPIs and managing SLAs. Where to get Consult Oracle Quality Management documentation. This may be a standard date field or a user-defined element in the quality collection plan. Examples 2023-05-302023-06-152024-01-10
	Business Unit BusinessUnit	The business unit or division of the organization where the quality event occurred or is being managed.
Description This attribute assigns the quality event to a specific part of the business structure. It helps to analyze and compare quality performance across different organizational units. Segmenting process analysis by Business Unit is a common requirement for large enterprises. It allows for BU-specific dashboards and helps identify if certain divisions have more efficient quality processes or are facing unique challenges. This is valuable for corporate oversight and for sharing best practices across the organization. Why it matters It enables performance comparison and analysis across different parts of the organization, supporting enterprise-wide quality management. Where to get This is typically part of the organizational context data associated with the transaction, often derived from the user or department's master data. Examples Medical DevicesConsumer ElectronicsAutomotive Parts
	Closure Code ClosureCode	A code indicating the reason or outcome of the quality event's closure.
Description When a quality event is closed, a closure code is often assigned to classify the final outcome. Examples include 'Action Effective', 'No Action Required', or 'Duplicate Issue'. This attribute is very useful for outcome analysis. By filtering on different closure codes, analysts can study the process paths that lead to successful outcomes versus those that do not. It can help answer questions like, 'What does our process look like for issues that are closed as duplicates?' and identify inefficiencies in the triage process. Why it matters It provides crucial information about the outcome of a case, enabling analysis of which process paths lead to successful resolutions. Where to get Consult Oracle Quality Management documentation. This would likely be a field populated during the final closure activity. Examples EFFECTIVENO_ACTIONDUPLICATERISK_ACCEPTED
	Corrective Action Plan ID CorrectiveActionPlanId	The unique identifier for the corrective action plan (CAPA) created to address the quality event.
Description This attribute provides a direct link between a quality event and the specific corrective and preventive action plan designed to resolve it. This is often a separate object in the system with its own lifecycle. In analysis, this ID can be used to join data from the quality event process with data from the CAPA management process, creating a more holistic view. It helps in tracking whether every event that requires a CAPA has one assigned and in analyzing the effectiveness of those actions. Why it matters It links the problem (quality event) with the solution (CAPA), enabling a more comprehensive end-to-end analysis of the quality management system. Where to get This would be a reference field on the quality event record that points to a record in a CAPA-specific table or module. Examples CAPA-2023-088CAPA-2023-091
	Is On Time IsOnTime	A flag indicating whether a corrective action was implemented by its target resolution date.
Description This boolean attribute is derived by comparing the completion timestamp of the 'Corrective Action Implemented' activity with the 'Target Resolution Date' for the case. It is true if the action was completed on or before the target date, and false otherwise. This attribute directly supports the 'CAPA Impl. On-Time Rate' KPI. It simplifies analysis and dashboard creation by providing a clear, binary classification for each case's timeliness. It allows for easy filtering and aggregation to monitor adherence to service levels and identify the root causes of delays. Why it matters It simplifies the tracking of on-time performance against targets, making it easy to measure and report on this critical KPI. Where to get This is a derived flag calculated during data transformation. It requires the TargetResolutionDate and the timestamp of the relevant completion activity. Examples truefalse
	Is Rework IsRework	A flag indicating if an activity is a repetition or rework of a previous step in the same case.
Description This attribute is a boolean flag that is set to true if a specific activity, like 'Corrective Action Plan Proposed', occurs more than once within a single quality event case. This indicates a loop or correction in the process, where a previously completed step had to be redone. Identifying rework is a key capability of process mining. This flag simplifies the quantification of such inefficiencies and directly supports the 'Activity Rework Frequency' KPI. Analyzing which steps are most prone to rework and under what conditions can uncover issues with training, data quality, or approval criteria, highlighting opportunities to make the process more efficient. Why it matters It flags process inefficiencies and loops, helping to quantify waste and identify the root causes of rework. Where to get This is calculated using window functions or sequential analysis on the event log during data preparation. It identifies when the same activity name appears multiple times for the same case. Examples truefalse
	Issue Category IssueCategory	The category or type of the quality issue, such as 'Product Defect' or 'Process Deviation'.
Description This attribute provides a classification of the quality event, which helps in grouping similar issues for analysis. The categories are typically defined by the organization to reflect their specific operational context. Analyzing the process by Issue Category allows for the identification of patterns related to specific types of problems. For example, it might reveal that 'Supplier Material' issues have a much longer cycle time than 'Internal Process' issues. This segmentation is valuable for targeted process improvement initiatives. Why it matters Categorizing issues enables targeted analysis to identify trends and root causes for specific problem areas. Where to get Consult Oracle Quality Management documentation. This is likely a user-defined element within the quality collection plan. Examples Product DefectProcess DeviationSupplier MaterialCustomer Complaint
	Last Data Update LastDataUpdate	The timestamp of the most recent data refresh or update from the source system.
Description This attribute indicates the last time the data for this event was updated in the process mining dataset. It reflects the freshness of the data and helps users understand the timeliness of the analysis. In dashboards and reports, this timestamp is critical for providing context to the user. It clarifies whether they are looking at real-time data or a snapshot from a specific point in time, which is essential for making informed operational decisions. It ensures transparency about the data's currency. Why it matters This timestamp provides transparency on data freshness, ensuring users understand how current the process analysis is. Where to get This value is generated and stored during the data ETL process, typically representing the timestamp when the data pipeline last ran successfully. Examples 2023-10-27T04:00:00Z2023-10-26T04:00:00Z
	Product Identifier ProductIdentifier	The identifier for the product associated with the quality event.
Description This attribute links the quality event to a specific product, material, or service. It could be a product code, SKU, or part number. This link is crucial for product quality analysis. Process mining can be used to compare quality management processes across different product lines or to identify products that are frequently associated with quality issues. This helps in prioritizing engineering or manufacturing improvement efforts where they are needed most. Why it matters It connects quality events to specific products, enabling analysis of product-related quality trends and process variations. Where to get This information would be stored in a field within the quality collection plan, often linked to the Oracle Inventory item master. Examples SKU-100-A-REDPN-987654CHEM-X2
	Source System SourceSystem	Identifies the system of record from which the data was extracted.
Description This attribute specifies the originating application or system for the event data. In an enterprise environment, quality event data might come from multiple sources, such as the core Oracle Quality module, a separate CAPA system, or a customer complaint portal. For analysis, this field helps in understanding data lineage and can be used to segment the process based on the system of origin. It is crucial for data governance and for troubleshooting data integration issues, ensuring that the process view accurately reflects the combined data landscape. Why it matters It provides crucial context about data origin, which is important for data validation, governance, and analyzing process variations across different systems. Where to get This is typically a static value added during the data extraction, transformation, and loading (ETL) process to label the dataset's origin. Examples Oracle Quality Management R12Oracle EBS QualityQM-PROD
	Total Cycle Time TotalCycleTime	The total time elapsed from the identification of a quality issue to its final closure.
Description This attribute measures the full end-to-end duration for a single quality event case. It is calculated as the difference between the timestamp of the very first activity ('Quality Issue Identified') and the very last activity ('Final Review and Closure'). This is a primary key performance indicator (KPI) for the overall efficiency of the quality management process. It is the main metric for the 'Quality Event End-to-End Cycle Time' dashboard. Tracking this metric over time and segmenting it by attributes like Severity or Issue Category provides a high-level view of process health and the impact of improvement initiatives. Why it matters This is a critical KPI that measures the overall speed and efficiency of the entire quality management process from start to finish. Where to get This is calculated at the case level during data processing for process mining. It requires the start time of the first event and the end time of the last event for each QualityEventId. Examples P30DT12HP15DP92D

Required Recommended Optional

Quality Management Activities

These are the key process steps and significant milestones to capture in your event log for accurate process discovery and performance evaluation.

6 Recommended 8 Optional

	Activity	Description
	Corrective Action Plan Approved	Represents the formal approval of the proposed corrective action plan by a designated authority. This is a critical control point, usually captured by an explicit approval action or a status change to 'Approved'.
Why it matters This approval is a key milestone and a frequent bottleneck. Analyzing approval times helps streamline the process and ensure compliance with procedures. Where to get Inferred from a status change on the Quality Action or CAPA record to 'Approved'. Oracle systems with approval workflows often log this change explicitly in audit tables. Capture Inferred from a status change to 'Approved'. Event type inferred
	Effectiveness of Action Verified	Confirms that the implemented corrective action has successfully resolved the root cause and prevented recurrence. This is captured when a user completes the verification step and updates the record's status.
Why it matters This is a critical outcome-based milestone and the basis for the 'Effectiveness Verif. Rate' KPI. It closes the loop on the corrective action cycle, ensuring problems are truly solved. Where to get Inferred from a status change on the CAPA record to 'Verification Complete' or 'Effective'. This might also involve populating specific verification result fields. Capture Inferred from status change to 'Verification Complete' or 'Effective'. Event type inferred
	Final Review and Closure	The final step where all related actions are confirmed complete and the parent quality issue is formally closed. This is captured by a final status change to 'Closed' or 'Resolved' on the primary record.
Why it matters This is the primary end event for the process. It is essential for calculating the 'Average Event Cycle Time' KPI and for measuring overall process throughput. Where to get Inferred from the final status change on the parent Quality Issue record to 'Closed'. The timestamp of this change serves as the event time. Capture Inferred from a status change to 'Closed' on the main Quality Issue record. Event type inferred
	Investigation Initiated	Marks the official start of the investigation phase to determine the root cause of the quality issue. This is usually represented by a status change in the system, such as moving to 'Under Investigation'.
Why it matters This serves as the starting point for measuring the 'Root Cause Analysis Lead Time' KPI and helps identify how long issues wait before a formal investigation begins. Where to get Inferred from a status change on the Quality Issue or an associated Quality Action record to an 'Investigation' status. The timestamp of this status change provides the event time. Capture Inferred from a status change to 'Under Investigation' or a similar state. Event type inferred
	Issue Categorized and Prioritized	This activity occurs when an analyst completes the initial assessment, assigning key attributes like severity, priority, and issue type. It is typically captured when the issue transitions from a 'New' status to an 'Assessed' or 'In Triage' status.
Why it matters This milestone is crucial for the 'Avg Triage Processing Time' KPI. Delays here can slow down the entire resolution process, especially for critical issues. Where to get Inferred from a status change on the Quality Issue record, for example, from 'New' to 'Under Assessment', or when fields like 'Severity' or 'Priority' are first populated. Capture Inferred from status change or first population of Severity or Priority fields. Event type inferred
	Quality Issue Identified	This activity marks the creation of a new quality event record, such as a non-conformance, deviation, or customer complaint. It is captured explicitly when a user creates a new Quality Issue or Quality Action record in Oracle.
Why it matters As the start event, it is essential for calculating the total cycle time of the quality management process and for understanding the volume of incoming quality events. Where to get This event is captured from the creation timestamp of the Quality Issue or Quality Action record, likely found in tables such as QAM_QUALITY_ISSUES or QAM_QUALITY_ACTIONS. Capture Event logged upon creation of a new Quality Issue or Action record. Event type explicit
	Corrective Action Implemented	Marks the completion of the tasks outlined in the approved corrective action plan. This is typically captured when a user updates the status of the corrective action record to 'Implemented' or 'Completed'.
Why it matters This activity is vital for the 'CAPA Impl. On-Time Rate' KPI, as it signifies that the planned fix has been executed and allows for comparison against target dates. Where to get This event is inferred from a status change of the associated Quality Action or CAPA record to 'Implemented' or 'Completed'. Capture Inferred from status change to 'Implemented' or 'Completed'. Event type inferred
	Corrective Action Plan Proposed	Occurs when corrective actions are defined and linked to the quality issue, outlining the steps to fix the problem. This can be the creation of a related Corrective Action record or a status change indicating a plan is ready for review.
Why it matters This tracks the transition from problem analysis to solution design. Rework involving this step, measured by rework KPIs, can indicate unclear requirements or ineffective planning. Where to get This could be an explicit event from creating a new Corrective Action record within a CAPA object, or an inferred event from a status change to 'Plan Proposed' or 'Pending Approval'. Capture Inferred from a status change to 'Pending Approval' or creation of a linked Corrective Action. Event type inferred
	Effectiveness Check Required	Represents the system or a user flagging that the implemented action requires a follow-up verification to ensure it was effective. This is often an automatic or manual status change that occurs after implementation.
Why it matters This step initiates the crucial verification phase. Understanding the time between implementation and this activity can highlight delays in initiating necessary follow-ups. Where to get This event is inferred from a status change on the Quality Action to 'Pending Effectiveness Check' or a similar state within the workflow. Capture Inferred from status change to 'Pending Effectiveness Check'. Event type inferred
	Issue Assigned For Triage	Represents the assignment of the newly created quality issue to a specific user or team for initial review and assessment. This event is often inferred by tracking changes to the assignee or owner field of the quality issue record.
Why it matters Tracking this initial handoff helps identify delays before assessment begins. Analyzing the time spent in this state reveals potential backlogs in the triage queue. Where to get Inferred from changes in the owner or assignee field within the Quality Issue record. This may be sourced from audit trail tables or by tracking status changes associated with assignment workflows. Capture Inferred from a change in the 'Assigned To' or 'Owner' field on the Quality Issue. Event type inferred
	Preventive Action Identified	Represents the creation of a preventive action (PA) to address systemic issues and prevent similar quality events from occurring. This is often logged as the creation of a new Preventive Action record linked to the original issue.
Why it matters This activity shows a mature quality process that moves beyond fixing single issues to preventing future ones. Tracking this helps measure proactive quality improvements. Where to get Captured from the creation of a new Quality Action record with a type of 'Preventive Action', often linked to the original Quality Issue or Corrective Action. Capture Logged upon creation of a 'Preventive Action' type Quality Action record. Event type explicit
	Preventive Action Implemented	Marks the completion of tasks defined in the preventive action plan to mitigate systemic risks. This is captured when a user updates the status of the preventive action record to 'Implemented' or 'Completed'.
Why it matters Measures the organization's ability to execute proactive quality improvements. Delays here can indicate a struggle to implement systemic changes across the organization. Where to get Inferred from a status change of the associated Preventive Action record to 'Implemented' or 'Completed', similar to how corrective actions are tracked. Capture Inferred from status change to 'Implemented' on a Preventive Action record. Event type inferred
	Root Cause Analysis Performed	Represents the completion of the root cause analysis (RCA) and the documentation of findings. This is typically captured when the investigation team updates the quality issue with the identified root cause and changes its status.
Why it matters This activity is the endpoint for the 'Root Cause Analysis Lead Time' KPI. Analyzing the duration leading to this step helps pinpoint bottlenecks in the problem-solving phase. Where to get Inferred from a status change to 'RCA Complete' or when the root cause category field is populated and the record is saved. The timestamp of this update is used. Capture Inferred from status change to 'RCA Complete' or population of root cause fields. Event type inferred
	Stakeholders Notified of Resolution	Represents communicating the resolution of the quality event to relevant parties, such as the reporter or affected customers. This is difficult to capture and may be inferred from a post-closure status change or a logged comment.
Why it matters Crucial for the 'Stakeholder Notification Lag' KPI. Timely communication is important for customer satisfaction and internal transparency, even after an issue is resolved. Where to get This is often difficult to capture automatically. It might be inferred from a status like 'Notification Sent' or logged in an activity or comments field, requiring special logic to extract. Capture Inferred from a specific status change or potentially text mining of activity logs. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Oracle Quality Management

Steps

Access Oracle BI Publisher: Log into your Oracle E-Business Suite instance and navigate to the responsibility that provides access to BI Publisher, such as BI Publisher Administrator or a similar custom responsibility.
Create a New Data Model: From the BI Publisher home page, select Create and then choose Data Model. This will open the data model editor.
Define a SQL Query Dataset: In the data model editor, click the plus icon on the Data Sets panel and select SQL Query. This will open the SQL query editor window.
Configure the Data Source: In the New Data Set window, provide a name for your dataset, for example, DS_QUALITY_EVENTS. Select the appropriate Oracle EBS database as the Data Source.
Enter the SQL Query: Copy the complete SQL query provided in the 'query' section of this document and paste it into the SQL Query text area.
Define Query Parameters: The provided query uses placeholders :P_START_DATE and :P_END_DATE for the reporting period. In the BI Publisher data model, you must define these as parameters. For each, create a new parameter, give it the corresponding name (e.g., P_START_DATE), set the Data Type to Date, and configure a user-friendly display prompt.
Save the Data Model: After pasting the query and defining parameters, save the data model. It is recommended to save it in a shared folder for reports.
Create a New Report: Navigate back to the BI Publisher home page and select Create, then choose Report. Select the 'Use Data Model' option and find the data model you just saved.
Configure Report Layout: The report wizard will guide you through the layout configuration. For ProcessMind, a simple table layout is sufficient. Drag and drop all columns from the data model into the report layout. Ensure the output format is configured for CSV.
Set Report Properties: Under the report's properties, ensure the 'Enable CSV Output' option is checked. You can also define default parameter values if needed.
Run and Export the Report: Save the report, then run it by providing the desired start and end dates. Once the report generation is complete, click the Export button and select CSV as the output format. The file will be downloaded to your local machine.
Prepare for Upload: Open the downloaded CSV file to ensure it contains the expected data. Verify that the column headers match the ProcessMind schema requirements. The file is now ready to be uploaded.

Configuration

Prerequisites: A user account with access to Oracle BI Publisher and read access to the underlying Quality module tables (e.g., QA_RESULTS, QA_PLANS, QA_ACTIONS, FND_USER).
Data Source Configuration: The BI Publisher data model must be configured to connect to your primary Oracle EBS application database (APPS schema).
Date Range Parameters: The query is designed with two mandatory parameters, :P_START_DATE and :P_END_DATE, to filter the data extract. For an initial analysis, a range of 6 to 12 months is recommended to capture enough complete cases. Format the date as 'YYYY-MM-DD'.
Output Format: The report must be configured to allow CSV output. This format is optimal for ProcessMind ingestion as it is simple, structured, and avoids complex parsing.
Scheduling: For continuous process monitoring, schedule the BI Publisher report to run on a recurring basis, for example, daily or weekly. Configure the output to be delivered to a designated server or content repository for automated pickup.
Performance: For instances with very high volumes of quality events, the query may take a significant time to run. Ensure that the date range is reasonable and consider discussing query optimization or table indexing with your database administrator if performance is a concern.

a Sample Query config

SELECT
    qr.occurrence AS QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    qr.creation_date AS EventStartTime,
    qr.last_update_date AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate, -- Or a dedicated target date field
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.created_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

-- Activities based on status changes are best captured from an audit table if available. 
-- This example uses LAST_UPDATE_DATE which is an approximation.
SELECT
    qr.occurrence AS QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Assigned', 'In Triage') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Assessed', 'Prioritized') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Investigation Initiated' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Under Investigation' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qpc_rc.char_value IS NOT NULL AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

-- Corrective and Preventive Actions from a table like QA_ACTIONS
SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    qa.creation_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.assignee_id = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.status_code = 'Approved' AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.status_code IN ('Implemented', 'Completed') AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Verification Pending' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Verification Complete' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    qa.creation_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.assignee_id = fu.user_id
WHERE qa.action_code = 'PREVENTIVE_ACTION' AND qa.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'PREVENTIVE_ACTION' AND qa.status_code IN ('Implemented', 'Completed') AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Final Review and Closure' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Closed', 'Resolved') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Notification Sent' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

Steps

Prerequisites: Ensure you have a database client (like SQL Developer or DBeaver) and read-only credentials for the Oracle database hosting the Quality Management module.
Understand the Schema: Familiarize yourself with key Oracle Quality tables. The query primarily uses QA_RESULTS for the quality event headers, QA_PLANS for the plan definitions, QA_RESULTS_V for a combined view of results and their values, and application user tables like FND_USER or PER_ALL_PEOPLE_F.
Define Query Parameters: Before running the query, locate the placeholder variables within the WHERE clause. You must replace :start_date, :end_date, and :organization_id with the appropriate values for your extraction scope. For example, set :start_date to '2023-01-01' and :end_date to '2023-06-30'.
Execute the SQL Query: Copy the complete SQL script and execute it in your database client. The script uses multiple UNION ALL clauses to gather different events into a single, unified event log format.
Review the Raw Data: After execution, review the output. Each row represents a single activity in the lifecycle of a quality event. Check for completeness and the presence of data in key columns like QualityEventId, ActivityName, and EventStartTime.
Handle Timestamps and Durations: The query provides EventStartTime. The EventEndTime is intentionally left as NULL because determining the end time for one event often requires knowing the start time of the next. This calculation is typically best handled in the process mining tool or a post-processing script. Similarly, ProcessingTime is set to NULL as it requires calculation based on start and end times.
Export to CSV: Export the complete result set from your SQL client to a CSV file. Ensure the file uses UTF-8 encoding and includes a header row with the column aliases from the query.
Prepare for Upload: Verify the CSV column headers match the requirements of the ProcessMind platform (Case ID, Activity, Start Timestamp). Rename the columns QualityEventId, ActivityName, and EventStartTime accordingly before uploading.

Configuration

Database Access: The user running the query must have SELECT privileges on all tables referenced in the script, which may include tables in the APPS, QA, PER, and HR schemas.
Key Query Filters: The query contains critical placeholders that must be configured:
- :start_date: The beginning of the reporting period. The query filters for events created on or after this date.
- :end_date: The end of the reporting period.
- :organization_id: The specific Oracle organization identifier you want to analyze. Quality plans and results are often tied to an organization.
Date Range: For an initial analysis, a date range of 3 to 6 months of data is recommended. For large, high-volume systems, start with a smaller period, like one month, to assess query performance before running a larger extraction.
Performance Considerations: This query joins several large tables and unions 14 separate result sets. It can be resource-intensive. Schedule the extraction during off-peak hours to minimize impact on system performance. If performance is poor, consult a database administrator about indexing key columns, especially date and foreign key columns.

a Sample Query sql

WITH QualityEventBase AS (
    SELECT
        qr.COLLECTION_ID,
        qr.PLAN_ID,
        qp.NAME AS PLAN_NAME,
        qr.ORGANIZATION_ID,
        qr.CREATION_DATE,
        qr.LAST_UPDATE_DATE,
        qr.CREATED_BY,
        qr.LAST_UPDATED_BY,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_STATUS') AS CurrentStatus,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_SEVERITY') AS SeverityLevel,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_ROOT_CAUSE') AS RootCauseCategory,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_DEPT') AS ResponsibleDepartment,
        (SELECT qrv.DATE1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_TARGET_DATE') AS TargetResolutionDate,
        (SELECT fu.USER_NAME FROM FND_USER fu WHERE fu.USER_ID = qr.LAST_UPDATED_BY) AS AssignedUser
    FROM
        QA_RESULTS qr
    JOIN
        QA_PLANS qp ON qr.PLAN_ID = qp.PLAN_ID
    WHERE
        qr.CREATION_DATE BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND qr.ORGANIZATION_ID = :organization_id
)
-- 1. Quality Issue Identified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    qeb.CREATION_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb

UNION ALL

-- 2. Issue Assigned For Triage (Approximation: first update after creation)
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'TRIAGE' AND qeb.LAST_UPDATE_DATE > qeb.CREATION_DATE

UNION ALL

-- 3. Issue Categorized and Prioritized
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'ASSESSED' AND qeb.SeverityLevel IS NOT NULL

UNION ALL

-- 4. Investigation Initiated
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Investigation Initiated' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'UNDER_INVESTIGATION'

UNION ALL

-- 5. Root Cause Analysis Performed
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'RCA_COMPLETE' AND qeb.RootCauseCategory IS NOT NULL

UNION ALL

-- 6. Corrective Action Plan Proposed
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_PROPOSED'

UNION ALL

-- 7. Corrective Action Plan Approved
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_APPROVED'

UNION ALL

-- 8. Corrective Action Implemented
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_IMPLEMENTED'

UNION ALL

-- 9. Effectiveness Check Required
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'EFFECTIVENESS_CHECK'

UNION ALL

-- 10. Effectiveness of Action Verified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'VERIFIED'

UNION ALL

-- 11. Preventive Action Identified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'PAPA_DEFINED'

UNION ALL

-- 12. Preventive Action Implemented
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'PAPA_IMPLEMENTED'

UNION ALL

-- 13. Final Review and Closure
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Final Review and Closure' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CLOSED'

UNION ALL

-- 14. Stakeholders Notified of Resolution (Approximation)
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    qeb.LAST_UPDATE_DATE + interval '1' minute AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CLOSED'

Steps

Prepare Your Environment: Ensure you have Python 3.6 or newer installed on your system. Install the necessary libraries using pip: pip install pandas oracledb. These libraries are required for connecting to the Oracle database and for data manipulation.
Obtain Database Credentials: Secure the required connection details for your Oracle Quality Management database. This includes the username, password, and the Data Source Name (DSN) which typically follows the format hostname:port/service_name.
Save the Extraction Script: Copy the complete Python script provided in the 'query' section and save it as a file, for example, extract_quality_events.py.
Configure the Script: Open the saved script in a text editor. Locate the configuration section at the top and replace the placeholder values for db_user, db_password, db_dsn, start_date, and end_date with your specific details.
Customize SQL Placeholders: Review the SQL query within the script. You may need to adjust table names like QA_RESULTS or specific status values like 'NEW' and 'CLOSED' to match your organization's Oracle configuration. Consult with your Oracle system administrator if you are unsure of these values.
Execute the Script: Open a command prompt or terminal, navigate to the directory where you saved the script, and run it using the command: python extract_quality_events.py.
Monitor Execution: The script will connect to the database, execute the query, and process the data. Depending on the date range and data volume, this may take several minutes. Look for a 'Successfully connected to Oracle Database!' message and a final 'Event log saved to quality_event_log.csv' message.
Retrieve the Output File: Once the script completes, a file named quality_event_log.csv will be created in the same directory. This file contains the extracted event log.
Review the Event Log: Open the quality_event_log.csv file in a spreadsheet application to perform a quick review. Check for the expected columns and that data appears to be populated correctly for a few sample cases.
Upload to Process Mining Tool: The generated CSV file is now ready to be uploaded to your process mining application for analysis.

Configuration

Database Connection: The script requires an Oracle Data Source Name (DSN), username, and password with read access to the necessary Quality Management tables (e.g., QA_RESULTS, QA_PLANS, FND_USER, PER_ALL_PEOPLE_F).
Date Range Filtering: The start_date and end_date variables in the script are critical for controlling the data volume. It is recommended to start with a smaller range, such as 3-6 months, to ensure performance and validate the output before running a larger extraction.
System-Specific Filters: The SQL query can be further customized to include filters based on your organizational structure. For example, you can add a WHERE clause to filter by ORGANIZATION_ID to limit the extraction to a specific plant or business unit.
Status Code Mapping: The activity extraction logic relies on mapping specific status values (e.g., 'NEW', 'UNDER_INVESTIGATION', 'CLOSED') to process steps. These values are highly specific to your Oracle configuration and must be verified and adjusted in the SQL query for accuracy.
Python Dependencies: The script depends on the pandas and oracledb libraries. Ensure these are installed in the Python environment where the script will be executed.

a Sample Query python

import pandas as pd
import oracledb
import sys

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle database credentials and connection details
db_user = class="hl-string">"your_username"
db_password = class="hl-string">"your_password"
class=class="hl-string">"hl-comment"># DSN (Data Source Name) format: hostname:port/service_name
db_dsn = class="hl-string">"your_host:1521/your_service_name"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SQL Query --- 
class=class="hl-string">"hl-comment"># This query extracts events from the Oracle Quality Management module.
class=class="hl-string">"hl-comment"># Each SELECT statement with a UNION ALL corresponds to a specific activity.
sql_query = fclass="hl-string">"""
WITH base_events AS (
    SELECT 
        qr.COLLECTION_ID AS QualityEventId,
        qr.LAST_UPDATE_DATE,
        qr.CREATION_DATE,
        qpc.PROMPT AS StatusPrompt,
        qr.CHARACTER1 AS CurrentStatus,
        qr.CHARACTER2 AS SeverityLevel,
        qr.CHARACTER3 AS RootCauseCategory,
        oap.NAME AS ResponsibleDepartment,
        fu.USER_NAME AS AssignedUser,
        qr.DATE1 AS TargetResolutionDate,
        (qr.LAST_UPDATE_DATE - qr.CREATION_DATE) * 24 * 60 AS ProcessingTime
    FROM 
        QA_RESULTS qr
    JOIN 
        QA_PLANS qp ON qr.PLAN_ID = qp.PLAN_ID
    JOIN 
        QA_PLAN_CHARS qpc ON qp.PLAN_ID = qpc.PLAN_ID AND qpc.PROMPT = 'Status'
    LEFT JOIN 
        FND_USER fu ON qr.LAST_UPDATED_BY = fu.USER_ID
    LEFT JOIN
        HR_ALL_ORGANIZATION_UNITS oap ON qr.ORGANIZATION_ID = oap.ORGANIZATION_ID
    WHERE 
        qr.CREATION_DATE BETWEEN TO_DATE('{start_date}', 'YYYY-MM-DD') AND TO_DATE('{end_date}', 'YYYY-MM-DD')
)
-- 1. Quality Issue Identified
SELECT
    be.QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    be.CREATION_DATE AS EventStartTime,
    be.CREATION_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    'New' AS CurrentStatus, -- Initial status
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be

UNION ALL

-- 2. Issue Assigned For Triage (approximated by first update after creation)
SELECT
    be.QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.LAST_UPDATE_DATE > be.CREATION_DATE AND be.CurrentStatus IN ('Assigned', '[Your Triage Status]')

UNION ALL

-- 3. Issue Categorized and Prioritized
SELECT
    be.QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus IN ('Assessed', 'Prioritized', '[Your Categorized Status]')

UNION ALL

-- 4. Investigation Initiated
SELECT
    be.QualityEventId,
    'Investigation Initiated' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus IN ('Under Investigation', 'Investigation')

UNION ALL

-- 5. Root Cause Analysis Performed
SELECT
    be.QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'RCA Complete' AND be.RootCauseCategory IS NOT NULL

UNION ALL

-- 6. Corrective Action Plan Proposed
SELECT
    be.QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Proposed'

UNION ALL

-- 7. Corrective Action Plan Approved
SELECT
    be.QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Approved'

UNION ALL

-- 8. Corrective Action Implemented
SELECT
    be.QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Implemented'

UNION ALL

-- 9. Effectiveness Check Required
SELECT
    be.QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Verification Pending'

UNION ALL

-- 10. Effectiveness of Action Verified
SELECT
    be.QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Verified Effective'

UNION ALL

-- 11. Preventive Action Identified
SELECT
    be.QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'PA Identified'

UNION ALL

-- 12. Preventive Action Implemented
SELECT
    be.QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'PA Implemented'

UNION ALL

-- 13. Final Review and Closure
SELECT
    be.QualityEventId,
    'Final Review and Closure' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Closed'

UNION ALL

-- 14. Stakeholders Notified of Resolution
SELECT
    be.QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    be.LAST_UPDATE_DATE + interval '1' day AS EventStartTime, -- Approximated as 1 day after closure
    be.LAST_UPDATE_DATE + interval '1' day AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Closed'
"""

class=class="hl-string">"hl-comment"># --- Main Execution Logic ---
try:
    class=class="hl-string">"hl-comment"># Establish the database connection
    with oracledb.connect(user=db_user, password=db_password, dsn=db_dsn) as connection:
        print(class="hl-string">"Successfully connected to Oracle Database!")
        
        class=class="hl-string">"hl-comment"># Execute the query and load data into a pandas DataFrame
        print(class="hl-string">"Executing query... This may take a few minutes.")
        df = pd.read_sql_query(sql_query, connection)
        print(fclass="hl-string">"Query finished. {len(df)} events extracted.")

        class=class="hl-string">"hl-comment"># Data Type Conversion
        df[class="hl-string">'EVENTSTARTTIME'] = pd.to_datetime(df[class="hl-string">'EVENTSTARTTIME'])
        df[class="hl-string">'EVENTENDTIME'] = pd.to_datetime(df[class="hl-string">'EVENTENDTIME'])
        df[class="hl-string">'TARGETRESOLUTIONDATE'] = pd.to_datetime(df[class="hl-string">'TARGETRESOLUTIONDATE'])

        class=class="hl-string">"hl-comment"># Sort the data for chronological order
        df = df.sort_values(by=[class="hl-string">'QUALITYEVENTID', class="hl-string">'EVENTSTARTTIME'], ascending=[True, True])

        class=class="hl-string">"hl-comment"># Save the DataFrame to a CSV file
        output_filename = class="hl-string">'quality_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
        print(fclass="hl-string">"Event log saved to {output_filename}")

except oracledb.DatabaseError as e:
    error, = e.args
    print(fclass="hl-string">"Database connection or query failed: {error.message}", file=sys.stderr)
    sys.exit(1)
except Exception as e:
    print(fclass="hl-string">"An unexpected error occurred: {e}", file=sys.stderr)
    sys.exit(1)

Your Quality Management Data Template

Your Quality Management Data Template

Quality Management Attributes

Quality Management Activities

Extraction Guides

Oracle BI Publisher Report for Quality Event Data

Steps

Configuration

a Sample Query config

Direct SQL Query on Oracle Quality Management Tables

Steps

Configuration

a Sample Query sql

Python Extraction Script via Oracle DB Connector

Steps

Configuration

a Sample Query python

Ready to Get Started?

Transform Oracle Quality Management, Boost Compliance Now

Your Quality Management Data Template

Your Quality Management Data Template

Quality Management Attributes

Quality Management Activities

Extraction Guides

Oracle BI Publisher Report for Quality Event Data

Steps

Configuration

a Sample Query config

Direct SQL Query on Oracle Quality Management Tables

Steps

Configuration

a Sample Query sql

Python Extraction Script via Oracle DB Connector

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Transform Oracle Quality Management, Boost Compliance Now