Wild

Ок, спасибо. А что на счет второго про условий отображения штатных и установленных доставок?

Вдогонку... Написано, что модуль корректно работает с симплой. У меня в ней уже задана логика зависимостей разрешения/запрещения некоторых методов оплаты. При задании дополнительных условий в вашем модуле ничего не поломается? Еще вопрос... В вашем модуле в настройках оплаты условия отображения можно задать и для штатных или установленных, и для созданных с помощью вашего модуля. А вот для доставки для штатных/установленных настройки условий отображения/запрещения нет. Только для созданныих через FilterIt. С чем это связано?

Признаки просты - 0 в количестве, и статус при отсутствии на складе - "под заказ". Я тестировал на демке этот вариант, такое условие создать можно. Или как тут уже писали просто использовать какое-либо ненужное поле типа UPS, но первый вариант мне кажется грамотнее и логичнее. С логическими операциями проблем не будет. Т.е. в целом мой вариант должен сработать, верно? Просто на демке нет возможности редактировать товары, чтобы проверить правильность моих мыслей и весь цикл работы модуля на корректность.

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

Товары обычные, производители разные, склады разные. В настройках условий есть учет количества и состояния на складе (нет в наличии, 2-3 дня, под заказ), так что в принципе можно обойтись и штатными методами. Я об этом и писал. Или же действительно можно задействовать неиспользуемые поля типа UPS и т.д. Т.е. в принципе можно реализовать и должно сработать, верно? Может еще у кого есть какие мысли?

Прежде чем купить модуль хочу проконсультироваться подойдет ли он. Заказчик поставил задачу реализовать продажу товаров под заказ с отложенной оплатой. Посмотрев демку, понял что можно сделать типа такого... Логика следующая.: Товары под заказ отмечаются соответствующим статусом отсутствия на складе и количеством 0, в настройках магаза разрешено заказывать товары с 0 количеством. Покупатель ложит товары под заказ в корзину. С помощью модуля создается метод оплаты именно таких товаров с условием доступности, если в корзине только такие товары (чтобы не мешать с обычными). В остальных методах оплаты добавляется исключающее условие на наличие в корзинах заказных товаров. Т.е. если в корзине винегрет, то запрещены все модули оплаты (с выводом соответствующего сообщения), если только обычные, то недоступна оплата заказных, если только заказные, то соответственно включается только заказной метод. Дальнейшие вопросы по поступлению заказанных товаров и их оплаты ложится на плечи менеджеров. В теории все верно? Какие подводные камни могут быть?

Адаптирую один из модулей для 1.5 под 2.0. В модуле 2 параметра - статус вкл./выкл. и еще один. Вроде все сделал, но статус записывается, а вот второй параметр почему-то не сохраняется. При этом форма передает оба параметра в этом куске. if (($this->request->server['REQUEST_METHOD'] == 'POST') && $this->validate()) { $this->model_setting_setting->editSetting('fast_opt', $this->request->post); $this->session->data['success'] = $this->language->get('text_success'); $this->response->redirect($this->url->link('extension/feed', 'token=' . $this->session->data['token'], 'SSL')); } Еще кусок контроллера: if (isset($this->request->post['fast_opt_status'])) { $data['fast_sitemap_status'] = $this->request->post['fast_opt_status']; } else { $data['fast_sitemap_status'] = $this->config->get('fast_opt_status'); } if (isset($this->request->post['f_s_cache_status'])) { $data['f_s_cache_status'] = $this->request->post['f_s_cache_status']; } else { $data['f_s_cache_status'] = $this->config->get('f_s_cache_status'); } Кусок шаблона: <form action="<?php echo $action; ?>" method="post" enctype="multipart/form-data" id="form-google-base" class="form-horizontal"> <div class="form-group"> <label class="col-sm-2 control-label" for="input-status"><?php echo $entry_status; ?></label> <div class="col-sm-10"> <select name="fast_opt_status" id="input-status" class="form-control"> <?php if ($fast_sitemap_status) { ?> <option value="1" selected="selected"><?php echo $text_enabled; ?></option> <option value="0"><?php echo $text_disabled; ?></option> <?php } else { ?> <option value="1"><?php echo $text_enabled; ?></option> <option value="0" selected="selected"><?php echo $text_disabled; ?></option> <?php } ?> </select> </div> </div> <div class="form-group"> <label class="col-sm-2 control-label" for="input-data-feed"><?php echo $entry_cache_status; ?></label> <div class="col-sm-10"> <select name="f_s_cache_status" id="input-status" class="form-control"> <?php if ($f_s_cache_status) { ?> <option value="1" selected="selected"><?php echo $text_enabled; ?></option> <option value="0"><?php echo $text_disabled; ?></option> <?php } else { ?> <option value="1"><?php echo $text_enabled; ?></option> <option value="0" selected="selected"><?php echo $text_disabled; ?></option> <?php } ?> </select> </div> </div> </form> Помогите разобраться... Почему не сохраняется параметр f_s_cache_status?

demo недоступно

Это запрос MySql. Можно выполнить в PHPMyAdmin. Только подставьте правильный префикс таблиц, если у вас отличается от oc_

О! Получил. Спасибо.

Купил вчера модуль. Правда покупал на другой площадке, поскольку нужно было оплатить Яндекс деньгами, а здесь в этом случае суммарная комиссия совсем конская 24%. Написал письмо на счет лицензии где-то в 17:30. До сих пор ни ответа ни привета. Включил ждуна... Че-то начинаю расстраиваться на счет оперативности поддержки.

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

Ответил в личку.

Купил вчера модуль. Написал письмо на счет лицензии где-то в 17:30. До сих пор ни ответа ни привета. Включил ждуна... Че-то начинаю расстраиваться на счет оперативности поддержки.

Поддерживаю 2 руками! Я не из России, пользуюсь их кошельком и картой. При попытке оплатить модуль за 600 рублей с карты, мне набросили комиссию агрегатора 38 рублей + 100 рублей комиссии от Яндекса. Некисло так 23%... Плюнул, отменил заказ, купил на другой площадке, с общей комиссией Яндекса 2,99 р. Уже в который раз надеюсь на более лояльное отношение к Яндексу и его картам, но воз и ныне там. В отменах лежит куча заказов, которые пробовал оплатить, но постоянно натыкался на эту проблему. По этому мои деньги уплывают мимо вас.