2.4.1 Условия создания

Направление работ: Back

Код раздела: 2.4.1 Объекты и предложения > Правила работы с заказами > Условия создания

Статус: Готов

Ответственный: Панкова Л.А.

Версия: 0.1

Обновлено: 10.07.26

1. Назначение

Условия создания — набор правил, определяющих допустимые параметры заказа в процессинговом статусе для привязки его к площадкам или услугам.

Условия создания работают по единому принципу правил работы с заказами: привязываются к объектам и площадкам через наследование стандартных системных правил из раздела Back 8.4 Параметры системы.

2. Ключевые понятия

Условия создания — правила, определяющие допустимые параметры заказа в процессинговом статусе.

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

Опции — характеристики предложения, для которых может уточняться действие условия создания.

3. Scope

Входит

S1 Условия создания: состав проверок, определяющих допустимые параметры заказа.

S2 Минимальная длительность заказа: минимальная продолжительность заказа и условия применения правила.

S3 Строгие промежутки: допустимые часы начала и окончания заказа и условия применения правила.

S4 Время до начала заказа: ограничение срока резервирования и возможность отправки заявки после его наступления.

S5 Совместимость условий создания: использование нескольких правил при отсутствии противоречий между их параметрами.

Не входит

4. Требования

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

ID	Требование	Комментарий	Тип требования	Вес	Статус
S1: BR2.4.1-1	Условия создания должны состоять из общих параметров и трех проверок, каждая из которых является отдельным набором правил	Параметры: - Название; - Описание; - Объекты; - Площадки; - Запретить бронирования день в день; - Признак “По умолчанию”; - Опции — перечень опций, на которые распространяется условие (если не задан — все опции); - Диапазон опции — число или диапазон в формате «X-X» (если не задан — любой диапазон); - Период действия — календарный период работы условия создания (если не задан — условие действует всегда). Проверки: - Минимальная длительность заказа — определяет минимально возможную длительность заказа; - Строгие промежутки — определяют конкретные часы, на которые можно создать заказ; - Время до начала заказа — определяет время, по истечении которого заказ не может быть зарезервирован. Все проверки применяются к заказу в процессинговом статусе, который раскрывается в Back 3.2 Процессинг заказов.	Бизнес	1	Частично \ OQ2.4.1-1, OQ2.4.1-14
S2: BR2.4.1-2	Условия создания должны содержать список правил, определяющих минимально возможную длительность заказа в процессинговом статусе	Минимальная длительность заказа — обязательное системное правило, без которого невозможно сохранить условия создания. Каждая запись содержит: - Минимальная длительность — значение минимальной длительности в часах (минимальное значение и значение по умолчанию — 1 час); - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни); - Время действия — один или несколько диапазонов (если не задано — весь день); - День в день — признак, активирующий правило, если дата и время создания заказа совпадают с датой заказа (если не задан — условие действует всегда). Применение к заказу раскрывается в Back 3.2 Процессинг заказов, опции — в Back 8.2.1 Сферы и Опции, обязательное системное правило — в Back 8.4 Параметры системы.	Бизнес	1	Частично \ OQ2.4.1-2, OQ2.4.1-3, OQ2.4.1-4, OQ2.4.1-5, OQ2.4.1-6, OQ2.4.1-7, OQ2.4.1-8
S3: BR2.4.1-3	Условия создания могут содержать список правил, определяющих конкретные часы, на которые можно создать заказ в процессинговом статусе	«Строгие промежутки» — необязательное правило. Каждая запись содержит: - Часы — перечень доступных часов в качестве времени начала и окончания заказа; - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни); - День в день — признак, активирующий условие, если дата и время создания заказа совпадают с датой заказа (если не задан — условие действует всегда). Применение к заказу раскрывается в Back 3.2 Процессинг заказов, опции — в Back 8.2.1 Сферы и Опции.	Бизнес	2	Частично \ OQ2.4.1-3, OQ2.4.1-7
S4: BR2.4.1-4	Условия создания могут содержать список правил, определяющих время, по истечении которого заказ не может быть зарезервирован	«Время до начала заказа» — необязательное правило. Каждая запись содержит: - Часов до начала — количество часов до начала заказа, по истечении которого активируется запрет на создание заказа (минимальное значение — 1); - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни); - Отправлять заявку — признак, активирующий возможность отправить заявку по истечении указанного в условии времени (по умолчанию не задан). Применение к заказу раскрывается в Back 3.2 Процессинг заказов.	Бизнес	2	Частично \ OQ2.4.1-9, OQ2.4.1-10, OQ2.4.1-11, OQ2.4.1-12
S5: BR2.4.1-5	Система должна допускать одновременное действие нескольких одинаковых или разных правил создания, если их параметры не противоречат друг другу	Правила могут определять разные условия создания на одно и то же время, день недели или период. Допускается: - Разная минимальная длительность — по дням недели и времени действия; - Минимальная длительность и строгие промежутки — могут комбинироваться; - Время до начала заказа — комбинируется с любыми другими условиями без ограничений, поскольку его действие не связано с конкретным временем в расписании площадки или услуги.	Системное	2	Частично \ OQ2.4.1-13

