Implementação Odoo: da auditoria inicial ao go-live

Implementar Odoo não consiste em instalar módulos e preencher alguns parâmetros. É um projeto que toca a forma como a empresa fatura, recebe, declara o IVA e, muitas vezes, paga os salários. Na Suíça, estes três temas — contabilidade, IVA, salários — estão enquadrados por regras precisas, e uma configuração que os ignore no momento da definição paga-se no primeiro encerramento, não antes. É a diferença entre um integrador que instala um software e uma fiduciária que pensa a implementação a partir daquilo que a contabilidade tem de produzir no final.

Esta página descreve o método que seguimos, fase a fase, desde a auditoria prévia até ao suporte que se segue à entrada em produção. Trata também, sem rodeios, o que faz falhar ou descarrilar um projeto ERP: são causas conhecidas, recorrentes, e evitáveis se forem antecipadas.

Quando uma empresa está pronta para o Odoo — e quando ainda não está

O Odoo faz sentido assim que uma empresa gere vários processos que hoje não comunicam entre si: faturação numa ferramenta, stock numa folha de cálculo, salários junto de terceiros, sem visão de conjunto. O sinal mais claro é a reintrodução manual — a mesma informação escrita duas ou três vezes em ferramentas diferentes — e a ausência de visibilidade em tempo real sobre a tesouraria ou as margens.

Pelo contrário, alguns sinais indicam que vale mais esperar ou primeiro resolver um problema a montante:

• Os processos atuais não estão estabilizados. Se a empresa ainda muda regularmente a forma de faturar ou de gerir as compras, informatizar um processo instável equivale a fixar a desordem.
• Ninguém pode ser libertado para pilotar o projeto do lado do negócio. Sem um responsável interno disponível, as decisões de configuração tomam-se por defeito, muitas vezes mal, e corrigem-se mais tarde a maior custo.
• Os dados de origem estão em muito mau estado (duplicados massivos, plano de contas incoerente, nenhum histórico fiável) e ninguém está pronto para os limpar antes do projeto.
• A empresa atravessa uma reorganização importante (fusão, mudança de forma jurídica, reestruturação) que vai de qualquer forma alterar os processos nos meses seguintes.

Nestes casos, a melhor decisão é por vezes adiar o projeto alguns meses em vez de o iniciar num terreno instável. Uma auditoria prévia permite decidir objetivamente.

A auditoria prévia

Antes de qualquer configuração, documentamos a situação existente:

• Processos em vigor: como circulam hoje os orçamentos, encomendas, faturas, pagamentos e salários, e quem intervém em cada etapa.
• Ferramentas atuais: software de contabilidade, de faturação, de salários, folhas de cálculo, e a forma como se articulam — ou não — entre si.
• Dados: onde residem, em que formato, o seu grau de limpeza (duplicados, campos incompletos, incoerências no plano de contas).
• Volumes: número de clientes, de fornecedores, de referências de produtos, de lançamentos anuais, de colaboradores — estes números determinam a complexidade da migração de dados e dos testes.
• Condicionantes regulatórias próprias da atividade: sujeição ao IVA (taxas aplicáveis, método de liquidação), obrigações setoriais, convenções coletivas que influenciam os salários.

Esta auditoria produz uma visão clara do que existe e do que tem de mudar — é a base da definição que se segue, não uma formalidade.

A definição: âmbito, módulos, o que se adia

A definição traduz a auditoria num âmbito de projeto concreto. É a etapa onde se decide grande parte do sucesso ou do fracasso posterior do projeto, porque fixa o que tem de funcionar no arranque e o que pode esperar.

Definir o âmbito da primeira fase

A regra mais útil é simples de enunciar e difícil de cumprir: começar com o âmbito mais restrito que cubra as necessidades reais de funcionamento da empresa, não o âmbito mais completo possível. Um projeto que tenta cobrir contabilidade, IVA, salários, CRM, inventário e desenvolvimentos específicos logo no primeiro dia multiplica os pontos de decisão, os testes e as pessoas a mobilizar em paralelo — e atrasa precisamente o momento em que a base financeira é fiável.

Escolher os módulos

A escolha dos módulos decorre diretamente do âmbito definido. Para a maioria das PME, a base inicial cobre a contabilidade, a faturação e as compras básicas. Consoante a atividade, acrescenta-se desde o início o CRM e a gestão comercial, a gestão de stocks e compras, ou os salários e recursos humanos — mas apenas se estes blocos forem indispensáveis ao funcionamento quotidiano, não porque existem no catálogo do Odoo.

O que se adia voluntariamente

Documentar explicitamente o que é adiado, e porquê, evita dois erros: a impressão de que algo foi esquecido, e a tentação de o acrescentar às pressas a meio do projeto. São tipicamente adiados para uma fase posterior: as integrações com ferramentas externas não críticas, os relatórios personalizados avançados, os módulos de e-commerce ou de gestão de projetos quando não condicionam o funcionamento de base, e qualquer personalização que ainda não tenha demonstrado a sua necessidade depois de a ferramenta standard estar em uso.

