+17
Under vurdering

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

Лаврентьев Сергей 11 år siden opdateret af Тимур Тт 10 år siden 17

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


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


Пример раз


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/ Надо брать вес позиции номенклатуры, верно? Покупают не карточку, а физческий товар, карточка просто продает...


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


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

+1

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

Никак не могу от вас отстать, уж больно нравитесь :-\


Вот еще... Смотрите что получается. Поголовно все разработчики пишут в менюшках админки... Каталог,->товары.. Для администратора/менеджера магазина никакие не товары! Это каталог карточек товара. Всего лишь. Товары это позиции номенклатуры.


Если называть вещи своими именами, что исчезнет из карточки товара? С вкладки "продукт" исчезнут пункты касающиеся цены, валюты, артикула, количества - это свойства реального товара. Останется просто карточка товара. Если она заполнена и никому не мешает - меняться не будет 100 лет. Профит статики очевиден.


При наличии справочника номенклатуры (задублируйте каталог "товаров" вместе с деревом характеристик, прикрутите другие карточки вот вам и справочник номенклатуры)


В карточке товара будет достаточно всего одной вкладки на которой можно будет:

а) указать одну или несколько позиций номенклатуры которые будет продавать эта карточка (тривиальный - одна позиция или простой режим вариантов товара 2 и более позиций без матрицы, похоже на то как сейчас, только круче =)

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


С учетной системой синхронизируется только номенклатура! Карточки с описаниями и потребительскими свойствами отдельно или вручную.


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


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


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

50% идей, которые были упомянуты - мои. Предлагаю обсудить и скинуться на доработку, т.к. расширять функционал движка разработчики не планируют. 
Я лучше себе на Spree скинусь... Там есть все что нужно и в том виде который нужен.

Доработка-костыль, это до первого обновления исходного продукта. Уже проходил, больше желания нет.

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

Уже сейчас, движки ИМ без нормального складского учета не особо конкурентны, а дальше будет еще интереснее.
Spree выглядит убого.. вебтринольно, трендово, но функционала там мало :
Видимо вы смотрели какую-то не такую Spree... Даже из коробки, функционала там на систему управления торговлей и складом хватит, не то что на е-магазин. Единственный движок в котором вменяемо и полноценно реализовано управление вариантами товаров.

Для всех остальных плюшек есть таксономия, модули, а кастомную морду на любой магазин заказывать надо если хочешь отличатся.
Я реально хочу в складчину интернет-магазин. Если сброситься на допил, можно получить вдвое больше за те же деньги. Фильтры, варианты, сео, куча прочих плюшек.

Сприи вроде этот, да? http://synergycommerce.ru/opportunities
Демка не показывает всего функционала

Складчина не вариант проект должен принадлежать одному пользователю
Svar
Under vurdering
+1
Замечено небольшое оживление xD Значит не все пропало...

Тут недавно встал вопрос о замене 1С и пришлось узнать и понять много нового применимо к работе с товарами. Основное:
1. Большинство альтернативных решений, а так же базовые версии систем только для бухучета от 1С не умеют работать с учетом по характеристикам (цвет,размер).
2. В ввиду большей гибкости небольших разработчиков учетных систем, добавить нужные поля в карточку товара, за весьма скромные суммы - не проблема, но учет все равно будет вестись по отдельным номенклатурным позициям как и обычно.
3. Отдельные решения для торгового склада имеют очень мощные возможности, но по сути являются избыточными если ИМ не требует такой детализации и дополнительным звеном увеличивающим трудозатраты.

Поэтому, предлагаемое решение на основе простого справочника номенклатуры будет наиболее универсальным. Однако есть пара моментов.

Чтобы не путаться, применяемые термины
  • "характеристики" - физические "параметры" реального товара которые присущи только конкретному наименованию. 
  • "свойства" - описательные, потребительские "признаки" которые могут иметь несколько реальных товаров с разными "характеристиками". Это уже есть в системе.
  • "параметр" - наименование элементов списка "характеристик"
  • "признак" - наименование элементов списка "свойств"

