(5 голосовало, оценка: 3,40 из of 5)

Загрузка...

НЕКОТОРЫЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ БИЛЛИНГОВЫХ СИСТЕМ В ЭНЕРГЕТИКЕ И ЖКХ

Часть I
Калуга, 2008

Комиссаров А.В.

Эта статья рассчитана на специалистов-разработчиков программных систем и комплексов, а также на руководителей предприятий по предоставлению услуг в области энергетики и ЖКХ. Не стоит рассматривать данный труд ни как учебное пособие, ни тем более как справочник. Его основная функция – прежде всего обсудить те трудные, «узкие» места в разработке биллинговых систем, с которыми пришлось столкнуться автору, и предложить пути решения сопутствующих проблем.

Введение

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

Прежде всего заметим, что на рынке уже существуют и продолжают разрабатываться «тяжёлые» биллинговые системы, в том числе в указанных областях. Например, в начале 2007 г. «КЭС-Холдинг и компания Oracle объявили о реализации проекта по созданию федеральной биллинговой системы КЭС-Холдинга на основе комплекса решений Oracle Utilities Global Business Unit. Проект подразумевает создание единой централизованной биллинговой системы для обслуживания 9,9 млн потребителей КЭС-Холдинга более чем в 20 регионах России и странах СНГ»[1]. Однако существует ряд причин, по которым руководство предприятия может принять решение не в пользу приобретения новых готовых систем:

·       стоимость покупной биллинговой системы  может составлять миллионы, даже десятки миллионов рублей и быть обременительной для предприятия, в то время как отсутствует потребность во многих функциях, входящих в комплект модулей покупной системы как единое целое;

·       в приведённом выше примере с КЭС-Холдингом и Oracle в случае покупки подобной системы предприятию также придётся произвести серьёзные затраты на  приобретение СУБД Oracle, которых можно было бы избежать, будь система реализована, к примеру, на Firebird, MySQL либо другой бесплатной или относительно недорогой (например, Cache) СУБД;

·       далеко не всегда оправдан выбор «тяжёлой» системы, если масштаб решаемых задач на несколько порядков ниже тех «типовых» требований, под которые создавалась покупная система. Например, если требуется обработка не 10 миллионов, а нескольких десятков…сотен тысяч абонентов. Это почти то же самое, что «бить из пушки по воробьям»;

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

В этом случае становится актуальным вопрос о разработке системы «на заказ» методами аутсорсинга (как правило, в данном случае исполнителем выступает небольшая софтверная или научно-производственная компания) либо  силами сотрудников IT-подразделения самого предприятия.

Но опыт показывает, что сотрудники IT-подразделения предприятия-заказчика могут быть серьёзно загружены поддержкой ряда работающих на предприятии разрозненных, зачастую морально устаревших программ и систем. В то же время сотрудники аутсорсинговой компании могут быть далеки от специфики функционирования предприятия-заказчика. Оптимальным в этом случае является «симбиоз» ресурсов предприятия и аутсорсинговой фирмы, когда их сотрудники совместно, причём очень тесно работают над проблемой. Под ресурсами здесь понимаются и человеческие ресурсы (непосредственные участники проекта, их квалификация), и организационно-методическая поддержка (как правило, со стороны руководства и отдельных специалистов предприятия-заказчика, а также специальная литература), и определённый фонд рабочего времени, и (последнее по порядку, но не по значимости!) материально-финансовая поддержка участников проекта.

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

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

Отыщи начало всему, и ты многое поймёшь.

Козьма Прутков

1. Причины и цели создания системы, или «для чего всё это нужно?»

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

1.1. Окружение предприятия

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

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

·       местные органы социальной защиты населения;

·       инспекции Федеральной налоговой службы Министерства финансов РФ.

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

Кроме того, для нас также будут иметь значение следующие контрагенты:

·       финансово-кредитные учреждения (отделения почтовой связи и филиалы банков), от которых производится поступление денежных средств, собранных у абонентов;

·       службы доставки сформированных документов-счетов на оплату (курьерская либо почтовая связь);

·       предприятия, осуществляющие контроль за формированием полезного отпуска услуги, а также обеспечивающие автоматический сбор показаний приборов учёта и производящие их поверку (для энергетики – это филиалы ОАО «Энергобаланс»).

