Фильтры По Опциям - Как Сделать Правильно

Общее Новости
1

Привет

В этой задаче я хотел бы поднять вопрос о том как должны работать фильтры по опциям.

Я прошел по некоторым популярным магазинам 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

Мы запустили опрос по опциям и тому как вы ими пользуетейсь.

Что мне хочется выяснить в этой теме, это какие товары вы продаете с опциями и как вы видите удобную работу с ними на витрине и фильтрах?

Высказывайтесь, чем детальнее тем лучше - давайте сделаем этот функционал удобным!

2 лайка
2

Илья, я на вопросы ответил. А тут, если интересно, распишу немного про комбинации размер/рост (с учетом наличия), как это реализовано у нас на sww.com.ru.

У нас одежда (подавляющее большинство моделей) имеет размер и рост (для цвета пришлось делать отдельные карточки, иначе вообще труба). Но мы решили, что в фильтре нам нужно решить задачу вывода не тех изделий, в которых возможна искомая комбинация размера/роста, а где в этой комбинации есть наличие товара на складе. Так как фильтр по комбинациям не работает, то модуль, который нам сделали классные ребята из Ecom Labs, сначала формирует из комбинаций характеристики (при редактировании комбинаций и изменениях остатков), для тех товаров, по которым остатки ненулевые. То есть если в каком--то размере/росте забрали последнюю штуку, из фильтра эта комбинация сразу же исчезает.

Есть один минус: приходится после каждого обновления лезть в ядро, корректировать функцию app/functions/fn.cart.php

1 лайк
3

Всем привет!

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

В некоторых случаях поставщики предоставляют 1 товар, например футболка с комбинациями опций, то есть синяя 42, красная 38 и тп.

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

В целом у каждого магазина свой подход, кто то делает 1 цвет и разные размеры, кто то по другому. Но самый популярный, это когда в одной карточке можно выбрать свой цвет и размер. При этом клиенты иногда расстраиваются, что к каждой комбинации нельзя написать свое описание (реже SEO). Так как к белой футболке можно написать другие рекомендации по стирке (например).

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

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

Модуль "Фильтр по опциям" позволяет создавать фильтры по опциям. Модуль смотрит на остатки и не будет создавать фильтры, если товара нет в наличии.

Модуль "Удобное отображение опций" позволяет выводить опции в красивых квадратиках в фильтре, каталоге и карточке товара. Поддерживает помимо Responsive поддерживает Uni и Youpi theme. Может выводить до 3 цветов в одном квадрате.

1 лайк
4

imac

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

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

Давайте определимся в различиях между характеристиками и опциями. Предлагаю такие определения:
Характеристики - это НЕОТЪЕМЛЕМЫЕ свойства товара. Их покупатель изменить не может.
Опции - ДОПОЛНИТЕЛЬНЫЕ свойства товара, покупатель решает - дополнять ими товар или нет... Предполагаю, что опции исторически появились из необходимости продавать программное обеспечение. В некоторых сферах это тоже работает. Например, мы знаем автомобиль + опции (доп.свойства).

Если остановиться на этих определениях, и уточнить систему работы с вариациями, то тогда все выстраивается

У нас есть простой товар с характеристиками
у нас есть вариации товаров (группа простых товаров одного типа, с отличающимися характеристиками)
и у тех и у других могут быть опции (доп. свойства)

То есть - 2 типа товаров. Товары с вариациями и товары без вариаций. Легко преобразуются одни в другие, путем установки-снятия кода принадлежности к главной вариации.
Эти 2 типа - на уровне программистской логики. Для операторов тоже два типа - с вариациями или без вариаций. Для покупателей - все это просто товары.

Фильтры по опциям (по доп.свойствам) не нужны. Есть работающий фильтр по характеристикам, которому нужно добавить логику отображения товаров с вариациями.

Не пугайтесь, Илья. Это не так страшно, как кажется при первом прочтении. у Вас все уже есть... Уточнение определений и однозначность идеологии не приведет к какому-то гробальному перекодингу

Карточка товара простого товара
Без опций - нет проблем, уже есть
с опциями (доп. свойствами) - уже есть

у вариаций ставится признак - отображать все вариации на одной карточке товара или для каждой вариации формировать отдельный УРЛ-отдельную карточку товара
у вариаций ставится код головной(основной) вариации, по которой и собираются вариации на карточке товара.
у вариации ставится код позиции отображения(значимости) вариации в группе.

Карточка товара группы вариаций
текущий механизм отображения опций (размеры-цвета и т.п.) ЗАМЕНЯЕТСЯ для вариаций на новый - отображается Набор ОТЛИЧАЮЩИХСЯ Характеристик (размеров, габаритов, цветов, мощностей и т.п.) для товаров ГРУППЫ вариаций.
Тут будут некоторые проблемы, но механизм отображения тот же самый, что и для опций, меняется источник данных для отображения, т.е. вся основа уже есть.

Если для вариации указан признак - формировать отдельный УРЛ, то тут же, на карточке группы вариаций показывается список страниц-урлов смежных вариаций группы,
у КОТОРЫХ могут быть и ОПЦИИ (доп. свойства).
Т.е. карточка товара вариации, для которой указан признак формировать отдельный УРЛ - точно ТАКАЯ ЖЕ, как карточка простого товара.

Вся система получается целостной и непротиворечивой.

Отображение в категориях и фильтрах ХАРАКТЕРИСТИК.
Если для вариации указано - формировать отдельный УРЛ, то вариация показывается как простой товар
Если для вариации НЕ указано формировать отдельный УРЛ, то показывается карточка группы вариаций, с названием и фото подходящей по условиям фильтра вариации и ее позиции в группе.


Перспективы
В конструкции заложена возможность расширения - строить дерево групп вариаций (это дебри, упоминаю, т.к. ниже разберем пример приведенный Вами)


Посмотрим, как описанное поведет себя в приведенных Вами примерах

- некоторые магазины создают отдельный URL для каждой цветовой вариации, а вот у разных размеров URL один и тот же. Иными словами для каждого цвета создается отдельный товар, а размеры являются единственной опцией.

То, что упомянул про дерево групп вариаций. Конструкция позволяет решить такие задачи. Причем крайне легко, путем изменения нужного кода головной вариации, БОЛЬШЕ НИЧЕГО не МЕНЯЯ.

- В базе, каталоге и поиске отображаются всегда все вариации цветов как отдельные товары https://www.evernote...02491e8610d5b4c

Предусмотрено. Отображаются вариации, для которых указано - формировать отдельный УРЛ

- Фильтр по цветам обычно сводится к группировке цветов под существующие. Т.е. даже если цвет у футболки розовый, она будет отображаться в фильтре по красному цвету https://www.evernote...daf61fc050203c9

Ну это обычный, уже существующий, фильтр характеристик. Тут уже все работает. Указываются две характеристики. "Цвет" и "Цветовая гамма". Одна характеристика выводится в фильтре, а другая - в карточке товара. Больше операторская работа, чем программистская.

Резюмирую.

Если однозначно определить и разделить Опции(доп.свойства) и Характеристики(неизменные свойства), и то, что и те и другие могут относиться к любому простому товару, а вариации - это группа простых товаров, отличающихся Характеристиками, но у каждого из которых могут быть свои Опции, то вопрос про фильтры опций снимается с повестки дня, а на передний план выходит вопрос, есть ли какие задачи, какие товары, какие способы продаж, что не могут быть решены при этих определениях?

5

То есть - 2 типа товаров. Товары с вариациями и товары без вариаций. Легко преобразуются одни в другие, путем установки-снятия кода принадлежности к главной вариации.
Эти 2 типа - на уровне программистской логики. Для операторов тоже два типа - с вариациями или без вариаций. Для покупателей - все это просто товары.

--------------------------------

у вариаций ставится признак - отображать все вариации на одной карточке товара или для каждой вариации формировать отдельный УРЛ-отдельную карточку товара
у вариаций ставится код головной(основной) вариации, по которой и собираются вариации на карточке товара.
у вариации ставится код позиции отображения(значимости) вариации в группе.

Какая-то путаница...

Далее по тексту упоминается какая-то группа?

Как на счет учета по наличию?

Как на счет импорта/экспорта?

На счет "опций", как дополнений, согласен. Варианты товаров должны создаваться из характеристик товаров.

6

У нас есть простой товар с характеристиками
у нас есть вариации товаров (группа простых товаров одного типа, с отличающимися характеристиками)
и у тех и у других могут быть опции (доп. свойства)

