Que el ERP no pise tus descripciones: altas y actualizaciones

Un compañero de la comunidad quería posicionar una tienda que se actualiza sola desde el ERP con un cron. Su duda era la de muchos: si mejoro a mano descripciones, títulos y categorías, ¿el ERP me lo pisa en la siguiente sincronización? Depende de cómo esté hecho el conector. Rekire lo explicó con lo que hace en sus integraciones.

Alta y actualización no son lo mismo

La clave es tratar distinto el producto nuevo y el que ya existe:

• En el alta, el conector coge del ERP toda la información posible: nombre, descripciones, referencias, EAN, categorías, imágenes, precio y stock. El producto nace lo más completo que se pueda.
• En la actualización, solo se tocan los campos que tú decidas. Lo habitual es stock y precio. El nombre, las descripciones o las categorías que has trabajado en la tienda no se vuelven a escribir.

Rekire avisó de que hay muy pocos conectores que sincronicen más allá de stock y precio, así que el problema solo aparece con los que lo sincronizan todo, en cada pasada. Si el tuyo es de esos, hay que saber si permite elegir qué campos se actualizan.

La tabla intermedia

Un compañero especialista en bases de datos propuso la forma más flexible: una tabla intermedia entre el ERP y PrestaShop que solo sincronice lo que quieras, con opciones por producto del tipo «modificar descripción: sí o no», «modificar categorías: sí o no». Un ejemplo de cómo podría ser:

CREATE TABLE sync_producto (
  referencia        VARCHAR(64) NOT NULL PRIMARY KEY,
  id_product        INT UNSIGNED NULL,
  hash_erp          CHAR(32) NOT NULL,
  pisar_descripcion TINYINT(1) NOT NULL DEFAULT 0,
  pisar_categorias  TINYINT(1) NOT NULL DEFAULT 0,
  pisar_precio      TINYINT(1) NOT NULL DEFAULT 1,
  actualizado       DATETIME NULL
);

Cómo se usa:

1. El ERP deja sus datos y el conector calcula un resumen (hash_erp) de cada producto. Si el resumen no ha cambiado desde la última vez, no se hace nada. Así solo viajan los cambios.
2. Si no hay id_product, es un alta: se crea el producto con todo.
3. Si existe, se actualiza solo lo que tiene la marca a 1. Por defecto, precio y stock sí; descripción y categorías, no.
4. Cuando un producto lo gestiona el ERP de verdad (por ejemplo, uno que no has tocado), pones sus marcas a 1 y se sincroniza entero.

El mismo especialista lo comentó en otro hilo sobre copias de seguridad: con comprobaciones de este tipo no procesas todo, solo lo que ha cambiado.

Un caso real: la tienda de nicho

Rekire contó un montaje parecido para un cliente que abrió una segunda tienda con un nicho concreto de su catálogo:

1. Desde la tienda principal se exportan los productos de las categorías que ofrece la de nicho.
2. Si el producto es nuevo en la de nicho, se da de alta con toda su información.
3. Si ya existe, solo se actualizan stock y precio.

Así la tienda de nicho puede tener sus propias descripciones, escritas para su público, sin que la principal se las borre cada noche.

Por qué importa el rendimiento

Además del SEO, actualizar solo los cambios es lo que hace viable un catálogo grande. Rekire mantiene un sistema que carga y actualiza a diario un millón de productos detectando altas, bajas y modificaciones y enviando solo eso. Si cada noche se reescriben todos los productos con todos sus campos, la tienda se ralentiza mientras dura la sincronización y saltan todos los hooks de actualización sin necesidad.

Qué pedirle a tu conector

• Que distinga alta de actualización.
• Que puedas elegir qué campos se actualizan, y mejor si es por producto o por categoría.
• Que detecte cambios y no lo reescriba todo.
• Que deje un registro de qué ha cambiado en cada pasada, para saber quién tocó qué.

Si necesitas conectar PrestaShop con la facturación, CoreGest ERP con VERI*FACTU se conecta con una o varias tiendas PrestaShop desde una sola cuenta.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación