Documentación funcional del sistema operativo de Blasón: cómo se enrutan los pedidos, qué estaciones existen, qué estados atraviesa cada ítem y cómo el equipo coordina el despacho cuando una mesa tiene platos en distintas estaciones. Después de la documentación, hay tres mockups visuales que muestran cómo se traduce todo esto en pantalla.
El POS divide cada pedido por estación de preparación. Una mesa puede tener ítems en tres estaciones a la vez. El sistema sincroniza los tiempos para que los platos lleguen juntos, no en secuencia desordenada.
Cada producto de la carta está asociado a una estación fija. Cuando se envía un pedido, el ítem aparece automáticamente en la pantalla de su estación correspondiente. El equipo de cocina nunca tiene que filtrar manualmente: cada KDS solo muestra lo suyo.
Cada ítem del pedido avanza por cuatro estados, sin retroceder. El cambio de estado lo dispara el responsable de la estación con un toque en su KDS. Al pasar a "Listo", el sistema notifica a sala para el despacho.
Cuando sala envía un pedido desde la mesa, el POS lee la estación asociada a cada ítem y reparte la información en paralelo. No hay decisión humana en el medio. La pizzaiolo solo ve sus pizzas; la cocina solo ve sus pastas; la barra solo ve sus bebidas y postres.
Cuando una mesa tiene ítems en más de una estación, cada ticket muestra una etiqueta indicando dónde están sus hermanos y cuántos quedan pendientes. Esto evita que el pizzaiolo termine su Margherita sin saber que la pasta de la misma mesa todavía está en cocción.
La regla de despacho del equipo es simple: una mesa se sirve junta o casi junta. Si un ítem termina antes y el hermano aún está en estado "En preparación" con más de 4 minutos restantes, el plato listo se mantiene en pase con el calor adecuado hasta que el hermano esté próximo a salir.
Mockups en miniatura de las tres pantallas críticas: mapa de mesas (sala), KDS de pizza (cocina) y toma de pedido (sala/tablet). Esto no es código funcional — es la representación visual del sistema descrito arriba para briefing de desarrollo.
Un POS real se rompe en las excepciones, no en el flujo feliz. Estos son los seis casos que el sistema tiene que manejar bien — sin que el mesero tenga que llamar al responsable cada vez.
Si está "Pendiente": cancelación libre desde la tablet de sala. Se descuenta del ticket sin necesidad de aprobación. Queda registrado quién canceló y cuándo.
Si está "En preparación": requiere aprobación del responsable de turno (PIN). Si la cocina ya empezó, se descuenta del ticket pero el insumo se reporta como merma — no se pierde la trazabilidad para el inventario.
Si está "Listo" o "Entregado": no se cancela, se rebaja. Solo el responsable puede emitir un descuento (10% / 25% / 50% / 100%) con motivo registrado.
Cada plato en el catálogo tiene una lista de modificadores aceptados, con dos niveles:
Sin costo: sin cebolla, sin ajo, sin albahaca, masa fina, masa gruesa, salsa aparte, picante extra, sin picante, sin sal añadida.
Con costo (extras): +mozzarella (S/ 6), +rúcula (S/ 4), +parmesano (S/ 5), +guanciale (S/ 8), +huevo (S/ 4).
No permitidos: sustituciones que rompen el plato (cambiar guanciale por bacon, mozzarella por queso amarillo). El POS no las muestra como opción. Si el cliente insiste, mesero llama al responsable, no se debate en mesa.
Cada ítem del ticket tiene un campo "tiempo" con tres valores: Antipasto, Principal, Postre. Por defecto se asigna según categoría del plato; el mesero puede cambiarlo en la toma de pedido.
La cocina recibe el pedido completo pero solo arranca un tiempo a la vez. Cuando todos los ítems de tiempo 1 están "Listos" y entregados, el responsable de pase libera el tiempo 2. Si el cliente quiere todo junto, se marca "salida única" en el ticket y se ignora la separación.
Caso típico: la mesa 5 está esperando una pizza, llega un grupo de 6 y necesitamos juntar 5 + 6. El responsable arrastra el ticket de la mesa 5 a la mesa 6 (o crea una mesa virtual "5+6"). Todos los ítems pendientes mantienen su estación y estado; los KDS se actualizan instantáneamente con el nuevo número de mesa.
Restricción: no se permite transferir si hay ítems "En preparación" — primero esperar a que estén "Listos" para evitar que la cocina sirva en mesa equivocada.
Tres marcadores opcionales por ticket o ítem:
· Alergia: el ticket se pinta de rojo en KDS, con el alérgeno escrito en grande arriba. Quien lo prepara firma con PIN antes de marcar "Listo". No se sirve sin esa firma.
· Prioridad alta: niño con hambre, mesa con cliente que tiene que salir a un horario. Se mueve al primer lugar de la cola en su estación. Visible con un indicador ▲ en KDS.
· VIP / cortesía: ticket marcado para tracking interno (ocasión especial, prensa, prueba de menú). No se cobra automáticamente; el responsable decide al cierre.
El POS soporta tres modos de split, elegidos al cerrar la cuenta:
· Por ítem: cada persona elige qué pagó. La pantalla arrastra ítems a "personas" (Persona 1, 2, 3, 4). Lo más usado.
· Igual: total dividido en N partes iguales. Útil cuando comparten todo.
· Mixto: una persona paga lo suyo y el resto lo dividen. Para el caso de "yo invito a Ana, los demás paguen lo suyo".
En todos los casos, la propina sugerida (10%) se calcula sobre cada porción. El cliente puede ajustar individualmente.
El orden importa: en Cusco, una trattoria que no acepta Yape pierde mesas. Diseñar el flujo de cobro para que el método rápido sea el más visible.
QR persistente del local. Cliente escanea, paga, muestra confirmación. Mesero verifica monto y nombre, marca el ticket como pagado.
Mismo flujo que Yape. QR único impreso en cada mesa más QR grande en el área de caja.
Visa, Mastercard, Amex. POS de banco con lector NFC en mesa (no se lleva la tarjeta del cliente). Soporta splits hasta 4 tarjetas.
Soles únicamente. Vuelto en máximo 2 minutos — caja con denominaciones suficientes pre-cargadas al inicio del turno.
Solo para reservas con depósito (grupos +6, eventos). No se acepta como pago de cuenta en mesa.
La propina nunca se cobra automáticamente ni se incluye sin avisar. La cuenta muestra: subtotal, IGV (incluido en el precio), y una línea de "Propina sugerida 10%" que el cliente puede aceptar, ajustar o quitar.
Si el cliente pregunta, mesero responde: "La propina es opcional, sugerimos 10% pero queda a tu gusto." Sin presión, sin caras.
Distribución interna: 70% para sala, 20% para cocina, 10% para barra. Se reparte al cierre semanal. La distribución está documentada por escrito y el equipo la conoce.
El cierre de turno tiene cuatro momentos. El responsable lo hace; ningún mesero se va antes de que esté firmado.
Conciliar efectivo en caja vs ventas en POS. Diferencia tolerable: ±S/ 10. Más que eso, se revisa transacción por transacción antes de firmar el cierre.
Descargar de las apps de pago vs ventas digitales en POS. Cuadrar montos. Si falta una transacción, se busca en la app antes de firmar.
Repasar qué quedó 86 hoy y por qué. Se pasa al pedido de mercadería del día siguiente. Si un ítem se repite, se marca como "revisar consumo" en bitácora.
El POS imprime un resumen: cubiertos atendidos, ticket promedio, top 5 platos vendidos, food cost del día estimado, propinas a repartir. Se guarda en la bitácora digital y en papel.
Asumir que internet se va a caer. El POS tiene que seguir tomando pedidos y la cocina tiene que seguir recibiéndolos, sin ayuda de la nube.
El POS funciona como app local en cada tablet, sincronizada en tiempo real vía red local (Wi-Fi del router del local, no internet externo). Si se cae internet del proveedor:
· Toma de pedidos: sigue funcionando normalmente. Las tablets hablan entre sí por la red local.
· KDS de cocina: sigue recibiendo tickets desde tablets de sala vía red local.
· Pagos digitales (Yape/Plin/tarjeta): se caen. Se acepta efectivo y se anota una promesa de pago digital al volver internet (raramente más de 30 minutos).
· Sincronización a la nube: se reanuda automáticamente cuando vuelve internet. Todos los tickets del periodo offline se suben con timestamp original.
· Si se cae el router del local (red interna): protocolo manual con comandera de papel. Cada tablet imprime al volver. Es el caso peor; debería pasar 0 veces al mes.
Cada estación de cocina (Pizza, Cocina, Barra) tiene tablet KDS + impresora térmica. Cada ticket que llega al KDS se imprime simultáneamente. Por dos razones:
· Backup físico: si la tablet se queda sin batería, se moja, o se cae, el papel sigue en la línea. La cocina no para.
· Preferencia de los cocineros: muchos cocineros experimentados prefieren mirar papel a pantalla. El papel se cuelga en la línea, marca prioridad por orden físico, y se rompe cuando está hecho. La pantalla es para tracking; el papel para trabajar.
Modelo: cualquier impresora térmica USB de 80mm con driver ESC/POS. La marca da igual; lo que importa es que la haya en repuesto en el almacén.
Caso peor: se va internet, se va luz (back-up de gas para horno), tabletas sin batería. Protocolo: comandera de papel triplicada — una para sala, una para cocina, una para barra. Cuenta a mano con calculadora del responsable. Cobro solo en efectivo.
Esto debe poder operar 30 minutos sin problemas. Más que eso, se cierra el local hasta que vuelva la operación normal.