Einstellungen der Odoo PrestaShop Schnittstelle

Toda la configuración vive en Odoo, en el backend de cada instalación (Ventas › PrestaShop › Conexiones). El módulo de PrestaShop solo guarda su clave, la URL del aviso inmediato (que le pone Odoo), cuánto conserva los eventos, su registro de depuración y la última respuesta de su licencia: una sola fuente de configuración. Cada opción tiene un valor por defecto que no escribe nada en la tienda hasta que alguien lo decide.

Una conexión nueva se da de alta con el asistente, que recorre en orden lo imprescindible; el resto de los bloques empieza con sus valores por defecto y se cambia en el formulario de la conexión. Cuántas tiendas se pueden conectar lo decide la licencia: las tiendas que el cliente vincula en bkmodules.com.

Asistente de alta

«Nueva conexión», en la lista de Conexiones (solo el administrador del conector), abre el asistente en un diálogo: la conexión se crea en el primer paso y cada paso guarda lo suyo en ella. Arriba se ve en qué paso va; «Atrás» y «Siguiente» se mueven por ellos.

• «Seguir más tarde» guarda y cierra; el formulario de la conexión avisa de que el alta no está terminada, en qué paso quedó, y la sigue con «Seguir con el alta». La lista lo enseña en su columna Alta.
• Una conexión creada antes del asistente, o terminada, está dada de alta: el asistente no vuelve a salir.
• Conectar solo pregunta a la tienda y le da la URL del aviso inmediato: nada más cambia en ella.

1. Conexión

• URL de la tienda, clave y URL del back office, que usan los enlaces de los errores y los botones «Ver en PrestaShop» de productos, pedidos y clientes. La página del módulo de PrestaShop enseña los tres valores para copiarlos: son lo único que se copia entre las dos piezas. La clave la crea el módulo al instalarse; «Crear una clave nueva» la sustituye (pide confirmación). Cambiar la clave de la conexión en Odoo hace que vuelva a leer los eventos desde el principio: un módulo reinstalado numera su bandeja desde 1, y leer dos veces el mismo evento no duplica nada.
• Probar conexión llama a system.capabilities, guarda lo que dice la tienda (versiones, zona horaria, tiendas, idiomas, monedas, estados, impuestos, módulos compatibles instalados) y enseña las versiones de PrestaShop, del módulo y del contrato. Rellena las listas de los mapeos y lo vacío que se puede deducir; nunca cambia lo elegido.
• HTTPS: la URL de una tienda de producción va con https://. Con http://, Probar conexión, el paso Conectar del asistente y la cola no envían nada a la tienda y la conexión queda sin conexión con el motivo (CONN_INSECURE): los pedidos y los clientes viajarían sin cifrar. Solo una dirección de pruebas, por las mismas reglas que la licencia (test., staging., dev.…, .local, .test, localhost o IP privada), puede ir por http://. Las redirecciones no se siguen, así que una tienda https:// no puede devolver a Odoo a http://.
• Peticiones de un solo uso: cada petición firmada lleva su nonce y la tienda la acepta una sola vez (contrato): quien capture una no puede repetirla. Un módulo de la tienda anterior funciona igual, pero aún acepta una petición repetida dentro de sus 5 minutos: Probar conexión lo dice como aviso (conectada, pero…) y el paso Comprobar del asistente lo lista con lo que el módulo aún no hace, hasta que se actualiza.
• Aviso inmediato: la tienda avisa a Odoo en cuanto hay un evento, sin esperar al minuto. No se configura: Probar conexión, después de las capacidades, le da a la tienda la URL de aviso de la conexión (events.subscribe) y guarda lo que contesta. La conexión enseña «Aviso inmediato» Activo (la tienda la tiene), Inactivo con el motivo (la tienda no la aceptó, falló al guardarla o su módulo no tiene la operación) o Pendiente (aún no se ha probado la conexión, o cambió la URL de la tienda o la clave). Un aviso que no se puede poner no hace fallar la prueba: la conexión queda bien, con un aviso en la notificación, y los pedidos llegan con la lectura de cada minuto. La página del módulo enseña el estado, de solo lectura: activo, con el servidor de Odoo al que avisa, o inactivo. El aviso solo llega si la tienda alcanza a Odoo; si no, la lectura de cada minuto los recoge igual.
• Versión del módulo de PrestaShop: la conexión enseña la instalada en la tienda (module_version de system.capabilities). El módulo se descarga del área de licencias de bkmodules.com; llevar su zip dentro del addon solo hace falta si se vende en Odoo Apps (venta).
• Situación: conectado, o sin conexión desde tal hora con el motivo (la cola de ese backend se pausa sola: jobs y errores).

2. Tiendas

Una fila por tienda de la instalación:

• Conectada: el conector trabaja con ella (sus pedidos, su catálogo y su stock) y ocupa una tienda de la licencia. Una tienda que llega con Probar conexión se conecta si su dirección está vinculada a la licencia y cabe en sus plazas; si no, queda sin conectar, en la lista «Sin conectar» debajo de las tiendas, con el motivo en su fila y en la conexión. Conectarla ahí pide lo mismo («… no está vinculada a tu licencia», «Tu licencia permite N tiendas de producción y están todas conectadas…»); desconectar una de arriba libera su plaza. Una tienda sin conectar no trae pedidos, no recibe productos ni stock, y sus pedidos no se leen aunque la tienda avise.
• Importar pedidos: sí o no.
• Equipo de ventas y lista de precios por moneda. La moneda de un pedido de venta es la de su lista de precios: un pedido en otra moneda que la de la empresa necesita una lista de su tienda en esa moneda (ORDER_PRICELIST_MISSING).
• Con Inventario, Almacén de los pedidos: el que entrega los pedidos de esa tienda (el almacén de su pedido de venta al crearlo). Vacío, el que Odoo pone a un pedido de venta nuevo. Y, cuando Odoo manda en el stock (bloque 10), Almacenes del stock y Recibe el stock.
• Serie de facturas: el diario de ventas de sus facturas y rectificativas. Al lado, los números que tomarán la siguiente factura y la siguiente rectificativa («Siguiente factura: BK/2026/033 · Siguiente rectificativa: RINV/2026/00003»), que salen de lo último publicado en ese diario. Vacía, el diario de ventas por defecto de la empresa, el mismo que el de las facturas hechas a mano, y la fila lo dice (serie de facturas).
• Publicar productos en esta tienda: sí o no. Una tienda que deja de publicar conserva los productos que tiene con lo último que recibieron de Odoo, precios incluidos, y Odoo ya no los cambia: el formulario lo avisa al apagarla (catálogo).
• Sus listas de precios son también las de su catálogo: la de su moneda por defecto da su precio base, y cada una va a la tienda en su moneda (precios). Una lista en una moneda que una tienda no tiene (también la de un grupo o la de un contacto vinculado) no va a esa tienda, y el bloque lo avisa con qué hacer: añadir la moneda en PrestaShop o quitar la lista. Probar conexión lee las monedas de cada tienda.

