Проверка набора перед запуском занятия

Запишите объект условия до настройки

Владелец мастер-класса решил проводить конкретное занятие при достаточном наборе. Администратору передали только число «6». Без остального условия это неполное задание: неизвестны дата, допустимое состояние заявки и момент проверки. Прежде чем менять настройки, составьте короткую карточку решения.

В нашей учебной карточке указаны занятие E24, дата 24 октября 2026 года, шесть подтверждённых мест и проверка 22 октября в 15:00 UTC. Считать нужно места именно E24. Шесть — заранее заданный организационный порог примера, а не рассчитанная безубыточность, требование безопасности или рекомендация для любого бизнеса.

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

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

Проверьте смысл поля в выбранной системе

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

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

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

Три небольших заказа и одно занятие

Все записи ниже вымышлены. В установленном срезе подтверждены A на два места, B на два и C на два: 2 + 2 + 2 = 6. Порог занятия достигнут. Но если вместо него настроить минимум три места в каждом заказе, ни одна из этих покупок не пройдёт такое правило. Суммирование разных заказов не исправляет проверку, применённую к каждому отдельно.

Теперь изменим один исходный факт: до контрольного срока C уменьшилась до одного подтверждённого места. Получается 2 + 2 + 1 = 5. В отдельном списке четыре человека выразили интерес. Для нашего правила это по-прежнему пять подтверждений, а не девять. Неподтверждённый интерес показываем рядом, без прибавления к результату.

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

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

Сохраните решение на контрольный момент

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

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

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

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

Передайте администратору проверяемый набор

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

• В основной версии A–C итог равен шести, во второй — пяти; история C не добавляет ещё два места.
• Заявка на другой день с тем же названием мастер-класса не входит в E24.
• Строка без понятного статуса попадает на проверку, а не получает подтверждение автоматически.
• Событие 15:07 меняет текущий список, но не сохранённый результат 15:00.
• Исключение содержит автора и причину; исходное правило остаётся доступным.
• Команда видит, какое решение принято, кому предстоит действие и что ещё не выполнено.

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