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 - то это, как раз Конструктор комплекта товаров, о котором написал выше.
Если будет движение в сторону этой концепции, то и наличие "комплектуемых" товаров будет известно, и пользователю будет выдаваться предложение "поукомплектовать" свой товар из того, что есть в наличии
Резюмирую
Вариации товаров можно обеспечить в рамках существующей идеологии. Чуть откатиться назад и отказаться от отдельного типа данных Вариация. Т.к. все уже было и без него.
Но! так как все идеологические изменения крайне болезненны для пользователей, необходимо прямо сейчас, невзирая на планы запуска и жалобы, определиться с комплектами товаров. Продолжить обсуждение именно комплектов товаров - практика, пожелания, узкие места текущие и возможные, ну и попутно доточить терминологию.
[/url]