Свойства товаров в обмене 1С и Битрикс: словарь атрибутов и проверка

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

Задача бизнеса и границы решения

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

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

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

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

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

Словарь атрибутов: что фиксируем до настройки обмена

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

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

Что входит в словарь

В словаре по каждому атрибуту фиксируют:

• рабочее название и понятный покупателю вариант;
• тип значения: строка, число, список, справочник;
• единицу измерения, если значение числовое;
• уровень: свойство товара или характеристика варианта;
• обязательность заполнения;
• участие в фильтре и в карточке;
• порядок сортировки при выводе.

Полезно сразу отметить, какие характеристики нужны только для внутреннего учёта и на сайт не переносятся. Это уменьшает объём работы и снижает шум в карточке.

Кто согласует словарь

Словарь не рождается в одном кабинете. Его собирают вместе: специалист по учётной системе показывает, какие характеристики вообще ведутся и в каком виде; менеджер объясняет, по каким атрибутам покупатели реально выбирают товар; разработчик проверяет, какие типы свойств поддерживает сайт и как они поведут себя в фильтре. Итог подписывают или хотя бы фиксируют письменно — иначе через месяц никто не вспомнит, почему цвет оказался свойством товара, а не варианта.

Как развести свойство товара и характеристику варианта

Разберём подробнее, потому что это место чаще всего вызывает споры.

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

Правило: если от значения зависят цена, артикул или остаток — это характеристика варианта. Если значение одинаково для всех вариантов и влияет только на описание или фильтр — это свойство товара.

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

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

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

Единицы измерения, типы значений и множественность

Тип значения определяет, что можно делать со свойством дальше. Строка подходит для свободного текста, но плохо фильтруется. Список удобен для фильтра из-за ограниченного набора значений. Число используется для диапазонов (например, толщины или длины).

Числовые значения и единицы

Числовые свойства без единицы измерения на сайте читаются плохо: «толщина 20» непонятно чего. Единицу фиксируют в словаре и проверяют, что она одинаково трактуется в обеих системах. Если в учётной системе толщина хранится в миллиметрах, а на сайте ожидаются сантиметры, это решают в словаре, а не «на глаз» при настройке.

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

Множественные значения

Множественные значения нужны, когда у одного товара несколько равнозначных значений: несколько материалов, несколько совместимых моделей. Множественность удобна для фильтра, но усложняет выгрузку и отображение. Если значение одно и то же почти всегда, множественность только запутает менеджера.

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

Как свойства товаров 1С и Битрикс связываются при обмене

Обмен переносит данные из учётной системы на сайт по заранее описанным правилам. Для свойств это означает: каждому атрибуту в источнике должно соответствовать конкретное свойство в инфоблоке сайта. Соответствие настраивается один раз и дальше используется при каждой выгрузке.

Порядок работы выглядит так:

1. В учётной системе определяют, какие характеристики вообще ведутся и в каком виде. 2. В словаре сопоставляют их со свойствами инфоблока на сайте. 3. Настраивают соответствие в обмене. 4. Выполняют пробную выгрузку на тестовом контуре. 5. Сверяют карточки, фильтр и варианты. 6. Только после проверки переносят настройки на рабочий сайт.

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

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

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

Отображение свойств по разделам и в фильтре

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

Это удобно покупателю и снижает шум в карточке. Но у настройки есть цена: чем больше исключений по разделам, тем сложнее поддерживать словарь. Если исключений становится много, стоит пересмотреть структуру каталога, а не наращивать правила.

Фильтр опирается на свойства. Чтобы фильтр работал осмысленно, свойства, по которым покупатели реально выбирают, должны быть списками или числами, а не свободным текстом. Свободный текст в фильтре бесполезен: значения не совпадают, и покупатель не находит товар.

Отдельно проверяют, какие свойства вообще попадают в фильтр. Если в него просочилось описание или внутренний код, покупатель увидит непонятные пункты. Набор свойств для фильтра — тоже часть словаря.

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

Таблица принятия решения: где хранить атрибут

Таблица помогает договориться до настройки, а не спорить после выгрузки.

Таблица — инструмент фиксации решений, а не догма. Споры по строкам решают до настройки обмена.

Учебный пример: каталог пиломатериалов

Учебный пример. Данные условные, компания и количество объектов вымышлены; это не реальный кейс, а демонстрация логики.

Входные условия

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

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

Действия

Команда составила словарь атрибутов. Породу и толщину отнесли к свойствам товара: они одинаковы для всех вариантов. Толщину сделали числом с единицей измерения. Цвет обработки перенесли в характеристики варианта, потому что от него зависела цена. Длину оставили свойством товара, но перевели в список значений.

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

Наблюдаемый результат и проверка

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

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

Как проверить результат и принять работу

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

• Словарь атрибутов согласован и подписан ответственными сторонами.
• Для каждого свойства определены тип, единица измерения и уровень.
• Свойства, участвующие в фильтре, имеют ограниченный набор значений.
• Пустые значения не выводятся в карточке и в фильтре.
• Контрольные позиции из каждой группы каталога выгружены и сверены.
• Позиции с несколькими вариантами показывают разные цены и остатки.
• Отображение свойств по разделам проверено на каждом разделе.
• Пробная выгрузка выполнена на тестовом контуре, а не на рабочем сайте.
• Перед изменениями сделаны резервная копия и план возврата.
• Результат проверки зафиксирован письменно с перечнем расхождений.

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

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

Типичные ошибки и ограничения

Ошибки повторяются из проекта в проект.

• Свойство, от которого зависит цена, оставили свойством товара. Карточка показывает одну цену для разных вариантов.
• Числовое значение выгрузили строкой. Фильтр не строит диапазоны.
• Свободный текст попал в фильтр. Значения не совпадают, покупатель не находит товар.
• Единицы измерения не согласованы. На сайте «толщина 20» без подписи.
• Слишком много исключений по разделам. Словарь становится неподдерживаемым.
• Настройки меняли сразу на рабочем сайте. Откат занимает время, а каталог в это время выглядит некорректно.
• В словарь не заглядывают после запуска. Новые характеристики добавляют «на ходу», и правила расходятся.

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужны:

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

Чем полнее эти данные, тем точнее оценка. Если перечень характеристик неполный, часть работы выяснится уже в процессе, и это нормально — важно заложить время на уточнение словаря.

Что дальше

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

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