1c 8.3 zUP checking the eligibility of using the configuration. Automated validation of configurations ... and a few words about development standards. What checkboxes to put

Sometimes troubles happen in 1c databases - the 1c report that used to work does not start, the document is not held due to an incomprehensible error, it is impossible to enter the program ... One of the main means of correcting 1c errors is testing and fixing the 1c 8.3 database using the utility built into the platform.

I want to note that in case of any incorrect operation of 1C Enterprise 8.3, the main methods for restoring the program's performance are:

  1. Clearing the cache 1C Enterprise;
  2. Testing and fixing the base 1c 8.3.

The method for removing the 1C cache is described in detail in the article. Consider the second service tool for administering the 1C platform.

Testing and fixing the 1c 8.3 database using the built-in utility

To start this operation, you do not need to have any special knowledge, so any user can handle this without contacting 1c specialists. To start testing and fixing, you need to enter the 1c configurator and select the "Administration" - "Testing and fixing ..."

Description of the "Testing and repairing the 1c infobase" utility

The form that opens contains a number of items that allow you to correct errors. In order to use this tool professionally, you need to understand the purpose and logic of each of the points, so let's take a closer look at them:

  • Reindexing infobase tables.

To quickly search for information, auxiliary tables are added to the main tables with the main data, in which the data is sorted according to the specified fields of the main table - the indexing table. Due to the use of indexing tables, the performance of 1c is significantly increased, since there is no need to iterate over the entire main data table for selection, you can use the index file and select the necessary records from there.
When writing data to the main data tables, the indexing tables are also filled. But for various technical reasons, the indexes can get lost, which in the end can lead to errors. To correct this class of errors, when testing and correcting the 1c 8.3 base is performed, you must check the box next to this menu item.

  • Checking the logical integrity of the infobase

At the time of creating new objects in the 1c configuration, new tables are created in the database, which indicate links with other tables in the database. For various reasons, connections may become incorrect (for example, due to an incorrect update or an unexpected power outage at the time of recording). To fix this kind of error, select this menu item.

  • Checking the referential integrity of an infobase

To identify and correct these errors, select this menu item, while the options for handling such errors are activated below (see the figure above). We can choose how to fix errors when if there are references to non-existent objects: create objects, clear links, do not change; and with partial data loss: create objects, delete the object, do not change.

  • Recalculation of totals

To perform quick data selections in the 1c database, there are tables with already calculated data with a monthly frequency. When we apply for this data, it is not collected from the main tables (it would take a long time), but are returned immediately from the data of the totals tables. Accordingly, for this mechanism to work, it is necessary to have correct results for the past periods. Therefore, if 1s "cheats" in the reports, then such an error is corrected by this menu item.

  • Compressing infobase tables

Deleting objects in the database is a rather painstaking and time-consuming operation, therefore, in 1c configurations, the deletion process is divided into 2 stages. When you delete objects in the configuration, the data in the 1c database is nullified and, because of this, does not participate in further operations, although it physically remains in place. To clean the tables from these records, do testing and correction of the 1c 8.3 base with the "Compress infobase tables" menu item.

  • Restructuring infobase tables

When changing the details of any 1c metadata object, the database must supplement all tables of the changed object with new records. This is done through restructuring the database tables. During the restructuring process, copies of the database tables with the structure of the current configuration are created, after which the data is transferred to the created tables. If a variable is added to the 1c metadata, an empty column will be created for it in the new table; if an attribute is deleted, a column for this attribute will not be created in the new table, and, accordingly, it will not be transferred.
The restructuring process will re-create all the tables in the database, so this is the longest operation.

Testing and fixing 1c 8.3 base in practice

After receiving comprehensive information, I think that you can easily navigate what utility items you need to select to fix any.

Testing and fixing the 1c 8.3 base can be done in two modes:

  1. Testing. In this mode, the database is tested and technical fixes for minor errors are made.
  2. Testing and fixing. In this mode, the 1C database is tested and tries to fix all noticed errors (see the figure above).

To test and fix the 1c 8.3 base, you must click the "Run" button, after which in the information window at the bottom of the configurator you can watch the progress of testing and fixes.

Similar

Testing and correcting the 1C 8.3 infobase must be performed if you have errors in the infobase and before updating the database configuration. In most cases, if your infobase is damaged, it helps.

Before testing and patching, you must make a backup copy of the database. If you cannot enter the configurator, then in the folder with the installed 1C program there is a utility for testing and fixing, which does not require running the program in the configurator mode. We will talk about all this below.

Let's take a look at this tool and how to work with it. Let's take a closer look at what flags should be set in the interface.

Let's start the program in the configurator mode:

Select from the Administration menu item "Testing and fixing":

What checkboxes should I put?

There are various options for setting up testing, consider these checkboxes:

  • Re-indexing infobase tables is a complete rebuild of indexes on database tables. Re-indexing increases the speed of the infobase. The procedure is lengthy, but it will never be superfluous.
  • Checking the logical integrity of the infobase- check the logical and structural integrity of the database, fix data errors;
  • Checking the referential integrity of an infobase- check for "broken links" in the database. Such errors can occur during direct deletion of system objects or failures. There are 3 options for correcting such errors:
    • Create objects- the system creates stub elements, which can then be filled in with the necessary information,
    • Clear links- "broken" links will be cleaned,
    • Do not change- the system will only show you errors.
  • Recalculation of totals. Totals is a table of pre-calculated results in accumulation, calculation and accounting registers. Recalculation of results, as well as reindexing, will never be harmful and will give a plus in the speed of the program;
  • Compressing infobase tables- when deleting data, 1C does not delete table rows, but only "marks" them for deletion. They are not visible to the user, but will continue to be in the database. Compacting the database will permanently delete this data. The same effect can be achieved by unloading and loading an infobase file (* .dt);
  • Restructuring infobase tables- a long process by which the system re-creates the database tables. This procedure also occurs when changes are made to the configuration structure.

In our example, put all the checkboxes as shown in the figure and click "Run":

We can observe the stage of the operation in the lower left corner of the 1C configurator window. The detected errors are shown in the service messages window.

After the end of testing, click "Close":

We can see the result of the operations in the service messages window.

Testing and fixing completed.

If the configurator does not open: chdbfl.exe utility

If the base is damaged so much that you cannot enter the configurator, you can use. The utility is installed along with the 1C platform and can be found in the Bin folder of the installation directory:

Before starting testing, you definitely need to make a copy of your database, since the use of this utility can lead to irreversible consequences. Since you cannot enter the configurator, a backup copy should be made by simply copying the directory of your infobase.

After you clicked copy, right-click on an empty space in the folder window and click "Paste". A copy is made, run the utility:

The main utility window appears. We need to provide the name of the database file. Click on three dots. A window for selecting a database file opens. We are looking for the directory of your database and in it we point to the 1Cv8.1CD file. Click "Open".

Check the box “Fix detected errors” and click “Run”.

We are waiting for the end of the operation. It can take a long time, depending on the size of the base.

After execution, if errors have been corrected, they will be displayed in the utility window. In my case, no errors were found. Click “Close” and try to enter the program. If you still cannot enter, you need to contact a specialist.

The introduction of 1C 8 provides a large number of advantages, however, effective work is possible only if the system is of high quality, both functional and technological.

Functional and technological quality of the system - features and differences The functional quality of the information system is the ability of a certain configuration to solve the business problems of the company, and the technological quality is high productivity, no failures and stable operation. Quality performance management varies considerably:
  • the technological quality of the system is checked during a specific implementation of the system. 1C licensed program implemented on the platform 1C: Enterprise 8, should ensure the stable operation of several users on certain equipment. In this case, it does not matter what capabilities are inherent in the system;
  • functional quality is tested for a specific configuration and its capabilities. The quality of the system is determined by the ability to perform the assigned tasks, regardless of the conditions of use.
