Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Основные технико-эксплатуционные требования к





Аннотация.

В данном дипломном проекте будет проделана работа по разработке АИС (Автоматизированной информационной системы) «Видеотека» на примере «Азия хит». Данный дипломный проект состоит из: постановки задачи, разработки технического задания и создания самой АИС. Так же будут произведены экономические расчеты и расчеты по обеспечению безопасности жизнедеятельности.

Содержание

Введение…………………………………………………………………….3

1 Аналитические исследования проблем по теме проекта и разработка основных решений по их технической реализации……………………....5

1.1 Техническое задание……………………………………………………….5

1.2 Детально обоснование це­лесообразности и возможность создания системы……………………………………………………………………...8

1.3 Особенности проектирования……………………………………………..9

1.4 Основные технико-эксплуатационные требования к проектируемым системам и устройствам…………………………………………..…..…...11

1.5 Анализ решаемых задач и современное состояние проектируемого объекта………………………………………..…........…………………….11

1.6 Обоснование постановки задачи………………………………...……….13

1.7 Обоснование и выбор системы, устройства, их структурной схемы………………………………………………………………....…….13

1.8 Обоснование вопросов технического проектирования………….…..….13

1.9 Определение общих характеристик проектируемого объекта….…..….13

1.10 Обоснование уточненных методов решения зада……………..…....…..14

2 Техническая часть……………………………………………………....…15

Основные технико-эксплатуционные требования к

проектируемой системе, которые, отражаются в разработанном техническом задании………………………………………………………15

2.2 Особенности проектирования (выбор среды)……………………...……17

2.3 Теоретические основы разрабатываемой информационной системы……………………………………………………....………….….21

2.4 Разработка алгоритмов……….………………………………………..….23

2.5 Разработка структуры данных и программ………..…………..………...27

3 Рабочая документация…………………………………………..…...….…44

3.1 Схема разграничения доступа……………………………………...……..45

3.2 Схема связей между модулями……………………………………...……46

4 Экономическая часть………………………………………………..….....52

4.1 Оценка экономической эффективности…………...……………………..52

4.2 Расчет экономической эффективности внедрения………………..….…52

5 Безопасность труда и экологическая безопасность……………………..59

Характеристика опасных и вредных факторов возникающих

в процессе функционирования разрабатываемого объекта…..………...59

5.2 Нормирование опасных и вредных факторов…………….……………..63

Рекомендации по уменьшению воздействию опасных и

вредных факторов на человека и окружающую среду…..……………..66

5.4 Расчетная часть………………………………………………..………….70

Заключение…………………………………………………………..….…71

Список литературы…………………………………………………....…...73

Приложение 1

Приложение 2

Введение.

Задача накопления, обработки и распространения (обмена) информации стояла перед человечеством на всех этапах его развития. В течение долгого времени основными инструментами для ее решения были мозг, язык и слух человека. Первое кардинальное изменение произошло с приходом письменности, а затем изобретением книгопечатания. Поскольку в эпоху книгопечатания основным носителем информации стала бумага, то технологию накопления и распространения информации естественно называть “бумажной информатикой”.

Положение в корне изменилось с появлением электронных вычислительных машин (ЭВМ). Первые ЭВМ использовались как большие автоматические арифмометры. Принципиально новый шаг был совершен, когда от применения ЭВМ для решения отдельных задач перешли к их использованию для комплексной автоматизации тех или иных законченных участков деятельности человека по переработке информации.

Одним из первых примеров подобного системного применения ЭВМ в мировой практике были так называемые административные системы обработки данных: автоматизация банковских операций, бухгалтерского учета, резервирования и оформления билетов и т.п. Решающее значение для эффективности систем подобного рода имеет то обстоятельство, что они опираются на автоматизированные информационные базы. Это означает, что в памяти ЭВМ постоянно сохраняется информация, нужная для решения тех задач, на которые рассчитана система. Она и составляет содержимое информационной базы соответствующей системы.

