[ic] Preference for Pricing Scheme?

[Nigel Hathaway]

I know this doesn't answer your question in the way you want it, but I do
believe that the issues you face are fundamental and not an obscure niche.
In addition, I am newer to Interchange.

I noticed an earlier posting where someone was trying to set up a website
like Dell's where you specify options on your computer, and the price of the
option varies depending on what you buy it with (or not).

Interchange does have the concept of 'accessories', but it seems that all
products have to have the same accessories (size, colour in their example).
It seems that you can also bundle products into order groups if you
structure the shopping cart differently, but I couldn't work out what the
documentation meant.  Further to that, the on-line help talks about a
non-existent 'matrix editor' which is supposed to say what options go with
what.

I am setting up a site for semi-custom products where each product has very
different 'accessories' (options) one to the next, and the price of the
option depends on the product it is attached to.  Also, in my case, some of
the options are not multi-choice, but require user entry of text (because it
is printed on the product).  A UK product call 'Actinic' (www.actinic.co.uk)
came a very close second to Interchange, and it may well be worth Akopia
downloading an evaluation copy and stealing a few of their ideas.  It does
what you want easily and with no technical expertise required (just point
and click), but it falls down on the programmability.

I have a feeling that the current Interchange suggested way of doing all
this is heading down a blind alley, and a step back is needed.

Quit beating about the bush: here's how I think Interchange could be
modified:

1. Create a new table called 'options' with columns as follows:
name (indexed) - values e.g. one of size, colour, hard drive, memory
attribute - values e.g. one of red, green, large, small, or NULL if no value
associated
widget - radio, check box, pull-down etc. - must be the same for all
attributes under a name
sku (indexed) - product code or NULL if general and not product specific
weight - additional weight to the associated option
price - price code for looking up in a modified pricing table (see below)

Expect many instances of the same 'name', but one per sku/attribute
combination.  In the same way, expect many instances of sku and attribute.

2. Remove columns like 'colour' and 'size' from the products table and
create a new field called 'options'. This contains either:
(a) *, in which case the SQL query in the options returns all records for
the matching sku, or
(b) a comma-separated list of names, in which case the SQL matches the
'name' column and NULL sku. (could do: name1=[opt1,opt2], name2=[optx,
opty]... - this may be considered syntactically complex)

3. In the products table, remove 'wholesale', and make 'price' mean price
code and not actual price.

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.

5. The orderline table needs a bit of tidying up.  Remove 'colour' and
'size', and use the options field with comma list: name1=opt1, name2=optx...

In addition, it's immediately obvious that even with the current accessories
scheme, the administration UI for orders cannot cope with
options/accessories and needs an overhaul anyway.

Comments?

Nigel Hathaway


-----Original Message-----
From:	Loy Ellen Gross [mailto:design@iinc.com]
Sent:	30 November 2000 20:55
To:	interchange-users@minivend.com
Subject:	[ic] Preference for Pricing Scheme?


For you pricing gurus out there; I've done the basic research and am
looking for an experienced opinion:

I have around 400 items for sale (both kits and individual):

- Kit A contains one each of products X, Y and Z for $39.95

- Kit B contains one each of products W, X, Y and Z for $69.95

- Products W, X, Y and Z are also available individually at
  various prices without the Kits: e.g. Product X: $14.95, etc.

- and also available as multiples after the initial Kit has been
  purchased, e.g. the first product X is included in Kit A, but a
  second product X is $14.95 even with Kit A.

OK. I know I need Order Groups - not a problem. I can use
[loop arg="[item-field related]"] to pull all items together and
build the code on the fly for a one-click, multiple item order
using something like:
  <FORM ACTION="[process-target]" METHOD=POST>
  <INPUT TYPE=hidden NAME=mv_todo VALUE=refresh>
  <INPUT TYPE=hidden NAME=mv_order_group VALUE="1">
  <INPUT TYPE=hidden NAME=mv_order_item VALUE="[item-code]">
  [loop arg="[item-field related]"]
    <INPUT TYPE=hidden NAME=mv_order_item VALUE="[loop-code]">
  [/loop]
  <INPUT TYPE=submit VALUE="Order Kit A">
  </FORM>
yes?

Pricing: I know I can do this with CommonAdjust, using an attribute
field "status" and setting that field based on which other products
are in the cart... and I know I can do it on the fly with
[discount [item-code]] perl here [/discount]. Perhaps there is even
a third way that I haven't found.

Are there any preferences among scriptors with experience? My thought
is that since I'm going to have to drop to perl anyway to count
the number of instances of items W,X,Y,Z in the cart that I
might as well use discount. That may also stem from the fact that
although I believe I understand CommonAdjust, I've never been able
to actually get it working :-)

Performance issues? Legacy issues? Simplicity issues?

[Pie in the sky] Sample code?

Thanks much!

  -- Loy

--
"Any language where the unassuming word "fly" signifies an annoying insect,
	a means of travel, and a critical part of a gentleman's apparel
		is clearly asking to be mangled." -- Bill Bryson

    Loy Ellen Gross * Web Designer & Programmer * Xcalibur Internet
          716-344-1114 * design@iinc.com * http://www.iinc.com
      Xcalibur Internet is part of the BiznessOnline.com Network