Adding a new user and assigning rights to him. Adding a new user and assigning rights to him Company prices

In this article I will tell you how the “record-level access restriction” configuration mechanism works in 1C:UPP 1.3. The information for the article was collected as of May 2015. Since then, the UPP has not been radically updated, because 1C chose 1C:ERP as its flagship. Still, the UPP works properly in many enterprises, so I am posting the results of my research on RLS in the UPP in this article. It will definitely be useful to someone.

Everything is dry, compressed and without water. How I love))).

Access rights settings.

Scheme of interaction of objects.

In UPP 1.3, access control is carried out by the “Access Control” subsystem from BSP version 1.2.4.1.

Metadata used in the access control system in the UPP:

1. Reference “User Permission Profiles”
2. Information register “Values ​​of additional user rights”
3. Plan of types of characteristics “User Rights”
4. Directory "Users"
5. System reference book “IS Users”
6. Directory "User Groups"
7. Register of information "User settings"
8. Plan of characteristics types “User settings”
9. Enumeration “Types of access objects”
10. Register of information “Purpose of types of access restrictions”
11. Enumeration “Data Areas of Access Objects”
12. Information register “User access rights settings”
13. Session option "Use limit by<ВидДоступа>».

Enable record-level access restrictions.

Record Level Limitation (RLS) is enabled in the interface
“User Administration” -> “Record Level Access” -> “Settings”.

Record-level access is defined through access object types. List of types of access objects (the corresponding directories are indicated in brackets):

• "Counterparties" ("Counterparties")
• "Organizations" ("Organizations")
• “Individuals” (“Individuals”)
• "Projects" ("Projects")
• “Warehouses (“Warehouses (storage places)”)
• "Candidates" ("Candidates")
• Notes (Note Entry Types)
• "Divisions" ("Divisions")
• "Divisions of organizations" ("Divisions of the organization")
• “Nomenclature (change)” (“Nomenclature”)
• "Specifications" ("Specifications")
• “Item prices” (“Item price types”)
• "External processing" ("External processing")

*The list of possible types of access is fixed and is contained in the “Types of access objects” enumeration.

Directory "User Permission Profiles".

Setting up access to infobase objects begins with setting up a user permissions profile.

Profile unites

• a set of roles – access rights to objects
• additional user rights – rights to the functionality of the program.

The result of setting up a profile is an entry in the information register “Values ​​of additional user rights”.
This register is not used in radar configuration.

Additional rights can be recorded for a profile or user. Moreover, if additional rights are configured for a profile and the profile is associated with a user, then additional rights cannot be configured individually for the user.
*The list of rights is listed in terms of types of characteristics “User Rights”

The profile itself in the “roles list” tabular section contains all the roles that are enabled for it. When the composition of profile roles changes, the “Roles” tabular part of all users of the information base (not the “Users” directory) to whom this profile is assigned is refilled.

The connection between the directory “Users” and “Information Base Users” is implemented through the attribute “IB User Identifier” of the directory “Users”, which stores the GUID of the IS user.

The composition of user roles is also not available for editing if the user is assigned a specific profile.

It is possible for the user to specify “User Settings”. These are various service settings for typical automatic system behavior in certain situations.

The result of the settings is recorded in the “User Settings” information register.

The list of settings and their possible values ​​is contained in the “User Settings” characteristic type plan.
*Not used in record-level access restriction settings.

Directory "User Groups".

Used to organize users into groups and, among other things, to configure access restrictions at the record level.

One user can be included in several groups.

In the user group form, you can configure a list of access types.

Record-level object permissions are configured only for user groups, not individual users.

If your configuration uses record-level access restrictions, then each user must be included in one of the groups.

IMPORTANT! Users who are not included in any group will not be able to work with those objects whose access is determined at the record level. This applies to all objects - regardless of whether the corresponding access object types are used or not.

If a user is a member of several groups that have different access rights settings at the record level, then the availability of an object for the user will be determined by combining the settings from several user groups using “OR”.

IMPORTANT! Including a user in a large number of groups can lead to slow performance. Therefore, you should not include a user in a large number of groups.

After recording changes to a user group, the Information Register “Assignment of access restriction types” will be filled in. This register stores records of compliance with a user group for a certain type of access.

*Case is used in access restriction templates

