LanBilling динамический учётный период

[pchol]

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

Наверняка тут есть люди которые используют данный продукт "в продакшене".

Когда выбирали биллинг задавали много вопросов разработчикам, многого нам наобещали.

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

В следствии чего нужно выкручиваться как-то самим.

Кто какие схемы реализовывал для решения поставленной задачи ?

 

[Andy52280]

IMHO оптимальнее всего ежедневные списания арендной платы за сутки.

Клиентам удобнее. Блокировки проще обсчитывать. Менять тарифы можно в любой день и т.п.

При таком варианте отчетные периоды становятся анахронизмом.

[pchol]

Идея конечно хороша, но возникает пара но:

1) Абонент уезжая на выходные совершает блокировку учётной записи и у него перестаёт сниматься а.п.

2) Абонент меняет тариф на максимально скоростной, выкачивает что то , и меняет тариф обратно. Следуя логике ланбиллинга, я так понял что за смену тарифа с него ничего не возьмут, ибо он отработал на нём менее 12 часов, и при смене тарифа на другой произойдёт перерасчёт с возвратом средств.

[vitalyb]

pchol

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

 

[pchol]

Допилить можно всё что угодно.

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

У нас родилась лишь одна идея.

Прибегнуть к схеме схожей с сотовыми операторами.

То есть тарифы создать в виде тарифов типа "Услуги" внутри создать категории по названию тарифа + дополнительные услуги доступные этому тарифу.

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

Из плюсов видится отсутствие необходимости морочится с объединениями для смены тарифов.

[Andy52280]

1)Ну и отлично. Используйте это как дополнительный маркетинговый рычаг.

2)Не нужно ничего пилить - ограничение на частоту сманы тарифа есть в LB.

 

[terrible]

Учитывая особенности вот этого:

IMHO оптимальнее всего ежедневные списания арендной платы за сутки.

Клиентам удобнее. Блокировки проще обсчитывать. Менять тарифы можно в любой день и т.п.

При таком варианте отчетные периоды становятся анахронизмом.

И этого:

Абонент меняет тариф на максимально скоростной, выкачивает что то , и меняет тариф обратно.

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

[Andrei]

1) Абонент уезжая на выходные совершает блокировку учётной записи и у него перестаёт сниматься а.п.

2) Абонент меняет тариф на максимально скоростной, выкачивает что то , и меняет тариф обратно.

Я спрашивал разработчиков ЛанБиллинг - реализуется ли взимание платы с абонента за его действия в личном кабинете, например, за установку блокировки или смену ТП. Разработчики ответили - нет, не реализуется никак. Версия 1.9, 6 сборка. Кто-то прикручивал какие-то костыли поэтому поводу?

 

2)Не нужно ничего пилить - ограничение на частоту сманы тарифа есть в LB.

Где? Каким агентом реализуется?

 

+ запрещать менять абоненту тариф чаще раза в неделю или в 2 недели.

Как? "Доработать напильником"?

[Andy52280]

Версии меньше 1.8 живьем не видел. Так что в Вашем конкретном случае советовать не возьмусь.

Для текущей версии (1.9) этот функционал присутствует.

Смотрите тему базы знаний #45 <Дополнительные настройки клиентского интерфейса LANBilling 1.9> (Класс: Административный Web интерфейс АСР)

[Andrei]

Версии меньше 1.8 живьем не видел

сорри за опечатку - версия 1.9, сборка 6.

 

Смотрите тему базы знаний #45 <Дополнительные настройки клиентского интерфейса LANBilling 1.9>

Там всего лишь рассказывается как запретить/разрешить клиентами те или иные действия в клиентском интерфейсе. А как брать плату за эти действия?

[wed]

а из каких соображений вам нужен динамический расчетный период?

почему нельзя всех абонентов приводить к тому расчетный период это месяц?

[pchol]

Тем что

1) Пользователям это удобнее.

2) У всех провайдеров конкурентов это есть

3) Так было на старом биллинге от которого уходим. И заставлять пользователей переучиваться не хочется.

Edited October 31, 2010 by pchol

[chubais]

Тем что

1) Пользователям это удобнее.

2) У всех провайдеров конкурентов это есть

3) Так было на старом биллинге от которого уходим. И заставлять пользователей переучиваться не хочется.

Тогда LanBilling не ваш выбор, сами мучаемся.

[Dushes]

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

[Andrei]

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

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

[terrible]

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

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

[Dushes]

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