Обзор решений автоматизации в ЖКХ: программное обеспечение ЖКХ

2. Обзор решений автоматизации в ЖКХ: программное обеспечение ЖКХ

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

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

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

Используем состав участников, перечисленный в первой части:

– Население

– Поставщики услуг

– Банки, пункты приема платежей

– ЖЭКи

– Расчетно-кассовый центр

– Учреждения власти

Население

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

Поставщики услуг

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

– Расчет отпуска

– Работа с приборами учета

– Перерасчеты

– Учет льгот

– Учет субсидий

– Оплата за услуги

– Учет оборотов

– Расчет пени

– Юридическая служба

– Отчеты

Расчет отпуска услуг

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

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

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

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

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

Одновременно на предприятие могут поступать независимые данные о других отключениях, например, о ремонте какой-либо ветки, отходящей от этой магистрали, а из ЖЭКа приходит информация об индивидуальных отключениях. Периоды различных документов могут пересекаться. Аналогично поступают на предприятие данные об отклонении от нормативного качества предоставляемых услуг. Для учета информации об отключениях и качестве услуг IT-система имеет в своей базе данных модель средств доставки услуг (обычно это древовидная структура) и средства для учета пересечений периодов, в диапазоне которых действуют предоставляемые данные.

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

Работа с приборами учета

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

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

Список трудностей и информационно-технических проблем при работе с приборами довольно внушительный.

Первая очевидная трудность – это правильность внесения показаний приборов. Появляются следующие ошибки:

– ввели показания не того прибора;

– текущее показание явно не соответствует предыдущему;

– ошибка в периоде, за который снято показание;

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

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

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

Третья – приборы должны периодически сниматься на поверку. Этот процесс должен быть поставлен на контроль. Для абонентов, у которых просрочена поверка, расчет количества отпуска выполняется расчетным методом. Несвоевременный ввод данных о возврате приборов с поверки снова приводит к необходимости перерасчетов.

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

Перерасчеты

Перерасчеты – это расчет величины корректировки количества и стоимости оказанных услуг для одного или нескольких прошедших периодов, или вмешательство в результат расчета текущего периода. Необходимость в перерасчетах обусловлена двумя причинами: недостоверными исходными данными и недостаточно развитым функционалом системы.

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

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

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

Учет льгот

Льгота со стороны абонента – это та сумма, на которую ему уменьшается платеж за коммунальные услуги. Ему выставляется счет на 25%, 50% и т.д. меньше, чем другим таким же абонентам, но не имеющим льготы. Льгота со стороны поставщика услуг – это сумма, которую за абонента платит бюджет. Льгота не уменьшает общую стоимость отпущенных услуг. Это просто один из видов оплаты.

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

Социальная норма потребления – это расчетное нормативное количество услуг, рассчитанное на одного человека. В пределах этой величины осуществляется льготирование. Превышение количества услуг по сравнению с нормативом не льготируется. Например, норма потребления электроэнергии на человека составляет 75 КВтч. Льгота у абонента – 50%. Получено в отчетном периоде 90 кВтч. Из них 75 отпускаются за пол цены, а оставшиеся 15 – по полной.

Зависимость между льготами состоит либо в самом характере льготы, либо в ограничении общей стоимостью полученных услуг. Характер льготы отражается в методе расчета. Например, льгота исполкома сельским учителям – 100% от суммы, оставшиеся после применения других льгот. Ограничение стоимостью отпуска состоит в том, что сумма льгот по всем привилегиям абонента не должна превышать общую стоимость отпущенной продукции.

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

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

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

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

Учет субсидий на предоставляемые услуги

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

А в системах ЖКХ остаются только функции учета и контроля:

– ввод (импорт) полученных субсидий;

– отслеживание платежной дисциплины абонентов, получающих субсидии

предоставление данных для расчета субсидий в соответствующие службы

Оплата

Ввод оплаты или импорт ее из банковских программ или систем РКЦ сопровождается решением нескольких задач:

– учет по видам оплаты;

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

– учет оплаты безналичной оплаты по банкам

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

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

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

Обороты

Это стандартная задача учета остатков на начало и конец месяца, дебета и кредита за отчетный период.

Расчет и начисление пени

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

Юридическая служба

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

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

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

Отчеты

Существует масса отчетов, формируемых информационными системами ЖКХ. Например, квитанции на оплату, ведомости расчета услуг, оборотно-сальдовые ведомости, списки льготников и субсидий, реестры льготников, отчеты по оплате и задолженности и др. Формирование отчетов по начислениям, оплате, задолженности, субсидиям. Формирование и печать платежных документов по оплате жилищно-коммунальных услуг в различных вариантах, оперативная отчетность в требуемых разрезах (оборотно-сальдовые ведомости по начислениям, оплате, задолженности и другие отчетные формы), статистическая отчетность, формирование сводных ведомостей.

Отдельная группа отчетов предназначена для работы с неплательщиками:

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

– отслеживание просроченной задолженности.

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

Банки

Пункт приема платежей

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

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

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

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

Бухгалтерия банка

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

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

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

ЖЭКи

ЖЕК, с одной стороны, выступает в системе ЖКХ как поставщик услуг, а с другой – как место учета населения. Как поставщик услуг ему свойственны все те функции, что и для всех других поставщиков услуг. Здесь рассмотрим ЖЭК, как место учета населения.

Регистрация населения

Регистрация населения осуществляется в соответствии с требованиями законодательства. Это предоставляет ряд следующих возможностей:

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

– ведение реестра населения;

– ведение архивов регистрационных записей;

– формирование всех видов справок;

– формирование необходимой отчетной документации.

Паспортный стол (Если он входит в состав ЖЭК)

Решаются следующие задачи:

– прописка и выписка (листок прибытия, листок выбытия);

– формирования списка жильцов, избирателей;

– справка о составе семьи, о регистрации иностранного гражданина, о свободной жилплощади и др. справки,

– отчетность в различные службы

Информация для поставщиков услуг

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

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

Расчетно-кассовый центр (РКЦ)

Роль расчетного центра – организация всей системы платежей в масштабах города. Функциональные возможности его программного обеспечения предназначены для решения этой главной задачи:

прием информации о начислениях за услуги от внешних организаций;

выдача информации в банки о состоянии лицевых счетов граждан;

регистрация банковских выписок по платежам населения;

прием наличных платежей и зачисление их на лицевые счета граждан;

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

выдача информации получателям платежей о принятых платежах;

прием информации из банков о платежах населения;

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

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

прием их паспортного стола;

информация о движении квартиросъемщиков.

К попутным задачам относятся: прием населения и выполнения расчетов в соответствии с количеством и стоимостью услуг вместо поставщиков этих услуг.

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

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

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

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

Учреждения власти

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