Биллинговая система Nodeny

Подскажите пожалуйста, как реализовать следующий тариф?

Стоимость тарифа 90 гр в мес.
абонплата в сутки 3 гр

чтоб у абонента каждый день минусовалось от 90 по 3 гр в сутки

Ну как разобрался?

Операции - настройки - тарификация:

галка на "Включить режим посуточной абоненской платы"
там же "Абонплата в сутки" = 3

Открываешь клиента и ставишь галку в параметре "Посуточная абонплата".

спасибо, разобрался

      Ето получается фиксированная плата для всех абонентов которые отмечены, и у всех на разных пакетах получается одинаковая суточная абоплата.
      А возможно реализовать так, что-бы у например безлимитных пакетах, каждый день снимало абонплату из расчета: стоимость пакета разделить на 30 дней, то есть при стоимости 60 гривен, будет сниматься 2 гривны, а 90 гривен - 3 гривни каждый день?

пока неполучится

А возможно ли это реализовать в следующих версиях ?

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

как оказалось есть такая необходимость у меня в сети )

Нашел программиста который за 50$ = 300 грн сделает данный функционал. Есть желающие оплатить разработку для общего блага??  можно скинутся донейшенами.

$50 это далеко не 300 грн :)
А какой конкретно функционал будет реализован?

Программист украинский, который согласился с тем что 6 грн = 1 бакс, как написано у нас на сайте
Конкретный функционал описан несколькими постами выше:

А почему на 30 дней? Есть же месяца и по 31 дню, и по 28 :) Второй момент: если стоимость пакета 70 грн в месяц, то ежедневно надо снимать 2,(3) - 3 в периоде, до какой степени округлять это число? чтобы сумма снятия за месяц стыковалась со стоимостью тарифного плана

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

Готов скинуться на разработку, звоните 80636007719 Женя.

что-то в этом определенно есть

А некоторые именно этого функционала и ждут.  Ну и ещё пожалуй возможность авторизации ip+mac.
Ибо на данный момент стоит биллинг который очень удачно считает безлимитные тарифы посуточно.
Пример: Тариф 5Мбит 400руб./мес. Суточная ставка будет 400*12/365=13,1506руб./сутки.  Пользователи привыкли,удобно.....другого им ненадо(а клиент всегда прав).

а что за биллинг щас стоит?
p.s. ip+mac - это не есть способ авторизации :) но вполне можно такое сделать )

если на свиче по Ip+mac, то можно по радиусу, наработки есть. Мы это уже неоднократно обсуждали

802.1х ? лучше не напоминай об этом :) это очень неправильно и глючно
начнем с того, какие soho-роутеры умеют .1x ?

ASUS WL500g ;)

Да Асусы наверняка умеют,но как быть с теми которые НЕ умеют?   Не скажешь же абоненту "простите,но из-за наших нововведений вам нужно купить новый роутер"  ;D

Да мы вкурсе что ip+mac это очень дырявое решение и мы готовы постепенно перевести всех на скажем DHCP+opt.82 ну и порт секьюрити к примеру(PPPoE так же как и VPN уже не приживётся судя по опросам) . Проблема в том что сразу перевести всех нереально т.к. абонентов уже далеко не 100,200.


Сейчас у нас стоит виндовое решение Траффик Инспектор. Нареканий впринципе нет.  Но к сожалению его производительности хватает не более чем на 150-200Мбит в которые мы собственно и упёрлись.

В каком виде сейчас осуществляется привязка mac+ip?

Клиент получает ip по DHCP в DES-3526 его ip+mac скриптом по snmp заносится в IMPB(IP-MAC-PORT-BINDING)

В биллинге авторизация идёт всё по той же связке ip+mac

дык DES-3526 умеет же option 82! нафиг вы людям мозги парите :)

Все говорят о мифическом Option82 но никто так примера конфига и реального использования в связке с нодени не привел:)

а в чем проблема? не вижу никакой проблемы :) фрирадиус в помощь :)

