O GLPI Agent entrega centenas de ativos em poucos dias - e nenhum deles com valor de compra, garantia ou fornecedor. O inventário automático preenche o hardware; o ciclo de vida financeiro - aquisição, depreciação, alerta de garantia e abate - é outra camada, vive no separador Gestão e na tabela glpi_infocoms, e é exatamente onde quase todo o projeto de gestão de ativos fica a meio. Este guia mapeia as cinco fases para os objetos reais do GLPI, mostra o cron que faz os alertas dispararem e a consulta que executamos na sustentação para encontrar os ativos cegos à depreciação.
O que o inventário automático não preenche
A primeira deceção de quase todo o projeto é a mesma: o cliente instala o GLPI Agent, vê 400 máquinas surgirem com CPU, RAM, disco e número de série, e conclui que "a gestão de ativos está pronta". Não está. O agente recolhe o que o sistema operativo sabe sobre si mesmo - e o SO não sabe quanto a máquina custou, a quem foi comprada, quando termina a garantia nem qual o centro de custo. Todos estes dados vivem no Infocom (separador Gestão do ativo, tabela glpi_infocoms) e são introdução manual ou importação. Nenhuma versão do agente os preenche, e essa é a confusão número um que encontramos em ambientes herdados: um inventário lindo, um ciclo de vida financeiro vazio. Sem Infocom não há depreciação, não há alerta de garantia e não há custo total - o ciclo de vida simplesmente não existe por baixo da superfície.
As cinco fases mapeadas para objetos do GLPI
Antes de configurar seja o que for, convém saber onde cada fase vive realmente no GLPI. Não existe um módulo "ciclo de vida"; existem campos, estados e tabelas que, juntos, formam o ciclo. Este é o mapa que usamos como checklist de implementação:
| Fase | Onde vive no GLPI | Tabela | Preenchido por |
|---|---|---|---|
| Aquisição | Separador Gestão: fornecedor, fatura, valor, garantia | glpi_infocoms | Manual ou importação CSV |
| Implementação | Estado + Localização + Utilizador/Grupo | glpi_states, glpi_locations | Agente (specs) + manual (estado/localização) |
| Operação | Tickets associados ao ativo | glpi_items_tickets | Automático, na abertura do ticket |
| Depreciação | Separador Gestão: tipo, duração, coeficiente | glpi_infocoms (sink_type, sink_time) | Cálculo automático do GLPI |
| Abate | Estado "Abatido" + documento anexo | glpi_states, glpi_documents_items | Manual |
Repare que só duas linhas são automáticas: as specs de hardware e a ligação ativo-ticket. Todo o resto - o que dá sentido financeiro ao ativo - é decisão e disciplina humana. É por isso que a gestão de ativos falha por processo, não por ferramenta.
Aquisição: o Infocom é o coração do ciclo
A fase de aquisição resume-se a preencher bem o Infocom. Os campos que importam, e que sustentam todo o resto do ciclo:
- Fornecedor, número da fatura e data de compra - rastreabilidade e base para acionar a garantia.
- Valor - base de cálculo da depreciação; sem ele o valor residual nunca sai.
- Duração da garantia - em meses; use
-1para garantia vitalícia. O alerta dispara a contar desta data. - Orçamento (budget) - liga o ativo a um centro de custo para relatórios por rubrica.
Preencher isto à mão em 400 ativos é inviável, por isso na implementação importamos o Infocom juntamente com o parque, a partir do CSV da folha de compra, cruzando pelo número de série. O erro comum aqui é deixar o valor em branco "para preencher depois": o depois nunca chega, e a depreciação nasce morta.
Estado: uma máquina de estados enxuta
O estado do ativo (campo states_id, tabela glpi_states) é o que move o ativo pelo ciclo: Em uso, Em stock, Em reparação, Abatido. O estado é totalmente configurável em Configurar > Listas > Estados, e é aí que vive a segunda armadilha de terreno: a explosão de estados. Vimos ambientes com trinta estados ("Em uso - sede", "Em uso - filial 2", "Em uso - portátil"...) que na prática misturam estado com localização e tipo, e quebram todo o relatório por estado. Estado é máquina de estados, não taxonomia: mantenha meia dúzia, transversal a todo o tipo de ativo.
Dois detalhes de sustentação sobre estado e o agente. Primeiro: na configuração do inventário nativo define o estado predefinido dos ativos recém-descobertos - aponte-o para "Em stock" para que uma máquina nova não entre já como "Em uso". Segundo: os ativos inventariados são dinâmicos (is_dynamic = 1); se apagar um ativo que o agente ainda vê, ele ressuscita no ciclo seguinte. Para o retirar a sério, desinstale o agente da máquina ou bloqueie o item, nunca o apague apenas na interface.
Depreciação: linear ou degressiva
Com valor e data de compra no Infocom, o GLPI calcula o valor residual sozinho. Escolhe o método no próprio ativo:
| Tipo (sink_type) | Como deprecia | Quando usar |
|---|---|---|
| Linear | Quota fixa por ano ao longo da vida útil (sink_time) | Padrão contabilístico da maioria dos ativos de TI |
| Degressiva | Quota maior no início, via coeficiente (sink_coeff) | Quando a política fiscal exige acelerar a perda de valor |
A duração (sink_time) é em anos - tipicamente 3 a 5 para computadores, conforme a sua política. Pode definir um valor predefinido global para não digitar em cada ativo, mas a vida útil real varia por classe de equipamento; um servidor não deprecia como um portátil. Deixe o predefinido para o caso comum e ajuste as exceções.
Os alertas dependem do cron certo
O fim de garantia e o fim de contrato só se tornam notificação se a ação automática infocom for executada. E aqui está a armadilha que mais gera "o GLPI não me avisou": o cron em modo GLPI (interno) é disparado por visita de página. Numa instância de baixo tráfego - típica da gestão de ativos, onde só a equipa de TI entra - as ações automáticas atrasam ou nunca são executadas, e o alerta de garantia nunca sai. A correção é tirar o cron do modo interno e ancorá-lo no sistema operativo:
# /etc/cron.d/glpi - dispara as acoes automaticas do GLPI a cada 5 min.
# Entre elas a acao "infocom": alerta de fim de garantia e fim de contrato.
*/5 * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1Depois, em Configurar > Ações automáticas > infocom, mude o modo de execução para CLI/externo. Sem isto, todo o resto do ciclo de garantia é decorativo.
SQL de diagnóstico: os ativos cegos à depreciação
À entrada de um contrato de sustentação, antes de discutir processo, medimos o buraco do Infocom: quantos computadores existem no inventário mas não têm qualquer informação financeira. São os ativos invisíveis para depreciação, custo total e alerta de garantia. Executamos diretamente na base de dados, em cliente só de leitura, para ter o número exato:
-- Computadores SEM informacao financeira (infocom):
-- inventariados pelo agente, mas invisiveis para a depreciacao e 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;O mesmo padrão vale para monitores, impressoras e itens de rede - troque a tabela e o itemtype. O número que sai daqui é o tamanho real do trabalho de registo financeiro, e costuma ser um choque saudável para quem julgava o parque "todo registado".
Abate com trilho para o RGPD
O fim de vida não é só mudar o estado para "Abatido". Equipamento com dados (portátil, servidor, armazenamento) sai da empresa com informação pessoal lá dentro, e o abate precisa de um trilho auditável para o RGPD. No GLPI: mude o estado, registe a data de fim de utilização no Infocom e anexe o comprovativo de destino (certificado de destruição de disco, termo de doação, manifesto de reciclagem eletrónica) como documento do ativo. Assim, quando o DPO perguntar "prove que o disco do portátil do colaborador que saiu foi destruído", a resposta está no próprio ativo, não na memória de alguém. Não apague o ativo abatido: ele é a prova. Só o retire dos relatórios operacionais filtrando pelo estado.
Precisa de transformar um inventário automático num ciclo de vida de ativos que sustente mesmo depreciação, alertas de garantia e trilho de abate? Conheça o serviço de suporte e sustentação de GLPI da NexTool.
Revisto pela equipa NexTool Solutions.
