Главная страница

ВКР+на+редакцию. Автоматизация финансовоэкономического отдела тоо "бак"


Скачать 254.27 Kb.
НазваниеАвтоматизация финансовоэкономического отдела тоо "бак"
Дата02.10.2022
Размер254.27 Kb.
Формат файлаdocx
Имя файлаВКР+на+редакцию.docx
ТипДокументы
#709090
страница4 из 7
1   2   3   4   5   6   7



Рисунок 3 – Шина
звезда

компьютеры подключены к сегментам кабеля, исходящим из одной точки;

кольцо

компьютеры подключены к кабелю, который замкнут в кольцо

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

С
реди концентраторов различают активные и пассивные концентраторы. Активные регенерируют и передают сигнал также, как это делают репитеры. Пассивные – это коммутирующие блоки, которые пропускают через себя сигнал, не усиливая и не восстанавливая его.
Рисунок 4 – Звезда

Рисунок 5 - Кольцо





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

Использование концентраторов дает ряд преимуществ:

сети, построенные на концентраторах, легко расширить, если подключить дополнительные концентраторы;

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

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

централизованный контроль за работой сети и сетевым трафиком – многие концентраторы наделены диагностическими возможностями.

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

Звезда-шина:

Несколько сетей с топологией звезда объединяются при помощи магистральной линейной шины.

Звезда-кольцо:

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

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

Топология

Преимущества

Недостатки

Шина

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

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

Кольцо

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

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

Звезда

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

Выход из строя центрального узла выводит из строя всю сеть.


Для построения системы мы используем топологию “звезда-шина”. Это позволит наладить надежную работу в сегменте сети финансового отдела, т.к. он будет иметь внутреннюю топологию “шина” (преимущества см. в таблице). На будущее же, общая магистральная шина будет служить физической основой объединения всех отделов в единую информационную систему. Финансовый отдел имеет выделенный вход С4 на концентраторе H34. Общая топологией существующей сети является “звезда-шина”, поэтому во избежание необоснованных расходов топология сети изменяться не будет.

2.3.5 Физическая среда передачи

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

коаксиальный кабель:

тонкий;

толстый.

витая пара:

неэкранированная;

экранированная.

оптоволоконный кабель

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

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

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

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

Характеристика

Тонкий коаксиальный кабель (10Base2)

Толстый коаксиальный кабель (10Base5)

Витая пара (10BaseT)

Оптоволоконный кабель

Стоимость

Дороже витой пары

Дороже тонкого коаксиального кабеля

Самый дешевый

Самый дорогой

Эффективная длина кабеля*

185м

500м

100м

2000м

Скорость передачи**

10МБит/с

10МБит/с

4-100МБит/с

100МБит/с и выше

Гибкость

Довольно гибкий

Менее гибкий

Самый гибкий

Не гибкий

Простота установки

Прост в установке

Прост в установке

Очень прост в установке; может быть установлен при строительстве

Труден в установке

Подверженность помехам

Хорошая защита от помех

Хорошая защита от помех

Подвержен помехам

Не подвержен помехам

Особые свойства

Электронные компоненты дешевле, чем у витой пары

Электронные компоненты дешевле, чем у витой пары

Тот же телефонный провод; часто проложен во время строительства

Поддерживает речь, видео и данные

Рекомендуемое применение

Средние или большие сети с высокими требованиями к защите данных

Средние или большие сети с высокими требованиями к защите данных

“Кольцо” любого размера

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


* - Эффективная длина кабеля может варьироваться в зависимости от каждой конкретной сети. С улучшением технологии она увеличивается.

** - Диапазон скоростей передачи для некоторых типов кабелей расширяется. Технические достижения в производстве медных проводов привели к такой скорости передачи сигналов, которую ранее нельзя было и предположить.[7]
2.3.6 Платы сетевого адаптера

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

Платы сетевого адаптера отличаются рядом параметров, которые должны быть правильно настроены. В их число входят: прерывание (IRQ), адрес базового порта ввода/вывода и базовый адрес в памяти.

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

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

