Cambios en el POS: descuento por pago QR

1. Que hace el POS cuando la billetera devuelve un descuento

Al cobrar con PAGO QR, la respuesta de la operacion puede traer un beneficio ya aplicado por la billetera. El POS lo recibe despues de que la operacion fue autorizada — de ahi "post-pago" — y debe reflejarlo en el ticket, en los libros fiscales y en el cierre Z sin pedirle nada al cajero.

1.1 Los tres campos que el POS lee

D = -importe_recdesc                      // beneficio, siempre >= 0
r = D / Ticket.TotalCobrar                // ratio global (TotalCobrar incluye percepcion)
condicion de aceptacion: importe_final == importe + importe_recdesc  (tolerancia 0.005)

1.2 La secuencia dentro del POS

PagoQR_ImputarDescuento() (pos_mppo.cpp:3622) corre dentro del lazo de autorizacion de _ProcessKeyTOTAL(), justo antes del Update() de la fila del medio de pago. En ese punto hace, en este orden:

1. valida las cinco guardas de entrada (seccion 5.1);
2. agrega al detalle del ticket una fila por bucket de IVA (TICKET::PagoQR_AppendFilasDescuento, pos_tic2.cpp:1153), con bAcumulado=1 y monto negativo;
3. reescala la percepcion (RecomputePercepcionxPromoMdeP(1, ...));
4. prorratea dataRedondeos (relevante solo con impresora fiscal);
5. baja los totales del ticket con ViewSaldo(-D);
6. ajusta Ticket.total[n] (importe -= D, recdesc += importe_recdesc);
7. escribe la fila de dE_MdeP/dE_DMdeP con importe_final, importe_recdesc y el id de autorizacion.

1.3 La decision de diseno que define todo lo demas

El beneficio se persiste igual que una promocion por medio de pago clasica: una fila real de ETdet → dB_TDeta/dE_TDeta por bucket de IVA. A partir de ahi TICKET::ComputarBinario netea dE_TResu solo, porque arma totalTRESU exclusivamente barriendo ETdet; y el ticket impreso, el CAE, el Informe Impositivo y la Nota de Credito ven el descuento sin ningun parche puntual, porque todos leen ese mismo detalle.

No se reuso el motor de promociones. ImputaPromocionesXCodigoDescuento esta acoplada a EProm/MProm/acupro, a ControlUsoUnaSolaVezMdeP y al monto que teclea el cajero (dMontoIngresado), no a un hecho post-autorizacion. Lo que se reuso es el patron de datos, no la funcion.

1.4 Numeros de referencia (ticket M1)

items (bAcumulado=0)         2750.00     neto 2145.21 + IVA21 450.50 + imp.int. 154.29
fila del beneficio           -275.00     neto -214.52 + IVA21  -45.06 + imp.int. -15.42
                             --------
dE_TResu.fPrecioTotal         2475.00    fNetoFiscal1 1930.69 / fTax0Fiscal 405.44 / fImpInterno1 138.87
dE_DDMP  PAGO QR              2475.00    dRecDesc -275.00
ticket impreso                SUBTOTAL 2750.00 / Rec-Desc -275.00 / TOTAL 2475.00
QR AFIP                       "importe": 247500

2. Flujo interno del POS

3. Tablas afectadas y consumidores

3.1 dB_TDeta / dE_TDeta (detalle del ticket) — el cambio central

Las filas de item (bAcumulado=0) no se tocan: siguen con el precio bruto de catalogo. Lo nuevo son las filas del beneficio, que escribe TICKET::PagoQR_AppendFilasDescuento() copiando campo por campo el patron de ImputaPromocionesXCodigoDescuento (pos_tic2.cpp:869-919).

Ejemplo M1: un item 21%, beneficio 10% → una sola fila

cEan          Articulo  iDepto  iPromocion  bAcu  iTax  PrecioFiscal  fNetoFiscal  Tax0Fiscal  fImpinterno
7799999999991 QRTEST01     777      990077     1    0       -275.00      -214.52      -45.06       -15.42

