Ticket 1041 — El POS no aplica el descuento (UAT Tecso)

Sistema Beneficios (DINI/DINO · Tipre) · 01/10/2026 · trx de ejemplo: GWQR id 1206807 / POS id 1196769.

Síntoma reportado

Pago por $200, BeneficiosCenter resuelve $-10, el autorizador cobra $190 — pero el POS no aplica el descuento. En toda la cadena (GWQR, RouterQR, POS) el campo importe_recdesc llega en null, y el POS lee ese campo para imputar el descuento.

importe_final = 190   (el descuento SÍ se cobró)
importe_recdesc = null   ← el POS necesita este campo y viene vacío

Causa raíz bug de GatewayQR

Tecso respetó el contrato. El spec que le pasamos a Tecso (sección 2, "Lo que devuelve el Autorizador") define que el descuento aplicado viaja anidado en benefits_data:

{ "status":"approved", "payment_method_id":990, "amount":190.00,
  "benefits_data": {
     "benefits_card": {...}, "original_amount":200.00,
     "discounted_amount": 10   ← acá, dentro de benefits_data
  } }

Pero GatewayQR leía discounted_amount del nivel superior del webhook (donde Tecso NO lo manda). Entonces nunca armaba importe_recdesc ni se lo pasaba al POS, y notificaba a BeneficiosCenter con descuentoAplicado:null. El importe_final (190) sí salía bien porque ese viene del amount top-level.

¿Por qué no se detectó antes? El emulador interno de GatewayQR emitía discounted_amount en el top level (no como Tecso), así que el E2E contra el emulador pasaba y tapaba el bug durante semanas. El doble de prueba no reflejaba el contrato real.

En resumen: no es un problema de Tecso ni de BeneficiosCenter — es que GatewayQR nunca implementó del todo el contrato que nosotros mismos definimos.

Solución GatewayQR v20261001

AlcanceSolo GatewayQR. BeneficiosCenter no cambia (resolvió bien desde siempre). RouterQR no cambia. Sin migración de DB, sin cambios de config. Archivoshelper/AutorizadorRespuesta.java, web/rest/TrxResource.java, web/rest/util/ConsultarTransaccion.java, web/rest/util/EmuladorBeneficioUtil.java

Verificación OK

36 tests unitarios en verde (incluye test directo del helper con shape real de Tecso + fallback, y regresión del webhook). Se corrió además un code-review del diff: sin bugs de correctitud; solo se cerraron huecos de cobertura. E2E completo: BeneficiosCenter + GatewayQR con el emulador ya emitiendo el shape de Tecso, pago QR por $200 con beneficio 10%:

CampoAntes (reclamo)Ahora
Respuesta al POS · importe_recdescnull-20.00 ✓
importe_final180.00180.00
Notificación a BeneficiosCenter · descuentoAplicadonull20 ✓
DB GatewayQR · trx.importe_recdescnull-20.00 ✓

El importe_recdesc (negativo, como espera el POS para imputar el descuento) ahora llega end-to-end.

Deploy

Release GatewayQR v20261001 — reemplazar el war y reiniciar. Solo el artefacto: sin claves nuevas, sin migración de esquema, sin tocar BeneficiosCenter ni RouterQR.

Nota: la corrección es en el autorizador real (Tecso). El circuito con emulador ya venía "ok" justamente porque el emulador no replicaba el contrato; con esta versión el emulador también lo replica.

Informe generado el 01/10/2026 · Sistema Beneficios · Tipre. Evidencia: traffic_GWQR_id_1206807.log, routerQr.log, 00991001_Router_id_1196769.26L (ticket 1041); contrato: "Beneficios en la intención de pago" (Tipre, 2026-09-10), sección 2.