Odoo PrestaShop connector jobs and errors

La cola

• bk.prestashop.job: acción (importar pedido, enviar producto, comprobar el catálogo, enviar las reglas de precios, subir documento, stock, seguimiento, cambiar estado, decir el pedido de venta, poner al día el portal de clientes, buscar posibles vínculos, importar desde la tienda), registro, backend, estado, intentos, próxima ejecución, y resultado o error.
• Importar desde la tienda (import.run, uno por lote de una importación inicial): lo encola «Importar» y cada lote encola el siguiente al acabar, primero los productos (de 40 en 40) y después los clientes (de 100 en 100). Cada elemento va en su punto de guardado: lo que Odoo rechaza de uno se queda en su fila de la importación y los demás siguen, así que el job termina «Hecho» aunque alguna fila tenga problema. Si la tienda no responde, el job se reintenta con lo que falta y lo ya importado se queda (importación inicial).
• Enviar el stock (stock.sync, uno por conexión, con Inventario y Odoo en el stock): lo encolan los cambios de stock de los productos enlazados (con «En cada cambio»), «Enviar el stock ahora», la tarea de cada hora y los cambios de la configuración del stock; lo que se encola mientras espera se suma a lo suyo, sin esperar más. Su resultado dice cuántos cambiaron en la tienda, cuántos ya tenía y cuántos no están en alguna tienda (stock).
• Enviar el número de seguimiento (order.ship, uno por pedido, con Inventario): lo encolan validar un albarán de salida de un pedido de la tienda y cambiar la referencia de seguimiento de uno ya validado. Manda a la tienda el número de los albaranes validados y, con el pedido entregado entero, el estado de los enviados (order.set_tracking); lo que la tienda ya tiene no lo vuelve a mandar. Su resultado dice el número y el estado que quedaron en la tienda y si mandó el correo «en tránsito» (envíos).
• Enviar las reglas de precios (price_rules.sync, uno por conexión): lo encolan una regla de precio de una categoría o de todos los productos de una lista que viaja, la lista propia de un contacto vinculado que cambia, y vincular o desvincular su cliente; lo que se encola mientras espera se suma a lo suyo. Sustituye las reglas de precios del catálogo del conector en la tienda, si cambiaron, y vuelve a mirar los productos que eso puede mover: envía solo los que cambian, cada uno con su job de producto. Su resultado dice cuántas reglas tiene la tienda y cuántos productos se han vuelto a mirar (precios).
• Un solo job vivo (pendiente, bloqueado o fallido) por acción y registro: encolar lo mismo otra vez no duplica; uno pendiente se pone en cola ya, aunque esperase su siguiente intento, y uno bloqueado o fallido vuelve a la cola con intentos nuevos. El job trabaja con los datos del momento en que se ejecuta, también los de lo que se encola mientras una pasada de la cola ya lo tiene en su lote.
• Corre en una tarea programada del núcleo cada minuto, que se despierta al momento cuando se encola algo. Procesa por lotes y guarda cada job por separado: un fallo no deshace los demás. Varios procesos de Odoo a la vez no cogen el mismo job.
• El cursor de eventos solo avanza cuando los jobs de esos eventos están guardados: una lectura interrumpida vuelve a leer los mismos eventos, no se salta ninguno.
• Un job que se ejecuta no bloquea nada: se marca «En ejecución» antes de hablar con la tienda. Si mientras tanto se vuelve a encolar lo mismo (el producto se guarda otra vez, se publica a mano una factura del pedido), se crea el siguiente job, que espera a que termine el primero y sale con los datos de entonces: guardar nunca falla porque la cola esté trabajando. Dos jobs de la misma acción y registro nunca se ejecutan a la vez.
• Lo que un job encola de sí mismo mientras se ejecuta (el flujo de un pedido que publica su factura) no crea otro: ya lo está haciendo.
• Un job corre en el idioma de la empresa del backend: en él quedan su resultado y su error.
• Sin configuración de servidor ni módulos externos: por eso la cola es propia y no la de OCA (queue_job), que exige server_wide_modules y un proceso aparte en cada instalación del cliente.

Estados de un job

• Errores técnicos (la tienda da error 500): se reintenta con espera creciente (1, 5, 15 y 60 minutos, multiplicados por la espera configurada) hasta el máximo, y después queda Fallido.
• Un servicio de fuera que no responde (VIES de un país, que en algunos se apaga cada noche; la pasarela de pago de la tienda): el job espera y se reintenta cada 5 minutos (multiplicados por la espera configurada) sin gastar intentos, lo que tarde el servicio en volver; mientras, enseña el motivo.
• Sin conexión con la tienda (un CONN_*: no responde, algo bloquea la petición, la clave no vale, los relojes difieren o el módulo no habla el contrato): se pausa la cola de ese backend sin gastar intentos y se reanuda sola cuando la lectura de eventos de cada minuto vuelve a funcionar. El backend enseña «sin conexión desde…» con el motivo.
• La conexión la decide una petición que no depende del job. Un CONN_* puede ser solo de la petición de un job: un cuerpo demasiado grande (413, habitual con el PDF de una factura en alojamientos con límites bajos) o un cortafuegos que rechaza su contenido (403). Por eso, ante un CONN_* de un job, la cola pregunta a la tienda por system.capabilities: si no responde, se pausa el backend como arriba; si responde, el error es técnico y de ese job, que gasta intento, se reintenta y queda Fallido con su motivo (el 413 dice que la petición es demasiado grande). Un job así nunca para el resto de la cola.
• Errores de datos: Bloqueado a la primera. No se gastan reintentos que no pueden salir bien.
• Una ejecución que no terminó (el proceso de Odoo se paró a mitad) cuenta como un error técnico de ese job: la siguiente pasada de la cola lo devuelve a su reintento.

