На районному рівні функціонують районні, міські, об'єднані дер­жавні податкові інспекції (усього близько 550 установ). Передбачається зменшення їх кількості шляхом утворення міжрайонних інспекцій (МРДПІ) та офісів великих платників (ОВП). У районах для зручності платників податків залишаться пункти податкового обслуговування Орієнтовно кількість МРДПІ може сягнути 150, тобто близько 15 на одну ОДПА. Основними компонентами інформаційних систем районного рівня є функціональні автоматизовані робочі місця (АРМ), що на даному етапі є перехідною системою у вигляді базового АРМ "TAX" на ос­нові FOXPRO.

Передбачається функціонування на районному рівні клієнт-серверних інформаційних систем, на основі WEB-технологій з доступом до сервера АІС обласного рівня, HTML- форматів даних, TCP/IP/ HTTP-протоколів обміну інформа­цією та з базовим сервером ДПІ (WFoxPro, SQL або Linux). Робочі станції ІС ДПІ виконуватимуть роль "тонкого клієнта", тобто біль­шість обчислень та операцій повинні виконуватись на сервері. Па­ралельно також будуть функціонувати традиційні операційні системи.

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

Вимоги до корпоративної інформаційної системи ДПС України

Враховуючи специфіку даного періоду розвитку інформаційних технологій, інтеграції інформаційних потоків суб'єктів економічної ді­яльності, реформування інфраструктури податкової системи, корпо­ративна інформаційна система державної податкової служби України (ДПС України) повинна відповідати наступним вимогам:

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

- не залежати від апаратних та системних засобів;

- базуватись на міжнародних та промислових стандартах;

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

- забезпечувати простоту та легкість додавання нових компо­нентів в існуючі програми;

- дозволяти інтегрувати старі функціонуючі програми у нові інформаційні системи;

- забезпечувати безпеку, надійність та стійкість до відмов.

Відповідно до цих вимог інформаційна система ДПС України  належить до сучасного типу інформаційних систем підтримки прийняття управлінських рішень і складається із наступних компонентів:

- системи податкового обліку та адміністрування податків;

- системи реєстрації та вводу податкових документів;

- системи оперативного аналізу податкової інформації;

- системи інтелектуального аналізу податкової інформації;

- інформаційно-пошукової системи;

- міжвідомчої системи обміну інформацією;

- системи координації документопотоків.

Компоненти повинні функціонувати у середовищі інтегрованого розподіленого сховища даних (СД), яке повинне інтегрувати в собі довільні масиви даних, зокрема реєстри платників податків, реєстри об'єктів оподаткування тощо.

Основні поняття реінжинірингу технологічних процесів адміністрування податків

На сучасному етапі реформування податкової системи України і модернізації ДПС України особливу увагу необ­хідно приділити перепроектуванню технологічних процесів адміністру­вання податків або реінжинірингу бізнес-процесів.

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

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

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

Для вирішення завдань у сфері управління на обласному та цен­тральному рівнях ДПС України інформаційна система повинна вклю­чати системи оперативного аналізу даних та оперативної звітності. З'являються доступні системи інтелектуального аналізу інформації, які можна інтегрувати з існуючими системами і створювати на їх основі системи підтримки прийняття рішень (СППР).

Система повинна забезпечувати облік, звітність та аналіз на ос­нові функціонально-повного набору адаптивних базових підсистем (компонент):

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

- накопичення, статистичної та аналітичної (інтелектуальна) об­робки даних із визначенням закономірностей процесів, що відбува­ються, та підтримкою прийняття управлінських рішень;

- інтерактивної побудови користувачем складних нестандартних запитів до баз даних з представленням запрошеної інформації у вигляді графіків, таблиць або гістограм;

- повної інтеграції з офісним програмним забезпеченням (MS Office-Excel, Word, Explorer).

Основні поняття створення баз даних

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

База даних (БД) - сукупність організованих з визначеною ціллю даних, між якими існують відношення. Структура БД полегшує доступ до даних, що відносяться до деякого об'єкта, на­приклад, "платник податку" і "види платежів".

Реляційна база даних (РБД) - тип БД, основою яких є реляційні моделі; нереляційні моделі, основою яких є ієрархічні, сіткові, об'єктно-орієнтовані та багатовимірні моделі.

СУБД - програмний комплекс, що забезпечує функці­онування бази даних.

Об'єктно-орієнтовані СУБД (ООСУБД). Внутрішня структура об'єктно-орієнтованих СУБД, як правило, складається із трьох різ­новидів об'єктів: контейнерів даних, індексаторів і перетворювачів.

Реляційна модель має дві основних властивості:

- базові порції даних являють собою відношення (Relation);

- операції над таблицями проводяться тільки над відношеннями.

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

Рис. Основні три типи відношень: а) один до одного, в) один до багатьох, с) багато до багатьох

Відношення - це математичне поняття, що описує, як відносяться між собою  елементи двох множин даних.

Реляційна модель передбачає організацію даних виключно у вигляді таблиць, тобто таблиця - базовий мовний об'єкт реляційної моделі.

Таблиця - це множина іменованих атрибутів, або стовпчиків, та множина записів (кортежів), або рядків. Дуже часто стовпчик називається полем таблиці. Перетин рядка і стовпчика утворює комірки таблиці. Набір допустимих значень стовпчика - характеризується визначеним типом даних, наприклад, сим­вольним або цілим тощо.

Реляційна модель ставить до таблиці наступні вимоги:

1. Дані в комірках таблиці повинні бути структурно неподільними.

2. Дані одного стовпчика повинні бути одного типу.

3. Кожний стовпчик повинен бути унікальним.

4. Стовпчики розміщуються у довільному порядку.

5. Рядки (записи) також розміщуються у довільному порядку.

6. Стовпчики мають унікальні імена.

7. Не може бути однакових первинних ключів, тобто всі рядки повинні бути унікальними.

8. Повинна дотримуватись посилкова цілісність для зовнішніх ключів.

Якість функціонування СУБД оцінюється рівнем забезпечення технології паралельної обробки даних. Наприклад, коли один ко­ристувач змінює фрагмент даних у той час, коли користувач про­глядає їх або також змінює. У даному випадку СУБД повинна ство­рити декілька копій даного фрагмента даних, узгодити всі внесені в копії зміни і в результаті внести в БД один відкоригований варіант, що задовольняє всіх користувачів операції.  Забезпечення паралельного доступу і збереження цілісності - дві тісно пов'язані між собою функції СУБД. В основі механізму реалі­зації цих функцій лежить поняття трансакції. Коли користувач проглядає дані або змінює їх, він стосовно БД виконує трансакцію. Транзакція - елементарна неперервна операція в механізмі паралельного доступу й у функціонуванні СУБД у цілому. СУБД організовує поновлення даних у БД, використовуючи трансакції в якості логічних одиниць роботи.

Основи адміністрування ресурсами корпоративної мережі ДПС України

В корпоративній мережі ДПС використовується семирівнева модель взаємодії відкритих систем OSI. Кожен рівень моделі являє собою службу для попе­реднього та наступного рівнів. Взаємодія між вузлами мережі може проходити за рівнями, при­чому кожен рівень одного вузла взаємодіє з відповідним рівнем іншого.

Фізичний рівень. На даному рівні проходять фізичні процеси передачі бітів за ка­бельною системою і використовується наступне мережне обладнання: кабелі, роз'єднувачі, мережні контролери.

Канальний рівень. Відповідно до специфікації IEEE канальний рівень поділяється на два підрівні - управління доступом до середовища передавання МАС і управління логічним каналом LLC. На канальному рівні працюють утиліти виявлення помилок у кадрах, що циркулюють між пристроями на фізичному рівні. Окремі біти перетворюються в кадри даних специфічного формату, що зрозумілий для протоколів наступного рівня.

Мережний рівень. На даному рівні формуються взаємозв'язки між вузлами мережі, встановлюються і обриваються з'єднання, підтримуються наступні служби:

- обмін логічними і фізичними адресами пристроїв;

- маршрутизація і комутація зв'язків;

- управління мережним трафіком.

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

Транспортний рівень. Даний рівень відповідає за наступні служби:

1. Безпомилкове передавання даних. Дані у великих пакетах сегментуються для підвищення ефективності передавання.

2. Підготовку і коректне передавання даних на верхній рівень OSI.

3. Повідомлення станції, що передає або приймає інформацію
про успішне або неуспішне виконання операцій.

4. Управління потоками даних на рівні транспортних протоколів.

Рівень сеансів. Для підтримки обміну даними між застосуваннями, запущеними на різних ПЕОМ, необхідно ідентифікувати їх приналежність одному сеансу роботи. Програми управління сеансами визначають порядок обміну даними між стан­ціями і підтримують взаємодію на рівні окремих застосувань. На рівні сеансів відбувається запуск, підтримка і закриття програм на відда­лених ПЕОМ.

Рівень представлення даних. На даному рівні визначаються формати даних, наприклад ASCI І, EBCIDIC. Виконується перетворення форматів, кодування, стиснення і розархівування даних. Даний рівень відповідає за направлення користувацького запиту на сервер і повернення звіту користувачу.

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

Основи адміністрування Windows NT/2000

Windows NT/2000 підтримує доменну організацію обчислюваль­ної мережі.

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

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

Додатковий сервер довіряє перевірку правомірності користувача контролеру домену та надає користувачам свої ресурси у межах їх допусків.

При наявності у мережі кількох доменів Windows NT Server до­зволяє організувати між ними кілька моделей взаємодії. Така взаємодія може бути реалізована завдяки можливості встановлення між доме­нами довірчих відносин та реалізації концепції глобальних груп. Таким чином, користувачі, що зареє­струвалися у домені, якому довіряють, отримують доступ до ресурсів домену, який довіряє.

Модель з одним головним доменом передбачає наявність одного головного домену, в якому створюються бюджети користувачів, що включаються до глобальних груп для отримання допусків до ресурсів інших доменів, які довіряють головному домену. Таким чином, бюд­жети користувачів та глобальних груп адмініструються в головному домені, а бюджети локальних груп та допуски до ресурсів адміністру­ються в доменах, що довіряють свої ресурси.

Модель з кількома головними доменами відрізняється наявністю кількох головних доменів, яким довіряють інші домени.

Мережні протоколи WindowsNT4.0. Windows NT має три транспортних драйвери: ТСР/ІР, NWLink та NBF, що відповідають транспортним протоколам ТСР/ІР, IPX/SPX та NetBEUI (NetBIOS). Кожен з цих протоколів має свої особливості, що визначають галузі їх застосування.

NetBEUI -протокол використовується для встановлен­ня мережевих з'єднань з платформами на базі DOS, MS Windows, OS/2.  

IPX/SPX- протокол використовується для встановлення мережних з'єднань з Novell NetWare.

ТСР/ІР - протокол може бути використаний для встановлення ме­режних з'єднань з платформами на базі практично будь-яких операційних систем. Протокол має досить складне конфігурування та вико­ристовує ієрархічну систему імен та IP-адрес. Повна підтримка між-мережної маршрутизації дозволяє створювати дуже великі мережі. Даний протокол слід використовувати для встановлення мережних з'єднань з UNIX, роботи з Internet/Intranet та у великих розділених на підмережі мережах.

Протокол TCP - один з двох основних протоколів комплекту ТСР/ІР. Він забезпечує надійну роботу служби гарантованої доставки. TCP сприймає дані швидше як потік байтів, а не як набір кадрів. Дані передаються у сегментах.

Термін гарантована доставка означає, що для кожного отрима­ного сегмента даних отримувач повинен повідомити через визначений період відправника про отримання даних. Якщо підтвердження не отримано, то дані передаються повторно. Якщо отриманий сегмент пошкоджений, приймаючий комп'ютер його ігнорує і повідомлення не висилає. У цьому випадку відправник повторно передає сегмент. Цілісність даних зберігається завдяки призначенню порядкового но­мера та контрольної суми для кожного сегмента.

Протокол ІР - протокол негарантованої доставки, який не по­требує логічного з'єднання. Пакет може бути загубленим, продубльо­ваним або затриманим. Протокол ІР виконує такі функції:

- забезпечує маршрутизацію інформації;

- забезпечує механізм розбирання/збирання пакетів та правила маршрутизації.

ІР-адреса собою єдине значення, але включає в себе два інформаційні елементи:

• адресу мережі - ідентифікує групу комп'ютерів або інших пристроїв, розташованих в одній логічній мережі;

• адресу хост-комп'ютера - ідентифікує комп'ютер у межах конкретної адреси мережі.

Мережні адреси повинні відповідати наступним вимогам:

1. Мережна адреса повинна бути унікальною.

2. Адреса мережі не може починатися з номера 127 (цей номер зарезервовано).

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

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

5. Адреса хост-комп'ютера повинна бути унікальною для мережі.

Корпоративна телекомунікаційна мережа ДПС України

Корпоративна телекомунікаційна мережа призначена для ство­рення єдиного інформаційного середовища державної податкової служби України. Мультисервісна корпоративна телекомунікаційна мережа ДПС України створюється для надання доступу до баз даних ДПС України, Інтранет-ресурсів ДПС України, що включають FTP та Web-сервіси, сервіси новин тощо, та Інтернет податковим органам усіх рів­нів, створення загальної системи телефонного зв'язку ДПС України, забезпечення проведення відеоконференцій.

Основним протоколом передачі даних у корпоративній телеко­мунікаційній мережі є протокол ТСР/ІР, що використовує загальний корпоративний простір IP-адрес. Корпоративна телекомунікаційна мережа ДПС України є IP-мережею, що складається з підмереж обласного рівня, які, в свою чергу, складаються з підмереж районного рівня. Передача даних між підмережами забезпе­чується маршрутизуючим обладнанням.

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

Обласний сегмент корпоративної телекомунікаційної мережі об'єднує ДПА обласного рівня, ДПІ в районах великих міст, ДПІ по роботі з великими платниками податків, управління податкової міліції. Мережа створюється за розподіленою топологією з організацією за допомогою резервних каналів доступу.

При включенні в корпоративну телекомунікаційну мережу ДПІ в районах великих міст, ДПІ по роботі з великими платниками по­датків, управлінь податкової міліції обласної ДПА мають використовуватись наступні технології в порядку зменшення пріоритетності:

- канали зв'язку на базі крученої пари та волоконно-оптичні  канали зв'язку при незначних відстанях;

- канали зв'язку на основі орендованих некомутованих з'єднань з використанням xDSL технологій передачі даних;

- radioEthernet.

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

Для включення у корпоративну телекомунікаційну мережу мо­більних користувачів використовуються комутовані канали зв'язку, для чого у відповідних податкових органах організовуються модемні пули. Для мобільних користувачів податкової міліції за неможливості використання комутованих каналів забезпечується мобільний доступ через Інтернет з використанням технологій 3G, GPRS, WAP.

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

Основним активним обладнанням корпоративної телекомуніка­ційної мережі є маршрутизатори, що забезпечують взаємодію локаль­них обчислювальних мереж у корпоративній мережі ДПС України. Маршрутизатори мають підтримувати протоколи обміну мультиме­дійних застосувань, комутацію пакетів за технологією FrameRelay, за­безпечувати передачу голосу FrameRelay (VoFR). Маршрутизатори мають підтримувати розмежування доступу за допомогою листів доступу та аутентифікацію і авторизацію корис­тувачів.

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

Організаційні питання розмежування доступу в інформаційній системі ДПС України

Відповідно до Закону України "Про захист інформації в автома­тизованих системах" право власності на інформацію, створену в процесі обробки у підрозділах ДПА України, належить власнику автомати­зованої системи (АС), який здійснив цю обробку, тобто Державній по­датковій адміністрації України. Доступ до інформації, яка обробляється, зберігається та розповсюджується в ДПА України, здійснюється згідно з Положенням про електронну інформацію в Державній податковій адміністрації. Положенням про електронну інформацію передбачено розподіл конфіденційної інформації та доступ до неї користувачів:

- інформація категорії А готується і використовується будь-яким працівником податкової адміністрації;

- інформація категорії Б готується та обробляється працівником податкової адміністрації за розпорядженням керівництва чи згідно з функціональними обов'язками працівників;

- інформація категорії В готується, обробляється та використо­вується виключно персоналом, який має спеціальний дозвіл.

Технічні засоби з розмежування доступу до інформації входять у систему захисту інформації (СЗГ) від несанкціонованого доступу (НСД). Розмежування доступу користувачів до інформації повинно забез­печуватись такими функціями засобів захисту інформації від НСД, як ідентифікація та аутентифікація користувачів, а також розмежуванням доступу користувачів до ресурсів ПЕОМ чи мережі, а їх контроль - автоматичним веденням системного журналу.

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

Розмежування доступу повинне забезпечувати управління досту­пом поіменованих суб'єктів (користувачі, процеси і т. ін.) до поіменованих об'єктів АС (томи, директорії, файли, сервери, принтери та ін.), тобто забезпечувати дозвіл у разі, якщо такі права є, і заборону доступу, якщо такі права відсутні.

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

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

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

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

Враховуючи, що більша частина інформаційних ресурсів ДПС України носить конфіденційний характер, для користувачів інфор­маційної системи є необхідним знання та уміння правильно виділяти власні ресурси для загального використання в мережі, тобто проводити адміністрування власних інформаційних ресурсів, використовуючи можливості серверних програмних засобів. В інформаційній системі ДПС України на сьогодні основними серверними продуктами є UNTX, OS/2, Windows NT4, Windows 2000.

Основні типи застосувань, пов'язаних із базами даних

Застосування даного типу використовуються з розвиненими засо­бами маніпулювання даними (мова SQL, SQL +). Їх робота пов'язана з інтенсивним потоком транзакцій, що виконують, в основному, по­новлення даних, рідше - вставки або видалення. Велике значення для систем типу OLTP має паралелізм доступу до даних, тобто одночасний доступ великої кількості користувачів до БД. Більша частина засто­сувань, що функціонують у підрозділах податкової служби, є засто­суваннями типу OLTP.

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

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

Пакетні системи розраховані на оперативну взаємодію з користу­вачем, але можуть працювати і в автоматичному режимі при мінімаль­ному втручанні оператора. Як правило, вони підтримують розвинеш мови маніпулювання даними, але погано справляються із задачами паралельного доступу. Класичним прикладом є продукційні й опе­раційні БД.

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

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

Центральне сховище даних дозволить задовольнити усі інформаційні потреби підсистем економічного аналізу та підтримки прийняті | рішень в адмініструванні податків за рахунок підтримки в ньому акту­альних даних.

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

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

ОБД ДПІ - оперативні БД державних податкових інспекцій.

СД ДПА - сховища даних ДПА в областях.

СД ДПА України - сховище даних ДПА України.

Сруктура та концепція СУБД ORACLE

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

Кожна БД Oracle має пов'язаний із нею екземпляр, причому доти, доки не будуть використовуватися опції Oracle Parallel Server, БД фор­мує тільки один екземпляр. Організація екземпляра дозволяє СУБД обслуговувати множину типів транзакцій, що ініціюються одночасно великою кількістю користувачів, і в той же час забезпечують високу продуктивність, цілісність даних та безпеку.

Користувацький процес:

- виконується на клієнтській машині;

- запускається при запуску інструментального засобу (SQL Plus, Server Manager) або застосування (наприклад, АІС "Галузь");

- виконує інструментальний засіб або застосування;

- вміщує програмний інтерфейс користувача (UPI);

- створює запити до сервера Oracle.

Серверний процес:

- виконується на серверній машині;

-обслуговує єдиний користувацький процес;

- оброблює запити, створені користувачем;

- повертає результати клієнту.

Кожний процес має окремий блок пам'яті, у якому зберігаються локальні змінні, стек адрес та інша поточна інформація. Усі процеси використовують разподільчу область пам'яті, у якій зберігаються дані спільного користування. Доступ до цієї секції пам'яті як для запису, так і для читання можуть одержати одночасно різні процеси і програми. Цей блок пам'яті називається глобальною системною областю (ГСО).Оскільки ГСО знаходиться у розподільчому сегменті пам'яті, його часто називають розподільчою глобальною областю.

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

Формування екземпляра. Відкриття БД Oracle включає три стадії:

- формування екземпляра Oracle (передустановча стадія);

- встановлення бази даних екземпляром (установча стадія);

-  відкриття БД (стадія відкриття).

Екземпляр Oracle формується на передустановчій стадії запуску системи. На цій стадії читається файл параметрів init.ora, запускаються фонові процеси та ініціалізується ГСО. Цей файл визначає параметри конфігурації екземпляра, зокрема розмір структур пам'яті, кількість і тип фонових процесів. Така стадія нази­вається установчою.

У ГСО зберігаються структури пам'яті, необхідні для маніпулю­вання даними, аналізу пропозицій SQL і кешування транзакцій. Це розподільча область, тобто до неї одночасно має доступ багато про­цесів, що можуть читати дані з неї або модифікувати їх. Усі операції над БД так чи інакше використовують інформацію, що знаходиться у ГСО. Як уже зазначалося, ГСО виділяється відразу ж після створення екземпляра ще на передустановчій стадії. Звільняється ця область тільки після повного вимикання екземпляра.

ГСО складається з таких компонентів:

- розподільчого пула;

- кеш-буфера даних;

- буфера журналу транзакцій;

- структури сервера багатозадачного середовища.

Розподільчий пул містить кеш-бібліотеки, кеш-словника і керу­ючі структури сервера. Кеш-бібліотеки зберігає текст, формати лексичного аналізатора і план вико­нання пропозицій SQL, що адресуються СУБД. Крім того, тут утриму­ються заголовки пакетів і процедур, що виконувалися раніше. Кеш-словника зберігає рядки словника даних, що були використані для лексичного аналізу операторів SQL. Кеш-словника містить інформацію зі словника даних, що необхідна СУБД для лексичного аналізу SQL-виразу. У цій області утримується інформація, що стосується сегментування, привілеїв доступу і розміру вільної пам'яті.

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

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

У процесі роботи СУБД Oracle переглядає тисячі і мільйони запи­сів у таблицях даних, відповідає на сотні запитів користувачів, одно­часно виконує складне опрацювання даних, і усе це - із максимально високою продуктивністю і надійністю. Для того, щоб це було мож­ливо, уся робота розподіляється між програмами, що працюють неза­лежно одна від одної, причому у кожної з них специфічна роль. У су­купності ці програми називаються фоновими процесами Oracle. На серверах Windows NT фонові процеси реалізуються у вигляді множини потоків до сервісів Oracle. Це дозволяє процесам більш ефективно використовувати адресний простір пам'яті спільного користування.

Користувачі бази даних можуть встановлювати з'єднання з сервером ORACLE одним із наступних способів:

- входу у систему через базову машину (сервер);

- з використанням дворівневого (клієнт-сервер) з'єднання, коли клієнтська машина безпосередньо має доступ до сервера;

- за допомогою трирівневого з'єднання, коли машина користувача з'єднується з сервером застосувань, який, у свою чергу, з'єднаний із сервером ORACLE.

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

Системні об'єкти мають відношення до внутрішніх функцій керу­вання системою. Вони формуються і налагоджуються адміністратором БД на сервері й безпосередньо не можуть бути доступними корис­тувачу.  У число системних об'єктів входять:

- файл (файли) параметрів ініціалізації;

- контрольний файл;

- оперативні файли журналів реєстрації трансакцій;

- архівні файли журналів трансакцій;

- файл (файли) трасировки;

- ідентифікатор запису;

- блоки Oracle.

Файл параметрів ініціалізації init.ora - це найперший засіб настро­ювання СУБД Oracle. У ньому немає нічого, крім списку параметрів і ключів настроювання, кожний з яких пов'язаний із визначеною функ­цією системи або компонентом бази даних. Файл init.ora являє собою звичайний текстовий ASCII-файл, що розміщується на сервері UNIX або на сервері Windows NT. Файл init.ora зчитується під час запуску БД, формуванні екзем­пляра Oracle і зчитуванні контрольних файлів. Значення параметрів, що задані в init. ora, визначають характеристики бази даних і формо­ваного екземпляра Oracle - параметри розподілу пам'яті для розпо­дільчого пула, кеш-буфера, буфера журналу трансакцій, характерис­тики фонових процесів, читає контрольні файли, сегменти відкату і т. п. Зміни вмісту файла init.ora сприймаються тільки після повтор­ного запуску системи.

Характеристика АІС ДПА України, що функціонують на платформі ORACLE

АІС "ГАЛУЗЬ" обласного та центрального рівнів.

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

Сфера застосування АІС "Галузь":

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

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

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

Процес роботи автоматизованої системи поєднує три рівні:

- районний;

- обласний;

- центральний.

На районному рівні система приймає дані від АРМ "Облік платежів і податків ("TAX") у вигляді dbf-файлів, здійснює процес зведення для подальшої аналітичної обробки на обласному рівні. Після перелічених операцій зведені дані у dbf-файлі за допомогою електронної пошти надсилаються до області.

На обласному рівні отримані з районів дані завантажуються у базу даних Oracle, після чого дані підлягають зведенню, яке складається з двох етапів:

- зведення у розрізі районів, виду бюджету, органів управління та галузей народного господарства;

- зведення у розрізі районів, виду бюджету з урахуванням ієрархії галузей.

Після зведення отримуються звіти, які порівнюються з офіційними даними (виписка з банку). Дані, які не задовольняють перевірці, пере­силаються на виправлення у відповідні райони.

Після отримання правильних даних з кожного району здійсню­ється процес пересилання до ДПА України за допомогою експортних структур Oracle та електронної пошти або прямим зв'язком із сервером бази даних ДПА України.

На центральному рівні здійснюється робота щодо зведення даних та їх аналітична обробка за допомогою отриманих звітів (див. рис. 5.12).

Склад функцій АІС "Галузь":

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

- аналіз пільг у різних аспектах;

- аналіз контрольної роботи;

- щоденний аналіз надходжень податку на додану вартість;

- аналіз кількості платників у різних розрізах;

- адміністрування форм звітів.

Принципи функціонування:

- інтеграція з існуючими АРМ районного рівня;

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

- вирішення питань системної узгодженості даних на рівні області з отриманням консолідованих даних на рівні області;

- формування обласних зведень для передавання у центральну БД, а також можливість доступу центральної системи до обласних баз;

- застосування параметризованих, об'єктних засобів для ство­рення звітів.

Зважаючи на принципову нестабільність предметного середовища ДПА, викликану неусталеною законодавчою базою, а також незавершеним процесом організації податкових служб, для створення АІС "Галузь" була вибрана технологія АsВаsе, що використовує тільки уніфіковане програмне забезпечення, яке не змінюється при зміні у постановці задач.

Автоматизована інформаційна система обласного рівня (АІС ОР).

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

Завдання критеріїв пошуку виконується шляхом встановлення умов для конкретних полів. Множина критеріїв складається з:

1. Реєстраційних даних

- код ЄДРПОУ;

- назва;

- код ДПІ;

- основна ДПІ;

- дата реєстрації в ДПІ;

- дата реєстрації в держадміністрації;

- сума статутного фонду;

- код форми власності;

- підпорядкування;

- стан платника;

- дата зняття з обліку;

- посадові особи.

2. Дані посадових осіб підприємства:

- код ДРФО;

- прізвище;

- № телефону;

- дані засновників.

3. Коди засновників:

- назва;

- № телефону;

- сума внеску;

- код валюти;

- банківські дані.

4. Банківські дані платника податків надані установами банків області:

- МФО банку;

- № рахунка;

- код валюти;

- дата відкриття рахунка;

- стан рахунка;

- кількість рахунків.

5. Видів діяльності платника:

- код виду діяльності;

- ознака ЗЕД.

6. Розрахунків з бюджетом6

- дата платежу;

- шифр звітності;

- сальдо на початок року;

- нараховано;

- сплачено (всього);

- сплачено грошовими коштами;

- векселі;

- казначейський вексель;

- взаємозалік;

- недоїмка;

- переплата;

- фін. санкцій на поч. року;

- нараховано фін. санкцій;

- сплачено фін. санкцій;

- залишок несплачених фін. санкцій;

- пеня на початок року;

- нараховано пені;

- сплачено пені;

- залишок несплаченої пені;

- вид діяльності.

7. Економічних показників

- дата;

- коефіцієнт покриття;

- коефіцієнт загальної ліквідності;

- коефіцієнт абсолютної ліквідності;

- коефіцієнт обіговості оборотних коштів;

- коефіцієнт забезпеченості власними оборотними коштами;

- коефіцієнт оборотності дебіторської заборгованості;

- коефіцієнт оборотності кредиторської заборгованості;

- коефіцієнт фінансової незалежності (автономії);

- коефіцієнт фінансової стабільності.

8. Митниць (експорт):

- назва отримувача;

- адреса отримувача;

- код товару;

- код ЄДРПОУ банку-контрактоутримувача;

- код валюти;

- курс валюти;

- фактична вартість;

- фактурна вартість;

- код митниці;

- дата дозволу;

- код характеру угоди.

9. Митниць (імпорт):

- назва відправника;

- код товару;

- код ЄДРПОУ банку-контрактоутримувача;

- код валюти;

- курс валюти;

- фактична вартість;

- фактурна вартість;

- код митниці;

- дата дозволу;

- код характеру угоди;

- код преференції за митом;

- код преференції за акцизом;

- код преференції за ПДВ.

10. Оборотів на рахунках

- дата платежу;

- МФО банку;

- № рахунка;

- сума платежу;

- код валюти.

11. Проведених перевірок

- дата перевірки;

- код інспекції;

- код типу перевірки;

- підстава перевірки;

- вид платежу;

- підрозділ, що провів донарахування;

- нараховано до держбюджету;

- нараховано до фонду МТБ;

- нараховано адмінштрафів.

Умови пошуку. Будь-який запит у пошуковій системі задається за допомогою умов, які накладаються на параметри пошуку. Для того, щоб запис про платника було вибрано, він повинен задовольняти всім вказаним умовам. З кількох умов, якщо вони встановлені для одного параметра, повинна виконуватись хоча б одна. При визначенні критеріїв пошуку "%"   означає будь-яку послідовність символів (навіть пропуски); "_" означає будь-який одиничний символ.

Поля вводу пошукової системи можна поділити на 2 типи: поля, що допускають введення лише одного рядка даних, які зустрічаються лише при накладанні умови "у межах від... до..."; поля, що допускають введення списку рядків.

Журнал запитів АІС ОР. Призначення журналу запитів полягає у фіксуванні запитів ко­ристувачів до сервера БД, запису службової інформації про час ви­конання запиту та кількість повернутих клієнту рядків. Також журнал дозволяє користувачу переглядати свої запити у хронологічному порядку за останні 2 місяці. При натисканні на запит він відобразиться у вікні побудови запиту. Журнал запитів відображається у лівій частині вікна браузера.

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

Програмний комплекс «Картка платника»

«Картка платника» є реалізацією інтегрованого відображення облікових даних платника, даних про розрахунки з бюджетом, декларацій тощо. Вона є логічним продовженням роботи з Інформаційно-пошуковою системою та підсистемою «Економічного аналізу» і викли­кається при необхідності детального аналізу стану платника та його платіжної дисципліни.

При ініціалізації картки вона виглядає так: ліва частина вікна - це згорнута папка Картка платника, а права - перелік наявних карток (код платника та його назва). Надалі права частина вікна вико­ристовуватиметься для відображення вихідних форм (згідно з вибором користувача), а ліва - служитиме панеллю - "навігатором".

Картка платника складається з таких розділів:

- реєстраційні дані;

- основні реєстраційні дані платника;

- адресні дані платника;

- види економічної діяльності;

- засновники, інвестори;

- керівники;

- особові рахунки платника;

- реєстри;

- об'єкти;

- відокремлені підрозділи;

- банківські рахунки;

- реєстр банківських рахунків;

- банківські рахунки (за даними ДПІ);

- банківські рахунки (за даними банків);

- постанова 587;

- дані управління статистики;

- реєстр підприємств та організацій;

- види економічної діяльності;

- засновники, інвестори;

- вантажно-митні декларації;

- експорт;

- імпорт;

- пільги;

- бухгалтерська звітність;

- баланс підприємства;

- звіт про фінансові результати;

- звіт про фінансово-майновий стан;

- декларації;

- аналітичні показники (ПДВ);

- аналітичні показники (прибуток);

- порівняльний аналіз декларацій на прибуток і ПДВ;

- розрахунки з бюджетом за податками;

- економічні показники;

- економічні коефіцієнти;

- основні засоби;

- оцінка капіталу;

- зміни майнового стану;

- характеристика оборотних засобів;

- характеристика дебіторської та кредиторської заборгованості;

- грошові кошти;

- аналіз рівня рентабельності;

- аналіз фінансових результатів;

- елементи операційних витрат;

- аудит (планові перевірки);

- інформація про проведені перевірки;

- інформація про донараховані суми;

- інформація про сплачені суми;

- касові апарати та торгові об'єкти;

- інформація про торгові об'єкти;

- інформація про касові апарати;

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

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

Підсистема «Економічний аналіз».  Підсистема призначена для:

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

- аналізу розрахунків з бюджетом у розрізі платників та податків.

Вигляд головного меню підсистеми «Еко­номічний аналіз»:

Отримання кожного звіту починається із введення параметрів запиту, яке забезпечує універсальна форма, зображена на малюнку. Для формування запитів з економічного аналізу необхідно вибрати такі параметри:

- Дата;

- Вид бюджету;

- Тип даних;

- Тип звіту;

- Район;

- Форму власності;

- Організаційно-правову форма;

- Показник для вибору даних (нараховано, сплачено, недоїмка, переплата, фінансові санкції тощо)

- Податок;

- Галузь.

Підсистема «Економічний аналіз» дозволяє формувати такі звіти:

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

- у розрізі податків;

- у розрізі податків та видів бюджетів;

- у розрізі галузей;

- у розрізі форм власності;

- у розрізі організаційно-правових форм;

- у розрізі платників;

- у розрізі платників та податків;

- у розрізі районів ;

- у розрізі банків.

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

Основна

1. Автоматизація роботи в органах державної податкової служби: Підручник/ За заг. ред. В.М. Росоловського, С.П. Ріппи. - Ірпінь: АДПСУ, 2002. - 401 с.

2. Єрьоміна Н.В. Проектування баз даних. Навчальний посібник. – К.: КНЕУ, 1998. - 208 с.

