Reference books and documents. What is the strength of 1C

A lot of highly specialized objects or a small number of universal ones? The truth, as usual, lies in the middle. Directories and documents in 1C are an example of a successful hit in this middle. Of course, this is not about what the user sees, but about what the developer operates with. The idea “but let’s not have database tables, but directories and documents”, for all its external discreetness, is not so simple. What we’ll talk about next

Introduction

We start with the fact that some of the database tables must be supplied with a field of type date and call them documents. Another part of the tables may contain fields of the type date, and may not have. We call them guides. Both of them, like almost all decent database tables, have a unique identifier field, which is also a primary key. Developers don’t have to worry about creating these fields and keys. The 1C:Enterprise platform will do it for them. Developers can use the results of the platform and link documentation And reference books with each other in all sorts of ways. Unique identifier values ​​are generated automatically.

Reference books And documentation in 1C they call entities. Because if you delete an entry, and then create “exactly the same”, then it will not be exactly the same. It will be a different entry, with a different unique identifier. There is no deep meaning behind all this. This is just the other side of automation. Pay for the fact that developers do not have to think about the formation of key values. Besides, it’s not true at all. In 1C, you can create “exactly the same record” using standard tools directory or document. It just requires additional effort on the part of the developer.

The automation does not end with the creation of keys. A number of service fields are created for both directories and documents. Also, developers are provided with interesting tools and methods. Let’s consider them in more detail.

Reference books

In addition to a unique identifier, in 1C it is called linkV reference book the following fields can be automatically created:

  • Code

  • Name

  • Owner

  • Parent

  • This group

  • FlagRemoval

  • Predefined

  • PredefinedDataName

Some of them deserve a more detailed account.

Immediately raises questions code. Why do we need it if we already have a unique identifier? Here again we are dealing with some of the costs of automation. A unique identifier is formed according to some of its “internal” rules. In the general case, the user does not see it and, moreover, cannot change it. On the other hand, the 1C platform was created at a time when auto-completion after each entered character was not yet so common, it was believed that search by code was more important than search by name. Therefore, each directory should be provided with a certain code, but already available to the user. Since then, it has gone like this, that some directory counterparties has a built-in unique identifier for links and no less unique TIN (KPP), but for search.

In addition, in any more or less meaningful configuration, there are a large number directorieswhich don’t need any code at all. All sorts of warehouses, divisions, types of prices, etc. The 1C Enterprise platform actually allows you to get rid of unnecessary code

But here the “especially smart” is waiting for a catch

We removed the code from directoryand the platform is not quite.

This bug is twenty years old. At first I was angry with him, but now it seems that I will miss him if he is ever fixed.

two fields, parent And this group, are responsible for the hierarchy. Users love hierarchy. And for developers, this love translates into the need to resort to recursive algorithms. The 1C:Enterprise platform allows you not to think about it at all.

One “tick” and the user gets a beautiful “tree” in front of his eyes, and the developer has such methods as Belongs to Element () and Select Hierarchically ().

Separately, it is worth talking about the so-called tabular parts. tabular part is a table related to the main table directory or document many-to-one relationship. In the previous, seventh version, only document. And in the amount of strictly one piece. In the eighth version, the restriction on the number of tabular parts was removed, and at the same time it was allowed to create tabular parts for directories. The only pity is that you cannot create tabular parts for tabular parts. Such tasks, although infrequent, but still have to be solved. And at this moment comes the understanding that for all its simplicity, the concept of tabular parts really saves the developer a lot of time.

Documentation

As I said, the document, in addition to links there is a field date. This allows considering documentation as an event display tool. There are three more predefined fields:

You can add tables. But the most interesting thing about documents is that they usually have movements. Movements are entries in accumulation registers (accounting registers, calculation registersless frequently in information registers) associated with the document. In the simplest cases, there is no need to write code to generate movements (and in complex cases, there is such an opportunity!). You can use the motion builder.

Three (if you have “+”, “income”) or four clicks (if you have “-“, “expenditure”) and the platform will create a code for you

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
	//{{__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
	// Данный фрагмент построен конструктором.
	// При повторном использовании конструктора, внесенные вручную изменения будут утеряны!!!

	// регистр ОстаткиТоваров Приход
	Движения.ОстаткиТоваров.Записывать = Истина;
	Для Каждого ТекСтрокаТовары Из Товары Цикл
		Движение = Движения.ОстаткиТоваров.Добавить();
		Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
		Движение.Период = Дата;
		Движение.Товар = ТекСтрокаТовары.Товар;
		Движение.Количество = ТекСтрокаТовары.Количество;
	КонецЦикла;

	//}}__КОНСТРУКТОР_ДВИЖЕНИЙ_РЕГИСТРОВ
КонецПроцедуры

Rapid development

What is the power of splitting tables into reference books And documentationand why I call it a lucky find.

Such a simple separation, as it were, takes the hand of an inexperienced developer and leads him to the result. Do we need inventory control? Okay, what will we have documentation? Obviously, at least for starters, the arrival at the warehouse and the consumption from the warehouse. What’s in the documents? The documents refer to reference books warehouses, goods, etc. Well, the quantity, of course. And all this is done in a matter of minutes, even by those who have never seen 1C before. A few more minutes and we created a register of stock balances in the warehouse, using the movement designer, we generated code for income and expense documents. In principle, our accounting system is already ready for use. You can also create report. Also using the constructor. And just as fast as everything else. But this is a topic for a separate interesting conversation.

Conclusion

In rapidly developing and constantly changing IT, sometimes there are “long-playing” topics. A good example of this is the SQL query language. Bringing the developer to the level of abstraction guides/documents appeared in 1C a quarter of a century ago. And it works great so far. Which serves as proof of a successful find.

I also want to remind you of free webinar from OTUS, where teachers will show how the tasks of designing metadata objects of various configurations are solved to solve practical business problems.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *