The language of the description of economic calculations - the idea of the program
The main goal of this article is not to get an invite, but to share an idea and get comments on its feasibility and prospects from the community of experts. (I already received an invite for this article - thanks to an unknown habr friend)
Once I worked as a programmer in a project institute in the economic department.
We carried out economic calculations for a large organization (Bashneft). I provided technical support for these calculations.
I was faced with the fact that there is no truly convenient tool for this purpose.
I came up with the idea of such a tool, a special declarative language resembling Prolog, a language for describing economic calculations.
The basic idea of the language of the description of economic calculations is to provide an opportunity to describe the calculations as closely as possible to how it is done in economics textbooks. That is something like:
Profit = Revenue - Costs
')
Revenue = Price_of_goods_ of goods * Quantity_ of goods
Etc.
The user describes the calculation in the form of formulas like this, and then sets the goal, that is, what he needs to actually calculate. After that, the system builds a calculation tree.
For example, if we need to calculate profits, we must first calculate revenues and costs.
To calculate the revenue you need to determine the unit price and quantity of goods.
To describe the real economic calculations, this language must be expanded.
You must provide the following features:
1. Extraction of data from the database
2. Provide a description of the different calculations depending on the context.
For this, the following entities are introduced into the language:
1. Formulas with conditions:
Before a group of formulas or before a single formula, you can put a condition under which this formula can be used.
2. Data sources:
Samples from the database of the enterprise for which the calculation is made.
(Standard data source: SQL query, DBF table, csv file, etc.)
Name, fields - string, numeric, dates
Data sources are used only in data extraction functions from the database.
3. Functions:
Standard Mathematics
Work with dates
Extracting data from the database
Aggregation functions: sum, maximum, minimum, etc.
4. Tags:
Types of tags:
Number
date
Lots of
Line
Tags are needed to describe the context of calculations:
Any economic calculation is done in some context:
For a certain object (Enterprise, workshop, department ..), for a certain period-date.
In addition, to calculate an indicator for an object, it is often necessary to calculate indicators for its sub-objects, for example, to calculate the profit for a department, it is necessary to calculate the profit for all departments of the department and add it up.
For all this, the tagging mechanism, their inheritance and modification is used.
That is, at the very beginning of the calculation a list of tags describing the context of the calculation is given. First of all, it is the object of calculation (the whole enterprise or any of the divisions, the date and period for which the calculation is made). Formulas have the ability to change context tags, change or add tags.
In the first formula of the following example in the line:
Profit = Amount (Profit [Object_type = Workshop], Facility_Code = Retrieve_Set (Facility_List, Facility_C, Parent_Code = Facility_Code))
In the substring Profit [Type_Object = Workshop], the value of the Type_Object tag is changed from Oil and Gas Production Department to Shop, so that further calculations are carried out at the same workshops, and the amount of these calculations is received in the Status Dialogue.
A line of the form {[Type_Object = NGDU] means that all formulas between curly brackets can be used only if Type_Object = NGDU.
Example:
{[Item_Type = OTG]
Profit = Amount (Profit [Object_type = Workshop], Facility_Code = Retrieve_Set (Facility_List, Facility_C, Parent_Code = Facility_Code))
}
{[Item_type = Workshop]
Profit = Production_Oil * Price_Oil - Expenses
Oil production = Amount (Production_Oil [Object_type = Well], Feature_code = Extract_Set (Well_list, Feature_Code, Parent_Code = Feature_Code, Type_Bore = Injection)
}
{[Item_type = Well]
Extraction_Oil = Ivlech_Value (Extraction_in_Bore, Extraction, Well_Code = ObjectCode, Date = Date_Account)
}
This example defines:
Profit at NGDU is the amount of profit for the shops that belong to it.
Profit by department is defined as the difference between the revenue from the oil sold and the cost. Oil production in the workshop is defined as the sum of production by wells.
It also implies the presence of 3 sources of data - sample tables from the enterprise database:
The list of workshops - a table with at least two fields, Cod_Object and Cod_Parent, defining which workshop to which NGDU belongs.
The list of wells is similar to the list of workshops, the table identifies the belonging of wells to workshops.
Data on well production for the period - a table with at least 3 fields: Production,
Well_Code, Date.
To run the calculation on OGPU with code 1, you need to enter something like: in the query input window:
Object_type = OGDU
Code_Object = 1
Calculation Date = '01 .01.2009 '
? Profit
The main core consists of 3 modules:
1. Editing formulas for calculations
2. Query window
3. Module for connecting data sources.
This is a computational core.
It is quite possible to expand the service functions for convenience.
For example, the following options seem to me the most relevant:
1. Query as a table, not a single value.
2. An opportunity to enter information on objects of calculation not by codes, but by names, that is, organization of reference books.
Etc.
Advantages of this approach:
1. Flexibility - Once a calculation has been made, it can be easily reworked in an intuitive way. Moreover, simple changes can be made by economists themselves. You can also conduct a project starting with a business plan, gradually replacing the data from the formulas calculated by the predictive model with real indicators
2. Universality - you can make a calculation that will take information from disparate sources. It is very important for large organizations consisting of a set of relatively independent subsidiaries.
3. Transparency - for any finite value, you can build a tree of calculations, show all intermediate values. Actual for large projects in which errors are unavoidable, the root cause of which is usually difficult to find.
Minuses:
1. The complexity of learning. Still, this is a whole new language, although quite simple.
2. The complexity of setting up calculations. For small calculations, this method may be too cumbersome.
There is another problem that stops me from taking further steps in the implementation of this project.
The fact is that its application makes sense only at relatively large business facilities.
I have a great experience of all kinds of implementations as an executor in projects for such objects and I can perfectly imagine
that for the sale of products to such customers very specific technologies are used, which, unfortunately, I do not own at all.
Maybe there are those who own them and who are interested in this idea?
Once I worked as a programmer in a project institute in the economic department.
We carried out economic calculations for a large organization (Bashneft). I provided technical support for these calculations.
I was faced with the fact that there is no truly convenient tool for this purpose.
I came up with the idea of such a tool, a special declarative language resembling Prolog, a language for describing economic calculations.
The basic idea of the language of the description of economic calculations is to provide an opportunity to describe the calculations as closely as possible to how it is done in economics textbooks. That is something like:
Profit = Revenue - Costs
')
Revenue = Price_of_goods_ of goods * Quantity_ of goods
Etc.
The user describes the calculation in the form of formulas like this, and then sets the goal, that is, what he needs to actually calculate. After that, the system builds a calculation tree.
For example, if we need to calculate profits, we must first calculate revenues and costs.
To calculate the revenue you need to determine the unit price and quantity of goods.
To describe the real economic calculations, this language must be expanded.
You must provide the following features:
1. Extraction of data from the database
2. Provide a description of the different calculations depending on the context.
For this, the following entities are introduced into the language:
1. Formulas with conditions:
Before a group of formulas or before a single formula, you can put a condition under which this formula can be used.
2. Data sources:
Samples from the database of the enterprise for which the calculation is made.
(Standard data source: SQL query, DBF table, csv file, etc.)
Name, fields - string, numeric, dates
Data sources are used only in data extraction functions from the database.
3. Functions:
Standard Mathematics
Work with dates
Extracting data from the database
Aggregation functions: sum, maximum, minimum, etc.
4. Tags:
Types of tags:
Number
date
Lots of
Line
Tags are needed to describe the context of calculations:
Any economic calculation is done in some context:
For a certain object (Enterprise, workshop, department ..), for a certain period-date.
In addition, to calculate an indicator for an object, it is often necessary to calculate indicators for its sub-objects, for example, to calculate the profit for a department, it is necessary to calculate the profit for all departments of the department and add it up.
For all this, the tagging mechanism, their inheritance and modification is used.
That is, at the very beginning of the calculation a list of tags describing the context of the calculation is given. First of all, it is the object of calculation (the whole enterprise or any of the divisions, the date and period for which the calculation is made). Formulas have the ability to change context tags, change or add tags.
In the first formula of the following example in the line:
Profit = Amount (Profit [Object_type = Workshop], Facility_Code = Retrieve_Set (Facility_List, Facility_C, Parent_Code = Facility_Code))
In the substring Profit [Type_Object = Workshop], the value of the Type_Object tag is changed from Oil and Gas Production Department to Shop, so that further calculations are carried out at the same workshops, and the amount of these calculations is received in the Status Dialogue.
A line of the form {[Type_Object = NGDU] means that all formulas between curly brackets can be used only if Type_Object = NGDU.
Example:
{[Item_Type = OTG]
Profit = Amount (Profit [Object_type = Workshop], Facility_Code = Retrieve_Set (Facility_List, Facility_C, Parent_Code = Facility_Code))
}
{[Item_type = Workshop]
Profit = Production_Oil * Price_Oil - Expenses
Oil production = Amount (Production_Oil [Object_type = Well], Feature_code = Extract_Set (Well_list, Feature_Code, Parent_Code = Feature_Code, Type_Bore = Injection)
}
{[Item_type = Well]
Extraction_Oil = Ivlech_Value (Extraction_in_Bore, Extraction, Well_Code = ObjectCode, Date = Date_Account)
}
This example defines:
Profit at NGDU is the amount of profit for the shops that belong to it.
Profit by department is defined as the difference between the revenue from the oil sold and the cost. Oil production in the workshop is defined as the sum of production by wells.
It also implies the presence of 3 sources of data - sample tables from the enterprise database:
The list of workshops - a table with at least two fields, Cod_Object and Cod_Parent, defining which workshop to which NGDU belongs.
The list of wells is similar to the list of workshops, the table identifies the belonging of wells to workshops.
Data on well production for the period - a table with at least 3 fields: Production,
Well_Code, Date.
To run the calculation on OGPU with code 1, you need to enter something like: in the query input window:
Object_type = OGDU
Code_Object = 1
Calculation Date = '01 .01.2009 '
? Profit
The main core consists of 3 modules:
1. Editing formulas for calculations
2. Query window
3. Module for connecting data sources.
This is a computational core.
It is quite possible to expand the service functions for convenience.
For example, the following options seem to me the most relevant:
1. Query as a table, not a single value.
2. An opportunity to enter information on objects of calculation not by codes, but by names, that is, organization of reference books.
Etc.
Advantages of this approach:
1. Flexibility - Once a calculation has been made, it can be easily reworked in an intuitive way. Moreover, simple changes can be made by economists themselves. You can also conduct a project starting with a business plan, gradually replacing the data from the formulas calculated by the predictive model with real indicators
2. Universality - you can make a calculation that will take information from disparate sources. It is very important for large organizations consisting of a set of relatively independent subsidiaries.
3. Transparency - for any finite value, you can build a tree of calculations, show all intermediate values. Actual for large projects in which errors are unavoidable, the root cause of which is usually difficult to find.
Minuses:
1. The complexity of learning. Still, this is a whole new language, although quite simple.
2. The complexity of setting up calculations. For small calculations, this method may be too cumbersome.
There is another problem that stops me from taking further steps in the implementation of this project.
The fact is that its application makes sense only at relatively large business facilities.
I have a great experience of all kinds of implementations as an executor in projects for such objects and I can perfectly imagine
that for the sale of products to such customers very specific technologies are used, which, unfortunately, I do not own at all.
Maybe there are those who own them and who are interested in this idea?
Source: https://habr.com/ru/post/130838/
All Articles