Красина Ф.А. Автоматизированная обработка налоговой информации

Подождите немного. Документ загружается.

• кодификация и систематизация законодательства;

• методология налогового законодательства;

• работа с налоговой инспекцией;

• судебно-арбитражная практика.

Кодификация и систематизация законодательства заключаются в

основном в решении системных вопросов правового обеспечения: обеспе-

чение законодательными и нормативными актами сотрудников региональ-

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

ских баз данных (писем, внутренних документов региональной налоговой

инспекции и т.д.).

Исходной информацией для решения указанных задач служат:

• база данных нормативных и законодательных актов по налогооб-

ложению;

• база данных законодательных и нормативных актов других отрас-

лей права.

Для обеспечения полноты информации при решении поставленной

задачи в общем случае инспекции необходимо иметь в своем распоряже-

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

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

ке и хорошо себя зарекомендовавшие. При значительном информационном

пересечении различных систем полная информационная среда должна

иметь возможность доступа к различным БД. При такой организации ин-

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

средств, объединяющих различные базы данных в единую метабазу с воз-

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

полагается, что такая метабаза будет существовать как составная часть

электронного информационного хранилища. Цель этой разработки – уни-

фицированный доступ к правовой базе данных всех заинтересованных

пользователей налоговой инспекции. При этом функции администрирова-

ния БД должны принадлежать юридическому управлению, остальные

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

Решение задач по методологии налогового законодательства связа-

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

выми вопросами.

Основная функция состоит в подготовке ответов на запросы налого-

плательщиков по всем проблемам налогообложения, а также в разработке

предложений по совершенствованию налогового законодательства.

Основная функция при работе с налоговой инспекцией заключается в

консультировании по вопросам налогового законодательства в связи с за-

просами инспекции. Если ответ выходит за пределы компетенции юриста,

к подготовке ответа подключаются специалисты методологии налогового

законодательства.

Информационные потребности данных задач, помимо доступа к об-

щеправовым базам данных, предполагают:

• возможность ведения собственных профессиональных баз данных

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

• возможность организации и ведения собственного документообо-

рота;

• создание базы прецедентов по видам налогов и по субъектам (ин-

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

венности и видам деятельности). Создание такой базы данных связано с

возможностью расхождений в ответах, данных в различные периоды вре-

мени различными субъектами по сходным проблемам налогообложения.

Разработка базы данных прецедентов предполагает создание систе-

мы классификации ответов, ведение статистики запросов, поиска и подбо-

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

Судебно-арбитражная практика предполагает реализацию двух ос-

новных функций:

• решение методологических вопросов для налоговой инспекции;

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

налоговой инспекции и ведение базы данных судебных прецедентов.

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

пуска подборок материалов судебно-арбитражной практики.

Для принятия многоаспектных решений по письменным запросам

налоговой инспекции с учетом методологических вопросов и анализом су-

дебной практики предлагается поддержка как профессиональной базы

данных запросов, судебных прецедентов во взаимосвязи с информацион-

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

вочно-консультационной гипертекстовой системы с элементами искусст-

венного интеллекта для подбора полной информации по каждому возни-

кающему запросу.

Помимо указанных информационных потребностей, возникает необ-

ходимость в поддержке базы данных предложений по совершенствованию

налогового законодательства.

Ведение базы данных доведенческих писем тесно связано с совер-

шенствованием документооборота в инспекциях в целом и упорядочением

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

этой проблемы требует создания сетевого варианта регистрации доведен-

ческих писем в налоговой инспекции с обязательной пометкой о прохож-

дении письма через юридическое управление.

Обобщая сказанное, можно выделить следующие основные инфор-

мационные потребности при разработке юридического обеспечения регио-

нальной налоговой инспекции:

• базы данных по налоговому законодательству, разработанные раз-

личными организациями;

• общеправовые базы данных, имеющиеся на информационном

рынке;

• база данных прецедентов по видам налогов и субъектам;

• база данных прецедентов судебной практики;

• база данных предложений по совершенствованию налогового за-

конодательства;

• профессиональные базы данных по рабочим местам;

• система регистрации прохождения доведенческих писем.

Для разработки информационного обеспечения юридической систе-

мы региональной налоговой службы необходимо проведение следующих

