BiTel

с любыми будут, разницы нет

будут работать дебетовые абонплаты с режимом "пропорционально периоду"?

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

По идее - запускаю 1-го числа, дебетовые абонплаты блокируют всех у кого не хватает денег на абонентку - это правильно, такая логика туда и заложена, но наступает 2-е (3-е, 5-е, 24-е) число и у кого-то денег уже будет хватать - разблокируют ли дебетовые абонплаты такого юзера или он будет продолжать висеть в заблокированных?
Платежи придут либо через cards либо через mps и статус изменится, как в мануале и написано. Меня больше волнует вопрос - какой статус будет у тех у кого хватает денег не на 1-е число месяца при условии ежесуточного запуска задачи?

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

Штатно логики такой нет, нам показалось это нелогичным и непонятным для клиента. Что 1го не открылось а 4го раз и открылось. А человек может и не в курсе вовсе.. Решил на следующий месяц заплатить.
А почему не открывать тогда с 1е по 26е, например. Вообще, при пропорциональном снятии но авансом за месяц выходит схема запутанная какая-то.

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

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

Если данный функционал будет востребован большим числом пользователей - сделаем в модуле поддержку.

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

Режим дебетовых абоплат умеет это делать .. Без скриптов

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

Нет, не умеет. Вы внимательно почитайте процитированное вами сообщение:

Мне очень сильно кажется, что человек хочет, чтобы npay открывал договор только в случае, если вносимая сумма >= стоимости абонентки за весь месяц, а вот этого npay не умеет Если умеет - ткните, пожалуйста, где это описано.

Перевод договора в активный статус, указанный в переменной debet.npay.active.status, происходит по платежу тогда, когда остаток баланса позволяет открыть договор от текущей даты, начислить ему абонентскую плату и баланс при этом не должен опуститься ниже лимита.

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

А еще смущает этот параметр:

Он должен быть равен 0??? Что будет если этот параметр вовсе не прописать? Получается если его прописать, сумма на балансе для разблокировки фиксирована, а не та которая указана на тарифных планах

Да на самом деле я имел ввиду вносимая сумма >= стоимость_абонентки+набежавший_минусовой_лимит

Что же нужно все-таки прописать в конфиге и работает ли оно?

Могу и ткнуть
http://bgbilling.ru/v6.0/doc/ch22s07.html

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

Есть такой провайдер как например сумтел.
так вот у них есть такое упоминание


Т.е. если вас заблокировало - будьте добры пополнить счет на месяц вперед для разблокировки.

И если BG будет поддерживать данный функционал, я первый обновлюсь

Спасибо за ссылку, но я думаю, что вы немного не поняли. Есть мнение, что ikoctya хочет, чтобы при абон. плате в 10 руб./день договор открывался только если абонент пополнит счет на сумму не меньше 300 руб, а не при зачислении, например, 10 или 20 руб., которых хватит для начисления (см. выделенный текст в цитате).
Если возможно использование дебетовых абонплат с подневными абонентками для указанной выше ситуации то, пожалуйста, скажите какие именно для этого должны быть подневные абонентки, а то их много и, честно говоря, я до сих пор не понял как некоторые из них работают

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

в каком виде?