Hi Rod,
I'm 99.9999999% sure it was the right file as I simply FTP'd it off the server,. edited it and dumped it back... But I'll double check anyway..
Thanks,
Mike
Printable View
I think I may be also having the same issue. I noticed over the weekend that sales stopped and only yesterday (after a customer query) discovered that the postal rates are displaying the Aust Post error 'Unexpected error (no valid methods). Using AP Flat Rate.' I have not added or made any changes to the site recently. I then installed the latest Ozpost module - although my zen cart version is only 1.3.8a so it may not be compatible? On top of that I have made the changes to the module ozpost.php as Rod outlined - but there is no change.
Perhaps I should revert back to the earlier Ozpost module suited to 1.3.8 and then make the changes to the ozpost.php module as outlined?
Any thoughts would be appreciated and Rod, if you wish to see the site I will pm you with the details.
Please, everyone. DON'T do this unless I specifically ask. Generally speaking, if I need login details then whatever it is you want/expect from me is going to be a chargeable job.
When I said I needed 'specific examples', I meant to imply that they need to be something that I can verify for myself.
I acknowledge that there are probably products in your store that will provide these shipping quotes, but I'm not going to spend the time adding random quantities of random products to a shopping cart and picking destination postcodes semi-randomly *just* to replicate the figures you have provided.
Previous to what? The Ice Age? The last price increase? The last incorrect quote provided to you by the obsolete AustPost module?
I will repeat... The same as what? ozpost V1? That'll cause you a problem straight up.. As per previous reply "Not an easy task considering V2 has a lot more settings than V1 :-) "
This comment worries me for two reasons.
1. It tells me that in spite of handling fees being shown, you haven't yet managed to decide whether it is the shipping quotes that are incorrect/different or whether it is the handling fees.
2. You should not need to "play" with the handling fees to see what they do. I believe they are all clearly marked, labeled, and otherwise pretty obvious what each of them do. I acknowledge that as clear as I attempt to make it, someone, somewhere, is going to be confused about one, perhaps two of the settings, in which case a little bit of experimenting soon resolves any confusion. What I'm getting from you as that that you are confused about ALL of them, therefore you feel a need to 'play'.
Playtime is over, and I'm not going to do your work for you.
Wow, what an amazing bit of insight... not only did I tell you that already, you also re quoted it back to me before presenting it as your own conclusion.
"Also, take careful note of the way the handling charges are defined, as some of them are applied differently between the versions."
Would/Should that make a difference? Same apparent problem (I guess/think), so I would assume the same conclusions (if any) could/should be applied. I shouldn't need to give every site/user personal attention.
That was aussiemaille 's complaint too. Have you tried the same fix that worked for there?
Temporarily enable DEBUG mode to capture the error message provided by TNT (if any). Then Contact TNT for further help.
Cheers
Rod
Hi Rod,
I can now say with 100% confidence, I am editing the right file
/public_html/includes/modules/shipping/ozpost.php
And the edited version now shows (at line 338)
// Server query string //
$HOST= str_replace(" ", "+", $HOST) ;
$qu = $this->_getAPdata($SERVER, "/postage.php?fromcode=" . MODULE_SHIPPING_OZPOST_SPCODE ."&destcode=$dcode&weight=$parcelweight&height=$parcelheight&width=$parcelwidth& length=$parcellength&value=$ordervalue&flags=$flags &host=$HOST&version=$VERSION") ;
If this all looks in order, as you suggest it is, then I will set to and update to the current version, as it seems I am the odd one out for whom the fix wont work..
Thanks for all your efforts thus far..
Mike
These are the words I dread most.
Yes, you MIGHT be having the same issue as one or more people in this thread, but this thread contains reports and fixes of many different problems going back several years, statistically everyone is going to have the same problems as everyone else, all else being equal. :-)
And the latest ozpost module is version ???? (for all you know, I may have released another version just today... I *haven't* but you don't know that, just as I have no idea what you think is the latest version (which is currently V2.0.6)
All versions of ozpost are compatible all versions of zencart from 1.3.7 upwards (and possibly even earlier versions).
Rod outlined changes to ozpost v1.0.2 only!! Surely that was clear?
Did you make this change before or after you " installed the latest Ozpost module"
So what bloody version did you change? V2?
I think you should just install the latest version of ozpost (v2.0.6) and worry about any problems afterwards, assuming there ARE any problems afterwards, in which case you'll be able to report the issues back here as a 'new' complaint, because whatever issue you find isn't going to 'be 'the same issue' that may or may not have brought you here in the first place.
Cheers
Rod
This may just be a formatting issue as a result of reposting, but I see that there is a space character between "$flags &host" - If this is a 'real' space (IOW, if it is in the code itself) please try closing it "$flags&host" and trying again.
Thanks
Rod
ps. It looks like this space exists in my original post. It is NOT supposed to be there and I'm pretty confident that this is going to pose the same problem we are trying to fix <sigh>
Hey everyone,
I had similiar issue with ozpost suddenly not providing any rates and then only giving the AP Flat rate. I was using a slightly old ozpost.
I opted to upgrade to the latest Ozpost module. (I'm still using 1.38a zencart). Everything worked perfectly. Just needed to disable and then re-enable the ozpost shipping module. Everything is working a treat! Thanks Rod!
Hey Rod,
There was space as thought..
I have since removed the module and re-installed (via admin)
Its back up again (kind of).
Sometimes it's ok, and then if I adjust the qty on the cart, or change the destination, it will disappear until I click the update again...
Would I be imposing if I asked you.. (or anyone else that happens to read this) to try it and see if you can replicate it..
Use this product, (thought it wouldn't matter which)
http://w w w.nortsandones.com.au/index.php?main_page=product_info&products_id=1459
Thanks
Mike
OK, this is a new problem.
Yes, I can replicate it (on your site) consistently.
It matters to me, because even if there is only one exception to the rule in any given store you can be sure that that will be the one I'd select randomly.
As for the problem... I'm not really sure what to make of it. It consistency requires a refresh for the quotes to show (It doesn't seem to matter if it is refreshed via the update buttons, or the F5 keyboard shortcut), so it isn't caused/fixed by a change or reset of any of the input data, therefore it simply isn't being output on the first request for some reason... or maybe it just isn't getting data on the fisrt request? ... hmm, no, if it wasn't getting any data it should still output the tables and info... (Sorry, I thinking/typing aloud here).... So, it is a display problem.... hmmm, how to prove/disprove?
Please enable DEBUG, it may or may not provide a clue.
You could also try reverting the tpl_modules_shipping_estimator.php back to the zencart original
Sorry, not much else comes to mind at the moment...
Cheers
Rod
Still has me baffled.
It does however still appear to be something 'local' rather than server related as the logs suggest it is getting (and returning) valid data even when the quotes don't appear.
The debug backs this up. The 'first' request (the one that doesn't show) is where it is getting the data from the server ... the refresh is getting the data from the cache (which wouldn't even be in the cache if the first request failed).
Other than this there isn't much more I can determine from the debug output ... but that is enough to convince me client/server communications are OK...
More thinking aloud..... It is as though the module is prematurely exiting on 1st quote..... Why would it do that? A bad edit? Bad code? Surely either of these will trigger an error message somewhere?
Do your Apache/PHP logs provide any clues?
Hmm, I wonder what would happen with the display under the same condition if you have another shipping module enabled at the same time? (eg, local pickup?)... just wondering....
Cheers
Rod
Hi Rod,
This is from my FF Error console
COT("https:// w w w . nortsandones.com.au/includes/templates/norts/images/secure_site.gif", "SC2", "none");
(Forgot about this feature in FF...)
Looking at this error had me just check for something....
Hmmmmm....
My Comodo SSL logo is not showing on my site anymore..
Would that be causing an issue ???
(no.. not that the logo is missing.. just the SSL part of it..)
Here is a log from when (I assume) nothing was returned, as opposed to retuning a cached page..
[08-Jun-2010 12:03:28] PHP Warning: SimpleXMLElement::__construct() [<a href='simplexmlelement.--construct'>simplexmlelement.--construct</a>]: Entity: line 1: parser error : Start tag expected, '<' not found in /home3/mikedean/public_html/includes/modules/shipping/ozpost.php on line 347
[08-Jun-2010 12:03:28] PHP Warning: SimpleXMLElement::__construct() [<a href='simplexmlelement.--construct'>simplexmlelement.--construct</a>]: 3b in /home3/mikedean/public_html/includes/modules/shipping/ozpost.php on line 347
[08-Jun-2010 12:03:28] PHP Warning: SimpleXMLElement::__construct() [<a href='simplexmlelement.--construct'>simplexmlelement.--construct</a>]: ^ in /home3/mikedean/public_html/includes/modules/shipping/ozpost.php on line 347
[08-Jun-2010 12:03:28] PHP Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /home3/mikedean/public_html/includes/modules/shipping/ozpost.php:347
Stack trace:
#0 /home3/mikedean/public_html/includes/modules/shipping/ozpost.php(347): SimpleXMLElement->__construct('3b??<?xml versi...')
#1 /home3/mikedean/public_html/includes/classes/shipping.php(129): ozpost->quote('')
#2 /home3/mikedean/public_html/includes/modules/shipping_estimator.php(134): shipping->quote()
#3 /home3/mikedean/public_html/includes/templates/norts/templates/tpl_shopping_cart_default.php(173): require('/home3/mikedean...')
#4 /home3/mikedean/public_html/includes/templates/norts/common/tpl_main_page.php(128): require('/home3/mikedean...')
#5 /home3/mikedean/public_html/index.php(97): require('/home3/mikedean...')
#6 {main}
thrown in /home3/mikedean/public_html/includes/modules/shipping/ozpost.php on line 347
Hi Rod
An FYI for you and others. I've finally narrowed it down and have transit days displayed beyond 'quoting' shipping' i.e., displayed in subsequent checkout pages, order history and order confirmation emails.
Example - BEFORE:
Your Total
Sub-Total: $xx.xx
Australia Post (500gm Prepaid Satchel Express): $xx.xx
Goods & Services Tax: $xx.xx
Total: $xx.xx
Example - AFTER:
Your Total
Sub-Total: $xx.xx
Australia Post (500gm Prepaid Satchel Express - 1 day(s) est. transit): $xx.xx
Goods & Services Tax: $xx.xx
Total: $xx.xx
Changed code as follows:
Result:Code:// store it //
// GAM hack - 8/6/2010 - include estimated delivery days in shipping_method (of DB) for email, order history, etc)
// $methods[] = array('id' => "$quote->id", 'title' => "$carrier $description $estimateddays $details", 'cost' => ($cost / $aus_rate),'txtCarrier' => $txtCarrier,'txtMethod' => "$quote->description");
$methods[] = array('id' => "$quote->id", 'title' => "$carrier $description $estimateddays $details", 'cost' => ($cost / $aus_rate),'txtCarrier' => $txtCarrier,'txtMethod' => "$quote->description"." - ".$quote->days." day(s) est. transit");
Australia Post (500gm Prepaid Satchel Express - 1 day(s) est. transit)
Result is stored in shipping_method of zen_orders which is what is used to populate the post-checkout order information.
Blunt hack that's working for me. :) There are more elegant ways but I don't have the PHP skills to do any better at the moment.
Cheers
Greig
I guess not now that you've turned it off (Sorry about the delay, took a tea break).
Anyway, with store pickup turned on I'm now not getting any ozpost quotes. Furthermore, the client is no longer sending the version information.. in other words, it appears to have gone backwards a step, and I can't see how enabling another module would cause that. Is this also repeatable? (ie, disable local pickup and ozpost will work again, albeing not correctly). Could be another clue if it is.
Cheers
Rod
Sorry Rod..
I could tell from my admin that I was getting other visitors trying to checkout (who have since abandoned) so I reverted back to a previously saved ozpost file (prior to the changes you suggested) so that at least it throws up the default error rate (Flat Rate)
Do you need my to put the modded file back in place and debug on again ??
Thanks,
Mike
Assuming these were caused by the error we are looking for (and not some other error) let's disseminate the important bits...
The first character in an XML response should always be a "<" and we are being told that this wasn't found.
This is a 'dump' of what the XML response apparently contained... Note the "3b??" that comes immediately before the "<" ? These characters (or this representation of) do not belong, and as such the 'parser' is failing with an error.
So, the question now is where the fluck is this coming from. It isn't being sent by the server (well, not by anything that I'm aware of, and if it were the server sending, then why to your client and no one elses? (At least not identified).
.... Aha!! I've seen something like this before .... V1.0.2 ... ENABLE cURL !!!!
Cheers
Rod
Do so at your leisure. I fear that I have a few other things that I need to move onto the the rest of the night.
My gut feeling tells me that the mods specifed, along with cURL enabled may, just may take care of your troubles.
If not, then you may also be onto something with it being SSL related, but this should be pretty darn easy to test/prove/disprove .. just disable SSL for a bit and see what happens. Only takes one or two changes to the config files.
Cheers
Rod
Not wishing to dampen your enthusiasm, but this hack is going to look very messy for those that retrieve TNT quotes, because TNT don't provide an estimated transit time, they provide a pretty specific date and time, eg "by 9am 10th June" or "by 4pm 9th June", etc, etc... so the 'result' will appear something like:
"TNT (Overnight Express - by 9am 10th June day(s) est. transit)"
Also, while I'm nit picking, technically "est. transit" is incorrect anyway, because the actual number of days presented here is adjusted by the number of days delay that may have been specified, this affects the total delivery time, but the time in transit remains the same. :smile:
I can appreciate that neither of these things probably really matter to you, but if I implemented it into the code I'm sure I'll have no end of people telling me how wrong it is... I'm just getting in first :D
Cheers
Rod
Good point, and I've just signed up for TNT :P LOL, I started by simply inserting ...[days]..', which I will probably revert to now, or similar, given the TNT date/time thing. It's mainly for my admin purposes anyway and whether it states [3] or [by 9am 10th June] still works for me.
Was applicable in my case.
It is an example and something to consider. I had hoped you might be interested and code something better. :blush:
If recording the quoted transit period on the order record in the database is important to someone then this is a way to do it. At the moment, once the order is confirmed that info is gone.
In my case, I email dispatch advices out for each order and state the estimated delivery date for their information, which is useful for customers to check and coordinate if their presence is required to take receipt. The last few days I've been either guessing or looking up the Australia Post site.
Cheers
Greig
Sincere apologies Rod!Quote:
These are the words I dread most.
Yes, you MIGHT be having the same issue as one or more people in this thread, but this thread contains reports and fixes of many different problems going back several years, statistically everyone is going to have the same problems as everyone else, all else being equal. :-)
Had a heck of a day and amidst it all, I inadvertently submitted a rough and far from finished message - too much happening and too many tabs open at once I suspect! Very sorry for wasting your time with my goof up.
My problem is I am unable to obtain postal quotes. This has only happened from the 4th June. Here is an outline.
Ozpost module V.1.0.2 was installed and working fine past 6 months plus, then noticed after 4 June that postage quotes not displaying - error message displayed was 'Unexpected error (no valid methods). Using AP Flat Rate.'
So I then installed the latest version of Ozpost, V2.0.6 - but there was no change, no quote displaying just the same error message. Curl is enabled. Tried removing and reinstalling ozpost module in admin - no change.
I saw in this thread a suggestion to modify the /public_html/includes/modules/shipping/ozpost.php file, (which I edited directly in cpanel file manager) but there was no change.
The shipping module Store Pickup has been in use throughout this time and it displays in the shipping quotes without problem, although I cannot recall if it did disappear when I initially found that postage quotes weren't displaying. I have the postal quotes displaying without need to login or register on the site btw.
Have utilised the ozpost debugging tool and am getting the message, in the table of the Available Shipping Methods box: Invalid input Data [No version information]
hmmmm, i'm not too savvy with any of this, but noticed in the cpanel error log as a response to requesting a postal quote from the website:
client denied by server configuration: ..../store/includes/templates/first/images/index.php
But I don't have an index.php file in that folder? (..should i have?) I have no knowledge if this is related to the issue.
Hoping it's something simple I'm not seeing!
Cheers,
Joanne
Hi Rod,
This issue above is also now resolved.. I checked the debug logs and it smacked me in the face.. I had forgotten to enable php_curl extension in PHP 5.2.11, so of course whenever I switched form 5.3.0 back to 5.2.11, the shipping module would not load.
But it's all fixed...
Hi Rod,
On the FCKeditor thread
http://www.zen-cart.com/forum/showth...ighlight=cache
there are several reports of after installing the new OZ post version the editor has been effected, not sure why these posts were not posted here where it counts.
in my original post i mentioned version 1.38, that of course is the zencart version i am running. This is the version i installed your latest update on. This is also where i am finding the conflict with my editor.
All you need do to see what i mean is install your new OZ update on a 1.38 version of zencart with the fckeditor module installed. Then go to edit a product on the site. You just get garbled code where there was once WYSIWYG.
Someone reported this:
admin\includes\modules\product\collect_info.php
or
admin\includes\modules\update_product.php
maybe causing the conflict, could this be correct?
At the moment the OZ post latest version works fine but i have to use my desktop storemanger to update stock numbers and product descriptions which is not the best as it is very slow.
I am having FCKeditor withdrawal symptoms :wacko:
Regards Sean
OK, this problem is now 'well known' and the fix is available.
If there was no change then something went astray with the upgrade installation. There are a LOT of differences between the V1 versions and the V2 versions. You *would* have noticed them in the admin control panel, regardless of whether it was able to return quotes or not.
Even the 'error message' has changed between V1 and V2.
ozpost V2.x.x. won''t even install without cURL being enabled.
For reasons unknown, the installation that you are upgrading doesn't appear to be the same installation that you are testing with - That, or the ozpost update files aren't being placed where the should be.
Those mods relate to ozpost V1.0.2 *only*, and assuming the files being used is the same file that you modified the WILL have been a change.
I mentioned/suggested this to Mike Dean as a debugging exersize FOR A TOTALLY DIFFERENT PROBLEM.
Please, relax and think before blindly following instructions that may or may not relate to your particular situation.
This is actually a 'new' error message that was put in place only a day or so ago (as a result of identifying the problem with V1.0.2) ... The fact that this is what you are now seeing tells me that you are currently running an *unmodified* V1.0.2.
If you have performed the 1.0.2 mods as specified OR upgraded to v2.0.x then you will not see this particular error message.
I'm not familiar with the template called 'first', and there probably *shouldn't* be an index.php file in any of the /images/ directories.
I would say, probably not.
It almost certainly is - As I mentioned to someone else recently, I wasted the best part of an hour over the weekend modifying a file and not seeing the expected changes, only to realise that I was modifying a backup file rather than the one that was actually being used.
I strongly suspect that this may be a similar case with you, because working or not, if you can't see any changes in the admin panel as a result of upgrading from v1 to v2 then this is about the only possible explanation.
Cheers
Rod
Hi Rod,
i was having problems with ozpost so i installed the new version but still getting postage rates too high. I know it's usually a config problem but I've looked and can't see anything wrong. I have debugging on. (See below)
http://www.fashionamour.com.au/maxi-wrap-p-33.html -
item is 29cm x 25cm x 2.5cm 200grams. from 4563 to 4563. (Tax= GST)
Australia Post site gives me:
regular: $4.35
500g Parcel Post Satchel:$5.70
express:$8.00
Express Post 500g Satchel:$8.00
Express Post Platinum Parcel: $11.90
Debugging information
Item 1 Maxi Wrap
Attribute Item Parcel
Qty 1 Weight gms Qty 1 Weight 200gms
Dimensions 29 x 25 x 2.5 29 x 25 x 2.5
Cube 1812.5cc 1812.5cc
CubicWeight 0.453125Kgs 0.453125Kgs
Submitted: Length=29.00cm. Width=25.00cm. Height=2.50cm Weight=200.00gms NumBoxes=1
Using Cached quotes
AU,4563,25.00,2.50,29.00,200.00,31.6 Array ( [id] => ozpost [module] => [methods] => Array ( [0] => Array ( [id] => RPP [title] => 4 Days Estimated Delivery.
[cost] => 8.5 [txtCarrier] => Australia Post [txtMethod] => Regular Parcel ) [1] => Array ( [id] => REG [title] => 5 Days Estimated Delivery.
[cost] => 15.5909090909 [txtCarrier] => Australia Post [txtMethod] => Registered Parcel ) [2] => Array ( [id] => EXP [title] => 1 Days Estimated Delivery.
[cost] => 16.3636363636 [txtCarrier] => Australia Post [txtMethod] => Express Parcel ) )
I'm not sure about the others, but Newcastle is NEW as far as I can tell. I was using NEW before and getting quotes but looking for other posts about omitted quotes I noticed the above list again and realised that the prefix for Newcastle was different to what I was using. I tried NTL... NO Fastway rates were returned. NEW = good for Newcatsle as far I'm concerned.
Cheers
Greig
Hi Rod
I've been noticing omitted valid quotes from Fastway via OzPost and looking into it discovered something interesting which might identify the cause of these absent and/or erroneous Fastway quotes.
I'm located in Newcastle. Fastway abbreviation is NEW. These abbreviations are listed in Fastway Transshipment schedules (Note re my earlier post concerning abbreviation, if anyone has their transshipment schedule, look up your own suburb and you should see the correct abbreviation for your depot/region).
I thought it was strange that I wasn't getting quotes for 2000 - Sydney. Then today a customer ordered and selected Express Post for 2760 - St Marys @$35.00 cost to them. Strange I thought as St Marys is 'short haul' zone from Newcastle and would have cost the customer less than half the price for their order.
Anyway, struggling to find an answer I tried changing my Fastway zone to SYD. Voila! Accurate quotes for 2760 - St Marys. Also for 2000 - Sydney and others that I've been noticing during the week.
This discovery makes me think that it might be the Fastway server, database, etc on the Fastway server side that is the reason for these absent quotes. Most likely the same reason for many others that aren't getting expected quotes for Fastway via OzPost.
Note that I have confirmed my expected (but omitted) results via Fastway's calculator too and there are definitely inconsistent results returned via OzPost.
Hopefully this info helps and sparks realisation of some 'easy' solution. ;-)
Let me know if I can help with any testing, hacks, etc. as I'm keen to get this fixed as I'm sure it's putting some customers off when they're not getting good freight quotes for their potential order. I'm happy to contact Fastway too if you want.
Cheers
Greig
The ozpost server is simply an aggregator. It takes the data provided by the user, reformats it to the format required by the 'real' servers. It then retrieves the response from the server and reformats this reponse into the format required by zencart.
Whether what you state is true or not, it is outside of the control of ozpost.
Maybe, but it could also be a result of a previous discussed issue in regards to missing or mis-identified suburb names.
Many others? Is there another forum where this issue is being discussed that I'm not aware of?
Well, no, not really.
Firstly, I seem to have only one other recorded report of incorrect FastWay quotes, and that was from vandiermen Post# #721 in this thread, so perhaps you have something different going on.
Secondly, if changing the local FastWay zone is the 'cure' for the problem, this is also outside control of ozpost
Thirdly, although there are currently only about 15 FastWay zones available (which I could EASILY have made into a dropdown menu), I opted not to do this because new zones can be added at any time (as more people take up the franchises), which results not only in additional zones, but also the occasional changing of the codes fro some existing zones (the 'NEW' vs 'NTL' could well be an example of this, so for this reason the input field is left as a text box so that the module doesn't 'force' iny particular inputs.. In other words, changes to, or incorrect zone codes is outside of the control of the ozpost module.
Also, please be aware that the zones are used for 'base pricing' EG, A 'Blue' label in the ADL zone has a different price than the 'Blue' label in the SYD zone, which will make a delivery costs from Adelaide to Sydney different than the same items Sydney to Adelaide. (assuming such quotes were possible). With this example, if the zone was set to SYD and the quote requested from Adelaide to Sydney then no quote will be provided because the SYD franchise won't do an Adelaide pickup.
Such 'decisions' are made by the FastWay server and not the ozpost module. Therefore this can't be 'fixed' either.
In summary, the only 'problem' that can conceivably be 'fixed' by the ozpost module is the one reported by vandiermen Post# #721 , which affects local/shorthaul delivery quotes only, and the reason for this is because FastWay uses suburb names rather than just the postcodes, and the suburb names aren't readily available/determinable by zencart, and therefore not available to ozpost either.
There *are* ways that this can be taken care of, but nothing that can easily be performed by the shipping module alone - it will require other changes and additions to the zencart core code so that the source/destination suburbs are 'known' before the quotes are requested.
I'd be interested in having your thoughts on how to best incorporate suburb names when requesting shipping quotes, as that will take care of the local/shorthaul delivery problems, but as far as I can see, everything else is completely outside of the realms of the ozpost module itself, which is really acting as nothing more than a realy/aggregator. Garbage in, Garbage out.
Cheers
Rod
I've set handling fees to zero while I'm trying to work this out.
Handling Fee - Letters
0
Handling Fee - Regular parcels
0
Handling Fee - Overseas parcels
0
Handling Fee - Registered and/or Insured parcels & letters
0
Handling Fee - Express parcels
0
Handling Fee - Prepaid Satchels
0
Handling Fee - Prepaid Satchels - Express
0
Handling Fee - COD
0
Handling Fee - ECI Documents
0
Handling Fee - ECI Merchandise
0
Handling Fee - TNT Merchandise
0
Handling Fee - FastWay Labels
0
Handling Fee - FastWay Satchels
0.00
Hide Handling Fees?
No
Cost on Error
25.00,99.99
Error cost Type
Flat Rate
Default ITEM Dimensions
29,25,2.5
Parcel Weight format
gms
Tare percent.
0
Icons type
jpg
Postage Delay (days).
0
Sort order of display.
0
Tax Class
GST
If you did an upgrade from v2.0.5 to v2.0.6 then you probably neglected to perform the remove/install procedure (I'm making this claim based on 'missing' options from what I assume was a cat/paste of the ozpost settings).
If that doesn't cure the problem then you probably have something amiss with either your currency or tax settings.
Cheers
rod
Thanks Rod, I didn't do an uninstall. I'll try that.
Cheers.
Yes, I understand that. I simply thought that knowing the reason for an issue would be helpful for you and others when addressing issues that users may have. I will be contacting Fastway to see if they can shed any light on the matter.
I'm thinking there are either different servers or scripts or such used by the Fastway web based calculator to that/those used by OzPost and other e-store quoting tools.
I tested that, or so I thought, using logged in account details with exact suburb names. The SYD test ruled this out for me with expected quotes being returned for postcodes with multiple suburbs.
Sorry, that wasn't a thought out or founded comment. Perusing this forum lately I thought I noticed a few users describing the same symptoms.
I have been able to identify the cause and/or reason for all mis-quotes I've experienced so far with the exception of the omitted Fastway services for some destinations.
Not a cure at all, simply highlighting a difference and pointing to a possibly source of the problem.
Agreed, not my point nor a request.
It is interesting though that the correct abbreviation for Newcastle transhipment quotes via OzPost is NEW, and this is the same for their printed transshipment schedule, but Fastway's calculator pages and other references for Newcastle is NTL.
Possibly they are in the midst of migrating and there is some confusion there. Maybe the issue I'm seeing is only applicable to Newcastle based quotes.
Yes, I understand that.
I'd wondering whether there might be another server or address for the Fastway lookups? If Fastway have upgraded or such, then maybe there's another address to point to. If you could provide some details on that I will look into it with Fastway.
I'm very willing to assist with the suburb/postcode issue as soon as I've addressed some of these other things that are important to me and my online store immediately. Selfish I know. ;) I think I'm so close now except for this omitted fastway options thing. :frusty:
Also, sorry I haven't yet provided the code hacks I've done for item stacking in parcels. I keep wanting to enhance it and then not getting around to doing the 'clean up' I wanted to do before sending it to you. FYI, it also now re-orientating items by length or width for 'best fit' in the max parcel area.
Cheers
Greig
Hi everyone,
Just thought i would share, i have been testing zencart locally with the ozpost module added and I have experienced a similar scenario that GAM described.
When i had the fastway location set as CBR i didn't receive expected quotes when shipping to SYD.
i had a 10x10x10 200g item.
with a qty of 4 (10x10x40 880g) sending to CBR i get a fastway satchel and label quote, if i send to SYD i only get a satchel quote.
with a qty of 5 (10x10x50 1100g) sending to CBR i get a fastway label quote, if i send it to SYD i would not get a fastway quote.
i changed the fastway location to SYD it appeared to fix the issue.
with a qty of 4 (10x10x40 880g) sending to SYD or CBR i get a fastway satchel and label quote.
with a qty of 5 (10x10x50 1100g) sending to SYD or CBR i get a fastway label quote.
i double checked sending from CBR to SYD using the fastway website i got the same results as placing SYD instead of CBR in the ozpost field.
i had Use Core Weight set to Yes and Restrain Dimensions set to Yes.
When i had Core Weight set to No it came back with 44 satchels, but having Restrain Dimensions set to No didn't effect the outcome.
I had debug turned on and for some reason ozpost just doesn't get any information from the fastway server about the label when shipping to SYD and the store is set to CBR.
Thanks to Rod and the zen cart team for making a great product that an idiot can teach himself to use!!!:clap:
Cheers
Tim
Just in the last couple of orders I've had error messages with Aus Post. Doesn't seem to matter what the goods are - I've checked that I've got correct weights and measures for the orders. I think I've set the flat rate. it hasn't bothered me so far as it's been close to the correct amount.
I have had the following :
Aussie Post ( Unexpected error (no valid methods). Using AP Flat Rate.): $4.00
Basically I'm wondering if it's me (my site) or something that's happened to Australia Post recently? Someone told me that there was an imminent rate rise but I'd presumed that the module would cater for this also.
has anyone else experienced this? or am I a lone voice in the wilderness........
I realise that this thread contains a lot of messages, but please read the last 4 or 5 days of postings.
Get back to me if these don't solve or relate to your problem.
The prices officially rise on 28th June.
From your perspective, the 'module' will take care of this. From my perspective I'll be updating the server with the new prices over the weekend prior to the official change.
Could be either. There has been a lot of activity around here lately due to a bug in some old code that has just been discovered, but this is all neatly identified and documented now, with a couple of possible solutions.
I/we don't know if you have a new/unrelated problem.
Cheers
Rod
This may seem like a really dumb question, but how do you manage to get the ozpost module to send to either SYD or CBR ? (where the heck is CBR anyway?).
Firstly, please forgive me, but I'm not even going to try to understand your findings, partly because it seems very confusing, and partly because the issue is almost certainly out of control of what can be done with the ozpost module in regards to a resolution (Unless what GAM suggests about different backend servers being utilised is correct, and if so, the 'other' server needs to be accessible via scripts, "magic94" doesn't appear that way .. in fact I understand 'magic' calls 'sctipts'. I digress.)
What I was going to say was the 3char code you enter into the ozpost settings is, to the best of my knoweldge, used to determine the $rates, as these are set according to the franchise. Each franchise has its own area of coverage, so as a general rule you cannot pick and choose which franchise will service your particular area. You may be able to 'fool' the system into providing a quote where one wouldn't normally be provided, but I'll never be convinced that that would be a wise thing to do.
For most people this is almost always the WRONG thing to do.
Sorry my friend, but this cannot be. The only way you'll ever get multiple satchels/parcels is if the "Use Core Weight" is set to "YES".
However, this is new/untested code, so you may have found a bug. Can you still set to 'no' and be quoted for 44 satchels ? (do you have a URL for me to see?).
Although there is no direct connection between the "Use Core Weight" setting and the "Restrain Dimensions" setting, there is an INDIRECT connection in that the use core weight will divide the shopping cart by weight, creating multiple parcels, and as a consequence of this the total dimension of all items in the cart is also divided by the number of parcels, which will pretty much always ensure that the dimesions of any given parcel won't exceed the carrier limitations anyway, therefore the Restrain Dimensions code never comes into play.
To both myself, and 'ozpost', a comment like "shipping to SYD" is meaningless. If you meant to say "shipping to postcode 2000" then please state it as such.
What code you set as your local franchise is also meaningless to both myself and the module ... ok, I know ADL means Adelaide, and SYD means Sydney (I really dont have a clue about CBR though, and not interested enough to look it up). To me, it really isn't important, and to the module it isn't important - The data is simply passed on to the fastway server in the required format.
If you find the fastway publicised codes are different than what works in reality (could be the case) then this hasn't been made clear and the oddity would best be taken up with the webadmin at FastWay (who will probably appreciate being informed of the oversight).
LOL.... Nah, I've met idiots before, and without exception they appear to lack the ability to teach themselves anything, unless it is wrong.
Cheers
Rod
Hi Rod
Further to the omitted Fastway Labels issue.
After a fair amount of testing I've determined that the issue is limited to Shorthaul (LIME/PINK) labels only. I get no shorthaul label quotes for shorthaul destinations/zones. This is likely to be the same for CanFish too as most if not all Sydney destinations would be 'Shorthaul' from CBR (Canberra) as it is from NEW (Newcastle). Changing my location to other shorthaul locations (Wollongong, Central Coast, etc) to Sydney and I get the same result - No shorthaul labels quotes.
Rod, perchance shorthaul labels have a different code or something that is not being captured or catered for?
I haven't tried to contact Fastway yet, but if this new information doesn't jiggle a solution then I will endeavour to do so on Monday.
For information - Fastway franchise codes copied from source code of http://www.fastway.com.au/1PriceServiceCalc.html:
<option value="ADL">Adelaide </option>
<option value="ALB">Albury </option>
<option value="BEN">Bendigo </option>
<option value="BRI">Brisbane </option>
<option value="CNS">Cairns </option>
<option value="CBR">Canberra </option>
<option value="CAP">Capricorn Coast </option>
<option value="CCT">Central Coast </option>
<option value="CFS">Coffs Harbour </option>
<option value="GEE">Geelong </option>
<option value="GLD">Gold Coast </option>
<option value="TAS">Hobart </option>
<option value="LAU">Launceston </option>
<option value="MKY">Mackay </option>
<option value="MEL">Melbourne </option>
<option value="NEW">Newcastle </option>
<option value="NTH">Northern Rivers </option>
<option value="PER">Perth </option>
<option value="PQQ">Port Macquarie </option>
<option value="SUN">Sunshine Coast </option>
<option value="SYD">Sydney </option>
<option value="TOO">Toowoomba </option>
<option value="TVL">Townsville </option>
<option value="BDB">Wide Bay </option>
<option value="WOL">Wollongong </option>
Cheers
Greig
Can anyone else confirm whether they are getting Fastway SHORTHAUL label quotes from the OzPost module?
Cheers
Greig
I've just tested MEL (Melbourne franchise) to 3550 - Bendigo and GEL (Geelong franchise) to 3550 - Bendigo, which are both shorthaul according to Fastway website and same result - No Fastway Label (i.e., shorthaul label) quote, only Fastway Satchel.
So I'm confident everyone would be experiencing the same omission.
Cheers
Greig
OK, I've read the numerous posts from the last half a dozen days. I understand the problem a little more now. Sorry for that, I should have read more before posting my query. It's just a bit daunting when you have 80+pages to read, just where my problem might be solved. :lookaroun
I can see I need to update or alter some files.
I'm not ready (as in just don't have the time) to update to the new version of Zen - hoping to get to it over next couple of weeks.
In the mean time, I'm presuming that the latest version of ozpost is only compatible with the latest Zencart as this is the only version mentioned on the download point.
I noticed further down the page there is a download for 1.3.7 - 1.3.9+ and am wondering if I should be doing that one instead for now until I get the new Zencart update?
Thanks Rod, :clap:
Will download the very latest then.
Cheers, and thanks for doing such a great job.
I have just installed this module. I now have a warning message:
Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in /home/sarahrot/public_html/store/includes/modules/shipping/ozpost.php on line 744
I have enabled regular and express satchel for Australia and air mail and express for international, yet when I test this through purchasing a product none of these are visible, only the previously set free shipping.
Does anyone know what might be the problem?
I've just updated it to the new version and am still having problems.
I think I'd better go Back to start all over in case I've missed something.
:oops:
I uninstalled old version uploaded new version then installed new version.
On the top of the description there is the line
MODULE_SHIPPING_OZPOST_TEXT_DESCRIPTION
does this mean I've left out a file somehow?
Yes... the CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set,and this option is trying to be activated by line #744 of the ozpost.php file.
I assume that you are next going to be asking for a solution to the problem. There are in fact two solutions.
1. Unset your open_basedir or
2. Comment out (or delete) line 744 of the ozpost.php file (This is safe to do at the moment, but it may cause a problem in the future if the server ever needs to have a redirect in place.)
Sorry, I cannot tell you the best way to unset the open_basedir on your server.
Cheers
Rod
thanks Rod - I figured that was the case:frusty:Quote:
It means you've screwed something up.
well I re did it all, and now I am getting a correct looking info panel in admin.
So, I did a quick test and although I now get to the quote screen I'm faced with the following
http://i31.photobucket.com/albums/c3...les/ozpost.jpg
which makes it hard to work out what is being offered.
Have checked and the icons are in the correct folder, where to I look next please?
I've just looked at it again using another browser (Firefox)and all is OK, so I'm thinking it's me using Google Chrome which was the problem :dontgetit
Don't think I'll spend much more time on it at the moment, seeing that it seems to be ok.
Rod
I've just upgraded to v 2.0.6 but on testing its only producing Flat Rate estimates.
In the attached screenshot of the table generated by the debugger I see two columns; one devoted to Item, the other devoted to Parcel info.
The Item column is missing the weight, whereas the parcel column has it so I'm guessing the error that prevents the estimate from displaying is down to this missing weight. Trouble is, I can't find the offending location to update. I've checked the weight on each product page and each is correctly filled in. Where do I add an item weight if its not the product page?
Correct.
Sorry, I'm confused and not sure exactly what you are asking. What do you mean by "each product page" and what do you consider to be 'correctly filled in'?
The only place to add/edit product weights is via the /admin/catalog/categoriesProducts editor, where it has always been. <extremely puzzled look>
If I assume that you are referring to the correct page (and I really can't imagine where you are looking if not), then what you consider to be 'correctly filled' simply cannot be the case. Given your example, the total parcel weight sent to the server for quoting weight a mere 0.28gm, (clearly shown on your screen capture)
A single sheet of A4 paper weights ~5gm. What are you mailing? A postage stamp without the envelope?
Cheers
Rod
Hi Rod,
I'm following this message up so that you know how it all went. The TNT stuff was a pain to sort out as you had indicated.
I can confirm here that the 'Rated Transit Times' service requires the acount to be created at 'TNT Online' and that it requires a phone call to the CIT Helpdesk on 1300 851 131 for the service be enabled for the account.
That should help others get it happening.
Kind regards,
Rob
EXCELLENT. I can't thank you enough for providing this information.
You'd have thought I'd have already known this, but as I was the 'first' and didn't have access to software that I knew 'worked' I (and another helpful user) went around in a number of circles with both the code and various folks at TNT before we struck the 'winning combination', by then neither of us were at all sure even what account it was that was needed (I'm sure that as a result of our trials we now have TNT accounts that things that aren't even used).
You probably wouldn't believe how much I was hoping that someone like you would come along with such definitive details. :-)
It is SURE to help others get it working. Again, thanks.
Cheers
Rod
Good on ya Rod. You hit the mail on the head!
I had indeed specified my product weights in gms and the ozpost in kgs. Too easy to do when the measurement system isn't mentioned anywhere near where the values are entered.
BTW I ship those pesky charts in tubes (you know, multiple products in one tube, multiple tubes in one delivery) as well as big flatpacks that really screw your packaging algorithm around
My zencart is telling me that there is a new ozpost shipping module available. (v2.0.6)
where can i find this download.
can someone please help me,
thanks
The usual place: Free Software and Add-ons/Shipping Modules/ozpost
or, more directly: http://www.zen-cart.com/index.php?ma...oducts_id=1286
I just found your module but am getting an error when I try to enable it.
1054 Unknown column 'NONE' in 'field list'
in:
[insert into configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added) VALUES ('Dispatch Postcode', 'MODULE_SHIPPING_OZPOST_SPCODE', NONE, 'Dispatch Postcode?', '6', '2', now())]
Hi Rod,
We've been running v1.0.2 for about 12 months with no problems, it's a great module. I've just noticed that for about the past week our orders specifying Australia Post for delivery have been reverting to the Flat Rate on Error price. Is there a server down somewhere or should we be upgrading to v2.0.6?
Thanks,
Warren
Hi Rod,
I've been using the new ozpost module, with fastway activated. Seem to be working well, however it has charged a customer in WA an incorrect price. Going to PO 6713. It quoted $6.90. Should of been closer to $40. order would of been around 7-8kg.
I went to the fastway website, and plugged in Melbourne to 6713 with 7kg, and price came up as $52.80.
Hi Rod
I've noticed the first shorthaul quotes as of around Mon. 14/6/2010. Yippee!!! :D I redid some of my earlier tests and can confirm that appropriate Fastway Shorthaul quotes are now provided.
Rod, can you confirm whether you changed something in light of the new info or did something miraculous occur? :blush:
Cheers
Greig
First question... What version of ozpost are you using? (please let me know, even though the following suggestion will probably fix this issue for you).
Suggestion for probable fix:
Go to your configuration settings -> shipping/packaging and set your Postal Code.
Then try installing the ozpost module again.
The error you are getting *shouldn't* be happening, because if the postcode isn't set the module should be using a default value of "9999" .. for some reason it appears that you don't have a valid postcode set, and the module isn't correctly detecting this fact, so it is trying to set a value of 'NONE' in a place where NONE isn't allowed.
This was a 'bug' that I noticed in the code a few versions back, which is why I added code to set a default value if the postcode wasn't already set, which is why I'm interested in know what version you are using.. If the current version then I need to take another look at the code, if an older version then I don't need to worry about it any longer.
Cheers
Rod
Yes, you should upgrade, but if you find this impractical you can make the following code changes to your V1.0.2
---------------------------------------------------------
ozpost v1.0.2 - line 338
Add:
Then change this:Code:$HOST= str_replace(" ", "+", $HOST) ;
;Code:$qu = $this->_getAPdata($SERVER, "/postage.php?fromcode=" . MODULE_SHIPPING_OZPOST_SPCODE ."&destcode=$dcode&weight=$parcelweight&height=$parcelheight&width=$parcelwidth&length=$parcellength&value=$ordervalue&flags=$flags&$method=$method&host=$HOST&version=$VERSION")
To:
CheersCode:$qu = $this->_getAPdata($SERVER, "/postage.php?fromcode=" . MODULE_SHIPPING_OZPOST_SPCODE ."&destcode=$dcode&weight=$parcelweight&height=$parcelheight&width=$parcelwidth&length=$parcellength&value=$ordervalue&flags=$flags&host=$HOST&version=$VERSION") ;
Rod
Hi
I am hoping someone can help me please.
I am totally stumped.
I have a fresh install of Zencart (latest version).
The lastest ozpost shipping module installed.
I went to do a test order but i get the message "not shipping to this destination at this time" (or something like that)....
I realised then I didn't have the Fixed Cost prices in - it was blank.
So I fixed this and now I come up with a "flat rate" of $7.00.
I do not have any other shipping module installed.
I do not have free shipping products etc.
I have the weight and dimensions in the products.
I have re-installed the ozpost module etc but I still come up with the same.
PLEASE help.
Kind Regards Casey
Hi
It is here.
Kind Regards Casey
You (appear) have everything set up right..
It's the weight of each item (or lack of it) that appears to be the issue.
If I add one chart, I get no rates, but if I add 10 charts I get rates.
What measurement are you using in the module ?
Check what weight you are using as a default, and check what weight you are entering for each item.
Also check the dimensions..
When I add 1 chart I get dimensions of 32.4x22.9x.01 so that's a width of 1mm ?? Obviously the width of the paper..! I'd make that 10mm...
I have checked and double checked all this. This is the strange this.
The weight is in gms in Ozpost module and it was changed in the english file from lbs.
I have the same measurements I used from my previous install (and that worked which were as follows in this order including weight:
113
0.01
32.40
22.90)
If 1 qty is selected, it should be a letter price.
I would be happy to be seeing that :yes: :frusty:
Kind Regards Casey
What you have you got this option in the module set to ?
Hide parcel rates if letter sized ?
Have you had any luck ?
I just tried changing one of my products to match your dimensions and it would NOT work, so it's not the module (at least I would have thought not..)
I just changed the order order of the dimensions to ;
Weight : 113
Height : .01
Length : 22.9
Width : 32.4
Admin settings are gms
With this and 1 of the item in the cart, I get Large Letter (0-125gms) rate returned;
With 4 in the cart I get Large Letter (250-500gms) rate returned
Any more and I get standard shipping rates..
Does this sound correct ?
Thanks, I had them around the wrong way - the length and the height.
Kind Regards Casey
That shouldn't make any difference. Regardless of what the 'labels' indicate, the ozpost module always treats dimensions in the following way:
The longest dimension is always considered to be the 'length'
The shortest dimension is always considered to be the 'height'
The remaining dimension is always considered to be the 'width'
If changing the dimensions around seemed to have cured your problem, it would be because something else got changed at the same time.
Cheers
Rod
This is Impossible for me to say (else I probably would have suggested it)
I guess one possibility is that your original dimensions weren't what you thought they were... eg ".O1" or ",01" (comma zero one). instead of ".01".
Feel free to make your own guesses 'cos that is all I'm doing.
Cheers
Rod
The new Ozpost module is interesting, especially with the ability to split into multiple parcels. I cannot get the weights to all by in sync. All items are in Kilograms, and Ozpost is configured for Kilograms. The Debug shows that the Cart weight 18000 grams which is correct. But the size / weight debug line shows 18.00 grams ! Is there another configuration entry that I have not set.
cheers
For the record, this isn't an 'ability' that the ozpost module has. It is in fact the default zencart behaviour.
It is probably best not to try (at least not without knowing a little about the underlying code).
All items are in Kilograms, and Ozpost is configured for Kilograms. The Debug shows that the Cart weight 18000 grams which is correct. But the size / weight debug line shows 18.00 grams !
[/QUOTE]
Alas, the image you attached is too small for me to read the details, so I'm pretty much guessing here ...
The debug shows several things, among them, how the weights and dimensions are being processed by the ozpost module itself. As well is this it should be showing the weights and dimesions being sent to the server for costing, and these figures will differ from the earlier figures if the maximum dimensions have been restrained or if the split by weight has been enabled.
It is unclear from your posting as to whether you actually have a problem, or simply wondering why the numbers displayed in debug don't 'sync' .
Cheers
Rod
Many thanks indeed Rod. Much better now. cheers
I was wondering if you might be able to help me RodG
I am using version Zen Cart v1.3.8a and Ozpost version V2.0.6 on a new site (currently in test, not production).
It is an Australian site but the business rules are that no orders to be taken within Australia as that is covered by their retailers. I have disabled (unchecked) the Australian shipping options.
My problem is that the shipping calculator defaults to flat rate BUT only when logged in as a test customer (US). If I use the shipping calculator with a guest cart (using same country - US) there is no problem at all.
I have followed the setup instructions but am wondering if I have missed something, I don't believe it is a bug in Ozpost but perhaps something that has been overlooked in the setup of customers/zones???
Thanks in advance.
hhmmmm..... ok....
I cannot explain this behaviour. Logged in or not, you should get the exact same results for the exact same destination. There must be more to this that we aren't seeing.
Perhaps.... even probably. I'm not exactly sure how or why though as the ozpost module doesn't use zones, well, at least not in the usual zencart way.
The ozpost module only 'knows' two 'zones' - Australia and the rest of the world. It determines which of these to use based on the destination country code (AU).
The fact that you are getting different results between a logged in user and a guest user would suggest that they are using a different country code. This is particularly the case with a guest user where the module doesn't have any clue where the guest is coming from (this is why the ozpost distribution files contain a modiifed shipping template file in order to force destination before a quote is provided.
Other than this, there really isn't much I can tell you - it is a mystery to me too.
Cheers
Rod
Hey Rod..
I hope that's adds a little humor to your day ??
I was doing a compare on V2.05 and V2.06 and found this little gem..
OK, now we have a 'real world' package made lets see if the user requires splotting by weight
Can you please enlighten me and advise what splotting is :D:D:D:D
Thanks,
Mike
Thanks for your reply Rod :-)
So, focusing on the logged in user for now, the shipping calculator defaults to flat rate when logged in as a test customer...could you please advise under what circumstances that it would do this?
I am supposing that this is the default return when there is an error.
Is there a list of areas that I could check to see if they are set up correctly?
Thanks in advance.
OK, so some further information here.
When logged in as a user, the module will work as long as there are no dimensions set on the individual products. If I set the dimensions, then place an order for 10 of that item, it aggregates the dimensions ie product is 25cm x 10cm x 2cm it makes the parcel 250cm long, and therefore invokes the error.
Is there a way to get around that?
Thanks!
The flat/static rates are used when no other valid methods are found.
Yes, this would be one condition (assuming it is an error getting a response from the server).
Another reason is if the responses received from the server are all excluded by the many user methods.
I'm not sure what you mean by "list of areas", but the way to debug the problem is to first enable the debug option :-)
As well as filling the screen with a lot of junk, this also bypasses any user filters and will display *all* of the methods returned by the server.
The server itself will provide quotes for AU destinations OR Overseas destinations.. never both at the same time.
If the server does return suitable quotes, but they don't show when NOT in 'debug' mode, it means that particular method has apparently been disabled.
If the server doesn't return suitable quotes in debug mode it should return some kind of error message explaining why 1 or more of the methods have failed.
Hope this helps?