“Access Settings” form.

The form for setting access restrictions at the record level is called by the “Access Settings” command of the “User Groups” directory list form.

On the right side of the form, tabs present tables with settings for each type of access, marked with checkboxes in the user group form.

The access rights setting form has a separate form page for each type of access with its own set of settings. The required page is enabled when the access type associated with it is checked in the user group.

Comparison of access types and possible settings:

Type of access	Access type settings
	Reading	Record	Type of access rights inheritance	Visibility in the list	View additional information	Editing additional information	View data	Editing data	Company prices		Counter agent prices
									Reading	Record	Reading	Record
Counterparties
Organizations
Individuals
Projects
Warehouses
Candidates
Notes
Divisions
Organizational divisions
Nomenclature
Specifications
Item prices
External treatments

Access rights.

“Reading” - the user will see the directory item in the list and will be able to open it for viewing, and will also be able to select it from the list when filling out the details of other objects.

“Record" - the user will be able to change:

• elements of some directories - types of access objects (not all - there are exceptions, see below),
• data (documents, registers, subordinate directories) associated with these directory elements

Exception: access to elements of some directories - types of access objects - does not depend on the “Write” right. These are directories: Organizations, Divisions, Divisions of Organizations, Warehouses, Projects. They relate to master data objects, so only a user with the “Master data setup...” role can change them.

For the access object type " Nomenclature (change)"The access right to "record" is defined only at the group level of the "Nomenclature" directory; it is not possible to set the "record" right for individual element reference book.

There is no restriction on access to “reading” the “Nomenclature” reference book and related information, because in general it is unclear what kind of access should be given to a document if the list of nomenclature that is in the document contains both “allowed” and “prohibited” » positions.

The restriction of access for the directories “Divisions” and “Divisions of Organizations” does not apply to information on personnel data, personal data of employees and payroll data.

Data areas.

Data areas are defined for the following types of access objects:

• Counterparties
• Individuals
• Item prices

For the access object type “Counterparties”

• Counterparties (list)— determines the visibility of counterparties in the list of the “Counterparties” directory. Depends on the value of the checkbox in the “Visibility in the list” column.
• Contractors (additional information)— determines the ability to “read”/“write” the directory element “Counterparties” and the additional information associated with it. information (contracts, contact persons, etc.). Depends on the value of the checkbox in the corresponding columns “View additional. information"/"Editing additional information" information."
• Counterparties (data)— determines the ability to “read”/“write” data (directories, documents, registers) associated with the “Counterparties” directory. Depends on the value of the checkbox in the “View data”/“Edit data” column.

For the access object type “Individuals” The following data areas are provided:

• Individuals (list)— determines the visibility of an individual in the list of the “Individuals” directory. Depends on the value of the checkbox in the “Visibility in the list” column.
• Individuals (data)— determines the ability to “read”/“write” data (directories, documents, registers) associated with the “Individuals” directory. Depends on the value of the checkbox in the “View data”/“Edit data” column.

For the access object type “Item prices” The following data areas are provided:

• Company prices—defines the ability to “read”/“write” prices for the company’s items.
• Contractor prices— determines the ability to “read”/“write” the prices of counterparties’ items.

*Data areas are a closed list of elements contained in the “Data areas of access objects” enumeration

Access groups.

For the following types of access objects, rights settings are performed only through access groups (the names of the directory are indicated in brackets):

• “Counterparties” (“Counterparty access groups”)
• “Individuals” (“Access groups of individuals”)
• “Candidates” (“Groups of Candidates”)
• “Item Specifications” (“Purposes of using specifications”)

The access group is indicated for each directory element (in a special attribute).

Access settings from the “access group...” are carried out in an additional form for setting access rights, which is called by one of two commands:

• "Access current items"
• "Access to the directory as a whole"

in the form of a list of “Access groups...” directories

Example: The document “Receipt order for goods” is limited by the types of access objects “Counterparties”, “Organizations”, “Warehouses”.

If you provide access to an empty value for the “Counterparties” access type, the user will see documents in which the “Counterparties” attribute is not filled in.

Access to a directory element or group.

Depending on whether access to a directory element or a group is being configured, the setting affects either the element itself or subordinate groups.

According to this, in the “Setting up access rights” form, in the “Type of inheritance of access rights of hierarchical directories” column, the following values ​​are set:

• Only for current permission– for a directory element, rights apply to the specified element
• Distribute to subordinates– for a directory group, rights apply to all subordinate elements

After recording the access restriction settings for user groups, the “User Access Rights Settings” Information Register will be filled in the system.

*Case is used in access restriction templates.

Using templates.

Templates in UPP 1.3 are written for each type of access separately and for possible combinations of access types, as a rule, for each user group.

For example , in the demo version of UPP, the “Purchases” user group is configured. For this group, the use of access types “Organizations”, “Counterparties”, “Warehouses” is enabled. Accordingly, a number of access restriction templates have been created in the system:

• "Organization"
• "Organization_Record"
• "Counterparties"
• "Counterparties_Record"
• "Warehouses"
• "Warehouses_Record"
• "CounterpartyOrganization"
• "CounterpartyOrganization_Record"
• "OrganizationWarehouse"
• "OrganizationWarehouse_Record"
• “CounterpartyOrganizationWarehouse_Record”
• "CounterpartyWarehouse"
• "CounterpartyWarehouse_Record"

That is, all possible combinations of access types that can be used in access restriction texts.

In general, the template construction scheme is the same for all types of access and looks like this:

1. Checking the inclusion of the type of access being checked.
2. The “User Groups” directory is attached to the main table and it is checked that the user is included in at least one group.
3. The register table “Settings of user access rights” according to connection conditions is attached to the information register “Assignment of types of access values” — The access object is the access value passed to the template parameter. — Type of access object – depends on the context of template development — Data area.— User.

The result of the connection determines whether access is allowed or not.

End of the second part.

All user rights settings that we will make within the framework of this article are located in section 1C 8.3 “Administration” - “User and rights settings”. This algorithm is similar in most configurations on managed forms. The 1C Accounting program will be used as an example, but setting up rights in other programs (1C UT 11, 1C ZUP 3, 1C ERP) is done in exactly the same way.

Let's go to the "Users" section of the settings window. Here we see two hyperlinks: “Users” and “Login Settings”. The first of them allows you to go directly to the list of users of this information base. Before creating a new user, let's look at the possible login settings (hyperlink on the right).

In this settings form, you can configure the password complexity (at least 7 characters, mandatory content of various types of characters, etc.). You can also specify the length of the password, its validity period, and prohibit users from logging into the program if they have not been active for a certain period of time.

Now you can proceed directly to adding a new user to 1C. This can be done by clicking the “Create” button, as shown in the image below.

First of all, we will indicate the full name - “Dmitry Petrovich Antonov”, and select an individual from the corresponding directory. Here you can also indicate the department in which our employee works.

The login name “AntonovDP” was automatically substituted as an abbreviation for the full name “Dmitry Petrovich Antonov”. Let's set a password and authentication for 1C Enterprise. Here you can also indicate whether this user can change their password independently.

Let's say we want Dmitry Petrovich Antonov to be available in the selection list when starting this information base. To do this, you need to set the checkbox on the “Show in selection list” item. As a result, the authorization window when starting the program will look as shown in the figure below.

Let's pay attention to another important setting in the user directory card - “Login to the program is allowed.” If the lag is not set, then the user simply will not be able to enter this information base.

Access rights

After filling out all the data in the user card - Dmitry Petrovich Antonov, we will write them down and proceed to setting up access rights, as shown in the figure below.

A list of access profiles previously entered into the program opened before us. Check the required boxes.

Access Group Profiles

Access group profiles can be configured from the main user and rights setup form. Go to the “Access Groups” section and click on the “Access Group Profiles” hyperlink.

Let's create a new group from the list form that opens. In the tabular section on the “Allowed actions (roles)” tab, check the boxes for those roles that will affect the access rights of users included in the group we are creating. All these roles are created and configured in the configurator. They cannot be changed or new ones created from user mode. You can only choose from the existing list.

RLS: Record Level Access Restriction

Allows you to more flexibly configure access to program data in certain areas. To activate it, check the box of the same name on the user and rights settings form.

Please note that enabling this setting may adversely affect system performance. The point is that the RLS mechanism modifies all requests depending on the established restrictions.

Let’s go to the “Test Group” access group profile we created earlier. The figure below shows that after enabling access restrictions at the record level, an additional “Access Restrictions” tab appeared.

