Автоматизація робочого місця менеджера

Автоматизація робочого місця менеджера МСП

Введення

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

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

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

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

Глава 1. Технічне завдання на проектування

1.1. Постановка завдання

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

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

1.2. Вимоги до системи.

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

Вимоги до розробляється системі:

Чітка і логічна структура баз даних;

Наявність мінімум третє нормальної форми для всіх створюваних структур даних;

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

Способи отримання інформації з спроектованої системи.

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

1.3. Користувачі системи

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

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

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

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

1.4. Етапи розробки

Основними етапами розробки системи є:

розробка техніко-економічного обгрунтування проекту;

розробка технічного завдання на проектування;

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

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

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

Терміни та склад робіт узгоджуються з викладачем і оформляються представленим у додатках "Завданням на курсове проектування".

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

Глава 2. Інфологіческое проектування

2.1. Обстеження предметної області.

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

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

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

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

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

2.2. Опис користувачів

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

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

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

2.3. Запити та регламентні завдання

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

Також у системі можуть реалізовані наступні запити:

інформація про борг клієнта (або нашому борг клієнту)

будь-яка інформація, яка може бути отримана на підставі документів (наприклад, сума відвантажень клієнта за певний період, і ін)

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

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

2.4. Опис алгоритму роботи системи

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

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

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

На підставі виданої клієнту накладної, комірник віддає товар. Таким чином, ми отримали чітку систему відвантаження товару.

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

Надходження товару на склад може виникати в двох випадках. По-перше, при надходженні товару від постачальника, а по-друге, при поверненні товару від покупця.

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

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

2.5. Словник даних

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

№ пп

Найменування елемента даних

Назва

Скаляр/масив/вх/вих/розрахунковий

Довжина байт

Обмеження цілосності

Примітки

Номер документа

Number

Скаляр

Маска #####

Значення формується автоматично

Дата оформлення

Date

Скаляр

Маска 99.99.99

Вид документа

DocType

Скаляр

Маска 999

Ознака накладної

Priznak

Скаляр

Маска 999

Має сенс тільки для накладної

Фірма

Firm

Скаляр

Клієнт

Klient

Скаляр

150

Вид продажу

SailType

Скаляр

Склад

Sklad

Скаляр

10.

Підстава для виписки документа

Osnov

Скаляр

11.

Автор документа

Author

Скаляр

Маска 999

12.

Найменування товару.

Tovar

Скаляр

13.

Ціна за одиницю

Price

Скаляр, вхідна

10, 2

Маска 9999999.99

14.

Кількість

Kol

Скаляр, вхід

10, 3

Маска 999999.999

15.

Сума

Sum

Скаляр, розрахунковий

12, 2

16.

ПДВ

NDS

Скаляр, розрахунковий

12, 2

Проведено

Proveden

Логічний

Проходить документ по регістрах чи ні

Глава 3. Даталогіческое проектування.

3.1. Вибір СУБД

Для реалізації спроектованої системи могла б підійти будь-яка СУБД середнього рівня (наприклад, Microsoft Access). Але в рамках даного курсового проекту система повинна бути реалізована в середовищі FoxPro. І ця система цілком підходить для складання програми, яка обслуговує проектовану систему, а саме:

СУБД є спеціалізованою програмою для роботи з реляційними БД, що значно спрощує процес даталогіческого проектування;

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

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

Ця система дуже вимоглива до апаратних ресурсів і може виконуватися на будь-якому комп'ютері на якому встановлена система Windows (та сама СУБД)

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

3.2. Даталогіческая модель

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

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

Tovar.dbf - Довідник товарів

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код товару

Name

Character

Найменування товару

PriceIn

Numeric

6,2

Вхідна ціна

PriceOut

Numeric

6,2

Продажна ціна

Unit

Character

Одиниця виміру

Proizvod

Numeric

Код виробника

Proizv.dbf - Довідник з виробниками

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код виробника

Name

Character

Повна назва виробника

Coment

Character

Інформація про виробника

Sklad.dbf - Довідник складів

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код складу

Name

Character

Повна назва складу

Users.dbf - Довідник користувачів системи

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код співробітника

Name

Character

Ім'я та По-батькові співробітника

Passport

Character

Серія та номер паспорта

Address

Character

Адреса співробітника

Status

Numeric

Статус співробітника як користувача

