Lesson 4. Documents

Estimated duration of the lesson is 1 hour 30 minutes.

CONTENT:

Understanding Documents.
Forms of a Document.
Theory. Data Types. Type-Specifying Configuration Objects.
The Receipt Of Goods Document.

Adding a Document.
Attributes of the Reference Type.
Fill Value Property of a Configuration Object Attribute.
Tabular Section Fill Check.
In the 1C:Enterprise Mode.
Adding the ReceiptOfGoods Documents.

Theory. Catalogs and Documents.
Automatic Recalculation of Sum in Document Rows.

Document Form.
An Event Handler.

One Procedure for Handling Multiple Events.

Common Module.

The Services Rendered Document.
Quiz.

At this lesson we will see the Document configuration object. You will learn the purpose of this object, its structure, and its main properties.

Next we will create several documents and demonstrate how a developer can introduce their own functions to control how document works.

Additionally, you will learn how to create a document form and will familiarize with some of the 1C:Enterprise script expressions, and will learn what a type-specifying configuration object is.

Understanding Documents

The Document configuration object is designed to record information regarding the status of financial operations or the events occurring within the organization in general. Normally, every company uses such documents as delivery receipt, employment applications, remittance orders, invoices, etc. The properties and structure of these documents are defined in the Document configuration objects. These objects are used by the platform to create database tables for storage of information contained in the documents.

Logics of documents is different from logics of other configuration objects. A document can be posted. A document's ability to be posted means that the events recorded in a document have had an effect on the account.

Up until the moment when a document is posted, the status of the account does not change and the document is nothing more than a draft or a blank. As soon as a document is posted, the changes into account introduced by the document come into effect and the status of the account is changed.

As soon as a document makes changes into accounts, it is always "tied" to a specific point in time. This makes it possible to depict actual sequence of events in the database.

The next important observation, which follows from the previous two, is that the 1C:Enterprise system has a mechanism for monitoring accuracy of the accounts. Suppose that we have changed one of the previously posted documents and then reposted it "retroactively." In this situation, 1C:Enterprise is capable of monitoring whether the changes we make would have an effect on subsequently posted documents and, if so, the system is capable of re-posting the required documents.

In the process of operation a user can create new documents manually, including receipts and invoices, etc.

In a database, every document is an individual record in the main table that stores information about this type of documents (fig. 4.1).

Fig. 4.1. The standard attributes of a ReceiptOfGoods in the Designer mode,  in the 1C:Enterprise mode, and in the database

As a rule, each document contains information that defines it in further details. For example, every Receipt of goods may include information on the supplier of products, the warehouse it is delivered to, etc.

This set of information is identical for all the documents of the same type, and this set of information is defined using the attributes of the Document configuration objects that are subordinate configuration objects. A developer creates the majority of attributes manually but every Document configuration object has a set of default standard attributes. Two most important attributes are Date and Number. Since the Date data type contains dates and times with accuracy of one second, this attribute will also generally serve as the documents timestamp (fig. 4.2).

Fig. 4.2. The "Supplier" attribute of a ReceiptOfGoods document in the Designer mode, in the 1C:Enterprise mode, and in the database

Besides, every document will generally contain an array of information that is identical in structure, but varies in quantity and is intended for different documents. So, for example, each ReceiptOfGoods document can contain a list of received products.

The Document configuration object uses tabular sections to store such information. In this case the database will have additional tables where tabular sections will be stored that are subordinate to a specific document (fig. 4.3).

Fig. 4.3. Tabular section "List of Products" of a ReceiptOfGoods document  in the Designer mode, in the 1C:Enterprise mode, and in the database

Forms of a Document

Various default forms exist to visualize a document. As mentioned above, multiple names exist for the forms (table 4.1).

Table 4.1. Document Default Forms

In the context menu  and in the properties palette	In the form wizard	On the form tab
Object form	Document form	Document
List form	Document list form	List
Choice form	Document choice form	Choice

Theory. Data Types. Type-Specifying Configuration Objects

Before we begin to actually create documents, we should take a moment to talk about the data types that are available within the 1C:Enterprise system.

In the previous lesson, when we created the attributes for catalogs or tabular sections, we always specified the data type that the attribute would use. Those were the primitive data types: Number, String, Date, and Boolean. Primitive data types are predefined within the system and are limited in number.

In addition to the types that are predefined for all the configurations, we can have data types that are defined only for a specific configuration. These are the types that do not exist in a configuration permanently but only appear when some specific configuration objects are added.

For example, once we created the Warehouses Catalog configuration object, several new data types immediately appeared that were related to that catalog. Such data types included, for example, CatalogRef.Warehouses. Now, if we assign some attribute to that data type, we can use it to store a reference to a specific Warehouses catalog object.

Configuration objects that can specify new data types are referred to as type-specifying objects.

For example, once we create a new Products catalog, the following data types become available:

• CatalogManager.Products;
• CatalogRef.Products;
• CatalogObject.Products;
• CatalogSelection.Products.

Note once again that these data types are not supported by the platform initially and only exist in a specific application.

This brief discussion was required because right when we create our first document, we will have to deal with data types CatalogRef.Warehouses and CatalogRef.Products that have appeared in our configuration as a result of creating new Catalog configuration objects - Warehouses and Products.

The Receipt Of Goods Document

Now that we are familiar with the Document configuration object, we will create a few such objects in order to be able to record the events taking place within Jack of All Trades.

Among the most popular services our company provides are television repair and washing machine installation. In both cases, there is a requirement for certain materials that are expended in providing these services. Therefore, two of the critical events in the life of our company will be receipt of materials and rendering of services.

To reflect these events in the database, we will create two documents: Receipt of Goods and Services Rendered.

The Receipt of Goods document will record the delivery of the materials our company needs, while the Services Rendered document will record services provided and the expenses of materials required.

In the Designer Mode

Adding a Document

First let us open the Designer and add a new Document configuration object. On the Main tab we will enter ReceiptOfGoods as the name of the document. Based on the name the synonym will be populated automatically.

Here we will also define how the document will appear in the 1C:Enterprise interface. We will not specify Object presentation and will use object Synonym instead. This is totally suitable because the name was specified in the singular.

On the contrary List presentation will be defined in the plural - ReceiptOfGoods (fig. 4.4).

Fig. 4.4. Defining general document properties

Click Next and navigate to the Subsystems tab.

The logics of our configuration suggest that the list of receipts should be available in the sections Goods Management and Accounting. True, this document is directly related to the first section and the list of documents that demonstrates delivery of materials may frequently be needed for analysis in accounting.

So we will check these subsystems in the list (fig. 4.5).

Fig. 4.5. Defining a list of subsystems where a document will be displayed

Now navigate to the Data tab and create an attribute for the document named Warehouse. To do so, click Add over the list of document attributes (fig. 4.6).

Fig. 4.6. Creating a document attribute

Attributes of the Reference Type

Select reference data type CatalogRef.Warehouses for the attribute. This data type is available in the configuration now that we have created the Warehouses catalog configuration object (fig. 4.7).

Fill Value Property of a Configuration Object Attribute

Now we will demonstrate how we can simplify things for a user when materials are received. Operations of the company that we are now automating are so that all the products are received in the main warehouse.

So in the properties palette for the Warehouse attribute of the document that we have created locate the Fill Value property.

For a value of this property select the predefined item of the Warehouses catalog - Main.

So when a new document is created, the warehouse will have the value Main filled right away and the user will not have to do it manually (fig. 4.8).

Fig. 4.7. Creating a document attribute

Fig. 4.8. Selecting a default fill value for the Warehouse attribute

Now we will add a tabular section named Materials to this document. To do so, click Add tabular section over the list of tabular sections of the document (fig. 4.9).

Fig. 4.9. Creating a tabular section for a document

Tabular Section Fill Check

In addition to the name of the tabular section, we will select Display error for the Fill check property.