Cómo se ve un error

Cada error lleva:

• un código estable (ORDER_VAT_INVALID), para buscarlo en este catálogo y para las extensiones;
• un mensaje en el idioma de la empresa, con el dato concreto: qué pedido, qué cliente, qué campo, qué valor;
• dónde se arregla (PrestaShop, Odoo o la configuración del conector) con un enlace directo: el pedido o la dirección en el back office de la tienda, el mapeo en Odoo;
• el detalle técnico plegado (petición, respuesta, traza) para soporte.

Bloqueado · ORDER_VAT_INVALID El pedido FRNQUACIA (Acme SL) tiene el NIF «B1234» en la dirección de facturación y no es un NIF español válido. Esta tienda exige un NIF válido a las empresas. Se arregla en PrestaShop: corrige la dirección de facturación del cliente → Abrir el pedido en PrestaShop. Después, Reintentar.

• Reintentar pone el job en cola ya, con los intentos a cero, y vuelve a pedir el pedido a la tienda: coge lo que se haya corregido.
• Aceptar el NIF y facturar, en un pedido parado solo por reglas del NIF (ORDER_VAT_MISSING, ORDER_VAT_INVALID, ORDER_VAT_VIES): quien lleva la tienda da el NIF por bueno tal como viene (un CIF español que no está dado de alta en VIES, por ejemplo). El pedido entra y se factura con ese NIF, y guarda quién lo aceptó y cuándo. Un pedido parado además por otra cosa no cambia: primero se arregla lo otro. Funciona también en lote.
• Reintentar y cancelar funcionan también en lote, y los puede usar quien ve la cola (PrestaShop / Usuario): es lo único que ese grupo cambia en ella.
• Un job bloqueado o fallido se ve también en el pedido de la tienda afectado (también los de sus facturas) y avisa con una actividad en el job, por correo o por las dos, a los usuarios elegidos en la configuración.
• Un job que espera a un servicio de fuera (VIES, la pasarela de pago) avisa a esos usuarios con una actividad, «en camino», para que vean que hay pedidos procesándose; no se manda por correo, porque no hay nada que hacer, y desaparece cuando el job termina.

Catálogo de errores

Conexión

Un CONN_* de la conexión (no el ok: false de una operación) deja el backend sin conexión y pausa su cola hasta que vuelve; el de un job con la conexión viva es un error técnico de ese job (arriba). En el asistente de alta, un CONN_* de Conectar deja el paso en Conectar con su mensaje; el asistente no tiene códigos propios.

La licencia tampoco tiene códigos ni crea jobs, y ningún job falla ni espera por ella: lo que dice (sin clave, no válida y por qué, sin comprobar, tiendas sin conectar, la última comprobación fallida) sale en la licencia y arriba de cada conexión, y solo decide si se puede conectar otra tienda.

Pedidos

Catálogo

• Un producto sin referencia con «Enlazar si existe» no se encola: su plan dice «No se publica: no tiene referencia con la que enlazarlo».
• Los errores de datos de un producto (PRODUCT_TAX_UNMAPPED, PRODUCT_PS_REJECTED, PRODUCT_REF_DUPLICATE, PRODUCT_DYNAMIC_ATTRIBUTES, PRODUCT_UNIT_UNKNOWN, PRODUCT_ORIGIN_INVALID, PRODUCT_SUBSCRIPTION_UNSUPPORTED): arreglado en el producto, el job vuelve a la cola solo; arreglado fuera (un mapeo, la tienda), «Reintentar».

Portal de clientes

• Un documento del portal que no se puede subir por su PDF da DOCUMENT_PDF_MISSING o DOCUMENT_PDF_INVALID, como la subida de los documentos de un pedido.
• Con un módulo de la tienda que no anuncia las operaciones del portal (o order.link), los jobs terminan sin llamar a la tienda y lo dicen en su resultado: no es un error.
• «Vincular un cliente de la tienda» no es un job: lo que contesta la tienda al buscar (sin conexión, CONN_*) sale en rojo en el mismo diálogo, y con un módulo sin customers.search el diálogo pide actualizarlo y probar la conexión.

Importación inicial

No son errores de un job: cada uno se queda en la fila de su elemento en la importación (columnas Resultado y código), y los demás elementos siguen. Se arregla y se prepara una importación nueva: lo ya importado sale como «Ya enlazado».

Documentos, stock y envíos

• Stock: un producto sin enlazar no envía stock (no es un error: el catálogo decide qué se enlaza). Lo que la tienda rechaza de un producto en stock.set bloquea el job stock.sync cuando ha enviado todos los demás, con el código del primero y la lista de productos: PRODUCT_MISSING_IN_PS si el producto o la combinación enlazados ya no están en la tienda (se arregla en Odoo: volver a enlazarlo o quitar el enlace) y PRODUCT_PS_REJECTED si la tienda no puede escribir esa cantidad (un producto enlazado sin combinaciones que en la tienda las tiene, o que toma la cantidad de la gestión de stock avanzada de una 1.7). El siguiente cambio de stock lo vuelve a poner en cola, y «Reintentar» también.

Los códigos de una extensión llevan el prefijo de su módulo y se documentan en él: los de sus reglas (_bk_ps_validate_order) bloquean el pedido como los del estándar, y los de sus operaciones de la tienda llegan como cualquier error de una operación (estándar y a medida).