How to develop 1C: ERP (and not only)

Hi, Habr!
In one of the previous articles it was described how the process of developing the 1C: Enterprise platform is organized. And today we want to tell you how the application solution 1C, “1C: ERP Enterprise Management 2” , is probably the most functional application solution 1C: 1C: ERP .
“1C: ERP Enterprise Management” is an innovative solution for building integrated information systems for managing the activities of multi-disciplinary enterprises, including those with technically complex multi-production, taking into account the best international and domestic automation practices of large and medium-sized businesses.
Some infographics:


More than 900 enterprises have become 1C: ERP users today (March 2016), and their number is growing. At the same time, several dozens of projects, from the point of view of developers, received the status of “pilot”, i.e. these enterprises and organizations primarily take an active part in the development of new functionality, promptly providing feedback.
Here are the logos of some 1C users: ERP:

An interesting feature of the 1C: ERP solution is that we are developing one solution - 1C: ERP - and from its sources we automatically get four solutions (by “cutting out” the functionality and switching the functional options):

1. Actually 1C: ERP. The most functional solution, ready for implementation for thousands of jobs in medium and large companies.
   Modules 1C: ERP

   
   
   
   
2. 1C: Integrated Automation . Its use will be most effective in the context of the growing business of small and medium-sized enterprises, whose management processes require close coordination and concerted actions of several executives.
   Read more

   The “Integrated Automation” configuration, edition 2.0 may be of interest to users who have experience with complex configurations on the 1C: Enterprise 7.7 platform, and users who work with separate information bases based on the Enterprise Accounting , Management of Trade , "Salary and personnel management."
   
   
   
3. 1C: Trade Management . Allows the complex to automate the tasks of operational and management accounting, analysis and planning of trade operations, thereby ensuring the effective management of modern trading enterprise.
   
4. 1C: Trade Management. Basic version . The solution for small trade enterprises allows you to keep records on behalf of one organization - a legal entity or an individual entrepreneur. Configuration changes are not supported, only typical configurations can be used and updates can be installed; only one user can work with one information base at a time, work with the 1C: Enterprise 8 server is not supported. That is, in fact, the notorious "automation of the stall."
   

If you expand your business or increase your automation needs, you can increase the functionality of the system in stages, moving from the “Trade Management” configuration to the “Integrated Automation” configuration and then to “ERP Enterprise Management 2”. Due to the high degree of unification of solutions, such a transition is performed quickly, the data accumulated in the information database is saved, and user retraining is not required - they continue to work in the usual software and information environment.

How to spell 1C: ERP

How do we make four of one solution?

Development is carried out only in one branch (ERP). The process of forming from the flagship ERP solution more “light”, functionally limited to Integrated Automation (hereinafter - KA for short) and two types of Trade Administration (hereinafter - UT and UT Basic) is automated.
Changes from ERP to “derived” configurations (KA, UT, UT Basic) are transferred automatically, using the mechanism of comparison and combination of configurations . This mechanism was originally intended to automate the process of transition to new versions of application solutions of those users who change / extend the functionality of the application solution on their side. The mechanism for comparing and merging configurations performs a three-way semantic fusion based on the analysis of three configurations:

• old vendor configuration
• new configuration from the supplier
• current user configuration (old configuration from the supplier plus changes made by the user)

At the output we get a new current configuration, which combines the new functionality (introduced by the developer) and saves the customization (modifications) made by the user.
In our case, the current configuration, in turn, is the AC, UT, UT Basic, and the old and new configurations from the supplier — the ERP of the old and the new version, respectively. Those. we believe that the functionally limited configurations - KA, UT, UT Basic - are customized (mainly by removing unused objects) versions of ERP.