3. Дубчак Л.В., Іванова Л.І., Свириденко В.Ю. Інформаційні системи і технології у фінансах. - Ірпінь: НУДПСУ, 2008. - 194 с

4. Зацеркляний М.М., Мельников О.Ф. Інформаційні системи і технології у фінансово-кредитних установах: Навч. посібник. - Київ: Вид. дім "Професіонал", 2007. - 432 с.

5. Іванюта П.В. Управлінські інформаційні системи в аналізі та аудиті: Навч. посібн. - Київ: ЦУЛ, 2007. - 180 с.

6. Інформаційні системи і технології в економіці. Посібник. / За ред. Пономаренка В.С. – К.: «Академія», 2002, 542 с.

7. Калберг Конрад. Бизнес-анализ с помощью MS Excel, 2-е издание. : Пер. с англ.-М.: Издательский дом «Вильямс», 2003. – 448 с.

8. Лук’янова В.В. Комп’ютерний аналіз даних. Посібник. К.: Видавничий центр «Академія», 2003. – 341 с.

9. Мамченко С.Д., Одинець В.А. Економічна інформатика. Практикум: Навчальний посібник. – К.: Знання, 2008. – 710 с.

10. Марченко Д.М., Яровенко Г.М. Автоматизовані інформаційні системи управління - ресурс підвищення ефективності внутрішнього контролю підприємства// Актуальні проблеми економіки, 2006.- 10(64). - С.150-158

11. Методична розробка "Основні поняття теорії баз даних як основної компоненти інформаційних систем" з курсу "Інформаційні системи в адмініструванні податків" та "Автоматизація роботи в органах ДПСУ". - Ірпінь: НАДПСУ, 2004. - 81 с.

12. Методичні вказівки до практичних і самостійних робіт з курсу "Інформаційні системи та технології під-ств" для підготовки бакалаврів за напр. "Економіка і під-цтво" спец-сті 6.050100 "Економіка п-ства"/ Уклад. Л.В. Дубчак. - Ірпінь: НАДПСУ, 2007. - 74 с.

13. Оксанич А.П., Петренко В.Р., Костенко О.П. Інформаційні системи і технології маркетингу.: Навч. посібник. - Київ: Вид. дім "Професіонал", 2008. - 320 с.

14. Олійник А.В., Шацька В.М. Інформаційні системи і технології у фінансових установах: Навч. посібник. - Львів: "Новий Світ-2000", 2006. - 436 с.

15. Петренко В.Р., Кротюк І.Г., Костенко О.П. Інформаційні системи і технології маркетингу. Лабораторний практикум.: Лабораторний практикум. - Київ: Вид. дім "Професіонал", 2008. - 464 с.

16. Піхоцький В.Ф., Яцишин Ю.В. Інформаційні системи у податковому контролі й аудиті: Навч. посібник. - Ірпінь: АДПСУ, 2004. - 70 с.

17. Свириденко В.Ю. Інформаційні системи фінансових установ: Навч. посібник. - Ірпінь: НАДПСУ, 2006. - 80 с.

18. Семенов М.И., Трубилин И.Т., Лойко В.И., Барановская Т.П. Автоматизированные информационные технологии в экономике. – М.: «Финансы и статистика», 2000. – 416 с.

19. Сиротинська А.П., Лазаришина І.Д. Інформаційні системи підприємств малого бізнесу: Навч. пос. - Київ: ЦУЛ, 2008. - 544 c.

20. Устинова Г.М. Информационные системы менеджмента: Основные аналитические технологии в поддержке принятия решений / Учеб. Пособие. – СПб: Издательство «ДиаСофтЮП», 2000. – 368 с.

21. Филимонова Є.В. Практическая работа в 1С: Предприятие 7.7. Учеб. пособие. Изд. 2-е доп. И перераб. – Ростов н/Д: Издательство "Феникс", 2004 – 416с.

22. Хотинская Г.И. Информационные технологии управления: Учебное пособие. – М.: Издательство «Дело и Сервис», 2003. – 128 с.

23. 1С: Предприятие 7.7. Конфигурация "Бухгалтерский учет для Украины". Руководство по ведению учета (описание конфигурации). Фирма "1С". М., 2001.

    Додаткова

    1. 1С: Предприятие 7.7. Руководство пользователя. Фирма "1С". М., 1999.

    2. Алексеенко В. и др. Конфигурация: "ABBYY Ukraine". / Методические материалы: фирма "1С", 2001. – 648 с.

    3. ІАЦ «ЛІГА» /  http://www.liga.net/

    4. Інформаційно-аналітична система «1С:Предприятие 7.7» / www.1c.ru.

    5. Інформаційно-аналітична система «Парус» / www.parus.ru.

    6. Корпоративна інформаційно-аналітична система «Галактика» www.galaktika.ru.

    7. Система анализа "Форт: Аналитик 3.0" / www.1c.ru.

    8. Чистов Д.В., Таранов А.В. и др. Хозяйственные операции в компьютерной бухгалтерии 7.7. для Украины. Фирма "1С". М., 2002. - 520 с.

З повагою ІЦ “KURSOVIKS”!