Developing data storage structure

In 1C:Enterprise, applications are not written with a programming language directly. Naturally, the programming language is used, but only when this is absolutely necessary (for instance, to calculate taxes or verify input data, etc.).

The entire application is described with metadata as a set of application objects from a strictly determined collection of prototypes (classes). You can refer to created objects as to "business components", and their prototypes as "patterns".

 

A prototype is used to provide applications with a collection of subjectspecific objects or processes with similar behavior and roles.

Catalogs, Documents, and Accumulation registers are examples of prototypes in 1C:Enterprise. The number of such prototypes is rather small (about two dozen). This lets you quickly master them and use them to handle any subject-specific tasks.

Defining configuration types

You already know that there are various 1C:Enterprise 8 user groups dealing with the application:

• End users work with the data whose storage structure is defined in the configuration.

• Developers determine   the    application   model          through       the configuration.

• Administrators use configuration and update files to modify the structure of the application.

In addition:

• Developers must not interrupt end users’ work and must be able to save their own work. This implies that the developers must have their own storage for intermediate configuration versions.

• Administrators must be able to upload updates to appropriate recipients, i.e., the system must be able to "understand" to which configuration the update is targeted.

Therefore, the technological platform must be able to support several types of configurations within a single application to meet the demands of various user groups:

• For end users: the configuration defining the current infobase structure and the application model for the execution mode (with scheduled modifications only).

• For developers: the configuration that stores real-time changes in the application model during the development and does not impact operations being performed by users (can be modified by a developer at any time).

• For administrators: the configuration that stores the structure of the parent configuration (if available) to support updates (can be modified only when the main configuration is updated).

To deal with these challenges while taking into account integrity, sustainability and safety requirements, the platform supports three configuration types:

• Database configuration (for end users): cannot be edited interactively and is built by the platform itself based on the main configuration. It is present at any time.

• Vendor configuration (for administrators): cannot be edited and is defined by the platform at the creation or update of the application.

• Main configuration (for developers): changes can be introduced interactively or from other configurations.

All three options are presented visually in the platform:

 

All three configurations can have different structure.

The main configuration window is used for editing the main configuration:

 

To view the configuration structure in the configuration window, upload it into Designer from the infobase by clicking Open Configuration on the Configuration menu.

 

Designer then opens the main configuration in the configuration window.

You can use Designer for development of objects stored outside the configuration (such as external data processors and reports). In this case, viewing the main configuration is not necessary.

The windows that display database and vendor configurations are only shown when the user accesses these configurations.

How to view database configuration: 

 

How to view vendor configuration: 

 

Each configuration is represented by a tree-like structure, each branch describing a specific aspect of the configuration. Configuration objects can be identified by their names in the configuration window. For example, on the following figure the Charts of characteristic types branch hosts objects of all charts of characteristic types that are present in the configuration, while AdditionalDataAndAttributes describes a single chart of characteristic types of this name.

 

In the main configuration window, you can interactively create and delete configuration objects, change their order, copy and move them, and filter them by subsystems unless the configuration window is locked, which means that making interactive (manual) modifications are disabled. The blocking can be turned on due to the following:

• The configuration is on full support.

 

• The group development feature is turned on.

 

• The configuration is used for defining the structure of a distributed infobase and therefore cannot be edited.

 

The main configuration, which can be modified, can have one of the following types:

• A fully editable configuration (without a vendor configuration): all actions are allowed.

 

• A partially supported configuration with certain restrictions on modifying it (the original objects cannot be deleted).

 

• A configuration on group development with modifications enabled (the lock is present but it is unlocked, for more information see "Chapter 7. Group Development" in part 2 of this tutorial):

 

You can use the shortcut menu of the configuration window (which is opened by right-clicking the window heading) to make the window docked, floating, or autohiding.

 

If the Dockable property of the window is turned off, the Docked and Autohide modes are unavailable.

To extend the area available for working with your objects, you can temporarily close the Configuration window. 

Closing the Configuration window does not end your session with its individual components that are open for editing: you close not the configuration, just the Configuration window.

With the Configuration window you can do the following:

• create new configuration objects; 

