BiTel

Тема постоянно всплывает, решил создать отдельный топик.

Вкратце:

(с) http://forum.bgbilling.ru/viewtopic.php?p=48848#p48848

Примеры того, что я понимаю под "мета-услугой" ("группой услуг", ваш вариант названия):
- Интернет
- VPN
- Телефония (либо 2 "мета-услуги": "Телефония местная", "Телефония МГМН")
- E-mail
- Хостинг

"Мета-услуга" включает в себя:
- набор сущностей разных модулей. Например, "Интернет": сервисы INET, абонплаты за инет, за локальный трафик и т.п.
- свой статус
- (?) свой баланс
- Свои тарифные планы

Где это проявляется в биллинге:
1. Статус модулей.
По сути, это статус нашей "мета-услуги", но перенесённый на уровень модуля. Это неправильно, т.к., например, модуль IPN может содержать в себе диапазоны для интернета и диапазоны для впн, а закроется всё.
Для разных модулей при этом логика закрытия/открытия разная (для разработчиков: helpdesk#4209)
2. 2 тарифных плана для одного модуля на 1 договоре.
Актуально для dialup, (частично) inet. Если в рамках одного модуля у нас реализуется 2 услуги: интернет, впн в Inet, то на одном договоре нужно 2 разных тарифных плана, но в случае с Inet есть общая услуга "Время", которая будет тарифицироваться по первому попавшемуся, а в dialup вообще все услуги так тарифицируются.
3. Счета. В счёте на позиции субдоговоров сгруппированы. Т.е. имеется двухуровневая структура "договор-субдоговор", а мы хотим "Клиент - Точка подключения - Услуга".
4. Агенсткая схема телефонии - яркий пример "мета-услуги" с собственным тарифом и балансом. Сейчас это сделано только для одного модуля и выглядит довольно костыльно, т.к. нельзя использовать агентскую схему на субдоговоре.
5. Тарифы для пойнтов phone. Каждому пойнту можно назначить свой тариф. Но это работает только в phone, не наглядно, ломает привычную логику. Тыц
...

Ссылки:
http://forum.bgbilling.ru/viewtopic.php?p=48848#p48848
http://forum.bgbilling.ru/viewtopic.php?p=56432#p56432
http://forum.bgbilling.ru/viewtopic.php?p=58272#p58272
http://forum.bgbilling.ru/viewtopic.php?p=18564#p18564
http://forum.bgbilling.ru/viewtopic.php?f=10&t=2951&
http://forum.bgbilling.ru/viewtopic.php?f=16&t=7609&
viewtopic.php?f=1&t=8734
viewtopic.php?f=22&t=8902

дадада, поддерживаю!!!

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Обдумываю переход на Inet, опять всплыла эта тема.

Вижу такие костыльные варианты сейчас:
1.
Договор -> Точка
Субдоговор -> Услуга

Т.е. разные услуги разносить по разным субдоговорам

Проблемы:
- как объединять точки одного клиента и выставлять по ним общий счёт?
- клиенту придётся заходить в web на каждую точку отдельно
- бардак при учёте точек клиента

2.
Договор -> Клиент
Субдоговор -> Точка + Услуга

Т.е. названия субдоговоров будут иметь вид "Клиент1 - точка1 - Интернет"

Проблемы:
- нет общего баланса по точке
- все субдоговоры в одной куче (клиент BG, web)

3.
Договор -> Клиент
Субдоговор -> Точка
Модуль -> Услуга

Проблемы:
- нужно плодить экземпляры одних и тех же модулей
- всё ещё нет баланса по услугам
- "услуга" как правило содержит в себе сущности разных модулей. Обычно это модуль трафика/телефонии/etc + абонплаты
- не всегда возможно разделить логику устройств на разные модули. Например, логины pppoe могут представлять разные услуги (интернет или VPN), но авторизоваться на одном радиусе.

Картинка для привлечения внимания:

Вопрос к форумчанам: кто как организует субдоговоры/услуги?

так же делаю.


а для привлечения внимания нада титьки, они всем нравятся

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Это как?


Но-но, нас могут читать дети!

ну что для разных услуг разные субдоговора

у них гугла нет? ))))

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

ага, и тоже суб договора и персональные тп

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

А зачем персональные ТП?
И что в них персональное?

внизу чья из вас лысина?

_________________
I'm clever. I've got a computer.

иногда на каждую точку свой тп, чтоб не плодить в глобальных

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

