Looking for some ideas ...

[Ken Mayer [dBVIPS]]

I'm working with a client who has an issue with a subsystem in the
application I've been working with him on.

The subsystem is the stock order system, and more specifically the End
of Day stock orders.

End of Day is actually 2:00pm, because the biggest supplier for his firm
needs the orders at that point to expedite shipments, etc.

The problem is that the code that generates the End of Day stock report
(currently) just looks at the date of the quotes (items customers have
ordered but not paid for ...).

After 2, more orders typically come in. However, the "End of Day" report
has been completed.

The next day, they want to be able to generate an "End of Day" stock
report that includes items from the previous day that were ordered after
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.

So, here's what I'm *considering* doing, but I'd love to hear if someone
has a better idea:

When the end of day report is done (which copies some fields for the
items needed for ordering to a specific table used for the report, which
includes the Quote Number for reference):
* Copy that table to a "backup" table.
* The next day, empty the current "End of Day" table (which is what
is being done now);
* Look at the quotes for the PREVIOUS day, and see if they are in
the "backup" copy of the table -- if they are, skip them and move on ...
* If they are not, process them like usual (copy to the End of Day
table), and of course then process everything for today (up to 2, or the
time at which the report is being generated).
* When done, overwrite the "backup" table with the current stock
orders, and ... we're done.
* Repeat the next day ...

I haven't started to write this (well, modify the existing code), but as
noted, I thought I'd see if this sounds like an optimal way of handling
it, or do you have a better idea? I am willing to entertain ideas, even
if I don't use 'em, it's a learning process (I've been doing this for
many years and am always learning new things).

Thanks in advance for your thoughts ...

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Claus Mygind]

Post by Ken Mayer [dBVIPS]
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.

So why can't you use the timestamp. If the requirement is that orders be
submitted before 2:00pm, simply advise anyone entering orders after 2 that
this order will be filled the next business day.

I do something simliar with a time sheet program. In order for payroll to
process the checks, the time sheets must be in by noon on Wednesday. Any
attempt to submit later is met with a notification they need to contact
payroll personally to get the timesheet submitted. But of course to make it
easier for payroll to process we just give them an extended timeframe (an
hour more) to the data inputted.

This allows for those exceptions you mention. In your case just authorize
the person responsible for processing the report to change the timestamp of
any orders between 2 and 2:30 or whatever exception procedure they want to
use to reset the submittal time to 2:00. All it would require on your part
is a small grid to display orders posted after 2 with a button or something
to click that the report generating person could use to override the
deadline. I think that would be easier than to massage the data through
several files.

Claus

[Christopher F. Neumann]

Why can't a logical field be added to the table, and that field be set to
true when the report is generated?
--
Christopher F. Neumann

[dBASE Gold Charter Member 107]
Blue Star Visual dBASE graduate
IWA-HWG Web Technologies Certified
IWA-HWG Web Programming Certified
ICCP TCP/IP Network Analyst
Data Communications Engineer
IEEE-CS Affiliate
http://cfneumann.us

"Just hanging out on the Sagittarian arm of the Milky Way"

Post by Ken Mayer [dBVIPS]
I'm working with a client who has an issue with a subsystem in the
application I've been working with him on.
The subsystem is the stock order system, and more specifically the End of
Day stock orders.
End of Day is actually 2:00pm, because the biggest supplier for his firm
needs the orders at that point to expedite shipments, etc.
The problem is that the code that generates the End of Day stock report
(currently) just looks at the date of the quotes (items customers have
ordered but not paid for ...).
After 2, more orders typically come in. However, the "End of Day" report
has been completed.
The next day, they want to be able to generate an "End of Day" stock
report that includes items from the previous day that were ordered after
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.
So, here's what I'm *considering* doing, but I'd love to hear if someone
When the end of day report is done (which copies some fields for the items
needed for ordering to a specific table used for the report, which
* Copy that table to a "backup" table.
* The next day, empty the current "End of Day" table (which is what is
being done now);
* Look at the quotes for the PREVIOUS day, and see if they are in the
"backup" copy of the table -- if they are, skip them and move on ...
* If they are not, process them like usual (copy to the End of Day
table), and of course then process everything for today (up to 2, or the
time at which the report is being generated).
* When done, overwrite the "backup" table with the current stock
orders, and ... we're done.
* Repeat the next day ...
I haven't started to write this (well, modify the existing code), but as
noted, I thought I'd see if this sounds like an optimal way of handling
it, or do you have a better idea? I am willing to entertain ideas, even if
I don't use 'em, it's a learning process (I've been doing this for many
years and am always learning new things).
Thanks in advance for your thoughts ...
Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/
*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Ken Mayer [dBVIPS]]