При решении очередной задачи система нуждается во вводе только небольшой порции дополнительной информации, остальное берется из информационной базы. Каждая порция вновь вводимой информации изменяет информационную базу системы. Эта база (информационная, или база данных) находится, таким образом, в состоянии непрерывного обновления, отражая все изменения, происходящие в реальном объекте, с которым имеет дело система.

Хранение информации в памяти ЭВМ придает этой информации принципиально новое качество динамичности, т.е. способности к быстрой перестройке и непосредственному ее использованию в решаемых на ЭВМ задачах. Устройства автоматической печати, которыми снабжены современные ЭВМ, позволяют в случае необходимости быстро представить любую выборку из этой информации в форме представления на бумаге.

По мере своего дальнейшего развития административные системы обработки данных перерастают в автоматизированные системы управления соответствующими объектами, в которых, как правило, не ограничиваются одной ЭВМ, а в составе двух и более ЭВМ объединяют в вычислительный комплекс.

В этом ряду особое место занимают базы данных и другое программное обеспечение, связанное с их использованием в качестве инструмента для делопроизводства и рационализации труда. Их использование позволяет сократить время, требуемое на подготовку конкретных маркетинговых и производственных проектов, уменьшить непроизводительные затраты при их реализации, исключить возможность появления ошибок в подготовке бухгалтерской, технологической и других видов документации, что дает для предприятия прямой экономический эффект.

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

Целью данного дипломного проекта является анализ и разработка системы автоматизации продажи и учета, проката и прогнозирования спроса на видеопродукцию.

По достижению этой цели Работа предприятия поднимется на новый уровень. Возрастет качество обслуживания, конкурентоспособность (пожалуй, самое главное в условиях рыночной экономики) и производительность в целом. Автоматизации также буде подвержено не только часть работы с клиентом, но и некоторые организационные вопросы. На данный момент в этой области применение Автоматизированных Информационных Систем слишком мало. Многие предприятия до сих пор используют в ведении учет продукты от корпорации Microsoft, а именно: Word, Excel. Эти продукты можно считать универсальными, фактически их можно настроить на работу в любом предприятии, но отдачу как специализированные АИС разработанные специально для конкретного предприятия, они не смогут отдавать. Мы не берем в рассмотрение ведение документации на бумаге, такой вариант абсолютно не актуален на сегодняшний день, тем более для более крупных предприятий.

 

Рис. 1.3 Пример диаграммы зависимостей сущностей

В реляционной базе данных в каждой ячейке может храниться только один объект. В базе данных существует также взаимосвязь между таблицами. Каждая взаимосвязь представлена в RDBMS (РСУБД) за счет совместного использования одной или нескольких колонок двумя таблицами.

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

Рис 1.4 ERD с атрибутами.

В ERD сущность представлена рамкой с именем этой сущности. Если вы всегда будете использовать существительные в единственном числе, то можете получить единый стандарт для всех названий, и тем самым, сделать диаграмму более читаемой.

Отношение многие - ко - многим.

Отношение многие ко многим, также называемое неопределенным отношением, отображает ситуацию, когда экземпляр в одной сущности относится к одному или нескольким экземплярам второй сущности, а экземпляр во второй сущности относится к одному или нескольким экземпляров первой сущности. В примере видеомагазина отношение многие ко многим возникает между экземплярами ПОТРЕБИТЕЛЬ и КОПИЯ ФИЛЬМА. В данном случае отношение многие ко многим показывает, что “ПОТРЕБИТЕЛЬ <берет напрокат> несколько КОПИЙ ФИЛЬМОВ” и “КОПИЯ ФИЛЬМА <сдается напрокат> нескольким ПОТРЕБИТЕЛЯМ”.

Рис. 1.5 Пример отношения многие ко многим в IDEF1X (вверху) и IE (внизу).

Отношения многие ко многим обычно используются на начальной стадии разработки диаграммы, например, в диаграмме зависимости сущностей (ERD) и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах.

Техническая часть.

 

Таблица 2.1 Характеристики процессов информационных систем.

