Sage 100

Just ran across this KB article and wanted to share the helpful DateChecker utility to locate Vendor Code 9 Date Errors. Client had this error while printing SO Invoices, told them to look for an invalid date - BUT - all dates actually looked correct on screen. The problem was a space in the date that could only be seen thought DFDM. This utility is better than scanning through DFDM record by record looking for a bad date. https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=89700&sliceId=1&isLoadPublishedVer=&docType=kc&docTypeID=DT_DOWNLOAD_1&stateId=18172&cmd=displayKC&dialogID=703958&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl&openedFromSearchResults=true

Resulting log is put in MAS90/HOME/Textout folder as CCC_Checkdate.txt file.

Also note that the bad date can be on an order/invoice line promised dates.

Or they could just validate it during entry like every other system. Sigh....

I've been seeing these errors recently with BR check cleared dates (probably from an import) and finding the bad rows is always so much ""fun"". This utility will be quite handy!

Utilities are easier to write....

I know you're being sarcastic @JeffSchwenk but geez, it sure would seem to be less expensive for Sage to validate the date during data entry than to have to field support calls and to write a utility program to fix a design flaw. It isn't a bug, it is a sloppy design. Add these up and they amount to something. No wonder the subscription cost is high.

Of course I am being sarcastic. This has been around for many moons. Since they haven't fixed in data entry, then utilities ""must"" be easier to do..... I am just hoping they will fix the bug in PR department deduction maintenance that has been around since day one but they won't. ""no one else has reported it, so it probably isn't an issue.....

There are no version #'s specified on the KB. Should one ""assume"" that it will work on all v20xx versions?

Well, my lucky evening. Installing new Crystal report for client tonight and it bombs for a bad date field. Now if only we could specify which module to verify. I was prompted for a company code and it is off to the races. Wish me luck!

Would be nice if there was a single DL that we could install to a customer site with all these hidden utilities. Having the utility is 1/2 the battle sometimes. Getting it DL to the customer server (especially in secure environments where you don't have a full time unattended) can be a challenge.

Can't agree more. Utilities are spread out. I usually forget about them as a result. Why do some make the hidden menu and others don't. And why do they even have a ""hidden"" menu? Just put it under the utilities menu in LM.

I think I've used ISERROR for that. But I like Ken Hamady's newsletter for helpful sets of additional formulas. This is one set I got from his newsletter. https://kenhamady.com/cru/

I use the freebie ODBCView program. A select * from tablename will give results up to just before the failing row (instead of dying without telling you how far into the query it gets before running into the bad data).

SOTAMAS90 ODBC source. Check off ""NULL Date"". Create a report in Crystal that draws from the file with the bad date. The bad date will no longer stop the report from processing. Sort by the date field. The bad dates will sort to the top (or end).

I do the same by exporting as a CSV from VI, then use Excel and search for the extra space.

Here's a list of files CHECKDATE appears to review

How come I never knew about this? sigh...

Because you use the collective wisdom of the Minds.........

@MadelineStefanou You didn't review every link on the four web sites often enough.

Sage has just given up... Which is why it's so important to make note of anything that looks new. Sure, in some cases people may say that the info is old news but more often than not the if the info looks new to you then it is worth sharing here.

@MadelineStefanou that's what I thought!

This is what the output looks like. Based on this, I'd say that if there is one utility for all versions, it must scan...gulp, every file. *OK* PR_ACAEmployeeCoveredInd *OK* PR_Department *OK* PR_DirectDepositSvcActivity *BAD DATE* PR_EarningsDeduction Key: D DateCreated: 0 *OK* PR_Employee *OK* PR_EmployeeDocuments

FYI - In January this year, Sage dev mentioned an M/D identified the actual bug behind the global date issue because he had fat-fingered a date himself and went to investigate and could reproduce the bad date at will. A break-thru at the time. So the plan was to fix in the dictionary itself in the DATE class and that fix was supposed to come out either in 2018 PU2 or PU3. Haven't heard anything since then as I don't know if the fix actually made it (they may have deferred it to 2019 because the fix is too risky for a PU) and/or if the CheckDate utility is a substitute/addition to it. Don't shoot the messenger.

@RhondaMcNamara - Exactly. Thus my comment for a second prompt after the company code prompt. ALL module or ONE. I usually know which module to search.

Update: the vendor code 9 fix in is 2018.3