New Assets & Components

This document provides even more information as well as suggestions around importing data to create new assets and components in the Metrix Asset Management system. It is broken into a number of sub-sections to assist readers in being able to focus on different asset management data contexts separately. These include:

Asset Data Fields

The following fields pertain to information that will be stored against the parent asset of the imported components. Remember, if you are importing an asset with multiple components ↗, the information in these columns will need to be repeated for each row, constituted by each child component.

Asset Import Reference

This is a value from your import CSV that will tie the imported record back (in system) back to that CSV entry.

• Header label: asset_import_ref
• For an asset with multi components, this value must remain constant for each row relating to that asset.
• Aside from the above case regarding assets with multi components, this value must be unique per row to ensure each component row is created on a unique asset record.
• The asset import reference is generally not visible inside the Metrix Asset Management system, however, it is able to be included in data exports such as the ‘Component Data Export’.
• Users typically set this to the ID value (i.e. asset id) from their legacy system, if unique.

See also Multi-component assets ↗

Asset Classification ID

This is the unique ID of the asset classification that the asset will be assigned to.

• Header label: asset_classification_id
• You must create and configure your asset classification prior to importing data.
• The ID can be copied from the asset classification configuration page.

See also Asset classification configuration page ↗

Asset Description

This field provides a description of the asset.

• Header label: asset_description
• This value will be displayed in the Identification section within the parent asset info panel.
• Users typically implement location based descriptors of their assets.

See also Parent asset info panel ↗

Legacy Asset ID

This field can be used to import an asset id from your legacy Asset Management System.

• Header label: legacy_asset_id
• If set, this value will be displayed in the Asset Attributes section within the parent asset info panel.
• Users typically ignore this field unless they are still actively using their legacy system.

See also Parent asset info panel ↗

Component Identity Data Fields

The following fields pertain to information that will be stored against each component in relation to the components identifying attributes.

Component Import Reference

This should be set to a value from you import CSV that will tie the imported record (in system) back to that CSV entry.

• Header label: component_import_ref
• The component import reference is generally not visible inside the Metrix Asset Management system, however, it is able to be included in data exports such as the ‘Component Data Export’.
• Users typically set this to the ID value (i.e. component id) from their legacy system, if unique.

Component Group ID

This is the unique ID of the component group within the asset classification that the component will be assigned to.

• Header label: component
• You must create and configure your asset classification and component groups prior to importing data.
• The ID can be copied from the component classification configuration page.

See also Component classification page ↗

Status

This is the unique ID of the component group within the asset classification that the component will be assigned to.

• Header label: component
• You must create and configure your asset classification and component groups prior to importing data.
• The ID can be copied from the component classification configuration page.

See also status configuration page ↗

Component Description

This field provides a description of the component.

• Header label: component_description
• This value will be displayed in the ‘Identification’ section within the component info panel.
• Users typically implement location and/or type based descriptors of their components.

See also Component info panel ↗

Legacy Component ID

This can be used to import a component id from your legacy Asset Management System.

• Header label: legacy_component_id
• If set, this value will be displayed in the Component Attributes section within the component info panel.
• Users typically ignore this field unless they are still actively using their legacy system.

See also Component info panel ↗

Spatial Definition Fields

The following fields enable users to define the spatial features representing the newly created asset components. It should be noted that the required/recommended/optional flags for each field are conditional to the import scenario (hence the asterisk). Please read each of the field notes carefully to determine if the field is required in your circumstances.

Shape WKT

The WKT stands for Well Known Text ↗ which is a method of writing simple geometry features into a standard text string. This field allows users to define such a geometry as the spatial feature representing the component.

• Header label: shape_wkt
• A valid spatial feature is a mandatory element of the system.

See also Guide to WKT ↗

Shape Import Ref

This is an optional field used to denote shared geometries on multi-component assets.

