Обмен 1С с интернет-магазином: что ломается на остатках и комплектах

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

Как устроен обмен и где в нём слабое место

В типовой схеме 1С выгружает два файла: import.xml — товары, свойства, категории, и offers.xml — предложения: цены, остатки, характеристики. Сайт их забирает и раскладывает по своей базе.

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

1. Частичный обмен вместо полного

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

Выглядит это так: в 1С доступно 240 позиций, на сайте видно 180, и разница ничем не объясняется — товары есть, они активны, они просто не приезжали. Мы разбирали ровно такой случай у производителя: полный обмен оказался выключен, после включения число доступных позиций выросло со 180 до 240, а количество единиц — до 1126.

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

2. Комплекты приезжают без состава

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

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

Решение — считать это на стороне сайта: хранить состав комплекта и выводить минимум по компонентам. У нас на такой схеме из 355 комплектов с описанным составом покупаемыми оказались 180 позиций общим объёмом 816 штук — при том что до расчёта все они показывались как недоступные.

Отдельная засада: у части комплектов состав в 1С не заполнен вообще. Никакой код это не исправит — это работа на стороне учёта, и её надо ставить в задачу заказчику явно, а не надеяться, что «данные подтянутся».

3. Характеристики заполнены не так, как ожидает сайт

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

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

4. Цены: какая из них настоящая

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

Проверять надо не «цены выгрузились», а «цена на сайте равна цене из нужного столбца» — на выборке в несколько сотен позиций, а не на трёх любимых товарах. Мы на одном проекте сверяли 880 значений: расхождений оказалось ноль, но узнали мы это только потому, что сверили все, а не выборочно.

Отдельно стоит проверить мусор в исходных данных: строки вида «3…50» вместо числа, пробелы, единицы измерения внутри поля цены. Такие значения парсер тихо приводит к нулю, и товар выходит на витрину с ценой 0 ₽.

5. Картинки закешированы навсегда

Изображения товаров обычно отдаются с заголовком долгого кеширования — это правильно для скорости. Но при обмене файл с тем же именем перезаписывается новым содержимым, а браузеры и CDN продолжают показывать старое. Менеджер меняет фото в 1С, на сайте ничего не происходит, и все решают, что обмен сломался.

Лечится версионированием: к адресу картинки добавляется метка изменения файла. Имя остаётся прежним, адрес меняется, кеш обновляется сам.

6. Обмен упирается в защиту сайта

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

Служебный маршрут обмена нужно выносить из-под этих проверок целиком и защищать отдельно — отдельным ключом и ограничением по адресу источника. Пытаться «подружить» 1С с общей авторизацией сайта — потерянное время.

Как принимать такую работу

Чек-лист, который стоит пройти до того, как считать интеграцию сделанной:

1. Число активных позиций на сайте совпадает с числом в 1С — не примерно, а точно.
2. Полный обмен запускается по расписанию, а не только вручную.
3. Для комплектов выводится доступное количество, посчитанное по компонентам.
4. Цена на сайте сверена с нужным типом цены на выборке в сотни позиций.
5. Изменение фотографии в 1С видно на сайте после следующего обмена.
6. Товар с нулевым остатком показывается как «под заказ», а не исчезает из каталога.
7. Есть журнал обменов, в который пишутся расхождения, и кто-то его смотрит.

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