работ:

• определение состава и структуры каждой БД с детализацией до

информационного элемента и их взаимосвязи;

• разработка программной надстройки над системой различных пра-

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

доступным системам;

• разработка системы классификации и кодирования информацион-

ных элементов различных баз данных;

• разработка структуры и состава информационных рубрикаторов

различных баз данных;

• первоначальное наполнение профессиональных баз данных преце-

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

• разработка или подбор адекватной гипертекстовой среды для реа-

лизации многоаспектных запросов к справочно-консультационной право-

вой системе;

• разработка или выбор единой системы документооборота;

• обеспечение доступа к общеправовым базам данных в режиме за-

проса других управлений и округов;

• реализация взаимодействия с информационным обеспечением

управления методики и ревизий;

• создание единой сетевой системы доступа к правовым БД из нало-

говой инспекции.

2.10 Основные подсистемы районного уровня

Подсистемы предназначены для автоматизации задач, решаемых в

районной инспекции.

Подсистема регистрации предприятий предназначена для ввода

информации по контролируемым предприятиям и учредителям предпри-

ятий (физическим и юридическим лицам), получения информации по

предприятиям в виде таблиц.

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

дующие реквизиты:

• наименование плательщика;

• вид деятельности;

• место регистрации;

• регистрационный номер;

• сведения о филиалах;

• данные об иностранных инвестициях;

• информация обо всех счетах предприятия (валютных, текущих,

субсчетах и др.;

• все атрибуты, необходимые для быстрого поиска плательщика в

информационно-поисковой системе.

Изначально при регистрации любого нового предприятия все исход-

ные данные о нем должны заноситься в компьютер с присвоением ему оп-

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

его в Госреестр предприятий.

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

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

предприятий, предоставляя пользователю возможность вести поиск по лю-

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

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

са приемки квартальной бухгалтерской отчетности предприятий, состоящих

на учете в налоговой инспекции. Подсистема должна обеспечивать:

• проверку расчетов, взаимоувязку форм отчетности, начисление

налогов;

• формирование достоверной базы данных в результате приема

квартальной и годовой отчетности;

• автоматическую генерацию типовых форм отчетности налоговой

инспекции;

• выдачу рекомендаций инспекторскому составу для документаль-

ных проверок.

Подсистема ведения лицевых карточек предприятий должна обес-

печивать:

• фиксацию платежных документов;

• автоматическое вычисление сальдо, начисление пени, выдачу

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

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

• получение справки о недоимках и переплатах по предприятиям;

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

• печать инкассовых поручений.

Подсистема анализа состояния предприятий обеспечивает выбор

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

анализа итогов деятельности предприятий на основании данных, сформи-

рованных инспектором при камеральных проверках, а также информации,

хранящейся в электронном хранилище данных.

По различным критериям и показателям формируется список пред-

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

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

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

налоговых инспекциях разрабатывается на основе применения законода-

тельных актов, позволяющих налоговой службе осуществлять контроль за

правильностью исчисления и уплаты налогов физическими лицами, в том

числе: подоходного налога, имущественных налогов, земельного налога,

налога с транспортных средств и др.

Подсистема для обработки документов физических лиц должна осу-

ществлять контроль и управление информацией по основным видам нало-

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

На основании первичных документов, поступающих из государст-

венных учреждений и от физических лиц, должны автоматически рассчи-

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

лицевой счет. Система должна автоматически вести лицевые счета по всем

видам налогов, распределять уплаченные суммы по срокам уплаты.

По всем видам налогов должны вычисляться бухгалтерские отчеты:

• сводка начислений;

• ведомость доначислений и сложений;

• реестр уплаты возвратов;

• список недоимщиков.

Информационно-поисковая подсистема нормативно-правовых доку-

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

постановлениями, указами, распоряжениями и другими правительствен-

ными документами, приказами, распоряжениями и методическими указа-

ниями Государственной налоговой службы Российской Федерации и ана-

логичными документами руководства региональной инспекции.

Подсистема должна быть реализована на базе информации элек-

тронного хранилища регионального уровня, обеспечивающего методиче-

скую и юридическую деятельность.

Основная функция подсистемы – сопровождение исковых заявлений

в суд и арбитраж.

Глава 3. ОСНОВНЫЕ ПРИНЦИПЫ РАЗРАБОТКИ АИС

НАЛОГОВОЙ СЛУЖБЫ

Для успешного проведения работ по разработке и совершенствова-

нию АИС налоговой службы необходимо выработать общие принципы по:

• выбору архитектуры АИС;

• выбору методологии разработки;

• применению CASE-средств.

3.1 Выбор архитектуры АИС

АИС налоговой службы можно представить в виде совокупности

программных подсистем, решающих определенный круг задач. Подсисте-

мы состоят из взаимодействующих компонентов (рис. 3.1).

Рис. 3.1 – Архитектура АИС

Архитектурой АИС называется распределение функций по ее под-

системам и компонентам, точное определение границ этих подсистем и их

взаимодействия по управлению и данным, а также распределение хранения

и исполнения этих подсистем и компонентов по различным ЭВМ, объеди-

ненным в локальную или глобальную вычислительную сеть.

Опыт показывает, что только изменение архитектуры АИС при про-

чих равных условиях может изменять в сотни раз суммарные затраты на

разработку. Поэтому правильный выбор архитектуры АИС – наиболее эф-

фективный способ снижения стоимости разработки и эксплуатации всей

системы в целом.

С целью эффективного управления информационно-вычислитель-

ными ресурсами в распределенной системе в основу архитектуры АИС на-

логовой службы положена трехуровневая модель «клиент−сервер», из-

вестная как модель сервера приложений (Application Server – AS) (рис.

3.2).

Рис. 3.2 – Модель «клиент−сервер»

Здесь компонент представления (клиент третьего уровня) обеспечи-

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

второго уровня) – прикладные функции, характерные для налоговой служ-

