Когда на брифе заходит разговор про обмен сайта с 1С, клиент обычно представляет себе одну кнопку: нажал — товары уехали. На деле это протокол с несколькими этапами, и почти все проблемы, которые потом называют «обмен не работает», случаются на конкретном, всегда одном и том же этапе. Разберём, что происходит между нажатием кнопки в 1С и появлением товара в каталоге.
Что такое CommerceML
CommerceML — это формат обмена коммерческой информацией: XML-схема, которую 1С умеет выгружать, а магазин — принимать. Придумана она была совместно 1С и Битриксом, поэтому у 1С-Битрикс поддержка встроена в ядро, а всем остальным платформам её приходится реализовывать самостоятельно.
Важно понимать: CommerceML описывает не только товары. В нём лежат классификатор (группы, свойства, единицы измерения), сами товары и отдельно — предложения с ценами, остатками и характеристиками. Это разделение и объясняет, почему выгрузка приезжает двумя файлами, а не одним.
Четыре этапа одного обмена
1С не отправляет файл «куда-то». Она последовательно дёргает один скрипт на сайте с разными параметрами и на каждом шаге ждёт от него конкретный ответ. В Битриксе это /bitrix/admin/1c_exchange.php, на других платформах — свой обработчик, но логика та же.
- checkauth — 1С представляется логином и паролем, сайт возвращает идентификатор сессии
- init — сайт сообщает, принимает ли он zip и какой максимальный размер файла готов взять
- file — 1С по частям загружает import.xml, потом offers.xml
- import — сайт разбирает загруженное и отвечает «progress» или «success»
Этап import вызывается в цикле. Сайт обрабатывает порцию товаров, отвечает «progress», и 1С зовёт его снова — пока не придёт «success». Именно поэтому большой каталог не падает целиком: он грузится пачками. И именно поэтому обмен может встать посередине, оставив половину каталога обновлённой, а половину — нет.
import.xml и offers.xml — что где лежит
Разделение простое, но его постоянно путают. В import.xml лежит то, что меняется редко: наименование, описание, группа, свойства, картинки, артикул. В offers.xml — то, что меняется каждый день: цены, остатки по складам, характеристики торговых предложений.
Отсюда практический вывод: если нужно обновлять только цены и остатки, полную выгрузку гонять не обязательно. Настраивается выгрузка одних предложений, и она идёт в разы быстрее. Если у вас каталог на десять тысяч позиций выгружается по сорок минут — почти наверняка каждый раз гоняется весь import.xml без необходимости.
Товар и предложение — разные сущности. Футболка — это товар, футболка размера L синего цвета за 1 490 рублей — это предложение. Пока это не разведено в голове, настроить обмен не получится.
Ид — то, на чём всё держится
Каждый объект в выгрузке имеет элемент <Ид> — GUID из базы 1С. Сайт записывает его в поле внешнего кода (в Битриксе это XML_ID) и при следующем обмене ищет товар именно по нему, а не по названию или артикулу.
Из этого следует главное правило эксплуатации: Ид нельзя трогать. Удалили товар в 1С и завели заново — получили новый GUID, а на сайте появился дубль. Перенесли базу 1С и потеряли соответствие — весь каталог задублировался. Разбирать такое приходится вручную, сопоставляя карточки по артикулам, и это долго.
У предложений Ид составной: GUID товара, символ #, GUID характеристики. Если в 1С поменяли состав характеристик, часть предложений отвяжется. Поэтому перед первым обменом мы всегда просим показать, как в учёте устроены характеристики, — это дешевле, чем разбирать последствия.
Где обмен ломается чаще всего
За годы список почти не меняется. По убыванию частоты:
- Не хватает лимитов PHP: upload_max_filesize, post_max_size, max_execution_time — выгрузка обрывается на середине
- Нет прав на запись в папку обмена — 1С получает ошибку уже на этапе file
- Сессия отваливается на длинном импорте: сайт теряет авторизацию и начинает цикл заново
- В 1С пересоздали номенклатуру — на сайте дубли
- Свойства товаров в 1С называются не так, как ожидает сайт, и не подхватываются
- Картинки не приезжают, потому что в выгрузке они лежат относительными путями внутри архива
Проверять всё это нужно по логам обмена, а не по экрану 1С: там видно только «обмен завершён с ошибками». Подробности пишутся на стороне сайта. Разбор таких случаев — обычная часть настройки обмена с 1С, и в девяти случаях из десяти причина оказывается в этом списке.
Обратная сторона: заказы из сайта в 1С
Выгрузка каталога — только половина. Вторая половина — приём заказов: 1С запрашивает у сайта список новых заказов тем же протоколом, получает XML с составом, покупателем и статусом, и подтверждает приём.
Здесь чаще всего спотыкаются на сопоставлении: покупатель с сайта должен во что-то превратиться в 1С — в контрагента, в физлицо, в существующего клиента по телефону. Это решение принимает не программист, а тот, кто ведёт учёт. Если ответа нет, обмен заказов настроить нельзя, и никакой модуль это не обойдёт.
Что спросить у подрядчика до начала
- Будет обмен односторонним или двусторонним
- Как часто и по какому расписанию он запускается
- Что происходит при расхождении: чья цена главнее, сайта или учёта
- Кто побеждает, если товар отредактировали в админке сайта
- Что делать с товарами, которых больше нет в выгрузке: скрывать или удалять
Последний вопрос особенно болезненный. Удалять нельзя: пропадут страницы, которые уже в индексе, и внешние ссылки на них. Правильное поведение — скрывать из продажи, сохраняя страницу. Об этом редко думают на старте и часто жалеют потом.
Мы настраиваем обмен на 1С-Битрикс, WordPress и своих решениях, разбираем чужие сломанные интеграции и приводим номенклатуру в порядок, если она к обмену не готова. Цены и сроки — на странице интеграции сайта с 1С. Если обмен нужен вместе с новым каталогом, смотрите разработку интернет-магазина: там интеграция считается частью проекта.
