Перенос повторяющейся записи: один визит или будущая серия

Выберите область изменения до редактирования

У просьбы «перенесите запись» есть разные смыслы: изменить один визит, всю серию либо выбранный визит и последующие. Уточните, что именно подтверждено клиентом. Дата обращения сама по себе не определяет границу, а изменение одного блока календаря не доказывает, что изменились остальные.

В справке Google Calendar при редактировании повторяющегося события предусмотрен выбор событий серии, к которым применяется обновление. Это подтверждает важность области действия, но не гарантирует одинаковые варианты интерфейса и обработки исключений у всех систем. Google: recurring event.

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

Разделите правило серии и отдельное обязательство

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

Сохраните исходную позицию экземпляра в серии отдельно от его текущего времени. Google Calendar API использует recurringEventId для связи с серией, а originalStartTime обозначает исходный слот и позволяет идентифицировать экземпляр даже после переноса. Google: recurring instances.

Для бизнес-процесса полезен устойчивый идентификатор самого обязательства. Технический идентификатор календарного события может измениться при поддерживаемом способе перестройки серии. Поэтому связь с заказом, согласованием и результатом визита не должна зависеть только от текста даты.

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

Определите судьбу исключений заранее

Для будущей части можно сохранить индивидуальные исключения, пересмотреть их вместе с новым правилом или временно исключить из массовой правки до отдельного согласования. Универсального правильного варианта нет. Главное, чтобы он был выбран явно и показан до применения.

Отмена особенно важна. Она означает принятое решение по определённому экземпляру, а не просто отсутствие строки в списке. Повторное развёртывание правила не должно считать пустое место новым свободным обязательством и создавать отменённый визит заново.

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

Учебный пример: шесть визитов и два исключения

Все записи условные, по 60 минут, время UTC. Исходная серия содержит шесть понедельников 2026 года: 2, 9, 16, 23 и 30 ноября, затем 7 декабря. Начало каждого по правилу — 09:00. Обозначим обязательства O1–O6 в таком порядке.

Ранее O3 с исходным слотом 16 ноября 09:00 отдельно перенесли на 17 ноября 11:00. O4, соответствующий 23 ноября, согласованно отменён. Остальные сохраняют исходное время. В истории шесть обязательств: пять активных и одно отменённое.

Теперь клиент согласовал новое начало 10:00 с O3 и далее, сохранив оба индивидуальных исключения. Граница относится к исходной позиции O3, а не к его нынешней дате 17 ноября. Предварительный результат должен выглядеть так:

• O1 и O2 остаются 2 и 9 ноября в 09:00.
• O3 сохраняет индивидуальный перенос на 17 ноября в 11:00.
• O4 остаётся отменённым, новая запись на 23 ноября не появляется.
• O5 переходит на 30 ноября в 10:00.
• O6 переходит на 7 декабря в 10:00.

Проверка состава: две прежние позиции плюс четыре позиции будущей части дают шесть исходных обязательств. В будущей части три активных и одно отменённое. Итого 2 + 3 = 5 активных визитов, или 300 минут плановой услуги. Перенос часов не создаёт дополнительный визит.

Если просто оставить первые два и создать четыре новых активных события, получится шесть активных визитов и 360 минут. Разница 60 минут возникла из восстановления отменённого O4. Общий вид аккуратной недельной сетки скрывает ошибку: требуется сверка с исключениями.

Это собственная модель сохранения согласованных исключений, а не обещание поведения Google Calendar или SABSUS. Если клиент отдельно согласует изменить O3 вместе со всеми, новый результат будет другим и должен иметь новое основание.

Почему фильтр по текущей дате может ошибиться

Рассмотрим независимую вариацию: O2 с исходным слотом 9 ноября ранее перенесён на 20 ноября. При выбранной границе «начиная с исходного O3» O2 по-прежнему относится к прежней части, хотя фактически состоится позже 16 ноября.

Фильтр «все события с текущим началом после 16 ноября» захватит O2 лишний раз. Обратная ошибка возможна для будущего исходного экземпляра, перенесённого раньше границы. Поэтому условия массовой правки должны обозначать, сравнивается исходная позиция, текущая дата или иной согласованный признак.

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

Проверьте ресурсы и согласования каждого результата

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

Решите, что делать при частичной выполнимости: оставить всю правку предварительной или согласовать только названные даты. Нельзя молча подтвердить половину серии и представить это как полный перенос. До завершения изменения действующий вариант должен оставаться однозначным для клиента и команды.

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

Что хранить и как разбирать сбой

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

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

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

Приёмочный чек-лист

1. Перед правкой явно выбраны один экземпляр, вся серия или будущая часть.
2. Граница указывает нужную исходную позицию либо другое согласованное основание.
3. O1 и O2 в основном примере сохраняют прежнее время.
4. O3 сохраняет 17 ноября 11:00 согласно выбранной политике.
5. O4 не появляется заново после массового изменения.
6. O5 и O6 получают 10:00 и проходят проверку ресурсов.
7. Шесть обязательств дают пять активных визитов и 300 минут.
8. Перенесённый через границу O2 не захватывается ошибочным фильтром.
9. Частичный сбой и повтор запроса не создают дубли будущей части.
10. Клиент и администратор находят одну действующую версию каждой записи.

Для SABSUS обсудите сценарии через запись, календарь и заказы. Изменение будущей части, сохранение исключений и связь технических событий с обязательствами нужно подтвердить в конфигурации.

Частые вопросы

Можно изменить только один визит без новой серии?

Это зависит от поддерживаемого механизма исключений. Бизнес-результат должен сохранить остальные визиты и связь изменённого экземпляра с исходным.

Отменённый визит нужно создавать по новому правилу?

В приведённой политике нет. Его отмена сохраняется, пока отдельное согласованное решение не изменит этот исход.

Перенос будущей части должен менять прошлые визиты?

Нет в описанном сценарии. История прежних договорённостей и результатов остаётся, даже если техническое представление серии меняется.

Источники

• Google Calendar Help: recurring event — выбор области изменения.
• Google Calendar API: recurring events — экземпляры, исключения и исходная позиция.

Проверено 9 октября 2026 года. Серия и правила сохранения исключений учебные.