Направление работ: Back Код раздела: 2.8.1 Объекты и предложения > Настройки партнерской зоны > Продление доступа Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 23.06.26
1. Назначение
Раздел описывает процесс активации и продления доступа партнерской зоны к функциональности платформы.
Система определяет доступные для партнерской зоны тарифы, фиксирует оплату доступа и комиссии и применяет результат к доступу партнера.
Тарифы, расчеты, платежная инфраструктура и интерфейсные сценарии раскрываются в соседних разделах.
2. Ключевые понятия
Продление доступа — процесс, в рамках которого партнер оплачивает доступ и комиссию, чтобы сохранить функциональность партнерской зоны.
Активация доступа — первичная оплата доступного партнерского тарифа для партнерской зоны.
Тариф доступа — тариф, который определяет доступные возможности партнерской зоны.
Сумма по тарифу — значение из настроек активного тарифа, которое может изменяться в зависимости от предложений в партнерской зоне и количества оплачиваемых периодов.
Сумма комиссии — динамическая часть стоимости, которая рассчитывается по заказам партнерской зоны.
Дата продления — дата окончания действия активного тарифа.
Дата окончания периода — дата окончания одного из оплаченных периодов; если оплачен один период, совпадает с датой продления.
Статус продления — состояние партнерской зоны в процессе активации и продления доступа.
3. Scope
Входит
S1 Активация доступа: выбор доступного тарифа для партнерской зоны и проверка условий его активации.
S2 Продление доступа: расчет продления, даты и этапы продления доступа партнерской зоны.
S3 Статус продления: автоматическое определение состояния партнерской зоны по этапу продления доступа.
Не входит
- Back: 1.4.1 Партнерская зона доступа — состав возможностей по активному тарифу
- Back: 1.4.2 Расширение партнерских прав доступа через тарифы
- Back: 2.8 Настройки партнерской зоны
- Back: 4.3 Стоимость доступа к платформе и Back: 4.4 Расчет комиссии за заказы
- Back: 5.1 Каналы оплаты, Back: 5.1.1 Объекты оплаты, Back: 5.1.2 Сценарии и методы оплаты, Back: 5.4 Платежные документы и Back: 5.5 Провайдеры онлайн-оплат
- Back: 8.3.1 Доступ и комиссия и Back: 8.3.2 Публикация объектов и площадок
- WebLk: 3.2 Продление доступа, WebLk: 3.2.1 О тарифе, WebLk: 3.2.2 Оплата доступа и комиссии, WebLk: 3.2.3 Отчет по комиссии и платежам и WebLk: 3.2.4 Смена тарифа и расширение доступа
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе.
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR2.8.1-1 | Активация доступа партнерской зоны должна выполняться через оплату доступного партнерского тарифа. | Подробнее тарифы доступа описаны в Back: 8.3.1 Доступ и комиссия. | Бизнес | 1 | Не реализовано OQ2.8.1-2, OQ2.8.1-4 |
| S1: BR2.8.1-2 | Система должна определять доступные для активации тарифы по условиям тарифа и партнерской зоны. | Условия проверки: - период доступности тарифа - разрешенные партнерские зоны - лимит количества активаций - флаг одноразового использования | Системное | 1 | Не реализовано OQ2.8.1-5, OQ2.8.1-6, OQ2.8.1-15 |
| S1: BR2.8.1-3 | После активации тарифа партнерская зона должна получать доступ к функциональности, соответствующей активированному тарифу. | Доступ к публикации объектов и площадок выдается при оплаченных квотах размещения. Функциональные возможности партнерской зоны описаны в Back: 1.4.1 Партнерская зона доступа, публикация предложений — в Back: 8.3.2 Публикация объектов и площадок. | Бизнес | 1 | Частично OQ2.8.1-3, OQ2.8.1-7 |
| S2: BR2.8.1-4 | Стоимость продления доступа должна рассчитываться из суммы по тарифу и суммы комиссии. | Сумма по тарифу выводится из настроек активного тарифа и может изменяться в зависимости от предложений в партнерской зоне и количества оплачиваемых периодов. Сумма комиссии рассчитывается по заказам партнерской зоны. Подробная логика расчетов описана в Back: 4.3 Стоимость доступа к платформе и Back: 4.4 Расчет комиссии за заказы. | Системное | 1 | Не реализовано OQ2.8.1-8 |
| S2: BR2.8.1-5 | Для продления доступа должны использоваться дата продления, которая может различаться у сущностей, и дата окончания оплаченного периода. | Дата продления определяется сроком окончания действия активного тарифа. Дата окончания периода определяется сроком окончания одного из оплаченных периодов; если оплачен один период, дата окончания периода совпадает с датой продления. | Системное | 1 | Не реализовано OQ2.8.1-3, OQ2.8.1-9 |
| S2: BR2.8.1-6 | Если тариф включает комиссию, комиссия должна быть погашена не позднее границы для оплаты комиссии. | Оплата комиссии возможна каждый день, но является обязательной не позднее установленного в партнерской зоне срока до даты окончания периода. | Бизнес | 1 | Частично OQ2.8.1-10, OQ2.8.1-11 |
| S2: BR2.8.1-7 | При продлении доступа система должна сначала погашать начисленную комиссию, затем оплачивать доступ. | Если комиссия отсутствует, этап погашения комиссии пропускается. Комиссия, начисленная в период после границы оплаты комиссии за прошлый период и до даты окончания прошлого периода, начисляется в следующий период. Если сумма по тарифу отсутствует либо есть оплаченные периоды, этап оплаты доступа пропускается. | Системное | 2 | Не реализовано OQ2.8.1-11, OQ2.8.1-12 |
| S3: BR2.8.1-8 | Статус продления партнерской зоны должен автоматически определяться по этапу продления доступа. | Допустимые значения: - активен — от даты активации или продления до наступления срока погашения комиссии - пролонгация — в пределах срока погашения комиссии - не продлен — после даты продления и до наступления трех месяцев с момента ее истечения - архивирован — после трех месяцев с момента наступления даты продления | Системное | 1 | Не реализовано OQ2.8.1-13 |
5. Открытые вопросы
Сверка с кодом: BRD 2.8.1 v0.1 · репозиторий
booking-monorepo· commit9d5f0af9/main· 29.07.26 · якорьsrc/services/booking.partner-managementСводка: 15 вопросов (Open 14 · Подтверждено 1) Внимание: из трёх задач раздела — активация доступа, продление доступа и статус продления — в коде не работает ни одна. Реализован только справочник тарифов и условий к ним, а тариф партнёрской зоне не назначается никогда: при создании зоны в поле тарифа подставляется пустое значение. Маршрутизация без сверки с гайдбуком (гайдбук не передавался).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ2.8.1-1 | Исходный материал | Текст вопроса не указан в исходном материале. | Open | |||
| OQ2.8.1-2 | Код вне BRD | Что нашли: в репозитории сервиса лежит собственный дизайн-документ на 1052 строки, который описывает продление доступа и комиссию иначе, чем BRD. По нему доступ покупается по объектам, а не на партнёрскую зону целиком; активация тарифа — административная операция, прямо названная не связанной с оплатой; вместо статусов продления используется вычисляемая блокировка размещения. Там же появляются правила, которых в BRD нет вовсе: бесплатный промежуток до начала первого периода, автопродление, скидка за дополнительные периоды. Ни одна из двух моделей пока не реализована в коде, поэтому выбор ещё возможен без переделок. Нужно решить, какой документ считать источником истины, и привести второй в соответствие. \ docs/partner-access-and-commission-design.md (весь документ), :40 (активация не связана с оплатой), :367-369 (доступ покупается по объектам), :729 (лимиты тарифа в продлении не участвуют) | Бизнес | Open | (А) Провести совместную вычитку BRD и дизайн-документа и зафиксировать единую модель в BRD (рекоменд.), оставив дизайн-документ техническим приложением без собственных бизнес-правил. (Б) Признать источником истины дизайн-документ — тогда переписывать придётся не только BR2.8.1-1…-8, но и смежные разделы 4.3, 4.4 и WebLk 3.2, потому что все они написаны под доступ на уровне зоны. Решение стоит принять до старта разработки: сейчас не реализована ни одна из моделей, и цена выбора минимальна. Это ключевой вопрос раздела — остальные вопросы по BR2.8.1-1…-8 зависят от него. | |
| OQ2.8.1-3 | Код BR2.8.1-3 | Требование говорит: доступ активируется и продлевается для партнёрской зоны целиком, а даты продления и окончания периода относятся к зоне. В коде тариф действительно хранится на зоне, но дизайн-документ описывает другую модель: периоды покупаются отдельно по каждому объекту, у каждого объекта свой независимый отсчёт и своя дата оплаченного доступа. Там же есть правило старта периодов — они начинаются не с момента покупки, а с начала следующего полного расчётного периода, а время до этого партнёр пользуется бесплатно. В BRD нет ни объектного уровня, ни бесплатного промежутка. От этого выбора зависят и расчёт стоимости, и даты продления, и статусы, поэтому его нельзя откладывать. \ PartnerZoneAggregate.cs:54 (тариф хранится на зоне), docs/partner-access-and-commission-design.md:367-369 (покупка по объектам), :371-374 (старт периодов и бесплатный промежуток), :31-32 (оплаченный доступ на паре зона-объект) | Бизнес | Open | (А) Оставить доступ на уровне партнёрской зоны (рекоменд.), как в BRD: модель проще, и соседние разделы уже написаны под неё. (Б) Перейти на объектный уровень — тогда в BRD нужно добавить понятие объекта доступа, правило старта периодов и бесплатного промежутка, а разделы 4.3 и WebLk 3.2 переписать. Решение принимать вместе с OQ2.8.1-2. | |
| OQ2.8.1-4 | Код BR2.8.1-1 | Требование говорит: доступ партнёрской зоны активируется оплатой доступного партнёрского тарифа. В коде активации нет ни в каком виде. Поле тарифа у партнёрской зоны есть, но при создании зоны в него всегда подставляется пустое значение, а сам метод создания тариф на вход даже не принимает. Ни одной операции, которая меняла бы тариф зоны, в сервисе нет — доступны только создание и редактирование зоны, и тариф в них не участвует. Оплаты доступа тоже нет: в сервисе не заведено ни покупок, ни связи с платёжными документами. \ PartnerZoneAggregate.cs:174 (подстановка пустого тарифа при создании), :110-134 (метод создания без параметра тарифа), Commands/PartnerZone/ (только Create и Update, тариф не меняется) | Разработка | Open | Завести тикет в Bitrix: реализовать назначение тарифа партнёрской зоне и оплату доступа. Продуктового выбора здесь нет, но ставить задачу имеет смысл после решения по OQ2.8.1-2 и OQ2.8.1-3 — от них зависит, что именно оплачивается. Отдельным пунктом стоит убрать подстановку пустого тарифа: сейчас каждая новая зона создаётся со ссылкой на несуществующий тариф, и это молча ломает все проверки прав по тарифу. | |
| OQ2.8.1-5 | Код BR2.8.1-2 | Требование говорит: система определяет, какие тарифы доступны партнёрской зоне, проверяя четыре условия — период доступности тарифа, разрешённые зоны, лимит количества активаций и флаг одноразового использования. В коде такого подбора нет. Единственный запрос списка тарифов помечен разработчиком как неиспользуемый и фильтрует совсем по другому — по городам, сферам и признаку архивности. Ни одно из четырёх условий нигде не проверяется: соответствующие поля тарифа только сохраняются и читаются, но в решениях не участвуют. \ GetPartnerTariffsByFilterQuery.cs:8 (пометка «не используется»), PartnerTariffReadRepository.cs:26-40 (фильтр по городам, сферам и архивности), PartnerTariffSetAggregate.cs:17-31 (поля условий есть, проверок нет) | Разработка | Open | Завести тикет в Bitrix: реализовать подбор доступных тарифов с проверкой всех четырёх условий и заменить им неиспользуемый запрос. Перед постановкой нужен ответ на OQ2.8.1-6 — дизайн-документ прямо отменяет два условия из четырёх. Заодно решить судьбу помеченного запроса: либо он становится основой подбора, либо его надо удалить, чтобы не путал следующего разработчика. | |
| OQ2.8.1-6 | Код BR2.8.1-2 | Требование говорит: лимит количества активаций и флаг одноразового использования ограничивают активацию тарифа. В коде оба поля существуют и настраиваются администратором, но дизайн-документ прямо пишет, что в продлении доступа они не участвуют и ограничением служит только лимит оплаты вперёд. При этом в разделе терминов того же документа оба поля названы ограничением на количество продлений, а не активаций — то есть их смысл описан двояко даже внутри одного документа. Нужно однозначно определить, что они ограничивают: число активаций тарифа зоной, число продлений или ничего. \ PartnerTariffSetAggregate.cs:19-20 (флаг одноразового использования и лимит активаций), docs/partner-access-and-commission-design.md:729 (в продлении не участвуют), :42 (названы лимитом по продлениям) | Бизнес | Open | (А) Подтвердить формулировку BRD (рекоменд.): оба поля ограничивают количество активаций тарифа партнёрской зоной, и подбор доступных тарифов обязан их проверять. (Б) Признать их лимитом продлений, как в дизайн-документе, — тогда BR2.8.1-2 надо переписать, убрав их из условий подбора. Худший исход — оставить как есть: поля продолжат настраиваться в админке и ни на что не влиять. | |
| OQ2.8.1-7 | Код BR2.8.1-3 | Проблема: механизм выдачи прав по тарифу построен, но тариф аккаунту никогда не проставляется. В сервисе аутентификации есть связка «право — тариф» и отбор прав по списку тарифов, то есть выдать расширенные возможности по активированному тарифу технически можно. Однако при регистрации в поле тарифа аккаунта записывается пустое значение, а рядом стоит пометка разработчика убрать заглушку. В результате отбор прав по тарифу всегда возвращает пустой список, и требование не заработает, даже если тариф зоне назначить. \ RegistrationMobileEndCommandHandler.cs:122-131 (заглушка с пустым тарифом и пометка TODO), AllowPermissionToPartnerTariff.cs (связка права и тарифа), PermissionsRepository.cs:51-55 (отбор прав по тарифам) | Разработка | Open | Завести тикет в Bitrix: проставлять аккаунту тариф партнёрской зоны и убрать заглушку из регистрации. Продуктового выбора нет. При постановке учесть, что тариф сейчас хранится в двух местах — на аккаунте в сервисе аутентификации и на партнёрской зоне; нужно определить ведущее, иначе значения разъедутся. | |
| OQ2.8.1-8 | Код BR2.8.1-4 | Требование говорит: стоимость продления складывается из суммы по тарифу и суммы комиссии. В коде расчёта нет ни для одной из двух частей: в сервисе не заведено ни покупок доступа, ни начислений комиссии, ни платёжной части. Дизайн-документ описывает формулу, которой в BRD нет: скидка тарифа применяется как процент за каждый дополнительный период сверх первого и считается отдельно по каждому объекту, а не на общую сумму покупки. Поле скидки у тарифа существует и настраивается, но нигде не используется, поэтому администратор заполняет его вслепую. \ PartnerTariffSetAggregate.cs:21 (поле скидки), docs/partner-access-and-commission-design.md:537-556 (формула суммы со скидкой за дополнительные периоды) | Бизнес | Open | (А) Подтвердить правило скидки из дизайн-документа (рекоменд.) и описать его в разделе 4.3 либо в комментарии к BR2.8.1-4 — иначе поле остаётся настройкой без смысла. (Б) Задать другое правило применения скидки, например на общую сумму покупки. В обоих случаях после решения нужен тикет на реализацию расчёта — сейчас его нет вообще. | |
| OQ2.8.1-9 | Код BR2.8.1-5 | Требование говорит: для продления используются дата продления и дата окончания оплаченного периода. В коде ни той, ни другой даты нет: у партнёрской зоны не хранится ни срок действия тарифа, ни границы оплаченных периодов, и поиск по всему сервису не находит ни одного поля с таким смыслом. Без этих дат невозможны ни статусы продления, ни граница оплаты комиссии, ни напоминания партнёру — то есть половина раздела упирается именно в них. Это базовая часть модели, с которой стоит начинать разработку. \ PartnerZoneAggregate.cs:54 (из всего, что связано с тарифом, хранится только его идентификатор), Persistence/PartnerZone/Models/ (нет ни таблиц, ни полей с датами доступа) | Разработка | Open | Завести тикет в Bitrix: завести хранение даты продления и границ оплаченных периодов вместе с историей оплаченных периодов. Продуктового выбора нет, но уровень хранения — зона или объект — определяется решением по OQ2.8.1-3, поэтому тикет ставить после него, иначе структуру придётся переделывать. | |
| OQ2.8.1-10 | Код BR2.8.1-6 | Проблема: срок погашения комиссии настраивается на партнёрской зоне и сохраняется в базе, но лежит в колонке с чужим именем — settlement_period, то есть «расчётный период». И запись, и чтение работают со сроком погашения в днях, а не с длиной расчётного периода; значение по умолчанию — семь дней. Кроме записи в журнал изменений это значение нигде не используется: граница оплаты комиссии по нему не считается. Имя колонки будет сбивать с толку любого, кто станет реализовывать требование, и рискует привести к неверному расчёту. \ CommissionSettings.cs:13-19 (настройка и значение по умолчанию), PartnerZoneMapper.cs:208-213 (запись срока погашения в колонку settlement_period), :120-123 (обратное чтение), TariffSettings.cs (описание колонки) | Разработка | Open | Завести тикет в Bitrix: переименовать колонку в соответствии со смыслом, например в payment_due_period_days. Продуктового выбора нет, миграция простая, но её лучше сделать до того, как на это поле начнут опираться расчёты. Реализация самой проверки границы оплаты — отдельная задача, зависящая от OQ2.8.1-11. | |
| OQ2.8.1-11 | Код BR2.8.1-6 | Что нашли: срок, связанный с оплатой комиссии, задаётся в двух разных местах и нигде не согласован. На партнёрской зоне это срок погашения комиссии в днях, а у тарифа есть отдельное поле «переход комиссии к оплате». Оба поля настраиваются, оба сохраняются, и ни одно не участвует в логике. Дизайн-документ знает только зонную настройку и строит от неё границу оплаты, поле тарифа он не упоминает вовсе. В BRD описан только один срок — установленный в партнёрской зоне. \ CommissionSettings.cs:15-18 (срок погашения на зоне), PartnerTariffSetAggregate.cs:22 (поле перехода комиссии к оплате на тарифе), docs/partner-access-and-commission-design.md:580 (граница считается от зонной настройки) | Бизнес | Open | (А) Оставить один источник — настройку партнёрской зоны (рекоменд.), как в BRD и в дизайн-документе, а поле тарифа убрать из админки и из модели. (Б) Если срок должен задаваться тарифом, а зона лишь уточняет его, это надо описать в BRD явно, вместе с правилом приоритета. Пока решения нет, реализовывать проверку границы преждевременно — можно закрепить неверный источник. | |
| OQ2.8.1-12 | Код BR2.8.1-7 | Требование говорит: при продлении система сначала погашает начисленную комиссию и только потом оплачивает доступ, а начисления, попавшие в промежуток между границей оплаты и концом прошлого периода, переносятся в следующий период. В коде нет ни начислений комиссии, ни покупок доступа, поэтому никакого порядка не существует. Дизайн-документ описывает две независимые операции — покупку доступа и оплату комиссии, — которые ничем друг с другом не связаны, а вместо обязательной последовательности использует блокировку размещения при непогашенном долге. Правило переноса начислений в следующий период в дизайн-документе тоже отсутствует. \ docs/partner-access-and-commission-design.md:402-406 (блокировка вместо последовательности), :569-583 (переходы статуса начисления и граница оплаты комиссии) | Бизнес | Open | (А) Подтвердить последовательность из BRD (рекоменд.): при продлении сначала комиссия, потом доступ — так партнёр не сможет продлить доступ с непогашенным долгом. (Б) Принять модель дизайн-документа с независимыми операциями и блокировкой — тогда BR2.8.1-7 надо переписать. В обоих вариантах правило переноса начислений нужно описать отдельно: сейчас его нет ни в коде, ни в дизайн-документе. | |
| OQ2.8.1-13 | Код BR2.8.1-8 | Требование говорит: партнёрская зона имеет статус продления с четырьмя значениями — активен, пролонгация, не продлен и архивирован. В коде такого статуса нет: ни поля, ни перечисления с этими значениями в сервисе не существует. Единственный близкий по смыслу статус живёт в сервисе аутентификации, относится к аккаунту, а не к зоне, и имеет другой набор значений — неактивен, активен, заблокирован, удалён. Дизайн-документ вместо статусов предлагает вычисляемый признак блокировки, который считается от границы оплаты комиссии и не различает «не продлен» и «архивирован». \ AccountStatus.cs (статус аккаунта, не зоны), docs/partner-access-and-commission-design.md:624 (формула признака блокировки) | Бизнес | Open | (А) Подтвердить четыре статуса продления из BRD (рекоменд.) — они нужны кабинету партнёра и разделу WebLk 3.2, где партнёру показывают состояние доступа. (Б) Ограничиться вычисляемым признаком блокировки — тогда надо описать, как кабинет покажет разницу между «не продлен» и «архивирован» и что происходит с зоной через три месяца после даты продления. После решения потребуется тикет на реализацию. | |
| OQ2.8.1-14 | Код вне BRD | Что нашли: у тарифа доступа есть настройки, которых в BRD нет. Лимит оплаты вперёд ограничивает, на сколько периодов партнёр может оплатить доступ за один раз, и в дизайн-документе именно он служит единственным ограничением продлений. Признак пробного тарифа тоже заведён и сохраняется, но нигде не описан и ни на что не влияет. Кроме того, дизайн-документ вводит автопродление, без которого при неподключённой онлайн-оплате запрещено размещение, и правило, что по заказам, оплаченным онлайн, комиссия не начисляется — обоих правил в BRD нет вовсе. \ PartnerTariffSetAggregate.cs:23-24 (лимит оплаты вперёд и признак пробного тарифа), PartnerTariffMapper.cs:34 (лимит хранится в колонке pay_period_quantity), docs/partner-access-and-commission-design.md:383 (размещение только при активном автопродлении), :410 (комиссия не начисляется по онлайн-оплаченным заказам) | Бизнес | Open | (А) Описать лимит оплаты вперёд в комментарии к BR2.8.1-4 или в разделе 4.3 (рекоменд.) — он напрямую влияет на сумму продления и уже настраивается в админке. По признаку пробного тарифа и автопродлению нужно отдельное решение: либо они входят в 2.8.1 и требуют собственных требований, либо их место в разделе 8.3.1. (Б) Если правило «по онлайн-оплаченным заказам комиссия не начисляется» верно, внести его в раздел 4.4 — оно меняет сумму комиссии и не может остаться только в дизайн-документе. | |
| OQ2.8.1-15 | Код BR2.8.1-2 | Что подтверждено: справочник тарифов доступа и условий к ним реализован полностью. У тарифа заведены период действия, признак выдачи по умолчанию, флаг одноразового использования, лимит активаций, скидка, длина периода, разрешённые партнёрские зоны и ссылки на условия, а также административные операции создания и изменения. Условия бывают двух видов: фиксированные — с ценой за период и привязкой к городам и сферам, и комиссионные — с ценами и процентами за бронирование, закрытое бронирование и заявку, признаком учёта позиций и привязкой к городам, сферам и источникам. Для условий обоих видов тоже есть операции создания и изменения. \ PartnerTariffSetAggregate.cs:16-34, Commands/PartnerTariff/Create/ и Update/, FixedConditionAggregate.cs:13-21, CommissionCondition.cs:7-21, Commands/FixedCondition/ и Commands/CommissionConditions/ | — | Подтверждено | Расхождения нет. Справочник — единственная реализованная часть раздела; всё, что его использует, ещё предстоит написать. | — |