# Техническое задание битриксологу: доработка воронки «Дни рождения» по результатам пилотной реализации «B2C мероприятия»

Версия: 1.0  
Дата: 13.08.2026  
Заказчик: Парк Сказка  
Портал: `https://portal.parkskazka.com`  
Тип установки: коробочный Bitrix24  
Целевая воронка: `Дни рождения`, Category ID `1`  
Референс: `B2C мероприятия`, Category ID `10`  

## 1. Назначение документа

Требуется доработать действующую воронку `Дни рождения`, используя подтверждённые решения и ошибки пилотной реализации `B2C мероприятия`. Работы выполняются без потери действующих источников, связей, истории, активных сделок и интеграционных идентификаторов.

Это не разрешение на немедленную перестройку production. Сначала исполнитель обязан подготовить доказательный снимок `as-is`, реестр потребителей и план миграции. Конфигурационные изменения выполняются только после письменной приёмки этих материалов владельцем процесса.

## 2. Цель

Получить управляемую воронку продаж дней рождения, в которой:

- коммерческие стадии отделены от календарных контрольных точек;
- одна сделка соответствует одному мероприятию;
- сохраняются все текущие источники и входящие маршруты;
- обязательные данные контролируются на переходах;
- источник, UTM, звонок, переписка и исходный Лид трассируются до сделки;
- предложение, смета, бронь и оплата имеют собственные подтверждаемые состояния;
- повторный вызов интеграции не создаёт дубль;
- подготовка мероприятия запускается только после подтверждённой предоплаты;
- существующие активные сделки остаются доступными и корректными;
- отчётность использует даты бизнес-событий, а не календарные стадии.

## 3. Неприкосновенные границы

Без отдельного согласования запрещено:

1. Удалять или переименовывать действующие источники, значения справочников и их XML_ID/STATUS_ID.
2. Отключать формы, телефонию, открытые линии, мессенджеры, REST-приложения, webhooks и интеграции.
3. Менять текущий маршрут входящего обращения до успешного source-by-source UAT.
4. Удалять поля, даже если они выглядят дублями, до реестра всех потребителей.
5. Массово переносить активные сделки без dry-run, таблицы соответствия и сверки до/после.
6. Изменять ядро `/bitrix`; допустимы штатная настройка, локальный модуль или расширение в `/local`.
7. Включать клиентские SMS, e-mail или сообщения без утверждённых шаблонов, согласий и теста получателей.
8. Считать стадию сделки подтверждением оплаты.
9. Сопоставлять Контакты или сделки только по имени.
10. Включать реальный серверный B2C-шлюз `parkskazka.b2cgateway`: текущий безопасный статус `enabled=N`, `uat_only=Y` должен сохраниться.

## 4. Подтверждённое исходное состояние

### 4.1. Среда

На 13.08.2026 подтверждены версии:

- main `26.600.0`;
- CRM `26.500.100`;
- bizproc `26.700.0`;
- bizprocdesigner `26.300.0`;
- REST `26.400.200`;
- PHP `8.2.30`.

Перед разработкой исполнитель повторно фиксирует версии и отмечает расхождения.

### 4.2. Воронка «Дни рождения»

На исходном аудите обнаружены рабочие стадии:

1. Новая.
2. В работе.
3. Сделано предложение.
4. Ожидание предоплаты.
5. Внесена предоплата.
6. 4 дня до банкета.
7. 1 день до банкета.
8. Банкет начался.

Финалы:

- Сделка успешна;
- Сделка проиграна, без ПО;
- Сделка проиграна, была ПО, возврат.

Проблемы исходной модели:

- коммерческие этапы смешаны с датами `4 дня` и `1 день` до мероприятия;
- в карточке есть полезные поля, но присутствуют дубли процента предоплаты и ссылки ЮKassa;
- в ожидании предоплаты видны отключённые роботы получения информации об оплате и смены стадии;
- используются уведомления, дела, звонки, смена стадий, SMS и создание элемента смарт-процесса;
- в воронке есть активные сделки, поэтому изменение схемы несёт production-риск.

### 4.3. Видимые интеграции

В портале обнаружены компоненты:

- MANGO OFFICE;
- Wazzup;
- Wappi;
- ЮKassa;
- 1С-коннектор;
- Estimates.guru;
- Tilda и веб-формы;
- NPS;
- смарт-процессы;
- REST-приложения и пользовательские интеграционные поля.

