Следующий сервис: считать срок от плана или от выполнения?

Два правила решают разные задачи

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

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

Microsoft Asset Management явно различает повторение от плановой или стартовой даты и повторение от последнего завершённого наряда. Для второго варианта используется фактическое окончание подходящей работы по определённому виду обслуживания. Microsoft Learn: Maintenance plans.

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

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

План хранит правило повторения. Событие представляет один ожидаемый результат, например «обслуживание объекта за июнь». Наряд описывает выполняемую работу. Запись резервирует время исполнителя. Одно событие может потребовать нескольких визитов, но это не несколько новых периодов обслуживания.

Создание наряда заранее также не означает, что визит уже назначен. В Dynamics 365 Field Service повторяющийся график соглашения формирует даты обслуживания; статус обработанной даты показывает, что наряд создан. Дальнейшее планирование наряда описано отдельно. Microsoft Learn: Create work orders from an agreement.

При переносе сохраняйте идентификатор сервисного события. Новый номер визита не должен создавать второй платёжный цикл или дополнительное обязательство без отдельного основания.

Какие поля нужны для воспроизводимого расчёта

В карточке плана полезно хранить:

• Клиента, объект или оборудование и конкретный вид услуги
• Тип основания: фиксированная сетка либо подтверждённое выполнение
• Стартовую дату, интервал, единицу периода и часовой пояс
• Правило конца месяца, выходного дня и допустимого окна
• Версию плана, дату её вступления в силу и согласующего
• Период действия, остановку, паузу и исключения
• Последнее подходящее выполнение с его фактическим временем
• Горизонт генерации задач и ответственного за отклонения

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

Слова «каждый месяц» требуют дополнительного определения. Это может быть конкретное число, последний день месяца или заданный день недели. Интервал в 30 суток создаёт другую последовательность. Без явного выбора два корректных по-своему календаря будут расходиться.

Учебный пример: как накапливается сдвиг

Рассмотрим условную административную услугу с интервалом 28 суток. Часовой пояс — UTC, все сравниваемые события происходят в одно и то же время суток. Исходное выполнение — 4 мая 2026 года. Модель выбирают до запуска.

Фиксированная сетка от 4 мая даёт 1 июня, 29 июня и 27 июля. Проверка: между соседними датами по 28 суток. Обслуживание, ожидавшееся 1 июня, фактически завершено 5 июня. При сохранении сетки следующий срок остаётся 29 июня.

При модели от завершения следующая дата после 5 июня — 3 июля: 5 июня + 28 суток. Допустим, следующую работу фактически завершили 6 июля. Новый срок по этой модели — 3 августа: 6 июля + 28 суток. В фиксированном календаре очередная дата была бы 27 июля. Разница составляет семь суток.

Здесь первые четыре дня задержки и следующие три дня задержки относительно сдвинутого срока накопились в семидневное изменение календаря. Это не ошибка арифметики; это последствие выбранного основания. Если бизнес рассчитывает обслуживать объекты по устойчивым маршрутам, такой сдвиг нужно учитывать до обещания регулярного дня клиенту.

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

Конец месяца: сохраняйте исходное правило

Учебное правило «последний день каждого месяца» для начала 2026 года даёт 31 января, 28 февраля и 31 марта. Если после февраля просто прибавить месяц к полученному числу 28, можно ошибочно перейти на 28 марта. Чтобы сохранить замысел, нужен исходный признак «конец месяца», а не только последняя вычисленная дата.

Для правила «31-е число, а при его отсутствии — последнее число» отдельно определите, возвращается ли последовательность к 31-му в следующем подходящем месяце. Проверьте февраль високосного года и календарь праздников. Перенос визита на рабочий день не обязан менять исходный срок самого события: это два поля с разным смыслом.

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

Пропуск, отмена и позднее закрытие

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

Поведение готовых систем может различаться. В Odoo Project новая повторяющаяся задача создаётся после перевода предыдущей в Done или Canceled; новый срок выводится из установленного периода повторения. Odoo 19: Recurring tasks. Поэтому само название «повторяющаяся задача» не подтверждает подходящую вашему процессу логику отмены и основания даты.

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

Не допускайте двух следующих событий

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

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

Чек-лист приёмки регулярного сервиса

1. Перенесите визит на четыре дня: следующий срок соответствует выбранному основанию.
2. Отмените только запись: сервисное событие сохраняется до отдельного решения.
3. Завершите неподходящий вид работы: он не меняет дату нужного плана.
4. Повторите генерацию: второй экземпляр того же периода не появляется.
5. Проверьте 31 января, февраль и март: исходное правило сохраняется.
6. Внесите факт задним числом: новая дата объяснима, подтверждённые визиты не меняются молча.
7. Измените периодичность: версия и список затронутых событий доступны.
8. Остановите план: новые периоды не создаются, старые обязательства не исчезают.
9. Проверьте один результат с двумя выездами: завершено одно сервисное событие.

Сквозной контекст объекта и повторного обращения разобран в руководстве HVAC-сервиса. Для SABSUS проверяйте выбранные правила через заказы, задачи и календарь сотрудников. Приведённая логика является спецификацией проверки, а не обещанием встроенного генератора для любой конфигурации.

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

Какое основание лучше для всех услуг?

Универсального основания нет. Фиксированный план поддерживает согласованную календарную сетку; отсчёт от выполнения поддерживает интервал после факта. Выбор зависит от реального обязательства.

Можно считать следующим сроком дату последней оплаты плюс месяц?

Только если именно такое правило явно принято для конкретного процесса. Обычно оплата и выполнение услуги описывают разные события; подменять одно другим нельзя.

Нужно ли автоматически закрывать просроченный период при создании нового?

Нет. Новый период не доказывает выполнение старого. Просроченное событие требует результата или отдельного решения с причиной и ответственным.

Источники

• Microsoft Learn: Maintenance plans — плановые основания и последнее выполнение.
• Microsoft Learn: Work orders from agreements — дата обслуживания и созданный наряд.
• Odoo 19: Recurring tasks — событие создания очередной задачи.

Источники проверены 9 октября 2026 года. Даты и примеры учебные.