Sistema para restobar en Perú: mesas, barra, cocina, caja y cierre sin islas

Una mesa puede pedir varias veces, dividir consumo entre barra y cocina y pagar con distintos medios al final de la noche. Ese contexto importa porque una función aislada puede verse correcta en una demo y fallar cuando el negocio mezcla canales, personas y decisiones bajo presión. Antes de comparar proveedores, dibuja una operación de principio a fin y marca exactamente dónde hoy se pierde información, se repite una pregunta o se depende de memoria.

En este caso la decisión clave es mantener la cuenta, las partidas y los estados unidos aunque trabajen varias estaciones. Tradúcela a una prueba observable: usa productos, modalidades y roles parecidos a los del negocio; cambia algo a mitad del flujo y comprueba si todos siguen viendo la misma orden. Una plataforma útil no obliga a reinterpretar lo que el cliente ya eligió ni a crear una segunda versión del pedido para que otra área pueda trabajar.

La secuencia que debes probar es Mesa → Comanda → Estaciones → Cuenta → Cobro → Cierre. Haz varias operaciones casi al mismo tiempo y observa qué parte empieza a exigir coordinación verbal. Si una modificación, un cambio de modalidad o una corrección de cobro obliga a abrir un chat paralelo, anótalo: esa fricción se multiplicará todos los días.

Fuerza también tres excepciones reales: Partida enviada a la estación incorrecta, Cuenta dividida sin trazabilidad, Pago parcial que no cuadra al cierre. La recuperación revela si el sistema tiene estados intermedios, permisos claros y trazabilidad suficiente. Un flujo que solo funciona cuando nadie se equivoca no está listo para una operación comercial exigente.

Para un restobar con mesas, barra y cocina, pide evidencia concreta sobre Mesas y cuentas abiertas, Ruteo a barra/cocina, División de cuenta, Cierre nocturno. Después pregunta qué cambia cuando aumentan pedidos, usuarios, productos, comprobantes o locales. La misma función puede ser suficiente hoy y convertirse en un cuello de botella si depende de límites que nadie explicó durante la venta.

Finalmente define una línea base: cuánto tarda hoy el equipo, cuántas correcciones realiza y qué pasos siguen fuera del sistema. No necesitas convertir cada minuto en soles para decidir. Basta medir antes y después con el mismo método para saber si la herramienta realmente simplificó el trabajo que pretendías mejorar.

Prueba “Mesas y cuentas abiertas” usando datos que se parezcan a los de un restobar con mesas, barra y cocina. Empieza en mesa y continúa hasta comanda sin preparar el sistema para que todo salga perfecto. Cambia una condición a mitad del recorrido y revisa si “Ruteo a barra/cocina” sigue teniendo contexto. Incluye también el caso “Partida enviada a la estación incorrecta”: si la recuperación exige borrar la operación o crear una segunda versión, todavía existe una debilidad que debes resolver antes de depender del flujo.

Para evaluar “Ruteo a barra/cocina”, observa qué ve la persona que recibe el trabajo después de comanda. No basta con que el dato exista en algún menú; debe aparecer en el momento en que cambia una decisión. Contrástalo con “División de cuenta” y documenta qué sucede ante “Cuenta dividida sin trazabilidad”. Una buena implementación deja una señal comprensible, una autoridad clara para corregir y un historial suficiente para que el siguiente turno no tenga que reconstruir lo ocurrido.

“División de cuenta” merece una prueba de responsabilidad: quién puede modificarlo, quién solo lo consulta y qué parte del flujo se actualiza cuando cambia. Recorre Estaciones → Cuenta con dos roles distintos y verifica que “Cierre nocturno” no dependa de permisos excesivos. Después provoca “Pago parcial que no cuadra al cierre”. Si la única forma de continuar es compartir credenciales, editar datos sin rastro o pedir a una persona concreta que intervenga, el proceso todavía no está preparado para crecer con seguridad.

Con “Cierre nocturno” conviene mirar escala y no solo funcionalidad. Repite Cuenta → Cobro varias veces, mezcla operaciones normales con “Partida enviada a la estación incorrecta” y comprueba si “Mesas y cuentas abiertas” conserva velocidad y claridad. Pregunta además qué límite contractual, técnico o de configuración cambia con más volumen. El objetivo no es exigir capacidad infinita; es saber con anticipación cuándo la operación necesitará otro plan, más hardware o una configuración distinta para seguir siendo predecible.

Simula “Partida enviada a la estación incorrecta” durante mesa. La prueba termina solo cuando la operación llega otra vez a estaciones con un estado coherente. Revisa qué mensaje recibió el equipo, quién tuvo permiso para actuar y cómo quedó afectado “Ruteo a barra/cocina”. Esta disciplina evita aceptar una demo donde el error se resuelve reiniciando, borrando o corrigiendo directamente en base de datos: acciones que no representan una recuperación sostenible para un restaurante en producción.

Cuando ocurra “Cuenta dividida sin trazabilidad”, mide tiempo hasta detección y tiempo hasta resolución por separado. Un problema puede ser fácil de corregir pero difícil de descubrir, y esa demora puede contaminar comanda, cuenta o “División de cuenta”. Pide que el sistema muestre suficiente evidencia para distinguir causa de síntoma. Si todos ven que algo está mal pero nadie puede explicar por qué, el flujo todavía produce trabajo de investigación que debe formar parte de la evaluación.

Usa “Pago parcial que no cuadra al cierre” como prueba de cambio de turno. Una persona inicia el caso en estaciones y otra debe poder terminarlo en cobro sin una explicación verbal privada. Comprueba que “Cierre nocturno” conserve contexto, que las acciones sensibles tengan autor y que los comentarios necesarios queden junto a la operación. La continuidad entre personas es una señal fuerte de que el proceso vive en el sistema y no solamente en la memoria del equipo.

Un restobar suele mantener cuentas abiertas durante más tiempo que un formato de comida rápida. La prueba debe incluir una mesa que ordena varias rondas, mueve una partida y divide el pago al final. Observa si cada adición conserva hora y usuario y si cocina o barra reciben solo lo que corresponde. La cuenta puede crecer durante horas sin perder su identidad; si el sistema crea subtotales desconectados, el cierre se vuelve una investigación.

Barra y cocina tienen ritmos diferentes. Una bebida puede estar lista antes que un plato, y el salón necesita saber qué parte del pedido puede servirse sin cerrar la orden completa. Simula partidas que salen de estaciones distintas y revisa si los estados son lo bastante simples para el equipo. Un tablero con demasiadas categorías puede ser tan confuso como no tener estados. La jerarquía debe ayudar a servir, no a documentar cada microevento.

La división de cuenta necesita reglas claras cuando hay promociones, descuentos o productos compartidos. Prueba una cuenta con dos medios de pago y una cortesía autorizada. Después revisa caja. El objetivo es que el total cobrado y el historial de cambios puedan explicarse sin editar retroactivamente la venta. Si la única forma de cuadrar es modificar la orden después del cierre, el control está escondiendo el problema en vez de resolverlo.

En inventario, barra y cocina pueden consumir insumos con unidades muy distintas. Bebidas por unidad, licores por medida y alimentos por peso requieren conversiones consistentes. No hace falta modelar cada gota desde el primer día; selecciona insumos costosos o de alta rotación. La prueba importante es comprobar si la venta puede producir consumo teórico suficiente para detectar una diferencia que merezca investigación.