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