Да, этой логики не хватает - у меня есть термостат 3-х цветов, а еще к нему может быть дополнительная новая рамка, без рамки вообще, без датчика

При этом цвет - опция конкретного товара, а рамка, наличие датчика - глобальные опции

цвета - это характеристики

рамки - опции

датчик - опция

А по существующей логике мне нужно или делать 3 товара (цвета) с опциями (+доп. рамка, без рамки, с датчиком, или делать порядка 7 опций для одного товара, а преобразовать их в вариации уже не реально...

А представьте что у меня добавился новый цвет - нужно перегенерировать все вариации... добавить опять к ним изображения... 20-50 штук

7

В случае с одеждой/обувью, то вариант работы с опциями выглядит вполне привычно по юзабилити (отдельная расцветка – отдельная карточка товара). Переключение во фронте между цветами одной куртки, к примеру (по сути опциями "цвет" товара) уже дописывается отдельно. Опции скриптом перегоняются в характеристики (либо сторонние модули). Либо реализуйте фильтр по опциям – не очень понятна парадигма фильтрации только по характеристикам.

Касательно фильтров – при выборе двух и более расцветок куртки вариант, когда у товара опция "Цвет" зашита в одной карточке товара, просто не отрабатывает корректно, т.к. выполняется сразу несколько условий: "черный, белый, красный", например. Что должен выдавать страница фильтра для товара в таком случае? Вот и все. У вариаций ровно та же проблема. Проблемы с отображением в каталоге разных опций/вариантов одной сущности при фильтрации, как и проблемы, связанные с СЕО (а эти вопросы нужно решать в связке) – ни опции, ни вариации в текущем виде из коробки не решают.

​Т.е. карточка товара вариации, для которой указан признак формировать отдельный УРЛ

Поэтому поддержу идею установить возможность указывать, нужно ли генерировать отдельный URL для конкретной вариации/комбинации в зависимости от нужд. Это будет вполне уникализированным решением. А там уже каждый сам решает, как ему нужно управляться с листингом, от какой структуры сайта отталкиваться и через что выводить фильтры: опции, характеристики или отдельные карточки товара (скорее всего все вместе взятое).

P.S. По поводу фильтров есть пожелание сделать более гибкий инструментарий для управления, где и какие фильтры выводить на определенных страницах (бренды/новинки/скидки и т.д.)

8

Илья, я на вопросы ответил. А тут, если интересно, распишу немного про комбинации размер/рост (с учетом наличия), как это реализовано у нас на sww.com.ru.

У нас одежда (подавляющее большинство моделей) имеет размер и рост (для цвета пришлось делать отдельные карточки, иначе вообще труба). Но мы решили, что в фильтре нам нужно решить задачу вывода не тех изделий, в которых возможна искомая комбинация размера/роста, а где в этой комбинации есть наличие товара на складе. Так как фильтр по комбинациям не работает, то модуль, который нам сделали классные ребята из Ecom Labs, сначала формирует из комбинаций характеристики (при редактировании комбинаций и изменениях остатков), для тех товаров, по которым остатки ненулевые. То есть если в каком--то размере/росте забрали последнюю штуку, из фильтра эта комбинация сразу же исчезает.

Есть один минус: приходится после каждого обновления лезть в ядро, корректировать функцию app/functions/fn.cart.php

Я так понял, у вас основной посыл в том что вы не просто по опциям фильтруете а еще и по наличию?

Т.е. в результатах фильтрации отображается только то что в наличии.

9

Да, этой логики не хватает - у меня есть термостат 3-х цветов, а еще к нему может быть дополнительная новая рамка, без рамки вообще, без датчика

При этом цвет - опция конкретного товара, а рамка, наличие датчика - глобальные опции

цвета - это характеристики

рамки - опции

датчик - опция

А по существующей логике мне нужно или делать 3 товара (цвета) с опциями (+доп. рамка, без рамки, с датчиком, или делать порядка 7 опций для одного товара, а преобразовать их в вариации уже не реально...

А представьте что у меня добавился новый цвет - нужно перегенерировать все вариации... добавить опять к ним изображения... 20-50 штук

ну вы сейчас и на вариациях это можете сделать.

У вас на основе цвета будут сформированы вариации, а рамки и датчик это опции у основного товара.

10

Developstores

Да, терминология не устоялась и хромает. Согласен, сумбурность присутсвует. Но я же не ТЗ пишу, а типа общаюсь на форуме :-)

Хочется достичь полноты общей логической конструкции и сделаю еще итерацию...

Выше говорил о 2х типах товаров, но неверно их определил. Каюсь.
Тип товара - 1. Простой товар. Идентификатор - SKU
Обладает свойствами и связями-отношениями.
Свойства
Характеристики (неизменяемые свойста) - могут указываться, а могут и не указываться (если все ствойства указываются в названии)
Например: цвет, размер, габариты, емкость, напряжение, форма, применение и т.п.
То, что продавец не может изменить у товара.
Опции (изменяемые свойста), - могут указываться, а могут и не указываться
как правило, это услуги, которые могут быть связаны с товаром - упаковка, продленный срок гарантии и т.п. -
Это то, что может продавец изменить, в связи с чем может измениться конечная цена. Суть опций - модификатор цены.

Связи-отношения
Вариации - товар может быть родителем или дочерним товаром группы вариаций.
Вариаций объединяются на логическом уровне, через указание SKU родительского товара.
УРЛ уже есть у всех товаров, нужен только признак - формировать или не формировать отдельный УРЛ, и нужна позиция данного товара в списке вариаций, если он - дочерний в вариации и нужно еще поле - Наименование товара, если он родительскаяя вариация.
И вроде все.
Требуемые товары (товары, без которых товар купить нельзя) - уже есть и тоже на логическом уровне. (не смотрел как строятся, скорее всего или по SKU или по product id)
Сопутствующие товары (товары, которые дополняют данный товар) - уже есть и тоже на логическом уровне. (не смотрел как строятся, скорее всего или по SKU или по product id)
Оптовые скидки по данному товару - уже есть
Отзывы по товару - уже есть
похожие товары - уже есть и несколько, по разным алгоритмам

Фильтры
Фильтры строятся по характеристкам(по неизменным свойствам). Если продавец захочет дать возможность выбирать товар по опции, например, по наличию расширенной гарантии, то такому экзоту придется нужную опцию продублировать в Характеристику.

Для вариаций и опций не нужны различные типы товаров. Все уладывается в существующий один тип товара.

Как на счет учета по наличию?

Как на счет импорта/экспорта?

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


Но тип товара 2 должен быть.
Это комплект-набор товаров (составной товар). Это - головная боль.
Особеность его в том, что комплект -это отдельный SKU, который является суммой других SKU, со своим названием, своей ценой, своим наличием
Сложность тут,в общем случае - именно опции дочерних товаров, которые в комплекте не предполагают выбор, должны быть однозначно определены, т.к. цена комплекта не должна меняться
Потребность в комплектах есть.
И концепцию комплектов нужно определять сразу, для целостности.


Путаница тут в том, что с точки зрения оформления пользователь, на странице карточки товаров, не видит различия - что перед ним?
Представление одинаковое - селекторы, радиобаттоны. А вот для операторов и программеров - это разные источники данных.

Товар с опциями (букет цветов с ленточкой, упаковкой, поздравительной открыткой) - покупка: 1 SKU+одно или несколько дополнений с измененнием конечной цены
Вариация товаров (рубашки 5ти цветов и 5 размеров) - группировка-облегчение выбора-поиска товаров для потребителя по характеристикам, покупка: 1 SKU. Цена видна стразу.
Комплект товаров (комплектация нескольких товаров по фиксированной цене) - покупка: несколько SKU, выбранных-объединенных оператором, одним нажатием "Купить". Цена видна сразу.
и в пределе -
Пользовательский конструктор комплекта товаров (то, что называют автомобилем с опциями) - конструирование своего набора SKU из автоматизированно предложенных вариантов одним нажатием


Guest_Алексей

Касательно фильтров – при выборе двух и более расцветок куртки вариант, когда у товара опция "Цвет" зашита в одной карточке товара, просто не отрабатывает корректно, т.к. выполняется сразу несколько условий: "черный, белый, красный", например. Что должен выдавать страница фильтра для товара в таком случае?

Если цвет будет Характеристкой проблем не будет. Надо только учитывать, что каждую куртку надо будет приходовать как отдельный товар, со своими характеристиками Цвет-Размер. А потом все куртки этого фасона-модели объединить в вариацию (указать код родительской куртки)

у меня есть термостат 3-х цветов, а еще к нему может быть дополнительная новая рамка, без рамки вообще, без датчика

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


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

11

Сумбур не то слово. Пример моих товаров.

У меня товар "Стальной радиатор" у него.

Высота: 200, 300, 500, 600, 900 мм

Глубина 50, 60, 100, 155

Длина: от 400 мм до 3000 мм.

Тип подключения: Боковое подключение, Нижнее подключение.

Это где то +/- 800 вариаций.

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

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

Но точно знаю, что в списке сравнения должна быть возможность менять вариацию не выходя со списка сравнения.

12

Я так понял, у вас основной посыл в том что вы не просто по опциям фильтруете а еще и по наличию?

Т.е. в результатах фильтрации отображается только то что в наличии.

Да, Илья, совершенно верно, в результате будут показаны только те товары, у которых есть в наличии остатки для выбранной комбинации.

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

13

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

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

14

Konrad

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

Вариации must have, тут никто и не спорит. Писал об этом еще здесь: http://forum.cs-cart.com/topic/50363-%D0%BF%D1%80%D0%BE-%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D1%86%D0%B8%D0%B8-%D1%82%D0%BE%D0%B2%D0%B0%D1%80%D0%BE%D0%B2-%D0%BF%D1%80%D0%BE-%D1%82%D0%B5-%D1%87%D1%82%D0%BE-%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0%BB%D1%81%D0%B8%D1%81%D1%8C-%D1%81-v461/#entry288435
Разговор о другом.
Отфильтровать конкретную вариацию Вы можете, продублировав опции в Характеристики.
Но встает вопрос - а зачем тогда нужны опции? Зачем дублировать данные?
Опции в текущей реализации нужны для только для поддержки вариаций.
Вот про это и разговор-предложение-пожелание, чтобы Вариации сразу могли работать с Характеристиками.

В чем узкое место?
в том, что то, что называется Опции в Cs-cart несет слишком много смыслов.
1.
Это Неизменяемые свойства товара
2.
Это Дополнительные свойства товара (услуги)
3.
Это Дополнительные товары, со своими SKU (кодами товара), которые имеют свое наличие и требуют своего учета.

+ сейчас навешиваются еще вариации.

А пользователям часто нужны все смыслы ОДНОВРЕМЕННО. И тут возникают напряги у всех.

Предложение разделить эти смыслы, навешанные на Опции - упростить логику.
И так как сейчас внедряется функционал Вариаций, начать с него, пока партнеры-интеграторы-пользователи не начали навешивать на существующую структуру данных интеграции и софт, не начали настраивать под это ERP и CRM

Кстати - вопрос. Товар может относиться к нескольким вариациям? Не сегодня, так завтра?
Предлагаемая выше схема не препятствует этому.

Техническая часть.
Все таки насчет 2х типов товаров (простые и составные), опять был неправ.
Похоже - есть возможность на предлагаемых механизмах все свести к 1 типу товара,
который будет легко изменяться из простого в вариацию и наоборот.
из простого товара в составной(комплект) и наоборот.

Прием тот же самый, что описан для вариаций - добавление в карточку товара (или строку импорта) родительского SKU (одного или нескольких через принятые в cscart разделители-";" )

Товар может входить в несколько комплектов? Безусловно.
Предлагаемая выше схема не препятствует этому.

То есть однозначность - 1 SKU = строка импорта-экспорта можно обеспечить, передавая туда-сюда все связи-отношения.

Еще есть терминологическая черная дыра.
"Сопутствующие товары", "Требуемые товары" и "Дополнительные товары" - чем они отличаются?

"Требуемые товары" сейчас как работают? При покупке душевой кабины, требуется поддон и лейка-шланг.
Добавляем 4 возможных варианты поддонов и 20 видов леек в "Требуемые товары"
Сколько товаров добавится в корзину? 2 или 24?

15

Привет, рад что идет активное обсуждение этой темы.

Вступление:

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

2. Все то что имеет отдельное количество например "футболка синия, XL" (вариация, комбинация или обычный продукт) должно быть отдельной сущностью с которой можно работать через Импорт Экспорт и выгружать синхронизировать с 1С или Яндекс.Маркет (сейчас так умеют обычные товары и вариации).

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

Как я вижу эту реализацию:

1. Все опции на которых строятся вариации всегда должны иметь дубликат в виде характеристик.

2. Родительский продукт который содержит вариаций всегда должен иметь все характеристики которые есть у его продуктов-вариаций.

Эти два пункта позволят сделать следующее:

- все вариации можно будет фильтровать - в результате будет отображаться родительский товар

- вероятно упростим импорт вариаций (т.е. привязка к опциям будет делаться через характеристики)

3. Все товары, которые должны отображаться в фильтре и магазине отдельно для каждого цвета - будут создаваться отдельным полноценным товаром.

Теперь к примерам.

Я думаю что понять то что написано выше, довольно сложно, так что давайте я покажу на примере.

Берем Wildberries:

https://www.evernote.com/l/AQHIyVanM8lGRJuWuDa7hHUVC3HwbbU6IxE

теперь поясняю.

1. Для того чтобы отдельные цвета отображались как отдельные товары мы их создаем как полноценные товары.

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

3. У каждого товара из пункта 1. есть вариации, на картинке это только размеры.

Сейчас передо мной стоит только один вопрос, как правильно реализовать пункт 2, т.е. группировать товары по определенному признаку.

16
2. Родительский продукт который содержит вариаций всегда должен иметь все характеристики которые есть у его продуктов-вариаций..

Родительский продукт - это реальный SKU или виртуальный-фейковый?

17

Родительский продукт - это реальный SKU или виртуальный-фейковый?

Виртуальный, тот к которому привязаны все вариации

18

imac

Вы делаете ошибку. Не как разработчик. На уровне продуктового маркетинга.

Ограничиваете сферу применения cs-cart

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

Чуть поясню.

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

2.
У малых компании горизонт планирования 3-6 месяцев. У средних - 2-3 года. Выбирая движок-платформу - изучают перспективы платформы. И то, что cs-cart ограничивается одиночками или малыми компаниями (игнорируя, или не видя потребностей средних компаний), это исключает его из числа возможных претендентов на несколько лет вперед.

Моя печаль, как проектировщика систем, в том, что мне интересен рынок средних компаний, или малых, с хорошим потенциалом вырасти до средней. Как говорил, в некоторых сферах, с оговорками, можно использовать cs-cart как движок.
Хотелось, чтобы было с чем и на рынок fashion выходить.. Чтобы ограничения движка уменьшались, а не росли.. :-(

Вы поняли, о чем говорю и что имею в виду?

19


Вы поняли, о чем говорю и что имею в виду?

Я понял о чем вы говорите, но не понял каким именно действием или реализацией чего конкретно, по вашему мнению, я ограничу применимость CS-Cart для средних компаний? Если поясните что конкретно в посте о реализации привело вас к этом мысли буду благодарен.

20

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

в средних компаниях участвует в принятии решения много позиций и у каждой свои KPI и свои интересы.
Один из сценариев, где всего 2 позиции...
Руководство приходит к мысли о необходимости через 2 года в составе бизнеса иметь и-магазин. Ставится задача Директору по IT проработать вопрос.
Напомню - компания средняя, у нее своя история, в течении которой уже накопилось и используется туча оборудования, софта, взаимодействующего и обменивающегося данными между собой, ежедневно генерирующего десятки отчетов для разных служб, на основании которых и строится вся деятельность.
KPI директора по IT зависит от бесперебойности работы этой системы. Но директор по IT не дурак и понимает, что все что он делает, делает для продаж. Поэтому Директор по IT делает запрос Директору по маркетингу - какие функции и-магазина нужно обеспечить?
KPI директора по маркетингу зависит от количества чеков и среднего чека. Он живет в этом мире: https://dreamkas.ru/blog/srednii-check/, http://hobiz.ru/lib/fraud/9-sposobov-uvelichit-srednij-chek/ , https://delovoymir.biz/11-sposobov-uvelichit-sredniy-chek.html (ссылки для примера)
Весь софт существующей компании уже заточен на реализацию этой философии. И, не мудрствуя лукаво, Директор по маркетингу отписывает Директору по IT - и-магазин должен быть встроен во все наши системы учета и поддерживать все наши маркетинговые программы.
Директор по IT пишет список маркетинговых программ, которые зашиты в процессах компании и его софте - "на карточке товара должны быть:
- дополнительные услуги к товару,
- дополнительные товары
- обязательные товары
- сопутствующие (рекомендуемые) товары
- комплекты, в которых участвует товар
- аналогичные товары с другими, близкими характеристиками (список вариаций)
- похожие товары (другие товары с такими же характеристиками)
Далее он смотрит в интернете какой-нибудь авторитетный, с его точки зрения, рейтинг по надежности CMS (помним о его KPI), например: https://roem.ru/14-04-2015/192219/cms-highload/ ,
идет на сайты CMS, смотрит список партнеров-интеграторов и отправляет запросы-список требований указанных выше и добавляет, что существующая система учитывает товар по SKU и данные и связи между данными передаются в CMS из существующих систем через SKU и передавать в существующий софт из и-магазина тоже через SKU.
Собирает отклики, и для тех CMS, чьи партнеры откликнулись, начинает изучать логическую структуру данных (проверять честность и компетентность партнеров)

И даже если партнеры cs-cart отписали ему, что в cs-cart, как в Греции, все есть, он конечно проверит...пусть и поверхностно, на уровне логической структуры данных...
Логическая структура данных CMS связи с внешним миром отражена в файле экспорта-импорта.
в файле экспорта-импорта он видит
1) вау! здесь товары, оказывается, существуют разных типов, и изменить тип товара, без изменения его связей, невозможно. Он что, для всех товаров существующих и будущих должен организовать определение типа? навсегда? и следить за его соответствием будущим потребностям?
2) вау! тут связи между товарами формируются в зависимости от местоположения строки в файле.. То есть сбой софта, людей, приведет к краху данных и отследить это программно нельзя и как потом править? руками?
3) вау! тут присутствуют виртуальные SKU... и что делать, если эти чужеродные SKU попадут в его софт? сегодняшний и будущий? править руками? или каждый раз сверку SKU делать по всей базе?
4) вау! а тут связи типа доп.товары, обязательные, требуемые и т.п. отсутствуют вообще и с SKU не работают, да и назначаются только руками

