NexTool Solutions

GLPI sabe cuántos tóneres tienes en stock, pero no en qué ticket salió el último. Los insumos son nativos (ConsumableItem), la baja es manual y está desconectada del ticket - así que cuando llega el momento de auditar el consumo de un período o justificar el coste de un ticket, la información sencillamente no existe. El módulo Stock de NexTool cierra esa brecha uniendo los dos lados que GLPI dejó separados.

El problema

GLPI tiene un módulo nativo de consumibles - ConsumableItem, guardado en las tablas glpi_consumableitems (el modelo de insumo) y glpi_consumables (cada unidad física). Controla cantidad, entrada y salida: dar de baja una unidad es, en el fondo, rellenar la columna date_out de esa fila. El problema no es el control de saldo en sí - es que esa baja nace suelta. De forma nativa, un consumible se "entrega" a un usuario o a un grupo, nunca a un ticket. Así que cuando el técnico consume tres memorias resolviendo una incidencia, sí registra la salida, pero en ningún lugar queda que esas tres memorias salieron por ese ticket.

Las consecuencias aparecen después. Auditar el consumo de un período por ticket se vuelve imposible: los datos viven en dos islas que no se cruzan. Calcular el coste de insumos de una incidencia se convierte en un ejercicio de memoria del técnico. Y la baja manual, hecha fuera del flujo del ticket, abre la puerta al error más común de todos - olvidar registrarla, o registrarla en el insumo equivocado, sin nadie que lo verifique.

Cómo funciona

El módulo Stock crea un puente bidireccional entre los tickets y los consumibles nativos, sin duplicar datos: sigue escribiendo en glpi_consumables, solo que ahora ata cada salida al ticket que la originó.

• Pestaña Stock en el ticket - el técnico elige el insumo y la cantidad dentro del propio ticket y da la baja ahí, sin cambiar de pantalla.
• Pestaña Salidas en el insumo - el mismo movimiento aparece en la ficha del insumo, con el ticket vinculado visible.
• Validación de saldo en tiempo real - antes de dar la baja, el módulo comprueba el saldo disponible con el cálculo nativo de GLPI (unidades con date_out vacío), impidiendo salidas por encima de lo que existe.
• Baja en el stock nativo - la salida rellena date_out en las unidades consumidas y graba el vínculo con el ticket en la propia fila nativa, manteniendo el stock de GLPI consistente.
• Estorno con devolución configurable - una salida se puede revertir con un clic, devolviendo las unidades al stock; el comportamiento es configurable.
• Informes con exportación CSV - panel de movimientos con filtros por período, insumo y estado, y botón de exportación en CSV para la hoja de cálculo.
• Ticket obligatorio - opción que exige que toda salida esté vinculada a un ticket, cerrando la puerta a bajas sin trazabilidad.

Cómo activarlo

1. Instala NexTool en tu GLPI (10 u 11).
2. Entra en Configuración > NexTool > Módulos.
3. Activa el módulo Stock y haz clic en Configurar.
4. En la pestaña de ajustes, define si el estorno devuelve el insumo al stock y si el ticket es obligatorio en cada salida.

Nativo vs. módulo Stock

La cuestión no es sustituir el consumible nativo - es ampliarlo. La tabla muestra dónde para el comportamiento nativo y dónde sigue el módulo:

Diagnóstico directo en la base de datos

Mientras evalúas el módulo - o solo para comprobar qué registra lo nativo - puedes medir el saldo y las salidas directamente en las tablas de GLPI. Las dos consultas que usamos:

-- Saldo real por insumo, directo desde las tablas nativas de GLPI.
-- Cada fila de glpi_consumables es UNA unidad física: date_out vacío = en stock,
-- date_out relleno = ya consumida. glpi_consumableitems es el modelo del insumo.
SELECT ci.id                       AS insumo_id,
       ci.name                     AS insumo,
       SUM(c.date_out IS NULL)     AS en_stock,
       SUM(c.date_out IS NOT NULL) AS consumidos,
       COUNT(c.id)                 AS total_registrado
FROM glpi_consumableitems ci
LEFT JOIN glpi_consumables c ON c.consumableitems_id = ci.id
WHERE ci.is_deleted = 0
GROUP BY ci.id, ci.name
ORDER BY en_stock ASC;

-- Salidas ya vinculadas a tickets: al dar la baja, el módulo graba itemtype='Ticket'
-- e items_id = el número del ticket en la propia fila nativa.
-- En un GLPI sin el módulo este filtro vuelve vacío (la salida nativa va a User/Group).
SELECT c.items_id      AS ticket,
       ci.name         AS insumo,
       COUNT(*)        AS unidades_dadas_baja,
       MAX(c.date_out) AS ultima_salida
FROM glpi_consumables c
JOIN glpi_consumableitems ci ON ci.id = c.consumableitems_id
WHERE c.date_out IS NOT NULL
  AND c.itemtype = 'Ticket'
GROUP BY c.items_id, ci.name
ORDER BY ultima_salida DESC;

La experiencia de quien lo opera

En el mantenimiento de service desks de clientes, la trazabilidad por ticket fue siempre lo que faltaba - GLPI decía "salieron 20 tóneres este mes", pero no "qué tickets los consumieron". Sin ese cruce, auditar el consumo por período se reconstruía a base de suposiciones. Dos errores se repiten en campo. El primero es la baja manual en el insumo sin citar el ticket: el técnico entrega el artículo por el flujo nativo, el saldo hasta cuadra, pero la incidencia queda sin coste y el informe, agujereado. El segundo es más silencioso - desplegar el módulo y olvidar activar el "ticket obligatorio": durante semanas conviven salidas, unas vinculadas y otras no, y solo cuando alguien pide el informe aparece el hueco. El detalle que solo sabe quien opera: el módulo no inventa una tabla paralela de stock, escribe en la misma glpi_consumables - por eso la baja hecha desde el ticket y la hecha desde la pantalla nativa compiten por el mismo saldo. Estandarizar todo por el ticket, con la obligatoriedad activada desde el primer día, es lo que evita que los dos números se separen.

Para quién es (y cuándo NO usarlo)

Stock tiene sentido para equipos de soporte e infraestructura que consumen insumos físicos - tóneres, cables, piezas, memorias - durante la atención y necesitan atar cada consumo al ticket que lo generó. Y para gestores que quieren ver el coste de insumos por incidencia sin exportar hojas de dos sistemas.

No compensa si no usas los consumibles nativos de GLPI - el módulo se apoya en ellos, no los sustituye - o si el control de stock de tu operación vive en un ERP externo, que sigue siendo la fuente de verdad. En esos casos, la integración correcta es con el ERP, no una segunda contabilidad de stock dentro de GLPI.

Compatibilidad

• GLPI: 10.0+ y 11.0+.
• Disponibilidad: bajo demanda.
• Plugin: NexTool 3.x o superior.

Stock forma parte de NexTool, el ecosistema de módulos que amplía GLPI sin personalización de código. Para ver la baja por ticket funcionando en tu entorno, habla con el equipo.

Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de Nextool Solutions.