[ic] Controlling checkout.html shipping method selections

Mark Bryant interchange-users@icdevgroup.org
Mon May 5 12:51:01 2003


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

OK it looks like I spoke too soon and you're right Ed.....

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.

I tested this many times yesterday and really thought I'd solved it, but it 
appears it doesn't want to play today.

I'm wondering if it's worth putting some additional code on checkout.html 
could see if there was a valid shipping method available and then do an 
auto refresh/recalculate of the page if the value of shipping is 0.00? A 
recalculate seems to get the shipping value aligned with the chosen method. 
I'm still confused as to why the shipping drop down is correct and the 
shipping value isn't. Is this not in fact an IC bug?

Short of doing the auto-recalculation here I'm stumped as to get these two 
things aligned and am open to suggestions from those that have been here 
before.

Many thanks

Mark