| Item | Description |
|---|---|
| Develop a naming convention for projects and tasks | 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. |
| Define non-project code | 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. |
| Define account groups | 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:
For more information, see: About account groups |
| Develop a naming convention for 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. |
| Plan labour items | 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. |
| Create a list of non-stock items to be used in projects | 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. |
| Plan reason codes | 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. |
| Plan attributes | 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. |
| Plan on integrating Projects with other workspaces | 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. |
| Define integration with time and expenses | 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. |
| Decide whether you need to track time on activities | 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. |
| Create a list of employees who will work for projects | Make sure that all the employees who will work on projects have employee and user accounts; also, make sure that their hourly rates are specified and the appropriate labour items are defined. |
| Design roles | Design the roles you need for users who will configure rate tables, set up allocation and invoicing rules, manage projects, and enter the data for projects. |
| Define @Rates (rate tables) | 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 |
| Define earning types | You will need non-stock items to account for labour on projects. |
| Design allocation rules | Allocation rules define how to:
For more information about allocation rules, see: Allocation rules (PM207500) |
| Design invoicing rules | Invoicing rules define how to invoice the customers for work performed by your company on specific projects. For more information about project invoicing, see: About project invoicing |
| Consider creating templates for projects and tasks | 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. |