Conceptual Excercise - Pricing

Progress Report:

I'm currently stuck trying to create the standard pricing table... It's a
little complicated and I'm having trouble wrapping my head around it.
Mostly, I'm waiting on Management to approve what I've come up with so far.
Once this is done I can see no reason not to implement the query suggestion
you guys made earlier. I imagine in my head a form with a bunch of combo
boxes set up in some sort of hierarchy that contain the criteria for pricing.
When one is selected the AfterUdate event limits my choices in the remaining
combos until finally you have a price based on all of those inputs. I've
read about this method in previous posts but I've never done it. I'll let
you know how it goes.
--
Why are you asking me? I dont know what Im doing!

Jaybird


"Tony Toews [MVP]" wrote:

Jaybird wrote:

I might better be able to tell what's going on in the code if I understood
better the structure of the query you are suggesting...

In your case you only really need the one table 'pricing process size
table' that you are "drilling" into with the various fields such as
ProcessID and size. Because I was using a price book which allows
for customizing the complete pricing system by customer or group of
customers along with a number of other additional factors my query had
four or six tables in it.

You seem to have
related at least three different tables: size, process, and customer
together in one table. In other words, I have a part of a certain size that
needs a certain process done to it, depending on what pricing model this
particular customer has I get a price. The key to this thing is, I believe,
the 'pricing process size table' which assigns a price for each possible
combination of price and size. This defines the 'standard' pricing which
will (hopefully) be used for pricing most of the jobs we get.

Correct.

From there I
can define the exceptions with customized queries, right?

Well no. Then you need to figure out what the business rules are
behind the exceptions. And you might, almost certainly, need to
add a customer ID field to the 'pricing process size table' and give
that customer a special price for that particular process/size entry.
Thus expanding the number of records much past 84 records.

Or group of customers. Maybe you have a ABC list of customers. A
gets the best price, B not quite as good a price and C a bit better
than list.

And tell mgmt that it's much easier to give customers x% of your
standard pricing rather than customized pricing where each item
process/size could have a different price. This will reduce clerical
work and the chance of errors. "Whaddya mean Joe Blow Inc has been
paying $4.40 for that process/size for the past two years when it
should've been $44.00." Especially when it comes to price changes in
the future.

I guess maybe I'm
just being stubborn. (Or dense) Maybe I do understand how this needs to
work and I'm just balking at the amount of work it will take. I don't know
why. Surely this is a lot less work than it would take to code it from
scratch... and a lot easier to read... and a lot easier to understand...
and a lot easier to fix in case something went wrong. If I'm still missing
something, please let me know...

Yes, this approach requires a different way of coding your the price
lookup. But once it's done and working then you just need to
maintain the prices using forms.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Jaybird wrote:

I'm currently stuck trying to create the standard pricing table... It's a
little complicated and I'm having trouble wrapping my head around it.
Mostly, I'm waiting on Management to approve what I've come up with so far.
Once this is done I can see no reason not to implement the query suggestion
you guys made earlier. I imagine in my head a form with a bunch of combo
boxes set up in some sort of hierarchy that contain the criteria for pricing.

Exactly.

When one is selected the AfterUdate event limits my choices in the remaining
combos until finally you have a price based on all of those inputs.

That depends if the choices are indeed dependent on the previous
choices. In same cases that might be the case and others not. For
example some processes might be limited to some ranges of sizes.

I've
read about this method in previous posts but I've never done it. I'll let
you know how it goes.

Feel free to ask questions as much as you want. You have some good
questions and your responses indicate you are a reasonably intelligent
person with common sense. We like those kinds of folks.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Well, that's very nice of you to say... Of course, if I was as intelligent
as all that I could probably remember the steps that are required. Not only
that, but I can't seem to find a suitable post that details these steps. Can
anyone refer me to a thread or refresh my memory? I'm trying to create some
cascading (I think that's what you call them) combo boxes that will limit the
selections in one based on the selection in another. This gets asked and
answered all the time, but when I'm looking for an appropriate thread, I
can't seem to find it.
--
Why are you asking me? I dont know what Im doing!

Jaybird


"Tony Toews [MVP]" wrote:

Jaybird wrote:

I'm currently stuck trying to create the standard pricing table... It's a
little complicated and I'm having trouble wrapping my head around it.
Mostly, I'm waiting on Management to approve what I've come up with so far.
Once this is done I can see no reason not to implement the query suggestion
you guys made earlier. I imagine in my head a form with a bunch of combo
boxes set up in some sort of hierarchy that contain the criteria for pricing.

Exactly.

When one is selected the AfterUdate event limits my choices in the remaining
combos until finally you have a price based on all of those inputs.

That depends if the choices are indeed dependent on the previous
choices. In same cases that might be the case and others not. For
example some processes might be limited to some ranges of sizes.

I've
read about this method in previous posts but I've never done it. I'll let
you know how it goes.

Feel free to ask questions as much as you want. You have some good
questions and your responses indicate you are a reasonably intelligent
person with common sense. We like those kinds of folks.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm