Modify Shipping Charge in Basket

[Leanne]

I have a site with somewhat complex shipping needs, and I have not been able to come up with anything using shipping rules to make it work.


Product A ships for 6% of Product A's total only to Canada

Product B ships for 25% of Product B's total only to Canada

These two product types are frequently ordered together.

Currently the Tool Kit is being used to add a surcharge to the basket charges if Product B is in the cart. But, the price of Product B is being included in the shipping calculations in addition to the surcharge.

What I would like to do is to be able to delete the shipping charge and the surcharge from the basket and replace them with a properly calculated single shipping charge, but I'm not having much luck so far. for the moment, I'm just playing with deleting the existing shipping charge and replacing it with the surcharge. When I view the Tokenlist on the OPAY page, it looks correct. The original shipping charge is gone, and the new shipping charge shows. But, on the front end, I'm not seeing the change. Any idea what I'm doing wrong, or alternatively, a better way to go about this?

    <mvt:do file="g.Module_Library_DB" name="l.success" value="BasketCharge_Delete_All_Type(g.Basket:basket_id, 'SHIPPING')" />
    <mvt:assign name="g.amount" value="glosub(g.hardware_formatted_surcharge,'$','')" />
    <mvt:assign name="l.basket_charge:basket_id" value="g.Basket:basket_id" />
    <mvt:assign name="l.basket_charge:type" value="'SHIPPING'" />
    <mvt:assign name="l.basket_charge:descrip" value="'Shipping: UPS Ground'" />
    <mvt:assign name="l.basket_charge:amount" value="g.amount" />
    <mvt:assign name="l.basket_charge:disp_amt" value="g.amount" />
    <mvt:assign name="l.basket_charge:tax_exempt" value="0" />
    <mvt:do file="g.Module_Library_DB" name="l.success" value="BasketCharge_Insert( l.basket_charge )" />

[Bruce - PhosphorMedia]

Is the ToolKit added surcharge actually labeled 'SHIPPING' as type (my memory says it defaults to something else).

(We have a nifty little free tool called Database Viewer -- https://www.phosphormedia.com/product/pm_dbviewer.html -- to actually check whats in the database. Much faster than launching phpMyAdmin.)

Also, why not just run the ToolKit process AFTER the internal shipping modules do there stuff and instead of inserting as a separate charge, add it to the current charge calculated. So,

When the customer goes to OSEL, calculate the charges manually, save that value and in the shipping methods array, add that value to each of the relevant shipping options.

When the customer goes to OPAY, pass that value in and do a BasketChargeDelete, BasketChargeInsert. (BTW: all of this can be done without toolkit.)

[Leanne]

Is the ToolKit added surcharge actually labeled 'SHIPPING' as type (my memory says it defaults to something else).

(We have a nifty little free tool called Database Viewer -- https://www.phosphormedia.com/product/pm_dbviewer.html -- to actually check whats in the database. Much faster than launching phpMyAdmin.)

Also, why not just run the ToolKit process AFTER the internal shipping modules do there stuff and instead of inserting as a separate charge, add it to the current charge calculated. So,

When the customer goes to OSEL, calculate the charges manually, save that value and in the shipping methods array, add that value to each of the relevant shipping options.

When the customer goes to OPAY, pass that value in and do a BasketChargeDelete, BasketChargeInsert. (BTW: all of this can be done without toolkit.)

The Toolkit type is TKUPCHARGE (and the Toolkit function was put in place long before these kinds of things were possible without it :) ). Thanks for the tip on the database tool, I'll add that to my arsenal.

What you propose is essentially what I'm trying to do. I am calculating the surcharge on OSEL, and passing it to OPAY. But, the BasketChargeDelete and BasketCharge Insert functions aren't doing anything on the front end. The original shipping charge still shows in the basket (and yes, the code is placed before the basket charges array in the basket).

[Bruce - PhosphorMedia]

ok, remember I'm not a toolkit user, but if Toolkit is calculating the 'add on' shipping fee, you'll need to use

mvt:do file="g.Module_Library_DB" name="l.success" value="BasketCharge_Delete_All_Type(g.Basket:baske t_id, 'TKUPCHARGE ')" /> to remove that entry. though, upon more careful reading (i.e., third cup of coffee) i note this: "But, the price of Product B is being included in the shipping calculations in addition to the surcharge." so, are you really saying that the toolkit created upcharge is calculating say $2.05 as its 'upcharge', but the database entry shows 2.05 + Product_Cost?

[Leanne]

Aha. I'm not being clear (surprise!). The code snippet I provided is ignoring the Toolkit upcharge for the moment while I just try to get the basics hammered out. The upcharge is in addition to a regular shipping charge, and that regular shipping charge is what the code in my first post is trying to remove and replace.

So the basket charges show, say:

SHIPPING: UPS Ground $5.00 ($4.00 for Product A and $1.00 for Product B -- this is built in shipping charge)
TKUPCHARGE: UPS Ground - Surcharge $2.00 (Product B only, should be total shipping charged for Product B)

The goal is to combine the built in shipping charge (value only for Product A) with the surcharge (value only for Product B) into a single charge. This part I can figure out, it's just math. Then I want to remove the existing Shipping and Surcharge amounts, and replace them with this new combined total as an item of type: SHIPPING.

But the Delete and Insert functions aren't working. That's the part I'm trying to figure out.

[Bruce - PhosphorMedia]

If the delete isn't work, I suspect its a timing issue (i.e, charge isn't there).

