Antylogic
Probar demoAcceso app

399 guías operativas

Secciones de Docs
DocsReservas online
Dispositivo

Cómo calcular disponibilidad por capacidad

Consulta los huecos disponibles de un servicio automático usando capacidad real de mesas, combinaciones, reservas existentes y reglas del optimizador. El cálculo solo devuelve disponibilidad: no crea reservas ni cambia asignaciones.

En este artículo

La disponibilidad optimizada ayuda al equipo de sala a saber qué horarios puede aceptar antes de crear una reserva. Antylogic calcula esos huecos con el plano del local, las mesas combinables, las reservas ya existentes y las asignaciones aplicadas.

El mismo cálculo sostiene la reserva pública: el cliente ve horas viables para Marea Gran Via, mientras el restaurante mantiene control sobre capacidad, preferencias y lista de espera.

Antes de empezar

  • Trabajar sobre una ocurrencia futura de servicio en Marea Gran Via, abierta y en modo automático.
  • Tener permisos internos para gestionar reservas y usar reservas automáticas cuando se opera desde la pantalla interna.
  • El servicio debe tener `layout_id` y `optimization_config_id` asociados.
  • El plano debe incluir mesas y, si el restaurante las usa, combinaciones de mesas configuradas.
  • El servicio externo de optimización debe estar disponible para que `/available` pueda devolver huecos.

Instrucciones

  1. 1.

    Abre el servicio que quieres cubrir

    Desde reservas, entra en el detalle del servicio y confirma que admite reservas automáticas. En la web pública, el cliente llega al mismo cálculo al avanzar por `/:orgId/:locationId/reservar` hasta la selección de disponibilidad.

  2. 2.

    Indica el número de personas

    Pulsa `Nueva reserva` o completa los datos iniciales del flujo público. El dato imprescindible es `party_size`; sin personas, la consulta de disponibilidad no se ejecuta.

  3. 3.

    Añade restricciones o preferencias de mesa si procede

    En el modal interno puedes trabajar con mesas asignadas, obligatorias o preferidas. En la web pública, las preferencias solo se aplican si el local las tiene activadas.

  4. 4.

    Revisa los horarios devueltos

    La aplicación muestra las franjas viables que devuelve el optimizador. Cada hueco tiene en cuenta plano, combinaciones, reservas confirmadas y asignaciones existentes.

  5. 5.

    Gestiona la falta de huecos o un fallo del optimizador

    Si no hay horarios, la respuesta queda vacía. En la pantalla interna puedes derivar a lista de espera o reserva manual; en la web pública se muestra el estado correspondiente sin permitir elegir una hora inválida.

  6. 6.

    Continúa con el hueco elegido

    Seleccionar una hora prepara el siguiente paso, pero esta acción no guarda la reserva. Si otra reserva ocupa el hueco antes de confirmar, el flujo posterior debe refrescar disponibilidad.

Validaciones y límites

  • El servicio debe estar en `booking_mode` automático, abierto y no estar en el pasado.
  • `party_size` debe ser mayor que cero.
  • Si falta `layout_id`, el backend no puede calcular disponibilidad.
  • Si falta `optimization_config_id` o el runtime externo no responde, no se generan slots optimizados.
  • Las reservas `cancelled` o `waitlist` no ocupan capacidad en el cálculo.
  • Las asignaciones fijas o ya aplicadas bloquean recursos; las seleccionadas automáticamente se envían como referencia previa.
  • En público, la ocurrencia debe ser visible públicamente y pertenecer al org/location de la ruta.
  • No documentar `table_type_id` ni `table_type_mode` como filtros fuertes del motor: en el runtime inspeccionado solo ayudan a calcular coincidencia en la respuesta.

Resultado esperado

El equipo obtiene una lista de horarios viables para la reserva, con señales de calidad del optimizador y una salida operativa cuando no hay disponibilidad. La base de datos no cambia hasta que el flujo posterior crea o actualiza la reserva.

Artículos relacionados