The Asset ID
Objective: To discuss the definition and purpose of Asset ID’s and their configuration in the Brightly Assetic Asset Register.
The Asset ID is a unique identifier for an individual asset normally consisting of a numerical or alphanumeric value. The Asset ID is key to the identification of assets and to the allocation and retrieval of information relating to them.
The structure and complexity of Asset ID’s can vary from simple sequential numbering to complex combinations of key asset attribute codes. Each organization will have their own business requirements on the format of the Asset ID. The Table 1 below illustrates some examples of Asset ID’s that are catered for in the Assetic Register.
Some organizations prefer to use complex combinations to create “Smart Id’s” that include detail about the asset such as type or location or importance to provide information about an asset, when viewing the assets ID, as per the last example in Table 1. A frequent user of the asset register in this scenario would be able to identify that the asset is a building and that the building is a community hall numbered 12.
Manual Asset IDs can be used in the Assetic Asset Register, however it must be noted that as these are manually created outside of the system, they require appropriate business rules with regards to the application and generation of the ID.
By default the Assetic Asset Register allows the user to input any Asset ID.
This article provides a guide to the configuration of the sequential numeric and alphanumeric auto Asset ID generation in the Assetic Asset Register, should you wish to utilize this function.
Component ID’s in the Brightly Assetic Asset Register
Each asset within the Assetic asset register will have corresponding components where specific data such as dimensions, service criteria and financial values are recorded and stored.
When creating components, each component will have its own unique component configuration which serves the same purpose as the Asset ID. It enables the identification of components and the allocation and/or retrieval of information relating to them.
Components are configured against each asset using the Asset ID and the pre-configured Component Type as per the example in Table 2.
Table 3 below illustrates the information that would be allocated to this building asset’s components using the following Table Field Names and attribute data sets. On import the system will assign the attribute data such as material and design life against each component as it utilizes the Asset ID in combination with the Component Name to determine where the information should be appended to. Essentially the Asset ID in combination with the Component Name will be used by the system to identify the asset component.
The Component Type is used to determine the available service criteria and dimension fields that will be made available to the component.
By default when a user adds an additional component that already exists in the register, this action will return an error message. The system will not recognize duplicate Component Names, as these need to be unique. The user will need to apply a unique identifier for the Component Name on the creation of the component as per the examples in Table 4 or Table 5.
Both of these components utilize the "Roof Main" component type in the Table 4 and 5 examples, which means they will have the same available service criteria, assigned to this component type.
To manually create a component against the asset in the Asset Register, refer to Add Component, for the step by step guide on how to perform this function.
Tips: Asset ID’s are required for every asset in the register and must be globally unique.
Each asset category can have its own unique alpha prefix, the numeric portion is then auto incremented for each asset added to the system.
For components, the combination of Asset ID and Component Name must be globally unique.
