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

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

Коротко. Стандартный обмен 1С с сайтом работает по протоколу CommerceML: 1С сама подключается к сайту, передаёт каталог (import.xml) и цены с остатками (offers.xml), а затем сама забирает с сайта новые заказы. Остатки расходятся из-за редкого обмена, лишних складов в выгрузке, резервов, оборванных и частичных выгрузок. От сбоев защищают предохранители на стороне сайта: не снимать товары с продажи, если выгрузка внезапно «усохла», и вести журнал обмена. С ИИ-разработкой обмен для каталога на 15 тысяч товаров укладывается в полторы недели.

Как работает обмен 1С с сайтом: кто кого вызывает

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

У такой схемы есть приятное следствие: офису не нужен «белый» IP-адрес и проброс портов. 1С ходит наружу так же, как браузер бухгалтера, поэтому обмен работает и с ноутбука, и из облачной 1С.

Протокол описан в документации самой 1С (протокол обмена с сайтом). Выгрузка каталога — это четыре шага, каждый из которых — HTTP-запрос с параметрами type и mode:

1. type=catalog&mode=checkauth
   сайт проверяет логин и пароль → «success» + имя и значение cookie сеанса
2. type=catalog&mode=init
   сайт сообщает, принимает ли архив (zip=yes/no) и сколько байт за раз (file_limit)
3. type=catalog&mode=file&filename=import.xml
   1С отправляет файл POST-запросом, большой — по частям
4. type=catalog&mode=import&filename=import.xml
   сайт разбирает файл → «progress», «progress»… «success»
   (шаги 3–4 повторяются для offers.xml)

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

Что лежит в import.xml и offers.xml

Выгрузка из 1С на сайт состоит из двух основных файлов в формате CommerceML:

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

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

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

Версии формата тоже различаются. У магазина мототехники «1С:Управление торговлей» 10.3 выгружает CommerceML 2.03, у магазина стройматериалов выгрузка приходит в версии 2.07. Структура похожа, но отличается в деталях, и разборщик на сайте должен знать, с какой версией имеет дело.

Заказы: 1С забирает их сама

С заказами логика та же — инициатор 1С, только type=sale:

type=sale&mode=checkauth → type=sale&mode=init
type=sale&mode=query     сайт отдаёт XML с новыми заказами
type=sale&mode=success   1С подтверждает, что записала их у себя
type=sale&mode=file      1С присылает изменения заказов, например статусы

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

Что нужно от 1С и от программиста 1С

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

• Какая конфигурация и версия: например, «Управление торговлей» 10.3 или 11, и какую версию CommerceML она выгружает.
• Узел обмена с сайтом: адрес, логин, пароль, расписание (раз в час, раз в 15 минут).
• Что выгружать: весь каталог или отдельные группы, какой вид цены — розничный, какие склады — только те, с которых реально продают.
• Картинки: выгружаются ли вообще и какого они размера в базе.
• Заказы: каким документом их записывать в 1С, как находить покупателя, что делать с новыми.
• Статусы: какие статусы из 1С должен видеть покупатель на сайте.
• Кто отвечает за обмен в компании: кто посмотрит журнал, если выгрузка не пришла.

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

Почему остатки на сайте и в 1С расходятся

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

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

Лишние склады. В одном из магазинов в выгрузке было 8 складов, среди них «Недовоз» и «Брак, возврат». Если сложить остатки по всем, сайт начнёт продавать бракованный товар и то, что ещё едет от поставщика. На витрину должны идти только продажные склады.

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

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

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

Отстающие фото. Папка с картинками в выгрузке может отставать от XML: товар уже появился, а фото к нему приедут со следующим обменом. Новые позиции какое-то время висят без картинок, и это нормально, если сайт умеет их потом подхватить.

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

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

Предохранители: что сайт должен делать с подозрительной выгрузкой

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

