Проектирование базы данных Учета расчетов с поставщиками и подрядчиками (Описание предметной области. Постановка задачи.)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

1 глава. Аналитическая часть

1.1 Описание предметной области. Постановка задачи

При осуществлении поставок предприятия изготовители продукции вступают в договорные отношения с предприятиями потребителями (покупателями) как поставщики заключают прямые договора с предприятиями потребителями для сбыта продукции и комплексного снабжения предприятий-заказчиков.

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

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

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

Разрабатываемый программный продукт призван решать данные проблемы.

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

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

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

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

Любую поставку предприятие-заказчик обязано оплатить в установленные договором сроки, поэтому АИС должна осуществлять подсчет суммы долга (денег к выплате) на текущую дату поставщиков предприятию или предприятия поставщикам.

Таким образом, для разработки АИС необходимо выполнить следующие задачи:

1) реализация управления доступом к АИС;

2) создать систему управления базой данных (СУБД) для работы АИС;

3) выполнить анализ и учета поставок.

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

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

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

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

1) удобство использования;

2) наглядность;

3) минимальные затраты ресурсов компьютерного обеспечения;

4) возможность использования БД при отсутствии профессиональных навыков.

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

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

2) контроль за своевременным, полным и правильным оприходованием поступивших товаров;

3) своевременное и правильное оформление документации и контроль за каждой операцией отпуска, отгрузки или реализации товара;

4) контроль за соблюдением нормативов запаса товаров.

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

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

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

2) заявку на поставку необходимой продукции (указывается количество, наименование, номенклатура, сроки поставки, сумма поставки);

3) заказ на поставку.

Разрабатываемая автоматизированная система должна будет реализовать следующие функции:

1) Обеспечение ввода данных о поставках на предприятие;

2) Анализ введенной информации;

3) Подсчет задолженности предприятия за осуществленные поставки;

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

1.2 Выбор СУБД

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

Microsoft Access относится к СУБД, ориентированным на рядовых потребителей. Она позволяет, не прибегая к программированию, с легкостью выполнять основные операции с БД: создание, редактирование и обработка данных. Этот пакет работает в ОС Windows на автономных ПК или в локальной сети. Посредством MS Access создаются и в дальнейшем эксплуатируются личные БД (настольные), а также базы организаций, имеющих относительно небольшой объем данных. Microsoft Access является частью пакета Microsoft Office и входит в комплект его поставки. Среда Access располагает характерным для приложений Windows интерфейсом, состоящим из следующих компонентов: титульной строки, главного меню, панели инструментов, поля для работы и строки состояния. СУБД работает с данными, которые можно выстроить в иерархическую последовательность. Верхний уровень иерархии содержит основные объекты Access: - таблицы - главный тип объекта, поскольку все остальные вариации объектов - это производные от таблицы. Основные составляющие таблицы - поля и записи, они определяют свойства элементов таблицы; - формы - вспомогательные объекты, от использования которых можно отказаться. Они формируются, чтобы создать дополнительные удобства пользователю в плане просмотра, ввода и редактирования данных; - запросы - результаты обращения пользователя к БД с целью поиска данных, удаления, добавления и обновления записей. Результаты поиска (выборки) подаются в табличном виде; - отчеты - документы, предназначенные для вывода на печать, сформированные на информации, которая содержится в таблицах и запросах; - схема - описание архитектуры связей многотабличной базы данных; - макросы и модули - объекты повышенной сложности, при обыденной работе могут не использоваться.

Paradox - популярный СУБД занимающий устойчивые позиции на рынке средств разработки настольных приложений с базами данных. Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase - каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md). Формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE - Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language). Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяют также манипулировать данными других форматов, в частности dBase и данными, хранящимися в серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.

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

Для данного проекта была выбрана СУБД Paradox так как обладает всей необходимой полнотой функциональности необходимой для реализации задач, а также входит в состав среды разработки Borland Delphi 7, используемой для реализации проекта.

1.3 Проектирование логической структуры базы данных

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

