Предметная область "Народная торговая компания"

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

ВВЕДЕНИЕ

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

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

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ

1.1 Описание предметной области

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

Основные сущности предметной области: филиалы, товары, изготовители, покупатели, продажа, ремонт.

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

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

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

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

Продажа состоит в учете стоимости товара, даты покупки и гарантийном периоде товара.

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

Задача управления состоит в учете компанией отремонтированного товаров.

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

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

1.2 Функциональная структура документа как элемента информационного пространства предметной области

В результате обследования предметной области установлено:

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

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

Указанные филиалы занимаются продажей бытовой техники и приемом ее на ремонт;

Название филиалов фиксируются регистрационным номером, начиная с 1;

В базе данных фиксируются изготовители бытовой техники, которые продаются данной компанией;

Изготовитель определяется индикационным номером;

Компания располагает данными о товарах и покупателях;

Товар определяется штрих-кодом, указанным в документе;

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

Продажа данной продукции фиксируется на филиалах и определяется штрих-кодом товара и датой продажи;

Наименования отдельных покупателей не уникальны, конкретный покупатель определяется с помощью его идентификатора;

Гарантийный ремонт фиксируется на филиалах, где указывается дата приема и получения, а так же оставшийся срок гарантии;

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

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

Таблица 1. Характеристика атрибутов документа

№	Поле	Тип	Размер	Описание
1	IDfilial	Числовой	1	Регистрационный номер филиала
2	Filial	Текстовый	20	Название филиала предприятия
3	InnFilial	Текстовый	10	ИНН филиала предприятия
4	Chief	Текстовый	60	Руководитель филиала
5	Capacity	Числовой	3	Количество работающих на ремонте
6	Address	Текстовый	60	Адрес филиала предприятия
7	Phone	Текстовый	12	Номер телефона филиала
8	GoodsID	Текстовый	15	Штрих-код товара
9	Goods	Текстовый	40	Название товара или прибора
10	Categoty	Текстовый	20	Категория (утюг, миксер)
11	Country	Текстовый	20	Страна-производитель
12	Company	Текстовый	40	Изготовитель
13	Picture	Поле объекта OLE	Авто	Фотография товара или прибора
14	INNcompany	Текстовый	10	ИНН изготовителя
15	AddressComp	Текстовый	60	Адрес изготовителя
16	DateStart	Дата/время	Авто	Дата изготовления товара
17	Period	Числовой	4	Гарантийный период
18	DateBuy	Дата/время	Авто	Дата покупки
19	Cost	Денежный	15	Стоимость товара
20	Fax	Текстовый	12	Номер факса компании
21	PhoneCompany	Текстовый	12	Телефон компании
22	Email	Текстовый	20	Адрес электронной почты компании
23	Web	Текстовый	20	Адрес Web-страницы
24	CostRepair	Денежный	15	Стоимость ремонта
25	CustomerID	Числовой	5	Идентификатор покупателя
26	Customer	Текстовый	60	Покупатель
27	AddressCust	Текстовый	60	Адрес покупателя
28	Comment	Поле Memo	Авто	Примечания (что было сделано)
29	Sign	Логический	1	Признак покупателя (юр./физ. лицо)
30	Guarantee	Числовой	5	Оставшийся гарантийный срок
31	StartDate	Дата/время	Авто	Дата приемки в ремонт
32	StopDate	Дата/время	Авто	Дата получения
33	RepairID	Текстовый	6	Номер накладной

1.3 Обзор средств программирования

C++ Builder поддерживает связь с различными базами данных 3-х видов:

dBASE и Paradox: Sybase, Oracle, InterBase и Informix; Excel, Access, FoxPro и Btrieve. Механизм BDE (Borland Database Engine) придает обслуживанию связей с базами данных удивительную простоту и прозрачность. Проводник Database Explorer позволяет изображать связи и объекты баз данных графически. Используя компоненты баз данных, я построил электронную записную книжку по таблице dBASE за полчаса работы на компьютере. Наследование готовых форм и их "подгонка" под специфические требования заметно сокращают временные затраты на решение подобных задач.

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

