Разработка информационной системы "Магазин Бытовой Техники"

- - операционная система Microsoft Windows 2000 или XP;

- - Microsoft Word, Microsoft Excel;

- -БД

Использование других средств для импорта-экспорта и преобразования данных допускается, но не рекомендуется.

Для успешного функционирования Программы необходимо применение персонального компьютера, оснащенного операционной системой Microsoft Windows 2000 или XP и пакетом офисных программ Microsoft Office 2000, 2003, XP или 2007, так же на ПК должн быть установлен SQL сервер 2005.

Функциональное ПО должно разрабатываться с учетом:

- масштабирования по мере усложнения и увеличения объемов обрабатываемой информации;

- возможного расширения возможностей АИС «Магазин Бытовой Техники» с помощью подключения новых программных модулей;

- максимальной устойчивости частей ПО при масштабировании и/или расширении возможностей какой-то отдельной его части;

- администрирование и управление АИC должно ограничиваться знаниями используемой БД и ее SQL-языка, ОС и программами представления данных.

Функциональное ПО клиента должно выполняться на платформе Windows XP или выше и требований к переносимости на другие платформы не выдвигается.

Требования к организации пользовательских интерфейсов

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

При разработке пользовательского интерфейса необходимо предусмотреть представление данных в виде:

- табличного просмотра;

- карточного просмотра.

Табличный просмотр - представление множества объектов БД в виде строк и столбцов, где строки представляют объекты, а столбцы - размерные атрибуты объекта.

Карточный просмотр - представление единичного экземпляра в виде множества атрибутов объекта, имеющие строго определенное место в карточке.

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

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

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

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

При разработке пользовательских интерфейсов необходимо соблюдать:

1) адекватность особенностям пользователей - все модули должны быть ориентированы на один уровень пользователей. Необходимо учитывать следующие особенности пользователей:

- стаж работы, навыки работы;

- опыт работы с подобными системами;

- знание терминологии;

- физические параметры (возраст).

2) адекватность среде использования системы. Основные составляющие этой среды:

- временные ограничения на выполнение действий;

- наличие перерывов в общении пользователей с системой;

- разрешение мониторов;

- скорость работы системы в целом.

3) адекватность отображения объектов системой и связи между ними:

- взаимное расположение объектов на экране должно соответствовать их логической связи;

- наиболее важная (ключевая) информация должна быть на виду и легко доступна;

- отсутствие избыточности информации.

- преемственность и типизация интерфейса во всех подсистемах:

- типичность простых диалогов;

- типичность информационных сообщений;

- типичность представления данных;

- типичность элементов управления.

Требования к техническому обеспечению

Технические требования разработаны исходя из условий использования при разработке АИС «Управление производственным предприятием» последних версий общесистемного программного обеспечения.

Требования к комплектации рабочей станции АИС Управление производственным предприятием»:

- процессор не ниже 2 ГГц.

- оперативная память не менее 1 Гбайт;

- монитор 17'' с рабочим разрешением 1024x768 точек;

- HDD не менее 10 Гбайт;

- клавиатура;

- мышь.

Конфигурации серверов представлены в приложении А.

Требования к метрологическому обеспечению

Специальных требований к метрологическому обеспечению АИС «Магазин Бытовой Техники» не предъявляется.

Требования к организационному обеспечению

Организационное обеспечение АИС должно быть представлено совокупностью мероприятий, средств и нормативных документов, определяющих:

- нормативно-правовую и организационную базы;

- разработку, внедрение и функционирование системы;

- финансирование проектирования, внедрения и функционирования системы;

- взаимодействие персонала между собой и другими организациями и предприятиями города в условиях функционирования АИС;

- структуру и порядок взаимодействия элементов АИС;

- затраты, источники и эффективность использования денежных средств;

- должностные инструкции, устанавливающие функции, права, обязанности и ответственность работников, участвующих в эксплуатации АИС.

Эксплуатация АИС должна осуществляться персоналом служб и отделов предприятий в соответствии с установленными полномочиями.

Функции пользователей и порядок работы в АИС должны быть описаны в документе «Руководство пользователя».

Обучение специалистов правилам работы с программным обеспечением АИС должно происходить в процессе опытной эксплуатации.

Состав, содержание и стоимость работ по созданию системы

