Проектирование информационной системы учета продаж Компания "Max-Service"

Содержание

Введение

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

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

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

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

Пользователями  этой системы будет оперативно-торговый персонал.

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

1. АнаЛИЗ ОБЪЕКТА ИССЛЕДОВАния

1.1 Анализ предметной области

Компания "Max-Service" специализируется на продаже, покупке и ремонте сотовых мобильных телефонов следующих производителей: Nokia, Sony Ericsson, Motorola, Samsung, Alcatel, VK Mobile, Siemens, Voxtel, Panasonic, Fly, Sagem, Benefon, Bird, Ericsson, Hewlett-Packard, Hyundai, I-Mate, LG, Maxon, NEC, Pantech, Philips, Sendo, Sharp.

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

Структурно в компании можно выделить два основных компонента:

1. Магазин – осуществляет продажу  сотовых телефонов и аксессуаров  и скупку у населения б\у  телефонов на запчасти или  перепродажи.

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

Организация ведет розничную торговлю за наличный расчет. Удовлетворяя потребности потребителям, предприятие розничной торговли получает доход от торговой надбавки на продаваемые товары.

2. Сервисный центр.

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

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

Товар в магазин доставляется тремя  путями: поставщиками, экспедиторами  или заказывается руководителем предприятия у оптовых фирм. Поставщики – это те, у кого магазин скупает б/у телефоны. Экспедиции – это подразделение фирмы, занимающееся закупкой и доставкой товаров у оптовых фирм.

Бухгалтерский учет реализации товаров  на данном предприятии осуществляется по мере поступления денег в кассу от покупателей и  ежемесячном пересчёте товаров оставшихся в магазине (ревизия).

ИС предприятия в рамках учёта, как функции управления, напрямую связана с процессом товародвижения.

1.2. Постановка задачи

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

Для установления и отображения  связей между задачами проведен анализ информационных потоков и процесса обработки документов в магазине и сервисном центре.

Работа с поставщиками происходит следующим образом:

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

Поставщики предоставляют далеко не все необходимые товары, поэтому  в фирме имеются подразделения  – товарные экспедиции. Экспедиция состоит из трёх человек: экспедитор, водитель, грузчик. Главную роль играет экспедитор. Его работа включает следующее:

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

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

Вопросом  расширения и обновления ассортимента занимаются экспедитор и  завмаг. Экспедитор исследует предложения фирм-оптовиков и докладывает о появлении интересных предложений завмагу. Завмаг принимает решение: везти или не везти определённый вид товара.

Таким образом, основными задачами, подлежащими автоматизации, являются:

• документальное сопровождение продажи сотовых телефонов и аксессуаров (чек, гарантийный талон);
• диагностика неисправностей;
• документальное сопровождение скупки телефонов, бывших в употреблении;
• автоматический расчёт стоимости ремонтных услуг и запчастей;
• подбор по каталогу моделей с заданными параметрами;
• подготовка сводных отчётов по продажам, ремонту и т. д.
• выдача информации по запросам.

2. Инфологическое моделирование

2.1. Диаграммы потоков данных

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

Рис. 1. Начальная контекстная диаграмма.

DFD первого уровня строится как  декомпозиция процесса, который присутствует на контекстной диаграмме. Процесс «Обслужить» является типовым, по одной и той же схеме с некоторыми несущественными изменениями происходят три базовых процесса: ПРОДАТЬ телефон, КУПИТЬ телефон и РЕМОНТИРОВАТЬ телефон.  Выполним декомпозицию процесса ОБСЛУЖИТЬ на процессы первого уровня (рис. 2, 3 и 4):

Рис. 2. Диаграмма потоков данных первого уровня для процесса ОТРЕМОНТИРОВАТЬ.

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

2. Анализировать, т. е. установить причину неисправности. На этом же этапе определяется, какие запчасти нужны для ремонта, рассчитывается стоимость ремонта. Делается заявка на склад на получение нужных запчастей.

3. Работать с неисправным телефоном. То есть, зафиксировать, ликвидировать неисправность, выписать счёт и гарантийный талон для клиента.

  На диаграмме  первого уровня были выделены  три промежуточных хранилища информации:

1. БД 1 – Состояние. Здесь хранится информация о нормативных показатели технического состояния телефонов на разных сроках эксплуатации. Эта информация является эталонной для системы, на её основе путём сравнения с реальным состоянием оборудования составляется предварительный счёт за ремонт. Эта информация является статической, т.е. обновляется сравнительно редко.  Здесь также содержатся все сведения о зафиксированных неисправностях, о проведённых ремонтных работах и т. п.

3. БД 2 – Склад. Здесь хранится информация о наличии телефонов, запчастей и т.п.

По аналогичной схеме протекает  процесс КУПИТЬ б\у телефон (рис. 3).

