Обсуждения изменения функционала блокировок.
Обсуждения изменения функционала блокировок.
Реализация механизма блокировок с версии 009 не пригодна для использования. (это мое личное мнение основанное на моих потребностях, а так же сложившееся по итогам обсуждений с представителями других провайдеров.)
Продублирую из соседней темы
Вводные данные для пересмотра текущего функционала блокировок и перерасчета, как я их вижу:
- необходим механизм, который позволит не списывать абонентскую плату с абонента при отсутствии достаточного количества средств на лицевом счете и блокировать счет спец. типом блокировки до поступления средств
- механизм должен сочетаться с текущим функционалом с минимальными последствиями для операторов в случае обновления биллинга
- функционал возврата средств очень сложен к пониманию (и местами к реализации в UTM5) и требует как минимум упрощения
Вводные данные для пересмотра текущего функционала блокировок и перерасчета, как я их вижу:
- необходим механизм, который позволит не списывать абонентскую плату с абонента при отсутствии достаточного количества средств на лицевом счете и блокировать счет спец. типом блокировки до поступления средств
- механизм должен сочетаться с текущим функционалом с минимальными последствиями для операторов в случае обновления биллинга
- функционал возврата средств очень сложен к пониманию (и местами к реализации в UTM5) и требует как минимум упрощения
Для начала давайте опишем глобальные задачи, без возврата жили 10 лет и еще год проживем, а с перерасчетами мы на новую версию биллинга перейти не можем.
Вот например:
Либо рассмотреть ввод такого режима:
Вариант 1
- Биллинг проводит все запланированные списания и перерасчеты в текущем РП
- Приостанавливает списание средств по всем услугам,
- Переводит абонента на новый РП
- Запускает пользовательский скрипт для пользователя, в котором мы как что нам надо то и реализуем.
Вариант 2
- Биллинг проводит все запланированные списания и перерасчеты в текущем РП.
- Приостанавливает списание средств по всем услугам, путем установки особого типа блокировки регламентированной по продолжительности, по истечении которой особая блокировка снимается.
- Переводит абонента на новый РП
- Мы сторонними средствами производим поиск пользователей у которых стоит особая блокировка и реализуем то что нам требуется.
т.е. в этом случает особая блокировка или сама сгорит по истечении регламентированного срока, или мы ее заменим на другую блокировку которая нам требуется.
Вот например:
Механизм, должен запускаться в момент закрытия РП, берем баланс, смотрим какие услуги переходят на следующий расчетный период, суммируем их стоимость, если денег не хватает, ставим блокировку на каждую услугу в зависимости от указанного типа следующей блокировки.- необходим механизм, который позволит не списывать абонентскую плату с абонента при отсутствии достаточного количества средств на лицевом счете и блокировать счет спец. типом блокировки до поступления средств
Либо рассмотреть ввод такого режима:
Вариант 1
- Биллинг проводит все запланированные списания и перерасчеты в текущем РП
- Приостанавливает списание средств по всем услугам,
- Переводит абонента на новый РП
- Запускает пользовательский скрипт для пользователя, в котором мы как что нам надо то и реализуем.
Вариант 2
- Биллинг проводит все запланированные списания и перерасчеты в текущем РП.
- Приостанавливает списание средств по всем услугам, путем установки особого типа блокировки регламентированной по продолжительности, по истечении которой особая блокировка снимается.
- Переводит абонента на новый РП
- Мы сторонними средствами производим поиск пользователей у которых стоит особая блокировка и реализуем то что нам требуется.
т.е. в этом случает особая блокировка или сама сгорит по истечении регламентированного срока, или мы ее заменим на другую блокировку которая нам требуется.
По возврату: больше интересует механизм возврата через URFA (хотя бы только в рамках текущего РП), где можно указать кому, сколько и какой услугой провести (т.е. на какую сумму уменьшить списание по услуге в текущем РП), запускать можно было бы через rfw по событию на снятие блокировки.
Тогда бы и блокировки переделывать не надо было бы, поставить всем "Перерасчитывать всегда" и раскидывать лишнее через скрипт.
ЗЫ Это же решит проблему с перерасчетами, так как ну неправильно перерасчитывать через пополнение баланса, так как доходы по услугам отражаются некорректно.
Тогда бы и блокировки переделывать не надо было бы, поставить всем "Перерасчитывать всегда" и раскидывать лишнее через скрипт.
ЗЫ Это же решит проблему с перерасчетами, так как ну неправильно перерасчитывать через пополнение баланса, так как доходы по услугам отражаются некорректно.
Если вы это сделаете, то, видит Бог, я обещаю целый год не употреблять название вашего биллинга с плохими словами в одном предложении! Я уверен, у огромного количества пользователей есть подпорки, пробегающие по пользователям в 23:5х минут с целью заблокировать их.serjk писал(а):
- необходим механизм, который позволит не списывать абонентскую плату с абонента при отсутствии достаточного количества средств на лицевом счете и блокировать счет спец. типом блокировки до поступления средств
Еще есть один нюанс, нигде нельзя указать дефолтный тип блокировки у заведенной услуги.
Например ТП содержит несколько услуг:
1) Услуга ничего не делать
2) Услуга перерасчитывать
В какой то момент времени понадобилось мне полностью заблокировать счет, для этого я проверяю все услуги меняю по надобности тип следующего списания на "Перерасчитывать" и ставлю админскую блокировку. Через пару дней мне необходимо разблокировать счет, и тут я задумываюсь, а в как были ранее выставлены услуги?
По идее наверное было бы удобно при заведении конкретной услуги сразу обозначить методы перерасчета при системной блокировки пользователя, при административной и при отсутствии блокировки.
т. е. если стоит не определено, то в момент установки той или иной блокировки, тип перерасчета не меняем, а если что-то выбрано то выставляем в данный тип.
Например ТП содержит несколько услуг:
1) Услуга ничего не делать
2) Услуга перерасчитывать
В какой то момент времени понадобилось мне полностью заблокировать счет, для этого я проверяю все услуги меняю по надобности тип следующего списания на "Перерасчитывать" и ставлю админскую блокировку. Через пару дней мне необходимо разблокировать счет, и тут я задумываюсь, а в как были ранее выставлены услуги?
По идее наверное было бы удобно при заведении конкретной услуги сразу обозначить методы перерасчета при системной блокировки пользователя, при административной и при отсутствии блокировки.
т. е. если стоит не определено, то в момент установки той или иной блокировки, тип перерасчета не меняем, а если что-то выбрано то выставляем в данный тип.
Ну оно не совсем сломалось, пусть оно всегда будут установленно как "Ничего не делать" перед установкой блокировки (клиент уехал в отпуск) ставим тип перерасчета при следующей блокировки как "Перерасчитывать" и блокируем счет.kirush писал(а):Присоединяюсь. С момента перехода на 008 сломалась такая простая реализация тарифа:
Пример:
1) Абонентская плата списывается всегда независимо от баланса и подключенных услуг.
2) При установке блокировки (клиент уехал в отпуск), абонентская плата не должна списываться в период блокировки.
Проблема в другом, блокировка с типом "Перерасчитывать" возможна только один раз в расчетном периоде.. Все остальное можно решить скриптами, но вот этот момент не позволяет обновить биллинг.
Разработчики выпустите в update3 патч на эту фичу, и объясните мне для чего введено было такое ограничение..
При установке такого вида блокировки, не возвращаются средства при окончании блокировки или починили?Ну оно не совсем сломалось, пусть оно всегда будут установленно как "Ничего не делать" перед установкой блокировки (клиент уехал в отпуск) ставим тип перерасчета при следующей блокировки как "Перерасчитывать" и блокируем счет.
Они и не должны возвращаться, тип "Перерасчитывать" не списывает абон плату во время блокировки, но работает один раз в периоде.kirush писал(а):При установке такого вида блокировки, не возвращаются средства при окончании блокировки или починили?Ну оно не совсем сломалось, пусть оно всегда будут установленно как "Ничего не делать" перед установкой блокировки (клиент уехал в отпуск) ставим тип перерасчета при следующей блокировки как "Перерасчитывать" и блокируем счет.
-
BasilKlyev
- Сообщения: 15
- Зарегистрирован: Чт ноя 24, 2011 06:39
Самая главная фича необходимая в работе.serjk писал(а):- необходим механизм, который позволит не списывать абонентскую плату с абонента при отсутствии достаточного количества средств на лицевом счете и блокировать счет спец. типом блокировки до поступления средств
UPD 18.10.2013 А когда планируется выпуск версии с таким функционалом ?
Затянули немного с ТЗ. Вот что получилось.
Проект изменений по функционалу периодических списаний.
1. Вводится разделение на системные, пользовательские, административные блокировки (перечислены в порядке возрастания приоритета)
2. В данный момент времени может существовать несколько блокировок лицевого счета (не более одной каждого типа). При этом действует блокировка с наивысшим приоритетом. При удалении этой блокировки, вступает в действие блокировка с более низким приоритетом.
3. В систему вводится новая сущность "Политика списаний". Каждая сервисная связка ссылается на одну из политик, заведенных в системе. Политика данной сервисной связки может быть выбрана в произвольный момент времени, так же может быть изменена сама сущность политики. При изменении политики, текущие настройки пересчета для данной сервисной связки действуют до конца текущей блокировки.
4. Политика списаний включает в себя следующие настройки
4.1 Параметры пересчета для каждого из типов блокировок (админская, пользовательская, системная)
a) не списывать абонентскую плату в блокировке
б) пересчитывать абонентскую плату
в) уменьшать предоплаченный трафик
4.2 Параметры блокировки
а) устанавливать системную блокировку при недостатке средств
[Если данный параметр установлен, перед проведением периодических списаний с типом "в начале РП", "плавный" проверяется достаточность средств на лицевом счете для проведения списания. В начале РП проверка производится для всех сервисных связок данного лицевого счета, привязанных к данному РП, у которых параметр 4.2а установлен. Если средств недостаточно, лицевой счет блокируется системной блокировкой до проведения списаний. Поведение списаний по счету в состоянии системной блокировки определяется политикой каждой из сервисных связок]
б) проверять разблокировку - список временных точек (например 9:00, 21:00)
[в случае, если лицевой счет был заблокирован до проведения списания и на нем имеются средства, в некоторой момент времени пересчитанный в состоянии блокировки размер абонентской платы может стать достаточен для разблокировки счета и проведения списания]
4.3 Параметры возврата средств
[параметры определяют, возвращать ли средства на лицевой счет в случае, если в результате пересчета абонентской платы в состоянии блокировки в течение данного расчетного периода средства были списаны излишне]
a) возвращать при снятии блокировки
б) возвращать при внесении платежа
в) возвращать в конце расчетного периода
г) возвращать при удалении сервисной связки
5. В свойствах лицевого счета добавляется флаг "включать интернет при выходе из блокировки"
Проект изменений по функционалу периодических списаний.
1. Вводится разделение на системные, пользовательские, административные блокировки (перечислены в порядке возрастания приоритета)
2. В данный момент времени может существовать несколько блокировок лицевого счета (не более одной каждого типа). При этом действует блокировка с наивысшим приоритетом. При удалении этой блокировки, вступает в действие блокировка с более низким приоритетом.
3. В систему вводится новая сущность "Политика списаний". Каждая сервисная связка ссылается на одну из политик, заведенных в системе. Политика данной сервисной связки может быть выбрана в произвольный момент времени, так же может быть изменена сама сущность политики. При изменении политики, текущие настройки пересчета для данной сервисной связки действуют до конца текущей блокировки.
4. Политика списаний включает в себя следующие настройки
4.1 Параметры пересчета для каждого из типов блокировок (админская, пользовательская, системная)
a) не списывать абонентскую плату в блокировке
б) пересчитывать абонентскую плату
в) уменьшать предоплаченный трафик
4.2 Параметры блокировки
а) устанавливать системную блокировку при недостатке средств
[Если данный параметр установлен, перед проведением периодических списаний с типом "в начале РП", "плавный" проверяется достаточность средств на лицевом счете для проведения списания. В начале РП проверка производится для всех сервисных связок данного лицевого счета, привязанных к данному РП, у которых параметр 4.2а установлен. Если средств недостаточно, лицевой счет блокируется системной блокировкой до проведения списаний. Поведение списаний по счету в состоянии системной блокировки определяется политикой каждой из сервисных связок]
б) проверять разблокировку - список временных точек (например 9:00, 21:00)
[в случае, если лицевой счет был заблокирован до проведения списания и на нем имеются средства, в некоторой момент времени пересчитанный в состоянии блокировки размер абонентской платы может стать достаточен для разблокировки счета и проведения списания]
4.3 Параметры возврата средств
[параметры определяют, возвращать ли средства на лицевой счет в случае, если в результате пересчета абонентской платы в состоянии блокировки в течение данного расчетного периода средства были списаны излишне]
a) возвращать при снятии блокировки
б) возвращать при внесении платежа
в) возвращать в конце расчетного периода
г) возвращать при удалении сервисной связки
5. В свойствах лицевого счета добавляется флаг "включать интернет при выходе из блокировки"