Реферат на тему:

Проблеми автоматизації бізнес-процесів податкової служби

Перехід України до ринкових відносин, подальше розгортання
державотворчих процесів, проведення соціально-економічних реформ,
розширення міжнародного співробітництва, розвиток демократизації
суспільства в умовах революційних зрушень у науково-технологічній сфері
на початку XXI століття викликають різке зростання вимог до рівня
інформатизації суспільства та інформаційно-аналітичного забезпечення
органів державного управління. На сучасному етапі переходу від
індустріального до інформаційного суспільства ступінь використання
інформаційного простору та інформаційних технологій стає безпосереднім
чинником економічного зростання, забезпечення обороноздатності країни,
соціально-політичної стабільності та розвитку демократичних засад в
управлінні державою. Автоматизована інформаційно-аналітична система
органів державної податкової служби України як складова частина
Інтегрованої інформаційно-аналітичної системи органів державної влади та
органів місцевого самоврядування скерована на забезпечення
оперативності, достовірності, доступності інформації в органах ДПС, а
також підвищення ефективності та досягнення якісно нового рівня
прийняття рішень у системі управлінні державою.

Разом із становленням податкової служби розвивалась також і інформаційна
система. Метою створення інформаційної системи податкової служби є
автоматизація процесів прийняття рішень щодо адміністрування податків.

Перший етап (1993–1998 рр.) розвитку інформаційної системи включав
поступову автоматизацію бізнес-процесів районного рівня за допомогою
автоматизованих робочих місць (АРМ), створених у середовищі СКБД FoxPro.
Засобами АРМ були автоматизовані такі процеси:

– ведення карток особових рахунків, відстрочок, журналу висновків
платників податків юридичних осіб – АРМ „Держдоходи”;

– облік юридичних осіб – АРМ „Облік платників”;

– облік суб’єктів підприємницької діяльності – фізичних осіб – АРМ
„Підприємці”;

– облік фізичних осіб – платників земельного податку – АРМ „Земля”;

– наповнення Єдиного державного реєстру фізичних осіб – АРМ „ДРФО”;

– планування документальних перевірок та ведення журналу обліку
результатів контрольно-перевірочної роботи – АРМ “Аудит”;

– облік реструктурованих сум – АРМ „Реструктуризація”;

– ведення журналу взаємозаліків;

– ведення журналу видачі патентів.

Звітні АРМи районного рівня нараховували більш ніж 20 одиниць та, як
правило, дозволяли виконувати такі прості функції:

– введення даних звіту;

– контроль введеної інформації за рахунок збитковості вводу (додатково
вводилися контрольні суми рядків чи граф );

– передача структурованого файла до обласної ДПА;

– зведення (агрегація) даних на обласному рівні;

– передача звіту по області до ДПА України.

Усі перераховані вище АРМи автоматизували окремі ділянки і не були
інтегровані між собою, хоча й мали певні точки інтеграції (як правило,
на рівні облікових даних або на рівні облікових даних і картки особового
рахунку). Більш того, незважаючи на можливість формування звітів
автоматично, звітність ДПІ формувалась все ж таки вручну. Пояснення тому
було наступне:

– недостовірність інформації в первинних базах даних;

– нецентралізоване ведення довідників;

– відсутність контролю за станом даних;

– дублювання даних у різних підсистемах та накопичення помилок.

Єдиною з перелічених систем, яка формувала центральну базу даних, була
система ДРФО.

У 1997–1998 роках було розроблено автоматизовану інформаційну систему
„Галузь”. Ця система формувала з обмеженого переліку показників картки
особового рахунку („нараховано”, „сплачено”, „недоїмка”, „переплата”,
”нараховано пені”) та деяких облікових показників („орган управління”,
„організаційно-правова форма”, „форма власності”, „основний вид
діяльності”) експортний файл, який передавався до обласного та
центрального рівнів.

Звітність в основному формувалась помісячно, деякі звіти мали статус
оперативної звітності, а також щодекади. Інформація з підсистеми
„Галузь” дозволяла автоматизовано отримувати деякі звіти, однак велика
похибка даних (5–15 %) не забезпечувала вимоги щодо достовірності
інформації.

У 1998 р. у зв’язку зі зміною податкового законодавства було розпочато
роботи по розробці АРМу „ПДВ”, який розроблявся у середовищі СКБД
FoxPro. Однак при побудові системи було запроваджено наступне:

– проаналізовані бізнес-процеси фізичних осіб – СПД і юридичних осіб, та
виділено спільні, зокрема при веденні карток особових рахунків та
облікових даних;

– запроваджено централізоване розповсюдження довідників;

– розроблено словник бази даних (опис таблиць, полів, індексів);

– розроблено систему контролю бази даних (перевірка унікальності
первинних ключів, перевірка зовнішніх ключів, перевірка заповнюваності
полів і інше);

– розроблено систему розподілу прав до даних за функціональною ознакою;

– систему спроектовано так, що основну бізнес-логіку з розрахунків та
формування звітності було описано також у базі даних;

– модульний принцип побудови системи.

На жаль, існуюче технічне забезпечення та відсутність достатнього
досвіду розробників не дозволила побудувати систему районного рівня на
базі SQL-сервера. Однак принципи, закладені при проектуванні АРМу „ПДВ”
дозволили на його основі розробити у 2000 р. автоматизовану систему
„Облік податків і платежів”, яка інтегрувала АРМ районного рівня в єдину
систему. На момент написання статті дана система інтегрувала в себе такі
підзавдання:

– ведення карток особових рахунків юридичних та фізичних осіб;

– ведення журналу обліку відстрочених сум;

– забезпечення процедур річних перерахунків для суб’єктів
підприємницької діяльності;

– ведення реєстру об’єктів оподаткування платників земельного податку
фізичних осіб;

– забезпечення імпорту нарахованих з підсистеми по обробці податкової
звітності;

– забезпечення ведення реєстру податкових вимог;

– забезпечення ведення реєстру податкових повідомлень;

– забезпечення ведення Національного плану документальних перевірок;

– забезпечення ведення справ про банкрутство;

– забезпечення роботи аналітичної системи „Картка боржника”;

– забезпечення імпорту сплачених сум з банківських файлів;

– ведення журналу торгових патентів;

– ведення реєстру платників єдиного податку;

– ведення журналу податкових векселів.

Починаючи з 1998 року, в органах ДПС запроваджено комп’ютерну обробку
податкової звітності платників, починає також формуватися база даних
податкових декларацій. Спочатку система використовується лише для
реєстрації документів та внесення сум, що підлягають нарахуванню в КОР,
потім і для внесення повного документа.

У серпні 2000 року у промислову експлуатацію впроваджено АІС обласного
рівня (далі – АІС ОР), розроблену на основі сучасних технологій. АІС ОР
забезпечує комплексну автоматизацію функцій підрозділів обласних ДПА з
інформацією баз даних регіону, має розвинену систему пошуку та
агрегування відібраних даних.

Функціонально АІС ОР розділяється на три блоки:

– підсистема економічного аналізу;

– пошукова підсистема;

– підсистема роботи з карткою платника.

Пошукова підсистема дозволяє виконувати добір платників по більш ніж 300
показниках (реєстраційних, економічних, податкових) і по практично
необмеженій кількості їхніх комбінацій.

АІС ОР є базовою для інформаційного забезпечення спеціалізованих
інспекцій великих платників податків і організаційно-аналітичних
підрозділів по боротьбі із приховуванням неоподаткованих доходів і
відмиванням доходів, одержаних незаконним шляхом.

Станом на початок 2004 року загальна кількість запитів до баз даних АІС
ОР досягла 2 мільйонів (статистику дозволяє збирати сама система).
Система спроектована так, щоб технічно її можна було б використати і на
центральному рівні.

Розширення номенклатури інформації Центрального банку даних (ЦБД) за
рахунок впровадження АІС ОР, надання користувачам всебічної інформації
про стан розрахунків кожного платника з бюджетом у щоденному
оперативному режимі, надало фахівцям податкових органів можливість
підняти на якісно новий рівень роботу щодо визначення бази
оподатковування регіону, прогнозування й аналізу надходжень до бюджету.
Інтеграція системи, контроль за цілісністю даних значно покращили якість
інформації.

Було запроваджено так звану „систему зведених показників”, яка прийшла
на заміну АІС „Галузь”. Принцип її побудови коротко полягає в
наступному. У картках особових рахунків платників передбачено ведення
операцій. Перша категорія операцій деталізована до рівня елементарних
процедур, вони містять економічний зміст, наприклад операції сплати
кодифіковані за такими критеріями:

– тип (сплата платежу, сплата пені, сплата відсотків за користування
відстрочкою, повернення зайво сплачених сум, відшкодування ПДВ – у
розрізі типів відшкодувань);

– технологічні операції. У картці особового рахунку вони активізують
певні події, як наприклад, сформовано висновок, відкрито справу з
визнання платника банкрутом, підтверджено суму задекларовано ПДВ тощо;

– операції розраховані системою автоматично. Наприклад, нараховано пені,
процентів за користуванням відстроченням і таке інше. Всі ці операції з
певним коефіцієнтом

(+ 1, 0, – 1) впливають на звітний показник, наприклад, операція за
кодом „193. Задекларовано ПДВ до відшкодування” впливає з коефіцієнтом +
1 на показник „Задекларовано ПДВ”, – 1 на показник „Нараховано”, + 1
„Зменшено згідно з декларацією, розрахунку”, 0 – „сплачено до бюджету”,
0 – „повернуто з бюджету”. Інформаційний файл, на відміну від
інформаційного файла системи АІС „Галузь”, який мав структуру „ключ”,
„показник 1”, „показник 2”, ..”показник N” має так звану вертикальну
форму, тобто – „ключ”, „код показника”, „значення показника”.

Перехід до „вертикальної форми” дозволив вирішити такі проблеми:

– відсутність розрідженості даних та економія розміру файла;

– гнучкість системи звітності. При запровадженні нового показника зміни
вносяться лише до довідників, сама структура звітного файла не
змінюється;

– різноманітні звітні форми можна подати також відповідним довідником.

Підвищені вимоги до системи підтримки прийняття рішень змусили зміни
регламент підйому даних з декадного на щоденний. При цьому потрібно було
вирішити такі взаємовиключаючі вимоги – зменшити потік інформації за
рахунок вивантаження змін і ґарантувати ненакопичення похибки за рахунок
втрати одного з пакета змін.

Виконання цих вимог можливе було б лише при застосуванні квитанцій про
отримання та наявності надійної системи контролю отриманих пакетів, що ,
безперечно, ускладнило б систему та збільшило час доставки пакетів. Тому
було розроблено компромісне рішення – є три базових періоди, коли
інформація передається повністю (базовий файл), у межах кожного з
періодів формується файл змін щодо базового періоду. Таким чином, втрата
файла змін у будь-який з днів не накопичує помилку в наступному файлі
змін.

Починаючи з 2002 року нове програмне забезпечення почало проектуватися з
використанням дво- (клієнт-сервер) (рис. 1) або трирівневної
(клієнт-сервер застосувань-сервер баз даних) (рис. 2) архітектури.

Рис. 1. Дворівнева архітектура побудови інформаційної системи

Рис. 2. Трирівнева архітектура побудови інформаційної системи

Підтримка клієнтських місць для дворівневної архітектури вимагає
встановлення спеціальних драйверів баз даних.

Перевагою ж трирівневної над дворівневною архітектурою є спрощене
супроводження клієнтських місць, інший термін – тонкий клієнт [6].

Вибір такої архітектури було обумовлено наступними чинниками:

– сервер баз даних (SQL-сервер) забезпечує цілісність, обробку даних,
протоколювання дій користувачів, розмежування доступу;

– сервер застосувань реалізує основну бізнес-логіку , побудову форм
звітності та вводу;

– клієнт, який забезпечує інтерфейс з користувачем.

Якщо як сервер застосувань використовувати веб-сервер, то клієнт
зводиться до звичайного WEB-браузера (який вкючає в себе будь-яка
сучасна операційна система) і адміністрування такої системи зводиться до
адміністрування сервера. Таке супрводження клієнтських місць отримало
назву „нульове” [1, 2, 3, 4, 5].

Для якісної побудови таких систем було вирішено наступні завдання:

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

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

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

– розроблено корпоративні стандарти стосовно побудови еталонної схеми
довідників як для СКБД „Oracle”, так і для систем, що продовжують
експлуатуватись під СКБД FoxPro.

Такі стандарти було розроблено в 2003 році. У цьому ж році розроблено
документ „Концепція функціонування та розвитку інформаційно-аналітичної
системи органів державної податкової служби України”. Цією концепцією,
зокрема, визначається рекомендована архітектура інформаційних систем
„клієнт-сервер застосувань сервера баз даних”, та пріоритетний напрям
розвитку корпоративної мережі.

