Printable View
Oh yes I think I can explain with girthQuote:
Originally Posted by zekin
Let's assume L is the longest, L > W > H
Girth = (W+H)*2
see max girth is 60cm because it's satchel's width 30cm x 2. If you take object's Length in consideration, it can work the same way, the max "(L + H) x 2" should be 80.
I believe this is the validation check that you can make sure the box can fit in a satchel or not.
Just as you say it should. Ergo, the current methods are still valid. Nothing more needs to change until/unless someone gives me another practical example of false positives. :DQuote:
Originally Posted by zekin
Cheers
Rod
No one asked you to.Quote:
Originally Posted by zekin
Yes, the length is always considered to be the largest of the 3 dimensions.Quote:
Originally Posted by zekin
Correct. and this is where you should stop!Quote:
Originally Posted by zekin
We have already taken the length into consideration when we determined which of the 3 dimensions was the longest .. The reason for doing this is so that we then know the two *shortest* dimensions so that we can calculate the *girth*Quote:
Originally Posted by zekin
But this calculation isn't the girth. It is meaningless.Quote:
Originally Posted by zekin
Not so. The length is always going to be the longest side, and the girth is always double the sum of the other two sides. There is nothing more to consider.Quote:
Originally Posted by zekin
Cheers
Rod
Hi the purpose of "max (L + H)x2 = 80" is to check if the box can be completely fit inside the satchel and seal properly.Quote:
Originally Posted by RodG
It's how i determine whether an item can fit satchel in real life. It's not meaningless IMHO.
Even though item's W & H might passed the girth test, but if L is too long, then when you try to fit your item into satchel, you can't seal the satchel (the sealable tape can't reach the other side), ie box exposed.Quote:
Originally Posted by RodG
your rule: The largest item that will fit (theoretically) is Length 40cm x Girth 60cm
In reality , the max Length can't be 40cm unless girth is very very small 0 , eg a few sheets of 40x30cm paper. When you have stack of paper, say 500, you will build up "height", so at that time the stack of paper's girth maybe still less than 60, but i gurantee this time the satchel won't be able to sealed.
That's why I suggest the rule that if (L+H)*2 is less than 80, so you are guaranteed that the satchel can be sealed.
And the reason I suggest L+H , not L+W is because I find that you need to count on the shortest side to give best possibility for "sealable tape" to seal properly. The stack of 40x30cm paper is an excellent example.
This rule can also apply to any satchel , including fastway.
Hope this helps.
You are hero for doing this module. Keep it up!Quote:
Originally Posted by RodG
Exactly.Quote:
Originally Posted by zekin
.... and the rest of it.... (see my first reply to thisa conversation).Quote:
Originally Posted by zekin
This has been accounted for.Quote:
Originally Posted by zekin
Yes, but it is no good sealing the parcel if the 'real' girth is too great.Quote:
Originally Posted by zekin
I see where you are coming from, and I think I'm going to need to sit down and think upon it a little more, because the possibilty of exceeding the real girth is one immediate drawback .. I think testing for two different 'girths' would be the most accurate solution, but that may needlessly overcomplicate the code (IMO).Quote:
Originally Posted by zekin
Cheers
Rod
Yup, totally agree. :yes:Quote:
Originally Posted by RodG
Thanks so much for looking into this btw.
Rod, this is a topic we have actually discussed before (say 2-3 yrs ago) ending abruptly when I linked you to a site that showed that the general case for a packaging algorithm is impossibly complex to solve. But it may be possible to improve on what you currently do without entirely solving the issue. For me the main problem with your module is that it doesn't know when to stop trying to calculate the costs and we, as shopowners, have no way of setting boundaries for it to test and drop to a generic "Call for price" when exceeded.Quote:
Originally Posted by RodG
In my case I have three differently 'shaped' products in my store: charts, which ship in tubes, B4 books, and flatpacks of charts (700 x 1000 mm). Each of these alone can cause problems, but when mixed in a single order the shipping costs are invariably absurd. Here are two common scenarios for my situation and some gratuitous suggestions which would help me, and perhaps significant numbers of others with similar problems:
1. I can and do pack up to six charts in a tube 100mm dia x 1000mm. Your software doesn't handle this properly because it doesn't understand that multiple charts can be rolled into a tube without changing the dimensions of the package and therefore adding the largest dimensions is meaningless. I think it would be really useful in this instance to have an option in the product page where I can specify how many products will fit into the tube (or indeed any defined package). This case is directly analogous to the teatowel problem you handled above. The shopowner should be able to specify the dimensions of the package and the number of a given product that will pack into it.
The shipping code will also need to test for item count and weight in order to determine the number of packages to create and then cost. I guess if (to use my case as an example) one gets an order of say 11 charts that the code will have to cost shipping of two tubes - or is it one if they are over-wrapped with paper into a single package? Fortunately I'm rarely presented with this problem so I say don't bother trying to handle such complex cases, eg a box with varying numbers of different items, or boxes of items consolidated within a bigger box etc.
2. I often get orders for a book and a chart, usually for export. You can't fit the book into the tube or vice versa but Ozpost will calculate the shipping cost at about $35 whereas in fact it will cost $60 ($35 + $25) to send it to the UK, blowing away any profit. I haven't got a simple answer for this but note that there is code out there for setting up discounts for a product when another is also purchased at the same time. Such links could be exploited to set up the "call for price" message described earlier.
I'm already happily subscribing to your postal service but if you were to find a widespread support for any of the features I've described I'm prepared to contribute towards any work you do on it.
During checkout - the message appears (no hovering takes place) and shows how may days left for the shipping module. No icon, just the text in a box, above the quote selector box. It's there each time I checkout with a test shopper.
For some reason you are missing a logo... it's called "ozpost_logo_gif" and should be found in the icons folder that holds all of the other ozpost icons.Quote:
Originally Posted by ozmosaics
You can restore it with an original copy from the distribution package, or, if you wish it to be a little less obvious just create an image 1px x 1px and store that in the folder (using the name "ozpost_logo_gif"
Cheers
Rod
I'll concede that it's a similar topic, but as I recall, the topic then was the best way to 'pack' any given assortment of items. This current thread is a lot simpler in that it is just a matter of determining 'will it fit'.Quote:
Originally Posted by lucidlee
I guess there is no reason I couldn't add a 'call for price' option should any given quote exceed a preset value.Quote:
Originally Posted by lucidlee
It is the 'things that fit into things' that would be your biggest issue... namely the charts ...Quote:
Originally Posted by lucidlee
The computer suffers a meltdown when it tries to combine multple 3d objects without altering the dimensions in any way <g>Quote:
Originally Posted by lucidlee
I'm reluctant to travel this path at the moment because it can only be done by modifying the core code, which is something I'd like to keep to an absolute minimum (for ease of installation/updates)Quote:
Originally Posted by lucidlee
Perhaps one day I'll even supply a dropdown menu for a selection of different package type/sizes ... (It HAS been considered, and several courier companies have similar inputs), but I honestly can't see this happening in the forseeable future.Quote:
Originally Posted by lucidlee
This is a good place to remind you that there are two different topics/issues at hand here... The PACKING of items and the cost to SHIP the items.Quote:
Originally Posted by lucidlee
The ozpost server is predominantly concerned with producing accurate shipping costs based on any given input data. This it does.
It is for the client software that deals with the 'packing', and yes, I am also the author of the client code, but I see this more as a base code for others to build upon, whilst I concentrate more on the server code/maintenance.
Unless I'm mistaken, the reason why it costs $60 is because you send them as two separate items? If so, don't do that. Just find a box that'll fit both items (or tape 'em together) and send them as a single parcel, then it'll only cost what you were quoted for. :-)Quote:
Originally Posted by lucidlee
This function/feature would be best performed by another module entirely, one that detects the condition and negates all other shipping options (including ozpost)Quote:
Originally Posted by lucidlee
If things go well I'll have a lot more time to devote on the project, so who knows where it will lead.Quote:
Originally Posted by lucidlee
Cheers
Rod
Dear Rod
The codes to determine whether items can fit in satchel or not, eg calculation of girth and length, and validating actual weight against satchel's allowable weight, and the information of all kinds of satchel's dimension, is it all in your ozpost server?
The code that calculates the parcel weights and dimensions is performed by the client code. (the store module)Quote:
Originally Posted by zekin
The determination as to whether it'll fit a letter, satchel, or whatever is made by the server code.
Cheers
Rod
Love the module, easy to install and configure.
Few issues:
The fastway module i have for cubecart has the option to turn certain colours of label on or off and add specific handling fees for certain labels.
For our company we post large items(25kg) and sending to Grey ticket areas is often hugely expensive and sometimes not even possible as fastway uses different couriers for these areas, so we just turn them off.
Also sometimes it wont retrieve costs at estimate shipping, but if you log in with full town and postcode etc it will estimate the shipping.
So it would seem it needs town name for some costs? this is mainly for Australia post it would seem.
I would really like a option that if this cant calculate postage it offered a option to submit the cart contents to us for freight calculation and we could then submit a postage price and they could log back in and finish the transaction. Sort of like ebays "request postage cost" feature. I dont expect that from this module but if someone knows of one please let me know.
But I haven't ported ozpost to cubecart (yet) ;-)Quote:
Originally Posted by gmturner
I always let the client decide whether shipping is too expensive or not.Quote:
Originally Posted by gmturner
I would assume that the FastWay servers wouldn't return a quote for areas where they don't deliver.Quote:
Originally Posted by gmturner
All FastWay quotes require the town/suburb names. These are currently derived at the server, based on the postcodes supplied by the client. This is not the BEST option (which would be for the client to supply the suburb names) but it is close enough for most practical instances (so far).Quote:
Originally Posted by gmturner
The ozpost module aleady has the ability to disable itself if it can't obtain suitable quotes from the server, so the job is 'half done'. I don't know if there is another module available (call for shipping quote) to use under a no_quote_available condition or not.Quote:
Originally Posted by gmturner
To cause ozpost to disable itself, all you need to is enter negative values for the 'fixed cost' data.
Cheers
Rod
Fastway are franchises, and the ability to post a item to a certain place for a certain price falls upon the franchise owner. As our items are so large and often beyond size limits we have a special deal that allows them to go, BUT when these items are travelling to grey zones and carried by other companies etc it can lead to the local franchise losing money and it can and has led to difficulties with items getting lost, although covered by fastway insurance it is troublesome.Quote:
Originally Posted by RodG
Because grey tickets cover like 2% of customers if that, we would prefer not to send to them or at least have them contact us so that we may work out a solution which sometimes involves greyhound bus freight and picking up from a depot which no module could ever work out. So disabling grey tickets isnt possible and not going to be possible in the near future?
Handy with a text editor? If so, make the following changes toQuote:
Originally Posted by gmturner
/includes/modules/shipping/ozpost.php
First, locate the following code segment:
-----------------------
case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
break;
-------------------------
Replace this block of code with:
---------------------------------------------------------
case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) {
if(!strstr($quote->description, "GREY" )) {
$handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
}
break;
-----------------------------------------
This will (should) prevent the Grey label quotes from showing.
Oh, I will also state that I'm really not that familiar with the FastWay pricing structure, nor the meanings of the colours of their labels, so would it be right/wrong for me to add a toggle to enable/disable all of the different colours. You also mentioned different handling fees .. again, would it be right/wrong to support a different handling fee for each colour?
Cheers
Rod
thanks seems to work, although you put a extra { in that i had to remove to make it work.
Also prices for Australia post satchels are incorrect. It gives $10 for a normal 3kg satchel and $11 for a express one. They are $10.30 and $11.70 respectively.
Actually, it appears I left one of them out.Quote:
Originally Posted by gmturner
The corrected code should read:
case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) {
if(!strstr($quote->description, "GREY" )) {
$handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
}
}
break;
The server is providing the correct quotes. I'm not sure why your store is chomping off the cents... this'll need further investigation.Quote:
Originally Posted by gmturner
Cheers
Rod
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.
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.Quote:
Originally Posted by zekin
Not difficult to fix:
/includes/modules/shipping/ozpost.php (v2.0.9)
Line 469 curtrently reads:
It needs to read:Code:if ( MODULE_SHIPPING_OZPOST_CORE_WEIGHT == "Yes") { $quote->cost = $quote->cost * $shipping_num_boxes ; }
This fix will be included with the next update (none currently planned)Code:if ( MODULE_SHIPPING_OZPOST_CORE_WEIGHT == "Yes") { $quote->cost = (float)$quote->cost * $shipping_num_boxes ; }
Cheers
Rod
See post #1123 in this thread. I'll bet this is the problem.Quote:
Originally Posted by gmturner
Cheers
Rod
Yep fixed, thanks.Quote:
Originally Posted by RodG
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.
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'Quote:
Originally Posted by gmturner
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
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.Quote:
Originally Posted by gmturner
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.
Actually, you are wrong. It rarely ever comes up.Quote:
Originally Posted by orien
How often is 'quite often'? (once a year? once a week? Every quote? one quote in 50 ?Quote:
Originally Posted by orien
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?Quote:
Originally Posted by RodG
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
Could be, but I'm not prepared to jump to this conclusion.Quote:
Originally Posted by orien
Correct. (as well as if valid methods cannot be obtained for other reasons)Quote:
Originally Posted by orien
I think if this were a common problem a lot more people would be screaming about it.Quote:
Originally Posted by orien
Did you enable the debug option for any clues?Quote:
Originally Posted by orien
That's what everyone says. On the odd occasion it has even been true, but mostly it isn't.Quote:
Originally Posted by orien
Not much I can do for you then (I sold my crystal ball when I gave up the TV/VCR repairs).Quote:
Originally Posted by orien
You do realise that zencart is designed so that more than one shipping module can be used at any given time, don't you?Quote:
Originally Posted by orien
But nonetherless, you assumed it was a common problem that "has probably come up quite a bit".Quote:
Originally Posted by orien
Is this just another wild guess, or have you some other reason to think it would be a cURL issue?Quote:
Originally Posted by orien
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.
This forum is for ozpost support only. If looking for alternative methods you would be better served using a different forum.Quote:
Originally Posted by orien
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.Quote:
Originally Posted by orien
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.Quote:
Originally Posted by orien
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.
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).Quote:
Originally Posted by gmturner
Cheers
Rod
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).Quote:
Originally Posted by RodG
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.Quote:
Originally Posted by ALiepinieks
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.
Correct.Quote:
Originally Posted by 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.Quote:
Originally Posted by orien
Rgds
Rod
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).Quote:
Originally Posted by ALiepinieks
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.
Sorry, no. There is no option or method to do this.Quote:
Originally Posted by Nintendoparts
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.Quote:
Originally Posted by Nintendoparts
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
Hi Rod
Could you please explain the "Use Core Weight" and "Restrain Dimensions" options to me.
The reason I want to know is that I post these crystal cubes that are quite heavy for their size. The postage works out OK until someone orders more that 17 of them and then it reverts to customer pickup only. To fix this recently I chose "yes" to the core weight and restrain dimension options. This seemed OK and put the postage across multiple parcels as I hoped.
However, when someone ordered a bracelet that should only be a letter it made it a parcel and tried to charge $16.00!
I have since reverted back to choosing "no" to both options as the majority of the time it calculated correctly.
What is the solution for the cubes when ordered in bulk?
Is anyone else having problems with this module right now? It appears to have gone down from our side.
Its working here, and were on V2.08 (if that helps)Quote:
Originally Posted by somedood
I can try :-)Quote:
Originally Posted by robbie269
Under 'normal conditions', the zencart core code calculates the number of parcels needed, and their weights, based on the settings in the shipping/packing configuration. It then makes this information avalaible to the shipping module(s). This isn't/wasn't really suitable for my needs, where the total weight and volume was more important than this simple parcel splitting, so up until recently, the ozpost ignored the zencart supplied values and calculated its own (the main difference being with the tare weights, which many found troublesome anyway).
The "Use Core Weight" setting is giving back the abilty to use the zencart supplied values, which also includes the creation of multiple parcels based on weight. The ozpost method assumes a single parcel only, regardless of weight.
The "Restrain Dimensions" option will limit the dimensions of any given parcel being quoted so that it will never fail a quote due to its size alone, for example, the max length item that australia post will accept is 105cm - so if the ozpost module calculates the parcel as being (say) 120cm long (which would normally fail to produce a quote), it will instead provide a quote for an item only 105cm long ... IOW, it'll be quoted based on weight alone.
This is very useful if you know that your products aren't subject to the cubing rules.
This will almost certainly be a result of 'apparent oversize' due to the cubes being stacked into a single column, and yes, setting the 'restrain dimensions' will alleviate this problem for you. This is exactly the situation that this option was created to for).Quote:
Originally Posted by robbie269
I can only guess that like most other Australian merchants, you haven't set/configured the *zencart* tare weights yet, and by default, this is set to a value of '3' (whether this is 3kg or 3gms is dependent on the 'Kgs/gms' setting in the ozpost module). Just to confuse matters, it'll probably appear as '3lbs' in some places (unless you've modified your language files).Quote:
Originally Posted by robbie269
Anyway, my guess is that this is why the bracelet appeared so heavy.
Another possible, but related reason could be that this is also where the 'max weight' settings are, if this is set at something like '20', and you have ozpost using 'gms', and the bracelet is weighted at 100gms, then the quote will be for 5, probably 6 parcels, each weighing a little under your 20gm maximum.
Ideally, if you are doing a lot of bulk sales, then the best method by far is to 'prepackage' the items and use the weights/dimensions for the bulk 'product' as this will give you the greatest accuracy and allow more products into any given cart.Quote:
Originally Posted by robbie269
However, if you aren't quite ready for bulk sales, and considering what you are selling, I would suggest that setting the 'restrain dimensions' to 'yes' and the 'use core weights' to 'no' will produce accurate results for all situations... the only time you'll come unstuck is if you do actually sell enough stones/jewelry in a single order that it'll be too large for most carriers to handle, but in that case, I suspect postage costs won't be an issue anyway :-)
Cheers
Rod
HiQuote:
Originally Posted by somedood
I am experiencing problems with the ozpost module that started yesterday some time. When in the checkout dialog the shipping page does not load and instead just displays a blank page. I've disabled ozpost and instead am using with flat rate postage and the shipping page now loads. I am using ozpost.php,v 1.0.2 and have been using this for 12 months without this problem. The site is hosted on bluehost. Does anyone have any ideas.
Anthony
Hi Rod
Yes, setting the Restrain Dimensions to yes has helped. Plus I adjusted the tare weight bits in shipping/packaging to 10:0. (10%). I have set the maximum package weight I will ship to 20kgs, is this correct?
It still gets to about 35 of the cubes (it only got to 17 before) and then gives me no postage calculation. I can live with this. If anyone orders that many in bulk they probably deserve free shipping! And bracelets etc seem to be calculating OK.
Thanks
Robyn
It isn't *incorrect* - but keep in mind that these settings are only used if the 'use core weight' setting is 'yes'. If this is set to 'no' then these settings are ignored.Quote:
Originally Posted by robbie269
If you enable the 'debug' option when testing/experimenting you'll probably be able to identfy why 35 is the new limit. If it is weight related, then using the settings that you have specified above, with the 'use core weights' set to 'on' will probably overcome this barrier. Keep in mind that with this configuration; if you have an item in the cart weighing 22kgs, the software will assume you can cut it in half and quote for 2x11kg parcels.Quote:
Originally Posted by robbie269
Cheers
Rod
I understand not everything can be free, but I do not agree with the way this move to fee service was done.
To just make the service "not work" anymore, causing the site to display a blank page, is in very poor form.
This happened to a customer's site, I will tell her why it has happened, and if she chooses to pay, that is her prerogative, but I do not like the idea of supporting these kinds of practices.
Perhaps it's because of zen cart's limitations, but this "Fee service" is not even explained in the download page here on zen cart!
I can understand if a newer and better fee based service was developed, and then support for the older free one was discontinued, but to just cut people off with no explanation really sucks. I don't think I've seen anything like it before.
I think it's ironic that your site tagline is "You never know what you will find". In light of these changes, that really becomes quite a negative statement. Great, what will happen next?
Sorry, I don't appear to have any records of your email address, and didn't know that either you, or your customer were even using an obsolete version of the module. If I had this knowledge I would have personally sent you emails detailing the changes.Quote:
Originally Posted by jettrue
I had also assumed that a merchant and/or developer would be checking in and/or subscribed to the support forums for the module(s) being used on a regular basis (at least monthly) to stay on top of security issues, etc.
I now know this assumption is wrong, but unless you and/or your client keeps up with things, the failure of a shipping module sooner or later is going to be the least of your concerns.
Cheers
Rod
I am another victim of OZPOST / VCSWEB.
My site was effectively shutdown without warning due to VCSWEB changing to a FEE Model.
The arrogance of the above response from Rod is astounding.
Why couldn't users of OZPOST be sent a message? I run a small business, I have no time to myself, I am flat out keeping it running and expanding. I don't have time to browse the support forums for a product that seems to be working fine.
The onus, without doubt, was on VCSWEB to advise all users that their sites would be made inoperative.
Your reason for imposing the FEE is so you can add features to the product. If you wanted to make an feature rich product that you could charge for, go ahead do it. I am quite happy with just the Australia Post functionality of the product. I don't want any more features.
So, what are my options? None, I have to keep the site running. I paid the ransom.
Now looking/hoping for an alternative.
I feel like I have been bushwacked.
Shane
This is disgusting! Like the above poster I dont have the time to come reading the forum every month, I spend 10+ hours a day 7 days a week keeping the business going and now I have piles of emails to get through on a sunday morning asking whats wrong with the shipping and please quote me the shipping cost!
If you want to start charging for a product that has always been promoted as free then you need to contact all the users and you need to learn a little about customer service. Just cutting off our access is a very low thing to do, my reputation, mortgage, living expenses all rely on my website 100% and you have just cut me off without even a word of contact...
How do I fix this??? Not all of us are computer gurus, I struggle through keeping up with zencart and keeping it running, I cannot afford to pay a developer to run my site.
I have only just come across this now when a customer emailed to say she couldn't get passed the checkout stage. I tried to do a dummy order and the same happened when I tried and no shipping options came up either.
So how do we get access to it. How much do we have to pay, how do we pay and to whom do we pay?
As a temporary fix though I have just added a flat rate cost for parcels.
Thank you.
Anna
www.toycrazy.com.au
I paid the fee this morning and am still waiting!!! When I logged back onto VCSWEB it tells me I have made no purchases!! The checkout system is not reliable, I had terrible trouble purchasing a subscription to the ozpost module, and have had nothing but a paypal invoice come through email.
Not impressed at all, I have spent years running online businesses and would have gone broke if I did things like this.
The weekend is the busiest time for my business, especially when the weather is bad, vcsweb is costing me money!
Hi Rod
I enabled the debug option then ordered 80 cubes and it gave me the error: "Server Returned:Quote:
Originally Posted by RodG
RPP0.00-1Invalid weight parameter 11.05 0.00 AIRDS AIRDS 362"
If I enable the core weight option it is OK and spreads it over 3 parcels. However the postage calculation is then slightly off, eg: a large letter is $1.00 instead of $1.20 a small parcel is $4.00 instead of $4.55. It seems to round it down to the nearest dollar??
Rob
This is a grossly inaccurate statement. When your 60 day trial period had expired the ozpost shipping module simply stopped providing quotes. It didn't stop anyones store from working, it didn't stop users from selecting other shipping methods, it didn't prevent anyone from checking out.Quote:
Originally Posted by bolts
We have no idea who is using the module, and server log files don't conatain email addresses. So other than relying on this forum (and the few emails that we have from previous correspondence with users) how exactly were we supposed to do this?Quote:
Originally Posted by bolts
Congratulations, you have just nominated yourself to be a future victim of a hack attack... No, not from anything I am going to do or say (or have said), but your open acknowledgement that your zencart is grossly outdated and simply waiting to be exploited.. Thankfully you didn't publisize your store name or URL, but I'm sure an interested hacker wouldn't have too much trouble finding it.Quote:
Originally Posted by bolts
I have been critisised in the past for not notifying users of important changes and/or security fixes and this is another reason We've moved towards a saubscriber system, so that we *can* keep individuals up to date.
Except for rhe vocal few in this forum, that have clearly neglected thier stores (and I'm sure there will be more to come) MOST ozpost users appear to have accepted this change with good grace, some by using other shipping methods, others by supporting what I am doing.Quote:
Originally Posted by bolts
I can only apologise so much to those of you that haven't kept abreast of things, and I do actually sympahise with you if the expirations has been your first indication, but on the other hand, I've found two types of people in this regard... Those like you that make a lot of noise saying how criminal it is, and those that have sent me polite email stating this was the first they knew about it. Guess which people have been given extensions so that they can review thier options?
I don't know where you got that idea from. It is mainly to allow me to devote more *time* to the project... This time may not even go towards zencart users specifically - I also have the OsC folk and their needs to consider, not to mention, CubeCart, OpenCart, and a few others.Quote:
Originally Posted by bolts
This is also untrue. Ozpost is in its infancy. Zencart, etc, has been around for a lot longer and yet people coped with the shipping ok.Quote:
Originally Posted by bolts
You have had at least two months to look for an alternative.Quote:
Originally Posted by bolts
Me too (often) .... but at least now I'm getting something out of it.Quote:
Originally Posted by bolts
Oh, and for those you that are interested.. although early days yet, the dropout rate hasn't been as high as I had expected (95% vs 98%).. so it is looking as though the project will be be a success (which is a relief, 'cos I'd hate to start giving refunds and closing the servers down now).
Cheers
Rod
This is Australia Post telling us that you've exceeded to 20kg limit.Quote:
Originally Posted by robbie269
If you had other carriers enabled their quotes would be shown as they are not subject to the RPP limit.
This is a bug.Quote:
Originally Posted by robbie269
The fix is very easy, and can be found here
Cheers
Rod
Thanks Rod that fixed it.
I thought I had read it somewhere but when I needed it I couldn't find it!
Rob
I'm tempted to report this to the zencart team as a bug report because we are running the latest zencart with no addons or modifications to the checkout system and the stock standard PayPal Express.Quote:
Originally Posted by ExtremeRC
Alas, you are the first to report this as an issue, so I doub't I'll be able to convince them it is a bug. Unless of course you have something to add that will give a further clue to this zencart issue?
Things should have started working ok for you at around 3pm this afternoon.. Please advise if this is not the case... I needed to manually match the storename you specified (www.extremerc.com.au) with the storename on record (Extreme Radio Control?).Quote:
Originally Posted by ExtremeRC
It is my hope that the loss or non-operation of 'ozpost' is going to cost lots of merchants lots of money, because that is what will show how much it is truely worth in comparison with the free alternatives ... or not.Quote:
Originally Posted by ExtremeRC
Ozpost isn't for everyone.
Cheers
Rod
I've just subscribed and was wondering when I can expect the cart to work again. I also tried phoning, but it went to message bank.Quote:
Originally Posted by RodG
Thanks in advance - Pink Sugar Design
Scrap that, It says I have 181 days but when I go through checkout it is saying "This is currently the only shipping method available to use on this order."Quote:
Originally Posted by pinksugardesign
I've set up the module, what may have gone wrong? Do I need to wait for it to set up on the server still?
Please enable to 'debug' option for any clues. It *should* be working.Quote:
Originally Posted by pinksugardesign
Cheers
Rod
Thanks for your help Rod. It is most definitely working now. It seems one must allow more than just NOW for it to work. :)Quote:
Originally Posted by RodG
Patience is not one of my virtues, it seems.
Will I receive an email when I am close to having my subscription end or is this something I need to keep an eye on myself?
Also, when you go through checkout it displays the subscription remaining. Can you change this so customers cannot see it at all?
Thanks again.
Although not yet developed, I do hope to have an automated way to send reminders before any renewals are due.Quote:
Originally Posted by pinksugardesign
Comment out LIne 299 of /modules/shipping/ozpost.phpQuote:
Originally Posted by pinksugardesign
This will probably be removed with the next release... The purpose of it is/was to make it a 'bright red flag' so as to help people avoid getting caught out by the changes to the fee structures. Alas, it didn't help with people still using old version of the code.
Cheers
Rod
Just paid subscription. (GAM Mods) Please enable ASAP. If any reason for delay, please advise ETA.
Cheers
Greig
Hi Rod, I've paid for a subscription. Please enable ASAP.
Do I need to upgrade at all, currently running 'ozpost V2.0.6.'
www.giftpackaging.com.au
Restored. Thank you.Quote:
Originally Posted by GAM
Should be ok (long before now).. No, you don't need to upgrade (although it is best if you do, because the latest versions will let you know how long your subs is good for), as well as other bugfixes.Quote:
Originally Posted by giftpackaging
Cheers
Rod
Holler if you still have a problem.
This was the way that we just found out and we're not impressed!Quote:
Originally Posted by annav
Nothing I can about about the way you discovered this, as I have told several others, I don't know who you are or what your email addresses are.. I figured at least 2 software updates and over 60 days notice (where possible) would avoid most people finding out 'by force' (actually this does still hold true, most people were aware long before the fact).Quote:
Originally Posted by Jour
Anyway, I've extended your trial by another month, this should give you ample time to either upgrade (so you don't get caught short again) or possibly consider the other alternatives.
Cheers
Rod
Thanks Rod. It gives us time to review and decide.Quote:
Originally Posted by RodG
Phil.
PLEASE REVIEW THE CONTRIBUTION SUBMISSION REQUIREMENTS:
https://www.zen-cart.com/tutorials/index.php?article=11
Unacceptable Submissions
- It is *not* acceptable to submit crippled modules which are only teasers for paid services. ie: a "limited" module with a sales pitch for a "full featured" commercial add-on is not permitted.
- Having "donate to me" buttons in the add-on, either admin-side or storefront-side or is not permitted. A single statement about where to send donations may be added to the documentation, but should be discrete and not plastered all over the place.
- Connectors to commercial services, such as embedded affiliate links or referral tracking links are not permitted.
- In the interest of protecting the end-user's privacy and identity, any sort of call-home capability is forbidden, whether disclosed or not.
Under GNU General Public License it would be nice to get the “source code” for the server. would you be willing to share that ?.
This module should be removed from the FREE ADD-ON'S if your charging for it ?? dont know how it got passed the zencart team. Are they aware this is not free and you have embedded tracking code. ?
[FONT=Verdana]I read this forum sometimes... it would have been nice to get a 'heads up' on the crash of all my sites...[/FONT]
I am NOT charging for the software. It is 100% free and fully functional.Quote:
Originally Posted by vandiermen
How did the PayPal module(s) 'get past the team', what about any of the many banking modules? The client software is certainly free, but you/we still need to pay for the services.Quote:
Originally Posted by vandiermen
Besides, even if the admins did remove the module, who is that going to harm? Not me, Firstly, I've not much to lose to begin with - Current return on investment = zilch. Expected return on investement if module is removed = zilch.
zilch plus zilch is still zilch no matter how you add it up.
All it will be doing is making it even more difficult for zencart users to find a suitable shipping module for their needs... to me this sounds like a case of just because YOU don't like it, then no one else should have access to it either. Pretty selfish and shortsighted in my opinion. ..
I also trust you are aware that 'ozpost' is no longer a 'zencart specific' module. It is gaining ever increasing momentum among OsC merchants (way more than I ever expected), and from what I have seen and read in forums for other ecommerce sites it will be equally successful with most of them too.
It would be a real shame if it ended up that in a few years time zencart could be the only ecommerce site that doesn't integrate with 'ozpost.net', and I'm sure that will be MY fault too.
Rod
I am getting wrong price for Fastway Satchels is anyone happen the same? or did I do some config wrong?
I tested with my store as in melb and delivery locate in brisbane 4000 and weight of 2kgs... but price always $5.50 with all sizes... (Fastway offer size A2 and A3)
also Fastway don't have satchels cost $5.50 (for melbourne price anyway)
I put "MEL" for FastWay Franchise and FastWay frequent user? YES
Please advice if i did some config wrong or is it the server calculation?
thanks
Hard to say for sure without more investigationing.Quote:
Originally Posted by ks_b
Are you *sure* this is being seen as 2ks and not 2gms? (This is the first most likely cause of unchanging/low quotes.Quote:
Originally Posted by ks_b
This is most likely the $5.45 price (being rounded up to the nearest 10c)Quote:
Originally Posted by ks_b
MEL is correct for the Melb franchise, but a "Frequent user" has a specific meaning for Fastaway customers ... IF my suspicion above is correct (and the 5.50 is a result of rounding) you'll find that if you set the Frequent User to 'no' you will be quoted the higher rate of $10.10 (actual quote is $10.07, but again, it gets rounded up).Quote:
Originally Posted by ks_b
You should be able to verify the Fastaway quotes by entering the same data hereQuote:
Originally Posted by ks_b
If you do find a discrepency please provide a URL to your store so that I can check into it further.
Cheers
Rod
I am refering to the price on this page here http://www.fastway.com.au/RFRatesPDF...r10%5D_web.swf
yes I set in ozpost config to be KGs
if according to the price on fastway calculation page then the price is correct. $5.45 ~ $5.50 <---**edit "no this price is not collect because $5.50 is for local price not national price... I am sending from Melbourne to Brisbane but I am not sure why fastway calculation page show up as $5.45 to $10.07"
but when I try with product that will not fit in A3 size (400x320mm) for example I buy product that size (450x400x50) which it should cost $10.07 for A2 size... but it still shows up $5.50 or if I change weight to 4kgs, it still shows $5.50
Even I did try changing Frequent User to 'no' it still shows $5.50
I havn't upload the store onto sever yet.. it still on localhost.. so I can't give u my site just yet. But calculation for fastway labels and Auspost parcel are collect from what I test though.
after more testing I found things very randomly.. if I change frequent user to "no"... then it will actually show $10.10 but it still disregards the size of the products
and if I set location to that i want to send item to Melbourne 3000 it will not shows satchels price,it shows only labels price.
I then try different postcode in melbourne e.g. Glen waverley 3150.. it doesn't show both labels and satchels for fastway!!
Hi Rod ,
Customers have started email me complaining that they can't checkout as the checkout page is blank.
I checked it and this is the case. The checkout page is completely blank.
When trying to view the page source in Firefox, their is no source displayed either.
I'm assuming it is because I did not have a subscription. I have just done that now.
Do you know how long before my subscription will be active?
Cheers,
Peter.
Hay everybody,
Free Zencart : Australia Post Shipping Module : has been updated and works
http://www.zen-cart.com/index.php?ma...oducts_id=1695
THis works through http://drc.edeliver.com.au (free)
Whereas Rods ozpost works through www.ozpost.net / www.vcsweb.com (no longer free)
:-) :-) :-) :-)
Hey, know you are only trying to help others, but could you please open another thread, or take AustPost discussions back to the AustPost thread(s).Quote:
Originally Posted by vandiermen
This thread is to support those using OZPOST, and not MY OLDER AND NO LONGER SUPPORTED (BY ME) AustPost module(s).
I request this because there has already been way too much confusion in the past about what module people are using, AustPost by Gerrad, AustPost (improved) by me, and ozpost, also by me.
,
THIS IS WHY I GAVE A NAME CHANGE AND CREATED THIS NEW THREAD.
If YOU wish to support my old code you may do so with my blessing, all I ask is that you do so in a forum OTHER than 'ozpost'
Is that asking/expecting too much from you?
Rod
You charge a FEE for use, where there are no fee's other than routing data. Base system for your module is free.Quote:
Originally Posted by RodG
Paypal has international banking costs and insurance, etc.
And paypal is a free module is allot of regards. But yours is in no way free.
You have many clients for webdesign services in australia which you worked on this module for, nice to know they have it free, but you wont give it to others for free.Quote:
Originally Posted by RodG
Zencart is free and you make money from clients paying you for web designs.
... its nice to give something back, or have you forgot that?
Good karma comes from helping. I think your getting a bit of bad karma by "as one of my clients said: "I am more than a little pissed off at being held to ransom by this .... . Where's my refund for lost revenue?".
THere is a free option if people search the contributions.Quote:
Originally Posted by RodG
Thank you for your old code and work. :bigups:Quote:
Originally Posted by RodG
Also created by me.Quote:
Originally Posted by vandiermen
I really don't care if people use this older version, as long as I'm not expected to support it in any way.
Sure you've done 'good' by many people, but at the same time you've also screwed a lot of people over by re-introducing the confusion that reigned a couple of years ago over what modules do what. I can see this is now going to turn into a support nightmare, I hope you are up to it.
Rod
Me neither, but this is almost certainly where things are falling over. The quotes provided by the ozpost server are ultimately derived from the fastway server.Quote:
Originally Posted by ks_b
Aha, the 'penny has dropped' - For some inexplicable reason, the FastWay server always quotes satchel rates even if the parcel is too heavy or large. The ozpost server checks for the parcel size/weight and will hide the satchel rates where applicable.Quote:
Originally Posted by ks_b
Although still only giving local satchel rates rather than national, the example you gave above is actually a valid satchel item.. (A2 size - 455x415 and < 5kg)
Assuming you are using the FastWay.com site for these comparisons, you'll note how it gives a price *range* of $xx.xx to $yy.yy ? Well, what the Frequent User setting does is cause the lowest of these two figures to be used (zencart can't work with ranges). If the Frequent user is NOT set, then the highest figure is used.Quote:
Originally Posted by ks_b
Is it possible that you retireved stale data after making this change? I can't think of much else that would cause this one.
Cheers
Rod
so look like Fastway satchels calculation is not really working properly then...
I am ok to switch to Frequent user to "No" and charge customers $1-$2 more dollars. But when I do that it won't show up Satchels at all for address locally in melbourne. If i do it from Fastway calculation page it shows up local price (therefore I don't think this is a problem of fastway server).... interstate will show $10.10 for all of them regardless of size of products. (which is ok for me)
It would be nice if u can actually fix up fastway probably. I am more than happy to pay for subscription of everything is working correctly, which from what I see most of things do work correctly except Fastway satchels!
When I use known/valid data I am getting the expected results. I DO NOT KNOW what data YOU are sending to the server, and as such I am unable to explain why you are apparently getting different results than I am. If that is indeed the case.Quote:
Originally Posted by ks_b
Rule#1 with ozpost ... USE REAL WORLD VALUES.Quote:
Originally Posted by ks_b
*IF* you are a Fastway Frequent user the SET the Frequent user flag. If you are not a frequent user then don't set it.
The same applies to the TAX setting... IF you are registered for GST then set enable the tax option, if you are not registered, then don't set it.
These are not things to be guessed at, they WILL affect the quotes, but if you need to set somethong 'wrong' in order to get the correct result then there is something else amiss.
Neither do I... I think what it is is that you are entering one set of data on the FastWay server and a *different* set of data for the ozpost module.Quote:
Originally Posted by ks_b
Yes, I know you *think* you are entering the same data, but the results that you are getting is telling me different.
The SIZE or the WEIGHT? They are BOTH relevent.Quote:
Originally Posted by ks_b
To the best of my knowlege, and based on tests and checks using the few figues you have provided, the module is working as it should..Quote:
Originally Posted by ks_b
If you can show me a discepency between the quote provided by FastWay and the SAME quote provided by ozpost, then and only then will I have something to fix.
Please, don't try to 'bribe' me this way, it doesn't help. If you or anyone finds a problem or discrepency then it is a bug, it is wrong, and it needs to be fixed, regardless of whether you are a subscriber or intend to subscribe or not.Quote:
Originally Posted by ks_b
The way you have worded this it can be taken as 'I'm not going to subscribe unless you fix this" - and that places me in a difficult position, because I have no definitive evidence from you to show the problem (and I can't access your server to run any tests of my own), so I am of the position in stating there is nothing I can do to fix it, because it doesn't appear to be broken, and that leaves you still thinking it is broken, even though it isn't, which means you'll have no intention of subscribing, so I can safely put your issue aside for a while and give my next hour of support time to existing subscribers. You may or may not discover what your own problem is by the time I get back to you.
Meanwhile, smartass comments aside, I do still take problems/issues seriously, so if you still wish me to help with this the first thing you need to is show me a discrepency.
To help this (since you server isn't live). Here are a couple of URL you can use for testing/experieming
6kg item melb to brisbane (should show label only , $21.50)
4kg item melb to brisbane (should show $10.10 FastWay Satchel (A5/A2 BLUE) and $17.60 FastWay Labels (ORANGE)
After the above page(s) load, feel free to experiment with the weight and dimension values.
If you DO find a discrepency, please paste the URL into a message so that I can verify for myself (which then means I can actually do something)
The URL to paste should look something like:
http://www.ozpost.net/postage.php?Fa...&version=2.0.9
(This is for the 4kg test) .
Happy hunting.
Cheers
Rod
lol sorry if I blame it on your code! Its probably my false but I just couldn't find what I have done wrong. I will upload the site soon so maybe u could help out in finding problem!
tried to open the links on previous post but it just showing up XML.
Thanks for ur help!
It is human nature to think the code is at fault rather than something we have/haven't. done. Of course, sometimes it IS the code at fault, but I play the odds :-)Quote:
Originally Posted by ks_b
Although not ideal, I don't *need* access to the site to help, it just means I can do a dozen quick test/checks in succession to figure out the cause.Quote:
Originally Posted by ks_b
If you can provide me with the name of your store (as defined under the admin/config settings) I'll be able to check the *last* request made by your store and will be able to report whether the results returned appear correct or not. (The quote server keeps a record of the last request made for this very reason).
If nothing else, I'll be able to verify that the server is recieiving data that you think it is.
Use Firefox (if possible) and the XML will be somewhat readable.Quote:
Originally Posted by ks_b
Failing that, use the 'view source' feature of IE, which will also show you something readable.
Some of the data won't make much sense (Such as the method ID's) but the 'cost', 'days', and 'description' fields will be pretty obvious.. The fastway quotes have an ID of "FWL" for labels, and "FWS" for the satchels. You can ignore pretty much everything else, which will be the Australia Post costings.
Cheers
Rod
Also I play around with your link and it doesn't show fastway stachels price if delivery locally
http://www.ozpost.net/postage.php?Fa...&version=2.0.9
example above sending from postcode 3000 to 3128
regards
OK, I can explain this, but I can't fix it, because it isn't broken.Quote:
Originally Posted by ks_b
Firstly, I assume you entered this same data into the fastway site, and recieved the following quotes as I did, namely. :
------------------------------------------------
Local BROWN/BLACK/BLUE/YELLOW $4.02 to 8.31
Satchel A3 Orange $4.29 *
-----------------------------------------
Now, see how the satchel is size A3? The max length item that will fit into an A3 satchel is 400mm (it is actually a less than that because if the satchel is near full we need to make an allowance so it can be sealed).. Anyway, assume the maximum is 400 ,,, the quote you asked for is for an item measuriing 450mm long - which means the item you are quoting for really won't fit into the satchel, therefore it will not be offered to the customer as a valid option, which is why it doesn't show.
I've no idea why Fastway don't offer A3/A2 as an option in this instance (as they do if it were a national delivery), because the item being quoted will fit into the A2 satchel (just)... perhaps it isn't offered because it is cheaper to use the 'local' rate than the larger satchel rates? Either way, A2 satchels do not appear to be a valid option for local delivery, and ozpost is reflecting this information.
Do you have any other examples?
Cheers
Rod
I tried with minimal size and weight and it still doesn't show satchels price for local....
http://www.ozpost.net/postage.php?Fa...&version=2.0.9
sorry if i am a pain.... just like to find out why it is not showing results as we expected because my client will be using fastway intensively.
thank you
Persistency pays off, I *think* I know what is causing the issue... its because on these quotes there isn't the usual "$xx,xx to $yy.yy" format. I'll need to double check and verify this in the morning (I'm likely to make things worse if I start on it tonight). I'll get back to you on this, meanwhile, no need for you to do any more testing, unless looking for other bugs/problems (its hard to convince me a bug exists, but I do take every report seriously) :-)Quote:
Originally Posted by ks_b
Cheers
Rod
Hi Rod,
i have installed the new OzPost and when I go to the modules page (where I activate modules) I get the following posted at the top of the page.
Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in /var/www/sites/horsemansshop/horsemansshop.com.au/subdomains/www/html/shop/includes/modules/shipping/ozpost.php on line 779
Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in /var/www/sites/horsemansshop/horsemansshop.com.au/subdomains/www/html/shop/includes/modules/shipping/ozpost.php on line 779
Thanks for any help you can offer
Johanne
The Horsemans Shop:oops:
Find the file /includes/modules/shipping/ozpost.phpQuote:
Originally Posted by jld
Delete line 779 (The one that contains CURLOPT_FOLLOWLOCATION).
Save the file, and all should be ok.
Cheers
Rod
My hunch was correct... This is now fixed. (He says waiting for confirmation).Quote:
Originally Posted by ks_b
Thanks for the bug report, much appreciated.
Cheers
Rod
This also turned out to be an important clue to support my hunch, because for safety measures (to protect the merchant) the module will not output a quote for zero, it assumes it is an error (as this time it was), so if toggling the frequent user flag made a diffierence in whether it showed or not (even though there would be no diffference in price) meant that only one value was available.Quote:
Originally Posted by ks_b
Hindsight is such a wonderful thing..
Cheers
Rod
HI Guys
Just got a email saying my ozpost module is about to expire and i need to subscribe well i have 8 carts and for all of them to have to pay 179 each or $5 per cart per month each is a bit expensive. I have been using this for sometime now (free) and now to charge im sorry but that is a joke
Can someone please tell me if there is another module doing the same thing free the same as this one was before someone decided they would make a few bucks off people. Its a good way to get people in let someone install it use it for years then decide to charge them.
The smart folk in this position have contacted us privately and have been given very good deals.Quote:
Originally Posted by uniqueliving
We used to get the daily paper for a while for free too, but like most freee offers, eventually they run out.Quote:
Originally Posted by uniqueliving
Odd thing is, I was always GREATFUL for when it was free. Not once did I consider it to be my god given right.
No, what is a joke is expecting me to provide the support and services for the rest of eternity at the same time as I'm struggling to meet daily expenses.Quote:
Originally Posted by uniqueliving
Yes, an older module of mine has been re-released (by someone without much vision). Not as functional as the current ozpost, but it doesn't connect to the ozpost.net servers (which means no fees to pay).Quote:
Originally Posted by uniqueliving
Yeah, with only a few dozen active zencart merchants in Australia I'm going to make a real killing out of this one.Quote:
Originally Posted by uniqueliving
As I've said many times in the last couple of months... it is either charge for the service or close the service fown.. Even now I'm on the borderline of deciding whether I wish to continue the support, development and maintanence of the servers, and code, or whether to make it easy for myself and pull the plug... As I;ve also said, the number of active merchants is quite low, the number of paid susbsribers even less, full refunds are still possible, without hardship... and the only losers - The merchants that currently rely on the module.Quote:
Originally Posted by uniqueliving
I do acknowldge that if I shut shop someone else will possibly take up where I've left of, but what if they don't? The *original* zencart/austpost code was broken for at least 6 months before I took it upon myself to fix, and since then it has come a LONG way into supporting more than just the basic parcel rates, but if you wish to revert back to the code that I've already decided is too unreliable and too inefficient for a serious merchant then fine, take that risk, but do so knowing that it doesn't harm me in any way, but it does place the current servers and support for other merchants at risk.
Anyway, it is entiely your choice what you do, and I promise, when I make my millions I'll make the service free again, ok? Meanwhile I do need to eat, sleep and breath.
Regards
Rod
I am completely over this, we use several modules for our Zencart, none receive the support that OzPost does. Why should anyone expect that for free. Get over it people, there are many other things that merchants end up paying for to use with/in their Zencart. I am tired of seeing people complain and complain about this change, it is clogging up my inbox. I bet the ones that complain have used Rod's time in the past for free! You cannot expect this module and support for nothing, that is unreasonable and you have had it good for this long. Now is the time to own up and decide if it is worth buying if not go somewhere else, but don't waste our time complaining about it!
Jazzah
previous and current OzPost user who appreciates the support (even if it sometimes has a sarcastic tone, which I hope with gleaning an income will also improve! lol)