ozpost shipping module

Mike_Dean:

I'm fully aware of what IceTV is, and also fully aware that there are other free services that offer the very same information that IceTV indeed charges you for.

They also offer that little 'extra' that others don't... Something I'm quite happy to pay for, and frankly, I wouldn't have the balls to suggest to them that they are asking me to pay for something I can get for free.

Mike_Dean:

Not sure where I have ever given any impression that I understood it merely as a relay agent or gateway to external information..

My apologies, I wasn't thinking of you specifically, but that IS the general impression I seem to be getting from a number of peoples' comments.

Mike_Dean:

I know too well what you have done in order to provide this service, as you would know too well the assistance you have provided me, AND my constant show of appreciation. No, not in the monetary sense, but have you ever suggested it in your signature ?

Well, yes, I have actually, also in the 'credits.txt' file. It is/was only recently (the last release or so) where I dropped this.

Mike_Dean:

As I also CLEARLY stated in my last response, I have no objection to paying a fee of sorts, I was merely expressing what I'm sure a lot of others have muttered to their keyboards and not bothered to press the keys.!

Sorry, I really didn't mean to upset you, but yes, I know you are only expressing what many others must be feeling. This is why I'm only expecting a 2% conversion rate. 99% of users will agree with all you have stated, of those, only 1% will put thier thoughts in writing, the other 98% will say nothing and go on to use alternative methods. .

Mike_Dean:

Lets call a spade a spade here Rod, your pretty good at handing out the insults tooo.. some I have felt were totally justified, but others.. well..

Granted, I give you that, but in my defence, I would suggest those times when you probably felt they weren't justified it is because you had only seen a part of the 'story'.

OK, so I may occasionally have had a bad day and been oversensitive to some comments too... I'm only human. (sometimes)

Mike_Dean:

Your trying to read too much between the lines of what I and or others are saying...

Possibly.

Mike_Dean:

And as a suggestion, it is these 'behind the scenes' services that are provided that need to be highlighted when setting the rates.

The telephone company, Electric company and water company don't need to highlight the 'behind the scenes' services whrn they set their rates. Manufactiring companies don't need to highlight all of their production costs when they set their rates, so although I agree in principle that this could be a good idea for setting MY rates, the onus is really on the end user to see the value of the service, or not, whichever the case may be,

Mike_Dean:

People want to know exactly what they are getting for their money. People don't part with money on my store unless they know exactly what they are getting, and I, like a lot of people are the same.

If you haven't already done so, please visit http://ozpost.net. It's not much, but I think it gives a pretty good idea what people will be getting for their money. (If you have any other suggestions for this 'site' I would really appreciate your input).

What isn't/hasn't been mentioned yet is that one of the major problems with using the ozpost.vcsweb.com server or the 'official' Australia Post server (drc.edeliver.com.au) is that neither has any form of redunancy or backup, which really isn't a good situation for ANY store to be placed in - Ergo, we've registered and set up this completely new/independant server so that if one server goes down (as rare as it is) the other should still be fully functional.

Mike_Dean:

Rod, I (and perhaps others) fully appreciate your position and do not for a minute take it for granted as my god given right to have this service for free.

Mike, if every (or even most) user had this attitude I probably wouldn't been as burned out, frustrated, and continuing what appears(ed) to be a moslty thankless task as I am, and perhaps it wouldn't be veiwing it as 'work' for which I need compensation for - It would actually be a pleasure (not that it hasn't been). I've really enjoyed seeing people use this module and helping them with problems, but Alas, this isn't the case ... most people aren't like you. You may have written what many are thinking, but I can assure you, you will be in the minority when it comes to the crunch.

Mike_Dean:

Again I will state that I have not objection to a fee of sorts, or your need to impose one.

As I said, that will place you in the 2% minority - even though you are speaking for the majority.

Mike_Dean:

But you also need to realize that some of us are in the exact same position as you in regards to financial situations.

Perhaps not in exactly the same position. (Not really wanting to go into personal issues, but for the last 4years I've been in legal battles with my 5 siblings for the right to keep or live in my own home of 30years). Even if/when I win the case I'm going to be pretty much bankrupt and homeless as a result of the legal fees).

Mike_Dean:

So yes, any additional fee, regardless of the amount, is going to cause those with little turnover to question it, where as those with larger stores or larger turnovers, probably would not blink an eye..

This is true, a couple of the larger stores have already opted for the 12 and 36 month option, and while I can see that the smaller stores may question the value, it is after all, less than a cup of coffee per week, and if this is enough to make or break a store then perhaps those people should consider the viablity of their stores in the first place.
Chances are such stores are already running at a loss, so if my asking fee is enough to bring about the demise of their store then perhaps in the longer term I'm actually doing these people a favour?

Mike_Dean:

Lastly.. I will ante up.. (It was never an issue) as I need the service,

No, really Mike, you don't NEED the service at all, I'm sure you'll get by quite well without it. You simply appreciate the service and what it can provide you. At least I hope that is your reasoning.

Mike_Dean:

but I do feel better for my at least expression my piece..

Me too :-)

