Validation errors
sdg.marinusvz
2015-01-20 12:19
This post was transcribed from email
In the past, we've informed you about the issues we were experiencing with the Itron SL7000 meters which were not reading in. This occured when the client changed to TOU tariffs.
This morning we did some work on these meters via pnpscada, we set the last read in date forward, we did this because the explanation in the communication monitor suggested it. The profiles then stared to read in. However, I noticed now when trying to validate that the two meters we worked with are bringing back validation errors.
The details are below.
Please have a look and advise on how to proceed, should we validate with reservations? or is there another solution.
Number 3 on the list is a check total error. Can I go ahead and delete the check totals and try to validate again?
| audit err, prof>tot | 2014-10-25 23:30:00.000 - 2015-01-01 00:00:00.000 | java.lang.Exception: 35013009 AUDIT ERROR! Your total register seems to be counting backwards? Does it reset every month? If it does, it is not compatible. You can switch reading totals off per meter. (between 2014-10-25 23:30:00.000 and 2015-01-01 00:00:00.000) |
| audit err, interplt, prof=0, pro | 2014-12-01 00:00:00.000 - 2015-01-01 00:00:00.000 | java.lang.Exception: 35013011 AUDIT ERROR! Check total too big at 2014-12-08 11:16:41.922. Gap in profile? |
| audit err | 2015-01-01 00:00:00.000 - 2015-01-16 01:00:19.140 | java.lang.Exception: 53069886 AUDIT ERROR! Check total too big at 2015-01-15 01:04:07.594. Gap in profile? |
sdg.marinusvz
2015-01-20 12:25
In addition, this is the complete list of the sites which were not reading in as of today.
The profile started reading in when we set the last read date to 01 January 2015, therefore we know that there is a gap in the profile from October to December and thus we suspect the reason for the invalidations. As the client and we are aware of the gap for these meters would it be safe proceed to validate with reservations ?
For Dhobi, it indicates that the gap is more than a month however when we set the dates back the gaps do not fill.
sdg.marinusvz
2015-01-20 12:30
Yes, these seems like typical errors for when a meter was reprogrammed: profile history missing from the meter memory, and some energy or TOU registers having reset back to zero.
Hopefully they won't reprogram the profile and the TOU registers in the same month!
When you know the meter was reprogrammed around that time (look at the From-To range on the line); you can probably approve it, by entering a very high percentage at the top right and then validating. Do With Reservations, then at least you can say why you approved it regardless.
In any particular month, ideally, either the registers or the profile should be good, otherwise the municipality would lose money.
So, if the registers reset, the sum of the profile should give an indication of what should be billed (last month's register + this month's consumption) - and then the municipality must reset the TOU register's value in their billing systemy to the real reading.
(if they can't do that, e.g. if they can only set it back to 0, the only thing to be done is to keep giving them fictitious register readings based on last month + profile consumption, until they can reprogram & reset the registers on the 1st of the month, at which time you start giving them the real register readings - but this is messy, they really should be able to enter a Start Reading in their accounting system when they move someone to TOU. Our contractual duty is to give them the actual meter register readings. So if it is too difficult to synthesize them readings, do them manually)
And if the profile is incomplete, hopefully the registers did not reset, so we must give them the actually read registers and that should be fine, even if the audit fails.
As long as you keep the above in mind, you can validate them With Reservations. By validating them, you take responsibility to take additional care of the above.
sdg.marinusvz
2015-01-20 12:32
Firstly there is the View->Profile Graph. You can zoom and pan any date range you want. When you run a Provisional Bill from that screen it would typically show you the consumption, and the end readings, at least the end total. If you page left the profile graph and get another Provisional Bill, the new end total would be the start total of the previous one: it is a total for an instance in time. You can even download a CSV from the profile graph if you need to check/balance things in excel to run your own checks to see if readings are correct or not.
Then there is the Edit->Meter Totals screen that shows you the Energy totals, the most important being the first column, which is your kWh. The rest doesn't really matter so much for billing. Here you can typically Hide and then Delete Check Totals, and it would also try to audit profile and totals, and if it can't, it would give you the option of recalculating totals (e.g. if the totals was reset, and you want it to reflect the consumption from a previous total); or you can interpolate profile inbetween totals, e.g. when there are missing profile. There is also a seperate menu item where you can do interpolates e.g. if you want to do this through a Bulk Edit for a lot of meters. If you interpolate a profile like this, at least the totals and the profile will balance. If you recalculate the total, the profile and the totals will balance. However, it is generally better to recalculate old totals, since there will always come a next total from the meter, and you don't want it to cause problems again.
Also on the meter page is the totals as read from meter (on the right hand side); and then the scaled & non-reclocked value on the left (the actual reading can reclock, the value on the left would just continue up).
There is also an Audit Report that you can play around with, and of course the Audit check functionality in the Validation screen itself.
Then for the TOU registers, the raw values as from the meter is under View->Meter Registers. And the interpreted & scaled TOU Billing registers are under Edit->TOU Billing Registers. If you don't see what you like on the TOU Billing Registers, you can delete it and read the meter again, and it will work it out again from scratch. These are the registers that were wrong for 2 meters last time, and why we are moving to 1 TOU id registers this month. In the past we used 2 TOU ids, namely High Season and Low Season, for each, e.g. Peak.
Hope that helps!