Продолжается подписка на наши издания! Вы не забыли подписаться?

АО НТЦ “Модуль”

Система автоматизации операционной деятельности Internet-провайдерской компании

Система, разработанная НТЦ “Модуль”, реализована в СУБД ORACLE и предназначена для внедрения в комплексы управления, учета и администрирования провайдерских фирм сети Internet (не исключены и другие сети, телефонные компании и т.д.).

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

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

Функциональные возможности системы

Определение типов клиентов и списка присущих им атрибутов

Каждый клиент в системе принадлежит к какому-либо из определенных типов. Тип клиента (например “Физические лица”, “Юридические лица”...) характеризуется в первую очередь списком атрибутов, которые должен иметь клиент данного типа. Список возможных атрибутов формируется разработчиком по согласованию с представителями компании. В процессе функционирования системы этот список может дополняться, а его элементы — изменяться или уничтожаться. Оператор системы имеет возможность создавать необходимые типы клиентов и привязывать к ним атрибуты из списка возможных атрибутов.

Заключение и ведение договоров с клиентами

Новый договор заключается или с уже существующим в базе данных клиентом, или создается новый клиент в имеющемся списке типов. В последнем случае для клиента автоматически создаются пустые атрибуты в соответствии с типом. Задачей оператора системы является ввод значений этих атрибутов (Рис. 1).

Рис. 1

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

Для удобства в работе имеется возможность создавать группы клиентов (Рис. 2). Каждый клиент может быть включен одновременно в любое количество групп или ни в одну из них.

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

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

При заключении нового договора в базе данных создается объект “Договор”, связанный с данным объектом “Клиент”. Атрибуты (номер, дата...) заполняются оператором. Для каждого клиента существует как минимум один подчиненный ему объект “Пользователь”. Первый пользователь для данного клиента создается автоматически, остальные — оператором по мере надобности.

Рис. 2

Процесс формирования договора заключается в привязывании к соответствующим пользователям услуг из действующего на данный момент списка услуг, т.е. создание отношений “Договор — Пользователь — Услуга” (Рис. 3). В соответствии с конфигурацией, для некоторых услуг система или создает атрибут данного отношения (например, договорная цена) и предлагает оператору ввести его значение, или предоставляет возможность создать и определить подобные атрибуты или их списки (например, льготы с датами их вступления в силу и прекращения) (Рис. 4). Информация по заключенному договору в дальнейшем может модифицироваться.

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

Рис. 3

Рис. 4

Регистрация пользователей в системе биллинга в соответствии с договором

В соответствии с конфигурацией, для определенных услуг система создает необходимые пустые атрибуты отношения “Договор — Пользователь — Услуга”, значения которых должен ввести оператор (например, начальный и конечный IP-адрес), или предоставляет возможность сформировать список подобных атрибутов (например, список входных имен). Первый элемент списка создается автоматически. Для некоторых атрибутов, опять же в соответствии с конфигурацией, автоматически вызываются процедуры последующей обработки введенных значений (например, процедура перевода IP-адреса в числовой вид и сохранения в другом поле) (Рис. 5).

Оператор обязан ввести идентификатор пользователя для обеспечения ему доступа к информации о своей работе в “клиент-брокер-сервер” и дату подключения услуги.

Если услуга подключена (введена дата подключения), система позволяет ее отключить (ввести дату отключения). Если услуга подключена, но не отключена, система предоставляет возможность формирования для тройки “Договор — Пользователь — Услуга” списков блокировок и отпусков с датами начала и окончания для каждого элемента этих двух списков.

Рис. 5

Автоматизированное выставление счетов клиентам

Разработчиком по согласованию с представителем компании формируются в базе данных об’екты “Статья” (например, “Абонентская плата”, “Подключение”...). Каждая статья соотносится с соответствующим множеством услуг. Наработка клиента по данной статье рассчитывается как сумма наработок всеми его пользователями по всем входящим в эту статью услугам за указанный период по данному договору.

При добавлении оператором нового счета создается его пустой атрибут “Номер счета” и “Дата”. Последнему присваивается значение даты по умолчанию, контролируемой оператором. Для них потом можно ввести нужное значение. Система также автоматически строит в базе данных связи данного счета со всеми статьями, которые содержат хотя бы одну услугу, задействованную в данном договоре хотя бы для одного пользователя. Для каждого отношения “Договор — Счет — Статья” создаются следующие атрибуты:

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

Затем производится полный расчет стоимости по каждой статье с учетом динамики изменения прейскуранта, констант (в том числе ставки НДС) и курса рубля, а также с учетом наличия отпусков, льгот и динамики их изменения. Понятие цены в такой динамической модели в общем случае теряет свой изначальный смысл, поэтому получается ее усредненное значение делением суммы на количество. Аналогично — и со ставкой НДС.

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

Удалить вместе со всей постатейной информацией можно только не оплаченный счет. Выдать на принтер, на экран или в файл можно текст любого счета в любое время (Рис. 6).

Рис. 6

Занесение в базу данных поступивших от клиентов платежей

