Home Guy wrote:
dpb wrote:
Very similar problem to what I and several others propositioned--
that it wasn't a "real" usage problem but either a human or computer-
generated problem... 
The meter was read correctly - to the extent that the reader entered the
correct numbers into a large handheld device of some sort.
You wouldn't think that there would be any other human hands touching
the data after that point, at any other point in the chain that leads to
the preparation of my monthly bill. Because I can't imagine the upwards
of 50 to 100 thousand customers having their bills similarly "touched"
by human hands, on a monthly basis.
As for this being a computer-generated problem, you would think that any
code that transforms "47" into "87" would have been caught long ago.
Home Guy wrote:
dpb wrote:
Very similar problem to what I and several others propositioned--
that it wasn't a "real" usage problem but either a human or computer-
generated problem...
The meter was read correctly - to the extent that the reader entered the
correct numbers into a large handheld device of some sort.
You wouldn't think that there would be any other human hands touching
the data after that point, at any other point in the chain that leads to
the preparation of my monthly bill. Because I can't imagine the upwards
of 50 to 100 thousand customers having their bills similarly "touched"
by human hands, on a monthly basis.
As for this being a computer-generated problem, you would think that any
code that transforms "47" into "87" would have been caught long ago.
Well, I wouldn't presume anything -- if it were fully automated there'd
be no need for the manual reader to come look to begin with.
Your previous posting said (at least that's that I thought it said) you
had confirmed it to have been a transcription error--you're nowing
saying that wasn't found to be so but is another supposition you're
making not what the utility rep confirmed?
Other possibility is that whatever the transfer mechanism is from the
reader's collection to the central billing computer is error-prone. Do
you know how/what technology they're using?
What if the reader;s data entry device prints out a record and that is
sent thru an OCR device for entry to the accounting software? I can
imagine that could create such a repetitive mistake. Or it's a wireless
connection and is flaky. If the utility is still stuck in an early
technology introduction mechanism I can imagine all sorts of possible
error-inducing things _could_ be doing. (In another life, I remember
having nuclear generating power plant data returned to central office by
punch paper tape--more effort was spent in making software to correct
the errors inherent in the process than the time required to do the
actual engineering calculations. Eventually, stuff was upgraded but
again it was a first-generation system and reasonable technology for the
first deployment but had been passed by during the time from initial
specification to deployment by other developments. As noted elsewhere,
am involved heavily in our local rural electric co-op; we're going thru
a similar issue of moving from manual readers to automated and have had
several trial pieces of gear during the last ten years since began that
have proven unequal to the task in the specific application. If we had
instead taken one of these at face value from the vendor and made a
deployment we could easily have had a case of generating many billing
errors such as the one you've described because they had bad
communications, primarily altho some were related to loss of onboard
memory or other glitches that caused bad readings. In your case, since
apparently the meter is mechanical and the reading manual, the problem
is a little different probably in inception but conceptually the same.
Would be interesting to find out what final resolution turns out to
be...as another poster noted and I had mentioned before, the earlier
real outlier value seems as though should have similar explanation and
perhaps a billing credit if hasn't somehow been otherwise corrected.
Whatever the actual mechanics, it turns out that it isn't an actual
locad problem which was the point I had been trying to make all along
that the issue really couldn't be a "real" physical usage problem with
the kind of characteristics of the posted data.
--