Los registros de productos, los componentes del kit y las imágenes a las que apuntan se transfieren desde Odoo a Inriver, por lo que el catálogo describe lo que recibe el cliente en lugar de lo que el almacén selecciona en cada momento.
Odoo puede vender un kit como un solo producto y presentarlo como varios, lo cual es lógico para un almacén pero confuso para un catálogo. Inriver debe decidir si el cliente compra un solo artículo con especificaciones o un conjunto de piezas con sus propias páginas, y si nadie se decide, aparecen ambas. Un comprador compara un kit con uno de sus componentes, las imágenes pertenecen a las piezas en lugar del producto, y la página a la que accede el cliente no es la que se pretendía publicar. Conectar Odoo e Inriver define la estructura antes de que se publique nada.

Un kit de Odoo llega a Inriver como el producto que compra un cliente, y sus componentes se mantienen como relaciones, por lo que el catálogo muestra una página en lugar de una página por cada componente.
Las imágenes y los documentos se utilizan como referencias, no como copias, por lo que el contenido que muestra una página es el que alguien aprobó y actualizarlo no significa volver a publicarlo.
Los componentes que un cliente puede comprar por separado conservan sus propios registros de Inriver, de modo que una pieza de repuesto se puede encontrar fácilmente sin que compita con el kit al que pertenece.
Dado que la forma se decide antes de la publicación, nadie descubre en el momento del lanzamiento que el mismo producto físico existe dos veces en el catálogo con dos códigos diferentes.
Alumio lee un kit de Odoo con sus componentes y crea el producto Inriver que compra el cliente, manteniendo las piezas unidas mediante el tipo de relación que expone el modelo de Inriver, de modo que el catálogo incluye una página con la composición detrás.
Las referencias a los recursos viajan de Odoo a Inriver en lugar de los archivos en sí, por lo que una página apunta a la imagen aprobada en la ubicación donde se encuentra y un reemplazo llega a todos los canales sin que se ejecute una segunda importación para cada uno.
Un componente que también se vende por separado mantiene su propio registro de Inriver vinculado al kit, por lo que un cliente que busca una pieza de repuesto la encuentra sin el kit y la pieza parece ser el mismo producto.
Alumio se sitúa entre los canales de venta y los sistemas de cumplimiento como una columna vertebral de integración gobernada. Los pedidos se enrutan, transforman y validan, mientras que las actualizaciones de estado regresan a cada canal.
Autentique sus sistemas utilizando los conectores preconfigurados de Alumio. Elija entre más de 200 paquetes de conectores en el marketplace, además de integraciones personalizadas ilimitadas.
Defina cómo se asignan los campos de datos entre sistemas en una interfaz visual. Ajuste formatos, enriquezca registros y aplique lógica de negocio, sin necesidad de código personalizado.
Configure los flujos para que se ejecuten en tiempo real según eventos, según un horario o ambos. Reduzca la entrada manual de datos y deje que Alumio gestione el movimiento y la transformación entre sistemas.
Una vez que su primera integración esté activa, añadir su ERP, PIM, WMS o CRM se conecta al mismo centro. Los flujos existentes siguen funcionando. Sin necesidad de reconstruir desde cero.
Lo que el catálogo necesita y el ERP nunca podrá contener es la guía, y para la mayoría de las empresas, esta es la versión impresa. Una empresa de producción de catálogos es una adición común, ya que Inriver contiene el contenido del producto final y la impresión requiere maquetación y corrección, mientras que Odoo no tiene ninguna opinión al respecto. Alumio mantiene esa conexión junto con la guía, de modo que la página impresa y la página web se crean a partir del mismo producto aprobado.
Las referencias a los activos son prioritarias, ya que un error en ellas implica volver a publicar todo posteriormente. Alumio lee los registros de productos de Odoo, los componentes del kit y las referencias a la ubicación de las imágenes y los documentos, y los escribe en los atributos de Inriver que aceptan una referencia, de modo que una página apunta al activo almacenado en lugar de a una copia. Los precios y los códigos se actualizan según el calendario que usted defina, y los productos que aún no están listos permanecen en Inriver.
No, y la distinción útil radica en que se trata de una referencia en lugar de un archivo. Alumio escribe el puntero que indica la ubicación de un recurso de Odoo en lugar de mover el archivo, lo cual forma parte de la configuración de la interfaz, y es por eso que una imagen reemplazada no requiere una segunda pasada por cada canal. Dado que los modelos de Inriver se construyen por implementación, la lógica personalizada permanece disponible a través del Code Transformer cuando un tipo de relación no tiene un equivalente directo.
El producto que compra el cliente, con sus componentes asociados, se mantiene como una relación entre ellos. Odoo puede vender un kit como un solo artículo o presentarlo como varios, por lo que el catálogo debe elegir cuál de ellos describe cada página. Publicar ambos presenta el kit y sus componentes al mismo comprador. Decidir que Inriver contenga el producto vendible y vincule los componentes garantiza que el catálogo coincida con lo que llega en la caja.
El fallo se debe a un enlace roto en el archivo, y la página sigue cargando, lo que dificulta su detección. Tanto el registro de Odoo como la referencia que falló se conservan, la alerta es inmediata e incluye el producto y el motivo, y se ejecutan reintentos donde esté configurado. La referencia anterior permanece activa, por lo que ninguna página de Inriver se publica con una imagen faltante y no se pierde ningún registro.
Habla con un especialista en integración de Alumio. Diseñaremos la arquitectura adecuada para tus sistemas, a la escala correcta, para que tus operaciones sigan siendo fiables ante cualquier cambio.