Those of you who have experience with any SQL database might be wondering, how to create just a table using 1C: Enterprise. Well, there is no such thing in the platform. But there is a metadata class as close to as it gets, the information register. This is what we will discuss in this episode. We use information registers when no other metadata object feeds our task. Now this is the most versatile and general purpose metadata object in the platform. Here are some examples of its usage. Remember the agreements catalog with these PDF attribute having the value storage type, here is the catch. When we open an agreement, it behaves as any other object entity. It gets read from the Infobase as a whole, including the PDF file itself. The file is the file, it can be of a significant size and the platform will be reading and writing it every time it reads and writes to the catalog item. To avoid this extra overhead, we usually move any bulky stuff to the information register, let me show you. I'm deleting this attribute and creating a new information register called agreement files. Like accumulation registers, the information ones have dimensions, but they work quite differently here. Now this is what's known as a primary key in SQL databases. A set of fields whose values uniquely identify each record. In other words, you can have the only record with any specific set of dimensions values. We want this register to store a single file for each agreement, so I am creating the agreement dimension here. I don't want any orphan records in the register, so I select these two checkboxes. Now this one tells the platform to delete the register record when its parent agreement is deleted, and this one does not allow to save a record without an agreement. Together, they secure the referential integrity of the register. The PDF file itself goes here into the resources. Here we go. Now, when I open an agreement, the PDF file isn't read from the Infobase, because it's not the part of the data object anymore. The platform reads the register data only when I click here. This is where I need to implement value storage reading and writing. We use information registers to store heavyweight attributes separately from objects to optimize performance. Next example, let's say all is good and the business is thriving. I hired another cashier and now I want my shift sorted out and tidied up, so I could plan in advance who works when. This is what I did, I added a new catalog called shifts and here are tomorrow's shifts I want to assign the cashiers to. Agnes wants to work both shifts and the new cashier is ready to help her during the second one. These two tables are in so-called many-to-many relationships. Every cashier can have any number of shifts assigned to them and every shift can have any number of cashiers. Of course I don't want to duplicate the cashiers names and shifts times in another table. These tables should store the references pointing to the cashiers and shifts catalogs only. This is where the information registers come in handy again. This is the one I just created and here are our shift schedule records. Now, let me show you what it looks like in designer. This is our shift schedule information register. It has two dimensions, a shift pointing at the shifts catalog and cashier pointing at the cashiers catalog, and that's it. We also use information registers to set many-to-many relationships between objects. In the last example, I wanted to show you, started when my new cashier Danny Boy, made a few mistakes in prices while filling out sales documents. It cost me a couple of bucks, so I decided to foolproof this functionality and this is what I came up with. First, I replaced the price attribute with these two guys, unit price and line total. Now, filling up a sales document, I specify only the unit price and the quantity. The line total gets calculated automatically by the documents form right here. The items object here is a collection of form elements. This is the products list and this is its current line data. Then I just multiply one by another and that's it. This procedure is called whenever the unit price or the quantity is changed. Next thing I did was this information register I called prices. This time the register is periodical, meaning that you can have many records with the same dimensions values as long as they belong to the different periods. In other words, you can think of the period as the additional dimension added by the platform. The period attribute leaves him on the standard attributes right here as always. The periodicity comes in all sizes from a second to a year. I also created the product dimension that points to the products catalog. But this setup, I can have different prices for the same product as often as every day if I need, but the register won't let me assign the same products price several times a day. Because the set of dimensions values including period has to be unique. Now to the form part, I also implemented the price out to fill in the sales document form. This one is the function that gets the price from the register. It receives the product reference as a parameter and calls the getLast method of the register. This method looks for the last price specified for this product before the date of the document we are working with right now. This is how we pass the specific product into this method. Well, let's see where this function of ours is called from? First of all I call it whenever the product is changed. I also need to call it when the document's data changes because there might be different prices for different dates. Let me show you how this works. I am opening the prices register and pricing the Coca-Cola like this, as of the beginning of the year and as of today. These are two different Coca-Cola prices for two periods of time. From the beginning of the year to October 11th and from October 11th further on. Now, I'm creating the sales document. It's dated to the October 11th, so when I'm adding a Coca-Cola, this is the price that gets read from the register. If I change here the date to October 10th, this beginning of the year price will be taken. It looks like now I can be sure that prices are in order and completely foolproof. This was one more application for information registers. We use them to store the history of value changes and to look for the factor value at any point in time.