• Header label: shape_import_ref
• For an asset with multi components that share a single spatial feature, this value must remain constant for each row relating to that asset.
• Spatial features CANNOT be shared across different assets.
• The shape import reference is not visible inside the Metrix Asset Management system following import.
• Users typically set this to the value of the Asset Import Reference as this is already common between the relevant rows.

See also Multi-component assets ↗

Component Intervention Fields

The following fields pertain to information that will be stored against each component in relation to the components intervention attributes.

Construction Date

This field reflects the original date of construction/commission for the component.

• Header label: construction_date
• If the component carries value, the construction date must be supplied.
• If setting the component’s useful life, the construction date must be supplied.
• If the value is not known, it can be derived from the component’s residual life and/or depreciation.
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.

Intervention Date

This field reflects the date of the most recent capital intervention (renewal) for the component.

• Header label: intervention_date
• If the value is not known, it can be derived from the component’s construction date.
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.

Condition

This field sets the condition of the component at a 1-5 value.

• Header label: condition
• A condition of 1 is considered excellent, and a condition of 5 is considered ver poor.
• Condition is required for some types of financial reports.

Condition Date

This field sets the date that the condition of the component was captured (if known).

• Header label: condition_date
• This value will default to ’today’ if not set.

Useful Life

This field reflects the expected lifespan, in years, of the component.

• Header label: intervention_useful_life
• If the component carries value, the useful life must be supplied.
• If setting this value, make sure either ‘Construction Date’ or ‘Intervention Date’ exists.
• If the value is not known, it can be derived from recent Annual Depreciation charges.

Treatment ID

This field sets the current intervention treatment for the component.

• Header label: treatment_id
• The treatment ID can be copied from the treatment configuration page.
• Configuring and assigning treatments will add great value to your experience of the Metrix Asset Management system.

See also Treatment definition ID

Cost Units

The cost unit value for the component in accordance with any treatment definition that has been applied.

• Header label: cost_units
• This value will be ignored if the component classification has been configured with a cost unit formula.
• If supplied, this must be a positive number to a maximum precision of 4 decimal places.
• Ensure you check any Unit of Measure assigned to the component treatment when setting this value.

Residual Life

By default, residual life (remaining useful life) is calculated by the Metrix Asset Management date using the intervention useful life, the intervention date, and the end of the current financial period. Supply this field if your data has residual life values that are known, and/or specified differently.

• Header label: intervention_residual_life
• If setting this value, also supply an effective date value for the import row that baselines when the residual life assertion is valid from.
• If the value is not known, exclude it and allow the system to calculate a value.

Effective Date

This field provides context to your imported data and will set the ‘modified’ date of the components to the supplied value, instead of the current date/time.

• Header label: effective_date
• This field is recommended if setting the residual life value as it provides the baseline from when the residual life assertion is founded.
• If the value is not known, the date/time of when you import the file will be used.

Financial Ledger Transactions

The following fields enable users to set the initial financial transactions ledger value for the newly created asset components. Please note, the optional flag is set to reflect that transaction posting is optional. If value exists on the assets being imported, then these fields are indeed required.

Finance Category

This is the unique ID of the finance category that the imported transactions will be assigned to.

• Header label: finance_category
• The finance category ID can be copied from the finance categories configuration page.
• If a component carries value, and transaction postings are being imported, this is a REQUIRED field.
• If a component carries value, and transaction postings are being imported, this is a REQUIRED field.

See also Finance categories configuration page

Transaction Type

This is the unique ID of the transaction type - with the type effect stripped - that the transaction value is being initialised with.

• Header label: transaction_type
• If the component carries value, and transaction postings are being imported, this is a REQUIRED field.
• The transaction type ID can be derived from the transaction type configuration page. Simply remove the -gross or -accumulated_depreciation tags from the ID to strip the type effect. The reason for this is that, in this import process, the transaction type effect is mandated by the column origin of the data - being either ‘gross_value’ or ‘accumulated_depreciation’ below.
• Users typically set this value to ‘recognition’, which is a built in transaction type for value initialisation.

