Claves NFR de Odoo: qué son, quién las pide y cómo se solicitan

Si has llegado aquí buscando «NFR» y lo que necesitabas eran requisitos no funcionales —rendimiento, disponibilidad, tolerancia a fallos—, esta página no es. Aquí NFR significa Not For Resale: la licencia que una empresa de software concede a sus partners para que monten demostraciones y entornos internos sin pagarlos. Y conviene saber una cosa: Odoo no llama NFR a nada. La palabra no aparece ni una sola vez en el Acuerdo de Partners de Odoo (versión 11, del 19 de mayo de 2023). Lo que buscas existe, pero se llama de otra forma: no hay clave, hay una cláusula de la licencia de Enterprise que se activa al firmar el acuerdo de partners, y un código que abre un proyecto de prueba en Odoo.sh.

Lo escribimos desde dentro: FLEXIBLES Y ACCESORIOS GOBE S.L. —la sociedad detrás de FlexigoTech— entró en el programa de partners de Odoo el 8 de septiembre de 2026, en nivel Learning Partner. Del panel no publicamos captura, porque lleva identificadores e importes; lo describimos campo por campo más abajo.

Sello de Learning Partner. El derecho a usar la marca y el logotipo de Odoo figura como Yes en los cuatro niveles de la tabla del apartado 4.2.

Por qué el acrónimo te devuelve resultados inútiles

NFR tiene dos significados sin relación. En ingeniería de software es non-functional requirement, un atributo de calidad del sistema. En el canal de distribución es not for resale, una licencia gratuita de uso interno para distribuidores. La segunda casi no tiene literatura en castellano y ninguna referida a Odoo, así que la búsqueda te devuelve glosarios de requisitos y programas de canal ajenos.

Qué te da Odoo en lugar de una clave NFR

Tres cosas distintas, con tres nombres propios y tres sitios donde se piden. Mezclarlas es el origen de casi toda la confusión.

1. El permiso de uso de Enterprise. No es una clave, es una cláusula. La licencia Odoo Enterprise Edition v1.0 dice que «con un Acuerdo de Partners válido con Odoo S.A., los permisos anteriores también se conceden, siempre que el uso se limite a un entorno de pruebas o de desarrollo». Esa frase es toda tu «licencia NFR».
2. El código de partner. Este sí es una cadena que se escribe en un formulario y abre un proyecto de prueba en Odoo.sh. El derecho sale del apartado 3.1 del acuerdo —«Odoo concede al partner acceso gratuito a la plataforma Odoo.sh con fines de prueba y desarrollo»—; el mecanismo, de la documentación de Odoo.sh, que dice que los partners pueden usar su código de partner para iniciar una prueba. Primera mano: en nuestro panel de Learning Partner el código que aparece etiquetado es el de ampliación de prueba, así que si no ves el de partner, pídeselo a tu gestor de cuentas.
3. El código de ampliación de la prueba de Enterprise. Un tercer código que no es para ti: alarga el periodo de prueba de un cliente potencial. La tabla de beneficios del apartado 4.2 lo marca como disponible en los cuatro niveles.

Encima está el acceso de lectura al repositorio del código fuente de Odoo Enterprise en GitHub, que es lo que te permite compilar y probar módulos contra Enterprise en tu máquina.

Para qué sirven de verdad y para qué no

Sirven para demostración comercial, formación interna y desarrollo y pruebas de tus módulos, incluido probar la misma base contra distintas versiones mayores antes de una migración. No sirven para la producción de un cliente, y el acuerdo es inusualmente tajante: el apartado 3.2 dice que el partner se compromete a no ofrecer servicios sobre Odoo Enterprise Edition a clientes no cubiertos por una suscripción de Enterprise, ni siquiera durante la fase de implantación. No hay ventana de cortesía mientras configuras.

Tampoco sirven para redistribuir nada: el mismo apartado obliga a mantener el código fuente de Enterprise confidencial dentro de la plantilla y prohíbe redistribuirlo sin permiso escrito. Lo que sí puedes hacer es desarrollar módulos encima de Enterprise y distribuirlos bajo cualquier licencia compatible: la licencia de Enterprise lo autoriza y cita LGPL, MIT o licencias propietarias similares.

Quién puede pedirlas y en qué momento del alta

No hay nada antes de la firma: la cláusula de la licencia habla de un «Acuerdo de Partners válido», y sin acuerdo no hay cláusula. El apartado 5 dice que el importe de la cuota se especifica por escrito en el momento de la firma —no es una cifra publicada—, que se paga al recibir la factura anual y que no es reembolsable. El apartado 2 fija la duración en un año desde la firma, con renovación automática salvo que una parte avise por escrito con 30 días de antelación. El programa tiene dos tipos de partnership y cuatro niveles, y el nivel depende de tres cifras.

El detalle que importa aquí: el acceso a Odoo.sh para pruebas y desarrollo, el código de ampliación de prueba y el acceso al código fuente figuran como Yes en los cuatro niveles. Los tienes desde el primer día como Learning Partner. Lo que no se obtiene es la visibilidad en la lista pública de partners de odoo.com y la comisión del 50 % sobre Odoo.sh, que en Learning se queda en el 10 % —y que en cualquier nivel tiene tope: la nota al pie del apartado 4.2 la limita a 150 € (o 180 $) al mes por suscripción, 1.440 € (o 1.728 $) al año. Una observación de primera mano: la fila que junta el gestor de cuentas dedicado y el panel de partner está marcada como No en Learning, y aun así en nuestra alta de septiembre de 2026 el panel estaba ahí y se nos asignó una gestora de cuentas con teléfono y correo directos. El propio apartado 4.4, además, dice que el partner tendrá acceso al coaching comercial de su gestor de cuentas, sin distinguir nivel. El contrato es el suelo, no el techo.

