Lesson 2. Subsystems
Estimated duration of the lesson is 45 minutes.
CONTENT:
- Definition of a Subsystem
Adding a Subsystem
Sections Panel of an Application
Section Order
Theory. Configuration Object Editor and Properties Palette
Quiz.
During this lesson we will learn the configuration object referred to as a Subsystem as the basis for declarative description of the 1C: Enterprise 8 interface.
We will create multiple subsystems that define logical structure of an application. We will also customize their appearance and order in the application interface.
Definition of a Subsystem
Subsystems serve as major items used to build 1C: Enterprise interface. Hence, the first thing you do when beginning to develop a configuration is designate the assortment of subsystems.
In doing so, the developer faces a crucial task: think over the assortment of subsystems carefully and then link the configuration objects that will be created to the subsystems while paying attention to all the details.
Subsystems can be avoided in simple applications but we will consider a generalist situation where subsystems are used.
The Subsystem configuration objects are intended to separate some functional parts in the configuration that are logical parts of the created application.
These objects are located in the Common object branch and allows us to create a tree-like structure that consists of subsystems and subordinate subsystems (fig. 2.1).
Fig. 2.1. Structure of subsystems in a configuration
The top-level subsystems are major interface items because they generate sections of an application (fig. 2.2).
Every configuration object may be included in one or multiple subsystems and will be displayed in such subsystems.
Looking ahead, we will mention here that subsystems combined with visibility by roles enable us to provide a user with an easy to use and feature-rich interface without any unnecessary items. For example, stock clerks need the ability to accept and issue products, but they have no need whatsoever to see anything related to accounting and service provision.
Hence, availability of subsystems determines the structure of an application, arranges the entire user interface, enables sorting of various documents, catalogs, and reports by the logically related sections where it will be easier for the user to find them and use. Note that every specific user will only see the sections (i.e. the features of the application) that this user needs for work.
Even for a small configuration like ours we can define multiple functional components that represent distinct subject areas.
So we could put everything that has to do with accounting into a separate subsystem.
Besides, payroll represents another distinct functional area.
The entire production operations of our company named Jack of All Trades can be divided into recording of materials and rendering of services.
Besides, specific administrator functions with the database make us have a separate subsystem that will only be accessible to the administrator.
Therefore, we will now create five new Subsystem objects in our configuration, which we will name as follows: Accounting, Payroll, GoodsManagement, RenderingServices, and Enterprise. To do so, proceed as follows.
Adding a Subsystem
In the Designer Mode
Let us close the application and return to the Designer. In order to create new subsystems, expand the Common branch in the configuration object tree by clicking the + icon to the left of the branch name.
Now highlight the Subsystems branch, open its context menu and select Add or click the respective button in the command bar of the configuration window (fig. 2.3).
Fig. 2.3. Adding a new subsystem to the configuration object tree
This will open the configuration object editing window.
It is designed specifically for complex configuration objects, and makes it possible to quickly create them in step-by-step procedures.
The Next and Back buttons in the lower part of the window are used to keep the steps in order. The Next button lets you set object properties
in the proper order (to avoid leaving anything out or skipping over to a location where data from one of the previous steps is needed). The Back button lets you go back several steps if you find that you have left something our or made a mistake earlier. In the future you will be able to define properties for an object by selecting the required tab immediately, e.g. the Data tab. When you open the configuration object editing window, the General tab is selected.
NOTE
To edit object properties in the development process, you may sometimes need to reopen the configuration object editing window. To do so, select the required item in the configuration object tree and click Change current item (F2) button in the command bar of the configuration window or doubleclick the selected item.
Now select the name for our subsystem as Accounting. Based on the name, the platform will automatically create the synonym Accounting (fig. 2.4).
Fig. 2.4. Defining name and synonym for a subsystem
Name and Synonym of a Configuration Object
The name is the main property of any configuration object. When creating a new object, the system automatically assigns a name.
You may use the name assigned automatically, but it is better to change it to a name that makes sense to you. The name can be whatever you like, just as long as it begins with a letter and does not contain certain special characters (such as spaces).
For readability, it is a common practice to use intuitively understandable names, and, in the case of names that consist of multiple words, to take out the spaces and begin each word with a capital letter. An object name is unique and serves to call the properties and methods of this object using 1C: Enterprise script.
Every configuration object will also have the property Synonym. It is used to store an "alternate" description of a configuration object. This description will be used by our software interface items. In other words, it is what users will see. Therefore, the synonym has almost no limitations and can be written in common human-readable form.
Subsystem Icon
In order to enhance an application interface we may also assign an icon that will be used to display the subsystem.
First, click the selection button 
in the Icon field (see fig.
2.4). In the icon selection window add the picture you want to the list on the From configuration
tab. To do so, click Add
(fig. 2.5).
Fig. 2.5. Selecting an icon to represent a subsystem
The system will create a Common picture configuration object and will open a window to edit its properties.
Name this icon Accounting. To define the picture itself, click Select from file (fig. 2.6).
Fig. 2.6. Configuration object editor for common picture
Now on the disk accompanying this book browse to the folder named Image where all the pictures are stored and specify the required image file.
To be able to preview the images, check Preview.
Highlight the file named Accounting and click Open (fig. 2.7).
Fig. 2.7. Selecting an icon to represent a subsystem
The selected picture will be displayed in the shared picture editor.
Now close the editor of the Shared picture configuration object and return to the picture selection window for the Accounting subsystem. Now you see that the list of pictures displayed on the From configuration tab contains the newly added picture. Click OK (fig. 2.8).
All of these actions result in a picture named Accounting displayed in the Shared pictures branch of the configuration object tree. We can edit this picture and use it in our configuration (fig. 2.9).
Fig. 2.8. Selecting an icon to represent a subsystem.
Fig. 2.9. Common pictures in the configuration object tree.
Now we are back to the editor of the Subsystem configuration object named Accounting. You see that the picture we selected (with the same name) is now assigned as an icon for this subsystem (fig. 2.10).
So the 1C: Enterprise interface will display the synonym of the subsystem as the section name and the selected icon will be displayed under this synonym.
If a subsystem does not have an icon, the section will still be displayed in the interface. In this case a default icon is displayed near the section name.
Now highlight the Subsystems branch again and click Add in the configuration object tree to create new subsystems named GoodsManagement and RenderingServices. Assign shared pictures Goods and Services as the icons for these subsystems (you will first need to add them from the files named Goods and Services using the same procedure we used for the Accounting subsystem).
Fig. 2.10. Selected picture is assigned as an icon for the subsystem
Now we will use another procedure to add subsystems. First open the context menu of one of the newly created subsystems. Select Add. This menu item includes two subitems. If you select Subsystem, you will be able to add a subsystem of the same hierarchy level as the one highlighted has. Selecting Subordinate Subsystem will enable you to add a subsystem that will subordinate to the one highlighted (fig. 2.11).
Fig. 2.11. Adding a new subsystem to the configuration object tree
Since we will not have a complex multi-level structure in our configuration, choose the first option and add the subsystem named Payroll. Assign an icon for this subsystem using the shared picture named Payroll (it should first be added from the file named Payroll).
Finally, add a subsystem named Enterprise that is intended to access administrator and service features.
Sections Panel of an Application
In the 1C: Enterprise Mode
Run 1C: Enterprise in the debugging mode and note the results of our modifications. The appearance of the application in development has changed (fig. 2.12).
Right under the Main menu we see the sections panel of the application where all the created subsystems are displayed. All the sections are accompanied by the icons we selected in the properties.
Sections are represented by hyperlinks. Clicking the hyperlinks enables a user to open the related documents, catalogs, reports, etc. The list of sections is currently empty as we have not created any configuration objects to populate them.
NOTE
Note that the section named Desktop is generated automatically by default. This section is intended to host the documents, reports and other items most frequently accessed by the user.
Section Order
In the Designer Mode
But we are not totally happy about the order subsystems are arranged in. Let us modify it.
Close the application and return to the Designer. Highlight the root of the configuration object tree named StartersGuide, right-click it to open and context menu and select Open configuration command interface (fig. 2.13).
Fig. 2.13. Opening setup window for configuration command interface
In the window Command Interface that opens you will see the list of created subsystems (sections of the application). Using Up and Down buttons change how sections are arranged in the list.
The first subsystems should be those that demonstrate production operations of the company: Goods Management and Rendering Services.
They should be followed by those subsystems that demonstrate accounting and payroll: Accounting and Payroll. The last one is the subsystem named Enterprise (fig. 2.14).
In the 1C: Enterprise Mode
Run 1C: Enterprise in the debugging mode and note that the order used to display the subsystems in the sections panel of the application has changed in compliance with our preferences (fig. 2.15).
Close the application and return to the Designer. During the next lesson we will begin creating our initial configuration objects, assigning them to various subsystems and demonstrate their use in the 1C: Enterprise interface.
CAUTION
When you successfully complete every lesson, it is recommended to save the configuration using AdministrationDump Infobase from the main menu. This is useful if at some point you encounter some problem and will want to revert to an already operating version. To do so, use AdministrationRestore Infobase.
Theory. Configuration Object Editor and Properties Palette
At first glance, the object editor and the properties palette seem redundant. It is the case that the properties palette reflects all of a configuration object's properties. So why create the object editor on top of that? And if the object editor exists, why do we need the properties palette, which presents the very same information in a different layout?
The configuration object editor is primarily intended for quick creation of new objects. Quick creation involves entering exhaustive information about the object. So you need to know everything about the object's structure, but that takes time. So how are we supposed to quickly create an object?
Easy enough. The object editor is based on the "masters" mechanism. Its process walks the developer through the proper sequence for entering the required data. The data entry sequence is designed so that previously entered data serves as the basis for entering subsequent data. Use Next and Back buttons for navigation. At each step, the developer is prompted to enter a group of logically related bits of information.
Now imagine that you are already comfortable with the structure of an object, or you only need to change a few object properties. So not to "replay" the whole process from the very beginning, the object editor has tabs that let you go directly to the step where you make the adjustments you are after. Hence, the object editor helps us to quickly create new configuration objects, while at the same time providing easy access to the properties we want, when editing existing objects.
But when it comes to the properties palette, it provides an absolutely irreplaceable feature. Its advantage is that its structure is not tied to any specific type of configuration object. So its contents will vary depending on the current object. By virtue of this fact, it can "remember" which property is selected, and when moving down the tree to another object, it will highlight that same property, but for the newly selected object.
This feature of the properties palette is one we could not do without when, for instance, if out of the configuration's three dozen catalogs, you need to quickly find those that are subordinate to some particular catalog. In this case, you would select the Owner property with your mouse in the properties palette of any catalog. Then go to the configuration object tree and simply scan through it using the or arrow buttons.
Quiz
- Why does one use the Subsystem configuration object?
- How does one define a configuration's logical structure using subsystem objects?
- How does one manage the order used to display subsystems in a configuration?
- What is a configuration object editor and how is it different from the properties palette?