Geum.ru

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

Вид материалаРеферат

Содержание


2 Проектный раздел
Отдел закупок и сбыта
2 Проектный раздел
Подобный материал:
Автоматизация задач складского учета в малом бизнесе на примере «..............»

Аннотация


Данная работа посвящена одной из актуальных тем малого бизнеса «Автоматизация задач складского учета в малом бизнесе на примере «...............».

Дипломный проект состоит из четырех основных частей, при написании которых использовались данные, полученные в процессе прохождения преддипломной практики в малом торговом предприятии ЧП Алексеевой М.А. и теоретические данные, представленные в списке использованных источников.

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

В аналитической части рассматривается характеристика предприятия, основные виды деятельности. Описаны цели и задачи, исследуемой предметной области.

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

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

В разделе безопасность и экологичность проекта описано влияние опасных и вредных факторов на организм специалиста, работающего с ЭВМ (перечислены мероприятия по защите человека от воздействия опасных и вредных факторов), а также цели и задачи гражданской обороны.

Работа включает 106 страниц и содержит 50 рисунков, 1 таблицe и приложение.


Содержание


Введение



1 Аналитический раздел



1.1 Технико-экономическая характеристика предметной области



1.1.1 Краткая характеристика предприятия



1.1.2 Экономическая сущность задачи учета продажи товаров



1.1.3 Цели и предмет деятельности предприятия



1.2 Место задачи учета продажи товаров в деятельности предприятия



1.3 Обоснование использования вычислительной техники



1.4 Особенности ведения учета и автоматизации бизнес-процессов на малом предприятии



1.5 Постановка задачи автоматизации учета и продажи товаров



1.5.1. Цель автоматизированного решения



1.5.2 Общая характеристика организации решения задачи на ЭВМ



1.6 Анализ существующих разработок



1.7 Обоснование решений по техническому обеспечению проекта



1.8 Обоснование решений по программному обеспечению

проекта



2 ПРОЕКТНЫЙ РАЗДЕЛ



2.1 Общие вопросы проектирования баз данных



2.2 Информационное обеспечение задачи учета продажи товаров



2.3 Структура таблиц входящих в БД



2.4 Интерфейс рабочей БД



2.4.1 Разработка рабочих форм



2.5 Описание используемых макросов и запросов



2.6 Описание разработанных отчетов



2.7 Описание работы с базой данных



3 Экономический раздел



3.1 Выбор и обоснование методики расчёта экономической эффективности



3.2 Определение трудоемкости разработки БД



3.3 Определение себестоимости создания БД



3.4 Определение оптовой и отпускной цены БД



3.5 Определение ожидаемого прироста прибыли в результате внедрения БД



3.5.1 Определение годовых эксплуатационных расходов при

ручном решении задачи



3.5.2 Определение годовых текущих затрат, связанных с

эксплуатацией задачи



3.6 Определение ожидаемого прироста прибыли в результате внедрения БД



3.7 Расчет показателей эффективности использования БД



4 Безопасность и экологичность проекта



4.1 Проектирование зануления



4.2 Меры по обеспечению электробезопасности



4.3 Общие мероприятия по защите организма человека от

воздействия опасных и вредных факторов



4.3.1 Мероприятия по снижению электромагнитного излучения на рабочем месте экономиста-программиста



4.3.2 Мероприятия по устранению психофизиологических

опасных и вредных производственных факторов



4.3.3 Мероприятия по снижению пожароопасности



Заключение



Список использованных источников



Приложение





Введение


Торговля – обширнейшая область предпринимательской деятельности и сфера приложения труда – получила в последние годы новые импульсы своего развития. В нее влилось много новых предприимчивых людей, в ряде случаев коренным образом поменявших профессию и жизненные ориентиры. От рядовых спекулятивных торговых операций и «челночно-палаточного бизнеса» многие предприниматели перешли уже к более высокой стадии торговой деятельности, организовав индивидуальные или коллективные предприятия. Менеджерам таких предприятий приходится ежедневно сталкиваться с множеством проблем организационного, экономического и финансового характера, которые приходится решать интуитивно, методом «проб и ошибок», приобретая постепенно практический опыт.

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

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

Динамическая конкурентная среда, новые условия ведения бизнеса предъявляют повышенные требования к организации управления на торговом предприятии. В современных условиях организационная структура управления является стратегическим фактором конкуренции. Рост физических объемов торговли и расширение ее ассортимента обуславливает необходимость совершенствования управленческой деятельности предприятий торговли. Таким образом, исследование и рационализация информационных процессов в системе управления на предприятиях торговли является актуальной задачей в научном и практическом отношении.

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

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

Однако, малый и средний бизнес наиболее подвержен риску. Статистика показывает, что из каждых 10 малых предприятий выживают только 2-3. Причиной тому - наличие многочисленных факторов вероятностного характера, учет которых часто не представляются возможным. С другой стороны, риск в бизнесе выступает как наступательный фактор. Предпринимательство в рыночной экономике невозможно без риска. Наличие фактора риска является сильным стимулом для экономии средств и ресурсов предпринимателями, что вынуждает их тщательно анализировать рентабельность проектов, оценивать величину риска с целью минимизации возможных потерь.

Данная работа является научно-исследовательской разработкой в области автоматизации деятельности коммерческих предприятий и относится к системам автоматизации складского учета. Использование систем автоматизации сегодня во многом определяет уровень развития предприятия. Развитая система автоматизации предприятия позволяет легко приспосабливаться к изменениям в законодательстве и налоговой политики РФ, изменениям внутри предприятия. Отсутствие автоматизации приводит к задержкам в развитии предприятия, убыткам и простоям, неразберихи и хищениям.

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

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

Результатом данной работы является разработанная БД, на вход которой в течение рабочего периода в реальном масштабе времени поступают данные о поступлении на склад и списании материальных ресурсов предприятия со склада. В конце рабочего периода, а также в любой момент рабочего периода на выходе программы мы можем получить стандартные отчеты о движении материальных запасах. Таким образом, мы можем анализировать работу предприятия в течение рабочего периода и выбирать оптимальный характер ведения складской деятельности.

В данной работе рассматривается автоматизация учета продажи товаров и складского учета на примере «...............».

Цель автоматизированного решения задачи сводится к устранению недостатков, которые формируют две группы подцелей:

1. Достижение улучшения ряда экономических показателей (увеличение числа обслуживаемых клиентов, увеличение объемов продаж в торговом зале);

2. Улучшение значений показателей качества обработки информации (повышение степени достоверности обработки информации, степени ее защищенности, повышение степени автоматизации получения первичной информации).

Целью данного дипломного проекта является создание автоматизированной информационной системы (АИС) для автоматизации деятельности малого торгового предприятия.

Объектом исследования является деятельность предприятия.

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

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


Отношения между отдельными местами и задачами характеризуются отношениями подчиненности сверху и снизу, или отношениями по горизонтали.




ОТДЕЛ ЗАКУПОК И СБЫТА


Рисунок 1 - Внешние и внутренние информационные связи

отдела закупок и сбыта


Задача учета продажи товара тесно связана с другими задачами, решаемыми на предприятии (Рисунок 2).




Рисунок 2 - Схема взаимосвязи задачи учета продаж товаров с задачами

учета закупок и запасов товаров





Контур оперативного Контур бух. учета

управления

Приходный складской

ордер

Расходный складской

ордер

Накладные на внутреннее

перемещение


Накладные на отпуск

Накладные на возврат

Основания на продажу

(договора, счета-фактуры)


Основания на закупку

(договора, счета-фактуры)

Накладные на прием,

Накладные на возврат


Рисунок 3 - Схема связи подсистемы бухгалтерского учета и

оперативного учета


2 ПРОЕКТНЫЙ РАЗДЕЛ


2.1 Общие вопросы проектирования баз данных


Основные понятия теории баз данных.

С развитием экономики возрастает объем взаимосвязанных данных, необходимых для решения коммерческих и административных задач. Взаимосвязанные данные называют информационной системой. Такая система в первую очередь призвана облегчить труд человека, но для этого она должна как можно лучше соответствовать очень сложной модели реального мира.