Post by Christopher F. Neumann
Why can't a logical field be added to the table, and that field be set to
true when the report is generated?

The hassles of altering the table structure. I know how to do it in a
deployed app, and have done so several times already. I'd like to avoid
it ... <g>

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Geoff Wass [dBVIPS]]

In article <***@news-server>, ***@_nospam_goldenstag.net
says...

Post by Ken Mayer [dBVIPS]
I'm working with a client who has an issue with a subsystem in the
application I've been working with him on.
The subsystem is the stock order system, and more specifically the End
of Day stock orders.
End of Day is actually 2:00pm, because the biggest supplier for his firm
needs the orders at that point to expedite shipments, etc.
The problem is that the code that generates the End of Day stock report
(currently) just looks at the date of the quotes (items customers have
ordered but not paid for ...).
After 2, more orders typically come in. However, the "End of Day" report
has been completed.
The next day, they want to be able to generate an "End of Day" stock
report that includes items from the previous day that were ordered after
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.
So, here's what I'm *considering* doing, but I'd love to hear if someone
When the end of day report is done (which copies some fields for the
items needed for ordering to a specific table used for the report, which
* Copy that table to a "backup" table.
* The next day, empty the current "End of Day" table (which is what
is being done now);
* Look at the quotes for the PREVIOUS day, and see if they are in
the "backup" copy of the table -- if they are, skip them and move on ...
* If they are not, process them like usual (copy to the End of Day
table), and of course then process everything for today (up to 2, or the
time at which the report is being generated).
* When done, overwrite the "backup" table with the current stock
orders, and ... we're done.
* Repeat the next day ...
I haven't started to write this (well, modify the existing code), but as
noted, I thought I'd see if this sounds like an optimal way of handling
it, or do you have a better idea? I am willing to entertain ideas, even
if I don't use 'em, it's a learning process (I've been doing this for
many years and am always learning new things).
Thanks in advance for your thoughts ...
Ken

Ken,

Another idea would be to track in a little table timestamps of when each
report was run. Then you would have a way to know exactly the starting
period for selecting today's report. If they run it at 5 pm, 7:30 am or
2 pm, you don't need to care.

[Ken Mayer [dBVIPS]]

Post by Geoff Wass [dBVIPS]
says...

Post by Ken Mayer [dBVIPS]
I'm working with a client who has an issue with a subsystem in the
application I've been working with him on.
The subsystem is the stock order system, and more specifically the End
of Day stock orders.
End of Day is actually 2:00pm, because the biggest supplier for his firm
needs the orders at that point to expedite shipments, etc.
The problem is that the code that generates the End of Day stock report
(currently) just looks at the date of the quotes (items customers have
ordered but not paid for ...).
After 2, more orders typically come in. However, the "End of Day" report
has been completed.
The next day, they want to be able to generate an "End of Day" stock
report that includes items from the previous day that were ordered after
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.
So, here's what I'm *considering* doing, but I'd love to hear if someone
When the end of day report is done (which copies some fields for the
items needed for ordering to a specific table used for the report, which
* Copy that table to a "backup" table.
* The next day, empty the current "End of Day" table (which is what
is being done now);
* Look at the quotes for the PREVIOUS day, and see if they are in
the "backup" copy of the table -- if they are, skip them and move on ...
* If they are not, process them like usual (copy to the End of Day
table), and of course then process everything for today (up to 2, or the
time at which the report is being generated).
* When done, overwrite the "backup" table with the current stock
orders, and ... we're done.
* Repeat the next day ...
I haven't started to write this (well, modify the existing code), but as
noted, I thought I'd see if this sounds like an optimal way of handling
it, or do you have a better idea? I am willing to entertain ideas, even
if I don't use 'em, it's a learning process (I've been doing this for
many years and am always learning new things).
Thanks in advance for your thoughts ...
Ken

Ken,
Another idea would be to track in a little table timestamps of when each
report was run. Then you would have a way to know exactly the starting
period for selecting today's report. If they run it at 5 pm, 7:30 am or
2 pm, you don't need to care.

