The Create Test Behavior and Find Existing Behavior settings on the Quality Inspector Setup page work together to control what happens when the system attempts to create a quality inspection test. These two global settings determine whether a new test is created, whether an existing test is reused, or whether a retest is created, and how the system identifies what counts as an existing test in the first place.

Understanding how these settings interact is important because the right combination depends on your business process. This article explains each setting, describes how they work together, and provides example configurations for common scenarios.

For a reference of all settings on the Quality Inspector Setup page, see the Quality Inspector Setup page.

Settings

Create Test Behavior

This setting determines what the system does when a test creation is triggered and there may already be existing tests for the same source.

Find Existing Behavior

This setting determines how the system searches for existing tests when it needs to decide whether a match exists. It controls which fields are compared to determine if a test is considered matching.

How the two settings work together

When a test creation event occurs (such as posting a purchase receipt, posting production output, or moving product into a bin), the system follows this decision process:

1. If Create Test Behavior is “Always Create a New Test”, a new test is created immediately. The Find Existing Behavior setting is not used.
2. For all other Create Test Behavior options, the system first searches for existing tests using the criteria defined by the Find Existing Behavior setting. Once it determines whether a matching test exists and what status it is in, it applies the Create Test Behavior logic to decide whether to create a new test, create a retest, or reuse the existing test.

This means Find Existing Behavior controls the scope of the search and Create Test Behavior controls the decision made based on the search results.

A narrow Find Existing Behavior (like Standard Source Fields) means fewer tests are considered “matching”, so new tests are created more often. A broad Find Existing Behavior (like Item Tracking) means more tests are considered “matching”, which can reduce duplicate tests when the same item or lot appears across different documents.

Example configurations

Scenario 1: Standard receiving inspection

Situation: You purchase items from vendors and want every receipt to generate an independent test. Each purchase receipt line is a distinct event that must be inspected on its own.

Recommended Settings:

• Create Test Behavior: Always Create a New Test
• Find Existing Behavior: Standard Source Fields

Why: Since a new test is always created, the Find Existing Behavior is not consulted. This is the simplest configuration and is appropriate when every transaction warrants an inspection, such as incoming material inspection on a per-receipt basis.

Scenario 2: One test per lot, regardless of source document

Situation: You receive the same lot across multiple purchase orders, or the lot might also arrive through transfers. You want a single test per lot, regardless of which document brought it into inventory.

Recommended Settings:

• Create Test Behavior: Use Existing Open Test if Available
• Find Existing Behavior: Item Tracking

Why: Item Tracking causes the system to search by item number, variant, serial, and lot — ignoring the document number. If an open test already exists for that lot, the system uses it instead of creating a duplicate. If the existing test is already finished, a new test is created for the new transaction. This prevents duplicate open tests when the same lot arrives in parts, while still allowing new tests for genuinely new transactions after the previous test is completed. See the Quantity will not be updated when an existing test is reused section for some important caveats.

Scenario 3: Production retesting after failure

Situation: You inspect production output. If a test fails, the lot undergoes corrective action and needs to be retested. You want the retest to be clearly linked to the original test for traceability.

Recommended Settings:

• Create Test Behavior: Create a Retest if a matching test is finished
• Find Existing Behavior: Standard Source Fields

Why: When production output is posted for the first time and no existing test is found, a new test is created. If that test is later finished (pass or fail), and the same production order line outputs again, the system finds the finished test and creates a retest linked to it. If the test is still open (in progress), no new test is created, which prevents duplicates while inspectors are still working on the first test.

Scenario 4: Make-to-order with multiple lots per order line

Situation: You produce items for specific sales orders. Each production order line may produce multiple lots or serial numbers, but you want one test per order line, not per lot.

Recommended Settings:

• Create Test Behavior: Use Existing Open Test if Available
• Find Existing Behavior: Document and Item Only

Why: Document and Item Only ignores lot and serial number details when searching for existing tests. If the first lot produced on a specific order line already has an open test, subsequent lots on the same line will reuse that test. This is useful when the order line (not the individual lot) is the unit of inspection, such as when a single inspection covers all output from a production run against one order.

Scenario 5: Comprehensive retest history

Situation: You require a complete retest chain for regulatory compliance. Every time a test is triggered for the same source, it should be recorded as a retest of the original, building a clear lineage of inspections.

Recommended Settings:

• Create Test Behavior: Always Create a Retest
• Find Existing Behavior: Standard Source Fields

Why: Every test creation event produces a retest linked to the previous test in the chain, regardless of whether the prior test is open or finished. This creates a traceable history showing the full sequence of inspections for that source. Standard Source Fields ensures the match is specific to the exact source document and line. Use this when regulatory or quality system requirements demand an auditable chain of all inspections.

Scenario 6: Items from multiple sources, one test per lot

Situation: An item can arrive via purchase, transfer, or production. You want one test per lot regardless of how the item entered inventory, and if a prior, finished test exists, you want to create a retest to maintain the connection between inspections.

