Автоматизация складского учета

Delphi также прост в  обучении, как Visual Basic, но при этом  средства языка программирования Pascal позволяют использовать все  современные возможности объектно-ориентированного программирования.

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

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

Поэтому для разработки информационной системы для учета движения товаров на складе ООО «Торнадо Киров» и была выбрана среда программирования Delphi.

1.8. Выбор  технических средств 

Для выбора характеристик  компьютера необходимо учесть следующие  моменты: время получения результатов запросов к базе данных допустимо в пределах нескольких секунд, то есть требования к скорости обработки данных невысоки; необходимо предусмотреть возможное развитие системы (увеличение объема базы данных, переход к новым версиям операционной системы и СУБД, включение системы в локальную вычислительную сеть и т.д.). Таким образом, технические требования приведены в таблице 1.

 

 

 

Таблица 1 – Технические требования

 

Характеристика	Требования
	минимальные	рекомендуемые
Процессор	Pentium 166	Pentium II – 400
Объем оперативной памяти, Мбайт	128	256
Емкость жесткого диска, Мбайт	115	675
Сетевые средства	-	Да
Привод FDD	Да	Да
Привод DVD-ROM	Да	Да
Монитор	15’	17’
Клавиатура	Да	Да
Мышь	Да	Да
Принтер	-	Да

 

Выводы

После рассмотрения аналогов системы, было принято решение разрабатывать свою собственную информационную систему, которая будет удовлетворять требуемым запросам и будет более приемлема по цене. Для реализации поставленных в данном проекте задач будет использована программа Microsoft Access , входящая в пакет Microsoft Office. Microsoft Access имеет большее преимущество перед другими системами главное в простоте, доступности программы, наличием всех средств для обработки и управления БД. Интерфейс программы разработан в Borland Delphi . Это одно из самых популярных в нашей стране средств разработки приложений. С помощью Delphi создаются приложения для операционной системы Windows. Среда Delphi легко расширяется установкой дополнительных модулей. Пользовательский интерфейс также хорошо настраиваемый - каждый организует рабочее пространство так, как ему будет удобно.

 

 

2. Проектная часть

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

2.1. Предметная область

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

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

Задачу автоматизации можно разделить на 3 подзадачи: справочники, учет движения товаров и анализ по товару.

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

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

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

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

Проанализировав все данные, необходимо составить схему данных рассматриваемой предметной области.

2.2. Проектирование модели в BPWin

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

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать  бизнес с трех ключевых точек  зрения:

С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

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

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

Как видно из контекстной  диаграммы (рисунок 1), управляющая информация входит в блок сверху (Должностные инструкции, ГОСТы), в то время как входная информация (Информация о товаре, Информация о клеинте, Заказа на поставку товара, Информация о поставщике), которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны блока (Прайс-лист, Расходная накладная, Отчеты). Механизм (Работники склада, Работники отдела сбыта, Работник отдела поставок), который осуществляет операцию, предоставляется дугой, входящий в блок снизу.

Рисунок 1. Контекстная  диаграмма

Далее блок Учет движения товаров на складе разбивается на 4 процесса, которые представлены на декомпозиции процесса (рисунок 2):

Получение товара на склад;

Хранение товара;

Выдача товара;

Оформление заявки.

Рисунок 2. Диаграмма декомпозиции процесса Учет движения товаров

 

Блок Получение товара на склад разбивается еще на 3 процесса:

Ввод данных о поставщике; Проверка данных; Ввод данных о товаре. Диаграмма декомпозиции процесса Получение товара на склад представлена на рисунке 3.

Рисунок 3. Диаграмма декомпозиции процесса Получение товара на склад

2.3. Логическое проектирование

Построение схемы данных выполняется в несколько этапов:

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

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

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

2. Моделирование связей. Связь – это поименованная ассоциация между двумя сущностями, значимая в рассматриваемой предметной области. Обычно каждый экземпляр одной сущности (родительской) ассоциируется с произвольным числом экземпляров-потомков. Имя каждой связи между двумя сущностями должно быть уникально, однако может повторяться в пределах модели. Для каждой связи определяется степень и обязательность. Связь всегда направляется от родительской сущности. Связи бывают следующих типов:

• 1:1 (один к одному) – используется на верхнем уровне иерархической модели данных;
• 1:М (один ко многим) – один экземпляр одной сущности связывается с несколькими экземплярами второй сущности;
• М:N (многие ко многим) – используется на начальной стадии разработки диаграммы.

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

На рисунке 1 представлена схема базы данных, на которой видно, что в существующей базе данных семь таблиц, так как в модели присутствуют семь сущностей – это Товары, Группы товаров, Склад, Клиенты, Поставщики, Приход товара, Расход товара. Также на рисунке описаны и все атрибуты сущностей. Все сущности в модели связаны связью один ко многим (1:М).

Рисунок 1. Схема базы данных

Сущность Клиенты и Товары должны быть связаны между собой, но связь получается многие-ко-многим, так как несколько клиентов могут купить один и тот же товар, а так же несколько наименований товара могут быть проданы одному клиенту, но связи многие-ко-многим в базе данных использовать не рекомендуется, поэтому вводится промежуточная сущность Расход товара, которая связывается с сущностью Клиенты по ключевому полю Код_клиента связью один-ко-многим. А сущность Товары связывается с сущностью Расход товара по ключевому полю Код_товара связью один-ко-многим.

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

Сущность Группы_товаров  и Товары связаны при помощи связи  один-ко-многим, так как одной  группе может принадлежать несколько наименований товаров.