Cheers
Rod

Hi Rod

I found the line in the tpl_modules_shipping_estimator.php and deleted it. I could not find the line in the ozpost.php. However I am still getting the error.
I know you are under siege at the moment and the error does not seem to be fatal. So there is no rush. Just when you get a chance.

Rob

Hi Rod

I think it's fixed. I uninstalled the module then copied ALL the 2.0.8 files over and it seems OK.

Oops: I tell a lie, it's still doing it??

Rob

RodG:

Yeah, that's what they all say...

In four years I've had four donations. Where was yours?

Pfft. I haven't donated because I don't use the ozpost module. lol

FYI I donate to ZenCart monthly, and various other open source solution providers.

So, where are you going to stand in this regard now? Are you going to be like the (expected) 98% of users that will be saying "So long, and thanks for all the fish", or do you plan to make a "voluntary donation" to help keep the service running a little while longer? (For each $5 or $10 you donate I will add an extra month to your server access). :-)

I'm on this thread because I was going to start using ozpost, but now in light of all this, I'm not.

Hope it goes well for you. A lot of people are depending on it.
Reuben

Rod, you say you're getting your Fastway quotes from http://www.fastway.com.au/1PriceServiceCalc.html

I always check them there too.

I'm assuming you are entering them manually, so here's a typical case:

Customer in Melb. wants a parcel sent under 5kgs from us in Sydney.

Fastway quote(s) online on their website are:

Can you tell us what logic you are using to get the figure of $11.00?

I realise there is a range of label prices - it says so - but I would be paying $12.05 not being a frequent user.

Maybe this is where my idea of a sliding percentage scale (per shipper) might actually work to make the quotes spot on???

robbie269:

Hi Rod

I think it's fixed. I uninstalled the module then copied ALL the 2.0.8 files over and it seems OK.

Oops: I tell a lie, it's still doing it??

Rob

Try deleting all/any tpl_modules_shipping_estimator.php files that you have laying around... all except the zencart original of course.

If that solves the problem then re-install the copy from the V2.0.8 distribution. I have double checked this and it already has the errant line of code commented out.

If it doesn't solve the problem we are going to have to dig a lot deeper.

Cheers
Rod

tpeck:

Rod, you say you're getting your Fastway quotes from http://www.fastway.com.au/1PriceServiceCalc.html

Correct.

tpeck:

I'm assuming you are entering them manually,

Incorrect.

tpeck:

so here's a typical case:
Customer in Melb. wants a parcel sent under 5kgs from us in Sydney.

Fastway quote(s) online on their website are:

Can you tell us what logic you are using to get the figure of $11.00?

Using the axample provided, the module should be returning a result of $12.05 (unless you have the Frequent user flag set, in which case it should return $9.52

tpeck:

I realise there is a range of label prices - it says so - but I would be paying $12.05 not being a frequent user.

Based on what I see above, yes, you should be quoted $12.05

tpeck:

Maybe this is where my idea of a sliding percentage scale (per shipper) might actually work to make the quotes spot on???

Methinks the better solution is for me to try to replicate the data and figure out exactly what is going on. As with most discrepancies of this nature I suspect that the data that you are entering online isn't the same data being submitted by the store.

I'll get back to you a little later with my findings.

Cheers
Rod

tpeck:

Can you tell us what logic you are using to get the figure of $11.00?

OK, Just had a look, but found nothing to explain it yet.

My test data:
fromcode=2000
destcode=3079
FastWay=SYD
weight=1000
height=50
width=50
length=50

On the Fastaway site this produces the exact same results as your sample graphic , namely, Red label $9.52 - $12.05

Using this same data on the ozpost site, produces a Red label quote of $12.10 (the FW server will often use odd cents, the ozpost server rounds up to the nearest 10cents).

You can see this for yourself with the following link:

http://ozpost.net/postage.php?fromcode=2000&destcode=3079&FastWay=SYD&weight=1000&height=50&width=50&length=50&host=example&version=1.0

So, the question is, what data is your store sending that causes an $11.00 quote?

I'll continue to experiment a bit even later today, but meanwhile I thought I'd share these preliminary findings with you, mainly because you are in a better position to see what data is being sent at any given time than I am.

Cheers
Rod

Hi Rod

Deleted any the tpl_modules_shipping_estimator.php files except the default one. Still getting the errors. Sorry!

Rob

Hi Rod

A little bit of success. I went back to version 2.0.6 and am not getting the error messages in the error log. Does that help?

Rob

robbie269:

Hi Rod

Deleted any the tpl_modules_shipping_estimator.php files except the default one. Still getting the errors. Sorry!

Rob

This has me beat at the moment.... doubly so because I can't seem to replicate the error on your site (thehorsestall.com.au)

Is there anything that you know of that will allow me to replicate the problem... eg, does it only occur when there are specific item(s) in the cart, or perhaps something with the destination location, basically any clues at all could be useful.

Anyway, you can probably revert back to the ozpost tpl file now, because it didn't fix the problem, so therefore has nothing to do with the cause.

Cheers
Rod

Hi Rod

The errors only appear in my cached error log. So I don't know how you could see them. However it is always the same 3 as my original post. And I get them no matter what products I order or where I pretend I am from.

It does not seem to effect customers at all because I am still getting orders with the correct postage rate etc.

My live site is still running 2.0.8 with the errors. But I have been fiddling on my test site which is identical to the live one. As I said previously I copied all the 2.0.6 files over and got no errors. I have since done a simple upgrade to 2.0.7 (just coping the ozpost.php files) and am now getting the errors again. So it must be something in those two files. I think?? Maybe.

Rob

tpeck:

Can you tell us what logic you are using to get the figure of $11.00?

I realise there is a range of label prices - it says so - but I would be paying $12.05 not being a frequent user.

OK, I've figured out whats happening here - As per earlier message, the ozpost server will quote this as $12.10 due to rounding. This price includes GST, so the figure being displayed to you ($11.00) is the pre-GST amount ($11.00 + $1.10 = $12.10).

Your other shipping quotes have the same 'error' - EG, AustPost Parcel - Shows $11.73 - The actual cost is $12.90 ($11.73 + $1.17)

In other words, you have something amiss with your GST/Tax settings.

If you are NOT registered for GST the solution is simple... under the ozpost admin settings is one to enable/disable the tax... It appears that you have this enabled - Just set it to 'none' and the quotes will be correct.

If you ARE registered for GST, you will need to enable this option AND ensure you have the correct TAX rates set for the Australia zone, and again, your customers will be presented with correct GST inclusive quotes.

The fact that you are seeing tax exclusive prices would indicate that you have enabled the GST functions, but haven't set a GST tax amount.

I know this may seem a bit convoluted, but in order to get the figures 'right' for both GST and non GST registered clients the ozpost module needs to take the GST inclusive prices provided by the servers, present them 'as is' for non GST merchants, but reduce them by the GST amount for those merchants that are GST registered... The zencart core code then calculates the amount of tax that needs to be added to the shipping based on the tax rates defined ... Since this tax rate should be 10%, the same that ozpost had reduced it by, the net result displayed will once again be GST inclusive - The only difference is that 'zencart' now 'knows' about this GST component and as such will show it as such on the invoices, etc.

I realise that many small GST merchants wouldn't normally even consider claiming the postage tax back as an input credit (partly because it is difficult to keep track oll those small amounts), but a busy store could be spending a small fortune on postage and these credits can add up pretty quickly.

On the other hand, any merchant that has a turnover of less than $75,000pa would be foolish to register for GST anyway - It provides no gains, and effectivly makes 'em an unpaid tax collector. (been there, done that).

Anyway, the cause of your problem has been identified - You shouldn't have too much problem fixing it. :-)

Cheers
Rod

robbie269:

The errors only appear in my cached error log. So I don't know how you could see them.

Oh, ok... When I first came across the issue the errors were being dumped to screen (I guess the server was set to report a different error level or sumfing). I had simply assumed yours was too. (I really must stop making assumptions).

robbie269:

However it is always the same 3 as my original post. And I get them no matter what products I order or where I pretend I am from.

This is also important to know :-)

