1C:Enterprise 8, Introduction

1. Introduction

The aim of the course is to give students a basic idea of how to work with the main objects and mechanisms of the platform, give them skills for working in the system by solving the so-called "end-to-end" example. The main focus in the course is on preparing the students to work alone.

Besides mastering the material, students must study the documentation that comes with the standard package, namely:

• 1C:Enterprise 8. User’s manual

• 1C:Enterprise 8. Configuration and administration

• 1C:Enterprise 8. Description of the script language.

These books are essential insofar as the present handbook does not replace, but merely supplements the program documentation with more specific examples and practical exercises.

This book consists of separate chapters. Each chapter covers a separate topic using specific examples. In the examples, we explain the relevant procedures step-bystep to help the student to master the material in the chapter.

2. General provisions

2.1. The task

Suppose you are tasked with automating the operations of a wholesaler/retailer.

The company consists of two departments: administration and sales, and the latter is divided into wholesale and retail sales.

You must keep a list of employees as part of the company’s personnel records. You must be able to provide information about the qualifications of each employee (where and when he or she studied), as well as information about his or her children (Fig. 2.1). When the salary is set or changed, or when the employee is transferred to a different location, record this in the Personnel Order document

Fig. 2.1.

The company's primary business is the purchase and subsequent sale of goods and provision of related services. You must keep a list of goods, services, suppliers and customers. All settlements with contacts are under contracts.

When you pay a supplier for goods, record this action as a Cash Outflow. When you receive the goods, record this action in a Purchase Invoice.

Make sure you are able not only to pay suppliers, but employees of the company as well.

When you send goods to a buyer, record this action as a Goods Issue (Fig. 2.2). When you receive the payment for it, record it as a Cash Inflow (Fig.2.3). Make sure you are able to print out Goods Issues satisfactorily.

Fig. 2.2.

Fig. 2.3.

When selling goods, the company may need to keep foreign currency records. You should be able to turn this function on and off.

To analyze the company's operations, you must be able to find out the sales figures for each business unit in the current month. 2.4).

Fig. 2.4.

2.2. Creating a new database

The 1C:Enterprise 8.2 software suite includes a platform and applied solutions developed on top of it to automate the activities of organizations and individuals. The platform itself is not a software product for end users who work with the applied solution (configuration) developed on this platform. Accordingly, the system has two modes of operation: 1C:Enterprise (user mode) and Designer (intended for developers of applied solutions and database administrators). We will start in design mode, since this is where existing configurations are modified and new ones are created.

The first thing we need to do to complete the task at hand is to create a new database. On the C:disk, create a directory called Introduction 8.2, then launch 1C:Enterprise 8.2

The 1C:Enterprise Startup dialogue box appears (Fig.2.5).

Fig. 2.5.

Create a new database by clicking Add.

Next, follow the instructions on the screen. Since we’re creating a new database, we leave the radio button in the first window as-is (Fig. 2.6).

Fig. 2.6.

Next, select the second radio button, specifying that you’re creating a new database, but not a standard one from a template (Fig. 2.7).

Fig. 2.7.

Then name the database you want to create. In this case, we’ll call it Introduction to 1C:Enterprise 8 framework (Fig. 2.8).

Fig. 2.8.

After that, you need to specify where to store the data contained in our database. For this purpose, we have already created a special folder, which we indicate in the settings (Fig. 2.9).

Fig. 2.9.

In the next window, leave the default settings (Fig. 2.10). The new database has now been created.

Fig 2.10.

Now when you run 1C:Enterprise 8.2, you can work with the new database (Fig. 2.11), and in both modes. You can switch between the modes by clicking the appropriate buttons 1C:Enterprise or Designer

Fig. 2.11.

Since our database lacks a structure for storing information, you must create one by opening a database in Designer mode. In the window that opens, open the Configuration window

Select Configuration-Open configuration. In the new window we see something like this picture (Fig. 2.12):

Fig. 2.12.

This window is called the configuration window, and the information contained in it is in the form of a configuration tree.

3. Constants

The object known as Constant is used to store constant or quasi-constant data. The important thing is that a single constant is designed to store only one value. There can be any number of constants in the system. Constants are created in the Designer, but are given values in user mode.

When creating the documents we will need information about the CEO of our firm as well as the company’s name and registration date. This information will not change, so you can use a constant to store it. Since the constant is used to store a single value, you need to create three constants.

To create a new constant in the configuration object tree window, right-click on the Constants branch to call up the context menu, then select Add. (Fig 3.1)

Fig. 3.1.

After we select the item, the properties palette, showing the properties of the constants, appears. (Fig 3.2)

Fig. 3.2.

Henceforth you can call up this window by double-clicking on the corresponding branch in the configuration object tree window, or through Properties in the context menu, which you can call up using the right mouse button. (Fig 3.3)

Fig. 3.3.

We will need to fill in the following fields:

• Name (the identifier of the constant). Since the system can have any number of constants, you must give each one a unique name.

• Synonym (a name that is convenient for the user).

• Data type (the type of data stored in the constant). For string data, you must specify a maximum string length and how the string is to be stored. The system allows you to store strings of unlimited length.

• The permissible length reflects how the system stores the strings. To store a string in the system, specify a certain place for it. Accordingly, we can fill the entire place by adding spaces to the string, or fill only the portion of the place that we need to store our string. In our case, we’ll use a 50-character string with variable permissible length. When the length of the string is constant, the specified value of the characters is always stored, with spaces added, if the string itself being stored is shorter.

Thus, we have created a data structure that will allow us to store the information we need, but have not entered the name of the CEO of our organization. In order to specify the desired value directly, go into user mode (1C:Enterprise mode). The user should be able to use the new object which was previously absent. To do this, select the menu item Tools - 1C:Enterprise and reaffirm step-by-step that you want to update the database (Fig. 3.4 and Fig. 3.5).

Constants

Fig. 3.4.

Fig. 3.5.

All of these actions must be done in order to enter the necessary information in user mode (Fig. 3.6 and Fig. 3.7).

Fig. 3.6.

Fig. 3.7.

Henceforth, if there is no need to change the data structure, you can launch the database in the standard way (Fig. 2.11).

We now move on to the creation of the following constant to enter our firm’s registration date. Repeat the steps we took before. In the configuration tree window (notice that new nesting levels have been added to the tree), right-click on Constants to call up the context menu, then select Add (Fig. 3.8).

Fig. 3.8.

After we select the item, the properties palette of the constant that we created appears. Fill in the fields Name and Synonym, and specify Date as the data type. In this case, a set of properties has changed compared to the properties possessed by the constant OrganizationName, with String as the data type (Fig. 3.9).

Fig. 3.9.

The 1C:Enterprise 8 system can store dates with precision down to the second. We can manually specify the date contents (date, time, or date-and-time) we need depending on the date contents with which it is convenient for us to work in this case. In the Date Contents field you can choose one of three options: date, time, or date-andtime. For our purposes we must choose Date, since we’re not concerned about the time of day when our company was registered. We launch 1C:Enterprise in user mode and indicate the actual date of registration. Since we changed the data saving structure in our database (added a new object), we must restructure the database. This process is complicated, and the user obviously cannot work with the object when its structure is being changed, so you may receive the following warning message (Fig. 3.10):

Fig. 3.10.

Constants

This message indicates that the database is open in user mode, and you need to exit user mode before you can restructure further. The user can use the new object only after the changes are loaded (Fig. 3.11).

Fig. 3.11.

This example demonstrates clearly enough the basics of 1C:Enterprise 8.2.

During configuration, the necessary structures for storing information are created. Later, during the execution stage, these structures will be filled with the necessary data.

Working independently

Create a new constant called CEO to store information about the CEO in the database.

4. Catalogs

4.1. General description and purpose

A catalog is a list which the user fills out during execution, allowing the storage of reference information about objects of the same type. Each element of the list may have a complex structure defined during configuration. The number of catalogs is specified during configuration and can be arbitrary. By using a catalog, you can avoid having to enter the same information many times, such as name of the counterparty, and it also provides authentication throughout the system, such as identification of the counterparty upon goods issue and payment.

To implement our record-keeping system in line with the customer’s requirements, we must store reference information about employees, departments, goods, customers and their contracts. Hence, we must create corresponding catalogs.

To create a new catalog in the configuration object tree, select the Catalogs branch. Then right-click it to call up the context menu and select Add, or on the toolbar of the configuration object tree window in the menu Actions - Add, or on the toolbar of the configuration object tree window click the Add button (Fig. 4.1)

Fig. 4.1.

All these actions are identical and call up the configuration object editing window (Fig. 4.2). Henceforth, you can call up this window by double-clicking on the selected catalog.

Since the system can have several catalogs, you need to distinguish between them. To distinguish one catalog from another, use the Name property. The system calls up this catalog by name, so the name of the catalog is created according to the same rules as the names of the constants or the names of variables, i.e., do not use spaces or other special characters. The Synonym field contains a user-friendly representation of the name without any restrictions. On the whole, everything is exactly the same as for constants.

We’ll create the first catalog to store information about our products and services. For convenience, we’ll indicate Name as the general concept "Products", and for the user we’ll also enter the long form "Goods & Services" in the Synonym field.

Fig. 4.2.

At this point, we’ve successfully created a simple catalog and can now switch to

Enterprise’s user mode and look at what we’ve just created (Fig. 4.3). We can perform all the necessary actions when working with a catalog by clicking on "All actions" and selecting the appropriate item from the dropdown menu.

Fig. 4.3.

Enter the following data into the catalog (Fig. 4.4):

Fig. 4.4.

4.2. Hierarchy

The catalog we created allows us to work only with simple data sets. Questions arise almost immediately. How do we deal with large volumes of data? Will it be convenient to work with a list containing several hundred items? For convenience, you can make the catalog hierarchical, i.e., create a tree structure. The simplest analogy is that of a hard drive, which contains many thousands of files located at various levels of a hierarchy, making it possible to navigate them quickly.

We want to make the Products catalog hierarchical, so in designer mode in the configuration object tree window we double-click on Products catalog to call up the catalog editing window and switch to the Hierarchy tab. First, place a check mark after Hierarchical catalog. The next field that we need to fill is Hierarchy type, where you can choose one of the two values Hierarchy of folders and items or Hierarchy of elements. To find out why they are needed, consider the following situation.

Suppose we’re selling a computer. We assume it consists of a system unit, monitor and peripherals. We can sell them together or separately. In this case, the computer must be considered both a commodity and as a "folder" as the node of a tree uniting the components that comprise it. In this case, when there is no difference between the grouping element and the elements being grouped, you must choose a hierarchy of elements.

Now consider another situation. Due to increasing demand, our organization has decided to focus on selling clothing and footwear. Accordingly, it will be convenient to group our products in the catalog according to type. At the same time, the grouping element itself will not have intrinsic value but will rather serve to ease navigation or as a unifying feature in the various reports from which you can display the results. For this purpose, the handbook contains a separate type of special items, which are called Catalog Group, and in order to use them you must choose Hierarchy of groups and elements as the hierarchy type (Fig. 4.5). We can also limit the number of hierarchy levels by placing a checkmark next to Limit the number of groups in the hierarchy and entering the required number in the Number of hierarchy levels field.

The nature of the task requires us to make the Product catalog hierarchical, with Hierarchy of groups and elements as the hierarchy type.

Fig. 4.5.

The appearance of the catalog will now change for the user. Groups now appear in addition to the elements. Working with them is analogous to working with files and folders in Windows Explorer (Fig. 4.6).

Fig. 4.6.

You can create new elements and groups right in the desired group and can move existing ones from one group to another. Thus, after creating a convenient hierarchical structure, the user can quickly and easily navigate within the catalog (Fig. 4.7).

Fig. 4.7.

It should be noted that by choosing All actions – Display mode you can choose one of three ways to display the catalog.

Working independently

Create a new catalog called Departments for storing data about the divisions of the organization. The catalog must have a hierarchy of elements.

4.3. Predefined elements

For the convenience of the user, you can create the catalog elements in advance. Unlike elements created interactively (or automatically) by the user, predefined elements cannot be deleted. Furthermore, each predefined element of a catalog has a unique name, which allows you to automatically refer to this element more conveniently than to conventional catalog elements.

Now let’s create a new catalog called Contacts, for storing data about our suppliers and customers. For the convenience of the end user, it is best to separate buyers and suppliers, which you can easily do through groups. Accordingly, the Contacts catalog must be made hierarchical. Next, using either the context menu in the configuration tree (Fig.4.8), or the Predefined button on the Miscellaneous tab (Fig.

4.9), we call up a window for editing the predefined elements of the catalog (Fig. 4.10).

Fig. 4.8.

We can add new predefined groups and elements in the same way as in user mode. The difference will lie in the presence of an additional Name, a system attribute which is subject to standard naming conventions and which will not be available to the user in 1C:Enterprise mode.

Fig. 4.9.

Fig. 4.10.

4.4. Catalog attributes

Heretofore we have been considering the catalog as a list of items, but now we’ll take a closer look at the elements of this list.

As we mentioned earlier, sometimes we need to store additional information for a catalog element. For this purpose, we have catalog attributes.

In the simplest case we consider the catalog as a table in which each element of the catalog has a corresponding row in the table, with the columns of the table corresponding to its attributes. For a Catalog-type object, there is always a set of system attributes such as Code and Name.

Since the catalog is constantly updated with new items, you must somehow identify them, and the Code attribute is usually intended for this purpose, while the Name attribute is usually used to store the semantic information in the item.

On the Data and Numbering tabs you must define the following properties of the catalog code (Fig. 4.11 and Figure 4.12):

• Autonumbering allows the system to automatically assign the following code when creating a new catalog item. This code can be changed later.

• Check uniqueness is a function that ensures that each new code is unique. Before recording a new item, the system makes sure that no item with the same code exists.

• Code series defines the way in which the code is numbered

• Within subordination (within each group) or Within subordination to the owner (is meaningful for the subordinate directories).

Fig. 4.11.

• Name length is the maximum number of characters that a name can occupy.

• Code length is the maximum number of characters that the code can occupy. For example, when the code length is 10, the code itself can be equal to 1 or 100000.

• Code type defines whether the code is stored as an integer or a string. It should be noted that in the case of a string code, the numbers are perceived as characters. For example, the code 01 is distinguished from the code 001.

Fig. 4.12.

