BiTel

Добрый день!

Никак не могу понять, как в биллинге реализуются действия над группами договоров! Не в теории (с этим все ясно), а на практике.

Допустим мне надо посмотреть сколько в биллинге договоров тарифа A. Простая и нужная задача. Захожу в отчеты, отчет по договорам.... там нет фильтра по тарифам. Но есть фильтр по группам.
Вторая задача - мне надо перевести всех пользователей тарифа A на тариф B. Захожу в сервис, групповые операции, смена тарифа. Все OK, но сначала, нужно найти договора, а для этого нужно зайти в договор, открыть договор, но и там нет фильтра по тарифам! Но есть фильтр по группам.

Логика разработчиков становится понятна - я создаю группы с такими же названиями, что и тарифы (удивляет только очень ограниченное количество возможных групп), добавляю пользователей тарифа A в группу A и начинаю с ними работать.

Но, после первого же действия (смена тарифа), все рассинхронизируется! А если еще пользователь сам поменяет себе тариф?

Если все в биллинге завязано на группы, как группы привязать к ПРЯМЫМ свойствам договора (хотя бы к текущему тарифу)?

Может я чего-то не догоняю?

Спасибо заранее!

если вам надо всех пользователей тарифа А перевести на тариф Б, не проще просто поменять тариф А на Б

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

Хм... ну почему же - логика простая: для всех договоров, у которых среди тарифов присутствует тариф A, поменять его на тариф B. Хотя, в принципе, можно действительно поменять прямо тариф...

Ну хотя бы просто посмотреть количество договоров с каким-то тарифом можно штатными средствами? Это было бы очень удобно.

В модуле отчетов есть отчет по тарифам.

Итак, конец месяца - у нас смена тарифных планов, соответственно, у меня есть конкретная задача из реальной жизни. И я в затруднении...

сейчас есть тарифы (опуская детали):
А1, А2, А3, А4
делаем новые:
Б1, Б2, Б3, Б4
меняем по схеме:
А1 -> Б2
А2 -> Б4
А3 -> Б3
А4 -> Б3

Почему так? Потому, что в этом случае стоимости новых и старых тарифов совпадают и клиент по умолчанию платит как платил, но получает большую скорость или трафик. Если же он хочет перейти на другой тариф (например с меньшей стоимостью - он это сделает сам когда захочет). Новый тариф Б1 имеет цену ниже чем самый дешевый старый тариф и поэтому на него автоматом никого не переводим.
Такая схема очень практична, так как при снижении тарифов не дает резкого скачка в доходах в сторону понижения, если клиенты и переходят на более дешевые тарифы, то убыток компенсируется ростом абон базы.

Просто изменить тарифы я не могу так как есть новый тариф Б3, на который мне нужно перевести сразу два тарифа А3 и А4....
Если делать через групповые операции - то сначала я должен найти пользователей для которых хочу поменять тариф, а поиска по старому (текущему) тарифу нет - есть только поиск по группам. Хорошо, что у меня есть у каждого пользователя группа соответствующая текущему тарифу. Делаю поиск по группам, захожу в групповые операции, меняю тариф А3 на Б3. Повторяю для тарифа А4. Но как теперь выправить соответствие групп тарифам - через какое-то время мне же придется опять менять тарифы и соответствие групп тарифам опять может оказаться нужным. Групповой операции смены группы нет... Если просто переименовать группу А3 в Б3. Но что делать с группой А4?

Вообщем.... Как же менять тарифы?

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

Отлично! Спасибо за совет!

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

"обычно просто периоды в самом тарифе делают" - а вот это не понял, можно чуть подробнее, плз.

Там же есть ветка период. Ее можно использовать, если у тарифа что-то изменилось. Не во всех случаях конечно, особенно если надо объединить два тарифа в один.

Вообщем - переехал я на новые тарифы успешно, спасибо за помощь!

Но есть еще вопрос:

теперь у меня рассинхрованы группы и тарифы и мне их надо снова синхронизировать.

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

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

Спасибо заранее!

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

Это будет убрать группу с кодом 6 из договора. Там битовая маска.

какая интересная тема ... при чем она далеко не одинока (1, 2, 3)

А почему при изменении цен в тарифе вы не используете узел "Период"? Он вроде для этого и предназначен..

пожалуй есть 2 основных причины:

1. в достаточно разветвленном дереве тарифов невозможно использовать некоторые возможности которые есть только в самом начале ветвей, например типы времени, радиус атрибуты и т.д. и т.п. (тема об этом) и даже если все это будет возможно - см. п.2
2. юзер должен видеть (ему так понятнее) что у него был тариф "ААА", а стал "БББ", а, к сожалению, имена тарифов нельзя менять узлом "период" и даже если и будет возможно - чтобы узнать какой тариф действовал в ту или иную дату - надо будет лезть в дерево чтобы увидеть всю историю смены имен

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

P.S. я правильно понимаю что кол-во пользователей в тарифах можно узнать вот таким запросом?

может сделаете какой нить пункт меню вызвав который можно было бы увидеть такую табличку не покупая модуль отчетов? дело даже не в его цене, а в том что, IMHO, сухая статистика должна быть неотъемлемой частью ядра, а модуль отчетов пусть предоставляет более глубокие аналитические данные, раз уж Вы не хотите сделать его такой же частью ядра как trayInfo и карточки

2 snark . вам нужно количество - так можете сделать себе такой отчет в модуле отчетов и выложить его в wiki. какая вам разница смотреть это в модуле отчетов или видеть эту "сухую аналитику" в ядре ?

сделать и выложить - не вопрос! вопрос в том как заставить начальство выделить по сути сущие копейки на модуль отчетов, чтобы уже в нем отчеты делать, а не в виде php страничек