Principles of design reference books in 1C Enterprise Management 2 (ERP 2.4.6)

Principles of a systematic approach to the design of the reference books of the nomenclature in 1C Enterprise Management 2 (ERP 2.4.6) or how to avoid littering.

In 1C Enterprise Management 2, a whole family of reference books is used to work with the nomenclature. These directories are part of the NSI. Properly organized approach to the NSI ensures control of the configuration and users. Therefore, working with the NSI requires a tough and, most importantly, a systematic approach; otherwise, the directories instantly turn into lists filled with garbage. In addition, well-organized reference books simplify the work with the compilation of queries and samples. In addition, systematically organized and completed directories allow you to use a mathematical apparatus to work with them (mainly the apparatus from graph theory). And, regardless of this, well-organized directories allow for the correct coding of goods.

What principles allow you to organize a systematic work with directories in 1C ERP?

Basic principles of work

First of all, this is the principle of hierarchy. Most 1C directories are designed for hierarchical content classification. This principle is most often violated when working with reference books. Hierarchical classification implies that the set of objects (directory elements) is distributed among the branches (directories) by:

1. One-type basis (in logic, this is the concept of "basis of division")
2. Only on one basis (feature)

Typical examples of violation of the principles of hierarchical classification are the selection in the “Nomenclature” directory of groups (catalogs) of the “Winter Collection” type or the notorious “Marya Stepanovna Goods”. In the case of the “Winter Collection”, within this group, the “Clothing” and “Footwear” subgroups are usually placed, but at the same time, the same subgroups are usually already in the base subgroup in another branch. Overlapping elements are obtained and the elements in the directory are duplicated. And the reason is that when organizing the branches of the catalog, the principle of uniformity of the foundation was violated - the division was made simultaneously according to the species attribute (clothes, shoes) and according to the situation (collection).

Here you can immediately say that reference guides are present in 1C ERP, which allow solving such collisions due to the fact that they were not originally designed for a hierarchical structure. The very first example is the reference book “Segments of nomenclature”. This directory allows you to collect arbitrary lists from the elements of the Nomenclature directory. At the same time, the same element of the nomenclature can be included in many lists. In particular, collections can be arranged through nomenclature segments (but it should be remembered that there is a separate “Collections” directory for collections that is convenient for collections of a seasonal look). Surprisingly, the “Segments of nomenclature” directory has a hierarchy of directories in which the principle of hierarchy must be observed.

Simplifying can be formulated: “If the directory is hierarchical, then any element of it can be included only in one branch (group, catalog)” or else “The directory structure of hierarchical directories should not allow intersection of different types of objects in one branch (group, catalog).

With this simple theoretical basis, consider the work with the reference books of the nomenclature in 1C ERP. (The truth is that although the theory is simple, in practice it is incredibly difficult to comply with its requirements due to psychological reasons, namely, the lack of motivation to strictly and uncompromisingly adhere to the rules of classification).

Directories and related objects

At first glance, the structure of the NSI of the nomenclature seems confusing, but if you collect the information from 1C piece by piece, then a certain system is formed.

Listing “Types of nomenclature”

First of all, the support of the nomenclature system of reference books is the transfer “Types of nomenclature”. There are only a few positions in it: Goods, Tara, Service, Work, Recruitment. Types of Goods and Services have several subtypes, of which particular attention should be paid to the products to be labeled and control identification signs. The “item types” enumeration is a control element of the individual 1C ERP operation algorithms and is therefore not editable by the user. Based on this listing, the user has the opportunity to organize the directory "Types of nomenclature".

Reference "Types of nomenclature"

Based on this listing, the user has the opportunity to organize the directory "Types of nomenclature". The reference book has a hierarchical system of unlimited levels and is available for filling by the user. But one should not immediately make a mistake and form from the directory “Types of nomenclature” an extensive directory structure of the directory “Nomenclature”. The types of nomenclature should be limited to the species characteristics of the nomenclature as much as possible and made minimalistic.

