Re: Changing pricing based on any field

Quoting Nathan Wiger (nate@xxxxxxxxxxxx):
> 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.

We don't tend to do this type of name-dependent hard-coding, for
the same reason we don't use variables like ${"name_$something"}.

> 
>    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.

It is done this much way in the 4.7.x options.

> 
>    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.

And if it has a trailing %, it is a percentage.

> 
>    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.

And in addition, it is easy to write a UserTag that does the same thing. I
have solved this problem many times, and it is almost easier to re-write
the UserTag than it is to build a reusable version..

-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@xxxxxxxxxx>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer