About restriction groups in Visma.net ERP

You can use restriction groups to do the following:

• Control the visibility of sensitive data for employees of your organisation.
• 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).

In Visma.net ERP, you can use specific windows 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.

Example

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).

• You create Group 2, which includes User Y and User Z, as well as the accounts they should work with (4, 5, and 6).

Final visibility

Among all users in the system:

• Only User C and User D will see the first group of sensitive accounts (1, 2, and 3).
• Only User Y 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.

You can create restriction groups that include users in the following way: 

• 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 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 items:
  You can define these restriction groups to reduce the number of items in the lists with items, depending on the particular employee logged in to the system.
  For more information, see:About item security.
• Users and projects:
  You can define these restriction groups to configure the visibility of particular projects only to a responsible project team.
• Branches, general ledger accounts, and users:
  With these restriction groups, you can allow users to work with only branch-specific accounts.
• Branches, subaccounts, and users:
  You can set up these restriction groups so that the system displays to users only the branch-specific subaccounts. About account and subaccount security.

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.

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.

Final visibility

The result of these settings is the following:

• A user that selects Account 1 on an entry form, will only be able to select Subaccount K, Subaccount L, or Subaccount M in a field with subaccounts.
  The subaccounts included in Group 2 will be hidden from the list.
• A user that selects Account 2, 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.

With the most common scenarios, you can create restriction groups that include the following system entities:

• 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.