El GLPI Agent te entrega cientos de activos en días - y ninguno de ellos con valor de compra, garantía o proveedor. El inventario automático rellena el hardware; el ciclo de vida financiero - adquisición, depreciación, alerta de garantía y descarte - es otra capa, vive en la pestaña Gestión y en la tabla glpi_infocoms, y es exactamente donde casi todo proyecto de gestión de activos se queda a medias. Esta guía mapea las cinco fases a los objetos reales de GLPI, muestra el cron que hace que las alertas se disparen y la consulta que ejecutamos en soporte para encontrar los activos ciegos a la depreciación.
Lo que el inventario automático no rellena
La primera decepción de casi todo proyecto es la misma: el cliente instala el GLPI Agent, ve aparecer 400 máquinas con CPU, RAM, disco y número de serie, y concluye que "la gestión de activos está lista". No lo está. El agente recoge lo que el sistema operativo sabe de sí mismo - y el SO no sabe cuánto costó la máquina, a quién se compró, cuándo vence la garantía ni a qué centro de coste pertenece. Todos esos datos viven en el Infocom (pestaña Gestión del activo, tabla glpi_infocoms) y son entrada manual o importación. Ninguna versión del agente los rellena, y esa es la confusión número uno que encontramos en entornos heredados: un inventario precioso, un ciclo de vida financiero vacío. Sin Infocom no hay depreciación, no hay alerta de garantía y no hay coste total - el ciclo de vida simplemente no existe bajo la superficie.
Las cinco fases mapeadas a objetos de GLPI
Antes de configurar nada, conviene saber dónde vive realmente cada fase en GLPI. No existe un módulo "ciclo de vida"; existen campos, estados y tablas que, juntos, forman el ciclo. Este es el mapa que usamos como checklist de implantación:
| Fase | Dónde vive en GLPI | Tabla | Rellenado por |
|---|---|---|---|
| Adquisición | Pestaña Gestión: proveedor, factura, valor, garantía | glpi_infocoms | Manual o importación CSV |
| Despliegue | Estado + Ubicación + Usuario/Grupo | glpi_states, glpi_locations | Agente (specs) + manual (estado/ubicación) |
| Operación | Tickets vinculados al activo | glpi_items_tickets | Automático, al abrir el ticket |
| Depreciación | Pestaña Gestión: tipo, duración, coeficiente | glpi_infocoms (sink_type, sink_time) | Cálculo automático de GLPI |
| Descarte | Estado "Descartado" + documento adjunto | glpi_states, glpi_documents_items | Manual |
Fíjate en que solo dos filas son automáticas: los specs de hardware y el vínculo activo-ticket. Todo lo demás - lo que da sentido financiero al activo - es decisión y disciplina humana. Por eso la gestión de activos falla por proceso, no por herramienta.
Adquisición: el Infocom es el corazón del ciclo
La fase de adquisición se reduce a rellenar bien el Infocom. Los campos que importan, y que sostienen el resto del ciclo:
- Proveedor, número de factura y fecha de compra - trazabilidad y base para reclamar la garantía.
- Valor - base de cálculo de la depreciación; sin él el valor residual nunca sale.
- Duración de la garantía - en meses; usa
-1para garantía vitalicia. La alerta se dispara contando desde esta fecha. - Presupuesto (budget) - vincula el activo a un centro de coste para informes por partida.
Rellenar esto a mano en 400 activos es inviable, así que en la implantación importamos el Infocom junto con el parque, desde el CSV de la hoja de compra, casando por número de serie. El error común aquí es dejar el valor en blanco "para rellenar después": el después nunca llega, y la depreciación nace muerta.
Estado: una máquina de estados esbelta
El estado del activo (campo states_id, tabla glpi_states) es lo que mueve el activo por el ciclo: En uso, En stock, En reparación, Descartado. El estado es totalmente configurable en Configurar > Listas > Estados, y ahí vive la segunda trampa de campo: la explosión de estados. Hemos visto entornos con treinta estados ("En uso - sede", "En uso - sucursal 2", "En uso - portátil"...) que en la práctica mezclan estado con ubicación y tipo, y rompen todo informe por estado. El estado es una máquina de estados, no una taxonomía: mantén media docena, transversal a todo tipo de activo.
Dos detalles de soporte sobre el estado y el agente. Primero: en la configuración del inventario nativo defines el estado por defecto de los activos recién descubiertos - apúntalo a "En stock" para que una máquina nueva no entre ya como "En uso". Segundo: los activos inventariados son dinámicos (is_dynamic = 1); si borras un activo que el agente aún ve, resucita en el siguiente ciclo. Para quitarlo de verdad, desinstala el agente de la máquina o bloquea el ítem, nunca solo lo borres en la interfaz.
Depreciación: lineal o degresiva
Con valor y fecha de compra en el Infocom, GLPI calcula el valor residual por sí solo. Eliges el método en el propio activo:
| Tipo (sink_type) | Cómo deprecia | Cuándo usar |
|---|---|---|
| Lineal | Cuota fija por año a lo largo de la vida útil (sink_time) | Estándar contable de la mayoría de los activos de TI |
| Degresiva | Cuota mayor al inicio, vía coeficiente (sink_coeff) | Cuando la política fiscal exige acelerar la pérdida de valor |
La duración (sink_time) es en años - típicamente 3 a 5 para ordenadores, según tu política. Puedes definir un valor por defecto global para no teclearlo en cada activo, pero la vida útil real varía por clase de equipo; un servidor no se deprecia como un portátil. Deja el valor por defecto para el caso común y ajusta las excepciones.
Las alertas dependen del cron correcto
El vencimiento de garantía y el fin de contrato solo se convierten en notificación si la acción automática infocom se ejecuta. Y aquí está la trampa que más genera "GLPI no me avisó": el cron en modo GLPI (interno) se dispara por visita de página. En una instancia de bajo tráfico - típica de la gestión de activos, donde solo entra el equipo de TI - las acciones automáticas se retrasan o nunca se ejecutan, y la alerta de garantía nunca sale. La corrección es sacar el cron del modo interno y anclarlo al sistema operativo:
# /etc/cron.d/glpi - dispara las acciones automaticas de GLPI cada 5 min.
# Entre ellas la accion "infocom": alerta de vencimiento de garantia y fin de contrato.
*/5 * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1
Después, en Configurar > Acciones automáticas > infocom, cambia el modo de ejecución a CLI/externo. Sin esto, el resto del ciclo de garantía es decorativo.
SQL de diagnóstico: los activos ciegos a la depreciación
Al comenzar un contrato de soporte, antes de discutir proceso, medimos el agujero del Infocom: cuántos ordenadores existen en el inventario pero no tienen ninguna información financiera. Son los activos invisibles para la depreciación, el coste total y la alerta de garantía. Lo ejecutamos directo contra la base de datos, en cliente de solo lectura, para tener el número exacto:
-- Equipos SIN informacion financiera (infocom):
-- inventariados por el agente, pero invisibles para la depreciacion y las alertas de garantia.
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;
El mismo patrón vale para monitores, impresoras y equipos de red - cambia la tabla y el itemtype. El número que sale de aquí es el tamaño real del trabajo de registro financiero, y suele ser un choque saludable para quien creía tener el parque "todo registrado".
Descarte con rastro para la protección de datos
El fin de vida no es solo cambiar el estado a "Descartado". El equipo con datos (portátil, servidor, almacenamiento) sale de la empresa con información personal dentro, y el descarte necesita un rastro auditable para la normativa de protección de datos. En GLPI: cambia el estado, registra la fecha de fin de uso en el Infocom y adjunta el comprobante de destino (certificado de destrucción de disco, acta de donación, manifiesto de reciclaje electrónico) como documento del activo. Así, cuando el responsable de datos pregunte "demuestra que el disco del portátil del empleado que se fue fue destruido", la respuesta está en el propio activo, no en la memoria de alguien. No borres el activo descartado: es la prueba. Solo sácalo de los informes operativos filtrando por el estado.
¿Necesitas convertir un inventario automático en un ciclo de vida de activos que realmente sostenga depreciación, alertas de garantía y rastro de descarte? Conoce el servicio de soporte y mantenimiento de GLPI de NexTool.
Revisado por el equipo de NexTool Solutions.