Pago contra reembolso (COD)¶

El pago contra reembolso (COD) permite que un cliente de la tienda web pague un pedido en efectivo (o con tarjeta) en el momento de la entrega del paquete, en lugar de pagar en línea al finalizar la compra. Dado que un único pedido de venta puede enviarse en varios envíos independientes (una ruta de almacén de varias etapas, un pedido pendiente por falta de existencias, una entrega parcial), el importe a cobrar en cada envío debe calcularse individualmente, y el riesgo de un cliente de COD poco fiable debe evaluarse antes de confirmar el pedido. eYssen cubre ambos problemas con dos módulos específicos: uno calcula el importe correcto de COD por envío para las integraciones de transportistas, y el otro filtra los métodos de pago de tipo contra reembolso al finalizar la compra frente a la base de datos de fraude compartida utanvet-ellenor.hu.

Ver también

Métodos de pago según el método de envío: cómo se filtran los proveedores de pago por método de envío, y la experiencia de pago contra reembolso al finalizar la compra
Integración con GLS, Integración con Foxpost y Integración con MPL: las integraciones de transportistas que llaman al cálculo de COD
Entrega condicionada al pago: retener las entregas hasta que se pague un pedido

screenshot: cash-on-delivery-checkout-payment-methods

menu: Website app ‣ open the shop ‣ add a product to the cart ‣ proceed to checkout ‣ reach the Payment step
shows: The website checkout payment step for a logged-in customer whose reputation is above the configured threshold, showing the "Payment on Delivery" option next to the other payment methods.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

Funciones principales¶

Cálculo dinámico de COD por entrega. Cada entrega saliente obtiene su propio importe de COD, proporcional a los productos que realmente contiene, de modo que los envíos parciales y de varias etapas nunca cobren de más ni de menos al cliente.
Un único cálculo compartido por todos los transportistas. GLS, Foxpost y MPL llaman al mismo método subyacente al construir su solicitud de etiqueta de envío, de modo que la regla de negocio reside en un único lugar en lugar de duplicarse por transportista.
Verificación compartida contra la base de datos de fraude al finalizar la compra. Los proveedores de pago se pueden marcar individualmente para ocultarlos a clientes con mala reputación en la base de datos compartida de Utánvét Ellenőr, incluso antes de realizar el pedido.
Permisivo por defecto ante fallos. Si la API de verificación de fraude no está disponible, no se bloquea el pago a menos que un administrador opte explícitamente por la política más estricta.
Informe de circuito cerrado. Las entregas exitosas y las fallidas o canceladas se notifican a Utánvét Ellenőr de forma asíncrona, de modo que la base de datos compartida se mantiene precisa para todos los comercios que la utilizan.

Cómo se calcula el importe de COD¶

El módulo eyssen_delivery_cod agrega un campo de solo lectura cod_amount a Transfers (stock.picking) y un único método, _compute_dynamic_cod(), que las integraciones de transportistas llaman al preparar un envío. No se activa automáticamente: GLS (eyssen_delivery_gls), Foxpost (eyssen_delivery_foxpost) y MPL (eyssen_delivery_mpl) dependen cada uno de eyssen_delivery_cod y llaman al método con el ID XML de su propio proveedor de "Payment on Delivery" al construir la solicitud de etiqueta de envío de un traslado.

screenshot: cash-on-delivery-picking-cod-amount

menu: Inventory app ‣ Transfers ‣ open the outgoing delivery for a COD sale order (after it has produced a shipping label)
shows: An outgoing delivery transfer form for an order paid through a carrier's "Payment on Delivery" method, with the read-only COD Amount field visible next to the Carrier field.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

El método solo calcula un importe cuando la última transacción de pago del pedido de venta corresponde al propio proveedor de "Payment on Delivery" de ese transportista; para cualquier otro método de pago, devuelve 0.0 y registra un aviso. Cuando sí se aplica, el importe se construye de la siguiente manera:

Valor de los productos de esta entrega: para cada movimiento de existencias del traslado que esté vinculado a una línea del pedido de venta, el precio unitario de la línea (price_total ÷ product_uom_qty, es decir, impuestos incluidos) se multiplica por la cantidad realmente enviada en este traslado.
Valor de los productos ya enviados: el mismo cálculo se repite para cada otro traslado del mismo pedido que ya tenga un cod_amount establecido, es decir, las entregas enviadas anteriormente.
Líneas de servicio: las líneas del pedido que no son productos almacenables/consumibles y que no son un anticipo (por ejemplo, recargos de envío) se añaden en su totalidad al total acumulado.
Anticipos facturados: las líneas de anticipo del pedido con una cantidad facturada se calculan con impuestos (mediante tax_id.compute_all) y se restan del total acumulado.
Importe ya cobrado: la suma de cod_amount de los traslados hermanos ya enviados se resta del objetivo acumulado para obtener el importe que aún se adeuda.
Límite del total del pedido: el resultado se limita para que la suma de todo lo cobrado en todas las entregas del pedido nunca supere el amount_total del pedido.

Nota

Dado que el objetivo acumulado ya incluye las líneas de servicio desde el primer cálculo en adelante, y cada entrega posterior resta lo que las entregas anteriores ya cobraron, en la práctica el cliente solo paga las líneas de servicio una vez, junto con la primera entrega que se envía.

El importe resultante se almacena en stock.picking.cod_amount y se muestra, de solo lectura, en el formulario de entrega justo después del campo Carrier (oculto mientras sea cero). Cada módulo de transportista utiliza después ese importe para completar el campo "collect on delivery" de su propia solicitud de etiqueta. Algunos transportistas, además, imponen su propio límite máximo sobre este cálculo; por ejemplo, Foxpost se niega a generar una etiqueta por encima de 150 000 HUF.

Importante

eyssen_delivery_cod no tiene pantalla de configuración propia. Solo se activa una vez que se instala un módulo de transportista que depende de él (GLS, Foxpost o MPL) y el cliente paga a través del propio método de "Payment on Delivery" de ese transportista.

La verificación de fraude de Utánvét Ellenőr al finalizar la compra¶

El módulo utanvetellenor integra la base de datos compartida de reputación de clientes utanvet-ellenor.hu, que varias tiendas web húngaras alimentan con los resultados de las entregas. Se conecta en dos puntos del ciclo de vida del pedido: el filtrado de métodos de pago al finalizar la compra, y la notificación posterior del resultado de la entrega.

Filtrado de proveedores de pago al finalizar la compra¶

El módulo amplía la búsqueda de proveedores de pago compatibles para que cualquier Payment Provider con la opción Utánvét Ellenőr Check habilitada solo se ofrezca a clientes cuya reputación supere el umbral configurado.

screenshot: cash-on-delivery-provider-check-toggle

menu: Website app ‣ Configuration ‣ Payment Providers ‣ open "Payment on Delivery" ‣ Configuration tab ‣ Availability group
shows: A "Payment on Delivery" payment.provider form (e.g. the one created by eyssen_delivery_gls) with the Configuration tab open on the Availability group, showing the "Utánvét Ellenőr Check" checkbox.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