Этот список не считается полным. Факт наличия приложения не доказывает, что конкретный источник подключён к `Дни рождения`. Полный реестр должен быть снят в live-контуре перед изменениями.

## 5. Главный контракт: сохранить все текущие источники

### 5.1. Что считать источником

Источник — не только `SOURCE_ID`. В реестр включаются:

- CRM-источник и описание;
- сайт, домен, URL посадочной страницы, форма и виджет;
- UTM source/medium/campaign/content/term;
- Roistat/Client ID/YCLID/YMCLID/Visitor ID и рекламные идентификаторы;
- номер входа, линия, ID звонка, запись и результат перевода;
- открытая линия, мессенджер, чат и ID диалога;
- ручное создание и импорт;
- исходный Лид и его `LEAD_ID`;
- `ORIGINATOR_ID`, `ORIGIN_ID` и внешний ID;
- REST-приложение, webhook или бизнес-процесс, создавший/изменивший сущность;
- Контакт, Компания, дела, товары, файлы, платежи и связанные смарт-процессы.

### 5.2. Обязательная инвентаризация

До первой конфигурационной записи исполнитель формирует таблицу:

| Поле | Требование |
|---|---|
| Источник/канал | Человекочитаемое название и технический ID |
| Точка входа | Форма, номер, линия, чат, приложение или ручной путь |
| Событие | Что создаёт Лид/Контакт/Сделку и в какой последовательности |
| Условия маршрута | Значения полей, статусы, категории и фильтры |
| Маппинг | Поле источника → поле Лида → Контакта → Сделки |
| Дедупликация | Ключ, порядок поиска, блокировка и поведение повтора |
| Роботы/БП | ID, стадия, условие, задержка, получатель, действие |
| Ответственный | Владелец бизнеса и технический владелец |
| Журнал | Где фиксируются успех, повтор и ошибка |
| UAT | Синтетический сценарий и ожидаемый результат |
| Откат | Как вернуть старый маршрут без потери новых обращений |

### 5.3. Сохранение исходных значений

- `SOURCE_ID`, `SOURCE_DESCRIPTION` и UTM копируются без нормализации на лету.
- First-touch значения не перезаписываются последующими касаниями.
- Last meaningful touch хранится отдельно.
- Технические ID не подменяются отображаемым названием.
- `LEAD_ID` является основной системной связью конверсии.
- Резервный ключ — `ORIGINATOR_ID + ORIGIN_ID`; он не заменяет `LEAD_ID`.
- Телефон и e-mail остаются мастер-данными Контакта.
- Старые поля не удаляются: при необходимости они переводятся в режим legacy/read-only после проверки потребителей.

### 5.4. Definition of Done по источникам

Для каждого реально подключённого источника отдельный синтетический тест обязан доказать:

1. обращение принято ровно один раз;
2. сохранены источник, детали, UTM и технический ID;
3. связан правильный Контакт без дубля по имени;
4. создана или переиспользована ровно одна сделка;
5. исходный Лид и коммуникация доступны в истории;
6. ответственный назначен по действующему правилу;
7. повторная доставка события не создаёт дубль;
8. ошибка видна в журнале и имеет безопасный retry;
9. старый production-маршрут не потерял обращения;
10. удаление синтетических сущностей выполнено по строгому маркеру.

До прохождения всех подключённых источников переключение production запрещено.

## 6. Целевая модель стадий

Рекомендуется привести `Дни рождения` к проверенной логике `B2C мероприятия`. Точные физические STATUS_ID и таблица переноса утверждаются после снимка `as-is`; существующие ID нельзя менять по предположению.

### 6.1. Продажа

1. Новая сделка.
2. Первичный контакт.
3. Предварительный бриф.
4. Подготовка предложения.
5. Предложение отправлено.
6. Получение обратной связи.
7. Переговоры и корректировка.
8. Финальная смета согласована.

### 6.2. Резерв и оплата

9. Бронирование даты.
10. Счёт / ссылка на оплату отправлены.
11. Ожидание оплаты.
12. Предоплата получена.

### 6.3. Проведение

13. Подготовка мероприятия.
14. Готовность подтверждена.
15. Монтаж.
16. Мероприятие проводится.
17. Мероприятие завершено.

