In we described the procedure of 1C:Enterprise platform development. Today we would like to talk about the development of the 1C:Enterprise application with the richest functionality: 1С:ERP Enterprise Management 2.
1С:ERP is an innovative solution and an ideal basis for designing integrated information management systems for diversified enterprises, including those with technically complex multiprocessing production procedures, based on global and local best practices for medium-sized and large business automation.
Let’s take a look at the infographics:
Over 900 enterprises use 1С:ERP. Several dozens of projects received "pilot" status from our developers, which means that such companies and organizations actively participate in the development of new functionality and provide feedback in a timely manner.
The figure shows logos of some 1С:ERP users:
What's interesting about 1С:ERP is the fact that we are developing one solution (1С:ERP) and automatically get four solutions based on the ERP source code by limiting the functionality and switching functional options:
- 1С:ERP is the highest functional application. It is built implementation-ready for medium-sized and large enterprises with thousands of users.
It includes the following modules:
- 1C:Complete Automation is a perfect solution for growing SMEs with management processes requiring perfect coordination and concerted actions of several performers.
- enables comprehensive automation of operational and management accounting and sales planning and analysis. This module increases the management efficiency of modern trading companies.
- 1C:Trade Management. Base version is a solution for small trading companies. It allows keeping records of one organization: a legal entity or a sole proprietorship. The solution does not support configuration changes: you can only use and update the standard configuration; only one user at a time can work with the infobase; client/server deployments are also not supported. It is literally a kiosk automation solution.
1С:ERP Development
Making four out of one
We have only one development branch (ERP). The building of "light" applications with limited functionality (Complete Automation, or CA, and Trade Management standard and base versions, or TM and TMB) on the basis of our flagship ERP system is automated.
All ERP changes are applied to the "derived" configurations (CA, TM, and TMB) automatically with . This tool was initially developed to automate migration to new versions of applications for users who change or expand the functionality of applications on their side. Configuration comparing and merging tool performs a 3-way semantic merging based on the analysis of three configurations:
- Old vendor configuration
- New vendor configuration
- Current user configuration (old vendor configuration plus changes implemented by a user)
We consider CA, TM, and TMB as a current configuration; old and new versions of the ERP system as an old and new vendor configuration respectively. In short, we regard functionally-limited configurations (CA, TM, and TMB) as ERP configurations customized mostly by removing out-of-use objects.
For each application, we manually program the defining the rules of integration of an application with other 1C solutions (1C:Document Management, for instance) or external equipment. However, due to step by step unification of data exchange in line with EnterpriseData standard developed by 1C, the number of unique exchange plans for a single solution decreases. We are working hard to implement unified data exchange throughout all our products.
An interesting feature of this approach is to program the solution once in the ERP branch and use most of its code, forms, scenarios, reports, etc., to develop four very different solutions. Indeed, 1C:ERP solution is created for enterprises with thousands of users while Trade Management base version is designed to suit individual business-people needs. We are taking great effort to improve the usability of our products.
According to ISO 9241-11 international standard:
Usability: the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
We are creating applications that are easy and comfortable to operate even for inexperienced users.
Development specifics
Developing the ERP, we should always remember that the functionality we program may be included in one or more derivative solutions, such as CA, TM or TMB. To simplify enabling and disabling functions, we use the originally designed for this purpose. Functional options help to identify the application functions to be switched on/off at deployment without modifying the application itself. Functional options are the solution settings (usually checkboxes), which disable all the related functionality when cleared. Functional options are used in the first place to fine-tune an application considering the parameters of a particular deployment project. In addition to its main purpose, we use this tool also to create derivative configurations based on the ERP. For instance, the ERP solution contains a functional option called "Enterprise Management". The functionality related to it is responsible for production management, including production scheduling and planning, cost accounting, reporting, and more. This option is enabled only in 1С:ERP and disabled in the "derivatives" (CA, TM, and TMB). The total of 1С:ERP functional options is over 600.
Another platform tool to make 1С:ERP developer's life easier is using of subsystems. The help to divide application functionality into blocks; each application object (catalog, document, report, etc.) should be a member of at least one subsystem. For instance, the ERP contains three subsystems simplifying the development of the ERP derivatives:
- Management, and Complete Automation.
- "ERP and CA objects" are included only in the ERP and Complete Automation configurations.
- "ERP objects" are included only in the ERP solution.
Versioning
The ERP version is designated by four numerals divided by periods (2.1.3.117).
- The first numeral (revision) changes rarely. It took us eight years to change CA 1.х.х.х to CA 2.х.х.х.
- The second numeral (subrevision) changes about once a year. A release with a new subrevision number usually contains new functionality.
- Releases with a new third numeral (version) contain the extensions of existing functionality; we usually launch new versions every 2–3 months.
- Releases with an updated fourth numeral (build) contain only fixes and legislation compliance updates. We publish new builds biweekly.
- 2.1.3.X, a supported release of the previous subrevision. Scheduled updates will be available till the end of 2016. They only include fixes and legislation compliance updates.
- 2.2.1.X, a current release of the current subrevision. It contains new subrevision functionality. Scheduled updates will be available till 2.2.2.X is released.
- 2.2.2.X, a functional expansion of the current subrevision. This release is under active development.
Through the development process we have up to four planning horizons:
- 2.1.3 (supported). We decide which bugs to fix, and which legislation-related projects to implement. We apply only the changes to come into effect in 2016. The planning period lasts till the end of 2016.
- 2.2.1 (supported). We fix "external" errors and add the support of legislation changes coming into effect before release 2.2.2 is published. The planning period lasts till 2.2.2 is released.
- 2.2.2 (under active development). We fix "external" and found errors, and implement new functions. The planning period lasts till 2.2.3 is released.
- 2.2.3 (planned). Largescale projects are often developed for this version initially. We do not include such projects in the previous version. The planning period lasts till 2.2.4 is released or till the end of 2017.
As we mentioned, in 1C we are following the principle by using our own products in the internal processes. Among other things, we are exploiting 1С:Application Design System (ADS) during the ERP development. As its name indicates, ADS helps with designing 1C:Enterprise-based applications and supports the full cycle of software development, including requirement gathering, revision control, documenting, bug tracking, etc.
With ADS, we can create two types of elements: errors (to be fixed) and requirements (new functionality requests). Now that everyone knows how to deal with errors let’s consider the creation of a new requirement.
A requirement can be based on one or more of the following reasons:
- There is a request from a customer or a partner. We often gather such requests during partner workshops. We identify the requests of the highest priority by partner voting.
- There is a request arisen during a pilot project on a new version deployment as a customer has a vital demand.
- There is a request from our technical support system (or rather, a request from a partner or a customer processed by the technical support), from the partner forum or our account manager accommodating an important customer.
- There is a request from 1C:Enterprise platform development team. The platform team is asking the ERP or other standard configuration development team to use a new platform function, such as the Taxi interface, , synchronous calls block, etc.
- Refactoring, architecture optimization, improving usability.
ADS comes as a part of the ERP solution, but you can also purchase it separately. When ERP is running in ADS integration mode, each form contains a button that opens the form's functional model (the functionality description) in ADS.
The following figure shows a workstation model in notation:
Alternatively, you can open the workstation form inspecting the functional model screen. This mode is helpful in exploring the application functionality.
It is important to understand that while opening the form inside the ERP system the ADS data is loaded into that form, but you do not open the ADS itself, as the integration is seamless and not visible to a user. We are using this approach to integrate the solution with other products as well, for instance, with 1C:Document Management. A user does not have to quit ERP to work with email, tasks, and business processes stored in another database.
ERP development process: 6 project milestones
So, we’ve decided to implement a new functionality change requested. We combine similar requirements into projects. A new ERP release usually includes 100–150 projects containing anything up to several dozens of requirements. We create projects in ADS, and each project has six milestones, all documented in ADS.
Teams within the ERP division are organized as follows: there is a team lead who is involved in designing and usually in the development process. A team also usually includes testers. Development teams are rather static; each team is assigned several subject areas. If the project involves related areas, we often engage members of the associated team. In some cases, there is no need to involve the whole team.
The team lead or the leading developer is responsible for the project process control:
- High-quality design, consideration of all possible scenarios, ensuring consistency with related modules
- Deadlines
- Quality of the architecture and the user interface
- Producing of the background documentation, project finalization (including the functional model creation)
The team lead creates projects in ADS as a release list. The objectives and requirements to be implemented are described in detail for each project. The list has to be discussed with the leading developer before the work starts. We don’t have meetings at the project start, so the project is sent to launch in ADS.
The project team starts concept elaboration.
Milestone 2. Concept finalization
To approve the concept, the expert responsible for the project, the team lead, the leading developer and other project members hold an online or offline meeting. By this stage, the person responsible for the project already has a draft concept to polish during the meeting. In the meeting, the participants also discuss the user scenarios and interface and describe them in ADS. If the requirement is based on a partner or customer request, sometimes we send project materials (concepts, scenarios, UIs) to the partner or customer for review.
During the meeting, the participants also negotiate on the labor costs for prototyping which usually takes up to 5 business days. The team initiates prototyping.
Milestone 3. Prototype finalization
We hold another meeting to explore the prototypes developed, discuss implementation details (i. e. the objects to add and to change), verify hypotheses, approve form prototypes, etc. To check the usability efficiently, we launch prototypes in the "hard" mode: in a web client, in the Taxi interface, on low-resolution monitors.
The functional design model in IDEF0 notation is developed and stored in ADS.
At this stage, the project team should assess the labor efforts required to implement the project as precisely as possible. Therefore, the meeting participants discuss all aspects of the project and document them in ADS:
- Verification of project description in ADS (at this point the completion of all the goals of previous milestones must be checked).
- New metadata objects (catalogs, documents, etc.) to be added to the solution.
- Existing metadata objects to be changed.
- Finalization and approval of the plans for data exchange with other solutions (whether and how new/updated data will participate in data exchange with other applications).
And they begin developing!
Milestone 4. Finalization of the solution developed
The team completes the solution development, and the PowerPoint presentation is ready. At this stage, we often hold a live meeting to demonstrate the software features.
If the project is public (i. e. it appears on the list of planned solutions available to partners on the 1C website), we publish the presentation in the ERP section of 1C partner forum to provide the engaged partners an opportunity to review it and give us feedback.
Milestone 5. Project testing and audit
As far as the primary development process is complete, the team runs the solution through manual functional tests. As the testers are full-value team members, they take part in all project stages and have a good understanding of project functionality and usage scenarios. The testers also evaluate new functionality for compliance with our usability standards including the coding and interface development standards published on a 1C website available to partners and registered users.
The program code is subject to the . For ERP projects, code review is performed by members of another project group. All ERP developers are to carry out the code review by turn. Any code errors detected are registered in ADS and must be fixed before the milestone 5.
The testers also check the process of updating to a new version from the previous one (the last one released).
So, when the project is finalized, and the tests are passed, the team uploads the code into the main repository (during the development, the code is stored in a separate repository of that particular project). At this stage, all help materials on the new functionality should be also ready and uploaded to ADS.
At the end of this stage, when we have run all the tests and prepared the help documentation, the project is to be downloaded to the main repository. After that, we conduct random regression tests in related areas to make sure all the existing functionality still works.
Milestone 6. Project finish
The team closes the project in ADS with a status "Completed."
Version release
About a month before the new release we block downloading of any new projects to the main repository. The teams continue development in other project repositories; all uncompleted projects are migrated to the next version.
During that month, we run regression tests. At this stage, we implement only the release bug fixes. By the time of regression testing, the inherited errors reproduced in previous releases are usually fixed; the remaining errors are carried to the next release. The primary objective of regression testing is to ensure there is no quality disruption.
As we mentioned, we also use ADS as a bug tracker.
Patches
We publish patches to the released versions every two weeks. Today it's 2.1.3.x, and when 2.2.1 is released, we'll launch two more patches: 2.1.3.x and 2.2.1.х. It takes us less than two weeks to correct a registered error and to implement the fix in a patch. According to our statistics, a fix for an ERP error reported by the customer is released as part of a patch within nine days on average.
Multi-branch development
During the ERP development, we usually use the tools provided by 1C:Enterprise platform. Configurations are stored in a ; when we check in the new functionality into the branch, we use the standard . All operations are automated. If the objects were updated only on the developer's side, the code is integrated automatically. If to combine the source code we need to involve the developer, we usually use the in-built platform capabilities. It is also possible to of the platform toolkit, including or . By the way, we have added the feature of calling third-party comparison/merging tools to the platform on the request by the ERP development team.
Miscellaneous
Developing a new functionality, we are using the platform version that will be available at the time of a new ERP version release (today it is 8.3.8 ).
It is possible because the platform provides sufficient backward compatibility support. As soon as a new platform is released, we migrate but don't disable the compatibility mode immediately. This is due to three causes:
- We do not want to shock users, so we attempt to disable the compatibility mode in low periods, not when all users are busy with their reporting.
- Disabling the compatibility mode is usually related to configuration updates and planning and implementing take time.
- At present, the ERP configuration includes ten libraries. Disabling the compatibility mode is possible only when all the libraries do the same.
The ERP contains ten libraries developed by other teams. The ERP development team members do not change the library code.
The libraries include:
- Subsystems Library
Basic functionality: access rights, printing, email management, etc. It is included in most of 1C:Enterprise applications. - Regulatory Reporting Library
Creating reports for fiscal authorities, submitting electronic reports. - Peripheral Equipment Library
Drivers for various equipment: barcode scanners, fiscal printers, scales, etc. - Service Technology Library
Interaction between SaaS configurations (i. e. deployed in the cloud) and the service infrastructure. - 1C:Document Management Integration Library
Seamless integration with 1C:Document Management: end-to-end business processes, a shared task list, file and email management, etc. without leaving an ERP screen. - Payroll and HR Library (extended)
Payroll calculation, personnel records, reporting. - Online User Support Library
Update notifications, technical support calls, update download and installation. - Electronic Document Management Library
E-document exchange with contractors (including legal e-document management), DirectBank (direct document exchange with banks), and data exchange with sites (CMS). - USAIS Integration Library
Accounting for retail sales of alcoholic beverages, including an exchange with the Unified State Automated Information System. - Regulatory Accounting Library
A piece of 1С:Accounting in the ERP. Strictly speaking, the regulatory accounting in the ERP is methodologically similar to 1C:Accounting (with some minor exceptions), but it's implemented in a different and independent way. For the ERP, we took accounting reports and some tax reports from 1C:Accounting.
Once we have developed the three applications based on the ERP (CA, TM, and TMB), we need to test all four solutions, so we perform a and analysis of the configurations.
A partial static analysis is conducted every time we create CA, TM, and TMB configurations based on the ERP repository and upload them to the specific repositories (twice a day).
A more detailed static analysis is performed with 1С:Automatic Configuration Check (1С:ACC), which checks the following:
- Role composition. For example, to verify that the read-only right for each constant is included in the "Basic rights" role.
- Code compliance with the existing standards. We use code analysis procedures for many application development standards (several hundred). For example, check that full connection are not used in queries or the localization accuracy of strings displayed.
- There are also specific ERP development checks.
For example, to make sure that each applied object is included in only one subsystem: "ERP, TM, and CA objects", "ERP and CA objects", or "ERP objects".
- Opening of all the forms
- Data exchange with other applications (1C:Accounting CORP, for example)
- Generation of accounting records (check if a document still generates correct accounting records after the posting in a reference database)
- And more
We also use these bases to test the process of updating to a new version from the previous one to ensure that update is conducted а) correct and b) within a reasonable time.
The 1C database update consists of two parts:
- The part that takes the most time: data is updated in multi-user mode. The application prepares data to update in the background; users can continue working with the system, but the system performance may be reduced, and the functionality may be limited. A version update is usually performed at the weekend when user activity is minimal.
- The part that takes minimum time: update in exclusive usage mode. When all the data is prepared in the background, it's time to change the database structure. To do this, we need to switch the database to the exclusive usage mode, when users are not allowed to work with the system. The update rate is very important for our users.
Conclusion
1C:ERP is one of our major products. We do our best to use modern and advanced methodologies to develop it as well as to create new methods and tools to speed up the development process, on the one hand, and to provide high-quality solutions, on the other hand.
