Две системы, которым нужно обмениваться данными, — это как два человека, которым нужно договориться о работе. Пока они обсуждают всё на словах, кажется, что поняли друг друга. А потом выясняется, что один имел в виду одно, второй — другое, и результат не устроил никого. Интеграция ломается не потому, что код плохой, а потому что договорённость неполная.
Поэтому обмен данными удобно рассматривать как договор. В нём есть стороны, предмет, формат, сроки и ответственность. Если хотя бы один пункт не согласован, интеграция работает «как-нибудь», а не как задумано. Разберём эти пункты по порядку.
Пункт 1. Стороны: кто с кем договаривается
Первое, что стоит зафиксировать, — участники обмена. Не «сайт и 1С», а конкретно: какая система, в какой версии, через что общается. Сайт на WordPress с WooCommerce, CRM в облаке, 1С на локальном сервере — у каждого участника свои ограничения.
Иногда в цепочке есть посредник: плагин, сервис-интегратор, промежуточная база. Его тоже нужно назвать стороной, иначе при сбое непонятно, к кому идти. И сразу определите, кто отвечает за каждую сторону: разработчик сайта, администратор 1С, подрядчик по CRM.
Пункт 2. Предмет: что именно передаётся
Дальше нужно перечислить, какие данные ходят между системами и в какую сторону. Обычно это товары, цены, остатки, заказы, статусы, контакты клиентов. Но важно не просто назвать категорию, а перечислить поля.
Например, не «передаём заказы», а «передаём номер заказа, состав, сумму, контакт, адрес доставки, способ оплаты и комментарий». Чем подробнее список, тем меньше сюрпризов. И для каждого поля укажите, в какую сторону оно идёт: цена — только из 1С на сайт, комментарий клиента — только с сайта в 1С.
Пункт 3. Формат: на каком языке говорить
Одни и те же данные в разных системах выглядят по-разному. Телефон может быть строкой или числом, дата — в одном формате или в другом, а имя — с отчеством или без. Если формат не согласован, данные доходят, но в неудобном виде.
Здесь стоит договориться о простых правилах: как выглядит телефон, как записывается дата, что делать с пустыми полями, как передаётся цена с копейками. Это кажется мелочью, но именно на таких мелочах чаще всего возникают ошибки — система не понимает формат и молча пропускает запись.
Пункт 4. Кто главный: источник истины
Самый важный пункт, который часто обходят. По каждому типу данных должен быть один хозяин. Если цену меняют и на сайте, и в 1С, при следующем обмене они будут перезаписывать друг друга по кругу, и никто не поймёт, какая цена настоящая.
Обычно источник истины очевиден: остатки и цены — в системе учёта, заказы — на сайте, статусы — там, где с ними работает менеджер. Но это нужно проговорить и зафиксировать, а не оставлять на догадки. Иначе через месяц появится вопрос «а почему у нас две разные цены на один товар».
Пункт 5. Сроки: когда происходит обмен
Ещё один пункт, который редко обсуждают заранее. Обмен может идти по расписанию, по событию или вручную. Цены и остатки обычно обновляются по расписанию — раз в час или чаще. Заказы — сразу, по событию. Справочники — раз в сутки.
Важно, чтобы эти сроки соответствовали реальности. Если остатки обновляются раз в сутки, а магазин продаёт последнюю единицу каждый час, покупатели будут заказывать товар, которого уже нет. Здесь нет универсального ответа, но должно быть понимание: как часто данные меняются и как быстро они должны доходить.
Пункт 6. Что делать, если что-то пошло не так
Любая интеграция рано или поздно даёт сбой: сервер недоступен, ответ пришёл с ошибкой, сеть пропала на минуту. Вопрос не в том, случится ли это, а в том, что произойдёт.
Хороший договор предусматривает поведение при ошибке. Данные должны сохраниться и уйти повторно, а не исчезнуть. Должен быть виден список неудачных обменов. И должно быть понятно, кто и как часто смотрит на этот список. Если этого нет, ошибки копятся молча, пока кто-нибудь не пожалуется.
Пункт 7. Как проверить, что договор работает
Проверка — это тоже часть договорённости. Пройдите путь данных целиком на реальных примерах: измените цену в системе учёта и посмотрите, обновилась ли она на сайте; оформите заказ и проверьте, дошёл ли он до CRM; смените статус и убедитесь, что он вернулся обратно.
Затем проверьте неудобные случаи: товар без цены, заказ с пустым комментарием, клиент без отчества. Именно на них интеграция чаще всего и ломается. И договоритесь, как часто вы будете смотреть на результат: раз в день, раз в неделю, после каждой крупной правки.
Красные флаги
- Никто не может сказать, какая система — источник истины по цене.
- Список передаваемых полей существует только в голове разработчика.
- Формат телефона и даты нигде не описан.
- Ошибки обмена нигде не фиксируются.
- При сбое данные просто теряются.
- Проверка проводилась на одном тестовом товаре.
- Никто не знает, кто отвечает за интеграцию после сдачи.
Что в итоге
Согласовать обмен данными — это не написать код, а договориться о семи вещах: стороны, предмет, формат, источник истины, сроки, поведение при ошибке и способ проверки. Если всё это проговорено, интеграция живёт годами. Если нет — её приходится чинить после каждой жалобы клиента.
Мы обычно начинаем интеграцию именно с такого «договора»: собираем стороны и поля, договариваемся о формате и главном источнике данных, а потом уже настраиваем обмен и проверяем его на реальных сценариях. Иногда на этом этапе выясняется, что часть данных вообще не нужно передавать. Напишите или оставьте заявку — разберём вашу цепочку и скажем, что стоит согласовать в первую очередь, чтобы данные не терялись между системами.