2.4.2 Условия оплаты

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

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

Статус: черновик

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

Версия: 0.1

Обновлено: 10.07.26

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

Условия оплаты — список правил, содержащих перечень проверок для отображения доступных сценариев оплаты при резервировании площадок объекта.

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

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

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

Сценарий оплаты — порядок осуществления платежа по условию оплаты.

Канал оплаты — доступный партнерской зоне канал, по которому осуществляются платежи по поступающим заказам.

3. Scope

Входит

S1 Условия оплаты: определение и базовое правило применения при резервировании площадок объекта.

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

S3 Ограничения: запрет сохранения условий оплаты с полностью идентичными параметрами.

Не входит

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

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

ID	Требование	Комментарий	Тип требования	Вес	Статус
S1: BR2.4.2-1	Условия оплаты должны содержать правила с перечнем проверок, определяющих доступные сценарии оплаты при резервировании площадок объекта	Условия оплаты применяются по правилам наследования и привязки к объектам и площадкам, описанным в Back 2.4 Правила работы с заказами. Стандартные системные правила раскрываются в Back 8.4 Параметры системы.	Бизнес	1	Частично — OQ2.4.2-1, OQ2.4.2-2
S2: BR2.4.2-2	Каждое условие оплаты должно определять платежную конфигурацию для поступающих заказов	Платежная конфигурация содержит: - Название условия оплаты — текстовое название условия; - Канал оплаты для поступающих заказов — один из доступных каналов оплаты партнерской зоны, по которому будут осуществляться платежи; - Сценарий оплаты — конкретный сценарий, по которому будут осуществляться платежи по условию (по умолчанию — «На месте»); - Методы оплаты — один или несколько методов, доступных в рамках выбранного сценария оплаты. Каналы партнерской зоны раскрываются в Back 1.4 Партнеры и Back 5.1 Каналы оплаты, сценарии и методы — в Back 5.1.2 Сценарии и Методы оплаты.	Бизнес	1	Частично — OQ2.4.2-3, OQ2.4.2-4
S2: BR2.4.2-3	Условие оплаты должно хранить обязательные параметры выбранного сценария оплаты	Параметры сценариев: - Параметры онлайн-платежа — запись из настроек партнерской зоны, определяющая размеры составных частей платежа и реквизиты юридического лица, на которое отправляется его основная часть; обязательна для сценария «Онлайн в интерфейсе»; - Инструкция — запись из настроек партнерской зоны, определяющая ссылку на документ со сценарием и реквизитами для внесения предоплаты; обязательна для сценария «По инструкции»; - Размер предоплаты — число от 10 до 100, определяющее процент от стоимости объекта оплаты; обязателен для сценариев «Онлайн в интерфейсе» и «По инструкции», значение по умолчанию — 100%. Параметры онлайн-платежа и инструкции раскрываются в Back 2.8 Настройки партнерской зоны, объекты оплаты — в Back 5.1.1 Объекты оплаты.	Бизнес	1	Частично — OQ2.4.2-5, OQ2.4.2-6
S2: BR2.4.2-4	Условие оплаты может ограничивать доступность сценария оплаты по параметрам клиента и заказа	Ограничения содержат: - Диапазон штрафа — диапазон непогашенного штрафа клиента, при котором условие доступно (если не задан — проверка по штрафу пропускается); - Диапазон итоговой стоимости заказа — диапазон стоимости заказа, при котором условие доступно (если не задан — проверка по стоимости заказа пропускается); - Минимальная длительность заказа — длительность заказа в часах, на которую распространяется условие оплаты (если не задана — не учитывается).	Бизнес	2	Частично — OQ2.4.2-10, OQ2.4.2-11
S2: BR2.4.2-5	Условие оплаты должно определять объекты, площадки, услуги и опции, на которые оно распространяется	Область действия содержит: - Разрешенные объекты — список объектов, на которых действует условие (если не задан — все объекты); - Разрешенные площадки или услуги — список площадок и услуг, на которых действует условие (если не задан — все площадки и услуги); - Опции — перечень опций, на которые распространяется условие (если не задан — все опции); - Диапазон опции — число или диапазон в формате «X-X» для опций с признаком «диапазон» (если не задан — любой диапазон). Объекты раскрываются в Back 2.1 Объекты партнеров, площадки — в Back 2.2 Площадки партнеров, опции — в Back 8.2.1 Сферы и Опции.	Бизнес	1	Частично — OQ2.4.2-7, OQ2.4.2-8
S2: BR2.4.2-6	Условие оплаты может ограничивать время своего действия	Временные параметры содержат: - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни); - Время действия — один или несколько диапазонов времени (если не задано — весь день); - Период действия — календарный период работы условия оплаты (если не задан — условие действует всегда).	Бизнес	2	Частично — OQ2.4.2-12
S2: BR2.4.2-7	Условие оплаты должно определять доступность по источникам и состояние активности	Параметры доступности содержат: - Источники — интерфейсы, в которых доступно условие (если не заданы — все источники); - Признак архивации — признак, деактивирующий работу условия оплаты. Справочник источников раскрывается в Back 8.2.2 Источники заказа.	Системное	1	Частично — OQ2.4.2-9
S2: BR2.4.2-8	По условию оплаты должны справочно отображаться клиенты, связанные с ним персональными условиями оплаты	Отображаются: - Аккаунты, на которые условие не действует; - Аккаунты, на которые условие действует. Персональные условия оплаты клиентов раскрываются в Back 1.3.2 Характеристики клиента.	Системное	2	Частично — OQ2.4.2-13
S3: BR2.4.2-9	Система не должна допускать сохранение условий оплаты с полностью идентичными параметрами		Системное	2	Не реализовано — OQ2.4.2-14

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

