Special Date Edit

[Brian K. White]

On 10/7/2015 1:23 PM, Stanley - stanlyn.com via Filepro-list wrote:
> Hi Richard,
>
>>> You will agree this is a strange problem.
> I think it is a bigger and more widespread problem than most people
> realizes.  Most invoices entered by AP clerks are current invoices and when
> they run across one with an invalid date they just guess at the date to keep
> it in their current accounting period and for the most part that is
> acceptable.  This fails if you are trying to make this as accurate as
> possible and spans many accounting periods and years.  This is what I'm
> dealing with, even though at this point its pure archival...
>
>
> I understand what you're saying, but thinking that the solution can be much
> simpler by:
>
> 1. create an edit that forces a consistent 10 digit character field like
> YYYY/MM/DD (reverse date), and allows for 0000/00/00 for data entry,
> 2. the invoice field for the date is character and will be based on this
> edit,
> 3. store all (good and bad) dates with the edit being responsible for zero
> padding the values,
> 4. done...
>
> If you don't want the slashes, then leave them out of the edit and reduce
> the field length by 2.  If the slashes are removed from the field length and
> edit, you can then use either character or numeric as its field type and
> both ways will both sort and index correctly.
> An index built on that field will show both good and bad invoices correctly
> and in correct order.
> Selecting a date range will pull what is expected, both good and bad dates.
> If math needs to be done, then parse and process in the v table as has been
> pointed out...
>
> Can you see any problem with this?
>
> Thanks,
>   Stanley


This is exactly what I would have done, at least based on my 
none-too-careful reading of the problem. YYYYMMDD fill in whatever you 
have easy peasy.

No only does everything sort right, both good and bad and mixed, but the 
incomplete dates are all gathered together and distinguishable from real 
dates. 0 days & 0 months, will all be together and in front of and 
distinguishable from the 1 months and 1 days.

You can put a nicer on-screen field with slashes or whatever and store 
it as YYYYMMDD.

How often will you really have a year and a day but not a month? Even if 
you did even that would still sort ok. It would still be with the 0 
months, just at the end of the 0 months, but definitely not in with Jan 
or later.

Sounds like all you need is what you first asked for, a special edit 
just to help with data entry just for convenience. I don't know how to 
make that edit either since I think plain processing would take less 
time to figure out than getting an edit to work.

-- 
bkw