Procedimiento de puesta en producción

Documento genérico. Se aplica a cualquier instalación en la que Shopify se alimente mediante la migración de una tienda existente (PrestaShop, WooCommerce, Magento…) mientras Dolibarr ya contiene el historial comercial correspondiente.

1. El riesgo que este procedimiento evita

Cuando sus pedidos históricos se trasladan a Shopify, reciben allí identificadores de Shopify nuevos, y sus fechas de creación y de modificación son las del día de la migración: Shopify permite retrodatar la fecha de procesamiento, nunca esas dos.

Doli2Shop reconoce un pedido ya importado por su identificador de Shopify. Un pedido presente en Dolibarr con otro origen no lleva ningún identificador de Shopify: el módulo no puede saber que se trata de la misma venta. Sin precauciones, se importa por segunda vez, con la fecha de hoy, en su contabilidad.

Tres vías pueden importar un pedido, y son independientes entre sí:

2. Antes de la migración — los ajustes

• Sentido de la sincronización de stock. DOLI2SHOP_SYNC_STOCKS_DIRECTION debe valer dolibarr_to_shopify si Dolibarr es su referencia de stock. El valor por defecto es both: en ese caso, un webhook de inventario de Shopify también escribe movimientos de stock en Dolibarr.
• Pedidos no pagados. Por defecto solo se importan los pedidos con estado financiero pagado. Si deben entrar los pedidos pendientes de pago (pago aplazado B2B, transferencia), active DOLI2SHOP_SYNC_NON_PAID_ORDERS.
• Referencias de producto. Los SKU de las variantes de Shopify deben coincidir exactamente con las referencias de Dolibarr: esa correspondencia es la que evita crear productos y variantes duplicados.
• Correos electrónicos de los terceros. Un cliente existente se vincula por el correo que consta en la ficha de empresa, no en sus contactos, y dentro de la misma entidad. Un correo que solo exista en un contacto, o que difiera del de Shopify, generará una empresa duplicada. Concílielos antes del cambio: es una tarea de datos, no de configuración.

3. Durante la migración — lo que debe permanecer apagado

Mientras la migración no esté terminada y verificada, las tres vías de importación deben estar inactivas:

1. los webhooks de pedidos — pantalla Webhooks de la configuración del módulo;
2. la tarea programada Doli2ShopOrdersCatchup;
3. la tarea programada Doli2ShopOrdersHistoricalImport.

Comprobación con una sola consulta (solo lectura):

SELECT label, entity, status FROM llx_cronjob WHERE label LIKE 'Doli2Shop%';

Ambas tareas deben mostrar status = 0. En una instalación Multicompany, aproveche para comprobar que la columna entity corresponde a la entidad donde está configurado el módulo: una tarea creada en la entidad equivocada se ejecuta en vacío, sin emitir ningún error.

La sincronización de productos y de stock sí puede seguir funcionando en esta fase.

4. El cambio a producción

1. Termine la migración y verifíquela en Shopify.
2. Anote la marca de tiempo exacta del final de la migración: llamémosla T0.
3. Reduzca DOLI2SHOP_CATCHUP_LOOKBACK_HOURS a un valor que no se remonte antes de T0: 1 o 2 horas. El valor por defecto es 168 (7 días), y haría entrar directamente sus pedidos migrados.
4. Active primero los webhooks de pedidos y, después, la tarea de recuperación.

5. Después del cambio — las comprobaciones

• Abra la pantalla de eventos de webhook: enumera lo que entra, con su estado.
• Compruebe que no se ha creado en Dolibarr ningún pedido anterior a T0.
• No devuelva DOLI2SHOP_CATCHUP_LOOKBACK_HOURS a su valor habitual (168) hasta que T0 tenga más de siete días. Antes de eso, la ventana alcanzaría sus pedidos migrados.

6. Lo que este procedimiento no cubre

La ventana de recuperación limita la tarea programada, no los webhooks.

Tras el cambio, cualquier modificación en Shopify de un pedido migrado —una edición, un reembolso, una corrección de dirección, añadir una etiqueta— dispara un webhook orders/updated. El módulo no conoce ese pedido: lo crea. Obtiene así un pedido histórico reimportado con la fecha de hoy.

Este hueco no se cierra con el procedimiento. Lo cerraría un ajuste de «fecha de puesta en producción»: todo pedido de Shopify creado antes de la fecha elegida quedaría excluido de la importación, sea cual sea la vía —webhook de creación, webhook de modificación, tarea de recuperación—, conservando la importación histórica deliberada sus propios límites.

⚠️ Este ajuste todavía no existe en el módulo. Es un desarrollo, disponible mediante presupuesto. Sin él, el único recurso es vigilar los pedidos migrados: no modificarlos en Shopify después del cambio y comprobar con regularidad que no ha aparecido en Dolibarr ningún pedido anterior a T0.

7. Si aun así se crea un duplicado

1. Localícelo en la pantalla de eventos de webhook: el evento lleva el identificador del pedido de Shopify afectado.
2. Mientras el pedido creado en Dolibarr no esté validado ni facturado, eliminarlo no tiene consecuencia contable.
3. Si ya está facturado, la corrección sigue su práctica habitual en Dolibarr (abono o anulación, según su política contable): el módulo no requiere nada especial.
4. Corte la causa antes de limpiar; de lo contrario, el siguiente webhook volverá a crear el mismo pedido.