BiTel

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

Например, абонентская плата (она же предоплаченные услуги) $200, предоплаченный трафик по цене $1 за мегабайт, трафик сверх лимита $2 за мегабайт, телефония предоплаченная $3 за минуту, телефония сверх лимита $4 за минуту.

Можно реализовать такую схему? Доработка или можно нарисовать свой "тарифный узел" в динамическом коде?

Есть еще осложнение, желательно реализовать "сдвинутый" относительно начала месяца период для описанного выше тарифного узла. Например, с 9го числа месяца.
Тут как я понимаю можно выкрутится разными услугами, для услуг INET через тариф, для периода времени 1-8 число каждого месяца одна услуга, а с 9 по конец месяца другая. Получится тоже самое сделать для услуг телефонии и абонентскую плату выставлять 9го числа?
Этот сдвиг для группы договоров одинаковый, он не зависит от активации договора. Сейчас, кроме нормальных договоров, считающихся по границе месяца, есть две группы договоров со "сдвигом".

И еще момент, источник данных будет самописный, данные надо выгребать через REST/SOAP API с удаленной системы и "засовывать" в биллинг. Вероятнее всего будем полученные данные через REST/SOAP превращать в радиус аккаунтинг, так что при необходимости можно добавить дополнительные атрибуты для облегчения реализации выше означенных задач.

договора кредитовые и дебетовые?

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

такой тариф может работать только в реалтайме, но как его реализовать у нас не знаю

просто если пытаться рассчитывать периодически, то будут проблемы
например клиент за день скачал 200 Мб и проговорил 50 минут
запускаем перерасчет... возникает вопрос сколько мегабайт вошли в абонплаты и сколько минут...

так есть же уже доводящие абонплаты ru.bitel.bgbilling.modules.inet.npay.InetModuleAccount и bitel.billing.server.npay.bean.Phone(Voip)ModuleAccount, в данном случае нужна лишь сумма и возможность использовать такой же механизм для определения цены, или нет?
в моем случае данные идут "в один поток", т.е. можно гарантировать что не будет телефония и ПД обсчитываться параллельно

еще есть идея подумать что будет с абонентской платой и как ее изменить (чтобы в результате получить аналогичную наработку по договору) если задавать тарифы для ПД и телефонии без скидки, возможно можно ее как то заменить отрицательной "компенсацией" (это опять же доводящая абонплата, отрицательная, и доводить она должна сумму InetModuleAccount и VoipModuleAccount), правда возникнут вопросы с тем как эту кашу потом отображать в ЛК и как формировать позиции для счетов и фактур

про "один поток" не понятно...
т.е. на каждом договоре в течение учетного периода будет только одна услуга реально потребляться (инет или телефония)

Нет. Источник данных и для ПД и для телефонии по сути CDR. Я это к тому что можно подпихивать данные биллингу так что по одному договору тарификатор не столкнется с одновременным обсчетом и ПД и телефонии. В этом случае ведь не должно быть проблем про которые вы говорили выше: "просто если пытаться рассчитывать периодически, то будут проблемы" ?

Или вы про ручной переобсчет? С ним да, похоже нерешаемая проблема.

Появилась еще одна мысль. Так как тарифицируемые данные имеют вид CDR, то можно ПД тарифицировать тем же модулем VoiceIP/Phone, при этом развести ПД и телефонию по разным услугам. В этом случае вопросы меняются:
1) цена меняется при превышении некоторой наработки, такого узла тарификации сейчас нет, да?
2) если я для ПД сделаю услугу модуля VoIP с единицей измерения "байты", все сломается?

1) в CDR трафик и минуты будут округлены до целых ?
2) как будет выглядеть трафик в CDR (временная метка => кол-во или период => кол-во)?

Данные получаются с оборудования с помощью SOAP, что будет в CDR зависит от нас. Время будет в секундах, данные в байтах, наверное. Вообще мысли были превращать эти данные не в cdr, а в радиус аккаунтинг стоп реквесты.
В детализации событий (звонков) будет (в смысле есть, в SOAP ответе) время начала, время окончания, объем (long), единица измерения (строка), тип звонка (примерно 2 десятка разных типов, те мое описание в виде ПД и телефонии это несколько упрощенно, типов "звонков" много, но все они сводятся либо к данным байтах, либо к телефонии в секундах, либо к штукам), ну еще куча ID для идентификации абонента и звонка. Да, если это был телефонный звонок, то в данных так же будет направление звока и номер вызываемого/вызывающего, а если если этот звонок был типа DATA, то будет IP нашего абонента, для информации, так как адреса динамически раздаются.