Recommended Settings:

• Create Test Behavior: Create a Retest if a matching test is finished
• Find Existing Behavior: Item Tracking

Why: Item Tracking searches by item and lot details, ignoring the source document type and number. If a lot was previously purchased and tested and later the same lot arrives on a transfer, the system finds the finished test from the purchase and creates a retest. If the original test is still open, no new test is created. This ensures continuity of the testing record for a lot across its lifecycle through different business processes.

Scenario 7: Custom entity testing (equipment, tools, or other non-item records)

Situation: You use Quality Inspector to test custom records such as equipment, machines, or tools. These records do not have item numbers, document numbers, or tracking details.

Recommended Settings:

• Create Test Behavior: Use Existing Open Test if Available
• Find Existing Behavior: Source Record

Why: Source Record matches tests based on the specific record ID and table, which is the only meaningful identifier for custom entities. If an open test already exists for that specific equipment record, the system uses it. This prevents duplicate tests when multiple events reference the same custom record.

Scenario 8: Avoid all duplicates

Situation: You want to ensure that only one test ever exists for a given source, regardless of timing or status. If a test has already been created (open or finished) the system must reuse it.

Recommended Settings:

• Create Test Behavior: Use Any Existing Test if Available
• Find Existing Behavior: Standard Source Fields

Why: The system searches for any matching test (open or finished) and uses it if found. A new test is only created when no match exists at all. This is appropriate for scenarios where a test record is a permanent reference document for its source and must never be duplicated, such as a certification record for a specific batch.

Quick Reference: Choose the right combination

How source configurations affect test data

When a test is created, the system uses Source Configurations to populate fields on the test from the triggering record. Source configurations define which fields from a source table (such as a Purchase Line, Prod. Order Line, or Warehouse Entry) map to which fields on the Quality Inspection Test. For example, the default source configurations map quantity fields from the triggering record (such as “Qty. to Receive (Base)” on a Purchase Line, or “Quantity (Base)” on an Item Ledger Entry) into the test’s Source Quantity (Base) field. They also map the following fields:

• Item No.
• Variant
• Lot No.
• Serial No.
• Location
• Document No.
• Description

These source configurations are set up automatically when Quality Inspector is first installed and can be viewed and modified on the Source Configuration List page. Understanding source configurations is relevant to these behavior settings because the data populated onto a test at creation time comes from the specific transaction that triggered it. See the Create Quality Inspection Template and Connect to a Customized Table in Quality Inspector page for a walkthrough of creating a custom source configuration.

Quantity will not be updated when an existing test is reused

When the Create Test Behavior causes the system to reuse an existing test (e.g., with “Use Existing Open Test if Available” or “Use Any Existing Test if Available”), the source fields on the existing test, including Source Quantity (Base), are not updated with values from the new transaction. The test retains the quantity and other source details from the original transaction that created it.

This has practical implications:

• Multiple receipts for the same lot: If you receive 100 units of Lot A on a purchase order and a test is created with a source quantity of 100, and then a second receipt of 50 units of Lot A arrives on a different purchase order, the system could find and reuse the existing test (depending on your settings). The test still shows a source quantity of 100, not 150. The second receipt’s quantity is not added to or reflected on the test.
• Partial production output: If a production order line is set to produce 100 units and you post output of 50 units, a test is created with a source quantity of 50. If you post the remaining 50 units and reuse the existing test, the source quantity on the test only reflects the initial output (50), not the total output (100).
• Sample size may not reflect total quantity: If you use AQL or percentage-based sampling, the sample size is calculated from the source quantity at the time the test is created. When the test is reused for a subsequent transaction, the sample size remains based on the original quantity and is not recalculated for the combined total.
• Audit and traceability: If your quality process requires that the test quantity accurately reflects the total quantity under inspection, reusing an existing test across multiple transactions produces incomplete records. The test documents the quantity from the first triggering transaction, not the cumulative total.

When this matters most: This caveat is most relevant when using Item Tracking as the Find Existing Behavior combined with a Create Test Behavior that reuses tests (“Use Existing Open Test if Available” or “Use Any Existing Test if Available”). In these configurations, the same lot arriving across multiple documents will match the same test, but the quantity only reflects the first arrival.

When this does not apply: If you use “Always Create a New Test,” every transaction gets its test with its quantity. If you use “Create a Retest if a matching test is finished,” a new test (retest) is created with fresh source data whenever the previous test is already finished. However, while a test is still open, additional transactions for the same source (such as partial production outputs) do not create new tests and do not update the quantity on the open test.

Recommendation: If accurate source quantity is important to your process and the same lot or item can arrive across multiple transactions, consider using “Always Create a New Test” or “Create a Retest if a matching test is finished” to ensure each test reflects the quantity from its specific transaction. Alternatively, if you prefer to consolidate tests per lot, be aware that the quantity on the test reflects the first transaction and plan your sampling and inspection procedures accordingly.