Chaves NFR do Odoo: o que são, quem as pede e como se solicitam

Se chegou aqui à procura de «NFR» e o que precisava eram requisitos não funcionais (desempenho, disponibilidade, tolerância a falhas), esta página não é a sua. Aqui NFR significa Not For Resale: a licença que uma empresa de software concede aos seus partners para montarem demonstrações e ambientes internos sem os pagar. E convém saber uma coisa: a Odoo não chama NFR a nada. A palavra não aparece uma única vez no Acordo de Partners da Odoo (versão 11, de 19 de maio de 2023). O que procura existe, mas tem outro nome: não há uma chave, há uma cláusula da licença Enterprise que se ativa ao assinar o acordo de partners, e um código que abre um projeto de teste no Odoo.sh.

Escrevemos isto por dentro: a FLEXIBLES Y ACCESORIOS GOBE S.L. (a sociedade por trás da FlexigoTech) entrou no programa de partners da Odoo a 8 de setembro de 2026, no nível Learning Partner. Não publicamos captura do painel, porque contém identificadores e montantes; descrevemo-lo campo a campo mais abaixo.

Selo de Learning Partner. O direito a usar a marca e o logótipo da Odoo figura como Yes nos quatro níveis da tabela do ponto 4.2.

Porque é que a sigla lhe devolve resultados inúteis

NFR tem dois significados sem relação. Em engenharia de software é non-functional requirement, um atributo de qualidade do sistema. No canal de distribuição é not for resale, uma licença gratuita de uso interno para distribuidores. A segunda quase não tem literatura em castelhano e nenhuma sobre a Odoo, pelo que a pesquisa devolve glossários de requisitos e programas de canal alheios.

O que a Odoo lhe dá em vez de uma chave NFR

Três coisas distintas, com três nomes próprios e três sítios onde se pedem. Misturá-las está na origem de quase toda a confusão.

1. A permissão de uso do Enterprise. Não é uma chave, é uma cláusula. A licença Odoo Enterprise Edition v1.0 diz que «com um Acordo de Partners válido com a Odoo S.A., as permissões anteriores também são concedidas, desde que o uso se limite a um ambiente de testes ou de desenvolvimento». Essa frase é toda a sua «licença NFR».
2. O código de partner. Este sim é uma cadeia de caracteres que se escreve num formulário e abre um projeto de teste no Odoo.sh. O direito resulta do ponto 3.1 do acordo («a Odoo concede ao partner acesso gratuito à plataforma Odoo.sh para fins de teste e desenvolvimento»); o mecanismo, da documentação do Odoo.sh, que diz que os partners podem usar o seu código de partner para iniciar um teste. Em primeira mão: no nosso painel de Learning Partner, o código que aparece etiquetado é o de extensão de teste, pelo que, se não vir o de partner, peça-o ao seu gestor de conta.
3. O código de extensão do teste do Enterprise. Um terceiro código que não é para si: prolonga o período de teste de um cliente potencial. A tabela de benefícios do ponto 4.2 marca-o como disponível nos quatro níveis.

Além disso, existe o acesso de leitura ao repositório do código-fonte do Odoo Enterprise no GitHub, que lhe permite compilar e testar módulos contra o Enterprise na sua máquina.

Para que servem de facto e para que não servem

Servem para demonstração comercial, formação interna e desenvolvimento e testes dos seus módulos, incluindo testar a mesma base contra diferentes versões principais antes de uma migração. Não servem para a produção de um cliente, e o acordo é invulgarmente taxativo: o ponto 3.2 diz que o partner se compromete a não oferecer serviços sobre o Odoo Enterprise Edition a clientes não cobertos por uma subscrição Enterprise, nem sequer durante a fase de implementação. Não há janela de cortesia enquanto configura.

Também não servem para redistribuir nada: o mesmo ponto obriga a manter o código-fonte do Enterprise confidencial dentro da equipa e proíbe a sua redistribuição sem autorização escrita. O que pode fazer é desenvolver módulos sobre o Enterprise e distribuí-los sob qualquer licença compatível: a licença do Enterprise di-lo expressamente e cita LGPL, MIT ou licenças proprietárias semelhantes.

Quem as pode pedir e em que momento da adesão

Não há nada antes da assinatura: a cláusula da licença fala de um «Acordo de Partners válido», e sem acordo não há cláusula. O ponto 5 diz que o valor da quota é especificado por escrito no momento da assinatura (não é um valor publicado), que se paga ao receber a fatura anual e que não é reembolsável. O ponto 2 fixa a duração em um ano a partir da assinatura, com renovação automática, salvo se uma das partes avisar por escrito com 30 dias de antecedência. O programa tem dois tipos de partnership e quatro níveis, e o nível depende de três valores.

O detalhe que aqui importa: o acesso ao Odoo.sh para testes e desenvolvimento, o código de extensão de teste e o acesso ao código-fonte figuram como Yes nos quatro níveis. Tem-nos desde o primeiro dia como Learning Partner. O que não se obtém é a visibilidade na lista pública de partners de odoo.com e a comissão de 50 % sobre o Odoo.sh, que em Learning fica nos 10 %: e que em qualquer nível tem um teto: a nota de rodapé do ponto 4.2 limita-a a 150 € (ou 180 $) por mês por subscrição, 1 440 € (ou 1 728 $) por ano. Uma observação em primeira mão: a linha que junta o gestor de conta dedicado e o painel de partner está marcada como No em Learning, e mesmo assim, na nossa adesão de setembro de 2026, o painel lá estava e foi-nos atribuída uma gestora de conta com telefone e e-mail diretos. O próprio ponto 4.4, além disso, diz que o partner terá acesso ao coaching comercial do seu gestor de conta, sem distinguir nível. O contrato é o piso, não o teto.

