Автоматизація робочого місця менеджера МСП
Введення
Однією з найскладніших завдань для фірми, що займається торговельною діяльністю,
є точний і упорядкований облік матеріальних засобів. При дуже великому
обороті первинних документів стає дуже складним їх упорядкування. Як
правило, багато фірм до цих пір, при такому стрімкому розвитку комп'ютерної
техніки та програмного забезпечення, що не мають чітко налагодженого комп'ютерного
обліку.
Однією з проблем недосконалості методів ведення обліку - є
недалекоглядність керівництва фірм. Та це факт, що це потребує чимало коштів,
але якщо порахувати збитки від розрізненості обліку, розбіжності залишків на
складі з залишками з документообігу і навіть просто спокою, а не
нервозності у колективі, то стає очевидним, що фірмі потрібна
автоматизація.
Нехай для початку це буде невелика програма, з малим набором функцій, але
правильною структурою, і безпомилковим рахунком і облік стане набагато простіше. Просто
подумати про те, щоб побачити рух певного товару за останній
місяць, при середній інтенсивності продажів, і стає зрозуміло, що при
"Паперовому" обліку це просто нереально. Але при комп'ютерному обліку - немає нічого
простіше (один запит).
В даному курсовому проекті представлена довідкова частини програми,
автоматизує складський облік на малих і середніх підприємствах. Найбільше
увага в курсовому проекті направлено на побудову правильних структур баз
даних, тобто на даталогіческое проектування.
 
