Sistema integral de gestión de datos de producto multi-proveedor

Resumen

Una empresa de distribución B2B trabajaba con varios proveedores externos cuyos catálogos llegaban en formatos distintos y se cargaban en gran medida a mano. El trabajo consistió en diseñar un sistema de ingesta, normalización y consolidación que compara automáticamente precios entre proveedores, selecciona la mejor oferta según reglas de negocio y mantiene sincronizados ERP (Odoo) y plataforma eCommerce a medida, eliminando reconciliación manual y errores de pricing.

Contexto

La empresa opera en un modelo de distribución que depende de varios proveedores externos. Cada proveedor entrega su catálogo en un formato propio: archivos CSV con codificaciones distintas, XML por FTP, feeds JSON vía API, hojas de cálculo enviadas por correo. Los productos se solapan entre proveedores, pero los identificadores, atributos y unidades no son consistentes entre fuentes.

El ERP — basado en Odoo — actúa como sistema central de negocio (compras, stock, facturación). La plataforma eCommerce, desarrollada a medida, consume datos del ERP para presentar el catálogo a los clientes finales. Cualquier inconsistencia entre lo que muestra la web y lo que el ERP considera vigente tiene impacto directo en márgenes, en la experiencia de compra y en el trabajo administrativo posterior.

Problema

El proceso anterior dependía de scripts dispersos y de carga manual:

• Cada proveedor se trataba como un caso aparte, sin patrón común.
• Los precios no se comparaban automáticamente: se elegía proveedor por inercia o criterio individual.
• Los atributos llegaban sin normalizar: marcas escritas de varias formas, unidades mezcladas (g/kg, ml/l), categorías incompatibles entre fuentes.
• Las cargas no eran idempotentes; reejecutar una importación podía duplicar registros o pisar datos válidos.
• La plataforma eCommerce reflejaba con retraso los cambios de precio y stock.
• El equipo dedicaba horas semanales a reconciliación manual sin valor añadido.

Un parche puntual no resolvía la raíz: el problema era estructural. Cada proveedor nuevo hacía el sistema más frágil en lugar de más capaz.

Objetivos

• Unificar la ingesta de catálogos en un único pipeline.
• Comparar precios automáticamente y seleccionar la mejor oferta según reglas explícitas.
• Garantizar idempotencia en las cargas para poder reejecutar sin riesgo.
• Normalizar datos antes de inyectarlos en el ERP.
• Mantener sincronizados ERP y eCommerce con trazabilidad.
• Reducir la carga operativa del equipo y preparar el sistema para incorporar proveedores nuevos con bajo coste.

Enfoque técnico

El sistema se diseñó por capas, separando explícitamente lo que cambia (cada proveedor) de lo que debe ser estable (la lógica de negocio).

Capa de ingesta (adaptadores por proveedor). Cada proveedor tiene un conector específico que solo se ocupa de obtener el catálogo en su formato nativo (FTP, API REST, descarga programada, parseo de archivos) y volcarlo en un esquema intermedio común. Esta capa es la única que conoce las particularidades de cada fuente. Añadir un proveedor nuevo es añadir un adaptador, no tocar el núcleo.

Capa de normalización. Los catálogos crudos pasan por limpieza y validación: unificación de unidades, normalización de marcas y categorías mediante tablas de mapeo editables, detección de códigos equivalentes (EAN, referencia interna, SKU del fabricante) y validación de campos obligatorios. Los registros que no superan la validación se aíslan en una cola de errores para revisión, sin bloquear el resto del lote.

Capa de consolidación y selección de mejor precio. Una vez normalizados, los productos equivalentes de distintos proveedores se agrupan por identificador canónico. Sobre ese grupo se aplica una política configurable que considera precio neto, disponibilidad, plazo de entrega y fiabilidad histórica del proveedor. El resultado es un único registro “ganador” por producto, con trazabilidad de qué proveedor se eligió y bajo qué criterio.

Integración con Odoo. La sincronización con el ERP usa operaciones idempotentes: cada producto consolidado se identifica por una clave externa estable, y la sincronización distingue entre crear, actualizar y desactivar. Se implementaron módulos personalizados para extender el modelo de productos con información de proveedores alternativos y el histórico de selección de precios, sin romper la lógica estándar del ERP.

