Introduction

QTrendControl software provides flexible dynamic creation of manual data input form, according to selected organizational elements to be included in an inspection.

By selecting organizational elements to be included, we instruct QTrendControl which inspection points and parameters to include in manual data input form creation, from previously defined inspection matrix.

There are two approaches for generation of data input form: ad-hoc approach or using previously defined templates which can speed up form generation.

Create Data Input Form

Open the form for generation of data input form, by clicking the button "Input of Inspection Results" from the main switchboard.

This will main form for defining criteria for dynamic generation of actual data input form.

Ad-hoc Selection Criteria for Organizational Elements

First, notice that the main form is applicable for currently selected organization.

Also notice that on the bottom part of the form there is navigation toolbar which you can use to navigate organizations, if there are more than one organization defined in the master data (in our demo instance there is only one organization).

Next, notice set of drop-down combo-boxes, for choosing organizational elements for the current organization.

Note that organizational nodes are structured in hierarchical order (Department-->Plant-->Area-->Line--->Device), meaning that if we select an element in a hierarchically superior level, all subordinated levels will be constrained i.e. filtered to contain only filtered corresponding subordinated organizational elements. This provides flexible way to narrow down inspection matrix to desired range of inspection points and inspection parameters (i.e. quality characteristics) previously defined in inspection matrix.

Inspection Type is not constrained to organizational elements, but is separate list.

 

Bare in mind that if you don't specify an explicit value in a combo-box, then by default it is considered as if you selected all elements from that drop-down list.

For example, if we select only department, it means that we selected all inspection points belonging to this department, in all corresponding plants, areas, lines, devices and of all inspection types:

Using Templates for Data Input Form

On the left part of the form, there is list of previously defined templates for data input. By clicking "+" sign button on the beginning of a row, you can see what organizational elements are assigned to the template.

We can apply or un-apply currently selected template by using corresponding buttons "Apply Input Data Template" and "Undo Input Data Template".

For example, let's apply template which includes only department and inspection type as organizational nodes.

If you click "Apply Input Data Template", you will notice that now only comboboxes for department and inspection type are available for choosing filtering constraints, while other comboboxes are hidden and not available.

if we click the button "Undo Input Data Template", then all comboboxes will become available again.

These templates for data input can be defined in the tab "Templates for inspection results input":

Dynamically Generate Inspection Data Input Form

Let's define our filtering constrains. For example, let's suppose that we want to create an inspection for a department "Softened hot sanitary water system". Let's first recall what has been defined in inspection matrix for that department.

Obviously, we have several different inspection points with corresponding inspection parameters (i.e. quality characteristics) defined for this department, of various data types, so this will suite as a good example for this tutorial.

Ok, let's close inspection matrix and come back to our main data input form.

Choose the department from drop-down list in the combo-box.

Now, click on the button "Generate Data Input Form".

This will trigger creation of new inspection data input form, which will be opened in the "Enter Inspection Results (Data Input Form)" tab.

Inspection Header

First we need to enter data for inspection header.

Basic Inspection Information

Enter descriptive information about the whole inspection. ID of inspection is automatically generated, other fields are customly defined by user. As a good practice, give some properly defined name for the inspection in the field "Inspection Identification". Though unique name is not enforced, it is a good practice to name it uniquely, for easier search and exploration afterwards.

Date(Time) information

QTrendControl will automatically assign current datetime timestamp to fields "Inspection Datetime", "Analysis Datetime" and "Reporting Datetime":

However, you are free to define these values by manually entering date(time) values in appropriate format, or by using calendar control. For example:

Note that datetime format is defined by current operating system and underlying PostgreSQL database settings, which is configurable on the server side. In this demo instance, settings are configured for Central European, Croatian format of date and time.

Additional Inspection Information

The software provides possibility to assign additional, non-mandatory information, for product, batch, lot and sample.

Product can be chosen from predefined product catalogue, by using drop-down menu. On our demo instance, we have only one product enetered, though.

If we enter some information of a batch and/or a lot, then we will be able to use this information for searching and filtering inspection results.

Similarly, there is possibility to enter some designation for samples. In the inspection header we can enter some designation of a collective sample, applicable for the whole inspection.

Notice, however, that we can also define samples in the details form as well.

Inspection Details

After we entered inspection header data, we can proceed with inspection details for each inspection point and corresponding inspection parameters (i.e. quality characteristics).

Notice that each inspection point can have one or more inspection parameters.

Inspection details section consists of three-level system of datasheets in master/detail relationship. The uppermost datasheet contains information about inspection point. The sub-datasheet contains information about inspection parameters. The sub-datasheet can also be expanded to details sub-datasheet where you can see some additional details and also use it for data input instead of the main sub-datasheet.

