Проектирование реализации операций бизнес-процесса «Продажи» (Характеристика существующих бизнес – процессов)

Содержание:

Введение

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

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

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

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

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

СУБД - программные средства, предназначенные для создания, наполнения, обновления и удаления баз данных.

Объектом исследования в курсовой работе является ООО «Максимум».

Цель работы - проектирование реализации операций бизнес-процесса «Продажи». Поставленной целью определены основные задачи исследования:

- дать оценку бизнес-процессу «Продажи»;

- провести анализ предметной области;

- спроектировать реализацию операций бизнес-процесса «Продажи».

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

1.1. Выбор комплекса задач автоматизации

Предметная область - частное предприятие ООО «Максимум».

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

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

1) Продвижение на рынок продукции, технологий и решений фирмы "1С" (Россия);

2) Увеличение объёмов предоставляемых услуг. С каждым годом фирма растет в качественном и количественном плане - происходит более четкая структуризация внутри фирмы, пополняется штат сотрудников;

3) Обеспечение условий для успешной деятельности персонала;

4) Получение максимальной прибыли.

1.2. Характеристика существующих бизнес – процессов

Бизнес-процесс продажи программного обеспечения (ПО) «1С» проистекает следующим образом:

Фирма-покупатель производит заказ на покупку прикладного решения – программной конфигурации, разработанной в системе 1С:Предприятие, способной решить задачу по автоматизированной обработки начисления заработной платы сотрудникам фирмы. Представитель фирмы отправляет запрос менеджеру по поводу приобретения данного программного продукта, после чего фирма ООО «Максимум» заключает с клиентом юридические соглашения в форме договора о поставке ПО «1С». Затем программисту 1С выдаётся задание адаптировать требуемую программную конфигурацию за определённые сроки.

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

Фирма-покупатель (Клиент)

ФИРМА

ООО

«МАКСИМУМ»

Поступление заказа

Заключение договора

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

Разработка требуемого ПО

Внутрифирмовая поддержка

Рис.1. Схема бизнес-процесса между фирмой «Максимум» и фирмой-клиентом

1.3. Характеристика документооборота, возникающего при решении задачи

В основе бизнес-процесса данной фирмы можно выделить следующие информационные объекты:

- Клиент (фирма-покупатель)

- Менеджер

- Программист

- Бухгалтер

- Заказ

- Договор

- ПО «1С: Предприятие»

- Счёт.

4) Отображение функциональных связей между информационными объектами:

Клиент

Делает

Оплачивает Заказ Подписывает

Подтверждает Охватывает

Счёт Включает ПО «1С» Определяет Договор

Выдаёт Формирует Составляет

Бухгалтер Программист Менеджер

Рис.2. Функциональные связи между информационными объектами

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

Формулировка требований к ИС:

- получение сведений о клиентах

- информация о заказе, что представляет собой ПО «1С»

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

- информация о продаже и сопровождении 1С: Предприятие

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

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

Программа должна работать под управлением операционных систем Windows XP SP2 или Windows XP SP3.

На компьютере должна быть установлена клиент-серверная СУБД Oracle XE, работающая с БД.

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

2.1. Информационная модель и её описание

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

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

Концептуальная модель данных включает следующее:

1. типы сущностей;

2) типы связей;

3) атрибуты;

4) домены атрибутов;

5) потенциальные ключи;

6) первичные ключи.

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

Сущность	Описание сущности
Клиент	Сведения о клиенте
Заказ	Характеристика заказа
Счёт	Информация об оплате
ПО «1С:Предприятие»	Данные о программном обеспечении (ПО)
Договор	Информация о договоре
Менеджер	Данные о менеджере
Программист 1С	Данные о программисте 1С
Бухгалтер	Данные о бухгалтере

Таблица 1. Определение сущностей

2.3. Характеристика результатной информации

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

