ActualTime vs Contract Hours: Control de Tiempo en GLPI

ActualTime mide el tiempo real del técnico; Contract Hours controla el saldo del contrato y factura. Comparativa de los dos plugins de tiempo en GLPI, el trade-off del actiontime compartido, veredicto por escenario y cómo medir el gap de redondeo.

En este artículo8 secciones

Medir el tiempo de un ticket y facturar ese tiempo son dos problemas diferentes. Uno trata de la productividad del equipo: cuánto tiempo real dedicó el técnico. El otro trata del contrato: cuántas horas ha consumido el cliente y cuántas le quedan. Confundir ambos es el error que más vemos en el soporte continuo - y la elección entre ActualTime y Contract Hours empieza justo ahí.

El problema: tres planos de "tiempo" en GLPI

Antes de elegir plugin, conviene separar tres cosas que GLPI trata de forma distinta:

  • Tiempo estimado - la duración que planificaste para la tarea.
  • Tiempo real - cuánto tardó de verdad el técnico, cronometrado.
  • Tiempo facturable - lo que entra en el contrato, ya redondeado y con reglas comerciales.

El campo nativo Duración de la tarea (almacenado en segundos en actiontime) resuelve lo básico, pero exige captura manual y no sabe nada del contrato. Ahí entran los dos plugins.

ActualTime (TICGAL)

ActualTime es un plugin gratuito y de código abierto de TICGAL. Añade botones de play, pausa y stop en la tarea del ticket y cronometra el tiempo real que el técnico dedica a ella. Al detenerlo, graba ese tiempo medido en la duración de la tarea. El enfoque es honesto y estrecho: convertir "creo que tardé unos 40 minutos" en un número medido. No tiene noción de contrato, saldo ni facturación - y no la necesita, porque su objetivo es la métrica de esfuerzo, no el cobro.

Contract Hours (NexTool)

Contract Hours es un módulo licenciado de NexTool orientado a quien vende paquetes de horas. El cronómetro está en la línea de tiempo del ticket, pero lo que produce es distinto: al detenerse, el tiempo se redondea al mínimo facturable configurado (por defecto 15 minutos), se convierte en una TicketTask privada automática y descuenta el saldo del contrato vinculado a ese ticket. Lleva lo que ActualTime no tiene: cuota mensual por contrato, extracto de consumo, panel de "Consumo de Horas" para el cliente en la interfaz simplificada, alertas de contrato vencido o excedido y, desde la versión 3.6, el concepto de horas no facturables (cortesía) - tiempo que se registra pero no descuenta del saldo.

Comparativa lado a lado

CriterioDuración nativa (manual)ActualTime (TICGAL)Contract Hours (NexTool)
Cómo se captura el tiempoCaptura manualCronómetro en la tareaCronómetro en la línea de tiempo
Mide tiempo realNo (lo que escribas)SíSí
Redondeo facturableNoNoSí (mínimo configurable, múltiplo de 5)
Vínculo con contratoNoNoSí (por entidad; grupo Y categoría)
Saldo / cuota de horasNoNoSí (cuota mensual + alertas)
Horas no facturables (cortesía)NoNoSí (interruptor por tarea)
Extracto / informe de consumoNativo (limitado)BásicoDetallado por ciclo / período
Panel para el clienteNoNoSí ("Consumo de Horas")
Dónde se guarda el tiempoactiontimeactiontimeactiontime (fuente de verdad) + saldo
LicenciaNativoGratuito (GPL)Licenciado
GLPI soportado10 y 1110 y 11Solo 11

El trade-off que importa en la operación

En el soporte continuo ya hemos usado ambos: ActualTime en clientes cuyo dolor era la productividad interna, Contract Hours donde el contrato de horas era el corazón de la facturación. El detalle que solo aparece operando es que ambos terminan tocando el mismo campo nativo, el actiontime de la tarea. ActualTime graba allí el tiempo real medido; Contract Hours trata el actiontime de la tarea como fuente de verdad (desde la 3.4.2) y crea una tarea privada con el tiempo ya redondeado. Ejecutar ambos en el mismo ticket, sin una regla de quién es el "dueño" de la tarea, genera dos duraciones que compiten - la medición cruda del técnico peleando con el registro facturable redondeado. Por eso decidimos separar los planos: ActualTime como métrica interna (nunca facturable) y Contract Hours como plano contractual, y nunca dejar que ambos creen tarea en el mismo ticket. La razón es simple: el número que va a la factura del cliente debe ser el redondeado y consciente del contrato, no los segundos crudos - y los segundos crudos son justamente lo que la gestión quiere para dimensionar la capacidad. Dos audiencias, dos números, dos herramientas.