Рис. 3. Диаграмма потоков данных первого уровня для процесса ОТРЕМОНТИРОВАТЬ.

Схема процесса ПРОДАТЬ телефон немного отличается от описанных выше схем (рис. 4).

Рис. 4. Диаграмма потоков данных первого уровня для процесса ПРОДАТЬ.

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

2.2. Диаграммы "сущность-связь"

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

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

Диаграмма «сущность-связь» обеспечивающая процесс товародвижения на данном предприятии  выглядит, как показано на рис. 9.

Рис. 9. Диаграмма «сущность-связь»

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

3. Даталогическое моделирование

3.1. Даталогическая модель данных

Задача даталогического и физического  этапа проектирования – выбор  рациональной структуры хранения данных и методах доступа к ним, исходя из арсенала методов и средств, которые предоставляются разработчику СУБД.

В соответствии с построенной инфологической моделью предметной области, были выделены следующие сущности (объекты):

1. Модель_телефона – данный объект содержит сведения о существующих моделях мобильных телефонов, их краткое описание, включая физические, технические параметры и комплектность. Здесь же отражаются сведения о цене и наличии на складе.

2. Фирма – данный объект содержит  основные сведения о фирмах-производителях мобильных телефонов.

3. Телефоны_товар – является  подчинённым по отношению к  объекту Модель_телефона и содержит  сведения об отдельных экземплярах  этого объекта, включая IMEI, состояние  телефона, статус (новый или б/у).

4. Клиенты – здесь содержатся основные сведения о клиентах, необходимые для того, чтобы оформить факт продажи, покупки, приёма телефона на ремонт, подготовки товарного чека и гарантийного талона.

5. Телефоны_клиентов. В общем случае  каждый клиент может иметь  несколько телефонов, которые он мог приобрести как непосредственно в магазине «Vid Service», так и у других продавцов. При этом телефоны клиента могут находиться в разном состоянии – быть исправными или неисправными и т. д.

6. Заявки_клиентов. Клиент, обратившийся  в магазин «Vid Service», может заказать модель, которая как присутствует, так и отсутствует на складе. В последнем случае срок выполнения заказа может увеличиться до трёх-четырёх недель, и каждую такую заявку необходимо отслеживать.

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

8. Ремонтные_работы. В общем случае ремонт может оказаться сложным, требующим, например, программирования, замены корпусных деталей и т.п. Изо всего этого складывается конечная стоимость произведённых работ.

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

10. Виды_ремонтных_работ.  На каждый вид работы существует  прейскурант, в котором заложена  базовая цена ремонта.

11. Виды_запчастей.  Подстановочный объект, структурирующий  информацию об имеющихся на  складе запчастях по категориям.

12. Запчасти –  данный объект содержит сведения  об имеющихся на складе запчастях,  включая информацию о взаимозаменяемости  запчастей разных моделей телефонов от одного производителя.

13. Сотрудники. Необходим  для того, чтобы учесть вклад  каждого сотрудника в общую  работу магазина «Vid Service».

14. Статус_клиента  – подстановочный объект, необходимый  для идентификации клиента в  плане возможности получения им скидки и т.п.

15. Тех_состояние  – оценка технического состояния  телефона (исправен-неисправен, пригоден  для ремонта, подлежит разбору  на запчасти и т.п.).

3.2. Физическая модель данных

В соответствии с разработанной структурой данных в среде СУБД Access были разработаны таблицы для хранения данных. Описание таблиц выполнено с помощью рабочих бланков объектов, в которых описываются: поля таблицы, их типы и размеры, индексы, ключи и связи с другими объектами.

В бланках описания таблиц в столбце Индекс используются следующие обозначения:

• PRI – первичный индекс, соответствующий ключевому полю таблицы. В каждой таблице только один первичный индекс;
• FOR – внешний индекс, создаваемый для поля, участвующего в связи с другой таблицей;
• REG – регулярный индекс, создаваемый для полей, часто участвующих в запросах к базе данных, для ускорения процесса поиска и обработки информации.

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

1. Упорядочение процесса ввода данных для контроля корректности вводимой информации.
2. Облегчение процесса ввода за счет возможности выбирать нужные данные из списка, вместо ручного набора.

Таким образом, была составлена даталогическая модель, реализованная в СУБД MS Access, представленная на рис. 5.

Рис. 5. Схема данных, реализованная в СУБД Access.

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

Далее выполнено описание физической структуры таблиц, включая типы, размеры полей, индексы и т.п.

В СУБД Access данные хранятся в таблицах. Каждая таблица состоит из схемы таблицы (названия полей, типы данных, размеры, ограничения, индексы) и собственно записей, содержащих информацию.

Описание структуры таблиц выполняется  средствами специальных рабочих  бланков, содержащих сведения, как о структуре самой таблицы, так и об ее связях с другими таблицами. Таблица 1 содержит описание объекта «Телефоны_клиентов».

