Автоматизация процессов приема и регистрации документов от физических лиц в Управлении Федеральной налоговой службы по РСО-Алания

 

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

Декомпозиция DFD осуществляется на основе процессов: каждый процесс  может раскрываться с помощью DFD нижнего уровня. Важную специфическую  роль в модели играет специальный  вид DFD.

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

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

 

Рис.2. 1 Начальная контекстная диаграмма

 

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

 

 

Рис.2. 2  Детализированная контекстная диаграмма

 

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

 

Рис.2. 3 Диаграмма детализации для процесса Организация движения документа внутри УФНС по РСО-А.

 

На данной диаграмме изображен  процесс Организации движения документа внутри УФНС по РСО-А. Как видно из рисунка, Организация движения документа внутри УФНС по РСО-А начинается с информационно справочной работы. Входящими потоками для той работы являются содержание документа. Далее происходит доведение документа до исполнителя, после которой оформляется результат: отказ в исполнении или контроль за дальнейшим исполнением документа. Затем согласование и подписание проекта документа.

 

 

 

 

 

2.2. Программное обеспечение задачи

 

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

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

При проектировании таблиц лучше разработать структуру  на бумаге и только затем начинать работу с СУБД Access. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

-    Не должно быть  повторений и между таблицами.

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

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

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

- Каждое поле должно  быть связано с темой таблицы. 

- Не рекомендуется включать  в таблицу данные, которые являются  результатом выражения.

- В таблице должна присутствовать  вся необходимая информация.

     - Информацию  следует разбивать на наименьшие  логические единицы (Например, поля  «Имя» и «Фамилия», а не общее  поле «Имя»).

 

2.2.1 Структура и создание таблиц

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

• Текстовый. Текст или числа не требующие проведения расчётов.
• МЕМО.  Поле этого типа предназначено для хранения небольших текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым или проиндексированным.
• Числовой.  Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вычислений.
• Счётчик.  Уникальные, последовательно возрастающие  числа, автоматически вводящиеся при добавлении новой записи в таблицу.
• Логический.  Логические значения, а так же поля, которые могут содержать одно из двух возможных значений.
• Денежный. Денежные значения и числовые данные, используемые в математических вычислениях.
• Дата/Время. Дата и время хранятся в специальном фиксированном формате.
• Поле объекта OLE. Включает звукозапись, рисунок и прочие типы данных. Поле этого типа не может быть ключевым или проиндексированным.
• Гиперсвязь.  Содержит адреса Web-страниц.

Для создания базы данных  сначала  запускаем  Microsoft Access 2007.

Для  реализации Базы данных нами были разработаны следующие  таблицы: Регистрационная карточка, Контроль, Сотрудники управления, Структура  Управления Федеральной Налоговой  службы по РСО-Алания.

1. Для  таблицы Регистрация были созданы поля:

• Код входящего документа

• Входящий номер
• «От кого»
• «Исходящий №»
• «Дата исходящего» Зарплата
• Дата регистрации
• Название
• Краткое содержание
• «Кому»

Типы данных показаны на рис.2.4.

Рис 2.4. Таблица Регистрационная карточка в режиме Конструктора

 

2. Таблица Сотрудники УФНС по РСО-А с полями:

• Код сотрудника
• код отдела
• Должность
• ФИО
• Рабочий телефон
• Дата рождения
• Адрес
• Функции
• Заработная плата;

Рис 2.5. Таблица Сотрудники УФНС в режиме Конструктора

 

3. Таблица Оказание услуг с полями:

• Код отдела  (Счётчик, обязательное,  уникальное);

    Наименование отдела (тип данных – мастер подстановок, фиксированный набор отделов УФНС по РСО-А:

общий отдел

отдел обеспечения

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

правовой отдел

отдел информатизации

- отдел учета, анализа  налоговых поступлений

отдел регистрации и учета  налогоплательщиков

отдел налогообложения юридических  лиц

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

отдел налогообложения физических лиц

работы с налогоплат-ами, ввода и обр-ки данных);

• Руководитель отдела
• Теленфон отдела

Рис 2.6. Таблица Структура УФНС в режиме Конструктора

 

4. Таблица Список должностей с полями:

•      Код (Счётчик, обязательное,  уникальное);

• входящий номер  (источник строк SELECT [Регистрационная карточка].[Код входящего документа], [Регистрационная карточка].[Входящий номер], [Регистрационная карточка].[Название] FROM [Регистрационная карточка] ORDER BY [Входящий номер];);
• код сотрудника
• Срок исполнения
• Контроль исполнения
• Пометка
• Дата исполнения
• Регистрационный № ответного документа
• отметка об отказе в исполнении (логический)
• отметка об исполнении (логический).

 

Рис 2.7. Таблица Контроль  в режиме Конструктора

 

2.2.2. Структурная  схема

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

1. Каждая таблица состоит  из однотипных строк и имеет  уникальное имя.

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

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

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

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

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

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

 

Рис 2.9.. Создание связей

 

В итоге после установления всех связей между таблицами, получаем следующую схему данных.

 

Рис.2.10. Схема базы данных

 

 

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

 

2.3.1. Организация  сбора, правки, просмотра информации

 

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