If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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 |
#12
|
|||
|
|||
Conceptual Excercise - Pricing
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 |
#13
|
|||
|
|||
Conceptual Excercise - Pricing
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 |
|
Thread Tools | |
Display Modes | |
|
|