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.
Verificado 2026-09-24
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 público o el operador POS elige consumo en local, recogida o entrega disponible para la dirección o zona. En el Ordering público, Kiosk y POS, este paso puede configurarse antes del menú o al final del carrito si el local quiere recopilar primero los artículos. Los artículos pueden añadirse directamente con la cantidad elegida y luego ajustarse con controles de menos/más en el carrito o en el ticket POS actual. El servidor recalcula precios, cantidades, modificadores, el cargo de entrega u otro cargo de fulfillment, por ejemplo envase para llevar, mínimo, cupones, vales y pago. No se puede confiar en un importe enviado solo por el navegador.
El 14-08-2026 se revisó el cambio visual móvil de Ordering público: los CTA de carrito y añadir artículo fuerzan el texto a primary-foreground para mantener contraste con temas de marca. El cambio no modifica la lógica del carrito, el checkout ni los estados de pedido.
El 14-08-2026 también se revisó el cambio de navegación de categorías en móvil para Ordering público: el encabezado del local se desplaza con la página y la barra de categorías permanece fijada arriba de la pantalla. El cambio mejora el acceso a categorías al recorrer el menú y no modifica carrito, checkout, pago ni estados de pedido.
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.
La página de estado del pedido es privada — se entra con un token desde la URL y el token nunca se repite en los metadatos — por lo que tiene noindex, nofollow. Muestra los modificadores guardados y los cargos cobrados desde el registro del pedido, para que el cliente pueda revisar sus elecciones después del pago. Cuando un pedido alcanza completed, la página muestra la encuesta privada e integrada de Guest Experience, pero solo si el módulo guest_experience está activo y el disparador de pedidos está habilitado. Los estados cancelled, refunded y todos los no completados no muestran encuesta. La página se sondea cada pocos segundos y se detiene en un estado terminal, así que la encuesta aparece al completarse sin recarga manual. La compra de un vale en el quiosco es técnicamente un pedido completed pero no una comida real, por lo que la página de estado y el resolver del servidor la omiten por igual.
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. Para comida, elige o confirma el modo de fulfillment, 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. Para un usuario con varias ubicaciones, POS abre una ubicación con menú disponible; una ubicación elegida manualmente sin menú envía al personal a la configuración del menú. POS puede tener su propia configuración de producto pos y hereda los campos faltantes de ordering, así que el paso de elección de fulfilment y los cargos pueden mantenerse compartidos o separarse para POS. 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
- Crea pedidos de local, recogida y cada zona de entrega.
- Comprueba precio, modificadores, cargo, mínimo, vale/cupón y resto.
- Comprueba pago aceptado/rechazado, webhook repetido y reembolso.
- Comprueba aceptación automática/manual, KDS y hora prometida.
- En el quiosco real prueba idle/reset, escáner, terminal, fiscalización, falta de papel, pérdida de red y recuperación.
Con LoyaltyPlant, el quiosco mantiene una sesión verificada del cliente en el servidor. REGULAR puede comenzar con una tarjeta o un regalo válido; un regalo eliminado no se incluye en el recibo final. Un pago fallido no autoriza un segundo cargo: hay que terminar el intento anterior y volver a escanear la tarjeta antes de un nuevo pedido. La acumulación real de puntos debe confirmarse con el proveedor, no deducirse de una respuesta correcta de la tarea.