Application modules

Modules and their interrelations

The BAS databases consist of two system databases, one database for each application module. The system bases include BAS_MAIN and BASADMIN. BAS_MAIN contains system procedures, functions, and configuration. VASADMIN contains client settings for the database administrator, for example, a list of users, access rights to modules and operations in modules, and so on.

Application databases are used to store operations on objects, processing results, as well as procedures and system tables describing the processes of input and processing operations. For example, databases BAS_BALANS, BAS_UMC, BAS_PARTNER, BAS_OSF, BAS_ZP are used for accounting.

Inter-module communications are implemented during configuration of operations through procedures called by the system when posting transactions. The procedure transmits the necessary data to the associated modules at the time of posting and deletes the transmitted information and at the time of cancellation. A consignment note for the release of goods from the BAS_UMC database to the BAS_PARTNER database, information about the leave operation is transmitted.

For modules used in accounting, there is a system link for accounting entries. Any transaction in the BAS_BALANS database, the transactions reflecting this operation are generated, and when the transaction is canceled, the transactions are deleted.

Structure of the application module

Accounting factors

The accounting factor is one of the parties to the analysis of personal accounts. All factors are described in tree-like directories. There are such examples of signs: the streets of the city, sources of products, accounting books, a tax table, and divisions. The number of factors in the general case can be variable.The list of factors used is found in the corresponding table. The composition of the characteristics is the same in all tables where at least one of them is used.

The composition of the accounting factors depends on the program and the place of its application. For the salary, this can be subdivisions, employee categories, income tax table, tariff rate and so on. For the subscription service, there may be streets, boiler rooms, facilities, etc. To sell the group's heat by types of financing, heat sources (boilers), groups by types of loads, etc.

Five factors are reserved in the program. Their purpose can vary. The list of factors used is in the SFaktor table. Each factor is assigned a specific application used in the program. Each of the factors corresponds to its own table Lst_F1 - Lst_F5, which contains the values of this factor. The list of factors involved is available to the user on the screen forms in order to choose the way data is displayed, the formation of statements, etc. Unactivated factors can be assigned as necessary.

Types of data

In most application modules, there are many separate accounting tasks for the same object. To solve each task, you need your own set of parameters different from the other set. Operations on objects are also aimed at solving a particular task, hence in the parameters of operations, the parameters of different accounting sides are used.

The usual approach in organizing the structure of the transaction table is to place in one transaction record all the parameters that may be required at any time. Since in every single operation only a part of the parameters is used, such organization of the database structure becomes redundant due to the number of unused fields.

The second extreme case is the use of only one parameter in the operation record to which its name is assigned. Such a table is redundant due to repeated repetition of the same key fields. Memory for key fields becomes several times more memory for information. The multiple increased numbers of records and the distribution of different parameters for the same operation leads to a slowdown in the process of selecting information.

In the PC "BAS" adopted an intermediate version. "Data type" is a set of parameters used to solve a single task for an accounting object. In different kinds of data, the same variable can have a completely different meaning. The data type code is entered in the operation. By its meaning, the meaning of object parameters differs. The same field in different types of data can have a different application purpose.

Information about the types of data is found in the two main tables SProdLst and SProdVar. The first table stores the list of data types used and their properties. In the second table, the structure of data types, which includes a set of variables used when working with data types. The process of changing the composition of variables is monitored by the database structure support system. If a parameter with a name that is not present in the database table structure is added to the data view, then the triggers in the Sys_TableConv table include the need for conversion for the operation table. The conversion process is performed by a command from the interface part.

Personal accounts

Personal accounts are a list of elementary objects and their parameter values.

In various application modules, personal accounts contain data about various objects, for example, in the module "salary" they are employees of the enterprise, in the module "partners" they are buyers, suppliers, in the module "materials" is the nomenclature of materials. Depending on the module, the personal accounts contain various data. But the methods of working with personal accounts are the same for all modules.

The three main tables contain data on personal accounts:

- Lst_Ls includes a list of personal accounts;
- Lst_Prod includes the parameters of personal accounts;
- Lst_Corr includes correction operations.

The list of personal accounts Lst_Ls contains the codes of personal accounts and the period of their use. It is used mainly for restrictions (control for availability when used in operations).

Parameters of personal accounts Lst_Prod are data on the personal account. If at least one parameter of the type "Personal account" is used in the form of data, a separate record is assigned for each data type. Special is the "General data" view. These are the parameters of the account that are used for processing any kind of data (KodProd = 0).

The DwN, DwK fields define the time range of the parameters. There cannot be in one period two records of parameters of the same kind of data. KodUser, DateUser fields contain information about the user who changed the parameters last time.

The Pr_Str_Table field is a separator between a group of system fields and a group of application parameters. The group of the fields located before this field is the same in all application modules. The group of the indices and relations between tables is also the same. The group and characteristics of application fields depend on the application and are automatically generated when you configure the data types.

The Lst_Corr table is used in those cases when the settlement procedures are not enough to discretely change the parameters of the personal account in 1 month. Its structure coincides with LSt_Prod.

Directory

The technology of working with reference data is the same in all tasks. Its essence is to create a directory, define its structure, organize windows for filling it and select data from it, and bind the key fields of the directory to the parameters of operations or objects. But in view of the numerous directories in a complex applied task, their creation represents a huge routine. The database, which provides a separate table (file) for each directory, is contaminated with these details, which is why its visibility is lost and, consequently, the implementation and maintenance process becomes more complicated.

The PC "BAS" used the common technology of working with directories and created an automated reference system. Creation and adjustment of directories are carried out in a special graphical mode, and connection to the parameters of operations or data types is performed from the corresponding object configuration modes. The data of all the directories are in one table of the module. In addition, several more system tables are used to manage the data, the structure of the directories, and the protection of data access. But the study of system tables is not mandatory for the developer of application modules. Its calculation procedures refer only to the SSprData table.

The SSprData table contains directory data. The fields are divided into two groups: system and variable. The system fields contain the key values of the records, the validity period of the information, the accounting factors and the data about the user who performed the adjustments. The variable part is separated from the system part by the Pr_Str_Table field.

Table SSprLst contains the list of used directories and their description.

The SSprGrup table is used to classify directories by purpose. It is a tree structure that allows you to group the reference books by common signs. This makes it easy for the user to select the required directory while working with screens.

The SLst_Role table contains a list of roles that are allowed to access the directories.

The SSprVa table contains a list of variables used as parameters for directories.

The Sys_TableVar and Sys_TableConv tables are used to manage the structure of the SSprData table. When you add a field to the directory that is not yet found in any other, a flag is set to convert the SSprData table. Conversion also becomes necessary when the field is deleted from the directory and it is no longer used in any other field.

Operations

Operations are the results of user input, as well as the results of the settlement procedures. They all consist of two parts: results and details. The results are in the table OPR1, and the details are in the table OPR2. The structure of these tables depends on the configuration of the module. The first part of the fields (before the Pr_Str_Table separator) is a system one, it is constant and the same for all application modules. The second part of the Opr1 table depends on the setting of the operation, and the Opr2 table depends on the settings of the data types used.

The operation directory Spr_Opr serves for a tree-like mapping of the operations structure on the user's screen, organizing data protection and storing the operation properties.

The remaining management structure tables are system tables. They are usually not used by data processing procedures in application modules. An application programmer should study the structure of these three tables.

The composition of the variables used in the operation is in the table Opr1Var. This table is monitored by the dynamic structure support system. Therefore, when you add or remove variables from it, you may need to convert the database.

The Opr1VarRole table is used by the data protection system. For each variable, a list of roles is listed, which have the ability to change the values of a variable.

The OPR2 table is arranged in a similar way. The Npp field specifies the order of the records in the operation. A detailed description of the purpose of the fields is in their Description.

The list of Opr2Var variables used in the operation includes the variable names and the KodProd data type code, from which the variable is taken. In one Opr2 entry, only one kind of data can be used. Depending on the type of data, the variable may have a different applied meaning.

The operation table variables are available for SQL calculation procedures that serve the user during the data processing.

Reports

The reporting system built into the "BAS" software package allows you to generate almost any reports based on the available data.In rare exceptional cases, you have to write procedures for preparing data for reports, when you need to process information that was remembered after a long period of program operation, and the report requires historical data.

The documentor consists of 4 blocks that represent routine programmer programming for the programmer: preparing parameters, a structure of output data sets, retrieving data from the database, processing (sorting, arches) and output for final formation in the report.

Preparation of report parameters consists of reading and preparing for use the formation parameters: period, sampling factor and conditions.

The structure of the output data sets is formed based on the composition of the parameters included in the report.

The data sampling unit is designed to read the necessary information from the database into a temporary table. The operation of this unit can be replaced by a special user procedure. If it exists, then the results of the preparation unit are passed to it in the form of formal parameters, and the result of the selection is taken on the same time table.

The processing unit is designed for imposing conditions, forming arches and substituting reference data.

The output block prepares the data for final processing, using Fast Report.

The documentary is able to group, sort the data and connect the directories of the first level of the attachment. In cases where non-standard final processing or connection of data on complex table relationships is required, a custom output procedure is used. It is transmitted, in formal parameters, the results of the preparation unit and a temporary table with the processed report data.

To generate reports, the documentor uses a set of system setup tables.

SReportLst contains a list of reports used in the module and the main properties of the report.

SReaportGrup is designed to classify reports by their purpose. This is a tree-like directory, which is used when displaying a list of reports on the user's screen.

SReportParam stores the report parameters for each user, with which it created it for the last time.

SReportProd contains a list of data types from which information is selected in the report.

