9. Promociones y descuentos

Cubre promotions (reglas automáticas/semiautomáticas) y discount_policies (límites de descuento manual por rol/categoría/producto).

Historial de ejecución

Promociones

CP PROMO-01: Promoción percentage, applies_to="all"

• Resultado esperado: aplica el porcentaje sobre toda la venta.
• Resultado obtenido: Pendiente.

CP PROMO-02: Promoción fixed, applies_to="product" con product_ids específicos

• Resultado esperado: descuenta el valor fijo solo cuando el carrito incluye alguno de esos productos.
• Resultado obtenido: Pendiente.

CP PROMO-03: Promoción applies_to="category" con category_ids

• Resultado esperado: aplica a cualquier producto de esas categorías, sin necesidad de listarlos uno por uno.
• Resultado obtenido: Pendiente.

CP PROMO-04: Promoción tipo bogo (“compre 1 lleve 1”)

• Pasos: agregar 2 unidades del producto promocionado.
• Resultado esperado: la segunda unidad queda gratis o con el descuento correspondiente — confirmar la fórmula exacta aplicada.
• Resultado obtenido: Pendiente.

CP PROMO-05: Promoción tipo buy_x_get_y con buy_qty=3, get_qty=1

• Pasos: agregar exactamente 3 unidades (no debería activarse aún), luego 4 (sí debería).
• Resultado esperado: la promoción solo se activa al alcanzar el umbral buy_qty + get_qty; verificar el límite exacto (¿con 3 ya da 1 gratis, o necesita las 4?).
• Resultado obtenido: Pendiente.

CP PROMO-06: Promoción con days_of_week/start_time/end_time fuera del horario actual

• Pasos: crear promoción válida solo “Lunes a Viernes, 12:00–14:00” y probarla en otro horario.
• Resultado esperado: no debe aplicarse fuera de esa ventana; confirmar también que sí se activa automáticamente al llegar la hora correcta sin necesidad de editar nada.
• Resultado obtenido: Pendiente.

CP PROMO-07: Promoción con start_date/end_date ya vencidos

• Resultado esperado: no debe aparecer como aplicable ni en el listado de promociones activas del POS.
• Resultado obtenido: Pendiente.

CP PROMO-08: Dos promociones is_auto_apply=true aplicables al mismo carrito, distinta priority

• Resultado esperado: solo se aplica la de mayor prioridad (ver también VTA-10) — confirmar si el POS informa visualmente al cajero que había otra promoción disponible pero no se aplicó por prioridad (si no lo hace, es una oportunidad de mejora de transparencia).
• Resultado obtenido: Pendiente.

CP PROMO-09: Crear promoción con type="percentage" y value mayor a 100

• Objetivo: no hay binding:"max=100" en Value del DTO de promociones (a diferencia de discount_policies, que sí limita a 100) — confirmar si acepta, por ejemplo, value: 150 y qué pasa al aplicarla (¿deja el precio en negativo?).
• Resultado obtenido: Pendiente.

CP PROMO-10: applies_to="product" sin especificar product_ids

• Resultado esperado a verificar: combinación contradictoria — confirmar si el backend la rechaza o la crea sin que nunca llegue a aplicarse a nada (promoción “fantasma”).
• Resultado obtenido: Pendiente.

Políticas de descuento manual

CP DESC-01: Política scope="role" con max_discount_pct=10 para el rol “Cajero”

• Resultado esperado: el cajero no debe poder aplicar más de 10% de descuento manual en una venta (ver también VTA-08).
• Resultado obtenido: Pendiente.

CP DESC-02: Política con allow_full_comp=true (permite cortesía/100% de descuento) para el rol “Supervisor”

• Resultado esperado: ese rol específico sí puede dejar una línea o venta en $0, aunque max_discount_pct sea menor a 100.
• Resultado obtenido: Pendiente.

CP DESC-03: Dos políticas aplicables al mismo caso (ej. una por role y otra por category para el mismo producto)

• Resultado esperado a verificar: confirmar cuál gana — ¿la más restrictiva, la más específica, o hay un orden de prioridad documentado en el código que valga la pena anotar aquí para referencia futura?
• Resultado obtenido: Pendiente.

CP DESC-04: Rol sin ninguna política de descuento asignada

• Resultado esperado a verificar: ¿el comportamiento por defecto es “no puede descontar nada” o “puede descontar libremente”? Confirmar cuál es, porque el impacto de negocio es opuesto según la respuesta.
• Resultado obtenido: Pendiente.

Notas de usabilidad y sugerencias

Se completa durante la ejecución.