При занесении в базу данных нового платежа создается объект с атрибутами дата, сумма и сумма НДС, которые должны быть заполнены оператором. Система предоставляет возможность ввода платежей, поступивших или по выставленному счету, или просто по договору. В первом случае создается отношение “Счет — Платеж” (отношение “Договор — Счет” уже существует), во втором — “Договор — Платеж”.

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

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

Автоматизированное формирование счетов-фактуры

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

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

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

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

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

Система позволит оператору занести сформированный счет-фактуру в книгу продаж, если текущий остаток денег является неотрицательным. Система не позволит добавить новый счет-фактуру, пока прежний не занесен в книгу продаж. Удалить вместе со всей постатейной информацией можно только не занесенный в книгу продаж счет-фактуру. Вычеркнуть из книги продаж можно только последний занесенный в нее счет-фактуру при условии, что в этот момент не существует не занесенный туда счет-фактура по данному договору. Выдать на принтер, на экран или в файл можно текст любого счета-фактуры в любое время (Рис. 7).

Рис. 7

Формирование и печать необходимых документов

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

договор между компанией и клиентом (на русском языке);

договор между компанией и клиентом (на русском и английском языках);

прейскурант услуг (на русском языке);

прейскурант услуг (на английском языке);

счет к оплате;

счет-фактура.

Прейскурант услуг формируется при выборе соответствующей опции в системе меню, сопутствующей данному рабочему месту, и введением затем даты, на которую прейскурант является действующим (Рис. 8).

Остальные документы формируются при осуществлении навигации на требуемый объект и нажатии кнопки “Печать” или выборе соответствующей опции в системе меню.

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

Рис. 8

Оперативное получение необходимых справок

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

список клиентов с их атрибутами;

наработка пользователей;

информация по договорам с клиентами;

информация по льготам;

информация по отпускам;

сверка счетов к оплате и платежей по ним;

список статей с соответствующими им услугами.

Справки формируются или для определенного оператором множества отдельных клиентов, или для множества типов клиентов, или для множества групп, или для пересечения множеств типов/групп (Рис. 9). Где это необходимо, требуется задать даты начала и окончания интересующего периода.

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

Рис. 9

Получение пользователем интересующей его информации о своей работе

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

Получение клиентом информации о работе своих пользователей

Любой клиент может получить в “клиент-брокер-сервер” информацию о работе своих пользователей, введя свой идентификатор клиента, выбрав нужный тип справки и задав даты начала и окончания интересующего его периода (Рис. 10). При соответствующей согласованной с клиентом конфигурации договоров клиент имеет возможность вести свой внутренний биллинг.

Рис. 10

Определение и конфигурирование услуг

Услуга, как объект, создается вместе со списком ее атрибутов (цена и пр.) разработчиком системы. Оператор имеет возможность изменить ее название и установить значения атрибутов в функции от времени (Рис. 11). Каждая услуга включается в соответствующий класс услуг и имеет свой тип, определяющий алгоритм расчета ее стоимости.

Рис. 11

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

Каждая услуга имеет алгоритм расчета стоимости, определяемый ее типом. В качестве параметров выступают значения ее собственных атрибутов на каждый момент времени (действующий на этот момент прейскурант), изменяющиеся во времени константы и курс рубля, значения атрибутов отношения “Договор — Пользователь — Услуга”, введенные при заключении договора и регистрации в системе биллинга и др. Появление нового типа услуг означает разработку новых программ расчета их стоимости.

Возможное изменение в процессе эксплуатации системы алгоритма расчета стоимости какой-либо услуги с определенного момента времени означает следующее:

Ведение прейскуранта услуг

Ведение прейскуранта услуг заключается в занесении оператором в базу данных значения сответствующего атрибута услуги и даты, начиная с которой это значение является действующим (Рис. 12).

Рис. 12

Определение и ведение необходимых констант

В системе определен набор динамических констант, необходимых для расчетов;

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

Суммарная продолжительность сеансов пользователя в течении месяца, включаемая в абонентскую плату по сути своей может изменяться только с первого числа месяца, остальные константы — на произвольную дату.

Помимо констант в базе данных хранятся в статическом виде списки IP-адресов сетей, принадлежащих Исполнителю и собственные атрибуты компании (банк, расчетный счет и др.), необходимые для формирования документов.

Занесение в базу данных текущих значений курса рубля

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

Загрузка в базу данных информации по биллингу

На соответствующих серверах размещаются программы формирования управляющих файлов SQL*Loader с информацией о работе dial-up абонентов, IP трафике и нагрузке на каналы пользователей. Эти файлы пересылаются на сервер базы данных ORACLE и загружаются в соответствующие таблицы первичных данных по биллингу. На каждые сутки создаются свои таблицы первичных данных, которые в последующем отправляются в архив в виде экспортных файлов, а затем уничтожаются.

Таблицы первичных данных с информацией о работе dial-up абонентов имеют следующую структуру:

Таблицы первичных данных с информацией об IP трафике имеют следующую структуру:

Таблицы первичных данных с информацией о нагрузке на каналы пользователей имеют следующую структуру:

Обработка загруженных первичных данных по биллингу

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

Постоянная таблица биллинга с информацией о работе dial-up абонентов имеют следующую структуру:

В эту таблицу попадает часть первого сеанса сверх текущей суммарной продолжительности сеансов пользователя в течении месяца, включаемой в абонентскую плату, с учетом возможного наличия части сеанса из прошлого месяца, и все последующие сеансы. Если есть часть сеанса, переходящая в следующий месяц, она отсекается и учитывается при обработке даннных следующего месяца. Расчет производится с учетом динамики изменения прейскуранта и констант “Суммарная продолжительность...”, “Время начала дня” и “Время начала ночи”. Для дневных сеансов в таблицу заносится дневная расценка, для ночных — ночная. Если на сеанс попадает граница дня и ночи, то он разбивается на дневную и ночную части и для каждой берется своя расценка по прейскуранту. По такому принципу могут обрабатываться сеансы любой продолжительности, неоднократно переходящие через границу дня и ночи, и даже продолжительностью свыше одного месяца. Сеанс (часть сеанса), переходящий через границу суток, также разбивается на части.

id отношения “Договор — Пользователь — Услуга” соответствует тому отношению, для которого хотя бы один элемент списка атрибутов “Входные имена пользователя” совпал с полем “Входное имя” таблицы первичных данных. Обработка производится с учетом отпусков, т.е. сеанс, начало которого приходится на период отпуска для данного пользователя, не учитывается.

Не учитываются сеансы, для которых значение поля “Номер телефона” совпадает со значением атрибута “Сотовый телефон “Билайн””.

Постоянная таблица биллинга с информацией об IP трафике имеют следующую структуру:

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

id отношения “Договор — Пользователь — Услуга” соответствует тому отношению, для которого входной IP-адрес или выходной IP-адрес в таблице первичных данных находятся в диапазоне, определяемом значениями его атрибутов “Начальный IP-адрес” и “Конечный IP-адрес”. Обработка производится с учетом отпусков, т.е. записи в таблице первичных данных с датой, приходящейся на период отпуска для данного пользователя, в постоянную таблицу биллинга не попадают.

Расчет производится с учетом динамики изменения прейскуранта.

Постоянная таблица биллинга с информацией о нагрузке на каналы пользователей имеют следующую структуру:

В эту таблицу попадают те записи из таблиц первичных данных, для которых выходная скорость попадает в один из интервалов, определяемых набором атрибутов данной услуги, действующих на данную дату. В качестве цены возвращается значение, соответствующее данному интервалу и действующее на данную дату. Также возвращается значение константы “Частота измерения загрузки канала”, действующее на данную дату.

id отношения “Договор — Пользователь — Услуга” соответствует тому отношению, для которого хотя бы один элемент списка атрибутов “Дескриптор” совпал по LIKE с полем “Дескриптор пользователя” таблицы первичных данных. Обработка производится с учетом отпусков, т.е. записи в таблице первичных данных с датой, приходящейся на период отпуска для данного пользователя, в постоянную таблицу биллинга не попадают.

Уникальный числовой код, генерируемый SQL*Loader для каждой записи при загрузке таблиц первичных данных, переносится и в постоянные таблица биллинга, обеспечивая однозначное соответствие между порождающими записями первых таблиц и порожденными записями вторых. Таким образом обеспечивается возможность производить повторную обработку таблиц первичных данных, предварительно уничтожая все записи в соответствующей постоянной таблице биллинга, код которых находится в интервале между минимальным и максимальным значениями кодов обрабатываемой таблицы первичных данных. Если по какой-либо причине потребуется обработка уже уничтоженной таблицы первичных данных, то она создается заново пустой и в нее импортируются данные из хранящегося в архиве соответствующего файла экспорта. После обработки эта таблица уничтожается.

Используемая в системе сложная двухступенчатая схема работы с данными по биллингу имеет следующие преимущества:

а) Экономится дисковое пространство, так как в постоянные таблицы биллинга попадают не все записи из таблиц первичных данных, а только нужные. Таблицы же первичных данных уничтожаются после их обработки и архивирования файлов экспорта. Кроме того, постоянные таблицы биллинга можно периодически “чистить с хвоста”, имея возможность в любое время снова загрузить в них данные за интересующий период времени.

б) Обеспечивается быстрый доступ к данным по биллингу в процессе оперативной работы, т.к. наличие в таблицах поля, содержащего id отношения “Договор — Пользователь Услуга”, позволяет существенно упростить команды SELECT, применять преимущественно простые соединения таблиц, а следовательно — резко повысить эффективность использования индексов.

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

Обеспечение целостности данных

Целостность данных обеспечивается в системе достаточной стройностью модели данных, использованием при этом декларативных правил целостности, хранимых триггеров и корректной выдачи в программах команд фиксации транзакций

Предотвращение несанкционированного доступа и обеспечение сохранности данных

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

Сохранность данных с точностью до последней фиксированной транзакции при сбое питания обеспечивается ORACLE путем автоматического восстановления базы данных при последующем запуске экземпляра.

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

Яценко П.Н.

 



Copyright © 1994-2016 ООО "К-Пресс"