Cinco ajustes en el ticket y el voucher. Cada caso se probó en el kit DOSBox, y los de pago QR también contra el gateway real.
Ningún ajuste cambia montos cobrados ni acumuladores, salvo G-01, que corrige justamente eso. F19b, el voucher y el orden de promos son cambios de impresión.
Problema. Si la respuesta al pago (POST /api/trxpago) no llega (timeout de lectura, denegado y el cliente paga después, estado diferido), el POS consulta la transacción (GET /api/trxes/<id>). Cuando la consulta da aprobada, el POS copiaba estado, ids, medio y cuotas, pero no importe_final, importe_recdesc, importe_cashback ni mensajevarios. Resultado: el ticket quedaba por el bruto y la billetera cobraba el neto. Además se perdía el número de autorización.
Ajuste. En los dos bloques "aprobada vía consulta" (pago en localPAGOQR_Op_v2 y anulación en localAnulacionQR_Op) se copian esos cuatro campos, solo si la consulta los informa. Así una consulta incompleta no pisa con cero un cashback ya cargado. Se agregó un log de control:
[G-01] consulta 24: final=7425.00 recdesc=-825.00 cashback=0.00
Prueba. Gateway real con beneficio del 10% y un proxy en el medio que descarta la respuesta del pago (y después la de la anulación), forzando el camino por consulta. Ticket con 3 Coca (8.250).
SUBTOTAL: 8250.00 TOTAL : 8250.00 DINI 8250.00 Billetera cobró: 7425.00 Diferencia de caja: -825.00
SUBTOTAL: 8250.00 Rec/Desc DINI -825.00 TOTAL : 7425.00 DINI 7425.00 PAGO QR Importe original : 8250.00 Dto. beneficio : -825.00 Importe pagado : 7425.00 AutorizacionId : 10311477077088
ANULACION PAGO QR Procesador : DINI Importe original : 8250.00 Dto. beneficio : -825.00 Importe anulado : 7425.00 TrxIdOriginal : 24
antes después delta VENTA 10175.00 17600.00 +7425 REC/DESC -825.00 -1650.00 -825 ANULACION 7700.00 15125.00 +7425 Neto QR 2475.00 2475.00 sin cambio
La sesión de backend confirmó los mismos montos del lado servidor: GatewayQR trx 10178, pago y anulación por 8250 / −825 / 7425.
Reclamo (Salsipuedes). "Aparentemente hace 2 descuentos de $7759.92 cuando solamente debería aparecer 1". El cálculo era correcto: 3% de 258.664 = 7.759,92, y TOTAL = SUBTOTAL − 7.759,92 una sola vez. Era una línea impresa de más.
Causa. PrintRecDescMdeP imprime "Rec/Desc <medio>" para explicar el beneficio de billetera post-pago. Desde el 22/09 se limita a medios QR, pero MERCADOPAGO también es un medio QR. La promo clásica 3#CLUBMAYORIST (previa al pago) deja su descuento en el mismo campo del medio y pasaba el filtro.
Ajuste. La línea se imprime solo si el ticket tiene las filas que materializa el beneficio de billetera (QRDTO). Si no las tiene, el descuento es una promo clásica, que ya tiene su propia línea.
SUBTOTAL: 258664.00 4101877 [6]OF.TANG.POLVO -7596.00 Rec/Desc MERCADOPAGO -7759.92 4100926 3#CLUBMAYORIST -7759.92 TOTAL : 250904.08
SUBTOTAL: 2750.00 00000000 Desc. Esp. 3# -82.50 TOTAL : 2667.50 DINI 2667.50 (sin línea Rec/Desc)
Hallazgo durante la prueba de F19b. El voucher (desglose agregado el 13/10) toma el descuento del registro del medio de pago, que también guarda la promo clásica. En el pago trx 25 la billetera cobró 2.667,50 sin beneficio, pero el voucher decía "Dto. beneficio −82,50".
Ajuste. Usa la misma señal que F19b: el desglose sale solo si el ticket tiene filas del beneficio de billetera.
Reimpresión. Con el ticket ya cerrado no se puede distinguir, porque en dE_DDMP los dos casos quedan idénticos. Por eso el voucher original guarda en memoria de POS_CTOQ.DLL la trx y el beneficio de billetera. La reimpresión del último voucher los usa si la trx coincide; si no coincide (por ejemplo, después de reiniciar el POS), muestra solo el importe pagado. No toca tablas, datos ni exports.
PAGO QR Procesador : DINI Importe original : 2750.00 Dto. beneficio : -82.50 Importe pagado : 2667.50 TrxId : 25
PAGO QR Procesador : DINI Importe : 2667.50 Extraccion Efect. : 0.00 TrxId : 26
PAGO QR Importe original : 2667.50 Dto. beneficio : -266.75 Importe pagado : 2400.75 TrxId :
misma sesión tras reiniciar Importe original 2667.50 Importe 2400.75 Dto. benef. -266.75 Importe pagado 2400.75 TrxId 526 TrxId 526
SUBTOTAL: 2750.00 Rec/Desc DINI SIM -266.75 00000000 Desc. Esp. 3# -82.50 TOTAL : 2400.75
PAGO QR Importe original : 2667.50 Dto. beneficio : -266.75 Importe pagado : 2400.75
Reclamo. Las promos de ítem salen después del SUBTOTAL, pero el SUBTOTAL ya las tiene descontadas: en el ticket del reclamo los ítems suman 266.260 y el SUBTOTAL (258.664) ya restó los 7.596. Piden que salgan antes, para que ítems + promos de ítem = SUBTOTAL, y abajo solo las promos por medio de pago.
Origen. El orden actual viene de un cambio del 09/05/2025 (//20250509), que pasó la impresión de promos de ítem de antes a después del SUBTOTAL. No tiene relación con lo de QR.
Ajuste (impresora no fiscal, Factura B, solo cuando hay SUBTOTAL):
TIC_VHEA.SCP, que imprime solo esa línea.Factura A, impresora fiscal y tickets sin SUBTOTAL quedan exactamente igual. Cada promo se acumula e imprime una sola vez.
Prueba con forma real. En la base de Salsipuedes (SERV0380) no hay promos MdeN ni lista de descuento; las líneas "[n]NOMBRE" son combos (66 activos), y el código de 7 dígitos es el artículo de la promo. Se armó en el kit el combo 199990000 "OF.TANG.POLVO", con la misma forma que el combo real 188470000 (−20% por unidad), sobre maíz.
NroRef: 517449 Items: 169 SUBTOTAL: 258664.00 4101877 [6]OF.TANG.POLVO -7596.00 4100926 3#CLUBMAYORIST -7759.92 TOTAL : 250904.08
NroTicket: 519 Items: 6 4101877 [6]OF.TANG.POLVO 598.80 SUBTOTAL: 2395.20 00000000 Desc. Esp. 3# -71.86 TOTAL : 2323.34
Control: 2.994,00 − 598,80 = 2.395,20 (SUBTOTAL), y 3% de 2.395,20 = 71,86. Pagos, total del ticket y cobrado coinciden en 2.323,34.
Signo del combo (revisado el 30/10). La primera prueba imprimió el combo en positivo (598.80) porque el árbol del kit es anterior al fix del cliente //20261004 (pos_mis2.cpp), que justamente quitó el fabs que dejaba la línea sin signo. Con el pos_mis2.cpp de entrega (fuente del cliente + este ajuste) el combo sale con signo:
NroTicket: 520 Items: 6 4101877 [6]OF.TANG.POLVO -598.80 SUBTOTAL: 2395.20 00000000 Desc. Esp. 3# -71.86 TOTAL : 2323.34
| # | Caso | Cómo | Esperado | Resultado |
|---|---|---|---|---|
| 1 | Pago QR aprobado por consulta, con beneficio | Gateway real 10%, proxy descarta la respuesta de /trxpago. Trx 24, 3 Coca | Ticket 7.425, voucher 8250/−825/7425, autorización presente | OK |
| 2 | Anulación QR por consulta | Proxy descarta la respuesta de /trxanulacion. Trx 24 | Voucher anulado 7.425; G-01 toma 7425/−825 | OK |
| 3 | Caja del medio QR tras pago + anulación | Listado de dE_TMdeP uId 22 | Neto QR sin cambios | OK 2.475 antes y después |
| 4 | Promo 3% pagando QR, sin beneficio: ticket | Gateway real sin beneficio. Trx 25, 1 Coca | Sin línea "Rec/Desc" | OK |
| 5 | Mismo caso: voucher | Trx 25 (antes) y trx 26 (después del ajuste 3) | Voucher solo con "Importe 2667.50" | OK en trx 26 |
| 6 | Beneficio de billetera + promo 3# (regresión) | Simulador 10%, ticket 518 | Ticket con las dos líneas; voucher solo con el beneficio de billetera | OK |
| 7 | Combo de ítem + promo 3# en efectivo | Combo 199990000 sobre 6 maíz, ticket 519 | Combo antes del SUBTOTAL; ítems + combo = SUBTOTAL | OK |
| 9 | Reimpresión del voucher QR en la misma sesión | Simulador 10% + 3#, ticket 526, y reimpresión directa (comando de test 9977) | Reimpresión igual al original: 2667,50 / −266,75 / 2400,75, TrxId 526 | OK |
| 10 | Reimpresión después de reiniciar el POS | Reinicio, login y reimpresión del mismo voucher | Solo "Importe 2400.75", TrxId 526 | OK |
| 8 | Ticket grande con cupón | 14 ítems, cupón MULTIPARQUE, ticket 516 | Ticket y cupón impresos completos | OK |
Evidencia: C:\Work\AI\DINI\E2E_QR\paranoia\evidence\ (G01_*, F19B_e2e_*, F19B_vou_*, M5_*, PORDC_*, PORDM2_*)
Se repitieron las pruebas con un árbol armado desde DINO 20261015Fsrcs.ZIP (los fuentes de producción actuales) más los archivos de entrega\. Build de prueba con -DQRSIM_TEST para los scripts de teclas; build de producción aparte, sin ese define.
| Caso | Cómo | Resultado obtenido | |
|---|---|---|---|
| Pago QR por consulta (G-01) | Gateway real con beneficio 10%, proxy descarta la respuesta de /trxpago. Trx 27 | Ticket SUBTOTAL 2750 / Rec/Desc DINI −266,75 / 3# −82,50 / TOTAL 2400,75. Voucher 2667,50 / −266,75 / 2400,75 | OK |
| Anulación por consulta (G-01) | Proxy descarta la respuesta de /trxanulacion. Trx 27 | Voucher 2667,50 / −266,75 / anulado 2400,75 | OK |
| Promo 3# pagando QR sin beneficio (F19b + voucher) | Gateway real, beneficio vencido. Trx 28 | Ticket SUBTOTAL 2750 / 3# −82,50 / TOTAL 2667,50, sin línea "Rec/Desc" de más. Voucher solo "Importe 2667,50" | OK |
| Reimpresión en la misma sesión | Simulador 10% + 3#, trx 533, reimpresión directa | Igual al original: 2667,50 / −266,75 / 2400,75, TrxId 533 | OK |
| Reimpresión después de reiniciar el POS | Reinicio, login y reimpresión de trx 533 | Solo "Importe 2400,75", TrxId 533 | OK |
| Combo de ítem + 3# | Combo 199990000 sobre 6 maíz | [6]OF.TANG.POLVO −598,80 antes del SUBTOTAL 2395,20; 3# −71,86; TOTAL 2323,34 | OK |
| Ticket grande con cupón | 14 ítems, cupón MULTIPARQUE | SUBTOTAL 14850 / 3# −445,50 / TOTAL 14404,50, cupón impreso | OK |
| Build de producción | make -f postcpnu sin -DQRSIM_TEST | 0 errores. Sin código del simulador en el EXE (0 strings QRSIM, igual que el del cliente). POS_MAIN.LIB idéntica a la del cliente: 2458 exports en el mismo orden | OK |
Nota de la prueba de reimpresión tras reinicio: la primera corrida no imprimió nada porque el último ticket era el del combo (efectivo). La función reimprime solo si el último ticket fue con pago QR; en otro caso muestra "ultimo ticket no es con PAGO QR". Es el comportamiento esperado; se repitió encadenando venta QR y reinicio.
Binarios de producción en C:\Work\TI\20261030\entrega\bin\:
Evidencia: C:\Work\AI\DINI\E2E_QR\paranoia\evidence\P15_*
Entregar desde C:\Work\TI\20261030\entrega\. El árbol del kit es anterior a los fuentes de producción del cliente del 15/10, que tienen el fix 20261004 del signo de combos y no tienen base_amount. Los ajustes se aplicaron como parche sobre los fuentes de producción del cliente (DINO 20261015Fsrcs.ZIP). Entregar los archivos del kit revertiría ese fix, y pos_mppo.cpp no linkearía en su build.
| Archivo | Ajuste | Backup previo |
|---|---|---|
pos_ctoq.cpp (árbol DINO y C:\Work\TI\20261015\pos_ctoq_sinbase\) | G-01 (dos bloques) y voucher QR (venta y reimpresión) | _bak_g01_20261029, _bak_vouf19b_20261030 |
pos_vnta.cpp | F19b | _bak_f19b_20261029 |
pos_mppo.cpp, pos_prom.cpp, pos_mis2.cpp, REPORTER\NOFISCAL\TIC_VHEA.SCP | Promos de ítem antes del SUBTOTAL | _bak_promoorder_20261029 |
-DQRSIM_TEST). La de producción se compila sin ese define. No se agregaron exports, así que las DLL existentes siguen siendo compatibles.TICKET::PagoQR_SumaFilasDescuento, que ya existe en POS_MAIN desde el 17/09.C:\tmp\20260914\pos\real\ no se tocó.Herramientas de prueba (no se entregan): proxy TCP que descarta respuestas del gateway; scripts de teclas para el diálogo de cupones y de combos (MCLEANC, MCLEANC2, PORDC); SETPRCLI con /CLONE y campos long/string para armar promos en el kit.
| Tema | Detalle |
|---|---|
| ABIERTO Respuestas incoherentes del gateway | Recargo positivo, final ≠ importe + recdesc o descuento mayor al total: hoy solo se registra un error en el log y la venta cierra por el bruto, tanto en el pago directo como por consulta. Quedó como cambio aparte. |
| ABIERTO Port de G-01 a Almacor | pcpos/20261003/src/ALMACOR/pos_ctoq.cpp. |
| RESUELTO Signo del combo de prueba | El kit no tenía el fix del cliente del 04/10. Con el archivo de entrega sale −598.80. |
| RESUELTO Reimpresión del voucher QR | Probada (casos 9 y 10). De paso se corrigió un bug previo: la reimpresión imprimía "TrxId" vacío porque leía cCuenta de dE_DDMP, y en esa tabla el id está en cCliente. |
| ABIERTO Datos del kit | Restaurar: promo 290000 (iCliLoyalty a 3), PROMOx6 (vigencia y links a Coca/jugo), combo 199990000. |
| QA CLIENTE Validación en sucursal | Instalar los binarios de entrega\bin\ (o compilar con los fuentes de entrega\) y repetir los casos 4, 5 y 7 con un ticket real de Salsipuedes. |