BRD Widget 5.2 Скидки, комментарий и правила
Направление работ: Widget Код раздела: 5.2 Раздел: Дополнения к заказу и подтверждение > Скидки, комментарий и правила Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 11.08.26
1. Назначение
Раздел описывает блоки скидок, комментария к заказу и согласия с правилами площадки в виджете на шаге оформления.
Клиент выбирает и применяет промокод, оставляет комментарий к заказу и подтверждает согласие с правилами площадки перед бронированием. Применённый промокод учитывается в итоговой стоимости, комментарий передаётся в заказ.
Документ описывает промокоды, комментарий и правила. Списание М-баллов — раздел 4.2; дополнительные позиции — раздел 5.1; итоговая стоимость и расчёт — раздел 4 и Back 4; создание заказа — Back 3.
Раздел зависит от Back: 4.2 Стоимость заказа и позиций и Back: 3.1 Состав заказа.
2. Ключевые понятия
Промокод — скидка, применяемая к заказу; может содержать скидку на время и/или на позиции. Промокоды создаются вне виджета; виджет только получает и применяет их.
Общий промокод — промокод, доступный всем клиентам в рамках партнёрской зоны, объекта или площадки.
Личный промокод — промокод, выданный конкретному клиенту; доступен только после входа в аккаунт.
Комментарий к заказу — свободный текст клиента, который передаётся в создаваемый заказ.
Правила площадки — условия площадки, с которыми клиент соглашается перед бронированием; включают условие отмены заказа.
3. Scope
Входит
S1: Выбор и применение промокода
S2: Ввод комментария к заказу
S3: Согласие с правилами площадки и отображение условия отмены
Не входит
- Widget: 5.1 Дополнения к заказу и подтверждение > Дополнительные позиции к заказу
- Widget: 4.2 Блок данных потенциального заказа > Отображение после входа в аккаунт (списание М-баллов)
- Back: 4.2 backend-логика скидок и стоимости
- Back: 3.1 backend-логика состава заказа
4. BR
Указаны в пункте 4 разделов Back: 4.2 Стоимость заказа и позиций и Back: 3.1 Состав заказа.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: #FR5.2-1 | Клиент открывает выбор промокода | Интерфейс показывает поле выбора промокода с плейсхолдером Промокод; выбор заблокирован, пока не заданы обязательные параметры заказа — площадка, зал, дата и время. | 1 | Реализовано | |
| S1: #FR5.2-2 | Клиент просматривает промокоды | Интерфейс показывает список доступных клиенту промокодов — как общих, так и личных: запрос промокодов передаёт идентификатор клиента, поэтому после входа в список попадают персональные промокоды, а без входа — только общие. Каждый вариант выводит название Промокод: {название} и, при наличии, скидку Время и Позиции; показывает состояние загрузки и пустое состояние Нет доступных промокодов. | 2 | Реализовано по коду — требуется перепроверка QA на тестовых промокодах, см. OQ5.2-3 | |
| S1: #FR5.2-8 | Промокоды запрашиваются без входа | Для неавторизованного клиента интерфейс запрашивает промокоды без идентификатора клиента и без подстановки вымышленного идентификатора аккаунта; в результате возвращаются только общие промокоды. | 2 | Не реализовано — подставляется 10000000-0000-0000-0000-000000000000, см. OQ5.2-4 | |
| S1: #FR5.2-3 | Клиент применяет промокод | Интерфейс позволяет выбрать промокод и применить его действием Применить; после применения действие показывает Применен, повторное применение того же промокода недоступно, применённый промокод учитывается в расчёте стоимости. | 1 | Реализовано по коду — требуется перепроверка QA на тестовых промокодах, см. OQ5.2-3 | |
| S2: #FR5.2-4 | Клиент вводит комментарий | Интерфейс принимает комментарий в поле с плейсхолдером Добавьте свой комментарий и передаёт введённый текст в создаваемый заказ. | 1 | Реализовано | |
| S3: #FR5.2-5 | Клиент видит правила и условие отмены | Интерфейс показывает условие отмены Бесплатная отмена доступна в приложении и чекбокс согласия С правилами площадки соглашаюсь со ссылкой на правила площадки. | 1 | Реализовано | |
| S3: #FR5.2-6 | Клиент открывает правила площадки | Интерфейс позволяет открыть правила площадки по ссылке в тексте согласия. Текст правил приходит из отдельного API правовых документов и не хранится в виджете. | 2 | Не реализовано — обработчик показа правил помечен TODO, см. OQ5.2-1 | |
| S3: #FR5.2-7 | Клиент не отметил согласие | Интерфейс не позволяет забронировать, пока чекбокс согласия с правилами не отмечен; согласие обязательно для создания заказа. | 1 | Не реализовано — бронирование не блокируется при снятом чекбоксе, см. OQ5.2-2 |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|---|---|---|---|
| #OQ5.2-1 | Код | Ссылка правила в согласии не открывает правила площадки: обработчик показа правил не реализован (в коде помечен TODO). Подтвердить источник и способ показа правил площадки. Решение: источник — отдельный API-эндпоинт правовых документов; виджет запрашивает текст правил оттуда и показывает по ссылке в согласии, собственных копий текста не хранит. Требуется уточнить у бэкенда контракт эндпоинта: как запрашивается документ и есть ли привязка к конкретной площадке или партнёру. \ features/order-rules/ui/OrderRules.vue:21, widgets/booking/steps/StepCheckout.vue:99-101 | Разработка | Закрыт |
| #OQ5.2-2 | Figma / продукт | Должно ли согласие с правилами быть обязательным для бронирования: в коде бронирование не блокируется при снятом чекбоксе (agreedToRules не проверяется перед созданием заказа). \ widgets/booking/ui/OrderBaseForm.vue:88, widgets/order-form/model/useOrderFormStore.ts:255-294 Решение: согласие обязательно — без отмеченного чекбокса бронирование недоступно. Требование зафиксировано в FR5.2-7. | Бизнес | Закрыт |
| #OQ5.2-3 | QA / код | Что уточнено: промокоды создаются вне виджета, виджет должен получать и общие, и личные. В коде запрос промокодов уже передаёт clientId вместе с партнёрской зоной, объектом, залом и датами — то есть разделение общих и личных выполняет бэкенд по идентификатору клиента, отдельной логики в виджете нет. Ранее QA пометил FR5.2-1/2/3 как заблокированные из-за отсутствия тестового промокода — это ограничение стенда, а не дефект виджета. Требуется перепроверка QA на тестовых промокодах: общий без входа и личный после входа. \ entities/promocode/model/usePromocodeEntityQueries.ts, widgets/order-form/model/useOrderFormStore.ts:202-210 | Разработка | Закрыт |
| #OQ5.2-4 | Код вне BRD | Что нашли: если клиент не авторизован, запрос промокодов уходит не под его аккаунтом, а под захардкоженным запасным идентификатором 10000000-0000-0000-0000-000000000000. Подтвердить, что это ожидаемое поведение для анонимного клиента и что общий список промокодов при этом корректен. Решение: это не ожидаемое поведение — заглушку убрать. Для неавторизованного клиента запрос промокодов выполняется без подстановки вымышленного идентификатора аккаунта; сервер сам определяет, что клиента нет, и отдает только общие промокоды. Требование зафиксировано в FR5.2-8. Тот же класс дефекта, что нулевой cityId в подборе слотов (Widget: 8.7.1) — проверить, нет ли других мест с подставными идентификаторами. \ entities/promocode/model/usePromocodeEntityQueries.ts | Разработка | Закрыт |