Благодаря средствам управления проектами, двусторонней интеграции приложения и синхронизации между средствами визуального и текстового редактирования, а также встроенному отладчику (с ассемблерным окном прокрутки, пошаговым исполнением, точками останова, трассировкой и т.п.) - C++ Builder корпорации Borland предоставляет собой впечатляющую среду разработки, которая, видимо, выдержит конкурентную борьбу с такими модными продуктами как Microsoft Developer Studio.

2. ПОСТАНОВКА ЗАДАЧИ

2.1 Основания для разработки

Основанием для разработки является задание преподавателя в соответствии с программой МДК 01.02 "Прикладное программирование".

2.1.1 Требования к функциональным характеристикам

Возможность ввести входные данные с клавиатуры;

Возможность вывести результат на печать;

Входными данными являются:

Информация о товарах, филиале ,компаниях ,покупателях и ремонта товара

Выходными данными являются:

Отчет по ремонту товара

2.1.2 Требования к условиям эксплуатации

Программа должна эксплуатироваться в условиях вычислительного центра при температуре от +15 до +35 С и относительной влажности воздуха от 25 до 85%.

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

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

2.1.3 Требования к техническим средствам

ПЭВМ не ниже Pentium 3;

объем ОЗУ не менее 128 Мбайт;

монитор;

клавиатура;

мышь;

принтер.

2.1.4 Требования к информационной и программной совместимости

Программа должна работать под управлением операционной системы Windows XP, Windows Vista, Windows7.

Файл базы данных Access импортируема в среду разработки C++ builder. Текстовый документ Word на который выводится информация о ремонте

2.1.5 Требования к маркировке и упаковке

Программа должна поставляться на диске в виде исполняемого (еxе) файла.

2.1.6 Требования к транспортировке и хранению

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

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

2.1.7 Требования к программной документации

Должны быть разработаны следующие программные документы:

Текст программы (ГОСТ 19.401-78)

Описание программы (ГОСТ 19.402-78)

Руководство оператора (ГОСТ 19.505-79)

Программа и методика испытаний (ГОСТ 19.301-79)

Описание языка (ГОСТ 19.507-79)

2.1.7 Стадии разработки

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

Технический проект срок сдачи 10.11.2013

Рабочий проект срок сдачи 20.12.2013

2.1.6 Виды испытаний

Приемо-сдаточные испытания проводятся преподавателем.

3. РАЗРАБОТКА БАЗЫ ДАННЫХ

3.1 Универсальная таблица

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

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

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

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

Проверим данное утверждение на нашем примере.

Проблема вставки

Проблема вставки может возникнуть при вводе какого-либо нового вида информации.

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

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

Проблема удаления

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

Итак, если по какой-то причине (к примеру, потеря сведений о продаже товара за 15.04.2011) мы удалим первую строку таблицы Warranty repairs (в которой фиксируется ремонт утюга Philips GC 3321 клиентом Ивановым И. И.), то из полученной БД будет безвозвратно утеряна информация о наличии данного клиента, т.к. в других строках таблицы информация о нем не содержится. Следовательно, можем говорить о наличии проблемы удаления в такой базе данных.

Проблема корректировки

Проблема корректировки данных определяется наличием необоснованной их избыточности. В полученной таблице Warranty repairs такая избыточность присуща атрибутам Filial, IDfilial, InnFilial, Chief, Capacity, Address, Phone, Customer, CustomerID, AddressCust, Sign, которые повторяются много раз в таблице, что повышает вероятность допущения ошибки при вводе и исправлении данных. Следствием этого может стать нарушение целостности данных в таблице. Таким образом, в БД, построенной по таблице Warranty repairs присутствуют все три проблемы (вставки, удаления и корректировки).

3.2 Формулировка ограничений на связи между сущностями предметной области

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

Итак, основными сущностями будут:

Филиалы - определяется атрибутами IDfilial, Filial, InnFilial, Chief, Capacity, Address, Phone.

Товары - идентифицируется атрибутом GoodsID, Goods, Categoty, Country, Company, Picture, DateStart.

