Наименование
|
Область применения,
описание
|
Финэко
|
Учет операций с банком
обслуживания.
|
WinRar 3.41
|
Программа-архиватор
|
Microsoft Visual FoxPro 6.0
|
Система управления базами
данных.
|
Существующие программные продукты позволяют автоматизировать малую долю
всех функций оперативного учета продаж и закупок продовольственных товаров. При
этом отсутствует возможность предоставления отчетов для принятия управленческих
решений в сфере прогнозирования состояния рынка товаров продовольственного
назначения, отсутствует единая база поставщиков и покупателей. В рамках ИП
Быкова Л.Ф. ведется учет движения товаров в бумажной форме, что не позволяет
контролировать остатки товаров на складах и в торговых точках.
Большой объем информации в ИП Быкова Л.Ф. хранится и обрабатывается с
использованием табличного процессора Microsoft Excel
2003. Файловая структура информационного хранилища усложняет контроль
целостности имеющейся информации, усложняет построение аналитических отчетов.
.1.8 Анализ проблемных ситуаций ИП Быкова Л.Ф. и обоснование
путей их решения
Основным недостатком для ИП Быкова Л.Ф. в области учета поставок и продаж
продовольственных товаров является ведение оперативного учета с использованием
бумажных носителей, и, как следствие, использование имеющейся в распоряжении
отдела вычислительной техники с максимальной эффективностью не представляется
возможным.
Большую часть рабочего времени занимают трудоемкие операции отбора
первичных документов по определенным критериям. Таким образом, учет каждой
отдельной оптовой или розничной операции представляет трудоемкую задачу и
занимает значительное время.
На базе имеющегося технического обеспечения ИП Быкова Л.Ф. можно
организовать автоматизированный учет закупок и продаж товаров
продовольственного назначения. Для этого рекомендуется разработать программное
обеспечение, позволяющее оперативно отображать факты совершения сделок, а также
хранить некоторые временные данные в разрезе складов, пунктов реализации,
товарных групп.
Для повышения оперативности получения информации о материальных остатках,
необходимо организовать долговременное хранение информации, как об остатках
товаров, так и о движении материальных ценностей.
При ведении учета движения продовольственных товаров с использованием
бумажных носителей, как в ИП Быкова Л.Ф., невозможно интегрировать данные об
остатках и оборотах в финансовом и товарном выражениях. Длительное время
занимает процесс получения агрегирующих показателей по различным товарным
группам, за различные промежутки времени.
Но при использовании информационной базы данных становится возможной
реализация интегрированного хранилища информации о количестве товаров, истории
сделок, движении товаров, сотрудниках, поставщиках, оптовых и розничных
покупателях ИП Быкова Л.Ф.
Требования к проекту, сформулированные заказчиком:
. Информационная подсистема для ИП Быкова Л.Ф. по учету закупок реализации
продовольственной продукции предназначена для автоматизации учета всех торговых
операций ИП Быкова Л.Ф.
. Информационная подсистема разрабатывается на основе информационной
базы, которая предназначена для хранения следующей информации:
а) количество товаров на различных складах;
б) сделки во временном разрезе по всем товарам;
г) заказчики предприятия;
г) сотрудники предприятия;
д) основные документа опосредующие сделки;
е) магазины ИП Быкова Л.Ф.
. Необходимо обеспечить добавление, удаление и модификацию информации для
следующих объектов предметной области:
а) товары;
б) товарные группы;
в) сотрудники;
г) покупатели, поставщики;
д) документы;
. Необходимо реализовать расчет агрегирующих показателей в натуральном и
денежном выражении в разрезе складов, товарных групп, магазинов за указанный
пользователем промежуток времени.
. Необходимо разработать отчеты, отражающие информацию о наличии товаров
на складах ИП Быкова Л.Ф., о движении товаров за указанный период, об истории сделок
с указанными поставщиками или оптовыми покупателями.
. Разрабатываемая система должна иметь графический интерфейс и работать в
среде Microsoft Windows XP и выше.
1.2 Формулировка задач проектирования
.2.1 Общие сведения о проекте
Полное наименование разрабатываемой подсистемы: Информационная подсистема
учета закупок и реализации продовольственной продукции для ИП Быкова Л.Ф.
Условное обозначение подсистемы: ИП УЗРПП.
Заказчик: индивидуальный предприниматель Быкова Л.Ф.
Адрес заказчика: 355000, г. Ставрополь, ул. Заводская, 7.
Исполнитель: Северо-Кавказский гуманитарно-технический институт в лице
разработчика Куценко Алексея Вениаминовича.
Адрес исполнителя: Ставропольский край, 355029, г. Ставрополь, пр.
Кулакова, 8.
Плановый срок выполнения работ по разработке информационной подсистемы
учета закупок и реализации продукции: 12 апреля 2010 г. - 24 мая 2010 г.
Работы по проектированию информационной подсистемы выполняются
инициативно без оплаты.
1.2.2 Назначение, цели создания информационной подсистемы
Информационная подсистема для учета закупок и реализации
продовольственной продукции для ИП Быкова Л.Ф. предназначена для автоматизации
учета оптовых и розничных операций закупки и реализации продовольственной
продукции.
Подсистема должна обеспечить единую информационную инфраструктуру для
сотрудников различных структурных подразделений ИП Быкова Л.Ф. с целью
повышения оперативности учета торговых операций и формирования отчетности.
Целью создания ИП УЗРПП является автоматизация учета продовольственной
продукции: от заключения торговых договоров с контрагентами до штучного учета
розничной продукции, в том числе:
1. Повышение оперативности учета торговых операций с продовольственными
товарами.
2. Введение в практику учета возможности многокритериального и оперативного
отбора требуемых документов, магазинов, товаров, покупателей и поставщиков, что
является невозможным при ведении учета с использованием бумажных носителей
информации.
. Обеспечение возможности для сотрудников ИП Быкова Л.Ф. при
работе с программой самостоятельно определять группы товаров и места хранения.
. Обеспечение автоматического контроля непротиворечивости данных
при ведении учета операций с продовольственными товарами.
. Помимо ведения учета торговых операций, реализовать
информационную базу, позволяющую оперативно получать информацию о сотрудниках,
поставщиках, покупателях, остатках товаров.
. Интеграция информации о первичных документах, сделках, пунктах
розничной продажи, складах и товарах в едином хранилище.
. Обеспечение возможности получать информацию не только об
остатках продовольственных товаров и денежных средств, но и о соответствующих
оборотах за указанные пользователем периоды времени.
Диаграмма вариантов использования информационной подсистемы представлена
на рисунке В.1.
.2.3 Характеристика объекта автоматизации
Индивидуальный предприниматель Быкова Л.Ф. (ИП Быкова Л.Ф.) является
субъектом предпринимательской деятельности и действует с 20 июня 2006 года на
основании свидетельства о государственной регистрации субъектов предпринимательской
деятельности.
Адрес регистрации индивидуального предпринимателя Быкова Л.Ф.: 355000, г.
Ставрополь, ул. Заводская, 7.
ИП Быкова Л.Ф. ведет свою деятельность на постоянной основе, имеет
деловых партнеров, работает непрерывно, выполняет требования действующего
законодательства.
Основная деятельность ИП Быкова Л.Ф. заключается в осуществлении оптовой
и розничной торговли продуктами питания, табачными и ликероводочными изделиями.
Коммерческая деятельность осуществляется на основании разрешающих лицензий
государственной налоговой службы РФ.
Ведется активная работа с поставщиками продукции, постоянно формируются
заказы на товары для дальнейшего их приобретения и реализации. ИП Быкова Л.Ф.
осуществляет свою деятельность с целью удовлетворения спроса на продукты
питания.
На протяжении двух лет индивидуальный предприниматель Быкова Л.Ф.
осуществляет успешную деятельность на рынке Ставропольского края. В настоящее
время ИП Быкова Л.Ф. располагает сетью магазинов по реализации
продовольственных товаров.
1.2.4 Требования к информационной подсистеме
Общими для системы являются следующие требования:
1. Подсистема должна содержать необходимый объем информации, набор
сервисов для работы с данными, обеспечивающий требуемую полноту информационных
услуг по учету закупок и реализации продовольственной продукции.
2. Структура представления информации и пользовательские интерфейсы
по доступу к системе и сервисам должны быть интуитивно понятны широкому кругу
пользователей.
. Пользовательский интерфейс должен обеспечивать выбор типового
профиля в соответствии с группами пользователей.
При проектировании ИП УЗРПП должно быть учтено следующее:
1. Перспектива дальнейшего расширения информационной подсистемы в единую
сетевую информационно-коммуникационную инфраструктуру ИП Быкова Л.Ф.,
охватывающую все торговые и складские объекты.
2. Уровень готовности потенциальных пользователей к использованию
информационной подсистемы.
. Необходимость обеспечения гибкости и оперативности в настройке и
модернизации информационной подсистемы как на уровне администрирования, так и в
пользовательском режиме.
Основными принципами создания ИП УЗРПП являются:
1. Высокая степень масштабируемости программных и аппаратных средств.
2. Использование лицензионного программного и аппаратного
обеспечения.
. Использование общепризнанных и широко используемых стандартов
структурирования информации и описания сервисов.
Разрабатываемая информационная подсистема для учета закупок и реализации
продовольственной продукции должна обладать следующими функциональными
возможностями:
1. Навигация. Система должна обеспечивать навигацию по всем доступным
пользователю ресурсам и отображать соответствующую информацию. Для навигации
должна использоваться система главного и контекстного меню. Интерфейс должен
обеспечивать возможность фильтрации отображаемой информации по требуемым
параметрам.
2. Наполнение информацией. Необходимо предоставить пользователям ИП
УЗРПП возможность формировать информационную базу самостоятельно в режиме
эксплуатации системы в соответствии с предоставленными правами.
. Разграничение прав доступа. ИП УЗРПП должна обеспечивать
возможность указания в режиме администрирования прав доступа для каждого
пользователя.
. Формирование отчетности. Необходимо разработать отчеты в
соответствии с формами, действующими в ИП Быкова Л.Ф.
. Автоматизация трудоемких операций. Необходимо обеспечить
автоматический расчет агрегирующих показателей в денежном и натуральном
выражении в разрезе товаров, торговых объектов, складов.
Требования к математическому обеспечению не предъявляются.
Информационная подсистема должна удовлетворять следующим требованиям к
информационному обеспечению:
должна быть совместима со всеми современными стандартами сетевого
администрирования;
должна иметь резерв наращивания функциональных возможностей, не выходя за
рамки принятой информационной модели и специфических потребностей
пользователей;
должна работать в графических операционных системах (рекомендуется
Windows XP и выше);
должна разрабатываться с применением реляционных систем управления базами
данных (рекомендуется MS SQL Server 2005 Express Edition).
документы, представленные в подсистеме в электронной форме, не имеют
юридической силы, а придание юридической силы документу осуществляется выводом
его на бумажный носитель средствами системы и визированием его соответствующим
должностным лицом;
все разрабатываемые модули подсистемы должны функционировать на основе
общесистемных сервисов операционных систем семейства Microsoft Windows.
Требования к техническому обеспечению определяются рекомендуемыми
требованиями к программному и информационному обеспечению.
1.2.5 Состав и содержание работ по созданию подсистемы
Состав и содержание работ по разработке информационной подсистемы
определяются целями создания подсистемы и совокупностью задач, подлежащих
автоматизации.
На рисунке 1.4 представлены основные функциональные области
разрабатываемого программного обеспечения, взаимосвязи между ними и задачи,
решаемые в каждой из областей.
Рисунок 1.4 - Функциональная структура программного продукта
В состав функциональной структуры входят четыре основные функциональные
области, которые объединяют задачи:
реализация управления средой данных;
реализация взаимодействия с операционной системой;
реализация интерфейса с пользователем;
реализация компонентов, реализующих взаимодействие среды данных и
интерфейса.
При практической реализации функциональные области представлены
отдельными модулями, библиотеками функций, файлами. В соответствии с
функциональной структурой выделим следующие этапы создания информационной
подсистемы:
. Проектирование базы данных. На данном этапе необходимо выделить
подмножество объектов и явлений предметной области, которые необходимо учитывать
при проектировании программного продукта. Необходимо также рассмотреть
взаимосвязи, существующие между этими объектами.
. Создание базы данных в среде конкретной системы управления базами
данных (СУБД), создание таблиц, триггеров, представлений и диаграммы.
. Разработка компонентов для реализации взаимодействия между
пользовательским представлением информационной базы данных и реальными
объектами, присутствующими в базе данных. На данном этапе осуществляется
проектирование общей структуры клиентского приложения, выбирается технология
доступа к данным.
. Разработка интерфейса пользователя и пользовательских представлений.
Данный этап будет реализовываться с учетом инструментария разработки.
Фактически, цель первого этапа - проектирование информационной базы
данных, второго - реализация базы данных в среде СУБД. Цель третьего и
четвертого этапов - построение на основе разработок первых двух этапов
пользовательского приложения, отвечающего требованиям к программному продукту
со стороны заказчика.
.2.6 Порядок контроля приемки подсистемы
Процедура контроля и приемки информационных подсистем состоит из
следующих этапов:
1. Определение состава приемочной комиссии. В состав комиссии входят
представители заказчика, связанные с учетом реализации сельскохозяйственной
продукции.
2. Установка и настройка программного обеспечения информационной
подсистемы.
. Проведение соответствующих испытаний (конкретный вид, состав и
объем испытаний определяется заказчиком).
. Обучение пользователей.
. Опытная эксплуатация ИП УЗРПП должна проводиться на площадке
исполнителя, приёмочные испытания - на объекте автоматизации заказчика.
Результаты работы комиссии должны оформляться актом апробации,
подписанным членами комиссии и утверждённым заказчиком.
Результаты внедрения информационной подсистемы оформляются актом
внедрения, подписанным членами комиссии и утверждённым заказчиком.
1.2.7 Требования к составу и содержанию работ по подготовке
объекта автоматизации
Информационная подсистема создается на базе имеющихся технических средств.
Организационные мероприятия ограничивается проведением консультаций с
персоналом, непосредственно задействованным в работе с информационной
подсистемой.
Изменения в информационном обеспечении состоят в следующем:
необходимо установить Microsoft .NET Framework 2.0 и выше (бесплатный компонент
операционной системы).
на одном из компьютеров необходимо установить и настроить СУБД Microsoft SQL Server 2005 Express Edition.
для предоставления возможности администратору системы исправления
исходных кодов программных модулей на каждом рабочем месте необходимо
установить Microsoft Visual Studio 2005 Express Edition.
1.2.8 Требования к документированию
Разработчиком ИП УЗРПП предоставляется:
пояснительная записка к курсовому проекту, база данных, исходные тексты программных
модулей в электронном виде на CD-ROM;
руководство пользователя ИП УЗРПП;
руководство администратора ИП УЗРПП.
.2.9 Источники разработки
Источником разработки ИП УЗРПП являются:
материалы отчета по преддипломной практике;
образцы форм первичных документов ИП Быкова Л.Ф.;
образцы форм отчетов ИП Быкова Л.Ф.
Выводы
В результате обследования ИП Быкова Л.Ф. сформулированы следующие выводы:
. ИП Быкова Л.Ф. является субъектом экономической деятельности с
простой организационной структурой. Предприятие имеет обширную сферу
деятельности, то есть сложную функциональную структуру. Малое предприятие
развивается в условиях рыночной экономики, имеет большое количество деловых
партнеров. Сферой деятельности ИП Быкова Л.Ф. является оптовая и розничная торговля
продовольственными товара. Предприятие характеризуется сложным
документооборотом и широким товарным ассортиментом.
2. Оперативное получение информации о наличии остатков товаров на
складах предприятия и об оборотах в денежном и натуральном выражениях является
необходимым условием функционирования торгового предприятия в условиях
современного рынка. Поэтому для повышения эффективности функционирования
предприятия в целом необходимо разработать информационную подсистему учета
закупок и реализации продовольственной продукции. Это позволит существенно
ускорить формирование отчетности и автоматизировать учет операций купли-продажи
товаров.
. Для разработки информационной подсистемы учета торговли
продовольственными товарами необходимо решить следующие задачи:
3.1 Разработать информационную базу данных.
3.2 Разработать клиентское приложение с графическим интерфейсом для
обеспечения эргономичной работы пользователей с единым информационным
хранилищем.
.3 Разработать формы отчетов в соответствии с требованиями к
проектированию, позволяющие получать информацию о текущем состоянии товаров на
складах колхоза и об истории сделок за определенные временные периоды.
2. Разработка информационной подсистемы учета закупок и
реализации продовольственной продукции для ИП Быкова Л.Ф.
2.1 Разработка базы данных
2.1.1 Построение логической модели базы данных
Для построения логической модели необходимо выявить сущности предметной
области, а также определить перечень атрибутов, характеризующих каждую
сущность. Объекты и процессы предметной области взаимосвязаны, следовательно,
при логическом проектировании учитываются связи между сущностями.
Построение логической модели осуществляется с использованием программного
продукта ERwin 4.0. Модель строится в нотации IDEF1X (Integration DEFinition for Information Modeling).
Основным объектом в сфере торговле продуктами питания является сущность
«Товар».
Перечень атрибутов для данной сущности представлен на рисунке 2.1
Рисунок 2.1 - Определение сущности «Товар» в среде Erwin 4.0
Для предметной области также характерны сущности «Поставщик» и
«Покупатель». Вид сущностей в среде проектирования Erwin 4.0 и их атрибутивный состав представлены на рисунке
2.2.
а) б)
Рисунок 2.2 - Сущности контрагентов в среде проектирования ERwin 4.0: а) «Покупатель» б) «Поставщик»
При определении атрибутивного состава сущностей, приведенных на рисунке
2.2, учитывается тот факт, что поставщиками продовольственных товаров являются
преимущественно организации и предприятия, следовательно, вводятся атрибуты,
позволяющие описать и идентифицировать данный объект предметной области как
юридическое лицо.
Продажа продовольственных товаров осуществляется преимущественно через
розничную сеть, поэтому, сущность «Покупатель» характеризуется только
атрибутами, характерными для физического лица.
Субъектами предметной области являются не только контрагенты ИП Быкова
Л.Ф., но и сотрудники организации, которые являются ответственными лицами при
оформлении сделок купли-продажи продовольственных товаров. Атрибутивный состав
сущности «Сотрудник» представлен на рисунке 2.3:
Рисунок 2.3 - Атрибутивный состав сущности «Сотрудник»
Для создания логической модели необходимо определить связи между
сущностями, выявленными при анализе предметной области. Предварительная
логическая модель приводится на рисунке 2.4:
Рисунок 2.4 - Связи между сущностями логической модели
Все связи определены как «многие ко многим» (М:М), то есть один поставщик
может продать множество различных товаров, и каждый товар может быть поставлен
различными поставщиками. Для связи между сущностями «Товар» и «Сотрудник» связь
типа М:М означает: каждый сотрудник участвует в оформлении многих товаров, и
каждый товар может быть оформлен различными сотрудниками.
2.1.2 Нормализация логической модели
Логическая модель, представленная на рисунке 2.4 нуждается в дальнейшей декомпозиции
с целью приведения сущностей в нормальную форму Бойса-Кодда (достижение
четвертой нормальной формы не целесообразно).
Перед процессом нормализации необходимо определит группы атрибутов
уникальным образом идентифицирующие отдельные экземпляры сущностей, то есть
первичные ключи. Для каждой сущности вводится простой первичный ключ, не
имеющий смыслового содержания в рамках предметной области (так называемый
искусственный идентификатор). Данный прием в выборе первичного ключа позволяет
повысить устойчивость базы данных за счет исключения противоречивости данных.
Для обеспечения непротиворечивости данных и сокращения избыточности
вводятся дополнительные отношения «Договор поставки» и «Договор продажи». Это
позволяет избежать многократного повторения данных о поставщиках и покупателях,
а также свести связи типа «многие ко многим» к связям «один ко многим» (связи
многие ко многим не реализуются в среде СУБД). Первичные ключи данных сущностей
также определяются как искусственные идентификаторы.
После декомпозиции атрибутов до атомарного состояния область,
представляемая сущностями «Покупатель-Товар-Поставщик», будет представлена
диаграммой, показанной на рисунке 2.5:
Рисунок 2.5 - Часть логической модели после удаления связей типа М:М
Все связи в модели на рисунке 2.5 приведены к типу 1:М («один ко
многим»).
На рисунке 2.5 не каждая сущность приведена к первой нормальной форме, а
именно: отношение «Сотрудник» содержит атрибуты «Отдел» и «Должность», которые
будут повторяться для различных записей. Следовательно, производится
декомпозиция данного отношения. Вводятся элементы, отражающие штатную структуру
предприятия: отношения «Должность» и «Отдел». В каждой сущности определяются
искусственные первичные ключи, определяются связи типа 1:М между ними (рисунок
2.6).
В реализованной логической модели присутствуют атрибуты, которые вносят
избыточность, то есть значения данных атрибутов будут повторяться для различных
записей. Кроме того, для отражения документов достаточно одной сущности
«Документ», поэтому нет необходимости вводить отношения «Договор поставки» и
«Договор реализации». Для отражения функциональной направленности документа
необходимо определить отношение «Тип документа». Для документов характерны
заголовочная часть и спецификация, отражающая предмет договора, перечень
товаров по счету-фактуре, перечень закупаемых товаров. Следовательно,
необходимо создать отношение «Спецификация документа».
Рисунок 2.6 - Часть логической модели, отражающая штатную структуру
предприятия.
Для ведения учета в разрезе валют вводится отношение «Валюта», связанное
с отношением «Спецификация». Каждая запись отношения «Спецификация»
представляет отдельную позицию в товарной номенклатуре. Торговля продовольственными
товарами отличается широкой номенклатурой. Поэтому для удобства пользователя
вводятся отношения «Товарная группа», «Единица измерения», «Склад». Данные
отношения позволяют упорядочить элементы товарной номенклатуры и более точно
отразить особенности ведения учета на предприятии ИП Быкова Р.Г. в
информационной подсистеме.
Для ведения учета в разрезе видов расчетов вводится отношение «Тип
расчета». Часть логической модели, отражающая сущности связанные с процессом
документооборота представлена на рисунке 2.7
Рисунок 2.7 - Часть логической модели, отражающая документооборот.
На рисунке 2.7 для сущностей «Товар», «Контрагент» и «Сотрудник»
представлены только атрибуты первичного ключа.
На рисунке 2.8 представлена часть логической модели, отражающая товарный
ассортимент ИП Быкова Р.Г. в базе данных.
Рисунок 2.8 - Часть логической модели, отражающая товарный ассортимент ИП
Быкова Р.Г.
На данном этапе проектирование логической модели завершено. Полная
логическая модель представлена на рисунке Г.1.
2.1.3 Выбор системы управления базами данных для реализации
физической модели
На данном этапе осуществляется перенос логической модели данных в среду
целевой СУБД. При выборе СУБД учитывается объем хранимых данных, частота и
характер операций при обращении к базе данных, а также операционная система,
которая установлена на компьютере конечного пользователя.
Для оперативного учета операций реализации продукции продовольственного
назначения рассматриваются реляционные СУБД:
- Microsoft Access 2003;
Microsoft Visual FoxPro 9.0;
- Microsoft SQL Server 2005.
Выбор данного программного обеспечения продиктован необходимостью
разработки приложения, совместимого с операционными системами семейства Microsoft Windows (версии Windows XP Professional и выше). Следует отметить, что все
СУБД являются коммерческими, разрабатываются одной компанией и обладают высокой
степенью интеграции с большинством сервисов операционных систем семейства Windows.
Все СУБД отличаются по спектру функциональных возможностей, кругу
решаемых с их помощью задач, области применения и стоимости.
Для СУБД Microsoft Access 2003 характерны следующие
достоинства:
. Высокая степень интеграции с офисными приложениями MS Office, что позволяет строить сложные отчеты непосредственно
в Excel или Word.
2. Простота развертывания приложений на основе данной СУБД.
. Наличие встроенного языка (диалекта SQL и языка высокого уровня VBA).
. Наличие средств разработки пользовательского интерфейса, что
позволяет сконцентрировать всю работу по сознанию программного продукта в
рамках одной СУБД.
Основным недостатком СУБД Microsoft Access является
низкая производительность и отсутствие поддержки многопользовательского режима.
Данные ограничения позволяют использовать базы данных Access как локальное хранилище небольших объемов информации.
Данная СУБД не отвечает требованию масштабируемости информационной подсистемы,
заявленным в техническом задании.
СУБД Microsoft Visual FoxPro 9.0 позволяет реализовать все, поставленные на этапе
составления технического задания цели и задачи, но обладает рядом существенных
недостатков;
. Плохая масштабируемость программ, разработанных с использованием СУБД
Visual FoxPro. Это объясняется наличие собственных встроенных
языков: диалекта SQL и
высокоуровневого объектно-ориентированного языка для создания интерфейса и
бизнес-классов.
2. Особенности используемого диалекта SQL не позволяют использовать все возможности языка
структурированных запросов.
СУБД Microsoft SQL Server 2005 представляет собой один из самых
производительных серверов баз данных. Основным недостатком является стоимость
использования (оплата производится за каждое подключение и каждый физический
процессор, задействованный на сервере). Существует версия СУБД Microsoft SQL Server 2005 Express Edition, которая
позволяет использовать данный сервер баз данных бесплатно с незначительными
ограничениями.
Для обеспечения высокой производительности, возможности интеграции со
всеми сервисами операционных систем Windows, свободы выбора средств разработки клиентского приложения
для работы с базой данных (большинство производителей сред разработки реализуют
всестороннюю поддержку данного сервера баз данных) в качестве СУБД выбрана Microsoft SQL Server 2005.
2.1.4 Разработка физической модели базы данных
Для переноса логической модели базы данных в среду Microsoft SQL Server 2005 для каждого отношения создается таблица базы
данных. В каждой таблице определяются столбцы (атрибуты), тип атрибута, длина,
допустимость пустых значений.
Первичный ключ каждой таблицы представлен целым числом. Установка типа
индекса как Primary (первичный) по ключевому атрибуту не
позволит создать в любой таблице двух записей с одинаковыми значениями
первичного ключа.
Создание внутренней модели предполагает определение триггеров и типов
связей между таблицами. Все связи, установленные между таблицами запрещают
удаление записей в родительской таблице в случае наличия дочерних записей.
Аналогичным образом проверяется родительская таблица на наличие первичного
ключа при вставке записи в дочернюю таблицу.
Перечень таблиц базы данных с описанием атрибутов, их типов и назначения
приводится в приложении Д. Физическая модель базы данных представлена на
рисунке Е.1.
2.2 Разработка клиентского приложения для работы с базой
данных
2.2.1 Выбор среды разработки для создания клиентского
приложения
Для разработки клиентского приложения используется интегрированная среда
разработки MS Visual Studio 2005 Express Edition.
Разработка ведется с использованием объектно-ориентированного языка C# (C Sharp). В процессе разработки используются возможности .NET Framework версии 2.0. Данные программные
средства позволяют создавать сложные приложения для работы с базами данных в
кратчайшие сроки. Это обусловлено следующими особенностями MS Visual Studio 2005 Express Edition:
1 Высокая степень интеграции с сервисами операционной системы Windows (в том числе с сервером MS SQL Server);
2 Развитые средства создания графического интерфейса пользователя.
Развитые средства взаимодействия с источниками данных различных
СУБД;
Широкие возможности по созданию бизнес-классов, представляющих
объекты базы данных (таблицы, связи).
Современные высокопроизводительные технологии работы с данными
(технология отсоединенного источника данных).
Полная совместимость типов с СУБД MS SQL Server 2005.
Широкие возможности мастеров данных по созданию пользовательских
приложений, ориентированных на работу с базами данных.
На современном этапе развития интегрированных сред разработки MS Visual Studio является оптимальным вариантом для создания не только
отдельных приложений, но и программных комплексов, ориентированных на
использование в распределенной среде.
Платформа .NET представляет
набор пространств имен ADO.NET для работы с данными из удаленных источников.
При разработке приложения в среде MS Visual Studio 2005 Express Edition работы выполняются в следующей последовательности:
. Создание графического интерфейса (включая специализированные
графические компоненты для представления данных).
. Разработка бизнес-классов приложения для отображения основных объектов
базы данных в проекте C#.
. Создание объектов-соединений, обработка событий, наполнение данными,
подключение визуальных элементов управления к объектам данных.
2.2.2 Создание графического интерфейса
В качестве каркаса приложения используется MDI-приложение (многодокументальное приложение). В
соответствии с данным подходом необходимо разработать главную форму приложения
и дочерние формы. Все формы разрабатываются на основе класса Form пространства имен System.Windows.Forms.
Форма главного окна (класс MDIParent) представляет собой окно верхнего уровня, для которого свойство IsMdiContainer установлено в значение null.
Все дочерние формы являются окнами, для которых свойство MdiParent ссылается на объект формы главного
окна.
Для формы главного окна разработано главное меню, с помощью команд
которого осуществляется вызов дочерних окон, управление ими и приложением в
целом.
На рисунке 2.9 представлена главная форма приложения в режиме
проектирования, показаны команды одного из пунктов главного меню.
Рисунок 2.9 - Главная форма приложения в режиме проектирования
Дочерние окна вызываются с использование команд главного меню и имеют
различную структуру, в зависимости от объектов данных, которые они отображают.
На рисунке 2.10 представлена дочерняя форма справочника «Контрагенты» в режиме
проектирования.
Рисунок 2.10 - Проектирование формы справочника «Контрагенты»
На рисунке видно, что на форме располагается элемент DataGridView, а также текстовые поля. Данные
элементы предназначены для отображения данных из одной таблицы s_kont. Все классы приложения, реализующие главное и
дочерние окна представлены на рисунке 2.11.
Рисунок 2.11 - Классы форм приложения в окне ClassView.
После разработки всех форм и наполнения их необходимыми компонентами,
необходимо разработать бизнес-классы приложения, то есть классы для выборки
данных из базы, хранения данных в процессе работы приложения и классы,
осуществляющие операции удаления, вставки, модификации записей.
2.2.3 Разработка бизнес-классов приложения
В программе использованы типизированные классы наборов данных, это
значит, что каждый объект класса, производного от DataTable, является поставщиком данных для
элементов управления формы из определенной таблицы. Перечень полей такого
класса по наименованию и типу совпадает с именами и типами столбцов
соответствующей таблицы в базе данных. В приложении все объекты, производные от
DataTable содержатся в наборах данных DataSet.
Для повышения модульности программы реализовано пять классов, производных
от DataSet. Все справочники представлены в DataSet1 (рисунок 2.12).
Рисунок 2.12 - Фрагмент набора данных DataSet1 в режиме проектирования
На рисунке 2.12 показаны элементы DataSet1: это типизированные DataTable и DataAdapter. Каждому объекту, представляющему
таблицу, например объект типа DataSet1.s_doctip, соответствует объект адаптера данных - DataSet1.s_doctipTableAdapter
(рисунок 2.12). Адаптеры осуществляют наполнение объектов DataSet данными, то есть содержат команды
обновления, удаления, модификации записей БД на языке SQL.
В приложении присутствуют наборы данных DataSet2 - для представления таблиц, отображающих информацию
о штатном расписании, DataSet3
- для объединения объектов DataTable, связанных с таблицей s_tovar («Товар») базы данных.
В реализованные DataSet
включены также связи между таблицами, что позволяет организовывать визуализацию
данных из нескольких связанных таблиц (рисунок 2.12).
На рисунке 2.13 представлена диаграмма класса DataSet2. Данный класс представляет собой набор данных, из
которого выбираются данные для справочника «Контингент».
Рисунок 2.13 - Класс DataSet2,
сгенерированная средой разработки, в режиме проектирования
В приложении Ж приводятся диаграммы классов для наборов данных, которые
используют формы приложения. На рисунке Ж.1 представлен состав класса DataSet3, который объединяет объекты DataTable, отражающие штатную структуру
предприятия. Класс DataSet4 (рисунок
Ж.2) производит выборку данных из таблиц базы данных, представляющих кадровый
состав предприятия. На рисунке Ж.3 представлен состав класса DataSet4, который объединяет объекты DataTable, отражающие документооборот
предприятия.
После создания бизнес-классов необходимо реализовать подключение
визуальных элементов управления к объектам, содержащим данные.
2.2.4 Создание классов для подключения визуальных элементов
управления к объектам данных
Для соединения элементов DataGridView, расположенных на дочерних формах и объектов данных (классы DataTable) реализованы дополнительные классы,
производные от BindingSource.
Схема взаимодействия между объектами данных классов представлена на рисунке
2.14.
Рисунок 2.14 - Схема взаимодействия компонентов приложения
В объекте BindingSource
инициализируются два свойства:
) свойству DataSource
присваивается объект DataSet,
содержащий требуемую таблицу;
) свойству DataMember
присваивается объект DataTable, содержащий набор строк из таблицы базы данных.
Таким образом, объекты классов BindingSource осуществляют функции прокси-сервера и распределяют данные от
источника по отдельным элементам управления. Такая схема позволяет
синхронизировать данные, отображаемые различными визуальными элементами, что
увеличивает устойчивость приложения и реализует механизм поддержки
непротиворечивости данных. Обновление данных, выполняемое пользователем через взаимодействие
с визуальными элементами управления, также происходит через объект BindingSource.
После разработки всех классов, необходимо организовать механизм
подключения к базе данных. Для этого в приложения водится объект соединения
(класс DataConnection). Так как база данных реализована с
использованием СУБД SQL Server, нет необходимости создавать
процедуры открытия и закрытия соединения для подключения в режиме выполнения
программы. Объект соединения настраивается в режиме разработки приложения с
использованием мастеров подключения.
Выводы
В качестве программных средств, используемых для разработки
информационной подсистемы, использовались продукты MS SQL Server 2005 Express Edition и MS Visual Studio 2005 Express Edition. Данные
среды выбраны по следующим причинам:
1 MS SQL Server 2005 Express Edition обеспечивает высокую производительность при работе с
удаленными источниками данных.
2 Возможность проектирования информационной подсистемы с
использованием визуальных мастеров, что существенно сокращает время разработки.
Инструментарий и библиотеки Visual Studio 2005 Express Edition обладают
высокой степенью интеграции с MS SQL Server, поддерживают все возможности данного сервера баз
данных.
Данные среды обладают высокой степенью интеграции с операционными
системами семейства Windows
Разработана информационная подсистема, учитывающая все требования
технического задания: создано приложение, функционирующее в среде Windows, обладающее широкими возможностями
масштабируемости и учитывающее все аспекты учета реализации продовольственной
продукции на предприятии ИП Быкова Р.Г..
Проект приложения, содержащий исходные тексты программных модулей
занимает 3 мегабайта на жестком диске. Для функционирования информационной
подсистемы необходимо подключение программы-клиента к серверу MS SQL Server. База данных (на начальном этапе эксплуатации)
занимает 5,75 мегабайт.
3. Информационное и программное обеспечение
.1 Общие сведения о программном продукте
Полное наименование разработанного программного продукта: «Информационная
подсистема учета закупок и реализации продовольственной продукции для ИП Быкова
Л.Ф.
Краткое наименование: ИП УЗРПП
Для разработки информационной системы использовались среды разработки:
. Для разработки клиентского приложения MS Visual Studio 2005 Express Edition.
2. Для разработки базы данных MS SQL Server 2005. Для доступа к данным использовались возможности
технологии ADO.NET.
Клиентское приложение разрабатывалось на языке C# (C Sharp). Для работы приложения необходима
установка бесплатного программного компонента .NET Framework версии 2.0 и выше.
3.2 Функциональное назначение программного продукта
Программный продукт предназначен для автоматизации задач учета закупок и
реализации продовольственных товаров в разрезе товарной номенклатуры, мест хранения,
контрагентов, документов.
Программный продукт обеспечивает следующие функциональные возможности:
Ввод и корректировка данных о сотрудниках, штатном расписании,
товарной номенклатуре, документах, опосредующих торговые операции в
соответствии с принципами ведения учета, характерными для ИП Быкова Л.Ф.
2 Контроль целостности и непротиворечивости вводимых данных как на
стороне сервера баз данных, так и на стороне клиентского приложения.
Оперативное получение информации о процессах закупки и реализации
продовольственной продукции по критериям, задаваемым пользователем.
Поиск, упорядочивание и фильтрация информации в программе по
критериям, задаваемым пользователем.
Получение агрегирующих показателей об оборотах продовольственных
товаров в натуральном и денежном выражении в разрезе товарных групп.
3.3 Описание логической структуры программного продукта
Обобщенный алгоритм работы программы представлен на рисунке 3.1.
Рисунок 3.1 - Обобщенный алгоритм работы программы
Программа представлена в виде сборки (исполняемого модуля с расширением .exe). Проект приложения в среде MS Visual Studio представлен совокупностью модулей (файлов с
расширение .cs), содержащих описание классов
приложения. Классы приложения объединены в пространства имен. В приложении семь
пространств имен, представляющих наборы данных и формы приложения. Спецификация
пространства имен KaKlient
представлена в таблице 3.1.
Таблица 3.1
Спецификация пространства имен KaKlient
Класс
|
Описание
|
DataSet1
|
Содержит коллекцию объектов
DataTable, представляющих таблицы-справочники
|
DataSet2
|
Содержит коллекцию объектов
DataTable, представляющих таблицу «Контрагент» и все
связанные с ней таблицы.
|
DataSet3
|
Содержит коллекцию объектов
DataTable, представляющих таблицу «Документ» и все связанные
с ней таблицы.
|
DataSet4
|
Содержит коллекцию объектов
DataTable, представляющих таблицу «Товар» и все связанные с
ней таблицы.
|
DataSet5
|
Содержит коллекцию объектов
DataTable, представляющих таблицу «Сотрудник» и все связанные
с ней таблицы.
|
MDIChild_s_cenatip
|
Класс формы, отображающей
данные из таблицы-справочника «Тип цены»
|
MDIChild_s_konttype
|
Класс формы, отображающей
данные из таблицы-справочника «Тип контрагента»
|
MDIChild_s_doctip
|
Класс формы, отображающей
данные из таблицы-справочника «Тип документа»
|
MDIChild_s_edizm
|
Класс формы, отображающей
данные из таблицы-справочника «Единица измерения»
|
MDIChild_s_kont
|
Класс формы, отображающей
данные из таблицы «Контрагент» и связанных с ней таблиц
|
MDIChild_s_sclad
|
Класс формы, отображающей
данные из таблицы-справочника «Склад»
|
MDIChild_s_sotrtip
|
Класс формы, отображающей
данные из таблицы-справочника «Тип сотрудника»
|
MDIChild_s_valut
|
Класс формы, отображающей
данные из таблицы-справочника «Валюта»
|
MDIChild_ShtatRasp
|
Класс формы, отображающей
данные о штатном расписании предприятия (из связанных таблиц «Отдел» и
«Должность»)
|
Формы справочников имеют одинаковый набор переопределенных методов.
Спецификация класса формы справочника представлена в таблице 3.2.
Таблица 3.2
Спецификация класса формы справочника
Атрибут
|
Способ доступа
|
Назначение
|
Button button1
|
private
|
кнопка «Сохранить»
|
Button button2
|
private
|
кнопка «Отменить»
|
DataGridView1
|
private
|
Таблицы для отображения
данных справочника
|
DataSet dataSet1
|
private
|
Набор данных, содержащий
таблицу-справочник
|
TableAdapter s_tadapt
|
private
|
Адаптер данных,
обеспечивающий наполнение таблицы
|
BindingSource s_bs
|
private
|
Источник данных,
обеспечивающий наполнение информацией элементов формы
|
void button1_Click
|
private
|
Обработчик нажатия кнопки
«Сохранить». Инициализирует пересылку измененных данных в БД
|
void button2_Click
|
private
|
Обработчик нажатия кнопки
«Отменить». Возвращает объект dataSet1 в первоначальное состояние.
|
DataGridView1_CellValue
Changed
|
private
|
Обработчик изменения значения
ячейки таблицы DataGridView1. Делает доступными кнопки button1 и button2.
|
DataGridView1_DataError
|
private
|
Обработчик возникновения
ошибки при вводе данных. Выдает информацию о ячейке и причине возникновения
ошибки
|
DataGridView1_RowsAdded
|
private
|
Назначение как у
обработчика DataGridView1_CellValueChanged
|
DataGridView1_Rows Removed
|
private
|
Назначение как у
обработчика DataGridView1_CellValueChanged
|
Load
|
private
|
Событие загрузки формы
справочника, загружает данные из БД
|
Классы экранных форм обрабатывают такие же события как и формы
справочников, но имеют расширенный состав элементов управления. Для
синхронизации различных элементов управления на форме, обработчики новых
элементов управления ссылаются на обработчики, представленные для справочников
в таблице 3.2. На рисунке И.1 представлена диаграмма классов, задействованных в
организации взаимодействия приложения с базой данных (классы несвязного уровня ADO.NET).
На рисунке И.2 представлена диаграмма классов, представляющих экранные
формы приложения.
В приложении также присутствуют классы для организации ресурсов
приложения, организации работы и запуска Windows-приложения. Диаграммы данных классов представлены на
рисунке И.3.
3.4 Требования к техническому обеспечению
.4.1 Основное программное обеспечение
Требования к техническому обеспечению определяются требовательностью к
аппаратным ресурсам самой программы, а также рекомендованными требованиями к
оборудованию со стороны используемого программного обеспечения сторонних
разработчиков.
На стороне ЭВМ с сервером баз данных, устанавливается следующее
программное обеспечение:
1. MS SQL Server 2005.
. MS .NET Framework 2.0.
. ОС Windows XP
Professional SP2.
На ЭВМ, используемых для доступа к базе данных (клиентские ПЭВМ)
устанавливается следующее программное обеспечение:
1. MS .NET Framework 2.0.
. MS Visual Studio 2005 Express Edition.
. ОС Windows XP Professional
SP2.
3.4.2 Требования к центральному процессору
Для ПЭВМ с установленным сервером баз данных требования определяются
рекомендациями, заявленными в документации по MS SQL Server 2005 (как наиболее ресурсоемкого приложения,
выполняемого на стороне сервера):
) минимальные: процессор не ниже Pentium 3 с частотой 600 МГц;
) рекомендуемые: процессор не ниже Pentium 3 с частотой 1 ГГц.
Для ПЭВМ с установленным клиентским приложением требования к процессору
не значительны и определяются только минимальными требованиями операционной
системы. Для Windows XP Professional: 300 МГц.
3.4.3 Требования к оперативному запоминающему устройству
Требования к ОЗУ на машине с установленным сервером баз данных MS SQL Server 2005 сведены в таблицу 3.3.
Таблица 3.3
Минимальные требования к ОЗУ на ЭВМ с реляционным сервером баз данных
Программный продукт
|
Минимальные требования к
ОЗУ, Мбайт
|
MS SQL Server
2005
|
250
|
Windows XP
Professional
|
128
|
Итого
|
378
|
Таким образом, минимальные требования к объему ОЗУ на ЭВМ с сервером баз
данных составляют 378 Мбайт.
Для ЭВМ с установленным клиентским приложением, требования к оперативной
памяти сведены в таблицу 3.4.
Таблица 3.4
Минимальные требования к ОЗУ на ЭВМ с клиентским программным обеспечением
Программный
продукт
|
Минимальные требования к
ОЗУ, Мбайт
|
Windows XP
Professional
|
128
|
MS Visual Studio
2005 Express Edition
|
128
|
Пространство,
занимаемое клиентским приложением
|
23
|
Итого
|
279
|
Требования к ОЗУ на машинах только с установленным клиентским приложением
составляют 279 Мбайт.
3.4.4 Требования к наличию свободного места на жестком диске
Размер инсталляционного пакета программы составляет 3,85 Мбайт.
Размер инсталляционного пакета MS SQL Server 2005 Express Edition составляет 150 Мб.
Для установки NET Framework 2.0 потребуется 120 Мбайт.
База данных на начальном этапе эксплуатации (с минимальным объемом
данных) занимает 5,75 Мбайт.
При эксплуатации программного продукта будет наблюдаться увеличение
объема файлов базы данных (в версии Express Edition размер
базы данных ограничивается значением 8 Гбайт). Таким образом, максимальное
пространство, которое может занять программный комплекс на жестком диске
составляет:
) Vmax (ПЭВМ) = 3,85 Мбайт + 120 Мбайт =
123,85 Мбайт (для ЭВМ с установленным клиентским приложением).
) Vmax = 150 Мбайт + 5,75 Мбайт +8 Гбайт =
8347,75 Мбайт (8,2 Гбайт) (для ЭВМ с установленной базой данных и СУБД).
.4.5 Требования к периферийным устройствам
Программный продукт не предъявляет специфических требований к
видеосистеме. Для комфортной работы рекомендуется использовать монитор с диагональю
17 дюймов.
Специфических требований к аудиосистеме нет.
В отчетах представлена только текстовая информация, что позволяет сделать
вывод о незначительных требованиях к качеству печати (300 dpi), рекомендуется использовать
черно-белый принтер.
Периодичность и оперативность отчетов достаточно высока, поэтому
необходимо использовать скоростной лазерный принтер со скоростью печати не
менее 40 страниц в минуту.
Для установки приложения необходимо наличие привода CD-ROM.
3.5 Вызов и загрузка программы
Для работы приложения на компьютере необходимо наличие следующих
компонентов:
1) .NET Framework 2.0 или выше;
) SQL Server Database Engine;
3) клиентское приложение;
) база данных, подключенная к серверу баз данных.
Для установки программы необходимо выполнить следующие действия:
) осуществить запуск сервера баз данных с помощью службы SQL Server Configuration Management;
2) Выполнить регистрацию базы данных на сервере СУБД;
) Вставить CD-ROM с программой в привод;
) Запустится программа установки, в которой необходимо задать
каталог для установки.
) После завершения установки можно приступать к работе с
программой.
Загрузка программы, разработанной с использованием технологий .NET осуществляется по мере
востребованности классов, которые размещаются в различных сборках. Так как
приложение является одномодульным (один исполняемый файл), то производится
загрузка всего приложения.
.6 Входные данные программы
Программа оперирует информацией, которую необходимо ввести пользователю.
В процессе своей работы, специалист отражает в программе факты учета реализации
продовольственной продукции путем ввода новых записей о товарах, контрагентах,
документах, сотрудниках.
Для ввода данных в различные таблицы разработан набор форм, которые
реализуются в виде диалоговых окон. Текстовые поля форм позволяют пользователю
вводить символьные или числовые данные с учетом ограничений, накладываемых
разработанной базой данных. То есть корректность вводимых данных проверяется не
только механизмами контроля целостности базы данных, но и логикой программы.
3.7 Выходные данные программы
Если пользователь регулярно фиксирует факты учета реализации
продовольственной продукции в базе данных, то в любой момент времени ему будет
доступна всеобъемлющая информация о штатной структуре предприятия, заключенных
сделках, личных данных сотрудников, контрагентах, документах.
Программа предоставляет возможность поиска, сортировки , фильтрации и
представления данных в нужном пользователю виде.
Программа позволяет учитывать не только остатки продовольственных
товаров, но и обороты товаров в натуральном и денежном выражениях в разрезе
валют, контрагентов, типов товаров.
Каждый элемент управления в программе соответствует типу данных которые
отображаются с помощью него. Например, при отображении значения из перечня
используется выпадающий список, при отображении даты - элемент управления
календарь.
Формы приложения разработаны таким образом, чтобы полно предоставлять
пользователю исчерпывающую информацию по всем аспектам деятельности ИП Быкова
Л.Ф. в сфере реализации продовольственной продукции.
В главном меню программы содержится пункт «Отчеты». С использованием
команд меню данного пункта возможно получение отчетов по перечню заключенных
договоров (рисунок Л.1) и расположению продовольственной продукции на складах
ИП Быкова Л.Ф. (рисунок Л.2).
Отчеты строятся с использованием программного обеспечения Crystal Reports, а также компонент MS Visual Studio 2005 для работы с данными генераторами отчетов.
3.8 Результаты тестирования программы
Тестирование программы производилось с использованием тестовых наборов
входных данных, которые охватывают различные возможные ошибки потенциальных
пользователей. К основным ошибкам при работе с клиентским приложением
относятся:
ввод значения не совпадающего с хранимым в базе данных по типу;
ввод строкового значения с длиной превышающей длину хранимой в базе
данных строки;
действия пользователя, приводящие к проявлению аномалий обновления,
удаления, вставки.
В результате тестирования приложения было выявлено, что программа является
устойчивой ко всем видам потенциально-возможных ошибок. Это достигается за счет
создания бизнес-правил и обработчиков ошибок в клиентском приложении, а также
за счет введения ограничений на операции вставки, удаления, модификации в самой
базе данных.
.9 Руководство пользователя по работе с программой
Для установки программы пользователю необходимо выполнить следующие
действия:
Установить MS SQL Server Express Edition.
2 Установить .NET Framework 2.0 или
выше.
Скопировать приложение с CD-ROM в папку на
жестком диске.
После запуска приложения на экране отобразится главное окно приложения
(рисунок 3.2).
Рисунок 3.2 - Главное окно приложения
С помощью команд главного меню вызываются справочники, формы для ввода документов,
сотрудников, штатного расписания.
Перед началом работы с программой необходимо заполнить справочники
(рисунки 3.3 и 3.4).
Рисунок 3.3 - Пример заполнения справочника «Валюты»
Рисунок 3.4 - Пример заполнения справочника «Склады»
После внесения всей необходимой информации необходимо перейти к вводу
информации о сотрудниках и штатном расписании ИП Быкова Л.Ф. Сначала необходимо
сформировать штатное расписание, то есть заполнить таблицы «Отдел» и
«Должность» (рисунок 3.5).
Рисунок 3.5 - Ввод сведений о штатном расписании
После этого необходимо назначить сотрудников на должности в форме,
представленной на рисунке 3.6.
Рисунок 3.6 - Ввод сведений о сотрудниках организации
Для управления товарной номенклатурой используются формы «Группы
продукции» и «