What is ERP-Platfoma
In this article I will talk about the functional classes of ERP-CRM systems, I will try to describe what the ERP-Platform system is, what niche is and how to properly organize the structure of the system.
In the article I will only talk about cloud systems. Where the user logged in, registered, and enjoys. Box systems are a separate topic.
Cloud systems are popular, available. With them just to get acquainted, the monthly payments are small.
For some companies, the cloud is unacceptable. They want to work on their equipment, in their closed network. So calmer. But get acquainted with the system before buying again in the cloud. You can always make a box out of a cloud box, but not always a cloud box.
')
There are many different cloud ERP-CRM systems. I would divide everything into 4 types:
1) Static
2) Static +
3) Semi dynamic
4) Dynamic
1) Static
By this is meant that the system: how it is done is so done. The interface is the same for all clients. The developer periodically finishes something in it. Changes in the interface apply to all clients, because common engine. There can be no individualization of the client’s business processes.
The option is essentially simple and not intricate. You can develop such a system quickly.
But they are almost gone, for having screwed the API, such a system becomes “Static +”.
2) Static +.
This is the development of the Static System. The difference is that the developers screwed the API. Those. the user can create (or buy ready) some external application. This application can communicate with the main system, receive or transmit data to it.
But this partly solves the problem of individualization of business processes. In fact, the logic of the system itself does not change here and the user will still have to adjust to the system. The system will not even make it possible to make a report with the sharing of system data and several applications (data in different places), if it of course allows you to configure reports at all ...
Such systems are popular - because they are fairly simple to create, and if you screw in good marketing here, hire good designers, everything will work out. They can also gather around themselves developers of external applications, integrators, etc. Those. they give bread to more people, thereby strengthening their position in the market.
Static systems are good in some narrow directions. For another profile you will have to build another system. If you want to serve any area, then a static system is a dead-end path of development. Static cloud systems "ERP" can not be, because this requires deep individualization of clients' business processes, and this can only be provided by the following class: “Dynamic Systems”.
3,4) Dynamic (Semi Dynamic)
Dynamic systems - are able to adapt to the user.
They have an interpreter kernel that can display the interface to the user according to the internal configuration settings. When the user opens the page, the system reads the configuration of this page and builds the elements in the right places.
The user can independently edit this configuration. Such systems give users unrivaled flexibility, adapt to any business process, and allow you to build an “ERP” system. You can create a configuration that will cover the life of the enterprise.
As a rule, such systems have an embedded programming system on their boards. Programming system - the apogee of flexibility settings. If the program settings are developed all the time, you will end up with a built-in programming system.
Building a good dynamic system is a big and difficult job. Just with a swoop, as a static system will not work. This is a lot of work and large investments, but it is a higher class system.
The dynamism of such systems is different.
I highlight here a few points:
1) Interface Configuration
2) Database structure configuration
3) Data Processing Configuration
If the system does not implement all the points, then I refer it to the “semi-dynamic class”. I know systems that allow you to create tables and add fields to the database, but do not allow you to configure the interface.
1) Interface configuration.
This means that:
A) you can freely configure an existing interface and create a new interface to a new module.
B) The interface is “two-dimensional”, and in some cases “three-dimensional”, if there are layering of variants. Those. You can manage any point on the page .
There are Static + class systems that have realized their own problems and are trying to make at least Dynamic in some form by adding new fields to the lists. But this will not solve the problems. Interface management is reduced to a one-dimensional list. And technically this is some kind of universal table with links from somewhere to somewhere and blobs to cram any type of field.
If the system was originally laid as static, which crutches do not nail it, do not jump above the head. And when the business is already established, it is very difficult to kill everything and from scratch to make a new system.
2) Configuration of the database structure
You can add new fields to the tables, create new tables, make queries to the database, modify the data.
3) Configuration of data processing.
Can be implemented:
A) The layer between receiving data from the database and displaying them on the screen. For example, on php, or some kind of invented language.
B) Data processing at the database level by means of PL \ SQL and issuing to the interface ready data. This is more promising. There is an opportunity to build triggers, because This is a special case of procedures. In the first version there will be problems.
Also, the threshold of entry here is lower, no need to teach your language. SQL it and in Africa SQL, only interfaces are different.
This article is about the ERP-Platform system, which has all 3 points on its board, and the third paragraph for option B. Data processing is carried out at the database level. There is a full cycle of database configuration from the web interface: tables, procedures, triggers.
Interface configuration
In the ERP Platform, you can manage each page element. At any point, you can organize the display of information, make a control, display or hide certain areas, depending on external conditions or user rights. You can create your own new modules, or edit the configuration of existing ones.
How is this flexibility achieved in the individual management of the system?
The structure of building a web page:
A web page consists of areas called Bookmarks.
Bookmarks at the web page can be any number. The first Bookmark is always visible. It is located on top and in it, as correctly, the basic information is displayed.
Between the rest of the bookmarks, the user can switch.
I will give here an example of the application. Above the main area (Bookmark 1). Below is a list of Bookmarks with their own functions for which the user can switch. In the example, Bookmark 3 “Planned” is open.
Next Bookmark is divided into cells. As in Excel. You can merge cells together, for example, 3 columns and 2 rows into one cell. Any structure for displaying information on the screen is made here.
Different structures can be displayed in each cell: just text, data from the database, data entry / editing element, table structures, links, etc.
But simply output the data to the cell a little. In the same cell, depending on external conditions, different data or elements may be displayed. Therefore, each cell can have several “screens”. Just like in a smartphone: there is one physical screen, but there can be many “desktops” and each has its own shortcuts. Here, too, the cell is one, but it can have several screens with different data and elements.
Also, depending on external conditions, columns or rows of a table of cells may be hidden / shown.
What are external conditions?
The properties of the cell or column / row indicate the procedure that, when the page loads, will display the cell number of the cell or the condition for displaying the column / row. And already in the procedure is the processing of data and conditions, and a decision is made on the withdrawal of one or another. In other words, when the page loads, the procedure twitches. which gives the decision to display the item or not.
In some very specific cases, the capabilities of the interface editor may not be enough. In this case, a php file with this special functionality can be embedded in the cell.
mobile version
Another cellular structure is very convenient for automatic conversion to the mobile version. To display the page “compactly”, all the cells of the page just enough to arrange in one column. For example, if a company has developed a module of its own, it does not need to do something specifically for the mobile version. The module will automatically fall into it. But many companies contain entire divisions in order to develop a mobile version. And then everything is automatic, without effort.
Additionally, there is a manual adjustment functionality to increase the “prettiness”. It may be noted, for example, which cells do not need to be output, or how to reduce the text in the table depending on the format of the mobile output.
As a result, from this:
Absolutely automatically it turns out this:
Universal access rights
Also, due to the cellular structure, the system of access rights is flexibly implemented.
The access level is detailed down to each page element. You can give an employee access to the page, but restrict to certain elements of the page, down to individual cells and editing elements.
The access level can be not specified initially, it is set by default in the properties of the cell, but overlap if otherwise specified in the Employee Rights Role.
Access rights are also inherited: page-tab-cell, unless otherwise specified in the elements.
Additionally, menu links are hashed with user ID and session. For example, it will not work, send the link to another user to the functionality inaccessible to him, such a link will not work for him. Those. security level is double, both at the menu level and at the level of direct access to the elements.
Due to the flexibility of the system of access rights, it is possible to let even external contractors into your account, just set up access rights for them so that they can see and can only work with what they need.
Multilanguage features
The multilingual capabilities of the system are another bonus of the cellular structure. There are no language restrictions. The user himself can add any language and translate elements of the system into it.
Each menu item, bookmarks, cells, form elements, etc. can be translated into any languages.
Technically, this is done simply, there is a table which indicates:
1) language number
2) item type
3) item number
4) element text
The user selects the interface language. The system knows the language number of the current user.
When the system kernel assembles a page, it knows the type of the element, the element number, the number of the currently selected language, and displays the desired text.
In the interface editor, the number of input fields is displayed in accordance with the number of languages ​​and the necessary information is entered.
To simplify the development, the API of the Yandex-translator, i.e. technically translation into the system languages ​​can be done with one click.
For example, a new language was needed in the system - nothing could be simpler. It is registered and a script is launched that will select all the fields from the translation table, each will run through the Yandex translator and create a field according to the desired language for each element. And wah, in 10 seconds the system is translated into a new language. The translation is of course technical, but it’s better than nothing, it’s easier for a specialist to fix it than to translate from scratch.
Example of automatic cell text translation
While there are some problems with Hebrew and Arabic, because there is mirroring, but we are working on it. Will automatically everything.
These, and many other features, are provided by the proper organization of the Dynamic System Interface Editor.
The relationship of the interface and database
The interface must somehow communicate with the database. Along with the link, the input parameters are passed to the page, for example, the Task number. According to the input parameter, the page displays the necessary information from the database in the cells. The same woman is able to modify data in the database from the forms filled by the user.
For this, there are structures called Data Sources. These are links that describe which procedure to pull from the database, which fields of the procedure to enter which input parameters, which output parameters the page will receive from the procedure and where to send them.
Data sources are "Global" and "Local." Global run when page loads. Local actions are performed by events, for example, when a button is pressed. In order to record the information entered by the user, the button is indicated, when activated, the source will be executed. In its input parameters indicate the appropriate fields where the information will come from.
Technically, Data Sources is a structure that allows the page to be formed on the fly on the fly and execute the corresponding query in the database. And after properly dispose of the information received.
Configuring the database
In the ERP Platform, the user is given full control of his database. The user manages the tables, procedures, and triggers. All from the web interface of your account.
Creating tables and fields is basically standard.
The only difference from conventional databases is the Image data type. Type of data for storing images.
Accordingly, the procedures are also able to work with him. They know how to work with images and data sources of web pages, as well as cells are able to display them, form elements - to load them.
Procedures support full PL \ SQL. You can make queries, loops, conditions, string operations, data modification operations, etc. Many built-in system functions.
There are unusual structures. For example, you can embed API structures directly into a procedure / trigger. Those. directly from the trigger in the database (by event), transfer information somewhere outside. The user himself configures the API structure, and he himself sets up the addresses where to transfer.
Triggers are created on data recording, modification, deletion events, and any combinations thereof.
You can embed procedures in procedures, any nesting.
There is a task scheduler, where you can put procedures in a scheduled launch on schedule.
In editable systems there is one feature. In order to allow users to edit everything, the configuration must be developed in this editing system. And since the developers themselves, using this configurator, configure the system, they are trying to automate their work. Therefore, there are good CRUD tools in the system.
For example, you can in the declaration of variables, automatically create them based on the data of the selected table, immediately with the name and the desired data type.
You can automatically fill them into into select by matching names. You can also set fields and variables in inset and update automatically.
You can create a set of typical procedures for each table. For example, you created a new table. You can create one-click procedures: add data, delete, change, list output, output by identifier. All data types will be already registered in them, the corresponding operations will be created. It is very convenient. If the default is not enough - without problems everything can be modified, it is easier than to create everything from scratch.
It is clear that they simply do not create a table, they usually create it for some module, and create an interface for the module. In the interface configurator there are also any automation systems. For example, you can create a set of input-editing form elements based on table fields. The system itself will create them, give them names, make an input restriction by data type, register the corresponding pattren data type, make an automatic technical translation of elements into other languages ​​through the Yandex-translator, etc. operations. It remains only to correct something, if necessary, to arrange them in the desired cells of the page.
In the fields with lists, specifying the universal reference number, automatically create a data source for it and send its output to the list.
With the output of tabular structures, you can also do various group operations on columns.
Naturally, you can copy the structure of cells, page templates, form elements, etc. You can even make snapshots of procedures and roll back if something goes wrong.
Thanks to the CRUD approach, development becomes fast.
Procedures work quickly due to compilation. Modern databases are a fairly advanced tool, and there is no point in neglecting them. The procedure that the user wrote through the web interface is compiled.
The system works, knowing the structure of the procedure, and performing the necessary queries to an already compiled, fast-running element.
Report Configurator
The powerful report configurator is built into the ERP Platform. About him a good article was recently published.
Basic configuration
Of course, if you provide the user with a bare core of the system, then whether it is even a thousand times steep, it simply does not understand what it is and what it is eating.
The bottom line is that there must be something on board. Moreover, it is desirable that this something be good, beautifully and comfortably done, and fit most companies without modifications.The new user, coming into the system, looks at the beauty and functionality of the appearance, and does not ponder the slope of the internal possibilities.
It is also desirable to make a "learning mode", where new users will be given a description of the elements, with an explanation of what is from where and where. This approach helps a lot.
In the ERP Platform, this is called the “Basic Configuration”. If it doesn’t fit anywhere, you can easily change it to the client’s needs.
The configuration can be developed arbitrarily deeply, to make any complicated interfaces and data processing.
The basic configuration is configured for a complete customer service cycle. CRM - for work on attracting new customers, task projects for work on providing services to customers, applications for registration and solving customer problems.
Currently, the basic configuration includes:
- Tasks and SCRUM boards for them.
- Projects
- Applications (Xelp Desk system)
- CRM (leads, offers, deals)
- Counterparty management system
- Charts, objects
- Accounts reconciliation system
All these modules are built directly from the system’s web interface. Therefore, can be easily edited by the user.
The basic configuration is constantly evolving and being finalized. There are new necessary modules.
In the general Basic configuration, it is planned to develop niche modules for various types of business. They will hang in the "hidden" mode, and if necessary, the user will just have to "turn them on".
In conclusion, I want to say that it is very nice when you ask a user to change something, you can answer " Yes, no problem! " And immediately solve the user problem, than answer " For such individual customization you need to purchase a boxed version, and then pay to us for finalizing ... money and through ... everything will be ready . "
A dynamic system makes it possible to organize excellent service.
- For customersThis is the ability to independently change the configuration of your system. The system is not a black box, because After reviewing the documentation and understanding the Configuration editor, you can make changes yourself. We do not close the editor. It is available to the System Administrator (who created the account) and to the employees to whom he will assign such rights.
- For the owner of the service - conveniently and efficiently serve customers. By calling the client, in the shortest possible time, you can make changes to him, and individually, and not to change the interface for all clients as in Static Systems. The client does not have to study the Configuration editor at all, you can simply call the support service and they will do everything for him. A certain amount of work can be included in the monthly fee.
In the article I will only talk about cloud systems. Where the user logged in, registered, and enjoys. Box systems are a separate topic.
Cloud systems are popular, available. With them just to get acquainted, the monthly payments are small.
For some companies, the cloud is unacceptable. They want to work on their equipment, in their closed network. So calmer. But get acquainted with the system before buying again in the cloud. You can always make a box out of a cloud box, but not always a cloud box.
')
There are many different cloud ERP-CRM systems. I would divide everything into 4 types:
1) Static
2) Static +
3) Semi dynamic
4) Dynamic
1) Static
By this is meant that the system: how it is done is so done. The interface is the same for all clients. The developer periodically finishes something in it. Changes in the interface apply to all clients, because common engine. There can be no individualization of the client’s business processes.
The option is essentially simple and not intricate. You can develop such a system quickly.
But they are almost gone, for having screwed the API, such a system becomes “Static +”.
2) Static +.
This is the development of the Static System. The difference is that the developers screwed the API. Those. the user can create (or buy ready) some external application. This application can communicate with the main system, receive or transmit data to it.
But this partly solves the problem of individualization of business processes. In fact, the logic of the system itself does not change here and the user will still have to adjust to the system. The system will not even make it possible to make a report with the sharing of system data and several applications (data in different places), if it of course allows you to configure reports at all ...
Such systems are popular - because they are fairly simple to create, and if you screw in good marketing here, hire good designers, everything will work out. They can also gather around themselves developers of external applications, integrators, etc. Those. they give bread to more people, thereby strengthening their position in the market.
Static systems are good in some narrow directions. For another profile you will have to build another system. If you want to serve any area, then a static system is a dead-end path of development. Static cloud systems "ERP" can not be, because this requires deep individualization of clients' business processes, and this can only be provided by the following class: “Dynamic Systems”.
3,4) Dynamic (Semi Dynamic)
Dynamic systems - are able to adapt to the user.
They have an interpreter kernel that can display the interface to the user according to the internal configuration settings. When the user opens the page, the system reads the configuration of this page and builds the elements in the right places.
The user can independently edit this configuration. Such systems give users unrivaled flexibility, adapt to any business process, and allow you to build an “ERP” system. You can create a configuration that will cover the life of the enterprise.
As a rule, such systems have an embedded programming system on their boards. Programming system - the apogee of flexibility settings. If the program settings are developed all the time, you will end up with a built-in programming system.
Building a good dynamic system is a big and difficult job. Just with a swoop, as a static system will not work. This is a lot of work and large investments, but it is a higher class system.
The dynamism of such systems is different.
I highlight here a few points:
1) Interface Configuration
2) Database structure configuration
3) Data Processing Configuration
If the system does not implement all the points, then I refer it to the “semi-dynamic class”. I know systems that allow you to create tables and add fields to the database, but do not allow you to configure the interface.
1) Interface configuration.
This means that:
A) you can freely configure an existing interface and create a new interface to a new module.
B) The interface is “two-dimensional”, and in some cases “three-dimensional”, if there are layering of variants. Those. You can manage any point on the page .
There are Static + class systems that have realized their own problems and are trying to make at least Dynamic in some form by adding new fields to the lists. But this will not solve the problems. Interface management is reduced to a one-dimensional list. And technically this is some kind of universal table with links from somewhere to somewhere and blobs to cram any type of field.
If the system was originally laid as static, which crutches do not nail it, do not jump above the head. And when the business is already established, it is very difficult to kill everything and from scratch to make a new system.
2) Configuration of the database structure
You can add new fields to the tables, create new tables, make queries to the database, modify the data.
3) Configuration of data processing.
Can be implemented:
A) The layer between receiving data from the database and displaying them on the screen. For example, on php, or some kind of invented language.
B) Data processing at the database level by means of PL \ SQL and issuing to the interface ready data. This is more promising. There is an opportunity to build triggers, because This is a special case of procedures. In the first version there will be problems.
Also, the threshold of entry here is lower, no need to teach your language. SQL it and in Africa SQL, only interfaces are different.
This article is about the ERP-Platform system, which has all 3 points on its board, and the third paragraph for option B. Data processing is carried out at the database level. There is a full cycle of database configuration from the web interface: tables, procedures, triggers.
Interface configuration
In the ERP Platform, you can manage each page element. At any point, you can organize the display of information, make a control, display or hide certain areas, depending on external conditions or user rights. You can create your own new modules, or edit the configuration of existing ones.
How is this flexibility achieved in the individual management of the system?
The structure of building a web page:
A web page consists of areas called Bookmarks.
Bookmarks at the web page can be any number. The first Bookmark is always visible. It is located on top and in it, as correctly, the basic information is displayed.
Between the rest of the bookmarks, the user can switch.
I will give here an example of the application. Above the main area (Bookmark 1). Below is a list of Bookmarks with their own functions for which the user can switch. In the example, Bookmark 3 “Planned” is open.
Next Bookmark is divided into cells. As in Excel. You can merge cells together, for example, 3 columns and 2 rows into one cell. Any structure for displaying information on the screen is made here.
Different structures can be displayed in each cell: just text, data from the database, data entry / editing element, table structures, links, etc.
But simply output the data to the cell a little. In the same cell, depending on external conditions, different data or elements may be displayed. Therefore, each cell can have several “screens”. Just like in a smartphone: there is one physical screen, but there can be many “desktops” and each has its own shortcuts. Here, too, the cell is one, but it can have several screens with different data and elements.
Also, depending on external conditions, columns or rows of a table of cells may be hidden / shown.
What are external conditions?
The properties of the cell or column / row indicate the procedure that, when the page loads, will display the cell number of the cell or the condition for displaying the column / row. And already in the procedure is the processing of data and conditions, and a decision is made on the withdrawal of one or another. In other words, when the page loads, the procedure twitches. which gives the decision to display the item or not.
In some very specific cases, the capabilities of the interface editor may not be enough. In this case, a php file with this special functionality can be embedded in the cell.
mobile version
Another cellular structure is very convenient for automatic conversion to the mobile version. To display the page “compactly”, all the cells of the page just enough to arrange in one column. For example, if a company has developed a module of its own, it does not need to do something specifically for the mobile version. The module will automatically fall into it. But many companies contain entire divisions in order to develop a mobile version. And then everything is automatic, without effort.
Additionally, there is a manual adjustment functionality to increase the “prettiness”. It may be noted, for example, which cells do not need to be output, or how to reduce the text in the table depending on the format of the mobile output.
As a result, from this:
Absolutely automatically it turns out this:
Universal access rights
Also, due to the cellular structure, the system of access rights is flexibly implemented.
The access level is detailed down to each page element. You can give an employee access to the page, but restrict to certain elements of the page, down to individual cells and editing elements.
The access level can be not specified initially, it is set by default in the properties of the cell, but overlap if otherwise specified in the Employee Rights Role.
Access rights are also inherited: page-tab-cell, unless otherwise specified in the elements.
Additionally, menu links are hashed with user ID and session. For example, it will not work, send the link to another user to the functionality inaccessible to him, such a link will not work for him. Those. security level is double, both at the menu level and at the level of direct access to the elements.
Due to the flexibility of the system of access rights, it is possible to let even external contractors into your account, just set up access rights for them so that they can see and can only work with what they need.
Multilanguage features
The multilingual capabilities of the system are another bonus of the cellular structure. There are no language restrictions. The user himself can add any language and translate elements of the system into it.
Each menu item, bookmarks, cells, form elements, etc. can be translated into any languages.
Technically, this is done simply, there is a table which indicates:
1) language number
2) item type
3) item number
4) element text
The user selects the interface language. The system knows the language number of the current user.
When the system kernel assembles a page, it knows the type of the element, the element number, the number of the currently selected language, and displays the desired text.
In the interface editor, the number of input fields is displayed in accordance with the number of languages ​​and the necessary information is entered.
To simplify the development, the API of the Yandex-translator, i.e. technically translation into the system languages ​​can be done with one click.
For example, a new language was needed in the system - nothing could be simpler. It is registered and a script is launched that will select all the fields from the translation table, each will run through the Yandex translator and create a field according to the desired language for each element. And wah, in 10 seconds the system is translated into a new language. The translation is of course technical, but it’s better than nothing, it’s easier for a specialist to fix it than to translate from scratch.
Example of automatic cell text translation
While there are some problems with Hebrew and Arabic, because there is mirroring, but we are working on it. Will automatically everything.
These, and many other features, are provided by the proper organization of the Dynamic System Interface Editor.
The relationship of the interface and database
The interface must somehow communicate with the database. Along with the link, the input parameters are passed to the page, for example, the Task number. According to the input parameter, the page displays the necessary information from the database in the cells. The same woman is able to modify data in the database from the forms filled by the user.
For this, there are structures called Data Sources. These are links that describe which procedure to pull from the database, which fields of the procedure to enter which input parameters, which output parameters the page will receive from the procedure and where to send them.
Data sources are "Global" and "Local." Global run when page loads. Local actions are performed by events, for example, when a button is pressed. In order to record the information entered by the user, the button is indicated, when activated, the source will be executed. In its input parameters indicate the appropriate fields where the information will come from.
Technically, Data Sources is a structure that allows the page to be formed on the fly on the fly and execute the corresponding query in the database. And after properly dispose of the information received.
Configuring the database
In the ERP Platform, the user is given full control of his database. The user manages the tables, procedures, and triggers. All from the web interface of your account.
Creating tables and fields is basically standard.
The only difference from conventional databases is the Image data type. Type of data for storing images.
Accordingly, the procedures are also able to work with him. They know how to work with images and data sources of web pages, as well as cells are able to display them, form elements - to load them.
Procedures support full PL \ SQL. You can make queries, loops, conditions, string operations, data modification operations, etc. Many built-in system functions.
There are unusual structures. For example, you can embed API structures directly into a procedure / trigger. Those. directly from the trigger in the database (by event), transfer information somewhere outside. The user himself configures the API structure, and he himself sets up the addresses where to transfer.
Triggers are created on data recording, modification, deletion events, and any combinations thereof.
You can embed procedures in procedures, any nesting.
There is a task scheduler, where you can put procedures in a scheduled launch on schedule.
In editable systems there is one feature. In order to allow users to edit everything, the configuration must be developed in this editing system. And since the developers themselves, using this configurator, configure the system, they are trying to automate their work. Therefore, there are good CRUD tools in the system.
For example, you can in the declaration of variables, automatically create them based on the data of the selected table, immediately with the name and the desired data type.
You can automatically fill them into into select by matching names. You can also set fields and variables in inset and update automatically.
You can create a set of typical procedures for each table. For example, you created a new table. You can create one-click procedures: add data, delete, change, list output, output by identifier. All data types will be already registered in them, the corresponding operations will be created. It is very convenient. If the default is not enough - without problems everything can be modified, it is easier than to create everything from scratch.
It is clear that they simply do not create a table, they usually create it for some module, and create an interface for the module. In the interface configurator there are also any automation systems. For example, you can create a set of input-editing form elements based on table fields. The system itself will create them, give them names, make an input restriction by data type, register the corresponding pattren data type, make an automatic technical translation of elements into other languages ​​through the Yandex-translator, etc. operations. It remains only to correct something, if necessary, to arrange them in the desired cells of the page.
In the fields with lists, specifying the universal reference number, automatically create a data source for it and send its output to the list.
With the output of tabular structures, you can also do various group operations on columns.
Naturally, you can copy the structure of cells, page templates, form elements, etc. You can even make snapshots of procedures and roll back if something goes wrong.
Thanks to the CRUD approach, development becomes fast.
Procedures work quickly due to compilation. Modern databases are a fairly advanced tool, and there is no point in neglecting them. The procedure that the user wrote through the web interface is compiled.
The system works, knowing the structure of the procedure, and performing the necessary queries to an already compiled, fast-running element.
Report Configurator
The powerful report configurator is built into the ERP Platform. About him a good article was recently published.
Basic configuration
Of course, if you provide the user with a bare core of the system, then whether it is even a thousand times steep, it simply does not understand what it is and what it is eating.
The bottom line is that there must be something on board. Moreover, it is desirable that this something be good, beautifully and comfortably done, and fit most companies without modifications.The new user, coming into the system, looks at the beauty and functionality of the appearance, and does not ponder the slope of the internal possibilities.
It is also desirable to make a "learning mode", where new users will be given a description of the elements, with an explanation of what is from where and where. This approach helps a lot.
In the ERP Platform, this is called the “Basic Configuration”. If it doesn’t fit anywhere, you can easily change it to the client’s needs.
The configuration can be developed arbitrarily deeply, to make any complicated interfaces and data processing.
The basic configuration is configured for a complete customer service cycle. CRM - for work on attracting new customers, task projects for work on providing services to customers, applications for registration and solving customer problems.
Currently, the basic configuration includes:
- Tasks and SCRUM boards for them.
- Projects
- Applications (Xelp Desk system)
- CRM (leads, offers, deals)
- Counterparty management system
- Charts, objects
- Accounts reconciliation system
All these modules are built directly from the system’s web interface. Therefore, can be easily edited by the user.
The basic configuration is constantly evolving and being finalized. There are new necessary modules.
In the general Basic configuration, it is planned to develop niche modules for various types of business. They will hang in the "hidden" mode, and if necessary, the user will just have to "turn them on".
In conclusion, I want to say that it is very nice when you ask a user to change something, you can answer " Yes, no problem! " And immediately solve the user problem, than answer " For such individual customization you need to purchase a boxed version, and then pay to us for finalizing ... money and through ... everything will be ready . "
A dynamic system makes it possible to organize excellent service.
- For customersThis is the ability to independently change the configuration of your system. The system is not a black box, because After reviewing the documentation and understanding the Configuration editor, you can make changes yourself. We do not close the editor. It is available to the System Administrator (who created the account) and to the employees to whom he will assign such rights.
- For the owner of the service - conveniently and efficiently serve customers. By calling the client, in the shortest possible time, you can make changes to him, and individually, and not to change the interface for all clients as in Static Systems. The client does not have to study the Configuration editor at all, you can simply call the support service and they will do everything for him. A certain amount of work can be included in the monthly fee.
Source: https://habr.com/ru/post/338988/
All Articles