Суточная абонплата

[goletsa]

в январе 31 день: 20/31 = 1.55

O_O, поделитесь таким калькулятором который будет все в мою пользу считать

[olegotek]

Не мог бы автор сказать в какой системе исчисления 1,55*31=20 ?
 и потом объяснить плюсы и минусы от того что мы делаем пропорциональную  и фиксированную абонплату скажем в 1 грн в день

Зачем вцепился к человеку, понятно же что он случайно в первой строке поделил не 20/31 а 31/20 вот и вышло 1,51. В задумке должно быть
20/31=0,645
20/28=0,714
Это нормальная система которая уже в некоторых билингах задействована. Я за! Думаю это несложно поправить в скрипте который снимает суточную оплату. Просто добавить опцию снимать установленную плату или снимать по частям.

[versus]

Не мог бы автор сказать в какой системе исчисления 1,55*31=20 ?
 и потом объяснить плюсы и минусы от того что мы делаем пропорциональную  и фиксированную абонплату скажем в 1 грн в день

Зачем вцепился к человеку, понятно же что он случайно в первой строке поделил не 20/31 а 31/20 вот и вышло 1,51. В задумке должно быть
20/31=0,645
20/28=0,714
Это нормальная система которая уже в некоторых билингах задействована. Я за! Думаю это несложно поправить в скрипте который снимает суточную оплату. Просто добавить опцию снимать установленную плату или снимать по частям.

Ну так, если ты думаешь, что это не сложно, то добавь, делов то по твоему на пару минут.

Дело не в том что мы прицепились, а в том что даже провайдер ошибается сколько ему платить надо в месяц, что говорить о пользователях, которые 5 на 2 поделить без калькулятора не могут.
Еще раз опишите плюсы и минусы от переменной суммы и постоянной абонплаты в 1 грн.

[olegotek]

Минус в том что за месяц получается плата с копейками или с лишними гривнами в зависимости от количества дней в месяце. А задача состоит в том чтобы клиент оплатил именно круглую суму, например ровно 50 грн. и каждый месяц.
При такой системе если клиент отключится или переведется в середине месяца, то билинг дальше будет посуточно считать по новому тарифу: если заблокирован - тогда 0грн в сутки, если дороже/дешевле тариф - тогда по новому за каждые сутки. Только тогда можно будет открыть доступ клиентам для выбора тарифа заблокирован или дешевле. Кстати так и не увидел раз'яснения как учтет билинг переход клиента 25 числа с тарифа за 200грн/мес на тариф 100грн/мес. Проделая такой експеримент с клиентом видим что ему нужно оплатить в конце месяца всего 100грн, потому что списания средств со счета происходи вконце месяца.

[stix]

Дело не в том что мы прицепились, а в том что даже провайдер ошибается сколько ему платить надо в месяц, что говорить о пользователях, которые 5 на 2 поделить без калькулятора не могут.
Еще раз опишите плюсы и минусы от переменной суммы и постоянной абонплаты в 1 гр

Сорри, спешил, поменял случайно цифры местами, сами же прекрасно поняли )

Давайте вот не будем думать, что думают юзеры.
Плевать на то что они думают.

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

Повторю, хотя бы для коммерческой версии, если вы думаете, что кругом собрались халявщики с 50-ю абонентами

как учтет билинг переход клиента 25 числа с тарифа за 200грн/мес на тариф 100грн/мес

эксперимент показал, что ему докинутся на счет эти 100 грн

[olegotek]

как учтет билинг переход клиента 25 числа с тарифа за 200грн/мес на тариф 100грн/мес

эксперимент показал, что ему докинутся на счет эти 100 грн

Продолжу... 100 грн вместо того, чтобы на счету у него осталось разницы где-то 19грн.

[stix]

как учтет билинг переход клиента 25 числа с тарифа за 200грн/мес на тариф 100грн/мес

эксперимент показал, что ему докинутся на счет эти 100 грн

Продолжу... 100 грн вместо того, чтобы на счету у него осталось разницы где-то 19грн.