3. Mapeos

Categorías

En la pestaña «Categorías» de los mapeos, una fila por categoría de Odoo con la categoría de la tienda que le toca, elegida por su nombre con su camino («Inicio > Ropa > Hombre»; también se busca por su id). Las categorías de la tienda llegan con Probar conexión y con «Actualizar las categorías de la tienda» (catalog.categories); una que la tienda ya no tiene queda en su fila marcada como que falta, y no cuenta. Un módulo de la tienda sin la operación no da sus categorías: la pestaña lo dice y la categoría por defecto se escribe por su id.

• Los productos de una categoría de Odoo, y los de sus subcategorías sin fila propia, van a su categoría de la tienda.

• Al crear un producto en la tienda: con «Categorías» en PrestaShop (bloque 5), la categoría por defecto de la conexión (bloque 4); con Odoo u Odoo al crear, las del mapeo (bloque 5).

• Idioma de reserva: el de los clientes cuyo idioma de la tienda no tiene idioma activo en Odoo. Por defecto, el inglés si está activo; si no, el de la empresa. La tienda suele tener más idiomas que Odoo (en pre: inglés, español, francés, italiano y alemán; en el Odoo de BK, inglés y español): un cliente francés tiene su contacto, y el PDF de sus facturas, en el idioma de reserva, y la tienda le sigue escribiendo en francés. La pestaña de idiomas enseña, en cada uno, el idioma que reciben sus clientes. Nunca se pone a un contacto un idioma inactivo. Cada idioma de la tienda solo se mapea a un idioma de Odoo de la misma lengua (es → es_ES o es_MX): uno que Odoo no tiene se queda vacío, sus clientes reciben el idioma de reserva y sus textos del catálogo son de la tienda.

4. Productos nuevos

Qué pasa cuando en Odoo hay un producto que la tienda no tiene enlazado. Se decide una vez por backend.

• Tiendas que publican: el catálogo solo va a las tiendas marcadas «Publicar productos» (bloque 2). Por defecto ninguna: hasta marcar una, la conexión no envía ni enlaza ningún producto.
• Qué productos cuentan: todos los vendibles (por defecto), solo los marcados «Publicar en PrestaShop», o solo los de ciertas categorías (con sus subcategorías). En cada producto, «Excluir de PrestaShop»: el conector ni lo envía ni lo enlaza. Un producto combo no cuenta (packs, fase 4). La casilla «Publicar en PrestaShop» del producto solo sale si alguna conexión publica solo los productos marcados.
• Acción. Por defecto, No hacer nada.

Con «Activo» en Odoo (bloque 5), el producto se crea activo o desactivado según esté en Odoo. - Tiendas de cada producto (con varias tiendas en la instalación): Todas las que publican (por defecto), Por la categoría del producto (cada tienda de la fila del bloque 2 lista sus categorías de Odoo, con sus subcategorías; sin ninguna, recibe todos los productos) o Elegidas en cada producto (en su pestaña PrestaShop; un producto sin tiendas elegidas no se publica). Un producto que deja de tocarle a una tienda que sigue publicando espera a «Aplicar en PrestaShop»: hasta entonces la tienda lo tiene como estaba, y al aplicarlo sale de ella (nunca de todas: un producto sin tiendas no se publica y se queda donde está). Una tienda que deja de publicar productos no saca los suyos. - Cuándo: un producto se mira al crearlo en Odoo, cuando empieza a contar y cuando cambia su referencia o su código de barras, al guardarse la operación: uno que la misma operación enlaza (un pedido con «Crear el producto en Odoo») ya está en la tienda. Cambiar la acción no mueve los productos que ya existen: se enlazan con «Enlazar catálogo existente» o se mandan con «Enviar a PrestaShop». Su plan dice en cada momento qué les pasará (catálogo). - Producto enlazado que deja de contar: qué pasa en la tienda con un producto enlazado que se archiva (sin «Activo» en Odoo, bloque 5), deja de venderse, se excluye, sale de las categorías que cuentan o pierde «Publicar en PrestaShop». Odoo deja de enviarle cambios en los tres casos, y su plan dice cómo queda en la tienda (catálogo).

Cuando vuelve a contar, se deshace solo lo que hizo la conexión. Con todos los datos en PrestaShop no se hace nada. Dejar de publicar en todas las tiendas no es dejar de contar: no toca ningún producto. - Valores de alta (solo al crear): categoría por defecto (elegida por su nombre entre las de la tienda, o su id si el módulo de la tienda no da sus categorías; vacía, la raíz de la tienda), que es la de los productos cuya categoría de Odoo no tiene ninguna en el mapeo de categorías, visibilidad (por defecto, en todas partes) y las tiendas del producto. Si se envía o no lo deduce del tipo de producto de Odoo: un servicio es virtual; un bien, físico. - La conexión enseña arriba cuántos productos, combinaciones y clientes tiene enlazados y cuántos productos que cuentan siguen sin enlazar (enlaces). - Enlazar catálogo existente (acción del backend): busca todas las referencias en la tienda y enlaza las que casan una a una. Informa de los enlazados, los que no tienen pareja, las referencias repetidas (en Odoo o en la tienda) y los productos sin referencia. No escribe nada en la tienda. - Enlace por referencia: un producto sin variantes con el producto de PrestaShop de la misma referencia; una variante con la combinación de la misma referencia; opcionalmente, por código de barras si no hay referencia. No se enlaza (PRODUCT_REF_DUPLICATE) una referencia repetida en Odoo o en la tienda, que en la tienda es de otro tipo (combinación frente a producto sin combinaciones) o que ya está enlazada con otro producto.

5. Quién manda en cada dato

Una fila por tipo de dato, con una de tres políticas:

Ejemplo: con los precios en Odoo al crear, un producto nuevo sale a la tienda con el precio de Odoo y a partir de ahí la estrategia comercial se lleva en PrestaShop; con Odoo, los precios se centralizan en Odoo. Qué es «vacío» para cada dato, en catálogo.

De dónde sale cada dato

Las filas de los datos que Odoo Community no tiene como campo propio, y las dos descripciones, eligen además de dónde toma Odoo el valor mientras Odoo manda en ellas (si no, no se elige nada):

• Un campo de Odoo: uno del producto o de su variante del tipo del dato (texto, número o sí/no), también de otro módulo instalado (la descripción de comercio electrónico de website_sale). Un campo traducible viaja en cada idioma; una selección, por su nombre visible, y una relación, por su nombre. El campo «Notas internas» (la descripción del producto en Odoo) solo se publica si alguien lo elige.
• Una propiedad del producto: por el nombre con que se ve, en cualquier categoría (las propiedades de Odoo se definen por categoría). Un producto cuya categoría no tiene esa propiedad no envía el dato: la tienda conserva el suyo. Las propiedades no se traducen: el mismo texto en todos los idiomas.
• Un valor fijo, el mismo para todos los productos; los textos, traducibles por idioma.

