Обмен 1С с CS-Cart: настройка, проверка и доработки

Команда Cart-Power

21 октября 2026·11 мин чтения

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

Что передаётся через штатный CommerceML

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

Мы проверили настройки и код модуля на демонстрационном стенде CS-Cart 4.21.1. У старого модуля обмена настройки другие. Инструкции к нему без сверки в новую версию не переносят.

Часть задач выглядит как повод заказать разработку, хотя решается настройкой. Например, правку названия на сайте от следующего обмена защищает запрет перезаписи, а оптовую цену показывают через соответствие типа цены группе покупателей. Основные настройки описаны в руководстве CommerceML для CS-Cart.

До подключения решите, где редактируются данные

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

Например, цены и остатки ведут в 1С, описание и SEO-заголовок правят в CS-Cart. Название приходит из 1С один раз, при создании карточки, а дальше его меняют на сайте. Схема условная, её стоит согласовать с контент-менеджером.

Настраивается это во вкладке «Товары». Здесь легко спутать две разные вещи. Источник поля, например «Рабочее наименование», задаёт, откуда брать название. Флажок «Импортировать только для новых товаров» рядом с ним ограничивает последующую перезапись: поле заполнится только у новых карточек.

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

Как подготовить обмен с УТ 11 и УНФ

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

Подготовьте CS-Cart

1. Выясните, какой модуль ведёт обмен сейчас. Если это старый модуль, сохраните его настройки и связи товаров, а их перенос в новый модуль проверьте отдельно.
2. Убедитесь, что в магазине есть CommerceML и модуль «Вариации товаров». В панели настроек откройте «Синхронизация данных» и раздел CommerceML.
3. Заведите для обмена отдельную учётную запись администратора с нужными правами. В Multi-Vendor это администратор того продавца, чьи товары передаёте.
4. Скопируйте адрес подключения из вкладки «Общие». На рабочем сайте адрес должен быть с HTTPS, а локальный адрес со снимка относится только к нашему стенду.

Подготовьте узел в «1С:Управление торговлей»

В УТ 11 включают обмен с сайтами и создают узел обмена с адресом из CS-Cart и данными отдельного администратора. Затем определяют состав выгрузки: отбор номенклатуры, виды цен, склады, характеристики и нужен ли обмен заказами.

Инструкция CS-Cart для УТ 11.1 начинает настройку с раздела «Администрирование → Настройки синхронизации данных». Путь и названия полей в других релизах УТ могут отличаться. Пример в инструкции написан для 11.1, поэтому в 11.5 расположение настроек сверяйте со справкой своей конфигурации.

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

Подготовьте обмен в «1С:УНФ»

В УНФ подключение к сайту с обменом по CommerceML создают в настройках интеграции с интернет-магазином. Укажите адрес и учётную запись, настройте передачу товаров и обмен заказами, выберите виды цен и склады. Отдельно проверьте отбор номенклатуры и выгрузку характеристик.

По описанию интернет-торговли в УНФ программа выгружает на сайты с CommerceML товары, изображения, цены и остатки. Путь к настройкам зависит от релиза УНФ и включённых возможностей, поэтому раздел интеграции ищите в справке своей версии. Первый обмен запускают вручную и смотрят, какие данные принял CS-Cart.

Завершите настройку на стороне магазина

Первый полученный файл CS-Cart только анализирует, и товары после него на сайте не появятся. На этом этапе вы задаёте соответствия. Откройте вкладку «Цены», сопоставьте хотя бы один тип цены из 1С с ценой магазина и сохраните настройки.

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

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

Как связать товары и избежать дублей

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

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

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

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

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

Как проверить цены, склады и заказы

Успешная проверка соединения говорит только о том, что 1С достучалась до сайта, а результат обмена смотрят на конкретном товаре и тестовом заказе.

Карточку открывают дважды, как гость и как покупатель нужной группы, и сверяют цену с соответствующим видом цены в учётной системе. Валютную цену магазин пересчитает по своему курсу. Смотрят уже итог пересчёта. Цена может прийти в файле и не дойти до оптовика, например если её тип сопоставлен не с той группой.

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

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

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

Карточку стоит открыть и с телефона: цена, выбранный вариант и наличие должны читаться сразу. Что ещё должно быть в мобильной карточке, мы собрали в разборе карточки товара.

Где искать причину, если обмен остановился

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

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

После переноса базы появились дубли. Начинают с внешних идентификаторов до и после переноса, потом сравнивают коды товаров и сохранённые связи. Автоматический обмен на время разбора лучше остановить. Новые запуски только запутают картину.

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

Большой файл обрабатывается долго. Штатный модуль обрабатывает его по этапам, и несколько запросов подряд здесь норма. По журналу видно, идёт ли импорт или запрос оборвался, а отметка о завершении показывает, закончился ли обмен. Универсального рецепта вроде «увеличить тайм-аут» тут нет. Причину ищут по размеру файлов, времени этапов и нагрузке.

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

Автоматическое скрытие товаров, пропавших из выгрузки, делается доработкой. В одной из наших интеграций импорт после полной выгрузки скрывает карточки, которых в ней не было, и заодно обнуляет их остаток и характеристики наличия. Одного скрытия там было бы мало: скрытый товар в CS-Cart по-прежнему открывается по прямой ссылке, и без обнуления на нём осталось бы старое наличие.

Тесты из таблицы приёмки повторяют на копии магазина после обновления CS-Cart или изменения конфигурации 1С. Собственные модули из цепочки импорта проверяют отдельно. Совместимость с новой версией у каждой доработки своя.

Что меняется при подключении мобильного приложения

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

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

На приёмке мы оформляем одинаковые тестовые заказы через сайт и через приложение, сверяем, как они поступили в 1С, и проверяем обратное изменение статуса.

Когда хватает настройки, а когда нужна разработка

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

Отдельного разбора требуют цены по индивидуальным договорам, расчёт доступности из нескольких источников, перенос сложившихся связей при смене базы, нестандартные документы и состояния заказа. У Multi-Vendor к этому добавляются правила работы продавцов и их учётных систем.

Один из таких проектов — дилер сельхозтехники «АгроЭлемент». Там заказы и реквизиты юрлиц вводят на сайте, а счета выставляют в 1С. Мы добавили поля в XML-файл заказа, который формирует CS-Cart, 1С забирает его по расписанию, а на сайт возвращаются счета с номерами из 1С. Соответствие статусов заказов в двух системах менеджер настраивает в панели администратора. Как это устроено, рассказали в кейсе «АгроЭлемента». Такую разработку мы оцениваем по конкретному примеру данных и ожидаемому результату.

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

Чтобы оценить обмен 1С с CS-Cart, нам понадобятся конфигурация и релиз 1С, версия магазина, обезличенный пример выгрузки и описание нужного результата. Передать задачу на разбор и посмотреть состав услуги можно на странице интеграции сайта с 1С.

Настройки и код CS-Cart 4.21.1, документация CS-Cart и 1С проверены 20 октября 2026 года. Скриншоты сняты на демонстрационном стенде. Последовательность обмена нужно проверить на вашей конфигурации 1С.