The sign of incorrect preparation of a “specific” reference book is the desire to insert definitions, adjectives, and indexes in the name of an item in the reference book. The reference book should be precisely that the species and adjectives are valid only if the concept has no expressiveness through one word (noun). For example: in the series “clothes”, “shoes”, “headgear”, it is permissible to introduce the element “headgear”, since one cannot easily find the equivalent equivalent to “headgear” in one word. Mark "Caps" can not be, because a hat is not a species concept, but a kind of headgear along with a “hat”. Similarly, in mechanical engineering it is permissible to designate the nomenclature type “blades”, but the definitions of “screw blades” and “turbine blades” no longer refer to the “Types of nomenclature” directory.

When initially filling in the directory of types of nomenclature, it would be logical to create the highest level of directories for activities such as: trade, production, consumption (own), assets, etc. But this is not the only way of structuring, the main thing is that groups and elements of the directory follow the principle of hierarchy, and this is possible only if we start from the most general level.
The purpose of the “Types of nomenclature” directory and the conditions when it is necessary to create a separate type of nomenclature (element) are the following:

1. It highlights the most common “species” nomenclature concepts. In particular, a separate type of nomenclature requires a nomenclature with a separate type of nomenclature (ie, each item used in the “Types of nomenclature” reference should be repeated in the “Types of nomenclature” reference book).
2. This is a classifier for physical properties.
3. The main message of creating a new species is its own, special set of characteristics of the nomenclature.
4. Also, a new view is created if you can select your own set of filters by properties, which allows you to find analogues of the nomenclature.
5. A separate type of nomenclature requires a nomenclature with its certificate.
6. A separate type of nomenclature requires a nomenclature with a separate set of product categories.
7. A separate type of nomenclature is required by the nomenclature with obligatory marking of the GISM.
8. A separate type of nomenclature is required by the nomenclature with the type “control identification sign” (CID).
9. A separate type of nomenclature require imported goods and materials.
10. A separate type of nomenclature is required by the nomenclature with general accounting parameters (for example: VAT rate).
11. A separate type of nomenclature requires nomenclature with a common set of properties.

The listed items, if they are taken into account when building the types of nomenclature, ensure the correct operation of 1C ERP algorithms, at least, as the developer (1C) described. As can be seen, if the listed criteria are met, a reference book of the types of nomenclature can be quite extensive, which should be avoided as much as possible and should not produce unnecessary entities. Accordingly, the structure of the types of nomenclature should not be copied as groups of the “Nomenclature” reference book in order to avoid redundancy.

Directory "Product Categories"

Previously, advice was given not to build the types of nomenclature on the basis of descriptive characteristics and excessive detail. But, in order to provide the necessary detailing of the nomenclature, use the “Product Categories” directory.

The purposes of this manual are as follows:

1. Continuation of detailing “Types of nomenclature”.
2. The main message of creating a product category is that the category constructs an article code for coding and bar-coding systems.
3. The category defines the essence and purpose of the goods included in it.
4. The product category serves as the basis for the distribution of the nomenclature included in it to the characteristics of the nomenclature.

Thus, product categories are a continuation of the classification of types of nomenclature. The nomenclature should fall into one commodity category, which is interchangeable for the client (buyer) or domestic consumer (production). The creation of a list of product categories is primarily determined by marketing considerations (product groups, pricing policies, warehousing, product flows, etc.), i.e. customer preferences of the item (if we are talking about production).

From the above and the fact that the directory “product categories” has a hierarchical structure, it follows that determining the list of product categories is a nontrivial task if the principle of hierarchy is to be observed. Therefore, in order to solve it, organizations should develop product categories independently only if there are experienced product managers, consultants, marketing specialists in the state, and if there are none, product categories should be based on common classifiers (TNVED, OKP, OKVED, OKDP, etc.). ).

