Personalizar o Odoo 19: configuração, Studio ou módulos personalizados?

Todos os projetos Odoo acabam por chegar à mesma pergunta: o fluxo padrão está próximo, mas não é exatamente o que a empresa quer. Deve alterar uma definição, abrir o Odoo Studio ou pedir a um programador que escreva um módulo personalizado? A resposta tem consequências a longo prazo no custo, na estabilidade e, sobretudo, nas atualizações.

Na 1CBMS seguimos uma regra simples em todas as implementações: primeiro a configuração, depois o Studio e só depois os módulos personalizados. Cada degrau dessa escada acrescenta flexibilidade, mas também acrescenta algo que a empresa tem de assumir e manter durante toda a vida do sistema.

Uma nota sobre as fontes: este artigo segue a documentação oficial do Odoo para a versão 19.0. Os menus e as opções podem diferir entre versões, edições e tipos de alojamento, por isso confirme sempre o comportamento numa base de dados de teste antes de alterar a produção.

Primeira camada: a configuração antes de tudo

O Odoo inclui um grande número de definições, opções e registos configuráveis em cada aplicação. Muitos pedidos que parecem personalizações são, na verdade, funcionalidades padrão que ainda não foram ativadas, como passos adicionais de fluxo de trabalho, esquemas de documentos ou campos opcionais que aparecem quando uma funcionalidade é ativada.

Antes de escrever qualquer especificação para o Studio ou para código, percorra as seguintes verificações com os utilizadores-chave do processo:

• Reveja a página de Definições de cada aplicação envolvida e leia o que cada opção ativa.
• Verifique se o requisito é coberto por registos configuráveis, como etapas, etiquetas, equipas, tipos de operação ou modelos de email.
• Use as definições de esquema de documentos da empresa para logótipos, cores, tipos de letra e rodapés, em vez de editar os modelos de relatório.
• Pergunte se a empresa pode adaptar o seu processo ao fluxo padrão, porque os fluxos padrão são testados e atualizados pelo Odoo.

A configuração é a camada mais barata de manter. Faz parte do produto padrão, é transportada pelo processo de atualização e não cria uma base de código separada que alguém tenha de manter.

Segunda camada: o que o Odoo Studio pode fazer

A documentação do Odoo descreve o Studio como uma caixa de ferramentas para personalizar o Odoo sem conhecimentos de programação. Abre-se com o ícone Alternar Studio quando está na aplicação e no modelo que pretende alterar, e fecha-se com o botão Fechar.

Segundo a documentação oficial, o Studio abrange estas áreas:

• Campos: campos simples como texto, inteiro, decimal, monetário, data, caixa de verificação, seleção, ficheiro e imagem, e campos relacionais como Many2One, One2Many, Linhas, Many2Many, Etiquetas e campos relacionados.
• Vistas: vistas de formulário, atividade, pesquisa, kanban, lista, mapa, calendário, coorte, Gantt, pivô e gráfico.
• Modelos e aplicações: novos modelos criados de raiz, com funcionalidades sugeridas como chatter, etapas de pipeline, etiquetas, arquivo e linhas para acelerar a criação.
• Regras de automação: acionadores baseados em atualizações de valores, eventos de email, condições temporais, criação ou eliminação de registos, alterações na interface e webhooks externos.
• Regras de aprovação: passos de aprovação associados a botões, com aprovadores definidos como utilizadores, grupos ou ambos. O Studio abrange também webhooks e regras de segurança.
• Relatórios PDF: edição de texto estático e inserção de campos dinâmicos, tabelas, colunas e imagens nos modelos de relatório; note que editar o cabeçalho ou o rodapé de um relatório afeta todos os relatórios.

Quando altera uma vista arrastando e largando elementos, o Studio cria automaticamente a vista herdada e o XPath adequados, em vez de substituir a vista padrão. Todo o trabalho feito no Studio fica agrupado num módulo chamado studio_customization na sua base de dados, que pode ser exportado como ficheiro ZIP e importado noutra base de dados.

O Studio é uma aplicação do Odoo Enterprise. A página oficial refere também que instalar o Studio numa base de dados com o plano de preços Padrão implica a passagem para o plano Personalizado, por isso verifique o impacto comercial com o seu gestor de conta Odoo antes de o ativar. As bases de dados Community não incluem o Studio; aí, tudo o que vai além da configuração é feito através de definições técnicas em modo de programador ou através de módulos.

Segunda camada (continuação): os limites do Studio

O Studio é poderoso, mas a própria documentação assinala vários limites e riscos que todos os projetos devem respeitar:

• O nome técnico de um campo não pode ser alterado no Studio após a criação, e os campos personalizados têm de manter pelo menos o prefixo x_, sendo que os campos do Studio usam x_studio_.
• A vista de atividade e os blocos condicionais nos relatórios só podem ser alterados editando o XML, o que exige o modo de programador.
• Desaconselha-se editar diretamente vistas padrão ou herdadas, porque essas alterações seriam repostas e perdidas durante atualizações do sistema ou dos módulos.
• O Odoo recomenda vivamente duplicar um relatório padrão e editar a cópia, e avisa que modificar diretamente o XML de um relatório pode causar problemas nas atualizações.
• A ação Executar Código nas regras de automação executa Python, e a documentação indica que a manutenção de código personalizado não está incluída nos planos Padrão nem Personalizado e implica custos adicionais.
• Os webhooks devem ser desenhados com um programador ou um perfil técnico, porque webhooks mal configurados podem perturbar a base de dados.
• As personalizações do Studio exportadas só podem ser importadas numa base de dados com a mesma versão do Odoo e as mesmas aplicações e módulos instalados.

