Маркировка превратила карточку товара из маркетингового текста в документ, который должен биться с реальностью. Обувь, одежда, парфюмерия, молочная продукция, шины, лекарства — по всё большему числу категорий магазин обязан вести достоверные данные и корректно работать с кодами маркировки. И если раньше в карточку писали «красивое», то теперь расхождение между витриной, учётом и системой маркировки — это уже риск, а не мелочь.
Эта статья — о том, какой контент обязательно указывать в карточках маркируемых товаров на сайте 1С-Битрикс, как хранить обязательные реквизиты в свойствах инфоблоков и почему всё держится на связи с 1С. Разберём, что показывать покупателю, а что ведётся в учёте, и как навести порядок один раз, а не заполнять карточки вручную. Настройку обмена и структуры данных мы закрываем услугой автоматизации на 1С.
Коротко
- Карточка маркируемого товара должна быть отражением достоверных данных из 1С, а не независимым текстом.
- Обязательные реквизиты (состав, страна, изготовитель, модель, размеры) хранят в свойствах инфоблоков и наполняют обменом.
- Уникальный код маркировки экземпляра ведётся в учёте и передаётся при продаже, а не выводится в публичной карточке.
- Те же обязательные атрибуты попутно работают как свойства умного фильтра — двойная выгода.
Что такое маркируемые товары для магазина
Маркировка — это система прослеживаемости, в которой каждая единица товара получает уникальный код и регистрируется на всём пути от производства до продажи. Перечень маркируемых категорий постоянно расширяется: обувь, одежда, парфюмерия, табак, молочная продукция, лекарства, шины, вода и другие группы.
Для интернет-магазина это означает две вещи. Во-первых, по таким товарам нужно вести дополнительные достоверные данные. Во-вторых, при продаже коды маркировки должны корректно выбывать из оборота через учётную систему. Первое напрямую касается контента карточки на сайте, и именно этому посвящена статья; второе — задача учёта в 1С.
Почему контент карточки стал критичным
Раньше карточка товара была зоной свободного творчества маркетолога. С приходом маркировки у неё появилась вторая функция — соответствовать данным учёта и системы прослеживаемости. Состав, страна происхождения, изготовитель, модель — это уже не «текст для красоты», а сведения, которые должны совпадать с зарегистрированными.
Отсюда меняется и подход к наполнению: обязательные реквизиты не выдумываются контент-менеджером, а приходят из 1С. Задача сайта — корректно их отобразить и структурировать, а не создать заново.
Обязательные реквизиты в карточке
Набор обязательных данных зависит от категории, но есть типовой костяк, который встречается в большинстве маркируемых групп.
| Реквизит | Зачем нужен | Источник |
|---|---|---|
| Наименование и модель | Точная идентификация товара | 1С |
| Изготовитель / бренд | Соответствие регистрации | 1С |
| Страна происхождения | Обязательный реквизит | 1С |
| Состав / материал | Достоверность для покупателя | 1С |
| Размер, цвет, объём | Идентификация вариации | 1С (SKU) |
| Артикул / код | Связь с учётом | 1С |
Общее у всех этих полей — источником является учётная система, а не сайт. Контент-команда добавляет поверх маркетинговое описание и изображения, но обязательные реквизиты должны приходить из 1С и совпадать с зарегистрированными данными.
Коды маркировки: где они живут
Частый вопрос — нужно ли показывать код маркировки в карточке. Ответ: уникальный код экземпляра (DataMatrix) не выводится в публичной карточке. Он привязан к конкретной физической единице товара и фигурирует не на витрине, а при отгрузке, в чеке и при выбытии из оборота.
То есть в карточке на сайте покупатель видит характеристики товара, а не код конкретного экземпляра. Сами коды ведутся в 1С и передаются при оформлении продажи через кассу и учётную систему. Смешивать эти уровни не нужно: витрина отвечает за достоверные характеристики, а движение кодов маркировки — за учётом.
Достоверность и связь с 1С
Всё держится на одном принципе: данные на сайте не должны расходиться с учётом и системой маркировки. Если на витрине заявлен один состав или страна, а по факту зарегистрированы другие, это вводит покупателя в заблуждение и создаёт риски.
Технически это решается тем, что карточка наполняется обменом из 1С, а не заполняется на сайте независимо. Обязательные реквизиты приходят как значения свойств товара при обмене CommerceML, и любое их изменение в учёте автоматически отражается на сайте. Так витрина, учёт и маркировка остаются согласованными без ручной сверки. Настройку и аудит такого обмена мы проводим в рамках аудита и оптимизации 1С, а надёжные потоки данных выстраиваем через автоматизацию продаж и склада на 1С.
Свойства инфоблоков под требования
В 1С-Битрикс обязательные реквизиты хранятся как свойства инфоблоков торгового каталога. Правильная структура делает карточки одновременно достоверными и удобными в поддержке.
- Свойства на уровне раздела. Для каждой маркируемой категории — свой набор обязательных свойств (состав, страна, изготовитель).
- Свойства торговых предложений. Размер, цвет, объём ведутся на уровне SKU, а не товара-родителя.
- Списочные значения. Страна, бренд, материал — как справочники, чтобы избежать разнобоя в написании.
- Наполнение обменом. Значения приходят из 1С, а не вводятся руками в карточке.
Структура свойств должна соответствовать данным учётной системы — тогда обмен наполняет их автоматически, а контент-менеджеру не приходится дублировать реквизиты вручную. Это разовая настройка, которая дальше поддерживается сама.
Категории и их особенности
У каждой маркируемой группы свой набор обязательных данных, и его нужно учитывать при проектировании свойств:
- Одежда и обувь. Размер, цвет, состав, изготовитель, страна — размерные атрибуты ведутся на уровне SKU.
- Парфюмерия. Объём, изготовитель, страна, состав — объём как отдельное свойство вариации.
- Молочная продукция. Срок годности, состав, изготовитель — данные, чувствительные к актуальности.
- Шины. Типоразмер, сезонность, изготовитель — атрибуты, важные и для фильтра.
Проектируя структуру, отталкивайтесь от конкретных категорий вашего ассортимента и их требований, а не от универсального шаблона. Разные группы требуют разных наборов свойств.
Обязательные атрибуты для фильтра и поиска
Приятный побочный эффект наведения порядка с обязательными реквизитами — они отлично работают как свойства навигации. Атрибуты, которые вы заполняете ради соответствия требованиям (размер, цвет, состав, страна, объём), одновременно становятся отличными фильтрами.
Умный фильтр catalog.smart.filter в 1С-Битрикс строится именно на свойствах инфоблоков. Заполнив обязательные атрибуты корректно и списочными значениями, вы попутно даёте покупателю удобный подбор по этим характеристикам. Так структурированные обязательные свойства выгодны дважды — и для соответствия, и для навигации. Про надёжные выборки по таким свойствам на больших каталогах мы писали в материале про D7 ORM в 1С-Битрикс.
Разделение ролей: учёт и контент
Чтобы система работала устойчиво, важно разграничить зоны ответственности между учётом и контент-командой.
- Учёт (1С). Ведёт обязательные реквизиты, коды маркировки, регистрационные данные — источник истины.
- Обмен. Переносит достоверные реквизиты на сайт как значения свойств, поддерживает согласованность.
- Контент-команда. Добавляет маркетинговое описание, изображения, читабельность поверх достоверной основы.
- Проверка. Периодическая сверка, что витрина совпадает с учётом и требованиями.
В такой модели никто не выдумывает обязательные данные: реквизиты — из 1С, описание — от контента, и они не конфликтуют. Это снимает и риск расхождений, и рутину ручного заполнения.
Гибкость под меняющиеся требования
Требования к маркировке периодически меняются и распространяются на новые категории. Чтобы не переделывать каталог при каждом изменении, структуру свойств проектируют гибко.
Практичный подход — набор атрибутов на уровне раздела и значения из обмена. Тогда при новом требовании достаточно добавить или уточнить свойство и передать данные обменом, а не перестраивать каталог целиком. Регулярная сверка с актуальными требованиями площадок и регуляторов при этом обязательна: гибкая структура упрощает изменения, но не отменяет необходимости следить за самими требованиями.
Частые ошибки
- Карточка заполняется независимо от 1С. Реквизиты вводят руками, они расходятся с учётом и маркировкой.
- Обязательные данные выдумываются. Контент-менеджер «дописывает» состав или страну вместо данных из учёта.
- Свойства не структурированы. Реквизиты в тексте описания, а не в свойствах — нельзя ни фильтровать, ни сверять.
- Разнобой в значениях. Страна и бренд свободным текстом, а не справочником — «Россия» и «РФ» как разные значения.
- Атрибуты вариаций на родителе. Размер и цвет ведут на товаре, а не на SKU — вариации неотличимы.
- Жёсткая структура. При изменении требований приходится перестраивать каталог, а не добавить свойство.
- Нет сверки. Витрину не сравнивают с учётом, расхождения копятся незаметно.
Чек-лист внедрения
- Определены маркируемые категории. Известно, какие группы ассортимента подлежат маркировке.
- Собран список реквизитов. По каждой категории известен набор обязательных данных.
- Спроектированы свойства. Реквизиты вынесены в свойства инфоблоков, вариативные — на уровень SKU.
- Значения — справочники. Страна, бренд, материал ведутся списками без разнобоя.
- Наполнение обменом. Обязательные реквизиты приходят из 1С, а не вводятся вручную.
- Коды маркировки в учёте. DataMatrix ведётся в 1С и передаётся при продаже, не на витрине.
- Атрибуты в фильтре. Обязательные свойства подключены к умному фильтру.
- Настроена сверка. Витрина периодически сравнивается с учётом и требованиями.
Вывод
Маркировка изменила смысл карточки товара: теперь это витрина достоверных данных, которая должна совпадать с учётом и системой прослеживаемости. Обязательные реквизиты — состав, страна, изготовитель, модель, размерные атрибуты — не выдумываются на сайте, а хранятся в свойствах инфоблоков и наполняются обменом из 1С. А сами коды маркировки живут в учёте и передаются при продаже, а не выводятся покупателю.
Наведите порядок один раз: спроектируйте структуру свойств под требования, настройте наполнение из 1С и разграничьте роли учёта и контента. Тогда карточки маркируемых товаров станут и достоверными, и удобными — те же обязательные атрибуты попутно улучшат фильтр и поиск, а поддержка сведётся к обмену, а не к ручному заполнению.
