Реализация расчета платежного баланса предприятий железнодорожной отрасли на основе языка FRIZ

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

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

Описанная выше система формирования платежных балансов (далее Система) представляет собой механизм оперативного управления финансовыми потоками, обеспечивающий:

• -    поддержание платежеспособности и финансовой устойчивости;

• -    эффективность оперативного управления финансовыми ресурсами;

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

• -    контроль за целевым использованием средств;

• -    оптимизацию дебиторской и кредитор- | ской задолженностей.

Результаты исследования. Анализируя процесс формирования ПБ, необходимо принять во внимание следующие факты:

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

• -    документы предоставляются руководству в печатном или электронном виде (т.е. в виде отдельных фалов);

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

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

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

Записывать присланное филиалом новое или откорректированное значение сразу в БД бессмысленно, т.к. базы данных не обладают возможностью перерасчета значений по формулам. Т.е. если в ячейку электронной таблицы можно поместить формулу расчета, то аналогичное действие в ячейке БД выполнить невозможно без использования специальных языков обработки данных, которыми методологи, выполняющие заполнение расчетных форм, не владеют. Подобные задачи решаются разработкой специальных программ, на встроенных в СУБД (и в другие платформы) языках программирования (ABAP [3],

JAVA [1], SQL [5] и др.). Такая программа может выполнить перерасчет всех зависимых значений в БД, если будут известны формулы перерасчета. Поэтому в БД необходимо хранить пассивную формулу расчета, как строку. При необходимости получить актуальные данные пользователь должен воспользоваться подпрограммой (синтаксическим анализатором и интерпретатором формул), которая просмотрит базу данных, выявит строки расчетных формул, выполнит синтаксический анализ и разбор формулы на отдельные функции, знаки операций и константы с последующим расчетом окончательного значения (на основе разобранных частей формулы).

Т.к. в отрасли железнодорожных перевозок достаточно давно эксплуатируется ERP-система [4] целесообразно использовать встроенный в нее язык программирования высокого уровня «ABAP» [3] для разработки синтаксического анализатора и интерпретатора формул, работающего на стороне сервера базы данных и сервера приложений. Реализация данной программы не вызывает трудностей, т.к. синтаксис формул подсчета платежного баланса достаточно простой, формула может выглядеть, например, так:

(1234~123456|01|01 + … + 2234~123456|01|02 – ЯНВ(2234|01|03)) * 1,2

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

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

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

Для разработки данного языка потребовалось пройти следующие этапы:

• -    выполнить анализ задач, которые должен решать язык программирования;

• -    разработать операторы языка для решения выявленных задач;

• -    разработать синтаксический анализатор операторов языка;

• -    разработать интерпретатор операторов языка;

• -    разработать графический интерфейс для программиста (IDE);

• -    разработать набор инструментов для облегчения написания программ.

В качестве инструмента для разработки был выбран язык Visual Basic for Application [2], который встроен в табличный процессор. Разработанный язык получил название FriZ.

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

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

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

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

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

Общая иерархия статей ПБ

статья 1

/статья 2

показатель 1

показатель 2

| показатель 3 статья 3

Форма 1

Форма 1

показатель 1

показатель 2 показатель 3

Статья 4

статья 5 показатель 1

| показатель 2 статья 6

статья 2

показатель 1

показатель 2

показатель 3

Форма 2

Рис. 1. Встраивание отчетной формы в общую иерархию статей ПБ

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

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

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

Запрограммированная методологом методика поступает на вход транслятору языка FriZ, который генерирует файл расчета платежного баланса. Последней операцией методолога служит загрузка полученного файла расчета ПБ в БД Системы. Пример участка загружаемого файла расчета ПБ, с формулами расчета в специальном формате, представлен на рисунке 2.

Единица планирования			Тип	Формула
1100	01	1	F	1110 01 1+1120 01 1+1130 01 1+1135 01 1+1150|01|1+1160|01|1+1170|01|1+1190|01|1*1199|01|1
1100	21	1	F	1110 21 1+1120 21 1+1130 21 1+1135 21 1+1150|2111+1160|2111+1170|2111+1190|2111+1199|21|1
1100	61	1	F	1110 61 1+1120 61 1+1130 61 1+1135 61 1+1150|61|1+1160|61|1+1170|61|1+1190|61|1+1199|61|1
1100	81	1	F	1110 81 1+1120 81 1+1130 81 1+1135 81 1+1150|81|1+1160|81|1+1170|81|1+1190|81|1*1199|81|1
1100	00	1	F	1100 01 1+1100 21 1+1100 61 1+1100 81 1
1110	01	1	I
1110	21	1	I
1110	61	1	L
1110	81	1	L
1110	00	1	F	1110|01|1 + 1110|21|1 + 1110|61|1 + 1110|81|1

