After creating an account and logging into the system, you see a friendly interface. You can create leads, tasks, projects. Usually in cloud CRM you can only use this, but in the "ERP-Platform" you can edit_s12 the interface and data structure, create new modules, make your own unique changes in standard modules and adjust the system to the logic of your business processes? And all this in the cloud !
Here we will tell you how the ERP-Platform is technically arranged, why it can be individually and unlimitedly configured. How is it that "ERP-Platform" can grow together with clients, turning into an ERP system for the client?
DatabasesWhen registering, each company receives an individual container in which its databases will live. Each company operates and stores data in its own individual database.
There are 4 databases inside the client container:
This division was made for technical and pragmatic reasons:
Configuration base (main base)This is the main customer database.
It stores individual configuration and data. All other bases are auxiliary. For example, it is not worth storing logs in this database. one field can be overwritten many times, and with each overwrite a copy of this field will be stored, which will bloat the database and complicate its backup. As a result, the backup is fast, takes up little space, and there is no water in it, but only the necessary data.
Backup of this database can be configured from the interface and is regulated by the client himself. It can also be backed up to an external ftp server of the client, i.e. you can store the backup on your side. To do this, you just need to specify the IP of your ftp server in the interface.
FilebaseThis database implements its own file system. There is a directory structure, access rights. Files are stored inside the database as a binary data sequence. When the user clicks on the file icon in the browser, the system reads the binary sequence and generates a file for the user.
Made so for the following reasons:
Database of logs.This database stores detailed logs of any activity. Who, when, where, what and for what changed. Here you can lift any actions on any table, see what data was before the change.
Logging data is written at the event level in the main database, not at the user interface level. Therefore, all changes along the chain of triggers and automatic actions are also recorded.
The client (client's administrator) can also manage the log recording on his own. You can configure the data retention period, disable or enable the recording of this data individually in the tables.
By default, the log database is not backed up. this data is not critical and even its loss will not affect the work as a whole. They are of an auxiliary nature so that you can understand mysterious situations.
But at the request of the client, we can make backups of this database.
Database.Our system allows the client to perform flexible integration with any of their external systems, directly from the cloud. The client himself can come up with interaction formats. Those. create your own API format.
Our technologies allow transferring data to the outside world directly from within the main event database. For example, you can create a trigger that, if the data in the table changes, will transfer the data in YOUR format to YOUR IP address on the Internet. Those. data transfer is not tied directly to the interface, but can work both with some user actions and with the occurrence of some events, including all changes along the chain of triggers and pending tasks.
These data can be quite voluminous, because similar to logs, multiple records can be made for one field when changing. Their storage in the main database is impractical, therefore, using a similar technology with logs, when an event occurs, the data is relayed to the service database, and from there it goes to the outside world. For some time, the data lives here, in case of problem analysis, and then it is cleared, only the packet headers remain, since they do not take up much space and after the fact you can understand that such and such a packet was transmitted with such and such a status.
This database is not backed up, because there is only service data.
ConfigurationNow let's look at how the Configuration (main) database works and how the individual web interface is built.
The base is divided into 2 large sections:
The interface configuration is interpreted . Those. when the user opens the page, it refers to its configuration and builds itself on the fly, arranges the elements in the right places on the web page.
Why Interpreted? The point is in the access rights and the withdrawal of elements depending on external conditions.
What is it? For example, in Bitrix you can add only new fields in the lists - this is 1D configuration. You can simply add a new field, but you cannot position it to the left, right, second or third row, in the corner, etc.
2D - when you can place interface elements anywhere on the page. 2D configuration is simple and elegant. The entire interface is divided into cells as in Excel. Just like in Excel, you can combine cells with each other, and rows and columns. This way you can build any page structure. After that, you can add interface elements to the cells. These may not necessarily be text fields. You can add buttons, lists, images, tables, etc. Cells can be styled i.e. paint in the desired colors, customize the borders of the fields, position and font, etc. You can set fixed sizes of columns and rows. In general, the interface is very flexible.
3D - 2D edit_s12or is not always enough if the page has to have complex logic of work. For example, when, depending on the status of the task, you need to hide or show certain blocks of the page. Or display different edit_s12ing elements in the same cell, depending on certain data.
To implement such complex interactions, a third dimension is introduced, by analogy with layers. Depending on the events, it can show the desired cell layer. Those. in each cell, you can create many layers with your own elements and set the logic according to which this or that layer will be displayed.
For rows or columns, you can also set the logic of hiding or showing, depending on external conditions.
Cloud 3D configuration of the page allows you to implement any logic of the user interface.
Data sources are also created in the interface configurator, which are the link between the interface and the database. They know with what data this or that page element will work, where to write the information entered by the user, where to get it from when forming the page.
Database configuration (DB), unlike the interface, is compiled .
This was done for the following reasons:
Queries can be of any complexity, including joining multiple tables, case, etc.
Inside some procedures, you can start others.
The division of levels into user (configuration) and working levels allows us to do quite unique things in our system, for example:
All configuration is naturally done in the cloud, right in the browser.
Interface and Database Friendship
When a page is formed, in addition to the arrangement of elements in space, it must also display data in the right places, fill in the elements or decide to display certain blocks. Those. knowing the input parameters, it must get the data necessary for output from the database. And sometimes it is not easy to get raw data, but to output it taking into account some processing, arithmetic operations, etc.
At the same time, it is necessary that everything works quickly, nothing superfluous is performed.
The link between the interface and the database is a structure called the Data Source. It's pretty simple. It must indicate:
With such a structure, you can configure whatever logic of the module's operation you want. You can change and create any interfaces, create any data storage and processing structures.
If you want to purchase a local version, client databases can be easily transferred to the client's server with all the data and the structure developed in the cloud.
Multilingual supportThe system includes multilingual support. Any element of the system can be translated into any language.
For this, the client can independently register a new language in the settings, and it will be available in the configurator. Any element can have a designation in the given language.
Also for the convenience of development, the system makes an automatic primary translation of new elements into registered languages. It works like this:
Basic configurationWe provide our client not with a “bare” platform where he can develop something, but an account with an already existing “basic” configuration. Those. the system configurator has already developed Tasks, Projects, Applications, Contractors, Leads, Deals, Proposals, Schedules, Warehouse, Documents, etc.
For more details on basic functionality, see OPPORTUNITIES .
Modules of standard configuration will suit most clients, or require some minimal changes for the client's specific needs. Changes can be made at any time in the configurator.
If a client has some unique business processes and needs to develop some individual module - no problem. Any custom modules can be developed using the system configurator. The client can do this independently, or order revisions.
For self-development configuration you need:
Report ConfiguratorA powerful report configurator is built into our system.
A detailed article about our report configurator on habr https://habr.com/post/331884/ (ru).
System performanceThe system is fast due to the correct architecture of the kernel.
System performance is greatly affected by the way the application works with the database. All edit_s12ed systems try to use the programming language built into the interface (it can be one of its own, or one of the standard popular languages), and only data is stored in the database. As a result, they get the following scheme of work:
We have made a more modern scheme of work, with minimization of losses. The result is absolutely the same as in the scheme above, but the speed of work is much higher.
All data processing takes place at the base level, in fast compiled tools. The interface only gives commands and outputs the result.
The required procedure is called from the interface, parameters are passed to it. Further, the procedure inside the database makes all requests, all data processing, all modifications and data records, and sends the already assembled result of work to the interface. As a result, there is no useless transfer of data back and forth, and data processing is performed by a technically perfect, fast tool, which are modern databases.
As a justification for the use of standard popular programming languages, it is often stated that there are many such specialists and they are quite easy to find. But there are also a lot of specialists professionally working with databases, and finding a programmer familiar with procedural SQL is also not difficult.
Welcome to our system!We invite you to register and test all the above features.
Or see how the configuration works without registration.
We are waiting for your questions, wishes and suggestions from 10:00 to 18:00 (Moscow time) from Monday to Friday
by writing by email: firstname.lastname@example.org
«ERP-PLATFORM» LLC © 2021