NexTool Solutions

GLPI weiß, wie viele Toner Sie auf Lager haben, aber nicht, in welchem Ticket der letzte verbraucht wurde. Verbrauchsmaterial ist nativ (ConsumableItem), die Abbuchung erfolgt manuell und losgelöst von der Ticketbearbeitung - und wenn es darum geht, den Verbrauch eines Zeitraums zu prüfen oder die Kosten eines Tickets zu begründen, existiert die Information schlicht nicht. Stock Management von NexTool schließt diese Lücke, indem es die beiden Seiten verbindet, die GLPI getrennt gelassen hat.

Die Herausforderung

GLPI hat ein natives Modul für Verbrauchsmaterialien - ConsumableItem, gespeichert in den Tabellen glpi_consumableitems (das Materialmodell) und glpi_consumables (jede physische Einheit). Es erfasst Menge, Zugang und Abgang: Eine Einheit abzubuchen bedeutet im Grunde, die Spalte date_out dieser Zeile zu füllen. Die Schwierigkeit liegt nicht in der Bestandskontrolle selbst - sondern darin, dass diese Abbuchung losgelöst entsteht. Nativ wird ein Verbrauchsmaterial an einen Benutzer oder eine Gruppe „ausgegeben“, nie an ein Ticket. Wenn also ein Techniker bei der Bearbeitung drei Speichermodule verbraucht, bucht er sie zwar ab, aber nirgends wird festgehalten, dass diese drei Speichermodule wegen genau dieses Tickets entnommen wurden.

Die Folgen zeigen sich später. Den Verbrauch eines Zeitraums pro Ticket zu prüfen wird unmöglich: Die Daten liegen auf zwei Inseln, die sich nicht berühren. Die Materialkosten einer Bearbeitung zu berechnen wird zur Gedächtnisübung des Technikers. Und die manuelle Abbuchung außerhalb des Ticketablaufs öffnet Raum für den häufigsten Fehler überhaupt - vergessen zu buchen oder auf falsches Material zu buchen, ohne dass jemand es prüft.

So funktioniert es

Das Modul Stock Management schafft eine bidirektionale Brücke zwischen Tickets und nativem Verbrauchsmaterial, ohne Daten zu duplizieren: Es schreibt weiterhin in glpi_consumables, verknüpft aber jeden Abgang mit dem Ticket, das ihn ausgelöst hat.

• Reiter Lager im Ticket - der Techniker wählt Material und Menge direkt im Ticket und bucht dort ab, ohne die Seite zu wechseln.
• Reiter Abgänge im Material - dieselbe Bewegung erscheint im Datenblatt des Materials, mit sichtbar verknüpftem Ticket.
• Bestandsprüfung in Echtzeit - vor dem Abbuchen prüft dieses Modul den verfügbaren Bestand anhand der nativen GLPI-Berechnung (Einheiten mit leerem date_out) und verhindert Abbuchungen über den vorhandenen Bestand hinaus.
• Abbuchung im nativen Lager - der Abgang füllt date_out bei den verbrauchten Einheiten und speichert die Verknüpfung zum Ticket in der nativen Zeile selbst, sodass der GLPI-Bestand konsistent bleibt.
• Storno mit konfigurierbarer Rückbuchung - ein Abgang kann mit einem Klick storniert werden, wobei die Einheiten ins Lager zurückgebucht werden; dieses Verhalten ist konfigurierbar.
• Berichte mit CSV-Export - Übersicht der Bewegungen mit Filtern nach Zeitraum, Material und Status sowie Schaltfläche für den CSV-Export in die Tabellenkalkulation.
• Ticket verpflichtend - Option, die verlangt, dass jeder Abgang mit einem Ticket verknüpft ist, und so Abbuchungen ohne Rückverfolgbarkeit ausschließt.

So aktivieren Sie es

1. Installieren Sie NexTool in Ihrem GLPI (10 oder 11).
2. Öffnen Sie Einrichtung > NexTool > Module.
3. Aktivieren Sie das Modul Stock Management und klicken Sie auf Konfigurieren.
4. Legen Sie im Reiter Einstellungen fest, ob ein Storno Material ins Lager zurückbucht und ob für jeden Abgang ein Ticket verpflichtend ist.

Nativ vs. Modul Stock Management

