Интеграция 1С-Битрикс с 1С:УНФ (Управление нашей фирмой)

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

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

Что такое 1С:УНФ и зачем связывать её с сайтом

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

Для интернет-магазина УНФ закрывает ровно ту часть, которую нельзя вести на самом сайте: реальный товарный и складской учёт, цены, взаиморасчёты и обработку заказов. Сайт умеет показывать каталог и принимать заказы, но не знает, сколько товара физически лежит на складе, что уже зарезервировано, по какой цене отгружать конкретному клиенту и что с оплатой. Всё это живёт в учётной системе. Интеграция соединяет две половины: витрину и учёт.

Что даёт связка сайта и УНФ

Интеграция снимает с людей рутину, в которой человек ошибается чаще всего: перенос товаров, обновление цен, сверку остатков и ручное заведение заказов. Когда учётная система и сайт обмениваются данными автоматически, витрина всегда показывает актуальный ассортимент и цену, а заказы попадают в УНФ без копирования руками.

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

Признаки, что интеграцию пора настраивать

Если вы узнаёте свой магазин в нескольких пунктах ниже — обмен с УНФ окупится быстро:

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

УНФ, УТ или ERP: чем УНФ отличается

Частый вопрос на старте: чем УНФ отличается от «старших» конфигураций 1С — Управления торговлей (УТ) и ERP — и не окажется ли её мало. Коротко: это разные по масштабу продукты одной платформы. УНФ — для малого и среднего бизнеса с относительно простым учётом; УТ — для более сложной оптовой и мультискладской торговли; ERP — для крупных предприятий с производством, финансами и глубокой аналитикой. Выбор между ними — управленческий, а не технический: он зависит от сложности ваших процессов, а не от сайта.

Важная новость для интеграции: протокол обмена с сайтом у всех трёх одинаковый — это CommerceML. Поэтому «как связать с Битриксом» решается принципиально одинаково; отличается лишь объём и сложность данных, которые едут на сайт, и количество настроек на стороне 1С. Ниже — обобщённое сравнение по признакам, важным именно для магазина.

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

Штатный обмен УНФ с сайтом по CommerceML

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

Работает это как файловый пакетный обмен. УНФ выгружает каталог и торговые предложения в XML-файлы (традиционно это import.xml с товарами и структурой каталога и offers.xml с ценами и остатками), передаёт их на адрес обработчика сайта, а затем забирает встречным пакетом заказы, оформленные на витрине. Инициатором выступает 1С: именно она по расписанию или по команде «толкает» пакеты на сайт и забирает заказы, а не наоборот.

Почему это удобно для небольшого магазина

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

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

Что синхронизируется между Битрикс и УНФ

Полноценный обмен закрывает четыре большие группы данных. Понимание, что и в какую сторону передаётся, — половина успеха при настройке. Как и в обмене с любой учётной системой, три группы идут из УНФ на сайт, а заказы — обратно.

В терминах УНФ товар — это номенклатура, вариант товара — характеристика номенклатуры, место хранения — склад, наличие берётся из остатков, заказ покупателя оформляется документом «Заказ покупателя», отгрузка — «Расходная накладная». Дальше в статье мы разберём, как правильно связать эти сущности с объектами Битрикса, потому что именно на маппинге чаще всего возникают ошибки.

Узел обмена с сайтом в 1С:УНФ

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

Что задаётся в узле обмена

• Адрес и доступ. URL обработчика обмена на сайте (стандартная точка приёма CommerceML в Битриксе) и учётные данные пользователя, от имени которого идёт обмен.
• Что выгружать. Какие группы номенклатуры и товары уходят на сайт — можно выгружать весь каталог или его часть (например, только товары с признаком «Публиковать на сайте»).
• Какие цены. Какие виды цен из УНФ передаются на сайт и как они соответствуют типам цен каталога Битрикса.
• Какие склады. С каких складов брать остатки — обычно исключают служебные (брак, витрина, транзит).
• Изображения и свойства. Выгружать ли картинки номенклатуры и какие дополнительные реквизиты передавать как свойства товара.
• Расписание. Как часто узел автоматически запускает обмен (по регламентному заданию).

Подготовка справочников в УНФ

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

• Структура групп. Номенклатура разложена по группам (папкам) логично и без дублирующихся веток — эта структура станет разделами каталога на сайте.
• Без дублей и мусора. Уберите повторяющиеся карточки, тестовые и архивные позиции, которые не должны попасть на витрину.
• Заполнены реквизиты. У товаров есть наименование, артикул, единица измерения, вид номенклатуры (товар/услуга/работа) — это влияет на то, как позиция ведёт себя в обмене.
• Единообразные характеристики. Значения характеристик (размер, цвет) записаны единообразно, без разнобоя «Красный / красный / кр.» — иначе на сайте это будут разные значения фильтра.
• Признак публикации. Если на сайт идёт не весь каталог, у товаров проставлен признак, по которому УНФ понимает, что выгружать.
• Заполнены цены и остатки. У номенклатуры установлены нужные виды цен и корректные остатки по складам, которые будут показываться на сайте.

Отдельно стоит проговорить разделение контента. УНФ — учётная система, её сильная сторона в цифрах, а не в продающих текстах. Практичное разделение: из УНФ приходят наименование, артикул, цена, остаток, базовые характеристики и, если ведутся, картинки; а продающие описания, галерею, SEO-поля (title, description), видео ведут на сайте. Поля, которыми «хозяйствует» сайт, исключают из перезаписи, чтобы обмен их не очищал. Механику «кто хозяин поля» мы подробно разбирали для 1С — она одинакова для УНФ.

Номенклатура и группы: что приходит на сайт

Из УНФ на сайт приходит структура каталога: группы номенклатуры превращаются в разделы инфоблока, сами товары — в элементы каталога, а их реквизиты — в свойства товара. Это база, поверх которой уже работают характеристики, цены и остатки.

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

• Наименование, код, артикул. Базовые реквизиты, по которым товар узнаётся и ищется.
• Группа номенклатуры. Определяет, в какой раздел каталога попадёт товар.
• Описание. Текст карточки, если он ведётся в УНФ (но чаще продающее описание лучше вести на сайте).
• Дополнительные реквизиты. Бренд, страна, материал и прочие свойства — становятся свойствами инфоблока.
• Изображения. Если фото прикреплены к номенклатуре в УНФ, они переносятся на сайт.
• Единица измерения. Штуки, метры, килограммы — важно для отображения и оформления заказа.

Свойства и умный фильтр

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

Характеристики УНФ → торговые предложения Битрикс

Самое частое место ошибок — характеристики. В УНФ товар с вариантами (размер, цвет, объём) ведётся как номенклатура с характеристиками: одна карточка номенклатуры и несколько её характеристик, у каждой свой артикул, цена и остаток. В Битриксе этому соответствует связка «товар — торговые предложения» (SKU): одна карточка и несколько предложений под ней.

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

1. Номенклатура УНФ маппится на элемент инфоблока товаров (карточку-товар).
2. Каждая характеристика маппится на торговое предложение в инфоблоке предложений, привязанное к этой карточке.
3. Значения характеристик (размер, цвет) переносятся в свойства торговых предложений, чтобы работал выбор варианта и фильтр по ним.
4. Связь товар→характеристика сохраняется по стабильным идентификаторам, чтобы при повторном обмене предложения не оторвались от карточки.

Тема торговых предложений заслуживает отдельного изучения: от того, как устроены SKU, зависит и карточка, и фильтр, и корзина. Подробно, как устроены торговые предложения и характеристики в Битриксе, мы разобрали в статье про торговые предложения (SKU) в 1С-Битрикс — рекомендуем прочитать её перед настройкой обмена с УНФ, чтобы заранее спроектировать свойства предложений под свои характеристики.

Виды цен УНФ и цены на сайте

Цена — данные, которые меняются часто, поэтому обмен ценами обычно ставят на регулярное расписание. В УНФ у номенклатуры может быть несколько видов цен: розничная, оптовая, закупочная и другие. Задача обмена — донести нужные виды цен до сайта и показать их правильным покупателям.

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

Цены по группам клиентов для B2B

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

Валюта и округление

Проверьте, в какой валюте ведутся цены в УНФ и как они должны показываться на сайте. Для большинства российских магазинов всё в рублях, и вопрос снимается. Согласуйте и правила округления, чтобы на витрине не появлялись цены вроде «1 249,87 ₽» там, где в учёте красиво «1 250 ₽». Это лучше задать единообразно на старте, чем править потом.

Остатки по складам и честное наличие

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

В УНФ остатки берутся по складам. В простом случае на сайт приходит одно число — общий остаток номенклатуры или характеристики. Если складов несколько, обмен может передавать остатки в разрезе складов, и тогда на сайте показывают наличие по конкретному складу или пункту выдачи. Это полезно магазинам с филиалами и самовывозом из разных точек. При этом учёт складов в УНФ проще, чем в УТ: здесь нет тяжёлой ордерной схемы, что для небольшого магазина скорее плюс — меньше настроек и путаницы.

Резерв и доступное количество

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

Правила отображения наличия

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

Заказы с сайта в УНФ и статусы обратно

До этого момента данные шли из УНФ на сайт. С заказами поток обратный: заказ рождается на сайте и должен попасть в УНФ, где его обработает менеджер. Это вторая половина интеграции, ради которой её часто и затевают, — чтобы не переносить заказы руками.

