NexTool Solutions

O GLPI sabe quantos toners tem em stock, mas não sabe em que chamado saiu o último. Os consumíveis são nativos (ConsumableItem), a saída é manual e está desligada do chamado - por isso, quando chega a altura de auditar o consumo de um período ou justificar o custo de um chamado, a informação simplesmente não existe. O módulo Stock do NexTool fecha essa lacuna ligando os dois lados que o GLPI deixou separados.

O problema

O GLPI tem um módulo nativo de consumíveis - o ConsumableItem, guardado nas tabelas glpi_consumableitems (o modelo de consumível) e glpi_consumables (cada unidade física). Controla quantidade, entrada e saída: dar baixa numa unidade é, no fundo, preencher a coluna date_out dessa linha. O problema não é o controlo de saldo em si - é que essa baixa nasce solta. Nativamente, um consumível é "entregue" a um utilizador ou a um grupo, nunca a um chamado. Por isso, quando o técnico consome três memórias a resolver um pedido, até regista a saída, mas em lado nenhum fica registado que aquelas três memórias saíram por causa daquele chamado.

As consequências surgem depois. Auditar o consumo de um período por chamado torna-se impossível: os dados vivem em duas ilhas que não se cruzam. Calcular o custo dos consumíveis de um pedido vira exercício de memória do técnico. E a baixa manual, feita fora do fluxo do chamado, abre espaço para o erro mais comum de todos - esquecer de a registar, ou registá-la no consumível errado, sem ninguém para conferir.

Como funciona

O módulo Stock cria uma ponte bidirecional entre os chamados e os consumíveis nativos, sem duplicar dados: continua a escrever em glpi_consumables, apenas amarrando cada saída ao chamado que a originou.

• Separador Stock no chamado - o técnico seleciona o consumível e a quantidade dentro do próprio chamado e dá baixa ali, sem trocar de ecrã.
• Separador Saídas no consumível - o mesmo movimento aparece na ficha do consumível, com o chamado ligado visível.
• Validação de saldo em tempo real - antes de dar baixa, o módulo confere o saldo disponível com o cálculo nativo do GLPI (unidades com date_out vazio), impedindo saídas acima do que existe.
• Baixa no stock nativo - a saída preenche date_out nas unidades consumidas e grava o vínculo com o chamado na própria linha nativa, mantendo o stock do GLPI consistente.
• Estorno com devolução configurável - uma saída pode ser estornada com um clique, devolvendo as unidades ao stock; o comportamento é configurável.
• Relatórios com exportação CSV - painel de movimentos com filtros por período, consumível e estado, e botão de exportação em CSV para a folha de cálculo.
• Chamado obrigatório - opção que exige que toda a saída esteja ligada a um chamado, fechando a porta a saídas sem rastreabilidade.

Como ativar

1. Instale o NexTool no seu GLPI (10 ou 11).
2. Aceda a Configuração > NexTool > Módulos.
3. Ative o módulo Stock e clique em Configurar.
4. No separador de definições, defina se o estorno devolve o consumível ao stock e se o chamado é obrigatório em cada saída.

Nativo vs. módulo Stock

O objetivo não é substituir o consumível nativo - é estendê-lo. A tabela mostra onde o comportamento nativo para e onde o módulo continua:

Diagnóstico direto na base de dados

Enquanto avalia o módulo - ou só para conferir o que o nativo regista - dá para medir o saldo e as saídas diretamente nas tabelas do GLPI. As duas consultas que usamos:

-- Saldo real por consumível, direto nas tabelas nativas do GLPI.
-- Cada linha de glpi_consumables é UMA unidade física: date_out vazio = em stock,
-- date_out preenchido = já consumida. glpi_consumableitems é o modelo do consumível.
SELECT ci.id                       AS consumivel_id,
       ci.name                     AS consumivel,
       SUM(c.date_out IS NULL)     AS em_stock,
       SUM(c.date_out IS NOT NULL) AS consumidos,
       COUNT(c.id)                 AS total_registado
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 em_stock ASC;

-- Saídas já ligadas a chamados: ao dar baixa, o módulo grava itemtype='Ticket'
-- e items_id = número do chamado na própria linha nativa.
-- Num GLPI sem o módulo este filtro volta vazio (a saída nativa vai para User/Group).
SELECT c.items_id      AS chamado,
       ci.name         AS consumivel,
       COUNT(*)        AS unidades_baixadas,
       MAX(c.date_out) AS ultima_saida
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_saida DESC;

A experiência de quem opera

Na sustentação de service desks de clientes, a rastreabilidade por chamado foi sempre o que faltava - o GLPI dizia "saíram 20 toners este mês", mas não "que chamados os consumiram". Sem esse cruzamento, auditar o consumo por período era reconstruído no achismo. Dois erros repetem-se no terreno. O primeiro é a baixa manual no consumível sem citar o chamado: o técnico entrega o artigo pelo fluxo nativo, o saldo até fecha, mas o pedido fica sem custo e o relatório furado. O segundo é mais silencioso - subir o módulo e esquecer de ligar o "chamado obrigatório": durante semanas convivem saídas, umas ligadas e outras não, e só quando alguém pede o relatório é que a lacuna aparece. O detalhe que só quem opera sabe: o módulo não inventa uma tabela de stock paralela, escreve na mesma glpi_consumables - por isso a baixa feita pelo chamado e a baixa feita pelo ecrã nativo disputam o mesmo saldo. Padronizar tudo pelo chamado, com a obrigatoriedade ligada desde o primeiro dia, é o que evita os dois números divergirem.

Para quem é indicado (e quando NÃO usar)

O Stock faz sentido para equipas de suporte e infraestrutura que consomem consumíveis físicos - toners, cabos, peças, memórias - durante os atendimentos e precisam de amarrar cada consumo ao chamado que o gerou. E para gestores que querem ver o custo de consumíveis por pedido sem exportar folhas de dois sistemas.

Não compensa se não usa os consumíveis nativos do GLPI - o módulo apoia-se neles, não os substitui - ou se o controlo de stock da sua operação vive num ERP externo, que continua a ser a fonte de verdade. Nesses casos, a integração certa é com o ERP, não uma segunda contabilidade de stock dentro do GLPI.

Compatibilidade

• GLPI: 10.0+ e 11.0+.
• Disponibilidade: a pedido.
• Plugin: NexTool 3.x ou superior.

O Stock faz parte do NexTool, o ecossistema de módulos que expande o GLPI sem personalização de código. Para ver a baixa por chamado a funcionar no seu ambiente, fale com a equipa.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.