BiTel

У наших абонентов могут быть установлены как аналоговые так и цифровые телефоны. Абонентская плата разная.
Как правильно организовать начисление соответствующих абон. плат если у одного абонента например три цифровых и два аналоговых телефона?

Сейчас мы используем разные экземляры модуля "Телефония" для ведения списков аналоговых и цифровых номеров и соответственно услуги "Доступ к ТФОП" и "Доступ к ТФОП цифровой".
Хотелось бы избавиться от такого минуса, как необходимость смотреть список звонков в отдельных закладках (в зависимости от вида линии) и дублирования веток тарифов и услуг типа "Звонки на местные сотовые" и "МН и МГ связь".
Мы также пробовали использовать субдоговора, но в таком случае критично неудобно выяснять, какие же телефонные номера задействованы для данного абонента и смотреть списки звонков по ним.
Оптимальным видится некий признак у поинта и возможность в тарифе задать свою цену абон.платы у такого поинта, потому как ничем, кроме величины абон.платы цифровая линия от аналоговой не отличается. (При биллинговании, разумеется :) ) Но, насколько я понимаю, такого функционала пока нет и отсюда вопрос: есть ли более удобные варианты и какие?

Нас (по крайней мере, как временный вариант) устроил бы модифицированный вариант этой вот "техники"

где вместо bitel.billing.server.npay.bean.PhoneModuleQuantity
использовался бы класс, способный фильтровать поинты по содержимому поля комментария.
Что то вроде:

Если имеет смысл передвинуть данную тему в раздел "Пожелания", то как это сделать?

Вы можете использовать 2 типа абонплат и использовать объекты для связки абонплат с номерами телефонов.. Или это неудобно?

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

Ну привязывайте к этим же объектам абонплаты номера.

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

Нет..

То есть вы предлагаете для каждого телефонного номера создавать свой объект и уже на этот объект назначать те или иные услуги?
Я правильно понял?

Да.

Получается, что если у абонента 130 аналоговых телефонов, 65 цифровых, на 50 цифровых и на 120 аналоговых действуют услуги переадресации, удержания линии, то в договор нужно ввести:
195 объектов,
130 раз услугу "доступ к ТФОП",
65 раз услугу "доступ к ТФОП цифровой",
170 раз услугу переадресации,
170 раз услугу удержания линии.
Общее количество строк в таблице договора услуги модуля "Абонплата": 535

Так?

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

Я не пойду с этим в абон. отдел. Жить хочется.

У вас же есть функционал bitel.billing.server.npay.bean.PhoneModuleQuantity - он делает достаточным для правильного расчета абон.плат ввод нужного количества поинтов - удобно и логично для АСР.
Почему бы его не расширить, как я предложил в начале темы, или как-то по другому (например, что бы события генерировались при тарификации абонплат)?
Неужели мы единственный оператор, использующий BGBilling, с потребностью обсчитывать разный состав абонплат на поинтах в одном договоре...

Может тогда добавить какие-то признаки в телефонные номера?
Типа состав доп. услуг.. Просто поиск по комментарию:
1) некрасиво
2) возможны ошибки при забитии
3) низкопроизводителен
Либо может сделать более прозрачным редактирование объектов? Этот механиз более идеологически верен и расширяем. Как было бы вам удобно забивать данные?

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

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

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

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

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

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

1, 2, 3 пункты - конечно можно сделать...
А вот с четвертым... На эти сотни строк привязки объектов к услугам нужно не только смотреть. Необходимо их еще редактировать и проверять. От того, что эти сотни строк распределятся по закладкам объектов, обозримость назначенных на договор услуг не улучшится.

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

Если моя догадка верна, то пусть будут пункты 1, 2, 3. Это выглядит лучше, чем сейчас.

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

Я именно о периоде валидности значения параметра объекта.

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

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

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

Но вопрос другой:
Можем ли мы расчитывать на реализацию означеных трех пунктов? И если можем, то на какие сроки ориентироваться?

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

Ждем.
Пока будем комбинировать экземпляры модулей Phone и объекты.

Все еще комбинируем. Возник вопрос: при использовании quantity считаются все поинты модуля или учитывается распределение поинтов по объектам? Пока получилось следующее:
Две связки поинт-объект-абонплата и quantity в настройках модуля NPAY привели к тому, что абонплата посчиталась 4 раза.

quantity - количество поинтов на договоре.

А можно что бы считалось количество поинтов в связке поинт-объект-абонплата? Чтобы не создавать 30 объектов с одинаковыми абонплатами для 30 поинтов?

В 4.5 версии будет возможно привязки к поинту абонплат и тарифов. Исходя из этого чего еще будет недостаточно?

То есть если в договоре 30 поинтов с переадресацией и 20 без, то нужно будет 50 раз назначить услуги?

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

Ну, я несколько иначе предлагал. Делать 30 объектов и у каждого одну и ту же услугу - абонплату + поинт.

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

Если у вас 30 номеров с одинаковым набором услуг, может этот набор определить в какую-то абонплату и вешать каждому номеру по одной этой абонплате - пакету. Сменился тип номера - сменили абонплату- пакет.

Комбинация quantity и объектов как раз позволяет обойтись без 30 объектов...
А с пакетами все хорошо, пока пакеты соответсвуют пакетам услуг в прайсе. А если придется комбинировать в пакеты услуги, которые в прайсе отдельно - может получиться неприятное количество псевдо-пакетов (например имеем в прайсе пять доп. услуг - сколько получается комбинаций?)

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

Объект как признак одинаковых свойств. Или что-то вроде того. Но я отталкивался от объектов исходя из вашей "концепции".
Если посмотреть на задачу без учета уже реализованного функционала, то перспективно смотриться (с моей точки зрения, разумеется) возможность создать базовый поинт, назначить на него услуги, а реальные поинты наследовать от базового. Либо использовать шаблон "такой же как". Работает же такой механизм в тарифах.

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