Ejecutar optimizador de ocurrencia
Lanza una corrida de optimización para una ocurrencia de servicio o reutiliza la última si la caché está fresca. El resultado son propuestas de asignación de mesas para revisar; esta acción no confirma cambios persistentes en las reservas.
En este artículo
Esta guía explica el flujo operativo desde el detalle de una ocurrencia de servicio: abrir Configuraciones, pedir Disposiciones propuestas y revisar las alternativas que devuelve el optimizador.
El caso está pensado para responsables de reservas y jefes de sala que necesitan preparar la distribución antes del servicio sin convertir la propuesta en una asignación definitiva.
Antes de empezar
- Sesión iniciada con organización y ubicación seleccionadas; en el demo ES, usar Grupo Marea Demo y Marea Gran Via.
- Abrir una ocurrencia de evento tipo servicio con `layout_id` y `optimization_config_id` resolubles.
- El plano de la ubicación debe existir, pertenecer a la misma ubicación y tener mesas; las combinaciones se incluyen si están configuradas.
- La configuración de optimización debe existir y sus ajustes deben poder leerse.
- El usuario debe tener acceso de gestión de reservas en la UI; backend exige permisos de optimización o reservas y `reservation-automatic:use`.
- Si no hay una caché fresca reutilizable, el servicio externo de optimización debe estar configurado para crear una corrida nueva.
Instrucciones
- 1.
Abrir la ocurrencia de servicio
Desde el calendario o un enlace profundo, entra en el detalle de la ocurrencia de reservas. La pantalla carga el servicio, reservas, asignaciones, cronograma, layout y configuración de optimización.
- 2.
Solicitar Disposiciones propuestas
Abre Configuraciones y pulsa Disposiciones propuestas. Si falta la configuración de optimización, no hay `occurrenceId` o el usuario no puede gestionar reservas, la acción no debe presentarse como disponible.
- 3.
Ejecutar o reutilizar la corrida
La UI decide si envía una ejecución forzada o permite reutilizar la última. Si el modo está en manual, la caché no está fresca o falta `optimization_last_run_id`, se pide una corrida nueva; si la caché está fresca y `force=false`, se devuelve la última.
- 4.
Esperar el cálculo
Cuando hace falta una corrida nueva, Antylogic prepara un snapshot con layout, mesas, combinaciones, reservas activas y asignaciones existentes. Las reservas canceladas y en lista de espera no se envían al optimizador.
- 5.
Revisar alternativas
Si el optimizador devuelve soluciones aplicables, la UI abre el modal de propuestas, selecciona la alternativa indicada o la primera disponible y permite comparar métricas y asignaciones por reserva.
- 6.
Precargar sin persistir
El operador puede precargar una propuesta en el cronograma para revisar la distribución. La persistencia definitiva de asignaciones pertenece a la acción separada de aplicar solución.
Validaciones y límites
- La creación de corrida usa `POST /api/app/{orgId}/{locationId}/service-occurrences/{occurrenceId}/optimization/runs`; otros métodos no aplican a esta creación.
- El body puede ir vacío; si incluye datos, solo se usa `force?: boolean`. El `occurrenceId` se toma de la URL.
- La ocurrencia debe existir en la misma `locationId` del contexto y su evento asociado debe ser `kind=service`.
- `layout_id` y `optimization_config_id` deben resolverse desde la ocurrencia o el evento.
- `force=true` fuerza una corrida nueva aunque exista una corrida fresca; `force=false` permite reutilizar la última corrida fresca.
- Si `alternatives` llega vacío, la corrida puede terminar como `succeeded` con `solutions_count=0`; la UI muestra aviso y no abre el modal de soluciones.
- Si el optimizador falla, el run queda `failed` y la caché, `failed`. Solo un fallo determinista (400 `bad_request`, 401 `unauthorized` o una respuesta que el backend no puede interpretar) pasa la ocurrencia a modo manual y guarda `optimization_last_error_code=optimize_failed`. Con una inviabilidad demostrada (422 `infeasible`) se guarda `optimizer_infeasible`, y con un fallo transitorio (503 `solver_timeout` o `auth_unavailable`, 500, red o plazo agotado), `optimizer_unavailable`; en esos casos el modo no cambia y la siguiente pasada vuelve a calcular.
- `Precargar en cronograma` no persiste `reservation_table_assignment`; la confirmación definitiva usa `/optimization/runs/{runId}/apply`.
Resultado esperado
La ocurrencia queda con propuestas comparables para revisar en sala. Si la corrida termina correctamente, se actualiza la caché de optimización y se limpian errores; las reservas no cambian de mesa hasta aplicar una solución en el flujo correspondiente.