A configuração

Uma vez validado o âmbito, a configuração estabelece as fundações técnicas e organizacionais do sistema:

• Empresa: firma, forma jurídica, dados de contacto, moeda de base, exercício contabilístico.
• Plano de contas: estrutura das contas, agrupamentos, contas de balanço e de demonstração de resultados adaptadas à atividade real — não apenas o plano por defeito.
• Posições fiscais e IVA: associação das contas e dos produtos às taxas corretas, gestão das operações isentas ou no estrangeiro, método de liquidação (efetivo ou taxa da dívida fiscal líquida consoante a elegibilidade).
• Diários: vendas, compras, banco, operações diversas, com as sequências de numeração e as contas de contrapartida corretas.
• Contas bancárias: associação das contas reais, formatos de importação dos extratos, configuração da fatura QR para a emissão e receção de pagamentos.
• Direitos de acesso: quem pode ver, introduzir, alterar ou validar cada tipo de documento, por perfil de utilizador.
• Fluxos de validação: circuitos de aprovação das faturas de fornecedores, das notas de despesas, das encomendas de compra, consoante os limites e as responsabilidades internas.

Este trabalho de configuração é a parte menos visível do projeto e a mais determinante para a fiabilidade dos números produzidos em seguida.

A localização suíça: verificar e completar, não apenas instalar

O Odoo instala automaticamente o módulo de localização suíça (l10n_ch) assim que a empresa é configurada com a Suíça como país. Este módulo estabelece uma base útil: estrutura de plano de contas adaptada aos usos suíços, taxas de IVA correntes (8,1 %, 2,6 % e 3,8 %, em vigor desde 1 de janeiro de 2024), e suporte à fatura QR, standard suíço de pagamento.

O trabalho de implementação não termina aí — começa precisamente nesse momento. Esta base genérica tem de ser:

