Importación a Odoo con IA: valida el mapeo de precios

Volver

Kevin Riedl

14 minutos de lectura · 5 nov 2026
Última revisión 5 de noviembre de 2026

Siguiente

Supón que un archivo de proveedor indica 1.200,00 € por una caja de 24 unidades. El mapeo propuesto calcula un número perfectamente válido, 50,00, pero mantiene «caja» como unidad de compra de destino. La operación aritmética es correcta. El precio resultante representa una condición distinta de la ofrecida por el proveedor.

Usa IA para proponer el mapeo de una importación a Odoo y después contrástalo con definiciones de origen y tablas de referencia aprobadas de forma independiente. Conserva la identidad de los registros existentes y la base del precio de cada unidad de compra. Deja los significados sin resolver en manos del responsable de los datos y exige una prueba controlada en Odoo antes de autorizar la importación.

Investigación comprobada: 5 de noviembre de 2026. Los datos del producto proceden de documentación oficial de Odoo 20. Ejecutamos doce casos sintéticos de mapeo con Python y aritmética decimal. Los candidatos se construyeron manualmente; no los generó una IA. No importamos datos a Odoo ni probamos su conversión de unidades. Las comprobaciones previstas en Odoo siguen en NOT_RUN.

¿Qué debe hacer la IA en el mapeo de una importación a Odoo?

La IA puede proponer correspondencias entre columnas de origen y campos de destino y señalar filas que necesitan una explicación. Un contrato de mapeo revisado por separado debe determinar si la propuesta es aceptable. El responsable de los datos debe fijar los significados, transformaciones permitidas e identificadores de actualización antes de modificar registros empresariales.

En una actualización de tarifas, «precio» no basta. Necesitas saber qué cantidad cubre ese importe y qué línea existente del proveedor debe cambiar. Una propuesta que rellena esas lagunas sin indicarlo va más allá de lo que demuestra el archivo de origen.

La guía oficial de importación utiliza ID externos para identificar registros y reconstruir relaciones. Nuestro contrato de aceptación añade los significados de negocio que el identificador, por sí solo, no puede aportar.

Este artículo trata la decisión previa a importar. La guía de aceptación de migraciones cubre la comparación posterior de los registros y procesos transferidos. Las actualizaciones recurrentes de fechas de entrega tienen otra decisión de arquitectura, explicada en reglas de Odoo, n8n o un agente de IA.

¿Qué significados del origen debes fijar primero?

Fija los identificadores y las convenciones de los valores antes de transformar precios de proveedor. Conserva los identificadores como texto, define la base del precio y de la cantidad mínima, y resuelve productos y proveedores mediante referencias aprobadas. Si el origen no establece el formato de fecha o el tamaño de la caja, hace falta una decisión de su responsable.

Nuestro archivo ficticio tiene dos líneas. Ambas usan el código de proveedor 0042 para la empresa A. Otra entrada de la tabla de referencia usa ese mismo código para la empresa B. Los códigos de producto 00123 y 00124 son cadenas de texto cuyos ceros iniciales forman parte del identificador acordado.

La regla de origen admite expresamente una coma decimal y, de forma opcional, un punto para agrupar los miles. Exige dos cifras decimales. Con esa regla, 1.200,00 se convierte en el valor decimal 1200.00. El analizador tiene un alcance deliberadamente limitado; no detecta cualquier formato numérico de una hoja de cálculo.

La convención de fecha también se establece por separado. Con día/mes/año aprobado, 01/03/2026 se convierte en 2026-03-01. Si falta esa convención, el validador deja el caso pendiente de aclaración. La interpretación preferida de un modelo no resuelve un valor ambiguo del origen.

Separa la identidad de la línea de tarifa de la identidad del producto. En un catálogo real, un proveedor puede tener varias condiciones de precio para un producto. La referencia aprobada del ejemplo identifica exactamente dos líneas existentes; no propone «proveedor más código de producto» como identificador universal para todas las escalas de cantidad o periodos de validez.

¿Por qué deben mantenerse unidos el precio y la unidad de compra?

El precio de proveedor y su unidad de compra expresan juntos una condición comercial. Cambiar el importe sin cambiar la unidad, o la unidad sin el importe, puede producir una oferta distinta. La cantidad mínima debe conservar esa misma base. Aprueba el conjunto como una sola decisión de mapeo antes de normalizar valores.

La documentación de unidades de medida de Odoo sitúa las unidades de compra en las líneas de proveedor y las distingue de las unidades de inventario. La unidad de destino correcta depende de la configuración real del producto y del proveedor.

Para L01, 1.200,00 € ÷ 24 unidades = 50,00 € por unidad. Su mínimo de 2 cajas equivale a 48 unidades. El mapeo aprobado conserva la base por caja: unidad de compra caja de 24, precio 1.200,00 y cantidad mínima 2.

Para L02, 48,00 € ÷ 12 = 4,00 € por unidad, y 3 cajas contienen 36 unidades. Estos cálculos ayudan a comprobar el significado del origen. No son campos de precio adicionales que deban importarse junto al precio por caja que se conserva.

Una conversión a unidades individuales podría ser válida si se aprueba de forma independiente. Necesitaría el precio y la cantidad mínima correspondientes, y pruebas de que el proceso de destino utiliza correctamente esa base. El validador suministrado aplica un contrato concreto; no prohíbe todos los mapeos alternativos.

¿Cómo validas el mapeo de forma independiente?

Valida el candidato con reglas de origen y tablas de referencia aprobadas por separado. Compara cada fila incluida con sus campos normalizados esperados y conserva tanto la cobertura de filas como la identidad exacta del destino. La confianza declarada, la explicación del candidato o su afirmación de haberse revisado no determinan si la comparación es correcta.

