Réception technique

La réception technique est le workflow d’entrée d’un composant dans le stock. Elle se déroule en deux phases mutuellement contrôlées, matérialisées par le champ technicalReceptionStatus du StockItem (pending puis validated). Tant que la phase technique n’est pas validée, l’installation sur aéronef est bloquée.

  1. Phase magasinier (R1) — réception logistique : identification du PN/SN, comptage, association à un bon de livraison, choix du fournisseur source.
  2. Phase technique (R2) — vérification de conformité par le technicien navigabilité : contrôle physique, documents joints (EASA Form 1 et certificats), saisie des StockItemMeterSnapshot initiaux (TSN, TSO, CSN…).

Les deux phases sont obligatoires pour un composant sérialisé soumis à navigabilité. Pour les consommables et la quincaillerie en lot, seule la phase magasinier est nécessaire.

Workflow complet

Réception d'un composant sérialisé

  1. Phase magasinier — création du StockItem

    Scanner ou saisir le PN, choisir le NCAGE, lire le SN sur l’étiquette OEM, sélectionner le storage de stockage initial. Le StockItem naît avec technicalReceptionStatus = pending. API : POST/stock-items (ou POST/stock-items/bulk pour une réception multi-SN atomique).

  2. Phase magasinier — mouvement de réception

    Sur le StockItem créé, modale « Réceptionner » qui enregistre le mouvement (quantité reçue, fournisseur source, référence document, date) et permet de basculer vers un autre storage. API : POST/stock-items/:id/movements/receipt.

  3. Worklist du technicien navigabilité

    Le technicien retrouve les StockItems à valider sur /stocks/pending-reception. La worklist est filtrée côté serveur (technicalReceptionStatus=pending) : seuls les articles en attente sont chargés, par pages, avec défilement infini (les lignes se chargent à mesure qu’on descend, un bouton « Charger plus » servant de repli) — la liste reste fluide même avec un grand volume d’articles en attente. La barre de filtres de l’inventaire (article, type, stockage, état, n° de série, péremption) s’applique en plus, également côté serveur.

  4. Phase technique — documents et inspection

    Sur la fiche StockItem (route /admin/stock-items/$id), l’onglet Documents accueille l’EASA Form 1 (ou équivalent défense), bon de livraison, certificat de conformité, rapport de test… Multi-attachements polymorphiques via DocumentsPanel resourceType=“stock_item” — l’onglet est visible quel que soit le statut R2 (pending / validated). L’inspection physique reste hors-système ; toute non-conformité doit faire l’objet d’un retour fournisseur géré ailleurs (pas de statut « Refusé » natif aujourd’hui).

  5. Phase technique — validation R2

    Modale CompleteTechnicalReceptionDialog, deux sections :

    1. Identification technique (pliable, déployée par défaut — c’est le cœur du boulot du technicien navigabilité) — état physique (StockCondition), date de fabrication OEM, niveau de modification (S1000D modLevel), version logicielle embarquée, et lien vers l’EASA Form 1 parmi les documents déjà attachés à l’article. Un bouton + Joindre un document ouvre une sous-modale d’upload (auto-lié à resourceType=stock_item) — pas besoin de fermer R2 pour ajouter l’EASA Form 1, le BL ou un certificat de conformité. À la fin de l’upload, le picker EASA Form 1 se rafraîchit et le doc devient sélectionnable. Le toggle reste disponible pour replier sur les réceptions « rapides » (consommables sans identif). Au submit, si l’un de ces champs a changé, un PATCH/stock-items/:id est déclenché AVANT le complete. En cas d’échec, le complete n’est pas envoyé (pas d’état mixte).

    2. Snapshots compteurs — saisie des

      StockItemMeterSnapshot

      (un par compteur applicable au PN via PartNumberMeterApplicability) + note globale. API : POST/stock-items/:id/complete-technical-reception. Transition atomique pending → validated (snapshots + statut + audit en une transaction).

  6. Composant disponible

    Une fois validated, le StockItem est éligible aux modales de pose / transfert / ajustement. Les snapshots servent d’origine au calcul du potentiel restant.

