Небольшой опрос про miniShop

Начал разработку miniShop 2, в связи с эти есть несколько вопросов.

Кто-нибудь пользуется несколькими складами? Нужны ли они, вообще?
Кто-нибудь пользуется наборами товаров?
Кто-нибудь пользуется учётом остатков?
Нужна ли отдельная работа с производителями товаров, чтобы устраивать по ним выборки и сортировки?

Прошу давать ответы просто по цифрам, "да" или "нет".

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

Скрипт миграции со старой версию на новую - будет.

Личный блог

31 комментарий

Алексей

28.12.2012, 12:54:35

1. Нет, не самая важная фича.

2. Да, комплекты товаров часто встречаются в мире интернет магазинов

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

4. Да, нужна.

p.s. А какие планы по характеристикам товара? Очень интересен этот момент! Как это будет выглядеть!

Василий Наумкин

28.12.2012, 13:34:56

Когда будет что рассказать — расскажу.

Добряков Алексей

28.12.2012, 13:08:36

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

Василий Наумкин

28.12.2012, 13:34:26

Да, miniShop не нужен, каждый сам пусть себе делает магаз на MODX.

Гибче некуда.

Добряков Алексей

28.12.2012, 13:37:58

Я бы с радостью клиенты сво… платить не хотят за такие эксклюзивы :) А мне очень нравиться miniShop спасибо тебе огромное проект завершу один свой который уже 3 месяца делаю очень крупный тебя поблагодарю денежкой, потому что ты реальный мужик с мозгами

Виталий Киреев

28.12.2012, 14:51:11

Пока ставил только больше для изучения магазина, и ничего из перечисленного не использовал, но думаю все это нужно. Главное, чтобы каждый этот пункт можно было отключить в настройках и забыть про их существование. Например, я писал свое обращение к процессору на создание товара, и оказалось, что обязательно перечислять кучу обязательных полей: тот же номер склада и тому подобное. И пришлось выпиливать лишнее комментированием Extjs-ного кода :)

Мордынский Николай

28.12.2012, 15:18:46

1 Нет

2 Да

3 Да (но если товар с 1 карточкой описания имет разные признаки, к примеру цвет или какие другие незначительные отличия влияющие не на цену, а на учет по складу это уже разные артикулы и разные остатки и приходится костылить — к примеру те же остатки и артикулы у 1 карточки хранить в JSON массиве и соответсвенно дописывать костыли)

4 Да (опять же у 1 и того же товара может быть разный производитель, но при этом нужна 1 карточка товара)

К чему я пишу везде что 1 карточка)) потому что веду магазин зоотоваров на 1 С битриксе)) есть очень большая проблема--- дохрена наименований около 20 тысчь(у 1 корма может быть до 6 видов упаковки посетители за голову хватаются когда в этом ворохе каталогов начинают, что то искать)

По ощущениям для каждого товара нужна под таблица

К примеру корм

артикул, остаток, вес, еще что то, еще что то

артикул, остаток, вес, еще что то, еще что то

Или одежда

Футболка

артикул,  размер, цвет, рисунок на ней

артикул,  размер, цвет, рисунок на ней

артикул,  размер, цвет, рисунок на ней

Есть параметры которые не запихнешь в набор (как это было показано у вас в примере), а любая мелочь по которой различаются предметы может влиять на учет по складу — артикулы остатки (по этому в таких случаях стандартные поля остаток и артикул становятся бесполезными и работа сними невозможна и приходится писать велосипеды).

Опять же повторюсь было бы шикарно если бы у товара был конфигуратор свойств на подобии MIGXdb.

Иван Климчук

28.12.2012, 16:32:41

Все пишут, о том, что нужно и что нет, причем каждый столкнулся со своей проблемой. Что-то отключить, что-то изменить. По хорошему, если планируется развивать проект дальше и делать его реально крутым, то я бы задумался о том, чтобы сделать своеобразное API компонента. Т.е. чтобы не костыли вставлять, а гибко использовать возможности miniShop. Кода тут может и не много писать нужно, но главное грамотно спроектировать такое апи.

По пунктам из опыта:

1. Особо не использовалось (актуально для очень больших магазинов)

