![](/stc/img/evkova.png)
Проектирование реализации операций бизнес-процесса «Контроль поставок товара
Содержание:
Введение
В нынешнее время автоматизация затронула практически все сферы человеческой жизни-деятельности.
Понятно, что на преимущества автоматизации одни из первых отреагировали и принялись их использовать в своей работе коммерческие предприятия. Одним из таких бизнес-процессов, который подлежит автоматизации в одну из первых очередей – это разного вида учеты, непременно это касаемо учета продаж. Продажи прямо взаимосвязаны с поставками товаров. Поэтому данная тема важна в нынешнее время.
Автоматизация учета продаж достаточно хорошо изучена. Создано много информационных систем для автоматизации. Но все эти разработки, несмотря на все свои достоинства, не учитывают специфики деятельности организации, так как у каждой организации свои требования к автоматизируемым процессам. Поэтому автоматизированная система будет разрабатываться самостоятельно.
Целью работы служит создание информационной системы по автоматизации контроля поставок товара.
Задачи, которые нужно выполнить для получения поставленной цели:
- Обзор и изучение литературы;
- Моделирование бизнес-процессов предприятия;
- Выявление недостатков существующей системы;
- Выбор и пояснение программного и информационного обеспечения для выполнения задачи;
- Проектирование базы данных.
Объектом исследования являются поставки товара.
Предмет исследования – процесс проектирования ИС.
Аналитическая часть
1.1. Характеристика комплекса задач
1.1.1. Выбор комплекса задач автоматизации
Обувь с торговой маркой «ТОФА» выпускается на фабрике, которая находится в г. Донской в Тульской области.
Ежегодно Тульская обувная фабрика «ТОФА» выпускает более 500 000 пар женской и мужской обуви для повседневной носки, с учетом особенностей российской стопы и климатических условий, в которых эксплуатируется обувь.
На конвейерах предприятия работает более 900 квалифицированных работников.
Обувь выпускается на современном техническом оборудовании итальянского и немецкого производств, данное оборудование стоит в Европе на нем производятся известные торговые бренды такие как Salamander, LLOYD, HOGL. Технологи, модельеры, мастера производства каждый год проходят курсы повышения квалификации в Италии и Германии.
Обувь «ТОФА» отмечена на международных выставках призами и наградами.
Опишем процессы, происходящие в отделе поставок.
- Менеджер принимает заказ от клиентов на поставку обуви.
- Регистрирует клиента в списке клиентов.
- Регистрирует заказ клиента в реестре заказов.
- Составляет счет-фактуры для поставщика.
- Менеджер отдела поставок выбирает поставщика для исполнения заказа.
- После чего поставщик принимает заказ или отказывается от него, если поставщик отказывается от заказа, то менеджер вновь выбирает поставщика. И так пока поставщик не примет заказ.
- Менеджер отдела поставок получает счет от поставщика и передает его бухгалтеру для оплаты.
- Бухгалтер оплачивает счет и получает у банка платежное поручение, подтверждающее оплату счета.
- Менеджер отдела поставок получает платежное поручение.
- После получения платежного поручения менеджер выписывает доверенность экспедитору на получение товара у поставщика.
- Экспедитор выезжает к поставщику и получает товар.
- По приезду экспедитор заполняет накладную для отгрузки товара клиенту.
Таблица 1
Операции бизнес-процесса «Деятельность отдела поставок»
Операция |
Исполнитель |
Периодичность |
Входной документ |
Выходной документ |
Комментарии |
1. Получение заказа |
Менеджер одела поставок |
По мере поступления |
Заказ |
||
2. Регистрация клиента |
Менеджер одела поставок |
По мере поступления |
Заказ |
Список клиентов |
Клиент вносится в список клиентов |
3. Составление и регистрация заказа |
Менеджер одела поставок |
По мере поступления |
Заказ |
Реестр заказов |
Заказ вносится в реестр заказов |
4. Выбор поставщика и передача ему заказа |
Менеджер одела поставок |
По мере поступления |
Список поставщиков |
||
5. Прием заказа |
Поставщик |
По мере поступления |
Заказ |
||
6. Выставление счета |
Поставщик |
По мере поступления |
Заказ |
Счет-фактура |
|
7. Получение счета и передача его бухгалтеру для оплаты |
Менеджер одела поставок |
По мере поступления |
Счет-фактура |
Счет-фактура |
|
8. Оплачивает счет |
Бухгалтер |
По мере поступления |
Счет-фактура |
||
9. Выписывает доверенность на получение товара |
Менеджер одела поставок |
По мере поступления |
Доверенность |
||
10. Получает товар у поставщика |
Экспедитор |
По мере поступления |
Доверенность |
||
11. Заполнение накладной |
Экспедитор |
По прибытию с товаром |
Накладная |
Заполненная накладная |
|
12. Отметка о выполнении заказа |
Менеджер одела поставок |
По мере поступления |
Реестр заказов |
Реестр заказов с отметкой о выполнении |
|
13. Формирование отчета |
Менеджер одела поставок |
Ежемесячно |
Реестр заказов с отметкой о выполнении |
Отчет |
Схема связей задач бизнес-процесса «Деятельность отдела поставок» изображена на Рисунке 1
07
01
05
02
03
04
06
08
09
10
11
12
13
Рисунок 1 Схема связей задач бизнес-процесса «Деятельность отдела поставок»
Таблица 2
Документов бизнес-процесса «Деятельность отдела поставок»
Исходящий документ (составляемый документ) |
Операция |
Исполнитель |
Периодичность |
Входящие документы (документы-обновления) |
Комментарий |
1.Список клиентов |
Регистрация клиента |
Менеджер одела поставок |
По мере поступления |
Заказ |
|
2. Реестр заказов |
Регистрация заказа |
Менеджер одела поставок |
По мере поступления |
Заказ |
|
3.Счет-фактура |
Выставление счета поставщика и передача ему заказа. Ответ поставщика |
Поставщик |
По мере поступления |
Заказ |
|
4. Список поставщиков |
Выбор поставщика - передача ему заказа |
Менеджер одела поставки. |
По мере поступления |
||
5.Доверенность |
Выписывает доверенность |
Менеджер одела поставки. |
По мере поступления |
||
6. Накладная |
Заполнение накладной |
Экспедитор |
По мере поступления |
Заполненная накладная |
|
7. Отчет |
Формирование отчета |
Менеджер одела поставок. |
Ежемесячно |
Реестр заказов |
Исходной информацией для ведения отчета о заказах служит:
1) Реестр заказов
2) Список экспедиторов
3) Список товаров
Характеристика исходной информации приведена в таблице 3.
Таблица 3
Характеристика исходной информации
Наименование информации |
Общая характеристика информации |
Источники информации |
Сроки сбора информации |
Способ поступления |
Реестр заказов |
Текущая информация |
заказы |
По мере необходимости |
Лично |
Список экспедиторов |
Текущая информация |
Паспортные данные |
По мере необходимости |
Лично |
Список товаров |
Текущая информация |
заказ |
По мере необходимости |
Лично |
Таблица 4
Идентификаторы документа «Реестр заказов»
Наименование реквизита |
Идентификатор |
Разрядность |
Примечание |
Номер заказа |
Id_zak |
9999 |
|
Номер экспедитора |
Id_eksp |
999 |
|
Номер товара |
Id_tovar |
9999 |
|
Кол-во товара |
Kolvo_tovara |
A(25) |
|
Дата отгрузки |
Data_otgr |
99/99/99 |
Таблица 5
Идентификаторы документа «Список экспедиторов»
Наименование реквизита |
Идентификатор |
Разрядность |
Примечание |
Фамилия |
fam |
A(25) |
|
Имя |
nam |
A(25) |
|
Отчество |
otch |
A(25) |
|
Номер экспедитора |
Id_eksp |
999 |
Таблица 6
Идентификаторы документа «Список товаров»
Наименование реквизита |
Идентификатор |
Разрядность |
Примечание |
Номер товара |
Id_tovar |
999 |
|
Название товара |
Nam_tovar |
A(25) |
- Документ «Реестр заказов»:
Контроль соответствия реквизитов «Номер заказа», «Номер экспедитора», «Номер товара», «Количество товара» «Дата отгрузки» списку значений базы данных;
Арифметический контроль реквизитов «Кол-во товара».
- Документ «Список экспедиторов»:
Контроль соответствия реквизитов «Фамилия», «Имя», «Отчество» списку значений базы данных;
- Документ «Список товаров»:
Контроль соответствия реквизитов «Номер товара», «Название товара»;
1.1.2. Характеристика существующих бизнес-процессов
Схемы описанных выше процессов приведены на рис.1-8.
Рис.1. Деятельность отдела поставок
Рис. 2. Декомпозиция бизнес-процесса «Деятельность отдела поставок»
Рис.3. Декомпозиция бизнес-процесса «Работа с поставщиком и отгрузка товара»
Рис. 4. Декомпозиция бизнес-процесса «Выбор поставщика»
Рис.5. Декомпозиция бизнес-процесса «Оплата счета и выписка доверенности»
Рис. 6. Декомпозиция бизнес-процесса «Прием и отгрузка заказа»
Рис. 7. Декомпозиция бизнес-процесса «Регистрация заказа и клиента»
Рис. 8. Детализация бизнес-процесса «Формирование отчета»
1.1.3. Характеристика документооборота, возникающего при решении задачи
Главным документом в наблюдаемой задаче служит договор поставки. Схема документооборота обработки продаж приведена на рис. 9.
Исполнитель Действие |
Отдел продаж |
Бухгалтерия |
Склад |
Клиент |
1) Поступление заявки |
||||
2) Фиксация заявки в журнале |
||||
3) Оформление заказа у поставщика |
||||
4) Отправка заказа |
||||
5) Отправка товара |
||||
6) Подготовка отчетов |
Рис.9. Схема документооборота
Существующий способ приема и обработки продаж связан с большой трудоемкостью, разрозненностью сведений, что с большой вероятностью ведет к их утере или неправильной интерпретации. На сегодняшний день сложно получить сведения об общем количестве продаж, провести анализ популярности тех или иных моделей обуви, а также проконтролировать заказы, обработанные каждым из менеджеров.
Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы отдела продаж за определенный период, что очень затруднительно.
Временные характеристики описанных процессов приведены в таблице 7.
Таблица 7
Характеристики описанных процессов
Действие |
Среднее количество за рабочий день |
Время, необходимое для выполнения одного действия, минут |
Общее время, минут |
Регистрация поставки |
10 |
15 |
150 |
Поиск необходимой информации |
5 |
30 |
150 |
Анализ информации за период |
0,5 |
60 |
30 |
ИТОГО, минут |
330 |
Таким образом, ежедневно, в среднем, 330 минут или 5 часов 30 минут, сотрудники отдела по работе с клиентами заняты занесением необходимых сведений в книги учета, а также при необходимости – анализом и поиском нужных сведений. Учитывая, что продолжительность рабочего дня составляет 8 часов, делаем вывод, что на выполнение остальных обязанностей (то есть непосредственную работу по решению проблем и выработке необходимых мероприятий) остается менее 40% рабочего времени, что крайне неэффективно.
Для данного способа также характерны следующие недостатки:
- низкая скорость и точность выполнения расчетов;
- неэффективное использование рабочего времени;
- слабый контроль работы сотрудника;
- увеличивающийся «поток» бумажной работы;
- усталость служащих - усиление негативного воздействия человеческого фактора.
В результате проводимой автоматизации предполагается постоянно иметь точнейшие сведения о количестве и сумме продаж, сократить время на подготовку аналитических отчетов и передачу документов за счет их электронной формы.
Очевидно, что для автоматизации необходимо использовать такие средства, как персональные компьютеры, принтеры, а также специальное программное обеспечение и локальную вычислительную сеть.
Проведем расчет ожидаемого эффекта от внедрения средств автоматизации. В случае использования вычислительной техники данный процесс сводится к просмотру заявки, оформленной на внутреннем сайте компании и уже занесенной в базу данных по мере их поступления, поиск информации будет производиться при задании необходимых параметров.
В таблице 8 рассчитан ожидаемый эффект от внедрения информационной системы.
Таблица 8
Ожидаемый эффект от внедрения информационной системы
Действие |
Среднее количество за рабочий день |
Время, необходимое для выполнения одного действия, минут |
Общее время, минут |
Регистрация поставки |
10 |
1 |
10 |
Поиск необходимой информации |
5 |
2 |
10 |
Анализ информации за период |
0,5 |
5 |
2,5 |
ИТОГО, минут |
1,5 |
Таким образом, ожидаемая экономия рабочего времени составляет около 5 часов ежедневно, что позволяет увеличить эффективность работы сотрудников отдела продаж.
1.2. Обовновьние проектных решений
1.2.1. Обовновьние проектных решений по информационному обеспечению
Система должна предоставлять возможность автоматизации учета торговых операций на предприятии, имеющем сеть торговых точек по продаже обуви.
Полученная информация накапливается в базе данных и обрабатывается системой с последующей возможностью оперативного доступа для контроля текущей ситуации, просмотра отчетов, анализа диаграмм, внесения корректировок и обновления информационной базы, изменения условно-постоянной информации в справочниках, анализа обобщенной информации за период времени по каждому магазину или в целом.
Входная информация, содержащая данные оперативного учета, включает данные о поступлении в торговые магазины новых партий обуви, регистрируется приходными накладными и вносится в базу данных через интерфейсную форму ввода (обеспечивается отмена произведенных операций с возвратом исходных значений).
Условно-постоянная информация включает справочные данные о номенклатуре моделей товаров, её характеристиках (цвет, размер, тип, материал). Номинальные расценки на товар хранятся в справочниках. Сведения о поставщиках, клиентах, магазинах хранится в отдельных справочниках и корректируется по мере необходимости.
Продажи товаров регистрируются в системе с контролем складского запаса и возможностью отмены транзакции, при операции выписывается отчет в виде товарного чека. Должна существовать возможность регистрации факта продажи и поступления товаров по измененной цене отличной от номинальной цены в справочнике.
Складской учет ведется по нескольким магазинам, а информация содержится в единой базе данных на сервере, соединение с клиентскими приложениями обеспечивается посредством архитектуры «клиент-сервер».
Клиентская часть системы должна быть многооконной и изменяемой под задачи отдельных операций, обеспечивать функции поиска, быстрой навигации и эргономичности управления. Доступ к модулям системы обеспечивается через главное кнопочное меню. Проектируемая система должна предоставлять удобный и интуитивно понятный пользовательский интерфейс.
Анализ накапливаемой количественно-суммовой информации в базе данных проводится в модуле аналитики с последующим выводом выходных данных в виде графических диаграмм. Параметры обрабатываемой информации должны корректироваться в зависимости от устанавливаемого пользователем интервала времени и конкретного магазина или итоговая информация за весь период по всему предприятию.
Система должна иметь возможность последующей реорганизации и расширения для улучшения её возможностей или добавления функций. Должен обеспечиваться контроль ввода данных при отсутствии избыточности, а также надежное хранение и целостность базы данных.
Таблица 9
Описание сущностей
Информационный объект |
Название атрибута |
Имя атрибута |
Поставщик (Supplier) |
Код _Поставщика Наим_Поставщика Телефон_Поставщика Адрес_Поставщика Счет_Поставщика |
Id_Supplier Supplier_Name Supplier_Phone Suplier_Adress Supplier_Account |
Поставка (Supply) |
Код_ Поставки Код_Поставщика Код _Магазина Дата_Поставки Состояние_Поставки |
Id_Suply Id_Supplier Id_Shop Supply_Date Supply_State |
Состав_Поставки (Delivery) |
Код_ Поставки Код _Товара Цена_Поставки Колво_Поставки |
Id_Supply Id_Product Delivery_Price Delivery_Quantity |
Товар (Product) |
Код _Товара |
Id_Product |
Код_Размера |
Id_Size |
|
Код_Цвета |
Id_Color |
|
Код__ Материала |
Id_Material |
|
Код_Типа |
Id_Type |
|
Артикул_Товара |
Product_Code |
|
Модель_Товара |
Product_Model |
|
Закупочная_Цена |
Product_InPrice |
|
Отпускная_Цена |
Product_OutPrice |
|
Описание_Товара |
Product_Description |
|
Покупатель (Client) |
Код_ Покупателя |
Id_Client |
Имя_Клиента |
Client_Name |
|
Номер_Карты |
Client_Card |
|
Тел_Клиента |
Client_Phone |
|
Продажа (Purchase) |
Код _Продажи |
Id_Purchase |
Код_Покупателя |
Id_Client |
|
Код_Магазина |
Id_Shop |
|
Дата_Продажи |
Purchase_Date |
|
Состояние_Продажи |
Purchase_State |
|
Состав_Продажи (Buying) |
Код_ Продажи |
Id_Purchase |
Код _Товара |
Id_Product |
|
Цена_Продажи |
Buying_Price |
|
Колво_Продажи |
Buying_Quantity |
|
Цена (Price) |
Код _Цены |
Id_Price |
Наим_Цены |
Price_Name |
|
Прим_Цены |
Price_Note |
1.2.2. Обовновьние проектных решений по программному обеспечению
MS Access в нынешнее время служит одной из самых популярных среди настольных программных систем управления базами данных.
Среди причин такой популярности следует отметить:
- Высокую степень универсальности и продуманности интерфейса, который рассчитан на работу с пользователями самой различной квалификации. В частности, реализована система управления объектами базы данных, позволяющая гибко и оперативно переходить из режима конструирования в режим их прямой эксплуатации.
- Глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE.
- Богатый набор визуальных средств разработки.
Нельзя не отметить, что существенной причиной такого широкого распространенная Ms Access служит интеграция в офисный пакет ПО и мощная рекламная поддержка, осуществляемая фирмой Microsoft.
Характерной особенностью СУБД Access служит то, что вся информация, относящаяся к одной базе данных, располагается в одном файле. Такой файл имеет вид *.accdb. Такое решение, как норма, удобно для пользователей любителей, потому что обеспечивает простоту при переносе данных с одного рабочего места на другое.
Внутренняя организация данных в рамках accdb -формата менялась от версии к версии, но фирма Microsoft поддерживала их совместимость снизу вверх, то есть базы данных из файлов в формате ранних версий Access могут быть конвертированы в формат, используемый в версиях более поздних.
Для более полной функциональности и правильной работы данного приложения нужно использовать пакет MS Office версии 2010.
Потом выбераем язык программирования. В нынешнее время лидерами на рынке сред разработки являются Microsoft Visual Studio, Delphi, C++ Builder, JBuilder. Любая из перечисленных сред позволит разработать современное клиент-серверное приложение с современным пользовательским интерфейсом. Однако, в компании имеются наработки на Delphi, которые можно использовать при разработке ИС склада. Выбор среды разработки Delphi позволит гораздо быстрее по сравнению с остальными из перечисленных сред разработки получить готовую систему, с интерфейсом, аналогичным ИС отделов снабжения и сбыта.
Delphi - среда для разработчиков программного обеспечения и приложений баз данных, заинтересованных в быстром создании высокоэффективных и простых в обслуживании приложений. Разработчики могут использовать мощную интегрированную среду разработки Delphi с рабочим полем визуального проектирования, обширной коллекцией визуальных компонентов и мощной инфраструктурой гетерогенных баз данных для визуальной разработки и поставки приложений в максимально сжатые сроки.
Мощный язык Delphi и компилятор обеспечивают высокую производительность и доступ ко всем возможностям, повышающим эффективность и скорость разработки на платформе Windows. Delphi предоставляет также обширный набор инструментов редактирования, рефакторинга и отладки в рамках комплексного решения, ориентированного на ускорение и упрощение разработки.
2. Проектная часть
2.1. Информационное обеспечение задачи
2.1.1. Информационная модель и её описание
Информационная модель представляет собой схему движения входных, промежуточных и результативных потоков и функций предметной области. Кроме того, она объясняет, на основе каких входных документов и какой нормативно-справочной информации происходит выполнение функций по обработке данных и формирование конкретных выходных документов.
В качестве информационной модели будем использовать схему данных (ГОСТ 19.701-90). Схемы данных отображают путь данных при решении задач и определяют этапы обработки, а также различные применяемые носители данных. Схема данных состоит из следующих элементов:
- символов данных (символы данных могут также указывать вид носителя данных);
- символов процесса, который следует выполнить над данными (символы процесса могут также указывать функции, выполняемые вычислительной машиной);
- символов линий, указывающих потоки данных между процессами и (или) носителями данных;
- специальных символов, используемых для облегчения написания и чтения схемы.[1]
Весь цикл обработки информации можно разбить на два этапа:
- Прием, обработка и ввод первичной входящей информации (паспортные данные, реквизиты организаций и т.д.).
- Формирование документов (договора на продажу и т.д.).
Информационная модель представлена на рис. 10.
Рис.10. Информационная модель системы контроля поставок
2.1.2. Характеристика нормативно-справочной, входной и оперативной информации
В качестве входных документов при автоматизированной учете продаж используются следующие документы:
- Прайс-лист;
- Перечень клиентов;
- Перечень поставщиков;
- Перечень продавцов.
Реквизитный состав данных документов, а также их объем, частота и источник поступления приведены в таблице 10.
Таблица 10
Описание входных документов
Наименование |
Реквизиты |
Объем, строк |
Частота поступления |
Источник |
Прайс-лист |
|
600 |
1 раз в неделю |
Отдел продаж |
Перечень клиентов |
|
20 |
ежедневно |
Отдел продаж |
Перечень поставщиков |
|
20 |
ежедневно |
Бухгалтерия |
Перечень продавцов |
|
Отдел кадров |
В системе используются справочники, приведенные в таблице 11.
Таблица 11
Перечень используемых справочников
№ пп |
Название справочника |
Ответственный за ведение |
Средний объём справочника в записях |
Средняя частота актуализации |
Средний объем актуализации, % |
Товары |
Администратор |
100 |
1 раз в месяц |
10 |
|
Клиенты |
Менеджер |
50 |
1 раз в неделю |
10 |
|
Поставщики |
Администратор |
20 |
1 раз в неделю |
25 |
|
Группы товаров |
Администратор |
5 |
1 раз в год |
10 |
|
Единицы измерения |
Администратор |
5 |
1 раз в год |
10 |
|
Продажи |
Администратор |
1000 |
1 раз в месяц |
10 |
|
Сотрудники |
Администратор |
40 |
1 раз в месяц |
10 |
2.1.3. Характеристика результатной информации
Результатной информацией для ведения отчета о выполненных заказах, служит:
Характеристика результатной информации приведена в таблице 12.
Таблица 12
Результатная информация
Наименование информации |
Потребитель информации |
Периодичность передачи информации |
Способ передачи |
Реестр заказов |
Руководство |
Ежемесячно |
На бумажном носителе информации |
2.2. Программное обеспечение задачи
2.2.1. Общие положения (дерево функций и сценарий диалога)
При разработке ИС, решающей задачи автоматизации документооборота, важным этапом служит описание иерархии функций управления и обработки данных разрабатываемого программного продукта
Дерево функций представляет собой иерархическую структуру действий, реализованных в ИС. Все действия (функции) программного продукта можно разделить на два основных подмножества:
1) служебные функции – идентичны для всех автоматизированных систем управления предприятием на современном уровне развития аппаратных и программных средств. Функции этого вида призваны обеспечить безопасность ввода, обработки и хранения информации, облегчить работу с системой, сделать ее наиболее удобной и незатруднительной для конечного пользователя.
2) основные функции управления и обработки данных – свойственны как информационным системам любой специализации, так и именно данной ИС. Они отражают особенности процесса обработки информации, получения результатов, ведения информационной базы проекта. Эти функции организованы в том порядке и в том составе, которые продиктованы условиями обработки и управления данными в конкретной предметной области.
Состав и классификация функций разрабатываемого программного продукта представлены в виде дерева функций (рис.11).
Рис.11. Дерево функций ИС
На данном этапе разработки проекта ИС необходимо также выбрать язык общения системы с конечным пользователем.
Диалог – это процесс обмена сообщениями между пользователем и ИС, при котором осуществляется постоянная смена ролей информатора и реципиента (пользователя, принимающего информацию), причем смена ролей достаточно оперативна.
В процессе диалога возможно:
- двустороннее управление на базе языка типа «запрос-ответ»,
- одностороннее управление со стороны ИС с языком общения типа «меню», «заполнения шаблона», ответа по «подсказке»,
- одностороннее управление со стороны пользователя с использованием языка директив (команд).
При использовании для общения языка «меню» в диалоговой системе должна присутствовать система планирования и управления диалогом, в функции которой входит:
- управление процессом диалога,
- обеспечение интерфейса пользователя,
- обеспечение выполнения сервисных или справочных функций,
- анализ и обработка ошибочных ситуаций,
- вызов обрабатывающих программ.
При разработке данного проекта система общения с пользователем организована таким образом, что основная часть диалога ведется на языке типа «меню», а заполнение форм входных документов – по «шаблону». Таким образом, происходит одностороннее управление процессом обработки данных со стороны ИС.
Структура сценария диалога в совокупности с деревом функций, которое отражает состав и иерархию функций системы, дает возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность.
Сценарий диалога предусматривает возможность обеспечения следующих функций управления ходом решения поставленных задач:
- возможность работы с экранными формами входных документов,
- формирование выходных документов,
- корректировка вводимых данных,
- просмотр введенной информации,
- работа с таблицами нормативно-справочной информации,
- протоколирование действий пользователя,
- помощь на всех этапах работы.
Сценарий диалога состоит из двух логически связанных частей:
1) Основные меню, относящиеся к головному, то есть те экраны меню, которые видит пользователь, прежде чем приступить к выполнению основных функций, согласно дереву функций. Основные меню предполагают обязательные действия пользователя при работе с ИС.
2) Сервисные меню, которые становятся доступны конечному пользователю после того, как выдана на экран соответствующая форма документа. Сервисные меню предполагают возможные действия, одно из которых может являться необязательным к выполнению.
Сценарий диалога изображен на рисунке 12.
Основное меню
Операции
Выход
Справка
Сервис
Отчеты
Справочники
Файл
О прогр
Экр. фор.
Настр.
Новый
Парамет
Вывод на экран
Открыть
Сохран.
Работа с НСИ
Печать
Вывод на печать
Выход
Рис. 12 Сценарий диалога
2.2.2. Характеристика базы данных
База данных состоит из 7 таблиц: товары, группы, сотрудники, клиенты, продажи, поставщики, единицы измерения.
Описание таблиц реляционной базы данных дано в таблицах 13-19.
Таблица 13
Характеристика таблицы «Товары»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Код товара |
Id_tovara |
Integer |
5 |
Идентификатор товара |
Наименование |
Name_tov |
Char |
15 |
Наименование товара |
Модель |
Model |
Char |
15 |
Модель |
цвет |
Color |
Char |
15 |
Цвет |
Стоимость |
Cena |
Integer |
5 |
Стоимость товара |
Таблица 14
Характеристика таблицы «Сотрудники»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Код сотрудника |
Id_sotr |
Integer |
3 |
Первичный ключ |
Фамилия |
Fam_sotr |
char |
20 |
Фамилия сотрудника |
Имя сотрудника |
Name_sotr |
Char |
15 |
Имя сотрудника |
Отчеcтво |
Otch_sotr |
Char |
20 |
Отчество сотрудника |
Таблица 15
Характеристика таблицы «Группы»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Код группы |
Id_gr |
Integer |
2 |
Первичный ключ |
Наименование группы |
Group |
Char |
15 |
Наименование группы |
Таблица 16
Характеристика таблицы «Клиенты»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Код клиента |
Id_kl |
integer |
3 |
Первичный ключ |
ФИО |
FIO |
char |
255 |
Фамилия Имя Отчество |
Таблица 17
Характеристика таблицы «Продажи»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Номер записи о продаже |
N_record |
Integer |
5 |
Первичный ключ |
Дата |
Date_prod |
date |
12 |
Дата продажи |
Код товара |
Id_tovara |
Integer |
5 |
Идентификатор товара |
Код сотрудника |
Id_sotr |
Integer |
3 |
|
Код клиента |
Id_kl |
Integer |
5 |
|
Количество |
Kol |
Integer |
3 |
Количество товара |
Сумма |
Sum |
Integer |
5 |
Сумма продажи |
Таблица 18
Характеристика таблицы «Поставщики»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Код поставщика |
Id_post |
integer |
3 |
Первичный ключ |
Наименование поставщика |
FIO |
char |
255 |
Наименование фирмы-поставщика |
Таблица 19
Характеристика таблицы «Единицы измерения»
Наименование поля |
Идентификатор поля |
Тип данных |
Длина поля |
Описание поля |
Код единицы измерения |
Id_ed |
Integer |
2 |
Первичный ключ |
Наименование единицы измерения |
Ed_izm |
Char |
15 |
Наименование единицы измерения |
Для иллюстрации связей всех сущностей, была разработана ER-модель, приведенная на рисунке 13.
Группы
Код группы
Наименование группы
Сотрудники
Код сотрудника
Фамилия
Имя сотрудника
Отчество
Товары
Код товара
Наименование
Модель
Цвет
Стоимость
Клиенты
Код клиента
ФИО
Продажи
Номер записи о продаже
Дата
Код товара
Код сотрудника
Код клиента
Количество
Сумма
Поставщики
Код поставщика
Наименование поставщика
Единицы измерения
Код единицы измерения
Наименование единицы измерения
Рис. 13 ER-модель
2.2.3. Структурная схема пакета (дерево вызова программных модулей)
Схема программных модулей содержит программные модули различных классов:
- выполняющие служебные функции;
- управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю;
- модули, связанные с вводом, хранением, обработкой и выдачей информации.
Схема взаимосвязи программных модулей представлена на рисунке 12.
Рис. 12. Схема взаимосвязи программных модулей ИС
2.2.4. Описание программных модулей
Таблица 14 содержит краткие сведения о программных модулях.
Таблица 14
Характеристики программных модулей задачи
Идентифи-катор модуля |
Наименование модуля |
Выполняемые функции |
Begin Module |
Управляющая программа |
Инициирует вызов и активизацию основных программных модулей системы, содержит меню ИС. |
Security Module |
Модуль проверки пароля и прав доступа |
Модуль, предназначенный для контроля прав доступа и правильности пароля в системе |
Form Mod |
Модуль ввода данных |
Модуль, предназначенный для ввода данных по документам. |
Контроль правильности вводимых данных, проверка соответствия вводимой даты, кодов и прочей строчной и числовой информации. В случае обнаружения ошибок на экран выдаются корректные предупреждения, и предлагается исправить ошибку |
||
Корректировка введенных данных первичных документов, пока они еще не сохранены в соответствующих файлах. |
||
Execute Module |
Модуль обработки |
Модуль обработки информации |
Help Module |
Модуль ведения справочников |
Модуль, предназначенный для актуализации (корректировки, добавления, удаления) сведений справочников. |
Result Module |
Модуль результатов |
Модуль, предназначенный для окончательных расчетов, необходимых для составления результатных документов. |
Module |
Модуль вывода на печать |
Модуль, предназначенный для вывода на печать форм первичных, промежуточных и результатных документов, сгенерированных в тех модулях, которые реализуют соответствующие пункты меню |
Также подробнее рассмотрим один из примеров блок-схемы алгоритма, а именно – процесс авторизации пользователя в системе
Рис. 14 Блок-схемы алгоритма «Авторизация»
2.3. Контрольный пример реализации проекта и его описание
Программа имеет удобный интерфейс, не требующий специального обучения. Главное окно представлено на рис.15. На нем представлено меню программы.
Рис.15. Главное окно
Редактирование всех справочников осуществляется через пользовательский интерфейс (рис.16-18).
Рис.16. Справочник «Товары»
Рис.17. Справочник «Группы товара»
Рис.18. Справочник «Товар на складе»
Заключение
По результатам выше проделанной работы можно сделать следующие выводы.
Для достижения главной цели были выполнены поставленные задачи. В итоге получилось приложение автоматизации обработки информации. Оно позволяет просматривать информацию, хранящуюся в базе данных, также предусмотрена возможность добавления, редактирования и удаления записей, а также реализация выходных документов с помощью отчетов
Разработанная база данных, позволяет снизить затраты времени и существенно облегчает формирование результатных документов.
Программное средство имеет удобный стандартизированный пользовательский интерфейс и высокую скорость обработки информации.
Разработанный программный продукт прост в освоении и рассчитан не только на профессионалов, но и на рядовых пользователей, работающих под операционную систему Windows. Удобный интуитивно понятный интерфейс в сочетании с системой всплывающих подсказок позволяет работать с программой без предварительной подготовки.
В отличие от дорогих и сложных программ, программа автоматизации учета продаж обоснованно хорошо годится для ниши малого и среднего бизнеса, так как размещает в себе все, что им необходимо, но не перегружена избыточными возможностями. Использование технологии создания программы в наглядных средах программирования делает ее интерфейс многофункциональным и синхронизированным с операционными системами Windows XP/7/Vista. Равно как служит одним из преимуществ программы, так как она не требует объемного свободного дискового пространства, потому что комплект поставки занимает места всего 1,9 Mb памяти.
Список использованной литературы
- РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.
- ГОСТ34.601-90. Автоматизированные системы. Стадии создания.
- ГОСТ34.602-89. Информационная технология.
- ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
- РД IDEF0 2000. Методология функционального моделирования.
- Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008.
- Введение в системы баз данных – СПб: Издательский дом "Вильямс", 2000. - 848 с.;
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: «Финансы и статистика», 2000
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем – М.: ИНТУИТ.ру, 2005
- Данелян Т.Я. Организация и функционирование больших информационных систем. -М.: МЭСИ, 2007
- Ивлиев М.К., Порошина Л.А. Автоматизация оперативного и бухгалтерского учета товаров, 1997.
- Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
- Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2005 г - 656 стр.
- Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
- Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2005 – 400с.
- Система защиты коммерческой тайны малого коммерческого предприятия
- Программные и аппаратные средства ограничения доступа к ресурсам ПК и сетей
- Стратегия управления персоналом (Формирование кадровой политики в современной организации)
- Стратегии разработки новых товаров (Теоретические основы определения нового товара)
- Построение организационных структур
- Построение организационных структур
- Шрифт в рекламе. Фирменный стиль и рекламное объявление
- НАВИГАЦИЯ ТУРИСТИЧЕСКОГО САЙТА
- Формирование кадровой политики в современной организации
- Методы кодирования данных (Виды кодирование данных)
- Разработка регламента выполнения процесса «Складской учет
- «Защита внутренней сети и сотрудников компании от атак»