ActualTime vs Contract Hours: Controlo de Tempo no GLPI

O ActualTime mede o tempo real do técnico; o Contract Hours controla o saldo do contrato e fatura. Comparativo dos dois plugins de tempo no GLPI, o compromisso do actiontime partilhado, veredito por cenário e como medir o desvio de arredondamento.

Neste artigo8 secções

Medir o tempo de um ticket e faturar esse tempo são dois problemas diferentes. Um é sobre a produtividade da equipa: quanto tempo real o técnico gastou. O outro é sobre o contrato: quantas horas o cliente já consumiu e quantas ainda tem. Confundir os dois é o erro que mais vemos na sustentação - e a escolha entre ActualTime e Contract Hours começa exatamente aí.

O problema: três planos de "tempo" no GLPI

Antes de escolher plugin, vale a pena separar três coisas que o GLPI trata de formas diferentes:

  • Tempo estimado - a duração que planeou para a tarefa.
  • Tempo real - quanto o técnico de facto demorou, cronometrado.
  • Tempo faturável - o que entra na conta do contrato, já arredondado e com regras comerciais.

O campo nativo Duração da tarefa (guardado em segundos no actiontime) resolve o básico, mas exige introdução manual e não sabe nada sobre o contrato. É aí que entram os dois plugins.

ActualTime (TICGAL)

O ActualTime é um plugin gratuito e de código aberto da TICGAL. Adiciona botões de play, pausa e stop na tarefa do ticket e cronometra o tempo real que o técnico passa nela. Ao parar, grava esse tempo medido na duração da tarefa. O foco é honesto e estreito: transformar "acho que demorei uns 40 minutos" num número medido. Não tem noção de contrato, saldo ou faturação - e não precisa de ter, porque o seu objetivo é a métrica de esforço, não a cobrança.

Contract Hours (NexTool)

O Contract Hours é um módulo licenciado da NexTool orientado a quem vende pacotes de horas. O cronómetro fica na timeline do ticket, mas o que produz é diferente: ao parar, o tempo é arredondado para o mínimo faturável configurado (por omissão 15 minutos), transforma-se numa TicketTask privada automática e debita o saldo do contrato associado a esse ticket. Traz o que o ActualTime não tem: quota mensal por contrato, extrato de consumo, painel de "Consumo de Horas" para o cliente na interface simplificada, alertas de contrato expirado ou excedido e, desde a versão 3.6, o conceito de horas não faturáveis (cortesia) - tempo que é registado mas não desconta do saldo.

Comparativo lado a lado

CritérioDuração nativa (manual)ActualTime (TICGAL)Contract Hours (NexTool)
Como o tempo é capturadoIntrodução manualCronómetro na tarefaCronómetro na timeline
Mede tempo realNão (o que introduzir)SimSim
Arredondamento faturávelNãoNãoSim (mínimo configurável, múltiplo de 5)
Ligação ao contratoNãoNãoSim (por entidade; grupo E categoria)
Saldo / quota de horasNãoNãoSim (quota mensal + alertas)
Horas não faturáveis (cortesia)NãoNãoSim (interruptor por tarefa)
Extrato / relatório de consumoNativo (limitado)BásicoDetalhado por ciclo / período
Painel para o clienteNãoNãoSim ("Consumo de Horas")
Onde grava o tempoactiontimeactiontimeactiontime (fonte de verdade) + saldo
LicençaNativoGratuito (GPL)Licenciado
GLPI suportado10 e 1110 e 11Apenas 11

O compromisso que importa na operação

Na sustentação, já usámos os dois: ActualTime em clientes onde a dor era a produtividade interna, Contract Hours onde o contrato de horas era o coração da faturação. O detalhe que só aparece a operar é que os dois acabam por tocar no mesmo campo nativo, o actiontime da tarefa. O ActualTime grava aí o tempo real medido; o Contract Hours trata o actiontime da tarefa como fonte de verdade (a partir da 3.4.2) e cria uma tarefa privada com o tempo já arredondado. Correr os dois no mesmo ticket, sem uma regra sobre quem é o "dono" da tarefa, gera duas durações concorrentes - a medição crua do técnico a lutar com o lançamento faturável arredondado. Por isso decidimos separar os planos: ActualTime como métrica interna (nunca faturável) e Contract Hours como plano contratual, e nunca deixar que os dois criem tarefa no mesmo ticket. A razão é simples: o número que vai para a fatura do cliente tem de ser o arredondado e consciente do contrato, não os segundos crus - e os segundos crus são justamente o que a gestão quer para dimensionar a capacidade. Dois públicos, dois números, duas ferramentas.

