Накидайте примеров реализации извращенных тарифов

[TheUser]

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

[Magnum72]

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

у каких разработчиков ?

[Ata-man]

[friedrich]

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

Это вообще-то не сюда нужно адресовать, а побродить по сайтам провайдеров. И не админу заниматься, а отделу продаж. Те придумывают продаваемые и доступные пользователю схемы, ваша задача уже реализовать.

[xerurg]

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

жжоте, товарищ

[TheUser]

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

у каких разработчиков ?

У любых вменяемых

[TheUser]

Это вообще-то не сюда нужно адресовать, а побродить по сайтам провайдеров. И не админу заниматься, а отделу продаж. Те придумывают продаваемые и доступные пользователю схемы, ваша задача уже реализовать.

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

[friedrich]

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

Из основных моментов, на которые можно сделать упор и которых не хватает УТМ:

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

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

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

[TheUser]

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

Из основных моментов, на которые можно сделать упор и которых не хватает УТМ:

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

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

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

Отлично! Спасибо!
Жду еще примеров!

[jekahawk]

А УТМ не позволяет в принципе реализовать суточный тариф(?), суть которого в следующем:

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

Кто-нить пытался реализовать такое?

[Magnum72]

А УТМ не позволяет в принципе реализовать суточный тариф(?), суть которого в следующем:

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

Кто-нить пытался реализовать такое?

думаю если и возможно то только через костыль с использованием модуля хотспота

[hammer]

Последнее время пишу скрипты на Perl, которые работают непосредственно с БД биллинга (сейчас начинаю перебираться на С - исполнение таких бинарников заметно повышает производительность при значительных нагрузках) и при необходимости получают данные с другого стороннего ПО, чтобы составить аналогичные или более сложные тарифы. Потом прикручивать к мускулю (пострге) на исполнение через использование триггеров, по факту изменения поля в таблице (exec() ) и от crontab впринципе можно отказаться.

З.Ы. Если есть ещё тут люди которые стороннии скрипты пишут - есть вопрос - не кто не составлял для себя ПОЛНОЕ описание таблиц БД UTM5 - такая бы документация сильно уменьшила время, требующееся для реализации оразличных нестандартных для UTM функций.

[Mental Noize]

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

Скиньте ещё примеры извращённых тарифных планов Интересно очень

[Mental Noize]

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

Ваш тариф реализуется следующим образом: делаете 3 таблицы ip_traffic_borders. Создаёте админкой. Первая таблица оригинал все обычные дни. Вторая имеющая необходимые границы трафика. И 3-я с нулевой ценой. Ваш скрипт узнаёт соответствующие необычные дни (третий, пятый и девятый дни после полнолуния и дни лунных и солнечных замтмений) с какого нибудь сайта с лунным календарём и делает выхлоп этих дат и помещает соответствующее задание с этой датой в крон. Крон при наступлении этого дня переименовывает таблицы и делает SIGN_HUP процессу utm_core в этом случае происходит пересчитываение базы.
Соответственно в кроне будет появляться что то вроде

Код: Выделить всё

59      23      12       may       2008       root     /netup/utm5/bin/utm5_luntarif.sh anotherday
59     23      13       may       2008       root     /netup/utm5/bin/utm5_luntarif.sh mainday

Сам скрипт

Код: Выделить всё

#!/bin/sh

mysqld="/usr/local/bin/mysql"
path="/netup/utm5/bin/"
log="/netup/utm5/log/luntarif.log"
datex=`date`;

echo -n "${datex} $1 " >> ${log}
$&#123;mysqld&#125; -u utm51 UTM5 < $&#123;path&#125;/$1.sql >> $&#123;log&#125; 2>&1
echo >> $&#123;log&#125;

pkill -HUP -F /var/run/utm5_core.pid

Соответсвенно файл anotherday.sql

Код: Выделить всё

RENAME TABLE iptraffic_borders TO iptraffic_borders_mainday,
             iptraffic_borders_anotherday.sql TO iptraffic_borders;

mainday.sql

Код: Выделить всё

RENAME TABLE iptraffic_borders TO iptraffic_borders_anotherday,
             iptraffic_borders_mainday.sql TO iptraffic_borders;

Сам УТМ обращается к этой таблице только когда израсходован весь предоплаченный трафик и её можно абсолютно безболезнено менять под свои нужды в текущем времени. Всё это уже пройдено и обкатано провайдерами. В личном кабинете будет несколько классов трафика "входящий", отличающихся ценой. С обычным днём и днём халявы всё понятно. На халяве просто меняем созданные значения на 0. А в случае каждые 100 мегабайт дело интереснее. Нужен дополнительный скрипт который выдирает из базы значение скачанного трафика и исходя из этого динамически создаёт таблицу iptraffic_borders_anotherday с теми цифрами, с которыми будет справедливо распределение каждых 100 мегабайт. Но тогда для каждого абонента надо созавать свой тариф, чтобы бордеры не путались. Вот этот случай определения каждых 100 мегабайт выглядит не свосем красиво. Может кто нибудь подскажет более простое определение?