Percepciones con el beneficio QR post-pago

1. Resumen y regla

Las percepciones (IIBB, Convenio/ComInd e IVA) sólo aplican cuando el neto del ticket supera un mínimo configurado. Con el beneficio de billetera QR post-pago, la billetera ya cobró el total incluida la percepción: el descuento D se calcula sobre el total con percepción y importe_final = total − D. Si el descuento dejaba el neto por debajo del mínimo, el recómputo anulaba la percepción y el ticket persistía menos de lo efectivamente cobrado.

2. Diagramas

2.1 ¿Se computa o no la percepción?

Cada evento que toca la percepción entra por un camino distinto. Las columnas 1 a 3 ocurren antes de cobrar y evalúan el mínimo; la columna 4 (el cambio de este trabajo) ocurre después de cobrar y sólo reescala; la columna 5 deshace el último recómputo.

2.2 Secuencia del beneficio QR post-pago (números de M4m)

2.3 Camino × qué pasa con el mínimo

"Guarda" = PromoCalculatePercepcion y PagoQR_ImputarDescuento sólo entran si VALIDAR(Ticket.Percepcion). El recargo/descuento de tarjeta clásico no llama a RecomputePercepcionxPromoMdeP (IMPL_NOTES y búsqueda en el árbol); la percepción queda como la calculó la entrada a cobro. Si un recargo se configura como promo x MdeP, sigue el camino del modo 1.

3. Detalle técnico

3.1 Modo 3 en RecomputePercepcionxPromoMdeP (verbatim)

Tres fragmentos de pos_tic2.cpp, tal como están en el árbol. Las líneas resaltadas llevan el marcador //20260922 QRDTO percepcion minimo o son el código que agrega.

pos_tic2.cpp:1826-1846 — comentario de la función, firma y normalización

1826//---------------------------------------------------------------------------
1827//UpdatePercepcion: 0=consulta, 1=actualiza, 2=revierte la ultima (RecoverLast),
1828//3=actualiza ignorando los minimos para las percepciones que el ticket YA tenia.
1829//20260922 QRDTO percepcion minimo
1830//El modo 3 existe para el beneficio QR post-pago (PagoQR_ImputarDescuento).
1831//Ahi la billetera YA cobro el total INCLUIDA la percepcion (D se calculo sobre
1832//el total con percepcion, importe_final = total - D). Si el descuento deja el
1833//neto por debajo del minimo (profile 272 / dPercepcionComIndMontoMin /
1834//dPERCIVA_MONTOMIN) el modo 1 anula la percepcion y el ticket persiste menos
1835//de lo cobrado. En el modo 3 una percepcion preexistente solo se reescala por
1836//el ratio y nunca se anula por minimo; una percepcion que el ticket NO tenia
1837//sigue sujeta al minimo (nunca se inventa una). Las promos x MdeP clasicas
1838//siguen en modo 1: son descuentos previos al cobro y ahi re-evaluar el minimo
1839//es correcto. El historial de percepcionPromoArray es identico al del modo 1,
1840//asi que la reversion (modo 2) no cambia.
1841int POS_EXPORT RecomputePercepcionxPromoMdeP(int UpdatePercepcion, double dRecDescPromo, double& dRecDescPorPercep)
1842{
1843int iIgnorarMinimo=(UpdatePercepcion==3);	//20260922 QRDTO percepcion minimo
1844if(iIgnorarMinimo)
1845	UpdatePercepcion=1;
1846double dACobrar=UpdatePercepcion==2 ? Ticket.TotalInicial:Ticket.TotalCobrar;	

pos_tic2.cpp:1869-1874 — mínimo 0 sólo para IIBB/ComInd preexistentes

1869//20260922 QRDTO percepcion minimo: en modo 3 el minimo es 0 solo si la
1870//percepcion ya existia en el ticket.
1871double dMinIIBB= (iIgnorarMinimo && VALIDAR(dMontoYaExistePercepcionIIBB)) ? 0.0L : profile.dMinimoPercepciones;
1872double dMinCOMIND= (iIgnorarMinimo && VALIDAR(dMontoYaExistePercepcionCOMIND)) ? 0.0L : profile.dPercepcionComIndMontoMin;
1873PercepcionesElement peIIBB(UpdatePercepcion, eptype_IIBB,profile.iUsaPercepciones, dMinIIBB, profile.dPorcentajePercepciones, dMontoYaExistePercepcionIIBB, dCurrentNetoTicketReal,dRatio);	
1874PercepcionesElement peCOMIND(UpdatePercepcion, eptype_COMIND,profile.iPercepcionComIndUsa, dMinCOMIND, profile.dPorcPercepcionComInd,dMontoYaExistePercepcionCOMIND, dCurrentNetoTicketReal,dRatio);

pos_tic2.cpp:1880-1892 — PIVA: no se anula el par que ya existía

1880//Ahora vamos el tema de PIVA, ya que para que se aplique la suma de piva21 y piva105 tiene que ser mayor que el minimo!
1881pePIVA21.dNewValue= (pePIVA21.dNewNeto*pePIVA21.dPercentage)/100L;
1882ROUND_DOUBLE(pePIVA21.dNewValue);
1883pePIVA105.dNewValue= (pePIVA105.dNewNeto*pePIVA105.dPercentage)/100L;
1884ROUND_DOUBLE(pePIVA105.dNewValue);
1885//20260922 QRDTO percepcion minimo: en modo 3 no se anula la PIVA que ya existia.
1886if(	(pePIVA21.dNewValue+pePIVA105.dNewValue)<profile.dPERCIVA_MONTOMIN
1887	&& !(iIgnorarMinimo && VALIDAR(dMontoYaExistePPIVA21+dMontoYaExistePPIVA105))){
1888	pePIVA21.dNewValue=0L;
1889	pePIVA105.dNewValue=0L;
1890	}
1891pePIVA21.Compute();
1892pePIVA105.Compute();

• Se normaliza a 1 antes de calcular dACobrar: base TotalCobrar, asignaciones a ETres, historial percepcionPromoArray.Add, Ticket.Percepcion y Ticket.NetoTicketReal son exactamente los del modo 1. La reversión (modo 2, RecoverLast) no cambia.
• PercepcionesElement no se tocó: con mínimo 0.0 la condición dNewNeto > 0.009 reescala y sólo da 0 si el neto llega a 0 (beneficio del 100%).
• "Ya existía" se lee por tipo desde dE_TResu con UtilizaPercepcion (pos_taxs.cpp:1736): fTax1, fMontoPercepcionCI, fMontoPercepcionIVA21/105.

3.2 Llamada en PagoQR_ImputarDescuento (verbatim)

pos_mppo.cpp:3651 y 3662-3683 — ratio, filas QR, recómputo de percepción (modo 3) y prorrateo

3651double dRatio= dD/dTotalAntes;		//ratio global unico: buckets y percepciones

3662if((tick!=NULL) && tick)
3663	tick->PagoQR_AppendFilasDescuento(dTotalAntes, dRatio, trx.mediodepago);
3664
3665//OJO ORDEN: esta llamada va ANTES del recomputo de percepcion.
3666//PagoQR_AppendFilasDescuento lee Ticket.Percepcion para descontar del lado
3667//VENTA solo (TotalCobrar - Percepcion)*r, y RecomputePercepcionxPromoMdeP
3668//reescribe Ticket.Percepcion en el lugar. Al reves, el monto de las filas
3669//sale calculado sobre la percepcion YA reducida y el ticket queda corto
3670//(visto en vivo en M4: 275.65 en vez de 275.00, 0.65 de menos).
3671//Percepciones: se alimenta con -r*NetoSinPercepcion para que el ratio interno
3672//de RecomputePercepcionxPromoMdeP reproduzca exactamente r. Ademas deja el
3673//historial en percepcionPromoArray para una futura reversion.
3674if(POSConPercepcionesHabilitadas() && VALIDAR(Ticket.Percepcion)){
3675	double dRecDescPorPercep=0.0L;
3676	double dNetoSinPercepcion= dTotalAntes - Ticket.Percepcion;
3677	//20260922 QRDTO percepcion minimo: modo 3 = la billetera ya cobro la
3678	//percepcion, asi que no se re-evalua el minimo para la que ya existia
3679	//(ver el comentario de RecomputePercepcionxPromoMdeP en pos_tic2.cpp).
3680	RecomputePercepcionxPromoMdeP(3, -1.0L*dRatio*dNetoSinPercepcion, dRecDescPorPercep);
3681	}
3682
3683PagoQR_ProrratearDataRedondeos(dRatio);

Orden efectivo: ratio r (3651) → PagoQR_AppendFilasDescuento (3663, lee Ticket.Percepcion) → recómputo modo 3 (3680, reescribe Ticket.Percepcion) → PagoQR_ProrratearDataRedondeos (3683) → ViewSaldo(-D) (3695). El cálculo inicial al entrar al cobro no se tocó y sigue aplicando el mínimo:

pos_mppo.cpp:4922-4934 — bootstrap al entrar al cobro (sin cambios)

4922Ticket.Percepcion=Ticket.NetoConPIVA21=Ticket.NetoConPIVA105=Ticket.NetoTicketReal=0L;
4923if(profile.iCAEA_Habilitado && EsFacturaTipo2_3(Fact.TipoFacturacion)){
4924	ComputarPercepcionExistente(Ticket.Percepcion, Ticket.NetoTicketReal,Ticket.NetoConPIVA21,Ticket.NetoConPIVA105, 1);	//1=solo netopor las dudas no tenga percepciones!
4925	}
4926if(POSConPercepcionesHabilitadas()){
4927	ComputarPercepcionExistente(Ticket.Percepcion, Ticket.NetoTicketReal,Ticket.NetoConPIVA21,Ticket.NetoConPIVA105,0);	//0=fullmode
4928	if(VALIDAR(Ticket.Percepcion)){
4929		Ticket.TotRecDesc+=Ticket.Percepcion;
4930		Ticket.Saldo= Ticket.Saldo + Ticket.Percepcion;	DIG_SIG( Ticket.Saldo);
4931		Ticket.SaldoBack= Ticket.Saldo ;
4932		Ticket.TotalNeto=Ticket.Saldo;
4933		ViewSaldo();
4934		}

3.3 Llamadores de RecomputePercepcionxPromoMdeP y sus modos

Búsqueda sobre todo el árbol: cinco llamadas efectivas (dos pasan por PromoCalculatePercepcion, cuya llamada real está en pos_tic2.cpp:1929). Declaración en pos_func.h:311, sin cambios de firma.

PromoCalculatePercepcion sólo recibe 0 o 1 (pos_prom.cpp:2656 y :4755), así que ningún camino clásico puede llegar al modo 3 por accidente.

3.4 Regla de PercepcionesElement::Compute y regla PIVA

1736	void POS_EXPORT Compute()
1737	{
1738	if(!iIsEnabled)
1739		return;
1740	//cuanta percepcion da ahora, si da 0, ojo ver si antes tenia, hay que considerar!
1741	//lo que de, comparar con el valor previo!
1742
1743	//lo de PIVA no se puede hacer individual!!!
1744	if(	(eptype==eptype_IIBB)||(eptype==eptype_COMIND)){
1745		if((dNewNeto-dMinimunValueToBeComputed)>0.009L){
1746			dNewValue=((dNewNeto*dPercentage)/100L);
1747			ROUND_DOUBLE(dNewValue);
1748			}
1749		else if(VALIDAR(dPreviousValue)){
1750			dNewValue=0L;//no aplica mas, entonces tenemos que saber que el valor completo previo hay que considerarlo como variacion.
1751			}
1752	}
1753		
1754	if(iUpdatePercepcion){
1755		switch(eptype){
1756			case eptype_IIBB:

pos_taxs.cpp:2228-2240 — bootstrap IIBB / ComInd (sin cambios)

2228if(profile.iUsaPercepciones && iTienePercepcionIIBB){
2229	if((dMontoPCalculo - profile.dMinimoPercepciones)>0.009L){
2230		dPercIIBB= (dMontoPCalculo * profile.dPorcentajePercepciones) / 100L;
2231		ROUND_DOUBLE(dPercIIBB);
2232		}
2233	}
2234	
2235if(profile.iPercepcionComIndUsa && iTienePercepcionCOMIND){
2236	if((dMontoNeto - profile.dPercepcionComIndMontoMin)>0.009L){
2237		dPercCI= (dMontoNeto * profile.dPorcPercepcionComInd) / 100L;
2238		ROUND_DOUBLE(dPercCI);
2239		}
2240	}

3.5 Por qué el modo 3 es un parámetro y no una variable global

• Sin estado que se filtre. La función tiene varios return 0L tempranos (dRecDescPromo o neto nulos, UtilizaPercepcion en 0, modo 2). Un flag global fijado por el llamador tendría que limpiarse en todos esos caminos; si quedara encendido, la siguiente promo clásica ignoraría el mínimo en silencio.
• Explícito en el sitio de llamada. El modo se ve en la única línea que lo usa (pos_mppo.cpp:3680) y la tabla de llamadores se obtiene con un grep. PromoCalculatePercepcion sólo pasa 0/1, lo que acota el modo 3 a un solo camino.
• Firma exportada intacta. El parámetro int UpdatePercepcion ya existía; pos_func.h:311 no cambia y ningún módulo que la importa necesita recompilarse por la firma.
• Sin datos nuevos en DGROUP. DGROUP tiene 158 bytes libres; el cambio no agrega variables estáticas ni literales (DGROUP sin cambio en TEST y producción).
• Mínimo impacto en POS_MPPO_TEXT. En pos_mppo.cpp el cambio es un carácter (1 → 3) más comentario: ese segmento está a 97 bytes del límite en TEST y el linker no avisa si envuelve. Toda la lógica nueva vive en pos_tic2.cpp (≈ 29.8 KB libres).

4. Evidencia

Build de TEST (-DQRSIM_TEST), matriz de paranoia, Z 20260903. Percepción IIBB forzada al 3% (SETPROF 273 3 + QRSIMPER.TXT) y perfil 272 variando; DM_PROFI.DAT respaldado antes de escribir y readback después de cada SETPROF. Estado final: 272 = 1000, 273 = 0, promo 290000 iCliLoyalty = 3, marcadores QRSIM*.TXT borrados. D = beneficio de la billetera; "antes → después" = percepción IIBB al momento del pago QR y al cierre.

Buckets persistidos (dE_TResu) de M4m: 21% 1930.69 + 405.44 · II 138.87 · perc IIBB 57.92; fPrecioTotal 2532.92 == dE_DDMP.dImporte 2532.92. M5m: 21% 2080.85 + 436.99 · II 149.66 · perc 0.00; fRecDescMPP −146.86 = promo −82.50 + percepción anulada −64.36 (preexistente). M5m y M5mq usan mínimo 2100 porque la promo del 3% deja el neto en 2080.85, que no cruza 2000.

Invariantes nuevas o ajustadas (assert_dump.py)

Re-evaluadas contra la evidencia guardada de M1/M2/M3/M4/M4c/M7/M8/M9a/M9b/M10/MFA/MD0: todas siguen en PASS.

5. F19: línea Rec/Desc duplicada en promos clásicas (encontrado y corregido)

Encontrado por M5m (ticket 67, 22/09): con la promo clásica 290000 pagada con EFECTIVO el ticket imprimía el descuento dos veces y no cerraba a la vista.

SUBTOTAL:                        2750.00
Rec/Desc EFECTIVO              -146.86
00000000  Desc. Esp. 3#     -82.50
TOTAL :                          2667.50

SUBTOTAL:                        2750.00
00000000  Desc. Esp. 3#     -82.50
TOTAL :                          2667.50

Causa. PrintRecDescMdeP (pos_vnta.cpp:4244, //20260903 QRSIM, código productivo) revivió la rama SF_Status==3 de TIC_VDET.SCP para cualquier medio con dRecDesc ≠ 0; sólo la fila del PAGO QR se reemplazaba por la suma de sus filas. Antes de esa función la rama estaba muerta, así que es una regresión de impresión del trabajo QRDTO. M5 original no la vio porque su promo iba sobre PAGO QR.

Corrección (//20260922 F19): la línea Rec/Desc <medio> se imprime sólo para PAGO QR. Una promo x MdeP clásica ya imprime su propio renglón Desc. Esp. ….

pos_vnta.cpp:4258-4280 (verbatim)

4258do{
4259	double dRD=0.0L;
4260	sfield(mbase, str_dRecDesc, dRD);
4261	if(!VALIDAR(dRD))
4262		continue;
4263	char cDes[24];memset(cDes,0,sizeof(cDes));
4264	mbase->field(strcDescripcion, cDes);
4265	double dPrint=dRD;			//20260917 QRDTO impresion neto
4266	int _uId=0, _uIdId=0;
4267	sfield(mbase, str_uId,   _uId);
4268	sfield(mbase, str_uIdId, _uIdId);
4269	//20260922 F19: solo el PAGO QR imprime esta linea. Una promo x MdeP clasica
4270	//deja su monto (+delta de percepcion) en dRecDesc del medio con que se pago
4271	//(p.ej. EFECTIVO) y ya se imprime como linea de promo: imprimirla aca la
4272	//duplicaba. Antes del 20260903 esta rama del script no la llamaba nadie.
4273	if(!EsPagoQR(_uId, _uIdId))
4274		continue;
4275	{
4276	double dQR= tick->PagoQR_SumaFilasDescuento(
4277					EsFacturaTipo2_3(Fact.TipoFacturacion) ? 1 : 0);
4278	if(VALIDAR(dQR))
4279		dPrint=dQR;
4280	}

Re-verificación en vivo del 23/09/2026

Sobre el binario TEST reconstruido el 22/09 (pos_vnta.obj/.exe más nuevos que pos_vnta.cpp, verificado por fecha). Perfiles con readback antes y después; revertidos al final (SETPROF 272 1000, SETPROF 273 0, SETPRCLI 290000 0 3).

I12 se corrió contra toda la evidencia existente: las únicas fallas aparecen en evidencia histórica ya marcada como FAIL por otros motivos (MD1, por F14; y un dump de limpieza mal rotulado M5promo que corresponde a una corrida de MCLEAN). Efecto colateral buscado: un recargo/descuento clásico en un medio no QR vuelve a no imprimir esa línea, como antes del 03/09. El camino fiscal no cambia (la función sale antes con impresora fiscal).

6. Archivos entregados

Los tres archivos de C:\tmp\20260914\pos\real\ son byte a byte idénticos a los de C:\Work\AI\DINO_20260902 (comparados con cmp el 23/09). El marcador 20260922 no aparece en ningún otro fuente del árbol. Sin cambios de perfiles de producción, DDF, .SCP ni scripts; los perfiles 272/273 y la promo 290000 sólo se modificaron en las bases de prueba y quedaron revertidos.

Segmentos (POS_MAIN.MAP)

La columna de producción sale de C:\Work\AI\DINO_20260902\POS_MAIN.MAP (23/09 09:16, después de cerrarse la ventana "DINO BUILD"); el POS_MAIN.EXE de ese build no contiene la cadena QRSIM. POS_MPPO_TEXT queda a 97 bytes del límite en TEST: revisar el MAP después de cualquier cambio en pos_mppo.cpp.

7. Pendiente: revisión general de percepciones

7.1 Puntos de la cadena a auditar

7.2 Método propuesto

1. Inventario de sólo lectura de los nueve puntos: quién escribe y quién lee cada magnitud (Ticket.Percepcion, dE_TResu, filas sintéticas, payload CAE).
2. Fuente única de verdad: proponer dE_TResu + filas sintéticas como origen, con invariantes Σ persistido == dE_DDMP == total CAE y importeTributo == Σ filas de percepción == fTax1 + CI + PIVA21 + PIVA105.
3. Extender el arnés: capturar el XML del CAE en TEST y agregar una invariante de igualdad con lo cobrado.
4. Matriz nueva: Factura A y B; cliente con base por precio; PIVA; ComInd; recargo que cruza el mínimo; NC total y parcial de un ticket QR con percepción.
5. Decisiones para el product owner: mínimo 0 en IIBB, recargos que cruzan el mínimo, base de cálculo por precio y NC de tickets con beneficio.

Fuera de alcance del trabajo del 22-23/09: todo lo de esta sección.

8. Notas de trazabilidad (documentos frente a código)

• Cambios_POS_Descuento_QR.html §5.5 todavía muestra RecomputePercepcionxPromoMdeP(1, …); el código actual es (3, …) (pos_mppo.cpp:3680). La §10.4 del mismo documento sí refleja el modo 3.
• F19 se cita como pos_vnta.cpp:4269: esa línea es el comentario; la sentencia if(!EsPagoQR(_uId, _uIdId)) está en :4273.
• MATRIX_RESULTS.md ("Estado final") llama al perfil 272 PERCEPCION_MONTOMIN y al 273 PERCEPCION_TASA; en pos_prof.h:299-300 son pro_MONTOMINIMOPERCEPCIONES y pro_PORCENTAJEPERCEPCIONES.
• El recargo/descuento de tarjeta clásico no re-evalúa el mínimo: no llama al recómputo (sección 2.3).
• IMPL_NOTES.md deja "números de producción pendientes" para F19; la sección 6 los completa desde el MAP de producción del 23/09 (POS_VNTA_TEXT E286H, +3 bytes).
• El resto de números y referencias de archivo:línea de este documento se verificaron contra el código del 22/09 (DINO_20260902).