When a NetSuite quality inspection does not appear, check whether the expected transaction matched an active specification context before changing the inspection itself. Then distinguish a missing queue record from an existing record hidden by assignment, filters or status. These are different failures with different remedies.
This checklist applies to the Quality Management SuiteApp. An inventory quarantine status alone does not establish that the SuiteApp is installed or that an inspection trigger has been configured. Confirm the account's installed version, roles and customized workflows before treating public documentation as an exact description of the local process.
Capture one transaction that should have triggered inspection: record type, parent transaction where relevant, item, location, vendor or work center, date and quantity. Record the expected specification and why the business believes it applies.
Avoid a starting statement such as “quality is broken.” A better statement is “the receipt for this item at Location East should create the incoming dimensional inspection under Context 12.” That gives the administrator a reproducible comparison.
Retain the transaction identifier and creation path. A UI receipt, an imported record and an event from a connected production application may involve different execution conditions. The actual path needs to be included in testing.
Quality Management triggers a specification when both the specification and a matching context are active. Check each record independently. A valid inspection definition with no active matching context can remain unused indefinitely.
Inspect the context's item and location along with the transaction type. Supported contexts distinguish item receipts, assembly or work-order builds, work-order completions and other documented event types. A context intended for non-work-center builds should not be assumed to cover a routed completion automatically.
If several contexts could match, record the intended coverage of each before changing them. Broadening one context to fix a single missing inspection could create duplicate or inappropriate inspections elsewhere.
| Matching dimension | Question to answer |
|---|---|
| Transaction type | Was the expected record actually a build, completion, receipt or another supported event? |
| Parent transaction | Does the receipt or fulfillment originate from an allowed parent type? |
| Location | Does the physical and transaction location match the context? |
| Vendor | Is the intended supplier included, or is a default rule being used? |
| Work center | Is production reported at the configured center or final-operation default? |
| Active state | Are both the specification and context active? |
| Frequency | Is this event intentionally skipped under the configured sequence? |
Use a side-by-side comparison of expected and observed values. Do not rely on similarly named locations or supplier display names when stable record identifiers are available.
The context's Apply to Default option has specific meanings. For receipt-from-purchase-order contexts, it can trigger the item specification regardless of vendor, ignoring a selected vendor. For work-order completion contexts, it can target the last routing operation, ignoring a selected work center.
That means it is not a general “make this work everywhere” switch. If an inspection belongs at an intermediate operation, turning on a final-operation default may delay the check beyond the point where it is useful.
Before changing the option, have quality approve the intended inspection boundary. Then test a transaction that should match and one that should not. Negative cases are essential when a configuration broadens coverage.
Transaction frequency controls which events create a queue entry in the documented receipt examples. It is different from how many units an inspector measures within an inspection.
For the documented context frequency table, blank or zero creates a queue for every item receipt. A value of one creates entries for every other receipt, and two for every third receipt. Do not interpret one as “inspect every receipt” without checking this behavior.
Have the quality owner approve the sampling policy and verify its implementation. Product safety, regulated quality obligations and statistical sampling design require qualified review. An ERP setting should not be treated as evidence that an inspection plan is sufficient for a particular regulation or product risk.
In an isolated hypothetical receipt sequence matching the documented example, a supplier delivers the same controlled component three times to Location North. The quality team expects three incoming inspections. The context is active and uses Transaction Frequency 1. Queue entries exist for the first and third receipts, but not the second.
Under the documented receipt-frequency behavior, this pattern is consistent with every-other-receipt generation. It is not, by itself, evidence of a failed script. Quality must decide whether the configuration or the stated expectation is wrong.
Now suppose a fourth delivery goes to Location South, where no matching context exists. Correcting frequency on the North context would not establish South coverage. The two missing inspections have different causes and need separate approved changes. The example illustrates a diagnostic sequence; no customer account has been tested.
If the trigger appears correct, look for a queue record using the transaction and item identity. Check assignment, location filters, date filters and record status. An inspector's tablet view may show only a subset of the full population.
A queue record represents a triggered specification. Inspection data collection is associated with Pending or In-Process states in the documented flow; Hold, Cancel, Pass and Fail have different implications. An existing queue that cannot accept data is not the same as a queue that was never created.
Do not create an ad hoc inspection until you understand whether one already exists. Duplicate inspections can split evidence across records or lead teams to act on inconsistent results.
Once the queue exists, inspect the difference between its Status and Action fields. Conformance rules evaluate submitted data, while actions and state combinations can drive quarantine, release or vendor-return workflows.
If a failed inspection exists but the stock remains usable, the next investigation concerns disposition workflow and inventory controls. Changing the trigger is unlikely to fix that downstream problem. Preserve the failure evidence and inspect the applicable workflow configuration and history with an authorized administrator.
For a passed inspection, verify the intended release actually occurred where the process requires it. A pass label is not sufficient proof that every associated lot, bin or inventory-status quantity moved correctly.
Test the matching event, wrong location, excluded vendor, alternate parent transaction and intended frequency sequence. For routed production, include an intermediate and final operation where relevant. Use the roles employees actually use.
Record expected queue count, observed queue count, specification identity, assignment and downstream action. Also verify that existing completed inspections were not unintentionally altered.
If the root cause involves a connected quality application, document which system triggers inspection and which stores the authoritative result. CuriousRubik's NetSuite integration services can help scope that event handoff. For native configuration issues, bring the same trigger-and-queue evidence to the account's support owner.
The matching context must also be active and match the actual transaction details. Check type, parent transaction, item, location, vendor or work center and frequency before assuming that the inspection definition itself is defective.
Not in the documented context receipt example. A value of one creates an inspection for every other receipt; blank or zero creates one for every receipt. Verify the sequence and have quality approve the intended policy.
No. Frequency determines which events create inspection work, while sample size concerns the units assessed within that work. Review both separately with the quality owner and validate the configured behavior.
Yes. Assignment, filters, role access or status may prevent it from appearing in the inspector's current view. Search using the original transaction and item before creating another inspection.
No. Verify the configured status-and-action workflow and the actual inventory result. Inspection conformance, workflow execution and usable stock are related but separate pieces of evidence.