BiTel

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

Тем временем структура БД в таблицах тарифов и абонплат имеет возможность привязывать тариф и абонплаты к разным сущностям (или наоборот). Отсюда рационализаторское предложение - сделать аналогичные связки тариф<->сущность, абон.плата<->сущность для всех модулей, только не как в модуле Phone (неудобно), а наоборот, более универсально, при добавлении/редактировании тарифа (или абон.платы) выбирается модуль и сущность, к которой привязывается этот тариф, ну и соответственно при тарификации просматривать тарифы либо которые не привязаны ни к одной сущности, либо привязаны именно к этой сущности, для которой проводится тарификация.

Таким образом в один договор могут добавляться несколько одинаковых услуг с разными тарифами (всё в одном месте). В ЛК пользователь видит тарифы и видит к какой сущности они привязаны и меняет нужный при необходимости и возможности.

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

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

Замечания, предложения ? Может уже в 6.1 такое ввести ?

идея хорошая, но вот это не хило усложнит/поломает текущую схему для тех кто выставляет тарифы, ну и возможно(в зависимости от реализации) запутает....нада подумать...

_________________

Код:

  Клиент: вер. 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 - тоже далеко не супер - абонки и тарифы "спрятаны" в поинте. Интересно, как на этот счёт будет в модуле Voice - он должен перенять всё лучшее, избавиться от недостатков и нарастить достоинств. Самое время подумать над этой темой.

Насчёт пакета услуг - это да, действительно хорошая идея. Давайте тему в ТОПе держать.



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

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

В таком варианте можно продолжить - в contract_account добавить поле packet (по умолчанию 0-дефолтный) и разбиваем наработку услуг по пакетам - позволит выводить в bill расшифровку, детализированную по пакетам (аля позиции суб.договоров). Это решит еще такой момент (была тема про это) - сейчас если добавить 2 абон.платы в договор (одну с 1го числа, вторую с 15го) с ценой 400, то в расшифровке расширенный экстрактор разобьёт это на 2 строчки по 300р, хотя по хорошему должны быть строчки 400 и 200р соответственно. А так добавляем в договор 2 пакета с одним общим тарифом без привязок и попакетное начисление наработки даст правильную расшифровку.

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

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

Опять же повторюсь, что в Phone оно (разные тарифы для поинтов, тут он, конечно, выделился) есть, но сделано также костыльно и непрозрачно. Как на этот счёт будут обстоять дела в Voice? Может уже разработчики подключатся и у нас пойдёт более конструктивный разговор. Ведь тема то все-таки достаточно актуальна для многих. И раз в Voice нужно будет аналогично (не-не, только не точности) Phone вводить разные тарифы для разных поинтов, то имеет смысл это сразу сделать глобально для всех модулей, примерно описанным выше образом, не нарушая сложившуюся систему тарификации.

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

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

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

+1

неужели идея не стоит внимания ?

Пора апнуть!