Let's say we want users assigned to a test group to have access to data for all organizations in this infobase, except for those specified in the profile.

In the upper tabular part, we will set access restrictions by organization. In the lower part, we will clarify that access to data (documents, directories, etc.) will not be provided for the organization “Roga LLC”.

21.09.2014

The task is to limit access to information on branches of separate divisions in the ZUP for the personnel officer and the accountant.

Types of access objects will be by organizations and individuals.Setting up access control at the record level

Main menu - Tools - Program settings - Access restriction tab

Since we initially took a clean database, let’s fill it with data.

Let's create organizations with a name.

Central organization

Branch of a central organization (as a separate division)

Second branch of the central organization (as a separate division)

Let's create access groups for individuals:

CO (for individuals of the central office)

CO branch (for individuals of the branch)

Second branch of the CO (for individuals of the second branch)

CO + CO branch (for individuals working in the CO and CO branch)

CO + Second branch of the CO (for individuals working in the CO and the second branch of the CO)

CO branch + Second CO branch (for individuals working in both branches)

Let's create user groups:

CO Group

Group Branch CO

Group of the Second Branch of the Central District

Let me remind you that we set the checkboxes for all types of access objects - Organizations and individuals.

After entering user groups, you can assign them groups of individuals to whom the action will apply.

In case of setting up RLS delimitation in separate branches, you need to know the following point - according to the laws of the Russian Federation, personal income tax and insurance premiums are calculated from the beginning of the year and, most importantly, based on the base of the organization as a whole. This means that the branch accountant, when calculating taxes, must know how much taxes have already been accrued and benefits provided for this individual in all other separate divisions. And this is access to data from all other branches, including the central office.

After this fact, it may seem that it is impossible to properly delimit access to separate branches, but this is not so and here’s why. The developers of the standard ZUP configuration have developed a data structure when, when calculating taxes, the calculation data is always recorded for the branch and the parent organization at the same time, and when calculating for the purpose of calculating taxes in the branch, the data is taken for the parent organization. It turns out that access to all branches is no longer needed, but only to the parent organization. This is already warmer, but firms, as a rule, want to limit the access of branches to the data of the central organization. It would seem that nothing will work out again!

I can confidently assure you that everything will work out! If we take into account the RLS concept, not a single document will be visible if there is at least one object prohibited for the user, i.e. documents of other organizations will not be visible if there is at least one object (individual) prohibited to the user.

Based on the above, we make the following access settings (the “Rights” button) for user groups.

For the central organization

For Group branch CO

For the element “Group Second Branch CO” we also make the following settings:

On the “Organizations” tab - the Central organization and the second branch, and on the individuals tab, all access groups of individuals in which the name of the second branch appears. All flags are cocked.

Let's create users of organizations:

Personnel officer - personnel officer of the central organization

Personnel officer 1 - branch personnel officer

Personnel officer 2 - personnel officer of the second branch

and set all users to the corresponding user groups from the list of users

or we do it in the user group itself

Now let's hire employees.

CO First Employee (central organization)

Branch First Employee (branch employee)

SecondBranchFirstEmployee (employee of the second branch)

Branch_CO FirstEmployee (employee hired at the branch, transferred to the central organization)

Upon acceptance, we assign access groups to individuals

CO First Employee - “CO”

Branch First Employee - “Branch Central Office”

SecondBranchFirstEmployee - “Second Branch of the Central Organ”

Branch_CO First Employee - “CO + Branch CO”

All employees were hired on 01/01/2014, and from 09/01/2014 the employee of “Branch_CO First Employee” was transferred from the branch to the central office.

We open the journal “Human Resources Accounting for Organizations” under an administrator who is not subject to RLS restrictions and see all the documents

We open the list of employees and see only two employees selected according to the restriction setting.

We open the “Organizational Personnel Accounting” journal and see 3 documents selected according to the restriction setting.

Login under the user Kadrovik1

We open the list of employees and see only “our” employees.

The journal “Personnel Accounting for Organizations” also contains only “their own” personnel documents.

Login under the user Kadrovik2

A list of employees

Magazine "Personnel Accounting of Organizations"

The RLS distinction operates in the same way with regard to calculated information, but I will not give examples here.

