Интеграция DaData с CRM: реквизиты по ИНН, проверка компаний и качество B2B-базы

Интеграция DaData с CRM полезна там, где сотрудники регулярно создают компании, готовят договоры, счета и коммерческие предложения. Если название, юридический адрес, КПП или руководитель вводятся вручную, одна организация быстро появляется в нескольких вариантах: с кавычками и без них, по бренду вместо юридического наименования, с устаревшим адресом или ошибочной цифрой в ИНН.

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

Какие задачи решает интеграция

Для B2C-процесса такая интеграция может быть избыточной, но для продаж юридическим лицам она окупается уже на этапе подготовки документов. Особенно заметен эффект, когда карточки создают несколько отделов, а данные затем уходят в бухгалтерию, ERP, ЭДО или BI.

Архитектура: подсказка, сервер и CRM

Пользовательский сценарий начинается с короткого запроса — ИНН, ОГРН или части названия. CRM или виджет передаёт его серверному интеграционному слою. Сервер обращается к API, нормализует ответ, применяет правила компании и возвращает только те поля, которые можно записать в карточку. Секрет API остаётся на сервере, а не в коде браузера.

После выбора результата CRM сначала ищет существующую компанию по нормализованному ИНН и КПП. Если карточка найдена, пользователю предлагают открыть или обновить её. Если нет — создают новую запись и сохраняют технические атрибуты: идентификатор источника, время проверки, версию маппинга и исходный статус. Документы и интеграции получают данные уже из CRM, а не вызывают внешний сервис независимо друг от друга.

Официальный метод DaData «Организация по ИНН» поддерживает поиск юридических лиц и ИП по ИНН, комбинации ИНН и КПП или ОГРН. В ответе доступны данные организации, а параметры позволяют учитывать головные компании и филиалы. Форматы сверены с документацией DaData 13 августа 2026 года.

Какие поля хранить в CRM

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

Как выглядит правильный сценарий менеджера

1. Ввод идентификатораМенеджер вводит ИНН или часть названия; CRM не требует заполнять десятки полей заранее.
2. Выбор результатаВ списке видны название, регион, статус, ИНН и КПП, чтобы отличить похожие записи.
3. Поиск дубляДо создания система проверяет компании, контакты и открытые сделки.
4. ПредпросмотрПользователь видит, какие значения будут созданы или изменены.
5. ЗаписьCRM сохраняет структурированные поля, источник и время проверки.
6. Следующее действиеКарточка готова для квалификации, договора или передачи в учётную систему.

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

Дубли, филиалы и несколько КПП

ИНН не всегда достаточно как единственного ключа. У головной организации и обособленных подразделений может совпадать ИНН, но различаться КПП и адрес. Поэтому правило уникальности зависит от модели бизнеса. Если договоры и отгрузки ведутся по филиалам, карточку идентифицируют комбинацией ИНН и КПП и связывают с головной компанией. Если продажи учитываются на уровне группы, филиалы можно хранить как дочерние объекты.

ИП и юридические лица также обрабатываются разными правилами: набор реквизитов и документов отличается. Перед объединением дублей система должна показать владельца, сделки, договоры и внешние ID обеих карточек. Автоматическое слияние только по похожему названию опасно — бренды, холдинги и одноимённые организации могут быть разными контрагентами.

Как обновлять сведения без потери данных

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

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

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

Этапы внедрения

1. Аудит карточкиСобираем поля компаний, документы, дубли и все системы-получатели.
2. Словарь данныхФиксируем назначение, формат, владельца и источник каждого реквизита.
3. Правила идентификацииОпределяем ключи для юрлиц, ИП, филиалов и групп компаний.
4. ПрототипНастраиваем поиск, выбор, предпросмотр и безопасный отказ.
5. Интеграционный слойДобавляем секреты, лимиты, кэш, повторные попытки и журнал ошибок.
6. МиграцияНормализуем активную базу партиями и отдельно разбираем конфликты.
7. ПриёмкаТестируем головную компанию, филиал, ИП, дубль, недоступный API и обновление.

Как измерить результат

Экономику считают не по числу вызовов API, а по времени сотрудников, снижению исправлений и стабильности последующих интеграций. Чистые реквизиты уменьшают стоимость каждого нового отчёта, шаблона и обмена с учётной системой.