Un dato en Odoo sin origen no se puede guardar: la conexión dice cuál falta. Lo que llega de un origen y no puede ser el dato (un número que no lo es, una condición que no es nuevo, usado ni reacondicionado, un sí/no que no lo es) para el producto con PRODUCT_ORIGIN_INVALID, con el valor y dónde se arregla. Cambiar en un producto el campo o la propiedad de los que sale un dato lo envía; un campo que no es el origen de nada no mueve nada.

• Precios con combinaciones: «Precio base y la diferencia en cada combinación» (por defecto, como Odoo) o «Precio base 0 y el precio entero en cada combinación». Sale bajo la tabla mientras Odoo manda en el precio base o en el impacto (precios). Con el precio entero en cada combinación, el precio base y el impacto son el mismo precio repartido: tienen que tener la misma política, y guardar otra cosa da un error que lo explica (si no, un producto quedaría a 0 o al doble en la tienda). Con la diferencia, cada parte tiene sentido por su cuenta (el precio base de Odoo con los recargos de la tienda, o al revés).
• Precios por cliente (mientras Odoo manda en los precios específicos): encendido por defecto. La lista propia de un contacto vinculado con un cliente de la tienda viaja como precios específicos de ese cliente; una lista que es la de una tienda o la de un grupo mapeado cuenta como esa. Un cliente de la tienda con varios contactos lleva una sola: la del primero que se vinculó de los que tienen lista propia. Apagado, no viajan, y los que el conector hubiera creado se quitan con el siguiente envío de cada producto. Cambiar la lista de un contacto, vincular o desvincular su cliente, vuelve a mirar sus productos en segundo plano.

• Reglas de precios del catálogo: cuántas tiene el conector en la tienda y si están al día, con «Enviar reglas de precios» (las envía y vuelve a mirar todos los productos enlazados, en segundo plano). Los descuentos de una categoría o de todos los productos de las listas de las tiendas y de los grupos son reglas del catálogo de la tienda; con un módulo de la tienda que no las tiene, viajan producto a producto. Una regla de categoría necesita las categorías de la tienda de esa categoría (el mapeo de categorías); sin ellas, va producto a producto.

• Grupos y valores de atributo: su nombre, su tipo (desplegable, botones o color), su color, su textura y su orden se escriben al crearlos, con lo que tiene Odoo; después son de la tienda (atributos).

• Siempre de la tienda: URL y metas por idioma (al crear, la URL sale del nombre).
• Con todos los datos en PrestaShop, nada del catálogo sale hacia la tienda: un producto nuevo solo se enlaza por su referencia, con «Enlazar por referencia» o solo según el bloque 4, y nunca se crea; «Enviar a PrestaShop» no sale, y uno enlazado dice «Enlazado con el producto id de conexión. Odoo no le envía nada: la tienda manda en todos sus datos». La conexión no enseña entonces los valores de alta ni «Comprobar consistencia».
• Modo de escritura del catálogo (en modo desarrollador): Nativo (por defecto) o Directo, con los hooks de guardado de producto o sin ninguno al terminar (modos).
• Cada dato que añade una extensión entra en esta tabla con su propia fila (extensiones).

6. Pedidos

Qué pedidos se importan

• De las tiendas que importan (bloque 2).
• En los estados elegidos: Cualquiera, Pagados según PrestaShop (los estados con «Considerar el pedido como pagado») o Solo estos (lista).
• Creados desde una fecha: los anteriores no entran solos, pero se pueden traer a mano (Importar pedidos anteriores).
• Un pedido en un estado que no se importa queda en la lista como Ignorado y entra en cuanto pasa a uno que sí.
• Pedidos que no se importan, por defecto ninguno: los pagados con ciertos métodos de pago, los de clientes de ciertos grupos (su grupo por defecto) y, con No importar los pedidos de 0, los de total 0. Se quedan como Ignorados, y el resultado de su job dice por qué; quitada la exclusión, entran con su siguiente cambio en la tienda o con «Reintentar».

Flujo por estado

Qué hace Odoo con un pedido según el estado en que está en la tienda. Una fila por estado mapeado, con los pasos que se ejecutan cuando el pedido llega a él, en este orden:

• Cada paso es idempotente: un pedido que ya lo tiene hecho lo salta. Un paso que falla deja el pedido en ese paso con su error, y Reintentar sigue desde ahí.
• La ficha del pedido de la tienda en Odoo enseña su flujo: qué pasos están hechos, cuál falló y por qué.
• Enviar desde la tienda, Subir y Registrar cobro esperan a que la factura esté publicada; publicarla a mano deja seguir el flujo.
• Odoo no manda ningún correo al cliente: los manda todos la tienda, en el idioma del cliente (correos al cliente).
• Plantillas para no empezar de cero: Pago por adelantado (por defecto: en los estados pagados, importar, confirmar, facturar, publicar y subir; en los cancelados y reembolsados, cancelar), Facturar al enviar (en los pagados, importar y confirmar; en los enviados, además facturar, publicar y subir; en los cancelados y reembolsados, cancelar) y Solo importar (en los pagados, importar). Pagado, enviado, cancelado y reembolsado son las banderas de cada estado en la tienda (el cancelado es su PS_OS_CANCELED y el reembolsado su PS_OS_REFUND), que la tabla enseña en «Marcado como». En el reembolsado, «Cancelar» acredita lo que no hayan devuelto ya los vales de abono, y la devolución de la pasarela paga la rectificativa (devoluciones). Una plantilla sustituye los pasos de todos los estados. La primera conexión aplica Pago por adelantado; un estado que aparece después llega sin pasos.
• Con Inventario, la columna Validar albarán, que ninguna plantilla marca, y Facturar al validar el albarán en Odoo (envíos).
• Facturar exige productos que facturan lo pedido, salvo con «Facturar al validar el albarán»; se comprueba antes de confirmar (ORDER_INVOICE_POLICY).
• Publicar espera a que el pedido tenga factura: con la factura hecha después (al validar el albarán, a mano), el siguiente paso del flujo la publica.

Resto