Особое внимание уделяется этапу проектирования информационно-логической модели, поскольку здесь необходимо добиться оптимального соотношения между предметной областью и абстракцией логической модели. Для проектирования существуют различные средства в том числе и компьютерные. Для этой цели мы воспользовались ER-диаграммой (ER – Entity Relation – «Сущность-Связь»). Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Связь – это некоторое соединение между двумя сущностями. ER-диаграмма – это несколько сущностей, соединенные связями. Модель «Сущность-связь» описывается в терминах сущность, связь, значение. Сущность – понятие которое может быть идентифицировано. Связь – соединение сущностей.

Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность – это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа «многие-ко-многим» или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности.

Сущность «Поставщик». С поставщиком заключается договор, на основании которого ведется вся остальная деятельность предприятии по поставкам, отправление заявки поставщикам, получение от них счета-фактуры, отправление заказа на поставку, получение товара, оплата поставки. В качестве ключа для данной сущности вводится атрибут № Поставщика.

Сущность «Договор». Договор содержит такие данные как дата договора, номер договора, сумма и срок действия. На основании договора составляются заявки на поставку товара. Договор включает ассортимент товаров. В качестве ключа сущности вводится атрибут № Договора.

Сущность «Заявка». Заявка содержит такие данные на основании какого договора она составлена, дата заявки, номер заявки. На основании заявки создается счет-фактура с указанием цены. Заявка включает перечень товаров. В качестве ключа сущности вводится атрибут №Заявки.

Сущность «Счет-фактура». Счет фактура включает номер счета-фактуры и сумму по заявке. На основании счета-фактуры составляется заказ. В качестве ключа для данной сущности вводится атрибут №счета.

Сущность «Заказ». Заказ содержит данные о номере заказа, ассортименту заказа, номере договора, дате заказа, номере счета. В качестве ключа для данной сущности вводится атрибут № заказа.

Все сущности, их атрибуты и ключи представлены в Таблице 1.

Таблица 1

Сущности, их атрибуты и ключи модели

Название сущности	Атрибут	Ключ
Договор	№Договора, дата договора, сумма договора, срок действия.	№Договора
Поставщик	№Поставщика, наименование поставщика, адрес, телефон.	№Поставщика
Ассортимент товаров	№Товара, наименование товара.	№Товара
Заявка	№Заявки, ассортимент заявки, номер договора, дата заявки.	№Заявки
Заказ	№Заказа, №Договора, ассортимент заказа, дата заказа, номер счета.	№Заказа
Счет-фактура	№Счета, ассортимент счета, цена за единицу товара, сумма счета.	№Счета

Выделение связей между сущностями осуществляется на основании анализа предметной области. В процессе анализа выделяем следующие связи:

- «Поставщик» заключает «Договор»;

- «Договор» включает «Ассортимент товаров»;

- «Договор» основание «Заявка»;

- «Заявка» включает «Ассортимент товаров»;

- «Заявка» основание «Счет-фактуры»;

- «Счет-фактура» основание «Заказ»;

- «Заказ» включает «Ассортимент товаров».

Выполнив анализ сущностей и связей между ними, построим логическую модель (Таблица 2).

Таблица 2

Логическая модель

Название сущности	Атрибут	Ключ
Договор	№Договора, дата договора, сумма договора, срок действия, №Поставщика.	№Договора
Ассортимент договора	№ Договора, №товара.	№Договора, №Товара.
Поставщик	№Поставщика, наименование поставщика, адрес, телефон.	№Поставщика
Ассортимент товаров	№Товара, наименование товара.	№Товара
Заявка	№Заявки, №Договора, дата заявки.	№Заявки
Ассортимент заявки	№Заявки, №товара, количество.	№Заявки, №Товара
Заказ	№Заказа, №Счета, дата заказа, номер счета.	№Заказа
Ассортимент заказа	№Заказа, №товара.	№Заказа, №Товара.
Счет-фактура	№Счета, №Заявки, сумма счета.	№Счета

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

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

- вторая нормальная форма (2NF): сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа (не должно быть зависимости от части ключа). Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первичный ключ;

- третья нормальная форма (3NF): сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (не должно быть взаимозависимости между не ключевыми атрибутами);

- нормальная форма Бойса-Кодда (усиленная 3NF): отношение находится в усиленной 3NF тогда и только тогда, когда каждый детерминант отношения является возможным ключом.

Разработанная модель находится в 3-й нормальной форме, так как:

– атрибуты сущностей являются атомарными;

– каждый не ключевой атрибут функционально полно зависит от первичного ключа;

– в модели отсутствуют транзитивные зависимости не ключевых атрибутов от ключа.

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

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

Для построения логической модели данных использовалось СASE-средство MS Visio, которое позволяет проектировать реляционные модели данных.

Логическая модель данных представлена на Рисунке 1.

Рисунок 1. Логическая модель данных

1.4 Проектирование физической структуры базы данных

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

Описанные сущности в предыдущем пункте согласно выбранной СУБД будут иметь следующие физические модели:

- сущность «Поставщик» (таблица 3);

- сущность «Договор» (таблица 4);

- сущность «Ассортимент договора» (таблица 5);

- сущность «Заявка» (таблица 6);

- сущность «Ассортимент заявки» (таблица 7);

- сущность «Счет-фактура» (таблица 8);

- сущность «Ассортимент товара» (таблица 9);

- сущность «Заказ» (таблица 10);

- сущность «Ассортимент заказа» (таблица 11).

Таблица 3

Поставщик

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
N	Номер	Number	8	Да
Name	Наименование	Alpha	30
Adress	Адрес	Alpha	40
Phone	Номер телефона	Alpha	15

Таблица 4

Договор

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
N	Номер	Number	8	Да
Name	Наименование	Alpha	30
Adress	Адрес	Alpha	40
Phone	Номер телефона	Alpha	15

Таблица 5

Договор

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
NDogovora	Номер договора	Number	8	Да
NTovara	Номер товара	Number	8	Да

Таблица 6

Заявка

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
N	Номер заявки	Number	8	Да
NDogovora	Номер договора	Number	8
Date	Дата	Date	4

Таблица 7

Заявка

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
NZayavki	Номер заявки	Number	8	Да
NTovara	Номер товара	Number	8	Да
Quantity	Количество	Number	8

Таблица 8

Счет-фактура

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
N	Номер счета	Number	8	Да
NZayavki	Номер заявки	Number	8	Да
Price	Сумма счета	Money	8

Таблица 9

Товар

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
N	Номер товара	Number	8	Да
Name	Наименование	Alpha	40

Таблица 10

Заказ

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
N Zakaz	Номер заказа	Number	8	Да
NScheta	Номер счета	Number	8
Date	Дата	Date	4
Oplata	Оплачено	Logical	1
Poluch	Получено	Logical	1

Таблица 11

Заказ

Название поля	Описание	Тип поля	Длина поля	Первичный ключ
NZakaza	Номер заказа	Number	8	Да
NTovara	Номер товара	Number	8	Да

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

2 глава. Практическая часть

2.1 Контрольный пример решения задачи

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

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

На основании этих данных происходит аналитика и формируются выходные документы согласно заданию: заявка на поставку, заказ и договор.

Для контрольного решения задачи подготовим следующие данные: список поставщиков (таблица 12), ассортимент товара(таблица 13), список договоров(таблица 14).

Таблица 12

Список поставщиков

Наименование	Код	Адрес	Телефон
АО Стройкомплект	100	123242, г. Москва, ул. Московская, 9	342-45-67
ОАО Строймонтаж	200	383940, г. Москва, ул. Кирова, 56	231-45-89
ЗАО Континенталь, Лтд.	300	483950, г. Самара, ул. Ладожская, 37	223-23-43
ЗАО Газкомплект	400	232423, г. Казань, ул. Пролетарская, 71	23-45-67
ОАО Краскомплект монтаж	500	849495, г. Краснодар, ул. Мира, 32	77-66-55

Таблица 13

Список товаров

