Направление работ: Back
Код раздела: 3.3 Заказы > Группы заказов
Статус: Готов
Ответственный: Панкова Л.А.
Версия: 0.1
Обновлено: 14.08.26
1. Назначение
Группа заказов объединяет связанные заказы в одну сущность и фиксирует принцип их группировки.
Система хранит параметры группы, распределяет входящие заказы по сериям и предоставляет сводные данные о стоимости и оплатах.
Влияние группы на процессинг определяется ее типом; операции с абонементами раскрываются в отдельном подразделе.
2. Ключевые понятия
Группа заказов — сущность, в рамках которой хранится информация о связанных между собой заказах и принципах их группировки. В зависимости от типа группы могут использоваться названия «Абонементы», «Множественные заказы», «Повторяющиеся события» и «Постоянки». Возможности группы и влияние на процессинг входящих в нее заказов, зависят от ее типа.
Справочный тип группы — тип для отображения и работы с постоянными событиями в календаре занятости площадки. Позволяет группировать только заказы в статусе «Предзаказ»; при переводе заказа в статус «Резерв» он исключается из группы. Также используется при работе с группами заказов, поступающими через Back: 6 Интеграции.
Процессинговый тип группы — тип для группировки заказов в абонементы и работы с ними. Параметры такой группы активируются при выборе процессингового типа и позволяют изменять стандартные настройки процессинга входящих заказов.
Границы дат — диапазон дат, в рамках которого возможно создание заказов в группе в соответствии с параметрами групп в Back: 2.8 Настройки партнерской зоны.
Серия заказов — запись с расшифровкой паттерна, которым связаны между собой заказы внутри группы.
Формат повторений серии — параметр, определяющий, по какому принципу сгруппированы заказы в рамках серии: ежемесячно, еженедельно или ежедневно.
3. Scope
Входит
S1 Модель группы: идентификатор, название, клиент, границы дат, тип группы и ограничения типов.
S2 Состав и серии: связь с заказами, распределение заказов по сериям и параметры повторений серии.
S3 Сводные данные: стоимость заказов по состояниям и суммы поступивших и ожидаемых оплат.
S4 Данные процессинговой группы: промокод, платежная ссылка, даты подтверждения и оплаты, публичная ссылка после релиза.
Не входит
- Back: 1.3 Клиенты, Back: 3.1 Состав заказа и Back: 3.2 Процессинг заказов — управление клиентами, состав и жизненный цикл отдельных заказов
- Back: 3.3.1 Процессинговые группы заказов — создание, подтверждение, оплата, продление и отмена абонементов
- Back: 1.4.1 Партнерская зона доступа, Back: 2.8 Настройки партнерской зоны и Back: 8.3.1 Доступ и комиссия — права, тарифы и настройки групп
- Back: 2.7.1 Акции и промокоды, Back: 4.2.1 Расчет в группах заказов, Back: 5 Платежи и Back: 5.5 Провайдеры онлайн-оплат — правила скидок, расчет стоимости и проведение платежей
- Back: 6 Интеграции — получение и синхронизация групп заказов из внешних систем
- WebLk: 5.5 Абонементы и Mobile: 4.3 Информация о группе заказов — интерфейсные сценарии работы с группами
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе.
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR3.3-1 | Группа заказов должна хранить номер, название, клиента, границы дат и тип группы | Состав данных: - номер — уникальный идентификатор группы; - название — опциональное текстовое название группы заказов; - клиент — клиент, за которым закреплена группа; - границы дат — диапазон дат, в рамках которого возможно создание заказов в группе в соответствии с параметрами групп в Back: 2.8 Настройки партнерской зоны; - тип группы — параметр, определяющий доступные операции по заказам, входящим в группу. | Бизнес | 1 | Частично OQ3.3-1 |
| S1: BR3.3-2 | Возможности группы и влияние на процессинг входящих в нее заказов должны зависеть от типа группы | Допустимые значения: - справочный — для справочной группировки заказов без влияния на их процессинг; - процессинговый — для группировки заказов с настраиваемым влиянием на их процессинг. Операции процессингового типа раскрываются в Back: 3.3.1 Процессинговые группы заказов. | Бизнес | 1 | Реализовано OQ3.3-2 |
| S1: BR3.3-3 | Справочный тип группы должен использоваться для отображения и работы с постоянными событиями в календаре занятости площадки | Справочная группа может содержать только заказы в статусе «Предзаказ»; при переводе любого заказа в статус «Резерв» система исключает его из группы. Статусы заказов раскрываются в Back: 3.2 Процессинг заказов. Справочный тип также используется при работе с группами заказов, поступающими через Back: 6 Интеграции. | Бизнес | 1 | Частично OQ3.3-3 |
| S1: BR3.3-4 | Процессинговый тип группы должен использоваться для группировки заказов в абонементы и позволять изменять стандартные настройки процессинга за счет параметров группы | Параметры группы активируются при выборе процессингового типа. Тип доступен только при активном тарифе из Back: 8.3.1 Доступ и комиссия, в который включен функционал процессинговых групп для Back: 1.4.1 Партнерская зона доступа. Операции с абонементами раскрываются в Back: 3.3.1 Процессинговые группы заказов. | Бизнес | 1 | Не реализовано OQ3.3-4 |
| S1: BR3.3-5 | Если в группе указан клиент, все заказы в рамках группы могут быть связаны только с этим клиентом | Управление клиентами раскрывается в Back: 1.3 Клиенты. | Системное | 1 | Частично OQ3.3-5 |
| S2: BR3.3-6 | Группа заказов должна хранить список входящих заказов, распределенных по сериям | Состав данных отдельного заказа определяется в Back: 3.1 Состав заказа. | Бизнес | 1 | Частично OQ3.3-6 |
| S2: BR3.3-7 | При привязке заказов к существующей группе система должна искать подходящие серии и создавать новые серии для заказов, которым не соответствует ни одна существующая серия | Если часть заказов подходит по параметрам существующих серий, система связывает с ними подходящие заказы, а для остальных создает новые серии. | Системное | 1 | Не реализовано OQ3.3-7 |
| S2: BR3.3-8 | Серия заказов должна хранить расшифровку паттерна, которым связаны между собой входящие в нее заказы | Состав данных: - формат повторений серии — принцип группировки заказов в серии; - площадки заказов — площадки, на которые созданы заказы серии; - время — время начала и окончания заказов серии; - заказы — список заказов серии. Форматы повторений: - ежемесячно — дни месяца, значение для каждого N-го месяца в пределах границ дат либо дни недели и значение для каждой N-й недели в пределах месяца; - еженедельно — дни недели от 1 до 7 и значение для каждой N-й недели в пределах границ дат; - ежедневно — значение для каждого N-го дня в пределах границ дат. Для ежемесячного формата значение 31 считается последним днем соответствующего месяца. | Бизнес | 1 | Частично OQ3.3-8 |
| S3: BR3.3-9 | Группа заказов должна предоставлять данные по стоимости входящих заказов | Состав данных: - итоговая стоимость группы — общая сумма всех заказов, входящих в группу; - сумма предзаказов — сумма всех заказов в статусе «Предзаказ»; - сумма зарезервированных заказов — сумма всех заказов в статусе «Резерв»; - сумма закрытых заказов — сумма всех заказов в статусе «Закрыто». Данные выводятся для Back: 3.3.1 Процессинговые группы заказов. Для справочной группы они рассчитываются только при включенном флаге в Back: 2.8 Настройки партнерской зоны либо если заказ был рассчитан до включения в группу. Расчет итоговой стоимости раскрывается в Back: 4.2.1 Расчет в группах заказов. | Бизнес | 1 | Частично OQ3.3-9 |
| S3: BR3.3-10 | Группа заказов должна предоставлять данные о сумме поступивших оплат и неоплаченном остатке | Состав данных: - оплачено — сумма поступивших оплат по заказам в группе; - не оплачено — сумма неоплаченного остатка по заказам в группе. Проведение платежей раскрывается в Back: 5 Платежи. | Бизнес | 1 | Частично OQ3.3-10 |
| S4: BR3.3-11 | Параметры подтверждения и оплаты должны использоваться только в группе с типом «Процессинговый» | Состав данных: - промокод — ручная скидка из Back: 2.7.1 Акции и промокоды, привязанная ко всем заказам группы; - ссылка на оплату — ссылка в среде провайдера из Back: 5.5 Провайдеры онлайн-оплат для проведения платежей по группе или входящим заказам; - подтвердить до — дата, рассчитанная по Back: 2.8 Настройки партнерской зоны, по наступлении которой выполняется отмена абонемента в Back: 3.3.1 Процессинговые группы заказов; - дата подтверждения — дата выполнения операции подтверждения абонемента в Back: 3.3.1 Процессинговые группы заказов; - оплатить до — дата, рассчитанная по сроку полной оплаты из Back: 2.8 Настройки партнерской зоны, по наступлении которой неоплаченные заказы группы в статусе «Резерв» отменяются по Back: 3.2 Процессинг заказов. | Бизнес | 1 | Не реализовано OQ3.3-11 |
| S4: BR3.3-12 | Если дата подтверждения указана, процессинговая группа должна считаться подтвержденной | Дата «Оплатить до» не может быть указана у неподтвержденной группы заказов. | Бизнес | 1 | Не реализовано OQ3.3-12 |
| S4: BR3.3-13 | Процессинговая группа должна иметь публичную ссылку на страницу с информацией о группе и входящих заказах (после релиза реализация) | Публичная ссылка открывается в виджете или мобильном приложении и включает ссылку на оплату. Отображение группы в мобильном приложении раскрывается в Mobile: 4.3 Информация о группе заказов. | Бизнес | 3 | Не реализовано OQ3.3-13 |
5. Открытые вопросы
Сверка с кодом: BRD 3.3 v0.1 · репозиторий
booking-monorepo· commit92603c64/main· 28.08.26 · якорьsrc/services/booking.orders(агрегатыOrders.Domain/NonProcessingGroupAggregate,Orders.Domain/ProcessingGroupAggregate)Сводка: 14 вопросов (Open 13 · Подтверждено 1)
Маршрутизация без сверки с гайдбуком (гайдбук не передавался).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ3.3-1 | Код BR3.3-1 | Требование говорит: группа должна хранить номер, название, клиента, границы дат и тип. В коде справочная группа хранит только номер и правило повторения (RRule) — без названия, клиента и границ дат; процессинговая группа хранит номер, клиента и границы дат, но тоже без названия. До 16.10.2025 обе таблицы имели эти поля (название, клиент/описание, даты) — их убрала миграция «Groups» через 6 дней после создания таблиц. \ NonProcessingOrderGroupModel.cs:7-11, ProcessingOrderGroupModel.cs:7-39, Migrations/20251016193058_Groups.cs | Бизнес | Open | (А) Восстановить поля (название — у обеих групп; клиент и границы дат — у справочной), если урезание 16.10.2025 было побочным следствием рефакторинга, а не продуктовым решением. (Б) Актуализировать формулировку требования под текущую упрощённую модель, если сокращение было осознанным. Связано с OQ3.3-6, OQ3.3-11, OQ3.3-12 — общая причина. | ОТ БИЗНЕСА: А. Восстановить недостающие поля. Вес 1 |
| OQ3.3-3 | Код BR3.3-3 | Требование говорит: справочная группа может содержать только заказы в статусе «Предзаказ»; при переводе заказа в «Резерв» система исключает его из группы. В коде исключение при переходе в «Резерв» реализовано (причём дважды — прямо в заказе и отдельным обработчиком событий на случай, если заказ и группа меняются не одной транзакцией) и работает. А вот входного контроля нет: при создании справочной группы не проверяется, что заказ-затравка сейчас в статусе «Предзаказ» — есть только проверки «не найден», «архивирован» и «уже в группе». \ OrderAggregate.cs:390-398, NonProcessingGroupOrderConsumer.cs:28-43, CreateNonProcessingGroupCommandHandler.cs:46-61 | Разработка | Open | (А) Добавить проверку статуса заказа-затравки перед созданием справочной группы (рекомендуется — требование прямо ограничивает группу заказами в статусе «Предзаказ»). (Б) Оставить как есть, если создание группы из уже зарезервированного заказа допустимо по продукту — тогда решение за бизнесом. | ОТ БИЗНЕСА: А. Добавить проверку статуса «Предзаказ» перед созданием справочной группы. Вес 1 |
| OQ3.3-4 | Код BR3.3-4 | Требование говорит: процессинговый тип группы должен быть доступен только при активном тарифе, включающем функционал процессинговых групп. В коде такой проверки нет вовсе: обработчик создания процессинговой группы не обращается ни к тарифам, ни к правам доступа (сервисы booking.partner-management/booking.abac не вызываются) — создать процессинговую группу может любая партнёрская зона независимо от тарифа. \ CreateProcessingGroupOrSubGroupCommandHandler.cs:38-53 (полный список зависимостей обработчика — тарифного/abac-сервиса среди них нет) | Разработка | Closed | Завести тикет в Bitrix: добавить проверку активного тарифа с функционалом процессинговых групп (см. Back: 8.3.1 Доступ и комиссия) перед созданием/подтверждением процессинговой группы. | ОТ БИЗНЕСА: Реализуем в рамках тарифов и ABAC. Тут вопрос закрываю |
| OQ3.3-5 | Код BR3.3-5 | Требование говорит: если в группе указан клиент, все заказы группы могут быть связаны только с этим клиентом (формулировка предполагает, что клиент — опциональный признак). В коде у процессинговой группы клиент обязателен всегда, а не «если указан»; при этом при добавлении заказа в уже существующую процессинговую группу код не сверяет клиента добавляемого заказа с клиентом группы — несовпадение технически пройдёт незамеченным. \ ProcessingOrderGroup.cs:23,35 (ClientId, комментарий «Non-nullable»), CreateProcessingGroupOrSubGroupCommandHandler.cs:105,117-123,421 (подгруппа и заказ добавляются в существующую группу без сверки ClientId) | Разработка | Open | (А) Добавить проверку совпадения ClientId при добавлении к существующей группе (рекомендуется — закрывает риск смешения клиентов в одном абонементе); заодно поправить формулировку требования — по факту клиент обязателен, а не опционален. | ОТ БИЗНЕСА: Добавить проверку совпадения ClientId при добавлении к существующей группе. Вес 1 |
| OQ3.3-6 | Код BR3.3-6 | Требование говорит: группа должна хранить список входящих заказов, распределённых по сериям. В коде заказы действительно ссылаются на группу (orders.group_id), но распределение по сериям есть только у процессинговых групп — через подгруппы (subgroup_id). У справочной группы своей серии/подгруппы не существует в принципе: на всю группу хранится одно общее правило повторения (RRule) без деления на несколько серий. \ ApplicationDbContextModelSnapshot.cs:453-459,548-550 (orders.group_id/group_type/subgroup_id), NonProcessingOrderGroupModel.cs:7-11 (только Id и RRule, без подгрупп) | Бизнес | Open | Уточнить, нужна ли справочной группе поддержка нескольких серий (как у процессинговой), или единого правила повторения на группу достаточно по продукту — от ответа зависит объём доработки. Связано с OQ3.3-1. | ОТ БИЗНЕСА: Реализовать поддержку нескольких независимых серий с разными правилами повторения в справочных группах. Вес 2 |
| OQ3.3-7 | Код BR3.3-7 | Требование говорит: при привязке заказов к существующей группе система должна искать подходящую серию и создавать новую только для заказов, которым не подошла ни одна существующая. В коде такого поиска нет: при добавлении к существующей процессинговой группе (параметр ExistingProcessingGrupId) обработчик безусловно создаёт новую подгруппу с новым идентификатором и добавляет её в группу — совпадение по правилу повторения / базе / комнате с уже существующими подгруппами нигде не проверяется. \ CreateProcessingGroupOrSubGroupCommandHandler.cs:105,117-123,421 | Разработка | Open | Завести тикет в Bitrix: перед созданием новой подгруппы искать среди существующих подгрупп группы совпадение по RRule / базе / комнате и переиспользовать найденную; создавать новую подгруппу только когда совпадения нет. | ОТ БИЗНЕСА: Перед созданием новой серии искать совпадение по RRule/базе/комнате; создавать новую только при отсутствии совпадений. Вес 2 |
| OQ3.3-8 | Код BR3.3-8 | Требование говорит: серия должна хранить формат повторения (ежемесячно/еженедельно/ежедневно с деталями), площадки, время начала-окончания и список заказов; отдельно — что 31-е число для ежемесячного формата считается последним днём месяца. В коде вместо структурированной серии хранится сырая строка стандарта iCalendar (RRULE), которую разбирает стандартная библиотека Ical.Net; отдельных полей формата или времени начала-окончания нет. Правило «31 = последний день месяца» в коде не встречается нигде — стандартная семантика RRULE в этом случае просто пропускает короткие месяцы, а не переносит дату на последний день. До 09.10.2025 в БД была отдельная таблица серии с нужными полями (формат/интервал/паттерн/площадка/время) — её удалили. \ RRuleParserService.cs:94 (создание RecurrencePattern из строки через Ical.Net), Migrations/20251009155201_Added grouptype and groupid.cs:14-24,130-157 (удалённая таблица order_group_series) | Разработка | Open | (А) Реализовать правило «31 = последний день месяца» отдельной обработкой поверх стандартного RRULE (важно — иначе ежемесячные абонементы, начатые 31-го числа, будут пропускать короткие месяцы вместо переноса на последний день). Формат/время можно оставить в виде RRULE-строки, если для UI и отчётности этого достаточно — при необходимости структурированного вывода уточнить у бизнеса. | ОТ БИЗНЕСА: Формат повторений должен поддерживать календарные месяцы(28/29,30 и 31 день). Вес 1 |
| OQ3.3-9 | Код BR3.3-9 | Требование говорит: группа должна отдавать итоговую стоимость и отдельно — суммы по статусам (предзаказы, зарезервированные, закрытые). В коде итоговая стоимость есть, но по статусам считаются только количества заказов (предзаказы/резерв/закрыто и т.д.), а не суммы в рублях — денежной разбивки по статусам в ответе метода нет. Для справочной группы нет вообще никакого метода для получения этих данных. \ GetProcessingGroupQuery.cs:107-127 (только счётчики), GetProcessingGroupQuery.cs:134-145 (ответ метода — общая сумма без разбивки по статусам) | Разработка | Open | (А) Досчитать суммы по статусам рядом с уже существующими счётчиками — данные по каждому заказу уже загружены в том же цикле, доработка точечная. (Б) Уточнить у бизнеса, действительно ли нужна именно денежная разбивка, а не количество заказов по статусам, которое уже есть. Связано с OQ3.3-10. | ОТ БИЗНЕСА: А. Рассчитывать суммы по статусам заказов на основании данных по заказам входящим в группу. Вес 2 |
| OQ3.3-10 | Код BR3.3-10 | Требование говорит: группа должна отдавать сумму поступивших оплат и неоплаченный остаток. В коде для процессинговой группы это реализовано корректно (оплачено / не оплачено, где «не оплачено» = максимум из «стоимость минус оплачено» и нуля), но для справочной группы аналогичного метода нет вообще — ни безусловно, ни по флагу, упомянутому в комментарии к требованию (флаг относится к Back: 2.8 Настройки партнерской зоны, сам флаг вне зоны этой сверки). \ GetProcessingGroupQuery.cs:129,138-140 | Бизнес | Closed | Уточнить, нужен ли вывод оплаченного/неоплаченного остатка для справочных групп и при каком условии (флаг настроек партнёрской зоны либо всегда) — отсутствие проверки этого флага в booking.orders означает, что для справочных групп условие сейчас никогда не выполняется. Связано с OQ3.3-9. | ОТ БИЗНЕСА: В справочных группах оплаты не производятся. Оставить как есть, вопрос закрываю |
| OQ3.3-11 | Код BR3.3-11 | Требование говорит: процессинговая группа должна хранить промокод, ссылку на оплату, дату «подтвердить до», дату подтверждения и дату «оплатить до» (рассчитанную по сроку полной оплаты из настроек партнёрской зоны). В коде из пяти полей не хранится ни одно в описанном виде: промокода, ссылки на оплату, даты «подтвердить до» и даты подтверждения в модели процессинговой группы нет вообще; единственное похожее по названию поле («дата оплаты») на деле хранит не срок оплаты, а минимальную (самую раннюю) дату среди заказов создаваемой группы — то есть это «дата начала первого заказа в группе», а не «оплатить до». Все перечисленные поля (кроме этого) были в таблице order_groups до 09.10.2025 — миграция удалила эту таблицу вместе с ними. \ ProcessingOrderGroupModel.cs:7-39, CreateProcessingGroupOrSubGroupCommandHandler.cs:210,214-216,414 (вычисление поля как минимума дат заказов), Migrations/20251009155201_Added grouptype and groupid.cs:14-24,70-102 (удалённые поля) | Бизнес | Open | (А) Восстановить недостающие поля (промокод, ссылка на оплату, даты подтверждения/оплаты) в модели процессинговой группы и пересчитать «оплатить до» по сроку полной оплаты из настроек партнёрской зоны — если функционал подтверждения/оплаты абонемента по-прежнему нужен в этом виде. (Б) Актуализировать требование под текущую реализацию, если урезание было осознанным (например, если эти данные теперь ведутся на уровне отдельных заказов, а не группы). Связано с OQ3.3-1, OQ3.3-12. | ОТ БИЗНЕСА: А. Восстановить поля и пересчитать «оплатить до» по сроку полной оплаты из настроек партнёрской зоны. Вес 2 |
| OQ3.3-12 | Код BR3.3-12 | Требование говорит: если у процессинговой группы указана дата подтверждения, группа должна считаться подтверждённой. В коде самого поля «дата подтверждения» у процессинговой группы не существует (см. OQ3.3-11) — соответственно, не из чего вычислить признак «подтверждена»: ни поля, ни производного статуса подтверждения в модели процессинговой группы нет. \ ProcessingOrderGroupModel.cs:7-39, ProcessingOrderGroup.cs:13-61 (полный список полей и методов агрегата — подтверждения среди них нет) | Бизнес | Open | Решение зависит от OQ3.3-11: если поле «дата подтверждения» восстанавливается — производный признак «подтверждена» реализуется вместе с ним; если нет — уточнить, чем сейчас в продукте заменено понятие «подтверждённый абонемент». | ОТ БИЗНЕСА: Реализовать производный признак «подтверждена» вместе с QQ3.3-11 |
| OQ3.3-13 | Код BR3.3-13 | Требование говорит: процессинговая группа должна иметь публичную ссылку на страницу с информацией о группе (само требование помечено «после релиза реализация»). В коде поля для публичной ссылки у процессинговой группы сейчас нет; такое поле существовало в удалённой 09.10.2025 таблице order_groups, в текущих таблицах его нет. \ ProcessingOrderGroupModel.cs:7-39, Migrations/20251009155201_Added grouptype and groupid.cs:14-24,93 | Бизнес | Closed | Требование само отмечает отложенную реализацию — уточнить актуальный приоритет и срок; если сроки подошли, поле и метод генерации публичной ссылки нужно реализовывать заново (переиспользовать старое поле не получится — таблица с ним удалена). | ОТ БИЗНЕСА: Восстановить после релиза. Вес 3. Вопрос закрываю. |
| OQ3.3-14 | Код вне BRD | Что нашли: команда обновления заказов справочной группы помечена атрибутом [Obsolete("unused")], но остаётся публичным RPC-методом (атрибут [RpcMethod] не снят) — формально считается неиспользуемой, но по-прежнему вызываема снаружи. \ UpdateNonProcessingGroupOrdersCommand.cs:15-17 | Разработка | Open | Завести тикет в Bitrix: проверить реальных вызывающих; если метод действительно не используется — закрыть RPC-доступ (убрать [RpcMethod]) или удалить, чтобы [Obsolete] не расходился с фактической достижимостью. | ОТ БИЗНЕСА: Если метод не используется удалить. Вес 1 |
| OQ3.3-2 | Код BR3.3-2 | Что подтверждено: справочная и процессинговая группы — разные агрегаты с разным влиянием на входящие заказы: архивация справочной группы архивирует входящие в неё заказы, а архивация процессинговой группы архивирует саму группу (заказы не трогает); при переходе заказа из «Предзаказ» в «Резерв» он автоматически исключается из группы, но только если группа справочная. \ ArchiveNonProcessingGroupCommandHandler.cs:58-63, ProcessingOrderGroup.cs:141-156, UpdateProcessingGroupCommandHandler.cs:36, OrderAggregate.cs:390-398 | — | Closed | Расхождения нет. | — ОТ БИЗНЕСА: ок |