Типы Систем Информационные Вводы Обработка Информационные Выводы Пользователи
ESS Совокупные данные; внешние, внутренние Графика; моделирование; интерактивность Проекции; реакции на запросы Старшие менеджеры
DSS Слабо формализованные данные; аналитические модели Моделирование; анализ; интерактивность Специальные доклады; анализ решений; реакция на запросы Профессионалы; управляющие персоналом
MIS Итоговые операционные данные; данные большого объема; простые модели Обычные доклады; простые модели; простейший анализ Резюме и возражения Средние менеджеры
KWS Технические данные проекта; база знаний Моделирование; проигрывание Модели; графика Профессионалы; технический персонал
OAS Документы; расписания Документы управления; планирование; связь Документы; графики; почта Служащие
TPS Транзакции; результаты Сортировка; список; слияние; модифицирование Детальные доклады; списки; резюме Оперативный персонал; управляющие

 

Необходимо отметить, что каждая из различных видов систем может иметь компоненты, которые используются различными организационными уровнями, и одновременно несколькими. Секретарь может находить информацию относительно MIS, или средний менеджер может нуждаться в данных анализа из TPS.

Внутри каждого из этих уровней принятия решений, исследователи классифицируют решения как структурированные и неструктурированные. Неструктурированные решения, – в которых принимающий решение должен обеспечить суждение, оценку, и проникновение в прикладную область. Каждое из этих решений оригинально, важно, нет установившейся практики, и не имеется никакой внятной или проработанной процедуры для их принятия. Структурные решения, наоборот, являются повторяемыми и обычными и отрабатывают определенную процедуру для их принятия так, чтобы они не рассматривались каждый раз как новые. Некоторые решения слабоструктурированы; в таких случаях, только часть проблемы имеет четкий ответ, обеспеченный в соответствии с принятой процедурой.
Классификация СУБД в соответствии с используемой моделью данных:

Иерархическая.

Сетевая.

Реляционная.

Объектная.

Гибридная. (Элементы объектной с реляционной).

В настоящее время самыми распространенными СУБД являются продукты, использующие реляционную модель данных. Это связано с простотой понимания и лучшими характеристиками по сравнению с другими. В связи с этим остановимся на рассмотрение только реляционных СУБД (РСУБД).

Классификация РСУБД в зависимости от объема поддерживаемых БД и количества пользователей.

Высший уровень. Эти продукты поддерживают крупные БД (сотни и тысячи Гбайт и более), тысячи пользователей. В крупных корпорациях. Представители: ORACLE7, ADABAS 5.3.2, SQL SERVER11.

Средний уровень. Эти продукты поддерживают БД до нескольких сот Гбайт, сотни пользователей. В небольших корпорациях и подразделениях крупных фирм. Представители: InterBase 3.3, Informix-OnLine7.0, Microsoft SQL Server6.0.

Нижний уровень. Эти продукты поддерживают БД до 1 Гбайт, менее 100 пользователей. В небольших подразделениях. Представители: NetWare SQL 3.0, Gupta SQL-Base Server.

Настольные СУБД. Для одного пользователя, используется для ведения настольной БД или как клиент для подключения к серверу БД.

 

Оценка современных СУБД на соответствие требованиям, предъявляемым к автоматизированным информационным системам кадастра.

 

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

Сопоставление базового и проектного вариантов производится на основании расчёта экономических показателей.

 

Разрабатываются алгоритмы

В данном случае под алгоритмом можно также понимать потоки данных и транзакции. В основу ляжет архитектура «Клиент-Сервер», это обусловлено тем, что салоны продаж находятся в разных местах и распределены по городу. Рассмотрим алгоритм действий с момента поступления продукции.

После заказа определенного количества продукции в виде видеозаписей, курьер доставляет продукцию. Далее идет проверка на количество и соответствие заказанным материалам. После чего следует расчет в виде наличных или в кредит. Пройдя все эти процедуры, товар заносится в базу. Фиксируется общее количество, количество по жанрам, затраченная сумма в общем, дата закупки, наименование поставщика. Также заносится Ф.И.О курьера и Ф.И.О поставщика. Это сделано для разрешения спорных ситуаций, которые могут произойти.

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

