Kinetic 2 digit year date issue 2021.2

Had an issue with a Sql Date overflow error when printing some reports yesterday.
Found out a customer record had a date saved with a 2 digit year format.

In the database a field with 1/1/2022 is saved as 0022-01-01 instead of 2022-01-01

So far I can make it happen with every date field in Kinetic 2021.2
I have not installed 2022 yet to start upgrading to that. Curious if anybody sees this in the newest version?

Which field? I’m looking at the customer master and don’t see any date fields so I am curious where they are entering a date.

In customer the credit review date. It is every date field that I have tested in any screen though.

Interesting, I’m on 2021.2.12 and cannot get a 0022 date to “take”. For example, in credit review date, if I type in 01/01/0022 the field is immediately cleared once I tab out of it, whereas if I type 01/01/2022 the date sticks.

Hey Mike,

Is your user set to a non EN-US culture?

It was blank, but setting the language did not effect how it behaves.

Type in just 1/1/22 in a Kinetic form Not 0022

When I type that in, then tab out of the field, this is what I see:

image

But I’m using classic not kinetic.

Edited: I just tested in the Kinetic app and got the same results as you - it lets you type in 1/1/22 and saves it as 01/01/0022 in the db. YIKES!

2 Likes

I just tested this on 2022.1.5 and it saves properly.

ReviewDate

1 Like

Good to know they fixed it in 2022.

1 Like

You typed in 5/1/14 and it changed and saved it to 5/1/2014 ?

5/1/2014 was the initial date.
I typed in “1/1/22” over the top and tabbed at which point it corrected to 1/1/2022.
I then changed the 2022 back to 22 and instead of tabbing, clicked save at which point it still corrected it to 2022.

OK thanks for clarifying. Time to start testing and update to 2022

I’ve had this happen with PO due dates. When manually typed in, the date took 04-01-0022, and realizing that was wrong, a team member updated it to 04-01-2022, and it STILL caused a problem because the 0022 was stored in the PreviousDueDate field. In short, it had to be updated twice for it not to cause a date spill.

Note: we are in Kinetic Cloud environment

1 Like

Pretty unique.

Such bugs. Much wow!

1 Like

I had to change my comment. I love Epicor. What they are trying to do is extremely tough. I wouldn’t know the first thing about it. Just sucks to read these types of issues.

You’re too nice, sir.
QA departments and controlled releases/betas exist for a reason.
I get the feeling marketing is all push, push, push to get these releases out without regard to functionality.

4 Likes