BiTel

Ув. разработчики.
Присматриваюсь к вашей логике блокировки дебитовых договоров, сейчас использую свои скрипты.
Есть несколько вопросов:
1. При автоматическом изменении статуса договора учитывается ли статусы, установленные на будущие периоды? или же они просто затираются?
Пример их жизни. Пришел абонент и написал заявление на приостановку услуги например с 01.07.2010 по 31.07.2010. Оператор меняет статус договора на этот период. И вдруг случается так что 01.06.2010 договор автоматически блокируется за неуплату, а 02.06.2010 клиент вносит на счет необходимую сумму и продолжает работу. Так вот затрется ли его заявка не приостановление услуги?
2. У нас есть премия. Если абонент 2 месяца исправно платит на наши услуги (т.е. не блокировался за неуплату) мы предоставляем ему бонус +20% к скорости. Так вот можно ли будет как то узнать был ли абонент заблокирован за неуплату например в период с 01.02.2010 по 31.03.2010? Если нет то можно ли при автоматической блокировке устанавливать статус, отличный от стандартных, например "Закрыт за неуплату" или "Приостановлен за неуплату"?

Кстати, да. Про приостановку по письму. Совсем забыл, писал при обсуждении об этом:
viewtopic.php?p=22504#p22504

Посмотрел в коде - будущий статус не учитывается:

По пункту 1, мне кажется, вообще нужна отдельная таблица для заданий на приостановление аналогично заданиям на возвращение лимита.
Тут же вопрос - планируется ли добавить функционал самостоятельного приостановления услуг из ЛК?

Ещё интересно - а как выискивать закрытые договора? тоесть раньше скриптом они переводились в другую группу, а сейчас как??

_________________

Код:

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

зачем ? чем вам таблица статусов не устраивает ?



В 5.1 из личного кабинета можно менять статус договора

затираются



такой возможности нет .. Можно по коментарию разделить только

Вот этим:

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

Зачем? Ну или за что?

Логика работы со статусами такая же как если бы тоже самое делал оператор из клиента биллинга . Т.е если он ставит какой-то статус с сегодняшнего дня , то он перетирает все будущие статусы . зачем так сделано ? потому что так проще и в некоторых случаях как раз это и надо . например , ставит статус отключен с для должника с завтрашнего числа , а если он сегодня оплатит, то новый статус активен все перетрет .. Предложите другую схему.
Например сегодня 15- число .А статусы стоят
так
заблокирован по 20 число
активен с 21 — 24.
Приостановлен 25 — 28.
активен с 29 — го.

Мы делаем забликрован сегодня(15 число) . Тогда по текущему алгоритму сделает так
заблокирован по 14 -е.
заблокирован с 15 — го.

Как вы предлагаете делать ?

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

Если кому-то из клиентов требуется именно такое поведение (с затиранием), то из этого не следует, что это правильно или нужно всем.
Если нам надо было затереть будущие статусы, то мы их и затирали. Для этого есть API, есть доступ в базу. Если не нужно было - оставляли.
Зачем вообще нужно было лишать нас права выбора варианта обработки истории статусов?

Поддерживаю vdd.


Как бы не так. Если сейчас статус = "активен", то по платежу ничего не произойдет и клиент завтра все равно отключится. У меня на этот случай скрипт отрабатывает и по приходу платежа перетирает будущие статусы "закрыт" и "отключен".

так вы скажите что вам нужно то. Я привел пример выше , что в нем будет ..оставляем все как есть , т.е оставляем статус приостановлен сегодняшнего дня , а после него снова будет статус активен? .. Т.е получим
так :
заблокирован по 14 -е..
заблокирован 15 - 24.
приостановлен 25 - 28.
активен с 29-го .

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

Или все-таки нужно все статусы в будущем коме статуса приостановлен , сменить на заблокирован ?

да, вы правы, так и есть . Если статус актитвен, то ничего не произойдет .

Я немного попутал, для статус договора нет значения заблокирован (спутал с IPN ). Поэтому так :
закрыт по 14 -е..
закрыт 15 - 24.
приостановлен 25 - 28.
активен с 29-го .

Или все таки так :
закрыт по 14 -е..
закрыт 15 - 24.
приостановлен 25 - 28.
закрыт с 29-го .

Мне кажется все-таки второй вариант . А потом по приходу платежа менять все статусы в будущем на активен , кроме статуса приостановлен . Поэтому после прихода платежа , например 17-го числа , он сделает так

закрыт по 14 -е..
закрыт 15 - 16.
активен 17-24
приостановлен 25 - 28.
автивен с 29-го

А если он заплатит не 17-го, а 26 -го, напрмер , то менять только на активен с 29-го . Т.е менять все в будущем , кроме приостановленных .

Нам нужно полное управление статусами. Зачем? Вот самая банальная причина - в комментарии к статусу может быть некая важная информация. Удалив автоматически этот статус вы оставите наших операторов и нашу автоматику без этой информации.

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

Да что значит отключаемая автоматика . отключаемая автоматика , это вообще нечего со статусами не делать . Если со статусами что-то делать, то это уже автоматика и я вас спрашиваю алгоритм для этой автоматики. я там привел 2 варианта развтития событий . Вам насколько я понимаю нужен 1-ы. т.е по любому будет активен с 29-го, даже если у него кончились деньги, раньше этого срока . такой будущий подарок , несмотря не на что

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

Вопрос со статусами очень скользкий. Предположить (не нафантазировать, а именно предположить), что понадобится через год - очень тяжело. Поэтому и свои требования к системе статусов мы стараемся предъявить наиболее универсально.

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

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

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

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

Кредитового тоже выключают статусом. Автоматика может рубить кредитового по исчерпанию лимита. Могут переключать клиента из кредита в дебет. Не угадаешь тут как, что и куда повернут. А затертый статус с комментарием уже не вернуть.

мы можем сделать галочку "ничего - не делать со статусами в будущем" .сами будите это расхлёбывать.

Так мы это и просили под названием "отключаемая автоматика"

Прошлые статусы, надеюсь, никому не пришло в голову перетирать?

Так до чего в итоге договорились?
Делаем настройку в конфиге - галочку с логикой "отключить перетирание статуса "приостановлен""? И если включено, то перетирать всё как раньше, кроме статуса "приостановлен", который останется на своём месте?
И даже оператор не должен мочь перетереть?

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

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

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

Проблема в основном не при перетирании из клиента или ЛК, а при стандартных действиях биллинга: открытие дебетного договора по приходу платежа, закрытие дебетного договора, etc (не могу пока ничего вспомнить)

Это всё в ту же кучу - во всех этих действиях происходит вызов одного и того же метода changeStatus. И пока точно никто не сказал, как именно должно и при каких случаях работать.
Пока, помимо варианта с полным перетираением всего и вся есть два реальных:
1) Всё и вся перетирается, кроме статуса "приостановлен". Это уже обсуждено в хелпдеске и скорее всего реализуется так или иначе. Будет отключаемо.
2) Плюс повешение скрипта на событие, чтобы логику перетирания можно было реализовать там. Логика срабатывает и при автоматической смене статуса и при смене из клиента и при смене из веба. Можно обрабатывать по-разному, конечно. Сейчас это один метод.

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

Да, скрипт это слишком оголтело, пожалуй. Не будем делать скриптом.

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

Хорошо ..Но в идеале отключить автоматику - это значит , что вообще ничего не делаем. Т.е меняете статус сегодня ..и СЕГОДНЯ и ТОЛЬКО сегодня он меняется. А завтра и тп он остаётся старым ..вдумайтесь в это ..вы хотите этого ?
Пример:
с01.07.2010 - 10.07.2010 - активен
11.07.2010 - 20.07.2010 - приостанолвлен
с 21.07.2010 - активен

И тут его закрывает по балансу 6-го числа .. Становится так

с 01.07.2010 - 05.07.2010 - активен
с 06.07.2010 - 06.07.2010 - закрыт
с 07.07.2010 - 10.07.2010 - актвивен // внимание - ( вы точно этого хотите ??? ) .мы же не меняем статус в будущем или как ? или все-таки меняем ?
11.07.2010 - 20.07.2010 - приостановлен
с 21.07.2010 - активен //а тут вы точно уверены ?

Или вы хотите так ?
с 01.07.2010 - 05.07.2010 - активен
с 06.07.2010 - 10.07.2010 - закрыт
11.07.2010 - 20.07.2010 - приостановлен
с 21.07.2010 - активен //мне этоn вариант тоже не нравится

Покажите на это конкретном примере .как работает ваша отключаемая автоматика ? а то я додумываю, додумываю . А вы сами может сами на этом конкретном примере
показать как должна отработать "отключаемая автоматика "? я пока не могу понять что вы хотите . вот helpdesk -е нам точно сказали, хотим чтобы статусы приостановлен не перетирались , остальное перетиралось .Это и реализуем .. ждем более внятного объяснения от вас

vote for this

Всё думаю, как можно обобщить такие вещи.
Например, можно каждому статусу в contract_status назначать его приоритет в виде числа. Сделать перегружаемый changeStatus с этим параметром, который перетирает только те статусы, приоритет которых ниже или равен заданному. Старый changeStatus будет запускать новый с приоритетом по умолчанию(?) А дальше задавать в конфигах набор приоритетов по умолчанию для каждого значения статуса. В конфиге задачи "Закрытие статуса NPAY догоаоров по балансу" задать приоритет устанавливаемого статуса "закрыт". Для открытия по платежу тоже указать приоритет статуса "активен" в глобальном конфиге. Далее для любой автоматики добавлять возможность указать статус через соответствующий конфиг.
Как-то так...

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

Может, лучше сделать квадратную матрицу из 1/0, по вертикали статусы с какого, по горизонтали - каким может перетираться. Как-то с приоритетами и сложнее и менее гибче, имхо.

То есть текущая ситуация:

ACTIVE = 1 1 1 1 1 1
IN_DISCONNECT = 1 1 1 1 1 1
DISCONNECTED = 1 1 1 1 1 1
CLOSED = 1 1 1 1 1 1
SUSPENDED = 1 1 1 1 1 1
IN_CONNECT = 1 1 1 1 1 1

"Перетираются все, кроме SUSPENDED":

ACTIVE = 1 1 1 1 1 1
IN_DISCONNECT = 1 1 1 1 1 1
DISCONNECTED = 1 1 1 1 1 1
CLOSED = 1 1 1 1 1 1
SUSPENDED = 0 0 0 0 0 0
IN_CONNECT = 1 1 1 1 1 1

Вопрос такой: а что должно означать НЕперетирание? То есть разрывание промежутка на несколько частей? Если у нас например, с 2 по 4 засуспенден, а мы ставим с 1 по 10 закрыть? Что должно произойти? 1 закрыто, 2-4 суспенден, 5-10 закрыто? Как-то всё хитро получается.

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