[ic] Controlling checkout.html shipping method selections

Mark Bryant interchange-users@icdevgroup.org
Sun May 4 18:57:00 2003


At 20:02 04/05/2003, you wrote:
>At 06:35 PM 5/4/2003 +0100, you wrote:
>>At 18:11 04/05/2003, you wrote:
>>>At 05:52 PM 5/4/2003 +0100, you wrote:
>>>>At 17:02 04/05/2003, you wrote:
>>>>>At 10:07 AM 5/4/2003 +0100, you wrote:
>>>>>>Hi Folks,
>>>>>>
>>>>>>I'm having a bit of trouble with the shipping methods displayed on 
>>>>>>checkout.html.
>>>>>>
>>>>>>I've already set up two shipping methods (let's call them SHIP1 & 
>>>>>>SHIP2), where the calculation is done by weight and they are behaving normally.
>>>>>>
>>>>>>What I would like to do now is customise which one is displayed by 
>>>>>>checkout.html dependent on the cost of the goods+sales tax :
>>>>>>
>>>>>>
>>>>>>     [if] (the cost of the goods + sales tax <= 28.00)
>>>>>>
>>>>>>        Show both methods in checkout.html
>>>>>>
>>>>>>     [if] (the cost of the goods + sales tax > 28.00)
>>>>>>
>>>>>>        Only show method SHIP2 in checkout.html
>>>>>>
>>>>>>     [/if]
>>>>>>
>>>>>>
>>>>>>The checkout.html page is currently showing both methods using this 
>>>>>>code, which I guess if just fine in the < 28.00 case, but not for 
>>>>>>the > 28.00 case.
>>>>>>
>>>>>>     <SELECT NAME=mv_shipmode>
>>>>>>     [shipping
>>>>>>       label=1
>>>>>>       mode=|[data table=country key='[default country UK]' 
>>>>>> col=shipmodes]|
>>>>>>     ]
>>>>>>     </SELECT>
>>>>>>
>>>>>>
>>>>>>I'll freely admit that I don't understand how most of the IC 
>>>>>>tags/code work and having spent hours looking at code and getting 
>>>>>>nowhere fast I have to ask if someone out there could supply the code 
>>>>>>(or enough of it to get me going) to do the job. I'm sure it's pretty 
>>>>>>simple if you understand how getting data from the databases works, 
>>>>>>but I'm so lame with IC right now I couldn't even write the required 
>>>>>>[if][/if] lines :o(
>>>>>>
>>>>>>Many thanks to anyone that can help out here.
>>>>>>
>>>>>>Mark
>>>>>
>>>>>I'll start by saying that I've never tried it before, but according to 
>>>>>the docs, your shipping formula can contain any mixture of ITL and 
>>>>>Interchange Perl objects as part of the expression, so this *should* work:
>>>>>
>>>>>SHIP1   Shipping method 1       weight  0       9999    f if ( 
>>>>>$Tag->subtotal({ noformat => 1}) + $Tag->salestax({ noformat => 1}) <= 
>>>>>28 ) { #your shipping formula here }
>>>>>
>>>>>- Ed L.
>>>>
>>>>Hi Ed,
>>>>
>>>>Many thanks for your reply :o)
>>>>
>>>>I've been using the UI to input the shipping method and data table 
>>>>which has produced the following in shipping.asc:
>>>>
>>>>REC2ND  Standard Shipping (3-5 Days)    weight  0       0       e Your 
>>>>Basket is Empty!         {'ui_ship_type' => "weight",'ups' => 
>>>>"0",'at_least' => "0.98",'PriceDivide' => "1",}
>>>
>>>Hmmm. I didn't guess that you had this many entries per shipping method. 
>>>In any case, if you were to apply my idea to this, it would look 
>>>something like:
>>>
>>>REC2ND  Standard Shipping (3-5 Days)    weight  0       60      f if ( 
>>>$Tag->subtotal( { noformat => 1} ) + $Tag->salestax( { noformat => 1} ) 
>>><= 28 ) { 0.98 } else { 0 }           {'PriceDivide' => "1",}
>>>
>>>I really have no idea if it will work or not, though in theory it should.
>>>
>>>- Ed L.
>>>
>>>>[del]
>>
>>Ed,
>>
>>You're a star!!
>
>Hardly!
>
>
>>Many thanks once again :o)
>>
>>Mark
>
>You are welcome. I occurs to me that the shipping selector might still 
>return the shipping method, but with $0.00 as the cost, because the 
>criteria (weight) will still be within the scope of the method. I don't 
>recall if [shipping ...] omits methods on out-of-range, returning zero, or 
>both. Also, another way to handle this might be a usertag (the following 
>is untested):
>
>UserTag noshipping Order limit cost
>UserTag noshipping Routine <<EOR
>sub {
>         my ($limit, $cost) = @_;
>         my $current = Vend::Interpolate::subtotal();
>         $current += Vend::Interpolate::salestax();
>         if ( $current >= $limit ) {
>                 $cost = 0;
>         }
>         return $cost;
>}
>EOR
>
>Then each entry of your shipping method would look something like:
>
>SHIP1   Shipping method 1       weight  0       9999    f [noshipping 
>limit=28 cost=0.98]
>
>Again, I'm not sure whether or not the selector on the checkout page will 
>suppress the $0.00 cost.
>

er pass, that's a bit over my head for the time being, but I did notice 
that the checkout page was sometimes showing a 0.00 result for shipping 
when working out the final total even though the shipping method shown in 
the drop down was the correct one.. I suspected that it was a minor bug or 
me not doing something right (probably more likely to be me of course).

So, after a bit of testing to be sure my computer/browser wasn't confused, 
it appeared that:

"If the order total was pushed over the limit for a shipping method by a 
recalculate, if the shipping method chosen before the recalculate became 
unavailable as a result of the recalculate, the 0.00 value appeared whilst 
the shipping methods drop down would be correctly populated."

What I did in the end to fix this was all done via the UI and really simple 
(as all good things should be)...

I edited the data table for the method, selected "Formula" as the charge 
type for the line and put the following in Charge Amount whilst editing the 
{ 0.98 } bit appropriately.

if ( $Tag->subtotal( { noformat => 1} ) + $Tag->salestax( { noformat => 1} 
) <= 28 ) { 0.98 } else { 0 }

Then I set the SHIP_DEFAULT_MODE (in the variable table) to the first 
shipping method code that's known to be available all the time (SHIP2). By 
doing this I seem to have avoided any spurious calculations for SHIP1 and 
other methods that may not be available after an update. Put it this way, 
it's working fine atm. I'll try the usertag route if things go pear-shaped :o)

Thanks once again.

Mark