forum.bitel.ru
http://forum.bitel.ru/

Разные абонплаты для цифровых и аналоговых линий
http://forum.bitel.ru/viewtopic.php?f=16&t=549		 Страница 1 из 1
Автор:  vdd [ 16 ноя 2007, 17:04 ]
Заголовок сообщения:  Разные абонплаты для цифровых и аналоговых линий
У наших абонентов могут быть установлены как аналоговые так и цифровые телефоны. Абонентская плата разная.
Как правильно организовать начисление соответствующих абон. плат если у одного абонента например три цифровых и два аналоговых телефона?

Сейчас мы используем разные экземляры модуля "Телефония" для ведения списков аналоговых и цифровых номеров и соответственно услуги "Доступ к ТФОП" и "Доступ к ТФОП цифровой".
Хотелось бы избавиться от такого минуса, как необходимость смотреть список звонков в отдельных закладках (в зависимости от вида линии) и дублирования веток тарифов и услуг типа "Звонки на местные сотовые" и "МН и МГ связь".
Мы также пробовали использовать субдоговора, но в таком случае критично неудобно выяснять, какие же телефонные номера задействованы для данного абонента и смотреть списки звонков по ним.
Оптимальным видится некий признак у поинта и возможность в тарифе задать свою цену абон.платы у такого поинта, потому как ничем, кроме величины абон.платы цифровая линия от аналоговой не отличается. (При биллинговании, разумеется :) ) Но, насколько я понимаю, такого функционала пока нет и отсюда вопрос: есть ли более удобные варианты и какие?
Автор:  vdd [ 20 ноя 2007, 16:37 ]
Заголовок сообщения: 
Нас (по крайней мере, как временный вариант) устроил бы модифицированный вариант этой вот "техники"
Код:
module.quantity.1.mid=2
module.quantity.1.class=bitel.billing.server.npay.bean.PhoneModuleQuantity
module.quantity.1.sids=1

где вместо bitel.billing.server.npay.bean.PhoneModuleQuantity
использовался бы класс, способный фильтровать поинты по содержимому поля комментария.
Что то вроде:
Код:
module.quantity.1.mid=2
module.quantity.1.class=bitel.billing.server.npay.bean.PhoneModuleQuantityFiltered
module.quantity.1.sids=1
module.quantity.1.filter=D

Если имеет смысл передвинуть данную тему в раздел "Пожелания", то как это сделать?
Автор:  Администратор [ 20 ноя 2007, 18:19 ]
Заголовок сообщения: 
Вы можете использовать 2 типа абонплат и использовать объекты для связки абонплат с номерами телефонов.. Или это неудобно?
Автор:  vdd [ 20 ноя 2007, 18:42 ]
Заголовок сообщения: 
Мы используем объекты для привязки номеров к узлам сети.
У нас еще есть сервисные пакеты с абонентской платой (переадресация, ожидание вызова и т.п.). Пакет может быть активирован как на цифровой, так и на аналоговой линии.
Как быть в этом случае?
Может ли номер быть привязан к нескольким объектам?
Автор:  Администратор [ 20 ноя 2007, 19:26 ]
Заголовок сообщения: 
Цитата:
Мы используем объекты для привязки номеров к узлам сети.

Ну привязывайте к этим же объектам абонплаты номера.
Цитата:
У нас еще есть сервисные пакеты с абонентской платой (переадресация, ожидание вызова и т.п.). Пакет может быть активирован как на цифровой, так и на аналоговой линии.
Как быть в этом случае?

Ну добавлять еще абонплаты, привязывая их к тому же объекту что и телефонный номер.
Цитата:
Может ли номер быть привязан к нескольким объектам?

Нет..
Автор:  vdd [ 20 ноя 2007, 19:55 ]
Заголовок сообщения: 
То есть вы предлагаете для каждого телефонного номера создавать свой объект и уже на этот объект назначать те или иные услуги?
Я правильно понял?
Автор:  Администратор [ 22 ноя 2007, 18:57 ]
Заголовок сообщения: 
Да.
Автор:  vdd [ 22 ноя 2007, 19:11 ]
Заголовок сообщения: 
Получается, что если у абонента 130 аналоговых телефонов, 65 цифровых, на 50 цифровых и на 120 аналоговых действуют услуги переадресации, удержания линии, то в договор нужно ввести:
195 объектов,
130 раз услугу "доступ к ТФОП",
65 раз услугу "доступ к ТФОП цифровой",
170 раз услугу переадресации,
170 раз услугу удержания линии.
Общее количество строк в таблице договора услуги модуля "Абонплата": 535