Firms.dbf - Довідник фірм за якими ведеться облік

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код фірми

Name

Character

Повна назва фірми

Address

Character

Адреса фірми

Tel

Character

Телефони

Numeric

Розрахунковий рахунок

OKPO

Numeric

Код ОКПО

MFO

Numeric

Код МФО банку

Bank

Character

Назва банку

Klients.dbf - Довідник клієнтів (постачальників і покупців)

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код клієнта

Name

Character

Повна назва клієнта

Address

Character

Адреса клієнта

Tel

Character

Телефони

Numeric

Розрахунковий рахунок

OKPO

Numeric

Код ОКПО

MFO

Numeric

Код МФО банку

Bank

Character

Назва банку

Doctype.dbf - Довідник типів накладних

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код

Name

Character

Назва документа

Coment

Character

Розшифровка назви

Sailtype.dbf - Довідник видів продажів

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код

Name

Character

Вид продажу

Coment

Character

Розшифровка виду

PriznDoc.dbf - Довідник ознак накладних

Назва поля

Тип

Довжина

Опис

Kod

Numeric

Код

Name

Character

Ознака накладної

Coment

Character

Розшифровка ознаки

Наступні дві бази в сукупності й представляють собою документ (в одному зберігаються шапки, в іншому - табличні частини)

DocumShp.dbf - Шапки документів

Назва поля

Тип

Довжина

Опис

Number

Character

Номер документа

Date

Дата оформлення документа

Type

Numeric

Тип накладної

Firm

Numeric

Фірма від якої випіс. накладна Sklad

Numeric

Склад для документа

Klient

Numeric

Клієнт на якого випіс. Наклей

Osnov

Character

Підстава документа

Positions

Numeric

Кількість позицій у накладній

SailType

Numeric

Вид продажу

Priznak

Numeric

Ознака накладної

Author

Numeric

Автор документа (співробітник)

Proveden

Logical

Пройшов Чи док-т по регістрах?

DocumTbl.dbf - Табличні частини документів

Назва поля

Тип

Довжина

Опис

Tovar

Numeric

Код товару

Kol

Numeric

Кількість

Price

Numeric

6,2

Ціна (по якій продали)

Docum

Character

Номер документа

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

Rests.dbf - Регістр залишків товарів

Назва поля

Тип

Довжина

Опис

Tovar

Numeric

Код товару

Sklad

Numeric

Склад

Rest

Numeric

Залишок товару

Motion.dbf - Регістр руху залишків

Назва поляОпісаніе

Tovar

Numeric

Товар

Kolvo

Numeric

Кількість

Date

Дата

Docnum

Character

Номер Документа

Duties.dbf - Регістр залишків взаєморозрахунків

Назва поля

Тип

Довжина

Опис

Klient

Numeric

Клієнт

Duty

Numeric

12,2

Поточний борг (або кредит)

Mduty.dbf - Регістр рухів взаєморозрахунків з клієнтами

Назва поля

Тип

Довжина

Опис

Klient

Numeric

Клієнт

Sum

Numeric

12,2

Сума

Date

Дата

Docum

Character

Номер документа

Тепер коротко опишемо призначення кожного довідника.

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

Довідник виробники зберігає код виробника та його повне найменування. Поле Coment призначене для додаткової інформації по виробнику.

Довідник склад містить код і назва всіх складів у системі.

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

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

Прибуткова накладна;

Видаткова накладна;

Рахунок;

Переміщення;

Податкова накладна

та інші.

Довідник види продажів може містити інформацію такого роду: зана; ЗаБН; Вкредіт. Що буде означати, як була проведена операція - за готівку, безготівкові гроші або в кредит.

Довідник співробітників зберігає всіх можливих користувачів системи і коротку інформацію про них, причому кожному з них можна вказати статус. Наприклад: 1-адміністратор;

2-Менеджер; 3-Бухгалтер, і т.д. А вже програміст визначить для кого які можливості доступні, а які недоступні.

Довідник ознак накладної зберігає інформацію Наступного виду, наприклад: 1-Продаж; 2-Повернення Постачальнику; 3 - Купівля; 4-Повернення Покупцю.

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

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

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

Регістри взаєморозрахунків ідентичні регістрів залишків, тільки враховують рух грошових коштів.

3.3. Опис програми

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

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

V. Висновки

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