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.
En la intención de pago (GatewayQR → Autorizador DINI/TECSO), base_amount viaja anidado dentro de discount, en cada entrada de benefits_methods_data. Ya viene calculado: el descuento está resuelto en discount.amount; el autorizador no recalcula — descuenta amount y devuelve discounted_amount.
{
// total del ticket = tope de base_amount
"original_amount": 100000.00,
"benefits_methods_data": [
{
"benefits_card": { "code": "990", "description": "Jueves Dini Negocios 10%" },
"discount": {
"percentage": 10.00,
"maximum_discount_amount": 15000.00,
"base_amount": 30000.00, // NUEVO: base de cálculo (del POS)
"amount": 3000.00, // = mín(base_amount × %/100, tope)
"type": "DISCOUNT"
}
}
]
}
Respuesta del autorizador (eco): benefits_data.base_amount. Si el POS no envía base_amount, vale el total (original_amount) → comportamiento histórico. Contrato completo (request + respuesta + reglas de cálculo) en docs/Beneficios-contrato-autorizador.html.
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.
docs/base-amount-circuito-completo.html. El contrato con el autorizador, en docs/Beneficios-contrato-autorizador.html.