Сущность		Связь	Сущность
Клиент		Делает	Заказ
Заказ		Охватывает	ПО «1С:Предприятие»
Договор		Определяет	ПО «1С:Предприятие»
Менеджер		Составляет	Договор
Клиент		Подписывает	Договор
Программист 1С		Формирует	ПО «1С:Предприятие»
Бухгалтер		Выдаёт	Счёт
Счёт		Включает	ПО «1С:Предприятие»
Счёт		Подтверждает	Заказ
Клиент	Оплачивает			Счёт

Таблица 2. Взаимосвязи между сущностями

Теперь определим кардинальность и степень участия каждой из связей:

1. Клиент делает Заказ

Один клиент в разное время может производить несколько заказов. Один заказ принадлежит только одному клиенту и поэтому между сущностями КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один ко многим».

Классы принадлежности сущностей КЛИЕНТ и ЗАКАЗ являются обязательными, так как каждый клиент должен сделать хотя бы один заказ, а любой заказ обязательно делается каким-либо клиентом.

1. Заказ охватывает ПО «1С:Предприятие»

Каждое программное приложение может быть указано в нескольких заказах, а каждый заказ должен охватывать хотя-бы одно ПО «1С». Следовательно, тип связи между сущностями ПО «1С» и ЗАКАЗ – «один ко многим».

В любом заказе каждое ПО «1С» может быть либо указано, либо нет, но в каждый заказ обязательно должно быть включено программное приложение. Из этого следует, что класс принадлежности сущности ЗАКАЗ является обязательным, а сущности ПО «1С» - необязательным.

1. Договор определяет ПО «1С:Предприятие»

Каждое программное приложение может быть указано в нескольких договорах, а в любом договоре должно быть определено хотя-бы одно ПО «1С». Следовательно, тип связи между сущностями ПО «1С» и ДОГОВОР – «один ко многим».

В любом договоре каждое программное приложение может быть либо указано, либо нет, но в каждом договоре обязательно должно быть определено программное приложение. Из этого следует, что класс принадлежности сущности ДОГОВОР является обязательным, а сущности ПО «1С» - необязательным.

1. Клиент подписывает Договор

Клиент может подписать только один договор в случае приобретения одного или нескольких прикладных решений «1С» и каждый договор может быть заключен только одним клиентом. Значит, взаимосвязь между сущностями КЛИЕНТ и ДОГОВОР определяется как «один к одному».

Каждый клиент, приобретая программное приложение должен заключить с фирмой договор, а каждый договор обязательно должен быть подписан клиентом. Поэтому степени участия в данной связи сущностей КЛИЕНТ и ДОГОВОР являются обязательными.

1. Менеджер составляет Договор

Менеджер может составить несколько договоров в случае заключения юридических отношений с несколькими фирмами-клиентами, но каждый договор может быть составлен только одним менеджером. Значит, взаимосвязь между сущностями МЕНЕДЖЕР и ДОГОВОР определяется как «один ко многим».

Менеджер, заключая юридические отношения должен составить договор, а каждый договор обязательно должен быть составлен менеджером. Поэтому степени участия в данной связи сущностей МЕНЕДЖЕР и ДОГОВОР являются обязательными.

1. Программист формирует ПО «1С:Предприятие»

Программист 1С может разработать или изменить несколько программных приложений, но каждое приложение может быть разработано одним программистом. Поэтому связь между сущностями ПРОГРАММИСТ и ПО «1С:Предприятие» имеет тип «один ко многим».

Программист 1С должен обязательно разработать программное приложение, а каждое программное приложение должно быть разработано программистом, поэтому степени участия в данной связи сущностей ПРОГРАММИСТ 1С и ПО «1С:Предприятие» являются обязательными.

1. Бухгалтер выдаёт Счёт

Бухгалтер может выдать несколько счетов, но каждый счет должен быть выдан одним бухгалтером. Поэтому связь между сущностями БУХГАЛТЕР и СЧЁТ имеет тип «один ко многим».

Бухгалтер должен обязательно выдать счёт, а каждый счёт должен быть выдан бухгалтером, поэтому степени участия в данной связи сущностей БУХГАЛТЕР и СЧЁТ являются обязательными.

1. Счет включает ПО «1С:Предприятие»

