[webtrend]

Добрый день, кто нибудь настраивал систему бонусов? Чтобы пользователю начислялись балы с покупки и он мог в дальнейшем их использовать

[Rodogor]

Стандартный механизм бонусов чем-то не подходит?

[aghigay]

А в чем проблема настройки бонусов?

[webtrend]

Проблема в том что не можем найти и почитать информацию, или примеры реализации xslt

[aghigay]

Если я правильно понимаю, то речь идет об этом http://help.docs.umi-cms.ru/rabota_s_modulyami/modul_internet-magazin/skidki/nakopitelnye_skidki/
Это подходит?

[Rodogor]

http://help.docs.umi-cms.ru/rabota_s_modulyami/modul_internet-magazin/skidki/nakopitelnye_skidki/

Прежде чем дойти до XSLT - нужно сначала разобраться куда-чего тыкать в админке.

Обычно народ без проблем, интуитивно настраивает данный функционал.

[webtrend]

C этим все понятно, а как поставить ограничение на оплату бонусами, к примеру чтобы бонусы составляли только 20% от покупки, или к примеру чтобы сгорали через 3 месяца

[aghigay]

Это слегка разные механизмы :-)
Я бы делал так:
1. При попытке оформить заказ проверял бы что бонусы - не более 20%
2. Запускал бы каждеый день по крону скрипт, который проходился бы по всем пользователям и жег бы им просроченные баллы

[webtrend]

А примеров реализации у Вас нету? Интересует первый вариант, второй пока не сильно актуален

[aghigay]

Примеров нет - есть только общий концепт.
Я бы повесился на событие order-status-changed и проверял бы его как-то так:

Код: [Выделить]

if( $event->getMode() == "before" &&
		$event->getParam("old-status-id") == false &&
		$event->getParam("new-status-id") == order::getStatusByCode('waiting') ) 

И тут бы смотрел, достигнуты ли 20% или нет

Про события подробнее тут: http://api.docs.umi-cms.ru/razrabotka_nestandartnogo_funkcionala/sobytijnaya_model_umicms/standartnye_tochki_vyzova/

[Rodogor]

C этим все понятно, а как поставить ограничение на оплату бонусами, к примеру чтобы бонусы составляли только 20% от покупки, или к примеру чтобы сгорали через 3 месяца

1. Ограничение на оплату.
Клиентская часть -
На этапе оплаты надо получить сумму заказа, сумму бонусов, ну и на JS ограничить ввод количества бонусов БОЛЬШЕ, чем 20% суммы заказа.
Самый простой способ - взять это из emarket::basket() - udata://emarket/basket, это можно сделать на JS. Если у пользователя есть бонусы, то они будут доступны в customer//property[@name='bonus'].
Серверная часть -
Предположим, что наши пользователи хитрожопые и могут обойти JS код на клиентской стороне, которые не даёт ввести более 20% бонусов от суммы заказа.
Бонусы для заказа устанавливаются методом order::setBonusDiscount($bonus) , в котором уже снова получаем сумму заказа, количество указанных бонусов и проверяем, что бы нас не нагрели. В случае, если это происходит, то устанавливаем процент бонуса - 20% от заказа + отсылаем уведомление менеджеру, а пользователя добавляем в группу "хитрожопые".

2. Бонусы сгорают через 3 месяца
Тут надо понимать как именно должно работать.
К примеру, в 1-ый месяц я получил 100 бонусов, во 2-ой - ещё 100, в 3-ий - ещё 100. Вопрос: на 4-ый месяц у меня сгорят 100 бонусов от 1-ого месяца или нет?
Или всё зависит от времени последнего заказа? От факты оплата бонусами?... От факта пополнения бонусами?.....

[aghigay]

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

[Rodogor]

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

Каждый календарный месяц или каждый месяц бездействия?
А если я зарегистрировался в последний день месяца и получил бонусы, завтра они сгорят?
А если у меня меньше 35 бонусов - отрицательное число бонусов станет?

[aghigay]

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

Каждый календарный месяц или каждый месяц бездействия?
А если я зарегистрировался в последний день месяца и получил бонусы, завтра они сгорят?
А если у меня меньше 35 бонусов - отрицательное число бонусов станет?

Ну зачем перегибать-то? Очевидно что нельзя списать бонусов больше, чем есть. Ну и последний день в случае системы, которую я сам лично видел никак не компенсируется. То есть реально в последний день я могу накопить 35 бонусов и у меня их тут же спишут. Да, есть такая тема - но это вопрос конкретного маркетингового подхода. Я же не говорю что это прям единственно верное решение. Да и не бывает верных решений в данном случае. Нужно тестировать на пользователях что их больше будет мотивировать: сгорающие на 100% бонусы каждые 3 месяца или сгорающие каждый месяц почутка бонусы? Ну то реально это выглядит как: напомнить о себе через 3 месяца после покупки или напоминать о себе каждый месяц, пока есть бонусы. И тут бабушка надвое сказала что выгоднее :-)

[webtrend]

Думаю банально можно ввести систему купил получил бонусы, через 3 месяца они сгорели, купил в этот период еще, заработал еще бонусов срок продлился еще на 3 мес с момента последней покупки