Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

Разработка АСИС “Учет поставок”

Зміст

Висновок

Література

Додаток 1

Додаток 2

Додаток 3

Вступ

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

Таким чином, до складу господарства України входять підприємства і організації, як сфери матеріального виробництва, так і сфери обслуговування, що як госпрозрахункові, так і перебувають на державному бюджеті. Найбільше число держбюджетних організацій знаходиться у веденні Міністерства освіти і науки України: школи, дитячі сади, педагогічні інститути, технікуми, училища і тому подібне (близько 30% загальної кількості організацій); міністерства охорони здоров'я України – лікарні, санаторії, госпитали і ін. лікувальні установи (близько 20%); міністерства культури і освіти України – театри, бібліотеки, музеї і ін. (більше 25% загальної кількості організацій) [3].

Керівництво місцевим господарством країни організоване як за галузевим принципом (через відповідні міністерства і відомства), так і по територіальному (через місцеві органи управління).

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

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

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

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

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

контроль за своєчасним, повним і правильним оприбутковуванням товарів, що поступили;

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

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

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

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

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

1 Загальна характеристика проблеми

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

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

Контроль за виконанням договорів здійснюють товарні відділи.

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

Правильне приймання і оформлення документами товарів, що поступили

Є надійною основою збереження товарно-матеріальних цінностей.

Загальний порядок приймання товарно-матеріальних цінностей встановлений “Положенням про постачання продукції виробничо-технічного призначення”. Порядок і терміни приймання товарно-матеріальних цінностей в певній кількості і якості, оформлення актів приймання і пред'явлення претензій визначені інструкцією про порядок приймання продукції виробничо-технічного призначення і товарів народного споживання по кількості і інструкцією про порядок приймання продукції виробничо-технічного призначення за якістю. Особливості приймання окремих видів продукції визначаються в Гостах [12.01.005-89], технічних умовах, Особливих умовах постачання і договорах постачання, що передбачають особливі порядки приймання продукції при постачаннях.

1.1 Формулювання завдань

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

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

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

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

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

Таким чином для розробки АСИС необхідно виконати наступні завдання:

реалізація управління доступом до АСИС;
створити СУБД для роботи АСИС;
розробити довідкову інформацію по АСИС;
виконати аналіз і обліку постачань.

1.2 Мотивація завдань.

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

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

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

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

1.3. Технічне завдання.

Автоматизована довідково-інформаційна система (АСИС) “Облік постачань” використовуватиметься на підприємствах різних форм власності і забезпечуватиме контроль і облік постачань вироблюваних на підприємство. Також при використанні даного ПО буде можливість складання звітності про постачання на підприємство, виявлення заборгованості по оплаті постачань. Що розробляється ПО може бути використано як керівником підприємства, для здійснення контролю вироблюваних постачань на підприємство, так і начальниками цехів, для ведення обліку постачань.

1.3.1 Призначення розробки

Метою дипломного проектування є розробка і створення програмного продукту “Облік постачань”. Даний програмне забезпечення призначене для контролю, обліку, автоматизації і систематизації інформації про постачання різного вигляду продукції на підприємство будь-якої форми власності, що займається будь-яким видом виробництва або діяльності.

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

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

Комерційна версія програмного продукту дозволить проводити:

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

Що розробляється автоматизована система повинна буде реалізувати наступні функції:

Забезпечення введення даних про постачання на підприємство;
Аналіз введеної інформації;
Підрахунок заборгованості підприємства за здійснені постачання;
Визначати оптимальний рахунок з точки зору “кількість-ціна”;
Проводить друк документації, пов'язаної з організацією постачань (бланк договору, замовлення, заявки).

1.3.4. Початкові вимоги до кінцевого результату.

Вимоги по функціональності.

АСИС, що розробляється, повинен забезпечувати автоматизований контроль, а так само облік постачань на підприємство (цех цього підприємства), для цього створювана система винна:

Забезпечувати введення, пов'язаних з постачаннями на підприємство і обробку цих даних;
Створювати звітні документи і документи для організації грузопоставок; ( Додаток 3)
Мати систему допомоги за програмою;
При введенні даних про найменування товарів повинен використовуватися довідник “Номенклатура товарів”;
Створювані документи повинні відповідати галузевим стандартам, прийнятим на підприємстві.

Умови експлуатації

