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

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

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

  2. Кто-нибудь пользуется наборами товаров?

  3. Кто-нибудь пользуется учётом остатков?

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

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

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

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

← Предыдущая заметка
Совершенно новая CMS от "Фабрики сайтов"
Следующая заметка →
С наступающим, 2013 годом
Комментарии (31)
alexeytulaАлексей
28.12.2012 08:54

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

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

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

4. Да, нужна.

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

bezumkinВасилий Наумкин
28.12.2012 09:34

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

Добряков Алексей
28.12.2012 09:08

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

bezumkinВасилий Наумкин
28.12.2012 09:34

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

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

Добряков Алексей
28.12.2012 09:37

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

argnistВиталий Киреев
28.12.2012 10:51

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

Мордынский Николай
28.12.2012 11:18

1 Нет

2 Да

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

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

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

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

К примеру корм
артикул, остаток, вес, еще что то, еще что то
артикул, остаток, вес, еще что то, еще что то
Или одежда
Футболка
артикул,  размер, цвет, рисунок на ней
артикул,  размер, цвет, рисунок на ней
артикул,  размер, цвет, рисунок на ней

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

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

AlroniksИван Климчук
28.12.2012 12:32

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

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

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

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

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

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

Жуковский Антон
28.12.2012 13:01

1. Да

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

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

4. Да

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

k07nAndrei Kilin
28.12.2012 13:15

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

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

3. Да.

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

Антон Слободчук
28.12.2012 15:02

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

2. да

3. да

4. да

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

OnFoxПеретягин Илья
29.12.2012 00:51

1. Да.

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

2. Да.

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

3. Да.

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

4. Да.

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

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

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

Владимир Булгаков
29.12.2012 13:33

1. Да

2. Да

3. Да

4, Да

RasulAbu
31.12.2012 14:23

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

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

bezumkinВасилий Наумкин
31.12.2012 14:55

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

Алексей
02.01.2013 04:04

1,2 — нет.

3, 4 — да

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

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

Prizrak Pro
09.01.2013 19:41

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

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

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

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

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

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

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

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

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

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

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

bezumkinВасилий Наумкин
09.01.2013 19:50

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

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

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

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

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

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

Prizrak Pro
09.01.2013 20:18

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

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

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

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

bezumkinВасилий Наумкин
09.01.2013 20:32

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

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

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

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

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

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

Prizrak Pro
09.01.2013 20:31

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

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

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

bezumkinВасилий Наумкин
09.01.2013 20:34

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

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

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

Мордынский Николай
08.01.2014 10:50

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

bezumkinВасилий Наумкин
09.01.2014 09:32

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

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

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

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

Мордынский Николай
09.01.2014 14:19

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

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

bezumkinВасилий Наумкин
09.01.2014 17:10

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

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

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

Дмитрий Ломакин
08.01.2014 15:31

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

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

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

Мордынский Николай
09.01.2014 00:06

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

Чикин Артур
08.01.2014 15:42

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

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

Мордынский Николай
09.01.2014 00:03

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

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

Зачем вы подымаете старые темы? Годичной давности! - будим считать что я web геронтофил))

Sindi Bober
09.01.2014 13:17

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

futuris
Futuris
26.03.2024 07:39
Страница отдельного поста заработала сразу в том виде, как ты написал.) А вот в ленте постов контент...
bezumkin
Василий Наумкин
20.03.2024 18:21
Volledig!
Андрей
14.03.2024 10:47
Василий! Как всегда очень круто! Моё почтение!
russelgal
russel gal
09.03.2024 17:17
А этот стоило написать хотя бы затем, чтобы получить комментарий от юзера, который ничего не писал ...
inetlover
Александр Наумов
27.01.2024 00:06
Василий, спасибо! Извини, тупанул.
bezumkin
Василий Наумкин
22.01.2024 04:43
Давай-давай!
bezumkin
Василий Наумкин
24.12.2023 11:26
Спасибо!
bezumkin
Василий Наумкин
27.11.2023 02:43
Ура!
bezumkin
Василий Наумкин
25.11.2023 08:30
Vesp тянет 2 зависимости: vesp-frontent для фронта и vesp-core для бэкенда. Их можно обновлять, но э...
bezumkin
Василий Наумкин
22.11.2023 08:09
Отлично, поздравляю!