El coste oculto de una mala integración de feeds de producto

Última actualización: 7 de julio de 2026. Escrito a partir de la construcción de integraciones de importación de proveedores y sincronización con marketplaces para PrestaShop 1.7, 8 y 9. Las consultas de diagnóstico que aparecen más abajo se ejecutan sobre tablas del núcleo de PrestaShop que puedes inspeccionar en tu propia tienda.

Autor: equipo editorial de mypresta.rocks — desarrollamos módulos para PrestaShop y gestionamos tiendas PrestaShop.

Una mala integración de feed de productos es ese tipo poco común de fallo que te cuesta dinero mientras todo parece ir bien. Nada da error: ni banner rojo, ni cron fallido, ni ticket de soporte. El catálogo simplemente empieza a mentir en silencio a los clientes con el precio equivocado, el stock equivocado, la disponibilidad equivocada, y cada pequeña mentira es un pedido cancelado, una devolución o un contracargo esperando a ocurrir.

Esto trata sobre la clase de riesgo: lo que una integración de importación entrante o de sincronización con marketplace barata, opaca o sin mantenimiento le hace a una tienda, y lo que una de confianza hace de otra manera. Si ya usas una y solo quieres saber si te está pasando, salta directamente a las dos consultas — encontrarán el daño en tu propio catálogo en cosa de un minuto.

Comparativa rápida: feed barato frente a feed de confianza

1. Stock fantasma: vender existencias que no tienes

La forma más común en que un módulo de importación barato desangra una tienda es el stock fantasma — una cantidad de stock en el escaparate que no corresponde a nada real en un almacén. Ocurre cuando una sincronización escribe una cantidad que no puede atribuir al producto correcto: se mapea la columna equivocada, se lee una marca de "disponible" como si fuera un recuento, o se escribe la cantidad de un producto sobre otro porque el emparejamiento fue erróneo. Dos variantes: fantasma (un número que nunca correspondió a la realidad) y obsoleto (un número que fue cierto en su momento, pero el feed dejó de actualizarlo y la tienda siguió vendiendo sobre un recuento congelado). En cualquier caso el número parece plausible, así que nadie lo cuestiona — hasta que estás cancelando pedidos que no puedes cumplir, asumiendo devoluciones y, en los marketplaces, encajando un golpe en la tasa de defectos que daña la salud de la cuenta.

La trampa específica de PrestaShop: el stock real vive en ps_stock_available (por producto, por combinación, delimitado por id_shop o id_shop_group), y debe escribirse a través de StockAvailable::setQuantity() para que se dispare el hook actionUpdateQuantity y el estado dependiente se mantenga coherente. Una importación barata que escribe directamente la columna heredada ps_product.quantity se desincroniza de lo que el escaparate realmente lee. Combina eso con la opción "permitir pedidos cuando no hay stock" (PS_ORDER_OUT_OF_STOCK, global o por producto) y una cantidad fantasma o puesta a cero se convierte directamente en una sobreventa en tiempo real. Una integración de confianza solo escribe una cantidad que puede atribuir a una línea de origen correctamente emparejada, la contrasta con el valor anterior como control de coherencia, y retiene todo aquello de lo que no puede responder en lugar de venderlo.

2. La cara: un listado de marketplace dañado

Cuando tu catálogo alimenta un marketplace — Allegro, Amazon, eBay — la integración ya no se limita a editar filas en tu base de datos. Está manipulando un activo vivo en la plataforma de otra empresa, bajo sus reglas. Un solo envío erróneo puede infringir esas reglas: un precio que la plataforma interpreta como inválido, un valor de stock enviado a cero que finaliza la oferta, un identificador mal mapeado que hace que la oferta parezca un producto distinto.

Conviene ser preciso sobre lo que realmente está en juego, porque las plataformas difieren. Lo que puedes perder es el impulso a nivel de oferta — la antigüedad del listado, la posición, las señales de velocidad que premia el ranking de un canal, los seguidores — y, en canales basados en ofertas como Allegro y eBay, el historial de ventas asociado a ese listado. Las valoraciones de producto son más matizadas: en Amazon viven en el ASIN y por lo general sobreviven a un cambio de oferta; las valoraciones de eBay son a nivel de vendedor, no de listado. Así que "un mal envío borra tus valoraciones" no es universalmente cierto — pero el impulso que hacía competitiva a la oferta sí puede reiniciarse por completo, y una oferta republicada lo reconstruye desde cero. El modo de fallo que hace esto peligroso es la propagación: una integración barata refleja el catálogo en el canal sin ninguna barrera, de modo que una sola fila local errónea llega a un listado activo a velocidad de máquina. Una de confianza valida la escritura de precio y stock, y bloquea los envíos masivos de "finalizar oferta" / puesta a cero para revisión, antes de que nada se propague.

3. Listados por debajo del precio real: exposición legal y financiera

Un producto listado muy por debajo de su precio real suele archivarse como "margen perdido". Eso se queda corto. Una vez que aceptas un pedido a un precio mostrado, algunas jurisdicciones esperan que lo cumplas (un precio mostrado por sí solo a menudo no es una oferta vinculante en los sistemas de common law; los errores evidentes pueden ser cancelables — depende de la legislación local y de tus condiciones), y en cualquier caso cancelar en masa cuesta más en contracargos y disputas que el margen que intentabas proteger. Los artículos mal tarificados también se detectan rápido: hay scripts de reventa que vigilan exactamente esto, así que un artículo con un precio muy por debajo del mercado se agota en minutos. En el plano del cumplimiento, incumplir un acuerdo con el proveedor es la exposición realista; la responsabilidad puramente en derecho de la competencia es estrecha (el artículo 102 de la UE exige posición dominante y abuso; el derecho estadounidense por lo general trata la fijación de precios por debajo del coste como legal salvo que sea depredadora). Y Google Merchant exige que el precio de tu feed coincida con el de tu página de destino, así que un desajuste se traslada a rechazos en el canal de pago.

El desencadenante es casi siempre un error de emparejamiento aguas arriba, y no se lanza ninguna excepción — el listado simplemente se publica a una fracción de su valor. La defensa es un precio mínimo que rechaza una escritura inverosímil antes de que llegue al escaparate o a un canal. El matiz que merece la pena incorporar: compara lo comparable — un precio base que supera el mínimo aún puede quedar por debajo del coste una vez que se aplica un descuento ps_specific_price activo o una regla de catálogo, así que el mínimo tiene que considerar el precio efectivo, no solo ps_product_shop.price.

La causa raíz: emparejar por IDs de proveedor volátiles

Este es el pecado original de la integración de feeds. Los IDs internos de proveedor no son estables — los distribuidores los reciclan y reasignan a medida que sus propios sistemas evolucionan. Empareja por ese ID y atarás tu catálogo a un objetivo en movimiento: el día que un proveedor reutilice un ID para un artículo distinto, tu producto caro adoptará el precio y el stock del barato. En su lugar, ánclate a un identificador estable del producto de destino. En PrestaShop eso es un GTIN único (ean13 / upc), el número de pieza del fabricante mpn, o tu propia reference, a nivel de combinación (ps_product_attribute). PrestaShop 8.1+ valida ean13 como GTIN a nivel de producto. La referencia propia del proveedor pertenece a ps_product_supplier.product_supplier_reference, delimitada por id_supplier, y debe usarse solo como recurso alternativo determinista — nunca como la clave principal que sobrescribe precio y stock.

Cómo saber si ya te está pasando

Si hoy usas un módulo de importación barato, no tienes que esperar a una reclamación. El daño deja huellas. Estos son chequeos rápidos de primera pasada — de solo lectura, seguros sobre una copia — no una auditoría completa, pero sacan a la luz los dos fallos que más cuestan.

Identidad duplicada — la condición previa para el emparejamiento de producto equivocado. Cualquier GTIN compartido por dos productos base es un defecto de datos y el terreno abonado para un intercambio de producto equivocado:

SELECT ean13, COUNT(*) AS n
FROM ps_product
WHERE ean13 <> ''
GROUP BY ean13
HAVING n > 1;
-- repetir para upc, mpn y los identificadores de ps_product_attribute (combinaciones)

Listados por debajo del coste — cualquier cosa tarificada por debajo de su propio coste mayorista es una fuga de margen en tiempo real o un error de emparejamiento que ya se ha disparado. Fíjate en id_shop: en multitienda el mismo producto puede estar bien en una tienda y por debajo del coste en otra. Esto comprueba solo el precio base — no descuenta los descuentos specific_price activos, ni impuestos, ni tasas, ni combinaciones, así que trata un resultado limpio como "sin fuga evidente en el precio base", no como "todo en orden":

SELECT p.id_product, p.reference, ps.id_shop, ps.price, ps.wholesale_price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE ps.wholesale_price > 0
  AND ps.price < ps.wholesale_price;

Las filas por debajo del coste son un fallo activo; los identificadores duplicados son un defecto de datos y un intercambio de producto equivocado a la espera de ocurrir. En cualquier caso está en tu catálogo ahora, no en teoría.

Trampas propias de PrestaShop que conviene conocer

• La casilla "Eliminar todos los productos antes de la importación" del importador CSV — junto con "Forzar todos los números de ID", es la acción que arrasa catálogos más famosa de PrestaShop. Una sola ejecución desatendida puede borrar y reindexar el catálogo entero.
• Escribir ps_product.quantity en lugar de usar StockAvailable. El stock real vive en ps_stock_available; saltarse la API omite el hook actionUpdateQuantity, de modo que las cachés y cualquier listener que dependa de él nunca se enteran de que el número cambió.
• Delimitación por multitienda. Los precios se delimitan por id_shop; el stock por id_shop o por un id_shop_group compartido. Una importación que ignora la delimitación actualiza el escaparate equivocado, o todos a la vez.

Deriva del catálogo y feeds truncados

