BiTel

Каким образом различаются те, кто просрочил обещанный платеж, но все же оплатил и те, кто не оплатил свое понижение лимита вообще?
В contract_limit_manage.status статус, 0 - "лимит не погашен", 1 - "лимит частично погашен", 2 - "лимит погашен", 3 - "лимит просрочен."
3 - "лимит просрочен." - это те, у кого срок вышел, а как помечаются, те, кто после этого оплатил? Им назначается статус 2 - "лимит погашен" или они навсегда остаются в 3?

Просрочен. И если просроченных кол-во достигает значения, заданного в конфиге параметром contract.limit.1.maxexpiredforblock
то этому юзеру блокируется возможность понижения лимита до ручной разблокировки менеджером.

Как отличить тех, у кого наступило contract.limit.1.maxnotpayoffed от тех, у кого наступило contract.limit.1.maxexpiredforblock ?
Т.е. первые вообще не оплатили, а вторые оплатили, но позже обещанной даты.

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

Во-первых хотелось бы знать сколько таких. Сейчас строим графики количества по group by contract_limit_manage.status. И по ним не видно тех, кто опоздал с платежем, но все же оплатил.
Во-вторых как сделать так, что те кто оплатил в предыдущем месяце, смогли воспользоваться обещанным платежем в новом месяце, а те кто не оплатил - нет?
С текущими настройками, которые приведены выше, те, кто просрочил платеж, не имеют возможность воспользоваться управлением лимитом независимо от того оплатили они или нет. А если сделать ненулевой maxexpiredforblock, то это затронет и тех, кто не платил.

если клиент ДО СИХ ПОР не оплатил обещанный платеж значит у него до сих пор минус и он не работает, так какая разница в каком месяце это было?


если вы стротите отчет 1 числа месяца, то все у кого просрочен обещанный платеж и отричательный баланс, именно те кто вам нужен.



написать скриптик который 1 числа будет выбирать клиентов со статусом "лимит просрочен" и балансом > 0 и менять им статус на "лимит погашен"

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



А может лучше добавить еще один статус "оплачен с опозданием" и переводить в него просроченные после оплаты?

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

не совсем понимаю чего вы хотите получить...
что бы клиент 1 числа делал обещенный платеж потом забивал на него, 31 числа погашал его и первого следующего месяца мог опять это повторить?

В этот статус переводить из просроченных, если contract.status после очередного поступления денег станет 0. Частичная оплата не интересна вообще.

В конечном счёте хотелось бы получить вот что:
При поступлении платежа сумму платежа раскидывать не только по обещанным платежам со статусом 0 (лимит не погашен) и 1 (лимит частично погашен), но и со статусом 3 (лимит просрочен). Остаток обещанного платежа уменьшать на сумму поступившего платежа, и если он достигает нуля, то менять статус платежу на 2 (лимит погашен), а таблице contract_limit_manage_mode уменьшать счётчик на 1 и, если необходимо, mode на 0.

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

сейчас логика такая:
1) при приходе платежа см. если текущие обещанные платежи, если есть и сумма платежа больше или равна сумме обещанного, закрываем ощещанный платеж и ставим статус лимит погашен, возвращаем лимит
2) если при приходе сумма меньше активного обещанного платежа, меняем статус на частично погашен, если статус уже частично погашен сумируем платежи с даты обещанного платежа и сверяем суммы, если сумма перекрыла меняем статус на погашен и возвращаем лимит
3) когда приходит время отката лимта, возращаем лимит и ставим статус не погашен
4) если при приходе нет активных понижений лимита, то ни чего не делаем

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

можно и более простой вариант.
в п.4 если при приходе статус контракта переходит в активное состояние, и есть обещанный лимит в состоянии "просрочен"(а в этом случае он может быть только один), то менять статус у такого обещанного лимита на "погашен просроченный лимит".

а зачем вам статус такой если можно просто
1) выбираем всех клиентов у кого статус договора Заблокирован и лимит просрочен - это те кто "просрочил и не заплатил"
2) выбираем всех клиентов у кого статус договора Активен и лимит просрочен - это те кто "просрочил и погасил"

Сейчас обнаружил следующую проблему: если лимит договора восстанавливается задачей восстановления лимитов (соответственно, обещанный платёж оказывается просроченным), то статус договора остаётся "Активен", а не "Закрыт", как ожидается. Соответственно, скрипт, который будет разблокировать возможность активации обещанного платежа, работать не будет, и графики мы тоже построить не сможем.
Это ошибка в конфигурации или так и задумано?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

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

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

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

Так почему не меняет?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

так а вы меняете?

_________________
I'm clever. I've got a computer.

Чего-то в списке событий для привязки дин. кода я не видел события "Изменение баланса". Собственно, кто должен обрабатывать это события и закрывать договор: дин. код или стандартный класс?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

На это событие не привязываются обработчики. Оно внутреннее, системное.

Вы бы между собой уже разобрались... Кто должен менять статус договора при восстановлении лимита?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

В данный момент ни кто не меняет, не было такой задачи.

Перевод в статус Закрыт выполняет соответствующая задача планировщика, и никто более. Вот срабатывает задача восстановления лимитов, далее следом идёт задача закрытия Npay договоров, дальше начисление абонплат. Вроде всё сходится. Доступ к услугам блокируется даже в Активном статусе при отрицательном балансе (меньше лимита).

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

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

Судя по документации http://bgbilling.ru/v5.2/doc/ch22s07.html, при выполнении задачи закрытия договоров не производится никаких действий, если уже начисленная наработка более или равна планируемой к начислению. Это показал и эксперимент. В нашем случае запуск задачи закрытия договоров не приводит к закрытию договора, т. к. при понижении лимита списывается полная наработка за месяц.
При навешивании скрипта на приход платежа уже нельзя ориентироваться на статус договора, чтобы сделать разблокировку. Пока единственный вариант, который я вижу - периодически запускать скрипт и, если баланс договора больше нуля, то разблокировать обещанный платёж. Но это не очень эффективно в плане расходования ресурсов.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Куда-то все пропали...

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

а чего вы ждете?

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Если честно я так до конца и не понял в чем задача, а главное для каких целей она нужна.

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91