BiTel

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

В том виде, как оно есть сейчас, все это делать можно. Скриптами. Но получается как-то идеологически не выдержанно.
К примеру, добавили новый тариф. На этом тарифе должны быть определенные параметры (к примеру скорость в IPN). Чтобы это заработало, надо править скрипт. Или использовать специфические имена тарифов. В общем, "через задницу".
Хотелось бы иметь возможность все это делать (при имеющейся поддержке в скриптах) редактируя только тарифный план.

В общем, предложение. В дереве тарифного плана сделать ветку "Параметры". Также фильтры по времени и типу времени (как на IPN).
Ну и функцию ПолучитьПараметрТарифа( ИмяПараметра, ДатаВремя, Контракт, ЗначениеПоУмолчанию ). Последний параметр - если на всех тарифах контракта параметр не задан.
Тогда многие вещи будет очень легко не только делать, но и изменять. Надо изменить скорость - пожалуста. Надо ночью - пожалуста. Надо запретить (разрешить) работу в определенное время - пожалуста. И т.д.

Возможно это будет сильно сложно... Подумайте плиз...

ну как раз именно это сейчас и делается в транке . Для IPN там есть отдельная ветка - "установка правила " , функционал пока не готов . Нечто подобное нужно сделать и для Radius - атрибутов .

А не IPN ?
К примеру, по таймеру надо что-то делать. При этом логика должна зависеть от тарифа.
// 1го числа проверить, есть-ли на балансе сумма для оплаты текущего тарифа. Если нет - перевести на бесплатный.
// Удобнее брать эту сумму из тарифа, а не вводить жестко в скрипте.
Жестко привязывать к коду тарифа - это надо для каждого нового тарифа править обработчик.
И чтобы изменить логику - опять править.

Просто есть люди, которые занимаются тарифами. И есть программисты, которые занимается скриптами.
Если в тарифе можно будет добавлять произвольные параметры (хотя-бы строковые), то можно будет делать более универсальные скрипты. И менять логику работы только изменяя параметры в тарифе.

Просто удобнее. И прграммисту и менеджеру по тарифам (ценам). Б'ольшая свобода действий, б'ольшая надежность (меньше правок скриптов). Больше личной ответственности. Больше независимости в работе.

Я не совсем понял про таймер и логику . Как это будет работать ?

В данный момент у нас сделано так:
- Клиенты сами выбирают себе тариф (помегабайтный или один из безлимитных) из доступной группы.
- Начисление за безлимит сделано отдельной услугой "Безлимит" в модуле "Абонплаты".
- Начисление услуги "Безлимит" происходит в 00:30 ежедневно (снятие денег - сумма "Безусловно").
- Ежедневно, в 00:05 запускается скрипт. Его логика (кратко):
(если тариф у клиента начался сегодня или сегодя 1е число) и текущий баланс меньше стоимости тарифа, то делается переход на обычный тариф - закрытие тарифа или удаление, создание нового обычного или удвляется закрывающая дата у прошлого тарифа.

По-простому - переход на б/л тариф если есть деньги и нет перехода если денег нету.
Запускается эта проверка каждый день. Стоимость каждого тарифа жестко прописана в скрипте (в отдельной библиотеке - так проще).

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

Ну и т.д., потребности могут быть разные.

у нас есть правила в iPN, есть атрибуты radius -в dialup . А вы хотите еще какие-то параметры для Абонплат в тарифах, чтобы их считывать из скриптов?

dialup не подходит.
В IPN нет авторизации по имени-паролю. Авторизовать по порту не можем - нет нужного железа (в планах).
Пришлось "городить огород" с программной авторизацией. Т.е. скриптовый шлюз IPN просто пишет параметры клиента, нужные для авторизации и открытии роутера, в базу. А дальше - не забота БГБ. Дальше своя наработка. У клиента Интернет-агент аля "Трафик Инспектор", и дальше серверная часть управляет роутером на линуксе.
Задача БГБ - в базу (дополнительная таблица) надо записать IP клиента, скорость, группу шейпера, параметры авторизации и пр.

Правила в IPN... А если изменился тариф? Пользователь сам сменил, к примеру. Шлюз остался, все параметры остались. Изменился только тариф. Обрабатывать событие изменения тарифа и менять правила на шлюзе? А если надо поменять какой-то параметр всем у кого определенный тариф? Допустим, "жест доброй воли" - вместо 512кб/сек сделать 600кб/сек...
Ну и как это "гладко" выковыривать? Вот и приходится плясать от ID тарифа. Как вариант - можно анализировать название тарифа. Но не фантан... Учтите, что эти параметры нужны не только при обработке шлюза.

Если будет возможность иметь в тарифе произвольные параметры - упростится все очень сильно. И удобнее будет.
Ну и использовать это можно где угодно. Хоть в обработке событий, хоть при обслуживании шлюза, хоть в dialup, хоть в IPN, хоть в телефонии. Да в любом модуле можно задействовать...

Это позволит легко реализовывать различную логику поведения в зависимости от тарифа. Без привязки к какому-то модулю... Т.е. гибкость.

Т.е вам правил ipn не хватает, вы хотите нечто подобное чтобы было глобальным и не принадлежало конкретному модулю, чтобы обрабатывать это где-то в скиптах по своей логике .. пока необходимость таких глобальных опции все равно не ясна до конца

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

Вот такая "имитация" параметров тарифа. Банальный switch.

И если добавляется (изменяется) тариф, то все это надо править...