Si ningún proveedor habilitado tiene la verificación activada, el módulo no hace nada, sin coste de rendimiento para las tiendas que no lo utilizan.
Antes de llamar a la API, el módulo verifica que el contacto de la compra sea el propio contacto del usuario actual, un contacto de la misma entidad comercial, o que quien realiza la llamada sea un usuario interno; esto evita que el endpoint se utilice para consultar la reputación de un cliente arbitrario.
El correo electrónico, el teléfono del cliente (normalizado a E.164 mediante phone_validation cuando está instalado), el código de país, el código postal y la dirección postal se envían al endpoint /request junto con el umbral de reputación configurado; el nombre, los datos de pago y los números de identificación fiscal nunca se envían.
El veredicto se guarda en caché en memoria por proceso worker durante cinco minutos, indexado por empresa, contacto, el write_date del contacto, el umbral y el modo; de este modo, cualquier edición local de los datos de contacto del contacto invalida inmediatamente el veredicto en caché.
La respuesta HTTP de la API se traduce en una decisión: un resultado blocked, un 204 (buzón temporal o inexistente), un correo electrónico faltante, o un 404 (cliente desconocido, siempre permitido) se gestionan todos explícitamente. 401 (claves incorrectas) y 402 (cuota agotada) se registran pero nunca bloquean el pago por sí mismos; solo los fallos de transporte genuinos (tiempo de espera agotado, error de conexión, 5xx) y los errores de cuota están sujetos a la política de reserva que se describe a continuación.

Importante

Cuando el cliente está bloqueado, o se produce un error de transporte/cuota mientras Fallback on API Error está configurado en Block payment, todos los proveedores que tengan habilitada la Utánvét Ellenőr Check se eliminan de la lista de métodos de pago ofrecidos al finalizar la compra. Los proveedores que no participan, por ejemplo un método de pago con tarjeta, nunca se ven afectados.

Cada llamada a la API que produce un bloqueo o un error se puede registrar como una nota interna en el cliente, controlada por el ajuste Chatter Verbosity:

screenshot: cash-on-delivery-partner-chatter-log

menu: Contacts app ‣ open a customer that has placed a webshop order paid by a guarded provider ‣ chatter / Log note history
shows: A res.partner (Contacts) form with the chatter open, showing an internal note logged by the module after a blocked or errored check (Mode, Threshold, HTTP status, Good/Bad, Reputation, Blocked, Reason lines).
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

La nota registra el modo, el umbral, el estado HTTP, los recuentos positivos/negativos de la API, la reputación numérica y el motivo textual; nunca las claves de la API.

Notificación del resultado¶

Una vez que se valida o se cancela una entrega saliente vinculada a un pedido de venta pagado a través de un proveedor protegido, el módulo pone en cola una señal para que la base de datos compartida conozca el resultado:

validar el traslado (_action_done) pone en cola el resultado 1 (Successful delivery (+1));
cancelar el traslado (action_cancel) pone en cola el resultado -1 (Failed / refused (-1)).

Solo se crea una fila en la cola si el traslado es saliente, está vinculado a un pedido de venta, y dicho pedido tiene una transacción en estado done en un proveedor con la Utánvét Ellenőr Check habilitada. Una restricción de la base de datos garantiza como máximo una fila por traslado y resultado, y un traslado revalidado nunca puede poner en cola un resultado contradictorio una vez que ya se ha enviado uno.

screenshot: cash-on-delivery-signal-queue-list

menu: Website app ‣ Configuration ‣ Utánvét Ellenőr signals
shows: The Utánvét Ellenőr signals list view with a few rows in different states, showing the green/red/grey state decorations and the Retry button on a failed row.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

Las filas en cola se pueden ver en Website ‣ Configuration ‣ Utánvét Ellenőr signals, con un código de color según el State (Pending, Sent, Failed). Una acción programada, Utánvét Ellenőr: send pending signals, se ejecuta cada 10 minutos y procesa hasta 100 filas pendientes por ejecución, reintentando las llamadas fallidas hasta tres veces con una espera de 5 minutos, luego 30 minutos y luego 2 horas, antes de marcar una fila como Failed. Un administrador puede restablecer una fila fallida con el botón Retry para que el cron vuelva a procesarla.

Configuración¶

eyssen_delivery_cod no necesita configuración: instálelo como dependencia de un módulo de transportista y el cálculo de COD se ejecutará automáticamente para los pedidos pagados a través del método "Payment on Delivery" de ese transportista.

Para configurar la verificación de Utánvét Ellenőr:

Instale utanvetellenor.
Vaya a Website ‣ Configuration ‣ Settings ‣ Shop - Checkout Process ‣ Utánvét Ellenőr y configure:
- Mode: Sandbox o Production;
- el par de claves pública/privada correspondiente a ese modo;
- Reputation Threshold: un valor entre -1.0 y +1.0 (0.5 de forma predeterminada);
- Fallback on API Error: Allow payment (predeterminado) o Block payment;
- API Timeout (s): el tiempo de espera HTTP utilizado en cada llamada (5 de forma predeterminada);
- Chatter Verbosity: All API calls, Blocked customers and errors only (predeterminado) o Errors only.
screenshot: cash-on-delivery-settings
menu
Website app ‣ Configuration ‣ Settings ‣ Shop - Checkout Process section ‣ Utánvét Ellenőr
shows
The Website Settings page scrolled to the "Shop - Checkout Process" block, with the "Utánvét Ellenőr" collapsible setting expanded showing Mode, key fields, Reputation Threshold, Fallback on API Error, API Timeout and Chatter Verbosity.
module
eyssen_delivery_cod, utanvetellenor
notes
English UI, light theme, 1440px width.
En cada proveedor de pago que deba protegerse (normalmente un método de pago contra reembolso o de transferencia bancaria), abra la pestaña Configuration, grupo Availability, y habilite Utánvét Ellenőr Check.

Importante

La integración es un acuerdo de corresponsabilidad en el tratamiento de datos: envía el correo electrónico, el teléfono, el código postal, el código de país y la dirección del cliente a un tercero. Firme el acuerdo de corresponsabilidad de datos con Utánvét Ellenőr y actualice la política de privacidad de la tienda antes de habilitar la verificación en el modo Production.

Nota

Las claves de API de sandbox y de producción se almacenan en texto sin cifrar en el registro de la empresa; el widget de contraseña en Settings solo oculta el valor en pantalla. El acceso a Settings está restringido al grupo Administration / Settings (base.group_system), y se requiere el mismo grupo para abrir la cola de señales y ver las claves de API; nunca reduzca esta restricción. Utilice pares de claves diferentes para sandbox y producción, de modo que una clave de prueba filtrada no se pueda reutilizar contra la base de datos en producción.

Uso¶

Un cliente finaliza la compra en el sitio web. Si algún proveedor de pago ofrecido tiene habilitada la Utánvét Ellenőr Check, el módulo busca (o reutiliza el veredicto en caché) la reputación de ese cliente y oculta los proveedores protegidos si el cliente está bloqueado, o si la API falló y la política de reserva está configurada en Block payment. Los demás métodos de pago siguen disponibles en cualquier caso.
El pedido se confirma y el almacén procesa la entrega, en uno o varios envíos, según la ruta y la disponibilidad de existencias.
Cuando el módulo de transportista (GLS, Foxpost o MPL) genera la etiqueta de envío de un traslado pagado a través de su propio método de "Payment on Delivery", llama a _compute_dynamic_cod() para calcular exactamente cuánto cobrar en esa entrega, y lo almacena en el campo COD Amount del traslado.
Una vez que el traslado se valida (entregado) o se cancela, se pone en cola una señal automáticamente y la acción programada la envía a Utánvét Ellenőr en unos 10 minutos, de modo que la base de datos de reputación compartida refleja el resultado real para futuras verificaciones, tanto de esta tienda como de cualquier otro comercio que utilice el servicio.

Alcance y módulos¶

eyssen_delivery_cod: calcula el importe dinámico de COD por entrega (envíos parciales, líneas de servicio, anticipos, límite del total del pedido) compartido por las integraciones de transportistas.
utanvetellenor: integra la base de datos de fraude compartida utanvet-ellenor.hu en el proceso de compra (filtrado de proveedores de pago) y en la notificación posterior al cumplimiento (cola de señales y cron de reintentos).