A configuration is essentially a definition. It defines the data that users can access in 1C:Enterprise mode.
In addition, a configuration defines all of the data processing operations available. Besides, a configuration defines how the data is displayed on the screen and in printouts, and so forth. The 1C:Enterprise platform then uses this definition to create a database that has the appropriate structure and provides user access to the data.
To ensure quick and easy customization of 1C:Enterprise for specific applied solutions, all of the definitions stored within a configuration are represented as logical items named configuration objects. Perhaps you have had a chance to flip through 1C:Enterprise Developer Guide, which provides a brief definition of a configuration object.
We will not repeat that definition in this book since our task is not to present the strategies behind the 1C:Enterprise system design as metadata structures focused on business essentials, but to teach you how to use 1C:Enterprise features correctly and efficiently.
Therefore, we will explain the nature of configuration objects at the mundane level. This explanation will nonetheless allow you to understand the role of objects in the tasks that you will solve in this tutorial.
On the one hand, configuration objects are the pieces of a set of building blocks the configuration is assembled of. A set of building blocks normally comes with a certain assortment of pieces. The pieces can be different: long, short, rectangular, square, and so on. Now imagine that you can make as many of each type of pieces as you need (say, 5 long pieces and 3 short ones). You can connect the pieces to each other in various ways.
The same is true for configuration objects. You can only create configuration objects of certain types. However, you can create as many objects of each type as you need. The difference between objects of different types is that they have different properties (to be exact, different sets of properties). Objects can interact with each other and you can define these interactions.
What else makes configuration objects similar to pieces in a set of building blocks? A set of building blocks usually includes pieces that can be attached to each other, as well as other pieces, such as wheels, that cannot be attached to each other but can be connected to an axle so that the wheel will be able to rotate. In other words, different pieces of a single set behave in a different manner.
Likewise, configuration objects have different behaviors, and that behavior depends on the object type. Some objects can perform certain actions, while others cannot do so, but have their own specific set of actions.
We will explain another characteristic of configuration objects using a car as an example. A car consists of a large number of parts. An engine is one of those parts. In turn, however, an engine also consists of a set of parts, while a single part can be used in different engines.
In the same way, "complex" configuration objects consist of "simple" objects and the same "simple" objects may be used to make up "complex" objects. This structure simplifies the work with configuration objects, since, if we know how a certain "simple" object works, we will deal with it in the same manner when it is a part of a "complex" object.
And finally, the most important property of a configuration object is its practical application. Configuration objects are not merely abstract constructs the developers use to describe a task at hand. Rather, they correspond to the actual objects involved in company operations.
For example, all companies use various documents that describe the facts of business transactions. In the same manner, a configuration contains objects of the Document type.
Additionally, all companies must maintain lists of employees and catalogs of goods or services. Configurations have objects of the Catalog type, which allow developers to create digital versions of these lists.
As mentioned above, based on the configuration objects, the platform creates database tables that store data. In the documentation, as a rule, a single name is used for describing a configuration object and the corresponding set of database tables.
For example, if a configuration contains the Employees catalog object, the set of tables created by the platform based on this configuration object is also referred to as the Employees catalog.
We will stay away from that sort of "fuzzy" writing style, and whenever we are talking about the configuration, we will use the unambiguous term: the Employees catalog configuration object. In those places where we are talking about the database, we will simply refer to the Employees catalog.
Next page: Adding configuration objects