Состав и сроки выполнения работ каждой очереди должны определяться календарным планом работ по созданию системы.

Создание автоматизированной системы должно быть выполнено в срок с 1 октября 2010 года. Контрольные точки предусмотрены в рамках лабораторных работ. Если продукт не соответствует его требованиям, имеется возможность исправления и доработки. Ответственным за проведение этих работ является студентка группы ПИЭ-81 Дарья Альбертовна Кадушкина.

№	Наименование работы	Код работы	Исполнитель	Дата начала	Длительность выполнения	Дата окончания
1	Определение целей, задач и функций объекта	001	Руководитель проекта	01.10.10	2	02.10.10
2	Определение основных параметров объекта	002	Руководитель проекта	03.10.10	2	04.10.10
3	Изучение и описание организационной и функциональной структур объекта	003	Зам. руководителя проекта	05.10.10	1	05.10.10
4	Изучение методов и методик управления	004	Кадушкина Д.А.	06.10.10	30	06.11.10
4.1	задачи, функции, документы,	005	Кадушкина Д.А.	07.11.10	5	11.11.10
4.2	методики расчета показателей	006	Кадушкина Д.А.	12.11.10	10	22.11.10
4.3	внутренние и внешние связи объекта	007	Кадушкина Д.А.	23.11.10	10	2.12.10
4.4	должностные инструкции персонала	008	Кадушкина Д.А.	3.12.10	5	7.12.10
5	Изучение и описание информационных потоков объекта	009	Кадушкина Д.А.	8.12.10	15	23.12.10
6	Изучение и описание материальных потоков объекта	010	Кадушкина Д.А.	24.12.10	15	19.01.11
7	ТЗ	011	Кадушкина Д.А.	20.01.11	5	25.01.11
8	ТЭО	012	Кадушкина Д.А.	26.01.11	3	29.01.11
9	Техническое проектирование	013	Кадушкина Д.А.	30.01.11	52	1.04.11
9.1	Разработка основных положений по новой системе	014	Кадушкина Д.А.	30.01.11	2	31.01.11
9.2	Описание организационной и функциональной структур	015	Кадушкина Д.А.	1.02.11	3	3.02.11
9.3	Разработка принципов организации ИО и внутримашинной БД	016	Кадушкина Д.А.	4.02.11	5	8.02.11
9.4	Разработка постановки решения задачи	017	Кадушкина Д.А.	9.02.11	7	15.02.11
9.5	Разработка форм документов и системы их ведения	018	Кадушкина Д.А.	16.02.11	5	20.02.11
9.6	Разработка классификаторов и кодов	019	Кадушкина Д.А.	21.02.11	5	25.02.11
9.7	Разработка структуры входных и выходных сообщений	020	Кадушкина Д.А.	26.02.11	5
9.8	Разработка макетов и структур файлов	021	Кадушкина Д.А.	2.03.11	3	4.03.11
9.9	Разработка внутримашинной и внемашинной технологии решения каждой задачи	022	Кадушкина Д.А.	5.03.11	3	7.03.11
9.10	Уточнение состава переферийной техники	023	Кадушкина Д.А.	8.03.11	3	10.03.11
9.11	Уточнение состава аппартной платформы проекта	024	Кадушкина Д.А.	11.03.11	3	13.03.11
9.12	Разработка проектно-сметной документации	025	Кадушкина Д.А.	14.03.11	5	18.03.14
9.13	Расчет экономической эффективности АИС	026	Кадушкина Д.А.	19.03.11	5	23.03.11
9.14	Разработка плана мроприятий по подготовке к внедрению системы	027	Кадушкина Д.А.	24.03.11	4	27.03.11
9.15	ТП	028	Кадушкина Д.А.	28.03.11	5	1.04.11
10	Рабочее проеатирование	029	Кадушкина Д.А.	2.04.11	20	21.04.11
10	Разработка технологических документов и инструкций	030	Кадушкина Д.А.	2.04.11	5	6.04.11
10.1	Разработка технологических документов и инструкций	031	Кадушкина Д.А.	7.04.11	5	11.04.11
10.2	Разработка правовых инструкций	032	Кадушкина Д.А.	12.04.11	5	16.04.11
10.3	Оформление рабочего проекта	033	Кадушкина Д.А.	17.04.11	5	21.04.11
11	Стадия внедрения	034	Кадушкина Д.А.	22.04.11	15	6.05.11
11.1	Подготовка объекта к внедрению	035	Кадушкина Д.А.	22.04.11	5	26.04.11
11.2	Опытное внедрение	036	Кадушкина Д.А.	27.04.11	5	1.05.11
11.3	Сдача проекта в промышленную эксплуатацию	037	Кадушкина Д.А.	2.05.11	5	6.05.11
12	Стадия эксплуатации и сопровождения	038	Кадушкина Д.А.	6.05.11	5	10.05.11