### 6.4. Закрытие

18. Закрывающие документы.
19. Контроль качества / NPS.
20. Успешно реализовано.

### 6.5. Отрицательные финалы

1. Проиграно до предложения.
2. Проиграно после предложения.
3. Отменено после оплаты / возврат.
4. Отложенный спрос.
5. Техническое закрытие.

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

### 6.6. Замена календарных стадий

Стадии `4 дня до банкета` и `1 день до банкета` после миграции новых сделок не используются как коммерческие статусы. Их функции переносятся в:

- роботы относительно даты/времени мероприятия;
- дела ответственным;
- контрольные поля готовности;
- эскалации при критическом блокере;
- связанные процессы служб.

Существующие активные сделки в этих стадиях не перемещаются массово до утверждённой таблицы соответствия.

## 7. Таблица соответствия старых и новых стадий

Исполнитель обязан подготовить приложение со следующими колонками:

| Старый STATUS_ID | Старое название | Число активных | Целевая стадия | Условие выбора | Роботы-потребители | Отчёты-потребители | Откат |
|---|---|---:|---|---|---|---|---|

Допустимые предварительные гипотезы, которые нужно подтвердить по данным:

- `Новая` → `Новая сделка`;
- `В работе` → одна из стадий 2–4 по заполненности и последней коммуникации;
- `Сделано предложение` → 5–7 по фактической истории;
- `Ожидание предоплаты` → 9–11 по броне и отправленному документу;
- `Внесена предоплата` → 12 либо 13 по наличию формализованной передачи;
- `4 дня до банкета` / `1 день до банкета` → 13–14 по готовности, но не автоматически только по названию;
- `Банкет начался` → 16, если старт подтверждён;
- финалы сопоставляются по фактической оплате, возврату и причине.

Ни одно сопоставление не выполняется только по названию стадии.

## 8. Карточка сделки

Целевая карточка строится по референсу B2C: 18 физических секций, 119 полей, без копирования нерелевантных HR/СБ-полей. Перед применением к Category ID `1` требуется отдельный аудит заполненности и потребителей каждого текущего CID.

### 8.1. Логические группы

1. Общая информация о сделке.
2. Общая информация о клиенте.
3. Квалификация и передача из лида.
4. Маркетинг и источники.
5. Данные по мероприятию.
6. Гости и особенности аудитории.
7. Локация и бронирование.
8. Питание.
9. Программа и дополнительные услуги.
10. Техника и логистика.
11. Коммерческие условия.
12. КП, сметы и документы.
13. Оплата и финансы.
14. Организация и готовность.
15. Изменения, риски и инциденты.
16. Закрытие, причины потери и NPS.
17. Служебные поля интеграций.

Допускается 18-я физическая секция для системных/товарных элементов формы.

### 8.2. Мастер-данные

- Контакт: Ф.И.О., телефон, e-mail, предпочтительный канал, согласия.
- Сделка: конкретное мероприятие, коммерческий результат, бронь, оплата, сводная готовность.
- Товарные позиции/смета: повторяемые услуги и расчёты.
- Смарт-процессы: детальное исполнение служб.
- Интеграционный журнал: техническое состояние без секретов и ПДн.

### 8.3. Дубли полей

Обязателен отдельный реестр по группам:

- дата и время мероприятия;
- локация и бронь;
- предоплата и процент;
- ссылка и ID ЮKassa;
- Roistat/атрибуция;
- Ф.И.О. и телефон заказчика;
- статус оплаты;
- причина отмены.

Для каждого дубля указать CID, тип, заполненность, роботов/БП/REST-потребителей, мастер-поле, режим legacy и план миграции. Удаление в рамках первого релиза не выполнять.

## 9. Обязательность по стадиям

Использовать проверенный принцип B2C: обязательность включается на контрольном рубеже и продолжается только по успешному маршруту. Отрицательные финалы не должны наследовать поля будущих успешных стадий.

Минимальная матрица:

| Переход/зона | Обязательные данные |
|---|---|
| Первичный контакт | Контакт, ответственный, источник, канал/точка входа, следующий шаг |
| Предварительный бриф | Резюме, результат контакта, предпочтительный канал |
| Подготовка предложения | Тип, дата/диапазон, взрослые, дети, локации, услуги и пожелания |
| Предложение отправлено | Сумма, версия, ссылка/файл, дата и канал отправки |
| Финальная смета | Гости, время, локация, финальная сумма и состав услуг |
| Счёт / ссылка | Бронь, резерв до, плательщик, сумма и процент предоплаты |
| Предоплата получена | Статус, факт, дата и доверенный источник подтверждения |
| Подготовка мероприятия | Организатор и формализованная передача |
| Готовность подтверждена | Сводный статус и отсутствие критического блокера |
| Контроль качества / NPS | Финансовая сверка |
| Любой отрицательный финал | Нормализованная причина и комментарий по условию |

Нельзя требовать интеграционный ID до фактического подключения источника, иначе менеджер будет вводить фиктивные значения.

## 10. Роботы и бизнес-процессы

### 10.1. Обязательный аудит до копирования

Для каждого существующего робота `Дней рождения` зафиксировать:

- внутренний ID;
- стадия и условие;
- задержка и база отсчёта;
- отправитель и получатель;
- изменение полей/стадии;
- внешнее сообщение;
- зависимые CID и шаблоны;
- действие при повторе;
- журнал и ошибка;
- фактическая активность;
- тестовый сценарий;
- решение: сохранить, изменить, заменить, вывести после миграции.

Отключённый робот также входит в реестр.

### 10.2. Безопасный внутренний пакет

В B2C подтверждены 11 внутренних уведомлений ответственному:

- создание сделки;
- вход в предварительный бриф;
- follow-up после предложения через 2 часа, 1, 2 и 4 дня;
- немедленная проверка брони;
- немедленная проверка оплаты;
- предоплата получена;
- мероприятие завершено;
- финансовая сверка / NPS.

Их можно использовать как шаблон только после сверки получателя, календаря, часового пояса и условий остановки. Уведомления не должны сами писать клиенту или подтверждать оплату.

### 10.3. Внешние коммуникации

SMS, Wazzup, Wappi, e-mail и звонки включаются только после:

- инвентаризации текущих шаблонов;
- проверки согласия и допустимого канала;
- теста получателя на синтетическом контакте;
- защиты от повторной отправки;
- отмены отложенного сообщения при ответе/закрытии;
- журнала доставки и ошибки.

## 11. Контракт Лид → Контакт → Сделка

### 11.1. Условия

- Маршрут должен использовать подтверждённый признак направления.
- Связанный Контакт обязателен до автоматической конверсии.
- Контакт переиспользуется; автоматическое слияние по имени запрещено.
- Поиск сделки выполняется до создания.
- Критический ключ: `Category ID + LEAD_ID`.
- Резервный ключ: `Category ID + ORIGINATOR_ID + ORIGIN_ID`.
- После успеха Лид и Сделка содержат взаимно проверяемые ссылки.

### 11.2. Идемпотентная последовательность

1. Получить блокировку по ID Лида.
2. Найти сделку целевой категории по `LEAD_ID`.
3. Если не найдена — проверить `ORIGIN_*`.
4. Если найдена — восстановить обратные ссылки и вернуть `reused`.
5. Если не найдена — выполнить штатную конверсию через product-native механизм.
6. Сохранить `LEAD_ID`, `ORIGIN_*`, Контакт, источник, UTM и поля брифа.
7. Записать ID сделки и дату в Лид.
8. Только после успешной сверки завершить маршрут.
9. Освободить блокировку и записать технический результат без ПДн.

### 11.3. Проверенный вывод B2C

Простое присвоение Лиду статуса `CONVERTED` запрещено: UAT показал риск разрушения системной связи. В B2C рабочим решением стал `LeadConversionWizard` и явное сохранение `LEAD_ID`/`ORIGIN_*`.

Для `Дней рождения` нельзя напрямую переиспользовать код B2C без:

- параметризации Category ID;
- отдельного маршрута и разрешённого статуса;
- source-by-source UAT;
- проверки конфликтов с действующими роботами;
- отдельной команды на включение production.

## 12. Оплата и бронь

