BiTel

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

Ну да, можно в статусе "Отключен" просто настроить некоторые абонплаты чтобы списывались.

кроме платежа стандартный механизм разблокировки для любого оператора дебета это понижение лимита, временное или постоянное не суть
отсюда следует
1) событие понижение лимита -> пересчет абонки, аналогично приходу платежа
2) событие повышения лимита -> пересчет абонки и блокировка если договор ушел в минус, для целоснос ти алгоритма мне кажется надо это обрабатывать

пока все коментария, в целом мне нравится направление мысли

Ну вообще там и генерится событие платежа, фейковое И поведение аналогично.

А зачем блокировать? Заблокирует в 0 часов следующих суток.. За текущие сутки уже списана абонплата.

Против пересчетов абонентки, да и любых пересчетов (в пересчётах куча потенциального гемора). Абонентка либо начисляется либо нет. Пересчеты, это "аварийные" действия, либо по заявлению клиента.

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

Вроде пока что хорошо все!
Каково будет поведение если у клиента абонентка 1000р. пропорционально периоду.
1) он её оплатил. значит активен на счету 0р
2) 15 числа ему начисляют расход -200р за вызов специалиста. оплачивает он их через 5 дней.
Какое будет поведение? Эти 5 дней должна начислиться абонентка(т.е. ничего не трогаем, клиент активен, баланс отрицателен, потому работать не может) или закрываем договор опять же?
Это актуально для ежемесячных абонплат. Я за первый вариант (ничего не трогаем, клиент сам решает проблемы с минусом)

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

Ну вообще он в минус уйдёт после списания 200 руб и работать не сможет, пока не заплатит. А абонка как списалась первого числа - та и всё, по сути сумма списания-то ведь не меняется. Т.е. например 16 запустит процесс пре-тарификации. Посмотрит - начислить надо 1000 ну и начислено 1000. Ну и можно успокоится и на статус не обращать внимания, т.к. всё что можно - уже списано.

Хорошо. Тогда вроде всё. Ждем!

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

Отлично!

Замечания:
1) Если будем постоянно дергать статусы, то проявится другая проблема, о которой я писал тут.

-

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

2)
В стандартной вебстатистике вообще неудобно смотреть текущий баланс. По-идее, он должен отображаться сразу, рядом с номером договора. Там же можно отображать и минимальную сумму платежа для разблокирования. Но это детали - главное включить эту цифру в xml, дальше уже каждый сам разберется, что с ней делать.

3) По поводу последнего: есть абонентка, снимающаяся в начале месяца разом. Она учитывает статусы, но снимается из расчета, что весь месяц клиент будет работать. Снимается 1000р., у клиента баланс становится, допустим, 50р. Дальше в середине месяца списывается расход в 200р -> баланс становится -150р. Лимит = 0. В 0:00 запускается блокировки и отрубает договор, ставя ему статус "закрыт". При следующем плановом пересчете абонплат вместо этих 1000р. с учетом статусов снимутся 500. Баланс становится положительным, но клиент закрыт.
Не вижу простого способа выйти из этой ситуации, кроме как отказаться от помесячных абонплат для дебета. Т.е. это должно быть на совести клиента.
Можно конечно придумать костыли, но как правило это вызывает ещё большие проблемы в дальнейшем.
Вообще, это задание блокировки нужно отключать по-умолчанию как раз из-за таких вот нюансов. Ещё неплохо было бы в конфиге указывать список групп договоров, подлежащих блокировке. Тогда можно будет ввести сначала для определенной категории клиентов и потестировать, а потом уж для всех. Если группы не указаны - обрабатываем все открытые дебетные договора.

По поводу пункта 3! Сразу надо ограничиться простотой алгоритма и не усложнять его. К алгоритму предлагаю требование такое: Абонентка либо начисляется(добавляется) либо не начисляется. Ни в коем случае алгоритм начисления абонплаты не должен сам пересчитывать предыдущие наработки. Пересчет наработки(любой) производится пользователем биллинга в исключительных случаях.
Далее рассматривая ваш пример, если клиент ушел в минус изза расхода, ночью он недолжен закрываться. Зачем его закрывать? Клиент итак не может потреблять услуги, и в случае расхода в большинстве случаев не может потреблять по своей вине (если не посвоей, пусть оператор биллинга сам его "закрывает" и пересчитывает). Автоматика не должна рассматривать все частные случаи, потому как усложнится всё.

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

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

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

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

Я имею в виду абонплату типа "помесячный режим снятия пропорционально периоду".

Это ежедневная. Ежемесячная должна только один раз начисляться.
Вообще, по этому поводу, малость не понятно предложение Администратора "каждый день запускать отдельный процесс". Зачем процесс? Лучше на мой взгляд изменить механизм начисления модуля абонплат. И если начисление абонплат запланировано раз в месяц, то и начислять в соответсвии с такой логикой РАЗ в месяц. Ну и автоматически доначислять при поступлении платежа если это необходимо.

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

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

Оно и сейчас так работает. Зачем требовать от дебетной схемы идеальной работы там, где даже кредитная создает головняк?

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

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

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

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

Те же самые "нюансы", что и в кредитном режиме.

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

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

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

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

P.S. Cromeshnic очень правильный пример привел на счет абонки и последуещего списания, подумать на эту тему очень даже стоит, а вот пытаться ли предусмотреть решение для такой ситуации или просто забить (пока?) это уже совсем другой вопрос и не нам (юзерам) его решать. И на счет статусов вспомнил, при них давно уже пишут, без реализации нормального механизма смены статусов вся затея будет как карточный домик, один неверный клик и история смены статусов договора "за 4 года и 5 месяцев" сливается в отхожее место.

тут клиенты голову еб "высушивают" с "пропорционально периоду", а чего уж говорить о более "хитрых" вариантах?


вот, Вот, ВОт, ВОТ!!!111 господа разработчики, умоляю, пожалуйста, перечитывайте эту фразу ежедневно, от 1++ раз на дню


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

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

С моей точки зрения это нисколько не хуже чем тереотизирование по поводу чужой или тем более "правильной" бизнес-логики.
Если кому-то из пользователей БГБ что-то не нравиться или даже неприемлимо, то ничего катастрофического тут нет. Последнее слово всегда за разработчиками. Только они видят полноценные данные по потребностям в том или ином функционале.

Нет, ему не поставит статус "закрыт". С него уже списано 1000 руб, и предкалькуляция опять же покажет, что списать нужно 1000 руб. Дельта нулевая, от его баланса ничего не требуется, т.е. до проверки баланса вообще не дойдёт..
Но в инет его не пустит и модуль IPN его залочит, но статус при этом не изменится.
Либо я не правильно понял проблему? Прошу уточнить.

вот текст скрипта под 4.5

вяжется на событие... открытие учетного периода....



import bitel.billing.server.contract.bean.*;
import bitel.billing.server.util.*;
import java.util.*;
import java.math.*;

VPN_MID = 1;
CHARGE_TYPE = 6;

bu = new BalanceUtils( con ) ;
cm = new ContractManager( con );
chm = new ChargeManager( con );
ctm = new ContractTariffManager( con );

event.setProcessed( true );
if( event.getRequestDate() == null ) {
error( "event.requestDate() == null" );
return;
}
cid = event.getContractID();
contract = cm.getContractByID( cid );
if( contract == null ) {
error( "Contract with ID " + cid + " was not found!" );
return;
}
date_clndr = (Calendar)event.getRequestDate();
date = date_clndr.getTime();
currentTariff = ctm.getContractTariff( cid, date_clndr );
if( currentTariff == null ) {
error( "Current tariff was not found!" );
return;
}
PAY = 0;
tpid = currentTariff.getTariffPlanID();
if( tpid == 7 ) {
PAY = 100;
}
else if ( tpid == 13 ) {
PAY = 150;
}
else if ( tpid == 8 ) {
PAY = 200;
}
else if ( tpid == 34 ) {
PAY = 350;
}
else if ( tpid == 29 ) {
PAY = 400;
}
else if ( tpid == 30 ) {
PAY = 500;
}
else if ( tpid == 32 ) {
PAY = 250;
}
else if ( tpid == 40 ) {
PAY = 800;
}
else if ( tpid == 41 ) {
PAY = 1200;
}
else if ( tpid == 42 ) {
PAY = 1500;
}
else if ( tpid == 44 ) {
PAY = 200;
}
else if ( tpid == 45 ) {
PAY = 260;
}
else if ( tpid == 46 ) {
PAY = 280;
}
else if ( tpid == 47 ) {
PAY = 300;
}
else if ( tpid == 48 ) {
PAY = 350;
}
else if ( tpid == 49 ) {
PAY = 390;
}

else {
error( "Incorrect current tariff!" );
return;
}
balance = bu.getBalance( date, cid );
if( balance.intValue() < PAY ) {
error( "Not enough money to open a period!!" );
return;
}
charge = new Charge();
charge.setContractID( cid );
charge.setChargeDate( date );
charge.setChargeTypeID( CHARGE_TYPE );
charge.setComment( "по тарифу за текущий месяц." );
charge.setSumma( new BigDecimal( PAY ) );
chm.updateCharge( "new", charge );
bu.updateBalance( date, cid );
date_start = new GregorianCalendar();
date_start.setTime( date );
date_end = (Calendar)date_start.clone();
date_end.set(Calendar.DATE, date_end.getActualMaximum(Calendar.DATE) );
event.setPeriodStart( date_start );
event.setPeriodEnd( date_end );
print( "PAY = " + PAY );

А, ясно - т.е. блокировка будет не по факту "баланс<лимита", а если нужно снять абонплату и после этого станет "баланс<лимита". Ок.
Если в данном примере ввести ещё и подневную абонплату, тогда он таки закроется и далее по списку. Впрочем, нет смысла опять об этом писать, т.к. все уже поняли, о чем речь. Править не нужно - это фича помесячной абонплаты.

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

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

А в 4.6 эта опция будет доступна?

Нет.