BiTel

а если клиент платит не ровно на 30 дней а больше, например 450 руб за 45 дней, когда проверку делать через 30 дней или когда бабки закончаться?
а если клиент положит 300 руб, а потом в течение этих 30 дней будет докидовать небольшими суммами?
или это условие должно срабатывать только если клиент допустит блокировку баланса по недостатку средств?

Я думаю, что подобная схема работы дебетовых абонплат будет нормально работать только на абонентках с авансовым начислением. Почему? Возвращаясь к примеру выше (абонплата 10 руб/день и месяц в котором 30 дней): абонент кладет 28-го числа 300 руб., мы _сразу_ снимаем со счета 20 руб. в текущем месяце, оставшиеся 280 руб. так же _сразу_ снимаем за следующий месяц - в результате этого у абонента стоит статус "активен" с 28-го по 30-е число текущего месяца и с 1-го числа и по "кол-во дней на сколько хватит абонентки" следующего месяца (может плавать в зависимости от тарифа на след. месяц), что дает абоненту возможность спокойно работать, но при этом, чтобы возобновить работу в следующем месяце ему необходимо опять положить 100% абонентки согласно действующего тарифа.
Подобный метод начисления устроит и абонентов и, что не маловажно, операторов.

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

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

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


Провайдеру выгоднее, когда абонент платит большими суммами, а не приносит 10 рублей 1 раз в неделю, именно поэтому до сих пор живут и здравствуют помесячные абонентки с безусловным начислением. Я же предлагаю реализовать механизм, который будет выгоден и провайдерам, т.к. они получают сразу всю сумму абонентки, и абонентам, т.к. они получают услугу в рамках тех денег, которые заплатили.
Основные моменты:

• Открытие договора только при наличии суммы >= абонентки за весь месяц.
• Снятие всей суммы как за текущий месяц, так и за следующий.
  Если человек в текущем месяце, пусть это будет "ноябрь", т.к. там 30 дней, положил 450 руб., а у него тариф 300 руб/мес, то мы снимаем 20 руб. за оставшиеся 2 дня текущего месяца, затем 310 руб. за "декабрь", тем самым оставляя абоненту аванс в 120 руб. (450-20-310), которые в январе он может потратить, а может и не потратить, будучи, например, в отпуске. Если же абонент в "декабре" возжелал другой тариф - снимаем деньги согласно этого тарифа тем самым либо оставляя у него на счету больше денег, если тариф дешевле, либо давая ему проработать меньше дней, если тариф дороже.
  Дальше следующего месяца в будущее заглядывать не стоит, т.к. проще оставить у абонента на счету некий аванс, чем потом с ним ругаться.

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

1) много чего клиентов или тарифов?
2) т.е. если у клиента на счете 300 руб и он еще понемногу докладыет, это плохо для провайдера... лучше когда клиент все выберет до нуля и принесет очередную пачку денег. Странно, видимо я чего то в этой жизни не понимаю.... (чем плохи 10 руб в неделю, если на счете есть 300 руб)

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

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Тарифов и способов тарификации в оных.



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

так я об этом и говорил....
весь вопрос в том как снимать абонплата каждый день по 10 руб или сразу за 30 дней
1) если каждый день, то после внесения 300 руб этого хватит на на 30 дней (по 10 руб в день), при этом если в это период клиент закинет на счет еще некую сумму (например 100 руб), то у него денег хватит уже на 40 дней и т.д. но стоит ему допустить ситуацию когда на очередную(дневную) абонентку не хватает, договор блокируется и для разблокировки нужно внести снова минимум 300 руб.
2) если абонентку снимать сразу за 30 дней, и потом отслеживать когда эти 30 дней кончатся и пытаться снять следующую абонентку за 30 дней, то тогда если клиент пополнил счет на 100 руб, его заблокирует через 30 дней, пока он не пополнит счет на сумму минимум 300 рублей (месячная абонентка)

Я считаю что второй вариант хуже и для орераторов и для клиентов и для нас (хз как это реализовывать).

А в чем проблема отслеживания? Когда абонент принес сразу 300 рублей, то его статус стал активным сроком на 30 дней:
- Если по истечении 30 дней он не пополнит баланс - его заблокирует и для разблокировки он должен принести 300 рублей.
- Если он в течении 30 дней пополнял баланс небольшими суммами и при этом набрал 300 рублей, то мы точно знаем дату окончания разрешенного срока работы и абонентку будем начислять только тогда. В момент когда он активен его не нужно блокировать при поступлении на счет любой суммы, т.к. он уже принес деньги и модулю нет нужды о нем заботится до того момента, когда не наступит срок >= начисления новой абонентки.

проблема в том, что в этом модуле нет механизма отслеживания, и он там не предусмотрен архитектурно.
можно начислять каждый день или начислять раз в месяц (в конкретный день, например 1 числа месяца), но по вашей схеме этот РАЗ у каждого клиента РАЗНЫЙ да еще может плавать (если клиент задолжал на пару дней например)
поэтому я и предлагаю схему по которой можно сделать примерно то что требуется, средствами которые есть в модуле.

Модуль же видит статусы и даже сам их ставит - вот пусть на них и ориентируется, или это не реально?
Да, статус можно выставить руками, но я почти уверен, что в модуле нет защиты от дурака и если кто-то выставил статус руками, то он ССЗБ.


Если вспомните, то тут периодически просят т.н. "плавающий/скользящий месяц" (Ростелеком юзает и мне абоненты переодически об этом напоминают в различной форме), а там как раз и получится, что у каждого "свой" месяц и задачу начисления всяко придется запускать 1 раз в сутки.


Мы оба много чего писали, поэтому, пожалуйста, давайте конкретизируем что именно можно сделать "сейчас" малой кровью.

использовать дневные абонплаты + скрипт разблокировки договора (после блокировки) с условием внесения на договор не менее определенной суммы.

это позволяет реализовать схему когда чел приносит по 300 руб в месяц и пользуется 30 дней, если к 30 дню он пополнит договор на 300 руб то получит еще 30 дней не пополнит, договор будет приостановлен до тех пор пока он не внесет 300 руб

Если вас не затруднит, не могли бы вы в вики выложить howto с полным текстом такого скрипта для 6.0, чтобы ikoctya или кто-то другой, у кого возникнет похожая проблема, мог простой копипастой получить требуемый функционал?

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

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

у меня есть с подневным режимом снятия до текущего дня, и штраф полная абонка за месяц
нннада?

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Спасибо, мне пока не надо, т.к. подневные абонентки у меня только в планах, да и то если утвердят.
Я тут больше о тех у кого со скриптами туговато беспокоился.


Надо как нить подобрать время и созвонится - расскажешь как это работает, может и понадобится

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Именно это и нужно.

имхо, запилите мой скрипт в систему

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

а че, писали его вы всеравно )))))

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Код не запилят, если его писал не dimOn, т.к. у него:

_________________
Сервер: вер. 7.0.1277 / 23.10.2017 21:20:55
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_101
BGCRM v 3.0 build 1209 from 18.10.2017 06:00:42