El problema
El DESGLOSE DE VENTA del Corte Z (#ORDER_SUBTOTAL#, #ORDER_TAXES#, #ORDER_TOTAL#) actualmente se calcula tomando lo que caja capturó como pago y dividiéndolo entre 1.16 para “obtener” el subtotal.
Por qué está mal
Además de errores del cajero, hay otros problemas estructurales:La fuente de verdad correcta
El DESGLOSE DE VENTA debe calcularse desdeOrderTicketLine con status open — las líneas que realmente se ordenaron, sirvieron y cobraron correctamente.
El método
getOrderTicketLines($model, 'open') ya existe en el código y filtra exactamente lo correcto — solo líneas con status open, excluyendo automáticamente canceled y voided. Solo hay que usarlo para calcular el subtotal de ventas.OrderTicketLine ya tiene los accessors correctos listos para usar:
El fix
Archivo a modificar:Método 1 — getOrderSubtotal (línea ~277)
Método 2 — getOrderTaxes (línea ~284)
Método 3 — getOrderTotal (línea ~291)
Qué cambia y qué no cambia
Los campos de efectivo, tarjeta, faltante/sobrante y saldo siguen viniendo de los pagos — eso es correcto y no debe cambiar. Solo cambian los 3 campos del DESGLOSE DE VENTA.
Impacto en Restaurantero Pro
Con este fix, cuando RC envíe elPOST /api/v1/ingest/sales al cerrar el Corte Z, Restaurantero Pro recibirá los valores correctos:
total_sales_cents= venta real neta (con descuentos, sin cancelados, sin voided)total_sales_no_iva_cents= venta real sin IVA calculada por línea- Food Cost % correcto en el dashboard del dueño
- P&L correcto
- EBITDA correcto
Prompt para Cursor
Cómo verificar que el fix funcionó
Después del cambio, en el siguiente Corte Z verifica:#ORDER_TOTAL#coincide con la suma de todos los tickets cerrados del período- Si hubo una cancelación de $500, ese monto NO aparece en
#ORDER_TOTAL# - Si hubo un descuento del 20% en una mesa, el total refleja el precio con descuento
#PAYMENT_CASH_TOTAL#y#PAYMENT_CARD_TOTAL_WITHOUT_TIP#no cambiaron- El
cash_shortage(faltante/sobrante) sigue calculándose correctamente
Restaurant Controller — Fix Corte Z
Mayo 2026 · Confidencial