• Verificada conta a conta, para confirmar que corresponde à estrutura real da atividade e não a um modelo genérico.
• Adaptada às posições fiscais efetivas: taxas aplicáveis consoante as prestações, método de liquidação do IVA, incluindo a verificação da elegibilidade aos limiares da taxa da dívida fiscal líquida (volume de negócios máximo de CHF 5'024'000 e imposto devido máximo de CHF 108'000 por ano, em vigor desde 1 de janeiro de 2025 segundo a AFC).
• Completada de acordo com os diários, as contas bancárias e os fluxos reais da empresa — a localização de base não conhece nem as suas contas bancárias, nem a sua organização interna.

É precisamente nesta etapa que se nota a diferença entre um integrador generalista e uma fiduciária: uma localização tecnicamente instalada mas não verificada no essencial produz números que parecem corretos até ao primeiro encerramento de IVA, onde os desvios aparecem. Para tudo o que diz respeito à contabilidade corrente uma vez o sistema em funcionamento, ver a nossa página de contabilidade Odoo.

A migração dos dados

A migração de dados responde a três questões distintas, que devem ser decididas separadamente.

O que se migra

Em geral: as fichas de clientes e fornecedores ativos, o catálogo de produtos, as faturas em aberto (ainda não recebidas ou pagas), os saldos de abertura na data da mudança, e os dados necessários à continuidade operacional imediata (stock presente, contratos em curso).

O que não se migra sistematicamente

O histórico contabilístico detalhado dos exercícios encerrados geralmente não precisa de ser reintroduzido lançamento a lançamento no Odoo. Continua acessível no sistema anterior ou arquivado em formato PDF, o que satisfaz as obrigações legais de conservação sem sobrecarregar a migração. Da mesma forma, as fichas de clientes ou fornecedores inativos há muito tempo, ou os dados cuja fiabilidade é duvidosa, ficam muitas vezes voluntariamente de fora em vez de serem migrados «por precaução».

A data de mudança

Escolhe-se em função do calendário contabilístico da empresa — na maioria das vezes no início do exercício ou de um período de IVA, para evitar dividir um período entre dois sistemas diferentes. Os saldos de abertura nessa data são estabelecidos com rigor: são eles que garantem a continuidade contabilística entre o sistema anterior e o Odoo. Para um projeto em que o sistema de origem já está identificado e documentado, ver a nossa página dedicada à migração de dados.

Desenvolvimentos e integrações, se necessários

O Odoo standard cobre a maioria das necessidades de uma PME. Um desenvolvimento específico ou uma integração com uma ferramenta externa (site de e-commerce, caixa registadora, software setorial) só se justifica quando o standard realmente não responde à necessidade — não por princípio. Cada desenvolvimento acrescenta uma dependência que terá de ser mantida nas futuras atualizações de versão; documentamos sistematicamente o que é desenvolvido à medida e porquê, para que essa escolha permaneça rastreável ao longo do tempo.

Por prudência metodológica, qualquer desenvolvimento não estritamente indispensável ao funcionamento da primeira fase é adiado: uma personalização prematura, decidida antes de as equipas terem usado o sistema standard, baseia-se muitas vezes num hábito da ferramenta anterior em vez de numa necessidade real no Odoo.

Os testes e a validação

A validação confirma que o sistema configurado produz resultados corretos antes de a empresa transferir para ele as suas operações reais.

• Testes de dados: dados representativos, construídos a partir de casos reais da empresa, não dados genéricos.
• Cenários de negócio: percursos completos — da encomenda ao recebimento, da receção de uma fatura de fornecedor ao seu pagamento, do cálculo de um salário ao seu decompte — testados de ponta a ponta, não função a função isoladamente.
• Validação contabilística: controlo dos balancetes, das reconciliações bancárias e de uma simulação de liquidação de IVA antes da mudança definitiva. É o controlo com mais valor, porque é o que revela uma configuração fiscal ou contabilística mal calibrada antes de esta produzir um número oficial.

A validação é conduzida com os utilizadores que realmente usarão o sistema no dia a dia, não apenas com o responsável de projeto — são eles que detetam os desvios entre a configuração teórica e o uso real.

A formação dos utilizadores, por perfil

Uma formação genérica, igual para todos, deixa cada um desenrascar-se com as funções que não lhe dizem respeito e negligencia aquelas de que realmente precisa. A formação é, por isso, construída por perfil:

• Contabilidade e finanças: introdução, reconciliação, rapprochement bancário, encerramento periódico, liquidação de IVA.
• Vendas e faturação: orçamentos, encomendas, faturação, acompanhamento dos recebimentos.
• Compras e stock, se este âmbito for retido: encomendas a fornecedores, receções, inventário.
• Recursos humanos, se os salários estiverem no âmbito: gestão dos processos dos colaboradores, ciclo de salários, decomptes sociais.
• Direção: leitura dos painéis de indicadores, sem necessariamente a introdução operacional.

Negligenciar a formação é uma causa de falha tão frequente como uma configuração técnica deficiente: um sistema bem configurado mas mal compreendido gera erros de introdução que, esses sim, produzem números errados. O detalhe da nossa abordagem de formação é apresentado na página de formação Odoo.

O go-live e o período de estabilização

O go-live é o momento em que a empresa transfere definitivamente as suas operações para o Odoo. É precedido de um congelamento das introduções no sistema anterior enquanto se finaliza a migração de dados, e seguido de um período de estabilização durante o qual os primeiros ciclos reais — primeira faturação, primeira reconciliação bancária, primeiro encerramento de IVA — fazem emergir desvios que nenhuma validação, por cuidada que seja, deteta inteiramente com antecedência. Este período é planeado como uma fase do projeto, com um acompanhamento reforçado, e não tratado como uma sucessão de incidentes imprevistos.

O suporte e a melhoria contínua

Uma vez ultrapassada a estabilização, a empresa passa para um suporte corrente: questões de utilização, correções de configuração menores, acompanhamento dos encerramentos periódicos, evoluções modestas conforme as necessidades constatadas. É também o momento em que os módulos e funcionalidades voluntariamente adiados na definição inicial podem ser reavaliados e acrescentados, sobre uma base agora estável. Ver a nossa oferta de suporte Odoo para o detalhe deste acompanhamento contínuo.

O que faz variar a duração e o orçamento de um projeto

Não damos um intervalo genérico de duração ou de custo: dependeria de pressupostos que ainda não conhecemos no momento de escrever esta página. Em contrapartida, os fatores que fazem variar um projeto de implementação Odoo, para cima como para baixo, são identificáveis:

• O âmbito definido: número de módulos ativados na primeira fase, número de empresas ou entidades legais a configurar.
• O estado dos dados de origem: dados limpos e estruturados migram-se depressa; dados dispersos, incoerentes ou duplicados exigem um trabalho de limpeza prévio que pode pesar mais do que a própria configuração.
• A disponibilidade do responsável interno: um projeto em que as decisões se tomam rapidamente avança regularmente; um projeto em que cada validação espera várias semanas estende-se na mesma proporção.
• O volume de desenvolvimentos específicos: cada personalização acrescenta um ciclo de especificação, de desenvolvimento e de teste que se soma à configuração standard.
• A complexidade regulatória da atividade: várias taxas de IVA, atividade internacional, convenções coletivas específicas para os salários, várias empresas — cada um destes elementos acrescenta casos a configurar e a testar.
• A edição escolhida, Community ou Enterprise: esta escolha influencia tanto as funcionalidades disponíveis desde logo como o modelo de custo recorrente por utilizador.
• A versão do Odoo instalada: o Odoo 19 é a versão estável atual; uma versão recente beneficia de um suporte do editor mais longo, o que limita as atualizações de versão forçadas a curto prazo.

É precisamente para pesar estes fatores na sua situação real, e não num caso genérico, que o projeto começa por uma auditoria e uma definição documentadas — não por um orçamento estabelecido antes de termos visto os seus processos. Se a sua empresa está sediada em Genebra ou na região, ver também o nosso acompanhamento Odoo em Genebra.