Gestão de Orçamentos e Contratos com GLPI

Passo a passo de contratos, orçamentos, fornecedores e depreciação no GLPI: como registar, fazer os alertas de vencimento dispararem mesmo (cron + glpi_alerts), diagnosticar contratos a vencer por SQL e escolher o método de depreciação correto.

Neste artigo8 secções

Gerir TI sem controlo financeiro é navegar sem bússola. O GLPI traz módulos nativos para contratos, orçamentos, fornecedores e depreciação, todos integrados com os ativos e os pedidos. Na prática, porém, o que falha não é o registo: é fazer os alertas dispararem e as contas fecharem.

Contratos: o que registar (e o que costuma faltar)

Em Gestão > Contratos, cada contrato deve conter:

  • Identificação: número, tipo (suporte, manutenção, aluguer, licença) e fornecedor associado.
  • Vigência: data de início e duração em meses. O GLPI não guarda a data de fim; ela é calculada a partir do início mais a duração.
  • Pré-aviso (notice): em meses. É a antecedência com que o alerta de renovação deve chegar.
  • Renovação: nunca, tácita ou expressa.
  • Custos: no separador de custos, com periodicidade (mensal, anual) para o consumo bater certo com o orçamento.
  • Ativos cobertos: associe computadores, servidores e demais itens para saber o que fica sem cobertura no vencimento.

A armadilha clássica: registar o contrato com duração 0 (indeterminado). Sem duração não há data de fim calculável, e o alerta de vencimento simplesmente nunca dispara.

Fazer os alertas dispararem mesmo

Três camadas têm de estar ligadas ao mesmo tempo, ou não sai qualquer e-mail:

  1. Notificações globais ativas em Configuração > Notificações, com um destinatário real configurado.
  2. Alerta ativado no próprio contrato (fim de contrato e/ou pré-aviso). O valor por omissão vem da chave default_contract_alert.
  3. Ação automática a correr. A tarefa contract só envia se o cron do GLPI estiver a ser chamado de facto.

Em ambientes de cliente, a falha número um é o cron parado. Garanta que o GLPI é despoletado pelo sistema operativo, e não apenas quando alguém abre a interface:

# /etc/cron.d/glpi - dispara as ações automáticas do GLPI a cada minuto
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Depois, em Configuração > Ações automáticas, abra a tarefa contract e verifique: modo CLI/externo, frequência (diária por omissão) e a data da última execução. Se o modo estiver como "GLPI" (interno), a tarefa depende de alguém a navegar no sistema à hora certa, o que é frágil.

O alerta configurado que não reenvia

Este é o detalhe que só aparece na operação diária: o GLPI grava em glpi_alerts cada notificação já enviada, para não duplicar. Se o e-mail falhou (SMTP errado, caixa cheia) mas o registo foi gravado, o GLPI considera "já avisei" e não reenvia, mesmo depois de corrigir o SMTP. Para forçar o reenvio de um contrato específico, limpe o marcador do alerta:

-- Descobrir o id do contrato pelo nome
SELECT id, name FROM glpi_contracts WHERE name LIKE '%Suporte Datacenter%';

-- Remover o marcador de alerta já enviado (ex.: contrato 42)
DELETE FROM glpi_alerts
WHERE itemtype = 'Contract' AND items_id = 42;

Na execução seguinte do cron, a tarefa contract reavalia o vencimento e reenvia. O mesmo se aplica às garantias, trocando por itemtype = 'Infocom'.

Diagnóstico rápido: contratos a vencer

Antes de confiar no painel, um SELECT direto confirma o que está mesmo a vencer nos próximos 90 dias, com fornecedor e dias restantes:

SELECT c.id,
       c.name                                            AS contrato,
       s.name                                            AS fornecedor,
       c.begin_date,
       DATE_ADD(c.begin_date, INTERVAL c.duration MONTH) AS fim,
       DATEDIFF(DATE_ADD(c.begin_date, INTERVAL c.duration MONTH),
                CURDATE())                               AS dias_restantes
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 fim ASC;

