Интеграция с 1С:Розница и офлайн-магазином на 1С-Битрикс: омниканальность

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

Это подробное руководство о том, как связать онлайн и офлайн-магазин на Битриксе в единую систему: что такое омниканальность на практике, как устроен обмен с 1С:Розница, как показать наличие по конкретной точке, настроить самовывоз и click&collect, сделать единую программу лояльности и карты между кассой и сайтом, единую историю покупок и возвраты в любой точке. Разберём роль РМК и касс, отличия 1С:Розница от УТ и УНФ и частые проблемы вроде расхождения остатков точки и разных баз клиентов. Материал основан на нашей практике разработки магазинов с интеграцией 1С — по делу, без маркетинговых обещаний.

Что такое омниканальность для магазина

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

Для магазина на 1С-Битрикс с офлайн-точками это означает связать четыре вещи в единое целое: единый клиент, единые остатки, единые цены и единую лояльность. Не «сайт отдельно, магазины отдельно», а один магазин с разными точками контакта.

Четыре опоры омниканальности

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

Что омниканальность даёт покупателю и бизнесу

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

1С:Розница: чем отличается от УТ и УНФ

Для омниканального магазина важно понимать, какая конфигурация 1С за что отвечает. 1С:Розница — это типовая конфигурация, заточенная под работу розничных магазинов: продажи через кассу и рабочее место кассира (РМК), учёт по чекам контрольно-кассовой техники, эквайринг, дисконтные и бонусные карты, учёт остатков и ассортимента по конкретным торговым точкам. Её родная задача — «магазин у прилавка», а не оптовый склад и не производство.

УТ (Управление торговлей) сильна в оптовой и мультискладской торговле, гибком ценообразовании и работе с контрагентами. УНФ (Управление нашей фирмой) — упрощённый «всё в одном» для малого бизнеса. ERP — тяжёлый контур для крупных предприятий с производством и финансами. Ключевой момент: протокол обмена с сайтом у всех один — CommerceML, поэтому «как связать с Битриксом» решается принципиально одинаково. Отличается розничная логика: у Розницы она развита сильнее всех — именно поэтому омниканальные сценарии «онлайн + касса» естественнее строятся на ней.

На практике в сети магазинов Розница часто работает не одна: в каждой точке (или на центральном сервере) она ведёт продажи и остатки, а сверху стоит центральная учётная система — УТ или ERP, — которая консолидирует данные всех точек, ведёт закупки и общий каталог. Тогда сайт может обмениваться либо напрямую с Розницей, либо с центральной системой — в зависимости от того, где «живут» нужные данные. Общие принципы файлового обмена по CommerceML — те же, что мы разбирали в руководстве по интеграции магазина с 1С, а специфику упрощённого учёта — в статье про интеграцию с 1С:УНФ.

Что синхронизируется между Битрикс и 1С:Розница

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

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

Обмен с 1С:Розница по CommerceML

Транспорт омниканальной связки на базовом уровне тот же, что у любого обмена 1С с Битриксом, — стандарт CommerceML. Это открытый формат обмена коммерческой информацией на базе XML, который и Розница, и модуль «Интернет-магазин» в 1С-Битрикс понимают штатно. Каталог и торговые предложения выгружаются в XML-пакеты, передаются на адрес обработчика сайта, а встречным пакетом забираются заказы. Инициатор обмена — 1С: она по расписанию «толкает» данные на сайт и забирает заказы.

Специфика Розницы в том, что часть омниканальных данных выходит за рамки классического каталожного CommerceML. Остатки по конкретным точкам передаются в разрезе складов, а вот единый клиент, карты и особенно бонусные операции нередко требуют дополнительной логики: отдельного обмена клиентами и заказами, а иногда — связки через центральную систему или внешний сервис лояльности. То есть каталог, цены и остатки едут штатным CommerceML, а «омниканальную надстройку» (клиент, бонусы, единый счёт) проектируют отдельно, поверх базового обмена.

Почему это пакетный, а не мгновенный обмен

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

