[ic] Variable/Attribute Pricing

[Nathan Wiger]

Jeff-

I just brought up the same issue. Here's the way I solved it, thanks to a
good amount of help from Mike Heins (Redhat).

What I did was make it so that fields that were going to modify the price
(i.e, like color and size) would be sensitive to a colon. All of this
happens in the main products db, no other external tables are used.

So, when creating/editing an item, a person would say:

   Price:  25.00
   Size:   S, M: -$5, L: +$10, XL: +$15
   Color:  Blue, Green, Red: +$35

The builtin [item-attributes] tag would then ignore this (since there's
nothing special about a colon to Akopia) and would make select lists like:
          _____________
   Size:  | S         |
          | M: -$5    |
          | L: +$10   |
          | XL: +$15  |
          -------------
          _____________
   Color: | Blue      |
          | Green     |
          | Red: +$35 |
          -------------

Then, I wrote a simple UserTag routine called "nw_modprice" which was
sensitive to the colon, and added/subtracted the appropriate values from the
base price. The part that caught me was I had to set the following variables
in catalog.cfg:

   CommonAdjust  [nw_modprice] ;:price
   PriceField    no_price

If you don't set PriceField to no_price (or some other non-existent field)
then CommonAdjust will be bypassed.

Check out this email for more details on CommonAdjust:

http://developer2.akopia.com/archive/interchange-users/2001/msg03850.html

In particular, note that inside your price modification routine, the current
value of the price chaining is available as $s, the current quantity as $q,
and the current item hash is available as $item.

-Nate

"Jeff Worsley" <jeffw@contactdesigns.com>:
>
> I want the abillity todo 2 things... the first is to manipulate the
> price field in such that you would enter "3.00,+2.00,+3.00". so the
> first part is the defult price value (3.00) of that item and the other
> parts of that field are the ups or downs of that item... ok now we add
> another field to the Item table... "Price By" in this it would be such
> "Size" "COLOR" or "Wieght" so lets say I select "Size" now when I fill
> out size I simply put "S,M,L" and the attributs are assotiated with the
> size and price... the reason I want this to be an BY ITEM basis, is
> because I want to not be limited to All products on the site to S,M,L or
> for that matter, I want to charge by wieght sometimes, on some items.
> CommonAdjust is just for Quantaty Sizing, or everything on the site has
> to be thought of in then catalog.cfg...