ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    АТ місця
         

     

    Інформатика
    Автоматизація робочого місця менеджера МСП
    Введення
    Однією з найскладніших завдань для фірми, що займається торговельною діяльністю,
    є точний і упорядкований облік матеріальних засобів. При дуже великому
    обороті первинних документів стає дуже складним їх упорядкування. Як
    правило, багато фірм до цих пір, при такому стрімкому розвитку комп'ютерної
    техніки та програмного забезпечення, що не мають чітко налагодженого комп'ютерного
    обліку.
    Однією з проблем недосконалості методів ведення обліку - є
    недалекоглядність керівництва фірм. Та це факт, що це потребує чимало коштів,
    але якщо порахувати збитки від розрізненості обліку, розбіжності залишків на
    складі з залишками з документообігу і навіть просто спокою, а не
    нервозності у колективі, то стає очевидним, що фірмі потрібна
    автоматизація.
    Нехай для початку це буде невелика програма, з малим набором функцій, але
    правильною структурою, і безпомилковим рахунком і облік стане набагато простіше. Просто
    подумати про те, щоб побачити рух певного товару за останній
    місяць, при середній інтенсивності продажів, і стає зрозуміло, що при
    "Паперовому" обліку це просто нереально. Але при комп'ютерному обліку - немає нічого
    простіше (один запит).
    В даному курсовому проекті представлена довідкова частини програми,
    автоматизує складський облік на малих і середніх підприємствах. Найбільше
    увага в курсовому проекті направлено на побудову правильних структур баз
    даних, тобто на даталогіческое проектування.
     
    Глава 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 еталі, наочна і може бути легко змінена або
    доповнена. На базі спроектованої системи даних може бути написаний серйозний
    програмний продукт, який надалі може бути використаний дуже широким
    кругом фірм, що займаються торговельною діяльністю.



         
     
         
    Реферат Банк
     
    Рефераты
     
    Бесплатные рефераты
     

     

     

     

     

     

     

     
     
     
      Все права защищены. Reff.net.ua - українські реферати !