See also Transaction type configuration page

Posting Date

This is the date in which the transactions should be recognised in the financial ledger.

• Header label: posting_date
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.
• If the data import is for a site initialisation, users typically set this value to the end of the last financial reporting period - i.e. 30/06/2023 for the 2023 EOY.
• If the component carries value, and transaction postings are being imported, this is a REQUIRED field.

Gross Value

The current replacement value of the asset component according to the organisations financial statements.

• Header label: gross_value
• If provided, this must be a positive number up to a maximum precision of 4 decimal places.
• This value has many pseudonyms including ‘Current Replacement Cost’, ‘Fair Value’, and ‘Market Value’

Depreciation Value

The current value of the life-to-date depreciation accumulated against the component according to the organisations financial statements.

• Header label: accumulated_depreciation
• If provided, this must be a negative number (or zero) up to a maximum precision of 4 decimal places.
• Sometimes, this value needs to be derived from financial statements. It is the difference between ‘Gross Value’ and the components ‘Carrying Value’ (AKA ‘Written Down Value’, and ‘Closing Value’).
• Don’t forget that this value must be provided as a negative figure - simply multiply by -1

Other Fields

The following fields, whilst not typical in a data import template, are also supported.

Report Categories

This is one or more - separated by semi-colons (;) - unique report category ID values that may pertain to the asset component.

• Header label: reporting
• To supply more than one report category tag, use a semi-colon. I.e. category1-option; category2-option.
• The report category IDs can be copied from the report categories configuration page.
• Users often use report category tags to note import anomalies that will be ‘cleaned up’ later in the system.

See also Report Category ID

Next Treatment Fields

The following fields can be included in an import sheet to set parameters around the component’s next intervention treatment plans. Although discussed as a single entity, each of the following should be distinct columns in your CSV file. The required/optional fields are only relevant if importing this information - otherwise, all fields are optional.

Next Treatment Description - next_treatment_description (required)

• A short description of the treatment.

Next Treatment Reason - next_treatment_reason (required)

• A brief reasoning for implementing the treatment.

Next Treatment ID - next_treatment_id (optional):

• The unique treatment id of the treatment definition that is being set as the next intervention for the component.
• This can be ignored if the next treatment is defined with a ‘Fixed Value’.

Next Treatment Cost Units - next_treatment_cost_units (optional):

• An override option to the component’s cost units value for the next treatment.
• This will be set if the next treatment only pertains to a known quantity subset of the component.

Next Treatment Cost Unit Factor (%) - next_treatment_cost_unit_factor (optional)

• This is another override option to the component’s cost units value for the next treatment.
• Instead of a known quantity, this value will set a cost unit value relative to the component cost unit value.
• This is typically 100% for standard renewal plans.

Next Treatment Fixed Value - next_treatment_fixed_value (optional)

• Set this value - in lieu of the above three (3) fields - if the next treatment is defined by a fixed/quoted price.

Next Treatment Date - next_treatment_expected_date (optional)

• An estimated date that the next treatment should occur.

See also Treatment ID

Financial Settings

The following fields allow users to define two financial settings for components. Although discussed as a single entity, each of the following should be distinct columns in your CSV file. The required/optional fields are only relevant if importing this information - otherwise, all fields are optional.

Depreciable Method - depreciable_method (required)

• Depreciable Value is the subset value of the component’s gross value that is depreciable. System default is 100%.
• If setting a depreciable value for the component, this is a required field.
• Set this value to fixed or variable.
• Fixed means that the depreciable value you supply will be a fixed dollar value.
• Variable means that the depreciable value of the component as a percentage of the component gross value.

Depreciable Value - depreciable_value (required)

• The value as defined by the depreciable method chosen above.

Period Depreciation Method - period_depreciation_method (required)

