[ic] Changing pricing based on any field

Nathan Wiger interchange-users@lists.akopia.com
Thu Jun 14 12:28:00 2001


Hey all-

I have a client who has some needs which I don't think are supported by
Interchange. However, I'm hoping that I'm wrong :-), so I wanted to ping the
list.

The client is opening a motorcycle parts store online. For many parts,
though, the price will vary based on several different fields. For example:

   Base helmet        $100.00
   XL and XXL         +$15.00
   XS                 -$10.00
   Metallic Paint     +$30.00

Now, I'm aware of Interchange's pricing database. The problem isn't with
size (since this is built in), but rather getting the price to change on
another variable (like color -- the paint above) as well.

This situation gets even trickier in some situations, where the size is not
just "XL" but rather corresponds to a model as well:

   Aftermarket Tailpipe   $165.00
   CBR, Yamaha            +$25.00
   Ducati                 +$45.00
   Black Chrome           +$15.00

The model information must be maintained, so we can't just say "L=Yamaha,
XL=Ducati" in the "size" field. So, if we were just to use the pricing
database, I'd have to create fields for all potential "sizes" -- S, M, L,
XL, Ducati, Yamaha, CBR, 17", 18", etc. This is obviously not really what I
want to do, since there's no way to tell what fields will be needed, and
besides that it would be really ugly. Plus, there's still no way to alter
price on size _and_ color as far as I can tell.

Is all this correct? If not, please stop and tell me where I'm wrong,
because the rest of this email is a proposed solution.

So, after looking at this it seems like the way that pricing is done in
Interchange could be tweaked to make it a little more flexible. Here's what
I was thinking. If you set a field up via UseModifier to alter the product,
then rather than Interchange looking in the pricing db, it does the
following:

   1. Looks for a field called "[field]_price" in the products db.
      So, if you set "UseModifier length", it would look for a
      field called "length_price" for that sku in the products db.

   2. This field takes the format "name=price, name=price", so for
      example:

          CBR=+25.00, Yamaha=+25.00

   3. This field is split up appropriately, and a key is searched
      for one corresponding to the value of the main field chosen.
      So, if we chose "CBR" as our "size", then we would look
      in "size_price" for the key "CBR" and find the value "+25.00".
      If the key isn't found, no change is made to the price.

   4. If the price is preceded with a + or nothing, it's added to
      the base price. If it's preceded with a -, it's subtracted.

   5. On checkout, these prices are added in the same order as
      the fields are listed with UseModifier. So, if we had
      said "UseModifier size color", then we would first go thru
      and look for "size_price" for that item, then "color_price".

This has the advantage that it is flexible and can be tailored on a per-item
basis. I supposed it could also be placed in an external table indexed by
sku, but it seems like keeping it together in the products db would be
easier.

Thoughts on this? If there's intereste, I'm more than willing to make the
changes to the source and check them in. I'd like to make these changes to
the main product; otherwise I'll have to repeatedly apply diffs everytime I
upgrade the client's software.

Thanks,
Nate

--
Nathan Wiger
Systems Analyst and Perl Hacker
Nateware, Inc. www.nateware.com