прямой доступ к памяти;

разделяемая память адаптера;

разделяемая системная память;

управление шиной.

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

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

разрядность шины (32-разрядная быстрее 16-разрядной);

тип шины (EISA и MCA быстрее ISA);

способ передачи данных в память (разделяемая память быстрее, чем порт вода/вывода или DMA);

возможность управления шиной;

авторитет производителя.

На клиентских компьютерах и сервере сети установлены сетевые платы Intel Ether Express Pro различных модификаций, которые удовлетворяют большинству вышеперечисленных требований.

В здании АБК ТОО “БАК ” ЛВС функционирует под управлением сервера Windows NT 4.0. На сегодняшний день эта сетевая операционная система является наиболее распространенной в организациях и предприятиях, т.к. она имеет достаточные характеристики, такие как устойчивость работы, многозадачность, поддержка большинства видов сетевого оборудования и программного обеспечения.
3. ТЕХНИЧЕСКИЙ ПРОЕКТ СИСТЕМЫ
3.1 Общий механизм функционирования системы
Финансовый учет на предприятии – это всестороннее отображение текущего состояния финансовых ресурсов, всех действительных операций по движению финансовых ресурсов. Эта очень сложная деятельность не может быть подвергнута строгой типизации по видам операций, т.к. в каждом конкретном деловом случае экономисты принимают решения, которые не всегда могут быть учтены даже в самой сложной программе. Поэтому для создания системы по автоматизации финансового учета мы будем использовать концепцию информационно-советующей системы.

Основными задачами финансового учета являются:

регулирование бюджетов отделений;

финансовая отчетность для высших руководителей;

учет и распределение всех видов финансовых средств по назначению;

управление дебиторско-кредиторской задолженностью;

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

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

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

Физически эта центральная структура представлена в виде таблицы БД, все остальные таблицы будут иметь связи на нее. Такой механизм функционирования системы позволит объединить всю информацию, т.о. определяется он структурой базы данных.[4]

Реально все выглядит так. Все виды финансовых операций можно разделить на несколько видов:

движения по расчетному счету и кассе;

операции с ценными бумагами;

получение товарно-материальные ценности;

выполнение работ и услуг;

проведение взаимозачета встречных обязательств;

цессии;

отгрузка угля;

начисление за теплоэнергию.

Два последних типа специфичны для компании, поэтому выделены отдельно.

Каждая из этих операций непосредственно влияет на дебиторско-кредиторскую задолженность предприятий, с которыми они проводятся. Потому принято решение, что эти виды операций будут определять функциональные элементы нашей системы. Т.о. мы имеем 6 первоначальных элементов системы – функциональных АРМ:

Движение по р/с и кассе;

Реестр векселей;

ТМЦ, работы и услуги по БАК;

ТМЦ, работы и услуги, теплоэнергия по ТЭЦ;

Взаимозачеты;

Уголь.

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

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

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

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

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

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

Коренное различие в работе новой системы по сравнению с предыдущей заключается в том, что раньше информация по проведению операций просто накапливалась, и только потом в при необходимости обрабатывалась для получения некоторых сводных данных. В разрабатываемой системе необходимая информация по деб./кред. задолженности формируется автоматически и непрерывно в течение всего рабочего процесса, что дает возможность получить оперативные сводки в любой момент. Поскольку функциональные элементы в автоматизированной системе реализованы в виде отдельных пользовательских приложений, то в дальнейшем мы не будем не будем проводить различия между этими понятиями. Т.о. система состоит из клиентских приложений и серверной БД.
3.2 “Клиент-серверная“ архитектура
В сегмент сети финансового отдела вводится дополнительный сервер S2 – Windows NT 4.0, на котором устанавливается программный сервер баз данных Borland IB Database 5.0. Клиентские приложения будут выполнятся на компьютерах Windows95, подключенных к сегменту C4.

Далее приводятся рабочие таблицы:
Таблица 8 - Главная таблица MAIN “Оперативная деб./кред. задолженность”

Поле

Описание поля




Имя поля

Тип поля

