Cómo ejecutar la optimización de reservas
Genera o recupera disposiciones propuestas para una ocurrencia de servicio, con alternativas, score, objetivo, desdobles y asignaciones visibles antes de aplicar cambios.
En este artículo
La optimización de reservas trabaja sobre una ocurrencia completa de servicio. Antylogic carga el plano, las mesas, las combinaciones, las reservas confirmadas y las asignaciones existentes para proponer distribuciones alternativas sin sustituir todavía lo guardado.
En el flujo de Marea Gran Via, el responsable abre Configuraciones, entra en Disposiciones propuestas y revisa el modal de soluciones. La acción puede reutilizar una corrida fresh o generar una nueva, pero aplicar una solución pertenece a otro paso.
Antes de empezar
- Estar en el detalle de una ocurrencia de reservas de tipo servicio dentro de la ubicación activa.
- Tener `reservation:manage` para abrir Configuraciones en la pantalla y que no haya envío en curso.
- Tener una ocurrencia con `layout_id` y `optimization_config_id` resueltos.
- La configuración de optimización debe existir, tener settings JSON válidos y el optimizador backend debe estar configurado.
- El backend exige `reservation-automatic:use` y acepta `optimization:view`, `reservation:manage` u `optimization:manage` para ejecutar la corrida.
Instrucciones
- 1.
Abre la ocurrencia de servicio
Entra en `/:orgId/:locationId/reservations/:occurrenceId` para revisar el servicio que quieres organizar. La optimización se calcula para toda la ocurrencia, no para una reserva individual.
- 2.
Abre Configuraciones
Pulsa Configuraciones en el detalle de la ocurrencia. Si el usuario no tiene permiso o hay un envío en curso, la pantalla no permite acceder a la opción.
- 3.
Selecciona Disposiciones propuestas
La aplicación cierra el menú y solicita una corrida de optimización. Si el servicio está en modo manual, la caché no está fresh o falta el último run, fuerza una corrida nueva; si existe una corrida fresh, puede reutilizarla.
- 4.
Espera el cálculo o la recuperación
El backend valida permisos, feature, ocurrencia, evento de tipo service, plano y configuración. Después carga mesas, combinaciones, reservas y asignaciones existentes para construir el snapshot del optimizador.
- 5.
Revisa las alternativas
Cuando hay soluciones, se abre el modal con la alternativa seleccionada o la primera disponible. Compara Score, Objetivo, desdobles usados, reserva, mesa y horario propuesto antes de decidir el siguiente paso.
- 6.
Continúa sin persistir cambios
Ejecutar optimización solo genera o recupera propuestas. Aplicar una solución o precargar el cronograma son acciones separadas cuando el operador quiera persistir asignaciones.
Validaciones y límites
- Si falta `occurrenceId` u `optimization_config_id`, la UI muestra un aviso y no llama al endpoint.
- `POST /api/app/{orgId}/{locationId}/service-occurrences/{occurrenceId}/optimization/runs` acepta body vacío o `{ force: boolean }`.
- El plano debe existir, pertenecer a la misma ubicación y la configuración de optimización debe parsear como JSON válido.
- El backend no ejecuta una corrida nueva si el optimizador no tiene `BaseURL` configurado.
- Con caché fresh y `force` false, el backend puede devolver el resumen de la corrida existente sin llamar de nuevo al motor.
- Si la respuesta no contiene soluciones, la UI informa de que no hay soluciones aplicables y no abre el modal.
- Si el motor falla, el run queda `failed` y la caché, `failed`. Solo un fallo determinista (petición rechazada con 400, secreto mal configurado con 401 o una respuesta que el backend no puede interpretar) pasa el servicio a modo manual y registra `optimization_last_error_code` como `optimize_failed`. Una inviabilidad demostrada (422 `infeasible`) registra `optimizer_infeasible` y un fallo transitorio (503 `solver_timeout` o `auth_unavailable`, 500, red o plazo agotado) registra `optimizer_unavailable`: en esos dos casos el modo no cambia y la siguiente pasada vuelve a calcular.
- Una corrida exitosa marca la caché como fresh y registra `optimization_last_run_id`, pero no escribe `reservation_table_assignments` persistidas.
- No se encontró una validación backend que bloquee esta ejecución para ocurrencias pasadas.
Resultado esperado
El responsable de sala ve propuestas de distribución de mesas para el servicio, con métricas y asignaciones revisables, mientras las asignaciones guardadas permanecen intactas hasta que se use una acción posterior de aplicación o cronograma.