Visma Net
About ID segmentation
General ledger accounts (and subaccounts, if applicable), as well as other objects in the
system, have IDs.
An ID is a unique alphanumeric string assigned to an object for its identification.
IDs are typically segmented: composed of segments whose values help
users remember the meanings of IDs.
For example: General ledger subaccount
IDs could contain the following segments: a two-character regional branch
code, a one-digit department number, and a three-character product type.
Thus, the
subaccount ID CA-1-T32 would denote a subaccount of the California
branch (CA), department 1, related to the product T32.
In Visma Net, a segmented key is a system entity that holds the definition of the structure of IDs for a certain type of objects and serves as a template when a user creates an ID for a new object of the type.
Visma Net provides the following built-in segmented keys, which can be used only for the intended types of accounts or objects:
- ACCOUNT: Used for General ledger accounts
- ACCGROUP: Used for account groups for project management
- BIZACCT: Used for business accounts in the system; serves as the parent key for customer, supplier, and employee account IDs
- CASHACCOUNT: Used for branch-specific cash accounts based on a GL account.
- CONTRACT: Used for contract reference numbers; inherits its structure from the PROJECT key
- CONTRACTITEM: Used for contract items
- CUSTOMER: Used for customer numbers; inherits its structure from the BIZACCT key
- EMPLOYEE: Used for company employees; inherits the structure from the BIZACCT key
- INVENTORY: Used for stock items
- INSUBITEM: Used for subitems of stock items
- INSITE: Used for warehouses
- INLOCATION: Used for warehouse locations
- LOCATION: Used for customer and supplier locations
- MLISTCD: Used for mail lists
- PROJECT: Used for projects
- PROTASK: Used for project tasks
- SALESPER: Used for salesperson accounts
- SUBACCOUNT: Used for General ledger subaccounts
- TMCONTRACT: Used for contract templates
- SUPPLIER: Used for supplier numbers; inherits its structure from the BIZACCT key
If your organisation requires new types of objects in a specific Visma Net workspace, you can create new segmented keys.
To configure segmented keys, use the Segment keys (CS202000)
window.
During initial system setup, you must define the following for
each segmented key:
- How many segments the key has
- What is the length of each segment
- What is the type of each segment
- Whether the segment should be validated on input
Consider the following factors as you decide how to configure each key:
- You may define as many segments as you want as long as the total length of all segments does
not exceed the maximum length.
The maximum ID length differs for different segmented keys.
The total does not include the user-defined character (such as a hyphen) used to separate the segments when the object IDs are displayed. - An ID may be non-segmented; that is, it may consist of only one segment.
- One segment per key can be defined as auto-numbered, which means that a number series is assigned to it.
- If you add a segment to or remove one from a segmented key after IDs have been
created, you have to update the objects associated with this segmented key.
Otherwise these actions may have unpredictable results.
Once you have configured the segmented key for a type of objects, use the Segment values (CS203000) window to populate the list
of values for segments that will not be auto-numbered.
When you add new values for a segment on the Segment values (CS203000) window, the system automatically converts the value (if such an option was selected) and checks whether the value meets the input mask requirements.
In some windows, users can select objects of different types from the same lookup list.
For example: When preparing time cards, employees can specify either a project or a
contract on which they spent their work hours.
For this, IDs of such objects
should have similar structures.
To enforce similar structures of IDs for two
or more types of objects, inheritance of segmented keys (on which IDs are
based) is used.
One segmented key (a child key) inherits its structure from another segmented key (a parent key) means that the child key has the same number of segments as the parent key, and all its segments have the same lengths as the respective segments of the parent key.
By default, the child key will have the same structure as the parent key, and the
segment values specified for the parent key will be available for IDs based
on the child key.
However, you can make IDs based on a child key
distinguishable at a glance from IDs based on the parent key in the
following ways:
- For an alphanumeric segment, you can enter different sets of values for the parent and child key segments.
- For an auto-numbered segment, you can assign number series with different properties—for example, with different prefixes.
In the above example, the CONTRACT segmented key inherits its structure from
the PROJECT segmented key.
After the segmented key is configured and its segments are populated, a user can create an object of the type, entering its ID by selecting values for each of its segments.
For example, General ledger accounts are created in the Chart of accounts (GL202500) window, subaccounts are created in the Subaccounts (GL203000) window, and warehouses are
created in the Warehouses (IN204000) window.
When a user creates an account, subaccount, or other object, the user will see the
input mask (for example, ––/–/–––, with the slash used as a separator) that shows
the number of segments and the length of each.
You can configure input validation options, described below, to reduce some input
errors that may occur when IDs are composed of segment values.
Although
validation can be used for any segmented key, this section describes how validation
options work for General ledger accounts and subaccounts.
For segments with the Validate option selected in the Segment keys (CS202000)
window, users select from the predefined segment values.
With this
option selected, when a user creates a new account or subaccount, the user does the
following:
- Sees the input mask with the character specified as a separator for the key (such as ––/–/–––)
- Double-clicks the segment to open the list of possible values, or points at any segment and presses F3
- Selects the value for the segment from the list
If the Validate option is not selected for a segment, users can enter new
values while they create accounts or subaccounts.
The new values will be validated
only in accordance with the segment definition: the type of string and its length.
When users enter a string in a segment of the ID, the string will not be added to the list of segment values.
If the General ledger account has a one-segment ID, segment validation cannot be turned off and users can create accounts only by selecting them from the list of segment values.
Once created, accounts and subaccounts can be used on various documents in the General ledger,
Supplier ledger, and Customer ledger workspaces, and can be selected on inquiry
and processing windows.
Visma Net also provides a validation option for using subaccounts.
The On-the-fly
entry check box (in the Segment keys (CS202000) window) controls how
the user specifies subaccounts:
- If the check box is not selected, the user can specify subaccounts only by selecting them
from the list of available subaccounts.
Thus, before subaccounts can be used on data entry windows, they must be created on the Subaccounts (GL203000) window. - If the check box is selected, subaccounts on data entry windows can be entered segment by
segment; the user selects each segment value from the appropriate list of
predefined segment values. New segment values cannot be created during data
entry.
New subaccounts created on the fly are not added to the list of subaccounts.
Selecting the On-the-fly entry check box is helpful when the number of segments and the number of values in each segment could produce so many combinations that it would be labour-intensive to enter all subaccounts in advance.
The On-the-fly entry option is also used for subitems defined by the INSUBITEM key.