In addition to the system attributes, you can add your required attributes to the catalog. To add a new attribute to the catalog, on the Data tab, right-click Attributes to call up the context menu and select Add (Fig. 4.12). You can perform the same action by selecting Add from the toolbar of this field.

Fig. 4.13.

Next, you need to define the properties of our attribute in the appropriate window.

(Fig. 4.13). Henceforth, you can call up the attribute properties palette by doubleclicking on this attribute, or by right-clicking it and selecting Properties. Let’s create a new attribute called Tax ID (of the Number type with length of 12).

For us, the following attribute properties will be significant:

• Name – the identifier of the attribute

• Use defines to which element of the catalog, element or group, the attribute will relate

• Data type defines the data type of the attribute. The data type can be of a primitive, reference or composite type.

You can also use the attributes to complete the next task: we must store the name of our contractor, but it’s very long. Since the Name attribute is used system-wide, certain restrictions are place on it, including with regard to its length. On the one hand, the name of our counterparty must be kept in the Name, attribute, but, on the other hand, it does not fit there. What can we do? In this case, in the Name attribute we can store a short version of contact’s name for internal use, and store the full name in an additional attribute, which can store the entire set of information. \

Working independently

Create in the Contacts catalog a new attribute for storing the contact’s full legal name.

The properties palette has some interesting peculiarities. First, you can use the right mouse button to specify that you want to display it as a list or set of tabs. In Fig. 4.13 and Fig. 4.14 one and the same properties palette is displayed as a set of tabs and as a list. Furthermore, if you choose "list" you can expand or collapse the corresponding groups.

Fig. 4.14.

Second, the toolbar has a button called Show only important. This saves the user time by not requiring him to fill out the less frequently used properties. However, you should always remember that not all the properties are displayed in this case.

You should also note that you can also call up the properties palette for the entire catalog. To do this, right-click on the corresponding branch in the configuration object tree window and select Properties. (Fig. 4.15). The title bar of the properties palette displays the name of the object whose properties are being displayed in the current window.

Fig. 4.15.

Now consider the following situation: Suppose you want to enter information on the division in which an employee works.

To do this, we add to the Configuration window a new catalog called Employees and assign him the Unit attribute with data type CatalogRef.Departments. (Fig. 4.16)

Fig. 4.16.

In this case, the newly-created attribute will be filled with values from the Departments catalog, bearing in mind that a link to the catalog item Departments will be stored in the Employees catalog, i.e., in effect, when we turn to the Department attribute of the Employees catalog, we turn to an item in the Departments catalog. For example, for the employee Balaganov we indicated that he works in the Sales department. Then, as a result of restructuring within the company, the name of the department has changed from simply Sales to Sales Department. To record this in the Departments catalog, we change the name of the corresponding item to Sales Department. Do we now need to change the name of the department in the Balaganov record? No, because the Employees catalog doesn’t store the name of the department, but rather a link to the catalog item, with all of its attributes.

Working independently

In the Contacts catalog, create a new attribute for storing the VAT rate at which this product will be sold from now on.

4.5. Tabular section

Sometimes you need to store more than one value in an attribute. For example, suppose you want to store information on an employee's children. For this purpose, the system has a tabular section.

Tabular section is a table whose structure is defined during configuration, and the data are entered by the user during execution. For a Catalog object you can now create any number of tabular sections.

Suppose the client wants you to store information on the employee's children and where the employee studied. This information has no intrinsic value, and therefore it must be an attribute of the catalog. Since we don’t know how many children the employee has—and he may have many—we must create not just an attribute, but a tabular section.

A similar situation arises when it comes to information about the employee's education. And since there’s no link between the two, we must store them separately. Thus, we need to create two tabular sections.

To create a tabular section for a catalog, right-click the Data tab and select Add. You can also right-click Tabular section in the configuration object tree window of the selected catalog and select Add to get the same result. (Fig. 4.17)

Fig. 4.17.

From now on, the you can call up the properties palette by double-clicking on the selected tabular section. Since there can be several tabular sections, you must name them. The name of a table must meet the same conditions as the names of catalogs or constants. We’ll call the first tabular section Children. (Fig. 4.18)

Fig. 4.18.

We’ll define whether this tabular section relates only to items, groups or both. In our case, information about children in relation to the group of the catalog does not make sense, so in the Use field we leave the value For item.

Then we must define the structure of the tabular section. In our case the table must contain two columns—the child's name and date of birth. We create two tabular section attributes. The tabular section attributes are defined in the same way as the catalog attributes. Right-click on the appropriate tabular section to call up the context menu, then select Add – Tabular section attribute. (Fig. 4.19)

Fig. 4.19.

To store data about the surname, name and patronymic (middle name) of the child, we create a 50-character string attribute and call it ―Name,‖ and for the date of birth, respectively the BirthDate Date-type attribute with Date as the date contents, since we are not interested in the time of birth (Fig. 4.20).

Fig. 4.20.

In user mode, the catalog will now appear as shown in Fig. 4.21

Fig. 4.21.

Working independently Add a tabular section called Education in the Employees catalog (Fig. 4.22)

Fig. 4.22.

4.6. Subordination

Consider the following scenario: settlements with contractors are conducted in the context of agreements, i.e., we may have several agreements with any given counterparty. In principle, you can create a new catalog in which agreements are items, and use groups order to combine the agreements of a single counterparty. However, this method is not very convenient. First of all, when we have a large number of contacts, for the agreements we need to organize a system of nested groups of an even more complex level. And second, we still have to manually search for the necessary group of agreements corresponding to the selected counterparty. The 1C:Enterprise 8 system allows us to select them at the system level. For our task, let’s consider how this works in more detail.

Create a new catalog called Agreements. Let’s assume that the number of agreements with one customer will not be very big and we won’t have to group them, so we’ll make the catalog non-hierarchical. To specify the settings for subordination, go to the Owners tab. In the toolbar of the Catalog owner list window, choose Edit list item. When we choose this item, we are shown a list from which to choose from where to select the catalog owner. (Fig. 4.23). In our case, the Agreements catalog must be subordinated to the Contacts catalog, i.e., the Contacts catalog will be the Owner of the Agreements catalog (the system allows us to organize subordination to multiple catalogs at the same time, but such a case in principle will not differ and will not be considered in this course).

Fig. 4.23.

4.7. Form. List form, Item form

In user mode of 1C:Enterprise, the user doesn’t work directly with the object that stores information, but through the object known as Form. It should be noted that, depending on the user's current task, he or she can work with the same object using various forms. For example, when working with the catalog, as with a list of items, you use List form, but when working with one item of this list, you use

Item form. If the developer didn’t take any additional steps to configure the object, the system will automatically create the appropriate form with which the user will work. If the automatic form does not suit the user for any reason, the developer can create the necessary form himself.

Let’s create a list form for the catalog Contacts by going to the form tab and creating a new list form using the designer (Fig. 4.24).

Fig. 4.24.

We’ll complete all the steps that the designer suggests. On the first tab, we indicate that we’re creating a list form (Fig. 4.25).

Fig. 4.25.

Then we mark the attributes of the catalog that we want to see (Fig. 4.26).

Fig. 4.26.

This will result in the creation of a form (Fig. 4.27).

Fig. 4.27.