• Period Depreciation Value details how much value is depreciated per financial period. System default is calculated by the component’s residual life and carrying value.
• If setting a period depreciable value for the component, this is a required field.
• Set this value to fixed or variable.
• Fixed means that the period depreciation value you supply will be a fixed dollar value.
• Variable means that the period depreciation value you supply will be a percentage of the component gross value.

Period Depreciation Value - period_depreciation_value (required)

• The value as defined by the period depreciation method chosen above.

New Components (Existing Assets)

This document provides even more information as well as suggestions around importing data to create new components against existing assets in the Metrix Asset Management system. It is broken into a number of sub-sections to assist readers in being able to focus on different asset management data contexts separately. These include:

Asset Data Fields

Although this import pertains to Component data, there is still a requirement for some asset related information to be provided for the import to function correctly.

Parent Asset ID

The parent asset record ID field is used to link the incoming new component records with an existing asset record from the system.

• Header label: parent_asset_record_id
• This value is case sensitive and should be copied from the parent asset info panel directly.

See also Asset info panel ↗

Asset Classification ID

This is the unique ID of the asset classification that the asset will be assigned to.

• Header label: asset_classification_id
• You must create and configure your asset classification prior to importing data.
• The ID can be copied from the asset classification configuration page.
• This assists with informing the correct component group ID is supplied.

See also Asset classification configuration page ↗

Component Identity Data Fields

The following fields pertain to information that will be stored against each component in relation to the components identifying attributes.

Component Import Reference

This should be set to a value from you import CSV that will tie the imported record (in system) back to that CSV entry.

• Header label: component_import_ref
• The component import reference is generally not visible inside the Metrix Asset Management system, however, it is able to be included in data exports such as the ‘Component Data Export’.
• Users typically set this to the ID value (i.e. component id) from their legacy system, if unique.

Component Group ID

This is the unique ID of the component group within the asset classification that the component will be assigned to.

• Header label: component
• You must create and configure your asset classification and component groups prior to importing data.
• The ID can be copied from the component classification configuration page.

See also Component classification page ↗

Status

This is the unique ID of the component group within the asset classification that the component will be assigned to.

• Header label: component
• You must create and configure your asset classification and component groups prior to importing data.
• The ID can be copied from the component classification configuration page.

See also status configuration page ↗

Component Description

This field provides a description of the component.

• Header label: component_description
• This value will be displayed in the ‘Identification’ section within the component info panel.
• Users typically implement location and/or type based descriptors of their components.

See also Component info panel ↗

Legacy Component ID

This can be used to import a component id from your legacy Asset Management System.

• Header label: legacy_component_id
• If set, this value will be displayed in the Component Attributes section within the component info panel.
• Users typically ignore this field unless they are still actively using their legacy system.

See also Component info panel ↗

Spatial Definition Fields

The following fields enable users to define the spatial features representing the newly created components. It should be noted that the required/recommended/optional flags for each field are conditional to the import scenario (hence the asterisk). Please read each of the field notes carefully to determine if the field is required in your circumstances.

Shape WKT

The WKT stands for Well Known Text ↗ which is a method of writing simple geometry features into a standard text string. This field allows users to define such a geometry as the spatial feature representing the component.

• Header label: shape_wkt
• A valid spatial feature is a mandatory element of the system.

See also Guide to WKT ↗

Shape Import Ref

This is an optional field used to denote shared geometries on multi-component assets.

• Header label: shape_import_ref
• For an asset with multi components that share a single spatial feature, this value must remain constant for each row relating to that asset.
• Spatial features CANNOT be shared across different assets.
• The shape import reference is not visible inside the Metrix Asset Management system following import.
• Users typically set this to the value of the Asset Import Reference as this is already common between the relevant rows.

See also Multi-component assets ↗

Shape ID

Set this value (instead of the ‘Shape WKT’) to link the new component’s spatial feature to an existing spatial definition that exists on the target asset’s components.