The functional quality of the system can be checked by the following indicators:
  • 1C licensed program solves all business problems;
  • in response to any correct user action, the system behaves adequately and predictably.

Thus, functional quality consists of two areas - subject and technical. The subject assessment of the system can only be carried out by a professional in a specific field, while the technical one can be assessed regardless of the tasks.

Why is the high functional quality of the system necessary? Developing a system for implementation requires a serious approach for several reasons. A high-quality system ensures easier implementation of 1C 8, which, as a result, saves the company time and money. In addition, maintaining a high-quality 1C system is much easier and requires less attention from specialists.

When developing new solutions based on a ready-made system, all processes are much faster and easier, and its operation eliminates operational disruptions.

How to define functional quality? The absence of errors in the program code does not mean at all that the functional quality of the system is at a certain level.

The overall quality of a configuration can be determined by a number of factors, for example:

  • availability of up-to-date and detailed reference information. By pressing "F1" the user must necessarily get help on each configuration object;
  • availability of tips. Brief tips on each form control should explain the meaning of these forms;
  • the dimensions of the screen forms should ensure comfortable work and not exceed the standard values;
  • the text of messages and warnings of systems should be concise and understandable, without spelling and grammatical errors;
  • before performing any irreversible action, the system must issue a warning with information about the operation and its consequences;
  • the program code must have up-to-date and comprehensive comments.
A complete list of requirements for the quality of the system is contained in the methodological manual "System of standards and methods for the development of configuration". System quality management - methods and possible problems The most effective way to manage the quality of a system is through prevention. As with any business, it is easier to fix the root cause of a problem than it is to fix poor quality consequences. A technique that allows you to identify and minimize configuration errors on the platform 1C: Enterprise 8 consists of several points:
  • defining the basic standards that are required for configuration;
  • checking the current version for compliance with established standards;
  • upon detection of inconsistencies, notification of specialists about the errors found; accumulation of statistical information about errors.
However, despite the prevalence, this method has several negative qualities:
  • even a small system takes a lot of time to check, and a complex configuration, which includes hundreds of objects, makes manual checking simply impossible;
  • the configuration verifier must be highly qualified and have an understanding of the standards. Even if the company has such a specialist, wasting his time on performing routine operations is not the most rational decision.
How to reduce the time spent on checking the quality of the system? The 1C company offers a convenient tool "Automated configuration check", which provides an opportunity to:
  • check configurations "1C: Enterprise 8" for compliance with development methods. In addition, the program registry can be supplemented with special verification rules that are necessary for a particular case;
  • collection of information about found system errors and automatic distribution according to the degree of criticality;
  • distribution of errors among the developers responsible for fixing them.
Applications for automated verification Using a software product 1C: Automated configuration check, you can solve several problems at once, including:
  • control over the functional quality of configurations, both production and individual, developed for a specific organization;
  • 1C support includes periodic revisions and changes to standard and industry-specific programs, and the 1C: Automated Configuration Checker solution allows you to check the quality of these revisions;
  • assessment of the quality of the configuration offered to the enterprise. In the process of preparing for implementation, the program allows you to find out not only the technological quality of the configuration, but also the competence of its developers.
In addition to the obvious advantages, the use of the 1C program for automatic system check helps to train IT professionals to thoroughly study all sections of the configuration. Checking the modifications will allow you to quickly identify all "temporary", low-quality places in the system, and personalization will allow you to accustom you to the idea that all configuration sections must be done efficiently, without hoping for subsequent revision.

Thus, with the help of a convenient 1C program, any company will be able to ensure the implementation of a high-quality system and the flawless operation of the configuration.

29.09.2016

Checking the legality of using the installed updates of typical configurations of programs of the 1C Enterprise 8 system.

Get access to the cloud 1C: Fresh for free for 30 days!

Starting with the version of the 1C: Enterprise platform 8.3.7, 1C programs have implemented a mechanism for checking the legality of using 1C applied solutions, including updates to the 1C configuration.

After installing the next update of the typical configuration and the 1C: Enterprise platform, the program may display a message that there are problems with checking the legality of using the installed configuration update in the update protection center.

The purpose of this mechanism is to inform the user in a timely manner about the actual use of certain versions or releases of the configuration, to which he does not have the rights, and the potential legal risks associated with this.

The check is performed for application solutions deployed in the file version or on the server in the MINI version. The validation check is not performed for application solutions using a base license. The verification procedure is carried out after the 1C: Enterprise system configuration update is completed, and the program makes a request to the Update Protection Center (hereinafter CPO).

Attention! At the moment, there may be technical problems with the availability of the site of the Update Protection Center https://1cv8update.com




When checking the legality of the installed configuration update, information about the program and the data of the account created during the registration of the software product and the IT support agreement on the 1C: ITS Portal are used. If the configuration update was installed unlawfully, the program periodically generates a dialog containing information about the reasons for the unlawful use of the applied solution.

In case of successful completion of the call, the CPO returns the status of the lawfulness of use. If the CPO does not confirm the legality of using the installed configuration update, the 1C: Enterprise system begins to inform all users of the information base that this applied solution is being used unlawfully, and the information received from the CPO is displayed.

Information about the results of the check can also be seen in the "About the program" dialog, which contains information on how the call to the CPO ended:


In order for the 1C applied solution to successfully pass the check in the CPO, it is necessary that the following conditions are met:

  • The program must be licensed.
  • The software product must have a valid ITS subscription.
  • The software product must be registered in the user's personal account on the 1C Portal
  • Internet user support must be enabled in the configuration.
