Pular para o conteúdo

Campos Personalizados no Odoo: Guia Completo e Prático

Saiba como adicionar campos personalizados a qualquer modelo do Odoo — quer prefira a interface visual do Odoo Studio, quer opte por trabalhar diretamente com código Python — e por que isso pode transformar processos e relatórios na sua empresa.
6 de março de 2026 por
Campos Personalizados no Odoo: Guia Completo e Prático
Dasolo
| Nenhum comentário ainda

Cada empresa tem particularidades: dados que um ERP genérico não prevê. Os campos personalizados no Odoo existem precisamente para registar essa informação única da sua operação.


Em vez de forçar a sua equipa a encaixar processos numa estrutura rígida, o Odoo permite acrescentar campos a quase qualquer registo — cliente, encomenda, produto ou fatura — e armazenar aí os dados que importam ao seu negócio.


Neste guia encontra o essencial: o que são campos personalizados, como o Odoo os gere internamente, como os criar com ou sem código, e como os usar sem poluir a sua instância Odoo.

O que é um campo personalizado no Odoo


Um campo personalizado é uma coluna de dados que acrescenta informação a um modelo Odoo já existente, além dos campos padrão. Funciona como qualquer campo nativo: guarda um valor associado a um registo específico.


No Odoo, os campos personalizados aparecem com o prefixo x_. Se usar o Studio, verá nomes tipo x_studio_priority_level. Num desenvolvimento, é comum usar um prefixo da empresa, por exemplo x_minhaempresa_cost_center.


Para o utilizador, um campo personalizado comporta-se exatamente como um campo normal: pode estar em formulários, listas, filtros, agrupamentos e relatórios. Quem só usa a interface raramente percebe que o campo é personalizado.


Tipos de campo disponíveis

O Odoo oferece vários tipos de campo para cobrir necessidades comuns de dados:

  • Texto curto (Char): texto breve, como um código ou etiqueta
  • Texto longo: texto multilinha para notas ou descrições
  • Inteiro: números inteiros para contagens ou índices
  • Decimal (Float): números com casas decimais para medidas ou taxas
  • Monetário: valores com moeda, ligado a um campo de moeda
  • Booleano: verdadeiro/falso (caixa de seleção)
  • Data / Data e Hora: data de calendário ou carimbo temporal
  • Seleção: lista fixa de opções (dropdown)
  • Many2one: ligação a um único registo noutro modelo
  • One2many: lista de registos relacionados de outro modelo
  • Many2many: várias ligações a registos noutro modelo
  • Binário: ficheiros anexados
  • HTML: conteúdo rico formatado

Escolher o tipo certo desde o início evita dores de cabeça: quando os valores são conhecidos, use uma seleção em vez de texto livre para garantir consistência nos relatórios.

Como funciona o campo


Por baixo do capô, o Odoo usa o ORM (Object-Relational Mapping). Cada vista e registo corresponde a uma classe Python que mapeia para tabelas no PostgreSQL. Ao criar um campo personalizado, o Odoo regista-o no ORM e cria a coluna correspondente na base de dados de forma automática.


Essa meta-camada é o que torna o modelo de dados do Odoo flexível: não está a mexer no código-fonte, mas a estender o modelo através de metadados guardados em ir.model.fields, que o Odoo carrega dinamicamente ao arrancar.


Campos definidos em código vs. campos definidos via base de dados

No desenvolvimento tradicional, os campos aparecem nas classes Python do modelo usando as ferramentas do framework Odoo. É a forma recomendada para projectos controlados por código.


Num módulo Python típico, um campo simples poderia ser declarado numa classe do modelo para acrescentar um atributo persistente e tipado à tabela correspondente.

Campos criados pela interface ou pela API são registados com state = 'manual' na tabela ir.model.fields e carregados em runtime. Tanto estes como os definidos em código geram colunas reais na base de dados e comportam-se da mesma forma para o utilizador.


Campos relacionais e reciprocidade

Ao criar um campo Many2one que aponta para outro modelo, o Odoo conta normalmente com um One2many do lado oposto. Esta reciprocidade permite navegar e agregar registos entre modelos através do ORM.


Por exemplo, ao adicionar um x_project_id (Many2one para project.project) numa encomenda, o ideal é ter um x_sale_order_ids (One2many para sale.order) no projeto, para que se veja quais as encomendas ligadas ao projeto na interface padrão.