• Estado en PrestaShop tras importar: No cambiar (por defecto) o cambiar a un estado. Lo que la tienda sabe al validar un albarán, con Inventario, en envíos.
• Líneas de descuento: una por cupón, con su nombre y su código (por defecto), o una sola por pedido con todos los códigos. Llevan el producto de descuento de la conexión o, sin él, el de la empresa, que Odoo crea la primera vez. Un envío gratis rebaja los portes: no es una línea de descuento. Con productos de varios impuestos, cada descuento se reparte entre ellos según su base, como hace la tienda, y cada parte lleva su impuesto.
• Envoltorio de regalo: una línea con el producto de envoltorio de la conexión. Un pedido con envoltorio y sin ese producto elegido se bloquea (ORDER_CONFIG_MISSING).
• Adoptar facturas existentes: si ya hay una factura de cliente con Documento origen = referencia del pedido, pasa a ser la factura de su pedido de venta en vez de facturarse otra vez, y el pedido de venta queda facturado. Sirve para arrancar cuando antes se facturaba a mano: con «Importar pedidos anteriores», cada pedido ya facturado entra con su pedido de venta y su factura de siempre. Si el total no coincide, o una línea del pedido no tiene en la factura una con su producto o su importe y su cantidad: ORDER_ADOPT_MISMATCH. Adoptarla no manda nada: sube a la tienda sin correo.
• Devoluciones: un vale de abono de la tienda (parcial o total) da una rectificativa de lo devuelto, y lo que la pasarela devolvió de un cobro registrado con su comisión la paga (devoluciones). Sin opciones.
• Transportista sin método de envío: Bloquear el pedido (por defecto, ORDER_CARRIER_UNMAPPED) o Usar un método de envío por defecto, el elegido, con su producto de portes; sin él elegido, el pedido se bloquea igual y lo dice.
• Descripción de las líneas: Nombre del producto en la tienda (por defecto: como lo vio el cliente, en el idioma del pedido) o Nombre del producto en Odoo (su descripción de venta en el idioma del contacto, como en un presupuesto hecho en Odoo). Los portes, cupones y envoltorio llevan siempre su nombre de la tienda.
• Mensajes del cliente: Como nota interna en el pedido de venta (por defecto) o No traerlos. Los mensajes que el cliente escribió en el pedido (el del checkout y los de su historial) y el mensaje de regalo, cada uno una vez: notas internas que no mandan correo a nadie.
• Productos sin enlazar. Cada línea lleva el producto enlazado a su combinación, o a su producto si no tiene combinación. Si no hay ninguno, el producto vendible de Odoo con la misma referencia, que queda enlazado si es del mismo tipo (variante con combinación, producto sin variantes con producto sin combinación) y aún no lo estaba; si la referencia es de varios productos, el pedido se bloquea (ORDER_PRODUCT_AMBIGUOUS). Sin ninguno, según esta opción: bloquear el pedido (por defecto, ORDER_PRODUCT_UNLINKED), usar el producto genérico de la conexión (sin él elegido, se bloquea), o crear el producto en Odoo con el nombre, la referencia, el precio y los impuestos de la línea (un servicio si es virtual), en la empresa de la conexión, y enlazarlo.

Envíos (con Inventario)

Con el puente de Inventario. Un pedido de la tienda llega a Odoo como pedido de venta y, al confirmarse, Odoo hace sus albaranes desde el almacén de los pedidos de su tienda (bloque 2). Las etiquetas de los transportistas no son del conector: las trae, si acaso, el addon de cada transportista, y el número que deja en el albarán viaja igual.

• Al validar un albarán en Odoo, la tienda sabe, por defecto, el número de seguimiento y el estado de los enviados; también solo el número, o nada. Cuenta cada albarán de salida al cliente que se valida, a mano o con el paso Validar albarán, y cada cambio de la referencia de seguimiento de un albarán ya validado:
• el número es la «Referencia de seguimiento» de los albaranes validados del pedido, en el orden en que se validaron y separados por comas; la tienda lo pone en el transportista del pedido y manda al cliente su correo «en tránsito» con el enlace de seguimiento del transportista (desde PrestaShop 8.1, solo si el transportista lo tiene). Un número que PrestaShop no admite (más de 64 caracteres, letras con acento) para el job con TRACKING_NUMBER_INVALID; un pedido sin transportista en la tienda, con TRACKING_CARRIER_MISSING;
• el estado, el de Estado de los enviados (Probar conexión pone el primero que la tienda marca como enviado: «Enviado»), con el correo de ese estado, en cuanto Odoo tiene el pedido entregado entero (ningún albarán de salida abierto): un albarán parcial manda solo su número. Un pedido que en la tienda ya está en un estado de enviado o en el cancelado conserva el suyo. Sin estado elegido, el job se para con TRACKING_STATE_UNMAPPED;
• lo que la tienda ya tiene no se manda otra vez. El cambio de estado lo lee Odoo como cualquier otro, y corre los pasos de ese estado (con la plantilla Facturar al enviar, la factura).
• Validar albarán, el paso del flujo: cuando la tienda pone el pedido en un estado con el paso, Odoo valida los albaranes abiertos de su pedido de venta (en una entrega en varios pasos, cada uno cuando termina el anterior) con todas sus cantidades, aunque no haya stock, y sin pedidos pendientes. Un producto con lotes o números de serie, o un albarán que espera una recepción, para el paso (ORDER_STEP_FAILED) con lo que dice Odoo: se valida a mano y Reintentar sigue. La tienda ya lo envió, así que no hay nada que contarle salvo el número que tenga el albarán.
• Facturar al validar el albarán en Odoo: la factura sale cuando Odoo tiene el pedido entregado entero, sea cual sea su estado en la tienda, y es de lo entregado: sus productos pueden facturar las cantidades entregadas. Un pedido sin nada que entregar (solo servicios) está entregado en cuanto se confirma. Publicarla, registrar sus cobros, enviarla y subirla siguen los pasos del estado del pedido.
• Odoo no manda nada al cliente: el paso Validar albarán valida sin la confirmación de entrega por correo ni por SMS de Inventario, aunque esté encendida en sus Ajustes; el cliente recibe los correos de la tienda. Un albarán validado a mano en Odoo sí la manda si está encendida, como cualquier albarán: con tiendas, se deja apagada.
• La ficha del pedido de la tienda en Odoo enseña sus albaranes, el paso hecho y el número que tiene la tienda.

7. Clientes

• Cómo se reconoce un cliente, por este orden:
• Su dirección de facturación, si ya llegó en otro pedido: el cliente de ese contacto.
• El cliente de la tienda enlazado: el conector lo enlaza en su primer pedido.
• Las claves marcadas, siempre en este orden: NIF, email, teléfono, nombre. Por defecto, NIF y email. El NIF se compara sin espacios, signos ni prefijo de país; el email y el teléfono, con los de cualquier contacto, también una dirección, y cuenta su cliente; el nombre, con el del contacto principal, sin distinguir mayúsculas.

