такая вот трабла.
у клиента стоит тариф с суточной абонплатой
тариф 160 грн
но в статистике пишется

Ув. абонент, вы начали пользоваться услугой с 27 числа, т.е. не полный месяц. Мы уменьшили стоимость тарифного плана и предоплаченный трафик: данные тарифного плана умножены на коэффициент 0.16
Цена, грн.   0.16 * 160 = 25.6
Итого к оплате, грн.   25.60

для тарифов с суточной абонплатой, нужно вообще ставить в 0 абонплату

Валентин так и не появился, потому новую логику хз

Помогите пожалуйста сделать проверку в скрипте чтобы была возможность заказывать только тарифы с большей стоимость

подожди новую версию, вроде исправят логику работы...наверное

Спасибо. интересно посмотреть.

Валентин?

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

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

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

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

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

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

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

как учтет билинг переход клиента 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 грн

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

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

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

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

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

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

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

общая сумма то не меняется
на 28 число она выйдет 20 грн

И каждый месяц объяснять клиенту почему в этом месяце он платит больше а в предыдущем платил меньше, особенно прикольно про февраль будет объяснялочка:
Ну эта панимаешь нам бабло надо за тариф отбить поэтому мы разделили 50 грн на 28 дней, а в следующем на 31 разделим.

нене, сумма будет одна и таже.
просто в разные месяцы будет меняться суточная абонплата.
например абонплата 20 грн.
в январе 31 день: 20/31 = 1.55
в феврале 28 дней: 20/28 = 0.71

цитирую юзера:

обычно остатка денег на счету хватает .. до получения ЗП, а на первое число месяца не всегда есть свободные деньги для пополнения... но это как известно проблемы индейцев )

По топику.
Не хотелось бы самому вбивать костыли в биллинг, но довольно просто реализовать через класс Date_DaysInMonth, модуля Date::Manip

Код:

use Date::Manip;
my ($m, $y) = UnixDate("today", "%m", "%Y");
my $days = Date_DaysInMonth($m,$y);
print "$days\n";

выведет количество дней

а если делать выборку из таблицы plans2, с поля price и делить ее на переменную $days, то получим сумму суточной абонплаты.
вроде не сложно, но костыли не хочется вбивать самому, чтобы не увалить биллинг

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

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

Смотри как получается:
Есть тариф за 100 грн и есть тариф за 200 грн
У человека на 20 число остается например ровно 100 грн с учетом того, что он был на тарифе за 100 грн, при переходе на тариф за 200 грн, у него будет не -100 грн, а 0, т.к. эти 100 грн, что брались за абонплату первого тарифа перейдут на второй тариф.

Следующий момент: клиент отключается в середине месяца или в первых числах, для таких моментов также как и для начала пользования услугами - сделан ввод даты и по коефициенту начисляется плата до конца месяца - так же сделать оплата от начала месяца до конца пользования услугами, к-во дней. Кстати именно из за отсутствия такой возможности становится СТРАШНЫМ перевод клиента в середине месяца на тарифний план (по рекомендации в инструкции) "Заблокирован", потому что после этого абсолютно снимается абонплата за текущий месяц. В результате мы не можем предоставить клиенту самому выбрать этот тариф и тем самым отключиться автоматически, а сами мы можем только либо вручную запретить доступ, либо назначить тариф заблокирован на слудующий месяц.

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

Абсолютно с согласен с вашим мнением насчет абонплаты
Но руководство требуют именно такого.
Сделал по среднеарифметическому значению аля 30+31/2, 28 пока исключение изза большой дельты.

сложно будет сделать режим пропорционального снятия абонплаты?
хотя бы для версии 50.хх