Так?
Автор:  Администратор [ 22 ноя 2007, 19:37 ]
Заголовок сообщения: 
Да, проще не получится. Объекты обзывать так же как и номера. Дополнительно можно ввести там параметры с адресом, кто подключал, когда подключал и пр.
Автор:  vdd [ 23 ноя 2007, 11:22 ]
Заголовок сообщения: 
Я не пойду с этим в абон. отдел. Жить хочется.

У вас же есть функционал bitel.billing.server.npay.bean.PhoneModuleQuantity - он делает достаточным для правильного расчета абон.плат ввод нужного количества поинтов - удобно и логично для АСР.
Почему бы его не расширить, как я предложил в начале темы, или как-то по другому (например, что бы события генерировались при тарификации абонплат)?
Неужели мы единственный оператор, использующий BGBilling, с потребностью обсчитывать разный состав абонплат на поинтах в одном договоре...
Автор:  Администратор [ 23 ноя 2007, 14:25 ]
Заголовок сообщения: 
Может тогда добавить какие-то признаки в телефонные номера?
Типа состав доп. услуг.. Просто поиск по комментарию:
1) некрасиво
2) возможны ошибки при забитии
3) низкопроизводителен
Либо может сделать более прозрачным редактирование объектов? Этот механиз более идеологически верен и расширяем. Как было бы вам удобно забивать данные?
Автор:  vdd [ 23 ноя 2007, 15:32 ]
Заголовок сообщения: 
Поиск по комментарию был предложен в качестве workaround. Грязно, но быстро реализуем.

Меня бы устроило следующее:
1) Произвольные параметры у поинтов. (Аналогично произвольным параметрам договора или группам договора)
2) Возможность использовать значение этих параметров при создании ветки "Абонплата" тарифа

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

Тот механизм объектов, который виден сейчас, легко приводит к сотням строк в таблице услуг. (Имеется ввиду GUI)

Если будет реализована возможность использовать значения параметров объекта, а не поинта, при создании тарифов, то тогда хотелось бы, что бы объекты можно было создавать "ближе" к месту создания поинтов, чем это происходит сейчас.
Автор:  Администратор [ 26 ноя 2007, 15:19 ]
Заголовок сообщения: 
А если сделать так:
1) Оставить объекты но сделать в гуи несколько мест для их редактирования
2) В свойствах поинта сделать закладку Объект, отображающую свойства привязанного объекта
3) В свойствах объекта добавить редактирование абонплат. Открытие/закрытие.
4) Те сотни строк которые торчат в договоре оставить, просто не смотреть на них..
Автор:  vdd [ 26 ноя 2007, 17:51 ]
Заголовок сообщения: 
1, 2, 3 пункты - конечно можно сделать...
А вот с четвертым... На эти сотни строк привязки объектов к услугам нужно не только смотреть. Необходимо их еще редактировать и проверять. От того, что эти сотни строк распределятся по закладкам объектов, обозримость назначенных на договор услуг не улучшится.

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

Если моя догадка верна, то пусть будут пункты 1, 2, 3. Это выглядит лучше, чем сейчас.
Автор:  Администратор [ 26 ноя 2007, 18:30 ]
Заголовок сообщения: 
vdd писал(а):
Впрочем я, кажется, понимаю истоки стремления избежать привязки параметров объектов к услугам непосредственно в тарифах. В таком случае придется вводить период существования того или иного значения параметра объекта. А добавлять новый механизм в систему, без крайней нужды никому не хочется.

Не совсем. Не хочется многообразия видов объектов.. Т.е. внесем мы настраиваемые параметры в телефоны, выйдут те же объекты. А связывать напрямую модуль телефонии и абонок вообще не красиво.. Идеологической стройности хочется :) сейчас она есть, но удобства нет..
Автор:  vdd [ 26 ноя 2007, 19:12 ]
Заголовок сообщения: 
Я именно о периоде валидности значения параметра объекта.

Сейчас значение присваивается бессрочно. Следовательно, если создать тариф, в котором абонплата начисляется в зависимости от значения параметра объекта, то такую абонплату нельзя будет "включить" / "выключить" в произвольные моменты времени.

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

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