• Header label: shape_id
• Spatial features CANNOT be shared across different assets.
• The shape ID can be copied from the ‘Spatial’ section of the Component info panel.

See also Component info panel ↗

Component Intervention Fields

The following fields pertain to information that will be stored against each component in relation to the components intervention attributes.

Construction Date

This field reflects the original date of construction/commission for the component.

• Header label: construction_date
• If the component carries value, the construction date must be supplied.
• If setting the component’s useful life, the construction date must be supplied.
• If the value is not known, it can be derived from the component’s residual life and/or depreciation.
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.

Intervention Date

This field reflects the date of the most recent capital intervention (renewal) for the component.

• Header label: intervention_date
• If the value is not known, it can be derived from the component’s construction date.
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.

Condition

This field sets the condition of the component at a 1-5 value.

• Header label: condition
• A condition of 1 is considered excellent, and a condition of 5 is considered ver poor.
• Condition is required for some types of financial reports.

Condition Date

This field sets the date that the condition of the component was captured (if known).

• Header label: condition_date
• This value will default to ’today’ if not set.

Useful Life

This field reflects the expected lifespan, in years, of the component.

• Header label: intervention_useful_life
• If the component carries value, the useful life must be supplied.
• If setting this value, make sure either ‘Construction Date’ or ‘Intervention Date’ exists.
• If the value is not known, it can be derived from recent Annual Depreciation charges.

Treatment ID

This field sets the current intervention treatment for the component.

• Header label: treatment_id
• The treatment ID can be copied from the treatment configuration page.
• Configuring and assigning treatments will add great value to your experience of the Metrix Asset Management system.

See also Treatment definition ID

Cost Units

The cost unit value for the component in accordance with any treatment definition that has been applied.

• Header label: cost_units
• This value will be ignored if the component classification has been configured with a cost unit formula.
• If supplied, this must be a positive number to a maximum precision of 4 decimal places.
• Ensure you check any Unit of Measure assigned to the component treatment when setting this value.

Residual Life

By default, residual life (remaining useful life) is calculated by the Metrix Asset Management date using the intervention useful life, the intervention date, and the end of the current financial period. Supply this field if your data has residual life values that are known, and/or specified differently.

• Header label: intervention_residual_life
• If setting this value, also supply an effective date value for the import row that baselines when the residual life assertion is valid from.
• If the value is not known, exclude it and allow the system to calculate a value.

Effective Date

This field provides context to your imported data and will set the ‘modified’ date of the components to the supplied value, instead of the current date/time.

• Header label: effective_date
• This field is recommended if setting the residual life value as it provides the baseline from when the residual life assertion is founded.
• If the value is not known, the date/time of when you import the file will be used.

Financial Ledger Transactions

The following fields enable users to set the initial financial transactions ledger value for the newly created components. Please note, the optional flag is set to reflect that transaction posting is optional. If value exists on the assets being imported, then these fields are indeed required.

Finance Category

This is the unique ID of the finance category that the imported transactions will be assigned to.

• Header label: finance_category
• The finance category ID can be copied from the finance categories configuration page.
• If a component carries value, and transaction postings are being imported, this is a REQUIRED field.
• If a component carries value, and transaction postings are being imported, this is a REQUIRED field.

See also Finance categories configuration page

Transaction Type

This is the unique ID of the transaction type - with the type effect stripped - that the transaction value is being initialised with.

• Header label: transaction_type
• If the component carries value, and transaction postings are being imported, this is a REQUIRED field.
• The transaction type ID can be derived from the transaction type configuration page. Simply remove the -gross or -accumulated_depreciation tags from the ID to strip the type effect. The reason for this is that, in this import process, the transaction type effect is mandated by the column origin of the data - being either ‘gross_value’ or ‘accumulated_depreciation’ below.
• Users typically set this value to ‘recognition’, which is a built in transaction type for value initialisation.

