Характеристики, свойства, варианты товаров - решение системной проблемы

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

К чему это приводит, пара показательных (почти) примеров:

Пример раз

http://bimbomoda.com.ua/shop/product/briuki-dlia-malchika-bagigi + http://bimbomoda.com.ua/shop/product/briuki-na-malchika-rosso-marine-bagigi

Сравните описания и количество лишнего ручного труда. А если где то ошибку исправить? А если таких штанишек одной модели было бы с десяток разных цветов? Сколько человекочасов (денег!) уйдет чтобы добавить с сотню таких моделей хотя бы по 5 цветов и в 3-х размерах?

А это не мало: 5*3*100 = 1500 позиций физической номенклатуры.

Конечно карточек товара получится в 3 раза меньше - 500, но их могло быть всего 100. Разница в 5 раз! То есть работу которую мой сотрудник может сделать за понедельник, он будет делать всю рабочую неделю. Повезет если при клонировании описаний не будет сделано ошибок... Еще одного человека на зарплату брать? 0_о Это к вопросу об эффективности бэкэнда подобной конструкции. Автоматизированная система должна автоматизировать ручной труд, а не добавлять его. Тем более в таких объемах.

Пример два

http://sportelement.com.ua/shop/category/proteiny/kompleksnye-proteiny

Обратите внимание сколько одинаковых продуктов по своим свойствам отличающихся только весом упаковки. Со стороны НОВОГО покупателя, который 3 секунды назад вылез из гугла после 2-х часов поиска, в полночь, с красными глазами, такое представление явно излишне и заставляет напрягать зрение в поисках подходящей банки. Пролистает он еще на пару страниц и пойдет искать где попроще или спать пойдет наконец...

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

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

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

Просматривая всевозможные варианты основы ИМ (движки, фреймворки и т.п.), в том числе малоизвестные западные, но с длинной историей и мощным портфолио, заметил вещь о которой сказано выше (про цвет и размер) плюс еще одну - данные учета или номенклатура товаров так или иначе отделены от представления которое выводится пользователю.  Мало того,  в ЗФ серьезных поставщиков, всегда присутствуют две этих колонки size и color.

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

одежда http://www.backcountry.com/patagonia-buckshot-flannel-shirt-long-sleeve-mens

лыжи http://www.backcountry.com/voile-charger-telemark-ski

рюкзаки http://www.telemark-pyrenees.com/en/lowealpinetfxkongur6575-p-76725.html

даже наши додумались (наверняка кастомная разработка ИМ потому что из рускоязычных это еще никтоне реализовал до сих пор в стандартном варианте) http://www.alpindustria.ru/catalog/snowboards/doski/1208/prod206398/

Что мы видим "снаружи" во вронтэнде как покупатель? Как минимум:

1. Много реально отличающихся товаров (назовем их "модель") на одной странице - больше выбор, проще ориентироваться, легко сравнивать.

2. Конкретный товар, который мы можем сконфигурировать под свои нужды выбрав цвет/размер.

3. Видим физическое наличие конкретной позиции номенклатуры.

Что имеем "внутри", в бэкэнде, как продавец?

1. Меньше карточек товара + меньше ресурсов для сопровождения единицы = меньше затраты на деятельность.

2. Данные учета позволяют использовать более гибкий подход к доработке ИМ под собственные нужды или для развития дистрибутива. Ведь к конкретной позиции, при необходимости можно привязать все индивидуально определенные свойства которые важны. Например, самое очевидное:

- вес и габариты, для выбора способа и определения стоимости доставки;

- оперативно владеем информацией об остатках на складах и в торговых точках по каждой номенклатурной позиции даже в ИМ

- проще синхронизировать с учетной системой

- имеем возможность назначить несколько типов цен в разных валютах и определить их для конкретной позиции

- мощные возможности дляч аналитики прямо в интерфейсе ИМ

3. Карточка "модели" товара объединяет в себе несколько номенклатурных позиций с общим описанием. Своего рода глубого кастомизированый шаблон. Это нам дает в 2-3 раза, а то и более меньше текста, меньше шансов ошибки, больше фоксировки покупателя на конкретном товаре облегчая ему выбор и дальнейшую покупку...

Каталог или представление товаров для фронтэнда в админке у вас сделано на отлично, характеристики для категорий и все такое... Очень здорово. Идея с фотографиями для вариантов товара заслуживает медали. Эти две вещи лучше не трогать.

Как это видится...

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

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

Вот.

Есть модель/образец БД в которой все это рассовано по таблицам и расписано по связям. Если найду и откопаю, могу поделиться для препарации/модернизации при необходимости.

Примеры текущих проблем которые можно решить при помощи этого подхода:

1 человеку нужен SKU (а потом захотят EAN,UPC, ISBN и т.п.) http://idea.imagecms.net/topic/289534-dobavit-vnutrennij-nomer-tovara/

2. в некоторых случая удалять карточку не обязательно, достаточно привязать друге номенклатурные позиции http://idea.imagecms.net/topic/289377-pri-udalenii-tovara-predlagat-sozdanie-redirekta/ + http://idea.imagecms.net/topic/156038-status-ustarevshij-tovar/

3. фильтры строго по потребительским свойствам (общим полям карточки) или по свойствам номенклатурной позиции (индивидуальные свойства) http://idea.imagecms.net/topic/159748-moschnaya-sistema-fasetnoj-navigatsii/

4. классика жанра =) http://idea.imagecms.net/topic/194247-dobavit-svojstva-tovara-v-variantyi-tovara/

5. Идея очень здравая, но чтобы не перегрузило всю систему применять только к карточкам в каталоге, а не к позициям в номенклатуре, http://idea.imagecms.net/topic/154040-sozdat-gruppyi-svojstv/

6. Речь про индивидуально определенное свойство конкретной позиции номенклатуры а не про карточку товара и его описание http://idea.imagecms.net/topic/159303-pole-valyuta-v-importe-eksporte/

7. Еще немного классики http://idea.imagecms.net/topic/156805-sortirovka-tovara-po-kolichestvu-v-nalichie/

 и еще http://idea.imagecms.net/topic/157891-gruppirovka-variantov-tovara/

еще http://idea.imagecms.net/topic/151932-modifitsiruemyij-tovar/

8. Наценка касается физического товара, позиции номенклатуры а не описания в каталоге http://idea.imagecms.net/topic/155963-natsenka-na-tovar/

сюда же http://idea.imagecms.net/topic/137745-nuzhna-vozmozhnost-rabotyi-s-izmenyaemyimi-tsenami/

9. Связка возможна! http://idea.imagecms.net/topic/152502-staraya-tsena-i-variantyi/ но только для позиции номенклатуры...

10. к вопросу управления запасами http://idea.imagecms.net/topic/148873-tovar-pod-zakaz/

11. только вес надо откуда то взять, а если у разных вариантов он разный? http://idea.imagecms.net/topic/148449-raschet-stoimosti-dostavki/ Надо брать вес позиции номенклатуры, верно? Покупают не карточку, а физческий товар, карточка просто продает...

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

Благодарю, что дочитали до конца.