Si en el primer blog hablamos de cómo obtener los datos de Odoo y en el segundo de cómo transformarlos, aquí llega el punto donde muchos proyectos se ganan (o se rompen): el modelado.

Porque una cosa es “tener datos” y otra muy distinta es tener un modelo semántico que cualquiera en la empresa pueda usar sin romper filtros, sin duplicar importes y sin que cada gráfico cuente una historia diferente.

Odoo, por naturaleza, es un ERP súper flexible… pero también muy “ERP”: lleno de relaciones, tablas técnicas y campos pensados para operar, no para analizar. El objetivo de este blog es que te lleves un método claro para pasar de “lo que devuelve Odoo” a “lo que tu negocio entiende”.

Por qué el modelado es crítico cuando vienes de Odoo

Odoo está diseñado para transaccionar: crear pedidos, facturas, movimientos de stock, partes de horas… Eso implica:

• Muchas relaciones (cliente ↔ pedidos ↔ líneas ↔ producto ↔ categoría…).
• Campos que son técnicos o dependen de módulos.
• Tablas con distintos “niveles de detalle” (pedido vs línea de pedido).
• Fechas múltiples para el mismo proceso (pedido, confirmación, envío, factura, pago).

Si llevas eso “tal cual” a Power BI, lo típico es acabar con:

• Relaciones ambiguas.
• Filtros que se comportan «raro».
• Duplicidades.
• Y modelos imposibles de mantener.

Ahí es donde recomendamos una idea simple: Odoo te da el dato, Power BI necesita el modelo.

Y, si además usas una capa de negocio (como nuestra Sixphere API REST), consigues que el dato ya venga más “analizable”, sin obligar a Power BI (o a tu equipo) a conocer las entrañas del modelo de Odoo.

Paso a paso: cómo diseñar tu modelo desde cero

1. Empieza por la pregunta, no por la tabla.

Antes de crear relaciones, define 2–4 preguntas típicas:

• ¿Ventas por mes, cliente y producto?
• ¿Margen por familia y comercial?
• ¿Facturación cobrada vs pendiente?
• ¿Stock y rotación por almacén?

Esto te marca qué “hecho” necesitas y qué dimensiones son obligatorias.

2. Define el grano de tu tabla

Esto es clave. El “grano” es el nivel de detalle de una fila.

Ejemplos típicos en Odoo:

• Ventas: una fila por línea de pedido.
• Facturación: una fila por línea de factura.
• Compras: una fila por línea de pedido de compra.
• Timesheets: una fila por parte de horas.

4. Crea tablas “de contexto” claras

Piensa en tu informe como si fuera un Excel bien montado:

• Tienes una tabla grande con todo lo que pasa (ventas, líneas de pedido, facturas…).
• Y luego tienes tablas más pequeñas que sirven para describir esas ventas: quién compra, qué compra, quién lo vendió, en qué empresa, desde qué almacén, etc.

Esas tablas “descriptivas” suelen ser: clientes, productos, comerciales / usuarios, compañías, almacenes o proyectos (si aplica). La idea que subyace es clara: cada cosa tiene su ficha.

Y lo importante para que Power BI no se líe es que cada ficha tenga un identificador único (el ID) para “enganchar” bien con la tabla grande (esto cuadra perfecto con lo que ya hicimos en transformación: separar “id” y “name”.)

4. Conecta las tablas con sentido (y sin montar una telaraña)

Aquí aplica una regla muy práctica: cuantas menos conexiones raras, mejor.

Lo que suele funcionar casi siempre: las tablas “pequeñas” (clientes, productos, fechas…) conectan con la tabla “grande” (ventas, facturas…).

La filosofía es: modelo simple = informe estable.

¿Dónde encaja Sixphere aquí?

Aquí es donde una API “de negocio” marca la diferencia.

La Sixphere API REST está pensada precisamente para abstraer el modelo complejo de Odoo y exponer de forma securizada sus endpoints funcionales (más cercanos a tu proceso de negocio), evitando integraciones “tricky” donde el sistema externo tiene que aprender Odoo.