Работает так: покупатель оформляет заказ на сайте; при очередном сеансе обмена УНФ забирает заказ встречным пакетом и создаёт документ «Заказ покупателя», подставляя контрагента, позиции, склад, вид цены и комментарий. Менеджер видит заказ в привычном интерфейсе УНФ, выставляет счёт, резервирует товар, оформляет отгрузку. Изменение статуса заказа возвращается на сайт следующим сеансом — и покупатель видит в личном кабинете, что заказ принят, собран или отгружен.

Что важно передать в заказе

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

Статусы заказов: как их синхронизировать

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

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

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

Особенности УНФ: услуги, работы, производство

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

Услуги и работы на витрине

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

Простое производство и комплекты

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

Настройка обмена на стороне УНФ

Когда справочники приведены в порядок, настройка на стороне УНФ сводится к понятной последовательности. Она короче, чем в УТ, — в этом одно из практических преимуществ УНФ для небольшого магазина.

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

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

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

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

Первый пробный обмен

Первый обмен делайте только на тестовой копии сайта. Запустите полную выгрузку из УНФ и внимательно проверьте результат: правильно ли создались разделы, на месте ли картинки, корректны ли цены и остатки, собрались ли характеристики в карточки с выбором варианта, ушёл ли тестовый заказ обратно в УНФ. На этом этапе всплывают почти все проблемы маппинга — и их дешевле исправить здесь, а не на боевом каталоге.

Расписание обмена: что как часто гонять

Не нужно (и вредно) гонять весь каталог каждые несколько минут — это нагрузит обе системы без пользы. Рациональнее разнести обмен по типам данных и их «скоропортящести». В УНФ это делается регламентными заданиями, а на стороне Битрикса — агентами и cron.

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

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

Маппинг и идентификаторы: как не наплодить дублей

Самая «невидимая», но критичная часть обмена — соответствие сущностей и идентификаторов. Чтобы при каждом сеансе сайт обновлял существующие товары, а не создавал их заново, у каждой сущности должен быть стабильный код, одинаковый от обмена к обмену. В УНФ у каждого объекта есть уникальный идентификатор; на стороне Битрикса он сохраняется как внешний код элемента (XML_ID).

Если этот код «плывёт» — например, при перезаливке номенклатуры в УНФ у товаров поменялись идентификаторы, — обмен перестаёт узнавать старые товары и создаёт дубли. Каталог распухает копиями, ломаются ссылки, страдает SEO. Поэтому стабильность идентификаторов — то, за чем следят в первую очередь.

Что с чем связывается

Что важно проверить по идентификаторам: у групп, номенклатуры и характеристик есть стабильные коды, которые не меняются между обменами; при переносе каталога идентификаторы сохраняются или явно сопоставляются со старыми; на тестовом обмене повторный сеанс обновляет товары, а не плодит дубли. Отдельно согласуйте маппинг реквизитов: имя и тип свойства в Битриксе должны заранее соответствовать реквизиту УНФ, иначе характеристики приедут «не туда» или строкой.

Чем настройка УНФ отличается от УТ

Тем, кто раньше настраивал обмен Битрикса с Управлением торговлей, полезно увидеть разницу явно. Протокол один — CommerceML, — поэтому «как включить обмен» решается одинаково. Отличается наполнение и количество настроек.

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

Когда УНФ становится мало: рост в УТ или ERP

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

• Сложное ценообразование. Много видов цен, скидок, сегментов клиентов и правил, которые в базовом наборе УНФ реализуются с трудом.
• Мультискладская логистика. Несколько складов с ордерным учётом, адресным хранением, перемещениями — где нужен развитый складской контур.
• Партионный учёт и серийные номера. Требования к учёту партий, сроков годности, серий, которых в УНФ нет в нужном объёме.
• Серьёзное производство. Многопередельное производство, спецификации, планирование — территория ERP.
• Глубокая аналитика. Потребность в сложной отчётности и управленческом учёте за пределами возможностей УНФ.

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

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

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

• Товары задваиваются после обмена. Почти всегда причина — нестабильные идентификаторы: код номенклатуры или характеристики между сеансами «поплыл», и обмен создал новую карточку вместо обновления. Лечится восстановлением стабильных кодов и картой соответствия.
• Характеристики не собрались в карточку. Если варианты заведены в УНФ отдельными номенклатурами, а не характеристиками, на сайте вместо одной карточки с выбором — россыпь товаров. Требует правки структуры в УНФ.
• Цены не приехали или не для тех групп. Виды цен УНФ неверно сопоставлены с типами цен сайта или типы не привязаны к группам пользователей. Проверяют маппинг цен и настройку групп.
• Остаток показывает «нет» у услуг и изделий под заказ. Нетоварные позиции выгружены как обычный товар с нулевым остатком. Их выделяют в отдельную логику отображения наличия.
• Обмен затирает описания и SEO. Поля, которые ведёт сайт, не исключены из перезаписи, и ночная выгрузка очищает их. Разделяют «хозяев» полей.
• Заказ уехал в УНФ «без товаров». Позиции заказа не сопоставлены с номенклатурой по идентификаторам. Проверяют связь строк заказа с товарами и характеристиками.
• Обмен идёт долго и роняет сайт. Тяжёлый полный обмен запускается в пик или без ограничения ресурсов. Переносят на ночь, поднимают лимиты PHP, защищают витрину кэшем.
• Статусы заказа на сайте не меняются. Состояния УНФ и сайта не сопоставлены или встречный обмен статусами не настроен. Согласуют карту статусов и включают возврат состояния.

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

