Анализ предметной области и постановка задачи
Информационная система — это взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели.
Экономическая информационная система (ЭИС) — это совокупности внутренних и внешних потоков прямой и обратной информационной связи экономического объекта, методов, средств, специалистов, участвующих в процессе обработки информации и выработке управленческих решений.
Автоматизированной информационной системой (АИС) называется комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства, информационные ресурсы, а также персонал, обеспечивающий поддержку динамической информационной модели предметной области для удовлетворения информационных потребностей пользователей.
В автоматизированных ИС часть функций управления и обработки данных выполняется компьютерами, а часть человеком.
Исходя из современных требований, предъявляемых к качеству работы финансового звена крупного предприятия, нельзя не отметить, что эффективная работа его всецело зависит от уровня оснащения компании информационными средствами на базе компьютерных систем автоматизированного складского учета.
Компьютерный учет имеет свои особенности и радикально отличается от обычного. Компьютер не только облегчает учет, сокращая время, требующееся на оформление документов и обобщение накопленных данных для анализа хода торговой деятельности, необходимого для управления ею. Отчеты о положении в торговле, получаемые с помощью компьютера, можно получить и без него – никакой особой математики в компьютере не содержится – но на расчеты уйдет столько времени, что они уже ни на что не будут нужны; или ими придется занять такое количество расчетчиков, что на их зарплату уйдет значительно больше, чем будет получено прибыли в результате их расчетов.
Таким образом, при применении компьютера «количество переходит в качество»: увеличение скорости расчетов делает возможным качественное улучшение самой схемы построения торговли.
Реализация проекта автоматизированной информационной системы «Учет движения материалов на складе» значительно облегчит работу сотрудников на складе и обеспечит возможность уменьшить расходы на управление за счет освобождения человеческих ресурсов, занятых различными видами обработки бумажных документов, хранить и анализировать данные за любой промежуток времени, осуществлять поиск нужной информации по различным критериям отбора. Поэтому данная тема является весьма актуальной в современных условиях хозяйственной деятельности.
Целью моей курсовой работы является анализ деятельности складского учета, внедрение информационных технологий в процесс работы склада. Результатом выполнения работы является создание готовой информационной системы учета движения материалов на складе.
При выполнении курсовой работы были поставлены следующие задачи:
— описание предметной области;
— проектирование концептуальной модели данных;
— проектирование физической структуры базы данных.
Решение этих задач предусматривает создание базы данных учета движения материалов на складе.
Глава 1. Анализ предметной области и постановка задачи
1.1 Предметная область
Предметная область информационной системы — это материальная система или система, характеризующая элементы материального мира, информация о которой хранится и обрабатывается. Предметная область рассматривается как некоторая совокупность реальных объектов и связей между ними.
Склад готовой продукции не занимается никакой коммерческой деятельностью, а только осуществляет процедуру хранения продукции для сторонних лиц заинтересованных в этом. Склад должен выполнять следующие функции: прием, учет, хранение и отгрузка готовой продукции, приемка готовой продукции, рассортировка, комплектация потребителям, определение потребности в транспортных средствах, механизированных погрузочных средствах, таре и рабочей силе для отгрузки продукции, согласование планов и условий поставок продукции с основного производства и по договорам со сторонними организациями, организация приемки продукции сторонними организациями, координация деятельности по закупке и продаже продукции с наличием свободных складских площадей, подготовка отчетов об объемах продукции, а также участие в рассмотрении поступающих на предприятие претензий.
Затем склад готовой продукции должен предоставить создание условий для сохранности продукции, находящейся на временном хранении, организацию рационального хранения, внутренней транспортировки, упаковки и подготовки продукции к отправке, обеспечение сохранности продукции, обеспечение высокого уровня механизации и автоматизации транспортно-складских операций, применения компьютерных систем и нормативных условий организации и охраны труда.
Склад обязан вести учет продукции, находящейся на временном хранении, составление карточек, кладовых книг, описей, приходных и расходных накладных, ордеров по учету прихода, расхода, наличия, остатков продукции на складе, учет выполнения заказов по отгрузке и разгрузке готовой продукции, составление отчетов о загрузке складских площадей.
Рассмотрим типичные бизнес-процессы складского учета на не автоматизированном гипотетическом складе. Такое рассмотрение проводится с целью выявить недостатки существующей системы складского учета, а так-же показать необходимость автоматизации склада.
Процедура принятия продукции на склад:
— Продукция приходит на склад в сопровождении экспедитора и приходной накладной;
— Контролер на складе, проверяет приходную накладную, и регистрирует ее в книге учета входящих документов (накладных);
— Осматривает входящую продукцию, и если с ней все нормально принимает ее на склад, передавая экспедитору товара выписку (документ) о том, что товар принят на хранение;
— Грузчики отвозят товар в свободное место хранения, и контролер делает запись в книге учета о том, где хранится вновь поступившая продукция.
В ходе работы склада, он нуждается в инвентаризации, которая включает в себя такие стадии как: ответственный работник по переучету продукции, в сопровождении книги переучета, отправляется на склад, и в ручную осматривает и переписывает данные о товаре и его количестве; после этого данные сверяются в книге учета товаров, лицами ответственными за документы отчетности на складе и составляется соответствующий отчет, по данным переучета продукции.
Отгрузка товаров со склада проходит следующие стадии:
— Получатель товара подает накладную на отгрузку товара;
— Контролер проверяет эту накладную и регистрирует ее в книге учета входящих документов;
— Далее контролер дает указание работникам склада на поиск нужной продукции и отгрузки ее;
— Затем получатель товара проводит его осмотр, на счет того нужный ли товар отгрузили и в нужном количестве;
— Контролер регистрирует в книге учета факт отгрузки товара;
— Далее контролер выдает получателю груза сопроводительный документ по отгрузке товара;
— Далее происходит непосредственно отгрузка товара техническими средствами.
Проанализировав ситуацию на складе и выявив все минусы, постараемся создать такую систему, которая бы автоматизировала следующие операции на складе:
— Регистрация документов осуществляется с помощью ЭВМ;
— Поиск товаров для отгрузки будет проводиться путем поиска соответствующего товара в БД и просмотра информации о месте его хранении (номер склада).
— Формирование документов отчетности, будет производиться системой автоматически.
В результате вся работа с бумагами будет проводиться с использованием компьютеров, не нужно будет возится с кучей бумаг.
При помощи ЭВМ на складе автоматизирован учет поступления и отгрузки товаров, учет входящих и исходящих документов, количественный учет. В общем объеме учетных работ эти задачи имеют значительный удельный вес. Их автоматизация позволяет сократить ручные операции, ускорить обработку информации, повысить точность учета. В памяти ЭВМ хранится и может быть выдана на печать детальная информация о количестве поступления и отгрузки конкретного товара по каждому документу в случае несовпадения величины запаса с данными машинного учета.
Главное назначение автоматизированной системы в данном случае – повысить эффективность выполнения основных функций работников склада.
Автоматизация управления процессами на складе, повышает его оперативность и эффективность. Критериями выбора технических средств являются:
— надежность функционирования системы;
— функциональная полнота системы; быстродействие;
— минимизация затрат на стоимость: аппаратных средств, прикладных систем, сопровождения системы, развития системы.
1.2 Постановка задачи
Основное преимущество автоматизации — это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте, увеличение степени достоверности информации и увеличение скорости обработки информации; излишнее количество внутренних промежуточных документов, различных журналов, папок, заявок и т.д., повторное внесение одной и той же информации в различные промежуточные документы. Также значительно сокращает время автоматический поиск информации, который производится из специальных экранных форм, в которых указываются параметры поиска объекта.
Под автоматизированной системой понимается система методов и способов сбора, накопления, хранения, поиска, обработки и защиты управленческой информации на основе применения развитого программного обеспечения, средств вычислительной техники и связи, а также способов, с помощью которых эта информация предоставляется пользователям.
Структура конкретной автоматизированной системы для своей реализации предполагает наличие трех компонентов: комплекса технических средств, состоящего из средств вычислительной, коммуникационной и организационной техники; системы программных средств, состоящей из системного (общего) и прикладного программного обеспечения; системы организационно-методического обеспечения, включающей инструктивные и нормативно-методические материалы по организации работы управленческого и технического персонала в рамках конкретной автоматизированной системы обеспечения управленческой деятельности.
Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. Притом, что любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных. Наиболее простым является составление ER- диаграммы. ER- диаграмма просто реализуется в реляционную модель: сущность становится таблицей, атрибуты- идентификаторами преобразуются в первичные ключи, а остальные атрибуты- в столбцы.
Бизнес-процессы – это последовательность взаимосвязанных активностей или задач, которые приводят к созданию определенного продукта или услуги для потребителей. Часто бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов. Бизнес-процесс начинается со спроса потребителя и заканчивается его удовлетворением. Бизнес-процесс может быть декомпозирован на несколько подпроцессов, которые имеют собственные атрибуты, однако также направлены на достижение цели основного бизнес-процесса. При описании бизнес-процессов используются различные методологии и соответствующие нотации, такие как: IDEF0, IDEF3, DFD.
В данной работе в качестве СУБД была выбрана система управления реляционной базой данных Microsoft Access, включающей все необходимые инструментальные средства для создания локальной базы данных. В ее файле могут храниться не только данные, но и объекты интерфейса: отчеты, формы, запросы.
1.3 Анализ информационных потребностей пользователей
В зависимости от поставщика решения, реализация основных и сопутствующих функций по управлению складом может существенно различаться, однако общим остается принцип построения логики процессов размещения, комплектации, приема, отгрузки на базе концепций «товар», «место хранения», «количество», «единица измерения», «заказ».
Минимальная функциональность системы автоматизации склада:
— Инструменты для обеспечения адресного хранения.
— Мониторинг исполнения заданий в режиме реального времени.
— Встроенные средства интеграции с технологическим оборудованием для сбора данных.
Системы автоматизации склада это большие, сложные, высокотехнологические продукты, которые потребуют комплексного внедрения и квалифицированных специалистов для настройки и последующей работы.
Информационной система должна давать полную, достоверную информацию и отвечать на любые вопросы, в пределах предметной области. Поэтому крайне важно иметь эффективные средства автоматизации всех этапов реализации проекта.
Глава 2. Проектирование информационной системы
На этапе проектирования информационной системы формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:
— схема базы данных (на основании ER-модели, разработанной на этапе анализа);
— набор спецификаций модулей системы (они строятся на базе моделей функций).
2.1 Моделирование бизнес-процессов
BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать деятельность предприятия с трех ключевых точек зрения:
— С точки зрения функциональности системы. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
— С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
— С точки зрения последовательности выполняемых работ. Более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
2.1.1 Нотация IDEF0
Нотация IDEF0 (Integration Definition for Function Modeling) была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.
IDEF0 может быть использована для моделирования широкого класса систем.
Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции.
Для существующих систем IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются.
Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок.
Контекстная диаграмма — это модель, представляющая систему как набор иерархических действий, в которой каждое действие преобразует некоторый объект или набор объектов. Высшее действие иерархии называется действием контекста — это самый высокий уровень, который непосредственно описывает систему. Уровни ниже называются порожденными декомпозициями и представляют подпроцессы родительского действия.
При создании модели сначала необходимо изобразить самый высокий уровень — действие контекста. Наименование действия описывает систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, которое разъясняет цель деятельности с точки зрения самого общего взгляда на систему.
Каждый блок может иметь различные типы связанных с ним стрелок. Стрелки обозначают людей, место, вещи, понятия или события. Стрелки связывают границы диаграммы с блоками, а также действия (блоки) на диаграмме между собой. В диаграммах IDEF0 имеется четыре основных типа стрелок.
Вход блока представляет материал или информацию, которая должна быть использована или преобразована блоком, чтобы произвести продукцию (выпуск). Стрелки входа всегда направляются в левую сторону блока. Стрелки входа необязательны, так как не все действия могут преобразовать или изменять (заменять) что-либо.
Каждый блок должен иметь по крайней мере одну стрелку контроля (управления). Управление всегда входит в вершину блока. Управление, как правило, представляется в виде правил, инструкций, политики компании, процедур или стандартов. Оно влияет на деятельность без фактического преобразования чего-либо. Управление может также использоваться для описания процедуры начала или окончания выполнения действия.
Стрелки выхода (выпуска) — это материал или информация, произведенная блоком. Каждый блок должен иметь по крайней мере одну стрелку выхода (выпуска). Процессы, которые не производят продукции (выпуска), лучше не моделировать вообще.
Механизмы исполнения — это те ресурсы, которые обеспечивают выполнение действия. В качестве механизма исполнения могут быть рассмотрены персонал компании, машины или оборудование, которые обеспечивают выполнение деятельности. Стрелка механизма может отсутствовать, если определено, что это не важно для работы блока.
Для проанализированной предметной области построим контекстную диаграмму при помощи BPWin 4.0.
Рисунок 1. Контекстная диаграмма
Декомпозиционное разложение модели используется в моделировании бизнес-процессов, для того чтобы дать более подробное описание блоков. Каждое из этих действий может в свою очередь быть декомпозировано. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели.
Декомпозируем контекстную диаграмму на 3 функциональных блока (Рис.2):
— Приемка товара на склад;
— Хранение и переучет продукции;
Рисунок 2. Диаграмма IDEF0
2.1.2 Нотация DFD
Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Диаграммы потоков данных используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. Главная цель DFD — показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами.
Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.
Далее моделировать систему будем, используя диаграммы потоков данных (DFD).
Декомпозируем функциональный блок «Приемка товара на склад» еще на четыре действия (Рис.3):
- Проверка товарно-транспортной накладной;
- Проверка поставленной продукции;
- Занесение данных о продукции в БД;
- Передача продукции на хранение.
Рисунок3. Диаграмма DFD «Приемка товара на склад»
Далее декомпозируем функциональный блок «Хранение и переучет продукции» на два действия (Рис.4):
— Размещение товара на складе;
— Анализ наличия необходимого количества на складе (на этом этапе лицу, принимающему решение, передается оперативная информация).
Рисунок 4. Диаграмма DFD «Хранение и переучет продукции»
Рисунок 5. Диаграмма DFD «Отгрузка»
Декомпозируем функциональный блок «Отгрузка» на три действия (Рис.5):
— Проверка наличия товара на складе;
— Занесение информации об отгружаемой продукции в БД;
— Отгрузка продукции по требованию.
2.1.3 Нотация IDEF3
Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (workflow), для которых важно отразить логическую последовательность выполнения процедур.
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
Декомпозируем функциональный блок «Проверка товарно-транспортной накладной» который, в свою очередь, является элементом декомпозиции блока «Приемка товара на склад» на четыре действия:
— Принятие товарно-транспортной накладной;
— Проверка реквизитов документа;
— Проверка количества продукции.
Рисунок 6. Диаграмма IDEF3 проверки товарно-транспортной накладной
Рисунок 7. Диаграмма IDEF3 проверки поставленной продукции
Декомпозируем функциональный блок «Проверка поставленной продукции» который, в свою очередь, является элементом декомпозиции блока «Приемка товара на склад» на три действия:
— Проверка продукции на годность;
2.2 Разработка информационной модели данных
Построение информационной модели предметной области предполагает выделение сущностей, их атрибутов и первичных ключей, идентификацию связей между сущностями. Общепринятым видом графического изображения реляционной модели данных является ER-диаграмма, на которой сущности изображаются прямоугольниками, соединенные между собой связями. Такое графическое представление облегчает восприятие структуры базы данных по сравнению с текстовым описанием.
Основные преимущества ER-моделей:
— модели позволяют проектировать базы данных с большим количеством объектов и атрибутов.
ER-модели реализованы во многих системах автоматизированного проектирования баз данных.
IDEF1X описывает собой совокупность/набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности, т.о. сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Сущность — это множество экземпляров реальных или абстрактных объектов (человек, место, вещь, событие, состояние, концепция, идея, предмет и т.п.), обладающих общими атрибутами или характеристиками, и о которых необходимо хранить информацию.
Основные элементы ER-моделей:
— связи между объектами
Сущность — это множество индивидуальных объектов — экземпляров, причем все эти объекты являются различными.
Связь — это функциональная зависимость между сущностями. Каждая сущность обладает атрибутами. Атрибут — это свойство объекта, характеризующее его экземпляр.
Графически связь изображается в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный — прерывистой линией.
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой).
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности.
В моей курсовой работе ER-модель имеет связь типа один-ко-многим.
Существуют два уровня представления и моделирования — логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.
Диаграмма уровня сущностей и атрибутов, в нотации IDEF1X логического уровня модели (Рис.8):
Физический уровень модели составляют целевая СУБД, имена объектов и типы данных, индексы. ERD – диаграмма в нотации IDEF1X физического уровня представлена на рис. 9.
Рисунок 8. Диаграмма сущностей и атрибутов логического уровня модели
Рисунок 9. ERD – диаграмма в нотации IDEF1X физический уровень.
3. Реализация информационной системы в СУБД Access
Структурными единицами базы данных Access являются таблицы, запросы, формы, отчеты, страницы, макросы и модули. Таблицы – это объекты, в которые вводятся данные.
Формы – это объекты предназначенные для работы с индивидуальными данными из таблиц баз данных. С помощью форм можно вводить информацию в таблицы, редактировать и удалять ее, а также ограничить доступ к данным и отображать их только в режиме просмотра.
Запросы – это объекты, позволяющие производить расчеты, извлекать нужные данные по определенным критериям, фильтровать данные входящие в БД.
Отчеты – это объекты, позволяющие выводить результатные данные на экран и печать в нужном виде.
Страницы – это объекты, позволяющие связываться с Internet или Intranet.
Макросы – это макрокоманды БД, позволяющие просто и быстро выполнять однотипные операции с данными базы.
Модули – это специальные программы, написанные в Access на языке Visual Basic для обработки данных базы, если средств, заложенных в Access для их обработки не хватает или пользоваться ими менее удобно.
3.1 Создание таблиц и схемы данных
Все таблицы создаются на основе информационной модели, причем каждой сущности будет соответствовать отдельная таблица. Ключевые поля будут соответствовать первичным ключам сущностей.
Рисунок 10. Струкрура полей таблицы “Продукция”
Рисунок 11. Пример таблицы “ Продукция ”
Схема данных является графическим образом БД. Она используется различными объектами Access для определения связей между несколькими таблицами. Например, при создании формы, содержащей данные из нескольких взаимосвязанных таблиц, схема данных обеспечивает автоматический согласованный доступ к полям этих таблиц. Она же обеспечивает целостность взаимосвязанных данных при корректировке таблиц.
Связь между таблицами устанавливает отношения между совпадающими значениями в ключевых полях, обычно между полями, имеющими одинаковые имена в обеих таблицах. В большинстве случаев с ключевым полем одной таблицы, являющимся уникальным идентификатором каждой записи, связывается внешний ключ другой таблицы. Обязательным условием при установлении связи является совпадение связываемых полей по типу и формату.
В нашей базе данных был использован тип связи «один-ко-многим». Отношение «один-ко-многим» является наиболее часто используемым типом связи между таблицами. В отношении «один-ко-многим» каждой записи в таблице A могут соответствовать несколько записей в таблице B, но запись в таблице B не может иметь более одной соответствующей ей записи в таблице A. База данных реализована в виде восьми взаимосвязанных таблиц.
Рисунок 12. “Схема данных”
3.2 Разработка запросов
С помощью запроса можно выполнить следующие виды обработки данных:
— сформировать на основе объединения записей взаимосвязанных таблиц новую виртуальную таблицу;
— включить в результирующую таблицу запроса заданные пользователем поля;
— выбрать записи, удовлетворяющие условиям отбора;
— произвести вычисления в каждой из полученных записей;
— сгруппировать записи, которые имеют одинаковые значения в одном или нескольких полях, в одну запись с одновременным выполнением над другими полями статистических функций;
— добавить в результирующую таблицу запроса строку итогов;
— произвести обновление полей в выбранном подмножестве записей;
— создать новую таблицу базы данных, используя данные из существующих таблиц.
В Access может быть создано несколько видов запроса:
— запрос на выборку — выбирает данные из взаимосвязанных таблиц базы данных и таблиц запросов. Результатом является таблица, которая существует до закрытия запроса. На основе такого запроса могут строиться запросы других видов;
— запрос на создание таблицы — также выбирает данные из взаимосвязанных таблиц и других запросов, но в отличие от запроса на выборку результат сохраняется в новой постоянной таблице базы данных;
— запросы на обновление, добавление, удаление — являются запросами, в результате выполнения которых изменяются данные в таблицах.
Согласно поставленному условию необходима реализация следующий запрос (на выборку):
— В какие дни объем поставок материалов X от поставщика Т превышал 200 единиц;
Рассмотрим реализацию запроса.
Окно создания запроса в режиме конструктора будет выглядеть следующим образом.
Поскольку запрос является параметрическим, при его выполнении на экране появятся диалоговые окна, где пользователю необходимо задать параметры выборки:
Рисунок 13. Окно создания параметрического запроса в режиме конструктора
Рисунок 14 а. Запрос на ввод поставщика
Рисунок 14 б. Запрос на ввод наименования продукции
Рисунок 15. Результат выполнения запроса
Рассмотрим другой тип запросов — запрос на создание таблицы. Таблица «Остатки» будет создана автоматически, на основе данных, имеющихся в таблицах «Продукция», «Приход» продукции» и «Расход продукции».
Рисунок 16. Окно создания запроса на создание таблицы в режиме конструктора
3.3 Разработка форм и отчетов
Access предоставляет возможность вводить данные как непосредственно в таблицу, так и с помощью форм. Форма в БД — это структурированное окно, которое можно представить так, чтобы оно повторяло форму бланка. Формы создаются из набора отдельных элементов управления.
Внешний вид формы выбирается в зависимости от того, с какой целью она создается. Формы Access позволяют выполнять задания, которые нельзя выполнить в режиме таблицы. Формы позволяют вычислять значения и выводить на экран результат. Источником данных для формы являются записи таблицы или запроса.
Форма предоставляет возможности для:
— ввода и просмотра информации базы данных
Основные способы создания форм:
— Конструктор форм (предназначен для создания формы любой сложности)
— Мастер форм (позволяет создавать формы различные как по стилю, так и по содержанию).
Рисунок 17. Форма “Приход” с кнопками
Аналогично создаются и остальные формы. Для удобства ввода данных также предусмотрена кнопочная форма, позволяющая, открыть формы для ввода данных, выполнить запросы, просмотреть и распечатать отчеты (см. Приложения).
Рисунок 18. Вид окна конструктора отчетов
Рисунок 19. Отчет «Ведомость прихода на склад»
Отчет – это гибкое и эффективное средство для организации просмотра и распечатки итоговой информации. В отчете можно получить результаты сложных расчетов, статистических сравнений, а также поместить в него рисунки и диаграммы.
Ниже представлен образец отчета «Ведомость прихода на склад». При этом данные сгруппированы по поставщикам. В примечаниях группы отображается число поставок по каждому из поставщиков, а также общая сумма, на которую была поставлена продукция.
Заключение
Использование информационных технологий для управления предприятием делает любую компанию более конкурентоспособной за счет повышения ее управляемости и адаптируемости. Подобная автоматизация позволяет:
1. Повысить эффективность управления компанией за счет обеспечения руководителей и специалистов максимально полной, оперативной и достоверной информацией на основе единого банка данных.
2. Снизить расходы на ведение дел за счет автоматизации процессов обработки информации, регламентации и упрощения доступа сотрудников компании к нужной информации.
3. Изменить характер труда сотрудников, избавляя их от выполнения рутинной работы и давая возможность сосредоточиться на профессионально важных обязанностях.
4. Обеспечить надежный учет и контроль поступлений и расходования денежных средств на всех уровнях управления.
5. Руководителям среднего и нижнего звеньев анализировать деятельность своих подразделений и оперативно готовить сводные и аналитические отчеты для руководства и смежных отделов.
6. Повысить эффективность обмена данными между отдельными подразделениями, филиалами и центральным аппаратом. Гарантировать полную безопасность и целостность данных на всех этапах обработки информации.
В ходе выполнения курсовой работы был проведен анализ предметной области, касающийся вопросов движения материалов на складе. В результате проведенных исследований были выделены объекты данной предметной области, определены характеризующие их атрибуты и установлены структурные связи между ними.
Список использованной литературы
- Балдин К.В., Уткин В.Б. Информационные системы в экономике. М.–Издательский центр Академия, 2015 – 288 с.
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп.– М.: Финансы и статистика, 2016. – 544 с: ил.
- Информационные системы в экономике. Балдин К.В., Уткин В.Б.(2011,5-е изд., 395 с.)
- Лекции по РИСП
- Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: Диалог-МИФИ, 2015. – 304 с.
- Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. – М.: Диалог-МИФИ, 2012. – 224 с.
- Материалы сайта http://www.cyberforum.ru/
- Муромцев В.В. Проектирование информационных систем: Учебное пособие для студентов вузов заочной формы обучения по спец. 010502 «Прикладная информатика в экономике». — Белгород: БелГУ,2015.-160
- Смирнова Г.Н. Проектирование экономических информационных систем: Учебник для студентов экономических вузов, обуч. по спец.: «Прикладная информатика в экономике», «Прикладная информатика в менеджменте», «Прикладная информатика в юриспруденции». — М.: Финансы и статистика, 2013. — 511 с.
- СУБД Microsoft Access: Учебное пособие для вузов/Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова- М.: Горячая линия-Телеком,2014.
- Фаронов В. В. DELPHI 2015. Разработка приложений для баз данных и Интернета – СПб.: Питер, 2016 г.
1.http://idefdfd.ru/category/glava-3-strukturnyj-analiz-potokov-dannyx-dfd.html – Сайт «Моделирование и анализ систем. IDEF и DFD технологии»
2.http://region55.ru/ – Сайт ООО «ТНТ Трейдинг»
3.http://www.info-system.ru/designing/methodology/dfd/dfd_theory_dfd.html – Сайт «Проектирование и разработка автоматизированных, информационных и аналитических систем».
4.http://www.interface.ru/ca/bpwin4us.html – Сайт «BPwin 4.0».
5.http://www.lnau.lg.ua/inf_12.html – «Проектирование информационных систем».
6.http://www.studarhiv.ru/dir/cat32/subj45/file1411/view1411/page12.html – Stud Files.
При копировании любых материалов с сайта evkova.org обязательна активная ссылка на сайт www.evkova.org
Сайт создан коллективом преподавателей на некоммерческой основе для дополнительного образования молодежи
Сайт пишется, поддерживается и управляется коллективом преподавателей
Telegram и логотип telegram являются товарными знаками корпорации Telegram FZ-LLC.
Cайт носит информационный характер и ни при каких условиях не является публичной офертой, которая определяется положениями статьи 437 Гражданского кодекса РФ. Анна Евкова не оказывает никаких услуг.
"Системный анализ предметной области"
С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами.
В общем случае существуют два подхода к выбору состава и структуры предметной области:
Функциональный подход – реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
Предметный подход – когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач.
Чаще всего на практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.
Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД.
2. Инфологическое (семантическое) моделирование предметной области
Инфологическое моделирование (иногда используется термин семантическое моделирование) применяется на втором этапе проектирования БД, то есть после системного анализа предметной области. На этапе системного анализа были сформированы понятия о предметах, фактах и событиях, которыми будет оперировать БД. Инфологическое проектирование связано с представлением семантики предметной области в модели БД, т.е. моделирование структур данных, опираясь на смысл этих данных.
Наибольшее распространение получила модель "сущность-связь" (entity-relationship model, ER-модель).
Модель «сущность-связь» является концептуальной моделью, т.е. не учитывает особенности конкретной СУБД. Из модели "сущность-связь" могут быть получены все основные модели данных (иерархическая, сетевая, реляционная).
Основными понятиями модели "сущность-связь" являются: сущность, связь и атрибут. Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей.
Примеры сущностей: люди, лекарства, студенты и т.д.
Примеры экземпляров сущностей: конкретный человек, конкретное лекарственное средство, конкретный студент и т.д.
Сущности не обязательно должны быть непересекающимися. Например, экземпляр сущности СТУДЕНТ, также принадлежит сущности ЛЮДИ.
Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного объекта.
Атрибут должен иметь имя, уникальное в пределах данной сущности.
Рассмотрим множество лекарственных препаратов (ЛП), имеющихся в аптеке. Каждый ЛП можно представить следующими характеристиками: Код ЛП, Название ЛП, Срок хранения, Условия хранения.
В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида:
ЛП (Код ЛП, Название ЛП, Срок хранения, Условия хранения)
Например, поставщиков, поставляющих лекарства в аптеку, можно описать как:
Поставщики (Код поставщика, Название поставщика, Адрес)
Множество допустимых значений (область определения) атрибута называется доменом.
Например, атрибут Срок хранения хранит информацию о количестве дней, в течение которых продукт годен к употреблению. То есть этот атрибут принадлежит домену Количество дней, который задается интервалом целых чисел, больших нуля, поскольку количество дней отрицательным быть не может.
Набор атрибутов сущности должен быть таким, чтобы можно было однозначно найти требуемый экземпляр сущности.
Например, сущность Название ЛП однозначно определяется атрибутом Код ЛП, поскольку все коды лекарств различны.
Отсюда определяется ключ сущности — это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Пример 2. Сущность Продажа, с атрибутами Дата продажи, Код ЛП, Количество, Цена, содержит информацию о продаже лекарств за конкретный день.
Для этой сущности ключом будут атрибуты: Дата продажи и Код ЛП, поскольку за день могут быть проданы несколько ЛП, а конкретное ЛП может быть продано в разные дни. Исключение любого атрибута из ключа не позволит однозначно найти требуемый экземпляр сущности, т.е. будет нарушено условие минимальности.
Обозначим эту сущность как:
Продажа (Дата продажи, Код ЛП, Количество, Цена). Ключевой атрибут выделен подчеркиванием.
Между сущностями могут быть установлены связи.
Связь — это ассоциация, установленная между несколькими сущностями, и показывающая как взаимодействуют сущности между собой.
1) В аптеке происходит продажа ЛП, т.е. между сущностями ЛП и Продажа существует связь «происходит» или ЛП – Продажа. Обычно, но необязательно, связь обозначается глаголом или двойным названием сущностей, между которыми установлена эта связь.
2) Так как ЛП в магазин поставляют поставщики, то между сущностями ЛП и Поставщики существует связь «поставка» или ЛП – Поставщики.
3) Могут существовать и связи между экземплярами одной и той же сущности (рекурсивная связь), например связь Родитель — Потомок между экземплярами сущности Человек.
Связь также может иметь атрибуты. Например, для связи ЛП — Поставщики можно задать атрибуты Дата поставки, Цена и т.д.
Связь, существующая между двумя сущностями, называется бинарной связью.
Связь, существующая между n сущностями, называется n-арной связью.
Рекурсивная связь – это связь между экземплярами одной сущности. Доказано, что любую n-арную связь всегда можно заменить множеством бинарных, однако первые лучше отображают семантику предметной области.
Модель "сущность-связь" может быть представлена в виде графической схемы (диаграммы). Это значительно облегчает анализ предметной области.
Анализ предметной области
Анализ предметной области является первым этапом для проектирования баз данных (БД) любого типа. Заканчивается этот этап построением информационной структуры (концептуальной схемы). На данном этапе анализируются запросы пользователей, выбираются информационные объекты и их характеристики, которые предопределяют содержание проектируемой БД. На основе проведенного анализа структурируется предметная область. Анализ предметной области не зависит от программной и технической сред, в которых будет реализовываться БД.
Анализ предметной области можно разбить на три фазы:
1) анализ концептуальных требований и информационных потребностей;
2) выявление информационных объектов и связей между ними;
3) построение концептуальной модели предметной области и проектирование концептуальной схемы БД.
На этапе анализа концептуальных требований и информационных потребностей необходимо выполнить:
1) анализ требований пользователей к БД (концептуальных требований);
2) выявление имеющихся задач по обработке информации, которая должна быть предоставлена в БД;
3) выявление перспективных задач (перспективных приложений);
4) документирование результатов анализа.
Требование пользователей к разрабатываемой БД представляет собой список запросов с указанием их интенсивности и объемов данных. Здесь же выясняются требования к вводу, обновлению и корректировке информации. Требования пользователей уточняются при анализе имеющихся и перспективных задач.
Теперь обратимся непосредственно к нашей БД. Рассмотрим примерный вопросник, требования к БД при анализе различных предметных областей.
1. Какая документация и какого типа существует на данной кафедре?
2. В каком виде должно храниться документация?
3. Сбор шаблонов, необходимых для создания документов.
4. Какие объекты кроме документов должно храниться в базе, и какими свойствами должны обладать данные объекты?
5. По каким критериям должен проводиться поиск по базе?
6. Для кого предназначена БД?
Выполним анализ требований к БД.
Вопрос1. Для каких типов задач проектируется БД?
Ответ. 1. Информация о документах. 2. Информация о преподавателях. 3. Информация о студентах, участвующих в работе кафедры. 4.Информация о кафедрах, на которых преподаватели данной кафедры работают совместителями. 5. Информация об олимпиадах, проводимых преподавателями данной кафедры. 6. Информация о конференциях по данной кафедре. 7. Учет участия студентов в олимпиадах. 8. Учет участия студентов в конференциях. 9. Информация о возможных должностях преподавателей. 10. Информация о возможных ученых степенях преподавателей. 11. Информация о возможных ученых званиях преподавателей. 12. Информация о литературе, имеющейся на кафедре. 13. Информация об авторах. 14. Информация об издательствах. 15. Информация о научных работах преподавателей. 16. Информация о дисциплинах, преподаваемых в рамках кафедры. 17. Информация о рабочих программах по дисциплинам. 18. Информация о типе документации (приказ, заявление и т.п.). 19. Информация о типе литературы (пособие, учебник и т.п.). 20. Учет преподавателей по кафедрам. 21. Информация о курсовых работах. 22. Учет студентов по курсовым работам. 23. Информация о специальностях данного ВУЗа. 24. Информация о типе научных работ преподавателей.
Вопрос2. Какими информационными объектами характеризуются эти задачи?
Ответ. 1. Информационный объект: Документация. 2. Информационный объект: Преподаватели. 3. Информационный объект: Студенты. 4. Информационный объект: Кафедры. 5. Информационный объект: Олимпиады. 6. Информационный объект Конференции. 7. Информационный объект Учет олимпиад. 8.Информацинный объект Учет конференций. 9. Информационный объект Должности. 10. Информационный объект Тип ученых степеней. 11. Информационный объект Тип ученых званий. 12. Информационный объект Литература. 13. Информационный объект Авторы. 14. Информационный объект Издательства. 15. Информационный объект Научные работы преподавателей. 16. Информационный объект Дисциплины. 17. Информационный объект Рабочие программы. 18. Информационный объект Тип документации. 19. Информационный объект Тип литературы. 20. Информационный объект Учет преподавателей по кафедрам. 21. Информационный объект Курсовые работы. 22. Информационный объект Учет студентов по курсовым работам. 23. Информационный объект Специальности. 24. Информационный объект Тип научных работ преподавателей.
Вопрос3. Каким текущим запросам должны удовлетворять информационные объекты?
1. Название олимпиады, курсовой работы, конференции, рабочей программы, тип документации, типа литературы, типа научной работы и т.п..
2. ФИО преподавателя, автора, студента.
3. Ученое звание, ученая степень преподавателя.
4. Дата проведения олимпиады, конференции, защиты курсовой работы, создания документа, рабочей программы.
5. Адрес преподавателя, издательства.
6. Телефон преподавателя.
7. Номер группы студента.
8. Направление научной работы преподавателя.
Вторая фаза анализа предметной области состоит в выборе информационных объектов, заданий необходимых свойств для каждого объекта, выявления связей между объектами, определений ограничений, накладываемых на информационные объекты, типы связей между ними, характеристики информационных объектов.
При выборе информационных объектов следует ответить на следующие вопросы:
1. На какие классы можно разбить данные подлежащие хранению в БД?
2. Какое имя можно присвоить каждому классу данных?
3. Какие наиболее интересные характеристики (с точки зрения пользователя) каждого класса данных можно выделить?
4. Какие имена можно присвоить выбранным наборам характеристик?
В ходе выявления связей между информационными объектами следует ответить на следующие вопросы:
1. Какие типы связей между информационными объектами?
2. Какое имя можно присвоить каждому типу связей?
3. Каковы возможные типы связей, которые могут быть использованы впоследствии?
Далее следует задать ограничения на объекты и их характеристики. Под ограничением целостности обычно понимают логические ограничения, накладываемые на данные.
При выявлении условий ограничения целостности следует ответить на следующие вопросы:
1.Какова область значений для числовых характеристик?
2.Каковы функциональные зависимости между характеристиками одного информационного объекта?
3.Какой тип отображения соответствует каждому типу связей?
Каждую сущность в нашей БД зададим набором атрибутов (ключевые атрибуты подчеркнем):
1. Документация (код документации, название, тип, дата создания, текст);
2. авторы (код автора, Фамилия, Имя, Отчество);
3. дисциплины (код дисциплины, название);
4. кафедры (код кафедры, название);
5. должность (код, название);
6. издательства (код, название, город, улица, офис);
7. конференции (код, название, дата проведения, код литературы);
8. курсовая работа (код, название, код дисциплины, номер зачетки, код руководителя, дата защиты, оценка, текст, приложение);
9. литература (код, название, код автора, код издания, код типа, дата создания);
10. направление (код, название);
11. научные работы преподавателей (код, название, тип научной работы, код преподавателя, дата создания, направление, текст);
12. олимпиада (код, название, код дисциплины, дата проведения);
13. преподаватели (Инн преподавателя, фамилия, имя, отчество, телефон, адрес, код договора, дата рождения, код ученой степени, код ученого звания);
14. рабочие программы (код, название, код специальности, код дисциплины, дата создания, код составителя, текст);
15. специальности (код, название);
16. студенты (номер зачетки, Фамилия, Имя, Отчество, номер группы);
17. тип документации (код, название);
18. тип литературы (код, название);
19. тип научной работы (код, название);
20. тип ученого звания (код, название);
21. тип ученой степени (код, название);
22. учет конференций (код, номер зачетки, код конференции, тема доклада);
23. учет олимпиад (код, номер зачетки, код олимпиады, результат);
24. учет преподавателей по кафедрам (код, инн преподавателя, код кафедры, код должности).
Заключительная фаза анализа предметной области состоит в проектировании ее информационной структуры или концептуальной модели.
Концептуальная модель включает описание объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных. Концептуальная модель применяется для структурирования ПО с учетом информационных интересов пользователей системы. Она дает возможность систематизировать информационное содержание ПО и увидеть ее отдельные элементы. Концептуальная модель является представлением точки зрения пользователя на ПО и не зависит не от программного обеспечения СУБД, ни от технических решений.
Одной из распространенных моделей концептуальной схемы является модель «сущность — связь». Под сущность понимают основное содержание объекта ПО, о котором собирают информацию. Экземпляр сущности – конкретный объект. Например: Сущность – факультет, экземпляр сущности – Факультет математики и информационных технологий.
Сущность принято определять атрибутами – поименованными характеристиками. Чтобы задать атрибут в модели, ему надо присвоить имя и определить область допустимых значений. Одно их назначений атрибута – идентифицировать сущность.
При построении модели «сущность — связь» использую графические диаграммы. При этом обозначают: сущность – прямоугольниками, атрибуты — овалами, связи – ромбами. Так в данной базе хранится большое количество таблиц, для компактности связи будем отображать просто прямыми линиями.
Рассмотрим концептуальную схему БД «Документооборот кафедры» (рис.1.1) (в данной схеме не будем указывать атрибуты).
3. Пример анализа предметной области.
Рассмотрим небольшую фирму, основной деятельностью которой является мелкооптовая торговля. Планируется разработать для этого предприятия торговую автоматизированную систему. Будем действовать с примерным порядком, введенным в предыдущем разделе.
Начнем с построения общей модели предприятия. Выявленные функциональные области и процессы представим в виде следующей таблицы.
Перспективная кадровая политика
Учет основных средств
Учет торговых операций и результатов основной деятельности
Учет оплаты труда
Бизнес планирование, бюджетирование
Управление финансовыми ресурсами
Управление заказами (товарооборот)
Управление закупками (поставщики)
Рассмотрим подробнее технологический процесс управления заказами (товарооборот). Запишем основные действия в виде следующей таблицы.
Действия процесса товарооборота (операции)
Выписка счета на заказанный товар
Оформление счета на товар (подписи)
Выписка счета на погрузку и доставку
Оформление счета на услуги
Оплата счета клиенту
Оплата выставленного счета
Проверка оплаты по копии платежного поручения
Проверка оплаты в банке
Проверка оплаты в кассе
Определение даты отпуска и резервирование товара
Резервирование транспорта и грузчиков
Прием денег от клиента и выписка приходного ордера
Выписка накладной на отпуск
Оформление накладной (подписи)
Выписка требования на складах
Выписка счета-фактуры на отпуск
Регистрация счета-фактуры в книге продаж
Выдача документов клиенту
Отпуск товара на складе
Выдача документов экспедитору
Погрузка и отправка товара
Напоминание об оплате
Исследуем динамику процесса товарооборота с рассмотрением участников операций, используемой информации и документов.
К торговому менеджеру обращается клиент, желающий приобрести товар. Клиент может обратиться лично — появившись в офисе: или заочно — по телефону. по электронной почте, письмом и т.п.
Менеджер собирает всю информацию, которая нужна для удовлетворения потребностей клиента, для выписки необходимых документов (счета, накладной, заявки на резервирование товара на складе и др.) и для выполнения операций по выполнению заказа клиента. Далее он производит эти операции, набор которых зависит в первую очередь от формы оплаты товара, а также от того, лично или заочно обращался клиент. Ограничимся следующими формами оплаты:
I — безналичная предоплата.
II — оплата наличными при получении товара;
III — с отсрочкой платежа на определенный срок.
Безналичная предоплата. При заочном обращении менеджер проделывает следующие операции. Выписывает в бухгалтерии счет на заказанный товар и. при необходимости. за услуги по погрузке и доставке товара. Отправляет клиенту счет сам или отдает для отправки секретарю или курьеру. (Отправка обычно производится по факсу, однако бывает и доставка с курьером). Ожидает оплаты выставленного счета. Здесь возможны два варианта.
Для надежных клиентов (точнее, надежных банков) в качестве подтверждения оплаты принимается копия платежного поручения. В этом случае об оплате обычно сообщает клиент, пересылая копию платежки по факсу или передавая ее лично при получении товара. В основном же подтверждением оплаты является приход денег на счет фирмы, о чем менеджеру сообщает бухгалтерия. Тогда если клиент не звонит сам, что бывает крайне редко. о приходе денег сообщает ему менеджер.
В обоих случаях после подтверждения оплаты менеджер совместно с клиентом определяют день и время отпуска товара, для чего менеджер должен узнать, имеются ли на складе нужные товары, и зарезервировать соответствующее количество. Если доставка товара производится фирмой, менеджер должен также зарезервировать транспорт и грузчиков. Для отпуска товара менеджер должен выписать в бухгалтерии накладную на отпуск товара в 2-х экземплярах, получить на ней подписи ответственного лица и главного бухгалтера, а также поставить печать фирмы. Также он выписывает требование на склад. Кроме накладной необходимо также выписать счет-фактуру на отпуск товара с занесением ее в книгу продаж. Если клиент получает товар самовывозом, то ему выдаются все вышеперечисленные документы и он отправляется на склад. При доставке товара клиенту эти документы выдаются экспедитору, который доставляет товар клиенту. При очном обращении клиента и безналичной предоплате все вышеприведенные операции остаются, за исключением отправки счета, он вручается клиенту.
Наличная оплата. Заочное обращение клиента. Определение дня и времени отпуска товара. Резервирование товара на складе. Резервирование при необходимости транспорта и грузчиков. Отпуск товара. Выписка накладной, требования на склад и счет-фактуры. Организация получения кассиром наличных денег с выдачей клиенту приходного ордера.
Если клиент получает товар самовывозом, то ему выдаются все вышеперечисленные документы, и он отправляется на склад.
При доставке товара клиенту, после получения документов клиент либо сопровождает доставляемый товар, либо отправляется по своим делам, а товар доставляет экспедитор.
Очное обращение клиента. Определение наличия товара на складе При отсутствии клиенту приходится отказывать или оговаривать его прийти в следующий раз. Если клиент соглашается, то выполняется та же последовательность операций, что и в случае заочного обращения. Отпуск товара. Выписка накладной, требования на склад и счет-фактуры. Организация получения кассиром наличных денег с выдачей клиенту приходного ордера.
Если клиент получает товар самовывозом, то ему выдаются все вышеперечисленные документы, и он отправляется на склад.
При доставке товара клиенту, после получения документов клиент либо сопровождает доставляемый товар. либо отправляется по своим делам, а товар доставляет экспедитор.
Оплата с отсрочкой платежа. Определение дня и времени отпуска товара. Резервирование товара на складе. Резервирование при необходимости транспорта и грузчиков. Отпуск товара. Выписка накладной, требования на склад и счет-фактуры.
Если клиент получает товар самовывозом, то ему выдаются все вышеперечисленные документы, и он отправляется на склад.
При доставке товара клиенту, после получения документов клиент либо сопровождает доставляемый товар. Либо отправляется по своим делам, а товар доставляет экспедитор.
Контроль своевременной оплаты полученного товара. Отпуск товара с отсрочкой платежа производится обычно для постоянных клиентов, с которыми существует постоянный договор, определяющий длительность отсрочки и пеня за просрочку платежа. Контроль сводится к проверке по бухгалтерии прихода соответствующих денег на счет и напоминанию клиенту, что срок оплаты заканчивается. В ряде случаев, по договоренности, оплата ведется по частям в течении всего оговоренного срока, тогда необходимо отслеживать несколько последовательных поступлений денег. Иногда оплата производится наличными. Очевидно, случай очного обращения ничем не отличается от заочного, мало того, постоянный клиент вряд ли свалится на голову неожиданно.
Как видно, относительно простая задача требует достаточно многословного описания, а ведь еще предстоит разбираться с информацией. Чтобы сократить его, далее сразу будем обобщать результаты анализа, оставляя только краткие пояснения.
Прежде чем перейти к анализу необходимой для процесса продажи информации, попытаемся обобщить уже имеющиеся данные. Нетрудно видеть, что большинство операций в различных вариантах продаж идентичны. Попробуем свести полученные данные по операциям продажи в таблицу (см. табл. 3)