Presentación: comprender cómo Odoo estructura los datos es clave para cualquier implantación. Los modelos son las plantillas que organizan la información en la base de datos; entre ellos, res.partner juega un papel transversal que afecta a múltiples procesos empresariales.
En Odoo, los modelos determinan la estructura y el almacenamiento de la información en la base de datos. Cada elemento de negocio —pedidos, facturas, contactos— se guarda según la definición de un modelo concreto, lo que permite consultas, validaciones y relaciones consistentes entre datos.
Para consultores y desarrolladores es fundamental dominar los modelos de Odoo: son la base de la arquitectura de datos. Definen campos, relaciones y la lógica empresarial que garantiza que los procesos funcionen correctamente y que la información sea fiable.
Este artículo se centra en res.partner, uno de los modelos más relevantes. Tanto si desarrollas módulos, integras sistemas externos o configuras procesos, trabajarás con este modelo y conviene entender sus particularidades para evitar errores y aprovechar sus capacidades.
Qué es el modelo res.partner: es la entidad central de Odoo que representa a personas y empresas con las que tu negocio interactúa. Allí se concentra la información de contacto, fiscal y comercial que utilizan ventas, compras, facturación y comunicación. Es, en la práctica, la libreta de direcciones ampliada de la empresa dentro de Odoo.
res.partner aglutina a clientes, proveedores, contactos y empresas. Actúa como el repositorio único donde se guarda toda la información sobre las contrapartes con las que operas: desde direcciones y datos fiscales hasta notas internas y preferencias de idioma.
El uso de res.partner se extiende por casi todos los módulos: desde Ventas y CRM hasta Contabilidad, Compras y Comercio Electrónico. Crear un cliente en Ventas, una oportunidad en CRM o un proveedor en Compras implica crear o vincular un registro de res.partner que será referenciado por esos módulos.
La definición base del modelo está en el módulo base, y otros módulos amplían su funcionalidad mediante la herencia de modelos. CRM puede añadir campos para oportunidades; Contabilidad, condiciones de pago o límites de crédito. Cada módulo suma lo que necesita manteniendo el núcleo común y evitando duplicidades.
Campos clave del modelo: entre los más importantes están name (nombre del socio), email, phone/mobile (contactos telefónicos), dirección (street, street2, city, zip, state_id, country_id), is_company/parent_id/child_ids (jerarquía empresa/contactos), vat (NIF/IVA), customer_rank/supplier_rank (indicadores de cliente/proveedor), user_id (responsable comercial), company_id (empresa en entornos multiempresa), active (archivo lógico), lang (idioma preferido), image_1920 (logo/foto) y category_id (etiquetas). Conocer estos campos facilita integraciones y operaciones diarias.
A continuación tienes los campos más relevantes de res.partner; conocerlos te permitirá manejar correctamente contactos y relaciones en Odoo y mejorar integraciones, filtrados y generación de documentos.
name: nombre que identifica al socio. Para empresas será la razón social; para personas, el nombre completo. Es el identificador principal que aparece en vistas y listados.
create_date: fecha y hora de creación del registro. Odoo la gestiona automáticamente y es útil para auditoría e informes temporales.
write_date: fecha y hora de la última modificación. También administrada por el sistema para rastrear cambios en los datos.
email: dirección de correo principal del socio. Empleada para comunicaciones, acceso al portal y notificaciones. Odoo intenta validar el formato cuando es posible.
phone: teléfono fijo o contacto principal. Visible en fichas y usado en flujos de comunicación.
mobile: teléfono móvil. Suele servir para mensajes SMS o alertas urgentes cuando difiere del teléfono principal.
street: primera línea de la dirección. Forma parte del bloque de dirección estándar usado en documentos y formularios.
street2: segunda línea de la dirección. Adecuada para pisos, urbanizaciones o información adicional del domicilio.
city: ciudad o población. El formato de direcciones puede variar según el país y la localización.
zip: código postal. Se usa para validar direcciones y calcular envíos o impuestos según localización.
state_id: provincia o estado (Many2one a res.country.state). El dominio suele filtrarse por country_id; no todos los países usan estados.
country_id: país (Many2one a res.country). Influye en el formato de la dirección, reglas fiscales y localización del partner.
is_company: booleano que indica si el registro es una empresa o una persona. Las empresas pueden tener contactos hijos; las personas pueden estar vinculadas a una compañía a través de parent_id.
parent_id: enlace Many2one a otro res.partner que representa la empresa relacionada. Permite heredar datos del padre y construir jerarquías empresa–contacto.
child_ids: relación One2many inversa de parent_id que lista los contactos asociados a una empresa; facilita navegar desde la empresa hacia sus personas de contacto.
company_id: Many2one a res.company. En entornos multiempresa indica a qué empresa pertenece el partner y condiciona visibilidad y acceso a datos.
vat: NIF o CIF del socio. Se valida según el formato del país y es crucial para facturación y cumplimiento fiscal; ciertos formatos indican exenciones.
customer_rank: entero que refleja la actividad como cliente. Odoo lo incrementa automáticamente cuando hay ventas; sirve para segmentar y priorizar listas de clientes.
supplier_rank: entero que muestra la actividad como proveedor. Se incrementa con pedidos de compra o facturas de proveedor; útil para identificar vendedores activos.
user_id: usuario responsable o comercial asignado al partner. Se utiliza en CRM, asignación de actividades y para gestionar relaciones comerciales.
type: selección que define el tipo de dirección para contactos hijos (Contact, Invoice, Delivery, Other). Determina qué dirección se usa en documentos y envíos.
ref: referencia interna o código del partner. Muy útil para enlazar con sistemas externos o para numeraciones personalizadas.
website: URL del sitio web del socio. Aparece en la ficha y se usa en contextos de e-commerce o comunicación pública.
comment: campo HTML para notas internas. Visible para usuarios internos; comúnmente usado para observaciones de venta o instrucciones especiales.
active: flag lógico para archivado. Si está a False, el socio queda archivado y oculto en vistas por defecto sin borrarse físicamente.
lang: idioma preferido del partner. Se usa para enviar documentos y correos en el idioma adecuado; puede heredarse del padre cuando procede.
image_1920: imagen o logotipo del partner en formato binario. Odoo almacena varias resoluciones y la usa en formularios, informes y páginas web.
category_id: etiquetas o categorías (Many2many a res.partner.category). Sirve para segmentación, campañas de marketing y filtros personalizados.
Ventas y CRM: al crear una cotización, el comercial selecciona un cliente de res.partner; ese mismo registro acompaña la oportunidad, el pedido y la factura. Campos como customer_rank y user_id alimentan informes y procesos de asignación.
Facturación: facturas y recibos referencian al partner para la dirección de facturación; el campo vat impacta en cálculos fiscales. Condiciones de pago y límites de crédito suelen gestionarse a nivel de partner.
Compras y proveedores: pedidos de compra y facturas de proveedor enlazan con res.partner. supplier_rank identifica proveedores activos y el buyer_id (si existe) asigna un responsable de gestión de proveedores.
Comercio electrónico y portal: los usuarios que se registran en la web generan partners que se usan para pedidos, presupuestos y acceso al portal; la información de contacto y dirección se toma del partner.
Multiempresa y consolidación: en instalaciones con varias empresas legales el mismo socio puede representarse con registros distintos por empresa. company_id y las reglas intercompañía deciden cómo se comparte y sincroniza la información.
Patrones de extensión para desarrolladores: herencia de modelos es la vía estándar. A través de ella se añaden campos, se extienden validaciones o se modifican comportamientos sin tocar el código base, lo que facilita mantenimiento y actualizaciones.
Herencia de modelos: define _inherit = 'res.partner' en tu módulo para ampliar la funcionalidad. Puedes declarar nuevos campos, sobreescribir métodos y agregar restricciones manteniendo tus cambios en un módulo separado.
Añadir campos: declara los campos nuevos en el modelo heredado usando tipos adecuados. Piensa en el alcance por empresa y usa company-dependent cuando corresponda en setups multiempresa.
Extensiones en Python: sobrescribe métodos como create, write o unlink para inyectar lógica; llama a super() y controla bien las dependencias de campos calculados para evitar efectos colaterales.
Odoo Studio: es útil para cambios rápidos sin programar, pero para lógica compleja o proyectos que deban sobrevivir a actualizaciones es preferible hacerlo mediante módulos personalizados y pruebas automatizadas.
Consejos prácticos de implementación: usa email_normalized o ref para deduplicar cuando importes contactos; mapea con cuidado los IDs externos en integraciones; aplica el tipo correcto a direcciones secundarias para que facturas y envíos usen la dirección adecuada.
Integraciones API: para sincronizar partners con sistemas externos emplea XML-RPC o JSON-RPC; res.partner está expuesto en la API y conviene mapear identificadores externos y normalizar datos antes de crear o actualizar registros.
Prefijos en campos personalizados: nombra los campos nuevos con el prefijo del módulo o con x_ para evitar colisiones con futuros desarrollos del core y facilitar la trazabilidad de los cambios.
Duplicados: crear nuevos partners sin comprobar los existentes es una causa frecuente de problemas. Usa campos como email_normalized o ref para buscar coincidencias antes de crear registros nuevos.
Confusión entre parent_id y company_id: recuerda que parent_id establece la jerarquía empresa–contacto mientras que company_id asigna la pertenencia del registro a una compañía en entornos multiempresa; usarlos mal provoca errores en visibilidad y heredabilidad de datos.
Tipo en contactos hijos: no olvidar definir type en contactos secundarios (Invoice, Delivery, Contact) ya que los documentos usan ese campo para escoger direcciones de facturación y envío.
Sobrescribir sin super(): nunca reescribas métodos base sin llamar a super(), porque puedes romper flujo de otros módulos y dificultar las futuras actualizaciones del sistema.
Campos obligatorios sin valores por defecto: al añadir campos requeridos sin defaults, las operaciones sobre registros existentes pueden fallar; siempre planifica migraciones o añade valores por defecto en las actualizaciones.
Conclusión: res.partner es el pilar para gestionar relaciones en Odoo. Conocer sus campos clave y las formas correctas de extenderlo te permitirá configurar procesos coherentes, integrar con terceros y minimizar problemas durante el ciclo de vida del proyecto.
Tanto si tu rol es funcional como técnico, invertir tiempo en entender res.partner te ahorrará incidencias, facilitará la automatización y mejorará la calidad de los datos en tu instancia Odoo.
¿Necesitas ayuda con Odoo?
Dasolo ofrece implantación, personalización y optimización de Odoo, con especial foco en integraciones API y desarrollo a medida. Contamos con experiencia práctica en la arquitectura de datos de Odoo y en modelos críticos como res.partner.
Si buscas apoyo en implantación, desarrollo de módulos o integraciones, podemos ayudarte a diseñar y ejecutar la solución adecuada.
Solicita una demo
y cuéntanos tu proyecto.
Tipo: Binario. Imagen o logotipo del socio. Odoo almacena varias resoluciones y tamaños. Se utiliza en formularios, plantillas de impresión y en la web.
28. category_id
Tipo: Many2many (res.partner.category). Etiquetas o categorías para segmentación. Útil para filtros, campañas de marketing y clasificaciones personalizadas.
Uso del modelo en flujos de negocio: res.partner alimenta ventas, CRM, compras, facturación y tienda online. Un mismo registro se utiliza desde la oportunidad hasta la factura; en compras y abastecimiento sirve para proveedores; en e-commerce los registros de usuarios se transforman en partners para pedidos y acceso al portal. En entornos multiempresa, la visibilidad y el tratamiento legal dependen del campo company_id y de las reglas de intercompañía.
1. Ventas y CRM
Cuando un comercial prepara un presupuesto, elige un cliente desde res.partner. Ese mismo registro sirve para el lead, la oportunidad y el pedido. Campos como customer_rank y user_id influyen en los informes y en la asignación de responsables.
2. Facturación
Facturas y recibos referencian un partner para la dirección de facturación. El campo vat se emplea en cálculos fiscales. Límite de crédito y condiciones de pago suelen almacenarse en el partner.
3. Compras y Proveedores
Pedidos de compra y facturas de proveedor enlazan con res.partner. El supplier_rank identifica a los proveedores activos. El campo buyer_id asigna el usuario responsable de la gestión del proveedor.
4. Comercio electrónico y Portal
Los visitantes de la web generan registros de partner al registrarse. Esos registros se usan para pedidos, presupuestos y acceso al portal. Las direcciones y contactos proceden del partner.
5. Multi-empresa y Consolidación
En entornos multiempresa, la misma entidad legal puede tener varios registros de partner según la compañía. company_id y las reglas intercompany determinan cómo se comparte la información.
Cómo los desarrolladores amplían este modelo: con herencia de modelos de Odoo (_inherit = 'res.partner') puedes añadir campos, modificar comportamientos y aplicar restricciones. Los campos nuevos se declaran en Python con el tipo adecuado (Char, Many2one, Boolean, Integer, Text, Selection). Para lógica de negocio se sobrescriben métodos como create o write usando super() y cuidando las dependencias de campos calculados.
Los desarrolladores amplían res.partner con varios patrones. La herencia de modelos en Odoo es la vía principal.
Herencia de modelo
Usa _inherit = 'res.partner' para extender el modelo. Añade campos, redefine métodos o incorpora restricciones. La herencia mantiene tus cambios en un módulo separado, facilitando futuras actualizaciones.
Añadir campos
Declara nuevos campos en tu modelo heredado. Elige el tipo correcto: Char, Many2one, Boolean, Integer, Text, Selection. Valora campos dependientes de la compañía en entornos multiempresa.
Extensiones en Python
Redefine create, write o unlink para incluir lógica personalizada. Llama a super() para ejecutar la implementación original. Ten cuidado con campos calculados y sus dependencias.
Odoo Studio
Odoo Studio permite añadir campos sin programar. Ideal para cambios rápidos. Para lógica compleja o mantenibilidad a largo plazo, los módulos personalizados son preferibles.
Buenas prácticas: crea primero la ficha de la empresa y luego los contactos hijos; establece country_id para que las direcciones y los impuestos funcionen correctamente; usa commercial_partner_id para agrupar entidades a nivel contable; nombra campos personalizados con prefijos de módulo (o x_) y evita lógica compleja sin pruebas. Asegura también que los cambios en modelos respeten multi-empresa y que las validaciones sean compatibles con datos existentes.
- Usa correctamente la jerarquía empresa-contacto. Crea primero la compañía y después añade contactos con parent_id.
- Configura country_id para que las direcciones se formateen bien y los impuestos se apliquen correctamente.
- Emplea commercial_partner_id cuando necesites la entidad de nivel superior para agrupaciones (por ejemplo, crédito o informes).
- Al integrar APIs, usa XML-RPC o JSON-RPC. El modelo res.partner está totalmente expuesto. Mapea los identificadores externos con cuidado.
- Para campos personalizados, usa el prefijo
x_o el prefijo de tu módulo para evitar colisiones en futuras versiones de Odoo.
Errores habituales a evitar: crear registros duplicados en lugar de buscarlos, confundir parent_id con company_id, olvidar asignar el tipo correcto a contactos secundarios, sobreescribir métodos base sin llamar a super(), y añadir campos obligatorios sin valores por defecto. Cada uno de estos fallos provoca problemas en facturación, envío y en la estabilidad del sistema tras actualizaciones.
- Crear partners duplicados en lugar de buscar existentes. Utiliza
email_normalizedorefpara deduplicar. - Confundir parent_id con company_id. parent_id vincula contacto y empresa; company_id pertenece al contexto multiempresa de Odoo.
- Olvidar fijar el type en contactos secundarios. Las direcciones de facturación y entrega necesitan el tipo correcto para generar documentos válidos.
- Sobrescribir métodos core sin llamar a super(). Esto puede romper otros módulos o complicar futuras actualizaciones.
- Añadir campos personalizados obligatorios sin valores por defecto. Los registros existentes fallarán al validar en una actualización.
Resumen final: res.partner es el núcleo donde Odoo guarda toda la información sobre clientes, proveedores y contactos. Dominar sus campos y cómo se extiende te permite configurar procesos, integrar sistemas y evitar errores comunes. Con buenas prácticas en la creación y extensión del modelo, ahorrarás tiempo y reducirás problemas durante actualizaciones y migraciones.
El modelo res.partner es el núcleo de Odoo. Guarda contactos, clientes y proveedores. Entender sus campos y cómo se amplía te ayudará a configurar, personalizar e integrar Odoo con menos errores.
Tanto si eres consultor funcional que mapea procesos como desarrollador que crea módulos, dominar res.partner te ahorrará tiempo y problemas.
¿Necesitas ayuda con tu implementación de Odoo?
Dasolo ayuda a empresas a implantar, personalizar y optimizar Odoo. Nos especializamos en integraciones por API y desarrollo sobre Odoo. Nuestro equipo conoce en profundidad la arquitectura de datos y modelos como res.partner.
Si necesitas apoyo con tu implementación, módulos a medida o integraciones, estamos a tu disposición. Reserva una demo para hablar sobre tu proyecto.