Изготовители - идентифицируется атрибутами Company, INNcompany, AdddressComp, Fax, PhoneCompany, Email, Web.

Продажа - определяется атрибутами: CustomerID, GoodsID, Cost, DateBuy, Period.

Клиенты - определяется атрибутами Sign, CustomerID, Customer, AddressCust.

Ремонт - идентифицируется атрибутами RepairID, InnFilial, CustomerID, GoodsID, StopDate, Guarantee, Comment, CostRepair, StartDate. При это атрибут RepairID определяет номер документа, фиксирующего ремонт с указанными при помощи остальных атрибутов параметры.

На основании пунктов 1.2., 1.3., 2.1. можно определить характер связей между основными сущностями:

(Филиалы - Ремонт) - 1 : m

Т.е., один филиал может ремонтировать множество видов товаров.

(Клиенты - Ремонт) - 1 : m

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

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

(Клиенты - Продажа) - 1 : m

Т.е. имеющейся в базе данных клиент может приобрести разные виды товаров данной компании.

(Товары - Ремонт) - 1 : m

Согласно данной связи, товар с одним и тем же штрих-кодом может ремонтироваться на разных филиалах разними покупателями данного товара.

(Товары - Продажа) - 1 : m

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

(Изготовитель - Товары) - 1 : m

Т.е. конкретный изготовитель может производить различные виды бытовой техники.

Далее рассмотрим перечень функциональных зависимостей таблицы Warranty repairs более подробно:

IDfilial > Filial: регистрационный номер филиала однозначно определяет один и тот же филиал.

IDfilial > InnFilial: ИНН филиала является уникальным для одного и того же филиала.

IDfilial > Chief: согласно установленным ограничения, руководитель для филиала с одним и тем же регистрационным номером является одним.

IDfilial > Capacity: количество работающих на определенном филиале одно и то же. В то же время на разных филиалах может совпадать количество работающих на ремонте.

IDfilial > Address: адрес уникален для каждого филиала.

IDfilial > Phone: номер телефона на одном и том же филиале один и тот же.

IDfilial > RepairID: регистрационный номер филиала однозначно определяет номер накладной по ремонту.

RepairID > CostRepair: согласно установленным ограничениям стоимость ремонта одна и та же для одного и того же номера накладной. В то же время стоимость ремонта может совпадать в разных номерах накладной.

RepairID > Comment: один и тот же номер накладной определяет одно и то же примечания в ремонте. Однако примечание может совпадать в разных накладных.

RepairID > Guarantte: оставшийся гарантийный период для одного и того же номера накладной один и тот же. В то же время данный период не уникален и может совпадать с другими номерами накладной.

RepairID > StartDate: в определенном номере накладной указывается определенная дата приема товара в ремонт.

RepairID > StopDate: дата получения одна и та же для одного и того же номера накладной. В то же время дата получения товара не уникальна и может встречаться в других накладных по ремонту.

RepairID > {GoodsID, INNcompany, CustomerID}: атрибут RepairID однозначно определяет в таблице совокупность атрибутов GoodsID, INNcompany, CustomerID.

GoodsID > Goods: штрих-код товара уникален для данного вида товара, поэтому если указан конкретный код во многих строках, то в этих строках таблицы всегда будет одно и тоже наименование товара.

GoodsID > Category: согласно установленным ограничениям категория для отдельного вида товара, определяемого его штрих-кодом, одна и та же. В то же время одна и та же категория может использоваться для различных товаров.

GoodsID > Country: страна-производитель для одного и того же товара является одной и той же. В то же время одна и та же страна-производитель может производить разные виды бытовой техники.

GoodsID > Picture: штрих-код товара уникален для каждого изображения товара.

GoodsID > DateStart: дата изготовления для товара с одним и тем же штрих-кодом является одинаковой.

GoodsID > Period: гарантийный период для одинаковых товаров одинаков.

GoodsID > Cost: стоимость товара одинакова для товаров с одним и тем же штрих-кодом.

GoodsID > DateBuy:

INNcompany > Company: ИНН изготовителя уникален для данного изготовителя, поэтому если указан конкретный ИНН во многих строках, то в этих строках таблицы всегда будет одно и тоже наименование изготовителя.

INNcompany > AdrressComp: для конкретного ИНН изготовителя уникальный адрес.

INNcompany > Fax: определенный изготовитель имеет свой назначенный номер факса.

INNcompany > PhoneCompany: определенным номером телефона обладает один изготовитель.

INNcompany > Email: адрес электронной почты для одного и того же изготовителя является одним и тем же.

INNcompany > Web: изготовитель обладает своей уникальной Web-страницей.

CustomerID > Customer: идентификатор покупателя уникален для каждого клиента.

CustomerID > AddressCust: согласно установленным ограничениям адрес для отдельного клиента, определяемого его идентификатором, один и тот же.

CustomerID > Sign: признак покупателя для отдельного клиента, определяемого его идентификатором, один и тот же. В то же время один и тот же признак может использоваться для разных клиентов.

3.3 Полнота и целостность схемы базы данных

После осуществления декомпозиции исходной таблицы Warranty repairs необходимо проверить полученные в результате таблицы на предмет сохранения полноты и целостности данных. Для проверки на сохранность функциональных зависимостей исходной универсальной таблицы Warranty repairs в таблицах полученной схемы базы данных необходимо составить перечень функциональных зависимостей по форме (табл. 3.4.)

предметный гарантийный база данные

Таблица 3.4. Функциональные зависимости в полученной схеме базы данных

ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ	НАЗВАНИЕ ТАБЛИЦ
УНИВЕРСАЛЬНЫЕ ТАБЛИЦЫ	СХЕМА БД
IDfilial > Filial IDfilial > InnFilial IDfilial > Chief IDfilial > Capacity IDfilial > Address IDfilial > Phone	IDfilial > Filial IDfilial > InnFilial IDfilial > Chief IDfilial > Capacity IDfilial > Address IDfilial > Phone	FILIAL
RepairID > CostRepair RepairID >IDfilial RepairID >GoodsID RepairID >CustomerID RepairID > Comment RepairID > Guarantte RepairID > StartDate RepairID > StopDate	RepairID > CostRepair RepairID >IDfilial RepairID >GoodsID RepairID >CustomerID RepairID > Comment RepairID > Guarantte RepairID > StartDate RepairID > StopDate	REPAIR
GoodsID > Goods GoodsID > Category GoodsID > Country GoodsID > Picture GoodsID > DateStart GoodsID > Period GoodsID > DateBuy GoodsID > Cost	GoodsID > Goods GoodsID > Category GoodsID > Country GoodsID > Picture GoodsID > DateStart GoodsID > Period GoodsID > DateBuy GoodsID > Cost	Goods
INNCompany > PhoneCompany INNCompany > AddressComp INNCompany > Company INNCompany > GoodsID INNCompany > Email INNCompany > Fax INNCompany > Web	INNCompany > PhoneCompany INNCompany > AddressComp INNCompany > Company INNCompany > GoodsID INNCompany > Email INNCompany > Fax INNCompany > Web	company
CustomerID > Customer CustomerID > AddressCust CustomerID > Sign	CustomerID > Customer CustomerID > AddressCust CustomerID > Sign	customer

4. ЭКСПЕРИМЕНТАЛЬНОЕ ИССЛЕДОВАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

В работе разработана информационная система, позволяющая компании координировать процесс гарантийного ремонта на филиалах.

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

Рис.(1)

В меню товары храниться информация о товарах рис(1) . Оператор по мере поступления товаров может занести их в базу данных рис.(1.2)



Рис(1.2)

Рис (1.3)

Если нажать на фотографию товара, то появится увеличенное изображение этого товара рис(1.4)

Рис (1.4)

Меню запрос на товары рис(2.1) фильтрует введенную информацию по товарам по определенным критериям заданным в фильтре рис (2.2)

Рис (2.2)

исходный код фильтра :

void __fastcall TForm3::BitBtn2Click(TObject *Sender)