One of the few objects that are written for each of the solutions manually is exchange plans that define the rules for integrating this solution with other 1C solutions (for example, with 1C: Document flow) or, for example, with external equipment. But, thanks to the gradual transition in the exchange of data to a single standard EnterpriseData , we reduce the number of exchange plans that are unique for a particular solution and try to use a single code for the exchange of data.
In this approach, there is one interesting feature. The entire solution is written once, in the ERP branch; but most of the code, forms, scripts, reports, etc. used in four solutions, and very different - ERP is implemented in enterprises with thousands of users, and UT Basic is designed to serve individual entrepreneurs. We try to pay a lot of attention to the usability of our product.
The international standard ISO 9241-11 defines usability as:

the extent to which a product can be used by certain users in a particular context of use to achieve certain goals with due efficiency, productivity and satisfaction

We try to write the application in such a way that even an inexperienced user can easily and conveniently work with it.

Design features

When developing ERP, we must always remember that the developed functionality can be used in one or several ERP-derived solutions (KA, UT, UT Basic). For easy on / off functionality, we widely use the mechanism of functional options , originally created for such tasks. Functional options allow you to select functionality in an application that can be turned on / off during implementation without changing the application itself. Functional options are solution settings, checkboxes, when turned off, all related functionality becomes inaccessible. First of all, functional options are used to fine-tune the program to the needs of a specific implementation. In ERP, we use this mechanism (in addition to its main purpose) to “cut out” ERP derived configurations. For example, in the ERP solution there is a functional option “Enterprise Management”, all the functionality that is responsible for production management is associated with it — setting up a production schedule, recording production costs, corresponding reports, and much more. This option is enabled only in the 1C: ERP solution and is disabled in the "derivative" solutions of the AC, UT, UT Basic. And just 1C: ERP uses about 600 functional options.
Another platform mechanism that facilitates the work of a 1C: ERP developer subsystem . Subsystems are a way to break the solution's functionality into blocks; each object in the solution (directory, document, report, etc.) must be included in at least one subsystem. In particular, the ERP solution instituted three subsystems that facilitate the construction of ERP-derived solutions:

1. “Objects of UE, UT, KA” are objects included in all applied solutions: Trade Management, Integrated Automation, Enterprise Management (Russian name ERP).
2. "Objects of UE, KA" - objects related only to the configurations of Integrated Automation and ERP.
3. "UE Objects" - objects related only to the ERP solution

Any application object in an ERP solution should ONLY refer to ONE of these three subsystems. This condition is verified by static analysis of the ERP solution code (see below).
')

Digits after comma

The ERP product version consists of four numbers separated by dots. For example - 2.1.3.117.

• The first number (edition) in the version changes extremely rarely (for example, the spacecraft 1... and the spacecraft 2... separates almost 8 years).
• The second number (sub-version) changes approximately once a year. In the new version version, new functionality is released. The release of such versions is often timed to the beginning of the calendar year, so that users have enough time to "move" to the new version.
• In versions with a new third number (release), existing functionality is developed; A new release comes out about once every two to three months.
• Versions with an updated fourth number (correctional builds) contain only bug fixes and updates to comply with current legislation. Come out every two weeks.

At the same time, we can have up to 3 product versions in development, for example:

1. 2.1.3.X - Supported release of the previous version. Will be issued until the end of 2016. This version is only a correction of errors and edits to comply with current legislation.
2. 2.2.1.X - The current release of the current version. It has a new sub-versioning functionality. For him, before the release of release 2.2.2.X, correctional assemblies will be released.
3. 2.2.2.X - Development of the functionality of the current sub-version. This release is actively developed.

Considering that from each branch of ERP, in addition to ERP, 3 more solutions - KA, UT and UT Basic - get 12 versions of products in 12 different repositories.
During development, we have up to 4 planning horizons, for example:

