The following post was transcribed from an email, and some details were obfuscated to protect client privacy
Hi Marinus

I have attached a file titled Java. It contains meters which give me errors when doing validations after running the bill. There are a few that are the same. Please have a look and advise me on how to fix them.

Regards

1) java.lang.Exception: 36043819 AUDIT ERROR! Missing profile? 0.006048605996176614% Gap between 2013-08-01 00:00:00.000 and 2013-09-02 00:30:00.000
2) java.lang.Exception: 36064352 AUDIT ERROR! Check total too small at 2013-08-30 00:07:47.302
3) java.lang.Exception: 36027621 AUDIT ERROR! Check total too big at 2013-08-25 00:59:25.658. Gap in profile?
4) java.lang.Exception: 35009007 AUDIT ERROR! Check total too big at 2013-08-13 00:59:21.896. Gap in profile?
5) java.lang.Exception: 36068584 AUDIT ERROR! Missing profile? 3.3015081084472313% Gap between 2013-02-28 02:00:00.000 and 2013-09-02 00:30:00.000
6) java.lang.Exception: 36027600 AUDIT ERROR! Check total too big at 2013-07-09 00:58:49.553. Gap in profile?
7) java.lang.Exception: 35013066 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 2013-06-20 00:00:00.000 and 2013-09-02 00:30:00.000)
8) java.lang.Exception: 53069842 AUDIT ERROR! Missing profile? 0.6207459645978028% Gap between 2013-03-20 00:00:00.000 and 2013-09-02 02:00:00.000
9) java.lang.Exception: 36088304 AUDIT ERROR! Missing profile? 1.0486073338772548% Gap between 2013-02-28 02:00:00.000 and 2013-09-02 02:00:00.000
10) java.lang.Exception: 33021157 AUDIT ERROR! Check total too small at 2013-07-25 00:38:31.588
11) java.lang.Exception: 36009941 AUDIT ERROR! Missing profile? 0.04634056361763916% Gap between 2013-07-25 00:00:03.000 and 2013-09-02 03:00:00.000
12) java.lang.Exception: 35012998 AUDIT ERROR! Check total too big at 2013-08-21 08:57:22.436. Gap in profile?
13) java.lang.Exception: 36045700 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 2013-03-15 00:00:00.000 and 2013-09-02 00:00:00.000)
14) java.lang.Exception: 36009929 AUDIT ERROR! Missing profile? 1.782884505705513% Gap between 2013-07-20 00:00:00.000 and 2013-09-02 02:00:00.000
15) java.lang.Exception: 33017240 AUDIT ERROR! Missing profile? 0.5742363154988297% Gap between 2013-04-29 02:00:00.000 and 2013-09-02 02:00:00.000
16) java.lang.Exception: 35013036 AUDIT ERROR! Check total too big at 2013-06-28 00:59:34.308. Gap in profile?
17) java.lang.Exception: 30060495 AUDIT ERROR! Missing profile? 0.30772865557091655% Gap between 2013-04-09 06:33:51.000 and 2013-09-02 00:30:00.000
18) java.lang.Exception: 30060266 AUDIT ERROR! Missing profile? 0.9894304873753587% Gap between 2013-07-01 00:00:00.000 and 2013-09-02 01:00:00.000
19) java.lang.Exception: 46030744 AUDIT ERROR! Missing profile? 0.006907046508741887% Gap between 2013-06-20 00:00:00.000 and 2013-09-02 02:00:00.000
20) java.lang.Exception: 46030658 AUDIT ERROR! Missing profile? 0.007319582978565576% Gap between 2013-05-14 18:00:00.000 and 2013-09-02 02:00:00.000
21) java.lang.Exception: 36027613 AUDIT ERROR! Check total too big at 2013-08-06 00:59:52.634. Gap in profile?
22) java.lang.Exception: 30060496 AUDIT ERROR! Missing profile? 0.0017882279511854148% Gap between 2013-05-20 00:00:0