Код	Наименование
80	Кирпич облицовочный
81	Цемент, марка 800
82	Эмаль для внешних работ
83	Кафель "Эстра"
84	Шпатлевка ШН-12
87	Плита прессованая
88	Песок строительный
90	Краска лаковая
91	Евровагонка
92	Кирпич силикатный
93	Стекло 10 мм

Таблица 14

Список договоров

Номер Поставщика	Номер договора	Дата	Сумма	Срок
100	112	01.03.2003	3323000.00	До исполнения договора
200	113	15.05.2003	5030000.00	До исполнения договора
300	114	20.06.2004	6434000.00	До исполнения договора
400	115	15.07.2004	12890000.00	5 лет
500	116	20.03.2005	1200000.00	6 лет

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

Таблица 15

Ассортимент договора

Номер договора	Номер товара
112	80
112	81
112	82
112	84
113	80
113	81
113	83
114	80
114	81
114	82
114	90
114	92
114	93

Данных достаточно чтобы можно было пользоваться программой. Приведем пример тестового ввода данных.

Таблица 16

Тестовые данные

№	Входные данные		Ожидаемый результат	Результат программы
	Поле ввода	Значение
1	номер договора	1000	нормальная работа АИС	Ожидание ввода дата договора
	дата договора	03.03.2003	нормальная работа АИС	занесение записи в БД
2	номер договора	1000	Ошибка.Ключ должен быть уникальным	Выдача сообщения об ошибке
3	номер договора	100	нормальная работа АИС	Ожидание ввода дата договора
	дата договора	2,2,2	ошибка. Ввод не в форме даты	Выдача сообщения об ошибке
4	сумма счета	12349	нормальная работа АИС	занесение записи в БД
5	сумма счета	0	Ошибка. Сумма счета должна быть больше 0	Выдача сообщения об ошибке
6	оплачено	да	нормальная работа АИС	занесение записи в БД
7	оплачено	нет	нормальная работа АИС	занесение записи в БД
8	оплачено	есть	ошибка. Значение поля принимает 2 значения: да, нет	Выдача сообщения об ошибке

2.2 Разработка интерфейса и реализация проекта

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

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

1) обеспечивать ввод данных, связанных с поставками на предприятие и обработку этих данных;

2) иметь систему краткой справки по программе;

3) при вводе данных о наименовании товаров должен использоваться справочник «Номенклатура товаров».

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

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

Таблица 17

Описание модулей и используемых типов и переменных

Модуль	Форма	Интерфейсные переменные
		Имя	Тип
uMain	fmMain − главная форма программы, на которой реализованы все основные функции АИС	fmMain	TfmMain − объект-потомок стандартного типа TForm
uDM	DataModule1 − модуль данных для хранения наборов данных, источников данных и запросов к БД	DataModule1	TDataModule1 − объект-потомок стандартного типа TDataModule
uPrintDogovor	fmPrintDogovor − форма для формирования текста договора	fmPrintDogovor	TfmPrintDogovor − объект-потомок стандартного типа TForm
uPrintZayavka	fmPrintZayavka − форма для формирования текста заявки по выбранному ассортименту товаров заявки	fmPrintZayavka	TfmPrintZayavka − объект-потомок стандартного типа TForm
uPrintZakaz	fmPrintZakaz − форма для формирования текста заказа по выбранному ассортименту товаров заказа	fmPrintZakaz	TfmPrintZakaz − объект-потомок стандартного типа TForm
uInfo	fmInfo − форма отображения краткой справки по работе с системой	fmInfo	TfmInfo − объект-потомок стандартного типа TForm

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

Описание основных процедур и функций, представленных в программе, наглядно приведено в таблице 18.

Таблица 18

Описание основных процедур и функций

Имя процедуры или функции	Назначение	Комментарий
PageControl1Change	Обработчик смены закладки на форме − активизация того или иного набора данных	Метод объекта типа TfmMain
dcbAssDogovoraClick	Обработчик выбора номера договора в выпадающем списке на закладке Ассортимент договора	Метод объекта типа TfmMain
acStopExecute	Обработчик выбора пункта меню «Операции|Приостановление действия договора» − отключение абонента	Метод объекта типа TfmMain
dcbNDogovoraClick	Обработчик выбора номера договора в выпадающем списке на закладке Заявка	Метод объекта типа TfmMain
dcbNZayavkiClick	Обработчик выбора номера заявки в выпадающем списке на закладке Ассортимент Заявки	Метод объекта типа TfmMain
ActionDogovorExecute	Обработчик выбора пункта меню Документы−>Договора − определение видимости соответствующих закладок	Метод объекта типа TfmMain
ActionZayavkiExecute	Обработчик выбора пункта меню Документы−>Заявки − определение видимости соответствующих закладок	Метод объекта типа TfmMain
ActionFacturesExecute	Обработчик выбора пункта меню Документы−>Счета-фактуры− определение видимости соответствующих закладок	Метод объекта типа TfmMain
ActionZakazExecute	Обработчик выбора пункта меню Документы−>Заказы − определение видимости соответствующих закладок	Метод объекта типа TfmMain
dcbZakazNZClick	Обработчик выбора номера договора в выпадающем списке на закладке Заказ	Метод объекта типа TfmMain
ActionPrintExecute	Обработчик нажатия кнопки Печать − вывод на печать текста выбранного договора, заявки или заказа в зависимости от активного документа на данный момент	Метод объекта типа TfmMain
qrSchetBeforeDelete	Обработчик удаления записи о счете-фактуре − обеспечение ссылочной целостности − удаление всех связанных записей	Метод объекта типа TDataModule1
qrZayavkaBeforeDelete	Обработчик удаления записи о заявке − обеспечение ссылочной целостности − удаление всех связанных записей	Метод объекта типа TDataModule1
qrDogovorBeforeDelete	Обработчик удаления записи о договоре − обеспечение ссылочной целостности − удаление всех связанных записей	Метод объекта типа TDataModule1
qrPostavschikBeforeDelete	Обработчик удаления записи о поставщике − обеспечение ссылочной целостности − удаление всех связанных записей	Метод объекта типа TDataModule1

Рассмотрим работу комплекса в процессе эксплуатации. После запуска файла postavki.exe на исполнение на мониторе появляется главная форма программы (Рисунок 2).

Рисунок 2. Таблица «Поставщики»

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

Работа с договорами (Рисунок 2) включает в себя:

1) работа с поставщиками;

2) работа с договорами;

3) работа с товарами;

4) работа с заключенными договорами;

5) работа с ассортиментом договоров.

Договор заключается предприятием-заказчиком с предприятием-поставщиком на поставку определенного вида и ассортимента продукции. С одним поставщиком может быть заключено несколько договоров. Атрибутами договора являются следующие поля: номер договора, код поставщика, дата договора, сумма договора, срок действия договора. Все атрибуты, кроме срока действия договора являются обязательными для заполнения. На основании договора производится дальнейшая деятельность по поставкам на предприятии. Она заключается в работе с заявками, работе со счетами, работе с заказами.

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

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

Редактирование происходит при нажатии клавиши Enter на выбранной записи.

Рисунок 3. Таблица «Договора»

Работа с поставщиками (Рисунок 3) состоит в добавлении нового поставщика, его атрибутов, удалении поставщика, редактировании атрибутов поставщика: код поставщика (для каждого поставщика код уникален), наименование поставщика, адрес и телефон поставщика. Все атрибуты, кроме телефона являются обязательными для заполнения, в случае их не заполнения возникает ошибка.

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

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

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

Рисунок 4. Таблица «Товары»

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

Добавление новой записи в таблицу осуществляется путем ввода информации о товаре в строки таблицы товары. Редактирование – нажатием клавиши Enter на редактируемой строке и изменении информации. Удаление – двойным щелчком мыши на удаляемой строке.

Рисунок 5. Таблица «Ассортимент договора»

Работа с ассортиментом договоров (Рисунок 5) заключается в добавлении, редактировании и удалении наименования товара или товаров, которые поставщик обязуется поставить заказчику на основании перечня поставляемых товаров, указываемом в заключенном договоре. Вышеуказанные операции проводятся аналогично операциям в работе с договорами.

Рисунок 6. Таблица «Заявка»

Рисунок 7. Таблица «Ассортимент заявки»

Рисунок 8. Таблица «Все заявки»

Работа с заявками (Рисунок 6) представляет собой работу с тремя закладками:

1) заявка;

2) ассортимент заявки;

3) все заявки.

Закладка «заявка» содержит таблицу с данными о заявках, которые сделал заказчик поставщику по одному из заключенных договоров. Таблица заявка содержит атрибуты: номер заявки, номер договора, дата заявки. Заполнение всех атрибутов является обязательным. Номер договора один из заключенных, в противном случае возникает ошибка.

Пользователь имеет возможность добавлять, редактировать и удалять записи.

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

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

Удаление, добавление и редактирование записей происходит аналогично закладке заявка.

Рисунок 9. Таблица «Счет-фактура»

Для работы со счетами предлагается закладка «Счет-фактура» (Рисунок 9). Таблица «Счета» включает атрибуты: номер счета, номер заявки, номер договора, сумма счета. Все атрибуты обязательны для заполнения. Ассортимент счета соответствует ассортименту заявки. На закладку выводится информация (либо предоставляется для ввода) только по одному из заключенных договоров, номер которого выбран в таблице ассортимент договоров.

Рисунок 10. Таблица «Заказ»

Рисунок 11. Таблица «Все заказы»

Для работы с заказами предлагается две закладки: «Заказ» (Рисунок 10) и «Все заказы» (Рисунок 11). Таблица «Заказ» имеет следующие атрибуты: номер заказа, номер договора, номер счета, получено, оплачено, и поле для определения задолженности предприятия по оплате выполненных поставок.

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

Закладка «Все заказы» представляет собой таблицу с перечнем всех заказов сделанных по всем заключенным договорам. Что-либо в ней изменять пользователь не имеет возможности.

 

ЗАКЛЮЧЕНИЕ

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

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

В рамках курсовой работы была разработана система « Учета расчетов с поставщиками и подрядчиками», которая может использоваться на предприятиях и обеспечивать контроль и учет поставок, производимых на предприятие.

Разработанная АИС выполняет следующие функции:

1) ввод, изменение и удаление данных о поставщиках, договорах, товарах, заявках, счетах-фактурах и заказах;

2) создание бланков договора предприятия-заказчика с фирмой-поставщиком, заказа на поставку необходимой продукции;

3) выдача краткой справки по работе с программой;

4) подсчет суммы долга к выплате на текущую дату поставщиков предприятию или предприятия поставщикам.

Разработанная АИС позволяет достигнуть следующих результатов:

1) уменьшение времени необходимого для учета поставок, произведенных на предприятие;

2) автоматизация контроля поставок;

3) возможность длительного хранения информации о поставках на предприятие большого срока давности, для возможности более полного расчета эффективности деятельности предприятия;

4) своевременное получение информации о сроках оплаты за осуществленные поставки.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1.Автоматизация сбора, обработки и представления информации /Под ред. С.И. Авдюшина. – М.: Машиностроение, 2005. – 95 с.

2.Автоматизированные информационные технологии в экономике. Под ред. Г.А. Титаренко, М., Компьютер, 1998. –с. 3-4,98-100.

3.Балабанов И.Т. «Основы финансового менеджмента.» – М.:Финансы и статистика, 1995.

4.Бекаревич Ю.Б., Пушкина Н.В. СУБД Access для Windows 2000 в примерах. Санкт-Петербург, BHV, 2003 –с.4-8.

5.Божко В.П. Организационно – методологические основы построения АСИС – М.: МЭСИ, 2004.

6.Брябин В.М. Программное обеспечение персональных компьютеров – М.: Наука, 2005.

7.Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: ФиС, 2000.

8.Григоренко Г.П., Желнинский Г.С., Немчинов В.К. "Технология машинной обработки экономической информации в реальном масштабе времени". Учебное пособие – М.: МЭСИ, 2005, 77 с.