Setting Up Inspections (QMS)

QualityOne Vaults allow users to process incoming, in-process, outgoing, and COA (Certificate of Analysis) inspections and analyze samples against pre-defined specifications.

About the Inspections Process

Incoming, in-process, outgoing, and COA inspections provide users the ability to create sample records and analyze samples against inspection plans. Sample records run against defined sample and success criteria using a fixed number or percentage of the total evaluation method. You can configure your Vault so that users can generate and analyze inspection samples. To generate and analyze inspection samples, you must enable the proper actions in the required lifecycles, configure the appropriate page layouts to include the necessary objects, and define the Inspection Plan records.

COA Inspections Process

COA inspections provide users the ability to analyze single or multi-batch COA files. COA uses an automated process to determine if the measurement values on the COA meet specification limits. External users can contribute to the COA Inspection record by directly emailing the COA file to Vault for upload to the record when prompted by a workflow task email or by sending COA files to a specified Vault inbound email address.

You can configure your Vault so that users can analyze COA files. To do so, each Vault must provide AWS Account credentials in order to leverage the Amazon Textract technology that performs an optical character recognition (OCR) scan of uploaded COA files. When a user uploads a COA file in an AWS supported language, Vault sends the file to AWS to extract the data, and then stores the returned data results as object records. This returned data is compared against an inspection plan which contains specification limits as inspection plan requirements; the returned data is also matched against the user’s Vault language to display any localized data values accordingly. Vault then provides the user with a rating on whether the COA passes or fails to meet specifications when the user runs the Analyze COA action. When running Analyze COA, the OCR data result (extracted from AWS Textract) is stored in the COA record for 30 days. You can optionally download OCR data results from an analyzed COA record to leverage the data for accuracy improvements when ingesting and analyzing various COA formats.

Inspections Objects

QualityOne uses the following objects and object types to support Inspections.

Core Data Objects

The core data objects of Inspections include the following:

  • Inspection (inspection__v): This object stores data about inspections.
    • Incoming Inspection (incoming__v): This Inspection object type stores information about incoming inspections.
    • In-Process Inspection (in_process__v): This Inspection object type stores information about in-process inspections.
    • Outgoing Inspection (outgoing__v): This Inspection object type stores information about outgoing inspections.
    • COA Inspection (coa_inspection__v): This Inspection object type stores information about COA inspections.
  • Material (material__v): This object stores product information related to product, formulation, and packaging.
  • Product (product__v): This object stores item master data.
  • Purchase Order (purchase_order__v): This object stores information to help track on-time delivery.
  • Purchase Order Line Item (purchase_order_line_item__v): This object stores information about purchase order line items.
  • Production Order (production_order__v): This object stores information about manufactured products.
  • Inspection Plan (inspection_plan__v): This object stores inspection plan data.
  • Inspection Plan Requirement (inspection_plan_requirement__v): This object stores the specifications to be used for a particular inspection plan.
    • Attribute Specification (attribute_specification__v): This Inspection Plan Requirement object type stores information about attribute specifications.
    • Variable Specification (variable_specification__v): This Inspection Plan Requirement object type stores information about variable specifications.
  • Master Specification Group (master_specification_group__v): This object centralizes all master specifications to be linked to multiple products.
  • Master Specification (master_specification__v): This object stores the base requirements for an item.
    • Attribute Specification (attribute_specification__v): This Master Specification object type stores attribute data used to describe an item specification.
    • Variable Specification (variable_specification__v): This Master Specification object type stores variable data used to describe an item specification.
  • Characteristic (characteristic__v): This object stores information about characteristics.
  • Organization (qdm_organization__qdm): This object stores information about an external organization such as an external supplier.
  • Facility (facility__v): This object stores information about an internal facility.
  • Inspection Sample (inspection_sample__v): This object stores sample data from an inspection.
  • Inspection Sample Test Results (inspection_sample_test_result__v): This object stores inspection results for each sample.
    • Test Result Attribute Data (test_result_attribute_data__v): This Inspection Sample Test Result object type stores information about test result attribute data.
    • Test Result Variable Data (test_result_variable_data__v): This Inspection Sample Test Result object type stores information about test result variable data.
  • Record Matching Rule (record_matching_rule__v): This object stores sharing rules for secured objects for individual users with a particular application role.
  • Localized Characteristic (localized_characteristic__v): This object stores information about characteristics that are translated to the user’s Vault locale.
  • Localized Unit (localized_unit__v): This object stores information about units that are translated to the user’s Vault locale.

COA Inspection Objects