Не стоит забывать и о том, что со временем у предприятия могут появиться (или уже появились) конкуренты, т.е. выполняющие аналогичную функцию субъекты, которые за счёт каких-то преимуществ (например, за счёт более высокого качества обслуживания абонентов или более низких тарифов[2]) захватили часть рынка сбыта, ранее относившуюся к данному предприятию. Немаловажную роль в конкурентной борьбе играет рациональный подход к автоматизации деятельности, о чём уже говорилось выше.

1.2. Взаимодействие предприятия с окружением

Если продолжать следовать аналогии с живым миром, в самом простом случае организм взаимодействует с окружающей средой посредством целой системы сигналов, представленных звуками, запахами и световыми импульсами. Эти сигналы отражают изменения только тех из внутренних параметров состояния объекта, которые представляют интерес для  его взаимодействия с окружающим миром в данный момент времени (и в данной точке пространства). В природе ничего просто так не делается.  Примеры читатель может привести сам.

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

Приведём пример: взаимодействие предприятия с абонентом. Такое взаимодействие в большинстве случаев проявляется путём формирования документов двух видов:

·       счёта на оплату услуги (как правило, счёта-фактуры для юридических лиц  и квитанции/извещения – для физических) – стадия I;

·       документа, фиксирующего факт оплаты абонентом услуги (это может быть погашенное кассовым оттиском извещение, заполненная форма ПД-4) – стадия II.

Эти документы формально отражают две (как правило, разнесённые во времени) стадии операции купли-продажи, сопровождающиеся разнонаправленным изменением состояния счёта абонента и предприятия. На первой стадии  происходит уменьшение суммы на счёте предприятия (и увеличение её на счёте абонента — за счёт полученной услуги), на второй – всё с точностью до наоборот. Счёт абонента называют также лицевым счётом.

Аналогичные примеры можно привести и для случаев взаимодействия предприятия с другими субъектами окружения, но в данном пункте это было бы излишним.

1.3. Внутренняя жизнь предприятия

Как было сказано выше, структура предприятия и его параметров во многом определяется окружением предприятия.  На самом абстрактном уровне структура любого предприятия может быть представлена как совокупность неких структурных объектов и бизнес-процессов, связывающих эти объекты в нужной последовательности. Такая связь необходима для функционирования предприятия.  Под структурными объектами можно в самом простейшем случае подразумевать иерархически и функционально организованные подразделения предприятия: производственные участки, службы, группы, отделы, отделения и т.д. Например, «Калужская сбытовая компания», ОАО, в котором автору довелось проработать более пяти лет, имеет географически распределённую структуру: представлена тремя отделениями и центральным подразделением — управлением, причём каждое отделение представлено несколькими (порядка 8…15) производственными участками, а также группами и отделами. Управление представлено службами и отделами.

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

·       обеспечение устойчивого взаимодействия с окружением;

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

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

I.  Исходные данные

II.  Расчёты

III.  Отчёты и статистика

IV.  Анализ и прогноз

V.Планирование и принятие долгосрочных решений.

Действительно, уровни I – II (III) соответствуют производственным участкам, уровни II – III – Отделениям компании, уровни III — V – Управлению компании.

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

Теперь мы можем ответить на поставленный в начале главы вопрос: «Зачем нужно создавать автоматизированную программную систему, в частности, биллинговую?»  Без создания такой системы в современных условиях практически невозможно решать задачи выполнения предприятием (в лице руководства и трудового коллектива) своих функций и обязательств, как (главным образом) взаимодействия с внешней средой, так и управления внутренними процессами – причём на всех уровнях, начиная подготовкой данных и заканчивая долгосрочным планированием и принятием адекватных управленческих решений.

2. Исходные данные

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

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

Каким же образом поступают данные в биллинговую систему? Здесь есть два пути:

·       ввод данных оператором (с использованием мыши, клавиатуры и, возможно, сканера штрих-кода);

