5. Ventas (POS)

Cubre sales, sale_items, payments, el flujo de órdenes en espera + KDS (kitchen_status), return_orders, el uso de gift_cards como método de pago, promociones/descuentos aplicados en el carrito, y el pedido público por carta online (menu).

Historial de ejecución

Venta simple

CP VTA-01: Venta de un solo producto, pago en efectivo exacto

• Resultado esperado: change=0, status="paid", descuenta inventario del producto vendido.
• Resultado obtenido: Pendiente.

CP VTA-02: Venta con pago en efectivo mayor al total (calcular vuelto)

• Pasos: total $23.500, pago con $25.000.
• Resultado esperado: change=1.500 calculado y mostrado correctamente en el recibo.
• Resultado obtenido: Pendiente.

CP VTA-03: Venta con paid_amount menor al total (venta a crédito/pendiente)

• Resultado esperado: debe poder guardarse con status distinto de "paid" (ej. "outstanding"), y aparecer como pendiente en reportes.
• Resultado obtenido: Pendiente.

CP VTA-04: Vender un producto sin stock suficiente

• Objetivo: confirmar si el sistema bloquea la venta o la permite y deja el inventario en negativo (el ajuste de stock vía evento usa max(0, ...), lo cual podría ocultar sobreventas en vez de advertirlas).
• Pasos: producto con 2 unidades de stock → vender 5.
• Resultado esperado a verificar: ¿hay alguna advertencia antes de confirmar la venta, o se vende igual y el inventario simplemente queda en 0 sin indicar que se vendieron 3 de más?
• Resultado obtenido: Pendiente.

CP VTA-05: Vender un producto tipo combo

• Precondición: combo creado en PROD-03.
• Resultado esperado: confirmar si descuenta inventario de los productos componentes del combo o no descuenta nada (el evento de venta solo recorre sale_items, que registra el combo como una sola línea — es probable que no descuente los componentes, lo cual sería un hallazgo real a reportar).
• Resultado obtenido: Pendiente.

CP VTA-06: Vender un producto que consume un ingrediente vía receta

• Precondición: producto con recipe_items de PROD-05.
• Resultado esperado a verificar: mismo caso que VTA-05 — ¿el sistema descuenta el ingrediente de la receta, o solo tiene efecto visual en el formulario sin lógica real de descuento?
• Resultado obtenido: Pendiente.

Descuentos y promociones aplicadas

CP VTA-07: Aplicar un descuento manual dentro del límite permitido por la política (discount_policies.max_discount_pct)

• Resultado esperado: se aplica correctamente al subtotal de la línea o la venta completa (confirmar a cuál).
• Resultado obtenido: Pendiente.

CP VTA-08: Intentar un descuento manual mayor al max_discount_pct permitido para el rol del cajero

• Resultado esperado: debe bloquearse o requerir aprobación — confirmar comportamiento real (¿el backend valida esto en sales, o solo el frontend lo sugiere sin forzarlo?).
• Resultado obtenido: Pendiente.

CP VTA-09: Promoción is_auto_apply=true que aplica automáticamente al agregar el producto correspondiente

• Resultado esperado: el descuento aparece sin que el cajero haga nada.
• Resultado obtenido: Pendiente.

CP VTA-10: Dos promociones que compiten por el mismo producto (prioridad distinta)

• Resultado esperado: debe aplicarse solo la de mayor priority, no ambas acumuladas (salvo que el diseño sea explícitamente acumulativo — confirmar cuál es el comportamiento real y si coincide con lo esperado por el negocio).
• Resultado obtenido: Pendiente.

Pago mixto / gift card

CP VTA-11: Pagar una venta combinando efectivo + tarjeta

• Pasos: registrar dos payments para la misma venta, uno method="cash" y otro method="card", que sumen el total.
• Resultado esperado: la venta queda marcada como pagada solo cuando la suma de pagos cubre el total — confirmar si esta suma la valida el backend o es responsabilidad del frontend.
• Resultado obtenido: Pendiente.

CP VTA-12: Pagar con gift card que no tiene saldo suficiente

