BiTel

В 5.2 появилась возможность создавать кастомные статусы и в модулях делать активные статусы для данного модуля, отлично. НО!!!
Модули все равно принимают решение об активности услуг модуля исходя из расчета баланс>=лимит. И нет возможности штатными средствами создать чисто "кредитовый" договор. Тип договора кредит/дебит исключительно для фильтрования в мониторе баланса. А чтобы создать договор который работает по пост оплате надо фигачить фейковый лимит (который как написано в документации служит ограничителем при вирусных эпидемиях).
Деваться-то некуда, приходится так изворачиваться, но у меня и как минимум у еще троих пользователей бгбиллинга (не будем тыкать пальцами, в джаббере обсуждалось) есть необходимость заводить абонентов, которых не будет выключать. И красивее всего это реализовалось бы статусом "Включен постоянно", при котором абонент фигачил бы в минус до принятия решения администратором.

Эта тема уже поднималась в разделе IPN, но актуально то ведь и не только в нем иметь такую возможность.

Может все-таки сделать такую штуку?
Ну или параметр в модулях сделать - типа игнорировать лимит. status.on.ingnore.limit=.... может что нибудь такое... Хотя круче было бы иметь возможность сделать какой нибудь из статусов принудительно включенными или выключенным )

один из них я,полностью поддерживаю

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

Я - ЗА!

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

один из них и я,полностью поддерживаю

я для своей веб морды сделал такой шайтан-майтан: статус постоянно включен. Это когда лимит меньше минус много миллионов. А если нужно установить этот статус будущим числом то мы добавляем задание на понижение лимита. Вот только куча подводных камней с этими движениями лимитов, в том числе связанных с тем что то что делает из родного клиента админами никак к этому не привязана.

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

Лимит в несколько десятков/сотен миллионов (миллиардов?), как я понял, никого не устраивает?

аха

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

Нет!(с)


Сложно реализуется скрипт, который при изменении дебет/кредит ставит нужный лимит с нужной даты?
Пожалуйста, скажите что Вы шутите.

1. дебет кредит выставляется не с даты а только текущим числом.
2. если статус был выставлен будущим числом (соотв. задано понижение лимита) а потом отменен или перенесен на дату, искать нужное понижение (а оно может быть не одно) - гемор
3. у меня единая работа с отключением/включением абонентов, мониторингом балансов и т.д., в каждое место где это используется писать проверку а не болььше ли лимит этих десятков миллионов и не надо ли его при выводе обрезать - жесть. Я не говорю что невозможно, сейчас у меня так и сделано, но поддерживать такой код и что то добавлять становится сложновато.
4. В 5.2 думаю проще было бы сделать - сделать статус какой нибудь, и повесить событие на изменение статуса -и синхронно с ним управлять лимитом - почему бы и нет, но опять же, говорю - в каждое место где выводится лимит (карта договора, ЛК) пихать проверялку лимита - неудобно.
5. У меня используются активно субдоговора - причем не хочется чтобы на них на всех был одинаковый лимит, пихать синхронизацию лимитов да еще и с проверками на соответствие этим миллионам - можно, и сделано, но гибкость системы потерялась.

Ладно бы только у меня такая задача стояла - но есть и еще люди кому это нужно.

Я объяснил задачу, по-моему, довольно понятно - сейчас у всех поголовно безлимитки. Макс задолженности (особенно при работе с юр.лицами) роли не играют. Кредит как ограничение макс задолженности (а у нас кстати снимается в минус АП при любом статусе) уже не нужен.

интересно мнение разработчиков