Restaurant Commerce: menú, Ordering, KDS, Kiosk y POS

Reven Ordering, KDS, Kiosk y POS utilizan un solo menú, las mismas reglas de precios y un registro común de pedido. Un artículo vendido o modificado no necesita actualizarse manualmente en cada canal.

Menú

Un usuario con menu:manage puede gestionar:

• ubicación, menú, publicación y orden de categorías;
• nombre, SKU, descripción, precio, precio comparativo e imagen;
• etiquetas Vege, Vegan, New y Bestseller y nivel de picante;
• categorías adicionales y estaciones de preparación;
• grupos de modificadores y número mínimo/máximo de opciones;
• opciones, suplementos, valores predeterminados, actividad y sold out;
• capacidad, lead time y zonas de entrega.

El SKU es importante para vínculos entre ubicaciones y vales de artículo exacto. Debe ser estable y único en el modelo elegido.

Ordering y tratamiento del pedido

El cliente elige consumo en local, recogida o entrega disponible. El servidor recalcula precios, modificadores, entrega, mínimo, cupones, vales y pago. No se puede confiar en un importe enviado solo por el navegador.

Tras el pago, el pedido puede aceptarse automáticamente o esperar a un empleado. En modo manual se acepta indicando una hora prometida. Secuencia típica: pagado → aceptado → en preparación → listo → completado. El reembolso requiere orders:manage y comprobar cada tender y beneficio.

KDS

KDS muestra pedidos y artículos por estaciones. Los usuarios con kds:operate actualizan el trabajo. Debe funcionar en un dispositivo dedicado y el procedimiento del local debe cubrir pérdida de red y comunicación manual.

Kiosk

El cliente puede iniciar un pedido de comida o una compra independiente de vale. Elige entrega, artículos y modificadores, puede escanear Loyalty, cupón o vale y paga el resto.

Kiosks registra el dispositivo una vez y controla conexión, terminal, impresora fiscal, escáner, papel y último error. El agente local establece una conexión saliente y mantiene el secret fuera del frontend.

En producción, el adaptador del terminal debe admitir estado, inicio idempotente, consulta, reversal y refund; el fiscal debe comprobar dispositivo, papel, fiscalización y resultado. Un resultado ambiguo se consulta por referencia: nunca se inicia otro pago a ciegas. Si la fiscalización es obligatoria, el pedido solo se envía a preparación después de completarla.

POS

POS usa el menú común para mostrador, teléfono y pedidos trasladados de marketplace. El pago por terminal depende del proveedor y dispositivo. Un pedido externo debe conservar su referencia y no crear un pago online paralelo.

Límites de la solución

Reven v1 no es por sí mismo una caja fiscal polaca certificada. El cliente mantiene el proceso legal salvo que el alcance incluya una integración aprobada concreta. Los drivers pueden ser simuladores; el estado de producción se confirma por terminal e impresora.

Comprobaciones antes del lanzamiento

1. Crea pedidos de local, recogida y cada zona de entrega.
2. Comprueba precio, modificadores, cargo, mínimo, vale/cupón y resto.
3. Comprueba pago aceptado/rechazado, webhook repetido y reembolso.
4. Comprueba aceptación automática/manual, KDS y hora prometida.
5. En el quiosco real prueba idle/reset, escáner, terminal, fiscalización, falta de papel, pérdida de red y recuperación.