2.4.3 Правила отмены

Направление работ: Back

Код раздела: 2.4.3 Объекты и предложения > Правила работы с заказами > Правила отмены

Статус: черновик

Ответственный: Панкова Л.А.

Версия: 0.1

Обновлено: 10.07.26

1. Назначение

Правила отмены заказов — список условий расчета доступного времени с момента резервирования заказа, в рамках которого заказ на площадке объекта можно отменить без начисления сбора.

Правила отмены работают по единому принципу правил работы с заказами: привязываются к объектам и площадкам через наследование стандартных системных правил из раздела Back 8.4 Параметры системы. Расчет сроков бесплатной отмены и начисление сборов раскрываются в Back 3.2.1 Сборы за заказ.

2. Ключевые понятия

Правило отмены — условие, определяющее доступный срок отмены заказа без начисления сбора.

Сбор за заказ — начисление, применяемое при отмене заказа за пределами срока бесплатной отмены.

3. Scope

Входит

S1 Правила отмены: определение доступного срока бесплатной отмены заказа и базовое правило применения.

S2 Параметры и данные: параметры времени создания заказа, срока бесплатной отмены, области и периода действия правила.

S3 Порядок применения: сортировка и последовательность проверки правил при расчете срока бесплатной отмены.

S4 Ограничения: запрет сохранения правил отмены с полностью идентичными параметрами.

Не входит

4. Требования

Правила и ограничения бизнеса на уровне данных, источник истины в системе.

ID	Требование	Комментарий	Тип требования	Вес	Статус
S1: BR2.4.3-1	Правила отмены должны содержать условия расчета доступного времени с момента резервирования заказа, в рамках которого заказ можно отменить без начисления сбора	Название правила отмены — текстовое название записи. Правила отмены применяются к заказам на площадках объекта по правилам наследования и привязки, описанным в Back 2.4 Правила работы с заказами. Расчет сроков бесплатной отмены и начисление сборов раскрываются в Back 3.2.1 Сборы за заказ, стандартные системные правила — в Back 8.4 Параметры системы.	Бизнес	1	Частично · OQ2.4.3-4
S2: BR2.4.3-2	Правило отмены должно определять условия по времени создания заказа	Группа параметров времени создания заказа содержит: - Тип расчета «День в день» — применяется к заказам, созданным в день заказа; - Тип расчета «Менее чем за» — применяется с указанным значением часов; - Тип расчета «Более чем за» — применяется с указанным значением часов.	Бизнес	1	Частично · OQ2.4.3-6, OQ2.4.3-7
S2: BR2.4.3-3	Правило отмены должно определять срок бесплатной отмены заказа	Группа параметров срока бесплатной отмены содержит: - Тип расчета «Всегда» — бесплатная отмена доступна всегда; - Тип расчета «В течение» — срок определяется указанным значением часов; - Тип расчета «Не позднее чем за» — срок определяется указанным значением часов.	Бизнес	1	Частично · OQ2.4.3-5
S2: BR2.4.3-4	Правило отмены должно определять период и область своего действия	Параметры действия содержат: - Период действия — календарный период работы правила отмены (если не задан — правило действует всегда); - Источники — интерфейсы, в которых доступно правило (если не заданы — все источники); - Опции — перечень опций, на которые распространяется правило (если не заданы — все опции); - Диапазон опции — число или диапазон в формате «X-X» для опций с признаком «диапазон» (если не задан — любой диапазон); - Дни недели — множественный выбор из семи вариантов, с понедельника по воскресенье (если не заданы — все дни). Источники раскрываются в Back 8.2.2 Источники заказа, опции — в Back 8.2.1 Сферы и Опции.	Бизнес	1	Частично · OQ2.4.3-1, OQ2.4.3-3, OQ2.4.3-8
S2: BR2.4.3-5	Правило отмены должно поддерживать деактивацию посредством архивации	Признак архивации деактивирует работу правила отмены.	Системное	1	Реализовано · OQ2.4.3-20
S3: BR2.4.3-6	Правила отмены должны проверяться в порядке, соответствующем алгоритму расчета сроков бесплатной отмены	Последовательность проверки зависит от группы параметров времени создания заказа: 1. «День в день» — проверяются в первую очередь; 2. «Более чем за» — проверяются от наибольшего значения часов к меньшему; 3. «Менее чем за» — проверяются от наибольшего значения часов к меньшему. Алгоритм расчета сроков бесплатной отмены раскрывается в Back 3.2.1 Сборы за заказ.	Системное	1	Не реализовано · OQ2.4.3-2
S4: BR2.4.3-7	Система не должна допускать сохранение правил отмены с полностью идентичными параметрами		Системное	2	Не реализовано · OQ2.4.3-9