я не понимаю как делить 200$ между услугами
например у нас уже потрачено 198$, далее приходит информация о звонке продолжительностью 10 мин и радиус пакет с 10Мб трафика
как считать стоимость этого звонка и трафика? можно формулу?

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

информация о звонке приходит в конце звонка
информация о трафике приходит тоже в конце периода

например имеем на время 12:00:00 баланс 198$
в 12:07:00 приходит инфа о звонке длительностью 10 минут (т.е. он начался в 11:57:00)
а в 12:03:00 приходит инфа о 10Мб трафика (т.е. этот например трафик за последние 5 минут с 11:58:00)

и как считать, о трафике мы узнаем раньше, но скачен он был позже....

Ну вышестоящий оператор почти наверняка вначале посчитает 10 мегабайт трафика, так как этот "звонок" будет в CDR раньше чем "звонок длительностью 10 минут". Грубо говоря есть CDR, его надо обработать, и думать о том что следом мы можем получить CDR звонка который начался раньше чем имеющийся не совсем правильно, так как ждать этого потенциального супердлинного звонка мы сколько будем (а вдруг он длительностью в несколько дней-недель-месяцев будет)?
Хотя такие моменты, как правило, уже зависят от программиста который писал алгоритм тарификации.

P.S. так а можно звонки побайтно тарифицировать в модуле VoiceIP или нет?

1) вы же не озвучили с какой частотой вам будут сливать информацию о трафике (раз в минуту или раз в час) от этого ситуация будут совершенно разная
2) звонки побайтно????

1) это просто CDR, просто он получается SOAP запросами, а раз это CDR то нет разницы звонок это или порция данных или SMS
2) ага, цена звонка за байт, на самом деле для VoIP звонков кол-во принятых/отправленных байт приходит в стандартных радиус атрибутах, тогда как продолжительность звонка в VSA

Я там вчера вечером написал про то что лучше всего эта логика услуг вписывается в классическую телефонию. Оператор услуг рассматривает все свои услуги как звонки: отправлена SMS - это звонок типа SMS направление OUT, была передача данных - это звонок (как он бьет это на сессии не известно, для меня это просто строчка в CDR). Есть и другие услуги, например, короткие бинарные сообщения, они тарифицируются тоже по объему, по сути это SMS только бинарные.

Тема изначально была навеяна тупиковой ситуацией с тарифными планами, которые озвучены в первом сообщении, но сейчас я все больше склоняюсь что все обсуждаемые тут услуги надо тарифицировать как звонки и отсюда и возникли уже другие вопросы
а) можно ли будет учитывать единицу измерений заданную для услуги модуля VoIP/Phone при расчете стоимости - если услуга задана как байты, то и цена может быть "за байт" и в GUI будут байты/килобайты/мегабайты, а не минуты/часы/сутки?
б) если все услуги укладываются в логику одного модуля, то тогда можно будет сделать тарифный узел для VoIP/Phone сходный с узлом bitel.billing.server.npay.bean.Phone(Voip)ModuleAccount, никаких логических противоречий не возникает?

1) про CDR понятно, не понятно как ее интерпретировать
когда речь идет про звонок там есть время начала и конца звонка
с трафиком не понятно, т.е. считать, что трафик потреблен одномоментно в указанное в CDR время?

можно и как звонки, только будет путаница в интерфейсе, отчетах и ЛК

1) Да, одномоментно. Тот же netflow так и считается, по времени его сброса. Flow агрегируется на маршрутизаторе и как правило "active timeout" установлен от 5 минут, в противном случае объем, требуемый для его хранения, будет расти линейно. А интервал radius alive реквестов минимум может быть установлен в 60 секунд, обычно устанавливается 5-10 минут.
Что касается нескольких одновременных событий, то такая ситуация и сейчас есть. Это могут быть два звонка которые начались и завершились в одно и то же время по одному и тому же договору, но имеющие разную цену. Эта ситуация чем то отличается кроме условностей что называть звонком, а что передачей данных?

2) Вот я на счет путаницы и спросил, по идее путаницы можно избежать если при отображении следить за единицами измерений услуг. Тут еще вопрос в том что последний раз я видел модули Phone/Voip на версии 4.6, а теперь уже ждем Voice, о котором пока еще ничего не известно

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

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

P.S. Тариф может зависеть не только от объема, а еще и от времени (периоды), и на границах периодов получится та же самая дилемма: пришел flow или радиус аккаунтинг с трафиком за 10 минут, и какую часть трафика и по какой цене считать? Неточный расчет получается. При этом зависимость цены от наработки даст даже меньшую погрешность, если делить объем события, так как при зависимости цены от времени (для случая трафика) вообще непредсказуемо какая часть трафика в какую сторону от граничного времени легла.