Ниже представлены алгоритмы при продаже и прокате видеопродукции.

 

Проследим ход алгоритма при продаже видеозаписи. Ниже представлен алгоритм в виде блок-схемы.

 

Рис.2.1 Алгоритм продажи товара.

 

Рассмотрим теперь этот алгоритм.

 

Допустим, поступил запрос от клиента на конкретную видеозапись. После этого продавец должен произвести поиск по основной базе, и в случае успеха, как и в случае отрицательного результата, сообщить клиенту о наличии или отсутствии данной видеозаписи, ее цене. Допустим, клиента все это устроило, далее оформляется сделка в виде продажи продукции. В основной базе конкретная видеозапись помечается как проданная и перемещается из основной базы в базу «Продажи за день». После этого система возвращается в ожидание следующего запроса. Так же фиксируется время продажи, цена, наименование видеозаписи и Ф.И.О продавца. Ф.И.О продавца фиксируется для последующего анализа с целью определения «лучшего продавца», тем самым становится, возможно, вести акцию среди продавцов для стимулирования интереса к работе. Также необходимо рассмотреть неприятный, момент в виде разбирательств, при конфликте между продавцом и клиентов. Наличие Ф.И.О продавца позволить легко ориентироваться в таких неприятных ситуациях. Ход алгоритма при оформлении сделки в виде проката практически аналогичен, но имеет различие, рассмотрим его.

Он так же представлен в виде блок-схемы.

Рис.2.2 Прокат товара.

 

Здесь при поступлении запроса на конкретную копию видеозаписи продавец производит поиск интересующей видеозаписи. После этого продавец должен выдать результаты поиска и условия проката. Далее необходимо спросить подтверждения у клиента, что его все устраивает. Затем, если клиент согласен идет оформление сделки в виде проката, состояние в основной базе меняется на «в прокате» и переносится в базу «прокат», в противном случае вся система возвращается в ожидание следующего запроса. После истечения срока проката клиент возвращает видеозапись, она удаляется из базы «прокат» и помечается в основной базе как «в наличии», после этого информация о данной видеозаписи перемещается в базу «прибыль за день» с пометкой «прокат».

 

Далее представлен полный алгоритм в виде блок-схемы при продаже или прокате.

Рис.2.3 Общий случай реализации товара.

Таблица №2.2 «Список поставщиков».

 

Наименование поля Тип данных Размер поля Значение по умолчанию
Наименование поставщика Char   Not Null
Юридический адрес Char   Not Null
Контактный телефон Integer   Not Null
№ лицевого счета Integer   Not Null
Адрес электронной почты Char    
Ф.И.О Директора Char   Not Null
Ф.И.О замдиректора Char   Not Null

 

Таблица №2.3 «Закупка продукции».

 

Наименование поля Тип данных Размер поля (в знаках) Значение по умолчанию
Поставщик Char   Not Null
Дата закупки Date Автоматически Not Null
Наименование видеозаписи Char   Not Null
Жанр Char    
Цена одной единицы Smallint Автоматически Not Null
Количество копий   Smallint Автоматически Not Null
Общая цена по данному фильму   Integer Автоматически Not Null
Тип носителя   Char   Not Null

 

Таблица 2.4«Список продукции».

 

Наименование поля Тип данных Размер поля Значение по умолчанию
Наименование видеозаписи Char   Not Null
Жанр Char   Not Null
Год выпуска в прокат Date Автоматически Not Null
Краткая информация Blob --  
Цена Smallint Автоматически Not Null
Тип носителя Char   Not Null
Состояние Char   Not Null
Количество копий Smallint Автоматически Not Null

 

Таблица №2.5«Учет реализации продукции в виде продажи».

 

 

Наименование поля Тип данных Размер поля Значение по умолчанию
Наименование видеозаписи Char   Not Null
Жанр Char   Not Null
Тип носителя Char   Not Null
Дата продажи Date Автоматически  
Цена Smallint Автоматически Not Null
Ф.И.О продавца Char   Not Null

 

 