In doing so we specify that a ReceiptOfGoods document should necessary include a tabular section, i.e. the list of received materials. Otherwise an error message will be displayed and the document will not be saved.

Let us now create the attributes for the Materials tabular section. To do so, click Add attribute in the description section of tabular sections of the document (fig. 4.10):

• Material, type CatalogRef.Products;
• Quantity, type Number, length 15, 3 decimal places, non-negative;
• Price, type Number, length 15, 2 decimal places, non-negative;
• Total, type Number, length 15, 2 decimal places, non-negative.

For every attribute of the tabular section we will select Display error for the Fill check property. Hence when a document is recorded, individual attributes of the tabular section will be checked for how they are filled and not only the tabular section in general.

Fig. 4.10. Creating attributes of a document tabular section

Now navigate to the Numbering tab and make sure that Autonumbering property is enabled. This property will ensure automatic generation of unique numbers for the created documents.

Finally, we will edit the command interface so that the Goods Management subsystem has the command available to create new documents.

To do so, highlight the Subsystems branch in the configuration object tree, open its context menu and select All subsystems.

In the window that opens highlight GoodsManagement in the Subsystems list on the left.

The right-hand Command Interface list will display all the commands of the selected subsystem.

In the Action panel.New enable visibility for the command Receipt Of Goods: Create (fig. 4.11).

In the 1C:Enterprise Mode

Let us launch 1C:Enterprise in debugging mode and test the resulting document.

In the 1C:Enterprise window that opens we will see that the Receipt Of Goods command is now available on the navigation panel of the sections Accounting and Goods Management. This command opens the list of receipts (fig. 4.12).

Fig. 4.12. Goods Management section

The name of the command is determined by the List presentation property we have defined for this document.

Also the action panel of the Goods Management section now has the Receipt Of Goods command to create new documents of this type. The name of the command is determined by the synonym because for this document we have not defined any Object presentation (see fig. 4.12).

Adding the ReceiptOfGoods Documents

For now there are no ReceiptOfGoods documents in our database so we will use the ReceiptOfGoods command from the action panel of the Goods Management section and create a new receipt of goods.

We will have a document form opened - the default object form. The title of the form ReceiptOfGoods matches the document synonym.

The current date of the document creation will be populated automatically and zero time will be applied because the document has not been posted yet. Upon real-time document posting real-time timestamp is assigned to the document.

The Number field is empty but a unique number will be generated for the document because the Autonumbering property is enabled by default for the document. A new number will be saved when the document is recorded.

Note that the warehouse field is already filled with the Main value exactly as we have selected in the properties of this attribute.

Now all we have to do is populate the tabular section of the receipt of goods with the materials for television repair as shown on the figure (fig. 4.13).

Fig. 4.13. Creating a new document Receipt Of Goods No. 1

Note that when you click selection button in the Material field (in the document tabular section), a form is opened to select items from the Products catalog because this attribute has reference data type and references the Products catalog (see fig. 4.13).

Click Post and Close.

The document will be saved and posted. An automatically generated number and current time of posting will be assigned to this document.

We will follow the same steps to create a second document where we will record the materials for washing machine installation received to the Main warehouse.

But this time we will not use the selection button in the Material field and will simply start typing the name of the material into the field. The materials with their names beginning with the entered characters will be found automatically by the platform and suggested for selection.

Fig. 4.14. Creating a new document Receipt Of Goods No. 2

Click Post and Close.

The document will be saved and posted. An automatically generated number and current time of posting will be assigned to this document.

Note that when a new document is added, the entire tabular section and every column are marked by red dotted line. It means that fill check is applied to them. If you do not enter any row into the document tabular section or leave some tabular section column empty and attempt to record the document, an error message will be displayed (fig. 4.15).

Fig. 4.15. Error Message upon New Document Item Entry

In order to view the list of created documents, use the Receipts of Goods command from the navigation panel.