·       импорт данных из внешних источников. Возможен только в случае наличия уже ранее подготовленных данных во внешнем источнике (например, автоматический сбор показаний – АСКУЭ и подобные системы), а также в случае наличия подсистемы импорта данных из внешнего источника. Таким способом при выполнении двух перечисленных условий могут передаваться показания счётчика, а также данные по оплате услуги.

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

Прежде всего, выделим точечные и интервальные параметры. Для точечного параметра характерной является привязка к конкретному моменту времени (с точностью до дня или более высокой – часов, минут, секунд).  Для интервального параметра существует диапазон дат, на который распространяется действие того или иного значения параметра.  Пример точечного параметра: показание прибора учёта (счётчика)[4]. Пример интервального параметра: величина (ставка) тарифа по конкретной тарифной группе (например, с 01.01.2007 г. по 31.12.2007 г действует одна величина, с 01.01.2008 г. — другая).

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

Далее выделим условно-постоянные (редко, эпизодически изменяемые) и условно-переменные (регулярно изменяемые) данные. К условно-постоянным данным можно отнести, например,   ФИО абонента,  его прочие паспортные данные; заводские параметры прибора учёта. К условно-переменным можно отнести, например, показания прибора учёта.

3. Влияние исходных данных на расчёты и отчёты. Хронологические аспекты целостности учёта

Расчёт – это процесс определения промежуточных или конечных параметров какого-либо процесса на основе исходных. Сами по себе результаты расчётов используются при подготовке документов и отчётов. Наибольшее значение имеет процесс регулярного расчёта начисления потреблённой электроэнергии как один из наиболее общих и значимых расчётов в биллинговой практике.

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

·       позволять ли пользователям изменять исходные данные, влияющие на расчёты и отчёты, и если да, то при каких условиях?

·       каким образом система должна реагировать на изменения данных?

·       следует ли хранить промежуточные и конечные результаты расчётов (повторных расчётов) в базе данных, включая результаты начислений и сальдо по лицевым счетам?

·       каким образом избежать дублирования и неучтённых отчётных данных?

·       следует ли устанавливать зависимость между временем (периодом) потребления услуги и периодами подготовки отчётов по начислению и оплате?

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

·       текущее состояние формируемых документов (счетов, квитанций/извещений) должно основываться ТОЛЬКО на текущем состоянии исходных данных;

·       вся совокупность отчётных данных также должна полностью соответствовать текущему состоянию исходных данных, и ТОЛЬКО ему. Кроме того, изменение исходных данных не должно приводить к изменению уже сформированного (зафиксированного, «сданного») отчёта;

·       данные в любом отчёте, который является итоговым, или отчётом-сводкой (т.е. представляет собой суммы параметров в разрезе отдельных категорий абонентов), должны быть отражены один и ТОЛЬКО один раз. Дублирование и наличие неучтённых данных не допускаются.

3.1. История изменения значений параметров

Для начала предположим, что пользователь или подсистема импорта  данных застрахованы от ошибок (хотя такого в жизни не бывает!). Но ведь сами параметры  — взять те же тарифные ставки или показания счётчика – не являются величинами постоянными!». Совершенно верно, и об этом уже говорилось в п. 2, когда речь шла о точечных и интервальных, условно-постоянных и условно-переменных параметрах. Так вот, опыт показывает, что практически все параметры, используемые в расчётах и для подготовки отчётов, должны быть хронологически определёнными точечными либо интервальными величинами. Действительно, в противном случае потребовалось бы изменение значения параметра путём «затирания» предыдущего значения, а это привело бы к потере соответствия между ранее сформированным отчётом и  исходными данными. В случае же невозможности изменить значение параметра (именно такое предположение мы сделали в начале пункта), работа бы вообще остановилась, т.к. все последующие документы и отчёты просто повторяли бы предыдущие. Итак, вести историю изменения значения параметра необходимо.

3.2. Расчётные и отчётные периоды

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

Итак, расчётный период (РП) – это месяц, в течение которого происходило потребление услуги, это наименьший временной диапазон, за который может быть произведено начисление за потреблённую услугу. Как минимум, по отношению к одному расчётному периоду (месяцу)  устанавливаются значения тарифов, нормативы безучётного (в случае отсутствия прибора учёта) потребления, величины социальных норм потребления услуги (учитываются, например, при расчёте некоторых видов льгот).