Un contacto con otro NIF es otro cliente, y también uno con NIF cuando el pedido no lo trae, o al revés: así una persona que compra para varias empresas, o para sí misma, factura cada pedido a quien toca. - Clientes nuevos: con empresa en la dirección de facturación, un contacto de empresa con su nombre y su NIF; sin empresa, la persona, con su DNI como NIF, que sigue siendo persona aunque tenga NIF (en Odoo 20, que hace empresa a todo contacto con NIF, la casilla «Persona (PrestaShop)» de la pestaña PrestaShop del contacto; quien sabe que es una empresa la desmarca). El NIF es el «Número de IVA» de la dirección o, si no tiene, su «DNI». El contacto lleva la dirección de facturación, el email y el teléfono, y el idioma del cliente en la tienda si Odoo lo tiene activo; si no, el idioma de reserva (bloque 3). - Poner al día el contacto que ya existe: el email, el teléfono y el idioma de un contacto que Odoo ya tiene, con cada pedido nuevo. Solo lo vacío (por defecto) rellena lo que le falta; Siempre escribe lo de la tienda, también sobre lo escrito en Odoo (el email de la empresa pasa a ser el de la persona que compra); Nunca lo deja como está. Sus direcciones no cambian: cada dirección de la tienda es su contacto. - Lo que recibe un contacto nuevo según su grupo (en la fila del grupo de clientes del bloque 3): plazo de pago, posición fiscal (vacía, la que Odoo encuentra por su país), etiquetas y comercial, que también es el de sus pedidos. Todo vacío por defecto. Un contacto que ya existe no lo recibe. - Direcciones: cada dirección de PrestaShop es un contacto hijo del cliente, de factura o de entrega, con el nombre de la persona, enlazado por su id. Una dirección con los mismos datos que el cliente o que otra suya (nombre, calle, código postal, ciudad, provincia y país) usa ese contacto: la tienda crea una dirección nueva al editar una ya usada, y así no se duplica. Por eso un particular sin empresa es su propia dirección de factura, y la factura lleva su nombre una vez («Ana Pérez», no «Ana Pérez, Ana Pérez»); con empresa, «Empresa, Persona». - Cliente de reserva para pedidos sin dirección de facturación: es el cliente y las dos direcciones del pedido. Opcional; sin él, esos pedidos se bloquean (ORDER_CUSTOMER_MISSING). - Grupo por defecto del cliente → equipo de ventas y lista de precios (mapeo del bloque 3). La lista de precios del pedido es la propia del contacto si la tiene en la moneda del pedido; si no, la del grupo si es de esa moneda; si no, la de la tienda en esa moneda. Las líneas llevan siempre el precio que cobró la tienda. - Los enlaces de un contacto con los clientes y direcciones de la tienda se ven en su pestaña PrestaShop, con «Ver en PrestaShop». Un cliente de la tienda se enlaza a mano con un contacto que ya existe con «Vincular un cliente de la tienda» (portal de clientes).

Portal de clientes

Lo que hace el portal, en portal. En el formulario, sección «Portal de clientes», detrás de «Clientes»:

• Portal de clientes en la tienda: apagado por defecto. Encendido, los clientes vinculados ven en su cuenta de la tienda los presupuestos, pedidos y facturas de Odoo que no vienen de la tienda; al encenderlo sube lo de todos los clientes ya vinculados, y al apagarlo Odoo retira de la tienda todo lo que había subido. Necesita el módulo de la tienda con las operaciones del portal: si no las anuncia, la sección lo dice y no se envía nada.
• Vincular automáticamente por email o NIF: apagado por defecto, solo con el portal encendido. Un cliente de la tienda sin vincular con el email o el NIF de un único contacto de Odoo se vincula solo; apagado, esa coincidencia espera en Posibles vínculos a que una persona la confirme, igual que la de un cliente que ya va con otro contacto. El formulario avisa del riesgo al encenderla: cualquiera que se registre con el email o el NIF de un cliente ve sus documentos, así que es solo para tiendas que aprueban a mano cada registro (como la de BK, con su módulo de registro B2B).
• Buscar posibles vínculos (con el portal encendido): pregunta a la tienda por los clientes de todos los contactos con documentos para el portal que aún no están vinculados, y dice cuántos posibles vínculos ha encontrado y cuántos ha vinculado solo. Odoo pregunta también, por cada contacto sin vincular, al enviar uno de sus presupuestos o confirmarlo y al publicar una de sus facturas.
• Posibles vínculos (Ventas › PrestaShop › Posibles vínculos, y el contador de la conexión): cada cliente de la tienda con el email o el NIF de un contacto, con qué coincide. Vincular (también en lote) lo enlaza con el contacto y sube todo lo suyo, junto a lo de los otros contactos con los que ya iba (la misma persona como autónomo y como su sociedad); Descartar no lo vuelve a sugerir; los descartados se ven con su filtro y Volver a sugerir los devuelve. Cada fila abre su contacto de Odoo, y la pestaña PrestaShop del contacto enseña también los suyos. Vincular y descartar son del administrador del conector (PrestaShop / Administrador).
• Vincular un cliente de la tienda (del administrador; en la pestaña PrestaShop del contacto, en la lista de Enlaces y junto a «Buscar posibles vínculos»): busca en la tienda por email, nombre, empresa, NIF o id de cliente y vincula a mano el elegido con el contacto, también si ya va con otros (portal). Necesita el módulo de la tienda con customers.search; sin ella, el contacto no enseña el botón y el diálogo lo dice. No es una opción: no cambia nada de la conexión.
• Quitar el vínculo de un cliente, en la lista de Enlaces o en la pestaña PrestaShop del contacto (del administrador): sus documentos del portal salen de la tienda, o pasan a otro cliente vinculado del mismo contacto, y esa pareja queda descartada.

8. Reglas de validación

Se comprueban antes de crear nada. Si una falla, el pedido no entra y su job queda Bloqueado con el motivo y dónde se arregla (jobs y errores); si fallan varias, el error las cuenta todas.