А мы вот суб договора юзаем когда нужно сделать две одинаковые услуги но с разной ценой.

_________________
Интернет и телефония оптом со склада, или в розницу

Получается, персональная в нём только абонплата?
Это ещё одна популярная проблема: нужен встроенный механизм скидок.


Звучит странно, можно пример?

Вспомнил ещё один пример, когда отсутствие третьей сущности в цепочке порождает костыли от разработчиков: привязка сущности договора к тарифу в модуле phone.
Т.е. каждому пойнту можно назначить тариф напрямую, в обход стандартной логики "пойнт -> договор -> тариф".
Минусы:
- доступно только в одном модуле
- не наглядно (тарифы пойнта видны только если в него зайти, внешне непонятно, что каким обсчитывается, какие пойнты имеют собственные тарифы, а какие обсчитываются глобальным)

viewtopic.php?f=10&t=2951&

Первый пришедший в голову вариант решения - сделать из объектов договора эту сущность "услуга".
- [+] сущности модулей
- [*] тарифные планы
- [-] статус
- [-] баланс
Сущности модуля к объектам и так уже привязываются.
Тарифные планы можно реализовать:
1. Заводим привязку тарифов договора к объектам
2. При поиске тарифов для тарификации сущности модуля проверяем не только напрямую по contract_tariff.emid и contract_tariff.eid, но и опосредованно - через привязку тарифов к объектам и объектов к сущностям
3. Со статусом сложнее, но тоже можно реализовать (надо ли?). Тут куча проблем, например: как приостанавливать отдельные сущности модулей, а не модуль целиком; какие статусы могут быть; как это будет работать со статусом договора и модулей.
4. Баланс нормально сделать не получится. А без баланса статусы не так актуальны. Разве что только делать жесткое приостановление.
5. Нужно отображать в договоре такие объекты более наглядно - в левом столбце, так же как и модули. Также сделать наглядное отображение тарифов, которые им соответствуют, и тарифов договора.

Тут выгода будет только в возможности заведения разных тарифов для разных услуг одного модуля для любого модуля.

...но у меня появилась идея получше

Другой вариант - надстроить логическую иерархию договоров клиента поверх текущей схемы.
Скажем, создать отдельную сущность "категория договора", которые для каждого клиента строятся в виде дерева, к некоторым узлам которого привязаны (суб)договоры:


Для каждого клиента структура может быть своя.

В списке субдоговоров договора выдавать не плоский список, а вот такое дерево.
В WEB-статистике - аналогично. Причём для группы "филиалы" можно посмотреть суммарный детальный баланс по ветке.
Аналогично структурировать XML в счетах.

Если подумать ещё, то можно такое дерево натягивать на несколько супердоговоров, объединённых одним клиентом.
Например, у банка 2 договоры на города А и Б, но организация одна. В личном кабинете клиент авторизуется не на уровне договора, а на уровне клиента (customer).

Также в узлах "категория договора" можно хранить разную информацию: устройство, порт и т.п. в листях дерева; адрес по КЛАДР в узлах - точках подключения ("<адрес1>").

Можно сделать в виде плагина например

Представьте, что у вашего клиента есть две точки, и в этих точках он берёт разное кол-во мегабит за разные деньги.
Вот и получается услуга одна: доступ в интернет, а стоимость разная.

_________________
Интернет и телефония оптом со склада, или в розницу

Ну т.е. это две точки, а не 2 услуги в одной точке. Ок.

В каждой организации свое представление о сервисе, заказах и точках подключения.
У нас подключение по адресу - точка подключение клиента.
В одной точке клиент может потреблять 1 и более сервисов:
- интернет,
- телефония,
- впн,
- другие услуги.

В итоге, как я понял, предложение Cromeshnic в следующем:
СУБ = АДРЕС (точка подключение) - Сервис
Например: СУБ = Маяковского, 1/б - Интернет.
СУБ = Маяковского, 1/б - Телефония.
СУБ = Маяковского, 1/б - VPN.

Ещё вижу + в такой схеме - отдельное управление доступом к услугам. т.е статусом суба рулим доступом к сервисам.

Ну да, это вариант 2:

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

_________________
Интернет и телефония оптом со склада, или в розницу

Да. И наши клиенты так иногда делают.

ещё:
viewtopic.php?f=16&t=7609&

Предлагаю продолжить в этой теме http://forum.bitel.ru/viewtopic.php?f=1&t=8734
Разработчики есть что ответить?

апну

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений