Horas de trabalho no ERP: a linha de venda certa
Tens as duas horas registadas, mas no fecho do mês ainda precisas de perguntar ao técnico a que serviço pertencem. O cliente está certo. A duração também. Mesmo assim, ninguém sabe se aquele trabalho estava incluído no contrato ou se corresponde a uma intervenção adicional para faturar.
Passar de uma mensagem de WhatsApp para um campo «2 horas» não resolve este problema. Só muda o sítio onde a dúvida fica guardada. A integração útil tem de preservar o destino comercial do trabalho: a tarefa, o projeto e, quando aplicável, a linha da encomenda de venda à qual essas horas pertencem.
É aí que se distingue um assistente que responde bem de um sistema que consulta o teu ERP e prepara um registo verificável. Não pela fluidez da conversa, mas pela associação que consegue justificar — e pela decisão que recusa tomar quando faltam dados.
O cliente certo ainda pode esconder o serviço errado
Imagina um laboratório de calibração que faz dois trabalhos para a mesma fábrica. Um está incluído num contrato periódico. Outro é uma intervenção extraordinária, adjudicada à parte. O técnico termina a visita e dita: «Hoje foram duas horas na fábrica.»
A frase permite extrair uma duração e talvez identificar o cliente. Não permite escolher, com segurança, entre os dois serviços. Se o sistema colocar tudo no contrato periódico, o trabalho adicional pode ficar fora da preparação da faturação. Se colocar tudo na intervenção extra, pode apresentar como faturável um trabalho já incluído.
O problema não é a transcrição. É uma relação comercial em falta.
Em saúde acontece algo semelhante com uma empresa que presta assistência técnica a equipamentos de uma clínica: a visita pode pertencer à manutenção contratada ou a uma reparação adicional. Num armazém, duas horas de manutenção de um transportador podem integrar a assistência regular ou um serviço extraordinário. O nome do cliente não distingue essas situações; o contrato e a ordem de trabalho podem distingui-las.
Não precisas de um modelo mais criativo para resolver isto. Precisas de consultar os registos certos.
O que o Odoo documenta — e o que não deves presumir
A documentação do Odoo 19 sobre folhas de horas dá uma indicação concreta: ao registar trabalho num projeto faturável, deve ser incluído o campo Sales Order Item, a linha da encomenda de venda, para que o tempo possa ser faturado ao cliente. A mesma documentação permite editar, nos detalhes do registo, o projeto, a tarefa, a duração e essa associação comercial quando aplicável.
Isto não significa que qualquer duração guardada se transforme automaticamente numa fatura. Significa que a ligação entre o trabalho e a venda faz parte dos dados necessários ao circuito. As condições de faturação continuam a depender da configuração do serviço e do contrato.
Há outro detalhe útil: segundo a mesma página, o temporizador pode selecionar inicialmente o projeto mais frequente entre os cinco registos mais recentes. É um atalho de utilização, não uma prova de que esse projeto corresponde à visita de hoje. A documentação consultada também não estabelece uma regra universal de seleção automática da linha de venda.
Por isso, uma integração não deve transformar «foi o último projeto usado» em «é o projeto correto». E ter um conector Odoo não dispensa verificar os módulos, a versão, a configuração e as permissões da instalação concreta.
Um exemplo: duas horas, dois destinos possíveis
Vamos usar um exemplo fictício, apenas para tornar o erro visível. Uma empresa de serviços tem duas linhas de venda para o mesmo cliente:
| Linha | Serviço | Tratamento contratado |
| — | — | — |
| A | Manutenção periódica | Trabalho incluído no preço acordado |
| B | Intervenção extraordinária | Tempo faturável a 65 €/hora |
O técnico trabalhou duas horas na intervenção extraordinária. Neste exemplo, o valor desse trabalho é 2 × 65 € = 130 €, antes de impostos. Não é uma estimativa de poupança nem um resultado de cliente: é a consequência aritmética da tarifa fictícia indicada.
Se as duas horas ficarem associadas à linha A, o registo pode parecer completo numa revisão superficial: tem colaborador, data, cliente e duração. Mas não representa o destino comercial do serviço realizado. A administração terá de reconstruir a visita antes de decidir o que faturar.
A resposta útil do assistente seria algo deste género: «Encontrei manutenção periódica e intervenção extraordinária para este cliente. A que trabalho pertencem as duas horas?» Se uma ordem de trabalho já ligar a visita à linha B, o sistema pode apresentar essa relação como fundamento da proposta, em vez de pedir ao técnico que escolha de memória.
Depois, o resumo para confirmação deve mostrar a data, o colaborador, a duração, a tarefa e a referência da linha de venda. «Confirmas as duas horas?» é insuficiente: o utilizador tem de confirmar também onde vão ficar.
O valor a faturar continua a ser calculado e validado no circuito comercial do ERP. Não deve nascer de uma tarifa que o modelo inventou ou recuperou de uma conversa antiga.
Primeiro consultar; só depois propor uma gravação
Na Leiritech, o acesso conversacional ao ERP é apresentado como só de leitura, auditado e baseado nos dados do cliente. Convém manter essa fronteira explícita: uma consulta não ganha permissão de escrita por ter sido feita em linguagem natural.
Para este caso, uma primeira implementação pode limitar-se a consultar as tarefas e linhas elegíveis e apresentar uma proposta de associação. O colaborador autorizado faz o registo no ERP. Já é possível testar se o sistema encontra o destino correto sem lhe permitir alterar dados.
Gravar as horas a partir da conversa seria uma evolução específica, sujeita à API disponível, às regras da instalação e à implementação de um circuito de confirmação. Não é uma funcionalidade instalada que este artigo esteja a anunciar.
Nesse circuito proposto, o contacto de WhatsApp teria de estar associado a uma identidade autorizada. O número de telefone, por si só, não concede acesso aos projetos da empresa. O conector deve limitar o que cada pessoa pode consultar e, numa eventual operação de escrita, voltar a validar as condições antes de a executar.
A mensagem original também não substitui o registo de auditoria. Para perceber uma associação mais tarde, interessa saber quem pediu, que referências o sistema consultou, o que propôs, quem confirmou e qual foi o identificador devolvido pelo ERP. Uma frase «ficou tratado» no WhatsApp não demonstra que exista um registo válido.
Se o destino estiver ambíguo, o estado correto é «por confirmar». Se a gravação falhar, é «não registado». A linguagem deve refletir o estado do sistema, não tentar tranquilizar o utilizador.
Porque é que dar instruções ao chatbot não chega?
Podes escrever no contexto do assistente que aquele cliente tem um contrato anual. Isso ajuda a explicar o negócio. Não lhe diz necessariamente que existe uma adjudicação adicional, que uma tarefa foi encerrada ou que aquele colaborador só pode consultar parte dos projetos.
Um sistema baseado nos dados reais faz uma coisa diferente: executa consultas delimitadas, recebe referências concretas e usa essas referências para sustentar a resposta. O modelo interpreta a frase do técnico; as regras da integração determinam quais os destinos admissíveis. Havendo duas possibilidades compatíveis, pede esclarecimento.
Nem consultar o ERP elimina todas as dúvidas. Se a ordem de trabalho não estiver ligada a uma linha de venda, a informação continua em falta. A vantagem é tornar essa ausência visível, em vez de a preencher com uma associação plausível.
É também por isso que uma fatura eletrónica corretamente emitida não corrige, por si, a origem comercial errada das horas. A emissão é uma etapa posterior. Primeiro tens de saber que serviço foi realizado e em que condições foi vendido.
O bot de 25 € e a objeção que merece resposta
Na oferta consultada em outubro de 2026, a 3HASH anunciava 15 €/mês para o site e mais 10 €/mês para WhatsApp, com IVA incluído, além de 100 € de configuração. A página descrevia atendimento, recolha de contactos e encaminhamento. Não especificava, nesse pacote, a associação de horas a linhas de venda num ERP.
Isso não prova incapacidade do fornecedor: a própria 3HASH anuncia integrações ERP na oferta Enterprise, sob consulta. Prova apenas que não deves comparar âmbitos diferentes como se fossem o mesmo produto.
A objeção mais forte nem é o preço: «O técnico já consegue fazer isto no Odoo. Para quê acrescentar um assistente?»
Se o registo direto funciona bem, não precisas de o substituir. Um formulário com a tarefa certa pré-selecionada pode ser mais simples e mais seguro do que uma conversa. A integração por WhatsApp só merece espaço se reduzir trabalho real sem enfraquecer a associação comercial.
Por isso, mede o processo completo: quantos registos precisam de esclarecimento, quantos chegam sem destino utilizável e quanto trabalho administrativo é necessário para os corrigir. Não contes apenas quantas mensagens o assistente respondeu. Também não há base para prometer que uma mensalidade se paga com determinado número de horas sem conhecer os teus custos e o teu processo.
O teste útil antes do fecho do mês
Com o fim de outubro a aproximar-se, há uma oportunidade simples: rever as horas antes de preparar a faturação. O dia 31 é aqui uma referência operacional ao fecho do mês civil, não um prazo fiscal universal.
Escolhe registos em que já conheces o destino correto. Inclui trabalho coberto por contrato, uma intervenção extra para o mesmo cliente e um caso realmente ambíguo. Neste último, o comportamento esperado não é acertar por sorte: é pedir a informação que falta.
Se testares uma futura gravação, começa num ambiente de teste devidamente isolado. Confere o registo dentro do ERP, não apenas a resposta do assistente. As horas devem aparecer na tarefa e na linha previstas, com a identidade e a duração corretas. Não avances se o sistema escolher pelo nome aproximado do cliente ou se não conseguires explicar por que razão usou aquela linha.
O resultado que procuras é pequeno e concreto: duas horas, no trabalho certo, com o destino comercial verificável. A conversa é apenas a entrada.
Envia para hello@leiritech.com um exemplo anonimizado de uma mensagem de horas e das linhas de venda possíveis no teu ERP. O primeiro passo é verificar se existe informação suficiente para distinguir os destinos — antes de prometer qualquer automatização.