Since several product categories can be tied to one “Type of nomenclature”, then virtually all the qualitative definitions that we wanted to include in the nomenclature type, but at the request of the principle of minimizing the types of nomenclature, they were not included in the type name, the product categories can contain descriptive essence of the nomenclature (the very "adjectives" that I wanted to insert into the name of the species). For example, the type of the nomenclature is “shoes”, then the categories can be “men's shoes”, “women's shoes”, “children's shoes”. And at the same time, it should be taken into account that one element of the “Nomenclature” reference book is included only in one product category. Thus, the nomenclature type contains a list of all product categories that can be individually assigned to an item (an item of the nomenclature directory) that has this type.

Reference "Product Categories" is very essential for the planning system in 1C ERP. It is precisely to the product categories that they are attached in the document "The distribution of sales plans by categories" of the distribution of the nomenclature by characteristics and details. This distribution is necessary if a company with a large number of nomenclature needs an initial sales plan drawn up by product categories to automatically expand to the nomenclature and its essential analytics, including the characteristics of the nomenclature. Distribution expands product categories to all items of the reference book of the nomenclature, which have a specific product category and at the same time detail to any set of details and characteristics. Here, the importance of the correct design of product categories increases in a non-linear way, because allows you to make detailed sales plans up to the nomenclature and its details / characteristics (including taking into account the distribution by seasonality, if seasonal functionality is used).

Reference "Commodity specifications"

It can be considered a special kind of product categories "product characteristics". These are the properties of the nomenclature that are important for the buyer (consumer) in quantitative terms. Thus, the following reference of the nomenclature block “Characteristics of the nomenclature” is used to describe those parameters of the nomenclature on which the system should have information on commodity balances in quantity. Product specifications can be clothing size, length of the workpiece, the qualitative composition of raw materials, etc. Quantitative residues in terms of product characteristics are the reference data for uploading to online stores, external databases, etc. Here it is important not to observe the hierarchy of the list of product characteristics, but not to include in the characteristics of those parameters that are of no interest to the consumer (buyer) in the context of quantity - in order to avoid the load on the 1C system in terms of quantity accounting.

Now consider an interesting consequence.

If we present a three-axis coordinate system, where the X axis is a type of item, the Y axis is product categories, the Z axis is a set (combination) of product characteristics, then the item list will be a kind of function of X, Y, Z. In fact, these three dimensions do not define the item itself. , and the group reference "Nomenclature". Inside each such group there will be a nomenclature, characterized by additional details and additional information. Actually, we have now formulated on what basis to create nomenclature groups in order to comply with a systematic approach. This allows you to automatically create groups of catalogs of the “Nomenclature” reference book in cases when a directory with a very large number of entries is maintained or when the directory is transferred to a new platform or is rebuilt.

In reality, the space for the “function” of the nomenclature consists of more than 3 dimensions. For example, the measurement can also make typical details, additional information and details. But this does not complicate much the auto-naming of the Nomenclature reference groups.

It should be noted that each element of the “Type of nomenclature” directory contains the constructor of the nomenclature names. The name of the nomenclature is based on the details of the nomenclature. Requisites, in particular, are the type of nomenclature, product category, certificate. Therefore, it is logical that elements with the same product category should be included in the nomenclature group. In 1C ERP of the standard functionality there is no automatic name for the groups themselves in the “Nomenclature” reference book, so it should be developed if necessary.

Based on my experience with 1C ERP, I can make this conclusion: Reference books of the nomenclature description of 1C ERP are designed in such a way that not the “Nomenclature” reference book becomes more important, but the triad of reference books “Type of nomenclature”, “Product categories”, “Nomenclature characteristics”. If this triad is designed correctly, then the Nomenclature reference book, including its groups, will be de facto designed.

Additional details and information

Let us make some digression from the description of the nomenclature directories for the description of additional details and information. Additional requisites are used to maintain lists of product attributes that are not found in standard reference books, listings, and similar objects. When creating additional requisites, you should always observe the principle of non-multiplication of entities and carefully check whether there is a typical object for storing the desired information. Duplication of similar in purpose objects will inevitably lead to user confusion and accumulation of garbage.

