Re: [ic] Preference for Pricing Scheme?

[Mike Heins <mikeh@minivend.com>]

Quoting Nigel Hathaway (nigel@bprj.co.uk):
> 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.
the string 

	pricing:q3,q6,q9,q12 ;:price

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
things. Example:

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.

Best,
Mike
-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Friends don't let friends use Outlook. -- Bob Blaylock

_______________________________________________
Interchange-users mailing list
Interchange-users@www.minivend.com
http://www.minivend.com/mailman/listinfo/interchange-users