The inbound inspection lifecycle
Inspection is lot-based: one inspection per received line. The lot carries a snapshot of the resolved plan — sample size, acceptance number, rejection number, the standard, the code letter — frozen at receipt so later plan edits never rewrite history.Pending, In Progress, Passed, Failed, and Partial (inspectionStatusType in apps/erp/app/modules/quality/quality.models.ts). Passed, Failed, and Partial are disposition outcomes. Recording all samples does not close a lot; the inspector must select Accept Lot or Reject Lot on the lot.
What triggers a lot
An item gets inspected when it has an inspection plan assigned for the Receipt usage. Assign it on the item’s Quality tab under Inspection Plan Assignments (“Which document drives each inspection flow for this item”). Inspections have a source document of Receipt or Job Operation; only receipt lots take the Accept and Reject dispositions described here, while job-operation lots are dispositioned from the shop floor. See quality.Recording samples
Each recorded result is a sample on the lot. For a Serial item, the inspector scans or selects a discrete per sample; for Batch / Inventory / Non-Inventory items there’s no discrete unit to scan, so the sample records just a Pass/Fail withtrackedEntityId left null (inspectionSampleValidator). Same modal either way — the serial path just adds a Scan/Select step.
Disposition
The Accept Lot and Reject Lot buttons gate on the recorded results (InspectionView.tsx):
- Accept Lot is available once the inspected count reaches the sample size and failures are at or below the acceptance number. When the plan has characteristics, every characteristic must reach its own sample size within its own acceptance number.
- Reject Lot is available the moment failures exceed the acceptance number (or a characteristic reaches its rejection number), so you don’t have to finish the sample to reject a clearly bad lot.
Sampling plans and AQL
Every lot needs a sample size and an accept/reject rule. That comes from a sampling rule on the inspection plan: a Default Sampling rule on the plan itself, which any characteristic can override with its own rule (Inherit document default or its own plan type), resolved against the lot size at receipt. There are four plan types (samplingPlanTypes in apps/erp/app/modules/quality/samplingStandards.ts):
The first three plans use a zero-defect rule. AQL uses standard acceptance tables. The rule modal shows a live Preview (lot, sample, Ac, Re, letter).
How an AQL plan resolves
— Acceptable Quality Limit — is the defect rate you’re willing to treat as “good enough”. The resolver (resolveSamplingPlan in samplingStandards.ts) takes the plan, the lot size, and the company’s standard, then walks the standard’s tables in two steps:
- Lot size → code letter. A single lot-size-range table maps the lot to a code letter (A–R) for the chosen inspection level. Level II is the general default; I and III trade sample size for confidence, and S1–S4 are special small-sample levels (
inspectionLevels). - Code letter + AQL + severity → sample plan. The code letter and AQL pick a cell giving the sample size
n, the acceptance number (Ac, max defects to still accept), and the rejection number (Re). Severity switches which table is used: Normal, Tightened (stricter — used when a supplier’s quality slips), or Reduced (inspectionSeverities).
0.065, 0.1, 0.15, 0.25, 0.4, 0.65, 1.0, 1.5, 2.5, 4.0, 6.5, 10.0 (standardAqlValues). The whole Z1.4 / ISO 2859-1 constant tables live in samplingStandards.ts — ISO 2859-1 cells match Z1.4 for the plans Alforse exposes, so both standards share the same tables today.
The standard itself (ANSI_Z1_4 or ISO_2859_1) is a company-wide setting, not per-plan, under Settings → Quality → Sampling Standard. The same page has Inspections: Require Different Inspector (enforceInspectionFourEyes), which makes the person who records a sample differ from the one who dispositions the lot.
Inspection templates and step types
Sampling decides how many to inspect. An inspection template decides what to check on each one. Templates are built from ordered steps, and every step has a type that determines what the inspector is asked to do (procedureStepType in apps/erp/app/modules/shared/shared.models.ts):
The step validator (qualityDocumentStepValidator in quality.models.ts) enforces the type-specific rules: a Measurement step must have a unit of measure, a List step must have at least one non-empty option, and when both minValue and maxValue are set the max must be greater than or equal to the min.
FAI, inspection documents, and balloons
For first-article inspection (FAI) and dimensional sign-off, Alforse works from the drawing itself. An inspection document is a part’s PDF drawing overlaid with numbered balloons, each balloon marking a characteristic to inspect (inspectionDocumentValidator / balloonFeatureValidator in quality.models.ts).
Each balloon feature carries:
Balloons anchor to a region of a specific PDF page (normalized 0–1 coordinates, so they stay put at any zoom) and each balloon can carry a step type from the same procedureStepType set, so a ballooned characteristic can be a Measurement, a Checkbox, and so on. Alforse can also auto-detect balloons from the drawing and turn detected regions into features. Balloon, geometry, and feature changes are saved together.
Inspection plans live under Quality → Inspection → Inspection Plans.