Plans for types of characteristics in 1C in simple words
“Plans of types of characteristics” – the phrase itself as such is already starting to break the brain a little. Yes, plans for types of characteristics are a rather complicated thing in 1C. They are complex both conceptually and technically. Here I will try as briefly as possible and to the point to state the concept of plans for types of characteristics, its technical implementation and scope.
Concept
The concept of the plan of types of characteristics solves three consecutive tasks. This is the first difficulty. The tasks, although they are related to each other, but there are exactly three of them.
First, we want to give the user the ability to add their own props somewhere. It can be a reference book or a document, but most often it is still a reference book. By adding his own attribute to the directory, the user expands the typical description of a certain entity. Everything is more or less clear here. We can say that a typical configuration (any) is intended for everyone at once and for no one in particular. A product can have a size (and sometimes many different sizes), model, grade, color… Authors text for the official website of 1C, they believe that the product may have a smell. Well… apparently yes. Be that as it may, it is impossible in a typical configuration to provide a product directory with all conceivable attributes in advance. It will become incredibly unwieldy, and it doesn’t matter if you miss something. Thinking about ways to further customize their standard solution, the developers decided to put this issue in the hands of the user. Let the user himself create the attribute he needs and indicate the type of this attribute. And we will open the opportunity for him to fill in this requisite, as well as use it in standard reports.
There are not so many possible types of this attribute: string, number, date, boolean and link. It can also be said that we have only two options: a primitive type and a reference type. At the same time, the reference type is more important for us. It is used more often. It is better to set the color not as a string: “red”, “green”, “blue”, but as a link to a reference element. Shoe size even looks like a number: 40, 41, 42… but it’s also better to set it as a link. Therefore, secondly, we need to give the user the opportunity to create their own directories. The user adds his own props, for example, color (or smell, as we are told from 1C). Most likely he will want it to be a link. And, most likely, he will want a link to the directory, which is not in the typical configuration. It is necessary to give him the opportunity to create such a directory.
Thirdly, the user may want the attribute he added to be applied not to the entire directory, but only to some part of it. For example, we sell sportswear and footwear. For shoes, we made additional props shoe size. And for clothes they made additional props clothing size. And it should be different directories! We have one product directory. But for some elements, we will fill in the props shoe sizeand for others clothing size.
Implementation
The implementation is even more difficult. The main point is that there is no one object that would be responsible for the implementation of the entire concept. If you need to add stock receipts and subtract stock write-offs, in other words, you need inventory balances, then you take an accumulation ledger. If you need to take into account the history of some indicator, for example, the exchange rate, and get the latest values, you use the information register with the option periodic. In 1C there is a special object called plan of types of characteristics. But in order to implement the concept described above, it is not enough for you to use only it. It can be said that the creation plan of types of characteristics this is the simplest in the whole scheme.
In addition to the plan of types of characteristics, you will need to create:
A directory that will store all additional references to size, color, etc. Such a mega guide. There will be everything mixed up, “boots with pies.” But the user will not see this if everything is configured correctly, namely, specify the plan of types of characteristics as the owner of this directory. In field Additional characteristic values in the plan of types of characteristics, you will then need to specify the created directory.
Register of information. It will store the actual values of additional details for a particular product. Usually there are two dimensions in this register: a reference to an object (in our case, a product) and a reference to a plan of types of characteristics. And one resource. Select the resource type from the Characteristics section. Moreover, it must correspond to the previously indicated measurement.
In the information register, you need to use two features. The first dimension should have the option Leading.
For the resource, set Selection parameter associations
This will open the transition to editing properties from the object form and the editing process itself will be correct.
And this is one of the easiest schemes! They make more complex ones. Those where the set of possible additional details depends on the type of product.
Conclusion
As I said above, all this was conceived by the developers in order to put customization issues in the hands of users. The questions were passed on, but, as practice shows, users for the most part did not take them. Very rarely I came across enthusiasts who liked to create their own props. But this is rather an exception, besides, it was quite a long time ago. Most still prefer to address such issues to specialists. And specialists have an arsenal of possible means of solving the problem, of course, more. If you need to keep records by colors, then you can add a reference book (normal, not a mega reference book) and the corresponding details to choose from: either in the product directory, or in the relevant documents and registers.
In the case when we have a product of various types, and each type has its own set of analytics, it still makes sense to think about denormalization. This is when for each product you can set a full set of analytics, and some remain empty. Sacrifice some base volume for the sake of greater simplicity in the circuit is a normal technique.
Plans of types of characteristics appeared a little earlier than the mechanism of extensions. Both solve the same task of customization. But the latter is much more general.
You cannot completely ignore the concept of a characteristic type plan. Analytical accounting in the accounting register is tied to it. In all typical configurations, plans for types of characteristics are also present in operational accounting.
But if you are designing your own solution, then using feature type plans to enable future customization is a matter that requires separate study.
In conclusion, I recommend an open lesson dedicated to EDT, which will be held at OTUS on July 12th. At it, participants will discuss the main features of EDT and learn how to develop through this environment. Joinif this topic is relevant to you.