Open the Commands - Global command tab and drag the item Items.List.CurrentData.Ref to the left window in the Command panel (Fig. 4.28).

Fig. 4.28.

In the properties of the command panel item that appears, specify the heading Agreements (Fig.4.29)

Fig. 4.29.

Now, in user mode, you can view only those agreements that relate to the current counterparty in the list form of the Employees catalog and in the record for the user (Fig. 4.30).

Fig. 4.30.

Similarly, you can create the item form for the catalog. For example, for the Employees catalog, the item form will look like this (Fig. 4.31).

Fig. 4.31.

Printing out a catalog

Until now, all the objects and mechanisms we have considered have been intended for entering data into the database. Of course, the user must be able to extract the data, such as in a printable form.

To print out a list of contractors, in the list form of the Contacts catalog, click All actions and select the menu item Output list (Fig.4.32).

Fig. 4.32.

Select the attributes of the catalog you want to print (Fig. 4.33).

Fig. 4.33.

The result is a table that can be printed or saved as an external file (Fig.4.34).

Fig. 4.34.

5. Enumeration

Enumeration is a non-hierarchical list of finite length which is populated with values only during configuration. Each item of the list is a simple value (it does not have any details or attributes) and cannot be changed by the user. For example, if we know for certain that an employee may be hired either part-time or full-time, it is logical to create an enumeration with two items. Of course, you can create a new catalog, set predefined items in it and assign roles so that they cannot specify new items, but enumeration is faster and easier to use for the programmer, system and end user.

So then, we want to have information in our database about whether our employee works for the company full time or part time. How do we do this? Well, first of all, this information must be specified for each employee, which means we need to create a new attribute of the Employees catalog. Second, the employee can either be full-time or parttime, so it is logical to create a new enumeration and specify it as the data type of our new catalog attribute.

Let’s create a new enumeration called HiringTypes. To do this, right-click on Enumeration and select Add. (Fig. 5.1).

Fig. 5.1.

Specify the name HiringTypes , which automatically populates the Synonym field just as it did for the catalogs. (Fig. 5.2).

On the Data tab, right-click Values and select Add, or select the appropriate button in the toolbar. The familiar properties palette appears (Fig. 5.3), in which we specify Name—the enumeration values. Similarly, we create the following value.

Fig. 5.2.

Fig. 5.3.

Notice that, unlike the attributes of the catalog, the enumeration values must be placed in the order in which the user wants to see them. You can change the order of the enumeration values by using the toolbar buttons Move up and Move down, or by the corresponding context menu items, which you can call up by right-clicking on the value you want.

At this point, in the Employees catalog we add the new attributes HiringType with data type EnumRef.HiringTypes.

6. Form controls

As mentioned above, the user does not work directly with the object, but with an on-screen form, and the user can use various forms to work with one and the same object. The system allows developers to use a number of standard mechanisms (form controls) in combination to create almost any functionality and appearance. It’s like building things with Legos; you can put the pieces together in various ways to create something completely new. Next, we consider a number of standard mechanisms in more detail. It should be borne in mind that these features of the on-screen form are not tied to any particular type of configuration items, so you can use them for any on-screen form of any object.

Although various elements of the form are designed for various purposes and have their own specific features, many properties will be important for all of them.

Name is the system name, a unique identifier that allows you to work with the item

DataPath establishes a connection between what is displayed on the form and where the information is stored

Visible allows you to either show the object or hide it from the user

Accessibility allows the user to see the object, but does not allow him to interactively modify it

You can add any of the form items by right-clicking and selecting Add from the context menu (Fig. 6.1).

Fig. 6.1.

For each form item, you can call up its properties palette to configure the necessary mechanisms by right-clicking it and selecting from the context menu.

6.1. Field

The Field form item is designed to display data on the form and enable the user to change the data. Depending on its Type, its appearance can vary.

6.1.1. Text box

In the Employees catalog we have the HiringType attribute, but the user cannot work with it. To work with it, you must place the attribute on the catalog item form. The Field form item with Text box type makes it easier to work with this attribute.

There are two ways to place on a form a text box that will show the data of the attribute. You can add a new form item by specifying the type Field (Fig. 6.2) and then specifying in its properties DataPath, Type and Title (Fig. 6.3).

Fig. 6.2.

Fig. 6.3.

You can also use the left mouse button to drag the attribute out of the attributes window to the form items window (Fig. 6.4).

Fig. 6.4.

The most important properties for the text box will be:

Title – the text header that the user sees

Title position – the position of the title relative to the text box

Ignore during input allows you to automatically move the cursor to the field when editing items on the form.

Activate by default allows you to make the field active when the form is opened.

Warn on edit allows you to issue a warning to the user when he or she is editing the data in the field, if WarnOnEdit is specified

6.1.2. Check box

By using the checkbox on the form, you can display data with Boolean or Number as the type.

Create an item form for the Products catalog (Fig. 6.5).

Fig. 6.5.

Then add to the catalog the Service attribute with Boolean as the type so as to allow the user to indicate whether this catalog item is a product or service. Now add this attribute to the form by dragging the Service attribute from the attributes window to the form items window (Fig. 6.6).

Fig. 6.6.

Since Boolean attributes are conveniently displayed on the form as a checkbox, the system will automatically indicate this type of field (Fig. 6.7).

Fig. 6.7.

For the checkbox, the most important properties for us will be the following:

Title – the text header that the user sees

Title position – the position of the title relative to the checkbox

6.1.3. Switch field

Switch field is designed to give the user a choice of one of several predefined options.

In the Products catalog, for each item we’ll indicate its quality, which may be one of three: high, normal and low. To do this, create a new enumeration called GoodsQuality consisting of three values. Now in the Products catalog, add the new attribute GoodsQuality with the appropriate data type. In the properties of the attribute, indicate the initial (default) value (Fig. 6.8).

Fig. 6.8.

To create the required number of switch items, use SelectionList (Fig. 6.9).

Fig. 6.9.

For the switch, the most important properties for us will be the following:

Title – the text header that the user sees

Title position – defines the position of the title relative to the switch items.

Selection list defines the items of the switch, how many there are of them, how they are to be represented on the form and the selected values.

Number of columns defines the appearance of the switch (Fig. 6.10).

Fig. 6.10.

6.2. Command

Commandallows the user to perform any of the actions that were predefined during configuration. These actions can be described in a script in the form module and then linked with the form (Fig.6.11) in the form of a button (or hyperlink) and be executed when the user clicks on this object.

Fig. 6.11.

Text of the procedure that is performed when the button is clicked:

&AtClient 
Procedure Command1(Command)
	Message ("Button is pressed.");
EndProcedure

Command may also perform any of the standard actions that the platform allows you to perform on an object (Fig. 6.12).

Fig. 6.12.

The following properties will be important for the button:

Title is a textual representation of the object on the form.

Type causes the command to appear as a button or hyperlink.

CommandName establishes a relationship between the form object and the action being performed.

Picture allows you to place on the form the image that is displayed depending on the Display settings.

6.3. Group

Group allows you to bring together several items located close to each other on the form in order to work with them. Its appearance can change depending on the Type property.

6.3.1. Normal group

The item known as Group item with Normal group as the type allows you to visually combine several items on the form and control where they appear on the form (Fig.6.13).

Fig. 6.13.

