Object Versions
- [Object Values] Populating the object with data
- [Object Attributes] Adding custom attributes or properties to objects
- [Object Structures] Grouping and structuring object values in hierarchies
- [Planning Versions] Defining versions of the planning data
Object versions makes it possible to have different versions of object related data (i.e. attributes and structures). An example can be the cost center structure might look different from one year to another. Or the classification of accounts into account groups. This makes it possible to without creating new objects and design new templates to work with multiple versions of object related data.
This should not be confused with versions of the input planning data entered by the end-user (i.e. [Planning Versions]). The planning version makes it possible to have more than one version of the entered planning data. I.e revenue in the budget can be something else then the revenue in the forecast. But both the budgeted numbers and the forecast numbers can be grouped and summarized using multiple object structures using object versions.
Access Object Versions by selecting Client administration > Objects > Object setup > Object Versions.
This topic contains the following sections:
Explanation and Definition of Terms
The following explanation of terms is based on an example with three objects; 100 accounts grouped into 10 account groups and 10000 products with attributes. When setting up a similar model without using object versions there will always be one object versions automatically created called ‘BASE’.
Say that you want to have different versions of the chart of account structure. This year actuals should be grouped into account groups in one way, but next year some accounts should be moved from one account group to another. This implies that the 100 records with accounts attached to the 10 account groups (100 records) must exist in two different versions. This data of 100 records is called a ‘Set’. The product object will also have a set of 10000 object value attributes.
In this scenario, we do not want to create a copy of the product base set due to the fact that this data should be the same for this year and next. When changing the color of a product this year, it should also apply to next year. For example, for products we want to use the same set of data for both this year and the next year, but for accounts we want to copy the base set and create a new set with 100 records where we can change the connection to account groups.
An object version is something that coordinates which sets of data should be used in a logical matter. In this scenario, you might use the ‘BASE’ object version, linking the base set for both accounts and products together. But for next year, you need to create a new object version that defines that the base set should still be used for products, but a new set of data should be used to group accounts.
Create an Object Version
To create a new object version click the New button. A new empty row will be created. Input the base data for the object version (first six columns).
Define if you want to use an existing set of object related data, or if you want to create a new set for each object.
If you select to create a new set, a dialog displays asking you if you wish to copy the set data from another set, or if you wish to start from scratch by creating a new empty set. Give the new set an ‘object version set code’.
To create the new object versions and sets, select the Save button in the main form. No data will be copied and nothing will be affected before the Save button is pressed.
Below is a list of Object Version fields:
Field | Description | Example | Note |
|---|---|---|---|
Object Version | The ID of the object version | 2016V1 | Keep short. Cannot be changed. |
Description | The description of the object version. | From 2016 and forward | Describe when this object version is used. |
Status | The status of the object version. | 1 Active |
|
Load Default | Defines if this is the object version that is populated with data using the standard procedures to load data from staging tables. | Only one object version within a client can be defined as the default update object version. | |
Datastore Update | Defines if the object version data should be synchronized to the datastore. | If using datastore, normally all object versions should be synchronized to datastore. | |
Datastore Default | Only one object version within a client can be defined as the default datastore object versions. This information is only used in the database views in datastore exposing data to other systems. | ||
(columns with objects controlled by object versions) | |||
Updated by (Read only) | Last update by user. | ||
Update (Read only) | Last update date and time. |
Additional Information
If an object has more than one object set (exists in more than one object version) an extra drop-down will be visible in the object value, and object structure maintenance windows (top right) making it possible to select what set of data to edit. The data controlled by object versions (attributes, parent attributes, and trees) will in these maintenance grids be shown with yellow color.
Object versions can be used in a drop-down in a selection pane making it possible for the end-user to select what structures to use when opening a form or report. The object version can also be sent from one drop-down in a selection pane to control what object structure should be visible in another drop-down. If not set, all drop-downs, grouping and filtering will be based on the BASE object versions.
Usage
The concept of object versions can be quite complex for an end-user to understand when for example doing selections in a selection pane. To overcome this it is possible to connect a planning version to an object versions. This implies that when a user in a drop-down in a selection pane selects a planning version, the user will by that selection also select what object version that should be used. See [Planning Version].