Разработка автоматизированного рабочего места менеджера по продажам ООО "ТиЭль-Плюс"

СОДЕРЖАНИЕ
СПИСОК УСЛОВНЫХ ОБОЗНАЧЕНИЙ И СОКРАЩЕНИЙ
ВВЕДЕНИЕ
І АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1 Технико-экономическая ООО «Ти эль плюс»
1.1.1 Характеристика предприятия и его деятельности
1.1.2. Организационная структура управления предприятием
1.2 Характеристика комплекса задач, задачи и обоснование необходимости автоматизации
1.2.1 Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов
1.2.2 Определение места проектируемой задачи в комплексе задач и ее описание
1.2.3 Обоснования необходимости использования вычислительной техники для решения задачи
1.3 Анализ существующих разработок и выбор стратегии автоматизации
1.3.1 Анализ существующих разработок для автоматизации задачи
1.3.2 Выбор и обоснование стратегии автоматизации задачи
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач
1.4 Обоснование проектных решений
1.4.1 Обоснование проектных решений по техническому обеспечению
1.4.2 Обоснование проектных решений по информационному обеспечению
1.4.3 Обоснование проектных решений по программному обеспечению
II ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
2.2.2. Используемые классификаторы и системы кодирования
2.2.3. Характеристика нормативно-справочной, входной и оперативной информации
2.2.4 Характеристика результатной информации
2.3 Описание программного проекта
2.3.1.Общие положения
2.3.2. Характеристика базы данных
2.3.3 Структурная схема пакета
2.3.4 Описание программных модулей
2.4 Технологическое обеспечение
2.5 Контрольный пример реализации проекта и его описание
III ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРОЕКТА
3.1 Выбор и обоснование методики расчёта экономической эффективности
3.2 Расчёт показателей экономической эффективности проекта
ЗАКЛЮЧЕНИЕ
ЛИТЕРАТУРА
ПРИЛОЖЕНИЕ Листинг разработанной программы

Разработка автоматизированного рабочего места менеджера по продажам ООО "ТиЭль-Плюс"

Отношение находится в третьей нормальной форме, если отсутствует взаимосвязь между не ключевыми атрибутами. Выделение в одно отношение атрибутов с одной и той же зависимостью от ключевого атрибута, использование атрибутов, определяющих зависимость, в качестве первичного ключа нового отношения и установки связи от нового отношения к старому.
Четвертая нормальная форма запрещает хранить независимые атрибуты в одном и том же отношении, когда между этими атрибутами существует связь вида «многие ко многим».
Рассмотренные выше нормальные формы относятся к методу декомпозиции на основе функциональных зависимостей, который является пригодным при условии небольшого числа задействованных атрибутов. В данном случае число атрибутов существенно усложняют применение этого метода. Поэтому применим метод «сущность-связь» (entity-relation), который отличается от метода декомпозиции тем, что функциональные зависимости привлекаются не на начальном, а на конечном этапе проектирования.
Сущность – некоторый объект, имеющий экземпляры, отличающиеся друг от друга и допускающие однозначную идентификацию.
Связь – соединение между двумя или более сущностями.
Атрибут – это свойство сущности. Если атрибут или набор атрибутов используется для идентификации экземпляра сущности, то называется ключом сущности. Важной характеристикой связи между двумя (и более) сущностями является степень связи: «один к одному», «один ко многим», «многие ко многим». Экземпляры сущности, участвующие в связи, делятся на класс принадлежности: обязательные или необязательные. После построения диаграмм ER-типа, из них получают отношения, анализируя степень связи между сущностями. Логическая модель проектируемой базы данных представлена.
Каждый элемент сущности обладает конкретными значениями атрибутов, причем не существует двух разных элементов с одинаковыми значениями. В процессе анализа предметной области были выделены следующие сущности:
Для успешной работы программного обеспечения поиска программных продуктов необходимо определение входной и выходной информации.
В качестве входной информации для поиска компьютерных комплектующих используется значение поля – ключа. В качестве ключевых полей при поиске программного обеспечения необходимо использовать поля:
- название комплектующей детали;
-срок гарантированной работы;
- фирма-поставщик;
- номер и дата накладной на проведение операции;
В качестве выходной информации рассматривается результат поиска – список записей удовлетворяющих условию поиска, с настраиваемым сочетанием полей.
Описание информационных объектов ПО. Для реализации функций информационной модели системы учета движения товаров необходимо наличие нескольких взаимосвязанных таблиц, описание которых представлено в табл.2.3
Данные таблицы необходимо реализовать в среде MS SQL Server 2005, по ключевым полям, для этого необходимо разработать концептуальную схему информационной модели.
Таблицы попарно связаны между собой через ключи связи, что существенно упрощает их обработку, так как автоматически обеспечивается контроль целостности данных.
Таблица 2.3
Содержание таблиц базы данных
№ п/п
Название таблицы
Назначение
1.
Tovar
Таблица содержащая данные о комплектующих и готовых компьютерах фирмы на складе и ссылочные поля на другие таблицы
2.
Nakladnaya
Таблица, содержащая информацию о накладных на комплектующие (компьютеры)
3.
Zapas
Таблица, содержащая информацию о «запасах» того или иного материала
4.
Zakaz
Таблица, содержащая информацию о заказах на получение материалов
5.
Location
Таблица, содержащая информацию о размещении материала на складе.
6.
Addional
Таблица, содержащая дополнительную информацию о товарах на складе
7.
Pokup
Таблица, содержащая информацию о покупателях
8.
partya
Таблица, содержащая информацию о партиях поступления материалов на склад.
Каждую из таблиц описанных выше введем индексное поле, с помощью которых решим задачи связи информационных таблиц. В результате, объединив необходимые ссылки, получим концептуальную схему информационной модели
Разработанная информационная модель позволит эффективно решать задачи информационного поиска и учета материальных средств на находящихся в обороте ООО «Ти Эль Плюс».
Для реализации функций информационной модели системы поиска программного продукта необходимо наличие нескольких взаимосвязанных таблиц, описание которых представлено в табл. 2.3-2.11 рис. 2.20-2.27.
Таблица 2.4
Назначение полей таблицы Tovar
№
п/п
Название поля
Тип
Назначение
1.
idTovar
Целое
Индексное поле – первичный ключ таблицы Tovar.
2.
NameTovar
Символьное
Поле содержит информацию о наименовании материальной ценности хранящейся на складе
3.
idLocation
Целое
Поле содержит ссылку на запись в таблице Location, содержащей информацию о размещении данной материальной ценности
4.
idAdditional
Целое
Поле содержит ссылку на запись в таблице Additional, содержащей дополнительную информацию о данной материальной ценности
5.
IdZapas
Целое
Поле содержит ссылку на запись в таблице Zapas, содержащей информацию о «запасах» на складе данной материальной ценности
6.
idPartya
Целое
Поле содержит ссылку на запись в таблице Partya, содержащей дополнительную информацию о партии товара с которой поступила данная материальной ценность
Рисунок 2.20. – Реализация таблицы Tovar средствами MS SQL 2005
Таблица 2.5
Назначение полей таблицы Nakladnaya
№
п/п
Название поля
Тип
Назначение
1.
idNakladnaya
Целое
Индексное поле – первичный ключ таблицы Nakladnaya.
2.
vremya
Дата-время
Дата создания накладной
3.
idTovar
Целое
Поле содержит ссылку на запись в таблице Tovar, идентифицирующей данную материальную ценность
4.
otkuda
Символьное
Место откуда перемещается материальная ценность
5.
kuda
Символьное
Место, назначения перемещения материальной ценности
6.
kolichestvo
Символьное
Количество запасов мат. Ценности необходимое для перемещения
7.
stoimost
Действит.
Суммарная стоимость материальной ценности в накладной
8.
idPartya
Целое
Поле содержит ссылку на запись в таблице Partya, содержащей дополнительную информацию о партии товара с которой поступила данная материальной ценность
9.
idPokup
Целое
Поле содержит ссылку на запись в таблице Pokup, содержащей дополнительную информацию о покупателе товара
10.
Lico
Символьное
Фамилия лица, на которого оформлена накладная
11.
Provodka
Символьное
Признак выполнения проводки накладной
12.
IdZakaz
Целое
Поле содержит ссылку на запись в таблице Zakaz, содержащей информацию о заказе согласно которому составлена накладная
Рисунок 2.21 Реализация таблицы Nakladnaya средствами MS SQL 2005
Таблица 2.6
Назначение полей таблицы Zapas
№
п/п
Название поля
Тип
Назначение
1.
idZapas
Целое
Индексное поле – первичный ключ таблицы Zapas.
2.
izmerenie
Символьное
Поле для хранения единицы измерения данной материальной ценности
3.
zapas
Целое
Поле для хранения величины запаса данной материальной ценности.
4.
Stoimost
Действит.
Поле для хранения велицины стоимости данной материальной ценности.
5.
Rezerv_kol
Целое
Поле содержит информацию о количестве единиц данной материальной ценности зарезервированной (забронированной)
6.
Rezerv_name
Символьное
Поле содержит информацию о лице, зарезервировавшем данную материальную ценность
7.
Rezerv_date
Дата/время
Поле содержит дату резервирования ценности
8.
Reserve_prim
Символьное
Поле содержит символьное примечание по вопросам резервирования.
Таблица 2.7
Назначение полей таблицы Zakaz
№
п/п
Название поля
Тип
Назначение
1.
id Zakaz
Целое
Индексное поле – первичный ключ таблицы Zakaz.
2.
Kogda
Дата/время
Поле для хранения даты заказа
3.
Lico
Символьное
Поле для хранения фамилии лица сделавшего заказ
4.
idTovar
Целое
Поле содержит ссылку на запись в таблице Tovar, идентифицирующей данную материальную ценность
5.
kolichestvo
Целое
Поле для хранения размер заказа
Рисунок 2.22 – Реализация таблицы Zapas средствами MS SQL 2005
Рисунок 2.23 – Реализация таблицы Zakaz средствами MS SQL 2005
Таблица 2.8
Назначение полей таблицы Location
№
п/п
Название поля
Тип
Назначение
1.
idLocation
Целое
Индексное поле – первичный ключ таблицы Location.
2.
Location
Символьное
Поле для хранения размещения материальной ценности на складе
3.
additionalLocation
Символьное
Поле для хранения уточнения для размещения материальной ценности на складе
4.
notes
Символьное
Поле для хранения примечания о размещении материальной ценности на складе
Рисунок 2.24 Реализация таблицы Location средствами MS SQL 2005
Таблица 2.9
Назначение полей таблицы Addional
№
п/п
Название поля
Тип
Назначение
1.
Id Addional
Целое
Индексное поле – первичный ключ таблицы Addional.
2.
Ser_num
Символьное
Поле для хранения серийного номера материальной ценности определенной партии товара
3.
Srok_godnost
Символьное
Поле для хранения срока годности материальной ценности, хранящейся на складе.
Рисунок 2.25 – Реализация таблицы Addional средствами MS SQL 2005
Таблица 2.10
Назначение полей таблицы partya
№
п/п
Название поля
Тип
Назначение
1.
Idpartya
Целое
Индексное поле – первичный ключ таблицы partya.
2.
NOM_part
Символьное
Поле для хранения номера партии поступившего товара
3.
kolichestvo
целое
Размер партии товара
4.
Otkuda
Символьное
Поставщик товара
5.
Kogda
Дата/время
Дата поступления партии товара
6.
Description
Символьное
Дополнительное описание партии товара
Рисунок 2.26.– Реализация таблицы partya средствами MS SQL 2005
Таблица 2.11
Назначение полей таблицы Pokup
№
п/п
Название поля
Тип
Назначение
1.
Idpokup
Целое
Индексное поле – первичный ключ таблицы pokup.
2.
Naimenovan
Символьное
Поле для ФИО или название организации покупателя.
3.
adres
Символьное
адрес покупателя
4.
bank_rekv
Символьное
Поле для хранения банковских реквизитов покупателя.
Рисунок 2.27.– Реализация таблицы pokup средствами MS SQL 2005
В результате препарирования - информационная модель была успешно реализована в среде MS SQL 2005. Концептуальная модель базы данных представлена на рис.2.28
Рисунок 2.28 – Концептуальная модель базы данных созданная в среде Microsoft SQL Server 2005
2.3.3 Структурная схема пакета
В программном обеспечении АРМ менеджера можно выделить серверную и клиентскую часть. На серверную часть возлагаются функции хранения БД и архива, а так же поддержки целостности данных, обработка запросов, управление транзакциями. На клиентскую часть возлагается обеспечение интерфейса пользователя, посылка запросов серверу БД (серверной части системы), получение результатов и сообщений от сервера, управление бизнес-правилами, проверку корректности, допустимости и обработку данных согласно содержащихся в них алгоритмах.
В среде БД клиент-сервер, сервер должен обеспечить целостность данных. Сервер использует несколько механизмов поддержания целостности:
Для обеспечения целостности данных в БД были реализованы:
совместное удаление зависимых данных;
поддержка внешних ключей;
централизованное хранение данных на сервере;
восстановление данных в исключительных ситуациях из архива;
контроль входных данных.
Для обеспечения функциональности ПП осуществляется:
управление данными (вставка, редактирование, удаление данных);
выдача результатов на запросы пользователей;
формирование отчетов для просмотра и вывод на печать.
Структура разработанного проекта представлена на рисунках 2.29-2.32 .
Задача эксплуатируется в среде Windows 98, Windows XP и выше.
Серверная часть программного обеспечения функционирует под управлением сетевой платформы Microsoft WINDOWS 2000 и выше. В качестве СУБД используется СУБД Microsoft SQL Server 2000.
Доступ к сетевым ресурсам осуществляется через соответствующие драйверы по протоколу TCP/IP. Для связи клиентского приложения с серверной частью задачи на каждой рабочей станции должны быть установлено BDE v. 5.0 – средства связи с базой данных SQL Server.
Рисунок 2.29 -Дерево диалога
Рисунок 2.30 – Структура разработанного программного проекта
Рисунок 2.31 – Структура разработанного проекта.
Рисунок 2.32 – Состав программного проекта
Разработанное приложение состоит из 5 модулей MainClients.pas, childTemplate.pas, DbdDirectoryTemplate.pas, AddSource.pas, ParamPoisk.pas.
2.3.4 Описание программных модулей
Структура разработанного проекта представлена на рис. 23. Разработанное приложение состоит из 5 модулей MainClients.pas, childTemplate.pas, DbdDirectoryTemplate.pas, AddSource.pas, ParamPoisk.pas.
Назначение главного модуля приложения MainClients.pas . Выборка, обработка, поиск данных, редактирование, добавление, удаление данных. Данная разработка предназначена для автоматизации действий менеджера склада ООО «Ти Эль Плюс», проводящего учет и выдачу материалов.
Модуль является главным и управляющим для остальных объектов проекта.
Интерфейс модуля определяется формой MainClients приложения, внешний вид которого представлен на рис.2.33.
Рисунок 2.33 – Внешний вид главной формы разработанного приложения.
Алгоритм работы главного модуля можно кратко описать следующей последовательностью действий. При загрузке модуля ожидается выбор одной из альтернатив главного меню. В зависимости от выбранной альтернативы главного меню происходит активация соответствующей процедуры, и синтез необходимых дочерних форм. После этого вычислительные процесс ожидает задействования элементов управления, которые могут приводить к запуску различных программных процедур, входящих в состав проекта.
Исходными данными для данного программного продукта являются первичные документы:
1. Заказы на поставку продукции;
2. накладные на поставку продукции.
Выходными данными являлись: бумажные носители информации, подготовленные автоматизированной подсистемой учета складских операций, файлы базы данных а так же информация на магнитных носителях.
Разрабатываемое предложение состоит из 5 форм, одна из которых является главной, остальные формы являются дочерними по отношению к ней. Внешний вид главной формы приложения MainClientsForm, представлен на рис.2.34.
Рисунок 2.34 – Главная форма приложения
Главная форма приложения содержит элементы управления – главное меню рис.2.34, с помощью которого и осуществляется работа всей системы, управление вычислительным процессом, организуется обмен данными и обеспечивается создание всех остальных форм приложения.
Как видно на рис.2.34 главная форма приложения MainClientsForm, также содержит компоненты, обеспечивающие взаимодействие приложения с базой данной, реализованной в СУБД MS SQL 2005 : компонент AdoConnection, компонент DataSource, 2 компонента AdoQuery, 7 компонентов AdoTable1, соответствующих каждой из таблиц базы данных
Главное меню приложения содержит альтернативы «файл», «просмотр», «создать», «поиск», «проводка накладных». Альтернатива «Просмотр» позволяет получить справочную информацию о каждой из таблиц базы данных, (рис. 2.35), а та же просмотреть записи всей базы данных в целом, для этого необходим выбор альтернативы «просмотр базы данных» (рис. 2.35).
Рисунок – 2.35 Пункт главного меню «просмотр»
В результате выполнения выбора альтернативы «просмотр БД», происходит создание двух дочерних форм DBDirectoryTemplateForm и AddSource. Форма DBDirectoryTemplateForm расположена на рис. 27 в верхней части позволяет отобразить записи таблицы товары, перемешаться, редактировать, обновлять которые позволяет компонент DBNavigator, расположенный на форме AddSource. Динамически создаваемая форма AddSource предназначена для отображения записей, находящейся в различных таблицах базы данных firm2 и связанных с записями расположенными в таблице Tovar.
Динамически создаваемая дочерняя форма AddSource, может использоваться не только для отображения связанных записей. Главное назначение формы AddSource это создание интерфейсов для добавления новых товаров, накладных, заказов (рис.2.36).
Альтернатива «создать» содержит альтернативы «поступление заказа», «накладную», «поступление товара». Альтернатива «поиск», содержит альтернативы «наличие товара», «срок гарантированной работы», «размещение товара», «хронология накладных». Таким образом, пункты главного меню позволяют полностью управлять ходом вычислительного процесса и работой приложения.
Форма DBDirectoryTemplateForm создается при выборе альтернатив меню «просмотр», и позволяет просматривать все таблицы базы данных. Это достигается изменением источника данных компонента DBGrid, расположенного на динамически создаваемой форме и выбираемого источника данных – таблицы в соответствии с пунктом меню.
Рисунок 2.37 – Дочерняя форма AddSource, динамически создаваемая для добавления информации о товарах и комплектующих
Элементы управления компоненты Button («Добавить», «Создать заявку», «Создать накладную») активируют процедуры, соответствующие названным действиям. Все процедуры функционируют по типизированным алгоритмом. В качестве основных этапов этих алгоритмов необходимо выделить следующие:
- считывание данных из компонентах редактирования, расположенных на динамически создаваемых формах;
- поиск записей базы данных соответствующих определенному динамически создаваемому запросу;
- выполнение вычислительных операций с результатами информационного поиска;
- внесение необходимых изменений в базу данных.
Рисунок 2.38 – Дочерняя форма AddSource динамически создаваемая для добавления информации о заказе на товары
Рисунок 2.39. – Дочерняя форма AddSource динамически создаваемая для добавления информации о накладной
Все алгоритмы отличаются разной степенью сложности информационного поиска и вычислительных процедур по обработке результатов такого поиска.
Дочерняя форма ParamPoisk динамически создается с одной стороны для организации запросов на различные виды сложного информационного динамического поиска по ключевым полям (рис.2.40 -2.41):
- поиск товаров по наименованию;
- поиск размещения на складе компьютерных комплектующих по их наименованию;
- поиск и отображение накладных, созданных в определенный временной интервал;
- поиск товаров с «просроченным» сроком годности.
Рисунок 2.40 – Дочерняя форма ParamPoisk, динамически создаваемая для организации запроса на поиск товаров с «просроченным» сроком годности
Элементы управления button («Выполнить поиск») на динамически создаваемых формах позволяют активировать программную процедуру учитывающую вид информационного поиска, соответствующие динамически создаваемые ключи и выполняют соответствующие вычислительные процедуры и операции по изменению, удалению, добавлению необходимых записей в базе данных.
Рисунок 2.42 – Дочерняя форма ParamPoisk, динамически создаваемая для организации запроса на поиск комплектующих по их наименованию
Рисунок 2.43. – Дочерняя форма ParamPoisk, динамически создаваемая для организации запроса на просмотр накладных, созданных в определенный временной интервал
Для отображения результатов информационного поиска, согласно выбранным настройкам, динамически создается форма ChildTemplateForm. Форма ChildTemplateForm содержит компонент DBGrid, источником данных которого является таблица – результатов динамического поиска, выполняемых при помощи компонентов AdoQuery.
При выборе альтернативы главного меню «Проводка накладных» так же динамически создается дочерняя форма ParamPoisk, для оргагнизации интерфейса для выполнения проводки накладных рис.2.44. В результате активации элемента управления button («Проводка»), осуществляется запуск сложной программной процедуры, осуществляющей неоднократный сложный динамический информационный поиск в базе данных, изменения записей базы данных с целью осуществления бухгалтерской проводки накладной на получение комплектующих или вычислительной техники на складе компании ЗОО «Ти Эль Плюс».
Рисунок 2.44. – Дочерняя форма ParamPoisk, динамически создаваемая для проводки накладных
Проводка накладных сопровождается строгим логически корректным программным механизмом, сопровождающимся информационной поддержкой в виде выдачи информационных сообщений при помощи метода ShowMessage, при выборе соответствующей ветви разветвления алгоритма.
При попытке проведении проводки (рис.2.45), вторично возникает исключительная ситуация характеризующая информационную поддержку разработанной программной системы. В качестве примера показана возможная ошибочная ситуация, которая может возникнуть в случае попытки повторной проводки накладной, номер которой указан в окне редактирования формы ParamPoisk. Система распознала текущую ситуацию и предупредила пользователя-оператора о сложившихся условиях при помощи информационного сообщения, о том, что проводка выполнена не будет, при помощи метода ShowMessage.
Рисунок 2.46 – Сообщение об исключительной ситуации