See also Transaction type configuration page

Posting Date

This is the date in which the transactions should be recognised in the financial ledger.

• Header label: posting_date
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.
• If the data import is for a site initialisation, users typically set this value to the end of the last financial reporting period - i.e. 30/06/2023 for the 2023 EOY.
• If the component carries value, and transaction postings are being imported, this is a REQUIRED field.

Gross Value

The current replacement value of the asset component according to the organisations financial statements.

• Header label: gross_value
• If provided, this must be a positive number up to a maximum precision of 4 decimal places.
• This value has many pseudonyms including ‘Current Replacement Cost’, ‘Fair Value’, and ‘Market Value’

Depreciation Value

The current value of the life-to-date depreciation accumulated against the component according to the organisations financial statements.

• Header label: accumulated_depreciation
• If provided, this must be a negative number (or zero) up to a maximum precision of 4 decimal places.
• Sometimes, this value needs to be derived from financial statements. It is the difference between ‘Gross Value’ and the components ‘Carrying Value’ (AKA ‘Written Down Value’, and ‘Closing Value’).
• Don’t forget that this value must be provided as a negative figure - simply multiply by -1

Other Fields

The following fields, whilst not typical in a data import template, are also supported.

Report Categories

This is one or more - separated by semi-colons (;) - unique report category ID values that may pertain to the asset component.

• Header label: reporting
• To supply more than one report category tag, use a semi-colon. I.e. category1-option; category2-option.
• The report category IDs can be copied from the report categories configuration page.
• Users often use report category tags to note import anomalies that will be ‘cleaned up’ later in the system.

See also Report Category ID

Next Treatment Fields

The following fields can be included in an import sheet to set parameters around the component’s next intervention treatment plans. Although discussed as a single entity, each of the following should be distinct columns in your CSV file. The required/optional fields are only relevant if importing this information - otherwise, all fields are optional.

Next Treatment Description - next_treatment_description (required)

• A short description of the treatment.

Next Treatment Reason - next_treatment_reason (required)

• A brief reasoning for implementing the treatment.

Next Treatment ID - next_treatment_id (optional):

• The unique treatment id of the treatment definition that is being set as the next intervention for the component.
• This can be ignored if the next treatment is defined with a ‘Fixed Value’.

Next Treatment Cost Units - next_treatment_cost_units (optional):

• An override option to the component’s cost units value for the next treatment.
• This will be set if the next treatment only pertains to a known quantity subset of the component.

Next Treatment Cost Unit Factor (%) - next_treatment_cost_unit_factor (optional)

• This is another override option to the component’s cost units value for the next treatment.
• Instead of a known quantity, this value will set a cost unit value relative to the component cost unit value.
• This is typically 100% for standard renewal plans.

Next Treatment Fixed Value - next_treatment_fixed_value (optional)

• Set this value - in lieu of the above three (3) fields - if the next treatment is defined by a fixed/quoted price.

Next Treatment Date - next_treatment_expected_date (optional)

• An estimated date that the next treatment should occur.

See also Treatment ID

Financial Settings

The following fields allow users to define two financial settings for components. Although discussed as a single entity, each of the following should be distinct columns in your CSV file. The required/optional fields are only relevant if importing this information - otherwise, all fields are optional.

Depreciable Method - depreciable_method (required)

• Depreciable Value is the subset value of the component’s gross value that is depreciable. System default is 100%.
• If setting a depreciable value for the component, this is a required field.
• Set this value to fixed or variable.
• Fixed means that the depreciable value you supply will be a fixed dollar value.
• Variable means that the depreciable value of the component as a percentage of the component gross value.

Depreciable Value - depreciable_value (required)

• The value as defined by the depreciable method chosen above.

Period Depreciation Method - period_depreciation_method (required)