Рис. 2. Пример участка загружаемого файла расчета ПБ

В таблице на рисунке 2 в первом столбике указан адрес (единица планирования) куда будет загружена формула в БД, в столбце 2 указан тип загружаемых данных (F-расчетная формула, I-ручной ввод данных, L-данные загружаются из другой БД).

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

№ статьи	Наименование статьи	виды деятельности:				ИТОГО денежные средства
		Перевозочные виды деятельности	Прочие виды деятельности	Инвест, деятельность	Прочие доходы н расходы
1.	2.		4.	5.	6.	7
1100	Финансирование затрат на оплату труда - всего, в т.ч.	1 550	1650	1 750	1 850	6 800
1110	расчеты по фонду оплаты труда	110	120	130	140	500
1120	оплата проезда железнодорожников по личным надобностям - всегот в т.ч.	250	270	290	310	1 120
1121	в дальнем следовании	120	130	140	150	540
1122	в пригородном сообщении	130	140	150	160	580
ИЗО	выплаты социального характера (кроме путевок)	140	150	160	170	620
1135	компенсация стоимости путевок на санитарнокурортное лечение	150	160	170	180	660
1150	корпоративная поддержка в приобретении жилья	160	170	180	190	700
1160	бьповое топливо	170	180	190	200	740
1170	отчисления на ДМС	180	190	200	210	780
1190	мотивационный фонд	190	200	210	220	820
1199	компенсируемый соцпакет и остальные затраты на оплату труда	200	210	220	230	860

Рис. 3. Упрощенная форма отчета ПБ

В форме серым цветом выделены ячейки, содержащие расчетные формулы (показаны только их значения), остальные ячейки содержат константы, вводимые вручную или загруженные из БД системы источника. На рисунке видно, что формулы, расположенные в столбцах 3-6 строки со статьей 1100, выполняют простое суммирование показателей строк статей: 1110, 1120, 1130, 1135, 1150, 1160, 1170, 1190, 1199, пропустив показатели 1121 и 1122. Эти показатели суммируются формулами, расположенными в строке со статьей 1120. Формулы, расположенные в по- следнем столбце, суммируют значения из столбцов 3-6 таблицы.

Методолог, должен создать файл методики расчета ПБ и заполнить его FriZ-командами, формирующими формулы расчета ПБ. Числовые константы в файл методики не записываются, так как методика расчета содержит только правила расчета значений и указание вида ввода данных в показатель (ручной ввод, загрузка из БД или расчет по формуле).

Заполненный шаблон методики расчета представлен на рисунке 4.

Номер статьи

Полное название

01

01

01

21

21

21

61

61

61

81

81

81

91

91

91

00

00

00

1

2

3

1

2

3

1

2

3

1

2

3

1

2

3

1

2

3

1100

Финансирование затрат на оплату труда ■ всего, в тч.

Ф1

X

X

Ф1

X

X

Ф1

X

X

Ф1

X

X

Ф1

X

X

ФЗ

X

X

1110

расчеты по фонду оплаты труда

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1120

оплата проезда железнодорожников по личным надобностям - всего, в т.ч.

Ф2

X

X

Ф2

X

X

Ф2

X

X

Ф2

X

X

Ф2

X

X

ФЗ

X

X

1121

в дальнем следовании

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1122

в пригородном сообщении

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1130

выплаты социального характера [кроме путевок)

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1135

компенсация стоимости путевок на санитарно-курортное лечение

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1150

корпоративная поддержка в приобретении жилья

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1160

бытовое топливо

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1170

отчисления на ДМС

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1190

мотивационный фонд

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

1199

компенсируемый соцпакет и остальные затраты на оплату труда

РВ

X

X

РВ

X

X

зг

X

X

зг

X

X

РВ

X

X

ФЗ

X

X

Рис. 4. Заполненный участок методики расчета ПБ

Первые два столбца шаблона хранят ту же информацию, что и форма отчета, т.е. номера и наименования статей и показателей ПБ. В заголовке таблицы методики показаны номера видов деятельности: 01 – перевозочная деятельность (перевозки); 21 – прочие виды деятельности; 61 – инвестиционная деятельность; 81 – прочие виды деятельности; 00 – общий итог по всем видам деятельности. Дополнительно в заголовке указаны виды поступления средств: 1 – денежные средства, 2 – безналичный расчет, 3 – общий итог текущему виду деятельности.

Предположим, что использовался только первый вид поступления. Показатели, не использующиеся в методике, помечаются символом «Х». Буквами РВ обозначается ручной тип вода значения показателя, буквами ЗГ обозначается загрузка значений из базы данных.

