Модуль - варианты данных для модели

[Kosteus]

Требуется разработка "Модуль - варианты данных для модели".

От 30 000 р + "25" часов в стуки сопровождение.

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

Исходный код защитить кодировкой.

ТЗ по ссылке https://yadi.sk/i/lTZe7dlNkqKy4

Вопросы здесь или в личку

[sv2109]

тз по ссылки

 

https://yadi.sk/i/lTZe7dlNkqKy4

И у нас есть победитель в конкурсе: "Лучшее ТЗ года" :)

[Blondi]

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

[Kosteus]

SouthBlondi, Сейчас покупатель может положить в корзину Модель (код товара) + значение опции или нескольких опций, фактически с этим справляется модуль "Связанные опции" и вероятно он куда то записывает значение SKU (В настройках модуля есть).

А раз есть это значение SKU то и остатки можно проверять по этому значению и прочие значения присваиваемые модулем "Связанные опции"

[Blondi]

А чем этот вариант не устраивает? 

Вы хотите то, что есть в опциях реализовать как-то иначе? Зачем?

[Kosteus]

Да я хочу проверять и обновлять остатки по значению  SKU

и иметь 1 карточку товара, и более 1 SKU для модели.

[Blondi]

Так в чем проблема это делать в опциях?

[Kosteus]

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

Раз модуль задает это значение SKU1, SkU2... SKUn, значит его можно использовать!

Но модуль связанные опции создает таблицы с ячейками (или как их там кластерами) вида к примеру:

где цвет размер SKU

черный;черный;черный;синий;красный | 44;48;46;48;46 | 5;6;7;3;10 | SKU1, SkU2, SKU3, SKU4, SKU5 |

а надо вид SKU размер цвет :

SKU1;44;5;

SkU2;48;6;

SkU3;46;7

SkU4;48;3

SkU5;46;6

[Kosteus]

Если вы не знаете как это сделать - не говорите что, это не возможно сделать!

Если это не возможно то действительно придется менять CMS!

[Kosteus]

Задачи для модуля:

- позволяет создавать для одной модели товара неограниченный набор опций любого типа, определенных значение SKU.

- Вести учет складских остатков по SKU.

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

- Искать товар по любому из заданных идентификаторов

- Выводить на странице товара любое количество опций и их значений

- Выводить для каждого SKU свое изображение

- Выбирать товар последовательно по значению опций

Дополнительные задача:

- правка встроенного фильтра

- полное сопровождение на абонементе

- закодировать код

- запатентовать

Оплата от 700$, предоплата.

Для юр.лиц работа по договору.

[MonaLiza]

Костеус, ну ты реально нафлудил по форуму)) Я подумал с начала почему это все так раздраженно отвечают, а потом заметил кучу тем, ведущих к одному и тому же. 

 

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

 

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

 

Да, да! Конечно! "Закажи под себя разработку" это понятно, что можно заказать под себя. Хотя, судя по реакции на размышления Костеуса - не так-то просто. И стоимость может получиться больше, чем современная коммерческая CMS, включающая в себя полный функционал контроля остатков по разным параметрам. Костеус, с ума сошел за 30 тыр заказывать подобное.

 

Возможность обновления цен и остатков в автоматическом режиме по опциям, по артикулам в опциях, по связанным опциям, по артикулам связанных опций - это очень важно и нужно!

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

 

Меня не удивляет такая тема  и вопрос в ней справедливый. По моим ощущениям успешным магазин на Опенкарте может стать, если в товарах нет опций, если товары редкие, если это хендмейд, если у владельца хорошая торговая смекалка и если владелец программист или "умник" с опенкартфорума :wink: - остальные обречены на битрикс или провал. Пока не появится возможность синхронизации товарных остатков на автомате. С опциями! Ведь опция это неотъемлемый атрибут многих товаров! И многие ведут остатки по этим опциям.

 

Разработчики, вы всегда успеете нарубить денег на нас - школьниках и пионерах в интернетомагазиностроении. Сделайте уже реально нужный функционал - научите опенкарт кушать csv и xml Битрикса и вести учет остатков по опциям на автомате!

 

Не смотря на этот недостаток опенкарта, из бесплатных он лучший! ИМХО

Змінено 1 грудня 2015 користувачем MonaLiza

[Kosteus]

MonaLiza 

+1

 

Почему нельзя взять то, что сейчас называется опциями и поместить в это значение SKU и только?

Вместо например цвет и его значение поместить SKU и его значение, и пока там останутся поля присущие опциям?

Вынести значение опций во внешние таблицы и обрабатывать их там также как сейчас это уже делает модуль связанные опции, только он обрабатывает связку опций?

Разве это не позволит при замене опции на SKU также во внешние таблицы поместить не только опции, но и прочие идентификаторы товарной позиции? Это уже делает модуль связанные опции. Разве это затрагивает ядро opencart?

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

