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(хх) Название
Листинг основных участков кода.

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-запросы. Это дает три хороших момента:

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

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

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

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

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

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

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

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

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

3.3 Схема информационных потоков

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Информация о работе «Автоматизация финансово-экономического отдела ТОО "БАК"»
Раздел: Финансовые науки
Количество знаков с пробелами: 131991
Количество таблиц: 20
Количество изображений: 4

Похожие работы

Скачать
67939
0
1

... операций в области сбыта и учета реализованной продукции применительно к заводу «Пластмасс». •    Содержательная постановка и реализация проекта «Учет готовой продукции на предприятии и ее реализации». • Расчет экономической эффективности по разработанным методическим положениям. 1 Место и роль объекта исследования экономической системы   Федеральное Государственное Унитарное предприятие ...

Скачать
115946
18
15

... Для их замены у предприятия на сегодня средства отсутствуют. Глава 3. Технико-экономическое обоснование мероприятий по повышению эффективности деятельности ТЭП ОАО «НефАЗ» 3.1. Техническая суть мероприятий и организация их реализации. Основными мероприятиями по повышению эффективности деятельности Транспортно-экспедиционного предприятия являются: 1. Повышение производительности подвижного ...

Скачать
826315
4
1

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

Скачать
121554
14
0

... законодательством, направлены на обеспечение полной и достоверной информации внутренних и внешних показателей финансовой отчетности .(прил. 23). 3. ОРГАНИЗАЦИЯ ФИНАНСОВОГО ПЛАНИРОВАНИЯ В «НАВЛИНСКИХ МИС» ФИЛИАЛА ГУП «БРЯНСКОБЛЖИЛКОМХОЗ» 3.1 Организация планирования на предприятии Планирование – это разработка и корректировка плана, включающие предвидение, обоснование, конкретизацию и ...

0 комментариев


Наверх