Thus, if your 1C program reports problems with checking the validity of the configuration used, then this may be due to one or several reasons:
  • Reason 1. An unlicensed (pirated, hacked, "varezny", "patched", etc.) version of the 1C software is being used.

    Solution: We can offer two options for solving the problem: purchase a licensed version of the 1C software product or go to work in "1C in the cloud".

    Option 1: Purchase a licensed version of the 1C software product.

    Please note that you need to purchase exactly the kit that includes the configuration you are using, i.e. if, for example, you use 1C: Trade Management, then it makes no sense to purchase 1C: Accounting, because this will not solve the problem of verifying the validity of the use of the configuration.
    If you have a single-user version of the program in file mode, then it will be enough to purchase only the basic package. If the network version is used on several computers in client-server mode, then you must also purchase additional client licenses and a license for the 1C: Enterprise server.

    Cost of 1C programs

    NamePrice
    rub.
    A comment
    1C: Accounting 8 PROF. Electronic delivery



    The fastest licensing option!
    Delivery time 3-4 hours from the date of payment! *
    Basic delivery for 1 workplace
    with a software protection system.
    1C: Salary and personnel management 8 PROF. Electronic delivery
    The fastest licensing option!
    Delivery time 3-4 hours from the date of payment! *
    Basic delivery for 1 workplace
    with a software protection system.

    The cost of other software products of the 1C: Enterprise system, additional client and server licenses can be found in the price list.
    If you urgently need to legalize 1C: Accounting or 1C partners do not have this program in your region, you can purchase "Electronic delivery" in our company. Electronic delivery is a "boxless" version of the program, which is 100% licensed, functionally no different from the usual "box". After payment in your personal account of Portal 1C, you can download the installation distributions of the program, activation codes and documentation in electronic form (in pdf format). If you need the help of our specialists when installing the program, they will help you remotely via the Internet.

    Option 2: Go to work in "1C in the cloud".

    In this case, you upload your database with all the accumulated credentials to the 1C Fresh cloud server (https://1cfresh.com/).
    You do not need to purchase 1C software and install the program on your computers. Work in the program is carried out via the Internet using a regular browser or "1C Thin Client", which can be legally downloaded from the official 1C website for free.
    Access to the 1C cloud server is provided on a lease basis according to the SaaS (Software as a Service) business model. The cost of access to the cloud version of 1C is 500-600 rubles per month per user. The exact cost will depend on the number of users, the number of databases used, the chosen tariff and the method of payment.

    The cost of renting 1C programsin the cloud using the SaaS model

    NameRate
    "PROF" **
    Rate
    "TECHNO"
    Cost of ownership per user per month
    when concluding a contract for 12 months.
    495 rubles / month
    525 rubles / month
    The exact cost depends on the terms of payment *:
    • Payment monthly
    • Prepayment 3 months
    • Prepayment for 6 months
    • Prepayment for 12 months

    RUB 2970
    RUB 8031
    RUB 15498
    RUB 29664

    1200 RUB
    3498 RUB
    6546 RUB
    RUB 12528
    Number of concurrent users5 users.
    2 users.
    Available applications from the list:
    • 1C: Accounting 8
    • 1C: Salary and personnel management 8
    • 1C: Management of a small firm 8
    • 1C: Accounting of a state institution 8
    • 1C: Salary and personnel of a public institution 8
    • 1C: Entrepreneur reporting 8
    • 1C-Fireplace: Salary
    EverythingOne of the list to choose from
    Number of information basesNo limitsOne working database
    + one test / archive / demo

    *The indicated cost is valid subject to the continuity of the contract.
    ** The cost of connecting at the PROF tariff, in addition to access for 5 users to an unlimited number of databases, includes a number of additional services: 1C-Reporting; legal framework "1C: Guarantor"; full access to the 1C: ITS information system; consultations and answers of auditors and experts to users' questions on accounting, taxation and personnel issues (in the personal account on the 1C: ITS website); access to updates for box versions of the 1C: Enterprise platform and standard configurations of 1C, etc. More details.

    The first 30 days of access are free!
    In order for you to evaluate the availability, stability, speed and usability for yourself, we can provide free access to the 1C: Fresh cloud service for 30 days.

    Information materials:
    -
    - Instructions for loading a database from a local computer into the 1C: Fresh cloud service
    - Instructions for installing and configuring a 1C thin client to work with the 1C: Fresh cloud service
    - Application form for connecting to the cloud service 1C: Fresh
    - Application form for self-registration in the cloud service 1C: Fresh

  • Reason 2. There is no valid contract for information technology support (ITS).

    Solution: conclude an agreement for information technology support. If you urgently need to subscribe to an ITS, you can subscribe to it in our company even if you are in another region of the Russian Federation and purchased the 1C program in another place. The only condition is that the program must be licensed.

    ITS subscription cost

    Pay attention to the following points:

    • There are two options for ITS subscription: ITS Techno and ITS PROF, which differ in information content. ITS Techno includes the minimum support option (access to the 1C technical support site for self-downloading updates). ITS Prof, in addition to access to updates, includes a number of additional services and services, for example, 1C: Reporting, 1C: Counterparty, 1C: Fresh, 1C: Cloud archive, legal base "GARANT" and many others. For a detailed comparison of ITS Techno and PROF see.
    • The cost of an ITS subscription depends on the period of the contract. The minimum option is a one-time subscription for 1 month, but given the need to regularly update accounting software for 1C: Accounting, we recommend subscribing for a longer period.
    • The cost of a subscription for continuous renewal of the ITS subscription is less than for its renewal.
      NamePrice at
      continuous
      prolongation
      rub.
      Price at
      renewal
      contract
      rub.
      ITS PROF one-time subscription for 1 month
      4818
      ITS Techno for 6 months

      7854
      ITS Techno for 12 months

      15036
      ITS PROF for 3 months

      9636
      ITS PROF for 6 months
      18600
      ITS PROF for 12 months
      35592
  • Reason 3. The software product is not registered in the user's personal account on the 1C portal.

    Solution: register the software product.
    Instructions for registering software products in the personal account of Portal 1C: ITS (portal.1c.ru)
    If the user has not previously registered on the portal, then before registering a software product in his personal account, the user must first register on the portal on his own and receive a login and password to access his personal account.
    Instructions for registering users on the 1C: ITS Portal (portal.1c.ru)

  • Reason 4. Internet support for the user in the 1C program is not configured.

    Solution: set up internet support.
    Instructions for connecting Internet support in typical configurations 1C: Enterprise 8

Technical problems

If you are using a licensed version of the program, the software product is registered in the personal account of the 1C portal, there is a valid ITS subscription and Internet support is configured correctly, and the program still displays the messages "Licensing center unavailable", "Configuration registration in the licensing center was not completed", "The remote node did not pass the check", etc., then technical problems are possible:

1. The CPO server https://1cv8update.com is unavailable
In this case, it is necessary to check the server's health and availability for blocking by antivirus, firewalls, firewalls or proxy server security settings.

2. On the website https://1cv8update.com, the security certificate was updated, and you are using the old 1C: Enterprise platform (or the compatibility mode is set) below version 8.3.8. In this case, you need to update the platform version, configure compatibility mode, or manually register the security certificate in the cacert.pem file in the bin directory.

3. Perhaps the server of the Update Protection Center is simply overloaded, try repeating the check procedure several times by clicking the "Retry now" button or performing the check later.



Clarifications on the terms of distribution of software updates 1C Enterprise

When selling 1C software products, non-exclusive (limited) rights to use the software are transferred from the Copyright Holder (1C Company) to the Licensee (user) in accordance with the terms of the License Agreement included in the delivery of the Software Product. At the same time, the Licensee undertakes to strictly adhere to and not violate the rules for the licensed use of software products, and violation of the terms of the "License Agreement" is considered a violation of copyright and is prosecuted.

According to the "License Agreement", the cost of 1C software products currently includes information technology support (ITS) for 3 months, which includes the monthly receipt of ITS DVDs; receiving software updates, configurations and reporting forms; consultation line services; access to the 1C technical support site (from 01.01.2016 you can purchase a "diskless" version of the ITS).

After the expiration of the free support period, 1C programs are serviced only under an ITS contract on a paid basis.

In addition, when installing an update, the user confirms his agreement with the terms of distribution and use of updates and accepts responsibility for violations of the terms of use, otherwise the user must refuse to install the update.

Thus, not only the programs themselves, but also UPDATES to the programs of production of the company "1C" are objects of the exclusive right of the company "1C" and are distributed according to the rules established by the company "1C" as the copyright holder in accordance with Art. 1225 of the Civil Code, and an unauthorized SPREAD and USAGE updates are considered copyright infringement and are prosecuted:

  • Art. 1301 of the Civil Code of the Russian Federation,
  • Art. 7.12 of the Code of Administrative Offenses of the Russian Federation,
  • Art. 146 of the Criminal Code of the Russian Federation.

Updates and information resources must be obtained by the user through legal distribution channels:

  • disks of information technology support
  • sites of the company "1C": www.1c.ru, v8.1c.ru, online.1c.ru, its.1c.ru, portal.1c.ru, releases.1c.ru, users.v8.1c.ru
  • offices of partners of the company "1C"

Updates received from other sources are ILLEGAL:

  • copied from a friend
  • the update was installed by "student Vasya" (source unknown)
  • downloaded from a site that is not the official site of "1C"
  • bought in a stall
  • etc.

It is very simple to find out the eligibility of using the update: 1C company is provided with information about all legal ITS subscribers with registration numbers of installed software products of 1C company and the subscription period, each update has a unique number and the release date, date and time of installation of the update on the user's computer are known is fixed in the program itself, i.e. in case of checking with the user at the time of release and installation of updates, a subscription to the ITS must be issued.

Checking for an ITS subscription

In order to avoid claims from law enforcement agencies and clarify the legality of using updates and information resources, we recommend that users check for an ITS subscription for their software product on the 1C website:
.
After entering the registration number of the "1C: Enterprise" program being used, a message will appear on the screen about the presence or absence of a valid ITS subscription.

  • Check if you have sent a registration form to 1C
  • If the data has changed - report it to "1C"
  • Make sure that the channel through which you receive updates is legal (official partner of "1C", official sites of "1C")
  • Before signing up for an ITS subscription, check whether the company serving you is an official partner of 1C
  • According to the registration number of your program, make sure that the subscription is registered in "1C" on the site
    http://www.1c.ru/rus/support/support.htm
  • Don't forget to renew your subscription in time

Do not require an ITS subscription:

  • Basic versions of software products "1C: Enterprise",
  • "Cloud" versions of 1C programs used in the 1C: Fresh cloud service

Tags: Checking the legality of receiving updates to 1c configurations, checking the legality of updating 1c 8.3, monitoring the legality of 1c updates, 1s download updates, its, 1s its, disk its, checking the legality of 1c 8.3 7, users.1c.ru, its.1c.ru, accompaniment 1s 8

Indeed, the complexity of 1C configurations is increasing every year, teams are growing, products containing more than 5,000,000 lines of code are released. It becomes difficult to work without ordering the streams of code. And it's not just about maintaining a minimum order - prefixing new objects, commenting conventions, or scattering objects across subsystems. As teams grow and configurations become more complex, the need to adhere to broader standards becomes clear.

And in order not to be shoemakers without boots, it is good to have the right tools for this purpose. Interesting tools are offered at conferences and webinars, including those listed above. At the same time, a rather little-known configuration from 1C itself also deserves attention. As you already understood from the title of the publication, this product is called “Automated Configuration Checker”. It is free, available to every user (formally, access to ITS is required to use it), quite easy to use, but so far not very widespread.

This is partly due to the fact that 1C itself actively promotes the idea of ​​compliance with standards and the use of tools suitable for this only among developers of production solutions through the 1C: Compatible certification. The impact of the idea of ​​adherence to standards and code cleanliness on the general mass of developers who do not deal with mass-produced solutions is much weaker. Even familiarization with the basic development standards is under a conditional lock - the availability of access to ITS (information is out of date, currently, for 2018-2019, access is open without registration) :

Basic information about the agro-industrial complex

The APC configuration is designed to automatically search for errors and deviations from standards in configurations. Its use has been recommended by 1C since 2009, and not only in companies that develop circulation solutions, but also for other companies in which standard solutions are being finalized and adapted:

The first impression about the configuration can be given by the page on the 1C website:

It describes the main features of this tool and says that it helps:

    adhere to typical development standards and perform platform configuration checks

    create and follow your own configuration validation rules

    comply with the standards required to obtain 1C: Compatible status

    perform scheduled checks

    check spelling mistakes

    assign various statuses to detected configuration errors, including marking them as “features” that do not require correction

    slightly facilitate the verification process by yourself performing some actions such as updating the demo database configuration from the repository, the possibility of a step-by-step verification, etc.

    even the possibility of integration with DSS is mentioned

Another source of general information is a publication in the online magazine PCMagazine:

Apart from these overview materials, there is almost no information on the web about the APK and its applications. The good news is that a PDF user manual is included with the configuration itself. Some issues are not covered in the manual in as much detail as we would like. But still there is a manual and allows you to learn how to perform basic techniques when working with configuration.

In order not to repeat the user's guide, here we will consider an example of using the APK for checking a typical configuration, and not a demo configuration from the APK delivery. We will also try to consider the details of the work, which are not mentioned in the manual.

Let's start from scratch. You can download the latest version of the APK from the following link:

At the time of publication of this article, the latest release is 1.1.12.26 from 01/30/17, but at first it was written for version 1.1.11.16, so some of the screenshots and comments will refer to this version. To work with APK 1.1, you need a platform version of at least 8.3.6. After installing the configuration delivery, three new items appear in the list of configuration templates:

The first template is a pure APK database. All standard rules are present in it, but there is no loaded demo database data for testing, which are present in the second template.

The second template “Automated configuration check (demo)” after deployment contains the loaded information about the demo database (located in the third template). You can use it to see how reports and standard checks work. It is best to learn how to work with this database armed with the user manual from the delivery, since the examples in the manual are designed specifically for this demo base:

The APC works in such a way that, when performing new checks, it loads information from the checked configuration via a COM connection. To do this, she needs an existing file "experimental" database. Therefore, if there is a desire not only to familiarize yourself with the interface of the demo database, but to carry out a full cycle of working with the database being tested, then it makes sense to also deploy one more file database from the third template “Demo configuration for testing”.

In this case, we will get two databases - one demo agro-industrial complex with already loaded information about the checked Demo base and the checked Demo base itself, which allows you to quickly familiarize yourself with the process of connecting and conducting new checks.

I would like to note that after experimenting with demo bases, a clean base of the agro-industrial complex may not be deployed. Working configuration checks can be performed on the same configuration as the demo database checks. In the APK, you can download information about any number of databases to be checked.

In general, the principle of operation of the APK is similar to the work of "Data Conversion". Work in the APK configurator is not required (although, as it will become clear later, it will hardly be possible to do without it at all)... Information about the structure of the checked configurations is loaded in user mode. It also specifies the algorithms for checking the configuration in the form of a code in the 1C: Enterprise language, which is then executed by the system itself using the operator “ Execute”. In the code, you can and should use the built-in APK (non-platform) methods - procedures and functions that perform work with automatically created objects. The objects necessary for carrying out the configuration check are created by the system itself and become available in the code of the check handlers. A detailed description of these methods, objects and handlers can be obtained from the 6th chapter of the "User's Guide".

The configuration of the AIC is almost entirely based on reference books, information registers and processing. In general, if you are familiar with “Data Conversion”, then the principles of working with the APK will be clear. Moreover, if there is no clear need for our own check algorithms, then at first it will be possible to restrict ourselves to standard checks and not study the built-in methods and program objects of the system. Then almost all the settings can be done with the mouse and it seems that this will be enough for many tasks.

Configuring connection to the checked base and default checks

After starting the demo database, we see the following interface:


The purpose of the sections from the point of view of APK developers can be found in the manual. We'll go in order and add a new configuration first. Click on the "New configuration" button. The system will prompt you to fill in the connection parameters. In fact, the form of the "Configurations" catalog item opens:


The name and full name are arbitrary text fields, only the feeling of beauty and the length of the field can limit you in what will be indicated in them. But further restrictions are more stringent. You need to specify the full path to the executable file of the 1C platform. In earlier versions of the APK, you must additionally indicate the version of the platform with which you are working. Let me remind you that the APK can only check configurations on the platform version 8.3.6 and higher.

Information from the developers:

If the path to the platform is specified below, then an error will be generated during the COM connection.The reason is as follows. In connection with the development of the platform and new checks of the APK, information (metadata properties) are collected that appeared only in platform 8.3.6 or higher. Thus, when checking against versions, for example, 8.2 when collecting such information, of course, an error will be issued. And since these new checks, as a rule, are priority ones, the ban on starting a scan is set lower than 8.3.6. In the opposite case (if the principal version of the platform is lower for the client), then it is assumed that he can use the previous versions of the APK to check his configuration.

Next, you need to specify the path to the demo database and the parameters for connecting to it. Under demo base in this case, we mean nothing more than a specially dedicated file base that contains the checked configuration. There are no possibilities for connecting a SQL database to the APK. This can be modified if desired, but it doesn't make much sense. First, it's just a configuration check, not unit testing or load testing. In this case, even for large configurations like ERP 2, just an empty file base containing the current configuration is sufficient. Secondly, in accordance with the 1C standards, any configuration should be designed to work not only with a SQL database, but also in a file version.

If you are developing using the repository, then the APK is able to automatically update the database configuration from the repository before performing a new test. The lower group of parameters in the screenshot is intended for this.

Note also that the DSS, like the APK, requires a file base to load configuration information. Therefore, if you decide to develop using the technologies offered by 1C, using APK and DSS, then for both of these systems it will be enough to create one file base, if necessary, connect it to the configuration storage and set up automatic configuration update from the storage before loading data.

The choice between the "Configuration" and "Library" modes determines the severity of the checks. For the "Library" mode, the checks are tougher. A library is a configuration that can be embedded in others, which means that it must comply with certain rules and “think not only about itself”. If you hover the cursor over both options of the switch, a hint with a description of the check differences will pop up. In particular, all selected requirements will be checked for the library. Requirements from the Develop and Use Libraries group are not checked for configuration, whether selected or not. This group of requirements contains very long-term validation rules that are really only for libraries.

An important point for version 1.1.11.16 and earlier versions of the APK (in version 1.1.12.26 this error has been fixed). After the settings are specified and the item in the “Configurations” directory is written down, you can check the connection. But for the first time, the system may give an error about the lack of connection.


This is a misleading message. If the paths and users are set correctly, you just need to pre-record the element of this directory and only then check the connection. Then the system will report on the successful connection. Checking the connection to a large database, for example ERP, can take up to 1-2 minutes:


In fact, now we have created a new item of the "Configurations" catalog. Now you can open it in different ways:

  • Through the menu "Settings" -> "Configurations"


  • In the "Checks" section, click "Select configuration"


  • Or just open the “Configurations” directory through the “Operations” menu

Let's go back to the configuration settings window.

On the second tab “Requirements to be checked”, you can configure what checks we want to perform on our configuration. There are two predefined options available: "Full check" - check for compliance with the system of standards https://its.1c.ru/db/v8std and spell control, as well as "1C: Compatible" - check for compliance with 1C: Compatible standards http://1c.ru/rus/products/1c/predpr/compat/soft/requirements.htm


You can also set up an arbitrary set of requirements to be checked, then insert an arbitrary representation of a variant into the “Verification variant” field and save it under this name by clicking the “Save variant” button. Variants are saved in relation to configurations, that is, the same setting cannot be automatically applied to other elements of the "Configurations" directory:


Let me make a note for those who plan to use the APK for several configurations and do not want to configure checks for each of them separately. You can transfer check settings between configurations by writing a simple script, if you know that they are stored in the "Configuration Requirements" information register, and the check options themselves are stored in the reference book of the same name:

The list of checks is quite lengthy. Each requirement is a development standard, adhering to which can make our products better. But the ability to disable individual requirements or their groups is also not superfluous. For example, at most enterprises, you can limit yourself to the "Full check" option (spelling + system of standards) and not do checks for "1C: Compatible". Or at least control the spelling, since there is no such thing that development has been carried out for years without a single spelling error.

The list of requirements selected here is the default list for automatic checks. As you step through the test, you can override the values ​​specified here.

Information from the developers:

It makes sense to tell in more detail what the "System of Standards" group is and how it differs from the other two groups. So, let's start with the "1C: Compatible" group. As previously written, this is a mandatory set of standards for obtaining a certain status for its configuration. Roughly speaking, this is the backbone that all configurations, without exception, must correspond to. By the way, this group of standards does not check the configuration for spelling errors ...

Further "Spelling" is a group of standards that checks the configuration only for spelling errors. Every self-respecting developer can spell check his configuration. This group contains all the checking rules that track spelling in module texts, metadata (name, synonym, comment), form elements, layouts, in general, wherever you can check text. Only the Russian text is checked out of the box, but as noted in the comments, for other languages ​​you can load your dictionaries and even replace the supplied configuration with them.

And now about the "System of Standards" group. It is the most global one and contains checks for the other two predefined groups of requirements, as well as additional specialized checks. For clients, errors in this group are more likely recommendations, although for typical configurations, most errors, of course, must be corrected. That. if any standard is described in the "1C: Compatible" or "Spelling" group, it will undoubtedly be described in the "System of Standards" group as well, however, maybe in more detail and with deeper checks.

Various filtering is configured on the "Scan exclusions" tab. For example, you can configure checks so that only objects you have added to the standard configuration with a specific prefix like “ mf_ Super Customs Declaration ”.

Or, if you are developing with the addition of all changed or added objects to a specific subsystem for development, then it makes sense to check only within this subsystem, and bypass the unchanged objects of the typical configuration that are locked. If you need to temporarily exclude a configured filter during checks, you do not need to remove it. It is enough to uncheck the use flag (second column):

The filtering function is very useful and it makes sense to experiment with it, which we will do next. I must say right away that permissive checks like "Include a subsystem" and "Include with a prefix" work by "OR". That is, an object will be checked if it meets one or another condition. This is not always convenient. Fortunately, changing this behavior is very easy. This issue will be discussed in more detail in the section devoted to filtering, as well as the question of the effect of filters on the time of checks.

In APK version 1.1.11.16 and earlier versions, filtering settings were divided into two tabs - “Requirements collection filters” and “Data collection exceptions”, but the meaning was the same:


Also, in the settings form, you can set the need for scheduled checks:


This is the setting not to work through a scheduled task... To run a scheduled scan, the APK must be launched in user mode and running. At the start of the system, the method is called in the module of a regular application At the Start of the System () where the wait handler is connected RunCheckScheduled (), which performs scheduled checks. If there is a desire to start a check with a routine task, the system will have to be modified. If you look into the configuration of the APK, you can see that it contains only two scheduled tasks, and both of them are not related to scheduled checks:

Information from the developers:

The explanation is very simple. If the APK is deployed in the SQL version, then when you specify the path to the configuration (more precisely, the demo database) on the client, the check simply will not start, because a scheduled job always runs on the server. In the file version of the agro-industrial complex, of course, a scheduled job would be more suitable than a wait handler.

The schedule is not the last possible tab. If you enable the integration with the “Applied Solutions Design System” in the system, then another tab “Integration with DSS” will appear, which allows you to configure the automatic registration of errors in the DSS. Integration setup at the system level is performed in the form of constants (“Operations” - “Constants”).

The functionality of integration with DSS was intended by the developers of the agro-industrial complex for internal use in 1C (this is described in the "User's Guide", page 28). However, I am sure that for those companies that already use DSS in their work or plan to use it, this functionality will be interesting. You can take it as a sample for implementing your own integration mechanism or deal with it and use it out of the box:


In this case, it is possible both to connect the agro-industrial complex to the web service raised from the side of the DSS, and vice versa, you can configure the connection to the web service raised on the side of the agro-industrial complex in the DSS:

Carrying out inspections

After the connection settings have been made and the checks to be carried out have been selected, you can proceed to performing the checks.

To perform a new check, you must first make the checked configuration current. All new checks are performed on the “current configuration”. To do this, in the “Checks” section, click “Select a configuration” and then select an element of the configuration reference that will be assigned “current”.

When you click on the "New check" button, the system will offer two options - to check again by connecting to the checked configuration, re-collecting the data, or to check the previously collected data.


The ability to conduct checks on previously collected data allows for lengthy checks to be carried out in stages. For example, you can first collect configuration data and perform a filtered check on a subset of the subsystems. Then enable filters for other subsystems and do the second check based on previously collected data, which will allow you to perform it much faster.

Information from the developers:

It should also be said here that now the composition of the collected data directly depends on the selected requirements. For example, one requirement "Spelling in module texts" is selected. If you open the card of the requirement itself and go to the "Verification stages" tab, you can see that only 1 checkbox "Fill in information about modules" is selected:

This means that when checking the configuration for spelling in the texts of the modules, only the collection of the texts of the modules will be performed (neither the properties of the metadata objects, nor the elements of the forms, nor the layouts will be collected - all types of information collection can be selected by the other flags).

This functionality of the dependence of the collected information on the selected requirements appeared relatively recently, previously, with each check with the collection of data, all information was collected. So earlier this option helped a lot: some one requirement was selected, for example, the same modules, all information was collected, errors were corrected for this one requirement, then the next requirement was selected, for example, spelling in form elements, and the check was started already according to the collected data, because form elements did not change, etc.

Now it can also be used, but only those requirements that were collected earlier can be checked against the collected data. Well, one cannot but say that this verification option is extremely necessary for the developers of new checks for debugging, testing, speeding up and identifying inaccuracies in the verification rules, since no need to rebuild the data every time.

Since we have not yet collected any data, we will select the item “Collect and verify data ...”. A window will open in which you can choose to conduct either an automatic check using the settings previously made in the new configuration window, or override these settings. Choosing the “Manual” option is especially convenient at the initial stage of acquaintance with the system, when you can influence each next step.


By clicking on the "Next" button, you can override all the settings that were described in the previous section of this publication, including the checks performed. However, it should be borne in mind that if you do not select a single check at the appropriate step, then the system will consider that you need to perform ALL checks, and not just connect and download information about objects from the database being checked:


Therefore, if the purpose of the launch is not a complete check, but updating the configuration structure or a test run of the APK and familiarizing yourself with the process, then you should not uncheck all the boxes at this step. For the first time, it is advisable to mark only one item, for example - "Platform configuration check" in the following branch:

In this case, the list of verification steps will be approximately as follows:


and can take as little as 20 minutes even on ERP. But this will be enough to get an idea of ​​how the process actually takes place. Although platform validation can be a surprise and time-consuming process, you can opt for a simpler element as well.

At the last step, you can also set filters on scanned objects. True, if this is the first check of the configuration, then the APK will not yet have information about the configuration structure. In this case, the configuration tree at this step will be empty, but you can load it by clicking the "Read configuration structure" button directly from the same window:

Now it remains to press the button "Perform check". The verification process will begin. With the blinking of 1C windows and the output of the process log to the message window. The log output is made very inconvenient. The check window hangs modally, and if you do not think in advance about making the message window visible, then you will not be able to find out anything about what is happening until the process ends:


Therefore, if you have a low screen resolution, then it is better to immediately attend to moving the modal window for starting the scan so that the message window is visible.

At one of the stages of verification, the system updates the contents of the "Configuration structure" directory, which contains a tree (hierarchy) of metadata objects as in the configurator. Data about a specific object will be updated if this object has changed or was included in an additional subsystem. A catalog item will be marked for deletion if the corresponding configuration object has been deleted. New elements will be created for new configuration objects:

Also, with each check with data collection, the contents of the "ObjectPropertyValues" and "CompactObjectPropertiesValues ​​"registers, which store object properties, modules, layout content, form elements, etc., are updated. When checked against previously collected data, this information remains the same.

If any checks are selected that require not only updating the metadata structure and platform verification, but also something more, then the system will unload the configuration into files for their subsequent analysis:

Uploading occurs without hierarchy - all files are in one folder:


Information from the developers:

So, what and when is going ( when checking with data collection):

  • The configuration structure is generally always, no matter what requirements are chosen.
  • Collecting occurs by running external processing from the common layout MetadataStructure Loader in the enterprise in the thick client. Processing in the enterprise works with the object of the "Metadata" platform and writes data to an external file, which is then transferred and parsed in the APK.

All further steps that trigger external processing in the enterprise operate in a similar manner. The rest of the information, as mentioned above, is collected depending on the selected requirements:

  • The collection of information about metadata (again, these are properties of metadata objects, and not the structure itself) occurs by launching external processing from the general layout "MetadataDataLoader".
  • Collecting information about forms (more precisely, about form elements) - using processing from the "FormDataLoader" layout.
  • The collection of information about forms from XML occurs by parsing the XML file of the form from unloading the configuration into XML files. All information that could not be obtained from the enterprise at the previous stage is collected.
  • Gathering information about modules - by reading module texts from XML upload files.
  • Collecting information about roles (more precisely, collecting the rights of each role for each object) - from the XML upload role files.
  • Collecting information about layouts - using processing from the layout "LayoutDataLoader".
  • Gathering help information - by reading the help files from the XML upload files.

Platform verification of configuration - batch launch of the demo database in the configurator mode with platform verification keys. The file with the check log is also indicated. Then it understands the APK, and it produces platform validation errors that are stored in a separate "ConfigurationVerification Errors" register.

Thus, if at least one requirement is selected with the checkbox for collecting information about forms from XML, roles, modules, or help, then the checked base will be dumped into XML files. If none of these actions are required, then the upload will not take place.

Previously, all actions were performed sequentially. First, the collection of the structure was started, then the upload to XML, then the platform validation, then the collection of metadata properties, modules, forms, etc., which greatly slowed down the validation (data collection) of large configurations.

In APK 1.1.12, copying of the original database to a temporary directory was added and the longest stages of data collection were identified, which made it possible to parallelize data collection during verification. Thus, at the moment, collecting the configuration structure, platform validation, unloading to XML, and clearing registers are performed in parallel. The rest of the steps take little time, even for ERP. As a result of the introduction of parallel information collection, it was possible to speed up the ERP check by at least a couple of hours.

In the directory of temporary files, processing is generated and opened in the checked base, which create instances of metadata objects and create forms and object layouts. This mechanism was originally intended to collect information about forms, layouts, and metadata properties. But also thanks to it, errors are looked for that do not even allow you to create an object or form programmatically. Of course, this is far from unit testing, but already something:


If an object or form module attempts to access an undeclared variable or an object inaccessible from the module context, the system will either stop during the check process with an error (there will be a window in the opened checked database), or the APK will catch this error and show it in reports. If the APK stops during the verification process due to such an error, then it is certainly not very convenient. But on the other hand, the presence of module compilation errors is a critical error of programmers and it is better if it is detected using the APK in such a way than it gets into production and a message about it will come from users!

In the process of a full check (or its analogue in terms of the number of rules and objects), the system gets stuck on checking object # 1 without informing in any way about the progress:


This status with the message that the object # 1 out of 77 thousand is being checked hangs for 5-10 hours and it seems that the agro-industrial complex is frozen. In fact, the process is going on, you can verify this by looking at the processor load in the task manager or by calling the stop from the configurator (if the APK was launched from it). The reasons for the long check of Object # 1, namely the configuration itself, are as follows:

1) As part of this step, information is collected and cached, which is used further when performing checks on individual objects. This makes checking the rest of the objects faster.

