[spoiler]
По-прежнему можно указать инфоблок торговых предложений для товаров в настройках модуля "Каталог":
Страница настроек модуля торгового каталога
Однако теперь инфоблок товаров не должен обязательно быть торговым каталогом (хотя такая ситуация возможна при необходимости).
Более того, управлять инфоблоком как торговым каталогом теперь можно в форме правки свойств инфоблока. О ней поподробнее.
Ранее, для добавления большого количества свойств инфоблока приходилось несколько раз сохранять настройки инфоблока. Теперь эта проблема снята - за один раз можно настроить нужное число свойств:
Закладка Свойства формы изменения инфоблока
Редактирование настроек свойства теперь происходит во всплывающем окне, без перезагрузки
страницы:
Окно настройки свойства инфоблока
Среди закладок формы правки инфоблока появилась еще одна - Торговый каталог (естественно, только для редакций, в которым входит модуль торгового каталога). На этой закладке можно управлять всеми настройками инфоблока как торгового каталога:
Закладка Торговый каталог формы настройки инфоблока
Т.е. чтобы указать, к примеру, размер НДС для конкретного инфоблока, можно сделать это в форме настройки инфоблока.
При создании инфоблока можно прямо на этой же странице создать и настроить инфоблок торговых предложений (название, тип инфоблока, нужный набор свойств - без каких-либо ограничений):
Создание инфоблока торговых предложений
Для нового инфоблока товаров можно создать новый инфоблок предложений, для уже существующего - создать новый либо выбрать уже существующий. Свойство привязки в инфоблоке торговых предложений создавать необязательно - система сделает это за Вас. Впрочем, свойство можно создать и самому. Условий два: свойство должно быть типа "Привязка к элементам" и не быть множественным.
После создания связки инфоблоков содержимое закладки Торговый каталог меняется. Для инфоблока товаров по-прежнему можно выбрать инфоблок торговых предложений, либо отключить поддержку торговых предложений:
Закладка Торговый каталог для инфоблока товаров с торговыми предложениями
а для инфоблока торговых предложений картина иная:
Настройки инфоблока торговых предложений
Инфоблок торговых предложений не может не являться торговым каталогом, пока привязан к инфоблоку товаров.
Перейдем к интерфейсу управления торговыми предложениями.
В форме правки элемента инфоблока так же появится новая закладка "Торговые предложения" (только для инфоблоков, имеющих торговые предложения):
Форма правки элементов инфоблока
Весь интерфейс реализован в ней. Основные требования, которые предъявлялись к интерфейсу:
- возможность быстрой правки предложений без перезагрузки страницы
- наглядность
- привычность для пользователя
- показ тех свойств и цен, что необходимо править и отслеживать чаще всего
Перечень торговых предложений для товара
Работа со списком торговых предложений аналогична работе со списком элементов инфоблока. Точно так же можно настраивать перечень и порядок колонок, использовать быстрое редактирование записей, осуществлять групповые операции над торговыми предложениями, сортировать список по различным полям.
На скриншоте - пример быстрой правки предложений.
Единственное ограничение - в списке нельзя править (лишь просматривать) свойства типа "Файл". Однако это легко можно сделать в форме правки торгового предложения, которая открывается во всплывающем окне:
Форма правки торгового предложения
Работать с элементами инфоблока торговых предложений можно и привычным способом - как с отдельным инфоблоком.
На следующем скриншоте - форма настройки перечня колонок в списке торговых предложений:
Мы постарались, чтобы интерфейс был максимально приближен к уже существующим.
Изменен фильтр для списка элементов:
В фильтре - свойства предложений
В публичной части так же возможно работать с торговыми предложениями:
Закладка Торговые предложения
Быстрое редактирование предложений
Добавление нового предложения (или правка уже существующего)
Уже знакомый стандартный интерфейс списка элементов запихали в отдельную вкладку формы редактирования, это круто, для этого потребовалось 1,5 года? Товарные предложения по прежнему приходится создавать вручную. Очередной костыль..
Wordpress посмотри -- вот там работа с SKU действительно круто сделана..
Думаю в Битрикс тоже будет.. года через 3..
PS: Вообще, я рад что это наконец-то появится хоть и в усеченном виде, и все же...
1. вы заводите два свойства типа список: размер (M, L, X, XL..), цвет (white, black, red..)
2. в форме редактирования товара отмечаете галочками (!) что у этого товара есть размеры X и L и цвета White и Black
3. система, сама, автоматом, в этой же форме ниже создает все возможные вариации товарных предложений:
футболка white L
футболка white X
футболка black L
футболка black X
4. удаляете лишние из них, назначаете им цену, кол-во на складе и тд.
Ну не круто ли?
А если комбинаций 64? Или 16 кликов мышкой или создание 64 элементов инфоблока, есть разница?
А вы имея готовый интерфейс списка элементов и готовую архитектуру товарных предложений (связанные элементы) постарались приспособить все это хозяйство под решение задачи. Получилось далеко не так удобно как это могло бы быть..
Любая маломальская БД состоит из нескольких связанных между собой справочников (Инфоблоков) каждый со своими свойствами (которые автозаполнением не установятся) -- крайне неудобно прыгать по множеству форм редактирования элементов при создании оной записи, что приходится делать в админке битрикс сейчас.
Простейшая БД:
инфоблок 1
Задачи
свойства:
заказчик (тип: привязка к элементам инфоблока Заказчики)
ответственный (тип: привязка к элементам инфоблока Ответственные)
оценка (тип: число)
....
Инфоблок 2
Заказчики
свойства:
наименование (тип: строка)
адрес
емаил
телефон
...
Хочется при создании новой задачи иметь возможность в этой же форме не только создать нового заказчика и ответсвенного привязанных к этой задаче, но и установить им ряд свойств (адрес, телефон итд)
Сейчас приходится открывать 3! формы редактирования, а еще дойти до них, туда да обратно.. количество кликов астрономическое..
Если свойств привязок даже 10, и для каждого из них своя вкладка с объектами -какая же будет форма и как долго она будет генериться.
В принципе быстрое создание связанного элемента - можно сделать из карточки основного, здесь поддержку, а в остальном пока кажется что слишком много надумано.
1. Интерфейс для SKU делался исходя из соображения "товар с предложениями как единая сущность"
2. Ситуацию, когда прямо в форме надо новый элемент из справочника, легко могу смоделировать. Ситуация, когда нужно прямо из формы полностью редактировать справочник - признак того, что надо срочно реорганизовывать работу. Нельзя одновременно делать несколько несвязанных дел.
3. С точки зрения юзабилити - однозначно шаг назад.
4. Кстати. Мы же храним только привязку к элементу. Если бы в форму приходили все свойства из записи справочника - тогда да. А в таком виде как сейчас - бессмысленно.
Роман, уж извините - не вижу смысла. Вообще.
Справочник он на то и справочник. Ведётся самостоятельно для фиксирования какого-то набора полей. Отсутствие нужного элемента справочника - ситуация частая и понятная. А вот каждый (ну условно) раз зачем-то редактировать существующий элемент... Зачем? Тогда не проще просто такие свойства завести в основном элементе и менять их, а не ссылаться на справочник?
Отдельный справочник Производителей. Где у нас бренды с логотипам, адресами официальных сайтов и прочее.
И вот мы создаем товар и нужно привязать его к новому производителю.
Сейчас нудно покинуть форму, добраться до формы создания производителя, вернуться обратно в карточку товара, привязать.
Удобнее было бы сделать это сразу в одной форме при создании товара.
А при разработке каких-нибудь нетривиальных сервисов и порталов со множеством связанных между собой справочников это было бы очень востребовано.
Смысл задачи я понял еще когда прочитал Ваш старый топик. Вам нужна работа со справочником в форме редактирования элемента, так? Без ухода из формы. С возможностью редактирования свойств записей справочника. Решение я предложил. Да, это будет всплывающее окно. Но работать оно будет.
Как и с генерацией символьных кодов, которые только для элементов, но не для разделов и только в публичке, а не при выгрузке из 1С.
Как и с редактированием файлов шаблонов компонентов из публички, где LANG редактируются только в редакциях с установленным модулем Перевод создать константу вообще нельзя. Java Script тоже не редактируется.
Как и с товарными предложениями выше.
Как и с ресайзом фотографий, которые только анонс и детальное, а не для свойства привязка типа файл. Ну тут ладно, была возможность свой модуль написать.
перечислять можно долго..
Во-вторых, данная операция автоматического создания не экономит время ни капли. Ну хорошо, нагенерили вы 16 элементов, а дальше что? Так и повесите продавать их? Или цена тоже автоматом заполняется?
Вам все равно придется кликать "редактировать", и править это SKU: прописывать цены, указывать картинки и т.п.. Что нажимать "редактировать", что "добавить" - сложность одинаковая. А экономия на том, что уже пара свойств заполнена значениями - очень небольшая, а если учесть - что еще ненужные комбинации надо удалить - вообще сомнительно, что вы что-то сэкономите.
ну да, как вы написали - мы сразу зарядили разработчиков и они приступили к большой работе
в вашем интерфейсе сейчас посчитаю.
1 клик создать
1 клик задать цвет
1 клик задать размер
1 клик сохранить
X2 товара = 8 кликов.
А если футболок 64?
16+1=17 кликов
против ваших 64*4=256 !!!
Во-вторых, ваши клики справедливы для очень-очень простой задачи, которая в жизни никогда не встретится в нормальном магазине. По вашему - у футболки может быть только 2 свойства и цена, но есть и артикул, и описание, и количество на складе, и цены разные от количества и многое еще чего есть. Мы предлагаем не строить аргументацию на примитивных примерах, а посмотрим на более серьезную задачу.
я могу вам легко накидать примеров задач, которые водпресс вообще не потянет, не говоря о том, что число кликов там будет больше.
Кстати, Насчет автосоздания множества - у инфоблока SKU могут быть разные настройки, в части обязательности полей например. В этом случае автосоздание не заработает. Цена например должна быть обязательно указана. И как партнер битрикса вы обязаны это знать.
Но, вот эту одну конкретную задачу, интерфейс работы с SKU можно сделать НАМНОГО удобнее. Я это вижу как ясный день.
Кстати, я забыл посчитать 1 клик в поле ввода названия товарного предложения и ввод с клавиатуры самого названия.. А в предложенном мной интерфейсе названия будут сгенерированы автоматически.
итого:
ввод 64 названий с клавиатуры и 5*64=320 кликов vs 17 кликов
+ цену вбить -- в обоих вариантах одинаковые трудозатраты, разве что при групповом редактировании это будет делать удобнее.
и это не обязательно и-м футболок, это может быть что угодно -- примеров можно придумать массу, где будет и 3 и 4 набора характеристик. Даже если цена от них не зависит, но на складе может быть разное количество товаров с разными хакартеристиками.
Согласен, что для больших и-м интегрированных с 1С это будет бесполезно -- нет нужды генерировать предложения так как они автоматом выгружаются из 1С. Связывать сгенерированные с выгруженными тоже проблема. А вот для маленьких и-м, без интеграции с 1с, это будет очень удобно.
PS: цену подставим 1 рубль, потом можно будет отредактировать -- проблем-то..
Вы мне напоминаете человека, который спорит с астронавтом, побывавшим на Луне, опираясь на рассказы Ж.Верна.
В который раз хочу вас обрадовать - автозаполнение названий SKU у нас уже есть. Штатно, в типовой поставке.
И напоследок - вместо того, чтобы хотя бы просто поблагодарить разработчиков и оценить мегаработу, которую они сделали (что ожидаешь от лояльного партнера), вы устроили опускание функционала на несколько постов и абстрактное сравнение с мифическим идеалом, основанным на системе, которой даже не нашлось место в списке систем для и-магазинов: .
Честно, не ожидал от вас, правда.
Кстати, установил обновление на рабочий сайт и сразу обнаружил ошибку:
В настройках модуля Каталог, существующий инфоблок с товарными предложения не был выбран как Инфоблок товарных предложений у Инфоблока с товарами.
После установки галочки -- повторно создалось свойство CML2_LINK. Я удалил этот дубль, а старому свойству CML2_LINK (которое создала 1С-ка при выгрузке) сменил тип с "Привязка к элементу" на "Привязка к товарам (SKU)".
Теперь, в карточке товара во вкладке "Товарные предложения" почему-то отображаются абсолютно все элементы из Каталога предложений.
Что я сделал не так?
Вспомнить тот же componet_epilog.php. Классная шутка, здорово что наконец-то сделали. Но, мы его для чего, в том числе, у вас просили? Для того чтобы для работы с генерацией TITLE и META-данными не приходилось стандартные компоненты кастомизировать. А он у вас отрабатывает перед вызовом settile и SetPageProperty в стандартных компонентах, которые установленные в componet_epilog.php значения переопределяют..
Выключил, удалил оба, включил, выгрузил товары из 1С -- свойство привязки к элементам пустое (ни одно торговое предложение к товарам не привязалось.)
Есть у нас ФУТБОЛКА, она имеет цвет белый, черный, зеленый.
Доступные размеры: XL, XXL, XXXL.
Кобминация цвет-размер --- ставится в соответствие один артикул. Покупателю нужно дать право выбрать футболку, ее цвет и размер.
Продавец должен знать артикул купленой футболки.
Как это было реализовано на самописном сайте, базу которого я перегнал на битрикс, обьяснять трудно, поэтому покажу картинкой:
[IMG]
Тоесть покупатель имел право выбрать цвет и размер. Результат выбора - ариткул и картинка.
[IMG]
Как такое сделать на БУСе - ума не приложу.
Очень прошу помощи более опытных разработчиков и пользователей системы 1С-Битрикс!
что такое SKU - это и есть сам товар со своим артикулом. У вас есть инфоблок товаров, есть инфоблок SKU (предложений). У предложения будет свой артикул, своя картинка, свой цвет и размер. Именно это предложение пойдет в корзину, будет в заказах и т.п. В этом и весь смысл SKU.
> Как такое сделать на БУСе - ума не приложу.
а я ума не приложу чего тут непонятного
> Очень прошу помощи более опытных разработчиков
Евгений все подробно рассказал и написал, будучи являясь разработчиком функционала и экспертом, какого еще разработчика вам предоставить?
У вас сейчас два схожих механизма есть:
1. покупка товара с характеристиками -- можно удобно чекбоксами и списками выбирать характеристики товара перед покупкой, но к сожалению от них ничего не зависит ни количество на складе ни цена.
2. SKU -- от них зависит и цена и количество на складе и что угодно еще, но нет готовых публичных компонентов для выбора характеристик списком или чекбоксами, только таблица со списком связанных товаров и у каждого своя кнопка купить.
В плане маркетинга -- все есть и все поддерживается. А реально, для решения задач пользователям все равно приходится обращаться к нам партнерам. На всякий случай пишу - вдруг вы не в курсе.
Добавили бы возможность заливать в список в формате, описанном мной, было бы очень хорошо. Хоть по отдельной кнопке тупо новый диалог вызывать с текстовым полем ввода, потом разбивать строки по значениям списка.
Дак вот я именно про форму занесения значений в свойство типа "Список". На каждое значение списка там отдельное строковое поле ввода. Поэтому копипастнуть туда сразу кучу значений нельзя.
скоро сделаем
- это
- это
- и это, если повезет
не скоро
- вот это
- и это
Вообще, клиенты путаются, зачем вносить данные 2 раза, вначале при регистрации в профиль пользователя, потом при заказе в профиль покупателя.
Иначе я вообще не разберусь. Когда есть реально работающий пример с данными и с ним можно поиграться - скорее обучаешься, нежели читать руководства.
1 - На какое число намечен выпуск данного обновления?
2 - Каким образом при импорте номенклатуры из 1С будет осуществляться по умолчанию привязка Торговых предложений к Товару?
3 - Будет ли возможность вести остатки по каждому Торговому предложению?
4 - Будет ли возможность вести остатки по нескольким складам?
2. Через свойство привязки. Проведете импорт - для это связки инфоблоков включится SKU.
3. Да.
4. Нет. Такой функционал штатно неикогда не поддерживался.
И вряд ли Роман хотел кого обидеть своим постом - Битрикс действительно лучший партнер и ребята много стараются, но... нас (партнеров) часто не слышат, на приоритеты в списке разработке повлиять мы не можем (ну не вижу я , каков текущий приоритет у моей хотелки) - приходится просто ждать.
Вообще, фишки битрикса развиваются так:
1. Появилась фишка на джумле или вордпрессе, ЮМИ или неткате
2. Партнеры пишут в разработку - хотим такую же
3. Битриксы аргументированно доказывают, что это не нужно
4. Партнеры пишут костыли
5. Проходит 2-3 года
6. Фишка реализуется в Битриксе
Вообще, показалось, что спор Артема и Романа - это взгляды со стороны разработчика (универсальность системы) и пользователя-редактора (юзабилити).
PS сорри за офтоп, наболело
Нашел небольшой баг в форме редактирования инфоблока торговых предложений (скрин ниже). Невозможно установить НДС - после применения/сохранения он опять сбрасыватся в "--не выбрано--". Я смог изменить "НДС по умолчанию" только в настройках модуля "Торговый каталог". Проявляется и в дистибутиве и в лаборатории.
И предложение: очень логично было бы, раз уже есть возможность устанавливать "ставку НДС по-умолчанию", также добавить чекбокс "Включать НДС в цену" и чекбокс "Уменьшать количество при заказе" на скрин выше и/или в настройках модуля "Торговый каталог".
Уменьшим количество телодвижений и риск пропустить параметр при ручном добавлении/редактировании товара. При импорте - сократим количество параметров позиции. Ведь в абсолютном большинстве случаев эти три параметра едины для всех товаров магазина.
Посмотрели, пощупали
Но вот есть вопросы.
Сейчас делаем магазин по контактным линзам.
Стоит задача: сделать в товаре выбор свойств, чтоб человек мог выбрать 2 параметра и нажал купить. А в корзину отправился товар с выбранными свойствами.
1 параметр - диоптрии(имеет 20 значений), 2 - цвет(10- значений).
Получается что нужно создать 200 предложений?
+ торговые предложения - привязываются только к 1-му товару, если 10 товаров - 2000 предложений?
посмотрели комплексную компоненту - там они выводятся не в виде простого select'a как хотелось бы, а в виде гигантской простыни из всех предложений с большой прокруткой.
или может я туплю и есть вариант попроще для 2-х select'ов в 10-ти товарах?
либо может это SKU не для таких задач?
Если нет - все проще и SKU не требуется.
Синхронизация с сайтом происходит стандартным методом при этом УТ может передавать наличие, измененные описания, фотографии, цены.
Если происходит редактирование инфоблоков непосредственно на сайте, то не вижу возможности передать изменения в 1С УТ.
Генерация одной кнопкой всех вариантов комбинаций свойств - тема!
Юзал и бед не знал.
Самая распространенная задача 2 свойства и в них до 5 вариантов.
В один клик делается весь возможный набор комбинаций 5х5 = 25 вариантов.
И из него удаляется все лишнее. и ставятся цены.
Ну а в Битриксе неудобно это реализовано.
Например, добавить пользовательское (или штатное) свойство "Привязка к элементам инфоблока с редактированием", и если оно стоит множественное - то показывать такую-же фору, как для привязки к SKU.
Взять, например, банальную привязку фотографий к карточке товара, до сих пор Битрикс рекомендует это делать через множественное свойство с типом "Файл", для которого нельзя настроить ни сортировку, ни водяной знак, ни автоуменшение фотограйфий, по хорошему это лучше делать через дополнительный связанный инфоблок, и конечно-же было бы удобно иметь возможность редактировать фотографии прямо таким-же списком как и SKU.
Обычное свойство с множественной привязкой, очень удобно было бы.
Если у меня каталог товаров на одном инфоблоке, и продает товары разных групп (Мешки и Подушки) и каждая группа товаров имеет свои свойтсва для торговых предложений (грузоподьемность и мягкость). Свойства сейчас всегда будут в этом интерфейсе одинаковые для всех групп товаров.
Впрочем, это задача похоже еще более глобальная и нерешаемя чем штатное свойство с привязкой к элементам как у SKU.