Visma.net ERP
About restriction groups in Visma.net ERP
Visma.net ERP provides you with restriction groups, which are flexible tools for limiting the visibility and use of entities, such as General ledger accounts, stock items, and customer and supplier accounts.
In this topic, you can find information about situations where restriction groups are useful, types of restriction groups, and types of entities that you can include in restriction groups.

You can use restriction groups to do the following:
- Control the visibility of sensitive data for employees of your organisation.
To do this, you include in a restriction group the entities for which you need to restrict the visibility, and the users who should or should not be able to view these entities. - To relate entities to one another so that they are used only together in Visma.net ERP windows (or so that they cannot be used together).
To do this, you include in a group only related entities and do not include users.
In Visma.net ERP, you can use specific forms to create restriction groups, view the entities
included in a group, and manage the list of entities of a particular type in a
restriction group.
For details on the typical operations you can perform with
restriction groups, see: About operations with restriction groups.

To understand how restriction groups with users are used, consider a typical case with
restriction groups that include users and general ledger accounts.
Suppose that
a role allows all its users to access all general ledger accounts, but for two groups of
accounts, you want to provide visibility to only particular users.
Restriction groups for general ledger accounts and users:
The diagram above shows how restriction groups can address these security needs.
You define
Group 1 as a restriction group that includes only appropriate accountants (User C
and User D) and accounts (1, 2, and 3).
Similarly, you create Group 2, which
includes User Y and User Z, as well as the accounts they should work with (4, 5, and
6).
Among all users in the system, only User C and User D will see the first group of sensitive accounts (1, 2, and 3), and only User X and User Z will see the second group of sensitive accounts (4, 5, and 6). Users who are not assigned to any restriction group will not see the accounts associated with either group.

If a restriction group does not include users, all users may view the entities that
are members of the group (if their roles provide access to windows with these
entities), but entities included in the group become related in a way that limits
their use.
For example: Suppose that you create two groups with general ledger accounts and
subaccounts as follows:
- Group 1 includes Account 1, Subaccount K, Subaccount L, and Subaccount M.
- Group 2 includes Account 2, Subaccount P, Subaccount Q, and Subaccount R.
For simplicity, suppose that there are no other accounts and subaccounts in the system.
The result of these settings is the following:
- If a user selects Account 1 on an entry form, he or she will be able to select
only Subaccount K, Subaccount L, or Subaccount M in a field with subaccounts.
The subaccounts included in Group 2 will be hidden from the list. - If the user selects Account 2, he or she will see Subaccount P, Subaccount Q, and Subaccount R in the field with subaccounts; the user will not see Subaccount K, Subaccount L, and Subaccount M.
If you are using restriction groups to
control the accounts and subaccounts that can be used together, you must create at least
two groups and include all subaccounts in either of the groups.
For example: Suppose
that you need to restrict visibility of subaccounts for only one account.
To solve this
task, you create two restriction groups.
In the first group with direct restriction, you
include a general ledger account and the list of subaccounts that should be related to this account.
In the second group with inverse restriction, you include the same account and
subaccounts that should not be displayed after users select this account.
As a result,
when users select the account on a window, they will see only one of the subaccounts
included in the first group.

Visma.net ERP provides two basic types of restriction groups, A and B.
Restriction groups of
both types can limit the visibility of system entities in a direct way (types
A and B) and an inverse way (types A inverse and B
inverse in the Visma.net ERP user interface). The differences between A and B and between A
inverse and B inverse are in how these groups work if the same entity
is added to multiple groups.
For detailed descriptions of each group type, see: About types of restriction groups.

Visma.net ERP supports the a variety of scenarios of configuring the visibility of entities
within the system.
With the most common scenarios, you can create restriction groups
that include the following system entities:
- Users and general ledger accounts:
With these restriction groups, if your organisation has sensitive general ledger accounts, you can make these accounts visible to a limited number of employees.
For details, see: About account and subaccount security. - Users and subaccounts:
As with groups that include users and general ledger accounts, you can limit the visibility of sensitive subaccounts to employees.
For more information, see:: About account and subaccount security.
For performance reasons, visibility restrictions by user for subaccounts do not affect analytical (ARM) and window-based reports or general inquiries.
This means that users who can view the reports and general inquiries that include subaccounts will see the full list of subaccounts. - Users and supplier accounts:
You can define these restriction groups to make particular suppliers visible in the system to only employees who work with these suppliers.
For details, see: About supplier security. - Users and customer accounts:
With these restriction groups, you can make particular customers visible to only employees who work with these customers.
For details, see: About customer security. - Users and general ledger budget articles:
With these restriction groups, you can limit the visibility of sensitive budget articles so that only particular users can see and work with these articles.
For more information, see:About security of general ledger budget articles. - Users and warehouses:
You can create restriction groups to display a particular warehouse (or set of warehouses) for only employees who work with this warehouse (or this set of warehouses).
For details, see: About warehouse security. - Users and stock items:
You can define these restriction groups to reduce the number of items in the lists with stock items, depending on the particular employee logged in to the system.
For more information, see:About stock item security. - Branches, general ledger accounts, and users:
With these restriction groups, you can allow users to work with only branch-specific accounts.
For details, see: About account and subaccount security. - Branches, subaccounts, and users:
You can set up these restriction groups so that the system displays to users only the branch-specific subaccounts.
For more information, see:: About account and subaccount security. - Branches and cash accounts:
If there are multiple branches in your organisation, with these restriction groups, you can allow users in each branch to work with only branch-specific cash accounts.
For details, see: About security of cash accounts. - General ledger accounts and subaccounts:
If you have subaccounts that employees must use only with particular general ledger accounts, by defining these restriction groups, you can set up lists of available subaccounts for each general ledger account.
For more information, see:: About account and subaccount security.
Parent topic:Manage visibility with restriction groups - overview