Единый клиент: онлайн и офлайн в одном профиле

Сердце омниканальности — единый клиент. Пока покупатель на сайте и покупатель на кассе — это две разные записи в двух базах, никакой «единой истории» и «общих бонусов» не получится. Задача — сделать так, чтобы человек опознавался одинаково во всех каналах и все его действия сходились в один профиль.

По какому признаку опознавать покупателя

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

Мастер-система для клиента и дедупликация

Клиентские данные могут меняться с обеих сторон: человек зарегистрировался на сайте, а потом пришёл на кассу и назвал телефон; или наоборот, кассир завёл карту, а клиент позже создал личный кабинет. Поэтому важно определить мастер-систему для клиента — где хранится «истина» о профиле, — и правила дедупликации: как система понимает, что «Иван по телефону +7…» с сайта и «Иванов И.» с кассы — один человек, и не создаёт двойников. Это отдельная, довольно тонкая тема; мы разбираем её в статье про синхронизацию клиентской базы — для омниканальной розницы действуют те же принципы, только каналов больше.

Единые остатки и наличие по конкретной точке

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

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

Физический остаток против доступного количества

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

Варианты отображения наличия по точкам

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

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

Склады-точки на сайте: как это устроено

Чтобы наличие по точкам заработало, каждую офлайн-точку заводят на сайте как отдельный склад модуля «Интернет-магазин». Магазин на Тверской — склад, магазин на Ленинском — склад, распределительный центр — тоже склад. Обмен с 1С:Розница передаёт остатки в разрезе этих складов, а витрина, самовывоз и резерв опираются на них.

Что настраивают на уровне складов-точек

• Соответствие точка → склад. Каждой торговой точке 1С:Розница сопоставляется склад на сайте по стабильному идентификатору, чтобы остатки приезжали «в свой» магазин.
• Адрес и режим работы. У склада-точки на сайте заводят адрес, часы, контакты — это же данные пункта самовывоза для покупателя.
• Участие в продажах. Какие точки участвуют в онлайн-продаже и самовывозе, а какие служебные (склад брака, транзит) — исключены из «наличия».
• Геопривязка. Город и координаты точки — чтобы показывать покупателю ближайшие магазины и наличие в его городе.

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

Цены по точкам и регионам

В рознице цена нередко зависит от точки или региона: аренда, логистика, конкуренция и локальные акции приводят к тому, что один и тот же товар в Москве и в области стоит по-разному. Омниканальность не требует «одинаковой цены везде» — она требует, чтобы цена была согласованной и предсказуемой, а не случайно разной из-за рассинхрона.

В 1С:Розница у номенклатуры могут быть цены по точкам или ценовым группам магазинов. Задача обмена — донести на сайт нужную цену и показать её правильному покупателю в зависимости от выбранного города или точки. Механика похожа на обычные виды цен: в Рознице заведены цены (в том числе по группам точек), на сайте создаются типы цен, они сопоставляются один к одному, а показ конкретной цены привязывается к выбранному покупателем городу/точке.

Практические правила для цен по регионам

• Определите ведущий канал цены. Решите, чья цена показывается по умолчанию: единая онлайн-цена или цена выбранной точки. Смешивать их без правила нельзя.
• Согласуйте цену самовывоза. При click&collect логично показывать цену той точки, где покупатель забирает товар, — это нужно продумать заранее.
• Договоритесь про акции. Локальные акции точки и федеральные акции сайта могут конфликтовать; правила приоритета описывают до запуска.
• Округление и валюта. Правила округления единые, чтобы на витрине не появлялись «некрасивые» цены там, где в учёте они ровные.

Роль РМК и касс в омниканальности

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

Что касса даёт омниканальной системе

• Фиксацию продажи. Чек уменьшает остаток точки — а значит, влияет на наличие товара на сайте после ближайшего обмена.
• Опознание клиента. Кассир вводит телефон или карту, и покупка привязывается к единому профилю клиента, пополняя общую историю.
• Операции лояльности. Начисление бонусов за офлайн-покупку и списание накопленных (в том числе за онлайн-заказы) идут через кассу.
• Выдачу онлайн-заказов. При самовывозе именно на кассе заказ выдаётся и пробивается, закрывая цикл click&collect.

