The GLPI Agent hands you hundreds of assets in days - and not one of them with a purchase value, warranty or supplier. Automatic inventory fills in the hardware; the financial lifecycle - acquisition, depreciation, warranty alert and disposal - is a separate layer, it lives on the Management tab and in the glpi_infocoms table, and that is exactly where almost every asset management project stalls halfway. This guide maps the five phases to the real GLPI objects, shows the cron that actually fires the alerts, and the query we run in support to find the assets that are blind to depreciation.
What automatic inventory does not fill in
The first disappointment in almost every project is the same: the customer installs the GLPI Agent, watches 400 machines appear with CPU, RAM, disk and serial number, and concludes that "asset management is done". It is not. The agent collects what the operating system knows about itself - and the OS does not know how much the machine cost, who it was bought from, when the warranty expires or which cost center it belongs to. All of that data lives in the Infocom (the asset's Management tab, table glpi_infocoms) and is manual entry or import. No version of the agent fills it in, and that is the number one confusion we find in inherited environments: a beautiful inventory, an empty financial lifecycle. Without Infocom there is no depreciation, no warranty alert and no total cost - the lifecycle simply does not exist beneath the surface.
The five phases mapped to GLPI objects
Before configuring anything, it is worth knowing where each phase actually lives in GLPI. There is no "lifecycle" module; there are fields, statuses and tables that together form the cycle. This is the map we use as a rollout checklist:
| Phase | Where it lives in GLPI | Table | Filled by |
|---|---|---|---|
| Acquisition | Management tab: supplier, invoice, value, warranty | glpi_infocoms | Manual or CSV import |
| Deployment | Status + Location + User/Group | glpi_states, glpi_locations | Agent (specs) + manual (status/location) |
| Operation | Tickets linked to the asset | glpi_items_tickets | Automatic, when the ticket is opened |
| Depreciation | Management tab: type, duration, coefficient | glpi_infocoms (sink_type, sink_time) | Calculated automatically by GLPI |
| Disposal | "Disposed" status + attached document | glpi_states, glpi_documents_items | Manual |
Notice that only two rows are automatic: the hardware specs and the asset-ticket link. Everything else - what gives the asset its financial meaning - is human decision and discipline. That is why asset management fails on process, not on tooling.
Acquisition: the Infocom is the heart of the cycle
The acquisition phase comes down to filling in the Infocom properly. The fields that matter, and that hold up the rest of the cycle:
- Supplier, invoice number and purchase date - traceability and the basis for a warranty claim.
- Value - the depreciation base; without it the residual value never comes out.
- Warranty duration - in months; use
-1for a lifetime warranty. The alert fires counting from this date. - Budget - links the asset to a cost center for reporting by line item.
Filling this in by hand across 400 assets is unworkable, so during rollout we import the Infocom together with the fleet, from the purchase spreadsheet CSV, matching on the serial number. The common mistake here is leaving the value blank "to fill in later": later never comes, and depreciation is dead on arrival.
Status: a lean state machine
The asset status (field states_id, table glpi_states) is what moves the asset through the cycle: In use, In stock, Under repair, Disposed. Status is fully configurable under Setup > Dropdowns > Status, and that is where the second field trap lives: status explosion. We have seen environments with thirty statuses ("In use - HQ", "In use - branch 2", "In use - laptop"...) that in practice mix status with location and type, and break every report by state. Status is a state machine, not a taxonomy: keep half a dozen, cutting across every asset type.
Two support-side details about status and the agent. First: in the native inventory configuration you set the default status of newly discovered assets - point it at "In stock" so a new machine does not come in already as "In use". Second: inventoried assets are dynamic (is_dynamic = 1); if you delete an asset the agent still sees, it comes back on the next cycle. To remove it for real, uninstall the agent from the machine or lock the item, never just delete it in the interface.
Depreciation: straight-line or declining
With value and purchase date in the Infocom, GLPI calculates the residual value on its own. You choose the method on the asset itself:
| Type (sink_type) | How it depreciates | When to use |
|---|---|---|
| Straight-line | Fixed amount per year over the useful life (sink_time) | Accounting default for most IT assets |
| Declining balance | Larger amount up front, via a coefficient (sink_coeff) | When tax policy requires accelerating the loss of value |
The duration (sink_time) is in years - typically 3 to 5 for computers, depending on your policy. You can set a global default so you do not type it on every asset, but real useful life varies by equipment class; a server does not depreciate like a laptop. Leave the default for the common case and adjust the exceptions.
The alerts depend on the right cron
Warranty expiry and contract end only become notifications if the infocom automatic action runs. And here is the trap that most often produces "GLPI did not warn me": the cron in GLPI mode (internal) is triggered by page visits. On a low-traffic instance - typical of asset management, where only the IT team logs in - the automatic actions lag or never run, and the warranty alert never goes out. The fix is to take the cron out of internal mode and anchor it to the operating system:
# /etc/cron.d/glpi - triggers GLPI automatic actions every 5 min.
# Among them the "infocom" action: warranty expiry and contract end alerts.
*/5 * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1Then, under Setup > Automatic actions > infocom, switch the run mode to CLI/external. Without this, the rest of the warranty cycle is decorative.
Diagnostic SQL: the assets blind to depreciation
When a support contract starts, before discussing process, we measure the Infocom gap: how many computers exist in the inventory but have no financial information at all. These are the assets invisible to depreciation, total cost and warranty alert. We run it straight against the database, on a read-only client, to get the exact number:
-- Computers WITHOUT financial information (infocom):
-- inventoried by the agent, but invisible to depreciation and warranty alerts.
SELECT c.id, c.name, c.serial
FROM glpi_computers c
LEFT JOIN glpi_infocoms i
ON i.itemtype = 'Computer' AND i.items_id = c.id
WHERE c.is_deleted = 0
AND c.is_template = 0
AND i.id IS NULL
ORDER BY c.name;The same pattern works for monitors, printers and network items - swap the table and the itemtype. The number that comes out is the real size of the financial-registration work, and it is usually a healthy shock for whoever thought the fleet was "all registered".
Disposal with a GDPR trail
End of life is not just changing the status to "Disposed". Equipment with data (laptop, server, storage) leaves the company with personal information inside, and disposal needs an auditable trail for data protection. In GLPI: change the status, record the end-of-use date in the Infocom, and attach the proof of destination (disk destruction certificate, donation form, e-waste recycling manifest) as a document on the asset. That way, when the DPO asks "prove the disk of the departed employee's laptop was destroyed", the answer is on the asset itself, not in someone's memory. Do not delete the disposed asset: it is the evidence. Just take it out of the operational reports by filtering on the status.
Need to turn an automatic inventory into an asset lifecycle that genuinely supports depreciation, warranty alerts and a disposal trail? Discover NexTool's GLPI support and maintenance service.
Reviewed by the NexTool Solutions team.
