7up

CSV Import/export - замечательный модуль, спасибо автору, сам через него обновляю цены. Он идеально подходит именно для обновления, но никак для например добавления товара или опций :( У меня допустим весь товар интернет-магазина храниться в 1с, там я все в нем меняю, корректирую, добавляю и т.д., а уже потом переношу в опенкарт. Так вот для такого метода кроме xls import/export решения не могу найти. Разве что покупать Total Import PRO или CVS Import PRO :( но не уверен что они решат задачу. Есть вот идея, попытаться переделать CSV Import/export добавив в него очистку базы перед загрузкой, ну и в место UPDATE использовать INSERT :) Допустим в файле экселя 7 вкладок, вот делать так же 7 файликов csv, ну или кому надо меньше и загружать их по отдельности. Что скажите господа?

Хотя тоже заметил какие-то непонятки с поиском :( кроме регистра он все таки не корректно ищет после замены OR на AND, а точнее ищет совсем не по критерию "И". Менял в 2х местах: после строки $words = explode(' ', $data['filter_name']); $sql .= " " . implode(" AND ", $implode) . ""; и после строки $words = explode(' ', $data['filter_tag']); $sql .= " " . implode(" AND ", $implode) . "";

Спасибо, полезная доработка. Но есть еще проблемка, как избавиться от регистра? У меня поиск, по крайней мере по названию товара, чувствителен к регистру символа! если ввести название товара с маленькой буквы, оно не попадает в результаты поиска :(

А русским языком, я чайник или нет? :) не пойму. А то чувствую что сделал не верно и полезу сейчас переделывать :) Денормализация (англ.denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных. P.S. Для обновления количества опций согласно склада, я из 1с выгружаю список(он получается не большой) в CSV вида: option_value;quantity и обновляю остатки цветов, размеров и т.д. Потому как полная выгрузка магазина в эксель с категориями, товарами, опциями у меня занимает при 150 товарах уже 1мб, причем 95% объема - это список вариантов опций.

Я это и имел ввиду, для каждой комбинации отдельная строка(опция), у нее свой уникальный айди, потому как при оформлении заказа она(комбинация) должна фигурировать в корзине, в истории заказа и т.д. Вот у меня вышло на 150 товаров одежды, с их комбинациями, больше пяти тысяч строк а таблице с опциями. Грубо посчитав (хотя конечно так не совсем верно) при 1500 товарах будет больше 50 тыс. строк. Нормально ли это для базы? Будет ли влиять на скорость работы? P.S. У меня по сути тоже самое, но доп. значения хранятся не в отдельном столбце таблицы, а через разделитель в строке value

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

Судя по скринам, необходимость связных опций в основном только для магазинов одежды :) Krish, а как в вашем случае, в каком виде, данные хранятся в базе? Меня например это волнует больше чем дизайн в админке :) Я вот вообще админкой не пользуюсь, даже не представляю как можно забить 1000 товаров через админку! У меня все товары в 1с из которой выгружают в магазин, в 1с же их и создаю....

Это единственная проблема, отображение? Ну а сам функционал? А как у вас хранятся в базе эти значения? Тоже для каждого товара дублируются строки и раздувается база?

To sergiosinicin: Получилось ли у вас реализовать ваш метод? :) Я вот столкнулся с проблемкой, сильно растет база, а именно таблица product_option_value. Получается что для каждого товара в этой таблице создается строчка с вариантом опции, в итоге всего на 136 товаров у меня 5454 строк в этой таблице :( Интересно, а есть какое-то иное решение для такого вида опций....

Да, работает отлично, спасибо! только подправил запросы под себя... делаю обновление количества опций товара и всякое другое......

Подскажите кто знает. Можно ли для блоков определять разные стили в зависимости от того, на какой странице они находятся. т.е. находясь на home блок будет иметь такие то стили (цвета, отступы и надписи), а находясь по другому пути, например pruduct другие. В теме пытался получить значение, на какой странице находимся, не вышло. Заранее спасибо.

Да, похоже тот самый, но бесплатный :)Хотя если учитывать то, что в поисках решения мне даже пришлось купить OpenStock за 25у.е. то 35у.е. - это мелочи :) Я б и купил, но смущает то, что все равно придется переписывать, потому как у меня при смене комбинаций опций меняется основная картинка товара + цена, значения опций выводятся не в селектах, а в картинках... Интересно как в этом модуле устроено хранение в базе? Видимо как было описано выше, просто доп. колонка с айди опции от которой она зависит... P.S К тому же этот модуль был добавлен 29го февраля, когда я уже по полной тестировал свое решение :)))) Мне напомнило то время, когда я ждал выхода опенкарта 1,5 и не начинал на 1,4 ничего, вот так вот всегда, нужно ждать, а не действовать :(

В смысле прайс в студию? :) Вид из которого импортировать в магазин? :)Мне просто промежуток в виде экселя между 1с и магазином не совсем нравится :( Да и каждый раз заливать всю базу магазина только ради обновления цены как-то не то. Пытаюсь сейчас работать на прямую с базой из 1с, что бы нажал кнопочку "обновить цены" обновились цены, а нажал "обновить остатки" обновились остатки и т.д. Хорошо бы, если модуль загружал в базу только отдельные данные, заранее указанные.... Вроде есть модификация импорт/экспорт ексель, который не стирает все данные при загрузке, а только обновляет... но она как-то не корректно работает :(

Ну у вас получается видимо пока два варианта решения, либо sergiosinicin либо 7up :) оба я так понимаю не особо сложны в реализации...А какой именно модуль CSV используете? CSV IMPORT PRO?

А куда слать то?Попытался прикрепить к теме файл, не получилось, или я не внимательный или у меня еще не тот статус на форуме :) А планируете делать, что бы связь опций была в три уровня? У меня, например, фасон:цвет:размер все зависит друг от друга, мучился, другого решения, не меняя базу, не смог найти. К тому же основной целью ставил - не менять базу, контролер и модель магазина, что бы можно было легко обновляться! посему 95% у меня это изменение в темплейте и 5% в одном файлике модели (для вычитания опций со склада)