Для удобства вместо операторов языка FriZ в таблицу вставлены макроопределения (имена функций) Ф1, Ф2 и Ф3. В макроопределения методолог должен ввести операторы формирования формулы расчета методики на языке FriZ. Как было сказано выше, формулы, расположенные в строке статьи 1100 суммируют данные, пропуская показатели 1121 и 1122. Чтобы запрограммировать такое суммирование на языке FriZ, воспользуемся двумя командами. Первая суммирует первые два показателя из списка (1110, 1120), а вторая суммирует все оставшиеся (1130, 1135, 1150, 1160, 1170, 1190, 1199). Для вычисления первой суммы воспользуемся оператором EП(), для второй оператором УИ() (описание действий операторов дано в руководстве по языку FriZ), получаем: Ф1=ЕП(ПК=1110)!\ + \ ЕП(ПК=1120)!\ + \УИ(Н+4)ЕП()

Для суммирования показателей 1121 и 1122 также воспользуемся оператором ЕП(), получаем: Ф2=ЕП(ПК=1121)!\ + \ ЕП(ПК=1122)

Для суммирования значений по столбцам воспользуемся оператором ВП(), получаем: Ф3=ВП(Ш=3) ЕП()\ + \

После трансляции файла методики интерпретатором языка FriZ, генерируется файл расчета платежного баланса, для последующей загрузки его в БД (рисунок 2). Именно в таком виде формулы расчета показателей платежного баланса хранятся в БД. В таблице на рисунке 2 столбик «Единица планирования» содержит адрес в системе координат платежного баланса, указывающий на единицу планирования, в которой находится формула, расположенная в столбике «Формула». Столбик «Тип» содержит сигнатуру типа ввода данных в единицу планирования: F – значение рассчитывается по формуле, I – ручной ввод данных, L – загрузка данных из БД сторонней системы. Столбик «Формула», содержит формулу только в том случае, если показатель является расчетным. При ручном вводе данных в показатель или при загрузке данных из другой системы столбик «Формула» пуст.

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

Особенности языка FriZ. Язык FriZ является мнемоническим языком, т.е. его ключевые слова (операторы) состоят из одно– или двухбуквенных аббревиатур, за которыми, в круглых, фигурных или косых скобках следует перечисление параметров:

НЦ(Т=3, Н+1) К(Т=2) У(Т=72, П=37, Ф=1) ЕП(СТ=СЯ{}, К+0)\ + \

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

ЕП(Р+1)! - НАРАСТ_ИТОГ (' ЕП () ', 1- )) / МЕС_ДО_КОН_ГОДА()

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

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

В алфавит входят символы: ««!, ?, %, _, -, +, *, /, \, =, (),{}, ;, :» и цифры. Пробелы удаляются синтаксическим анализатором из обрабатываемой строки. Некоторые операторы, значения параметров которых, могут содержать пробелы, умеют заменять двойное подчеркивание («__») на пробел, тем самым позволяя вставить пробел в нужное место расчетной формулы.

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

Для предотвращения ложного обнаружения окончания оператора, операторы, находящиеся внутри других операторов, должны иметь фигурные скобки и разделение их параметров выполняется не запятой, а точкой с запятой или двоеточием, например: ЕП(СТ= СЯ{Т=__: П=/} , К+0)\ + \

Большинство операторов языка являются составными и всегда состоят из нескольких, идущих подряд мнемоник, например: НЦ() К() У() ЕП()\ + \

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

Операторы языка FriZ можно разделить на две группы: операторы, использующиеся для работы с файлом методики расчета ПБ и операторы, не использующиеся для работы с методикой. К первой относятся операторы, генерирующие формулы расчета ПБ, к остальным: операторы загрузки и выгрузки информации из баз данных, операторы для работы с сетью и другие. Подробное описание операторов и их параметров представлено в описании языка[6]. Язык FriZ разрабатывался для работы с табличным процессором MS Excel, однако может быть адаптировать для работы с любым редактором таблиц.

Заключение. Т.о., если раньше для создания файла расчета ПБ формы, показанной на рисунке 4, методологу требовалось сформировать и вручную внести в файл расчета ПБ 20 расчетных формул (8 расчетных и 12 для подсчета общих сумм) и прописать для них адреса расположения в БД Системы (см. рисунок 2), то новый метод требует от методолога разработки и записи в файл методики только трех простых конструкций на языке FriZ:

• -    Ф=ЕП(ПК=1110)!\ + \ ЕП(ПК=1120)!\ + \УИ(Н+4)ЕП();

  - Ф=ЕП(ПК=1121)!\ + \ ЕП(ПК=1122);

• -    Ф= ВП(Ш=3) ЕП()\ + \.

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

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