Собственные разработки в реестре российского ПО Санкт-Петербург · работаем по всей России
ГлавнаяРазработкаИнтеграции
Обмен данными

Интеграции систем и обмен данными

integration

Связываем учётные системы, CRM, склад, телефонию и внешние сервисы так, чтобы данные не переносили руками и не сверяли файлами. Каждый обмен ведёт журнал: видно, что ушло, что не доехало и почему.

С чего начинается интеграция
Что связываем

Системы и сервисы

systems

Со стороны, где есть штатный программный интерфейс, работаем через него. Где интерфейса нет, разбираем выгрузки, файлы обмена и протоколы оборудования — задача решаема почти всегда, вопрос в трудоёмкости.

Номенклатура, контрагенты, счета, оплаты, отгрузки и остатки. Обычно самая объёмная часть проекта и хозяин большинства справочников.

Битрикс24 и CRM

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

Склад и WMS

Остатки по местам хранения, приёмка, отбор и инвентаризация. Резерв под заказ виден до того, как товар обещали клиенту.

Телефония

Звонки привязываются к клиенту и сделке, записи разговоров доступны в карточке, пропущенный звонок становится задачей.

Почта и мессенджеры

Переписка попадает в историю по клиенту, а не остаётся в личном ящике сотрудника. Уведомления уходят туда, где человек их прочитает.

Маркетплейсы и сайт

Заказы приходят в единую очередь обработки, цены и остатки уезжают обратно. Оператор не копирует строки между кабинетами.

Оборудование и телеметрия

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

Внешние сервисы

Платёжные, логистические и государственные сервисы, справочники контрагентов, электронный документооборот.

Складскую часть подробнее разбираем в разделе Автоматизация склада, работу внутри CRM — в разделе Битрикс24.

Первый вопрос

Кто главный по каждой сущности

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

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

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

Типовые потоки

Сценарии обмена

scenarios

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

Справочники

Товары, услуги и контрагенты создаются в системе-хозяине и расходятся в остальные с сохранением связки по идентификатору.

Одно направление, по расписанию

Заказы и документы

Сделка из CRM становится заказом в учёте, счёт и отгрузка возвращаются обратно вместе со статусом и суммой.

Две стороны, по событию

Остатки и цены

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

Часто и небольшими порциями

События и уведомления

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

В момент возникновения
Качество данных

Дубли и сопоставление справочников

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

  • Связка по идентификатору, а не по названию. У каждого объекта хранится ссылка на его пару в другой системе — переименование не рвёт связь
  • Разбор существующих дублей. До запуска сводим повторы, выбираем основную запись и переносим на неё историю
  • Правила поиска пары. Для контрагентов — по реквизитам, для товаров — по артикулу и штрихкоду, а не по строке наименования
  • Ручное сопоставление там, где машина не уверена. Спорные пары попадают в отдельный список, решение принимает человек
  • Запрет на создание вслепую. Если пара не найдена, объект не плодится молча — обмен спрашивает, а не догадывается

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

Проектная разработка
Контроль

Журнал обмена и работа с ошибками

control

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

  • Каждая передача записывается: что, когда, в какую сторону и с каким результатом
  • Не прошедшие записи хранятся целиком, вместе с текстом ошибки, — их видно, а не приходится восстанавливать по памяти
  • Повторная отправка выполняется кнопкой, без правки данных руками и без обращения к разработчику
  • Повторы идут автоматически с нарастающим интервалом, а не одной попыткой в момент, когда другая сторона недоступна
  • Ответственный получает уведомление, если обмен встал или ошибки повторяются, — до того, как это заметит клиент
  • Одно и то же сообщение не применяется дважды: повтор не удваивает документ и не задваивает оплату
Режим и сопровождение

Разовая выгрузка или постоянный обмен

mode

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

Разовый перенос

Переезд на новую систему, объединение баз, сверка перед закрытием периода. Делается один раз, с проверкой объёмов и контрольной сверкой.

Постоянный обмен

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

Обновления систем

Перед обновлением 1С или платформы обмен прогоняется на тестовом контуре, после — проверяется по списку сценариев и правится при изменении форматов.

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

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

Что спрашивают про интеграции

faq
Данные будут ходить в обе стороны?

Не всегда, и это осознанный выбор. Двусторонний обмен нужен там, где объект реально меняется в обеих системах, — например, статус заказа. В остальных случаях направление одно: у справочника есть хозяин, и он диктует значение. Двусторонний обмен без правил разрешения конфликтов рано или поздно приводит к тому, что данные затирают друг друга.

Как часто данные будут обновляться?

Зависит от того, что происходит с данными между обновлениями. Остатки и цены обычно гоняют по расписанию — раз в несколько минут или раз в час. События, на которые кто-то реагирует сразу, передают в момент возникновения. Ночной обмен большими объёмами дешевле и проще, но для оперативной работы бесполезен, поэтому режим выбираем по каждому потоку отдельно.

Что будет, если внешний сервис не отвечает?

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

Сколько занимает подключение обмена?

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

Обмен переживёт обновление 1С или платформы?

Если он написан по правилам платформы — да. Мы не правим ядро и типовые механизмы, а работаем через расширения и штатные точки расширения. Перед обновлением обмен прогоняется на тестовом контуре, после обновления проверяется по контрольному списку сценариев. Так изменения на одной стороне не превращаются в тихую поломку на другой.

Можно ли обойтись разовой выгрузкой вместо постоянного обмена?

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

Старт проекта

Расскажите, что с чем нужно связать

Назовите системы на обоих концах и данные, которые сейчас переносят руками, — посмотрим оба конца обмена и назовём порядок сроков и стоимости.

Позвонить Telegram-канал