2) Most of the checks that affect all configuration objects at once are performed within this step. There are many such checks, about 90. But the most lengthy, most of the time, only a couple. For example "Finding Unused Service Export Methods"... Obviously, it is impossible to infer whether or not the method of an individual object is being used by checking only that one object or some particular subsystem. This conclusion can only be drawn by analyzing method calls across the entire configuration. And it is obvious that it is optimal to bypass the entire configuration once, when checking "Object No. 1", and not many times, when checking individual documents and reference books. Another example of a lengthy check is "Control of the presence of a common module, subsystem, method and control of the composition of parameters".

If you disable the two specified checks and platform verification of the configuration, then checking even such a configuration as ERP can take no more than half an hour. But you probably shouldn't save time and sacrifice quality. It is better to resolve this issue organizationally and do checks in advance.

I give an example - the beginning and end of the check execution log, which shows that the entire process on ERP 2.1 and APK 1.1.11.16 takes about 15 hours (of course, the figure strongly depends on the performance of the computer, also check speed on APK 1.1.12 is much faster and under the same conditions it takes about 10 hours):

: Checking the connection to the infobase via a COM connection

: Start collecting information about the configuration metadata structure

: Start uploading configuration to XML files

: Start cleaning up metadata information

: Start collecting information about configuration roles