Here is an example of the thought processes and actions I go through when fixing these:
Notes:
navigate to the validation screen (Tools>Meter Validation Screen)
submit blank to return all meters
look up the first problem on the Word document you've sent, see it is meter 36043819
search for 36043819 on the validation screen web page, once it has finished loaded (Ctrl-F) you have to wait until it has finished loading.
didn't find it soon enough. In another window, go through the process again, only this time do not submit a blank page, type the meter number into the required field before the submit. then it returns much more quickly.
Click on the 'Unreservedly' button next to the meter serial number 36043819 line on the report. It complains about possibly missing profile: a discrepancy of 0.005682013810577519%, which is pretty darn small.
Click on the From-To link to see the profile. I see no gaps in the profile. The profile looks fine.
So, back on the validation screen, I change the 'Validation within' value to 1% (it was on 0%); and I click the 'Unreservedly' button again. It now clears.
However, I saw EOB on the event list. Now, EOB is 'end of billing'. This event should not cause an invalidation. So, I select the meter, and I go to the Edit>Meter Event Setup.
On the Meter Event Setup screen, I now do a search on EOB (Ctrl-F). I see that this is checked under 'Invalidates'. Naughty, naughty. I uncheck it, and press Commit. Now this event will not invalidate it again in future.
I check and see that the original validation screen blank submit has now finished loading. Good! I close the other windows I have opened after, and look for the second problem in the word document, see it is meter 36064352.
I search for it on the validation screen web page. S973 Dar Del Sud Afrika.
By just looking at the events ( audit err, EOB, Hz<, I>, proOn the Meter Events page, I do a search on Update (Ctrl-F). I find it has to do with Comms, which is normally not such a biggie. I also find a lot of Time Sync messages, which have me worried. Why does this meter seem to be losing its time every day? No wonder it seems to be losing profile: if we're adjusting its clock all the time, some profile half hours might be cut short or something, or the totals and profile could be out of sync, time wise. Also not sure what 'diag EOI period' means, but it has me worried. I resolve to go look in the Itron documentation or ask someone about what that means. EOI is End of Interval, and it comes from the meter. EV_EVENT_PERIODICAL_EOI in the Itron spreadsheet, which means absolutely zero to me.
I click on the profile link on the validation screen, and the profile looks relatively good. It seems to have picked up some load recently, since the beginning of august, but when I zoom out, I find that actually it used to be that high around end of June, so July was for some reason just a quieter month?
I try to validate it, to try and see if it audits. It complains that a check total is too small at 2013-08-30 just after midnight. I can understand jittery totals if the time is always out. But since check totals are not that important, I resolve that I can probably delete it.
I go to the meter, from the validation screen, by clicking on the meter serial number on the left of the line for 36064352 on the validation screen. It selects the meter in a new tab.
In the screen, with the meter selected, I go to Edit>Meter Totals.
On the Edit>Meter Totals screen, I don't see any christmas light colors in the cells, and 30 August is in range, so we're more or less ok. I click on the link that says 'Hide Check Totals'. (Check totals are totals that are not on a half hour boundary, so we cannot use them for billing, since they are not precise, but we can still use them for a plausibility check)
(This screen has many interlocks to protect it against unwarranted edits, but you can usually manage to fix the totals if you try hard enough.)
Now I have a different screen, with the check totals hidden. It now shows up a problem on the Reactive energy total (red christmas lights). Which means that the total difference is greater than the profile sum. Oops. Ok, since it is reactive energy, it is not so bad. If it was Active energy, I would have been more worried. Possibly the total is more than just Q1, in reality. There must be something set up strange on that meter somehow, it could even be cabling, but since the Active Energy is fine and the power factor on the profile graph looks plausible, I will ignore that problem for now. Also, it was not what the audit on the verification screen complained about, so I get back to what I was doing before, namely:
Now there is a link visible on Edit>Meter Totals called 'Delete Check Totals'. I click on that link. It asks 'Are you sure', I click OK.
By the way, I see the billing totals, even on August, is the 20th of the month, still. Perhaps the problem with the reactive energy totals will go away when it gets reprogrammed.
After the check totals are deleted, I go back to the line on the validation screen, and try to validate it again. It works! Yay. Next lady for a shave.
Looking at the Validation screen generally, I now see so many Sync, Update events on there it is scary. Surely, the meters should be able to keep their time settings better? I resolve to look into the algorithm to see by how much it must be out before I set it, to make sure this amount is not too small. (on Tools>Configure Server, on SDG login, I find that it says the meter can be 300 seconds out before we set the time. That is 5 minutes! If we set the time every day, it certainly seems excessive. I resolve that I'll look at the code to ensure we are looking at this field. Yes, we are. Aha, it seems that the time sync event is actually not generated by us, but by the meter, and it happens in absence of our own setting of the time! Is it possible that the time on these meters are set by some other means? like a sync input from the municipality? I know some municipalities like Durban does provide such sync pulses. Ok, so it doesn't seem to be PNPSCADA that causes these excessive time syncs.)
Right, the next meter in the spreadsheet is 36027621. I go there on the Validation screen (Ctrl-F); after closing the other tabs again.
This time the profile seems BIGGER than the totals. I try to validate. It says a check total is too big.
I go to the totals screens.
I click Hide Check Totals, then Delete Check Totals. This time it seems the profile might be looking at more energy than the totals. It is the opposite problem from the previous one. But still only reactive energy. This time, at least they've fixed the billing date. I see the nature of the problem has remained the same before and after they fixed the billing dates.
I go back and try to validate it again, and it validates.
Next meter in the spreadsheet is 35009007..... (and so and and so forth)
All the above had audit errors, which are serious, so you shouldn't try to hide these. There seems to be something, either internal to the meter or some other mechanism, that sets the time on these meters all the time, causing some jitter, and I think this is mostly to blame for the above 3 problems. The correct way to address this is to consult with the technical people at the municipality and possibly the meter manufacturer, and maybe ask the installer or installation auditor about the actual installation, finding out if there is any sync pulse involved. Perhaps look at a few photographs and try to figure out where this extra sync is coming from? There seems to be communications involved, so it might even be a remote PC that is calling in periodically. This is something we need to understand before we fix it at another level, e.g. software or ignoring audit events. If they can discontinue the other means of syncing the meter times, which is excessive, that would probably sort out this problem.