Но вопрос другой:
Можем ли мы расчитывать на реализацию означеных трех пунктов? И если можем, то на какие сроки ориентироваться?
Автор:  Администратор [ 27 ноя 2007, 15:11 ]
Заголовок сообщения: 
Задача в общем-то ясна, постараемся реализовать к следующей версии. Ориентировочный срок - от 2х месяцев.
Автор:  vdd [ 27 ноя 2007, 16:31 ]
Заголовок сообщения: 
Ждем.
Пока будем комбинировать экземпляры модулей Phone и объекты.
Автор:  vdd [ 03 июл 2008, 15:31 ]
Заголовок сообщения: 
Все еще комбинируем. Возник вопрос: при использовании quantity считаются все поинты модуля или учитывается распределение поинтов по объектам? Пока получилось следующее:
Две связки поинт-объект-абонплата и quantity в настройках модуля NPAY привели к тому, что абонплата посчиталась 4 раза.
Автор:  Администратор [ 03 июл 2008, 16:05 ]
Заголовок сообщения: 
quantity - количество поинтов на договоре.
Автор:  vdd [ 03 июл 2008, 16:19 ]
Заголовок сообщения: 
А можно что бы считалось количество поинтов в связке поинт-объект-абонплата? Чтобы не создавать 30 объектов с одинаковыми абонплатами для 30 поинтов?
Автор:  Администратор [ 03 июл 2008, 16:31 ]
Заголовок сообщения: 
В 4.5 версии будет возможно привязки к поинту абонплат и тарифов. Исходя из этого чего еще будет недостаточно?
Автор:  vdd [ 03 июл 2008, 17:57 ]
Заголовок сообщения: 
То есть если в договоре 30 поинтов с переадресацией и 20 без, то нужно будет 50 раз назначить услуги?

Если же отвечать точно на поставленый вопрос, то хотелось бы средство, которое позволяет сообщить системе, что вот эти 30 поинтов имеют одинаковый перечень тарифов и услуг за наименьшее количество операций с интерфейсом. Например назначить 30 поинтам один объект и назначить на этот объект нужные услуги проще, чем каждому из 30 поинтов назначать эти же услуги. Опять таки, если поинт переходит из первой 30 во вторую 20 с другими услугами, то достаточно переназначить поинту другой объект, а не закрывать-открывать все нужные услуги. И дело тут не в лени операторов, а в вероятностях совершения трудно обнаруживаемых ошибок при подобных операциях.
Кстати, это было ваше предложение - назначать услуги на объекты, а не на поинты. Решили подправить "концепцию"? :)
Автор:  Администратор [ 03 июл 2008, 19:05 ]
Заголовок сообщения: 
Цитата:
Кстати, это было ваше предложение - назначать услуги на объекты, а не на поинты.

Ну, я несколько иначе предлагал. Делать 30 объектов и у каждого одну и ту же услугу - абонплату + поинт.
Цитата:
Решили подправить "концепцию"?

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

Если у вас 30 номеров с одинаковым набором услуг, может этот набор определить в какую-то абонплату и вешать каждому номеру по одной этой абонплате - пакету. Сменился тип номера - сменили абонплату- пакет.
Автор:  vdd [ 03 июл 2008, 19:52 ]
Заголовок сообщения: 
Комбинация quantity и объектов как раз позволяет обойтись без 30 объектов...
А с пакетами все хорошо, пока пакеты соответсвуют пакетам услуг в прайсе. А если придется комбинировать в пакеты услуги, которые в прайсе отдельно - может получиться неприятное количество псевдо-пакетов (например имеем в прайсе пять доп. услуг - сколько получается комбинаций?)
Автор:  Администратор [ 04 июл 2008, 12:58 ]
Заголовок сообщения: 
Я так понял, вы хотите объекты использовать как признаки услуги.. Но тогда нужно поинт к нескольким объектам иметь возможность привязать?
Автор:  vdd [ 04 июл 2008, 13:47 ]
Заголовок сообщения: 
Объект как признак одинаковых свойств. Или что-то вроде того. Но я отталкивался от объектов исходя из вашей "концепции".
Если посмотреть на задачу без учета уже реализованного функционала, то перспективно смотриться (с моей точки зрения, разумеется) возможность создать базовый поинт, назначить на него услуги, а реальные поинты наследовать от базового. Либо использовать шаблон "такой же как". Работает же такой механизм в тарифах.

Если же отвечать точно на вопрос: с моей точки зрения поинт привязанный к нескольким объектам позволяет устоить не меньший кавардак, чем 50 поинтов, каждый со своим перечнем услуг и тарифов
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/