Главное отличие "параметра характеристики" от "признака свойства" в том, что "параметр" - всегда физически измеряемая или отдельно учитываемая в рамках бухучета величина.

Обратное так же верно: "признак свойства" в бухучете не учитывается, физически измерить его возможно далеко не всегда и информация о его значении доступна в 99% случаев по данным производителя.

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

Основные положения относительно справочника номенклатуры:
1. Он должен использовать существующую структуру каталога товаров, то есть позиции на основе которых собирается карточка товара должны находится в той же группе что и карточка товара.
2. Необходим справочник "характеристики" - фактически, функциональный дубль справочника "свойства" но с некоторыми изменениями карточки и применяемый только к дереву номенклатуры. Все замечания по поводу группировки "свойств" ( http://idea.imagecms.net/topic/154040-sozdat-gruppyi-svojstv/ ) так же актуальны и для этого справочника. Потому что у каждого производителя свои тараканы насчет цветов, размеров и прочего. Поэтому нужны отдельные группы которые можно было бы привязать не только к категориям каталога товаров но и к брендам. Иначе будет в списке размеров адское месиво из все систем: российской, европейской, британской, американской...

Еще было бы здорово:
- иметь возможность на основе позиции номенклатуры создавать карточку товара одним кликом, это ускорит и упростит работу даже в случае если есть варианты и этот функционал не перегрузит когда магазин работает с товарами без вариантов.
- если магазин работает ТОЛЬКО с товарами без вариантов предусмотреть настройку номенклатура = карточка товара (или включить этот функционал в премиум версию - только за него реально доплатить разницу и с ощутимым экономическим эффектом)
- указывать в карточке товара, какие параметры номенклатуры являются общими для всех вариантов (возможно по образцу одного из вариантов или традиционно для системы shared=ON/OFF)

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

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

По сути этот плосский список является основой обединяющей:
1. бухучет - имеет значение стоимость ТМЦ (оперирует цифрами)
2. товарный и складской учет - имеет значение сама единица ТМЦ (оперирует физическими и учетными параметрами товара)
3. интернет-магазин - имеет значение представление (оперирует потребительским свойствами)

Очень нужен справочник номенклатуры отделенный от карточек товара как описано в более ранних комментариях. Синхронизация упрощается донельзя. Вести учет проще. Карточки товаров станут логичнее и на их сохдание/сопровождение уйдет ощутимо меньше трудозатрат. Радикально повысится гибкость самой схемы для расширения (доп.свойства, характеристики и т.д.), описание будет отделено от самого предмета что тоже упрощает много сложностей.
Бредовая статья. Если нужно вносить данные - то это сколько нормочасов!!! О Ужжасс!!! А вы хотите, чтобы данные сами по себе внеслись, или чтобы вам даром люди их вбивали?
+5
Да, хочу чтобы данные сами по себе вносились. Иначе зачем тогда нужна автоматизация которая не уменьшает количество ручного труда и затраты на его оплату?
Вопрос не в том что даром, а в том чтобы не делать дурной работы. Данные функционалы давно разработаны и даже вылизаны их только применить к своему движку... И тогда есть шанс что imageCMS будет претендовать на лидерство в движках ИМ
Ребята  абсолютно правы - создавай не один интернет магазин на joomla где компонент joomshoping развит до такой степени что работать одно удовольствие. Проблема только в том что движок не держит большое количество посетителей. Ребята ненужно ничего придумывать возьмите этот компонент и переложите на свой движок. Я один из ваших клиентов зпплативший хорошие деньги за движок. 1с битрикс стоит гораздо дешевле который заточен под ИМ. Хотите конкурировать развивайте функционал. Я надеюсь что вы не будете с этим затягивать так как можете потерять очень много клиентов. 
Вот с возможность выбора цветовой гаммы товара явно не хватает этому движку !  Вполне поддержу.  

Kundesupport af UserEcho