Varios orígenes
API, SFTP, hojas, bases de proveedor: cada uno con su suciedad.
Escala
Cuando tienes varios proveedores, precios por canal y destinos que no hablan el mismo idioma de ficha, el CSV deja de ser una solución y se convierte en un riesgo.
Cuándo hace falta
API, SFTP, hojas, bases de proveedor: cada uno con su suciedad.
Lo que se puede vender en un sitio no se puede en otro; el precio tampoco coincide.
Necesitas saber qué se publicó, qué falló y qué hay que retirar, canal a canal.
Arquitectura
Prueba (anonimizada)
En producción hemos operado el patrón PIM + publishers para catálogos de recambio con varios orígenes y destinos (marketplaces generalistas, B2B y canales de ocasión). Sin nombres ni cifras identificables: lo que importa es que el diseño aguanta decenas de miles de referencias con reglas distintas por canal.
Dudas
Un feed suele tener un origen y un destino. Un PIM absorbe varios orígenes, normaliza, aplica reglas por canal y deja que cada publisher publique y confirme (ACK) por su lado.
No necesariamente. El PIM puede alimentarse de APIs, SFTP, hojas o bases, y publicar a marketplaces mientras el ERP sigue siendo el dueño de stock y pedidos —o al revés, según el diseño.
Es donde más lo hemos aplicado (compatibilidades, multiproveedor, precios por canal), pero el patrón vale para cualquier catálogo grande con reglas distintas por destino.
Sí: un origen y un canal, con el contrato de salida ya pensado para el segundo. Evita rehacer el catálogo cada vez que abres un marketplace.
Cuéntanos orígenes y destinos. Si con un feed o un hub basta, no empujaremos un PIM.