Порядок контроля и приемки системы

Ввод в действие АИС «Магазин Бытовой Техники» должен осуществляться в соответствии с ГОСТ 34.6О1-90 «Автоматизированные системы. Стадии создания».

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

Приемка работ по созданию каждой очереди системы должна проходить в два этапа:

- приемка на контрольном примере;

- ввод в опытную эксплуатацию (ОЭ).

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

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

- обучение пользователей правилам эксплуатации системы;

- проверка реализации функций системы на реальных данных;

- проверка информационных связей системы с другими системами;

- доработка системы и корректировка документа «Руководство пользователя» по замечаниям Заказчика.

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

По завершении комплексной отладки и опытной эксплуатации системы в целом АИС «Магазин Бытовой Техники» должна быть сдана в промышленную эксплуатацию.

Приемка АИС «Магазин Бытовой Техники» в промышленную эксплуатацию заключается в выполнении следующих работ:

- проверки соответствия выполненных работ требованиям технического задания;

- проверки работоспособности системы на реальных данных;

- проверки подготовленности пользователей к работе с системой;

- выработки рекомендаций по дальнейшему развитию системы.

Для приемки АИС «Магазин Бытовой Техники» в промышленную эксплуатацию должна быть создана приемочная комиссия, в которую входят представители Заказчика и Разработчика.

Работа комиссии завершается подписанием актом приемки-передачи программного продукта.

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие

Для подготовки к вводу в действие АИС «Магазин Бытовой Техники» необходимо выполнить следующие основные мероприятия:

Организационные мероприятия:

- провести обучение персонала;

- назначить системного администратора;

- ввести изменения в должностные инструкции.

Технические мероприятия:

- оборудовать помещения, в которых будут размещены ПЭВМ, соответствующим количеством двухполюсных розеток 220В (с заземлением), из расчета - 2 розетки на одну ПЭВМ;

- оборудовать помещения, в которых размещаются ПЭВМ, средствами охранной и пожарной сигнализации;

- осуществить монтаж и наладку комплекса технических средств;

Организация базы нормативно-справочной информации:

- провести анализ используемой нормативно-справочной информации (НСИ);

- выбрать классификаторы информации;

- завести НСИ на машинные носители информации.

Работы по п.п. 7.1.1 - 7.1.3 выполняет Заказчик АИС.

Требования к документированию

При создании системы должна быть разработана следующая технорабочая документация:

- Перечень входных данных и выходных документов;

- Описание массива информации (структура таблиц информационной базы);

- Руководство пользователя (для соответствующих рабочих мест).

Технорабочая документация АИС «Магазин Бытовой Техники» должна разрабатываться в соответствии с государственными стандартами:

ГОСТ 34.2О1-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»;

РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».

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

Функциональное программное обеспечение должно устанавливаться на жестких магнитных дисках ПЭВМ Заказчика.

4.4 Источники разработки

Техническое задание разрабатывалось на основание ФЕЛДЕРАЛЬНОГО ЗАКОНА о малом предпринимательстве в Российской Федерации, устава предприятия, экономическим требованиям к рабочим.



5. Проектирование системы

5.1 Моделирование системы

Рассмотрим моделирование бизнес - классов.

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

1. «Покупатели» - код покупателя, ФИО, серия паспорта, № паспорта, дата выдачи, кем выдан, адрес, телефон.

2. «Поставщики» - код поставщика, полное наименование, ИНН, КПП, код по ОКПО, адрес, телефон.

3. «Банки» - код банка, наименование, корреспондирующий счет, БИК, адрес, телефон.

4. «Сервисные центры» - код сервисных центров, наименование, адрес, телефон.

5. «Товары» - код товара, наименование товара, № счет-фактуры, единица измерения, дата счет-фактуры, закупочная стоимость, продажная стоимость, поставщик.

