BiTel

Может хотябы соизволите сообщить, что - "Добавить событие трудоемкая задача, в данный момент не можем выделить время на неё. Ориентировочное время через пол года" или чтото такое. Люди терпеливо ждут ответа на любой вопрос, несмотря на то что вы частенько кладете на них.

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

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

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

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

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

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

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

- В конфиге будет фильтр по договорам, попадающим под эту обработку? (Кредит/Дебет, фильтр по группам)
- Как будет вычисляться и храниться(?) эта сумма? Для каждого отдельного дня она будет своя, т.к. могут меняться тарифные планы и абонплаты.

- В конфиге будет фильтр по договорам, попадающим под эту обработку? (Кредит/Дебет, фильтр по группам)

- Как будет вычисляться и храниться(?) эта сумма? Для каждого отдельного дня она будет своя, т.к. могут меняться тарифные планы и абонплаты.

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

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

Будут ли неотключаемые абонплаты, которые начилсляются не зависимо от статуса ? Хотим чтобы снималась в месяц у закрытых договоров какаято фиксированная сумма в месяц.

#абонплаты, на которые не влияет приостановка договора
#service.no.suspend=
#абонплаты, начисляемые при нахождении договора в статусе "Приостановлен"
#service.no.suspend.in.suspend=
#абонплаты, начисляемые при нахождении договора в статусе "Закрыт"
#service.no.suspend.in.close=
#автоматическое переначисление абонентских плат договора при изменении их периода, количества и т.п.
recalculate.on.service.change=1
#E-Mail для отправки уведомлений об автоматическом переначислении при изменении абонплаты, если не указан - уведомление не высылается
#auto.recalculate.email=

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

Фильтр по группам добавим.

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

По докам не понял, в личном кабинете юзер сможет узнать почему он не работает, и сколько должен?

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

Пока нет, отложили на второй этап.

Недостаточно! У нас нет отдельной группы для физ.лиц, т.к. это было бы дублированием информации

Т.е. при активации нужно чтобы у него на балансе было достаточно средств на 30 дней абонплаты? Такой возможности нет..
А какая логика в этом?

Нужна обязательно оплата именно за весь месяц, но помесячное снятие конечно же не подходит?!

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

Требуется, чтобы сумма необходимая для активации договора была не (цена_АП - исходящий_остаток), а (цена_АП*30 - исходящий остаток)