Интеграция сайта с учётной системой: где обмен ломается и как это ловить
6 мин чтенияЦены на сайте вчерашние, товар в наличии оказался распродан, заказы не доезжают до менеджера. Разбор типовых сбоев обмена и того, как настроить контроль, чтобы узнавать о них первым.
- Договориться, какая система главная по каждому полю, важнее, чем выбрать способ обмена
- Обмен ломается тихо: сайт продолжает работать и показывать устаревшие данные
- Уведомление о том, что обмен не проходил дольше N часов, — самая полезная настройка проекта
- Не всё нужно передавать: чем меньше полей в обмене, тем меньше поводов для поломки
- Заказы стоит дублировать на почту — это дешёвая страховка на случай сбоя
- Что вообще передавать: минимальный и расширенный набор
- Что ломается чаще всего: пять сценариев
- Как настроить контроль: три уровня
- Порядок внедрения: как не сорвать сроки
- Разбор сбоя: как выглядит расследование по шагам
- Как выбрать частоту обмена
- Кто за что отвечает: разграничение до начала работ
- Вопросы и ответы
Что вообще передавать: минимальный и расширенный набор
Первая ошибка большинства проектов — попытка синхронизировать всё. Чем больше полей в обмене, тем больше мест, где он сломается.
Минимальный набор, с которого стоит начинать: артикул (по нему сопоставляются товары), название, цена, остаток, признак «показывать на сайте». Этого хватает, чтобы магазин работал корректно.
Расширенный набор, который добавляют вторым этапом: характеристики, категории, изображения, единицы измерения, скидки и цены для разных групп покупателей.
Что обычно передавать не нужно: описания товаров и тексты категорий. Их пишут под продвижение, и учётная система для этого не приспособлена — при следующей выгрузке аккуратно написанный текст затирается тем, что менеджер вбил в карточку номенклатуры.
Отдельно решается направление обмена по каждому полю. Цена и остаток идут из учётной системы на сайт. Заказы — с сайта в учётную систему. А вот описания и фотографии почти всегда должны жить на сайте и в обмене не участвовать.
Правило, которое стоит зафиксировать письменно до начала работ: для каждого поля названа главная система. Если её нет, две системы будут по очереди затирать данные друг друга, и виноватого не найти.

Что ломается чаще всего: пять сценариев
1. Изменился формат выгрузки. Обновили учётную систему или доработали конфигурацию — и структура файла поменялась. Сайт продолжает работать, но данные перестают обновляться. Самый частый и самый незаметный сбой.
2. Товары рассыпались из-за смены артикула. Сопоставление идёт по артикулу, а менеджер изменил его в карточке. Товар на сайте превращается в новый, теряя адрес страницы, накопленные позиции и отзывы. Лечится тем, что сопоставление ведётся по неизменяемому внутреннему коду, а не по артикулу.
3. Обмен упал по времени. Каталог вырос, выгрузка перестала укладываться в лимит времени на сервере и обрывается на середине. Признак — обновляется только часть товаров, всегда одна и та же.
4. Заказы не доезжают. Сайт принял заказ, а в учётной системе его нет: не совпал формат, не заполнено обязательное поле, недоступна служба обмена. Для магазина это прямые потери, поэтому заказы всегда стоит дублировать на почту.
5. Остатки обновляются реже, чем нужно. Обмен раз в сутки для магазина с быстрым оборотом означает, что часть заказов оформляется на товар, которого уже нет. Это не поломка, а неверно выбранная частота.
Как настроить контроль: три уровня
Главная особенность сбоев обмена в том, что они тихие: сайт работает, страницы открываются, никто ничего не замечает. Поэтому контроль настраивается отдельно.
| Уровень | Что проверяет | Как узнаёте | Настройка |
|---|---|---|---|
| 1. Факт обмена | обмен проходил за последние N часов | письмо или сообщение в мессенджер | 15 минут |
| 2. Объём данных | число обновлённых товаров не упало резко | то же уведомление с цифрой | час |
| 3. Выборочная сверка | цена и остаток по 10 товарам совпадают | отчёт раз в неделю | несколько часов |
Первый уровень обязателен всегда и окупается на первом же сбое. Второй ловит обрыв выгрузки на середине — случай, когда обмен формально прошёл, но обновилась половина каталога. Третий нужен магазинам, где ошибка в цене стоит дорого.
Отдельно стоит договориться, кто получает эти уведомления. Если они уходят только подрядчику, вы узнаете о проблеме от клиента.
Порядок внедрения: как не сорвать сроки
Интеграция — та часть проекта, которая чаще всего задерживает запуск. Порядок, при котором этого не происходит:
Шаг 1. Согласовать поля на бумаге. Таблица: поле, откуда берётся, куда пишется, кто главный, как часто обновляется. Полчаса работы, снимает большую часть будущих споров.
Шаг 2. Проверить качество данных в учётной системе. Это узкое место почти всех проектов: у половины товаров нет характеристик, названия написаны сокращениями, единицы измерения не заполнены. Сайт покажет ровно то, что есть, и разбирать это придётся заказчику.
Шаг 3. Запустить обмен на части каталога. Одна категория, ручной запуск, сверка глазами. Ошибки на этом этапе стоят минут, а не дней.
Шаг 4. Прогнать полный обмен и замерить время. Если выгрузка идёт близко к лимиту, увеличивать каталог уже нельзя — нужно менять схему на передачу только изменившихся позиций.
Шаг 5. Включить расписание и контроль. И только после этого — запуск на боевом сайте.
Пропуск второго шага — самая частая причина срыва сроков. Разработка готова, а данных для наполнения нет, и подготовка номенклатуры занимает недели, о которых никто не договаривался.

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