Ядром информационной системы являются хранимые в ней данные. На любом предприятии данные различных отделов, как правило, пересекаются, то есть используются в нескольких подразделениях или вообще являются общими. Например, для целей управления часто нужна информация по всему предприятию. Заказ комплектующих невозможен без наличия информации о запасах. Хранящиеся в информационной системе данные должны быть легко доступны в том виде, в каком они нужны для конкретной производственной деятельности предприятия. При этом не имеет существенного значения способ хранения данных. Сегодня на предприятии мы можем встретить систему обработки данных традиционного типа, в которой служащий вручную помещает данные в скоросшиватель, и рядом с ней – современную систему с применением самой быстродействующей ЭВМ, сложнейшего оборудования и программного обеспечения. Несмотря на поразительную несхожесть, обе эти системы обязаны предоставлять достоверную информацию в определенное время, определенному лицу, в определенном месте и с ограниченными затратами. Построение информационных систем основывается на понятиях теории баз данных [24].

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

Предметной областью называется часть реальной системы, представляющая интерес для данного исследования.

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

Необходимо различать полную предметную область (предприятие) и организационную единицу этой предметной области. Организационная единица в свою очередь может представлять свою предметную область (отделы).

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


Объект.

Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью.

Объект может быть реальным (например, человек, какой-либо предмет или населенный пункт) и абстрактным (например, событие, счет покупателя или изучаемый студентами курс). Так, для складского учета примерами объектов могут служить ПОСТАВЩИК, ТОВАР, ПОЛУЧЕНИЕ и т. д. Каждый объект обладает набором определенных свойств, которые запоминаются в информационной системе. При обработке данных часто приходится иметь дело с совокупностью однородных объектов, например служащие, и записывать информацию об одних и тех же свойствах для каждого из них.


Класс объектов.

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

Объекты и их свойства являются понятиями реального мира. Для информационного пространства употребляется понятие атрибута объекта.


Атрибут.

Атрибут – это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов. Например, сотрудник предприятия имеет такие атрибуты, как фамилию, имя, отчество, адрес и возможно идентификационный номер. Каждый атрибут в модели должен иметь уникальное имя – идентификатор. Атрибут при реализации информационной модели на каком-либо носителе информации часто называют элементом данных, полем данных или просто полем.


Таблица.

Таблица – это некоторая регулярная структура, состоящая из конечного набора однотипных записей.

Каждая запись одной таблицы состоит из конечного числа полей, причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа.


Значение данных.

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

Информацию о некоторой предметной области можно представить с помощью нескольких объектов, каждый из которых описывается несколькими элементами данных. Принимаемые элементами данных значения называются данными. Единичный набор принимаемых элементами данных значений называется экземпляром объекта. Объекты связываются между собой определенным образом. Соответствующая модель объектов с составляющими их элементами данных и взаимосвязями называется концептуальной моделью. Концептуальная модель дает общее представление о потоке данных в предметной области.

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


Ключевой элемент данных.

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

Однозначно идентифицировать объект могут два и более элемента данных. В этом случае их называют «кандидатами» в ключевые элементы данных. Вопрос о том, какой из кандидатов использовать для доступа к объекту, решается разработчиком системы. Выбирать ключевые элементы данных следует тщательно, поскольку правильный выбор способствует созданию достоверной концептуальной модели данных.


Представление.

Представление – это сохраненяемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).

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


Связь.

Связь – это функциональная зависимость между сущностями.

Если между некоторыми сущностями существует связь, то факты из одной сущности ссылаются или некоторым образом связаны с фактами из другой сущности.

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

Связи могут быть представлены пятью основными характеристиками:
  • тип связи (идентифицирующая, не идентифицирующая, полная/неполная категория, неспецифическая связь);
  • родительская сущность;
  • дочерняя (зависимая) сущность;
  • мощность связи;
  • допустимость пустых значений.

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

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

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.


Основы теории проектирования баз данных.

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

Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами.

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


Концептуальная модель.

Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.

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

Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью.

Логическая модель (внешняя модель).

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.

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


Физическая модель (внутренняя модель).

Физическая модель, определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы.

Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Это положение отражает первый уровень независимости данных. С другой стороны, если концептуальная модель способна учитывать расширение требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели. Это – второй уровень независимости данных. Построение логической модели обусловлено требованиями используемой СУБД.

Все актуальные требования предметной области и адекватные им «скрытые» требования на стадии проектирования должны найти свое отражение в концептуальной модели. Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации.

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


