David
I assume yours was not rhetorical ...
I would have a [Discount] field, since that, too, is data I may want to
know about later...
--
Regards
Jeff Boyce
Microsoft Access MVP
Disclaimer: This author may have received products and services
mentioned in
this post. Mention and/or description of a product or service herein
does
not constitute endorsement thereof.
Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.
You can thank the FTC of the USA for making this disclaimer
possible/necessary.
"David C. Holley" <David.C.Holley> wrote in message
Ah...but how would you handle negotiated rates on a per account basis?
Or applying a discount? There could be some scenarios where the nature
of the transaction is such that the invoice can't show that a standard
rate was discounted. For example, the client is paying $75 for an item
that normall sells for $100, but the billing has to show $75 as opposed
to $100 with a 25% discount.
message As Gina points out, in invoicing, you might want to store the
"point-in-time" unit price as part of the transaction for a
product/item, mainly because that item's price can change over time.
However, it is NOT necessary to do so, as you could design a (much
more complex) table structure that held ItemID, UnitPrice, FromDate,
and ToDate, and use this structure to track the price changes for
items over time. You would also use this to "know" what the price was
when the transaction happened (i.e., using a TransactionDate).
As pointed out elsethread, there may also be performance issues that
would make it more likely to see a stored calculated value... but if
that's the case, you might also be looking for a more robust,
server-based back-end for your data!
Best of luck!
--
Regards
Jeff Boyce
Microsoft Access MVP
Disclaimer: This author may have received products and services
mentioned in
this post. Mention and/or description of a product or service herein
does
not constitute endorsement thereof.
Any code or pseudocode included in this post is offered "as is", with
no
guarantee as to suitability.
You can thank the FTC of the USA for making this disclaimer
possible/necessary.
Yups, thats what i thought but i thought it best to make sure as
didnt want
to make changes down the line...
One question though: you say it is "rarely necessary" - when would
it be
necessary? I mean when would you NOT put it in a query?
:
As suggested elsethread, it is rarely necessary to store a value you
can
calculate.
Use a query to return the calculated value 'on-demand'.
--
Regards
Jeff Boyce
Microsoft Access MVP
Disclaimer: This author may have received products and services
mentioned in
this post. Mention and/or description of a product or service herein
does
not constitute endorsement thereof.
Any code or pseudocode included in this post is offered "as is",
with no
guarantee as to suitability.
You can thank the FTC of the USA for making this disclaimer
possible/necessary.
Not sure if im posting this in the right category; if not
apologies...
Ive created a pretty straight-forward table to capture training.
So one
of
those fields is "Seats Available" with a number such as 25.
Another field is Seats Booked - lets say that value is 20...
I want a 3rd field: Seats Left to calculate automatically
so i
thought
i
could do that when designing the table but i cant see any wayn of
doing
it...
I know it can be done if i pull it into a query
.