Corra como consulta só de leitura. É o mesmo cálculo que a interface faz, útil para auditar antes de uma renovação em lote.

Orçamentos ligados a contratos e compras

Em Gestão > Orçamentos, defina o valor, o período (anual, semestral ou por projeto) e o tipo. O ponto que muita gente ignora: o orçamento no GLPI é uma referência de acompanhamento, não um bloqueio. Não impede lançamentos acima do teto; mostra planeado versus consumido quando associa os custos dos contratos e as informações financeiras dos ativos (Infocom) a esse orçamento. Sem essa associação, o consumo fica a zero e o relatório engana.

Depreciação de ativos

Cada ativo tem o separador Gestão (Infocom) com valor de compra, data de aquisição, garantia e depreciação. O GLPI calcula o valor contabilístico automaticamente a partir do tipo e do prazo. Escolher o método certo evita distorção no TCO:

CenárioTipo (sink_type)Prazo típico (anos)Nota
Portáteis e computadores de secretáriaLinear4 a 5Perda constante; simples de auditar.
Servidores e armazenamentoLinear5 a 7Acompanhe a garantia alargada em paralelo.
Equipamento com perda acelerada no inícioDegressivo3 a 5Exige um coeficiente (sink_coeff) coerente.
Licença ou ativo sem valor residual relevanteLinear1 a 3Alinhe o prazo à vigência do contrato.

Defina os valores por omissão em Configuração > Geral > separador Ativos para não preencher item a item. O erro comum aqui é deixar a data de início de utilização em branco: sem ela o GLPI não sabe a partir de quando depreciar, e o valor contabilístico fica igual ao de compra para sempre.

Relatórios e custo por pedido

  • Ativos por valor: quanto está investido por localização ou entidade.
  • Contratos a vencer: a mesma lista do SELECT acima, agora no painel.
  • Depreciação: valor contabilístico do parque ao longo do tempo.
  • Custo por pedido: valor do contrato dividido pelo número de pedidos atendidos por esse fornecedor, ótimo para fundamentar uma renegociação.

Checklist de sustentação NexTool

Na sustentação de ambientes de clientes, antes de confiar na gestão financeira do GLPI validamos sempre a mesma sequência: cron a chamar front/cron.php pelo sistema operativo (não pelo navegador); tarefa contract em modo externo com última execução recente; notificações globais ativas e um destinatário real no alerta; contratos sem duration = 0 indevido; e uma varredura em glpi_alerts quando o cliente diz que "deixou de receber e-mail". Nove em cada dez casos de "o GLPI não avisa do vencimento" caem num destes cinco pontos, não num erro do produto.

Precisa de pôr contratos, orçamentos e alertas do GLPI a funcionar de ponta a ponta? A NexTool implementa e sustenta estes fluxos em ambientes de clientes B2B: conheça a sustentação NexTool.


Revisto pela equipa NexTool Solutions.

Perguntas Frequentes

É quase sempre uma de três causas: notificações globais desativadas, alerta não ativado no próprio contrato, ou a ação automática 'contract' que não corre porque o cron do sistema (front/cron.php) não está agendado. Confirme as três antes de suspeitar de um erro.

Não guarda. A data de fim é calculada a partir de begin_date mais duration (em meses). Por isso um contrato com duração 0 (indeterminado) nunca gera alerta de vencimento.

O GLPI regista cada alerta enviado em glpi_alerts para não duplicar. Apague a linha correspondente (itemtype igual a 'Contract' ou 'Infocom' e o items_id do objeto) e a execução seguinte do cron reavalia e reenvia.

A linear distribui a perda de valor em partes iguais ao longo do prazo (sink_time). A degressiva concentra a perda no início, com um coeficiente (sink_coeff). Para um parque de TI padrão, a linear é mais simples de auditar.

Não. O orçamento é uma referência de acompanhamento (planeado versus consumido), não um controlo de bloqueio. O consumo só aparece quando associa os custos dos contratos e as informações financeiras dos ativos ao orçamento.

Precisa de ajuda?