El framework de Odoo, por dentro. Con método.
Sabes programar. El problema es que cuando abres el código de Odoo no terminas de entender cómo encaja todo — módulos, ORM, vistas, seguridad. YouTube te da piezas. Los foros te dan parches. La IA te da código. Ninguno te da el cuadro completo.
¿Te suena alguna de estas?
- Tienes un proyecto Odoo en la mano ahora mismo — con fecha límite — y no sabes si vas a llegar. Cada día que pasa buscando en foros es un día que no estás resolviendo.
- Llevas semanas viendo videos de YouTube y sigues sin conectar las piezas. Sabes cosas sueltas pero no entiendes cómo encaja el framework completo.
- ChatGPT o Claude te generan el módulo, lo instalas en Odoo y da error. No sabes qué cambiar porque no entiendes por qué falla.
- Tienes un proyecto Odoo con fecha límite. Estás improvisando. Y cada día que pasa la presión sube.
- Entregas algo al cliente. Cruzas los dedos. Y en el fondo sabes que si falla a los tres meses no vas a saber por qué.
- Ves que otros devs cierran proyectos Odoo con seguridad. Tú todavía dependes de foros, Stack Overflow y tutoriales para cada cosa que no has visto antes.
Los agentes escupen código.
Tú tienes que saber si funciona.
Ya no es copy-paste de ChatGPT. Ahora son agentes que van prueba y error solos, generando 800 líneas para hacer una tonterita. Sin base, no puedes dirigirlos. Sin base, no puedes validar lo que escupen.
"No vayas por ahí. Vete por aquí." — eso es dirigir la orquesta.
Un agente genera 800 líneas de código para algo que con el ORM bien entendido
son 30. Sin la base no sabes decirle: "toma este contexto, agarra este módulo,
lee esto del core, y arma la solución así."
Lo dejas que vaya a su manera — y obtienes entornos diferentes,
estructuras diferentes, código que nadie va a poder mantener.
Y cuando llegue la v20 — que saldrá — y fallen esas 800 líneas,
¿qué le vas a decir al cliente que confió en ti?
La API te puede fallar. El método no.
"Lo siento, estamos teniendo problemas. Inténtelo más tarde." Eso te puede decir la API de cualquier IA — y el cliente está esperando. Al cliente no le puedes decir que la API estaba ocupada. Necesitas un método. Un protocolo. No un solo camino.
ORM y campos relacionales
Many2one, One2many, Many2many. Computed vs related. Cuándo usar @api.depends y cuándo @api.onchange. La IA confunde esto constantemente.
Seguridad y accesos
Grupos, reglas de registro, ir.model.access. Sin esto bien configurado tu módulo puede exponer datos o bloquear usuarios en producción.
Debugging real
No el debug de "pongo un print y rezo". El diagnóstico sistemático — logs, trazas, modo debug de Odoo — para encontrar el problema en minutos, no en días.
Mantenibilidad real
El código que generas hoy lo tienes que migrar a v20 el año que viene. ¿Va a aguantar? ¿Sabes si lo que generó la IA va a ser mantenible en esa empresa seria que confía en ti?
De cada maestrillo su librillo — a todos bajo el mismo sistema.
- Montar el entorno en local: todo el día ahí pegado, y eso antes de resolver la incidencia
- Cada dev instala a su manera — uno con Docker, otro con un script de GitHub, otro a mano
- El agente genera 800 líneas para una tonterita y no sabes si va a aguantar
- Copias lo que escupe la IA sin saber si la estructura es correcta para Odoo
- Entregas con miedo — si falla en producción no sabes dónde mirar
- Sangría de horas que se come el margen del proyecto
- Entorno desplegado en minutos, no en un día — con o sin IA
- Estándar operativo que todo el equipo entiende y replica
- Le dices a la IA: "no vayas por ahí, vete por aquí" — y entiendes por qué
- Validas lo que genera el agente porque conoces el ORM y la arquitectura
- Entregas con criterio — sabes exactamente por qué funciona y cómo migrarlo
- Proyectos mantenibles que aguantan el upgrade a la siguiente versión
Si te valoras en serio, multiplica tus horas de autodidacta por lo que vale tu hora.
Un developer Odoo cobra entre 40 y 50€ la hora mínimo.
Multiplica eso por las horas que llevas buscando en YouTube, en foros,
probando sin método. Solo en montar el entorno en local puedes pegarte
ahí todo el día — y eso antes de resolver la incidencia real.
No es que las horas estén desperdiciadas. Es que vas más lento,
sin método, y hay alguien que ya pasó por esos problemas.
Esa sangría de horas se come el margen de tus proyectos.
"Este método no nació para venderlo. Nació para resolver un problema interno real en una empresa donde trabajé.
Lo que me encontré al llegar era lo de siempre: cada dev a su bola, cada uno instalaba Odoo a su manera. Y la frase que se escuchaba era: 'Aquí aprender Odoo cuesta un año mínimo.' Un año. Para que un dev de grado superior o recién salido de la uni pudiera dar soporte real a un cliente.
Estandarizamos. Con método, pasamos de ese año a 3-4 semanas para que un dev nuevo diera sus primeros pasos y pudiera acompañar proyectos reales. No porque fueran menos capaces — sino porque por fin tenían el cuadro completo del framework, no piezas sueltas.
Lo sacamos a la venta cuando vimos que funcionaba. No antes. Todo lo que está aquí se probó con equipos reales dentro de empresa — y eso incluye los errores que cometimos en el camino."
El framework completo.
Un solo cuadro que encaja.
No qué "aprendes". Qué problemas reales de producción resuelves con cada bloque.
- Instalación de Odoo en Linux/Debian desde cero
- Configuración de PostgreSQL y usuarios del sistema
- Entorno virtual Python y dependencias de Odoo
- Configuración del archivo odoo.conf
- addons_path y rutas de módulos personalizados
- VS Code + extensiones para desarrollo Odoo
- Modo debug — activación y herramientas del navegador
- Logs del servidor — cómo leerlos y qué buscar
- Anatomía de un módulo — carpetas y archivos obligatorios
- El manifest __manifest__.py — todos los campos explicados
- __init__.py — por qué existe y cómo estructurarlo
- Instalación, actualización y desinstalación de módulos
- Dependencias entre módulos — cuándo y cómo usarlas
- Categorías y secuencias de carga
- Errores comunes al instalar — diagnóstico sistemático
- Módulos de Community vs Enterprise — diferencias reales
- Tu primer módulo funcional desde cero
- Scaffolding con odoo-bin scaffold
- models.Model — qué hace Odoo por debajo con tu clase
- Campos básicos — Char, Integer, Float, Boolean, Date, Datetime
- Campos relacionales — Many2one, One2many, Many2many
- Campos computed — @api.depends y stored
- Campos related — cuándo usarlos y cuándo no
- @api.onchange — validación y lógica de UI
- @api.constrains — validación de datos en base
- Métodos CRUD — create, write, unlink, copy
- search, browse, read — cómo consultar registros
- Domains — el lenguaje de filtros de Odoo
- sudo() — cuándo es correcto y cuándo es un error de seguridad
- Contexto y env — cómo viajan los datos en Odoo
- Estructura de una vista en Odoo — ir.ui.view
- Vista form — campos, grupos, notebooks y páginas
- Vista list/tree — columnas, botones y decoradores
- Vista kanban — tarjetas, columnas y grupos
- Vista search — filtros, groupby y búsqueda avanzada
- Acciones de ventana — ir.actions.act_window
- Menús — ir.ui.menu y estructura de navegación
- Botones en vistas — tipo object, action y URL
- Campos condicionales — attrs, invisible, required, readonly
- Widgets — many2many_tags, statusbar, priority
- Tipos de herencia en Odoo — _inherit vs _inherits vs prototype
- Extender modelos existentes con _inherit
- Agregar campos a res.partner, sale.order, account.move
- Override de métodos — super() y cuándo llamarlo
- Herencia de vistas — xpath y posición de nodos
- Errores comunes en herencia — diagnóstico
- Herencia de reportes QWeb
- Caso real — extender el módulo de ventas
- Grupos de seguridad en Odoo — res.groups
- ir.model.access — permisos CRUD por modelo y grupo
- Reglas de registro — ir.rule y domains de filtro
- Visibilidad de menús y vistas por grupo
- sudo() — uso correcto y riesgos de seguridad
- Errores de acceso en producción — cómo diagnosticarlos
- Caso real — módulo con múltiples roles de usuario
- Motor de plantillas QWeb — sintaxis completa
- Crear un reporte PDF desde cero
- Conectar datos del modelo al reporte
- Estilos CSS en reportes — lo que funciona y lo que no
- Imágenes, logos y campos binarios en PDF
- Reportes con líneas — tablas y totales
- Herencia de reportes base de Odoo
- TransientModel — qué es y cuándo usarlo
- Crear un wizard paso a paso
- Abrir un wizard desde un botón en lista o form
- Acciones del servidor — ir.actions.server
- Acciones programadas — ir.cron
- Envío de correos desde código
- Caso real — wizard de confirmación masiva
- Definición del proyecto — requisitos reales
- Diseño del modelo de datos
- Construcción del módulo base con ORM completo
- Vistas form, list y kanban del proyecto
- Seguridad — grupos y reglas de acceso
- Reporte PDF del proyecto
- Wizard de cierre con lógica de negocio
- Revisión final y buenas prácticas de producción
Devs reales. Proyectos reales. Sin adornos.
"En un mes ya estaba entregando soluciones reales en proyectos de Odoo. Pasé directo de la teoría a producción — sin rodeos."
"Odoo y Python me cambiaron la forma de gestionar proyectos. Llevo 2 años desarrollando integraciones con webhooks y APIs — 40h a la semana, 4 proyectos al año de principio a fin. Empiezo a ser referente en mi mercado."
Un precio. Todo incluido. Sin planes.
- 77 bloques del framework · 19.2h de video técnico
- Odoo v18 + v19 activo — siempre actualizado
- 6 meses soporte Telegram — "no estás solo, esto lo puedes conducir así"
- Acceso ilimitado + actualizaciones permanentes
- Proyecto real — App completa desde la arquitectura
- Comunidad de devs Odoo activa
Lo que se preguntan los devs antes de entrar.
La escalera técnica de Odoo.
Backend Developer es el punto de entrada. Una vez dominas el framework, el siguiente paso natural es el frontend.
El que tiene la base cuando llega el proyecto
lo cierra. El que no, lo rechaza.
El momento de prepararse es antes de necesitarlo. Acceso ilimitado, v18 + v19, 6 meses de soporte y garantía de 15 días. Sin planes. Sin fricción.
Acceder al Backend Developer — 597€El framework de Odoo, por dentro. Con método.
Sabes programar. El problema es que cuando abres el código de Odoo no terminas de entender cómo encaja todo — módulos, ORM, vistas, seguridad. YouTube te da piezas. Los foros te dan parches. La IA te da código. Ninguno te da el cuadro completo.
¿Te suena alguna de estas?
- Tienes un proyecto Odoo en la mano ahora mismo — con fecha límite — y no sabes si vas a llegar. Cada día que pasa buscando en foros es un día que no estás resolviendo.
- Llevas semanas viendo videos de YouTube y sigues sin conectar las piezas. Sabes cosas sueltas pero no entiendes cómo encaja el framework completo.
- ChatGPT o Claude te generan el módulo, lo instalas en Odoo y da error. No sabes qué cambiar porque no entiendes por qué falla.
- Tienes un proyecto Odoo con fecha límite. Estás improvisando. Y cada día que pasa la presión sube.
- Entregas algo al cliente. Cruzas los dedos. Y en el fondo sabes que si falla a los tres meses no vas a saber por qué.
- Ves que otros devs cierran proyectos Odoo con seguridad. Tú todavía dependes de foros, Stack Overflow y tutoriales para cada cosa que no has visto antes.
Los agentes escupen código.
Tú tienes que saber si funciona.
Ya no es copy-paste de ChatGPT. Ahora son agentes que van prueba y error solos, generando 800 líneas para hacer una tonterita. Sin base, no puedes dirigirlos. Sin base, no puedes validar lo que escupen.
"No vayas por ahí. Vete por aquí." — eso es dirigir la orquesta.
Un agente genera 800 líneas de código para algo que con el ORM bien entendido
son 30. Sin la base no sabes decirle: "toma este contexto, agarra este módulo,
lee esto del core, y arma la solución así."
Lo dejas que vaya a su manera — y obtienes entornos diferentes,
estructuras diferentes, código que nadie va a poder mantener.
Y cuando llegue la v20 — que saldrá — y fallen esas 800 líneas,
¿qué le vas a decir al cliente que confió en ti?
La API te puede fallar. El método no.
"Lo siento, estamos teniendo problemas. Inténtelo más tarde." Eso te puede decir la API de cualquier IA — y el cliente está esperando. Al cliente no le puedes decir que la API estaba ocupada. Necesitas un método. Un protocolo. No un solo camino.
ORM y campos relacionales
Many2one, One2many, Many2many. Computed vs related. Cuándo usar @api.depends y cuándo @api.onchange. La IA confunde esto constantemente.
Seguridad y accesos
Grupos, reglas de registro, ir.model.access. Sin esto bien configurado tu módulo puede exponer datos o bloquear usuarios en producción.
Debugging real
No el debug de "pongo un print y rezo". El diagnóstico sistemático — logs, trazas, modo debug de Odoo — para encontrar el problema en minutos, no en días.
Mantenibilidad real
El código que generas hoy lo tienes que migrar a v20 el año que viene. ¿Va a aguantar? ¿Sabes si lo que generó la IA va a ser mantenible en esa empresa seria que confía en ti?
De cada maestrillo su librillo — a todos bajo el mismo sistema.
- Montar el entorno en local: todo el día ahí pegado, y eso antes de resolver la incidencia
- Cada dev instala a su manera — uno con Docker, otro con un script de GitHub, otro a mano
- El agente genera 800 líneas para una tonterita y no sabes si va a aguantar
- Copias lo que escupe la IA sin saber si la estructura es correcta para Odoo
- Entregas con miedo — si falla en producción no sabes dónde mirar
- Sangría de horas que se come el margen del proyecto
- Entorno desplegado en minutos, no en un día — con o sin IA
- Estándar operativo que todo el equipo entiende y replica
- Le dices a la IA: "no vayas por ahí, vete por aquí" — y entiendes por qué
- Validas lo que genera el agente porque conoces el ORM y la arquitectura
- Entregas con criterio — sabes exactamente por qué funciona y cómo migrarlo
- Proyectos mantenibles que aguantan el upgrade a la siguiente versión
Si te valoras en serio, multiplica tus horas de autodidacta por lo que vale tu hora.
Un developer Odoo cobra entre 40 y 50€ la hora mínimo.
Multiplica eso por las horas que llevas buscando en YouTube, en foros,
probando sin método. Solo en montar el entorno en local puedes pegarte
ahí todo el día — y eso antes de resolver la incidencia real.
No es que las horas estén desperdiciadas. Es que vas más lento,
sin método, y hay alguien que ya pasó por esos problemas.
Esa sangría de horas se come el margen de tus proyectos.
"Este método no nació para venderlo. Nació para resolver un problema interno real en una empresa donde trabajé.
Lo que me encontré al llegar era lo de siempre: cada dev a su bola, cada uno instalaba Odoo a su manera. Y la frase que se escuchaba era: 'Aquí aprender Odoo cuesta un año mínimo.' Un año. Para que un dev de grado superior o recién salido de la uni pudiera dar soporte real a un cliente.
Estandarizamos. Con método, pasamos de ese año a 3-4 semanas para que un dev nuevo diera sus primeros pasos y pudiera acompañar proyectos reales. No porque fueran menos capaces — sino porque por fin tenían el cuadro completo del framework, no piezas sueltas.
Lo sacamos a la venta cuando vimos que funcionaba. No antes. Todo lo que está aquí se probó con equipos reales dentro de empresa — y eso incluye los errores que cometimos en el camino."
El framework completo.
Un solo cuadro que encaja.
No qué "aprendes". Qué problemas reales de producción resuelves con cada bloque.
- Instalación de Odoo en Linux/Debian desde cero
- Configuración de PostgreSQL y usuarios del sistema
- Entorno virtual Python y dependencias de Odoo
- Configuración del archivo odoo.conf
- addons_path y rutas de módulos personalizados
- VS Code + extensiones para desarrollo Odoo
- Modo debug — activación y herramientas del navegador
- Logs del servidor — cómo leerlos y qué buscar
- Anatomía de un módulo — carpetas y archivos obligatorios
- El manifest __manifest__.py — todos los campos explicados
- __init__.py — por qué existe y cómo estructurarlo
- Instalación, actualización y desinstalación de módulos
- Dependencias entre módulos — cuándo y cómo usarlas
- Categorías y secuencias de carga
- Errores comunes al instalar — diagnóstico sistemático
- Módulos de Community vs Enterprise — diferencias reales
- Tu primer módulo funcional desde cero
- Scaffolding con odoo-bin scaffold
- models.Model — qué hace Odoo por debajo con tu clase
- Campos básicos — Char, Integer, Float, Boolean, Date, Datetime
- Campos relacionales — Many2one, One2many, Many2many
- Campos computed — @api.depends y stored
- Campos related — cuándo usarlos y cuándo no
- @api.onchange — validación y lógica de UI
- @api.constrains — validación de datos en base
- Métodos CRUD — create, write, unlink, copy
- search, browse, read — cómo consultar registros
- Domains — el lenguaje de filtros de Odoo
- sudo() — cuándo es correcto y cuándo es un error de seguridad
- Contexto y env — cómo viajan los datos en Odoo
- Estructura de una vista en Odoo — ir.ui.view
- Vista form — campos, grupos, notebooks y páginas
- Vista list/tree — columnas, botones y decoradores
- Vista kanban — tarjetas, columnas y grupos
- Vista search — filtros, groupby y búsqueda avanzada
- Acciones de ventana — ir.actions.act_window
- Menús — ir.ui.menu y estructura de navegación
- Botones en vistas — tipo object, action y URL
- Campos condicionales — attrs, invisible, required, readonly
- Widgets — many2many_tags, statusbar, priority
- Tipos de herencia en Odoo — _inherit vs _inherits vs prototype
- Extender modelos existentes con _inherit
- Agregar campos a res.partner, sale.order, account.move
- Override de métodos — super() y cuándo llamarlo
- Herencia de vistas — xpath y posición de nodos
- Errores comunes en herencia — diagnóstico
- Herencia de reportes QWeb
- Caso real — extender el módulo de ventas
- Grupos de seguridad en Odoo — res.groups
- ir.model.access — permisos CRUD por modelo y grupo
- Reglas de registro — ir.rule y domains de filtro
- Visibilidad de menús y vistas por grupo
- sudo() — uso correcto y riesgos de seguridad
- Errores de acceso en producción — cómo diagnosticarlos
- Caso real — módulo con múltiples roles de usuario
- Motor de plantillas QWeb — sintaxis completa
- Crear un reporte PDF desde cero
- Conectar datos del modelo al reporte
- Estilos CSS en reportes — lo que funciona y lo que no
- Imágenes, logos y campos binarios en PDF
- Reportes con líneas — tablas y totales
- Herencia de reportes base de Odoo
- TransientModel — qué es y cuándo usarlo
- Crear un wizard paso a paso
- Abrir un wizard desde un botón en lista o form
- Acciones del servidor — ir.actions.server
- Acciones programadas — ir.cron
- Envío de correos desde código
- Caso real — wizard de confirmación masiva
- Definición del proyecto — requisitos reales
- Diseño del modelo de datos
- Construcción del módulo base con ORM completo
- Vistas form, list y kanban del proyecto
- Seguridad — grupos y reglas de acceso
- Reporte PDF del proyecto
- Wizard de cierre con lógica de negocio
- Revisión final y buenas prácticas de producción
Devs reales. Proyectos reales. Sin adornos.
"En un mes ya estaba entregando soluciones reales en proyectos de Odoo. Pasé directo de la teoría a producción — sin rodeos."
"Odoo y Python me cambiaron la forma de gestionar proyectos. Llevo 2 años desarrollando integraciones con webhooks y APIs — 40h a la semana, 4 proyectos al año de principio a fin. Empiezo a ser referente en mi mercado."
Un precio. Todo incluido. Sin planes.
- 77 bloques del framework · 19.2h de video técnico
- Odoo v18 + v19 activo — siempre actualizado
- 6 meses soporte Telegram — "no estás solo, esto lo puedes conducir así"
- Acceso ilimitado + actualizaciones permanentes
- Proyecto real — App completa desde la arquitectura
- Comunidad de devs Odoo activa
Lo que se preguntan los devs antes de entrar.
La escalera técnica de Odoo.
Backend Developer es el punto de entrada. Una vez dominas el framework, el siguiente paso natural es el frontend.
El que tiene la base cuando llega el proyecto
lo cierra. El que no, lo rechaza.
El momento de prepararse es antes de necesitarlo. Acceso ilimitado, v18 + v19, 6 meses de soporte y garantía de 15 días. Sin planes. Sin fricción.
Acceder al Backend Developer — 597€