I would still need a timestamp in the quotes table or some place
specific that tracked when the report was run for that particular quote.

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Geoff Wass [dBVIPS]]

In article <***@news-server>, ***@_nospam_goldenstag.net
says...

Post by Ken Mayer [dBVIPS]

Post by Geoff Wass [dBVIPS]
Ken,
Another idea would be to track in a little table timestamps of when each
report was run. Then you would have a way to know exactly the starting
period for selecting today's report. If they run it at 5 pm, 7:30 am or
2 pm, you don't need to care.

I would still need a timestamp in the quotes table or some place
specific that tracked when the report was run for that particular quote.
Ken

Ken,

Yes, I see what you mean. That could still work. You would track when
the report was run and the quotes it contained (ie. two tables).

[Ken Mayer [dBVIPS]]

Post by Geoff Wass [dBVIPS]
says...

Post by Ken Mayer [dBVIPS]

Post by Geoff Wass [dBVIPS]
Ken,
Another idea would be to track in a little table timestamps of when each
report was run. Then you would have a way to know exactly the starting
period for selecting today's report. If they run it at 5 pm, 7:30 am or
2 pm, you don't need to care.

I would still need a timestamp in the quotes table or some place
specific that tracked when the report was run for that particular quote.
Ken

Ken,
Yes, I see what you mean. That could still work. You would track when
the report was run and the quotes it contained (ie. two tables).

I have hit on a relatively simple solution that appears (at least for
me) to work. I store the last quotenumber in a specific table (one that
is automatically opened for each form to store preferences in -- the
custom form actually opens it), and then check against that when running
the routine. And I just realized a problem. Sigh. Need to work on that.
But the idea is there.

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Ronnie MacGregor]

On Fri, 05 Dec 2008 16:55:53 -0800

Post by Ken Mayer [dBVIPS]
The next day, they want to be able to generate an "End of Day" stock
report that includes items from the previous day that were ordered after
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.

We handle a similar problem, but on a monthly basis, in one of my businesses, a
group purchasing / invoicing company where we handle thousands of incoming
invoices every month.

Typically our "end of month" cutoff will be in the first few days of the
following month.

To translate our approach to handle your problem :

Store a "day number" eg. "20081206" (Note that this date format indexes and
sorts correctly) in a settings table somewhere.

Each order entered onto the system has a field which is populated with this day
number at the point of data entry.

Someone makes the decision of "pressing the big red button" to start a new day,
simply incrementing the "Current Day" value in the settings table. The act of
running the "end of day" report can do this automatically if desired.

Now you are in a position to run an "End of day" report for any day you wish
simply by means of SQL select on that "Day Number" value.


A simple, non convoluted system which has worked reliably for us for about
twenty years now.

[Ken Mayer [dBVIPS]]

Post by Ronnie MacGregor
On Fri, 05 Dec 2008 16:55:53 -0800

Post by Ken Mayer [dBVIPS]
The next day, they want to be able to generate an "End of Day" stock
report that includes items from the previous day that were ordered after
2. However, I cannot just base this on a timestamp, because of course
people are people, and things happen, and while 2:00 pm is the *stated*
time, I can't imagine that some days the report doesn't get run at 2:15,
or 2:30, etc.

We handle a similar problem, but on a monthly basis, in one of my businesses, a
group purchasing / invoicing company where we handle thousands of incoming
invoices every month.
Typically our "end of month" cutoff will be in the first few days of the
following month.
Store a "day number" eg. "20081206" (Note that this date format indexes and
sorts correctly) in a settings table somewhere.
Each order entered onto the system has a field which is populated with this day
number at the point of data entry.
Someone makes the decision of "pressing the big red button" to start a new day,
simply incrementing the "Current Day" value in the settings table. The act of
running the "end of day" report can do this automatically if desired.
Now you are in a position to run an "End of day" report for any day you wish
simply by means of SQL select on that "Day Number" value.
A simple, non convoluted system which has worked reliably for us for about
twenty years now.

Hmm. Something to think about. Another option, I realized this morning
as I was deciding whether to get up is to simply stuff the QuoteNumber
into a "processed" table, and look for it quickly there. That would be
all that was needed in the "processed orders" or whatever table. A quick
search for the QuoteNumber ...

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Jan Hoelterling]

Hi Ken,

I have come accross this several times in accounting scenarios, where a
invoice needs to be assigned to an accounting period, which may or may not
match the month and year it was created - much for the same reasons you
described.