• El NIF es el «Número de IVA» de la dirección de facturación o, si no tiene, su «DNI»; cualquiera de los dos cumple «NIF obligatorio», y es el que recibe el contacto. El formato se comprueba sobre ese NIF, con la validación de Odoo para el país de la dirección; VIES, sobre el Número de IVA y solo en direcciones de la UE fuera de los países que no se preguntan en VIES: los clientes del país del vendedor no tienen por qué estar dados de alta como operadores intracomunitarios. Con «No comprobar», el NIF pasa al contacto tal cual. Si la tienda ya pregunta a VIES al registrar al cliente (el módulo de registro B2B lo hace), basta con «Formato»: VIES se activa o se desactiva eligiendo entre «Formato» y «Formato y VIES».
• No se vuelve a comprobar el NIF aceptado en un pedido («Aceptar el NIF y facturar») ni el de un cliente que Odoo ya tiene con ese mismo NIF: se comprobó o se aceptó cuando entró.
• VIES falla a menudo un momento: se le pregunta tres veces seguidas (con pausas de 1 y 2 segundos). Si sigue sin responder (el servicio de un país que se apaga de noche), el pedido espera y se reintenta cada 5 minutos, sin gastar intentos, hasta que responde: no se bloquea ni falla un pedido por una caída de VIES. VIES solo se consulta cuando el pedido pasa todas las demás reglas.
• Total exacto: las líneas llevan los precios sin impuestos de la tienda (el total de cada línea entre su cantidad). Si así el total no cuadra al céntimo, por precios con impuestos incluidos y cantidades de más de uno o por un redondeo de impuestos distinto del de la tienda, el pedido de venta va con impuestos incluidos, que da a cada línea exactamente lo que cobró la tienda. El precio unitario lleva los decimales de «Product Price» o, si con ellos el total de una línea no se reparte entre sus unidades (2 unidades por 32,35 en una moneda que convierte la tienda), los 6 de PrestaShop: en Odoo 20 el precio unitario de una línea guarda todos sus decimales. Si tampoco cuadra, ORDER_TOTAL_MISMATCH con la diferencia de cada línea y, si con el otro método de redondeo de impuestos de Odoo cuadraría, cuál: se calcula el pedido con él, porque lo que declara la tienda no lo dice (de 1.7.7 a 9.1, PrestaShop quita un cupón de porcentaje de cada línea antes de redondear su IVA aunque declare redondeo por línea). El pedido guardado se comprueba otra vez: si no suma lo cobrado, no queda nada de él.
• Redondeo de impuestos recomendado: «Redondeo por impuesto», el de Odoo por defecto. Con él cuadran los pedidos de todas las versiones probadas, de 1.7.6 a 9.2: los de una tienda que redondea por línea, con impuestos incluidos, y los cupones de porcentaje de 1.7.7 a 9.1, que con «Redondear por línea» se quedan a un céntimo.
• Los portes y el envoltorio llevan el impuesto de las líneas de su mismo tipo o, si ninguna lo tiene, el único impuesto de Odoo mapeado de ese tipo.
• Antes de crear nada se comprueba también que cada línea tiene su producto (bloque 6), que los portes cobrados tienen su transportista mapeado (bloque 3) y que un pedido con envoltorio tiene su producto.
• Comprobar pasa las reglas a un pedido, o a todos los de un rango, sin crear nada: sirve antes de la puesta en marcha.
• Una extensión añade reglas propias con sus códigos (extensiones).

9. Cobros

En la pestaña «Métodos de pago» de los mapeos, una fila por módulo de pago de la tienda (de system.capabilities):

• Registrar: encendido por defecto. Apagado, el paso Registrar cobro deja fuera los cobros de ese método, y la factura se concilia después con el extracto del banco donde llega el dinero (una transferencia, por ejemplo).
• Diario de Odoo donde entra el cobro y, opcionalmente, Diarios en otras monedas: un cobro en la moneda de uno de ellos va a ese; los demás, al diario. Con la comisión de la pasarela cuenta la moneda en que liquida la pasarela.
• Cuándo se registra: es el paso Registrar cobro del flujo (bloque 6), después de Publicar y antes de Enviar y Subir: el PDF que recibe el cliente ya dice pagada. Sin el paso, el cobro no se registra y la factura se concilia después con el extracto del banco.
• Comisión: ninguna (por defecto): el cobro entra por lo que pagó el cliente, en la fecha de la transacción en la tienda y con su id en la referencia (memo) del pago. O la de la pasarela, solo en un método con pasarela (hoy stripe_official y bksubscriptions, BK Subscriptions with Stripe, también en sus renovaciones): la tienda le pregunta a su pasarela lo que liquidó de verdad por cada cobro (payment.details): el bruto, la comisión y el neto en la moneda en que liquida, con su cambio. Lo pregunta la tienda con la clave de su propio módulo de pago, la de la tienda del pedido y su modo: Odoo no guarda ninguna clave para los cobros de la tienda, y funciona igual en una empresa que no cobra con Stripe en Odoo. El cobro es un solo asiento en el diario, en la fecha del cargo en la pasarela: entra el neto, la comisión va a su cuenta y el cliente paga el bruto, que se concilia con la factura en su moneda (cobros). El diario (o uno de los de otras monedas) tiene que ir en la moneda en que liquida la pasarela.
• Cuenta de comisiones, con la comisión de la pasarela (por ejemplo, Comisiones bancarias).
• Diferencia del cobro, con la comisión de la pasarela: lo que separa el bruto que liquida la pasarela, a su cambio, de lo que la factura debe al cambio de Odoo. Por defecto, la diferencia de cambio de Odoo: el cliente paga el bruto y, al conciliarlo con la factura, Odoo hace su asiento de diferencia de cambio. O en el asiento del cobro: el cliente paga lo que debe la factura y la diferencia va, en el mismo asiento, a la Cuenta de diferencias elegida (así lo lleva BK, a Diferencias en cobros de clientes). Una factura en la moneda de la empresa no tiene diferencia de cambio: con la de Odoo, lo que no cuadre va en el asiento a la cuenta de diferencias de cambio de la empresa.
• Devoluciones desde Odoo (solo lectura): la tienda devuelve los cobros de ese módulo cuando Odoo lo pide, y el pedido y su factura llevan Devolver en la tienda (devoluciones). Lo anuncia la tienda (payment_modules[].refunds); hoy, bksubscriptions. Las devoluciones de un método con la comisión de la pasarela se registran solas en su diario, con su cuenta de diferencias, también las hechas en la tienda o en el panel de la pasarela.
• Pasarela detectada: un módulo de pago cuyos cobros sabe leer la tienda llega, la primera vez que aparece, con la comisión de la pasarela y, si se deduce, con su diario (el del proveedor Stripe de Odoo si cobra con él, o el único diario de banco que se llama como la pasarela). La columna dice la pasarela y, en naranja, si el módulo de la tienda no tiene clave para su modo en alguna tienda activa («Stripe: el módulo de pago de la tienda no tiene clave»). Probar conexión lo pone al día sin cambiar lo elegido.
• Cobros de Stripe del portal de Odoo con su comisión (con bk_prestashop_payment_stripe, que Odoo instala solo si tiene su proveedor Stripe): apagado por defecto. Encendido, cuando Odoo registra el cobro de una transacción de Stripe de su portal (una factura o un presupuesto pagado desde su enlace), el cobro entra neto con su comisión, leída con la clave de ese proveedor, con el mismo asiento, la cuenta de comisiones y la diferencia de la fila de Stripe de la conexión; por eso solo se enciende con esa fila con la comisión de la pasarela y sus cuentas. El neto va a la cuenta de la forma de pago Stripe del diario del proveedor: la del propio diario si se quiere que entre directamente en el saldo de Stripe, o Cobros pendientes hasta conciliarlo con su extracto. Si Stripe no responde, el posproceso de la transacción falla y Odoo lo repite con su propia tarea durante un día, como cualquier fallo del posproceso.