6. «Сотрудники» - код сотрудника, табельный номер, ФИО, дата приема на работу, № договора, подразделение, должность.

7. «Гарантийное обслуживание» - код гарантийного обслуживания, наименование товара, дата продажи, дата поступления по гарантийному талону, дата отправки в сервисный цент, данные покупателя.

8. «Журнал продаж» - код журнала продаж, наименование предприятия, период, остатки на начало и конец дня, наименование товара, приход и расход товара, количество и сумма.

9. «Проценты» - код проценты, кредит, рассрочка

10. «Договора с поставщиками» - № договора, предмет договора, поставщик, адрес поставщика, дата составления договора, дата окончания договора.

11. «Договора с покупателями» - № договора с покупателями, предмет договора, ФИО покупателя, адрес покупателя, № страхового свидетельства, дата составления договора, дата окончания договора, стоимость товара.

12. «Договора с сервисными центрами» - № договора с сервисными центрами, предмет договора, наименование сервисного центра, адрес, дата составление договора, дата окончания договора.

13. «Отчет «О финансовых результатах» - Код отчета, начальная дата, конечная дата, вид деятельности, наименование статьи, сумма, финансовый результат.

Теперь опишем взаимосвязь между бизнес классами системы:

Поставщики связаны со справочником банки так как из справочника банки выбирается соответствующий банк для перевода средств за поставленный товар.

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

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

Справочник товары связан со справочником поставщики для занесения в базу товары данных о поставщике.

В журнал продаж заносятся все данные о покупателе товаре и поставщике, так как на его основание потом производится составление отчета.



Рисунок 22 - Логическая модель бизнес классов предметной области

Рисунок 23 - Физическая модель бизнес классов



Договор с поставщиками связан со справочниками поставщики и банки.

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

Договор с сервисными центрами связан со справочниками сервисные центры и банки.

5.2 Описание постановок задач

ДОГОВОР С ПОКУПАТЕЛЯМИ

1. Характеристика задачи

1.1. Цель: Оформление договора

1.2. Назначение: Целью работы карточной формы является внесение данных в договор о новом клиенте. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Договор с покупателями». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: Расчет суммы товара оформленного в рассрочку или в кредит.

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

1.5. Описание алгоритма для решения задач: Формулой для решения данной задачи будет являться - стоимость товара + % по кредиту или рассрочке.

1.6. Периодичность: Договоры с покупателями заключаются по мере обращения покупателей.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов.

1.8. Связи с другими задачами: Данная база связана с базой проценты по кредиту.

2. Выходная информация

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

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Договор с покупателями	ДП	1. Код договора с покупателями; 2. Дата составления; 3.Предмет договора; 4. № договора; 5. ФИО покупателя; 6. Адрес покупателя; 7. Дата составления договора; 8. Дата окончания договора; 9. Стоимость товара.

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Договоры с покупателями, код договора с покупателями - INTEGER, договор оформляется по мере обращения клиентов, сроки получения сразу после приобретения товара.



Рисунок 23 - Договоры с покупателями

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о покупателе. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	Данные паспорта	Состав реквизитов: - ФИО покупателя - Адрес покупателя - № паспорта, серия - кем и когда выдан
2	Страховое свидетельство	№ страхового свидетельства

Рисунок 24 - Договоры с покупателями входная форма

3.2. Наименование, идентификатор, форма, требования к точности, источник - Договор с покупателями, код договора с покупателями INTEGER, должна соблюдаться полная точность документа так как на основание договора оформляется кредит или рассрочка на товар, источником данных 80вляяются первичные документы.

ДОГОВОР С ПОСТАВЩИКАМИ

1. Характеристика задач

1.1. Цель: Оформление договора

1.2. Назначение: Целью работы карточной формы является внесение данных в договор о новом поставщике. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Договор с поставщиками». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: Расчет суммы, на которую будет заказан товар.

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

1.5. Описание алгоритма для решения задач: Формулой для решения данной задачи будет являться - стоимость товара * количество товара. Расчет суммы, на которую заказан товар.

1.6. Периодичность: Договоры с поставщикам заключаются при необходимости в товаре.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов.

1.8. Связи с другими задачами: Данная база связана с базой поставщики.

