13/01/2013
Цитата:
В то время как все движки от самого сложного до самого простого работают именно по такому принципу 1 карточка = 1 товар.
В то время как все движки от самого сложного до самого простого работают именно по такому принципу 1 карточка = 1 товар.
Не так. В одной карточке может быть много товаров.
Футболка "Флора" желтая 28разм. - 600 руб
Футболка "Флора" желтая 32разм. - 650 руб
Футболка "Флора" белая 32разм. - 700 руб
И учет должен вестись по каждому артикулу.
13/01/2013
Ну, хорошо пусть так. Всё равно можно выбирать 1 товар = 1 карточке или нет. Не совсем понятно какое ноу-хау предлагает топик стартёр. lisa, вы понимаете?
13/01/2013
Смутно ) На нашем уровне технической поддержки SLA Премиум+ проблема не в том как что-то сделать программно, а в том что бы придумать и найти что-то, что повысит продажи и чего пока нет у Озона )
13/01/2013
qualified:
Не совсем понятно какое ноу-хау предлагает топик стартёр.
Не совсем понятно какое ноу-хау предлагает топик стартёр.
У нас с самого начала, в самом первом магазине, в одной карточке товаров можно было выбирать товары того же артикула, но разных размеров и цветов (или других разных атрибутов).
Т.е. к каждому артикулу прикрепляется как бы прайс-лист на товары, отличающиеся такими атрибутами как размеры, цвет и т.п.
При этом атрибуты товаров хранятся отдельно, из них формируются карточки. Делали и комплекты, а также добавляли к товарам подарки.
Действительно не очень понятно, что хотелось бы улучшить ТС, в чем, собственно, проблема...
13/01/2013
qualified:
Поэтому я подумал, что таким образом вы хотите сократить количество карточек товара.
Поэтому я подумал, что таким образом вы хотите сократить количество карточек товара.
С чего вы взяли?
Никакого ноу-хау. По трехлетним наблюдениям видно что все более-менее активные разработки, так или иначе, двигаются именно в эту сторону. Только пути какие-то окольные.
Описание товара само по себе для бухгалтерии и целей учета никакой роли не играет. Так же как и сухие значения номенклатуры для покупателя. Это данные для разных целей.
Не знаю как у кого, а у меня есть и заказные формы и регулярно обновляемый оперативный сток. При том количестве поставщков с которым я работаю в 80% случаев под конкретный заказ покупателя, актуализация каталога несоразмерна затратна. При том, что работа по актуализации ведется в основном не по описательным параметрам важным для потребителя а именно по данным для учета - цена, кол-во и т.д. При разделении этих данных однажды созданная карточка товара будет существовать без серьезных изменений даже если сток поменяется 100 раз, а пакетная обработка/импорт стока и ЗФ в систему при разделени данных реализуются значительно проще.
Автоматизация должна автоматизировать а не добавлять ручной работы.
13/01/2013
Пример типичной ЗФ
Колонки:
Пример записей в ЗФ
Это одна модель карабина ( http://www.petzl.com/us/outdoor/vertica ... rs/william ), только с разными вариантами замка и цвета анодировки.
Параметр "вариант замка":
- SCREW-LOCK
- BALL-LOCK
- TRIACT-LOCK
Параметр: "цвет анодировки":
- стандартный
- черный
Покупатель в единственной карточке товара выбирает соответствующее значение этих параметров и получает конкретный артикул/товар по матрице.
Карточка одна, реальных товаров 5. Как хочешь так и верти. Можно сделать две карточки поделив замки на группы - автоматическая/ручная муфта. Т.е. на SCREW-LOCK и BALL/TRIACT-LOCK, получим 3 товара в одной и 2 в другой. Номеклатура при этом как была так и останется без изменений.
Привязка артикулов к параметрам осуществляется в виде массивов. то есть:
- для значения параметра "SCREW-LOCK" указываем соответствие артикулам (реальные товары обладающие этим свойством) M36 SL и M36 SLN для "TRIACT-LOCK" - M36 TL и M36 TLN
- для значения параметра "черный" указываем соответствие артикулам M36 SLN и M36 TLN
и т.д.
Получаем два массива (по числу параметров):
Параметр "вариант замка"
Порядок выбора может быть произвольным если предусмотреть возможность фиксации значения параметра (например чекбоксом с подписью "выбор сделан"). Или же жестко задать последовательность выбора с возможностью сброса, но, что программисту хорошо, то для покупателя не всегда удобно.
При смене значения любого из параметра должна проводиться фильтрация вариантов в остальных списках значений. При выборе значения параметра мы получаем массив второго уровня которым проходимся по элементам массива других параметров.
Например, делаем пересечение $вариант_замка->SCREW-LOCK с каждым элементом массива (отдельной операцией) "цвет анодировки" - в результате нехитрых дополнительных операций у на останется по одному элементу в массиве второго уровня другого параметра.
Это просто пример, конкретная реализация может быть любой если дает результат.
Сочетаний параметров влияющих на финансовые показатели (цена, стоимость доставки от веса артикула), для обычных товаров исключительно редко бывает больше трех. Например, страховочные системы для альпинизма на базе одной модели могут быть разного цвета, размера и иметь особенный вариант, например с "фастами", так же в разных размерах и цвете. Можно нагородить четыре параметра объединив с товаром на базе этой же модели, больше не требуется.
Добавить еще проверки на недопустимые сочетания и пожалуй достаточно. Реализовать это совсем не сложно. Просто другой подход.
Имея схему логики которая разделяет данные и описание можно много чего делать значительно проще и более гибко - импорт/экспорт, акутализация и отображение остатков магазине, у поставщика, операции с ценами, типами цен и т.д. Не трогая описательные данные, важные для потребителя на которые было потрачено изрядное количество времени. В сумме трудозатрат, наполнение ИМ по такой схеме становится более эффективным.
Номенклатура в БД по образу сток листов и ЗФ это всего лишь абстракция, точка контакта к которой привязан как реальный товар с точки зрения розничного продавца, оптовика и производителя так и сумма потребительских свойств, с точки зрения покупателя. Если говорить образно - общий язык или термины на которых все стороны общаются.
Извращаться с карточкой и деревом модифицирующих параметров, которые зачастую объединены с описательными характеристиками для того чтобы добавлять реальные товары - это тупиковый путь к полной потере гибкости. Это этого уже уходят и будут уходить.
Колонки:
- Название
- MPN (Код/артикул производителя)
- Цвет
- Размер
- Опт
- Розница
Пример записей в ЗФ
- WILLIAM SCREW-LOCK / M36 SL // 790
- WILLIAM SCREW-LOCK black / M36 SLN / чёрный // 880
- WILLIAM BALL-LOCK / M36 BL // 990
- WILLIAM TRIACT-LOCK / M36 TL // 990
- WILLIAM TRIACT-LOCK black / M36 TLN / чёрный 1 120
Это одна модель карабина ( http://www.petzl.com/us/outdoor/vertica ... rs/william ), только с разными вариантами замка и цвета анодировки.
Параметр "вариант замка":
- SCREW-LOCK
- BALL-LOCK
- TRIACT-LOCK
Параметр: "цвет анодировки":
- стандартный
- черный
Покупатель в единственной карточке товара выбирает соответствующее значение этих параметров и получает конкретный артикул/товар по матрице.
Карточка одна, реальных товаров 5. Как хочешь так и верти. Можно сделать две карточки поделив замки на группы - автоматическая/ручная муфта. Т.е. на SCREW-LOCK и BALL/TRIACT-LOCK, получим 3 товара в одной и 2 в другой. Номеклатура при этом как была так и останется без изменений.
Привязка артикулов к параметрам осуществляется в виде массивов. то есть:
- для значения параметра "SCREW-LOCK" указываем соответствие артикулам (реальные товары обладающие этим свойством) M36 SL и M36 SLN для "TRIACT-LOCK" - M36 TL и M36 TLN
- для значения параметра "черный" указываем соответствие артикулам M36 SLN и M36 TLN
и т.д.
Получаем два массива (по числу параметров):
Параметр "вариант замка"
- SCREW-LOCK
- M36 SL
- M36 SLN
- M36 SL
- TRIACT-LOCK
- M36 TL
- M36 TLN
- M36 TL
- стандартная
- M36 SL
- M36 TL
- M36 SL
- черная
- M36 SLN
- M36 TLN
- M36 SLN
Порядок выбора может быть произвольным если предусмотреть возможность фиксации значения параметра (например чекбоксом с подписью "выбор сделан"). Или же жестко задать последовательность выбора с возможностью сброса, но, что программисту хорошо, то для покупателя не всегда удобно.
При смене значения любого из параметра должна проводиться фильтрация вариантов в остальных списках значений. При выборе значения параметра мы получаем массив второго уровня которым проходимся по элементам массива других параметров.
Например, делаем пересечение $вариант_замка->SCREW-LOCK с каждым элементом массива (отдельной операцией) "цвет анодировки" - в результате нехитрых дополнительных операций у на останется по одному элементу в массиве второго уровня другого параметра.
Это просто пример, конкретная реализация может быть любой если дает результат.
Сочетаний параметров влияющих на финансовые показатели (цена, стоимость доставки от веса артикула), для обычных товаров исключительно редко бывает больше трех. Например, страховочные системы для альпинизма на базе одной модели могут быть разного цвета, размера и иметь особенный вариант, например с "фастами", так же в разных размерах и цвете. Можно нагородить четыре параметра объединив с товаром на базе этой же модели, больше не требуется.
Добавить еще проверки на недопустимые сочетания и пожалуй достаточно. Реализовать это совсем не сложно. Просто другой подход.
Имея схему логики которая разделяет данные и описание можно много чего делать значительно проще и более гибко - импорт/экспорт, акутализация и отображение остатков магазине, у поставщика, операции с ценами, типами цен и т.д. Не трогая описательные данные, важные для потребителя на которые было потрачено изрядное количество времени. В сумме трудозатрат, наполнение ИМ по такой схеме становится более эффективным.
Номенклатура в БД по образу сток листов и ЗФ это всего лишь абстракция, точка контакта к которой привязан как реальный товар с точки зрения розничного продавца, оптовика и производителя так и сумма потребительских свойств, с точки зрения покупателя. Если говорить образно - общий язык или термины на которых все стороны общаются.
Извращаться с карточкой и деревом модифицирующих параметров, которые зачастую объединены с описательными характеристиками для того чтобы добавлять реальные товары - это тупиковый путь к полной потере гибкости. Это этого уже уходят и будут уходить.
22/01/2013
qualified:
Кстати в другой теме вы раскритиковали OpenCart, а как вам такой магазинчик (не мой) на OpenCart: http://grantmall.ru/
По моему очень даже ничего.
Кстати в другой теме вы раскритиковали OpenCart, а как вам такой магазинчик (не мой) на OpenCart: http://grantmall.ru/
По моему очень даже ничего.
Не идеал, конечно, но ничего...
А есть опыт работы с OpenCart?
22/01/2013
Xel:
Да это даквным-давно известный ход - все коробочные версии любого ПО живут за счет саппорта дописывания и допиливания. Сама по себе версия стоит довольно недорого, а вот разнообразный допил и настройка - золотое дно для любой софтверной компании. Бизнес такой.
Да это даквным-давно известный ход - все коробочные версии любого ПО живут за счет саппорта дописывания и допиливания. Сама по себе версия стоит довольно недорого, а вот разнообразный допил и настройка - золотое дно для любой софтверной компании. Бизнес такой.
То есть, старый давний способ аферистов (лохотронщиков) сыграть простой и понятной человеческой "жабе" и раздеть клиента (лоха) по полной программе...
Поэтому даже не рассматриваю варианты:
- откровенно дешёвые варианты;
- когда ИМ берётся в аренду и тому подобные сервисы с помесячной абонентской платой;
- коробочный продукты, которые в исходнике (пусть отдельными докупаемыми блоками) не имеют всего нужного функционала.
Xel:
Преста - откровенно впечатляет и радует.
Преста - откровенно впечатляет и радует.
А можно подробнее, в свете моей предыдущей реплики?
22/01/2013
learn and learn:
- когда ИМ берётся в аренду и тому подобные сервисы с помесячной абонентской платой;
- когда ИМ берётся в аренду и тому подобные сервисы с помесячной абонентской платой;
Заступлюсь за этот вариант.
Лохотронщики тут совершенно ни причем. Сервисы SAAS, к которым можно отнести и аренду ПО интернет-магазина, широко распространены. Они позволяют экономить не только на открытии проекта, но и на его сопровождении.
Причем не все себе представляют, сколько именно экономить - содержание собственной ИТ-команды, способной надежно сопровождать сложный проект, чрезвычайно затратно.
Сейчас очень большая проблема именно с ИТ-кадрами. С другой стороны, SAAS-сервисы изолируют предпринимателя от этой проблемы. Да, это стоит денег, а как еще?
22/01/2013
Xel:
Т.е. нет демонстрационой версии - даже время не буду тратить на переписку и выяснение нюансов.
Т.е. нет демонстрационой версии - даже время не буду тратить на переписку и выяснение нюансов.
Полностью с Вами согласен!
Больше всего мне "нравится", когда выкладываешь на фриланце проект и в обязательных условиях указываю ссылки на реализованные проекты в разрезе стоимости - в ответ только стандартные предложения к диалогу и ссылки на портфолио. А в портфолио - скрины от сайтов - без ссылок.
Назовите Ваши реализованные проекты с ценником - все всегда уходят от разговора - всё, для меня диалог закончен. мы же, владельцы ИМ, сразу выкладываем цену за чайник или табуретку на своём сайте. Представьте, если бы для выяснения цены чайника нужно было бы вступать в длительный диалог.
22/01/2013
learn and learn:
мы же, владельцы ИМ, сразу выкладываем цену за чайник или табуретку на своём сайте. Представьте, если бы для выяснения цены чайника нужно было бы вступать в длительный диалог.
мы же, владельцы ИМ, сразу выкладываем цену за чайник или табуретку на своём сайте. Представьте, если бы для выяснения цены чайника нужно было бы вступать в длительный диалог.
Вы путаете цену на товар и цену на услуги.
22/01/2013
Александр Фролов:
Заступлюсь за этот вариант.
Заступлюсь за этот вариант.
Заступайтесь, только не словами, а рублём: вот я открываю на подобном сайте свой ИМ, вкладываю в его раскрутку и развитие время, средства, силы, душу... Вы готовы гарантировать возмещение затрат в случае прекращения действия (по любой причине) Вашего сервиса? Если да, то что Вы выдвинете в качестве материального гаранта? Уставной капитал ООО? Или всем своим (личным) имуществом? Если получу положительный ответ на все мои вопросы и дальнейшее документальное подтверждение - то я готов к диалогу.
22/01/2013
alive:
Вы путаете цену на товар и цену на услуги.
Вы путаете цену на товар и цену на услуги.
Услуга - тот же товар, предназначенный к реализации. К примеру, на моём действующем сайте (он меня абсолютно не устраивает технически, поэтому ищу подрядчика для его нового создания) клиенту сразу известна цена товара самовывозом (без УСЛУГ) и цена товара, в которую уже включена УСЛУГА по его доставке.
Ваши доводы несостоятельны.
И изматывать себя переговорами с тем, кто сразу не предлагает варианты своих работ в разрезе цены (хотя бы стартовой) - самая большая глупость покупателя этих услуг.
Даже Равшаны и Джуншуты носят с собой альбомчик с фотографиями своих работ по ремонту и озвучивают цены на свои УСЛУГИ.
Так что: "путате" Вы и путаете добропорядочного покупателя с клиентом напёрсточного сервиса.
22/01/2013
Александр Фролов:
Xel :
я хочу попробовать сама, без общения с менеджерами, посмотреть изнутри при чем - не выходя из дома.
Да, я понимаю, что в каком-то виде демонстрационная версия все же позволит привлечь дополнительных клиентов, но с этим не все так просто...
Xel :
я хочу попробовать сама, без общения с менеджерами, посмотреть изнутри при чем - не выходя из дома.
Да, я понимаю, что в каком-то виде демонстрационная версия все же позволит привлечь дополнительных клиентов, но с этим не все так просто...
Да всё проще паренной репы: дайте ссылку на уже действующий ИМ в разрезе цен. Можете цены, если это уж такая военная тайна - кидать в личку.
А хозяева ИМ, думаю, будут только рады лишнему посетителю и лишнему упоминанию их ЮРЛа на страницах столь уважаемого форума.
22/01/2013
Александр Фролов:
Открытые исходники сами по себе не дадут результата, необходимо постоянное сопровождение со стороны ИТ-специалистов.
А если исходники "обросли" большим количеством доработок, то сопровождение этих доработок превращается в проблему. Особенно если их делали разные люди и в разное время.
А потом выходит обновление "движка", и может оказаться, что обновленная версия не совместима с доработками. А в старой версии, например, имеются уязвимости и оставаться на ней нельзя.
Наличие тысяч модулей тоже не говорит о том, что среди них найдутся нужные.
Открытые исходники сами по себе не дадут результата, необходимо постоянное сопровождение со стороны ИТ-специалистов.
А если исходники "обросли" большим количеством доработок, то сопровождение этих доработок превращается в проблему. Особенно если их делали разные люди и в разное время.
А потом выходит обновление "движка", и может оказаться, что обновленная версия не совместима с доработками. А в старой версии, например, имеются уязвимости и оставаться на ней нельзя.
Наличие тысяч модулей тоже не говорит о том, что среди них найдутся нужные.
Мудрые слова практика.
Полагаю, заказчикам, подбирающим себе варианты, можно смело эти слова в рамочку и на стенку: как краткий курс для начинающего заказчика...
Ответить
Читайте также
22/08/2018
Площадка будет отдавать партнерским сайтам до 80% дохода, полученного от переходов покупателей по ссылкам и виджетам с этих сайтов в интернет-магазины...
Подробнее
21/04/2015
Недавнее совместное исследование Buzzstream и агентства Fractl показало, что эмоциональная вовлеченность клиентов, отзывы в соцсетях и вирусное распространение тесно связаны....
Подробнее
30/05/2012
"Яндекс" запустил контентный API "Яндекс.Маркета", который содержит все характеристики товаров, фотографии, отзывы на модели и магазины, данные о стоимости и наличии товаров, возможность поиска по базе "Яндекс.Маркета"...
Подробнее