Всё верно.   К сожалению сеть изначально строилась не на 3526...   Большинство были мыльницы)
И вот сейчас уже перестроенная сеть позволяет использование опт.82. 
Если НоДени позволит авторизировать клиентов с помощью неё,то можно будет смело начать переход.  Хотя есть ещё вопросы по платёжным системам (у нас их 4-ре)+нужен АПИ для получения данных (свой информационный портал статистики абонентов).

ну строго говоря, опшн 82 - это не совсем авторизация :) но можно спокойно использовать совместно с нодени )
а какие 4е платежные системы?
АПИ = мускуль - с него можно любые данные очень даже просто вытянуть

Платёжные системы(терминалы)  "Свободная касса","Кассира.нет","НОВОПЛАТ","money-money".   Сейчас всё реализовано через скрипты php.

ну дык перенести их в nodeny будет проще простого :)

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

да, не плохо было-б

Сейчас разрешился вопрос с суточной абонплатой?
Актуальная функция очень, без нее тяжело полностью перейти на NoDeny

так скоко нас народу есть ? давайте скинемся и точка на етой проблеме !

Можно ставить фиксированную сумму для тарифа.
Но без учета 1/31, 1/30

как?

Операции>Тарифы>выбираешь свой тариф, листаешь в самый низ.

Программирование поведения тарифа
9:xx - суточная абонплата в размере xx грн.

если я выставлю 9:3  то у клиентов посуточно будет снимать по 3грн. ?

А чего не потестить и потом отписаться на форуме?

Да, только здесь разная концепция суточной абонплаты.
Есть суточное вычитание из общей суммы абонплаты.
А здесь константа вычитается

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

ем. я понял так : если я пробю скажем в тарифе за 90 грн. программирование трафика на 9:3 то у них будет снимать по 3 грн. каждую сутку . а что произойдет вконце месяца ??  скрипт newmonth.pl срежет потом полностью стоимость тарифа ? 

делаешь тариф, присваиваешь себе и тестишь без всяких красных телефонов

Зачем ты обижаешь автора? Думаешь он ен предусмотрел ситуацию с тем что есть посуточная абонплата в скрипте перехода ??
константное значение посуточной оплаты было насколько я помню заказано при разработке модуля. Пропорциональное никто не заказывал это раз, во вторых если делать пропорциональное, тогда в чем отличие от абонплаты за месяц! Помоему тут как раз верен принцип продажи в розницу и оптом, хочет клиент посуточную, пусть оплачивает больше, за то что берет в розницу, оплатит за месяц. будет цена как за мелкий опт ))
Цель предприятия- заработать денег, чем больше тем лучше. Это достигается увеличением продаж, уменьшением связанного капитала и уменьшением затрат для перевода связанного капитала в продажи. Вот от этого и исходи при еедневной абонплате! 

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

Давай думать логически, пропорциональная ежемесячная оплата только снижает поступление денег. Т.е. Клиент кинул на счет 9 грн  выгреб их и вырубило. какой смысл в том что бы вводить пропорциональное снятие ??? АРПУ уменьшается, стоимость клиента растет, окпуаемость и рентабельность падает. Смысл ???? Жопку клиенту лизнуть ?? Так сколько не лижи клиенту все мало. Надо действовать жетско, например тариф 50 грн ставить 3 грн ежедневки, таким образом хоть потери компенсируем от падения уровня продаж.
Ох уж эти маркетологи.... Учитесь у гигантов, например Яблоко 3 раза за 5 лет продал модификации своего Я-телефона своим фанатам. Если б он сразу все функции включил, кому б надо было менять совершенный телефон на что то еще ??

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

Вполне нормальный вариант в нашей системе начислений. Берем 50 грн в месяц, и 20 грн повторное включение. Если клиент отключился и хочет сделать паузу - без проблем - 20 грн при повторном включении или если на пару дней или даже неделю то ему не выгодно и он НЕ ОТКЛЮЧАЕТСЯ. Таким образом клиенту становится вигодным только отключение на 2 недели и больше.

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

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

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

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