O processo, passo a passo

1. Assine o acordo e pague a quota anual. Paga-se ao receber a fatura da Odoo e não é reembolsável. Sem acordo assinado, não há nada do que foi dito acima.
2. Entre no painel de partner, em odoo.com/my/partner. Aí tem o nível atual e a escada até Official; a ligação de referenciação, que leva o identificador numérico de partner dentro do parâmetro de campanha; o código de extensão de teste; o acesso de leitura ao repositório do Enterprise no GitHub para o utilizador que indicar; a transferência de fontes e instaladores; os ativos de marca; o estado da ficha da empresa, publicada ou não; e o contador de comissões dos últimos doze meses.
3. Abra o projeto de demonstração no Odoo.sh. Clique em Deploy your platform, autorize com uma conta do GitHub e, no campo Subscription Code (a documentação avisa de que também lhe chamam subscription referral, contract number ou activation code), escreva o código de partner.
4. Escolha a versão principal e a região. O Odoo.sh não admite as versões intermédias que o Odoo Online executa. Se vai começar no Odoo Online e migrar depois, a documentação recomenda criar a base a partir de odoo.com/start-lts para que nasça numa versão compatível.
5. Quando o cliente disser que sim, mude de código. A documentação é explícita: se o cliente avançar, deve contratar um plano do Odoo Enterprise que inclua alojamento no Odoo.sh e usar o seu próprio código de subscrição. O seu código de partner sai da equação.

Os limites que surpreendem

Nenhum é secreto: todos estão na documentação oficial. O problema é que estão espalhados por cinco páginas e vai encontrando-os um a um, sempre no pior momento.

• 1 GB e dois ramos de staging. É o teto das compilações de teste criadas com código de partner. Os dumps que importar também não podem passar de 1 GB.
• 30 dias e a produção deixa de ser produção. Em projetos de teste, o ramo de produção e todos os de staging voltam automaticamente à fase de desenvolvimento aos 30 dias. Essa é a caducidade real da sua demo.
• As bases de staging apagam-se sozinhas ao fim de um mês e é preciso reconstruir o ramo para voltar a usá-lo.
• Uma demo em staging não envia e-mails. A neutralização desativa as ações agendadas e o e-mail de saída (intercetado por um mail catcher) e desliga os serviços IAP, os gateways de pagamento e os métodos de envio. A base neutralizada perde ainda a sincronização bancária e a visibilidade para motores de pesquisa, e leva uma faixa vermelha no topo para que se note.
• A mudança de código é uma porta de sentido único. Pode mudar o código de ativação do projeto, mas não para um já atribuído a outro projeto nem para um código de teste: passar de pago a teste não é permitido.
• O nível é revisto todos os trimestres e ajusta-se ao mais alto cujos três requisitos cumpre. Contam os utilizadores líquidos novos dos últimos doze meses: as renovações não contam para o nível, embora gerem comissão.
• Se o acordo termina, termina tudo. O ponto 6.1 diz que, ao expirar ou ser rescindido, o partner já não pode usar o Odoo Enterprise nem para desenvolvimento, nem para testes, nem para produção, e deve deixar de usar a marca. A caducidade da sua «licença NFR» é a data do seu acordo, não a do seu projeto.

Os erros que se pagam caro

• Montar a produção de um cliente em cima do seu projeto de teste. Viola o ponto 3.2, não se pode desfazer porque não se permite passar de pago a teste, e aos 30 dias o ramo de produção degrada-se sozinho. Tudo isto com o cliente a ver.
• Esquecer a renovação. O acordo renova-se sozinho por mais um ano se ninguém avisar por escrito com 30 dias de antecedência. Se quer renovar, nenhum problema; se quer sair, o esquecimento custa-lhe uma anuidade não reembolsável.
• Prometer numa demo o que a neutralização desliga: e-mails, pagamentos reais, etiquetas de transportadora, ações agendadas. Mostre-o num ambiente de desenvolvimento com dados de demonstração, ou avise antes.
• Carregar código do Enterprise para um repositório público. É o incumprimento mais silencioso e o mais difícil de desfazer, porque o que é público já foi copiado.

E se ainda não é partner?

Duas saídas honestas enquanto não assina. As bases de demonstração partilhadas da Odoo não pedem registo, mas, segundo a documentação, cada uma só está disponível durante umas poucas horas: servem para mostrar um ecrã, não para preparar uma demo à medida. E o Odoo Community é software livre sob LGPLv3: se o que tem de demonstrar vive num módulo seu e não numa app do Enterprise, é um ambiente válido e sem caducidade. O Odoo Online não o é: não admite módulos personalizados nem da App Store, e os duplicados caducam aos 15 dias, com um máximo de cinco por base.

Nós testamos cada módulo contra compilações reais do Odoo.sh nas versões 19, 18 e 17 antes de mexer na App Store: o ambiente de partner é exatamente onde esse trabalho se faz. Explicamo-lo em engenharia de Odoo para consultoras e em conector de Odoo para o seu software.

Para continuar

Se a decisão que tem pela frente é outra (que edição precisa de facto), comparámo-la em Community ou Enterprise. E se o que o trava é não ter equipa para entregar um projeto já vendido, veja subcontratar desenvolvimento de Odoo: quem assina o módulo.

Perguntas frequentes