• Period Depreciation Value details how much value is depreciated per financial period. System default is calculated by the component’s residual life and carrying value.
• If setting a period depreciable value for the component, this is a required field.
• Set this value to fixed or variable.
• Fixed means that the period depreciation value you supply will be a fixed dollar value.
• Variable means that the period depreciation value you supply will be a percentage of the component gross value.

Period Depreciation Value - period_depreciation_value (required)

• The value as defined by the period depreciation method chosen above.

Update Existing Components

This document provides even more information as well as suggestions around importing data to update existing components
in the Metrix Asset Management system. It is broken into a number of sub-sections to assist readers in being able to focus on different asset management data contexts separately. These include:

Component Identity Data Fields

The following fields pertain to information that will be stored against each component in relation to the components identifying attributes.

Component ID

The component record ID field links the incoming component update with the existing component record in the system.

This field is the unique ID of the component throughout the system.

• Header label: component_record_id
• This value is case sensitive and should be copied from the component info panel directly.

See also Component info panel ↗

Component Description

This field provides a description of the component.

• Header label: component_description
• This value will be displayed in the ‘Identification’ section within the component info panel.
• Users typically implement location and/or type based descriptors of their components.

See also Component info panel ↗

Component Intervention Fields

The following fields pertain to information that will be stored against each component in relation to the components intervention attributes.

Construction Date

This field reflects the original date of construction/commission for the component.

• Header label: construction_date
• If the component carries value, the construction date must be supplied.
• If setting the component’s useful life, the construction date must be supplied.
• If the value is not known, it can be derived from the component’s residual life and/or depreciation.
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.

Intervention Date

This field reflects the date of the most recent capital intervention (renewal) for the component.

• Header label: intervention_date
• If the value is not known, it can be derived from the component’s construction date.
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.

Condition

This field sets the condition of the component at a 1-5 value.

• Header label: condition
• A condition of 1 is considered excellent, and a condition of 5 is considered ver poor.
• Condition is required for some types of financial reports.

Condition Date

This field sets the date that the condition of the component was captured (if known).

• Header label: condition_date
• This value will default to ’today’ if not set.

Useful Life

This field reflects the expected lifespan, in years, of the component.

• Header label: intervention_useful_life
• If the component carries value, the useful life must be supplied.
• If setting this value, make sure either ‘Construction Date’ or ‘Intervention Date’ exists.
• If the value is not known, it can be derived from recent Annual Depreciation charges.

Treatment ID

This field sets the current intervention treatment for the component.

• Header label: treatment_id
• The treatment ID can be copied from the treatment configuration page.
• Configuring and assigning treatments will add great value to your experience of the Metrix Asset Management system.

See also Treatment definition ID

Cost Units

The cost unit value for the component in accordance with any treatment definition that has been applied.

• Header label: cost_units
• This value will be ignored if the component classification has been configured with a cost unit formula.
• If supplied, this must be a positive number to a maximum precision of 4 decimal places.
• Ensure you check any Unit of Measure assigned to the component treatment when setting this value.

Residual Life

By default, residual life (remaining useful life) is calculated by the Metrix Asset Management date using the intervention useful life, the intervention date, and the end of the current financial period. Supply this field if your data has residual life values that are known, and/or specified differently.

• Header label: intervention_residual_life
• If setting this value, also supply an effective date value for the import row that baselines when the residual life assertion is valid from.
• If the value is not known, exclude it and allow the system to calculate a value.

Effective Date

This field provides context to your imported data and will set the ‘modified’ date of the components to the supplied value, instead of the current date/time.

• Header label: effective_date
• This field is recommended if setting the residual life value as it provides the baseline from when the residual life assertion is founded.
• If the value is not known, the date/time of when you import the file will be used.

Other Fields

The following fields, whilst not typical in a data import template, are also supported.

Report Categories

This is one or more - separated by semi-colons (;) - unique report category ID values that may pertain to the asset component.