In the list form that opens in the application window work area we see two created documents marked with icons demonstrating that these documents have been posted (green checkmark in the document icon, fig. 4.16).

Fig. 4.16. List of Receipts of goods

Theory. Catalogs and Documents

It is interesting to note the differences in the use of singular and plural terms in referring to Catalog and Document objects.

If you open the tree of one of the standard configurations, you will see that all the objects in the Catalogs branch will generally be named in the plural. While the Documents branch normally uses the singular.

It may seem that when we create a Catalog configuration object we create a repository to store the items of this catalog, whereas when we create a Document configuration object we create some template of one specific document. That is not actually the case.

When we create a Catalog object in the Designer, we name it in the plural (Products). This action signifies that in the database this object will include items describing specific products (in the singular).

When we create a Document object we name it in the singular (Receipt Of Goods), even though we are creating the same sort of a repository as in the case of a catalog. Each record in that repository will describe one document, one receipt of goods (in the singular). Therefore, in the Designer, it would be conceptually correct to name Document objects in the plural, which would emphasize the fact that the they describe a set of documents of that type (such as Receipts Of Goods).

However, human psychology is such that, when opening the Documents branch, people expect to see them listed in the singular rather than in the plural. So we end up with a situation where it is difficult to come up with an appropriate term to describe a whole set of documents of one type (a set of records of one type is far easier - a catalog, a plan, etc.). Therefore, the corresponding configuration object branch is named Documents, while the configuration objects created in this branch are named in the singular despite of the fact that the branch actually contains descriptions of repositories for various types of documents and each item in the branch describes the set of all the documents of a certain type.

Automatic Recalculation of Sum in Document Rows

You have probably noticed that, when filling in the document, you needed to enter the total in each row. That is a nuisance and the natural impulse is to automate the document, so that the total will be automatically calculated every time there is a change to the price or quantity of materials in a row.

It is actually easily accomplished. To do so, we will first create the document form itself, and then use the features of the 1C:Enterprise script.

The thing is that up to this point, we have used the predefined object forms created automatically by 1C:Enterprise by default. Now, we have come to the point of needing to slightly modify the way a document form operates, and that means that we will need to create our own form of ReceiptOfGoods document which will allow us to define the algorithm we need with the 1C:Enterprise script. Our form will be used by the software instead of the default form.

In the Designer Mode

Document Form

Let us go back to the Designer and open the editor for ReceiptOfGoods document configuration object.

Here we need the Forms tab.

As we see, no default forms have been specified yet. To create a document form, click the open button marked with the magnifying glasses in the text box or the Add button above the list of forms (fig. 4.17).

Fig. 4.17. Creating a document form

The system then calls up yet another helpful developer tool - the form wizard (fig. 4.18).

This tool is also set up following the pattern for wizards: data are entered in a specific order and Next and Back buttons are used for navigation.

Select Document form for the form type and click Finish after you confirm all the automatic suggestions (see fig. 4.18).

Note that DocumentForm form (fig. 4.19) has appeared in the configuration object tree of the ReceiptOfGoods Document, and that the form editor is opened displaying this form (fig. 4.20).

Form editor combines multiple windows of interconnected editors. We will not discuss the actions in the form editor in detail here and will only cover the issues that are needed to fulfill the basic actions related to our task.

For details on working with the form editor, see the following documentation: "1C:Enterprise 8.2. Developer Guide", Chapter 21.1. "Development Tools" - "Form Editor."

For now we will only discuss the document form window in the view mode (located in the bottom pane) and the form controls editor window (located in the top left pane of the form editor window).

Fig. 4.19. New document form in the Designer

Fig. 4.20. Form Editor

First of all, you should realize that when you develop configuration object forms, it is impossible to simply draw a form. It is only possible to specify the controls the form will include and these controls will be arranged within the form automatically.

Form controls in the upper left window of the form editor are arranged in a hierarchical structure that suggests that the highest control in the list will be located in the highest leftmost position in the form.

This structure can be edited on the Controls tab. It allows you to manage data display and editing in a form.