Типы моделей данных.

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


Иерархическая модель.

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объектов. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.

Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и др. уровнях.


Сетевая модель.

В сетевой модели данных понятия главного и подчиненного объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный – термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.


Реляционная модель.

В реляционной модели данных объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ (ключевой элемент) – поле или комбинацию полей, которые единственным образом идентифицируют каждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение в СУБД для персональных компьютеров.


Проектирование базы данных.

Все тонкости построения информационной модели преследуют одну-единственную цель – получить хорошую базу данных. Что же такое хорошая база данных?

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

В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации – концептуальные требования к системе.

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:

База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.

База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности.

База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.

База данных должна легко расширяться при реорганизации и расширении предметной области.

База данных должна легко изменяться при изменении программной и аппаратной среды.

Загруженные в базу данных корректные данные должны оставаться корректными.

Данные до включения в базу данных должны проверяться на корректность.

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

В результате анализа поставленной заказчиком задачи и обработки требований конечных пользователей составляется концептуальная модель.

При разработке логической модели базы данных, прежде всего, необходимо решить, какая модель данных наиболее подходит для отображения конкретной концептуальной модели предметной области. Коммерческие системы управления базами данных поддерживают одну из известных моделей данных или некоторую их комбинацию. Большинство СУБД для персональных компьютеров поддерживают реляционную модель данных.

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


2.2 Информационное обеспечение задачи учета продажи товаров


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

В состав информационной базы входят:
  • массивы постоянной нормативно-справочной информации;
  • массивы, содержащие текущие данные о состоянии управляемого объекта;
  • массивы, содержащие данные, поступающие из внешней среды;
  • массивы, содержащие накапливаемые данные за определенный промежуток времени.

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

Основная задача организации информационного обеспечения состоит в адекватном отображении объекта управления и обеспечении информационных потребностей функциональных задач управления, а в данном случае, потребностей задачи «Автоматизация учета продаж».

2.3 Структура таблиц входящих в БД


При проектировании БД необходимо решить вопрос о наиболее эффективной структуре данных. Основные цели, которые при этом преследуются:

- обеспечить быстрый доступ к данным в таблицах;

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

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

Для решения поставленных задач была разработана БД, в состав которой входят 20 таблиц.

1. Структура таблицы «tblContr» (рисунок 4).



Рисунок 4 - таблица «tblContr»


В данной таблице хранятся данные о контрагентах.

2. Структура таблицы «tblFrom» (рисунок 5).



Рисунок 5 - Таблица «tblFrom»


В этой таблице хранятся сведения о заказах.

3. Структура таблицы «tblFrom2». Вторая вспомогательная форма, в которой хранятся сведения о заказах.



Рисунок 6 - Таблица «tblFrom2»


4. Структура таблицы «tblGoods». В таблице хранятся сведения о товаре.



Рисунок 7 - Таблица «tblGoods»


5. Структура таблицы «tblManuf». В таблице хранятся сведения о производителях.



Рисунок 8 - Таблица «tblManuf»


6. Структура таблицы «tblOper». В таблице хранятся сведения о операциях.



Рисунок 9 - Таблица «tblOper»



Рисунок 10 - Таблица «tblOperМ»


7. Структура таблицы «tblOurFirm». В таблице хранятся основные сведения о торговом предприятии (рисунок 11).



Рисунок 11 - Таблица «tblOurFirm»


8. Структура таблицы «tblPayment». В таблице хранятся сведения о платежах.



Рисунок 12 - Таблица «tblPayment»

9. Структура таблицы «tblSite». В таблице хранятся сведения о складах.



Рисунок 13 - Таблица «tblSite»


10. Структура таблицы «tblStatus». В таблице хранятся сведения о статусе продажи «Опт-Рынок-Магазин» (рисунок 14).



Рисунок 14 – Таблица «tblStatus»


11. Структура таблицы «tblTo». В таблице хранятся сведения о продажах (рисунок 15).



Рисунок 15 - Таблица «tblTo»



Рисунок 16 - Расширенная таблица «tblTo2»


12. Структура таблицы «tblType». В таблице хранятся сведения о типе продоваемого товара (Комнатное растение, Бонсаи, Плошка, Грунт и др.) (рисунок 17).



