Перейти до

Переход на помесячное снятие абонплаты.


Рекомендованные сообщения

Вот ещё, я не стану крутить дату на рабочем сервере. А больше просто негде.

Лучше поверить на слово, что дело тут скорее не в FullFee:

FullFee – снимать полную абонплату, даже если пользователь был

заморожен часть учетного периода. Принимает значения yes и no.

Параметр не является обязательным, по умолчанию установлен в no.

А в

DayFee – параметр, показывающий серверу, в какой день месяца снимать

с клиентских счетов сумму абонплаты, в соответствии с тарифными

планами клиентов. По умолчанию DayFee=21. Следует помнить, что в

некоторых месяцах не более 28 дней. Данный параметр также может

принять значение 0; если параметр равен 0, тогда система выполнит

действия в последний день текущего

и в

DayFeeIsLastDay – параметр, указывающий серверу, когда абонплата

снимается в последний (yes) или первый (no) день учетного периода. Это

влияет на то, как будет снята абонплата (АП) при переходе на новый

тариф. Если у пользователя был тариф A с АП=100 и он хочет перейти на

тариф B с АП=200, то при переходе на новый тариф со счета пользователя

снимется 100, если DayFeeIsLastDay = yes, и 200, если

DayFeeIsLastDay = no. По умолчанию DayFeeIsLastDay = yes.

 

Это цитаты из pdf-файла http://stg.dp.ua/download/other/stargazer_help_v2.13.pdf - к Stargazer, думаю по поводу DayFee=21 в самом СТГ что-то уже поменялось.

 

Т.е. я хочу сказать, что если бы было DayFeeIsLastDay=no (сумма АП соответствует текущему месяцу, на момент расчёта) и DayFee=0 (снимать АП в конце месяца) - эта схема могла бы сработать правильно, только в конце месяца.

Но при DayFeeIsLastDay=no и DayFee=1 - получается, что конец расчётного периода это 1-ое число. Потому в моём случае он и снял АП только за один день.

 

А вот опция FullFee=yes - заставляет снять всю сумму АП и позволяет обойти эту путаницу.

Вот. Ну, подождём что скажет 1-ое число. Подождём февраля. :)

Ссылка на сообщение
Поделиться на других сайтах

У меня:

 

DayFee = 1

DayFeeIsLastDay = no

SpreadFee = no

FullFee=yes

 

 

Все работает уже года 2 как часы, абонплата снимается полностью(а не енная часть от месяца) и безвозвратно :) 1-го числа каждого месяца сразу после изменения тарифов и сброса каунтеров.

Ссылка на сообщение
Поделиться на других сайтах
  • 5 weeks later...
У меня:

 

DayFee = 1

DayFeeIsLastDay = no

SpreadFee = no

FullFee=yes

 

 

Сделал так же. Всё сработало "на ура", за исключением одного момента:

У меня 28-го числа каждого месяца - скрипт обходит счета юзеров и если видит сумму на счету менее определённой суммы - замораживает счёт.

Ну так вот, сегодня 1-ое, а абонка с замороженного счёта снялась полностью. Т.е. произошло движение средств по счёту, вопреки моим ожиданиям.

Почему это и как победить?

Правда я его вручную заморозил только 31-го...

Или мне будет проще написать скрипт, который возвращает деньги таким юзерам?

Ссылка на сообщение
Поделиться на других сайтах

Пардон, ничем к сожалению здесь не помогу ибо "отмороженных" пользователей не использую ;)

 

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

 

В конце концов кто на кого работает? :)

 

/* по идее FullFee таки должен тотально снимать абонплату полностью в независимости от бобочных обстоятельств - на то он и FullFee */

Ссылка на сообщение
Поделиться на других сайтах

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

Меня смущает лишь то, что абонка таки снимается в этом случае, хотя не хотелось бы чтоб так было.

Ссылка на сообщение
Поделиться на других сайтах

Ну во-первых если у вас АП 100 грн а человек "проломил себе череп и уехал на северный полюс на 6 месяцев" будет полностью очевидно что в случае полного снятия абонплаты (а не 31.22 или 84.973 грн.) у пользователя получится -600 грн и никто не мешает их вправив баланс вручную по факту реанимации человека пингвинами.

 

1234g.png

 

С другой стороны насчитывая им скажем по 10 грн. в месяц по факту простоя очень хороший метод надресировать их менять себе тариф на стояночный и в целом хоть как-то держать АРПУ в условиях демпинга.

 

 

PS Да я знаю что пингвины на северном полюсе не живут :Р

Ссылка на сообщение
Поделиться на других сайтах

madf, спасибо, как-то пропустил это в документации, хотя выше цитировал.

Заморочка в том, что если FullFee=no (не снимать полную абонку), то снятие денег первого числа с параметром DayFee=1 (снимать абонку 1-го числа) произойдёт только за этот первый день.

А иначе возможен только вариант, когда DayFee=0 (снимать абонку в последний день) и FullFee=no (не снимать полную абонку). В этом случае снимется абонка полностью, за прошедший месяц. И заморозка по идее будет работать. Только путаница будет , если человеку сменили тариф в середине месяца, да и снятие денег 30-го числа, когда юзеры уже привыкли, что АП снимается 1-го - восторгов не вызовет. ;)

Видимо и правда проще скриптом как-то обходить таких юзеров или вручную.

Ссылка на сообщение
Поделиться на других сайтах

madf, спасибо, как-то пропустил это в документации, хотя выше цитировал.

Заморочка в том, что если FullFee=no (не снимать полную абонку), то снятие денег первого числа с параметром DayFee=1 (снимать абонку 1-го числа) произойдёт только за этот первый день.

А иначе возможен только вариант, когда DayFee=0 (снимать абонку в последний день) и FullFee=no (не снимать полную абонку). В этом случае снимется абонка полностью, за прошедший месяц. И заморозка по идее будет работать. Только путаница будет , если человеку сменили тариф в середине месяца, да и снятие денег 30-го числа, когда юзеры уже привыкли, что АП снимается 1-го - восторгов не вызовет. ;)

Видимо и правда проще скриптом как-то обходить таких юзеров или вручную.

Лучше тариф менять в конце месяца. Проблем намного меньше возникает, да и тарификацию проверять намного проще.

Ссылка на сообщение
Поделиться на других сайтах

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

Кстати, вопрос на засыпку - если FullFee=yes, и счёт заморожен не первый месяц уже, абонка всё равно будет сниматься все эти месяцы или нет?

Если нет, значит проблема решена, я могу и подправить разок, если что. :)

 

вот сколько наблюдаю ваши посты Kucher2 так и не могу понять кто там у вас на кого работает

ЗЫ без обид

;)

Ссылка на сообщение
Поделиться на других сайтах
абонка всё равно будет сниматься все эти месяцы или нет?

будет - нечего тут :)

 

Хотя очевидно что если пользователь отморожен, у него на счету -1200 грн значит он не работал он год по тарифу за 100 грн. Вы можете посердобольствовать ему и накинуть обратно мульйон денег.

 

У нас для таких штук используется просто парковочный тариф без абонплаты - это снимает все такие проблемы автоматом.

Ссылка на сообщение
Поделиться на других сайтах

давайте я разовью вам мысль в направлении вашей "юзеролюбивости и гуманности"? :)

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

Кстати, вопрос на засыпку - если FullFee=yes, и счёт заморожен не первый месяц уже, абонка всё равно будет сниматься все эти месяцы или нет?

Если нет, значит проблема решена, я могу и подправить разок, если что. ;)

 

вот сколько наблюдаю ваши посты Kucher2 так и не могу понять кто там у вас на кого работает

ЗЫ без обид

;)

Только за текущий месяц.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...