You see that based on the configuration description of the ReceiptOfGoods document a controls structure has been created that defines how the form will be displayed.

These controls serve various purposes and have different behaviors. However, all of them serve to reflect information stored in the database and allow us to interact with that information.

You can drag and drop fields in the controls tree and relocate tabular section attributes, for example. The results will be immediately displayed in the document form in the bottom of the form editor. Note that you do not have to think of specific locations (in pixels) of various form controls, their sizes and locks to other controls. All of this is taken care of automatically.

But properties palette allow you to modify control properties that will influence how such controls are displayed in the form. You can also modify the structure of form controls: create a new field, a group of fields, add a tabular section, and link these controls to form data.

But for now we do not have to do any of this. We are currently concerned with three items of the tabular section: MaterialsQuantity, MaterialsPrice and MaterialsTotal (see fig. 4.20).

Every time there is a change to a value in the Quantity or Price fields, we want the Total field to be automatically set equal to Quantity*Price.

Obviously, to do so we will need to use the 1C:Enterprise script to write a command that executes something like, Total = Quantity*Price when a value in the Quantity or Price fields is changed. But how are we going to "capture" that point of change?

An Event Handler

As we have already seen, the system operates the objects described in the configuration tree independently: displays data for them, adds new items, etc. So the system has some standard understanding of how it should all operate.

But usually developers are satisfied with this standard understanding only in the very basic situations. Actual tasks are much more diverse. This is why the system has events that are connected to various moments of standard operations. These include the events related to operations of forms and controls located in the forms.

1C:Enterprise script allows a developer to squeeze in these events and define their own algorithm of the steps that should be taken when an event happens. This is exactly what we will do now.

Double-click MaterialsQuantity form control or open its properties palette (using Properties command of its context menu).

Scroll to the end of the list to see the list of events that can be linked to this field.

It is obvious that we need an event OnChange that happens when the value of the field is changed. Locate this event in the list of events and click the opening button  marked with the magnifying glass in the text box (fig. 4.21).

Fig. 4.21. Creating OnChange event handler for the Quantity tabular section field

The system will create a handler procedure template for this event in the module of our form and will open the Module tab of the form editor (fig. 4.22).

Fig. 4.22. Template of OnChange event handler for the Quantity tabular section field

The Module is the repository for the 1C:Enterprise script code. In this case it is a form module because handlers of all interactive events connected to form controls are stored in the form module.

We will now add the code as follows to the form module to the MaterialsQuantityOnChange() procedure (listing 4.1).

Listing 4.1. Procedure MaterialsQuantityOnChange()

  TabularSectionRow = Items.Materials.CurrentData;
  TabularSectionRow.Total = TabularSectionRow.Quantity * TabularSectionRow.Price;

Let us explain these lines.

The first line creates the variable TabularSectionRow where the object will be stored that contains the data located in a row of the tabular section we need to recalculate.

Soft data typing of the 1C:Enterprise script makes it possible without defining the variable and its type beforehand. We are creating the variable on the fly and its type is defined by the type of the value it contains.

Since we are located in the form module, all the properties and methods of the ManagedForm 1C:Enterprise script entity are available within this module. Hence we can call them directly. In this case after the equality sign we call a set of form controls using one of the ManagedForm equity - the Items property.

The set of form controls is a 1C:Enterprise script entity FormAllItems that contains all the form controls. This is basically a script analog of the root of the form controls tree.

Every form control may be obtained by specifying its name as the property of this object (separated by a dot). In this situation we call the tabular section of the Materials document (Items.Materials).

Tabular section of a document is a 1C:Enterprise script entity FormTable. You can get the row that is currently being edited using the CurrentData property (Items.Materials.CurrentData) of the FormTable script entity.

So when the first line of the handler procedure is executed, the TabularSectionRow variable will contain the FormDataStructure entity. This entity includes the data stored in the current row of the document tabular section (Items.Materials.CurrentData).