• Header label: reporting
• To supply more than one report category tag, use a semi-colon. I.e. category1-option; category2-option.
• The report category IDs can be copied from the report categories configuration page.
• Users often use report category tags to note import anomalies that will be ‘cleaned up’ later in the system.

See also Report Category ID

Next Treatment Fields

The following fields can be included in an import sheet to set parameters around the component’s next intervention treatment plans. Although discussed as a single entity, each of the following should be distinct columns in your CSV file. The required/optional fields are only relevant if importing this information - otherwise, all fields are optional.

Next Treatment Description - next_treatment_description (required)

• A short description of the treatment.

Next Treatment Reason - next_treatment_reason (required)

• A brief reasoning for implementing the treatment.

Next Treatment ID - next_treatment_id (optional):

• The unique treatment id of the treatment definition that is being set as the next intervention for the component.
• This can be ignored if the next treatment is defined with a ‘Fixed Value’.

Next Treatment Cost Units - next_treatment_cost_units (optional):

• An override option to the component’s cost units value for the next treatment.
• This will be set if the next treatment only pertains to a known quantity subset of the component.

Next Treatment Cost Unit Factor (%) - next_treatment_cost_unit_factor (optional)

• This is another override option to the component’s cost units value for the next treatment.
• Instead of a known quantity, this value will set a cost unit value relative to the component cost unit value.
• This is typically 100% for standard renewal plans.

Next Treatment Fixed Value - next_treatment_fixed_value (optional)

• Set this value - in lieu of the above three (3) fields - if the next treatment is defined by a fixed/quoted price.

Next Treatment Date - next_treatment_expected_date (optional)

• An estimated date that the next treatment should occur.

See also Treatment ID

Update Spatial Features

This document provides even more information as well as suggestions around importing data to update existing spatial features in the Metrix Asset Management system. It is broken into a number of sub-sections to assist readers in being able to focus on different asset management data contexts separately. These include:

Spatial Definition Fields

The following fields enable users to update existing spatial features, by ‘Shape ID’, using a WKT spatial definition.

Shape WKT

The WKT stands for Well Known Text ↗ which is a method of writing simple geometry features into a standard text string. This field allows users to define such a geometry as the spatial feature representing the component.

• Header label: shape_wkt
• A valid spatial feature is a mandatory element of the system.

See also Guide to WKT ↗

Shape ID

Set this value to link the unique ‘Shape ID’ that is currently defined in the system.

• Header label: shape_id
• The shape ID can be copied from the ‘Spatial’ section of the Component info panel.

See also Component info panel ↗

Financial Ledger Transaction

This document provides even more information as well as suggestions around importing data to create financial ledger transaction entries in the Metrix Asset Management system. It is broken into a number of sub-sections to assist readers in being able to focus on different asset management data contexts separately. These include:

Fixed Transaction Fields

The following fields form the basis of the transaction import.

Component ID

This field is the unique ID of the component throughout the system.

• Header label: component_record_id
• This value is case sensitive and should be copied from the component info panel directly.

See also Component info panel ↗

Posting Date

This is the date in which the transactions should be recognised in the financial ledger.

• Header label: posting_date
• Don’t forget that date values should be formatted ‘DD/MM/YYYY’.
• If the data import is for a site initialisation, users typically set this value to the end of the last financial reporting period - i.e. 30/06/2023 for the 2023 EOY.

Finance Category ID

This is the unique ID of the finance category that the imported transactions will be assigned to.

• Header label: finance_category
• The finance category ID can be copied from the finance categories configuration page.
• If a component carries value, and transaction postings are being imported, this is a REQUIRED field.
• If a component has no current transaction postings, this is a REQUIRED field.

Transaction Type Headers

Following the above fixed columns, the next set of columns to include are for transaction types and their corresponding transaction value.

For each ‘Transaction Type’ with a corresponding value for a row’s component, the transaction type ID ↗ must be used as the header value, and the transaction value constitutes the cell value for each row.