Рисунок 17 - Таблица «tblType»


13. Структура таблицы «tblTypePayment». В таблице содержаться сведения о типе платежа.



Рисунок 18 - Таблица «tblTypePayment»


14. Структура таблицы «tblUnit». В таблице хранятся сведения о единицах измерения (шт., кг., объем и т.д.).



Рисунок 19 - Таблица «tblUnit»


Другие таблицы являются вспомогательными.

После того как определены все таблицы составляем схему данных. Схема данных показана на рисунке 20.



Рисунок 20 – Схема данных разработанной БД


2.4 Интерфейс рабочей БД


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

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

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


2.4.1 Разработка рабочих форм


Работа в БД построена на экранных формах, в которые поступает информация из подчинённых форм. Для эффективной работы с БД разработано 52 экранных формы. Основная часть форм является вспомогательными, которые необходимы для корректной работы всей БД. Дадим описание основных рабочих форм.


1. Форма «frmArr». С помощью этой формы вносятся сведения о «новом приходе», о получаемом товаре.







Рисунок 21 – Форма «frmArr»


2. Форма «frmArrs». Основная форма отображающая приход (рисунок 22).



Рисунок 22 - Форма «frmArrs»


3. Форма «frmChangePrice». Вспомогательная форма, в которой можно изменить введенные цены.



Рисунок 23 - Форма «frmChangePrice»


4. Форма «frmChooseEtic». Форма для выбора товара для печати ценников(рисунок 24).



Рисунок 24 - Форма «frmChooseEtic»


5. Форма «frmContr». Форма для введения контагентов в БД.



Рисунок 25 - Форма «frmContr»

6. Форма «frmDolgAdd». Форма для ведения и регистрации должников (рисунок 26).



Рисунок 26 - Форма «frmDolgAdd»


7. Форма «frmDolgPament». Форма для регистрации проплаты по долгам.




Рисунок 27 - Форма «frmDolgPament»




Рисунок 28 – Форма статистики должников «frmDolgStat»


8. Форма «frmGoodsL». Разработана для развернутого поиска жилья (рисунок 29).



Рисунок 29 - Форма «frmGoodsL»


9. Форма «frmManuf». Для ведения справочника «Производитель».

10. Форма «frmOstatkiType».Форма для вывода на печать остатков.

11. Форма «frmOurFirm».Форма для ввода сведений о фирме.




Рисунок 30 - Форма «frmOurFirm»


12. Форма «frmSale».Форма для ввода сведений «новая продажа».




Рисунок 31 - Форма «frmSale»


13. Форма «frmSalesS».Форма для ввода сведений о расходах.





Рисунок 32 - Форма «frmSalesS»


14. Форма «frmType».Форма для ввода сведений о типах товара.





Рисунок 33 - Форма «frmType»


Все остальные формы являются вспомогательными к основным формам.


2.5 Описание используемых макросов и запросов


Все запросы и макросы применяются для того, чтобы корректно работала база данных. Большинство запросов применяется для осуществления поиска и промежуточных расчетов. Так запрос qryAdress реализует поиск по фамилии. Запрос qryContrSales является вспомогательным для ведения контроля сумм. Запрос qryDolgiItog для выведения итогов по должникам. Зпросы qryFrom для корректной работы форм. Запрос qryGoodsArr производит сортировку по возрастанию в поле упаковка. Запросы qryItog позволяют выводить итоговые суммы. Запросы qryOstatki позволяют выводить сведения об остатках. Запросы qryPayment необходимы для ведения платежей. Запросы qryPribyl позволяют вести учет по прибылям. В работе также использовано ряд запросов на добавление новых записей.

Наиболее интересным является использование разнообразных макросов. Так макрос AddArr предназначен для открытия Формы новый приход. Макрос AddDolgi открывает форму для учета должников. Макрос AddPayment открывает форму новой проплаты. Макрос AddSale открывает форму «Новая продажа». Макрос PreW активизирует отчет «Товарный чек». Макрос Print – стандартный макрос для начала печати.


2.6 Описание разработанных отчетов


Отчеты необходимы для вывода на печать необходимых сведений. Отчет repAvillable предназначен для вывода на печать сведений о хранящихся товарах на складе. Отчет repCheque предназначен для вывода на печать товарных чеков (рисунок 34)