I would therefore do something similar in your application - add a date
field for which date to "count" the transaction for. Add a function to
change that date (at 2:00 p.m. or whenever) to make it go to the "next" day.
Then you just need to add an option to the report to go by that date or the
"true" date and the users can report either way.

Hope this helps,

Jan

[Bruce Beacham]

Post by Ken Mayer [dBVIPS]
After 2, more orders typically come in. However, the "End of Day" report
has been completed.

When running the end of day report, why create a backup of the whole
quotes table (I assume it's that one you thought to backup)? Surely
it's just the quote numbers that matter. So create a table of just them.

Alternatively, is there a memo field you can add a bit more data to,
with some symbol so you'll know it means the quote has been previously
reported as ordered?


Bruce Beacham

[Ken Mayer [dBVIPS]]

I was just going to post a weird problem I'm having that makes *no*
sense to me (sigh). One can lose hair doing this sometimes (and I don't
have that much to lose!).

Er, maybe not. Dopey me. I had the wrong object reference ... sigh.
Sometimes the obvious isn't ... until you finally figure it out.

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Ken Mayer [dBVIPS]]

Post by Bruce Beacham

Post by Ken Mayer [dBVIPS]
After 2, more orders typically come in. However, the "End of Day"
report has been completed.

When running the end of day report, why create a backup of the whole
quotes table (I assume it's that one you thought to backup)? Surely
it's just the quote numbers that matter. So create a table of just them.
Alternatively, is there a memo field you can add a bit more data to,
with some symbol so you'll know it means the quote has been previously
reported as ordered?

Actually, what I thought I might do -- simpler than many suggestions (no
offense!) so far:

I already have a "Preferences" table that is meant to be kind of a
catch-all (right now it has a time-out value in it for forms in a
multi-user environment); and I figured I would add another entry:
EODLastQuote -- the End of Day report's Last Quote processed. Then when
processing I can back up to the previous day (set the range to the date
of the report -1 to the date of the report), and check to see if the
QuoteNumber being looked at is <= to the Last Quote processed -- if so,
skip it, otherwise process it. That's the idea.

I was just going to post a weird problem I'm having that makes *no*
sense to me (sigh). One can lose hair doing this sometimes (and I don't
have that much to lose!).

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Bruce Beacham]