That's it, the task stated in the title is completed - users see only “their” documents.

Also, you can familiarize yourself with the nuances of writing queries when setting delimitation

At the record levelin my article "Using the Allowed directive"

In the subsystem " Access Control", included in the BSP, access settings to data at the record level of database tables (RLS) carried out using two directories - " Access Group Profiles" And " Access groups". User roles are configured through the first directory, while RLS can be configured through both directories mentioned above - at the choice of the database administrator.

I would like to note that the subsystem has the ability to differentiate access to data both elementally and by a set of elements combined together according to some characteristic. As an example, let's take the directory " Individuals", the ability to configure RLS for which is available in almost all standard configurations, and is done using a special reference book" ". For each directory element " Individuals"It is possible to indicate in its details" Access group"the corresponding element from the directory" Individual access groups", after which for each user (or group of users) the corresponding access group of individuals available for work is indicated. Thus, the directory " Individuals" acts as a subject of access restriction (almost any system object can act as such), and the directory " Individual access groups"as a means (tool) of delimiting access to an object.

Now let's move on to the fact that let's say we needed to organize access restrictions to some configuration object according to a certain criterion, but there is no ability to configure such restrictions in the program. As an example for consideration, let's take a typical configuration " Enterprise accounting 3.0"(BP), which includes a subsystem" Access Control", and in which there is no ability to configure RLS using the directory " Counterparties". Before making changes to the configuration I would also like to make a reservation - the changes made depend on the version of the BSP used in the configuration, but the principle remains the same. The article in question uses BSP version 2.2.2.44.

And so, the sequence of our actions in the configurator, the purpose of which is to implement the ability to configure the RLS configuration according to the directory " Counterparties" (in our case, subject to access restrictions), will be as follows:
1. Filter the configuration metadata tree by subsystem " Standard subsystems" - "Access Control".
2. Through the configuration support setting (if the support mechanism is used), enable the ability to change the following configuration objects:
A. Configuration root.
b. Directory " Counterparties".
V. Defined type " AccessValue".
d. Subscription to the event " ".
d . General module " ".
3. Add a new directory to the configuration " Contractor access groups".
4. Add to the directory " Contractors"new props" Access Group"reference type to our new directory.
5. For a defined type " AccessValue"include references to directories in the composite type" Counterparties" And " Contractor access groups".
6. To subscribe to an event "UpdateAccessValueGroups "also indicate reference book as a source" Counterparties".
7. Open the shared module "Access ControlOverridable " and insert the code fragments below into three of its procedures.
8. From the role " Changing Group MembersAccess" copy RLS templates with names to the role you need (or roles that determine access to the directory) ByValues" And " ByValuesExtended". Set your roles to use one of the templates according to the required right (for example, " Reading"), as shown in the screenshot below.
9. Run the configuration in " mode Enterprises"with launch parameter" LaunchInformationBaseUpdate" (or call the export procedure " UpdateSettingsAccess Restrictions"common subsystem module" Access ManagementService").

Let's pay attention to a rather important point: you may need to add more lines of code to the last procedure if you plan to restrict access not only to the directory "Counterparties", but also to any other configuration objects associated with this directory, for example, to restrict access to documents "Sales of goods and services"by props" Counterparty" - in this case, the subject of access restriction is a document, and a reference book "Counterparties"is a criterion for restricting access to an item using a directory delimiter tool"Contractor access groups".

Procedure When Filling in Access Types (Access Types) Export Salary Personnel. Access Management Fill in Access Type Properties (Access Types); // +Our insertionAccessType =AccessTypes.Add(); AccessType.Name = "Account Groups"; // name of the access type (used in roles for RLS) AccessType.Presentation = NStr("ru = "Groups of counterparties""); AccessType.ValueType = Type("DirectoryLink.Counterparties"); // access restriction criterion AccessType.ValueGroupType = Type("DirectoryLink.AccessGroups of Counterparties"); // access restriction tool // - Our insertion End of Procedure Procedure When Filling in the Use of Access Type (Name of Access Type, Use) Export Salary Personnel. Access Management Fill in Use of Access Type (Name of Access Type, Use); // +Our insertion If AccessTypeName = "Contractor Groups" Then Use = True; endIf; // -Our insertion End of Procedure Procedure When Filling in Types of Limitations of Rights of Metadata Objects (Description) Export // + Our insertion // indicating the rights of metadata objects that are covered by RLS Description = Description + " | Directory. Counterparties. Reading. Counterparty Groups | Directory. Counterparties. Change. Counterparty Groups | "; // -Our insertion EndProcedure