La deriva del catálogo es la lenta divergencia entre lo que tu proveedor ofrece hoy y lo que tu escaparate sigue mostrando — SKU añadidos, descatalogados y con precio modificado que tu feed no reflejó. El caso más desagradable es un producto descatalogado que aún muestra stock fantasma: el cliente compra algo que no puedes conseguir. Manejarlo es delicado. Detecta el "desaparecido del feed", pero no mates el producto a ciegas — el agotamiento de stock real, propio (disponible en mano tras reservas, no el número del proveedor) es dinero que ya has pagado. En un catálogo con varios proveedores, "falta en un feed" debería descartar esa fuente, no el producto, y solo pasas a "ya no disponible" cuando el stock real en mano llega a cero y ningún otro proveedor lo cubre.

El fallo que convierte un problema pequeño en una catástrofe es el feed truncado — una descarga que muere a medias y que un módulo ingenuo trata como completa. De repente una gran parte de los SKU parecen "faltar" y se ponen a cero o se descatalogan en masa. La solución es una auditoría de la ejecución de importación: nunca actúes sobre un feed que no hayas validado contra la ejecución anterior.

CREATE TABLE ps_feedrun (
  id_run         INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  supplier       VARCHAR(64),
  started_at     DATETIME,
  row_count      INT UNSIGNED,
  prev_row_count INT UNSIGNED,
  checksum       CHAR(64),
  state          ENUM('running','applied','rejected'),
  reject_reason  VARCHAR(255)
);
-- Rechazar la ejecución (nunca aplicar eliminaciones) cuando la descarga es incompleta,
-- el checksum falla, la marca de tiempo de exportación es obsoleta, o row_count se desploma
-- frente a prev_row_count.

Cómo una sola ejecución errónea se propaga en cascada

Es ilustrativo, pero cada paso es un mecanismo real: una importación programada se ejecuta de madrugada como lo ha hecho durante meses. Esta vez la exportación se trunca a medias, y el módulo la ingiere como palabra sagrada. Los productos posteriores al punto de corte parecen "desaparecidos", así que su stock se pone a cero. Un puñado de IDs que el proveedor recicló esa semana vinculan artículos caros a líneas baratas, y esos precios se sobrescriben. Para cuando alguien inicia sesión, el escaparate muestra sin stock en productos activos, unos cuantos artículos están muy por debajo del coste vendiéndose ya a bots y — porque el catálogo lo propagó todo hacia adelante sin ninguna barrera — las ofertas del marketplace se han reiniciado por datos inválidos. Ni una sola línea lanzó un error. Cada barrera que lo habría atrapado — la auditoría de la ejecución de importación, el precio mínimo, la comprobación de procedencia, la barrera del canal — sencillamente no estaba.

Qué debe hacer una integración de feed de confianza

• Emparejar por identidad estable — un GTIN (ean13/upc), mpn, o tu propia reference, a nivel de combinación; la referencia del proveedor solo como recurso alternativo delimitado.
• Proteger los precios antes de publicarlos — un mínimo sobre el precio efectivo (después de specific_price y las reglas de catálogo), que rechaza y alerta en lugar de publicar.
• Escribir el stock de forma atribuible — a través de StockAvailable, solo desde una línea de origen correctamente emparejada, con una banda de coherencia ante saltos grandes.
• Auditar cada ejecución de importación — checksum, recuento de filas frente al anterior, frescura de la exportación; un feed sospechoso nunca impulsa eliminaciones.
• Poner una barrera a la propagación al canal y mantener la reversibilidad — validar antes de que nada llegue a un marketplace, y hacer una instantánea antes de cambiar para que la recuperación sea una restauración, no una reconstrucción.

Preguntas frecuentes

¿Por qué mi tienda vende artículos sin stock?

Normalmente por stock fantasma u obsoleto, a menudo amplificado por "permitir pedidos cuando no hay stock", o por un pedido que cae en la ventana entre sincronizaciones. La solución es una integración que escriba el stock de forma atribuible a través de StockAvailable, distinga un cero confirmado de una actualización que falta, y proteja contra saltos inverosímiles.

¿Cómo dejo de vender por debajo del coste?

Pon un mínimo delante de cada escritura de precio, comparado sobre el precio efectivo tras cualquier specific_price o regla de catálogo activa — no solo ps_product_shop.price. Rechaza y alerta en lugar de publicar, y mantén los datos de coste al día, porque un coste obsoleto oculta una venta por debajo del coste hasta que llega el informe de márgenes. La consulta de precio por debajo del coste de más arriba encuentra las que ya están publicadas.

¿Qué es la deriva del catálogo?

La brecha creciente entre lo que tu proveedor ofrece ahora y lo que tu escaparate sigue mostrando. Mide la tuya comparando el feed actual del proveedor con tu catálogo en vivo — cada SKU que esté en uno y no en el otro es deriva: un precio equivocado, stock fantasma, o un artículo que ya no puedes conseguir.

La conclusión

Una integración de feed justifica su valor en su peor día, no en el promedio. Cuando la exportación se trunca, un ID se recicla, o un distribuidor cambia los precios de la noche a la mañana, una integración bien construida rechaza los datos erróneos y una barata los aplica. Ninguno de estos fallos es exótico — son el resultado predecible de saltarse un puñado de barreras que no son difíciles de construir. Ejecuta las dos consultas de arriba contra tu propio catálogo; si devuelven filas, ya tienes la respuesta.