Определённые сложности состоят в том, что на практике в большинстве случаев невозможно совместить во времени процессы потребления услуги (в некотором месяце M), начисления за потребление услуги в месяце M и оплаты за потребление услуги в месяце M (см. рис. 3.1). Дело в том, что начисление не может быть произведено в месяце M (за исключением случаев, когда расчёт ведётся по плановым, или договорным, величинам[5], а также по заданным наперёд нормативам безучётного потребления), так как до тех пор, пока этот месяц не закончится, не будет известно и точное значение потребления за данный месяц.  Далее, оплата за месяц M (за исключением случаев авансовой оплаты) в подавляющем большинстве случаев производится не раньше момента получения абонентом счёта на оплату услуги за месяц M.  Хотя с ростом числа систем электронных терминалов и повышением удобства работы с ними количество таких случаев будет сокращаться. С другой стороны, возможны и задержки против предельного срока оплаты.

П

РПk ОПm

РПk+1 ОПm+1

РПk+2 ОПm+2

Расчет начисления за РП(k). Прием оплаты за РП(k-1)

Расчет начисления за РП(k-1). Прием оплаты за РП(k-2)

Расчет начисления за РП(k+1). Прием оплаты за РП(k)

Платежи (ОПm+2)

Начисления (ОПm+2)

Рис.3.1. К иллюстрации соотношения расчетных и отчетных периодов

Указанные выше обстоятельства вынуждают нас наряду с расчётным периодом ввести ещё одно понятие — отчётный период.

Отчётным периодом будем называть промежуток времени (не обязательно полностью совпадающий по продолжительности и датам с календарным месяцем), в течение которого происходит сбор информации по начислениям и поступлениям (платежам)[6] для отражения в отчётах.  Для систем электронного документооборота практикуется[7] следующее соглашение: основанием для отнесения документа или его фрагмента (начисления или платежа) к тому или иному отчётному периоду является момент (дата-время) занесения (последнего изменения) информации по нему в электронную базу данных. Предположим, отчётный период «Сентябрь 2007» имеет границы «с 00:00:00 27-го августа  по 23:59:59 26-е сентября  2007 года включительно». В этом случае платёж, введённый, к примеру, 26.09.2007 в 16:45 будет отнесён к отчётному сентябрю, а платёж, занесённый 27.09.2007 в 08:10 – уже  к  отчётному октябрю.

Здесь возникает следующий вопрос: следует ли хранить в базе данных в качестве одного из атрибутов документа отчётный период, если фиксируется дата-время создания/последнего изменения документа? Казалось бы, эти атрибуты дублируют друг друга. Понятно, что в базе данных должна быть таблица (у нас она называлась TS_PERIOD), в которой фиксируется дата-время начала и окончания (по умолчанию) каждого отчётного периода. Зная дату последнего изменения документа и учитывая то обстоятельство, что периоды ни в коем случае не должны перекрываться, с использованием этой таблицы можно однозначно определить отчётный период, к которому документ относится.

С другой стороны, возможна следующая ситуация: на компьютере (или на сервере, с которым данный компьютер синхронизируется) произошёл сбой в установке системного времени. Это повлечёт за собой неверную фиксацию даты-времени создания/изменения документа, который модифицировался в базе данных после сбоя. Предположим теперь, что через определённое время (отчёты уже предварительно подготовлены, но ещё не сданы) этот сбой был выявлен и устранён. Администратор БД вынужден в этом случае изменить атрибуты изменённых (занесённых) документов таким образом, чтобы они «попали» в нужный отчёт. В случае присутствия атрибута «отчетный период» это сделать достаточно просто – всего лишь требуется изменить значение кода отчётного периода и переформировать последний отчёт. Правда, в этом случае нарушится соответствие между границами отчётного периода «по умолчанию» в таблице периодов и кодом периода документа. Но это «нарушение» не повлияет на формирование отчётов: ведь анализируется в указанном случае всегда только код отчётного периода, а не дата документа (при вводе/модификации документа из даты-времени документа получаем код отчётного периода).

В случае же, когда анализ принадлежности документа к отчётному периоду производится исключительно на основании даты, при обнаружении сбоя системного времени администратору БД придётся изменять дату-время документа на какое-то в общем случае «фантомное» значение[8] (т.к. в этом случае определить реальное значение даты-времени, как правило, не представляется возможным), которое обеспечит попадание документа в нужный отчёт.

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

3.3. Соотношение периодов

Рассмотрим более подробно типовую схему соотношения периодов различных операций (см. рис. 3.1) на конкретном примере. Рассмотрим отчетный период – сентябрь 2007 г. Пусть его начало[9] – 27-е августа 2007 г., а окончание – 26-е сентября 2007 г. (включительно). В отчетном сентябре 2007 г. делают в массовом порядке начисления за расчетный[10] август 2007 г. и вводят в БД (и разносят, т.е. переводят в фиксированное состояние) оплату, в основном за расчетный июль 2007 г. Упомянутые начисления будут отражены в статье «полезный отпуск»[11] отчета за  сентябрь 2007 г., а платежи – в статье «реализация» отчета за сентябрь 2007 г. Вместе с тем, может поступить оплата  за предыдущие расчетные периоды – июнь, май и т.д., которая также будет отражена в отчетах за сентябрь.

3.4. Отклонения от регулярной схемы и их причины. Закрытие отчётного периода

В идеальном (и самом простом) случае границы отчётного периода могут совпадать с границами календарного месяца. Например, для отчётного периода  «сентябрь 2007 г.» — с  00:00:00  01.09.2007 г. по 23:59:59 30.09.2007 г..  В этом случае сбор информации по платежам и начислениям для отчётов каждый раз происходит по всем дням соответствующего календарного месяца.

Однако на практике многие операции, так или иначе связанные со сбытовой[12] деятельностью и в конечном итоге влияющие на отчётность (доставка счетов абонентам, оплата абонентами счетов,  доставка информации об оплате или оплаченных счетов в сбытовую компанию, снятие показаний приборов учёта, доставка информации о контрольных показаниях и нарядах на замену/установку/снятие счётчиков), не являются регулярными относительно границ календарного месяца.  Причины этому могут быть разные, как и «виновники» этих явлений:

·       задержки в работе почтовых и банковских систем,

·       нерегулярность оплаты и сообщения показаний абонентами,

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

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

Таким образом, возникает необходимость в отдельной операции «закрытие отчётного периода». На практике она сводится к следующим действиям:

·       фиксируется правая граница текущего отчётного периода указанным моментом времени;

·       текущий отчётный период помечается как «закрытый».

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

Наконец, осталось сформулировать самый главный «постулат» этого пункта, связанный с необходимостью поддержания целостности отчётных данных: «Любая модификация данных (добавление, изменение, удаление), относящихся к отчётам закрытого периода, не должна изменять результаты этих отчётов  ни при каких условиях!»  Т.е. отчёт закрытого периода считается «фиксированным» и «сданным», изменению не подлежит. В дальнейшем отчёты закрытого отчётного периода будем просто называть закрытыми отчётами.

3.5. Закрытые и незакрытые расчётные периоды

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

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

3.6. Обработка ситуаций изменения исходных данных «поздним числом»

Относительно изменения исходных данных, которые уже «поучаствовали» в формировании документов и отчётов, существуют две возможности:

·       вообще запретить какое-либо изменение исходных данных;

·       предусмотреть механизм отражения указанных изменений на предстоящих (незакрытых) отчётах, т.е. на отчётах ещё не закрытых отчётных периодов[13].

Первый способ для большинства реальных биллинговых систем, связанных с оказанием услуг населению, вряд ли подойдёт, поскольку различные, в том числе рассмотренные в предыдущем пункте, «дестабилизирующие» факторы вынуждают менять исходные данные, по дате относящиеся даже к закрытым расчётным периодам. Например, абонент указал неверное показание счётчика на определённую дату, а затем сообщил правильное; показания счётчика или наряды на смену/установку/снятие счётчика поступили от службы контроля и учёта с опозданием и т.д.  Следовательно,  выбрать следует второй способ, который и рассмотрим поэтапно в следующих пунктах.

3.7. Хранение результатов расчётов в базе данных

