BiTel

Я правильно понимаю задачу? Если клиент блокирован (нет денег на счете), то пускать его только до страницы биллинга. Если деньги есть, то пускать его везде, но абонентку списывать только если он скачал >5Мб? Если все верно, то все это прекрасно делается в рамках существующей системы.
Нет денег - блокируем на файрволе/выдаем серый IP или аналогичное (reject to accept).
Есть деньги - разрешаем на файрволе.
При этом в привязках трафика не считаем трафик до внутренних серверов (dns, billing)

С возвращением из отпуска


Да, вы правильно понимаете задачу. Когда есть деньги - начислять абонентку после Х услуги (секунд/байт/т.д.)

Вы не правы, предполагая, что можно реализовать стандартными средствами. Почему? Основная проблема - невозможно определить факт наличия у договора суммы достаточной для начисления абонентки, т.е. нельзя понять есть деньги на абонентку или нет. Дебетовые абонплаты не приостанавливают договор, т.к. не видят стоимости абонентки "обернутой" условием начисления на основе объема услуги. Приостанавливать договор скриптом тоже не получается, т.к. Calculator, предсказуемо, так же не видит подобных абонплат.

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

Ну понятно, да, на момент начала месяца все счетчики по 0. Вопрос в другом - насколько я все же понял постановку вашей задачи, эти 5Мб как бы "защитная мера" от того, что клиент не пользовался услугой в данном месяце. А оно вам реально надо? Я предлагаю вообще не оборачивать абонентку в какие-либо условия. Просто начислять ее как обычно. И ограничивать доступ пользователя на шлюзе. Или вам такая схема не подходит? Но тогда хотелось бы понять почему.

P.S. Я в свое время использовал эти критерии чтобы определить суточную наработку. И деньги снимались за те сутки, когда абонент был в сети. Когда деньги на счету кончались, абонент блокировался.

Для того, чтобы показать, как отработают дебетовые абонплаты возьмем такой пример:
- Есть тариф с помесячным начислением "безусловно", т.е. абонентка начислится в размере 100% за весь месяц (сумма не имеет значения).
- Дебетовые абонентки закрывают/приостанавливают договор с 1-го июня.
- Клиент не пользуется интернетом весь июнь (причина не важна).
- 30-го июня он пополняет баланс, планируя начать пользоваться инетом с 1-го июля.
- Дебетовые абонентки открывают/активируют договор абонента и производят начисление абонентки за июнь.

За что начислилась абонентка, если клиент вообще не пользовался услугами?
Капитан, я не понимат




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

Извечный вопрос: что делать?

Предвидя предложения - отвечаю: нет, подневная абонентка не подходит.

Да, понял. Мы просто в этом случае изначально пошли навстречу пользователям и всегда списываем абонентку пропорционально. Но и разработчиков понимаю, делать не очень понятный костыль в виде "заглядывать" в последнюю ветку не получится. По этой вашей логике вы всегда в своем тарифе будете получать безусловную цену за месяц, независимо от ветвления. Возможно тут подойдет аналог "цена по умолчанию" из модуля Phone. Но, imho, наверное все же сделать ветку "java logic" будет гораздо правильнее. Кстати, в биллинге NetAMS, разработчики пошли именно по этому пути. У них тарифы - суть java классы. С биллингом поставляется набор каких-то базовых классов, а хочешь что-то "изощренное", пиши сам или заказывай у разработчиков.

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



Дык если бы цену можно было получить и вопроса бы небыло, но проблема в том, что Calculator не возвращает цену, в результате чего рассчитать планируемую абонентку невозможно

А снимать пропорционально периоду чем не устраивает ? Пусть заплатит за 30-е число только .

Изначально хотел написать про ситуацию, когда абонент был приостановлен с 1-го числа, а 30-го, в 23:59 (он педант и по часам засекал) положил деньги на счет, но подумал, что это уж как-то слишком и время исключил

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

Я думаю, что как-то выкрутится можно, если бы можно было составить тариф такого вида (считаем что в месяце 30 дней):
- при подключении/активации в первые 15 дней, т.е. с 1-го по 15-е снимаем абонентку безусловно и даем max скорость до конца месяца
- при подключении/активации в оставшееся время, т.е. с 16-го по 30-е снимаем абонентку пропорционально периоду и даем скорость max/2 до конца месяца
Но как такое нарисовать в рамках одного тарифа я даже что-то не соображу

Подскажите, в Calculator можно как-то "влезть" в ветки дерева, чтобы можно было подсмотреть абонентку? Если это возможно, то его можно было бы использовать в скрипте, который приостанавливал/активировал абонентов и дебетовые абонентки тогда не нужно было бы трогать, т.к. у многих на них все завязано. Если это не возможно, то скажите - там много пилить надо?

А если добавить ветку в NPAY с названием, например, "Дебетовая блокировка", которая будет пускать внутрь только, если это задача блокировки по дебетовым абонплатам (или наоборот, только если это обычное начисление)?
В Inet уже есть, в NPAY просили, но все руки не доходят. Хотя мы не очень рекомендуем их использовать, только если действительно знаете, что делаете, т.к. в тарификации нужно много что учитывать (тот же переобсчет, например) и производительность важна.

Если это сделать, то у многих людей все поломается, пока они абонентки в ветку не перенесут

Я думаю, что есть смысл допилить Calculator. Почему?
- Сейчас я прошу, чтобы он видел абонентки зависящие от наработки, а завтра кто-нить попросит, чтобы он видел абонентки пропорциональные количеству телефонов, логинов и сервисов (мне кажется, что телефонисты будут одними из первых).
- Если Calculator будет видеть все разнообразие абоненток (пусть и с ограничениями), то это позволит реализовывать скриптами почти любую логику.
- Не придется ломать основной тарификатор, чтобы у людей все работало в прежнем режиме.

А почему поломается? Вам нужно, вроде как, чтобы задача блокировки думала что нужно снимать 500 руб, даже если еще нет наработки (т.е. нет на счету 500 рублей - блокируется, есть - разблокируется), а задача начисления начисляла только если есть 5Мб.

Сорри, я немного не правильно понял, как это будет выглядеть

В "дебетовая блокировка" можно будет просто добавлять клонов из начисления? Если да - делайте!
Может добавите туда возможность указания расходов, т.к. думаю, что это попросят.

Попутный вопрос - как запретить дебетовым абоненткам производить начисление, при открытии договора?
Чтобы избежать описанной выше ситуации.

А задача дебетовых абонплат, которая меняет статус договора на активен/приостановлен, вроде бы, ничего не начисляет.

Пардон, не верно выразился
Тут:

Это можно как-то отменить или, если вы добавите узел "дебетовая блокировка", начислений не будет, т.к. нет объема?

Сумму из "дебетовой блокировки" можно будет получать с помощью API?

Вообще есть идея сделать как-то так:
- Один раз, при запуске этого механизма, ставим всем договорам статус "приостановлен" с 1-го числа месяца.
- В момент 1-го подключения, скриптом на событие учетного периода, проверяем достаточно ли денег на счету. Если денег достаточно - проставляем даты учетного периода и, заодно, устанавливаем договору статус "активен" с даты 1-го подключения и по конец месяца. На следующий месяц статус выставляется в "приостановлен", до нового запроса учетного периода.
Дальше система работает сама, в автоматическом режиме.

Как вы считаете - можно ли так сделать? Правильно ли это? Может можно как-то более изящно, что ли?