Опции - отстой!

[toporchillo]

OpenCart хранит остатки товаров по опциям неправильным способом. Представьте товар с двумя опциями. Его количество задается 2-мерной матрицей. Но OpenCart хранит в базе не всю матрицу, а только сумму элементов по строкам и сумму элементов по столбцам. M + N чисел могут однозначно хранить M x N чисел только если M и N <= 2.

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

Надо базу переделывать со всеми вытекающими последствиями.

[19th]

Это был крик души или попытка обратить внимание общественности?

[toporchillo]

Это был крик души или попытка обратить внимание общественности?

Хочется обсудить с компетентными товарищами, как лучше всего исправить эту серьезную ошибку OpenCart.

[19th]

как лучше всего исправить эту серьезную ошибку OpenCart.

Не скажу, что это ошибка. Я так понимаю изначально это планировалось как "упаковка" или там "доп.наушники", а не цвета и размеры футболки, к примеру. Есть платные плагины для связи опций типа http://www.opencart.com/index.php?route=extension/extension/info&extension_id=3706

[toporchillo]

Не скажу, что это ошибка. Я так понимаю изначально это планировалось как "упаковка" или там "доп.наушники", а не цвета и размеры футболки, к примеру. Есть платные плагины для связи опций типа http://www.opencart....tension_id=3706

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

[mpn2005]

OpenCart хранит остатки товаров по опциям неправильным способом. Представьте товар с двумя опциями. Его количество задается 2-мерной матрицей. Но OpenCart хранит в базе не всю матрицу, а только сумму элементов по строкам и сумму элементов по столбцам. M + N чисел могут однозначно хранить M x N чисел только если M и N <= 2.

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

Надо базу переделывать со всеми вытекающими последствиями.

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

Или я что-то недопонял.

Поясните о чём речь. А то я что-то затупил. :oops:

[toporchillo]

Допустим в базе хранятся опции:

Красный - 2, Зеленый - 3, Синий - 5

Большой - 5, Маленький - 5

При этом у вас на складе может быть:

Синих-больших - 5

Красных-маленьких - 2

Зеленый-Маленький - 3

либо

Синих-больших - 4

Зеленых-больших - 1

Синих-маленьких - 1

Красных-маленьких - 2

Зеленый-Маленький - 2

Так сколько же и каких товаров у вас на складе?

[19th]

Поясните о чём речь.

Если не путаю: у вас в магазине есть футболки, размеры и цвета храните опциями. В наличии:

• красная футболка 50 размера - 2 штуки
  
• красная футболка 49 размера - 1 штука
  
• синяя футболка 50 размера - 1 штука
  
• синяя футболка 49 размера - 1 штука.
  

Тогда у вас:

• товар "футболка" с остатком 5
  
• опция "красный" - 3
  
• опция "синий" - 2 штуки
  
• опция "50 размер" - 3 штуки
  
• опция "49 размер" - 2 штуки
  

Контроль остатков включен. Таким образом человек может заказать 3 красных футболки 50 размера.

[19th]

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

Ну такой ответ можно дать на 70% функционала Опенкарта. Все вроде бы как есть, но почти все нужно настраивать, допиливать и доделывать модулями.

[toporchillo]

Ну такой ответ можно дать на 70% функционала Опенкарта. Все вроде бы как есть, но почти все нужно настраивать, допиливать и доделывать модулями.

Тогда зачем было вообще вводить кол-во в опциях?

[mpn2005]

Тут немного беда в сопряжении.

Каждая опция это своя сущность.

Лучше тогда организоввывать по другому.

Опция футболка:

Синяя, размер 1 - 10 шт

Красная, размер 2 - 8 шт

Белая, размер 1 - 3 шт

При выводе опций, парсим название опции и разбиваем (Разделитель запятая).

Выводим опцию например таблицей (Колонка Цвет, Столбец размер).

При таком подходе должно быть всё хорошо.

Пример http://softlab.by/an...t-Security.html

[toporchillo]

Об этом и речь: хранить надо всю матрицу (гиперкуб) остатков по опциям, а не только срезы.

Вопрос: Как это лучше сделать на уровне таблиц БД, как реализовать на уровне интерфейса?

[mpn2005]

Об этом и речь: хранить надо всю матрицу (гиперкуб) остатков по опциям, а не только срезы.

Вопрос: Как это лучше сделать на уровне таблиц БД, как реализовать на уровне интерфейса?

