One set of alerts, specific to periodic trackers, is designed to alert the user when dates on certain activity records appear inconsistent with the periodicity configured for the corresponding tracker. Ultimately, they are intended to help the user find billing or data entry mistakes, in particular, extra or missing records.
At times, there may be anomalies in a certain tracker's activity record dates that trigger one or more alerts regarding records that are actually legitimate. Anticipating this case, Scope 5's alerting system was built to allow the user to dismiss specific alerts that the user determines to be spurious. In this article, we discuss a specific set of alerts, why they occur and how to dismiss them if appropriate. These are the extra and missing record alerts.
For a broader discussion on periodic tracker alerts and the ability to configure alerting thresholds on an individual account basis, see this article.
A Month Doesn't Mean Exactly One Month
Before proceeding, it's helpful to understand periodic tracker tolerance. Many trackers are configured for certain periods to correspond to utility billing cycles. Most commonly, that cycle is monthly. However, most real utilities don't generate bills exactly one month apart. In reality, there is some variability around one month intervals. For example, a bill might be issued on February 28th and the next bill might be issued on March 25th. Although these are not exactly one month apart, they are close to one month and the deviation from the expected cycle should not trigger an alert. The Scope 5 alerting system is designed to tolerate eight days of variability around the tracker's configured periodicity. In the particular example cited, the March record would have been expected on March 28th. It is dated three days earlier, which falls into the eight day tolerance window. As a result, no alert would be generated.
Sometimes Variations Exceed the Threshold
Consider the following sample ledger, extracted from a monthly electricity tracker:
We see that most of the records are dated close to the 10th of each month. However, the August record is dated on the first of the month when we would have expected it to be dated closer to the tenth. It's probably legitimate - we still seem to have one record for each month, but it does fall sufficiently far from the expected date (beyond the eight day tolerance window) that it triggers a couple of alerts:
The first alert is telling us that the gap between the July 12th record and the August 1st record is less than one month (20 days), even allowing for eight days of variability. One of those records might be an extra record.
The second alert is telling us that there is more than one month gap between the August 1st record and the September 10th record (40 days). A record might be missing.
Upon reviewing these alerts, we might determine that there is indeed an anomaly in the record dates but that the specific records generating the alerts are legitimate. As such, we can dismiss the alerts by following the instructions in each alert.
Upon dismissing the Unexpected Record Found alert, the tracker's ledger flags the anomalous records as anomalous but legitimate:
The ledger is now telling us, in effect, that the application determined that these records are dated too close to each other to be considered one month apart, but that the user dismissed the alert, approving the records. The application cannot say with certainty which one is the 'extra' record, just that there is not enough gap between them, making them both suspect.
The corresponding alert, complaining of an unexpected 'extra' record, has been removed and the tracker will no longer be deemed 'unhealthy' because of these records.
The alert complaining of a 'missing' record is still present. It too is dismissible. After dismissing the second alert, the ledger looks like this:
The application has inserted a record - a zero activity placeholder. As a result, the gap that exceeded one month and suggested a missing record, is now gone. The alert also disappears and, most importantly, because the placeholder record indicates zero usage, accounting results are unchanged.
But I Just Don't Want to See These Alerts/Yellow Records
The kind of anomaly described occurs infrequently and most users review the alerts and just dismiss them in the manner illustrated above. Even though the accounting remains unchanged, some users would rather not see the occasional flagged yellow records in their ledgers. As such, they have the option of eliminating these kind of alerts by configuring the tracker to be a-periodic. This is a legitimate option but it does mean that the application's alerting system will no longer flag anomalies in record dates, potentially missing actual errors and reducing data quality.
Comments