Personalizar o Odoo: da parametrização ao módulo à medida

Quando uma empresa portuguesa procura desenvolvimento Odoo, raramente precisa de começar por programar. A maioria das necessidades resolve-se com parametrização, com aplicações já existentes ou com ferramentas sem código. O desenvolvimento específico entra no fim, para o que é realmente diferenciador no seu negócio. Esta página ajuda-o a decidir onde parar, o que isso implica para as atualizações e como avaliar quem lhe propõe escrever código.

Os quatro níveis de personalização do Odoo

Convém ordenar as opções do menos para o mais invasivo. Cada nível acrescenta flexibilidade, mas também custo de manutenção.

A regra prática é simples: só se sobe de nível quando o anterior não resolve o problema com um custo razoável.

Parametrização: o que o standard já faz

Antes de falar em personalização do Odoo, vale a pena esgotar a parametrização. Uma implementação bem conduzida (veja a implementação do Odoo) cobre normalmente:

• circuitos de aprovação de compras e despesas;
• regras de preços, tarifas e descontos;
• tipos de documento e sequências de numeração;
• perfis de acesso por função;
• modelos de documentos e de mensagens.

Muitas vezes, o que parece uma necessidade específica é uma opção que ninguém ativou. Por isso, uma boa fase de análise começa por demonstrar o standard e só regista como «lacuna» aquilo que, de facto, não existe.

Odoo Studio: personalizar sem código

O Odoo Studio permite ajustar o sistema sem escrever código: campos, vistas, modelos, aplicações inteiras, regras de automatização, webhooks, relatórios PDF, regras de aprovação e regras de segurança. É adequado para acrescentar um campo de referência interna, uma vista simplificada para o armazém ou um relatório com a apresentação que a sua empresa usa.

Há, porém, uma implicação comercial a ter presente. O Studio faz parte da formulação Custom. Instalá-lo numa base em formulação Standard desencadeia uma mudança automática para Custom: uma encomenda complementar com um prazo de 30 dias num contrato anual, ou a passagem no ciclo de faturação seguinte num contrato mensal. A formulação Standard está indicada a 24,90 EUR por utilizador e por mês; a Custom, a 44,90 EUR (preços de lista, com desconto no primeiro ano para os utilizadores contratados no arranque). Antes de entusiasmar a equipa com o Studio, faça as contas ao conjunto. O mesmo se aplica ao multi-sociedade e ao acesso à API externa, que também pertencem à Custom. Para o enquadramento completo, consulte os preços do Odoo.

O Studio tem um limite natural: lógica de negócio complexa, cálculos encadeados ou integrações exigentes acabam por pedir código.

Aplicações existentes e módulos da comunidade

O Odoo anuncia 50 aplicações principais e uma comunidade que contribuiu com mais de 50 000 aplicações adicionais. É uma riqueza real, mas exige critério. Um módulo da comunidade não tem o mesmo grau de garantia que uma aplicação oficial. Antes de o adotar, verifique:

1. se é mantido e se acompanha as versões recentes do Odoo;
2. se a licença é compatível com a sua edição (Community ou Enterprise);
3. se o código é legível e se o autor responde a problemas;
4. se o integrador está disposto a assumir o suporte desse módulo.

Para ver o que já está coberto antes de procurar fora, consulte os módulos do Odoo.

Desenvolvimento específico: quando se justifica

Um módulo sobre medida Odoo faz sentido quando o processo é um traço distintivo da sua atividade e nenhuma combinação de parametrização, Studio e módulos o cobre. Exemplos típicos no tecido empresarial português:

• uma regra de cálculo de comissões para uma rede de agentes comerciais;
• um fluxo de produção com etapas próprias de uma indústria específica;
• uma ligação a uma plataforma de transportadores ou a um marketplace;
• um relatório de gestão que cruza dados de várias áreas.

O desenvolvimento no Odoo faz-se em código sobre a estrutura do próprio sistema, normalmente em Python, com ficheiros de definição para vistas e dados. A boa prática é herdar o comportamento standard em vez de o substituir: o módulo acrescenta ou ajusta, sem reescrever o núcleo.

Quanto à licença, os programadores podem criar módulos sobre o Odoo e distribuí-los sob a licença que escolherem, desde que compatível com a edição de origem. A Community está sob LGPLv3; a Enterprise, sob a licença Odoo Enterprise Edition v1.0, utilizável apenas com uma subscrição Enterprise válida para o número correto de utilizadores. Isto tem consequências práticas: um módulo que depende de funções Enterprise não pode ser reaproveitado livremente numa instalação Community.

Integrações: a API externa

Muitas «personalizações» são, na verdade, ligações a outros sistemas. A documentação atual apresenta a API JSON-2 como a via corrente, com chaves de API, direitos de acesso, escolha da base de dados e transações; o XML-RPC e o JSON-RPC são tratados como históricos, com um guia de migração. Se uma integração existente ainda assenta nos protocolos antigos, inclua a migração no seu planeamento. O acesso à API externa é uma função da formulação Custom. Detalhes em as integrações do Odoo.

