Each project in Visma Net is assigned a unique project ID. Project IDs can be comprised of segments with optional validation of each segment.

Plan the structure of the project ID based on the segmented key PROJECT: number of segments, length of segments, whether and how they should be validated, and whether auto-numbering should be used.

Note that the PROJECT segmented key is also used for project templates, so decide whether you want the IDs of projects to differ from the IDs of templates. Prepare a list of valid entries for segments that should be validated. Design a numbering sequence for an auto-numbered segment, if one will be used.

Plan also the structure for the task IDs (the segmented key PROTASK ).

The task ID should be unique only within a project. Two different projects can have tasks with the same identifier, and they will be different tasks. For this reason, you should not use auto-numbering for task IDs.

Once the Projects workspace is enabled, the system will require project IDs and project task IDs for every transaction in all the integrated workspaces of Visma Net.

This does not mean that each transaction must be linked to a project; you can enter the non-project code (which you define) for a transaction that is not related to any project.

For convenience, the non-project code should be distinctly different from project IDs and should be short, such as the single character X, which is used by default.

The role of account groups in Projects is similar to the role of accounts in the General ledger: All transaction processing and all reporting in Projects are done by using account groups.

When defining account groups, first identify the accounts that will be used in project-related transactions. Customer ledger accounts (accounts debited by project invoicing) and supplier ledger accounts (accounts credited by purchase invoices) should be excluded. For each identified group, write down the following:

• A short description of the account group.
• The type of account group: Asset, Liability, Income, Expense, or Off-balance. The type of the group should be the same as the type of general ledger accounts included in the group. An off-balance group cannot include any general ledger account.
• The list of General ledger accounts associated with the group.
• The account group ID (which should comply with the ACCGROUP segmented key).

For more information, see: About account groups

Plan the structure of IDs to be used for account groups.

The structure is defined by the ACCGROUP segmented key.

The account group IDs can mimic the general ledger account numbers or be text IDs, such as BUDGET, REVENUE, and EXPENSE.

If needed, the IDs can be defined with multiple segments. Use similar IDs for similar account groups to be able to specify ranges of account groups (arranged alphabetically) when defining allocation rules.

Labour items provide information about hourly rates, general ledger accounts, and VAT categories to be used to account for labour on projects.

The general ledger accounts used for labour items should be mapped to appropriate account groups; otherwise, the transactions related to labour on projects will not be visible in the Projects workspace.

Decide what different types of labour are involved with projects and how they differ (thus, how their settings will differ). Decide how many labour items you will need for these types of labour.

Write down all non-stock items to denote services, miscellaneous expenditures that may be used for projects, and various types of labour.

Select the general ledger accounts to be used for those items and note that the accounts should be mapped to the defined account groups.

To issue a stock item from a warehouse for a project, you have to specify a reason code that would provide appropriate accounts for the transaction.

The accounts specified for the reason codes should be mapped to appropriate account groups.

Attributes can be used to store additional information about projects.

You can define the types of UI controls to be used for attributes and the lists of possible values; you can even make them required elements in the windows.

The Projects workspace can be integrated with the General ledger, Supplier ledger, Customer ledger, Purchases, Inventory, and Cash management workspaces. Integration with a specific workspace means that projects are visible in this workspace, and the users can enter project-related transactions in this workspace.

Particular projects and their tasks can have their own (more narrow) visibility scopes.

Whether or not the Projects workspace is integrated with the General ledger and Customer ledger workspaces, the system will post the Projects transactions to the General ledger workspace and generate sales invoices.

If you are going to track the time your employees’ work on specific projects, integrate the Projects workspace with the Time and expenses workspace.

With this integration, the Time and expenses workspace will initially release the employee time cards to the Projects workspace; then, on allocation, the Projects workspace will post them to General ledger.

Enabling the Time reporting on activities functionality will allow you to track the work time and overtime your employees spend on the activities related to projects. This functionality should be included in your license.

Also, plan the activity types for which you want to track time.

In Projects, @Rate is a parameter used in formulas of the allocation and invoicing rules.

Different rates can be applied to different transactions based on many related factors, such as particular tasks or projects, account groups, stock items involved, particular employees participating, and the particular step of the allocation or invoicing.

For example: You can charge customers for consultant work differently depending on the particular consultant involved in a project.

In the context of rate tables, rate is a number (@Rate) that you can use in allocation rules as a multiplier, an addend, or a constant value. For instance: To implement a price model that estimates the project price as total costs plus 10 percent, you can define a @Rate of 1.1 in the appropriate rate table and calculate the project price as the total cost multiplied by this rate.

For more information about rates and rate tables, see: About rate tables and Configure a rate table

Allocation rules define how to:

• Re-allocate costs between account categories, tasks, and projects.
• Calculate burdens, overheads, not yet invoiced, and unearned revenues.
• Select and group transactions for posting.
• Calculate invoiceable amounts and generate sales invoices.

For more information about allocation rules, see: Allocation rules (PM207500)

Review the planned projects, group them by similar properties, and decide on creating project templates. Review the project tasks, and write down a list of the tasks that are common for most projects (common tasks).

Also, create lists of tasks specific for each group of projects to include them in respective project templates.

These projects do not use the rate table to calculate the sales rates, but instead use a mark-up percentage for all project transactions.

You must enter the mark-up percentage in the Projects (PM301000) window, on the Attributes tab.