BRD Mobile 4.2 Мои заказы > Список архивных заказов
Направление работ: Mobile Код раздела: 4.2 Раздел: Мои заказы > Список архивных заказов Статус: Готов Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 17.08.26
1. Назначение
Раздел обеспечивает клиенту мобильного приложения просмотр истории завершенных и отмененных бронирований, отклоненных заявок и завершенных абонементов.
Клиент просматривает основные сведения и итоговый статус архивной записи, видит начисленные за завершенный заказ М-баллы, переходит к подробной информации или повторяет заказ. Для завершенного заказа клиент также должен иметь возможность перейти к сценарию оценки и отзыва.
Состав архивного списка, конечные состояния заказов и заявок, начисление М-баллов и завершение абонементов определяются системой по правилам связанных Back BRD. Интерфейс отображает полученные данные и доступные для типа записи действия.
2. Ключевые понятия
Экран «Список архивных заказов» — раздел мобильного приложения с активной вкладкой «История», в котором клиент видит завершенные и отмененные заказы, отклоненные заявки и завершенные абонементы.
Архивный заказ — бронирование, которое завершилось оказанием услуги либо было отменено пользователем или партнером.
Отклоненная заявка — заявка, которую партнер отклонил и которая больше не участвует в активном процессе обработки.
Абонемент — процессинговая группа связанных заказов, для которой в архивном списке показываются период, состав, стоимость и состояние оплаты.
М-баллы — баллы программы лояльности, начисляемые клиенту за завершенный заказ по правилам балльной системы.
3. Scope
Входит
S1: Открытие списка архивных заказов и отображение заполненного или пустого состояния
S2: Просмотр карточек завершенных и отмененных бронирований и отклоненных заявок
S3: Просмотр карточек завершенных абонементов
S4: Переходы к информации, повтору заказа, группе заказов и списку текущих заказов
Не входит
- Mobile: 4.1 Список текущих заказов — просмотр активных бронирований, заявок и абонементов.
- Mobile: 4.2.1 Информация об архивном заказе — подробная информация об отдельном завершенном или отмененном заказе либо отклоненной заявке.
- Mobile: 4.2.2 Повтор заказа — создание нового заказа по данным архивного заказа или отклоненной заявки.
- Mobile: 4.2.3 Оценить и оставить отзыв — оценка завершенного заказа и публикация отзыва.
- Mobile: 4.3 Информация о группе заказов — подробная информация о завершенном абонементе и входящих в него заказах.
- Определение конечного состояния заказа, заявки или абонемента и расчет начисленных М-баллов на стороне системы.
4. BR
Указаны в пункте 4 разделов Back: 3.1 Состав заказа, Back: 3.2 Процессинг заказов, Back: 3.2.2 Заявки, Back: 3.3 Группы заказов и Back: 8.4.2 Настройки балльной системы.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR4.2-1 | Клиент открывает вкладку «История» в разделе «Мои заказы» | Интерфейс открывает список архивных заказов и выделяет вкладку «История». | 1 | Реализовано OQ4.2-1, OQ4.2-2, OQ4.2-3 | |
| S1: FR4.2-2 | У клиента есть архивные записи | Интерфейс показывает в одном списке завершенные и отмененные бронирования, отклоненные заявки и завершенные абонементы клиента. Активные записи в список не включаются. | 1 | Частично OQ4.2-4, OQ4.2-5, OQ4.2-6, OQ4.2-7, OQ4.2-8 | |
| S1: FR4.2-3 | У клиента нет архивных записей | Интерфейс показывает заглушку с заголовком «У вас пока нет завершенных заказов» и пояснением «Здесь будут отображаться все ваши завершенные бронирования». | 1 | Реализовано OQ4.2-9, OQ4.2-10 | |
| S2: FR4.2-4 | Клиент просматривает карточку завершенного или отмененного бронирования либо отклоненной заявки | Интерфейс показывает изображение, название партнерской зоны, название площадки или услуги (на будущее), дату, временной интервал, итоговый статус, стоимость и действия «Подробнее» и «Повторить». | 1 | Частично OQ4.2-11, OQ4.2-12, OQ4.2-13, OQ4.2-14 | |
| S2: FR4.2-5 | Бронирование завершено и услуга оказана | Интерфейс показывает пользовательский статус «Завершен». | 1 | Частично OQ4.2-15 | |
| S2: FR4.2-6 | За завершенный заказ начислены М-баллы | Интерфейс показывает строку «Начислено: +{количество}» с обозначением М-баллов. Для отмененного заказа и отклоненной заявки начисление не отображается. | 1 | Не реализовано OQ4.2-16 | |
| S2: FR4.2-7 | Бронирование отменено клиентом или партнером | Интерфейс показывает пользовательский статус «Заказ отменен». | 1 | Частично OQ4.2-15 | |
| S2: FR4.2-8 | Партнер отклонил заявку | Интерфейс показывает пользовательский статус «Заявка отклонена». | 1 | Частично OQ4.2-15 | |
| S3: FR4.2-9 | Все входящие в абонемент заказы завершены | Интерфейс отображает абонемент в списке архивных заказов и показывает изображение и название партнерской зоны, тип «Абонемент», количество входящих заказов, период действия, статус «Завершен» и итоговую стоимость. | 1 | Частично OQ4.2-17, OQ4.2-18 | |
| S3: FR4.2-10 | Клиент просматривает состав завершенного абонемента | Интерфейс показывает блок «Состав» со сгруппированными по объектам названиями площадок, входящих в абонемент. | 2 | Реализовано OQ4.2-19 | |
| S3: FR4.2-11 | Клиент просматривает состояние оплаты завершенного абонемента | Интерфейс показывает суммы «Оплачено» и «К оплате», полученные по входящим заказам. | 1 | Реализовано OQ4.2-20 | |
| S3: FR4.2-12 | Клиент просматривает доступные действия завершенного абонемента | Интерфейс показывает только действие «Подробнее». Действие «Повторить» для абонемента недоступно. | 1 | Реализовано OQ4.2-21, OQ4.2-18 | |
| S4: FR4.2-13 | Клиент нажимает карточку завершенного или отмененного бронирования либо отклоненной заявки или действие «Подробнее» | Интерфейс открывает выбранную запись в разделе Mobile: 4.2.1 Информация об архивном заказе. | 1 | Частично OQ4.2-12 | |
| S4: FR4.2-14 | Клиент нажимает «Повторить» в карточке завершенного или отмененного бронирования либо отклоненной заявки | Интерфейс передает данные выбранной записи и открывает раздел Mobile: 4.2.2 Повтор заказа. | 1 | Частично OQ4.2-22 | |
| S4: FR4.2-15 | Клиент нажимает карточку завершенного абонемента или действие «Подробнее» | Интерфейс открывает выбранный абонемент в разделе Mobile: 4.3 Информация о группе заказов. | 1 | Реализовано OQ4.2-23 | |
| S4: FR4.2-16 | Клиент нажимает вкладку «Текущие» | Интерфейс переходит в раздел Mobile: 4.1 Список текущих заказов. | 1 | Реализовано OQ4.2-24 |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ4.2-1 | Код FR4.2-1 | Что подтверждено: вкладка «История» есть в шапке раздела «Мои заказы», переключение вкладок работает, выбранная вкладка подсвечивается индикатором, а содержимое вкладки — это список архивных записей (тот же список, но с признаком «не текущие»). \ order_screen.dart:31-57 (две вкладки «Текущие»/«История», индикатор), booking_list.dart:67-84 (рендер архивного списка при isCurrent: false) | Бизнес | Подтверждено | Расхождения нет. Нюанс: при входе в раздел всегда открывается «Текущие» — отдельной точки входа сразу в «Историю» в коде нет; если бизнес ожидает такой переход (например, из уведомления о завершении заказа), это нужно заводить отдельным требованием. | |
| OQ4.2-2 | Код FR4.2-1 | Что нашли: «Текущие» и «История» — не самостоятельные экраны, а две вкладки на одном общем состоянии. Оба списка загружаются одним запросом сразу при открытии раздела, на время загрузки обе вкладки показывают одну общую полноэкранную анимацию (не скелетон), а «потянуть, чтобы обновить» в «Текущих» перезагружает и «Историю» тоже, сбрасывая её пролистанные страницы к первой. Практический эффект: клиент, пролиставший архив вглубь, теряет позицию из-за действия на соседней вкладке. \ orders_bloc.dart:296-318 (оба списка одним Future.wait), :173-190 и :296-301 (обновление сбрасывает пагинацию обеих вкладок), booking_list.dart:56-61 (общая полноэкранная анимация загрузки) | Разработка | Open | (А, реком.): развести состояние вкладок — грузить «Историю» при первом открытии вкладки и обновлять только ту вкладку, на которой сделали pull-to-refresh; (Б): если совместная загрузка сделана осознанно ради скорости — как минимум не сбрасывать пагинацию неактивной вкладки и показывать загрузку только на обновляемой вкладке. | развести состояние вкладок — грузить «Историю» при первом открытии вкладки и обновлять только ту вкладку, на которой сделали pull-to-refresh |
| OQ4.2-3 | Код FR4.2-1 | Что нашли: событие первичной загрузки заказов отправляется дважды — один раз при создании блока и ещё раз прямо из метода отрисовки экрана, то есть при каждой перерисовке. Сейчас это не приводит к лишним запросам только потому, что обработчик игнорирует событие в любом состоянии, кроме начального, — то есть защита держится на побочном условии. \ order_screen.dart:25 (диспатч при создании) и :29 (диспатч из build), orders_bloc.dart:287-294 (обработчик срабатывает только в InitOrdersState) | Разработка | Open | Убрать диспатч из build — инициализацию делать один раз при создании блока. Это не влияет на видимое поведение сегодня, но ломается при любом изменении логики обработчика. | Убрать диспатч из build — инициализацию делать один раз при создании блока |
| OQ4.2-4 | Код FR4.2-2 | Требование говорит: архивные бронирования, отклонённые заявки и завершённые абонементы показываются в одном списке. В коде они действительно в одном списке, но порядок внутри страницы фиксированный и не связан с датой: сначала идут все абонементы страницы, затем все заказы; сортировки по дате завершения нет ни на клиенте, ни при склейке подгруженных страниц. Клиент увидит «перемешанный» по датам архив. \ orders_bloc.dart:421-424 (склейка [...абонементы, ...заказы]), :504-506 (та же склейка при подгрузке следующей страницы) | Бизнес | Open | Зафиксировать правило сортировки архива (реком.: по дате завершения, новые сверху, абонементы в общей ленте по дате окончания периода) — и передать его в разработку. Без правила порядок остаётся случайным для пользователя. | Зафиксировать правило сортировки архива |
| OQ4.2-5 | Код FR4.2-2 | Что нашли: размер страницы архива фактически равен 4 записям, при этом в коде списка объявлена константа «размер страницы = 10», которая нигде не используется. Клиент подгружает архив по 4 записи — это много лишних запросов и заметные подгрузки при скролле. \ pagination_data.dart:6 (_PageSize = 4, идёт в начальное состояние :19-25), orders_bloc.dart:14 (_PageSize = 10 — мёртвая константа) | Разработка | Open | Свести к одному значению и согласовать его с продуктом (реком. 10–20 на страницу); мёртвую константу удалить, чтобы она не читалась как действующая настройка. | вести к одному значению и согласовать его с продуктом (реком. 10–20 на страницу) |
| OQ4.2-6 | Код FR4.2-2 | Что нашли: при подгрузке следующей страницы «Истории» новая пагинация строится на основе пагинации «Текущих» (берётся объект пагинации текущих заказов, у него подменяется номер страницы), а результат сохраняется в пагинацию «Истории». Из-за этого «История» наследует общее число страниц и размер страницы чужого списка: архив может перестать подгружаться раньше времени или, наоборот, запрашивать несуществующие страницы. \ orders_bloc.dart:460-464 (state.currentPagination!.copyWith(...) в общем методе подгрузки), :521-527 (результат кладётся в historyPagination) | Разработка | Open | Брать исходную пагинацию по признаку вкладки (isCurrent ? currentPagination : historyPagination), как это уже сделано на входе в подгрузку (:257-258). Это дефект, а не продуктовый выбор — часть архива может быть недоступна клиенту. | Брать исходную пагинацию по признаку вкладки |
| OQ4.2-7 | Код FR4.2-2 | Что нашли: в коде два несовместимых ответа на вопрос «есть ли ещё страницы»: метод-счётчик считает номер страницы < всего страниц, а сохраняемое в состоянии поле — номер страницы < всего страниц − 1 (то есть теряет последнюю страницу). Реальную подгрузку гейтит метод, а поле не читается нигде — оно только записывается. \ orders_bloc.dart:143-147 (метод, используется в :260-262), :436 (поле с другой формулой), поле hasMore нигде не читается | Разработка | Open | Оставить один источник истины: либо удалить неиспользуемое поле, либо перевести гейт подгрузки на него и выровнять формулу. Сейчас поле выглядит рабочим и при первом же рефакторинге «съест» последнюю страницу архива. | Оставить один источник истины |
| OQ4.2-8 | Код FR4.2-2 | Что нашли: обработчики подгрузки страницы приводят состояние к «загруженному» жёстким приведением типа, без проверки. Если клиент доскроллит до конца в момент, когда список перезагружается или находится в состоянии ошибки, обработчик упадёт с ошибкой приведения типа. \ orders_bloc.dart:255 (state as IdleOrdersState в обработчике пагинации), :442 (то же в методе подгрузки) | Разработка | Open | Проверять состояние перед подгрузкой и выходить из обработчика, если список не в загруженном состоянии. | Проверять состояние перед подгрузкой и выходить из обработчика, если список не в загруженном состоянии |
| OQ4.2-9 | Код FR4.2-3 | Что подтверждено: пустое состояние архива реализовано и тексты совпадают с требованием дословно — заголовок «У вас пока нет завершенных заказов» и пояснение «Здесь будут отображаться все ваши завершенные бронирования»; заглушка также позволяет обновить список жестом. \ booking_list.dart:89-103 (условие «список пуст» и тексты :96, :99), :91-93 (обновление из заглушки) | Бизнес | Подтверждено | Расхождения нет. Отдельно см. OQ4.2-10 про то, что текст заглушки не упоминает абонементы и отклонённые заявки. | |
| OQ4.2-10 | Код FR4.2-3 | Требование говорит: в архивном списке живут в том числе отклонённые заявки и завершённые абонементы. В коде текст пустого состояния говорит только про «завершенные заказы» и «завершенные бронирования» — ни заявки, ни абонементы в нём не упомянуты, хотя рендерятся в этом же списке. \ booking_list.dart:96, :99 (тексты), :71-72 (абонементы в том же списке) | Бизнес | Open | Подтвердить или поправить формулировку заглушки (реком.: «Здесь будут отображаться завершённые бронирования, отклонённые заявки и завершённые абонементы»). Правка текстовая, дешёвая. | Подтвердить или поправить формулировку заглушки |
| OQ4.2-11 | Код FR4.2-4 | Требование говорит: карточка показывает название партнёрской зоны и название площадки (или услуги — на будущее). В коде в карточке заказа выводятся название площадки (зала) и название объекта/базы: если название площадки есть — оно заголовок, а объект идёт второй строкой; если названия площадки нет — заголовком становится объект. Названия партнёрской зоны в карточке нет и взять его неоткуда: в модели заказа есть только идентификатор партнёрской зоны, без названия. \ order_tile.dart:230-244 (заголовок/подзаголовок карточки), order_list_model.dart:22-32 (partnerZoneId есть, названия нет) | Бизнес | Open | (А, реком.): если в карточке нужен именно партнёрская зона — требуется её название в ответе бэкенда (сейчас его нет), это отдельная задача на Back; (Б): если фактическая пара «площадка + объект» устраивает — поправить формулировку требования, чтобы тестирование не считало это дефектом. | если в карточке нужен именно партнёрская зона — требуется её название в ответе бэкенда (сейчас его нет), это отдельная задача на Back Вопрос к бизнесу |
| OQ4.2-12 | Код FR4.2-4 + Код FR4.2-13 | Требование говорит: в архивной карточке доступны действия «Подробнее» и «Повторить», и по «Подробнее» (или тапу по карточке) открывается информация об архивном заказе. В коде кнопки «Подробнее» в архивной карточке нет вообще: показываются либо «Оценить» + «Повторить» (если заказ завершился в последние 7 дней и отзыв ещё не оставлен), либо только «Повторить». Переход к информации об архивном заказе работает, но исключительно тапом по карточке. \ conditions_btns_util.dart:214-228 (набор кнопок для архива), order_tile.dart:82-141 (панели «Оценить»/«Повторить»), :205-209 и :36-39 (переход тапом по карточке) | Бизнес | Open | (А, реком.): зафиксировать фактический набор действий архивной карточки в BRD («Оценить»/«Повторить», переход по тапу) — тап по карточке уже покрывает сценарий «Подробнее»; (Б): если кнопка «Подробнее» нужна визуально — это доработка вёрстки карточки (три кнопки в ряд), нужен макет. | |
| OQ4.2-13 | Код FR4.2-4 | Требование говорит: для завершённого заказа клиент должен иметь возможность перейти к оценке и отзыву. В коде окно доступности отзыва задано в двух местах по-разному: в списке архива кнопка «Оценить» показывается, если заказ завершился в последние 7 дней, а на экране самого заказа — 14 дней (значение из конфигурации приложения). То есть на 8-й день кнопка пропадает из списка, но остаётся в карточке заказа. \ conditions_btns_util.dart:214-228 (7 дней в списке), :73-87 вместе с app_config.dart:56 (quantityDaysWhileReviewOrderIsPossible = 14) | Бизнес | Open | Зафиксировать один срок (реком. 14 дней — он вынесен в конфигурацию и совпадает с карточкой заказа) и передать в разработку задачу свести оба места к этому значению. Сам сценарий отзыва — раздел 4.2.3, здесь речь только про доступность действия в списке. | Зафиксировать один срок (реком. 14 дней |
| OQ4.2-14 | Код FR4.2-4 | Что нашли: признак «клиент уже оставил отзыв на этот заказ» хранится только локально на устройстве (в локальном хранилище приложения), потому что API списка заказов такого признака не отдаёт. Последствия: после переустановки приложения, очистки данных или на другом устройстве кнопка «Оценить» снова появится у уже оценённых заказов, а попытка отправить повторный отзыв будет отклонена сервисом. \ reviewed_orders_storage.dart:4-12 (локальный набор id, комментарий про отсутствие признака в API), order_tile.dart:306-309 (карточка спрашивает именно локальное хранилище) | Разработка | Open | Запросить у Back признак «отзыв оставлен» в ответе списка/деталей заказа и перевести кнопку на него, локальное хранилище оставить как кэш до появления поля. | Запросить у Back признак «отзыв оставлен» в ответе списка/деталей заказа и перевести кнопку на него, локальное хранилище оставить как кэш до появления поля. |
| OQ4.2-15 | Код FR4.2-5 + Код FR4.2-7 + Код FR4.2-8 | Требование говорит: пользовательские статусы архивных записей — «Завершен», «Заказ отменен», «Заявка отклонена». В коде используются другие подписи из общего справочника статусов: «Закрыта» вместо «Завершен», «Отменена» вместо «Заказ отменен», «Отклонена» вместо «Заявка отклонена». Сама логика определения статуса корректная (закрыт → закрыта, отменён → отменена, отклонён → отклонена), расходятся только формулировки; для неизвестного статуса показывается «Без статуса». \ status_badges.dart:21-24, :33-34 (маппинг статусов), :114-126 (подписи Закрыта / Отменена / Отклонена / Без статуса) | Бизнес | Open | Подтвердить целевые пользовательские формулировки и передать в разработку правку подписей. Замечание: подписи в справочнике женского рода («Закрыта», «Отменена») — это язык внутренних статусов брони, а не клиентский; вариант из BRD выглядит корректнее. Отдельно решить, что показывать вместо «Без статуса» в клиентском приложении. | Подтвердить целевые пользовательские формулировки и передать в разработку правку подписей. Замечание: подписи в справочнике женского рода («Закрыта», «Отменена») — это язык внутренних статусов брони, а не клиентский; вариант из BRD выглядит корректнее. Отдельно решить, что показывать вместо «Без статуса» в клиентском приложении. |
| OQ4.2-16 | Код FR4.2-6 | Требование говорит: за завершённый заказ в карточке показывается строка «Начислено: +{количество}» с обозначением М-баллов, и она не показывается для отменённых заказов и отклонённых заявок. В коде такой строки нет нигде — ни в архивной карточке, ни в общем виджете карточки заказа; поиск по приложению даёт только экран истории М-баллов в профиле и виджет «Применить баллы» на оформлении заказа (это списание, а не начисление). В модели заказа поле начисленных баллов отсутствует: есть только points — баллы, доступные для оплаты. \ order_tile.dart:180-316 (полный состав карточки — строки начисления нет), order_list_model.dart:55-56 (points — «mpoints доступные для оплаты»), mpoints_widget.dart:39-45 («Применить баллы» — списание, экран заказа) | Разработка | Open | Уточнить у Back, отдаётся ли по завершённому заказу сумма начисленных баллов (в текущем ответе списка её нет). Без поля требование нереализуемо на клиенте — сначала контракт, затем вёрстка строки. | нужно менять бек |
| OQ4.2-17 | Код FR4.2-9 | Требование говорит: завершённый абонемент показывается со статусом «Завершен». В коде у абонемента статуса как такового нет: бэкенд его не отдаёт (в модели абонемента поля статуса нет), и клиент выводит статус из сумм оплаты — получаются «Оплачено», «Частично оплачена», «Ожидает оплаты» или «Резерв». Значение «Завершен»/«Закрыта» для абонемента не может появиться ни при каких данных. Остальной состав карточки абонемента требованию соответствует: изображение и название партнёрской зоны, «Абонемент: N заказов», период, итоговая стоимость. \ status_badges.dart:40-54 (статус выводится из оплат, комментарий «Abonements don’t carry an explicit status field from the backend»), abonement_model.dart:35-49 (поля статуса нет), abonement_tile.dart:78-159 (состав карточки) | Разработка | Open | Запросить у Back состояние процессинговой группы (завершена/активна/отменена) и показывать его как статус абонемента; вычисление из оплат оставить только как запасной вариант. Параллельно бизнесу — подтвердить, что для архивного абонемента ожидается именно «Завершен», а не состояние оплаты. | Нужно менять бэк |
| OQ4.2-18 | Код FR4.2-9 + Код FR4.2-12 | Что нашли: архивный абонемент рисуется тем же элементом, что и активный, — признак вкладки в него не передаётся. Поэтому у завершённого абонемента всё равно показываются блок «К оплате» и строка «Оплатить до: {дата}» с уже прошедшей датой, что для архива выглядит как призыв к действию по закрытой записи. \ booking_list.dart:71-72 (один и тот же элемент для обеих вкладок), abonement_tile.dart:175-195 («Оплачено» / «К оплате»), :199-211 («Оплатить до») | Бизнес | Open | Решить, что показывать в архивном абонементе вместо платёжного блока (реком.: «Оплатить до» скрывать, «К оплате» показывать только при ненулевом остатке). Требование FR4.2-11 про «Оплачено»/«К оплате» при этом сохраняется. | Решить, что показывать в архивном абонементе вместо платёжного блока (реком.: «Оплатить до» скрывать, «К оплате» показывать только при ненулевом остатке). Требование FR4.2-11 про «Оплачено»/«К оплате» при этом сохраняется. |
| OQ4.2-19 | Код FR4.2-10 | Что нашли: заголовок блока состава набран с латинской буквой «C» — в коде строка "Cостав:" (первый символ — латинская C, код U+0043), а не кириллическая «С». Визуально неотличимо, но ломает поиск по тексту, автотесты по подписи и будущую локализацию. \ abonement_tile.dart:330 | Разработка | Open | Заменить первый символ на кириллическую «С». Заодно проверить, нужно ли двоеточие — в требовании блок называется «Состав». | исправить |
| OQ4.2-20 | Код FR4.2-11 | Что подтверждено: в карточке абонемента показываются две суммы — «Оплачено» и «К оплате», обе рассчитываются от данных абонемента, приходящих с бэкенда. \ abonement_tile.dart:175-195 (блоки «Оплачено» / «К оплате»), :54-57 (расчёт сумм) | Бизнес | Подтверждено | Расхождения по составу нет. Нюанс к сведению: «К оплате» считается как итоговая стоимость плюс штраф минус оплачено — то есть в остаток попадает и штраф; если по правилам штраф не должен смешиваться с остатком по абонементу, заведите отдельный вопрос. | |
| OQ4.2-21 | Код FR4.2-12 | Что подтверждено: у карточки абонемента ровно одно действие — «Подробнее»; кнопки «Повторить» для абонемента нет ни в одной ветке кода, набор кнопок для типа «абонемент» жёстко сводится к «Подробнее». \ abonement_tile.dart:215-229 (единственная кнопка «Подробнее»), conditions_btns_util.dart:230-231 (для абонемента — только панель «Подробнее») | Бизнес | Подтверждено | Расхождения нет. Про лишний платёжный блок на этой же карточке — см. OQ4.2-18. | |
| OQ4.2-22 | Код FR4.2-14 | Требование говорит: по «Повторить» интерфейс передаёт данные выбранной записи и открывает сценарий повтора заказа. В коде «Повторить» уводит клиента из раздела «Мои заказы» на вкладку «Поиск» и открывает карточку площадки, передавая только идентификаторы (площадка, объект, сфера, партнёрская зона) и название объекта. Дата, время, длительность, оборудование и прочий состав архивного заказа не переносятся — клиент подбирает слот заново с нуля. \ order_tile.dart:107-122 и :123-141 (обработчики «Повторить»), order_utils.dart:17-34 (переносятся только идентификаторы и baseName), :49-93 (переключение на вкладку поиска и открытие карточки площадки) | Бизнес | Open | Определить, что значит «передаёт данные выбранной записи» для повтора: только площадка (как сейчас) или ещё и предзаполненные дата/время/длительность/оборудование. От ответа зависит объём доработки; детальный сценарий — раздел 4.2.2. Отдельно подтвердить, что уход на вкладку «Поиск» из «Моих заказов» — ожидаемое поведение. | Вопрос к бизнесу. |
| OQ4.2-23 | Код FR4.2-15 | Что подтверждено: и тап по карточке абонемента, и кнопка «Подробнее» ведут в один и тот же экран состава абонемента, куда передаются сам абонемент и рассчитанные суммы. \ abonement_tile.dart:59-66 (тап по карточке) и :220-226 (кнопка) — оба ведут в AbonementCompositionRoute, abonement_composition_page.dart:16-44 | Бизнес | Подтверждено | Расхождения нет. К сведению: заголовок экрана в коде — «Информация об абонементе» (abonement_composition_page.dart:76), в BRD раздел называется «Информация о группе заказов»; если формулировка важна — выровнять. | |
| OQ4.2-24 | Код FR4.2-16 | Что подтверждено: «Текущие» и «История» — вкладки одного экрана, переключение по нажатию на вкладку работает штатно и показывает список текущих заказов. \ order_screen.dart:31-57 (контроллер вкладок, вкладки и их содержимое) | Бизнес | Подтверждено | Расхождения нет. Формально это не «переход в раздел 4.1», а переключение вкладки на том же экране — при желании уточнить формулировку требования. |
Пин-контекст. BRD 4.2 v0.1 · репо
booking.mobile.flutter(Flutter/Dart) · commit9db8346/ веткаdev· дата сверки 17.08.26 · якоря:lib/src/feature/orders_tab/(order_screen.dart,widget/booking_list.dart,widget/tiles/order_tile.dart,widget/tiles/abonement_tile.dart,widget/status_badges.dart,bloc/orders_bloc.dart,utils/conditions_btns_util.dart,data/reviewed_orders_storage.dart), опорные модели:lib/src/core/components/repositories/order_service/model/. Архив — не отдельный экран: это та же вкладочная реализация «Моих заказов» с признаком «не текущие». Сводка. 24 строки: Open разработке — 10 · Open бизнесу — 8 · Подтверждено — 6. Требования: Реализовано — 7, Частично — 8, Не реализовано — 1. Отрезано находок обратного прохода — 4 (см. комментарий ниже). Разделы 4.1, 4.2.1, 4.2.2 и 4.2.3 в сверку не входили. Маршрутизация без сверки с гайдбуком — гайдбук на вход не передавался; продуктовые и спорные вопросы отнесены бизнесу как «подтвердить нечем», технические дефекты — разработке. Статусы и адресаты — предложение агента, требуют валидации человеком.