Ejemplo M2: 21% + 10.5% + exento → tres filas

cEan          Articulo  iDepto  iPromocion  bAcu  iTax  PrecioFiscal  fNetoFiscal  Tax0/2Fiscal  fImpinterno
7799999999991 QRTEST01     777      990077     1    0        -274.99      -214.52       -45.06        -15.41
7799999999991 QRTEST01     777      990077     1    2         -49.91       -45.16        -4.75          0.00
7799999999991 QRTEST01     777      990077     1    1        -149.00      -149.00         0.00          0.00
                                                       suma  -473.90  ==  -D

Una fila por bucket con monto distinto de cero. Un bucket sin items no genera fila. Los valores de cEan/Articulo/iDepto/iPromocion del ejemplo son los de prueba; en produccion salen de los perfiles cargados (seccion 4).

3.2 dE_TResu (resumen del ticket)

Se llena integramente en TICKET::ComputarBinario(0, ...). Con -DNOCOMPUTAREDONDEOS activo (postcpnu.mak:137), totalTRESUPromo — donde caen las filas bAcumulado==1 — se suma a totalTRESU antes de los assign, asi que las filas del beneficio bajan los campos por si solas.

Las tasas salen de Fact.TaxPorc[0] (21%) y Fact.TaxPorc[2] (10.5%), con fallback IVA/neto de la propia fila si Fact no viene cargada.

3.3 dE_DDMP (medios de pago del ticket) y su espejo .BIN

Cambio de QRFILA en Dump2DDMP (pos_misc.cpp:4717)

if(!EsPagoQR(uId, uIdId))	//20260913 QRFILA
	dTotalRecDescMPP += dRecDesc;

Con las filas de detalle, fPrecioTotal ya viene neto; acumular ademas el dRecDesc del QR en fRecDescMPP haria que ReadTRESU_Totals (camino de recuperacion ReStartEndVueltoOK, pos_vnta.cpp) lo restara dos veces. El monto no se pierde: sigue en dE_DDMP.dRecDesc, que es de donde ya lo lee AnalyzeRecDesc (pos_info.cpp:3873) para el informe de recargos y descuentos.

Cambio de contrato a avisar: una promo por medio de pago sobre un medio que no sea QR sigue entrando en fRecDescMPP, y como esa promo tambien netea fPrecioTotal por sus propias filas, ReadTRESU_Totals la restaria dos veces en el camino de recuperacion. Es un hueco preexistente, anterior a este trabajo, pero ahora esta identificado.

3.4 dE_MdeP / dE_DMdeP y dE_TMdeP

• dE_MdeP (memoria, browse de medios ingresados): dImporte = importe_final, dRecDesc = importe_recdesc. Es la fila que recorre PrintRecDescMdeP para imprimir la linea Rec/Desc.
• dE_DMdeP: espejo de la anterior; su vData es lo que lee PagoQR_BloquearBorradoMdeP.
• dE_TMdeP: no tiene campo de ticket (esta indexada por iNroY: son movimientos de valores del cajero). Ticket.total[n].importe -= D y Ticket.total[n].recdesc += importe_recdesc hacen que UpdateTMdeP grabe el importe cobrado real mas una accion idRECARGO_DESCUENTO (pos_mppo.cpp:1205), que es lo que hace cerrar el Z. CheckLimites no rechaza porque VALIDAR(Ticket.TotRecDesc) ya es cierto.

3.5 ZLOG\<Z>.bin

Binario de items de la Z, escrito al cerrar la Z. El equivalente vivo de una Z abierta es BASES\DB_TDETA.BIN, identico en layout (mismo DDF, mismo escritor DdfBin). Es la fuente del Informe Impositivo, que lo copia a vT_TDeta y lo recorre separando por iTax y por bAcumulado: como las filas del beneficio viven en el detalle, ese informe ya las ve.

3.6 dM_Profi

Cuatro perfiles nuevos (564-567, seccion 4). No se agrego ni se modifico ningun campo DDF en todo el trabajo.

3.7 Matriz de consistencia de los consumidores