• edit existing configuration objects; 

• delete configuration objects with checking if there are any references to the object being deleted; 

• place configuration objects within a group in your preferred order; 

• search the configuration tree for the object whose data is being edited (in the object editing window, or form/template/module editor); 

• sort configuration objects that are subordinate to a specific configuration object by name, synonym, or comment; 

• search for references to a configuration object in other configuration objects; 

• search for references to other configuration objects in a configuration object; 

• select configuration objects according to their membership in subsystems of the configuration; 

• start wizards related to a configuration object.

To make development faster and easier, there are four ways to modify the configuration:

• by using shortcut menus;

• by using keyboard shortcuts; 

• by using the toolbar;

• by using the Actions menu of the configuration window. 

Each developer chooses the way they like most. Developers can switch from one way to another as they improve their skills. However, the perfect scenario is when a developer uses various options depending on the context (this can be compared to knowing how to perform various tasks using a mouse and using a keyboard).

First you have to determine the type of object you want to create. In the configuration tree, select the object type or any configuration object of that type.

If adding objects is allowed, the Add button is available on the Configuration window toolbar.

 

Adding objects is not allowed in the cases described earlier and also if the pointer is on the configuration name or on the Common branch.

 

In this example, neither an object type nor a configuration object is selected. Some commands are unavailable when an object type (a first-level branch) is selected: 

 

This restriction applies because no branches can be added or deleted.

When you create configuration objects that have complex structure, the platform suggests using a wizard for editing configuration object properties.

 

The wizard allows you to do the following:

• edit configuration object properties in the standard order, so that you first specify property values that you can use later in the wizard; 

• edit configuration object properties in any order by navigating directly to the desired property category; 

• edit predefined configuration object elements (if these are supported by the object); 

• open and edit object-related forms; 

• create objects that are subordinate to the object being edited (resources, attributes, dimensions, forms, templates, and so on); 

• delete subordinate configuration objects with checking if there are any references to the objects being deleted; 

• search for references to the configuration object in other configuration objects;

• search for references to other configuration objects in the current configuration object. 

• start wizards related to the configuration object.

Editable properties are organized into several tabs. Each tab contains a set of attributes for customizing the properties of a particular object type. You can switch across the tabs using the Next and Back buttons. 

Availability of certain tabs and controls on these tabs may vary depending on the configuration object type. Some objects types may have unique tabs. For example, only documents have tabs Register records, Logs, and Sequences.

The configuration object editing window displays many properties of the object, but not all of them. This is because this window is designed to help you to create objects. Viewing all of the object properties at that time would be distracting.

You can then tweak object properties using a common tool for editing both complex and simple objects, the Properties palette. You can call the Properties palette from the shortcut menu of the configuration window:

or through the Edit menu of the main Designer window.

You can create new subordinate objects as follows:

1. Select an object where you want to add a subordinate object.

2. Open the object editing window (in the Configuration window, on the Actions menu, click Change).

3. Specify the subordinate object types on the following tabs:

the Data tab contains subordinate objects of attribute and tabular section types;

the Forms tab contains subordinate objects of form type; the Templates tab contains subordinate objects of template type; the Commands tab contains subordinate objects of command type.

4. Click Add.

When the Properties palette is displayed for the configuration object being customized, the tabs display both main and additional property palettes. 

The Properties palette allows you to edit all of the properties of a configuration object. The list of properties depends on the object type.

The toolbar of the Properties palette has five buttons:

BUTTON	ACTION
	Sorts the properties alphabetically. If the properties are sorted, their categories are not displayed.
	Groups the properties by category.
	Toggles between displaying important properties only and all properties.
	Discards changes made in the property text box.
BUTTON	ACTION
	Saves changes made in the property text box

Categories of properties can be arranged into tabs or lists.

 

When properties are arranged in a list, it can be sorted by category  or alphabetically  (in the latter case category names are not displayed).

When properties are displayed on tabs, the sort buttons ( and ) become unavailable.

The More menu item opens the additional properties palette.

The Comment menu item is used to display the detailed description of the selected configuration object property in the lower part of the properties palette.

 

The Display property names menu item toggles between displaying property names and property presentations:  

 

Let us get back to the functions of the configuration editing window.

You can delete configuration objects only if they are not related to the parent configuration, i.e., the vendor configuration:

 

If object deletion is allowed and no other configuration objects contain references to this object, it is deleted.

 

If there are references to the object (which means that the object is in use), the message "Object cannot be deleted, because other objects contain links to it!" is displayed, and the message window displays the list of objects that refer to it.

 

To switch to an object that refers to the object you want to delete, doubleclick its name in the message window.

 

You can create an object by using the drag-and-drop functionality. When you drag an object (either within its branch or outside it), you create a new object. At this moment, a check is performed to determine whether the object's original properties can be used in the resulting object. If the resulting object supports these properties, they are copied. For example, attributes and templates of a catalog object are successfully copied to a document object.

If the original object contains subordinate objects (attributes, forms, templates, etc.), when you drag it to a "similar" level (for example, if you drag an object from the Currencies catalog to the Documents branch), the attributes, forms, templates, and tabular sections are copied.

You can arrange configuration objects on the configuration tree in your preferred order within their group of configuration objects. This order applies to various lists of configuration objects, too.

To move a configuration object, select it in the Configuration window and then, on the Actions menu, click Move Up or Move Down. You can also sort configuration objects by clicking Sort on the Actions menu.

To search the configuration tree for the object that is being edited, on the Edit menu of the main Designer window, click Find in Tree.

To sort similar configuration objects subordinate to a specific configuration object, right-click a subordinate configuration object and then click Sort.

 

Select a property to sort by:

• Name

• Synonym

• Comment

Select the sorting direction:

• Ascending

• Descending

Judging from their interrelationship, all configuration objects can be divided into two groups: unlinked objects (for example, the Purchase price attribute, which has Number type), and linked objects (for example, the Unit of measure attribute in the Items catalog, which is linked to the Units of measure catalog).

Sometimes it is useful to know which objects refer to a specific object, or which objects are linked to it. To do this, use the Find References to Objects and Find References in Object commands from the Actions menu of the Configuration window. In the Find References dialog box, specify the search area and click OK. If there are references, they will be listed in the message window.

The Find References in Object command on the Actions menu is useful for objects that have composite types.

To follow a reference, double-click the line with the name of the linked object in the message window.

 

 

When the main configuration is uploaded to Designer, all Configuration menu items become available:

 

As you can see, there are many actions related to the main configuration besides editing.

There is no need to open the main configuration to manage the database configuration.

 

In this case, only actions applicable to the database configuration are available:

• Open Database Configuration – view it in read-only mode.

 

• Save Database Configuration to File (for instance, before updating from the main configuration).

 

If you want to manage the vendor configuration, first load the main configuration. Then, on the Configuration menu, point to Support and click Support Options.

 

The Support options window helps you check whether a vendor configuration is available:

 

Clicking the Enable modification button makes the main configuration available for modification.

If a vendor configuration is available, you can open and view it in a separate window:

 

Configuration objects and their classification concepts

When a programmer wants to create an object representing some subject area features, the common way is choosing the best prototype and then creating a metadata object (configuration object) based on it:

 

You can set various parameters defining the behavior of a prototype-based object, make some additions to the object data structure, implement the methods that you need, define event handlers, specify display options for the object in the user interface, and so on.

By defining the object structure properly, you can enhance user experience and provide developers with better understanding of the application business logic, while reducing the number of code lines. If the right prototype for a configuration object is chosen, the platform itself provides a variety of ways to process its data without extra programming.

Let’s go through an example to see what various configuration objects are the best for.

First, look at the configuration object part that defines the data storage location and data structure. 

Inventory information is stored as some data in the database. Real goods have some properties that have to be put into the program (not all of them though) for they can help us identify products and find them rapidly in lists.

Product: ballpoint pen

PROPERTY	VALUE
Product description	Ballpoint pens
Item no.	Ð0100402

 

Product catalog

ITEM NO.	DESCRIPTION
P0100402	Ballpoint pens
L0200101	Erasers
K0100101	Pencils
L0100101	Rulers

 