Код

Уникальный код записи




NPP

INTEGER

Предприятие

юр.лицо по договору




COMPANY

SMALLINT

Дата

дата получения/передачи средств




DATE_PAY

DATE

Дата рег.

дата регистрации записи




DATE_INPUT

DATE

Сумма

Float-значение




SUMMA

FLOAT




"+" - мы передали средства













"-" - мы получили средства










Вид средств

- перечисление с/на расчетный счет

0

TYPE

SMALLINT




- касса

1










- векселя

2










- ТМЦ, работы и услуги

3










- уголь

4










- теплоэнергия

5










- договора-цессии

6







Запись

№ записи в журнале с информацией получении/передаче средств

POINT

INTEGER

Служба

дирекция, курирующая служба, подразделение, отвечающие за исполнение договора

DEPARTMENT

SMALLINT

Договор №

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

CONTRACT

INTEGER

Взаимозачет

Указатель на журнал взаимозачетов




VZACHET

INTEGER


Таблица 9 - CONTRACT “Договор”

№ п/п

Поле

Тип

Назначение

1

NPP

INTEGER

Код

2

NOMER_OUR

VARCHAR(20)

Номер с нашей стороны

3

NOMER_THEM

VARCHAR(20)

Номер с их стороны

4

NOMER_ADD

SMALLINT

Номер доп.соглашения 1-Есть доп. согл.

5

N_JUR_FOLDER

SMALLINT

Номер папки юр.отдела

6

N_JUR_NPP

SMALLINT

Номер договора относительно папки юр.от.

7

N_FIN_FOLDER

SMALLINT

Номер папки фин.отдела

8

N_FIN_NPP

SMALLINT

Номер договора относительно папки фин.от.

9

DATE_INPUT

DATE

Дата регистрации

10

DATE_CONCLUDE

DATE

Дата заключения

11

DATE_END

DATE

Дата исполнения

12

DEPARTMENT

SMALLINT

Код службы

13

COMPANY_PAY

SMALLINT

Код плательщика

14

COMPANY_GET

SMALLINT

Код получателя

15

SUBJECT

SMALLINT

Код группы по предмету договора

16

SUBJECT_FULL

VARCHAR(255)

Предмет договора в полн. варианте

17

SUMMA

FLOAT

Сумма

18

MONEY

SMALLINT

Тип валюты

19

CONDITION

VARCHAR(255)

Условия поставки

20

EXECUTED

SMALLINT

0 - Неисполнен, 1 - Исполнен

21

PARENT

SMALLINT

Код договора, к к-му относится доп.согл.

22

PROLONGATION

SMALLINT

0 - Непродлен, 1 - Продлен

23

REALIS

SMALLINT

1-Реализация иначе приобретение


Таблица 10 - VZACHET “Взаимозачеты”



Наименование поля




Имя поля

Тип поля

1

Код




NPP

INTEGER

2

Дата




DATA

DATE

3

Номер зачета




VZNUM

INTEGER




Приход










4

Плательщик




PAY1

INTEGER

5

Получатель




GET1

INTEGER

6

За что




SUBJECT1

SMALLINT

7

Служба




DEPARTMENT1

SMALLINT

8

Сумма




SUMMA1

FLOAT




Расход










9

Плательщик




PAY2

INTEGER

10

Получатель




GET2

INTEGER

11

За что




SUBJECT1

SMALLINT

12

Служба




DEPARTMENT2

SMALLINT

13

Сумма




SUMMA2

FLOAT

14

Формы оплаты




PAYTYPE

SMALLINT




- перечисление с/на расчетный счет

0










- касса

1










- векселя

2










- ТМЦ, работы и услуги

3










- уголь

4










- теплоэнергия

5










- договора-цессии

6








Таблица 11 - COUNT “Расчетный счет”.

Поле

Описание поля

Имя поля

Тип поля

Код




NPP

INTEGER

Дата

дата выписки из банка

DATA

DATE

Банк




BANK

SMALLINT

Наш р/с




OUR_COUNT

INTEGER

Предприятие

фирма, организация, гос.структура…

COMPANY

INTEGER

Их р/с




COM_COUNT

INTEGER

Их МФО




COM_MFO

INTEGER

Договор №

необязателен

CONTRACT

INTEGER

Назначение

назначение платежа

SUBJECT

SMALLINT

Дата получ тов

Дата исполнения назначения платежа

GET_DATA

DATE

Сумма

Float - значение ( "+" - расход с расчетного счета

SUMMA

FLOAT




"-" - приход на расчетный счет)







Остаток

текущий остаток после каждой операции

REMAINDER

FLOAT


Таблица 12 - PAYDESK “Касса”

Поле

Описание поля

Имя поля

Тип поля

Код




NPP

INTEGER

Дата

дата отчета кассира

DATA




Кассир

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

ACCOUNTER

SMALLINT

Получатель

Получатель/ плательщик

COMPANY

INTEGER

За что




SUBJECT

SMALLINT

Сумма

Float - значение ( "+" - расход с кассы, "-" - приход в кассу)

SUMMA

FLOAT

Остаток кассира

текущий остаток после каждой операции данного кассира

DELTA

FLOAT

Остаток общий

общий текущий остаток после каждой операции

REMAINDER

FLOAT


Таблица 13 - VECSEL “Реестр векселей”

Поле

Имя поля

Тип поля

номер регистрации

NPP

INTEGER

№ акта приема/передачи

ACTNUM

SMALLINT

№ векселя

VECNUM

INTEGER

эмитент

EMITENT

SMALLINT

сумма в рублях

RUBSUM

FLOAT

дата составления

EMISDATE

DATE

дата передачи

SENDDATE

DATE

векселедержатель

VECHOLDER

INTEGER

поставщик

SUPPLIER

INTEGER

№ контракта

CONTRACT

INTEGER

предмет договора

SUBJDET

INTEGER

курирующая служба

SERVICE

SMALLINT

примечание

NOTE

VARCHAR(30)

регион

REGION

SMALLINT

исполнен

EXECUTED

SMALLINT


Таблица 14 - INVOICE “Реестр счет-фактур”

Поле

Описание поля

Имя поля

Тип поля

Код




NPP

INTEGER

Дата рестра




DATA

DATE

№ реестра




NOMER

INTEGER

№счет-факт




NOMER_CI

INTEGER

Дата прихода/отгрузки




EXECDATE

DATE

Договор(ТЭЦ) №




DOGOVOR

VARCHAR(20)

Договор(БАК) №




DOGOV_BAK

INTEGER

Предприятие




FACTORY

INTEGER

Наименование




PRODUCT

INTEGER

Сумма

Сумма по счет фактуре включая НДС и ТехПД

SUMMA

FLOAT




"+" - мы предъявили счет-фактуру










"-" - нам предъявили счет-фактуру







Служба




DEPARTMENT

SMALLINT

Исполнение

1-исполнен, 0-неисполнен

PERFORMED

SMALLINT


Таблица 15 - COAL “Уголь”

Поле

Описание поля

Имя поля

Тип поля

Код




NPP

INTEGER

Дата отгрузки




DATA

DATE

Плательщик

Кому отправлен уголь

COMPANY

INTEGER

№ договора




CONTRACT

INTEGER

№ счет-фактуры

счет-фактура, выписанная за отгруженный уголь

INVOICE

INTEGER

Сумма

Сумма с ж.д.тарифом

SUMMA

FLOAT


Таблица 16 - TEC “Теплоэнергия”

№ п/п

Поле

Тип

Назначение

1

NPP

INTEGER

Код

2

NOMER_DOG

VARCHAR(8)

Номер договора

3

DATA

DATE

Месяц начисления

4

SUMMA

FLOAT

Сумма

5

FACTORY

INTEGER

Предприятие


Все справочные таблицы имеют одинаковую структуру.


№ п/п

Поле

Тип

Назначение

1

NPP

SMALLINT

Код

2

NAME

VARCHAR(хх)

Название


Листинг основных участков кода.

