Направление работ: Back
Код раздела: 8.3.5 Администрирование > Тарифы > Внутренние
Статус: Готов
Ответственный: Панкова Л.А.
Версия: 0.2
Обновлено: 17.09.26
1. Назначение
Внутренние тарифы (Сервисные услуги) предназначены для одноразовых покупок различных услуг сервиса Партнерами и Клиентами.
Параметры Внутреннего тарифа используются для расчета стоимости и оплаты сервисной услуги.
2. Ключевые понятия
Тариф — сущность, которая отвечает за процессы, связанные с реализацией услуг сервиса и возможностями системы для конкретного пользователя.
Внутренний тариф (Сервисная услуга) — Тариф для одноразовой покупки Партнером или Клиентом различных услуг сервиса, например консалтинговых услуг, стилизованных товаров, аналитических данных или заказных работ по реализации интеграций или кастомизации интерфейсов.
3. Scope
Входит
S1 Внутренний тариф: назначение, получатели, примеры Сервисных услуг и связанные процессы.
S2 Основные параметры: срок действия Тарифа, доступность Партнерам и Клиентам, ограничения активаций.
S3 Стоимость Сервисной услуги: фиксированная стоимость в рублях.
Не входит
- Back: 8.3 Тарифы
- Back: 1.4 Партнеры
- Back: 1.3 Клиенты
- Back: 8.1 Сервисная зона доступа
- Back: 4.6 Стоимость рекламы и сервисных услуг
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе.
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR8.3.5-1 | Внутренний тариф предназначен для одноразовых покупок различных услуг сервиса Партнерами и Клиентами | Получатели: Back: 1.4 Партнеры и Back: 1.3 Клиенты. Примеры Сервисных услуг: - консалтинговые услуги - стилизованные товары - аналитические данные - заказные работы по реализации интеграций или кастомизации интерфейсов | Бизнес | 1 | Частично OQ8.3.5-1, OQ8.3.5-2 |
| S1: BR8.3.5-2 | Параметры Внутреннего тарифа определяют расчет стоимости и оплату Сервисной услуги | Настройка Тарифа: выполняется сотрудниками платформы с соответствующим доступом в Back: 8.1 Сервисная зона доступа. Расчет стоимости: раскрывается в Back: 4.6 Стоимость рекламы и сервисных услуг | Бизнес | 1 | Частично OQ8.3.5-1, OQ8.3.5-2 |
| S2: BR8.3.5-3 | Внутренний тариф должен хранить основные параметры доступности | Состав данных: - Название Тарифа — краткое наименование - Описание Тарифа — подробное описание - Срок действия Тарифа — период доступности для использования: дата и время начала — дата и время окончания | Системное | 1 | Частично OQ8.3.5-1 |
| S2: BR8.3.5-4 | Внутренний тариф должен хранить признаки доступности для Партнеров и Клиентов (после релиза реализация) | Варианты доступности: - только Партнерам - только Клиентам - Партнерам и Клиентам | Системное | 3 | |
| S2: BR8.3.5-5 | Внутренний тариф должен ограничивать количество и повторность активаций | Количество активаций: задается целым числом и обозначает лимит на суммарное количество активаций Тарифа. В интерфейсах такой Тариф помечается как ограниченное предложение. Флаг одноразового использования: задает одноразовое предложение или триал-период. При установленном флаге Тариф можно активировать только один раз на Аккаунт | Системное | 1 | Частично OQ8.3.5-1, OQ8.3.5-2 |
| S3: BR8.3.5-6 | Внутренний тариф должен хранить стоимость Сервисной услуги в рублях | Системное | 1 | Частично OQ8.3.5-1 |
5. Открытые вопросы
Первая полная сверка (дейлики сентябрь 2026): BRD 8.3.5 v0.1 · репозиторий
booking-monorepo· commit82359296/main· 2026-09-08 · якорьsrc/services/booking.partner-management(PartnerZones.Domain/ServiceTariffAggregate). Гайдбук на вход не передавался — маршрутизация без сверки с гайдбуком. Сводка: 2 вопроса (Open 2 · оба — Разработке). Все 5 требований, проверенных при этой сверке, получили статус «Частично»: доменная модель Сервисного тарифа реализована и совпадает с ранее проверенными требованиями по составу полей, но упирается в те же две сквозные проблемы, что и раздел 8.3.2 — неиспользуемый CRUD (OQ8.3.5-1) и отсутствие модели покупки/активации Сервисного тарифа Партнёром или Клиентом (OQ8.3.5-2).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ8.3.5-1 | Код BR8.3.5-1, BR8.3.5-2, BR8.3.5-3, BR8.3.5-5, BR8.3.5-6 | Требование говорит: Внутренний тариф (Сервисная услуга) должен хранить название/описание/срок действия, ограничивать активации по количеству и одноразовости и хранить стоимость в рублях. В коде ServiceTariffAggregate хранит ровно этот набор полей (Info/DateRange/ActivationCount/OnlyOnce/Price) — полное соответствие BR8.3.5-3, -5, -6. Но команды создания/изменения Сервисного тарифа помечены в коде как неиспользуемые, и по автосгенерированному словарю API ни одно клиентское приложение их не вызывает — создать/изменить Внутренний тариф через существующие интерфейсы сейчас нельзя. \ ServiceTariffAggregate.cs:9-37; CreateServiceTariffCommand.cs:8 [Obsolete("unused")]; UpdateServiceTariffCommand.cs:9 [Obsolete("unused")]; Musbooking.ApiGateway/ApiDocs/api-dictionary.json:14462-14471 (CreateServiceTariffService, deprecated: true, obsoleteInCode: true), :17059-17068 (UpdateServiceTariffService), :16085-16095 (GetServiceTariffsService) | Разработка | Open | Подтвердить план подключения AdmLk/WebLk к CRUD Сервисных тарифов (та же работа Ксении, что и в 8.3.2). Модель ранее проверенных параметров готова, не хватает вызывающей стороны. | |
| OQ8.3.5-2 | Код BR8.3.5-1, BR8.3.5-2, BR8.3.5-5 | Требование говорит: Внутренний тариф предназначен для одноразовой покупки услуги Партнёром или Клиентом, а его параметры определяют расчёт стоимости и оплату, включая лимит и одноразовость активации на Аккаунт. В коде ServiceTariffAggregate и его CRUD-команды не различают, кто покупатель — Партнёр или Клиент (нет поля-получателя), и в анкере не найдено ни одной модели «покупки»/«оплаты»/«активации» Сервисного тарифа (аналог ClientTariffPurchaseAggregate из раздела 8.3.4, который в booking.partner-management и в связанных с ним потоках booking.clients для Сервисных тарифов отсутствует). Соответственно лимит активаций и одноразовость (BR8.3.5-5) хранятся как числа, но ничем не проверяются, а связь с оплатой (BR8.3.5-2) не подтверждается кодом в этом анкере — расчёт стоимости явно вынесен в 4.6 («Не входит»), но и сам факт оплаты/покупки нигде не зафиксирован. \ ServiceTariffAggregate.cs:9-37 (нет поля типа получателя); поиск ServiceTariffPurchase/ServiceTariffActivation по booking.partner-management и booking.clients — совпадений нет | Разработка | Open | Уточнить у разработки, где (в каком сервисе) должна жить операция покупки Сервисного тарифа Партнёром/Клиентом и проверка лимита/одноразовости — либо такой код действительно ещё не написан ни в одном сервисе, и тогда BR8.3.5-1/-2/-5 по факту не достигают описанного бизнес-эффекта независимо от готовности CRUD (OQ8.3.5-1). |