BiTel

насколько я понял абонка - 20 рублей, подневная .. к утру 5-го числа , у абонентиа уже сняли 4* 20 = 80 рублей(за 4 предудщих дня) ..и осталась одна копейка .. пытаются снять еще 20 рублей и получают -19,99 рублей

2 Akhmat, а при смене тарифа , вручную менять минимальный платеж ?

2 stark
Пообщался с коллегами и на работе и на форуме. Ща оформлю алгоритм наиболее полно, и выложу.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

Итак:
1. При заведении тарифов и т.д. (для дебетных договоров) БГ сам высчитывает сумму абонплат и автоматически выставляет параметр договора"Требуемый платеж" в эту сумму. Желательно чтобы этот параметр был в таблице contract, и во вкладке договора высвечивался рядом с лимитом, т.е. был на видном месте.

2. При начислении абонплат смотрим

3 При поступлении платежа, после его добавления, выполняем полностью пункт 2.
4. Чтобы дать возможность клиенту поработать в долг, предполагается что вручную меняем статус договора + понижаем лимит если требуется на время. Тогда абонка не должна начислиться

Примеры
1. для месячного режима
Клиенту надо снять абонентку на договоре 3100р(т.е. "требуемая сумма" на договоре равна 3100.), вх. остаток 50 р.
В начале месяца у него остаток остался 50р. он стал "приостановлен"! Пополнил счет на сумму 3050, стал активен, снялась абонентка. все чики-пуки.

2. При ежедневном. Ежедневная абнонентка 30р. Соответсвенно требуемая сумма 30р. У клиента на начало месяца 50р.
При ежедневном идет недоразумение изза того что вх. остатком для ежедневного режима является исх. остаток на прошедший день. Потому условие начисления надо переделать из

на


И все должно быть супер пупер. Пока что дырок в логике не вижу.
А при смене ТП должен измениться "требуемый платеж", также с выполнением условий пункта 2.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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


прошу, прощения, но я по ошибке перетер последнее сообщение от Akhmat

Да, если на договоре несколько абонплат для различных услуг, в "требуемом платеже" хранится сумма
Во вторых
Если мы не разрешаем клиенту уходить в минус, и блокируем, то оператору биллинга требуется знать, сколько клиенту надо заплатить для разблокирования, плюс самому клиенту требуется знать в личном кабинете что ему надо столько то оплатить. Поэтому в клиенте биллинга(и в личном кабинете) отображаем рядом с лимитом "Требуемый платеж"/"Сколько надо доплатить до него"

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

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Сумма приходов уже есть в текущем балансе.
Если мы ежедневно будем принимать решения о блокировке, то нам нужно будет хранить входящий и исходящий остаток на каждый день. Иначе как потом разбираться, почему клиент не работал с такого-то по такое-то число? Сумма минимального остатка нужна, имхо. Во-первых, нужно отображать её клиенту, во вторых, она может вычисляться по сложным правилам, включая собственную логику оператора. Нужно дать возможность задавать эту сумму явно в скриптах + получать рекомендуемую биллингом.
Вообще, интересно, как эта логика реализована в других биллинговых системах.

Может наоборот? "Кредит" является частным случаем "дебета", а в БГБ сейчас это не соблюдается?
Напомните, пожалуйста, как было в 4.4? Мы работаем с 4.3, но при прохождении через 4.4 дебет нас не интересовал.

Точно! Не учел. Ну мне до ежедневной абонентки все равно... Если сама идея нравится, подумайте как правильно. Там вроде несложно допридумать. Тогда можно просто

Вроде так получим то что надо.
Когда блокируем пишем в комментарий
"Недостаточно средств для снятия абонплаты: Текущий_баланс < Требуемый_платеж "
Както так.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Ну да, согласен. Потому, если мы её будем хранить в табличке contract, значит сможем её самостоятельно редактировать из скриптов. Ну надо ещё чтобы была функция стандартная, типа setRequiredPrepayment() которая сумму абонплат высчитывает сама.

Норм? Вам подходит такая реализация?

PS
Здесь я полагал что вы под "суммой минимального остатка" преполагаете "требуемый платёж".

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

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

Алгоритм следующий:
1) В 0 часов каждых суток запускается некий процесс планировщика, который оценивает текущий баланс и абонентские платы каждого _активного_ договора. Имеем текущий баланс, список абонплат, сумму текущих начислений модуля абопнлат (что уже есть в contract_account за этот месяц). Вычисляем сумму начислений модуля абонплат, которая будет после после переобсчета договора с текущим набором абонплат и текущей датой. В результате можем оценить дельту, на которую упадёт баланс после проведения начисления модулем.
2) Если при проведение начисления на требуемую сумму абонент не уйдёт ниже лимита, ничего не делаем.
3) Если данное начисление уведёт абонента ниже лимита, то статус абонента переключается в "Отключен" (пока условно, нужно подумать) от текущего дня.
4) Отрабатывает начисление абонентских плат, снимающее сумму с учётом статусов.
5) При приходе платежа на отключенный договор оценивается, достаточен ли текущий баланс для начисления абонплаты (идёт запрос на оценочную тарификацию в модуль абонплат). Если достаточен - то договор открывается от текущей даты.
Насчёт пункта 5 есть такой вопрос, нужно ли открывать абонента автоматически, если по прохождении какой-то части месяца остатка на его счету уже достаточно для открытия абонплаты?

Необходимы доработки:
1) Заложить в модуль абонплат возможность просто вычислить размер абонплаты за месяц до текущей даты без её непосредственного списания.
2) Задача планировщика - "Блокировка" для модуля абонплат.
3) Обработка события платежа модулем абонплат с открытием договора, если поступившего платежа достаточно для снятия абонплаты.

Просьба заинтересованных оценить пригодность данного алгоритма, задать вопросы если есть.

Дополнение 1:
Необходимы доработки.
1) Режим работы узла "Диапазон услуги" который "Пропорционально периоду" - нужно дополнительно учитывать статус. Какую часть периода был договор активен.
2) После прихода платежа и открытия статуса необходимо переначисление абонплаты для договора.

Дополнение 2:
В задаче переключать нужно в статус "Закрыт", чтобы абонплата не снималась. В "Отключен" - снимается.

Дополнение 3:
В карточке договора в дереве, где модули напротив модуля абонплат отображать сумму, необходимую открытия данным модулем.

Пункт 3) Почему в "отключен"? Т.е. мы уведем его раз в минус? Но тут многие нехотят минуса. Тут предлагаю либо отключен либо приостановлен. указываем в конфиге. Чтобы начисление в пункте 4 могло и не выполниться
Пункт 5) Открывать автоматически договор выглядит довольно странно. Получается если у клиента на счету денег достаточно для работы на 20 дней, то в первый день мы ему закрывам доступ на первые 10 дней, а потом снова даем Типа сюрприз. Так недоразумений будет много, клиенту откуда знать что его включит через 10 дней и т.д.?

В случае если в Пункте 3) мы договор приостанавливаем, то обязательно надо показывать сколько "требуем платежа ежедневно(месячно)"/ (сколько надо доплатить до него)

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

До конца месяца пропорционально периоду? Безусловно? Или это не влияет?


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

Конкретный статус можно отдать на откуп нам, с помошью конфига

Конкретно для нас - нет, ни в коем случае. Но допускаю, что кому-то это понадобится. Следовательно, скорее всего такая автоматика должна иметь выключатель.

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

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

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

Да можно и так. Хотя при приходе нужно выводить из этого же статуса получается, но статус из которого выводить тоже в конфиг можно заложит..

Вообще пока никому такое не понадобилось, можно на будущее отложить..

Я про минус ничего не писал. Если статус будет "отключен" то начисление в п. 4 и не выполнится.

Если статус "отключен" начисление абонплаты выполняется.

А что на счет показывать сколько клиент должен оплатить, если не будем в минус? чтобы не было ситуации примерно такой. Клиенту надо оплатить 2100. он кладет 2000р. этого платежа не достаточно для разблокировки. Клиент сразу может и не понять, да и поддержка тоже. С какого это на счету есть деньги, а пользоваться не может

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Да, нужно в "Закрыт" переводить. Ошибся.

Можно эту информацию отображать в дереве на карточке договора. Там где модули. У IPN, например, отображается состояние шлюза. Для NPay можно писать как раз недостающую сумму. В Web статистике как это сделать и где - пока не понятно.

Я в свой пост по ходу пишу уточнения, сверяйтесь с ним когда что-то пишете.

Чудо.

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

Отлично! но лучше статус менять приостановлен. Закрыт, из названия предполагает "тяжелый случай", что клиент уже не будет работать. А то что клиент не успел оплатить это не тяжелый случай. Потом может потребоваться пробежаться по приостановленным договорам находящимся в статусе месяц, другой, и "закрыть" его. для отчетности

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Прошу не придавать сурового смысла названиям статусов в БГБ.

Да ничего не будет. Эти процессы отрабатывают-то минут за пару каждый.. Ну поставите начисление на час.
Максимум что будет - не успеет первый процесс статусы выставить корректно до того как начисление пойдёт.

Ок, тогда какая разница в статусах Приостановлен и Закрыт? пусть за одним одна логика будет закреплена, за другим другая

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Вообще, мы как раз таки и задумывали закрыт, что из него выходит договор по платежу, см. доку. В кредитовом режиме из него платежом выводит, там только сальдо оценивается а не остаток. А приостановлен - это только руками выводить из него.. Т.е. это добровольная приостановка услуги.
http://www.bgbilling.ru/v5.0/doc/ch01s18s09.html

И ещё такой момент мы обязаны учесть. Мы должны дать возможность клиенту поработать в долг, т.е. понижение лимита должно также учитываться. Если лимит понижен, значит абонплата пускай списывается в минус

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

2 Администратор:

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

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

неотключаемые гуд +1

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/