Post by Ken Mayer [dBVIPS]
I already have a "Preferences" table that is meant to be kind of a
catch-all (right now it has a time-out value in it for forms in a
EODLastQuote -- the End of Day report's Last Quote processed. Then when
processing I can back up to the previous day (set the range to the date
of the report -1 to the date of the report), and check to see if the
QuoteNumber being looked at is <= to the Last Quote processed -- if so,
skip it, otherwise process it. That's the idea.

Surely Quotes are processed into Orders randomly? What is the
sequence number that is broken at the point the End of Day is run? - is
it an Order serial number which is then put on to the Quotes table? If
so - yes, that sounds promising.

Post by Ken Mayer [dBVIPS]
I was just going to post a weird problem I'm having that makes *no*
sense to me (sigh). One can lose hair doing this sometimes (and I don't
have that much to lose!).

Oh I don't know... there seemed to be plenty there when we met!


Bruce

[Ken Mayer [dBVIPS]]

Post by Bruce Beacham

Post by Ken Mayer [dBVIPS]
I already have a "Preferences" table that is meant to be kind of a
catch-all (right now it has a time-out value in it for forms in a
EODLastQuote -- the End of Day report's Last Quote processed. Then
when processing I can back up to the previous day (set the range to
the date of the report -1 to the date of the report), and check to see
if the QuoteNumber being looked at is <= to the Last Quote processed
-- if so, skip it, otherwise process it. That's the idea.

Surely Quotes are processed into Orders randomly? What is the
sequence number that is broken at the point the End of Day is run? - is
it an Order serial number which is then put on to the Quotes table? If
so - yes, that sounds promising.

The Quote Numbers are sequential, and it doesn't appear to matter if the
quote is actually eventually processed to an Invoice, the end of day
stock order looks at the Quotes. I don't know why, but that's the way
the client wants it, so that's how it is. <g>

Post by Bruce Beacham

Post by Ken Mayer [dBVIPS]
I was just going to post a weird problem I'm having that makes *no*
sense to me (sigh). One can lose hair doing this sometimes (and I
don't have that much to lose!).

Oh I don't know... there seemed to be plenty there when we met!

I think there's less than when you saw me in April. <g>

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Ronnie MacGregor]

On Sat, 06 Dec 2008 15:27:54 -0800

Post by Ken Mayer [dBVIPS]
Actually, what I thought I might do -- simpler than many suggestions (no

Hmmmm .... from where I'm standing, ... not simpler and not robust !! <g>

Post by Ken Mayer [dBVIPS]
I already have a "Preferences" table that is meant to be kind of a
catch-all (right now it has a time-out value in it for forms in a
EODLastQuote -- the End of Day report's Last Quote processed. Then when
processing I can back up to the previous day (set the range to the date
of the report -1 to the date of the report), and check to see if the
QuoteNumber being looked at is <= to the Last Quote processed -- if so,
skip it, otherwise process it. That's the idea.

Then one day, somebody needs to know .....

"This order here at 14:25 on December 31st 2006 ..... which 'Accounting Day'
does it belong to, the 31st December or the 1st January 2007 ?"

The answer to this question is critical, and could have major VAT and Tax
consequences for the company, and they have to prove this absolutely.

Your approach cannot answer this question.

For an order close to a major cut off point you also need to be able to
establish :

Which invoice has this been allocated to ?
Which monthly customer statement has this been allocated to ?
Which quarterly VAT period has this been allocated to ?
Which financial year has this been allocated to ?

etc. etc. .....

With the greatest of respect, I offered you the answer to this problem, a very
simply implemented solution, which deals with not just the immediate issue as
you perceive it, but a future proof solution which covers any future query in
this regard.

The underlying key is that the record for each order contains the information
as to the "Order Day" it has been allocated to.

For a robust system, there is no other way but to have a record of this very
important bit of information.

Don't re-invent the wheel <g>

Take a bit of advice from someone who has 20 years of experience running
multiple successful businesses of his own in addition to doing his own
programming !!!

[Ken Mayer [dBVIPS]]

Post by Ronnie MacGregor
On Sat, 06 Dec 2008 15:27:54 -0800

Post by Ken Mayer [dBVIPS]
Actually, what I thought I might do -- simpler than many suggestions (no

Hmmmm .... from where I'm standing, ... not simpler and not robust !! <g>

Post by Ken Mayer [dBVIPS]
I already have a "Preferences" table that is meant to be kind of a
catch-all (right now it has a time-out value in it for forms in a
EODLastQuote -- the End of Day report's Last Quote processed. Then when
processing I can back up to the previous day (set the range to the date
of the report -1 to the date of the report), and check to see if the
QuoteNumber being looked at is <= to the Last Quote processed -- if so,
skip it, otherwise process it. That's the idea.

Then one day, somebody needs to know .....
"This order here at 14:25 on December 31st 2006 ..... which 'Accounting Day'
does it belong to, the 31st December or the 1st January 2007 ?"
The answer to this question is critical, and could have major VAT and Tax
consequences for the company, and they have to prove this absolutely.
Your approach cannot answer this question.
For an order close to a major cut off point you also need to be able to
Which invoice has this been allocated to ?
Which monthly customer statement has this been allocated to ?
Which quarterly VAT period has this been allocated to ?
Which financial year has this been allocated to ?
etc. etc. .....
With the greatest of respect, I offered you the answer to this problem, a very
simply implemented solution, which deals with not just the immediate issue as
you perceive it, but a future proof solution which covers any future query in
this regard.
The underlying key is that the record for each order contains the information
as to the "Order Day" it has been allocated to.
For a robust system, there is no other way but to have a record of this very
important bit of information.
Don't re-invent the wheel <g>
Take a bit of advice from someone who has 20 years of experience running
multiple successful businesses of his own in addition to doing his own
programming !!!

The impression I have from the client is that this is not important.
Believe it or not. I could be wrong, but he has not said so ...

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Ken Mayer [dBVIPS]]

Post by Ronnie MacGregor
On Sat, 06 Dec 2008 15:27:54 -0800

Post by Ken Mayer [dBVIPS]
Actually, what I thought I might do -- simpler than many suggestions (no

Hmmmm .... from where I'm standing, ... not simpler and not robust !! <g>

Post by Ken Mayer [dBVIPS]
I already have a "Preferences" table that is meant to be kind of a
catch-all (right now it has a time-out value in it for forms in a
EODLastQuote -- the End of Day report's Last Quote processed. Then when
processing I can back up to the previous day (set the range to the date
of the report -1 to the date of the report), and check to see if the
QuoteNumber being looked at is <= to the Last Quote processed -- if so,
skip it, otherwise process it. That's the idea.

Then one day, somebody needs to know .....
"This order here at 14:25 on December 31st 2006 ..... which 'Accounting Day'
does it belong to, the 31st December or the 1st January 2007 ?"
The answer to this question is critical, and could have major VAT and Tax
consequences for the company, and they have to prove this absolutely.
Your approach cannot answer this question.
For an order close to a major cut off point you also need to be able to
Which invoice has this been allocated to ?
Which monthly customer statement has this been allocated to ?
Which quarterly VAT period has this been allocated to ?
Which financial year has this been allocated to ?
etc. etc. .....
With the greatest of respect, I offered you the answer to this problem, a very
simply implemented solution, which deals with not just the immediate issue as
you perceive it, but a future proof solution which covers any future query in
this regard.
The underlying key is that the record for each order contains the information
as to the "Order Day" it has been allocated to.
For a robust system, there is no other way but to have a record of this very
important bit of information.

Sorry if my previous message looked like I was blowing you off, I was
getting ready to take off ...

Honestly, for this system:

We have the date the Quotes were taken from the clients.
We have the date the Quotes were made into Invoices (i.e., paid orders).
We have the date the STOCK ORDER was done for the Quotes.

I am not sure that I need to track anything else. There is actually, if
anything, a huge amount of redundancy which would make a hard-core
database designer insane -- very little proper normalization (as in,
this application was not well-written to start with, and my original
goal was to simply upgrade it to Windows -- as time has gone by -- two
and 1/2 years ... -- it has been enhanced, and gotten a lot of spiffy
Windows stuff thrown in, and more, but it is based on a seriously flawed
application ... I was not commissioned to fix all those flaws, and
frankly I really want the application DONE and not my problem anymore
... sigh).

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Ronnie MacGregor]

On Sun, 07 Dec 2008 21:27:24 -0800

Post by Ken Mayer [dBVIPS]
Sorry if my previous message looked like I was blowing you off, I was
getting ready to take off ...

No worries !! .... I could "read" the rush <g>

.... and I've known you too long to be offended anyway !!

Post by Ken Mayer [dBVIPS]
but it is based on a seriously flawed
application ... I was not commissioned to fix all those flaws, and
frankly I really want the application DONE and not my problem anymore
... sigh).

I can sympathise with that !


Because I am both the business owner and the software developer, if I become
aware of a problem or even a potential problem it "has to be fixed".

I realise this bears no relation to the situation you are in with this job, so
I'm sorry if my previous post was a bit "Don't ignore this" ! I could just
forsee future problems arising.

[Ken Mayer [dBVIPS]]

Post by Ronnie MacGregor
On Sun, 07 Dec 2008 21:27:24 -0800

Post by Ken Mayer [dBVIPS]
Sorry if my previous message looked like I was blowing you off, I was
getting ready to take off ...

No worries !! .... I could "read" the rush <g>
.... and I've known you too long to be offended anyway !!

Post by Ken Mayer [dBVIPS]
but it is based on a seriously flawed
application ... I was not commissioned to fix all those flaws, and
frankly I really want the application DONE and not my problem anymore
... sigh).

I can sympathise with that !
Because I am both the business owner and the software developer, if I become
aware of a problem or even a potential problem it "has to be fixed".
I realise this bears no relation to the situation you are in with this job, so
I'm sorry if my previous post was a bit "Don't ignore this" ! I could just
forsee future problems arising.

No problem. My feeling is that if the client is happy with the end
result, and he has been running his business for years ... the code I'm
upgrading was written by his brother, but his brother passed away, so
while my client knows what it SHOULD do, he couldn't tell me how the
code works, and I can't ask the brother why he did something, etc. It's
been a weird experience.

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Bruce R. Roland]

Ken

... the code I'm upgrading was written by his brother, but his brother passed away, so

Excuse me but are we looking in the right place for the answer ... maybe what we really need is a good medium <grin>.

Bruce

[Ken Mayer [dBVIPS]]

Post by Bruce R. Roland
Ken
... the code I'm upgrading was written by his brother, but his brother passed away, so
Excuse me but are we looking in the right place for the answer ... maybe what we really need is a good medium <grin>.

There are times it might be useful, just to say "What were you
THINKING?" ... sigh.

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase