Ведення списку матеріалів

1.1.3.4 Ведення списку матеріалів

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

1.1.3.5 Ведення списку груп послуг

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

1.1.3.6 Ведення списку груп матеріалів

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

1.1.3.7 Формування кошторису на замовлення

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

1.1.3.8 Формування звіту по кошторису для друку

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

1.1.4 Опис постановки завдання

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

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

Звіти про становище у сфері надання послуг, одержувані за допомогою комп'ютера, можна отримати і без нього – ніякої особливої математики в комп'ютері не міститься – але| на розрахунки піде стільки часу, що вони вже ні на що не будуть потрібні; або ними доведеться зайняти таку кількість розраховувачів, що на їх зарплату піде значно більше, чим буде одержано прибутку в результаті їх розрахунків. Таким чином, при застосуванні комп'ютера "кількість переходить в якість": збільшення швидкості розрахунків робить можливим якісне поліпшення самої схеми побудови надання послуг.

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

–   проаналізувати суть завдань ремонтного та постачального відділів;

–   обґрунтувати використання обчислювальної техніки;

–   обґрунтувати розробки по всіх видах забезпечення;

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

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

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

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

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

Актори – це користувачі, або інші системи, які унікальним чином взаємодіють із даною системою.

У інформаційній системі, що розробляється, претендентами на роль акторів є:

–   Адміністратор – користувач, що здійснює настройку і конфігурацію системи;

–   Головний бухгалтер – користувач, що здійснює фінансові операції;

–   Співробітник – майстер ремонтного відділу, який приймає заявки від клієнтів та формує замовлення.

На підставі перерахованих потреб можна виділити наступні прецеденти:

–   реєстрація в системі;

–   конфігурація системи;

–   формування документів;

–   пошук даних.

Діаграма прецедентів використання системи показана на рис.1.4.

Рисунок 1.4 - Діаграма прецедентів використання

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

Рисунок 1.5 – Функціональна схема програми