O ERP diz que tens dois metros. Vais ao armazém e encontras duas sobras de um metro. O cliente precisa de uma peça inteira de dois metros. A conta está certa; a resposta à encomenda está errada.
Quem trabalha com perfis de alumínio, tubos ou varão conhece a diferença. O problema começa quando essa diferença fica apenas na cabeça de quem conhece as estantes. O comercial consulta o saldo, vê metros suficientes e promete material que ninguém consegue tirar de uma barra existente.
Acrescentar um assistente de WhatsApp não resolve isto por si só. Se o assistente consultar apenas a metragem agregada, vai devolver a mesma conclusão errada, agora numa frase mais convincente. A integração útil tem de responder a outra pergunta: existe uma peça física, com comprimento contínuo suficiente, que possa ser usada neste pedido?
O metro é uma unidade de medida, não uma descrição da peça
A dor aparece numa pergunta pública do fórum Odoo sobre compras, inventário e fabrico a partir de barras, num contexto de caixilharia de alumínio e Odoo 18. O utilizador procura uma solução sem desenvolvimento à medida e explica precisamente o obstáculo: duas sobras de um metro não substituem uma peça contínua de dois metros.
Isto não demonstra que o Odoo seja incapaz de gerir o processo. Demonstra que a configuração e o modelo de dados precisam de representar o que a oficina realmente consome. A discussão comunitária sugere separar matéria-prima, peças intermédias e produto final, mas não prova uma solução completa para acompanhar todas as sobras.
Há duas informações diferentes: a quantidade total de material e a distribuição dessa quantidade por peças físicas. A primeira pode servir para valorização e planeamento agregado. A segunda é indispensável para saber se um corte é possível. Não tens de abandonar a gestão em metros; tens de deixar de lhe pedir uma resposta que ela, sozinha, não contém.
Quatro metros podem permitir o trabalho — ou não
Considera este exemplo didático, não um resultado de cliente. O artigo, a secção e o acabamento são iguais nos dois conjuntos; todas as peças estão disponíveis. Por agora, vamos ignorar perdas de corte e preparação.
| Conjunto | Peças físicas existentes | Total no ERP | Existe uma peça contínua de 2 m? |
| — | — | — | — |
| A | Quatro sobras de 1.000 mm | 4 m | Não |
| B | Duas sobras de 1.000 mm e uma barra de 2.000 mm | 4 m | Sim, antes de considerar preparação |
Uma consulta que devolva apenas «stock disponível: 4 m» não distingue estes conjuntos. Nem um modelo de linguagem mais caro consegue deduzir a distribuição certa a partir desse total. Falta informação, não eloquência.
No conjunto A, juntar quatro comprimentos não cria continuidade física. Uma emenda só seria uma alternativa se o projeto a permitisse e alguém competente a aprovasse. O assistente não pode inventar essa autorização para conseguir responder «sim».
No conjunto B, existe continuidade suficiente para uma peça entregue tal como está, se cumprir os restantes requisitos. Isso ainda não significa que seja possível produzir uma peça acabada de 2.000 mm a partir daquela barra.
Comprimento nominal não é comprimento útil
Se o trabalho exige preparação das pontas, tolerâncias ou um corte de separação, uma barra nominal de 2.000 mm pode não chegar. Essas necessidades dependem do processo real: não existe uma margem universal que um chatbot deva aplicar por intuição.
Imagina uma regra de oficina, definida para este exemplo, que acrescenta 10 mm de preparação e 3 mm para um corte de separação. Para obter a peça acabada de 2.000 mm, a consulta tem de procurar pelo menos 2.013 mm nas condições previstas por essa regra. Uma barra de 2.030 mm passa esse primeiro filtro; uma de 2.000 mm não passa.
Os 13 mm são uma hipótese explícita de cálculo, não uma recomendação técnica para a tua serra. Na implementação, a oficina tem de definir como contabiliza preparação e perdas, sem as contar duas vezes. Se a regra não estiver definida, a resposta deve pedir validação, não escolher uma margem plausível.
Também não basta encontrar um comprimento maior. O material tem de corresponder ao pedido: secção, liga ou especificação aplicável, acabamento e estado de utilização. Uma barra suficientemente longa mas danificada na zona necessária não é uma candidata válida só porque tem o número certo no registo.
O que o ERP precisa de saber sobre cada sobra
Não é obrigatório criar um artigo comercial diferente para cada comprimento. É obrigatório conseguir identificar a peça física e associar-lhe os dados relevantes. Isso pode ser resolvido por registos individuais, identificação de peças ou outra estrutura suportada pelo ERP. A escolha depende do sistema instalado e do processo; não se pode prometer que ativar lotes resolve automaticamente o problema.
Para este caso, cada peça precisa de uma identificação, comprimento medido, unidade, localização e ligação ao artigo ou especificação. É ainda necessário representar o estado que determina se pode ser usada. O conector tem de conhecer o significado desses campos, não apenas conseguir lê-los.
O ciclo continua depois do corte. Se uma barra dá origem a uma peça produzida e a uma sobra reutilizável, o sistema precisa de refletir esse resultado. Reduzir apenas a metragem total perde novamente a distribuição por comprimentos. Guardar todo o resíduo como material utilizável também falseia o stock: o critério de reaproveitamento tem de vir da oficina.
Se estás a preparar contagens antes do fecho do ano, esta distinção merece uma verificação própria. Confirmar que a soma de metros bate certo não confirma que os comprimentos registados existem. Podes ter uma quantidade total correta e uma promessa de fabrico impossível.
O que faria uma consulta ligada aos dados reais
Numa integração desenhada para este caso, a pergunta pode ser simples: «Consigo tirar uma peça acabada de dois metros deste perfil?» O trabalho por trás não é uma pesquisa genérica em documentos.
Primeiro, o sistema identifica o perfil e os requisitos em falta. Depois consulta, com as permissões do utilizador, os registos das peças físicas e a regra de preparação aplicável. Uma função de negócio calcula o comprimento mínimo e filtra os candidatos. O modelo de linguagem apresenta o resultado; não decide sozinho a aritmética nem inventa os comprimentos.
A resposta útil seria deste género, ainda no nosso exemplo: «Para a peça acabada de 2.000 mm, a regra indicada exige 2.013 mm. O registo S-104 indica uma barra de 2.030 mm na localização A3. As duas sobras de 1.000 mm não servem. Esta consulta não reservou material.»
A identificação permite ao operador encontrar e conferir a barra. A indicação da regra permite discutir o cálculo. A última frase separa uma leitura de uma alteração ao ERP. São detalhes mais importantes do que o tom simpático da mensagem.
Se o ERP só guardar o saldo agregado, a resposta correta muda: «Consigo consultar os metros totais, mas não confirmar uma peça contínua de dois metros. Não existem comprimentos individuais disponíveis nesta consulta.» Dados insuficientes não significam falta de stock; significam que esta pergunta ainda não pode ser respondida pelo sistema.
Só de leitura, com prova do que foi consultado
O fluxo descrito é um desenho de integração, não a afirmação de que este conector específico já está instalado num cliente Leiritech. O ponto de partida é acesso só de leitura: consultar o ERP e apresentar uma conclusão sustentada, sem alterar barras, ordens ou movimentos.
A auditoria deve permitir reconstruir a resposta: quem perguntou, quando, que peças foram consultadas e que regra de cálculo foi aplicada. Guardar apenas a conversa não chega. Se a conclusão depende de uma barra de 2.030 mm, é esse registo e o valor usado que interessam para perceber a decisão, respeitando os acessos e a política de retenção da empresa.
Se mais tarde houver um âmbito contratado para registar cortes ou atualizar sobras, isso exige um fluxo de escrita separado, autorizado e integrado nas regras do ERP. Uma consulta bem feita não é uma autorização implícita para mexer no inventário.
«Mas eu já resolvo isso quando vou à estante»
Sim. E, se tens poucas barras e uma única pessoa a decidir todos os cortes, talvez não precises de um assistente. Uma identificação clara das sobras e um registo disciplinado podem ser o primeiro investimento certo.
A dificuldade aparece quando o comercial precisa da resposta antes de alguém ir à estante, quando outra pessoa assume o turno ou quando o conhecimento sobre as sobras não acompanha a encomenda. A integração não substitui a disciplina de registo: torna essa informação consultável sem depender sempre da mesma pessoa.
Também não é necessário confundir consulta de viabilidade com otimização de corte. Escolher a melhor distribuição de dezenas de peças por várias barras é outro problema. Encontrar uma barra que serve para um pedido não demonstra que essa escolha minimiza desperdício no plano completo.
O bot de 25 € não é o adversário. A promessa sem dados é
Na oferta pública da 3HASH consultada para esta análise, o assistente de site custa 15 €/mês e o canal WhatsApp acrescenta 10 €/mês, com IVA incluído e 100 € de implementação. A descrição apresenta atendimento, conteúdos da empresa e recolha de contactos; não identifica gestão de barras no ERP incluída nesse pacote. Isso não prova que o fornecedor não consiga desenvolver integrações.
Para responder a horários ou encaminhar pedidos, esse âmbito pode chegar. Para confirmar um comprimento contínuo, o preço da conversa não resolve o modelo físico do stock. E dizer apenas «o nosso agente está ligado ao ERP» também não chega: uma integração que lê o campo errado continua a responder mal.
A diferença defensável está na consulta executada sobre os registos certos, na regra de negócio explícita e na capacidade de mostrar quando não há informação suficiente. Não está em trocar um chatbot barato por outro com uma mensalidade maior.
Começa por uma barra, duas sobras e um pedido real
Antes de escolheres o assistente, leva um pedido concreto ao teu ERP: identifica a especificação, encontra uma barra inteira e duas sobras, e verifica se consegues consultar os comprimentos separadamente. Depois acrescenta a regra de preparação da oficina. É um teste pequeno que expõe imediatamente o que falta representar.
Envia esse exemplo para hello@leiritech.com, sem dados pessoais nem informação confidencial. A conversa começa por perceber o que o teu sistema consegue provar sobre aquela peça — não por prometer que a IA resolve o inventário.
