Difference between revisions of "Collision Resolution Error"

Revision as of 09:18, 30 April 2015

This page explains what happens behind the scenes when attempting to resolve a collision yields this error:

Collisions - Link to review

To review what collisions are and how to resolve them please visit the Collisions page

What happens when a Collision Resolution Error happen?

TrackAbout Support proactively monitors these errors the same way we monitor Sync Problems. The work flow for these issues follow this flow:

As soon as an error is generated, a Support ticket is created.
TrackAbout Support addresses these issues as quickly as possible. (We place them at the top of our queue.)
After the problem has been resolved, a TrackAbout Support Specialist will email the user who attempted to resolve the collision.
- There are times when our attempts to resolve the underlying problem did not resolve the issue or that it uncovered another issue with that collision resolution. If that happens then when that collision is attempted again, a new Support ticket will be generated. TrackAbout Support will again proactively fix the underlying problem and communicate with the user who attempted to resolve the collision.

The Underlying Cause

There are two issues that make up the majority of collision resolution errors:

The resolution would cause a customer's non-exchange NS balance to go negative
Two different records have the same effective date / time.

Potential Negative Not Scanned (NS) balance

These errors occur when the resolution of a collision would reduce a customer's DNS or RNS balance below zero.

The general scenario is as follows:

A customer's NS balance is taken to zero by some action (Reduce NS Balance, Customer Audit, etc.)
Later, Asset A, which at one point was on the customer's balance, is merged with Asset B. Asset B's history now reduces the customer's balance prior to the action which zeroed out DNS and RNS balances.
Now that Asset B (merged into Asset A) has caused the balance to go negative, the ensuing action which zeroed out the DNS and RNS balances now causes the NS balance to go negative, causing the error.

This issue can be exacerbated if collisions are not resolved in a timely manner.

Same Effective Date

These errors occur when the resolution of a collision would create a record that has the same effective date as a record that already exists in the system.

When an action is saved in TrackAbout via a mobile device the time captured is down to the second. You will notice in the screenshot above that the time is 2:42:55. Because these records have a time captured to the second, it is very unlikely that they will encounter a Same Effective Date Error.

The majority of these errors come from records that are created on the website - Edit, locate, add new, invoices, maintenance, etc. These records will end in :00 as the user is not able to choose the time down to the second.

If you are attempting to save a record on the website with an effective date that already exists, you have seen this error message:

The same rules apply to collisions as current actions being saved to the system.

@@ Line 1: / Line 1: @@
-This page is to give TrackAbout customers a better understanding of what is happening behind the scenes when you are trying to resolve a collision and you run into this error:
+This page explains what happens behind the scenes when attempting to resolve a collision yields this error:
 [[File:2015-03-26 16_35_01-https___www.trackabout.com_error_error.aspx.gif|800px]]
@@ Line 8: / Line 8: @@
 ==What happens when a Collision Resolution Error happen?==
 TrackAbout Support proactively monitors these errors the same way we monitor Sync Problems. The work flow for these issues follow this flow:
-*An error is generated in TrackAbout and emailed to the Support Team as a ticket.
+*As soon as an error is generated, a Support ticket is created.
-*Once the ticket is in the support queue it will be addressed as quickly as possible
+*TrackAbout Support addresses these issues as quickly as possible. (We place them at the top of our queue.)
-*After the problem has been resolved, a TrackAbout Support Specialist will email the customer that attempted to resolve the collision.
+*After the problem has been resolved, a TrackAbout Support Specialist will email the user who attempted to resolve the collision.
-**There are times that our attempts to resolve the underlying problem did not resolve the issue or that it uncovered another issue with that collision resolution. If that happens then when that collision is attempted again, a new error will be generated and sent to TrackAbout.
+**There are times when our attempts to resolve the underlying problem did not resolve the issue or that it uncovered another issue with that collision resolution. If that happens then when that collision is attempted again, a new Support ticket will be generated. TrackAbout Support will again proactively fix the underlying problem and communicate with the user who attempted to resolve the collision.
 ==The Underlying Cause ==
-There are two issues that make up the vast majority of collision resolution errors and they are based on two of the "golden rules" of the TrackAbout asset tracking system. A customer's balance cannot fall below zero, unless another configuration permits it (see [[Exchange Balances]]) and two different records cannot have the exact same effective date/time.
+There are two issues that make up the majority of collision resolution errors:
+* The resolution would cause a customer's non-exchange NS balance to go negative
+* Two different records have the same effective date / time.
 ===Potential Negative Not Scanned (NS) balance===
-These errors occur when the resolution of a collision would reduce a customer balance below zero. Because TrackAbout does not allow a customer balance to fall below zero, an error is generated.
+These errors occur when the resolution of a collision would reduce a customer's DNS or RNS balance below zero.
-Generally the underlying cause will be a Reduce NS balance, Customer Audit, or RightSize action that has been performed on a customer account. Because these "manual" adjustments to customer accounts are created without first resolving all collisions and these actions are not able to take into account the potential customer balance changes from collision records, the eventual resolution of a collision will error. Consider the following example.
+The general scenario is as follows:
+* A customer's NS balance is taken to zero by some action (Reduce NS Balance, Customer Audit, etc.)
-# An action that would return an asset causes a collision - This collision is not resolved promptly. If it were resolved at this point, no collision resolution error would occur.
+* Later, Asset A, which at one point was on the customer's balance, is merged with Asset B. Asset B's history now reduces the customer's balance ''prior to'' the action which zeroed out DNS and RNS balances.
-# The customer balance is modified through a bulk action, such as a Customer Audit.
+* Now that Asset B (merged into Asset A) has caused the balance to go negative, the ensuing action which zeroed out the DNS and RNS balances now causes the NS balance to go negative, causing the error.
-# An attempt to resolve the collision from step 1 now generates an error because it is attempting to reduce the customer balance and that balance was already reduce via an Audit (or similar action).
+This issue can be exacerbated if collisions are not resolved in a timely manner.
 ===Same Effective Date===
-In this case the Collision that you are attempting to resolve would create a record that has the same effective date as a record that already exists in the system.
+These errors occur when the resolution of a collision would create a record that has the same effective date as a record that already exists in the system.
 [[File:2015-03-26 16_18_02-Add New Asset Action - Detail View.gif|400px]]
-When an action is saved in TrackAbout via a mobile device the time captured is down to the second. You will notice in the screenshot above that the time is 2:42:55.  Because these records have a time captured to the second, it is very unlikely that they will encounter a Same Effective Date Error. Not to say that it is impossible for an action on a mobile device to have this type of conflict, but the majority of these errors come from records that are created on the website - Edit, locate, add new, invoices, maintenance, etc.  These records will end in :00 as the user is not able to choose the time down to the second.
+When an action is saved in TrackAbout via a mobile device the time captured is down to the second. You will notice in the screenshot above that the time is 2:42:55.  Because these records have a time captured to the second, it is very unlikely that they will encounter a Same Effective Date Error.
+The majority of these errors come from records that are created on the website - Edit, locate, add new, invoices, maintenance, etc.  These records will end in :00 as the user is not able to choose the time down to the second.
 [[File:2015-03-26 16_25_48-Edit Asset Action - Detail View.gif|400px]]