NexTool Solutions

GLPI sait combien de toners vous avez en stock, mais pas sur quel ticket le dernier est sorti. Les consommables sont natifs (ConsumableItem), la sortie de stock est manuelle et déconnectée du ticket - alors quand vient le moment d'auditer la consommation d'une période ou de justifier le coût d'un ticket, l'information n'existe tout simplement pas. Le module Stock de NexTool comble ce manque en reliant les deux côtés que GLPI a laissés séparés.

Le problème

GLPI possède un module natif de consommables - ConsumableItem, stocké dans les tables glpi_consumableitems (le modèle de consommable) et glpi_consumables (chaque unité physique). Il suit la quantité, l'entrée et la sortie : sortir une unité revient, au fond, à remplir la colonne date_out de cette ligne. Le problème n'est pas le contrôle du solde en soi - c'est que cette sortie naît détachée. Nativement, un consommable est "attribué" à un utilisateur ou à un groupe, jamais à un ticket. Alors quand un technicien consomme trois barrettes de mémoire pour résoudre une demande, il enregistre bien la sortie, mais nulle part il n'est écrit que ces trois barrettes sont sorties à cause de ce ticket.

Les conséquences apparaissent ensuite. Auditer la consommation d'une période par ticket devient impossible : les données vivent sur deux îles qui ne se croisent pas. Chiffrer les consommables d'une demande devient un exercice de mémoire du technicien. Et la sortie manuelle, faite hors du flux du ticket, ouvre la porte à l'erreur la plus courante - oublier de l'enregistrer, ou l'enregistrer sur le mauvais consommable, sans personne pour vérifier.

Comment ça marche

Le module Stock construit un pont bidirectionnel entre les tickets et les consommables natifs, sans dupliquer les données : il continue d'écrire dans glpi_consumables, en rattachant simplement chaque sortie au ticket qui l'a provoquée.

• Onglet Stock sur le ticket - le technicien choisit le consommable et la quantité dans le ticket lui-même et débite là, sans changer d'écran.
• Onglet Sorties sur le consommable - le même mouvement apparaît sur la fiche du consommable, avec le ticket lié visible.
• Validation du solde en temps réel - avant de débiter, le module vérifie le solde disponible avec le calcul natif de GLPI (unités dont date_out est vide), empêchant toute sortie au-delà de ce qui existe.
• Écriture dans le stock natif - la sortie remplit date_out sur les unités consommées et écrit le lien avec le ticket sur la ligne native elle-même, gardant le stock de GLPI cohérent.
• Contre-passation avec retour configurable - une sortie peut être contre-passée en un clic, renvoyant les unités au stock ; le comportement est configurable.
• Rapports avec export CSV - un tableau de mouvements avec filtres par période, consommable et statut, et un bouton d'export CSV pour le tableur.
• Ticket obligatoire - une option qui impose que toute sortie soit liée à un ticket, fermant la porte aux sorties sans traçabilité.

Comment l'activer

1. Installez NexTool sur votre GLPI (10 ou 11).
2. Allez dans Configuration > NexTool > Modules.
3. Activez le module Stock et cliquez sur Configurer.
4. Dans l'onglet des réglages, définissez si la contre-passation renvoie le consommable au stock et si le ticket est obligatoire à chaque sortie.

Natif vs. module Stock

L'idée n'est pas de remplacer le consommable natif - c'est de l'étendre. Le tableau montre où le comportement natif s'arrête et où le module prend le relais :

Diagnostic directement en base

Pendant que vous évaluez le module - ou juste pour vérifier ce que le natif enregistre - vous pouvez mesurer le solde et les sorties directement dans les tables de GLPI. Les deux requêtes que nous utilisons :

-- Solde réel par consommable, directement depuis les tables natives de GLPI.
-- Chaque ligne de glpi_consumables est UNE unité physique : date_out vide = en stock,
-- date_out rempli = déjà consommée. glpi_consumableitems est le modèle du consommable.
SELECT ci.id                       AS consommable_id,
       ci.name                     AS consommable,
       SUM(c.date_out IS NULL)     AS en_stock,
       SUM(c.date_out IS NOT NULL) AS consommes,
       COUNT(c.id)                 AS total_enregistre
FROM glpi_consumableitems ci
LEFT JOIN glpi_consumables c ON c.consumableitems_id = ci.id
WHERE ci.is_deleted = 0
GROUP BY ci.id, ci.name
ORDER BY en_stock ASC;

-- Sorties déjà liées aux tickets : au débit, le module écrit itemtype='Ticket'
-- et items_id = le numéro du ticket sur la ligne native elle-même.
-- Sur un GLPI sans le module ce filtre ne renvoie rien (la sortie native va vers User/Group).
SELECT c.items_id      AS ticket,
       ci.name         AS consommable,
       COUNT(*)        AS unites_sorties,
       MAX(c.date_out) AS derniere_sortie
FROM glpi_consumables c
JOIN glpi_consumableitems ci ON ci.id = c.consumableitems_id
WHERE c.date_out IS NOT NULL
  AND c.itemtype = 'Ticket'
GROUP BY c.items_id, ci.name
ORDER BY derniere_sortie DESC;

Ce que l'exploitation nous a appris

En maintenance de centres de services clients, la traçabilité par ticket a toujours été la pièce manquante - GLPI pouvait dire "20 toners sont sortis ce mois-ci" mais pas "quels tickets les ont consommés". Sans ce recoupement, auditer la consommation par période se reconstruisait au jugé. Deux erreurs reviennent sur le terrain. La première est la sortie manuelle sur le consommable sans citer le ticket : le technicien remet l'article par le flux natif, le solde tombe même juste, mais la demande n'a pas de coût et le rapport est troué. La seconde est plus discrète - déployer le module et oublier d'activer le "ticket obligatoire" : pendant des semaines, des sorties coexistent, certaines liées et d'autres non, et ce n'est qu'au moment où quelqu'un demande le rapport que le trou apparaît. Le détail que seuls les opérateurs connaissent : le module n'invente pas de table de stock parallèle, il écrit dans la même glpi_consumables - donc la sortie faite depuis le ticket et celle faite depuis l'écran natif se disputent le même solde. Tout standardiser par le ticket, avec l'obligation activée dès le premier jour, est ce qui empêche les deux chiffres de diverger.

Pour qui (et quand NE PAS l'utiliser)

Stock a du sens pour les équipes de support et d'infrastructure qui consomment des fournitures physiques - toners, câbles, pièces, mémoire - pendant leurs interventions et doivent rattacher chaque usage au ticket qui l'a généré. Et pour les responsables qui veulent voir le coût des consommables par demande sans exporter des tableurs de deux systèmes.

Cela n'en vaut pas la peine si vous n'utilisez pas les consommables natifs de GLPI - le module s'appuie dessus, il ne les remplace pas - ou si le contrôle des stocks de votre exploitation vit dans un ERP externe, qui reste la source de vérité. Dans ces cas, la bonne intégration est avec l'ERP, pas une seconde comptabilité de stock dans GLPI.

Compatibilité

• GLPI : 10.0+ et 11.0+.
• Disponibilité : à la demande.
• Plugin : NexTool 3.x ou supérieur.

Stock fait partie de NexTool, l'écosystème de modules qui étend GLPI sans personnalisation de code. Pour voir la sortie par ticket fonctionner dans votre environnement, parlez à l'équipe.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe Nextool Solutions.