1. 2.1.3 (supported), we decide which mistakes are being corrected, which projects related to the change in legislation will be implemented. Only those changes that will take effect in 2016 will be implemented. Horizon - until the end of 2016
2. 2.2.1 (supported) - “external” errors + changes in legislation are corrected, which come into force before the release 2.2.2. Horizon - until release 2.2.2.
3. 2.2.2 (actively developed) - “external” errors are corrected + errors found by us + new functionality is implemented. Horizon - until release 2.2.3
4. 2.2.3 (planned). If the project is large, then it can be immediately developed for this version (and will not be included in the previous one). Horizon - until release 2.2.4 or until the end of 2017.

Using the product "1C: Application Solutions Design System" in the development of ERP

As already mentioned , we in 1C try to follow the principle of Eat your own dogfood , using our own products in our internal procedures. In particular, in the development of ERP, we widely use the product "1C: Design System for Applied Solutions" (abbreviated as DSS). DSS, as the name implies, helps to design application solutions on the 1C: Enterprise platform, and allows you to service the tasks of the complete software development cycle - gathering requirements, controlling changes, documenting, bug tracking, etc.
DSS allows you to create elements of two types - errors (which must be corrected) and requirements (requests for new functionality). With errors, everything is more or less clear, consider the creation of a new requirement.
The reason for creating a requirement may be:

1. Request from partner or customer. We collect such requests, in particular, at partner seminars; by voting among partners, we highlight the most priority of them.
2. A request may arise during a pilot project to introduce a new version if the client had an important wish for him.
3. A request from our technical support service (more precisely, a request from a partner or client that has passed through our technical support), a request from our partner forum or from our account manager (who accompanies an important client / clients).
4. Request from the 1C: Enterprise platform development team. The platform team asks the ERP development team (and other typical configurations) to use the new platform functionality — for example, Taxi interface , rejection of modal windows , rejection of synchronous calls, etc.
5. Refactoring, optimizing the architecture, improving usability.

The reason for refactoring (clause 5) can be serious architectural changes (for example, revision of shipment orders, when orders began to be used instead of invoices).

Product DSS comes in the ERP (but it can be bought separately). ERP solution can be launched in the mode of integration with DSS; in this case, on each form there will be a button “Open functional model”, when you click it, a description of the form functionality in the DSS will open.

This is what opens up - this is a workplace model in IDEF0 :

It is possible and vice versa - to study the functional model and open the forms of workplaces from it. This mode can be used when studying the program.
The important point is that the DPR does not open, the form opens inside the ERP where the data from the DSS is loaded. Those. seamless integration (the user does not see it). This technique is used for integration with other products. For example, from 1: Document flow (you can work without leaving ERP with mail, tasks, business processes that work in another database).

How we develop ERP: 6 project control points

So, it was decided to implement a new requirement for changing functionality. Requirements of the same type are combined into technical projects. As part of the new ERP release, typically from 100 to 150 technical projects are implemented, each project has from one to several dozen requirements. Technical project is started in the DSS; the project during the implementation passes through 6 control points, each of them is fixed in the DSS.
A little about the division into teams within the ERP unit. The team leader (team lead) participates in the design and, as a rule, participates in the development. The team also usually includes testers. Development teams are static, assigned to them in several subject areas. If the project involves adjacent areas, participants of the relevant team are involved in the project. The project may not be involved the whole team.
The person responsible for the project is the lead developer or team lead. It is his responsibility to control the processes:

• High-quality design, accounting for various scenarios, pairing with adjacent blocks
• Timing
• Quality of architecture, user interface
• Writing a certificate, design of the project, including development of a functional model

Point 1. Opening project

Tim-lead gets technical projects in the DSS list for release. In each project, the goals are signed, the requirements are implemented. The list before starting work on the release is discussed with the development manager. Actually, when the project is opened, the meetings are not held - just the project in the DSS is sent to the opening.
The project team is starting to develop a concept.

Point 2. Coordination of the concept

