São 6h40. O camião está encostado ao cais, as paletes estão filmadas e o motorista quer sair às 7h para apanhar o cliente de Braga antes do almoço. Falta a guia. Quem a emite no ERP é a Sandra, da administrativa, que entra às 9h. O motorista manda mensagem para o número de WhatsApp da empresa e o bot responde, simpático e inútil: "Para questões de logística, por favor contacte o departamento responsável."
Ficam três hipóteses em cima da mesa: esperar duas horas, ligar à Sandra para casa ou arrancar sem guia e "resolver depois". Esta última é a que dá problemas, e é a que acontece mais vezes do que se admite.
Porque é que "resolver depois" não resolve
O regime dos bens em circulação é simples de enunciar: o documento de transporte tem de ser comunicado à AT antes de o transporte começar. Quando é comunicado a tempo, por webservice a partir do software certificado, a AT devolve um código de identificação, e é com esse código que o motorista circula.
O pormenor que muita gente só descobre numa operação STOP: se comunicares a guia depois de a mercadoria ter saído, a AT aceita a comunicação, mas não atribui código. O documento existe, mas não prova o que devia provar, porque foi comunicado fora de tempo. Não há conversa bonita que corrija isto a posteriori.
E o problema tem calendário. A Black Week arranca a 23 de novembro, daqui a 54 dias, e a partir daí as expedições não abrandam até ao Natal. Mais cargas, mais cedo, mais saídas fora do horário de quem tem o ERP aberto. O que agora é uma chatice ocasional às 6h40 passa a ser rotina diária.
O que o bot de €25 consegue fazer (e não é isto)
Há chatbots para WhatsApp a €25 por mês, prontos em "alguns dias", que respondem a partir do site, do catálogo e das FAQ. Para dizer o horário do armazém ou captar um contacto chegam perfeitamente. Mas nenhum deles fala com o teu ERP, e sem ERP não há guia. A resposta "contacte a logística" não é um defeito de configuração: é tudo o que um sistema desses pode dizer, porque não tem acesso a nada que exista na tua operação.
Há um segundo limite, e esse é legal. Em Portugal, a Portaria 363/2010 obriga a usar exclusivamente software de faturação certificado. Os documentos são assinados com a chave privada do programa, e o programa não pode ter nenhuma função que altere informação fiscal sem deixar rasto. Um modelo de linguagem não é software certificado. Não pode emitir uma guia, nem que queira. O máximo que pode fazer, e é exatamente o que deve fazer, é pedir a guia ao teu ERP certificado, pela API, e devolver o resultado.
Ou seja, a guia às 6h40 não é um problema de conversa. É um problema de integração.
O mesmo pedido, feito por um agente ligado ao ERP
Pega na mesma manhã. O motorista escreve: "Guia para a encomenda 1432, matrícula AA-00-BB." Eis o que acontece, passo a passo:
- Identificação. O número de telefone está associado a um utilizador com permissão para pedir guias de transporte, e só para isso. Um número desconhecido não passa daqui.
- Leitura (read-only). O agente lê a encomenda 1432 no ERP: cliente, NIF, morada de carga e de descarga, artigos, quantidades. Confirma que a encomenda está preparada e que o stock está reservado.
- Pré-visualização. Antes de escrever o que quer que seja, devolve o resumo: "Guia para Cliente X, Braga, 12 paletes, 3 artigos, matrícula AA-00-BB, início às 7h00. Confirmas?" O motorista confere e responde sim.
- Pedido ao ERP. O agente chama a API do ERP (no PHC GO, por exemplo, através da Full API, com o respetivo acordo de developer) para criar a guia a partir da encomenda. Quem numera, assina e comunica à AT é o ERP certificado, não o agente.
- Resposta. O ERP devolve o número do documento e o código AT. O agente envia-os ao motorista, com o PDF da guia em anexo.
- Registo. Fica gravado quem pediu, de que número, a que horas, com que parâmetros, que documento foi criado e que código a AT atribuiu.
Tudo isto demora menos do que o motorista a apertar o cinto. E a Sandra, quando chega às 9h, encontra a guia no ERP como se a tivesse feito ela, com um registo que diz exatamente de onde veio.
Os detalhes que separam um piloto de um sistema em produção
Uma demo faz os seis passos acima num dia bom. A produção vive nos dias maus.
O motorista envia a mensagem duas vezes. Rede fraca no cais, a mensagem parece não ter ido, ele repete. Um sistema ingénuo cria duas guias. O correto é o pedido levar uma chave de idempotência (encomenda, matrícula e data): o segundo pedido devolve a guia que já existe, não cria outra.
O webservice da AT não responde. Acontece. Aqui é onde um chatbot que "adivinha" se torna perigoso: um modelo sem acesso aos dados pode perfeitamente produzir uma sequência de caracteres com cara de código AT. Um sistema grounded só devolve o que o ERP devolveu. Se não há código, diz "sem código AT, não arranques" e aciona o procedimento de contingência que a tua empresa definiu, avisando quem tem de saber.
A encomenda não está pronta. Se falta a morada de descarga ou uma linha não tem stock reservado, o agente não inventa nem completa. Para, diz o que falta e a quem pedir.
Alguém se enganou na matrícula. A guia é um documento do ERP como qualquer outro: a correção faz-se lá, pelo procedimento normal, e o registo mostra a guia original, quem a pediu e o que mudou.
Nenhum destes casos tem que ver com "IA". Têm que ver com engenharia de integração, e é por isso que um agente destes custa entre €250 e €1.200 por mês e um bot de FAQ custa €25. Não estás a pagar mais pela conversa. Estás a pagar pelo que acontece depois de a conversa acabar.
Não é só no armazém
A mesma lógica aparece onde menos se espera.
Laboratórios de calibração. Quando um laboratório devolve ao cliente um lote de instrumentos calibrados (paquímetros, manómetros, blocos-padrão), essa mercadoria circula e precisa de documento de transporte. O técnico que embala ao fim do dia raramente é quem emite documentos. Num ERP como o PrüfMittel, o pedido pode partir da própria ordem de calibração: os instrumentos, o cliente e os certificados já lá estão.
Saúde e lares. O fornecedor que abastece lares de consumíveis e material clínico sai cedo e faz várias paragens. Cada paragem é uma descarga que tem de estar na guia. Se a rota muda, a alteração tem de ser feita antes de o transporte começar, e é aí que o pedido pelo WhatsApp ganha tempo.
Técnicos no terreno. A carrinha do técnico que leva equipamento para instalar também transporta bens. A guia pedida no próprio telemóvel, a partir da ordem de serviço, evita a guia em papel preenchida à pressa no tablier.
As objeções que ouvimos sempre
"O meu ERP já comunica as guias à AT automaticamente." Ótimo, é exatamente isso que queremos. O agente não substitui essa comunicação; usa-a. O problema nunca foi o ERP comunicar, foi haver alguém com o ERP aberto às 6h40.
"Dou ao motorista acesso ao ERP e pronto." Podes, mas pagas mais uma licença, formas uma pessoa que usa o sistema dois minutos por dia e dás-lhe um acesso muito mais largo do que precisa. O agente dá-lhe exatamente uma ação, e fica tudo registado.
"E se o agente fizer asneira?" É por isso que lê primeiro, mostra antes de escrever, pede confirmação e regista tudo. Um agente que escreve no ERP sem pré-visualização nem auditoria é mesmo uma má ideia, e não é isso que estamos a propor.
Por onde começar
Faz a conta a uma semana normal de expedição: quantas guias foram emitidas fora do horário de quem tem o ERP aberto, quantas cargas esperaram, quantas saíram "para resolver depois". Se a resposta for zero, o bot de €25 serve-te. Se não for, o próximo passo é ver se o teu ERP (PHC, Moloni, InvoiceXpress ou outro) expõe a criação de guias pela API, e com que permissões.
É uma conversa de meia hora com quem vai escrever o código. Fala connosco antes de 23 de novembro: hello@leiritech.com ou +351 914 572 595.
