> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alforse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Inspections and sampling

> How Alforse inspects received goods against AQL sampling plans, and how inspection templates and ballooned FAI drawings define what gets checked.

Alforse's inbound inspection evaluates received goods against a sampling plan. When a receipt posts for an item that has an inspection plan assigned for receipts, Alforse holds the received units, calculates the sample size, and requires inspection results before releasing stock. Lots are listed under **Quality → Inspection → Inspections**.

This page describes the inspection lifecycle, sampling calculations, template step types, and ballooned-drawing FAI workflow. See [quality](/docs/reference/quality.md) for the module overview.

## 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.

<details>
  <summary>**Pending**</summary>

  The lot exists but no samples are recorded yet. Its tracked entities were posted **On Hold** at receipt, not Available.
</details>

<details>
  <summary>**In Progress**</summary>

  At least one sample has been inspected. The inspector is working through the sample size, recording each unit as Passed or Failed.
</details>

<details open>
  <summary>**Passed**</summary>

  The lot was **accepted** on disposition. Un-sampled entities are released to Available; sampled passes stay Available, sampled failures stay Rejected.
</details>

<details>
  <summary>**Failed**</summary>

  The lot was **rejected**. Every entity in the lot flips to Rejected, and an issue can be opened automatically.
</details>

<details>
  <summary>**Partial**</summary>

  Some units cleared and the rest stay On Hold. A middle disposition for when part of the lot is good and part isn't.
</details>

The status values are `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.

HEADS UP

**Inspection-required stock is not on-hand until dispositioned**

When a receipt posts for an item with a receipt inspection plan, its tracked entities are set to **On Hold**, not Available. They're received but you can't sell or consume them yet. Only Accept (or the per-sample passes) releases them.

### 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](/docs/reference/quality.md).

### Recording samples

Each recorded result is a sample on the lot. For a **Serial** item, the inspector scans or selects a discrete tracked entity per sample; for **Batch / Inventory / Non-Inventory** items there's no discrete unit to scan, so the sample records just a Pass/Fail with `trackedEntityId` 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.

Disposition writes the terminal status. Rejecting a **non-tracked Inventory** lot also posts a compensating negative inventory adjustment, because that received quantity has no per-entity status to exclude it from on-hand. A reject can also open an issue automatically: the reject dialog has an **Open an NCR for MRB disposition** option with an issue type selector. See [Quality](/docs/reference/quality.md) for how those issues run to closure.

## 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`):

FieldType

<details>
  <summary>**Inspect All**`All`</summary>

  Sample size equals the whole lot. Accept on 0 defects, reject on 1.
</details>

<details>
  <summary>**Inspect First N**`First`</summary>

  A fixed count off the top of the lot (Sample Size). Accept 0 / reject 1.
</details>

<details>
  <summary>**Percentage**`Percentage`</summary>

  A share of the lot (Percentage of Lot), rounded up, capped at the lot size. Accept 0 / reject 1.
</details>

<details>
  <summary>**AQL**`AQL`</summary>

  Statistical acceptance sampling per ANSI/ASQ Z1.4 or ISO 2859-1 — the sample size and accept/reject numbers come from the standard's tables.
</details>

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

AQL — 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:

1. **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`).
2. **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`).

The standard AQL values Alforse exposes are the twelve canonical steps `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.

NOTE

**The plan is snapshotted, not referenced**

When the receipt posts, the resolved numbers are copied onto the inspection (`sampleSize`, `acceptanceNumber`, `rejectionNumber`, `codeLetter`, and the plan's AQL, level, and severity). Editing the inspection plan afterward changes future lots, never the lot already on the dock.

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`):

FieldType

<details>
  <summary>**Task**</summary>

  A do-this instruction with no captured value — a checklist line.
</details>

<details>
  <summary>**Measurement**</summary>

  A dimensional reading. Requires a **unit of measure**, and takes an optional min/max range that bounds an acceptable value.
</details>

<details>
  <summary>**Value**</summary>

  A free numeric or text value with no unit requirement.
</details>

<details>
  <summary>**Checkbox**</summary>

  A pass/acknowledge tick.
</details>

<details>
  <summary>**Timestamp**</summary>

  Captures the moment the step was performed.
</details>

<details>
  <summary>**Person**</summary>

  Captures who performed the step.
</details>

<details>
  <summary>**List**</summary>

  A pick from a defined set of options (the `listValues`).
</details>

<details>
  <summary>**File**</summary>

  An attachment — a photo, a scan, a cert.
</details>

<details>
  <summary>**Inspection**</summary>

  A nested inspection reference.
</details>

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:

FieldType

<details>
  <summary>**balloonNumber**required</summary>

  The number stamped on the drawing next to the characteristic — the reference an inspector reads off.
</details>

<details>
  <summary>**description**required</summary>

  What the characteristic is (a bore diameter, a hole position, a surface finish).
</details>

<details>
  <summary>**nominalValue**</summary>

  The target value.
</details>

<details>
  <summary>**tolerancePlus / toleranceMinus**</summary>

  The allowed deviation above and below nominal.
</details>

<details>
  <summary>**unitOfMeasureCode**</summary>

  The unit the nominal and tolerances are expressed in.
</details>

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**.

### Gauges

A characteristic can name the [gauge](/docs/reference/calibration.md) type it must be measured with, in the plan editor's **Gauge Type** column. Leave it empty to allow any gauge.

When an inspection runs, each characteristic has a **Gauge** cell. The list offers only Active gauges, of the required type when one is set, with the gauges recently used at the same work center first; all receipts share one list. The gauge is recorded once per lot and characteristic, with the time it was recorded. An out-of-calibration gauge is flagged but can still be recorded, and a gauge retired later still shows on the lots it measured.

## Related

**Quality**

The module overview — issues, dispositions, and where inbound inspection fits.

[Open](/docs/reference/quality.md)

**Issues and NCRs**

A rejected lot can open an issue automatically; this is how issues are driven to closure.

[Open](/docs/reference/quality.md)

**Shop floor (MES)**

Where in-process inspection steps surface for operators.

[Open](/docs/reference/mes.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.