База данных торговой организации
Обзор существующих автоматизированных систем учета для торговой организации. Разработка проекта базы данных, новая технология учета. Реализация базы данных в торговой организации. Выбор средств разработки клиентской части. Описание программных модулей.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 31.12.2017 |
| Размер файла | 3,8 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
БАЗА ДАННЫХ ТОРГОВОЙ ОРГАНИЗАЦИИ
ОГЛАВЛЕНИЕ
база данные торговый автоматизированный
ВВЕДЕНИЕ
ГЛАВА 1. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В ТОРГОВЛЕ
Особенности торгового предприятия
Существующая технология учета в торговой организации
Обзор существующих автоматизированных систем учета для торговой организации
Система 1С: Торговля и склад
Программы складского учета ФОЛИО WinСклад. Проф
Комплекс «Галактика»
ГЛАВА 2. ХАРАКТЕРИСТИКА ТОРГОВОЙ ОРГАНИЗАЦИИ ООО «МАРТА»
Описание торговой организации ООО «Марта»
Описание основных информационных потоков
Постановка задачи на разработку базы данных торговой организации ООО «Марта»
ГЛАВА 3. РАЗРАБОТКА ПРОЕКТА БАЗЫ ДАННЫХ ТОРГОВОЙ ОРГАНИЗАЦИИ ООО «МАРТА»
Новая технология учета в торговой организации ООО «Марта»
Информационное обеспечение
Описание реализации БД ИС
ГЛАВА 4. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ ТОРГОВОЙ ОРГАНИЗАЦИИ ООО «МАРТА»
Обоснование выбора средств разработки ИС
Обоснование выбора средств разработки клиентской части ИС
Обоснование выбора СУБД
Дерево функций и сценарий диалога
Описание программных модулей
Инструкция пользователя
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
ПРИЛОЖЕНИЕ. ТЕКСТ МОДУЛЕЙ КЛИЕНТСКОГО ПРИЛОЖЕНИЯ
ВВЕДЕНИЕ
На данном этапе развития человеческого общества наиболее ярко выражен переход к всеобщей информатизации, внедрению компьютерных и информационных систем во все сферы и области деятельности человека. В связи с этим решение проблем использования современных, перспективных методов и средств обработки информации в практической деятельности приобретает первостепенное значение.
Использование баз данных и информационных систем становится неотъемлемой составляющей деловой деятельности современного человека и функционирования преуспевающих организаций. В свою очередь большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных, CASE- средств автоматизации проектирования и других.
Объектом исследования является ООО «Марта», специализирующееся на реализации продуктов питания.
Предметом исследования является деятельность менеджера по продажам торговой организации ООО «Марта».
Цель проекта - разработка база данных торговой организации ООО «Марта».
Для достижения поставленной цели решены следующие задачи:
– Анализ деятельности ООО «Марта»;
– Анализ задач, решаемых начальником оптово-распределительного склада;
– Изучение возможностей существующих систем автоматизации продаж;
– Разработка информационной, математической и технической обеспечивающих подсистем;
– Реализация базы данных.
Работа состоит из 4 разделов, введения и заключения, списка литературы, приложений.
В первом разделе выполнен аналитический обзор роли информационных технологий в торговле, а также представлены основные понятия БД и СУБД.
Описана типовая схема документооборота в торговых предприятиях и существующая технология обработки данных в торговой организации ООО
«Марта». В результате приведенного описания делается вывод о целесообразности усовершенствования технологии обработки данных, при этом в первую очередь делается обзор существующих автоматизированных систем учета в торговых организациях
Во втором разделе приводится характеристика торговой организации ООО
«Марта», описывается экономическая область функционирования объекта исследования, выполняется описание основных информационных потоков, на основании которых ставится задача на разработку базы данных торговой организации
Третий раздел посвящен вопросу разработки проекта базы данных торговой организации. Разработана логическая и физическая модели системы, описаны макеты всех входных и выходных документов. Представлена математическая модель задачи
В четвертом разделе производится обоснование выбора среды разработки и СУБД, на основание которой будет построена АРМ. Описаны все основные элементы пользовательского интерфейса системы, а также реализация БД. Представлена подробная инструкция пользователя.
ГЛАВА 1. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В ТОРГОВЛЕ
Особенности торгового предприятия
Торговля - один из наиболее интенсивно развивающихся секторов приложения информационных технологий. Однако в силу различных причин автоматизация здесь происходит относительно медленно: торговля более консервативна в восприятии информационных технологий, чем большинство других сфер экономики; стартовые условия автоматизации в торговле были менее благоприятны; объективные потребности в автоматизации формировались постепенно.
Особенности автоматизации в торговле обусловлены, структурными особенностями торговых предприятий.
Организационно торговое предприятие состоит из следующих основных групп подразделений:
– административных подразделений (менеджеров, кадровой и юридической служб, маркетинга);
– торговых отделов;
– центрального склада (складов);
– бухгалтерии;
– технических служб.
Основные структурные подразделения торгового предприятия - отделы и склады - имеют достаточно однородную структуру:
– отдел состоит из секций;
– отдел возглавляет заведующий, в функции которого входят вопросы расстановки кадров, формирования рабочих графиков, текущей коммерческой политики, взаимосвязи с поставщиками и др.;
– основной задачей отдела является формирование ассортимента, обеспечивающего выполнение товарного плана (плана прибыли);
– товаровед отдела непосредственно подготавливает и реализует контакты с поставщиками, анализирует информационные и рекламные материалы на выпускаемую или готовящуюся к выпуску продукцию по направлению отдела, ведет оформление договоров, анализирует предложения частных лиц о продаже товаров по договорным ценам;
– секции отделов являются автономными в отношении материальной ответственности; они обеспечивают прием, реализацию товаров, учет товаров и денежных средств от реализации, кассовых операций, рекламу изделий в отделах; периодически подготавливают товарные отчеты для бухгалтерии;
– отделы могут реализовывать товар по системе мелкого опта;
– возможен отпуск товара непосредственно с центрального склада при отправке товара по бартеру или в порядке передачи в другие магазины;
– реализация товаров по договорным ценам осуществляется практически всеми отделами по закрепленной продукции.
В стране отмечается возрастающий интерес к распространению информации о товарах через информационные каналы, в т.ч. через Интернет, использование интерактивных банковских услуг для оплаты товаров.
Административные подразделения ориентированы на управление фирмой, реализацию кадровой политики, выработку стратегии и корректировку задач тактического управления. Бухгалтерия выполняет традиционные функции учета: по подразделениям, товарам, поставщикам, группам клиентов, а также по регионам (если фирма работает на региональных рынках). Технические подразделения ориентированы на поддержку бизнеса.
Основными внешними связями торгового предприятия являются связи с поставщиками, покупателями и смежниками. Кроме того, в деятельности предприятия могут возникать и разовые связи.
Взаимосвязи с юридическими лицами регламентируются договорами и счетами на оплату товаров. Оплата товаров частными лицами осуществляется через кассовые операции или оплату через почтовые отправления.
Существующая технология учета в торговой организации
Для проведения анализа существующей технологии выполнения выбранной функции управления удобно использовать CASE - средство верхнего уровня All Fusion Process Modeler (BPwin), поддерживающее методологии IDEF0 (функциональная модель), DFD (Dataflow Diagram) и IDEF3 (Workflow Diagram). BPwin является мощным программным продуктом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство, для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели.
С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой. Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO- BE). Методология IDEF0 предписывает построение иерархической системы диаграмм, т.е. единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействие с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая система описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее для достижения нужной степени подробности.
Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию DFD или IDEF3. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
Для рассмотрения бизнес - процессов выполняющихся в торговой организации, необходимо использовать только две методологии IDEF0 и DFD. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы или бизнес- процессов в целом.
Для изучения бизнес-процессов «Формирование заказа поставщика», «Получение товара», «Отпуск товара», рассмотрим диаграммы, которые представлены в виде IDEF0 диаграмме. IDEF0 система представляется как совокупность взаимодействующих работ или функций.
Рассмотрим диаграммы деятельности системы учета в торговой организации
Для общей видимости системы необходимо построить контекст «Деятельность торговой организации».
Рис.1.1
Входными данными контексной диаграммы являются:
- Заявка на товар - фактически представляет собой список запрашиваемых товаров, а также необходимое количество;
– Накладная на поставку от поставщика - фактически преставляет собой список поступивших на склад организации товаров, их количество, а также цен;
– Перечень, имеющегося в наличии товара - список товара, имеющегося в наличии, а также его количества и цен, по которым реализуется.
Результатом работы являются следующие отчеты:
– Отчет «Товар, имеющийся в наличии на складе» - важно отметить, что информация о имеющихся в наличии товаре на складе подается и на вход, однако после выполнения ряда операций (продажа, поставки, поступление товара) номенклатура и количество товара значительно изменяются;
– Отчет «Поступление товара» содержит информацию о поставках товаров;
– Отчет «Продажи и отгрузка товаров» содержит информацию о реализованном товаре, а также о перераспределении товаров между торговыми точками;
– Отчет «Прайс-лист» содержит детальную информацию о ценах. Следует отметить, что один и тот же товар, полученный в разных поставках может иметь отличающиеся цены, что объясняется отличающимися ценами поставки.
Управляющими механизмами в данной системе являются:
– Должностные инструкции сотрудников торговый организации;
– Правила оформления документов. Здесь понимается, что документы оформляются вручную посредством MS Word и MS Excel, однако каждый документ должен иметь специфическую структуру и содержать определенную информацию.
Далее строится декомпозиция контексной диаграммы.
Каждая последующая диаграмма является более подробным описанием одной из работ на вышестоящей диаграмме. Далее каждый из блоков декомпозиции системы будет еще разбиваться, «Оформление прихода товара на склад» - Рисунок 1.4, «Оформление отпуска товара со склада» - Рисунок 1.5.
Рисунок 1.2 - Диаграмма декомпозиции процесса «Автоматизированная система учета торговой организации» первого уровня
Рисунок 1.3 - Декомпозиция процесса «Учет имеющегося товара»
Рисунок 1.4 - Декомпозиция процесса «Оформление прихода товара на склад»
Рисунок 1.5- Декомпозиция процесса «Оформление отпуска товара со склада»
Как видно из диаграмм, представленных на Рисунках 1.3-1.7 все процессы учета и анализа товаров торговой организации выполняются практически вручную сотрудниками. Это значительно замедляет процесс и приводит к возникновению возможных ошибок. Рассмотрим наиболее типичные проблемы, характерные для каждой отдельной задачи.
Задача «Учет имеющегося товара». На текущий момент эта задача решается средствами MS Excel и при каждой операции поступления или отгрузки товаров, информацию о наличии какого-либо товара приходится править вручную. Это весьма трудоемкий процесс, чреватый большим количеством ошибок. Кроме того, сложной становится задача отследить динамику изменения наличия того или иного товара.
Задача «Учет поступлений товара». На данный момент при поступлении товара сотрудники склада вручную корректируют информацию об имеющемся в наличии товаре, увеличивая количество имеющихся позиций на количество позиций, представленных в накладной на поставку. Такой способ решения задачи зачастую приводит к возникновению ошибок и увеличивает время, затрачиваемое на решение задачи, кроме того отдельные сложности возникают при изменении цены поставки на уже имеющийся в наличии товар.
Задача «Учет продаж и отгрузок товара с центрального склада» также решается на данный момент практически вручную при помощи таблиц. По причине возможных ошибок, возникающих при вводе исходных данных зачастую возникает ситуация, когда по спискам товар имеется, а фактически в наличии его нет, либо наоборот по спискам товара нет, а на самом деле он имеется. И то и другое негативно сказывается на прибыли компании. Кроме того, по причине информации о продажах и отгрузках товара возможно возникновение новых ошибок, а по причине неструктурированности информации практически невозможно провести анализ спроса на товары и динамики продаж, что в свою очередь позволило бы грамотно скорректировать ассортимент.
На данный момент практически все операции связанные с учетом товаров выполняются практически вручную. Фактически используется MS Excel, который не обладает должными средствами автоматизации. Так возникают проблемы при проведении следующих операций:
– Поступление товара на склад. Периодически в списке возникают дублирующие друг друга позиции. Это является следствием отсутствия возможности удобного отслеживания списка товаров;
– Отгрузка товаров со склада. Периодически возникает проблема «ложного недостатка товаров». Эта проблема является следствием того, что товары одинакового наименования могут быть внесены в несколько позиций списка и вовремя не обнаружены.
– Формирование печатных отчетов. Отчеты формируются практичеси вручную. Этот процесс является долгим и рутинным и периодически приводит к возникновению ошибок.
– Большое количество «ручного» труда ведет к временным задержкам оформления заказов, ошибках при заполнении документов и произведении расчетов. Так же необходимо отметить, что при такой организации деятельности серьезно затруднен обмен информацией между подразделениями.
Все базовые бизнес-процессы торговой организации, как правило, включают множество этапов тщательно отрабатываемых различными подразделениями компании, поэтому единовременно данный процесс не может быть изменен. По этой причине предприятия с осторожностью относятся к внедрению готовых информационных систем. Как правило, российские предприятия используют собственные наработки в этой области.
Обзор существующих автоматизированных систем учета для торговой организации
На рынке предложено довольно большое количество решений от разных фирм: 1С: Торговля и склад, Программы складского учета ФОЛИО WinСклад. Проф., Галактика.
Система 1С: Торговля и склад.
«1С: Торговля и склад» представляет собой компоненту "Оперативный учет" системы «1С: Предприятие» с типовой конфигурацией для автоматизации складского учета и торговли.
Компонента "Оперативный учет" предназначена для учета наличия и движения материальных и денежных средств. Она может использоваться как автономно, так и совместно с другими компонентами «1С: Предприятия».
«1С: Торговля и склад» предназначена для учета любых видов торговых операций. Благодаря гибкости и настраиваемости, система способна выполнять все функции учета - от ведения справочников и ввода первичных документов до получения различных ведомостей и аналитических отчетов.[1]
Недостатки:
– дороговизна и длительность настройки программы, для решения конкретных задач;
– переход учета с одной системы на другую займет некоторый промежуток времени, в течение которого деятельность предприятия будет затруднена и тем самым предприятие затратит средства, которые можно было избежать;
– неудобство интерфейса: общие кнопки расположены внутри закладок, нет единого стиля (беспорядок в надписях полей, общая загруженность форм лишними компонентами).
Программы складского учета ФОЛИО WinСклад. Проф.
Предназначены для автоматизации учета и анализа движения товаров и денежных средств, формирования различных отчетов, подготовки и печати первичных складских и платежных документов, экспорта данных в бухгалтерские программы ФОЛИО и других производителей, а также в MS Excel. Функциональные возможности выпускаемых модификаций программ (для малых предприятий - версии: 7. 5. E, для средних и крупных - версии: 7.5) полностью идентичны.[9]
Недостатки:
– сопровождение только по телефону и в офисах фирмы;
– стандартная конфигурация не предусматривает аналитики и учета заявок, эти задачи продаются за отдельные деньги.
Комплекс «Галактика»
Представляет собой продукт одноименной фирмы. Содержит много контуров, имеющих модульную структуру.
Процесс решения задач логистики на промышленном предприятии с помощью системы «Галактика» можно обобщенно представить в виде следующей последовательности операций:
– ввод договоров с покупателями готовой продукции с указанием реквизитов сторон;
– формирование планов сбыта по заявкам потребителей.
– формирование договоров с поставщиками на закупку сырья, комплектующих и т.д;
– формирование приходных накладных по ДО на закупку при поступлении МЦ;
- оплата поступивших МЦ предусмотренными условиями договора видами платежных средств;
- по мере производства готовой продукции и наступления сроков отгрузки
- формирование ДО (счетов) на продажу по товарным ПКП договоров с покупателями;
– формирование по ДО на продажу сопроводительных документов на отпуск готовой продукции;
– ввод входящих платежных документов по мере поступления платежей за отгруженную продукцию;
– отражение хозяйственных операций в бухучете путем формирования проводок по первичным документам с помощью механизма ТХО. [3]
Недостатки:
– длительная окупаемость полного программного комплекса;
– сложность настройки системы под малое предприятие;
– очевидная громоздкость для решения данной задачи;
– разработка производилась для автоматизации работы крупных промышленных предприятий.
Для наглядности обобщим недостатки и достоинства каждого программного средства в виде Таблицы 1.1.
Таблица 1.1
Сравнительный анализ программного обеспечения для автоматизации деятельности начальника склада
|
Характеристика |
1С: Торговля и склад |
Программы складского учета ФОЛИО WinСклад |
Комплекс «Галактика» |
|
|
Стоимость |
- |
+ |
- |
|
|
Адаптированность под специфику компании |
± (Процесс настройки длительный и дорогостоящий) |
± (За отдельную плату) |
± (Нуждается в длительной сложной настройке) |
|
|
Отсутствие заведомо лишних функций |
+ |
+ |
- |
|
|
Расширяемость и возможность добавления новых функций |
± (За дополнительную плату) |
- |
± (За дополнительную плату) |
|
|
Удобный интерфейс |
- |
+ |
+ |
|
|
Техподдержка |
+ |
± (Только по телефону) |
+ |
Проведя анализ существующих решений, были выявлены общие недостатки:
– слишком широкий спектр функций для автоматизации локальной задачи;
– неэффективность использования: затраты не соответствуют экономическому эффекту от внедрения;
– сложность обучения персонала.
Ввиду этого принято решение создать новую систему собственными силами, которая бы отвечала следующим требованиям:
– компактное размещение нужных функций;
– простота в обращении;
– легкость в обучении персонала.
Эта система в дальнейшем могла бы быть распространена на малых предприятиях, имеющих схожий принцип работы.
ГЛАВА 2. ХАРАКТЕРИСТИКА ТОРГОВОЙ ОРГАНИЗАЦИИ ООО «МАРТА»
Описание торговой организации ООО «Марта»
ООО «Марта» осуществляет услуги по реализации продуктов питания и отдельных видов бытовой химии. Существует на рынке с ноября 2006 года. Но в отличие от многих фирм-однодневок уже успела полностью покрыть расходы на создание, принести немалую прибыль и, что не менее важно, заработать постоянных клиентов, в числе которых, например, сеть кафе-ресторанов «Мафия».
Организация имеет несколько филиалов, размещенных в разных частях города и центральный оптово-распределительный склад. С центрального оптово- распределительного склада основная часть товаров распространяются на местные склады филиалов, с которых товары реализуются клиентам.
На территории торговой организации ООО «Марта» выделена площадь под склады, где хранятся основные виды товаров, реализуемые заказчикам, поэтому менеджеры могут контролировать наличие товара на центральном складе, отгрузку, погрузку и проводить инвентаризацию в непосредственной близости от офиса. Благодаря этому упрощена схема документооборота.
Продукция поступает непосредственно от поставщиков и реализуется на склады и клиентам, нуждающимся в данном виде товаров. Торговая организация
«Марта» осуществляет транспортировку продукции, ее складирование, хранение и отгрузку.
Номенклатура реализуемых товаров составляет несколько сотен наименований и постоянно увеличивается. В основном это продукты питания.
Торговая организация «Марта» ведет оптовую торговлю преимущественно за безналичный расчет. Удовлетворяя потребности розничных торговцев, предприятие оптовой торговли получает доход от торговой надбавки на продаваемые товары.
Основными целями данной организации являются являются:
– расширение рынков сбыта;
– увеличение прибыли;
– расширение фирмы;
– приобретение новых клиентов.
Во внешней системе торговая организация «Марта» выполняет роль посредника между поставщиками товаров и клиентами на эту продукцию. Наглядно это можно увидеть из рисунка 2.1
Рисунок 2.1- Схема внешней среды фирмы
Внутренняя организационная структура торговой организации «Марта» представляет собой схему изображенную на рисунке 1.2.
Во главе организации стоит генеральный директор, который решает в основном управленческие вопросы, а также вопросы стратегического характера. Он контролирует деятельность всех отделов. Также в его компетенции вопросы движения финансовых потоков.
Закупкой товаров занимается отдел снабжения. В его функции также входит поиск новых поставщиков с более выгодными условиями поставки. Этот отдел решает вопросы закупки по всему ассортименту. Закупка производится на основании заявок покупателей, оформленными менеджерами.
Рисунок 2.2 - Внутренняя структура организации
Организационная структура торговой организации ООО «Марта» относится к функциональному типу. Фактически, во главе каждого отдела стоит его руководитель, который подчиняется непосредственно генеральному директору, и которому подчиняются сотрудники его отдела.
В отдел сбыта входят менеджеры, которые занимаются непосредственно клиентами. Каждый менеджер имеет свою базу клиентов, с которыми он работает. Он заключает договора, обговаривает сроки, условия поставки и оплаты товара; осуществляет прием заказов от покупателей. Увеличивает свою базу клиентов за счет поиска новых.
Отдел бухгалтерии включает в себя три подотдела: это главный бухгалтер, выписка, платежи и касса.
Главный бухгалтер ведет бухгалтерский учет, делает баланс, различные встречные сверки, считает все налоги и решает вопросы, возникающие в отделах, находящихся в его подчинении.
Отдел «Платежи» предполагает отправку и получение платежей из банка через специальную банковскую программу. Это оплата по счетам поставщикам, уплата налогов, каждодневные получения денежных средств на расчетный счет фирмы от клиентов и др. платежи.
Кассир занимается распределением наличных средств организации (выдача заработной платы, выделение средств на хозяйственные нужды, выдача командировочных и т.д.)
В отдел экономической безопасности входят: начальник охраны, который отвечает за безопасность объекта и пропускной системой; системный администратор, обязанностью которого является сохранение информационной безопасности и обеспечение функциональности вычислительного комплекса.
В процессе деятельности торговой организации ООО «Марта» все ее подразделения взаимосвязаны между собой.
Описание основных информационных потоков
Управление товарооборотом в торговой организации ООО «Марта» основывается на информации, отражающей объем, структуру и динамику поступления, перераспределения и запасов товаров. Движение информации между ООО «Марта» и внешней средой (поставщиками, заказчиками) осуществляется в форме потоков информации. По отношению к торговой организации различают входные, внутренние и выходные потоки информации (входную, внутреннюю и выходную информацию). От рациональной организации потоков информации торговой организации, способов сбора, регистрации, передачи, хранения и обработки информации, ее состава и своевременного получения зависят оперативность и эффективность управления торговыми процессами.
Проблема грамотного управления торговыми процессами организации ООО «Марта» имеет значительное влияние на ее экономику. Это объясняется тем фактом, что основным предметом деятельности компании является реализация товаров и от того насколько грамотно это будет выполняться напрямую зависит прибыль компании. Так, например, при ложном определении запрашиваемого товара как отсутствующего на складе, в лучшем случае, уменьшится возможная прибыль за счет того, что товар остался на складе, а в худшем- придется еще и оплачивать неустойки.
Учет реализации товаров в торговле осуществляется по мере отгрузки товаров и предъявления контрагентам расчетных документов.
Реализация товаров ООО «Марта» происходит по схеме, представленной на рисунке 2.3. Для полноты описания представим все информационные потоки, протекающие в процессе реализации товаров, а также процессы, относящие к поставкам товаров на склад ООО «Марта».
Рисунок 2.3 Схема информационных потоков торговой организации ООО «Марта»
Рассмотрим информационные потоки организации ООО «Марта» (Рисунок 2.3). Клиенты делают заявку на склад (сбрасывает по факсу или договаривается по телефону) на нужную им продукцию.
Организация выставляет счет на оплату и отсылает заказчику. При наличии товара на складе резервируется необходимое количество. Если товара нет, то оформляется заявка на поставку, где указывается дата составления заявки, фамилия ответственного сотрудника, наименование продукции и крайние сроки доставки товаров.
Оформленная заявка поступает в отдел снабжения, где все заявки сортируются в зависимости от товара, от сроков поставки и т.д. и определяется примерная дата поступления товара на склад.
Начальник склада, имея эти данные, уточняет сроки доставки товара с клиентом.
Снабженцы выставляют заявки на товар поставщикам, оплачивают выставленные счета и привозят товар, который поступает на склад ООО «Марта».
После того, как вся документация на поставку оформлена, выполнена проплата со стороны клиента либо оформлены документы на отсрочку оплаты товар доставляется либо отгружается заказчику.
Более детально процесс реализации продукции и функциональные задачи автоматизируемого объекта можно проследить из схемы, представленной на рисунке 2.4:
Рисунок 2.4 - Схема информационных потоков процесса реализации продукции со склада торговой организации
При поступлении товаров от поставщиков заводится приходная накладная.
После того, как клиент оплатил счет, выставленный ему менеджером, либо оформил документы на отсрочку оплаты, продукция со склада может быть ему отгружена либо доставлена.
На основании счета выписывается расходная накладная на склад. По этой накладной клиент может получить со склада продукцию, оплаченную им. На складе товар взвешивается или измеряется и в накладной указывается точное количество продукции и заверяется подписью кладовщика. С учетом сделанных пометок выписываются товарная накладная и счет-фактура, на которых потом ставятся подпись и печать.
В случае пересортицы товаров или излишков оформляются внутренние документы - списание или оприходование.
На основании имеющихся данных периодически возникает необходимость формирования ряда отчетов.
Отчет по остаткам на складах. Он может быть сформирован на конкретную дату и по конкретной продукции.
Также можно сформировать отчет по приходным, расходным документам и банковским выпискам за определенный период времени, который показывает общую сумму по этим документам за какой-то период времени.
Эти отчеты на данный момент формируются в основном вручную. Это занимает много времени и часто приводит к ошибкам.
Постановка задачи на разработку базы данных торговой организации ООО «Марта»
Проведя анализ деятельности торговой организации ООО «Марта», был выявлен ряд существенных недостатков, которые негативно влияют на деятельность всей организации в целом. Рассмотрим основные их них и выявим причины их возникновения.
Практически вся деятельность организации осуществляется в, так называемом «ручном режиме» - все документы, необходимые для работы, заполняется вручную, используя программные средства MS Word и MS Excel. Также эти программные продукты используются при последующем анализе деятельности торговой организации.
Большое количество «ручного» труда ведет к временным задержкам оформления заказов, ошибках при заполнении документов и произведении расчетов. Так же необходимо отметить, что при такой организации деятельности серьезно затруднен обмен информацией между подразделениями.
Количество постоянных клиентов, не превышает тридцати. В дальнейшем обобщим их одним термином- контрагент. При том в месяц один контрагент в среднем совершает не более 10 заказов. Малое количество заказов обусловлено спецификой работы с оптовиками, которые совершают крупные разовые закупки, а каждый такой заказ может содержать множество позиций (более 100). При текущем алгоритме работы, описанном в разделе описания бизнес-процессов, сотрудники склада не успевают справляться со своими обязанностями, в течение рабочего дня, и им приходиться оставаться сверхурочно, что так же негативно сказывается как на качестве работы, так и на психоэмоциональном состоянии работников. Идея расширения штата введением еще одной штатной единицы на склад может быть лишь временным решением, т.к. при дальнейшем расширении оборота вновь встанет проблема нехватки рабочей силы. При этом количество ошибок значительно увеличится.
Аналитическая деятельность, используя MS Office, то же становится невозможной, в связи с тем, что только заполнение такого объема информации вручную потребует колоссальных временных затрат и, как следствие, приведет к большому количеству ошибок.
Исходя из выше сказанного было принято решение о разработке базы данных торговой организации ООО «Марта». В связи с этим составим список задач, подлежащих автоматизации:
– Учет товара
– ценообразование (ведение прайс-листа);
– учета прихода и реализации товара;
– формирование выходных документов:
– прайс-лист;
– товар в наличии;
– книга продаж за период;
– книга покупок за период;
– отчет по продажам в разрезе по продавцам-консультантам;
– счет;
– товарная накладная;
– товарный чек;
– аналитика:
– расчет дневной выручки и валовой прибыли;
– формирование статистических диаграмм.
ГЛАВА 3. РАЗРАБОТКА ПРОЕКТА БАЗЫ ДАННЫХ ТОРГОВОЙ ОРГАНИЗАЦИИ ООО «МАРТА»
Новая технология учета в торговой организации ООО «Марта»
В результате внедрения базы данных торговой ООО «Марта» в процессы учета и анализа продаж и наличия товаров на складе будут внесены изменения, а бизнес-процессы, выполняемые начальником склада, будут изменены.
Новая технология учета основана на внедрении автоматизированного рабочего места начальника склада, что позволяет перейти от ручной обработки информации к автоматизированной.
Разработанная модель процесса учета продаж в условиях ООО «Марта» «КАК БУДЕТ» приведена на рисунке 3.1. Появившаяся в модели база данных торговой организации в качестве механизма выполнения выделена красным цветом. В тоже время состав бизнес-процессов не изменяется.
Рисунок 3.1- Модель бизнес-процесса «Деятельность торговой организации» «Как будет»
При анализе приведенной схемы можно увидеть, что по сравнению с моделью «КАК ЕСТЬ», представленной в первом разделе данной работы в данной схеме механизм во всех блоках диаграммы появился исполняющий механизм «База данных торговой организации», что показывает, что внедренная база данных используется используется на всех этапах работы торговой организации.
Декомпозиция процессов нулевого уровня представлена на рисунке 3.2.
Рисунок 3.2 ЇДекомпозиция процессов нулевого уровня
Как видно из рисунка 3.2, база данных используется на всех этапах деятельности торговой организации ООО «Марта». Следует отметить, что несмотря на то, что сам менеджер по продажам формально участвует на каждом этапе продаж, как один из сотрудников склада. Фактически его работа с введением базы данных сводится к вводу необходимой информации.
На рисунке 3.3 представлена диаграмма декомпозиции процесса «Учет имеющегося товара».
Рисунок 3.3- Диаграмма декомпозиции бизнес-процесса «Учет имеющегося товара»
Из рисунка 3.3 видно, что база данных используется только на этапе «Получение списка имеющегося в наличии товара». Задача сверка имеющегося товара с товаром в заявке выполняется вручную, а составление заявки поставщику на недостающий товар с помощью постороннего программного обеспечения
На рисунке 3.4 представлена диаграмма декомпозиции бизнес-процесса «Оформление прихода товара на склад».
Из рисунка 3.4 видно, что база данных используется на этапах «Корректировка информации о наличном товаре». «Расчет цен на товар» выполняется с помощью стороннего ПО. Задача сопоставления накладной на поставку с поступившим товаром выполняется вручную.
На рисунке 3.5 представлена диаграмма декомпозиции бизнес-процесса «Оформление отпуска товара».
Рисунок 3.4- Диаграмма декомпозиции бизнес-процесса «Оформление прихода товара»
Рисунок 3.5- Диаграмма декомпозиции Бизнес-процесса «Оформление отпуска товара»
Из рисунка 2.5 видно, что база данных используется на всех этапах процесса «Оформление отпуска товара».
Информационное обеспечение
Построение инфологической модели БД начнем с реализации диаграммы потоков данных (DFD). Стандарт описания бизнес-процессов DFD -- Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.
На рисунке 3.6 показана диаграмма потоков данных в рамках рассматриваемой предметной области.
Рисунок 3.6- Диаграмма потоков данных
Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком, но естественный язык не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка.
Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Выходные данные образуются на основе существующих данных, в конкретном случае, составляется отчетность, накладные, товарный чек, счет и прайс-лист (документы должны выводиться на экран и печать), а также справочники.
На рисунке 3.7 показана инфологическая модель, включающая в себя сущности и атрибуты сущностей. Инфологическая модель базы данных представляет собой описание объектов (сущностей), с набором атрибутов и связей между ними, которые выявляются в процессе исследования как входных, так и выходных данных. Она предназначается для структурного образования предметной области, с ориентированием на информационное внимание пользователей, разрабатываемой системы. Так же инфологическая модель должна быть как стабильной, так и неизменной, и являться представлением аспекта пользователя на описанную предметную область. Однако, при проектировании инфологической модели, должна присутствовать возможность для её увеличения и вставки вспомогательных данных.
Рисунок 3.7- Инфологическая модель БД
Описание сущностей и атрибутов диаграммы представленной на рисунке 3.7 представлено в таблице 2.1.
Таблица 3.1 Описание сущностей и их атрибутов в ER-диаграмме на логическом уровне
|
Наименование сущности |
Наименование атрибута |
Обязательный атрибут |
Первичный ключ |
Внешний ключ |
|
|
ГруппаТовара |
ID |
Да |
Да |
Нет |
|
|
Группа |
Нет |
Нет |
Нет |
||
|
Контрагент |
ID |
Да |
Да |
Нет |
|
|
Поставщик |
Да |
Нет |
Нет |
||
|
ФИО_Наимено вание |
Нет |
Нет |
Нет |
||
|
Информация |
Нет |
Нет |
Нет |
||
|
Паспорт |
Нет |
Нет |
Нет |
||
|
Адрес |
Да |
Нет |
Нет |
||
|
Телефоны |
Да |
Нет |
Нет |
||
|
Реквизиты |
Нет |
Нет |
Нет |
||
|
ИНН |
Нет |
Нет |
Нет |
||
|
КПП |
Нет |
Нет |
Нет |
||
|
Операция |
ID |
Да |
Да |
Нет |
|
|
Дата |
Да |
Нет |
Нет |
||
|
Закупка |
Да |
Нет |
Нет |
||
|
КонтрагентID |
Да |
Нет |
Да |
||
|
ТочкаID |
Да |
Нет |
Да |
||
|
МенеджерID |
Да |
Нет |
Да |
||
|
КассирID |
Да |
Нет |
Нет |
||
|
ПрайсЛист |
ТоварID |
Да |
Да |
Да |
|
|
Дата |
Да |
Да |
Нет |
||
|
ЦенаЗакупки |
Да |
Нет |
Нет |
||
|
ЦенаПродажи |
Да |
Нет |
Нет |
||
|
Работник |
ТабN |
Да |
Да |
Нет |
|
|
ФИО |
Нет |
Нет |
Нет |
||
|
ДолжностьID |
Да |
Нет |
Да |
||
|
Логин |
Нет |
Нет |
Нет |
||
|
Пароль |
Нет |
Нет |
Нет |
||
|
Процент |
Да |
Нет |
Нет |
||
|
Реквизиты |
Наименование |
Да |
Да |
Нет |
|
|
Адрес |
Да |
Нет |
Нет |
||
|
Реквизиты |
Да |
Нет |
Нет |
||
|
ИНН |
Да |
Нет |
Нет |
||
|
КПП |
Да |
Нет |
Нет |
||
|
ГенДиректор |
Да |
Нет |
Нет |
||
|
ГлавБух |
Да |
Нет |
Нет |
||
|
Склад |
ТоварID |
Да |
Да |
Да |
|
|
ТочкаID |
Да |
Да |
Да |
||
|
Количество |
Да |
Нет |
Нет |
||
|
СоставОперации |
ОперацияID |
Да |
Да |
Да |
|
Наименование сущности |
Наименование атрибута |
Обязательный атрибут |
Первичный ключ |
Внешний ключ |
|
|
ТоварID |
Да |
Да |
Да |
||
|
Количество |
Да |
Нет |
Нет |
||
|
Цена |
Да |
Нет |
Нет |
||
|
ЦенаЗакупки |
Да |
Нет |
Нет |
||
|
Товар |
ID |
Да |
Да |
Нет |
|
|
ГруппаID |
Да |
Нет |
Да |
||
|
Наименование |
Нет |
Нет |
Нет |
||
|
ЕдИзм |
Нет |
Нет |
Нет |
||
|
Фото |
Да |
Нет |
Нет |
||
|
ТорговаяТочка |
ID |
Да |
Да |
Нет |
|
|
Точка |
Нет |
Нет |
Нет |
||
|
Адрес |
Нет |
Нет |
Нет |
||
|
Описание |
Нет |
Нет |
Нет |
Разработанная модель находится в 3-й нормальной форме, так как:
– атрибуты сущностей являются атомарными;
– каждый неключевой атрибут функционально полно зависит от первичного ключа;
– в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.
Данные в БД должны обладать свойством целостности. Под целостностью данных понимается корректность данных и их непротиворечивость в любой момент времени. Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушения (этот вопрос не относится к незаконным изменениям и разрушениям, которые являются проблемой безопасности).
В разрабатываемой структуре базы данных учтены основные правила целостности. Каждая сущность идентифицируется уникальным ключом, и разработана система внешних ключей. База данных не содержит несогласованных значений внешних ключей, то есть при работе с записями происходит каскадное обновление связанных полей и каскадное удаление связанных записей.
Описание реализации БД ИС
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах [20].
В качестве СУБД выбрана MS Access 2010.
ER-диаграмма БД на физическом уровне представлена на рисунке 3.17.
Целостность, определяемая пользователем, поддерживается ограничениями в таблицах базы данных на ввод неотрицательных значений, а также обеспечением выбора значений внешних ключей из списков без разрешения варианта ввода недопустимого значения.
Описание таблиц базы данных приведено в таблице 3.8.
Таблица 3.8 Описание таблиц базы данных
|
Наименование таблицы |
Наименование поля |
Тип поля |
|
|
ГруппаТовара |
ID |
AutoNumber |
|
|
Группа |
Text(50) |
||
|
Должность |
ID |
AutoNumber |
|
|
Должность |
Text(50) |
||
|
Операция |
ID |
AutoNumber |
|
|
Дата |
Date/Time |
||
|
Закупка |
Да/Нет |
||
|
КонтрагентID |
Long Integer |
||
|
ТочкаID |
Long Integer |
||
|
МенеджерID |
Long Integer |
||
|
КассирID |
Long Integer |
||
|
Поставщик |
ID |
AutoNumber |
|
|
ФИО_Наименование |
Text(100) |
||
|
Информация |
Text(255) |
||
|
Паспорт |
Text(30) |
||
|
Адрес |
Text(100) |
|
Наименование таблицы |
Наименование поля |
Тип поля |
|
|
Телефоны |
Text(30) |
||
|
Реквизиты |
Text(100) |
||
|
ИНН |
Text(15) |
||
|
КПП |
Text(15) |
||
|
Перемещение |
ID |
AutoNumber |
|
|
ТоварID |
Long Integer |
||
|
ТочкаID1 |
Long Integer |
||
|
ТочкаID2 |
Long Integer |
||
|
Дата |
Date/Time |
||
|
Количество |
Single |
||
|
ПрайсЛист |
ТоварID |
Long Integer |
|
|
Дата |
Date/Time |
||
|
ЦенаЗакупки |
Currency |
||
|
ЦенаПродажи |
Currency |
||
|
Работник |
ТабN |
AutoNumber |
|
|
ФИО |
Text(100) |
||
|
ДолжностьID |
Long Integer |
||
|
Логин |
Text(15) |
||
|
Пароль |
Text(20) |
||
|
Процент |
Single |
||
|
Реквизиты |
Наименование |
Text(100) |
|
|
Адрес |
Text(100) |
||
|
Реквизиты |
Text(100) |
||
|
ИНН |
Text(15) |
||
|
КПП |
Text(15) |
||
|
ГенДиректор |
Text(30) |
||
|
ГлавБух |
Text(30) |
||
|
Склад |
ТоварID |
Long Integer |
|
|
ТочкаID |
Long Integer |
||
|
Количество |
Single |
||
|
СоставОперации |
ОперацияID |
Long Integer |
|
|
ТоварID |
Long Integer |
||
|
Количество |
Single |
||
|
Цена |
Currency |
||
|
ЦенаЗакупки |
Currency |
||
|
Товар |
ID |
AutoNumber |
|
|
ГруппаID |
Long Integer |
||
|
Наименование |
Text(150) |
||
|
ЕдИзм |
Text(15) |
||
|
Фото |
OLE Object |
Рисунок 3.8 ---ER-диаграмма БД на физическом уровне
ГЛАВА 4. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ ТОРГОВОЙ ОРГАНИЗАЦИИ ООО «МАРТА»
Обоснование выбора средств разработки ИС
Обоснование выбора средств разработки клиентской части ИС
Разработка интерфейса всегда являлась трудоемкой задачей отнимающей много времени у разработчиков. Однако в последние годы появились так называемые средства визуальной разработки приложений в значительной мере упростившие задачу разработки графического интерфейса пользователя. Сейчас на рынке программных продуктов предлагается довольно много разнообразных средств визуальной разработки приложений, ориентированных на разработку информационных систем. Все их можно условно разделить на два класса:
- Специализированные средства ориентированные исключительно на работу с вполне определенной СУБД и не предназначенные для разработки обычных приложений, не использующих базы данных. Примером средств такого рода может служить система Power Builder фирмы Sybase;
- Универсальные средства, которые могут использоваться как для разработки информационных приложений, взаимодействующих с базами данных, так и для разработки любых других приложений, не использующих базы данных.
Из таких средств наибольшей известностью пользуются системы Borland Dеlрhi фирмы Borland‚ Visual Basic, Visual C++ фирмы Microsoft. Каждый из указанных классов имеет свои достоинства и недостатки, поэтому в общем случае трудно отдать предпочтение одному из них. В предлагаемом дипломном проекте в качестве средства разработки выбран продукт Borland Delphi, пользующийся большой популярностью. Delphi базируется на объектно-ориентированном языке Object Раsсal, который наилучшим образом подходит для учебных целей вследствие своей строгости и простоты. Кроме того, в Object Pascal в полной мере реализованы все основные концепции объектно-ориентированного программирования. О6ъектно- ориентированное программирование позволяет сделать любую систему более гибкой и динамичной, исключив необходимость в постоянном переписывании структуры базы данных и приложений. Главное достоинство объектно-ориентированного проектирования заключается в возможности повторно использовать ранее написанный код. Кроме того, объектные системы несут в себе возможность модификации и развития. Это положение позволяет начать проектирование будущей системы, не имея исчерпывающего представления о предметной области. Поскольку получение детальной информации о предметной области ??процесс весьма трудоемкий, то применение объектно-ориентированного подхода позволит сократить сроки и уменьшить стоимость разработки системы [10].
Delphi - это комбинация нескольких важнейших технологий:
– высокопроизводительный компилятор в машинный код;
– объектно-ориентированная модель компонент;
– визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов;
– масштабируемые средства для построения баз данных;
Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений. Еще до компиляции разработчик видит результаты своей работы ??после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде [10].
Основной упор объектно-ориентированной модели программных компонент в Delphi делается на максимальном использовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Все в Delphi написано на нем же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые вы можете создать /10/.
Cреда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений VCL -- библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами.
Обоснование выбора СУБД
На сегодняшний день существует достаточно большое количество СУБД, возможности которых полностью удовлетворяют требованиям задачи. Однако в рамках организованного в строительном тресте единого информационного пространства для хранения данных системы будет использоваться MS SQL Server. В первую очередь это обусловлено тем, что все прочие задачи предприятия используют для хранения данных данную СУБД, установленную и используемую в централизованном порядке. С учетом того, что использование SQL Server не требует дополнительного финансирования (используется уже установленная СУБД, поддерживаемая силами отдела АСУ), рассмотрим дополнительные преимущества SQL Server.
Microsoft SQL Server 2010 -- это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В сервер SQL Server 2010 включена поддержка протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения. Кроме того, SQL Server 2010 полностью использует все возможности операционной системы Windows, включая поддержку до 32 процессоров и 64 ГБ ОЗУ.
Основные преимущества SQL Server 2010:
– широкая поддержка языка XML и стандартов Интернета;
– удобный доступ к данным через веб;
– масштабируемость для электронной коммерции;
– масштабируемость для хранилищ данных;
– упрощенное управление и настройка;
– быстрые преобразование данных, разработка и отладка и так далее.
Дерево функций и сценарий диалога
Для автоматизации разрабатываемого программного продукта существуют функции управления и обработки данных. При этом можно выделить и детализировать два подмножества функций: реализующих служебные функции (например, проверки пароля, ведения календаря, архивации баз данных и др.) и реализующих основные функции (ввода первичной информации, обработки, ведения справочников, ответов на запросы и др.).
При наличии различных вариантов ответа на ввод функции пользователем в последующих шагах происходит детализация, или уточнение действий, например, какая информация должна вводится, в каком виде или на какое устройство желательно осуществить вывод и т.д.
Дерево функций разрабатываемого приложения представлено на рисунке 4.1.
Рисунок 4.1 - Дерево функций
Сценарии диалога - описывает начальное окно, множество состояний диалога, а также действия, которые выполняются в каждом состоянии.
Выявление состава функций, их иерархии и выбор языка общения (например, языка типа «меню») позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность.
При разработке структуры диалога предусмотрена возможность работы с экранными формами входных документов, формирование выходных документов, корректировки вводимых данных, просмотра введенной информации, работу с таблицами нормативно-справочной информации, протоколирования действий пользователя, а также помощь на всех этапах работы.
Рассматриваемое приложение реализует следующие режимы работы:
1. Режим «Справочники»
2. Режим «Товары»
3. Режим «Отчеты и статистика»
Сценарий диалога в режиме справочника предполагает следующую последовательность действий:
1) Выбор справочника: группы товаров, торговые точки, работники, контрагенты;
2) Выбор действия: просмотр, изменение записи, удаление записи, добавление записи;
3) Выполнение выбранного действия;
4) Завершение работы со справочником.
Сценарий диалога для режима «Справочники» представлен на рисунке 4.2.
Более сложным является режим «Товары». Он предполагает следующие возможности: управление прайс-листом, создание закупки и/или продажи, просмотр наличия товаров на складе, перемещение товара.
Сценарий диалога задачи управления прайсом схож со сценарием диалога «Справочники». Отличие состоит в наличии дополнительных возможностей фильтрации и поиска записей. Сценарий диалога для задачи управления прайс-листом представлен на рисунке 4.3.
Подобные документы
Анализ системы управления базами данных, основные задачи: обработка информации, организация работы пользователей. Access как функционально полная система, имеющая мощные средства для работы программы. Этапы разработки базы данных торговой организации.
контрольная работа [458,0 K], добавлен 05.01.2013Возможности извлечения информации из баз данных. Программы для создания и обработки базы данных и создания пользовательского интерфейса. Обоснование выбора программных средств для реализации. Создание базы данных, интерфейса и базы данных к интерфейсу.
курсовая работа [2,9 M], добавлен 24.03.2023Проектирование логической структуры базы данных методом нормальных форм, сущность связь. Сравнительный анализ спроектированной базы данных и базы данных существующих информационных систем. Выбор и обоснование состава технических и программных средств.
курсовая работа [3,0 M], добавлен 22.12.2014Базы данных и системы управления ими. Разработка базы данных "Торговая организация", позволяющей вести учет имеющегося товара, покупателей и поставки товара. Проектирование таблиц, запросов и форм. Создание отчетов. Обеспечение доступа к информации.
курсовая работа [1,2 M], добавлен 21.11.2014Обзор программных средств разработки приложений и обоснование выбора языка программирования. Классификация приложений для работы с базами данных. Функциональная структура базы данных с указанием назначения программных модулей, руководство пользователя.
дипломная работа [645,3 K], добавлен 21.11.2010Обзор и сравнительная характеристика программного обеспечения для создания СУБД. Принципы организации данных. Основные возможности MS Access. Разработка структуры и реализация средствами SQL базы данных для учета заказов, наличия и продажи автозапчастей.
курсовая работа [2,5 M], добавлен 27.05.2013Разработка эскизного и технического проектов программы, ее назначение и область применения, описание алгоритма, организация входных и выходных данных. Выбор состава технических и программных средств, разработка рабочего проекта, спецификация программы.
курсовая работа [700,6 K], добавлен 26.01.2010Выбор программных и аппаратных средств для создания базы данных. Описание структуры программы. Описание разработки приложения. Подключение к базе данных, выполняемое с помощью компонента ADOConnectio. Создание средств защиты информации в программе.
курсовая работа [2,1 M], добавлен 16.02.2015Общая характеристика систем обработки информации, их роль в управлении современным предприятием. Разработка проекта автоматизации процесса учета товаров на основе использования базы данных для магазина. Создание клиентской базы с возможностью обновления.
дипломная работа [3,1 M], добавлен 13.07.2011Создание базы данных для учета лекарственных средств и изделий медицинского назначения в аптеках стационаров. Требования к программному продукту. Способ организации данных. Начало работы с приложением. Экономическая эффективность внедрения разработки.
дипломная работа [2,6 M], добавлен 10.10.2015
