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

«Настройте нам обмен с 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С?

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

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

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

Что дальше

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

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

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