Período fechado no ERP: qual foi a data do lançamento?
«Pedi para lançar em outubro. Porque é que isto aparece em novembro?»
Quando estás a conferir o fecho, não precisas de uma mensagem simpática a dizer que ficou tudo tratado. Precisas de saber que data ficou no lançamento, em que estado está e que regra impediu o registo no período pedido. Se a conversa diz outubro e o ERP diz novembro, a conversa não serve de prova.
O problema surge quando chega um documento atrasado, quando alguém regista hoje uma operação do mês anterior ou quando o fecho acontece entre o pedido e a execução. O ERP pode recusar a operação ou ajustar a data contabilística segundo as suas regras. Um assistente que repete a intenção do utilizador, sem verificar o resultado, esconde precisamente a diferença que a contabilidade precisa de conhecer.
Um pedido não é um lançamento confirmado
Há três afirmações diferentes: «percebi que queres outubro», «enviei um pedido com uma data de outubro» e «o ERP confirmou um lançamento com uma data de outubro». Só a última descreve o resultado contabilístico, e mesmo essa exige distinguir um rascunho de um lançamento confirmado.
A documentação do Odoo 19 dá um exemplo concreto. O bloqueio designado Lock Everything impede alterações em lançamentos confirmados com data igual ou anterior à data de bloqueio. Também impede confirmar novos lançamentos nesse período; nesses casos, a documentação descreve o ajuste automático da data contabilística para o dia seguinte ao bloqueio.
Isto não significa que todos os ERPs se comportem da mesma maneira. Nem que qualquer documento no Odoo tenha exatamente o mesmo percurso, independentemente da localização, configuração ou permissões. Significa que existe uma regra documentada capaz de separar a data que pediste da data usada pelo sistema. A integração tem de conhecer e testar esse comportamento na instalação concreta.
Não basta guardar no histórico da conversa que o utilizador escreveu «31 de outubro».
Quatro datas que não deves tratar como uma só
A data do documento identifica o documento de origem. A data contabilística determina onde o lançamento entra nos relatórios que usam esse campo. A data e hora de criação dizem quando o registo entrou no sistema. A data pedida é apenas a intenção expressa na conversa.
Podem coincidir. Não são equivalentes.
Uma fatura datada de outubro pode chegar à equipa em novembro. O respetivo registo pode ser criado em novembro e receber uma data contabilística condicionada pelo bloqueio existente. Isto não autoriza o assistente a alterar a data de emissão, a decidir o tratamento de IVA ou a escolher sozinho o período fiscal adequado. Essas decisões pertencem ao processo contabilístico e às regras aplicáveis.
A distinção também muda a pergunta que fazes ao ERP. «O que entrou em novembro?» pode significar documentos criados nesse mês ou valores contabilizados nesse período. Se o assistente escolher o campo errado, pode devolver uma lista tecnicamente correta para uma pergunta que não fizeste.
Uma integração útil esclarece qual das datas está a usar, em vez de esconder essa escolha numa resposta fluente.
Exemplo: pediste 31 de outubro, ficou 1 de novembro
Considera este cenário ilustrativo, não um caso de cliente: em 3 de novembro, um operador pede o registo de um lançamento de 1.200 euros com data contabilística de 31 de outubro. A empresa tem o período bloqueado até 31 de outubro, inclusive. Não existe uma exceção autorizada aplicável à operação.
Num percurso sujeito ao comportamento descrito no Odoo 19, a data contabilística passa para 1 de novembro. O montante não mudou. A data pedida também não mudou no histórico da conversa. Mudou o resultado que interessa ao relatório.
| Elemento | Valor no exemplo |
|—|—|
| Data contabilística pedida | 31 de outubro |
| Bloqueio aplicável | Até 31 de outubro, inclusive |
| Dia de criação do registo | 3 de novembro |
| Data contabilística efetiva | 1 de novembro |
| Montante do lançamento | 1.200 euros |
Se uma consulta filtrar exclusivamente pela data contabilística, este lançamento fica fora de outubro e dentro de novembro. Não estamos a afirmar que as contas finais devam ficar assim sem qualquer avaliação adicional. Estamos a mostrar por que motivo «registado com sucesso» não responde à pergunta «entrou em outubro?».
A resposta útil seria: «Pediste 31 de outubro. O lançamento consultado está confirmado com data contabilística de 1 de novembro. O bloqueio consultado abrange até 31 de outubro. O período não foi reaberto.» Deveria acompanhar essa explicação a referência interna do lançamento e o momento da consulta.
Se a informação disponível só mostrar o resultado, mas não a regra aplicada à execução, há um limite importante: o assistente pode confirmar a data de novembro, mas não deve inventar a causa. Um bloqueio observado hoje pode não ser o bloqueio que existia quando a operação ocorreu. Para provar essa relação, é necessário histórico suficiente.
A operação aconteceu num dia; o registo pode chegar depois
No armazém, uma receção física pode acontecer em 30 de outubro e ser introduzida no sistema em 2 de novembro. A pergunta sobre quando a mercadoria chegou não se responde necessariamente com a data de criação do registo. A pergunta sobre o lançamento contabilístico associado exige ainda outro campo. Misturar as duas respostas pode esconder uma diferença no fecho.
Num laboratório de calibração, a data de execução do serviço não é automaticamente a data do documento comercial nem a data contabilística. O assistente deve conseguir identificar o serviço e consultar o registo financeiro associado, quando essa ligação existe. Se não existe, não deve concluir que o serviço já foi contabilizado só porque foi concluído tecnicamente.
Na saúde ou num lar, a data de prestação de um serviço e a data do registo administrativo também podem divergir. A consulta financeira deve usar apenas a informação necessária e autorizada; não precisa de expor dados clínicos para explicar em que período entrou um valor.
Na faturação eletrónica, emitir ou comunicar um documento e contabilizá-lo são estados distintos. Uma confirmação de comunicação à autoridade competente não demonstra, por si só, a data contabilística usada no ERP. O conector deve consultar a evidência adequada a cada pergunta, sem transformar uma resposta fiscal numa confirmação contabilística.
O princípio é sempre o mesmo: preservar a data do acontecimento, identificar a data do registo e confirmar qual delas alimenta o relatório em discussão.
O que um assistente só de leitura já consegue resolver
Não é preciso dar permissões de escrita para responder a «em que mês ficou este lançamento?». Uma integração só de leitura pode consultar o documento, o lançamento associado, o estado, a data contabilística e o bloqueio acessível. Deve fazê-lo dentro das permissões do utilizador e da empresa correta.
O modelo de linguagem interpreta a pergunta e apresenta o resultado. A consulta estruturada ao ERP fornece os valores. A aplicação controla que operações são permitidas e regista o acesso. O modelo não ganha autoridade contabilística por conseguir explicar uma regra.
É este o sentido prático de uma resposta fundamentada nos teus dados: a data vem do campo do lançamento identificado, não de uma previsão do modelo nem de um manual genérico. Uma pesquisa em documentos pode ajudar a explicar o fecho; não substitui a consulta do estado real do registo.
Se o acesso não permitir consultar o bloqueio, a resposta deve separar o que sabe do que falta: «Confirmei a data contabilística de 1 de novembro; não tenho acesso à regra de bloqueio aplicável.» É menos elegante do que uma explicação completa. É bastante mais útil do que uma explicação inventada.
Na Leiritech, o acesso conversacional aos dados é proposto com leitura, controlo de acesso e auditoria. Uma eventual capacidade de escrita é outro âmbito de trabalho, não uma consequência automática de ligares o WhatsApp ao ERP. Este exemplo descreve requisitos de integração; não apresenta um conector Odoo específico já entregue.
Se houver escrita, a prova vem depois da execução
Num projeto que inclua escrita, com autorização explícita e âmbito contratado, a integração deve usar os métodos de negócio suportados pelo ERP. Pode identificar antecipadamente um conflito de datas, mas não deve prometer o resultado apenas com base nessa verificação: o estado do período pode mudar entretanto.
Depois da execução autorizada, tem de confirmar o estado devolvido e consultar o registo resultante. Só então pode distinguir «foi criado um rascunho», «o lançamento ficou confirmado com outra data» e «a operação foi recusada».
Se houve uma mudança face ao pedido, essa diferença tem de aparecer na resposta. Se a alteração exige nova decisão do responsável, o processo deve parar nesse ponto. Não se resolve um conflito contabilístico com uma reformulação simpática da mensagem.
O rasto de auditoria deve permitir reconstruir quem pediu, em que empresa, que registo foi consultado, que data foi pedida e que resultado foi confirmado. Uma alteração posterior deve ficar distinguível da observação original. Guardar apenas «sucesso» não permite explicar por que razão o fecho mudou.
«Mas não basta mandar o assistente reabrir o mês?»
Não. Se o período está fechado, existe uma decisão de controlo por trás desse estado. Transformar um pedido informal numa reabertura elimina precisamente a separação entre quem pede uma operação e quem pode alterar as condições do fecho.
O Odoo 19 documenta mecanismos de exceção para administradores da contabilidade e distingue-os de um bloqueio definitivo não reversível. A existência desses mecanismos não é uma recomendação para os expor num chat. Uma exceção deve seguir o processo autorizado da empresa e deixar o respetivo registo.
Também não compete ao assistente concluir que novembro é contabilisticamente aceitável só porque o ERP aceitou essa data. O sistema demonstra o que aconteceu. O responsável contabilístico decide se é necessário algum tratamento adicional.
A diferença para um bot de 25 euros está nesta verificação
Na oferta publicada em junho de 2026, a 3HASH anunciava 15 euros mensais pelo assistente do site e mais 10 pelo WhatsApp: 25 euros por mês, com 100 euros de implementação, IVA incluído. A descrição desse pacote não identificava integração ERP incluída. Isso não prova que a empresa não a consiga desenvolver.
Um assistente de perguntas frequentes pode explicar muito bem o que é um período fechado. O preço baixo não torna essa função inútil. Mas explicar a regra e confirmar que um lançamento concreto ficou em novembro são serviços diferentes.
A lacuna está no segundo: identificar o registo certo, respeitar permissões, distinguir datas, verificar o estado e apresentar prova. Ter uma API ou um fluxo visual também não garante tudo isto. A comparação justa não é entre duas mensagens de WhatsApp; é entre os resultados que cada integração consegue demonstrar.
O teste a fazer antes do próximo fecho
A 21 de outubro de 2026 faltam dez dias para o fim do mês. É uma boa altura para testar este percurso num ambiente de testes, sem tocar no fecho real. Não é um prazo fiscal universal.
Escolhe um lançamento de teste, uma data anterior ou igual ao bloqueio e outra posterior. Verifica o comportamento com as permissões reais previstas para a integração. A resposta deve mostrar a data pedida, a efetiva e o estado, sem reabrir períodos nem atribuir causas que não consegue provar.
Para avaliar o teu caso, envia para hello@leiritech.com um exemplo anonimizado com o ERP e a versão, a data pedida e a data que ficou registada. O primeiro passo é perceber se o teu sistema permite confirmar essa diferença por consulta auditada. Não é dar ao assistente permissão para a apagar.