After completing the information security update in the program, you must do the following:
1. Fill out the directory you just added to the system " Contractor access groups".
2. Udirectory elements " Counterparties"fill in the required details" Access group".
3. In the directory " Access Group Profiles"(or in the reference book" Access groups") on the " tab Access restrictions"properly configure RLS by counterparty access groups (the screen below shows users to whom the profile is assigned" Our new access profile", will work in the directory only with counterparties included in access groups " Wholesale" And " Are common").
4. It may be necessary to provide in the configuration a mechanism for automatically filling in the details " Access group"for new directory items" Counterparties" (in order to facilitate its administration).

Summary: Using the "subsystem" Access Control"from the BSP makes it possible to manage RLS for any configuration objects, while operating at least two standard directories" Access Group Profiles" And " Access groups". Expansion of RLS configuration capabilities is provided with minimal changes to the subsystem. In the event that the criterion (or subject) for restricting access rights is large and is constantly expanding (for example, a directory " Counterparties"), then it is possible, through your additional directory (delimitation tool), to divide the criterion (or subject) of access into certain areas ( in our case via "Contractor access groups"), otherwise the directory elements themselves can be used as an access delimiter (and it makes sense) (for example, in the directory " Organizations"). An undeniable advantage of using the subsystem is also the unification of the administration of access rights in the information base.

Vladimir Ilyukov

Rights, roles, access group profiles and access groups allow you to configure user rights in 1C Enterprise 8.3. User rights in 1C 8.3 are a set of actions that he can perform on directories, documents, reports and settings. It is very important to understand these concepts if several users will work with the program and each of them needs to be assigned the appropriate rights.

The article describes how to correctly distribute rights between users of the 1C ZUP 3.1 program so that each of them can work within the framework of their competence and job descriptions. The material in this article does not require any special computer knowledge.

Profiles and access groups in 1C ZUP 3.1

To differentiate access rights in 1C Enterprise 8.3, “Rights”, “Roles”, directories “Users”, “Access Groups” and “Access Group Profiles” are used.

Right and Role

Rights and roles are certain allowed actions (Reading, Viewing, Deleting, Carrying out, etc.) over constants, directories, documents and other configuration objects. Each right represents a unit of action from a list of possible ones. The minimal integrator of rights is the role. Each role consists of a set of specific rights. Rights and roles are created in the configurator. The user cannot change their composition.

As in previous versions of 1C Enterprise 8, a user can be registered in the configurator mode and assigned the necessary roles there. However, 1C ZUP 3.1 provides about several hundred available roles (in the user card they are listed on the “Other” tab: “Configurator > Administration > Users”).

With so many roles available, it can be very difficult to navigate. In addition, for the uninitiated, many role titles mean little. In such a situation, selecting roles in the configurator for the user is a very labor-intensive task. However, at the user level in 1C ZUP 3.1 it is easily solved using the “Access Group Profiles” and “Access Groups” directories.

Reference book “Access group profiles”

Each element of the Access Group Profiles directory is a role integrator. The link to this reference is located at “Administration > Configure Users and Rights > Access Groups > Access Group Profiles.” The developers have already described the most popular profiles in it.

• Administrator,
• Timekeeper,
• Personnel officer,
• Calculator, etc.

You can create your own profiles in the directory, but in most cases this is not necessary. Predefined profiles already contain the necessary sets of roles allowed for them (allowed actions). Note that the timekeeper has a minimum set of permitted actions. But even to describe it, it took about 50 roles, a drawing.

Elements of the “Access Group Profiles” directory are set as a suitable value in the “Profile” attribute of the “Access Groups” directory.

Directory "Access groups"

The meaning and purpose of this directory is that it lists the users (participants) who will have all the rights of the access group profile assigned to it.

To open this directory, follow the links “Administration > Setting up users and rights > Access groups > Access groups”. One access group called “Administrators” is preinstalled in it. The rest are created as needed by users with full rights.