{

Edit2->Text = Edit2->Text + " AND ";

}

//---------------------------------------------------------------------------

void __fastcall TForm3::BitBtn1Click(TObject *Sender)

{

Edit1->Clear();

}

//---------------------------------------------------------------------------

void __fastcall TForm3::BitBtn7Click(TObject *Sender)

{

Edit2->Clear();

}

//---------------------------------------------------------------------------

void __fastcall TForm3::BitBtn3Click(TObject *Sender)

{

Edit2->Text = Edit2->Text + " OR ";

}

//---------------------------------------------------------------------------

void __fastcall TForm3::BitBtn4Click(TObject *Sender)

{

Edit2->Text = Edit2->Text + " < ";

}

//---------------------------------------------------------------------------

void __fastcall TForm3::BitBtn5Click(TObject *Sender)

{

Edit2->Text = Edit2->Text + " > ";

}

//---------------------------------------------------------------------------

void __fastcall TForm3::BitBtn6Click(TObject *Sender)

{

Form6->ADOTableFil->Filter = Edit2->Text;

Form6->ADOTableFil->Filtered = true;

}

//---------------------------------------------------------------------------

void __fastcall TForm3::ListBox1Click(TObject *Sender)

{

if( ListBox1->ItemIndex == 0)

Edit2->Text = Edit2->Text + "Goods" + "='" + Edit1->Text + "'";

if( ListBox1->ItemIndex == 1)

Edit2->Text = Edit2->Text + "Category" + "='" + Edit1->Text + "'";

if( ListBox1->ItemIndex == 2)

Edit2->Text = Edit2->Text + "Country" + "='" + Edit1->Text + "'";

if( ListBox1->ItemIndex == 3)

Edit2->Text = Edit2->Text + "Period" + "='" + Edit1->Text + "'";

}

Меню ремонт (рис.3) предоставляет информацию о товарах находящихся в ремонте на гарантии



Рис.3

В этом меню можно добавлять и редактировать информацию о товарах находящихся на ремонте рис(3.1)

Рис.3.1

Кнопка отчет выводит информацию в документ формата DOC (рис.3.2)

Исходный код кнопки отчет:

void __fastcall TForm7::Button1Click(TObject *Sender)

