Inventaire mobile - traçabilité

Cette page complète le guide Inventaire mobile 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 :

Les transitions autorisées sont contraintes :

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 :

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 :

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 :

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)

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.