За архітектурою „клієнт-сервер застосувань сервера баз даних” розроблено
автоматизовану систему „Реєстри платників податків”. Ця система, на
відміну від попередніх систем, побудована як сховище різноманітних
документів та містить спеціальний процесор, який на підставі певних
атрибутів, визначених документів з урахуванням пріоритетності, формує
поточний зріз облікових даних. Використання сервера баз даних, звичайно,
не тільки покращило якість інформації, а й дає змогу з набагато меншими
зусиллями будувати системи реплікації даних (як онлайнової, так і
оффлайнової).

Досвід використання існуючої бази даних центрального рівня показує, що
великий інтерес функціональних підрозділів обласного та центрального
рівнів ДПС існує до повної інформаційної бази даних районного рівня з
щоденним оновленням.

Ця мета по-різному досягається для систем, побудованих з виділеним
сервером баз даних, та на системах, побудованих з використанням СКБД
FoxPro.

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

Для систем, побудованих із використанням СКБД FoxPro, пропонується така
схема обміну:

1. Створюється словник даних, в якому міститься інформація щодо таблиці,
яка підлягає реплікації, значення її первинного або унікального ключа,
переліку полів, по яких аналізуються зміни.

2. Пакети, що відсилаються, можуть бути 2-х типів – повний або базовий
та пакет змін.

3. При першому запуску системи формується повний пакет даних. Відісланий
пакет зберігається в системі в вигляді архіву та приймає номер № = 0.

4. Система обласного рівня робить спробу повного завантаження цього
файла.

5. При вдалому завантаженні повного файла система робить запит про
надання пакета змін № = 1 щодо пакета № = 0. Зміни розраховуються так. З
архіву видобувається пакет за № = 0. З використанням первинного ключа
вибирають такі записи, які є в пакеті № = 0 і відсутні в базі даних
нині. Такі записи потрапляють до пакета 1 як ті , що повинні бути
видалені з обласної БД. З використанням первинного ключа вибирають такі
записи, які є в базі даних зараз і відсутні в пакеті № = 0. Такі записи
потрапляють до пакета 1 як ті, що повинні бути додані в обласну БД. З
використанням первинного ключа вибираються такі записи, які одночасно є
в базі даних зараз і в пакеті № = 0. Якщо хоч одне з полів поточної бази
даних і пакета № = 0 відрізняються, такий запис потрапляє до пакета, як
той, що повинен бути модифікований. Формується стан бази даних № = 1
районного рівня і архівується (рис. 3).

6. Обласна система обробляє отриманий пакет, тобто виконує операції
видалення, вставки, заміни. При вдалому виконанні цих процедур до
районної бази формується запит щодо формування файла змін поточного
стану баз стосовно попереднього, при невдалому – щодо останнього вдало
завантаженого пакета (рис. 4).

7. Аналогічно, наступні пакети оновлення (п. 5–6).

Рис. 3. Приклад розрахунку пакета файлів змін

Рис. 4. Відновлення стану обласної бази даних при збої завантаження змін

Формат даних щодо обміну даними пропонується використовувати текстовий з
полями фіксованої ширини як такий, що найшвидше завантажується до БД.
Використання інших форматів, наприклад DBF, ХМL, та інше застосовувати
недоцільно, оскільки для такого завантаження потрібно буде розробляти
програмне забезпечення для розбору даних і перетворення їх до форми,
придатної до завантаження в СКБД, при цьому швидкість завантаження
значно знизиться.

Описана вище схема оновлення дозволить щоденно отримувати на обласному
та центральному рівнях актуальну інформацію щодо адміністрування
податків і платежів. Наявність такої інформації дозволить скласти
„портрет” платника податків, вивчати нетипову поведінку деякої категорії
платників, упереджувати порушення податкового законодавства.

Література:

1. Елисеев Владимир. Ладыженский Глеб. Введение в Интранет
(www.jetinfo.ru)

2. Теллин Стивен. – Методология Интранет (www.jetinfo.ru)

3. Теллин Стивен. – Интранет и Адаптивные Инновации: переход от
управления к координации в современных сетях

4. Галатенко Владимир, Трифаленков Илья. – Информационная безопасность в
Интранет: концепции и решения (www.jetinfo.ru)

5. Гагин Александр. – Сервисы Интернет(www.jetinfo.ru)

6. Анни Павел. – Тонкие клиенты (www.jetinfo.ru)

Похожие записи