Разделов: 110
Как работает Битрикс
Регламент движения сделки по воронке «Институт»: стадии, роботы, поля карточки и вызовы на наш сервер.
1Как читать этот документ
Документ описывает путь сделки по воронке «Институт» от заявки до оплаты. Каждая стадия — отдельный раздел: сначала что делает менеджер руками и что система делает сама, затем блок-схема, затем роботы по порядку срабатывания. У каждого робота раскрывается, какие поля карточки он читает и заполняет и что уходит на наш сервер.
Коды полей и названия стадий не придуманы: они выгружены напрямую из Битрикса и лежат в репозитории отдельным снимком, по которому документ автоматически сверяется. Если про какой-то факт мы не уверены, так и написано — догадки за факты здесь не выдаются.
2Карта воронки целиком
Как сделка движется по воронке
3Заявка
Первая стадия. Сюда сделка попадает сразу после создания. Здесь система приводит её в порядок и считает все скидки.
3.1Кто и что делает на этой стадии
Менеджер руками
Когда все данные проброшены и условия проверены, менеджер переводит сделку дальше. Если клиент новый, сделка идёт в стадию Данные клиента запрошены. Если данные клиента уже есть в Битриксе, сделка идёт сразу в Подписание документов.
Система сама
Как только сделка создана, система сразу подтягивает данные клиента, придумывает название сделки, проставляет товары, ставит нужную кассу, подтягивает членство, считает все положенные скидки и промокоды и проверяет рассрочку.
3.2Блок-схема
3.3Оформление сделки
3.3.1Откуда пришла заявка и кто ответственный
Заявка попадает в Битрикс двумя путями. Если она пришла с платформы, ответственным в сделке становится АКПП. Если заявка пришла с битрикс-формы, ответственный проставляется тот, что указан в самой форме.
Для технарей
Всю стадию «Заявка» ведёт один большой робот — бизнес-процесс 252 на стадии C4:NEW (docs/b24-bizproc-dump/robots/robot-252-C4_NEW.json). Отдельных роботов на каждый пункт нет, это ветки внутри одного шаблона.
3.3.2Название курса и id товаров в сделку
Система заполняет два служебных поля сделки. В поле Название курса для фильтрации пробрасывается вычищенное название товара — по нему потом удобно искать и фильтровать сделки. В поле id товаров складываются номера всех товаров сделки: поле множественное, каждый номер лежит отдельной строкой, а не через запятую. Перед заполнением поле очищается, поэтому при изменении состава сделки список пересобирается заново.
Поля карточки
поле сделки
UF_CRM_1709028516198Вычищенное название курса без служебных приписок. По нему удобно фильтровать и группировать сделки в отчётах.
поле сделки
UF_CRM_1735786947685Список номеров товаров-мероприятий в сделке (поле множественное). По нему при отчислении проверяется, остались ли у человека другие оплаченные сделки на это же мероприятие: если нет — его снимают и с самого события.
Что уходит на наш сервер
Берём сделку из Битрикса. Работаем только если сделка на стадии C4:NEW и название ещё не проставлено — иначе выходим, ничего не трогая. Берём первый товар сделки, вычищаем из его названия слова «Курс:», «курса », всё после слова «Рассрочка» и дату вида 01-02-2026 в начале. Что осталось — записываем в поле «название» сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/nameДля технарей
Поле id товаров заполняет бизнес-процесс 946 «Записываем id товаров» (docs/b24-bizproc-dump/templates_all.json). Он стоит на автозапуске «при создании и при изменении сделки»: сначала очищает поле UF_CRM_1735786947685, затем перебирает товарные позиции и дописывает номер каждого товара. Это то самое поле, по которому дальше на стадии «Оплачено» ветвятся роботы (например, «id товаров равно 30760 или 34106»).
3.3.3Касса по продавцу курса
У каждого курса есть свой продавец, то есть юрлицо, от которого идут деньги и документы. Система смотрит продавца курса и проставляет в сделку нужную кассу. Именно от кассы зависит, в каком кабинете PayKeeper потом создастся счёт и от кого будут документы. Всего касс шесть: МИР КПТ, АКПП, АКПП cbt1, АКПП cbttour, АКПП becbt и ЦЭК.
Поля карточки
поле сделки
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
Что уходит на наш сервер
По товару сделки находим номер курса, по курсу в нашей базе — продавца потока, по продавцу — кассу, и записываем её в сделку. Выполняется сразу, без очереди.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/set-cashbox-courseДля технарей
Значения поля «Плательщик» (UF_CRM_1681889179) по снимку боевого портала от 20.07.2026: 1136 — МИР КПТ, 1138 — АКПП, 1242 — АКПП cbt1, 1244 — АКПП cbttour, 1246 — АКПП becbt, 2242 — ЦЭК. Юридических лиц по сути три (МИР КПТ, АКПП, ЦЭК), но у АКПП четыре отдельных кабинета PayKeeper — отсюда шесть значений.
3.3.4Признак рассрочки и дата
Если в сделке есть товар со словом «рассрочка» в названии, система ставит в сделке пометку Рассрочка. Отдельно заполняются даты: дата старта первого модуля курса и крайний срок оплаты — старт минус два дня. По этой пометке дальше решается, как формировать документы и когда пойдут следующие платежи.
Поля карточки
поле сделки
UF_CRM_DEAL_1702541356872Как клиент платит: сразу всю сумму или частями. От этого зависит, сколько товаров-платежей будет в сделке.
поле сделки
UF_CRM_1710230487473Дата старта первого модуля курса.
поле сделки
UF_CRM_1710234093549Крайний срок оплаты: дата старта курса минус два дня. Считается автоматически.
Что уходит на наш сервер
Просматриваем названия товаров сделки. Если хотя бы в одном встречается «рассрочк» (в любом падеже и регистре), ставим в сделке признак рассрочки — значение списка 1308. Если такого товара нет, ничего не пишем.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/installment-flagСмотрим товары сделки, по свойствам товара определяем курс и модуль, находим дату старта первого модуля. Записываем в сделку дату старта (в формате 2026-07-20) и дату платежа — это старт минус два дня (в формате 20.07.2026).
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/date-fields3.3.5Чистка служебных товаров
Срабатывает когда в составе сделки есть служебная позиция с номером товара 29476
Иногда в сделку попадает служебный товар, которого там быть не должно. Система убирает его, чтобы сумма и состав сделки были корректными. Если после чистки не осталось ни одной позиции, чистка отменяется — пустой состав в Битрикс не отправляется.
Что уходит на наш сервер
Смотрим состав товаров сделки и выбрасываем служебную позицию с номером товара 29476. Если её нет — ничего не переписываем. Если после чистки не осталось ни одного товара, чистку отменяем и пишем предупреждение в лог — пустой состав в Битрикс не отправляем.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/clean-products3.3.6Бесплатный товар сразу в Оплачено
Срабатывает когда товар бесплатный
Если товар бесплатный, платить нечего. Сделка автоматически переходит сразу в стадию Оплачено, минуя все шаги оплаты, а клиенту уходит уведомление об этом.
3.4Данные клиента
3.4.1Данные клиента в сделку
Система проверяет, есть ли уже такой клиент в Битриксе. Если клиент уже зарегистрирован, его данные подставляются в сделку. Если это новый клиент, система заводит новый контакт и подставляет его данные в сделку. Менеджеру не нужно вносить контакт руками.
3.4.2Членство АКПП клиента
Система заглядывает в платформу becbt и проверяет, является ли клиент действующим членом АКПП. Результат кладётся в карточку контакта. От этого потом зависит, положена ли клиенту скидка члена АКПП.
Поля карточки
поле контакта
UF_CRM_AMO_538621Есть ли у человека действующее членство АКПП. Синхронизируется с платформой; от членства зависят льготные цены.
поле контакта
UF_CRM_1665408442Номер человека на нашей платформе обучения becbt. Ключевая связка «контакт Битрикса ↔ студент платформы»: по нему идёт зачисление, отчисление, перенос, выдача справок и синхронизация членства и почты.
Что уходит на наш сервер
Находим человека в системе becbt (по нашему полю с becbt-номером, при необходимости — по почте), спрашиваем у becbt статус членства и записываем его контакту в Битриксе: 656 — член АКПП, 658 — не член.
Отправляет: Номер контакта. Принимаем под именами CONTACT_ID, contact_id, id; префикс C_ отрезаем.
Роут:
/api/v1/integrations/membership/akpp-sync3.5Скидки и цены
3.5.1Скидка за полный курс
Срабатывает когда курс не в рассрочку и у курса задана скидка за полный курс
Если клиент берёт курс целиком, а не в рассрочку, и у курса настроена скидка за полный курс, система применяет её к товарам. Сумма сделки и цена товара уменьшаются на процент скидки, а в ленте сделки появляется комментарий, что скидка применена.
Поля карточки
поле сделки
UF_CRM_1707376758296Список скидок, которые уже применены к сделке, в виде текстовых меток (например «14.5%»). Поле множественное. Нужен, чтобы одна и та же скидка не применилась дважды и чтобы правильно расписать её в договоре.
Что уходит на наш сервер
Пересчитываем товарный состав сделки со скидкой на курс. Если робот прислал вместо «Да»/«Нет» неподставленный шаблон, мы сами идём в Битрикс: берём контакт сделки и смотрим его поле членства (656 — член). Если Битрикс недоступен, считаем «не член» и скидку члена не даём.
Отправляет: Номер сделки и признак «член АКПП» в виде слова «Да» или «Нет» (параметр is_member_akpp).
Роут:
/api/v1/integrations/deal/course-discount3.5.2Скидка члена АКПП
Срабатывает когда клиент член АКПП и у курса задана скидка члена
Членам АКПП положена своя скидка. Если у клиента есть членство и у курса такая скидка настроена, она применяется. Если вдобавок действует скидка за полный курс, обе скидки складываются и считаются от базовой цены.
Поля карточки
поле контакта
UF_CRM_AMO_538621Есть ли у человека действующее членство АКПП. Синхронизируется с платформой; от членства зависят льготные цены.
поле сделки
UF_CRM_1707376758296Список скидок, которые уже применены к сделке, в виде текстовых меток (например «14.5%»). Поле множественное. Нужен, чтобы одна и та же скидка не применилась дважды и чтобы правильно расписать её в договоре.
Что уходит на наш сервер
Пересчитываем товарный состав сделки со скидкой на курс. Если робот прислал вместо «Да»/«Нет» неподставленный шаблон, мы сами идём в Битрикс: берём контакт сделки и смотрим его поле членства (656 — член). Если Битрикс недоступен, считаем «не член» и скидку члена не даём.
Отправляет: Номер сделки и признак «член АКПП» в виде слова «Да» или «Нет» (параметр is_member_akpp).
Роут:
/api/v1/integrations/deal/course-discount3.5.3Скидка Т-банка
Срабатывает когда в сделке заполнены виды рассрочек Т-банка
Когда клиент платит через рассрочку Т-банка, банк удерживает свою комиссию. Чтобы клиент не переплачивал, система заранее уменьшает сумму сделки на размер этой комиссии. Процент зависит от выбранного вида рассрочки. Исходная сумма до скидки сохраняется отдельным полем — именно она уходит в банк.
Поля карточки
поле сделки
UF_CRM_1733735071900Конкретная программа рассрочки Т-банка. От неё зависит размер скидки, которую банк удерживает: 6 месяцев — 8,2%, 9 месяцев — 11,4%, 12 месяцев — 14,5%. На эту величину уменьшаются позиции сделки.
поле сделки
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
поле сделки
UF_CRM_1734352839672Сумма сделки ДО скидки Т-банка. Позиции сделки к моменту отправки заявки в банк уже уменьшены на скидку, поэтому в банк уходит именно эта, исходная сумма — иначе клиент заплатит меньше положенного.
поле сделки
UF_CRM_1687847636Отметка, что скидка по сделке уже посчитана и повторно её применять не нужно. Без неё повторный запуск робота уменьшил бы сумму второй раз.
Что уходит на наш сервер
Пересчитываем состав сделки с удорожанием/скидкой по выбранной программе рассрочки Т-банка (8,2%, 11,4% или 14,5%) и записываем результат в поля сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/tbank-discount3.5.4Промокод
Срабатывает когда в сделке заполнен промокод
Клиент сам вписывает промокод в форму при заявке. Система берёт этот промокод из сделки, проверяет его по справочнику промокодов и применяет заложенную в него скидку.
Поля карточки
поле сделки
UF_CRM_637D4125F2927Промокод, который ввёл клиент. Проверяется по справочнику промокодов: магазин, процент или сумма скидки, ограничение по числу применений и по курсам.
Что уходит на наш сервер
Читаем промокод из сделки, проверяем его и, если он подходит, применяем к составу товаров. В ответе возвращаем статус — что именно произошло с промокодом.
Отправляет: Номер сделки (промокод берётся из поля сделки).
Роут:
/api/v1/integrations/deal/promo-code4Данные клиента запрошены
Сюда сделку переводит менеджер, когда клиент новый. Система разбирается с ответственным и через 10 минут отправляет клиенту письмо со ссылкой на анкету.
4.1Кто и что делает на этой стадии
Менеджер руками
Менеджер переводит сюда сделку по новому клиенту и ждёт, пока тот заполнит анкету. Дальше сделка уходит на следующую стадию сама, руками её двигать не нужно.
Система сама
Система проверяет ответственного по сделке, через 10 минут отправляет клиенту на почту письмо со ссылкой на анкету и подробной инструкцией, забирает заполненную анкету в Битрикс, отправляет данные на проверку ИИ и сама переводит сделку в стадию Проверка данных клиента.
4.2Блок-схема
4.3Оформление сделки
4.3.1Проверка ответственного
Как только сделка попадает на стадию, система смотрит, кто её сюда перевёл. Если сделку перевёл тот же менеджер, который уже был ответственным, ответственный не меняется. Если сделку перевёл другой менеджер, ответственным становится он.
4.4Письма и уведомления
4.4.1Письмо клиенту со ссылкой на анкету
Через 10 минут после перехода на стадию клиенту на почту уходит письмо со ссылкой на анкету для заполнения и подробной инструкцией, что и как в ней заполнять.
4.4.2Уведомление
Ответственному менеджеру приходит уведомление о том, что появилась новая заявка, со ссылкой на сделку.
4.5Данные клиента
4.5.1Заполненная анкета и автопереход
После того как клиент заполнит анкету и нажмёт отправить, данные подтягиваются в Битрикс и уходят на проверку ИИ. Сделка при этом автоматически переходит в стадию Проверка данных клиента, менеджеру двигать её не нужно.
4.6Скидки и цены
4.6.1Для Т банка
Срабатывает когда поле Виды рассрочек Т банк заполнено или поле Кредит рассрочка Т банк заполнено
Если клиент идёт через рассрочку или кредит Т-банка, система пересчитывает скидку Т-банка, чтобы сумма к моменту документов была верной.
Поля карточки
поле сделки
UF_CRM_1733735071900Конкретная программа рассрочки Т-банка. От неё зависит размер скидки, которую банк удерживает: 6 месяцев — 8,2%, 9 месяцев — 11,4%, 12 месяцев — 14,5%. На эту величину уменьшаются позиции сделки.
поле сделки
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
поле сделки
UF_CRM_1687847636Отметка, что скидка по сделке уже посчитана и повторно её применять не нужно. Без неё повторный запуск робота уменьшил бы сумму второй раз.
Что уходит на наш сервер
Пересчитываем состав сделки с удорожанием/скидкой по выбранной программе рассрочки Т-банка (8,2%, 11,4% или 14,5%) и записываем результат в поля сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/tbank-discount4.7Документы
4.7.1Авто отправка документов
Система запускает автоматическую подготовку и отправку договора по сделке: собирает параметры документа (шаблон, продавец, признак рассрочки) и передаёт их в Битрикс, который формирует и отправляет документ.
Что уходит на наш сервер
Собираем параметры документа (шаблон, продавец, признак рассрочки) по товарам и полям сделки и запускаем в Битриксе бизнес-процесс 270 — он и формирует договор и отправляет его.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/document-sendДля технарей
Сам документ делает бизнес-процесс 270 «Документы на подписание» на стороне Битрикса. Если договор не пришёл — смотреть журнал этого бизнес-процесса, а не наши логи.
4.7.2Исходящий Вебхук дипломы
Система забирает загруженные клиентом дипломы, переводит их в картинки и отправляет на проверку искусственному интеллекту. Результат записывается в сделку: диплом подтверждён или нет, плюс комментарий в ленте.
Поля карточки
UF_CRM_1729519052401Чем закончилась автоматическая проверка диплома искусственным интеллектом. По результату сделка либо идёт дальше, либо возвращается менеджеру на ручной разбор.
Что уходит на наш сервер
Запускаем бизнес-процесс 894 — он копирует файлы дипломов на Битрикс.Диск. Затем скачиваем и распаковываем архивы, переводим PDF в картинки, отправляем их на проверку в becbt и записываем результат в сделку: 2180 — диплом подтверждён, 2184 — нет. Плюс пишем комментарий.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/parsing-diplomДля технарей
Копированием файлов из сделки на Битрикс.Диск занимается бизнес-процесс 894 «Переносим файлы из сделки в диск», его запускает наш обработчик.
5Тестовая
Служебная стадия-отстойник для тестовых и проверочных сделок. Всё, что сюда положили, выпадает из выручки и из отчётов.
5.1Кто и что делает на этой стадии
Менеджер руками
Менеджер, тестировщик или разработчик переводит сюда сделку, которую завели для проверки: пробный платёж, проверка рассрочки, демо-сценарий. Реальных клиентов на эту стадию ставить нельзя — сделка перестанет считаться продажей.
Система сама
Автоматических роботов на стадии нет — она нужна не для действий, а для исключений. Наши сервисы смотрят на код стадии C4:1 и относятся к таким сделкам как к тестовым: они не попадают в дашборд продаж и отчёты по выручке, и к ним не привязываются банковские платежи при сверке выписок.
5.2Оформление сделки
5.2.1Сделка исключается из дашборда продаж и отчётов
Дашборд продаж и отчёты по выручке раскладывают все стадии воронки на «выиграна», «провалена» и «в работе». Стадия Тестовая — единственное исключение из этого правила: сделка на ней помечается как тестовая и не попадает ни в одну метрику. Проверить перед закрытием месяца стоит именно это: если реальную продажу случайно оставили на Тестовой, в выручке её не будет.
Для технарей
Код стадии C4:1. Битрикс помечает её обычной семантикой «в работе» (process) и от рабочих стадий не отличает, поэтому код опознаёт её по самому коду стадии: StageClassifier.php, константа TEST_STAGE_IDS.
5.3Оплата
5.3.1Банковский платёж к такой сделке не привязывается
Когда сверка банковской выписки ищет, к какой сделке отнести пришедший платёж, сделки на стадии Тестовая она пропускает — вместе со сделками из чужих воронок (лиды, заказы) и сделками, у которых в названии стоит «тест», «кролик», «проверка рассрочки», «перевод с курса», «демо», «не трогать». Так живые деньги не приклеиваются к учебной сделке.
Для технарей
DealMatcher.php, метод isTestDeal: стадия C4:1 либо название сделки по списку стоп-слов.
6Проверка данных клиента
Сюда сделка попадает автоматом сразу после заполнения анкеты. Всю анкету и документы клиента проверяет ИИ-агент, менеджер только смотрит вывод и решает.
6.1Кто и что делает на этой стадии
Менеджер руками
Менеджер читает вывод ИИ в таймлайне сделки. Если данные одобрены, он переводит сделку в стадию Подписание документов. Если ИИ ошибся, менеджер проверяет документы сам и одобряет вручную. Если ИИ прав и данные некорректны, менеджер связывается с клиентом, чтобы тот поправил анкету и загрузил верные документы.
Система сама
Вся информация из анкеты и все загруженные документы уходят на проверку ИИ-агенту. Он разбирает документы об образовании, сверяет ФИО, проверяет профориентацию, гособразец диплома, год окончания и срок годности справки об обучении. Результат с подробным ответом пишется в таймлайн сделки.
6.2Блок-схема
6.3Данные клиента
6.3.1Всё уходит на проверку ИИ-агенту
Как только сделка автоматом перешла на эту стадию, ИИ-агенту уходит вся информация из анкеты: все заполненные данные, все документы об образовании, которые загрузил клиент (диплом, повышение квалификации, сертификаты и так далее), подписанное заявление о приёме, лист ознакомления и согласие на обработку персональных данных.
Поля карточки
UF_CRM_1729519052401Чем закончилась автоматическая проверка диплома искусственным интеллектом. По результату сделка либо идёт дальше, либо возвращается менеджеру на ручной разбор.
Что уходит на наш сервер
Запускаем бизнес-процесс 894 — он копирует файлы дипломов на Битрикс.Диск. Затем скачиваем и распаковываем архивы, переводим PDF в картинки, отправляем их на проверку в becbt и записываем результат в сделку: 2180 — диплом подтверждён, 2184 — нет. Плюс пишем комментарий.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/parsing-diplomДля технарей
Проверку запускает тот же вызов, что и на предыдущей стадии: файлы дипломов сначала переносит на Битрикс.Диск бизнес-процесс 894, затем наш обработчик скачивает их, распаковывает архивы, переводит PDF в картинки и отправляет на проверку в becbt.
Собственных активных роботов в дизайнере у стадии C4:UC_Q0J3Q2 не нашлось (docs/b24-funnel-verified-2026-07-15.md: «только служебные выключенные»). Описанные ниже проверки — это шаги одного ИИ-агента, а не отдельные роботы стадии.
6.3.2Разбор документов об образовании
ИИ-агент разбирает пачку загруженных файлов и раскладывает их на две части: отдельно диплом о высшем образовании и отдельно все остальные документы — справки, сертификаты и прочее.
6.3.3Сверка ФИО
ИИ-агент сверяет ФИО, которое клиент ввёл в анкете, с ФИО, указанным в документах. Они должны совпадать.
6.3.4Профориентация документов
ИИ-агент проверяет, что образование клиента относится к психологическому направлению: подходит диплом врача, диплом по психологии или переподготовка по психологии.
6.3.5Диплом государственного образца
ИИ-агент проверяет, что диплом соответствует государственному образцу.
6.3.6Корректный год окончания ВУЗа
ИИ-агент проверяет, что год окончания ВУЗа указан корректно.
6.3.7Справка об обучении не старше месяца
Срабатывает когда клиент прислал справку о том, что ещё учится
Если клиент вместо диплома отправляет справку о том, что он ещё в процессе обучения, ИИ-агент проверяет, что дата выдачи справки не старше месяца с момента выдачи.
6.3.8Вывод ИИ в таймлайне и что делает менеджер
Если все данные заполнены корректно и ИИ их пропускает, менеджер видит в таймлайне сделки, что данные одобрены, и может перевести сделку в стадию Подписание документов. Если ИИ не одобрил данные, но при этом ошибся, менеджер проверяет их вручную, одобряет и тоже ведёт сделку в Подписание документов. Если ИИ отработал верно и данные действительно некорректные, в таймлайне появляется сообщение с подробным ответом ИИ, и менеджер связывается с клиентом, чтобы тот предоставил корректные данные в анкете и загрузил корректные документы.
Поля карточки
UF_CRM_1729519052401Чем закончилась автоматическая проверка диплома искусственным интеллектом. По результату сделка либо идёт дальше, либо возвращается менеджеру на ручной разбор.
7Для менеджера
Ручная рабочая стадия менеджера — и одновременно перевалочный пункт, куда система кладёт технические сделки, пока собирает их состав.
7.1Кто и что делает на этой стадии
Менеджер руками
Менеджер ведёт сделку вручную: связывается с клиентом, уточняет детали и готовит её к следующему шагу. Если менеджер видит здесь сделку с названием вида «донор от сделки #123» или «… (разделение ЧП от сделки 123)» — это не его сделка, а служебная, созданная переносом или разделением заказа. Такие сделки трогать руками не нужно: система сама доведёт их до конечной стадии.
Система сама
Роботов в дизайнере у стадии нет — сверено по выгрузке бизнес-процессов (шаблон 254 на стадии C4:PREPARATION не содержит ни одного внешнего вызова). Зато стадия используется как ПРОМЕЖУТОЧНАЯ двумя нашими операциями. Первая — перенос студента на другой поток: система создаёт сделку-донор сразу на этой стадии, дополняет её товарами, которые остаются за студентом, и только потом переводит донора в Оплачено. Вторая — разделение сделки по акции «Чёрная пятница»: каждая дочерняя сделка тоже сначала создаётся здесь, наполняется своим курсом и суммой, и лишь затем уходит в Оплачено. Поэтому сделка, надолго зависшая на этой стадии с техническим названием, — сигнал, что операция оборвалась на середине.
8Подписание документов
Здесь формируются акт, счёт и договор от нужного юрлица и уходят клиенту, а договор отправляется на электронную подпись в Легиум.
8.1Кто и что делает на этой стадии
Менеджер руками
Менеджер переводит сделку на эту стадию, когда данные клиента собраны и можно оформлять документы.
Система сама
Система проверяет продавца по сделке и плательщика, формирует под них акт и договор, готовит ссылку на Легиум и отправляет клиенту все документы и ссылку на почту и по СМС. Все эти шаги видны в таймлайне сделки. Как только клиент подписал документ в Легиуме, сделка сама уходит в стадию Отправлена на оплату.
8.2Блок-схема
8.3Документы
8.3.1Проверка продавца и покупателя
Первым делом система смотрит, кто продавец по сделке: АКПП, ЦЭК или МИР КПТ. Затем определяет, кто покупатель — по полю «Кто оплачивает»: за курс платит сам студент, оплачивает юридическое лицо или оплачивает другой человек. От этих двух условий зависит, какие именно акт и договор будут сформированы дальше.
Поля карточки
поле сделки
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
поле сделки
UF_CRM_1679212846Галка «за обучение платит организация». Влияет на то, какой шаблон договора собирается клиенту.
поле сделки
UF_CRM_DEAL_1695820568107Галка «платит третья сторона». Тоже меняет комплект и шаблон договора.
Для технарей
Развилка видна прямо в шаблоне бизнес-процесса 898: сначала «Не рассрочка / Рассрочка», внутри — три ветки по продавцу (АКПП, ЦЭК, МИР КПТ), а внутри каждой три ветки по значению поля «Кто оплачивает» (юрлицо, другой человек и «иначе» — сам студент).
8.3.2Отправка акта и счёта
Срабатывает когда определены продавец по сделке (поле «Плательщик»: АКПП, ЦЭК или МИР КПТ) и плательщик (поле «Кто оплачивает»: студент, юрлицо или другой человек); отдельно проверяется, рассрочка это или нет, а для рассрочки — первый это платёж или последний
Система формирует акт и счёт от нужного юрлица: АКПП, ЦЭК или МИР КПТ. Учитывается, кто плательщик: физлицо, юрлицо или другой человек, и рассрочка ли это. В документах верная сумма, налог считается по ставке 5 процентов, подставляется название курса. Готовые документы кладутся на Диск и отправляются клиенту письмом, а на сделке ставится пометка, что акт выслан.
Поля карточки
поле сделки
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
поле сделки
UF_CRM_DEAL_1702541356872Как клиент платит: сразу всю сумму или частями. От этого зависит, сколько товаров-платежей будет в сделке.
поле сделки
UF_CRM_1716101415050Номер документа-акта в генераторе документов Битрикса — его читает бизнес-процесс отправки акта, чтобы отдать нужный файл в Легиум. Раньше поле заполнял бизнес-процесс формирования документов, но после переезда формирования на новый сервис перестал: последняя сделка с непустым полем создана 02.09.2025, дальше пусто на всех сделках. Теперь поле заполняем мы — сами находим акт сделки в генераторе документов перед отправкой.
поле сделки
UF_CRM_1730969289301Отметка, что акт по сделке СФОРМИРОВАН и выслан клиенту на стадии «Подписание документов» — её ставит бизнес-процесс 898 шагом «Помечаем, что выслали акт». Это условие запуска отправки акта после курса, а НЕ отметка о самой отправке. Наш сервис поле не читает и не пишет: у него свой журнал отправок, иначе две системы спорят за одно поле.
Для технарей
Порт бизнес-процесса bp-898. Отдельные шаблоны для АКПП ЮЛ, АКПП ФЛ, АКПП другой человек, ЦЭК, МИР КПТ ЮЛ, МИР КПТ ФЛ, МИР КПТ другой человек, и отдельные для первой и последней рассрочки.
8.3.3Документы на подписание (Легиум)
Срабатывает когда выбран шаблон договора под связку «продавец + тип плательщика» (АКПП ФЛ, АКПП ЮЛ, АКПП сторонний заказчик, МИР КПТ ФЛ, МИР КПТ ЮЛ, МИР КПТ другой заказчик) и определено, обычная это продажа, первая рассрочка, промежуточная или последняя
Система готовит договор и отправляет его в сервис электронной подписи Легиум. Шаблон договора выбирается под юрлицо (АКПП или МИР КПТ) и под тип клиента: физлицо, юрлицо или другой человек, сам студент или сторонний заказчик. ФИО в договоре склоняется в нужный падеж. Готовая ссылка на подпись сохраняется в сделке. Если платит сам студент, договор считается подписанным после первой подписи; если платит юрлицо или другой человек — ждём вторую.
Поля карточки
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
поле сделки
UF_CRM_1713866126499Сколько подписей уже поставлено под договором в сервисе Легиум. Если платит сам студент, хватает одной; если платит юрлицо или другой человек — ждём вторую.
поле сделки
UF_CRM_1679212846Галка «за обучение платит организация». Влияет на то, какой шаблон договора собирается клиенту.
поле сделки
UF_CRM_DEAL_1695820568107Галка «платит третья сторона». Тоже меняет комплект и шаблон договора.
Что уходит на наш сервер
Готовим акт, счёт и договор и запускаем бизнес-процесс 1096. При islast=0 ничего не отправляем сразу, а кладём сделку в очередь ожидания — она уйдёт, когда курс закончится.
Отправляет: Номер сделки; islast — 2 отправить сразу, 1 курс закончился, 0 отложить до окончания курса; folder_id — папка на Битрикс.Диске; type — служебный параметр из шаблона робота.
Роут:
/api/v1/integrations/deal/document-signФормируем договор по сделке, отправляем его в сервис Legium на электронную подпись и возвращаем ссылку на документ (linkDoc).
Отправляет: От активити бизнес-процесса: properties (поля для шаблона документа), document_id вида ["crm","CCrmDocumentDeal","DEAL_123"] и event_token для возврата управления бизнес-процессу.
Роут:
/api/v1/integrations/legium/sendНаходим нашу сделку по адресу документа и отмечаем, что документ подписан. Всегда отвечаем 200 «принято».
Отправляет: Данные Legium: адрес документа (document_url), статус подписи; в адресе — параметр agent.
Роут:
/api/v1/integrations/legium/callbackДля технарей
Порт бизнес-процесса 270 «Документы на подписание». Использует активити «Склонение» для морфологии ФИО. Внутри шаблона видны ветки «Это не рассрочка или первая», «Это последняя рассрочка», «Промежуточная рассрочка» и по одной ветке на каждый шаблон договора.
Раньше в этом месте были описаны два разных вызова с одинаковым адресом /deal/document-sign («на подпись» и «старый обработчик акта и счёта»). Это один и тот же вызов: старый обработчик courses/kinish/action.php перенесён в него же, а поведение переключается параметром islast — 2 отправить сразу, 1 курс закончился, 0 отложить до окончания курса.
8.3.4Подписал в Легиуме — автопереход
Как только клиент подписывает документ в Легиуме, сделка автоматически переходит в стадию Отправлена на оплату. Менеджеру двигать её руками не нужно. Система считает подписи: если платит сам студент, хватает одной; если платит юрлицо или другой человек, ждём вторую.
Поля карточки
поле сделки
UF_CRM_1713866126499Сколько подписей уже поставлено под договором в сервисе Легиум. Если платит сам студент, хватает одной; если платит юрлицо или другой человек — ждём вторую.
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
Что уходит на наш сервер
Находим нашу сделку по адресу документа и отмечаем, что документ подписан. Всегда отвечаем 200 «принято».
Отправляет: Данные Legium: адрес документа (document_url), статус подписи; в адресе — параметр agent.
Роут:
/api/v1/integrations/legium/callbackДля технарей
Ответ Легиума приходит на открытый наружу адрес без пароля: сделка находится по адресу подписанного документа. Легиум хранит только ссылку на документ, самого PDF у него нет — пустая ссылка означает, что документ создался неудачно.
8.4Письма и уведомления
8.4.1Отправка клиенту на почту и по СМС
Система отправляет клиенту все документы и ссылку на Легиум двумя способами сразу: письмом на почту и по СМС. Все эти шаги отображаются в таймлайне сделки, так что менеджер видит, что и когда ушло клиенту.
9Рассрочка
Стадия-метка для сделок в рассрочку. Никакой автоматики за ней не стоит — на движение денег и на рассрочку она не влияет.
9.1Кто и что делает на этой стадии
Менеджер руками
Менеджер может поставить сделку сюда как пометку «эта продажа идёт частями». Больше стадия ничего не даёт: она не создаёт график платежей, не выставляет счета и не запускает списания.
Система сама
Здесь не происходит ничего: роботов в дизайнере нет, ни один бизнес-процесс сделки на эту стадию не переводит и не забирает с неё — во всей выгрузке 68 бизнес-процессов код C4:UC_2QPXBP встречается только в списке возможных вариантов у выпадающего списка стадий, то есть как пункт меню, а не как действие. Настоящая рассрочка живёт в других местах: признак «Рассрочка или полная оплата» в карточке, товары вида «Рассрочка 1/5» в составе сделки и график платежей, который строится на стадии Оплачено. Практический вывод для отчётов: по этой стадии нельзя считать, сколько у нас рассрочек — считать надо по признаку и по товарам.
10Отправлена на оплату
Здесь клиенту создаётся счёт в нужном кабинете PayKeeper и отправляется ссылка на оплату. Это самый большой робот воронки.
10.1Кто и что делает на этой стадии
Менеджер руками
Менеджер переводит сделку на эту стадию, когда пора выставлять счёт.
Система сама
Система определяет плательщика и продавца, применяет скидки и депозит, создаёт счёт в нужном кабинете PayKeeper и отправляет клиенту ссылку на оплату письмом или СМС. Для рассрочки Долями и кредита Т-банка создаются свои ссылки.
10.2Блок-схема
10.3Скидки и цены
10.3.1Скидки и депозит перед оплатой
Срабатывает когда промокод применяется, если поле «Промокод» заполнено; скидка Т-банка — только если поле «Кредит рассрочка Т банк» НЕ пустое; ветка депозита работает, когда в сделке указаны сумма к списанию и источник депозита
Перед созданием счёта система применяет положенные скидки: промокод и скидку Т-банка. Отдельная ветка разбирается с депозитом: проверяет, хватает ли денег на счету клиента, списывает нужную сумму и возвращает номер ветки. Если депозита не хватило, сделка откатывается назад и счёт не выставляется. Если депозит в точности равен сумме сделки (отдельно для обычного и для подарочного), ставится отметка о выдаче первого чека через депозит.
Поля карточки
поле сделки
UF_CRM_637D4125F2927Промокод, который ввёл клиент. Проверяется по справочнику промокодов: магазин, процент или сумма скидки, ограничение по числу применений и по курсам.
поле сделки
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
поле контакта
UF_CRM_1675768976Старый общий счёт депозита клиента, копившийся до разделения по юрлицам. Происхождение денег в нём неизвестно, поэтому новые отчисления сюда БОЛЬШЕ НЕ пишем — теперь депозит копится в поле того юрлица-продавца, с чьего курса отчислили (МИР КПТ/АКПП/ЦЭК). При оплате депозитом это поле всё ещё учитывается и тратится ПЕРВЫМ (вместе с корзиной юрлица сделки), чтобы неоднозначные деньги со временем обнулились. Хранится строкой вида «12000|RUB».
поле контакта
UF_CRM_1755248843058Отдельный счёт клиента для подарочных денег — хранится и списывается независимо от обычного депозита. Используется, когда в сделке выбран источник «Подарочный депозит».
UF_CRM_1751458196Сколько по этой сделке заявлено к списанию с депозита клиента. Если у клиента на счету меньше — сделка откатывается на предыдущую стадию и списание не проходит. Это же число используется в расчёте второго чека и в отчётах.
поле сделки
UF_CRM_1751458372С какого счёта клиента списывать: «битрикс» и «амо» — обычный депозит, «Подарочный депозит» — отдельный подарочный счёт. Без заполненного источника списание не происходит вовсе, даже если сумма указана.
поле сделки
UF_CRM_1714208685879Отметка, что чек на оплату по сделке уже пробит. Пока её нет, второй (зачётный) чек не выдаётся вовсе — батч вторых чеков берёт в работу только сделки с этой отметкой.
Что уходит на наш сервер
Читаем промокод из сделки, проверяем его и, если он подходит, применяем к составу товаров. В ответе возвращаем статус — что именно произошло с промокодом.
Отправляет: Номер сделки (промокод берётся из поля сделки).
Роут:
/api/v1/integrations/deal/promo-codeПересчитываем состав сделки с удорожанием/скидкой по выбранной программе рассрочки Т-банка (8,2%, 11,4% или 14,5%) и записываем результат в поля сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/tbank-discountОпределяем, оплачивается ли сделка депозитом клиента — обычным или подарочным. Списываем депозит и возвращаем бизнес-процессу код ветки: 0, 1, 2 или 3.
Отправляет: От активити бизнес-процесса: document_id и event_token.
Роут:
/api/v1/integrations/paykeeper/activity/deposit-navigatorДля технарей
Ветвление по депозиту сделано на возвращаемом коде активити «навигатор депозита»: 1 — суммы депозита в контакте недостаточно, 2 — сумма депозита равна сумме сделки, 3 — то же для подарочного депозита. Ветки так и подписаны в шаблоне бизнес-процесса 258.
Списание депозита — денежная операция. Повторный запуск может списать повторно, вручную вызов не дёргать.
10.4Оплата
10.4.1Счёт и ссылка на оплату PayKeeper
Срабатывает когда активити проверки курса ответила «Y» (счёт выставлять можно) — если у курса включено «не выставлять счета при заполнении» и мест набрано столько же или больше плана, ветка не выполняется; дальше выбор кабинета идёт по полю «Плательщик», а способ отправки ссылки — по полю «Кто оплачивает»
Система смотрит, кто плательщик и от какого продавца идёт курс, и создаёт счёт в нужном кабинете PayKeeper. Кабинеты разные: МИР КПТ, АКПП, АКПП cbt1, АКПП cbttour, АКПП becbt, ЦЭК, а по умолчанию МИР КПТ. Перед созданием проверяется возможность выставить счёт. Клиенту уходит ссылка на оплату: физлицу почтой, для других случаев письмом или СМС. Если PayKeeper вернул ошибку, приходит уведомление.
Поля карточки
поле сделки
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
Что уходит на наш сервер
Смотрим курс сделки. Если у курса включено «не выставлять счета при заполнении» и мест уже набрано столько же или больше, чем план, возвращаем бизнес-процессу отказ. Иначе — «Y». Ответ уходит в бизнес-процесс отдельным вызовом, а нам достаточно 200.
Отправляет: От активити бизнес-процесса: document_id и event_token.
Роут:
/api/v1/integrations/paykeeper/activity/check-courseОпределяем кассу по продавцу курса и записываем её в сделку, затем отвечаем бизнес-процессу.
Отправляет: От активити бизнес-процесса: document_id и event_token.
Роут:
/api/v1/integrations/paykeeper/activity/change-cashboxСоздаём счёт в PayKeeper и возвращаем в бизнес-процесс две вещи: ссылку на оплату (link_payment) и готовое тело письма (html_page). Используется на стадии «Отправлено на оплату».
Отправляет: От активити бизнес-процесса: properties, document_id и event_token.
Роут:
/api/v1/integrations/paykeeper/activity/payment-linkПо товарам сделки собираем корзину, определяем кассу (из поля сделки либо по продавцу товара), создаём счёт в PayKeeper и возвращаем ссылку на оплату. Повторный вызов новый счёт не создаёт — вернётся already_existed=true.
Отправляет: Номер сделки, номер заказа (orderid), ФИО, почта, телефон плательщика, код кассы (cabinet).
Роут:
/api/v1/integrations/paykeeper/invoice/createДля технарей
Порт бизнес-процесса 258. В шаблоне на каждый кабинет заведена своя ветка — АКПП, МИР КПТ, АКПП cbt1, АКПП cbttour, АКПП becbt, ЦЭК и «По умолчанию (МИР КПТ)». Внутри каждой: «Ссылка заполнена» (активити вернула ссылку на оплату), затем развилка по плательщику «Юрик» / «Другой человек» / «Физик» (последняя — ветка «иначе»), и отдельная ветка «Ошибки заполнены» на случай отказа PayKeeper.
10.4.2Ссылка Долями
Срабатывает когда поле «Кредит рассрочка Т банк» ПУСТОЕ (ветка так и подписана — «проверяем что функционал Т банка не нужен») И проверка курса разрешила выставлять счёт; дальше своя ссылка для кассы АКПП и своя для МИР КПТ
Долями — это запасной вариант оплаты частями, он включается только когда клиент НЕ идёт через Т-банк. Система собирает корзину по товарам сделки, отправляет заказ в Долями и кладёт полученную ссылку в сделку и в ленту. Отказ Долями по делу (например, «сумма меньше 4 ₽» или «позиции отличаются от ранее полученных») — не поломка, а обычный ответ сервиса.
Поля карточки
поле сделки
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
поле сделки
UF_CRM_1763552954942Ссылка на оплату частями через сервис «Долями», которую отправляют клиенту. Формируется нами и кладётся в сделку.
поле сделки
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
Что уходит на наш сервер
Собираем корзину по товарам сделки, отправляем заказ в Долями и возвращаем ссылку на оплату. Ссылку и причину отказа (если она была) пишем в ленту сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/dolami/generate-linkДля технарей
Ветка в бизнес-процессе 258: условие «UF_CRM_1733734965406 = пусто», внутри — ответ активити проверки курса «Y», внутри — кассы АКПП и МИР КПТ с разными адресами (в старой системе это были dolami_akpp/generateLink.php и dolami/generateLink.php).
Долями помнит заказ по номеру сделки: если сумму сделки изменили, повторно создать ссылку не выйдет.
10.4.3Ссылка на кредит или рассрочку Т-банка
Срабатывает когда поле «Кредит рассрочка Т банк» НЕ пустое (ветка «Условие функционал Т банка установлен»); кабинет выбирается по кассе: если «Плательщик» = МИР КПТ — кабинет tbank-mir, во всех прочих случаях — кабинет tbank
Если клиент оформляет кредит или рассрочку Т-банка, система в этой же ветке пересчитывает скидку банка и создаёт ссылку на оформление. В банк уходит полная стоимость сделки до скидки — позиции сделки к этому моменту уже уменьшены на комиссию банка, и если отправить текущую сумму, клиент заплатит меньше положенного.
Поля карточки
поле сделки
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
поле сделки
UF_CRM_1733735071900Конкретная программа рассрочки Т-банка. От неё зависит размер скидки, которую банк удерживает: 6 месяцев — 8,2%, 9 месяцев — 11,4%, 12 месяцев — 14,5%. На эту величину уменьшаются позиции сделки.
поле сделки
UF_CRM_1734352839672Сумма сделки ДО скидки Т-банка. Позиции сделки к моменту отправки заявки в банк уже уменьшены на скидку, поэтому в банк уходит именно эта, исходная сумма — иначе клиент заплатит меньше положенного.
поле сделки
UF_CRM_1733745863620Номер заявки в Т-банке. По нему сделку можно найти в банке.
поле сделки
UF_CRM_1733745901945Ссылка, по которой клиент оформляет рассрочку или кредит в Т-банке.
поле сделки
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
Что уходит на наш сервер
Собираем заявку по составу сделки, отправляем в Т-банк и возвращаем ссылку на оформление рассрочки или кредита.
Отправляет: Номер сделки (deal_id, dealid или id) и код кабинета (cabinet: tbank или tbank-mir).
Роут:
/api/v1/integrations/tbank/generate-linkПересчитываем состав сделки с удорожанием/скидкой по выбранной программе рассрочки Т-банка (8,2%, 11,4% или 14,5%) и записываем результат в поля сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/tbank-discountДля технарей
В шаблоне бизнес-процесса 258 ветка называется «Условие функционал Т банка установлен» (UF_CRM_1733734965406 != пусто). Внутри неё три действия: пересчёт скидки, вложенная развилка «Условие если мир кпт» (касса = МИР КПТ) и ветка «Прочие плательщики» — им соответствуют два кабинета Т-банка.
Отказ Т-банка по делу (сумма вне диапазона 3001–500000 ₽, неполные данные клиента) — это понятная причина, а не сбой.
11Оплачено
Сделка попадает сюда по триггеру оплаты. Это самая насыщенная стадия: студента зачисляют на обучение, выдают доступы и оформляют все документы. Роботов очень много.
11.1Кто и что делает на этой стадии
Менеджер руками
Менеджеру почти не нужно вмешиваться. Он контролирует, что зачисление прошло и документы сформированы.
Система сама
Система зачисляет студента и выдаёт доступ на becbt, выдаёт код доступа к материалам, синхронизирует данные в GetCourse, корректирует остатки по рассрочке, заказывает книги, отправляет письмо об оплате и приглашения, а также запускает сопутствующие бизнес-процессы.
11.2Блок-схема
11.3Зачисление
11.3.1Предоставление доступа на becbt
Главный робот стадии. Система находит или создаёт пользователя на платформе becbt и зачисляет его на купленный курс, семинары и события. Товар с признаком курса — обычное зачисление на поток; товар с признаком мероприятия, но без курса — запись на самостоятельное мероприятие вроде КЭМПа вместе с его частями. Повторный запуск не создаёт дублей: в сделке ставится отметка об обработке.
Поля карточки
свойство товара
PROPERTY_2558Номер курса, к которому относится товар. Главный признак «этот товар — курс»: по нему идёт зачисление, выбирается касса, считается скидка, собирается договор и справка. Внимание: это номер курса в старой базе, а не номер товара.
свойство товара
PROPERTY_2532Номер мероприятия на платформе becbt. Если у товара есть это свойство, но нет номера курса, значит куплено самостоятельное мероприятие (например, КЭМП) — человека записывают прямо на событие. Незаполненное свойство = классическая причина «оплатил, а на мероприятие не записали».
поле сделки
UF_CRM_1705065564103Отметка, что зачисление по сделке уже отработало и повторно запускать не нужно. Ставится в единицу по итогам успешного зачисления.
поле контакта
UF_CRM_1665408442Номер человека на нашей платформе обучения becbt. Ключевая связка «контакт Битрикса ↔ студент платформы»: по нему идёт зачисление, отчисление, перенос, выдача справок и синхронизация членства и почты.
поле сделки
UF_CRM_1666698212Номер курса, на который человека зачислили. Проставляется по итогам зачисления.
поле сделки
UF_CRM_1650797894Когда начинается курс, на который зачислили человека. Заполняется по итогам зачисления.
поле сделки
UF_CRM_1650998820140Когда курс заканчивается. Заполняется при зачислении и используется дальше: по ней отправляется акт об оказании услуг после окончания обучения.
UF_CRM_1680861578День, начиная с которого можно выбивать второй (зачётный) чек — по сути дата окончания обучения. Заполняется при зачислении самой поздней датой окончания среди курсов сделки. Батч берёт сделки, у которых эта дата уже наступила.
поле сделки
UF_CRM_1683218529Отметка, что к сделке добавлены практики (личная терапия, интервизия и подобное), входящие в состав курса.
поле сделки
UF_CRM_1666698260Номер записи рассрочки в нашей базе. Проставляется по итогам зачисления, чтобы связать сделку с графиком платежей.
Что уходит на наш сервер
Ставим задачу в очередь и отвечаем «принято» (202). Дальше разбираем товары сделки: товар с признаком курса (PROPERTY_2558) — обычное зачисление на поток; товар с признаком мероприятия (PROPERTY_2532) без курса — запись на самостоятельное мероприятие вроде КЭМПа, вместе с его частями. Заводим человека в becbt, записываем на курс и мероприятия, создаём записи в нашей базе и проставляем в сделке отметку об обработке.
Отправляет: Номер сделки и номер контакта. Контакт необязателен — если его не прислали, возьмём из самой сделки. Робот стоит на стадии «Сделка успешна» (C4:WON).
Роут:
/api/v1/integrations/enrollment/runДля технарей
Если человека не зачислили на купленное мероприятие — первым делом проверить, заполнено ли у товара свойство мероприятия PROPERTY_2532: без него обработчику не за что зацепиться.
Отдельным бизнес-процессом 864 «Добавить событие на платформе» вызывается тот же самый адрес зачисления.
11.3.2Код доступа институт Бэка
Срабатывает когда в поле «id товаров» есть значение 30760 или 34106
Для двух конкретных товаров института Бэка система выдаёт клиенту персональный код доступа к закрытым материалам: берёт свободный код из общей Google-таблицы, помечает его выданным и записывает в сделку.
Поля карточки
поле сделки
UF_CRM_1735786947685Список номеров товаров-мероприятий в сделке (поле множественное). По нему при отчислении проверяется, остались ли у человека другие оплаченные сделки на это же мероприятие: если нет — его снимают и с самого события.
поле сделки
UF_CRM_1748354994254Персональный код доступа, который выдаётся студенту и складывается в общую таблицу Google. Используется для входа в закрытые материалы.
Что уходит на наш сервер
Берём свободный код из таблицы Google Sheets, помечаем его выданным, записываем код в сделку и запускаем в Битриксе бизнес-процесс 1012 — он отправляет код клиенту.
Отправляет: Номер сделки и номер контакта. Принимаем под именами DEAL_ID/deal_id и CONTACT_ID/contact_id/user_id/USER_ID; префиксы D_ и C_ отрезаем.
Роут:
/api/v1/integrations/access-code/issueДля технарей
Само письмо с кодом отправляет бизнес-процесс 1012 «Подтверждение покупки курса в институте Бэка» — наш обработчик его запускает.
Коды берутся из внешней Google-таблицы: если она недоступна или коды кончились, выдача не пройдёт.
11.3.3Даты события и команда на второй чек
Срабатывает когда номер сделки не равен 2857556 — в роботе стоит исключение по одной конкретной сделке; иных ограничений у робота нет
По товарам сделки система находит мероприятие и его дату окончания, записывает в сделку дату окончания курса и дату отправки второго чека, а также ставит признак «нужен второй чек». Это денежное действие: именно этот признак — команда выбить зачётный чек. Ставить его вручную промежуточным платежам рассрочки нельзя, зачёт задвоится: по всей цепочке рассрочки зачёт бьётся один раз, на последнем платеже.
Поля карточки
свойство товара
PROPERTY_2532Номер мероприятия на платформе becbt. Если у товара есть это свойство, но нет номера курса, значит куплено самостоятельное мероприятие (например, КЭМП) — человека записывают прямо на событие. Незаполненное свойство = классическая причина «оплатил, а на мероприятие не записали».
поле сделки
UF_CRM_1650998820140Когда курс заканчивается. Заполняется при зачислении и используется дальше: по ней отправляется акт об оказании услуг после окончания обучения.
UF_CRM_1680861578День, начиная с которого можно выбивать второй (зачётный) чек — по сути дата окончания обучения. Заполняется при зачислении самой поздней датой окончания среди курсов сделки. Батч берёт сделки, у которых эта дата уже наступила.
поле сделки
UF_CRM_1714136588978Статус второго чека — того самого «зачёта аванса», который выбивается после оказания услуги. Это НЕ способ оплаты и не даты события: по нему батч и отбирает сделки. «Да» ставится при оплате, «Нет» — при отчислении или уходе денег в депозит, «Отменен» — когда зачитывать нечего (пустая корзина). У промежуточного платежа рассрочки («Рассрочка 1/5») отметки нет, и это штатно: по всей цепочке рассрочки зачёт бьётся ОДИН раз, на финальном платеже. Проставить её промежуточным платежам = задвоить зачёт.
поле сделки
UF_CRM_1705065564103Отметка, что зачисление по сделке уже отработало и повторно запускать не нужно. Ставится в единицу по итогам успешного зачисления.
Что уходит на наш сервер
По товарам сделки находим мероприятие и его дату окончания. Записываем в сделку дату окончания курса, дату отправки второго чека (та же дата) и ставим признак «нужен второй чек (зачёт аванса)» в значение 1388 — «Да».
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/event-dates11.3.4Синхронизация в GetCourse
Данные оплаченной сделки и студента уходят на платформу дистанционного обучения GetCourse, чтобы у человека появился доступ к материалам. В сделке ставится отметка о выгрузке — она же защищает от повторной отправки. Если доступ к материалам не открылся, проверять надо на стороне GetCourse.
Поля карточки
поле сделки
UF_CRM_1678350446206Отметка о выгрузке сделки на внешнюю платформу GetCourse. Показывает ход выгрузки и одновременно защищает от повторной отправки.
Что уходит на наш сервер
Передаём данные сделки и студента в систему дистанционного обучения GetCourse, чтобы у человека появился доступ к материалам.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/getcourse-sync11.3.5Заказ книг
Если у купленного курса стоит признак «с книгами», система создаёт отдельную сопутствующую сделку с товарами-книгами в воронке заказов. В исходной сделке ставится отметка, что заказ книг уже создан, — повторный запуск вторую сделку не создаст.
Поля карточки
свойство товара
PROPERTY_4222Признак «товар — это курс» (значение 1). По нему решается, разделять ли сделку в «Чёрную пятницу», создавать ли заказ книг и как назвать позицию в чеке.
поле сделки
UF_CRM_1692781047163Отметка, что по сделке уже создан заказ книг в магазине. Защищает от повторного создания заказа при повторном запуске робота.
Что уходит на наш сервер
Если у купленного курса стоит признак «с книгами», создаём отдельную сопутствующую сделку в воронке 18 с товарами-книгами и ставим в исходной сделке отметку, что заказ книг уже создан.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/order-book11.4Скидки и цены
11.4.1Т-банк скидка для рассрочки после оплаты
Срабатывает когда поле «Кредит рассрочка Т банк» равно значению «Рассрочки Т банк» (2208)
После оплаты для рассрочки Т-банка система ещё раз применяет корректную скидку. Повторно она не сработает: в сделке стоит отметка «Скидка рассчитана?», которая защищает от второго уменьшения суммы.
Поля карточки
поле сделки
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
поле сделки
UF_CRM_1733735071900Конкретная программа рассрочки Т-банка. От неё зависит размер скидки, которую банк удерживает: 6 месяцев — 8,2%, 9 месяцев — 11,4%, 12 месяцев — 14,5%. На эту величину уменьшаются позиции сделки.
поле сделки
UF_CRM_1687847636Отметка, что скидка по сделке уже посчитана и повторно её применять не нужно. Без неё повторный запуск робота уменьшил бы сумму второй раз.
поле сделки
UF_CRM_1707376758296Список скидок, которые уже применены к сделке, в виде текстовых меток (например «14.5%»). Поле множественное. Нужен, чтобы одна и та же скидка не применилась дважды и чтобы правильно расписать её в договоре.
Что уходит на наш сервер
Пересчитываем состав сделки с удорожанием/скидкой по выбранной программе рассрочки Т-банка (8,2%, 11,4% или 14,5%) и записываем результат в поля сделки.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/tbank-discount11.5Оплата
11.5.1Для промежуточных рассрочек
Если в сделке товар вида «Рассрочка 1/5», система собирает график будущих платежей: даты семинаров и товары «Рассрочка 2/5», «Рассрочка 3/5» и так далее — и сохраняет его в нашей базе. Сами сделки-платежи создаются потом, ежедневной задачей по этому графику. Пустой график чаще всего значит, что в сделке нет товаров-рассрочек.
Поля карточки
свойство товара
PROPERTY_2570Номер записи рассрочки. Заполнено = этот товар не сам курс, а один платёж рассрочки. Такие товары обрабатываются отдельно: в чеке они склеиваются в одну позицию на всю сумму курса.
свойство товара
PROPERTY_2680Отметка, что это ПОСЛЕДНИЙ платёж рассрочки (единственное живое значение — «106»). Именно на нём выбивается зачётный чек сразу на всю сумму курса; на промежуточных платежах его нет, и это нормально.
поле сделки
UF_CRM_1666698260Номер записи рассрочки в нашей базе. Проставляется по итогам зачисления, чтобы связать сделку с графиком платежей.
Что уходит на наш сервер
Собираем будущие платежи: даты семинаров и товары «Рассрочка 2/N», «Рассрочка 3/N» и так далее — и сохраняем график в нашу базу. Дальше ежедневная задача сама создаёт сделки-платежи к нужным датам. В ответе — статус и количество строк графика.
Отправляет: Номер сделки с товаром вида «Рассрочка 1/N».
Роут:
/api/v1/integrations/deal/installment-webhook11.5.2Корректировка остатка мест при рассрочке
Срабатывает когда номер сделки не равен 2857550 — в роботе стоит именно такое исключение по одной конкретной сделке; иных ограничений у робота нет
Система уменьшает складской остаток мест по товару, чтобы места не продались дважды. Если куплен первый платёж рассрочки — остаток списывается у головного товара; если куплен обычный товар — у всех рассрочек этого курса. История списаний дописывается в свойство товара. Важно: правится карточка товара, а не сделки, — последствия видят все будущие покупатели курса.
Поля карточки
свойство товара
PROPERTY_2558Номер курса, к которому относится товар. Главный признак «этот товар — курс»: по нему идёт зачисление, выбирается касса, считается скидка, собирается договор и справка. Внимание: это номер курса в старой базе, а не номер товара.
свойство товара
PROPERTY_2570Номер записи рассрочки. Заполнено = этот товар не сам курс, а один платёж рассрочки. Такие товары обрабатываются отдельно: в чеке они склеиваются в одну позицию на всю сумму курса.
свойство товара
PROPERTY_2754Накопительная запись о том, сколько по этому товару уже списано остатков при переносах и отчислениях. Нужна, чтобы одни и те же деньги не списались повторно.
Что уходит на наш сервер
При покупке уменьшаем складской остаток товара в Битриксе. Если куплен первый платёж рассрочки — списываем у головного товара; если куплен обычный товар — списываем у всех рассрочек этого курса. Историю списаний дописываем в свойство товара.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/remains-writeoff11.6Письма и уведомления
11.6.1Письмо об оплате курса
Срабатывает когда поле «Бесплатное мероприятие(сд)» не равно «да» И в поле «id товаров» нет значения 30760 И нет значения 34090
После оплаты клиенту уходит письмо, подтверждающее оплату курса. Два товара из списка исключены: по ним идут свои письма.
Поля карточки
поле сделки
UF_CRM_1735786947685Список номеров товаров-мероприятий в сделке (поле множественное). По нему при отчислении проверяется, остались ли у человека другие оплаченные сделки на это же мероприятие: если нет — его снимают и с самого события.
свойство товара
PROPERTY_2558Номер курса, к которому относится товар. Главный признак «этот товар — курс»: по нему идёт зачисление, выбирается касса, считается скидка, собирается договор и справка. Внимание: это номер курса в старой базе, а не номер товара.
Что уходит на наш сервер
Собираем данные по курсу сделки и запускаем в Битриксе бизнес-процесс 420 — он отправляет клиенту письмо со ссылкой и информацией об оплате.
Отправляет: Номер сделки.
Роут:
/api/v1/integrations/deal/payment-emailДля технарей
Само письмо отправляет бизнес-процесс 420 «Письмо о покупке курса» на стороне Битрикса — наш обработчик только собирает данные по курсу и запускает его. Письмо не пришло — смотреть журнал бизнес-процесса 420.
11.6.2Письма CBT FORUM 2026
Срабатывает когда условие в дизайнере роботов не восстановлено, требует проверки. По скриншотам канбана это четыре отдельных робота — «(ОНЛАЙН)», «(ОНЛАЙН)(Копия)», «(ОЧНО)», «(ОЧНО)(Копия)», — но по какому именно полю или товару они различают формат участия, из выгрузки не видно
Для участников CBT FORUM 2026 система отправляет приглашения в очном и онлайн-форматах, каждое своим письмом.
11.6.3Сообщение в Telegram
Срабатывает когда условие в дизайнере роботов не восстановлено, требует проверки. Робот выполняется приложением [Telegram24], его настройки в выгрузку бизнес-процессов не попадают
По условию система отправляет клиенту сообщение в Telegram. Отправку делает стороннее приложение [Telegram24], установленное в портале, а не наш сервер.
11.7Документы
11.7.1Запуск смарт-процесса Оплата
Срабатывает когда номер сделки не равен 2857550 — в роботе стоит исключение по одной конкретной сделке; иных ограничений у робота нет
Система запускает бизнес-процесс, который заводит по сделке отдельную карточку смарт-процесса «Оплата» — по ней бухгалтерия дальше видит платёж отдельной сущностью.
Для технарей
Шаблон бизнес-процесса 272 «Создаём смарт-процесс "Оплата"», запускается вручную роботом стадии (автозапуска у него нет).
11.7.2Акт на подпись после курса
Срабатывает когда курс закончился и по сделке сформирован акт
Акт — закрывающий документ, он уходит клиенту после того, как курс проведён: на следующий день после последнего дня по дате окончания из сделки. Акт отправляется на электронную подпись, шаблон письма выбирается по юрлицу (МИР КПТ или АКПП) и по тому, кто оплачивает. Отправляем всем, у кого акт сформирован — и физлицам, и юрлицам: документы формируются только если менеджер провёл сделку через стадию «Подписание документов», и это и есть признак, что клиенту они нужны.
Поля карточки
поле сделки
UF_CRM_1716101415050Номер документа-акта в генераторе документов Битрикса — его читает бизнес-процесс отправки акта, чтобы отдать нужный файл в Легиум. Раньше поле заполнял бизнес-процесс формирования документов, но после переезда формирования на новый сервис перестал: последняя сделка с непустым полем создана 02.09.2025, дальше пусто на всех сделках. Теперь поле заполняем мы — сами находим акт сделки в генераторе документов перед отправкой.
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
поле сделки
UF_CRM_1650998820140Когда курс заканчивается. Заполняется при зачислении и используется дальше: по ней отправляется акт об оказании услуг после окончания обучения.
Для технарей
Ожидание окончания курса переехало из Битрикса к нам. Раньше робот стадии «Оплачено» запускал бизнес-процесс 726 сразу после оплаты, а внутри процесса стоял цикл «спать 12 часов, пока дата окончания в будущем». Цикл не отрабатывал: на 22.07.2026 в портале висело 111 живых экземпляров, самый старый — с мая 2024, и у 47 из них курс давно закончился, а акт так и не ушёл. Теперь ждёт наш сервис (PostCourseActSender, ежечасный крон), а бизнес-процесс 726 только отправляет.
Акт ищется напрямую в генераторе документов по сделке (шаблоны актов и УПД всех трёх юрлиц), а не читается из поля «ID акта» — поле с сентября 2025 никто не заполнял. Найденный номер мы в поле записываем, потому что его читает сам бизнес-процесс.
Дедуп — в нашей таблице post_course_act_sends. Поле «Высылался ли до этого акт» для этого не годится: оно означает «акт сформирован» и принадлежит роботам Битрикса.
12Сделка провалена
Конечная стадия несостоявшихся продаж — и одновременно место, где хранится всё непройденное при отчислении. Финансово значимая: именно от неё считаются возвраты и депозиты.
12.1Кто и что делает на этой стадии
Менеджер руками
Менеджер переводит сюда сделку, которая не состоялась, и отмечает причину. Но не каждая сделка на этой стадии — потерянная продажа: сюда же система складывает служебные сделки при отчислении и при разделении заказа. Прежде чем считать «провал», стоит посмотреть на название сделки и на технические метки — они прямо говорят, что это техническая сделка, а не отказ клиента.
Система сама
Автоматических роботов в дизайнере у стадии нет, но сюда попадают сделки, созданные системой в двух случаях. Первый — отчисление студента с курса или с мероприятия: система разрезает оплаченную сделку на две части, пройденное остаётся в исходной сделке-доноре, а всё непройденное уезжает в новую сделку-приёмник (акцептор), созданную сразу на этой стадии. По этой сумме дальше считается, сколько вернуть клиенту деньгами или сколько положить ему на депозит, поэтому такие сделки трогать руками нельзя. Второй — разделение сделки по акции «Чёрная пятница»: после того как из одной покупки успешно создались отдельные сделки по каждому курсу, родительская сделка помечается и переводится сюда, чтобы её сумма не посчиталась в выручке второй раз. Важно: родитель переводится в провал ТОЛЬКО если создана хотя бы одна дочерняя сделка — иначе продажа осталась бы без сделок вовсе.
13Анализ причины провала
Стадия для разбора, почему сделка не состоялась. В отчётах приравнивается к провалу.
13.1Кто и что делает на этой стадии
Менеджер руками
Менеджер переводит сюда сделку, чтобы разобрать причину отказа и учесть её в дальнейшей работе. Это ручное решение — сама система сделки на эту стадию не переводит.
Система сама
Роботов на стадии нет, и ни один бизнес-процесс сюда сделки не отправляет. Для отчётности стадия ведёт себя так же, как «Сделка провалена»: Битрикс помечает её особой семантикой «apology», а дашборд продаж считает такие сделки потерянными. В дашборде банковских платежей стадия подписана как «Не реализовано». Разницу между «Провалена» и «Анализ причины провала» система нигде не различает — она нужна только людям, чтобы отделить разобранные отказы от неразобранных.
14Сквозные процессы
Чеки, депозиты, зачисление и переносы идут поперёк стадий: их нельзя описать в разделе одной стадии, не разорвав на куски. Здесь рядом показаны требование бухгалтерии и то, как система работает на самом деле.
14.1Чеки: первый, второй (зачёт аванса), коррекция и возврат
На каждую оплату выбивается чек в момент прихода денег, а после окончания обучения — второй чек на зачёт аванса; всё, что не успели за сутки, закрывается чеком коррекции.
Когда применяется: Как только по сделке пришли деньги — через кассу PayKeeper, Долями, рассрочку Т-банка или на расчётный счёт. Второй чек — когда поток закончился.
Как это происходит по шагам
Деньги пришли в кассу — выбиваем первый чек
Касса присылает нам уведомление об оплате. Сначала мы спрашиваем саму кассу, не пробила ли она чек сама (у PayKeeper есть автофискализация) — если пробила, мы только ставим отметку в сделке и ничего не печатаем. Если не пробила, печатаем чек по корзине счёта, ставим «Первый чек выдан», дату выдачи и дату фактической оплаты.
Оплата по счёту — отдельный чек «безналичными»
Когда менеджер отмечает в сделке «оплачено через счёт», робот просит нас пробить чек. Перед печатью проверяем, нет ли по этой сделке чека, выбитого другим путём (например, банковской сверкой): если есть — только записываем его номер в сделку.
Оплата Долями — чек по стоимости услуги
Долями присылает уведомление о том, что покупка проведена. Мы проверяем подлинность уведомления (перечитываем статус заказа в самой Долями), пробиваем чек по ценам товаров сделки и записываем номер чека в карточку. Признак расчёта — обычная безналичная предоплата, а не кредит.
Рассрочка/кредит Т-банка — чек с признаком «кредит»
Если в сделке заполнено поле кредита Т-банка, чек выбивается с суммой в графе «кредит». Касса выбирается по продавцу первого товара, по умолчанию — МИР КПТ. После выдачи ставятся те же отметки «первый чек выдан» и дата.
Ставим отметку «нужен второй чек» и дату его выдачи
Первый чек — это аванс: услуга ещё не оказана. Поэтому в сделке взводится галочка «Выдать второй чек» (значение «Да») и дата отправки второго чека — дата окончания потока. Дату проставляет зачисление (берёт самую позднюю дату окончания среди купленных курсов) либо робот дат мероприятия.
Раз в два часа система сама ищет сделки, которым пора выдать второй чек
Батч берёт сделки в стадии «Сделка успешна», у которых стоит «Выдать второй чек = Да», первый чек выдан, второй ещё нет, дата выдачи наступила, сумма сделки не нулевая и не стоит служебная метка отсева. Дальше собирается корзина по всей цепочке связанных сделок (переносы, доноры, акцепторы, рассрочки), считается сумма — и печатается чек с признаком «зачёт аванса».
Отмечаем, что второй чек выслан
После успешной печати в сделке ставится «Выслан второй чек?». Если включена выгрузка PDF, файл чека кладётся в папку Битрикса и в ленту сделки падает комментарий. Ошибка с PDF не отменяет чек — он уже пробит в налоговую.
Возврат денег и чек коррекции
Возврат и коррекция автоматикой не выполняются — это ручные команды администратора по согласованному списку. Чек коррекции пробивается со ссылкой на номер исходного чека (тип «самостоятельная коррекция»), каждый прогон пишется в журнал, повторное гашение одного и того же чека блокируется.
Правила
На выдачу чека есть ровно 24 часа с момента оплаты. Если срок пропущен, выдать чек всё равно обязаны — но уже чеком коррекции, со ссылкой на исходный чек. Даже если прошло два месяца.
Источник: созвон с бухгалтерией 20.07.2026
Признак расчёта в чеке: обычная оплата и Долями — «100% предоплата, безналичными». Рассрочка и кредит Т-банка — «кредит». Долями кредитом не является, это сверено с юристом.
Источник: созвон с бухгалтерией 20.07.2026
Признаки расчёта в коде совпадают с требованием: Долями и оплата счёта уходят как безналичный расчёт, Т-банк — как кредит, второй чек — как зачёт аванса.
Источник: Integration/PayKeeper/ReceiptSumType.php:9-13; DolamiReceiptHandler.php:96; TbankReceiptHandler.php:101; CheckSchetHandler.php:104; IssueFinalReceiptsHandler.php:341
Юридическим лицам, оплатившим на расчётный счёт, чек по законодательству не выдаётся.
Источник: созвон с бухгалтерией 20.07.2026
Банковская сверка выбивает чек по любому уверенно распознанному поступлению, в том числе по платежу юридического лица. Разделение «физлицо / ИП / юрлицо» в коде есть, но оно управляет только галочкой «оплачено через счёт», а не решением печатать чек.
Источник: Domain/Bank/BankReconciler.php:264 (чек пробивается сразу после матча) против BankReconciler.php:512-522 (проверка на физлицо только для галочки); классификация плательщика — BankReconciler.php:669-725
Если платёж не проходил через PayKeeper (ручные переводы, оплаты от иностранцев) — чек не выбиваем.
Источник: созвон с бухгалтерией 20.07.2026
Долями: сумма чека берётся по стоимости услуги, а не по фактически пришедшей от Долями сумме — Долями удерживает свою комиссию, и уменьшать на неё чек нельзя.
Источник: созвон с бухгалтерией 20.07.2026
По Долями система печатает ОДИН чек — по уведомлению о завершённой покупке, на сумму цен товаров сделки. Повторная печать заблокирована тем, что номер чека уже записан в карточку. Сумма по стоимости услуги требованию соответствует.
Источник: Domain/Installment/DolamiNotificationHandler.php:19-31 (чек только на статусе completed); Domain/Payment/DolamiReceiptHandler.php:56-95 (одна печать, гейт по UF_CRM_1764334975153)
СКОЛЬКО ЧЕКОВ ПО ДОЛЯМИ — требует подтверждения бухгалтера. На созвоне 20.07.2026 требование прозвучало дважды и по-разному: сначала «по Долями чек выдаётся на каждый платёж», позже — «по Долями мы получаем все деньги сразу, клиент получает просто один чек». Возражений не прозвучало ни на одну формулировку. Вторая версия совпадает с тем, как устроена сама услуга: рассрочка существует между клиентом и Долями, а нам деньги приходят одной суммой сразу.
Источник: созвон с бухгалтерией 20.07.2026 — две взаимоисключающие формулировки
Второй чек выбивается в дату окончания потока, с признаком «полный расчёт», на сумму СО СКИДКОЙ — ту, что клиент реально заплатил. К личным достижениям студента чек не привязан: если человек не отчислен, он получает чек, даже если ничего не посещал.
Источник: созвон с бухгалтерией 20.07.2026
Дата второго чека берётся из даты окончания курса: зачисление записывает в сделку самую позднюю дату окончания среди купленных курсов.
Источник: Domain/Enrollment/DealWriteBackComposer.php:58-60
Батч вторых чеков идёт раз в два часа, а не один раз в дату окончания. Прогон защищён замком, чтобы ручной запуск и расписание не наложились и не выдали два чека.
Источник: Scheduler/FinalReceiptsSchedule.php:41 (каждые 2 часа); MessageHandler/IssueFinalReceiptsHandler.php:112-119 (замок прогона)
Схема двух чеков действует с 20 декабря 2024 года: сделки, у которых дата второго чека раньше этого дня, батч пропускает. Старый хвост компания закрывать не стала.
Источник: MessageHandler/IssueFinalReceiptsHandler.php:68-74, :173-182
Есть отдельный ограничитель по номеру сделки: батч берёт только сделки новее заданного номера. Без него в обработку попадают около полутора тысяч старых сделок, по которым второй чек давно выбит на старом сервере.
Источник: MessageHandler/IssueFinalReceiptsHandler.php:94-99, :151-155
Если сделка оплачена Долями, цена в чеке поднимается на удержанную комиссию: цена делится на 0,931 (то есть увеличивается на 6,9%). Так чек показывает стоимость услуги, а не сумму, дошедшую до нас.
Источник: MessageHandler/IssueFinalReceiptsHandler.php:58-59, :297, :314
НДС во втором чеке считается по дате ПЕРВОГО чека, а не по сегодняшнему дню: если первый чек выбит до перехода на новую ставку, а зачёт делается после, ставка не должна поменяться задним числом.
Источник: MessageHandler/IssueFinalReceiptsHandler.php:60-61, :298-301, :533-544
Если сделка входит в длинную цепочку переносов и обход упёрся в ограничение глубины, чек НЕ печатается вовсе: часть товаров могла не собраться, а заниженный чек недопустим. Такая сделка ждёт разбора руками.
Источник: MessageHandler/IssueFinalReceiptsHandler.php:251-257
Ничего за прошлые периоды без согласования с бухгалтером. Глубина правок — не больше года назад.
Источник: созвон с бухгалтерией 20.07.2026
Массовые чеки коррекции — прямой риск выездной проверки ФНС. Гасить пачками нельзя, только порциями и по согласованному списку.
Источник: созвон с бухгалтерией 20.07.2026
Пакетные коррекции по умолчанию идут вхолостую (только показывают план). Боевой прогон требует двух явных подтверждений, ограничен размером партии (по умолчанию 10 чеков) и ведёт журнал, чтобы один чек не погасить дважды.
Источник: Command/PayKeeperBulkCorrectionCommand.php:30-41, :51
Правило «24 часа» нигде в системе не отслеживается: нет ни счётчика просрочки, ни сигнала «по этой оплате чек так и не выбит, пора делать коррекцию». Чеки коррекции существуют только как ручная команда администратора.
Источник: поиск по всему коду: коррекция встречается только в ручных командах Command/PayKeeperBulkCorrectionCommand.php и Command/PayKeeperRestoreReceiptCommand.php; автоматической проверки срока нет
Подводные камни
- Если у сделки не заполнена дата ВЫДАЧИ ПЕРВОГО чека, второй чек не выдаётся вообще — батч такие сделки пропускает. Это защита: без первого чека зачитывать нечего.
- Пустая корзина в момент печати второго чека — сделке навсегда ставится служебная метка отсева, и больше она в обработку не попадёт. Метка снимается только руками.
- Галочка «Выдать второй чек» важнее даты: если дата стоит, а галочки нет, чек не выйдет. Промежуточный платёж рассрочки без галочки — это норма, зачёт делается один раз на финальном платеже.
- Дата окончания курса раньше даты оплаты — признак мусора в поле; такие сделки пропускаются с ошибкой в журнале, иначе зачёт уходил бы до оказания услуги.
- Сверять выдачу чеков нужно по кассе, а не по отчёту в интерфейсе: поиск по кассе игнорирует часть фильтров, поэтому любой отфильтрованный отчёт может врать.
14.2Депозиты: обычный и подарочный
Депозит — это деньги клиента, которые лежат у нас: обычный копится при отчислении с курса, подарочный выдаётся акцией; и тем и другим можно оплатить новую покупку.
Когда применяется: Когда студента отчисляют и деньги за непройденное возвращаются не на карту, а на его счёт у нас; и когда клиент оплачивает новую сделку этими деньгами.
Как это происходит по шагам
Депозит появляется при отчислении в депозит
Система обходит оплаченные сделки клиента, делит купленное на пройденное и непройденное. Пройденное остаётся в исходной сделке (она помечается донором), непройденное уезжает в новую сделку в стадии «Сделка провалена», а его стоимость прибавляется к депозиту контакта. Поле депозита накопительное: новое значение = старое + возвращаемая сумма.
Подарочный депозит начисляется отдельно
Подарочный депозит лежит в своём поле контакта и с обычным не смешивается. Это не деньги клиента, а маркетинговый подарок, поэтому и правила по чекам у него другие.
Менеджер указывает в сделке, сколько списать и какой это депозит
В сделке заполняются два поля: сумма к списанию и тип депозита. Коды 2352 и 2354 — обычный депозит, код 2364 — подарочный. По типу система понимает, из какого поля контакта списывать.
Робот-навигатор проверяет депозит и списывает его
Бизнес-процесс Битрикса спрашивает нас, что делать со сделкой, и получает код ветки: 0 — депозита не хватает на всю сделку или он не заявлен, 1 — заявлено больше, чем есть у контакта (в ленту падает предупреждение), 2 — списан обычный депозит, 3 — списан подарочный. Если депозит больше суммы сделки, заявленная сумма подрезается до суммы сделки, и списывается ровно сумма сделки.
Счёт выставляется только на остаток
При выставлении счёта депозит вычитается из суммы сделки, а корзина пересчитывается под остаток. Если депозит покрыл всё, счёт не создаётся вовсе — в журнале пишется «сумма к оплате 0 (покрыто депозитом)». Если у контакта депозита меньше заявленного, счёт не создаётся и возвращается ошибка «недостаточно депозита».
Второй чек по сделке с подарочным депозитом считается по-особому
Если подарочный депозит покрыл сделку целиком, второй чек не выдаётся совсем. Если покрыл частично, остаток (сумма сделки минус депозит) раскладывается равными долями по всем товарам сделки, и чек печатается уже на этот остаток.
Правила
Если человек зачислился на депозит и сразу отчислился, услуг ему не оказали — второй чек не выдаётся вовсе. Чеков на 0 рублей не бывает.
Источник: созвон с бухгалтерией 20.07.2026
Подарочный депозит покрыл сделку целиком — второй чек не выдаётся. Покрыл частично — остаток раскладывается по товарам равными долями.
Источник: созвон с бухгалтерией 20.07.2026
Оба правила по подарочному депозиту реализованы дословно: при полном покрытии сделка пропускается, при частичном каждому товару выставляется цена «(сумма сделки − депозит) / количество товаров».
Источник: MessageHandler/IssueFinalReceiptsHandler.php:201-211 (полное покрытие — пропуск); :454-473 (раскладка остатка равными долями)
Обычный депозит — это настоящие деньги клиента, поэтому услуга отображается на 100%, а не на ноль.
Источник: созвон с бухгалтерией 20.07.2026
Обычный и подарочный депозиты хранятся в разных полях контакта и не смешиваются: тип 2352/2354 списывается из «Депозит клиента», тип 2364 — из «Подарочный депозит».
Источник: Domain/Payment/DepositNavigatorActivity.php:30-35, :115-137; Domain/Payment/DepositApplier.php:17-20, :49
Депозит клиента общий на все наши юридические лица. В карточке контакта это ОДНО поле «Депозит клиента» (и одно поле подарочного депозита) без привязки к организации. Деньги, пришедшие в АКПП, могут быть потрачены на покупку у МИР КПТ или ЦЭК: касса выбирается отдельно, по продавцу товара и кабинету сделки, и с полем депозита никак не связана.
Источник: Domain/Payment/DepositApplier.php:19-20, :49-73 (одно поле на контакт, юрлицо не учитывается); Domain/Payment/DepositNavigatorActivity.php:34-35, :112-137; Domain/CourseOps/Course/CourseDepositRefunder.php:105-106, :326-340 (накопление в то же единственное поле); касса определяется независимо — Domain/Payment/InvoiceCreator.php:84-98
Сделка, полностью оплаченная депозитом, уходит в «Оплачено» с суммой к оплате 0: счёт не выставляется, живых денег в кассу не приходит. В выгрузке для расчёта гонораров такая сделка выглядит как продажа за ноль, и спикер недополучает деньги.
Источник: Domain/Payment/InvoiceCreator.php:100-131 (при полном покрытии счёт не создаётся, возвращается «Сумма к оплате 0 (покрыто депозитом)»); Domain/Payment/DepositApplier.php:57-64 (сумма к списанию 0); Domain/Payment/DepositNavigatorActivity.php:184-194 (ветка «депозит равен сумме сделки» — бизнес-процесс Битрикса двигает сделку в оплату сам)
Депозит начисляется только за непройденное. Пройденные семинары и практики остаются в исходной сделке, и деньги за них не возвращаются: перед расчётом система спрашивает у платформы обучения, что студент реально посетил.
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:199-222 (бюджет пройденного), :481-508, :523-591 (пройден → донор, не пройден → депозит)
Повторное отчисление одного и того же человека депозит не задваивает: сделки, уже помеченные донором отчисления, пропускаются.
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:245-250
Если данные о посещаемости получить не удалось, отчисление в депозит НЕ выполняется: оператор получает понятную ошибку. Иначе система вернула бы больше денег, чем нужно.
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:203-217
Подводные камни
- Если в сделке заявлено больше депозита, чем есть у контакта, счёт не выставится, а в ленту сделки упадёт комментарий «сумма депозита превышает существующий объём».
- Депозит списывается роботом в момент оплаты, а не при заполнении поля: пока сделка не дошла до оплаты, деньги у контакта не тронуты.
- Отчисление в депозит и обычное отчисление — разные операции с разными полями: «отчисление в депозит» ставится только в первой.
- Все операции отчисления и переносов закрыты общим выключателем: при выключенном флаге система ничего не делает и отвечает понятной ошибкой.
14.3Зачисление на курс после оплаты
Как только сделка становится оплаченной, система разбирает купленные товары и записывает человека на курсы, семинары и мероприятия, а результат возвращает в карточку сделки.
Когда применяется: Сделка перешла в стадию «Сделка успешна» (оплачена) — робот Битрикса дёргает зачисление.
Как это происходит по шагам
Робот сообщает нам номер оплаченной сделки
Запуск идёт по стадии оплаты. Номер контакта можно не передавать — если его нет, берём контакт из самой сделки. Одновременный повторный запуск блокируется замком по сделке, иначе человека записали бы на курс дважды.
Разбираем товары сделки
Из сделки берутся товары, у которых заполнен либо номер курса, либо номер события. Свойства товара читаются отдельным запросом к карточке товара — в составе сделки их нет. Товар только с номером события (например, самостоятельный КЭМП) обрабатывается отдельной веткой: человека записывают на мероприятие по цене товара.
Находим человека на платформе обучения
По контакту Битрикса определяется пользователь платформы. Если связь не найдена, зачисление не проходит — это одна из типовых причин «оплатил, а курса нет».
Записываем на курс, семинары и практики
По каждому курс-товару человек записывается на поток, на входящие в него семинары и практики, при необходимости открывается доступ в систему дистанционного обучения. Повторный вызов безопасен: платформа сама глушит «этот участник уже записан».
Возвращаем результат в карточку сделки
В сделку записываются номер курса, номер рассрочки, даты начала и окончания обучения, дата отправки второго чека (самая поздняя дата окончания среди купленных курсов) и отметка, что практики добавлены. Служебная отметка «обработано» ставится в самом конце — после успеха, а не в начале.
Правила
Отметка «обработано» больше не блокирует повторное зачисление. Раньше сделка с этой отметкой давала пустой прогон, и студент, у которого запись на платформу сорвалась, навсегда оставался без курса — пересинки не помогали.
Источник: Domain/Enrollment/EnrollmentOrchestrator.php:24-27, :76-84
От двойного зачисления защищает замок по сделке (на 5 минут), а не отметка: между началом работы и записью отметки проходят десятки секунд обращений к платформе.
Источник: Domain/Enrollment/EnrollmentOrchestrator.php:44-66
Дата отправки второго чека — это дата окончания обучения. Если у сделки несколько курсов, берётся самая поздняя из дат окончания.
Источник: Domain/Enrollment/DealWriteBackComposer.php:34-60
Товар, у которого заполнен только номер события (самостоятельное мероприятие вроде КЭМПа), зачисляется отдельной веткой — как участник мероприятия по цене товара.
Источник: Domain/Enrollment/DealProductParser.php:52-56 (читает номер события из товара); Domain/Enrollment/ProductEnroller.php:102-107, :637-652 (ветка зачисления на самостоятельное событие)
Зачисление напрямую влияет на чеки: именно оно проставляет дату второго чека. Если зачисление не отработало, у сделки не будет даты — и второй чек не выйдет.
Источник: Domain/Enrollment/DealWriteBackComposer.php:58-60 вместе с MessageHandler/IssueFinalReceiptsHandler.php:141-145
Подводные камни
- «Человека не зачислили на купленное событие» — в 9 случаях из 10 у товара не заполнено свойство с номером события или номером курса. Без них товар для зачисления невидим.
- Свойства товара нельзя увидеть в составе сделки: они читаются отдельным запросом к карточке товара. Если товар заведён неправильно, в составе сделки это незаметно.
- Если в списке «Встречи» показывается чужой семинар — значит, поток не нашёлся, и показываются все потоки участника подряд. Это подсказка, а не ошибка данных.
- Ошибка платформы обучения не всегда означает провал зачисления: часть ошибок («участник уже записан») считается допустимой и не помечает прогон неуспешным.
14.4Переносы и отчисления: доноры и акцепторы
Когда студент переходит в другой поток или отчисляется, исходная сделка не переписывается: деньги делятся между «донором» (что остаётся) и «акцептором» (что уезжает).
Когда применяется: Студента переводят на другой поток, отчисляют с курса или с отдельного мероприятия. Операции выполняются из личного кабинета сотрудника.
Как это происходит по шагам
Считаем, что пройдено, а что нет
Система спрашивает у платформы обучения, какие семинары и практики студент реально посетил («Был полностью»). Пройденное деньгами не возвращается и остаётся в исходной сделке; непройденное — предмет переноса или возврата.
Исходная сделка становится базовой и донором
Товары исходной сделки не переписываются — Битрикс не даёт менять уже отгруженные позиции. Вместо этого сделке ставятся метки: «базовая сделка, участвующая в переносе или отчислении», «сделка донор» и, при отчислении, «сделка донор для отчисления». По меткам сделка исключается из отчётов по выручке, чтобы деньги не считались дважды.
Создаётся сделка-акцептор
При переносе акцептор создаётся в стадии «Сделка успешна» и получает переносимые товары нового потока. При отчислении акцептор создаётся в стадии «Сделка провалена» и получает непройденные товары. Акцептор всегда помечается и хранит ссылку на базовую сделку.
Двигаем человека на платформе обучения
При переносе семинара студента отписывают от старого семинара и подписывают на соответствующий семинар нового потока (соответствие ищется по порядковому номеру модуля). При отчислении студента снимают с курса и со всех его мероприятий.
Отчисление с события — отдельная ветка
У мероприятий свои правила: полное отчисление (сделка уходит в «Сделка провалена», человек снимается со всех мероприятий), частичное (снимаются только выбранные мероприятия, их стоимость идёт в депозит) и «только Битрикс» (человека на платформе нет, двигаем одну сделку).
Чеки по цепочке считаются целиком
Второй чек собирается не по одной сделке, а по всей цепочке связанных: базовая, доноры, акцепторы, рассрочки. Если у сделки нашлись «дети», товары самой базовой сделки из чека исключаются — иначе они посчитались бы дважды.
Правила
При отчислении студенту возвращаются деньги и выбивается чек возврата. На уже оказанную часть услуги выбивается второй чек — на эту сумму.
Источник: созвон с бухгалтерией 20.07.2026
Автоматической связки «отчислили → чек возврата» в системе нет: отчисление делит деньги между сделками и начисляет депозит, а чек возврата пробивается отдельной ручной командой администратора.
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:326-399 (депозит и сделки, чек не трогается); Domain/CourseOps/Course/CourseExpeller.php (то же); возврат чека — только Command/PayKeeperBulkCorrectionCommand.php / PayKeeperRestoreReceiptCommand.php
Товары исходной сделки при переносе и отчислении не переписываются: сделка помечается базовой и донором, а непройденное уходит в новую сделку. Битрикс запрещает менять состав уже отгруженных товаров.
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:377-387
Если сделку-акцептор создать не удалось, донора НЕ обрезают: непройденные товары остаются на месте, а в чат уходит тревога. Иначе деньги пропали бы бесследно.
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:356-371
Если студент прошёл все модули, отчисление невозможно — операция отклоняется с понятным объяснением, а не выполняется «на ноль».
Источник: Domain/CourseOps/Course/CourseDepositRefunder.php:319-324
Перенос затрагивает только исходную сделку зачисления, а не все сделки контакта: выбираются товары указанных семинаров, остальное остаётся у донора.
Источник: Domain/CourseOps/Course/CourseTransferrer.php:36-48 (описание алгоритма)
Метка «базовая сделка» — это ещё и метка для отчётности: помеченные сделки исключаются из выручки, чтобы одна покупка не считалась несколько раз.
Источник: Domain/CourseOps/Course/CourseExpeller.php:65 (поле базовой сделки)
Второй чек по сделке, попавшей в перенос, считается по всей цепочке связанных сделок, и товары базовой сделки из него выбрасываются, если у неё нашлись «дети».
Источник: MessageHandler/IssueFinalReceiptsHandler.php:238-276
Двухдневный семинар блокируется к переносу только тогда, когда посещены ВСЕ его дни. Один посещённый день переносу не мешает.
Источник: Domain/CourseOps/Course/CourseTransferrer.php:687-715 (seminarFullyPassed собирает все дни семинара по потоку и названию)
Подводные камни
- Перенос и отчисление ходят в платформу обучения десятками запросов, поэтому выполняются в фоне: интерфейс показывает «выполняется», а результат приходит позже.
- Ошибка платформы обучения не откатывает уже сделанное в Битриксе: депозит и сделки проведены, а сбой платформы только попадает в тревогу — иначе операция зависла бы наполовину выполненной.
- Двойной перенос одного и того же студента отклоняется: сделки, уже помеченные донорами, повторно не обрабатываются, иначе депозит начислился бы дважды.
- У завершённых потоков операции переноса и отчисления доступны — раньше кнопка «Действия» у них пряталась, и исправить ошибку задним числом было нельзя.
- Длинная цепочка переносов может упереться в ограничение глубины обхода — тогда второй чек по такой сделке намеренно не выдаётся и требует разбора руками.
АПриложение А. Справочник полей карточки
Все поля, которые читает или заполняет автоматика: 103 штук. Названия взяты из выгрузки боевого Битрикса, а не написаны по памяти.
Плательщик
UF_CRM_1681889179Юрлицо-продавец по сделке. По нему выбирается касса PayKeeper: у каждого юрлица свой отдельный кабинет, и чек уходит именно туда. Ставится автоматически по свойству «Продавец» товара, а если товаров несколько — по первому подходящему.
Читают: Выставление счёта PayKeeper, Выдача второго чека, Чек по оплате Долями, Чек по оплате через счёт, Сверка банковских выписок, Чек по рассрочке Т-банка
Заполняют: Простановка кассы по курсу, Простановка кассы по сделке, Разделение «Чёрной пятницы»
Дата фактической оплаты
UF_CRM_FACT_PAYMENT_DATEДень, когда клиент реально заплатил деньги — через PayKeeper или по счёту в банке. Специально отдельное поле для отдела продаж: на технические сделки переноса (доноров и акцепторов) и на неоплаченные оно НЕ ставится, поэтому пусто = реальной оплаты не было. Именно по нему считается выручка в дашборде продаж, а не по дате закрытия сделки.
Читают: Дашборд продаж, Отчёты по выручке
Заполняют: Простановка фактической даты оплаты
Первый чек выдан
UF_CRM_1714208685879Отметка, что чек на оплату по сделке уже пробит. Пока её нет, второй (зачётный) чек не выдаётся вовсе — батч вторых чеков берёт в работу только сделки с этой отметкой.
Читают: Выдача второго чека
Заполняют: Обработка оплаты PayKeeper, Чек по рассрочке Т-банка, Уведомление об оплате Долями, Разделение «Чёрной пятницы» (копируется в дочернюю сделку)
Дата выдачи первого чека
UF_CRM_1735290599615Когда был пробит чек на оплату. Ставится вместе с отметкой «Первый чек выдан». Две важные роли: от этой даты считается ставка НДС для второго чека, и без неё второй чек не выдаётся вообще. Пустое поле означает, что чек по сделке нашей схемой не бился и зачитывать нечего — без этой проверки 01.07.2026 батч разом выдал 174 лишних чека по старым сделкам 2023–2025 годов.
Читают: Выдача второго чека, Отчёты по выручке
Заполняют: Обработка оплаты PayKeeper, Чек по рассрочке Т-банка, Уведомление об оплате Долями, Досверка дат оплаты (backfill)
Выдать второй чек
UF_CRM_1714136588978Статус второго чека — того самого «зачёта аванса», который выбивается после оказания услуги. Это НЕ способ оплаты и не даты события: по нему батч и отбирает сделки. «Да» ставится при оплате, «Нет» — при отчислении или уходе денег в депозит, «Отменен» — когда зачитывать нечего (пустая корзина). У промежуточного платежа рассрочки («Рассрочка 1/5») отметки нет, и это штатно: по всей цепочке рассрочки зачёт бьётся ОДИН раз, на финальном платеже. Проставить её промежуточным платежам = задвоить зачёт.
Читают: Выдача второго чека
Заполняют: Обработка оплаты PayKeeper, Уведомление об оплате Долями, Отчисление с курса, Разделение «Чёрной пятницы» (копируется в дочернюю сделку)
Выслан второй чек?
UF_CRM_1653572436574Отметка, что второй (зачётный) чек уже пробит и повторно делать не нужно. Батч исключает такие сделки из выборки; при сборе цепочки рассрочек это же поле работает нашим предохранителем от двойного учёта одних и тех же товаров.
Читают: Выдача второго чека, Сбор цепочки рассрочек
Заполняют: Выдача второго чека, Восстановление чеков PayKeeper (ручная команда)
Дата отправки второго чека
UF_CRM_1680861578День, начиная с которого можно выбивать второй (зачётный) чек — по сути дата окончания обучения. Заполняется при зачислении самой поздней датой окончания среди курсов сделки. Батч берёт сделки, у которых эта дата уже наступила.
Читают: Выдача второго чека
Заполняют: Зачисление на курс
выдать финальный чек для товаров рассрочек
UF_CRM_1756914789945Ручное распоряжение по рассрочке: «2» — финальный чек надо выдать, «1» — уже выдан. Без «2» промежуточные платежи рассрочки просто выбрасываются из чека и в него не попадают.
Читают: Сбор цепочки рассрочек, Выдача второго чека
финальный чек_16 отсев
UF_CRM_1769092273812Одностороннее гашение: помеченная «1» сделка НИКОГДА больше не попадёт в батч вторых чеков. Ставится автоматически, когда при сборе чека корзина оказалась пустой — зачитывать нечего. Снимать метку вручную нельзя без разбора: ей закрыто 1303 сделки.
Читают: Выдача второго чека
Заполняют: Выдача второго чека
оплачено через счет
UF_CRM_1769081546595Отметка, что сделку оплатили по банковскому счёту, а не картой. Ставится сверкой банковской выписки и только физлицу (для ИП ветка другая). Служит гейтом: чек по такой оплате выбивается отдельным обработчиком.
Читают: Чек по оплате через счёт
Заполняют: Сверка банковских выписок
чек по оплате через счет выдан
UF_CRM_1769081566935Отметка, что чек по оплате через банковский счёт уже пробит — повторно делать не нужно.
Читают: Чек по оплате через счёт
Заполняют: Чек по оплате через счёт
ID чек по оплате через счет
UF_CRM_1769088828631Номер выбитого чека в кассе PayKeeper по оплате через банковский счёт. Нужен, чтобы найти чек в кассе.
Заполняют: Чек по оплате через счёт
Полная стоимость сделки
UF_CRM_1734352839672Сумма сделки ДО скидки Т-банка. Позиции сделки к моменту отправки заявки в банк уже уменьшены на скидку, поэтому в банк уходит именно эта, исходная сумма — иначе клиент заплатит меньше положенного.
Читают: Ссылка на рассрочку Т-банка
Заполняют: Расчёт скидки Т-банка
Рассрочка или полная оплата
UF_CRM_DEAL_1702541356872Как клиент платит: сразу всю сумму или частями. От этого зависит, сколько товаров-платежей будет в сделке.
url долями
UF_CRM_1763552954942Ссылка на оплату частями через сервис «Долями», которую отправляют клиенту. Формируется нами и кладётся в сделку.
Заполняют: Генерация ссылки Долями
Оплачен долями
UF_CRM_1763637983893Отметка, что сделку оплатили через «Долями». Влияет на деньги: сервис берёт комиссию 6,9%, поэтому цены позиций в чеке пересчитываются (делятся на 0,931).
Читают: Выдача второго чека, Сборка корзины чека, PDF-чек Долями
Заполняют: Уведомление об оплате Долями
id check paykeeper dolamy
UF_CRM_1764334975153Номер чека в кассе PayKeeper по оплате «Долями». По нему потом забирается PDF чека.
Читают: PDF-чек Долями
Заполняют: Чек по оплате Долями
Возврат по долями
UF_CRM_1764774893687Отметка, что по оплате «Долями» прошёл возврат денег клиенту.
Заполняют: Уведомление об оплате Долями
Кредит рассрочка Т банк
UF_CRM_1733734965406Клиент берёт кредит или рассрочку Т-банка. Заполненное поле работает гейтом: только тогда выбивается чек по Т-банку и в договор подставляются условия банка.
Читают: Чек по рассрочке Т-банка, Отправка договора, Выбор промокода Т-банка
Виды рассрочек Т банк
UF_CRM_1733735071900Конкретная программа рассрочки Т-банка. От неё зависит размер скидки, которую банк удерживает: 6 месяцев — 8,2%, 9 месяцев — 11,4%, 12 месяцев — 14,5%. На эту величину уменьшаются позиции сделки.
Читают: Расчёт скидки Т-банка, Отправка договора, Выбор промокода Т-банка, Чек по рассрочке Т-банка
Т банк id
UF_CRM_1733745863620Номер заявки в Т-банке. По нему сделку можно найти в банке.
Заполняют: Ссылка на рассрочку Т-банка
Т банк link
UF_CRM_1733745901945Ссылка, по которой клиент оформляет рассрочку или кредит в Т-банке.
Заполняют: Ссылка на рассрочку Т-банка
ID рассрочки
UF_CRM_1666698260Номер записи рассрочки в нашей базе. Проставляется по итогам зачисления, чтобы связать сделку с графиком платежей.
Заполняют: Зачисление на курс
Депозит клиента — СТАРОЕ общее поле (унаследованное)
UF_CRM_1675768976Старый общий счёт депозита клиента, копившийся до разделения по юрлицам. Происхождение денег в нём неизвестно, поэтому новые отчисления сюда БОЛЬШЕ НЕ пишем — теперь депозит копится в поле того юрлица-продавца, с чьего курса отчислили (МИР КПТ/АКПП/ЦЭК). При оплате депозитом это поле всё ещё учитывается и тратится ПЕРВЫМ (вместе с корзиной юрлица сделки), чтобы неоднозначные деньги со временем обнулились. Хранится строкой вида «12000|RUB».
Читают: Оплата депозитом, Навигатор депозита (робот)
Заполняют: Оплата депозитом
Депозит клиента — МИР КПТ
UF_CRM_DEP_MIRKPTДепозит клиента по юрлицу МИР КПТ. Пополняется при отчислении с курса/мероприятия, проданного от МИР КПТ (по «Продавцу» сделки), и тратится только при оплате сделок МИР КПТ. Так деньги одного юрлица нельзя потратить как оплату другого. Хранится строкой «сумма|RUB».
Читают: Оплата депозитом, Навигатор депозита (робот)
Заполняют: Оплата депозитом, Отчисление с курса, Отчисление с мероприятия
Депозит клиента — АКПП
UF_CRM_DEP_AKPPДепозит клиента по юрлицу АКПП (все четыре кабинета АКПП сводятся в это одно поле). Пополняется при отчислении с курса/мероприятия АКПП и тратится только при оплате сделок АКПП. Хранится строкой «сумма|RUB».
Читают: Оплата депозитом, Навигатор депозита (робот)
Заполняют: Оплата депозитом, Отчисление с курса, Отчисление с мероприятия
Депозит клиента — ЦЭК
UF_CRM_DEP_CEKДепозит клиента по юрлицу ЦЭК. Пополняется при отчислении с курса/мероприятия ЦЭК и тратится только при оплате сделок ЦЭК. Хранится строкой «сумма|RUB».
Читают: Оплата депозитом, Навигатор депозита (робот)
Заполняют: Оплата депозитом, Отчисление с курса, Отчисление с мероприятия
Подарочный депозит
UF_CRM_1755248843058Отдельный счёт клиента для подарочных денег — хранится и списывается независимо от обычного депозита. Используется, когда в сделке выбран источник «Подарочный депозит».
Читают: Оплата депозитом, Навигатор депозита (робот)
Заполняют: Оплата депозитом
оплачено с депозита
UF_CRM_1751458196Сколько по этой сделке заявлено к списанию с депозита клиента. Если у клиента на счету меньше — сделка откатывается на предыдущую стадию и списание не проходит. Это же число используется в расчёте второго чека и в отчётах.
Читают: Оплата депозитом, Навигатор депозита (робот), Выдача второго чека, Дашборд продаж, Отчёты «Таблицы Леры»
источник депозита
UF_CRM_1751458372С какого счёта клиента списывать: «битрикс» и «амо» — обычный депозит, «Подарочный депозит» — отдельный подарочный счёт. Без заполненного источника списание не происходит вовсе, даже если сумма указана.
Читают: Оплата депозитом, Навигатор депозита (робот), Выдача второго чека
Заполняют: Разделение «Чёрной пятницы» (копируется в дочернюю сделку)
отчисление в депозит
UF_CRM_1755018001330Отметка, что при отчислении деньги ушли не возвратом, а на депозит клиента. Вместе с метками донора и акцептора определяет роль сделки в цепочке при сборе второго чека.
Читают: Выдача второго чека, Сбор цепочки сделок
Заполняют: Возврат на депозит при отчислении
Базовая сделка участвующая в переносе или отчислении
UF_CRM_1751360441579Метка ИСХОДНОЙ сделки — той, с которой человека переносят или отчисляют. Заполнено = сделка участвует в переносе или отчислении и исключается из отчётов по выручке, чтобы деньги не посчитались дважды.
Читают: Выдача второго чека, Сбор цепочки сделок, Вкладка «Встречи» в карточке, Простановка фактической даты оплаты
Заполняют: Перенос на другой поток, Отчисление с курса, Возврат на депозит при отчислении
Сделка донор
UF_CRM_1751360500609Метка технической сделки-донора: с неё списываются остатки товаров, практики в ней свёрнуты. «Донор» — это про списание товаров, а не про человека. На такую сделку не ставится дата фактической оплаты, потому что реальных денег по ней не было.
Читают: Выдача второго чека, Сбор цепочки сделок, Вкладка «Встречи» в карточке, Простановка фактической даты оплаты
Заполняют: Перенос на другой поток, Отчисление с курса, Возврат на депозит при отчислении
id запроса
UF_CRM_1786113298690Номер заявки на участие НАБЛЮДАТЕЛЕМ в итоговой супервизии во внешнем сервисе (сторона Романа Леонтьева). Заполнено = сделкой управляет этот сервис: он бронирует место, а мы ведём деньги. По заполненному полю робот стадии «Сделка провалена» гасит ссылку на оплату — иначе человек оплатит место, которое уже отдали другому. Поле строковое, но наружу мы отдаём его числом.
Читают: Запись наблюдателем на итоговую супервизию, Снятие брони наблюдателя и гашение ссылки на оплату
Заполняют: Внешний сервис заявок (не мы)
Сделка акцептор
UF_CRM_1751360557921Метка технической сделки-приёмника: сюда переносят человека или складывают непройденное при отчислении. Заполнено = сделка создана переносом или отчислением, а не продажей. Дата фактической оплаты на неё не ставится.
Читают: Выдача второго чека, Сбор цепочки сделок, Вкладка «Встречи» в карточке, Простановка фактической даты оплаты
Заполняют: Перенос на другой поток, Отчисление с курса, Возврат на депозит при отчислении
Сделка донор для отчисления
UF_CRM_1751382121194Отдельная метка донора именно для отчисления — не путать с обычной «Сделка донор». По ней сделка попадает в свою ветку расчёта второго чека.
Читают: Выдача второго чека, Сбор цепочки сделок
Заполняют: Отчисление с курса, Перенос на другой поток, Возврат на депозит при отчислении
id базовых сделок для переноса
UF_CRM_1750323700785Список номеров сделок-родителей (поле множественное). У дочерней сделки здесь стоит ссылка наверх — по нему собирается вся цепочка переносов сверху вниз при расчёте второго чека.
Читают: Сбор цепочки сделок, Выдача второго чека
Заполняют: Перенос на другой поток, Отчисление с курса, Возврат на депозит при отчислении
Игнорировать родительскую сделку в момент отчисления
UF_CRM_1750678527377Распоряжение «при отчислении родительскую сделку не трогать». Это указание, что делать, а не отметка «уже обработано» — путать нельзя.
Читают: Отчисление с курса, Сбор цепочки рассрочек
отчисление с события и мероприятия
UF_CRM_1761923569607Метка сделки, созданной отчислением с самостоятельного мероприятия (например, КЭМПа), а не с курса.
Заполняют: Отчисление с мероприятия
id базовой сделки при отчислении с события или мероприятия
UF_CRM_1761923892575Номер исходной сделки, с которой человека отчислили с мероприятия. Связь «приёмник → родитель».
Заполняют: Отчисление с мероприятия
id товаров
UF_CRM_1735786947685Список номеров товаров-мероприятий в сделке (поле множественное). По нему при отчислении проверяется, остались ли у человека другие оплаченные сделки на это же мероприятие: если нет — его снимают и с самого события.
Читают: Отчисление с мероприятия
Заполняют: Отчисление с мероприятия
базовая сделка для разделения по чп
UF_CRM_1760017432848Метка исходной сделки, которую разделили на несколько в акции «Чёрная пятница» (одна покупка = несколько сделок).
айди родительской сделки по чп
UF_CRM_1760019815135Ссылка дочерней сделки «Чёрной пятницы» на родительскую — чтобы понимать, из чего она получилась.
Заполняют: Разделение «Чёрной пятницы»
Сделка была в стадии успеха
UF_CRM_1755004328654На дочерние сделки, созданные разделением «Чёрной пятницы», это поле ставится как признак их происхождения.
Заполняют: Разделение «Чёрной пятницы»
Кто оплачивает
UF_CRM_1713179223134Кто платит за обучение: сам студент, его работодатель-юрлицо или другой человек. От этого зависит и комплект документов (кому уходит акт), и логика подписания: если платит сам студент, договор считается подписанным после первой подписи, иначе ждём вторую.
Читают: Подписание договора (Легиум), Отправка акта после курса
Количество подписей документов
UF_CRM_1713866126499Сколько подписей уже поставлено под договором в сервисе Легиум. Если платит сам студент, хватает одной; если платит юрлицо или другой человек — ждём вторую.
Читают: Подписание договора (Легиум)
Заполняют: Подписание договора (Легиум)
ID акта
UF_CRM_1716101415050Номер документа-акта в генераторе документов Битрикса — его читает бизнес-процесс отправки акта, чтобы отдать нужный файл в Легиум. Раньше поле заполнял бизнес-процесс формирования документов, но после переезда формирования на новый сервис перестал: последняя сделка с непустым полем создана 02.09.2025, дальше пусто на всех сделках. Теперь поле заполняем мы — сами находим акт сделки в генераторе документов перед отправкой.
Читают: Отправка акта после курса
Заполняют: Отправка акта после курса
Высылался ли до этого акт
UF_CRM_1730969289301Отметка, что акт по сделке СФОРМИРОВАН и выслан клиенту на стадии «Подписание документов» — её ставит бизнес-процесс 898 шагом «Помечаем, что выслали акт». Это условие запуска отправки акта после курса, а НЕ отметка о самой отправке. Наш сервис поле не читает и не пишет: у него свой журнал отправок, иначе две системы спорят за одно поле.
За меня платит Юр. лицо
UF_CRM_1679212846Галка «за обучение платит организация». Влияет на то, какой шаблон договора собирается клиенту.
Читают: Отправка договора, Отправка договора на подпись
За меня платит другой человек/организация
UF_CRM_DEAL_1695820568107Галка «платит третья сторона». Тоже меняет комплект и шаблон договора.
Читают: Отправка договора, Отправка договора на подпись
результат проверки документов для поступления силами ИИ
UF_CRM_1729519052401Чем закончилась автоматическая проверка диплома искусственным интеллектом. По результату сделка либо идёт дальше, либо возвращается менеджеру на ручной разбор.
Заполняют: Проверка диплома ИИ
Справки по обучению для студентов
UF_CRM_1716880811849Готовые файлы справок об обучении, которые система сформировала и приложила к сделке.
Заполняют: Выдача справки об обучении
Предмет договора
UF_CRM_1650797871Предмет договора — текст, который подставляется в документы. В нашем коде поле встречается только как пример в комментариях (им объясняют, что человеческие подписи полей отдаёт лишь метод crm.item.fields), ни читать, ни писать его мы не умеем.
Скидка рассчитана?
UF_CRM_1687847636Отметка, что скидка по сделке уже посчитана и повторно её применять не нужно. Без неё повторный запуск робота уменьшил бы сумму второй раз.
Читают: Расчёт скидки Т-банка
Заполняют: Расчёт скидки Т-банка
Применённые скидки
UF_CRM_1707376758296Список скидок, которые уже применены к сделке, в виде текстовых меток (например «14.5%»). Поле множественное. Нужен, чтобы одна и та же скидка не применилась дважды и чтобы правильно расписать её в договоре.
Читают: Отправка договора
Заполняют: Скидка за курс, Расчёт скидки Т-банка
Промокод
UF_CRM_637D4125F2927Промокод, который ввёл клиент. Проверяется по справочнику промокодов: магазин, процент или сумма скидки, ограничение по числу применений и по курсам.
Читают: Применение промокода
handlerB24_action
UF_CRM_1705065564103Отметка, что зачисление по сделке уже отработало и повторно запускать не нужно. Ставится в единицу по итогам успешного зачисления.
Читают: Зачисление на курс
Заполняют: Зачисление на курс
Название курса для фильтрации
UF_CRM_1709028516198Вычищенное название курса без служебных приписок. По нему удобно фильтровать и группировать сделки в отчётах.
Заполняют: Сборка названия сделки
ID курса
UF_CRM_1666698212Номер курса, на который человека зачислили. Проставляется по итогам зачисления.
Заполняют: Зачисление на курс
Дата начала курса
UF_CRM_1650797894Когда начинается курс, на который зачислили человека. Заполняется по итогам зачисления.
Заполняют: Зачисление на курс
Дата окончания курса
UF_CRM_1650998820140Когда курс заканчивается. Заполняется при зачислении и используется дальше: по ней отправляется акт об оказании услуг после окончания обучения.
Читают: Отправка акта после курса
Заполняют: Зачисление на курс
Дата начала
UF_CRM_1710230487473Дата старта первого модуля курса.
Дата платежа
UF_CRM_1710234093549Крайний срок оплаты: дата старта курса минус два дня. Считается автоматически.
Практики добавлены?
UF_CRM_1683218529Отметка, что к сделке добавлены практики (личная терапия, интервизия и подобное), входящие в состав курса.
Заполняют: Зачисление на курс
ID клиента на becbt.online
UF_CRM_1665408442Номер человека на нашей платформе обучения becbt. Ключевая связка «контакт Битрикса ↔ студент платформы»: по нему идёт зачисление, отчисление, перенос, выдача справок и синхронизация членства и почты.
Читают: Зачисление на курс, Отчисление с курса, Перенос на другой поток, Выдача справки об обучении, Вкладка «Встречи» в карточке, Синхронизация членства АКПП
Заполняют: Смена почты участника
Членство
UF_CRM_AMO_538621Есть ли у человека действующее членство АКПП. Синхронизируется с платформой; от членства зависят льготные цены.
Читают: Скидка за членство
Заполняют: Синхронизация членства АКПП
добавлен на геткурс
UF_CRM_1678350446206Отметка о выгрузке сделки на внешнюю платформу GetCourse. Показывает ход выгрузки и одновременно защищает от повторной отправки.
Читают: Выгрузка на GetCourse
Заполняют: Выгрузка на GetCourse
код для института бэка
UF_CRM_1748354994254Персональный код доступа, который выдаётся студенту и складывается в общую таблицу Google. Используется для входа в закрытые материалы.
Читают: Выдача кода доступа
Заполняют: Выдача кода доступа
Сделка товар-курс создана
UF_CRM_1692781047163Отметка, что по сделке уже создан заказ книг в магазине. Защищает от повторного создания заказа при повторном запуске робота.
Читают: Создание заказа книг
Заполняют: Создание заказа книг
Встречи
UF_CRM_1664098687166Старое поле вкладки «Встречи» в карточке сделки — показывает расписание участника прямо в Битриксе. Работает через тип поля, зарегистрированный прежним приложением; приложение удалено, поэтому тип «осиротел» и занять его заново нельзя. Ему на смену сделано поле UF_CRM_BECBT_MEETINGS.
Встречи
UF_CRM_BECBT_MEETINGSНовое поле вкладки «Встречи»: показывает в карточке сделки расписание и посещаемость участника. Создаётся нашим приложением при установке, чтобы не зависеть от осиротевшего старого типа поля.
Заполняют: Установка приложения (регистрация вкладки «Встречи»)
Служба доставки
UF_CRM_1734076900885Кем отправляем посылку — СДЭК или Почтой России. Определяется по тексту поля и выбирает перевозчика при создании отправления.
Читают: Отправлятор (доставка в карточке сделки)
Пункт СДЕК
UF_CRM_1734076755655Код пункта выдачи СДЭК, который выбрал клиент. Туда поедет посылка.
Читают: Отправлятор (доставка в карточке сделки)
Учет факт лидов
UF_CRM_1678888418494Отметка, что лид по этой сделке уже посчитан в отчётности. Без неё один и тот же лид попал бы в отчёт несколько раз.
Читают: Учёт фактических лидов
Заполняют: Учёт фактических лидов
Таблицы Леры
UF_CRM_1752504347304Служебная отметка для выгрузки в отчётные таблицы отдела продаж. Вместе с суммой, оплаченной с депозита, определяет, попадает ли сделка в выгрузку.
Читают: Отчёты «Таблицы Леры»
Заполняют: Разделение «Чёрной пятницы» (копируется в дочернюю сделку)
Таблица Леры 2
UF_CRM_1752567975017Такая же служебная отметка для второй отчётной выгрузки отдела продаж.
Читают: Отчёты «Таблицы Леры»
Заполняют: Разделение «Чёрной пятницы» (копируется в дочернюю сделку)
Таблицы Леры 3
UF_CRM_1756134452406Служебная отметка для третьей отчётной выгрузки отдела продаж.
Читают: Отчёты «Таблицы Леры»
ID курса
PROPERTY_2558Номер курса, к которому относится товар. Главный признак «этот товар — курс»: по нему идёт зачисление, выбирается касса, считается скидка, собирается договор и справка. Внимание: это номер курса в старой базе, а не номер товара.
Читают: Зачисление на курс, Простановка кассы по курсу, Скидка за курс, Отправка договора, Выдача справки об обучении, Сбор цепочки рассрочек
Заполняют: Выгрузка курса в Битрикс
id события
PROPERTY_2532Номер мероприятия на платформе becbt. Если у товара есть это свойство, но нет номера курса, значит куплено самостоятельное мероприятие (например, КЭМП) — человека записывают прямо на событие. Незаполненное свойство = классическая причина «оплатил, а на мероприятие не записали».
Читают: Зачисление на курс, Отчисление с мероприятия, Подбор под-мероприятий, Приветственное письмо о событии
ID Рассрочки
PROPERTY_2570Номер записи рассрочки. Заполнено = этот товар не сам курс, а один платёж рассрочки. Такие товары обрабатываются отдельно: в чеке они склеиваются в одну позицию на всю сумму курса.
Читают: Сбор цепочки рассрочек, Обработка оплаты PayKeeper, Названия позиций чека, Зачисление на курс
Заполняют: Выгрузка мероприятия в Битрикс
Финальная рассрочка
PROPERTY_2680Отметка, что это ПОСЛЕДНИЙ платёж рассрочки (единственное живое значение — «106»). Именно на нём выбивается зачётный чек сразу на всю сумму курса; на промежуточных платежах его нет, и это нормально.
Читают: Сбор цепочки рассрочек, Обработка оплаты PayKeeper
Заполняют: Выгрузка мероприятия в Битрикс
id события в б24
PROPERTY_5112Номер мероприятия в СТАРОЙ базе (таблица events_event). По нему товар-рассрочка привязывается к мероприятию при сборе чека. Название свойства вводит в заблуждение: это НЕ номер события на платформе becbt.
Читают: Сбор цепочки рассрочек, Корзина Долями
Заполняют: Выгрузка мероприятия в Битрикс
id события в б24
PROPERTY_5080Номер мероприятия для товаров-тарифов. Используется при расчёте скидки на мероприятие. Подписано так же, как PROPERTY_5112, — при разборе смотреть на код, а не на подпись.
Читают: Скидка на мероприятие
Заполняют: Выгрузка мероприятия в Битрикс
ID Мероприятий
PROPERTY_4970Список номеров под-мероприятий, входящих в товар: например, отдельные дни семинара. По ним человека записывают на каждый день.
Читают: Зачисление на курс, Выбор кабинета Долями
id мероприятия
PROPERTY_4992Номер ОДНОГО под-мероприятия (одного дня события) в старой базе. Отличается от PROPERTY_2532 тем, что там всё событие целиком, а тут — конкретная его часть.
Читают: Подбор под-мероприятий, Отчисление с мероприятия
Товар-курс
PROPERTY_4222Признак «товар — это курс» (значение 1). По нему решается, разделять ли сделку в «Чёрную пятницу», создавать ли заказ книг и как назвать позицию в чеке.
Читают: Разделение «Чёрной пятницы», Создание заказа книг, Названия позиций чека, Корзина Долями
товар-семинар
PROPERTY_4146Признак «товар — это семинар» (значение 1, а не номер). По нему проставляются даты в сделке и подбирается название позиции в чеке. Товары с этим признаком нельзя оплатить через «Долями».
Читают: Названия позиций чека, Зачисление на курс, Генерация ссылки Долями
товар-тариф
PROPERTY_5078Признак «товар — тариф участия в мероприятии» (например, разные уровни доступа на конференцию).
Заполняют: Выгрузка мероприятия в Битрикс
Продавец
PROPERTY_4148От чьего юрлица продаётся товар. Отсюда берётся касса PayKeeper для сделки; если свойство не заполнено, по умолчанию используется касса «МИР КПТ». Тот же признак ограничивает, в каком магазине действует промокод.
Читают: Простановка кассы по сделке, Чек по рассрочке Т-банка, Выставление счёта, Применение промокода
Заполняют: Выгрузка курса в Битрикс, Выгрузка мероприятия в Битрикс
Ссылка на курс
PROPERTY_2546Адрес страницы курса на сайте — подставляется в карточку товара при выгрузке курса в Битрикс.
Заполняют: Выгрузка курса в Битрикс
СДО
PROPERTY_2664Привязка товара к системе дистанционного обучения. Заполняется при выгрузке курса в Битрикс.
Заполняют: Выгрузка курса в Битрикс
Дата начала курса
PROPERTY_2666Дата старта, записанная на самой карточке товара. Заполняется при выгрузке мероприятия в Битрикс.
Заполняют: Выгрузка мероприятия в Битрикс
Дата окончания курса
PROPERTY_2668Дата окончания на карточке товара. По ней в сделку проставляется дата, с которой можно выбивать зачётный чек.
Читают: Простановка дат по событию
Заполняют: Выгрузка мероприятия в Битрикс
Дата окончания активности
PROPERTY_4150До какого числа товар доступен к покупке. После этой даты продажа закрывается.
Заполняют: Выгрузка курса в Битрикс
История списаний
PROPERTY_2754Накопительная запись о том, сколько по этому товару уже списано остатков при переносах и отчислениях. Нужна, чтобы одни и те же деньги не списались повторно.
Читают: Списание остатков
Заполняют: Списание остатков
Картинки товара
PROPERTY_100Изображения карточки товара. В нашем коде встречается только в команде снятия снимка схемы Битрикса — ни бизнес-логика, ни роботы его не используют.
Код промокода
PROPERTY_2632Сама строка промокода, которую вводит клиент. Живёт в справочнике промокодов (инфоблок 532), а не на товаре — в снимке свойств товара этого поля нет, подпись взята из кода.
Читают: Применение промокода
Скидка в процентах
PROPERTY_2634На сколько процентов промокод снижает цену. Из справочника промокодов (инфоблок 532); подписи в снимке нет, название взято из кода.
Читают: Применение промокода
Скидка в рублях
PROPERTY_2636Фиксированная сумма скидки по промокоду. Из справочника промокодов (инфоблок 532); подписи в снимке нет, название взято из кода.
Читают: Применение промокода
Магазин промокода
PROPERTY_5410В каком магазине действует промокод — АКПП или МИР КПТ. Из справочника промокодов (инфоблок 532); подписи в снимке нет, название взято из кода.
Читают: Применение промокода
Количество применений промокода
PROPERTY_5412Сколько раз промокодом уже воспользовались — по нему проверяется лимит. Из справочника промокодов (инфоблок 532); подписи в снимке нет, название взято из кода.
Читают: Применение промокода
Повторное применение промокода
PROPERTY_5414Можно ли применить промокод повторно тому же человеку. Из справочника промокодов (инфоблок 532); подписи в снимке нет, название взято из кода.
Читают: Применение промокода
Курсы, на которые действует промокод
PROPERTY_5416Список курсов, к которым промокод применим. Пусто = применим ко всем. Из справочника промокодов (инфоблок 532); подписи в снимке нет, название взято из кода.
Читают: Применение промокода
БПриложение Б. Справочник вызовов на наш сервер
67 вызовов, которые роботы Битрикса делают на наш сервер. Если рядом указан фиче-флаг и он выключен, робот получит ошибку 404 и молча ничего не сделает.
Собрать название сделки
/api/v1/integrations/deal/nameБерём сделку из Битрикса. Работаем только если сделка на стадии C4:NEW и название ещё не проставлено — иначе выходим, ничего не трогая. Берём первый товар сделки, вычищаем из его названия слова «Курс:», «курса », всё после слова «Рассрочка» и дату вида 01-02-2026 в начале. Что осталось — записываем в поле «название» сделки.
Уходит: Номер сделки.
Повторный вызов ничего не портит: если название уже стоит, обработчик молча выходит.
Вне стадии C4:NEW не сработает вообще — это не поломка, а защита от переименования старых сделок.
Проставить даты старта и оплаты
/api/v1/integrations/deal/date-fieldsСмотрим товары сделки, по свойствам товара определяем курс и модуль, находим дату старта первого модуля. Записываем в сделку дату старта (в формате 2026-07-20) и дату платежа — это старт минус два дня (в формате 20.07.2026).
Уходит: Номер сделки.
Две даты пишутся в разных форматах — так было в старой системе, менять нельзя, иначе поедут отчёты.
Отметить, что сделка в рассрочку
/api/v1/integrations/deal/installment-flagПросматриваем названия товаров сделки. Если хотя бы в одном встречается «рассрочк» (в любом падеже и регистре), ставим в сделке признак рассрочки — значение списка 1308. Если такого товара нет, ничего не пишем.
Уходит: Номер сделки.
Признак только ставится и никогда не снимается: убрать его можно лишь руками.
Убрать служебный товар из сделки
/api/v1/integrations/deal/clean-productsСмотрим состав товаров сделки и выбрасываем служебную позицию с номером товара 29476. Если её нет — ничего не переписываем. Если после чистки не осталось ни одного товара, чистку отменяем и пишем предупреждение в лог — пустой состав в Битрикс не отправляем.
Уходит: Номер сделки.
Номер служебного товара 29476 зашит в коде. Заведут новый служебный товар — этот обработчик его не увидит.
Проставить даты мероприятия и отметку о втором чеке
/api/v1/integrations/deal/event-datesПо товарам сделки находим мероприятие и его дату окончания. Записываем в сделку дату окончания курса, дату отправки второго чека (та же дата) и ставим признак «нужен второй чек (зачёт аванса)» в значение 1388 — «Да».
Уходит: Номер сделки.
Признак 1388 — это и есть команда «выбить второй чек». Ставить его вручную промежуточным траншам рассрочки нельзя: зачёт задвоится. По рассрочке зачёт бьётся один раз, на последнем платеже.
Разделить сделку по акции «Чёрная пятница»
/api/v1/integrations/deal/bf-splitСтавим задачу в очередь и сразу отвечаем «принято» (код 202). Дальше рабочий процесс разбивает товарный состав сделки на части по правилам акции, создаёт дочерние сделки, проставляет им ссылку на родителя, кассу, признаки чеков и суммы разделения.
Уходит: Номер сделки.
Отвечает 202 «принято в очередь», а не «сделано». Результат появится через несколько секунд.
Сделано через очередь специально: разделение делает много обращений к Битриксу, и раньше любой сбой Битрикса ронял операцию и терял продажу. Очередь повторяет попытку сама.
Повторный запуск безопасен: есть признак «уже разделено» и сверка дочерних сделок.
Списать остатки мест на складе
/api/v1/integrations/deal/remains-writeoffПри покупке уменьшаем складской остаток товара в Битриксе. Если куплен первый платёж рассрочки — списываем у головного товара; если куплен обычный товар — списываем у всех рассрочек этого курса. Историю списаний дописываем в свойство товара.
Уходит: Номер сделки.
Меняет карточку товара, а не сделки — последствия видны всем будущим покупателям курса.
Создать заказ книг
/api/v1/integrations/deal/order-bookЕсли у купленного курса стоит признак «с книгами», создаём отдельную сопутствующую сделку в воронке 18 с товарами-книгами и ставим в исходной сделке отметку, что заказ книг уже создан.
Уходит: Номер сделки.
Отметка о созданном заказе защищает от дублей: повторный вызов вторую сделку не создаст.
Обработать удаление сделки
/api/v1/integrations/deal/delete-dealСтавим задачу в очередь и отвечаем «принято». Дальше отчисляем студента в системе becbt, откатываем доходность модуля и удаляем записи о зачислении.
Уходит: Номер удалённой сделки. Битрикс шлёт это событием ONCRMDEALDELETE, номер лежит в data[FIELDS][ID].
Операция необратимая: студента отчисляют. Если сделку удалили по ошибке, зачисление придётся восстанавливать руками.
Обновить членство в АКПП у контакта
/api/v1/integrations/membership/akpp-syncНаходим человека в системе becbt (по нашему полю с becbt-номером, при необходимости — по почте), спрашиваем у becbt статус членства и записываем его контакту в Битриксе: 656 — член АКПП, 658 — не член.
Уходит: Номер контакта. Принимаем под именами CONTACT_ID, contact_id, id; префикс C_ отрезаем.
Это поле — источник истины о членстве. От него зависит скидка члена АКПП в расчёте цены курса.
Показать членство АКПП по контакту
/api/v1/integrations/membership/contact/{contactId}/akppТолько читаем, ничего не меняем. Находим becbt-номер человека, тянем из becbt его членство и заявку на членство, и отдаём это вместе с данными контакта. Если человек есть у нас как участник, добавляем его внутренний номер — тогда вкладка покажет полную карточку.
Уходит: Номер контакта Битрикса в адресе.
Если becbt-номер нашли по почте, он попутно записывается контакту — единственная запись в этом «читающем» вызове.
Контакта нет в Битриксе — отвечаем 404.
Объединить дубли контакта
/api/v1/integrations/contact/mergeИщем контакты-дубли по телефону и почте и сливаем их в самый старый контакт. Контакты с почтой getcourse и selfbecbt не сливаем — это технические адреса.
Уходит: Событие Битрикса «создан или изменён контакт» (ONCRMCONTACTADD / ONCRMCONTACTUPDATE) с номером контакта в data[FIELDS][ID] либо в document_id.
СЛИЯНИЕ НЕОБРАТИМО. Пока выключатель CONTACT_MERGE_ENABLED выключен, вызов отвечает 200 и ничего не сливает.
Всегда отвечает 200, даже при внутренней ошибке — чтобы Битрикс не долбил повторами. Ошибку ищите в журнале ошибок интеграций, а не по коду ответа.
Применить скидку на курс
/api/v1/integrations/deal/course-discountПересчитываем товарный состав сделки со скидкой на курс. Если робот прислал вместо «Да»/«Нет» неподставленный шаблон, мы сами идём в Битрикс: берём контакт сделки и смотрим его поле членства (656 — член). Если Битрикс недоступен, считаем «не член» и скидку члена не даём.
Уходит: Номер сделки и признак «член АКПП» в виде слова «Да» или «Нет» (параметр is_member_akpp).
Меняет цены в сделке — это деньги. Проверять на тестовых сделках, не на живых.
Если Битрикс в момент вызова недоступен, скидка члена АКПП молча не применится.
Применить скидку на мероприятие
/api/v1/integrations/deal/event-discountТо же, что скидка на курс, но по правилам мероприятия: берём размер скидки из свойства товара-мероприятия и пересчитываем состав сделки.
Уходит: Номер сделки и признак «член АКПП» («Да»/«Нет»).
Легко перепутать со скидкой на курс: это разные обработчики и разные источники процента. Мероприятие берёт скидку из свойства товара, курс — из карточки курса.
Применить скидку по программе Т-банка
/api/v1/integrations/deal/tbank-discountПересчитываем состав сделки с удорожанием/скидкой по выбранной программе рассрочки Т-банка (8,2%, 11,4% или 14,5%) и записываем результат в поля сделки.
Уходит: Номер сделки.
Деньги. Процент зависит от выбранной программы — сверяйте с тем, что реально одобрил банк.
Проверить и применить промокод
/api/v1/integrations/deal/promo-codeЧитаем промокод из сделки, проверяем его и, если он подходит, применяем к составу товаров. В ответе возвращаем статус — что именно произошло с промокодом.
Уходит: Номер сделки (промокод берётся из поля сделки).
Единственный из этой группы, кто возвращает поле status. Робот в Битриксе может по нему ветвиться.
Отправить договор клиенту
/api/v1/integrations/deal/document-sendСобираем параметры документа (шаблон, продавец, признак рассрочки) по товарам и полям сделки и запускаем в Битриксе бизнес-процесс 270 — он и формирует договор и отправляет его.
Уходит: Номер сделки.
Сам документ делает Битрикс, не мы. Если договор не пришёл — смотреть журнал бизнес-процесса 270.
Отправить документы на подписание
/api/v1/integrations/deal/document-signГотовим акт, счёт и договор и запускаем бизнес-процесс 1096. При islast=0 ничего не отправляем сразу, а кладём сделку в очередь ожидания — она уйдёт, когда курс закончится.
Уходит: Номер сделки; islast — 2 отправить сразу, 1 курс закончился, 0 отложить до окончания курса; folder_id — папка на Битрикс.Диске; type — служебный параметр из шаблона робота.
Робот присылает данные формой, а не JSON — поэтому тело читается «мягко». Если бы читали строго, робот получал бы ошибку 422.
При islast=0 ответ «ок» означает «поставлено в ожидание», а не «отправлено».
Разослать отложенные документы по закончившимся курсам
/api/v1/integrations/deal/document-sign/process-finishedБерём из очереди ожидания все сделки по этим курсам, запускаем для каждой бизнес-процесс 1096 с пометкой «курс закончился» и убираем их из очереди. В ответе — сколько обработали.
Уходит: Список номеров курсов (course_ids) — тех, что уже закончились.
Единственный вызов из этой группы, которому нужен не номер сделки, а список курсов. Пустой список — ошибка 422.
Может разом отправить документы по сотням сделок. Перед запуском проверяйте список курсов.
Выдать справку об обучении
/api/v1/integrations/deal/referenceПо курсу сделки и becbt-номеру человека формируем справку об обучении, кладём файл в папку на Битрикс.Диске и прикрепляем его к полю справок в сделке.
Уходит: Номер сделки.
Файлы кладутся в папку Битрикс.Диска с номером 39450 — номер зашит в коде.
Проверить диплом искусственным интеллектом
/api/v1/integrations/deal/parsing-diplomЗапускаем бизнес-процесс 894 — он копирует файлы дипломов на Битрикс.Диск. Затем скачиваем и распаковываем архивы, переводим PDF в картинки, отправляем их на проверку в becbt и записываем результат в сделку: 2180 — диплом подтверждён, 2184 — нет. Плюс пишем комментарий.
Уходит: Номер сделки.
Вызов долгий: скачивание, распаковка, конвертация, запрос к becbt. Не пугайтесь, если ответ идёт десятки секунд.
Решение принимает нейросеть — это подсказка человеку, а не окончательный вердикт.
Отправить документ на электронную подпись (Legium)
/api/v1/integrations/legium/sendФормируем договор по сделке, отправляем его в сервис Legium на электронную подпись и возвращаем ссылку на документ (linkDoc).
Уходит: От активити бизнес-процесса: properties (поля для шаблона документа), document_id вида ["crm","CCrmDocumentDeal","DEAL_123"] и event_token для возврата управления бизнес-процессу.
Активити шлёт данные формой, а не JSON. Если читать строго, активити зависает в бизнес-процессе.
Legium хранит только ссылку на документ, сам PDF у него не лежит. Если ссылка пустая — документ создался неудачно.
Ответ Legium о подписании (внешний вебхук)
/api/v1/integrations/legium/callbackНаходим нашу сделку по адресу документа и отмечаем, что документ подписан. Всегда отвечаем 200 «принято».
Уходит: Данные Legium: адрес документа (document_url), статус подписи; в адресе — параметр agent.
Адрес открыт наружу без пароля (security.yaml:48). Подпись запроса не проверяется — сделка ищется по известному нам адресу документа.
Всегда 200: по коду ответа нельзя понять, нашли ли сделку. Смотреть журнал интеграций.
Назначить кассу по продавцу товара
/api/v1/integrations/deal/set-cashboxСтавим задачу в очередь и отвечаем «принято». Дальше определяем кассу по продавцу товара (свойство товара PROPERTY_4148) и записываем её в сделку.
Уходит: Номер сделки. Обычно прилетает событием Битрикса ONCRMDEALUPDATE.
Повторы отсекаются на 24 часа (DealHandlersController:244-257). Дважды за сутки по одной сделке касса не переставится — в ответе будет deduped:true. Это не поломка.
Так сделано потому, что Битрикс шлёт ONCRMDEALUPDATE пачками при каждом редактировании сделки, а очередь под лимитом 2 запроса в секунду не успевала разгребать — бэклог доходил до 3400 задач.
Не путать с «кассой по продавцу КУРСА» — это другой обработчик и другой источник продавца.
Назначить кассу по продавцу курса
/api/v1/integrations/deal/set-cashbox-courseПо товару сделки находим номер курса, по курсу в нашей базе — продавца потока, по продавцу — кассу, и записываем её в сделку. Выполняется сразу, без очереди.
Уходит: Номер сделки.
Пишет в то же поле кассы, что и /set-cashbox, но продавца берёт из карточки курса в нашей базе. Если продавец у курса не заполнен, касса не проставится.
Отправить письмо об оплате
/api/v1/integrations/deal/payment-emailСобираем данные по курсу сделки и запускаем в Битриксе бизнес-процесс 420 — он отправляет клиенту письмо со ссылкой и информацией об оплате.
Уходит: Номер сделки.
Само письмо шлёт Битрикс. Не пришло — смотреть журнал бизнес-процесса 420.
Построить график платежей рассрочки
/api/v1/integrations/deal/installment-webhookСобираем будущие платежи: даты семинаров и товары «Рассрочка 2/N», «Рассрочка 3/N» и так далее — и сохраняем график в нашу базу. Дальше ежедневная задача сама создаёт сделки-платежи к нужным датам. В ответе — статус и количество строк графика.
Уходит: Номер сделки с товаром вида «Рассрочка 1/N».
Сделки-платежи создаются не здесь, а по расписанию. Пустой график чаще всего значит, что в сделке нет товаров-рассрочек.
Перенести анкету заказчика из базовой сделки
/api/v1/integrations/deal/payer-carryoverЕсли за обучение платит муж, родственник или работодатель, анкету с его данными клиент заполняет ОДИН раз — в первой сделке курса. В транше рассрочки, заведённом руками, поля пусты, и робот «Отправлена на оплату» считает такую сделку оплатой самого студента: счёт и ссылка уходят обучающемуся. Обработчик находит сделку того же контакта и того же курса, где заказчик указан, и копирует анкету в ПУСТЫЕ поля новой сделки. Пишет комментарий в таймлайн.
Уходит: Номер сделки.
Заполненные поля не перезаписываются: правку менеджера в этой сделке мы не трогаем.
Если у контакта есть заказчик, но на ДРУГОЙ курс, перенос не делается — иначе счёт ушёл бы постороннему человеку.
Отдельно звать роутом обычно не нужно: перенос ставится в очередь на обычном обновлении сделки и делается кроном рассрочки при создании транша.
Создать счёт в PayKeeper
/api/v1/integrations/paykeeper/invoice/createПо товарам сделки собираем корзину, определяем кассу (из поля сделки либо по продавцу товара), создаём счёт в PayKeeper и возвращаем ссылку на оплату. Повторный вызов новый счёт не создаёт — вернётся already_existed=true.
Уходит: Номер сделки, номер заказа (orderid), ФИО, почта, телефон плательщика, код кассы (cabinet).
Название товара длиннее 127 символов PayKeeper не принимает — мы обрезаем его при сборке корзины.
Без orderid или с deal_id ≤ 0 отвечаем 422.
ФИО и почту робот присылает КОНТАКТНЫЕ (во всех кассовых ветках это жёстко «Контакт: Фамилия/Имя/Отчество» и «Контакт: E-mail»). Если в сделке указано, что платит другой человек или организация, мы подменяем их данными заказчика из анкеты — иначе счёт и чек выписывались бы на обучающегося.
Отменить неоплаченные счета по сделке
/api/v1/integrations/paykeeper/invoice/cancelНаходим неоплаченные счета PayKeeper по сделке (а если передан курс — только по нему) и отзываем их. В ленту сделки пишем комментарий, кто и что отменил. В ответе — сколько отменили.
Уходит: Номер сделки; при необходимости номер курса (course_id) и кто отменяет (responsible).
Отменённый счёт клиент оплатить уже не сможет — ссылка перестанет работать.
Отменить все неоплаченные счета по курсу
/api/v1/integrations/paykeeper/invoice/cancel-by-courseБерём из нашей базы все неоплаченные счета этого курса, отзываем их и на каждую затронутую сделку пишем комментарий в ленту.
Уходит: Номер курса (course_id), кто отменяет (responsible) и заголовок X-Api-Key.
Единственный вызов с паролем: нужен заголовок X-Api-Key, он сверяется с настройкой INBOUND_API_KEY. Если ключ в настройках пуст, адрес закрыт всегда (401) — так задумано.
Массовая операция: одним запросом можно погасить счета всего потока. Проверяйте номер курса дважды.
Показать счёт и чек по сделке
/api/v1/integrations/paykeeper/checkТолько читаем: отдаём данные счёта из нашей базы и ссылку на фискальный чек в кабинете PayKeeper. Ничего не меняем и не пробиваем.
Уходит: Номер сделки в адресе (deal_id).
Единственный вызов оплаты, которому не нужен выключатель PayKeeper — он только читает.
Пробить чек по оплаченному счёту
/api/v1/integrations/paykeeper/schet-receiptПо оплаченному счёту сделки пробиваем кассовый чек по ФЗ-54. В ответе — пробили или нет, номер чека и список ошибок. После чека сделка приводится к тому же виду, что и после оплаты картой: «первый чек выдан», «дата первого чека», дата фактической оплаты, а финальному траншу рассрочки — команда на зачёт.
Уходит: Номер сделки (принимаем также под именем ID).
Это реальный фискальный чек. Пробитый чек отменяется только через возврат — не тестировать на живых сделках.
Юридическому лицу чек не выдаётся — сделка возвращается без чека и без отметки «выдан».
До 27.07.2026 «дату первого чека» здесь не ставили (как и старый скрипт) — из-за этого закрывающий чек по оплатам счетов не выдавался никогда.
Пробить финальный (второй) чек — зачёт аванса
/api/v1/integrations/paykeeper/final-receiptПробиваем второй чек — зачёт аванса — по одной сделке: собираем цепочку связанных сделок, берём ставку НДС на дату первого чека, проверяем, не выбит ли чек уже. После обработки перечитываем сделку и по признаку «второй чек выдан» отвечаем issued: да или нет, а при отказе — reason с причиной по-русски (какой гейт не пройден). Принимает и GET: роботы дёргают адрес ссылкой.
Уходит: Номер сделки.
Несмотря на постановку сообщения, выполняется прямо в этом же запросе — сообщение не уходит в очередь.
Зачёт по рассрочке бьётся ОДИН раз, на финальном платеже. Запуск на промежуточном транше задваивает зачёт.
issued:false не всегда ошибка — бывает, что чек по правилам и не должен выбиваться; смотри reason.
При переносе/отчислении запускать на БАЗОВОЙ сделке: донор и акцептор попадают в расчёт сами, как её дети. Сумма зачёта = фактически оказанное (у отчисления это товары донора, акцептор в C4:LOSE в корзину не идёт).
Ручной запуск обходит проверку «дата отправки 2-го чека наступила» — на боевой сделке это выдаст зачёт раньше окончания курса.
Заявка на расход → таблица бухгалтерии
/api/v1/integrations/rpa/expense-requestЧитает заявку на расход из процесса «Заявка на расход» и дописывает строку в Google-таблицу бухгалтерии (лист «Ответы на форму (1)»): когда создана, автор, проект, получатель, дата и сумма оплаты, примечание, способ оплаты, папка с документами, файл счёта, куда платить без счёта, нужна ли платёжка, кому подтверждение, статья расходов.
Уходит: Номер заявки (робот RPA-процесса шлёт его в адресе как id).
Таблица должна быть открыта на запись сервис-аккаунту bek-institut@bek-institut.iam.gserviceaccount.com — старый скрипт ходил под личным Google-аккаунтом.
Раньше при пустом «способе оплаты» все колонки после него съезжали влево — такие строки в таблице остались с прошлых лет.
Помощник менеджера в интерфейсе Битрикса
/api/v1/integrations/crm-slider/{emails|deals|contact}Три запроса скрипта-помощника, который добавляет в почте Битрикса кнопку «История» и свой CRM-слайдер: письма по адресу клиента, его сделки с названиями направления и стадии, контакт по адресу (находим самый старый или создаём). Сам скрипт отдаёт роут /crm-slider/app.js — в Tampermonkey ссылка ставится один раз, дальше правки приезжают сами.
Уходит: Адрес почты клиента (и ключ доступа).
Заменил открытый прокси старого сервера (CRMslider/action.php), через который можно было вызвать ЛЮБОЙ метод Битрикса без авторизации.
Требует ключ CRM_SLIDER_KEY и портальный Origin; ключ живёт в userscript'е у менеджера. Установка — docs/runbooks/crm-slider-userscript.md.
Тело письма показывается в песочнице (iframe sandbox): раньше скрипт из письма мог выполниться в сеансе менеджера.
Пробить закрывающий чек по книжной сделке
/api/v1/integrations/paykeeper/book-final-receiptПо сделке воронки «Книги» на стадии «Оплачено» пробиваем закрывающий (второй) чек — зачёт аванса. Корзина — товары самой сделки, касса «АКПП ЦБТ-Тур», ставка НДС 5%. После успеха пишем комментарий в таймлайн, ставим в сделке «Выслан второй чек?» и через пять минут кладём PDF чека в папку клиента.
Уходит: Номер сделки (робот шлёт его в адресе как deal_id).
Реальный фискальный чек — не тестировать на живых сделках.
Отдельный адрес от обычного финального чека: у книжных сделок нет «даты отправки 2-го чека», и общий обработчик их пропускает.
Работает только на стадии «Оплачено» воронки «Книги» — на других стадиях отвечает отказом и ничего не пробивает.
Пробить чек по оплате Т-банком
/api/v1/integrations/paykeeper/tbank-receiptПробиваем кассовый чек по ФЗ-54 по оплате через рассрочку или кредит Т-банка.
Уходит: Номер сделки (робот чека Т-банка шлёт его как ID).
Реальный фискальный чек.
Пробить чек по оплате Долями
/api/v1/integrations/paykeeper/dolami-receiptПробиваем кассовый чек по ФЗ-54 по оплате через рассрочку Долями.
Уходит: Номер сделки.
Известная беда старой системы: она била чеки и на всю сумму, и на сумму без комиссии — получались дубли. Переход на наш обработчик по Долями пока не завершён, сверяйтесь с кассой.
Сформировать PDF-чек Долями
/api/v1/integrations/paykeeper/dolami-pdfФормируем PDF финансового чека по рассрочке Долями. В ответе — ok: да или нет.
Уходит: Номер сделки.
Нужны СРАЗУ ДВА включённых выключателя. Выключен любой — ответ 404.
Уведомление PayKeeper об оплате (внешний вебхук)
/api/v1/integrations/paykeeper/callback/{accountKey}Проверяем подлинность по контрольной подписи MD5 (секрет берём по кассе). Находим счёт и сделку, отмечаем оплату, проставляем дату фактической оплаты, признаки чеков и двигаем сделку дальше. Отвечаем обычным текстом «OK <подпись>».
Уходит: PayKeeper шлёт формой: номер платежа (id), сумму (sum), клиента (clientid), номер заказа (orderid) и контрольную подпись (key). Ключ кассы — в адресе; работает и адрес без ключа.
Адрес открыт наружу без пароля (security.yaml:46) — защита только контрольной подписью.
Если ключ кассы в адресе не передан, касса определяется по номеру заказа. Классическая авария: касса не описана у нас в справочнике — уведомление отвергается, деньги пришли, а курса у человека нет. Симптом: PayKeeper повторяет уведомление каждые 10 минут.
Ответ — обычный текст, не JSON. Так требует PayKeeper.
Активити: можно ли выставлять счёт по курсу
/api/v1/integrations/paykeeper/activity/check-courseСмотрим курс сделки. Если у курса включено «не выставлять счета при заполнении» и мест уже набрано столько же или больше, чем план, возвращаем бизнес-процессу отказ. Иначе — «Y». Ответ уходит в бизнес-процесс отдельным вызовом, а нам достаточно 200.
Уходит: От активити бизнес-процесса: document_id и event_token.
Контроллер всегда отвечает 200, даже если внутри случилась ошибка — иначе активити зависнет в бизнес-процессе.
Активити: касса по продавцу курса
/api/v1/integrations/paykeeper/activity/change-cashboxОпределяем кассу по продавцу курса и записываем её в сделку, затем отвечаем бизнес-процессу.
Уходит: От активити бизнес-процесса: document_id и event_token.
То же поле кассы, что и у /deal/set-cashbox-course — просто вызывается из бизнес-процесса, а не роботом.
Активити: ссылка на оплату PayKeeper
/api/v1/integrations/paykeeper/activity/payment-linkСоздаём счёт в PayKeeper и возвращаем в бизнес-процесс две вещи: ссылку на оплату (link_payment) и готовое тело письма (html_page). Используется на стадии «Отправлено на оплату».
Уходит: От активити бизнес-процесса: properties, document_id и event_token.
Закрыт выключателем PayKeeper, а не общим выключателем интеграций — в отличие от соседних активити.
Создать ссылку рассрочки Долями
/api/v1/integrations/dolami/generate-linkСобираем корзину по товарам сделки, отправляем заказ в Долями и возвращаем ссылку на оплату. Ссылку и причину отказа (если она была) пишем в ленту сделки.
Уходит: Номер сделки.
Отказ Долями по делу («позиции отличаются от ранее полученных», «сумма меньше 4 ₽») — это 422 с русским текстом, а не поломка. Тревогу в Телеграм по таким случаям не шлём.
Долями помнит заказ по номеру сделки. Если сумму сделки изменили, повторно создать ссылку не выйдет.
Сделки нет в Битриксе — отвечаем 404, без тревоги.
Уведомление Долями о статусе (внешний вебхук)
/api/v1/integrations/dolami/notificationОбновляем статус рассрочки по сделке. Всегда отвечаем 200 {ok:true}.
Уходит: Данные Долями: номер и статус заказа. Принимаем и JSON, и форму.
Адрес открыт наружу без пароля (security.yaml:63).
Всегда 200 — по коду ответа нельзя понять, обработали ли уведомление.
Создать ссылку рассрочки Т-банка
/api/v1/integrations/tbank/generate-linkСобираем заявку по составу сделки, отправляем в Т-банк и возвращаем ссылку на оформление рассрочки или кредита.
Уходит: Номер сделки (deal_id, dealid или id) и код кабинета (cabinet: tbank или tbank-mir).
Работает и по GET, и по POST — часть роботов Битрикса умеет только открыть ссылку.
Отказ Т-банка по делу (сумма вне диапазона 3001–500000 ₽, неполные данные клиента) — это 422 с понятной причиной, а не сбой.
Робот шлёт форму, а не JSON. Раньше строгое чтение давало 422 ещё до разбора номера сделки — ссылка не создавалась, и письмо уходило с пустой ссылкой.
Уведомление Т-банка о статусе (внешний вебхук)
/api/v1/integrations/tbank/webhookЗапрашиваем у Т-банка текущий статус заявки по сделке и обновляем его у нас. Всегда 200 {ok:true}.
Уходит: В адресе: dealid — номер сделки и cabinet — код кабинета.
Адрес открыт наружу без пароля (security.yaml:65).
Номер сделки берётся ТОЛЬКО из адреса, из тела не читается. Пустой dealid — пишем предупреждение в журнал и отвечаем 200.
Зачислить студента (главный вызов при выигранной сделке)
/api/v1/integrations/enrollment/runСтавим задачу в очередь и отвечаем «принято» (202). Дальше разбираем товары сделки: товар с признаком курса (PROPERTY_2558) — обычное зачисление на поток; товар с признаком мероприятия (PROPERTY_2532) без курса — запись на самостоятельное мероприятие вроде КЭМПа, вместе с его частями. Заводим человека в becbt, записываем на курс и мероприятия, создаём записи в нашей базе и проставляем в сделке отметку об обработке.
Уходит: Номер сделки и номер контакта. Контакт необязателен — если его не прислали, возьмём из самой сделки. Робот стоит на стадии «Сделка успешна» (C4:WON).
Повторный вызов безопасен: есть отметка «уже обработано».
Если добавить sync=1, вызов выполнится сразу и вернёт подробный отчёт — это для ручной проверки, не для боевого робота.
Человека не зачислили на купленное мероприятие — первым делом проверьте, заполнено ли у товара свойство мероприятия PROPERTY_2532.
Битрикс подставляет номера с префиксом: D_2923342, C_261528. Мы их отрезаем — раньше из-за этого за день сорвалось 42 зачисления.
Зачислить по подтверждённой оплате (запасной путь)
/api/v1/integrations/payment/enrollСоздаём запись о зачислении только в нашей базе, без похода в becbt и без записи обратно в сделку. В ответе — номер зачисления и его статус.
Уходит: В JSON: номер контакта и товара Битрикса, номер сделки, номер платежа рассрочки, имя, фамилия, отчество, почта, телефон.
Это заготовка, а не боевой путь. Боевое зачисление — /enrollment/run.
Единственный вызов зачисления, требующий строгий JSON: форма даст ошибку 422.
Выдать код доступа
/api/v1/integrations/access-code/issueБерём свободный код из таблицы Google Sheets, помечаем его выданным, записываем код в сделку и запускаем в Битриксе бизнес-процесс 1012 — он отправляет код клиенту.
Уходит: Номер сделки и номер контакта. Принимаем под именами DEAL_ID/deal_id и CONTACT_ID/contact_id/user_id/USER_ID; префиксы D_ и C_ отрезаем.
Коды берутся из внешней Google-таблицы. Если она недоступна или коды кончились, выдача не пройдёт.
Google иногда отвечает временной ошибкой 503 — в этом месте нужен повтор запроса.
Отправить приветственное письмо о записи на мероприятие
/api/v1/integrations/deal/event-welcomeСмотрим товары-мероприятия сделки. Если у мероприятия включена отправка приветственного письма, запускаем в Битриксе бизнес-процесс 918.
Уходит: Номер сделки.
Без свойства мероприятия у товара письмо не уйдёт — обработчику не за что зацепиться.
Записать наблюдателем на итоговую супервизию
/api/v1/integrations/supervision-observer/enrollСмотрим, наша ли это сделка: заполнено поле «id запроса» либо в составе лежит товар 43376 «Итоговая супервизия. Участие в качестве наблюдателя» (единый для всех потоков БК и ПК, 20 000 ₽). Если да — сообщаем админке becbt, что место оплачено: PUT spectator/paid/bitrix с телом {id, deal_id}, где id — номер заявки числом. Операцию записываем в свою таблицу, чтобы она не потерялась.
Уходит: Номер сделки. Робот стоит на стадии «Сделка успешна» (C4:WON) воронки «Институт». Адрес отвечает и на GET, и на POST — роботы Битрикса зовут его по-разному.
Повторный вызов ничего не дублирует: по каждой сделке запись уходит ровно один раз.
Поле «id запроса» в Битриксе строковое, но наружу мы отдаём число — так просил принимающий сервис.
Если админка becbt недоступна, операция копится в очереди и уходит командой app:supervision:observer-replay --apply. В карточке сделки при этом появляется запись, что оплата принята, а отправка отложена.
Товар наблюдателя намеренно без свойств курса и мероприятия — обычное зачисление на поток по нему не срабатывает, и это правильно.
Снять бронь наблюдателя и погасить ссылку на оплату
/api/v1/integrations/supervision-observer/cancelГасим все действующие счета PayKeeper по сделке — ссылка на оплату перестаёт работать. Если наблюдателя записывали мы, дополнительно сообщаем админке becbt о снятии: PUT spectator/cancel/bitrix с телом {id, deal_id}. В карточку сделки пишем, что именно сделано.
Уходит: Номер сделки. Робот стоит на стадии «Сделка провалена» (C4:LOSE) воронки «Институт». Адрес отвечает и на GET, и на POST.
Зачем это нужно: место бронируется под неоплаченную сделку, и если бронь сняли, а ссылка жива — человек оплатит уже отданное место.
На сделках без признака наблюдателя вызов не делает ничего: счета обычных сделок гасит человек кнопкой, а не робот стадии.
Оплаченный счёт касса отменить не даст — это нормально, остальные счета всё равно гасятся.
Передать данные студента в GetCourse
/api/v1/integrations/deal/getcourse-syncПередаём данные сделки и студента в систему дистанционного обучения GetCourse, чтобы у человека появился доступ к материалам.
Уходит: Номер сделки.
Доступ к материалам выдаёт GetCourse. Не открылся — проверять на их стороне.
Отчёт по выручке: учесть сделку
/api/v1/integrations/deal/tables-leraЗаписываем сделку в отчёт по выручке на сегодняшнюю дату и ставим в ней отметку об учёте — 1 или 2 в зависимости от того, как сделка попала в отчёт.
Уходит: Номер сделки.
Дата берётся не из сделки, а «сегодня» на момент вызова. Запустить задним числом нельзя.
Пакетная сделка даёт в отчёте несколько строк — при ручном подсчёте выручка может задвоиться.
Журнал продаж по менеджеру
/api/v1/integrations/deal/tables-lera-2Дописываем выигранную сделку строкой в журнал продаж по менеджеру и ставим отметку об учёте.
Уходит: Номер сделки.
Дата — «сегодня» на момент вызова.
Учёт провалившихся сделок
/api/v1/integrations/deal/tables-lera-3Записываем провалившуюся сделку в колонку потерь витрины выручки и ставим отметку об учёте.
Уходит: Номер сделки.
Дата — «сегодня» на момент вызова.
Учесть заявку на поток
/api/v1/integrations/deal/lead-factСтавим задачу в очередь и отвечаем «принято». Дальше по товару сделки находим поток в нашей базе и увеличиваем счётчик фактических заявок на единицу. В сделке ставим отметку «заявка учтена».
Уходит: Номер сделки. Прилетает событием Битрикса ONCRMDEALADD при создании сделки.
Отметка защищает от двойного счёта: одна сделка учитывается один раз.
В очередь вынесено потому, что событие прилетает на каждое создание сделки, а учёт требует нескольких обращений к Битриксу.
Товар-курс в универсальный список «Курсы»
/api/v1/integrations/product/course-listПроверяем, настоящий ли это курс: есть признак курса, семинара или рассрочки; это не тест, не книга и не мусор; цена не меньше 1000 ₽. Если да — добавляем или обновляем название товара в универсальном списке «Курсы» (список 1092) с кодом course-<номер товара>.
Уходит: Событие Битрикса ONCRMPRODUCTADD или ONCRMPRODUCTUPDATE с номером товара в data[FIELDS][ID].
Выключателя нет — работает всегда.
Всегда отвечает 200, даже при ошибке: в теле будет status со словом skip или error. По коду ответа судить нельзя.
Событие другого типа отбрасываем со статусом skip:wrong_event.
Приложению в Битриксе нужно право на работу со списками (scope lists), иначе запись в список 1092 не пройдёт.
Установка приложения PayKeeper
/api/v1/integrations/paykeeper/installРегистрируем в Битриксе активити «проверить курс» и «плательщик/касса» так, чтобы их обработчик указывал на наш сервер. Коды активити оставляем прежние — существующие бизнес-процессы менять не нужно.
Уходит: Битрикс шлёт данные доступа: либо auth[access_token] и auth[client_endpoint], либо плоские AUTH_ID и DOMAIN.
Адрес открыт наружу без пароля (security.yaml:52) — Битрикс дёргает его без нашей сессии.
Из присланного DOMAIN берём только имя хоста и только у порталов вида *.bitrix24.<домен>. Иначе можно было бы увести токен доступа на чужой сервер.
Работает и по GET, и по POST.
Установка приложения Legium
/api/v1/integrations/legium/installРегистрируем активити отправки документа на подпись с обработчиком на нашем /legium/send. Код активити и его свойства прежние — бизнес-процессы не меняются, меняется только адрес.
Уходит: Данные доступа Битрикса (auth.access_token, auth.client_endpoint).
Адрес открыт наружу без пароля (security.yaml:50).
Пишет файл-маркер var/legium-install-marker.json со структурой запроса — секреты в нём замаскированы. Это временная диагностика.
Установка вкладки «Фильтр» в карточке сделки
/api/v1/integrations/deal-tab/installПри установке: привязываем вкладку CRM_DEAL_DETAIL_TAB к нашей странице /deal-filter и отдаём Битриксу HTML-страницу, которая вызывает BX24.installFinish() — без этого Битрикс считает приложение недоустановленным. При отрисовке поля: достаём номер сделки из PLACEMENT_OPTIONS (а если его там нет — из адреса вида /crm/deal/details/123/) и перенаправляем на /deal-filter?dealId=123.
Уходит: Данные доступа Битрикса. Отдельно смотрим поле PLACEMENT: значение USERFIELD_TYPE означает не установку, а отрисовку поля «Встречи» в карточке.
Адрес открыт наружу без пароля (security.yaml:56).
Один адрес на два разных случая — установка и отрисовка поля. Различаем по PLACEMENT.
Битрикс не передаёт номер сделки напрямую, приходится вытаскивать его из адреса страницы.
Отвечает HTML, а не JSON.
Установка вкладки «Операции» в карточке контакта
/api/v1/integrations/contact-tab/installПривязываем вкладку CRM_CONTACT_DETAIL_TAB к нашей странице /operations (потоки и мероприятия контакта) и отдаём HTML с BX24.installFinish(). Заменяет старые встройки user_course и user_event.
Уходит: Данные доступа Битрикса (auth.* либо плоские AUTH_ID и DOMAIN).
Адрес открыт наружу без пароля (security.yaml:54). Отвечает HTML, а не JSON.
Установка вкладки «Отправлятор» в карточке сделки
/api/v1/integrations/shipping-tab/installПривязываем вкладку CRM_DEAL_DETAIL_TAB к нашей странице /b24/shipping (оформление доставки СДЭК и Почтой) и отдаём HTML с BX24.installFinish().
Уходит: Данные доступа Битрикса (auth.* либо плоские AUTH_ID и DOMAIN).
Адрес открыт наружу без пароля (security.yaml:58). Отвечает HTML, а не JSON.
В карточке сделки живут ДВЕ вкладки на одном и том же месте CRM_DEAL_DETAIL_TAB — «Фильтр» и «Отправлятор».
Приложение «Договор со спикером»
/api/v1/integrations/speaker-appОтдаём HTML-страницу, которая сразу перенаправляет рамку на новый экран спикеров https://bitrix.associationcbt.ru/speakers и заодно вызывает BX24.installFinish() — на случай, если это установка.
Уходит: Битрикс открывает адрес в рамке (iframe) POST-запросом с данными доступа.
Адрес открыт наружу без пароля (security.yaml:60). Работает и по GET, и по POST.
Перенаправляем только саму рамку. Трогать адрес всей страницы нельзя — уведёт весь Битрикс.
ВПриложение В. Бизнес-процессы, которые мы запускаем
Обратное направление: здесь уже наш сервер просит Битрикс что-то сделать. Важно при разборе жалоб «письмо не пришло»: наш вызов мог отработать успешно, а само письмо отправляет бизнес-процесс на стороне Битрикса — смотреть надо его журнал.
ГПриложение Г. Словарь терминов
Термины, которые в тексте подчёркнуты пунктиром: при наведении курсора всплывает пояснение. На бумаге подсказки не видны, поэтому они собраны здесь.
PayKeeper | Платёжный сервис, через который клиент оплачивает курс. У каждого юрлица свой отдельный кабинет. |
Легиум | Внешний сервис электронной подписи legium.io. Клиент подписывает договор онлайн по ссылке, которую присылает система. |
Долями | Сервис оплаты частями без банка. Сумма делится на несколько равных платежей. |
Т-банка | Рассрочка или кредит от Т-банка. Банк берёт комиссию, поэтому система заранее пересчитывает сумму. |
Т-банк | Рассрочка или кредит от Т-банка. Банк берёт комиссию, поэтому система заранее пересчитывает сумму. |
депозит | Внутренний счёт клиента внутри becbt. С него можно оплатить обучение вместо денег. |
депозитом | Внутренний счёт клиента внутри becbt. С него можно оплатить обучение вместо денег. |
becbt | Наша платформа обучения, где заведены курсы, потоки, семинары и студенты. |
GetCourse | Внешняя платформа обучения. Часть курсов завязана на неё, туда уходят данные оплаченной сделки. |
смарт-процесс | Отдельный процесс в Битриксе рядом со сделкой. Здесь используется для учёта оплаты. |
смарт-процесс Оплата | Отдельный процесс в Битриксе для учёта оплаты по сделке. |
потока | Конкретный запуск курса с датами. У каждого потока свои часы, семинары и участники. |
поток | Конкретный запуск курса с датами. У каждого потока свои часы, семинары и участники. |
потоку | Конкретный запуск курса с датами. У каждого потока свои часы, семинары и участники. |
семинары | Отдельные занятия внутри потока. На них зачисляют студента при оплате. |
семинар | Отдельное занятие внутри потока. На него зачисляют студента при оплате. |
семинаров | Отдельные занятия внутри потока. На них зачисляют студента при оплате. |
потоков | Конкретные запуски курса с датами. У каждого потока свои часы, семинары и участники. |
Диск | Хранилище файлов внутри Битрикса. Туда кладутся готовые акты, счета и чеки. |
академических часов | Учебные часы курса. В договоре указываются часы конкретного потока, а не стандартные. |
идемпотентно | Сколько бы раз действие ни повторилось, результат один и тот же. Повтор не создаёт дублей. |
АКПП | Ассоциация когнитивно-поведенческой психотерапии. Одно из юрлиц-продавцов и организация членства. |
МИР КПТ | Одно из юрлиц-продавцов курсов. От него идут деньги и документы по части курсов. |
ЦЭК | Одно из юрлиц-продавцов курсов. |