Splitting Assets

The ability to split an Asset is vitally important in keeping the Organisation’s financial reporting, engineering concepts, and asset management data policies in sync. The core concept involves splitting a linear geometry (representing one or more Components associated with an Asset) at any given coordinate, at an effective date.

The returned feature set represents the two (or more in certain cases) new Assets, each containing a distinct copy of the original Components, with each new Component being proportionately associated with one of the two (or more) resultant geometries. The original Asset and Components are deprecated (see section on deprecation).

The following concepts are covered in this article:

Note: This article is specifically addressing Asset Split operations where the goal is to generate two (or more) distinct new Assets with their own Components (mirroring the original). Users may also be interested in reading about splitting asset components whereby the parent Asset is maintained, but a sub-selection of Components are split and duplicated within said parent Asset.

How a Split Works

The basic mechanics of the Asset Split operation is that a user submits a request to the system for a split to occur. The system will respond (assuming no errors occur) with the required Asset, Component, and Resource inserts and updates that need to occur. Accepting this response will process the Split operation. This process is summarised below:

1. User submits request for a split operation
2. System assesses the request and responds with a detailed summary of the inserts and updates required to achieve the split
3. User accepts the response, and the split occurs.

Requesting a Split

To request a split, the following information is required:

• The Split Level (split_level) which must be set to ‘asset’ for an Asset Split.
• The Asset Record ID (asset_uid) of the Asset being split
• The Splitting Blade definition (intersection_wkt) defined in Well Known Text.
• An optional Posting Date (posting_date) for when transactions associated with the split operation should occur. This field will default to the current date/time if empty.
• An optional Effective Date (effective_date) for when the split should occur. This field will default to the current date/time if empty.
• Optional Split Flags (flags) that can control facets of what will be copied across to the new Assets and Components. See ‘Advanced Splitting: Resource Exclusions’ for more information.

System Assesses the Request and Response

Upon receiving a split request, the system will review the prohibitions detailed in the section, ‘When a Split can Occur’. It will then commence building a response that (if accepted by the user) instructs the system on how to:

• Deprecate the Old (split) Asset and Components
• Create the new Asset and Components
• Append the appropriate valuations and resources to the new Assets and Components.

User Accepts the Response and the Split Occurs

After reviewing the response - where the user can investigate in detail what will and wont be created - the user can accept the response and the relative Split Operation will occur.

How the Split Works at a Geometry Level

In order to perform the split, the user must provide a splitting blade - a linear geometry that cuts across the Component geometry/geometries at the desired split coordinate. See screenshot below:

In the above screenshot, the Asset (Twynam Avenue) is highlighted in yellow and the user provided splitting blade is located about 25% along it’s overall length. For the purpose of this example, we will assume that Twynam Avenue has three (3) Components - earthworks, base, and seal - all sharing the same linear geometry running from Governors Parade to Barr Street.

Prior to the split, the Twynam Avenue Asset Components could be represented by the following (basic) attribute data set:

With the ID of the Asset and the definition of the splitting blade supplied, the system first derives the NEW Component Geometries that would result from the split operation. See screenshot below:

In the above screenshot, the split has occurred and the first of the resultant two geometries is highlighted in yellow. The remaining portion of Twynam Avenue is associated with the second of the resultant two geometries.

Following the split, Twynam Avenue is now two (2) distinct Assets whose Components could be represented by the following attribute data set:

Asset 1 (highlighted in yellow)

NOTE: the proportion of length between ‘Asset 1’ and the original Asset is assumed to be 25% - the System has returned the new Cost Unit values based on this geometric truth.

Asset 2 (not highlighted)

NOTE: the returned data for ‘Asset 2’ represents 75% of the original Cost Unit values. All Components have been duplicated to the second Asset and can be managed in isolation of Asset 1 from now on.

When a Split can Occur

The following restrictions are enforced by the system when a user attempts to perform an Asset Split operation:

• The splitting blade MUST pass through the subject Geometry/Geometries at some point.
• The construction/Intervention dates of the Components cannot be after the effective date.
• The status effect of the Components must be active.
• The Component must have no Transaction postings that occur after the posting date.
• The posting date must not conflict with a Locked Financial Year.
• Only linear Geometries can be split.

Resources Assigned to the New Assets

Following an Asset Split, the following resources are copied across to the new Assets. They are discussed in detail below.

• Original Attribution
• Transaction Summary
• Condition History
• Report Categories
• Task Records

Original Attribution

Each new Asset or Component record that is created will inherit it’s attribution from the original Asset or relevant Component. Attributes are copied to the new Assets and Components unchanged - The ONLY EXCEPTION to this is the cost units value, which is modified by the Component’s relative proportionality.

Transaction Summary

Each new Component record that is created will inherit a proportionate baseline value from the original relevant Component and the original Component’s Value is written-off. This means there is ZERO change in overall value in the system. Consider the following 50/50 split of a single Component into two (2) new Components.

The original transaction schedule would look something like this, with the carrying value displayed at the bottom.

As a part of the Asset Split operation, the following transaction schedule would be generated and applied. Note: transaction schedule simplified to years for the example.

By the end of the process, the valuation summary for ALL Components would be:

Condition History

For each newly created Component, the relevant Condition History is copied to across in a split operation. The term ‘relevant’ refers to whether or not the Condition record concerned the spatial bounds associated with the new Component (see section: Advanced Splitting: Multiple Geometry Features), as well as whether or not the Condition record existed at the ‘Effective Date’ for the split operation.

The following table details this concept of ‘relevant’ Condition history for an Effective Date of 12/10/2000. Note, each row represents a Condition record that lasts from the Assessment Date until the Assessment Date of the subsequent row. That is, the above Component was considered to be in Condition 1 from January 1993 to February 1997.

Note: this condition record is carried over, however the Assessment Date is set to the Effective Date (October 2000) and a comment is added to reflect the original Assessment Date.

Report Categories

For each newly created Component, the LATEST (as at the Effective Date) relevant Report Categories are copied across in a split operation. That is, if a Component held a Special Schedule 7 Category of ‘Roads’ at the Effective Date, each new Component would inherit this Report Category.

Task Records

For each newly created Component, the relevant Task Records are copied across in a split operation. This occurs at both the Asset and Component Register level. Please note, the same rules of ‘relevancy’ that apply to the Condition History, apply to Task Records.

What happens to the Original Asset and Components

Following an Asset Split operation, the original Asset and ALL of it’s Components are marked with a status code of ‘Deprecated’. This is a special system status code (that users cannot access) which marks the record as ‘superseded by another record or records’. Deprecated records remain in the system, but they are excluded from the default map view, tables, filters, dashboards, and reports.

Information associated with a Deprecated Asset record can be fetched via the NEW Asset record(s). Each new record maintains a ‘Deprecated Parent’ linkage back to the original Asset.

Note: In the case of an Asset Split operation, only the Asset records receive a Deprecated Parent link back to the original Asset. The Component’s do not receive such a linkage in this case as the operation was at the Asset level.

Advanced Splitting: Multiple Geometry Features

In certain situations, an Asset’s Components may not all be represented by the same Geometry record. See the cross-section view below:

In the above example, the Asset (Twynam Avenue) is associated with five (5) Components. An earthworks Components, represented by a single Geometry running from Governors Place to Barr Street. Two (2) base Components running from Governors Place to Matthews Street and then from Matthews Street to Barr Street. And Two (2) seal Components running from Governors Place to Matthews Street and then from Matthews Street to Barr Street (identical to the base).

Given the above scenario, if Poate Street was to be extended such that it now crosses Twynam Avenue, the Asset Management and Engineering principles may require Twynam Avenue to be now represented as two (2) Assets, split by it’s intersection with Poate Street. In this case, the splitting blade would look like the following:

In the above, the Twynam Avenue Asset is to be split by its new full intersection with Poate Street. For the purpose of the example, we will assume the split blade is 75% along the original Asset’s length.

The resultant Assets and Components of such a split are shown below. The original Seal 1 and Base 1 features are not altered by proportionality, they are simply copied and associated with the new, shorter, Twynam Avenue Asset. The Seal 2, Base 2, and Earthworks Components however, are split between the two new Twynam Avenue Assets.

In the above, the Twynam Avenue Asset is to be split by its new full intersection with Poate Street. For the purpose of the example, we will assume the split blade is 75% along the original Asset’s length.

The association and proportion share of the new Assets and Components can be represented in the following table. As can be seen, Base 1 and Seal 1 features are copied and wholly associated with the first Asset (Governors Pde to Matthews Street). However, the Earthworks, Base 2, and Seal 2 are copied and distributed across the splitting blade.

Splitting Asset Components

The ability to split a Component is vitally important in keeping the Organisation’s financial reporting, engineering concepts, and asset management data policies in sync. The core concept involves splitting a linear geometry ( representing one or more Components) at any given coordinate, at an effective date.

The returned feature set represents the two or more new Components, each containing a distinct copy of the original Components, with each new Component being proportionately associated with one of the two (or more) resultant geometries. The original Components are deprecated (see section on deprecation) and the new Components are inherited by the original Asset.

The following concepts are covered in this article:

Note: This article is specifically addressing Component Split operations where the goal is to maintain the single Asset parent. Users may also be interested in reading about asset splitting whereby the parent Asset is also deprecated and the result is two (or more in certain cases) new Assets with all new associated Components.

How a Split Works

The basic mechanics of the Component Split operation is that a user submits a request to the system for a split to occur. The system will respond (assuming no errors occur) with the required Component/Resource inserts and updates that need to occur. Accepting this response will process the Split operation. This process is summarised below:

1. User submits request for a split operation
2. System assesses the request and responds with a detailed summary of the inserts and updates required to achieve the split
3. User accepts the response, and the split occurs.

Requesting a Split

To request a split, the following information is required:

• The Split Level (split_level) which must be set to ‘component’ for a Component Split.
• The Asset Record ID (asset_uid) of the Asset that ‘owns’ the Component(s) being split.
• The Component Record IDs (component_uids) of the Component(s) that are being split.
• The Splitting Blade definition (intersection_wkt) defined in Well Known Text.
• An optional Effective Date (effective_date) for when the split should occur. This field will default to the current date/time if empty.
• Optional Split Flags (flags) that can control facets of what will be copied across to the new Components. See ' Advanced Splitting: Resource Exclusions’ for more information.

System Assesses the Request and Response

Upon receiving a split request, the system will review the prohibitions detailed in the section, ‘When a Split can Occur’. It will then commence building a response that (if accepted by the user) instructs the system on how to:

• Deprecate the Old (split) Components
• Create the new Components against the original Asset
• Append the appropriate valuations and resources to the new Components.

User Accepts the Response and the Split Occurs

After reviewing the response - where the user can investigate in detail what will and wont be created - the user can accept the response and the relative Split Operation will occur.

How the Split Works at a Geometry Level

In order to perform the split, the user must provide a splitting blade - a linear geometry that cuts across the Component geometry/geometries at the desired split coordinate. See screenshot below:

*In the above screenshot, the Asset (Twynam Avenue) is highlighted in yellow and the user provided splitting blade is
located about 25% along it’s overall length. For the purpose of this example, we will assume that Twynam Avenue has
three (3) Components - earthworks, base, and seal - all sharing the same linear geometry running from Governors Parade
to Barr Street.*

Prior to the split, the Twynam Avenue Components could be represented by the following (basic) attribute data set:

Assuming the user only wants to split the Base and Surface Components (leaving the Earthworks untouched), they would supply the Asset Record ID, and the two (2) Component ID’s relating to the Surface and Base. The system then derives the NEW Component Geometries that would result from the split operation. See screenshot below:

*In the above screenshot, the split has occurred and the first of the resultant two geometries is highlighted in
yellow - a portion of the base and seal will be associated with this geometry. The remaining portion of base and seal
Components are associated with the second of the resultant two geometries. The earthworks are still associated with the
original geometry record.*

Following the split, Twynam Avenue is still one distinct Asset, however, instead of having three (3) Components, it now has five (5). The new Component Structure (ignoring deprecated Components) would look like this:

NOTE: the proportion of length between the smaller geometry and the original Asset is assumed to be 25% - the System has returned the new Cost Unit values based on this geometric truth.

When a Split can Occur

The following restrictions are enforced by the system when a user attempts to perform an Asset Split operation:

• The splitting blade MUST pass through the subject Geometry/Geometries at some point.
• The construction/Intervention dates of the Components cannot be after the effective date.
• The status effect of the Components must be active.
• The Component must have no Transaction postings that occur after the effective date.
• The effective date must not conflict with a Locked Financial Year.
• Only linear Geometries can be split.

Resources Assigned to the New Components

Following a Component Split, the following resources are copied across to the new Components. They are discussed in detail below.

• Original Attribution
• Transaction Summary
• Condition History
• Report Categories
• Task Records

Original Attribution

Each new Component record that is created will inherit it’s attribution from the original relevant Component. Attributes are copied to the new Components unchanged - The ONLY EXCEPTION to this is the cost units value, which is modified by the Component’s relative proportionality.

Transaction Summary

Each new Component record that is created will inherit a proportionate baseline value from the original relevant Component and the original Component’s Value is written-off. This means there is ZERO change in overall value in the system. Consider the following 50/50 split of a single Component into two (2) new Components.

The original transaction schedule would look something like this, with the carrying value displayed at the bottom.

As a part of the Component Split operation, the following transaction schedule would be generated and applied. Note: transaction schedule simplified to years for the example.

By the end of the process, the valuation summary for ALL Components would be:

Condition History

For each newly created Component, the relevant Condition History is copied to across in a split operation. The term ' relevant’ refers to whether or not the Condition record concerned the spatial bounds associated with the new Component ( see section: Advanced Splitting: Multiple Geometry Features), as well as whether or not the Condition record existed at the ‘Effective Date’ for the split operation.

The following table details this concept of ‘relevant’ Condition history for an Effective Date of 12/10/2000. Note, each row represents a Condition record that lasts from the Assessment Date until the Assessment Date of the subsequent row. That is, the above Component was considered to be in Condition 1 from January 1993 to February 1997.

Note: this condition record is carried over, however the Assessment Date is set to the Effective Date (October 2000) and a comment is added to reflect the original Assessment Date.

Report Categories

For each newly created Component, the LATEST (as at the Effective Date) relevant Report Categories are copied across in a split operation. That is, if a Component held a Special Schedule 7 Category of ‘Roads’ at the Effective Date, each new Component would inherit this Report Category.

Task Records

For each newly created Component, the relevant Auxiliary Data Records are copied across in a split operation. Please note, the same rules of ‘relevancy’ that apply to the Condition History, apply to Task Records.

What happens to the Original Components

Following a Component Split operation, the original Components are marked with a status code of ‘Deprecated’. This is a special system status code (that users cannot access) which marks the record as ‘superseded by another record or records’. Deprecated records remain in the system, but they are excluded from the default map view, tables, filters, dashboards, and reports.

Information associated with a Deprecated Component record can be fetched via the NEW Component record(s). Each new record maintains a ‘Deprecated Parent’ linkage back to the original Component.

Advanced Splitting: Resource Exclusions

When requesting a Component Split operation, a user can supply some optional flags that will alter what resources the newly created Components will receive. The flags currently available in the system are:

• Apportion Cost Units (apportion_cost_units - true/false): If not supplied, this defaults to TRUE. This flag indicates that the user wishes for the Cost Unit values of each new Component to be proportionately set based on its ' share’ of the original Component. If set to FALSE, each new Component will receive a Cost Units value equal to that of it’s parent Component.
• Copy Condition History (copy_condition_history - string): If not supplied, this defaults to all. This flag indicates what sort of Condition History the user would like to translate to the new Components. The following options are available:
  • all (default): All relevant Condition history will be copied.
  • latest: Only the most recent Condition record (relative to Effective Date) will be copied.
  • none: No Condition records will be copied.
• Copy Report Categories (copy_report_categories - true/false): If not supplied, this defaults to TRUE. This flag indicates that the user wishes for the relevant Report Categories to be copied to the new Components.
• Copy Task Records (copy_auxiliary_data - string): If not supplied, this defaults to all. This flag indicates what sort of Task Record History the user would like to translate to the new Components. The following options are available:
  • all (default): All relevant Records will be copied.
  • latest: Only the most recent Record (relative to Effective Date) will be copied.
  • none: No Records will be copied.

Advanced Splitting: Multiple Geometry Features

In certain situations, an Asset’s Components may not all be represented by the same Geometry record. See the cross-section view below:

*In the above example, the Asset (Twynam Avenue) is associated with five (5) Components. An earthworks Components,
represented by a single Geometry running from Governors Place to Barr Street. Two (2) base Components running from
Governors Place to Matthews Street and then from Matthews Street to Barr Street. And Two (2) seal Components running
from Governors Place to Matthews Street and then from Matthews Street to Barr Street (identical to the base).*

Given the above scenario, if Poate Street was to be extended such that it now crosses Twynam Avenue, the Asset Management and Engineering principles may require the Component’s of Twynam Street to reflect this new extent. In this case, the splitting blade would look like the following:

*In the above, the Twynam Avenue Components are to be split by its new full intersection with Poate Street. For the
purpose of the example, we will assume the split blade is 75% along the original Asset’s length.*

The resultant Components of such a split are shown below. The original Seal 1 and Base 1 features are not altered by proportionality, they are therefore UNMODIFIED by the split operation. The Seal 2, Base 2, and Earthworks Components however, are split by the intersection blade.

*In the above, the Twynam Avenue Components are to be split by its new full intersection with Poate Street. For the
purpose of the example, we will assume the split blade is 75% along the original Asset’s length.*

The association and proportion share of the new Components can be represented in the following table. As can be seen, Base 1 and Seal 1 features are left UNMODIFIED. However, the Earthworks, Base 2, and Seal 2 are copied and distributed across the splitting blade.

Deprecated Records

Following an action that results in assets or components being regenerated into a new entity, the original records will be marked as ‘deprecated’. This is a special system status code (that users cannot access) which marks the record as ‘superseded by another record or records’. Deprecated records remain in the system, but they are excluded from the default map view, tables, filters, dashboards, and reports.

Information associated with a Deprecated records can be fetched via the NEW (replacing) record(s). Each new record maintains a ‘Deprecated Parent’ linkage back to the original record. This can be accessed via the Actions menu at the top of the info panel.

Finance Re-Categorisation

A component’s finance category is defined by the first entry into the financial transactions ledger posted against that component. Following that, all transactions against that component will utilise that same finance category. To change a component’s finance category, the adjustment must be recorded through the financial transactions ledger as a movement off the original category, and then on to the new category.

Below is a summary of the involved movements posted during a financial re-categorisation from ‘Roads’ to ‘Footpaths’.

Note: In the above example, the gross value is $200, and the accumulated depreciation is -$150

In the above schedule, the process involves:

1. Writing off the accumulated depreciation value from the old category
2. Writing off the gross value from the old category
3. Writing on the gross value for the new category
4. Writing on the accumulated depreciation value for the new category

Importantly, the net change in carrying value for the component is zero.

Financial Re-Categorisation

To perform a financial re-categorisation, firstly, ensure that you understand the purpose and implications of such a process. Then, simply follow these steps.