Additional information is similar to the purpose and functionality of additional requisites, but 1C recommends that the information should reflect attributes related not to the nomenclature itself, but to the links of the nomenclature with external sources or with access control to the nomenclature. For example, to store encoding for exchanging data, codes in external databases, etc. In other words, additional information is used in exceptional cases, while additional details must be inseparably connected with the nomenclature.

Also, the Quality props are somewhat isolated. Its purpose is very limited - they are given a new or used nomenclature, degree of wear. But such an approach means duplicating the same nomenclature in the directory, which makes it difficult to select and distinguish similar elements of the directory. In fact, there is a multiplication of entities, since quality and its degrees are situational states. The purpose of the organization is not the production of low-quality goods or the purchase of low-quality raw materials for the launch of production. Therefore, to simplify the design of the “Nomenclature” directory and its contents, it may be more correct to not use the “quality” requisite, but to separate accounting-separators with different quality (accounting data, sub-accounts, storage cells, nomenclature segments, etc.) and / or labeling. For trade organizations where goods of different quality can be the same trade object, this advice is less relevant. But for manufacturing enterprises where goods (products) or materials of reduced quality serve as raw materials for production, it makes sense to select even a separate type of nomenclature for such re-raw materials and make a transfer from the sales / output nomenclature to the raw materials nomenclature (for example, de-assembly).

In the framework of the deviation from the consideration of the actual reference books of the nomenclature series, we also consider the functional “Filter by properties” of the reference books “Type of nomenclature” and “Nomenclature”. Filter by properties is set in the form of a nomenclature as a list of details and additional information. For these properties, in the “Nomenclature” reference book, the elements of the nomenclature that are similar in purpose and essence are selected. Since for the user this functionality looks like a dynamic selection in the form of a nomenclature reference book when selecting the Nomenclature with similar properties link in the Nomenclature reference item, it is important only for quickly finding a similar nomenclature in the lists. But if you organize the storage of the results of such selections and thoughtfully compile lists of selection properties, you can get a functionality similar to the typical “Nomenclature sold together” functionality. For example, manufacturing plants for the nomenclature of production can organize a dynamic selection of analogues of the nomenclature allowed for replacement in the production process.

Functionality "Nomenclature sold together"

The “Nomenclature sold together” functionality itself is an algorithm for searching the implementation documents and storing the selection results in the corresponding register, by the item pairs that are encountered, with the user-defined frequency of meetings within one wholesale / retail sales document. Register filling is possible both automatically by the algorithm and manually by direct indication of item pairs. The selection of pairs is carried out taking into account the characteristics of the nomenclature and setting up the search for associations in the NSI. Due to the fact that this functionality is poorly managed by the user, it has a more evaluative and auxiliary character for marketing purposes. The purpose of this functionality is to give a hint to the manager when drawing up rebounds in the sales documents which other goods can be offered to the client in addition to the order. This shows that if the sales of an organization are formed in separate billing systems or in online stores, then the described functionality is of little use.

Reference "Manufacturers"

Returning to the directories consider the directory "Manufacturers". He imagines the repository of the list of values ​​selected in the requisite of the “Manufacturer” nomenclature. These values ​​are merely text and are not related to the Counterparty directory. It cannot be said that this is a very thoughtful decision on the part of 1C, because it leads to duplication of the directory “Counterparties” and those who need to specify the manufacturer in the nomenclature exactly, until the legal entity will have to do this instruction in one more additional requisite. Therefore, using the “Manufacturers” guide is not for listing manufacturers-legal entities, but for dividing them into “types” of producers. For example, it is necessary to select the group “Our production” and indicate our production centers, and external manufacturers to single out “third-party manufacturers” or “foreign manufacturer” as one element. It makes no sense to mention the brand in the manufacturer's name, since the nomenclature has a separate props "Brand". The proposed filling of the “Producers” reference book allows to simplify the reference books “Type of nomenclature” and the “Nomenclature” reference group, since they do not need to be split under the manufacturer, but it increases the number of items in the “Nomenclature” directory, since For each "type" of the manufacturer, a separate element of the nomenclature is established. The proposed approach will be useful for organizations that sell or produce a product known to the consumer as an object that is produced by various organizations, in particular, who have purchased a license for the production of a certain brand, etc.

