BiTel

Здравствуйте.

В настоящий момент наша компания в качестве биллинга использует Netup UTM5. Кол-во абонентов более 6 тыс, и идет стабильный рост, в связи с чем предпологается переход на другой биллинг.

В настоящий момент тарифы на предоставление услуг Интернет следующие:
1) Оплата по трафику (пример: до 1Гб стоит - 0,5 руб, выше - 0,3 руб)
2) Оплата по трафику с предоплатой (примерн: абонплата 300 руб, выключено 1Гб трафика, превышение по 0,25 руб)
3) Условно-безлимитные тарифы, с ограниченим скорости (пример: 500 рублей абон.плата, включено 10Гб на скорости 512кбит/сек, при превышении трафика скорость снижается до 48Кбит/сек)
4) Безлимитные тарифы (пример: абон.плата 700 рублей, скорость 512кбит/сек)

Типы подключения абонентов:
- VPN PPTPD (несколько серверов)
- Direct IP

Весь трафик проходит через общий роутер с Netflow, затем натится и отправляется в Интернет. Соотвественно подсчет трафика ведется через Netflow v5.

В компании разработана собственная система CRM и кабинет пользователя.

Теперь вопросы:

1) Возможно ли миграция с UTM5 на BGBilling (перенос лиц. счетов, подключеных услуг и тарифов)
2) Реализация выше названых тарифных планов
3) Использование плавающих месячных расчетных периодов (нарпимер по одной услуге расчет перид с 15го по 15го, а по другой с 01го по 01го каждого месяца) и как следствие разное кол-во дней в периоде в зависимости от месяца.
4) Различные способы оплаты услуг: Prepaid и Postpaid
5) Возможность реагировать на события биллинга внешними скриптами (блокировка/разблокировка пользователя, внесение средств, снижение баланса ниже порога и т.д.)
6) Возможность из внешних приложений управлять процессами в биллинге (добавление/редактировать абонента, подключение/отключение услуги, внесение платежей и т.д.)
7) Хранение детального трафика в файлах собственного формата (мы детальные файлы от utm5 парсим, преобразуем в удобочитаемый вид, и храним в архиве по принципу /data/YYYY-MM/DD/$account_id.zip) очень удобно в таком виде из обрабатывать и предоставлять абоненту
Возможность начислять разовые и переодические услуги. Например: вызов специалиста на дом, настройка оборудования, или переодическа плата за аренду постоянного реального IP и т.д.
9) Интерграция с 1С, интересует экспорт в 1С счетов, актов, счет-фактур, из 1С импорт платежей. Какие есть возможности вообще.

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

да , есть наработки уже .

да

да

да.

да

да, база данных открыта и описана , есть диллерский интрефейс.

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

да. модуль rscm

http://wiki.bgbilling.ru/index.php/Inte ... -BGBilling
http://wiki.bgbilling.ru/index.php/%D0% ... 0%A1_v.7.7

Интеграция идет со стороны 1с . Биллинг предоствляет интрефейс

Как и обещал еще вопросы:

1) Когда наши абонент подключется к VPN серверу, ему назначается реальный IP и пула адресов, нам важно что бы трафик этого абонента учитывался через Netflow, т.е. без использования Radius-Accounting, т.к. данный механизм всегда позволяет продемонстрировать абоненту потраченые объемы трафика. В BGBilling умеет так? т.е. динамический пул адресов для VPN, привязка полученого IP к услуге абонента (передача интернет трафика)

2) Каким образом ядро биллинга узнает, что мы внесли какие либо изменения в БД? Например обновили услугу абоненту или еще что-то.
[/quote]

Ребят, ну полистать то документацию хоть чуточку можно?
1. Биллинг может считать как по аккаунтингу, так и по нетфлоу. В случае с нетфлоу, трафик можно поделить на классы (инет, локальный, бесплатный и т.п.) Поддерживается и статичная привязка IP так и выдача из пула. Более того, абоненту детальная статистика по потребленному трафику доступна в личном кабинете.

2. В подавляющем большинстве случаев в базу писать ничего не надо, все операции можно проводить через стандартный интерфейс биллинга (HTTP(S) + XML), тем самым, который использует сам клиент биллинга.

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

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

Ну Victor правильно все ответил, если есть еще вопросы - пишите.

Спасибо за ответы.
Возник вопрос:

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

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

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

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

Возможно ли реализовать необходимую схему начислений за доп. плату? Без использования костылей в виде скриптов?

Вопрос спорный. Так как у клиента есть возможность потреблять услугу (он занимает например порт комутатора, служба поддержки дежурит, и т.д.), т.е провайдер несет определенные затраты, для того что бы клиент в любой момент когда захочет мог бы воспользоваться услугой, так что по ПРАВИЛЬНОМУ какая то абонплата должна начисляться всегда (ну это мое личное мнение)

Возможно все, вопрос цены и сроков. А встроенные скрипты - впринципе не костыль, позволяют обеспечить необходимую гибкость. Практически все крупные клиенты так или иначе ими пользуются.

в этот момент счастливые пользователи BGB улыбаются и приветливо машут руками пользователям UTM


скрипты в БГБ - это не костыль! это данная Вам разработчиками возможность сделать функционирование системы такой как Вы хотите, как Вам удобно ... костыль - это когда вместо того чтобы использовать родной для системы RADIUS Вы вынуждены использовать FreeRADIUS, а в БГБ любой скрипт - часть системы, и ни как не является костылем!

Тоже присматриваемся к bgbilling. Интересуют очень важные для нас моменты:

- Как я понял, возможность списывать абонплату с плавающим периодом (например, с 5 июня по 5 июля) есть. Возможно ли при наступлении очередного отчетного периода и недостатке средств на счете для полного списания платы НЕ списывать ее, а просто блокировать доступ абоненту к услугами? А при поступлении средств - в течение 1-10 минут списать абонентку и возобновить доступ?

Разумеется, если средства поступят позже, то границы учетного периода должны передвинуться на нужное количество дней. Если я заплачу не 5 июня, а 10-го - то в следующий раз должен буду платить 10 июля.

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

можно списывать но не средствами модуля Абонплат, а скриптами и расходами.

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

я так понял вам нужнто что-то вроде этого:
http://wiki.bgbilling.ru/index.php/%D0% ... reeBSD_MPD

Прошу сильно не ругаться, мне не ясен принцип лицензирования модуля абонплат. Группа (тарифный план) с абонплатой в которой 100 клиентов - и одинаковая для всех абонплата (100 руб в месяц) это лицензия на 100 абонплат или на одну???

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