2. Выходная информация

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

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Договор с поставщиками	ДПС	· № договора, · предмет договора, · поставщик, · адрес поставщика, · дата составления договора, · дата окончания договора

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Договоры с поставщиками, код договора с поставщиками - INTEGER, договор оформляется, однократна и изменяется при изменение данных поставщика, сроки получения начало года

Рисунок 25 - договоры с поставщиками выходная форма

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о поставщике. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	ИНН	Состав реквизитов: - № - кем выдан
2	КПП	№ КПП Кем выдан

3.2. Наименование, идентификатор, форма, требования к точности, источник - Договор с поставщиками, код договора с поставщиками INTEGER, должна соблюдаться полная точность документа так как на основание договора основывается вся дальнейшая работа с поставщиками, источником данных являются первичные документы.

Рисунок 26 - Договоры с поставщиками входная форма

ДОГОВОР С СЕРВИСНЫМИ ЦЕНТРАМИ

1. Характеристика задачи

1.1. Цель: Оформление договора

1.2. Назначение: Целью работы карточной формы является внесение данных в договор о новом сервисном центре. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Договор с сервисным центром». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: Расчет суммы за ремонт товара если поломка произошла по вине потребителя.

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

1.5. Описание алгоритма для решения задач: Формулой для решения данной задачи будет являться - стоимость всех запчастей в сумме.

1.6. Периодичность: Договоры с сервисными центрами заключаются по мере поступления товара по гарантии.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов.

1.8. Связи с другими задачами: Данная база связана с базой сервисные центры.

2. Выходная информация

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

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Договор с сервисными центрами	ДСЦ	· № договора с сервисными центрами, · предмет договора, · наименование сервисного центра, · адрес, · дата составление договора, · дата окончания договора.

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Договоры с сервисными центрами, код договора с сервисными центрами - INTEGER, договор оформляется однократно в начале года, данные добавляются или изменяются при изменение данных сервисного центра, сроки получения в начале года.

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о сервисном центр. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	ИНН	Состав реквизитов: - № - кем выдан
2	КПП	№ КПП Кем выдан

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

Рисунок 27 - Договоры с сервисными центрами входная форма

ПОКУПАТЕЛИ

1. Характеристика задачи

1.1. Цель: Внесение данных о новом покупателе

1.2. Назначение: Целью работы карточной формы является внесение данных о новом покупателе. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Покупатели». Модуль вызывается из главного меню программы.

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

1.4. Описание алгоритма для решения задач: отсутствует.

1.5. Периодичность: добавление покупателя в базу происходит по мере их обращения.

1.6. Требования к организации исходных данных: Исходные данные берутся из первичных документов: паспорта.

1.7. Связи с другими задачами: Данная база связана с базой договоры с покупателями. При оформление нового договора данные о покупатели берутся из базы покупатели.

2. Выходная информация

2.1. Перечень описания выходных сообщений и документов: выходным сообщением будет являться ошибка при внесение несоответствующих данных. Выходным документом будет являться сформированный список покупателей.

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Покупатели	ПК	· код покупателя, · ФИО, · серия паспорта, · № паспорта, · дата выдачи, · кем выдан, · адрес, · телефон.



2.2. Наименование, идентификатор, форма, периодичность, сроки получения - покупатели, код покупателя - INTEGER, данные заносятся по мере обращения клиента, данный список предназначен только для персонала магазина.

Рисунок 28 - Покупатели

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о покупателе. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	Данные паспорта	Состав реквизитов: - ФИО покупателя - Адрес покупателя - № паспорта, серия - дата выдачи - кем и когда выдан

3.2. Наименование, идентификатор, форма, требования к точности, источник - Покупатели, код покупатели INTEGER, должна соблюдаться полная точность внесения данных, так как на данного человека оформляется кредит, источником данных являются первичные документы.



Рисунок 29 - справочник покупатели входная форма

ПОСТАВЩИКИ

1. Характеристика задачи

1.1. Цель: Добавление данных о новом поставщике.

1.2. Назначение: Целью работы карточной формы является внесение данных о новом поставщике. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Поставщики». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: отсутствует, так как база 93вляяется справочником.

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

1.5. Описание алгоритма для решения задач: Отсутствует.

1.6. Периодичность: Данные о поставщике вносятся однократно, и изменяются при изменении данных поставщика. Так же добавляются поставщики.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, которые предоставляет поставщик.

