What is the purpose of the directory configuration object? Brief theoretical information. The “Directory” configuration object is an application object and is designed to work with lists of data. What is a directory
Print (Ctrl+P)
Main types of configuration objects
All configuration objects that exist in the 1C:Enterprise system form
several main types. Each type of configuration object represents both
times those “building elements” from which the configuration will be created.
Formally, configuration objects are grouped into views in the configuration tree. The user sees the names of the types at the first level of the configuration tree when he opens the Configuration window in the configurator.
Despite the lack of a formal definition, the names of types of objects
configurations are widely used when working with the 1C:Enterprise system.
For example, a specialist configuring the 1C:Enterprise system
sees its goal in developing the necessary set of reference books, documents, reports,
journals that will implement the required accounting system. The end user of the 1C:Enterprise system - manager, accountant, manager, storekeeper - also operates with specific reference books, documents, etc. to solve the tasks facing him. Communication between these two categories of users will also occur in terms of configuration object types.
A data object of any type is already a specific document, report,
log, constant, and so on. As a rule, each object is used for work
with well-defined information of the subject area.
Below is a brief description of the main types of system configuration objects
"1C:Enterprise". Details of the configuration objects that are combined into
Each of these types will be described below.
Constants
To work with permanent and conditionally permanent information, the system uses
objects of type Constant. The information stored in constants rarely changes, but
as a rule, it is often used in work. For example, constants can store
name of the enterprise, its tax identification number, surnames of the director and chief accountant and other
similar information. An unlimited number of constants can be described in the system.
Directories
To work with constant and conditionally constant information with a certain set
For values, the system uses objects of the Directory type.
Typically, directories are lists of materials, goods, organizations, currencies,
employees, etc.
The directory support mechanism allows you to design and maintain the most
various reference books. At the configuration stage, you can describe what properties
each specific directory has. Custom properties include:
for example, code length and type, number of hierarchy levels, uniqueness support
codes, a set of directory details.
In addition to the code and name, the mechanism for working with directories allows you to create
a set of details for storing any additional information about the element
directory (for example, for a product it may be purchase and selling prices,
manufacturer, for an employee - position, education, residence address, etc.),
as well as tabular parts. The tabular parts store the same type of information, number
which may be variable, for example, description of product components, composition
employee’s family, organization phone numbers, etc.
For each directory, several types of forms can be specified: element, group,
list, selection, group selection. For each type of form, you can create an arbitrary
number of forms.
To describe subordinate entities, you can use subordinate directories. In this case, in the subordinate directory, each element “belongs” to a specific element of the owner directory.
In a specific configuration, the required number of directories is created to store data about objects used in the automation of a given subject area. For example, these could be directories of Organizations, Products, Employees, etc.
Transfers
Enumerations are used in the 1C:Enterprise system to describe permanent
sets of values that do not change during the configuration process.
At the configuration stage, you can describe an almost unlimited number of types of enumerations. Unlike the directory, the values of enumerations are set at the configuration stage and cannot be changed at the execution stage.
Typical examples of transfers are types of payment (cash, non-cash,
barter), client status (permanent, one-time), etc.
One of the main features of enumerations that distinguishes them from directories is
that the set of enumeration values does not change when the end user interacts with
program. For example, a configuration algorithm may be designed to
Each client has one of two statuses - either permanent or one-time. In that
In this case, the client status is indicated by selecting one of the values
transfers. The user cannot add a new status.
Unlike enumerations, for directories specific values are usually entered
by the user when working with the program, for example: names of goods, contractors, etc.
Documentation
Documents are intended to reflect the economic events of the enterprise, which
are related to the subject area being automated. For example, in the configuration,
intended for recording trade transactions, there may be documents such as an invoice,
receipt invoice, expenditure invoice, etc. With the help of documents, we reflect and
payments from the current account, and cash register transactions, and movements in the warehouse, and others
similar events.
During the configuration process, an arbitrary number of document types is configured.
Typical examples of document types are Payment Order, Invoice, Receipt Note, Expenditure Note, Internal Movement Note,
Receipt cash order and others. Each type of document is designed to reflect
its type of event. This determines its structure and properties, which are described in
configurations.
Each type of document can have an unlimited number of details and tabular
parts. Several tabular parts are required in cases where one document
it is necessary to register essentially different but related events, for example: reflect
receipt of goods at the warehouse and register additional costs incurred –
payment for transport, loaders, etc.
Input forms are created for the document - screen analogues of real documents. If in
other forms use document data, then to include this information
Forms for selection are being developed. To view a list of documents of the same type
list forms are created. The number of forms is unlimited. Each document also
can have an unlimited number of printed forms.
All documents are identified by number, date and time. When setting up a document, you also specify the length of the document number, conditions for maintaining unique numbers, and others.
Documents play a central role in the core mechanisms implemented by the system.
All documents form a single chronological sequence. In fact she
reflects the actual sequence of events. Sequence inside date
documents are determined by their time, while the time of the document is not so much
a means of reflecting the real (astronomical) time of document entry, how long
a tool that allows you to clearly organize documents within one date. Data,
entered into the document (in details and tabular parts of the document), usually contain
information about the event that occurred: for example, in the invoice - information about
what warehouse, what goods and how many shipped, what additional costs
made when purchasing goods.
For a document, a very important action is its implementation. If the document is not
is "conducted", meaning that the event it reflects does not affect
the state of accounting maintained in this configuration. If the document is carried out, then
it changes the state of certain data taken into account. When holding a document
can reflect the event recorded by him in mechanisms implemented by various
registers.
For example, in a trading company, issuing an invoice to a client for payment does not change
the state of the commodity or cash assets of the enterprise, since the account in this case is
it is only an expression of the customer's intention to purchase the product. In this case, in
configurations for recording trade transactions, the Account document may not be reflected in
accounting registers.
However, if the issuance of an invoice is accompanied by a reservation of goods for a given client, then in this case the Invoice document must be reflected in the accounting registers, since the operation of issuing an invoice also “freezes”, temporarily removes a certain number of goods from circulation. In this case, the trade accounting configuration must be able to track the reserved item.
Document logs
Document journals are designed to view documents of different types. Each type of document can be shown in several journals. The document journal does not add new data to the system, but is a means for displaying several types of documents in a single list.
For example, a Warehouse Documents journal can be created, which will display all incoming and outgoing invoices and invoices for internal movement.
For a log, log columns can be defined for displaying
details of documents of various types related to this journal. For example, a magazine
trade documents may contain a Counterparty column, which will reflect
details Document committee Admission to the commission, details Organization of the document
Receipt invoice, etc.
Each magazine can have an unlimited number of forms of visual presentation and
printed forms.
Reports and processing
To describe reports and information processing procedures at the configuration stage
An unlimited number of reports and processing can be created. Reports and processing can have several forms intended, for example, for entering report generation parameters or data processing parameters. For example, to issue a warehouse certificate, select a specific warehouse.
The algorithm for obtaining a report can be described using a built-in language or generated automatically by the system if a data composition system is used. Both text format and specialized tabular report format (layouts) can be used to output reports.
The system also supports the ability to develop external processing that is not stored
in the configuration itself, but in separate files.
Characteristic type plans
In the 1C:Enterprise system, the Plans of characteristics types objects are intended for
descriptions of sets of similar analytical accounting objects.
Calculation type plans
Objects of this type are intended for creating types of calculations used in
mechanisms of periodic settlements.
Charts of accounts
The chart of accounts is one of the basic concepts of accounting. Chart of accounts
is a set of synthetic accounts intended for grouping
information about the economic activities of the enterprise. Information accumulated on
such synthetic accounts allows you to get a complete picture of the status of funds
enterprises in monetary terms.
Exchange plans
Objects of this type are designed to organize data exchange between
various information bases, as well as information bases and external
software systems.
Business processes and tasks
Allows you to create formalized descriptions of typical work sequences,
performed in the organization, and on their basis create lists of tasks that
must be performed by one or another employee of the organization at the moment.
For example, the process of selling a product can be represented as a sequence
issuing an invoice, approving it, receiving cash payment and shipping goods from the warehouse.
Different employees may be responsible for each step. Thus, in
At any point in time, you can determine the state of the product sales process and which employee currently needs to perform any actions.
Registers
Registers are designed to store and process various information reflecting
economic or organizational activities of an enterprise and not having an objective nature.
Registers usually store information about changes in object states or other
information that does not directly reflect the objects of the subject area. For example, in
registers can store information about exchange rates or information about receipts and
consumption of goods.
There are 4 types of registers in the 1C:Enterprise system:
● information registers,
● accumulation registers,
● settlement registers,
● accounting registers.
Specialized configuration objects ("General" branch)
In addition to objects describing the subject area of accounting, the configuration contains a number
auxiliary objects that are not directly related to the activities of the enterprise, but are closely related to the functioning of the system itself. These are mechanisms for user interaction with the 1C:Enterprise system (command interface, selection criteria, access rights of various user groups to various
information); auxiliary objects for design purposes, allowing
perform configuration based on the generated styles; picture libraries taking into account the national language; application module and general modules in which
procedures and functions available from other configuration modules are located; general layouts of printed forms and much more.
The “Directory” configuration object is an application object and is designed to work with lists of data. The “Directory” configuration object is used so that on its basis the platform creates an information structure in the database in which, for example, a list of employees, a list of goods, a list of clients or suppliers will be stored.
The directory consists of elements. A characteristic feature of the “Directory” configuration object is that the user can independently add new elements during the work process: for example, add new employees, create a new product or add a new client.
Each directory element usually contains some additional information that describes it in more detail. The set of such information is the same for all elements of the directory, and to describe such a set, the details of the “Directory” configuration object are used, which, in turn, are also configuration objects. Because these objects are logically related to the Directory object, they are called subordinate objects. The developer creates most of the details of the “Directory” configuration object independently, however, each configuration object has two “default” fields: “Code” and “Name”.
In addition, each element may contain a certain set of information, which is the same in structure, but different in quantity, intended for different elements of the directory. To describe such information, tabular parts of the “Directory” configuration object, which are subordinate configuration objects, can be used.
For ease of use, the directory elements can be grouped by the user according to some principle. The ability to create such groups in the directory is specified by the Hierarchical property of the “Directory” configuration object. In this case, the directory element, which is a group, will be the parent of all elements and groups included in this group. This type of hierarchy is called a hierarchy of groups and elements.
Another type of hierarchy is also possible - the hierarchy of elements. In this case, the parent is not a group of directory elements, but one of the directory elements itself.
Elements of one directory can be subordinated to elements or groups of another directory. In the 1C: Enterprise system, this is achieved by specifying a list of directory owners for each “Directory” configuration object.
Sometimes situations arise when it is necessary for some elements to always exist in the directory, regardless of user actions. The “Directory” configuration object allows you to describe any number of such directory elements. These are called predefined directory elements.
Depending on what actions we want to perform with the directory, we need to display the directory in “different views”. For example, in order to select a certain element, it is more convenient to present the directory in the form of a list, and in order to change some element, it is more convenient to present all the details of this directory element on one form. Therefore, the “Directory” configuration object can have an arbitrary number of forms, some of which can be designated as main ones.
“Form” is used to “visualize” the data in the database. It presents this data in a user-friendly form and allows you to describe the algorithms that will accompany the user’s work with the data shown in the form.
Any form can be described in the configurator. To create such a description, there is a subordinate configuration object “Form”. As a rule, it is subordinate to one of the application objects, but it can exist independently. Based on the description contained in the “Form” configuration object, at the right moment of the user’s work, the 1C: Enterprise platform will create a “Form” software object with which the user will work.
Now let's create several such objects to describe the directories that will be used in our database.
First, we need a list of company employees who will make up the organization’s production staff. Then we will need a list of departments and positions available in the enterprise. After this, we will need a list of finished products that are sold externally by the company.
Let's start with one of the simplest directories - the "Positions" directory. Let’s open the configuration being developed in the configurator and create a new configuration object “Directory”.
The task is to create a directory in which a list of positions will be stored.
After clicking “Add”, the system will open a window for editing the configuration object.
This tool was created to help the developer. It is designed specifically for complex configuration objects and allows you to quickly create such objects by performing sequential actions. In order to follow the correct sequence of actions, there are “Next” and “Back” buttons at the bottom of the window. The “Next” button allows you to set the properties of the object in the desired sequence, so as not to miss anything and not skip ahead where data that should have been entered earlier is required. The “Back” button allows you to go back a few steps if you discover that you have previously entered incomplete or incorrect data.
Let’s set the name of the directory – “Positions”. The name is the main property of any configuration object. When a new object is created, the system automatically assigns it a name. You can use the name assigned by the system, but it is better to replace it with your own user-friendly name. You can set any name, as long as it starts with a letter and does not contain some special characters (for example, a space). To make configurations easier to read, it is customary to make intuitive names, and if they consist of several words, remove spaces between words and start each word with a capital letter.
Based on the name, the platform will automatically create a synonym - “Positions”. Any configuration object also has the “Synonym” property. It is intended to store an “alternative” name of the configuration object, which will be used in program interface elements, that is, will be shown to the user (Fig. 4.1).
Fig.4.1. Directory "Positions". “Basic” tab
Therefore, there are practically no restrictions on the synonym, and it can be specified in a form familiar to humans.
For this reference book, all properties of the configuration object offered by the program fully satisfy the task. Therefore, click “Next” three times and find yourself on the “Data” tab.
What is of interest to us here is the length of the code and the length of the name. Code length is an important property of a reference book. As a rule, a directory code is used to identify directory elements and contains values unique to each directory element. The platform itself can control the uniqueness of codes and support automatic numbering of directory elements.
The platform itself can track the uniqueness of codes, so the number of elements contained in the directory will depend on the length of the code. Code length – 9 characters. As a result, you can use codes from 1 to 999999999 - that’s enough.
Let's move on to the length of the name. 25 characters are clearly not enough, let’s increase the length of the name to 150 (Fig. 4.2).
Fig.4.2. Directory "Positions". “Data” tab
We will leave all other properties of the “Directory” configuration object as they are offered by the system by default, and click “Close”.
According to the same principle, namely, without any special features, the directories “Items of Expenses” and “Movement of Cash” are created.
The “Employees” directory will be somewhat more complex than the “Positions” directory. The fact is that it will store not only the employee’s last name, first name and patronymic, but also information about his past work activity. This information is homogeneous in its structure (organization, start, end of work, position held), but the number of previous jobs may vary for different employees. Therefore, to store such information we will use the tabular part of the directory.
Let's create a new configuration object "Directory". Let's call it "Employees". On the “Data” tab, set the code length to 9, code type to String, and the length of the directory name to 150 characters. Let's assign the necessary details to the directory:
Last name – type String, length 100;
Name – type String, length 100;
Middle name – type String, length 100;
Date of Birth – type Date, date composition – Date;
Salary – type Number, length 10, accuracy 2;
And we will add a new tabular part to the directory with the name “Labor Activity”. Let’s create the details of the “Labor Activities” tabular section (Fig. 4.3):
Start of Work – type Date, date composition – Date;
Completion of Work – type Date composition of dates – Date;
Organization – type String, length 100;
Fig.4.3. Directory "Employees". “Data” tab
Now we should select the option to edit the directory. Obviously, editing in the list will no longer work for us, since in the list we will not be able to edit the tabular part of the directory and enter information about work activity.
Therefore, in the “Employees” directory, we will select the option to edit the directory in both ways – both in the list and in the dialogue. To do this, go to the “Forms” tab and set the appropriate switch. Also on this tab we will set the Basic Forms directory (“ListForm”, “SelectionForm”, “ElementForm”) (Fig. 4.4):
Fig.4.4. Directory "Employees". “Forms” tab
The creation of these forms (Fig. 4.6 - 4.9) is necessary in order to make changes in them, which in user mode will facilitate the visual perception of the directory and thereby speed up the user's work.
Also, this directory will have one more feature, namely, the owner will be determined for it - the “Divisions” directory (Fig. 4.5). This is necessary so that during the subsequent calculation of wages, which occurs in the context of individual structural divisions, it is more convenient for the user to select employees assigned to these divisions.
Again, to achieve the goal described above, it is necessary to transform the “Selection Form” of the “Employees” directory by adding an input field to it, which is subsequently used to select the department of interest to the user and display a list of employees working in it. To do this, it is necessary to make certain changes and additions to the properties of objects (Fig. 4.7 – 4.8).
Rice. 4.5. Directory "Employees". Owners tab
Rice. 4.6. Directory "Employees". List Form
Rice. 4.7. Directory "Employees". SelectionForm. Subdivision
Rice. 4.8. Directory "Employees". SelectionForm. Table field
Rice. 4.9. Directory "Employees". ItemForm. Basic data
As can be seen from the last fig. 4.9, a panel with several pages has been added to the Element Form, each of which contains certain information. Also in Fig. Figure 4.9 illustrates the first page “Basic Data”, which is filled out when a new employee is admitted to the organization. All details assigned to the Directory are used here. The next page “Labor activity” is called so due to the fact that the previously created tabular part is located on it (Fig. 4.10).
Rice. 4.10. Directory "Employees". ItemForm.
Labor activity
Next, let’s look at the “Document” page (Fig. 4.11), which will be used to select the documents “Order for Hiring for Work” and “Order for Promotion” according to the “Employee” detail. To do this, a “TableField” control element was placed (value type – “Selection CriteriaList.Employee”. In addition, “DirectoryObject.Link” was selected in the “Link by selection value” table field property).
Fig.4.11. Directory "Employees". ItemForm. Documentation
The “Layout” configuration object is designed to store various forms of data representation that may be required by some configuration objects or the entire application solution as a whole. A layout can contain a tabular or text document, binary data, an HTML or Active Document, a graphical or geographic diagram, a data composition diagram, or a data composition diagram design layout. Layouts can exist either by themselves (general layouts) or be subordinated to a configuration object.
One of the purposes of a layout subordinate to a configuration object and containing a spreadsheet document is to create a printed form of this object.
Creating a printed form consists of designing its component parts - named areas, from which the finished printing form is then “assembled”. The order of filling areas with data and the order of outputting them to the final form is described using a built-in language.
The printed form can include various graphic objects: pictures, OLE objects, diagrams, etc.
In addition to creating a layout manually, the configurator provides the developer with the opportunity to use a special tool - a print designer, which takes care of most of the routine work on creating a layout.
A Directory configuration object can have a Layout. Let’s create a “Print form” for the reference book in question, so that when you click the “Print” button in user mode, you can get a beautifully designed list of employees for the working date. On the “Layouts” tab, using the print designer, we will create a “Print” layout (Fig. 4.12).
Rice. 4.12. Directory "Employees". Layouts tab
After design, the layout will look like this (Fig. 4.13):
Rice. 4.13. Directory "Employees". Printable form
In order for the list to be generated on the working date, changes were made to the List Form module (Fig. 4.14), which contains the “Print” button, when clicked in user mode, a list of employees will be obtained.
Rice. 4.14. Directory "Employees". Print button module
in List Form
When accepting a new employee, it is necessary not only to enter information into the program directory for further use, but also to draw up a document “Order for Hiring” in the unified form No. T-1 (more details about the documents will be discussed in paragraph 4.2). To ensure that the user does not have to re-enter the same information, we will set on the “Input based on” tab that this directory will be the basis for entering the specified document (Fig. 4.15).
Rice. 4.15. Directory "Employees". Tab "Input based on"
Also, if the user needs to find out more detailed information about a specific employee, then he will be able to obtain the necessary data by selecting the employee in the list and clicking the “Open in detail” button. To do this, we will create the mentioned button and write the following procedure in the ListForm module (Fig. 4.16).
Rice. 4.16. Directory "Employees". Button module
“OpenDetails” in the ListForm
The creation of the “Employees” directory is completed.
Consider the following directories “Divisions” and “Finished Products”. It is not for nothing that they stand in the same row, which will be explained below.
One of the features of the “Divisions” directory is that it is hierarchical, that is, we will group the divisions of an organization due to its organizational structure. This is done to make the reference book convenient to use. To accomplish this task, when creating a directory, let’s go to the “Hierarchy” tab and set the “Hierarchical directory” flag (Fig. 4.17).
Rice. 4.17. Directory "Divisions". Tab "Hierarchy"
Now we will explain the connection between the directories “Divisions” and “Finished Products”. It is determined by the subordination of the latter to the “Divisions” directory. Since the main task is the automation of payroll for production personnel, the main production shops will be considered as the main departments. Each division in the enterprise produces its own type of finished product, therefore, when maintaining analytical accounting in the future, it is necessary, when choosing the appropriate division to which the employee is assigned, to select the type of finished product. Since the product range can be widely diversified, it will be more clear if, when defining a division, a list of products related directly to the specified division is immediately displayed.
To do this, when creating the “Finished Products” directory, you must, just like the “Employees” directory, indicate the owner - the “Divisions” directory.
And in the “List Form” of the latter, add two table fields (Fig. 4.18) and set the following properties for it (Fig. 4.19):
Rice. 4.18. Directory "Divisions". "ListForm"
Rice. 4.19. Properties of the "Products" table field
At this point, the creation of these directories is completed, and let’s see how the established relationships will look in user mode (Fig. 4.20).
Rice. 4.20. Directory "Divisions" in user mode
Also, the property of subordination is inherent in another directory, “Information About Employees.” Only in this case, the owner is not another directory, but a configuration object such as “Plan of characteristics types” with the same name “Information About Employees” (Fig. 4.21).
Rice. 4.21. Directory "Information about Employees". Owners tab
And let’s look at the remaining two directories “Personal Income Tax Dimensions of Deductions” and “Units of Measurement”, which are united by another feature that is not inherent in the previously illustrated directories, namely the presence of predefined elements. We will demonstrate the creation of such elements for the first directory, which plays a significant role in the implementation of the task, since the personal income tax (or the abbreviation personal income tax), to which Chapter 23 of the Tax Code of the Russian Federation is dedicated, is directly related to wages. In this case, the employee has the right to reduce the amount of tax levied on his earnings by the amount of deductions. Since the deduction data is valid for all enterprises, so that the user does not have to enter them independently and so as not to accidentally delete or change any, we will set these deductions as predefined elements of the directory (Fig. 4.22).
Rice. 4.22. Directory "Personal Income Tax Amounts of Deductions". Predefined elements
In user mode, an “amber ball” will appear next to the picture, which will indicate that these elements are predefined.
Thus, all reference books and their inherent features were reviewed.
I rarely write, but that’s okay. I keep fighting, chapters 7 and 8.
What is the purpose of the Report configuration object?
The report configuration object is used to describe the algorithms with which the user can obtain the output data he needs.
How to create a report using the Data Composition Schema Designer?
In the configurator, select the “Reports” option, right-click the mouse and select the “Add” command. On the "Basic" tab, select the "Open data composition diagram" button
Next, click the “Add Data Set” button. Here you can select a query, object, or union as a data set.
The request goes through the request console. On the “Settings” tab, you control the output of report data; here you need to check the “selected fields” box.
In fact, I’ll be honest, I don’t like this “data composition system” at all. It’s much easier to work with code, simpler and clearer, honestly.
How to display a report in sections of an application solution?
Right click on the report - "Subsystems" tab
Lesson 8
What is the purpose of the layout configuration object?
The layout configuration object is designed to store various forms of data representation that may be required by some configuration objects or the entire application solution as a whole; One of the purposes of a sub-layout is to create a printed form of that object;
What is a print designer?
The print designer is a tool for creating printable forms (although in fact it is more convenient not to use the designer)
How to create a layout using the print designer?
Select the configuration object that needs a layout (this can be a document, a report, external processing), right-click on it, the “Edit” command, the “Layouts” tab, the “Print Designer” button.
We determine what details will be in the header;
We determine which details of the table parts will be displayed;
There will also be an opportunity to fill out the basement of the printed form.
How to change a spreadsheet document?
Resizing cells occurs similarly to Excel, and other properties - right click on the cell, properties, the properties palette will slide out on the right.
What's the difference between filling a spreadsheet document cell with text, a parameter, or a template?
The text is what will be shown on the screen in any case;
Parameter - will be replaced with some value that can be assigned to it (the parameter) using the built-in language. For example, a query can fill a table with an item column. When printing, the table will be displayed line by line, and the Nomenclature column will be unloaded in the place where the Nomenclature parameter was. Naturally, this requires additional work, but I’m too lazy to describe it now.
Template is a text string in which parameter values will be inserted in certain places.
How can I display a new area in a spreadsheet document using the built-in language?
Using the following construction:
RegionAreaName = Layout.GetArea("AreaName");
Before this, you need to create this area on the layout. Select a column or row, right-click, “Properties” command and name the desired area.
How can I change the appearance and behavior of a form?
The appearance of the form changes directly when editing the form, and the behavior of the form - right click on the open form, the properties command. There are a whole bunch of behavior settings in the properties palette
Sometimes I start to blame myself for being so lazy. But I quickly stop - laziness.
Lesson 22 is about roles. And here I’ll even tell you a little funny stories from my practice dedicated to roles (not really).
What is the purpose of the Role configuration object?
The role is intended to organize the interface of the application solution and to differentiate the rights and actions of individual users.
How to create a role using configuration subsystems?
Expand the General branch - right click on Roles (Fig. 1). Next, you can configure restrictions on various configuration objects (Fig. 2)
| Fig.1 |
 |
| Fig.2 |
How to create a list of system users and determine their rights?
On the main command panel, go to Tools – Administration – Users.
A list of users will appear (Fig. 3). You can add a new user by clicking on
On the main tab we write various data about the user, on the “other” tab we provide rights (Fig. 4).
 |
| Fig.3 |
 |
| Fig.4 |
How does 1C: Enterprise authentication differ from operating system authentication?
As the name suggests, when authenticating using 1c, the user is required to enter a login/password directly in the 1c system. In the case of authentication using the operating system, you do not need to enter anything, since 1c will determine under which user the OS is running, refer to its internal list of users, and if it finds the corresponding entry, log in with these rights.
Most often, OS authentication occurs if 1c is virtualized. What does it mean? That the server and clients are physically located not under your nose, but in another place. On your computer you launch a remote connection, which is already connected to 1c.
And now stories from practice. If you are engaged in 1C support, then there are often cases when users complain that such and such a document is not carried out, such and such a report is not generated. This often happens due to the fact that the developers assigned rights to a document to such and such a user, but forgot about the register, which, in fact, reflects the postings of the document. Go to the action log and look at this user, how he processes the document - that inaccessible register will be displayed in the log with the wording “violation of user rights”.
It’s much sadder when developers put restrictions on roles in the code - then you can only use a debugger to see where, when and what kind of rights restriction there is, directly in the module of the required document/report.
Let's get acquainted with the Directory configuration object. You will learn what this object is used for, what its structure is and what basic properties it has. Using practical examples, you will learn how to create directories, describe the most important elements of their structure and fill them with data.
In addition, you will learn about one more configuration object - Form.
In conclusion, let's look at the mechanism for making changes to the configuration and using one of the developer tools - the properties palette.
Configuration object Directory is applied and designed to work with lists of data. The Directory configuration object is used so that, based on it, the platform creates an information structure in the database in which, for example, a list of employees, a list of goods, a list of clients or suppliers will be stored.
The directory consists of elements. A characteristic feature of the Directory configuration object is that the user can independently add new elements to the directory while working: for example, add new employees to the directory, create a new product, or add a new client.
Every directory element, usually contains some additional information that describes the element in more detail.
For example, all elements of the Products directory may contain additional information about the manufacturer, expiration date, etc. The set of such information is the same for all elements of the directory, and to describe such a set, the details of the Directory configuration object are used, which, in turn, are also configuration objects. Because these objects are logically related to the Directory object, they are called subordinate objects. The developer creates most of the details of the configuration object in the Directory independently, however Each Directory configuration object has two default fields: Code and Name.
In addition, each element of the directory may contain a certain set of information, which is the same in structure, but different in quantity, intended for different elements of the directory. For example, each element of the Employees directory can contain information about the composition of the employee’s family. For one employee this will be only the spouse, while for another the family may consist of a spouse, son and daughter. To describe such information, tabular parts of the Directory configuration object, which are subordinate configuration objects, can be used.
For ease of use, the directory elements can be grouped by the user according to some principle. For example, in the Household Appliances directory the following groups can be created: Refrigerators, TVs, Washing Machines, etc. The ability to create such groups in the directory is specified by the Hierarchical property of the Directory configuration object. In this case, the directory element, which is a group, will be the parent of all elements and groups included in this group. This type of hierarchy is called a hierarchy of groups and elements.
Another type of hierarchy is also possible - the hierarchy of elements. In this case, the parent is not a group of directory elements, but one of the directory elements itself. For example, this type of hierarchy can be used when creating a directory of Divisions, when one division is the parent of several others that are part of it.
Elements of one directory can be subordinated to elements or groups of another directory. For example, the Units of Measurement directory can be subordinated to the Products directory. Then, for each element of the Products directory, we will be able to indicate the units of measurement in which this product arrives at the warehouse. In the 1C:Enterprise system, this is achieved by specifying a list of directory owners for each Directory configuration object.
Sometimes situations arise when it is necessary for some elements to always exist in the directory, regardless of user actions. Let's say the logic of business processes at an enterprise is such that all goods first arrive at the main warehouse, and then, as needed, are moved to other warehouses. In this case, the Main warehouse must always exist in the Warehouses directory, otherwise the receipt of goods will be processed incorrectly. The Directory configuration object allows you to describe any number of such directory elements. These are called predefined directory elements.
Depending on what actions we want to perform with the directory, we need to display the directory in “different views”. For example, in order to select some directory element, it is more convenient to present the directory in the form of a list, and in order to change some directory element, it is more convenient to present all the details of this directory element on one form. Therefore, the Directory configuration object can have an arbitrary number of forms, some of which can be designated as main ones.
The following table explains the names of these forms as defined in the configurator.
Table 2.1. Basic forms of the directory
The form serves to “visualize” the data in the database. It presents this data in a user-friendly form and allows you to describe the algorithms that will accompany the user’s work with the data shown in the form.
Any form can be described in the configurator. To create such a description, there is a subordinate configuration object, Form. As a rule, it is subordinate to one of the application objects, but it can exist independently. Based on the description contained in the Form configuration object, at the right moment of the user’s work, the 1C:Enterprise platform will create a Form program object with which the user will work.
