BiTel

как я понял написание скрипта отрицается в принципе, да?

так за что вы берете АБОНПЛАТУ, и почему вы ее называете АБОНПЛАТОЙ, а не разовым платежом

так как АБОНПЛАТА это ПЕРИОДИЧЕСКОЕ списание средст, в вашем случае клиент 3 месяца не пользуется услугой соответственно 3 месяца не платит, где ПЕРИОДИЧНОСТЬ?

Нет скрипт неотрицается. А то что это абонплата это точно.
Это не разовый платеж.

Абонплата с условием наработки (если нет наработки нет абонплаты),
но если на счету у клиента 1 руб. его авторизует и снимается абонплата - результат на счету минус.

Как может авторизовать и снять денег в минуса, когда авансовая система расчетов?

Вот я и предлагаю эту шероховатость поправить хотябы скриптом.

Шероховатость есть - согласитесь?

Я просто присоединился к автору данной темы.

У меня абонентов мало и я в состоянии отследить это вручную.

А когда абонентов много, наверное совсем печально?

- делаете абонентку по условию наработки в услуге время, т.к. оно всегда есть - этим 100% решается вопрос "подключился - снялось"
- рисуете скрипт который сделает наитупейшую оперцию:

собсно все!

Так ЗА ЧТО Вы берете АБОНПЛАТУ? Не при каких условиях, а за ЧТО? Зачем вам вообще модуль абонплат?

почему бы не сделать так

при логоне клиента проверяем есть ли у клиента СПЕЦИЛИЗИРОВАННЫЙ РАСХОД за этот месяц,
если есть и есть деньги на счете, пускаем
если нет, заносим расход если есть необходимая сумма для расхода, и пускаем
если нет расхода и не хватает денег на пускаем...

в разных тарифах разные абонплаты. а это интересно. Поподробнее можно?

if (есть деньги) {
начислить абонентку;
}

Т.к. АПИ почти некоментирован.

Вы предлагаете отказаться от модуля абонплат?

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

"На пальцах" логика ясна а вот в АПИ функциях:

при авторизации проверять:
- если баланс договора равен или больше суммы абонплаты, то авторизовать.
- если меньше то неавторизовать.

А абонплата сама снимется по условиям Нпей модуля. Или не так?

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

нельзя скриптами перекрыть логику изменения статуса и выставлять для вашего случая статус "приостановлен" и соответсвенно при получении денег выставлять статус в активен? в этом случае абон плата не будет сниматься в период приостановки договора

http://wiki.bgbilling.ru/index.php/%D0% ... reeBSD_MPD

Последний скрипт, вносит определённый расход при наличии денег на счету, если денег не хватает не пускает!

Собственно выше я и описал, как добиться того, чего требуется. И помоему это действительно какое-то списание, а не абонплата.

"На пальцах" логика ясна а вот в АПИ функциях:

Повесить скрипт в предобработку радиус авторизации.

при авторизации проверять:
- если баланс договора равен или больше суммы абонплаты, то авторизовать.
- если меньше то неавторизовать.

А абонплата сама снимется по условиям Нпей модуля. Или не так?

Тогда мы остаемся с функционалом модуля абонплат и уходим от от внесения отдельного "Расхода".

Скрипт висит на событие "Запрос учетного периода".
При авторизации если есть учетный период, то скрипт не выполняется. Если нет учетного периода идет запрос в скрипт. В скрипте вы проверяете баланс, списываете расход, устанавливаете период учетного периода. Или же не устанавливаете период, если денег не хватает - тогда автризация не пройдет.

Тоесть модуль абонплат ненужен?

это только Вам решать

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

вот этот скрипт привязанный к запросу учетного периода заносит расход но неавторизует с ошибкой 31 (ошибка установки учетного периода).

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

// ID модуля Dialup
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 == 53 ) {
// Размер вносимого расхода
PAY = 290;
}
else if ( tpid == 66 ) {
PAY = 360;
}
else if ( tpid == 67 ) {
PAY = 660;
}
else if ( tpid == 68 ) {
PAY = 960;
}
else if ( tpid == 69 ) {
PAY = 1660;
}
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.setDate( date_clndr );
charge.setChargeTypeID( CHARGE_TYPE );
charge.setComment( "Активация периода UNLIM" );
charge.setSumma( 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.add( Calendar.DAY_OF_YEAR, 30 );
event.setPeriodStart( date_start );
event.setPeriodEnd( date_end );

print( "PAY = " + PAY );

невыходит каменный цветочек. 31 ошибка и все

А как тогда узнать, снимали за этот месяц деньги или нет?
Посмотрите что в логи пишет радиус, в script.log
Возможно какое-то услови скрипта не выполняется, например, код тарифного плана.

Почитал я тут... Эмоционально...
Решил свое мнение написать.
Разделим проблему на две части:
1. Хороший или плохой биллинг. Отношение к разработчикам.
2. Использование npay для работы с безлимитными тарифами широкополосного доступа.

По первому вопросу. Биллинг отличный. Я с ним почти с самого начала.
Разработчики очень ответственные люди. Просто не стоит ставить свежие версии. Я например, с 2007г. на 4.3. Вчера обновился на 4.5, полет нормальный!
Есть одно "но". Биллинг сделан не в Москве, а в Уфе. Другими словами, то что само собой разумеется по московской логике, не всегда таковое в Уфе. И это надо просто учитывать. При этом, вся заявленная логика работает. И если Вам необходимо изменить логику под свои нужды, не надо топать ногами и кричать, что так должно быть.
Разработчики все могут сделать по отдельному заданию, за отдельные деньги. Сам несколько раз заказывал, очень доволен!

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