WWW.REFERATCENTRAL.ORG.UA - Я ТУТ НАВЧАЮСЬ

... відкритий, безкоштовний архів рефератів, курсових, дипломних робіт

ГоловнаБухгалтерський облік, Податки → Проблеми автоматизації бізнес-процесів податкової служби - Реферат

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

звітності;
- забезпечення ведення реєстру податкових вимог;
- забезпечення ведення реєстру податкових повідомлень;
- забезпечення ведення Національного плану документальних перевірок;
- забезпечення ведення справ про банкрутство;
- забезпечення роботи аналітичної системи "Картка боржника";
- забезпечення імпорту сплачених сум з банківських файлів;
- ведення журналу торгових патентів;
- ведення реєстру платників єдиного податку;
- ведення журналу податкових векселів.
Починаючи з 1998 року, в органах ДПС запроваджено комп'ютерну обробку податкової звітності платників, починає також формуватися база даних податкових декларацій. Спочатку система використовується лише для реєстрації документів та внесення сум, що підлягають нарахуванню в КОР, потім і для внесення повного документа.
У серпні 2000 року у промислову експлуатацію впроваджено АІС обласного рівня (далі - АІС ОР), розроблену на основі сучасних технологій. АІС ОР забезпечує комплекснуавтоматизацію функцій підрозділів обласних ДПА з інформацією баз даних регіону, має розвинену систему пошуку та агрегування відібраних даних.
Функціонально АІС ОР розділяється на три блоки:
- підсистема економічного аналізу;
- пошукова підсистема;
- підсистема роботи з карткою платника.
Пошукова підсистема дозволяє виконувати добір платників по більш ніж 300 показниках (реєстраційних, економічних, податкових) і по практично необмеженій кількості їхніх комбінацій.
АІС ОР є базовою для інформаційного забезпечення спеціалізованих інспекцій великих платників податків і організаційно-аналітичних підрозділів по боротьбі із приховуванням неоподаткованих доходів і відмиванням доходів, одержаних незаконним шляхом.
Станом на початок 2004 року загальна кількість запитів до баз даних АІС ОР досягла 2 мільйонів (статистику дозволяє збирати сама система). Система спроектована так, щоб технічно її можна було б використати і на центральному рівні.
Розширення номенклатури інформації Центрального банку даних (ЦБД) за рахунок впровадження АІС ОР, надання користувачам всебічної інформації про стан розрахунків кожного платника з бюджетом у щоденному оперативному режимі, надало фахівцям податкових органів можливість підняти на якісно новий рівень роботу щодо визначення бази оподатковування регіону, прогнозування й аналізу надходжень до бюджету. Інтеграція системи, контроль за цілісністю даних значно покращили якість інформації.
Було запроваджено так звану "систему зведених показників", яка прийшла на заміну АІС "Галузь". Принцип її побудови коротко полягає в наступному. У картках особових рахунків платників передбачено ведення операцій. Перша категорія операцій деталізована до рівня елементарних процедур, вони містять економічний зміст, наприклад операції сплати кодифіковані за такими критеріями:
- тип (сплата платежу, сплата пені, сплата відсотків за користування відстрочкою, повернення зайво сплачених сум, відшкодування ПДВ - у розрізі типів відшкодувань);
- технологічні операції. У картці особового рахунку вони активізують певні події, як наприклад, сформовано висновок, відкрито справу з визнання платника банкрутом, підтверджено суму задекларовано ПДВ тощо;
- операції розраховані системою автоматично. Наприклад, нараховано пені, процентів за користуванням відстроченням і таке інше. Всі ці операції з певним коефіцієнтом
(+ 1, 0, - 1) впливають на звітний показник, наприклад, операція за кодом "193. Задекларовано ПДВ до відшкодування" впливає з коефіцієнтом + 1 на показник "Задекларовано ПДВ", - 1 на показник "Нараховано", + 1 "Зменшено згідно з декларацією, розрахунку", 0 - "сплачено до бюджету", 0 - "повернуто з бюджету". Інформаційний файл, на відміну від інформаційного файла системи АІС "Галузь", який мав структуру "ключ", "показник 1", "показник 2", .."показник N" має так звану вертикальну форму, тобто - "ключ", "код показника", "значення показника".
Перехід до "вертикальної форми" дозволив вирішити такі проблеми:
- відсутність розрідженості даних та економія розміру файла;
- гнучкість системи звітності. При запровадженні нового показника зміни вносяться лише до довідників, сама структура звітного файла не змінюється;
- різноманітні звітні форми можна подати також відповідним довідником.
Підвищені вимоги до системи підтримки прийняття рішень змусили зміни регламент підйому даних з декадного на щоденний. При цьому потрібно було вирішити такі взаємовиключаючі вимоги - зменшити потік інформації за рахунок вивантаження змін і ґарантувати ненакопичення похибки за рахунок втрати одного з пакета змін.
Виконання цих вимог можливе було б лише при застосуванні квитанцій про отримання та наявності надійної системи контролю отриманих пакетів, що , безперечно, ускладнило б систему та збільшило час доставки пакетів. Тому було розроблено компромісне рішення - є три базових періоди, коли інформація передається повністю (базовий файл), у межах кожного з періодів формується файл змін щодо базового періоду. Таким чином, втрата файла змін у будь-який з днів не накопичує помилку в наступному файлі змін.
Починаючи з 2002 року нове програмне забезпечення почало проектуватися з використанням дво- (клієнт-сервер) (рис. 1) або трирівневної (клієнт-сервер застосувань-сервер баз даних) (рис. 2) архітектури.
Рис. 1. Дворівнева архітектура побудови інформаційної системи
Рис. 2. Трирівнева архітектура побудови інформаційної системи
Підтримка клієнтських місць для дворівневної архітектури вимагає встановлення спеціальних драйверів баз даних.
Перевагою ж трирівневної над дворівневною архітектурою є спрощене супроводження клієнтських місць, інший термін - тонкий клієнт [6].
Вибір такої архітектури було обумовлено наступними чинниками:
- сервер баз даних (SQL-сервер) забезпечує цілісність, обробку даних, протоколювання дій користувачів, розмежування доступу;
- сервер
Loading...

 
 

Цікаве