Направление работ: Back
Код раздела: 3.3.1 Заказы > Группы заказов > Процессинговые группы заказов
Статус: Готов
Ответственный: Панкова Л.А.
Версия: 0.1
Обновлено: 14.08.26
1. Назначение
Процессинговые группы заказов позволяют работать с абонементами и применять групповые правила к заказам на разных этапах процессинга.
Система управляет доступностью функционала, созданием, подтверждением, оплатой, продлением и отменой абонемента.
Параметры отдельных заказов и базовая модель группы остаются ответственностью родительских разделов.
2. Ключевые понятия
Процессинговая группа заказов (Абонемент) — тип группы заказов, который позволяет работать внутри группы с заказами во всех статусах, влиять на их процессинг и совершать групповые операции.
Создание абонемента — процесс, в результате которого создается группа заказов с типом «Процессинговый».
Подтверждение абонемента — процесс, в результате которого у группы заполняется дата подтверждения и процессинговая группа заказов считается подтвержденной.
Оплата абонемента — процесс проведения платежей по группе заказов в соответствии с правилами Back: 5 Платежи.
Отмена абонемента — процесс отмены или архивации всех заказов группы в зависимости от их статуса в Back: 3.2 Процессинг заказов.
Продление абонемента — процесс, при котором на основании параметров продляемой группы, называемой родительской, на следующий период за ее границами дат создается группа-дубликат, называемая дочерней, с заказами в статусе «Предзаказ».
Настройки абонементов — параметры процессинговых групп, которые появляются в Back: 2.8 Настройки партнерской зоны после активации функционала через тариф.
3. Scope
Входит
S1 Доступ и создание: тарифный доступ, влияние группы на горизонт бронирования и создание абонемента.
S2 Настройки абонементов: границы дат, условия создания, скидки, правила отмены и сервисные абонементы.
S3 Подтверждение: срок, порядок, условия и результат подтверждения абонемента.
S4 Оплата: срок полной оплаты, порядок платежей, условия и результат оплаты абонемента.
S5 Продление: порядок, условия и создание дочерней группы на следующий период.
S6 Отмена: условия отмены абонемента и обработка входящих заказов.
Не входит
- Back: 1.3 Клиенты, Back: 3.3 Группы заказов, Back: 3.1 Состав заказа и Back: 3.2 Процессинг заказов — клиенты, модель группы, состав и жизненный цикл отдельных заказов
- Back: 1.4.2 Расширение партнерских прав доступа через тарифы, Back: 2.8 Настройки партнерской зоны и Back: 8.3.1 Доступ и комиссия — управление правами, тарифами и значениями настроек
- Back: 2.1 Объекты партнеров, Back: 2.2 Площадки партнеров и Back: 8.2.1 Сферы и Опции — управление связанными объектами, площадками и сферами деятельности
- Back: 2.4.1 Условия создания, Back: 2.4.2 Условия оплаты, Back: 2.4.3 Правила отмены и Back: 2.7.1 Акции и промокоды — управление применяемыми правилами и скидками
- Back: 4.2.1 Расчет в группах заказов, Back: 5 Платежи и Back: 5.4 Платежные документы — расчет стоимости, проведение платежей и формирование платежных документов
- WebLk: 3.4.8 Работа с абонементами, WebLk: 5.5 Абонементы и Mobile: 4.3 Информация о группе заказов — настройка и интерфейсные сценарии работы с абонементами
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе.
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR3.3.1-1 | Функционал процессинговых групп должен быть доступен только в партнерской зоне, где тариф доступа и комиссии расширяет зону доступа партнера | Активация тарифа из Back: 8.3.1 Доступ и комиссия должна включать права на процессинговые группы по Back: 1.4.2 Расширение партнерских прав доступа через тарифы. После активации в Back: 2.8 Настройки партнерской зоны появляется перечень параметров абонементов. | Бизнес | 1 | Частично — OQ3.3.1-9 |
| S1: BR3.3.1-2 | Процессинговая группа должна позволять работать с заказами во всех статусах, влиять на их процессинг и совершать групповые операции | Доступные операции: создание, подтверждение, оплата, отмена и продление абонемента. Базовая модель группы раскрывается в Back: 3.3 Группы заказов, статусы заказов — в Back: 3.2 Процессинг заказов. | Бизнес | 1 | Частично — OQ3.3.1-10 |
| S1: BR3.3.1-3 | Заказы, создаваемые в процессинговой группе, должны игнорировать срок бронирования, заданный сферой деятельности, и расширять его до границ дат группы | Срок бронирования задается сферой из Back: 8.2.1 Сферы и Опции, границы дат хранятся по Back: 3.3 Группы заказов. | Системное | 3 | — OQ3.3.1-8 |
| S1: BR3.3.1-4 | Создание абонемента должно завершаться созданием группы заказов с типом «Процессинговый» | Определение операции приведено в разделе 2 «Ключевые понятия». Параметры и типы создаваемой группы определяются в Back: 3.3 Группы заказов. | Системное | 1 | Реализовано — OQ3.3.1-12 |
| S2: BR3.3.1-5 | Тип границ дат должен определять максимальные и минимальные значения границ отдельной процессинговой группы в партнерской зоне | Допустимые значения: - любые даты — значение по умолчанию, которое допускает любые границы в пределах максимальной длительности группы из Back: 2.8 Настройки партнерской зоны; - значение дней — задает максимально допустимый период между границами в пределах максимальной длительности группы; - в пределах календарного месяца — допускает период между границами в пределах одного календарного месяца. Сами границы дат хранятся по Back: 3.3 Группы заказов. | Бизнес | 3 | Не реализовано — OQ3.3.1-5 |
| S2: BR3.3.1-6 | Настройки партнерской зоны должны хранить список условий создания, проверяемых при создании заказов в процессинговых группах (после релиза реализация) | Если специальные условия для групп не заданы, используются стандартные условия из Back: 2.4.1 Условия создания. Управление списком относится к Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-5 |
| S2: BR3.3.1-7 | Настройки партнерской зоны должны хранить список скидок, действующих на заказы в процессинговых группах (после релиза реализация) | Состав списка: - акции — автоматические скидки, действующие на заказы группы; - промокоды — ручные скидки, доступные для привязки к заказам группы. Управление скидками раскрывается в Back: 2.7.1 Акции и промокоды, хранение настройки — в Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-5 |
| S2: BR3.3.1-8 | Настройки партнерской зоны должны хранить список правил отмены, действующих при отмене заказов в процессинговых группах (после релиза реализация) | Если специальные правила для групп не заданы, используются стандартные правила из Back: 2.4.3 Правила отмены. Управление списком относится к Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-5 |
| S2: BR3.3.1-9 | Настройки партнерской зоны должны позволять активировать сервисные абонементы и ограничивать их разрешенными объектами и площадками (после релиза реализация) | Состав настройки: - глобальные абонементы — параметр, активирующий создание заказов в партнерской зоне по сервисным абонементам; - разрешенные объекты — объекты из Back: 2.1 Объекты партнеров, на которых разрешено создание таких заказов; - разрешенные площадки — площадки из Back: 2.2 Площадки партнеров, на которых разрешено создание таких заказов. Значения параметров хранятся в Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-5 |
| S3: BR3.3.1-10 | Срок подтверждения должен определять количество дней с момента создания группы, по истечении которых выполняется отмена абонемента | Если срок в Back: 2.8 Настройки партнерской зоны не указан, подтверждение не требуется и все абонементы партнерской зоны создаются подтвержденными без заполнения даты подтверждения из Back: 3.3 Группы заказов. | Бизнес | 3 | Не реализовано — OQ3.3.1-3 |
| S3: BR3.3.1-11 | По умолчанию подтверждение абонемента должно выполняться вручную без проверки условий подтверждения | Порядок подтверждения определяет сценарий выполнения операции и настраивается в Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-3 |
| S3: BR3.3.1-12 | Подтверждение абонемента должно выполняться вручную при соблюдении условий подтверждения (после релиза реализация) | Условия подтверждения перечислены в BR3.3.1-14. | Бизнес | 3 | Не реализовано — OQ3.3.1-3 |
| S3: BR3.3.1-13 | Система должна автоматически выполнять подтверждение абонемента при соблюдении условий подтверждения (после релиза реализация) | Условия подтверждения перечислены в BR3.3.1-14. | Системное | 3 | Не реализовано — OQ3.3.1-3 |
| S3: BR3.3.1-14 | Настройки партнерской зоны должны позволять выбирать условия активации подтверждения абонемента (после релиза реализация) | Допустимые условия: - частичное резервирование — указанное количество заказов группы переведено в статус «Резерв» по Back: 3.2 Процессинг заказов; - полное резервирование — все заказы группы переведены в статус «Резерв»; - полное резервирование и предоплата — все заказы группы переведены в статус «Резерв» и внесена предоплата, указанная в Back: 2.4.2 Условия оплаты; - полная оплата — сумма оплат равна итоговой стоимости группы из Back: 3.3 Группы заказов, рассчитываемой по Back: 4.2.1 Расчет в группах заказов. Выбранные условия хранятся в Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-3 |
| S3: BR3.3.1-15 | Подтверждение абонемента должно заполнять дату подтверждения группы, после чего процессинговая группа заказов считается подтвержденной | Определение операции приведено в разделе 2 «Ключевые понятия». Операция становится доступна в соответствии с выбранным порядком подтверждения и, если он их использует, условиями подтверждения. После подтверждения система устанавливает срок до полной оплаты. Дата подтверждения и поле «Оплатить до» хранятся по Back: 3.3 Группы заказов, срок полной оплаты задается в Back: 2.8 Настройки партнерской зоны. | Системное | 3 | Не реализовано — OQ3.3.1-3 |
| S4: BR3.3.1-16 | Срок до полной оплаты должен определять количество дней с момента подтверждения абонемента, по истечении которых отменяются заказы без проведенных оплат в статусе «Резерв» | Статус и отмена заказов раскрываются в Back: 3.2 Процессинг заказов, дата «Оплатить до» хранится по Back: 3.3 Группы заказов, значение срока задается в Back: 2.8 Настройки партнерской зоны. | Бизнес | 1 | Не реализовано — OQ3.3.1-3 |
| S4: BR3.3.1-17 | По умолчанию проведение платежей по абонементу должно быть доступно только с привязкой к конкретному заказу группы | После оплаты система создает несколько платежных документов по Back: 5.4 Платежные документы и связывает каждый документ с соответствующим заказом. Формат проведения платежей определяется порядком оплаты из Back: 5 Платежи, выбранным в Back: 2.8 Настройки партнерской зоны. | Бизнес | 1 | Не реализовано — OQ3.3.1-6 |
| S4: BR3.3.1-18 | Проведение платежей по абонементу должно поддерживать привязку к группе заказов (после релиза реализация) | После оплаты система создает платежные документы по Back: 5.4 Платежные документы и связывает их с группой заказов из Back: 3.3 Группы заказов. | Бизнес | 3 | Частично — OQ3.3.1-6 |
| S4: BR3.3.1-19 | Оплата абонемента должна проводить платежи по группе заказов при наличии неоплаченных заказов и на основании условий оплаты группы | Определение операции приведено в разделе 2 «Ключевые понятия». Условия оплаты группы — список условий из Back: 2.4.2 Условия оплаты, добавленных в Back: 2.8 Настройки партнерской зоны и используемых для платежей по Back: 5 Платежи. Если размер предоплаты меньше 100%, стоимость рассчитывается по Back: 4.2.1 Расчет в группах заказов в зависимости от порядка оплаты. После платежа система создает платежные документы по Back: 5.4 Платежные документы в соответствии с выбранным порядком. | Бизнес | 3 | Частично — OQ3.3.1-7 |
| S5: BR3.3.1-20 | По умолчанию продление абонемента должно выполняться вручную без проверки условий продления | Порядок продления определяет сценарий выполнения операции и настраивается в Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-4 |
| S5: BR3.3.1-21 | Продление абонемента должно выполняться вручную при соблюдении условий продления (после релиза реализация) | Условия продления перечислены в BR3.3.1-23, BR3.3.1-24 и BR3.3.1-25. | Бизнес | 3 | Не реализовано — OQ3.3.1-4 |
| S5: BR3.3.1-22 | Система должна автоматически выполнять продление абонемента при соблюдении условий продления (после релиза реализация) | Условия продления перечислены в BR3.3.1-23, BR3.3.1-24 и BR3.3.1-25. | Системное | 3 | Не реализовано — OQ3.3.1-4 |
| S5: BR3.3.1-23 | Продление абонемента должно становиться доступно после выполнения операции подтверждения абонемента | Подтверждение раскрывается в BR3.3.1-15. | Бизнес | 3 | Не реализовано — OQ3.3.1-3, OQ3.3.1-4 |
| S5: BR3.3.1-24 | Продление абонемента должно поддерживать условия подтверждения с частичной или полной оплатой (после релиза реализация) | Допустимые условия: - после подтверждения и частичной оплаты — абонемент подтвержден и внесена предоплата из Back: 2.4.2 Условия оплаты; - после подтверждения и полной оплаты — абонемент подтвержден и сумма оплат равна итоговой стоимости группы из Back: 3.3 Группы заказов, рассчитываемой по Back: 4.2.1 Расчет в группах заказов. | Бизнес | 3 | Не реализовано — OQ3.3.1-4 |
| S5: BR3.3.1-25 | Продление абонемента должно становиться доступно по наступлении настроенной даты (после релиза реализация) | Способы расчета даты: - количество дней от начальной даты группы — значение дней от начальной даты в границах группы; - количество дней до конца границ дат — значение дней до конечной даты в границах группы. Границы дат хранятся по Back: 3.3 Группы заказов, способ расчета выбирается в Back: 2.8 Настройки партнерской зоны. | Бизнес | 3 | Не реализовано — OQ3.3.1-4 |
| S5: BR3.3.1-26 | Продление абонемента должно создавать по параметрам родительской группы дочернюю группу-дубликат на следующий период за границами дат родительской группы с заказами в статусе «Предзаказ» | Определение операции приведено в разделе 2 «Ключевые понятия». Правила создания: - дочерняя группа создается на того же клиента; - для типов границ «Любые даты» и «Значение дней» начальная дата дочерней группы равна конечной дате родительской группы плюс один день, а конечная дата равна начальной дате дочерней группы плюс количество дней в границах родительской группы; - для типа «В пределах календарного месяца» используются первый и последний дни следующего календарного месяца; - система анализирует серии из Back: 3.3 Группы заказов, создает в дочерней группе заказы в статусе «Предзаказ» по Back: 3.2 Процессинг заказов и объединяет их в серии; - поле «Подтвердить до» устанавливается по сроку подтверждения из Back: 2.8 Настройки партнерской зоны. | Системное | 3 | Не реализовано — OQ3.3.1-4 |
| S6: BR3.3.1-27 | Отмена абонемента должна выполнять отмену или архивацию всех заказов группы в зависимости от их статуса | Определение операции приведено в разделе 2 «Ключевые понятия». Операция доступна только при отсутствии в группе оплаченных заказов и заказов в статусе «Закрыто». Система отменяет заказы в статусе «Резерв» и архивирует заказы в статусе «Предзаказ» по Back: 3.2 Процессинг заказов. | Системное | 1 | Частично — OQ3.3.1-1, OQ3.3.1-2 |
5. Открытые вопросы
Сверка с кодом: BRD 3.3.1 v0.1 · репозиторий
booking-monorepo· commit92603c64/main· 28.08.26 · якорьsrc/services/booking.orders(Orders.Domain/ProcessingGroupAggregate,Orders.Application/{Commands,Queries}/ProcessingGroup,Orders.Persistence— конфигурация/репозиторий/маппингProcessingOrderGroup); cross-layer обход —booking.abac(права доступа),booking.partner-management(настройки партнёрской зоны),booking.notifications(события), плюс полнотекстовый поиск по всемуbooking-monorepo(horizon/подтверждение/продление/DateRangeType и т.п.)Сводка: 12 вопросов (Open 11 · Подтверждено 1)
Маршрутизация без сверки с гайдбуком (гайдбук не передавался).
Оговорка по обходу: разделы «не входит» по Scope BRD (8.3.1, 1.4.2, 2.8, 5.4, 3.3, 2.4.1–2.4.3, 2.7.1) не проверялись по существу — только там, где на них прямо ссылаются требования 3.3.1 (см. OQ3.3.1-5, OQ3.3.1-9). Находка обратного прохода — одна (OQ3.3.1-11), не срезана.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ3.3.1-1 | Код BR3.3.1-27 | Проблема: условие, при котором абонемент разрешено архивировать («снять»), выглядит перевёрнутым относительно того, что показывает пользователю карточка абонемента. При получении абонемента признак «можно архивировать» истинный, когда ВСЕ заказы группы ещё в статусе «Предзаказ». А при самой попытке архивации система, наоборот, выдаёт ошибку «есть заказы не в предрезерве» именно тогда, когда все заказы группы в «Предзаказе» — то есть блокирует ровно тот случай, который экран показывает как разрешённый, и пропускает архивацию, когда в группе уже есть заказы в других статусах. Судя по тексту ошибки, задумано было наоборот. \ Orders.Application/Queries/ProcessingGroup/GetProcessingGroup/GetProcessingGroupQuery.cs:130; Orders.Application/Commands/ProcessingGroup/Update/UpdateProcessingGroupCommandHandler.cs:28-34; Orders.Persistence/Repositories/ProcessingOrderGroupRepository.cs:69-75 | Разработка | Open | Завести тикет в Bitrix: свести признак «можно архивировать» на экране и проверку при архивации к одному правилу. По тексту ошибки похоже, что верное правило — «архивировать можно, только если ВСЕ заказы ещё в „Предзаказе“», а не наоборот, но перед фиксом стоит уточнить у автора кода намерение. | ОТ БИЗНЕСА: Привести экранный признак и проверку при архивации к одному правилу. Вес 1 |
| OQ3.3.1-2 | Код BR3.3.1-27 | Требование говорит: отмена абонемента должна сама отменять заказы группы в статусе «Резерв» и архивировать заказы в статусе «Предзаказ», а доступна операция только когда в группе нет ни одного оплаченного заказа и ни одного заказа в статусе «Закрыто». В коде отдельной операции «отмена абонемента» нет — есть только обновление абонемента с флагом архивности (в правах доступа она так и называется — «снятие абонемента»), и она лишь переключает флаг архивности у самой группы. Ни один заказ группы при этом не отменяется и не архивируется, а проверка перед архивацией смотрит только на статус «Предзаказ» — про оплаченные заказы и заказы в статусе «Закрыто» в коде упоминаний нет. \ Orders.Application/Commands/ProcessingGroup/Update/UpdateProcessingGroupCommandHandler.cs:17-46 (нет обращений к заказам группы); Orders.Domain/ProcessingGroupAggregate/ProcessingOrderGroup.cs:141-156 (метод Update меняет только комментарий, признак архивности и дату оплаты) | Разработка | Open | (А) доreализовать каскадную отмену «Резерва» и архивацию «Предзаказа» по заказам группы плюс проверку на оплаченные/закрытые заказы, как в требовании — рекомендуется: требование весом 1 и не помечено как отложенное; (Б) если каскадное поведение бизнесу больше не нужно — скорректировать формулировку BRD. Связать с OQ3.3.1-1 — исправление бага в проверке является предпосылкой для этой доработки. | ОТ БИЗНЕСА: А - Реализовать каскадную отмену/архивацию по заказам и проверку на оплаченные/закрытые заказы. Вес 1 |
| OQ3.3.1-3 | Код BR3.3.1-10, BR3.3.1-11, BR3.3.1-12, BR3.3.1-13, BR3.3.1-14, BR3.3.1-15, BR3.3.1-16, BR3.3.1-23 | Требование говорит: у абонемента должен быть срок подтверждения (дней от создания), по умолчанию подтверждение — ручное действие без проверки условий; в результате подтверждения заполняется дата подтверждения, после чего стартует отдельный срок до полной оплаты, по истечении которого неоплаченные заказы в «Резерве» отменяются; продление абонемента становится доступно только после подтверждения. Ни один из этих пунктов не помечен в BRD как «после релиза» — то есть по документу это уже текущее, базовое поведение (кроме самого списка условий подтверждения — он прямо помечен «после релиза»). В коде во всём бэкенде (проверено не только в этом разделе, а по всему репозиторию) нет ни поля вроде даты подтверждения, ни операции подтверждения абонемента, ни настройки срока подтверждения или срока полной оплаты, ни фоновой задачи, которая отменяла бы неоплаченные заказы по истечении срока — единственная похожая задача в сервисе относится к заявкам, а не к абонементам. Единственное поле с датой на группе — дата оплаты, но она заполняется при создании абонемента датой самого раннего заказа серии, а не в момент подтверждения и не по настройке срока. \ поиск признаков подтверждения (по названиям полей и по-русски) по всему репозиторию — совпадений в контексте абонементов нет; агрегат группы целиком — Orders.Domain/ProcessingGroupAggregate/ProcessingOrderGroup.cs:1-157; заполнение даты оплаты при создании — Orders.Application/Commands/ProcessingGroup/Create/CreateProcessingGroupOrSubGroupCommandHandler.cs:210-216; единственная фоновая задача сервиса заказов — Orders.Infrastructure/Jobs/AutoRequestCancellingJob.cs (про заявки, не про абонементы) | Бизнес | Closed | (А) подтвердить, что весь блок подтверждения абонемента (срок, ручной порядок, дата подтверждения, вытекающий срок полной оплаты и автоотмена) на самом деле относится к будущей доработке, и поправить BRD — явно пометить BR3.3.1-10, 11, 15, 16, 23 как «после релиза», как уже сделано для BR3.3.1-12–14 — рекомендуется, поскольку в коде нет ни одной части механизма; (Б) если это ожидалось в текущем релизе — завести отдельный эпик, объём большой (поле, операция, настройки, фоновая задача). Затрагивает 8 из 27 требований раздела. | ОТ БИЗНЕСА: Функционал подтверждения не входит в релиз, Вес требований 10,11 и 15 изменен, вопрос закрываю. |
| OQ3.3.1-4 | Код BR3.3.1-20, BR3.3.1-21, BR3.3.1-22, BR3.3.1-23, BR3.3.1-24, BR3.3.1-25, BR3.3.1-26 | Требование говорит: продление абонемента — отдельная операция, которая по параметрам «родительской» группы создаёт новую «дочернюю» группу-дубликат на следующий период, с заказами в статусе «Предзаказ»; по умолчанию она запускается вручную без проверки условий, а доступна становится только после подтверждения абонемента. В коде такой операции нет вовсе — ни ручной, ни автоматической. Единственное похожее по смыслу поведение — расширение границ дат у той же самой группы, когда через операцию создания в неё добавляют ещё один заказ; но это другой механизм — он растягивает старую группу, а не создаёт дубликат на следующий период. Поиск по всему бэкенду слов «продление», «дочерняя/родительская группа» и «серии» рядом с абонементами тоже ничего не нашёл. \ расширение границ дат существующей группы — Orders.Domain/ProcessingGroupAggregate/ProcessingOrderGroup.cs:132-139 (ExtendDateRangeTo), вызов — Orders.Application/Commands/ProcessingGroup/Create/CreateProcessingGroupOrSubGroupCommandHandler.cs:418; операций продления в Orders.Application/Commands/ProcessingGroup/ нет — там только создание, обновление, расчёт и пересчёт статистики | Бизнес | Closed | (А) подтвердить, что продление абонемента (BR3.3.1-20, 23, 26 — вес 1, не помечены «после релиза») на самом деле ещё не запланировано к текущему релизу, и поправить пометку в BRD — рекомендуется по тому же основанию, что и OQ3.3.1-3: механизма нет вообще, ни частично; (Б) если продление должно быть в текущем релизе — завести эпик на отдельную операцию создания дочерней группы. Связано с OQ3.3.1-3: BR3.3.1-23 требует, чтобы продление становилось доступно «после подтверждения», а подтверждения тоже нет — проектировать оба механизма нужно вместе. | ОТ БИЗНЕСА: Функционал продления не входит в релиз, Вес требований 20,23 и 26 изменен, вопрос закрываю. |
| OQ3.3.1-5 | Код BR3.3.1-5, BR3.3.1-6, BR3.3.1-7, BR3.3.1-8, BR3.3.1-9 | Требование говорит: в настройках партнёрской зоны должен появиться блок параметров абонементов — тип границ дат (любые / значение дней / в пределах календарного месяца — это требование весом 1 и НЕ помечено «после релиза»), а также, уже прямо помеченные «после релиза», списки условий создания, скидок, правил отмены и настройка сервисных абонементов. В коде сервис партнёрских зон не содержит вообще ни одной настройки, связанной с абонементами или процессинговыми группами, — ни типа границ дат, ни одного из списков. Единственное найденное в этом сервисе про процессинговые группы — доступные способы оплаты для них, это уже про другое требование (см. OQ3.3.1-7). \ поиск по названиям (в т.ч. «абонемент», «тип границ дат») во всём PartnerZones.Domain/PartnerZones.Application/PartnerZones.Persistence — ни одного совпадения; единственная находка про процессинговые группы в сервисе — PartnerZones.Application/Queries/PaymentFilters/GetProcessingFiltersForProcessingGroup/GetProcessingFiltersForProcessingGroupQuery.cs | Бизнес | Closed | (А) для BR3.3.1-5 (вес 1, заявлено как текущее) — подтвердить необходимость реализации сейчас либо перенести пометку «после релиза» и на него, синхронизировав с BR3.3.1-6–9; (Б) завести на весь блок «Настройки абонементов» одну задачу на будущий релиз — без него не смогут заработать и части требований по подтверждению/оплате/продлению (см. OQ3.3.1-3, OQ3.3.1-4), им негде хранить свои параметры. | ОТ БИЗНЕСА: Типы границ дат не входит в релиз, Вес требования 5 изменен, вопрос закрываю. |
| OQ3.3.1-6 | Код BR3.3.1-17, BR3.3.1-18 | Требование говорит: по умолчанию оплату по абонементу можно привязать только к одному конкретному заказу группы (это уже текущее поведение), а привязку оплаты сразу ко всей группе заказов планируется добавить позже («после релиза»). В коде ограничения «только один заказ» нет уже сейчас: общая команда оплаты заказов принимает массив заказов и ничем не запрещает передать сразу несколько заказов группы за один платёж, а отдельная мобильная операция оплаты абонемента изначально оплачивает сразу все заказы группы в статусе «Резерв» одним платежом. То есть то, что по BRD должно появиться только «после релиза» (привязка к группе), в части оплаты уже работает, а описанное как текущее ограничение «только один заказ» — не действует. \ Orders.Application/Commands/Orders/CreatePayment/CreateOrderPaymentCommandHandler.cs:28-38 (список заказов — массив, привязка к абонементу — необязательный параметр, ограничения на количество заказов нет); Orders.Application/Commands/Orders/CreatePayment/CreateProcessingGroupPaymentMobileCommandHandler.cs:80-90 (оплата сразу всех «Резервов» группы одним платежом) | Бизнес | Closed | (А) признать, что групповая привязка оплаты (BR3.3.1-18) фактически уже частично реализована раньше срока, и актуализировать формулировки BR3.3.1-17/18 под фактическое поведение — рекомендуется, переделывать уже работающую оплату ради искусственного ограничения «один заказ» выглядит шагом назад; (Б) если ограничение «только один заказ по умолчанию» всё ещё нужно бизнесу — добавить в код проверку количества заказов, когда групповая привязка не запрошена явно. | ОТ БИЗНЕСА: Оставить как есть. В BRD групповая оплата предполагается как проведение платежей не по заказам а по абонементу. Вопрос закрываю. |
| OQ3.3.1-7 | Код BR3.3.1-19 | Требование говорит: оплата абонемента должна проводить платежи по группе на основании условий оплаты группы — если размер предоплаты в этих условиях меньше 100%, стоимость к оплате считается по правилам расчёта в группах заказов. В коде мобильная операция оплаты абонемента действительно платит сразу за все заказы группы в «Резерве» одним платежом, но процент предоплаты в ней жёстко задан как 100% — своих «условий оплаты группы» она не читает (их и негде хранить, см. OQ3.3.1-5). У веб-канала такой специальной операции вообще нет — доступна только общая оплата произвольного набора заказов, без автоматического подбора заказов и условий по правилам группы. \ жёстко заданные 100% — Orders.Application/Commands/Orders/CreatePayment/CreateProcessingGroupPaymentMobileCommandHandler.cs:176; общая оплата без правил группы — Orders.Application/Commands/Orders/CreatePayment/CreateOrderPaymentCommandHandler.cs:27-38 | Разработка | Closed | (А) после появления настроек «условий оплаты группы» (OQ3.3.1-5) довести мобильную оплату до чтения реального процента предоплаты вместо жёстких 100% и решить, нужна ли аналогичная операция для веба; (Б) если для абонементов навсегда достаточно 100%-й предоплаты и ручной оплаты по заказам на вебе — зафиксировать это в BRD вместо ссылки на условия оплаты группы. | ОТ БИЗНЕСА: Текущей реализации достаточно. Вес требования 19 изменен. Вопрос закрываю |
| OQ3.3.1-8 | Код BR3.3.1-3 | Требование говорит: заказы внутри процессинговой группы должны игнорировать срок бронирования, заданный сферой деятельности, и вместо него ограничиваться только границами дат самой группы. В коде не найдено ни одного места, где вообще хранится или проверяется «срок бронирования, заданный сферой», — ни для обычных заказов, ни для заказов в группе (поиск по всему бэкенду ничего не дал). Поле, которое по названию ближе всего к сроку брони, при создании и обычного заказа, и заказа в процессинговой группе жёстко выставляется в одно и то же максимальное значение — различия в поведении между «обычным» и «групповым» заказом в коде нет, но нет и самого правила «сфера ограничивает срок», от которого группа должна была бы освобождаться. \ Orders.Application/Commands/Orders/CreateOrder/CreateOrderCommandHandler.cs:31,250 (максимальный срок для обычного заказа); Orders.Application/Commands/ProcessingGroup/Create/CreateProcessingGroupOrSubGroupCommandHandler.cs:247 (то же самое для заказа в группе); Orders.Domain/OrdersAggregate/ValueObjects/Orders/Lifetime.cs (сама value-object ограничения по сфере не содержит) | Разработка | Closed | (А) уточнить у команды, отвечающей за раздел «Сферы и опции» (8.2.1) и за создание обычных заказов, где физически проверяется ограничение по сфере, — «не найдено» может означать «ещё не реализовано в принципе», а не только «нереализовано для групп»; (Б) если ограничение по сфере в системе уже есть под другим названием — указать, где искать, и перепроверить именно групповое исключение. До ответа статус по BR3.3.1-3 остаётся неподтверждённым, а не «не реализовано». | ОТ БИЗНЕСА: Текущей реализации достаточно. Вес требования 3 изменен. Вопрос закрываю |
| OQ3.3.1-9 | Код BR3.3.1-1 | Требование говорит: функционал процессинговых групп должен быть доступен только там, где активированный тариф «Доступ и комиссия» расширил права партнёра. В коде подтверждается только вторая половина цепочки: создание, просмотр и изменение процессинговой группы закрыты отдельными правами доступа (в т.ч. отдельное право на «снятие» абонемента) — то есть без нужного права операции недоступны. А выдаётся ли это право именно активацией тарифа «Доступ и комиссия», или его можно назначить роли и без активного тарифа, по коду сервисов, отвечающих за 3.3.1, не проверялось: сама привязка тарифа к правам живёт в разделах 8.3.1 и 1.4.2, которые в Scope этого BRD прямо помечены как «не входит». \ права на операции с процессинговыми группами — booking.abac/src/Abac.Persistence/Migrations/20260825101541_OperationsSeedV3.cs:598,616-618,642-643; определение группы прав «абонемент» — booking.abac/src/Abac.Persistence/Migrations/20260821145020_PermissionsCatalogV2.cs:54-61 | Разработка | Closed | (А) считать эту часть BR3.3.1-1 подтверждённой на уровне 3.3.1 (права на операции есть) и адресовать вопрос «привязаны ли права именно к тарифу» в сверку разделов 8.3.1/1.4.2, где это и должно проверяться, — рекомендуется, чтобы не дублировать чужой раздел; (Б) если для 3.3.1 принципиально важно перепроверить именно тарифную привязку — расширить якорь на сервис партнёрских зон и раздел 8.3.1 отдельным заходом. | ОТ БИЗНЕСА: Не связан с данным документом. Вопрос закрываю |
| OQ3.3.1-10 | Код BR3.3.1-2 | Требование говорит: процессинговая группа должна поддерживать пять групповых операций — создание, подтверждение, оплату, отмену и продление абонемента — и позволять заказам внутри себя быть в любом статусе. В коде из пяти операций уверенно есть только создание (см. OQ3.3.1-12 — подтверждено) и оплата, хотя и с оговорками (см. OQ3.3.1-6, OQ3.3.1-7); операция, ближе всего похожая на «отмену», работает не так, как описано (см. OQ3.3.1-1, OQ3.3.1-2); подтверждения и продления нет вообще (см. OQ3.3.1-3, OQ3.3.1-4). При этом то, что группа умеет вмещать заказы сразу в разных статусах и учитывать их («Предзаказ», «Резерв», «Закрыто», «Отменено»), в коде подтверждается — это видно по подсчёту заказов группы по статусам. \ подсчёт заказов группы по статусам — Orders.Application/Queries/ProcessingGroup/GetProcessingGroup/GetProcessingGroupQuery.cs:116-123 | Бизнес | Open | Это сводное требование, отдельного технического решения не требует — итоговый статус зависит от решений по OQ3.3.1-1–OQ3.3.1-4, OQ3.3.1-6, OQ3.3.1-7. Смысл вопроса — зафиксировать перед бизнесом сам факт: из пяти заявленных операций абонемента сейчас в разной степени работают только создание и оплата. | ОТ БИЗНЕСА: Привести порядок отмены к требованию(остальное не включено в релиз). Вес 1 |
| OQ3.3.1-11 | Код вне BRD | Что нашли: в сервисе уведомлений есть полностью готовый обработчик события «абонемент архивирован» — он формирует и отправляет клиенту уведомление, подставляя в него данные группы и партнёрской зоны. Но само событие нигде в бэкенде не публикуется: агрегат процессинговой группы не поднимает доменных событий вообще ни на одном своём методе (создание, обновление/архивация, расширение границ дат, изменение статистики), а обработчик обновления группы, через который сейчас проходит архивация, ни разу не вызывает публикацию событий по группе. То есть уведомление об архивации абонемента клиенту никогда не уйдёт, хотя код для этого написан и задеплоен. \ обработчик-получатель — booking.notifications/src/Booking.Notifications/Features/ProcessingGroup/ProcessingGroupArchivedConsumer.cs:19-51; определение события — booking.domain.abstractions/src/Booking.Domain.Abstractions/Contracts/ProcessingGroups/Events/ProcessingGroupArchivedEvent.cs; отсутствие публикации — Orders.Domain/ProcessingGroupAggregate/ProcessingOrderGroup.cs:1-157 (нет ни одного добавления события), Orders.Application/Commands/ProcessingGroup/Update/UpdateProcessingGroupCommandHandler.cs:17-46 (нет вызова публикации событий) | Разработка | Closed | Завести тикет в Bitrix: либо публиковать событие архивации группы при архивации (заодно проверить, актуальны ли его данные после доработки по OQ3.3.1-2), либо, если уведомление больше не нужно, удалить неиспользуемый обработчик в сервисе уведомлений, чтобы не вводить в заблуждение. | ОТ БИЗНЕСА: При архивации абонемента уведомления не требуются. Вопрос закрываю |
| OQ3.3.1-12 | Код BR3.3.1-4 | Что подтверждено: при создании абонемента система действительно проставляет каждому заказу серии тип группы «Процессинговый» — это происходит безусловно, при любом создании (и для новой группы, и при добавлении подгруппы в уже существующую). \ Orders.Application/Commands/ProcessingGroup/Create/CreateProcessingGroupOrSubGroupCommandHandler.cs:259 (тип группы Processing); значения типа группы — booking.domain.abstractions/src/Booking.Domain.Abstractions/AggregateRoot/Enums/OrderGroups/OrderGroupType.cs:1-8 | — | Closed | Расхождения нет. | — ОТ БИЗНЕСА: ок. Вопрос закрываю |