Um projeto Odoo que derrapa raramente falha por uma única razão. Falha por acumulação: um módulo desenvolvido à pressa, uma importação de dados mal limpa, uma versão que ninguém atualizou, um integrador que deixou de responder. Uma auditoria Odoo serve para transformar a sensação de «isto não anda» numa lista objetiva de problemas, ordenados por gravidade e por custo de correção.
Esta página explica quando a auditoria se impõe, o que se examina, como funciona uma reprise de projeto Odoo e como mudar de integrador Odoo sem perder o que já foi feito. O objetivo é que chegue à conversa com um novo integrador a saber o que pedir.
Sinais de que o seu projeto Odoo precisa de uma auditoria
Nenhum sinal, isolado, é condenatório. A combinação de vários é que deve levar a agir.
- Os utilizadores fogem do sistema. A faturação continua em Excel, o stock é confirmado «à mão» e a contabilista recebe ficheiros em vez de lançamentos.
- O projeto não fecha. Cada fase é dada como quase terminada, mas a entrada em produção é adiada sem causa técnica explicada.
- Cada correção cria outro problema. Sinal clássico de desenvolvimentos mal isolados ou de paramétrico contraditório.
- A lentidão é crónica. Listagens que demoram, relatórios que bloqueiam a base, tarefas agendadas que se atropelam.
- Ninguém sabe dizer o que está feito. Não existe documentação, e o conhecimento está na cabeça de uma só pessoa do lado do integrador.
- A relação azedou. Respostas tardias, faturação de horas pouco detalhada, escalamento sem resposta.
- A versão está a ficar para trás. A sua instalação aproxima-se do fim do suporte e ninguém planeou a atualização.
Se reconhece três ou mais, uma auditoria sai mais barata do que continuar a pagar horas a corrigir sintomas.
O que uma auditoria Odoo examina
Uma boa auditoria é um trabalho de leitura e de medição, não de correção. Cobre seis frentes, e o relatório final deve tratar cada uma separadamente.
Parametrização e processos
Verifica-se se os módulos instalados correspondem aos processos reais da empresa: circuitos de compra e venda, regras de preço, armazéns e localizações, tipos de documento, impostos e posições fiscais. Procuram-se parametrizações redundantes, módulos instalados e nunca usados, e circuitos que obrigam os utilizadores a passos manuais que o Odoo faria sozinho. Pode comparar com a oferta funcional descrita nas páginas sobre módulos e processos do Odoo tal como se aplicam em Portugal.
Qualidade dos dados
É aqui que muitos projetos escondem o problema. Examinam-se duplicados de clientes, fornecedores e artigos, contas contabilísticas mal atribuídas, saldos iniciais que não batem com a contabilidade, unidades de medida incoerentes e histórico importado com campos truncados. Dados maus contaminam relatórios, inventários e fecho de contas, e nenhum desenvolvimento os corrige.
Desenvolvimentos à medida
Cada módulo específico é revisto: está num repositório versionado, tem testes, depende de quê, altera o comportamento nativo ou acrescenta-lhe algo? A pergunta decisiva é se esse código sobreviverá à próxima atualização. Um módulo que reescreve partes do núcleo é uma dívida; um módulo que se limita a estender é gerível. O tema é desenvolvido na página sobre personalização e desenvolvimento em Odoo.
Desempenho e infraestrutura
Analisam-se os registos do servidor, as consultas lentas, a dimensão e a organização da base de dados, as cópias de segurança e, sobretudo, o teste de restauro. Uma cópia de segurança que nunca foi restaurada é uma hipótese, não uma garantia. Verifica-se também onde está alojada a instalação e quem tem acesso de administrador.
Segurança e conformidade
Revêem-se os perfis de acesso, as contas partilhadas, as palavras-passe de administrador, o acesso a dados sensíveis (recursos humanos, margens) e as ligações a sistemas externos. Em Portugal, acrescenta-se o que é específico do país: a emissão de documentos de faturação por programa certificado, o ficheiro SAF-T (PT), o ATCUD e o código QR nos documentos, e o fecho de períodos com o contabilista certificado. Um Odoo que não gera estes elementos corretamente é um risco fiscal, não um simples defeito.
Versão, licenciamento e suporte
Confirma-se qual a versão em produção e em que fase do ciclo de suporte se encontra. Segundo a página de versões suportadas da Odoo, a versão 17.0 saiu em novembro de 2023 e o seu suporte standard terminou em setembro de 2026; a 18.0, de outubro de 2024, vai até setembro de 2027; a 19.0, de setembro de 2025, até setembro de 2028. As correções de segurança só são fornecidas durante o suporte standard, e o suporte alargado, pago, só existe no Odoo.sh e em instalação própria. Para uma empresa que ficou numa versão antiga, isto muda o calendário de decisão.
Verifica-se ainda o licenciamento: a edição Community está sob LGPLv3, mas a Enterprise só pode ser usada com uma subscrição válida para o número certo de utilizadores. Convém confirmar quem conta como utilizador pago (os que têm acesso ao backend; os utilizadores de portal, como clientes e fornecedores, não contam) e se as funcionalidades usadas, como o Odoo Studio ou a gestão de várias sociedades, correspondem ao plano contratado.
Resumo: sintoma, causa provável e o que a auditoria confirma
| Sintoma observado | Causa provável | O que a auditoria verifica |
|---|---|---|
| Folhas de cálculo em paralelo | Processo mal parametrizado ou formação insuficiente | Fluxos reais versus fluxos configurados |
| Relatórios que não batem com a contabilidade | Dados iniciais ou plano de contas incoerentes | Saldos de abertura, contas, posições fiscais |
| Erros após cada alteração | Desenvolvimentos acoplados ao núcleo | Estrutura e dependências dos módulos |
| Sistema lento | Consultas pesadas, base mal dimensionada | Registos, índices, tarefas agendadas |
| Medo de atualizar | Código à medida sem testes | Compatibilidade com a versão seguinte |
| Dependência de uma pessoa | Ausência de documentação e de código acessível | Repositório, acessos, documentação |
Reprise de projeto Odoo: o que muda em relação a um projeto novo
Retomar não é recomeçar com outro nome. Num projeto novo, o integrador parte de requisitos e constrói. Numa retoma, parte de um existente, e a primeira pergunta é o que se pode manter sem risco.
Uma retoma bem conduzida segue três princípios.
- Congelar antes de mexer. Faz-se uma cópia completa da base e do código, e nada de novo entra em produção enquanto o diagnóstico não estiver fechado.
- Separar o que funciona do que não funciona. Dados limpos e parametrização estável conservam-se; desenvolvimentos frágeis reescrevem-se ou substituem-se por funcionalidade nativa.
- Voltar a dar confiança aos utilizadores. Uma retoma que corrige a técnica mas ignora a equipa falha pela mesma razão que o projeto original. Planeie formação e pontos de acompanhamento nos primeiros ciclos de utilização.
Muitas vezes, a retoma é também o momento certo para decidir o que vem a seguir: atualizar de versão, rever a migração de dados ou reorganizar o alojamento.
Mudar de integrador Odoo sem tudo recomeçar
A dúvida mais comum é esta: «se mudar, perco o que já paguei?». Em regra, não, desde que os ativos certos sejam recuperados. A base de dados é sua, o código desenvolvido para si deve estar coberto pelo contrato, e a licença Odoo está associada à sua empresa, não ao integrador.
Documentos e acessos a recuperar
| Item | Porque é essencial |
|---|---|
| Acesso de administrador à base de dados e ao alojamento | Sem ele, ninguém audita nem recupera nada |
| Repositório com o código dos módulos à medida | O código é o ativo que paga o investimento já feito |
| Caderno de requisitos e atas de decisão | Mostram o que foi acordado e o que foi desviado |
| Documentação de parametrização | Evita reconstituir regras por tentativa e erro |
| Scripts e ficheiros de importação de dados | Permitem repetir ou corrigir cargas |
| Credenciais e descrição das ligações a outros sistemas | Banco, transportadoras, loja online, ver integrações |
| Contrato Odoo e dados de faturação da subscrição | Provam a propriedade da licença |
| Registo de pendências e de erros conhecidos | Ponto de partida da lista de correções |
Peça tudo por escrito e antes de formalizar a saída. Se o integrador atual se recusar a entregar o código ou os acessos, releia o contrato: a propriedade dos desenvolvimentos e das credenciais deve estar prevista. Em caso de litígio, o conselho jurídico é do seu advogado; do lado técnico, o que conta é ter provas de que a instalação lhe pertence.
Como escolher quem retoma
Quem retoma deve começar por uma auditoria curta e paga, com relatório entregue, antes de propor um orçamento de correção. Desconfie de quem promete um preço fechado sem ter visto o código nem os dados. Um bom critério é a capacidade de dizer o que não vale a pena corrigir. Os critérios de seleção gerais estão em como escolher um parceiro Odoo e a lógica de pedido de propostas na página sobre como funciona a ligação a um integrador. O programa de parceiros da Odoo exige certificação e formação do pessoal e o apoio de primeiro nível, o que ajuda a pedir provas concretas de competência sem recorrer a nomes.
Plano de redressamento: por onde começar
Depois do relatório de auditoria, o plano faz-se por prioridades e não por módulos.
- Estabilizar. Cópias de segurança testadas, acessos limpos, contas partilhadas eliminadas, ambiente de teste separado da produção.
- Proteger o fiscal. Garantir que a faturação, o SAF-T (PT) e a comunicação com a Autoridade Tributária funcionam sem intervenção manual. Esta frente não espera.
- Limpar os dados. Duplicados, saldos, artigos, contas. Sem isto, qualquer relatório continua a mentir.
- Tratar a dívida técnica. Reescrever o que está mal desenhado, substituir desenvolvimentos por funcionalidade nativa quando existe, documentar o resto.
- Pôr a versão em dia. Definir o caminho de atualização. No Odoo Online e no Odoo.sh a atualização para uma versão principal é obrigatória de dois em dois anos, com aviso prévio, e a documentação prevê a obtenção de uma base de teste atualizada para validar a nova versão antes da passagem a produção. Consulte versões e edições para escolher o alvo.
- Organizar a vida após o projeto. Contrato de suporte e manutenção com âmbito e tempos de resposta escritos, e responsável interno designado.
Cada etapa termina com um critério de aceitação verificável: o que muda para o utilizador, quem valida e em que ambiente.
O que fazer do lado da empresa
A auditoria não é só um trabalho do integrador. A direção precisa de designar um responsável interno, de disponibilizar o contabilista certificado e os utilizadores-chave para entrevistas, e de decidir previamente o que é prioritário: reduzir risco fiscal, ganhar produtividade ou preparar o crescimento. Sem esta decisão, a auditoria devolve uma lista longa e nenhuma ordem.
Convém também reler os erros típicos de projetos ERP, resumidos em por que falham os projetos ERP: muitos reaparecem numa retoma se não forem nomeados logo no início.
Em síntese
Uma auditoria Odoo não é um ato de desconfiança contra o integrador; é o instrumento que permite decidir com factos. Corrija o que é localizado, conserve o que está bem, recupere os seus acessos e o seu código, e só então escolha quem leva o projeto até ao fim. O serviço de ligação que apresentamos é gratuito e não implica compromisso: descreve-se a situação, e a proposta chega de um integrador adequado ao seu caso.
Perguntas frequentes
Quando é que uma auditoria Odoo se justifica?
Justifica-se quando os utilizadores contornam o sistema com folhas de cálculo, quando os prazos do projeto derrapam sem explicação clara, quando cada alteração parte outra coisa ou quando a versão se aproxima do fim do suporte. Também faz sentido antes de uma mudança de integrador, para saber exatamente o que se herda.
Posso mudar de integrador Odoo a meio do projeto?
Sim, e é mais frequente do que se pensa. A condição é recuperar o código dos desenvolvimentos, a documentação do paramétrico, o acesso de administrador à base e ao alojamento, e a lista do que foi prometido. Com isso, o novo integrador começa por uma auditoria e propõe um plano de retoma em vez de recomeçar do zero.
A auditoria obriga a parar a utilização do Odoo?
Não necessariamente. A análise faz-se sobretudo sobre uma cópia da base de dados e do código, num ambiente de teste, sem tocar na produção. Só os testes de carga ou de restauro exigem coordenação com a equipa, e fazem-se fora das horas de maior utilização.
Que documentos devo exigir ao integrador que sai?
Os acessos de administrador à base de dados e ao alojamento, o repositório do código dos módulos desenvolvidos à medida, o caderno de requisitos, as atas e as decisões de parametrização, os scripts de importação de dados e as credenciais das ligações a outros sistemas. Sem o código e os acessos, a retoma fica refém de quem saiu.
Uma auditoria Odoo pode concluir que é preciso recomeçar?
Pode, mas é raro quando a base é razoável. Na maioria dos casos conclui-se que se conserva o que está bem (dados, parametrização estável), se corrige o que é localizado e se reescreve apenas o que está mal desenhado. Recomeçar justifica-se quando a base de dados e os desenvolvimentos estão de tal forma acoplados que a atualização de versão deixa de ser viável.
Fontes
Os nomes de software mencionados são marcas dos respetivos editores, citadas a título meramente informativo. Este site é independente e não é afiliado a nenhum editor.