SQL-текст команды создания таблицы Vecsel

CREATE TABLE VECSEL (NPP INTEGER NOT NULL,

ACTNUM SMALLINT NOT NULL,

VECNUM INTEGER NOT NULL,

EMITENT SMALLINT NOT NULL,

RUBSUM DOUBLE PRECISION NOT NULL,

EMISDATE DATE NOT NULL,

SENDDATE DATE,

VECHOLDER INTEGER,

SUPPLIER INTEGER,

CONTRACT INTEGER,

EXECUTED SMALLINT NOT NULL,

NOTE VARCHAR(50) CHARACTER SET WIN1251,

REGION SMALLINT);

CREATE GENERATOR VECSEL_GEN;

CREATE TRIGGER SET_VECSEL FOR VECSEL

ACTIVE BEFORE INSERT POSITION 0

AS BEGIN NEW.NPP=GEN_ID(VECSEL_GEN,1);END;

Текст основного SQL-запроса реестра векселей:

SELECT A.NPP, A.ACTNUM, A.VECNUM, B.NAME EMITENT, A.RUBSUM, A.EMISDATE,

A.SENDDATE, C.NAME VECHOLDER, D.NAME SUPPLIER, E.NOMER_OUR,

F.NAME SUBJECT, G.NAME SERVICE,

A.EXECUTED, A.NOTE, H.NAME REGION

FROM VECSEL A

LEFT OUTER JOIN EMITENT B

ON (A.EMITENT = B.NPP)

LEFT OUTER JOIN COMPANY C

ON (A.VECHOLDER = C.NPP)

LEFT OUTER JOIN COMPANY D

ON (A.SUPPLIER = D.NPP)

LEFT OUTER JOIN CONTRACT E

ON (A.CONTRACT = E.NPP)

LEFT OUTER JOIN REGION H

ON (A.REGION = H.NPP)

LEFT OUTER JOIN SUBJECT F

ON (E.SUBJECT = F.NPP)

LEFT OUTER JOIN DEPARTMENT G

ON (E.DEPARTMENT = G.NPP)

ORDER BY A.NPP

Запрос выводит информацию из таблицы VECSEL и тех таблиц, коды из которых использованы:

COMPANY – справочник по компаниям;

CONTRACT – таблица активных договоров;

REGION – справочник по регионам и энергосистемам;

SUBJECT – справочник по предмету договора;

DEPARTMENT – иерархический справочник по подразделениям компании.

Листинг основного модуля программы vecsel.exe

program Vecsel;

uses Forms, Windows, …

{$R *.RES}

const ProductTitle='Реестр векселей';

var FormPointer:PChar;

hD : HWND;

begin

Application.ShowMainForm:=false;

FormPointer:=PChar(ProductTitle);

hD:=FindWindow('TApplication',FormPointer);

If hD<>0 then

// если программа уже запущена, то вывести главное окно на первый план

SetForegroundWindow(hD)

else

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

begin

Application.ShowMainForm:=true;

Application.Initialize;

Application.CreateForm(TCSTForm, CSTForm);

Application.CreateForm(TMainDM, MainDM);

Application.CreateForm(TMainForm, MainForm);

Application.CreateForm(TExcangeForm, ExcangeForm);

Application.Run;

end;

end.

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

страны;

города;

службы;

виды валют;

компании;

банки;

предмет договора;

пользователи.

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

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

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

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

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

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

в таблицу “Договора” – об исполнении поставщиком своей части контракта;

в главную таблицу – об изменении оперативной задолженности данного контрагента.

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

Бизнес-правила реализуются в виде процедур в базе данных finance.gdb, и при внесении изменений в одни таблицы, они автоматически обновляют данные в других. Образно говоря, бизнес-правила организуют взаимодействие между отдельными таблицами, которые хранят обособленную информацию. Этим мы достигаем цели каждый момент иметь самую последнюю информацию в главной таблице оперативной дебиторско-кредиторской задолженности.[6]
3.3 Схема информационных потоков
1   2   3   4   5   6   7


написать администратору сайта