As you can see, most of the columns are already populated with data defined in master data, i.e. inspection matrix.

Notice column "RESULT" in the inspection parameters sub-datasheet. This is the primary field in which you will enter inspection data. This column is data type agnostic, meaning that you will have to consider proper data formatting for specific data type. System will, however, notify you with error message if you enter invalid value for a certain data type. You can also enter your comments in the column "Comment".

 

OK, let's now enter inspection results!

Notice that QTrendControl will provide immediate signalling of any requirement or limits violation, during the data input. The system will immediately color to yellow color any result violating requirement or limits. Also, if you scroll datasheet to right, you can see several columns indicating status of the entered result value.

Check-box "O.K.?" says whether result is O.K. or not, i.e. whether result value violates any requirement or limit defined in the inspection matrix.

Check-boxes "Requirement Violated?" and "Limits Violated" indicate whether result value violated an explicit requirement or predefined limits.

If there were limits violations, then column "Limit Violations Count" says how many individually defined limits are violated. For example, you might have several different limits defined for the inspection parameter, let's say that you have specification limit, action limit and warning limit. A result might, for example, violate warning and action limit, but not vioalate specification limit. in that case, limit violations count would be 2.

Notice also that the system provides you instantaneous information about requirements and limits in several ways.

Column "Limits" provides concatenated representation of all limits being predefined for the inspection parameter.

There is also presentation of limits in each major cathegory (USL - Upper Specification Limit, LS- Lower Specification Limit, UAL - Upper Action Limit, LAL - Lower Action Limit, UWL - Upper Warning Limit, LWL - Lower Warning Limit, UCL - Upper Control Limit, LCL - Lower Control Limit).

Explicit requirements are presented in the column "Requirement". By explicit requirement we consider, for instance, target value (in case of variable data), but also categorically expressed requirements, for example boolean requirement (yes/no i.e. True/False). Bare in mind that if value in this column is "False" and the inspection parameter is not defined as boolean data type, then "False" means that there are not explicit requirements defined! (see explanation below).

Sub-Sub-form with additional Details

You can enter your results data directly in the inspection parameter sub-datasheet, as already explained. However, you can also do it in the sub-sub-form, which you can reveal if you click on the "+" button in front of the row.

Special Considerations related to Entering and Showing Boolean Values

When dealing with boolean data type values and requirements, we must be extra caution how to input data and also, how to interpret data.

When talking about interpreting boolean data in the "Requirement" column, we must be aware that "False" value can actually mean two completely different things. If data type of an inspection parameter has been defined as boolean data type, then this "False" value indeed means that the requirement is that result must be "False", and if it is "True" then it means violation. However, if data type of an inspection parameter is not defined as boolean, then this "False" value actually means that there is no explicit requirement defined! This is unfortunate limitation of Access front-end which does not distinguish triple-state of a boolean field (triple states: true, false, null). Although in underlying PostgreSQL database we might define null (or 'nothing' or 'none'), Access front-end is unfortunately not able to deal with null state in a boolean field. Therefore this unfortunate ambiguity.

if we talk about entering boolean results, then keep in mind that proper way of entering boolean value in the "RESULT" column is by typing corresponding English textual values "True" or "False". Otherwise, you will get an error.

Special Considerations applicable to Attribute (discrete) Data Input

In case of attribute data types (i.e. discrete data), such it is case when counting defects or defectives, beside entering result value, you will also need to enter at least sample data count as well. That's because for counting defectives or counting defects, we also must define sample size for which result is expressed. This sample size is defined in the column "Sample Count".

Don't mistake column "Sample Count" (which is used for attribute data) with similarly named column "Sample Quantity", which is general purpose column for defining sample quantity in case of variable data!

Customization of input datasheet

You might want to hide certain columns and unhide some other columns. You can customize datasheet columns to be visible, by using corresponding options of the ribbon.

   

Preparation of multiple data input forms

You are not forced to enter inspection data immediately after you generated a inspection form. You can create multiple inspection data input forms and then fill them afterwards.

All these generated data input form will be listed in the tab "Enter Inspection Results (Data Input Form)" and you can navigate between them by using navigation toolbar of the form.

  

Confirmation of Inspection Data Input

Once you have entered all the data for inspection, you can confirm inspection by clicking on the button "Confirm inspection input". This will trigger procedure that transactionally transfers data from temporary tables into persistent database. 

Keep in mind that while you are entering data into data input form, it is not yet recorded in the audit trail. Only after you click "Confirm inspection input", data becomes subject of audit trail recording. Any subsequent editing or deletion of data is recorded in the audit trail as well.