SeringueiroGuide simple pour enregistrer une collecte de latex dans l’app Seringueiro, lier les bonnes activités et finaliser le flux sans casser la routine du terrain.
Matheus Peguim
Quand une journée de terrain avance bien, la collecte ne doit pas casser le rythme. Dans l’app Seringueiro, le flux de collecte a été pensé pour aller droit au point, lier les bonnes activités et éviter qu’un enregistrement utile se perde au moment de finaliser.
Le principe est simple, une collecte propre repose sur trois bases: au moins une photo, les bonnes activités de terrain et une quantité réelle avec le bon récipient.
Le flux s’ouvre comme un wizard en étapes. Cela évite les formulaires trop longs et garde le même rythme du début à la fin.
Pour enregistrer une collecte, l’app demande d’abord une preuve visuelle, puis relie les activités de champ éligibles, ensuite elle confirme l’emballage et la quantité, et enfin elle laisse un passage optionnel par la divulgation au Hub quand ce contexte existe.
La photo n’est pas un détail cosmétique. C’est la preuve minimale exigée par le flux. Sans elle, la collecte ne passe pas à l’étape suivante.
Au moment de la capture, l’app tente aussi d’enregistrer la position de façon best effort. Cela aide à garder une trace plus propre sans transformer la routine en procédure lourde.
L’étape suivante montre les activités de terrain qui peuvent entrer dans la collecte actuelle. Au premier chargement, toutes les activités éligibles arrivent déjà sélectionnées, ce qui réduit du temps quand la journée a suivi le flux normal.
Une activité ne doit pas déjà être liée à une autre collecte. Le filtre protège aussi contre les doublons, pour éviter de rattacher deux fois la même base de terrain.
En pratique, l’app ne retient que les activités du bon contexte, avec le bon rattachement de propriété, module et utilisateur quand ce lien existe.
La collecte n’avance pas avec un récipient implicite. Il faut choisir explicitement le type d’emballage, par exemple box, bag ou drum, puis confirmer une quantity supérieure à zéro.
Ce point compte parce qu’une collecte avec emballage supposé crée vite de la confusion dans l’historique. Le flux a justement été durci pour empêcher ce raccourci.
La divulgation au Hub reste optionnelle. Elle peut être ignorée proprement avec l’action de saut, en sauvegardant la collecte avec marketEnabled=false.
Quand l’utilisateur veut activer cette partie, il faut être en ligne. Hors connexion, l’app bloque l’activation de la divulgation au lieu de laisser croire qu’elle a déjà été prise en compte.
Quand la collecte appartient déjà à un contexte de companyId, cette étape n’apparaît même pas, ce qui évite une décision inutile.
Le flux continue de respecter la logique offline-first. Quand la connexion manque, la collecte peut être sauvegardée en brouillon local avec ses données et ses annexes. Le bouton final n’a pas besoin d’attendre le Firestore ou le Storage pour laisser l’utilisateur sortir proprement du flux.
Si internet revient, la synchronisation repart à la prochaine opportunité. Autrement dit, hors ligne, la collecte peut rester en attente, mais elle ne devrait pas bloquer la fin du travail sur place.
Ces erreurs paraissent petites, mais ce sont elles qui rendent l’historique moins lisible ensuite.
Le retour de succès compte, parce qu’il confirme que la fin du flux a bien été comprise par l’app, même si la synchronisation complète doit encore attendre le réseau.
Non. Le flux exige au moins une photo avant de laisser avancer la collecte.
Non. À la première charge, toutes les activités éligibles arrivent déjà sélectionnées.
Parce qu’une collecte ne peut plus être enregistrée avec un emballage implicite. Le flux demande un choix clair pour éviter l’erreur opérationnelle.
Oui. Elle peut rester en attente localement puis se synchroniser quand la connexion revient.
Non. Cette activation demande une connexion en ligne au moment du changement.
Une collecte bien fermée au bon moment évite de revenir le soir sur une routine qui aurait dû rester simple.
Continuer la lecture