: Collected and recorded information about configuration roles

: Gathered configuration metadata information

: Platform check configuration completed

: Start testing configuration objects

: Start collecting configuration form information from XML files

: Configuration check started

…… ... HERE MESSAGES BEGIN TO BE DISPLAYED IN THE STATUS LINE… ..

: Configuration check performed

Result of checking

What do we get as a result of the first check? First, the directory of configuration versions is filled in (the "Versions" directory is subordinated to the "Configurations" directory). An element corresponding to the version of the checked configuration appears in it. The version information is also updated in the form of the "Configurations" catalog item:


Secondly, a document of the "Configuration Check" type is created, which specifies this element of the "Versions" directory and other check parameters - the list of checked requirements, the list of checked objects and the "Check log", which duplicates the log displayed earlier in the message window:


Third, the data about the configuration structure is updated:


The configuration structure is a hierarchical directory with a hierarchy of elements, subordinate to the "Versions" directory, that is, when checking the configuration of a new version, a new item of the "Versions" directory will be created and a new metadata structure will be loaded in conjunction with this version.

And fourthly, the “Found errors” register is filled in, which actually contains information about which errors were found during the verification process and is the basis for the APK reports:


No list form has been created for this register. The dump in this common register boiler can be put in order in just a few minutes. For example, add a managed form, in user mode or directly in the configurator display the owner of objects (elements of the "ConfigurationStructure" catalog) to which errors are attached. These owners will be the configuration versions.


If we display the owners and from them, we will get in the form of a list the ability to filter errors both by configurations and by their versions. You can make groupings on them. In this case, it will be possible to work with errors not only with the help of reports, but also directly through the register, which is sometimes much more convenient:


Each entry in this register is a found nonconformity, spelling or other error. Opening any of them, you can make sure that even such reliable and proven systems as ERP 2.1;)) contain typos and errors. Moreover, a fairly large number of them:



I would like us to perceive the presence of such errors in ERP not as an indulgence for their presence in our developments, but as additional proof that they can and should be identified and eliminated. Especially with the right tools. Because they look ugly and this is exactly what our users see. The 1C blog on Habré notes that ERP 2 developers use the AIC to check the configuration, but apparently limit the list of checks to the most important rules from their point of view, ensuring an acceptable ratio of development speed and product quality. We can, when developing our products, raise the bar for quality and capture this direction as well.

It will also be useful to know that the collected data about the texts of modules, blocks of modules and other properties of configuration objects is placed in the registers “Values ​​of composite properties of objects” and “Values ​​of properties of objects”. The records are stored in conjunction with all the same objects, subversions and configurations:


You won't be able to see the module texts directly from the register forms, they are all packed in value stores.

But for viewing the texts of modules, already divided into component parts, and other properties of configuration objects in the APK there is a wonderful tool! This is the processing "View properties of configuration objects", opened through the "Settings" menu:

APK reports

Information about the errors found in the form of reports allows you to get at once two sections of the system. Section "Errors":

It builds on the FoundErrors report:

And the section "Reports"


It is built on the basis of the "Work Results" report:

In fact, there are only two main “Report” objects in the AIC configuration. But they have quite a few different ACS layouts:

All of them are based on the analysis of the "FoundErrors" information register. The “Reports” section is intended for obtaining summary information on errors, it has a statistical focus, while the “Errors” section is for obtaining detailed information on errors and their management. In the "Errors" section, control is possible both with the help of a special command panel, and through the context menu:



There is a problem when using the APK file base and 32-bit 1C platform. If you do not install a sufficient number of filters, then when analyzing large configuration errors, you may receive an out-of-memory message. In the case of ERP 2.x, this message will appear constantly. This error usually occurs already at the stage of data output to a spreadsheet document. In general, it is worth putting filters. Only a few of them were included in the quick tackles. The rest can be set using the "Report settings" command.

It gets in the way of the fact that reports begin to form immediately after choosing an option. This greatly interferes with the work and suggests the need to finalize the configuration of the agro-industrial complex up to writing your own reports: you want to impose selections before they are generated, and so that the report settings are saved, and that they are on a controlled form. Fortunately, on the basis of just one register of information, this is not difficult to do.

Note that when using a 64-bit version of 1C or sql database of the APK, an error with insufficient memory is not observed.

From a first glance at the reports, it seems that the APC is too picky about the checked configuration. For example, it requires the assignment of correct synonyms even for layouts of printed forms, perceives as a mistake the words “logistic”, “add”, “accountable”, etc. But first, most of the errors found really need to be fixed! Second, the choice of the rules to be checked is provided to the user; it can be made both when setting up the checked configuration and when performing a check. Thirdly, each of the rules can, if desired, be modified, replaced with your own, or you can set up filtering in reports in such a way as to see only the information of interest.

Finally, there are other customization options in the system. For example, the information register “TrueWords” (initially empty). It participates in spell checking, in particular the Check.Check Spelling () method. Words that we believe to be correct can be entered manually or loaded from a text file, in which each word is on a separate line. A sample of such a txt-file can be unloaded from the general layout “Dictionary of True Words”. But you do not need to load this file into the register. By default, the system takes the correct words from this layout and supplements it with data from the register. There is also a processing in the system " Dictionary update". Its use is described in great detail and clear in the user manual (see chapter 4.6).

In general, if it seems that the system is too strict for our configurations, then you can tweak it in the right places and "cajole"))

The most interesting reports are "Requirements Errors" in the "Errors" section, which displays data in a grouping corresponding to the structure of the "Requirements" directory:


and “Error analysis” in the “Reports” section, which displays summary data based on the classification “1C: Compatible”, “Mandatory” and “Recommendation”:


Configuration validation rules

Creation of your own rules using specific examples will not be considered here. First you need to better understand this issue yourself. In the user manual supplied with the APK, a rather voluminous Chapter 5 is devoted to the creation of new rules - this is a cross-cutting example in the form of as many as 30 pages of fascinating text and illustrations))

Let's go over the rules in an overview. They are located in the system's directory of the same name:


Navigation in the left tree is inconvenient - you can double-click to select an element to display its composition in the right part. Therefore, the selected element does not always coincide with the one whose composition is displayed on the right.

Each rule can be opened. The form of the directory element gives access to the list of object types that must be checked by this rule, the algorithm parameters (a numbered list of errors that can be referenced from the algorithm), the algorithm itself and its description, a description of the requirement, as well as settings for use:


There are three useful buttons at the top. "Show standards" leads to the corresponding section of the 1C site with a description of the standard, the link opens in the browser. “Open Requirements” opens the “Requirements” catalog item corresponding to the rule, and the “Open Debug” command starts processing the “ValidationRulesDebugger”. How it works in the user manual is silent, but it is obvious that debugging tools are either available, or there are developments for them that can be developed.