The data storage structure is defined at the level of applied object model description, not at table level.

 

Then the platform automatically creates all required tables based on this description and uses them for storing the product information.

 

As you can see from the table view above, the object has some attributes that have not been defined by user. These are standard attributes.

 

The presence of some standard attributes depends on the configuration object settings, while other standard attributes are always there and are used by the system.

Standard attributes are defined at the system level; you can set their values for specific configuration elements in Designer. They can be divided into mandatory properties (for instance, Ref, Predefined, and DeletionMark for catalogs) and conditional properties (Owner, Parent, Code, and Description for catalogs).

Despite the fact that the platform stores data as tables, this data is provided to users at run time not as tables but in the way familiar to them.

For example, a user who wants to view a product catalog will see a list with available operations:

 

If you want to view product details, you can open a form with properties of the selected product and available commands for filling the properties.

 

This form has several options to output object data, for example, through printing:

 

As you may have noticed already, each configuration object has its mandatory set of properties (Name, Synonym, and Comment) both in the configuration object editing window and in the properties palette.

 

 

Name is always mandatory and must be unique.

 

It is used for creating links between objects.

 

Object names are also required to specify data processing rules. For example:

     MyGoods = Catalogs.Goods.Select();

Synonyms define the user view of applied objects at run time. For example, you can see synonyms in the All functions menu.

 

Synonyms can be set according to the particular UI languages:

 

Properties can be used for additional customization of object presentations in the command interface of managed applications:

 

The values of these properties (similarly to synonyms) can vary depending on the UI language.

 

Comment is a property of the configuration object that points to its use cases. Some examples are: 

• Comment as a short description of the purpose of an applied object.

 

• Comment as a reference to the code of an object creation request (in project implementations).

 

You can use comments not only in configuration object properties, but also in modules for documenting your algorithms:

All configuration objects are combined by their type in the configuration tree. 

Configuration objects can be divided into three major groups according to their purpose:

• Common objects: these objects define the ways of interaction between users and the 1C:Enterprise information system (command interface, selection criteria, access rights, etc.) Common objects are grouped into a separate group of the metadata tree:

 

• Applied objects: these objects represent entities from the application business area:

 

• Subordinate objects: these objects define the structure of complex configuration objects (such as applied objects),

 

and they also define the structure of some common objects:

 

You can define the structure of some configuration objects using the Type property. Such objects are known as typed objects. Among the typed objects there can be applied objects (e.g., constants):

 

and subordinate objects (e.g., catalog attributes):

 

You can choose one or several types for each value:

• Composite type – the Composite datatype check box with several types selected. 

• A type set – AnyRef type, CatalogRef type, and so on. The structure of the set is defined by the platform automatically.

 

At run time, a type set can be converted to a composite data type or any single data type.

For example, if CatalogRef is set as a type for the ManagementAccountsCurrency constant, and the configuration contains a single catalog, i.e., Currencies, the result will be as follows:

 

In this scenario, there is only one way to define an empty value.

However, as soon as you add one more catalog, the type set will be transformed into a composite type, and the empty value will be different.

 

The platform verifies whether definitions of composite data types are correct. Composite types cannot contain the following types of values:

 

If you are trying to use an invalid type as a composite one, you will see one of the two possible messages:

• When you are trying to include an invalid type in the composite type:

 

• When you are trying to include a new type in a type that contains an invalid type:

 

Configuration objects can create new types of values. 

For instance, when the Currencies catalog is created, a new type called CatalogRef.Currencies (used in the ManagementAccountsCurrency constant) appears:

 

Such configuration objects are called type-forming objects. 

If you try to delete a configuration object, the platform will check whether its data types are found in the configuration structure, and if so, it will report an error.

 

If no references to the object to be deleted are found in the configuration structure, the platform will delete the object. But before deleting the object, it will ask the developer to approve the operation, since some data types related to this object may be used in algorithms, and this cannot be checked by the platform at the development stage.

 

To avoid such problems, it is recommended that you perform a check across all modules before deleting (or renaming) a configuration object to make sure the object is not used in any of them. The most convenient way to check that is using the global text search feature: