Реально все выглядит так. Все виды финансовых операций можно разделить на несколько видов:
движения по расчетному счету и кассе;
операции с ценными бумагами;
получение товарно-материальные ценности;
выполнение работ и услуг;
проведение взаимозачета встречных обязательств;
цессии;
отгрузка угля;
начисление за теплоэнергию.
Два последних типа специфичны для компании, поэтому выделены отдельно.
Каждая из этих операций непосредственно влияет на дебиторско-кредиторскую задолженность предприятий, с которыми они проводятся. Потому принято решение, что эти виды операций будут определять функциональные элементы нашей системы. Т.о. мы имеем 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
Сумма
Float-значение
SUMMA
FLOAT
"+" - мы передали средства
"-" - мы получили средства
Вид средств
- перечисление с/на расчетный счет
0
TYPE
- касса
1
- векселя
2
- ТМЦ, работы и услуги
3
- уголь
4
- теплоэнергия
5
- договора-цессии
6
Запись
№ записи в журнале с информацией получении/передаче средств
POINT
Служба
дирекция, курирующая служба, подразделение, отвечающие за исполнение договора
DEPARTMENT
Договор №
первичный договор, если есть (без указания доп.соглашений)
CONTRACT
Взаимозачет
Указатель на журнал взаимозачетов
VZACHET
Таблица 9 - CONTRACT “Договор”
№ п/п
Тип
Назначение
NOMER_OUR
VARCHAR(20)
Номер с нашей стороны
NOMER_THEM
Номер с их стороны
NOMER_ADD
Номер доп.соглашения 1-Есть доп. согл.
N_JUR_FOLDER
Номер папки юр.отдела
N_JUR_NPP
Номер договора относительно папки юр.от.
7
N_FIN_FOLDER
Номер папки фин.отдела
8
N_FIN_NPP
Номер договора относительно папки фин.от.
9
Дата регистрации
10
DATE_CONCLUDE
Дата заключения
11
DATE_END
Дата исполнения
12
Код службы
13
COMPANY_PAY
Код плательщика
14
COMPANY_GET
Код получателя
15
SUBJECT
Код группы по предмету договора
16
SUBJECT_FULL
VARCHAR(255)
Предмет договора в полн. варианте
17
18
MONEY
Тип валюты
19
CONDITION
Условия поставки
20
EXECUTED
0 - Неисполнен, 1 - Исполнен
21
PARENT
Код договора, к к-му относится доп.согл.
22
PROLONGATION
0 - Непродлен, 1 - Продлен
23
REALIS
1-Реализация иначе приобретение
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15