Centre d’aide/Workflows & automatisation/La pipeline view : où le travail est bloqué, pas où vit chaque asset
03Workflows & automatisation4 min de lecture

La pipeline view : où le travail est bloqué, pas où vit chaque asset

Comment la page pipeline montre tous les workflows et toutes les stages d’un coup, pourquoi la réception a son propre bloc au-dessus, et où le retest se passe réellement.

La pipeline view (/core/pipeline) est la lecture opérationnelle du workflow engine : une section par workflow activé, un résumé par stage, et les chiffres dont un responsable d’entrepôt a besoin pour décider où l’équipe doit travailler cet après-midi. Ce n’est explicitement pas un endroit où modifier des assets un par un. Les goulets d’étranglement sont visibles ici ; la correction se fait dans Inventaire, Testing ou Outbound.

La réception a son propre bloc

Les assets n’entrent dans une stage de workflow qu’une fois que la réception les a créés ; une pipeline qui n’afficherait que des stages aurait donc l’air vide le matin d’arrivage le plus chargé du mois. Au-dessus des sections de workflow, la pipeline montre par conséquent le travail de réception en amont sous forme de worklist, pas de tuile : les receiving sessions ouvertes et en pause en lignes, avec une action directe de scan ou de reprise, et en dessous les inbound orders actives sans session, comme du travail que l’on peut démarrer. Une order partiellement reçue — deux items sur trois — obtient « Continuer la réception ». Quelles orders comptent, c’est la même règle que celle de l’aperçu Réception : pas encore entièrement reçue, ou portant encore une session ouverte ou en pause. Un brouillon, une order annulée ou une order entièrement reçue sans session n’apparaît sur aucun des deux écrans.

Filtres et tris

La vue par stage filtre par inbound order, par client et par warehouse, et dispose d’un interrupteur pour n’afficher que les items hors SLA — le SLA étant les heures du template de la stage, ou le SLA du contrat quand un contrat en définit un. Le tri se fait par volume d’assets (la stage la plus pleine d’abord), par urgence, ou par l’item le plus ancien de la stage. Trois tris, trois questions : où se trouve le gros du travail, où est-il le plus en retard, et qu’est-ce qui traîne là depuis le plus longtemps.

Le retest vit dans la file de testing

Un asset déjà gradé qui rencontre un problème — le contrôle avant expédition d’un acheteur échoue, un audit d’entrepôt attrape un appareil regradé — retourne au testing via l’action retest sur l’asset, qui le remet en file. L’ancienne ligne de file gradée reste dans le tableau comme historique, si bien que l’asset possède une chaîne gradé, retesté, gradé à nouveau qu’un auditeur peut suivre. Un retest est refusé tant que l’asset a encore un item de file ouvert : attendez qu’il soit gradé avant de le tester à nouveau. La pipeline rapporte la conséquence — un item de plus dans Diagnostics — mais l’action elle-même n’est pas sur la page pipeline.

Les actions groupées vivent dans Inventaire

Sélectionner une stage et faire avancer quarante assets d’un coup n’est pas le métier de la pipeline. Le travail en masse se fait dans Inventaire, où une sélection peut être envoyée à l’effacement, étiquetée, ajoutée à un outbound, dotée d’un evidence package, déplacée, journalisée comme reconditionnée ou mise en vente, chacune avec un résultat par asset. La pipeline est la carte. Inventaire est le camion.

Ouvrir les appareils nécessitant une attention

La liste signale les appareils sans workflow et ceux dont un délai d’étape ou contractuel existant est dépassé. Chaque ligne présente le numéro de série, l’étape actuelle, l’ordre de réception et l’échéance initiale. Plusieurs motifs restent sur une seule ligne. Les appareils vendus, expédiés, recyclés ou mis au rebut sont exclus. Sans personne affectée dans la source, la liste indique « Non renseigné ». La recherche porte sur toute la sélection filtrée avant pagination ; les filtres supérieurs s’appliquent aussi. Ouvrez la fiche de stock, effectuez les modifications dans le processus existant, puis actualisez Pipeline. Un échec de lecture affiche une erreur permettant de réessayer, et non une liste vide.

Suivre les preuves et calculs en attente

Une liste distincte, consultable et paginée présente les évaluations de preuves ouvertes et les problèmes Carbontrace actuels de votre organisation. Les actions ouvrent l’import concerné. Administrateurs et responsables accèdent aux problèmes de calcul actuels et aux données source, paramètres de connexion ou imports manuels de résultats. Les anciennes exécutions remplacées et les appareils calculés avec succès sont exclus. Les tentatives planifiées ne s’affichent que si elles sont enregistrées. Actualisez après résolution. Le travail de réception permet aussi de rechercher et paginer, avec personne affectée, auteur de session et note. Une session en pause conserve son statut neutre et son action de reprise. Les calculs ne bloquent pas le travail physique.