Центр системных исследований "ИНТЕГРО"

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

РАБОЧИЕ МЕСТА

9. ОТДЕЛЬНЫЕ ПОДСИСТЕМЫ (РАБОЧИЕ МЕСТА)

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

9.1. Подсистема документооборота

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

РИС_41.png
рис. 41 Вид рабочего места сотрудника ОКО

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

9.2. Подсистема для администраторов платежей

Для распределения данных о платежах, поступивших собственнику из управления Федерального казначейства (УФК), создана подсистема, которая состоит из конвертора (программы, осуществляющей перенос данных о платежах в систему «Имущество»), и программы, осуществляющей «связывание» каждого платежа с конкретным договором, который имеется в системе «Имущество», и его распределения по договорам. Если платежи не относятся ни к одному договору, или же имеются какие-либо неопределенности, не позволяющие однозначно связать платеж со сделкой, в программе распределения платежей имеется возможность создать уведомление в УФК и вывести его на печать. Если УФК передал собственнику кроме данных о платежах еще и мемориальные ордера с уточнениями, в системе имеется еще одна программа, которая позволяет обрабатывать мемориальные ордера и увязывать их с конкретным уведомлением. Таким образом, ведется не только учет поступивших из УФК данных о платежах, но и учет уведомлений и мемориальных ордеров и контроль их исполнения.

9.2.1. Программа переноса данных о платежах в систему «Имущество»

Специальная программа (рис. 42) расшифровывает поступившую из УФК информацию и записывает ее в таблицы системы. После этого информация по платежам становится доступна всем пользователям системы, и эти платежи могут быть распределены по конкретным договорам.

РИС_42.png
рис. 42 Программа для переноса в Систему информации о платежах
9.2.1.1. Импорт информации о поступлениях

Для импорта в систему «Имущество» информации о платежах, поступающей из УФК, используется подсистема Импорта платежей. С помощью этой подсистемы можно внести всю информацию из следующих документов, передаваемых из УФК с помощью СЭД-АП:

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

• Информация из расчетных документов, прилагаемых к выписке,

• Запросы на выяснение принадлежности платежа.

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

Входными данными для подсистемы являются текстовые файлы, выгруженные из СЭД-АП. При запуске программы необходимо указать путь к этим файлам (рис. 42.1.).

РИС_42.1.png
рис.42.1

Далее, в окне «Содержимое директории», можно проверить, информация из каких файлов будет импортирована в систему (рис. 42.2).

РИС_42.2.png
рис.42.2

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

РИС_43 (3).png
рис. 42.3

При нажатии на кнопку «Импорт» запускается процесс импорта платежей, в ходе которого осуществляются действия:

  1. Импорт всей поступившей из УФК информации в рабочие таблицы.
  2. Импорт информации о платежах и возвратах из выписки (с использованием информации из расчетных документов).
  3. Импорт мемориальных ордеров из выписки.
  4. Связывание мемориальных ордеров с соответствующими им исходными платежами.
  5. Связывание возвратов с соответствующими заявками на возврат
9.2.1.2. Импорт поступившей информации

Первоначально вся информация из СЭД-АП вносится в базу в «рабочие» таблицы (для проверки корректности).

После импорта всей исходной информации из файлов СЭД-АП осуществляется заполнение таблиц, данные из которых используются в системе «Имущество» на всех этапах администрирования платежей.

9.2.1.3. Импорт информации о платежах и возвратах

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

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

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

9.2.1.4. Импорт мемориальных ордеров

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

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

9.2.1.5. Привязка мемориальных ордеров к платежам

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

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

  • КБК списания в мемориальном ордере должен совпадать с КБК в платеже;
  • Дата мемориального ордера должна быть позже даты платежа;

Если к платежу подготовлено уведомление, то связь мемориального ордера с платежом осуществляется через уведомление. В этом случае проверяется совпадение номера и даты уведомления в мемориальном ордере и платеже, КБК списания/зачисления, ОКАТО списания/зачисления.

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

9.2.1.6. Привязка возвратов к заявкам на возврат

После импорта возвратов осуществляется их привязка к исходной заявке на возврат.

Для определения исходной заявки на возврат используется информация о возврате из выписки (номер и дата документа-основания).

9.2.2. Программа распределения платежей по договорам

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

_РИС_43
рис. 43 Поисковая форма системы распределения плптежей

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

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

РИС_44.png
рис. 44 Информация по платежу в системе

Если установлено состояние платежа «Не распределен», то этот платеж можно распределить. Для этого имеется операция «Распределить платеж». При выполнении данной операции система определяет, относится ли данный код КБК к одной из групп по видам платежей (например, за аренду земли или за аренду ОНФ). Если указанный КБК отнесен к соответствующей группе, то система ищет в базе договоров аренды земли договора, относящиеся к указанному плательщику, и выводит список этих договоров (рис. 45). Если не будет найдено ни одного договора, то можно осуществить поиск договоров вручную.

РИС_45.png
рис. 45 Список договоров для указанного плательщика

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

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

9.3. Подсистема контроля поступления платежей из банка «Уралсиб» по системе «Город»

По соглашению с банком «Уралсиб» КУМС г. Уфы регулярно посылает реестр договоров, которые заключает КУМС с субъектами. Если плательщики оплачивают начисленные КУМС платежи за пользование имуществом по системе «Город» через банк «Уралсиб», то периодически банк посылает в УФК информацию о платежах в виде двух текстовых файлов — файл реестра платежей и файл отредактированных примечаний, в котором информация по платежам детализирована.

Разработана подсистема, которая позволяет осуществлять следующий контроль передаваемой в УФК информации:

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

9.4. Подсистема массового формирования уведомлений

Если необходимо подготовить и разослать уведомления определенного вида (например, о погашении долга или о пролонгации договоров) большому числу субъектов, тогда используется подсистема массового формирования уведомлений. Она позволяет подготовить задание для формирования уведомлений, сформировать список объектов рассылки (сделок), автоматически определить и заполнить адреса рассылки, сформировать и распечатать тексты уведомлений (рис. 46).

РИС_46.png
рис. 46 Пример подготовки задания для массового формирования уведомлений

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

Если уведомление сформировано, то информация о нем заносится в процесс оформления соответствующей сделки.

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

Имеется возможность сформировать и распечатать уведомления о вручении.

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

Для подготовки уведомлений об уточнении вида и принадлежности платежа (далее – уведомлений) и заявок на возврат (далее – заявок) используется приложение «Подсистема подготовки уведомлений». Она позволяет создавать реестр уведомлений на уточнение платежей или реестр заявок на возврат. Для этого необходимо только выбрать нужные платежи (они должны быть предварительно импортированы в систему имущество с помощью подсистемы импорта платежей) и ввести необходимые реквизиты. Затем созданные с помощью подсистемы уведомления и заявки можно импортировать в СЭД-АП и отправить в УФК. При создании уведомлений и заявок с помощью подсистемы не требуется копировать исходные данные из платежа, они вносятся автоматически.

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

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

Форма поиска платежей выглядит следующим образом – Рис. 1.

РИС_46_1png.png
рис. 46.1 Форма поиска платежей

На левой панели можно ввести критерии поиска:

  • электронный номер документа;
  • № документа (платежного поручения);
  • дата последнего существенного изменения. Это дата импорта (если к платежу не было мемориальных ордеров), либо дата мемориального ордера, уточнившего платеж;
  • дата реестра – дата реестра УФК, в котором содержался платеж;
  • ИНН плательщика;
  • КПП плательщика;
  • наименование плательщика;
  • ОКАТО, указанный в выписке;
  • КБК, указанный в выписке;
  • сумма платежа;
  • сумма из копии платежного поручения – первоначальная сумма. Может быть больше суммы платежа в случае частичного уточнения платежа.

