Fix recargo/descuento en pago parcial

00Resumen

Cuando el cliente paga una parte del ticket con un medio de pago que tiene recargo o descuento porcentual (ej. VISA/CORDOBESA), el sistema calculaba mal el porcentaje y el total cobrado (DDMP) no coincidía con el total fiscal del ticket (Tresu/Tdeta). Eso generaba el descuadre de las ~45 zetas de agosto/septiembre. El fix corrige el cálculo en 3 puntos encadenados de la misma función y quedó validado corriendo el POS real.

01El problema — por qué el bruto rompe el cálculo

El recargo/descuento es un porcentaje. Aplicar el % sobre un bruto que ya lo contiene da un valor inflado. Ejemplo con recargo del 10% y un bruto de 100000 que el cajero pone en la tarjeta:

recargo = bruto × p/100
        = 100000 × 10/100
        = 10000   (inflado)

base    = bruto / (1 + p/100)
        = 100000 / 1.10 = 90909.09
recargo = base × p/100
        = 9090.91   (correcto)

El segundo golpe: eproCons

Aunque se corrigiera el cálculo, más abajo en la misma función eproCons.getPromoySugerido() volvía a pisar el valor con la fórmula vieja (×/100). Por eso el fix necesita, además, neutralizar ese override para el caso del parcial. Este punto es el que solo se ve corriendo el código (no compilando) — el binario del laboratorio simplificado no tenía eproCons y por eso al principio "daba bien" y en producción no.

02Antes → Después (código)

// una sola linea, sin distinguir bruto
_dTmpMontoPromocion =
   (dMontoAPromo * Porcentaje) / 100L;

// ... mas abajo:
if(!eproCons.getPromoySugerido(...)){
   _dTmpMontoPromocion = dPromo; // re-pisa
}

// guarda del caso (conservadora)
int iParcialBrutoPorcentaje =
  (iPromoIngresoMdeP==1) && !iIngresoLoSugerido
  && (Porcentaje>-100) && (Action==MA_PORCENTAJE)
  && !VALIDAR(Ticket.Percepcion)
  && eproCons.isSinglePromo(IdPromo);

// extraccion de base + topeo
if(iParcialBrutoPorcentaje){
  base = dMontoIngresado/(1.0+Porcentaje/100.0);
  if(base>dMontoDisponibleParaPromo) base=...;
  if(base>dTotalDelTicket) base=...;
  _dTmpMontoPromocion = (base*Porcentaje)/100L;
}

// fiscal alineado (Tresu = DDMP)
// eproCons NO pisa si iParcialBrutoPorcentaje

03Comparación numérica — antes vs después

Bruto de 100000 a la tarjeta, resto en EFECTIVO. Base del ticket = 183000 (caso de laboratorio validado).

Recargo 10%

Descuento 14%

04Diagrama de flujo (bug vs fix)

05Los 5 ajustes en pos_prom.cpp

• 1. eproCons::isSinglePromo() — método nuevo: confirma que hay una sola promo cacheada (evita mezclar bases con multi-promo).
• 2. Guarda iParcialBrutoPorcentaje — conservadora: solo modo 1, promo porcentual (MA_PORCENTAJE), sin percepción, promo única, %>-100 (evita división por cero), y el cajero tipeó el monto.
• 3. Extracción + topeo — base = bruto/(1+p/100), topeada a lo disponible y al total del ticket, luego recargo = base×p/100.
• 4. Alineación fiscal — iguala el recargo fiscal (que arma Tresu) al recargo real del mdep y reescala los acumuladores por tasa → Tresu = DDMP.
• 5. Neutralización de eproCons — se saltea el override para que el valor extraído sobreviva al total.

06Validación

Corrido con el árbol de producción completo (con eproCons) compilado en el entorno DOSBox del kit, con las bases Btrieve reales:

DIAG FIX == DIAG FINAL confirma que eproCons ya no pisa. Parc=1 confirma que la guarda conservadora dispara en los casos reales. CAE OK.

07Alcance y pendiente

Tradeoff conservador: casos con percepción, multi-promo o promo no-porcentual quedan en el camino original (el bug reportado no es de esos: consumidor final, % único, sin percepción). Ampliable si aparecen.

• Rollout: copiar srcs/pos_prom.cpp → .releases/20260728/CYRE/ → CO.BAT → cajas.
• Problema #2 (separado): impresión entrecortada en comanderas Kretz — sin tocar.

PCPOS CYRE · fix recargo/descuento en pago parcial · pos_prom.cpp · generado 16/09/2026