т.е. как я понял логическая проблема при переходе с повышенной абонплаты на меньшую из-за того, что возвращаются деньги, хотя поидее не должны.
имеем 201 грн налом:
скорость 100мбит с 1-25 тариф за 200 грн, на балансе - 1 грн
скорость 128 кбит с 25-31 тариф за 10 грн, на балансе - 191 грн
хотя с 1 по 25 человек получал услугу 100мбит, заплатил почти в конце месяца всего 10 грн.

olegotek, я правильно уловил мысль?

поидее нужно значит хранить буферное значение до момента перехода с тарифа на тариф, и вычитать его при смене с тарифа, т.е. за 25 дней по тарифу 200 грн в месяц и с начала работы нового тарифа снять еще 10 грн

[Aivanzipper]

Да, серьезный вопрос!! Срочно решать надо!!!!!

Лично мне хватило бы блокировки возможности заказывать пакет с меньшей ценой. Думаю, сделать это не сложно.

[versus]

Эм.... а с каких это клиенту мы даем метатся между пакетами в оплаченом месяце Работа идет только по предоплате!!!
Клиент в статистике заказывает пакет на следующий месяц!!! Если вы переводите клиента в ручную с интерфейса администратора, то вам и флаг в руки. Если человек ошибся в первый день месяца перешел не на тот пакет, то позвонив админу, админ может или решить проблему переводом человека на другой тариф, тогда есстественно ему пересчитывается тариф, либо не решать проблему и сказать дарагой ты уже полмесяца на 100 мегабитах. Деньги в любом случае УЖЕ сняты!!!

По поводу суточной оплаты не вижу плюсы и минусы от текущей реализации единой суммы суточной оплаты.
Я свои доводы уже высказал и пока не увижу нормальной аргументации, кроме ХНЫ ХНЫ ХАЧУ, не дам фичу в разработку, отрывая разработчика от ядра 52 версии. 

Да и кстати 31*0.65 = 20,15 грн 31* 0.64 =19,84  где тут круглая сумма ?? или у вас дробные копейки в обиходе ? У нас нет.
Вот и получаем что или перебор или недобор да еще и помнить клиенту надо что в этом месяце я плачу 65 копеек а в следующем 63 копейки, а в фазе луны новолуния 89 копеек, потому что недобор средств.

И кстати вот оно маркетинговое чудо, спорят тут о том что клиенту платить надо пропорционально и в тоже время плевать на мнение клиента.. Ох уж эти маркетоиды....

[stix]

Да и кстати 31*0.65 = 20,15 грн 31* 0.64 =19,84  где тут круглая сумма ?? или у вас дробные копейки в обиходе ? У нас нет.
Вот и получаем что или перебор или недобор да еще и помнить клиенту надо что в этом месяце я плачу 65 копеек а в следующем 63 копейки, а в фазе луны новолуния 89 копеек, потому что недобор средств.

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

[Aivanzipper]

Эм.... а с каких это клиенту мы даем метатся между пакетами в оплаченом месяце Работа идет только по предоплате!!!

Валентин, а для чего тогда сделана возможность указания суммы комиссии при смене пакета посреди месяца? Или вы пересмотрели свою идеологию?

Кстати скажу, это полезная возможность, но надо разрешить только ПОВЫШАТЬ пакет (по цене), тем самым зарабатывая еще больше!

[stix]

надеюсь в 52 версии будет изменена концепция, а пока временно запретил смену пакетов пользователями
ибо чтобы решить проблему с переходами на тарифы не позволяет грамотно суточная абонплата, а без нее - шаровой способ работать по минимальным ценам на максимальных тарифах

[stix]

сделал пропорциональную суточную абонплату.
так что уже не актуально.

актуален остается вопрос перерасчета перехода с большего на меньший тариф

[olegotek]

сделал пропорциональную суточную абонплату.
так что уже не актуально.

актуален остается вопрос перерасчета перехода с большего на меньший тариф

Поможешь брату по проблеме?

[stix]

если устроит такой алгоритм работы:
в первый день каждого месяца, скрипт делает выборку из БД на непустые значение программируемого тарифа (сделано для того, чтобы помесячные тарифы не трогать).
далее делается выборка значения тарифа, которое делится на количество дней, получаемое функцией которую написал на прошлой странице и это значение через sql update прописывается в базу данных.
хз, может это неправильно и костылями, но выбора нет.

может сделать отдельный топик по пропорциональной суточной абонплате?