Technical reception

Technical reception is the workflow that brings a component into stock. It unfolds in two mutually controlled phases, materialised by the StockItem’s technicalReceptionStatus field (pending then validated). As long as the technical phase has not been validated, installation on an aircraft is blocked.

Warehouse phase (R1) — logistic reception: PN/SN identification, counting, link to a delivery note, source supplier.
Technical phase (R2) — conformity check by the airworthiness technician: physical inspection, attached documents (EASA Form 1 and certificates), capture of initial StockItemMeterSnapshot records (TSN, TSO, CSN…).

Both phases are mandatory for a serialised component subject to airworthiness. For consumables and batch hardware, only the warehouse phase is required.

Full workflow

Reception of a serialised component

Warehouse phase — create the StockItem
Scan or enter the PN, pick the NCAGE, read the SN from the OEM label, select the initial storage. The StockItem is born with technicalReceptionStatus = pending. API: POST/stock-items (or POST/stock-items/bulk for an atomic multi-SN reception).
Warehouse phase — receipt movement
On the created StockItem, the “Receive” modal records the movement (quantity received, source supplier, reference document, date) and can move the item to another storage. API: POST/stock-items/:id/movements/receipt.
Airworthiness technician worklist
The technician finds StockItems to validate on /stocks/pending-reception. The worklist is filtered server-side (technicalReceptionStatus=pending): only pending items are loaded, in pages, with infinite scroll (rows load as you scroll down, with a “Load more” button as a fallback) — the list stays responsive even with a large backlog. The inventory filter bar (part, type, storage, condition, serial number, expiry) applies on top, also server-side.
Technical phase — documents and inspection
On the StockItem sheet (route /admin/stock-items/$id), the Documents tab carries the EASA Form 1 (or defence equivalent), delivery note, certificate of conformity, test report… Polymorphic multi-attachments via DocumentsPanel resourceType=“stock_item” — the tab is visible at any R2 status (pending / validated). Physical inspection stays out-of-system; any non-conformity must be handled through a supplier-return process managed elsewhere (no native “Refused” status today).
Technical phase — R2 validation
CompleteTechnicalReceptionDialog modal, two sections:
1. Technical identification (collapsible, expanded by default — this is the airworthiness technician’s core job) — physical condition (StockCondition), OEM manufacture date, modification level (S1000D modLevel), embedded software version, and a link to the EASA Form 1 chosen from the documents already attached to the article. A + Attach a document button opens a sub-dialog (auto-linked to resourceType=stock_item) — no need to close R2 to add the EASA Form 1, delivery note or certificate. The picker refreshes after upload so the new doc becomes selectable. The toggle can still collapse the section for « quick » receipts (consumables with no identification). On submit, if any of these fields changed, a PATCH/stock-items/:id fires BEFORE the complete call. If it fails, the complete call is skipped (no mixed state).
2. Counter snapshots — capture of
  StockItemMeterSnapshot
  
  records (one per counter applicable to the PN through PartNumberMeterApplicability) + global note. API: POST/stock-items/:id/complete-technical-reception. Atomic transition pending → validated (snapshots + status + audit in a single transaction).
Component available
Once validated, the StockItem becomes eligible for install / transfer / adjustment modals. The snapshots serve as the origin for remaining-potential computation.

Expected documents

For components subject to airworthiness, the technical phase requires:

EASA Form 1 (or defence equivalent FRA-1, FAA 8130-3), signed and legible.
Delivery note from the direct supplier.
Certificate of conformity from the manufacturer or repair shop.
Test report for refurbished components.

For critical MEL/CDL items, add the calibration certificate when the component is a measurement instrument.

Edge cases

Return from a repair order — the verdict is given here

When the item presented for technical reception comes back from a repair order still awaiting its verdict (status returned), the dialog adapts so there is no round-trip back to the OR page:

A banner names the order concerned (“Repair return — RO-0042”).
The physical-condition dropdown is replaced by a requalification verdict: Serviceable — back in service or Scrap. Attaching the repairer’s EASA Form 1 is still available via the same picker.
On validation, both the technical reception and the OR requalification are recorded in one gesture: the item moves to its final condition (serviceable / scrap) and the order closes automatically. The technician no longer needs to reopen the OR screen.

While the part is back but not yet requalified, inventory shows it distinctly (“Repair return — to requalify”, repair_in_progress + technical reception pending) so it is no longer confused with a part still at the repairer. Requalification also remains available directly from the OR page for cases handled outside the worklist.

Container components

When receiving a container (turbine, computer), the technical phase may be performed with its sub-modules already installed. The apparent decomposition is then frozen at validation time. A later sub-module removal requires a new technical phase for the sub-module alone.

Creating a container on the fly

While receiving an article, the Container field lets you store it inside a container (case, bin — an article whose type has the “container” flag). If the desired container does not exist yet, the “+ New” button opens a small dialog: pick the container type and its serial number; the container inherits the location of the current reception. Once created, it is automatically selected for the article — without leaving the reception. The button is enabled as soon as a storage is chosen.

Unpacking a container

To empty a container received full, the “Unpack container” button (a container’s “Contained items” tab) opens a dialog where you pick, for each item, its destination location (pre-filled with the container’s current location), plus the emptied container’s location. On confirm, all items are taken out and each real relocation is recorded as a transfer movement. The emptied container remains a reusable container.

Removing an item from a container

To take an item out of the case it is stored in, a “Remove from container” button is available on the item’s page, and a “Remove” button per row in the container’s “Contained items” tab. The item stays at its location (storage), simply no longer inside the case. If the item is installed in a component (active fitment), the action is refused: you must perform a removal/dépose (airworthiness impact), not a simple storage take-out.

Batch reception

For batched components (screws, seals, consumables), a single StockItem carries the total quantity. Being non-serialised, these items are created directly with status not_required: they do not go through technical validation (R2 worklist) — only the storekeeper phase applies. Later transfers (via the “Transfer” modal) split the batch across storages.