BiTel

Возможность указания в тарифных планах переменных обязательных либо нет, возможно со значениями по-умолчанию.
При добавлении тарифа требуются либо предлагаются к определению переменные.
Таким образом:
1) возможно без расширения тарифа добавление однотипных тарифов пользователям (различается потолок безлимита, например), или сумма а/платы.
2) возможна более простая выборка этих переменных в отчётах, т.к. они будут храниться в более простом виде.

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

А в чем будет отличие от простого копирования тарифа?
Скопировал - поменял пару значений - сохранил.
Спасибо, пожалуйста, все свободны.

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

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

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Супер.

Нашел тему 5-летней давности про это:
viewtopic.php?f=1&t=3200&
Олсо:
Скидки
viewtopic.php?f=16&t=6122
Скидки
viewtopic.php?p=62052#p62052

Попробую собрать мысли в кучу.
Какие проблемы позволят нам решить шаблоны?
1. Переопределение цены.
Есть стандартный тариф, но конкретному клиенту хотят продать его по другой цене. Сейчас приходится делать персональные. На практике это причина заведения 90% персональных тарифов. Не буду расписывать, почему персональные тарифы - зло.
2. "Возможна более простая выборка этих переменных в отчётах, т.к. они будут храниться в более простом виде."
Т.е. это все бесконечные темы на форуме вида "а каким SQL-запросом нам получить ценник абонплаты для тарифа?" и т.п.
Было бы круто, правда тогда нужно делать значения по-умолчанию в тарифе. Т.е. чтобы хранились где-то дефолтные цены с привязкой к tariff_plan.id, а не только к contract_tariff.id договора.
3. focus подсказал ещё одно интересное применение: у нас клиенты на трафиковых тарифах (с пакетом и без) иногда просят делать уведомления или вообще отключать доступ по достижении определённого объёма трафика. Уведомления тут ни при чём, а отключать можно например так: добавить в тарифе ветку диапазона трафика с объёмом -1 или ещё каким, чтобы по дефолту туда не заходило, а внутри ветки узел "запретить доступ". На конкретном договоре при необходимости уже переопределять этот "критический" объём в узле на нужный.

Больше не могу навскидку придумать применений. Но переопределение цены - очень востребованно.
Мы сейчас у себя реализовали костылями переопределение и скидки, поэтому конкретно нам этот проект не приоритетен. Модуль Voice нужнее. Но в целом интересно.

Ещё есть вопросы по реализации:
- Как будут назначаться на договоре эти переменные? К чему они будут привязываться, к contract.id или contract_tariff.id? Очевидно, правильный вариант - второй.
- Будут ли переменные клиентского тарифа иметь период действия или он будет равен периоду действия тарифа? Т.е. захотел поменять переопределение - меняй тариф. Вроде с периодом полезнее, но нужно тщательно подумать, т.к. могут вылезти проблемы. Нужно смотреть от практического применения этих переменных.
- Как это будет выглядеть в ЛК? И должно ли быть доступно для управления? Нужно думать.

ps. Главное не повторить ошибки с тарифными опциями. Имхо, у тарифных опций были преждевременные роды. Т.е. до конца не продумали и выкатили решение. Переменные и шаблоны частично адресуют проблемы, которые не решили тарифные опции. Нужно избежать подобной ситуации.
Проблемы с тарифными опциями:
- Привязка к договору, а не к тарифу.
- Жесткие условия по режимам активации/деактивации, недостаточная гибкость задания на договоре, хардкодед условия подключения.
- Отсутствие параметров тарифной опции. Т.е. опция модифицирует тариф только в виде "подключено/отлючено". Но это уже by design.

pps. Не нашел своей темы про "параметризированные тарифные опции", похоже удалили.

Странно. Быстрый ответ отключили

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

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Да, да, и еще раз да!

Апну темку.

Я вместе со скидками несколько лет назад таки сделал механизм переопределения цен через кастомные узлы тарифного плана модуля NPay взамен стандартных узлов "Стоимость" :
- Добавлена таблица с переопределёнными ценами по услугам для тарифов договора:
custom_tariff_cost: contract_tariff_id * sid -> value
- В тарифном узле берётся (если задана) цена из этой таблицы. Если нет - стандартная цена.

Основная идея такая.
Остальное - обвязка вокруг:
- Кэширование таблицы переопределения цен с обновлением кэша по событию через ActiveMQ
- Визуальное отображение переопределения:

- Галка "возможно переопределение цены" в тарифном узле, чтобы разделять основную цену, которую нужно переопределять, от добавочных (через тарифные опции, например)
- Веб-сервис для работы с переопределениями цен - используется внешними системами при назначении тарифов (из внешней CRM, например)
- (!) Допил клиентской части: вкладка "Переопределение цен" модуля Npay для редактирования переоопределений вручную на договорах (через тот же веб-сервис):


Всё работает как часы в версии 5.2 уже несколько лет.
Думаю, многим эта доработка будет интересна.
На 6.2 базовую часть перенести будет не сложно, я думаю.
Планирую обновиться до 6.2 в ближайшие месяцы, кстати.

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

Посему у меня предложение к разработчикам: допилите RSCM Calculator, чтобы в тарифный запрос передавались кроме sid и time услуги также tree_id тарифа и cid договора:
[code=java]
tariffRequest.setRequestParam("cid", cid);
tariffRequest.setRequestParam("tree_id",tree.getTree().getTreeId());
[\code]
- нужно добавить 2 строчки. Ну либо переписать калькулятор RSCM на более современный ваш API работы с тарифым деревом, где есть TariffContext и пр. плюшки.

А я взамен выложу своё решение на Wiki

Причём не обязательно делать это в 5.2 - можно в 6.2 или даже в 7.

Что скажете?

А также вопрос к юзерам - кому-то эта фича интересна?

О, Кромешник вернулся!
А в договоре это как указывается?
Фича очень интересна, т.к. у нас практически большая часть юриков идет с персональными тарифами

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Как на скрине - вешается обычный тариф, а к нему в кастомной таблице - цена на услугу (или несколько).

Редактировать руками - через отдельный интерфейс (см пост).


Я немношк.

Почему этого не сделать было на вкладке модуля npay в договоре. Там же логичнее ? Зачем на общей вкладке выбирать договор ? Возможно я не вижу каких-то нюансов.
Может быть нам лучше это сделать на вкладке внутри договора и причем в ядре, чтобы работало сразу для всех опций? Т.е выбираем тарифные планы и там будет справа вкладка переопределения цен.

Обновление для 5.2 выкладывается, для 7.0 будет чуть позже. Ждем решения на wiki

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


Спасибо!
Постараюсь до конца недели сделать. На выходных мб.

Кстати, ещё просьба: добавьте поддержку тарифного узла "Обработчик" в тарифные XML всех модулей, а не только в Inet.
Хотя бы в последних версиях.
А то приходится переопределять npay.xml, phone.xml и т.д.

Блин, в следующие выхи - точно напишу доку!

Пока нормальные люди едят шашлыки, я выложил таки решение для переопределения цен на договоре:

http://wiki.bitel.ru/index.php/%D0%9F%D ... 0%BE%D0%B2

В калькулятор на 5.2 добавили, спасибо.
Но у нас не работает hotcalc теперь, т.к. там тоже тарифный запрос делается. А также в hard.tariff.check (хоть мы им и не пользуемся).
Добавите туда тоже?

Мы сделали сейчас персональные цены для услуг RSCM но наткнулись на hotcalc - выдаёт ошибку при добавлении услуги на договор.

зы. Кто-нибудь читал статью вообще? Можно ожидать чего-то подобного в стандартном BG?

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Добавим. За статью спасибо, просмотрел бегло, до реализации пока руки не дошли.

Up

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Кстати, с повышением НДС придумал новую фичу: карта цен абонплат (прайс).
Чтобы было понятнее - похоже на карту цен в телефонии, т.е. в тарифном узле по sid услуги будет браться цена из таблички, а не из дерева.
Решит 2 проблемы:
- Можно будет наконец через SQL получать цену услуги по тарифу из таблички в отчётах (!)
- Проще будет массово обновлять цены на всех тарифах с даты, без необходимости вручную редактировать все деревья тарифов

Пока вижу такую реализацию:
- табличка "тариф*услуга*период -> цена": tree_id, sid, date1, date2, cost
- в стандартных узлах костов если на узле стоит галка "взять цену из прайса", то ищем цену в этой табличке

Т.о. старая логика дерева не отменяется. Просто в дереве будут узлы, берущие "стандартную" цену, но можно добавить узлы в зависимости от условий, заменяющие её или добавляющие стоимость (через тарифные опции и т.п. условия).

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

Сделали фичу с заданием цены тарифа через таблицу - работает.
Теперь сижу завожу новые цены в таблице:



- тут с 1 января будет 406р (из таблицы)

UP.
Stark, как я уже предлагал в телеге, могу в ХД с платной доработкой обратиться, если это ускорит дело

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Пример переопределения цены стандартного тарифа на уровне лицевого счёта в Netcracker BSS.

это к чему?

К тому, что в других биллингах такое предусмотрено.

что предусмотрено? переопределение цены, так это и у нас есть через персональные тарифы...