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	Условия создания должны состоять из трех проверок, каждая из которых является отдельным правилом	Проверки: - Минимальная длительность заказа — определяет минимально возможную длительность заказа; - Строгие промежутки — определяют конкретные часы, на которые можно создать заказ; - Время до начала заказа — определяет время, по истечении которого заказ не может быть зарезервирован. Все проверки применяются к заказу в процессинговом статусе, который раскрывается в Back 3.2 Процессинг заказов.	Бизнес	1	Частично \ OQ2.4.1-1, OQ2.4.1-14
S2: BR2.4.1-2	Условия создания должны содержать список правил, определяющих минимально возможную длительность заказа в процессинговом статусе	Минимальная длительность заказа — обязательное системное правило, без которого создание заказов невозможно. Каждая запись содержит: - Минимальная длительность — значение минимальной длительности в часах (минимальное значение и значение по умолчанию — 1 час); - Опции — перечень опций, на которые распространяется условие (если не задан — все опции); - Диапазон опции — число или диапазон в формате «X-X» (если не задан — любой диапазон); - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни); - Время действия — один или несколько диапазонов (если не задано — весь день); - День в день — признак, активирующий условие, если дата и время создания заказа совпадают с датой заказа (если не задан — условие действует всегда); - Период действия — календарный период работы условия создания (если не задан — условие действует всегда). Применение к заказу раскрывается в 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	Условия создания могут содержать список правил, определяющих конкретные часы, на которые можно создать заказ в процессинговом статусе	«Строгие промежутки» — необязательное правило. Каждая запись содержит: - Часы — перечень доступных часов в качестве времени начала и окончания заказа; - Опции — перечень опций, на которые распространяется условие (если не задан — все опции); - Диапазон опции — число или диапазон в формате «X-X» (если не задан — любой диапазон); - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни); - День в день — признак, активирующий условие, если дата и время создания заказа совпадают с датой заказа (если не задан — условие действует всегда); - Период действия — календарный период работы условия создания (если не задан — условие действует всегда). Применение к заказу раскрывается в 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`	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести дефект «условие применения проверок минимальной длительности и брони день в день инвертировано — правила не работают в проде» → тикет в 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.
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.
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`	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести задачу «валидация минимальной длительности: не меньше 1 часа, по умолчанию 1» → тикет в Bitrix. Продуктового выбора нет — значение прямо задано в BRD. Делать одной задачей с OQ2.4.1-11.	Добавить валидацию минимальной длительности заказа: значение должно быть не меньше 1 часа, при отсутствии значения использовать 1 час по умолчанию. Запретить сохранение 0 и отрицательных значений при создании и обновлении набора правил. Реализовать проверку на уровне обработки команд и доменной модели; сделать одной задачей с валидацией поля «часов до начала» из OQ2.4.1-11.
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 конкретный механизм наследования и поведение при пустом наборе. Сначала решение бизнеса, затем реализация.	Требуется решение бизнеса по модели обязательности минимальной длительности. Уточнить: правило минимальной длительности должно быть обязательным в каждом наборе правил или может наследоваться из системных параметров/шаблона. Если правило не задано в наборе, бизнес должен выбрать поведение: запретить сохранение набора, подставлять значение по умолчанию 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`	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести дефект «период действия набора правил не учитывается при проверке заказа» → тикет в Bitrix. Продуктового выбора нет: поле заведено и заполняется партнёром, но не влияет на результат — это скрытая ошибка, а не спорное поведение.	Добавить в проверку создания заказа учет периода действия набора правил. Если у набора правил задан период, применять этот набор только к заказам, дата которых попадает в период действия. Если период не задан, набор правил должен применяться без ограничения по датам.
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)	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести задачу «недостижимая ветка отказа по минимальной длительности» → тикет в Bitrix. Чинить вместе с OQ2.4.1-1 — это следствие той же перевёрнутой логики; отдельная правка смысла не имеет.	Исправить вместе с OQ2.4.1-1 как часть дефекта инвертированного условия применения правил. После исправления проверка минимальной длительности должна выполняться при обычном создании заказа, а отказ по причине “Минимальная длительность N ч. Текущая длительность M ч.” должен стать достижимым и возвращаться вызывающему сервису.
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. Объём больше, чем добавление поля: нужно развести проверку правил для заказа и для заявки.
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.	Привести правило «Время до начала заказа» к единой модели условий создания: дни недели должны задаваться множественным выбором, как у правил минимальной длительности и строгих промежутков. Если дни недели не заданы, правило применяется на все дни. Текущую модель “одна запись — один день” заменить на “одна запись — один или несколько дней”. Поведение при нескольких записях, подходящих на один и тот же день, определить отдельно в OQ2.4.1-13.
OQ2.4.1-11	Код BR2.4.1-4	Требование говорит: количество часов до начала имеет минимальное значение 1. В коде значение принимается без проверок — можно сохранить 0 или отрицательное число, что фактически отключает правило, не удаляя его, и вводит партнёра в заблуждение. \ `CreateRuleSetCommandHandler.cs:97-99`; значение хранится без ограничений — `PartnerZones.Domain/BookingRulesAggregate/ValueObjects/HoursBefore/HoursBeforeInfo.cs:11-24`	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести задачу «валидация: часов до начала — не меньше 1» → тикет в Bitrix. Продуктового выбора нет — значение прямо задано в BRD. Делать одной задачей с OQ2.4.1-4.	Добавить валидацию поля «Часов до начала»: значение должно быть не меньше 1. Запретить сохранение 0 и отрицательных значений при создании и обновлении набора правил. Реализовать проверку на уровне обработки команд и доменной модели; при нарушении возвращать ошибку валидации. Делать одной задачей с OQ2.4.1-4.
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 — сначала нужно договориться о смысле признака.
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 как «комбинируются правила разных видов». Отдельно подтвердить, ожидается ли одновременное действие нескольких наборов на одной площадке — сейчас это не так. Сначала бизнес-решение о приоритете, затем реализация.	Нужно определить правила применения нескольких настроек условий создания, если они подходят под один и тот же заказ. Бизнесу нужно подтвердить, можно ли заводить пересекающиеся правила одного типа внутри одного набора. Если можно, нужно определить, какое правило считается приоритетным при пересечении. Если нельзя, система должна запрещать сохранение таких пересекающихся настроек. Также нужно определить, как применять правила, заданные на разных уровнях: использовать только самый конкретный набор правил или объединять правила базы и комнаты.
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`	Бизнес (Герман)	Open	(А) дополнить BR2.4.1-1 фактическим составом проверок и вынести подбор рекомендованного времени в отдельное требование (рекомендуется — сейчас документ занижает реальный объём логики, из-за чего её никто не сопровождает и она разъезжается между реализациями); (Б) подтвердить, что проверка режима работы площадки относится к другому разделу, и явно сослаться на него в «Не входит». Уточнить границу с разделом об объектах и расписании.
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`	Бизнес (Герман)	Open	(А) описать переключатель в 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, иначе объединение зафиксирует ошибочное поведение.	Устранить расхождение между проверкой создания заказа и подбором доступных слотов. После исправления OQ2.4.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`	Разработка (Владислав)	Open	(А) добавить недостающие два вида правил в уведомление и снять жёсткий фильтр у получателя (рекомендуется, если пересчёт цен должен реагировать на минимальную длительность); (Б) если сервису цен действительно нужны только строгие промежутки — зафиксировать это осознанно в описании контракта, чтобы состав не выглядел упущением. Требует подтверждения от владельца раздела цен (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` (единственное упоминание параметра в файле)	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести задачу «перечень опций принимается интерфейсом и игнорируется — либо реализовать, либо убрать из контракта» → тикет в Bitrix. Что именно делать, решается по итогам OQ2.4.1-3 — это его техническое следствие; до ответа бизнеса убрать из контракта, чтобы не вводить в заблуждение.	Решение зависит от OQ2.4.1-3. Нужно уточнить у бизнеса, должны ли условия создания зависеть от опций и диапазонов опций. Если привязка к опциям нужна, реализовать её полноценно: сохранять опции в правилах, передавать данные об опциях в проверку заказа и учитывать их при выборе применимого правила. Если привязка к опциям не нужна, убрать поле опций из контракта и интерфейса настройки, чтобы система не принимала данные, которые фактически не используются.
OQ2.4.1-19	Код вне BRD	Проблема: автотестов на условия создания заказа не найдено за обход — ни на минимальную длительность, ни на строгие промежутки, ни на время до начала, ни на саму проверку «можно ли создать заказ». Для правил, которые напрямую управляют возможностью забронировать и оплатить, это означает, что ошибки уровня OQ2.4.1-1 и OQ2.4.1-8 не обнаруживаются до продакшена — что и произошло. \ поиск по всем тестовым проектам репозитория на упоминания проверки бронирования, правил минимальной длительности и признака игнорирования правил — совпадений нет	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести задачу «покрыть тестами проверку условий создания заказа» → тикет в Bitrix, делать в одном пакете с исправлением OQ2.4.1-1 (тест на инвертированный признак — первый кандидат). Продуктового выбора нет.	Сделать автоматизированную проверку логики условий создания заказа. Покрыть сценарии работы BookingAllowedQueryHandler для минимальной длительности, строгих промежутков, времени до начала, запрета бронирования «день в день» и флага игнорирования правил. Проверять не только факт разрешения или отказа, но и корректную причину отказа. Отдельно проверить согласованность результата между проверкой создания заказа и подбором доступных слотов, чтобы одинаковые правила давали одинаковое поведение в обоих сценариях.
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`	Разработка (Владислав)	Закрывает PM	Закрываю сам: завести задачу на техуборку «удалить устаревшие таблицы правил после проверки, что в них нет данных» → тикет в Bitrix. Продуктового выбора нет. Низкий приоритет относительно остальных вопросов раздела.	Удалить устаревший способ хранения правил условий создания после проверки его фактического использования. Подтвердить, что старые отдельные таблицы для строгих промежутков и времени до начала не используются для чтения и записи, а актуальным источником данных является JSON/document-поле внутри набора правил. Если в старых таблицах нет нужных данных, убрать их создание из инициализации базы и удалить связанные неиспользуемые модели. Если данные есть, сначала определить необходимость миграции в актуальную модель хранения.

BRD

Explorer