BRD 2.4.2 v0.1 · booking-monorepo · commit 83423b21 / main · 2026-07-20 · якорь src/services/booking.partner-management (условие оплаты = PaymentFilters, платёжная конфигурация = PaymentSettings); cross-layer обход: booking.orders, TinkoffPayments, booking.clients, booking.apigateway Сводка: вопросов 22 (Open 18 · Закрывает PM 4 · Подтверждено 0) · требований без расхождений 0 · отрезано находок обратного прохода 13 Маршрутизация без сверки с гайдбуком (гайдбук на вход не передавался — позиция гайдбука нигде не додумывалась). Оговорка по обходу: в сервисе booking.partner-management нет ни SQL-миграций, ни EF-миграций — схема создаётся кодом (PartnerZones.Persistence/DbInitializer.cs). Поэтому утверждения об отсутствии ограничений на уровне базы опираются на этот файл и на атрибуты LinqToDB, а не на DDL; проверить фактическую схему боевой базы статически нельзя. Отрезано (перечислено, чтобы не читалось как «всё покрыто»): дефект if (Account != null) Account = account в изменении платёжной конфигурации (относится к Back 2.8); сценарий оплаты невозможно изменить через изменение настройки — в обработчике жёстко передан пропуск (Back 2.8); признак «только на сегодня» сбрасывается в пустое значение при частичном изменении; название и комментарий условия невозможно очистить через изменение — старое значение «залипает»; пустое название условия сохраняется без ошибки; проверка прав при изменении выполняется после мутации агрегатов в памяти; в тексте ошибки при архивации подставляется общее число заказов вместо числа броней в «Резерве»; мёртвый дизъюнкт !true в выборке кандидатов; идентификаторы строк области действия и связей опций перегенерируются при каждом сохранении; идентификатор партнёрской зоны на условии денормализован (источник истины — таблица области действия); срок жизни ссылки на онлайн-оплату захардкожен 5 минутами (относится к Back 5.1); доплата остатка сверх процента предоплаты невозможна — потолок платежа равен сумме предоплаты (относится к Back 5.1); доменных тестов по условиям оплаты нет (PartnerZones.Domain.Tests пуст).

ID	Источник	Вопрос	Кому	Статус	Рекомендации	Итоговое решение
OQ2.4.2-1	Код BR2.4.2-1	Проблема: признак «у условия вообще есть ограничения» вычисляется с перевёрнутым условием по дням недели, и из-за этого часть условий проходит отбор вообще без единой проверки. В коде признак «есть ограничения» по дням становится истинным, когда выбраны все семь дней (то есть когда ограничения по дням фактически НЕТ), и остаётся ложным, когда выбрано подмножество дней (то есть когда ограничение как раз ЕСТЬ). Дальше в отборе стоит короткое замыкание: если признак ложный, условие принимается сразу — без проверок по штрафу, датам, дням, времени, стоимости, источнику и опциям. Итог: условие, ограниченное, например, только тремя днями недели и суммой заказа, может быть выдано клиенту в дни и на суммы, для которых оно не предназначено. Второй эффект: при создании через команду пустой список дней молча заменяется на все семь дней, поэтому почти любое созданное условие получает признак «есть ограничения» = истина, и тогда клиенту перестаёт отдаваться процент предоплаты — отдаётся только «предоплата возможна». \ `PaymentFiltersAggregate.cs:232`; `CreatePaymentFilterCommandHandler.cs:82-86`; `PaymentEvaluationHelper.cs:59-68`, `:241-242`	Разработка (Владислав)	Закрывает PM	Закрываю сам: это ошибка, а не продуктовый выбор — привести условие к «дни заданы частично», то есть `Count > 0 и < 7`, и отдельно решить, должна ли команда создания подставлять все семь дней вместо пустого списка → тикет в Bitrix. Разблокирующий: пока признак считается неверно, любые выводы о работе проверок из OQ2.4.2-11, OQ2.4.2-12 частично обесцениваются.	Исправить ошибку в определении ограничения по дням недели: считать ограничение активным только при выборе неполного набора дней (больше 0 и меньше 7). Дополнительно проверить и зафиксировать поведение создания условия оплаты при пустом списке дней: нужно ли автоматически подставлять все 7 дней. Бизнес-решение не требуется, завести задачу в разработку.
OQ2.4.2-2	Код BR2.4.2-1	Требование говорит: доступность сценария оплаты определяется перечнем проверок самого условия оплаты. В коде поверх этих проверок действует ещё один, не описанный в BRD, слой — признак доверия к клиенту в партнёрской зоне. Если клиенту выставлено «только по предоплате», сценарий «На месте» исключается полностью, ещё до всех проверок. Если клиенту выставлено «доверенный», то условия со сценариями «Онлайн в интерфейсе» и «По инструкции» принимаются без единой проверки — ни штраф, ни даты, ни дни, ни время, ни сумма, ни источник, ни опции не проверяются. То есть характеристика клиента способна полностью отменить правила условия оплаты. \ `PaymentEvaluationHelper.cs:43-44`, `:46-57`; значение приходит из сервиса клиентов: `ClientPartAggregate.cs:15`, `CreateOrderCommandHandler.cs:157`	Бизнес (Герман)	Open	(А) признать приоритет характеристики клиента над условием оплаты целевым и описать его в BRD отдельным требованием со ссылкой на Back 1.3.2 — рекомендуется, поведение выглядит осознанным и давно работающим; (Б) оставить за клиентом только исключение сценария «На месте», а «доверенному» клиенту всё равно проверять ограничения условия — это изменение поведения, требует отдельной оценки.
OQ2.4.2-3	Код BR2.4.2-2	Требование говорит: каждое условие оплаты определяет свою платёжную конфигурацию — название, канал оплаты, сценарий оплаты и методы оплаты. В коде на самом условии хранится только название (плюс описание и комментарий). Канал оплаты, сценарий оплаты, процент предоплаты и реквизиты лежат уровнем выше — в отдельной записи «настройка оплаты», а методы оплаты ещё уровнем выше — на самом канале оплаты. Связь «условие → настройка» — многие-к-одному: одна настройка обслуживает несколько условий, и изменение сценария или канала в ней меняет платёжную конфигурацию сразу у всех связанных условий. Отдельно: если у канала методы оплаты не заданы, система считает доступными все методы без исключения. \ `PaymentFiltersAggregate.cs:25-27`; `PaymentSettingsAggregate.cs:31,36,37,41`; `PaymentFilters.cs:17,63-64`; методы на канале — `AllowPaymentMethodOnPayChannel.cs:9-20`; «пусто = все методы» — `PaymentFiltersReadOnlyRepository.cs:521-523`	Бизнес (Герман)	Open	(А) переформулировать требование как «условие оплаты ссылается на платёжную конфигурацию партнёрской зоны и наследует её» и явно описать, что конфигурация общая для группы условий — рекомендуется, это соответствует фактической модели и границе с Back 2.8; (Б) переносить канал/сценарий/методы на само условие — это переделка модели данных, не оправдана без продуктовой потребности. Связать с OQ2.4.2-5.
OQ2.4.2-4	Код BR2.4.2-2	Требование говорит: сценарий оплаты по умолчанию — «На месте». В коде значения по умолчанию нет: сценарий обязательно выбирается при создании платёжной конфигурации, и по нему сразу выбирается своя ветка создания. Ни в одном месте «На месте» не подставляется автоматически при отсутствии выбора. Косвенно похожее поведение есть в другом месте и по другому поводу: при создании заказа из веб-подобных источников без явно выбранного условия система сама подбирает условие со сценарием «На месте» и методом «наличные» — но это правило заказа, а не значение по умолчанию для условия оплаты. \ `CreatePaymentSettingCommandHandler.cs:55-89`; автоподбор при заказе — `CreateOrderCommandHandler.cs:214-233`	Бизнес (Герман)	Open	(А) убрать из BRD упоминание «по умолчанию — На месте», если значение по умолчанию задаётся интерфейсом, а не бэкендом — рекомендуется, бэкенд действительно требует явный выбор; (Б) реализовать подстановку «На месте» при отсутствии выбора — имеет смысл только если такое поведение нужно для внешних интеграций.
OQ2.4.2-5	Код BR2.4.2-3	Требование говорит: размер предоплаты — число от 10 до 100, значение по умолчанию 100%. В коде ни границ, ни значения по умолчанию нет. Процент предоплаты хранится как обычное необязательное число без единой проверки: сохранить можно 0, 5, 300 или отрицательное значение. Значение по умолчанию при создании — не 100, а 0 для сценария «Онлайн в интерфейсе»; для «По инструкции» значение сохраняется как есть, включая пустое; для «На месте» не задаётся вовсе. Пустое значение позже трактуется при расчёте платежа как 100% — то есть «не задано» и «100%» дают одинаковый результат в деньгах, а «0» даёт нулевую предоплату. Отдельно: попытка держать процент предоплаты на самом условии оплаты в коде есть, но отключена — строка сопоставления закомментирована. \ `PaymentSettingsAggregate.cs:36`, `:87`, `:139-140`; значения по умолчанию — `CreatePaymentSettingCommandHandler.cs:79`, `:87`; трактовка пустого как 100% — `CreateOrderPaymentCommandHandler.cs:210-216`; отключённое сопоставление — `PaymentFiltersMapper.cs:82`	Бизнес/Разработка (Герман, Владислав)	Open	(А) подтвердить границы 10–100 и значение по умолчанию 100% как целевые, добавить проверку при сохранении и разово проверить существующие записи на выход за границы — рекомендуется, расхождение имеет прямые денежные последствия; (Б) признать текущее поведение целевым (произвольный процент, пустое = 100%) и переписать требование — тогда нужно решение бизнеса, зачем разрешать 0% и >100%. Первым нужно решение бизнеса по границам, затем реализация.	Сначала подтвердить с бизнесом целевое правило для процента предоплаты: допустимы только значения от 10 до 100%, значение по умолчанию — 100%. После подтверждения добавить проверку при сохранении платёжной конфигурации и разово проверить существующие записи на 0%, значения меньше 10%, больше 100% и отрицательные значения. До решения бизнеса разработку не начинать, так как правило влияет на сумму оплаты.
OQ2.4.2-6	Код BR2.4.2-3	Требование говорит: параметры онлайн-платежа обязательны для сценария «Онлайн в интерфейсе», инструкция обязательна для сценария «По инструкции». В коде обязательность не проверяется нигде. При создании конфигурации со сценарием «Онлайн в интерфейсе» реквизиты, код магазина, банк и счёт при отсутствии молча заменяются на пустую строку; при сценарии «По инструкции» ссылка на инструкцию так же заменяется на пустую строку. Единственная реальная проверка при создании — что указанный канал оплаты существует. Валидаторов на входе тоже нет: в сервисе нет ни одного файла-валидатора, а шлюз проверяет только токен доступа. Последствие всплывает позже, уже при оплате заказа: если сценарий или настройка не заполнены, заказ падает с ошибкой конфигурации оплаты — то есть незаполненная конфигурация обнаруживается не при сохранении, а при попытке клиента заплатить. \ `PaymentSettingsAggregate.cs:178-220`, `:221-254`; `CreatePaymentSettingCommandHandler.cs:72-79`, `:86`, `:50-53`; отложенная ошибка — `CreateOrderPaymentCommandHandler.cs:168-179`	Разработка (Владислав)	Open	(А) добавить проверку обязательных параметров по сценарию при сохранении конфигурации — рекомендуется, переносит отказ из момента оплаты клиентом в момент настройки; (Б) оставить как есть и описать в BRD, что обязательность обеспечивается интерфейсом администратора — тогда нужно зафиксировать, что бэкенд принимает неполную конфигурацию. Связать с OQ2.4.2-5.	Добавить серверную проверку обязательных параметров платёжной конфигурации по сценарию оплаты: для «Онлайн в интерфейсе» запрещать сохранение без параметров онлайн-платежа, для «По инструкции» — без инструкции. Ошибку нужно возвращать при настройке, а не в момент оплаты клиентом. Дополнительно проверить существующие конфигурации на пустые обязательные значения. Бизнес-решение не требуется, если обязательность из BRD подтверждается как целевая.
OQ2.4.2-7	Код BR2.4.2-5	Требование говорит: область действия условия — объекты, площадки и услуги. В коде услуг в области действия нет вообще: область действия трёхуровневая — партнёрская зона, объект, площадка. Строка области действия хранит только эти три ссылки, поля услуги нет ни в таблице, ни в командах создания и изменения. Пустая ссылка на объект и площадку означает «всё в партнёрской зоне», пустая ссылка на площадку — «весь объект». Отдельно подтверждено, что при совпадении настройки условие уровня площадки вытесняет условие уровня объекта. \ `PaymentFiltersScope.cs:9-18`; `PartnerZoneEntityScope.cs:12-14`; приоритет площадки над объектом — `PaymentFiltersReadOnlyRepository.cs:333-367`	Бизнес (Герман)	Open	(А) убрать услуги из требования, если они не самостоятельная сущность области действия — рекомендуется, в коде их нет ни в каком виде; (Б) подтвердить, что услуги должны ограничивать условие оплаты, и завести это как доработку — тогда нужно решение, что считать услугой применительно к области действия.
OQ2.4.2-8	Код BR2.4.2-5	Требование говорит: диапазон опции — число или диапазон «X-X» для опций с признаком «диапазон»; если не задан — любой диапазон. В коде три расхождения. Первое: сравнивается не диапазон с диапазоном, а точка с диапазоном — числовая характеристика опции заказа подставляется в проверку дважды, и как нижняя, и как верхняя граница. Второе: односторонний диапазон теряется — если у опции условия задана только нижняя или только верхняя граница, диапазон при чтении из базы схлопывается в «не задан», потому что собирается только когда обе границы заполнены. Третье: поведение при отсутствии опции в заказе несогласованно — в поштучном расчёте условие с фильтром по опциям отбраковывается, а в диапазонном расчёте (мобильный календарь) та же проверка просто пропускается. Признак «диапазон» при этом на связке опции с условием не хранится вовсе — он живёт в справочнике опций. \ `PaymentEvaluationHelper.cs:104-117` и `:180`; подстановка одного значения дважды — `GetAllowedPaymentFiltersBulkQueryHandler.cs:171-176`; потеря односторонней границы — `PaymentFiltersMapper.cs:49`; признак в справочнике — `Options/Models/Option.cs:21-22`	Разработка (Владислав)	Open	(А) привести к требованию: поддержать односторонние границы и согласовать поведение поштучного и диапазонного расчётов при отсутствии опции — рекомендуется, сейчас один и тот же заказ даёт разный набор условий в разных интерфейсах; (Б) зафиксировать в BRD, что диапазон задаётся только полностью (обе границы) — снимает часть расхождения, но не устраняет расхождение между двумя расчётами.	Исправить проверку опций в условиях оплаты: для диапазонных опций сравнивать фактический диапазон заказа с диапазоном условия, а не одно значение как обе границы. Поддержать односторонние границы условия («от» или «до») и не терять их при чтении из базы. Унифицировать поведение поштучного и диапазонного расчётов: если в заказе нет опции, по которой задан фильтр условия, такое условие не должно считаться подходящим. Бизнес-решение не требуется, это приведение к уже описанному требованию.
OQ2.4.2-9	Код BR2.4.2-7	Проблема: признак «условие ограничено по источникам» считается неверно после изменения условия. Признак определяется как «набор источников условия отличается от набора источников платёжного канала», но список источников канала в конструкторе условия не сохраняется — принимается параметром и теряется. В результате при любом изменении условия сравнение идёт с пустым списком, и признак становится истинным всегда, когда у условия указан хоть один источник — даже если он в точности совпадает с источниками канала и никакого ограничения не задаёт. При создании признак считается корректно, расхождение проявляется только после изменения. Побочный эффект тот же, что и в OQ2.4.2-1: условие считается «с ограничениями», и клиенту перестаёт отдаваться процент предоплаты. Часть требования про архивацию при этом подтверждается: признак архивации хранится, архивные условия исключаются из отбора, а перевод в архив дополнительно защищён — он запрещён, если по площадкам условия есть будущие брони в статусе «Резерв», и требует отдельного права. \ параметр теряется — `PaymentFiltersAggregate.cs:83` и тело конструктора `:89-111`; расчёт признака — `:222-228`, `:336`; архивация — `:379-400`, `UpdatePaymentFilterCommandHandler.cs:92-93`, `:169-190`, `:119-125`; исключение архивных из отбора — `PaymentFiltersReadOnlyRepository.cs:209`, `:245`	Разработка (Владислав)	Закрывает PM	Закрываю сам: сохранять переданный список источников канала в конструкторе — это явная потеря параметра, продуктового выбора здесь нет → тикет в Bitrix. Связать с OQ2.4.2-1: оба дефекта искажают один и тот же признак «есть ограничения».	Исправить изменение условия оплаты: при пересчёте ограничения по источникам использовать список источников платёжного канала, а не пустой список. После изменения условие должно считаться ограниченным по источникам только если выбранные источники отличаются от источников платёжного канала. Завести задачу в разработку.
OQ2.4.2-10	Код BR2.4.2-4	Требование говорит: условие оплаты может ограничиваться минимальной длительностью заказа в часах. В коде такого параметра нет нигде — ни в условии, ни в таблице, ни в командах создания и изменения, ни в наборе данных, по которому идёт отбор. Проверки по длительности заказа в отборе тоже нет. Длительность участвует только косвенно: из времени начала и окончания заказа вычисляются период дат, набор дней недели и время окончания. Ближайший по названию параметр — «время на оплату» в минутах, но это срок оплаты, а не длительность заказа. Остальные два ограничения этого требования подтверждаются: диапазон непогашенного штрафа клиента реально проверяется (включающее сравнение, значения по умолчанию 0 и «без верхней границы» пропускают любой штраф), сама сумма штрафа приходит из сервиса клиентов, а при неизвестном клиенте считается нулевой. \ отсутствие параметра — не найдено за обход `PaymentFiltersAggregate.cs`, `PaymentFilters.cs`, `CreatePaymentFilterCommand.cs:22-40`, `UpdatePaymentFilterCommand.cs:14-35`, `PaymentEvaluationCandidate.cs`; проверка штрафа — `PaymentEvaluationHelper.cs:71-72`; источник суммы штрафа — `GetAllowedPaymentFiltersBulkForOrdersQueryHandler.cs:97-118`	Бизнес (Герман)	Open	(А) подтвердить, что ограничение по минимальной длительности нужно, и завести доработку — тогда потребуется новое поле, миграция и проверка в отборе; (Б) убрать параметр из требования — рекомендуется, если он попал в BRD по аналогии с другими правилами работы с заказами, где длительность действительно есть; в условиях оплаты его никогда не было.
OQ2.4.2-11	Код BR2.4.2-4	Требование говорит: если диапазон итоговой стоимости заказа не задан, проверка по стоимости пропускается; если задан — условие доступно только внутри диапазона. В коде проверка срабатывает только когда заданы обе границы и когда сумма заказа вообще передана. Незаданные границы при сохранении молча заменяются на 0 и «максимально возможное число», поэтому «задана только нижняя граница» технически возможно, но проверка в этом случае не выполняется вовсе — условие доступно на любую сумму. Отдельно: в мобильном календаре сумма заказа не передаётся (передаётся пусто), поэтому проверка по стоимости там не работает никогда; в диапазонном расчёте того же календаря дополнительно не проверяются дни недели, время и признак «только на сегодня». То есть один и тот же заказ может получить разный набор доступных условий в зависимости от того, из какого интерфейса он рассчитывается. \ проверка суммы — `PaymentEvaluationHelper.cs:97-101`; подстановка границ — `PaymentFiltersAggregate.cs:154`; мобильный календарь — `RoomProcessingService.cs:140`, `:145`; диапазонный расчёт без дней и времени — `PaymentEvaluationHelper.cs:172-189`	Разработка (Владислав)	Open	(А) проверять каждую границу независимо и выровнять набор проверок между расчётом заказа и мобильным календарём — рекомендуется, сейчас расхождение видно пользователю как разный список способов оплаты; (Б) зафиксировать в BRD, что диапазон стоимости задаётся только целиком, а мобильный календарь показывает предварительный, неполный набор условий — дешевле, но закрепляет расхождение между интерфейсами. Связать с OQ2.4.2-12.	Исправить проверку диапазона итоговой стоимости заказа: применять нижнюю и верхнюю границы независимо, чтобы условие ограничивалось по сумме даже при заполненной только одной границе. В мобильном календаре передавать сумму заказа в расчёт условий оплаты и применять тот же набор проверок, что и при обычном расчёте заказа. Завести задачу в разработку.
OQ2.4.2-12	Код BR2.4.2-6	Требование говорит: время действия условия — один или несколько диапазонов времени; если не задано — весь день. В коде диапазон ровно один: два поля «время с» и «время по» на условии. Кроме того, проверяется только время окончания заказа — время начала не проверяется вообще, поэтому заказ, начавшийся до начала действия условия и закончившийся внутри него, условие пройдёт. И «время по = 00:00» служит признаком «верхняя граница не задана», из-за чего задать окончание действия ровно в полночь невозможно — такое значение неотличимо от «не задано». По остальным временным параметрам: дни недели хранятся и проверяются, но достаточно совпадения любого дня из периода заказа; период действия проверяется на пересечение с периодом заказа, а не на вложенность — то есть заказ, лишь частично попадающий в период действия условия, условие проходит. \ один диапазон — `PaymentFilters.cs:32-33`; только время окончания — `PaymentEvaluationHelper.cs:92-93`; трактовка 00:00 — там же и `PaymentFiltersAggregate.cs:157`; любой день из периода — `PaymentEvaluationHelper.cs:75-88`; пересечение периодов — `:73-74`	Бизнес/Разработка (Герман, Владислав)	Open	(А) привести BRD к коду: один диапазон времени, и явно описать выбранную семантику («любой день из периода», «пересечение периодов», проверка по времени окончания) — рекомендуется, семантика выглядит осознанной, но нигде не зафиксирована и потому не проверяема; (Б) признать целевыми несколько диапазонов времени и проверку начала заказа — это доработка модели и отбора. Сначала нужно решение бизнеса, какая семантика правильная.	Уточнить у бизнеса целевую логику временных ограничений условия оплаты: нужно ли поддерживать несколько диапазонов времени или достаточно одного; должно ли условие проверяться по времени окончания заказа или по всему интервалу заказа; достаточно ли совпадения хотя бы одного дня недели и частичного пересечения с периодом действия условия. Отдельно подтвердить, что значение «00:00» в поле «время по» должно означать отсутствие верхней границы времени.
OQ2.4.2-13	Код BR2.4.2-8	Требование говорит: по условию оплаты справочно отображаются две группы клиентов — аккаунты, на которые условие действует, и аккаунты, на которые оно не действует. В коде группа «не действует» отсутствует как понятие: хранится единственный список привязанных клиентов без признака включения или исключения. Пустой список означает «условие действует на всех», непустой — «только на перечисленных». И этот список не справочный: он реально применяется при отборе и при повторной проверке условия — клиент, не входящий в непустой список, условие не получит. Отдельно: сервис клиентов о привязке к условиям оплаты ничего не знает — там хранится только степень доверия и сумма штрафа, а сама привязка живёт в партнёрском сервисе. Получить список клиентов условия можно только из общего реестра условий — отдельной операции для этого нет. \ хранение — `AllowClientsOnPaymentFilters.cs:8-12`; применение при отборе — `PaymentFiltersReadOnlyRepository.cs:169-178`, `:676-690`; выдача в реестре — `:573`; в сервисе клиентов привязки нет — не найдено за обход `src/services/booking.clients`	Бизнес (Герман)	Open	(А) переписать требование под фактическую модель: один список «условие действует только на этих клиентов», он же — работающее ограничение, а не справка — рекомендуется, отражает реальность и снимает ложное ожидание списка исключений; (Б) подтвердить, что список исключений нужен, и завести доработку — тогда потребуется признак включения/исключения и изменение отбора. Связать с OQ2.4.2-22.
OQ2.4.2-14	Код BR2.4.2-9	Требование говорит: система не должна допускать сохранение условий оплаты с полностью идентичными параметрами. В коде такой защиты нет ни на одном слое. В обработчиках создания и изменения условия нет ни одного запроса на существующие условия и ни одной ошибки о дубликате. На уровне базы у таблицы условий оплаты объявлен только первичный ключ по идентификатору; уникальных индексов по ней не создаётся — при том что в этом же сервисе уникальные индексы создаются для других таблиц, а в других сущностях (сферы, группы позиций, опции) проверка дубликатов в обработчике есть. На шлюзе доменных проверок нет вообще. То есть создать два полностью одинаковых условия оплаты можно, и оба попадут в выдачу клиенту. \ нет проверки в обработчиках — `CreatePaymentFilterCommandHandler.cs:52-113`, `UpdatePaymentFilterCommandHandler.cs:54-167`; таблица и индексы — `PaymentFilters.cs:13-16`, `DbInitializer.cs:113-118` (уникальные индексы по другим таблицам — `:163`, `:406`, `:408`, `:473`); существующий образец проверки — `CreateSphereCommandHandler.cs:41-42`; шлюз — `RpcProxyController.cs:471`	Разработка (Владислав)	Open	(А) реализовать проверку в обработчике создания и изменения по составу значимых параметров (настройка, область действия, источники, опции, клиенты, диапазоны, дни, время) — рекомендуется, уникальный индекс по такому составу неудобен из-за связанных таблиц; (Б) ограничиться уникальностью по названию в пределах партнёрской зоны — дёшево, но не закрывает требование. Первым вопрос к бизнесу: считать ли дубликатом условия, различающиеся только комментарием и описанием.	Уточнить у бизнеса, считать ли дубликатами условия оплаты, которые отличаются только описанием или комментарием. После ответа добавить проверку дублей при создании и изменении условия оплаты по значимым параметрам: платёжная настройка, область действия, источники, опции, клиенты, диапазоны, дни недели и время действия. При найденном дубле запрещать сохранение условия оплаты и возвращать понятную ошибку.
OQ2.4.2-15	Код вне BRD	Что нашли: у условия оплаты есть параметр «только на сегодня», которого нет ни в одном требовании раздела. Если он включён, условие доступно только для заказов, начинающихся сегодня по местному времени площадки. Это полноценное бизнес-ограничение доступности сценария оплаты, наравне с днями недели и периодом действия. \ хранение — `PaymentFilters.cs:24`, `PaymentFiltersAggregate.cs:63`; проверка — `PaymentEvaluationHelper.cs:90-91`; вычисление «сегодня» по местному времени — `GetAllowedPaymentFiltersBulkQueryHandler.cs:141-142`	Бизнес (Герман)	Open	(А) добавить параметр в требование BR2.4.2-6 как ещё одно временное ограничение — рекомендуется, он там по смыслу и уже работает; (Б) признать параметр устаревшим и вывести из оборота — требует проверки, сколько действующих условий его используют.
OQ2.4.2-16	Код вне BRD	Что нашли: условие оплаты невозможно удалить — операции удаления нет ни в командах, ни в репозитории, ни в перечне методов сервиса. Единственный способ вывести условие из оборота — архивация. При этом архивация ограничена не описанным в BRD бизнес-правилом: перевести условие в архив нельзя, если по его площадкам есть будущие заказы в статусе «Резерв» — система обращается за этим в сервис заказов и отказывает с сообщением об активных бронированиях. Дополнительно архивация требует отдельного права, отличного от права на изменение. \ отсутствие удаления — не найдено за обход `Commands/PaymentFilters/`, `IPaymentFiltersRepository.cs:12-24`, `PartnerZoneMethodMessageCatalog.cs`; правило архивации — `UpdatePaymentFilterCommandHandler.cs:92-93`, `:169-190`; отдельное право — `:119-125`	Бизнес (Герман)	Open	(А) описать в BR2.4.2-7, что удаления нет по замыслу, а архивация запрещена при будущих бронях в «Резерве» — рекомендуется, правило защищает уже принятые заказы и стоит того, чтобы быть зафиксированным; (Б) подтвердить необходимость удаления условий — потребует решения, что делать со ссылками из уже созданных заказов.
OQ2.4.2-17	Код вне BRD	Что нашли: срок на оплату заказа существует, доезжает до заказа и никем не используется. Значение задаётся в платёжной конфигурации партнёрской зоны как число минут, при проверке условия отдаётся заказу без каких-либо вычислений и записывается в заказ полем «время жизни». Дальше цепочка обрывается: это поле не читает ни одна фоновая задача и ни один обработчик — оно уходит только в интерфейс как справочная величина. Автоотмены неоплаченного заказа по истечении срока в системе нет: фоновых задач ровно две, обе про заявки, а не про заказы, и ни одна из них это поле не смотрит. Дедлайн оплаты как дата нигде не хранится — только число минут, без точки отсчёта, поэтому вычислить момент истечения по данным заказа нельзя. Начальное значение при создании заказа — «максимально возможное число», то есть фактически «бессрочно». Срок жизни ссылки на онлайн-оплату к этому сроку отношения не имеет: он захардкожен пятью минутами и настройками партнёрской зоны не управляется. Захардкоженных сроков подтверждения на 4 или 24 часа в коде не найдено. \ источник — `PaymentSettings.cs:56-57`; проброс без вычислений — `ValidatePaymentFilterAndGetTtlQueryHandler.cs:148-168`; запись в заказ — `OrderAggregate.cs:525-531`, `OrderModel.cs:21`; начальное значение — `CreateOrderCommandHandler.cs:31`, `:250`; отсутствие автоотмены — не найдено за обход `Orders.Infrastructure/Jobs/` (единственная задача — отклонение заявок, `AutoRequestCancellingJob.cs:14`), `RequestExpirationBackgroundService.cs:13-15`; захардкоженные 5 минут — `TinkoffPaymentService.cs:363-373`, `InitOnlinePaymentCommandHandler.cs:110-118`	Бизнес/Разработка (Герман, Владислав)	Open	(А) подтвердить, что автоотмена неоплаченного заказа нужна, и завести доработку: хранить момент истечения (а не число минут) и добавить фоновую отмену — рекомендуется, сейчас настраиваемый срок оплаты создаёт у партнёра ложное ожидание, что он на что-то влияет; (Б) признать срок чисто информационным и зафиксировать это в BRD раздела Back 2.8, убрав ожидание автоотмены. Первым нужно решение бизнеса.	Уточнить у бизнеса назначение срока на оплату заказа: должен ли этот срок автоматически отменять неоплаченный заказ или должен отображаться только как справочная информация. Если нужна автоотмена, доработать логику заказа: сохранять конкретный момент истечения срока оплаты и добавить фоновую отмену неоплаченных заказов после этого момента. Если автоотмена не нужна, зафиксировать в BRD, что срок оплаты является только информационным и не влияет на статус заказа.
OQ2.4.2-18	Код вне BRD	Что нашли: в выдачу доступных условий подмешивается условие уровня партнёрской зоны со сценарием «На месте», не проходя ни одной проверки отбора. Оно срабатывает для веб-источников, календаря Google, событий приложения и YClients, а также при отсутствии аккаунта, и отдаётся клиенту с пустыми названием, комментарием, процентом предоплаты и сроком оплаты. Связанное правило в сервисе заказов: если условие оплаты при создании заказа не выбрано, для тех же источников система сама подбирает условие со сценарием «На месте» и методом «наличные», сортируя по возрастанию процента предоплаты; если такого условия нет — создание заказа падает с ошибкой о недоступности оплаты наличными. Для остальных источников невыбранное условие сразу приводит к отказу. \ подмешивание без проверок — `PaymentFiltersReadOnlyRepository.cs:489-536`, `GetAllowedPaymentFiltersBulkQueryHandler.cs:57-61`, `:109-122`; автоподбор и отказы — `CreateOrderCommandHandler.cs:214-233`; пропуск повторной проверки для этой ветки — `:370-411`	Бизнес (Герман)	Open	(А) описать «оплату на месте на уровне партнёрской зоны» как отдельное системное условие по умолчанию и зафиксировать, что на него ограничения не распространяются — рекомендуется, поведение рабочее, но сейчас это скрытое исключение из BR2.4.2-1; (Б) прогонять и это условие через общий отбор — изменит поведение веб-заказов, требует оценки рисков.
OQ2.4.2-19	Код вне BRD	Что нашли: для процессинговых групп (эквайринг) действует отдельный, гораздо более жёсткий отбор условий оплаты, не описанный в BRD: берутся только неархивные условия со сценарием «Онлайн в интерфейсе» и ровно 100% предоплаты, у которых источник привязан к платёжному каналу. Проверки по датам, времени, дням недели, сумме, штрафу, клиенту и опциям здесь не применяются вовсе. То есть у одного и того же условия оплаты два разных режима применения в зависимости от того, кто его запрашивает. \ `PaymentFiltersReadOnlyRepository.cs:736-779` (сценарий — `:760`, ровно 100% — `:761`, источник — `:762-764`)	Бизнес (Герман)	Open	(А) описать процессинговый отбор отдельным требованием (возможно, в разделе Back 5.1) со ссылкой отсюда — рекомендуется, правило про «ровно 100%» имеет денежные последствия и сейчас нигде не зафиксировано; (Б) оставить неописанным как техническую деталь эквайринга — не рекомендуется: условие с 99% предоплаты молча выпадет из процессинга без объяснимой для партнёра причины.
OQ2.4.2-20	Код вне BRD	Проблема: при изменении условия оплаты можно случайно стереть всю его область действия. Обработчик изменения всегда создаёт список области действия и передаёт его в условие, даже если в запросе не переданы ни объекты, ни площадки — в этом случае уходит пустой (но не «отсутствующий») список, а механизм отслеживания изменений трактует как «не менять» только отсутствующий список. В результате все привязки к объектам и площадкам затираются. Дополнительное последствие: партнёрская зона условия вычисляется по первой строке области действия, поэтому после затирания условие теряет и привязку к партнёрской зоне. \ `UpdatePaymentFilterCommandHandler.cs:80`, `:82-90`, `:105`; трактовка пустого списка — `PaymentFiltersAggregate.cs:312`, `ChangeTracker.cs:146-149`; вычисление партнёрской зоны — `PaymentFiltersAggregate.cs:46`	Разработка (Владислав)	Закрывает PM	Закрываю сам: передавать «отсутствующий» список, когда объекты и площадки в запросе не заданы, — продуктового выбора нет → тикет в Bitrix. Стоит также проверить существующие данные на условия с пустой областью действия.	Исправить изменение условия оплаты: если в запросе не переданы объекты и площадки, не передавать пустой список области действия и не менять текущие привязки условия. Пустой список должен использоваться только как явная команда очистить область действия, если такая операция разрешена. Дополнительно проверить существующие условия оплаты с пустой областью действия. Завести задачу в разработку.
OQ2.4.2-21	Код вне BRD	Проблема: диапазоны условия сохраняются без проверки «начало не больше конца». Для диапазона стоимости заказа и диапазона штрафа проверок нет вообще — можно сохранить условие, которое не сработает никогда. Для диапазона времени проверка написана, но закомментирована. Проверка есть только для периода дат, и на частичном изменении она опасна: при изменении одной лишь даты начала она сравнивается с уже сохранённой датой окончания, что может неожиданно уронить изменение. Незаданные границы при этом молча заменяются на 0, «максимально возможное число» и границы календаря. \ отсутствие проверки — `PriceRange.cs:8-12`; закомментированная проверка времени — `TimeRange.cs:12`; проверка дат — `DateOnlyRange.cs:11-17` и её применение на изменении `PaymentFiltersAggregate.cs:315-317`; подстановка границ — `:154-157`	Разработка (Владислав)	Закрывает PM	Закрываю сам: добавить проверку «начало ≤ конец» для диапазонов стоимости и штрафа и решить судьбу закомментированной проверки времени → тикет в Bitrix.	Добавить проверку диапазонов при создании и изменении условия оплаты: начало диапазона не должно быть больше конца для стоимости заказа, штрафа, времени действия и периода действия. При частичном изменении проверять итоговый диапазон после применения новых значений к уже сохранённым. Некорректные диапазоны не сохранять и возвращать понятную ошибку. Завести задачу в разработку.
OQ2.4.2-22	Код вне BRD	Что нашли: у характеристики клиента есть значение «особые условия предоплаты», которое не обрабатывается нигде — оно объявлено в перечислении и больше не встречается ни в одной строке кода. Клиент с таким значением попадает в общую ветку и обрабатывается как обычный. Это важно для BR2.4.2-8: требование говорит о клиентах, «связанных персональными условиями оплаты», а единственный механизм персональных условий, реально работающий в коде, — это список привязанных к условию клиентов, а не характеристика клиента. \ объявление — `ClientPayKind.cs:32`; обработанные значения — `PaymentEvaluationHelper.cs:43-44`, `:46-57`, `:238-248`; отсутствие обработки — не найдено за обход всего `src/`	Бизнес (Герман)	Open	(А) решить судьбу значения «особые условия предоплаты»: либо описать, что оно должно делать, и реализовать, либо вывести его из перечисления — рекомендуется, необработанное значение в справочнике читается пользователем как работающая настройка; (Б) оставить как зарезервированное и пометить это в BRD Back 1.3.2. Связать с OQ2.4.2-13.

BRD

Explorer