Данной статьей я планирую начать цикл публикаций об информационных технологиях в системе ЖКХ. Об актуальности даже заикаться не будем. Итак, всем ясно, что времена ручного заполнения квитанций на квартплату уходят в прошлое. Казалось, что с ними уходят и большинство проблем, однако… Как говорится исправляя старые ошибки мы волей не волей совершаем новые. Предположительно цикл будет состоять из четырех частей – общей информации, работы паспортных столов, работы Единых Информационных Расчетных Центров (ЕИРЦ) и, наконец, системы для работы с юридическими лицами. Что же, приступим…
Если вдуматься, то вся идея автоматизации и компьютеризирования системы ЖКХ (Жилищно-Коммунального Хозяйства) должна служить трем целям: удобству и быстроте работы операторов (паспортистов, экономистов, бухгалтеров), удобству, простоте и прозрачности для конечных пользователей (физических лиц и юридических лиц), повышению процента сбора денежных средств Дирекциями Единого Заказчика (ДЕЗ). Допустим с быстротой, в принципе, все в порядке – печать квитанций на квартплату на двадцать тысяч лицевых счетов занимает часов шесть. А вот со всем остальным периодически возникают различные проблемы. Подробнее них мы остановимся в соответствующих разделах. Для начала я попробую прояснить работу системы в целом. На первый взгляд все кажется очень сложным, но если разложить все по полочкам, то разобраться не так уж и сложно. Приступим.
Что мы имеем в качестве исходных данных. Есть потребитель (физическое или юридическое лицо – пока не важно) и есть ДЕЗ. ДЕЗ предоставляет потребителям коммунальные и эксплуатационные услуги, а взамен получает плату за свою работу. Задача – сделать взаимодействие между этими двумя субъектами как можно эффективнее и, по возможности, чтобы оно удовлетворяла трем условиям, которые я описал выше. Формально это означает следующее – как Дирекции собирать плату за свои услуги. До недавнего времени было так. Жилец раз в месяц самостоятельно заполнял квитанцию на оплату, в которой он указывал услугу и цену за нее. Далее нес ее в Сбербанк и оплачивал. Основное неудобство, что намеренно или случайно гражданин мог ошибиться в сумме. Тогда у него образовывался долг или переплата, что естественно было плохо, поскольку разобраться в этом спустя, например, полгода было очень проблематично. Где же выход? Предложили следующее. Пусть квитанции выдает сам ДЕЗ! Ведь написать программу (точнее базу данных) которая формирует ЕПД (Единый Платежный Документ) не очень большая, на первый взгляд, проблема. Но! Если сделать начисления на месяц в соответствии с действующими тарифами, объемами, количеством жильцов, льготами и субсидиями не сложно, то как Дирекция узнает, что клиент это начисление оплатил? Не приносить же им всем свои квиточки обратно. Было предложено решение, которое с одной стороны прибавило головной боли программистам софта для ДЕЗа, но с другой позволило свести к минимуму хождения жильцов по всяческим инстанциям. Предполагалось обрабатывать платежи клиентов электронно! Однако у Дирекций нет, и не было средств и возможностей для реализации данной идеи. Нужен посредник, который будет принимать от потребителей деньги, переводить их на счет ДЕЗа и после этого отправлять туда же сведения о том, кто, сколько и когда оплатил денег. Причем сведения эти необходимо предоставлять в электронном виде, поскольку набивать вручную эти «оплаты» у операторов просто не хватит сил и времени. Посредником выступил Банк Москвы. Совместно с ним, Дирекциями и организациями, которые разрабатывали программы, была придумана следующая схема. Когда оператор выписывает ЕПД, автоматически формируется начисление по данному лицевому счету. Далее в конце рабочего дня или на следующий день, эти начисления выгружается в файл, который в последствии отправляется в Банк Москвы по специальному защищенному каналу связи. Начисления «подливаются» в базу и ждут. Чего? Когда клиент придет в банк и оплатит ЕПД, который и соответствует виртуальному начислению в базе. Далее оплата в виде квитка сканируется на специальном аппарате (ЕПД снабжен штрих кодом), сравнивается с тем, что прислали ранее и, если все в порядке, то в виде другого файла отправляется в ДЕЗ все по тому же каналу связи. Вот и все. Просто и красиво! Однако это в идеале. Но не все так гладко. Из выше написанного следует, что для безошибочного функционирования этой схемы необходимо соблюдения следующего условия – начисление и оплата должны всегда совпадать не только по общей сумме, но и по услугам! Если же этого не произойдет, тогда программа банка не сможет правильно распределить оплату по поставщикам (после того как деньги перевели на расчетный счет ДЕЗа, он переводит их поставщикам в соответствии с начислениями) и, следовательно, они не смогут полностью получить свои деньги. Как же поступает банк в таком случае? Он формирует еще один файл – так называемый файл запросов. В нем указываются проблемные оплаты. Чтобы урегулировать конфликт, ДЕЗу необходимо сформировать новое начисление точно на ту сумму, которую оплатил клиент. Если потребитель заплатил меньше чем надо, то Дирекция формирует начисление равное его оплате, плюс еще одно – остаток, и ЕПД с остатком выдает клиенту при встрече. Если произошла переплата, то начисление в следующем месяце будет меньше на сумму переплаты. В общем, все построено так, чтобы у потребителя был «нулевой баланс» - ни долгов, ни переплаты. Кстати, забыл сказать, что банк имеет некий процент с тех денег, которые проходят через него подобным образом. И еще. В Дирекции были сформированы специальные расчетные центры (ЕИРЦ), которые взяли на себя функции расчета квартплаты.
Это, что касается коммунальных услуг. В паспортных столах естественно никаких денег не фигурирует (ну кроме взяток конечно). И, тем не менее, они неразрывно связаны с ЕИРЦ. Подробнее об этом в следующей части. Для ПС актуально вести обмен данными с милицией (сведения о выбывших, прибывших, умерших и родившихся). Как видите, все подразделения Дирекции очень тесно связаны не только между собой, но и с другими ведомствами. Отсюда следует логичный вывод – объединить программы для ПС и ЕИРЦ в один комплекс для удобства, однако это не всегда удается. Продолжение следует…

Андрей Удовенко
27.07.2005