Текущая система начисления бонусных требует доработки:
1) Бонусные баллы начисляются после оплаты заказа, а не после фактического исполнения/получения покупателем, что было бы логично. Сейчас имеется возможность/лайфхак получить скидку на ровном месте:
Покупатель оплачивает заказ(ы), сразу получает бонусные баллы. После этого оформляет еще заказ, применяя к нему только что полученные баллы, а затем обращается в магазин и просит отменить первый заказ.
2) Округление бонусов как минимум до целого числа просто необходимо и совершенно непонятно, почему столь легкая опция через ceil(...) до сих пор не реализована по умолчанию. Кому нужны десятичные числа в бонусных баллах? Наверное, лучше 26 баллов, чем 25,94? Это полный аналог копеек, которыми в 2021-м году пользуется лишь тот магазин, который не уважает ни покупателей, ни свою бухгалтерию, добавляя им геморроя.
3) Поддержка разного курса начисления баллов в зависимости от типа/категории/списка товаров.
4) Нативная поддержка/хук отображения бонусных баллов в карточке товаров и в каталоге, которые покупатель получит за каждый из товаров, в т.ч. с учетом артикула и количества в поле quantity.
9 комментариев
2-4 решаются плагином «гибкие скидки и бонусы»
Фунционал не сырой. он удовлетворяет базовым потребностям. Большинству пользователей не нужна гибкая система начисления бонусов, многих устраивает фиксированный процент на все товары. Вам нужна продвинутая гибкость - для вас сделали плагин.
Навскидку, проблема решается одной строчкой кода в user.css (задать минимальную высоту элементу). Могу заблуждаться, т.к. вывод информации плагином не использую и не знаю как там сверстано, вместо этого в целях оптимизации скорости загрузки просто вшиваю информацию о бонусах в тему дизайна статично. В любом случае, эта мелкая погрешность плагина отображаемая на вашей теме дизайна решаема малыми силами.
Ну так у вас и цена не меняется. Какой смысл динамически менять бонусы от кол-ва добавляемых товаров, но не менять цену?) при желании, и то и другое в индивидуальном порядке можно поправить достаточно быстро.
Какая принципиально разница кто будет делать запросы к БД: код в плагине или код в теме дизайна или код в движке?
Вы правда считаете что сделать на уровне Shop Script функционал повторяющий плагин "Гибкие скидки и бонусы" можно за сутки? Вы не Земле живете или на Венере?
Я думаю, что ваше пожелание по доработке функционала (начисление бонусов не в момент получения заказом признака "Оплачен" а либо в момент получения заказом статуса "Выполнен", либо через N дней после получения заказом статуса "Выполнен" с возможностью указать N) с бОльшей вероятностью может быть принято к рассмотрению сотрудником Webasyst и когда-либо реализовано, если вы создадите отдельную тему с данным пунктом. Это действительно дельное предложение.
Округление до целого числа для бонусов - это и есть база, которая нужна, я уверен, 99% пользователей. Или же Вы из тех, кто и копейки до сих пор использует в цене а-ля 132 руб 47 копеек?!
height: Ypx позволяет устранить, однако мигание остается.
А цена и не должна меняться, на то она и "цена" за единицу товара. Сомневаюсь, что изменение цены в большую сторону может положительно отразиться на росте конверсии. А вот увеличение размера бонусов/кэшбека при изменении количества товара вполне может простимулировать покупку большего количества. Увы, есть такие незаурядные покупатели, которым неочевидно, что баллы начисляются кратно количеству, особенно если целевая аудитория 50+ и с этой аудиторией приходится работать.
Наверное, потому что плагин с таким обширным функционалом даже при отключении такового будет делать в лучшем случае столько же запросов, а в подавляющем количестве случаев - больше запросов, чем нативная реализация?! Кроме того, разница может проявиться в сложности/тяжести запроса. Для нативной реализации для условной доработки нужно подцепить дополнительный столбец/строку/ячейку. А для отдельного плагина почти всегда будет делаться свой отдельный запрос, где большая часть данных будет дублировать родной запрос.
Почему не процитировали "возможная несовместимость с другими плагинами или обновлениями CMS на первых порах" - быть в зависимости от разработчика плагина? А как же дополнительные подключаемые во фронтенде .css/.js? Забавно порой видеть некоторые плагины, в т.ч. платные, которые реализуют элементарный функционал, но засирающий сайт своими ненужными подгрузками.
У Вас какая-то уникальная способность вырывать фразы из контекста, поливать их своим фирменным соусом и подавать на блюде в качестве мысли другого человека. Приведите мне цитату, где я сообщил, что реализация функционала, повторяющего плагин "Гибкие скидки и бонусы", займет сутки. Да и вообще сама мысль того, что кому-то может понадобиться полная копия уже разработанного и купленного плагина, мягко говоря, недальновидна. Когда приведете эту цитату - поскорее возвращайтесь с Нептуна.
=) прилетел. поискал пример цитаты, не нашел. действительно, не так вас понял и вырвал из контекста.
ваша очередь искать и приводить пример плагина/темы/приложения, которое серьезно конфликтует с плагином "Гибкие скидки и бонусы".
--
Главную мысль которую я хотел донести: не вижу смысла агитировать за добавление чего-либо в движок, если это что-то уже имеется в каком-либо плагине и нормально работает.
- возможность начислять бонусы не по признаку заказа "оплачен"? - да, этого не хватает.
- возможность округлять бонусы? - можно решить проблему плагином.
- возможность начислять бонусы по каким-либо критериям? - можно решить проблему плагином.
Зачем Вебасисту тратить время на то чтобы что-то сделать, если это уже сделано? Других проблем как будто не хватает? Ладно, я обратно на Нептун. Соус стынет.
никакой очереди, ведь я написал о возможной несовместимости - плагинов тысячи, где-нибудь да найдется, и опять же - сначала обновляется движок, потом плагин. Вот этот промежуток между обновлением движка и плагином порой занимает приличное количество времени. А новейшие версии php/mysql? Сам не раз сталкивался с тем, что движок оптимизирован под свежую версию, а вот плагины - нет.
Это несколько странно, учитывая Вашу тему https://support.webasyst.ru/fo... где Вы просите разработчиков Webasyst доработать функционал наклеек/стикеров и пишете "Текущий функционал наклеек в Shop Scriot сделан для галочки, не более.". В комментариях верно указали, что есть соответствующие плагины, в т.ч. "Наклейки" от... *барабанная дробь*... того же разработчика, что и плагин "Гибкие скидки и бонусы", на который Вы здесь акцентируете внимание. Иронично, не находите?
Идеально лезет пословица "в чужом глазу соломину видеть, в своём — бревна не замечать"
- штатный функционал начисления бонусов в шоп скрипт сделан на твердую 4-ку и большинству пользователей подходит. Он имеет небольшие недостатки, которые по необходимости можно подправить плагином.
- штатный функционал наклеек в шоп скрипт сделан на 2-ку с минусом. Он имеет большие недостатки.
Не сравнивайте жопу с пальцем.
Ничего ироничного не нахожу. Это вы заняли позицию, что плагины это априори плохо, а штатный функционал это априори хорошо. Я в отличие от вас стараюсь быть объективным.
1 пункт действительно проблемный в контексте возвратов заказов. По-хорошему, начисление бонусов должно происходить не тогда, когда заказ получает признак "Оплачен", а тогда, когда захочет администратор сайта. Например: в момент перевода заказа в статус "Выполнен" или через 14 дней после перевода заказа в статус "Выполнен". Возможности кастомизации здесь немного не хватает.
Разработчики наверное не ходят в магазины и ничего не заказывают онлайн или в доставке еды, тоже бонусы работают. Бо логично, что бонусы должны приходить после статуса выполнен и в идеале через 14 дней, так как можно вернуть товар. Это должно быть в коробке ШШ, ну ясень пень никто это вздумает делать