Синяя, размер 1 - 10 шт - это значение одной опции в базе

что и есть конечный товар

Так это выглядит в админке:

[sh0ut]

Такая реализация мне кажется это имхо не круто и имхо не красиво.

На сайте о котором идёт речь установлен модуль Dependent Options, который как раз и даёт заказать товар, которого фактически нет на складе.

[mpn2005]

Такая реализация мне кажется это имхо не круто и имхо не красиво.

На сайте о котором идёт речь установлен модуль Dependent Options, который как раз и даёт заказать товар, которого фактически нет на складе.

В том что я предлагал, какраз нельзя заказать то чего нет.

Одна строчка один товар и с отниманием беды нет.

А когда товар составной из опций, то там концов не собрать. И вычитание со склада не работает.

[19th]

Тогда зачем было вообще вводить кол-во в опциях?

Можно я еще раз повторю?

Я так понимаю изначально это планировалось как "упаковка" или там "доп.наушники"

Ну или давайте другой пример приведу, Вы продаете букеты цветов и как опции у вас идут "открытка", "красивая ленточка", "бутылка шампанского". Т.е. не вид товара, а дополнительная штука к нему.

[freelancer]

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

[toporchillo]

Синяя, размер 1 - 10 шт - это значение одной опции в базе

что и есть конечный товар

Так это выглядит в админке:

....

А какой модуль используется?

[mpn2005]

Сам писал вывод.

Там всё просто. Разбираю строку с разделителем, запихиваю в двумерный массив.

Потом вывод таблицей.

Пишите в личку мыло, скину модуль.

[7up]

Сам писал вывод.

Там всё просто. Разбираю строку с разделителем, запихиваю в двумерный массив.

Потом вывод таблицей.

Пишите в личку мыло, скину модуль.

Делаю примерно так же :)

 

Может и глупо, но у меня опция для например футболки имеет вид "Мужская | Синяя | L" - 10шт. После чего в tpl разбиваю все и получаю некое подобие связи опций, т.е. при выборе Мужская получаю цвета только для мужской, при выборе Синяя получаю размеры только для Мужской-Синей. Правда при выгрузке из 1с приходится пробегать всю таблицу опций и менять количество остатка в каждой повторяющейся строке :(

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

 

Аналогично задумывался что как-то не хорошо хранятся опции в Опенкарте, хотя правильнее сказать "не так как мне нужно" :)

[mpn2005]

Делаю примерно так же :)

 

Может и глупо, но у меня опция для например футболки имеет вид "Мужская | Синяя | L" - 10шт. После чего в tpl разбиваю все и получаю некое подобие связи опций, т.е. при выборе Мужская получаю цвета только для мужской, при выборе Синяя получаю размеры только для Мужской-Синей. Правда при выгрузке из 1с приходится пробегать всю таблицу опций и менять количество остатка в каждой повторяющейся строке :(

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

 

Аналогично задумывался что как-то не хорошо хранятся опции в Опенкарте, хотя правильнее сказать "не так как мне нужно" :)

В вашем варианте, тоже жить можно.

 

Создавайте значения опции в виде: Тип|Цвет|Размер

Одна опция однозначно определяет товар.

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

Как-бы виртуальное разделение на три опции.

 

Решение не претендует на универсальность, зато для конкретного случая не сильно трудно реализуется.

[7up]

В вашем варианте, тоже жить можно.

 

Создавайте значения опции в виде: Тип|Цвет|Размер

Одна опция однозначно определяет товар.

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

Как-бы виртуальное разделение на три опции.

 

Решение не претендует на универсальность, зато для конкретного случая не сильно трудно реализуется.

Да, я именно так и делаю, все работает красиво, НО при обновлении остатка опций приходится выполнять довольно долгий запрос. Одна единица опции у меня для каждого товара одна и та же, например "Мужская красная футболка М" есть у каждого товара, товар - это принт на футболке. Так вот что бы изменить количество "мужская, красная, м" приходится делать что-то вроде " UPDATE quantity... WHERE IS "мужская, красная, м" и чем больше  товаров тем дольше выполняется такой вот элементарный запрос :(

 

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

[mpn2005]

Тогда понятно.

Тут немого нетривиальная организация товара.

[Zavik21]

При создании больце 250 наименований товара выходит ошибка... 249 созраняет а больше, хоть на один не получается!

[ravilr]

значений опций?? Если да, то пишите хостеру, на предмет увеличении лимита по передачи значений в пост запросе.