Направление работ: AdmLk Код раздела: 3.2.1 Раздел: Управление > Клиенты > Карточка клиента Статус: Готов Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 23.06.26
1. Назначение
Данный раздел обеспечивает сотруднику сервисного кабинета интерфейс для просмотра и сервисной работы с карточкой клиента.
Сотрудник видит основные сведения клиента, сообщения, данные по партнерам, заказы, баллы, подписки и доступные сервисные действия в рамках админской зоны.
Функциональное назначение раздела — дать единую точку работы с клиентом без переноса в текущий раздел полного управления заказами, подписками и backend-операциями.
Раздел зависит от Back: 1.3 Аккаунты и пользователи > Клиенты, Back: 8.5 Администрирование > Управление клиентами и Back: 8.5.1 Администрирование > Управление клиентами > Сервисные операции с клиентами.
2. Ключевые понятия
Карточка клиента — экран просмотра и сервисной работы с данными клиента в AdmLk 3.2.1.
Основные сведения клиента — имя, контакты, аватар или заменяющий элемент, статус, подписка, баллы и дополнительные данные клиента.
Сообщения по клиенту — записи о клиенте с текстом, автором, датой и настройкой доступа на просмотр.
Партнерская информация клиента — данные по взаимодействию клиента с партнерами: заказы, промокоды, сборы и статусы.
Сбор — информация о задолженности клиента перед конкретным партнером с указанием причины ее возникновения. Подробнее понятие описано в разделе Back 3.2.1 Сборы за заказ.
Баллы клиента — текущий баланс баллов и записи по начислению или изменению баллов.
Подписки клиента — клиентские тарифы, отображаемые в карточке с датами действия.
Сервисные действия — действия сотрудника админской зоны с клиентом: блокировка, сообщения, баллы и просмотр связанных данных.
3. Scope
Входит
S1: Открытие карточки клиента S2: Просмотр основных сведений клиента S3: Работа с панелью “О клиенте” S4: Работа с сообщениями по клиенту S5: Просмотр связанных данных клиента S6: Работа с баллами клиента S7: Просмотр подписок клиента S8: Состояния интерфейса
Не входит
- AdmLk 3.2 Управление > Клиенты
- WebLk 6.4.1 Отчеты > Клиенты > Карточка клиента
- Back 3.2 / 3.2.1 / 3.2.2 — процессинг заказов, сборы и заявки
- Back 8.3.4 — управление тарифами и подписками
- Полный сценарий создания, редактирования, отмены и оплаты заказа
- Создание и настройка клиентских тарифов
- Backend/API-контракты, структура БД и техническая реализация
4. BR
Указаны в пункте 4 разделов Back: 1.3 Аккаунты и пользователи > Клиенты, Back: 8.5 Администрирование > Управление клиентами и Back: 8.5.1 Администрирование > Управление клиентами > Сервисные операции с клиентами.
5. Функциональные требования (UC + FR) {#5-funkcionalnye-trebovaniya-uc-fr}
FR – functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Cценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR3.2.1-1 | Сотрудник открывает карточку клиента | Интерфейс открывает карточку выбранного клиента в админской зоне и показывает заголовок, данные клиента, и блок его заказов и подписок с хлебными крошками. | 1 | Не реализовано OQ3.2.1-1, OQ3.2.1-8 | |
| S1: FR3.2.1-2 | Сотрудник возвращается к списку клиентов | Интерфейс позволяет вернуться из карточки к разделу управления клиентами. | 2 | Не реализовано OQ3.2.1-8 | |
| S2: FR3.2.1-3 | Сотрудник просматривает основные сведения клиента | Интерфейс показывает имя клиента, телефон, электронную почту, аватар или заменяющий элемент, признак подписки и текущий баланс баллов. | 1 | Не реализовано OQ3.2.1-1, OQ3.2.1-2 | |
| S2: FR3.2.1-4 | Сотрудник просматривает дополнительные сведения клиента | Интерфейс показывает дату рождения, пол, ссылки на VK и Telegram, если эти данные заполнены. | 2 | Не реализовано OQ3.2.1-2 | |
| S2: FR3.2.1-5 | Сотрудник просматривает деятельность клиента | Интерфейс позволяет раскрыть блок “Деятельность” и показывает сферу деятельности, род деятельности, профессиональный навык, музыку и танцы, если эти данные заполнены. | 2 | Не реализовано OQ3.2.1-2 | |
| S3: FR3.2.1-6 | Сотрудник открывает панель “О клиенте” | Интерфейс открывает боковую панель “О клиенте” и показывает имя, фамилию, телефон, электронную почту, статус, баллы, дополнительные сведения и деятельность клиента. | 1 | Не реализовано OQ3.2.1-1, OQ3.2.1-2 | |
| S3: FR3.2.1-7 | Сотрудник блокирует клиента (На будущую реализацию) | Интерфейс позволяет нажать “Заблокировать”, показывает подтверждение блокировки и применяет действие только после подтверждения. | 2 | — OQ3.2.1-14 | |
| S3: FR3.2.1-8 | Сотрудник просматривает автора создания клиента (на будущую реализацию) | Интерфейс показывает поле “Кем создан” в панели “О клиенте”. | 3 | — OQ3.2.1-14 | |
| S3: FR3.2.1-9 | Сотрудник просматривает привязанные карты клиента (на будущую реализацию) | Интерфейс позволяет открыть список привязанных банковских карт клиента с маской номера и признаком активной карты. | 3 | — OQ3.2.1-14 | |
| S4: FR3.2.1-10 | Сотрудник просматривает сообщения по клиенту | Интерфейс показывает сообщения по клиенту с датой, временем, текстом, автором и доступными данными автора. | 1 | Не реализовано OQ3.2.1-5 | |
| S4: FR3.2.1-11 | Сотрудник добавляет сообщение по клиенту | Интерфейс позволяет ввести текст сообщения, выбрать доступ на просмотр и отправить сообщение в карточку клиента. | 1 | Не реализовано OQ3.2.1-5 | |
| S4: FR3.2.1-12 | Сотрудник редактирует сообщение по клиенту | Интерфейс позволяет открыть меню сообщения, выбрать “Редактировать”, изменить текст или доступ на просмотр и сохранить изменения. | 2 | Не реализовано OQ3.2.1-5 | |
| S4: FR3.2.1-13 | Сотрудник удаляет сообщение по клиенту | Интерфейс позволяет открыть меню сообщения и выбрать “Удалить”. | 2 | Не реализовано OQ3.2.1-5 | |
| S5: FR3.2.1-14 | Сотрудник переключает вкладки карточки клиента | Интерфейс позволяет переключаться между вкладками “Сообщения по клиенту”, “Информация по клиенту”, “Баллы” и “Подписки” без выхода из карточки. | 2 | Не реализовано OQ3.2.1-8 | |
| S5: FR3.2.1-15 | Сотрудник просматривает информацию по клиенту | Интерфейс показывает таблицу по партнерам с колонками “Партнер”, “Заказы”, “Промокод”, “Сбор” и “Статус”. | 1 | Не реализовано OQ3.2.1-6, OQ3.2.1-12 | |
| S5: FR3.2.1-16 | Сотрудник просматривает заявки и заказы клиента | Интерфейс показывает список заказов клиента, а при включенной работе по заявкам — также список заявок клиента. Для работы со списком доступны поиск, фильтры по периоду, партнеру и статусу, счетчик заказов, таблица и легенда статусов. Состояния заказов: — Без статуса; — Зарезервировано; — Частично оплаченный; — Оплаченный; — Закрытый; — Отмененный без сбора; — Отмененный со сбором. Состояния заявок: — Новая заявка; — Необработанная; — В работе; — Отклонена. | 1 | Не реализовано OQ3.2.1-3 | |
| S5: FR3.2.1-17 | Сотрудник открывает заказ клиента | Интерфейс открывает боковую панель заказа и показывает клиента, дату и время, статус, источник, объект, площадку и опционально: вид работ (опции), количество людей, оборудование, услуги, комментарии, скидки, баллы, стоимость, сбор и доступные действия с заказом. | 2 | Не реализовано OQ3.2.1-3 | |
| S5: FR3.2.1-18 | Сотрудник просматривает историю изменений (на будущую реализацию) | Интерфейс показывает вкладку “История изменений” с событиями, датой, автором и содержанием изменения . | 3 | — OQ3.2.1-14 | |
| S6: FR3.2.1-19 | Сотрудник просматривает баллы клиента | Интерфейс показывает текущий баланс баллов и записи по операциям с баллами клиента. | 1 | Не реализовано OQ3.2.1-4 | |
| S6: FR3.2.1-20 | Сотрудник начисляет баллы клиенту | Интерфейс позволяет указать количество баллов, выбрать причину или доступный тип операции и начислить баллы клиенту. | 1 | Не реализовано OQ3.2.1-4 | |
| S6: FR3.2.1-21 | Сотрудник редактирует запись по баллам | Интерфейс позволяет открыть меню записи по баллам, выбрать “Редактировать”, изменить доступные поля и сохранить изменения. | 2 | Не реализовано OQ3.2.1-4 | |
| S6: FR3.2.1-22 | Сотрудник удаляет запись по баллам | Интерфейс позволяет открыть меню записи по баллам и выбрать “Удалить”. | 2 | Не реализовано OQ3.2.1-4 | |
| S7: FR3.2.1-23 | Сотрудник просматривает подписки клиента | Интерфейс показывает подписки клиента в таблице с названием, стоимостью, датой активации и датой окончания действия. | 1 | Не реализовано OQ3.2.1-7 | |
| S8: FR3.2.1-24 | Сотрудник открывает карточку, данные загружаются | Интерфейс показывает состояние загрузки карточки клиента. | 2 | Не реализовано OQ3.2.1-10 | |
| S8: FR3.2.1-25 | Сотрудник открывает карточку без части данных | Интерфейс показывает пустое состояние в блоках, где у клиента нет сообщений, заказов, баллов или дополнительных сведений. | 2 | Не реализовано OQ3.2.1-10 | |
| S8: FR3.2.1-26 | Сотрудник использует карточку на разных ширинах экрана | Интерфейс адаптирует карточку клиента, таблицы и боковые панели для desktop, laptop и tablet без потери доступных действий. | 2 | Не реализовано OQ3.2.1-9 | |
| S8: FR3.2.1-27 | Сотрудник выполняет действие, которое завершилось ошибкой | Интерфейс показывает ошибку в текущем контексте и позволяет повторить действие, если повтор доступен. | 2 | Не реализовано OQ3.2.1-10 |
6. Открытые вопросы {#6-otkrytye-voprosy}
BRD 3.2.1 v0.1 · репозиторий
musbooking.weblk.adminpanel· commitc3765793801affc3bf4e6f67f42ba60045c168f8/main· дата сверки 2026-07-15 Якорь:pages/management/clients.vue,widgets/clients/,shared/api/ClientsService.ts(обход расширен на весь репозиторий, т.к. в якоре реализации не оказалось) Сводка: вопросов 14 (Open 13 · Закрывает PM 0 · Подтверждено 1) · отрезано находок обратного прохода 8 Маршрутизация без сверки с гайдбуком — гайдбук на вход не передавался, поэтому ни одно расхождение не квалифицировано как баг: спорные места отправлены бизнесу как «подтвердить нечем». Главное: раздел не реализован — 23 из 27 требований описывают экран, которого в коде нет; 4 требования помечены «на будущую реализацию», и их отсутствие ожидаемо. Это BRD, опережающий код, а не код, разошедшийся с BRD. Примечание к нумерации: во входном BRD v0.1 строкаOQ3.2.1-1была пустой строкой-заготовкой (без источника, вопроса и адресата); содержимого она не несла, поэтому нумерация начата сOQ3.2.1-1. Ни одно требование, формулировка, ссылка или комментарий BRD не изменены — заполнена только колонка «Статус».
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ3.2.1-1 | Код FR3.2.1-1 (и весь раздел) | Требование говорит: сотрудник открывает карточку клиента с заголовком, данными клиента, блоком заказов и подписок и хлебными крошками. В коде раздела «Клиенты» в админ-панели нет: по адресу /management/clients открывается страница-заглушка из четырёх строк — заголовок «Клиенты» и текст «Здесь будет управление клиентами»; отдельного адреса карточки клиента (вида /management/clients/<id>) в приложении не существует, слоя данных о клиенте — тоже. Все 23 требования раздела, кроме помеченных «на будущую реализацию», описывают экран, которого сейчас нет. \ widgets/clients/ui/ClientsWidget.vue:1-14, pages/management/clients.vue:1-13 | Бизнес (Герман) / Разработка (Владислав) | Open | (А) Признать BRD 3.2.1 спецификацией на будущую разработку и зафиксировать это статусом раздела — рекомендуется: BRD в статусе «черновик» v0.1, разработка не начиналась, поэтому «Не реализовано» здесь не дефект, а состояние «к разработке»; (Б) Проверить, не описан ли фактически другой кабинет: WebLk 6.4.1 «Отчеты > Клиенты > Карточка клиента» вынесен в «Не входит», но похожий экран может жить именно там — тогда сверку нужно перезапустить против того репозитория. Разблокирующий вопрос: ответ определяет судьбу всех остальных строк раздела. | Артем: Согласен с (А). Раздел в процессе разработки с нуля. |
| OQ3.2.1-2 | Код FR3.2.1-3, FR3.2.1-4, FR3.2.1-5, FR3.2.1-6 | Требование говорит: карточка показывает имя, телефон, почту, аватар, признак подписки и баланс баллов, а также дату рождения, пол, ссылки на VK и Telegram и блок «Деятельность» (сфера, род деятельности, профессиональный навык, музыка, танцы). В коде единственный способ получить данные клиента — служебное обращение, написанное для формы промокодов; оно возвращает пять полей: идентификатор, имя, фамилию, телефон и почту. Поле аватара в нём объявлено, но в обоих преобразованиях ответа жёстко подставляется пустое значение — картинка не приходит даже формально. Дата рождения, пол, VK, Telegram, признак подписки и баланс баллов у клиента в админ-панели не встречаются; слово «Деятельность» не найдено во всём коде ни разу. \ shared/api/ClientsService.ts:7-14,35,50,63; остальное — не найдено за обход (искал по всему репозиторию) | Разработка (Владислав) | Open | (А) До разработки выяснить у бэкенда (Back 1.3), какие из перечисленных полей вообще отдаёт получение клиента по идентификатору, и дополнить BRD ссылкой на конкретные BR — рекомендуется: фронт сегодня знает о клиенте пять полей, и до половины карточки рискует остаться без источника данных; (Б) Отложить выяснение до момента разработки — дешевле сейчас, дороже при реализации. Связать с OQ3.2.1-1. | Артем: О недоработках бэку уже сообщил, частично исправлено. В процессе тестов и доработок. |
| OQ3.2.1-3 | Код FR3.2.1-16, FR3.2.1-17 | Требование говорит: карточка показывает список заказов клиента с поиском, фильтрами по периоду, партнёру и статусу, счётчиком и легендой статусов, а по клику открывает боковую панель заказа. В коде в админ-панели нет ни сущности заказа, ни службы работы с заказами, ни панели заказа; страница «Отчёт по заказам» — заглушка с одним заголовком. При этом есть готовый набор параметров отбора заявок, который уже умеет фильтровать по клиенту, партнёрской зоне, периоду и статусу, но им никто не пользуется. Заявка и заказ в коде — разные вещи: заявка лишь конвертируется в заказ, после чего у заказа начинается собственный статус. Легенда статусов не найдена: слово «легенда» во всём коде отсутствует. \ shared/types/request.ts:41-50,55-65, widgets/report-orders/ui/ReportOrdersWidget.vue:1-13 | Бизнес (Герман) | Closed | (А) Уточнить в BRD, что показывает блок — заказы, заявки или и то и другое, и какие статусы попадают в легенду — рекомендуется: на фронте эти понятия разведены, и без ответа требование нельзя ни оценить, ни проверить; (Б) Оставить «заказы» и явно вынести заявки за скоуп раздела. Связать с OQ3.2.1-1. | Артем: Согласен с (А). Нужно зафиксировать, что показывает блок и какие статусы в легенде. От бизнеса: внесли уточнение в БРД. |
| OQ3.2.1-4 | Код FR3.2.1-19, FR3.2.1-20, FR3.2.1-21, FR3.2.1-22 | Требование говорит: карточка показывает баланс баллов и записи по операциям, позволяет начислить баллы с указанием количества и причины, отредактировать и удалить запись. В коде раздел «Баллы» существует, но это справочник правил начисления в настройках (/settings/parameters/scores): у правила есть название, описание, количество и причина, и оно не привязано ни к какому клиенту. Баланса баллов конкретного клиента и истории операций по нему в админ-панели не найдено. \ entities/score/store/scores.api.ts:19-33, pages/settings/parameters/scores.vue:8-11 | Бизнес (Герман) | Open | (А) Указать в BRD, берётся ли «причина» начисления из существующего справочника правил начисления баллов или это независимый список — рекомендуется: справочник уже есть, переиспользование избавит от второго списка причин и расхождений между ними; (Б) Считать начисление в карточке отдельным механизмом — тогда нужно решение бизнеса, зачем в системе два источника причин. Связать с OQ3.2.1-1. | Артем: вариант (А). От бизнеса: внесем уточнения в БРД после разговора с Германом. |
| OQ3.2.1-5 | Код FR3.2.1-10, FR3.2.1-11, FR3.2.1-12, FR3.2.1-13 | Требование говорит: карточка показывает сообщения по клиенту с датой, временем, текстом и автором, позволяет добавить сообщение с выбором доступа на просмотр, отредактировать и удалить его. В коде сообщений по клиенту не найдено ни в каком виде: ни экрана, ни обращения к данным, ни настройки доступа. Само понятие «доступ на просмотр» нигде в коде не определено — неизвестно, кто и кого при этом видит. \ не найдено за обход (искал по всему репозиторию админ-панели: «сообщение по клиенту», ClientMessage, заметки/комментарии к клиенту) | Бизнес (Герман) | Open | (А) Описать в BRD, что означает «доступ на просмотр»: кто адресат ограничения — только сотрудники админской зоны, партнёр, автор сообщения — рекомендуется: без этого требование FR3.2.1-11 (вес 1) нельзя ни реализовать, ни принять; (Б) Сослаться на готовое правило из Back 8.5.1, если оно там уже описано, и не дублировать формулировку. Связать с OQ3.2.1-1. | Артем: UI делаю, но на бэке метода для создания сообщений пока нет. Лучше эти требования описать. От бизнеса: ДОРАБОТКА после АБАК — дополнить БРД и реализовать. |
| OQ3.2.1-6 | Код FR3.2.1-15 | Требование говорит: вкладка «Информация по клиенту» показывает таблицу по партнёрам с колонками «Партнер», «Заказы», «Промокод», «Сбор» и «Статус». В коде такой таблицы нет; страницы «Партнеры» и «Информация о партнёрах», где она была бы уместна, — заглушки с одним заголовком. Отдельно: понятие «Сбор» не встречается в коде админ-панели ни разу, поэтому непонятно, что это за величина и откуда её брать. \ widgets/partners/ui/PartnersWidget.vue:1-14, widgets/report-partners/ui/ReportPartnersWidget.vue:1-13; «Сбор» — не найдено за обход | Бизнес (Герман) | Closed | (А) Определить в BRD, что такое «Сбор» (комиссия партнёра за период? сумма сборов по заказам клиента?) и из какого раздела берутся данные — рекомендуется: четыре колонки из пяти понятны, эта — нет, и она же тянет за собой Back 3.2.2, вынесенный в «Не входит»; (Б) Убрать колонку из требования до появления раздела о сборах. Связать с OQ3.2.1-1. | Артем: У нас это что то вроде “долга” за неуплату. Лучше описать. От бизнеса: описали в ключевых понятиях. |
| OQ3.2.1-7 | Код FR3.2.1-23 | Требование говорит: карточка показывает подписки клиента таблицей с названием, стоимостью, датой активации и датой окончания. В коде подписок клиента нет; ближайшее место — вкладка «Клиентские тарифы» в разделе тарифов, но она тоже заглушка из пяти строк без всякой логики (в том разделе из пяти вкладок реально сделана одна — партнёрские тарифы). То есть требование опирается на раздел, который сам ещё не сделан. \ widgets/tariffs/ui/ClientTariffsTab.vue:1-5 | Бизнес (Герман) | Open | (А) Зафиксировать в BRD зависимость: подписки в карточке появятся только после раздела клиентских тарифов (Back 8.3.4 вынесен в «Не входит») — рекомендуется: снимает ложное ожидание, что подписки входят в объём работ по карточке; (Б) Оставить как есть — тогда требование веса 1 заблокируется на старте разработки. Связать с OQ3.2.1-1. | Артем: Пока этот элемент не могу реализовать, потому что на бэке, как я понимаю, вообще тарифов пока нет. Думаю, описание нужно не только здесь, а в целом требуется продуманная структура тарифов. От бизнеса: ожидаем реализации тарифов. |
| OQ3.2.1-8 | Код FR3.2.1-1, FR3.2.1-2, FR3.2.1-14 | Требование говорит: карточка открывается как экран с хлебными крошками, позволяет вернуться к списку клиентов с сохранением предыдущего контекста и переключать вкладки без выхода из карточки. В коде способ открытия ещё не выбран, и требование конфликтует со сложившимся устройством админ-панели: все карточки сущностей сделаны боковыми панелями поверх списка, отдельным адресом открывается только редактирование шаблона уведомления. Хлебные крошки собираются автоматически из адреса страницы и умеют показывать только заранее прописанные названия разделов — подставить в крошку имя клиента сейчас нечем: механизм передачи крошек снаружи в коде есть, но к макету страниц он не подключён и фактически не работает. Сохранение предыдущего контекста (фильтров списка) при возврате не реализовано нигде. \ features/header-breadcrumbs/model/useHeaderBreadcrumbs.ts:55-85, layouts/default.vue:9, pages/settings/notifications-templates/update/[id].vue:22-25 | Разработка (Владислав) | Closed | (А) Выбрать до разработки: карточка — отдельный адрес (тогда нужны динамические хлебные крошки и возврат с фильтрами) или боковая панель (крошки не нужны, контекст списка сохраняется сам) — рекомендуется: FR3.2.1-1, -2 и -14 читаются как «отдельный экран», а весь остальной интерфейс построен на панелях; противоречие дешевле снять сейчас; (Б) Оставить решение на этап разработки — риск переделки требований задним числом. Связать с OQ3.2.1-1. | Артем: Сейчас для таблицы с клиентами ХК - “Клиенты”, а для страницы с карточкой любого клиента - “Информация о клиенте”, при выходе из которой мы возвращаемся в “Клиенты”. Добавлять туда какие то вкладки с сохранением контекста на мой взгляд - избыточно. Несколько разных карточек с разными клиентами можно открыть просто во вкладках браузера. От бизнеса: поправили требование. |
| OQ3.2.1-9 | Код FR3.2.1-26 | Требование говорит: карточка, таблицы и боковые панели подстраиваются под desktop, laptop и tablet без потери доступных действий. В коде единой системы контрольных ширин экрана нет: готовые средства определения размера экрана не используются, вместо них по коду разбросано около десяти правил вёрстки с шестью разными пороговыми ширинами (640, 720, 768, 900, 1024, 1200 пикселей), а у таблиц высота задана жёстко. Что такое desktop, laptop и tablet в цифрах, в коде не определено, поэтому требование нечем проверить. \ layouts/default.vue:43,56, shared/ui/navigation/TabsContainer.vue:442,504, shared/ui/data-table/DataTable.vue:71 | Разработка (Владислав) | Closed | (А) Указать в BRD конкретные ширины для desktop/laptop/tablet и завести общий набор пороговых значений — рекомендуется: сейчас требование непроверяемо, а каждый экран задаёт свои пороги; (Б) Убрать перечисление устройств и потребовать «интерфейс не теряет действий при уменьшении ширины» — слабее, но проверяемо. Связать с OQ3.2.1-1. | Артем: Поскольку сервисные кабинет будет использоваться только в офисе на ПК, то первоначально жестких требований к адаптивности не было. При разработке учитывается, чтобы на разных экранах разделы выглядели читаемо, поэтому предлагаю вопросы правил адаптивности помечать с весом 3. От бизнеса: принято, вес требования не меняем, так как это общее универсальное требование, которое подразумевает наличие адаптивов в любом рабочем виде. |
| OQ3.2.1-10 | Код FR3.2.1-24, FR3.2.1-25, FR3.2.1-27 | Требование говорит: карточка показывает состояние загрузки, пустые состояния в блоках без данных и ошибку с возможностью повторить действие. В коде для карточки клиента этого нет (её самой нет), но в соседних разделах уже сложился рабочий образец: на время загрузки — скелет таблицы, в пустой таблице — стандартный текст «Нет данных», над таблицей — полоса ошибки. Повтора действия после ошибки в этом образце нет ни у одного раздела: полоса ошибки только показывает текст и закрывается; в части списков её нет вовсе. \ features/city-list/ui/CitiesList.vue:6,33,36-37,117, shared/ui/notifications/ErrorBar.vue:16-27, shared/ui/data-table/DataTable.vue:28-32 | Разработка (Владислав) | Open | (А) Переиспользовать сложившийся образец состояний и отдельно решить, для каких действий карточки нужен повтор после ошибки — рекомендуется: оговорка «если повтор доступен» в BRD не раскрыта, а в коде повтора нет нигде, то есть требование по факту описывает новый механизм; (Б) Перечислить в BRD конкретные повторяемые действия. Связать с OQ3.2.1-1. | Артем: Согласен с (А). Переиспользую скелет / «Нет данных» / ErrorBar. Повтор после ошибки - новый механизм. От бизнеса: принято. |
| OQ3.2.1-11 | Код вне BRD | Что нашли: в админ-панели уже есть работающее обращение к данным клиента — поиск клиентов по строке и получение клиента по идентификатору. Написано оно для подсказок в форме промокодов и используется только там, но это готовая точка входа для будущей карточки. В требованиях раздела не упомянуто. Попутно: объявленное в нём поле аватара всегда пустое, поэтому в форме промокодов аватары клиентов не отображаются — на промокоды это влияет уже сейчас. \ shared/api/ClientsService.ts:1-2,22,35,50,63, features/promo-code-drawer/model/usePromoCodeDrawer.clients.ts:99,145 | Разработка (Владислав) | Open | (А) При разработке карточки переиспользовать существующее обращение, расширив состав полей, и заодно решить судьбу пустого аватара — рекомендуется: иначе в системе появится второй способ получать того же клиента; (Б) Сделать для карточки отдельный слой данных, промокодам оставить свой — сознательное дублирование. Связать с OQ3.2.1-2. | Артем: Согласен с (А). Расширяю существующий ClientsService, пустой аватар поправлю заодно. |
| OQ3.2.1-12 | Код вне BRD | Что нашли: существующий поиск клиентов обязательно требует указать партнёрскую зону — искать клиента «по всей системе» этим способом нельзя. Для сервисного кабинета, который смотрит на клиента поверх партнёров (вкладка «Информация по клиенту» показывает таблицу сразу по нескольким партнёрам), это ограничение может оказаться несовместимым с задачей. В требованиях раздела вопрос не затронут. \ shared/api/ClientsService.ts:22-27 | Разработка (Владислав) | Open | (А) Проверить на бэкенде (Back 8.5), есть ли получение клиента и его связанных данных без привязки к партнёрской зоне — рекомендуется: от этого зависит, реализуема ли вкладка «Информация по клиенту» в принципе; (Б) Отложить до разработки. Связать с OQ3.2.1-6. | Артем: На это я уже указал бэку, проблему они исправили. |
| OQ3.2.1-13 | Код вне BRD | Что нашли: заглушками в админ-панели остаются девять разделов из тридцати двух, и среди них — весь блок, на который опирается карточка клиента: «Клиенты», «Партнеры», «Отчёт по заказам», «Информация о партнёрах». Карточка клиента не единственный несделанный раздел, а часть несделанного блока; в требованиях эта зависимость не отражена. \ widgets/clients/ui/ClientsWidget.vue:3-4, widgets/partners/ui/PartnersWidget.vue:3-4, widgets/report-orders/ui/ReportOrdersWidget.vue:3, widgets/report-partners/ui/ReportPartnersWidget.vue:3 | Бизнес (Герман) | Open | (А) Планировать 3.2.1 в одном заходе с AdmLk 3.2 «Клиенты» (точка входа, вынесена в «Не входит») — рекомендуется: карточка открывается из списка клиентов, которого нет, поэтому раздельная разработка невозможна; (Б) Начать с карточки по прямой ссылке — быстрее, но без списка её нельзя ни открыть штатно, ни принять. Связать с OQ3.2.1-1. | Артем: уже описали оба рездела. |
| OQ3.2.1-14 | Код FR3.2.1-7, FR3.2.1-8, FR3.2.1-9, FR3.2.1-18 | Что подтверждено: четыре требования помечены «на будущую реализацию» — блокировка клиента, поле «Кем создан», привязанные банковские карты и вкладка «История изменений». В коде админ-панели ничего из этого нет: блокировки клиента, масок банковских карт и истории изменений не найдено; сведения о том, кем и когда создана запись, есть у заявок, партнёрских зон и промокодов, но не у клиента. Отсутствие ожидаемо и требованиям не противоречит. \ не найдено за обход (искал по всему репозиторию); shared/types/request.ts:118-120, shared/api/PartnerZonesService.ts:217-219 | — | Подтверждено | Расхождения нет — отсутствие соответствует пометке «на будущую реализацию». При будущей реализации FR3.2.1-8 можно опереться на существующий способ хранения сведений о создателе записи у смежных сущностей. |
Что отрезано на обратном проходе
Из находок «код делает то, чего нет в BRD» в таблицу вошли 3 бизнес-значимые (OQ3.2.1-11, OQ3.2.1-12, OQ3.2.1-13). Отрезано 8 находок уровня плумбинга и инфраструктуры общего назначения — сами по себе они не требуют решения бизнеса или продукта, но учтены в рекомендациях к вопросам выше:
- общие компоненты таблицы, боковой панели, скелета загрузки и полосы ошибки — учтены в OQ3.2.1-10;
- неподключённый механизм передачи хлебных крошек и единственный пример страницы-карточки по адресу — учтены в OQ3.2.1-8;
- жёстко заданная высота таблиц и разнородные пороговые ширины — учтены в OQ3.2.1-9;
- набор статусов заявок и готовые параметры их фильтрации — учтены в OQ3.2.1-3;
- справочник статус-кодов (настроечный словарь, не легенда статусов заказа);
- генератор аватаров-заглушек из букв (используется карточками сфер);
- диалог подтверждения и всплывающие уведомления (пригодятся для FR3.2.1-7 при будущей реализации);
- настройка видимости колонок таблицы (боковая панель настроек отображения).