Интеграция МойСклад и Битрикс24: что синхронизировать и как не сломать учёт

Интеграция МойСклад и Битрикс24: что синхронизировать и как не сломать учёт

Компании, которые продают товар, обычно держат две системы: склад и закупки живут в МойСклад, продажи и клиенты в Битрикс24. Пока заказов немного, менеджеры переносят данные руками и всех это устраивает. С ростом оборота такой перенос становится источником ошибок: клиенту обещают позицию, которой на складе уже нет, один заказ заводят дважды, а руководитель не может сопоставить выручку в CRM с реальными отгрузками. Разберём, что имеет смысл синхронизировать между системами, какие есть способы их связать и где интеграции обычно ломаются.

Что происходит, пока системы живут отдельно

Типичный набор проблем выглядит так:

• Менеджер продаёт вслепую. Актуальные данные о товаре лежат на складе, в карточке сделки их нет. Проверять наличие приходится вручную, а в разговоре с клиентом на это нет времени.
• Заказ заводится дважды. Сначала сделка в CRM, потом заказ на складе. Данные вводит человек, поэтому расхождения появляются на второй же неделе.
• Номенклатура расходится. В CRM менеджеры называют товар по-своему, на складе он заведён по артикулу. Свести одно с другим потом стоит дороже, чем настроить обмен сразу.
• Отчётность не сходится. Руководитель видит сумму сделок в CRM и сумму отгрузок на складе, и эти цифры не совпадают.

Что синхронизируется между системами

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

Скриншот 1. Типовой набор обмена. Точный состав зависит от выбранного приложения.

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

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

Три способа связать МойСклад и Битрикс24

• Готовое приложение из Битрикс24.Маркет. Самый быстрый путь: ставится за вечер, настраивается через интерфейс, стоит недорого. Ограничение в том, что набор сценариев обмена в нём фиксированный. Как настраивается такое приложение, мы разобрали в отдельной пошаговой инструкции.
• Приложение из магазина приложений МойСклад. Та же логика, но подключение начинается со стороны складской системы. Решение стороннее и платное, разработчик у него свой.
• Своя интеграция по API. Битрикс24 и МойСклад открывают программные интерфейсы, поэтому обмен можно собрать под конкретный процесс: свои правила сопоставления товаров, своя логика статусов, обработка нестандартных документов. Этот путь дороже и дольше, зато он не упирается в чужой набор сценариев.

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

Что решить до подключения

Половина проблем с интеграцией появляется не из-за техники, а из-за того, что заранее не договорились о правилах. До настройки обмена стоит ответить на четыре вопроса:

1. Какая система главная по номенклатуре. Обычно это складская: товары заводятся там и уходят в CRM. Важно, чтобы это правило было одно на всю компанию.
2. Какая система главная по контрагентам. Клиентов чаще ведут в CRM, но если на складе уже накоплена база с реквизитами, порядок сопоставления нужно продумать отдельно.
3. Какие документы участвуют в обмене. Счета, заказы, отгрузки: чем меньше сущностей в обмене на старте, тем проще его отладить.
4. Что происходит при одновременном изменении. Если запись правят с двух сторон, система должна знать, чьё изменение принимать.

Отдельного внимания заслуживает первая загрузка. К моменту подключения в обеих системах уже накоплены данные: на складе тысячи позиций, в CRM сотни контрагентов, и часть из них описывает одни и те же объекты под разными названиями. Если включить обмен сразу, интеграция попытается сопоставить всё это автоматически и там, где не найдёт совпадения, создаст новые записи. Так за одну ночь база может удвоиться.
Поэтому первую загрузку делают отдельным этапом: выгружают справочники из обеих систем, сводят пары вручную или по ключевому полю, закрывают явные дубли и только после этого включают регулярный обмен. Это самая трудоёмкая часть подключения, и именно её чаще всего недооценивают при планировании сроков.

Где интеграции обычно ломаются

Технически обмен настраивается быстро. Разваливается он потом, и почти всегда по одним и тем же причинам.

• Сопоставление по названию вместо кода. Если системы узнают товар по наименованию, любое расхождение в пробеле, регистре или разделителе создаёт вторую карточку. «Кабель ВВГ 3х2,5» и «Кабель ВВГ 3х2.5» для человека одно и то же, для обмена это две разные позиции. Через месяц в каталоге живут пары почти одинаковых товаров, и остатки по ним считаются раздельно.
• Единицы измерения и кратность. На складе позиция заведена в упаковках по двенадцать штук, менеджер в CRM продаёт штуками. Если при обмене количество переносится числом без пересчёта, заказ на двенадцать штук уезжает на склад как двенадцать упаковок. Такие ошибки обнаруживаются уже после отгрузки.
• Несколько типов цен. В складской системе у товара может быть розничная, оптовая и специальная цена, а в карточке сделки поле цены одно. Пока явно не указано, какой тип забирать в CRM, в сделку попадает первый по списку, и менеджер выставляет счёт не по той цене.
• Контрагенты без обязательного ключа. Клиент заведён в CRM как компания по названию, а на складе как контрагент с ИНН. Без поля, по которому системы обязаны узнавать одну и ту же организацию, каждый обмен добавляет к паре ещё одну запись. Отдельная разновидность той же проблемы: у клиента есть юрлицо и ИП, в одной системе они разведены, в другой слиты в одну карточку.
• Неполная карта статусов.Стадий у сделки обычно больше, чем статусов у заказа на складе. Если соответствие описано не для всех стадий, сделка уходит вперёд, а заказ остаётся в прежнем статусе, и склад просто не видит, что пора собирать.
• Правки с двух сторон между сеансами обмена. Когда обмен идёт по расписанию с интервалом, запись успевают поправить в обеих системах. Побеждает то изменение, которое синхронизировалось последним, и второе тихо теряется. Чем реже сеансы обмена, тем чаще это происходит.

Что делать, когда данные разошлись

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

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

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

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

Где готовое приложение перестаёт справляться

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

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

С чего начать

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

1. Опишите, какие данные и в какую сторону должны ходить между системами.
2. Назначьте главную систему по номенклатуре и по контрагентам.
3. Приведите справочники к общему виду до первого обмена: единицы измерения, категории, ставки.
4. Запустите обмен на ограниченном наборе данных и сверьте результат.
5. Заведите регулярную сверку.

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

Коротко

МойСклад и Битрикс24 связывают, чтобы менеджер видел товар в карточке сделки, заказ заводился один раз, а отчётность сходилась. Обмен реализуют сторонние платные приложения из Битрикс24.Маркет или из магазина МойСклад, а для нестандартных сценариев собирают интеграцию по API. Успех зависит от подготовки: назначить главную систему по каждой сущности, привести справочники к общему виду, задать правила сопоставления и завести регулярную сверку.

Об авторе

Карпук Василий

Основатель и директор по маркетингу и развитию в «Соль». Руководит продажами с 2008 года и внедряет CRM с 2012 года; за это время вместе с командой реализовал более 500 проектов по автоматизации бизнеса. Автор статей о продажах, маркетинге и внедрении корпоративных систем. Ведущий подкаста «Пуд Соли», где вместе с экспертами обсуждает технологии, бизнес и эффективное управление.