Переносы и отмены в серии записей: как изменить отдельный визит

Правило описывает повторение: например, каждую среду в 18:00 до конца месяца. Экземпляр — конкретное посещение в одну из сред. Перенос этого экземпляра на четверг не обязан менять правило. Иначе просьба одного клиента может внезапно сдвинуть все последующие занятия.

В стандарте iCalendar RFC 5545 свойство RECURRENCE-ID обозначает конкретный экземпляр повторяющегося события и сохраняет его исходную позицию даже при переносе. EXDATE задаёт исключаемые даты. Это полезная модель идентичности для интеграций, но наличие календаря в продукте само по себе не доказывает поддержку этих свойств.

Внутри системы нужны устойчивая связь с серией, исходное плановое время и актуальный интервал. Если искать экземпляр только по новому началу, повторная генерация легко создаст исходную среду заново. Клиент увидит четверг в сообщении, а администратор — одновременно среду и четверг в расписании.

Сначала определяют экземпляр и проверяют возможность его изменения: визит может уже завершиться или находиться в процессе обслуживания. Затем рассчитывают новый интервал с нужным специалистом, кабинетом и вместимостью. Само наличие свободного места в обычной сетке не означает, что оно подходит для полной длительности переноса.

Подтверждение должно связывать освобождение прежнего времени и занятие нового. Если новое место уже занял другой клиент, операция сообщает об отказе, а исходный визит не исчезает. Повторное нажатие или повторная доставка команды не должны создавать ещё один экземпляр: у операции нужна защита от повторного выполнения.

Сохранённое исключение показывает новое время и связь с исходным посещением. Если расписание позже расширяют на следующий месяц, существующие исключения сохраняются. Для внешнего календаря отправляется корректное обновление конкретного события по поддерживаемому контракту, а не независимое приглашение без объяснения судьбы исходного.

Удаление строки из календаря не всегда равно отмене экземпляра. Если программа снова разворачивает правило «каждую среду», она может восстановить удалённую среду. Поэтому отмену хранят как явное исключение или статус с устойчивой связью с серией. Пользователь вправе ожидать, что согласованная отмена переживёт обновление расписания.

Пример: клиент отменил занятие 14 октября, а позже администратор продлил серию на ноябрь. Проверка должна подтвердить, что 14 октября не появилось снова и на него не создано напоминание. Повторная отправка той же отмены не должна второй раз менять баланс пакета или освобождать места сверх фактически занятых.

Восстановление отменённого посещения — отдельное действие с повторной проверкой доступности. Исходное место мог занять другой клиент. Нельзя просто убрать исключение и считать, что бронь автоматически вернулась: сначала нужно убедиться, что полный интервал и все обязательные ресурсы доступны сейчас.

Сообщение об изменении одного визита должно содержать старую и новую дату, актуальное время, место и дальнейшее действие. Напоминание на прежний интервал отменяют или обновляют. Остальные участники серии не должны получать сообщения, если их посещения не изменились; для групп заранее определяют, кто является получателем.

Баланс абонемента не следует менять только потому, что время стало другим. Отмена, неявка, перенос и состоявшееся занятие могут иметь разные правила списания, заданные бизнесом. В интеграции храните отдельный результат финансовой или пакетной операции и связь с экземпляром, чтобы повтор команды не дал второе списание.

На демонстрации MySlot попросите воспроизвести одну отмену и один перенос, затем продлить серию. Проверьте календарь, сообщения, связанные задачи и баланс в вашей конфигурации. Если исключения ведутся внешним сервисом, уточните, какая система является источником актуального расписания и как разрешаются расхождения.