Директор по IT (напомню, у него целый зоопарк разного софта и главное для него - однозначная устойчивая и бесперебойная связь данных внутри этого зверинца, во вторую очередь - подготовить инструмент для Директора по маркетингу) вычеркивает cs-cart из своего списка и переходит изучать предложения партнеров следующей CMS.

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

Тут, на форуме, уже был пост (не помню кто писал), что ЗА ДЕНЬГИ спецы по 1С ОТКАЗАЛИСЬ (сказали-невозможно) сделать интеграцию с данными cs-cart. Ну понятно, что не в криворукости или знании commerceML дело, а либо в неполноте, либо в неоднозначности связи данных. Нехороший звоночек. 1С - это типовой софт, не экзотика. Жаль, не помню кто писал, любопытно на данные взглянуть.

Давайте еще короче.
На основе логической структуры данных - файла экспорта.
* Должна быть однозначность навсегда. Одна строка - один SKU-код. И все данные по SKU - в одной строке экспорта-импорта. Это исключает неоднозначность и уменьшает ошибки приема-передачи данных стороннему софту.
* Должен быть один тип товара, у которого могут быть разные типы связей (участие в вариациях, назначенные доп.товары, назначенные обязательные товары, назначенные рекомендуемые товары, участие в комплектах и т.п.) с другими товарами на основе SKU. Как это обеспечить на логическом уровне? Предложения выше были. Можно продолжить обсуждение. Как реализовать во внутренней архитектуре? Да, тут наверняка есть сложности, но зависит только от Вас и Вашего коллектива. Это - вызов: справитесь или не справитесь?

И еще момент. Маркетологи-продавцы - они же безбашенные. Маркетолог, не генерирующий и не проверяющий каждую неделю новую идею по повышению среднего чека - не продавец. И тут закладываться надо на будущее. Не стоит ограничивать возможность участия SKU в нескольких вариациях. Это несложно заложить сразу. Маркетологу нужны ВСЕ возможные связи товара ОДНОВРЕМЕННО (чтобы отразить их на карточке товара). Нужно заложить возможность покупателю самому конструировать свой комплект товаров. Реализовывать, конечно, поэтапно.

Ну это если совсем-совсем коротко, по верхушкам...
Я ответил на Ваш вопрос?