Um caso frequente é o comércio eletrónico. O Odoo eCommerce já trata catálogo e variantes, contas de clientes, B2B e B2C, carrinhos abandonados, modos de entrega, devoluções e faturação, com vários sites, e liga-se a mais de vinte fornecedores de pagamento. Antes de encomendar um conector próprio, confirme que o standard não basta.

Impacto nas atualizações: o custo escondido

O verdadeiro preço de uma personalização não está na sua criação, mas em cada atualização que se segue. Um módulo à medida tem de ser verificado, testado e, por vezes, reescrito sempre que muda a versão do Odoo. Quanto mais código próprio, mais trabalho nessas alturas.

Para limitar o impacto:

• prefira a parametrização e o standard sempre que o resultado for aceitável;
• mantenha cada módulo pequeno e com uma única responsabilidade;
• evite copiar código do núcleo; herde e estenda;
• registe cada desvio ao standard e a razão de negócio que o justifica;
• planeie uma revisão das personalizações antes de cada mudança de versão ou migração.

Uma pergunta útil a fazer a cada pedido: «Se isto não existisse, o que perderíamos concretamente?» Muitas exigências desaparecem quando o utilizador percebe o custo de as manter.

Conformidade fiscal: onde não se improvisa

Em Portugal, há uma área em que a personalização exige cuidado redobrado: tudo o que toca à faturação. O software de faturação tem de estar certificado pela Autoridade Tributária, os documentos precisam de ATCUD e código QR, e o ficheiro SAF-T (PT) tem de refletir corretamente os dados. Alterar o comportamento de faturas, numeração, séries ou ficheiros fiscais por conta própria pode comprometer a conformidade.

Por isso, qualquer desenvolvimento nesta zona deve partir de uma localização portuguesa validada e ser discutido com o seu contabilista certificado. Pode aprofundar o tema nos nossos guias sobre o SAF-T (PT) e o software de faturação certificado, e no resumo do Odoo em Portugal.

Boas práticas: ficar no standard, documentar, testar

Ficar o mais perto possível do standard

O standard é a melhor garantia de atualizações previsíveis, de suporte acessível e de formação reutilizável. Adapte a empresa ao ERP sempre que isso não prejudique o negócio, e personalize apenas onde há vantagem competitiva.

Documentar cada desvio

Cada módulo deve ter uma ficha com o objetivo, o responsável do lado da empresa, as regras implementadas, as dependências e a forma de reverter. Sem isto, a empresa fica refém de quem escreveu o código.

Testar antes de colocar em produção

Os desenvolvimentos devem ser validados numa cópia da base de dados, com casos reais, antes de chegarem aos utilizadores. Peça testes automatizados para as regras críticas e uma fase de aceitação com utilizadores-chave. Ao tratar do alojamento, veja também as opções de alojamento cloud do Odoo, porque o tipo de implantação condiciona o que pode instalar. O Odoo pode ser implantado em Odoo Online, em Odoo.sh ou em servidor próprio; as duas últimas opções estão associadas à formulação Custom, e os custos do Odoo.sh não estão incluídos no preço por utilizador.

Prever manutenção e formação

Um módulo sem manutenção tende a tornar-se um problema. Defina quem corrige falhas, quanto tempo demora a resposta e como se faz a transição se o prestador mudar. Veja o suporte e a manutenção do Odoo.

Como avaliar um programador ou um integrador Odoo

A qualidade do desenvolvimento depende menos da tecnologia do que de quem a pratica. Eis perguntas que separam uma proposta séria de uma proposta arriscada:

Desconfie de propostas que prometem «tudo à medida» logo na primeira reunião, que não separam o que é parametrização do que é código, ou que recusam entregar o código-fonte. Para um critério mais completo, leia o guia para escolher um integrador ERP e a página sobre como escolher um parceiro Odoo.

Se o projeto já está em curso e as personalizações se acumularam, uma auditoria ao projeto Odoo pode ajudar a separar o que vale a pena manter do que convém simplificar.

Como preparar o seu pedido

Para obter propostas comparáveis, descreva cada necessidade como uma situação de negócio, não como uma solução técnica. Em vez de «precisamos de um campo novo na fatura», diga «o armazém precisa de saber a que obra se destina cada encomenda». Indique quantos utilizadores terá, que processos são críticos, que sistemas existentes devem ligar-se ao Odoo e quem, internamente, decide. Um caderno de encargos de ERP bem preparado reduz mal-entendidos e permite distinguir, desde o início, o que é parametrização do que é desenvolvimento.

Se quiser ser posto em contacto com um integrador adequado ao seu projeto, o nosso serviço é gratuito: veja como funciona a ligação a um integrador. Nós não desenvolvemos o projeto; encaminhamos o seu pedido para quem o pode fazer.

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.