Es geht nicht darum, das native Verbrauchsmaterial zu ersetzen - sondern es zu erweitern. Die Tabelle zeigt, wo natives Verhalten endet und wo dieses Modul weitermacht:

Diagnose direkt in der Datenbank

Während Sie dieses Modul evaluieren - oder um zu prüfen, was GLPI nativ erfasst - können Sie Bestand und Abgänge direkt in den GLPI-Tabellen messen. Die beiden Abfragen, die wir verwenden:

-- Real balance per consumable, straight from GLPI's native tables.
-- Each glpi_consumables row is ONE physical unit: empty date_out = in stock,
-- filled date_out = already consumed. glpi_consumableitems is the consumable model.
SELECT ci.id                       AS consumable_id,
       ci.name                     AS consumable,
       SUM(c.date_out IS NULL)     AS in_stock,
       SUM(c.date_out IS NOT NULL) AS consumed,
       COUNT(c.id)                 AS total_registered
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 in_stock ASC;

-- Exits already linked to tickets: when debiting, the module writes itemtype='Ticket'
-- and items_id = the ticket number on the native row itself.
-- On a GLPI without the module this filter returns nothing (native exit goes to User/Group).
SELECT c.items_id      AS ticket,
       ci.name         AS consumable,
       COUNT(*)        AS units_taken,
       MAX(c.date_out) AS last_exit
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 last_exit DESC;

Die Erfahrung aus dem Betrieb

Beim Betrieb von Service Desks für Kunden war die Rückverfolgbarkeit pro Ticket immer genau die fehlende Information - GLPI sagte „diesen Monat wurden 20 Toner entnommen“, aber nicht „welche Tickets sie verbraucht haben“. Ohne diese Verknüpfung wurde die Verbrauchsprüfung pro Zeitraum nach Gefühl rekonstruiert. Zwei Fehler wiederholen sich in der Praxis. Der erste ist die manuelle Abbuchung im Material ohne Angabe des Tickets: Der Techniker gibt den Artikel über den nativen Ablauf aus, der Bestand stimmt zwar, aber die Bearbeitung bleibt ohne Kosten und der Bericht lückenhaft. Der zweite ist unauffälliger - dieses Modul einzuführen und zu vergessen, „Ticket verpflichtend“ einzuschalten: Wochenlang existieren Abgänge nebeneinander, manche verknüpft, andere nicht, und erst wenn jemand den Bericht anfordert, zeigt sich die Lücke. Ein Detail, welches nur kennt, wer im Betrieb steht: Dieses Modul erfindet keine parallele Lagertabelle, es schreibt in dieselbe glpi_consumables - deshalb konkurrieren die Abbuchung über das Ticket und die Abbuchung über die native Oberfläche um denselben Bestand. Alles einheitlich über Tickets abzuwickeln, mit eingeschalteter Pflicht vom ersten Tag an, verhindert, dass die beiden Zahlen auseinanderlaufen.

Für wen es sich eignet (und wann NICHT)

Stock Management ist sinnvoll für Support- und Infrastrukturteams, die bei der Bearbeitung physisches Material verbrauchen - Toner, Kabel, Ersatzteile, Speichermodule - und jeden Verbrauch mit dem Ticket verknüpfen müssen, das ihn ausgelöst hat. Und für Führungskräfte, die die Materialkosten pro Bearbeitung sehen möchten, ohne Tabellen aus zwei Systemen zu exportieren.

Es lohnt sich nicht, wenn Sie die nativen Verbrauchsmaterialien von GLPI nicht nutzen - dieses Modul baut auf ihnen auf, ersetzt sie nicht - oder wenn die Lagerkontrolle Ihres Betriebs in einem externen ERP liegt, welches weiterhin die maßgebliche Quelle bleibt. In diesen Fällen ist die richtige Integration die mit dem ERP, nicht eine zweite Lagerbuchhaltung innerhalb von GLPI.

Kompatibilität

• GLPI: 10.0+ und 11.0+.
• Verfügbarkeit: auf Anfrage.
• Plugin: NexTool 3.x oder höher.

Stock Management ist Teil von NexTool, dem Modul-Ökosystem, das GLPI ohne Code-Anpassungen erweitert. Um die Abbuchung pro Ticket in Ihrer Umgebung in Aktion zu sehen, sprechen Sie mit dem Team.

Geprüft vom Team der NexTool Solutions.