Um desenvolvimento Odoo nunca é uma operação puramente técnica quando toca na faturação, no IVA, nos salários ou na contabilidade. Compromete a empresa a prazo, com obrigações legais suíças que não se negoceiam com um caderno de encargos. No mercado romando, esta realidade opõe frequentemente dois perfis: os integradores que dominam o código do Odoo sem conhecer o plano de contas suíço, a fatura QR ou as normas Swissdec; e as fiduciárias que dominam a contabilidade mas não desenvolvem nada elas próprias, remetendo cada pedido de personalização para terceiros. A AX-Fiduciaire, parceira oficial Odoo, reúne as duas competências na mesma equipa: o desenvolvimento (módulos, campos, workflows, relatórios, conectores) e a experiência fiduciária (contabilidade, IVA, salários, conformidade suíça). Esta página apresenta o nosso desenvolvimento Odoo à medida: o que cobre, o método seguido, e os limites que nós próprios estabelecemos.
Quando um desenvolvimento à medida se justifica
O Odoo standard cobre uma parte alargada das necessidades de gestão de uma PME: contabilidade, faturação, compras, stocks, vendas, recursos humanos. Uma parte destas necessidades resolve-se sem escrever uma linha de código, através da configuração ou do Odoo Studio. Um desenvolvimento à medida só se justifica quando estas opções estão esgotadas: um processo de negócio realmente específico da empresa, uma regra de gestão que o standard não prevê, um conector para um sistema externo que não existe sob nenhuma forma de módulo, ou um documento cuja estrutura não corresponde a nenhum modelo fornecido.
Pelo contrário, um desenvolvimento não se justifica quando:
- a necessidade já está coberta pela configuração standard (campos adicionais, regras de faturação, sequências, direitos de acesso);
- o Odoo Studio permite acrescentar o campo, a vista ou a automatização sem tocar no código-fonte;
- um módulo OCA (Odoo Community Association) existente responde à necessidade, com a vantagem de ser mantido por uma comunidade em vez de um único prestador;
- a necessidade real é uma mudança de hábito de trabalho, não uma limitação do software.
Esta disciplina condiciona a sobrevivência do desenvolvimento ao longo do tempo. Um módulo acrescentado para reproduzir um hábito em vez de responder a uma condicionante real torna-se, na primeira atualização de versão importante, um trabalho suplementar sem justificação clara. O critério determinante não é o número de funções que um desenvolvimento pode acrescentar, mas a sua capacidade de atravessar as futuras versões do Odoo. O Odoo 19 é a versão estável atual; o Odoo 20 é revelado a 24 de setembro de 2026. Cada desenvolvimento à medida deve ser pensado para esta continuidade, não apenas para responder à necessidade do dia.
Esta questão coloca-se com particular acuidade assim que um módulo toca na contabilidade, no IVA ou nos salários. Um campo acrescentado a uma fatura, uma regra de cálculo inserida num workflow de validação, ou uma automatização que altera um lançamento contabilístico nunca são desenvolvimentos anódinos: executam-se em cada transação, muitas vezes sem supervisão humana direta. A pergunta a fazer antes de qualquer desenvolvimento não é apenas «é possível», mas «este desenvolvimento continuará correto daqui a dois anos, com uma equipa diferente, numa versão diferente do Odoo». É esta pergunta, mais do que a viabilidade técnica, que distingue um desenvolvimento pertinente de um desenvolvimento que se tornará um problema.
O que é possível desenvolver no Odoo
O desenvolvimento à medida no Odoo abrange vários níveis, do mais simples ao mais estruturante. Combinam-se frequentemente no mesmo projeto: um conector é quase sempre acompanhado de um novo modelo de dados para armazenar o que recebe, um workflow geralmente altera uma vista para se manter legível.
Módulos
Um módulo Odoo reúne um conjunto coerente de funcionalidades: modelos de dados, vistas, regras de negócio, direitos de acesso. Um módulo à medida instala-se ao lado dos módulos standard sem os alterar, o que limita o impacto nas futuras atualizações de versão. É o nível que privilegiamos por defeito, em vez de intervir diretamente no código dos módulos fornecidos pelo Odoo.
Campos e modelos
Acrescentar um campo a um formulário existente, criar um novo modelo de dados para acompanhar uma informação própria da empresa (um número de processo, uma categoria interna, um estado específico), e ligar essas informações aos modelos existentes — clientes, faturas, encomendas, colaboradores. É muitas vezes o ponto de partida de um desenvolvimento mais alargado: uma vez a informação armazenada, tem de ser exibida, filtrada, e por vezes reportada num documento.
Vistas
Adaptar a apresentação de um formulário, de uma lista ou de um painel para que corresponda ao fluxo de trabalho real da equipa, sem sobrecarregar a interface standard com opções inúteis para os outros utilizadores. Uma vista mal pensada, acrescentada para um único posto de trabalho, acaba muitas vezes por atrapalhar todos os outros.
Workflows e automatizações
Automatizar um encadeamento de etapas — validação, notificação, mudança de estado — segundo regras próprias da empresa, dentro dos limites em que a automatização se mantém compreensível e corrigível por um humano. Uma automatização opaca, que ninguém sabe explicar nem corrigir, representa um risco superior ao ganho de tempo que proporciona.
Relatórios e documentos
Conceber documentos impressos ou em PDF (faturas, boletins, guias de remessa, relatórios de análise) que respeitem uma identidade gráfica ou uma estrutura de informação particular, mantendo-se sempre gerados a partir dos dados reais do Odoo, nunca de uma fonte paralela que arriscaria divergir.
Conectores e API
Ligar o Odoo a um sistema externo — banco, caixa registadora, plataforma de e-commerce, ferramenta setorial de terceiros — através da API do Odoo (XML-RPC, JSON-RPC ou REST consoante os casos) ou através de conectores dedicados aos standards suíços de pagamento, ISO 20022 e fatura QR. Um conector mal isolado pode fazer falhar uma sincronização inteira por um erro menor do lado do sistema externo; a análise de impacto, descrita mais adiante, serve precisamente para limitar este risco.
Portais
Abrir um acesso limitado e seguro a terceiros — clientes, fornecedores, colaboradores — para consultar ou depositar documentos, sem lhes dar acesso à interface completa de gestão. Os direitos de acesso do portal devem ser definidos com o mesmo rigor que os de um utilizador interno.
O método seguido em cada desenvolvimento
Um desenvolvimento Odoo que toca em dados de gestão segue uma sequência de trabalho fixa, seja qual for a sua dimensão.
| Etapa | Objetivo |
|---|---|
| Definição da necessidade | Compreender o processo real, distinguir o que releva da configuração standard do que justifica um desenvolvimento. |
| Análise de impacto | Identificar os módulos standard envolvidos, os riscos nas futuras atualizações de versão, e as alternativas existentes (Studio, módulo OCA). |
| Especificação | Descrever com precisão os campos, regras, vistas e documentos envolvidos, validados antes de qualquer desenvolvimento. |
| Desenvolvimento | Escrita do código num módulo dedicado, sem alteração dos módulos standard. |
| Testes | Verificação funcional e testes de não regressão sobre os processos existentes. |
| Validação | Validação pelos utilizadores de negócio num ambiente de teste, antes da entrada em produção. |
| Entrada em produção | Implementação planeada, com um ponto de retorno possível em caso de anomalia. |
| Manutenção | Acompanhamento do desenvolvimento ao longo do tempo, incluindo nas atualizações de versão. |
Duas etapas deste método são frequentemente negligenciadas pelos integradores que não conhecem a contabilidade suíça: a análise de impacto, que deve incluir uma leitura das consequências contabilísticas e fiscais do desenvolvimento, e a validação, que deve ser confirmada por uma pessoa capaz de julgar se o resultado produzido é correto no sentido contabilístico, não apenas no sentido funcional.
A condicionante suíça: o que a dupla competência muda
Um desenvolvimento que toca na contabilidade, no IVA ou nos salários nunca é um desenvolvimento neutro. Tem de respeitar o plano de contas adotado pela empresa, as posições fiscais aplicadas a cada tipo de operação, a estrutura da fatura QR, o standard de pagamento ISO 20022, e as exigências Swissdec para a gestão dos salários. Um campo acrescentado sem ter em conta estas condicionantes pode produzir um lançamento contabilístico errado, uma posição de IVA incorreta, ou uma fatura QR não conforme.
O Odoo instala automaticamente a localização suíça (módulo l10n_ch) quando a empresa é configurada na Suíça, o que estabelece uma base correta para o plano de contas e as taxas de IVA — 8,1 %, 2,6 % e 3,8 % desde 1 de janeiro de 2024. Esta base standard não dispensa a verificação, a cada desenvolvimento, de que a personalização permanece alinhada com ela em vez de a contornar.
Quanto aos salários, o Odoo consta do registo Swissdec ao nível «swissdec certified basic» (certificado n.º 1203.25, para ELM 5.3, verificado a 22.09.2026). Um desenvolvimento que toque no cálculo ou na transmissão dos salários tem de respeitar este quadro de certificação: não é um domínio onde se possa admitir uma adaptação que se afaste do standard certificado. É precisamente nesta interseção que a dupla competência da AX-Fiduciaire conta: compreender ao mesmo tempo o que o código tem de fazer e o que a lei suíça exige desse resultado. Os nossos desenvolvimentos que tocam na contabilidade articulam-se com a nossa oferta contabilidade Odoo; os que tocam nos salários, com a nossa oferta salários e RH Odoo.
Manter um desenvolvimento ao longo do tempo
Um desenvolvimento entregue não é um desenvolvimento terminado. Vive com o resto do sistema e tem de se manter compatível com as suas evoluções. É um ponto que os projetos pilotados apenas pela entrada em produção inicial negligenciam frequentemente: o custo de um desenvolvimento não se mede apenas pela sua entrega, mas pelo que custa mantê-lo em várias versões sucessivas.
- Atualizações de versão: cada nova versão importante do Odoo pode alterar API, modelos ou vistas nas quais um módulo à medida se apoia. Um módulo bem concebido, sem alteração dos módulos standard, limita este risco sem o eliminar. Ver a nossa oferta migração Odoo.
- Dívida técnica: cada desenvolvimento acrescentado aumenta a superfície a manter. Um desenvolvimento não documentado, não testado ou redundante com o standard torna-se um encargo que se acumula.
- Testes de não regressão: verificar, a cada atualização, que os desenvolvimentos existentes continuam a funcionar como previsto.
- Documentação: registar o que foi desenvolvido, porquê, e segundo que regras de negócio, para que outro programador possa retomar o trabalho sem adivinhar as intenções de origem.
- Reversibilidade: um desenvolvimento deve poder ser desativado ou retirado sem quebrar o resto do sistema, caso a necessidade que o motivou desapareça.
Este acompanhamento ao longo do tempo integra-se na nossa oferta de suporte Odoo, que cobre tanto os módulos standard como os desenvolvimentos realizados pela AX-Fiduciaire.
Retomar um desenvolvimento existente feito por outro prestador
Intervimos também em desenvolvimentos Odoo realizados por um prestador anterior, seja para corrigir uma anomalia, preparar uma atualização de versão, ou retomar a manutenção de um sistema cujo prestador de origem já não está disponível. Esta retoma começa sempre por uma análise do código existente: o que faz realmente, como foi construído, se altera módulos standard ou se vive em módulos separados, e que riscos apresenta para as futuras atualizações de versão.
Esta análise pode mostrar que um desenvolvimento existente é sólido e merece ser mantido tal como está, que tem de ser documentado antes de qualquer intervenção adicional, ou que tem de ser parcialmente revisto porque altera diretamente módulos standard ou contorna uma regra contabilística. Em todos os casos, a retoma faz-se com base no que existe, não numa reescrita sistemática.
Este tipo de intervenção é frequente após uma atualização de versão que revela desenvolvimentos que se tornaram incompatíveis, ou quando um desenvolvimento que toca na contabilidade ou nos salários foi realizado por um prestador sem experiência fiduciária e tem de ser verificado no essencial, não apenas na forma do código.
O que a AX-Fiduciaire não fará
Estes limites são estabelecidos desde a definição da necessidade, não descobertos a meio do projeto.
- Desenvolver o que o standard já cobre. Se uma configuração, uma opção nativa ou um módulo OCA existente responde à necessidade, não propomos um desenvolvimento à medida em vez disso.
- Contornar uma regra contabilística, fiscal ou de salários através de código. Um desenvolvimento nunca serve para produzir um resultado que se afaste do plano de contas, das posições de IVA ou das exigências Swissdec aplicáveis.
- Entregar sem testes. Um desenvolvimento que toca em dados de gestão passa por testes funcionais e testes de não regressão antes da sua entrada em produção, sem exceção.