2 и 3. Нужно иногда

4. Бренды (или производители) нужны, но возможно скорее как доп. параметр, с возможностью по ней фильтровать.

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

Жуковский Антон

28.12.2012, 17:01:55

1. Да

2. Нет, но планируется.

3. Да. Очень хочется учет с учетом характеристик товара (черных маек размера L 5 шт., черных маек размера XL 10 шт. и т.д.).

4. Да

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

Andrei Kilin

28.12.2012, 17:15:17

1. Несколько складов — да. Есть хотелка даже, чтобы у каждого склада был свой счет.

2. Пока нет, но в планах было.

3. Да.

4. Нет, но, думаю, может пригодится.

Антон Слободчук

28.12.2012, 19:02:41

1. нет, т.к. текущая реализация не подходит, но этот функционал очень важен.

2. да

3. да

4. да

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

Перетягин Илья

29.12.2012, 04:51:32

1. Да.

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

2. Да.

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

3. Да.

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

4. Да.

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

Как бы это не звучало, но чем больше возможностей идет в базовом пакете, тем лучше.

Есть фирма которая делает магазин для joomla уже много лет, думаю они понабивали шишки себе в этой сфере, почему бы не подглядеть их функционал. virtuemart.net/home/demo

Владимир Булгаков

29.12.2012, 17:33:09

1. Да

2. Да

3. Да

4, Да

Abu

31.12.2012, 18:23:48

1.нет 2.нет 3.да 4.да (из небольшого личного опыта).

Василий, нет желания писать магазин в виде продолжения уроков для новичков? Сложный проект конечно, и с нуля, нужны знания php, да и с нами чайниками затянется, но с другой стороны будет более-менее понимающее сообщество, документация, опять же на наши вопросы меньше отвечать. С наступающим и желаю Вам еще больше энергии в будущем году!)

Василий Наумкин

31.12.2012, 18:55:03

Нет, такого желания нет.

Алексей

02.01.2013, 08:04:58

1,2 — нет.

3, 4 — да

склады собственноручно вырезаю каждый раз из админки, ровно как и наборы товаров.

Чего-бы очень очень хотелось: создание товара за меньшее кол-во кликов. (к примеру вместо «сохранить и закрыть» — просто кнопка «далее»)

Prizrak Pro

09.01.2013, 23:41:11

1 - нет 2,3,4 - да

Давно хотел написать. Все с регистрацией проблемы были.

Я хотел предложить отказаться от такого количества стандартных полей. Лично все описания товаров пишу в созданных TV. Ну оставить нужны для работы компонента. Цена, производитель.

А вес, описания. Да мне проще даже картинки через TV. Тот же вес не всегда значим. Габариты. Когда то нужны по отдельности а когда пишут через X. Производитель, да. Но я использовал и для сортировки. Поле производитель в TV использовал для тегов.

Вообщем я к той мысли.Что для упрощения магазину, предлагаю как можно больше использоваться стандартные решения платформы. Но только не во вред производительности. Это главное.

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

Удобное сравнение товаров.

Возможность выборки товаров по всевозможным характеристикам. По цвету, производителю, стилю. (например каких то заданных TV)

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

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

Хотелось много сказать. Может где то и повторился.

Василий Наумкин

09.01.2013, 23:50:10

Посмотри в сторону Shopkeeper - там как раз всё на ТВ сделано.

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

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

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

К тому же, если я знаю, какие у меня есть поля, и за что они отвечают - я могу строить гораздо более быстрые выборки из БД. Это тоже важно.

Спасибо за комментарий!

Prizrak Pro

10.01.2013, 00:18:16

У меня 2 магазина на minishop. Он мне нравиться. Не мне проще под тебя подстроиться, и самому допилить, что мне нужно.

Но я тебя понял. Хотя разные магазины и требования разные сложно подвсех подстроиться.

Тогда надеюсь возможность останется как и сейчас. Чего не хватает в TV загонять. С одно стороны стандартно с другой все, что не хватает сам доделал. Импорт можно делать и в стандарте пол и TV. Тоже возможность потрясающая.

Ещё тогда предложение, сделать каждое поле отдельным классом, на основе единого интерфейса. Методы и определяют поведение поля. Что бы дописывать свои поля было легко, с определенным функционалом. И БД расширять. Это прикидка конечно, как вы делаете не знаю. Но идея, что бы легко читать код было и допиливать.

Василий Наумкин

10.01.2013, 00:32:52

Каждое поле отдельным классом - это будет большой тормоз.

Нет, будет как и раньше, отдельная таблица, но гораздо лучше связанная с основной. Много интересного будет, ведь всё на CRC.

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

То есть, можно будет писать просто не парясь:

if ($product = $modx->getObject('msProduct', 15)) {
    $price = $product->get(array('pagetitle','price'));
}

И цена выберется из дополнительной таблицы, а название - из основной.

Prizrak Pro

10.01.2013, 00:31:34

Вообще мне minishop и первый очень нравиться. Вот когда все ладно в программе(ну ты то конечно знаешь где косячки). Прям приятно работать с ней. Мне правда и modx так же нравиться.

Думаю сделаю сайт на yii (обычный). А потом понимаю зачем, и тут все есть.

Извиняюсь, что на комментарий не ответил. Спешил)

Василий Наумкин

10.01.2013, 00:34:41

Для первого большого компонента miniShop неплохой.

Но после Tickets про него и говорить как-то неловко, столько там косяков! Даже связей между объектами нет, имена таблиц в разных регистрах, гора E_NOTICE и т.д.

В общем, давно пора переделать "как надо"!

Мордынский Николай

08.01.2014, 14:50:13

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

Василий Наумкин

09.01.2014, 13:32:11

В первом MS управление было в отдельной странице - там можно было сделать склады и это тащило за собой кучу проблем. В новой версии всё управление товаров находится в ресурсах MODX, поэтому разделять их можно контекстами, или просто по директориям (по уникальному полю, по ТВ).

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

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

Я всем говорю, что зная PHP и применив фантазию, на MS2 можно написать практически любой магазин - и это правда.

Мордынский Николай

09.01.2014, 18:19:47

Спасибо идею понял. Кстати Василий по поводу опций - размеров цветов и всякой хрени связанной с отстками. Спрашивал у нашего менеджера который занимается товарооборотом по магазину. Так вот оказывается любое изменение в наименовании товара цвет или еще чтонибудь - озгначает что у него совершенно другой штрих код поставщика - то есть как некрути если есть 10 одинаковых футболок разного цвета то по складу их надо вводить как 10 разных товаров. Это решает все заморочки впринципе с остатками - то есть опции как таковые привязанные к 1 товару это удобно - но состороны товарооборота изврат )) Так что старая схема складов из mnishop была правильная. __________________________________________________________ Думаю просто создать отдельную таблицу складов где буду хранить id товара и остатки по каждому складу и все.

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

Василий Наумкин

09.01.2014, 21:10:09

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

Отдельную табличку создать - да, хороший вариант.

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

Дмитрий Ломакин

08.01.2014, 19:31:41

А вот вопрос есть: те кто имеют магазин на минишопе2 какой ассортимент товаров? вариант 1 : до 100товаров вариант 2 : до 500товаров вариант 3 : до 1500товаров вариант 4 : больше 1500товаров

цифры Интересны вместе с инфой вариант А - в продакшене вариант Б - в разработке

PS вопрос топику не противоречит, ибо функционал требуемый с ассортиментом хорошо кореллируется

Мордынский Николай

09.01.2014, 04:06:37

есть 1 магазин в работе на 200+ наименований товар специфический нагрузка небольшая работает шустро. inkubator.su Сейчас курю проблемму перевода магазина с 50 000 наименований - надеюсь будет быстрее чем 1 с битрикс)))

Чикин Артур

08.01.2014, 19:42:40

Зачем вы подымаете старые темы? Годичной давности! >Мордынский Николай для minishop2 есть msklad.

Дмитрий Ломакин Хочешь провести опрос создай топик в вопросах! Не апайте старые темы.

Мордынский Николай

09.01.2014, 04:03:33

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

Если да то стоит купить, а если это прокладка между тем чего нет и 1 с то это пустышка за 1500 р