La identidad que ata los tres libros:

SUM(dB_TDeta.PrecioFiscal, filas no-percepcion)
  == dE_TResu.fPrecioTotal - percepciones
  == SUM(dE_DDMP.dImporte) - percepciones

4. Configuracion: perfiles

4.1 Perfiles nuevos (564-567)

Identifican la fila de detalle del beneficio. 563 era el ultimo id definido en pos_prof.h y 553 el ultimo presente en la tabla dM_Profi de la copia de prueba, asi que 564-567 estaban libres de los dos lados. Declarados en pos_prof.h:672-675; miembros de GLOBALPROFILE en pcpos.h:571-574; leidos en pos_main.cpp:4692-4699; resueltos en un solo lugar por PagoQR_FilaIds() (pos_tic2.cpp:1095).

4.2 Perfiles existentes que influyen

5. Reglas de calculo y guardas

5.1 Guardas de entrada (PagoQR_ImputarDescuento, pos_mppo.cpp:3622)

Fuera de esta funcion hay una guarda mas: ActiveDMdeP() (pos_mppo.cpp:3240) impide cargar el PAGO QR dos veces en el mismo ticket — "Error, solo permitido ingreso PAGOQR una vez!".

5.2 Ratio global y ratio efectivo

D        = -importe_recdesc                          ROUND_DOUBLE
r        = D / Ticket.TotalCobrar_antes              // ratio global, con percepcion incluida
dDVenta  = ROUND((Ticket.TotalCobrar_antes - Ticket.Percepcion) * r)
r_eff    = dDVenta / SUM(PrecioFiscal de las filas de item)

• Por que r incluye la percepcion: el D informado se calculo sobre el total que el POS pidio cobrar, y ese total ya venia inflado por la percepcion bruta.
• Por que el lado venta la resta: a la percepcion le baja su parte RecomputePercepcionxPromoMdeP por separado. Restarle a la venta el D completo la cortaria dos veces. Sin percepcion, dDVenta == D exacto y el ajuste es un no-op bit a bit.
• Por que existe r_eff: un ticket que ya trae una promo por medio de pago tiene el Ticket.TotalCobrar bajado por esa promo, pero todavia no tiene su fila en ETdet (se escribe mas tarde, en ProcesarRedondeos_y_Descuentos). Recalcular el ratio contra el bruto real de los items es lo que hace que las filas sumen exactamente -dDVenta: medido, r_eff = 0.097000 contra el r = 0.100000 global.

5.3 Reparto por bucket de IVA

Se barre ETdet con los mismos buckets que ComputarBinario (indice 0 = 21%, 1 = 10.5%, 2 = EXENTO), tomando solo filas de item (bAcumulado==0 y iTax que no sea percepcion), y acumulando por bucket precio, IVA, impuestos internos y neto. Despues, por bucket:

K   = ROUND(N * r_eff)                   // recorte del neto
N'  = N - K                              // neto descontado
II' = ROUND(II * (1 - r_eff))            // impuestos internos escalados
T'  = ROUND(N' * (1 + tasa)) - N'        // IVA RECALCULADO, nunca prorrateado
fila_j = (N' + T' + II') - (N + T + II)  // el monto de la fila es el DELTA, negativo

5.4 Residuo de centavos

residuo = -dDVenta - SUM(fila_j)

Va entero a los impuestos internos del bucket de neto mas grande, entre los buckets que tienen items. Es el mismo destino que le da ImprimirIVAS, que saca los impuestos internos por diferencia contra Ticket.TotalCobrar: por eso la fila persistida queda identica a la impresa y a la del CAE. Medido: M1 persiste II 138.87 (residuo +0.01) y M2, con un articulo 10.5% y uno exento mas, persiste II 138.88. En un ticket solo exento o solo 10.5% el residuo cae en los impuestos internos de ese unico bucket con neto, que es lo que hace tambien la impresion.

5.5 Percepcion

if(POSConPercepcionesHabilitadas() && VALIDAR(Ticket.Percepcion)){
    double dNetoSinPercepcion = dTotalAntes - Ticket.Percepcion;
    RecomputePercepcionxPromoMdeP(1, -1.0L * dRatio * dNetoSinPercepcion, dRecDescPorPercep);
    }

Se alimenta con -r * NetoSinPercepcion para que el ratio interno de RecomputePercepcionxPromoMdeP reproduzca r exacto. Reescala Ticket.Percepcion y Ticket.NetoTicketReal; no toca ninguna fila de ETdet, ni siquiera la fila sintetica de percepcion. Deja ademas el historial en percepcionPromoArray, que es lo que permite revertirlo con RecomputePercepcionxPromoMdeP(2, ...). Medido: sin QR, neto 2145.21 → fTax1 64.36; con beneficio del 10%, neto 1930.69 → fTax1 57.92 (cociente 0.8999).

5.6 Orden de las llamadas

5.7 Caso limite: beneficio del 100% (r == 1)

La guarda 4 rechaza solo D > TotalCobrar (estricto), asi que D == G pasa. La formula por bucket con r_eff == 1 da K = N, N' = 0, II' = 0 y T' recalculado sobre neto cero, sin ningun caso especial. Medido: filas sumando -4739.00, todos los buckets en 0.00, fPrecioTotal 0.00, ticket impreso TOTAL 0.00. El POS no rechaza un total de 0.00. Los rangos que acotan este ratio usan limite superior cerrado (0 < r <= 1.0 + 1e-9, con clamp a 1.0 exacto): un intervalo abierto dejaria el caso del 100% sin netear (ver seccion 9).

6. Bloqueo de borrado de un PAGO QR autorizado

6.1 La politica

Una fila de PAGO QR ya autorizada no se puede borrar desde la pantalla de medios de pago — la billetera ya cobro. El camino correcto es la Reversa QR. Una fila de PAGO QR cargada pero no autorizada si se puede borrar, y en ese caso se limpia todo lo imputado.

6.2 La exposicion: donde queda el ticket abierto despues de autorizar

En el camino feliz el ticket cierra en la misma tecla y no hay ventana. Las salidas por error posteriores a la imputacion son la exposicion:

Sin guarda, al borrarse la fila de PAGO QR quedaban en ETdet las filas del beneficio y en memoria los acumuladores: un ticket pagado despues en efectivo persistia igual el descuento.

6.3 El precedente y la guarda

El criterio ya existia en la casa para tarjetas EMV (pos_mppo.cpp:1563, DeleteLastCardYaAutorizada): una tarjeta ya autorizada no se borra desde la pantalla de medios de pago. La guarda de QR se inserta en pos_mppo.cpp:1581, inmediatamente despues de la EMV y antes de SPbase->Remove(); el cuerpo vive en pos_tic2.cpp:1174.

if(PagoQR_BloquearBorradoMdeP(SPbase, _iIdMdeP, _iIdIdMdeP, cQRDto_TrxId))
	return 1;

1. EsPagoQR(uId, uIdId) → si no es QR, no hace nada.
2. Marca de autorizacion = vData de la fila de dE_DMdeP de este ticket; si esa fila no lo trae, cae al acumulador en memoria.
3. Sin marca → se permite borrar (QR cargado pero nunca autorizado).
4. Con marca → Error("PAGO QR autorizado: anule via Reversa QR"), log de error y corta.

6.4 Limpieza cuando el borrado si procede

pos_mppo.cpp:1612 llama a PagoQR_RevertirImputacionMdeP() (pos_tic2.cpp:1198), que:

1. Saca del detalle las filas del beneficio (TICKET::PagoQR_RemoveFilasDescuento, pos_tic2.cpp:1207), identificadas por el mismo triple con que se escribieron: bAcumulado==1 + iPromocion + cEan + Articulo + iNroTicket. Remove() invalida el cursor, por eso el barrido se reinicia despues de cada baja.
2. Deshace el recomputo de percepcion con RecomputePercepcionxPromoMdeP(2, ...), que es exactamente lo que hace TICKET::PromocionesMdeP_DeleteMdeP para una promo por medio de pago clasica (pos_prom.cpp:2810).
3. Limpia los acumuladores del beneficio.

Los totales no se tocan ahi: DeleteLastMDEP ya los devuelve a los valores previos al QR.

Saldo'       = 0 + (G-D) - (-D) = G      (vuelve a deber el bruto)
TotRecDesc'  = TotRecDesc + D   = 0
TotalNeto'   = TotalInicial + 0 = G
TotalCobrar' = G

No se revierte dataRedondeos (lo prorratea PagoQR_ProrratearDataRedondeos, pos_mppo.cpp:3588). Es un no-op sin impresora fiscal, porque CalcularRedondeos() solo lo llena con profile.iAjustaRedondeFiscal && HayImpresoraFiscal. Con impresora fiscal real es un pendiente.

6.5 Que ve y que hace el cajero

1. Presiona la tecla de borrar medio de pago sobre la fila PAGO QR.
2. Ve el mensaje PAGO QR autorizado: anule via Reversa QR y la fila queda.
3. Si tiene que deshacer la operacion, usa la Reversa QR: menu Admin/Tarjetas, tecla kbANULACION_PAGOQR (pos_cara.cpp:1195).
4. Si no, simplemente cierra el ticket con TOTAL: el pago QR ya esta hecho y el ticket cierra por el importe cobrado.

Limites de la Reversa QR que hay que conocer antes de instruir al cajero:

• es total, no parcial;
• alcanza solo la ultima operacion, porque el id sale del perfil 500, que se limpia en cada COBRO() y en cada StartTicket;
• no limpia vData de la fila de dE_DMdeP, asi que despues de una reversa exitosa la guarda sigue bloqueando el borrado del medio de pago.

6.6 Decisiones abiertas

7. Archivos fuente a integrar

7.1 Nota sobre el .mak

postcpnu.mak lleva una macro nueva, declarada en Translator Definitions antes de la definicion de CC:

!ifdef QRSIM_TEST
QRSIM_DEFINE = -DQRSIM_TEST
!else
QRSIM_DEFINE =
!endif
CC = bcc286 -crtdll +postcpnu.cfg $(QRSIM_DEFINE)

Trampa de make a tener presente al integrar: Borland MAKE decide recompilar por fecha de archivo, no por flags. Al alternar configuraciones de build sin tocar los .cpp, los .obj quedan "al dia" con la configuracion anterior y el link produce un binario que no corresponde. Hay que borrar a mano los .obj afectados (pos_main.obj, pos_mppo.obj, pos_vnta.obj, pos_tic2.obj, pos_misc.obj) o tocar los .cpp para adelantar su fecha.

7.2 Presupuesto de segmentos

8. Resultados de validacion

Corridas end-to-end sobre una copia real de bases, Z 20260903. G = bruto de catalogo, D = beneficio, "neto persistido" = dE_TResu.fPrecioTotal.

Controles verificados en cada corrida: total persistido == cobrado; IVA por tasa == ROUND(neto * tasa); fila de dE_DDMP con dImporte y dRecDesc correctos y fRecDescMPP == 0; suma de items de dB_TDeta == bruto de catalogo; suma de las filas del beneficio == -D; una fila por tasa presente y ninguna de mas; los cuatro campos de identidad de la fila iguales a los perfiles; suma del detalle == fPrecioTotal; ticket impreso y QR fiscal coherentes; sin rechazos ni lineas de log inesperadas.

Casos destacados. Percepcion + QR: los buckets de venta dan 1930.69 + 405.44 + 138.87 = 2475.00, identicos al split sin percepcion; la percepcion queda en 57.92 y fPrecioTotal 2532.92 == dE_DDMP.dImporte. Promo por medio de pago + QR: la promo dispara antes (-82.50), el beneficio se aplica sobre la base ya descontada (2750.00 - 82.50 - 266.75 = 2400.75) y el ticket impreso cierra exactamente.

8.1 Lo que NO esta cubierto

9. Bugs encontrados y corregidos durante el desarrollo