Это хорошо только если переход на тариф подороже, а если на дешевле - тогда хохма - человек был на 200 проработал до 25-го числа, в конце месяца выбрал 100 и оплатил 100 ЗА ЦЕЛЫЙ МЕСЯЦ, это разве биллинг!? Это попадалово. Поэтому переводы в середине месяца возможно делать только на тарифы дороже и то делать этого никто не будет, то есть платить за то что не было использовано.
Ну а если клиент отключился не в конце месяца, а например 4 числа, по-моему нечелоевечно ему считать целый месяц, тогда как? Далее если отсрочка платежа стоит до 5-го. Тогда он может не платить ни за 4 дня потому что отключившись перейдет в заблокированные, и история о том что он был работал уйдет в бытие, ни за месяц, а я хотел бы чтобы он при повторном подключении оплатил свои 4 дня. Подсумировав видно что биллинг идеально настроен для тарифов помегабайтной оплаты, но никак не для безлимитов!

Только что вы прослушали фантазии человека, который не потратил время на изучение нодени и его возможностей имеет сеть в размере 100 человек и имеет мнение о работе сети в несколько тысяч абонентов. Шкала автоматики у вас по каким критериям построена ??

Хавтит принимать вещества, на ваши фантазии больно смотреть, тужится человек тужится, а оно вон как выходит в виде высеров.

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

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

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

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

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

Хотя дураки на чужих ошибках не учатся, надо своих шишек набить...

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

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

Получается цена а феврале ежедневно почти в половину меньше чем в январе.
Ура товарищи это прогресс!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сделал пропорциональную абонплату, необходимо тестирование, обращайтесь к Валентину

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

Валентин?

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

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

"наверное"... а пока юзеры читают этот форум и пользуются недолiками

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

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

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

Ну так и ставь абонку в "0" или же в тарифе нужно поставит галучку в "- для данного тарифа не осуществлять пропорциональное преобразование данных для новых клиентов, т.е. день начала потребления услуг будет установлен в ноль для таких клиентов" и небудет коэфициентов.

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

Логика такая. В поле "скрипты" тарифа появился код "8", который работает аналогично коду "9", за исключением того, что в нем указывается стоимость снятия не в сутки, а за месяц. Каждые сутки с клиента снимается (проводится соответствующий платеж) сумма равная стоимости в месяц/количество дней в месяце. Например мы указали абонплату в 31 грн. Клиент начал работать 28 числа. 28 числа с него спишется 1грн. 29го - еще одна грн. А 30 его заблокирует. Угадайте почему? Ладно, отвечу сам - потому что у клиента было всего 2 гривны на счету, остальное он потратил на пиво.

Круто!!!  :D Еще потестить надо!

Мысли вслух по поводу алгоритма суточной абонплаты. Задача:
Имеем тариф безлимит 50 грн/мес. Подключились 2числа, переходим на тариф 75грн/мес 11числа.
1. Всегда нужно помнить и обновлять переменную Х = количество запланированных дней в месяце на выбранном тарифе. Вначале месяца Х всегда = к-ву дней в месяце. Переменная должна обновится в случае изменения статуса клиента в разрыве месяца:
a)при отключении или для смены тарифа (У нас 11числа) в разрыве месяца Х стает равным к-ву дней пребывания на этом тарифе которое аккумулируется в отдельной переменной W. (У нас Х=11-2=9);
b)при подключении или после смены тарифа в разрыве месяца Х должен приобрести вид (У нас подключка 11числа)  Х=31-11=20 (к-во дней до конца месяца), W=1 .
2. Списание происходит каждые сутки в первую минуту 00.01ч. Сума списания = стоимость тарифа/к-во дней в месяце (У нас 75/31=2,41) проверяем и добавляем количество использованных дней W, и ждем когда оно будет = Х (У нас 31),
Каждый день аккумулируем в переменную Z каждое списание абонплаты только текущего тарифа.
3. 31 ... тут мы поймали 31=Х, производим списание абонплаты. Если абонент целый месяц был на одном тарифе всех интересуют лишние или недостающие копейки. Все просто. Пример2: при проверке если X=W, то есть в конце месяца (тариф50/31=1,61) снимаем не 1,61, а 50-Z=1.70грн.
Лог событий задачи:
2 число, баланс -1,61 W=1 X=29 (при стандартной формуле 31-2 первый день клиенту несчитается)
3 ... -3,22 W=2 X=29
10 ... -14.49 W=9 X=29
11 ... -16.10 W=10 X=29 после смены тарифа W=1 X=20
12 ... -18.51 W=2 X=20
30 ... -61,89 W=19 X=20
31 ... -64.30грн W=20 X=20 Z=64.30 оплата или списание с баланса. Баланс=0
1 ... -2.41 W=1 X=31
30 ... -72.30 W=30 X=31
W=31 X=31 W=X
31 ... -75.00 Z=75.00
Понятно что надо точить, но костяк думаю нормальный, на нем можно будет строить.