• Порог усыхания. У магазина мототехники в Вологодской области правило такое: если полная выгрузка вдруг «теряет» больше половины товаров, товары с продажи не снимаются. Это признак оборванной выгрузки, а не закрытия магазина. У магазина стройматериалов порог строже: полная выгрузка, «усохшая» больше чем на 30 %, не применяется вовсе.
• Частичные выгрузки — только слиянием. Файл «только изменения» вливается в каталог по идентификатору товара и ничего не удаляет.
• Состояние до первого обмена. Пока обмена ещё не было, товары показываются «в наличии» — иначе весь каталог выглядел бы недоступным в день запуска.
• Надёжный якорь. В одной выгрузке артикулы были пустые у всех 641 товара, неповторяющимся оказался только код 1С — он и стал ключом для обмена. Наименование ключом быть не может: его переименуют, и сайт создаст дубль.
• Служебные позиции — мимо витрины. В базе магазина лежат аренда, транспортные услуги, канцелярия — закупки «для себя». Их нужно отсекать списком, а не надеяться, что никто не закажет «Транспортные услуги».
• Журнал и страница состояния. Владельцу нужна страница, где видно, когда пришёл последний обмен, сколько товаров обновлено и были ли ошибки. У магазина мототехники такая страница есть, вместе с инструкцией по настройке в 1С.

Всё это — работа на стороне сайта. 1С про предохранители ничего не знает и честно отдаёт то, что у неё настроено.

Каталог без категорий и характеристик: как достроить

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

Магазин газового оборудования в Череповце начинал с одной выгрузки: 652 строки, из них 641 товар и 11 служебных позиций. Категорий нет, артикулы пустые, цена есть у 634 позиций, остаток — у 526. Дальше по шагам:

1. Дерево каталога из 8 разделов построено автоматически по наименованиям. Ядро — запчасти к бытовым газовым плитам, 247 позиций, 38 % каталога.
2. Характеристики 254 позиций разобраны прямо из названия, без участия человека: «Подводка газ. 3/4 ПВХ 1,5 гш» превращается в резьбу 3/4″, длину 1,5 м и присоединение «гайка — штуцер». Ничего не додумывается: если размера в названии нет, строки просто нет, а карточка попадает в отчёт о пробелах — таких набралось 52.
3. Для 83 позиций брендовой техники характеристики собраны из интернета: два поисковых запроса на товар, до 10 страниц, значения «голосуют». Сайт производителя весит втрое больше магазина, для товаров без модели нужны минимум два независимых источника — так отброшено 404 слабых значения. Во втором заходе — 358 товаров, 5 263 кандидата с 516 сайтов, в среднем 4,4 характеристики на карточку, у плит — 13,3.
4. Описания собираются только из фактов таблицы характеристик: 4 абзаца, в среднем 677 знаков. Формулировка выбирается от названия товара, чтобы 641 страница не была дублем. Текст владельца всегда важнее автоматического, и обмен его не затирает.

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

У магазина мототехники беда была другая: на старом сайте 2 892 товара и всего 76 заполненных значений характеристик. Всё остальное жило в тексте описаний, и на новом сайте характеристики пришлось доставать оттуда.

Магазин стройматериалов принёс из 1С 345 групп — для покупателя это лабиринт. Каталог перестроили по таблице владельца: 2 группы, 22 раздела. Соответствие групп 1С разделам сайта стоит хранить отдельной таблицей — тогда новая группа в 1С не ломает меню. Там же выяснилось, что 40 % фото в 1С — миниатюры около 230 пикселей. Растягивать их не стали: размытая картинка на весь экран выглядит хуже маленькой, но чёткой.

А у магазина спецодежды в Череповце, наоборот, меню и витрина вообще не правятся руками: 1 383 товара и 1 508 статических страниц собираются из выгрузки 1С, плашки наличия — из её остатков.

Пример из практики: каталог на 15 тысяч товаров за девять дней

Магазин стройматериалов и метизов в Череповце — самый крупный из четырёх примеров. Полная выгрузка из 1С в формате CommerceML 2.07: 17 298 товаров, 345 групп, 8 складов, файлы по 32–37 МБ.

Что получилось на сайте:

• 15 132 карточки и 615 страниц разделов, около 270 МБ статических страниц;
• сборка всего сайта на сервере без фото — 13 секунд;
• изменение цены в 1С появляется на сайте примерно через 20 секунд и затрагивает 4 файла: сайт пересобирает только изменившиеся страницы;
• обмен в обе стороны: каталог, цены и остатки из 1С; заказы с сайта уходят в 1С документом «Заказ товара»; статусы заказов из 1С возвращаются на сайт;
• остатки берутся только с продажных складов, «Недовоз» и «Брак, возврат» на витрину не попадают.

Хронология: выгрузка получена 14 сентября, полный статический каталог готов 16-го, корзина — 17-го, обмен в обе стороны на стороне сайта — 21-го, боевой домен — 23 сентября. Девять дней от файла до работающего магазина.

У магазина газового оборудования путь от выгрузки до оплаты картой занял меньше трёх недель, хотя работа шла параллельно с другими проектами: выгрузка из 1С получена 4 сентября, демо главной — 5-го, характеристики и описания — 11–12-го, корзина с доставкой СДЭК — 12-го, оплата картой — 23 сентября. Как устроены корзина, доставка и оплата с чеками, разобрано в статье про обязательный минимум интернет-магазина.

Сколько стоит интеграция сайта с 1С и сколько она занимает

Стоимость интеграции считается по задаче, и на неё влияют конкретные вещи:

• размер каталога и число складов;
• обмен в одну сторону (каталог, цены, остатки) или в обе (плюс заказы и статусы);
• насколько типовая 1С и где лежат данные;
• состояние каталога: есть ли категории, характеристики, нормальные фото;
• переезд со старого сайта: у магазина мототехники старая CMS работала на PHP 5, в ней было 2 892 товара, из них активных 1 900.

Что изменилось за последние два года — скорость. Раньше разборщик CommerceML, сборку каталога, корзину и формат заказов программист писал руками, и такие проекты шли месяцами. Теперь код пишет ИИ-агент: читает выгрузку, пишет разбор, прогоняет его на реальных файлах, запускает проверки и выкладывает на сервер. Человек ставит задачу, принимает решения — какой порог усыхания, какие склады продажные — и проверяет результат. Отсюда девять дней для каталога на 15 тысяч товаров. Цена падает вслед за сроками: оплачиваются часы специалиста, а их стало в разы меньше. Как это устроено изнутри, — в статье про Claude Code для бизнеса.

Честно о том, когда интеграция не нужна:

• в интернет-магазине с 1С всего несколько десятков товаров, а цены меняются раз в квартал — дешевле обновлять руками или загружать таблицу;
• сайт на CMS со встроенным обменом (например, 1С-Битрикс) и каталог стандартный — хватит готового модуля и настройки;
• в 1С хаос в остатках — сначала навести порядок в учёте, иначе сайт будет точно и быстро показывать неправильные цифры.

Когда нужна связка не только с 1С, но и с доставкой, оплатой, CRM, — это уже общая задача интеграции по API. Если нужно оценить свой случай, студия «Эдисон» берёт такие проекты в работу — подробности на странице автоматизации.

Частые вопросы

Как часто выгружать остатки из 1С на сайт?

Для большинства магазинов достаточно обмена раз в час, для магазина с торговым залом и ходовым товаром — раз в 10–15 минут. Важнее частоты правильный остаток: свободный, а не фактический, и только с продажных складов. Полную выгрузку каталога достаточно делать раз в сутки, а между ними — частичные.

Нужен ли программист 1С, чтобы связать сайт и 1С?

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

Можно ли подключить 1С к сайту на Тильде или другом конструкторе?

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

Почему заказы с сайта не появляются в 1С?

В стандартном обмене 1С сама забирает заказы с сайта запросом type=sale&mode=query — если в узле не включён обмен заказами или не задано расписание, заказы будут лежать на сайте. Вторая частая причина — 1С не может сопоставить покупателя или договор. Третья — сайт отдаёт заказы в формате другой версии CommerceML.

Что делать, если в 1С нет категорий, характеристик и нормальных фото?

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