Actualizar servicios futuros de una serie recurrente
Edita una ocurrencia futura de un servicio recurrente para que los cambios se apliquen desde esa fecha en adelante. Antylogic conserva la serie anterior hasta justo antes de la ocurrencia elegida y crea una nueva serie de servicio para el tramo futuro.
En este artículo
Usa esta guía cuando el horario, la visibilidad, la dotación, el plano, la carta o la configuración de un servicio recurrente cambian a partir de una fecha concreta en Marea Gran Via.
La opción `Servicios futuros` no crea una excepción individual. Divide la recurrencia: el servicio original queda cerrado antes de `occurrence_start` y el nuevo tramo se guarda como otro servicio recurrente.
Antes de empezar
- Existe un servicio recurrente de tipo `service` con recurrencia activa.
- La edición se abre desde una ocurrencia concreta y la URL incluye `occurrenceStart`.
- La ocurrencia seleccionada todavía no ha empezado según la hora de referencia del servicio.
- El usuario tiene `service:view` para cargar el servicio y `service:manage` para guardar el cambio.
- Si se modifican horarios de empleados, el usuario tiene `staff-schedule:manage`.
- Si el servicio queda como `public`, conserva `layout_id` y `catalog_id` válidos.
Instrucciones
- 1.
Abrir la ocurrencia recurrente
Desde el calendario de servicios, selecciona una ocurrencia futura del servicio recurrente. La pantalla de edición debe abrirse con `kind=service` y `occurrenceStart`; si falta esa fecha, Antylogic no puede partir la serie desde el punto correcto.
- 2.
Revisar y modificar el servicio
Actualiza solo los datos que deban cambiar desde esa fecha: horario, recurrencia, visibilidad, plano, carta, optimización, roles requeridos u horarios de empleados. En servicios `public`, el plano y la carta siguen siendo obligatorios.
- 3.
Guardar y elegir el alcance
Pulsa `Guardar`. Cuando aparezca el modal `Editar servicio recurrente`, elige `Servicios futuros`. La opción `Solo este servicio` pertenece al flujo de excepción individual y no a esta acción.
- 4.
Aplicar el split futuro
Antylogic envía `action=update`, `scope=future`, el `occurrence_start` de la ocurrencia seleccionada y el bundle actualizado. El backend trunca la serie original y crea el nuevo tramo recurrente.
- 5.
Comprobar el calendario
Al volver al calendario, revisa que las ocurrencias anteriores mantienen su configuración y que el tramo futuro refleja el cambio aplicado. Si aparecen advertencias operativas, revísalas antes de seguir ajustando reservas o mesas.
Validaciones y límites
- El evento original debe ser `kind=service` y tener `calendar_recurrence.frequency`.
- `occurrence_start` es obligatorio, debe pertenecer a la serie y no puede estar en una ocurrencia pasada o ya iniciada.
- El formulario bloquea título vacío, rango horario inválido, requisitos duplicados y horarios de empleados inválidos.
- Un servicio `public` requiere `layout_id` y `catalog_id` válidos; un servicio `internal` no debe presentarse como reservable públicamente.
- No se puede convertir a `internal` un tramo futuro con reservas activas incompatibles.
- No se puede cambiar horario o recurrencia si deja reservas activas fuera de la nueva ventana del servicio.
- La respuesta de `scope=future` usa `original_id` y `future_id`; no documentes esta acción como creación de `calendar_override`.
Resultado esperado
La serie original queda truncada hasta justo antes de `occurrence_start`, el tramo futuro se crea como un nuevo servicio recurrente identificado por `future_id`, y el calendario invalida sus datos para mostrar las ocurrencias futuras sincronizadas.