Таблица №2.6«Учет реализации продукции с последующим возвратом».

 

Наименование поля Тип данных Размер поля Значение по умолчанию
Наименование видеозаписи Char   Not Null
Дата сдачи в прокат Date Автоматически Not Null
Дата возврата из проката Date Автоматически Not Null
Сумма залога Smallint Автоматически Not Null
Стоимость проката Smallint Автоматически Not Null
Ф.И.О клиента Char   Not Null
Домашний телефон клиента Integer Автоматически Not Null

 

 

Таблица №2.7 «Выручка за продажу».

Наименование поля Тип данных Размер поля Значение по умолчанию
Дата продажи или возврата из проката Date Автоматически Not Null
Сумма Integer Автоматически Not Null

Таблица №2.8 «Выручка за прокат».

Наименование поля Тип данных Размер поля Значение по умолчанию
Дата продажи или возврата из проката Date Автоматически Not Null
Сумма Integer Автоматически Not Null

Таблица №2.9 «Общая выручка».

Наименование поля Тип данных Размер поля Значение по умолчанию
Дата продажи или возврата из проката Date Автоматически Not Null
Сумма Integer Автоматически Not Null

 

 

Таблица №2.10 «Прогнозирование спроса».

 

Наименование поля Тип данных Размер поля (в знаках) Значение по умолчанию
Дата продажи Date Автоматически Not Null
Общее количество проданных копий Smallint Автоматически Not Null
общее количество проданных комедий Smallint Автоматически Not Null
общее количество проданных мелодрам Smallint Автоматически Not Null
общее количество проданных боевиков Smallint Автоматически Not Null
общее количество проданных ужасов Smallint Автоматически Not Null
общее количество проданных мультфильмов Smallint Автоматически Not Null
общее количество проданных документальных фильмов Smallint Автоматически Not Null
общее количество проданных сериалов Smallint Автоматически Not Null
общее количество проданных фантастических фильмов Smallint Автоматически Not Null
общее количество проданных триллеров Smallint Автоматически Not Null
общее количество проданных научно-познавательных фильмов Smallint Автоматически Not Null
общее количество проданных исторических фильмов Smallint Автоматически Not Null
общее количество проданных музыкальных фильмов Smallint Автоматически Not Null

Таблица №2.11 «Цены».

 

Наименование поля Тип данных Размер поля Значение по умолчанию
Накрутка на одну единицу Smallint Автоматически Not Null
Стоимость проката видеозаписи на носителе DVD. Smallint Автоматически Not Null
Стоимость проката видеозаписи на носителе VCD Smallint Автоматически Not Null
Стоимость проката видеозаписи на носителе VHS.   Smallint Автоматически Not Null
Минимальное количество копий. Smallint Автоматически  
Количество проданных копий, по превышению которых видеозапись становится фаворитной. Smallint Автоматически  

Таблица №2.11 «Фаворитные видеозаписи».

Наименование поля Тип данных Размер поля Значение по умолчанию
Дата, начиная с которой видеозапись стала фаворитной.   Date Автоматически Not Null
Наименование видеозаписи. Char   Not Null

Таблица №2.13 «История закупок».

Наименование поля Тип данных Размер поля Значение по умолчанию
Дата закупки   Date Автоматически Not Null
Поставщик Char   Not Null
Сумма закупки Integer Автоматически Not Null
Общее количество закупленных видеозаписей   Integer Автоматически Not Null

 

 

Таблица №2.14 «Продавцы».

Наименование поля Тип данных Размер поля Значение по умолчанию
Ф.И.О   Date Автоматически Not Null

 

 

Таблица №2.15 «Создание заказа».

Наименование поля Тип данных Размер поля Значение по умолчанию
Наименование видеозаписи Char   Not Null
Количество копий на данный момент Smallint Автоматически Not Null
Необходимое количество копий Smallint Автоматически Not Null

 

 

Таблица №2.16 «Просмотр заказав».