1.8. Связи с другими задачами: Данная база связана с базой договоры с поставщиками. При заполнении договора с поставщиками из базы поставщики берутся все его данные.

2. Выходная информация

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

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Поставщики	ПС	· код поставщика, · полное наименование, · ИНН, · КПП, · код по ОКПО, · адрес, · телефон

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - поставщики, код поставщики - INTEGER, данные заносятся однократно изменяются при появление нового поставщика или изменение данных поставщика, данный список формируется и используется только персоналом магазина.

Рисунок 30 - Справочник поставщики выходная форма

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о покупателе. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	ИНН	Состав реквизитов: №; кем выдан
2	КПП	№ КПП; Кем выдан
	ОКПО	Код по ОКПО

3.2. Наименование, идентификатор, форма, требования к точности, источник - Поставщики, код поставщики - INTEGER, должна соблюдаться полная точность так как работа и расчеты с поставщиками происходят постоянно, источником данных являются первичные документы.

Рисунок 31 справочник поставщики входная форма

БАНКИ

1. Характеристика задачи

1.1. Цель: Внесение данных о новом банке

1.2. Назначение: Целью работы карточной формы является внесение данных о новом банке. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Банки». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: отсутствует, так как база является справочником.

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

1.5. Описание алгоритма для решения задач: отсутствует.

1.6. Периодичность: данные о банках заносятся однократно, происходит лишь обновление в начале каждого года.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, которые предоставляет банк.

1.8. Связи с другими задачами: Данная база связана с базой покупатели.

2. Выходная информация

2.1. Перечень описания выходных сообщений и документов: выходным сообщением будет являться ошибка при внесение несоответствующих данных. Выходным документом будет являться сформированный список.

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Банки	БН	· код банка, · наименование, · корреспондирующий счет, · БИК, · адрес, · телефон.

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Банки, код Банки - INTEGER, список формируется либо корректируется однократно, и используется только персоналом магазина.

Рисунок 32 - Справочник банки выходная форма

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о покупателе. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	Корреспондирующий счет	Состав реквизитов: Корреспондирующий счет
2	БИК	БИК

3.2. Наименование, идентификатор, форма, требования к точности, источник - Банк, код банк - INTEGER, должна соблюдаться полная точность документа так как на основание этих данных происходит оформление кредита покупателю и в дальнейшем перечисление денег на данный счет, источником данных являются первичные документы.

Рисунок 33 - Справочник банки входная форма

СЕРВИСНЫЕ ЦЕНТРЫ

1. Характеристика задачи

1.1. Цель: Внесение данных о новом сервисном центре

1.2. Назначение: Целью работы карточной формы является внесение данных о новом сервисном центре. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Сервисные центры». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: отсутствует, так как база является справочником.

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

1.5. Описание алгоритма для решения задач: отсутствует.

1.6. Периодичность: данные о сервисных центрах заносятся однократно, происходит лишь обновление в начале каждого года.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, которые предоставляет сервисный центр.

1.8. Связи с другими задачами: Данная база не связана с с другими базами.

2. Выходная информация

2.1. Перечень описания выходных сообщений и документов: выходным сообщением будет являться ошибка при внесение несоответствующих данных. Выходным документом будет являться сформированный список.

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Сервисные центры	СЦ	· код сервисных центров, · наименование, · адрес, · Телефон

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



Рисунок 34 - Справочник сервисные центры выходная форма

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о сервисном центре. Входящими документами будут являться первичные документы.

3.2. Наименование, идентификатор, форма, требования к точности, источник - сервисные центры, код сервисные центры - INTEGER, должна соблюдаться полная точность так как в дальнейшее происходит отправка товара на ремонт в сервисные центры, источником данных являются первичные документы.

Рисунок 35 - Справочник сервисные центры входные формы

ТОВАРЫ

1.Характеристика задачи

1.1. Цель: Внесение данных о новом товаре

1.2. Назначение: Целью работы карточной формы является внесение данных о поступившем товаре. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Товары». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: отсутствует, так как база является справочником.

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

1.5. Описание алгоритма для решения задач: отсутствует.

1.6. Периодичность: данные о товарах заносятся по мере поступления товара в магазин.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, счет - фактуры.

1.8. Связи с другими задачами: База связана с базой поставщики.

