Рефераты

Автоматизация финансово-экономического отдела ТОО "БАК"

Таблица 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 Схема информационных потоков

Структура входной информации осталась неизменной. Таким образом, на входе нашей централизованной системы управления будут “бумажные” данные. Главной функцией клиентских приложений будет обеспечение работоспособного и быстрого интерфейса по вводу данных. За обработку же информации будет отвечать база данных со всеми ее внутренними механизмами.

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

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

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

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

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

3.4 Внедрение, этапы освоения

Создание информационной системы финотдела является реальной задачей ОИС ТОО “БАК ”. Для ее выполнения создана группа, в состав которой входят специалист по финансовому учету, системный инженер по информационным потокам, специалист по удаленным БД, 2 программиста. Я разработал данный дипломный проект в составе этой группы во время практики.

Существующая система финансового учета имеет архив данных по всем операциям и различные отчетности за два года. Это огромный объем информации, который организован в виде электронных таблиц Excel. В этих таблицах данные хранятся в не типизированном виде. С другой стороны, БД системы клиент/сервер предполагает четкую структуризацию всех таблиц, строгое описание формата данных, которые будут в них храниться. Поэтому, если рассматривать возможность перевода всей старой информации из существующей системы в новую, единственным способом будет ручной ввод всех данных. Учитывая специфику работы автоматизированной системы, для этого придется отключать некоторые элементы автоматизации и внутреннего контроля, что для сохранения целостности данных потребует дополнительного программирования.

Существует 2 пути внедрения системы финансового учета в работу компании:

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

2 - перенести только активные данные, такие как незавершенные договора, все данные по операциям за незаконченный отчетный период, и т.д.

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

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

4. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

4.1 Новые технологии и прибыль компании

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

Решение о целесообразности изменения существующей системы управления или создания новой принимается на основе информации:

текущее финансовое состояние предприятия;

направление развития предприятия;

новейшие научно-технические достижения в области управления;

анализ существующей системы управления предприятием;

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

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

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

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

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

Целями совершенствования системы управления являются:

- повышение конкурентоспособности компании;

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

- гибкость и скорость принятия решений;

- надежность хранения информации;

- безопасность секретной информации;

- оперативный контроль за текущим состоянием;

- “прозрачность” управления информацией.

Конкретно для финотдела:

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

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

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

4.2 Измерение эффективности капиталовложений

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

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

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

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

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

- отделение ИС получает ощутимую обратную связь при решении стратегических и тактических вопросов;

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

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

Затраты на создание или модернизацию информационных систем нужно рассматривать скорее как инвестиции, чем расходы. В ТОО “БАК” рассматривают каждый крупный проект в области информационных технологий, как и любой другой инвестиционный проект компании.

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

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

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

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

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

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

При исследовании работы финотдела был сделан вывод, что определяющими будут нематериальные качественные преимущества.

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

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

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

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

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

Страницы: 1, 2, 3, 4


© 2010 Реферат Live