10. Stock (con Inventario)

Con Inventario instalado en Odoo (el puente bk_prestashop_stock llega solo: requisitos). Lo que se envía, cómo y lo que la tienda hace con ello: catálogo.

• Stock en la tienda: PrestaShop (por defecto): la tienda lleva sus cantidades y Odoo no envía ninguna. Odoo: Odoo envía la cantidad de cada producto almacenable enlazado a cada tienda, y la tienda la pisa con la suya. Un producto sin enlazar, que no es almacenable, archivado o con No enviar su stock a PrestaShop (en su pestaña PrestaShop) no se envía: la tienda conserva la suya.
• Cantidad que se envía: Disponible (por defecto: a mano menos lo que reservan los pedidos, lo que aún se puede vender), A mano o Prevista (con las entradas y salidas planificadas). La tienda vende unidades enteras: va la parte entera, hacia abajo.
• De qué almacenes: en cada tienda del bloque 2, Almacenes del stock, cuyas cantidades se suman. Vacío, su almacén de los pedidos; sin él, todos los almacenes de la empresa. Recibe el stock (encendido por defecto) apagado deja esa tienda con sus propias cantidades.
• Cuándo: En cada cambio de stock (por defecto: los productos cuyo stock cambió, en un lote, unos segundos después), Cada hora (todo el stock; la hora es la de la tarea programada «PrestaShop: enviar el stock a las tiendas») o Solo a mano. Enviar el stock ahora lo envía todo en cualquier caso. Cambiar estas opciones, o los almacenes de una tienda, vuelve a enviar todo (salvo «Solo a mano»).
• Multitienda con stock compartido: las tiendas de un grupo que comparte stock en PrestaShop reciben una sola cantidad, la de los almacenes de todas ellas; el bloque lo dice. También avisa de una tienda que no gestiona el stock en PrestaShop (enseña y vende sin mirar la cantidad).
• El bloque enseña el último envío y su resultado; la pestaña PrestaShop de cada producto, lo que tomó cada tienda.
• Con un módulo de la tienda sin stock.set, el bloque pide actualizarlo y no se envía nada. Lo que la tienda rechaza de un producto, en jobs y errores.

11. Cola y avisos

• Tamaño de lote, intentos máximos, espera entre intentos y días que se guardan los jobs hechos: valores por defecto que no hace falta tocar, visibles en modo desarrollador. En el formulario, este bloque se llama Avisos.
• Los eventos de todas las conexiones se leen cada minuto, y al momento con el aviso inmediato. Ese minuto es el de la tarea programada «PrestaShop: leer los eventos de la tienda», y se cambia en ella.
• Avisos de un job bloqueado o fallido: actividad o correo a los usuarios elegidos, o las dos (por defecto, actividad al usuario que crea la conexión).

Módulos de BK Modules

Algunos módulos de PrestaShop de BK Modules hacen posible o mejoran una función del conector. Junto a la opción que mejoran, una línea discreta (el mismo texto gris que explica cada opción) dice qué se gana y enlaza a su ficha en bkmodules.com, en una pestaña nueva; si la tienda ya lo tiene, lo nombra sin enlace y dice cómo ayuda ahí o qué ajustar en él. Lo que tiene la tienda lo dice modules de system.capabilities en la última prueba de conexión: hasta la primera no sale ninguna línea, y un módulo instalado después cuenta desde la siguiente prueba. Ninguna línea cambia nada ni es un aviso: es información junto a la opción.

• Un módulo sin ficha publicada en bkmodules.com no se recomienda: bksubscriptions solo se nombra cuando la tienda lo tiene. Su ficha, cuando se publique, va en BK_MODULE_PAGES (código).
• Las fichas van en inglés; la tienda de BK lleva a cada visitante a la de su idioma. Los nombres y los textos, en los idiomas del addon.

Importación inicial desde la tienda

Para quien parte de PrestaShop: trae a Odoo, una vez, los productos (con sus combinaciones) y los clientes (con sus direcciones) de la tienda. «Importar desde la tienda», en el grupo Productos de la conexión, abre la importación que se está preparando o una nueva; «Importaciones anteriores» lista las hechas. Solo la usa el administrador del conector. Nada cambia en la tienda.

• Qué se trae: Productos (por defecto), con También los desactivados (llegan archivados; sin la casilla, no se importan) y Portadas (la imagen de portada de cada producto que se crea, por defecto); y Clientes (por defecto): los activos que no son invitados.
• Primero, el plan («Preparar el plan»): Odoo lee la lista de productos y la de clientes de la tienda (catalog.list, customers.list) y dice qué pasará con cada uno, sin escribir nada:

Cada fila se puede desmarcar para dejarla fuera. «Preparar el plan otra vez» lo rehace con lo que hay entonces. - Cómo se reconoce lo que Odoo ya tiene: - Un producto, por su referencia y, sin ella y con «Enlazar por código de barras», por su código de barras, entre los productos de la empresa: un producto sin combinaciones con el producto de Odoo sin variantes de su referencia; uno con combinaciones con el producto de Odoo cuyas variantes tienen las referencias de sus combinaciones (cada combinación con su variante; las que no tienen variante se quedan sin enlazar y el plan lo dice). Un producto sin referencia ni código de barras se crea. - Un cliente, con las claves del bloque 7 en su orden (NIF, email, teléfono, nombre, las que estén marcadas), y un contacto con otro NIF es otro cliente. Si coincide con un solo contacto se enlaza; con varios, no se importa y se vincula a mano con «Vincular un cliente de la tienda» (portal). - «Importar» pasa el plan a la cola, en lotes (job import.run): primero los productos, después los clientes. Cada elemento se decide otra vez con lo que hay en ese momento y solo se hace si sigue siendo lo que dijo el plan; si no, la fila lo dice (IMPORT_PLAN_CHANGED) y no se toca. Lo que Odoo rechaza de un elemento se queda en su fila con el motivo y los demás siguen (códigos). Al acabar, la importación queda «Hecha»; para traer lo que faltó, se arregla y se prepara una importación nueva: lo ya importado sale como «Ya enlazado». - Un producto creado lleva de la tienda: el nombre y la descripción corta (como descripción de venta, en texto) en cada idioma de la tienda que Odoo tiene activo y mapeado (bloque 3), la referencia y el código de barras (si ningún producto de Odoo lo tiene ya), el precio sin impuestos y el coste (en la moneda de la empresa, al cambio del día si la tienda tiene otra), el impuesto de su grupo de reglas (la fila de «Grupos de reglas de impuestos»; sin ella, los de Odoo por defecto y el plan lo avisa; «Sin impuestos», ninguno), la categoría de Odoo cuya fila de «Categorías de Odoo en la tienda» va a su categoría por defecto (sin ella, la de Odoo por defecto), el peso (convertido a la unidad de Odoo), si es un servicio (virtual) o un bien y, con Inventario, que es almacenable. Es de la empresa de la conexión. - Sus combinaciones: un atributo de Odoo por grupo (el de la clave de esta conexión, el que se llama igual y crea variantes, o uno nuevo) y un valor por valor, igual. Odoo hace variantes de todas las parejas de valores: las que ninguna combinación tiene quedan excluidas, y una variante que no es ninguna combinación y no se puede excluir así se archiva. Cada variante lleva la referencia, el código de barras, el peso (el del producto más el de la combinación) y el coste de su combinación. El precio de cada valor sale de los impactos de las combinaciones: los valores de la combinación por defecto son la base, y cada valor toma la diferencia de la combinación que solo cambia ese valor; si los impactos no suman así, los precios de los valores quedan a 0 y la fila lo dice. Unas combinaciones sin los mismos grupos no se pueden importar (IMPORT_ATTRIBUTES_UNEVEN). - Un cliente creado: la empresa de su cuenta o, sin ella, la de su dirección más reciente, con su NIF (el de la empresa de la cuenta o, sin él, el de esa dirección), como contacto de empresa; sin empresa, la persona, como en los pedidos. Lleva esa dirección, el email, el teléfono, el idioma (como en el bloque 7) y lo que da su grupo a un contacto nuevo. Cada dirección activa con su mismo NIF, o sin NIF, es un contacto suyo enlazado (o él mismo, si tiene los mismos datos), como en los pedidos; una dirección con otro NIF es otro cliente y entra con su primer pedido. Un cliente que se enlaza recibe así sus direcciones, y nada más cambia en el contacto. - Después: lo importado está enlazado como lo que se enlaza por referencia. Crear y enlazar en la misma operación no envía nada a la tienda; el plan de cada producto dice lo que la tienda recibirá en su primer envío, que sale con el siguiente cambio de un dato que manda Odoo o con «Enviar a PrestaShop» (catálogo). Antes de importar conviene dejar en «PrestaShop» los datos que la tienda debe conservar (las descripciones con formato, por ejemplo: Odoo guarda la corta en texto). Con Odoo en el stock (bloque 10), los productos enlazados reciben el stock de Odoo, que al importar es cero: se importa antes de pasar el stock a Odoo. - Con un módulo de la tienda sin catalog.list, catalog.get o customers.list, «Preparar el plan» pide actualizarlo y probar la conexión.

Licencia

Ventas › PrestaShop › Licencia (solo el administrador del conector), de solo lectura: aquí no se escribe nada. La licencia se compra en bkmodules.com y sus plazas son tiendas: el cliente vincula en su área de licencias la dirección de cada tienda que conecta, como los dominios de un módulo de PrestaShop. La licencia decide qué tiendas se pueden conectar y nada más: nunca para los pedidos, el catálogo o el stock de las tiendas ya conectadas, aunque deje de valer o bkmodules.com no conteste.

• Plazas: cada plaza de producción lleva una de pruebas. Una licencia de N tiendas admite N direcciones de producción y N de pruebas; una dirección es de pruebas si lo es de verdad (test., staging., dev., demo.…, .local, .test, localhost o IP privada), y eso lo decide bkmodules.com, nunca el cliente. La dirección de una tienda es la que da PrestaShop, con su carpeta si la tiene (mitienda.com/es y mitienda.com/fr son dos tiendas), sin esquema, www, puerto por defecto ni barra final. Una dirección solo puede estar en una licencia del conector.
• Quién pregunta: el módulo de PrestaShop de cada tienda pregunta a bkmodules.com por su dirección y entrega a Odoo la respuesta firmada en system.capabilities (contrato). Pregunta como mucho cada doce horas, cuando le habla otra base de Odoo y cuando Odoo pide comprobar: Probar conexión trae la respuesta que la tienda tenga, y «Comprobar ahora» y la tarea diaria «PrestaShop: comprobar la licencia» hacen que cada tienda pregunte ya.
• Respuesta firmada: bkmodules.com firma cada respuesta con Ed25519 y el addon lleva la clave pública. Solo vale una respuesta firmada por BK Modules y de la dirección de la tienda con la que habla esa conexión: un servidor propio, una respuesta editada o la de otra tienda no valen. Se guarda con las capacidades de la conexión y se verifica cada vez que se lee.
• Qué se envía a bkmodules.com (lo dice la propia página, por la regla R4 de Odoo Apps y el RGPD): lo envía la tienda, no Odoo; la dirección y el nombre de la tienda, la versión del módulo y, para que la licencia enseñe dónde se usa, la dirección y el identificador de este Odoo (database.uuid), si es una copia de pruebas y las versiones de Odoo y del conector. Nada más: ni clientes, ni pedidos, ni productos, ni precios.
• La base de Odoo se anota sola en la licencia, con su dirección: de producción, o de pruebas si está neutralizada (odoo-bin neutralize, o una copia hecha con «Neutralizar»). No ocupa plaza; la primera de producción fija la versión de Odoo de la licencia si la compra no la traía.
• Margen sin red: una respuesta vale 30 días desde que se emitió. Si la tienda no puede preguntar (sin red, bkmodules.com sin contestar), entrega la última con el motivo; si la tienda no contesta a Odoo, vale la última que dio.
• Estado de cada tienda (en la página de la licencia, en su fila de «Sin conectar» y arriba de la conexión):

En todos, las tiendas ya conectadas siguen funcionando. Conectar una tienda pide plaza por cualquier camino: a mano, al descubrirla Probar conexión, al crearla ya conectada (por RPC o una importación) y al desarchivar una conexión con tiendas conectadas. Además de que bkmodules.com solo deja vincular las plazas compradas, Odoo cuenta las tiendas conectadas de cada licencia, las de producción y las de pruebas por separado (las de una multitienda que comparten dirección, una por una): nunca deja conectar más de las compradas. - Serie: la licencia es de una versión de Odoo. Una respuesta de otra versión no vale aquí (No válida, «es para Odoo 19.0»), también la que guarda una base traída de otra versión, hasta que la tienda pregunte otra vez. - Versión nueva: si bkmodules.com tiene una versión del conector más nueva para esta versión de Odoo, la licencia y las conexiones lo dicen, con el enlace; se descarga desde el área de licencias. Una versión de otra serie no se avisa. - Plan Continuidad: la licencia enseña hasta cuándo, si lo tiene, y el enlace a la licencia en el área. - Servidor: el módulo pregunta a https://bkmodules.com. BK_ODOO_LICENSE_SERVER en la configuración de la tienda pone otro; como solo valen respuestas firmadas por BK Modules, otro servidor no da licencias.

El lado de bkmodules.com (direcciones vinculadas, plazas, la comprobación firmada y las descargas por serie) está en el módulo bkmodules de la tienda de BK.