Создаем цифровые решения, которые работают на бизнес
Каталог на сайте производства устаревает быстрее, чем кажется. Месяц после запуска всё хорошо, через три — цены уже не те, несколько позиций сняты с производства, остатки не совпадают со складом. Менеджер тратит день на ответы «а это ещё актуально?», а закупщик, увидевший старую цену, перестаёт верить всему каталогу. Синхронизация с 1С убирает эту проблему технически: сайт перестаёт быть второй базой, которую кто-то должен обновлять руками.
Схема «менеджер раз в неделю обновляет цены на сайте» выглядит рабочей ровно до первого аврала. Дальше срабатывает простая арифметика: у производства тысяча позиций, цены меняются частями, остатки — ежедневно, и ручная работа физически не успевает.
Дальше начинается хуже. Каталог, которому не доверяют, менеджеры перестают использовать сами: клиенту проще отправить актуальный Excel на почту. Сайт формально есть, а продажи идут мимо него.
Поэтому вопрос не в дисциплине сотрудников, а в архитектуре. Данные должны быть в одном месте и расходиться автоматически — тогда забыть невозможно.
Обмен — это не «выгрузить всё». Обычно передаётся четыре группы данных, и у каждой своя частота обновления.
Номенклатура: название, артикул, категория, единица измерения, характеристики, кратность отгрузки. Меняется редко, обновляется раз в сутки.
Цены: базовая и по типам клиентов — розница, опт, дилер, персональные. Обновляются по расписанию или сразу после изменения в учёте.
Остатки: по складам, часто с делением «в наличии / под заказ / ожидается». Самая частая частота — несколько раз в день или в реальном времени.
Обратный поток: запросы КП и заказы из кабинета дилера возвращаются в учёт как документы. Это та часть, которую обычно забывают, а она и экономит больше всего времени.
Технически вариантов несколько, и выбор зависит от того, в каком состоянии ваша система.
Штатный обмен. У многих конфигураций 1С и BAS есть встроенный механизм обмена с сайтом в формате CommerceML. Самый простой путь, если конфигурация типовая и не сильно допилена.
Через API или веб-сервис. Более гибкий вариант: сайт обращается к системе напрямую и забирает ровно то, что нужно. Подходит, когда обмен должен быть частым или двусторонним.
Через промежуточный файл. Учёт выгружает XML или CSV в папку либо облако по расписанию, сайт его забирает. Просто, надёжно и не требует доступа извне к вашему серверу — часто это решающий аргумент для службы безопасности.
Если учётной системы ещё нет, стартовым вариантом остаётся импорт из Excel по расписанию: вы ведёте файл в привычном виде, сайт подхватывает изменения. Позже источник меняется, а структура каталога остаётся.
Разработчики обычно говорят «подключим за неделю», и это правда лишь в отношении самого канала. Основная работа — в сопоставлении структур.
Типичные места, где всё ломается: категории в учёте названы иначе, чем нужно на сайте; характеристики лежат одним текстовым полем вместо отдельных; одна позиция имеет несколько артикулов; единицы измерения не совпадают — в учёте тонны, на сайте погонные метры; фото хранятся вне системы.
Поэтому реальный план выглядит так: сначала выгрузка и анализ номенклатуры, потом карта соответствий полей, и только после этого настройка обмена. Пропустить средний этап не выйдет — именно он определяет, будет ли каталог выглядеть как каталог, а не как дамп базы.
Как должен быть устроен сам каталог и почему в B2B нужен запрос КП, мы разбирали в материале B2B-каталог: запрос КП вместо корзины.
Учёт знает артикул, цену и остаток, но не знает, как продавать. Описание, применение, преимущества, фото с объектов, сертификаты — этого в 1С обычно нет и быть не должно.
Рабочая схема гибридная: технические поля тянутся из учёта и перезаписываются при каждом обмене, а маркетинговые живут в админке сайта и обменом не трогаются. Тогда менеджер может дописать описание категории или добавить чертёж, не боясь, что следующая выгрузка это сотрёт.
Это правило стоит заложить на старте: для каждого поля определяется источник правды. Иначе через месяц кто-то спросит, почему исчезли все описания.
Точные цифры остатков в B2B показывают редко — это чувствительная информация, и конкуренты тоже читают ваш сайт. Но и прятать полностью не стоит: закупщику надо знать, есть ли товар сейчас.
Практический компромисс — статусы вместо чисел: «есть на складе», «под заказ, срок N дней», «ожидается». Для дилеров в кабинете можно показывать точные остатки, для гостей — статусы.
Главное, чтобы эти статусы обновлялись автоматически. Пометка «в наличии» на позиции, которой нет два месяца, хуже отсутствия пометки вообще.
Реальное время звучит привлекательно, стоит дороже и нужно не всем. Практические ориентиры такие.
Номенклатура и характеристики — раз в сутки, ночью. Цены — раз в сутки или после каждого изменения в учёте, если они двигаются часто. Остатки — несколько раз в день для большинства производств; в реальном времени имеет смысл тогда, когда позиция может закончиться за час.
Заказы и запросы КП — сразу, без задержки: здесь скорость прямо влияет на сделку.
Отдельно стоит предусмотреть ручной запуск обмена кнопкой в админке. Это спасает в ситуациях «изменили цену, надо чтобы сейчас».
Любая интеграция когда-нибудь ломается: обновили конфигурацию, изменился пароль, сервер учёта был выключен. Вопрос не в том, случится ли, а в том, узнаете ли вы об этом.
Минимальный набор страховок: журнал обменов с результатом каждого запуска; уведомление на почту, если обмен не прошёл два раза подряд; правило «не обновилось — оставляем предыдущие данные», а не обнуляем каталог; и отметка даты последнего обновления в админке, чтобы было видно невооружённым глазом.
Последняя деталь особенно важна: без неё каталог может две недели показывать старые цены, и никто этого не заметит. Это та же логика, что и с бэкапами: вопрос не в том, понадобятся ли, а в том, узнаете ли вовремя — о ней мы писали в материале резервное копирование сайта.
Три эффекта, которые видны быстро. Менеджеры перестают тратить часы на «уточню и перезвоню» — данные на сайте совпадают с учётом. Исчезают письма «пришлите актуальный прайс», потому что файл генерируется из каталога в момент скачивания. И появляется статистика: что смотрят, что попадает в запросы, а что лежит без движения.
Плюс менее очевидное: когда каталогу можно доверять, его начинают использовать сами менеджеры — отправляют клиентам ссылку на позицию вместо переписки с вложениями. Как считать отдачу от сайта в целом, мы расписали в материале как рассчитать окупаемость сайта.
Что входит в разработку такого сайта, собрано на странице B2B-сайта для производства.
Самая частая причина срыва сроков — не техническая. Данные в учёте заведены так, как удобно бухгалтерии, а не так, как нужно каталогу. Поэтому перед подключением стоит пройтись по номенклатуре и привести её в порядок — это та работа, которую никто, кроме вас, не сделает.
Минимум: названия позиций в человеческом виде, а не «Труба ст.20 ГОСТ 8732 б/у скл.2»; характеристики разложены по отдельным полям вместо одного текстового; категории, по которым покупатель реально ищет; единые единицы измерения; убранные дубли и давно снятые с производства позиции.
Это можно делать параллельно с разработкой сайта, и именно так мы обычно и работаем: пока идёт дизайн и вёрстка, ваш специалист по учёту чистит номенклатуру по нашему списку. К моменту, когда каталог готов принимать данные, они уже пригодны.
Да, и это самый распространённый случай — типовых конфигураций почти не бывает. Просто вместо штатного обмена делается индивидуальная выгрузка по согласованному формату. На брифе нужны версия конфигурации и контакт вашего специалиста по учёту: он делает выгрузку со своей стороны, мы — приём на сайте.
При правильной настройке нет. Выгрузку ставят на ночное время или делают инкрементной — передаются только изменения с момента последнего обмена, а не вся база каждый раз. Нагрузка на 1С в таком режиме незаметна.
Ничего, если на старте определить источник правды для каждого поля. Технические данные перезаписываются из учёта, маркетинговые — нет. Это настраивается один раз и дальше работает само.
Сам канал обмена — несколько дней. Сопоставление структур и чистка номенклатуры — от недели до месяца, в зависимости от состояния данных. Поэтому честный ответ: если номенклатура в порядке, интеграция идёт вместе с разработкой сайта и не удлиняет срок; если нет, сначала надо привести данные в порядок.
Да, и для многих это правильный путь. Стартуете с импортом из Excel по расписанию, а когда учёт будет готов, мы меняем источник данных. Структура каталога, фильтры и страницы остаются те же — переделывать ничего не придётся.
Синхронизация с 1С нужна не ради технологии, а чтобы каталог не врал. Передаются номенклатура, цены по типам клиентов и остатки, а запросы КП возвращаются в учёт. Основная работа не в канале обмена, а в сопоставлении структур и чистке номенклатуры. Обязательно оставьте маркетинговые поля на стороне сайта, поставьте мониторинг обмена — и каталог перестанет устаревать без чьего-либо участия.
Давайте вместе создадим что-то потрясающее Оставьте номер — перезвоним в течение 15 минут в рабочее время.
Перезвоним в ближайшее время.