For a normal group, the most important properties are:

Display – defines the appearance of the group on the form

Grouping – defines how the items within the group are located on the form

6.3.2. Command panel

The command panel is a set of commands that can be either standard or created by the developer (Fig. 6.14).

Fig. 6.14.

6.3.3. Group of pages

The groups with Pages and Page as the type allow you to place items on the form in the form of several layers of pages. To do this, create a Pages-type group and then for each page within it create a Page-type group (Fig. 6.15), and place the form items on it in the usual order.

Fig. 6.15.

The following properties are important for us:

PagesRepresentation- for the Pages group sets how the tabs are displayed on the form.

Title- for the Page group sets the title on the tab of the form.

6.4. Table

Table allows you to display a table on the form, such as a tabular section of an object (Fig. 6.16).

Fig. 6.16.

A table may include various items such as a command panel, fields and groups, thus defining how the table appears on the form.

7. Event handler

When you need to have actions performed automatically in response to user actions, use the event handler.

We store the short and long versions of the counterparty’s name in the Contacts catalog. It is logical to assume that these names will be similar. Therefore, when a user enters a short name, it is desirable to replicate it in full, i.e., perform certain actions in conjunction with a name change. The system cannot predict what actions we want to perform when an event occurs, so we must write our own procedure for the system to perform and link this process to the event that is being processed (Fig. 7.1).

Fig. 7.1.

Text of the event handler procedure:

&AtClient 
Procedure DescriptionOnChange(Item) 
	If Object.FullDescription="" Then 
		Object.FullDescription = Object.Description; 
	EndIf;
EndProcedure 

Besides being able to perform actions when an event occurs, you can sometimes manage the event itself, i.e., indicate whether the event will happen or not.

Consider the following scenario: Suppose you need to set a VAT of only 18% on services. In this case, when you save a catalog item, you must make sure it is a service. If a Product item is a service and VAT is not 18%, the program must inform the user that this is not allowed and refuse to record the item until the user either specifies the correct VAT rate or specifies that it is a product.

To solve this problem, we use the event handler BeforeWriteAtServer (Fig. 7.2).

Fig. 7.2.

Text of the procedure:

&AtServer 
Procedure BeforeWriteAtServer(Cancel, CurrentObject, WriteParameters) 
	If CurrentObject.Service And (CurrentObject.VATRateBase <> Catalogs.VATRates.VAT18) Then 
		Message("The service can have the VAT rate only 18%"); 
		Cancel = True;
	EndIf;
EndProcedure 

8. Document

Document is the type of configuration object designed for recording day-to-day events that happen within a company in the system and corresponds to the generallyaccepted concept of a document. A document is uniquely defined by its type, number and date. The date of the document is stored in the date-and-time format with precision down to the second. You can create any number of various types of documents.

To record a completed payment, create a new document type. Creating a new document type is the same as creating a new catalog. In the configuration object tree window, right-click on Documents and select Add. In the new window, specify the Name of the document, i.e., its type. This name is subject to the same restrictions as the names of other configuration objects. Let’s call it ExpenseCashAssets and Cash outflow as the Synonym (Fig. 8.1). Next, we need to determine the structure of our document based on its attributes.

Fig. 8.1.

Depending on their purpose, all attributes can be divided into those that occur once and those that are repeated. Accordingly, the attributes of a document are divided into those of the header and those of the tabular section. For example, a goods received note usually indicates the supplier and a list of the goods received from him, and in this case the supplier will be the attribute of the header, while the merchandise will be the attribute of the tabular section.

8.1. Header attributes

When a cash outflow occurs, we’ll assume that it’s more convenient for the customer to work with each payment separately, so in this case the document will only have the attributes of the header.

Fig. 8.2.

As we have already stated, documents always have the attributes Date and Number. In the editing window of the ExpenseCashAssets document on the Numbering tab, set the following properties related to its date and number (Fig. 8.2):

• Autonumbering – a checkbox that toggles automatic creation of the document number when it is created. You can change the number later.

• Number length is the maximum number of characters the document number can occupy.

• Check uniqueness is a checkbox that toggles automatic checking of the document number. The system warns you if an action is in violation of the numbering rules.

• Number type specifies the data type of the document number. It may be a number or string. On the one hand, it is convenient when the documents are numbered in sequence, but sometimes you need to specify not only a number in a sequence, but also the prefix of the document (a letter or string of letters). In this case, the entire number must be defined as a string, i.e., practically the same as the catalog code.

• Periodicity. The numbering of documents is usually not open-ended, but within a certain time interval, most often in years. The system allows for this by offering the following periodicity options:

§ Non-periodic

§ Within a year

§ Within a quarter

§ Within a month

§ Within a day

For the document ExpenseCashAssets let’s change the number length to 6 characters and the periodicity to Within a year.

According to the task, you must keep records of settlements with contacts in the context of agreements. Furthermore, the document ExpenseCashAssets must allow us to pay not only suppliers, but employees as well. To fulfill this requirement, you must create new attributes of the ExpenseCashAssets document. We need to create three attributes:

• Counterparty;

• Agreement;

• Amount.

Fig. 8.3.

On the Data, tab in the same way as was done for the catalog, add the new attributes. (Fig. 8.3) Specify the Name of the attribute, its type and, if necessary, additional settings for the type, such as, for example, the string length or the precision of the number. Since the system already stores information about contacts and agreements, the type of the attributes Counterparty and Agreement you must specify CatalogRef.Contacts and CatalogRef.Agreements. For the attribute Amount you must not only specify the Number type, but precision 2 as well, so that you can correctly enter the amount of money received. Furthermore, since you need to pay not only contacts, but employees as well, for the attribute Counterparty you can indicate the aggregative data type CatalogRef.Contacts and CatalogRef.Employees.

8.2. Document forms

In the same way as when working with a catalog, the user does not work directly with the Document object, but through the on-screen form. Accordingly, when working with one document, use Document form (Fig. 8.4), and for working with multiple documents of this type, use List form (Fig. 8.5).

Fig. 8.4.

Fig. 8.5.

If the auto-generated form is not satisfactory, you can create a corresponding form in the Designer using the form-handling mechanism we described earlier (Fig. 8.6). However, you can specify some of the settings affecting the appearance and behavior of the form without creating the form itself.

Fig. 8.6.

To ensure that the user can select only those agreements in the document form that relate to the selected counterparty, you must make the following settings (Fig. 8.7) In the properties of the Agreement attribute, establish a connection between the choice parameters and the Counterparty who must be the owner for the Agreement.

Fig. 8.7.

The program provides ample opportunities for the user to configure the list form directly in 1C:Enterprise mode.

Click All actions in the document list form and select List options in the menu that appears. Then by marking the settings tab-by-tab (Fig. 8.8 - Fig. 8.12), the user can cause the form to be displayed in the most convenient way (Fig. 8.13).

Fig. 8.8.

Fig. 8.9.

Fig. 8.10.

Fig. 8.11.

Fig. 8.12.

Fig. 8.13.

Working independently Create a document called Cash inflow (Fig. 8.14)

Fig. 8.14.

Note that the user himself can, within certain limits, change the appearance of the form (Fig. 8.15 and Fig. 8.16). To do this, select Change form from the drop-down list that appears when you click All actions.

