Основними принципами і цілями внутрішньофірмових систем інформації є:

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

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

• визначення потреб у технічних засобах (в тому числі, в комп'ютерній техніці) на підприємстві в цілому;

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

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

• автоматизація адміністративно-управлінської праці на основі використання комп'ютерної техніки.

Важливими завданнями внутрішньофірмової системи управління є:

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

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

• визначення основних напрямків розвитку технології обробки інформації.

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

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

4 Порядок нарахування амортизаційних відрахувань

Відшкодування балансової вартості (первісної або відновної) вартості основних фондів підприємств здійснюється шляхом включення амортизаційних відрахувань за затвердженими єдиними нормами у витрати виробництва. Підставою для нарахування суми амортизації є довідка про вартість зазначених об'єктів або їх частин за даними обліку капітальних вкладень [1]. Формула розрахунку суми амортизаційних відрахувань на основні фонди.

1. Місячна амортизація:

МесАморт = (БалСтоім * Відсоток) / 12/100,

де:

• МесАморт - місячна амортизація;

• БалСтоім - балансова вартість основних фондів;

• Відсоток - відсоток амортизаційних відрахувань для даного виду обладнання.

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

2. Повна сума амортизаційних відрахувань:

ПолнАморт = МесАморт * КолвоМес,

де:

• ПолнАморт - повна сума амортизаційних відрахувань;

• МесАморт - сума місячної амортизації;

• КолвоМес - кількість місяців з моменту введення в експлуатацію обладнання, до поточного звітного місяця.

3. Залишкова вартість:

ОстСтоім = БалСтоім-ПолАморт,

де:

• ОстСтоім - залишкова вартість;

• БалСтоім - балансова вартість основних фондів;

• ПолнАморт - повна сума амортизаційних відрахувань.

Нарахування амортизаційних відрахувань по основних фондах, по знову введеним в експлуатацію, нараховується з першого числа, наступного за місяцем їх введення в експлуатацію, а по вибулим основним фондам - ​​припиняється з першого числа місяця, наступним за місяцем вибуття [2].

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

4. Повна вартість амортизації для автотранспорту:

ПолнАморт = (БалСтоім * 0,481) / 1000 * КМ,

де:

• ПолнАморт - повна вартість амортизаційних відрахувань з дня введення автотранспортного засобу в експлуатацію;

• БалСтоім - балансова вартість;

• КМ - фактичне значення пробігу.

За повністю замортизованих основних фондів нарахування амортизації припиняється з першого числа місяця, наступного за останнім місяцем, в якому вартість цих фондів повністю була перенесена на вартість продукції [1].

Варіант реалізації розрахунків на мові Pascal:

1. Звичайне обладнання (що не є автотранспортним засобом):

DataModule1.Table6.Edit;

MonthIn: = StrToInt (Copy (DateTimeToStr (DataModule1.Table6Data_vvod.Value), 4,2));

YearIn: = StrToInt (Copy (DateTimeToStr (DataModule1.Table6Data_vvod.Value), 7,4));

YearOut: = StrToInt (AHMSpinEdit1.Text);

SumMonth: = (YearOut-YearIn) * 12 + (MesNumber-MonthIn);

DataModule1.Table6Mes_amort.Value: = StrToFloat (FormatFloat ('0 .00 ', DataModule1.Table6Procent.Value * DataModule1.Table6Bas_Stoim.Value/12/100));

DataModule1.Table6Pol_iznos.Value: = StrToFloat (FormatFloat ('0 .00 ', SumMonth * DataModule1.Table6Mes_amort.Value));

DataModule1.Table6Ost_stoim.Value: = StrToFloat (FormatFloat ('0 .00 ', DataModule1.Table6Bas_Stoim.Value-DataModule1.Table6Pol_iznos.Value-DataModule1.Table6Old_amortiz.Value));

DataModule1.Table6.Post;

2. Автотранспортний засіб:

DataModule 1. Table 6. Edit;

DataModule1.Table6Pol_iznos.Value: = (DataModule1.Table6Bas_Stoim.Value * 0.481) / 1000 * DataModule1.Table6KMetrash.Value;

DataModule1.Table6Ost_stoim.Value: = StrToFloat (FormatFloat ('0 .00 ', DataModule1.Table6Bas_Stoim.Value-DataModule1.Table6Pol_iznos.Value));

DataModule1.Table6.Post;

3. У разі якщо обладнання повністю замортизовано:

DataModule1.Table6.Edit;

IF DataModule1.Table6Pol_iznos.Value> DataModule1.Table6Bas_Stoim.Value Then Begin

DataModule1.Table6Mes_amort.Value: = 0;

DataModule1.Table6Pol_iznos.Value: = DataModule1.Table6Bas_Stoim.Value;

DataModule1.Table6Ost_stoim.Value: = 0;

End;

IF DataModule1.Table6Ost_Stoim.Value <0 Then Begin

DataModule1.Table6Mes_amort.Value: = 0;

DataModule1.Table6Pol_iznos.Value: = DataModule1.Table6Bas_Stoim.Value;

DataModule1.Table6Ost_stoim.Value: = 0;

End;

DataModule1.Table6.Post;

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

5 Алгоритм розрахунку сум амортизаційних відрахувань

Для розрахунку сум амортизаційних відрахувань необхідно скористатися алгоритмом.

1. Обнуляємо змінну дати закриття звітного місяця.

2. Вводимо значення дати закриття звітного місяця.

3. Переводимо покажчик записи бази даних «Osnova.DB», на початок таблиці.

4. Відключаємо зв'язок з таблицею «Uhastoc.DB».

5. Переводимо таблицю «Osnova.DB» у монопольний режим.

6. Переводимо таблицю в режим редагування (Edit).

7. Перевіряємо якщо таблиця порожня, якщо «ТАК» то переходимо до пункту (16), якщо «НІ», то переходимо до пункту (8).

8. Перевіряємо кінець таблиці, якщо «Так» то переходимо до пункту (16), якщо «НІ», то переходимо до пункту (9).

9. Перевіряємо, є запис забороненої на перерахунок, якщо «ТАК», то переходимо до пункту (13), якщо «НІ», то переходимо до пункту (10).

10. Перевіряємо, який тип обладнання, якщо «Автотранспорт», то переходимо до пункту (11), якщо «Звичайний», то виконуємо:

• визначаємо значення місячної амортизації, шляхом множення балансової вартості обладнання на відсоток амортизації, отримане значення розділимо на 12 і на 100;

• записуємо отримане значення в таблицю;

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

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

• записуємо отримане значення в таблицю;

• визначаємо значення залишкової вартості, віднявши з балансової вартості значення суми повної амортизації;

• запишемо отримане значення в таблицю і переходимо до пункту (11).

11. Перевіряємо, який тип обладнання, якщо «Звичайний», то переходимо до пункту (11), якщо «Автотранспорт», то виконуємо:

• визначаємо значення повної суми амортизації, шляхом множення балансової вартості на коефіцієнт 0,481, розділимо отримане значення на 1000 і помножимо на пробіг автотранспорту;

• записуємо отримане значення в таблицю;

• визначаємо значення залишкової вартості, віднявши з балансової вартості значення суми повної амортизації;

• запишемо отримане значення в таблицю і переходимо до пункту (12).

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

• обнулити показники місячної амортизації;

• повний знос прирівняємо з балансовою вартістю;

• значення залишкової вартості прирівняємо до 0;

• запишемо отримані дані в таблицю.

13. Перевіряємо якщо значення залишкової вартості менше ніж 0, то:

• обнулити показники місячної амортизації;

• повний знос прирівняємо з балансовою вартістю;

• значення залишкової вартості прирівняємо до 0;

• запишемо отримані дані в таблицю.

14. Переводимо таблицю в режим збереження даних (Post).

15. Переміщаємо покажчик бази даних на наступний запис.

16. Переходимо до початку циклу. Пункт (8).

17. Знімаємо з таблиці «Osnova.DB» монопольний режим.

18. Відновлюємо зв'язок з таблицею «Uhastoc.DB».

19. Завершуємо процедуру розрахунку.

6 Порядок нарахування сум орендної плати

Так як все використовуване обладнання є орендованим, тому нарахування сум орендної плати проводиться від імені лізингової компанії, у якої дані основні фонди знаходяться на балансі [3], за формулою:

Оренда = ((БалСтоім/100 * Відсоток) + (БалСтоім/100 * Відсоток) / 100 * КоефІзн) / 365 * КолвоДней,

де:

• Оренда - вартість орендної плати за місяць;

• БалСтоім - балансова вартість обладнання;

• Відсоток - відсоток амортизації;

• КоеІзн - коефіцієнт на знос;

• КолвоДней - кількість днів у місяці, на який здійснюється розрахунок орендної вартості.

Якщо на момент розрахунку орендної вартості основні фонди знаходиться на складі, то організація бере їх на відповідальне зберігання. У цьому випадку розрахунок орендної вартості буде виходити з того, де в даний час зберігається устаткування (на відкритому майданчику, в холодному складі, в опалювальному складі), виходячи з цього, змінюється значення коефіцієнта орендних відрахувань для обладнання знаходиться у відповідальному зберіганні [2]. Тоді формула розрахунку вартості орендної плати буде виглядати:

Оренда = КоефОтвХран * Обсяг * КолвоДней,

де:

• КоефОтвХран - коефіцієнт розрахунку орендної вартості при відповідальному зберіганні;

• Обсяг - об'єм займаний на складі;

• КолвоДней - кількість днів у звітному місяці.

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

Варіант реалізації розрахунків на мові Object Pascal:

DataModule1.Table6.Edit;

IF DataModule1.Table6Arenda.Value = 'Оренда' Then Begin

X: = DataModule1.Table6Bas_stoim.Value/100 * DataModule1.Table6Procent.Value;

Y: = X/100 * Coofic.AHMRealSpinEdit5.Value;

DataModule1.Table6SunAnda.Value: = (X + Y) / 365 * AHMSpinEdit1.Value;

End;

IF DataModule1.Table6Arenda.Value = 'Відповідь - зберігання'; Then Begin

IF DataModule1.Table6Sclad.Value = '1 'Then X: = Coofic.AHMRealSpinEdit1.Value;

IF DataModule1.Table6Sclad.Value = '2 'Then X: = Coofic.AHMRealSpinEdit2.Value;

IF DataModule1.Table6Sclad.Value = '3 'Then X: = Coofic.AHMRealSpinEdit3.Value;

IF DataModule1.Table6Sclad.Value = '4 'Then X: = Coofic.AHMRealSpinEdit4.Value;

DataModule1.Table6SunAnda.Value: = X * DataModule1.Table6KovMetr.Value * AHMSpinEdit1.Value;

End;

DataModule1.Table6.Post;

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

У разі якщо обладнання починають використовувати в організаціях субпідрядників, з цього моменту відбувається витрачання обладнання з балансу УПТК ВАТ «Бамтунельбуд», в лізингову компанію, яка і буде організацією орендодавцем.

7 Переоцінка основних фондів

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

1. Якщо сталася деномінація рубля, після чого для всіх основних фондів необхідно перерахувати балансову вартість, в цьому випадку користуємося наступними формулами.

Для випадку якщо здійснюється розподіл на підвищення вартості:

НовБалСтоім = БалСтоім + (БалСтоім/100 * Коефіцієнт),

де:

• НовБалСтоім - балансова вартість після переоцінки;

БалСтоім - балансова вартість до переоцінки;

• Коефіцієнт - коефіцієнт на переоцінку обладнання.

Для випадку якщо проводиться розрахунок на зниження вартості:

НовБалСтоім = БалСтоім-(БалСтоім/100 * Коефіцієнт),

де:

• НовБалСтоім - Балансова вартість після переоцінки;

• БалСтоім - Балансова вартість до переоцінки;

• Коефіцієнт - коефіцієнт на переоцінку обладнання.

Для переоцінки обладнання необхідно точно вказати коефіцієнти перерахунку для кожного типу обладнання (Будівлі, споруди, автотранспорт і т.д.).

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

Варіант реалізації розрахунків на мові Object Pascal:

DataModule1.Table1.Active: = False;

DataModule1.Table13.First;

While not DataModule1.Table13.Eof Do DataModule1.Table13.Delete;

IF RadioButton1.Checked = True Then Begin

DataModule1.Table6.First;

While not DataModule1.Table6.EOF Do Begin

IF DataModule1.Table6Kod.Value = '1 'Then Koof: = AHMRealSpinEdit1.Value;

IF DataModule1.Table6Kod.Value = '2 'Then Koof: = AHMRealSpinEdit2.Value;

IF DataModule1.Table6Kod.Value = '3 'Then Koof: = AHMRealSpinEdit3.Value;

IF DataModule1.Table6Kod.Value = '4 'Then Koof: = AHMRealSpinEdit4.Value;

IF DataModule1.Table6Kod.Value = '5 'Then Koof: = AHMRealSpinEdit5.Value;

IF DataModule1.Table6Kod.Value = '6 'Then Koof: = AHMRealSpinEdit6.Value;

IF DataModule1.Table6Kod.Value = '7 'Then Koof: = AHMRealSpinEdit7.Value;

IF DataModule1.Table6Kod.Value = '8 'Then Koof: = AHMRealSpinEdit8.Value;

IF DataModule1.Table6Kod.Value = '9 'Then Koof: = AHMRealSpinEdit9.Value;

IF Koof <> 0 Then Begin

DataModule1.Table13.Append;

DataModule1.Table6.Edit;

DataModule1.Table13.FieldByName ('Old_Stoim'). AsFloat: = DataModule1.Table6Bas_stoim.Value;

PolZnac: = DataModule1.Table6Bas_stoim.Value/100 * Koof;

DataModule1.Table6Bas_stoim.Value: = DataModule1.Table6Bas_stoim.Value + PolZnac;

DataModule1.Table13.FieldByName ('New_Stoim'). AsFloat: = DataModule1.Table6Bas_stoim.Value;

DataModule1.Table13.FieldByName ('Inventar'). AsString: = DataModule1.Table6Inventar.Value;

DataModule1.Table13.FieldByName ('Uhastoc'). AsString: = DataModule1.Table6Uhastoc.Value;

DataModule1.Table13.FieldByName ('DataRash'). AsDateTime: = Date;

DataModule1.Table13.Post;

DataModule1.Table6.Post;

End;

DataModule1.Table6.Next;

End;

DataModule1.Table9.First;

While not DataModule1.Table9.EOF Do Begin

IF DataModule1.Table9Kod.Value = '1 'Then Koof: = AHMRealSpinEdit1.Value;

IF DataModule1.Table9Kod.Value = '2 'Then Koof: = AHMRealSpinEdit2.Value;

IF DataModule1.Table9Kod.Value = '3 'Then Koof: = AHMRealSpinEdit3.Value;

IF DataModule1.Table9Kod.Value = '4 'Then Koof: = AHMRealSpinEdit4.Value;

IF DataModule1.Table9Kod.Value = '5 'Then Koof: = AHMRealSpinEdit5.Value;

IF DataModule1.Table9Kod.Value = '6 'Then Koof: = AHMRealSpinEdit6.Value;

IF DataModule1.Table9Kod.Value = '7 'Then Koof: = AHMRealSpinEdit7.Value;

IF DataModule1.Table9Kod.Value = '8 'Then Koof: = AHMRealSpinEdit8.Value;

IF DataModule1.Table9Kod.Value = '9 'Then Koof: = AHMRealSpinEdit9.Value;

IF Koof <> 0 Then Begin

DataModule1.Table13.Append;

DataModule1.Table9.Edit;

DataModule1.Table13.FieldByName ('Old_Stoim'). AsFloat: = DataModule1.Table9Bal_stoim.Value;

PolZnac: = DataModule1.Table9Bal_stoim.Value/100 * Koof;

DataModule1.Table9Bal_stoim.Value: = DataModule1.Table9Bal_stoim.Value + PolZnac;

DataModule1.Table13.FieldByName ('New_Stoim'). AsFloat: = DataModule1.Table9Bal_stoim.Value;

DataModule1.Table13.FieldByName ('Inventar'). AsString: = DataModule1.Table9Inventar.Value;

DataModule1.Table13.FieldByName ('Uhastoc'). AsString: = DataModule1.Table9Uhastoc.Value;

DataModule1.Table13.FieldByName ('DataRash'). AsDateTime: = Date;

DataModule1.Table13.Post;

DataModule1.Table9.Post;

End;

DataModule1.Table9.Next;

End;

End;

IF RadioButton2.Checked = True Then Begin

DataModule1.Table6.First;

While not DataModule1.Table6.EOF Do Begin

IF DataModule1.Table6Kod.Value = '1 'Then Koof: = AHMRealSpinEdit1.Value;

IF DataModule1.Table6Kod.Value = '2 'Then Koof: = AHMRealSpinEdit2.Value;

IF DataModule1.Table6Kod.Value = '3 'Then Koof: = AHMRealSpinEdit3.Value;

IF DataModule1.Table6Kod.Value = '4 'Then Koof: = AHMRealSpinEdit4.Value;

IF DataModule1.Table6Kod.Value = '5 'Then Koof: = AHMRealSpinEdit5.Value;

IF DataModule1.Table6Kod.Value = '6 'Then Koof: = AHMRealSpinEdit6.Value;

IF DataModule1.Table6Kod.Value = '7 'Then Koof: = AHMRealSpinEdit7.Value;

IF DataModule1.Table6Kod.Value = '8 'Then Koof: = AHMRealSpinEdit8.Value;

IF DataModule1.Table6Kod.Value = '9 'Then Koof: = AHMRealSpinEdit9.Value;

IF Koof <> 0 Then Begin

DataModule1.Table13.FieldByName ('Old_Stoim'). AsFloat: = DataModule1.Table6Bas_stoim.Value;

DataModule1.Table6.Edit;

PolZnac: = DataModule1.Table6Bas_stoim.Value/100 * Koof;

DataModule1.Table6Bas_stoim.Value: = DataModule1.Table6Bas_stoim.Value-PolZnac;

DataModule1.Table13.FieldByName ('New_Stoim'). AsFloat: = DataModule1.Table6Bas_stoim.Value;

DataModule1.Table13.FieldByName ('Inventar'). AsString: = DataModule1.Table6Inventar.Value;

DataModule1.Table13.FieldByName ('Uhastoc'). AsString: = DataModule1.Table6Uhastoc.Value;

DataModule1.Table13.FieldByName ('DataRash'). AsDateTime: = Date;

DataModule1.Table13.Post;

DataModule1.Table6.Post;

End;

DataModule1.Table6.Next;

End;

DataModule1.Table9.First;

While not DataModule1.Table9.EOF Do Begin

IF DataModule1.Table9Kod.Value = '1 'Then Koof: = AHMRealSpinEdit1.Value;

IF DataModule1.Table9Kod.Value = '2 'Then Koof: = AHMRealSpinEdit2.Value;

IF DataModule1.Table9Kod.Value = '3 'Then Koof: = AHMRealSpinEdit3.Value;

IF DataModule1.Table9Kod.Value = '4 'Then Koof: = AHMRealSpinEdit4.Value;

IF DataModule1.Table9Kod.Value = '5 'Then Koof: = AHMRealSpinEdit5.Value;

IF DataModule1.Table9Kod.Value = '6 'Then Koof: = AHMRealSpinEdit6.Value;

IF DataModule1.Table9Kod.Value = '7 'Then Koof: = AHMRealSpinEdit7.Value;

IF DataModule1.Table9Kod.Value = '8 'Then Koof: = AHMRealSpinEdit8.Value;

IF DataModule1.Table9Kod.Value = '9 'Then Koof: = AHMRealSpinEdit9.Value;

IF Koof <> 0 Then Begin

DataModule1.Table13.FieldByName ('Old_Stoim'). AsFloat: = DataModule1.Table9Bal_stoim.Value;

DataModule1.Table9.Edit;

PolZnac: = DataModule1.Table9Bal_stoim.Value/100 * Koof;

DataModule1.Table9Bal_stoim.Value: = DataModule1.Table9Bal_stoim.Value-PolZnac;

DataModule1.Table13.FieldByName ('New_Stoim'). AsFloat: = DataModule1.Table9Bal_stoim.Value;

DataModule1.Table13.FieldByName ('Inventar'). AsString: = DataModule1.Table9Inventar.Value;

DataModule1.Table13.FieldByName ('Uhastoc'). AsString: = DataModule1.Table9Uhastoc.Value;

DataModule1.Table13.FieldByName ('DataRash'). AsDateTime: = Date;

DataModule1.Table13.Post;

DataModule1.Table9.Post;

End;

DataModule1.Table9.Next;

End;

8 Закриття звітного місяця

Перед закриттям звітного місяця отримують всі звітні документи.

Закриття проводиться в наступному порядку.

1. Перед закриттям поточного звітного місяця проводиться розрахунок орендної вартості основних фондів у ЗАТ УПТК «Бамтунельбуд» і всіх лізингових компаніях ВАТ «Бамтунельбуд».

2. Налічується вартість орендної плати по всіх підрозділах і субпідрядним організаціям.

3. Перекладається нове обладнання в список устаткування, для перерахунку орендної плати в наступному місяці.

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

5. Формуємо звіти по руху основних фондів у звітному місяці.

9 Передача даних в 1С «Підприємство»

Для того щоб отримати повний баланс по підприємству, необхідно передати дані про стан по основних фондах в 1С «Підприємство» (1С «Бухгалтерія»), після чого зробити формування балансу підприємства.

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

1. За сформованими списками ввести проводки в 1С «Бухгалтерію», тільки в цьому випадку можливі помилки при введенні даних.

2. У програмі «Автоматизоване робоче місце бухгалтера» необхідно сформувати базу даних по руху основних фондів, до якої увійдуть дані по кожному рахунку, що використовується в поточному місяці. Прийняти дані в 1С «Підприємство», програма створить всі необхідні проводки. Після цього можна формувати баланс по підприємству в цілому.

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

Частина процедури, яка описує створення нової проводки:

СпрОписаниеКод.НайтиПоКоду (Число (Код), 0);

Операція.НоваяПроводка ();

Операція.Дебет.Субконто (1, СпрОпісаніеКод.Субконто1);

Операція.Дебет.Субконто (2, СпрОпісаніеКод.Субконто2);

Операція.Дебет.Субконто (3, СпрОпісаніеКод.Субконто3);

Операція.Кредіт.Счет = СчетПоКоду ("01")

Операция.СодержаниеПроводки = Рядок (Опис);

Операція.НомерЖурнала = "ОС"

Для реалізації цієї можливості використовувалися бази даних формату DBF, який використовується програмою 1С «Підприємство». Для того щоб створити файл у форматі DBF, довелося додати новий драйвер баз даних у Borland DataBase Engine, що дозволило передати дані в формат Dbase IV.

10 Передача даних з попередньої версії програми

Ця функція призначена для передачі даних з попередньої версії програми, що дозволяє ввести у використання нову програму, без виконання великої кількості рутинної роботи. На сьогоднішній день база даних основних засобів у ВАТ «Бамтунельбуд» перевищує 10000 записів. Для передачі даних використовуються файли баз даних програми «Osnova» у форматі Dbase IV. (Osnova.dbf, Lizing.dbf, Library.dbf).

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

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

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

У процесі автоматизації бухгалтерського обліку міні-ЕОМ використовуються, переважно для:

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

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

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

• аналізу даних про поточний стан зношеності обладнання;

• реєстрації нових надходжень обладнання;

• витрачання і продаж устаткування третім фірмам або лізинговим компаніям;

• ведення обліку та звітності.

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

12 Форми як носії інформації

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

Розрізняють такі види бланків форм: форми для зберігання інформації, форми реєстрації даних, форми статистичної (фінансової) звітності, форми обстежень.

Заповнені форми зберігаються в пам'яті ЕОМ і при необхідності можуть бути виведені на екран дисплея або отримані шляхом роздруку на принтері.

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

13 Інформаційні бази даних

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

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

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

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

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

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

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

• обчислювальний центр для обслуговування фірми в цілому;

• центральну службу інформації;

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

У випадку малого підприємства даний апарат управління, як правило, складається з двох відділів:

• відділ автоматизації (відділ програмування);

• технічний відділ (відділ мережевих розробок).

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

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

14 Реляційні бази даних

Всі системи управління базами даних призначені для зберігання і обробки інформації. Реляційний підхід до управління базами даних заснований на математичній моделі, що використовує методи реляційної алгебри та реляційного числення. Тим не менше, більшість дійсно необхідних визначень з області управління базами даних скоріше відносяться до практичної, ніж до теоретичної стороні цього питання [4].

С. Дейт дає наступне неформальне визначення системі управління реляційними базами даних (СКБД).

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

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

Др. І.Ф. Кодд, автор реляційної моделі, розробив цілий список критеріїв, яким повинна задовольняти реляційна модель. Опис цього списку, який часто називають «правилами Кодда», вимагає введення складної термінології і теоретичних викладок, що виходить за рамки даного дипломного проекту. Тим не менш, опишемо складається з 12 правил тест Кодда для реляційних систем, і будемо використовувати його разом із загальним визначенням Дейта.

Щоб вважатися реляційної, система управління базами даних повинна:

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

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

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

• підтримувати основні реляційні операції (вибір, проектування і об'єднання), а також теоретико-множинні операції, такі як об'єднання, перетин і доповнення;

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

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

• забезпечувати механізми для підтримки цілісності, авторизації, транзакцій і відновлення даних.

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

14.1 Реляційна модель: одні таблиці

Перше правило Кодда говорить, що вся інформація в реляційних базах даних представляється значеннями в таблицях (tables). У реляційних системах таблиці складаються з горизонтальних рядків (row) і вертикальних стовпців (column). Всі дані представляються в табличному форматі - іншого способу переглянути інформацію в базі даних не існує. Кілька зауважень по термінології. Оскільки такі поняття як таблиця, рядок і стовпець є загальноприйнятими в комерційних системах управління реляційними базами даних, будемо намагатися використовувати їх у цьому дипломному проекті. Однак іноді можна зустрітися і з такими поняттями, як відношення (relations), кортеж (tuple) і атрибут (attributes). Це відповідно синоніми понять таблиця, рядок і стовпець, так само, як і файл (file), запис (record) і полі (field). Перші три вважаються академічними термінами, останні - узяті із загального лексикону, використовуваного в області обробки даних. Набір пов'язаних таблиць утворює базу даних (database). Таблиці в реляційної базі розділені, але повністю рівноправні. Між ними не існує ніякої ієрархії і, взагалі кажучи, вони не обов'язково навіть фізично пов'язані один з одним [5].

Кожна таблиця складається з рядків і стовпців. Кожен рядок описує окремий об'єкт або сутність (entity) людини, компанію, торгову угоду або що-небудь інше. Кожен стовпець описує одну характеристику об'єкта-ім'я людини або його адресу, номер телефону компанії або її президента, лоти розпродажі або дату. Кожен елемент даних, або значення (value), визначається перетинанням рядка та стовпця таблиці. Щоб знайти потрібний об'єкт даних, необхідно знати ім'я містить його таблиці, стовпець і значення його первинного ключа (primary key), або унікального ідентифікатора (кожен рядок повинен єдиним чином ідентифікуватися по одному з своїх значень.)

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

14.2 Незалежність

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

Реляційна модель забезпечує незалежність даних на двох рівнях - фізичному і логічному. Фізична незалежність даних (physical data independents) означає з точки зору користувача, що подання даних абсолютно не залежить від способу їх фізичного зберігання. Як наслідок цього, фізичне переміщення даних жодним чином не може вплинути на логічну структуру бази даних і ваше сприйняття даних. Такі зміни зазвичай стають просто необхідними, особливо у великих багатокористувацьких системах. Наприклад, при нестачі місця для зберігання інформації може знадобитися установка додаткових фізичних носіїв. Коли пристрій виходить з ладу, на жаль, його доводиться швидко замінювати. Іноді може знадобитися збільшити продуктивність системи або спростити її використання, змінивши для цього методи доступу до фізичних даними [4]. (Ці методи пов'язані зі створенням стратегії доступу (access strategies) і застосуванням індексів (index).)

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

14.3 Мова високого рівня

Визначення реляційної системи, так само, як і правила Кодда, вимагає, щоб весь діалог з базою даних вівся на одній мові - іноді його називають загальним підмовою даних (comdivhensive data sublanguage). У світі комерційних систем управління базами даних такої мова отримала назву SQL. SQL використовується для маніпуляцій з даними (data manipulation) вибірки і модифікації, визначення даних (data definition) і адміністрування даних (data administration). Будь-яка операція по вибірці, модифікації, визначенню чи адміністрування виконується за допомогою оператора (statement) чи команди (command) SQL.

Є два різновиди операцій з маніпуляції з даними - вибірка даних (data retrieval) і модифікація даних (data modification). Вибірка - це пошук необхідних вам даних, а модифікація означає додавання, видалення або зміну даних. Операції по вибірці (чаші звані запитами (query)) здійснюють пошук у базі даних, найбільш ефективно витягають затребувану вами інформацію та відображають її. Інші команди SQL призначені для створення і видалення таблиць, індексів та інших об'єктів [4].

Остання категорія операторів SQL - оператори адміністрування, або команди управління даними (data control). Вони дозволяють вам координувати спільне використання бази даних і підтримувати її в найбільш ефективному стані.

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

14.4 Реляційні операції

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

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

Проектування - операція проектування дозволяє визначити системі, які стовпці таблиці повинні проглядатися. З концептуальної точки зору: операція проектування визначає підмножина стовпців в таблиці. Зверніть увагу, що результати виконання проектування (як і будь-який інший реляційної операції) також відображаються у формі таблиці. Результуючі таблиці іноді називають похідними таблицями (derived tables), щоб відрізняти їх від базових таблиць (base tables), що містять вихідні рядки даних.

Вибір - операція вибору дозволяє вам отримувати з таблиці підмножини її рядків. Щоб вказати, які рядки потрібні, відповідні умови потрібно розмістити в реченні WHERE. У пропозиції WHERE оператора SELECT визначається критерій, якому повинні відповідати обирані рядка. Можна комбінувати в запиті операції проектування і вибору, щоб отримати необхідну інформацію.

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

14.5 Альтернативний спосіб перегляду даних

Курсор (view) - це альтернативний спосіб перегляду даних з декількох таблиць. Курсори іноді називаються віртуальними таблицями (virtual tables), або похідними таблицями. Таблиці, на основі яких працюють курсори, називаються базовими таблицями. Курсор можна розглядати як переміщувану за таблицями рамку, через яку можна побачити тільки необхідну частину інформації. Курсор можна отримати з однієї або декількох таблиць бази даних (зокрема й інші курсори), використовуючи будь-які операції вибору, проектування та об'єднання. Курсори дозволяють створювати таблиці для спеціальних цілей. З їх допомогою можна використовувати результати виконання операторів вибору, проектування та об'єднання як основу для подальших запитів. Віртуальні таблиці, на відміну від «справжніх», або базових таблиць, фізично не зберігаються в базі даних. Важливо усвідомити, що курсор - це не копія деяких даних, що поміщається в іншу таблицю. Коли змінюються дані у віртуальній таблиці, то тим самим змінюються дані в базових таблицях. Подібно результатами операції вибору, курсори нагадують звичайні таблиці баз даних.

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

14.6 Нулі

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

Проблема, звичайно, полягає не в простій непривабливості подібних дірок. Небезпека полягає в тому, що через них база може стати суперечливою. Щоб зберегти цілісність даних в реляційній моделі, так само, як і в правилах Кодда, для обробки пропущеної інформації використовується поняття нуля. «Нуль» не означає порожнє поле або звичайний математичний нуль. Він відображає той факт, що значення невідоме, недоступне або не застосовується [4]. Істотно, що використання нулів ініціює перехід з двозначною логіки (так / ні або что-то/нічего) на тризначну (так / ні / може бути або що-то нічого не впевнений).

З точки зору іншого експерта з реляційних систем, Дейта, нулі не є повноцінним вирішенням проблеми пропусків інформації. Тим не менш, вони є складовою частиною більшості офіційних стандартів SQL і de facto промислових стандартів.

14.7 Безпека

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

У багатокористувацьких системах зазвичай є користувач з правами навіть більш високими, ніж у власника бази даних - системний адміністратор (system administrator), або адміністратор бази даних (database administrator). Цей користувач зазвичай володіє широкими правами на наділення повноважень, а також виконує цілий ряд інших завдань, пов'язаних з підтримкою і адмініструванням бази даних.

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

14.8 Цілісність

Цілісність (integrity) - дуже складний і серйозне питання при управлінні реляційними базами даних. Неузгодженість між даними може виникати з цілої низки причин. Неузгодженість чи суперечливість даних може виникати внаслідок збою системи - проблеми з апаратним забезпеченням, помилки в програмному забезпеченні або логічні помилки в додатках. Реляційні системи управління базами даних захищають дані від такого типу неузгодженості, гарантуючи, що команда або буде виконана до кінця, або буде повністю скасована. Цей процес зазвичай називають управлінням транзакціями (transaction management).

Інший тип цілісності, званий об'єктної цілісністю (entity integrity), пов'язаний з коректним проектуванням бази даних. Об'єктна цілісність вимагає, щоб ні один первинний ключ не мав нульового значення. Третій тип цілісності, званий посилальної цілісністю (referential integrity), означає несуперечність між частинами інформації, повторюваними в різних таблицях. Наприклад, якщо ви змінюєте неправильно введений номер розрахункового рахунку покупця в одній таблиці, інші таблиці, які містять цю ж інформацію, продовжують посилатися на старий номер, тому ви повинні оновити і ці таблиці. Надзвичайно важливо, щоб при зміні інформації в одному місці, вона відповідно змінювалася і у всіх інших місцях [2]. Правила Кодда свідчать, що системи управління реляційними базами даних повинні забезпечувати не тільки об'єктну і посилальну цілісність, але і дозволяти «вводити додаткові обмеження на цілісність, що відображають спеціальні вимоги». Крім того, за визначенням Кодда, обмеження на цілісність повинні:

• визначатися на мові високого рівня, що використовується в системі для всіх інших цілей;

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

Спочатку тільки декілька реалізацій реляційних баз даних задовольняли критеріям Кодда на цілісність, але ситуація поступово змінювалася. Стандарт 1992 року (часто званий «SQL92») підтримує обмеження, що забезпечують посилальну цілісність і дозволяють задавати бізнес правила. Ці можливості в тому чи іншому вигляді реалізовані в більшості систем.

15 Проектування баз даних

Процес, в ході якого вирішується, який вигляд буде у новостворюваної бази даних, називається проектуванням бази даних (database design). Робота з проектування бази даних включає вибір:

• таблиць, які будуть входити в базу даних;

• стовпців, що належать кожній таблиці;

• взаємозв'язків між таблицями і стовпцями.

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

Конструювання баз даних на основі реляційної моделі має ряд важливих переваг перед іншими моделями.

1. Незалежність логічної структури від фізичного і користувальницького подання.

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

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

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

15.1 Підхід до проектування бази даних

Часто при обговоренні питань проектування реляційних баз даних майже вся увага приділяється застосуванню правил нормалізації. У ході нормалізації забезпечується захист цілісності даних шляхом усунення дублювання даних. В результаті таблиця, яка спочатку здавалася «має сенс», розбивається на дві або більше пов'язаних таблиць, які можуть бути «зібрані разом» за допомогою операції об'єднання. Цей процес називається декомпозицією без втрат (non-loss decomposition) і просто означає розділення таблиці на кілька менших таблиць без втрати інформації. Нормалізація найбільш корисна для перевірки створеної вами структури. Можна проаналізувати свої рішення про те, які стовпці повинні бути включені в ту чи іншу таблицю з точки зору правил нормалізації, переконавшись при цьому, що не зробили якихось фатальних помилок. Розуміння основ процесу нормалізації також може допомогти в процесі проектування бази даних, але воно не є універсальним рецептом при побудові бази з нуля. Отже, як визначити, які стовпці повинні розташовуватися на початку таблиці. Загального правила на цей рахунок не існує. Однак тут вам може надати істотну допомогу моделювання залежностей - аналіз сутності даних (в термінах об'єктів або речей) і залежностей між ними (один-до-одного, один-до-багатьох, багато-до-багатьох).

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

1. Дослідження інформаційного середовища для моделювання.

• Звідки надходить інформація і в якому вигляді?

• Як вона буде вводитися в систему, і хто цим буде займатися?

• Як часто вона змінюється?

• Які параметри системи будуть найбільш критичними з точки зору часу реакції на запит і надійності?

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

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

• Кому вона буде призначатися.

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

3. У ході роботи обов'язково повинен створюватися макет таблиць і зв'язків між ними, званий структурою даних (data structure), або діаграмою залежностей між об'єктами (ER diagram).

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

5. Потім повинні бути розглянуті залежності між об'єктами.

• Чи є залежність типу один-до-багатьох (один замовник може мати безліч виписаних рахунків, але кожен рахунок може бути виписаний тільки на одного замовника) або багато-до-багатьох?

• Чи є можливості для об'єднання пов'язаних таблиць? Для цього служать зовнішні ключі (foreign key), стовпці в пов'язаних таблицях з співпадаючими значеннями первинних ключів.

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

7. Безпосередньому створення структури бази даних і приміщенню в неї деяких прототипів даних. Обов'язкове експериментування із запитами, вивчення отриманих результатів. Виконання рядів тестів на продуктивність, щоб перевірити різні технічні рішення.

8. Оцініть бази даних з точки зору того, чи задовольняють замовника отримані результати.

15.2 Кілька слів про структуру бази даних

1. Що таке «хороша структура» - це, в першу чергу, «прозора» структура. Простіше кажучи, хороша структура:

• максимально спрощує взаємодію з базою даних;

• гарантує несуперечність даних;

• «Витискає» максимум продуктивності з системи.

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

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

2. Погана структура бази даних

• призводить до нерозуміння результатів виконання запитів;

• підвищує ризик введення в базу даних суперечливої ​​інформації;

• породжує надлишкові дані;

• ускладнює виконання змін структури створених раніше і вже заповнених даними таблиць.

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

15.3 Нормалізація

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

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

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

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

15.3.1 Перша нормальна форма

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

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

15.3.2 Друга нормальна форма

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

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

15.3.3 Третя нормальна форма

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

Розглядаючи структуру цих таблиць, ви побачите, що вони задовольняють як другий, так і третьої нормальній формі. Вони задовольняють другій нормальній формі, тому що всі не ключові стовпці залежать від усього первинного ключа, і третій нормальній формі, тому що всі не ключові стовпці не залежать один від одного. Іншими словами, будь-який не ключовий стовпець залежить від ключа, всього ключа і нічого, крім ключа [4].

15.3.4 Четверта і п'ята нормальні форми

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

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

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

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

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

16 Загальна опис бази даних

16.1 Завдання, що виконуються додатком АРМ «Облік основних засобів»

База даних «автоматизоване робоче місце бухгалтера з обліку основних засобів» призначена для автоматизації роботи бухгалтерії (прибуткування, витрачання, розрахунки з організаціями, оренда техніки, тощо). В технічне завдання на реалізацію бази даних входили наступні завдання:

1. Оформлення, облік та виписка первинної бухгалтерської документації.

2. Прихід основних засобів на баланс підприємства.

3. Розрахунок орендної плати по всіх підрозділах і лізинговим компаніям.

4. Розрахунок вартості амортизаційних відрахувань за обладнання.

5. Перерахунок балансової вартості.

6. Формування звітів для відділу головного механіка.

7. Формування звітів для податкової інспекції.

8. Додавання різної кількості організацій використовують обладнання.

16.2 Технічні вимоги, які пред'являються до бази даних

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

- Система повинна нормально функціонувати на стандартних персональних комп'ютерах клону IBM на базі процесора Intel Pentium з тактовою частотою 100 МГц (мінімальні вимоги), приєднаних до локальної офісної обчислювальної мережі в режимі виділених серверів;

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

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

- Система повинна забезпечувати захист інформаційної бази даних від несанкціонованого доступу;

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

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

- Система повинна мати можливість нарощування в програмній частині.

- Система повинна функціонувати під управлінням операційних систем Windows 95, Windows 98 і Windows NT.

17 Вибір мережевої операційної системи

Як мережевий операційної системи був вибраний Novell Netware 4.11, дана модель має на увазі виділений сервер, що дозволяє:

• обмежити доступ до бази даних;

• організувати можливість переглядати дані тільки тим користувачам, які зареєстровані в системі;

• використовувати мережеві принтери;

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

• налаштувати програму як Launcher програму, що не буде вимагати встановлення її на локальному комп'ютері, а тільки буде необхідно встановити BDE;

У зв'язку з тим, що Novell Netware зарекомендував себе в якості одного з кращих файл-серверів, використання для зберігання баз даних файлової системи NTFS представляється краще, ніж FAT з міркувань відмовостійкості.

18 Вибір системи проектування й реалізації.

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

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

Delphi - це не просто нова версія компілятора мови Pascal, а принципово новий програмний продукт, що дозволяє створювати широкий спектр додатків для Середовища Microsoft Windows. Він об'єднує в собі високопродуктивний компілятор з мови ObjectPascal, засоби наочного (візуального) створення програм і масштабовану технологію управління базами даних. Основне призначення Delphi - служить засобом для швидкого створення широкого класу Windows - додатків. Вона враховує багато новітні досягнення в програмуванні та практиці створення додатків і призначена для візуального програмування, коли розробник бачить велику частину результатів безпосередньо на екрані монітора вже в процесі своєї роботи зі створення програми. Візуальне програмування дозволяє швидше створити інтерфейс програми, зробити його більш якісним за рахунок найкращого розташування інформації вікна екрані монітора, уникнути багатьох помилок вже на екрані проектування [7].

Використання Delphi також відбувається з таких міркувань:

• операційна система DOS і її застосування доживають свої останні дні на залишках РС, які не підтримують оболонки Windows або операційної системи Windows 95;

• мова Pascal як і раніше залишається кращим мовою для програмування;

• мову Object Pascal, на відміну від Borland (Turbo) Pascal та інших сучасних засобів розробки додатків того ж класу, має вбудовану підтримку модульної методології створення додатків, оскільки кожній візуальної формі автоматично ставиться у відповідності окремий модуль;

• створення Windows додатків з використанням візуальної технології розробки програм починається не від найпростіших операторів (if, while і т.п.), а від готових візуальних компонент, для яких автоматично генерується код у вигляді значно більших синтаксичних одиниць (класів, властивостей, методів, модулів).

Delphi з точки зору коштів для розробки Windows - додатків об'єднує в собі наступні елементи:

• високопродуктивний компілятор. Наявний у складі Delphi компілятор з мови ObjectPascal є одним з найбільш продуктивних у світі і дозволяє компілювати програми зі швидкістю до 120000 рядків у хвилину (350000 рядків у хвилину для процесора Pentium 90 МГц). Середовище Delphi включає в себе вбудований компілятор. При необхідності можна скористатися і пакетним компілятором DCC.EXE, що також входить в пакет поставки;

• об'єктно-орієнтована модель компонентів. Основним призначенням застосовуваної в Delphi моделі компонентів є забезпечення можливості багаторазового використання компонентів і створення нових. Фактично для створення Delphi використовувалися ті ж компоненти, що і входять у комплект постачання. Тим не менше, не можна не відзначити, що внесені в об'єктну модель зміни в першу чергу були викликані необхідністю підтримки технології візуального програмування. При цьому мова залишився сумісним з мовою Pascal, підтримуваним компілятором Borland Pascal 7.0;

• швидка середовище розробки (RAD). Середовище Delphi містить повний набір візуальних засобів для швидкої розробки додатків, що підтримують як створення користувацьких інтерфейсів, так і обробку корпоративних даних. Використання бібліотеки візуальних компонентів (VCL) і візуальних об'єктів для роботи з даними дозволяє створювати додатки з мінімальними витратами на безпосереднє кодування. При цьому компоненти, включені до складу Delphi, максимально інкапсулюють виклики функцій Windows API, тим самим, полегшуючи процес створення програм;

• масштабоване ядро ​​управління даними;

• розширюваність. Delphi є системою з відкритою архітектурою, що дозволяє доповнювати її новими засобами і переносити на різні платформи.

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

Бази даних створені за допомогою системи Borland Delphi 5 повністю реалізують реляційну модель побудови даних. База даних створена для Borland Delphi використовує всі переваги таблиць Borland Paradox і являє собою набір груп об'єктів, таких як таблиці, запити, форми, звіти.

Зв'язки між таблицями можна розбити на чотири базових реляційних типу з відносинами:

• один - до - одному;

• один - ко - багатьом;

• багато - до - одному;

• багато - до - багатьом.

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

Також Borland Delphi 5 надає велику кількість національних засобів щодо оптимізації роботи проектованого додатки. До них відносяться:

• використання BDE (Borland DataBase Engine) для управління базами даних;

• використання бібліотек Windows API;

• індивідуальна настройка системи;

• ефективне використання індексів;

• вбудований оптимізатор запитів.

Для швидкого знайомства з основними принципами створення додатків в середовищі Delphi можна використовувати інтерактивну навчальну систему.

Окрім засобів, які призначені для надання допомоги в процесі розробки програм, Середовище Delphi включає в себе так звані технічні засоби - інтегрований відладчик, пакетний компілятор і утиліти WinSight і WinSpector. Основне призначення утиліти WinSight - спостереження за системою передачі повідомлень Windows. Утиліта WinSpector - дозволяє дізнатися причини помилкового завершення того чи іншого додатка.

Бібліотека компонент - Visual Components Library (VCL) є "серцем" Delphi. Всі засоби розробки, включені до складу Delphi, в тій чи іншій мірі базуються на бібліотеці класів. Ця бібліотека містить близько 140 класів, інкапсулюючих різні групи функцій Windows API. Чисто умовно класи, що входять до бібліотеки VCL, можна розділити на класи, що реалізують функціональність компонентів, і внутрішні класи, які реалізують підтримку роботи самого програми, але не використовуються безпосередньо.

Для мінімальної роботи Delphi потрібно персональний комп'ютер з пристойними характеристиками. Пакет Delphi посилює ці вимоги. Для роботи в цьому середовищі необхідний комп'ютер 486 або Pentium з тактовою частотою не менше 100 МГц, оперативною пам'яттю не менше 8М (бажано 16М і більше), жорстким диском об'ємом не менше 50Мб. Бажано, щоб монітор мав дозвіл не гірше 800х600. Можна спробувати використовувати Delphi і з менш потужним комп'ютером, але навіть якщо це вдасться, робота з пакетом навряд чи принесе в цьому випадку задоволення.

19 Опис структури бази даних У проекті використовується 12 таблиць, формату Borland Paradox. (Основна, прихід, витрата, архів приходу, архів витрати, підрозділи, шифри амортизації, лізингові компанії, підзвітні особи, план рахунків, підсумкова, переміщення ОС). Розглянемо кожну окремо: Основна. Ім'я таблиці: Osnova.DB (тип: Borland Paradox). Призначення: Ця таблиця є основною для зберігання інформації щодо основних засобів (Таблиця 19.1), в яку входять (Інвентарний номер, найменування, шифр амортизації, балансова вартість, залишкова вартість, місячна амортизація, підрозділ, підзвітну особу тощо). (Докладніше про структуру у додатку 1). Таблиця 19.1 - Структура таблиці Osnova.DB Ім'я поля Опис Inventar Інвентарний номер Naimenov Найменування устаткування Hifr_amo Шифр амортизації Procent Відсоток амортизації TypeOS Тип оборудования Bas_stoim Балансова вартість Mes_amort Місячна амортизація Pol_iznos Сума повного зносу Ost_stoim Залишкова вартість Data_vvod Дата введення в експлуатацію Uhastoc Ділянка використання Podoth Підзвітна особа Old_amortiz Сума старої амортизації KMetrash Показання лічильника автотранспорту SunAnda Сума оренди Sclad Найменування складу Зв'язки: Один до багатьох - поле Ділянка з таблицею Ділянок (поле «ділянку»), цей зв'язок забезпечує об'єднання даних по ділянках, що є дуже зручним при роботі з конкретними організаціями з обліку основних засобів. Один до багатьох - поле шифр амортизації з таблицею шифри амортизацій (поле Shifr), дана зв'язок забезпечує об'єднання даних по шифру амортизації і є довідником шифрів амортизації. Один до багатьох - поле «Інвентарний номер» з таблицею «Переміщення основних засобів», що дозволяє отримувати інформацію, де і ким використовувалося поточне обладнання. Прихід. Ім'я таблиці: Prihod.DB (тип: Borland Paradox). Призначення: Ця таблиця є основною для зберігання інформації по приходу основних засобів за поточний місяць (Таблиця 19.2), що дозволяє працювати з новим списком до закінчення місяця, робити зміни, редагувати дані, які ні як не впливають на результати руху до того поки не проведена операція закриття місяця. в яку входять (Інвентарний номер, найменування, шифр амортизації, балансова вартість, залишкова вартість, місячна амортизація, підрозділ, підзвітну особу і тп.). (Детальніше про структуру у додатку 1). Таблиця 19.2 - Структура таблиці Prihod.DB Ім'я поля Опис Inventar Інвентарний номер NaimenovOS Найменування устаткування ShifrAmo Шифр амортизації Procent Відсоток амортизації Bal_Stoim Балансова вартість Mes_amort Місячна амортизація Poln_amort Повна сума амортизації Ost_Stoim Залишкова вартість Old_amortiz Стара сума амортизації Продовження таблиці 19.2 Sclad Номер складу Uhastoc Ділянка використання DataVvoda Дата введення в експлуатацію Podothetnic Підзвітна особа Kmetrash Пробіг автотранспорту TypeOS Тип оборудования Arenda Тип використання (оренда / відповідальне зберігання) Зв'язки: Один до багатьох - поле Ділянка з таблицею Ділянок (поле «ділянку»), цей зв'язок забезпечує об'єднання даних по ділянках, що є дуже зручним при роботі з конкретними організаціями з обліку основних засобів. Один до багатьох - поле шифр амортизації з таблицею шифри амортизацій (поле Shifr), дана зв'язок забезпечує об'єднання даних по шифру амортизації і є довідником шифрів амортизації. Один до одного - поле «дебіт», «кредит» з таблицею «План рахунків», що дозволяє організувати довідник рахунків беруть участь при роботі. Один до багатьох - поле «Інвентарний номер» з таблицею «Переміщення основних засобів», що дозволяє отримувати інформацію де і ким використовувалося поточне обладнання. Витрата. Ім'я таблиці: Rashod.DB (тип: Borland Paradox). Призначення: Ця таблиця є основною для зберігання інформації по витраті основних засобів за поточний місяць (Таблиця 19.3), що дозволяє працювати з списком витрачених обладнання до закінчення місяця. У цю таблицю потрапляють дані з основної таблиці (повне перенесення даних, що виключає дублювання даних), що дозволяє зробити відкат, помилково зробленого витрати устаткування. У таблицю входять поля (Інвентарний номер, найменування, шифр амортизації, балансова вартість, залишкова вартість, місячна амортизація, підрозділ, підзвітну особу і тп.). (Детальніше про структуру у додатку 1). Таблиця 19.3 - Структура таблиці Rashod.DB Ім'я поля Опис Inventar Інвентарний номер Naimenov Найменування устаткування Hifr_amo Шифр амортизації Procent Відсоток амортизації TypeOS Тип оборудования Bas_stoim Балансова вартість Mes_amort Місячна амортизація Pol_iznos Сума повного зносу Ost_stoim Залишкова вартість Data_vvod Дата введення в експлуатацію Uhastoc Ділянка використання Podoth Підзвітна особа Old_amortiz Сума старої амортизації Kmetrash Показання лічильника автотранспорту SunAnda Сума оренди Sclad Найменування складу Data_del Дата витрачання обладнання Зв'язки: Один до багатьох - поле Ділянка з таблицею Ділянок (поле «ділянку»), цей зв'язок забезпечує об'єднання даних по ділянках, що є дуже зручним при роботі з конкретними організаціями з обліку основних засобів. Один до багатьох - поле шифр амортизації з таблицею шифри амортизацій (поле Shifr), дана зв'язок забезпечує об'єднання даних по шифру амортизації і є довідником шифрів амортизації. Один до одного - поле «дебіт», «кредит» з таблицею «План рахунків», що дозволяє організувати довідник рахунків беруть участь при роботі. Один до багатьох - поле «Інвентарний номер» з таблицею «Переміщення основних засобів», що дозволяє отримувати інформацію, де і ким використовувалося поточне обладнання. Лізингові компанії. Ім'я таблиці: Lizing.DB (тип: Borland Paradox). Призначення: Ця таблиця є основною для зберігання інформації з лізинговим компаніям надають обладнання в оренду (Таблиця 19.4), в яку входять (Інвентарний номер, найменування, шифр амортизації, балансова вартість, залишкова вартість, місячна амортизація, підрозділ, підзвітну особу і тп.) . (Детальніше про структуру у додатку 1). Таблиця 19.4 - Структура таблиці Lizing.DB Ім'я поля Опис Inventar Інвентарний номер Naimenov Найменування устаткування Hifr_amo Шифр амортизації Procent Відсоток амортизації TypeOS Тип оборудования Bas_stoim Балансова вартість Mes_amort Місячна амортизація Pol_iznos Сума повного зносу Ost_stoim Залишкова вартість Data_vvod Дата введення в експлуатацію Uhastoc Ділянка використання Podoth Підзвітна особа Old_amortiz Сума старої амортизації KMetrash Показання лічильника автотранспорту SunAnda Сума оренди Sclad Найменування складу Lizing Найменування лізингової компанії Зв'язки: Один до багатьох - поле Ділянка з таблицею Ділянок (поле «ділянку»), цей зв'язок забезпечує об'єднання даних по ділянках, що є дуже зручним при роботі з конкретними організаціями з обліку основних засобів. Один до багатьох - поле шифр амортизації з таблицею шифри амортизацій (поле Shifr), дана зв'язок забезпечує об'єднання даних по шифру амортизації і є довідником шифрів амортизації. Один до багатьох - поле «Інвентарний номер» з таблицею «Переміщення основних засобів», що дозволяє отримувати інформацію де і ким використовувалося поточне обладнання. Підрозділи. Ім'я таблиці: Uhastoc.DB (тип: Borland Paradox). Призначення: Ця таблиця зберігає інформацію з підрозділам що беруть участь в розрахунках за основними засобами (Таблиця 19.5), за допомогою цієї таблиці зв'язуються всі таблиці по підрозділах. У цю таблицю входять стовпці (Шифр, Найменування організації, інформація про організацію, телефон). (Детальніше про структуру у додатку 1 і 2). Таблиця 19.5 - Структура таблиці Uhastoc.DB Ім'я поля Опис Naimenov Найменування підрозділу Information Інформація про організацію Adress Адреса організації Telefon Номер телефону Зв'язки: Один до багатьох - поле Шифр ​​з таблицями «Основна», «Прихід», «Видаток», «Лізингові компанії». Шифр амортизації. Ім'я таблиці: Shifr.DB (тип: Borland Paradox). Призначення: Ця таблиця зберігає інформацію з шифрам та відсотками амортизації, та опис конкретного шифру амортизації (Таблиця 19.6). Дана таблиця використовується тільки в якості довідника при оприбуткуванні нового обладнання, що виключає можливість допустити помилку і можливо налаштувати довідник під обладнання яке бухгалтер постійно використовує. У цю таблицю входять стовпці (Шифр, Відсоток амортизації, Опис шифру амортизації). (Детальніше про структуру у додатку 1). Таблиця 19.6 - Структура таблиці Shifr.DB Ім'я поля Опис Shifr Шифр амортизації Procent Відсоток амортизації Opisanie Опис шифру амортизації Зв'язки: Один до багатьох - поле Шифр ​​з таблицями «Основна», «Прихід», «Видаток», «Лізингові компанії». Даний зв'язок дозволяє згрупувати основні засоби по шифру амортизації, а це означатиме і за типом устаткування. Переміщення основних засобів. Ім'я таблиці: Peremesh.DB (тип: Borland Paradox). Призначення: Ця таблиця зберігає інформацію з інвентарними номерами які були переміщені в межах підприємства (змінили підзвітну особу, змінили підрозділ і тп.), Що дозволяє переглянути всі переміщення устаткування з моменту його приходу (таблиця 19.7). У цю таблицю входять стовпці (Шифр Стара організація, Нова організація, Старе Підзвітна особа, Нове підзвітну особу, Дата). (Детальніше про структуру у додатку 1). Таблиця 19.7 - Структура таблиці Peremesh.DB Ім'я поля Опис Increm Унікальне поле Inventar Інвентарний номер Naimenov Найменування устаткування Uhastoc Ділянка «ВІД» Podothotnic Подотчетнік «ВІД» Uhas2 Ділянка «КУДИ» Podoth Подотчетнік «КУДИ» Arenda Тип використання «ВІД» Arenda2 Тип використання «КУДИ» Data Дата переміщення обладнання Зв'язки: Один до багатьох - поле Шифр ​​з таблицями «Основна». План рахунків. Ім'я таблиці: Schet.DB (тип: Borland Paradox). Призначення: Ця таблиця зберігає інформацію за рахунками використовуються в програмі і їх описом (Таблиця 19.8). Дана таблиця є довідником, по якому проводиться групування звітів по руху основних засобів за місяць. У цю таблицю входять стовпці (Номер рахунку, опис). (Докладніше про структуру у додатку 1). Таблиця 19.8 - Структура таблиці Schet.DB Ім'я поля Опис Schet Номер рахунку Opisanie Опис рахунку Otcrit Дозвіл на використання рахунку Підзвітні особи. Ім'я таблиці: Podothot.DB (тип: Borland Paradox). Призначення: Ця таблиця зберігає інформацію з підзвітним особам, прикріпленим за організаціями, орендує обладнання (таблиця 19.9). У таблицю входять поля (Шифр, Прізвище, Дата народження, паспортні дані і тд.). (Детальніше про структуру у додатку 1). Таблиця 19.9 - Структура таблиці Podoth.DB Ім'я поля Опис Kod Код таблиці Family Прізвище Name Ім'я Othestvo По батькові DatRoshden Дата народження . . . . . . Паспортні дані Uhastoc Ділянка Зв'язки: Один до багатьох - поле Ділянка з таблицею Ділянок (поле «ділянку»), цей зв'язок забезпечує об'єднання даних по ділянках, що є дуже зручним при роботі з конкретними організаціями з обліку основних засобів. Один до багатьох - поле «прізвище» таблицями, дана зв'язок забезпечує об'єднання даних по шифру амортизації і є довідником шифрів амортизації. У звіті розписані дані по базах даних самих необхідних таблиць, так як опис всіх побічних таблиць збільшує обсяг звіту. У разі необхідності переглянути структури баз даних можна звернутися до додатка 1. 20 Структура програми Так як підсумком роботи Delphi є повністю закінчила додаток у вигляді EXE модуля, тому описати структуру можна тільки у вигляді блок схем показують взаємозв'язку з окремими компонентами програми (рисунок 20.1): Нове обладнання Прихід Витрата Витрата обладнання (Продаж, передача ..) Основна база даних Переміщення ОС Витрата в лізинг Відновлення ОС Розщеплення ОС Розрахунок оренди вартості Розрахунок амортизації Імпорт ОС Переоцінка ОС Установка значення пробігу База даних по лізинговим компаніям Закрити місяць Запис підсумків Розрахунок оренди вартості Розрахунок амортизації Архів приходу Архів витрати Звіти для бухгалтерії Звіти для інших відділів Малюнок 20.1 21 Керівництво користувачеві 21.1 Установка програми Для установки програми на комп'ютер необхідно вставити перші дискету з комплекту установки програми і запустити на виконання файл Setup.exe. Після запуску програми установки, необхідно вказати шлях для встановлення програми, в який будуть встановлені всі файли програми, але всі бази даних програми. Після того, як вкажіть шлях, необхідно вказати найменування групи програм, в яку буде записаний ярлик для запуску програми APMBos.exe, який і є запускним модулем програми «Облік основних засобів». (Після роботи програми установки буде налаштований драйвер баз даних BDE, в якому буде прописаний псевдонім бази даних програми під назвою «Osnova», який вказує на бази даних програми «Основні засоби»). У разі якщо з'явиться необхідність видалити програму, необхідно увійти в (Пуск - Настройка - Панель управління - Установка видалення програм). У вікні необхідно вибрати програму Osnova і натиснути на кнопку «Видалити». 21.2 Запуск і початкові установки програми Для запуску програми необхідно вибрати ярлик програми (Пуск - Програми - Основні засоби - Osnova), після чого з'явиться основне вікно програми. Для початку роботи з програмою необхідно налаштувати довідники, без заповнених довідників неможлива нормальна робота програми, розглянемо кожен окремо. Довідник підрозділів - цей довідник містить інформацію про підрозділ (найменування організації, інформація про організації, адреса організації, номер телефону). Виберіть пункт меню «Налаштування - Довідники - Підрозділи», після чого, з'явиться вікно (рисунок 21.1). Малюнок 21.1 У даному вікні ви зможете додати, змінити і видалити підрозділ яке безпосередньо використовує обладнання. Натиснувши на кнопці «Додати» з'явиться вікно, в якому необхідно ввести (найменування організації, опис організації, адреса організації, і телефон). Якщо необхідно змінити дані по підрозділу натисніть кнопку «Змінити» і з'явиться вікно, аналогічне процедурі додавання. У випадку якщо необхідно видалити, то натисніть видалити і при позитивній відповіді запис буде видалена. 2. Довідник шифрів амортизацій - цей довідник містить інформацію про шифри амортизацій (шифр амортизації, опис шифру, група шифрів за типом). Виберіть пункт меню «Налаштування - Довідники - Шифри амортизацій», після чого, з'явиться вікно (рисунок 21.2). Малюнок 21.2 У даному вікні ви зможете додати, змінити і видалити шифр амортизації, який можна знайти в довідниках з розрахунку амортизаційних відрахувань. Натиснувши на кнопці «Додати» з'явиться вікно, в якому необхідно ввести (шифри амортизації, опис і групу шифрів за типом). Якщо необхідно змінити дані по підрозділу натисніть кнопку «Змінити» і з'явиться вікно аналогічне процедурі додавання. У випадку якщо необхідно видалити, то натисніть видалити і при позитивній відповіді запис буде видалена. Даний довідник слід змінювати, тільки в тому випадку, якщо на підприємстві з'явилося не стандартне обладнання. 3. Довідник підзвітних осіб - цей довідник містить інформацію про підзвітних осіб поточного підрозділу (ініціали, паспортні дані, номер телефону). Виберіть пункт меню «Налаштування - Довідники - Підзвітні особи», після чого, з'явиться вікно (рисунок 21.3). Малюнок 21.3 У даному вікні ви зможете додати, змінити і видалити підзвітну особу поточного підрозділу, у випадку якщо необхідно змінити підрозділ, слід вибрати вкладку «Підрозділ» і вибрати необхідне підрозділ. Натиснувши на кнопці «Додати» з'явиться вікно, в якому необхідно ввести (ініціали, паспортні дані та телефон). Якщо необхідно змінити дані по підзвітній особі натисніть кнопку «Змінити» і з'явиться вікно аналогічне процедурі додавання. У випадку якщо необхідно видалити, то натисніть видалити і при позитивній відповіді запис буде видалена. 4. Довідник план рахунків - цей довідник необхідний для автоматизації введення рахунків, в даному довіднику міститься шифр рахунку та опис шифру. Виберіть пункт меню «Налаштування - Довідники - Підзвітні особи» для налаштування довідника.