To agree on a concept, an online or offline meeting is held, in which the project leader, team lead, development manager, and specialists involved in the project participate. Usually, a “large-block” concept is prepared for this stage by the project manager, who is being polished during the meeting. Also discussed (and prescribed in the DSS) scenarios, description of the user interface. If the requirement was born from a request from partners or clients, the project materials (concepts, scenarios, UI) can be sent to the partner / client to evaluate the solution.
In the course of the meeting, the complexity of creating a prototype is consistent (usually creating a prototype takes up to 5 working days). The team starts to create a prototype.

Point 3. Approval of prototypes

A meeting is held, during which ready prototypes are considered, implementation details are discussed (in particular, which objects will be added and changed), hypotheses are tested, form prototypes are approved, etc. In order to test as much as possible for usability, prototypes are launched in the “hard” mode itself - in the web client, in the “Taxi” interface, on low-resolution monitors.
The functional model of the project in IDEF0 notation is developed and stored in the DSS.
At this stage, the project team should as accurately as possible assess the labor costs for the project, therefore all aspects of the project are discussed (and documented in the DSS):

• Approval of the correctness of the project description in the DSS (in particular, it is monitored that all tasks at the previous control points of the project have been completed).
• What new metadata objects (directories, documents, etc.) will be added to the solution?
• What changes will be made in already existing metadata objects
• Coordination of data exchange plans with other solutions (will new / modified data be involved in data exchange with other applications, and if so, how)

If everyone is happy with the labor costs, a presentation is held (based on the project materials from the DSS) of everything that was done on the project, in order to identify as many nuances as possible before the start of development.
And the development begins!

Point 4. Coordination of the developed solution

The solution has been developed, a presentation has been prepared (in PowerPoint format). An in-person meeting is often held with a “live” demonstration of the developed solution.
If the project is public (published in the list of plans available to partners on the 1C website), then the presentation is laid out in the partner forum in the ERP section, so that all interested partners can read and comment.

Point 5. Testing and project audit

At the end of the main development, manual functional tests are run. Testers as full-fledged members of the team participate in all control points of the project and have an understanding of the functionality of the project and work scenarios. Testers also evaluate new functionality for compliance with our usability standards. These standards (include coding standards and interface development standards) are published in an accessible resource for partners and registered users on the 1C website.
The project code is code reviewed.. Code review in ERP is carried out by members of another project team; code review is a responsibility that all ERP team developers take on in turn. If problems are found in the code, errors are recorded in the DSS, which must be corrected before passing point 5. The
update is checked for a new version from the previous one (the most recent release released at the moment).
So, the project is ready, the tests are completed, time to upload the code to the main repository (before this, all development is carried out in a separate repository of the technical project). At this stage, the writing of reference materials on new functionality also ends (the certificate is stored in the DSS).
At the end of the stage (tests passed and reference materials are ready) the project is poured into the main repository; after that, selective regression testing is carried out in adjacent areas - we must make sure that we have not broken anything of the existing functionality.

Point 6. End of the project

We close the project in the DSS - assign the status “Completed” to it.

Release Version

About a month before the release of a new release, a moratorium is imposed on pouring new projects into the main repository (development in the repositories of technical projects continues); those projects that did not have time to end by this time are transferred to another version.
During this month, regression testing is conducted; it is allowed to make changes to the code only to correct the errors introduced in this release. Unprovoked errors (those that were reproduced in previous releases), almost all were fixed by the beginning of regression testing; the same errors that remain are carried over to the next release. The main objective of regression testing is to ensure the product does not deteriorate.
As already mentioned, the same DSS is used as a bug tracker.

Correctional assembly

Every two weeks we release correctional assemblies to versions; today it is 2.1.3.x, after the release of release 2.2.1 2 corrective assemblies will be released - 2.1.3.x and 2.2.1.. From the registration of the error to its appearance in the correctional release, we have less than two weeks; Our statistics show that the average time from client's request for an error in ERP in support until the release of its correction in the correctional assembly for today is 9 days.

Branched development