Частые ошибки при интеграции с УНФ

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

• Запуск первого обмена сразу на боевом сайте. Самая дорогая ошибка: неотлаженный обмен портит каталог в рабочее время. Лечится одним правилом — сначала тестовая копия.
• Грязные справочники в УНФ. Дубли, мусор, разнобой в характеристиках — всё это ровно так и приедет на сайт. Обмен не наводит порядок, он его переносит.
• Варианты как отдельная номенклатура. Размеры и цвета заведены отдельными позициями, а не характеристиками — на сайте вместо карточки с выбором получается россыпь почти одинаковых товаров.
• Свойства приходят «строкой». Реквизиты, которые должны быть списками или числами, выгружаются текстом — и умный фильтр по ним работает плохо.
• Обмен затирает данные сайта. Картинки, SEO-поля или описания, которые ведутся на сайте, перезаписываются пустыми значениями из УНФ. Нужно явно разделить, какие поля «хозяйствует» сайт.
• Не учтены услуги и изделия под заказ. Нетоварные позиции выгружаются как обычный товар и висят на витрине с нулевым остатком, хотя их можно заказывать.
• Нестабильные идентификаторы. Код номенклатуры между обменами «плавает», обмен создаёт дубли вместо обновления, каталог распухает копиями.
• Тяжёлый обмен в пик нагрузки. Полную выгрузку запускают днём без ограничения ресурсов — и сайт тормозит у покупателей. Место тяжёлому обмену — ночью.
• Нет мониторинга. Обмен молча встал, а узнали об этом через неделю по жалобам на старые цены и остатки. Нужны протоколы и уведомления об ошибках.
• Обещание «оптовой цены» без правил. Виды цен для B2B заведены до того, как в компании решили, кто и как попадает в оптовую группу. Сначала правила, потом настройка.

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

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

• Номенклатура в УНФ структурирована по группам, без дублей и мусора.
• Заполнены артикулы, единицы измерения, вид номенклатуры, цены и ключевые характеристики.
• Варианты заведены характеристиками номенклатуры, а не отдельными позициями.
• Заведены нужные виды цен и определены склады для остатков; служебные склады исключены.
• Услуги и изделия «под заказ» выделены и имеют понятную логику отображения наличия.
• Согласован маппинг: группы → разделы, номенклатура → элементы, характеристики → торговые предложения, реквизиты → свойства нужных типов, виды цен → типы цен.
• Создан узел обмена с сайтом в УНФ: адрес, доступ, состав выгрузки, цены, склады.
• На сайте каталог построен на инфоблоке с торговым каталогом и предложениями; свойства заведены правильных типов.
• Поля, которыми «хозяйствует» сайт (описания, SEO, галерея), исключены из перезаписи.
• Выбрано, показывать физический или доступный остаток; логика резервов согласована.
• Первый обмен отлажен на тестовой копии, повторный сеанс не плодит дубли.
• Настроено расписание: каталог — ночью, цены и остатки — чаще, заказы — почти в реальном времени.
• Согласована карта статусов заказа и включён их возврат на сайт.
• Включены протоколы и уведомления об ошибках обмена.

Когда интеграция нужна, а когда нет

Интеграция с УНФ — не самоцель. Полезно честно понимать, когда она окупается, а когда можно обойтись проще.

Когда обмен точно нужен

• Товарный и складской учёт ведётся в УНФ, и его нужно показывать на сайте актуально.
• Ассортимент растёт, цены и остатки меняются часто, а заказов достаточно, чтобы ручная сверка не справлялась.
• Несколько видов цен и складов, есть B2B-клиенты с разными прайсами.
• Нужно, чтобы заказы с сайта сразу попадали в учёт и обрабатывались менеджером в УНФ.

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

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

И обратная сторона ожиданий: обмен переносит данные, но не наводит в них порядок и не принимает за вас бизнес-решения. Если в УНФ бардак — дубли, пустые описания, кривые характеристики, — ровно это приедет на сайт. Структуру каталога, ценовую политику и продающие тексты по-прежнему определяете вы; обмен лишь убирает рутину и расхождения.

Вывод

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

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