О продаже каждого ПО свидетельствует счет. Может быть предъявлено несколько счетов на оплату покупки нескольких ПО «1С». Между сущностями СЧЁТ и ПО «1С:Предприятие» можно установить связь «многие ко многим».

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

1. Счет подтверждает Заказ

Каждый заказ подразумевает оформление одного или нескольких счетов, а каждый счёт подтверждает только один заказ. Следовательно, между сущностями СЧЁТ и ЗАКАЗ существует связь «один ко многим».

Заказ на ПО подтверждает выписанный и оплаченный счет. Любой счет не может быть выписан без факта заказа. Поэтому степени участия сущностей СЧЁТ и ЗАКАЗ являются обязательными.

1. Клиент оплачивает Счет

Клиент может в случае приобретения нескольких прикладных решений оплатить несколько счетов, но каждый счет может быть оплачен только одним клиентом. Значит, взаимосвязь между сущностями КЛИЕНТ и СЧЕТ определяется как «один ко многим».

Каждый клиент оплачивает хотя бы один счет, а каждый счет обязательно должен быть оплачен клиентом. Поэтому степени участия в данной связи сущностей КЛИЕНТ и СЧЕТ являются обязательными.

2.4. Общие положения (дерево функций и сценарий диалога)

ER-диаграмма концептуальной модели бизнес-процесса фирмы «Максимум» приведена на рис. 3.

1 1 1

Клиент

Делает

Подписывает

М

Оплачивает

Заказ

1

Подтверждает

М

Охватывает

1

М

М М М 1 1 М

Определяет

Включает

Договор

ПО «1С»

Счёт

М М М

Составляет

Выдаёт

Формирует

1 1 1

Менеджер

Бухгалтер

Программист

– обязательная степень участия сущности в связи,

– необязательная степень участия сущности в связи.

Рис. 3. ER-диаграмма концептуальной модели бизнес-процесса фирмы «Максимум»

2.5. Характеристика базы данных

Построение и проверка логической модели данных на основе представлений о предметной области.

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

Итак, проанализируем ER-диаграмму концептуальной модели бизнес-процесса фирмы «Максимум» (рис. 3) с учетом правил проектирования БД из ER-диаграммы. В данном случае можно выделить следующие отношения:

1) Клиент Делает Заказ

Таблицы:

«Клиент» (Уникальный ключ клиента, …);

«Заказ» (Уникальный ключ заказа, Уникальный ключ клиента,…).

2) Заказ Охватывает ПО «1С:Предприятие»

Таблицы:

«Заказ» (Уникальный ключ заказа,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный ключ заказа,…).

3) Договор Определяет ПО «1С:Предприятие»

Таблицы:

«Договор» (Уникальный ключ договора,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный ключ договора,…).

4) Клиент Подписывает Договор

Таблицы:

«Клиент» (Уникальный ключ клиента, …);

«Договор»(Уникальный ключ договора, Уникальный ключ клиента,…).

5) Менеджер Составляет Договор

Таблицы:

«Менеджер» (Уникальный ключ менеджера, …);

«Договор»(Уникальный ключ договора, Уникальный ключ менеджера,…).

6) Программист Формирует ПО «1С:Предприятие»

Таблицы:

«Программист» (Уникальный ключ программиста,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный ключ программиста,…).

7) Бухгалтер Выдаёт Счёт

Таблицы:

«Бухгалтер» (Уникальный ключ бухгалтера,…);

«Счёт» (Номер записи, Уникальный ключ бухгалтера,…).

8) Счёт Включает ПО «1С:Предприятие»

Таблицы:

«Счёт» (Уникальный номер счёта,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный номер счёта,…).

9) Счёт Подтверждает Заказ

Таблицы:

«Счёт» (Уникальный номер счёта,…);

«Заказ» (Уникальный ключ заказа, Уникальный номер счёта,…).

10) Клиент Оплачивает Счёт

Таблицы:

«Клиент» (Уникальный ключ клиента,…);

«Счёт» (Уникальный номер счёта, Уникальный ключ клиента,…).

2.6. Структурная схема пакета (дерево вызова программных модулей)

Разработка программного приложения включает в себя следующие этапы:

- выбор и обоснование среды программирования;

- разработка пользовательского интерфейса;

- подготовка отчётных данных.

В качестве среды для разработки программного интерфейса была выбрана объектно-ориентированная среда программирования Borland Delphi 7. Эта среда, предназначенная для разработки приложений в архитектуре клиент-сервер.

Преимущества Delphi по сравнению с другими программными продуктами:

1) Быстрота разработки приложения;

2) Высокая производительность разработанного приложения;

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

4) Возможность полного доступа к функциям операционных систем Windows;

5) Hаращиваемость за счет встраивания новых компонент и инструментов в среду Delphi.

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

1. Формирование базы данных Oracle в среде Delphi;
2. Автоматизация заключения договоров и выдачи счетов;
3. Создание формы для выбора определённых записей;
4. Создание поисковой системы;
5. Создание справочной системы.

Для подключения базы данных «Максимум» в среду Delphi, которая была спроектирована в СУБД Oracle будем использовать технологию Microsoft ActiveX Data Objects (ADO), которая основана на возможностях СОМ, а именно интерфейсов OLE DB.

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

В Палитре компонентов Delphi со страницы ADO, содержащей набор компонентов, позволяющих создавать полноценные приложения БД, на форме разместим следующие компоненты:

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

2) ADOTable, - таблица базы данных, подключается к ADOConnection;

Помимо этих стандартных компонентов, инкапсулирующих набор данных, на форме необходимо для подключения таблиц расположить также компонент DataSource со страницы Data Access, обеспечивающий связь компонента отображения-редактирования данных (например, компонента DBGrid) и источника данных, в качестве которого может выступать таблица (компонент Tаblе) или результат выполнения SQL-запроса к таблице (компонент SQL) и визуальный компонент DBGrid, отображающий подключённую таблицу БД.

Для удобного расположения таблиц на форме воспользуемся компонентом PageControl со страницы Win32 и создадим в нём восемь вкладок (компонент TabSheet, входящий в компонент PageControl), каждая из которых будет соответствовать определённой таблице базы данных.

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

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

1. Подключить;
2. Добавить запись;
3. Сохранить запись;
4. Удалить запись;

Расположим эти кнопки также на каждой вкладке TabSheet компонента PageControl.

Подключение таблиц в компонент DBGrid будет осуществляться следующим образом:

1) в палитре свойств компонента ADOConnection выбираем свойство ConnectionString, нажимаем на кнопку с троеточием, затем нажимаем кнопку Build, появится окно «Свойства связи с данными», в списке поставщиков данных которого выбираем: Oracle Provider for OLE DB.

Рис.4 Выбор подключаемого драйвера

Нажав Далее, попадаем на вкладку «Подключение», где указываем имя и пароль базы данных. После этого в строку ConnectionString автоматически занесётся путь источника подключаемых данных. В свойстве LoginPrompt выставим значение False для того, чтобы программа не запрашивала при запуске имя пользователя и пароль.

2) соединяем компонент ADOTable с ADOConnection при помощи свойства Connection, а в свойстве TableName выбираем из списка нужную таблицу БД и выставляем значение Active в True.

3) соединяем компонент DataSource с ADOTable через свойство DataSet.

Для полного подключения и отображения таблицы БД в компоненте DBGrid необходимо установить значение свойства DataSource в DataSource, соответствующий подключаемой таблице. Однако мы сделаем это программно, поскольку у нас есть кнопка «Подключить», в обработчике события которой необходимо прописать следующий код:

DBGrid1.DataSource:=DataSource1; // для подключения таблицы 1

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

ADOTable1.Insert; // добавление записи в таблицу 1

ADOTable1.Next; // сохранение записи в таблице 1

ADOTable1.Delete; // удаление записи из таблицы 1

В результате проделанных действий окно интерфейса уже будет иметь вид:

Рис.5 Табличная форма базы данных «Максимум»

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