Отсюда важное следствие: касса — это тоже канал, который меняет общие данные. Если продажи через кассу идут интенсивно, остатки точки «тают» быстро, и обмен с сайтом должен успевать за этим. Поэтому в омниканальной схеме частота обмена остатками розничных точек — обычно самая высокая из всех потоков.

Самовывоз и click&collect: заказ онлайн — забрать в магазине

Самовывоз и его продвинутая форма click&collect («заказ онлайн — забрать в магазине») — один из главных сценариев, ради которых омниканальность и строят. Покупатель оформляет заказ на сайте, выбирает точку, где товар есть, и забирает его там, не дожидаясь доставки. Для магазина это дешевле курьера, для клиента — быстрее и удобнее. Но именно здесь честность данных проверяется на прочность: если покупатель приедет за товаром, которого в точке уже нет, вся омниканальность обесценится в его глазах.

Как проходит click&collect по шагам

1. Выбор товара и точки. Покупатель видит наличие по магазинам и выбирает точку, где товар есть в наличии прямо сейчас.
2. Оформление с самовывозом. В заказе указывается способ получения «самовывоз» и конкретная точка; заказ уходит в 1С:Розница с привязкой к ней.
3. Резерв в точке. В точке создаётся резерв на позиции заказа, и они вычитаются из доступного остатка — чтобы их не пробили на кассе другому покупателю.
4. Сборка сотрудником. Сотрудник магазина видит заказ, откладывает товар и подтверждает готовность.
5. Статус «готов к выдаче». Статус возвращается на сайт, покупатель получает уведомление, что можно приезжать.
6. Выдача и продажа. Покупатель забирает заказ, продажа пробивается через кассу точки, начисляются бонусы, цикл закрывается.

Каждый шаг здесь опирается на общие данные: наличие по точке, резерв, обмен статусами. Если хотя бы одно звено «фальшивит» — остаток неверный, резерв не создался, статус не вернулся, — сценарий ломается. Механику самовывоза и резервирования на стороне сайта мы подробно разбираем в статье про самовывоз и резервирование в 1С-Битрикс — рекомендуем прочитать её перед настройкой click&collect.

Резерв в точке: чтобы товар дождался покупателя

Резерв — незаметная, но критичная механика самовывоза. Когда покупатель оформил click&collect, между моментом заказа и моментом выдачи проходит время: минуты, часы, иногда день. Всё это время товар должен «дождаться» клиента и не быть проданным на кассе кому-то ещё. Для этого позиции заказа резервируются в конкретной точке и вычитаются из доступного к продаже остатка.

Что нужно решить про резерв

• Момент создания резерва. Резервировать сразу при оформлении заказа или после подтверждения/оплаты — зависит от политики магазина и доли невыкупов.
• Срок резерва. Сколько товар ждёт покупателя, прежде чем резерв снимется и позиция вернётся в продажу. Слишком короткий срок раздражает клиентов, слишком длинный — замораживает ходовой товар.
• Влияние на наличие. Зарезервированное количество вычитается из доступного на сайте, чтобы витрина не обещала того, что уже отложено.
• Снятие и продление. Что происходит, если покупатель не приехал: резерв снимается автоматически, товар возвращается в доступное, клиент уведомляется.

Резерв — это компромисс между удобством клиента и оборачиваемостью товара. Держать позицию в резерве бесконечно нельзя — она «мертвеет» и не продаётся. Поэтому срок и правила резерва проговаривают заранее, вместе с логикой отображения доступного остатка. Технически резерв может создаваться на стороне сайта, на стороне Розницы или согласованно в обеих — это решение принимают на этапе проектирования обмена.

Единая программа лояльности: бонусы и карты

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

Где живёт единый бонусный счёт

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

