Проверка контрагента перед сделкой обычно выглядит так: менеджер копирует ИНН из CRM, идёт в сервис проверки, смотрит статус и выручку, возвращается и пересказывает результат в комментарии. Работает, пока сделок мало и все помнят, что проверять надо. Слабое место — человеческий фактор: договор с ликвидированным юрлицом подписывается именно тогда, когда «было некогда проверить». Разберём, как перенести проверку внутрь Битрикс24 — в бизнес-процесс, который запускается сам и не забывает.

Что можно узнать по ИНН, не выходя из CRM

Робот «Компания по ИНН (реестр)» по одному ИНН возвращает данные госреестра: официальное название (краткое и полное), статус юрлица — действует или ликвидировано, руководителя, основной ОКВЭД, юридический адрес и дату регистрации. Робот «Оборот компании по ИНН» добавляет финансовый разрез: годовую выручку по бухгалтерской отчётности (строка 2110) с указанием отчётного года — и сразу пишет её в системное поле «Оборот» карточки компании или любое другое поле на выбор. Вместе это закрывает базовый скоринг: жива ли компания, кто её подписант, каков масштаб бизнеса.

Сценарий 1: проверка при создании компании

Процесс на создание компании делает три шага. Сначала «Найти компанию по ИНН» ищет этот ИНН среди существующих карточек — если контрагент уже есть, новый не создаётся, и база не обрастает дублями (почему дубли расползаются и как их чистить — в разборе дублей). Затем «Компания по ИНН» заполняет карточку данными реестра: название как в ЕГРЮЛ, адрес, руководитель — вместо того, что менеджер успел напечатать. Как реестровые данные соотносятся с блоком реквизитов карточки — в статье о реквизитах. Финальный штрих — «Оборот компании по ИНН» проставляет выручку, и сегментация «крупный/средний/малый» начинает работать с первого дня жизни карточки.

Сценарий 2: стоп-проверка на стадии договора

Главная страховка ставится на стадию «Договор»: процесс запрашивает статус юрлица, и условие разводит ветки. Статус «действует» — сделка идёт дальше. Статус ликвидации или банкротства — процесс останавливает движение, ставит задачу юристу и добавляет руководителя отдела наблюдателем сделки (как работают наблюдатели — в отдельном разборе). Дополнительное условие — по выручке: контракт на сумму больше годового оборота контрагента — повод для ручной проверки, и процесс честно об этом скажет. Такая проверка не зависит от загрузки менеджера: она срабатывает на каждой сделке, дошедшей до стадии.

Сценарий 3: понятный ОКВЭД и актуализация базы

Код «62.01» в поле карточки не говорит менеджеру ничего. Робот «ОКВЭД 2: расшифровка по коду» превращает код в название вида деятельности — «Разработка компьютерного программного обеспечения» — и процесс пишет его в текстовое поле рядом. Для накопленной базы всё то же самое делается массово: процесс «проверить и дозаполнить» прогоняется по списку компаний массовым запуском — статусы, выручка и расшифровки обновляются по всей базе за один прогон, без ручного перебора карточек.

Частые вопросы

Откуда берутся данные? Из государственных реестров и бухгалтерской отчётности через сервисы данных; источник настраивается на стороне приложения, портал ходит только к роботу. Как часто актуализировать? Разумный минимум — при создании карточки и на стадии договора; для активной базы добавьте прогон по расписанию раз в квартал. Заменяет ли это полноценную проверку благонадёжности? Нет: суды, залоги и санкционные списки — отдельная глубина; роботы закрывают первый рубеж — статус, подписанта, масштаб и чистоту базы. Что с данными физлиц? Роботы работают с юридическими лицами по ИНН из карточки компании.

Итог

Проверка контрагента в Битрикс24 — это процесс, а не привычка менеджера: дубль-контроль и автозаполнение при создании карточки, стоп-условие по статусу на стадии договора, выручка и понятный ОКВЭД для сегментации. Все четыре робота — в каталоге Роботеки, ставятся из Маркета бесплатно. Нет нужного сценария — опишите задачу, сделаем робота.