Documents attendus

Pour les composants soumis à navigabilité, la phase technique exige :

  • EASA Form 1 (ou équivalent défense FRA-1, FAA 8130-3) signée et lisible.
  • Bon de livraison du fournisseur direct.
  • Certificat de conformité du fabricant ou de l’atelier réparateur.
  • Rapport de test ou « Test Report » pour les composants reconditionnés.

Pour les MEL/CDL critiques, ajouter le certificat de calibration s’il s’agit d’un instrument de mesure.

Cas particuliers

Retour d’un ordre de réparation — le verdict se donne ici

Quand l’article présenté à la réception technique revient d’un ordre de réparation encore en attente de verdict (statut returned), la modale s’adapte pour éviter tout aller-retour vers la fiche OR :

  • Un bandeau rappelle l’ordre concerné (« Retour de réparation — RO-0042 »).
  • Le choix d’état physique est remplacé par un verdict de requalification : Apte — remis en service ou Rebut. Joindre l’EASA Form 1 du réparateur reste possible via le même picker.
  • À la validation, la réception technique et la requalification de l’OR sont enregistrées d’un seul geste : l’article bascule dans son état final (en service / rebut) et l’ordre se clôt automatiquement. Le technicien n’a plus à rouvrir l’écran OR.

Tant que la pièce est revenue mais pas encore requalifiée, l’inventaire l’affiche distinctement (« Retour répa — à requalifier », repair_in_progress + réception technique pending) : elle n’est plus confondue avec une pièce encore chez le réparateur. La requalification reste aussi accessible directement depuis la fiche OR pour les cas gérés hors worklist.

Composant containers

Quand on reçoit un container (turbine, calculateur), la phase technique peut être conduite avec ses sub-modules déjà installés. Dans ce cas la décomposition apparente est figée au moment de la validation. Une dépose ultérieure de sub-module impose une nouvelle phase technique du sub-module seul.

Création d’un conteneur à la volée

Pendant la réception d’un article, le champ Conteneur permet de le ranger dans un conteneur (caisse, bac — un article dont le type a la case « conteneur »). Si le conteneur voulu n’existe pas encore, le bouton « + Nouveau » ouvre une petite fenêtre : on choisit le type de conteneur et son numéro de série ; le conteneur hérite de l’emplacement de la réception en cours. Une fois créé, il est sélectionné automatiquement pour l’article — sans quitter la réception. Le bouton est actif dès qu’un stockage est choisi.

Déballer un conteneur

Pour vider un conteneur reçu plein, le bouton « Déballer le conteneur » (onglet « Articles contenus » d’un conteneur) ouvre une fenêtre où l’on choisit, pour chaque pièce, son emplacement de destination (pré-rempli avec l’emplacement actuel du conteneur), ainsi que l’emplacement du conteneur vidé. À la validation, toutes les pièces sortent et chaque relocalisation réelle est tracée comme un mouvement de transfert. Le conteneur vidé reste un conteneur réutilisable.

Sortir une pièce d’un conteneur

Pour retirer une pièce de la caisse où elle est rangée, le bouton « Sortir du conteneur » est disponible sur la fiche de la pièce, et un bouton « Sortir » par ligne dans l’onglet « Articles contenus » du conteneur. La pièce reste à son emplacement (stockage), simplement plus dans la caisse. Si la pièce est montée dans un composant (pose active), l’action est refusée : il faut alors faire une dépose (impact navigabilité), pas une simple sortie de rangement.

Réception en lot

Pour les composants en lot (vis, joints, consommables), un seul StockItem porte la quantité totale. N’étant pas sérialisés, ces articles sont créés d’emblée avec le statut not_required : ils ne passent pas par la validation technique (worklist R2) — seule la phase magasinier s’applique. Les transferts ultérieurs (modale « Transférer ») ventilent le lot entre storages.

Voir aussi