The rule algorithm can be changed, as well as new rules and rule groups can be created. If you need to write your own algorithms, you will have to study built-in methods and program objects. This is the topic of the corresponding section “Syntax of Check Rules” in Chapter 6 of the PDF User's Guide. You can also use the algorithms of existing rules as examples and examples for copying.

The built-in help for the program is disastrously scarce. Rather, it is absent, so the description of built-in methods cannot be obtained from it.


Filtering objects during checks

In conclusion, let's see how APK 1.1 behaves when checking with imposed filters. Do they really help to shorten the verification time and reduce the amount of information in the reports? Let's check both prefix and subsystem filtering.

In this section, there will be more "burying in the code" than a story about the capabilities of the agro-industrial complex. If this is not your goal at this stage, you can skip this section.

Let's take all the same experimental configuration, create a new element for it in the configuration reference (only you need to create an element not by copying, since when copying configurations, their versions and data structure are also copied, this is a long process and violates the purity of the experiment). Let us classify documents as two new subsystems:

apk_Document_1_1,apk_Document_1_2 and new_Document_1_3 we refer to the subsystem apk_Subsystem_1

apk_Document_2_1, apk_Document_2_2 and new_Document_2_3 we refer to the subsystem apk_Subsystem_2

Let us make spelling mistakes in the documents and add an unused export method to the manager module. We will create documents by copying.

Let's add two filters for collecting information - per prefix apk_ and on the subsystem apk_Subsystem_2 (screenshot taken on APK version 1.1.11.16):


As a result of the check, we expect to see errors and error reports concerning only documents matching filters. (as shown below, filters are applied "OR")... I would also like to speed up the verification process, with a discount on the fact that some operations and checks are performed regardless of the number of objects being scanned.

Let's start the check. After a couple of hours of basic checks (including platform checks), we will see that the number of objects for further checks is no longer frightening 77 736, but only 65:


As a result of the checks, reports really stop giving information about "extra" objects and only report about objects that match filters. At the same time, both specially made mistakes were found, and other comments were made:


However, there is almost no gain in checking time from filters. In this example, the full check instead of 15 hours took 10 hours, that is, it was accelerated by only 30%. The section "Conducting Checks" has already explained the reasons for this behavior. Now let's figure out why this happens at the code level and at the same time understand more deeply how the algorithms for filtering and bypassing configuration structure elements during checks work.

The reports show that in addition to information about documents, information about the root configuration element is also collected as part of general checks. And when conducting inspections, it is difficult not to notice that it is the message about the inspection of this object No. 1 that hangs in the status bar for almost all 10 hours (on version 1.1.11.16)... At the same time, the system informs about the upcoming check of 65 objects, although we need a maximum of 6-8 of them. Let us stop the process in the debugger while the message “Object # 1 is being checked” hangs in the status bar and see which modules are being checked. You can see that at the first stage of verification, the system still analyzes all objects, including, for example, salary common modules that are definitely not included in our new subsystem:


But we didn’t require the system to collect data on common modules. What are the same 65 objects that the system will check?

You can get a list of them by going up the call stack to the CheckObjects () method in the "VersionCheck" document object module. From it you can also get information that ALL objects from the StructureConfiguration directory for which data were collected are selected for verification, or the system considers that the data was collected:


These objects are:

The objects themselves are less than 65, the system simply counted not only our documents, but also their details. But you can see that the root element of the hierarchy of the ConfigurationConfigurations catalog was the very first one in this list. And we have seen that it is the verification process that takes so long.

Having a list of these objects, we can draw conclusions about how the filtering mechanism works and how checks work with filters:

    Filtering works only at the stage of data collection. In the process of the check itself, filters no longer play any role. And this is logical, because the algorithms are set in the user mode. The APC only sends them for checking the elements of the StructuralConfiguration directory, if it considers that data has been collected on them.

    Despite the filters we applied for checks, the APK collects information about the modules of ALL configuration objects. The data on the modules are used by the APC when carrying out checks that are common for the entire configuration. It will be shown below what happens if you disable such checks.

    Some of the common objects will be present in the list for verification in any case, regardless of our filters. Including the top root object - the configuration itself. Again, this is necessary for "general" checks. Since the configuration included in the list is still checked according to the same rules as before, and common modules, their texts and some other data were not filtered during data collection, the longest multi-hour check of object # 1 will still be performed. It will not be possible to obtain a radical acceleration of the process from the use of filters.

    The system decided to check not only documents that satisfy both of our filters, but those that satisfy any of them. Objects that start with the prefix will also be sent for verification. apk_ and those objects that are included in the subsystem apk_Subsystem2 including document new_Document_2_3... Only a document has disappeared from the list of scanned objects new_Document_1_3 not suitable for any filter. The result will become clear if you look into the filtering function. Permissive filters work on "OR", not "AND". If this needs to be changed, then again you will have to make small changes to this method:


Now let's try to “play” with the code and see what would happen if the filtering worked not only at the stage of data collection, but also at the stage of verification. For this, let's create one more element of the Configuration directory with the same filters:


Artificially, in the code of the CheckObjects () method of the VersionCheck document, we will skip the first selection element when traversing the query result. That is, let's skip the root element of the ConfigurationConfiguration directory:


Let's perform the same check and look at the time it will take for the whole process and see if the results of the reports will differ from those obtained without skipping the root of the configuration.

In this case, it takes only 50 minutes from the start of the process to its completion instead of 10 hours:

: Created document Check version 8 from 11/01/2017 20:51:37

………………..

: Start uploading configuration to XML files

: Dumping configuration to XML files completed

………………..

: Configuration check started

: Configuration check performed

Now the report:


You can see that the root element is no longer displayed. But in addition, the report displays 9 lines instead of 10, relating to each document. Lines indicating unused export methods in document manager modules are missing. That is, some of the errors are really detected only if the root element of the ConfigurationConfigurations directory is involved in the verification process. Otherwise, the corresponding verification rules simply do not work out. These are errors, when detected, according to the logic, the relationship of the object with all other configuration objects should be checked.

Thus, if we want to drastically speed up checks when applying filters, then this must be done either by disabling the most lengthy general checks that require bypassing all modules (this can be done in the settings), or by developing our own alternative check rules.

Outcome:

    The "Automatic Configuration Testing" tool really allows, once configured, to find errors in configurations in automatic mode. APK makes it possible to find gross errors in the configuration, correct spelling, bring it into line with quite reasonable and reasonable development standards from 1C.

    APK cannot be a complete replacement for other code improvement tools, such as code reviews. It does not allow you to track down the presence of unnecessary copy-paste (code duplication), several server calls where they can be packed into one, or check for the simplest signs of a non-optimal request. But it can significantly reduce the need for visual control and become a good starting point for other tools and practices. And if necessary, write your own checks that solve more problems than those that are out of the box.

    Despite the lack of information on it, mastering this tool to start using it in practice is not difficult. Having a user manual, and now this article, can be a good start for a step-by-step guide. The configuration of the APK itself is quite simple and easy to modify, at least in terms of the interface. There really is a lot to refine. For a comfortable and efficient use, our "tanks" always need a file))

    The development of your own verification rules requires mastering the “built-in language” of the APK, more precisely built-in procedures and functions; this can be done using the user's manual and existing rules.

    Even the simplest operations requiring data collection from configurations such as ERP take over 20 minutes for the AIC. Therefore, to develop and debug your own verification rules, you should either create your own small demo configurations and demo databases, in which some modules will violate this rule, or carry out checks using previously collected data. Both techniques will help speed up the process of debugging new rules.

  • The configuration contains tools for debugging new and existing rules. To work with them, you need to deal with the APC configuration code, see how objects are created and in what context the algorithms specified in the user mode are executed. But if you wish, it seems quite possible, the approaches should be similar to those that we use in "Data Conversion".