[ic] Preference for Pricing Scheme?
Fri, 1 Dec 2000 09:07:25 -0500
Quoting Nigel Hathaway (firstname.lastname@example.org):
> 4. Scrap the existing pricing table (used for quantity discounts), and
> replace it with and new pricing table, with columns as follows:
> code (indexed) - the price code in the products or options table
> quantity - the maximum number of items for which the price applies
> wholesale - boolean (if both combinations are not present, then price
> applied to both)
> price - unit price for that code and quantity
> I don't find it's helpful having the same discount structure for all
> products, by having q2, q4, etc. columns.
> Product pricing is normally grouped like this - go into any shop and see how
> many different price values there are.
Very interesting post, I am re-replying. 8-)
I am sure I seem obtuse a lot of times to a lot of people, but I have
two reasons for not using what would usually be the easy way
out and relying on tree structures and fast SQL queries.
1) Part of my reluctance is my non-SQL background. It would be very
inefficient if you cannot do multiply-indexed selects on the database,
and would fall apart for large GDBM databases. Now that Interchange has
such good SQL support, though, I really don't recommend using GDBM for
larger databases. Even then, the cost of SQL queries can get big when
you have large tables.
Also, 2) I am constantly fighting the battle of not imposing structure
such that only our tools can maintain a product. I always want to keep
it such that Interchange data can be maintained via a spreadsheet or
foreign database tools. Once there is too much tree structure, that
becomes impractical. If it gets even more complex, you must rely
on features like foreign-key constraints to prevent your database
from getting full of garbage over time.
You can actually set up different quantity pricing structures in Interchange
by putting different CommonAdjust structures in the pricing field, i.e.
And you can produce some symbolic things with:
Variable DEALER_Q3 wholesale:q3,q6,q9,q12 ;:wholesale
Variable RETAIL_Q3 pricing:q3,q6,q9,q12 ;:price
and put __DEALER_Q3__ and __RETAIL_Q3__ in the price and wholesale fields.
All that being said though, it still doesn't address the dealer-pricing
issue, or at least not really.
I have added a Profile feature in 4.7.x, one that allows you to set a
field in the userdb (price_level) by default, that can determine some
Profile dealer CommonAdjust pricing:price_group,w5,w10,w25 ;:wholesale
Profile dealer NontaxableField nontaxable
Profile dealer DefaultShipping ups
Profile default CommonAdjust pricing:price_group,q5,q10,q25 ;:price
Profile default NontaxableField
Profile default DefaultShipping postal
Then you set "dealer" for that user, and when they log in they get those
directives applied. It is not that different from the Locale scheme. In fact,
I am going to have to figure out how to reconcile that; it may be hard to
do both, though of course you could have dealer_en_UK and dealer_fr_FR.
Along with that, I am implementing a new options pricing scheme somewhat
along the lines of what you had mentioned. I will live with the fact that
it is difficult to maintain via external tools. 8-\
Thank you for a very well thought out post. Posts like yours do a lot to help
Interchange get better.
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH 45056
phone +1.513.523.7621 fax 7501 <email@example.com>
Friends don't let friends use Outlook. -- Bob Blaylock