Salida hacia eCommerce. La plataforma consume una vista enriquecida y preparada para el frontend, no los datos crudos del ERP. Esto permite añadir campos calculados (tramos de precio, etiquetas, agrupaciones de variantes) sin contaminar el modelo del ERP y mantiene el rendimiento de la web independiente del estado del ERP en cada momento.

Observabilidad. Cada ejecución del pipeline deja métricas y logs estructurados: registros entrados por proveedor, descartados, productos que cambiaron de proveedor ganador respecto al lote anterior. Convierte un proceso opaco en uno auditable.

Decisiones y trade-offs

Se descartó construir un sistema “completo” que cubriera todos los casos posibles desde el inicio. Se priorizó cubrir los proveedores con mayor volumen y dejar el resto para iteraciones posteriores, con la arquitectura ya preparada para absorberlos.

Se evitó la comparación de precios en tiempo real contra los proveedores: el coste operativo y la dependencia de APIs externas no lo justificaban para este caso. La comparación se ejecuta por lotes programados, lo que aporta estabilidad y desacopla los tiempos de respuesta de la web del estado de cada proveedor.

La normalización se mantiene declarativa, en tablas de mapeo editables por el equipo de negocio, en lugar de estar incrustada en código. Añade algo de configuración inicial, pero permite que los cambios habituales (una marca nueva, una categoría renombrada) no requieran intervención técnica.

Finalmente, se decidió no reescribir los módulos estándar de Odoo, sino extenderlos. La integración resulta más mantenible a medio plazo y reduce el riesgo en futuras actualizaciones del ERP.

Resultado

• La actualización de catálogo pasó de tarea manual recurrente a ejecución desatendida.
• La selección de mejor precio dejó de depender del criterio individual y pasó a ser una política trazable y reproducible.
• Los tiempos de propagación de cambios de proveedor al eCommerce se redujeron de forma notable.
• El equipo recuperó horas semanales antes dedicadas a reconciliación manual.
• Incorporar un proveedor nuevo dejó de ser un proyecto y pasó a ser una tarea acotada de añadir un adaptador.
• Las discrepancias entre ERP y web se redujeron de forma significativa, con trazabilidad para investigar las restantes.

Stack técnico

• Plataforma Java
• Spring Framework / Spring Batch / Spring Data / Spring Web
• PostgreSQL
• Conectores FTP, REST y parsers CSV/XML/JSON
• Procesamiento por lotes con control de idempotencia
• Plataforma eCommerce a medida integrada vía API
• Logging estructurado y métricas de ejecución

Qué demuestra este caso

Este caso demuestra capacidad para abordar un problema de integración heterogéneo desde una perspectiva de arquitectura: separar lo que cambia (cada proveedor) de lo que debe ser estable (la lógica de negocio), convertir reglas implícitas en políticas explícitas y trazables, y dejar el sistema preparado para crecer sin que cada nueva incorporación añada deuda técnica. Combina conocimiento profundo de Odoo, diseño de pipelines de datos y criterio de negocio para decidir dónde invertir el esfuerzo y dónde no.

Versión corta para tarjeta

Título: Consolidación de catálogos multi-proveedor para ERP y eCommerce

Sector: Distribución B2B con múltiples proveedores

Problema: Catálogos heterogéneos cargados manualmente, sin comparación sistemática de precios ni sincronización fiable con ERP y web.

Enfoque técnico: Pipeline por capas con adaptadores por proveedor, normalización declarativa, consolidación con política de mejor precio e integración idempotente con Odoo y eCommerce.

Resultado: Proceso desatendido, selección de precio trazable, sincronización fiable entre ERP y web y arquitectura preparada para nuevos proveedores con bajo coste.

Tags: Odoo, ERP, Integración multi-proveedor, Pipelines de datos, eCommerce, Backend

CTA opcional

Si trabajas con varios proveedores y la gestión del catálogo se está convirtiendo en un cuello de botella —datos inconsistentes, precios desactualizados, cargas manuales recurrentes— puedo ayudarte a analizar el flujo actual y plantear una arquitectura realista que escale con tu negocio.