In group work on ERP, we try to use the tools provided by the 1C: Enterprise platform. Configurations are stored in the configuration repository , with the checkin of new functionality in branches, the standard delivery and support mechanism is used . All operations are automated to the maximum; if the objects changed only on the developer’s side, the code is merged without the participation of the programmer. If integrating a source requires developer intervention, we usually use the built-in capabilities of the platform. But there is also the possibility of calling third-party comparison / merging tools from platform tools (for example, KDiff3 or Araxis). By the way, this feature - calling third-party comparison / merging tools - was added to the platform by the request of the ERP development team.

miscellanea

When developing new functionality, we use the version of the platform that will be available at the time of the release of the new version of ERP (today it is platform 8.3.8).
This is possible due to the fact that the platform is actively used to maintain compatibility with previous versions. As soon as a new platform appears, we are switching to it, but disconnection of the compatibility mode does not happen immediately. This is due to three reasons:

1. We want to “shock” users less, so we try to do shutdown of the compatibility mode during “quiet” periods, and not when all users, for example, submit reports.
2. . , .
3. ERP – , 10 . , .

You can write about libraries separately. A library is a specially written configuration that includes functionality that should work in the same way in our various final solutions. The integration of libraries is carried out using the already mentioned mechanism of the platform “Delivery of configurations”. Libraries are divided into published (those that we publish, and which third-party developers can use in their application solutions) and internal (which we do not publish separately - only as part of application solutions). An overwhelming number of libraries are published.
The ERP includes 10 libraries developed by other teams. Their code does not change the developers of the ERP team.

How we test 1C: ERP

After the creation of three solutions from ERP - Spacecraft, UT, UT Basic - to verify the correctness of all four solutions, we conduct a static and dynamic analysis of the resulting configurations.
Partial static analysis is carried out each time after the configuration of the spacecraft, UT, UT baseline is created from the ERP repository and poured into its own repositories (this process takes place twice a day).
A more detailed static analysis is done using the configuration of 1C: Automatic Configuration Check (1C: APK). In particular, 1C: APC checks:

• The composition of roles. For example, it is verified that the read permissions of all constants are included in the role “Basic rights”.
• Compliance with accepted standards. For a large number of application development standards (of which we have several hundred), code analysis procedures have been written for compliance. For example, that full joins are not used in queries, or that the strings that are displayed in the interface are correctly localized.
• Specific checks related to the features of ERP development.
  For example, checking that each application object is included only in one of the Subsystems UT, KA, UE, KA, UE or UE Objects

Dynamic code analysis includes, in particular, regression testing , in which the following operations are run (and the results of operations are compared with the last previous successful testing):

• Discovery of all forms
• Data exchange with other application solutions (for example, from 1C: Enterprise Accounting)
• The reflection of the documents held in the account. It is checked that after the document is held in the reference database, the result of its reflection in the account has not changed.
• And etc.

For regression testing, we use from 10 to 20 databases, of various sizes (from 15 GB to 70 GB) and different specifics of filling.
On the same bases, we are testing the update to the new version from the previous one, in order to make sure that the update passes a) correctly and b) in a reasonable time.
When updating the database 1C there are two significant steps:

1. Basic time - updating data in multi-user mode. The application solution prepares data for updating in the background, users can continue to work with the system, but the system performance can be reduced and some functions can work limitedly. Usually update to a new version is carried out on the weekend (when user activity is minimal).
2. Minimum time - update in exclusive mode. When all data is prepared in the background, it is time to change the database structure. For this, the database is translated into exclusive mode when users cannot work with the system. Update speed is extremely important for our users.

In the near future, we are expanding the auto-testing zone in order to cover the maximum number of scenarios.

Conclusion

ERP is one of our largest products. We try to use modern and advanced techniques in its development, as well as to create new techniques and tools, on the one hand, to develop it quickly, and on the other hand, to provide a high quality of the developed solution.