Начисление и списание без задвоений

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

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

Единая история покупок клиента

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

Как собирается единая история

• Онлайн-заказы уже есть на сайте — они рождаются здесь.
• Офлайн-продажи приходят из 1С:Розница: продажи через кассу привязываются к профилю клиента по телефону или карте и передаются на сайт.
• Общий профиль сводит оба потока в одну историю в личном кабинете, показывая покупки независимо от канала.
• Бонусные операции дополняют картину: начисления и списания видны рядом с покупками.

Здесь снова упирается всё в опознание клиента: покупка на кассе попадёт в историю только если кассир ввёл телефон или клиент предъявил карту. Часть офлайн-покупок неизбежно остаётся «анонимной» — когда человек не назвался. Это нормально: единая история собирает то, что удалось связать с профилем, и чем удобнее опознание на кассе, тем полнее история. Технически передача офлайн-продаж на сайт — это отдельный поток данных, который проектируют вместе с обменом клиентами.

Возвраты в любой точке

Возможность вернуть покупку в любой удобной точке — вершина омниканальности и одновременно самый «неудобный» для учёта сценарий. Купил онлайн — вернул в магазине; купил в одном магазине — вернул в другом. Для покупателя это высший комфорт, но за ним стоит серьёзная работа с учётом, кассой и лояльностью, а не только обмен данными.

Что должно сойтись при возврате в любой точке

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

Как видно, возврат в любой точке — это на 80% бизнес-процесс и учёт и лишь на 20% обмен. Обмен переносит то, что вы заранее договорились считать возвратом: каким документом он оформляется, как влияет на бонусы и остаток, кто его имеет право принять. Поэтому такие сценарии проектируют совместно с бухгалтерией и учётной командой ещё до запуска, а не «прикручивают» потом. Начинать омниканальность с возвратов в любой точке не стоит — это финальный, самый требовательный этап.

Онлайн против офлайна: что общее, что разное

Полезно явно разложить, что в омниканальной схеме у онлайна и офлайна общее, а что — разное. Общими должны быть данные (каталог, клиент, бонусы), а разными остаются физика канала и способ получения товара. Понимание этой границы помогает не пытаться «слить» несливаемое и корректно спроектировать обмен.

Главный практический вывод из таблицы: остаток офлайн-точки меняется в реальном времени (продажи через кассу идут постоянно), а онлайн узнаёт об этом по обмену. Отсюда — весь фокус на частоте обмена остатками и на выводе доступного количества. Всё остальное (каталог, клиент, бонусы) должно быть строго единым, и любое расхождение здесь — это дефект, а не «особенность канала».

Настройка обмена на стороне 1С:Розница

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

1. Наведите порядок в номенклатуре и точках. Товары разложены по группам без дублей; торговые точки заведены корректно; определено, остатки каких точек уходят на сайт.
2. Определите мастер-системы. Решите, где ведётся каталог, где — остатки по точкам, где — клиент и бонусный счёт (в Рознице, центральной УТ/ERP или внешнем сервисе лояльности).
3. Настройте узел обмена с сайтом. Укажите адрес обработчика на сайте, доступ, состав выгрузки, какие цены и остатки каких точек передавать.
4. Настройте цены по точкам/регионам. Заведите нужные виды цен и сопоставьте их с типами цен сайта; продумайте, какая цена показывается при самовывозе.
5. Спроектируйте обмен клиентами и бонусами. Определите признак опознания клиента, правила дедупликации и единый источник бонусного счёта — это отдельная логика поверх CommerceML.
6. Задайте расписание. Настройте регламентные задания: остатки точек — часто, цены — по изменению, каталог — ночью, заказы — почти в реальном времени.

Настройка обмена на стороне 1С-Битрикс

Встречная часть — на сайте. Здесь важно, чтобы каталог, склады-точки и логика наличия были готовы принять розничные данные.

