BiTel

Добрый день всем!

Уже предлагал такое кажется, ещё раз уточню.
Хочется, чтобы активность клиентов оперативно отражалась в биллинге, очень хочется. Есть очень простое решение этой задачи (у меня в прежнем биллинге такое было)

1. При установке конкретного модуля(если для модуля это имеет смысл) в таблицу contract добавляется поле lastBill<module>_<id> типа datetime. Например lastBillDialUP_1. И эта поле всякий раз будет обновляться при залогинивании/потреблении клиентом услуги этого модуля, т.е. в нем отражается последняя дата пользования услугами.
2) И общее поле lastBillDate сюда заносится дата последнего пользования любой из услуг.

Для чего это? Чтобы оперативно видеть активность клиента, и можно было легко отслеживать динамику пользования той или иной услугой за период. Это раз:)
Два: Предлагаю изменить (или добавить) Ваш "неинтересный" поиск договоров, добавив, помимо вывода номера договора, и комментария, столбец/столбцы lastbill.

Дело говорю! удобно будет. И Вам уж точно не сложно будет такое реализовать.

PS
Не предлагайте это перенести в модуль отчетов, создать такой отчёт самому, и т.д. (Уже создал, он не особо красивый, изза способа хранения данных в БД.) Это оперативная информация, и должна быть под рукой у ПОЛЬЗОВАТЕЛЕЙ биллинга.

С уважением!

Думаю данная информация операторам биллинга вообще не к чему! Данная инфа важна скорее всего руководству, и только за определённый период, а не постоянно!
Внесение дополнительных полей бред! Пользуйтесь отчётами!

Спасибо за Ваше мнение! Всеже по легче выражайся, и смотри шире.
Под "операторами" полагал всех пользователей биллинга!
Кто не пробовал, как говорится не поймёт. Вполне толковый функционал, и реализовать довольно легко. Не требую же переделать биллинг. Мне оно, как администратору тоже ни к чему! мне и клиент собственно не особо нужен! Здесь вопрос удобства, и легкости реализации!

PS
Скажи какой это отчёт мне посмотреть, чтобы узнать, когда клиент или группа клиентов последний раз пользовался произвольной услугой? Их активность?
Подскажи способ как вручную создать его, и не обязательно в среде клиента биллинга?

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

Юзер залогинился, или позвонил. (Для модулей IPN не актуально. Для телефонии помыслить можно). Фактическое потребление услуг. Списание средств не годится, потому что он может работать по абонентке (а абонплата имеет свойство начисляться в любом случае). Личный кабинет, это в общем, не потребление услуг.

Такое изменение предлагаю также и изза сложности по имеющейся структуре БД легко определить фактическую активность клиента. Можно было бы активность клиента определять, как последнюю запись в таблице contract_balance, однако в общем случае это не верно. Ну и, "активность" договора, это оперативная информация, и лучше её иметь под рукой.

Если честно не очень понимаю зачем это нужно.

См выше) чуть подредактировал .
Нужно для удобства. Крайней необходимости нет. Просто чтобы СРАЗУ видеть, клиент работающий, или нет. И при формировании отчётов "клиентов подключили, из них работает столько, не работает столько" и т.д.удобней!
Можно также в поиске выводить сразу баланс текущий, это вообще супер удобно) Хорошо!, текущую реализацию поиска, можно оставить, а добавить ещё "Расширенный поиск". С инфой о балансе, и датах о последних сессиях этих.


Удобство, епта!

все равно не понимаю например зачем в поиске нижен баланс и инфа о том активан клиент или нет. Мне кажется что вы хотите из поиска сделать оперативные отчеты... Если вам нужно найти какого то клиента и узнать по нему инфу, то я найдя его в поиске не трудно зайти в карточку и получить всю ИНФУ по клиенту, а не только активен он или нет (+баланс), а если вы хотите выбрать группу договоров то в поиске вы получите инфу про первые несколько десятком договоров без возможности распечать и т.д. (т.е. те же самые отчеты)

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

PS
Вернемся, к тому, как точно определить активность клиента, вопрос, который задал резкому and-у, когда он последний раз потреблял услуги, в каком месяце? Определить как последнюю запись в таблице contract_account не учитывая услуги модуля абонплат(по известной причине)? Или как? пока что примерно так определяю активность. Не красиво так и возможно не всегда точно)

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

У нас этих просьб куча, и каждый смотрит со своей колокольни, считая что это обязательно нужно и удобно .Если мы будем реализовывать все, вы сами же не сможете с этим биллингом работать ..Будите удивлятся каждый раз нажимая на кнопку и получая своебразный результат , который до вас кто-то посчитал логичным(причем он даже может быть описан в документации , но кроме автора никому не будет понятен и нужен, да и тот забудет про него ) .. потом через несколько версий будут вопросы - а что это за столбец, а почему он так именно работает а не иначе .. Во-первых добавлять дополнительный столбец - это действительно бред с чисто технической точки зрения и точки зрения БД(лучше не пользоваться биллингом, где такое практикуется) .. нужно тогда добавлять отдельную таблицу id договора - id модуля - дата ..как-то так.. А во-вторых смысла делать это сомнительный функционал не вижу .

