Merging Assets
The ability to merge 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 merging/combining two or more spatial features (representing one or more Assets), at an effective date.
The returned feature represents a new combined Asset, containing a distinct copy of the original Asset and Component’s data, with each being associated with parent Assets/Components. The original Assets and Components are deprecated (see section on deprecation).
The following concepts are covered in this article:
Note: This article is specifically addressing Asset Merge operations where the goal is to generate one new Asset with its own Component(s) from two or more Assets. At the date of publication of this guide, the ability to merge Components within an Asset is not supported by this tool.
How a Merge Works
The basic mechanics of the Asset Merge operation is that a user submits a request to the system for a merge 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 Merge operation. This process is summarised below:
- User submits request for a merge operation
- System assesses the request and responds with a detailed summary of the inserts and updates required to achieve the merge
- User resolves any merge conflicts identified by the system (such as conflicting attribute values)
- User accepts the response, and the merge occurs.
For Components within each Asset, they will be merged in accordance with their Component Group classification. For example, when merging two road Assets, all child Surface Components will be merged together, all child base Components will be merged together, and all child earthwork Components will be merged together.
Requesting a Merge
To request a merge, the following information is required:
- The Asset Record IDs (
asset_uid) of the Assets being merged - A Posting Date (
posting_date) for when any transactions associated with the merge operation should occur. This field will default to the current date/time if empty.
System Assesses the Request and Response
Upon receiving a merge request, the system will review the prohibitions detailed in the section, ‘When a Merge can Occur’. It will then commence building a response that (if accepted by the user) instructs the system on how to:
- Deprecate the Old (merged) Assets and Components
- Create the new Asset and Components
- Append the appropriate valuations and resources to the new Asset and Components.
During this process, the system analyses the Asset and Component attribution from all records being merged. Any conflicting values will be flagged to the user for resolution.
User Resolves any Merge Conflicts Identified by the System
The system will return a summary of merge request. This summary will include details regarding any conflicts that need to be resolved before continuing. Along with each conflict, the system will return some suggested values that might resolve the conflict. Where appropriate (for numeric values) the suggested values may include sums, averages, min and/or max values of the input Components for the Component Group in question.
Examples of conflicts, system suggestions, and possible ways to resolve them, include:
- Mismatch Cost Units: This is expected as each Component being merged will likely have a different value for Cost Units, reflecting their individual size/quantity. The system will return the sum of all Cost Units for that Component Group, as well as the average, the min, and the max value across the Component Group. Users may wish to elect the SUM value, reflecting the fact that the new Components size will be an aggregate of each input Components size.
- Mismatch Custom Text Attribute: This can occur from time to time and will typically not be accompanied by any ‘smart’ sugestions (sum, average, etc.). Users will be asked to choose one of the values from the input Components for the Component Group.
In all of the above examples, and during any merge operation, users do NOT have to settle for any of the suggested values (smart or otherwise). In all cases, a manual override is available for conflicting attributes.
User Accepts the Response and the Merge Occurs
After reviewing the response and resolving all merge conflicts - where the user can investigate in detail what will and wont be created - the user can accept the response and the relative Merge Operation will occur.
How the Merge Works at a Component by Component Level
In order to perform the merge, the user must provide two or more valid Asset Records.
Prior to the merge, the Twynam Avenue Asset Components could be represented by the following (basic) attribute data set:
Asset 1
| Description | Component Class | Cost Units | Units of Measure | Treatment |
|---|---|---|---|---|
| Twynam Avenue Earthworks | Earthworks | 89.25 | metres | nil |
| Twynam Avenue Base | Base | 89.25 | metres | 300mm Compacted Gravel Base |
| Twynam Avenue Seal | Surface | 535.5 | square metres | 10mm Seal |
Asset 2
| Description | Component Class | Cost Units | Units of Measure | Treatment |
|---|---|---|---|---|
| Twynam Avenue Earthworks | Earthworks | 267.75 | metres | nil |
| Twynam Avenue Base | Base | 267.75 | metres | 300mm Compacted Gravel Base |
| Twynam Avenue Seal | Surface | 1606.5 | square metres | 14mm Seal |
NOTE: each Surface Component have differing values for ‘Treatment’. This will be a merge conflict that user must resolve in order to complete the merge. Additionally, each of the Cost Unit value conflicts (per Component Group) will need to be resolved.
The system, upon reviewing the merge request, will return a merge preview response highlighting any merge conflicts. For the above example (and for the information supplied), the following merge conflicts are likely:
| Component Class | Merge Conflict | Values Encountered | Possible Sollutions |
|---|---|---|---|
| Earthworks | Cost Units | 89.25, 267.75 | Sum(357), Avg(178.5), Min(89.25), Max(267.75), Other (User Defined) |
| Base | Cost Units | 89.25, 267.75 | Sum(357), Avg(178.5), Min(89.25), Max(267.75), Other (User Defined) |
| Surface | Cost Units | 535.5, 1606.5 | Sum(2142), Avg(1071), Min(535.5), Max(1606.5), Other (User Defined) |
| Surface | Treatment | 10mm Seal, 14mm Seal | 10mm Seal, 14mm Seal, Other (User Defined) |
For the above merge conflict, the resolution may be the following:
| Component Class | Merge Conflict | Solution |
|---|---|---|
| Earthworks | Cost Units | 357 (sum) |
| Base | Cost Units | 357 (sum) |
| Surface | Cost Units | 2142 (sum) |
| Surface | Treatment | 10mm Seal |
Following the merge, Twynam Avenue is now one (1) distinct Asset whose Components could be represented by the following attribute data set:
| Description | Component Class | Cost Units | Units of Measure | Treatment |
|---|---|---|---|---|
| Twynam Avenue Earthworks | Earthworks | 357 | metres | nil |
| Twynam Avenue Base | Base | 357 | metres | 300mm Compacted Gravel Base |
| Twynam Avenue Seal | Surface | 2142 | square metres | 10mm Seal |
When a Merge can Occur
The following restrictions are enforced by the system when a user attempts to perform an Asset Merge operation:
- At least two (2) Assets must be submitted for merge.
- All Assets within the merge operation must share the same Asset Classification.
- The construction/Intervention dates of the Components cannot be after the posting 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.
- For each Component Group, the Finance Category for associated Capital Value must be the same.
- The Asset Components must not have any outstanding WIP transactions (from a Capital Budget process).
- The Assets or Components must not have any outstanding Programming Tasks.
Resources Assigned to the New Asset
Following an Asset Merge, the following resources are migrated to the new Asset. They are discussed in detail below.
- Original Attribution (with consideration for any merge conflict instruction)
- Transaction Summary
- Condition (with consideration for any merge conflict instruction)
- Report Categories (with consideration for any merge conflict instruction)
Original Attribution
The Asset/Component record that is created will inherit it’s attribution from the original Assets or relevant Components. Attributes are copied to the new Assets and Components unchanged (excepting any merge conflict instrucitons).
Transaction Summary
Each new Component record that is created will inherit a combined baseline value from the original relevant Components and the original Componens Value is written-off. This means there is ZERO change in overall value in the system. Consider the following merge of two (2) Components into one (1) new Component.
The original transaction schedule would look something like this, with the carrying value displayed at the bottom. For Component 1,
| Comp ID | Year | Transaction Type | Value |
|---|---|---|---|
| comp_1 | 2015 | Recognition (Gross) | $1500 |
| comp_1 | 2016 | Annual Depreciation | -$150 |
| comp_1 | 2017 | Annual Depreciation | -$150 |
| comp_1 | 2018 | Annual Depreciation | -$150 |
| comp_1 | 2019 | Annual Depreciation | -$150 |
| $900 |
For Component 2,
| Comp ID | Year | Transaction Type | Value |
|---|---|---|---|
| comp_2 | 2015 | Recognition (Gross) | $2000 |
| comp_2 | 2016 | Annual Depreciation | -$200 |
| comp_2 | 2017 | Annual Depreciation | -$200 |
| comp_2 | 2018 | Annual Depreciation | -$200 |
| comp_2 | 2019 | Annual Depreciation | -$200 |
| $1200 |
As a part of the Asset Merge operation, the following transaction schedule would be generated and applied. Note: transaction schedule simplified to years for the example.
| Comp ID | Year | Transaction Type | Value | Comment |
|---|---|---|---|---|
| comp_1 | 2020 | Adjustment (Depreciation) | $600 | Writing off the accumulated depreciation |
| comp_1 | 2020 | Adjustment (Gross) | -$1500 | Writing off the gross value |
| comp_2 | 2020 | Adjustment (Depreciation) | $800 | Writing off the accumulated depreciation |
| comp_2 | 2020 | Adjustment (Gross) | -$2000 | Writing off the gross value |
| comp_3 | 2020 | Recognition (Gross) | $3500 | Bringing on the sum of gross value to the merged new Component. |
| comp_3 | 2020 | Recognition (Gross) | -$1400 | Bringing on the sum of accumulated depreciation to the merged new Component. |
By the end of the process, the valuation summary for ALL Components would be:
| Comp ID | Gross Value | Depreciation Value | Carrying Value |
|---|---|---|---|
| comp_1 | $0 | $0 | $0 |
| comp_2 | $0 | $0 | $0 |
| comp_3 | $3500 | -$1400 | $2100 |
| $3500 | -$1400 | $2100 |
Condition
For the newly created Component, the relevant Condition is copied across in a merge operation. On conflict, the user will be asked to choose which Condition value should be applied.
Report Categories
For the newly created Components, the LATEST (as at the Effective Date) relevant Report Categories are copied across in a merge 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. This is, of course, subject to any merge conflict instructions.
What happens to the Original Assets and Components
Following an Asset Merge operation, the original Assets and ALL of their 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.