Перейти к содержимому

Правила доступности ресурса

Функция доступна в production для ресурсов Daily и Hourly. Правила онлайн-окна Public Booking не входят в эту статью.

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

Для Daily доступны:

  • закрытые периоды;
  • минимальное число ночей по дате заезда;
  • минимальное число ночей при пересечении периода;
  • дни, когда бронирование не может начинаться;

Для Hourly доступны закрытые интервалы. Минимальные ночи и запрет дня заезда к Hourly не применяются. OneTime не входит в этот модуль.

Правило относится к конкретному ресурсу. Наследование от локации, владельца или группы ресурсов в принятую модель не входит.

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

Для Daily закрываются занятые ночи: выезд в первый закрытый день разрешён. Для Hourly нарушением является любое пересечение с закрытым интервалом. Повторяющиеся недельные закрытия в принятую модель не входят.

Закрытый период отличается от корректировки количества. Корректировка меняет физическую ёмкость, а закрытие выражает бизнес-правило и может иметь внутреннюю причину, которую гость не видит.

Минимальное проживание относится только к Daily и считается календарными ночами. Время суток, цена, billing step и буфер на него не влияют.

Если одновременно применимы несколько правил минимального проживания, действует самое строгое — наибольшее число ночей.

Запрет заезда проверяет только дату начала. Он не запрещает выезд и не создаёт отдельное правило closed to departure.

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

  • в Public Booking нарушение правила является блокировкой без раскрытия внутренней причины;
  • в ручной работе владельца и в Customer Proposal нарушение является предупреждением, которое сотрудник может явно подтвердить;
  • физическая нехватка количества, конфликт зависимостей, неактивный ресурс, неверное количество или финансовая блокировка всегда остаются жёстким запретом и не обходятся подтверждением.

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

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