BRD Mobile 2.7 Заказ успешно создан
Направление работ: Mobile Код раздела: 2.7 Раздел: Поиск > Заказ успешно создан Статус: Готов Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 14.08.26
1. Назначение
Раздел обеспечивает клиенту мобильного приложения подтверждение результата создания заказа и показывает дальнейшие действия.
Клиент видит состояние успешного бронирования или отправленной заявки, сведения об отмене и обработке заказа, а при оплате по инструкции — срок подтверждения и переход к инструкции по внесению предоплаты.
Раздел зависит от процессинга бронирований и заявок, условий оплаты и правил отмены, описанных в связанных Back BRD.
2. Ключевые понятия
Экран «Заказ успешно создан» — экран результата создания заказа, на котором клиент видит подтверждение бронирования или отправки заявки и доступные дальнейшие действия.
Бронирование — форма заказа, при которой выбранное время резервируется за клиентом.
Заявка — предварительная форма заказа для площадки с форматом работы «По заявке», которая ожидает обработки партнером.
Сценарий оплаты — порядок оплаты, определяющий доступные клиенту действия после создания бронирования.
Срок бесплатной отмены — момент, до которого клиент может отменить заказ без начисления сбора.
3. Scope
Входит
S1: Открытие экрана и выбор состояния результата создания заказа
S2: Просмотр результата успешного бронирования
S3: Просмотр результата отправки заявки
S4: Просмотр бронирования с оплатой по инструкции и переход к предоплате
S5: Просмотр блока социальных сетей и переходы в социальные сети сервиса
Не входит
- Mobile: 2.6 Итоговая информация о заказе — проверка данных заказа, выбор способа оплаты и создание заказа.
- Mobile: 4.1.1 Информация о текущем заказе — просмотр созданного заказа в разделе «Заказы».
- Mobile: 4.1.2 Перенос и отмена заказа — изменение и отмена созданного заказа.
- WebLk: 5.4.1 Работа с заявкой и ее преобразование в заказ — обработка заявки партнером.
4. BR
Указаны в пункте 4 разделов Back: 3.2 Процессинг заказов, Back: 3.2.2 Заявки, Back: 2.4.2 Условия оплаты и Back: 2.4.3 Правила отмены.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR2.7-1 | Клиент завершает создание заказа | Интерфейс открывает экран результата и выбирает его состояние по формату работы площадки и сценарию оплаты: успешное бронирование — для моментального бронирования с онлайн-оплатой или оплатой на месте; отправленная заявка — для формата работы «По заявке»; бронирование с предоплатой — для оплаты по инструкции. | 1 | Частично OQ2.7-6 | |
| S2: FR2.7-2 | Клиент просматривает результат моментального бронирования с онлайн-оплатой или оплатой на месте | Интерфейс показывает заголовок «Бронирование успешно выполнено». | 1 | Реализовано OQ2.7-16 | |
| S2: FR2.7-3 | Клиент просматривает условия отмены бронирования | Если бесплатная отмена доступна, интерфейс показывает срок в формате «Бесплатная отмена доступна до {время} {дата}». Если бесплатная отмена недоступна, этот информационный блок не отображается. | 2 | Частично OQ2.7-7 | |
| S2: FR2.7-4 | Клиент просматривает сведения о созданном бронировании | Интерфейс показывает сообщение «Мы оповестили {название партнера} о вашем бронировании», дату, день недели, время начала и окончания, длительность заказа и пояснение «Изменить или отменить свой заказ вы можете в разделе «Заказы»». Просмотр созданного заказа относится к Mobile: 4.1.1 Информация о текущем заказе, изменение и отмена — к Mobile: 4.1.2 Перенос и отмена заказа. | 1 | Частично OQ2.7-8 OQ2.7-9 | |
| S2: FR2.7-5 | Клиент нажимает «Поделиться заказом» | Интерфейс запускает системное действие и передает сообщение: «Привет Через МАРТ ({ссылка на сайт}) за нами забронировано время: {день недели}, {день} {месяц}, {время} {площадка} {объект} {адрес} {метро} {ссылка на видео «Как дойти»} До встречи!». | 1 | Не реализовано OQ2.7-10 | |
| S2: FR2.7-6 | Клиент нажимает «Завершить» | Интерфейс переходит в раздел Mobile: 2.1 Список сфер. | 1 | Реализовано OQ2.7-16 | |
| S3: FR2.7-7 | Клиент просматривает результат создания заказа для площадки с форматом работы «По заявке» | Интерфейс показывает заголовок «Ваша заявка отправлена». | 1 | Не реализовано OQ2.7-11 | |
| S3: FR2.7-8 | Клиент просматривает следующие шаги по заявке | Интерфейс показывает срок рассмотрения заявки партнером из поля «Обработать до», название партнера, сообщение «В ближайшее время с вами свяжутся для согласования деталей заявки и ее подтверждения» и пояснение «Изменить или отменить свой заказ вы можете в разделе «Заказы»». Просмотр заявки относится к Mobile: 4.1.1 Информация о текущем заказе, изменение и отмена — к Mobile: 4.1.2 Перенос и отмена заказа. | 1 | Не реализовано OQ2.7-11 OQ2.7-12 | |
| S3: FR2.7-9 | Клиент нажимает «Позвонить» | Интерфейс инициирует телефонный звонок партнеру по номеру, указанному при создании объекта. | 1 | Частично OQ2.7-13 | |
| S3: FR2.7-10 | Клиент нажимает «Завершить» | Интерфейс переходит в раздел Mobile: 2.1 Список сфер. | 1 | Реализовано OQ2.7-11 OQ2.7-16 | |
| S4: FR2.7-11 | Клиент просматривает бронирование с оплатой по инструкции | Интерфейс показывает заголовок «Бронирование успешно создано». | 1 | Не реализовано OQ2.7-14 | |
| S4: FR2.7-12 | Клиент просматривает условия подтверждения и сведения о бронировании с оплатой по инструкции | Интерфейс показывает срок бесплатной отмены, если она доступна, предупреждение «Внимание! Для подтверждения брони требуется оплата в течение {срок оплаты}», сообщение об уведомлении партнера, дату, день недели, время начала и окончания, длительность заказа и пояснение о возможности изменить или отменить заказ в разделе «Заказы». Срок оплаты берется из настройки WebLk: 3.4.5 Профиль партнера > Настройки правил работы > Параметры оплаты и носит информационный характер: интерфейс не проверяет факт оплаты по инструкции. Просмотр созданного заказа относится к Mobile: 4.1.1 Информация о текущем заказе, изменение и отмена — к Mobile: 4.1.2 Перенос и отмена заказа. | 1 | Не реализовано OQ2.7-14 OQ2.7-9 | |
| S4: FR2.7-13 | Клиент нажимает «Поделиться заказом» | Интерфейс запускает системное действие и передает сообщение: «Привет Через МАРТ ({ссылка на сайт}) за нами забронировано время: {день недели}, {день} {месяц}, {время} {площадка} {объект} {адрес} {метро} {ссылка на видео «Как дойти»} До встречи!». | 1 | Не реализовано OQ2.7-10 | |
| S4: FR2.7-14 | Клиент нажимает «Внести предоплату» | Интерфейс открывает инструкцию по оплате во встроенном браузере. | 1 | Не реализовано OQ2.7-15 | |
| S5: FR2.7-15 | Клиент просматривает блок социальных сетей | Интерфейс показывает текст «Секреты сервиса, подборки площадок, концерты и фестивали — все это в наших соцсетях:» и кнопки VK и Telegram; нажатие открывает соответствующую страницу сервиса во внешнем приложении или браузере. | 1 | Реализовано OQ2.7-17 |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ2.7-1 | Figma / пользовательские правила / Back: 3.2.2 | Какой срок рассмотрения заявки должен отображаться: фиксированный «1 час», показанный в макете, или срок из поля «Обработать до», рассчитанный по дневной или ночной настройке партнерской зоны? | Продукт / Back | Open | Отображается срок из поля «Обработать до». Дневная или ночная настройка, по которой он рассчитан, в этом Front BRD отдельно не описывается. | |
| OQ2.7-2 | Figma / пользовательские правила / Back: 2.4.2, 3.2 | Какой срок оплаты должен отображаться для сценария «По инструкции»: фиксированные «15 минут», показанные в макете, или срок из настройки способа оплаты? С какого момента он отсчитывается и что должно происходить после его истечения? | Продукт / Back | Open | Срок берется из раздела WebLk: 3.4.5 Параметры оплаты и носит информационный характер; мобильное приложение не проверяет факт оплаты по инструкции. | |
| OQ2.7-3 | Figma / пользовательские правила | Кому звонит клиент по кнопке «Позвонить» в состоянии отправленной заявки: партнеру или в поддержку? Какой номер используется? | Продукт | Open | Звонок выполняется партнеру по номеру, указанному при создании объекта. | |
| OQ2.7-5 | Figma | Какие сведения о заказе и в каком формате передаются по кнопке «Поделиться заказом»? | Продукт | Open | Системное действие передает сообщение в формате: «Привет Через МАРТ ({ссылка на сайт}) за нами забронировано время: {день недели}, {день} {месяц}, {время} {площадка} {объект} {адрес} {метро} {ссылка на видео «Как дойти»} До встречи!». | |
| OQ2.7-6 | Код FR2.7-1 | Требование говорит: экран открывается и выбирает одно из трёх состояний по формату работы площадки и сценарию оплаты — успешное бронирование, отправленная заявка, бронирование с предоплатой. В коде экран открывается, но состояние фактически одно. У экрана есть единственный переключатель — булев флаг isAwait, и во всех трёх местах, откуда экран открывается, он передаётся жёстко как false. Сценарий оплаты на выбор состояния не влияет: развилка перед переходом бинарная — «онлайн» (сценарий 2) ведёт через экран оплаты, а «на месте» (0) и «по инструкции» (1) сваливаются в одну и ту же ветку и открывают один и тот же экран с заголовком «Бронирование успешно выполнено». Формат работы площадки в развилке не участвует вовсе. \ order_success/widget/order_success.dart:21 и :53 (единственный флаг состояния), order_result/widget/order_result_screen.dart:531, :700, order_result/widget/payment_webview_screen.dart:244 (везде isAwait: false), order_result/widget/order_result_screen.dart:627-628 (развилка только по «онлайн»), :684-702 (ветка «всё остальное»), partner_zone_service/models/payment_filters_model.dart:35-38 (сценарии 0/1/2) | Разработка | Open | Завести тикет в Bitrix, приоритет высокий: это корневая задача раздела — от неё зависят OQ2.7-11 (состояние «заявка») и OQ2.7-14 (состояние «оплата по инструкции»). Сначала нужно решить продуктовые вопросы OQ2.7-1 и OQ2.7-2, затем заменить булев флаг на явное состояние из трёх значений и завести развилку по формату работы площадки и по сценарию оплаты. | нужно исправлять |
| OQ2.7-7 | Код FR2.7-3 | Требование говорит: блок со сроком бесплатной отмены показывается, только если бесплатная отмена доступна; если недоступна — блока нет. В коде блок показывается всегда. Экран запрашивает заказ и, если бэкенд подтвердил бесплатную отмену, берёт реальный срок; но если бесплатная отмена не разрешена, срока нет или заказ не нашёлся — экран не прячет блок, а показывает тот же текст «Бесплатная отмена доступна до» с датой и временем, которые ему передал предыдущий экран. А предыдущий экран в ветке оплаты «на месте» подставляет туда текущее время (см. OQ2.6-8). То есть клиенту без права бесплатной отмены сообщается, что она у него есть, со сроком «сегодня, минута нажатия кнопки». Формат вывода при этом требованию соответствует: «{ЧЧ:ММ} {д месяц, день недели}». \ order_success/widget/order_success.dart:219-233 (ветка «есть срок» / ветка-фолбэк без условия скрытия), :93-96 (срок берётся только при freeCancellationAllowed), :121-129 (формат), order_result/widget/order_result_screen.dart:687-691 (подстановка текущего времени) | Разработка | Open | Завести тикет в Bitrix, приоритет высокий: скрывать блок, если freeCancellationAllowed не пришёл или равен false, и не показывать фолбэк-дату вообще. Продуктового решения не требуется — правило прямо описано в требовании. Корень подстановки текущего времени общий с OQ2.6-8, но даже после его исправления блок будет показываться не тем клиентам, поэтому задачу нужно делать отдельно. | скрывать блок, если freeCancellationAllowed не пришёл или равен false, и не показывать фолбэк-дату вообще |
| OQ2.7-8 | Код FR2.7-4, FR2.7-8 | Требование говорит: сообщение «Мы оповестили {название партнера} о вашем бронировании». В коде сообщение выводится, но в него подставляется название объекта (комнаты), а не партнёра: во всех трёх точках перехода на экран передаётся room.simpleRoom.name. Название партнёра при этом уже доступно — экран сам загружает заказ, и в загруженной модели есть поле baseName, но экран забирает из неё только срок отмены и телефон. Та же подстановка используется и в тексте заявки — «ваша заявка будет рассмотрена {название объекта}». В результате клиент видит, например, «Мы оповестили Зал №2 о вашем бронировании» вместо названия площадки. \ order_success/widget/order_success.dart:250 (вывод), :216 (то же в тексте заявки), order_result/widget/order_result_screen.dart:527, :678, :696 и payment_webview_screen.dart:240 (передаётся имя комнаты), order_service/model/order_list_model.dart:27 (поле baseName есть в модели), order_success/widget/order_success.dart:89-102 (загруженный заказ используется только частично) | Разработка | Open | Завести тикет в Bitrix, приоритет средний: подставлять baseName из уже загруженного заказа, имя комнаты оставить только там, где требование просит объект. Продуктового решения не требуется — требование называет партнёра явно. Заодно убрать лишний пробел в конце строки «о вашем бронировании ». | подставлять baseName из уже загруженного заказа |
| OQ2.7-9 | Код FR2.7-4, FR2.7-12 | Требование говорит: на экране показываются дата, день недели, время начала и окончания и длительность заказа. В коде этих сведений на экране нет ни в одном состоянии. Экран состоит из заголовка, трёх строк-иконок (срок отмены, уведомление партнёра, «Изменить или отменить…»), блока соцсетей и двух кнопок — блока с датой и временем заказа среди них нет. Дата и время в коде экрана фигурируют только как срок бесплатной отмены, а это другая величина. При этом данные доступны: экран загружает заказ, в котором есть поля начала и окончания (from, to). Пояснение «Изменить или отменить свой заказ вы можете в разделе “Заказы”» выводится, но с прямыми кавычками вместо ёлочек (см. OQ2.7-21). \ order_success/widget/order_success.dart:199-312 (весь состав экрана), :252-259 (пояснение про раздел «Заказы»), order_service/model/order_list_model.dart:35-36 (поля from / to в загружаемом заказе) | Разработка | Open | Завести тикет в Bitrix, приоритет высокий: добавить блок «дата, день недели, время начала и окончания, длительность», собирая его из уже загружаемого заказа. Продуктового решения не требуется. Задача общая для состояний S2 и S4, но в S4 её нельзя закрыть раньше OQ2.7-14. | добавить блок «дата, день недели, время начала и окончания, длительность» |
| OQ2.7-10 | Код FR2.7-5, FR2.7-13 | Требование говорит: на экране есть действие «Поделиться заказом», которое запускает системное действие и передаёт заранее заданное сообщение о брони. В коде такой кнопки на экране нет — внизу экрана только «Позвонить» и «Завершить». Механизм системного «поделиться» в приложении в принципе есть (библиотека share_plus подключена), но используется он в одном-единственном месте — в модальном окне приглашения друга в профиле; к экрану успеха он не подключён, и текста сообщения о брони в коде нет нигде. \ order_success/widget/order_success.dart:317-403 (нижние кнопки экрана: «Позвонить» и «Завершить»), pubspec.yaml:121 (share_plus подключён), profile_page/profile/widget/invite_modal.dart:6 (единственное использование) | Разработка | Open | Завести тикет в Bitrix, приоритет средний: реализовать «Поделиться заказом» в обоих состояниях (S2 и S4). Перед разработкой нужно закрыть OQ2.7-5 — там аналитик уже зафиксировал требуемый формат сообщения; отдельно уточнить у бизнеса, какая именно «ссылка на сайт» и «ссылка на видео “Как дойти”» подставляются, так как в коде их источников нет. | нужно получать эти данные, пока что неоткуда, надо сделать |
| OQ2.7-11 | Код FR2.7-7, FR2.7-8, FR2.7-10 | Требование говорит: для площадки с форматом работы «По заявке» экран показывает заголовок «Ваша заявка отправлена» и следующие шаги по заявке. В коде это состояние недостижимо. Тексты для него написаны и лежат в экране, но включаются флагом isAwait, который во всех точках перехода передаётся как false (см. OQ2.7-6) — то есть это мёртвый код. Заголовок к флагу вообще не привязан: строка «Бронирование успешно выполнено» задана без всякого условия, поэтому даже если флаг когда-нибудь станет true, клиент с заявкой увидит заголовок про бронирование. Глубже: заявку приложение и не умеет создавать — в запросе на создание заказа нет ни поля типа заказа, ни признака заявки, хотя в модели заказа тип request предусмотрен. \ order_success/widget/order_success.dart:206 (заголовок без условия), :215-216 и :248-249 (тексты заявки под флагом), order_result/widget/order_result_screen.dart:531, :700, payment_webview_screen.dart:244 (isAwait: false), order_result/model/create_order_request.dart:11-31 (в запросе создания заказа нет типа/признака заявки), order_service/model/order_list_model.dart:196-199 (тип request в модели существует) | Разработка | Open | Завести тикет в Bitrix, приоритет высокий: сначала подтвердить у бизнеса, поддерживает ли мобильное приложение формат работы «По заявке» на этом релизе. Если да — задача крупнее экрана: нужно уметь создавать заявку (сквозь Mobile 2.6 и бэкенд), затем привязать заголовок к состоянию и оживить ветку. Если нет — снять S3 из scope этого BRD и удалить мёртвые тексты, чтобы они не создавали ложного впечатления готовности. | с заявкой вообще надо много что делать. На Доработку. |
| OQ2.7-12 | Код FR2.7-8 | Требование говорит: показывается срок рассмотрения заявки партнёром из поля «Обработать до». В коде срок захардкожен фразой «В течении 1 часа ваша заявка будет рассмотрена {…}» — ровно тот фиксированный час, про который спрашивает OQ2.7-1. Экран при этом принимает параметр awaitTime со сроком ожидания, но нигде его не читает: параметр объявлен, передаётся из обеих точек перехода строкой 99:99 и молча выбрасывается. Поля «Обработать до» в модели заказа, которую загружает экран, нет вообще — то есть подставить настоящий срок сейчас неоткуда. \ order_success/widget/order_success.dart:216 (захардкоженный «1 час»), :26 и :36 (параметр awaitTime объявлен и ни разу не используется), order_result/widget/order_result_screen.dart:532, payment_webview_screen.dart:245 (передаётся 99:99), order_service/model/order_list_model.dart:20-60 (поля «Обработать до» в модели заказа нет) | Разработка | Open | Завести тикет в Bitrix, приоритет средний, после OQ2.7-1 и OQ2.7-11: добавить поле срока обработки заявки в модель заказа и подставлять его вместо константы, либо убрать неиспользуемый параметр awaitTime и заглушку 99:99, если S3 будет снят из scope. Захардкоженную строку 99:99 в любом случае убрать с боевого пути — она общая с находкой OQ2.6-21. Отдельно поправить «В течении» → «В течение» (см. OQ2.7-21). | ага, исправить |
| OQ2.7-13 | Код FR2.7-9 | Требование говорит: звонок партнёру по номеру, указанному при создании объекта, в состоянии отправленной заявки. В коде кнопка «Позвонить» есть и работает: номер нормализуется (пробелы и скобки убираются, российский номер приводится к +7…), при пустом номере показывается понятное окно «К сожалению партнёр не указал номер телефона». Но расхождения два. Первое: номер берётся из поля basePhone загруженного заказа — это телефон площадки (базы), а не объекта, и в модели заказа отдельного телефона объекта нет. Если заказ загрузить не удалось, подставляется номер, переданный предыдущим экраном, а он там захардкожен строкой +7 (999) 123-45-67 (см. OQ2.6-21) — то есть клиент может позвонить на подставной номер. Второе: кнопка показывается во всех состояниях экрана, в том числе при успешном бронировании, где требование её не предусматривает. \ order_success/widget/order_success.dart:322-380 (кнопка, всегда видима), :328 (_basePhone ?? widget.phoneNum), :99-102 (источник — basePhone заказа), :354-366 (нормализация номера), :331-351 (окно при пустом номере), order_result/widget/order_result_screen.dart:530, :699, payment_webview_screen.dart:243 (захардкоженный номер) | Разработка | Open | Завести тикет в Bitrix, приоритет высокий в части фолбэка: убрать захардкоженный номер, при отсутствии телефона показывать уже готовое окно «партнёр не указал номер телефона». Отдельно спросить бизнес в рамках OQ2.7-3: телефон площадки — это то, что имелось в виду под «номером, указанным при создании объекта», и должна ли кнопка «Позвонить» оставаться в состоянии успешного бронирования, где требование её не описывает. | Вопрос к бизнесую. Телефон площадки и базы это разные вещи? Также подвредить нужна ли кнопка на экране успешного бронирования? |
| OQ2.7-14 | Код FR2.7-11, FR2.7-12 | Требование говорит: для оплаты по инструкции экран показывает заголовок «Бронирование успешно создано» и предупреждение «Внимание! Для подтверждения брони требуется оплата в течение {срок оплаты}». В коде состояния «оплата по инструкции» нет: сценарий 1 (byInstruction) обрабатывается тем же кодом, что и оплата на месте, — клиент видит заголовок «Бронирование успешно выполнено» и обычный экран бронирования. Ни заголовка «Бронирование успешно создано», ни текста «Внимание! Для подтверждения брони требуется оплата…», ни какого-либо срока оплаты в коде экрана нет. Сам сценарий приложению известен и в других местах называется «По инструкции», то есть данных достаточно — не сделана только развилка на этом экране. \ order_success/widget/order_success.dart:206 (единственный заголовок), :199-312 (состав экрана — предупреждения об оплате нет), order_result/widget/order_result_screen.dart:627-628 и :684-702 (сценарий 1 попадает в ветку «на месте»), partner_zone_service/models/payment_filters_model.dart:35-38 (byInstruction(1)), orders_tab/order_room/widget/actullity/payment_type_widget.dart:69-70 (название сценария «По инструкции») | Разработка | Open | Завести тикет в Bitrix, приоритет высокий: делать вместе с OQ2.7-6 и OQ2.7-15 — это один экран-состояние. Перед разработкой закрыть OQ2.7-2: без ответа на вопрос о сроке оплаты предупреждение нечем наполнить. | доработка |
| OQ2.7-15 | Код FR2.7-14 | Требование говорит: по кнопке «Внести предоплату» открывается инструкция по оплате во встроенном браузере. В коде такой кнопки на экране нет. При этом ссылка на инструкцию приходит с бэкенда и лежит в моделях: поле instructionUrl есть и в способе оплаты, и в ответе на создание платежа, а встроенный браузер в приложении реализован и уже используется для онлайн-оплаты. В разделе «Заказы» переход по инструкции тоже не сделан — там на этом месте стоят пометки-FIXME. То есть всё необходимое есть, но экран успеха про предоплату ничего не знает. \ order_success/widget/order_success.dart:317-403 (нижние кнопки: «Внести предоплату» отсутствует), order_result/model/payment_filter.dart:15 и order_result/model/create_order_payment_response.dart:10 (поле instructionUrl), order_result/widget/payment_webview_screen.dart (встроенный браузер), orders_tab/order_room/widget/actullity/buttons_panel_widget.dart:109 и orders_tab/utils/conditions_btns_util.dart:64 (FIXME «Добавить переход по инструкции») | Разработка | Open | Завести тикет в Bitrix, приоритет высокий: добавить кнопку «Внести предоплату» в состоянии S4 и открывать instructionUrl во встроенном браузере. Делать одной задачей с OQ2.7-14. Продуктового решения не требуется, кроме уже заданного OQ2.7-2. | доделать |
| OQ2.7-16 | Код FR2.7-2, FR2.7-6, FR2.7-10 | Что подтверждено: заголовок состояния успешного бронирования и кнопка «Завершить» работают ровно как описано. Заголовок совпадает с требованием дословно — «Бронирование успешно выполнено». Кнопка «Завершить» переводит клиента на экран списка сфер (Mobile: 2.1), заменяя текущий экран, а не добавляя его в стек, так что вернуться назад к экрану успеха нельзя. Дополнительно кнопка отправляет в раздел «Заказы» сигнал обновить список — созданный заказ появится там сразу. Кнопка одна и физически общая для всех состояний экрана, поэтому FR2.7-10 закрывается той же реализацией; оговорка про состояние заявки — в OQ2.7-11. \ order_success/widget/order_success.dart:206 (заголовок), :386-399 (обработчик «Завершить»), :392 (сигнал обновления списка заказов), :396 (переход на SpheresRoute), core/utils/app_router.dart:341 (маршрут списка сфер) | Разработка | Подтверждено | Действий не требуется. | — |
| OQ2.7-17 | Код FR2.7-15 | Что подтверждено: блок социальных сетей реализован полностью и совпадает с требованием. Текст выведен дословно: «Секреты сервиса, подборки площадок, концерты и фестивали — все это в наших соцсетях:». Рядом две кнопки — VK и Telegram; нажатие открывает страницу сервиса во внешнем приложении или браузере, каждое нажатие дополнительно фиксируется в аналитике («Клик вк», «Клик тг»). Оговорка по адресам страниц — в OQ2.7-22. \ order_success/widget/order_success.dart:264-268 (текст), :275-288 (кнопка VK), :291-309 (кнопка Telegram), :279 и :296 (открытие ссылок во внешнем приложении) | Разработка | Подтверждено | Действий не требуется. | — |
| OQ2.7-18 | Код вне BRD | Что нашли: чтобы показать срок бесплатной отмены, экран скачивает весь список заказов клиента и ищет нужный перебором — отдельного запроса «дай заказ по номеру» нет. Сначала запрашивается страница на 100 заказов, и если нужного там не оказалось — повторный запрос уже на 1000. Номера страниц в двух соседних методах одного и того же репозитория при этом заданы по-разному: список заказов запрашивается со страницы 0, а поиск по номеру — со страницы 1, то есть поиск может систематически смотреть не туда, куда думает. Если заказ так и не нашёлся или запрос упал, экран молча остаётся с подставленной датой (см. OQ2.7-7) — ошибка уходит только в консоль. \ orders_tab/data/order_repository.dart:85-98 (первый запрос, pageNumber: 1, pageSize: 100), :118-127 (повторный запрос на 1000), :42-51 (соседний метод, pageNumber: 0), order_success/widget/order_success.dart:107-118 (тихий фолбэк при «не найдено» и при ошибке) | Разработка | Open | Завести тикет в Bitrix, приоритет средний: запросить у бэкенда метод получения одного заказа по номеру и перестать выкачивать список; до этого — привести нумерацию страниц к одному виду. Отдельно решить, что показывать, когда заказ получить не удалось: сейчас клиенту показывается заведомо неверная дата вместо честного отсутствия блока. | нужна новая апи желаетльно |
| OQ2.7-19 | Код вне BRD | Что нашли: все информационные строки экрана жёстко обрезаны двумя строками текста с многоточием — и на узких, и на широких экранах. Под это ограничение попадают самые длинные тексты требований: «В ближайшее время с вами свяжутся для согласования деталей заявки и её подтверждения», «Изменить или отменить свой заказ вы можете в разделе “Заказы”» и сам блок срока отмены, который уже занимает две строки (заголовок + перенос + дата). На типичном телефоне часть этих сообщений клиент увидит обрезанной. \ order_success/widget/order_success.dart:432-433 (широкий экран, maxLines: 2 + многоточие), :453-454 (узкий экран, то же), :249, :258, :221-233 (длинные тексты, попадающие под ограничение) | Разработка | Open | Завести тикет в Bitrix, приоритет средний: снять ограничение в две строки для информационных строк экрана — тексты в требованиях длиннее и обрезаться не должны. Проверить на самом узком поддерживаемом экране. | да, адаптировать |
| OQ2.7-20 | Код вне BRD | Что нашли: экран успеха сбрасывает параметры поиска клиента (дата, время, выбранная опция, выбранное оборудование и услуги) — но не сразу, а через 300 миллисекунд после отрисовки, специальной задержкой, чтобы разойтись с сохранением данных на предыдущем экране. Это гонка: две операции разведены во времени константой, а не порядком выполнения, и если клиент успеет уйти с экрана раньше (например, сразу нажмёт «Завершить»), сброс не произойдёт вовсе — приложение останется со старыми параметрами поиска. Сам сброс в BRD не описан ни как требование, ни как ограничение. Попутно: на боевом пути экрана осталось 14 отладочных печатей в консоль, включая номер заказа и телефон партнёра — тот же приём, что зафиксирован в OQ2.6-24. \ order_success/widget/order_success.dart:60-70 (задержка 300 мс и комментарий о гонке с предыдущим экраном), :131-173 (сам сброс параметров), :81, :90, :94, :100, :332, :367 (отладочная печать с данными заказа и телефоном) | Разработка | Open | Завести тикет в Bitrix, приоритет средний: заменить задержку явной последовательностью — сбрасывать параметры поиска после того, как предыдущий экран завершил сохранение, а не «через 300 мс». Заодно решить с аналитиком, где место этому сбросу: он не описан ни в этом BRD, ни в Mobile 2.6. Отладочную печать с боевого пути убрать. | Реальный колстыле-колхоз (капец это же я и написал?) 100% исправить |
| OQ2.7-21 | Код вне BRD | Что нашли: мелкие расхождения в текстах, которые видит клиент. В тексте заявки написано «В течении 1 часа» — правильно «в течение». В пояснении про раздел заказов используются прямые кавычки — «в разделе “Заказы”», тогда как в требовании стоят ёлочки — «в разделе «Заказы»». В сообщении об уведомлении партнёра остался лишний пробел в конце — «о вашем бронировании ». \ order_success/widget/order_success.dart:216 («В течении»), :258 (прямые кавычки), :250 (лишний пробел) | Разработка | Open | Завести тикет в Bitrix, приоритет низкий (техуборка текстов): привести тексты экрана к формулировкам требований посимвольно. Продуктового решения не требуется. Удобно сделать одной задачей с OQ2.7-8 и OQ2.7-12, которые правят те же строки. | исправить |
| OQ2.7-22 | Код вне BRD | Что нашли: кнопки социальных сетей ведут на страницы musbooking — vk.com/musbooking и t.me/musbooking, адреса зашиты в код экрана. В самом BRD сервис в других местах называется «МАРТ» (например, в тексте «Поделиться заказом», FR2.7-5). Требование FR2.7-15 говорит про «страницу сервиса», не называя её адрес, поэтому подтвердить или опровергнуть соответствие по коду нельзя — нужен ответ бизнеса. \ order_success/widget/order_success.dart:279 (VK), :296 (Telegram) | Бизнес | Open | Подтвердить или уточнить: на какие страницы должны вести кнопки VK и Telegram после ребрендинга — на текущие musbooking или на страницы «МАРТ». Если адреса меняются, стоит завести их в конфигурацию, а не зашивать в экран: сейчас смена ссылки требует релиза приложения. | будут ли меняться ссылки на “MAPT” |
BRD 2.7 v0.1 · booking.mobile.flutter · commit 9db8346/dev · 17.08.26 · якоря
lib/src/feature/order_success/,lib/src/feature/order_result/widget/order_result_screen.dart,lib/src/feature/order_result/widget/payment_webview_screen.dart,lib/src/feature/orders_tab/data/order_repository.dart,lib/src/core/components/repositories/order_service/model/order_list_model.dart,lib/src/core/components/repositories/partner_zone_service/models/payment_filters_model.dartТребований 15: Реализовано 4, Частично 4, Не реализовано 7. Вопросов добавлено 17 (OQ2.7-6…OQ2.7-22): Open разработке 14, Open бизнесу 1, подтверждений 2. Вопросы аналитика OQ2.7-1…OQ2.7-5 оставлены без изменений. Под особым вниманием (вес 1): OQ2.7-6 (состояние экрана не выбирается — реализовано одно состояние из трёх), OQ2.7-11 (состояние «заявка» недостижимо, приложение не умеет создавать заявку), OQ2.7-14 и OQ2.7-15 (состояния «оплата по инструкции» и перехода к предоплате нет вовсе), OQ2.7-10 («Поделиться заказом» не реализовано), OQ2.7-9 (на экране нет даты, времени и длительности заказа), OQ2.7-13 (звонок может уйти на подставной номер). Смежная находка соседнего раздела: OQ2.6-8 — в ветке оплаты «на месте» номер заказа на этот экран не передаётся, из-за чего вместо срока бесплатной отмены подставляется текущее время; здесь этот корень разобран в OQ2.7-7 и OQ2.7-18. Маршрутизация без сверки с гайдбуком (гайдбук не передавался).