Lo que un POS de restaurante no puede fallar

Un mesero está parado en la mesa nueve con cuatro tragos en la cabeza y un cliente pidiendo la cuenta en la mesa dos. Le quedan unos cuatro segundos de paciencia para tu software. Si la pantalla que necesita está a dos menús de distancia, va a anotar la orden en la mano y la va a meter después, mal, de memoria. Ahí es donde fallan en silencio la mayoría de los sistemas de restaurante, y ningún dashboard te lo va a mostrar.

Armamos una interfaz de POS de restaurante como parte del set que está en /demos. Es un mock-up con platos inventados, mesas inventadas y totales inventados, sin cocina ni gaveta de dinero conectadas. La razón de construirlo fue resolver la forma del sistema: qué pantallas existen, qué queda en el primer toque, y qué tiene que demostrar la pantalla de cierre al final de un turno.

El camino frecuente tiene que ser cortísimo

Casi todo el trabajo en un restaurante son las mismas tres acciones repetidas unas cuantas cientos de veces por noche. Abrir mesa. Agregar ítem. Mandar a cocina. Lo demás, dividir cuentas, cortesías, devoluciones, es raro en comparación y puede permitirse un toque extra. Los sistemas salen al revés cuando alguien lista todas las funciones y le da el mismo peso a cada una en la navegación.

Entonces la pregunta de diseño no es qué puede hacer el sistema, sino qué se alcanza con el pulgar mientras uno camina. En la interfaz de muestra, el mapa de mesas es la pantalla principal y la grilla de productos está a un toque desde cualquier mesa abierta. Los modificadores se abren ahí mismo, no en otra página. Nada de eso es ingenioso; es simplemente decidir cuál es la acción frecuente y negarse a enterrarla.

Lo que un punto de venta tiene que resolver, más o menos en este orden:

SIN

• Todas las funciones con el mismo peso
• Orden creada en el servidor
• Impresión a cocina por la nube
• Trazabilidad agregada después

CON

• Acción frecuente en el primer toque
• Orden creada en el dispositivo
• Impresora de cocina en red local
• Trazabilidad escrita con la venta

• mandar una orden a cocina en menos de tres toques, siempre
• modificadores y cuentas divididas sin salir de la mesa
• cada anulación, descuento y cortesía amarrada a la persona que la hizo
• imprimir la comanda aunque no haya conexión
• una secuencia de comprobantes sin saltos y sin duplicados
• un cierre de turno que un gerente pueda cuadrar contra el efectivo de la gaveta

Cuando se cae la conexión

El internet en RD es bueno hasta que deja de serlo, y suele fallar justo a la hora que menos te conviene. Un POS que deja de tomar órdenes porque un API en la nube dio timeout es peor que una libreta. La regla de diseño es que el terminal es dueño del turno mientras el turno ocurre: las órdenes se crean localmente, con un identificador generado en el dispositivo, y se encolan. El servidor se pone al día cuando pueda.

Eso tiene consecuencias que hay que aceptar desde el principio. Los números de comprobante no los puede asignar el dispositivo, porque dos terminales offline al mismo tiempo van a reclamar el mismo número, así que salen del servidor y el ticket impreso tiene que tolerar esa espera. Las impresoras de cocina van en la red local, hablando directo con el terminal, para que un módem quemado no detenga la comida. Y si dos meseros tocan la misma mesa estando offline, cómo se resuelve el choque es una decisión del negocio, no técnica, y alguien tiene que tomarla antes de escribir el código.

El cierre de turno es el verdadero producto

La pantalla que decide si un restaurante se queda con el sistema es la de las dos de la mañana. Efectivo contado, totales del lote de tarjetas, propinas declaradas, anulaciones con nombre al lado, y la diferencia entre lo que dice el sistema y lo que hay en la gaveta. Si ese número no se puede explicar, el dueño deja de creerle a todos los demás números del sistema, incluyendo los que estaban bien.

Por eso la trazabilidad no es un requisito de cumplimiento que se atornilla después. Se escribe en el mismo momento de la venta: quién abrió la mesa, quién movió el ítem, quién aplicó el descuento, a qué hora imprimió el ticket. Meter eso después en un sistema que trataba las órdenes como filas modificables duele, y preferimos decirlo antes que fingir que es una migración pequeña.

Nada de esto es exótico. Es la disciplina normal de construir para un salón lleno de gente que va corriendo y a la que tu software le importa poco. La interfaz de muestra en /demos existe para que un dueño de restaurante vea la forma del sistema y nos diga en qué su operación es distinta, que siempre lo es, antes de que alguien escriba una línea de código de producción.