5. Открытые вопросы

Пин контекста. BRD 2.4.1 v0.1 · репозиторий booking-monorepo · commit 83423b21 / ветка main · дата сверки 20.07.2026 Якорь: src/services/booking.partner-management/src/ — PartnerZones.Domain/BookingRulesAggregate (модель правил), PartnerZones.Application/Commands/RuleSet + Queries/BookingRules (операции), PartnerZones.Application/Queries/Room/BookingAllowed (применение правил), PartnerZones.Persistence/BookingRules + DbInitializer.cs (хранение и схема БД). Дополнительно пройдены: src/services/booking.orders (создание заказа и заявки, вызов проверки), src/services/booking.prices (получатель уведомлений об изменении правил), src/libs/booking.domain.abstractions (общие объекты, контракты, события). Сводка: 20 вопросов (Open 12 · Закрывает PM 8 · Подтверждено 0) · отрезано находок обратного прохода: 5 (техническая обвязка вне предмета раздела — дублирующиеся ветки авторизации, неиспользуемые импорты, внутренности кэша и трекера изменений). Маршрутизация без сверки с гайдбуком (гайдбук на вход не передавался). Ни одно из пяти требований не подтверждено полностью. Правила бронирования вычисляются «на лету» в booking.partner-management, сервис заказов обращается к ним по gRPC и своей копии правил не хранит. Пути в доказательствах указаны от якоря src/services/booking.partner-management/src/, если не указано иное.