1. Navigate to the main ‘Assets’ page and make a selection from the map screen.

   Ensure the correct asset component is your active selection.

2. Within the transactions info panel is a section title ‘Transaction History’. It is here that users can see past recorded movements, as well as perform financial re-categorisations.

3. At the top of the ‘Transaction History’ section, click on the ‘Reclassify’ button.

   Info

   If the summary table and/or the ‘Reclassify’ button is not displayed for your active component, it typically means that the asset component does not have any transactions posted against it. This therefore indicates that re-categorisation is NOT necessary.

4. A fly-out panel will display, requiring the target finance category and posting date for the change to occur.

5. Enter the posting date for the financial re-categorisation to occur using the calendar input.

6. Select the target finance category from the drop-down list.

7. Provide an optional comment.

8. Click ‘Reclassify’ when ready.

9. This operation does NOT proceed via staged changes, and occurs immediately. You have successfully re-categorised your component.

Splitting Assets or Components

The ability to split an Asset is vitally important in keeping the Organisation’s financial reporting, engineering concepts, and asset management data policies in sync. This section provides an overview on two different methods supported by the Metrix Asset Management system to perform spatial, linear bisections of your assets or asset components.

• Split Asset
• Split Asset Components
• Explode Multi-Geometry features

For a basic overview of how splitting works, please see the video below:

Reclassification

From time to time, an organisation’s asset infrastructure will undergo different purposes - or data management practices may adjust. In these cases, it can become necessary to reclassify assets and/or components to different asset classifications (or component groups). This section provides an overview on two different methods supported by the Metrix Asset Management system to perform reclassification of assets (including the asset components) or components.

• Reclassify Asset
• Reclassify Component within Asset Classification

For a basic overview of how reclassification works, please see the video below:

Set Component Status

This section provides an overview on how to alter a component’s status code in the Metrix Asset Management system:

1. Navigate to the main ‘Assets’ page and make a selection from the map screen.

   Info

   Make sure you have the correct component selected - the one you wish to update the status for

2. The component’s status is referenced toward the top of the ‘Info’ tab in the component information panel. To the right of this label, exists an option to ‘Update Status’ for the active component. Click this drop down list and choose the desired status from the options presented.

   Alternatively, setting the status in an option in the Info Panel ‘Actions’ menu. From the ‘Actions’ menu, choose ‘Set Component Status’ and then, from the sub-menu, choose the target component status that you wish to set.

   

3. A fly-out panel will appear seeking confirmation for the status change. If the target status effect is ‘inactive’, the system will also generate the required financial transactions ledger postings required to successfully set the status.

   These transactions are designed to ensure that ‘inactive’ components (i.e. disposed) do not carry any value or have any gross value. If you proceed, the transactions will be posted to your ledger.

4. Once satisfied with the proposed change, click the confirmation button at the bottom of the panel.

5. This operation does NOT proceed via staged changes, and occurs immediately. You have successfully updated the status on your component.

Deleting Assets & Components

From time to time, you may create a new asset or asset component and that eventuates to being a mistake. For these scenarios, the Metrix Asset Management system has support for users deleting assets or asset components.

Delete Assets

To delete an asset record and its asset components:

1. Navigate to the main ‘Assets’ page and make a selection from the map screen.

2. At the top of the info panel, click the ‘Actions’ menu.

3. From the ‘Actions’ menu options, hover or select ‘Parent Asset Actions’ and then choose ‘Delete Asset’.

4. The asset deletion has been STAGED and is ready to save.

Delete Component

To delete an asset component from a parent asset:

1. Navigate to the main ‘Assets’ page and make a selection from the map screen.

   Info

   Make sure you have the correct component selected - the one you wish to delete.

2. At the top of the info panel, click the ‘Actions’ menu.

3. From the ‘Actions’ menu options, choose ‘Delete Component’.

4. The component deletion has been STAGED and is ready to save.