{

Variant v1,v;

int Rows,Cols;

Rows = DBGrid1->DataSource->DataSet->RecordCount+1;

Cols = DBGrid1->Columns->Count;

Variant Word = CreateOleObject("Word.Application");

Word.OlePropertySet("Visible", true);

//Делаем наш документ видимым.

Variant Doc = Word.OlePropertyGet("Documents");

Doc.OleProcedure("Add");

if(Doc.OlePropertyGet("Count") != 1)

{

MessageBox(0, "Ошибка при создании документов",

"Ошибка", MB_OK);

return;

}

vVarDoc=Doc.OleFunction("Item",1);

//Смотреть будем тоже на первый документ

vVarDoc.OleProcedure("Activate");

vVarDoc=Doc.OleFunction("Item",1);

//И сделаем его Альбомным и формат А3

vVarDoc.OlePropertyGet("PageSetup").OlePropertySet("PageWidth",29.7*28.35);

vVarDoc.OlePropertyGet("PageSetup").OlePropertySet("PageHeight",42*28.35);

vVarDoc.OlePropertyGet("PageSetup").OlePropertySet("Orientation",1);

vVarDoc.OlePropertyGet("PageSetup").OlePropertySet("TopMargin",28.35);

vVarDoc.OlePropertyGet("PageSetup").OlePropertySet("LeftMargin",28.35);

vVarParagraphs=vVarDoc.OlePropertyGet("Paragraphs");

//Задаем текст для вывода

AnsiString str;

str="Проверка " + Now().DateString();

vVarParagraphs.OleProcedure("Add");

vVarParagraph=vVarParagraphs.OleFunction("Item",1);

v=Word.OlePropertyGet("Selection").OlePropertyGet("Font");

v.OlePropertySet("Size",14);

v.OlePropertySet("Bold",true);

vVarParagraph.OlePropertyGet("Range").

OlePropertySet("Text",str.c_str());

vVarParagraph.OlePropertySet("Alignment",1);

/*Word.OlePropertyGet("ActiveWindow").

OlePropertyGet("ActivePane").

OlePropertyGet("View").

OlePropertySet("Type",6);*/

vVarParagraphs.OleProcedure("Add");

vVarParagraphs.OleProcedure("Add");

vVarParagraph=vVarParagraphs.OleFunction("Item",3);

vVarParagraph.OlePropertySet("Alignment",1);

vVarRange = vVarParagraph.OlePropertyGet("Range");

vVarDoc.OlePropertyGet("Tables").OleFunction("Add",vVarRange,Rows,Cols,1,0);

vVarTable=vVarDoc.OlePropertyGet("Tables").OleFunction("Item",1);

Variant t = vVarTable.OlePropertyGet("Columns");

//Устанавливаем ширину первого столбца

t.OleFunction("Item",3).OlePropertySet("Width",110);

t.OleFunction("Item",4).OlePropertySet("Width",150);

// t.OleFunction("Item",11).OlePropertySet("Width",110);

//Выравниваем таблицу по центру

vVarTable.OlePropertyGet("Rows").OlePropertySet("Alignment",1);

vVarTable.OleFunction("AutoFitBehavior",2);

int i=1;

for(int b=1;b <= Cols;b++)

{

vVarCell=vVarTable.OleFunction("Cell",1,b);

vVarCell.OlePropertySet("VerticalAlignment",1);

vVarCell.OleFunction("Select");

v=Word.OlePropertyGet("Selection").OlePropertyGet("Font");

v.OlePropertySet("Size",12);

v.OlePropertySet("Bold",true);

v1=Word.OlePropertyGet("Selection"). OlePropertyGet("ParagraphFormat");

v1.OlePropertySet("Alignment", 1);

switch(b)

{

case 1:

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text", "ID ремонта");

break;

case 2:

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text","ID товара на ремонте");

break;

case 3:

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text","дата потступления товара");

break;

case 4:

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text","дата окончания ремонта");

}

}

ADOTable1->Open();

ADOTable1->First();

while(!ADOTable1->Eof)

{

vVarCell=vVarTable.OleFunction("Cell",i+1,1);

vVarCell.OlePropertySet("VerticalAlignment",1);

vVarCell.OleFunction("Select");

v=Word.OlePropertyGet("Selection").OlePropertyGet("Font");

v.OlePropertySet("Size",10);

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text",ADOTable1->FieldByName("RepairID")->AsString.c_str());

vVarCell=vVarTable.OleFunction("Cell",i+1,2);

vVarCell.OlePropertySet("VerticalAlignment",1);

vVarCell.OleFunction("Select");

v=Word.OlePropertyGet("Selection").OlePropertyGet("Font");

v.OlePropertySet("Size",10);

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text",ADOTable1->FieldByName("GoodsID")->AsString.c_str());

vVarCell=vVarTable.OleFunction("Cell",i+1,3);

vVarCell.OlePropertySet("VerticalAlignment",1);

vVarCell.OleFunction("Select");

v=Word.OlePropertyGet("Selection").OlePropertyGet("Font");

v.OlePropertySet("Size",10);

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text",ADOTable1->FieldByName("StartDate")->AsString.c_str());

vVarCell=vVarTable.OleFunction("Cell",i+1,4);

vVarCell.OlePropertySet("VerticalAlignment",1);

vVarCell.OleFunction("Select");

v=Word.OlePropertyGet("Selection").OlePropertyGet("Font");

v.OlePropertySet("Size",10);

vVarCell.OlePropertyGet("Range").

OlePropertySet("Text",ADOTable1->FieldByName("stopdate")->AsString.c_str());

i++;

ADOTable1->Next();

}

}

Меню покупатели выводит информацию о покупателях (рис. 4)

Рис.4

Меню филиал/компании выводит информацию о филиалах и компаниях рис.5

Рис.5

Размещено на Allbest.ru

...