бы; компонент к ресурсам (сервер первого уровня) – функциональные

функции хранения и управления данными (базами данных, файловыми

системами и т.п.).

Основная цель выбора такой модели – отделение компонентов, реа-

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

законодательными документами по налогообложению. В случае налогово-

го законодательства только отдельные компоненты, а не вся система в це-

лом. Это существенно позволит экономить ресурсы на модификацию АИС.

В качестве серверов используются мини-ЭВМ или «мейнфрейм», а

клиентов – ПЭВМ или терминалы на рабочих местах конечных пользова-

телей. Такая архитектура базируется на вычислительных сетях с неодно-

родным техническим и программным обеспечением, что предполагает со-

ответствующую сетевую операционную систему, позволяющую осуществ-

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

нических средств.

Архитектура таких распределенных интероперабельных информаци-

онных систем базируется на концепции промежуточного слоя

(middleware), содержащего службы и средства поддержки глобального

пространства объектов (программных компонентов).

Спецификации ОМА (Object Management Architecture) – фактических

международных стандартов для построения распределенных объектных

систем в гетерогенных средах разработаны консорциумом Object Manage-

ment Group (OMG).

Компьютер−клиент

Компонент

представления

Компьютер

−

сервер

Прикладной

компонент

Компьютер−сервер

Компонент

доступа

к ресурсам

ОМА состоит из четырех основных компонентов, представляющих

собой спецификации различных уровней поддержки приложений:

• архитектура брокера запросов объектов (CORBA-Common Object

Request Broker Architecture) устанавливает базовые механизмы взаимодей-

ствия объектов в гетерогенной сети;

• сервисы объектов (Object services) являются основными системны-

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

• универсальные средства (Common Facilities) ориентированы на под-

держку пользовательских приложений, таких, как электронная почта,

средства печати и т.п.;

• объекты приложений (Application Objects) предназначены для ре-

шения конкретных прикладных задач.

Спецификация CORBA определяет механизм, обеспечивающий

взаимодействие приложений в распределенной среде. Концептуально

CORBA относится к уровням приложений и представлений семиуровневой

модели сетевого взаимодействия. Она обеспечивает возможность построе-

ния распределенных систем и приложений на самом высоком уровне абст-

ракции в рамках международных стандартов. С ее помощью возможно

изолировать клиентские программы от низкоуровневых и гетерогенных

характеристик информационных систем.

Главные компоненты стандарта CORBA (рис. 3.3):

• обработчик объектных заявок (Object Request Broker);

• язык определения интерфейсов (Interface Definition Language), с

помощью которого могут быть определены операции для обращения кли-

ентов к серверным объектам;

• объектный адаптер (Object adapter), который предоставляет доступ

к сервисам объектного обработчика и обеспечивает все низкоуровневые

средства для связи объекта с его клиентами;

Рис. 3.1 − Структура интерфейсов

• репозиторий интерфейсов, представляющий собой средство для

хранения и обработки информации, необходимой для описания интерфей-

сов CORBA-объектов. Характерные особенности разработки приложений

по технологии CORBA заключаются в следующем:

• язык описания интерфейсов позволяет определить интерфейс, не

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

• высокий уровень абстракции CORBA в семиуровневой модели 081

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

• программисту не требуется информация о реальном месте распо-

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

• разработка клиентской программы не зависит от серверной опера-

ционной системы и аппаратной платформы;

• после модификации можно использовать ранее разработанные при-

ложения.

3.1 Методология разработки

Для упорядочения и регламентации процесса разработки сложных

АИС используют модель жизненного цикла (МЖЦ) программного обеспе-

чения, которая представляет собой логически связанную последователь-

ность основных этапов развития АИС – от появления обоснованной необ-

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

коренной реконструкции в соответствии с новыми возможностями техни-

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

Каждый этап МЖЦ определяется характерными для нее решаемыми

задачами, исходными и результирующими спецификациями, применяемы-

ми методами решения поставленных задач. На каждом этапе в соответст-

вии с решаемыми задачами применяются определенные инструментальные

средства и методология. Наиболее общие этапы МЖЦ АИС с характерны-

ми решаемыми задачами – анализ, проектирование, кодирование, тестиро-

вание и отладка, эксплуатация и сопровождение, устаревание.

Основные особенности МЖЦ АИС – отсутствие четко детерминиро-

ванных границ между соседними состояниями системы и ее статичность.

Первая особенность означает, что начало и конец каждого этапа жизненно-

го цикла накладываются один на другой и не могут быть точно определе-

ны во времени. Вторая связана с тем, что МЖЦ представляет собой некое

«застывшее» отображение реального процесса, задающее в явном виде

только перечень и логическую последовательность состояний АИС.

Последнее состояние в процессе разработки АИС представляет со-

бой готовую систему. Любой способ перевода проекта в новое состояние

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

ных процедур.

Методология составляет основу для проектирования и разработки

прикладных систем. Она задает определенную последовательность про-

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

стью в итоге получится хорошо работающее приложение. Методологии

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

все важные шаги или элементы, которые необходимо надлежащим обра-

зом учитывать.

Главное достоинство использования методологий разработки заклю-

чается в том, что они обеспечивают предсказуемость результатов и кон-

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

Методология представляет собой тесно связанные, предписанные

конкретные последовательности шагов; конкретные данные, подлежащие

накоплению на каждой стадии; критерии завершения работ в контрольных

точках; решения, которые нужно принять перед выбором между альтерна-

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

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

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

принципу декомпозиции – деления сложной системы на менее сложные

подсистемы:

1. Структурные методологии. Реализуют принцип алгоритмической

декомпозиции: АИС делится на модули, каждый из которых реализует не-

которую часть общего технологического процесса. Наиболее известны и

распространены:

• методология структурного анализа и проектирования Росса;

• методологии, использующие в качестве центрального метода моде-

лирование потоков данных: Гейн/Сарсон, ДеМарко, Йордон;

• методологии моделирования данных: Варнье/Орр, ЕК-моделирова-

ние Чена.

2. Объектно-ориентированные методологии. Реализуют принципы

объектной декомпозиции: АИС представляет собой совокупность взаимо-

действующих объектов, которые соответствуют словарю предметной об-

ласти. Наиболее известны и распространены объектные методологии сле-

дующих авторов:

Буч;

Рамбо;

Шлеер/Меллор;

Код/Иордон;

Универсальный язык моделирования.

Последний получает все большее распространение и становится фак-

тически международным стандартом.

Результатом использования этих методологий на каждом этапе явля-

ется построение набора моделей – графических спецификаций, которые

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

кладных систем. Фрагменты моделей приведены в приложениях 2.