Я тоже поною, раз никто не возражает.
<нытье>
Для начала несколько общеизвестных фактов, что бы придать тоскливым завываниям некоторую стройность:
По требованию государства отношения между Оператором и Абонентом регулируются Договором.
Договор состоит из юридически значимых идентификаторов сторон, текста различных пугалок и страшилок (обычно предвзято выборочно перепечатанных из "закона о связи" и "правил оказания услуг связи") и описания того, ради чего все затевается - Предмета договора.
Предмет договора содержит перечень чего-то, что Оператор обязуется выполнять и список того, что должен ему за это Абонент.
В вакуумно-сферической информационной системе Договор распределяется следующим образом:
Все сотрясание воздуха находится в CRM;
Предмет договора транслируется:
"Аппаратные" обязательства Оператора - в OSS;
Потребление ресурсов - в правила системы учета ресурсов;
Что должен Абонент - в правила системы, конвертирующей что угодно в деньги, то есть в АСР (биллинговую систему);
Правила соблюдения баланса "обязан-должен" - в систему учета денежных средств.
Перечисленные системы прозрачно взаимодействуют между собой, реализуя BSS.
В текущем БГБиллинге Договор представлен в виде:
Параметров бгбДоговора и бгбОбъектов, имеющих смысл только для Оператора;
Предмета договора, транслированного в условные "подсистемы":
"Аппаратные" обязательства Оператора - в параметры соответствующих модулей (Phone, Inet);
Потребление ресурсов - в параметры соответствующих модулей (Phone, Inet);
Что должен Абонент - в комбинацию бгбТарифов и бгбУслуг т.е правила конвертации чего-то в деньги, реализованные в соответствующих модулях (Phone, Inet, NPay);
Правила соблюдения баланса "обязан-должен" - в бгбБаланс бгбДоговора, режимы кредит/дебет бгбДоговора, временные лимиты.
При этом какая-то часть взаимодействия "подсистем" скрыта внутри определенного модуля, некоторая часть зафиксирована в правилах типа режима кредит/дебет, еще одна часть реализована посредством бгбСтатуса бгбДоговора, другая часть - начислениями.
Связь бгбДоговора, бгбТарифов, бгбБаланса, бгбСтатуса и модулей монолитна. (исключение в связке бгбТариф-бгбДоговор - Phone, но это из разряда "а налево живой человек стоит, а чем живет и как туда попал - тоже неизвестно", поэтому игнорируем).
Пока Предмет договора транслируется "один в один" в фиксированную связь бгбДоговора, бгбТарифов, бгбБаланса, бгбСтатуса и модулей - этот монолит незаметен и воспринимается как естественный и удобный: есть Договор, есть его операционализированная копия - бгбДоговор.
Как только Предмет договора требует некоторой, порой незаметной для простых смертных, гибкости, например, Абонент возжелал по одному Договору получать доступ к сети Интернет в 15 географически распределенных точках с индивидуальными абонентскими платами и возможностью независимой приостановки оказания услуг в любой из точек, то начинаются самодеятельные маневры по обходу, подкопу и другому надковыриванию глыбы бгбДоговора. Один городит субдоговора, получая неуправляемую избыточность, другой противоестественно мучает персональный тариф, третий пробивает и оплачивает безсистемную доработку (наверное так и появилась возможность назначать тариф на поинт
). В результате, либо разрушается связь Договор - бгбДоговор, либо Предмет договора реализуется сущностями БГБиллинга настолько неочевидно, что оказывается закопан так же как орех белкой - найти без собаки-ищейки невозможно, попытка выкопать приводит к глобальной катастрофе.
Исходя из этих общеизвестных фактов
идеальная деглыболизация бгбДоговора ощущается следующим очевидным образом:
1. бгбДоговор состоит из набора параметров, одного или более бгбЭлемент_Предмета_Договора, для краткости - бгбЮнит, одного или более бгбБаланса, одного или более бгбСтатус и назначений "общедоговорных", "некалькуляционных" модулей, например Bill;
2. бгбЮнит состоит из набора параметров, бгбТарифов, назначений "юнитовых" или "калькуляционных" модулей (NPay, Inet, Phone) (и бгбУслуг соответственно) и привязан к определенному бгбБалансу;
3. бгбБаланс имеет приоритет, определяющий его очередность при распределении прихода, режим дебет/кредит, лимиты. К одному бгбБалансу могут быть привязаны несколько бгбЮнит;
4. Связь бгбСтатус - бгбБаланс: "многие ко многим".
В вырожденном случае полностью повторяются существующие отношения бгбДоговора, бгбТарифов, бгбБаланса, бгбСтатуса и модулей.
Более реальные варианты:
а) бгбСтатус один на бгбДоговор, режим дебет/кредит, лимиты - на бгбДоговор;
б) бгбСтатус - свойство бгбБаланса, режим дебет/кредит, лимиты - на бгбДоговор.
в) бгбБаланс один на бгбДоговор.
В вырожденном случае система может даже не показывать существование бгбЮнита, тем самым обеспечивая полную совместимость.
</нытье>
Дополнение:
для реализации агентских схем в пределах одного бгбДоговора необходима и достаточна возможность "наследования" или "построения иерархии" юнитов.
Процедура "наследования" предполагает выставление "птичек" - что доступно "наследнику", что "наследник" может заменить.
Вход
Регистрация
FAQ
Поиск
)