The same “Access Group Profile” can be assigned to different “Access Groups”. In contrast, any “Access Group” can have only one “Access Group Profile”. In many cases, it is convenient to indicate the name of the access group profile assigned to it as the name of the access group, figure.

On the “Group Members” tab, you need to list users from the directory of the same name. When selecting, you should be guided by the fact that the access group usually corresponds to the job responsibilities of its members. The higher the position, the more rights. Any access group can have an arbitrary number of participants, picture.

The relationship between the described configuration objects is clearly illustrated in the following figure.

In general, the same user can be a member of several access groups.

Description of access group profiles in 1C ZUP 3.1

From the above it follows that a user's rights are determined by the profile of the access group of which he is a member. It remains to figure out how the access group profiles differ from each other. For example, from the name of the 1C ZUP 3.1 profiles it is not clear how exactly their roles differ.

• Personnel officer (without access to salary).
• Personnel officer.
• Calculator.

Unfortunately, their descriptions are not given in the configuration. Judging by the name, we can assume that a user with the profile “Human Resources Officer,” as opposed to “Human Resources Officer (without access to salary),” has some kind of access to salary. But to what extent is not at all clear. Another question: does the accountant have the right to work with personnel documents?

For those who have it, you can read the description of access group profiles given by 1C. It is published, but it is very short. The author's article provides a more detailed description of access group profiles. At the same time, in order not to distort the descriptions given by 1C, they are marked in the article with a special font.

Administrator

A user with the “Administrator” profile has the right to perform everything that is provided for by the standard functionality. To do this, such a user must have the “Administration”, “System Administrator” and “Full Rights” roles enabled.

Auditor

View all program data, but without the ability to change them, 1C.

All sections are available for viewing by the auditor except for the “Administration” section. It can view personnel and payroll documents and generate reports. The auditor only has the right to review regulated reporting. The “Settings” section is also visible to the auditor, but here he can only view existing settings.

Typically this profile is included in the auditors access group. At the same time, it is advisable to include it in the access group of those managers of the organization who, due to their official duties, need the data of this program, but they do not know how to work with it or should not.

Timekeeper

Viewing and changing time tracking documents, 1C.

Links to journals that contain documents regarding changes in time recording are located in the “Salary” and “Settings” sections. The “Salary” section contains two links: “Tables” and “Individual work schedules”, figure.

The timekeeper has the right to view other objects, but he will not be able to change them. Personnel documents contain information about planned accruals. However, they are not displayed to the timekeeper and he cannot see them. For example, in the document “Hiring” he will see only two tabs “Main” and “Employment Contract”. The “Payment” tab will not be displayed, figure.

The timekeeper has the ability to generate some personnel reports and the “Working time sheet (T-13)” report.

Personnel officer (without access to salary)

It differs from the personnel officer in that viewing and changing the planned payroll is not available, 1C.

HR staff without access to salaries are deprived of the opportunity to view planned accruals and the method of calculating advance payments. They also cannot print the acceptance order, since it displays accruals. However, unlike a timekeeper, personnel officers without access to salaries can create new and adjust existing personnel documents.

In addition, “HR Officer (without access to salary)” has the ability to generate all “HR reports” and edit the “Individuals” and “Employees” directories. But he does not have the rights to edit the directories “Organizations”, “Units”, “Positions” and those related to military registration.

The “HR Personnel Officer (without access to salary)” profile is intended for those users who should not see planned accruals (salaries, allowances, etc.).

Personnel officer

View and change information about employees in terms of personnel records, including planned payroll, as well as personnel documents. View directories of enterprise structure, 1C.

The “Human Resources Officer”, in addition to the rights that the “Human Resources Officer (without access to salaries)” has, has the right to assign, add and change planned accruals and drawings in the HR registrars.

That is, “Kadrovik” has the opportunity not only to see planned accruals, but also to change them. This profile is advisable to use where there is no secret about employee accruals.

Senior personnel officer

It differs from a personnel officer in that he can change enterprise structure directories and personnel records settings, 1C.

The “Senior Personnel Officer”, in addition to the rights that the “Human Resources Officer” has, has the ability to edit the directories “Organization”, “Divisions”, “Positions” and directories related to military registration. In addition, senior personnel officers have the right to change the staffing table.

Regarding access to the objects listed below, the following can be noted.

• Setup > Organizations. All details are available for editing except for the “Accounting Policy” form.
• Settings > Accruals
• Setup > Holds. Can be viewed without editing rights.
• Settings > Initial data entry templates. Can be viewed without editing rights.

Calculator

Viewing and changing documents for calculating and paying salaries, contributions, information about employees (in the part that affects calculations), 1C.

A user with the “Calculator” profile has the ability to view personnel documents without the ability to edit personnel information. But he has the right to change the planned accruals in them. For example, the salary set by the personnel officer can be changed or added by the calculator to some other planned accrual.

The accountant cannot create personnel documents independently. But he has the right to set a new or change the existing work schedule for the list of employees.

• "Setup > Organizations".
• "Setup > Payroll".
• “Settings > Accruals”.
• "Setup > Holds."
• “Settings > Initial data entry templates.”

In other words, the calculator does not have the right to make any settings. It works with ready-made settings.

Senior accountant

It differs from the calculator in that it is possible to change the settings for salary calculation, accruals and deductions, 1C.

In addition to the rights that the “Calculator” has, the “Senior Accountant” has the rights to change the following settings.

• Settings > Organizations.
• Settings > Accruals.
• Settings > Holds.
• Settings > Initial data entry templates.

• At the same time, “Settings > Payroll” remains inaccessible to the senior accountant. It is advisable to assign this profile to those calculators who master the technology of generating new types of calculations.

HR manager

Combines the rights of a personnel officer, a bookkeeper and a timekeeper, 1C.

Nothing to add here: three in one. It is advisable to use this profile where one user simultaneously acts as three persons: a timekeeper, a personnel officer and a bookkeeper.

Senior personnel manager

Combines the rights of a senior personnel officer, a senior accountant and a timekeeper. The last two profiles are implemented for the convenience of setting up the program in small organizations, where one user can be responsible for all areas of accounting, 1C.

A clarification is needed here. Indeed, the senior personnel manager has the right to set up “Accruals”, “Deductions”, “Salary calculation indicators”, etc. But he does not have the right to set up “Salary calculation” and “Personnel accounting”. This is true at least for release 3.1.4.167.

Opening external reports and processing

All users, including auditors and timekeepers, have the right to work with external reports and processing. However, for security reasons, by default the ability to use external reports and processing is disabled. If the report (processing) was received from reliable sources, then you can update the ability to work with external reports and processing as follows.

Run the payroll program in user mode as an administrator. On the system panel, click on the link “Main Menu > Tools > Options”. In the form that opens, update the “Display command “All functions”” flag and click “OK”.

We set the flag of the same name in it. After this, in the sections “Personnel”, “Salaries”, “Payments”, “% taxes and reporting” and “Reporting, certificates”, in the subsection “Service” links “Additional reports” and “Additional processing” will be displayed.

Manage change prohibition dates

To set the date for prohibiting changes to documents from previous periods, you must follow the links “Administration > User and rights settings > Dates for prohibiting changes”, figure.

Users who do not see the “Administration” section mean that they do not have the right to set the date for prohibiting changes to documents from previous periods.

Synchronizing data with other programs

This profile allows you to configure the data exchange mode. Subsequently, in accordance with the settings made, the exchange between payroll and accounting programs is ensured. By default, the roles of this profile are available only to administrators: "Administration > Data Synchronization".

It should be remembered that the profiles “Opening external reports and processing”, “Managing ban dates” and “Synchronizing data with other programs” are not self-sufficient. This means that if you create an access group with any of these profiles and connect a user only to it, then when they try to open the program, we will receive a message.

It indicates that the created access group does not have mandatory roles connected to it, making it self-sufficient.

Conclusion

Planned accruals can be assigned not only by users with the “Calculator” profile and above, but also by users with the “HR” profile and above. But neither planned nor one-time personnel officers have the right to assign deductions.

Access to the “HR Accounting” and “Payroll Calculation” settings is available only to users with full rights. The senior personnel manager does not have such rights.

In order to differentiate user rights, as a rule, preset profiles are quite sufficient. If necessary, you can create new profiles. At the same time, to create a self-sufficient profile, it should include some mandatory roles, such as “Launch thin client”, “Basic rights”, etc. In practice, it is easier to make a copy of the profile that is closest in terms of rights, and then edit it as necessary.