Раз уж философствуем:)) то здесь топик для предложений. Аргумент этот принят:).

Как лучше реализовать, Вам виднее, я с технической точки зрения тут бреда не вижу. В чем проблема то, добавить колонку, да хоть 10 колонок, не понятно? Работать всё должно, если принят хороший стиль выполнять SQL запросы в программах, а именно писать конкретные нужные колонки во всех запросах SELECT INSERT UPDATE и т.д. дефалт валуе у остальных рулит.


Да Вы даже и не подумали особо над этим(. Выше приводил аргументы. Основной аргумент(это идеология даже), всё нужное должно быть под рукой, а оперативное, на видном месте.
С уважением.

PS
Помыслил, действительно, lastBill<модуль>_<id> не особо поправляет изза id. Подумаю, может както подругому также просто можно будет реализовать это:) Вас бы убедить как нибудь:)

PPS

Да, согласен, это хорошее решение. Сразу же все решили как это делать, ёлки. Просто то как:)

1) в БД в таблицу добавить столбец - или отдельную таблицу это уже работа и не маленькая так как нужно переделать десяток запросов.
2) возьмем поиск, если там результат выводить в таблицу, то кол-во столбцов нужно знать заранее, так как они прописываются в конфиге, а вы хотите что бы столбцы генерить автоматически в зависимости от подключенных модулей
3) для каждого модуля разработать алгоритм его АКТИВНОСТИ и реализовать его
4) переделать отчеты

И это по вашему МАЛЕНЬКОЕ изменение....

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

1. Клиент: Посмотрите, чёто у меня не работает инет или ещё чего.
Оператор: Имя ваше. Далее поиск, сразу вижу баланс. у вас бабоса нет. до свидания.
2. Выбираю группу, вижу сразу клиентов с балансами, и их активностью. (Отрицательные балансы можно подсветить, например красным, клиенты, которые не активны n месяцев, помечаются серым). Надо обзвонить, каких то клиентов, звоню по списку. и т.д. Никаких отчётов не надо, все сразу есть, "активно"), надо посмотреть дополнительную инфу по договору, кликаю и захожу в сам договор, где уже ВСЯ инфа. И т.д.

Другими словами, наглядность повыше. соответсвенно удобство!


Вам виднее, со своей стороны этапы этой работы вижу так:
1. Добавляем ОДНУ единственную таблицу эту. Обзовём например lastBill. Поля скажем такие:
cid, mid, lastBillDate
Всем Вашим модулям известно её существование.
2. Во всех радиуссерверах, коллекторах, и ещё там где, (где получается в общем), при залогинивании(потреблении), дополнительно добавить одно единственное действие: обновлять(если нет записи, добавлять) соответствующую строчку в этой табличке! ВСЁ, вся организация хранения и содержания этой инфы в БД.
3. Расширенный поиск, этот, если динамически не получается вычислять кол-во столбцов, можно настроить вручную

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

Это, помоему, простое, маленькое изменение.

С уважением.

В догонку:

В расширенный поиск, стоит помимо lastBill-ов, разрешить возможность выводить какие нибудь параметры договора. Это уже супер в квадрате.

Т.е. выглядеть вывод в этом поиске будет например так(в угловых скобках настраиваемые столбцы):


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

Клиент: Какая жалость, а вы бы не могли понизить лимит, я завтра оплачу...
Оператор: пип, пип, пип....
Клиент:



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

Там же постранично всё, уважаемый, а чтоб не устала рука, фильтр рядом:)



Должники ни причём!!! Причем то, чтобы выводить сначала КРАТКУЮ инфу, а если далее потребуется, сам залезешь и вытащишь ПОЛНУЮ инфу. В конце концов, если непонятно всё преимущество(а преимущество этого на лицо, даже на лице), реализовать то это совсем не сложно! За Вас же переживаю, продукт богаче станет!

Разработчикам ДВА за подход к обсуждению предложений! Вы их не обсуждаете, а сводите разговор к тому, чтобы в итоге не реализовать это предложение (Как в страховых компаниях, просят принести кучу документов, для того, чтобы найти основание отказать в выплате по страховке )

Традиционный PS(По откровенничаем при всех:)):
Где Вы придумали инструмент в клиенте биллинга, под названием "групповые операции", на мой взгляд, абсолютно... в высшей степени бесполезная вещь, т.к. она ориентирована на администраторов больше, а администраторы и без Вашей помощи такое легко реализуют(ни разу не использовал его, за всё время работы, бесполезные вещи делать мастера);). По сравнению с этим инструментом, этот "расширенный поиск", просто обязан быть в клиенте, хотя бы потому, что с клиентом больше работают менеджеры, бухи, техподдержка, а не администраторы.