Fig. 8.15.

Fig. 8.16.

Until now, all the forms we have considered had a static appearance, which was set in the designer, but the appearance of the form can vary depending on the situation.

Since the attributes of the payer have meaning only when the payment is cashless, we will cause them to be hidden in all other cases. To make it easier to hide the attributes, group them together (Fig.8.17).

Fig. 8.17.

To make the attributes disappear when the payment method changes, use the OnChange event handler for the payment method (Fig. 8.18).

Fig. 8.18.

In addition, you must use the OnOpen event handler for the entire form (Fig.8.19).

Fig. 8.19.

Text of the event handler procedures in the CashInflow document form module (for easier visualization, this code is not optimized for running in thin client mode):

&AtClient 
Procedure PaymentMethodOnChange(Item) 
	Items.Group1.Visible=GetVisible(Object.PaymentMethod);
EndProcedure 

&AtServer 
Function GetVisible(Method) 
	If Method=Enums.PaymentMethods.Noncash Then 
		Ret=True;
	Else
		Ret=False;
	EndIf;
	Return Ret; 
EndFunction 

&AtClient 
Procedure OnOpen(Cancel) 
	Items.Group1.Visible=GetVisible(Object.PaymentMethod); 
EndProcedure 

As a result, for the user in 1C:Enterprise mode the appearance of the form will change over time depending on the user’s actions(Fig.8.20).

Fig. 8.20.

8.3. Attributes of the tabular section

In order to store not just a single value, but any number of values of the same type, we use a tabular section of the document. For each document we can define any number of tabular sections, each of which can contain any number of atttributes.

In our case, for the PurchaseInvoice document we need to create a tabular section called Goods with the attributes Goods, Quantity, Price and Amount with value types CatalogRef.Product, Number with precision of 3 and Number with precision of 2, respectively. Creating a tabular section of the document is also identical to creating a tabular section of a catalog. On the Data tab in the appropriate window using the context menu, we create a tabular section, and then its attributes (Fig. 8.21).

Fig. 8.21.

For the Purchase Invoice document, the form will differ from the form of the Cash inflow and Cash outflow documents in that it has a tabular section. When you create an invoice, you must also pay attention to the connection between Agreement and Counterparty, as well as bring up the total of the Amount column.

To calculate the amount, use the OnChange event handlers for quantity and price (Fig. 8.22). Though the result of these handlers must be the same, for convenience we give 2 different ways of writing this action.

&AtClient 
Procedure GoodsQuantityOnChange(Item) 
	Items.Goods.CurrentData.Total = Items.Goods.CurrentData.Price * Items.Goods.CurrentData.Quantity;
EndProcedure 

&AtClient 
Procedure GoodsPriceOnChange(Item) 
	CalculateRow = Items.Goods.CurrentData; 
	CalculateRow.Total = CalculateRow.Price * CalculateRow.Quantity;     
EndProcedure 

Fig. 8.22.

Fig. 8.23.

In order to let the user see not only the sum in each row, but also the total for the document, in the properties of the Goods table we indicate that it is necessary to output the Footer (Fig. 8.23). Then in the properties of the Total field we indicate Footer data (Fig. 8.24).

Fig. 8.24.

As a result, the user receives the following form (Fig. 8.25) for working with a purchase invoice.

Fig. 8.25.

Working independently

Create a Sales invoice document (Fig. 8.26 and Fig. 8.27)

Fig. 8.26.

Fig. 8.27.

The SalesInvoice document has a more complicated structure than the PurchaseInvoice document we considered earlier, so we use a number of additional mechanisms to make it easier for the user. First, to ensure that the user can only enter goods in the Goods tabular section and only services in the Services tabular section, we set the choice parameters in the properties of the attributes (Fig. 8.28).

Fig. 8.28.

Second, since the user has already indicated the VAT rate at which each good must be sold, it is desirable to automatically insert the rate in the document. For this we use the event handler OnChange for the product in the Goods table.

Third, we need to calculate the amount of VAT according to the specified rate. Since the VAT rate is a reference to a catalog item, it is not subject to multiplication. To obtain for each VAT rate the number for calculating the amount of VAT, in the VATRates catalog we add a new attribute called Rate (Fig. 8.29).

Fig. 8.29.

Furthermore, to allow the user to see the total sum of the document in the list form, we must calculate the DocumentTotal attribute, for which we use the BeforeWrite event handler. Since we want to handle this event not for the form, but for the object itself, the text of the event handler procedure will be in the document module.

&AtClient 
Procedure GoodsVATAmountOnChange(Item) 
	CurRow = Items.Goods.CurrentData; 
	CurRow.Total = CurRow.SubTotal+CurRow.VATAmount; 
EndProcedure 

&AtClient 
Procedure GoodsVATRateOnChange(Item) 
	CurRow = Items.Goods.CurrentData; 
	RateNumber = GetRate(CurRow.VATRate); 
	CurRow.VATAmount = CurRow.SubTotal * RateNumber; 
	GoodsVATAmountOnChange(Item);
EndProcedure 

&AtServerNoContext
Function GetRate(VATRate) 
	Ret = VATRate.Rate / 100; 
	Return Ret; 
EndFunction 

&AtClient 
Procedure GoodsSubTotalOnChange(Item) 
	GoodsVATRateOnChange(Item);
EndProcedure 

&AtClient 
Procedure GoodsPriceOnChange(Item) 
	CurRow = Items.Goods.CurrentData; 
	CurRow.SubTotal  = CurRow.Price * CurRow.Quantity; 
EndProcedure 

&AtClient 
Procedure GoodsQuantityOnChange(Item) 
	GoodsPriceOnChange(Item); 
EndProcedure 

&AtClient 
Procedure GoodsProductOnChange(Item) 
	CurRow = Items.Goods.CurrentData; 
	CurRow.VATRate = GetProductRate(CurRow.Product); 
	GoodsVATRateOnChange(Item); 
EndProcedure 

&AtServerNoContext 
Function GetProductRate(Product) 
	Ret = Product.BaseVATRate; 
	Return Ret; 
EndFunction 

8.4. Printing out a document. The print wizard

To allow the user to print out documents, we use the print wizard. Go to the Layouts tab and click Wizards (Fig. 8.30).

Fig. 8.30.

Following the instructions in the wizard (Fig. 8.31 - Fig. 8.36), fill in all the required fields.

Fig. 8.31.

Fig. 8.32.

Fig. 8.33.

Fig. 8.34.

Fig. 8.35.

Fig. 8.36.

The wizard then creates a new template (Fig. 8.37) as well as a new command, and the following code will be created in the command module and manager module:

