Введення
В даний час все більше і більше поширення, як у виробництві, так і в документообігу підприємств знаходить комп'ютерна техніка, все ширше і ширше стає перелік охоплених нею завдань. Постійно зростає обсяг і складність оброблюваної інформації, потрібні все нові і нові види її подання. Як показує практика, більшість користувачів вже не уявляє собі, як би вони виконували свою роботу, з якої чудово справлялися ще 5 - 10 років тому, без допомоги комп'ютера. Ось тільки деякі з переваг використання обчислювальної техніки при роботі, з якими - небудь даними, документами:
можливість оперативного контролю за достовірністю інформації, зменшується число можливих помилок, при генеруванні похідних даних;
відразу після введення, дані можуть брати участь в різних операціях;
можливість швидкого отримання необхідних звітів;
необхідна інформація може бути швидко знайдена (у тому числі за допомогою контекстного пошуку), пошук якої в звичайній папці з документами утруднений;
істотна економія часу і людських ресурсів при виконанні операцій, пов'язаних з обробкою інформації;
дозволяє швидко і в найбільш підходящому для конкретної людини вигляді переглянути дані, що підвищує їх сприйняття.
Все, вище викладені переваги, на сьогоднішній день оцінені не тільки рядовими користувачами, але і владними структурами, особливо це стосується можливості контролю та пошуку інформації. У нашому випадку податкова поліція зацікавлена мати єдину, електронну базу по всім фізичним особам - платникам податків, так як наявність такої бази істотно ускладнює процес ухилення від сплати податків (приховування, заниження доходів, повторне використання одноразових пільг і т.д.)
Тому 15 червня 1998 була прийнята чергова редакція інструкції державної податкової служби Російської Федерації № 35 від 29 червня 1995года. Згідно з якою, з 01 березня 1999 року всі підприємства з чисельністю працюючих понад 100 чоловік зобов'язані надавати дані про доходи своїх працівників до податкової інспекції на магнітних носіях, причому в чітко обумовленому форматі. (Див. Додаток 2)
На практиці ж податкова інспекція вимагає надання даних на магнітних носіях організаціями із загальною чисельністю працюючих понад 20 осіб.
У зв'язку з вище викладеним, у великих підприємств і об'єднань з'явилася гостра потреба у відповідному програмному забезпеченні. Пропоноване податковою службою для цих цілей ПО, забезпечує імпорт даних тільки з конкретної, не дуже поширеної програми Best-4, розробленої фірмою "Інтелект-Сервіс".
Підприємства об'єднання "СургутГазПром" в даний час працюють з двома різними програмними продуктами, призначеними для розрахунку заробітної плати і обліку інших доходів платників податків;
комплекс "Заробітна плата", розроблений "АСУ-Партнер";
АРМ з обліку праці та заробітної плати (ВАТ Автоматика).
Обидва цих комплексу не підтримують надання звітів до податкової інспекції на магнітних носіях, і в силу обмеженості використовуваної СУБД (FoxPro v.2.6 (Х)) не здатні вести єдину базу по всьому об'єднанню. Тому було поставлено завдання, розробити програмний продукт, який був би в стані:
вести єдину базу даних про доходи фізичних осіб по всьому об'єднанню;
видавати звіти в податкову інспекцію на магнітному носії;
видавати інші необхідні звіти про нарахування, утримання платників податків на паперових носіях, в тому числі про динаміку нарахувань і утримань, як по всьому об'єднанню, так і за окремими категоріями осіб;
обробляти довільні запити користувача до бази даних;
збирати інформацію у власну базу, з баз даних програм розрахунку заробітної плати, що використовуються на місцях;
підтримувати ручне введення і коригування інформації;
забезпечувати захист від несанкціонованого доступу до бази, як для зміни, так і для перегляду даних;
відповідати сучасним вимогам по швидкодії, ергономічності, використовувати сучасну СУБД з можливістю заміни її на ще більш сучасну в майбутньому;
мати можливість налаштування під змінюється законодавство, з мінімальними переробками.
Дана робота є автоматизованим робочим місцем бухгалтера з відділу податкової політики підприємства, що веде звітність в податкову інспекцію. Вона відповідає всім вище викладеним вимогам.
У роботі:
дається повний опис роботи з алгоритмами запитів;
даються структури баз даних, використовуваною програмою;
наведено безліч ілюстрацій, що допомагають зрозуміти роботу програми;
До дипломної роботи додається демонстраційна програма, виконана на Borland Delphi 4.0 з використанням СУБД InterBase v 5.0 і представлена на дискеті 3,5 ".
1. Огляд існуючих аналогів
У даному розділі я постарався розглянути декілька найбільш популярних в нашій країні програмних продуктів автоматизують в тій чи іншій мірі бухгалтерський облік підприємства.
1.1. Турбо бухгалтер
Програма Турбо Бухгалтер розроблена науково - дослідним центром ДІЦ. Найбільш рання з її версій, з якими я мав справу - версія 3.0.
Програма призначена для ведення синтетичного й аналітичного бухгалтерського обліку по всіх розділах. Аналітичний облік ведеться по об'єктах аналітичного обліку (аналітичним ознаками) у натуральному та вартісному виразах.
Її відмінною рисою, є дуже розвинений внутрішній мова, яка включає в себе більше 100 операторів, змінні, розвилки, а з 6 версії масиви і цикли. Це дозволяє написати, на мою особисту досвіду (4 роки роботи), практично будь-яку типову операцію, звіт, бланк, навіть за такого предмету безпосередньо не пов'язаного з бухгалтерією, як облік продажів у магазинах фірми або телефонний довідник. Цьому також сприяє розвинена система позабалансових рахунків проводки, за якими зберігаються в базі, і показуються лише на вимогу програміста. Керівництво програми так само розділена на дві книги: "Керівництво користувача" і "Керівництво програміста".
Введення проводок можна організувати в ручну, але в основному для цього використовуються бланки, які генерують проводки від 1 до необмеженої кількості.
Після занесення проводок в журнали операцій, необхідно обробити журнали, для прийняття цих проводок в базу. Ще однією відмінною рисою цієї програми є можливість ведення декількох планів бухгалтерії. План бухгалтерії - це файл з налаштуваннями (підприємство, видимі журнали, бланки, типові операції, аналітичні ознаки тощо), тобто ми можемо набудувати програму, так, щоб вести кілька різних підприємств на одному комп'ютері, в одній базі. Це не тягне надмірність даних, тому що різні фірми можуть використовувати, наприклад: загальні бланки, аналітичні ознаки і т.д.
Після розрахунку підсумків програма автоматично формує різні відомості і звіти:
зведені проводки;
оборотно-сальдову відомість;
оборотно-сальдову відомість по об'єктах аналітичного обліку;
картка рахунку;
картка рахунку по одному об'єкту аналітичного обліку;
головну книгу;
аналіз рахунку по датах;
аналіз рахунку по об'єктах аналітичного обліку;
аналіз об'єкта аналітичного обліку по всіх рахунках;
картка об'єкта аналітичного обліку по всіх рахунках;
журнальний ордер.
Також дозволяє задати довільний звіт.
На сьогодні, остання з відомих мені версій - 6, виходить в чотирьох варіантах:
базова;
професійний (локальна);
професійний (мережева) - вперше;
ТБ-6 Зарплата.
Але більш ранні версії також дозволяли працювати в мережі при правильних прописаних шляхах типу "GlBuhC: TB6Blanka *. gru"
З негативних рис хотілося б зазначити:
створивши прекрасний внутрішній мову, розробники заощадили на розробці бланків, надавши робити це кінцевим користувачам, що, ймовірно, різко знизило популярність цієї програми;
обмеження ширини бланка - 255 символів (не завжди достатньо);
часта (у середньому 1 раз на тиждень) необхідність перебудови баз з-за її псування програмою, що може займати до 10 хвилин (виправлено в 6 версії).
1.2. 1C: Бухгалтерія
Напевно, на сьогодні найпопулярнішою з бухгалтерських програм є 1С Бухгалтерія - універсальна бухгалтерська програма яка призначена для ведення синтетичного й аналітичного бухгалтерського обліку по різних розділах. Аналітичний облік ведеться по об'єктах аналітичного обліку (субконто) у натуральному та вартісному виразах.
Програма надає можливість ручного й автоматичного введення проводок. Усі проводки заносяться в журнал операцій. При перегляді проводок у журналі операцій їх можна обмежити довільним тимчасовим інтервалом, групувати і шукати по різних параметрах проводок.
Після розрахунку підсумків програма формує різні відомості:
зведені проводки;
оборотно-сальдову відомість;
оборотно-сальдову відомість по об'єктах аналітичного обліку;
картка рахунку;
картка рахунку по одному об'єкту аналітичного обліку;
аналіз рахунку (аналог головної книги);
аналіз рахунку по датах;
аналіз рахунку по об'єктах аналітичного обліку;
аналіз об'єкта аналітичного обліку по всіх рахунках;
картка об'єкта аналітичного обліку по всіх рахунках;
журнальний ордер.
У програмі існує режим формування довільних звітів, що дозволяє на деякій бухгалтерській мові описати форму і зміст звіту, включаючи в нього залишки й обороти по рахунках і по об'єктах аналітичного обліку. За допомогою даного режиму реалізовані звіти, надані в податкові органи, крім того, даний режим використовується для створення внутрішніх звітів для аналізу фінансової діяльності організації в довільній формі. Крім того, програма має функції збереження резервної копії інформації і режим збереження в архіві текстових документів. Програма може бути повністю налаштована бухгалтером на поточне законодавство і конкретні форми обліку.
"1С" реалізована для різних програмних і апаратних платформ: DOS, Windows, Windows 95, Macintosh (з початку 1996 р.), Power Macintosh (з літа 1996 р.). Існує кілька модифікацій системи: базова, професійна (для рішення більш складних бухгалтерських задач), мережна.
З недоліків можна відзначити:
малі можливості базової версії;
досить високу ціну при покупці всіх необхідних модулів для автоматизації бухгалтерії середнього підприємства.
1.3. БЕСТ
ПЗ "БЕСТ" (розробка фірми "Інтелект-Сервіс") виконана у вигляді набору взаємозалежних програмних модулів: встановлення та системні утиліти; ведення Головної книги (АРМ головного бухгалтера); облік касових операцій; облік операцій з банком; облік основних засобів; облік виробничих запасів; облік товарів і готової продукції; управління продажами (реалізацією); заробітна плата.
В даний час, остання з відомих мені версій - 4.12 є орієнтацією на комплексну автоматизацію підприємств. Розроблені спеціалізовані версії для оптової та роздрібної торгівлі, страхової діяльності, бюджету і навіть мостозагонів (працює в мостозагону № 94). Є потужна система аналізу фінансового стану підприємства.
Крім функцій, що дозволяють вирішувати завдання управління продажами, розрахунків з постачальниками і покупцями, підтримки операцій торгового залу, обліку ресурсів підприємства за групами товарно-матеріальних цінностей, номенклатурі, місць зберігання і т.п., в "БЕСТ-4" включено ряд додаткових можливостей . Нова прикладна підсистема "Управління закупівлями" забезпечує складання і подальше супроводження реєстрів рахунків-фактур постачальників, контрагентів і покупців, на основі яких автоматично формуються звіти по операціях купівлі / продажу. Ведення окремого реєстру рахунків кредиторів дозволяє консолідувати і відстежувати всі взаєморозрахунки з постачальниками і контрагентами.
Для підприємств роздрібної торгівлі "БЕСТ-4" надає можливість ведення індивідуальних прайс-листів для кожного магазину, а також архіву прайс-листів, використовуваного для отримання докладних звітів за обсягом продажів на будь-яку дату. Система здійснює зв'язок з касовими апаратами, підтримує систему штрихового кодування товару. Система дозволяє вести облік для довільного числа незалежних підприємств і використовувати для його автоматизації тільки необхідний набір модулів. Система цікава зручним інтерфейсом, своєю багатофункціональністю, гнучкістю і простотою настроювання на потреби конкретного підприємства.
З недоліків хотілося б відзначити:
невелику швидкість роботи, що викликано моральною застарілістю використовуваної СУБД (FoxPro 2.6) і величезним числом файлів в директорії з даними понад 600, що сильно ускладнює роботу ДОС по роботі з ними;
накладення досить істотних обмежень на внутрішню мову (мабуть, для збереження тільки за собою права модифікації). Наприклад, неможливо додати до бланку довільний реквізит. Що викликає необхідність звернення у фірму розробник;
відсутність планів випуску версії з Windows, що різко знижує її популярність;
для захисту використовується ключ (вставляється в LPT порт і в принципі прозорий для принтера), але деякі з відомих мені принтерів, зокрема LexMarkі спрацьовують при перевірки наявності ключа.
Продукт може функціонувати як в локальному, так і в мережевому варіанті. Як мережевий середовища використовуються ОС NetWare версій 3.11 і вище, Windows NT, VINES, LANtastic та ін Вимоги до апаратного забезпечення: для станції-клієнта необхідні процесор 386 і вище, оперативна пам'ять від 4 Мбайт; для сервера - процесор від 486DX, ОЗУ обсягом не менше 16 Мбайт.
1.4. Інтегратор 3.0
Пакет "Інтегратор", призначений для комплексної автоматизації бухгалтерського обліку. Версія "Інтегратор 3.0" в мережевому виконанні призначена для роботи на промислових підприємствах різних галузей і видів діяльності, тому що історично всі розробки "Інфософт" були орієнтовані на автоматизацію промислових підприємств.
"Інтегратор 3.0" складається з наступних підсистем: грошові кошти (каса, банк); дебітори і кредитори; матеріали, продукція, товари, МШП; постачальники та підрядники, основні засоби та нематеріальні активи; виробничі витрати; покупці і замовники; прибуток, податки, капітал; фінансова звітність.
При розробці використовувалася СУБД Clipper 5.2. У мережевому варіанті базовою є конфігурація "файл-сервер". Для роботи в архітектурі клієнт / сервер необхідно додатково встановити ПО Advantage Xbase Server. "Інтегратор" експлуатується в мережах NetWare 3.xx і вище, Windows NT, LANtastic та ін Не рекомендується застосування ОС NetWare 4.01. Вимоги до апаратного забезпечення: для станції-клієнта необхідні процесор класу 486DX2 і 8 Мбайт оперативної пам'яті; для сервера - процесор не нижче Pentium 75 і ОЗУ об'ємом від 16 Мбайт.
2. Опис автоматизуються функцій
Мета створення системи: забезпечити виконання вимог законодавства щодо звітності з прибуткового податку.
Призначення системи:
облік нарахованої заробітної плати на підприємстві, інших доходів і утриманого прибуткового податку;
ведення різної статистики з оплати праці, як в об'єднанні "СургутГазПром" в цілому, так і в кожному підрозділі окремо;
видача необхідних звітів до податкової інспекції, як на магнітних, так і на паперових носіях;
заповнення довідок.
Передбачається, що система буде використовуватися в наступних відділах підприємства:
відділ податкової політики;
відділ ОТиЗ.
2.1. Аналіз існуючої системи функціонування та завдання автоматизації
В даний час об'єднання "СургутГазПром" складається з тридцяти трьох структурних підрозділів - підприємств другої ланки, які в свою чергу мають у своєму підпорядкуванні дрібні підприємства, ділянки. Всі ці підрозділи географічно розподілені по Сургут, Сургутської району, Тюменської області. У кожному окремому підрозділі є свої управляючі структури (директор, заступники і т.д.). Настільки розгалужена структура, викликана виключно виробничою необхідністю, має ряд незручностей у частині централізованого планування і управління. У цікавій для нас частини, це призвело до того, що в різних структурних підрозділах встановлено різне програмне та технічне забезпечення, розроблені різні системи кодування інформації, відсутня єдина база даних, різні форми внутрішніх звітів. Тільки в кінці 1998 року була зроблена спроба, перевести всі підрозділи на роботу з єдиними класифікаторами. Зокрема введено єдиний класифікатор видів нарахувань і утримань, розроблений відділом охорони праці та заробітної плати. Також розробляються єдині довідники посад і професій.
У місці з тим, незважаючи на таку роз'єднаність, СургутГазПром змушений звітувати перед податковою інспекцією як єдине ціле.
До 1999 року всі звіти про доходи працівників, утриманий прибутковий податок підготовлялися і здавалися на паперових носіях. Однак, в даний час, у зв'язку із змінами в законодавстві, про які йшла мова у вступі, це стало неможливо.
У даний момент надавати звіт на магнітних носіях представляє проблему в зв'язку з вище викладеної ситуацією.
Також не представляється можливим ведення єдиної бази через програмного забезпечення різних фірм, великий територіальної розподіленості і величезного обсягу інформації, з яким застосовувана СУБД працювати просто не в змозі (за один рік тільки по одному структурному підрозділу накопичується інформація обсягом понад 140 Мбайт).
У цих умовах було прийнято рішення про автоматизування роботи відділів податкової політики об'єднання.
Схема представлена на малюнку 1 відображає потоки інформації в процесі виробництва звітності до ДПІ РФ. У міру потреби, але не рідше одного разу на місяць, підрозділи передають необхідну для розрахунку прибуткового податку інформацію до відділу податкової політики центрального офісу підприємства, де ці дані консолідуються і перевіряються, після чого готується звітність для ДПІ РФ. Також до цих даних має доступ відділ ОТиЗ для одержання необхідних йому звітів по заробітній платі.
Завданням розв'язуваної розробленою системою є автоматизація цих процесів.
2.2. Склад функцій що реалізуються системою
збір інформації про нараховану працівникам заробітної плати та про утриманий прибутковий податок від усіх структурних підрозділів Газпрому;
передача інформації від віддалених робочих станцій на сервер через електронну пошту, безпосереднє з'єднання по модему, або підготовка інформації для передачі за допомогою магнітних носіїв;
перевірка коректності отриманої інформації (правильності утримання прибуткового податку);
формування власної бази, видачі всіх необхідних звітів і довідок в податкову інспекцію, як на магнітних, так і на паперових носіях, на основі інформації та бази даних, згідно з чинним законодавством РФ;
формування і видача внутрішніх звітів;
чисельність працівників підрозділів, розмір середньої заробітної плати;
динаміка змін чисельності працівників, середньої заробітної плати;
динаміка% і чисельності працівників, що знаходяться на лікарняному;
динаміка% і чисельності працівників перебувають, у чергових відпустках;
видача інших внутрішніх звітів;
ручне введення інформації про заробітну плату та заповнення довідок в податкову інспекцію для фізичних осіб;
забезпечення сервісних функцій, як то: оптимізація бази даних, ведення архівів за "закриті" роки, резервне копіювання даних і їх відновлення, блокнот, калькулятор, календар;
забезпечення захисту даних від несанкціонованого доступу.
2.3. Рішення за структурою системи
Структурно система складається з робочої станції і серверної частини.
У функції серверної частини повинні входити:
зберігання, Оптимізація і підтримування в робочому та актуальному стані базу даних;
оброблення запити користувачів;
забезпечення захисту даних від несанкціонованого доступу.
У функції робочих станцій входить:
забезпечення збору, імпорту інформації, безпосередньо з програм її формують;
перевірка коректності зібраної інформації;
передача інформації серверу;
формування запитів до сервера;
видача довідок і звітів;
підтримка сервісних функцій, забезпечення дружнього інтерфейсу користувача.
2.4. Рішення за функціональним розбиття системи на модулі
Функціонально АРМ на робочій станції складається з наступних модулів:
модуль імпорту, що займається вибіркою інформації з баз даних АРМів розрахунку заробітної плати та її імпортом у власну базу;
модуль довідників, призначений для коригування та показу довідників системи (довідник професій, посад, цехів, дільниць, регіонів тощо);
робочий модуль, призначений для введення / перегляду інформації, отримання різних звітів;
контролюючий модуль, що займається контролем достовірності та цілісності інформації, а також правильності утримання прибуткового податку з фізичних осіб;
модуль адміністратора, призначений для коригування системної інформації шляхів доступу і т.п.
3. Проектне рішення
У даному розділі розглянуті:
рішення щодо заходів, для збереження цілісності баз і запобігання несанкціонованого доступу;
вибір операційного середовища та засобів розробки;
рішення по комплексу технічних засобів;
інформаційне забезпечення розробки.
3.1. Забезпечення захисту баз даних
Система забезпечує захист від несанкціонованого доступу на читання, запис і коригування частини інформації, що зберігається в ній. Для доступу на зміну в базі службової інформації передбачений пароль адміністратора. Також введено розмежування доступу між робочими станціями, кожна з них працює тільки зі своїми даними.
Для збереження інформації при перервах у зовнішньому електроживленні передбачені такі заходи:
ведення журналу транзакцій, що дозволяє у випадку порушення структури баз зробити відкат транзакції;
максимальне скорочення часу, протягом якого робітники файли відкриті на запис, тобто при необхідності оновити файл, він відкривається на запис, оновлюється і відразу ж закривається. При цьому вдається виключити ситуацію, коли файл відкритий тривалий час;
періодичне резервне копіювання бази;
наполеглива рекомендація в керівництві користувача і програміста, встановити UPS на сервер.
Дана система є відновлюваної і періодично обслуговується системою тривалого функціонування. В частині загальних ергономічних вимог, відповідає загальноприйнятим стандартам.
3.2. Вибір операційного середовища та засобів розробки
Вибір в якості операційного середовища для функціонування АРМу платформи win32 (їй відповідають операційні системи Windows95, Windows98, Windows NT) обумовлений наступними її особливостями:
орієнтація замовника на цю платформу;
розвинені засоби створення призначеного для користувача інтерфейсу;
достатня масштабованість, тобто здатність працювати на широкому діапазоні комп'ютерного обладнання, починаючи від машин рівня 486DX4-100 до багатопроцесорних систем;
наявність драйверів для підтримки широкого спектру периферійних пристроїв (відеоадаптерів, мережевих адаптерів, принтерів, дисководів CD-ROM тощо);
надзвичайно широке розповсюдження цієї платформи;
прийнятна для завдань такого рівня надійність і продуктивність програм, що працюють з використанням механізму витісняючої багатозадачності.
З недоліків даної платформи, істотних для пропонованої розробки, варто відзначити наступні:
відсутність в операційних системах Windows95 і Windows98 засобів забезпечення безпеки і захисту від несанкціонованого доступу, що змушує розробляти власні або використовувати сторонні модулі для цього. У Windows NT цей недолік частково усунений, проте як і раніше немає підтримки шифрации збережених даних;
висока вимогливість до апаратних ресурсів комп'ютера, що змушує використовувати більш потужні апаратні платформи.
Вибір в якості середовища розробки пакету Borland Delphi 4 обумовлений наступними його особливостями:
політика підприємства в галузі розробки ПЗ;
можливість повторного використання готових програмних компонент;
наявність великої кількості стандартних компонентів, а також достатня кількість бібліотек компонент від сторонніх фірм, що розширюють і доповнюють можливості стандартних;
можливість генерації коду під платформу win32;
підтримка технологій ActiveX, OLE, COM, CORBA, InterNet-технологій;
досить висока швидкість і надійність роботи скомпільованих програм у порівнянні з інтерпретують системами;
орієнтація на "візуальні" методи розробки програм, що дозволяє швидко і якісно спроектувати і реалізувати стандартний користувальницький інтерфейс;
перспективність, популярність і широка поширеність даного середовища розробки в світі.
Вибір в якості СУБД розробки InterBase v. 5.0. обумовлений наступними його особливостями:
після включення його до складу Delphi Client / Server Suite InterBase став "рідним" для Borland (нині Inprise Corporation), а засоби розробки додатків цієї компанії давно зарекомендували себе з позитивного боку. Вже те, що він дуже активно використовується в державному і військовому секторі США говорить на його користь;
InterBase досить простий в налаштуванні і в адмініструванні в порівнянні з іншими SQL серверами;
InterBase володіє відмінними технічними характеристиками:
розмір бази даних до 20 Гбайт;
Максимальна кількість таблиць у одній БД 65536;
Максимальна кількість полів в одній таблиці 1000;
максимальну кількість записів в одній таблиці не обмежене;
максимальна довжина запису 64К (не рахуючи полів BLOB);
максимальна довжина поля 32К (крім полів BLOB - не обмежена);
максимальну кількість індексів в одній БД 65536.
Додатково в процесі розробки застосовувалися такі програмні пакети і інструментальні засоби:
Пакет InstallShield Exdivss - для створення комплекту дистрибутивних дискет.
Для підготовки документації, рекламного листа і демонстраційної версії програм використовувалися програми, що входять до комплекту Microsoft Office 97.
3.3. Рішення з комплексу технічних засобів
3.3.1. Вибір критеріїв відбору технічних засобів
Серед усієї безлічі критеріїв відбору ТЗ нас цікавлять:
достатній обсяг оперативного запам'ятовуючого пристрою;
достатній об'єм накопичувача на жорсткому магнітному диску;
прийнятний тип відеоадаптера і дисплея для роботи користувача;
достатня продуктивність центрального процесора;
наявність можливості виведення інформації на паперовий, магнітний носій;
достатня швидкість передачі даних в ЛВС;
прийнятна вартість складових комплексу технічних засобів.
3.3.2. Розрахунок необхідних ресурсів, для функціонування системи, вибір ТЗ
Обсяг необхідного ОЗП розраховується, виходячи з розмірів пам'яті, займаної завантажується операційною системою, з необхідного обсягу пам'яті, що виділяється під драйвери для обслуговування ЕОМ, програми-оболонки, основного завантаження модуля програмного комплексу, динамічних бібліотек, підвантажуваних по мірі виконання програми та резерву пам'яті для обробки інформації.
Виходячи з вищевикладеного, доходимо, що для нормальної роботи серверної частини системи необхідно не менше 64 Мбайт ОЗУ (128 Мбайт рекомендується). За сучасними поняттями, це вже не надто високу вимога пояснюється тим, що для нормальної роботи обраної в якості ОС серверної частини системи Windows NT v. 4.0 потрібно не менше 32 Мбайт оперативної пам'яті. Крім того, з огляду на великий обсяг бази даних, більше 100 Мбайт і можливість багатокористувацького доступу для оперативної роботи сервера буде потрібно ще не менше 32 Мбайт ОЗУ.
Враховуючи те, що в якості ОС для функціонування робочих станцій обрана Windows 95 або Windows 98 приходимо до того що, для нормальної роботи необхідно й досить 16 Мбайт ОЗУ (при використанні Windows 98 рекомендується 32 Мбайт). Це пояснюється тим, що Windows 95 для нормального функціонування вимагає 8 Мбайт ОЗУ, Windows 98 - 12. Сама система займає 6 Мбайт оперативної пам'яті. Так як в комп'ютери типу Pentium плати пам'яті випускаються обсягом 8, 16, 32, 64 Мбайт і вставляються по парно, а комп'ютери типу Pentium II, Pentium III об'ємом 16, 32, 64, 128 Мбайт і вставляються по одному. Виходячи з вище наведених технічних міркувань, ми отримуємо вищенаведені вимоги до оперативної пам'яті.
Підбір об'єму накопичувача на жорсткому магнітному диску, далі HDD грунтується на розмірі бази даних, в момент її передбачуваної пікової завантаженості, займаному ОС об'ємом жорсткого диска, а також на розмірі архівів створюваних системою за минулі роки. Так само слід врахувати необхідну швидкодію HDD, в залежності від потреби в швидкості реакції системи.
Передбачуваний обсяг архівів, з огляду на перший рік функціонування системи, приблизно складе (річний обсяг інформації * передбачуваний термін служби техніки).
Передбачуваний термін служби техніки - 5 років. Так як 5 років - середній термін повного морального старіння парку машин і його заміни.
ОС Windows NT/95/98 в середньому займають по 150-200 Мбайт вільного місця на жорсткому диску.
Враховуючи все вищевикладене, приходимо до висновку, що для нормального функціонування серверної частини системи необхідно 100 * (5 + 1) + 150 »1Гбайт вільного дискового простору, однак бажано мати деякий резерв вільного місця, тому рекомендований об'єм вільного місця на жорсткому диску - 1, 5 Гбайт. Для здійснення резервного копіювання необхідно мати ще один диск розміром 850 Мбайт. У зв'язку з великим обсягом бази даних і можливістю багатокористувацького доступу, рекомендовано використовувати для роботи SCSI HDD зі швидкістю передачі даних не менш 10Мбайт/сек.
Для нормальної роботи робочої станції необхідно не менше 350 Мбайт (150 - Windows + 150 - InterBase + 50 резерв) вільного місця на жорсткому диску зі швидкістю передачі даних не менш 2 Мбайт / сек.
Серверна частина системи не потребує постійної присутності людини, тому для її роботи монітор не потрібно, однак для періодичного обслуговування бази, враховуючи застосовувану платформу win32 необхідно мати VGA або SVGA монітор діагоналлю 14 ".
Для роботи робочих станцій, у зв'язку з великою кількістю даних, що відображаються і використовуваної OS необхідний SVGA монітор діагоналлю 15 ".
Вибір центрального процесора завжди грунтується на міркуваннях про продуктивність системи.
Враховуючи великий обсяг оброблюваної інформації і застосовується платформу для прийнятної роботи сервера, необхідно використовувати процесор Intel п'ятого покоління (Pentium) з вбудованим співпроцесором з тактовою частотою не менше 200 Mzh або його аналоги.
Для робочої станції з-за великого обсягу обчислень також необхідний цей або більш сучасний процесор.
Для перенесення інформації віддалені робочі станції, а також головна робоча станція у відділі податкової політики для видачі звітів до ДПІ, повинні бути обладнані дисководами 3,5 ".
Для друку звітів і довідок, вони так само повинні бути обладнані принтером формату А4 або мати доступ до такого мережного пристрою.
Швидкість передачі даних в ЛВС залежить від обраного мережного програмного і технічного забезпечення. Парк застосовуваних машин на підприємстві замовника оснащений Ethernet-адаптерами та іншими мережевими пристроями зі швидкістю передачі даних 10Mбіт/сек. Враховуючи достатність цієї швидкості для роботи системи, і дорожнечу заміни цього устаткування на 100 Mzh прийнято рішення, використовувати наявні засоби.
Отже, підіб'ємо підсумки вище наведених міркувань і висунемо комплексні вимоги до складу технічних засобів, необхідних для функціонування системи.
Для роботи серверної частини системи необхідно:
ПЕОМ на базі Intel-сумісного процесора п'ятого покоління з частотою не менш 200МГц, з ОЗУ рівним 64Мб, оснащена VGA-відеоадаптером і монітором 14 ", мережевим Ethernet-адаптером на 10Мбіт, з вільним дисковим простором рівним 1Гб.
Для роботи робочої станції системи необхідно:
ПЕОМ на базі Intel-сумісного процесора п'ятого покоління з частотою не менш 200МГц, з ОЗУ рівним 16Мб, оснащена SVGA-відеоадаптером і монітором 15 ", мережевим Ethernet-адаптером на 10Мбіт, з вільним дисковим простором рівним 350Мб і доступом до принтера формату А4.
3.4. Інформаційне забезпечення розробки
Проектування інформаційного забезпечення розділене на два етапи:
аналіз існуючих інформаційних потоків;
розробка структури баз даних.
Інформаційне забезпечення повинно виконувати наступні функції:
організація та ведення масивів інформації;
формування звітів;
контроль даних;
збереження та відновлення даних.
Реалізація вищезазначених функцій виконана за рахунок:
використання СУБД InterBase v 5.0;
використання ODBC-драйверів для роботи з таблицями FoxPro v.2.6;
розробки власних модулів для збереження і відновлення даних з використанням середовища розробки Inprise Delphi Client / Server Suite v. 4.
3.4.1. Вхідна і вихідна інформація
Відмінними ознаками даної АС є:
середній обсяг вхідний і вихідний інформації;
велику кількість перетворень і обчислювальних операцій, вироблених над даними.
Робота з даними виробляється в кілька етапів:
збір інформації з АРМів заробітної плати;
перерахунок / перевірка даних;
видача необхідних звітів.
Збір вхідної інформації проходить в три етапи:
перевірка інформації в базі даних АРМу розраховувача на повноту, цілісність, коректність;
безпосередній імпорт даних до бази даних сервера;
перевірку власних довідників на повноту і коректність інформації.
Вихідна інформація включає в себе:
стандартні звітні форми для надання до ДПІ РФ на паперових носіях;
файл про сукупні доходи осіб-платників податків (формат див. Додаток 2);
інші звіти та довідки для відділу ОТиЗ і керівництва (динаміка росту / падіння заробітної плати на підприємстві, рівень доходів різних категорій працюючих, чисельність працівників підрозділів, звіт про минулі сумах за кодами витрат, балансовими рахунками тощо).
Збір інформації проводиться кожного місяця після розрахунку зарплати (15 число). По закінченню збору інформації проводиться перевірка її коректності при наявності потреби, по команді оператора здійснюється перевірка правильності утриманого прибуткового податку. ООТиЗ отримує доступ до нової інформації. Отримані дані у вигляді звітних форм передаються в ДПІ РФ.
Під час збору інформації особливий наголос робиться на перевірці її повноти і коректності, тому що вся вхідна інформація, яка стосується, безпосередньо, нарахувань / утримань, є ключовою. Помилка в цих даних потягне за собою невірно розраховане або не розраховане значення, яке, потрапивши в звітну форму або не потрапивши до неї зовсім, призведе до того, що форма буде визнана неправильно заповненої або спричинить за собою подібні неприємні наслідки. Помилка ж в довідкових даних призведе до того, що відділ ОТиЗ буде користуватися звітністю, яка не відбиває справжній стан справ на підприємстві.
3.4.2. Опис інформаційних масивів
Інформаційні масиви в даному комплексі розподіляються на три типи:
основні - зберігають отримані, запроваджені та розраховані дані за доходами (включаючи архівні копії минулих років), протоколи про отримання даних від підрозділів;
довідники, такі як довідник форм, довідник кодів нарахувань, довідник входимость, довідник з інформацією про структуру підприємства;
додаткові - містять інформацію про налаштування АС, іншу допоміжну інформацію.
Табличне опис структури бази даних наведено у Додатку 3.
4. Керівництво користувача
Керівництво користувача призначене для того, щоб навчити користувача програми роботі з нею. При цьому передбачається, що він має деякий початковий навик роботи з комп'ютером, тобто вміє працювати з клавіатурою і мишкою, орієнтується в повідомленнях видаються комп'ютером, знає, що таке Windows, вікно і т.п.
Тому в цьому розділі я постарався максимально докладно викласти основні режими роботи системи, не вдаючись в глибокі технічні деталі.
На малюнку 2. наведено відеокадр роботи системи з інформацією про розробника, версію і т.д.
4.1. Ідентифікація користувача
Інформація про заробітну плату та інших доходах фізичних осіб на сьогоднішній день є суворо конфіденційною. Крім того, слід врахувати те, що неправильні або неправомочні зміни даних приведуть до різних помилок у базі даних і, як наслідок, у звітах. Тому робота з даною системою починається з ідентифікації користувача, для чого система запитує його найменування та пароль, це демонструє нам відеокадр, наведений на малюнку 3. Після імені користувача і пароля проводиться перевірка прав доступу. На рисунках 4 та 5 продемонстровані відеокадри з АС з варіантами результатів.
У залежності від них, деякі з пунктів меню або опцій у формах можуть бути недоступні.
4.2. Довідники системи
На початку експлуатації АС необхідно заповнити довідники, перелік яких висвічується на екрані при вході в однойменну функцію основного меню (див. Малюнок 6). Інформація в довідниках повинна бути закодована (див. опис конкретних довідників).
Вся подальша робота користувача буде здійснюватися з тими кодами, які він заведе в довідники. Протягом часу експлуатації системи коди можуть вилучатися для того, коректуватися, додаватися новими значеннями в тому числі і імпортуватися з АРМів зарплати (аналогічно, будь-яка інша інформація довідників).
Для кожного довідника закладений свій перелік режимів обробки інформації, як то можливість редагування, друк, пошук, сортування і т.д.
Довідники використовуються для формування звітів, перевірки інформації, а також для формування файла, який в електронному вигляді передається до податкової інспекції і для друку документа "Довідка про доходи фізичної особи. Додаток № 3 до інструкції Державної податкової служби Росії N35 від 29 червня 1995 року" .
Тому при формуванні довідників потрібно керуватися інструкцією щодо їх заповнення "вимоги до складу та структури інформації про доходи фізичної особи, що подається на магнітних носіях підприємствами, організаціями та податковими інспекціями", яка міститься на магнітному носії, що постачається податковими інспекціями, разом зі структурою переданого в інспекцію файлу, і інструкцією, наведеною в "Фінансової газеті" N52 (316) за грудень 1997 року.
4.2.1. Класифікатори
У класифікатори, згідно з їх опису наведеному нижче, заносяться об'єкти бухгалтерського обліку, які беруть участь у роботі даної АС і підлягають обов'язковому кодуванню.
Список довідників увійшли до класифікаторів:
види нарахувань;
види утримань;
довідник видів документів;
довідник посад;
довідник категорій персоналу;
довідник професій;
довідник регіонів Росії;
довідник країн;
довідник ділянок;
довідник цехів.
У довіднику видів нарахувань повинні міститися всі види нарахувань, які використовуються в даний час на підприємстві, використовувалися протягом звітного періоду, належить використовувати найближчим часом.
При введенні коду нарахування в будь-якому іншому режимі системи виробляється обов'язковий автоматичний контроль на його наявність у цьому довіднику. При його відсутності про це видається повідомлення.
Повторне введення одного й того ж коду не допускається.
Коди, введені в довідник видів нарахувань, автоматично потрапляють в довідники входимость (опис див. далі)
У довіднику з видами утримань повинні міститися всі види утримань, які використовуються в даний час на підприємстві, використовувалися протягом звітного періоду, належить використовувати найближчим часом.
При введенні коду утримання в будь-якому іншому режимі системи виробляється обов'язковий автоматичний контроль на його наявність у цьому довіднику. При його відсутності про це видається повідомлення.
Повторне введення одного й того ж коду не допускається.
Коди, введені в довідник видів утримань, можуть бути прив'язані до алгоритмів розрахунку прибуткового податку, пенсійного фонду, збільшувати неоподатковувану суму.
Види документів заносяться в довідник видів документів згідно довідника "Види документів, що засвідчують особу платника податків", що формується в самій податковій інспекції, наприклад:
01 - паспорт;
03 - свідоцтво про народження;
і т. д.
Довідник посад містить коди і найменування посад, що застосовуються в об'єднанні.
У довіднику категорій персоналу повинні міститися всі категорії персоналу (керівники, фахівці, робітники і т. д.), які:
є в даний час на підприємстві;
утворюються в найближчим часом.
При введенні коду категорії персоналу в будь-який інший відеокадр системи виробляється обов'язковий автоматичний контроль на його наявність у цьому довіднику. При його відсутності про це видається повідомлення і виконання операції припиняється.
Повторне введення одного й того ж коду не допускається.
У довідник професій повинні бути занесені всі професії, які є в об'єднанні.
Повторне введення одного й того ж коду не допускається.
Також у системі є довідник ділянок. Даний довідник необхідний для виробництва звітів для відділу ОТиЗ з вибіркою даних по ділянках, в ньому повинні міститися всі ділянки, які є в даний момент в підрозділі:
При введенні коду ділянки в будь-який інший відеокадр АС виробляється обов'язковий автоматичний контроль на його наявність у цьому довіднику. При його відсутності про це видається повідомлення, і виконання операції припиняється.
Повторне введення одного й того ж коду не допускається.
Довідник цехів так само необхідний для виробництва звітів для відділу ОТиЗ, але з вибіркою даних по цехах, в ньому повинні міститися всі цехи, наявні в даний момент в підрозділі:
При введенні коду цеху в будь-який інший відеокадр АС виробляється обов'язковий автоматичний контроль на його наявність у цьому довіднику. При його відсутності про це видається повідомлення, і виконання операції припиняється.
Повторне введення одного й того ж коду не допускається.
Найменування країн з кодами згідно класифікатора країн світу (Оксмен) Держстандарту Росії заносяться в довідник країн світу.
У довідник регіонів заносяться найменування регіонів Росії (область, край, республіка) прописки фізичної особи згідно з довідника зігніть.
4.2.2. Загальні довідники
Нижче наведено список і опис загальних довідників:
довідник неоподатковуваних мінімумів;
довідник організацій.
Одним з найбільш важливих довідників системи є довідник неоподатковуваних мінімумів. Даний довідник використовується для визначення суми мінімального неоподатковуваного заробітку для конкретного місяця, за який утримується прибутковий податок, а також для розрахунку прибуткового податку з кодів нарахувань, оподатковуваних податком в сумах, що перевищують дванадцять мінімальних неоподатковуваних заробітків.
У довіднику окремо по заданим користувачем років (кількість збережених років у файлі не обмежена) імпортуються з АРМів зарплати або набираються вручну суми неоподатковуваних мінімальних заробітків за кожен місяць року.
Користувач повинен самостійно стежити за змінами сум мінімальних заробітків і оперативно вносити в довідник зміни.
У будь-який момент часу (звітним місяцем є, наприклад, січень або лютий, або березень і т.д.) обов'язково повинні бути заповнені всі дванадцять місяців року.
У місяці, наступні за звітним, заноситься сума неоподатковуваного заробітку, рівна тій, яка діє у звітному місяці.
Довідник організацій містить коди і найменування про структурних підрозділів об'єднань. Приклад його заповнення наведено на рисунку 7.
Особливу увагу слід звернути на те, що в слідстві нормалізованності бази даних при зміні коду організації, його зміна відбудеться автоматично усіх таблицях бази даних АС, що може зажадати багато часу при великих розмірах бази.
4.2.3. Довідники стосуються працюючого
До складу довідників, які стосуються працюючого увійшли тільки ті довідники, значення яких встановлюються конкретно для кожної людини:
загальна інформація з фізичній особі;
особові рахунки працюючих.
У довідник із загальною інформацією з фізичній особі користувачем вводиться або імпортується інформація по кожному табельної номером, за яким потрібно передавати відомості до податкової інспекції.
Введена інформація зберігається для всіх подальших формувань файлу і коректується користувачем в міру необхідності.
У даний довідник вводиться така інформація як: табельний номер, цех, ділянка, посада, професія, паспортні дані і т.п.
Заповнення даного довідника обов'язково!
Особовий рахунок працюючого містить інформацію про нарахування, утримання за табельної номеру, по кожному періоду розрахунку. Даний довідник є основним джерелом інформації, тому:
заповнення його обов'язково;
цей довідник закритий для коригування, щоб уникнути його ручної правки і спотворення звітності, і може бути поповнений або відкоригований тільки шляхом перенесення відповідних даних з АРМа заробітна плата (опис див. нижче).
Перед тим як відобразити цей довідник необхідно відповісти на запит системи про діапазон відображуваних табельних номерів і періодів. (Наведено на малюнку 8.)
На рисунку 9 представлений приклад заповнення цього довідника реальними даними.
Для перегляду більш докладної інформації по працівнику досить зробити клацання мишею на його рядку. У вікні (наведено на малюнку 10) можна буде переглянути повну інформацію про нарахування та утримання вироблених з цього фізичній особі за вибраний період розрахунку.
4.2.4. Довідники входимость
Призначені для налаштування розрахунку прибуткового податку. Нижче наведений їх список:
входимость нарахувань в розрахунок прибуткового податку;
збільшення неоподатковуваної суми;
кратність пільги.
У таблиці входимость нарахувань в розрахунок прибуткового податку відображена входимость кодів нарахувань в розрахунок прибуткового податку.
Якщо код нарахування входить до алгоритму розрахунку прибуткового податку (тобто з нього береться прибутковий податок), то в стовпці, в якому знаходиться цей код, набирається одиниця. В іншому випадку, в цьому місці набирається нуль. Проти тих кодів, що обкладаються прибутковим податком по фіксованій шкалою 12% (місцевий + федеральний) проставляється двійка.
УВАГА! Повинен проставлятися нуль в реквізиті за кодами нарахувань, які обкладаються податком з урахуванням кратності по відношенню до неоподатковуваного мінімуму або збільшують неоподатковувану суму (в таблиці "входимость нарахувань в суму до виплати" за цими кодами нарахувань реквізити "Кратність пільги" і "Збільшення неоподатковуваної суми" відмінні від нуля). В іншому випадку, суми за цими кодами будуть обкладені прибутковим податком двічі: як повністю оподатковувані і як оподатковувані з урахуванням кратності.
У довіднику збільшення неоподатковуваної суми проставляється одиниця по тим кодами нарахувань / утримань, які при розрахунку прибуткового податку додаються до неоподатковуваного мінімуму, пільг та пенсійному фонду, утворюючи разом з ними неоподатковувану суму, віднімаються з доходу.
У довіднику кратності пільги проставляються значення, відмінні від нуля, за тими кодами нарахувань, які обкладаються прибутковим податком не повністю, а тільки в сумі, що перевищує річний мінімальний неоподатковуваний податком заробіток.
За тим кодами нарахувань, які порівнюються з неоподатковуваним мінімумом, будучи попередньо підсумовані, має проставлятися однакове значення.
4.2.5. Довідники таблиць податків і категорій платників податків
Дана категорія довідників складається з чотирьох пунктів які будуть описані нижче:
коефіцієнти для розрахунку пільг;
категорії платників податків;
основна таблиця прибуткового податку;
розмір прибуткового податку з чорнобильців.
Довідник коефіцієнтів для розрахунку пільг служить для визначення кількості пільг (на самого платника податків та дітей та утриманців, до нього відносяться) і мінімальних неоподатковуваних податком заробітків, які повинні бути надані платнику податків при утриманні з нього прибуткового податку залежно від розміру його доходу з початку оподатковуваного року (графа "Мінім." - на самого працівника, графа "ПІЛЬГ" - на дітей і утриманців).
У таблиці категорій платників податків повинні бути відображені всі категорії платників податків, що є на підприємстві.
Основна таблиця прибуткового податку є:
для розрахунку прибуткового податку з основних працівників підприємства, тобто з тих, у яких мінімальний неоподатковуваний заробіток при розрахунку прибуткового податку віднімається із суми доходу (у таких табельних номерів у довіднику, які стосуються працюючого значення реквізиту "Кількість мінімумів" повинно бути відмінно від нуля);
для розрахунку прибуткового податку з сумісників (у таких табельних номерів у довіднику, які стосуються працюючого значення реквізиту "Кількість мінімумів" має дорівнювати нулю).
Інформація в цю таблицю заноситься з офіційною таблиці, в якій дана градація сум заробітку для обкладення її прибутковим податком.
У першому рядку таблиці обов'язково має міститися інформація з найменшим діапазоном заробітку. У цьому рядку в графу "Сума, віднімається з оподатковуваного заробітку" заноситься неоподатковуваний мінімальний заробіток, який діє на конкретний звітний місяць. За зміною мінімального неоподатковуваного заробітку користувач стежить самостійно і в міру необхідності вручну коректує значення цієї графи. В інші рядки інформація повинна заноситися суворо за зростанням діапазонів заробітку.
Користувач набирає тільки початкове значення кожного наступного діапазону заробітку. Кінцеве значення попереднього діапазону формується автоматично на одну копійку меншим заданої цифри.
Таблиця розміру прибуткового податку з чорнобильців служить для розрахунку прибуткового податку з учасників ліквідації аварії на Чорнобильській АЕС, дохід яких оподатковується з урахуванням спеціальних пільг, передбачених відповідною постановою Уряду (так, за станом на 01 січня 1999 року - перші тридцять тисяч доходу, нараховані з початку року, податком взагалі не обкладаються).
Заповнення таблиці аналогічно її заповнення основної таблиці прибуткового податку, тільки тут у графі "Сума, віднімається з оподатковуваного заробітку", в першому рядку повинен набиратися той граничний заробіток, з якого згідно законодавства податок з чорнобильців не береться.
4.3 Робочі режими системи
4.3.1. Поповнення бази даних системи
База даних даної АС допускає два способи поповнення:
ручний (всі довідники, крім довідника "Особовий рахунок працюючого" допускають можливість ручного коректування даних);
автоматичний (передбачений режим поповнення довідників безпосередньо з баз АРМів заробітної плати, що застосовуються на підприємстві замовника).
Автоматичне поповнення здійснюється з бази даних АРМу поточного структурного підрозділу або файлів переданих по електронній пошті, на магнітному носії. На малюнку 11 наведено приклад поповнення довідника регіонів Росії. Даний довідник розроблений і застосовується ДПІ РФ і є єдиним для всіх підприємств.
Поповнення інформації про проведені нарахування та утримання провадиться після попереднього видання запиту про інтервал дат і табельних номерів. Фрагмент його ми можемо спостерігати на рисунку 12. Після чого виводиться індикатор, що відображає поточний стан процесу, виконувану операцію (Малюнок 12).
Під час поповнення відбувається автоматичний контроль коректності інформації для збереження цілісності бази даних. Він здійснюється на рівні СУБД шляхом введення зовнішніх ключів і тригерів, що забезпечують каскадне оновлення бази даних при зміні ключового поля в зв'язку один до багатьох. (SQL інструкції, реалізують вищеперелічене див. у Додатку 2). Після закінчення процедури імпорту видається відповідне повідомлення.
4.3.2. Підготовка даних для передачі по електронній пошті
Застосовується в разі необхідності передачі даних по електронній пошті, або за допомогою магнітного носія. Дана необхідність виникає, при неможливості доступу до головної локальну мережу підприємства з машини, на якій експлуатується АРМ Заробітна плата (наприклад, через віддаленість її в географічному плані). На малюнку 13 наведено відеокадр, що ілюструє роботу в цьому режимі.
Увага! На етапі підготовки даних ніякої перевірки коректності оброблюваної інформації не ведеться, тому що її повна перевірка все одно неможлива через відсутність доступу до головного сервера.
Підготовлені файли створюються в каталозі, які задає користувач у налаштуваннях, звідки їх можна передати електронною поштою CC-Mail з використанням існуючого програмного забезпечення, або переписати на магнітний носій.
Імпорт даних переданих через електронну пошту або магнітний носій здійснюється аналогічно імпорту даних від підрозділу має доступ до основної локальної мережі об'єднання.
4.3.3. Перевірка правильності утримання прибуткового податку
Найбільш важливими умовами, що забезпечують спокійне і безболісне спілкування з податковими органами, є достовірність, точність і своєчасність надання інформації. Для забезпечення достовірності в системі передбачений режим перевірки правильності утримання прибуткового податку.
Перевірка здійснюється на підставі таблиці входимость нарахувань в розрахунок прибуткового податку (приклад заповнення див на малюнку 14), таблиці шкали податку, таблиці c сумами мінімальних окладів, таблиці з коефіцієнтами пільг даних про нарахування / утримання, вироблених по фізичних особах.
По закінченні видається повідомлення та список осіб, у яких податок був утриманий невірно із зазначенням суми відхилень. Тому що, по уникнення порушення достовірності інформації, ручна правка особових рахунків, які стосуються працюючого заборонена, крім особливих випадків при вході за паролем адміністратора, то даний список підлягає здачі в бухгалтерію підрозділи для доутримання або повернення сум прибуткового податку.
4.4. Виробництво звітів
Як і в будь-який інший автоматизованій системі, що працює з базою даних в даній системі, виробництво звітів є найважливішою частиною і кінцевою метою всієї роботи.
На сьогоднішній день система забезпечує виробництво звітів для ДПІ, необхідну звітність для відділу ОТиЗ. Якщо говорити про перспективи розвитку системи, то варто згадати плани забезпечення необхідною звітністю, також плановий відділ. Нижче наведено список звітів системи.
Для ДПІ РФ:
податкова картка;
звіт про підсумкові суми доходів і прибутковий податок;
реєстру відомостей про доходи фізичних осіб;
список працівників з прогресивним оподаткуванням;
довідка про доходи фізичної особи;
формування файлу про доходи на магнітний носій.
Для відділу ОТиЗ:
склад ФЗП згідно класифікатора посад;
склад ФЗП згідно класифікатора кодів з нарахування;
склад ФЗП по ділянках;
склад ФЗП по цехах;
звіт по складу ФЗП, ФМП, інших фондів;
зведення по нарахуваннях з відображення балансових рахунків;
звід по відпустках і відгулів;
звіт по чисельності і нарахованої заробітної плати;
склад ФЗП згідно класифікатора категорій персоналу (у динаміці) (див. Малюнок 15);
розмір ФЗП і чисельність працівників у динаміці (див. Малюнок 16);
звіт про розмір ФЗП по довільному коду нарахування, цеху, дільниці і періоду (в динаміці).
Для того, щоб сформувати звіт, вам необхідно тільки заповнити форму, аналогічну наведеній на рисунку 12, тобто вибрати діапазон табельних номерів і період. У деяких випадках необхідно вибрати також структурну одиницю, за якою буде йти вибірка даних (цех, ділянка, категорію, тип нарахування і т.п.)
На закінчення варто відзначити, що всі звіти будуть сгенерірованни за поточним структурному підрозділу. (Вибір структурного підрозділу дивися в сервісних функціях)
4.5. Сервісні функції
Як і випливає з назви, сервісні функції покликані забезпечити вирішення двох завдань:
виконання операцій з обслуговування системи (робота з базою, налаштування параметрів і т.д.);
забезпечення користувача необхідним інструментарієм для підвищення комфортності роботи з системою.
Нижче наведено список функцій.
Функції доступні тільки адміністратору (подробиці приведені в керівництві програміста):
шляхи доступу;
резервне копіювання баз даних;
реіндексація баз даних;
установка паролів доступу.
Функції доступні користувачеві:
блокнот (вбудований текстовий редактор призначений для ведення записів. По своїх можливостях дещо поступається редактору WordPad, що поставляється разом з Windows 95/98. Зберігає файли в RTF форматі);
установка поточної організації (вибір поточного структурного підрозділу);
календар (призначений для зручності орієнтації користувача в робочий час, наведено на малюнку 17);
калькулятор (для зручності розрахунків, результати розрахунку можна переносити прямо у форму);
загальні параметри (для настройки загальних параметрів, таких як, поточний робочий період);
про програму (наводить коротку інформацію про програму, наведена на малюнку 2);
Доступ до службових сервісних функцій можна отримати, тільки зайшовши в систему під паролем адміністратора. Дане обмеження введено для гарантованого збереження цілісності даних, захисту їх від несанкціонованого доступу.
5. Керівництво програміста
5.1. Інсталяція системи
Інсталяція та налаштування системи проводиться фахівцями АСУ Сургутгазпрому. Програма інсталяції системи являє собою типову програму установки додатків для Windows 95, забезпечену великою кількістю підказок, що мінімізувала ручне введення даних користувача, шляхом надання йому вибору потрібних опцій установки за допомогою інтуїтивно зрозумілих засобів діалогу.
У процесі установки програма запропонує вибрати шлях на диску, за яким будуть копіюватися виконувані і конфігураційні файли програмного комплексу. За замовчуванням він буде встановлений в каталог Program FilesNp_W
Після того, як необхідний шлях буде вказано, відбудеться копіювання файлів. Програма створить Робочу групу "Платник податку" в кнопці "Пуск", увійшовши до якої можна буде виявити однойменний ярлик, який посилається на файл запуску в роботу системи "Платник податку". Аналогічний ярлик буде автоматично створений на робочому столі. Драйвери для роботи з БД і всі необхідні налаштування будуть встановлені автоматично.
По закінченню копіювання файлів програма установки запропонує закінчити свою роботу. Після цього можна приступати до роботи з комплексом.
5.2. Налаштування системи
Налагодження системи полягає в прописці шляхів доступу до баз даних АРМів заробітна плата, встановлених у підрозділах, а також у розподілі прав доступу до даних (повний, доступне для редагування, тільки для читання, гість-демонстрація, працюють тільки деякі режими). Для даної мети використовуються відповідні пункти в меню "Сервіс".
шляхи доступу;
установка паролів доступу.
На рисунку 19 наведено відеокадр роботи системи в режимі налаштування шляхів доступу до баз підрозділів.
5.3 Службові функції роботи з базою даних
5.3.1. Резервне копіювання баз даних
Резервне копіювання даних залишається актуальним, незважаючи на такі способи збереження цілісності даних в критичних ситуаціях роботи з базою даних, як ведення системного журналу, контроль цілісності бази за допомогою обмежень посилальної цілісності, тригерів і т.п.
Справа в тому, що в результаті непередбачених обставин: типу пожежі в серверній або навмисного втручання, інформація може бути повністю знищена, що може призвести до неприємних наслідків, як для окремих осіб, так і для підприємства в цілому. Для максимально швидкого відновлення даних у таких ситуаціях застосовуються резервні копії. Практика показує, що бажано мати дві копії.
У даній системі режим резервного копіювання баз даних також передбачений. Також, у зв'язку з великим обсягом бази даних, користувачу надана можливість самому вибрати типи даних для резервного копіювання (особові рахунки, різні довідники тощо).
На користь періодичного створення резервної копії і відновлення бази даних з неї говорить також сама структура бази даних у InterBase. База даних в якому складається з пронумерованих з 0 сторінок фіксованого розміру. InterBase розташовує на одній сторінці БД версії одного запису таблиці БД. Після видалення записів на сторінці утворюються дірки. При додаванні нового запису аналізується розмір максимальної дірки, якщо він менше довжини запису, який додається, то відбувається компресія сторінки, в процесі якої дірки об'єднуються. Якщо простору, що звільнився не вистачає, то запис записується з нової сторінки. Виділення сторінок ніяк не оптимізовано. При тривалій роботі з базою це призводить до високої фрагментації БД і як наслідок - до уповільнення роботи з нею. Тому необхідно періодично проводити дефрагментацію бази.
InterBase автоматично проводить її через 20000 (транзакцій), але цей спосіб обробляє тільки ті версії записів, для яких немає активних транзакцій.
Тому більш реальним є другий спосіб, який полягає у збереженні БД на дисковому носії і наступному її відновлення з резервної копії. Даний спосіб гарантує повну дефрагментацію, тому що при збереженні та відновленні БД не може бути активних транзакцій.
5.3.2. Реіндексація баз даних
У керівництві програміста не прийнято зупинятися на речах тривіальних, тому я не буду поширюватися тут про необхідність і корисність використання індексів у роботі з БД.
Режим призначений для перебудови індексних файлів у разі їх пошкодження або розбалансованості.
Індекси можуть бути розбалансовані після багаторазового внесення змін до таблиці БД. Це призводить до того, що глибина індексу зростає понад критичного значення, що різко знижує його цінність.
5.4. Коротка інформація для програмістів про базу даних
Тип бази - INTERBASE
Ім'я адміністратора - SYSDBA
Пароль - masterkey
Мовний драйвер - Pdox ANSI Cyrillic
Режим відкриття - READ / WRITE
Структури таблиць, тригерів, переглядів та індексів БД, наведені у додатку 3 у вигляді SQL програми. Це зроблено для зручності редагування структур бази.
Додаток 1
1. Загальні відомості
Повне найменування розроблюваного АРМа: "Автоматизоване робоче місце" Платник податку "працівника відділу податкової політики, здійснює збір інформації про доходи платників податків з об'єднання, контролюючого нарахування прибуткового податку і виробляє звіти для ДПІ РФ".
1.1. Розробник і найменування підприємства замовника
АРМ розробляється студентом п'ятого курсу Донецького Державного Технічного Університету на замовлення цеху виробничо-господарської діяльності Виробничо Технічного Підприємства "Сургутгазенергоремналадка" ВАТ "Сургутгазпром".
1.2. Мета створення АРМу
Мета створення системи: забезпечити виконання вимог законодавства щодо звітності з прибуткового податку, автоматизувати процес виробництва звітності до ДПІ РФ.
1.3. Призначення АРМа
АРМ "Платник податку" призначений для виконання поточних робіт працівника відділу податкової політики, таких як:
збір зі структурних підрозділів підприємства інформації про заробітну плату за період;
збір зі структурних підрозділів підприємства інформації про утриманий прибутковий податок платі за період;
перевірка правильності утримання прибуткового податку в підрозділі;
підготовка і заповнення звітів до ДПІ РФ на паперових та носіях;
здача інформації про нараховану заробітну плату та утриманий прибутковий податок у податкову інспекцію на магнітному носії;
формування і видача індивідуальних довідок фізичним особам;
висновок стандартних звітів;
архівування та відновлення даних.
2. Характеристика об'єкта автоматизації
Автоматизації підлягають:
відділ податкової політики ВАТ "Сургутгазпром";
відділи бухгалтерій структурних підрозділів.
При розробці системи варто також враховувати найбільш характерні особливості об'єктів автоматизації:
територіальну роз'єднаність;
специфіку дії трудового законодавства в північних територіях;
наявність на об'єкті автоматизації чинного програмного забезпечення.
3. Вимоги до АРМу
АРМ "Платник податку" повинен бути реалізований на програмно-технічних засобах, сумісних із загальною концепцією АСУ підприємства. Обов'язковою вимогою до цього АРМу є коректна обробка їм даних, що містяться в базах даних програм, що застосовуються для розрахунку заробітної плати в структурних підрозділах ВАТ "Сургутгазпром".
3.1. Вимоги до функцій, виконуваних АРМом
АРМ повинен забезпечувати виконання таких функцій:
налаштування системи на параметри конкретного робочого місця (список користувачів системи, права доступу до інформації, використовувані технічні засоби, шляхи доступу до АРМам розраховувачів заробітної плати, спосіб передачі інформації до вищестоящої організації, прийняті форми документів і т.д.);
виконання стандартних параметричних запитів до бази даних з можливістю відображення знайденої інформації на екрані, формування друкарських форм (довідки, звіти) за стандартними запитами;
формування вихідних даних для податкової інспекції, вищестоящої організації;
занесення інформації в базу даних з можливістю її перегляду на екрані;
резервне копіювання бази даних.
3.2. Вимоги до видів забезпечення
3.2.1. Вимоги до організаційного забезпечення
Структура програмно-інформаційного забезпечення в цілому повинна визначатися взаємовідносинами між структурними підрозділами ВАТ "Сургутгазпром". Організаційне забезпечення діяльності колективу працівників бухгалтерії, що займаються податками, повинно бути реалізовано у вигляді самостійних автоматизованих робочих місць.
Запуск модулів у Армі повинен здійснюватися через меню АРМу, пункти якого відповідають конкретним функціональним завданням.
Доступ до інформації має визначатися правами користувачів системи. Повинна бути розроблена система допуску, що дозволяє обмежити права користувачів по групах:
тільки перегляд інформації;
можливість редагувати базу даних;
перегляд (редагування частини даних).
3.2.2. Вимоги до програмного забезпечення
АРМ "Платник податку" повинен бути реалізований на програмно-технічних засобах, сумісних із загальною концепцією АСУ підприємства. Обов'язковою вимогою до цього АРМу є коректна обробка їм даних, що містяться в базах даних програм, що застосовуються для розрахунку заробітної плати в структурних підрозділах ВАТ "СургутГазПром".
Звіти, форми введення і процедури обробки інформації повинні бути розроблені інструментальними засобами мови програмування Borland Delphi 4.0 з використанням СУБД InterBase v5.0.
Продукт повинен бути розроблений під операційну систему Microsoft Windows 95 або вище, мережеве програмне забезпечення Microsoft.
Додаток 2
Приклад подання інформації про доходи на магнітному носії
ІдФайл: 7707123456 ** 980110150011
ТіпІнф: ДОХІД
НаімОтпрЮЛ: ВАТ Сургутгазпром
ТелОтпр :235-95-84
АдрОтпр:, 646400,77, Миру ВУЛ, 10,
ДолжнОтпр: БУХГАЛТЕР
ФІООтпр: МЕЛЬНИК ОЛЕКСАНДР СЕРГІЙОВИЧ
КолДок: 123
ВерсПрог:
ІдДок: 7707123456 ** 9700000001
ДатаДок: 10.06.1999
ІННФЛ: 770712345678
ПІБ: ПУСЬ, ІРИНА, ВІКТОРІВНА
УдЛічн: 01, Х1-ФР 178469
ДатаРожд: 05.11.1955
АдрМЖ:, 626400,36,,,, ОСТРОВСЬКОГО ВУЛ, 1,, 27
СтатусФЛ: 1
МестоДох: 1
ПеріодДох: 111000110001
ДоходМес: 10000.00,10000.00,10000.00,0.00,0.00,0.00,15000.00,
5000.00,0.00,0.00,0.00,10000.00
ДоходВід: 0200,50000.00,0,0.00; 3100,10000.00,02,10000.00
Відрахування: 10,600.00; 11,100.00; 41,400.00
СкідСумм: 10000.00
ВичСумм: 1000.00
ВалСумм: 60000.00
ОблСумм: 49000.00
ОблСуммНалІс: 5880.00
ОблСуммНалУд: 5880.00
НадСумм: 10000.00
НадОбл: 9900.00
НадОблНалІс: 1188.00
НадОблНалУд: 1188.00
ВигСумм: 500.00
ВигОбл: 500.00
ВигОблНалІс: 75.00
ВигОблНалУд: 75.00
ВзискГНІ: 100.00
Додаток 3
SQL програма створює базу даних системи
create table Org (
KeyOrg char (3) Not Null,
NameOrg char (254) Not Null,
Primary Key (KeyOrg));
create table Config (
CurrYear Integer,
CurrOrg Char (3),
ServerWay Char (254),
Tab_Start Char (5),
Tab_End Char (5),
God_Start Char (4),
Mes_Start Char (2),
God_End Char (4),
Curr_User Char (25),
Mes_End Char (2),
CONSTRAINT PO_KeyOrg7
FOREIGN KEY (CurrOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create table Users (
User_ Char (25),
Pasword Char (25),
Type SmallInt)
create table RabPlaces (
KeyOrg Char (3) not Null,
NameRabPlace Char (254) Not Null,
Way Char (254) Not Null,
CONSTRAINT PO_KeyOrg6
FOREIGN KEY (KeyOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create table FIO (
Tab Char (5),
Fio Char (100),
Zeh Char (2),
Ych Char (2),
Kat Char (2),
Oklad Float,
Sist_Opl Char (1),
Prin Date,
Yvol Date,
Skidka SmallInt,
Sovmest Char (1),
Inostr SmallInt,
Prof Char (2),
Deti SmallInt,
Ijd SmallInt,
Dolgn Char (2),
KeyOrg char (3));
create table Nach (
Tab Char (5) Not Null,
KeyOrg char (3) Not Null,
Kod char (3) Not Null,
Data_M Char (2),
Data_G Char (4) Not Null,
Symma Float,
Data_Ras_M Char (2),
Data_Ras_G Char (4) Not Null,
Data_R Char (4),
CONSTRAINT PO_KeyOrg8
FOREIGN KEY (KeyOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create table Ud (
Tab Char (5) Not Null,
KeyOrg char (3) Not Null,
Kod char (3) Not Null,
Data_M Char (2),
Data_G Char (4) Not Null,
Symma Float,
Data_Ras_M Char (2),
Data_Ras_G Char (4) Not Null,
Data_R Char (4),
CONSTRAINT PO_KeyOrg9
FOREIGN KEY (KeyOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create table Data (
KeyOrg char (3) Not Null,
Tab Char (5) Not Null,
Fami Char (25),
Nami Char (15),
Otch Char (15),
Dat_R Date,
Docum Char (2),
SerDoc Char (10),
NomDoc Char (6),
KVID Char (32),
Dvid Date,
Str Char (3),
PostInd Char (6),
Obl Char (4),
Raion Char (15),
Gorod Char (20),
Punct Char (25),
Ulica Char (25),
Dom Char (13),
Korp Char (10),
KV Char (10),
Tel Char (10),
Katp Char (4));
CREATE INDEX FAMILY ON DATA (FAMI);
CREATE INDEX tab_sum_n ON nach (tab, symma);
CREATE INDEX tab_sum_u ON ud (tab, symma);
CREATE INDEX zeh ON zeh (zeh);
CREATE INDEX ych ON ych (ych);
create table Zeh (
Zeh Char (2) not null,
KeyOrg char (3) Not Null,
Naim Char (25) not null,
CONSTRAINT PO_KeyOrg3
FOREIGN KEY (KeyOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create table Ych (
Ych Char (2) not null,
KeyOrg char (3) Not Null,
Zeh Char (2) not null,
Naim Char (15) not null,
CONSTRAINT PO_KeyOrg4
FOREIGN KEY (KeyOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create trigger kaskad_ych for zeh
Active
After
Update
As
begin
if (old.zehnew.zeh) then
Update Ych
Set Zeh = new.Zeh
Where Zeh = Old.Zeh;
end
create table Kat (
Kat Char (2) not null,
Naim Char (15) not null,
Primary Key (Kat));
create table Sist_Opl (
Sist_Opl Char (1) not null,
Naim Char (30) not null,
Primary Key (Sist_Opl));
create table Prof (
Prof Char (2) not null,
Naim Char (20) not null,
Primary Key (Prof));
create table Dolgn (
Dolgn Char (2) not null,
Naim Char (20) not null,
Primary Key (Dolgn));
create table Strana (
Str Char (2) not null,
Strana Char (15) not null,
Primary Key (Str));
create table Oblast (
Obl Char (2) not null,
Oblast Char (30) not null,
Primary Key (Obl));
create table Kat_Plat (
KatP char (2) not null,
naim Char (35) not null,
Primary Key (KatP));
create table Docum (
Docum char (2) not null,
naim Char (75) not null,
Primary Key (Docum));
CREATE TABLE Minim (
Data date NOT NULL,
Minim Char (10) not null,
PRIMARY KEY (Data));
create table MLV (
Tab Char (5) Not Null,
KeyOrg char (3) Not Null,
Date_Nach Char (4),
For_Nal Float,
Sum_Nal Float,
Sum_Pens Float,
Skidka SmallInt,
Sum_RK_SN Float,
Nal_RC_SN Float,
Sum_Pens_RK_SN Float,
Lgot Float,
Lgot_RK_SN Float,
Mat_Pom Float,
Pr_Vkl Char (1),
Deti SmallInt,
Ijd SmallInt,
Zen_Pod Float,
Sum_Vig Float,
Nal_Vig Float,
CONSTRAINT PO_KeyOrg5
FOREIGN KEY (KeyOrg) REFERENCES Org (KeyOrg) ON UPDATE CASCADE);
create table SHK_SKID (
God Char (4) Not Null,
Summa_End Char (15) Not Null,
Koef SmallInt Not Null);
create table SHKALA (
God SmallInt Not Null,
Dox1 Char (15) Not Null,
Dox2 Char (15) Not Null,
Pr SmallInt Not Null,
Nal Char (15),
Use_3_Proz Char (1));
create table Type_Nach (
Kod Char (3) not Null,
Naim Char (254) Not Null,
Inp Char (1),
Primary KEY (Kod))
create table Type_Ud (
Kod Char (3) not Null,
Naim Char (254) Not Null,
Primary KEY (Kod))
create table imput_podoh (
kod char (3),
inp char (1))
declare external function sh_date_to_y cstring (4)
returns cstring (4)
entry_point "sh_date_to_y"
module_name "my_funct"
declare external function sh_date_to_m cstring (4)
returns cstring (2)
entry_point "sh_date_to_m"
module_name "my_funct"
create trigger corr_date for nach
Active
Before
Insert
As
begin
New.Data_M = sh_date_to_m (New.Data_G);
New.Data_G = sh_date_to_y (New.Data_G);
New.Data_Ras_M = sh_date_to_m (New.Data_Ras_G);
New.Data_Ras_G = sh_date_to_y (New.Data_Ras_G);
end
create trigger int_nach for Nach
Active
Before
Insert
As
begin
New.Gen = Gen_Id (Numb_Nach, 1);
end
CREATE GENERATOR Numb_Nach;
SET GENERATOR Numb_Nach TO 1;
CREATE GENERATOR Numb_Ud;
SET GENERATOR Numb_Ud TO 1;
create view nach_01 (tab_, data_ras_m_, data_ras_g_, sum_)
as
select tab, data_ras_m, data_ras_g, sum (symma) as sum_n
from nach
group by tab, data_ras_m, data_ras_g
create view ud_01 (tab_, data_ras_m_, data_ras_g_, sum_)
as
select tab, data_ras_m, data_ras_g, sum (symma) as sum_u
from ud
group by tab, data_ras_m, data_ras_g
create view fio_01 (tab_, fio_, zeh_, ych_, prin_, yvol_)
as
select tab, fio, zeh, ych, prin, yvol
from fio
group by tab_, fio_, zeh_, ych_, prin_, yvol_
create view fio_02 (ych_, deal_tab_)
as
select ych, count (tab) as deal_tab
from fio
group by ych_
create view zeh_01 (zeh_, naim_)
as
select zeh, naim
from zeh
group by zeh, naim
create view ych_01 (ych_, zeh_, naim_)
as
select ych, zeh, naim
from ych
group by ych, zeh, naim
create view nach_04 (data_, sum_, kat_)
as
select data_ras_m, sum (symma), fio.kat
from nach, fio
where nach.tab = fio.tab
group by data_ras_m, fio.kat
create view nach_03 (data_, data__)
as
select data_ras_m_, count (data_ras_m_)
from nach_01
group by data_ras_m_
create view nach_05 (data_ras_m_, sum_)
as
select data_ras_m, sum (symma/100000)
from nach
group by data_ras_m