Блин читайте внимательнее!!! Я же сказал выбрали группу договоров (например частники, кабельное телевидение) в итоге получили выборку 10тыс договоров, по 50 записей на страницу итого 200 страниц... и что вы делать с такой массой договоров... цитирую ваши слова "Надо обзвонить, каких то клиентов, звоню по списку. и т.д. Никаких отчётов не надо, все сразу есть, "активно"" БУДЕТЕ ОБЗВАНИВАТЬ? (может вам еще и телефончики сразу выводить и адресочки и вообще все инфу по всем договору, ну и сессии за одно)

Вы по себе не судите обо всех. Понятие АКТИВНОСТИ клиента ОЧЕНЬ субъективно и НИ О ЧЕМ не говорит... баланс тоже... клиент может работать в кредит, баланс у него отрицательный, но он не должник...

Напрмер, у одного из наших клиентов, после поступления звонка, диспечер в ЛЮБОМ случае открывает договор и в CRM фиксирует звонок клиента (так что даже если диспечер на этапе поиска увидит баланс пользователя, ей он ни чего не скажет так у пользователя может быть пониженный лимит и много чего еще).

Привязались вы к этим примерам:)) от фуфла их привёл, и заметьте, они - два РАЗНЫХ примера. И вывод следует сделать такой: таким образом можно получить многофункциональный инструмент, который помогает:

1) (1-й пример), быстро решить вопрос клиента: (по примеру имелось ввиду, что после сообщения ему о причине недоступности сервиса, у клиента нет дополнительных вопросов, в общем случае, если бы мне сказали что у меня инет не работает, потому что денег нет, какие ещё вопросы???) (ЭТО только пример, ошибки баланса обычно понятны большинству пользователей и без оператора, не надо придираться)
2) (2-й пример) То, что этот поиск можно использовать и как систему по работе с должниками, (она не отменяет Вашу стандартную систему по работе с должниками, а дополняет)
3) Позволяет выводить любую быструю ИНФУ, например день рождения клиента. Клиент звонит, оператор сразу видит, что у клиента день рождения, поздравляет. Мелочь, а приятно.
4) Да по мелочи, можно разное придумать, с таким нехитрым инструментом.

ДАЙТЕ людям то, что им может помочь, группируйте информацию. Сначала даем небольшую инфу, со ссылкой, потом уже пользователь сам разберётся, нужна ли ему дополнительная информация по этому поводу!!!
Подход интернета!!! Зашёл на сайт, сбоку банеры, ссылки, "горячие девочки", "доллар сбросил 5 рублей", и т.д. и т.п. Кому надо, тот кликнет и почитает. При этом в биллинге, в нашем случае, СЛУЧАЙНОЙ, не нужной инфы не будет выводиться, а выводится то, что сам посчитаешь нужным выводить!
ДАЙТЕ ВОЗМОЖНОСТЬ БЫСТРО ПОЛУЧАТЬ ИНФУ, КОТОРУЮ ПОЛЬЗОВАТЕЛЬ ХОЧЕТ, ЧТОБЫ ОНА БЫЛА НА ВИДУ СРАЗУ. Ещё раз повторю, некоторым пользователям, для удобства, хочется чтобы какаято инфа отображалась сразу, а не заходить куда то глубоко, и вытаскивать её! ПОЖАЛЕЙТЕ ПОЛЬЗОВАТЕЛЕЙ! ДАЙТЕ УДОБНЫЙ ИНТСТРУМЕНТ.
Возможно он её не ищет специально, но если увидит, то вспомнит, решит внезапно что сделать.

PS

Да, возможность эта полезна, об этом также толкую. Можно и телефончики с адресами выводить, и группу крови если надо! А сессии, это слишком детальная информация, и к группе КРАТКОЙ инфы не относится.

У меня СРМ не используется, она меня не устраивает, изза одной небольшой особенности её. А именно, что ответы к задаче в СРМ не подписанные, не авторские, и любой может перетереть предыдущую инфу. (Этот недостаток перечёркивает ВСЕ достоинства)
Странно почему на эту "мелочь" не обратили внимание!

PS
Сори за офтоп

Конечно, но с такими полями, с большой долей уверенности можно сказать, клиент АКТИВЕН ИЛИ НЕТ!

Касаемо субъективности:
В общем случае, каждый решает сам, что ему нужно, а что ему не нужно, что правильно, что неправильно! Надеюсь по этому поводу у нас с Вами разногласий не возникнет. Поэтому берём за аксиому! Итак аксиома:


Из аксиомы, очевидным образом вытекает следствие:

Сейчас Вы, Ваш именно клиент, (скрипты предобработки, слава богу, дают возможность получать в плане функционала то, что надо) не даёт возможности решить, что я хочу видеть, а что не хочу!

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

Следует гибкость, это уже Ваш подход.

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

Настраиваемые поля в таблице с результатами поиска - вот за это я за. А насчёт активности клиента - я сомневаюсь, что этот функционал действительно оправдает трудозатраты.

МГ/МН операторы могут предоставить... Или из их тарифов при конвертации тарифа в биллинг вытаскивать.

Прочти трудозатраты то? Какие там? одну таблицу добавить, и при авторизации, там запись обновлять? Это ТРУДОЗАТРАТА? Очень просто сделать это, зато информацию эту получить, точно, по имеющейся структуре БД очень сложно(сессии помесячно хранятся, одним запросом не вытащишь), а другими методами вообще сложно ТОЧНО определить когда был клиент активен. Потому привязался к этой активности. Инфа полезная, а получить сейчас проблематично очень.

Трудозатраты на 5 копеек.

Не понятно, о чём речь..

1) Вы же сами сказали что Активность актуально практически только для одного модуля VPN, для остальных сомнительна... т.е. Вы предлагаете внести изменения в ЯДРО завязаное на модуль VPN, что не есть гуд.
2) Во вторых что такое активность, дата последнего логина клиента? Тогда например клиент последний раз залогинился месяц назад и провисел 1 минуту, он Активен? или висит до сих пор, он Активен? Может просто взять таблицу сессий и вывести всех клиентов с активными сессиями или всех у кого были сесси в этом месяце?

VoIP также без проблем! В модуле телефонии можно писать туда дату последнего обработанного звонка этого договора(Вам точки вычисления этой активности лучше видны для телефонии, например так, но эт не совсем оптимально наверно), IPN сложнее, помыслить надо. (Было б у Вас желание, домыслите легко сами:))


Интересно не то, насколько клиент был активен несколько месяцев назад, а то, активен ли он на ТЕКУЩИЙ момент. Таким образом АКТИВНОСТЬ, это признак, потребляет ли договор услуги на данный момент, или нет! У нас например считается, если договор не потреблял услуг 3 месяца, он не активен. И уже с такой информацией, с такими клиентами можно чтото придумать. Мыслить, почему так, а не иначе.



Да, дата последнего логина клиента.
Означает что последний раз клиент потреблял услуги такой то датой. Если сессия(VPN) висит неделями, пёс с ней, такое случается не так уж часто, можно пренебречь(не хотите пренебрегать, можно придумать другой момент в который можно замерить активность). С VoIP и телефонией таких моментов нет. (IPN ещё надо придумать, как определить активность, наверно и не определить так легко момент, в который можно её вычислить)

Если он висел месяц назад 1 минуту всего за месяц(да хоть каждый месяц по одной минуте) , всё равно считаем что активен. Объёмы не рассматриваем.

Хорошо, предположим мы видим например баланс и активность

1) договор 1 баланс отриц. последний логин вчера.
2) договор 2 баланс положительный последний логин 3 месяца назад

И что нам это дает? Какие ОПЕРАТИВНЫЕ выводы мы можем сделать по каждому договору на основе этой информации?

1) У чела деньги вчера кончились. Не надо лезть в договор чтобы это видеть там. Возможно этой инфы мне уже достаточно при работе с данным клиентом.
2) Клиент перестал работать, если знакомый, или важный клиент, можно позвонить, и уточнить в чем причина например.

Заметьте, наглядность какая. Можно сразу и отчётики мутить (не печатные), если надо:) (Для этого сортировка по столбцам должна быть, и подсветка:) )

Встречный вопрос, Вам! Удобна ли такая наглядная информация, и будет ли с такой информацией работа с клиентом ПРОЩЕ, и УДОБНЕЕ, для ПОЛЬЗОВАТЕЛЯ биллинга? Если ему лишних "кликов" не надо делать, чтобы получить какую то популярную инфу договора, как баланс, и т.д.??? Помыслите!

PS
Надеюсь понятно почему привязался к поиску?? Чтобы это было именно в поиске? Отвечу: Поиск, это самый популярный, и жизненно необходимый инструмент, которым ВСЁ РАВНО приходится пользоваться, таким образом упростить работу с биллингом убрав поиск просто НЕЛЬЗЯ. А если пользователь всегда пользуется поиском, да и ещё ему нужна какая то инфа дополнительная, которую он ВСЁ РАВНО будет получать, логично было бы разрешить ему видеть её сразу, по возможности!

Вы как то примитивно и узко мыслите...

вы мне опишите с фига ли вы вообще биллинг открыли и начали искать ИМЕННО этого клиента зачем он вам понадобился?