- Источник истины по оплате утверждается письменно: ЮKassa, 1С/банк, бухгалтерия или комбинация с приоритетом.
- Менеджер не подтверждает банковскую оплату вручную без разрешённого источника.
- Обрабатываются полная, частичная, неидентифицированная оплата, доплата, возврат и частичный возврат.
- Webhook имеет подпись/проверку, idempotency key, retry и журнал.
- Дублированное событие не меняет сумму повторно и не создаёт второй процесс.
- Резерв содержит ID, локацию, начало, окончание, срок действия, источник проверки и конфликт.
- Истечение резерва создаёт контролируемое действие, но не скрытую потерю сделки.

## 13. Смарт-процессы и проведение

Сделка остаётся мастер-карточкой продажи. После подтверждённой минимальной предоплаты создаются только процессы, соответствующие составу услуг.

Требования:

- единый ключ `Deal ID + тип процесса + версия контракта`;
- повтор не создаёт второй элемент;
- в процесс передаются актуальная версия сметы, дата, время, локация и дедлайн;
- частичная ошибка поддерживает безопасный повтор только отсутствующих элементов;
- обратная ссылка записывается в Сделку;
- критический риск эскалируется;
- T−4/T−1 реализуются делами и контрольными точками, а не стадиями продажи.

В первый релиз не входит полная разработка всех операционных процессов с нуля, если она не согласована отдельной оценкой.

## 14. Права

Целевая матрица:

| Роль | Чтение | Добавление/изменение | Удаление | Импорт/экспорт | Роботы |
|---|---|---|---|---|---|
| Менеджеры b2c | Свои | Свои | Нет | Нет | Чтение |
| РОП | Все | Все | Нет | Нет | Чтение |
| Администратор | Все | Все | Да | По регламенту | Изменение |
| Посторонняя роль | Нет | Нет | Нет | Нет | Нет |

Перед релизом права проверяются из отдельных сессий менеджера, РОП и постороннего пользователя. Административная сессия не заменяет ролевой UAT.

## 15. Миграция активных сделок

### 15.1. По умолчанию

Существующие сделки не переносятся массово. Возможны два безопасных режима:

1. Старые сделки завершаются по прежней схеме, новые поступают в обновлённую.
2. Ограниченная группа активных сделок переносится по утверждённой таблице и после dry-run.

### 15.2. Dry-run

- обезличенные копии или 5–10 разрешённых тестовых карточек;
- сверка стадии, ответственного, Контакта, суммы, товаров, дел, файлов, коммуникаций, источника, UTM, оплаты и смарт-процессов;
- контроль количества до/после;
- повторный запуск без дублей;
- отчёт по каждой ошибке;
- очистка строго по маркеру.

### 15.3. Откат

Откат означает:

- остановить новый маршрут;
- вернуть маршрутизацию входящих источников на зафиксированную старую схему;
- отключить только новые роботы/обработчики;
- не перемещать уже созданные сделки хаотично обратно;
- сохранить журналы и новые обращения;
- выполнить сверку очередей и необработанных событий.

## 16. Этапы работ

### Этап 0. Снимок `as-is`

Результаты:

- экспорт категорий, стадий, форм, полей и обязательности;
- реестр всех источников и маппингов;
- реестр роботов, БП, триггеров, webhooks и REST-приложений;
- агрегированное число активных сделок по стадиям;
- реестр legacy-полей и потребителей;
- backup и план отката;
- контрольные хэши/версии экспортов.

### Этап 1. Проект и маппинг

- таблица старых и новых стадий;
- целевая карточка и мастер-поля;
- матрица обязательности;
- роли и права;
- SLA, оплата, резерв и календарные контрольные точки;
- решение по старым активным сделкам;
- source-by-source программа UAT.

### Этап 2. Тестовая конфигурация

- отдельный тестовый контур или скрытая копия направления;
- стадии, поля, форма и права;
- внутренние уведомления;
- интеграционные обработчики в UAT-only режиме;
- без реального входящего потока и клиентских сообщений.

### Этап 3. UAT

- функциональный маршрут;
- отрицательные финалы;
- обязательность;
- роли;
- каждый текущий источник;
- дубли и повторная доставка;
- оплата и возврат;
- смарт-процессы;
- миграционный dry-run;
- очистка синтетических сущностей.

### Этап 4. Ограниченный пилот

- 2–3 менеджера и РОП;
- ограниченный, но явно перечисленный набор источников;
- ежедневная сверка обращений и ошибок;
- запрет массовой миграции;
- стоп-критерии;
- решение `Go / Extend / Rollback`.

