Стандартный обмен 1С с сайтом идёт по протоколу CommerceML. 1С по расписанию отправляет на сайт файлы каталога и предложений. Сайт их разбирает и обновляет карточки товаров, а заказы отправляет обратно. Если процесс продаж завязан не только на каталог, а ещё и на CRM, настройка обмена сайта с 1С и CRM закрывает обе части одной интеграцией. Товары не выгружаются по трём частым причинам: ошибка авторизации, лимит сервера на размер файла, несовпадение идентификаторов товаров между базами. Ниже — рабочая таблица по всем частым симптомам и схема обмена по шагам, чтобы понять, на каком именно звене цепи что-то сломалось.
Как устроен обмен: схема CommerceML
CommerceML — открытый стандарт электронного обмена коммерческой информацией. Его описывает 1С, актуальная версия 2.x и XML-схема лежат на v8.1c.ru (источник: v8.1c.ru, стандарт CommerceML 2, проверено 29.09.2026). Обмен каталогом идёт двумя файлами. import.xml несёт структуру разделов, товары и их свойства — файл большой, меняется редко. offers.xml несёт цены и остатки — файл маленький, обновляется часто, иногда несколько раз в день. Заказы идут в обратную сторону: сайт формирует файл с новыми и изменёнными заказами, 1С его забирает и создаёт документы.
| Шаг | Кто инициирует | Файл | Что внутри |
| 1. Выгрузка каталога | 1С | import.xml | разделы, товары, характеристики, картинки |
| 2. Выгрузка цен и остатков | 1С | offers.xml | цены, склады, остатки по каждому товару |
| 3. Приём каталога | Сайт | — | разбор файлов, обновление карточек товаров |
| 4. Выгрузка заказов | Сайт | файл заказов CommerceML | новые и изменённые заказы с сайта |
| 5. Приём заказов | 1С | — | создание документов заказа, смена статусов |
Шаги 1–2 идут по расписанию. Каталог — ночью, раз в сутки. Остатки и цены — несколько раз днём, они меняются быстрее. Шаг 4, выгрузка заказов, может идти чаще: вплоть до режима, близкого к реальному времени, если так настроено. Разрыв между шагами — источник половины симптомов из таблицы ниже: цена или остаток на сайте всегда немного отстаёт от 1С, и вопрос лишь в том, на сколько минут или часов.
Технически обмен идёт по HTTP: 1С обращается к специальному адресу на сайте, авторизуется логином и паролем узла обмена и передаёт содержимое файла частями через POST-запросы. Сайт отвечает кодом состояния на каждый шаг — принял файл, обработал, готов к следующему. Именно на этой переписке чаще всего рвётся связь: сработал брандмауэр, истёк лимит времени запроса, сменился пароль. Кроме версии 2.x, которую используют чаще всего, существует CommerceML 3.0 и 3.1 — там к import.xml и offers.xml добавляются отдельные файлы prices.xml и rests.xml для типов цен и складов. Для среднего интернет-магазина хватает 2.x: файлов меньше, разбираться в логах проще.
Что подготовить перед первым запуском обмена
Три вещи сводят к единому виду ещё до первого запуска, иначе обмен пойдёт, но данные разъедутся. Первая — единый формат артикула на обеих сторонах. В 1С артикул «А-001», на сайте «a001» — система решит, что это два разных товара, и заведёт дубль. Вторая — соответствие категорий: раздел каталога в 1С не обязан совпадать со структурой меню на сайте, но кто-то сводит одно к другому один раз, руками или скриптом. Третья — доступ. Логин и пароль узла обмена держите в защищённом месте, доступном ограниченному числу людей, а не в общем файле настроек CMS. Тогда при следующей смене пароля не придётся вспоминать, кто и что менял последним.
Таблица симптомов: что чинить в первую очередь
Рабочий инструмент этой статьи — таблица «симптом → где смотреть → частая причина → что сделать». Десять частых ситуаций собраны по логике самого протокола: где по схеме выше должен быть файл или запись, там и ищем разрыв.
| Симптом | Где смотреть | Частая причина | Что сделать |
| Товары не появились | Лог обмена на сайте | Первая выгрузка ещё не завершена или оборвалась | Дождаться следующего цикла, проверить лог на обрыв соединения |
| Цены не обновились | Дата последней выгрузки offers.xml | Расписание для цен реже, чем для каталога | Проверить регламентное задание в 1С, время следующего запуска |
| Остатки — ноль | Настройки склада в узле обмена | К обмену не привязан склад-источник остатков | Указать нужный склад в настройках обмена на стороне 1С |
| Картинки не пришли | Каталог файлов обмена на сайте | Превышен лимит размера пакета | Уменьшить размер порции выгрузки в настройках 1С |
| Заказы не уходят в 1С | Раздел заказов в 1С | Выгрузка заказов отключена или регламент не запускается | Включить выгрузку заказов, проверить расписание задания |
| Дубли товаров | Идентификаторы (артикул, внешний код) | Несовпадение внешних кодов при повторной выгрузке | Сверить и жёстко привязать внешние коды товаров |
| Обмен «висит» | Временные таблицы CMS | Параллельно запущены два импорта | Дождаться завершения текущего, не запускать выгрузку вручную поверх |
| Ошибка авторизации | Текст ошибки в логе | Модуль обмена устарел или сменился логин/пароль | Обновить модуль обмена, проверить учётные данные узла |
| После обновления 1С-Битрикс | Версия модуля обмена | Ядро обновилось, формат обмена мог поменяться | Сверить версию модуля с обновлением ядра Битрикса |
| После переименования в 1С | Идентификаторы разделов и товаров | Переименование меняет внешний код позиции | Сопоставить старые и новые коды вручную перед следующей выгрузкой |
Половина строк решается за пять минут: посмотреть лог, найти дату, перезапустить. Вторая половина требует правки настроек с обеих сторон — и на сайте, и в 1С. Это нормально: обмен — двусторонний процесс, чинить его в одиночку с одной стороны не всегда получается.
Если сайт на 1С-Битрикс: модуль обмена, журнал и режимы
На 1С-Битрикс обмен настраивается через штатный модуль «1С-Битрикс: Управление сайтом». В 1С это раздел «Обмен с Web-сайтом», в админке сайта — парная настройка узла. Журнал обмена ведётся по каждой конфигурации отдельно и дописывается после каждого сеанса. По нему разбирают проблему без доступа к серверу 1С (источник: dev.1c-bitrix.ru, разбор типовых операций обмена, проверено 29.09.2026). Доступны три режима: полная выгрузка всех данных, выгрузка только изменений и режим, близкий к реальному времени, для заказов. Отдельного «пошагового» режима в документации нет. Есть управление размером пакета — им решают проблему лимита файла из таблицы выше. Ошибка «проверка источника запроса» из той же таблицы — вторая по частоте после лимита файла: модуль обмена посчитал запрос подозрительным и остановил сеанс. Обычно её лечит обновление модуля до актуальной версии; временное решение — отключить строгую проверку источника в настройках каталога и продаж, но держать её отключённой постоянно не стоит — это часть защиты от чужих запросов к узлу обмена.
Битрикс и 1С в связке — тема отдельного разговора о выборе CMS: плюсы и минусы 1С-Битрикс для интернет-магазина разобраны там же, включая то, где готовый обмен с 1С выигрывает у самописной интеграции. Симптомы разобрали, обмен настроен верно, а сбоит именно сама поддержка модуля — поддержка Битрикса вместе с обменом закрывает и то, и другое одним пакетом часов.
Если сайт на OpenCart или WordPress: модули и логи
На OpenCart и WordPress обмен с 1С работает через сторонние модули или плагины. Штатного механизма CommerceML в этих CMS нет. Модуль подписывается на те же файлы import.xml и offers.xml, но лог хранит там, где решил разработчик модуля — часто в отдельной директории или в таблице базы данных плагина. Найдите сначала журнал самого модуля, а не общий лог CMS: в нём видно, на каком файле и с каким кодом ответа обмен остановился. Магазин недавно перешёл или собирается переходить на новую версию платформы? Что меняется в OpenCart 4 касается и модулей обмена — часть из них требует отдельного обновления под новую версию CMS.
На WordPress с WooCommerce картина похожая: сам движок ничего не знает про 1С и CommerceML, весь обмен держится на плагине. Плагинов несколько. Они по-разному раскладывают товары по категориям, атрибутам и вариациям. Главный вопрос при выборе — как плагин разруливает конфликт, если товар пришёл из 1С с уже изменённой ценой, пока на сайте его правил вручную менеджер. Хорошие плагины логируют такой конфликт отдельной строкой и оставляют выбор человеку — плохие переписывают карточку молча, без следа в логе.
Заказы обратно в 1С: статусы, оплата, чеки
Обмен заказами — постоянный цикл, а не разовая выгрузка. Сайт создаёт заказ. 1С забирает его и присваивает статус. Дальше статус меняется в обе стороны: «оплачен» появляется на сайте, «собран» — в 1С. Отдельный вопрос — где формируется чек по 54-ФЗ. Если приём оплаты и чеки уже настроены на сайте, логичнее пробивать чек в момент оплаты, а не ждать, пока заказ дойдёт до 1С по общему расписанию. Расхождение статусов — частая причина недовольства покупателей: заказ оплачен на сайте, а в 1С ещё значится новым, потому что обмен заказами идёт реже, чем хотелось бы.
Отмена и возврат — отдельная развилка. Если покупатель отменяет заказ на сайте после того, как он уже ушёл в 1С, отмена должна вернуться обратно тем же каналом, иначе склад зарезервирует товар под заказ, которого больше нет. Частичная отгрузка — ещё сложнее: часть позиций собрали и отправили, часть — нет, и статус заказа в целом перестаёт описывать реальность. Для интернет-магазина с преимущественно готовым складом это редкость. Для B2B с позаказной сборкой — обычный рабочий день, и без явно прописанных правил «что считаем частичной отгрузкой» команда быстро расходится в трактовках.
Когда стандартного обмена мало: API, очередь, шина
Стандартный CommerceML-обмен справляется, пока схема простая: один сайт, одна база 1С, справочники не расходятся. С несколькими системами сложнее. Сайт, 1С, CRM, склад — и любая из них может стать источником изменений. В этой точке переходят на обмен через API с очередью сообщений или на интеграционную шину: она разводит потоки данных и не даёт одной упавшей системе остановить остальные. Три признака, что пора расти дальше стандартного обмена: несколько складов с разными остатками одного товара, несколько сайтов или маркетплейсов на одном каталоге, регулярные падения по лимиту файла при уже сокращённом пакете. Если ни одного из трёх нет, стандартный обмен по CommerceML обычно справляется годами без доработок. Цены на такие работы — только со страницы услуги. Интеграция с одной внешней системой (CRM, 1С, платёжный шлюз) — от 150 000 ₽. Интеграция нескольких систем и шина обмена данными — от 450 000 ₽. Поддержка и мониторинг интеграций — от 30 000 ₽ в месяц (источник: /integrations/, проверено 29.09.2026).
Частые вопросы
Как часто должен идти обмен по расписанию?
Каталог и цены — по регламенту 1С: как правило, раз в сутки для каталога и несколько раз в день для цен и остатков. Заказы можно передавать чаще. Чем ближе к реальному времени, тем меньше расхождений в статусах между сайтом и 1С.
Можно ли запустить обмен вручную, не дожидаясь расписания?
Да. В узле обмена, как правило, есть кнопка ручного запуска — она полезна после правки настроек или при разборе ошибки. Не запускайте ручной обмен поверх ещё не завершённого автоматического: это частая причина зависших сессий и временных таблиц.
Обмен работал, а после переезда на новый хостинг остановился. Что проверить сначала?
Доступность адреса обмена снаружи и корректность логина с паролем узла. При переезде чаще всего меняется IP или закрывается порт на новом сервере, и 1С не может достучаться до сайта.
Нужен ли отдельный сервер для 1С ради обмена с сайтом?
Нет. Обмен идёт по HTTP(S) от 1С к сайту и обратно. Держать 1С на выделенном сервере есть смысл по другим причинам — нагрузка базы, число пользователей, — но не ради самого обмена.
Можно ли выгружать не весь каталог, а только часть товаров?
Да, в настройках обмена задаётся план обмена с фильтром по группам или номенклатуре: можно выгружать только определённые каталоги, склады или ценовые типы. Это ускоряет каждый цикл обмена и снижает риск упереться в лимит размера файла на большом каталоге. Для интернет-магазина с десятками тысяч позиций такой фильтр часто превращает обмен из проблемной ночной задачи в рутину, которую никто не замечает месяцами.