Рисунок 34- товарный чек


Отет repEtic1 предназначен для печати ценников (рисунок 35).




Рисунок 35 – Печать ценников


Отчет repFromDay предназначен для печати продаж по выбранной дате. Отчет repGoodsRozn для печати списка товаров розницы. Отчет repListGoods необходим для печати списка товаров. Отчет repOstatki для печати остатков. Отчет repPrice в дальнейшем будет использован для печати прайс-листа. Отчеты repWaybill предназначены для печати товарных чеков. Примеры использования отчетов будут описаны ниже в разделе описания работы с БД.

2.7 Описание работы с базой данных


Работать с БД просто. Запускаем MS Access и откраваем файл с БД. Если правильно настроить запуск БД в меню Сервис\Параметры запуска (как показано на рисунке 36), то при запуске нам будет доступна только панель с рабочими кнопками БД.



Рисунок 36 – Настройка параметров запуска БД


При первом запуске БД необходимо начать работу с заполнения справочников (рисунок 37). Нами будт использованы шесть справочников (рисунок 37).



Рисунок 37 – Настройка справочников


Заполняя справочник «Склады», мы вносим перечень используемых нами складов (рисунок 38).





Рисунок 38 – Справочник по складам

Далее заполняется справочник с производителями. Важно указать полный перечень производителей основных видов товара (рисунок 39).





Рисунок 39 – Спавочник «Производители»

Следующим заполняется справочник «Контрагенты».



Рисунок 40 – Справочник «Контрагенты»

Далее необходимо заполнить справочник «Сведения о фирме» и справочник «Виды товаров». Заполнение данных справочников необходимо для корректной работы БД. Сведения о фирме используюстя для печати отчетов.



Рисунок 41- Сведения о фирме




Рисунок 42 – Виды товаров


Наибелее важным из справочниов является справочник по наличию товаров рисунок 43. Здесь заносятся основные сведения о товаре. Нужно отметить, что при заполнении поля «Кол. в упаковке; Высота» заполняются либо сведения о штучном товаре (для комнатных растений указывается высота), либо количество в упаковке, если товар не единичный. В подчиненной форме можно посмотреть цены на данный товар, а также движение товара на складе «Приход-Расход».






Рисунок 43 – Справочник «Товары»

После заполнения всех справояников можно приступить к работе с БД. Новый приход. Заполнение данной формы необходимо вести одновременно с заполнением формы справочника «Товары», если ранее у нас небыло в продаже такого товара. Если товар уже был и учтен в базе данных, то при заполнении формы «Новый приход» выбирается товар из списка и можно проводить товар по новой цене, если цена закупки уже изменилась (рисунок 44).








Рисунок 44 – Форма «Новый приход»

Далее, если у нас прошла продаже товара, то необходимо сделать отметки на форме «Новая продажа» (рисунок 45).



Рисунок 45 – Форма «Новая продажа»

При новой продаже в форме автоматически высвечивется дата, затем выбирается контрагент. В разделе статус указывается статус продажи, либо продаже по оптовой цене, либо по рыночной, либо по цене установленной в магазине. Раздел «долг» используется для контрагентов, которые являются постоянными покупателями и они могут покупать продукцию в рассрочку. Если заказ сразу оплачивается, то необходимо нажать кнопку «Продажа» и провести новую продажу (рисунок 46).





Рисунок 46 – Форма «Оплата»


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

Нажав кнопку «Приход» можно посмотреть, сколько получено товара, когда, от кого и по какой цене (рисунок 47).




Рисунок 47 – Форма «Приход»


Аналогично можно посмотреть «Расход».

В разделе отчеты представлены отчеты о деятельности фирмы (рисунок 48).




Рисунок 48 – Отчеты

Пример отчета по остаткам показан на рисунке 48. Таким образом, рассмотрена работа с использованием разработаннй БД. Далее планируется совершенствовать БД. В раздел «документация» будут добавлены отчеты по прайсам, будет добавлена возможность распечатывать ценники. В разделе «Касса» можно получить информацию о должниках (рисунок 49).




Рисунок 49 – Отчеты о должниках на начало периода