SReportVar defines a set of variables from each data type from which information is read.

SReportAlias is the structure of the output buffer. It contains a list of temporary table names for data placement, as well as links to data type parameters.

SReport_Group and SReport_Sort define the rules for grouping data and the rules for sorting them at the final output.

An application programmer does not need to study the structure and relationships of system tables. It is enough to know the structure of the temporary table #Rpt, used as a buffer that contains the selected data for the report.

Development of applied modules of PC "BAS"

Creating and updating modules

Creating a module consists of several steps:

- Create a new database by copying an empty database or the database of the most similar module.
- Write an entry into the list of used modules by creating a connection string for it.
- Assign user access to the module.
- Perform the necessary functional settings (operations, directories, reports, and procedures).

To support modules, a special mode of storing and executing update scripts is used, both of the entire complex and of individual application modules.

Creating a new module

One application module in the BAS software is one database. All databases of the BAS program complex are identical in the system part. This means that they have the same set of tables, links between tables, indexes, constraints, system procedures, triggers, etc. The whole set of tables is divided into two groups: auxiliary and working. Auxiliary contain metadata - the results of setting the application module. By structure, these tables are absolutely identical in all application modules. The second group of tables contains information data entered by users or resulting from calculations. There are several such tables:

- SSprData - reference books;
- Lst_Prod - personal account data;
- Opr1 - register of operations (documents);
- Opr2 - details of operations (documents).

The structure of these tables is the same in the system part (key and system fields, indices, restrictions) and the variable group of the fields used as parameters of data types, directories, and personal accounts.

The first step in creating a new module is to create a new database that will be used for this module. This can be done in two ways: from an empty database and from the database of the prototype module.

The first method is to use the empty BAS_Model database, which contains only the system part of the application module. Further, in this database all the settings are executed from scratch: entering the variables directory, forming the group of data types, directories, operations, and reports.

The second way is to use the database of the application module, which best suits the problem to be solved. For example, to solve the problem of warehouse accounting, you need to take a database of material records and remove from it other people's information, surplus operations and reports.

Regardless of the method, the database is created in the same way through an archive copy of the prototype. You make the BackUp database of the prototype, create a new database with the tools you have available, and then restore the prototype made from the prototype. There is necessary functionality for this purpose in the built-in SQL editor.

The next step in creating a new module is adding it to the list of application modules of the PC "BAS" and a description of its properties. To do this, in the system setup mode, which is called from the administrator's menu or by the combination of keys Cntr Alt Schist F12, the main window of the PC "BAS" is current.

On the "Tasks" tab, the application settings window, you need to add a new module, enter the module code, name, create a database connection string and enter a comment.

The module code is set in all database operations to identify inter-module connections. The user sees the module name on his screen. The connection string to the database (ConnectionString) is used by the system to connect to the database. A special window is used to create it.

A new entry in the list of modules can also be created by copying an existing one. In this case, the control menu of the source program is also copied.

A new database is assigned to the new module, previously created. This is done by building a Connection String. You can write a line manually or call a window to generate it.

Сontrol menu

The next step in creating a module is creating a control menu. In the PC "BAS" it is described in the form of a tree, the name of the vertices of which are displayed on the corresponding panels of the control menu.

Behind each hanging vertex is fixed the mode of operation. There is a list of such modes from which the appropriate one is selected. List of modes is a set of screen forms included in Bas.exe.

The next step is to compile a list of user roles used in the new module. The roles are configured in the administrator module from the "Data Protection - Roles" menu.

For each role, the program modes in which it is allowed to enter are marked. Not available modes on the screen of this role are not displayed.

It is not necessary to list all the roles at once. At any time, the list of roles can be replenished. It is enough for at least one role to be able to enter the program.

Now it is necessary to note which users can work with the new module and set the roles for them. To do this, in the administrator module, in the mode of working with users, you need to make the necessary notes: which module is available to the user and his role in this module.

Since the database structure of the various application modules in the system part is the same, then the procedures working at the system level are the same. This leads to the need to maintain uniformity of procedures in all application modules. Any adjustment in this procedure should be made in all modules. This is the main purpose of the mode of supporting SQL-texts in the PC "BAS".

The second purpose of the mode is to transport the texts of procedures and scripts to the clients while escorting the program. All of them are in the base BAS_MAIN, which is enough to substitute from the client and compile procedures or scripts created or modified in a certain period of time.

Any text can be added to the list, read from a file, saved to a file, modified, compiled, etc.

The list of databases in which the script should be executed is located in the "Database" tab. Each database has a script execution protocol. The system analyzes it before loading the script for execution. If the date of creation (correction) of the script is less than the date of execution of the script according to the protocol, the script is not executed. This is a guarantee that one script is executed only once.

Also, there is a rigid order of execution of scripts. If at least one of the previous scripts is not executed, then the current one will not be executed either. In this case, a corresponding message is issued.