O erro comum é esperar que o ActualTime responda "quantas horas restam no contrato?". Não tem esse conceito. Todo o cliente que tentou montar isso exportando dados do ActualTime para uma folha de cálculo viu o número afastar-se da realidade em semanas. E há o desvio do arredondamento: o Contract Hours arredonda para cima até ao mínimo faturável (15 minutos por omissão, múltiplo de 5 por compatibilidade com o GLPI). Uma tarefa de 3 minutos fatura 15. Num mês com muitos tickets curtos, a diferença entre o total real (ActualTime) e o total faturado (Contract Hours) é material - e é exatamente essa diferença que negoceia com o cliente, ou absorve como cortesia através do interruptor de não faturável.

Meça o desvio você mesmo

Como os dois plugins gravam no campo nativo actiontime (em segundos), pode quantificar o tempo registado diretamente na base de dados, sem depender de uma tabela de plugin. Some por técnico no mês e compare com o total faturado que aparece no extrato do Contract Hours:

-- Horas registadas por técnico no mês (campo nativo actiontime, em segundos)
SELECT u.name AS tecnico,
       ROUND(SUM(tt.actiontime) / 3600, 2) AS horas_registadas
FROM glpi_tickettasks tt
JOIN glpi_users u ON u.id = tt.users_id_tech
WHERE tt.date BETWEEN '2026-06-01' AND '2026-06-30 23:59:59'
  AND tt.actiontime IS NOT NULL
GROUP BY tt.users_id_tech
ORDER BY horas_registadas DESC;

Se o total daqui bater com o tempo real medido mas divergir do faturado, a diferença é o arredondamento mais as horas de cortesia - e isso é informação de negociação, não um erro.

Veredito por cenário

  • Use ActualTime quando a pergunta é "a minha equipa é produtiva?". Quer medir o esforço real, alimentar indicadores internos e não cobra à hora. Custo zero, instalação simples.
  • Use Contract Hours quando vende pacotes de horas e o cliente pergunta "quanto já usei e quanto sobra?". Precisa de saldo, extrato, arredondamento faturável, painel do cliente e alerta de excesso. É investimento, mas paga-se a si próprio no primeiro contrato que deixa de subfaturar.
  • Use os dois quando quer o real interno E o faturável externo, desde que em planos separados: ActualTime como métrica (não faturável) e Contract Hours como cobrança, com a regra clara de que só um cria tarefa por ticket.
  • Fique só no campo nativo quando o volume é baixo e a duração manual já resolve. Não instale um plugin para um problema que não tem.

Custo e esforço

O ActualTime é gratuito (GPL): o custo é o de sempre num plugin - validar a build para a sua versão do GLPI e incluí-lo na janela de atualização. O Contract Hours é licenciado, mas o esforço real de implementação não está no cronómetro, e sim no modelo de contrato: definir a quota, mapear o grupo e a categoria que resolvem cada contrato (a regra é E, não OU), configurar o mínimo faturável e a visibilidade de quem vê cada contrato no painel. É meia hora de cliques e algumas horas de decisão comercial. O retorno aparece no primeiro fecho de mês em que o extrato sai pronto para o cliente, sem folha de cálculo.

Na NexTool implementamos e sustentamos os dois modelos no GLPI de clientes B2B. Se o seu estrangulamento é transformar horas de ticket em faturação defensável - com saldo, extrato e painel que o cliente compreende - o módulo Contract Hours do plugin NexTool resolve exatamente isso. Se a dúvida ainda é qual plano faz sentido para a sua operação, fale connosco.


Revisto pela equipa NexTool Solutions.

Perguntas Frequentes

Sim, os dois acabam por escrever no campo nativo actiontime da tarefa. Podem coexistir, mas em planos separados: ActualTime para métrica interna (não faturável) e Contract Hours para cobrança. Nunca deixe que os dois criem tarefa no mesmo ticket, senão soma a medição crua ao lançamento arredondado e infla as horas.

Porque o Contract Hours arredonda para cima até ao mínimo faturável (por omissão 15 minutos, múltiplo de 5). Uma tarefa de 3 minutos fatura 15. A diferença entre o real e o faturado é o arredondamento somado às horas marcadas como não faturáveis (cortesia). É esperado e é justamente o que negoceia com o cliente.

Não. O ActualTime só mede o tempo real gasto na tarefa; não tem conceito de contrato, quota ou saldo. Para responder a 'quanto já usei e quanto sobra' precisa do Contract Hours ou de um controlo externo, que tende a divergir do real com o tempo.

Não. O módulo Contract Hours é apenas para GLPI 11. No GLPI 10, para medir tempo usa o ActualTime ou o campo nativo de duração; o controlo de contrato tem de ser resolvido por outra via até à migração para o 11.

O GLPI nativo tem o campo Duração na tarefa (actiontime, em segundos). Pode somar por técnico via SQL ou pela pesquisa. Funciona para volume baixo, mas é manual e não sabe nada sobre o contrato nem o arredondamento faturável.

Precisa de ajuda?