As for the insert, I don't see a "l.basket_charge:module_id"....and i'm not sure it would fail it or not, but change "l.success" those functions to g.deleteHere and g.insertHere,

then eval them. it should be 1 if the function THINKS it worked and empty (or -1) if not

[Leanne]

I did wonder about the module id, because that comes up as 0 in the token list. However, I ran this code and got 1s all around, but still have the old charges in the basket.

    <mvt:do file="g.Module_Library_DB" name="g.deleteupcharge" value="BasketCharge_Delete_All_Type(g.Basket:basket_id, 'TKUPCHARGE')" />
    <mvt:do file="g.Module_Library_DB" name="g.deleteship" value="BasketCharge_Delete_All_Type(g.Basket:basket_id, 'SHIPPING')" />
    <mvt:assign name="g.amount" value="glosub(g.hardware_formatted_surcharge,'$','')" />
    <mvt:assign name="l.basket_charge:basket_id" value="g.Basket:basket_id" />
    <mvt:assign name="l.basket_charge:type" value="'SHIPPING'" />
    <mvt:assign name="l.basket_charge:descrip" value="'Shipping: UPS Ground'" />
    <mvt:assign name="l.basket_charge:amount" value="g.amount" />
    <mvt:assign name="l.basket_charge:disp_amt" value="g.amount" />
    <mvt:assign name="l.basket_charge:tax_exempt" value="0" />
    <mvt:do file="g.Module_Library_DB" name="g.insertship" value="BasketCharge_Insert( l.basket_charge )" />

&mvt:global:deleteupcharge;
&mvt:global:deleteship;
&mvt:global:insertship;

The Toolkit has a function for deleting the upcharge. I ran it right after this code, and the surcharge disappears from the basket. So at least the surcharge is present at the time this code is loading, but it doesn't get deleted using the Miva API function. So I have to think I'm doing something wrong with this code.

P.S. You are a saint for sticking with me through this. I owe you a drink at the next Miva conference!

[Bruce - PhosphorMedia]

Well, besides keeping you company, its not like i've actually helped...its a mystery, I just used

<mvt:do file="g.Module_Library_DB" name="l.success" value="BasketCharge_Delete_All_Type(g.basket:baske t_id, 'TAX')" />

Today to create B2B Tax Exemption feature on a site (OSEL)...so, i know that function works on that page.

[Leanne]

So the plot thickens. It turns out that my code does work, but doesn't display correctly until the INVC page.

