After we input some data into the system, We might want to get it back in the form of a printable document. In other words, we might need a report. There are two major ways of getting reports in 1C Enterprise. Let's start with the so called template-based approach. [MUSIC] Here is a perfectly simple and very basic example of a template-based report for you. I'm going to the Sales document context menu and selecting this Print wizard. The wizard suggested creates a new command called print, which I have no objections against. Now I need to pick the reports head or attributes, which sounds like a perfect place for all the documents fields. Next, the list of the products with all the attributes except for the line number. Next, the footer, which I want to put the amount paid. The command is to go to the important group and wow, what just happened? Okay, let's see. First of all, the wizard added to the document a command called print. The command gets called from the sales document form and the current sales document reference is passed to this client side procedure. The procedure creates a new spreadsheet and passes it to the server side procedure called print along with the documents reference. The server side procedure calls the sales document print method where all the magic happens. And the spreadsheet gets filled out with a report data to be shown to user after that. As for the magic itself, here it goes. This is the main print procedure created by the wizard and this hails document manager module. And the procedure's very first line explains why this approach is called template-based. What's going on here is that we go to the sales document metadata object, read the template also called print, and assign it to this template variable. So what exactly is a template? You can think of templates as of files attached to metadata objects. It can be virtually anything, you might want leaving along with your object, including any binary file uploaded from the disk. But in our case, It's a spreadsheet document created by the wizard on looking like this. What we have here is basically a form waiting to be filled out with the data. So, let's see what we've got here and how we work with it from the source code. First off, the print procedure reads the documents data with this query, which is perfectly straightforward, except for this unusual syntax over here. Let me debug this piece of code and show you how this query works. [SOUND] so I'm opening the sales document, triggering the print command, and we're back in the designer. One little trick like this. And here is the query result with the only record inside. The record is perfectly normal and contains all boring single value document attributes, [SOUND] and this products table. You heard me right, the entire table with all the current documents products list living inside of a single field. So this is what the syntax does. Okay, next, the code reads this named areas from the template. [SOUND] this areas are just named to our groups. You can create yourself just like this. You can make a named area from whatever's on hand, row, columns, Or just a bunch of neighboring cells. And all of them will be accessible by name from your source code. Okay, now we're clearing up the report spreadsheet, just in case, initializing the Insert page break flag and entering the cycle going through all the records returned by the query. Which is not particularly wise from the wizard side. Because it knows for sure there is the only record there. But anyway, and this is where the magic starts. We'll take the first named area from the template spreadsheet, [SOUND] and copy it to the report spreadsheet. This whole affair is copied as this, with the specific row size, merged columns, typeface and font size, and whatever is written down here. The next line is just a little bit more complex. Let me show you. Whenever you write anything in a spreadsheet itself, you can set this field type property to parameter, And then assign any value to it using this fill method. The method assumes there are many parameters in the template. So you can pass an object of any type and any complexity down here. The fill method will take the first template parameter, look up the object property with the same name, [SOUND] take its value, and fill up the parameter with it, [SOUND]. The same happens with the rest of the parameters, [SOUND] after which the entire header area gets copied to the report spreadsheet [SOUND]. Okay, the rest is pretty obvious. We copy the products list header to the report, get the products list from the query results, and cycle through the list filling out the products table. Then we fill out the footer and here we go. This is our reports spreadsheet with the data from the Current sales document. This is how we build template-based reports. [MUSIC]