Once we get this entity, we can refer to the data of a specific column of the tabular section using the column name as the entity property. For example, using TabularSectionRow.Quantity allows us to get the number located in the edited row in the Quantity column.

Hence, the second line of the handler procedure calculates the value of the Total column by multiplying the values in the Quantity and Price columns.

In the 1C:Enterprise Mode

Now let us see how it works. Run 1C:Enterprise in the debugging mode, open the list of ReceiptOfGoods documents and open any of the two documents created earlier. Now if you change the number in any row of the document, the total for the row will be recalculated automatically.

One Procedure for Handling Multiple Events

So we have made sure that when a number is changed in any row of the ReceiptOfGoods document, the total in this row is recalculated automatically.

Excellent. But now we would like the Price field to behave in the similar manner. Taking a look ahead though, you will see that similar automatic calculation of Total fields might come in handy in other documents as well.

Therefore, it will be better to place the calculation of totals in some universally accessible location, so that various documents with similar attributes in their tabular sections will be able to use the function.

The Common Module configuration object is used to define these universally accessible locations, and is located in the Common 4Common Modules branch. The procedures and functions contained in these modules are accessible to all the configuration objects.

So we will create a common module and locate our procedure used to calculate totals into this module. In the document we will simply place a call to that procedure from the common module.

In the Designer Mode

Common Module

First add the Common Module configuration object.

To do so, expand the Common branch in the configuration object tree by clicking the + icon to the left of the branch name. Next highlight the Common modules branch and click Add in the command bar of the configuration window (fig. 4.23).

Name it DocumentProcessing and use its properties to select Client (managed application) and clear Server. It means that copies of this module will be compiled in the thin client context and in the web client context (fig. 4.24).

Fig. 4.23. Creating a common module in the configuration object tree

Fig. 4.24. Common module properties

Add the following code to this module (listing 4.2).

Listing 4.2. Procedure CalculateTotal()

Procedure CalculateTotal(TabularSectionRow) Export
	TabularSectionRow.Total = TabularSectionRow.Quantity * TabularSectionRow.Price; 
EndProcedure

Now we will discuss this code. The CalculateTotal() procedure receives a variable TabularSectionRow that we have defined in the OnChange event handler of the Quantity field. This variable stores the data of the edited row of the ReceiptOfGoods document tabular section.

Now using this variable we can access the data of the tabular section columns and calculate the total by multiplying the price and quantity.

The keyword Export in the procedure title is used to indicate that this procedure can be accessed from other program modules.

Now we will change the handler code in the module of our form (listing 4.3).

Listing 4.3. Procedure MaterialsQuantityOnChange()

&AtClient
Procedure MaterialsQuantityOnChange(Item)
	TabularSectionRow = Items.Materials.CurrentData;
	DocumentProcessing.CalculateTotal(TabularSectionRow);
EndProcedure

We see that the first line of the procedure remained unchanged. And in the second line instead of directly calculating the total we access the CalculateTotal() procedure from the DocumentProcessing common module and send the current row of the tabular section as a parameter.

Let us check how it works and make sure that nothing has changed.

Now we only need to implement the same handler for the Price field. Since we have already coded the required procedure in the form module, we could simply reuse it for another control's event within the form. However, the 1C Company configuration development standards do not permit that approach.

LEARN MORE!

According to the 1C Company development standards, each event must have its own handler. If identical actions are to be performed in response to changes to different controls (such as clicking several buttons), it should be handled as follows:

• a specific procedure (function) is created to perform the desired actions;
• for each control, a separate handler is created with a default name;
• the required procedure (function) is then called from within each handler.

This is why we will create OnChange event handler for the MaterialsPrice field of the tabular section same as we have done it for the MaterialsQuantity field and repeat call for the CalculateTotal procedure from the common module (listing 4.4).

Listing 4.4. Procedure MaterialsPriceOnChange()

&AtClient
Procedure MaterialsPriceOnChange(Item)
	TabularSectionRow = Items.Materials.CurrentData;
	DocumentProcessing.CalculateTotal(TabularSectionRow);
