Understanding catalogs

 


The Catalog configuration object is intended for managing data lists. All companies have lists of employees, products, customers (clients), vendors (suppliers), and so on. Configuration objects of the Catalog type define the structure and properties of those lists. The platform uses Catalog objects to create database tables that store data available in the catalogs.

A catalog consists of items. For example, an employee is an item of the Employees catalog, while a product is an item of the Products catalog, and so on. Users can add catalog items, which can include adding new employees, creating new products, or entering new customers.

In a database each catalog item is an individual record in the main table, which stores data of that catalog (fig. 3.1).


Fig. 3.1. Products catalog in Designer mode, in 1C:Enterprise mode, and in the database

Normally, each catalog item includes additional data that further defines the item. For example, all of the items in the Products catalog can contain additional information about the manufacturer, shelf life, and so on. This data set is identical for all the items in a catalog, and it is defined using the attributes of the Catalog configuration object, which are, in turn, configuration objects (fig. 3.2).

 
Fig. 3.2. Standard catalog attributes and developer-defined attributes

Since these configuration objects are logically connected to the Catalog object, they are referred to as subordinate to this object.

A developer creates the majority of attributes manually. However, each Catalog configuration object has a set of standard attributes: Code, Description, and more (see fig. 3.2). Note that the availability of standard attributes depends on the catalog properties.

For example, a hierarchical catalog has the Parent standard attribute available. If a catalog is subordinate to another configuration object, it has the Owner attribute. If you select zero for the length of the standard Code attribute, the catalog will not have this attribute available. The same is true for the Description attribute. But at least one of the two attributes (either Code or Description) should be available because otherwise the catalog makes no sense.

A catalog is stored in a database as a table, its rows store list items and columns represent attributes (either default ones or developer-defined). Hence, each table cell stores a value of a specific attribute for a certain catalog item (fig. 3.3).


Fig. 3.3. Products catalog in Designer mode, in 1C:Enterprise mode, and in the database

Catalog items can also store certain data sets that have identical structure but vary in quantity (different quantities for different catalog items).

For example, each item of the Employees catalog can include information about employee family members. For one employee that is only a spouse, while another family can include a spouse, a son, and a daughter.

You can use the tabular sections of the Catalog configuration object to store such data. These sections are configuration objects subordinate to the catalog. In this scenario the database has additional tables for storing tabular sections subordinate to a specific catalog item (fig. 3.4).


Fig. 3.4. Employees catalog in Designer mode, in 1C:Enterprise mode, and in the database

Note that the software hides the technical details related to data storage from developers: multiple catalog tables in the database, connections between tables based on a unique Ref field, specific table field types, and so on. The platform handles all of these automatically. The only thing you have to do is add a subordinate Tabular section object to the Catalog configuration object.

For user convenience, catalog items can be grouped.

For example, you can create the following groups in the Household appliances catalog: Refrigerators, TV sets, Washing machines, and so on. The Hierarchical property of the Catalog configuration object defines whether one can create groups in the catalog. A catalog item that is identified as a group is the parent for all items and groups that are included in it. This hierarchy type is referred to as folder and item hierarchy (fig. 3.5).


Fig. 3.5. Hierarchical catalog with folder and item hierarchy

Another available hierarchy type is item hierarchy. In this scenario the parent is not a group of catalog items but one of the catalog items itself. For example, you can use this hierarchy type in the Departments catalog where a single department can be the parent for several subdepartments (fig. 3.6).


Fig. 3.6. Hierarchical catalog with item hierarchy

Catalog items can be subordinate to items or groups belonging to another catalog. For example, the UnitsOfMeasure catalog can be subordinate to the Products catalog. Then you can specify a unit of measure for each item of the Products catalog.

In 1C:Enterprise this is accomplished by defining a list of owners for each Catalog configuration object. In this case the Products catalog should be the owner of the UnitsOfMeasure catalog (fig. 3.7).


Fig. 3.7. Products catalog is the owner of the UnitsOfMeasure catalog

In some scenarios a catalog must always contain certain items, regardless of user actions. For example, standard business processes in a company assume that all products are first received at the main warehouse, and then they might be shipped to other warehouses. In this scenario the Warehouses catalog must contain the Main item at all times, otherwise the receipt of goods would not be accomplished correctly. The Catalog configuration object supports defining any number of such catalog items. They are referred to as predefined catalog items (fig. 3.8).


Fig. 3.8. Warehouses catalog with the Main predefined item

Unlike regular items, predefined items are created in Designer and they can be accessed using 1C:Enterprise script. In the user interface predefined catalog items are marked with a special icon (see fig. 3.8).


Comments
0
Add comment