Tres 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: la línea de Rec/Desc, el voucher y el orden de promos son cambios de impresión.
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. La impresión del ticket agrega "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 del beneficio de billetera. 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 los registros del pago los dos casos quedan idénticos. Por eso el voucher original guarda en memoria 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 ni datos.
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, 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):
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 kit de desarrollo es anterior al fix del cliente del 04/10, que justamente corrigió la línea sin signo. Con los fuentes de la entrega (fuentes 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 | Promo 3% pagando QR, sin beneficio: ticket | Gateway real sin beneficio. Trx 25, 1 Coca | Sin línea "Rec/Desc" | OK |
| 2 | Mismo caso: voucher | Trx 25 (antes) y trx 26 (después del ajuste del voucher) | Voucher solo con "Importe 2667.50" | OK en trx 26 |
| 3 | 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 |
| 4 | Combo de ítem + promo 3# en efectivo | Combo 199990000 sobre 6 maíz, ticket 519 | Combo antes del SUBTOTAL; ítems + combo = SUBTOTAL | OK |
| 5 | Reimpresión del voucher QR en la misma sesión | Simulador 10% + 3#, ticket 526, y reimpresión directa | Reimpresión igual al original: 2667,50 / −266,75 / 2400,75, TrxId 526 | OK |
| 6 | Reimpresión después de reiniciar el POS | Reinicio, login y reimpresión del mismo voucher | Solo "Importe 2400.75", TrxId 526 | OK |
| 7 | 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\
Se repitieron las pruebas sobre los fuentes de producción actuales del cliente (15/10 F) más los ajustes de la entrega. Las pruebas automatizadas usan un build de prueba; el build de producción se compiló aparte, sin el código de prueba.
| Caso | Cómo | Resultado obtenido | |
|---|---|---|---|
| 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 | Compilación sin el código de prueba | 0 errores. Sin código del simulador en el EXE, 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_*
Reclamo recibido: "Andres/Ale: de las pruebas con Tecso en el caso de anulacion hay que verificar impresion de voucher en POS sale con importe sin dto en vez del que pago con DTO, para tener en cuenta ademas en el movimiento/accion financiera en el POS."
Revisión. Se probó sobre los fuentes de producción del 15/10 (en la anulación la entrega no cambia nada), contra el gateway con el emulador y beneficio 10% activo. Venta QR de 2667,50 con beneficio −266,75 (pagado 2400,75), trx 29, y anulación directa.
| importe | importe_recdesc | importe_final | |
|---|---|---|---|
| Respuesta del pago | 2667,50 | −266,75 | 2400,75 |
| Respuesta de la anulación | 2667,50 | −266,75 | 2400,75 |
| Qué se verificó | Resultado | |
|---|---|---|
| Voucher de anulación | Importe original 2667,50 / Importe anulado 2400,75 (lo pagado con descuento) | OK |
| Movimiento financiero del medio QR | Pago: ventas +2400,75. Anulación: anulaciones +2400,75. Efecto neto en caja QR: 0 | OK |
| Registros financieros de la anulación | −2400,75 en ambos, por el neto; nunca por el bruto | OK |
Conclusión. Con la versión 15/10 el bug reclamado no se reproduce: el voucher y la imputación de la anulación salen por el importe pagado con descuento, como inverso exacto del pago. El POS toma los montos de la consulta del pago original y no los de la respuesta de anulación, de modo que un placeholder en esa respuesta (por ejemplo, el importe = 1 que devolvía el emulador de Tecso) no afecta. Condición: el gateway debe informar en la consulta del pago los mismos importe e importe_recdesc del pago; si el descuento no viene informado, la anulación se calcularía por el bruto.
A tener en cuenta: la anulación no modifica el acumulador de Rec/Desc del medio QR; el descuento queda en el ticket, porque se anula el pago, no el ticket.
Evidencia: C:\Work\AI\DINI\E2E_QR\paranoia\evidence\P16_venta_*, P16_anul_*, P16_tmdep_*