robbie269:

My live site is still running 2.0.8 with the errors. But I have been fiddling on my test site which is identical to the live one. As I said previously I copied all the 2.0.6 files over and got no errors. I have since done a simple upgrade to 2.0.7 (just coping the ozpost.php files) and am now getting the errors again. So it must be something in those two files. I think?? Maybe.

Until now I wasn't sure about v2.0.6 - But you have confirmed this version is ok... Now, I know that V2.0.7 definitely had the issue, and the fix for it came about with 2.0.8 - or at least I was hoping this was the case.

So, if you don't mind, I would suggest you go back to a working copy of 2.0.6 then upgrade directly to V2.0.8. I'm not sure if it'll help any, but I think it is worth a shot.

I have done other research this afternoon, and from all accounts, the problem is definitley linked to the attempted saving of XML data as a SESSION variable, and I'm 99.9% confident that there is only the one instance of this, and that is in the 'main' ozpost.php file.

.... (later)

Hmm, I may have found another culprit that I missed:
ozpost.php line 285

$_SESSION['ozpostdsub'] = $xmlQuotes->information[0]->destsuburb;

Try commenting this line out and see if the problem goes away. If so, re-add the line with a minor modification, thus:

$_SESSION['ozpostdsub'] = (string)$xmlQuotes->information[0]->destsuburb;

I will add that this isn't important code - it does nothing for the functionalty of the module, what it does do is show the Destination suburb on the shipping estimator page, and the customers should know what suburb their postcode is anyway <g> ... I added it as a bit of feedback because FastWay requires suburb names rather than postcodes, and some postcodes have many suburbs associated with them - This 'feedback' was to let me (and others) know exactly which suburb is 'selected' for any given postcode.

Anyway, hopefully the fix above will solve the XML/Session problem for you. If not, it's back to the drawing board.

Cheers
Rod

The only other oddities that I notice when being served quotes is that the weight at the top of the shipping estimator is in lbs not gms, yet I have set gms (not kgs) as the setting.

I think you might have answered this before (beyond your control maybe???) - I can't remember.

The other thing is that one of the quotes is always bolded, but there's no knowing which one it will be.

It's likely an error my end, and I'm now wondering if another add-on I installed is messing things up. I'll have to do some research.

EDIT: POSTED THIS WITHOUT READING YOUR LATEST MESSAGE, SO THANKS - WILL INVESTIGATE.

Hi Rod

It's fixed!!! It was that culprit in the ozpost.php file. I have added the edited line and I am not getting any errors in the log. (And I have gone in there a couple of times just in case my eyes have tricked me.)

Thanks Rod. I really appreciate your work.

Robyn

You must be right - given the figures - but I'm a bit bemused by this GST solution because I think I already have it set up right:

If you ARE registered for GST, you will need to enable this option AND ensure you have the correct TAX rates set for the Australia zone, and again, your customers will be presented with correct GST inclusive quotes.

The fact that you are seeing tax exclusive prices would indicate that you have enabled the GST functions, but haven't set a GST tax amount.

I kept the settings from the previous zencart/ozpost setup before I moved to zencart1.3.9d and ozpost 2.0.8.

I've always been registered for GST so I have it set up like this:

and...

...but my quotes are tax exclusve? Weird.

It's got to be me but has me beat. Sorry to cause you strife.