Интересное решение, но в таком случае не получится делать загрузку из эксель например :( или переделывать модуль импорта/экспорта. Я уже вроде довел до версии пререлиз :) могу выслать коды, попробуете.

Проблема с вычитанием опций решена слегка изменив запрос: Может кто грамотный проверить, не будет ли такой запрос давать нагрузку на базу или что еще? Заранее спасибо. P.S. Оказалось движек не может учитывать количество опций на остатки при продаже. т.е. если осталось 5шт этой опции, а ввести количество товара при покупке 10, то в базу записывается значение -5 :( т.е. проверка на остаток делается только для товара. Надеюсь в следующих версиях добавят....

Проблема с вычитанием опций решена слегка изменив запрос: Может кто грамотный проверить, не будет ли такой запрос давать нагрузку на базу или что еще? Заранее спасибо. P.S. Оказалось движек не может учитывать количество опций на остатки при продаже. т.е. если осталось 5шт этой опции, а ввести количество товара при покупке 10, то в базу записывается значение -5 :( т.е. проверка на остаток делается только для товара. Надеюсь в следующих версиях добавят....

Есть опция, допустим, "подарочная упаковка", она(упаковка) одна для всех товаров. Добавляя ее в список опций товара, указываем ее количество на складе и subtract("вычитать со склада") - да. Так вот при покупке этого товара, как положено, происходит вычитание из остатка опции, но только для этого товара! В остальных товарах остаток "подарочной упаковки" остается прежним. Реально ли сделать так, что бы определенная опция вычиталась, при продаже любого товара где она есть, со всех списков, т.е. везде где она упоминается будет -1 при продаже?

В /catalog/model/checkout/order.php нашел строки, которые отвечают за вычитание количества: foreach ($order_product_query->rows as $order_product) { $this->db->query("UPDATE " . DB_PREFIX . "product SET quantity = (quantity - " . (int)$order_product['quantity'] . ") WHERE product_id = '" . (int)$order_product['product_id'] . "' AND subtract = '1'"); $order_option_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_option WHERE order_id = '" . (int)$order_id . "' AND order_product_id = '" . (int)$order_product['order_product_id'] . "'"); foreach ($order_option_query->rows as $option) { $this->db->query("UPDATE " . DB_PREFIX . "product_option_value SET quantity = (quantity - " . (int)$order_product['quantity'] . ") WHERE product_option_value_id = '" . (int)$option['product_option_value_id'] . "' AND subtract = '1'"); } } и вроде все понятно, вместо WHERE product_option_value_id = '" . (int)$option['product_option_value_id']. "' поставить бы WHERE option_value_id = '" . (int)$option['option_value_id']."' но в таком варианте работать отказывается когда ручками ставлю: WHERE option_value_id = '247' то все как положено, везде где опция с id 247 вычитается. т.е. (int)$option['option_value_id'] = 0 :( спрашивается, как правильно взять это значение. Заранее спасибо. P.S. Прошлое сообщение проглючило, форум вставил не корректно, как удалить не знаю....

please delete

Как раз столкнулся с проблемой вычитания со склада. Количество на складе каждой опции прописывается в каждом товаре отдельно. А не подскажет ли кто, как сделать, что бы во всех товарах где присутствует эта опция она вычиталась в нужном количестве? Я так подозреваю надо править где-то в моделе, строчку обращения к базе для вычитания quantity в таблице product_option_value, т.е. что-то тива везде в product_option_value где option_id равен этой опции сделать -"количество"

Да, было бы хорошо реализовать все это в админке конечно. Тогда каждый смог бы пользоваться как модулем... У меня такой необходимости нет, я все товары редактирую в 1с и после выгружаю, т.е. в админку практически заходить не нужно. Да и ума не хватит такое реализовать :) Мой метод уже потерпел несколько изменений :) Пока пришел у нужному.... Сейчас значение опций хранится в виде: большая:зеленая:красивая большая:зеленая:не красивая большая:красная:красивая большая:красная:не красивая маленькая:синяя:красивая маленькая:красная:красивая таким образом при выборе "большая" получаем на выбор только "зеленая" и "красная", а при выборе "маленькая" получаем только "синяя" и "красная" и далее соответственно..... у каждого такого набора свой option_id и своя цена, размер, вес и т.д. и самое главное свой остаток на складе. Цена меняется динамически. вот как-то так: ну и картинки товара меняются в зависимости от выбранного варианта. правда приходится хранить для одного товара много картинок :( но тут думаю другого варианта быть не может...

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

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