Направление работ: Back Код раздела: 2.8 Объекты и предложения > Настройки партнерской зоны Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 27.07.26
1. Назначение
Настройки партнерской зоны определяют формат взаимодйствия партнера с платформой и ее сотрудниками, а также собственными сотрудниками и клиентами.
Система хранит параметры документооборота, уведомлений, платежей, работы с заказами, правил оказания услуг, продления доступа и сотрудников в контексте конкретной партнерской зоны.
Детальная логика связанных процессов раскрывается в соседних разделах; текущий раздел фиксирует состав и правила применения настроек партнерской зоны.
2. Ключевые понятия
Настройки партнерской зоны — набор параметров, которые определяют формат взаимодйствия партнера с платформой и ее сотрудниками, а также собственными сотрудниками и клиентами.
Партнерская зона — обособленная сущность партнера в системе, к которой относятся объекты, площадки, услуги, сотрудники, платежные и операционные настройки.
Организация — данные юридического лица партнерской зоны, необходимые для автоматизации документооборота между платформой и партнером.
Платежная информация — записи с параметрами онлайн-платежей и инструкциями оплаты, которые используются для заказов, сборов и других объектов оплаты.
Параметры работы с заказами — стандартные сроки, режимы и сценарии, которые применяются к бронированиям, сборам, заявкам и группам заказов в партнерской зоне.
3. Scope
Входит
S1 Организация
- Договор, форма собственности, данные организации, адреса, учредители и банковские реквизиты для партнерских зон с типом “Юридическое лицо”.
S2 Уведомления
- Варианты почтовой рассылки по партнерской зоне.
- Дополнительные каналы доставки после их реализации.
S3 Платежная информация
- Параметры онлайн-платежей.
- Валидация связи параметров онлайн-платежей с условиями оплаты.
- Инструкции оплаты для дальнейшей привязки к заказам, сборам и другим объектам оплаты.
S4 Параметры работы с заказами
- Сроки и сценарии по бронированиям, сборам, блокировке клиентов, заявкам и группам заказов.
- Параметры групп заказов, включая настройки автопролонгации и сценарии оплаты абонементов.
S5 Правила и условия заказов
- Правила оказания услуг.
- Условия создания, условия оплаты, правила отмены и правила списания баллов, используемые по умолчанию или для привязки к объектам и площадкам.
S6 Связанные настройки доступа
- Параметры активации и продления доступа.
- Список сотрудников партнерской зоны как связанная информация текущего раздела.
Не входит
- Базовая сущность и тип партнерской зоны — Back: 1.4
- Доступные права по активному тарифу — Back: 1.4.1
- Логика ролей сотрудников — Back: 1.2.1
- Детальная логика условий создания заказов — Back: 2.4.1
- Детальная логика условий оплаты заказов — Back: 2.4.2
- Детальная логика правил отмены — Back: 2.4.3
- Детальная логика правил списания баллов — Back: 2.7.3
- Процесс продления доступа и уведомления о продлении — Back: 2.8.1
- Обработка бронирований, заявок и сборов — Back: 3.2, Back: 3.2.1
- Каналы, объекты, сценарии, методы и провайдеры оплаты — Back: 5.1, Back: 5.1.1, Back: 5.1.2, Back: 5.5
- Настройка входящих и отправленных уведомлений — Back: 7.2.1, Back: 9.3
- Сервисные документы и загруженные файлы — Back: 8.2.7, Back: 9.6.1
- UI настроек правил работы, продления доступа, сотрудников и доступа в интерфейсе партнера — WebLk
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: #BR2.8-1 | Настройки партнерской зоны должны храниться в контексте конкретной партнерской зоны. | Настройки определяют формат взаимодйствия партнера с платформой и ее сотрудниками, а также собственными сотрудниками и клиентами. | Системное | 1 | Реализовано |
| S1: #BR2.8-2 | Партнерская зона с типом “Юридическое лицо” должна хранить организационные данные для документооборота. | Состав данных: - договор с юридическим лицом (PDF-файл) - форма собственности: ИП или ООО - данные организации: полное наименование, сокращенное наименование, ИНН, КПП, ОКВЭД, ОГРН, регистрационный орган, дата регистрации, оператор ЭДО, идентификатор ЭДО - адреса: тип, индекс, страна, город, улица - учредители: номер, имя, фамилия, отчество, дата рождения, телефон - банковские реквизиты: название счета, наименование банка, БИК, расчетный счет, корреспондентский счет Тип партнерской зоны раскрывается в Back: 1.4. | Системное | 1 | Частично \ #OQ2.8-4 \ #OQ2.8-18 |
| S2: #BR2.8-3 | Настройки уведомлений партнерской зоны должны задавать вариант почтовой рассылки уведомлений. | Допустимые значения: - отправка только на адрес владельца партнерской зоны (значение по умолчанию) - отправка только на адрес партнерской зоны - отправка на адрес партнерской зоны и владельца компании Логика настройки входящих уведомлений раскрывается в Back: 7.2.1. | Бизнес | 1 | Не реализовано \ #OQ2.8-2 |
| S2: #BR2.8-4 | Настройки партнерской зоны должны поддерживать дополнительные каналы отправки уведомлений (после релиза реализация). | Каналы после реализации: боты, SMS, мессенджеры. Логика доставки уведомлений раскрывается в Back: 7.2.1. | Системное | 3 | Частично \ #OQ2.8-13 |
| S3: #BR2.8-5 | Параметры онлайн-платежей должны хранить данные, необходимые для проведения платежей по сценарию “Онлайн в интерфейсе”. | Состав данных: - название - провайдер онлайн-оплат - терминал из списка привязанных к каналам оплат партнерской зоны - банковские реквизиты из данных организации - реквизиты в среде провайдера - размер удержания с операции - детали платежа - сценарий возврата: автоматический или ручной - срок на оплату заказа в минутах - дата создания записи - дата последней операции по параметрам Детальная логика каналов, объектов, сценариев и методов оплаты раскрывается в Back: 5.1, Back: 5.1.1 и Back: 5.1.2. | Системное | 1 | Частично \ #OQ2.8-15 \ #OQ2.8-16 |
| S3: #BR2.8-6 | Параметр приема онлайн-платежей должен связываться только с условием оплаты, которое соответствует заданным параметрам валидации. | Параметры валидации: - разрешенный размер предоплаты — допустимый диапазон значений от 0 до 100 для размера предоплаты, заданного у условия оплаты; - разрешенные объекты оплаты — допустимые объекты оплаты, заданные у условия оплаты; - разрешенные методы оплаты — допустимые методы оплаты, заданные у условия оплаты; - разрешенные источники — допустимые источники заказа, заданные у условия оплаты. | Системное | 1 | Не реализовано \ #OQ2.8-20 |
| S3: #BR2.8-7 | Инструкции оплаты должны хранить данные для проведения платежей по сценарию “По инструкции”. | Состав данных: - название инструкции - ссылка на инструкцию - срок подтверждения оплаты клиентом (по умолчанию 4 часа) - срок подтверждения зачисления средств (по умолчанию 24 часа) Детальная логика сценариев оплаты раскрывается в Back: 5.1.2. | Системное | 1 | Не реализовано \ #OQ2.8-1 |
| S4: #BR2.8-8 | Параметры работы с бронированиями должны задавать срок автоматического завершения бронирований. | Срок задается количеством часов с момента завершения заказа, после которого бронь переходит в статус “завершена”. Значение по умолчанию: 48 часов. Логика процессинга бронирований раскрывается в Back: 3.2. | Бизнес | 1 | Не реализовано \ #OQ2.8-3 |
| S4: #BR2.8-9 | Параметры работы со сборами должны задавать режим начисления сборов и формат блокировки клиентов. | Допустимые значения: - режим начисления сборов: сразу после отмены (по умолчанию), с подтверждением - формат блокировки клиентов: автоматический (по умолчанию), ручной - блокировать после: целое число нарушений правил отмены с непогашенным штрафом (по умолчанию 1) Логика сборов раскрывается в Back: 3.2.1. | Бизнес | 1 | Реализовано |
| S4: #BR2.8-10 | Параметры работы со сборами должны задавать доступные сценарии оплаты сборов. | Допустимые значения: - в составе будущих заказов (по умолчанию всегда) - в приложении (доступно при наличии параметров онлайн-платежей) - по параметрам онлайн-платежа заказа, отмененного со сбором - по отдельным реквизитам - по инструкции (доступно при наличии инструкции) Детальная логика платежных сценариев раскрывается в Back: 5.1.2. | Бизнес | 2 | Не реализовано \ #OQ2.8-10 \ #OQ2.8-19 |
| S4: #BR2.8-11 | Параметры работы с заявками должны задавать сроки автоотклонения и количество продлений работы с заявками. | Состав данных: - срок автоотклонения поступивших заявок днем (по умолчанию 4 часа) - срок автоотклонения поступивших заявок ночью (по умолчанию 12 часов) - срок автоотклонения заявок в работе (по умолчанию 12 часов) - количество продлений работы с заявками (по умолчанию 2) Логика обработки заявок раскрывается в Back: 3.2. | Бизнес | 1 | Частично \ #OQ2.8-14 |
| S4: #BR2.8-12 | Параметры работы с заявками должны задавать сценарии оплаты заказов, созданных по подтвержденным заявкам. | Допустимые значения: - на месте (по умолчанию всегда) - в приложении (доступно при наличии параметров платежей) - по инструкции (доступно при наличии инструкции) Детальная логика платежных сценариев раскрывается в Back: 5.1.2. | Бизнес | 2 | Частично \ #OQ2.8-11 |
| S4: #BR2.8-13 | Параметры работы с группами заказов должны хранить настройки автопролонгации и сценарии оплаты абонементов. | Состав параметров: - настройка автопролонгации; - сценарии оплаты абонементов. Детальная логика групп заказов и абонементов раскрывается в соседних разделах по процессингу заказов. | Системное | 2 | Не реализовано \ #OQ2.8-12 \ #OQ2.8-17 |
| S5: #BR2.8-14 | Партнерская зона должна хранить правила оказания услуг. | Допустимые форматы: - текстовые правила в HTML-формате - PDF-файл По умолчанию используются стандартные сервисные правила в HTML-формате. Управление сервисными документами раскрывается в Back: 8.2.7, хранение файлов - в Back: 9.6.1. | Системное | 1 | Частично \ #OQ2.8-5 |
| S5: #BR2.8-15 | Партнерская зона должна хранить списки условий создания, условий оплаты, правил отмены и правил списания баллов для привязки к объектам и площадкам. | Состав списков: - условия создания заказов (по умолчанию добавлено одно условие создания) - условия оплаты заказов (по умолчанию добавлено одно условие оплаты) - правила отмены (по умолчанию добавлен набор глобальных правил отмены для сфер) - правила списания баллов (по умолчанию баллы не принимаются) Детальная логика условий и правил раскрывается в Back: 2.4.1, Back: 2.4.2, Back: 2.4.3 и Back: 2.7.3. | Системное | 1 | Частично \ #OQ2.8-6 |
| S6: #BR2.8-16 | Настройки партнерской зоны должны хранить параметры активации и продления доступа. | Состав данных: - флаг автопродления - срок перехода комиссии к оплате - срок погашения комиссии (по умолчанию 7 дней) - сумма, обязательная для погашения - сумма заказов без начисления комиссии - сумма комиссии без начисления Процесс продления доступа и рассылка уведомлений о продлении раскрываются в Back: 2.8.1. | Системное | 1 | Частично \ #OQ2.8-7 |
| S6: #BR2.8-17 | По партнерской зоне должен транслироваться список сотрудников, сгруппированный по ролям. | Состав и правила связи: - сотрудник добавляется через новый или существующий аккаунт пользователя - после добавления сотруднику отправляется уведомление с информацией о партнере и учетными данными, если был привязан новый аккаунт - по умолчанию есть один сотрудник - владелец партнерской зоны - владелец обладает всеми правами активного тарифа доступа - владелец может передать права другому аккаунту, если этот аккаунт является сотрудником текущей партнерской зоны Логика аккаунтов, ролей и прав доступа раскрывается в Back: 1.2.1 и Back: 1.4.1. | Системное | 1 | Не реализовано \ #OQ2.8-8 \ #OQ2.8-9 \ #OQ2.8-18 |
5. Открытые вопросы
Вопросы прогнаны через гайдбук 2.8. Нумерация требований обновлена (добавлены BR2.8-6 «валидация связи онлайн-платежа с условием оплаты» и уточнён BR2.8-13 «группы заказов» — из-за них сдвинулись номера с BR2.8-6 и далее); ссылки OQ приведены к новой нумерации. Гайдбук подтвердил дословно: три варианта почтовой рассылки, сроки инструкций 4ч/24ч, срок автозавершения брони 48ч, дефолты заявок 4/12/12/2, PDF-формат правил услуг, все 6 полей активации/продления, передачу прав владельца, множественный выбор сценариев сборов, добавление сотрудника «новый ИЛИ существующий». Гайдбук добавил сущности, которых нет в BRD: «Максимальная длительность групп» (деф. 1 год), «Расчёт заказов в группах», «Параметры абонементов» с типом границы дат — вынесены отдельными вопросами. Дефолты заявок разошлись: BRD «автоотклонение днём/ночью», гайдбук «обработка днём/ночью + автоотклонение» (5 полей против 4).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации |
|---|---|---|---|---|---|
| #OQ2.8-1 | Код BR2.8-7 | Требование говорит: инструкция оплаты хранит срок подтверждения оплаты (деф. 4 ч) и срок подтверждения зачисления (деф. 24 ч). В коде обоих полей нет вовсе: CreateOnInstruction принимает только название/описание/ссылку/процент; колонок сроков в БД нет, дефолтов 4/24 нет. \ PaymentSettingsAggregate.cs:221-254; CreatePaymentSettingCommand.cs:27-28 | Разработка (Влад) | Open | Гайдбук подтверждает дословно: «Срок подтверждения оплаты клиентом — по умолчанию 4 часа; Срок подтверждения зачисления средств — по умолчанию 24 часа» — значит поля целевые, вариант «перенести в 5.1.2» отпадает. Рекомендация: добавить оба срока с дефолтами 4/24 на инструкцию оплаты в этом сервисе. Процессинг подтверждения — 5.1.2, но хранение сроков — здесь. |
| #OQ2.8-2 | Код BR2.8-3 | Требование говорит: режим почтовой рассылки — только владелец (деф.) / только зона / зона и владелец. В коде такого переключателя нет: в booking.notifications хранится плоский список email-контактов зоны без различения владелец/зона; дефолт «только владелец» не засевается. \ PartnerZoneContacts.cs:20-24; ContactType.cs:3-8 | Бизнес/Разработка | Open | Гайдбук подтверждает три варианта дословно (владелец / зона / зона+владелец, деф. владелец) — модель-переключатель целевая, «список контактов» её не заменяет. Рекомендация: реализовать трёхзначный режим рассылки с дефолтом «только владелец» на настройках зоны; список email-контактов оставить как адресатов. Логика входящих — 7.2.1. |
| #OQ2.8-3 | Код BR2.8-8 | Требование говорит: срок автозавершения брони в часах с момента завершения заказа, деф. 48 ч. В коде такого срока в настройках зоны нет: в OrderManagement только срок оплаты (0–24 ч, max 24 — 48 недостижимо); дефолт 48 за обход partner-management не найден. \ OrderPayManagementAggregate.cs:10-12,65-69 | Бизнес/Разработка | Open | Гайдбук подтверждает 48 ч как настройку зоны в блоке «Брони», но сам блок помечает «см. 3.2 Процессинг заказов». Решение: подтвердить границу — если срок автозавершения хранится как настройка зоны, реализовать здесь (сейчас нет); если он живёт в booking.orders (3.2), уточнить в BR2.8-8 ссылку на источник. |
| #OQ2.8-4 | Код BR2.8-2 | Требование говорит: состав данных организации, в т.ч. учредители (номер, имя, фамилия, отчество, дата рождения, телефон) и договор (PDF). В коде реквизиты/адреса/ЭДО/банк — есть, но: «учредители» хранятся как ОДИН Founder (не список); ссылки/файла договора в сущности организации нет; сверх BRD хранится система налогообложения TaxationSystem. \ Company.cs:25; CompanyDetails.cs:22-23 | Бизнес/Разработка | Open | Гайдбук перечисляет «Данные организации» обобщённо и не уточняет ни множественность учредителей, ни хранение файла договора (договор — «PDF-файл», хранение файлов — 9.6.1). Подтвердить нечем. Решение: (А) привести к BRD — учредители списком, ссылка на договор (файл — 9.6.1), узаконить/убрать TaxationSystem; (Б) привести BRD к коду (один учредитель + налоговая система). За продуктом целевой состав. |
| #OQ2.8-5 | Код BR2.8-14 | Требование говорит: правила оказания услуг — HTML ИЛИ PDF; по умолчанию стандартные сервисные правила в HTML. В коде хранится только HTML-текст, PDF не смоделирован; «стандартные правила» берутся из дефолта СФЕРЫ и копируются при создании БАЗЫ, не зоны. \ TextBookingRuleAggregate.cs:15-16; CreateFromDefaultTextBookingRuleCommandHandler.cs:37,55 | Бизнес/Разработка | Open | Гайдбук подтверждает оба формата («текстовые в HTML; PDF-файл»), но дефолт уводит в 8.4 Параметры системы («стандартные сервисные правила в HTML — см. 8.4»), а не в дефолт сферы. Решение: (А, рекоменд.) добавить PDF-вариант и привязать «стандартный» дефолт к параметрам системы (8.4), а не к сфере; (Б) оставить HTML+дефолт сферы и уточнить BR2.8-14. PDF-файл — хранение 9.6.1. |
| #OQ2.8-6 | Код BR2.8-15 | Требование говорит: списки — условия создания (деф. 1), условия оплаты (деф. 1), правила отмены (деф. набор глобальных по сферам), правила списания баллов (деф. не принимаются). В коде правила отмены и 1 условие оплаты сидируются; но «условия создания» в коде = BookingRuleSet (часы), а FixedCondition — тарифный биллинг без partner_zone_id; списка «правил списания баллов» нет, дефолт «не принимаются» не задаётся. \ CreateFromDefaultCommandHandler.cs:42-73; BookingRuleSetAggregate.cs:44-58; FixedConditionAggregate.cs:13-19 | Бизнес/Разработка | Open | Гайдбук подтверждает все 4 списка и их дефолты, причём дефолты — из 8.4 Параметры системы (условие создания/оплаты «По умолчанию», набор правил отмены по сферам), а «Приём баллов — по умолчанию баллы не принимаются». Значит списки целевые. Решение: согласовать маппинг терминов (что в коде соответствует «условиям создания/оплаты») и завести список «правил списания баллов» с дефолтом «не принимаются». Пересекается с 2.4.1/2.4.2/2.7.3. |
| #OQ2.8-7 | Код BR2.8-16 | Требование говорит: параметры активации/продления — флаг автопродления, срок перехода к оплате, срок погашения (деф. 7 дн), сумма обязательная, сумма заказов без комиссии, сумма комиссии без начисления (6 полей). В коде есть 2 из 6: срок перехода и срок погашения (деф. 7); нет флага автопродления и трёх «сумм», подсистемы продления в сервисе нет. \ CommissionSettings.cs:13,18,20 | Бизнес/Разработка | Open | Гайдбук подтверждает все 6 полей поимённо (Автопродление, Срок перехода комиссии, Срок погашения деф. 7 дн, Сумма обязательная, Сумма заказов без начисления, Сумма комиссии без начисления) — значит недостающие 4 целевые. Гайдбук отсылает процесс к 2.8.1, но сами поля-настройки живут в зоне. Решение: реализовать 4 недостающих поля здесь; процесс продления — 2.8.1. Связать с 1.4.1 (активный тариф). |
| #OQ2.8-8 | Код BR2.8-17 | Требование говорит: владелец может передать права другому аккаунту, если тот — сотрудник текущей зоны. В коде механизма передачи прав владельца нет во всём репозитории; OwnerId задаётся только при создании и далее не меняется. \ PartnerZoneAggregate.cs:173 | Разработка (Влад) | Open | Гайдбук подтверждает дословно: «Владелец может передать свои права другому аккаунту при условии, что этот аккаунт является сотрудником данной партнёрской зоны». Продуктового выбора нет — это недоделка. Рекомендация: реализовать команду передачи прав владельца с проверкой «новый владелец — сотрудник зоны». Модель прав — 1.2.1/1.4.1. |
| #OQ2.8-9 | Код BR2.8-17 | Требование говорит: по умолчанию один сотрудник — владелец; владелец обладает всеми правами активного тарифа. В коде «владелец = все права тарифа» отдельно не обеспечивается: авто-доступ ко всему только у роли Admin, владелец — лишь метка; явного сотрудника-владельца по умолчанию нет (выражен через OwnerId). \ IsAuthorizedQuery.cs:118-128 | Бизнес/Разработка | Open | Гайдбук подтверждает: «владелец обладает всеми правами активного тарифа доступа», «доступные права определяются активным тарифом (см. 1.4.1)». Значит целевая модель — владелец получает права от тарифа, а не через Admin-bypass. Решение: согласовать реализацию прав владельца с 1.4.1 (там резолвер сейчас заглушка return true — OQ1.4.1-5). До включения проверки прав владельца это не enforce-ится. |
| #OQ2.8-10 | Код BR2.8-10 | Требование говорит: сценарии оплаты сборов — множественный выбор (в составе будущих заказов деф.; в приложении; по параметрам онлайн-платежа отменённого заказа; по отдельным реквизитам; по инструкции). В коде множественного выбора нет: в ForfeitSettings только InFutureOrders (bool) и PaymentSettingsId; остальные не смоделированы; висит //Todo: множественный выбор. \ ForfeitSettings.cs:33-35 | Бизнес/Разработка | Open | Гайдбук подтверждает множественный выбор и его состав (в приложении: по параметрам онлайн-платежа отменённого заказа / по отдельным реквизитам; по инструкции — при наличии инструкции). Значит целевой набор шире, чем bool. Рекомендация: реализовать множественный выбор сценариев сборов по составу гайдбука с условной доступностью «в приложении/по инструкции». Процессинг сборов — 3.2.1. |
| #OQ2.8-11 | Код BR2.8-12 | Требование говорит: сценарии оплаты заказов по подтверждённым заявкам — на месте (деф.), в приложении (при наличии параметров), по инструкции (при наличии инструкции). В коде сценарии есть как общие PaymentSettings зоны (enum OnSite/OnlineInterface/ByInstruction), но НЕ привязаны к заявкам; «на месте» сидируется; условная доступность не проверяется. \ PaymentScenarioType.cs:3-8; RequestSettings.cs:14-29 | Бизнес/Разработка | Open | Гайдбук уточняет модель: «Условие оплаты бронирований по подтверждённым заявкам» = «На месте (системное, деф.)» ИЛИ «одно из добавленных условий оплаты (см. 2.4.2)». То есть привязка идёт не к общим сценариям, а к условиям оплаты заявок. Решение: реализовать выбор условия оплаты для заявок (на месте по умолчанию + ссылка на условие оплаты 2.4.2), а не переиспользовать общий enum. |
| #OQ2.8-12 | Код BR2.8-13 | Требование говорит: группы заказов хранят настройки автопролонгации и сценарии оплаты абонементов. В коде в PositionGroup нет ни автопролонгации, ни сценариев оплаты абонементов (только type/info/архив/сферы); «абонемент» реализован как ProcessingGroup в booking.orders (вне scope). \ PositionGroupAggregate.cs:20-26 | Бизнес/Разработка | Open | Гайдбук разворачивает блок «Группы заказов» шире BRD: «Максимальная длительность групп (деф. 1 год)», «Расчёт заказов в группах (деф. не рассчитываются)», а «Параметры абонементов» — отдельный блок с типом границы дат (см. OQ2.8-17). Автопролонгации/сценариев оплаты абонементов гайдбук в этом виде не называет. Решение: согласовать целевой состав настроек групп по гайдбуку (длительность, расчёт) и уточнить, где живут автопролонгация/оплата абонементов (ProcessingGroup — 3.3?). BR2.8-13 помечен в BRD «НЕ РЕАЛИЗОВАНО, результат мультирасчётов» — статус подтверждён. |
| #OQ2.8-13 | Код BR2.8-4 | Проблема: BR2.8-4 помечен «после релиза», но в booking.notifications каналы SMS и Telegram-бот для зон уже присутствуют и подключены к отправке; канала «мессенджеры» (кроме Telegram) нет. \ SmsChannel.cs; TemplateChannelSender.cs:192,292 | Бизнес/Разработка | Open | Гайдбук называет три канала (боты, SMS, мессенджеры) «после их реализации» — но по факту боты и SMS уже реализованы, то есть пометка «после релиза» устарела. Рекомендация: обновить статус BR2.8-4 — зафиксировать, что SMS и Telegram-бот уже доступны, а «мессенджеры» (прочие) остаются на будущее. Логика доставки — 7.2.1. |
| #OQ2.8-14 | Код BR2.8-11 | Проблема: все 4 поля заявок есть (RequestSettings), но хранятся ПО СФЕРАМ, не как единый параметр зоны. Класс Options.RequestSettings с точными дефолтами BRD (4/12/12/2) внедрён в обработчик создания, но нигде не читается — значения копируются из настроек каждой сферы; зонный дефолт не применяется. \ CreatePartnerZoneCommandHandler.cs:26,45,66-72 | Бизнес/Разработка | Open | Расхождение состава BRD↔гайдбук: BRD даёт 4 поля («автоотклонение днём 4ч / ночью 12ч / в работе 12ч / продлений 2»), а гайдбук — 5 («срок обработки днём 4ч / ночью 12ч / автоотклонение необработанных 12ч / автоотклонение в работе 12ч / продлений 2»), разведя «обработку» и «автоотклонение». Решение: (1) согласовать состав (4 или 5 полей — гайдбук новее, 27.07); (2) решить, дефолт зонный (тогда задействовать Options 4/12/12/2, сейчас мёртвый) или из сферы. |
| #OQ2.8-15 | Код BR2.8-5 | Проблема (два дефекта пути редактирования онлайн-платежа): (1) доменный Update() не обновляет UpdatedAt — «дата последней операции» не двигается при обычном редактировании (меняется лишь в Archive/Restore); (2) if (Account != null) Account = account; проверяет текущее свойство, а не параметр → расчётный счёт обновляется некорректно. \ PaymentSettingsAggregate.cs:107-140,133-134 | Разработка (Влад) | Open | Гайдбук подтверждает состав («Дата последней операции по параметрам — выводится в справочных целях», банковские реквизиты из данных организации). Оба — программные баги, продуктового выбора нет. Рекомендация: в Update() обновлять UpdatedAt; исправить if (Account != null) → проверку параметра account. |
| #OQ2.8-16 | Код BR2.8-5 | Проблема: отдельного поля «провайдер» нет — провайдер выводится из канала оплаты PayChannelId; «сценарий возврата» — это bool AutoRefund, а не enum авто/ручной. \ PaymentSettingsAggregate.cs:32,41 | Бизнес/Разработка | Open | Гайдбук: «Провайдер онлайн-оплат — см. 5.5» (значит вывод из канала/провайдера — by design, отдельного поля не требуется) и «Сценарий возврата: автоматический / ручной» (два значения — bool их покрывает). Расхождение косметическое. Решение: зафиксировать в BRD, что провайдер берётся из канала (5.5), а bool AutoRefund достаточно для авто/ручной; либо ввести enum, если планируется больше вариантов. Низкий приоритет. |
| #OQ2.8-17 | Код вне BRD (гайдбук сверх BRD) | Что нашли: гайдбук 2.8 вводит сущности, которых нет в требованиях BRD: «Максимальная длительность групп» (деф. 1 год), «Расчёт заказов в группах» (деф. не рассчитываются), блок «Параметры абонементов» с «Типом границы дат» (любые даты — деф. / значение дней / в пределах календарного месяца; доступны только при тарифе с процессинговыми группами). В BRD 2.8 этих настроек нет. | Бизнес (Герман) | Open | Гайдбук новее BRD (27.07) и расширяет состав настроек групп/абонементов. Подтвердить нечем со стороны BRD — не додумываю. Решение бизнеса: внести в требования 2.8 «максимальную длительность групп», «расчёт заказов в группах» и «параметры абонементов (тип границы дат)» по гайдбуку, либо отнести к разделу процессинга групп (3.3) со ссылкой. Затрагивает BR2.8-13. |
| #OQ2.8-18 | Код BR2.8-2, BR2.8-17 | Проблема (два программных дефекта состава): (1) адрес организации — нет поля «тип»: два фиксированных слота PhysicalAddress/LegalAddress, enum AddressType объявлен, но мёртв; (2) сотрудник добавляется только через НОВЫЙ аккаунт: при занятых email/телефоне бросается AlreadyExists, привязки существующего аккаунта нет. \ AddressType.cs:6-10; CreateEmployeeCommandHandler.cs:42-51,68 | Бизнес/Разработка | Open | По (2) гайдбук на стороне BRD дословно: «Сотрудник добавляется через новый или существующий аккаунт пользователя» → привязка существующего аккаунта обязательна, сейчас её нет. По (1) гайдбук состав адреса не детализирует. Рекомендация: реализовать путь привязки существующего аккаунта сотрудника (не бросать AlreadyExists); по «типу адреса» — либо задействовать AddressType, либо убрать «тип» из BR2.8-2, если двух слотов достаточно. |
| #OQ2.8-19 | Код BR2.8-10 | Проблема: в конструкторе ForfeitSettings — InFutureOrders = inFutureOrders; InFutureOrders = true;: первое присваивание мёртвое, поле принудительно всегда true; выключить сценарий «в составе будущих заказов» невозможно. \ ForfeitSettings.cs:51-52 | Разработка (Влад) | Open | Гайдбук подтверждает инвариант: «В составе будущих заказов — всегда доступно и включено по умолчанию». То есть true по умолчанию верно, но мёртвое двойное присваивание — всё равно дефект кода (сбивает с толку и игнорирует входной параметр). Рекомендация: убрать мёртвое первое присваивание; если «всегда включено» — это инвариант, оставить true осознанно и убрать входной параметр inFutureOrders. |
| #OQ2.8-20 | Код BR2.8-6 | Требование говорит (новое): параметр приёма онлайн-платежей связывается только с условием оплаты, прошедшим валидацию — по размеру предоплаты (0–100), разрешённым объектам оплаты, методам оплаты и источникам заказа. Пометка BRD: «Не реализовано, результат МУЛЬТИРАСЧЁТОВ» — то есть требование новое и появилось после прохода Влада, отдельной находки по нему нет. \ (не сверялось: требование добавлено после сверки v0.1) | Бизнес/Разработка | Open | Требование добавлено в обновлённой версии и Владом ещё не сверялось — статус честно «не сверялось». Гайдбук валидацию связи параметров онлайн-платежа с условием оплаты в явном составе не раскрывает (отсылает к условиям оплаты 2.4.2 и сценариям 5.1.2). Рекомендация: передать BR2.8-6 Владу на отдельную сверку с кодом (проверить, есть ли валидация связи PaymentSettings ↔ условие оплаты по 4 параметрам), затем актуализировать статус. До сверки не считать ни реализованным, ни нет. |
Подстраницы
Вопросы по сверке с кодом
BRD 2.8 v0.1 · booking-monorepo · commit 67a32a3/test/bypass-payment-gate · 2026-07-09 · якорь src/services/booking.partner-management (namespace PartnerZones.*) Сводка: вопросов 19 (бизнесовых 13 / программных 6) · подтверждено без вопросов 2 (BR2.8-1, BR2.8-9) · отрезано находок обратного прохода 6 Стек-примечание: сервис использует LinqToDB (не EF Core); схема/индексы создаются в DbInitializer.cs + атрибуты [Table]/[Column] на моделях; валидации — в конструкторах value object/агрегатов. Значения по умолчанию проверялись в CreatePartnerZoneCommandHandler.cs и конструкторах VO. Под особым вниманием: BR2.8-7 (сроки 4 ч/24 ч отсутствуют полностью), BR2.8-16 (2 из 6 полей), BR2.8-17 (передачи прав владельца нет во всём репо); дефолты BR2.8-9 (Immediate/Automatic/1) и BR2.8-11 (4/12/12/2) — проверены отдельно.
Бизнесовые
| № | Связано с | Что в BRD | Что в коде | Где в коде |
|---|---|---|---|---|
| Б1 | BR2.8-7 | Инструкция оплаты хранит срок подтверждения оплаты клиентом (деф. 4 ч) и срок подтверждения зачисления средств (деф. 24 ч) | Обоих полей нет вовсе: CreateOnInstruction принимает только name/description/instructionUrl/prepaymentPercent; в модели БД и командах полей сроков нет; дефолтов 4/24 в коде нет — нужно решение: хранить ли эти сроки на инструкции здесь или это зона ответственности сценариев оплаты (Back 5.1.2), и реализовать | PaymentSettingsAggregate.cs:221-254; CreatePaymentSettingCommand.cs:27-28; PaymentSettings.cs (колонок сроков нет) |
| Б2 | BR2.8-3 | Вариант почтовой рассылки: только адрес владельца (деф.) / только адрес зоны / адрес зоны и владельца | Такого режима-переключателя нет; в booking.notifications хранится плоский список email-контактов зоны (тип Email), без различения владелец/зона; дефолт «только владелец» на бэке не засевается — нужно решение: нужен ли трёхзначный режим рассылки или целевая модель — список контактов | PartnerZoneContacts.cs:20-24; ContactType.cs:3-8; CreateOrUpdatePartnerZoneSettingsCommandHandler.cs:33-47 |
| Б3 | BR2.8-8 | Срок автозавершения брони в часах с момента завершения заказа, деф. 48 ч | В настройках зоны такого срока нет: в OrderManagement есть только срок оплаты (минуты 0–60, часы 0–24, max 24 ч — 48 недостижимо); дефолт 48 не найден за обход partner-management; вероятно живёт в booking.orders (3.2, вне scope) — нужно подтверждение, где хранится настройка автозавершения | OrderPayManagementAggregate.cs:10-12,65-69; DbInitializer.cs:410-413 |
| Б4 | BR2.8-2 | Состав данных организации, в т.ч. учредители (номер, имя, фамилия, отчество, дата рождения, телефон) и договор (PDF-файл) | Реквизиты, адреса, ЭДО, банковские реквизиты — есть. Расхождения: «учредители» хранятся как ОДИН Founder (не список) — и в домене, и плоскими колонками БД; ссылки/файла договора юрлица в сущности организации нет (хранение файлов — 9.6.1, вне scope); сверх списка BRD хранится система налогообложения TaxationSystem — нужно решение: список ли учредителей, где ссылка на договор, узаконить ли TaxationSystem | Company.cs:25; PartnerZoneMapper.cs:197-198; CompanyDetails.cs:22-23 |
| Б5 | BR2.8-14 | Правила оказания услуг: текст в HTML ИЛИ PDF-файл; по умолчанию — стандартные сервисные правила в HTML | Хранится только HTML-текст (TextBookingRule.Text), PDF-формат не смоделирован (нет колонки file/format). «Стандартные правила по умолчанию» не зашиты — берутся из дефолта СФЕРЫ (сидит оператор) и копируются при создании БАЗЫ, не зоны — нужно решение: нужен ли PDF-вариант и что считать стандартным дефолтом зоны | TextBookingRuleAggregate.cs:15-16,52-62; TextBookingRule.cs:11-12; CreateFromDefaultTextBookingRuleCommandHandler.cs:37,55 |
| Б6 | BR2.8-15 | Списки: условия создания (деф. 1), условия оплаты (деф. 1), правила отмены (деф. набор глобальных по сферам), правила списания баллов (деф. баллы не принимаются) | Частично: правила отмены — весь набор дефолтов сферы копируется при создании базы (есть); условие оплаты — 1 дефолтная PaymentSettings «на месте» сидируется (есть). Не совпало: «условия создания» в коде — это BookingRuleSet (мин. часы/часы до брони), а FixedCondition — тарифный биллинг (без partner_zone_id); отдельного списка «правил списания баллов» нет (только числовые MaxLoyaltyPoints у базы/комнаты), дефолт «баллы не принимаются» не задаётся — нужно решение: подтвердить маппинг «условий» и модель баллов | CancelRuleAggregate.cs:216-234; CreateFromDefaultCommandHandler.cs:42-73; BookingRuleSetAggregate.cs:44-58; FixedConditionAggregate.cs:13-19; BaseAggregate.cs:37-39 |
| Б7 | BR2.8-16 | Параметры активации/продления: флаг автопродления, срок перехода к оплате, срок погашения (деф. 7 дн), сумма обязательная для погашения, сумма заказов без комиссии, сумма комиссии без начисления | Есть 2 из 6: PaymentTimeoutInHours (срок перехода) и PaymentDuePeriodInDays (деф. 7). Нет: флага автопродления и трёх «сумм»; подсистемы продления/активации в сервисе нет (грепы autoRenew/mandatory/freeCommission пусты). BRD сам ссылается на 2.8.1 — нужно подтверждение, что эти поля и процесс живут там | CommissionSettings.cs:13,18,20; (autoRenew/mandatory/freeCommission не найдено за обход partner-management) |
| Б8 | BR2.8-17 | Владелец может передать права другому аккаунту, если тот — сотрудник текущей зоны | Механизма передачи прав владельца нет во всём репозитории (грепы TransferOwnership/ChangeOwner/MakeOwner/ReassignOwner/NewOwnerId пусты); OwnerId задаётся только при создании зоны и далее не меняется — нужно решение: реализовать передачу прав владельца | PartnerZoneAggregate.cs:173; (смены владельца не найдено за обход src/**) |
| Б9 | BR2.8-17 | По умолчанию один сотрудник — владелец; владелец обладает всеми правами активного тарифа | Список сотрудников по ролям транслируется (authentication). Но «владелец = все права тарифа» отдельно не обеспечивается: авто-доступ ко всему только у роли Admin, владелец — лишь отображаемая метка «Владелец»; явного сотрудника-владельца по умолчанию нет (владелец выражен через OwnerId) — нужно подтверждение целевой модели прав владельца (пересекается с 1.2.1/1.4.1) | IsAuthorizedQuery.cs:118-128; AccountReadOnlyRepository.cs:122,129 |
| Б10 | BR2.8-10 | Доступные сценарии оплаты сборов (множественный выбор): в составе будущих заказов (деф. всегда), в приложении, по параметрам онлайн-платежа отменённого заказа, по отдельным реквизитам, по инструкции | Множественного выбора нет: в ForfeitSettings только InFutureOrders (bool) и PaymentSettingsId; остальные сценарии не смоделированы; в коде висит //Todo: добавить сценарии оплаты сборов(множественный выбор) — нужно решение: целевой набор сценариев оплаты сборов | PartnerZoneAggregate.cs:32; ForfeitSettings.cs:33-35 |
| Б11 | BR2.8-12 | Сценарии оплаты заказов по подтверждённым заявкам: на месте (деф.), в приложении (при наличии параметров), по инструкции (при наличии инструкции) | Сценарии существуют как общие PaymentSettings зоны (enum OnSite/OnlineInterface/ByInstruction), но НЕ привязаны к заявкам; «на месте» по умолчанию сидируется; условная доступность («в приложении/по инструкции») не проверяется — пустые значения допускаются — нужно решение: должны ли это быть отдельные настройки заявок | PaymentScenarioType.cs:3-8; RequestSettings.cs:14-29; CreatePaymentSettingCommandHandler.cs:70-86 |
| Б12 | BR2.8-13 | Группы заказов хранят настройки автопролонгации и сценарии оплаты абонементов | В PositionGroup нет ни автопролонгации, ни сценариев оплаты абонементов (только type/info/архив/сферы); «абонемент» реализован как ProcessingGroup в booking.orders (вне scope) — нужно подтверждение, где хранятся эти настройки как настройки зоны | PositionGroupAggregate.cs:20-26; PositionGroups.cs:10-37 |
| Б13 | BR2.8-4 | Доп. каналы (боты, SMS, мессенджеры) — реализация после релиза | В booking.notifications каналы SMS и Telegram-бот для зон уже присутствуют и подключены к отправке (сверх «после релиза»); канала «мессенджеры» (кроме Telegram) нет — нужно решение: обновить статус BR2.8-4, т.к. частично уже реализовано | SmsChannel.cs; TemplateChannelSender.cs:192,292; ProcessMessagesJob.cs:109,124-126 |
Рекомендация / варианты решения
- Сроки подтверждения по инструкции (Б1). Вариант А (реком.): добавить на инструкцию оплаты поля «срок подтверждения оплаты» (деф. 4 ч) и «срок подтверждения зачисления» (деф. 24 ч), как требует BR2.8-7. Вариант Б: если эти сроки — зона ответственности сценариев оплаты (Back 5.1.2), зафиксировать и перенести требование туда. Решение продуктовое: где источник истины для сроков.
- Режим почтовой рассылки (Б2). Вариант А: реализовать трёхзначный режим (владелец/зона/зона+владелец) с дефолтом «только владелец» на партнёрской зоне. Вариант Б (реком., если текущая модель целевая): зафиксировать в BRD, что рассылка задаётся списком email-контактов зоны (booking.notifications), и описать, откуда берётся дефолтный владелец.
- Срок автозавершения брони 48 ч (Б3). Подтвердить принадлежность настройки: если это настройка зоны — реализовать в partner-management (сейчас нет); если срок живёт в booking.orders (3.2) — уточнить в BR2.8-8 ссылку на источник.
- Состав данных организации (Б4). Вариант А: привести к BRD — сделать учредителей списком, добавить ссылку/файл договора (хранение — 9.6.1), узаконить или убрать
TaxationSystem. Вариант Б: привести BRD к коду — один учредитель + налоговая система в составе. Продукту решить целевой состав данных. - Формат и дефолт правил услуг (Б5). Вариант А: добавить PDF-вариант правил и зашитый «стандартный» дефолт зоны. Вариант Б (реком.): оставить HTML-текст + дефолт сферы, PDF/файлы отнести к 9.6.1, уточнить формулировку BR2.8-14.
- Списки условий и баллы (Б6). Вариант А: согласовать терминологию — что соответствует «условиям создания/оплаты» (BookingRuleSet + PaymentSettings), и завести список «правил списания баллов» с дефолтом «не принимаются». Вариант Б: обновить BR2.8-15 под фактическую модель. Пересекается с 2.4.1/2.4.2/2.7.3.
- Активация/продление доступа (Б7). Подтвердить, что 4 недостающих поля и процесс продления живут в Back 2.8.1/другом сервисе; если это настройки зоны — реализовать здесь. До этого решения BR2.8-16 закрыть нельзя.
- Передача и права владельца (Б8, Б9). Вариант А (реком.): реализовать команду передачи прав владельца сотруднику зоны (BR2.8-17 прямо требует) и определить, как владелец получает «все права тарифа» (сейчас — только Admin-bypass). Вариант Б: если модель ролей/прав целиком в 1.2.1/1.4.1 — вынести туда и уточнить BR2.8-17.
- Сценарии сборов и оплаты по заявкам (Б10, Б11). Определить целевые наборы: для сборов — множественный выбор (сейчас только «в составе будущих заказов»); для заявок — привязку сценариев к заказам по заявкам и правила условной доступности. В коде есть Todo — нужна продуктовая спецификация.
- Группы заказов / абонементы (Б12). Подтвердить, где живут автопролонгация и сценарии оплаты абонементов (сейчас — ProcessingGroup в booking.orders, не в настройках зоны); если это настройки зоны — реализовать, иначе уточнить BR2.8-13.
- Каналы уведомлений (Б13). Обновить BR2.8-4: SMS и Telegram-бот для зон уже частично реализованы, отметка «после релиза» устарела; зафиксировать фактический статус и оставшийся объём (прочие мессенджеры).
Программные
| № | Связано с | Что в BRD | Что в коде | Где в коде |
|---|---|---|---|---|
| П1 | BR2.8-11 | Сроки автоотклонения заявок (деф. день 4 ч, ночь 12 ч, в работе 12 ч) и число продлений (деф. 2) | Все 4 поля есть (RequestSettings), но хранятся ПО СФЕРАМ (SphereRequestSettings), не как единый параметр зоны. Класс Options.RequestSettings с ТОЧНЫМИ дефолтами BRD (4/12/12/2) внедрён в обработчик создания, но нигде не читается — фактические значения копируются из настроек каждой сферы; зонный дефолт 4/12/12/2 не применяется | RequestSettings.cs (Options):11-14; CreatePartnerZoneCommandHandler.cs:26,45,66-72 |
| П2 | BR2.8-5 | Параметры онлайн-платежа хранят «дату последней операции по параметрам» и расчётный счёт | Два дефекта пути редактирования: (1) доменный Update() не обновляет AuditableInfo/UpdatedAt — «дата последней операции» не двигается при обычном редактировании (меняется лишь в Archive/Restore); (2) if (Account != null) Account = account; — проверяется текущее свойство, а не параметр, из-за чего расчётный счёт обновляется некорректно | PaymentSettingsAggregate.cs:107-140,133-134 |
| П3 | BR2.8-5 | Параметры онлайн-платежа хранят провайдера онлайн-оплат и сценарий возврата (авто/ручной) | Отдельного поля «провайдер» нет — провайдер выводится из канала оплаты PayChannelId (каналы/провайдеры детально в 5.1/5.5, вне scope), вероятно by design; «сценарий возврата» — это bool AutoRefund, а не enum авто/ручной — уточнить, достаточно ли bool | PaymentSettingsAggregate.cs:32,41; CreatePaymentSettingCommandHandler.cs:44-49 |
| П4 | BR2.8-17 | Сотрудник добавляется через новый ИЛИ существующий аккаунт | Реализован только путь НОВОГО аккаунта: при занятых email/телефоне бросается AlreadyExists, аккаунт всегда создаётся заново (Account.Create); привязки существующего аккаунта нет — расхождение с «новый или существующий» | CreateEmployeeCommandHandler.cs:42-51,68 |
| П5 | BR2.8-2 | Адрес организации хранит «тип» (наряду с индексом, страной, городом, улицей) | Отдельного поля «тип адреса» нет: адреса реализованы двумя фиксированными слотами PhysicalAddress/LegalAddress; enum AddressType {Physical, Legal} объявлен, но нигде не используется (мёртвый) — уточнить, достаточно ли двух слотов | AddressType.cs:6-10; CompanyAddress.cs:10-13; PartnerZoneAggregate.cs:122-123 |
| П6 | BR2.8-10 | Режим «в составе будущих заказов» — по умолчанию всегда | В конструкторе ForfeitSettings: InFutureOrders = inFutureOrders; InFutureOrders = true; — первое присваивание мёртвое, поле принудительно всегда true; выключить сценарий «в составе будущих заказов» невозможно — проверить, осознанный ли это инвариант или баг | ForfeitSettings.cs:51-52 |
Рекомендация / варианты решения
- Мёртвый конфиг дефолтов заявок (П1). Вариант А (реком.): применять
Options.RequestSettings(4/12/12/2) как зонный дефолт при создании настроек заявок, если он целевой; либо явно удалить неиспользуемый Options, если источник истины — настройки сферы. Сейчас точные дефолты BRD присутствуют, но не задействованы — легко ошибочно принять за «реализовано». - Дефекты редактирования онлайн-платежа (П2). Вариант А (реком.): в
Update()обновлятьAuditableInfo.UpdatedAt(иначе «дата последней операции» неверна) и исправитьif (Account != null)→ проверку параметраaccount. Оба — программные баги, продуктового решения не требуют. - Провайдер и сценарий возврата (П3). Уточнить контракт: провайдер выводится из канала (5.x, вероятно by design) — зафиксировать; при необходимости различать возврат тоньше bool — ввести enum. Низкий приоритет.
- Привязка существующего аккаунта сотрудника (П4). Вариант А (реком.): добавить путь привязки существующего аккаунта как сотрудника (BR2.8-17 «новый или существующий»), не бросать AlreadyExists. Направление задаёт продуктовое решение по модели сотрудника, реализация — программная.
- Тип адреса (П5). Если достаточно двух слотов (физический/юридический) — убрать неиспользуемый enum
AddressTypeи снять «тип» из состава BR2.8-2; если типов адреса может быть больше — вынести тип в поле. - Принудительный InFutureOrders=true (П6). Убрать мёртвое первое присваивание и определить, инвариант ли это (всегда true) или настраиваемый флаг; влияет на трактовку BR2.8-10.