base_amount — beneficio sobre un monto base acumulado
1. La idea en una frase
Hoy el beneficio se calcula como un % del total del ticket. La idea es calcularlo sobre un monto base (base_amount) que define el negocio vía promociones, no sobre el total. El cliente paga lo mismo menos el descuento; cambia sobre qué se calcula ese descuento.
2. Por qué
- Promos dirigidas: permite premiar categorías/productos puntuales sin descontar todo el ticket.
- El negocio decide el alcance desde la configuración de promociones del POS, sin tocar código.
- Retrocompatible por defecto: sin
base_amount, el beneficio se calcula sobre el total — el comportamiento actual no cambia.
Opciones de comportamiento que proponemos (detalle en §5):
- Sin
base_amount(ausente) → beneficio sobre el total del ticket. Es el comportamiento de hoy. - Con
base_amount(> 0) → beneficio sobre esa base (los ítems de la promo).
3. Cómo funciona, de punta a punta
Cinco actores, cada uno con un rol claro:
| Actor | Rol en base_amount |
|---|---|
| POS | Calcula el monto base acumulando las promociones que correspondan y lo envía. Nunca aplica el descuento él mismo. |
| RouterQR | Relaya el dato (transparente). |
| GatewayQR | Lleva base_amount al resolvedor y se lo informa al autorizador. |
| BeneficiosCenter | Calcula el beneficio: % sobre el monto base (con tope y mínimo), sin cambiar el total. |
| TECSO (autorizador) | Aplica el descuento y lo confirma; el POS lo imputa y reparte el IVA. |
4. El dato nuevo: base_amount
- Qué es: el monto (en pesos) sobre el que se calcula el beneficio. Lo produce el POS.
- De dónde sale: de promociones que el POS computa pero nunca cobra — suman un acumulado que viaja como
base_amount. (El detalle de configuración está en el doc técnico.) - Cómo viaja: POS → RouterQR → GatewayQR → BeneficiosCenter; y al autorizador dentro del descuento.
- Si no viene: el beneficio se calcula sobre el total, como hoy.
5. Reglas que importan
| Regla | Qué significa |
|---|---|
| Cálculo | descuento = mín( base × % , tope ). |
| Tope por el monto QR | El monto base nunca supera lo que se paga por QR → el descuento nunca deja el pago en negativo. |
| Monto mínimo | El mínimo del beneficio se evalúa contra el monto base (no contra el total). |
| Default (ausente) | Sin base_amount → se usa el total (comportamiento actual). Pensado para promos clásicas sobre todo el ticket. |
| Un beneficio por medio de pago | Nunca se suman beneficios; se elige uno (sin cambios respecto de hoy). |
| El total no cambia | El descuento se resta de lo que se cobra; el ticket sigue valiendo lo mismo. |
6. La vuelta: descuento e IVA
El autorizador confirma el descuento aplicado. El POS lo recibe e imputa el descuento repartiéndolo sobre todo el ticket (de forma proporcional por alícuota de IVA), de modo que lo informado al fisco cierra contra lo cobrado. El cálculo del beneficio usa el monto base; el reparte fiscal es sobre el ticket completo — son dos cosas distintas y así queda validado.
7. Estado y alcance
base_amount; falta el E2E real y el build de prod.Todo este cambio se desarrolla aparte del release en QA; no afecta lo que ya está en producción. El formato del campo quedó confirmado entre POS y server. Falta la prueba de punta a punta con el POS real (build de prod).
docs/base-amount-circuito-completo.html. El contrato con el autorizador, en docs/Beneficios-contrato-autorizador.html.