*snipped*
OK...half-baked, but, lemme offer this up and an idea on where we can go with it. :woohoo:
I just noticed :doh: maybe you guys saw this all along...
In the following example (forget what Exhibit letter I gave it :bang
but, in LE-version of the records I see something that might clue us into something to look for in the 'Gentiva' version.
Ever notice (1) The ORIGINATING and DESTINATION #'s are both ~Gentiva's x7992 number (one exception) EXCEPT THE EXCHANGE NUMBER IS DIFFERENT IN THE DIFFERENT COLUMNS!!
619 VS. 629!! And (2) Note also that
619 is Casey's cell exchange (i.e. (407)
619-9286)
These are Casey Calls TO "Gentiva" so, in the process of filtering the report LE somehow corrupted the last 4-digs of data in the ORIGINATING column. :bang:
Tell you that to tell you this...
Depending on how you filter data (assuming they are working from a spreadsheet, but, never know...they could be working from a database) the filtering process may have problems with '0000', the last 4-digs of Lexus. It can be screwed up by data being defined as text vs. number, etc.
I dealt w/ this on our cell log look-up early on since we were using the last 4-digits to match-up the # with the entity in a look-up table.
Perhaps...just perhaps...the records you're referring to AZ were subject to the same sort of corruption...or data exception problem with the '0000' results that resulted in a post-generation *correction* against an LE-corrupted product already in-progress based on their date & timestamps (should find a better term than LE-corrupted). Let's take a look and see. Can you point me to 'em?