Направление работ: WebLk Код раздела: 3.2.3 Раздел: Профиль партнёра > Продление доступа > Отчет по комиссии и платежам Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 03.08.26
1. Назначение
Данный раздел обеспечивает партнеру интерфейс для просмотра отчета по комиссии и платежам в рамках текущей партнерской зоны.
Партнер находится в разделе «Продление доступа» и просматривает предварительно начисленную комиссию, комиссию к оплате и сведения о выполненных оплатах.
Интерфейс позволяет просматривать сводные показатели и состав записей, настраивать отображение колонок и, где это предусмотрено макетом, скачивать отчет.
Раздел зависит от Back: 2.8.1 Продление доступа. Правила расчета комиссии и формирования платежных данных требуют уточнения в связанных Back-разделах.
2. Ключевые понятия
Отчет по комиссии и платежам — интерфейсная область раздела «Продление доступа» с вкладками «Предварительная комиссия», «Комиссия к оплате» и «Оплаты».
Продление доступа — сценарий, в рамках которого партнер просматривает условия доступа, начисленную комиссию и сведения об оплатах текущей партнерской зоны.
Сумма комиссии — динамическая часть стоимости, которая рассчитывается по заказам партнерской зоны и отображается в отчете.
Предварительная комиссия — вкладка с заказами и суммой комиссии, начисленной за текущий период до переноса к оплате.
Комиссия к оплате — вкладка с заказами и суммой комиссии, перенесенной к оплате за указанный период.
Оплаченный период — оплаченный период доступа, сведения о котором отображаются в истории оплат.
3. Scope
Входит
S1: Просмотр раздела «Предварительная комиссия»
S2: Просмотр раздела «Комиссия к оплате»
S3: Просмотр раздела «Оплаты»
Не входит
- WebLk 3.2.1 О тарифе — подробная работа с описанием и составом тарифа
- WebLk 3.2.2 Оплата доступа и комиссии — выполнение оплаты доступа и комиссии
- WebLk 3.2.4 Смена тарифа и расширение доступа — смена тарифа и расширение доступа
4. BR
Указаны в пункте 4 раздела Back: 2.8.1 Продление доступа.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR3.2.3-1 | Партнер выбирает вкладку «Предварительная комиссия» | Интерфейс открывает вкладку «Предварительная комиссия» в разделе «Продление доступа» и показывает относящиеся к ней сводные показатели и таблицу заказов. | 1 | Частично \ #OQ3.2.3-1 | |
| S1: FR3.2.3-2 | Партнер просматривает сводные показатели предварительной комиссии | Интерфейс показывает показатели «Кол-во заказов», «Сумарно заказов на:», «Текущая комиссия» и «Перенос комиссии к оплате». | 1 | Частично \ #OQ3.2.3-1 | |
| S1: FR3.2.3-3 | Партнер просматривает заказы, по которым начислена предварительная комиссия | Интерфейс показывает таблицу с колонками «Клиент», «Дата», «Объект», «Площадка», «Часы», «Стоимость», «Комиссия» и «Статус». В колонке «Статус» интерфейс отображает цветовой индикатор статуса заказа в соответствии с установленной легендой: - «Зарезервировано»; - «Частично оплачено»; - «Оплачено»; - «Закрытый заказ». Статусы «Выбрано» и «Без статуса» в таблице не используются. | 1 | Частично \ #OQ3.2.3-3 | |
| S1: FR3.2.3-4 | Партнер настраивает отображение колонок предварительной комиссии | Интерфейс открывает «Настройки отображения». Варианты отображения: - «По умолчанию»; - «Открыто»; - «Скрыто». Действия с колонками: - изменить порядок; - скрыть или показать отдельную колонку; - применить действие «Скрыть все»; - применить действие «Показать все». Колонки: - основные: «Дата заказа», «Объект», «Площадка», «Часы», «Итоговая стоимость», «Комиссия», «Статус»; - дополнительные: «ID заказа», «Дата создания», «Источник», «Комментарий», «Вид работ», «Кол-во», «Позиции», «Скидка на позиции», «Скидка на время», «Сумма скидки», «Сбор», «Промокоды», «Сумма за часы». | 2 | Частично \ #OQ3.2.3-4 | |
| S1: FR3.2.3-5 | Партнер скачивает отчет по предварительной комиссии | Интерфейс открывает меню скачивания с действиями «Скачать в CSV» и «Скачать в XLS» и запускает выгрузку в выбранном формате. | 2 | Частично \ #OQ3.2.3-6 | |
| S1: FR3.2.3-6 | Партнер просматривает следующую часть списка предварительной комиссии | Интерфейс показывает постраничную навигацию и позволяет переходить между доступными страницами таблицы. | 2 | Частично \ #OQ3.2.3-7 | |
| S1: FR3.2.3-7 | В текущем периоде нет заказов с предварительной комиссией | Интерфейс показывает нулевые значения показателей «Кол-во заказов», «Сумарно заказов на:» и «Текущая комиссия», значение «Не определен» для показателя «Перенос комиссии к оплате», заголовки таблицы без записей и первую страницу постраничной навигации. | 1 | Не реализовано \ #OQ3.2.3-8 | |
| S2: FR3.2.3-8 | Партнер выбирает вкладку «Комиссия к оплате» | Интерфейс открывает вкладку «Комиссия к оплате» и показывает относящиеся к ней сводные показатели и таблицу заказов. | 1 | Частично \ #OQ3.2.3-1 | |
| S2: FR3.2.3-9 | Партнер просматривает сводные показатели комиссии к оплате | Интерфейс показывает показатели «Кол-во заказов», «Сумарно заказов на:», «Комиссия к оплате» и «Комиссия за период». | 1 | Не реализовано \ #OQ3.2.3-9 | |
| S2: FR3.2.3-10 | Партнер просматривает заказы, комиссия по которым перенесена к оплате | Интерфейс показывает таблицу с колонками «Клиент», «Дата», «Объект», «Площадка», «Часы», «Стоимость», «Комиссия» и «Статус». В колонке «Статус» интерфейс отображает цветовой индикатор статуса заказа в соответствии с установленной легендой: - «Зарезервировано»; - «Частично оплачено»; - «Оплачено»; - «Закрытый заказ». Статусы «Выбрано» и «Без статуса» в таблице не используются. | 1 | Частично \ #OQ3.2.3-3 | |
| S2: FR3.2.3-11 | Партнер настраивает отображение колонок комиссии к оплате | Интерфейс открывает «Настройки отображения» с вариантом «По умолчанию», группами «Открыто» и «Скрыто» и позволяет изменять порядок колонок, скрывать или показывать отдельные колонки, а также применять действия «Скрыть все» и «Показать все». Состав доступных колонок соответствует настройкам таблицы «Предварительная комиссия». | 2 | Частично \ #OQ3.2.3-4 | |
| S2: FR3.2.3-12 | Партнер скачивает отчет по комиссии к оплате | Интерфейс открывает меню скачивания с действиями «Скачать в CSV» и «Скачать в XLS» и запускает выгрузку в выбранном формате. | 2 | Частично \ #OQ3.2.3-6 | |
| S2: FR3.2.3-13 | Партнер просматривает следующую часть списка комиссии к оплате | Интерфейс показывает постраничную навигацию и позволяет переходить между доступными страницами таблицы. | 2 | Частично \ #OQ3.2.3-7 | |
| S3: FR3.2.3-14 | Партнер выбирает вкладку «Оплаты» | Интерфейс открывает вкладку «Оплаты» и показывает таблицу выполненных оплат. | 1 | Частично \ #OQ3.2.3-1 | |
| S3: FR3.2.3-15 | Партнер просматривает выполненные оплаты | Интерфейс показывает таблицу с колонками «Оплаченный период», «Дата оплаты», «Объект оплаты», «Способ оплаты», «Описание», «Плательщик» и «Сумма». В зависимости от оплаты могут быть заполнены не все поля строки таблицы. | 1 | Частично \ #OQ3.2.3-2 | |
| S3: FR3.2.3-16 | Партнер настраивает отображение колонок оплат | Интерфейс открывает «Настройки отображения» с вариантом «По умолчанию», группами «Открыто» и «Скрыто» и позволяет изменять порядок колонок, скрывать или показывать отдельные колонки, а также применять действия «Скрыть все» и «Показать все». | 2 | Частично \ #OQ3.2.3-5 | |
| S3: FR3.2.3-17 | Партнер просматривает признак ручного проведения оплаты (на будущую реализацию) | Интерфейс позволяет показать в таблице «Оплаты» дополнительную колонку «Проведено вручную (да/нет)» через «Настройки отображения». | 3 | Не реализовано \ #OQ3.2.3-11 | |
| S3: FR3.2.3-18 | Партнер просматривает комментарий к оплате (на будущую реализацию) | Интерфейс позволяет показать в таблице «Оплаты» дополнительную колонку «Комментарий» через «Настройки отображения». | 3 | Не реализовано \ #OQ3.2.3-11 |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ3.2.3-1 | Код FR3.2.3-1, FR3.2.3-2, FR3.2.3-8, FR3.2.3-14, FR3.2.3-15 | Требование говорит: отчет показывает партнеру фактические сводные показатели, заказы с начисленной комиссией и историю выполненных оплат в рамках текущей партнерской зоны. В коде ни одна из трех вкладок не обращается к бэкенду: все цифры и все строки таблиц — литералы в pinia-сторе, у которого нет ни одного action, ни одного await и ни одного запроса. Сводка предварительной комиссии зашита как 12 заказов / 7 850 ₽ / 1 500 ₽ / «12 мая 2025»; таблица предварительной комиссии — 22 записи; вкладка «Комиссия к оплате» питается геттерами, которые даже не читают state, а возвращают литерал 8 / 5 200 ₽ / 950 ₽ / «28 ноября 2025» и 8 записей; «Оплаты» — 12 записей. Каталога shared.fsd/api/extending-access/ не существует, класса ExtendingAccessApi в коде нет — он описан только в плане миграции как намерение. Партнерская зона в отчете не используется нигде, поэтому смена зоны не меняет ни одной цифры. При этом бэкенд уже отдает комиссию по заказу: поле PartnerCommission объявлено в контракте заказа, но во всем репозитории эта строка встречается ровно один раз — в самом объявлении, ни один компонент ее не читает. Собственная документация модуля называет данные временными прямым текстом: «Mock data для тестирования UI без подключения к бэкенду» и TODO «Заменить моки на реальные queries». \ stores/extendingAccess.ts:33-514 (стор целиком, без actions и запросов), :35-40, :42-285, :287-408, :417-422, :423-513; shared.fsd/api-contracts/orders/orders.schema.ts:174; entities.fsd/extending-access/model/mock-data.ts:1-3; entities.fsd/extending-access/README.md:355-359; entities.fsd/extending-access/MIGRATION.md:219-226; не найдено за обход: запросов комиссии и оплат доступа в shared.fsd/api/**, classes/api/**, server/api/**, proto/** | Бизнес/Разработка | Open | Раздел собран как визуальный прототип, поэтому ни одно требование не получило статус «Реализовано» — это головной вопрос, от которого зависят OQ3.2.3-3, OQ3.2.3-7, OQ3.2.3-8, OQ3.2.3-9, OQ3.2.3-10. Продуктового выбора в части «моки или бэкенд» нет. Рекомендация: (1) разработке — завести shared.fsd/api/extending-access/ и Zod-схемы, как уже спроектировано в MIGRATION.md, и снять данные с реального источника, переиспользуя готовое поле PartnerCommission и существующий фильтр заказов; (2) бизнесу — зафиксировать в Back 2.8.1 правила, которые фронту неоткуда взять: что попадает в «предварительную» и что в «к оплате», в какой момент происходит перенос и как считается «Перенос комиссии к оплате». Пункт 1 Назначения этого BRD уже помечает эти правила как требующие уточнения. | |
| OQ3.2.3-2 | Код FR3.2.3-3, FR3.2.3-10, FR3.2.3-15 | Требование говорит: интерфейс показывает таблицу с записями. В коде компонент таблицы, на котором построены все три вкладки, статически сломан: его шаблон шесть раз вызывает функции resolveCell и resolveTooltip при отрисовке каждой ячейки, но ни одна из них не определена ни в <script setup> этого файла, ни где-либо еще в репозитории. Единственное определение resolveCell живет локально внутри другого компонента (shared.fsd/ui/tables/DataTable.vue:113), не экспортируется и под авто-импорт Nuxt не попадает — в каталогах авто-импорта (composables/, utils/) такой функции нет. Формально это означает TypeError при отрисовке любой непустой строки любой из трех таблиц отчета. Проверка сделана статически, прогоном приложения не подтверждалась. \ components/UI/table/DataTable.vue:71,72,75,79,80,83 (вызовы), :123-307 (script setup без определений); shared.fsd/ui/tables/DataTable.vue:113 (единственное определение, чужое и не экспортируемое); components/partner-profile/commission/PreliminaryCommission.vue:82-90, CommissionToPay.vue:82-90, Payments.vue:58-66 (использование сломанного компонента) | Разработка (Влад) | Open | Продуктового выбора нет. Рекомендация: подтвердить дефект прогоном страницы /partner-profile/extending-access и вернуть resolveCell / resolveTooltip в components/UI/table/DataTable.vue с прежней семантикой (format(item), иначе String(item[col.key]), иначе «—») — она сохранилась в живом аналоге shared.fsd/ui/tables/DataTable.vue:113-123. Дефект затрагивает не только этот раздел, а всех потребителей components/UI/table/DataTable.vue, поэтому его стоит вынести из скоупа 3.2.3 в отдельную задачу и проверить остальные экраны. | |
| OQ3.2.3-3 | Код FR3.2.3-3, FR3.2.3-10 | Требование говорит: в колонке «Статус» показывается цветовой индикатор статуса заказа по легенде из четырех значений — «Зарезервировано», «Частично оплачено», «Оплачено», «Закрытый заказ», а «Выбрано» и «Без статуса» не используются. В коде цветового индикатора нет: колонка «Статус» объявлена без format и без слота, то есть выводится как обычный текст. Набор значений тоже другой и приходит из мока свободными строками — «Оплачен», «Забронирован» и «К оплате»; тип поля объявлен как обычный status: string, без перечисления. Ни одна из этих строк не совпадает с ключами общесистемной палитры статусов, поэтому даже при подключении цвета потребуется отдельный словарь сопоставления. Отдельно отмечу: и палитра, и подписи, и переиспользуемый компонент легенды, и готовый образец цветного кружка в колонке таблицы в проекте уже есть — просто не подключены в этом разделе. \ components/partner-profile/commission/PreliminaryCommission.vue:185-190, CommissionToPay.vue:191-196 (колонка без format); stores/extendingAccess.ts:19 (тип), :52,63 («Оплачен», «Забронирован»), :433 («К оплате»); есть в проекте, но не используется: shared.fsd/constants/order-status.ts:1-15 (STATUS_COLORS), :18-32 (STATUS_DESCRIPTIONS), features.fsd/order-calendar/ui/Core/Legend.vue, widgets.fsd/order-report/lib/table-configuration.ts:417-437 (образец цветного индикатора в колонке) | Бизнес/Разработка | Open | (А, рекоменд.) Бизнесу — подтвердить, что легенда отчета совпадает с общесистемной легендой статусов заказа, и уточнить обработку статусов «Отменено» / «Отменено со сбором»: они есть в системной палитре, но в BRD раздела не описаны, а исключены только «Выбрано» и «Без статуса». Разработке — после этого переиспользовать STATUS_COLORS и образец из widgets.fsd/order-report/lib/table-configuration.ts:417-437, а не заводить третью копию словаря. (Б) Оставить текстовый статус без цвета и убрать требование о цветовом индикаторе из BRD — вариант дешевле, но расходится с остальными отчетами кабинета. Пока источник данных не подключен (OQ3.2.3-1), реальный набор статусов все равно определится контрактом заказа. | |
| OQ3.2.3-4 | Код FR3.2.3-4, FR3.2.3-11 | Требование говорит: в «Настройках отображения» доступны 7 основных колонок («Дата заказа», «Объект», «Площадка», «Часы», «Итоговая стоимость», «Комиссия», «Статус») и 13 дополнительных («ID заказа», «Дата создания», «Источник», «Комментарий», «Вид работ», «Кол-во», «Позиции», «Скидка на позиции», «Скидка на время», «Сумма скидки», «Сбор», «Промокоды», «Сумма за часы»). В коде список колонок ровно один и состоит из 8 позиций: «Клиент», «Дата», «Объект», «Площадка», «Часы», «Стоимость», «Комиссия», «Статус». Ни одной из 13 дополнительных колонок нет — их не существует ни в списке колонок, ни в типе записи, у которого всего 9 полей. Две основные колонки названы иначе, чем в требовании: «Дата» вместо «Дата заказа» и «Стоимость» вместо «Итоговая стоимость». Обратное расхождение: колонка «Клиент» в коде есть и в тексте FR3.2.3-3 упомянута, но в перечне колонок настроек ее нет. \ components/partner-profile/commission/PreliminaryCommission.vue:142-191, CommissionToPay.vue:148-197; stores/extendingAccess.ts:10-20 (тип записи, 9 полей); не найдено за обход: «ID заказа», «Дата создания», «Источник», «Вид работ», «Позиции», «Скидка на позиции», «Скидка на время», «Сумма скидки», «Сбор», «Промокоды», «Сумма за часы» в components/partner-profile/commission/** и stores/extendingAccess.ts | Бизнес (Герман) | Open | (А, рекоменд.) Подтвердить состав из 20 колонок как целевой и включить недостающие 13 в задачу подключения бэкенда (OQ3.2.3-1) — большинство из них уже есть в контракте заказа, отдельного бэкенда под них не нужно. Заодно зафиксировать в BRD колонку «Клиент» в перечне настроек и согласовать точные подписи «Дата заказа» / «Итоговая стоимость». (Б) Сократить требование до фактических 8 колонок и перенести дополнительные в отдельную итерацию — тогда FR3.2.3-4 и FR3.2.3-11 переписываются под текущий состав. Выбор продуктовый: он определяет, насколько отчет по комиссии должен дублировать отчет по заказам. | |
| OQ3.2.3-5 | Код FR3.2.3-4, FR3.2.3-11, FR3.2.3-16 | Требование говорит: «Настройки отображения» содержат вариант «По умолчанию» и группы «Открыто» и «Скрыто». В коде меню действительно есть и умеет все перечисленные действия — перетаскивание для смены порядка, скрытие и показ отдельной колонки, «Скрыть все», «Показать все» и сброс «По умолчанию». Расходятся только подписи групп: вместо «Открыто» и «Скрыто» отрисовываются заголовки «Видимые» и «Скрытые». Меню общее для всего кабинета, поэтому переименование затронет не только этот раздел. \ components/UI/filters/ColumnsMenu.vue:21 («Видимые»), :51 («Скрытые»), :80 («По умолчанию»), :23-24 («Скрыть все»), :53-54 («Показать все»), :27-45,57-75 (перетаскивание через vuedraggable) | Бизнес (Герман) | Open | (А, рекоменд.) Привести BRD к коду: заменить «Открыто» / «Скрыто» на «Видимые» / «Скрытые». Компонент общий для всех отчетов кабинета, и переименование ради одного раздела рассинхронизирует интерфейс. (Б) Переименовать группы в коде на «Открыто» / «Скрыто» — тогда правку нужно согласовать сразу для всех разделов, где используется это меню, и внести в соответствующие BRD. | |
| OQ3.2.3-6 | Код FR3.2.3-5, FR3.2.3-12 | Требование говорит: меню скачивания содержит действия «Скачать в CSV» и «Скачать в XLS». В коде меню есть и выгрузка работает по-настоящему: CSV собирается с BOM и разделителем «точка с запятой», XLSX — через библиотеку xlsx, и выгружаются все записи, а не только текущая страница. Расходятся подписи и формат: пункты названы «CSV» и «Excel (XLSX)» вместо «Скачать в CSV» и «Скачать в XLS», а второй формат — современный XLSX, а не устаревший XLS. Выгружаются при этом моковые данные (OQ3.2.3-1), а состав столбцов файла повторяет видимые колонки, то есть наследует неполный состав из OQ3.2.3-4. \ components/partner-profile/commission/PreliminaryCommission.vue:51-56, CommissionToPay.vue:51-56, Payments.vue:26-31 (подписи пунктов); composables/useTableExport.ts:38-63 (CSV), :65-76 (XLSX через xlsx), :29 (выгружаются все items, не страница) | Бизнес (Герман) | Open | (А, рекоменд.) Подтвердить XLSX как целевой формат и поправить формулировку BRD с «Скачать в XLS» на «Скачать в XLS(X)»; подписи пунктов привести к макету — это правка на одну строку в каждом из трех компонентов. XLS — устаревший бинарный формат, возвращаться к нему смысла нет. (Б) Если выгрузка в XLS требуется контрагентами партнера, это отдельная задача с подтверждением от бизнеса, что именно XLS обязателен. | |
| OQ3.2.3-7 | Код FR3.2.3-6, FR3.2.3-13 | Требование говорит: интерфейс показывает постраничную навигацию и позволяет переходить между доступными страницами таблицы. В коде навигация есть и переключение страниц работает, но целиком на клиенте: полный массив режется в памяти по 12 записей на страницу, число страниц считается от длины уже загруженного массива. На моках это дает 2 страницы в «Предварительной комиссии», 1 в «Комиссии к оплате» и 1 в «Оплатах». Размер страницы захардкожен и партнеру недоступен. При переходе на реальные данные (OQ3.2.3-1) такая схема потребует тянуть весь отчет одним запросом. Отдельно: компонент пагинации полностью скрывается при одной странице или при нуле — это же поведение делает невыполнимой часть FR3.2.3-7 про «первую страницу постраничной навигации» (OQ3.2.3-8). \ components/partner-profile/commission/PreliminaryCommission.vue:120-131, CommissionToPay.vue:126-137, Payments.vue:95-106 (клиентская нарезка, 12 на страницу); components/UI/table/TablePagination.vue:2 (v-if="totalPages > 1") | Разработка (Влад) | Open | Продуктового выбора нет. Рекомендация: при подключении бэкенда (OQ3.2.3-1) сразу закладывать серверную пагинацию (offset/limit в запросе, общее число записей из ответа), а не переносить текущую клиентскую нарезку — отчет по комиссии растет линейно с числом заказов зоны. Размер страницы вынести в константу модуля. Если бизнесу нужен выбор размера страницы партнером, это отдельное требование, в BRD его сейчас нет. | |
| OQ3.2.3-8 | Код FR3.2.3-7 | Требование говорит: когда в текущем периоде нет заказов, показатели «Кол-во заказов», «Сумарно заказов на:» и «Текущая комиссия» равны нулю, «Перенос комиссии к оплате» показывает «Не определен», таблица показывает заголовки без записей, а постраничная навигация показывает первую страницу. В коде сценарий пустого периода не реализован ни в одной части: показатели выводятся из захардкоженных значений и нулевыми не станут ни при каких данных, строка «Не определен» во всем репозитории не встречается ни разу, а компонент пагинации при нуле страниц не отрисовывается вообще — вместо «первой страницы» партнер не увидит ничего. Из четырех частей требования по факту выполняется одна: заголовки таблицы при пустом списке действительно остаются, и таблица показывает собственную заглушку «Нет данных» — которой, в свою очередь, нет в BRD. \ stores/extendingAccess.ts:35-40 (показатели-константы), :417-422; components/UI/table/TablePagination.vue:2 (скрытие при totalPages <= 1); components/UI/table/DataTable.vue:99-103 (заглушка «Нет данных»), заголовки строятся из колонок, а не из данных — :289-297; не найдено за обход: строка «Не определен» в репозитории | Бизнес/Разработка | Open | Разработке — реализовать пустое состояние вместе с подключением данных (OQ3.2.3-1), отдельно до этого смысла нет: на константах пустой период недостижим. Бизнесу — снять противоречие внутри самого требования: (А, рекоменд.) показывать текст-заглушку «Нет данных» и скрывать пагинацию при пустом списке, как уже делает общий компонент таблицы, и привести формулировку FR3.2.3-7 к этому поведению; (Б) показывать пустую пагинацию с активной страницей «1» — тогда нужна правка общего компонента TablePagination, затрагивающая все отчеты. Значение «Не определен» нужно подтвердить в любом случае — сейчас его нет нигде в продукте. | |
| OQ3.2.3-9 | Код FR3.2.3-9 | Требование говорит: на вкладке «Комиссия к оплате» показываются показатели «Кол-во заказов», «Сумарно заказов на:», «Комиссия к оплате» и «Комиссия за период». В коде вкладка «Комиссия к оплате» отрисовывает подписи, скопированные с вкладки «Предварительная комиссия»: третий и четвертый показатели подписаны «Текущая комиссия» и «Перенос комиссии к оплате» вместо требуемых «Комиссия к оплате» и «Комиссия за период». То есть двух из четырех показателей на вкладке нет, а вместо них показаны показатели соседней вкладки. Под подписями лежат поля currentCommission и commissionTransferDate — те же имена, что и в предварительной комиссии, просто с другими зашитыми значениями. Похоже на копирование шаблона без правки подписей. \ components/partner-profile/commission/CommissionToPay.vue:20,27 (подписи), :118-123 (источник — геттеры к оплате); сравнить с components/partner-profile/commission/PreliminaryCommission.vue:20,27 (идентичные подписи); stores/extendingAccess.ts:417-422 (поля currentCommission, commissionTransferDate) | Разработка (Влад) | Open | Продуктового выбора нет, BRD однозначен. Рекомендация: переименовать два показателя на вкладке «Комиссия к оплате» в «Комиссия к оплате» и «Комиссия за период» и одновременно переименовать поля модели, чтобы они перестали дублировать смысл предварительной комиссии. Смысловое наполнение «Комиссии за период» зависит от правил переноса, которые бизнесу нужно зафиксировать в Back 2.8.1 (см. OQ3.2.3-1) — до этого правка косметическая. | |
| OQ3.2.3-10 | Код FR3.2.3-9, FR3.2.3-15 | Требование говорит: вкладка «Комиссия к оплате» показывает комиссию, перенесенную к оплате «за указанный период», а «Оплаты» — историю с колонкой «Оплаченный период». В коде выбрать период партнер не может нигде: общий заголовок отчета поддерживает выбор даты, но во всех трех вкладках он выключен явным флагом, поиска и фильтров там тоже нет. «Указанный период» существует только как текст внутри данных — например, зашитая строка «01.10.2025 - 31.10.2025» в записи оплаты и строка «28 ноября 2025» в сводке. Из-за этого требование «за указанный период» на текущем интерфейсе непроверяемо: указывать период нечем. \ components/partner-profile/commission/CommissionLayout.vue:4 (:show-date="false", :show-search="false", :has-filter-tree="false"); components/partner-profile/commission/Payments.vue:5-7 (то же); stores/extendingAccess.ts:290 (период как строка в данных), :421 | Бизнес (Герман) | Open | (А, рекоменд.) Уточнить в BRD, что период не выбирается партнером, а определяется расчетным циклом комиссии на бэкенде, и переформулировать FR3.2.3-9 — тогда селектор периода не нужен, но в интерфейсе стоит показывать границы текущего периода явной подписью. (Б) Если партнер должен смотреть комиссию за произвольный период — это новое требование: нужен селектор периода и серверная фильтрация, что связано с OQ3.2.3-1 и OQ3.2.3-7. Выбор продуктовый: он определяет, отчет это «за текущий цикл» или полноценный аналитический отчет. | |
| OQ3.2.3-11 | Код FR3.2.3-17, FR3.2.3-18 | Требование говорит: в таблице «Оплаты» через «Настройки отображения» можно показать дополнительные колонки «Проведено вручную (да/нет)» и «Комментарий»; оба требования помечены как «на будущую реализацию». В коде обеих колонок нет: список колонок оплат состоит ровно из семи требуемых основных, дополнительных нет вообще, а тип записи оплаты содержит 8 полей, среди которых нет ни признака ручного проведения, ни комментария. Расхождение ожидаемое — требования сами помечены как будущие; фиксирую его, чтобы «Не реализовано» не читалось как дефект. \ components/partner-profile/commission/Payments.vue:117-160 (7 колонок, дополнительных нет); stores/extendingAccess.ts:22-31 (тип записи оплаты, 8 полей); не найдено за обход: «Проведено вручную», «Комментарий» в components/partner-profile/commission/** | Бизнес (Герман) | Open | Продуктового выбора по сути нет, нужно подтверждение статуса. Рекомендация: подтвердить, что FR3.2.3-17 и FR3.2.3-18 остаются в статусе «на будущую реализацию» и не входят в текущий скоуп. Если признак ручного проведения и комментарий нужны сразу — их следует закладывать одновременно с подключением бэкенда (OQ3.2.3-1), поскольку оба поля должны прийти из контракта оплаты, которого на фронте пока нет; добавлять их позже будет дороже. |
Вопросы по сверке с кодом
BRD 3.2.3 v0.1 · musbooking_personal_account · commit 93383777/main · 06.08.26 · якорь pages/partner-profile/extending-access, components/partner-profile/commission/, stores/extendingAccess.ts, widgets.fsd|features.fsd|entities.fsd/extending-access, shared.fsd/ui/extending-access, components/UI/table/, components/UI/filters/ColumnsMenu.vue, composables/useTableExport.ts, composables/useTariffMock.ts, shared.fsd/api/, shared.fsd/api-contracts/, classes/api/, server/api/, proto/** Сводка: вопросов 11 (бизнесовых 5 / программных 3 / смешанных 3) · подтверждено без вопросов 0 · находок обратного прохода 6 · «Реализовано» 0 из 18, «Частично» 14, «Не реализовано» 4 Ключевой факт: отчет работает на моках. Все три вкладки читают захардкоженный pinia-стор
stores/extendingAccess.ts:33-514, в котором нет ни одного action и ни одного запроса; каталогаshared.fsd/api/extending-access/не существует, классExtendingAccessApiописан только вMIGRATION.md:221как план. Это тот же вывод, что и в соседнем разделе 3.2.1: весь блок «Продление доступа» — визуальный прототип. Второй по значимости факт: общий компонент таблицыcomponents/UI/table/DataTable.vueвызывает в шаблоне неопределенныеresolveCell/resolveTooltip— статически это TypeError при отрисовке любой непустой строки во всех трех вкладках (см. П2). Прогоном не подтверждалось. Под особым вниманием (вес 1): FR3.2.3-9 — вкладка «Комиссия к оплате» показывает подписи соседней вкладки (прямой дефект копипасты); FR3.2.3-7 — пустое состояние не реализовано ни в одной из четырех частей; FR3.2.3-3 и FR3.2.3-10 — цветового индикатора статуса нет, набор статусов не совпадает с легендой; FR3.2.3-1, -2, -8, -14, -15 — верстка соответствует, данные захардкожены. Маршрутизация выполнена без сверки с гайдбуком (гайдбук не передавался).
Бизнесовые
| № | Связано с | Что в BRD | Что в коде | Где в коде |
|---|---|---|---|---|
| Б1 | FR3.2.3-4, FR3.2.3-11 | В «Настройках отображения» 7 основных колонок и 13 дополнительных («ID заказа», «Дата создания», «Источник», «Комментарий», «Вид работ», «Кол-во», «Позиции», «Скидка на позиции», «Скидка на время», «Сумма скидки», «Сбор», «Промокоды», «Сумма за часы»). | Список колонок один и состоит из 8 позиций, дополнительных нет ни одной; тип записи заказа содержит 9 полей и физически не может отдать требуемые данные. Две колонки названы иначе: «Дата» вместо «Дата заказа», «Стоимость» вместо «Итоговая стоимость». — нужно решение: подтверждать ли состав из 20 колонок как целевой или сокращать требование до фактического. | PreliminaryCommission.vue:142-191; CommissionToPay.vue:148-197; stores/extendingAccess.ts:10-20; не найдено за обход: 13 дополнительных колонок в components/partner-profile/commission/** |
| Б2 | FR3.2.3-4, FR3.2.3-11, FR3.2.3-16 | Группы в «Настройках отображения» называются «Открыто» и «Скрыто». | Меню общее для всего кабинета и умеет все требуемые действия, но группы подписаны «Видимые» и «Скрытые». Переименование затронет все отчеты, а не только этот раздел. — нужно решение: править BRD под код или код под BRD во всех разделах сразу. | components/UI/filters/ColumnsMenu.vue:21,51,80 |
| Б3 | FR3.2.3-5, FR3.2.3-12 | Меню скачивания с действиями «Скачать в CSV» и «Скачать в XLS». | Выгрузка реализована по-настоящему (CSV с BOM; XLSX через библиотеку xlsx; выгружаются все записи, а не текущая страница), но пункты подписаны «CSV» и «Excel (XLSX)», и формат — XLSX, а не XLS. — нужно подтверждение: XLSX вместо устаревшего XLS. | PreliminaryCommission.vue:51-56; CommissionToPay.vue:51-56; Payments.vue:26-31; composables/useTableExport.ts:38-63,65-76,29 |
| Б4 | FR3.2.3-9, FR3.2.3-15 | Комиссия к оплате показывается «за указанный период»; в оплатах есть «Оплаченный период». | Выбрать период нечем: селектор даты, поиск и дерево фильтров выключены явными флагами во всех трех вкладках. Период существует только как строка внутри данных. — нужно решение: период задается расчетным циклом бэкенда или выбирается партнером. | CommissionLayout.vue:4; Payments.vue:5-7; stores/extendingAccess.ts:290,421 |
| Б5 | FR3.2.3-17, FR3.2.3-18 | Дополнительные колонки «Проведено вручную (да/нет)» и «Комментарий» в таблице «Оплаты» (на будущую реализацию). | Обеих колонок нет; список колонок оплат — ровно 7 основных, тип записи оплаты содержит 8 полей без признака ручного проведения и без комментария. — нужно подтверждение: остаются ли требования в статусе «на будущую реализацию». | Payments.vue:117-160; stores/extendingAccess.ts:22-31 |
Программные
| № | Связано с | Что в BRD | Что в коде | Где в коде |
|---|---|---|---|---|
| П1 | FR3.2.3-1, FR3.2.3-2, FR3.2.3-8, FR3.2.3-14, FR3.2.3-15 | Отчет показывает фактические показатели, заказы с начисленной комиссией и историю оплат текущей партнерской зоны. | Данных из бэкенда нет: pinia-стор состоит только из литералов, без actions и без запросов. Сводка предварительной комиссии — 12 / 7 850 ₽ / 1 500 ₽ / «12 мая 2025»; 22 заказа предварительной комиссии; вкладка «Комиссия к оплате» питается геттерами, которые не читают state, а возвращают литералы (8 / 5 200 ₽ / 950 ₽ / «28 ноября 2025» и 8 заказов); 12 записей оплат. Каталога shared.fsd/api/extending-access/ нет, ExtendingAccessApi описан только в плане миграции. Партнерская зона в отчете не используется — смена зоны ни на что не влияет. Бэкенд при этом уже отдает PartnerCommission по заказу, но поле не читается ни одной строкой кода. Документация модуля помечает данные как временные. | stores/extendingAccess.ts:33-514,35-40,42-285,287-408,417-422,423-513; shared.fsd/api-contracts/orders/orders.schema.ts:174; entities.fsd/extending-access/model/mock-data.ts:1-3; entities.fsd/extending-access/README.md:355-359; entities.fsd/extending-access/MIGRATION.md:219-226; не найдено за обход: запросы комиссии и оплат доступа в shared.fsd/api/, classes/api/, server/api/, proto/ |
| П2 | FR3.2.3-3, FR3.2.3-10, FR3.2.3-15 | Интерфейс показывает таблицу с записями. | Общий компонент таблицы шесть раз вызывает в шаблоне resolveCell / resolveTooltip, которые нигде не определены: ни в его script setup, ни в каталогах авто-импорта Nuxt, ни как экспорт где-либо в репозитории. Единственное определение — локальное внутри другого компонента и не экспортируется. Статически это TypeError при отрисовке любой непустой строки; прогоном не подтверждалось. Дефект затрагивает всех потребителей компонента, а не только этот раздел. | components/UI/table/DataTable.vue:71,72,75,79,80,83 (вызовы), :123-307 (нет определений); shared.fsd/ui/tables/DataTable.vue:113 (чужое локальное определение); PreliminaryCommission.vue:82-90; CommissionToPay.vue:82-90; Payments.vue:58-66 |
| П3 | FR3.2.3-9 | На вкладке «Комиссия к оплате» показываются «Кол-во заказов», «Сумарно заказов на:», «Комиссия к оплате», «Комиссия за период». | Третий и четвертый показатели подписаны «Текущая комиссия» и «Перенос комиссии к оплате» — подписи скопированы с вкладки «Предварительная комиссия», требуемых показателей на вкладке нет. Под подписями лежат поля с теми же именами, что и в предварительной комиссии. Похоже на копирование шаблона без правки подписей. | CommissionToPay.vue:20,27,118-123; PreliminaryCommission.vue:20,27 (идентичные подписи); stores/extendingAccess.ts:417-422 |
| П4 | FR3.2.3-3, FR3.2.3-10 | В колонке «Статус» — цветовой индикатор по легенде из четырех статусов. | Колонка объявлена без format и без слота, то есть выводится обычным текстом; цветового индикатора нет. Значения статусов приходят из мока свободными строками («Оплачен», «Забронирован», «К оплате»), тип поля — просто string, и ни одна строка не совпадает с ключами общесистемной палитры. При этом палитра, подписи, компонент легенды и готовый образец цветного кружка в колонке в проекте уже есть и не подключены. | PreliminaryCommission.vue:185-190; CommissionToPay.vue:191-196; stores/extendingAccess.ts:19,52,63,433; не подключено: shared.fsd/constants/order-status.ts:1-15,18-32; features.fsd/order-calendar/ui/Core/Legend.vue; widgets.fsd/order-report/lib/table-configuration.ts:417-437 |
| П5 | FR3.2.3-6, FR3.2.3-13 | Постраничная навигация с переходом между доступными страницами. | Навигация работает, но целиком на клиенте: массив режется в памяти по 12 записей, число страниц считается от длины уже загруженного массива, размер страницы захардкожен. При переходе на реальные данные потребуется тянуть весь отчет одним запросом. Компонент пагинации полностью скрывается при одной странице или при нуле. | PreliminaryCommission.vue:120-131; CommissionToPay.vue:126-137; Payments.vue:95-106; components/UI/table/TablePagination.vue:2 |
| П6 | FR3.2.3-7 | Пустой период: нулевые показатели, «Не определен» для переноса комиссии, заголовки без записей, первая страница пагинации. | Из четырех частей выполняется одна. Показатели — константы и нулевыми не станут; строки «Не определен» нет во всем репозитории; пагинация при нуле страниц не отрисовывается вообще, поэтому «первой страницы» не будет. Заголовки таблицы при пустом списке действительно сохраняются (строятся из колонок, а не из данных), и показывается заглушка «Нет данных», которой нет в BRD. | stores/extendingAccess.ts:35-40,417-422; components/UI/table/TablePagination.vue:2; components/UI/table/DataTable.vue:99-103,289-297; не найдено за обход: строка «Не определен» в репозитории |
Находки обратного прохода (код сверх BRD)
| № | Что в коде | Почему это важно | Где в коде |
|---|---|---|---|
| О1 | Все колонки всех трех таблиц объявлены сортируемыми, и общий компонент таблицы прокидывает сортировку в заголовки (sortable: c.sortable ?? true). | Партнер может сортировать отчет по любой колонке — поведение, которого нет ни в одном FR раздела. При клиентской пагинации сортировка применяется ко всему массиву, а при переходе на серверную ее поведение изменится. Стоит либо задокументировать в BRD, либо осознанно отключить. | PreliminaryCommission.vue:211-217; CommissionToPay.vue:217-223; Payments.vue:180; components/UI/table/DataTable.vue:289-297 |
| О2 | Компонент components/ExtendingAccessContent.vue на 785 строк не импортируется нигде в проекте — поиск по репозиторию не дает ни одной ссылки, кроме самого файла. | Мертвый код, дублирующий раздел «Продление доступа» и тоже завязанный на моковый тариф. Создает риск правки не того файла при доработке раздела. | components/ExtendingAccessContent.vue (785 строк); :274,276 (использует useTariffMock); не найдено за обход: импорты ExtendingAccessContent в *.vue и *.ts |
| О3 | Параллельно с рабочими вкладками существует неиспользуемый FSD-слой entities.fsd/extending-access + features.fsd/extending-access: типы, геттеры, отдельный набор моков, README и MIGRATION. Вкладки отчета его не импортируют — они ходят напрямую в легаси-стор. | В проекте два независимых представления одних и тех же данных. Готовые типы и геттеры под подключение бэкенда уже написаны, но не подключены — их можно переиспользовать вместо новых при работе по OQ3.2.3-1. Тот же вывод зафиксирован в разделе 3.2.1. | entities.fsd/extending-access/types.ts; entities.fsd/extending-access/lib/extending-access.getters.ts; entities.fsd/extending-access/model/mock-data.ts; features.fsd/extending-access/model/extending-access.ui.ts:13,21; PreliminaryCommission.vue:103, CommissionToPay.vue:103, Payments.vue:79 (импорт легаси-стора) |
| О4 | Колонка «Клиент» присутствует в коде обеих таблиц комиссии и упомянута в тексте FR3.2.3-3 и FR3.2.3-10, но отсутствует в перечне колонок «Настроек отображения» в FR3.2.3-4. | Противоречие внутри самого BRD, а не расхождение с кодом. Если перечень колонок настроек считать закрытым, «Клиент» окажется колонкой, которую нельзя скрыть; код же позволяет ее скрывать. | PreliminaryCommission.vue:143-148; CommissionToPay.vue:149-154 |
| О5 | Выгрузка в CSV и XLSX отдает все записи отчета, а не только текущую страницу, и включает только видимые на момент выгрузки колонки. | Поведение разумное, но в BRD не зафиксировано: FR3.2.3-5 и FR3.2.3-12 не уточняют, выгружается страница или весь отчет и учитываются ли настройки колонок. Стоит закрепить, чтобы это не поменялось при переходе на серверную пагинацию. | composables/useTableExport.ts:16,29-36 |
| О6 | Меню колонок поддерживает действие «Копировать информацию», а также перенос колонок перетаскиванием между группами «Видимые» и «Скрытые». | «Копировать информацию» в этом разделе не включено (флаг не передается, по умолчанию выключен), но доступно в компоненте — при включении появится действие, которого нет в BRD. Перенос перетаскиванием между группами шире, чем описанные в FR3.2.3-4 «изменить порядок» и «скрыть или показать отдельную колонку». | components/UI/filters/ColumnsMenu.vue:4-16,95 (копирование, флаг showCopyAction); :27-45,57-75 (группы с pull/put) |