Глава 1. Технічне завдання на проектування
1.1. Постановка завдання
Виділимо предметну область. Це облік товарообігу на фірмі що займається
торговельною діяльністю. Сюди входить і облік товарів на складі (на декількох
складах), оформлення документів по відвантаженню і під час оприбуткування товару на склад,
ведення реєстру постачальників і покупців, облік взаєморозрахунків з юридичними та
приватними особами та отримання звітної інформації про його продаж.
Спроектувати всю систему цілком для навчальних цілей не має сенсу, тому в
даному проекті основним завданням ставиться правильна організації структури
збереження інформації (тобто структури баз даних.), алгоритмів вводу, читання,
коректування інформації. А сама програма є довідкову
систему, яка продемонструє приклад доступу до інформації, що зберігається.
1.2. Вимоги до системи.
Головною вимогою даного курсового проекту є правильні структури
даних, тому і вимоги до проектованої системі в основному будуть складатися
з вимог до правильної організації структур баз даних та їх взаємозв'язку.
Вимоги до розробляється системі:
Чітка і логічна структура баз даних;
Наявність мінімум третє нормальної форми для всіх створюваних структур даних;
Наявність логічно грамотних зв'язків між компонентами структури даних;
Способи отримання інформації з спроектованої системи.
Що стосується вимог до апаратних ресурсів, то тут все залежить від розмірів
автоматизується обліку, але для даного проекту достатнім буде платформа на
основі 386 процесора і операційної системи ДОС.
1.3. Користувачі системи
Дана проектована система призначена для дуже широкого кола
користувачів.
Першими користувачами цієї системи будуть комірник та/або менеджер, тому що вони
будуть вводить первинні документи. У міру потреби вони можуть видаляти
документи, змінювати вже існуючі документи, додавати інформацію про нові
покупців, формувати звіти для відстеження неточностей в обліку. Але цими
людьми коло користувачів не закінчується.
Система може бути використана бухгалтером для отримання інформації про суми
прибуткових і витратних накладних, догах постачальникам, і боргів клієнтів нам. Крім
того вони можуть брати участь в цій системі, наприклад, вводити виписки з банку,
коториебудут погашати заборгованості.
Для головного менеджера фірми система теж може становити інтерес. Наприклад,
він може подивитися обсяги продажів, товарообігу за певний період,
визначити товар користується, що приносить найбільший дохід (самий
товар, який продається) і отримати іншу статистичну інформацію.
1.4. Етапи розробки
Основними етапами розробки системи є:
розробка техніко-економічного обгрунтування проекту;
розробка технічного завдання на проектування;
збір вихідного матеріалу для проектування;
оформлення проекту (документування інформаційної системи та програмного
забезпечення, підготовка текстової записки);
подання курсового проекту на кафедру; захист курсового проекту в разі
написання курсового проекту, або передача системи замовнику і продовження
роботи з нею в режимі супроводу.
Терміни та склад робіт узгоджуються з викладачем і оформляються
представленим у додатках "Завданням на курсове проектування".
Приймання здійснюється викладачем шляхом надання студентом
демонстрації роботи системи на контрольних прикладах, захисту проектних і
програмних рішень.
Глава 2. Інфологіческое проектування
2.1. Обстеження предметної області.
Перш ніж розпочати будь-яке проектування необхідно проаналізувати предметну
область.
Для аналізу предметної області було вибрано конкретна фірма, і на її прикладі
досліджувалися інформаційні потреби менеджера, комірника, бухгалтера і
інших користувачів системи.
При більш детальному розгляді роботи менеджера був виявлений перелік
документів і типових операцій, необхідних для ведення обліку. Для оприбуткування
товару використовувалися документи або прибуткова накладна, або повернення від
покупця. Витрата товару оформлявся або видаткової накладної, або повернення
постачальнику.
Після виявлення повного переліку необхідних документів і виконуваних типових
операцій була розроблена складна структура баз даних (приведена нижче) основним
вимогою до якої - були універсальність, логічність, наочність.
Для проектування структур баз даних були формалізовані первинні документи
(виділено реквізитних мінімум, проаналізовано зв'язки між ними) і сформовані
структури записів БД. Потім шляхом нормалізації структур даних вони були зведені
до структур даних, що задовольняє вимогам 3нф.
2.2. Опис користувачів
Для даної системи може існувати безліч категорій
користувачів, але пропонована програма передбачає користувача, якому
необхідна довідкова інформація.
Для кожної гарної системи завжди повинен існувати адміністратор, який
супроводжуватиме систему, усувати помилки, а при розширенні предметної
області допрацьовувати програмні модулі.
Що стосується кінцевих користувачів, то тут можуть бути майже всі співробітники
фірми, причому для кожного співробітника може бути запрограмований тип доступу
(читання, зміна, додавання, видалення тощо) до документів, довідників,
регістрів та іншої інформації в системі.
2.3. Запити та регламентні задачі
Для проектованої системи основним запитом є запит на отримання
руху по певному товару за конкретний проміжок часу. Цей запит
виконується на підставі даних зберігаються в базах даних, які можна умовно
віднести до "Регістр".
Також у системі можуть реалізовані наступні запити:
інформація про борг клієнта (або нашому борг клієнту)
будь-яка інформація, яка може бути отримана на підставі документів
(наприклад, сума відвантажень клієнта за певний період, і ін)
Регламентний завданням для проектованої системи є розрахунок обсягів продажів
(наприклад, за готівковий або безготівковий розрахунок).
Для додається програми регламентним запитом є отримання інформації про
залишках товарів і рух товару за документами і висновок отриманої інформації в
відеоформу.
2.4. Опис алгоритму роботи системи
У цьому розділі, описується: яким чином повинна функціонувати
проектована система на підставі обраної предметної області.
Розглянемо ланцюжок документів, які необхідно оформити для відпуску товару
при розрахунку за безготівковий розрахунок.
Спочатку клієнт вибирає потрібний йому товар у необхідній кількості. На підставі
цієї заявки (можливо усній) менеджер виписує цьому клієнтові рахунок для оплати.
У випадку, якщо клієнт ще не існує в системі, то його необхідно додати.
Коли клієнтові виписаний рахунок, це не говорить про те, що товар клієнту відданий, але
документ у систему введений. Для цього цей вид документів не враховується в базах
враховують рух товарів (назвемо їх регістрами). Пізніше, коли клієнт
оплатив, виписаний йому рахунок, і гроші потрапили на наш розрахунковий рахунок, бухгалтер
вводить виписку з банку, відповідним документом, наприклад, "прихід грошей на
рахунок ". Відповідно в системі з'являється наш борг клієнту на суму, яку він
сплатив. Через деякий час клієнт приходить, щоб отримати свій товар і
тоді менеджер виписує йому видаткову накладну і податкову накладну за
безготівковим розрахунком (можна ввести на підставі раніше виписаного рахунку). При
виписуванні накладної система автоматично заносить інформацію про те, що
клієнтові був відданий товар на суму зазначену в накладній, і таким чином погашає
наш борг клієнта. Крім цього документ проходить по регістрах рухів та залишків
товарів, тобто інформація про кількість проданого товару заноситься в
відповідні бази даних.
На підставі виданої клієнту накладної, комірник віддає товар. Таким чином,
ми отримали чітку систему відвантаження товару.
Процедура відвантаження товару за готівковий розрахунок відбувається аналогічним чином,
тільки рахунок при цьому не виписується, гроші оформляються документом "прибутковий
касовий ордер "або іншим подібним і при оформленні накладних вказується що
продаж здійснена за готівковий розрахунок.
Надходження товару на склад може виникати в двох випадках. По-перше, при
надходження товару від постачальника, а по-друге, при поверненні товару від
покупця.
У першому випадку оформляється прибуткова накладна від постачальника за готівку або
безготівковий розрахунок, а гроші постачальнику (мається на увазі в системі) віддаємо
документом "платіжне доручення" або "видатковий касовий ордер" або іншим
документом.
Якщо оформляється повернення від покупця, то процедура ідентична, тільки в
накладної вказується відповідний ознака накладної.
2.5. Словник даних
Словник даних, необхідних для зберігання в проектованої системі виходить
дуже об'ємним. Тому зараз наводиться тільки словник даних для документів.
Для згаданих вище документів необхідно зберігати такі реквізити:
№ ппНаіменованіе елемента даннихІмяСкаляр/масив/вх/вих/расчетнийДліна
байтОграніченіе целосностіПрімечанія
1.Номер документаNumberСкаляр10Маска ##### Значення формується
автоматично
2.Дата оформленіяDateСкаляр8Маска 99.99.99
3.вид документаDocTypeСкаляр3Маска 999
4.Прізнак накладнойPriznakСкаляр3Маска 999Імеет сенс тільки для накладної
5.ФірмаFirmСкаляр20
6.КліентKlientСкаляр150
7.Від продажіSailTypeСкаляр20
8.СкладSkladСкаляр20
9.
10. Підстава для виписки документа OsnovСкаляр50
11.Автор документаAuthorСкаляр3Маска 999
12.Наіменованіе товара.TovarСкаляр70
13.Цена за едініцуPriceСкаляр, вхідні 10, 2Маска 9999999.99
14.Колічество KolСкаляр, вход10, 3Маска 999999.999
15.СуммаSumСкаляр, расчетний12, 2
16. НДСNDSСкаляр, расчетний12, 2
17ПроведенProvedenЛогіческій1 Проходить документ по регістрах чи ні

 
Глава 3. Даталогіческое проектування.
3.1. Вибір СУБД
Для реалізації спроектованої системи могла б підійти будь-яка СУБД середнього
рівня (наприклад, Microsoft Access). Але в рамках даного курсового проекту
система повинна бути реалізована в середовищі FoxPro. І ця система цілком підходить
для складання програми, яка обслуговує проектовану систему, а саме:
СУБД є спеціалізованою програмою для роботи з реляційними БД, що
значно спрощує процес даталогіческого проектування;
У неї потужний підхід, зручний для програмування додатків середньої
складності;
Наявність великої кількості майстрів дозволяє швидко створювати зручний для
кінцевих користувачів інтерфейс, формувати красиві звіти
Ця система дуже вимоглива до апаратних ресурсів і може виконуватися на
будь-якому комп'ютері на якому встановлена система Windows (та сама СУБД)
Окремі утиліти дозволяють створювати кінцевий виконуваний файл, і тоді це
дуже значно спрощує розповсюдження програми.
 
3.2. Даталогіческая модель
Після докладного аналізу предметної області на етапі інфологіческого
проектування були отримані реквізити баз даних. Після цього було вироблено
розподіл цих реквізитів по записах БД, потім бази були декомпозіровани до
тих пір, поки не вийшли структури, що задовольняють вимогам третього
нормальної форми і володіють мінімальної надмірністю (хоча надмірність
повинна бути присутнім для прискорення процесів обробки інформації). В
результаті були отримані файли баз даних з наступними структурами:
Спочатку наведемо бази, які можна умовно віднести до довідників. Це
означає, що в них зберігається інформація, яка використовується іншими базами.
 
Tovar.dbf - Довідник товарів
Назва поляТіпДлінаОпісаніе
KodNumeric5Код товару
NameCharacter20Наіменованіе товару
PriceInNumeric6, 2Входная ціна
PriceOutNumeric6, 2Продажная ціна
UnitCharacter5Едініца вимірювання
ProizvodNumeric3Код виробника

Proizv.dbf - Довідник з виробниками
Назва поляТіпДлінаОпісаніе
KodNumeric3Код виробника
NameCharacter10Полное назва виробника
ComentCharacter30Інформація про виробника

Sklad.dbf - Довідник складів
Назва поляТіпДлінаОпісаніе
KodNumeric3Код складу
NameCharacter25Полное назва складу

Users.dbf - Довідник користувачів системи
Назва поляТіпДлінаОпісаніе
KodNumeric2Код співробітника
NameCharacter25Імя та По-батькові співробітника
PassportCharacter15Серія і номер паспорта
AddressCharacter50Адрес співробітника
StatusNumeric1Статус співробітника як користувача

Firms.dbf - Довідник фірм за якими ведеться облік
Назва поляТіпДлінаОпісаніе
KodNumeric2Код фірми
NameCharacter25Полное назва фірми
AddressCharacter50Адрес фірми
TelCharacter15Телефони
RSNumeric14Расчетний рахунок
OKPONumeric8Код ОКПО
MFONumeric6Код МФО банку
BankCharacter15Названіе банку

Klients.dbf - Довідник клієнтів (постачальників і покупців)
Назва поляТіпДлінаОпісаніе
KodNumeric2Код клієнта
NameCharacter25Полное назва клієнта
AddressCharacter50Адрес клієнта
TelCharacter15Телефони
RSNumeric14Расчетний рахунок
OKPONumeric8Код ОКПО
MFONumeric6Код МФО банку
BankCharacter15Названіе банку

Doctype.dbf - Довідник типів накладних
Назва поляТіпДлінаОпісаніе
KodNumeric3Код
NameCharacter10Названіе документа
ComentCharacter30Расшіфровка назви

Sailtype.dbf - Довідник видів продажів
Назва поляТіпДлінаОпісаніе
KodNumeric1Код
NameCharacter10Від продажу
ComentCharacter30Расшіфровка виду

PriznDoc.dbf - Довідник ознак накладних
Назва поляТіпДлінаОпісаніе
KodNumeric1Код
NameCharacter10Прізнак накладної
ComentCharacter30Расшіфровка ознаки

Наступні дві бази в сукупності й представляють собою документ (в одному
зберігаються шапки, в іншому - табличні частини)
DocumShp.dbf - Шапки документів
Назва поляТіпДлінаОпісаніе
NumberCharacter10Номер документа
DateDate8Дата оформлення документа
TypeNumeric3Тіп накладної
FirmNumeric3Фірма від якої випіс. накладна
SkladNumeric3Склад для документа
KlientNumeric3Кліент на якого випіс. Наклей
OsnovCharacter50Основаніе документа
PositionsNumeric3Колічество позицій у накладній
SailTypeNumeric1Від продажу
PriznakNumeric1Прізнак накладної
AuthorNumeric2Автор документа (співробітник)
ProvedenLogical1Прошел чи док-т по регістрах?

DocumTbl.dbf - Табличні частини документів
Назва поляТіпДлінаОпісаніе
TovarNumeric5Код услуги
KolNumeric4Колічество
PriceNumeric6, 2Цена (по якій продали)
DocumCharacter10Номер документа

Наступна і остання група являє собою бази в яких відображається
реальний рух чого-небудь. Назвемо їх регістрами.
Rests.dbf - Регістр залишків товарів
Назва поляТіпДлінаОпісаніе
TovarNumeric5Код товару
SkladNumeric3Склад
RestNumeric5Остаток товару

Motion.dbf - Регістр руху залишків
Назва поляОпісаніе
TovarNumeric5Товар
KolvoNumeric4Колічество
DateDate8Дата
DocnumCharacter10Номер Документа

Duties.dbf - Регістр залишків взаєморозрахунків
Назва поляТіпДлінаОпісаніе
KlientNumeric3Кліент
DutyNumeric12, 2Текущій борг (або кредит)

Mduty.dbf - Регістр рухів взаєморозрахунків з клієнтами
Назва поляТіпДлінаОпісаніе
KlientNumeric3Кліент
SumNumeric12, 2Сумма
DateDate8Дата
DocumCharacter10Номер документа

Тепер коротко опишемо призначення кожного довідника.
Довідник товарів призначений для зберігання товарів. Причому код повинен бути
унікальним у всьому довіднику. Кожен товар має прибуткову і продажну ціни,
од. вимірювання і виробника, який зберігається в довіднику виробники.
Довідник виробники зберігає код виробника та його повне найменування.
Поле Coment призначене для додаткової інформації по виробнику.
Довідник склад містить код і назва всіх складів у системі.
У довіднику клієнтів зберігається вся необхідна інформація про фірму-покупця
чи фірму-постачальника. У той час як у довіднику фірм зберігається інформація про
наших фірмах, тобто фірмах від імені яких ми працюємо.
Довідник Вид Накладной зберігає в собі всі види документів, які можуть бути
видані системою. Наприклад:
Прибуткова накладна;
Видаткова накладна;
Рахунок;
Переміщення;
Податкова накладна
та інші.
Довідник види продажів може містити інформацію такого роду: зана; ЗаБН;
Вкредіт. Що буде означати, як була проведена операція - за готівку,
безготівкові гроші або в кредит.
Довідник співробітників зберігає всіх можливих користувачів системи і коротку
інформацію про них, причому кожному з них можна вказати статус. Наприклад:
1-Адміністратор;
2-Менеджер; 3-Бухгалтер, і т.д. А уже програміст визначить для кого які
можливості доступні, а які недоступні.
Довідник ознак накладної зберігає інформацію Наступного виду, наприклад:
1-Продаж; 2-Повернення Постачальнику; 3 - Купівля; 4-Повернення Покупцю.
База даних в якій зберігаються шапки документів - просто зберігає всі необхідні
реквізити документа. Унікальним у всій системі є номер документа. Він
спеціально оголошений текстовим. За цим номером в базі, яка зберігає табличні
частини, ми може відшукати ті позиції, які належать до цього документа. Якщо
побудувати індексний файл по полю Number (він побудований в системі), то став на
перший елемент, що відповідає цьому документу, можна отримати всі інші
елементи по порядку, тому що в шапці документа зберігається кількість рядків у ньому.
Регістри залишків товарів зберігають залишки товарів по кожному складу в
окремо. Виходить як таблиця, де стовпці відповідають складам, а рядки
- Товарам, а на перетині - буде кількість товару на конкретному складі.
У регістрі руху залишків товарів відображається кожна операція, над цим
товаром (прихід чи витрата) і вказується, який документ здійснив дане
рух і коли.
Регістри взаєморозрахунків ідентичні регістрів залишків, тільки враховують рух
грошових коштів.
3.3. Опис програми
Програма є довідкову систему, яка покликана показати,
яким чином можна отримати доступ до заносяться в систему інформації. В
програмі реалізована система додавання нового товару, як приклад долучення
інформації в довідник.
Сама програма пропонує вибрати товар і показує всю інформацію про товар,
залишок цього товару на складі, і всі рухи з даного товару. Нижче наведені
види екранів.
V. Висновки
У результаті спроектована надійна, логічна, гнучка структура даних, яка
задовольняє вимогам 3 еталі, наочна і може бути легко змінена або
доповнена. На базі спроектованої системи даних може бути написаний серйозний
програмний продукт, який надалі може бути використаний дуже широким
кругом фірм, що займаються торговельною діяльністю.