Pull to refresh

Язык описания экономических расчётов — идея программы

Reading time 4 min
Views 2.9K
Главная цель этой статьи это не получение инвайта, а возможность поделиться идеей и получить комментарии по поводу её целесообразности и перспективности от сообщества специалистов. (Инвайт за эту статью я уже получил — спасибо неизвестному хабр другу)
Когда-то я работал программистом в проектом институте в экономическом отделе.
Мы производили экономические расчёты для крупной организации (Башнефть). Я обеспечивал техническое обеспечение этих расчётов.
Я столкнулся с тем, что по настоящему удобного инструмента для этих целей нет.
У меня появилась идея подобного инструмента- специального декларативного языка, напоминающего Prolog- языка описания экономических расчётов.


Основная идея языка описания экономических расчётов состоит в том, чтобы дать возможность описывать расчёты максимально приближенно к тому, как это делается в учебниках по экономике. То есть что-то вроде:

Прибыль = Выручка – Затраты

Выручка = Цена_еденицы_товара * Количество_товара

И т.д.

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

Необходимо обеспечить следующие возможности:
1. Извлечение данных из БД
2. Обеспечить описание разных расчётов в зависимости от контекста

Для этого в язык вводятся следующие сущности:
1. Формулы с условиями:
Перед группой формул либо перед единичной формулой можно поставить условие, при котором эта формула может быть использована.
2. Источники данных:
Выборки из базы данных предприятия, для которого происходит расчёт.
(Стандартный источник данных: SQL запрос, таблица DBF, csv файл и т.д.)
Имя, поля – строковые, числовые, даты
Источники данных используются только в функциях извлечения данных из БД
3.Функции:
Стандартные математические
Работа с датами
Извлечение данных из БД
Агрегирующие функции: сумма, максимум, минимум и т.д.
4. Теги:
Типы тегов:
Число
Дата
Множество
Строка

Теги нужны для описания контекста расчётов:
Любой экономический расчёт делается в каком-то контексте:
Для определённого объекта (Предприятие, цех, отдел..), на определённый период-дату.
Кроме того, для расчёта показателя по объекту часто бывает нужно рассчитать показатели для его подобъектов, например для расчёта прибыли по департаменту надо рассчитать прибыль по всем отделам департамента и сложить.
Для всего этого используется механизм тегов, их наследования и изменения.

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

В первой формуле следующего примера в строчке:
Прибыль = Сумма(Прибыль[Тип_Объекта=Цех ], Код_Объекта=Извлечь_Множество( Список_Цехов, Код_Объекта, Код_Родителя=Код_Объекта))
В подстроке Прибыль[Тип_Объекта=Цех ] происходит смена значения тега Тип_Объекта с НГДУ на Цех, чтобы дальнейшие расчёты проводились у же по цехам, а в НГДУ попадала сумма этих расчётов.
Строчка вида {[Тип_Объекта=НГДУ] означает что все формулы находящиеся между фигурными скобками можно использовать только если Тип_Объекта=НГДУ.

Пример:

{[Тип_Объекта=НГДУ]

Прибыль = Сумма(Прибыль[Тип_Объекта=Цех ], Код_Объекта=Извлечь_Множество( Список_Цехов, Код_Объекта, Код_Родителя=Код_Объекта))
}

{[Тип_Объекта=Цех]
Прибыль = Добыча_Нефти*Цена_Нефти – Расходы
Добыча_Нефти=Сумма(Добыча_Нефти[Тип_Объекта=Скважина], Код_Объекта = Извлечь_Множество( Список_Скважин, Код_Объекта, Код_Родителя=Код_Объекта, Тип_Скважины=Нагнетательная))
}

{[Тип_Объекта=Скважина]
Добыча_Нефти=Ивлечь_Значение(Добыча_по_скважине, Добыча, Код_Скважины=Код_Объекта, Дата=Дата_Расчета)
}

В этом примере определяется:
Прибыль по НГДУ это сумма прибыли по цехам, в неё входящим.
Прибыль по отделу определяется как разница между выручкой от проданной нефти и затратами. Добыча нефти по цеху определяется как сумма добычи по скважинам.
Так же подразумевается наличие 3 источников данных- таблиц выборок из БД предприятия:
Список цехов – таблица по крайней мере с двумя полями, Код_Объекта и Код_Родителя, определяющая какой цех к какому НГДУ принадлежит.
Список скважин – аналогично списку цехов, таблица определяющая принадлежность скважин к цехам.
Данные по добыче скважин за период – таблица по крайней мере с 3 полями: Добыча,
Код_Скважины, Дата.

Чтобы запустить расчёт по НГДУ с кодом 1 необходимо в окне ввода запросов ввести что- то вроде:
Тип_Объекта=НГДУ
Код_Объекта=1
Дата_Расчета='01.01.2009'
? Прибыль

Основное ядро состоит из 3 модулей:
1.Редактирование формул для вычислений
2. Окно запросов
3. Модуль для подключения источников данных.

Это вычислительное ядро.
Его вполне можно расширить сервисными функциями для удобства.
Например, мне кажутся наиболее актуальными следующие возможности:
1. Запрос в виде таблицы, а не отдельного значения
2. Возможность вводить информацию по объектам расчёта не по кодам, а по названиям, то есть организация справочников.
И т.д.

Плюсы данного подхода:
1. Гибкость — однажды сделанный расчёт можно легко переделывать интуитивно понятным способом. Причём простые изменения могут делать сами экономисты. Также можно вести проект начиная с бизнес плана, постепенно заменяя данные с формул, расчитанных по прогнозной модели на данные реальных показателей
2. Универсальность — можно сделать расчёт, который будет брать информацию из разнородных источников. Очень актуально для больших организаций, состоящих из множества относительно независимых «дочек».
3. Прозрачность — для любой конечной величины можно построить дерево расчётов, показать все промежуточные величины. Актуально для больших проектов, в которых неизбежны ошибки, первопричину которых обычно сложно находить.

Минусы:
1. Сложность обучения. Все-таки это целый новый язык, хотя и достаточно простой.
2. Сложность настройки расчётов. Для небольших расчётов этот метод может оказаться слишком громоздким.

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

Может здесь есть те кто ими владеет и кого заинтересовала эта идея?
Tags:
Hubs:
+1
Comments 15
Comments Comments 15

Articles