ozpost shipping module

[RodG]

hi RodG,

Thanks for looking into FW satchel... If possible I would like A2 & A3 to work, as you said its probably use most. but the price return from FW is for A5 and A2.

Thanks to you I probably would never have known that, and it needs to be fixed, because the #1 principle of ozpost is to never underquote (given valid input data), and this is definitely going to cause under quoting.

BTW, the 500gm text thing... yes, definitely text only.. it can be corrected by editing lines 522 and 810 of /includes/modules/shipping/ozpost.php. The text must match in both places.

One more problem I have... hopefully last lolz.
When I view order details in admin. Sometime shipping want to display as images

This one is going to haunt me forever... if it is what I think it is..

Funny thing is that it does not happen all the time (most of the time though)... and when this happen we can't really tell at all what option customer has select (my clients can tell because they know that this price is for which option)

I have no clue why this is happen.

It shouldn't happen at all, at least not if you are using V2.x.x and are refering to current/new orders.

So I am not sure if this happen in coding at ozpost server side or what? If possible I would like it to display as text instead of image all the time...

This is done/performed/created on the client side ... a long time ago I thought it was 'cute' to display the icons in /admin/ as well as on the estimator page, until I discovered a few hidden problems, such as database tables not always long enough to hold the image location strings (broken images), so with the V2 series I made significant changes to the code to prevent the icons in admin, thinking that would be the end of it. Alas, data entries created before this update is/was still storing the image data, and zencart is doing its thing and still trying to display them... Well, that's what I think it is..

If this shipping info display is generate at client side can you tell me which file should i be looking at to fix this??

Unless I've really screwed up again somewhere you are probably seeing the 'damage' caused by the older code. The only way to fix it is to directly edit or remove it from the database itself.

If it is occuring with new/current orders, and you are using V2.x.x then I'm currently at a loss to explain it.

Cheers
rod

[ks_b]

Yes I am using V2.1.1 and they are current/new orders that is happening.

I did upgraded from V2.0.9

Unless I've really screwed up again somewhere you are probably seeing the 'damage' caused by the older code. The only way to fix it is to directly edit or remove it from the database itself.

Which table should i be looking at in database?

This is done/performed/created on the client side ... a long time ago I thought it was 'cute' to display the icons in /admin/ as well as on the estimator page, until I discovered a few hidden problems, such as database tables not always long enough to hold the image location strings (broken images), so with the V2 series I made significant changes to the code to prevent the icons in admin, thinking that would be the end of it. Alas, data entries created before this update is/was still storing the image data, and zencart is doing its thing and still trying to display them... Well, that's what I think it is..

If it is done on client side then which file should i be looking at...so I can check if it is up to date to latest one.

Cheers,

Kieran

[vandiermen]

You didn't need to do that... Like I said, it was a logic error on the server, which I had already fixed and was awaiting your confirmation. If you've also changed the setting at your end we'll never know if my fix worked ot not. Oh well, If still broke I'm sure someone else will report it, eventually.

Cheers
Rod

I am unsubscribing from this post now. If you would like me to help you test anything please PM me with the changes you want made and a time to do it, I will do it at the time requested and email you. or if you like I can give you access. No response needed or respond by PM.
Thanks again.

[vandiermen]

p.s.
Sorry didnt read your reply properly at first.
I turned Hide parcel rates if letter sized ? back to Yes
and the fastway was still working, so what ever you did worked :-)

Although I have put it back to No again, just to be safe; ...but its good you probably fixed this problem for other people.

[RodG]

I've just read the following from Australia Post

Aviation Security - Parcel restrictions to the United States

Please provide a link. At time of writing I can find nothing about this on the AustPost website(s)

Will the module automatically calculate this $9 surcharge and if not, is there a way to include this charge?

If true, ozpost.net will be adapted so that it provides accurate quotes.

Cheers
Rod

[RodG]

Will the module automatically calculate this $9 surcharge and if not, is there a way to include this charge?

I eventually found the relevent (official) information, and ozpost.net now includes this surcharge where relevent. (ie: Destination US, weight > 453gm)

The information I found specified this surcharge applies to Articles over 453g

Tech Note:
One would have to assume that this would include large letters, which may be up to 500gms, but as this means only a 47gm 'window' where it would apply, it may be reasonable to assume that such letters will not be subject to this surcharge, therefore, being a reasonable person, when quoting, ozpost will not apply the surcharge to any of the letter rates, it only applies it to the parcel rates.

Objections, comments or other feedback welcome.

And hopefully someone will advice me when this ridiculous money grabbing surcharge is dropped.

Cheers
Rod

[Peter Homann]

I found out about it today too. I am so upset. $9.00 per parcel. Someone is making a lot of money.

Cheers,

Peter.

[ks_b]

Hi Rod,

Have you find solution to why it showing broken images instead of text??

source file show something like this

<td align="right" class="ot-shipping-Text">  (<table border=0><tr><td nowrap><img src="includes/templates/template_default/images/icons/ozpost_fastway_logo.jpg" alt="FastWay Couriers" title=" FastWay Couriers " width="14" height="16" /> <img src="includes/templates/template_default/images/icons/oz</td>

and when I look in includes/modules/shipping/ozpost.php
line 585

$carrier = "<table border=0><tr><td nowrap>".$carrier ;

line 595

$methods[] = array('id' => "$quote->id",  'title' => "$carrier $description $estimateddays $details", 'cost' => ($cost / $aus_rate),'txtCarrier' => $txtCarrier,'txtMethod' => "$quote->description");

so seem like instead of just insert only text into the database "shipping_method" field under "order" table, it trying to insert html coding as well.

I can't find where is the actually coding that doing the inserting of the shipping_method into the database though.

I tried turning image to non in ozpost admin... and hopefully this will fix the problem for now but this also make the checkout and estimate page to show as text, and it not really good looking and more difficult for customer to read.

regards,

Kieran

[RodG]

Have you find solution to why it showing broken images instead of text??

Sorry, but no not yet (not llooked)... all being well I'll get onto it later this afternoon.

Cheers
Rod

[RodG]

Have you find solution to why it showing broken images instead of text??

It's Still a mystery.

source file show something like this
< snip >
I can't find where is the actually coding that doing the inserting of the shipping_method into the database though.

I don't know that either.. I/We don't really need to know either.

What I have found, and can now tell you is that the code that you referenced is from an intermediate stage of processing, and that the quote that ends up in the database is derived from the function quote($method = 'ID') ... this function runs from lines 123 - 151 (V2.1.1).

What happens (or should be happening, but apparently isn't always) is that for any given order two calls to the shipping module are made, the first with method=NULL, to rettrieve the list of what is avalable, the second request has the method variable set to whatever shipping method was selected.

On the first call, the ozpost module stores the data as an object *similar* but not identical to what zencart needs .. The main difference is that the ozpost object has additional information, in that it contains the graphical/icon data as well as the plain text data. This occurs in that section of code that you referenced.

On the second call, where the method variable is set, the ozpost data object is scanned for the matching method, the text data only is then retreived, and a new object meeting zencarts' requirements is then passed back as a single quote, where it gets used by the checkout page(s) and somewhere along the line inserted into the database (that's why I said knowing this isn't really important).

At the moment I have no explanation as to how/why the intermediate data is being stored in your database rather than the single quote... The *only* time the iconified format should show is where there is a list of multiple methods (IOW, when method = NULL).

That's where I'm up to with things at the moment ... I may or may not have another chance to get onto it later this evening, meanwhile perhaps it'll give you something to ponder too :-)

Cheers
rod