Visma Nmbrs is a payroll system that has its own structure and logic behind it. Make sure you understand the different levels of the two products: Nmbrs Accountant and Nmbrs Business, and be aware that most company and employee data in Nmbrs is period based. Which will be explained in the article below.
Nmbrs Accountant Levels
- Top level - the user can set up and manage on top level settings for all his clients
- Debtor level - before you can create a company you have to create a debtor. After you have created a debtor, you can create one or more companies that will belong to this debtor.
On debtor level you can store and change information for that particular debtor. You will have to use API methods from debtor service to retrieve debtor information. - Company level - before you can create an employee you have to create a company. After you have created a company, you can create employees that will belong to this company.
On company level you can store and change information for that particular company. You will have to use API methods from company service to retrieve company information. - Employee level - on employee level you can store and change information for that particular employee. You will have to use API methods from employee service to retrieve employee information.
Changes that you do can only have top-down effect. As an example: salary changes on debtor level will only apply to that debtor and its companies and employees.
The level structure is presented in picture below.
Visma Nmbrs Business Levels
The owner of Nmbrs Business environment is a company which does the salary process for itself. Nmbrs Business has only one debtor and can have multiple companies. There are 3 levels:- Debtor level - on debtor level you can store and change information for that particular debtor. You will have to use API methods from debtor service to retrieve debtor information.
- Company level - before you can create an employee you have to create a company. After you have created a company, you can create employees that will belong to this company.
On company level you can store and change information for that particular company. You will have to use API methods from company service to retrieve company information. - Employee level - on employee level you can store and change information for that particular employee. You will have to use API methods from employee service to retrieve employee information.
Changes that you do can only have top-down effect. As an example: salary changes on debtor level will only apply to that debtor and its companies and employees.
The level structure is presented in picture below.
Period based data
Most company and employee data in Nmbrs is period-based. This means that information that is necessary for payroll can be saved and changed in a current period, the future or the past. That also implies that changes in the past might affect other periods, and therefore data will be changed with the next payroll process.The payroll process, what we call a run, closes a current period. An example below will explain this further.
The actual date is September 2016. Because no run is made for September, the current period of the company is August. Changes that are made in current period will affect August. After you do a run, calculations will be made for August, the period will be closed and current period will become September.
If we take the same example, but you make changes in February (previous period) after you do a run, the calculation will affect the periods from February up to and including August.
Be aware that you are able to do runs, pre-runs, correction-runs, include correction-runs in a normal run, run multiple periods in one run and merge runs. For more information see
Each company has its own period type, for more information see company period. The exceptions are the debtor data and information where period or date can be added.
The questions below will help you to understand how the period should be handled:
- Is data in your application period based?
- Are you able to change data in your application in previous periods?
- How are you going to handle changes in the past?
- What is the user's expectation?
Data in our software, such as employees, companies, functions, departments and other, is registered with numbers in the interface. When using API we work with unique numbers what we call ids.
Comments