Обмен 1С с сайтом: что на самом деле синхронизируется

Часть 1 из 5 · Серия «Каталог без ручного труда»

«Настройте нам обмен с 1С» звучит как задача на один вечер. Иногда так и есть — если сайт типовой, учётная система типовая и никто ничего не дорабатывал.

Чаще бывает иначе. Обмен настроили, он даже заработал, а через месяц выясняется, что цены на сайте не те, остатки живут своей жизнью, а менеджер по-прежнему переносит заказы руками, потому что «так надёжнее».

Причина почти всегда не в технике. Она в том, что перед настройкой не ответили на один вопрос.

Главный вопрос: кто прав

Обмен — это не «данные появились в двух местах». Это соглашение о том, чьи данные считаются правильными, когда они разошлись.

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

Поэтому первое, что нужно сделать, — расписать источник правды по каждому типу данных. Примерно так:

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

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

Что реально обменивается

Обмен состоит из двух половин, и они независимы. Можно включить одну и не включать другую.

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

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

Что не обменивается никогда — и это стоит сказать клиенту заранее:

• SEO-тексты, мета-описания, посадочные страницы;
• отзывы, рейтинги, вопросы к товарам;
• настройки фильтров и порядок вывода;
• содержимое корзин незалогиненных посетителей;
• баннеры, акции и всё, что относится к оформлению.

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

Владельцу этого достаточно. Всё остальное — предмет разговора разработчика с тем, кто ведёт вашу 1С.

По расписанию или по событию

Второй вопрос, который задают почти сразу: как часто.

По расписанию — обмен запускается сам, скажем, каждый час или раз в ночь. Простой, предсказуемый, легко отлаживать. Минус — данные на сайте отстают на интервал.

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

На практике чаще выбирают комбинацию: каталог целиком раз в сутки ночью, цены и остатки — чаще, заказы — почти сразу.

И ответ, который звучит скучно, но верен в большинстве случаев: раз в сутки для каталога достаточно. Если ассортимент не меняется каждый час, ночной обмен закрывает задачу и не создаёт нагрузки в рабочее время. Требование «онлайн» почти всегда относится к остаткам, а не к описаниям товаров.

Конфигурации: чем они отличаются для вас

Вопрос «а у нас УНФ, это подойдёт?» — один из самых частых.

Управление торговлей (УТ) — самый распространённый случай для магазина. Обмен с сайтом там штатный, ассортимент, цены, остатки и заказы — всё на месте.

Управление нашей фирмой (УНФ) — для небольших компаний. Обмен тоже есть, но набор данных беднее, и часть вещей, привычных по УТ, придётся решать иначе.

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

ERP — большая система, обмен возможен, но объём данных и количество доработок обычно означают, что это проект, а не настройка.

Бухгалтерия — сюда обмен товарами обычно не ставят. Она не про ассортимент.

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

Где ломается на практике

Семь мест, где обмен ломается чаще всего. Ни одно из них не про «не работает технология».

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

Товары без артикула. Обмен опирается на уникальный идентификатор. Если его нет и сопоставление идёт по названию, любая правка названия создаёт новый товар вместо обновления старого.

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

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

Изображения. Тяжёлые фотографии — главная причина того, что обмен «висит». Первая полная выгрузка каталога с картинками может идти часами, и её нужно планировать отдельно от регулярных.

Ручные правки на сайте. Менеджер поправил название, следующий обмен вернул как было. Это не баг — это та самая табличка источников правды, которую не составили.

Отменённые и изменённые заказы. Заказ уехал в 1С, покупатель позвонил и попросил убрать одну позицию. Что происходит дальше, надо решить заранее: правка в 1С, правка на сайте или запрет на правки вообще.

Если сайт не на Битриксе

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

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

Что меняется на практике:

• на Битриксе обмен чаще настраивается штатными средствами, но упирается в ограничения типового модуля, когда каталог нестандартный;
• на других системах обмен пишется под вас, и это дольше на старте — зато логика ровно та, которая нужна, а не та, которая заложена в модуль.

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

Сколько это занимает

Честно, потому что ожидания здесь расходятся с реальностью сильнее всего.

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

Реалистичная рамка для магазина среднего размера — проект на недели, а не настройка на час. И бо́льшая часть времени уходит не на код, а на согласование той самой таблицы источников правды и на разбор данных, которые накопились в 1С за годы.

Тот, кто обещает настроить обмен за час, не видел вашей 1С.

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

Можно ли обмениваться только остатками, без всего остального?

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

Заказы будут падать в 1С сразу?

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

У нас 1С стоит в офисе, не в облаке. Это проблема?

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

Что будет с товарами, которых больше нет в 1С?

Это решение, а не автоматика. Варианты: скрыть с сайта, показать как «нет в наличии», удалить. Удалять почти никогда не стоит — вместе с товаром уходят накопленные позиции в поиске и ссылки. Подробнее — в четвёртой части.

Мы ведём часть товаров только на сайте. Обмен их не сотрёт?

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

Что дальше

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

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

В следующей части разберём, как из такого файла получается работающий каталог и что при этом теряется чаще всего.

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