Автоматизация финансово-экономического отдела ТОО "БАК"
* - Эффективная длина кабеля может варьироваться
в зависимости от каждой конкретной сети. С улучшением технологии она
увеличивается.
** - Диапазон скоростей передачи для некоторых
типов кабелей расширяется. Технические достижения в производстве медных
проводов привели к такой скорости передачи сигналов, которую ранее нельзя было
и предположить.[7]
2.3.6 Платы сетевого адаптера
Платы сетевого адаптера - это интерфейс между
компьютером сетевым кабелем. В обязанности платы сетевого адаптера входят
подготовка, передача и управление данными в сети. Для подготовки данных к
передаче по сети плата использует трансивер, который переформатирует данные из
параллельной формы в последовательную. Каждая плата имеет уникальный сетевой
адрес.
Платы сетевого адаптера отличаются рядом
параметров, которые должны быть правильно настроены. В их число входят:
прерывание (IRQ), адрес базового порта ввода/вывода и базовый адрес в памяти.
Чтобы обеспечить совместимость компьютера в
сети, плата сетевого адаптера должна, во-первых, соответствовать архитектуре
шины данных компьютера, и, во-вторых, иметь требуемый тип соединителя с сетевым
кабелем.
Плата сетевого адаптера оказывает значительное
влияние на производительность всей сети. Существует несколько способов
увеличить эту производительность. Некоторые платы обладают дополнительными
возможностями. К их числу, например, относятся:
- прямой доступ к памяти;
- разделяемая память адаптера;
- разделяемая системная память;
- управление шиной.
Производительность сети можно повысить также с
помощью буферизации или встроенного микропроцессора.
При покупке платы сетевого адаптера необходимо
учитывать:
- разрядность шины (32-разрядная
быстрее 16-разрядной);
- тип шины (EISA и MCA быстрее ISA);
- способ передачи данных в память
(разделяемая память быстрее, чем порт вода/вывода или DMA);
- возможность управления шиной;
- авторитет производителя.
На клиентских компьютерах и сервере сети
установлены сетевые платы Intel Ether Express Pro различных модификаций,
которые удовлетворяют большинству вышеперечисленных требований.
В здании АБК ТОО “БАК ” ЛВС функционирует под
управлением сервера Windows NT 4.0. На сегодняшний день эта сетевая
операционная система является наиболее распространенной в организациях и
предприятиях, т.к. она имеет достаточные характеристики, такие как устойчивость
работы, многозадачность, поддержка большинства видов сетевого оборудования и
программного обеспечения.
3.
ТЕХНИЧЕСКИЙ ПРОЕКТ СИСТЕМЫ
3.1 Общий механизм функционирования
системы
Финансовый учет на предприятии - это
всестороннее отображение текущего состояния финансовых ресурсов, всех
действительных операций по движению финансовых ресурсов. Эта очень сложная
деятельность не может быть подвергнута строгой типизации по видам операций,
т.к. в каждом конкретном деловом случае экономисты принимают решения, которые
не всегда могут быть учтены даже в самой сложной программе. Поэтому для
создания системы по автоматизации финансового учета мы будем использовать
концепцию информационно-советующей системы.
Основными задачами финансового учета являются:
·
регулирование
бюджетов отделений;
·
финансовая
отчетность для высших руководителей;
·
учет
и распределение всех видов финансовых средств по назначению;
·
управление
дебиторско-кредиторской задолженностью;
·
решение
потенциальных проблем с платежами до наступления срока сдачи ежемесячного
отчета;
Ключевым моментом при проведении всех операций
по движению финансовых средств является изменение дебиторско-кредиторской
задолженности партнеров-контрагентов компании. Одним из путей объединения всех
потоков информации в базе данных поэтому будет глобальное присвоение всем
создаваемым записям связей с основной таблицей, которая и будет регистрировать
каждый отдельный этап изменения дебиторско-кредиторской задолженности.
Эта методология объединения всех потоков
информации выработана в результате анализа работы финотдела, структуры входящих
и выходных потоков информации. Было произведено обобщение всех связей между
отдельными потоками, в результате была определена структура информации, которая
составляет информационную основу всего механизма работы системы.
Физически эта центральная структура представлена
в виде таблицы БД, все остальные таблицы будут иметь связи на нее. Такой
механизм функционирования системы позволит объединить всю информацию, т.о.
определяется он структурой базы данных.[4]
Реально все выглядит так. Все виды финансовых
операций можно разделить на несколько видов:
·
движения
по расчетному счету и кассе;
·
операции
с ценными бумагами;
·
получение
товарно-материальные ценности;
·
выполнение
работ и услуг;
·
проведение
взаимозачета встречных обязательств;
·
цессии;
·
отгрузка
угля;
·
начисление
за теплоэнергию.
Два последних типа специфичны для компании,
поэтому выделены отдельно.
Каждая из этих операций непосредственно влияет
на дебиторско-кредиторскую задолженность предприятий, с которыми они
проводятся. Потому принято решение, что эти виды операций будут определять
функциональные элементы нашей системы. Т.о. мы имеем 6 первоначальных элементов
системы - функциональных АРМ:
1) Движение
по р/с и кассе;
2) Реестр
векселей;
3) ТМЦ,
работы и услуги по БАК;
4) ТМЦ,
работы и услуги, теплоэнергия по ТЭЦ;
5) Взаимозачеты;
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(хх)
|
Название
|
Листинг основных
участков кода.
Страницы: 1, 2, 3, 4
|