Directory "Nomenclature of Suppliers"

The “Supplier’s Nomenclature” functionality, which includes the Supplier Nomenclature Directory, has something in common with the “Manufacturers” directory. This functionality is tied to the "Partners" directory and, when enabled, the corresponding settings in the "NSI" section, compare the elements of the "Nomenclature" directory to a separate directory that stores the names of the supplier nomenclature. This is a very important and significant functionality, the value of which is difficult to overestimate.

First of all, it is important for the optimal design of its own directory of the nomenclature, regardless of the quality of approaches to the design of the nomenclature on the side of suppliers.

Secondly, it is important to design the nomenclature of our own production and design specifications, because the organization gets the opportunity to build its “Nomenclature” directory for raw materials, materials and semi-finished products, regardless of the suppliers pool that is currently in place, or from changes in the pool and in the nomenclature suppliers in the future. From here it becomes possible to more easily control production costs, incl. by reducing the number and complexity of service specifications. In other words, manufacturers and those selling goods of the same brand, received from different suppliers / manufacturers, the described functionality should be used without fail. Otherwise - a crime!

The supplier nomenclature reference book is hierarchical and allows you to structure the supplier nomenclature according to the groupings of its nomenclature or to independent suppliers groupings. But here it is not necessary to unnecessarily complicate the classification of the supplier nomenclature, since nomenclatures are linked once in pairs in the functionality of the “supplier nomenclature” itself or directly in the goods receipt documents, in which the grouping is of no particular importance. In companies with a large flow of nomenclature, it makes sense to prohibit linking of the nomenclature in documents of receipt of goods and materials to employees of the “operator” level working with primary documents, since the binding requires much higher qualification and must be carried out by an individual specialist (commodity specialist, engineer, etc.) in the functional "Supplier nomenclature" in the period of conclusion of the transaction (contract). In addition, bundles of nomenclatures must be quickly verified for relevance when processing new modifications of suppliers' price lists, prior to delivery. The functionality of the “nomenclature of suppliers” is used in the 1C ERP planning system with the automatic creation of procurement plans and procurement plans from sales plans for purchased goods from production plans (material requirements).

It should also be noted that the supplier prices are tied to the supplier’s nomenclature, which is also relevant when planning procurement plans, especially in industries with a unique release (shipbuilding, luxury furniture manufacturing, interior decoration and facilities), although there is no user-controlled algorithm in the standard 1C selection at supplier prices when planning.

Reference "Price groups"

The reference book “Price Groups” is intended to maintain a list of features, according to which a nomenclature is selected with the same pricing methods. The directory does not have a hierarchical structure by default, so the approach to its content should be minimalist. A price group is assigned if it is possible to set a special calculation formula for it (in reference books “Types of prices” or “Discounts”). But, since the two mentioned reference books have independent means of selecting the nomenclature, it can be said that the role of the “Price Groups” reference book is primitive - just the convenience of selection when assigning pricing / discount formulas. If during creation all elements of the nomenclature are linked with price groups, then the ease of selection on this basis is guaranteed.

Reference "Seasonal groups of nomenclature"

The “Seasonal nomenclature groups” directory is a reference to the planning system and is also a simple repository of lists that help to divide the nomenclature into groups with the same seasonality. For each created seasonal group, the distribution coefficients by months of the year are stored in the Seasonal Ratios register (not by year / planning period !!! And by months of the calendar year). The handbook is useful if the planning is based on the initial creation of a sales plan for the period (year) as a whole by product categories, and then the Sales Plan is automatically created according to the nomenclature taking into account seasonality and product characteristics.But, if sales planning is initially based on a monthly or more fractional sales plan, then the seasonality reference book is not needed, since seasonality will already be taken into account in the turnover of each month (week).