The core COA inspection objects include the following in addition to the core data objects:

  • COA Header OCR Data (coa_header_ocr_data__v): This object stores data obtained from the OCR scan of the uploaded COA file.
  • COA Test Results OCR Data (coa_test_results_ocr_data__v): This object stores test results obtained from the OCR scan of the uploaded COA file.
  • COA Table Column OCR Data (coa_table_column_ocr_data__v): This object stores table column data obtained from the OCR scan of the uploaded COA file.
  • COA Matching Rule (coa_matching_rule__v): This object stores a matching rule used to interpret COA data before creating records.
  • COA Matching Rule Variant (coa_matching_rule_variant__v): This object stores a matching rule variant used to interpret COA data before creating records.
  • Component Matching Variant (component_matching_variant__v): This object stores information about matching variants.
    • Unit Matching Variant (unit_matching_variant__v): This Component Matching Variant object type stores information about unit matching variants.
    • Characteristic Matching Variant (characteristic_matching_variant__v): This Component Matching Variant object type stores information about characteristic matching variants.
  • Attribute Test Result Variant (attribute_test_result_variant__v): This object stores attribute test result variations used when analyzing COA files.
    • Attribute Variant (attribute_variant__v): This Attribute Test Result Variant object type stores information about attribute test result variations.
    • Verdict Variant (verdict_variant__v): This Attribute Test Result Variant object type stores information about verdict test result variations.
  • Below Detectable Limit Variant (below_detectable_limit_variant__v): This object stores information about variant texts of limits below the detectable limit. When an existing Below Detectable Limit Variant record matches against data in an analyzed COA file, the Test Result (Variable Data) field returns empty and the Test Result Variable Data Symbol field is set to “Not Detected”.

Alternate Supporting Objects

Contact your Veeva Representative to inquire about the following objects:

  • Item Group (Brand) (item_group__v): This object stores information about item groups, product families, or brand names to which product variants or line extensions can be related.
  • Item Version (item_version__v): This object stores item version data.
    • Manufactured Item (manufactured_item__v): This Item Version object type stores information about manufactured items.
    • Purchased Item (purchased_item__v): This Item Version object type stores information about purchased items.
  • Item Specification (item_specification__v): This object stores data about an individual requirement for an item.
  • Item Specification Acceptable Attribute (item_specification_acceptable_attribute__v): This object stores attributes that can be used to describe an item specification.
  • Purchased-Item Organization (purchased_item_organization__v): This object stores information about the purchased-item organization.
  • Acceptable Attribute (acceptable_attributes__v): This object stores acceptable values for an attribute for an inspection plan requirement.
  • Specification Acceptable Attribute (specification_acceptable_attribute__v): This object stores a base acceptable criteria for attribute specifications.
  • Localized Acceptable Attribute (localized_acceptable_attribute__v): This object stores information about acceptable values for an attribute that are translated to the user’s Vault locale.

Configuration Overview

Configuring your Vault to use Inspections involves the following steps:

  1. Setup prerequisite records for Inspections
  2. Configure the Incoming, In-Process and Outgoing Inspection object types
  3. Configure the COA Inspection object type
  4. Configure the Inspection lifecycles
  5. Configure the Inspection object actions

Setting Up Prerequisite Records

Currently, QualityOne Inspections provides functionality to create and evaluate samples on incoming, in-process, and outgoing inspections and, for Early Adopters, to automate the inspection of COAs. Set up the following prerequisite records to support the Inspections feature:

  1. Define all referenced items
  2. Define application security
  3. Create the Inspection Plan and Inspection Plan Requirement records

Defining Referenced Items

You need to populate certain picklists so you can reference picklist values when creating Inspection Plans and Inspections. You also need to create certain records before users can create Incoming, In-Process, Outgoing, and COA Inspection records.

You need to review and maintain values for the Inspection Type picklist so that you can reference these items when creating Inspection Plans.

You need to review and maintain values for the Specification Source picklist so that you can reference these items when creating Inspection Plan Requirements.

In order for users to be able to create Inspection records, you need to create the appropriate records for the following objects:

  • For all Inspection types:
    • Material
    • Product (Item)
    • Master Specification Group
    • Master Specification (Item Specification)
    • Inspection Plan
  • For COA Inspection type:
  • Purchase Order (for Incoming and COA Inspection object types only)
  • Purchase Order Line Item (for Incoming and COA Inspection object types only)
  • Production Order (for In-Process and Outgoing Inspection object types only)

For Localized Characteristics and Localized Unit, creating appropriate records for these objects supports and maintains values for any localized data records.

Defining Application Security for Inspections