Наименование поля Тип данных Размер поля Значение по умолчанию
Наименование видеозаписи Char   Not Null
Количество копий Smallint Автоматически Not Null
Дата Заказа Date Автоматически Not Null

 

 

 

Рабочая документация.

Теперь рассмотрим структуру программного обеспечения (клиентское приложение).

Программное обеспечение клиентской стороны будет состоять из одной подпрограммы, но в этой программе будет разделение прав доступа с помощью учетных записей и паролей. По умолчанию будет созданы три учетные записи: «Администратор», «Директор» и «Продавец».

Это сделано, для того чтобы каждый работник имел доступ только к той информации, которая предназначена только ему. Соответственно учетная запись «Администратор» будет иметь полный доступ к информации по работе предприятия, и клиентского приложения, Таким образом, возможно, будет управлять, и вносить корректировки в работу предприятия своевременно для достижения лучших результатов. Учетная запись «Продавец» – ограниченная в правах доступа учетная запись, ее доступ распространяется на базы: «Основная база», «Прокат», «Создание заказа». Оно будет вносить изменения в эти базы по ходу реализации продукции.

Таким образом, разграничим права доступа.

 

 

 

Рис 3.1 Схема доступа и разграничения к базе данных из разных учетных записей.

 

 

- Форма «Окно».

 

- Блок основных расчетов.

 

 

- Вспомогательные блоки.

 

 

Рис 3.2 Схема изображения связей между модулями и блоками программы.

 

 

Рис 3.3 - Внешний вид основной формы.

 

Здесь представлена главная форма, из которой производятся все действия.

На форме размещены: сверху - первые два пункта меню это поиск и сортировка по основной базе, далее «Касса», а именно «Продажа», «Прокат», «Закупка». Выручка состоит из следующего подменю: «Выручка за продажу», «Выручка за прокат», «Общая выручка» стоить отметить, что выручка считается за один день при закрытии программы. Далее идет меню «Настройки»,оно состоит из: «Общие», «Сервер», «Цены», «Доступ». Далее следует подменю «Поставщики», с помощью него можно работать с базой поставщиков. Затем идет меню «Прогнозирование», с помощью него, возможно, работать и составлять прогноз. Далее расположено меню «Заказы», оно предназначено для составления заказа и для просмотра видеозаписей находящихся в заказе и последнее меню это – «Смена пользователя». Это меню предназначено для смены учетных записей при работе программы.

Внизу формы расположены кнопки для управления и работы с основной базой, рассмотрим их: Первый элемент это кнопка «Продано», она используется при продаже видеозаписи. Затем расположена кнопка «Прокат», она используется при сдаче в прокат видеозаписи. Далее расположен элемент типа ComboBox, он предназначен, для выбора продавца который продает видеозапись. Затем расположена кнопка «Изменить», она позволяет менять информацию видеозаписи такую как: Дата выхода в прокат, Краткая информация и вносить или убирать видеозапись из списка «Фаворитные видеозаписи». И последний идет блок работы с основной таблицей это кнопки: «Удалить», «Обновить», «Вперед», «Назад», «Отмена». Стоит отметить, что кнопка «Удалить» становится активной, если зайти в программу под учетной записью «Администратор».

 

 

 
 

 


Рис 3.4 - Внешний вид формы «Закупка».

 

Форма «Закупки» позволяет работать и производить учет видеопродукции при закупке. После того как вся продукция внесена в таблицу, программа посчитает общую стоимость закупки, для этого нужно нажать кнопку «Рассчитать общую стоимость». Также здесь возможно приготовить накладную, для этого необходимо нажать кнопку «Приготовить накладную». После завершения расчетов общей стоимости и подготовки накладной необходимо нажать кнопку «Завершить». При подтверждении вся информация в данной таблице перенесется в основную таблицу, но уже не с оптовыми ценами, а с накруткой (установленной в настройках «Цены»). Также занесется информация в таблицу «История закупок». Получить доступ к таблице можно путем нажатия на кнопку «История закупок» (для учетных записей «Директор» и «Администратор»). Информация в таблице «Закупка» удалится. Так как работу с этой таблицей производят только при закупке, в ней отсутствует сортировка, поиск и выборка.

 

 

 

Рис 3.5 - Внешний вид формы «История закупок».

 

Эта форма позволяет вести учет истории закупок. Так же можно осуществить выборка из истории закупок и составить отчет.

 

 

 

 


Рис 3.6 - Внешний вид формы «Продажа».

 

 

С помощью этой формы, возможно, вести учет продаж. По базе «Продажи» предусмотрено: поиск по наименованию видеозаписи и по дате продажи, для этого указать критерий и нажать кнопку «Найти». Также предусмотрена сортировка записей: по наименованию, жанру, типу носителя, дате продажи, цене, ФИО продавца. Предусмотрена выборка и отчет.

 

       
   
 
 

 


Рис 3.7 - Внешний вид формы «Прокат».

 

Перед сдачей в прокат необходимо заполнить сведения о клиенте, это: дата, с которой видеозапись в прокате, дата возврата из проката, ФИО клиента, его контактный телефон, сумма залога, тип носителя. Сумма проката установится автоматически, когда будет выбран тип носителя (значения берутся из базы «Цены»). Далее необходимо нажать кнопку «Сдано», после этого в основной базе число копий данной видеозаписи уменьшиться на единицу, а таблицу «Прокат» будет добавлена данная видеозапись. Также предусмотрено: поиск, сортировка, выборка и отчет. При возвращении видеозаписи из проката необходимо нажать на кнопку «Возврат из проката», при этом конкретная видеозапись удалится из базы «Прокат», а в основной базе число копий данной видеозаписи увеличится на единицу.

 

 

 

Рис 3.8 - Внешний вид формы «Выручка за продажу».

 

Данная форма позволяет вести учет выручки за продажу. Выручка считается путем вычета оптовой стоимости (при закупке) от стоимости продажи в розницу. Все расчеты происходят при закрытии программы в конце рабочего дня. Программа фильтрует все продажи за число, при котором была закрыта программа и создает цикл, в котором происходят все расчеты. Также предусмотрено: выборка, поиск, сортировка и отчет.

 

 

 

 

Рис 3.9 - Внешний вид формы «Выручка за прокат».

 

Данная форма позволяет вести выручку за прокат. Работа программы в этом случае частично аналогична действиям при расчете выручки за продажи, но с отличием. Программа считает выручка за прокат по конкретной видеозаписи только при возврате ее из проката, т.е. при нажатии на кнопку «Возврат из проката». При этом на время работы создается отдельная переменная, куда заносится выручка за прокат – некий счетчик. При закрытии программы, в базу «Выручка за прокат» заносится значение этой переменной. Предусмотрено: выборка (необходимо задать критерий и нажать на кнопку «Выбрать», при отмене выборки необходимо нажать кнопку «Отмена»), поиск (необходимо выбрать критерий поиска и нажать кнопку «Найти») и сортировка (для ее осуществления необходимо просто выбрать критерий из списка в компоненте ComboBox). Также предусмотрен отчет.

 

 

Рис 3.10 - Внешний вид формы «Прогнозирование спроса – жанр Комедии».

 

Даная форма позволяет производить и работать с прогнозированием спроса на предстоящие 3 месяца. Прогноз производится по жанрам, на основе статистики продаж за последние 3 месяца с момента составления прогноза. Для того чтобы составить прогноз на следующий месяц программа обращается к статистике за последние 3 месяца. Для создания прогноза второго будущего месяца, программа обращается к статистике за предыдущие 2 месяца, но учитывает прогноз на первый будущий месяц. Для составления прогноза на 3-й будущий месяц, программа обращается к статистике за последний предыдущий месяц, но учитывает прогноз на первые 2 месяца. Для всех жанров действия аналогичны. Для прогноза предусмотрена печать графиков, об этом будет сказано ниже. Также предусмотрена следующая ситуация: допустим, программа будет внедряться в уже действующее предприятие тогда, для возможности составления







Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.