2. Выходная информация

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

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Товары	Т	· код товара, · наименование товара, · № счет-фактуры, · дата счет-фактуры, · закупочная стоимость, · продажная стоимость, · единица измерения, · поставщик



2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Товары, код товары - INTEGER, список пополняется при поступление нового товара, используется только персоналом магазина.

Рисунок 36 - справочник товары выходная форма

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о товаре. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	Счет фактура	Состав реквизитов: - наименование товара № с/ф Дата с/ф поставщик

3.2. Наименование, идентификатор, форма, требования к точности, источник - товары, код товары - INTEGER, должна соблюдаться полная точность так как на основание этих данных товар оформляется в кредит и отправляется по гарантии, источником данных являются первичные документы.



Рисунок 37 - справочник товары входная форма

СОТРУДНИКИ

1.Характеристика задачи

1.1. Цель: Внесение данных о новом сотруднике

1.2. Назначение: Целью работы карточной формы является внесение данных о новом сотруднике. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Сотрудники». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: отсутствует, так как база 104вляяется справочником.

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

1.5. Описание алгоритма для решения задач: отсутствует.

1.6. Периодичность: данные о банках заносятся при поступление нового сотрудника на работу, или смене личных данных сотрудников.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, которые предоставляет сотрудник: трудовая книжка, паспорт, ИНН.

1.8. Связи с другими задачами: Данная база не связана с другими базами.

2. Выходная информация

2.1. Перечень описания выходных сообщений и документов: выходным сообщением будет являться ошибка при внесение несоответствующих данных. Выходным документом будет являться сформированный список.

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Сотрудники	С	· код сотрудника, · табельный номер, · ФИО, · дата приема на работу, · № договора, · подразделение, · должность.

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - сотрудники, код сотрудники - INTEGER, список дополняется при приеме сотрудника на работу, список предназначен для персонала магазина.

Рисунок 38 - справочник сотрудники выходная форма

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о сотруднике. Входящими документами будут являться первичные документы.



№	Наименование	Реквизиты
1	Данные паспорта	Состав реквизитов: - ФИО покупателя - Адрес покупателя - № паспорта, серия - кем и когда выдан

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

Рисунок 39 - справочник сотрудники входная форма

ГАРАНТИЙНОЕ ОБСЛУЖИВАНИЕ

1.Характеристика задачи

1.1. Цель: Внесение данных о гарантийном обслуживание

1.2. Назначение: Целью работы карточной формы является внесение данных о гарантийном обслуживание. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Гарантийное обслуживание». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: расчет суммы, если ремонт товара производился за счет покупателя, т.е. если вины производителя в поломке товара нет.

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

1.5. Описание алгоритма для решения задач: сумма стоимости всех запчастей необходимых для ремонта.

1.6. Периодичность: данные о банках заносятся по мере поступления товара по гарантии.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, технического паспорта товара.

1.8. Связи с другими задачами: Данная база связана с базой сервисные центры и договора с сервисными центрами.

2. Выходная информация

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

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Гарантийное обслуживание	ДП	· код гарантийного обслуживания, · наименование товара, дата продажи, · дата поступления по гарантийному талону, · дата отправки в сервисный цент, · данные покупателя.

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Гарантийное обслуживание, код гарантийное обслуживание - INTEGER, список формируется по мере обращения клиентов с товаром по гарантии, сроки получения гарантийного талона сразу по прибытию товара с гарантийного ремонта.

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о товаре. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
1	Счет фактура	Состав реквизитов: - наименование товара № с/ф Дата с/ф

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

Рисунок 40 - гарантийное обслуживание входная форма

ЖУРНАЛ ПРОДАЖ

1.Характеристика задачи

1.1 Цель: Внесение данных о проданном товаре и остатках на начало и конец дня.

1.2. Назначение: Целью работы карточной формы является внесение данных о проданном товаре и остатках. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Журнал продаж». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: расчет суммы проданного товара, расчёт остатков на начало и конец дня.

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

1.5. Описание алгоритма для решения задач: сумма всех проданных товаров и подсчет остатков на конец дня - остатки на начало дня - продано товаров.

1.6. Периодичность: данные заносятся при продаже товара.

1.7. Требования к организации исходных данных: Исходные данные берутся из ценников и счет-фактуры.

1.8. Связи с другими задачами: Данная база связана с базой товары.

2. Выходная информация

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

Журнал продаж

На __.__.____г.

Наименование организации

Остаток на начало дня	Приход	Расход
	Количество	Сумма	Количество	Сумма



В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Журнал продаж	ДП	· код журнала продаж, · наименование предприятия, · период, · Остатки на начало дня, · Остатки на конец дня, · Наименование товара, · Расход товара, · Количество, · Сумма, · Приход товара.

2.3. Наименование, идентификатор, форма, периодичность, сроки получения - Журнал продаж, код журнала продаж - INTEGER, журнал продаж формируется ежедневно, записи вносятся в начале и конце дня.

3. Входная информация.

3.2. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о проданном товаре. Входящими документами будут являться первичные документы.

№	Наименование	Реквизиты
	Тех. Паспорт	Наименование товара

3.3. Наименование, идентификатор, форма, требования к точности, источник - Журнал продаж, код журнал продаж - INTEGER, должна соблюдаться полная точность документа так как на основание журнала продаж формируется Отчет, источником данных являются первичные документы.



Рисунок 41 - журнал продаж входная форма

ПРОЦЕНТЫ

1. Характеристика задачи

1.1. Цель: Внесение данных о новом проценте

1.2. Назначение: Целью работы карточной формы является внесение данных о новом проценте. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Проценты». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: отсутствует, так как база является справочником.

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

1.5. Описание алгоритма для решения задач: отсутствует.

1.6. Периодичность: данные о новых процентах заносятся, при каких либо изменениях процентов.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, которые предоставляет банк.

1.8. Связи с другими задачами: Данная база связана с базой договоры с покупателями, банки.

2. Выходная информация

2.1. Перечень описания выходных сообщений и документов: выходным сообщением будет являться ошибка при внесение несоответствующих данных. Выходным документом будет являться сформированный список.

В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Проценты	П	Код процента Кредит Рассрочка

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - проценты, код проценты - INTEGER, данные заносятся однократно в базу.

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные о процентах. Входящими документами будут являться документы предоставляемые банком.

3.2. Наименование, идентификатор, форма, требования к точности, источник - проценты, код проценты - INTEGER, должна соблюдаться полная точность документа так как на основание процентов происходит начисление процентов по кредиту и рассрочке, источником данных являются первичные документы.

ОТЧЕТ «О ФИНАНСОВЫХ РЕЗУЛЬТАТАХ»

1. Характеристика задачи

1.1. Цель: Заполнение отчета.

1.2. Назначение: Целью работы карточной формы является заполнение отчета. Форма позволяет вносить и просматривать данные в удобном для пользователя формате. Присвоить модулю наименование «Отчет». Модуль вызывается из главного меню программы.

1.3. Экономическая сущность задачи: подсчет финансового результата.

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

1.5. Описание алгоритма для решения задач: Подсчет всех сумм и выведение финансового результата.

1.6. Периодичность: Отчет «О финансовых результатах» заполняется 1 раз в квартал и в конце года формируется итоговый.

1.7. Требования к организации исходных данных: Исходные данные берутся из первичных документов, которые предоставляет продавцы.

1.8. Связи с другими задачами: Данная база связана с базой журнал продаж.

2. Выходная информация

2.1. Перечень описания выходных сообщений и документов: выходным сообщением будет являться ошибка при внесение несоответствующих данных. Выходным документом будет являться сформированный отчет.

Отчет

«О финансовых результатах»

за период с __.__.____г. По __.__.____г.

Наименование организации______________________________

Вид деятельности______________________________________

Показатель	За отчетный период
Наименование	код
Финансовый результат



В таблице представлено описание выходных документов:

№	Наименование	Кодовое обозначение	Структурная единица информации
1	Отчет	О	· Код отчет · Начальная дата · Конечная дата · Вид деятельности · Наименование статьи · Сумма · Финансовый результат

2.2. Наименование, идентификатор, форма, периодичность, сроки получения - Отчет, код отчет - INTEGER, отчет формируется в конце каждого квартала.

3. Входная информация.

3.1. Перечень описания входных документов и сообщений - входными сообщения будут являться данные журнала. Входящими документами будут являться первичные документы.

3.2. Наименование, идентификатор, форма, требования к точности, источник - Отчет, код Отчет - INTEGER, должна соблюдаться полная точность документа, источником данных являются первичные документы.