Для поиска платежа можно использовать как один из критериев, так и несколько. Обычно уточняются платежи из последнего реестра, находящиеся на невыясненном КБК (например, 10011701010010000180. Поэтому чаще используются поля «дата реестра» и «КБК».

После ввода критериев поиска и нажатия на кнопку «Поиск» в таблице выдается список платежей, удовлетворяющих критериям поиска (рис. 46.2).

РИС_46_2.png
рис. 46.2 Результаты поиска после введения критериев

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

Зеленым (этот цвет указывается в меню Настройки -> Цветовые схемы) выделены платежи, последнее уведомление у которых исполнено – то есть:

  • либо уведомление не принято ФК (отказано) и этот факт отмечен в системе «Имущество». Тогда в платеже ничего не изменилось – находится на прежнем КБК (ОКАТО);
  • либо из органа ФК прислали мемориальный ордер, который связался с платежом, изменив при этом КБК, ОКАТО или сумму.

К этим платежам можно готовить повторное уведомление.

Если платеж не выделен цветом, значит, к нему еще ни разу не готовилось уведомление.

В нижней части формы отображается дополнительная информация о выделенном в данный момент платеже: КБК выписки и приложения к выписке; ОКАТО выписки и приложения к выписке; № и дата последнего уведомления (если было подготовлено); № и дата последнего мемориального ордера (если есть мем. ордер); предшествующие КБК и ОКАТО (с которых списали); новые КБК и ОКАТО (на которые уточнили) – если есть мемориальный ордер.

В списке нужно отметить галочкой платежи, к которым необходимо подготовить уведомления или заявки*. Помеченные платежи выделяются желтым (рис. 46.3) – этот цвет указывается в меню Настройки -> Цветовые схемы. Далее переходим непосредственно к формированию уведомлений (заявок).

РИС_46_3.png
рис.46.3 Помеченные платежи
9.4.1.2. Подготовка уведомлений

Форма редактирования уведомлений содержит уведомления к платежам, которые были выбраны для уточнения (рис. 46.4). В нижней части формы выведена вспомогательная информация о платеже, к которому подготовлено выделенное уведомление. Все поля уже заполнены, необходимо только внести параметры для уточнения (КБК, ОКАТО или сумму).

РИС_46_4.png
рис. 46.4 Форма подготовки уведомлений

На форме редактирования реестра уведомлений можно работать в двух режимах: массовая замена и единичная. Массовая замена необходима тогда, когда несколько платежей нужно уточнить на одни и те же КБК и ОКАТО. Единичная замена используется тогда, когда каждый платеж необходимо уточнить на определенные КБК и ОКАТО.

После того, как для всех уведомлений проставлены КБК, ОКАТО и суммы, на которые необходимо уточнить, нужно нажать кнопку «Сформировать реестр уведомлений и уведомления в нем».

Открывается форма Реестр реестров уведомлений (рис. 46.5) с только что сформированным реестром.

РИС_46_5.png
рис. 45.5 Только что сформированный реестр уведомлений

В подсистеме подготовки уведомлений из формы «Реестр реестров уведомлений» (сразу после подготовки уведомлений – рис. 46.5, либо меню Реестры -> Реестры уведомлений) для любого реестра уведомлений можно подготовить следующие документы в Excel:

  • уведомления;
  • выписку в журнал регистрации уведомлений;
  • реестр уведомлений.

Также можно сформировать текстовый файл для импорта в СЭД-АП.

9.4.1.3. Подготовка заявок на возврат

Форма редактирования реестра возвратов содержит заявки на возврат к платежам, которые были выбраны для возврата (рис. 46.6). Все поля из платежа уже заполнены, при необходимости можно внести изменения (например, в поля: Сумма заявки на возврат, Назначение платежа, Номер счета и БИК банка получателя платежа).

РИС_46_6
рис. 46.6 Форма подготовки заявок на возврат

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

Открывается форма Реестр реестров возвратов (рис. 46.7) с только что сформированным реестром.

РИС_46_7
рис. 46.7 Только что сформированный реестр возвратов

В подсистеме подготовки уведомлений из формы «Реестр реестров возвратов» (сразу после подготовки заявок – (рис. 46.7), либо меню Реестры -> Реестры возвратов) для любого реестра заявок на возврат можно подготовить следующие документы:

• заявки на возврат;

• реестр возвратов.

Также можно сформировать текстовый файл для импорта в СЭД-АП.

9.4.1.4. Формирование файла для отправки в УФК

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

9.4.1.5. Дополнительные функции подсистемы подготовки уведомлений

1. История платежа

Кратко историю платежа можно просмотреть в форме «Реестр платежей». Если навести фокус на интересующий платеж, то внизу формы можно увидеть КБК/ОКАТО из копии платежного поручения, КБК/ОКАТО из выписки. Для платежей, к которым подготовлены уведомления, отображается информация о последнем уведомлении (номер и дата). Для платежей, с которыми связаны мемориальные ордера, отображается информация о последнем уведомлении (номер и дата) и о соответствующем ему мемориальном ордере (номер и дата).

Также можно просмотреть и более подробную историю платежа: узнать, какие вообще были уведомления и мемориальные ордера к этому платежу (рис. 46.8).

РИС_46_8
рис. 46.8

2. Связь мемориальных ордеров с платежами

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

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

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

3. Статистика по уведомлениям и возвратам

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

4. Резервирование номеров уведомлений и заявок на возврат

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

5. Дублирование уведомлений

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

9.5. Подсистема массового перерасчета арендной платы

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

В качестве примера можно привести переход на расчет арендной платы за аренду земли по кадастровой стоимости.

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

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

9.6. Рабочее место для юристов

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

Наиболее полно проработана процедура учета судебных исков (рис. 47). Она позволяет учитывать не только иски, в которых Комитет является истцом, но также судебные иски, в которых Комитет выступает ответчиком или же третьим лицом.

РИС_47.png
рис. 47

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

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

9.7. Подсистемы для администратора

Разработана также подсистема ИнМета для администратора системы «Имущество», средства которой позволяют настраивать Систему под конкретные требования ведения учета объектов имущества и оформления сделок с ними. Эти средства делают Систему открытой для дополнений и изменений.

В данную подсистему входят следующие средства:

  • построитель выходных документов;
  • настройка прав доступа;
  • просмотр журнала изменений;
  • метаданные.

9.7.1. Построитель выходных документов

Построитель выходных документов позволяет встраивать в Систему шаблоны выходных документов, и связывать их с информацией, хранящейся в Системе. Шаблоны выходных документов формируются в формате «*.doc» текстового процессора MS Word.

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

Для встраивания в Систему новых выходных документов требуется хорошо знать архитектуру Системы и структуру метаданных.

9.7.2. Подсистема настройки прав доступа

Подсистема настройки прав доступа позволяет (рис. 48):

  • описать рабочие места Системы
  • завести пользователей Системы и связать их с рабочими местами
  • описать функции пользователей и разрешить или запретить пользователям действия с информацией в Системе.
РИС_49.png
рис. 48 Страница настройки прав доступа

Реализованы два вида разрешений/запретов:

  • запреты для всех, кроме …
  • запреты для …

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

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

9.7.3. Просмотр журнала изменений

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

_РИС_50
рис. 49 Журнал изменений