Зачастую разработчики программных систем,  использующих  базы данных, спорят о том, следует или нет сохранять в базе данных  результаты расчётов. Аргумент «против» сохранения выглядит примерно так: «Всякий расчёт может быть повторён при необходимости любое количество раз (на основании исходных данных), а вот загромождать базу «лишними» данными не следует». Приведём возражения против подобного рода аргументов.

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

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

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

Например, в бухгалтерии часто используют термин «Проводки», или «Обороты». Суть его состоит в отражении перехода сумм с одного счёта (например, счёта абонента) на другой счёт (например, счёт организации – поставщика услуг), причём этот процесс раскладывается на отдельные составляющие «переходящей» суммы, которые называются статьями, или регистрами учёта. Применительно к результатам расчёта начислений тоже создаётся список регистров учёта, относящихся к различным элементам, из которых складывается результирующая величина расчёта начисления по абоненту.

Приведём фрагмент регистров (статей) учёта применительно к начислениям[14] (пример взят из системы учёта бытовых потребителей электроэнергии, в разработке которой принимал участие автор данного пособия):

·       РАСХОД по 1 ступени[15]

·       РАСХОД по 2 ступени

·       ЛЬГОТА 50% по 1 ступени (берётся со знаком «-»)

·       ЛЬГОТА 50% по 2 ступени (берётся со знаком «-»)

·       ЛЬГОТА 100% по 1 ступени (берётся со знаком «-»)

·       ЛЬГОТА 100% по 2 ступени (берётся со знаком «-»)

·       НАЧИСЛЕНО ПО АКТУ

3.8. Перерасчёт начислений и определение величин коррекции

Целью перерасчёта начислений является определение величин коррекции, которые отразили бы в последующих (незакрытых) отчётах изменения в исходных данных, в том числе на временных диапазонах, относящихся к закрытым расчётным периодам.

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

(3.1),

где  i – номер лицевого счёта,  j —  номер регистра учёта, а  k – номер расчётного периода, к которому относится данное начисление.

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

(3.2),

где n – номер перерасчёта (он соответствует n+1- ому расчёту начисления).

При подстановке n=1  получим формулу (3.1), где опущен верхний индекс (1), а верхний индекс (2) заменён верхним штрихом (суммирование по α в данном случае выполняться не будет, т.к. правая граница индекса суммирования менее левой границы). В дальнейшем, если не указано иное, будем для перерасчётов использовать формулу (3.2) как отражающую наиболее общий случай.

Из приведённых формул следует, что в общем случае в базе данных хранить необходимо не только «первичные» начисления, но и результаты коррекций начислений – по каждому лицевому счёту, регистру учёта и расчётному периоду[16].

Понятно, что перерасчёт обязательно должен быть выполнен по всем закрытым расчётным периодам. Но следует ли затрагивать при этом незакрытый расчётный период? По сути дела, любой повторный расчёт незакрытого периода должен сопровождаться формированием новой версии документа – счёта на оплату. Автору известны работающие системы с двумя разными подходами к этому вопросу.

3.9. Два разных подхода к перерасчёту незакрытого расчётного периода

Подход 1. Незакрытый расчётный период интерпретируется в плане перерасчёта точно так же, как и закрытый. В этом случае:

·       суммирование (по k, см. формулу 3.2)  производится по всем расчётным периодам, для которых хотя бы одно из слагаемых в формуле (3.2) не равно нулю;

·       повторный расчёт незакрытого периода никогда не записывается как отдельное начисление в базу данных (даже если сменился отчётный период), только как коррекция начисления;

·       при формировании счёта на оплату производится расчёт по формуле:

(3.3)

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

Преимущества данного подхода:

·       единообразие при формировании отчётов:  в этом случае формирование итоговой величины начислений (как в натуральном, так и в стоимостном выражении) по лицевым счетам в разрезе некоторой категории G за отчётный период T производится по достаточно простой формуле[17]:

(3.4)

(простота здесь связана с тем, что нет необходимости анализировать разные отчётные периоды);

Недостатки данного подхода:

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

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

Преимущества данного подхода:

·       «прозрачность» при формировании счёта на оплату: никаких суммирований с коррекциями не производится, просто берётся начисление (и его фрагменты) за незакрытый расчётный период, соответствующие наибольшему отчётному периоду;