El archivo descargable contiene filas de origen, un objeto de reglas aprobadas y filas candidatas como entradas separadas. El validador obtiene los valores esperados a partir de esas reglas, resuelve las referencias del proveedor dentro de la empresa y compara campo por campo. Cada diferencia incluye el identificador de la fila de origen para localizarla.

La independencia se refiere a quién responde por la decisión. Si el mismo modelo inventa el factor de una caja y lo introduce tanto en el mapeo como en su supuesta tabla de referencia, dos resultados coincidentes siguen basándose en una suposición sin respaldo. El responsable debe vincular la definición del embalaje con una especificación del proveedor o un registro de producto aprobado.

Antes de facilitar datos reales de proveedores a un servicio de IA, aplica la decisión aprobada sobre el recorrido de los datos para ese servicio. La revisión de residencia de datos en Odoo IA trata esa cuestión por separado. Este ejemplo contiene únicamente registros inventados.

¿Qué mostraron las doce comprobaciones del mapeo?

Los doce casos construidos recibieron la clasificación esperada: uno READY_FOR_REHEARSAL, ocho REJECT y tres HOLD. Esto demuestra el comportamiento del validador suministrado con los datos declarados del ejemplo. No mide la precisión del mapeo generado por IA ni demuestra que una importación a Odoo vaya a funcionar.

Descarga el validador y el archivo de casos en el mismo directorio y ejecuta:

python3 mapping-validator.py

Compara la salida con los resultados registrados. Que el proceso termine correctamente significa que coincidieron las doce clasificaciones, incluidos los casos rechazados o pendientes de forma deliberada. No supone aprobar una importación.

El script admite la estructura JSON y las convenciones de origen declaradas. No abre hojas de cálculo arbitrarias ni descubre campos nativos. Tampoco contempla todas las reglas fiscales, monetarias y de precios. Sus nombres de campo normalizados son un formato intermedio para revisión, no un CSV listo para subir a Odoo.

¿Cuándo debes dejar el mapeo pendiente de revisión?

Deja el mapeo pendiente cuando falte un significado autorizado del origen o una referencia de destino. Recházalo cuando el significado aprobado sea conocido y la propuesta lo contradiga. La diferencia determina el siguiente paso: un precio incorrecto necesita un mapeo corregido; un tamaño de caja desconocido necesita evidencia del responsable de los datos.

El registro de revisión del mapeo separa la transformación propuesta de la evidencia de aprobación. Anota la identidad del archivo de origen y la revisión del mapeo. Después, asigna cada campo sin resolver a la persona que puede aclararlo. Cada caso pendiente debe plantear una pregunta concreta: «¿El mínimo de 2 corresponde a cajas o a unidades?».

No conviertas una referencia de producto ausente en la creación automática de un producto si esa conducta no pertenece al alcance aprobado. Este ejemplo actualiza líneas de tarifa existentes. Crear un producto o un registro de precio nuevo cambia la decisión y necesita criterios de aceptación propios.

El validador tampoco puede demostrar que una referencia aprobada sea verdadera. Si se aprobó una referencia de proveedor equivocada para la empresa A, el candidato puede coincidir con ella perfectamente. Revisa los datos de referencia antes de confiar en una comparación correcta y conserva la evidencia que respalda la relación elegida.

¿Qué debe demostrar la prueba en Odoo?

La prueba en Odoo debe demostrar que el mapeo revisado utiliza los campos reales de destino y produce el comportamiento previsto de las tarifas. Comprueba referencias y unidades en la instalación configurada. Después verifica las actualizaciones y un borrador de compra representativo. El validador sintético solo demuestra que la propuesta intermedia coincide con su contrato.

La guía de listas de precios de proveedor recomienda exportar registros existentes como plantilla y distingue el precio de la cantidad mínima. Parte de esa estructura del destino, en vez de cambiar los nombres de los campos del ejemplo y asumir que son columnas de importación nativas.

El paquete de aceptación en Odoo contiene catorce comprobaciones propuestas, todas en NOT_RUN y con aceptación PENDING. Los campos de evidencia real y revisor permanecen vacíos.

Revisar un borrador de compra no autoriza enviar ni confirmar un pedido. Mantén esas acciones fuera de la prueba, salvo que el responsable de negocio las incluya por separado. Aquí se busca observar las consecuencias del mapeo antes de una actualización en producción.

Conserva el archivo exacto utilizado en la prueba y la revisión aprobada de su transformación. Si el proveedor cambia el significado de una columna el mes siguiente, reconocer su encabezado no demuestra que la regla anterior siga siendo válida. Revisa el mapeo afectado y repite las comprobaciones correspondientes.

¿Qué aprobaríamos antes de importar?

Aprobaríamos una revisión concreta del mapeo después de resolver los significados de origen y las identidades de destino, rechazar los contraejemplos conocidos y obtener evidencia en Odoo de la actualización prevista. Una fila sin resolver permanece pendiente. La evidencia debe identificar a quien acepta las condiciones del proveedor y a quien responde por la importación.

Empieza por el conjunto de precio, unidad y cantidad mínima, junto con la identidad exacta de la línea existente. Esas decisiones determinan si una transformación aparentemente correcta conserva las condiciones del proveedor y actualiza el registro previsto. Añade las comprobaciones de formato y relaciones, manteniendo el archivo de origen disponible para la revisión.

Para la decisión de publicación más amplia, utiliza la lista de comprobación de calidad del software. El servicio de aseguramiento de la calidad de software de Wavect puede ayudarte a definir y revisar de forma independiente la evidencia de aceptación de un flujo de importación. Aporta la especificación de origen y los mapeos cuyo significado siga en discusión.