Ну это если совсем-совсем коротко, по верхушкам...
Я ответил на Ваш вопрос?
Нет.
Я написал план реализации, вы ушли в маркетинг и мотивацию при выборе CMS, но что конкретно вас подтолкнуло в моем посте на обсуждение этих вопросов вы не написали.
Я продублирую вопрос
>не понял каким именно действием или реализацией чего-то конкретного, по вашему мнению, я ограничу применимость CS-Cart для средних компаний?
imac
Предлагаю завершить углубление в продуктовый маркетинг.
Был неправ, необдуманно, не по адресу позволил себе высказать необоснованные претензии.
Извините. Извинения приняты?
Технический вопрос, как к разработчику.
Родительский продукт - это реальный SKU или виртуальный-фейковый?
Виртуальный, тот к которому привязаны все вариации
При импорте вариаций,
код родительского продукта должен быть уникальным или не обязательно?
код родительского продукта создается автоматически, или его нужно формировать заранее?
Если формировать - можно его формировать произвольно при каждом импорте?
Или он должен быть одним и тем же и его нужно сохранять где-то во внешних системах?
Что будет в базе при ежедневном импорте прайс-листов, если код родительской вариации формировать произвольно, при подготовке прайс-листа для импорта?
imac
Вопросы заданные в предыдущем посте - снимаются, проверил на http://dev.demo.cs-cart.ru/?url=admin.php
Структура файла экспорта импорта сейчас и то, о чем описывал словами в предыдущих сумбурных постах, представлено на скриншоте.
Отобразил то, что есть сейчас, и то, как можно, на мой взгляд, улучшить
[url=https://b.radikal.ru/b13/1802/53/8e4ed8621e91.jpg]
[/url]
а возможно как то всю базу товаров перевести на вариации с опций... не вводя товары заново?
imac
Предлагаю завершить углубление в продуктовый маркетинг.
Был неправ, необдуманно, не по адресу позволил себе высказать необоснованные претензии.Извините. Извинения приняты?
Вы уж через чур официально) Я все ваши сообщения воспринимаю как дискуссию и обратную связь. За что вам очень благодарен. То что ушли немного в сторону - бывает.
Что касается фильтров план пока такой, попробуем сделать синхронизацию опций с характеристиками, чтобы можно было удобно работать с фильтрами. А дальше будем смотреть.
imac
Не стоит благодарить :-) Спасибо.
Важнее иное- Вы посмотрели пример-структуру файла импорта-экспорта?
Все ли понятно?
Видите ли какие изъяны-ограничения в приведенной структуре? Для обработки-учета вариаций? Комплектов товаров? Дополнительных товаров? Обязательных(требуемых) товаров? Сопутствующих(рекомендуемых) товаров?
Или уже с вариациями обратной дороги нет? Так и будет требоваться отдельная строка с виртуальной родительской вариацией и тремя типами товаров?
Илья, еще один момент вообще по функционалу фильтров. Он уже несколько раз упоминался на форуме.
Точнее два момента:
У нас клиент может искать соседние роста, соседние размеры, соседние комбинации роста/размера. При выборе одного варианта, он «выпрыгивает» вверх. Некоторых просто нереально выбешивает. Ну с чего это вдруг размер 60 становится раньше 44-го? Это же совершенно нелогично?
Как я понимаю, на сегодня простого решения, как отключить эту функцию, нет. Были предложения закомментировать строку типа
scroll: '.ty-mainbox-title',
в файле js/tygh/product_filters.js
только это ни к чему не приводит. Во всяком случае, у меня ничего не вышло, кеш весь удалял.
Ну и обновление страницы каждый раз при наборе последовательности фильтров тоже может доставлять кучу отрицательных эмоций.
Нужна кнопка «Обновить» или «Применить». Просто представьте, вам нужен летний полукомбинезон из хлопка с карманами для наколенников, световозвращающими лентами, оранжевого цвета, размера 50 роста 182. Имеем 6 чекбоксов. Шесть раз страница обновится и пят раз придется скроллить с начала, чтоб найти нужные комбинации. Не каждому такое понравится.
Можно будет это прикрутить к новой версии?
Привет
В этой задаче я хотел бы поднять вопрос о том как должны работать фильтры по опциям.
Я прошел по некоторым популярным магазинам Lamoda, Wildberries, Next, Zappos и другие.
Могу сделать несколько выводов:
- некоторые магазины создают отдельный URL для каждой цветовой вариации, а вот у разных размеров URL один и тот же. Иными словами для каждого цвета создается отдельный товар, а размеры являются единственной опцией.
- В базе, каталоге и поиске отображаются всегда все вариации цветов как отдельные товары https://www.evernote.com/shard/s257/sh/7babf55d-7217-4935-97cc-9a62bdc40a1e/702491e8610d5b4c
- Фильтр по цветам обычно сводится к группировке цветов под существующие. Т.е. даже если цвет у футболки розовый, она будет отображаться в фильтре по красному цвету https://www.evernote.com/shard/s257/sh/8c316c12-b6cf-441a-8801-3646df12a4a6/8daf61fc050203c9
Мы запустили опрос по опциям и тому как вы ими пользуетейсь.
Что мне хочется выяснить в этой теме, это какие товары вы продаете с опциями и как вы видите удобную работу с ними на витрине и фильтрах?
Высказывайтесь, чем детальнее тем лучше - давайте сделаем этот функционал удобным!
Очень нужно все, что перечислили.
Для одежды и обуви каждая цветомодель товара (цветовая вариация) должна выводиться в списке товаров (в категории) отдельным товаров. Люди выбирают такие товары глазами и не заходят в карточку каждого товара посмотреть, есть ли такая модель в другом цвете. Цвет имеет один из наивысших приоритетов.
Есть категории товаров, где также присутствуют цветомодели. Но покупатели выбирают цвет уже в карточке товара, т.к. он менее важен. В данном случае выводить в каталог каждый цвет такого товара как отдельный товар не нужно. Это например стельки для обуви.
Фильтр по размерам в наличии - это просто MUST HAVE.
Теперь к примерам.
Я думаю что понять то что написано выше, довольно сложно, так что давайте я покажу на примере.
Берем Wildberries:
https://www.evernote.com/l/AQHIyVanM8lGRJuWuDa7hHUVC3HwbbU6IxE
теперь поясняю.
1. Для того чтобы отдельные цвета отображались как отдельные товары мы их создаем как полноценные товары.
2. Для того чтобы как то связать товары из пункта между собой, мы каким то образом группируем их в админке по принципу "Цвет"
3. У каждого товара из пункта 1. есть вариации, на картинке это только размеры.
Сейчас передо мной стоит только один вопрос, как правильно реализовать пункт 2, т.е. группировать товары по определенному признаку.
Пункт 2.
Мне кажется тут все довольно просто.
Каждому товару должна быть возможность задать настройку, например, с названием "Модель". Записываем товару значение этой настройки и таким образом группируем. Все товары, у которых будет одинаковое значение данной настройки будет сгруппированы. В карточке таких товаров можно будет переключаться другим между другом - т.е. между всеми товароми с одинаковым значением данный нстройки
Как правило, в качестве значений данной настройки будут использоваться названия моделей или артикулы (часть артикула) моделей.
В нашей 1Ске каждая цветомодель заведена как отдельная номенклатура, а размеры заведены через характеристики. Если группировка будет реализована вышеуказанным способом, то нужно предусмотреть возможность синхронизации настройки товара "Модель" с данными в 1С (в 1С скорее всего добавим доп. реквизит, куда пропишем значение модели)
Очень нужно все, что перечислили.
Для одежды и обуви каждая цветомодель товара (цветовая вариация) должна выводиться в списке товаров (в категории) отдельным товаров. Люди выбирают такие товары глазами и не заходят в карточку каждого товара посмотреть, есть ли такая модель в другом цвете. Цвет имеет один из наивысших приоритетов.
Есть категории товаров, где также присутствуют цветомодели. Но покупатели выбирают цвет уже в карточке товара, т.к. он менее важен. В данном случае выводить в каталог каждый цвет такого товара как отдельный товар не нужно. Это например стельки для обуви.
Фильтр по размерам в наличии - это просто MUST HAVE.
Тут есть один нюанс. Если каждая "цветомодель" в фильтрации отображается как отдельный товар то и в каталоге она будет отображаться так же как отдельный товар. Т.е. в категории у вас будет столько товаров сколько цветов.
Так сделано например в Next http://www.next.co.uk/shop/gender-men-category-shirts/use-casual#1_498- посмотрите первый и пятый товар - это один товар но в разном цвете.
Тут есть один нюанс. Если каждая "цветомодель" в фильтрации отображается как отдельный товар то и в каталоге она будет отображаться так же как отдельный товар. Т.е. в категории у вас будет столько товаров сколько цветов.
Так сделано например в Next http://www.next.co.uk/shop/gender-men-category-shirts/use-casual#1_498- посмотрите первый и пятый товар - это один товар но в разном цвете.
Да, так и нужно. Каждый цвет товара одежды и обуви нужно в каталоге показывать отдельным товаром. Люди не переходят в карточку товара, чтобы посмотреть, а какие там еще варианты цветов этой модели сапог.... Все привыкли цвета смотреть непосредственно со страницы категории. Но при этом в самой карточке товара должна быть возможность переключиться на другой цвет этой же модели - соответственно будет переход в другую карточку товара. Например, зашел посетитель в карточку босоножек модели ХХХ золотистого цвета. Но 37-го размера нет в наличии. Но в наличии 37-го размера есть эта же модель, но бежевого цвета. Так вот, если из карточки босоножек ХХХ золотистого цвета нельзя сразу перейти на модель ХХХ бежевого цвета, то маловероятно, что посетитель вернется в каталог и будет по нему "шерстить" в поисках такой же модели другого цвета с 37-го размера.
То, как делают крупные магазины (как в ваших примерах) для категорий одежды и обуви - это и есть правильно.
Да, так и нужно. Каждый цвет товара одежды и обуви нужно в каталоге показывать отдельным товаром. Люди не переходят в карточку товара, чтобы посмотреть, а какие там еще варианты цветов этой модели сапог.... Все привыкли цвета смотреть непосредственно со страницы категории. Но при этом в самой карточке товара должна быть возможность переключиться на другой цвет этой же модели - соответственно будет переход в другую карточку товара. Например, зашел посетитель в карточку босоножек модели ХХХ золотистого цвета. Но 37-го размера нет в наличии. Но в наличии 37-го размера есть эта же модель, но бежевого цвета. Так вот, если из карточки босоножек ХХХ золотистого цвета нельзя сразу перейти на модель ХХХ бежевого цвета, то маловероятно, что посетитель вернется в каталог и будет по нему "шерстить" в поисках такой же модели другого цвета с 37-го размера.
То, как делают крупные магазины (как в ваших примерах) для категорий одежды и обуви - это и есть правильно.
Да, мы говорим об одном и том же.
Так и планирую на текущий момент.
Хорошо бы для каждой вариации товара иметь свой SEO.
И если опции будут как то связаны с харрактеристиками. Возможен ли будет обратный процесс. Собрать из множества товаров один родительский с опциями. К примеру у нас ситуация такая. Никогда не пользовались опциями. Каждый тип, размер имеет отдельную карточку все отличия в харрактеристиках. С такой возможностью можно было бы такие товары собрать под одним Родительским товаром с опциями и перемещаться по ним сменяя опции. Собираться они бы могли по общим харрактеристикам и их значениям скажем товары имеющие 3-5 общих харрактиристик и значений и дополнительной ручной настройкой исключая ненужные.
И немножко не по теме. Почему то обделили вниманием разработчики возможность для мета данных и остальных полей, генерировать данные через переменные/шаблоны/плейсхолдеры. С падежами или сторонними сервисами, библиотеками склонения. Вроде в Битрикс генерация seo и мета по переменным в типовую конфу заложено, а тут целый зоопарк модулей сторонних.
1С : Дополнительные реквизиты = CS-CART: опции(по умолчанию)/характеристики(многие переименовывают)/они же фильтры
1C : Характеристики = CS-CART: вариации
При условии что вся номенклатура грузится из 1С. Пришел к выводу что вариации не каждому товару подойдут к сожалению.
В 1С есть возможность привязывать реквизиты только к родительскому товару. А все характеристики 1С (вариации) привязаны уже к этому родительскому товару и имеют реквизит этого товара например вес, фото, длину, ширину и тд. Таким образом эта история при выгрузке из 1С работать не будет. Потому как данные для вариаций из 1С брать неоткуда. Этого просто не заложено. Останется только ручками на сайте добавлять все недостающие данные.
Возможный выход для таких товаров это собирать их в вариации на сайте из отдельных карточек.
Пример товара радиатор отопления. Он имеет массу общих характеристик: давление материал, цвет и т.д. Для него необходимо создать вариации товара по размерам 27 ширин и 3 высоты. 81 позиция. Из 1С эти данные передать невозможно для вариаций, только общие характеристики родительского товара. Но можно создать 81 товар со своими габаритами весом (вес будет отличаться существенно для ширины радиатора 400 или 3000 мм, важный параметр для доставки) и остальными уникальными параметрами, выгрузить на сайт и там это превратить в вариации объединив по нескольким характеристикам.
Я не предлагаю отказываться от существующей схемы. Для одежды она видимо хорошо подходит, хотя из 1С грузить все параметры все равно невозможно. А это все таки основная программа учета в РФ. Предлагаю дополнить создание вариаций еще одной схемой. Собирать их из отдельных карточек.
А хотя бы приблизительно понятно уже, в какой версии будет реализовано что-то подобное?
Мне кажется однозначно нужно делать просто: один товар - одна карточка, а все вариации делать динамически через объединение карточек по определенному признаку (характеристике (кам)), задаваемой в админке. Встает вопрос о том, что при показе содержимого категории товаров будут вываливаться все подряд карточки. Решение опять таки в группировке при выводе - на одно объединение карточек (по заданной характеристике (кам)) один вывод в сетке витрины. При включенном фильтре показывать опять таки с группировкой, но чтоб из группы карточек показывалась именно та, которая соответствует текущему фильтру, а остальные связанные карточки будут видны при детальном просмотре товара.
Вот на мой взгляд ссылка на хорошую реализацию ссылка
Тут отдельные карточки объединены (сгруппированы) по определенным признакам (модель дивана, тип и цвет), а в рамках этой группировки уже показаны разные размеры по ширине. При этом в каталоге показываются опять таки не все подряд карточки, а сгруппированные. А при фильтрации по размеру например все равно показывается все в сгруппированном виде, только главной при группировке становится карточка с подходящим к фильтру размером.
Сумбурно наверное объяснил, но основной посыл в том, что все товары должны быть равнозначными отдельными карточками (не нужно городить разные типы товаров), а остальное уже дело второе как их группировать и выводить на витрину магазина, тут уже полет фантазии может быть разный под разный бизнес, при этом базовые данные (структура данных о товаре) будут у всех одинаковые - один товар (вариация) - одна карточка
Судя по всему в 4.8.1 которая планируется на конец весны не успеваем. Поэтому видимо летом или осенью этого года.
Тут не все так просто.
В общем вариации это про то, что физически для админа это отдельные товары, а в клиентской части для клиента это товар тот же, но можно менять свойство (опцию)
Для реализации фильтров нужны именно обычные товары, но группировать их опять же нельзя по причинам выше.
По сути в этой теме именно такую реализацию и обсуждаем. Для того чтобы у товара было полноценное SEO имя, фильтрация по опциях (характеристикам) - нам проще их сгруппировать по какому то признаку.