Обмен сайта с 1С: что передаётся, как устроен и где ломается

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

Что именно передаётся

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

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

Как обмен устроен технически

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

Второй вариант — прямой обмен через API: 1С обращается к сайту по http и передаёт данные в JSON. Гибче и быстрее, но требует доработки со стороны 1С-программиста. Мы делаем так, когда типового формата не хватает: например, когда один приёмник обслуживает несколько сайтов и товары нужно разбирать по признаку «какому сайту принадлежит».

Третий вариант, самый простой, — файл. 1С сохраняет выгрузку в Excel или CSV, сайт забирает его по расписанию. Годится для небольших каталогов, где цены меняются раз в неделю.

Где обмен ломается

• Несовпадение ключей. Товар в 1С опознаётся по идентификатору, а на сайте — по артикулу. Артикул поправили в 1С — на сайте появился дубль. Ключ должен быть один, неизменяемый, и определён до первой выгрузки.
• Размер выгрузки. Полная выгрузка на 30 000 товаров каждый час кладёт сайт. Нужен обмен изменениями: только то, что поменялось с прошлого раза.
• Остатки по складам. 1С считает остаток по трём складам, сайт показывает сумму, а покупатель хочет знать, есть ли товар в его городе. Логику «что считать наличием» нужно решить словами до того, как её напишут кодом.
• Кодировки и пределы. Файл в 200 МБ не пройдёт через лимит загрузки веб-сервера; выгрузка в windows-1251 превратит названия в вопросительные знаки. Мелочи, которые всплывают на первой же реальной выгрузке.
• Никто не смотрит. Обмен упал в марте, а заметили в мае по звонкам «на сайте старые цены». Обмену нужен журнал и уведомление, если он не прошёл.

Заказы обратно в 1С

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

Что подготовить перед началом

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

Мы настраивали обмен и по CommerceML, и через собственный приёмник для нескольких сайтов сразу. Первый вариант быстрее и дешевле; второй — когда у каталога есть особенности, в которые типовой формат не укладывается.