I have two questions about how inventory and billing software handles
pricing.

I understand that cost, selling price, discounting information, etc.,
can all be stored in item records and accessed by the invoicing
program and that some algorithms may be applied for grouping of items,
calculating discounts for certain customers, etc.  I don't need an
explanation of any of the basics of billing and inventory control
records design or the general logic of business applications.

What I'm after is the logic typically used in two pricing situations. 
I know something about how this was done with the cards and diskettes
and computers of 30 years ago; I want to know how it's done now, with
a completely different set of storage and retrieval capabilities
available to users.  How does contemporary business software typically
handle these two specific situations?

1.  When a sale price is in effect for a routine retail sale, what is
the trigger that tells the system to use the sale price rather than
the regular price?  Is it keyed to date, and if so, is the effective
date of sale price stored in the inventory record?  What I want to
know is how the system knows which price to use for a given routine
sale (where there's no discount by customer number, no group discount,
no prior quote, etc.).  When I buy a box of, let's say, Crunxy Crax on
sale at the supermarket, what pieces of information have to come
together, and how do they come together, for me to get the sale price?
 I am assuming this is not a method of actually changing the selling
price outright and then changing it back after the sale because I see
that commercially available inventory systems are likely to have a
"sale price" field in addition to a "selling price" or a cost field
plus markup percentage.  What I don't see is a key to when to use the sale price.

2.  How are actual price changes prepared for inputting and then input
to the system?  Let's say the price of the box of Crunxy Crax goes from
$2.75 to $3.00 on April 1st.  Is the $3.00 price stored in the
inventory record along with an effective date, so it's not used before
that date?  Do new prices, stored outside the inventory file, get
input at midnight on the effective date and overwrite the old price? 
If the latter, is there a manual operation involved, or is there an
automatic price updating function set up that can be left to run
itself at the designated time?  What I'm looking for here is how price
change information, such as a price increase, is prepared in advance
but held back so that the new price is used on the effective date and
not before.

I realize that specifics may vary from one software vendor or
customized instance to another.  I am just looking for what is the
standard solution for these situations.  Since one solution would
probably work for a wide spectrum of businesses, I am assuming that
there is a fairly small number of approaches and that most creators of
business software use one of the conventional solutions.  I just want
to know what the prevailing wisdom or the usual treatment is.

Thank you.

I'm a programmer in a different field, so perhaps this answer doesn't
apply to your particular kind of system, but in general: even in areas
where you'd expect there to be a standard approach, there generally
isn't one.  I would guess that there are commercial systems that
implement all of the different approaches you mention above.  for that
matter, it wouldn't surprise me at all if you could find a *single*
system which implemented all of these approaches, in response to
customer requests.

Thanks, Dave.  I imagined that variation would be the case.  But I am
not just listing alternatives and asking which one is right.  Those
were guesses.  I am asking how it is done at all.  If there isn't a
standard solution, what is *a* working solution?  How does the system
know when to use the sale price?  How is a price change prepared but
held back from use until the right time?  Those are my questions.  I
am after a working solution and not a survey of relative popularity of
solutions that I am providing.

Just to clarify my situation, I am not a programmer (although I have
been), and I am not writing an application.  I am trying to define
requirements for solving another problem entirely.  The problem I want
to solve is a direct analog of the pricing problem, which I remember
from my programming days.  So if I can find out how pricing solutions
are being implemented now, I can come up with a recommendation for the
case I am trying to deal with.