---
title: "Inventaire mobile - traçabilité"
weight: 36
description: "Cycle de vie d'un équipement, dates métier, historique d'évènements, transfert d'un équipement vers un autre site ou client, codes-barres 1D, réassignation de QR. Compléments à l'inventaire mobile."
---

# Inventaire mobile - traçabilité

Cette page complète le guide [Inventaire mobile](inventaire-pwa) avec les fonctionnalités de traçabilité ajoutées en version 2.2.0 : cycle de vie d'un équipement, dates métier, historique d'évènements, transfert entre sites ou clients, codes-barres 1D / 2D autres que QR, et réassignation explicite d'un code QR collé physiquement.

## Cycle de vie d'un équipement

Chaque équipement porte désormais un **cycle de vie** parmi 5 valeurs :

| Valeur | Signification |
|--------|---------------|
| En service | Production normale chez le client. Valeur par défaut à la création. |
| En réparation | En atelier, en cours de réparation. L'équipement existe mais n'est pas utilisable. |
| Hors service | Décommissionné chez le client, en attente de retrait. Reste affichable, plus contrôlable. |
| Retour stock | Repris par le distributeur, retour au stock interne. |
| Rebut | Mis au rebut. État terminal, aucune transition n'est possible. |

Les **transitions** autorisées sont contraintes :

| Depuis | Vers |
|--------|------|
| En service | En réparation, Hors service, Retour stock, Rebut |
| En réparation | En service, Hors service, Rebut |
| Hors service | Retour stock, Rebut |
| Retour stock | En service (réinstallation chez nouveau client), Rebut |
| Rebut | (aucune transition) |

Sur l'application, le bouton **"Changer le statut"** ouvre une fenêtre où seules les valeurs autorisées sont proposées dans la liste déroulante (pas de risque de saisir une transition invalide).

À la confirmation, un évènement de type `status_changed` est inscrit dans l'historique de l'équipement avec la raison saisie (optionnelle) et l'utilisateur à l'origine du changement.

## 4 dates métier

À la création et à l'édition d'un équipement, vous pouvez renseigner :

| Date | Usage |
|------|-------|
| Date d'installation | Date de première installation chez un client. Renseignée à la création (défaut : aujourd'hui). |
| Fin de garantie | Fin de garantie constructeur. Sert aux alertes back-office et au tri "à surveiller". |
| Dernière maintenance | Pilotée automatiquement par le système : à la clôture d'une intervention de maintenance liée à cet équipement, la date est mise à jour si la nouvelle est plus récente. **Non modifiable depuis l'application mobile.** |
| Prochaine échéance | Prochaine intervention de maintenance prévue (saisie libre). Peut être recalculée automatiquement en back-office selon une règle "dernière maintenance + N mois" configurable. |

La date d'installation devient verrouillée dès qu'un transfert a été effectué (voir section suivante).

## Historique d'évènements

Chaque action métier sur un équipement laisse une trace dans l'historique. Les types d'évènements sont :

| Type | Cas |
|------|-----|
| Création | À la création d'un équipement. |
| Mise à jour | Modification d'un champ métier (hors transitions dédiées). |
| Transfert | Déplacement vers un autre site ou client. |
| Changement de cycle de vie | Transition de statut. |
| Maintenance effectuée | Clôture d'une intervention de maintenance liée. |
| QR scanné | Affectation d'un code (QR ou code-barres). |
| QR réassigné | Réassignation d'un code depuis un autre équipement. |
| Mis hors service | Raccourci de transition vers "Hors service". |
| Mis au rebut | Idem vers "Rebut". |

L'historique est consultable depuis la fiche détail de l'équipement, en back-office Dolibarr (section "Historique" sur la fiche équipement).

### Filtrage côté client

Lorsqu'un technicien intervient chez un client qui a **repris** un équipement déjà passé chez un autre propriétaire (cas d'occasion, transfert de parc), il ne voit **que l'historique de la période courante**, pas ce qui s'est passé avant. Exemple :

- Marie achète une machine d'occasion à Jean en mars 2026.
- Le tech qui intervient chez Marie ne voit que les évènements postérieurs à mars 2026.
- L'évènement "Transfert" lui-même apparaît (c'est la transition).

Le back-office admin voit toute l'histoire, avec mention claire du propriétaire pour chaque période.

## Transfert d'un équipement

Cas d'usage : déplacer un distributeur d'un café à un autre, reprendre une machine pour réparation, ou revendre à un autre client.

### Conditions

Le bouton **"Déplacer..."** est disponible sur la fiche d'un équipement uniquement si son cycle de vie est :

- En service, ou
- En réparation, ou
- Retour stock.

Sur **Hors service** ou **Rebut**, le bouton est grisé avec une infobulle expliquant pourquoi. Pour transférer une machine décommissionnée, il faut d'abord la passer à "Retour stock".

### Flux

Le formulaire de transfert se déroule en 4 étapes (toutes côté smartphone, possible hors ligne) :

1. **Choix du nouveau client** -- recherche autocomplete avec option de créer un client en cours de route.
2. **Choix du nouveau site** -- liste filtrée par le client choisi, avec option de créer un site.
3. **Détails du transfert** :
   - Date effective (défaut : maintenant, modifiable pour antidater un transfert).
   - Raison (obligatoire, min 3 caractères) : "Vente d'occasion", "Reprise SAV", "Réinstallation après réparation".
   - Nouveau cycle de vie après transfert (optionnel, par défaut on conserve le courant).
4. **Confirmation** : récapitulatif "De <client>/<site> vers <client>/<site>, raison : ...".

### Hors ligne

Le transfert fonctionne sans réseau, comme la création. L'équipement est muté localement (nouveau client/site/cycle de vie + drapeau "transfert en attente"). La synchronisation se déclenchera au retour de connectivité, dans l'ordre :

1. Clients en attente.
2. Sites en attente.
3. Équipements (création) en attente.
4. Transferts en attente.

### Transferts multiples hors ligne

Si vous transférez un équipement A -> B -> C sans synchroniser entre B et C, **seul le dernier transfert (B -> C) sera enregistré côté serveur**. L'étape intermédiaire B est perdue dans ce cas (compromis assumé). Cas rare en pratique. Pour conserver l'étape intermédiaire, synchronisez entre les deux transferts.

## Codes-barres 1D et 2D

À partir de la version 2.2.0, l'application reconnaît plusieurs formats de code en plus du QR :

| Format | Cas d'usage |
|--------|-------------|
| QR code | Étiquettes pré-imprimées custom, génération à la volée (déjà disponible en 2.0.64). |
| Code 128 | Étiquettes constructeur (numéros de série gravés sur la machine). |
| EAN-13 | Code produit standard. |
| DataMatrix | Étiquettes constructeur compactes (pharma, électronique). |
| PDF417 | Bon de livraison, étiquette logistique. |

Le format détecté est stocké automatiquement avec la valeur lue, et visible sur la fiche détail.

**Génération** : seul le QR peut être généré côté application. Les autres formats sont en lecture seule (on lit ce que le constructeur ou le logisticien a mis sur la machine).

**Compatibilité navigateur** : sur les navigateurs modernes (Chrome, Edge, Firefox, Safari iOS 17+), la détection utilise le détecteur natif. Sur les anciens (Safari iOS < 17, certains Android), un module de secours est chargé à la volée.

## Réassignation d'un QR

Cas d'usage courant : un QR collé physiquement sur le support (mur du local, support du distributeur) reste en place quand la machine est remplacée. Plutôt que d'imposer au technicien de gratter l'étiquette, on permet de **réassigner** le QR au nouvel équipement, en gardant la trace.

### Flux

Au scan d'un code déjà attaché à un autre équipement, l'application propose **deux choix** :

- **"Conserver sur l'ancien équipement"** : annule l'opération. Vous devrez choisir un autre code.
- **"Réassigner à ce nouvel équipement"** : ouvre un mini-formulaire :
  - Raison (obligatoire, min 5 caractères) : "Étiquette ré-utilisée après dépose", "Erreur d'attribution initiale", etc.
  - Saisie de **"OUI"** en clair pour confirmer (anti-fat-finger).

À la confirmation, le code est détaché de l'ancien équipement, attaché au nouveau, et deux évènements sont inscrits dans l'historique :

- Sur l'ancien équipement : `qr_reassigned` avec la raison et l'id du nouvel équipement.
- Sur le nouvel équipement : `qr_scanned` avec la raison et l'id de l'ancien équipement.

### Mode strict

Pour les métiers à traçabilité légale stricte (extincteurs réglementaires, équipements médicaux), l'administrateur peut positionner la constante `SMARTINTERVENTIONS_QR_COLLISION_STRICT = 1` dans **Configuration > Constantes système**. Dans ce mode :

- Le bouton "Réassigner" disparaît côté application.
- Seul le bouton "Conserver sur l'ancien équipement" reste.
- Côté serveur, toute tentative de réassignation par un autre canal est refusée avec un message d'erreur.

## Périodes de propriété

L'historique des propriétaires successifs d'un équipement est tracé dans une table dédiée (`llx_smartinter_equipment_ownership`). Chaque période contient : date de début, date de fin (vide si période courante), client, site, utilisateur qui a déclenché le début de période, raison.

Les invariants :

- À chaque instant, **au plus une période ouverte** par équipement (sauf après "Retour stock" : la période ouverte est fermée sans en ouvrir une nouvelle).
- À la **création** d'un équipement, une période initiale est ouverte automatiquement.
- À chaque **transfert**, la période courante est fermée et une nouvelle est ouverte.
- À la **décommission** ou au **rebut**, la période courante n'est PAS automatiquement fermée (le client reste propriétaire d'une machine HS tant qu'il ne la rend pas).
- Au **"Retour stock"**, la période courante est fermée. Si la constante `SMARTINTERVENTIONS_INTERNAL_STOCK_FK_SOC` pointe vers une `Societe` interne configurée, une nouvelle période est ouverte vers ce stock interne.

L'admin voit la liste complète des périodes sur la fiche back-office de chaque équipement, sous la section "Historique > Périodes de propriété".

## Endpoints REST (référence technique)

| Endpoint | Description |
|----------|-------------|
| `POST /inventory/equipment/{id}/relocate` | Transférer un équipement vers un autre site / client (cf section "Transfert"). |
| `POST /inventory/equipment/{id}/status` | Changer le cycle de vie d'un équipement (cf section "Cycle de vie"). |
| `POST /inventory/equipment/{id}/qr-reassign` | Réassigner un code QR depuis un autre équipement (cf section "Réassignation"). |
| `GET /inventory/equipment/{id}/events` | Récupérer l'historique d'évènements d'un équipement, filtré par période de propriété pour les utilisateurs externes. |

Tous ces endpoints sont protégés par les permissions Dolibarr standard du module SmartInterventions.

## Récapitulatif des permissions

Pour utiliser ces fonctionnalités, les techniciens doivent avoir :

- `smartinterventions/read` -- lecture (pour voir l'historique).
- `smartinterventions/mobilecreate` -- accès au mode inventaire mobile ET modification (lifecycle, dates, transfert, réassignation QR). C'est ce droit, pas `write`, qui garde ces opérations (déjà requis depuis la 2.0.64).
- `societe/creer` -- pour créer un client en cours de transfert (déjà requis pour la création client dans le core 2.0.64).

Aucun nouveau droit n'a été introduit en 2.2.0.