Reference "Policy accounting series"

Reference book "Policy accounting series" is used to bind to the type of nomenclature of rules for working with a series of nomenclature and expiration dates. Policies for accounting of series can be divided into “light” (not requiring accounting of residuals or cost in terms of series / shelf life) and “heavy” (requiring consideration of residues or cost of production in terms of series / shelf life). Marking of goods and the use of control identification marks (CIZ) 1C suggests to use the specially marked light version of the “Product labeling for GISM” policy type. “Heavy” accounting should be avoided if possible, i.e. to use it reasonably, due to the fact that serial accounting involves an extremely high load on system performance, especially the variant with the “Cost accounting by series” policy type.In this case, there is an avalanche-like increase in the number of calculations, processor operations and the number of rows in the tabular parts of the documents of the movement of inventories. The reference of the accounting policies of the series by default is not hierarchical, so that sensible minimalism is recommended when designing its elements. Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying the GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / expiry dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.processor operations and the number of rows in the tabular parts of the documents of the movement of inventories. The reference of the accounting policies of the series by default is not hierarchical, so that sensible minimalism is recommended when designing its elements. Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying the GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / expiry dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.processor operations and the number of rows in the tabular parts of the documents of the movement of inventories. The reference of the accounting policies of the series by default is not hierarchical, so that sensible minimalism is recommended when designing its elements. Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying the GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / expiry dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.The reference of the accounting policies of the series by default is not hierarchical, so that sensible minimalism is recommended when designing its elements. Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying the GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / expiry dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.The reference book of accounting policies for series by default is not hierarchical, so common minimalism is recommended when designing its elements. Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / validity dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying the GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / expiry dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.Since the policies of accounting series are attached to the type of item, they apply to all elements of the item with a given type. Serial accounting should be entered only in cases when each unit of production has unique differences or when applying GISM marking or its own piece-by-piece identification of units of production (for example, RFID tags) or when the values ​​have release / validity dates. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.RFID tags) or when values ​​have a release / validity date. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.RFID tags) or when values ​​have a release / validity date. In other cases, the use of series with a high probability is an abuse of the capabilities of 1C ERP and common sense.

Справочник «Группы доступа номенклатуры»

Separately, it is worth mentioning the reference book “Access groups of the nomenclature”, which is a simple list of access types that are described in the access profiles. It should be remembered that the separation of access leads to a slowdown of the system, so this directory is generally not worth using. But it will be very useful if it is necessary to remove from the eyes of the users of the operational unit the elements of the nomenclature transferred to the archive, taken out of use. Usually, a method of entering separate catalog groups is used for the archival nomenclature in the “Nomenclature” reference book, but this leads to a duplication of the nomenclature and complication of selections when sampling data for past periods. But if you create a special access group “Archive of the nomenclature”, then the outdated nomenclature will simply disappear from the field of view of those users whom it only hinders in work.You can also create a separate access group for the new projected nomenclature, the principle of visibility is the same. This method allows, without violating the systematic approach to the design of the types of nomenclature and the nomenclature reference book, to withdraw from the turnover and put into circulation the corresponding positions, keeping or immediately placing them in the necessary groups of the catalog.

The directories "Collections", "Ratings of sales of nomenclature", "Assortment quotas" are highly specific and intended for retail trade of consumer goods, therefore we will not consider them in this article.

Summary

1. To design the “Nomenclature” reference book in 1C ERP, it is necessary and sufficient to design reference books “Types of nomenclature”, “Product categories”, “Nomenclature characteristics”.
2. One should strictly follow the principle of strict hierarchy of classification described in the article for a systematic approach to the design of the contents of reference books and the application of the mathematical apparatus to them.