Re: CommonAdjust (driving me batty, Help please)

[mikeh@minivend.com]

******    message to minivend-users from mikeh@minivend.com     ******

Quoting Rob Zimmerman (rob@readysite.net):
> 
> Well I have tried numerous scenarios to try and get CommonAdjust to 
> simulate the MixMatch directive. I will say that I have a much better grasp of 
> CommonAdjust but I still have not solved my problem. 
> 
> Tried adding a UseModifier  'volume' so I could see if the attribute feature 
> would work; ==volume:pricing  but it didnt :-( and yes I added volume to my 
> products database with the field contents 'yes' on  the items I wanted to run 
> through the quanity pricing scheme with the column 'yes' in the pricing 
> database with those fields containing the CA string pricing:q1,q2
> 
> It seems to me that using MixMatch = yes and then somehow turning it off 
> for those items not wanted would be the way to go, but I have no idea how to 
> do this as MixMatch is not documented other than how I have used it. 
> 
> Also not well documented is the use and examples of minivend tags within 
> the commonadjust sting. The use of the option key* is always explained as 
> "defaults to item code" but I wonder what else it is used for and how? If I had 
> a item keyed and it was chained would it look through the column adding up 
> all those that I wanted to apply the string too? 
> 
> Maybe my logic is all screwed up here....I have been looking at this too long 

You are attributing too much magic to it. There are at least a thousand
ways to do pricing and you cannot anticipate them all. If someone
finds something more capable than MiniVend in this area please give
me details and I might be able to do something to improve upon it.
As far as I have heard, MiniVend completely decimates the field in this
area. But...it cannot do and anticipate everything. There are too many
ways to do pricing, shipping, and taxing. That is why I tried to build
in hooks to attach your own subroutines where appropriate.

The bottom line is you cannot do something like this without special programming.
I have done some of the special programming for some situations, which is why
you can do quite a bit with MiniVend's pricing without writing any Perl code.

I think you are making a "reflex" bash on the documentation.  While it
may not be very well written, what do you mean "what else it is used
for and how?" What do you think a key is used for when combined with a
table and a column? Perhaps I should include a link to a database primer
at the head of every paragraph. 8-)

And I really don't encourage use of MV tags within pricing routines for
most people. If it is done poorly (meaning with [if ... ], [loop ...]
and such) the catalog will slow to a crawl. So I don't go into great
detail because it is not a wise idea unless you know exactly what you
are doing. If you know that much you should easily be able to figure
it out. It CAN be a good way to call a precompiled subroutine, meaning
a UserTag.

This is one situation where you can't avoid special programming simply
because the pricing depends so much on the data. I would bet not more
than a couple of people can visualize what you are talking about because
you have not described the data structures at all. I know what "MixMatch
over multiple groups" means but I am not sure too many other people
do.

If you are going to do special programming you should look at
the source code. That is one reason it is there.  The current item is
available as the variable $Vend::Interpolate::item.  Write a UserTag or
routine with code like:

##
## This works in catalog.cfg because Vend::Session and Vend::Interpolate
## are exempted from Safe checking in UserTags
##
UserTag check-breaks Routine <<EOR
sub {
    # Better would be a global usertag and $cart = $Vend::Items;,
    # which would work for all shopping carts
    my $cart = $Vend::Session->{carts}{main};

    my $item;
    foreach $item (@$cart) {
        # do your counting and grouping here
        #
        # This is just a test that only sets the t-shirt
        # to quantity 25 pricing
        #
        # &Vend::Interpolate::tag_data() would work here,
        # but it would be best to have a preset grouping
        # attribute for performance.
        $item->{price_group} = 'pricing:q25' if $item->{code} eq '99-102' ;
    }
    return $Vend::Interpolate::item->{price_group};
}
EOR

Then

# tag touch prepares for use of tag_data, not really needed for
# SQL or memory databases
CommonAdjust <<EOF
"[tag touch products][/tag][check-breaks]"
products:price
EOF

Of course this is skeleton code and needs the grouping routines.

If you wanted to do just a simple MixMatch, then a little thing like:

UserTag mix-match Order number
UserTag mix-match Routine <<EOR
sub {
	my $nitems = shift;
	my $ca_string = 'products:price';
	my $level;
	my @breaks = ( 5, 10, 25 );
	foreach $level ( @breaks ) {
		last if $nitems < $level;
		$ca_string = "pricing:q$level";
	}
	return $ca_string;
}
EOR

CommonAdjust   "[mix-match number='[nitems]']" ;products:price

Of course this type of thing can be expanded infinitely. Be careful
on your DB accesses though, or performaance goes out the window.
You don't want to use [item-price ....] on your search lists if you do
pricing like this and hit the database at all. Use [currency][item-field
price][/currency] instead.

I worked very hard on CommonAdjust chained costing because I wanted to
provide a high-performance method for doing complex pricing, shipping,
and taxing. I think it succeeds there, but that it will take time for
people to learn to use it. When I get the new UserTag repository up I
hope this will be the kind of thing that goes there.

-- 
Mike Heins                          http://www.minivend.com/  ___ 
                                    Internet Robotics        |_ _|____
                                    131 Willow Lane, Floor 2  | ||  _ \
It's a little-known fact            Oxford, OH  45056         | || |_) |
that the Y1K problem caused         <mikeh@minivend.com>     |___|  _ <
the Dark Ages. -- unknown           513.523.7621 FAX 7501        |_| \_\
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list