El trámite, paso a paso

1. Firma el acuerdo y paga la cuota anual. Se abona al recibir la factura de Odoo y no es reembolsable. Sin acuerdo firmado no hay nada de lo anterior.
2. Entra en el panel de partner, en odoo.com/my/partner. Ahí tienes el nivel actual y la escalera hasta Official; el enlace de referido, que lleva el identificador numérico de partner dentro del parámetro de campaña; el código de ampliación de prueba; el acceso de lectura al repositorio de Enterprise en GitHub para el usuario que declares; la descarga de fuentes e instaladores; los activos de marca; el estado de la ficha de empresa, publicada o no; y el contador de comisiones de los últimos doce meses.
3. Abre el proyecto de demostración en Odoo.sh. Pulsa Deploy your platform, autoriza con una cuenta de GitHub y, en el campo Subscription Code —la documentación avisa de que también lo llaman subscription referral, contract number o activation code—, escribe el código de partner.
4. Elige versión mayor y región. Odoo.sh no admite las versiones intermedias que corre Odoo Online. Si vas a empezar en Odoo Online y migrar después, la documentación recomienda crear la base desde odoo.com/start-lts para que nazca en una versión compatible.
5. Cuando el cliente diga que sí, cambia de código. La documentación es explícita: si el cliente sigue adelante, debe contratar un plan de Odoo Enterprise que incluya alojamiento en Odoo.sh y usar su propio código de suscripción. Tu código de partner sale de la ecuación.

Los límites que sorprenden

Ninguno es secreto: todos están en la documentación oficial. El problema es que están repartidos por cinco páginas y te los encuentras de uno en uno, siempre en el peor momento.

• 1 GB y dos ramas de staging. Es el techo de las construcciones de prueba creadas con código de partner. Los volcados que importes tampoco pueden pasar de 1 GB.
• 30 días y la producción deja de ser producción. En proyectos de prueba, la rama de producción y todas las de staging vuelven automáticamente a la etapa de desarrollo a los 30 días. Esa es la caducidad real de tu demo.
• Las bases de staging se borran solas al mes y hay que reconstruir la rama para volver a usarla.
• Una demo en staging no envía correos. La neutralización desactiva las acciones planificadas y el correo saliente —interceptado por un mail catcher— y apaga los servicios IAP, las pasarelas de pago y los métodos de envío. La base neutralizada pierde además la sincronización bancaria y la visibilidad para buscadores, y lleva una banda roja arriba para que se note.
• El cambio de código es una puerta de un solo sentido. Puedes cambiar el código de activación del proyecto, pero no a uno ya asignado a otro proyecto ni a un código de prueba: bajar de pago a prueba no está permitido.
• El nivel se revisa cada trimestre y se ajusta al más alto cuyos tres requisitos cumples. Cuentan los usuarios netos nuevos de los últimos doce meses: las renovaciones no suman para el nivel, aunque sí generen comisión.
• Si el acuerdo se acaba, se acaba todo. El apartado 6.1 dice que al expirar o rescindirse el partner ya no puede usar Odoo Enterprise ni para desarrollo, ni para pruebas, ni para producción, y debe dejar de usar la marca. La caducidad de tu «licencia NFR» es la fecha de tu acuerdo, no la de tu proyecto.

Los errores que se pagan caros

• Montar la producción de un cliente encima de tu proyecto de prueba. Incumple el apartado 3.2, no se puede deshacer porque no se permite bajar de pago a prueba, y a los 30 días la rama de producción se degrada sola. Todo eso con el cliente mirando.
• Olvidar la renovación. El acuerdo se renueva solo por otro año si nadie avisa por escrito con 30 días. Si quieres renovar, ningún problema; si quieres salir, el olvido te cuesta una anualidad no reembolsable.
• Prometer en una demo lo que la neutralización apaga: correos, pagos reales, etiquetas de transportista, acciones planificadas. Enséñalo en un entorno de desarrollo con datos de demostración, o avisa antes.
• Subir código de Enterprise a un repositorio público. Es el incumplimiento más silencioso y el más difícil de deshacer, porque lo que es público ya se ha copiado.

¿Y si todavía no eres partner?

Dos salidas honestas mientras no firmas. Las bases de demostración compartidas de Odoo no piden registro, pero según la documentación cada una solo está disponible unas pocas horas: sirven para enseñar una pantalla, no para preparar una demo a medida. Y Odoo Community es software libre bajo LGPLv3: si lo que tienes que demostrar vive en un módulo tuyo y no en una app de Enterprise, es un entorno válido y sin caducidad. Odoo Online no lo es: no admite módulos personalizados ni del App Store, y los duplicados caducan a los 15 días con un máximo de cinco por base.

Nosotros probamos cada módulo contra construcciones reales de Odoo.sh en las versiones 19, 18 y 17 antes de tocar el App Store: el entorno de partner es exactamente donde se hace ese trabajo. Lo explicamos en ingeniería de Odoo para consultorías y en conector de Odoo para tu software.

Para seguir

Si la decisión que tienes delante es otra —qué edición necesitas de verdad—, la hemos comparado en Community o Enterprise. Y si lo que te frena es no tener equipo para entregar un proyecto ya vendido, mira subcontratar desarrollo de Odoo: quién firma el módulo.

Preguntas frecuentes