Campos computados

Campos computados são preenchidos automaticamente a partir de outros valores: define-se uma função em Python ligada ao campo via o parâmetro compute. São normalmente só de leitura e atualizam-se quando as dependências mudam.


Os campos computados são potentes mas exigem código; o Studio não cria estes campos automaticamente sem ativar o modo desenvolvedor e escrever lógica em Python.

Casos de uso nas empresas


Nos nossos projetos vemos campos personalizados em quase todos os clientes. Abaixo estão cinco exemplos práticos que surgem frequentemente.

1. CRM: qualificação de leads com mais detalhe

Além dos contactos e estágio, as equipas comerciais precisam de categorizar leads por indústria ou segmento. Um campo de seleção "Setor" ou um Many2one para um modelo interno de "Segmento de Mercado" acelera a qualificação e permite relatórios por segmento.


2. Vendas: códigos internos de projeto

Empresas que faturam por projeto normalmente anexam um código interno a cada proposta ou encomenda. Um campo Char chamado "Código de Projeto" em sale.order resolve isto sem precisar de uma integração de gestão de projetos completa, aparecendo em documentos impressos e relatórios.


3. Inventário: atributos específicos do produto

Para além dos atributos padrão, fabricantes ou distribuidores registam especificações técnicas próprias — por exemplo "Período de Garantia (meses)" (Inteiro), "Norma de Certificação" (Seleção) ou "País de Origem" (Many2one para res.country). Esses campos entram naturalmente no formulário de produto e em relatórios de stock.


4. Contabilidade: alocação por centro de custos

As finanças precisam muitas vezes de marcar faturas ou lançamentos com centros de custo. Um Many2one em account.move para um modelo "Centro de Custo" permite análise detalhada sem alterar a contabilidade analítica nativa; filtros e pivot tables passam a respeitar imediatamente o campo.


5. RH: dados de onboarding personalizados

O departamento de pessoas recolhe informação na integração que muitas vezes não existe nos campos padrão: tipos contratuais locais, categorias internas de competências ou referências de viatura. Campos em hr.employee mantêm esses dados dentro do Odoo, pesquisáveis e reportáveis.

Criar ou personalizar o campo


Existem duas formas principais de criar campos personalizados em Odoo; a escolha depende dos recursos técnicos e da complexidade do campo.


Opção 1: Odoo Studio (sem código)

O Studio é a via mais rápida para utilizadores de negócio. Com o Studio ativo pode acrescentar campos a qualquer vista em poucos cliques:

  1. Abra a aplicação e o tipo de registo onde quer adicionar o campo (por exemplo, um formulário de encomenda)
  2. Clique no ícone do lápis para entrar no modo de edição do Studio
  3. Arraste o tipo de campo do painel lateral para o formulário
  4. Defina o rótulo, o nome técnico e propriedades adicionais do campo
  5. Grave e saia do Studio

O Studio cria o campo em ir.model.fields com o prefixo x_studio_ e insere-o na vista sem necessidade de reiniciar o servidor — ideal para campos simples sem lógica personalizada.


Opção 2: personalização técnica via API

Para projetos de personalização, campos podem ser criados programaticamente com a API XML-RPC ou num módulo Python. Esta via é indicada quando precisa de campos computados, domínios complexos ou controlo por versionamento.


Usando a API, é possível automatizar a criação de um campo de seleção num modelo como sale.order a partir de um script de deployment.


Um script que pesquisa o modelo e cria o registo em ir.model.fields cria um campo x_project_type com seleção predefinida e state: 'manual', sendo útil para configurações remotas e automatizadas.

Este procedimento faz parte do fluxo de trabalho recomendado para adicionar campos sem alterar ficheiros fonte — útil em deploys automatizados.


Num módulo Python completo, define-se o campo na classe do modelo e o módulo carrega-o pelo mecanismo normal do Odoo, a opção mais sustentável para alterações que devem sobreviver a upgrades e ficar em controlo de versão.


Adicionar o campo à vista

Criar o campo não o torna automaticamente visível: tem de o inserir no formulário ou na lista relevante. Com o Studio isso acontece durante a criação; com desenvolvimento técnico, altera-se o XML da vista ou cria-se uma vista herdada que injeta o campo na posição desejada.


Boas práticas