5. Открытые вопросы

Пин контекста. BRD 2.4.3 «Правила отмены» v0.1 · репозиторий booking-monorepo · commit 83423b21, ветка main · дата сверки 20.07.2026 · якорь: src/services/booking.partner-management/src/PartnerZones.{Domain,Application,Persistence}/…CancelRule…, cross-layer — src/services/booking.orders, src/libs/booking.domain.abstractions.

Сводка: 20 вопросов (Open 14 · Закрывает PM 5 · Подтверждено 1) · требований подтверждено 1 из 7 · отрезано находок обратного прохода: 5 (плумбинг и правила, принадлежащие разделам 3.2.1/2.8).

Маршрутизация без сверки с гайдбуком — гайдбук на вход не передавался, поэтому спорные места отнесены к бизнесу как «подтвердить нечем», а не закрыты как баги.

ID	Источник	Вопрос	Кому	Статус	Рекомендации	Итоговое решение
OQ2.4.3-1	Код BR2.4.3-4	Требование говорит: правило отмены действует только в тех источниках заказа, которые в нём указаны; если источники не заданы — во всех. В коде источники у правила сохраняются и хранятся в отдельной таблице, но при подборе правила для заказа они никогда не проверяются: в основном (пакетном) запросе таблица источников только подгружается, в условие отбора не входит; в одиночном запросе идентификатор источника принимается параметром и не используется; в структуре запроса из сервиса заказов поля источника нет вообще. Практический эффект: правило, ограниченное, например, только виджетом, одинаково применится к заказу из админки. \ `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:176` (только подгрузка), `:224,228-245` (параметр игнорируется), `Booking.Domain.Abstractions/Contracts/PartnerZones/GRPC/GetCancelRuleOrDefaultByBookingConditions/GetCancelRuleOrDefaultByBookingConditionsQuery.cs:13-34` (нет поля источника)	Бизнес (Герман)	Open	(А) Признать ограничение по источникам обязательным и добавить его в отбор — правило перестанет «протекать» между каналами продаж (рекомендуется: параметр заявлен в BRD и уже хранится, сейчас он вводит партнёра в заблуждение). (Б) Признать, что источники к правилам отмены не применяются, убрать параметр из BRD и из интерфейса. Разблокирует OQ2.4.3-9 (состав «идентичных параметров»).	доработка, вариант А
OQ2.4.3-2	Код BR2.4.3-6	Требование говорит: при подборе правила сначала проверяются правила «День в день», затем «Более чем за» от большего числа часов к меньшему, затем «Менее чем за» тоже от большего к меньшему. В коде такой сортировки нет ни в одном месте. Единственный приоритет — по уровню привязки: правило площадки выигрывает у правила объекта. Среди правил одного уровня берётся первое попавшееся в том порядке, в котором их вернула база. В запасном сценарии (правила по умолчанию для сферы) сортировки нет вовсе. \ `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:208-214` (сортировка только площадка/объект), `:244-245`, `:293-294`, `PartnerZones.Application/Queries/CancelRule/GetCancelRuleOrDefaultByBookingConditions/GetCancelRuleOrDefaultByBookingConditionsQueryHandler.cs:116` (запасной сценарий без сортировки)	Бизнес (Герман) / Разработка (Владислав)	Open	(А) Реализовать порядок, описанный в требовании — иначе при нескольких подходящих правилах партнёр не может предсказать, какое применится (рекомендуется: это ядро раздела S3, без него требование не имеет наблюдаемого эффекта). (Б) Если фактический порядок (по уровню привязки) признаётся целевым — переписать BR2.4.3-6 под него и явно описать правило разрешения ничьих. Корневой вопрос: разблокирует OQ2.4.3-12.	доработка
OQ2.4.3-3	Код BR2.4.3-4	Требование говорит: правило действует в выбранные дни недели. В коде для заказа строится набор дней только из дня начала и дня окончания заказа — промежуточные дни многодневного заказа не учитываются. Для заказа со среды по субботу правило, не покрывающее четверг и пятницу, всё равно будет применено. Дополнительно семантика различается между сценариями подбора: в основном требуется, чтобы правило покрывало все дни заказа, в старом — достаточно совпадения хотя бы по одному дню. \ `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:158-167` (набор дней), `:182` (покрывать все), `:236` (достаточно пересечения)	Бизнес (Герман)	Open	(А) Строить набор дней по всем суткам, которые захватывает заказ, и оставить одну семантику — «правило должно покрывать все дни» (рекомендуется: соответствует формулировке требования и убирает расхождение между сценариями). (Б) Зафиксировать в BRD, что для многодневных заказов дни недели проверяются только по началу и окончанию.	Не подтверждённый баг, а вопрос к бизнесу об инварианте заказа и семантике дней недели для правил отмены. Тут вопрос изначально в возможности того, чтобы ОДИН заказ длился НЕСКОЛЬКО дней
OQ2.4.3-4	Код BR2.4.3-1	Требование говорит: у правила отмены есть название — текстовое название записи. В коде отдельного поля «название» у правила нет: единственное текстовое поле называется «описание» (`description`), так же оно названо в контракте создания. Заполнять его не обязательно — пустое или отсутствующее описание принимается без ошибки, поэтому правило может быть сохранено безымянным. Сам механизм расчёта срока бесплатной отмены и привязка к партнёрской зоне / площадке / объекту при этом реализованы. \ `PartnerZones.Persistence/CancelRules/Models/CancelRule.cs:24-25`, `PartnerZones.Domain/CancelRuleAggregate/ValueObjects/CancelRule/Info.cs:12-17` (без проверки на пустоту), `PartnerZones.Application/Commands/CancelRule/Create/CreateCancelRuleCommand.cs:66` («Описание правила отмены»)	Бизнес (Герман)	Open	(А) Считать это поле названием, сделать обязательным и переименовать в контракте — партнёр должен различать правила в списке (рекомендуется: список правил без названий нечитаем). (Б) Признать поле описанием (необязательным) и убрать из BR2.4.3-1 упоминание названия.	Правила отмены в ЛК сейчас создаются с дефолтный “Правило 1”, “Правило 2” etc. Названия им как таковые не задаются, поле Description не указывается + в UI сейчас нигде не предусмотренно введение названия/описания
OQ2.4.3-5	Код BR2.4.3-3	Требование говорит: срок бесплатной отмены задаётся одним из трёх типов — «Всегда», «В течение N часов», «Не позднее чем за N часов». В коде три типа заведены и хранятся корректно, но расчёт срока существует в двух независимых реализациях с разными границами: боевая (в сервисе заказов) считает отмену доступной включительно по границе, вторая (в сервисе партнёрских зон) для типа «Не позднее чем за» использует строгое сравнение, то есть на самой границе даёт противоположный ответ. Вторая реализация, судя по обходу, ниоткуда не вызывается и в gRPC-контракте отсутствует. \ `booking.orders/src/Orders.Domain/Common/Helpers/FreeCancellationHelper.cs:89-108,117` (боевая), `PartnerZones.Application/Queries/CancelRule/FreeCancellationAllowed/FreeCancellationAllowedQueryHandler.cs:96-109` (вторая, строгое сравнение)	Разработка (Владислав)	Open	(А) Удалить неиспользуемую реализацию, оставив одну точку расчёта (рекомендуется: две формулы одного правила рано или поздно разойдутся в проде). (Б) Если второй обработчик планируется включать — привести границы к боевой и покрыть тестом. Требуется также бизнес-ответ по OQ2.4.3-6 о поведении на границе.	доработка
OQ2.4.3-6	Код BR2.4.3-2	Требование говорит: типы «Менее чем за» и «Более чем за» применяются с указанным значением часов. В коде часы можно не указать: система не отвергает такое правило при сохранении, а при подборе молча его пропускает — правило сохраняется, отображается партнёру как действующее, но не срабатывает никогда. Симметрично при типе «Всегда» / «День в день» переданные часы молча отбрасываются вместо явной ошибки. \ `PartnerZones.Domain/CancelRuleAggregate/ValueObjects/CancelRule/OrderCreationSettings.cs:12-17`, `FreeCancellationSettings.cs:12-17` (тихая нормализация), `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:192,195` (правило без часов не подбирается)	Разработка (Владислав)	Open	(А) Отвергать сохранение правила, у которого тип требует часов, а часы не заданы (рекомендуется: «правило-пустышка» выглядит рабочим и разбирается только по инциденту). (Б) Оставить как есть и описать в BRD, что правило без часов считается неактивным.	Сейчас при создании правил отмены в UI есть дефолтное значение “более чем за 24 и менее чем за 24”. Если партнер его не меняет, то оно и передается. Можно дополнительно добавить проверку на бэке на отсутствие часов, НО
OQ2.4.3-7	Код BR2.4.3-2	Требование говорит: правило применяется к заказам в зависимости от времени их создания. В коде если заказ начинается раньше момента своего создания (заказ, оформленный «задним числом»), проверка по времени создания отключается целиком: подходит любое правило независимо от его типа расчёта. Отдельно: тип «День в день» сравнивает дату создания с датой начала заказа и не обращается к параметрам самого правила. \ `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:187` (отключение проверки), `:189` (сравнение дат), `PartnerZones.Application/Queries/CancelRule/GetCancelRuleOrDefaultByBookingConditions/GetCancelRuleOrDefaultByBookingConditionsQueryHandler.cs:105`	Бизнес (Герман)	Open	(А) Определить, какое правило отмены должно применяться к заказам «задним числом», и закрепить это в BRD и коде (рекомендуется: сейчас исход зависит от порядка выдачи базы). (Б) Признать, что для таких заказов правила отмены не применяются, и возвращать явный отказ вместо произвольного правила.	Клиент задним числом забронироваться не может, соответственно правил там никаких нет. Задним числом партнер может ЗАКРЫТЬ время, на что правила не распространяются
OQ2.4.3-8	Код BR2.4.3-4	Требование говорит: период действия, опции, диапазон опции и дни недели ограничивают применение правила. В коде это верно для обычных правил, но не для запасного сценария: если для объекта/площадки подходящее правило не нашлось, система берёт правила по умолчанию для сферы и фильтрует их только по времени создания заказа — период действия, дни недели, опции и диапазон опции на этом пути не проверяются вовсе. \ `PartnerZones.Application/Queries/CancelRule/GetCancelRuleOrDefaultByBookingConditions/GetCancelRuleOrDefaultByBookingConditionsQueryHandler.cs:104-116`, `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:53` (отбор дефолтов только по сфере и архивности)	Бизнес (Герман)	Open	(А) Применять к правилам по умолчанию тот же набор проверок, что и к обычным (рекомендуется: иначе параметры системного правила из Back 8.4 объявлены, но не работают). (Б) Зафиксировать в BRD, что правила по умолчанию для сферы задаются без периода, дней недели и опций, и запретить их указывать при создании.	Тут больше вопрос к бизнесу: Если системное правило сферы — полноценная действующая политика по умолчанию, оно обязано проходить те же проверки, что обычное правило. Тогда это доработка Если системное правило — намеренно упрощённый глобальный fallback только по времени создания, то OQ8 — не баг. Но тогда создание не должно принимать дни, период, источники и опции либо эти поля надо явно пометить как неиспользуемые/убрать из BRD.
OQ2.4.3-9	Код BR2.4.3-7	Требование говорит: система не должна допускать сохранение правил отмены с полностью идентичными параметрами. В коде такого запрета нет ни на одном уровне: при создании и изменении проверяются только непустой список правил, права доступа и корректность привязки к объектам/площадкам; на уровне базы у таблицы правил единственный ключ — суррогатный идентификатор. Инициализатор базы создаёт уникальные индексы для других сущностей (тарифы партнёра, привязки сфер, приоритетное размещение), для правил отмены — нет. Два байт-в-байт одинаковых правила создаются без ошибки; также не ограничено число правил по умолчанию на одну сферу. \ `PartnerZones.Application/Commands/CancelRule/Create/CreateCancelRuleCommandHandler.cs:51-93` (весь набор проверок), `PartnerZones.Persistence/DbInitializer.cs:80` (таблица без индексов) против `:163,406,408,473` (уникальные индексы у других сущностей)	Бизнес (Герман) / Разработка (Владислав)	Open	(А) Ввести запрет — но сначала бизнес-решение, что считать «полностью идентичными параметрами» (входят ли источники, привязка, период, описание) (рекомендуется: без этого списка запрет нельзя закодировать однозначно). (Б) Понизить до предупреждения в интерфейсе без жёсткого запрета. Зависит от OQ2.4.3-1.	Перед реализацией надо определить точный набор идентифицирующих параметров.
OQ2.4.3-10	Код вне BRD	Что нашли: если ни одно правило отмены не подошло и правил по умолчанию для сферы тоже нет, система возвращает не отказ, а разрешающую заглушку: тип «Всегда», то есть бесплатная отмена доступна всегда, с пояснением «Правила отмены не найдены». Сервис заказов трактует такой ответ по-разному: при одиночном запросе бросает ошибку, при пакетном — молча пропускает заказ, и правило к нему не привязывается вовсе. В требованиях поведение «правил нет» не описано. \ `PartnerZones.Application/Queries/CancelRule/GetCancelRuleOrDefaultByBookingConditions/GetCancelRuleOrDefaultByBookingConditionsQueryHandler.cs:130-135`, `booking.orders/src/Orders.Infrastructure/Services/PartnerZoneService.cs:79-82` (ошибка) против `:128-129` (молча пропускается)	Бизнес (Герман)	Open	(А) Зафиксировать в BRD умолчание «нет правил ⇒ отмена бесплатна» и выровнять оба сценария на него (рекомендуется: заглушка уже работает так, надо лишь сделать это осознанным и единообразным). (Б) Считать отсутствие правил ошибкой конфигурации и не давать создавать заказ. Связать с OQ2.4.3-8.	доработка
OQ2.4.3-11	Код вне BRD	Что нашли: подобранное правило отмены кэшируется на 6 часов, при этом в ключ кэша не входит дата создания заказа, хотя именно она влияет на подбор (группа параметров «время создания заказа»). Два заказа на одни и те же дату, объект и опцию, но созданные в разное время, могут получить одно и то же правило из кэша — то есть не то, которое им полагается. В требованиях кэширование не описано. \ `booking.orders/src/Orders.Infrastructure/Services/PartnerZoneService.cs:55,86,133-134`	Разработка (Владислав)	Open	(А) Добавить дату создания заказа в ключ кэша (рекомендуется: минимальная правка, устраняет выдачу чужого правила). (Б) Отказаться от кэша на этом пути.	доработка
OQ2.4.3-12	Код вне BRD	Что нашли: когда после фильтрации остаётся несколько правил одного уровня привязки (например, два правила на один и тот же объект), победитель выбирается недетерминированно — берётся первый элемент в том порядке, в каком строки вернула база. Один и тот же заказ при повторном расчёте может получить разные правила отмены. \ `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:208-214`	Разработка (Владислав)	Open	(А) Ввести устойчивый порядок разрешения ничьих (после решения по OQ2.4.3-2) (рекомендуется: воспроизводимость расчёта сбора — требование к деньгам). (Б) Запретить существование нескольких правил одного уровня — тогда закрывается вместе с OQ2.4.3-9.	нужен детерминированный порядок либо запрет дублей.
OQ2.4.3-13	Код вне BRD	Что нашли: при отмене заказа правило отмены влияет только на бинарный выбор «бесплатно / со сбором». Размер сбора из правила не выводится вообще: он равен полной стоимости заказа либо остатку переплаты. Ни процента удержания, ни фиксированной суммы, ни шкалы «за N часов до начала» в правиле отмены нет; сохраняемый в заказе снимок правила содержит только четыре поля (два типа и двое часов) и не позволяет восстановить, какое именно правило применилось. \ `booking.orders/src/Orders.Domain/OrdersAggregate/OrderAggregate.cs:473-503` (расчёт суммы), `Booking.Domain.Abstractions/AggregateRoot/ValueObjects/Orders/CancelRuleSnapshot.cs:18-21` (состав снимка)	Разработка (Владислав)	Закрывает PM	Закрываю сам: это область Back 3.2.1 Сборы за заказ, выведенная из scope 2.4.3 — правило здесь не дублирую, а передаю находку в сверку 3.2.1 (процент удержания и восстановимость применённого правила) → тикет в Bitrix.	сбор расчитывается отдельно
OQ2.4.3-14	Код вне BRD	Что нашли: правило, унаследованное площадкой или объектом от правила по умолчанию сферы, создаётся с поднятым признаком «правило по умолчанию», хотя сфера у него при этом не указана. Признак используется при отборе системных правил, поэтому пометка обычной копии как дефолтной выглядит дефектом, а не намерением. \ `PartnerZones.Domain/CancelRuleAggregate/CancelRuleAggregate.cs:230-231` (передаётся `isDefault: true`, `sphereId: null`), сигнатура — `:191`	Разработка (Владислав)	Закрывает PM	Закрываю сам: продуктового выбора нет — либо признак ставится осознанно и это надо описать, либо это ошибка позиционного аргумента. Завожу на разбор и правку → тикет в Bitrix.
OQ2.4.3-15	Код вне BRD	Что нашли: таблица привязок правила к партнёрской зоне / площадке / объекту (`cancel_rule_scope`) читается в рантайме, но не создаётся инициализатором базы, в отличие от остальных таблиц правил отмены. На чистом окружении привязки правил работать не будут — схема, видимо, доезжает откуда-то ещё. \ `PartnerZones.Persistence/DbInitializer.cs:80,108,109` (создаются три другие таблицы, этой нет), `PartnerZones.Persistence/DbConnection.cs:68` (таблица запрашивается)	Разработка (Владислав)	Закрывает PM	Закрываю сам: развёртывание, продуктового выбора нет — добавить создание таблицы в инициализатор → тикет в Bitrix.	доработка
OQ2.4.3-16	Код вне BRD	Что нашли: у диапазона опции не проверяется, что верхняя граница не меньше нижней — диапазон «с 10 по 5» сохраняется. Кроме того, при подборе верхняя граница читается без проверки на пустоту: строка, где нижняя граница задана, а верхняя нет, приведёт к сбою расчёта. \ `Booking.Domain.Abstractions/AggregateRoot/ValueObjects/Places/Options/OptionRange.cs:10-15` (проверяется только неотрицательность нижней), `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:185` (верхняя граница разыменовывается)	Разработка (Владислав)	Закрывает PM	Закрываю сам: скрытая ошибка, продуктового выбора нет — добавить проверку «верхняя ≥ нижней» и согласованность заполнения обеих границ → тикет в Bitrix.	доработка
OQ2.4.3-17	Код вне BRD	Что нашли: архивация правила отмены отдельной командой не проверяет прав доступа — обработчик вообще не обращается к сервису авторизации, тогда как создание и изменение требуют прав `cancel_rules_write`, а архивация через изменение — `cancel_rules_delete`. В требованиях права на архивацию не описаны. \ `PartnerZones.Application/Commands/CancelRule/Archive/ArchiveCancelRuleCommandHandler.cs:1-31` (проверки прав нет), `PartnerZones.Application/Commands/CancelRule/Update/UpdateCancelRuleCommandHandler.cs:95-100` (права требуются)	Разработка (Владислав)	Open	(А) Требовать `cancel_rules_delete` и в отдельной команде архивации (рекомендуется: обход прав через альтернативный путь — это дыра в доступе). (Б) Подтвердить, что команда недоступна снаружи, и закрыть её на уровне шлюза.	решается ABAC’ом
OQ2.4.3-18	Код вне BRD	Что нашли: режим «учитывать сбор в будущих заказах» в настройках партнёрской зоны жёстко зафиксирован как включённый: переданное значение присваивается и тут же перезаписывается на «истину», то есть настройка не действует. Это область Back 2.8, но она напрямую влияет на последствия отмены заказа. \ `PartnerZones.Domain/PartnerZoneAggregate/ValueObjects/PartnerZone/ForfeitSettings.cs:51-52`	Разработка (Владислав)	Закрывает PM	Закрываю сам: явная ошибка (две подряд идущие записи в одно поле), продуктового выбора нет. Принадлежит разделу Back 2.8 — здесь не дублирую, передаю в его сверку → тикет в Bitrix.
OQ2.4.3-19	Код вне BRD	Что нашли: удалить обычное правило отмены нельзя — отдельной команды удаления нет, доступна только архивация. Физическое удаление предусмотрено исключительно для правил, унаследованных от правил по умолчанию, и выполняется без публикации доменных событий. В требованиях жизненный цикл правила описан только через архивацию. \ `PartnerZones.Application/Commands/CancelRule/DeleteDefaultRules/DeleteDefaultCancelRulesCommandHandler.cs:37,43,50-52`, `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:352-357`	Бизнес (Герман)	Open	(А) Подтвердить, что архивация — единственный способ вывести правило из работы, и дописать это в BRD (рекомендуется: соответствует BR2.4.3-5 и текущему коду). (Б) Если удаление нужно партнёру — сформулировать требование отдельно.	вариант а
OQ2.4.3-20	Код BR2.4.3-5	Что подтверждено: признак архивации действительно деактивирует правило отмены. У правила хранятся признак архивности и дата архивации, есть команды архивации и восстановления, а главное — архивные правила исключены из подбора во всех сценариях: в пакетном, в двух одиночных, при отборе правил по умолчанию для сферы и в списочной выдаче. \ `PartnerZones.Domain/CancelRuleAggregate/CancelRuleAggregate.cs:158-178` (архивация/восстановление), `PartnerZones.Persistence/CancelRules/Models/CancelRule.cs:90-97` (хранение), `PartnerZones.Persistence/CancelRules/CancelRuleRepository.cs:179,232,280,37,53,70` (исключение из подбора), `CancelRuleReadOnlyRepository.cs:33`	—	Подтверждено	Расхождения нет. Побочно: в отдельной команде архивации ветка «уже архивно» недостижима, так как правило загружается с фильтром по неархивным и раньше падает с «не найдено» — косметика, на требование не влияет (`ArchiveCancelRuleCommandHandler.cs:18-23`).	Подтверждено: архивные правила исключены из подбора. Есть только косметический дефект с недостижимой проверкой «уже архивно».

BRD

Explorer