Розділ 3. Застосування інформаційних систем управління ЗЕД на підприємствах

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

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

Структура таблиць, що копіюються в директорії місяців, несе в собі багато зайвої інформації, яка тільки займає місце на диску. АРМ підготовки звітності "Фінансова звітність" для своєї роботи потребує встановлення на ПЕОМ пакета Microsoft Office, зокрема програми з цього пакета Excel. Програма Excel дуже вимоглива до апаратного забезпечення. До того ж макромова, за допомогою якої створений АРМ "Фінансова звітність" (VBA for Excel), унаслідок технічних особливостей працює набагато повільніше, ніж програми, написані традиційними мовами. Таким чином, на не дуже сучасних ПЕОМ деякі ресурсномісткі операції, наприклад формування великої (10-15 аркушів) зведеної форми звітності діяльності 10-30 підприємств, можуть зайняти близько двох годин, що неприпустимо повільно.

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

Частково проблеми перевірки введених даних вирішуються за допомогою принципу "ув'язування" даних. Але, на жаль, не всі дані підлягають таким залежностям.

Отже, найнагальніша проблема системи "Фінанси" — це забезпечення правильного та швидкого заповнення форм фінансової звітності Тим більше, що склад показників, які заносяться у форми, регламентований або законодавчо, або наказами "Укрзалізниці" для випадку внутрішньофірмової звітності

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

Рис. 3.6. Оновлена структура АІС "Фінанси"

Цей модуль як функціональне доповнення АРМ підготовки даних "Фінансова звітність", повинен реалізовувати:

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

- можливість створення та збереження правил заповнення форм фінансової звітності;

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

- зручність та простоту здійснення фінансово-економічних розрахунків.

Модуль може бути або частиною АРМу "Фінансова звітність", або його окремим додатком. Створення модуля не має на увазі переробки інших АРМів оперативного чи середнього рівня або їх частин.

Модуль повинен працювати на всіх тих платформах, що й АРМ "Фінансова звітність". Це більшість платформ сімейства Windows, а саме Windows 95, Windows 98, Windows 98 SE, Windows ME, Windows NT 4.0, Windows 2000 та Windows XP.

Мовою програмування обрано Delphi, що походить від Турбо Паскаля, створеного для операційної системи CP/M у 1983 році. У лютому 1994 року Турбо Паскаль був перенесений на операційну систему MS-DOS.

На ранньому етапі розвитку комп'ютерів архітектури IBM PC Турбо Паскаль був однією з найпопулярніших мов розробки програмного забезпечення — головним чином тому, що це був цілком серйозний компілятор, редактор і т. ін., коштував усього $19.95 і працював на машині з 64 Kb оперативної пам'яті.

На Windows Турбо Паскаль був перенесений фірмою Borland у 1990 році. А найостанніша версія — мова Borland Pascal 7.0, що передувала Delphi, вийшла у світ в 1992 році. Розробка Delphi почалася в 1993 році. Після успішного beta-тестування Delphi показали на "Software Development '95". Саме 14 лютого 1995 року офіційно оголосили про її продаж у СІЛА. У мережу торгівлі Delphi потрапив через 14 днів — 28 лютого 1995 року [56, с. 201-206].

Охарактеризуємо основні переваги Delphi.

• Можливість багаторазового використання й розширення компонентів. Delphi усуває необхідність програмувати такі компоненти Windows загального призначення, як мітки, піктограми і навіть діалогові панелі та безліч інших багаторазово використовуваних компонентів, які дозволяють заощаджувати час і програмні зусилля під час розробок для Windows. Delphi має попередньо визначені візуальні і невізуальні об'єкти, до яких належать кнопки, об'єкти з даними, меню і вже побудовані діалогові панелі. За допомогою цих об'єктів можна забезпечити виведення даних просто кількома натискуваннями кнопок миші, не вдаючись до програмування. Завдяки великому списку об'єктів Delphi очолює перелік мов програмування, що надають можливість повторного використання компонентів.