ozpost shipping module

zekin:

Hey Rod,

I notice if the function of splitting package is turned on, the quote will become whole dollar, ie cents being chopped off.

Well spotted. It's a bug.

Not difficult to fix:

/includes/modules/shipping/ozpost.php (v2.0.9)

Line 469 curtrently reads:

  if ( MODULE_SHIPPING_OZPOST_CORE_WEIGHT == "Yes") { $quote->cost = $quote->cost * $shipping_num_boxes ; }
```It needs to read: 

if ( MODULE_SHIPPING_OZPOST_CORE_WEIGHT == "Yes") { $quote->cost = COLOR=Red[/COLOR]$quote->cost * $shipping_num_boxes ; }

Cheers
Rod

gmturner:

ahh right well it worked by taking it out, not sure if its causing any other side effects. Will add in the extra ones later.

Yeh im not sure why mine is quoting whole dollars and constantly rounding down. Pretty sure it didnt used to, will have to have a look later.

See post #1123 in this thread. I'll bet this is the problem.

Cheers
Rod

RodG:

See post #1123 in this thread. I'll bet this is the problem.

Cheers
Rod

Yep fixed, thanks.

I understand that when it only have postcode to work with it uses a guess, being the first postcode auspost suggests for that postcode. But when the customer specifically enters and different suburb why doesnt it use that?

example:

customer from Singleton NSW 2330, even when logged in with suburb entered, it estimates for Appletree Flat 2330.

The parcel is too big for Auspost so it suggests nothing for it, which is good.

But for Fastway it should suggest a orange ticket for Singleton, instead it goes off appletree flat which is a grey ticket and therefore disables it and shows no postage. Luckily the customer emailed us, otherwise may have lost the sale.

gmturner:

But when the customer specifically enters and different suburb why doesnt it use that?

It would be easier to ask 'when will this functionality be added'?, because the answer would be 'The next release following the first reported incident of it being an actual problem'

OK, now the long answer:
One of the aims of any code I develop is to keep it is simple and as foolproof as possible, so, with this in mind, the first renditions of ozpost only supported Australia Post rates, and since AP base their prices entirely on their postcodes it made no sense for the ozpost module to gather the suburb information. In fact, the modified ozpost template file was created specifically to remove the then superflious dropdown menu(s)

Of the other Couriers, the first of which was added earlier this year, some need postcode only, some need suburb only, and the remaining requires both a suburb and a postcode. Anyway, it has only been 'recently' that the 'need' for suburb names has emerged, and you are the first to report it as being an 'actual' problem rather then a theoretical problem.

This is/was important for me to know, because the act of re-introducing what are essentially 'user inputted' suburb names raises what could be bigger concerns due to suburb names not matching the 'official' names because of mis-spelling, upper/lower case differences, abbreviations ("McKoy" vs "McKoy" vs "Macoy", etc)

This also requires more input validation, and decisions on how to behave on non fatal errors, eg, user inputs postcode "1234" and Suburb "St Ives", and the 'official' suburb name is "Saint Ives", but the first official name for the postcode '1234' is 'Devils advocate' - Should the module return an error (invalid suburb) or the quote to Devils advocate? Does this need to be a user selectable option? (so much for KISS)

Anyway, as I said, that's the long answer. The short answer is probably more to your liking. :-)

Cheers
Rod

gmturner:

customer from Singleton NSW 2330, even when logged in with suburb entered, it estimates for Appletree Flat 2330.

If it looks as though this is going to be a regular occurance (ie, a regular customer that's gunna be peeved at having to contact you for quotes every time), I'd be happy to set the server so that it returns Singleton as the default suburb for 2330 rather than Appletree Flat.

Of course, this will have repurcussions for anyone @Appletree Flat but for all I know "Appletree Flat" could be nothing more than a stump in the road :-)

Cheers
Rod

I'm sure this has probably come up quite a bit, but after so many pages looking for it in this thread I gave up, so if anyone else knows the exact page, feel free to redirect me :)

My questions is related to the flat rate feature the Ozpost addon has, This addon works out better for me because it includes insurance, and most other addons I've tried for shipping insurance don't seem to work for me.

Basically quite often I get the "Flat Rate" appear as the shipping method, is this an issue with my servers ability to use cURL? or something I've missed? This is the only reason I continue to use the other Auspost addon.

Thanks for any light on this subject.

orien:

I'm sure this has probably come up quite a bit,

Actually, you are wrong. It rarely ever comes up.

orien:

Basically quite often I get the "Flat Rate" appear as the shipping method, is this an issue with my servers ability to use cURL? or something I've missed?

How often is 'quite often'? (once a year? once a week? Every quote? one quote in 50 ?

Have you found anyway to constantly replicate the problem?
Have you found anyway to constantly avoid the problem?

Could you possibly supply a URL where I can see for myself and perform a few tests?

What version of ozpost are you using? (2.0.9 is the latest)
What version zencart?

Thanks
Rod

RodG:

Actually, you are wrong. It rarely ever comes up.

How often is 'quite often'? (once a year? once a week? Every quote? one quote in 50 ?

Have you found anyway to constantly replicate the problem?
Have you found anyway to constantly avoid the problem?

Could you possibly supply a URL where I can see for myself and perform a few tests?

What version of ozpost are you using? (2.0.9 is the latest)
What version zencart?

Thanks
Rod

That's good that it's a rare issue, That leads me to believe it could possibly be server related, as 'flat rate' is designed to only come up when there are issues with client/server communication right?

The issue comes up about every maybe 4th-5th refresh/check out.

I have not been able to recreate the issue as of yet other than refreshing and having it appear randomly, no real timing to it. I came here first to see if it was a common problem or rare so I had something to go by.

I'm using The latest version of ozpost and version 1.3.9 of Zen Cart.

I currently do not have a URL to have it tested as I have uninstalled it for testing other shipping modules, I just wanted a basic idea if it was a problem only I was experiencing or others were having issues with as well. I'm so far leading to believe it's quite possibily a cURL issue with my web host.

I'm looking into alternative methods for Australia shipping and insurance however considering it's a rare issue I've been having with Ozpost, I may look into it a bit more. Thanks for the helpful info Rod.

~Orien

orien:

That's good that it's a rare issue, That leads me to believe it could possibly be server related,

Could be, but I'm not prepared to jump to this conclusion.

orien:

as 'flat rate' is designed to only come up when there are issues with client/server communication right?

Correct. (as well as if valid methods cannot be obtained for other reasons)

orien:

The issue comes up about every maybe 4th-5th refresh/check out.

I think if this were a common problem a lot more people would be screaming about it.

orien:

I have not been able to recreate the issue as of yet other than refreshing and having it appear randomly, no real timing to it.

Did you enable the debug option for any clues?

orien:

I'm using The latest version of ozpost

That's what everyone says. On the odd occasion it has even been true, but mostly it isn't.

orien:

I currently do not have a URL to have it tested

Not much I can do for you then (I sold my crystal ball when I gave up the TV/VCR repairs).

orien:

as I have uninstalled it for testing other shipping modules,

You do realise that zencart is designed so that more than one shipping module can be used at any given time, don't you?

orien:

I just wanted a basic idea if it was a problem only I was experiencing or others were having issues with as well.

But nonetherless, you assumed it was a common problem that "has probably come up quite a bit".

orien:

I'm so far leading to believe it's quite possibily a cURL issue with my web host.

Is this just another wild guess, or have you some other reason to think it would be a cURL issue?

In my experience, cURL is either enabled and working, or it isn't, the fact that 4 out of 5 times you get a valid result would suggest to me that your cURL is fine.

orien:

I'm looking into alternative methods for Australia shipping and insurance however considering it's a rare issue I've been having with Ozpost,

This forum is for ozpost support only. If looking for alternative methods you would be better served using a different forum.

orien:

I may look into it a bit more.

I think you exaggerate... "a bit more" implies that you've already looked into it... The contents of your postings would suggest that this the first step of 'looking into it' that you have actually taken.

orien:

Thanks for the helpful info Rod.

Other than 'correcting' your assumption that the problem "has probably come up quite a bit" I have said and done nothing helpful at all, and your 'thanks' is premature.. if you really want my help please avoid assumptions and exaggerations, stick with facts, and most importantly, give me something to work with, because only then can I be of any help.

Cheers
Rod

I think the trying to match the user input first and then if it cant be matched returning a error that says such may be best.. or just make it then jump to the first suggested by Auspost. That way at least it has a chance of getting it right.

gmturner:

.. or just make it then jump to the first suggested by Auspost. That way at least it has a chance of getting it right.

This tends to be the way I'm thinking... OTOH I have been looking at a few AJAX scripts that'll offer suburb name suggestions based on postcode, and they'll do this in 'real time' as needed... research indicates that this seems to be the current rage for this situation, but having never integrated AJAX with zencart before I have a bit of experimenting and learning to do (and still not enough time to do it).

Cheers
Rod

RodG:

In my experience, cURL is either enabled and working, or it isn't, the fact that 4 out of 5 times you get a valid result would suggest to me that your cURL is fine.

In my ever so humble (and very recent) experience, I could forgive someone for thinking this. I recently had an issue where cURL seemed to be installed and working fine. Although not Auspost, ozpost or any other variation, one out every 5-10 of my cURL requests would lead to my script exceeding a server time out restriction, and no amount of debugging, logging, php error reporting, catch throw or ANYTHING (that I know of) seemed to let me know what the problem was (having said this I didn't have access to some of the server log files).

Anyway, I actually suspected it was Apache timing out, and finished up working around the problem by using multi cURL functions instead, but...

I mention this because:

a) Orien - even if you think it's cURL, then think you know it's cURL, the problem might simply appear to be occurring while processing a cURL request, and in fact not be cURL at all...

b) RodG - I can understand why someone might think cURL is the problem, as at times the lack of response from PHP error reporting can simply lead us up the garden path...

Andrejs

ALiepinieks:

In my ever so humble (and very recent) experience, I could forgive someone for thinking this. I recently had an issue where cURL seemed to be installed and working fine. Although not Auspost, ozpost or any other variation, one out every 5-10 of my cURL requests would lead to my script exceeding a server time out restriction, and no amount of debugging, logging, php error reporting, catch throw or ANYTHING (that I know of) seemed to let me know what the problem was (having said this I didn't have access to some of the server log files).

Anyway, I actually suspected it was Apache timing out, and finished up working around the problem by using multi cURL functions instead, but...

I mention this because:

a) Orien - even if you think it's cURL, then think you know it's cURL, the problem might simply appear to be occurring while processing a cURL request, and in fact not be cURL at all...

b) RodG - I can understand why someone might think cURL is the problem, as at times the lack of response from PHP error reporting can simply lead us up the garden path...

Andrejs

That makes sense to me more, I'm no programmer so what I'm trying to express is just how it appears to me.

Regarding postage dimensions with Ozpost though, it states "Default ITEM dimensions (in cm). Three comma seperated values (eg 29,24,2.5 = 29cm x 24cm x 2.5cm). These are used if the dimensions of individual products are not set"

That leads me to believe I am able to change the individual product dimensions? I'm unaware of where to go for this.
I've tried searching google but perhaps was not asking the right questions.

Anyone familiar with Ozpost know where to set the individual dimensions?

Cheers.

~ Orien

gee, its been a while now, but i have a slightly older ozpost implementation where we use three fields that were added to the products table, and then another three fields added to the "edit product" admin page. honestly can't quite remember if these were added as part of the install or manually. might have to refer to rod on this one as i won't have time to look at it for a few days.

orien:

That leads me to believe I am able to change the individual product dimensions?

Correct.

orien:

I'm unaware of where to go for this.
I've tried searching google but perhaps was not asking the right questions.

Anyone familiar with Ozpost know where to set the individual dimensions?

Cheers.

~ Orien

As long as you have a valid install, the place to enter the dimensional data will appear on any of the add/edit product pages (Just below the entry for product weight). If these data fields don't appear it is because the files located under the /admin/ folder of the ozpost distribution package haven't replaced the zencart originals.

Rgds
Rod

ALiepinieks:

b) RodG - I can understand why someone might think cURL is the problem, as at times the lack of response from PHP error reporting can simply lead us up the garden path...

Sorry, but this really doesn't wash with me... it makes as much sense and is just as illogical as thinking the problem is caused by a failing switch at the border of the network, or thinking it is early warning of an imminant power supply failure on the host server, or any one of the hundreds of other things that could, in theory, produce the exact same symptoms of unspecified time out errors (and that is assuming it IS a timeout issue, as yours apparently was).

I'll stand by my original comment. cURL is either enabled and working or it isn't.

IF the problem is a timeout issue (as yours was), this has yet to be proven, and even if it is proven there is still no more reason to suspect cURL over any of the other possible suspects - in your case it was Apache timng out (not cURL), so, without wishing to beat a dead horse, thinking the issue may be 'cURL' is a wild guess without any basis of fact to support the assumption.

Cheers
Rod

perhaps you're right, cURL is either working or it isn't.

not to get argumentative, but in isolation this comment isn't really relevant though, as orien's original statement was that "perhaps it's a cURL issue with my web host" (or something like that). so while your statement about cURL is quite valid, i'm not sure it's of much help as orien wasn't actually suggesting cURL was broken in the first place.

either way, i think a little more investigation / debugging is required from orien before any fingers are pointed at any particular technology, as it's hard to see how cURL would be falling over with such a small amount of data being requested and then returned unless timeliness of the response from the server with the data is in fact the problem.

Hi Rod,

First of all, thanks for a great module. I was wondering if there is a way to offer large letters only. Basically to remove small letters as an option.

I have small thin LCD screens as a product and even though they could fit in a small letter, I don't want them packaged in a small letter as I'm afraid they will get damaged in transit. If I were to offer large letters only it would give me room to add some protective packaging, or if they were posted along with other items in a large letter the other items would serve to protect the thin LCD screens.

Thanks in advance for any help.

Nintendoparts:

I was wondering if there is a way to offer large letters only. Basically to remove small letters as an option.

Sorry, no. There is no option or method to do this.

Nintendoparts:

I have small thin LCD screens as a product and even though they could fit in a small letter, I don't want them packaged in a small letter as I'm afraid they will get damaged in transit. If I were to offer large letters only it would give me room to add some protective packaging,

What I would suggest is that you modify one of the dimensions (width or length) so that they appear a little too large for a small letter.
IOW, make the length 241mm OR the width 131mm and that'll force them into one of the 3 large letter sizes instead.

Cheers
Rod