Na prática, o Studio é ideal para recolha de dados, esquemas, automações simples e aprovações. Torna-se arriscado quando é usado para esconder programação real em edições de XML ou em ações Executar Código que ninguém documenta.

Terceira camada: quando se justifica um módulo Python personalizado

Um módulo personalizado é uma base de código separada que estende o Odoo através de modelos, vistas, segurança, ficheiros de dados e lógica Python, construída com a mesma framework que o Odoo usa nas suas próprias aplicações. É a ferramenta certa quando o requisito vai além do que a configuração e o Studio conseguem exprimir de forma limpa.

Situações típicas em que recomendamos um módulo personalizado:

• Regras de negócio, cálculos ou restrições complexas que precisam de testes automatizados e de controlo de versões.
• Integrações com sistemas externos que exigem tratamento de erros robusto, novas tentativas e registos.
• Alterações à lógica de negócio padrão, como a forma como os documentos são validados ou os valores são calculados, e não apenas à forma como são apresentados.

O alojamento é aqui determinante. A documentação oficial indica que o Odoo Online é incompatível com módulos personalizados ou com módulos da Odoo Apps Store. Os módulos personalizados exigem o Odoo.sh ou uma instalação on-premise, pelo que a decisão de alojamento e a estratégia de personalização têm de ser tomadas em conjunto.

Impacto de cada opção nas atualizações

• Configuração: faz parte do produto padrão e é migrada pelo processo de atualização padrão.
• Studio: os serviços de atualização descritos na documentação do Odoo incluem a atualização de todas as personalizações criadas com a aplicação Studio, desde que o Studio esteja instalado e a respetiva subscrição ativa.
• Módulos personalizados: uma base de dados com módulos personalizados não pode ser atualizada enquanto não existir uma versão desses módulos para a versão do Odoo de destino, e cabe a quem mantém o módulo torná-lo compatível.

O guia do Odoo para atualizar uma base de dados personalizada recomenda congelar o desenvolvimento, verificar que funcionalidades personalizadas passaram a existir nativamente, garantir que cada módulo se instala sem erros numa base de dados vazia da versão de destino, escrever scripts de atualização para modelos, campos e identificadores externos renomeados e ensaiar a atualização antes de tocar na produção.

Seja qual for a camada, teste exaustivamente a base de dados atualizada. A documentação aconselha testar os fluxos de negócio de ponta a ponta, incluindo integrações, ações automatizadas, ações de servidor e relatórios, e lembra que as bases de dados de teste são neutralizadas, com as ações agendadas e os emails de saída desativados.

Governação: manter as personalizações sob controlo

As personalizações raramente falham no primeiro dia. Falham anos depois, quando já ninguém se lembra porque é que um campo existe ou quem escreveu uma regra de automação. Um modelo de governação simples evita isto.

• Mantenha um registo de personalizações que enumere cada campo do Studio, alteração de vista, regra de automação, regra de aprovação, relatório e módulo personalizado, com o respetivo responsável e motivo de negócio.
• Faça todas as alterações primeiro numa base de dados de teste ou de staging e depois passe-as para produção através de um processo controlado.
• Restrinja o Studio e o modo de programador a administradores com formação; a própria documentação avisa que algumas ferramentas de programador são avançadas e comportam riscos.
• Reveja o registo antes de cada atualização e retire as personalizações que a nova versão cobre nativamente.
• Mantenha o código dos módulos personalizados sob controlo de versões, com testes, e assegure que existe um acordo de manutenção para ele.

Uma matriz de decisão para aplicar em workshops

Quando surge um novo requisito, percorremos estas perguntas por ordem e paramos na primeira camada que o satisfaz.

• Uma definição padrão, um registo configurável ou uma alteração de processo resolvem a necessidade? Use a configuração.
• Trata-se de um campo novo, de uma alteração ao esquema de uma vista, de uma automação simples, de um passo de aprovação ou de uma alteração ao texto de um relatório? Use o Studio.
• Precisa de lógica Python, testes automatizados, integração complexa ou reutilização entre bases de dados? Use um módulo personalizado.
• A base de dados está no Odoo Online? Mantenha-se na configuração e no Studio, ou planeie primeiro a mudança para o Odoo.sh ou para on-premise.

Como a 1CBMS pode ajudar

A 1CBMS ajuda empresas no Egito e no Iraque a desenhar soluções Odoo 19 Enterprise que se mantêm próximas do padrão. Realizamos workshops de análise fit-gap para separar a configuração das verdadeiras lacunas, criamos personalizações disciplinadas no Studio, desenvolvemos e mantemos módulos personalizados quando são realmente necessários e preparamos registos de personalizações e planos de teste de atualização para que o seu sistema continue fácil de manter. Contacte-nos através de www.1cbms.com para rever as suas personalizações atuais ou planear uma nova implementação.