1. Проверьте модуль «Интернет-магазин». Каталог реализован на инфоблоке с торговым каталогом и торговыми предложениями, есть модуль заказов.
2. Заведите склады-точки. Каждая офлайн-точка — отдельный склад с адресом, режимом работы и геопривязкой; служебные склады исключены из наличия.
3. Подготовьте типы цен. Заведите типы цен под виды цен Розницы, привяжите их к городам/точкам и группам пользователей.
4. Настройте отображение наличия по точкам. Выберите формат (список точек, наличие для города, суммарно + детализация) и выводите доступное количество, а не физический остаток.
5. Настройте самовывоз и резерв. Включите способ получения «самовывоз» с выбором точки, логику резерва и статусы «в сборке / готов к выдаче».
6. Согласуйте маппинг. Проверьте соответствия: группы → разделы, номенклатура → элементы, точки → склады, виды цен → типы цен, клиент → профиль, статусы заказа.
7. Защитите поля сайта. Исключите из перезаписи продающие описания, SEO и галерею, чтобы обмен их не затирал.

Первый пробный обмен — только на копии

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

Расписание обмена для омниканальности

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

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

Такое разделение снимает нагрузку и держит критичные данные свежими. На стороне Битрикса под тяжёлый обмен поднимают лимиты PHP и защищают витрину кэшированием и композитом, чтобы обмен не влиял на скорость каталога. Отдельно стоит заложить надёжность самого обмена: если сеанс упал, критичные потоки (остатки, заказы) не должны «встать» надолго. Про очереди и устойчивость интеграций у нас есть отдельный разбор в рубрике «Интеграции».

Частые проблемы омниканальности и как их лечить

Часть проблем повторяется в омниканальных проектах из раза в раз. Разберём типовые симптомы и причины — так их проще узнать и устранить.

• Остатки точки на сайте расходятся с реальностью. Причина — редкий обмен и вывод физического остатка вместо доступного: между сеансами точка распродаёт товар через кассу. Лечится учащением обмена остатками, выводом доступного количества, резервом под онлайн-заказы и буфером по ходовым позициям.
• Разные базы клиентов, задвоение профилей. Сайт и Розница ведут клиента по разным признакам, и один человек превращается в двух. Лечится единым признаком опознания (телефон/карта), мастер-системой для клиента и дедупликацией.
• Бонусы «теряются» между каналами. Начислили онлайн — не видно на кассе, и наоборот. Причина — раздельные бонусные счёта. Лечится единым источником баланса, к которому обращаются оба канала.
• Двойное списание бонусов. Два канала независимо меняют баланс. Лечится проведением всех операций через единый источник с подтверждением.
• Покупатель приехал за товаром, которого нет. Резерв под самовывоз не создался или создался не в той точке. Проверяют привязку заказа к точке и логику резерва.
• Цена «прыгает» при смене города. Цены по регионам показываются без правил. Определяют ведущую цену и честно поясняют зависимость от точки.
• Услуги и «под заказ» висят с нулевым остатком. Нетоварные позиции выгружены как обычный товар. Их выделяют в отдельную логику наличия.
• Обмен остатками роняет сайт. Частый обмен по всем точкам без оптимизации нагружает витрину. Оптимизируют объём выгрузки, поднимают лимиты, защищают каталог кэшем.
• Статусы самовывоза не доходят до покупателя. Встречный обмен статусами не настроен, «готов к выдаче» не возвращается. Согласуют карту статусов и включают их возврат.

Если обмен сломался, порядок такой: посмотреть протокол последнего сеанса и найти ошибку, проверить доступность обработчика и корректность доступа, убедиться, что справочники и маппинг в порядке, и перезапустить. Хорошо настроенный обмен идемпотентен — повторный сеанс обновляет данные, а не плодит дубли, поэтому перезапуск безопасен.

Частые ошибки при построении омниканальности

Большинство ошибок повторяются из проекта в проект. Зная их заранее, вы сэкономите недели отладки и сохранените доверие покупателей:

• Включить всё сразу. Попытка запустить единые остатки, самовывоз, клиента, лояльность и возвраты одним махом. Разворачивать нужно поэтапно, отлаживая каждый слой.
• Вывод физического остатка вместо доступного. Витрина обещает товар, который уже отложен или продаётся на кассе. Всегда выводят доступное к продаже количество.
• Два разных клиента. Нет единого признака опознания и мастер-системы — база двоится, история и бонусы разваливаются.
• Два бонусных счёта. Бонусы копятся раздельно онлайн и офлайн — покупатель не может пользоваться ими везде, начинаются споры.
• Резерв без правил. Не определён момент создания и срок резерва под самовывоз — товар либо не дожидается клиента, либо мёртво висит в резерве.
• Цены по регионам без объяснения. Цена меняется при смене города молча — воспринимается как обман.
• Первый обмен на боевом сайте. Неотлаженный омниканальный обмен портит каталог и остатки в рабочее время. Сначала — тестовая копия.
• Грязные справочники и точки. Дубли, мусор, неверно заведённые точки — всё это ровно так и приедет на сайт.
• Возвраты без проработки процесса. «Возврат в любой точке» включили, не описав, как он проходит по кассе и бонусам, — и он ломается на первом же кейсе.
• Нет мониторинга обмена. Обмен молча встал, а узнали через жалобы на неверные остатки. Нужны протоколы и уведомления об ошибках.
• Обещание того, что не собираете. Показали «всю историю покупок», хотя на кассе редко спрашивают телефон, — история неполная, и это заметно.

Чек-лист перед запуском

Короткий список, по которому удобно свериться до включения омниканального обмена на боевом сайте:

• Определены мастер-системы: где каталог, где остатки по точкам, где клиент и бонусный счёт.
• Номенклатура и торговые точки в 1С:Розница структурированы, без дублей и мусора.
• Каждая офлайн-точка заведена на сайте складом с адресом, режимом и геопривязкой; служебные склады исключены.
• На сайт выводится доступное к продаже количество по точкам, а не физический остаток.
• Заведены нужные виды цен, согласована логика цен по точкам/регионам и цена при самовывозе.
• Настроен самовывоз с выбором точки, логика резерва и статусы «в сборке / готов к выдаче».
• Определён единый признак опознания клиента (телефон/карта) и правила дедупликации.
• Бонусный счёт один, начисление и списание идут через единый источник — без задвоений.
• Согласовано, какие офлайн-продажи попадают в единую историю покупок и как опознаётся клиент на кассе.
• Процесс возврата в любой точке описан вместе с учётом и лояльностью (если сценарий включается).
• Согласован маппинг: группы → разделы, точки → склады, виды цен → типы цен, клиент → профиль, статусы заказа.
• Настроено расписание: каталог — ночью, цены — по изменению, остатки точек и заказы — часто.
• Первый обмен отлажен на тестовой копии, повторный сеанс не плодит дубли.
• Включены протоколы и уведомления об ошибках обмена; критичные потоки устойчивы к сбою сеанса.

Когда омниканальность нужна, а когда нет

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

Когда омниканальность точно нужна

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

Когда можно повременить

• Магазин пока только онлайн или только офлайн — нет двух каналов, которые нужно сшивать.
• Учёт в Рознице не наведён: сначала порядок в точках, остатках и клиентах, потом омниканальность.
• Точек мало и остатки стабильны — иногда проще начать с единых остатков и самовывоза, отложив лояльность и возвраты.
• Бизнес на этапе запуска: важнее проверить спрос, чем строить полную бесшовную схему.

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

Вывод

Омниканальность на 1С-Битрикс — это не отдельная кнопка, а состояние, когда сайт, офлайн-точки и касса опираются на общие данные: единый клиент, единые остатки по точкам, согласованные цены и единую программу лояльности. Технически фундамент строится на интеграции с 1С:Розница (и, как правило, центральной учётной системой) по стандарту CommerceML: каталог, цены и остатки точек едут на сайт штатным обменом, заказы и самовывоз возвращаются в точку, а поверх проектируется омниканальная надстройка — единый клиент, карты и бонусы.

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