Створюваний програмний продукт повинен буде використовуватися директором підприємства, начальником цеху, начальником складу, залежно від місця експлуатації продукту. Задані характеристики функціонування повинні забезпечуватися за умов, які визначаються конкретним носієм даних, на якому зберігаються дані. Найбільш поширеними носіями даних в даний час є жорсткі диски, для яких оптимальним є функціонування при температурах від 5 до +35^оС і відносній вологості від 10 до 60 відсотків.

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

Програма повинна функціонувати на персональних комп'ютерах з наступною конфігурацією:

IBM PC/AT сумісних ПЕВМ не нижче Pentium 100;
з об'ємом ОЗУ не менше 16 мегабайт;
Об'єм необхідного дискового простору - не менше 10 мегабайт.

Вимоги до інформаційної і програмної сумісності

Створювана програма повинна функціонувати, легко інсталюватися, настроюватися і коректно працювати при виконанні наступних вимог:

наявність операційної системи типу Windows 95, Windows 98, Windows NT 4.x, Windows 2000 і сумісних з ними;
наявність бази даних LocalInterBase або сумісних з нею;
введення дати обов'язкове у формі маски;
введення цифр обов'язкове.

Вимоги по захисту.

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

2 Плановані показники ефективності.

В результаті виконаної роботи передбачається досягти наступних ефектів:

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

2.1 Аналіз представлення моделей даних.

Для ефективного функціонування АСИС, що розробляється, “Облік постачань” буде розроблений СУБД. Тому нижче розглянуті логічні і концептуальні моделі даних.

2.2 Вибір логічної моделі даних.

2.2.1 Ієрархічна модель даних.

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

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

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

У зв'язку з тим, що ієрархічна модель володіє великою кількістю недоліків вона не буде застосуються для моделювання АСИС, що розробляється.

2.2.2 Мережева модель даних

Мережа [5] – більш загальна структура порівняно з ієрархією. Вузлами мережі є окремі екземпляри запису. Вузли запису є одиницею доступу до БД. Оскільки окремий вузол може мати декілька безпосередньо старших вузлів, так само, як і декілька безпосередньо підлеглих, то дана структура забезпечує пряме представлення відношення “багато до багатьом”. Для зв'язку між записами-вузлами існує запис, що пов'язує, всі екземпляри якого поміщаються в ланцюжок для зв'язку двох екземплярів.

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

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

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

2.2.3 Реляционная модель данных.

Реляційна модель – множинним відношенням яке є підмножина декартова твори списку доменів [27,20]. Домен – це безліч значень, з якої витягуються значення для даного атрибуту. Іншими словами в основі реляційної моделі лежать прості таблиці, які задовольняють певним обмеженням, а тому можуть розглядатися як математичні відносини. Рядки таких таблиць називаються кортежами, імена стовпців – атрибутами. Слід зазначити, що всі кортежі різні, а порядок стовпців довільний, чим спрощується процес обробки кортежів. У відношенні (таблиці) виділяється декілька атрибутів, що однозначно ідентифікують кортежі і званих ключами.

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

Основний недолік реляційної моделі даних зв'язується з низькою продуктивністю реляційної СУБД. Але розробка сучасних СУБД таких як, ORACLE, InterBase, Acsses і ін. дозволило подолати і цей недолік.

Достоїнства реляційної моделі можна розділити на дві групи:

достоїнства для користувача:

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

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

достоїнства обробки даних реляційною БД:

зв'язність. Реляційне уявлення дає ясну картину взаємозв'язків атрибутів з різних відносин;
точність. Направлені зв'язки в реляційній БД відсутні. Відносини за своєю природою володіють точнішим сенсом і піддаються маніпулюванню з використанням таких засобів, як алгебра і числення відносин [5], забезпечуючу наочність і гнучкість моделі даних;
гнучкість. Операції проекції і об'єднання [17] дозволяють розрізати і склеювати відносини, так що програміст може отримувати різноманітні файли в потрібній формі;
секретність. Контроль секретності спрощується. Для кожного відношення є можливість завдання правомірності доступу, засекречені показники можна виділити в окремі відносини з перевіркою прав доступу.
Простота впровадження. Фізичне розміщення однорідних (табличних) файлів набагато простіше, ніж розміщення ієрархічних і мережевих структур.
Незалежність даних. БД повинна допускати можливість розширення, тобто додавання нових атрибутів і відносин.

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