ID	Источник	Вопрос	Кому	Статус	Рекомендации	Итоговое решение
OQ2.4.1-1	Код BR2.4.1-1	Требование говорит: проверка минимальной длительности и запрет брони «день в день» должны применяться к каждому заказу. В коде обе проверки выполняются только тогда, когда вызывающая сторона просит проигнорировать правила бронирования. Логика признака перевёрнута, и все без исключения сценарии создания заказа передают «не игнорировать» — то есть в проде обе проверки не выполняются никогда: заказ короче минимальной длительности проходит, бронь «день в день» при выключенном режиме проходит. Работают только строгие промежутки и время до начала. \ перевёрнутое условие — `PartnerZones.Application/Queries/Room/BookingAllowed/BookingAllowedQueryHandler.cs:89,222`; все вызывающие передают «нет» — `src/services/booking.orders/src/Orders.Application/Commands/Orders/CreateOrder/CreateOrderCommandHandler.cs:280`, `.../CreateOrderWidget/CreateOrderWidgetCommandHandler.cs:363`, `.../CreateNonProcessingGroup/CreateNonProcessingGroupCommandHandler.cs:95`, `Orders.Infrastructure/Services/CalculationService.cs:99,138,205,211`	Разработка (Владислав)	Closed	Закрываю сам: завести дефект «условие применения проверок минимальной длительности и брони день в день инвертировано — правила не работают в проде» → тикет в Bitrix, наивысший приоритет раздела. Разблокирующий вопрос: пока признак перевёрнут, BR2.4.1-1 и BR2.4.1-2 не выполняются независимо от остальных правок. Связать с OQ2.4.1-8, OQ2.4.1-16, OQ2.4.1-19.	ОТ БИЗНЕСА: ок
OQ2.4.1-2	Код BR2.4.1-2	Требование говорит: признак «День в день» включает условие, когда дата создания заказа совпадает с датой заказа; если признак не задан — условие действует всегда. В коде признак сравнивается на точное совпадение: правило с непроставленным признаком применяется только к заказам не на сегодня, а к заказам на сегодня не применяется вовсе. То есть «не задан» означает не «всегда», а «только не сегодня». Чтобы правило работало и сегодня, и в другие дни, его нужно завести дважды. Так устроены все три вида правил. \ `BookingAllowedQueryHandler.cs:117,137,147,225,320,330`	Бизнес (Герман)	Open	(А) привести код к BRD: непроставленный признак = правило действует всегда (рекомендуется — так формулировка BRD читается однозначно и не требует заводить парные правила); (Б) привести BRD к коду: описать признак как трёхзначный выбор «только сегодня / только не сегодня». Ответ разблокирует OQ2.4.1-12 и OQ2.4.1-15.	ОТ БИЗНЕСА: А - привести код к БРД, вес доработки - 1
OQ2.4.1-3	Код BR2.4.1-2, BR2.4.1-3	Требование говорит: и правило минимальной длительности, и правило строгих промежутков должны уточняться перечнем опций и диапазоном опции в формате «X-X». В коде ни у одного из трёх правил условий создания нет ни опций, ни диапазона опции — ни в модели, ни в хранении, ни в проверке заказа. Более того, запрос «можно ли создать заказ» вообще не передаёт опции: он оперирует только площадкой, базой и датами, поэтому уточнить правило по опции технически невозможно без изменения контракта. При этом у соседних видов правил (правила отмены, платёжные фильтры) привязка к опции с диапазоном реализована полностью — механизм в системе есть, но к условиям создания не подключён. \ отсутствие в модели — `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/MinHours/MinRuleInfo.cs:11-22`, `src/libs/booking.domain.abstractions/.../BookingRules/StrictRule/StrictRuleInfo.cs:5-14`; отсутствие в хранении — `PartnerZones.Persistence/BookingRules/RuleSet/Models/MinHoursRuleJson.cs:3-16`, `.../StrictRuleJson.cs:3-15`, `.../HoursBeforeRuleJson.cs:3-8`; отсутствие в контракте проверки — `src/libs/booking.domain.abstractions/.../GRPC/BookingAllowed/BookingAllowedQuery.cs:8-44`; работающий аналог — `PartnerZones.Persistence/CancelRules/CancelRuleReadOnlyRepository.cs:44`, `PartnerZones.Persistence/PaymentFilters/Mappings/PaymentFiltersMapper.cs:49`	Бизнес (Герман)	Open	(А) подтвердить, что привязка к опциям нужна, и поставить в разработку по образцу правил отмены (рекомендуется — BRD называет опции в двух требованиях из пяти, и готовый механизм рядом); (Б) если сценария нет — убрать опции и диапазон опции из BR2.4.1-2 и BR2.4.1-3. Учесть объём: потребуется расширение контракта проверки, а не только модели. Связать с OQ2.4.1-18.	ОТ БИЗНЕСА: А - привести код к БРД, вес доработки - 3
OQ2.4.1-4	Код BR2.4.1-2	Требование говорит: минимальная длительность заказа имеет минимальное значение и значение по умолчанию — 1 час. В коде значение принимается как есть, без нижней границы и без значения по умолчанию: можно сохранить правило с минимальной длительностью 0 или отрицательной. Во всём разделе на уровне операций найдено только две проверки вообще — «не указана партнёрская зона» и «набор правил не найден»; проверок значений нет. \ `PartnerZones.Application/Commands/RuleSet/Create/CreateRuleSetCommandHandler.cs:101-104`; значение хранится без ограничений — `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/MinHours/MinRuleInfo.cs:11-22`; единственные существующие проверки — `CreateRuleSetCommandHandler.cs:60`, `Update/UpdateRuleSetCommandHandler.cs:66`	Разработка (Владислав)	Open	Закрываю сам: завести задачу «валидация минимальной длительности: не меньше 1 часа, по умолчанию 1» → тикет в Bitrix. Продуктового выбора нет — значение прямо задано в BRD. Делать одной задачей с OQ2.4.1-11.	ОТ БИЗНЕСА: ок, вес доработки - 1
OQ2.4.1-5	Код BR2.4.1-2	Требование говорит: минимальная длительность — обязательное системное правило, без которого создание заказов невозможно, и оно наследуется из системных параметров (раздел 8.4). В коде обязательность не проверяется: набор правил можно сохранить вообще без правил минимальной длительности. Наследование «стандартного системного правила» тоже не подтверждено: механизм копирования из сферного набора-образца есть, но команда, которая этот образец создаёт, помечена как неиспользуемая, а начального наполнения базы правилами по умолчанию не найдено за обход. Косвенно обязательность держится только на том, что при полном отсутствии набора правил у площадки бронирование запрещается. \ отсутствие проверки — `CreateRuleSetCommandHandler.cs:101-117`; запрет при отсутствии набора — `BookingAllowedQueryHandler.cs:59-66`; копирование из образца — `PartnerZones.Domain/BookingRulesAggregate/BookingRuleSetAggregate.cs:141-172`; неиспользуемая команда создания образца — `PartnerZones.Application/Commands/RuleSet/CreateDefault/CreateSphereRuleSetCommand.cs:15` (помечена «Obsolete: unused»); начальное наполнение — не найдено за обход `PartnerZones.Persistence/DbInitializer.cs`	Бизнес/Разработка	Open	(А) подтвердить обязательность и запретить сохранение набора без правила минимальной длительности, а также определить, откуда берётся значение по умолчанию для новой площадки (рекомендуется — сейчас площадка может остаться без правила молча); (Б) если обязательность обеспечивается разделом 8.4 — зафиксировать в BRD конкретный механизм наследования и поведение при пустом наборе. Сначала решение бизнеса, затем реализация.	ОТ БИЗНЕСА: А - привести код к БРД, вес доработки - 3. Из системных параметров берется ЗНАЧЕНИЕ минимальной длительности по умолчанию, чтобы сохранить условие создания. В рамках MVP можно оставить вшитое в предыдущем вопросе значение - 1 час.
OQ2.4.1-6	Код BR2.4.1-2	Требование говорит: период действия — календарный период работы условия создания; если не задан, условие действует всегда. В коде период у набора правил хранится и заполняется, но при проверке заказа не используется: правила выбираются только по площадке и признаку «не в архиве», дата заказа с периодом действия не сверяется. Набор правил с истёкшим или ещё не наступившим периодом продолжает ограничивать заказы. \ хранение периода — `PartnerZones.Persistence/BookingRules/RuleSet/Models/BookingRuleSet.cs:31,34`, `PartnerZones.Domain/BookingRulesAggregate/BookingRuleSetAggregate.cs:41`; выборка без учёта периода — `PartnerZones.Persistence/BookingRules/Repositories/BookingRuleSetRepository.cs:231-245`	Разработка (Владислав)	Closed	Закрываю сам: завести дефект «период действия набора правил не учитывается при проверке заказа» → тикет в Bitrix. Продуктового выбора нет: поле заведено и заполняется партнёром, но не влияет на результат — это скрытая ошибка, а не спорное поведение.	ОТ БИЗНЕСА: Этот вопрос должен быть закрыт в рамках Back 3.2
OQ2.4.1-7	Код BR2.4.1-2, BR2.4.1-3, BR2.4.1-4	Требование говорит: период действия задаётся у каждой записи правила — отдельно у минимальной длительности, у строгих промежутков и у времени до начала. В коде период существует только один на весь набор правил; у отдельных записей своего периода нет ни в модели, ни в хранении. Разные сроки действия для разных правил внутри одного набора задать нельзя — под каждый срок придётся заводить отдельный набор, а на площадку применяется только один набор (см. OQ2.4.1-13), поэтому обходной путь тоже не работает. \ период на наборе — `PartnerZones.Persistence/BookingRules/RuleSet/Models/BookingRuleSet.cs:31,34`; записи правил без периода — `PartnerZones.Persistence/BookingRules/RuleSet/Models/MinHoursRuleJson.cs:3-16`, `.../StrictRuleJson.cs:3-15`, `.../HoursBeforeRuleJson.cs:3-8`	Бизнес (Герман)	Open	(А) привести BRD к коду: описать период действия как свойство набора правил, а не отдельной записи (рекомендуется — набор и так является единицей привязки к площадке); (Б) привести код к BRD и добавить период каждой записи — дороже и усложняет разбор конфликтов. Выбор (А) осмыслен только вместе с решением по OQ2.4.1-13 о нескольких наборах на площадку. Зависит от OQ2.4.1-6.	ОТ БИЗНЕСА: А - БРД исправлен
OQ2.4.1-8	Код BR2.4.1-2	Проблема: в проверке минимальной длительности есть ветка отказа, которая не может выполниться никогда. Она вложена в блок, срабатывающий только при просьбе проигнорировать правила, но сама требует обратного — что игнорировать не просили. Условие взаимоисключающее, поэтому отказ «Минимальная длительность N ч. Текущая длительность M ч.» не показывается пользователю ни при каких настройках. \ `BookingAllowedQueryHandler.cs:265` (внутри блока, открытого на строке 222)	Разработка (Владислав)	Closed	Закрываю сам: завести задачу «недостижимая ветка отказа по минимальной длительности» → тикет в Bitrix. Чинить вместе с OQ2.4.1-1 — это следствие той же перевёрнутой логики; отдельная правка смысла не имеет.	ОТ БИЗНЕСА: ок, вес доработки - 1
OQ2.4.1-9	Код BR2.4.1-4	Требование говорит: у правила «время до начала заказа» есть признак «Отправлять заявку», разрешающий отправить заявку после того, как срок резервирования истёк. В коде такого признака нет ни в правиле, ни в команде создания, ни в хранении, и — что важнее — заявка проходит ту же самую проверку правил, что и заказ: при нарушении срока до начала создание заявки падает с той же ошибкой. То есть сценарий «после истечения срока бронировать нельзя, но заявку отправить можно» сейчас невозможен в принципе: заявка блокируется наравне с заказом. \ отсутствие признака — `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/HoursBefore/HoursBeforeInfo.cs:11-24`, `PartnerZones.Application/Commands/RuleSet/Create/CreateRuleSetCommand.cs:13`, `PartnerZones.Persistence/BookingRules/RuleSet/Models/HoursBeforeRuleJson.cs:3-8`; жёсткий отказ — `BookingAllowedQueryHandler.cs:124-128`; заявка проверяется тем же путём и падает при ошибке — `src/services/booking.orders/src/Orders.Application/Commands/Requests/CreateRequest/CreateRequestCommandHandler.cs:112-116`	Бизнес (Герман)	Open	(А) подтвердить сценарий «после истечения срока — не отказ, а заявка» и поставить в разработку (рекомендуется — S4 прямо описывает эту возможность, а сейчас правило работает только на запрет и закрывает поздний спрос); (Б) если сценарий не подтверждается — убрать признак «Отправлять заявку» из BR2.4.1-4 и соответствующую формулировку из S4. Объём больше, чем добавление поля: нужно развести проверку правил для заказа и для заявки.	ОТ БИЗНЕСА: реализовать после релиза, вес доработки - 3
OQ2.4.1-10	Код BR2.4.1-4	Требование говорит: дни недели в правиле «время до начала» — множественный выбор из семи вариантов; если не заданы — все дни. В коде у записи ровно один день недели: чтобы задать правило на будни, нужно завести пять отдельных записей, а варианта «все дни» не существует вовсе. Дополнительно при проверке берётся только первое подходящее правило на день, поэтому вторая запись на тот же день молча не сработает. Для правил минимальной длительности и строгих промежутков множественный выбор дней реализован — расхождение только у «времени до начала». \ один день — `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/HoursBefore/HoursBeforeInfo.cs:13`, `PartnerZones.Persistence/BookingRules/RuleSet/Models/HoursBeforeRuleJson.cs:4`; выбор первого совпадения — `BookingAllowedQueryHandler.cs:116-117`; множественный выбор у других правил — `src/libs/booking.domain.abstractions/.../Common/TimeWithWeekdays.cs:12-13`	Разработка (Владислав)	Open	(А) привести код к BRD: хранить список дней и вариант «все дни», как у остальных правил (рекомендуется — убирает расхождение между тремя однотипными правилами и упрощает интерфейс партнёра); (Б) привести BRD к коду: описать правило как «одна запись — один день». В любом случае отдельно решить, что делать при нескольких записях на один день — см. OQ2.4.1-13.	ОТ БИЗНЕСА: ок, вес доработки - 2
OQ2.4.1-11	Код BR2.4.1-4	Требование говорит: количество часов до начала имеет минимальное значение 1. В коде значение принимается без проверок — можно сохранить 0 или отрицательное число, что фактически отключает правило, не удаляя его, и вводит партнёра в заблуждение. \ `CreateRuleSetCommandHandler.cs:97-99`; значение хранится без ограничений — `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/HoursBefore/HoursBeforeInfo.cs:11-24`	Разработка (Владислав)	Open	Закрываю сам: завести задачу «валидация: часов до начала — не меньше 1» → тикет в Bitrix. Продуктового выбора нет — значение прямо задано в BRD. Делать одной задачей с OQ2.4.1-4.	ОТ БИЗНЕСА: ок, вес доработки - 1
OQ2.4.1-12	Код BR2.4.1-4	Что нашли: у правила «время до начала заказа» в коде есть признак «День в день», которого нет в перечне полей BR2.4.1-4 (в отличие от BR2.4.1-2 и BR2.4.1-3, где признак описан). Он реально влияет на применение правила так же, как у остальных двух правил, то есть правило умеет различать заказы на сегодня и на другие даты — просто в BRD это не зафиксировано. \ `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/HoursBefore/HoursBeforeInfo.cs:15`; применение — `BookingAllowedQueryHandler.cs:117`	Бизнес (Герман)	Open	(А) дописать признак «День в день» в перечень полей BR2.4.1-4 (рекомендуется — приводит описание в соответствие с фактом и делает три правила единообразными); (Б) подтвердить, что для этого правила признак не нужен, и убрать его из кода. Ответ зависит от OQ2.4.1-2 — сначала нужно договориться о смысле признака.	ОТ БИЗНЕСА: Б - привести код к БРД. Признак “день в день” не нужен для “Время до начала”. Вес доработки - 2
OQ2.4.1-13	Код BR2.4.1-5	Требование говорит: система должна допускать одновременное действие нескольких одинаковых или разных правил создания, если их параметры не противоречат друг другу. В коде проверки на противоречия между правилами нет ни при сохранении, ни в базе данных — уникальных ограничений на правила не создаётся. Одновременность поддержана лишь частично: разные виды правил действительно применяются вместе, но среди однотипных берётся только первое подходящее — вторая запись с теми же днями и временем молча игнорируется, а не «действует одновременно», и какая именно победит, зависит от порядка сохранения. Кроме того, на площадку применяется всего один набор правил (самый частный: правило комнаты вытесняет правило базы), поэтому наборы между собой не складываются. Единственная существующая проверка совместимости — запрет привязывать правила «день в день» при выключенном режиме брони «день в день». \ выбор первого совпадения — `BookingAllowedQueryHandler.cs:116,140,150,226`; один набор на площадку — `PartnerZones.Persistence/BookingRules/Repositories/BookingRuleSetRepository.cs:240-245`; отсутствие уникальных ограничений на правилах — `PartnerZones.Persistence/DbInitializer.cs:79-84`; единственная проверка совместимости — `PartnerZones.Domain/BookingRulesAggregate/BookingRuleSetAggregate.cs:220-229`	Бизнес/Разработка	Open	(А) уточнить в BRD ожидаемое поведение при пересечении однотипных правил: «побеждает самое строгое» / «побеждает самое частное» / «сохранение запрещается» — и затем реализовать (рекомендуется: текущее «первое попавшееся» непредсказуемо для партнёра и невоспроизводимо в поддержке); (Б) оставить как есть и переформулировать BR2.4.1-5 как «комбинируются правила разных видов». Отдельно подтвердить, ожидается ли одновременное действие нескольких наборов на одной площадке — сейчас это не так. Сначала бизнес-решение о приоритете, затем реализация.	ОТ БИЗНЕСА: А - привести код к БРД. Запретить сохранение набора условий при использовании пересекаемых правил(когда на одни и те же дни/часы задаются разные мин длительности и/или строгие промежутки. При проверке правил(описана в Back: 3.2) всегда используется конкретный набор условий заданный для бронируемой площадки(могут быть отдельными, могут наследоваться из объекта). Вес доработки - 2
OQ2.4.1-14	Код вне BRD	Что нашли: BR2.4.1-1 говорит о трёх проверках, а код выполняет больше. Сверх описанных трёх есть: (1) проверка попадания заказа в рабочие часы площадки — заказ вне режима работы отклоняется; (2) запрет бронирования «день в день» на уровне всего набора правил. Обе влияют на возможность создать заказ наравне с описанными правилами, но в BRD как условия создания не значатся. Дополнительно есть неописанный механизм «подсказки»: при нарушении строгих промежутков или минимальной длительности система не просто отказывает, а подбирает и возвращает скорректированное время окончания заказа (до 5 итераций подбора). \ рабочие часы — `BookingAllowedQueryHandler.cs:103-112`; запрет «день в день» — `BookingAllowedQueryHandler.cs:91-98`; подбор времени — `BookingAllowedQueryHandler.cs:295-386`	Бизнес (Герман)	Closed	(А) дополнить BR2.4.1-1 фактическим составом проверок и вынести подбор рекомендованного времени в отдельное требование (рекомендуется — сейчас документ занижает реальный объём логики, из-за чего её никто не сопровождает и она разъезжается между реализациями); (Б) подтвердить, что проверка режима работы площадки относится к другому разделу, и явно сослаться на него в «Не входит». Уточнить границу с разделом об объектах и расписании.	ОТ БИЗНЕСА: Все проверки описаны в Back: 3.2. Данный документ описывает только параметры правил и правила валидции их параметров.
OQ2.4.1-15	Код вне BRD	Что нашли: у набора правил есть отдельный переключатель «бронирование день в день выключено», запрещающий любые заказы на текущую дату независимо от трёх описанных правил. В BRD такой сущности нет. При его включении система дополнительно запрещает привязывать к набору правила с признаком «День в день» — то есть между переключателем и признаком есть связь, которую BRD не описывает. Отмечу: сам запрет сейчас не срабатывает при создании заказа из-за OQ2.4.1-1, но работает в поиске слотов, что и даёт расхождение из OQ2.4.1-16. \ поле — `PartnerZones.Domain/BookingRulesAggregate/BookingRuleSetAggregate.cs:46`; запрет на совмещение — `BookingRuleSetAggregate.cs:220-229`; применение — `BookingAllowedQueryHandler.cs:91`, `PartnerZones.Infrastructure/Services/RoomProcessingService.cs:1033`	Бизнес (Герман)	Closed	(А) описать переключатель в BR2.4.1-1 как отдельное условие создания вместе с правилом его сочетания с признаком «День в день» (рекомендуется — это реально работающее ограничение, влияющее на выручку площадки); (Б) подтвердить, что он относится к разделу 8.4 «Параметры системы», и сослаться на него. Учесть при ответе на OQ2.4.1-2.	ОТ БИЗНЕСА: А, БРД исправлен
OQ2.4.1-16	Код вне BRD	Проблема: одни и те же условия создания реализованы в системе дважды, разным кодом и с разным поведением. Первая реализация отвечает на вопрос «можно ли создать этот заказ», вторая — подбирает свободные слоты для поиска, календаря и карточки площадки. Во второй запрет «день в день» и минимальная длительность работают всегда, в первой — не работают вовсе из-за OQ2.4.1-1. Практическое следствие для партнёра: слот не показывается в поиске, но заказ на него проходит — и наоборот. \ реализация 1 — `PartnerZones.Application/Queries/Room/BookingAllowed/BookingAllowedQueryHandler.cs:57-290`; реализация 2 — `PartnerZones.Infrastructure/Services/RoomProcessingService.cs:1021-1070`	Разработка (Владислав)	Open	(А) свести обе реализации к одному общему коду проверки правил (рекомендуется — расхождение воспроизводится у партнёров как «показало слот, но не даёт забронировать», и это самый частый источник обращений по данному разделу); (Б) оставить две, но покрыть общими тестами на одинаковых данных. Сначала закрыть OQ2.4.1-1, иначе объединение зафиксирует ошибочное поведение.	ОТ БИЗНЕСА: ок, вес доработки - 1
OQ2.4.1-17	Код вне BRD	Проблема: при изменении набора правил система рассылает другим сервисам уведомление, в которое попадают только строгие промежутки. Правила минимальной длительности и времени до начала в уведомление не включены, хотя в самом наборе они есть. Это не теоретическая дыра: сервис цен, единственный внешний получатель, дополнительно отфильтровывает уведомления по признаку изменения строгих промежутков и на изменения двух других правил не реагирует в принципе. То есть правка минимальной длительности или времени до начала не запускает пересчёт на стороне цен. \ состав уведомления — `src/libs/booking.domain.abstractions/.../Contracts/BookingRules/Common/BookingRuleEventDto.cs:21`; сборка уведомления — `PartnerZones.Domain/BookingRulesAggregate/BookingRuleSetAggregate.cs:324-339`; жёсткий фильтр у получателя — `src/services/booking.prices/src/Prices.Infrastructure/Consumers/BookingRuleChangedConsumer.cs:34-38`	Разработка (Владислав)	Closed	(А) добавить недостающие два вида правил в уведомление и снять жёсткий фильтр у получателя (рекомендуется, если пересчёт цен должен реагировать на минимальную длительность); (Б) если сервису цен действительно нужны только строгие промежутки — зафиксировать это осознанно в описании контракта, чтобы состав не выглядел упущением. Требует подтверждения от владельца раздела цен (2.6).	ОТ БИЗНЕСА: Все верно - реагируем только на изменение строгих промежутков.
OQ2.4.1-18	Код вне BRD	Проблема: команда создания набора правил принимает от клиента перечень опций, но обработчик его нигде не использует — значение молча отбрасывается. То же при обновлении: перечень опций доходит до модели правил и там не читается. Внешне интерфейс выглядит так, будто привязка правил к опциям работает, фактически она не влияет ни на что — партнёр может считать, что настроил правило под опцию. \ параметр принимается — `PartnerZones.Application/Commands/RuleSet/Create/CreateRuleSetCommand.cs:22`; не используется в обработчике — `CreateRuleSetCommandHandler.cs:92-117`; не читается в модели — `PartnerZones.Domain/BookingRulesAggregate/BookingRuleSetAggregate.cs:179` (единственное упоминание параметра в файле)	Разработка (Владислав)	Open	Закрываю сам: завести задачу «перечень опций принимается интерфейсом и игнорируется — либо реализовать, либо убрать из контракта» → тикет в Bitrix. Что именно делать, решается по итогам OQ2.4.1-3 — это его техническое следствие; до ответа бизнеса убрать из контракта, чтобы не вводить в заблуждение.	ОТ БИЗНЕСА: Реализовать опции на уровне набора правил. Вес доработки - 2
OQ2.4.1-19	Код вне BRD	Проблема: автотестов на условия создания заказа не найдено за обход — ни на минимальную длительность, ни на строгие промежутки, ни на время до начала, ни на саму проверку «можно ли создать заказ». Для правил, которые напрямую управляют возможностью забронировать и оплатить, это означает, что ошибки уровня OQ2.4.1-1 и OQ2.4.1-8 не обнаруживаются до продакшена — что и произошло. \ поиск по всем тестовым проектам репозитория на упоминания проверки бронирования, правил минимальной длительности и признака игнорирования правил — совпадений нет	Разработка (Владислав)	Open	Закрываю сам: завести задачу «покрыть тестами проверку условий создания заказа» → тикет в Bitrix, делать в одном пакете с исправлением OQ2.4.1-1 (тест на инвертированный признак — первый кандидат). Продуктового выбора нет.	ОТ БИЗНЕСА: ок, вес доработки - 2
OQ2.4.1-20	Код вне BRD	Проблема: правила хранятся одним полем-документом внутри набора, но при инициализации базы по-прежнему создаются старые отдельные таблицы под строгие промежутки и время до начала — в самом коде они помечены как устаревшие, и ни один репозиторий из них не читает и в них не пишет. Два способа хранения сосуществуют, что затрудняет понимание, где источник истины. \ `PartnerZones.Persistence/DbInitializer.cs:81-84` (комментарий «Deprecated: normalized MinHours tables removed (JSONB now stores rules)», при этом таблицы строгих промежутков и времени до начала продолжают создаваться); неиспользуемые модели — `PartnerZones.Persistence/BookingRules/StrictRules/Models/StrictRuleEntity.cs:10`, `.../StrictRuleHours.cs:11`, `.../HoursBefore/Models/HoursBefore.cs:10`	Разработка (Владислав)	Open	Закрываю сам: завести задачу на техуборку «удалить устаревшие таблицы правил после проверки, что в них нет данных» → тикет в Bitrix. Продуктового выбора нет. Низкий приоритет относительно остальных вопросов раздела.	ОТ БИЗНЕСА: ок, вес доработки - 1

BRD

Explorer