Интеграция сайта с учётной системой: где обмен ломается и как это ловить

Что вообще передавать: минимальный и расширенный набор

Первая ошибка большинства проектов — попытка синхронизировать всё. Чем больше полей в обмене, тем больше мест, где он сломается.

Минимальный набор, с которого стоит начинать: артикул (по нему сопоставляются товары), название, цена, остаток, признак «показывать на сайте». Этого хватает, чтобы магазин работал корректно.

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

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

Отдельно решается направление обмена по каждому полю. Цена и остаток идут из учётной системы на сайт. Заказы — с сайта в учётную систему. А вот описания и фотографии почти всегда должны жить на сайте и в обмене не участвовать.

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

Что ломается чаще всего: пять сценариев

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

2. Товары рассыпались из-за смены артикула. Сопоставление идёт по артикулу, а менеджер изменил его в карточке. Товар на сайте превращается в новый, теряя адрес страницы, накопленные позиции и отзывы. Лечится тем, что сопоставление ведётся по неизменяемому внутреннему коду, а не по артикулу.

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

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

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

Как настроить контроль: три уровня

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

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

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

<form action="/api/lead" method="post">
  <label>Телефон или почта
    <input name="contact" autocomplete="email" required>
  </label>
  <input type="hidden" name="page" value="/service/">
  <button type="submit">Отправить</button>
</form>

Порядок внедрения: как не сорвать сроки

Интеграция — та часть проекта, которая чаще всего задерживает запуск. Порядок, при котором этого не происходит:

Шаг 1. Согласовать поля на бумаге. Таблица: поле, откуда берётся, куда пишется, кто главный, как часто обновляется. Полчаса работы, снимает большую часть будущих споров.

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

Шаг 3. Запустить обмен на части каталога. Одна категория, ручной запуск, сверка глазами. Ошибки на этом этапе стоят минут, а не дней.

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

Шаг 5. Включить расписание и контроль. И только после этого — запуск на боевом сайте.

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

Разбор сбоя: как выглядит расследование по шагам

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

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

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

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

Шаг 4. Смотрим на признак показа. Иногда товар обновляется корректно, но остаток передаётся по одному складу из нескольких, а продажа идёт со всех.

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

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

Как выбрать частоту обмена

Универсального ответа нет, но есть простой способ прийти к нужному числу: посчитать, сколько стоит одна ошибка.

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

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

Компромиссный вариант для большого каталога — полная выгрузка раз в сутки ночью и частая передача только изменившихся позиций днём. Это снимает нагрузку и сохраняет актуальность.

Кто за что отвечает: разграничение до начала работ

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

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

Разумно также договориться о времени реакции: сколько часов есть на ответ при остановке обмена. Для магазина, где обмен обновляет остатки, сутки — уже дорого.