### Этап 5. Production и hypercare

- включение источников по одному;
- контроль входящего количества до/после;
- мониторинг дублей, очередей, оплат и сообщений;
- окно наблюдения не менее 5 рабочих дней;
- передача документации и регламента изменений.

## 17. Приёмочные сценарии

Минимум:

1. Каждый действующий источник создаёт обращение без потери технических меток.
2. Повторное событие каждого источника не создаёт дубль.
3. Контакт не объединяется только по имени.
4. Исходный Лид и коммуникации доступны из Сделки.
5. MANGO сохраняет ID звонка, запись и результат перевода в рамках прав.
6. Wazzup/Wappi сохраняют канал и историю без повторной отправки.
7. Tilda/веб-форма сохраняет URL, UTM, согласие и защиту от спама.
8. Ручное создание требует основание и проверку дубля.
9. Предложение нельзя отправить без суммы и версии.
10. Старые версии сметы не перезаписываются.
11. Follow-up прекращается после ответа или закрытия.
12. Отложенный спрос невозможен без следующей даты.
13. Бронь содержит срок и конфликт.
14. Неподтверждённая оплата не переводит сделку дальше.
15. Платёж ниже порога не запускает подготовку.
16. Дублированный webhook не удваивает оплату и процессы.
17. Возврат переводит сделку в правильный финал с причиной.
18. Смарт-процессы создаются ровно один раз по составу услуг.
19. T−4/T−1 создают дела, но не искажают стадию продажи.
20. Нельзя закрыть успешно без финансовой сверки.
21. Менеджер видит только свои сделки и не удаляет их.
22. РОП видит все сделки и отчётность.
23. Посторонняя роль не имеет доступа.
24. Старые активные сделки, дела, файлы и коммуникации доступны.
25. Все синтетические сущности удалены по маркеру; реальные не затронуты.
26. При откате ни одно новое обращение не потеряно.

## 18. Stop-критерии

Релиз немедленно останавливается, если:

- потерян или подменён источник/UTM;
- создан дубль Контакта или Сделки;
- реальное обращение не дошло до CRM;
- сообщение ушло неправильному получателю;
- оплата подтверждена неподоверенным событием;
- повтор создал второй платёж/процесс;
- посторонняя роль увидела сделку;
- старые активные сделки или история стали недоступны;
- rollback не возвращает входящий маршрут;
- журналы содержат секреты или клиентские данные сверх необходимого.

## 19. Журнал выполненных работ по B2C и выводы для «Дней рождения»

### 19.1. Каркас

- Создана отдельная Category ID `10`.
- Настроены 19 рабочих, одна успешная и пять отрицательных стадий.
- Стадии `Дней рождения` при этом не менялись.

Вывод: доработка активной воронки требует отдельной таблицы миграции и rollback, а не прямого копирования.

### 19.2. Карточка и поля

- Спроектированы 17 логических групп.
- Созданы 34 нормализованных поля Сделки и 7 полей Контакта.
- Форма расширена до 18 секций и 119 полей.
- Legacy-поля сохранены, массовая миграция не выполнялась.

Вывод: сначала назначить мастер-поля и потребителей, затем менять представление; удаление дублей — отдельная миграция.

### 19.3. Обязательность

- Сохранены 25 правил по стадиям.
- Все пять отрицательных финалов требуют причину.
- Булевы поля не удалось сделать обязательными штатным механизмом.
- Значение-зависимая видимость полей в текущей версии штатно недоступна.

Вывод: проектировать контроль с учётом физических ограничений установленной версии, не обещать неподдерживаемую динамику.

### 19.4. Автоматизация

- Настроены 11 внутренних уведомлений.
- Клиентские отправки, платежи и автоматические переходы не включались.
- В лидах сохранены прежние 12 роботов.

Вывод: внутренние напоминания можно выпускать отдельно; внешние действия требуют паспорта интеграции и UAT.

### 19.5. Права

- Использованы роли `Менеджеры b2c` и `РОП`.
- Менеджеры получили свои сделки, РОП — все; удаление/импорт/экспорт закрыты.
- Новую роль не создавали из-за лимита `18/18`.

Вывод: ролевую архитектуру необходимо переиспользовать или консолидировать, а не создавать роль без проверки лимита.