The Inspections feature uses Raw objects to provide performance consistency for your Vault. However, this data store option does not allow organizations to configure record-level security using DAC. To ensure that these objects are secured, see Defining Object Application Security for more details.

Creating Inspection Plans & Inspection Plan Requirements

In an incoming, in-process, or outgoing inspection, Inspection Plans (containing Inspection Requirements) provide the specifications that are defined within samples which Vault compares the values in an Inspection record in order to analyze whether an Inspection passes or fails.

In a COA inspection, Inspection Plans provide the specifications which Vault compares the values in an uploaded COA file in order to analyze whether a COA Inspection passes or fails. You can create and maintain Inspection Plans for each Material for products.

You can define the specifications of an Inspection Plan in one of the following ways:

  • Define referenced records to use for a new Inspection Plan record.
  • Deep copy an existing Inspection Plan and its associated referenced records using the Copy Record action: Inspection Plan Requirement and Acceptable Attribute records.
    • To acquire and maintain a copy of the same Inspection Plan and its specifications, navigate to the appropriate Inspection Plan record and select the Copy Record action from the All Actions menu. In the pop-up dialog, select the Copy Related Records checkbox to copy the hierarchy of records identified. Click Save to complete the action. You can start modifying the new records to your requirements.

To create a new Inspection Plan:

  1. Navigate to Business Admin > Objects > Inspection Plans.
  2. Click Create.
  3. Enter a name for the Inspection Plan.
  4. Select a Material.
  5. Select a Specific Product (Product Version).
  6. Optional: Enter a Description.
  7. Optional: Select a Facility.
  8. Optional: Select a Location.
  9. Optional: Select the Inspection Type.
  10. Click Save. To create another Inspection Plan, click Save + Create.

If you have already created Master Specification and associated with a Master Specification Group for a Specific Product, Vault will automatically generate an Inspection Plan Requirement upon saving the Master Specification.

To create an Inspection Plan Requirement by creating a Master Specification:

  1. Navigate to the appropriate Inspection Plan.
  2. In the Inspection Plan Requirements section, click Create.
  3. Select whether the inspection plan requirement type is a Variable Specification or Attribute Specification. Variable specifications allow you to specify lower and upper limits while attribute specifications are based on a single attribute value.
  4. Click Continue.
  5. Select a Characteristic.
  6. Optional: Select CTQ? if this requirement is a Critical to Quality parameter.
  7. Optional (Variable type only): Enter the lower specification limit (LSL).
  8. Optional (Variable type only): Enter the upper specification limit (USL).
  9. Optional (Variable type only): Select the measurement Unit or create a new unit.
  10. Optional: Enter the Target Value.
  11. Select the Specification Source.
  12. Click Save. To create another inspection plan requirement, click Save + Create.

Configuring Incoming, In-Process & Outgoing Inspections

To configure your Vault to create and evaluate incoming, in-process, and outgoing inspections, see Configuring Incoming, In-Process & Outgoing Inspections for more details.

Configuring COA Inspections

To configure your Vault to create and analyze COA inspections, see Configuring COA Inspections for more details.

Inspections Lifecycles

QualityOne Inspections contains various object lifecycles which your organization can use and customize to suit your specific needs:

  • Inspection
  • Inspection Plan Lifecycle
  • Inspection Sample Lifecycle
  • Inspection Sample Test Result
  • Master Specification Lifecycle

QualityOne Inspections contains the following document lifecycle which your organization can use and customize to suit your specific needs:

  • COA Document lifecycle

Configuring Object Actions

The Inspection object lifecycle contains the following actions shared between all Inspection types:

  • Analyze Inspection
  • Delete Inspection
  • Sync Related Records

See Configuring Incoming, In-Process & Outgoing Inspections and Configuring COA Inspections for more details.

About Inspection Field Sync Tracking

Inspections tracks and stores data records when users modify and save changes to specific related fields in existing Inspection records, triggering the asynchronous Sync values from related records job. This job copies those modified field values in the Inspection record to the related fields in the Inspection Sample Test Result records. When the job runs, Vault creates an App field sync tracker record for each Inspection record that details whether the job was successful in syncing the field values or not. Should synchronization fail, you can use this data record for investigation.

Upon completion, users receive a Vault notification if the job failed due to errors. When this happens, users should run the Sync Related Record action on the same Incoming, In-Process, Outgoing, or COA Inspection record to manually update the related Inspection Sample Test Result records.

Users trigger the Sync values from related records job when they modify and save the following fields on Inspection records:

  • Material (material__v)
  • Supplier Name (supplier_name__v)
  • Supplier Manufacturing Site Name (supplier_manufacturing_site_name__v)
  • Facility (facility__v)