Обмен между интернет-магазином на 1С-Битрикс, ERP и CRM редко сводится к простой передаче нескольких таблиц. В системе могут одновременно меняться товары, цены, остатки, заказы, контакты и статусы сделок. Если не договориться заранее, какая сторона отвечает за каждое поле, данные начнут перезаписываться: например, менеджер исправит телефон клиента в CRM, а очередная выгрузка из ERP вернёт старое значение.
Надёжная интеграция начинается не с выбора модуля, а с описания процессов и правил обмена. Нужно определить, что именно передаётся, кто считается источником данных и что происходит, если запись изменилась сразу в нескольких системах.
Сначала распределите ответственность за данные
Для каждого объекта и, по возможности, для каждого его поля задайте систему-владельца. ERP часто отвечает за номенклатуру, артикулы, складские остатки, закупочные цены и бухгалтерские документы. Сайт может быть источником описаний, фотографий и SEO-полей. CRM обычно хранит историю общения, задачи и этапы работы с клиентом. Но у конкретной компании распределение может быть другим — его нельзя надёжно вывести только из названия системы.
Составьте карту обмена: например, остаток идёт из ERP в магазин, заказ — с сайта в ERP, а статус обработки возвращается на сайт. Для полей с совместным редактированием установите отдельное правило: чей вариант главнее, разрешено ли автоматическое обновление и кто разбирает конфликт. Если два подразделения могут менять одно и то же поле, синхронизация без такого правила превращается в случайную борьбу за последнее слово.
Сопоставьте объекты и сохраните их идентификаторы
Одинаково названные записи в системах не обязательно являются одной и той же записью. У товара могут различаться внутренний код и артикул, у клиента — формат телефона, у заказа — номер в ERP и номер на сайте. Сопоставление только по названию или электронной почте рискованно: названия меняются, адрес может быть общим, а телефон — записан в разных форматах.
Надёжнее хранить устойчивый внешний идентификатор каждой связанной записи. При создании нового объекта интеграция должна записать его идентификатор в обеих системах или в отдельную таблицу соответствий. Повторная передача тогда обновит существующую запись, а не создаст копию. Для товаров стоит заранее определить, что служит ключом: например, уникальный артикул или код из ERP. Для заказов обычно используют идентификатор исходной системы и отдельное поле с номером, который видит сотрудник.
Отдельно проверьте справочники: единицы измерения, склады, типы цен, статусы, валюты, способы доставки и оплаты. Если одна система передаёт «Оплачен», а другая ожидает код статуса, нужно явное соответствие, а не попытка угадать значение по тексту.
Продумайте поведение при сбоях и повторной отправке
Сеть может оборваться, сервер — не ответить вовремя, а обмен — завершиться ошибкой после обработки части пакета. Поэтому сбой не должен означать, что вся операция потеряна или будет выполнена повторно с созданием дублей. Для каждого сообщения полезно фиксировать уникальный ключ, время, тип операции и результат обработки. Повторная доставка с тем же ключом должна обновить результат или подтвердить уже выполненную операцию, а не создать новый заказ.
Если обмен объёмный или не должен блокировать работу сайта, сообщения удобно обрабатывать через очередь. Тогда временный сбой ERP не обязан останавливать оформление заказов: они сохраняются для отправки, а обработчик повторяет попытку с интервалом. После нескольких неудач запись следует помещать в список ошибок для проверки, а не бесконечно гонять по кругу. В небольшом проекте достаточно журнала и понятного механизма повторной отправки; сложность решения должна соответствовать нагрузке и цене простоя.
Для передачи изменений полезны отметки времени, версии записи или журнал изменений. Один лишь запрос «забрать всё, что менялось после такого-то времени» требует аккуратной настройки: учитывайте часовые пояса, точность времени и возможное запаздывание обновления. Иначе изменения на границе интервала можно пропустить. Периодическая полная сверка помогает обнаружить расхождения, но не должна без проверки массово перезаписывать данные.
Не удаляйте записи автоматически
Удаление товара или клиента в одной системе не всегда означает, что запись нужно стереть везде. За ней могут быть связаны заказы, документы и история переписки. Часто безопаснее передавать признак активности или архивирования, сохраняя объект и его связи. Если физическое удаление всё же необходимо, заранее определите условия, порядок и возможность восстановления.
С тем же вниманием настройте обновление остатков и цен. Для магазина важно понимать, передаётся остаток одного склада или доступное для продажи количество по нескольким площадкам. Нужно также решить, что делать с нулевым остатком и временно недоступными данными: обнуление при ошибке выгрузки способно скрыть товары, хотя фактическое наличие не изменилось.
Проверяйте обмен до запуска и после него
До подключения боевых данных протестируйте не только штатный сценарий, но и ошибки: повторную отправку заказа, недоступность одной из систем, изменение записи одновременно в ERP и CRM, пустое обязательное поле, незнакомый статус. Проверьте также большой пакет данных и восстановление после прерванного обмена. В тестовой среде используйте обезличенные данные, если в них есть персональная информация.
После запуска настройте наблюдение за обменом. В журнале должны быть видны время последней успешной синхронизации, число обработанных записей, ошибки и идентификаторы проблемных объектов. Полезны уведомления о задержке очереди, росте числа отказов и необычном падении количества передаваемых товаров или заказов. Само наличие статуса «обмен выполнен» ещё не доказывает, что все поля обновились верно: периодически сверяйте количество записей и выборочные значения между системами.
Наконец, зафиксируйте, кто отвечает за разбор ошибок и как безопасно повторить обработку. Изменения формата, структуры каталога или логики статусов сначала проверяйте на копии и документируйте. Когда у каждой записи есть устойчивый ключ, у каждого поля — понятный источник, а у сбоя — контролируемый сценарий, синхронизация перестаёт быть невидимым риском и становится процессом, который можно проверять и восстанавливать.
