Разработка системи з збору информации

Тип работы:
Реферат
Предмет:
Информатика, программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Разработка системи з збору інформації про доходи фізичних осіб на формування податкових документів і майже звітності для податкової служби з об'єднання «Сургутгазпром».

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

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

сразу після введення, дані можуть брати участь у різних операціях;

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

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

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

позволяет швидко й у найкращому конкретної людини вигляді переглянути дані, що підвищує їх сприйняття.

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

Поэтому 15 червня 1998 року прийнята чергова редакція інструкції в державній податковій служби Російської Федерації № 35 від 29 червня 1995 года. Відповідно до якої, з 01 березня 1999 року всі підприємства з кількістю працюючих понад 100 людина зобов’язані надавати дані про доходи своїх працівників у податкову інспекцію на магнітних носіях, причому у суворо обговореному форматі. (див. Додаток 2)

На практиці ж податкова інспекція вимагає надання даних на магнітних носіях організаціями, із загальною чисельністю працюючих понад двадцять людина.

В зв’язки України із вище викладеним, у великих підприємств і об'єднань виникла гостра потреба у відповідному програмне забезпечення. Пропоноване податкової службою цих цілей ПО, забезпечує імпорт даних тільки з конкретної, надто поширеній програми Best-4, розробленої фірмою «Интеллект-Сервис».

Предприятия об'єднання «СургутГазПром» нині працюють із двома різними програмними продуктами, призначеними розрахунку заробітної плати обліку інших доходів платників податків;

комплекс «Заробітну плату», розроблений «АСУ-Партнер»;

АРМ з обліку праці та зарплати (ВАТ Автоматика).

Оба цих комплексу не підтримують надання звітів до податкової інспекції на магнітних носіях, і з обмеженості використовуваної СУБД (FoxPro v.2. 6(Х)) неспроможні єдину базу з усього об'єднанню. Тому поставили завдання, розробити програмний продукт, який був би у стані:

вести єдину базі даних про доходи фізичних осіб із всьому об'єднанню;

выдавать звітів у податкову інспекцію на магнітному носії;

выдавать інші необхідні звіти про нарахуваннях, удержаниях платників податків на паперових носіях, зокрема динаміку нарахувань і утримань, як у всьому об'єднанню, і за окремими категоріями осіб;

обрабатывать довільні запити користувача до бази даних;

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

поддерживать ручний введення і коригування інформації;

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

отвечать сучасним вимогам по швидкодії, эргономичности, використовувати сучасну СУБД із можливістю заміни в ще більше сучасну у майбутньому;

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

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

Діяльність:

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

даются структури баз даних, використовуваної програмою;

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

До дипломної роботі додається демонстраційна програма, виконана на Borland Delphi 4.0 з допомогою СУБД InterBase v 5.0 і представлена на дискеті 3,5″.

1. Огляд існуючих аналогів

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

1.1. Турбо бухгалтер

Программа Турбо Бухгалтер розроблена науково — дослідницьким центром ДІЦ. Найбільш рання з його версій, із якими я мав справу — версія 3.0.

Программа варта ведення синтетичного і аналітичного бухгалтерського обліку за всіма розділами. Аналітичний облік ведеться за об'єктах аналітичного обліку (аналітичним ознаками) в натуральному і вартісному висловлюваннях.

Ее характерною рисою, є дуже розвинений внутрішній мову, що включає у собі понад сто операторів, перемінні, розвилки, і з 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 Гбайт;

максимальное число таблиць лише у БД 65 536;

максимальное число полів лише у таблиці 1000;

максимальное кількість записів лише у таблиці необмежена;

максимальная довжина записи 64К (беручи до уваги полів BLOB);

максимальная довжина поля 32К (крім полів BLOB — не обмежена);

максимальное кількість індексів у однієї БД 65 536.

Дополнительно у процесі розробки застосовувалися такі програмні пакети і вони інструментальні кошти:

Пакет InstallShield Express — до створення комплекту дистрибутивных дискет.

Для підготовки документації, рекламного аркуша" й демонстраційної версії програм використовувалися програми, що входять до комплект Microsoft Office 97.

3.3. Рішення комплексу технічних засобів

3.3.1. Вибір критеріїв відбору технічних засобів

Среди всього безлічі критеріїв відбору МС нас цікавлять:

достаточный обсяг оперативного запоминающего устрою;

достаточный обсяг нагромаджувача на жорсткому магнітному диску;

приемлемый тип видеоадаптера і дисплея до роботи користувача;

достаточная продуктивність центрального процесора;

наличие можливості виведення інформації на паперовий, магнітний носій;

достаточная швидкість передачі в ЛВС;

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

3.3.2. Розрахунок необхідних ресурсів, для функціонування системи, вибір МС

Объем необхідного ОЗУ розраховується, з розмірів пам’яті, займаній загружаемой операційній системою, з необхідного обсягу пам’яті, який виділяється під драйвери обслуговування ЕОМ, программы-оболочки, основного загружаемого модуля програмного комплексу, динамічних бібліотек, подгружаемых принаймні виконання програми розвитку й резерву пам’яті в обробці інформації.

зважаючи на викладене, приходимо, що з нормальної роботи серверної частини системи необхідно щонайменше 64 Мбайт ОЗУ (128 Мбайт рекомендується). За сучасними поняттям, це не є занадто високе вимога пояснюється лише тим, що з нормальної роботи обраної як ОС серверної частини системи Windows NT v. 4.0 необхідно щонайменше 32 Мбайт оперативної пам’яті. З іншого боку, враховуючи великий обсяг бази даних, понад сто Мбайт і можливість многопользовательского доступу для оперативної роботи серверу треба ще щонайменше 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 і п’яти продемонстровані відеокадри з АС з варіантами результатів.

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

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), таблиці шкали податку, таблиці з сумами мінімальних окладів, таблиці з коефіцієнтами пільг даних про начислениях/удержаниях, вироблених по фізичних осіб.

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

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 автоматично проводить її через 20 000 (транзакцій), але цей спосіб обробляє ті версії записів, котрим немає активних транзакцій.

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

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

Приклад подання про доходи на магнітному носії

ИдФайл: 7 707 123 456**980 110 150 011

ТипИнф: ДОХОД

НаимОтпрЮЛ: ОАО Сургутгазпром

ТелОтпр: 235−95−84

АдрОтпр:, 646 400,77,Мира У Л, 10,

ДолжнОтпр: БУХГАЛТЕР

ФИООтпр: МЕЛЬНИК ОЛЕКСАНДР СЕРГЕЕВИЧ

КолДок: 123

ВерсПрог:

ИдДок: 7 707 123 456**9 700 000 001

ДатаДок: 10. 06. 1999

ИННФЛ: 770 712 345 678

ФИО: ПУСЬ, ИРИНА, ВИКТОРОВНА

УдЛичн: 01, Х1-ФР 178 469

ДатаРожд: 05. 11. 1955

АдрМЖ:, 626 400,36,ОСТРОВСКОГО УЛ, 1,27

СтатусФЛ: 1

МестоДох: 1

ПериодДох: 111 000 110 001

ДоходМес: 10 000. 00,10 000. 00,10 000. 00,0. 00,0. 00,0. 00,15 000. 00,

5000. 00,0. 00,0. 00,0. 00,10 000. 00

ДоходВид: 0200,50 000. 00,0,0. 00;3100,10 000. 00,02,10 000. 00

Вычет: 10,600. 00;11,100. 00;41,400. 00

СкидСумм: 10 000. 00

ВычСумм: 1000. 00

ВалСумм: 60 000. 00

ОблСумм: 49 000. 00

ОблСуммНалИс: 5880. 00

ОблСуммНалУд: 5880. 00

НадСумм: 10 000. 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),

Use3_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 nach01 (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 ud01 (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 fio01 (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 fio02 (ych_, deal_tab_)

as

select ych, count (tab) as deal_tab

from fio

group by ych_

create view zeh01 (zeh_, naim_)

as

select zeh, naim

from zeh

group by zeh, naim

create view ych01 (ych_, zeh_, naim_)

as

select ych, zeh, naim

from ych

group by ych, zeh, naim

create view nach04(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 nach03(data_, data__)

as

select data_ras_m_, count (data_ras_m_)

from nach01

group by data_ras_m_

create view nach05(data_ras_m_, sum_)

as

select data_ras_m, sum (symma/100 000)

from nach

group by data_ras_m

ПоказатьСвернуть
Заполнить форму текущей работой