• Resultado esperado: debe rechazarse o cobrar solo el saldo disponible, nunca dejar la gift card en saldo negativo (el repositorio limita a max(0, ...) al restar, igual que el inventario).
• Resultado obtenido: Pendiente.

CP VTA-13: Pagar con una gift card ya vencida (expiry_date en el pasado)

• Resultado esperado a verificar: ¿el sistema valida la fecha de vencimiento al usarla como pago, o solo es un dato informativo que no bloquea nada?
• Resultado obtenido: Pendiente.

Órdenes en espera y pantalla de cocina (KDS)

CP VTA-14: Crear una orden status="held" (mesa) y confirmar que llega a la pantalla de cocina

• Pasos: crear venta con status: "held", mesa asignada (table_name) → abrir la pantalla KDS de esa tienda.
• Resultado esperado: la orden aparece en tiempo real vía SSE (/sse/kds), con kitchen_status="new".
• Resultado obtenido: Pendiente.

CP VTA-15: Avanzar el estado de cocina (new → acknowledged → preparing → ready → served)

• Resultado esperado: cada transición se refleja en tiempo real; un valor fuera de ese oneof (ej. "lista" en español) debe rechazarse con 400.
• Resultado obtenido: Pendiente.

CP VTA-16: “Re-hold” de una orden ya servida (volver a abrir la mesa con los mismos productos)

• Objetivo: el código respeta kitchen_status si el cliente lo envía explícitamente al crear, en vez de forzar siempre "new" para órdenes held — confirmar que esto sirve para no re-enviar a cocina algo que ya se preparó.
• Resultado obtenido: Pendiente.

CP VTA-17: Dos pantallas KDS de la misma tienda abiertas en paralelo

• Resultado esperado: ambas deben recibir la actualización en tiempo real cuando se marca una orden como lista, sin necesidad de refrescar.
• Resultado obtenido: Pendiente.

Devoluciones

CP DEV-01: Devolución total de una venta, referenciando el sale_id

• Resultado esperado: debe aumentar nuevamente el inventario de los productos devueltos.
• Resultado obtenido: Pendiente.

CP DEV-02: Devolución parcial (solo uno de los productos de una venta de varios ítems)

• Resultado esperado: solo ese producto recupera inventario; el resto de la venta queda sin cambios.
• Resultado obtenido: Pendiente.

CP DEV-03: Devolución con cantidad mayor a la comprada originalmente

• Resultado esperado a verificar: ¿el backend valida que la cantidad devuelta no exceda la vendida? Si no, se podría “inventar” inventario devolviendo de más.
• Resultado obtenido: Pendiente.

CP DEV-04: Devolución sin referenciar ninguna venta (sale_id nulo, solo sale_reference de texto libre)

• Resultado esperado a verificar: el DTO permite devoluciones “sueltas” sin venta real asociada — confirmar si esto es intencional (ej. para mercancía dañada sin venta previa) o es una laguna de validación.
• Resultado obtenido: Pendiente.

Carta online (pedido público)

CP VTA-18: Cliente hace un pedido por QR sin iniciar sesión

• Pasos: escanear/abrir /public/menu/:slug, agregar productos con modificadores, enviar pedido.
• Resultado esperado: se crea una venta held asociada a la tienda correcta, visible en el KDS.
• Resultado obtenido: Pendiente.

CP VTA-19: Pedido por carta online de un producto marcado show_in_menu=false

• Resultado esperado: no debería ni aparecer en la carta pública; si se fuerza el product_id directamente en la petición, el backend debería rechazarlo igual.
• Resultado obtenido: Pendiente.

CP VTA-20: Pedido por carta online con un slug que no existe

• Resultado esperado: página de error clara (“tienda no encontrada”), no una pantalla en blanco o un crash.
• Resultado obtenido: Pendiente.

Notas de usabilidad y sugerencias

Se completa durante la ejecución. Prestar especial atención a VTA-05/VTA-06 (combos e ingredientes) — si no descuentan inventario correctamente, es un hallazgo de negocio importante, no solo de UI.