EndProcedure

In the 1C:Enterprise Mode

Run 1C:Enterprise in debugging mode and make sure that the total in the tabular section rows of Receipt Of Goods documents will recalculate in response to changes in both quantity and price.

The Services Rendered Document

Now we will use the same steps to create the second document that we will need - Services Rendered. To do so, we will follow the same procedure we used to create the Receipt Of Goods document (page 106).

In the Designer Mode

Let us create a new Document configuration object and name it ServicesRendered.

On the Main tab we will define how the document will appear in the 1C:Enterprise interface.

We will not specify Object presentation and will use object Synonym instead.

Enter Rendering Services for List presentation.

On the Subsystems tab select that the document will be available in the Rendering Services and Accounting subsystems.

On the Data tab, we will create the attributes for the document:

• Warehouse, type CatalogRef.Warehouses. Select predefined item Main of the Warehouses catalog for the Fill value property.
• Client, type CatalogRef.Clients. Select Display error for the Fill check property.
• Technician, type CatalogRef.Employees. Select Display error for the Fill check property.

Now we will create a tabular section for this document named ProductList with the following attributes:

• Product, type CatalogRef.Products;
• Quantity, type Number, length 15, 3 decimal places, non-negative;
• Price, type Number, length 15, 2 decimal places, non-negative;
• Total, type Number, length 15, 2 decimal places, non-negative.

Select Display error for the Fill check property for the entire tabular section and all its attributes.

On the Forms tab create the default document form.

For the ProductListQuantity we will create OnChange event handler that will access the CalculateTotal procedure from the DocumentProcessing common module.

This will open the form module with a template for the ProductList QuantityOnChange event handler that we will not populate for now and will navigate to the Form tab of the form controls window to create ProductListPriceOnChange event handler for the ProductListPrice in a similar manner.

Next enter the following code to the ServicesRendered document form module (listing 4.5).

Listing 4.5. Module of the ServicesRendered document form

&AtClient
Procedure ProductListQuantityOnChange(Item)
	TabularSectionRow = Items.ProductList.CurrentData;
	DocumentProcessing.CalculateTotal(TabularSectionRow);
EndProcedure

&AtClient
Procedure ProductListPriceOnChange(Item)
	TabularSectionRow = Items.ProductList.CurrentData;
	DocumentProcessing.CalculateTotal(TabularSectionRow);
EndProcedure 

Finally, we will edit the command interface so that the Rendering Services subsystem has the command available to create new documents.

This time we will use another procedure. Open the editor of the Rendering Services configuration object and click Command Interface button.

All the commands of the selected subsystem are displayed in the window that opens.

In the Action panel.New enable visibility for the command Services rendered:

Create (fig. 4.25).

Fig. 4.25. Subsystem Command Interface Setup

These actions will result in the ServicesRendered document looking as follows in the configuration object tree (fig. 4.26).

Fig. 4.26. ServicesRendered document in the configuration object tree

In the 1C:Enterprise Mode

Run 1C:Enterprise in the debugging mode.

On the action panel of the Rendering Services section click the command of creating a new document Services Rendered and populate the document as follows (fig. 4.27).

Fig. 4.27. Creating a document Services Rendered No. 1

Note that the Main warehouse is selected by default and fill check is applied to the Technician and Client fields.

Also when you enter the price and quantity in the tabular section of the Services Rendered document, the total is recalculated using our function.

Quiz

• What are the uses of the Document configuration object?
• What are the distinctive features of a document?
• What are the uses of document attributes and tabular sections?
• What default document forms are available?
• What is posting of a document?
• How does one create a Document configuration object and define its basic structure?
• How does one create a new document and populate it with data?
• How does one create one's own document form?
• What is the form wizard?
• What is the form editor?
• What is a form control?
• What is an event? What are events linked to?
• What is an event handler? How does one create an event handler?
• What is a module? What is a module used for?
• Why do we need common modules?
• What are type-specifying objects?