*(BTW - the green admin background is the Green Tea theme - easier on my tired old eyes. Highly recommend if that's your thing too.) *

robbie269:

Hi Rod

It's fixed!!! It was that culprit in the ozpost.php file. I have added the edited line and I am not getting any errors in the log. (And I have gone in there a couple of times just in case my eyes have tricked me.)

Thanks Rod. I really appreciate your work.

Robyn

Thanks for the bug report, and all that you have done to help me solve it :-)

I'll update my source code now so that it'll be fixed 'out of the bx' with the next update.

Cheers
Rod

tpeck:

It's got to be me but has me beat.

A bit to early to come to any conclusions yet, but I have to admit, it has got me stumped at the moment too.

Please bear with me on this reply, I'm 'thinking with my fingers' (I often find it helps when trying to figure sometring that doesn't make much sense)

I've discovered a couple of 'odditys' that I can't explain, that may or may not be the key to the issue.

Firstly, one of the graphics you supplied shows that your GST zone is for "1.Australia" - This may or may not be significant. All other stores I've worked on has this displayed simply as "Australia".

Whether, or even how this will affect things I have no idea (much of what zen does in regards to handling tax is a bit of a mystery to me).

The other oddity is in my code - I've spotted a discepency that may or may not be intentional - It has been a long time since I've look at this part of the code and to be honest, I have no explanation as to why I've done what I've done (I'm sure there is/was a good reason, but can't think what it would be.
<stop the press>
Forget this - The oddity is/was intentional to avoid a divide by zero error.

..... Thinks some more......

Nope, this has me stumped.... the ozpost code does pretty much the exact same checks when deducting the GST as it does when adding it - The check/test when adding GST being:

if ($this->tax_class > 0) { "get tax rates" }

and for reduction:
if (($dest_country == "AU") && (($this->tax_class) > 0)) {"calc ex GST"}

The stuff between {} isn't the actual code, it is just to indicate what the code actually does if the conditions are met.
It needs to be noted that the deduction of GST only occurs if the destination country is AU and the 'tax_class variable is greater than zero. This is because only AU deliverys have the GST component.

The test for reADDING the GST only needs to check for tax_class > 0 with no need to limit to AU because any non AU quotes don't have a GST component in the first place.. in any case, it wouldn't be important because it is this less restrictive test/check that appears to be broken. IOW,

if (($dest_country == "AU") && (($this->tax_class) > 0)
is finding and using the correct tax_class,
but the code
if ($this->tax_class > 0) is either failing to match, or, if it is matching, it isn't returning the tax rate......

OKAY....... I think this is where we should possibly start with a little bit of debugging. Are you handy with a text editor?

If, so, load the ozpost.php into your editor, and seach for 'tax_class'.

There will be one such entry on line 131... So, on line 132 (currently blank) add this:

$this->quotes['tax'] = 10 ;

There is a similar entry on line 537 .. as above, on the line below, add:
$this->quotes['tax'] = 10 ;

Save the file and see if the quotes now appear with the correct GST inclusive amounts. (The lines you have added will effectively negate/override the lines the precede them).

IF this seems to 'cure' the problem we'll need to investigate whethjer it is the ($this->tax_class > 0) check itself that is failing, or whether it is the retrieval of the actual data that is amiss... My gut feeling is the latter, but the modification I suggested tests both possibilty at the same time rather than each one individually.

Well, Im not sure how much of this you have been able to follow (as I said at the start, I'm finking with my thingers) - I'm hoping you have followed enough to see the direction I'm heading and that you are willing/able to make the suggested changes... if not please get back to me and we'll see if alternative debugging can be arranged....

Cheers
Rod

ps. For the time being (at least when not testing/debugging) it will be wise for you to tell the ozpost module that you are NOT registered for GST. This will/should at least stop you from underquoting. The downside being that you'll have no way of isolating the GST component for reporting purposes.

I'm willing and (I hope) able - just not ready yet...my server has been on and off for the past day and a half and I'm still waiting for it to snap to. It hasn't got anything to do with it - just co-incidental.

I'll get this done tonight. Thanks again for your explanation of what it might be. (PS - I hope you got the updated .gif by now.)