Недостатки данного подхода:

·       дополнительная сложность при формировании отчётов, связанная с необходимостью анализа различных отчётных периодов, а также с необходимостью анализа расчётного периода. В случае, когда существуют две записи начислений по последнему закрытому расчётному периоду, относящиеся к разным (соседним) отчётным периодам, в отчёте наибольшего периода должно быть учтено не полностью данное начисление (т.к. это привело бы  к дублированию части данных в разных отчётах), а лишь та его часть, которая не отражена в предыдущем отчёте. Кроме того, необходимо учесть начисление, относящееся одновременно к последнему расчётному и к последнему отчётному периоду. Аналитически это выглядит так (сравните с формулой 3.4):

(3.5)

В формуле (3.5) суммирование коррекций (крайнее правое слагаемое) идёт только по закрытым расчётным периодам; номер k соответствует незакрытому (текущему) расчётному периоду.

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

3.10. Связь между начислениями/коррекциями и исходными данными

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

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

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

Интерес к причинам коррекций исходных данных (а следовательно, и начислений) могут проявлять всевозможные контролирующие и заинтересованные органы, например, в энергетике – предприятия «Энергобаланса», службы контроля учёта, сетевые компании. В том случае, если периодичность проверок и разбирательств такого рода невысока (скажем, не чаще, чем раз в квартал), то можно ограничиться  первым вариантом.

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

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

3.11. Платежи и сальдо

Понятие «сальдо» по отношению к лицевым счетам абонентов означает задолженность либо переплату (в зависимости от знака). Если рассматривать сальдо как разность между начислениями и поступлениями (суммой платежей), то знак «+» соответствует задолженности, а «-» — переплате:

(3.6)

(в данной формуле i –  номер лицевого счёта, а  τ – промежуток времени – с начала истории  начислений и до некоторого момента —  на конец которого нужно определить величину сальдо; суммирование идёт по некоторым подмножествам документов, о которых будет сказано ниже).

Как правило, сальдо по обычным (рядовым) операциям и по нарушениям (актам) считаются отдельно.

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

·       «черновик» — документ занесён в базу данных, но может продолжать редактироваться. На отчётах и при подсчёте сальдо платёж не отражается;

·       «проверен» — сверены контрольное и фактическое количества и суммы платежей в пачках и бандеролях[18]. На отчётах и при подсчёте сальдо платёж не отражается.

·       «разнесён» — платёж переведён в фиксированное состояние и не подлежит дальнейшему редактированию. На отчётах и при определении сальдо платёж отражается.

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

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

При определении сальдо по рядовым операциям подмножество Ψ содержит рядовые (не по актам) начисления, а подмножество Ω – рядовые (не по актам), но только разнесённые платежи.

При определении сальдо по актам подмножество Ψ содержит начисления по актам, а подмножество Ω – разнесённые платежи по актам[19].

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

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

Что касается расчётного периода, то в некоторых системах считают сальдо и по нему. Для этого дополнительно вводят поле «расчётный период» в таблицу платежей. Скорее, это нужно рассматривать как «рудимент». Необходимости в фиксации сальдо на конец расчётных периодов в отчётах нет. В документах же (счетах на оплату) обычно указывают сальдо на первое число расчётного месяца. Определить его также не представляет особого труда: для этого достаточно определить сальдо на текущий момент (т.е. на момент формирования квитанции) и вычесть из него начисление за расчётный месяц.

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

Об авторе: 1977 г.р., образование высшее техническое, специалист в области компьютерных систем и сетей, разработки программного обеспечения и баз данных. Имеет публикации (тезисы докладов, 1998-1999 гг) по темам, связанным с базами данных и искусственным интеллектом. Имеет опыт работы с биллинговыми системами в области электроэнергетики с декабря 2002 г (адаптация и участие в разработке систем на предприятии «Калужская сбытовая компания», ОАО).

Эта запись была опубликована 25.11.2008в 8:34 дп. В рубриках: Экономика, Интеллектуальные здания, Все статьи. Вы можете следить за ответами к этой записи через RSS 2.0. Вы можете оставить свой отзыв или трекбек со своего сайта.