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

Главная цель этой статьи это не получение инвайта, а возможность поделиться идеей и получить комментарии по поводу её целесообразности и перспективности от сообщества специалистов. (Инвайт за эту статью я уже получил — спасибо неизвестному хабр другу)
Когда-то я работал программистом в проектом институте в экономическом отделе.
Мы производили экономические расчёты для крупной организации (Башнефть). Я обеспечивал техническое обеспечение этих расчётов.
Я столкнулся с тем, что по настоящему удобного инструмента для этих целей нет.
У меня появилась идея подобного инструмента- специального декларативного языка, напоминающего 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. Сложность настройки расчётов. Для небольших расчётов этот метод может оказаться слишком громоздким.

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

Может здесь есть те кто ими владеет и кого заинтересовала эта идея?
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 15
  • 0
    а как же 1С? Разве там не так?
    • +2
      Поздравляю, вы изобрели функциональное программирование!
      • 0
        Как раз для этого придумали 1С :)
        • +1
          ! С не очень подходит для этого.
          Она на бухгалтеров расчитанв
          У экономистов несколько другие задачи

        • 0
          1. Вы переизобрели Лисп.
          2. martinfowler.com/books.html#dsl
          3. Первичное гугление — www.google.ru/url?sa=t&rct=j&q=finance%20domain%20specific%20language&source=web&cd=4&sqi=2&ved=0CD4QFjAD&url=http%3A%2F%2Fwww.st.ewi.tudelft.nl%2F~arie%2Fpapers%2Ftalks%2Frisla.ppt&ei=DxqgToWgIs3S4QTfu_jiBA&usg=AFQjCNH7MaGUiNwajDZLCocF-9NTswIByA&cad=rja
          • 0
            Или Haskell )
            • +1
              Я не претендую на новзну идеи
              Я сам указал Prolog в качестве основы.
              Просто непосредственно эти языки, в силу их сложности, не так удобны для этой задачи.
              Идея в том, чтобы экономист сам мог править уже готовый расчёт, синтаксис максимально упрощён для этого.
              Экономистам часто нужно много слегка отличающихся вариантов расчёта.
              Вот и приходится либо переделывать программу каждый раз, либо ставить непомерное количество параметров для разных вариантов, в которых потом очень просто запутаться.
              Здесь же расчёт представлен максимально просто и понятно.
              • 0
                Если библиотека построена верно, то экономист справится с haskell да и практически любым другим современным языком. Все зависит от того, насколько сложные изменения должен вносить человек.

                Если вы хотите сделать Domain Specific Language с минимальными затратами обратите внимание также на Scala, который позволяет довольно гибко менять синтаксис.

                Вообще говоря в вашей статье не хватает как раз описания того, чего конкретно вы хотите добиться, чего не дают стандартные языки. Из вашей статьи видно только то, что вы хотите использовать выражения до их объявления и только.
                Думаю вам стоит больше сконцентрироваться на том, как пользователь будет видеть продукт, а не на его функционале.
            • –1
              в заголовке ошибка… дальше читать не стал!
              • 0
                Cobol не годится?
                • 0
                  статью пока не читал, в данный момент время есть только на коротенький комментарий: рассмотрите язык tcl
                  • 0
                    К сожалению, только недавно нашёл этот пост, к тому же вообще через Google.
                    Скажите, пожалуйста, идея получила какое-то продолжение, или в комментариях ваш энтузиазм запинали ногами до смерти?
                    Просто было бы интересно посмотреть на практическую реализацию.
                    • 0
                      Нет, к сожалению, эта идея не получила никакого продолжения.
                      Дело тут не в комментариях. У данного продукта очень специфический рынок сбыта — экономические отделы крупных компаний.
                      У меня нет сейчас ни связей в этой сфере, ни каких-то способностей и/или технологий чтобы эти связи наладить.
                      • 0
                        Думаю, потенциальная сфера использования в целом шире. К отделам экономического планирования крупных компаний можно прибавить научное экономическое сообщество, плюс инвестиционные фонды, банки, да и более мелкие предприниматели.
                        Разумеется, для этого потребуется для каждого из этих направлений немного прокачать соответствующий навык инструмента: добавить абстрактных экономических сущностей для теоретиков, встроенные механизмы инвестиционного анализа для инвесторов и банкиров, плюс какие-нибудь шаблоны для типичных действий, чтобы завлечь малый и средний бизнес.
                        К тому же не помешает некоторая местечковость в синтаксисе, в частности возможность выбрать между русским и английским вариантами, как в 1С.
                        Касательно же продвижения, действительно, в нашем «бумажном» мире есть с этим проблемы, но ведь startup — это всегда что-то, что по началу никому не нужно, по крайней мере за деньги, а потом некоторым везёт.
                        В общем если вдруг будет какое-то продолжение, то не сочтите за труд и напишите на Хабре. Я, конечно, не экономический отдел в крупной компании, но мне всё равно интересно. :-)
                        • 0
                          Спасибо за поддержку!
                          Если вернусь к этой идее- обязательно напишу об этом на Хабре.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.