Обмен 1С с сайтом: почему остатки расходятся и как это чинится

Интеграция 1С с сайтом почти никогда не ломается громко. Она ломается частично: большая часть данных ходит нормально, а какая-то доля позиций живёт своей жизнью. Логи при этом чистые, обмен «прошёл успешно», и заметить расхождение можно только когда клиент оплатил товар, которого нет.

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

Почему обмен 1С с сайтом видит не все изменения

Большинство интеграций работают по принципу «отдай то, что изменилось с прошлого раза». Это экономно и быстро. Но выборка изменений обычно не включает архивные и удалённые позиции — их просто нет в ответе.

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

Лечится не переделкой обмена, а добавлением к нему регулярной полной сверки: раз в сутки сравнить списки целиком и привести флаги в соответствие.

Причина вторая: остатки считаются по разным правилам

В 1С остаток — это не одно число. Есть физический остаток на складе, есть зарезервированное под заказы, есть доступное к продаже. Сайту нужно доступное, а выгружают часто физическое, потому что его проще получить.

Результат: на сайте видно десять штук, из которых восемь уже зарезервированы под чужие заказы. Формально данные верные, практически — сайт продаёт чужой товар.

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

Причина третья: обмен падает молча

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

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

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

Причина четвёртая: разные ключи товара

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

Дубли обычно и есть первый видимый симптом: в каталоге появляются одинаковые товары с разными остатками. Чинится переходом на неизменяемый идентификатор — внутренний код 1С, — а не на то, что удобно человеку.

Как проверить свой обмен

Проверка занимает вечер и не требует доступа к коду интеграции.

• Посчитайте активные позиции в 1С и карточки на сайте. Цифры должны сходиться; расхождение больше процента — уже повод разбираться.
• Возьмите пять товаров и сверьте остатки вручную: в 1С, на сайте и фактически на складе.
• Отправьте один товар в архив в 1С и посмотрите, что произойдёт на сайте в течение суток.
• Найдите в каталоге сайта дубли по названию — их наличие говорит о проблеме с ключом сопоставления.
• Спросите подрядчика, что происходит, когда часть выгрузки не доходит. Ответ «обмен сообщит об ошибке» проверьте на практике.

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