### 19.6. Административный UAT

- Выполнено 30 сценариев: `20 PASS`, `10 BLOCKED`, `0 FAIL`.
- Проверены обязательные рубежи, пять отрицательных финалов и пять базовых уведомлений.
- Синтетическая сделка и Контакт удалены.
- Ролевые сценарии остались `BLOCKED/DEFERRED`.

Вывод: успешный тест администратора не является приёмкой прав менеджера и РОП.

### 19.7. Шлюз Лид → Сделка

- Штатный роботный черновик отклонён: порядок поиска/создания и фильтр Category ID не были доказаны.
- Установлен локальный модуль `parkskazka.b2cgateway 1.1.3`.
- Использованы `LeadConversionWizard`, MySQL named lock, `LEAD_ID` и резервный `ORIGIN_*`.
- UAT подтвердил создание одной сделки, `reused` при повторе и восстановление снятого `LEAD_ID`.

Вывод: конвертация должна быть атомарной и идемпотентной; визуально правдоподобная цепочка роботов без доказанного порядка неприемлема.

### 19.8. Инцидент UAT

- Длинный административный сценарий дважды получил `504`.
- Редактор мог повторно отправить старый текст без явного сохранения.
- Остатки были найдены и удалены только по уникальному строгому маркеру.

Вывод: UAT разбивать на короткие независимые шаги, проверять фактически сохранённый код/настройку и применять уникальный маркер очистки.

### 19.9. Финальное состояние B2C

- Маркерные сделки/лиды/контакты: `0/0/0`.
- Category ID `10`: `0` сделок.
- Модуль: `enabled=N`, `uat_only=Y`.
- Реальный пилот пропущен и не считается пройденным.

Вывод: `Дни рождения` нельзя переключать на B2C-механику на основании лабораторного UAT без source-by-source production-пилота.

## 20. Артефакты исполнителя

Обязательные результаты:

1. `as-is` схема воронки, полей, форм, роботов, БП и прав.
2. Реестр всех подключённых источников и интеграционных паспортов.
3. Карта `старый STATUS_ID → новый STATUS_ID`.
4. Карта `старый CID → мастер-CID → legacy`.
5. Список активных сделок по стадиям без распространения ПДн.
6. Пакет настроек/кода с версией и changelog.
7. Backup и пошаговый rollback.
8. Source-by-source UAT-протокол.
9. Ролевой UAT-протокол.
10. Миграционный dry-run и сверка до/после.
11. Журнал релиза и hypercare.
12. Инструкция менеджеру и администратору.

## 21. Критерии приёмки

Работа принята, когда одновременно выполнено:

- все текущие источники перечислены и прошли тест;
- не потеряны исходные значения источника и UTM;
- нет дублей на повторах;
- старые активные сделки и история доступны;
- календарные стадии заменены контрольными действиями для новых сделок;
- обязательность и отрицательные финалы работают;
- оплата подтверждается только доверенным источником;
- смарт-процессы создаются идемпотентно;
- права подтверждены из отдельных ролей;
- откат проверен;
- нет P0/P1-дефектов;
- пилот имеет формальное решение `Go`;
- владелец процесса письменно разрешил промышленное переключение.

## 22. Не входит в автоматическое разрешение этого ТЗ

- включение реального B2C-шлюза;
- массовая миграция действующих сделок;
- отключение старых источников;
- удаление legacy-полей;
- клиентские рассылки;
- промышленный запуск без отдельного `Go`;
- изменение других воронок;
- хранение токенов, паролей, cookie и платёжных секретов в документации или CRM-полях.

## 23. Исходные проектные материалы

- `outputs/Расширенный план разработки воронки B2C мероприятия — Bitrix24 — 2026-08-13.md`;
- `outputs/bitrix24-b2c-implementation-20260813/implementation-result.md`;
- `field-groups-and-card-spec.md`;
- `phase3-required-fields-matrix.md`;
- `phase4-internal-robots-result.md`;
- `phase5-permissions-result.md`;
- `phase6-uat-execution-result.md`;
- `phase8-commercial-automation-result.md`;
- `phase9-lead-conversion-contract.md`;
- `phase11-server-gateway-result.md`;
- `phase11-server-gateway-uat-result.md`.

Документ не содержит секретов и клиентских персональных данных.