Campos personalizados são fáceis de criar, mas sem planeamento a arquitetura pode ficar caótica. Estas práticas ajudam a manter a instância limpa.


Prefira campos de seleção a texto livre sempre que possível

Quando as opções são conhecidas, use Seleção em vez de Char. Texto livre gera entradas inconsistentes que arruínam filtros e relatórios. Um dropdown garante uniformidade sem esforço extra.


Nomeie campos de forma clara e consistente

O nome técnico (x_project_type) deve descrever o conteúdo, não a sua posição no ecrã. Evite nomes genéricos como x_field_1. Adote convenções e documente o propósito de cada campo.


Não sobrecarregue modelos nativos

Se estiver a acrescentar muitos campos a sale.order, talvez seja melhor criar um modelo próprio. Conjuntos de campos que representam uma entidade (projeto, contrato, certificação) devem viver num modelo dedicado ligado por Many2one.


Teste sempre numa base de dados de staging

Antes de tocar na produção, experimente numa cópia do ambiente. Criar um campo no modelo errado ou com o tipo errado pode exigir limpeza manual; um staging revela esses problemas cedo.


Documente os campos personalizados

Registe cada campo: modelo, nome técnico, finalidade e quem o pediu. Sem documentação, o histórico de campos cresce descontrolado e torna-se impossível identificar o que pode ser removido.


Use a ferramenta correta para lógica computada

Se o valor depende de outros campos, implemente um campo computado em vez de pedir entrada manual. Evita erros e divergências; os campos computados são uma funcionalidade standard do Odoo em Python.

Erros frequentes


Mesmo equipas experientes tropeçam em erros previsíveis. Eis os mais comuns e como evitá-los.


Esquecer o One2many ao criar um Many2one

Erro frequente: adicionar um Many2one para o modelo B a partir do modelo A sem a correspondente One2many em B. Assim, a navegação inversa quebra e os utilizadores não veem registos relacionados do outro lado. Crie ambos em conjunto.


Apagar um campo que contém dados

Eliminar um campo remove a coluna da base de dados e todos os dados associados sem possibilidade de desfazer. Se houver hipótese de reutilização futura, arquive ou oculte o campo em vez de o apagar.


Criar campos diretamente em produção

Alterar a base de dados em ambiente live sem testes é arriscado: uma má configuração da vista gera erros para utilizadores. Valide tudo num ambiente de teste antes de ir para produção.


Conflitos de nomes com campos padrão

O Odoo recusa nomes já existentes, mas pode surgir colisão com módulos que instalará mais tarde. Usar um prefixo da empresa (por exemplo x_minhaempresa_) reduz este risco.


Adicionar campos à vista sem pensar na UX

Só porque um campo existe não significa que deva ser visível por defeito. Formulários sobrecarregados atrasam os utilizadores. Coloque campos contextuais em separadores ou torne-os visíveis apenas em condições específicas.


Misturar campos do Studio e campos técnicos sem estratégia

Combinar personalizações por Studio e por código sem regras leva a campos com propósitos redundantes ou nomes conflitantes. Defina uma estratégia: Studio para coisas simples, código para lógica complexa, ou centralize tudo em código quando necessário.

Conclusão


Campos personalizados são uma das formas mais simples e eficazes de adaptar o Odoo ao seu negócio: não mexem no código-fonte, integram-se com a plataforma e permitem capturar dados específicos sem gambiarras.

O essencial é planear antes de criar: escolha o tipo adequado, nomeie com cuidado, respeite a reciprocidade relacional e documente as alterações. Uma arquitetura de campos bem pensada facilita manutenção e evolução.


Quer use o Studio para pequenos ajustes sem código ou escreva módulos Python para personalizações profundas, os princípios são os mesmos: alinhe o campo com os dados, mantenha o modelo limpo e teste antes de aplicar em produção.

Na Dasolo, ajudamos empresas a implementar, personalizar e otimizar Odoo para que o sistema espelhe os processos reais. Se precisa de alguns campos ou de um módulo completo, temos equipa para o projeto.

Contacte-nos para aconselhamento sobre a sua implementação Odoo. Analisamos a sua configuração e propomos o caminho mais limpo e sustentável.

Campos Personalizados no Odoo: Guia Completo e Prático
Dasolo 6 de março de 2026
Compartilhar esta publicação
Iniciar sessão para deixar um comentário