Форум
Читайте нас также:

об электронной торговле - для интернет-магазинов и ритейла. портал и сообщество

Форум

Посыл разработчикам ИМ от неблагодарного пользователя



Ссылка на сообщение


Цитата:

В то время как все движки от самого сложного до самого простого работают именно по такому принципу 1 карточка = 1 товар.


Не так. В одной карточке может быть много товаров.
Футболка "Флора" желтая 28разм. - 600 руб
Футболка "Флора" желтая 32разм. - 650 руб
Футболка "Флора" белая 32разм. - 700 руб

И учет должен вестись по каждому артикулу.



Ссылка на сообщение


Ну, хорошо пусть так. Всё равно можно выбирать 1 товар = 1 карточке или нет. Не совсем понятно какое ноу-хау предлагает топик стартёр. lisa, вы понимаете?



Ссылка на сообщение


Смутно ) На нашем уровне технической поддержки SLA Премиум+ проблема не в том как что-то сделать программно, а в том что бы придумать и найти что-то, что повысит продажи и чего пока нет у Озона )



Ссылка на сообщение


qualified:

Не совсем понятно какое ноу-хау предлагает топик стартёр.


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

Т.е. к каждому артикулу прикрепляется как бы прайс-лист на товары, отличающиеся такими атрибутами как размеры, цвет и т.п.

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

Действительно не очень понятно, что хотелось бы улучшить ТС, в чем, собственно, проблема...



Ссылка на сообщение


qualified:

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

С чего вы взяли?

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

Описание товара само по себе для бухгалтерии и целей учета никакой роли не играет. Так же как и сухие значения номенклатуры для покупателя. Это данные для разных целей.

Не знаю как у кого, а у меня есть и заказные формы и регулярно обновляемый оперативный сток. При том количестве поставщков с которым я работаю в 80% случаев под конкретный заказ покупателя, актуализация каталога несоразмерна затратна. При том, что работа по актуализации ведется в основном не по описательным параметрам важным для потребителя а именно по данным для учета - цена, кол-во и т.д. При разделении этих данных однажды созданная карточка товара будет существовать без серьезных изменений даже если сток поменяется 100 раз, а пакетная обработка/импорт стока и ЗФ в систему при разделени данных реализуются значительно проще.

Автоматизация должна автоматизировать а не добавлять ручной работы.



Ссылка на сообщение


Пример типичной ЗФ
Колонки:
  • Название
  • 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
  • TRIACT-LOCK
    • M36 TL
    • M36 TLN
Параметр "цвет анодировки"
  • стандартная
    • M36 SL
    • M36 TL
  • черная
    • M36 SLN
    • M36 TLN

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

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

Например, делаем пересечение $вариант_замка->SCREW-LOCK с каждым элементом массива (отдельной операцией) "цвет анодировки" - в результате нехитрых дополнительных операций у на останется по одному элементу в массиве второго уровня другого параметра.

Это просто пример, конкретная реализация может быть любой если дает результат.

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

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

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

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


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



Ссылка на сообщение


qualified:

Кстати в другой теме вы раскритиковали OpenCart, а как вам такой магазинчик (не мой) на OpenCart: http://grantmall.ru/
По моему очень даже ничего.


Не идеал, конечно, но ничего...
А есть опыт работы с OpenCart?



Ссылка на сообщение


Xel:

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


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

Xel:

Преста - откровенно впечатляет и радует.


А можно подробнее, в свете моей предыдущей реплики?



Ссылка на сообщение


learn and learn:

- когда ИМ берётся в аренду и тому подобные сервисы с помесячной абонентской платой;


Заступлюсь за этот вариант.

Лохотронщики тут совершенно ни причем. Сервисы SAAS, к которым можно отнести и аренду ПО интернет-магазина, широко распространены. Они позволяют экономить не только на открытии проекта, но и на его сопровождении.

Причем не все себе представляют, сколько именно экономить - содержание собственной ИТ-команды, способной надежно сопровождать сложный проект, чрезвычайно затратно.

Сейчас очень большая проблема именно с ИТ-кадрами. С другой стороны, SAAS-сервисы изолируют предпринимателя от этой проблемы. Да, это стоит денег, а как еще?



Ссылка на сообщение


Xel:

Т.е. нет демонстрационой версии - даже время не буду тратить на переписку и выяснение нюансов.


Полностью с Вами согласен!
Больше всего мне "нравится", когда выкладываешь на фриланце проект и в обязательных условиях указываю ссылки на реализованные проекты в разрезе стоимости - в ответ только стандартные предложения к диалогу и ссылки на портфолио. А в портфолио - скрины от сайтов - без ссылок.
Назовите Ваши реализованные проекты с ценником - все всегда уходят от разговора - всё, для меня диалог закончен. мы же, владельцы ИМ, сразу выкладываем цену за чайник или табуретку на своём сайте. Представьте, если бы для выяснения цены чайника нужно было бы вступать в длительный диалог.



Ссылка на сообщение


learn and learn:

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

Вы путаете цену на товар и цену на услуги.



Ссылка на сообщение


Александр Фролов:

Заступлюсь за этот вариант.


Заступайтесь, только не словами, а рублём: вот я открываю на подобном сайте свой ИМ, вкладываю в его раскрутку и развитие время, средства, силы, душу... Вы готовы гарантировать возмещение затрат в случае прекращения действия (по любой причине) Вашего сервиса? Если да, то что Вы выдвинете в качестве материального гаранта? Уставной капитал ООО? Или всем своим (личным) имуществом? Если получу положительный ответ на все мои вопросы и дальнейшее документальное подтверждение - то я готов к диалогу.



Ссылка на сообщение


alive:

Вы путаете цену на товар и цену на услуги.


Услуга - тот же товар, предназначенный к реализации. К примеру, на моём действующем сайте (он меня абсолютно не устраивает технически, поэтому ищу подрядчика для его нового создания) клиенту сразу известна цена товара самовывозом (без УСЛУГ) и цена товара, в которую уже включена УСЛУГА по его доставке.
Ваши доводы несостоятельны.
И изматывать себя переговорами с тем, кто сразу не предлагает варианты своих работ в разрезе цены (хотя бы стартовой) - самая большая глупость покупателя этих услуг.
Даже Равшаны и Джуншуты носят с собой альбомчик с фотографиями своих работ по ремонту и озвучивают цены на свои УСЛУГИ.

Так что: "путате" Вы и путаете добропорядочного покупателя с клиентом напёрсточного сервиса.



Ссылка на сообщение


Александр Фролов:

Xel :
я хочу попробовать сама, без общения с менеджерами, посмотреть изнутри при чем - не выходя из дома.


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


Да всё проще паренной репы: дайте ссылку на уже действующий ИМ в разрезе цен. Можете цены, если это уж такая военная тайна - кидать в личку.
А хозяева ИМ, думаю, будут только рады лишнему посетителю и лишнему упоминанию их ЮРЛа на страницах столь уважаемого форума.



Ссылка на сообщение


Александр Фролов:

Открытые исходники сами по себе не дадут результата, необходимо постоянное сопровождение со стороны ИТ-специалистов.

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

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

Наличие тысяч модулей тоже не говорит о том, что среди них найдутся нужные.


Мудрые слова практика.
Полагаю, заказчикам, подбирающим себе варианты, можно смело эти слова в рамочку и на стенку: как краткий курс для начинающего заказчика...






Ответить


:D
:)
:(
:o
:shock:
:?
8)
:lol:
:x
:P
:oops:
:cry:
:evil:
:twisted:
:roll:
:wink:
:!:
:?:
:idea:
:arrow:
:|
:mrgreen:







2001 - 2018 © Оборот.ру. Все права защищены