ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 05.12.2023
Просмотров: 453
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Автоматизация рабочего места менеджера МСПВведениеОдной из самых сложных задач для фирмы, занимающейся торговой деятельностью, является точный и упорядоченный учет материальных средств. При очень большом обороте первичных документов становится очень сложным их упорядочивание. Как правило, многие фирмы до сих пор, при таком стремительном развитии компьютерной техники и программного обеспечения, не имеют четко отлаженного компьютерного учета.Одной из проблем несовершенства методов ведения учета – является недальновидность руководства фирм. Да это факт, что это требует немало средств, но если посчитать убытки от разрозненности учета, несовпадения остатков на складе с остатками по документообороту и даже просто спокойствия, а не нервозности в коллективе, то становится очевидным, что фирме нужна автоматизация.Пусть для начала это будет небольшая программа, с малым набором функций, но правильной структурой, и безошибочным счетом и учет станет гораздо проще. Просто подумать о том, чтобы посмотреть движение определенного товара за последний месяц, при средней интенсивности продаж, и становится понятно, что при “бумажном” учете это просто нереально. Но при компьютерном учете – нет ничего проще (один запрос).В данном курсовом проекте представлена справочная часть программы, автоматизирующей складской учет на малых и средних предприятиях. Наибольшее внимание в курсовом проекте направлено на построение правильных структур баз данных, т.е. на даталогическое проектирование.Глава 1. Техническое задание на проектирование1.1. Постановка задачиВыделим предметную область. Это учет товарооборота на фирме занимающейся торговой деятельностью. Сюда входит и учет товаров на складе ( на нескольких складах), оформление документов по отгрузке и при оприходовании товара на склад, ведение реестра поставщиков и покупателей, учет взаиморасчетов с юридическими и частными лицами и получение отчетной информации о продажах.Спроектировать всю систему целиком для учебных целей не имеет смысла, поэтому в данном проекте основной задачей ставится правильная организации структуры хранения информации (т.е. структуры баз данных.), алгоритмов ввода, чтения, корректировки информации. А сама программа представляет собой справочную систему, которая продемонстрирует пример доступа к хранимой информации.
1.2. Требования к системе.Главным требованием данного курсового проекта является правильные структуры данных, поэтому и требования к проектируемой системе в основном будут состоять из требований к правильной организации структур баз данных и их взаимосвязи.Требования к разрабатываемой системе:
Сроки и состав работ согласовываются с преподавателем и оформляются представленным в приложениях “Заданием на курсовое проектирование”.Приемка осуществляется преподавателем путем предоставления студентом демонстрации работы системы на контрольных примерах, защиты проектных и программных решений.Глава 2. Инфологическое проектирование2.1. Обследование предметной области.Прежде чем начать любое проектирование необходимо проанализировать предметную область.Для анализа предметной области была выбрана конкретная фирма, и на ёё примере исследовались информационные потребности менеджера, кладовщика, бухгалтера и других пользователей системы.При более подробном рассмотрении работы менеджера был выявлен перечень документов и типовых операций, необходимых для ведения учета. Для оприходования товара использовались документы либо приходная накладная, либо возврат от покупателя. Расход товара оформлялся либо расходной накладной, либо возврат поставщику.После выявления полного перечня необходимых документов и выполняемых типовых операций была разработана сложная структура баз данных (приведена ниже) основным требованием к которой - были универсальность, логичность, наглядность.Для проектирования структур баз данных были формализованы первичные документы (выделен реквизитный минимум, проанализированы связи между ними) и сформированы структуры записей БД. Затем путем нормализации структур данных они были сведены к структурам данных, удовлетворяющим требованиям 3нф.2.2. Описание пользователейДля рассматриваемой системы может существовать большое множество категорий пользователей, но предлагаемая программа предполагает пользователя, которому необходима справочная информация.Для каждой хорошей системы всегда должен существовать администратор, который будет сопровождать систему, устранять ошибки, а при расширении предметной области дорабатывать программные модули.Что касается конечных пользователей, то тут могут быть почти все сотрудники фирмы, причем для каждого сотрудника может быть запрограммирован тип доступа (чтение, изменение, добавление, удаление и др.) к документам, справочникам, регистрам и другой информации в системе.2.3. Запросы и регламентные задачиДля проектируемой системы основным запросом является запрос на получение движения по определенному товару за конкретный промежуток времени. Этот запрос выполняется на основании данных хранящихся в базах данных, которые можно условно отнести к “Регистрам”.
Также в системе могут реализованы следующие запросы:
Поступление товара на склад может возникать в двух случаях. Во-первых, при поступлении товара от поставщика, а во-вторых, при возврате товара от покупателя.В первом случае оформляется приходная накладная от поставщика за наличный или безналичный расчет, а деньги поставщику (подразумевается в системе) отдаем документом “платежное поручение” или “расходный кассовый ордер” или другим документом.Если оформляется возврат от покупателя, то процедура идентична, только в накладной указывается соответствующий признак накладной.2.5. Словарь данныхСловарь данных, необходимых для хранения в проектируемой системе получается очень объемным. Поэтому сейчас приводится только словарь данных для документов. Для упомянутых выше документов необходимо сохранять следующие реквизиты:
1.2. Требования к системе.Главным требованием данного курсового проекта является правильные структуры данных, поэтому и требования к проектируемой системе в основном будут состоять из требований к правильной организации структур баз данных и их взаимосвязи.Требования к разрабатываемой системе:
-
Четкая и логичная структура баз данных; -
Наличие минимум третьей нормальной формы для всех создаваемых структур данных; -
Наличие логически грамотных связей между компонентами структуры данных; -
Способы получения информации из спроектированной системы.
-
разработка технико-экономического обоснования проекта; -
разработка технического задания на проектирование; -
сбор исходного материала для проектирования; -
оформление проекта (документирование информационной системы и программного обеспечения, подготовка текстовой записки); -
представление курсового проекта на кафедру; защита курсового проекта в случае написания курсового проекта, либо передача системы заказчику и продолжение работы с ней в режиме сопровождения.
Сроки и состав работ согласовываются с преподавателем и оформляются представленным в приложениях “Заданием на курсовое проектирование”.Приемка осуществляется преподавателем путем предоставления студентом демонстрации работы системы на контрольных примерах, защиты проектных и программных решений.Глава 2. Инфологическое проектирование2.1. Обследование предметной области.Прежде чем начать любое проектирование необходимо проанализировать предметную область.Для анализа предметной области была выбрана конкретная фирма, и на ёё примере исследовались информационные потребности менеджера, кладовщика, бухгалтера и других пользователей системы.При более подробном рассмотрении работы менеджера был выявлен перечень документов и типовых операций, необходимых для ведения учета. Для оприходования товара использовались документы либо приходная накладная, либо возврат от покупателя. Расход товара оформлялся либо расходной накладной, либо возврат поставщику.После выявления полного перечня необходимых документов и выполняемых типовых операций была разработана сложная структура баз данных (приведена ниже) основным требованием к которой - были универсальность, логичность, наглядность.Для проектирования структур баз данных были формализованы первичные документы (выделен реквизитный минимум, проанализированы связи между ними) и сформированы структуры записей БД. Затем путем нормализации структур данных они были сведены к структурам данных, удовлетворяющим требованиям 3нф.2.2. Описание пользователейДля рассматриваемой системы может существовать большое множество категорий пользователей, но предлагаемая программа предполагает пользователя, которому необходима справочная информация.Для каждой хорошей системы всегда должен существовать администратор, который будет сопровождать систему, устранять ошибки, а при расширении предметной области дорабатывать программные модули.Что касается конечных пользователей, то тут могут быть почти все сотрудники фирмы, причем для каждого сотрудника может быть запрограммирован тип доступа (чтение, изменение, добавление, удаление и др.) к документам, справочникам, регистрам и другой информации в системе.2.3. Запросы и регламентные задачиДля проектируемой системы основным запросом является запрос на получение движения по определенному товару за конкретный промежуток времени. Этот запрос выполняется на основании данных хранящихся в базах данных, которые можно условно отнести к “Регистрам”.
Также в системе могут реализованы следующие запросы:
-
информация о долге клиента (или нашем долге клиенту) -
любая информация, которая может быть получена на основании документов (например, сумма отгрузок клиенту за определенный период, и др.)
Поступление товара на склад может возникать в двух случаях. Во-первых, при поступлении товара от поставщика, а во-вторых, при возврате товара от покупателя.В первом случае оформляется приходная накладная от поставщика за наличный или безналичный расчет, а деньги поставщику (подразумевается в системе) отдаем документом “платежное поручение” или “расходный кассовый ордер” или другим документом.Если оформляется возврат от покупателя, то процедура идентична, только в накладной указывается соответствующий признак накладной.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 | | Проходит документ по регистрам или нет |