Осталось материально заинтерсовать программиста для реализации. Сколько то денег готов предложить ?

Извините, не совсем понял логику работы. Зачем указывать после кода "8" размер снимаемой суммы в месяц, когда я её уже указал в поле "стоимость тарифного плана".  :-\
Мы же не собираемся с вами 2 раза снимать плату (сначала разово, потом посуточно). ???
Де факто - зашёл в тупик с тарифом "анлим на 30 дней за 100 рублей" (Васе с 12го, а Пете с 22го). Включаю и выключаю пользователей руками, докидываю им суммы после снятия 1-го числа, если там не хватает денег, отключаю по блокнотику из верхнего ящика стола. И пользователей становится потихоньку больше, что неприводит меня в восторг. Что я делаю не так?

Извиняем. Теперь прочувствуй разницу между формулировками:
- указывается сумма за месяц
- снимается сумма за месяц

Все просто, модуль программирования тарифа отдельная платная еденица, она работает отдельно от общего модуля тарифа, поэтому для реализации функционала есть 2 варианта, задействовать основной модуль  или задействовать модуль программирования поведения тарифа. Если мы внесем в основной модуль, то часть модуля программирования тарифа надо добавлять в основной функционал и следить за всеми вытекающими последствиями.Если вносить в модуль программирования, то необходимо передать ему сумму тарифа.Что и было сделано. Кстати а вы купили модуль скриптов ??



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

Нет, я пользую то что есть в открытом доступе. Если бы была озвучена цена на модуль скриптов, я бы скорее всего купил бы этот модуль для своей копии 49-ки. Даже ради своего анлима на 30 человек по ADSL модему...

Да, возможно я ещё не готов задать вопрос. :) Спорить не буду.

Подскажите как это использовать. Т.е. я должен обновиться до 50.32 + еще чтото поставить дополнительно или как? Модуль скриптов вроде как у нас лицензирован.

Сейчас стоит 50.31
Рядом с полем скрипты есть подсказка что можно использовать 9:XX
И есть стоимость тарифа выше.
Т.е. надо ставить стоимоть тарифа в 0 а в 9: ставить сумму в день?

Или если там стоит допустим как стоимость тарифа - 500 а абонентская 30 то в зависимости от галки в договоре будет снимать или посуточно или ежемесячно? Хотя чтото я галки не нашел тперь в тарифе.

Просто с этом количестве информации черт ногу сломит.

обновляйте биллинг, появится опция.

Вопрос по суточной абонентской плате.
Почемуто оно снимает деньги постоянно а не в те дни когда абонент пользуется.
ЧЯДНТ?
Или надо чтото подкрутить чтобы снимало только тогда когда у абонента есть хоть одна авторизация за сутки?

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

Т.е. надо ваять внешний скрипт или править текущую реализацию.
Спасибо, будет посмотреть.

