IT-Management ohne Finanzkontrolle ist wie Navigieren ohne Kompass. GLPI bringt native Module für Verträge, Budgets, Lieferanten und Abschreibung mit, alle mit Assets und Tickets verknüpft. In der Praxis scheitert es aber nicht an der Erfassung, sondern daran, dass Warnungen ausgelöst werden und die Zahlen aufgehen.
Verträge: was Sie erfassen sollten (und was oft fehlt)
Unter Verwaltung > Verträge sollte jeder Vertrag Folgendes enthalten:
- Identifikation: Nummer, Typ (Support, Wartung, Miete, Lizenz) und verknüpfter Lieferant.
- Laufzeit: Startdatum und Dauer in Monaten. GLPI speichert kein Enddatum; es wird aus Start plus Dauer berechnet.
- Kündigungsfrist (notice): in Monaten. Sie bestimmt, wie früh die Verlängerungswarnung eintreffen soll.
- Verlängerung: nie, stillschweigend oder ausdrücklich.
- Kosten: in der Registerkarte Kosten, mit Periodizität (monatlich, jährlich), damit der Verbrauch zum Budget passt.
- Abgedeckte Assets: Verknüpfen Sie Computer, Server und weitere Elemente, um zu wissen, was bei Ablauf ohne Abdeckung bleibt.
Die klassische Falle: einen Vertrag mit Dauer 0 (unbefristet) anzulegen. Ohne Dauer lässt sich kein Enddatum berechnen, und die Ablaufwarnung wird schlicht nie ausgelöst.
So werden die Warnungen wirklich ausgelöst
Drei Ebenen müssen gleichzeitig aktiv sein, sonst geht keine E-Mail raus:
- Globale Benachrichtigungen aktiviert unter Einrichtung > Benachrichtigungen, mit einem echten Empfänger, der sie erhält.
- Warnung im Vertrag selbst aktiviert (Vertragsende und/oder Kündigungsfrist). Der Standardwert kommt aus dem Schlüssel
default_contract_alert. - Automatische Aktion läuft. Die Aufgabe
contractsendet nur, wenn der GLPI-Cron tatsächlich aufgerufen wird.
In Kundenumgebungen ist ein gestoppter Cron die Fehlerursache Nummer eins. Stellen Sie sicher, dass GLPI vom Betriebssystem angestoßen wird und nicht nur, wenn jemand die Oberfläche aufruft:
# /etc/cron.d/glpi - triggers GLPI automatic actions every minute
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1
Öffnen Sie danach unter Einrichtung > Automatische Aktionen die Aufgabe contract und prüfen Sie: Modus CLI/extern, Häufigkeit (standardmäßig täglich) und Datum der letzten Ausführung. Steht der Modus auf „GLPI“ (intern), hängt die Aufgabe davon ab, dass zur richtigen Zeit jemand im System navigiert, und eine solche Lösung ist fragil.
Die konfigurierte Warnung, die nicht erneut sendet
Dieses Detail zeigt sich erst im Betrieb: GLPI speichert in glpi_alerts jede bereits gesendete Benachrichtigung, um Duplikate zu vermeiden. Ist die E-Mail fehlgeschlagen (falscher SMTP, volles Postfach), wurde der Eintrag aber gespeichert, geht GLPI von „schon benachrichtigt“ aus und sendet nicht erneut, selbst nachdem Sie SMTP korrigiert haben. Um den erneuten Versand für einen bestimmten Vertrag zu erzwingen, löschen Sie die Markierung der Warnung:
-- Find the contract id by name
SELECT id, name FROM glpi_contracts WHERE name LIKE '%Datacenter Support%';
-- Remove the already-sent alert marker (e.g. contract 42)
DELETE FROM glpi_alerts
WHERE itemtype = 'Contract' AND items_id = 42;
Bei der nächsten Cron-Ausführung bewertet die Aufgabe contract den Ablauf neu und sendet erneut. Für Garantien gilt dasselbe, mit itemtype = 'Infocom'.
Schnelldiagnose: auslaufende Verträge
Bevor Sie dem Dashboard vertrauen, bestätigt ein direktes SELECT in der Datenbank, was in den nächsten 90 Tagen tatsächlich ausläuft, mit Lieferant und verbleibenden Tagen:
SELECT c.id,
c.name AS contract,
s.name AS supplier,
c.begin_date,
DATE_ADD(c.begin_date, INTERVAL c.duration MONTH) AS end_date,
DATEDIFF(DATE_ADD(c.begin_date, INTERVAL c.duration MONTH),
CURDATE()) AS days_left
FROM glpi_contracts c
LEFT JOIN glpi_contracts_suppliers cs ON cs.contracts_id = c.id
LEFT JOIN glpi_suppliers s ON s.id = cs.suppliers_id
WHERE c.is_deleted = 0
AND c.is_template = 0
AND c.duration > 0
AND DATE_ADD(c.begin_date, INTERVAL c.duration MONTH)
BETWEEN CURDATE() AND DATE_ADD(CURDATE(), INTERVAL 90 DAY)
ORDER BY end_date ASC;
Führen Sie sie als reine Leseabfrage aus. Es ist dieselbe Berechnung wie in der Oberfläche, nützlich für ein Audit vor einer Sammelverlängerung.
Budgets, verknüpft mit Verträgen und Einkäufen
Legen Sie unter Verwaltung > Budgets Betrag, Zeitraum (jährlich, halbjährlich oder pro Projekt) und Typ fest. Ein Punkt, den viele übersehen: Ein Budget im GLPI ist eine Referenz zur Nachverfolgung, keine Sperre. Es verhindert keine Buchungen über der Obergrenze; es zeigt Plan gegenüber Verbrauch, wenn Sie die Kosten der Verträge und die Finanzinformationen der Assets (Infocom) mit diesem Budget verknüpfen. Ohne diese Verknüpfung bleibt der Verbrauch bei null, und der Bericht täuscht.
Abschreibung von Assets
Jedes Asset hat die Registerkarte Verwaltung (Infocom) mit Kaufpreis, Anschaffungsdatum, Garantie und Abschreibung. GLPI berechnet den Buchwert automatisch aus Typ und Laufzeit. Die richtige Methode vermeidet Verzerrungen bei den TCO:
| Szenario | Typ (sink_type) | Typische Laufzeit (Jahre) | Hinweis |
|---|---|---|---|
| Notebooks und Desktops | Linear | 4 bis 5 | Konstanter Wertverlust; einfach zu prüfen. |
| Server und Storage | Linear | 5 bis 7 | Verfolgen Sie die erweiterte Garantie mit. |
| Geräte mit anfangs beschleunigtem Wertverlust | Degressiv | 3 bis 5 | Erfordert einen stimmigen Koeffizienten (sink_coeff). |
| Lizenz oder Asset ohne nennenswerten Restwert | Linear | 1 bis 3 | Richten Sie die Laufzeit an der Vertragslaufzeit aus. |
Legen Sie die Standardwerte unter Einrichtung > Allgemein > Registerkarte Assets fest, um nicht jedes Element einzeln auszufüllen. Der häufige Fehler hier ist, ein Datum der Inbetriebnahme leer zu lassen: Ohne dieses Datum weiß GLPI nicht, ab wann abgeschrieben wird, und der Buchwert bleibt für immer gleich dem Kaufpreis.
Berichte und Kosten pro Ticket
- Assets nach Wert: wie viel pro Standort oder Einheit investiert ist.
- Auslaufende Verträge: dieselbe Liste wie im SELECT oben, jetzt im Dashboard.
- Abschreibung: Buchwert des Bestands im Zeitverlauf.
- Kosten pro Ticket: Vertragswert geteilt durch die Zahl der von diesem Lieferanten bearbeiteten Tickets, ideal als Grundlage für Nachverhandlungen.
NexTool-Checkliste für den Betrieb
Im Betrieb von Kundenumgebungen prüfen wir, bevor wir uns auf die Finanzverwaltung von GLPI verlassen, immer dieselbe Abfolge: Cron ruft front/cron.php über das Betriebssystem auf (nicht über den Browser); Aufgabe contract im externen Modus mit kürzlicher letzter Ausführung; globale Benachrichtigungen aktiv und ein echter Empfänger in der Warnung; Verträge ohne unzulässiges duration = 0; und eine Durchsicht von glpi_alerts, wenn der Kunde sagt, er „bekomme keine E-Mails mehr“. Neun von zehn Fällen von „GLPI warnt nicht vor dem Ablauf“ gehen auf einen dieser fünf Punkte zurück, nicht auf einen Fehler im Produkt.
Sie möchten Verträge, Budgets und Warnungen in GLPI durchgängig zum Laufen bringen? NexTool führt diese Abläufe in Umgebungen von B2B-Kunden ein und betreut sie: Lernen Sie den Betriebsservice von NexTool kennen.
Geprüft vom Team von NexTool Solutions.