Wierd Date Translation in Avanté

[adewitt]

Periodically I encounter a situation where a date is entered "incorrectly."  It displays the correct MM/DD/YY on the screen, but translates into a -21XXX number when viewed in the record.  When I use MYDATE to translate the internal date MYDATE returns blank.

Avanté does an After Input Process which checks to see if the value is less than @DATE and to check to see if it's in the shop calendar.  It apparently passes both tests.

Since this field is used to calculate due dates and mfg scheduling when subsequent programs try to use the corrupt date they hang up.  So, any idea what kind of post-input check I could put in to verify that this is a good date?

[precisonline]

I'd be surprised if a negative date is in the shop calendar, unless it's doing the comparison with external dates?  Seems to me you might calculate today's date and if the value is < n days (you decide n) away from the current date, at least display a warning.

Mind sharing a couple samples of a specific internal date and its external counterpart?

[adewitt]

Wish I could.  I didn't take any pictures.  The date was 06/15/10.  When I did LIST INVPLAN01 F1 F2 F3 (F1 being the date field) it displays as 06/15/10.  It wasn't until I did the OS.ED INVPLAN01 PartNbr that I saw the corrupt internal date.  That's when I knew what the problem was.  I traced it back to the request date in the SO Header file.

This may not be a SB problem.  It may be a Unidata one. 

[precisonline]

06/15/1910 is -21018.  This suggests to me that your pivot date may be incorrect.  Enter this command @ TCL and let me know what you get, please?

CENTURY.PIVOT

[adewitt]

I just did exactly the same thing and got the same result.

When I do CENTURY.PIVOT the result is 1930

[precisonline]

That's what I would have expected.  That doesn't stop someone from entering 1930 however.  So back to the original question: If you put some validation on there to make sure the date entered is within n days of the current internal date, that should do the trick, right?

[adewitt]

I went back and looked at the current validation.  It turns out that an error results in a warning not a hard error.  My gut feel is, even though they deny it, that our CSR's just blow through the error when entering orders.  I have no idea why we do this, but we first write it up on an order form and then key it into the system.  Seems self-defeating.  So I changed the error to be a hard error in our system.  There is no reason why a request date should be less than "today."  Our shortest lead time is 24 hours.  I then got on Epicor about same.  They're thinking about it.

[precisonline]

I've seen this before, and only with Avante.  But what's weird is that nobody ever remembers entering the date improperly.  The worst I can recall is someone who fat fingered the 0 and entered something like 04/12/905.  Of course, the D2/ showed it as 04/12/05 but all of the calculations off that date were GOOFY!