Procedure Print(Spreadsheet, Ref) Export 
            //{{_PRINT_WIZARD(Print)
            Template = Documents.SalesInvoice.GetTemplate("Print"); 
            Query = New Query; 
            Query.Text = "SELECT
                        SalesInvoice.Agreement,
                        SalesInvoice.Contact,
                        SalesInvoice.Date,
                        SalesInvoice.DocumentTotal,
                        SalesInvoice.Employee,
                        SalesInvoice.Number,
                        SalesInvoice.Goods.(
                                    LineNumber,
                                    Product,
                                    Quantity,
                                    Price,
                                    SubTotal,
                                    VATRate,
                                    VATAmount,
                                    Total
                        ),
                        SalesInvoice.Services.(
                                    LineNumber,
                                    Product, 
                                    SubTotal, 
                                    VATAmount, 
                                    Total 
						) 
						FROM 
							Document.SalesInvoice AS SalesInvoice 
						WHERE SalesInvoice.Ref IN (&Ref)"; 
            
			Query.Parameters.Insert("Ref", Ref); 
            Selection = Query.Execute().Choose(); 
  
            AreaCaption = Template.GetArea("Caption"); 
            Header = Template.GetArea("Header"); 
            AreaGoodsHeader = Template.GetArea("GoodsHeader"); 
            AreaGoods = Template.GetArea("Goods"); 
            AreaServicesHeader = Template.GetArea("ServicesHeader"); 
            AreaServices = Template.GetArea("Services"); 
            Footer = Template.GetArea("Footer"); 
  
            Spreadsheet.Clear(); 
  
            InsertPageBreak = False; 
            While Selection.Next() Do 
			
				If InsertPageBreak Then 
					Spreadsheet.PutHorizontalPageBreak();
				EndIf; 
  
				Spreadsheet.Put(AreaCaption);
				Header.Parameters.Fill(Selection);
				Spreadsheet.Put(Header, Selection.Level()); 
				Spreadsheet.Put(AreaGoodsHeader);
				
				SelectionGoods = Selection.Goods.Choose(); 
				
				While SelectionGoods.Next() Do 
					AreaGoods.Parameters.Fill(SelectionGoods);
					Spreadsheet.Put(AreaGoods, SelectionGoods.Level()); 
				EndDo; 
				
				Spreadsheet.Put(AreaServicesHeader);
				
				SelectionServices = Selection.Services.Choose(); 
				While SelectionServices.Next() Do  
					AreaServices.Parameters.Fill(SelectionServices);
					Spreadsheet.Put(AreaServices, SelectionServices.Level()); 
				EndDo; 
				
				Footer.Parameters.Fill(Selection);
				Spreadsheet.Put(Footer); 
				InsertPageBreak = True; 
			EndDo; 
			//}} 

EndProcedure 

Fig. 8.37.

In addition, the Print button has appeared in the list form and document form on the command panel (Fig. 8.38). Click on it to print out the document.

Fig. 8.38.

9. Functional options

The functional options are a mechanism that allows you to quickly enable or disable the selected functionality in user mode.

Create the following objects:

A boolean constant called CurrencyAccounting

A catalog called Currencies

In the document CashInflow, an attribute called Currency with CatalogRef.Currencies as the type

In the document SalesInvoice an attribute called Currency with CatalogRef.Currencies as the type

A functional option called CurrencyAccounting (Fig. 9.1)

Fig. 9.1.

In the properties of the functional option we include the catalog and the attributes we created (Fig. 9.2). Of course, we also need to add the attributes we created to the document forms. We then switch to 1C:Enterprise mode and do the following:

Set the value of the constant CurrencyAccounting False (unchecked) and open the documents CashInflow and SalesInvoice. In this case, the relevant attributes will be hidden (Fig. 9.3). In addition, the Currency catalog will be unavailable to the user.

Now we set the constant to True and make sure the user has access to the objects that are responsible for currency accounting (Fig. 9.4).

Fig. 9.2.

Fig. 9.3.

10. Subsystems and interface

Subsystem allows you to group various system objects according to any functional sign.

Let’s create some subsystems and indicate their composition (Fig. 10.1). Keep in mind that all objects must be included in one subsystem or other.

Fig. 10.1.

As a result of these actions, an interface which is divided according to the subsystems has been automatically created for the user in 1C:Enterprise mode (Fig. 10.2).

Fig. 10.2.

You will notice that for each subsystem there is an additional section on the partition panel called Desktop. To activate this section, we create for all the object types (documents and catalogs), which we may want to see as the user, the list forms. After that, in the configuration properties (Fig. 10.3), open the desktop workspace. In the window that appears, in both columns, we add all the list forms that we created (Fig. 10.4) and then hide them by unchecking the Visible checkbox.

Fig. 10.3.

Fig. 10.4.

In 1C:Enterprise mode, right-click the Desktop icon, select Desktop setup (Fig. 10.5) and indicate the forms of the objects that we as the user want to see on the desktop (Fig. 10.6). In this way, the user can customize the functionality and appearance of the desktop (Fig. 10.7).

Fig. 10.5.

Fig. 10.6.

Fig. 10.7.

11. Information register

Sometimes it’s inconvenient to store information in a catalog. For example, if we buy a product from a single vendor, the price isn’t likely to change very often. It would be convenient to be able to store the price and automatically insert it into documents. To accomplish this task, we need to store the price for each vendor and for each product we purchase from it. The task is much more complex if we decide to also store the price as part of an agreement. On the one hand, this is frequently-accessed information, i.e., it makes sense to store it in a catalog. On the other hand, it is difficult to store it, and many of the system’s catalog capabilities are superfluous in this case. Besides, we would like to be able to find values quickly. For this purpose, there is a special object called Information register.

Working with the information register is similar to working with other objects. The register must be structured for the kind of information that will be stored in it. If you want to store various types of information, you can create any number of information registers.

Fig. 11.1.

Creating a new register is similar to creating a new document or catalog (Fig. 11.1). Define the structure of the register on the Data tab. (Fig. 11.2). The information we store in the register is located in a Resource, while the various contexts in which we want to see the information is in Dimensions. In our case, we must store the price for each product purchased under each agreement with each vendor, i.e., price in the context of vendors, agreements and products. Consequently, the price must be a resource, while the vendor, agreement and product are dimensions. In this case, the system will make sure that for each unique set of measurement values there can be only one value of the resource, i.e., there can be only one price for each item under each agreement. Of course, you must enter the appropriate data type for the dimensions and resources.

Fig. 11.2.

The user can enter information in the register in 1C:Enterprise mode using the appropriate list form list (Fig. 11.3).

Fig. 11.3.

To ensure that the price is automatically inserted in a Purchase Invoice, use the GoodsProductOnChange event handler. To get the desired price, we must extract only the information we need now out of all the information stored in the register, i.e., filter it somehow. This can be done using a special object called Structure. Then we apply the filter to our register to get the price we need.

The code is as follows:

&AtServer 
Function GetPrice(Product) 

	FilterStructure = New Structure;
	FilterStructure.Insert("Vendor",Object.Contact);
	FilterStructure.Insert("Agreement",Object.Agreement);
	FilterStructure.Insert("Product",Product);
	FilterResult = InformationRegisters.VendorPrices.Get(FilterStructure); 
	
	Return FilterResult.Cost; 

EndFunction 

&AtClient 
Procedure GoodsProductOnChange(Item) 

	CalculateRow = Items.Goods.CurrentData; 
	CalculateRow.Cost = GetPrice(CalculateRow.Nomenclature); 
	GoodsPriceOnChange(Item);
	
EndProcedure 

The information register allows us to not only quickly retrieve information in various contexts, but also accomplish a number of other tasks. Sometimes we want to know the history of changes to certain information, such as currency exchange rates. In this case, we need to store the exchange rate for each currency every day. Applying what we learned above, we can add a new dimension called Date to the information register. However, since this is a common occurrence, we do it at the system level. In the properties of the information register, you can indicate that it is periodic (Fig. 11.4).

