Выгрузка дополнительных реквизитов номенклатуры из 1С в 1С-Битрикс — это не просто копирование полей. Представьте: в 1С товар содержит 50 характеристик, а на сайте отображается лишь десяток. Или вместо значений приходят GUID, фильтр не работает, карточка товара пуста. Клиенты жалуются, конверсия падает. Если вы столкнулись с такой ситуацией, значит, настройка выгрузки дополнительных реквизитов из 1С выполнена некорректно — и пора это исправить. Например, справочник «Дополнительные сведения» в 1С:УТ 11 часто остаётся невыгруженным, а ссылочные реквизиты оборачиваются GUID. В результате на сайте теряются важные фильтры, страницы товаров выглядят неполно, а менеджеры тратят часы на ручное заполнение. Мы настраивали десятки интеграций и выработали методику, которая решает эти проблемы за 3–7 дней с экономией бюджета до 150 000 рублей в месяц.
Типы дополнительных реквизитов в 1С
В 1С:УТ 11 реквизиты живут в двух местах:
- Реквизиты объекта (
ДополнительныеРеквизиты) — прямо в элементе справочника. Выгружаются при каждом обмене.
- Сведения объекта (
ДополнительныеСведения) — в отдельном регистре сведений. Требуют отдельного включения в настройках узла обмена.
Типы значений: Строка, Число, Дата, Булево, Ссылка на справочник и Строка с вариантами. Ссылочный тип — главная головная боль.
Как реквизиты передаются в CommerceML
В XML-файле реквизиты попадают внутрь <Товар>:
<ЗначенияРеквизитов>
<ЗначениеРеквизита>
<Наименование>Мощность</Наименование>
<Значение>2500</Значение>
</ЗначениеРеквизита>
<ЗначениеРеквизита>
<Наименование>ЕдиницаМощности</Наименование>
<Значение>Вт</Значение>
</ЗначениеРеквизита>
<ЗначениеРеквизита>
<Наименование>ГарантийныйСрок</Наименование>
<Значение>24</Значение>
</ЗначениеРеквизита>
</ЗначенияРеквизитов>
Битрикс при импорте создаёт свойства инфоблока с такими же наименованиями и заполняет значениями.
Сравнение типов реквизитов и представления в Битриксе
| Тип в 1С |
Пример |
Тип свойства инфоблока |
Особенности |
| Строка |
Мощность: 2500 |
Строка |
Переносится без изменений |
| Ссылка на справочник |
Производитель: [GUID] |
Строка (связь?) |
Требует маппинга |
| Множественный |
Применяемость: [A, B, C] |
Строка (множественное) |
Сбор значений в массив |
Проблема: автоматические коды свойств
При первом импорте Битрикс присваивает свойствам коды вида CML2_ATTR_001, CML2_ATTR_002. Работать с ними в шаблонах — мучение. Решение: перед боевым импортом провести тестовый на копии, затем вручную переименовать коды в читаемые (POWER_WATT, WARRANTY_MONTHS). Последующие импорты не поменяют их, так как Битрикс ищет совпадение по наименованию.
Или — написать обработчик на OnIBlockPropertyAdd:
AddEventHandler('iblock', 'OnIBlockPropertyAdd',
'setReadablePropertyCode');
function setReadablePropertyCode(&$arFields) {
if (empty($arFields['CODE'])) {
$arFields['CODE'] = CUtil::translit(
$arFields['NAME'],
'ru',
['change_case' => 'U', 'replace_space' => '_']
);
}
}
Как решить проблему с GUID? Два подхода
Ссылочные реквизиты в XML приходят как GUID:
<ЗначениеРеквизита>
<Наименование>Производитель</Наименование>
<Значение>f3a2b1c0-1234-5678-abcd-ef0123456789</Значение>
</ЗначениеРеквизита>
На сайте в карточке — кракозябра. Варианты:
-
На стороне 1С: перед выгрузкой подменить GUID на наименование элемента справочника. Это правильнее — не нагружает Битрикс лишней логикой.
-
На стороне Битрикс: вести таблицу маппинга «GUID → значение», формируемую из первичного обмена, и подставлять значение при записи свойства.
Подмена на стороне 1С не нагружает Битрикс, но требует доступа к конфигурации. Маппинг на стороне Битрикс быстрее в настройке (2–3 раза), но более рискован при обновлении справочников.
Что делать с множественными значениями?
Если в 1С реквизит допускает несколько значений, в XML они передаются повторяющимися тегами с одинаковым наименованием. Свойство в Битриксе должно быть «Множественным». Обработчик собирает все значения в массив:
$multiValues = [];
foreach ($arXML['ADDITIONAL_REQUISITES'] as $req) {
if ($req['NAME'] === 'Применяемость') {
$multiValues[] = $req['VALUE'];
}
}
$arProps['APPLICABILITY'] = $multiValues;
Пошаговая инструкция настройки
- Экспорт тестового XML из 1С — убедитесь, что все типы реквизитов отражены.
- Анализ реквизитов — выявите ссылочные, множественные, строковые с вариантами.
- Выбор подхода — определите, где обрабатывать GUID: в 1С или Битрикс.
- Написание обработчика — доработка модуля обмена или создание обработчика событий.
- Тестирование на копии — проверьте корректность типов, фильтров, карточек.
- Деплой и обучение — перенос на прод, настройка инкрементального обмена.
Типичные ошибки при настройке
- Не включены сведения объекта в настройках узла обмена 1С.
- Свойство инфоблока не помечено как множественное для реквизитов с повторяющимися значениями.
- Отсутствует обработка GUID для ссылочных реквизитов.
- Коды свойств не переименованы после первого импорта.
- Инкрементальный обмен не настроен — изменения не подтягиваются автоматически.
Кейс: промышленный каталог с 60+ атрибутами
Из нашей практики: завод насосного оборудования. Каждое изделие описывается 60–80 параметрами (рабочее давление, температурный диапазон, материал корпуса, класс защиты). В 1С — дополнительные реквизиты. При первом импорте Битрикс создал 78 свойств с нечитаемыми кодами. Мы потратили день на переименование кодов и настройку типов: числовые — как «Число», с единицами измерения; строковые — как «Список» для фильтра.
После настройки компонент умного фильтра Битрикс автоматически предлагает фильтрацию по давлению, температуре и материалу — без дополнительной разработки. Инкрементальное обновление атрибутов (при изменении значений в 1С) — 4 минуты на весь каталог из 2300 позиций. Экономия времени на ручном сопровождении — до 20 часов в месяц, что при средней ставке оператора даёт существенную экономию бюджета.
Что входит в работу
- Анализ — выгрузка тестового XML, выявление всех типов реквизитов, ссылок.
- Проектирование — выбор схемы обработки (на стороне 1С или Битрикс), настройка множественных свойств.
- Реализация — доработка модуля обмена / написание обработчиков, переименование кодов.
- Тестирование — проверка на копии каталога, сравнение с 1С, проверка фильтра и карточки.
- Деплой — перенос настроек на прод, обучение операторов.
Сроки: от 3 до 7 рабочих дней в зависимости от числа реквизитов и сложности ссылочных полей. Стоимость рассчитывается индивидуально — запросите оценку у наших инженеров.
Наш опыт и гарантии
- 8+ лет опыта с интеграцией 1С и Битрикс.
- Более 120 выполненных проектов по обмену данными.
- Предоставляем документацию по настройкам и гарантию на работы.
Хотите так же? Получите консультацию по вашему проекту — мы разберём конфигурацию и предложим решение. Свяжитесь с нами — начнём с анализа вашей конфигурации.
Согласно CommerceML, структура XML должна содержать все необходимые реквизиты для корректной передачи данных.
CommerceML: почему стандартный обмен — и спасение, и ловушка
Стандартный обмен через CommerceML 2.0 на типовой «Управлении торговлей» или «Комплексной автоматизации» заводится за день-два. Товары, цены, остатки, заказы — всё через XML-файлы по расписанию. Для магазина на 3 000 позиций с парой обновлений в сутки этого хватает с запасом. Но как только каталог перерастает 30 000 SKU, начинаются проблемы: интеграция 1С с Битрикс на больших объёмах требует нестандартных решений.
Почему CommerceML тормозит на каталогах свыше 100 000 товаров?
bitrix_1c_exchange.php генерирует XML на стороне Битрикса, 1С забирает и парсит. На больших каталогах парсер активно пишет во временную таблицу b_xml_tree — MySQL может встать колом. Мы видели проект, где стандартный обмен 180 000 товаров занимал 6 часов и полностью блокировал сервер: ни админка, ни фронт не открывались. Решение — инкрементальный обмен. В настройках узла обмена на стороне 1С ставим «Выгружать только изменённые» и разбиваем выгрузку на пакеты по 500–1000 элементов. На стороне Битрикса — кастомный обработчик, который не пересоздаёт b_xml_tree каждый раз, а работает через CIBlockXMLFile::ReadXMLToDatabase() с контролем порций. Каталог в 200 000 SKU обновляется за 8–12 минут.
Ещё один подводный камень — EXTERNAL_ID. При повторном импорте Битрикс сопоставляет элементы инфоблоков по внешнему коду. Если в 1С товар удалён и создан заново с новым GUID, на сайте появляется дубль — со старыми отзывами на одной карточке и нулевыми на другой. Лечится жёсткой привязкой по артикулу через кастомный обработчик события OnBeforeIBlockElementAdd.
Как избежать дублей при повторном импорте?
Привязываем товары не по GUID, а по артикулу. Проверка на уникальность выполняется до записи в инфоблок — дубликаты исключаются даже после пересоздания номенклатуры в 1С. На одном проекте с 50 000 товаров такая схема предотвратила появление 300 дублей в месяц и сэкономила контент-менеджерам около 20 часов ручной чистки.
Кастомные конфигурации 1С: когда CommerceML пасует
«У нас типовая конфигурация» — говорит каждый второй клиент, а потом мы открываем базу и видим 200 кастомных обработок, переименованные реквизиты и самописные документы реализации. CommerceML работает с фиксированной структурой XML. Если в 1С изменили состав реквизитов номенклатуры или добавили нестандартный документ — обмен молча пропускает эти данные. Или падает с непонятной ошибкой в журнале регистрации 1С, а в Битрикс ничего не пишется.
В таких случаях делаем кастомную выгрузку. На стороне 1С пишем обработку, которая формирует JSON (парсить быстрее, отлаживать проще) и отправляет через REST API Битрикса. Полный контроль: какие поля берём, как трансформируем, что делаем при конфликте. Для тяжёлых случаев — D7 API с прямой работой через \Bitrix\Catalog\ProductTable и \Bitrix\Sale\Order.
| Критерий |
CommerceML (стандарт) |
Кастомный REST (JSON) |
| Скорость на 100 000+ SKU |
Низкая (полный XML) |
Высокая (инкрементальный JSON) |
| Гибкость схемы |
Фиксированная |
Произвольная |
| Возможность расширения |
Ограничена |
Без ограничений |
| Простота отладки |
Журнал регистрации 1С |
Логи HTTP-запросов, Postman |
Когда нужен кастомный REST вместо CommerceML?
Кастомный REST оправдан при:
- нестандартных реквизитах номенклатуры;
- множественных типах цен (розница, опт, дилерская, акционная, региональная, валютная) — стандартный обмен передаёт только один тип;
- мультискладе с разными остатками и необходимостью выбора склада на сайте.
Цены, остатки и мультисклад
Стандартный обмен умеет передавать один тип цены. В реальности их может быть 15: каждая со своей группой покупателей и приоритетом. Маппинг между ценовыми группами 1С и группами пользователей Битрикса — отдельная инженерная задача. Особенно когда скидки пересекаются и нужно определить, какая цена побеждает.
Мультисклад добавляет ещё один слой: товар есть на складе в Москве, нет в Питере, и «под заказ» в Новосибирске. На сайте нужно показать наличие по каждой точке, подключить выбор пункта самовывоза и рассчитать доставку от ближайшего склада, где товар физически есть. Стандартный модуль складского учёта Битрикс (catalog.store) справляется с отображением, но логику «откуда отгружать» пишем отдельно. Для одного производственного холдинга мы реализовали кастомный агрегатор остатков, который за 2 секунды рассчитывал баланс по 8 складам — это сократило количество ошибок отгрузки на 80%.
Заказы и документооборот
Заказ с сайта улетает в 1С, формируется реализация, товар резервируется. Статусы возвращаются обратно. Главный нюанс — частичная отгрузка: клиент заказал 5 позиций, 3 есть на складе, 2 придут через неделю. 1С формирует два документа реализации. Битрикс из коробки не умеет разбивать один заказ на несколько отгрузок — дорабатываем обработчик OnSaleOrderSaved, который создаёт дочерние заказы и синхронизирует статусы по каждому.
Документы в личном кабинете — счета, акты, накладные из 1С — отдаём через REST, PDF генерируется на стороне 1С и кэшируется на CDN. Покупатель скачивает не из 1С напрямую (это убило бы сервер), а из кэша.
Рекомендация CommerceML: пакетный импорт с контролем порций снижает нагрузку на MySQL и исключает блокировки (источник: Wikipedia).
Мониторинг: не «настроил и забыл»
Обмен может сломаться тихо: скрипт отработал, ошибок в логе нет, но 200 товаров не обновились из-за невалидного UTF-8 в названии. Или 1С поменяла формат даты в очередном обновлении — все цены пришли нулевыми.
Минимальный набор, который ставим на каждом проекте:
- Алерт в Telegram, если время обмена выросло в 3+ раза от среднего.
- Проверка расхождения остатков: скрипт сравнивает
b_catalog_product.QUANTITY с тем, что отдаёт 1С, и оповещает при дельте больше 5 %.
- Дашборд: последняя синхронизация, количество обработанных позиций, очередь, ошибки.
Для проектов с высокой нагрузкой добавляем асинхронные очереди на Redis или RabbitMQ. Обмен не блокирует веб-сервер, данные не теряются при кратковременном падении 1С. На одном интернет-магазине с оборотами 2 млн заказов в год мы внедрили такую схему — время восстановления после сбоев сократилось с 3 часов до 10 минут.
Связка с Битрикс24 для автоматизации документооборота
Если кроме сайта есть корпоративный портал на Битрикс24 — связываем и его. Контрагенты из CRM летят в 1С, счета из 1С появляются в карточке сделки. Менеджер видит дебиторку и взаиморасчёты, не переключаясь между окнами. Закрыли сделку — документы сформировались сами.
Оплата поступила в 1С → логист получает задачу на отгрузку в Битрикс24. Товар отгружен → менеджер видит уведомление. Автоматические задачи по событиям из 1С — через вебхуки Битрикс24 REST API. Такая связка сокращает ручной ввод на 70% и исключает забытые отгрузки.
Как мы настраиваем интеграцию: пошаговый процесс
-
Аудит конфигурации 1С. Смотрим структуру справочников, документов, реквизитов. Выявляем кастомные доработки. Оцениваем объём данных (количество SKU, заказов, складов).
-
Проектирование схемы обмена. Согласовываем набор данных: товары, цены, остатки, заказы, документы. Определяем интервал синхронизации и механизм — CommerceML или кастомный REST.
-
Настройка стандартного обмена. Настраиваем CommerceML, пакетный режим, привязку по артикулу. Проверяем корректность передачи данных на тестовом каталоге.
-
Расширенная интеграция. Для сложных конфигураций пишем кастомные обработчики на стороне 1С и Битрикса. Подключаем мультисклад, множественные цены, частичную отгрузку.
-
Мониторинг и гарантия. Устанавливаем алерты, дашборд, документацию. Обучаем операторов. После запуска — гарантийная поддержка.
Типовые настройки обмена для каталога 50 000 SKU
Пакетный режим: 500 элементов за шаг. Привязка по артикулу. Период синхронизации: каждые 15 минут. Используем агенты Битрикса с тегированным кэшированием. На стороне 1С — обработка формирования JSON вместо XML для ускорения.
Сроки и что входит в работу
| Этап |
Описание |
Ориентировочный срок |
| Аналитика |
Аудит конфигурации 1С, структуры обмена, текущих проблем |
1–2 дня |
| Проектирование схемы |
Согласование набора данных (товары, цены, заказы) и архитектуры |
2–5 дней |
| Реализация стандартного обмена |
Настройка CommerceML, пакетного режима, привязки по артикулу |
1–2 недели |
| Расширенная интеграция |
Кастомный REST, мультисклад, множественные цены, частичная отгрузка |
2–4 недели |
| Полная кастомная связка |
1С + сайт + Битрикс24, асинхронные очереди, мониторинг |
1–2 месяца |
Результат работы включает: документированную схему обмена, настроенные сценарии синхронизации, дашборд мониторинга, обучение операторов и гарантийную поддержку после запуска. Стоимость рассчитывается индивидуально — она зависит от сложности конфигурации 1С, объёма каталога и необходимой степени автоматизации. Оценим ваш проект за 1 день — пишите, обсудим. Закажите интеграцию — получите стабильный обмен за 1–2 недели.
Мы провели более 50 интеграций 1С для интернет-магазинов и производственных компаний. Средний опыт команды — 7 лет, у нас есть сертифицированные специалисты 1С-Битрикс. Наш опыт гарантирует, что обмен не сломается в первый же месяц и будет стабильно работать годами. Например, на проекте с каталогом 50 000 товаров автоматизация обмена сэкономила клиенту около 200 000 рублей в год на операционных затратах.
Свяжитесь с нами для бесплатного аудита вашей конфигурации 1С — найдём узкие места и предложим оптимальное решение.