El error común es esperar que ActualTime responda "¿cuántas horas quedan en el contrato?". No tiene ese concepto. Todo cliente que intentó montar eso exportando datos de ActualTime a una hoja de cálculo vio el número desviarse de la realidad en semanas. Y está el gap del redondeo: Contract Hours redondea hacia arriba hasta el mínimo facturable (15 minutos por defecto, múltiplo de 5 por compatibilidad con GLPI). Una tarea de 3 minutos factura 15. En un mes con muchos tickets cortos, la diferencia entre el total real (ActualTime) y el total facturado (Contract Hours) es material - y esa diferencia es exactamente lo que negocias con el cliente, o absorbes como cortesía mediante el interruptor de no facturable.

Mide tú mismo el gap

Como ambos plugins escriben en el campo nativo actiontime (en segundos), puedes cuantificar el tiempo registrado directamente desde la base de datos, sin depender de una tabla de plugin. Suma por técnico en el mes y compáralo con el total facturado que aparece en el extracto de Contract Hours:

-- Horas registradas por técnico en el mes (campo nativo actiontime, en segundos)
SELECT u.name AS tecnico,
       ROUND(SUM(tt.actiontime) / 3600, 2) AS horas_registradas
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_registradas DESC;

Si el total de aquí coincide con el tiempo real medido pero difiere de lo facturado, la diferencia es el redondeo más las horas de cortesía - y eso es información de negociación, no un error.

Veredicto por escenario

  • Usa ActualTime cuando la pregunta es "¿es productivo mi equipo?". Quieres medir el esfuerzo real, alimentar indicadores internos y no cobras por hora. Coste cero, instalación sencilla.
  • Usa Contract Hours cuando vendes paquetes de horas y el cliente pregunta "¿cuánto he usado y cuánto queda?". Necesitas saldo, extracto, redondeo facturable, panel del cliente y alerta de exceso. Es una inversión, pero se paga sola en el primer contrato que dejas de subfacturar.
  • Usa ambos cuando quieres el real interno Y el facturable externo, siempre que estén en planos separados: ActualTime como métrica (no facturable) y Contract Hours como facturación, con la regla clara de que solo uno crea tarea por ticket.
  • Quédate en el campo nativo cuando el volumen es bajo y la duración manual ya lo resuelve. No instales un plugin para un problema que no tienes.

Coste y esfuerzo

ActualTime es gratuito (GPL): el coste es el de siempre en un plugin - validar la build para tu versión de GLPI e incluirlo en la ventana de actualización. Contract Hours es licenciado, pero el esfuerzo real de implantación no está en el cronómetro, sino en el modelo de contrato: definir la cuota, mapear el grupo y la categoría que resuelven cada contrato (la regla es Y, no O), configurar el mínimo facturable y quién ve cada contrato en el panel. Es media hora de clics y unas horas de decisiones comerciales. El retorno aparece en el primer cierre de mes en que el extracto sale listo para el cliente, sin hoja de cálculo.

En NexTool implantamos y damos soporte a ambos modelos en el GLPI de clientes B2B. Si tu cuello de botella es convertir horas de ticket en facturación defendible - con saldo, extracto y panel que el cliente entiende - el módulo Contract Hours del plugin NexTool resuelve exactamente eso. Si aún dudas qué plano tiene sentido para tu operación, habla con nosotros.


Revisado por el equipo de NexTool Solutions.

Preguntas Frecuentes

Sí, ambos terminan escribiendo en el campo nativo actiontime de la tarea. Pueden coexistir, pero en planos separados: ActualTime para métrica interna (no facturable) y Contract Hours para facturación. Nunca dejes que ambos creen tarea en el mismo ticket, o sumarás la medición cruda al registro redondeado e inflarás las horas.

Porque Contract Hours redondea hacia arriba hasta el mínimo facturable (por defecto 15 minutos, múltiplo de 5). Una tarea de 3 minutos factura 15. La diferencia entre lo real y lo facturado es el redondeo más las horas marcadas como no facturables (cortesía). Es lo esperado y es justo lo que negocias con el cliente.

No. ActualTime solo mide el tiempo real dedicado a la tarea; no tiene concepto de contrato, cuota ni saldo. Para responder 'cuánto he usado y cuánto queda' necesitas Contract Hours o un control externo, que tiende a desviarse de la realidad con el tiempo.

No. El módulo Contract Hours es solo para GLPI 11. En GLPI 10, para medir tiempo usas ActualTime o el campo nativo de duración; el control de contrato hay que resolverlo de otra forma hasta la migración a 11.

GLPI nativo tiene el campo Duración en la tarea (actiontime, en segundos). Puedes sumarlo por técnico vía SQL o por la búsqueda. Funciona para volumen bajo, pero es manual y no sabe nada del contrato ni del redondeo facturable.

?Necesitas ayuda?