O GLPI sabe quantos toners você tem em estoque, mas não sabe em qual chamado o último saiu. Os insumos são nativos (ConsumableItem), a baixa é manual e desligada do atendimento - e quando chega a hora 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 Estoque 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, gravado nas tabelas glpi_consumableitems (o modelo de insumo) e glpi_consumables (cada unidade física). Ele controla quantidade, entrada e saída: dar baixa em uma unidade é, no fundo, preencher a coluna date_out daquela linha. O problema não é o controle de saldo em si - é que essa baixa nasce solta. Nativamente, um consumível é "entregue" a um usuário ou a um grupo, nunca a um chamado. Então quando o técnico consome três memórias resolvendo um atendimento, ele até dá baixa, mas em nenhum lugar fica registrado que aquelas três memórias saíram por causa daquele chamado.
As consequências aparecem depois. Auditar o consumo de um período por chamado fica impossível: os dados existem em duas ilhas que não se cruzam. Calcular o custo de insumos de um atendimento 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 registrar, ou registrar no insumo errado, sem ninguém para conferir.
Como funciona
O módulo Estoque cria uma ponte bidirecional entre os chamados e os insumos nativos, sem duplicar dados: ele continua escrevendo em glpi_consumables, só que amarrando cada saída ao chamado que a originou.
- Aba Estoque no chamado - o técnico seleciona o insumo e a quantidade dentro do próprio chamado e debita ali, sem trocar de tela.
- Aba Saídas no insumo - a mesma movimentação aparece na ficha do insumo, com o chamado vinculado visível.
- Validação de saldo em tempo real - antes de debitar, o módulo confere o saldo disponível usando o cálculo nativo do GLPI (unidades com
date_outvazio), impedindo a baixa acima do que existe. - Baixa no estoque nativo - a saída preenche
date_outnas unidades consumidas e grava o vínculo com o chamado na própria linha nativa, mantendo o estoque do GLPI consistente. - Estorno com devolução configurável - uma saída pode ser estornada com um clique, devolvendo as unidades ao estoque; o comportamento é configurável.
- Relatórios com exportação CSV - painel de movimentações com filtros por período, insumo e status, e botão de exportação em CSV para levar à planilha.
- Chamado obrigatório - opção que exige que toda saída esteja vinculada a um chamado, fechando a porta para baixas sem rastreabilidade.
Como ativar
- Instale o NexTool no seu GLPI (10 ou 11).
- Acesse Configuração > NexTool > Módulos.
- Ative o módulo Estoque e clique em Configurar.
- Na aba de configurações, defina se o estorno devolve o insumo ao estoque e se o chamado é obrigatório em toda saída.
Nativo x módulo Estoque
O ponto não é substituir o consumível nativo - é estendê-lo. A tabela mostra onde o comportamento nativo para e onde o módulo continua:
| Recurso | GLPI nativo (ConsumableItem) | Módulo Estoque |
|---|---|---|
| Baixa vinculada ao chamado | Manual, atribuída a um usuário ou grupo (itemtype User/Group) - sem ligação com o chamado | Debita de dentro do chamado e grava itemtype = 'Ticket' na linha nativa |
| Validação de saldo | Controla o saldo, mas fora do fluxo do atendimento | Confere o saldo em tempo real na aba do chamado, antes de debitar |
| Estorno | Devolução manual, editando a unidade para limpar a saída | Estorno em um clique, com devolução configurável |
| Rastreabilidade auditável | Registra quem recebeu, não qual chamado motivou | Movimento com chamado, insumo, quantidade, usuário e data |
| Relatório CSV por período | Listagem por insumo, sem recorte por chamado | Painel com filtros de período e status, exportável em CSV |
Diagnóstico direto no banco
Enquanto avalia o módulo - ou para conferir o que o nativo registra - dá para medir o saldo e as saídas direto nas tabelas do GLPI. As duas consultas que usamos:
-- Saldo real por insumo, direto nas tabelas nativas do GLPI.
-- Cada linha de glpi_consumables é UMA unidade física: date_out vazio = em estoque,
-- date_out preenchido = já consumida. glpi_consumableitems é o modelo do insumo.
SELECT ci.id AS insumo_id,
ci.name AS insumo,
SUM(c.date_out IS NULL) AS em_estoque,
SUM(c.date_out IS NOT NULL) AS consumidos,
COUNT(c.id) AS total_cadastrado
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_estoque ASC;
-- Saídas já vinculadas a chamados: ao debitar, 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 insumo,
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 "quais chamados os consumiram". Sem esse cruzamento, a auditoria de consumo por período era reconstruída na base do achismo. Dois erros se repetem em campo. O primeiro é a baixa manual no insumo sem citar o chamado: o técnico entrega o item pelo fluxo nativo, o saldo até fecha, mas o atendimento fica sem custo e o relatório, furado. O segundo é mais silencioso - subir o módulo e esquecer de ligar o "chamado obrigatório": por semanas as saídas convivem, umas vinculadas 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 paralela de estoque, ele escreve na mesma glpi_consumables - por isso a baixa feita pelo chamado e a baixa feita pela tela nativa 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 Estoque faz sentido para equipes de suporte e infraestrutura que consomem insumos físicos - toners, cabos, peças, memórias - durante os atendimentos e precisam amarrar cada consumo ao chamado que o gerou. E para gestores que querem enxergar o custo de insumos por atendimento sem exportar planilha de dois sistemas.
Não vale a pena se você não usa os consumíveis nativos do GLPI - o módulo se apoia neles, não os substitui - ou se o controle de estoque da sua operação vive num ERP externo, que continua sendo a fonte de verdade. Nesses casos, a integração certa é com o ERP, não uma segunda contabilidade de estoque dentro do GLPI.
Compatibilidade
- GLPI: 10.0+ e 11.0+.
- Disponibilidade: sob demanda.
- Plugin: NexTool 3.x ou superior.
O Estoque faz parte do NexTool, o ecossistema de módulos que expande o GLPI sem customização de código. Para ver a baixa por chamado funcionando no seu ambiente, fale com a equipe.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.