Fig. 11.4.

Depending on the periodicity that we set for the information register, it can store information that is unique to various periods, for example, one value for each year, or one value for the month or day, etc. If the register is periodic, we add a dimension called Period, (Fig. 11.5 and Fig. 11.6) and the system allows fast access to the information we need for the selected time period.

Fig. 11.5.

Fig. 11.6.

Information stored in the information register can be linked with documents. For example, we can keep track of where each employee works and his or her salary, using an appropriate personnel order to assign him or her to the appropriate department and set his or her salary. On the one hand, if we create a document and fill in the catalog attributes, all this information will be entered into the system. However, if we delete that same document, the information remains in the catalog and becomes irrelevant. To solve this problem, there is a document-posting mechanism which allows us to establish a relationship between the data in the register and the document. Here’s how it works: You can assign a status called Posted to a recorded document, which is determined by the value of the system attribute Posted. When you assign this status, you trigger the posting event handler, in which you can describe which records in which register create the document. If this status is removed (such as when it is marked for deletion), the records generated by this document are automatically deleted from the registers. The status of the document is displayed in the appropriate pictogram and may be changed by the user.

To accomplish this task, you need to create an information register called Information about employees. We’ll assume that our organization does not have parttime employees, i.e., an employee can only work in one department and earn a salary there. The structure of the information register must be as follows: dimension Employee and resources Department and Salary. Keep in mind that you can store a reference value in a resource—in our case, a reference to the Departments catalog (Fig. 11.7).

Fig. 11.7.

Thereafter, our employees will probably eventually be able to move from one department to another or receive another salary, so we set the periodicity of the register as Within a month. Then to ensure that the data from the document is stored in the register, we must specify Subordinate to recorder as the write mode (Fig. 11.8). In this case, the register will show an additional field called Recorders, in which the document that created these records will be indicated.

Fig. 11.8.

Then we create a document called Personnel order. The document will have the attributes Employee, Department and Salary (Fig. 11.9).

Fig. 11.9.

Since we want the document to create records in the register, go to the Register records tab and set the following properties (Fig. 11.10):

Posting: Enable (for this document we can assign the Posted status)

Register records deletion is automatic (i.e., after the posting of this document is canceled, the records that it formed will be deleted in the registers) Specify the registers in which the records will be created.

Fig. 11.10.

Then use the designer to create the code that will define which information will be recorded and where. To do this, click Register records wizard, and then manually or automatically using Fill expressions (Fig. 11.11).

Fig. 11.11.

The wizard then creates an event handler procedure in the document module.

Procedure Posting(Cancel, Mode) 

	//{{__REGISTER_REGISTERRECORDS_WIZARD
	//This fragment was built by the wizard.      
	// Warning! All manually made changes will be lost next time you use the wizard. 
	//register InformationAboutEmployees 
	
	RegisterRecords.InformationAboutEmployees.Write = True; 
	Record = RegisterRecords.InformationAboutEmployees.Add(); 
	Record.Period = Date; 
	Record.Employee = Employee; 
	Record.Department = Department; 
	Record.Salary = Salary; 
	
	//}}__REGISTER_REGISTERRECORDS_WIZARD

EndProcedure 

In 1C:Enterprise mode, users can post and unpost documents (Fig. 11.12).

Fig. 11.12.

12. Query

Query is an object of the script language that is used to get information from the database as a sample that is created according to specified rules.

Let’s try using this function to obtain information about the sales figures for the current month for this or that department.

To learn how to create a query and see what it does, use the data processor of the query console. Change the settings as follows (Fig. 12.1):

In the system preferences, specify startup mode Thick client (managed application). In the configuration properties, specify Use ordinary forms in managed application.

Fig. 12.1.

Open the data processor in 1C:Enterprise mode and create a new query (Fig. 12.2).

Fig. 12.2.

It’s easier to create a query using the Query Builder (Fig. 12.3).

Fig. 12.3.

Fig. 12.4. Since our database doesn’t have a direct connection between departments and sales, we divide the problem into parts. Using the first query, try to collect the data on the employees’ sales (Fig. 12.4)

Fig. 12.5.

The result of this query will show us the sales data (Fig. 12.5), but let’s process them first to make it easier to work with them. To obtain general sales information, use the grouping function (Fig. 12.6 and Fig. 12.7).

Fig. 12.6.

Fig. 12.7. Since we’re interested in sales figures for a certain period of time, we specify the appropriate condition in the query (Fig. 12.8).

Fig. 12.8.

The value of the parameters themselves must be set manually by clicking Parameters (Fig. 12.9).

Fig. 12.9.

Fig. 12.10.

Using the second query, we obtain information about the division in which the staff member works. For this purpose, we use the virtual table SliceLast for the register InformationAboutEmployees (Fig. 12.10 è Fig. 12.11).

Fig. 12.11.

Thus, we obtained 2 tables, each of which contains information of interest to us. To obtain the resulting data, gather together the data from these two tables (Fig. 12.12). For this purpose, we use the join function (Fig. 12.13). Next we use the grouping and conditions functions, which we discussed earlier, and specify the necessary parameters (Fig. 12.14 and Fig. 12.15).

Fig. 12.12.

Fig. 12.13.

Fig. 12.14.

Fig. 12.15.

Fig. 12.16.

Thus, by using the query we were able to gather and process the information (Fig. 12.16) that was stored in various places in our database.

13. Report. Data composition

Report is an object of the 1C:Enterprise system that is designed to process information and present it to the user in the form of a table document which can be printed out or saved as an external file. Data composition is a function of the platform that we use to create a report for the developer.

Let's create a new object called Report in the standard way using data composition (Fig. 13.1).

Fig. 13.1.

Use the wizard to create a new data composition schema (Fig. 13.2).

Fig. 13.2.

Add the new set of data that we will obtain using a query (Fig. 13.3).

Fig. 13.3.

Create a query using the query builder (Fig. 4.13 – Fig. 13.6), which will gather employee sales data by currency for a certain period.

Fig. 13.5.

Fig. 13.6.

When setting up the schema of the composition, indicate DocumentTotal on the Resources tab as the resource (Fig. 13.7).

Fig. 13.7.

On the Options tab, lift the access restriction from the start and end date parameters of the reporting period (Fig. 13.8).

Fig. 13.8.

On the Settings tab, define the appearance of our report. For this, we add a new table and specify groupings of rows in it (Fig. 13.9). In addition, in the properties of the options for both dates, indicate that they are included in the custom settings and set them to normal edit mode.

In the same place, on the Selected fields tab, select the DocumentTotal field (Fig. 13.10).

Fig. 13.9.

Fig. 13.10.

Fig. 13.11.

Here we also create another version of the report with a different print form (Fig. 13.11). As we did for the first version, we must specify the appropriate settings for the options and selected fields.

In 1C:Enterprise mode, when you click on Settings, the user must specify the period for which he wants the sales data (Fig. 13.12). Next, by selecting one of the versions, the user receives information about sales in various forms (Fig. 13.13 and Fig. 13.14).

Fig. 13.12.

Fig. 13.13.

Fig. 13.14.

Working independently

Create a report on the sales of all the divisions (Fig. 13.15).

Fig. 13.15.