Budget- und Vertragsverwaltung mit GLPI

Schritt für Schritt zu Verträgen, Budgets, Lieferanten und Abschreibung im GLPI: wie Sie sie erfassen, Ablaufwarnungen zuverlässig auslösen (Cron + glpi_alerts), auslaufende Verträge per SQL diagnostizieren und die richtige Abschreibungsmethode wählen.

In diesem Artikel8 Abschnitte

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:

  1. Globale Benachrichtigungen aktiviert unter Einrichtung > Benachrichtigungen, mit einem echten Empfänger, der sie erhält.
  2. Warnung im Vertrag selbst aktiviert (Vertragsende und/oder Kündigungsfrist). Der Standardwert kommt aus dem Schlüssel default_contract_alert.
  3. Automatische Aktion läuft. Die Aufgabe contract sendet 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:

SzenarioTyp (sink_type)Typische Laufzeit (Jahre)Hinweis
Notebooks und DesktopsLinear4 bis 5Konstanter Wertverlust; einfach zu prüfen.
Server und StorageLinear5 bis 7Verfolgen Sie die erweiterte Garantie mit.
Geräte mit anfangs beschleunigtem WertverlustDegressiv3 bis 5Erfordert einen stimmigen Koeffizienten (sink_coeff).
Lizenz oder Asset ohne nennenswerten RestwertLinear1 bis 3Richten 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.

Häufig gestellte Fragen

Fast immer liegt es an einer von drei Ursachen: globale Benachrichtigungen deaktiviert, Warnung im Vertrag selbst nicht aktiviert oder die automatische Aktion „contract“ läuft nicht, weil der System-Cron (front/cron.php) nicht eingeplant ist. Prüfen Sie alle drei, bevor Sie einen Fehler vermuten.

Gar nicht. Das Enddatum wird aus begin_date plus duration (in Monaten) berechnet. Deshalb erzeugt ein Vertrag mit Dauer 0 (unbefristet) nie eine Ablaufwarnung.

GLPI erfasst jede gesendete Warnung in glpi_alerts, um Duplikate zu vermeiden. Löschen Sie die entsprechende Zeile (itemtype gleich „Contract“ oder „Infocom“ und items_id des Objekts), und die nächste Cron-Ausführung bewertet neu und sendet erneut.

Linear verteilt den Wertverlust in gleichen Teilen über die Laufzeit (sink_time). Degressiv konzentriert den Wertverlust am Anfang und verwendet einen Koeffizienten (sink_coeff). Für einen üblichen IT-Bestand ist linear einfacher zu prüfen.

Nein. Ein Budget ist eine Referenz zur Nachverfolgung (Plan gegenüber Verbrauch), keine Sperre. Der Verbrauch erscheint erst, wenn Sie die Kosten der Verträge und die Finanzinformationen der Assets mit dem Budget verknüpfen.

Brauchen Sie Hilfe?