Here is the current intended workflow:

OCST: Loop through the basket and and assign surcharge amounts for Product B for various shipping locations.

OSEL: Calculate correct intended combined shipping charge based on ship to state/country. Display as default shipping charge and pass to OPAY.

OPAY: Delete current SHIPPING basket charge. Insert new SHIPPING basket charge for calculated shipping rate from OSEL.


If I run through that workflow, when I examine the database, I get the correct updated basket charges as soon as OPAY loads. HOWEVER, the old charges still display on OPAY. If I complete the order, the correct updated charges display on INVC, and in the store admin. Which leads me to think that the basket display is being cached. So now the question is, how do I clear that cache?

[Bruce - PhosphorMedia]

I suspect It's not really a cache issue, but once the OPAY screen starts rendering the l.settings:charges array has already been generated. You could test the charges foreach for the correct condition then use the values you sent from OSEL to OPAY instead of the values in the array. This is they primary downside to using SMT code for what used to be done via modules, there's no way to intercept page actions to insert/manipulate data.

I believe Kent has a module that lets you use SMT like methods to do this however.

[Leanne]

That makes more sense than basket caching. For now, since I know the update is taking place, I'll just focus on modifying the display on the front end unless the store owner tries to get more complicated on me.

[Bruce - PhosphorMedia]

FYI: that's what i was proposing :)

[alphabet]

I think you should add your code to a PRE_ACTION on the OSEL page. The PRE_ACTION will update the DB and the basket:charges array will be available prior to the OPAY page rendering.

Here is a page life cycle:

1. OSEL page is parsed lined by line and rendered. Any SMT variable assignments are spawned.
2. OSEL form is submitted with g.Action, typically SHIP,PSHP, CTAX

Note: Any PRE_ACTION or POST_ACTION is run for each Action which updates the DB

3. PRE_ACTION
4. ACTION
5. POST_ACTION

6. POST request is made for g.Screen (typically OPAY)
7. OSEL variables are destroyed
8. OPAY environmental variables are spawned

9. OPAY page is parsed lined by line and rendered. Any SMT variable assignments are spawned.

Recreating display basket:charges variables while the OPAY page is rendering will then be unnecessary and easier to maintain.

There is also the issue that taxes may need to be calculated on shipping so it should be correctly calculated before the CTAX action is run. There may also be future issues that Marketing, Coupons and Price Groups that may need to be calculated before the OPAY page is rendered.

[Leanne]

That is an excellent suggestion, thank you. Worked like a charm.

[Leanne]

So, to come back to this one. Using the PREACTION works a treat on the regular checkout and we are so close to solving a major shipping pain point for my client, but I am not getting good results using Amazon checkout (now that I finally have it working on the dev site, thank you dreamingdigital). I set up a page PREACTION_AMAZON_OPAY and populated it with the following code, which is taken from the PREACTION_OPAY page and works perfectly in the regular checkout.

<mvt:do file="g.Module_Library_DB" name="g.deleteship" value="BasketCharge_Delete_All_Type(g.basket:basket_id, 'SHIPPING')" />
<mvt:assign name="g.amount" value="glosub(g.formatted_shipcharge,'$','')" />
<mvt:assign name="l.basket_charge:basket_id" value="g.basket:basket_id" />
<mvt:assign name="l.basket_charge:type" value="'SHIPPING'" />
<mvt:assign name="l.basket_charge:descrip" value="g.shipping_method_code" />
<mvt:assign name="l.basket_charge:amount" value="g.amount" />
<mvt:assign name="l.basket_charge:disp_amt" value="g.amount" />
<mvt:assign name="l.basket_charge:tax_exempt" value="0" />
<mvt:do file="g.Module_Library_DB" name="g.insertship" value="BasketCharge_Insert( l.basket_charge )" />

I can output g.amount and g.shipping_method_code successfully on AMAZON_OPAY so those variables are definitely present, but the only thing that is being output into the basket for a shipping charge is a colon.

Help?