В бланках описания таблиц в столбце  Индекс используются следующие обозначения:

PRI – первичный индекс, соответствующий ключевому полю таблицы. В каждой таблице только один первичный индекс;

FOR – внешний индекс, создаваемый  для поля, участвующего в связи  с другой таблицей;

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

Таблица 1.

Описание таблицы «Телефоны_клиентов»

Полное описание всех объектов приведено  в приложении Б.

4. Разработка программного обеспечения

4.1. Структура программных средств

Ядром разрабатываемых программных  средств является база данных. В  силу специфики реляционной СУБД, программное обеспечение имеет модульную структуру (рис. 12).

Рис. 12 - Общая структура программных средств

На рисунке сплошными линиями  показаны структурные связи, штриховыми – вызов одних элементов приложения из других.

Кнопочная форма содержит объединяющие последовательности команд и запросов для выполнения задач приложения.

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

В категории Отчеты представлены выходные отчеты, формируемые системой.

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

Инструкции на выборку данных

SELECT [ALL | DISTINCT |DISTINCTROW | TOP ]

{ * | таблица.* | [таблица.]поле_1 [AS псевдоним_1] [, [таблица.]поле_2 [AS псевдоним_2] [, ...]]}

FROM выражение [, ...] [IN внешняяБазаДанных]

[WHERE условие отбора ]

[GROUP BY условие группировки ] (до 10 полей)

[HAVING условие отбора сгруппированных  полей ]

[ORDER BY поле 1[ASC|DEC], … ] (сортировка)

[WITH OWNERACCESS OPTION] (пользователю предоставляются  права владельца)

Для отбора всех полей таблицы можно  использовать символ (*).  Если несколько  таблиц, включенных в предложение FROM, содержат одноименные поля, перед именем такого поля следует ввести имя таблицы и оператор (.).

В предложении WHERE может размещаться  вложенный запрос:

WHERE поле1, поле2, … IN (запрос).

Также, в этом предложении могут  быть размещены кванторы существования (EXIST, NOT EXIST). Они всегда размещаются перед вложенным запросом.

В предложении FROM могут быть представлены результаты выполнения операций над  другими таблицами:

FROM таблица_1 [INNER | RIGHT | LEFT JOIN таблица_2 ON таблица_1.поле_1 оператор таблица_2.поле_2]

В качестве оператора — любой  оператор сравнения.

Операция INNER JOIN объединяет записи из двух таблиц, если связующие поля этих таблиц содержат одинаковые значения.

Инструкции, которые изменяют данные:

Инструкция SELECT...INTO — создаёт новую таблицу. SELECT поле_1[, поле_2[, ...]] INTO новая Таблица [IN внешняяБазаДанных] FROM источник;

Инструкция DELETE создает запрос на удаление записей, предназначенный  для удаления записей из одной  или нескольких таблиц, перечисленных  в предложении FROM, которые удовлетворяют предложению WHERE. DELETE [таблица.*] FROM таблица  WHERE условиеОтбора;

Инструкция INSERT INTO добавляет запись или записи в таблицу. INSERT INTO назначение [(поле_1[, поле_2[, ...]])] [IN внешняяБазаДанных]  
SELECT [источник.]поле_1[, поле_2[, ...]     FROM выражение;

Инструкция UPDATE создает запрос на обновление, который изменяет значения полей указанной таблицы на основе заданного условия отбора. UPDATE таблица      SET имя поля = новое Значение     WHERE условие Отбора.

Инструкции, изменяющие структуру данных

Инструкция CREATE TABLE используется для  описания новой таблицы, ее полей  и индексов. Если для поля добавлено  ограничение NOT NULL, то при добавлении новых записей это поле должно содержать допустимые данные.

CREATE [TEMPORARY] TABLE таблица (поле_1 тип [(размер)] [NOT NULL] [WITH COMPRESSION | WITH COMP] [индекс_1] [, поле_2 тип [(размер)] [NOT NULL] [индекс_2] [, ...]] [, CONSTRAINT составнойИндекс [, ...]])

Создаваемая временная (TEMPORARY) таблица  будет доступна только в том сеансе, где эта таблица была создана. По завершении данного сеанса она автоматически удаляется. Временные таблицы могут быть доступны для нескольких пользователей. Использование атрибута WITH COMPRESSION допускается только для типов данных CHARACTER и MEMO (он же TEXT) и их синонимов (переход к формату Юникод).

Модификация существующей таблицы, добавление или удаление поля или индекса, изменение  типа и размера полей.

ALTER TABLE таблица {ADD {COLUMN тип поля[(размер)] [NOT NULL]

[CONSTRAINT индекс] |     ALTER COLUMN тип поля[(размер)] | CONSTRAINT составнойИндекс} |     DROP {COLUMN поле I

CONSTRAINT имяИндекса} }