Тут я не удержался и решил высказаться.
Вот смотри, допустим бы у оператора сотовой связи купил какой-нить пакет, оплата за месяц, ежесуточно равными долями. Ну скажем как у нас - прямой городской номер. Я плачу 20 центов в сутки. даже если у меня телефон вообще выключен, у меня абаненку в 20 центов всё равно снимут, другой разговор, когда баланс минусовой.
думаю это не целесообразно так уж сильно баловать клиента. У меня в сети, к примеру, народ и месяцами некоторые не пользуются(есть таких двое), они вносят бабло и знают, что у них в любой момент есть инет. Они платят свои 500 рублей за мнимый мегабит, почему мнимый, да потомы что я им скорочть режу с 18 до 24 в 2 раза, ну да не об этом.
Клиент совсем расслабится и сядет на шею, это же безлимитный тариф, с абаненской платой в месяц, а не в день. Клиент по договору должен заплатить скажем 500 рублей в месяц, вот и  пусть платит, а то что снимается эта абаненская плата каждый день, это совсем другая тема.

песши исчо!
p.s. не удержался :)

Форум предлагает открыть новую тему, но напишу здесь.
Есть небольшая сеть на 200 абонентов, сейчас используется Траффик Инспектор. Есть желание перейти на Нодени. В качестве эксперимента был выделен небольшой сектор клиентов, которых перевели на Нодени. Работаем и присматриваемся почти месяц.
Но появился вопрос:
(краткая преамбула - мы выиграли по кол-ву абонентов у конкурента введением посуточной оплаты. В тестовом режиме включили этот режим на Нодени 49.33. Видели предупреждение о необходимости покупки лицензии для включения скриптов, но исходя из количества обсуждений посуточной абонплаты хотели проверить - как оно работает. Отмена посуточной платы не приемлема.).
Собственно амбула: Подскажите, пожалуйста, в биллинге в событиях корректно отображается снятие абонплаты и т.д. Абонент блокируется при уменьшении строки "На счете с учетом стоимости тарифного плана" меньше нуля или лимита. А вот значение "На счету" не изменяется. Должно ли так быть? Возможно уменьшение "На счету" будет осуществляться после покупки лицензии? Или это какая досадная ошибка?
Это недоразумение вносит путаницу как самим клиентам, так и нам. Ведь мы перевели только самых нетребовательных и простых абонентов. А остались ещё сложные тарифы...

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

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

У абонента есть баланс - это сумма всех положительных и отрицательных платежей. Все эти платежи прописаны в базе в таблице платежей pays. Их сумма равна полю balance в таблице users. Я этот баланс называю либо "начальный" либо "баланс без стоимости услуг". Этот баланс не включает стоимость пакета в текущем месяце, поскольку эта стоимость не прописана в таблице pays. Почему она не прописывается? Потому что допускается изменения пакета и его условий в середине месяца. Как только наступает новый месяц, этот платеж попадает в таблицу pays и при этом изменяется баланс клиента.

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

Вышеприведенная абонплата работает несколько иначе - каждое снятие оформляется как реальный платеж, он попадает в таблицу pays. Следовательно "начальный" баланс должен уменьшаться. Запусти внутреннюю проверку - nodeny покажет несходняки балансов. Скорее всего несходняков не будет, что будет свидетельствовать, что абонплата списывается правильно. А если будут, то это уже надо разбираться... но такой баг ни у кого не проявлялся...

Спасибо Efendy за помощь!
Проверка показала наличие ошибок у всех пользователей. Ошибки возникли поскольку изначально не совсем разобрались с бухгалтерской частью: остатки средств с другого биллинга переносили в Нодени и корректировали вручную (а не проводили платежом); несоответствие строк "На счету" и "На счету с учетом стоимости тарифного плана" обусловливалось тем, что указывали и суточную абонплату и стоимость тарифного плана; не снятие денег при балансе меньше нуля сделали по подсказке 0xbad0c0d3.
Есть ещё один вопрос, но задам его в подходящей теме.