Кто не знаком с функционалом обработки данных элемента в SEO полях вот ссылка на пост Юрия Волошина.

И так о проблеме: {=this.catalog.price.Retail} и {=min this.catalog.sku.price.Retail} не работает если у SKU ценовые диапазоны(включен расширенный режим управления ценами)! т.е. если у товара есть цены на разное количество товара - то функционал не работает!

В GET параметры достаточно передать ID SKU и количество для точной ссылки на товар определенной цены.
Необходимо настроить "SKU_ID" и "QUANTITY" в URL и собственно их историю при переключении(JS History.pushState()).

Вот пример:
http://ra-germes.ru/catalog/adv/printing/business-cards/1102/?OFFER_ID=2530&MIN_QUANTITY=100


Работает немного через костыль, где-то идет кэширование и первая загрузка страницы выдаёт ошибку в "script.js"
Ошибка в том, что нет объекта this.offers[this.offerNum] и TREE не возможно определить. Пришлось прикрутить костыль по перезагрузке страницы. Комменты в студию. Разработчикам просьба внедрить такой функционал.


p.s. Спросите ЗАЧЕМ? - для таргетированной рекламы хорошо подходит направлять пользователей на чётко заданные страницы. Да и обмен ссылками упрощается.

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

Добавьте этот функционал для SKU тоже.

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

Добавить возможность выбора еденицы измерения для генерируемых торговых предложений

Поддержка SKU - это огромные портянки кода, иногда в самых неожиданных местах, и в тех случаях, когда они не нужны, их приходится очень долго и очень аккуратно вычищать. К тому же приличная часть этого кода расположена в шаблонах, что не по фен-шую. Поэтому, собственно, предложение - разделить ветки компонентов на "простые" - текущую ветку, с убранными наворотами, и "продвинутые" - с кодом поддержки SKU, включенным в компонент, а не в шаблон.

Часто встречаюсь с задачей, когда необходимо отфильтровать не только товары по свойствам их товарных предложений, но и фильтровать сами предложения и выводить для товара только те, которые удовлетворяют фильтру. Я решил этот вопрос переопределением(через extends, а не модификаций ядра) метода GetOffersArray системного класса CIBlockPriceTools.

Читать подробнее...

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

Для свойства Строка, в отличие от свойств Список и Справочник, отсутствует уникальный идентификатор значения (ID), что впрочем не является проблемой. Вместо ID значения можно использовать хэш значения. Или же в процессе формирования страницы перебрать все значения присутствующие в данном наборе элементов, и путем текстового сравнения задать для каждого уникального значения уникальный индекс т.е. поросту пронумеровать все уникальные значения.

Создаем товар: Портфель "Анджелина Джоли"
Генерируем торговые предложения для этого товара, в названии ставим макрос Свойство родителя -> Название

Нажимаем генерировать, получаем: Портфель &quoАнджелина Джоли&quo

Собственно сабж.
Сейчас выбираются все активные торговые предложения, но бывают ситуации, когда ТП обладают некоторым свойством, которое накладывает свою логику отображения. Например создание ТП с привязкой к разным городам/складам.

Добавьте, пожалуйста, в генератор SKU возможность геренерации товаров с расширенным режимым управления ценами.

Сейчас мы можем при генерации задать только одну цену, которую получат все товары, а бывает нужно задать диапазон цен, в зависимости от количества:

1...10 - 100 руб.
11....20  - 90 руб.
21...30 - 80 руб.
... и тд.

По возможности предоставить больше способов для отображения свойств элементов.

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

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

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


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

1. 1.5 спальный,
2. 2 спальные,
3. Евро,
4. Cемейный.
   

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

Много магазинов работает с SKU. При использовании складского учета товары "заводятся" и списываются со складов с учетом SKU (только SKU). Но в отчетах по остаткам товаров нет возможности работать с SKU. Получается что складской учет работает, но остатки и движение товаров посмотреть нельзя.

На данный момент функция не учитывает,  что поле привязки SKU может быть множественным. Например для формирования комплектов товаров в торговое предложение. И возвращает только один товар.

Добавить функционал SKU для обычных инфоблоков. Имеется ввиду добавление на форму редактирования элемента списка подчиненных элементов

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

Элемент этого же инфоблока - выпуск
Элементы другого инфоблока - статьи
необходимо добавить статьи, после чего только выпуск в журнал.