Если еще и количество удастся вынести во внешние таблицы, то встречайте CMS openBase 1.0 - конкурент 1С

[Kosteus]

+ почти все тоже самое делает модуль от Usergio, он также использует внешние таблицы.

[Kosteus]

 мы ознакомились с вашим ТЗ и решили делать по бартеру за 2 кг той травы, которую вы курили. Предоплата обязательна, иначе не реализуем.

 

p.s.  SKU в опциях сделать час делов, но патентовать это я морально не готов.

Не SKU в опциях, а опции в SKU.

Вполне вероятно право обладание вручить Usergio. Одному ему предполагаю будет тяжело.

Если внешние таблицы будут иметь не связанную структуру, а:

SKU1;размер; такой то;цвет; такой то; UPC; такой то; QR код; такой то; Наличие на складе А; такой то; Наличие на складе B; такой то

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

[Kosteus]

не... тут 2 кг не хватит. Минимум 3 надо будет

в $ сколько? щас прикину - 3 мульта.... а идея та хорошая была.... или самому программером становиться и распространять по лицензии GNU или как там ее :)

[Kosteus]

в $ сколько? щас прикину - 3 мульта.... а идея та хорошая была.... или самому программером становиться и распространять по лицензии GNU или как там ее :)

Ошибся в рублях 3 мульта, а это в 10 раз превышает допустимый бюджет, хотя если только программисту обещать 49% прибыли от продаж модуля, то можно и поменьше бюджет старт апа. Подтвердим это юридически.

[MonaLiza]

Не SKU в опциях, а опции в SKU.

Вполне вероятно право обладание вручить Usergio. Одному ему предполагаю будет тяжело.

Если внешние таблицы будут иметь не связанную структуру, а:

SKU1;размер; такой то;цвет; такой то; UPC; такой то; QR код; такой то; Наличие на складе А; такой то; Наличие на складе B; такой то

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

 

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

 

В БД есть колонка optsku, в которой указаны артикулы опций, там же есть колонка, в которой наличие. Usergio можно добавить инструмент "Обновить остатки по опциям". Но это только под мои нужды подойдет, т.к. я не использую связанные опции, а как с ними логика обстоит не знаю.

 

Такие вот настройки: черный;черный;черный;синий;красный | 44;48;46;48;46 | 5;6;7;3;10 | SKU1, SkU2, SKU3, SKU4, SKU5 | - это ужас! Для создания товаров пойдет, но не для синхронизации. Нужно менять логику.

[MonaLiza]

Ошибся в рублях 3 мульта, а это в 10 раз превышает допустимый бюджет, хотя если только программисту обещать 49% прибыли от продаж модуля, то можно и поменьше бюджет старт апа. Подтвердим это юридически.

 

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

 

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

[Kosteus]

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

 

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

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

Модуль А: выводит значение QR код на странице товара

Модуль B: Подсчитывает количество проволки и умножает значение метров на цену.

Модуль С (здесь немного сложнее, но уверен что и такой появиться): Выводит на страничке товара наличие товара в конкретных магазинах (Складах).

Это обработчик базы данных на основе SKU - это онлайн CMS управление торговлей и складом, имеющий неограниченные возможности для расширения. В opencart есть модули для выставления счетов, счетов фактур, накладных, а это решение действительно может заменить кому то 1C и это будет openbase, этого сейчас или нет, или появится очень скоро. Если в сегменте B2B, Вы правы это чисто коммерчески, если по аналогии лицензии самой opencart - это FREE и сообщество само все сделает. И начать можно сейчас с замены понятия ОПЦИИ на SKU.

[Blondi]

И вот после этого ответа вашего выходит, что теперь разработчик вам должен за идею

[Kosteus]

И вот после этого ответа вашего выходит, что теперь разработчик вам должен за идею

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

Право на обладание если это так важно вам можно вручить безвозмездно 19th 19th или Usergio или обоим сразу.

[MonaLiza]

И вот после этого ответа вашего выходит, что теперь разработчик вам должен за идею

 

Вообще-то, Костеус, напротив - предлагает за реализацию идеи свои 30 тыр. Он дает деньги разработчику, чтобы тот пока кодит мог на что-то питаться, а потом поднимать справедливый кеш за свои труды.

 

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

[Blondi]

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

[afwollis]

И начать можно сейчас с замены понятия ОПЦИИ на SKU.

воу-воу, ребята.

уже обсуждалось - опции в opencart изначально предполагались для мелочей, вроде

- нужна подарочная упаковка? - да/нет;

- надо ли запасное колесо? - да/нет;

- нужна ли установка/настройка нового оборудования? - да/нет;

- какие ингредиенты добавлять в пиццу? (список чекбоксов);

- желаемая дата доставки;

- итпд.

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

так что "заменять понятие _опции_ на _sku_" никто не будет.

[Kosteus]

opencart не затрагивается, затрагиваются только смежные модули.