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

Детализированный отчет может генерироваться как по платежным документам (картам), так и по лицевым счетам.

Отчет по платежным документам предусматривает следующую детализацию:

–дату активации платежного документа (или дата выдачи предыдущего отчета);

–сумму на счете на дату активации (или на дату выдачи предыдущего отчета);

–суммы пополнения счета и дата их пополнения за указанный период;

–суммы перевода средств на другие счета и их даты;

–сумму оказания услуг за отчетный период.

Детализированный отчет по лицевым счетам обычно содержит:

–дату расчетного периода;

–расшифровку наименования предоставленной услуги;

–время оказания услуги;

–трафик (длительности оказания услуги);

–объем переданной (принятой) информации;

–стоимость тарификационной единицы в соответствии с индивидуальным та-

рифным планом.

Отчет также может содержать суммарные показатели трафика и/или стоимости за расчетный период.

Результаты отчета являются основанием для выставления пользователю счета на оплату.

5.3. Логика услуг

Создание логики услуг определяется функцией среды создания услуг (SCEF) на ос- нове функции управления событиями (ECF) и с использованием функции поддерж- ки данных услуг (SDF). Таким образом, созданная в SMP и информационно поддер- живаемая SDP логика услуг реализуется в пункте управления услугами SCP.

Говоря о создании логики услуг как об основе концептуальной модели, необ- ходимо подчеркнуть, что имеются два подхода к ее созданию. Первый заключает- ся в разработке индивидуальной логики каждой услуги и доработке ее при необ- ходимости создания новой услуги (так называемый подход «снизу вверх»). Вто- рой подход заключается в построении такой логики услуги, который позволяет, создав некоторую универсальную логику, путем исключения из нее отдельных компонент получать требуемый спектр услуг (такой подход часто называют «сверху вниз»). Выбор того или иного подхода для создания логики услуги одно- значно влечет за собой и аналогичный выбор для создания архитектуры УБС. Яв- ляясь сторонником второго подхода, автор придерживается пути создания необ- ходимого и достаточного перечня компонент услуги как основы для создания универсальной логики услуги.

Важным аспектом при создании логики услуги является достаточность совокуп- ности средств реализации. Так, если предоставление услуги некоторым телекомму- никационным оборудованием не предусматривает обмен данными с УБС в реальном времени, то не приходится говорить о расчетах pre-paid. Также не может быть реали- зован расчет pre-paid в случае, если информация о параметрах услуги поступает в УБС после ее оказания, даже если используется hot-line биллинг. Примером первого утверждения может служить of-line биллинг, а второго — передача заранее неизвест- ных объемов информации, которые нельзя оценить в процессе их передачи.

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

Говоря о реализации логики услуг биллинга, надо иметь в виду, что отдельные функциональные компоненты могут быть подготовительными, т.е. заранее подго- тавливающие информацию и ее структуру для реализации логики услуги, а также компонентами реального времени, т.е. выполняемые в процессе реализации услуги. Если обратится к реализации логики услуг hot-line биллинга, то в качестве подгото- вительной функциональной компоненты (FF) используется функция генерации сче- тов платежных документов, неперсонифицированных лицевых счетов и индивиду- альных тарифных планов. Для логики услуг on-line и off-line биллинга характерно использование в качестве предварительной функциональной компоненты функции генерации персонифицированных лицевых счетов, текущих счетов, а также тариф- ных планов.

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

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

–направление связи выбирается после анализа совокупности запросов от одной FF к другой и должно соответствовать направлению запроса или направлению передачи информации;

–если в запросах существуют оба направления, то производится двойная ори- ентация связей с присвоением соответствующего номера;

–для не ориентированных связей типа «родство» или «ассоциация» произво- дится ориентация связей от каждой FF к каждой.

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

систему отношений, которая включала бы в себя все отношения, декларируе- мые FF.

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

ориентированная дуга в fk типе отношений, соединяющая i-ю вершину с j-й, и равно 0 в противном случае.

Пару типов отношений будем считать эквивалентными, если rmnfk ≡ rmnsp для всех m и n M(x), где M(x) = (X fk X sp ) (X sp X fk ).

Пару типов отношений будем считать независимыми, если rijfk ≠ rijsp для всех i и j.

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

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

Первый пример описывает логику услуги, состоящую из компоненты hot-line pre-paid с авторизацией как по паролю доступа, так и по номеру терминала, с дополнительной компонентой услуги в виде пополнения персонифицированных лицевых счетов со счета платежного документа (рис. 5.7). Такая услуга биллин- га может быть использована, например, оператором сотовой связи, который пре- доставляет услуги радиотелефонной связи по договорам с абонентами на усло- вии предоплаты, а также таксофонной радиотелефонной связи по дебетовым скретч-картам с одновременной возможностью пополнения лицевых счетов с такой же карты.

Второй пример описывает логику услуги, состоящую из компонент услуги online post-paid, с авторизацией по паролю доступа и дополнительной компонентой услуги в виде пополнения персонифицированных счетов со счета платежного инст- румента (рис. 5.8). Такая услуга биллинга может быть использована, например, провайдером услуг Интернета, который предоставляет услуги коммутируемого дос- тупа в кредит, но с условием погашения этого кредита путем авансового платежа со счетов дебетовой карты.

Рис. 5.8. Логика услуги on-line post-paid

Обратимся к первому примеру (см. рис. 5.7). Предварительными функциональ- ными компонентами в этом случае будут являться функции генерации индивиду- альных тарифных планов (FF6), счетов платежных инструментов (FF1) и персони- фицированных лицевых счетов (FF2) на основе заключенных с абонентами догово- ров. При заключении договора с абонентом, в котором абоненту присваивается но- мер радиотелефона, выбирается индивидуальный тарифный план, а также опреде- ляется перечень предоставляемых ему услуг, что автоматически определяет пере- чень текущих счетов (FF4) по каждому виду услуг. Для абонентов, которые будут пользоваться таксофонной радиотелефонной связью по картам, генерация неперсо- нифицированных лицевых счетов (FF3) производится автоматически при первой ав- торизации карты. Автоматическая генерация текущих счетов (FF5) проводится при первом предоставлении данного вида услуги. Например, текущие счета местной и междугородной связи генерируется при первом предоставлении этих услуг.