Для решения поставленной задачи создадим на форме панель «Регистрация», которая будет включать два переключателя: «Договора» и «Счета» (рис.6). При этом предварительно должны быть созданы новые формы – форма регистрации договоров и форма регистрации счетов.

Рис.6 Панель «Регистрация»

В обработчике события переключателя «Договора» пропишем следующий код:

Листинг 1. Процедура обработки события «Регистрация договоров»

// форма регистрации договоров

Form3.Show;

// реквизиты договора из таблицы "Договор"

Form3.Edit1.Text:=DBGrid4.DataSource.DataSet.FieldByName('ID').AsString;

Form3.Edit2.Text:=DBGrid4.DataSource.DataSet.FieldByName('Predmet').AsString;

Form3.Edit3.Text:=DBGrid4.DataSource.DataSet.FieldByName('DATA_ZAKLYCHENIA').AsString;

Form3.Edit4.Text:=DBGrid4.DataSource.DataSet.FieldByName('SUMMA').AsString;

Form3.Edit5.Text:=DBGrid4.DataSource.DataSet.FieldByName('SROK_ISPOLNENIA').AsString;

Form3.Edit6.Text:=DBGrid4.DataSource.DataSet.FieldByName('OBJEM_PRODAG').AsString;

Form3.Edit7.Text:=DBGrid4.DataSource.DataSet.FieldByName('ID_KLIENT').AsString;

Form3.Edit8.Text:=DBGrid4.DataSource.DataSet.FieldByName('ID_MENEDGER').AsString;

// реквизиты договора из таблицы "Клиент"

Form3.Edit9.Text:=DBGrid1.DataSource.DataSet.FieldByName('ID').AsString;

Form3.Edit10.Text:=DBGrid1.DataSource.DataSet.FieldByName('NAME_FIRMA').AsString;

Form3.Edit11.Text:=DBGrid1.DataSource.DataSet.FieldByName('ADRES').AsString;

Form3.Edit12.Text:=DBGrid1.DataSource.DataSet.FieldByName('RASHETNIY_SHET').AsString;

Form3.Edit13.Text:=DBGrid1.DataSource.DataSet.FieldByName('KOD_EDRPO').AsString;

Form3.Edit14.Text:=DBGrid1.DataSource.DataSet.FieldByName('FIO_DIRECTOR').AsString;

Form3.Edit15.Text:=DBGrid1.DataSource.DataSet.FieldByName('BANK').AsString;

Form3.Edit16.Text:=DBGrid1.DataSource.DataSet.FieldByName('MFO').AsString;

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

Нажатие на кнопку «Экспортировать в Word» автоматически сформирует нам типичный договор купли-продажи в документе Word. Подтянутые реквизиты в Word будут выделены жирным шрифтом. После экспорта реквизитов договора в Word станет доступна кнопка «Сохранить C:\Договор.doc», которая позволит сохранить сформированный документ на жёстком диске.

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

1. Обновить "Договор" (для отражения изменений реквизитов в таблице «Договор»);
2. Обновить "Счет" (для отражения изменений реквизитов в таблице «Счёт»);
3. Обновить "Клиент" (для отражения изменений реквизитов в таблице «Клиент»);

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

Например, процедура обработчика событий при нажатии на кнопку Обновить "Договор" будет следующая:

Листинг 2. Процедура обработки события «Обновить договор»

// обновление для таблицы "Договор"

ADOTable4.Edit;

ADOTable4.FieldByName('Predmet').AsString:=Form3.Edit2.Text;

ADOTable4.FieldByName('Data_zaklychenia').AsString:=Form3.Edit3.Text;

ADOTable4.FieldByName('Summa').AsString:=Form3.Edit4.Text;

ADOTable4.FieldByName('Srok_ispolnenia').AsString:=Form3.Edit5.Text;

ADOTable4.FieldByName('Objem_prodag').AsString:=Form3.Edit6.Text;

ADOTable4.Post;

BitBtn2.Enabled:=False;

Form3.Close;

Форма регистрации счетов аналогична форме договоров, однако есть отличие. Поскольку при выдаче счёта на оплату услуг необходимо учитывать такой реквизит как «сумма», то мы дополнительно должны создать в этой форме новые реквизиты:

1. Количество // этот реквизит мы вводим
2. Цена // этот реквизит мы выбираем из списка
3. Сумма // этот реквизит будет рассчитываться как Количество*Цена.

Здесь реквизит «Цена» соответствует полю «Сумма» из таблицы «Договор». Необходимо выбрать из списка соответствующую цену.

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

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

Пройдя по «маршруту» Данные – Договора – Выбрать на экране появится окно «Список договоров». В этом окне мы разместим панель «Список договоров», внутри которого разместим компонент DBLookupComboBox со страницы Data Controls, компоненты для подключения таблицы «Договор» и две кнопки «Изменить» и «Назад в Базу Данных».

В свойстве компонента DBLookupComboBox ListSource выставим значение DataSource1, а в свойстве KeyField – ID. Этот компонент будет выводить список всех номеров договора, среди которых можно выбрать интересующий. Выбрав договор на экране отобразятся компонент DBGrid1 и кнопки. При этом курсор установится в ту запись поля ID, которая была выбрана из списка.

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

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

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

1. ComboBox1 – для отображения списка полей таблицы;
2. Edit1 – Edit6 – для ввода значений;
3. Button1 – Button6 – кнопки «Найти»;
4. Кнопка «Назад» - для возврата в БД.

Рис.7 Форма «Поиск договоров»

2.7. Контрольный пример реализации проекта и его описание

Физическая организация для базы данных «Максимум» в СУБД Oracle включает следующие таблицы:

Рис. 8. Таблица «Бухгалтер»

Рис. 9. Таблица «Договор»

Рис. 10. Таблица «Клиент»

Рис. 11. Таблица «Менеджер»

Рис. 12. Таблица «ПО»

Рис. 13. Таблица «Программист»

Рис. 14. Таблица «Счет»

Рис. 15. Таблица «Заказ»

После того, как мы создали и заполнили таблицы базы данных в Oracle перейдём к этапу написания запросов на языке SQL.

1) Запрос: «Список ПО с указанием фирм-производителей»

Рис. 16. Запрос «Список ПО с указанием фирм-производителей»

2) Запрос: «Рейтинг программ по объёмам продаж с указанием номера и предмета заказа»

Рис. 17. Запрос «Рейтинг программ по объёмам продаж с указанием номера и предмета заказа»

3) Запрос: «Рейтинг менеджеров, осуществивших продажи за прошедший месяц»

Рис. 18. Запрос «Рейтинг менеджеров, осуществивших продажи за прошедший месяц»

4) Запрос: «Список клиентов, осуществивших заказ в прошлом году»

Рис. 19. Запрос «Список клиентов, осуществивших заказ в прошлом году»

5) Запрос: «Список договоров с указанием суммы»

Рис. 20. Запрос «Список договоров с указанием суммы»

Заключение

В данной курсовой работе была спроектирована реализация операций бизнес-процесса «Продажи». Результатом стала база данных по предметной области ООО «Максимум».

Была составлена концептуальная модель представления данных в виде ER-диаграммы, логическая и физическая модель в среде реляционной СУБД Oracle XE. Был разработан программный интерфейс в среде программирования Borland Delphi 7 с целью автоматизации управления работой сотрудников «Максимум» по продаже системы «1С» на заказ по договору. Все поставленные задачи выполнены.

Список литературы

1. Базы данных: модели, разработка, реализация / Т.С. Карпова. – СПб.: Питер, 2012;
2. Система программирования Delphi. – СПб.: БХВ – Петербург, 2014;
3. Базы данных. Учебно-методическое пособие / В.Н. Яхонтова. – Казань: Академия управления “ТИСБИ”, 2014;
4. Базы данных и приложения. Лекции и упражнения. – СПб.: ООО “ДиаСофтЮП”, 2002;
5. Основы программирования в Delphi – Н.Культин;

6. Работа с базами данных в Delphi / В.Э. Гофман, А.Д. Хомоненко – СПб.: КОРОНА принт, 2010.