Quote Originally Posted by ks_b View Post
the problem ozpost having is the local delivery because it has 4 different colours (blue, yellow, black, brown) (that's why fastway calculation page show them all together) and each colour represent how often the user use fastway in a month. hint the more you use the cheaper it get.

if you looks at melbourne for example if you use min of 200 each month then you only have to pay $4.02 each label, min 100 then $5.61 and so on...
OK, this makes sense, but is cerainly doesn't make it *easy* because there is no way to know what price any particular merchant is on (TNT overcome this by requiring an account number to be passed along with the other parameters so that 'personalised' quotes can be given).

Quote Originally Posted by ks_b View Post
Suggestion...
I think only way you can do this is you have to put in the price of each label manually,
Hmmm, wouldn't this need to be done by the merchant? (How would I make the code 'know' what each merchant pays for thier labels?)

Quote Originally Posted by ks_b View Post
I can see this is not too difficult as in ozpost user can select what label they want to use.... therefore if user select blue then they should have brown, black, yellow turned off and when fastway return (blue/yellow/black/brown) you can then check which colour option user selected and use that price.
The downside to this proposal is that it is tossing the maintenance back to the client in that they'll need to ensure their label prices are kept accurate, and one of the principles behind ozpost is that the merchant shouldn't need to worry themselves about price changes, as it is supposed to be handled by the server.

Quote Originally Posted by ks_b View Post
Now the hard part is that different local has different prices... so to make ozpost work perfectly, you probably have to input all the price for different location.. you can look number of location here http://www.fastway.com.au/1Prices.html
Although this is possible (and I would suggest, in time, even probably the way to go, as it would make us independent of the FastWay server). At this stage though I think it is going to take a lot more work rto do this than the project deserves.

Quote Originally Posted by ks_b View Post
good news is black and brown for all the location is the same price.
and blue is always quote correctly because it's the price for non frequent user.
only problem is yellow which I think you can just average it and it should be really close enough for all ozpost customer to be happy :)

I will need to do abit more research with satchel and i will let you know.

Hope this help.
It has helped in as much as confirming what I had expected, and that is, to take care of the issue I pretty much need to scrap using the FastWay servers and create/use our own table rate instead... At least that is what *I* have picked up from your suggestion (If I'm wrong, please try again).

I was hoping for some way to take care of the issue by utilising the data that is readily available from the FastWay servers, and then modifying it in some way to compensate for the shortcomings..

One thing I might suggest is that you use the "Frequent user" option with care because this will always return the lowest quote that it can. I am of the opinion that a merchant should charge the customer non frequent user prices anyway... if a merchant has earned price reductions for any reason they aren't really obligated to pass the savings on. The end consumer may not even know.

One last question... with the Erronious FastWay quote/options - are they in favour of the merchant of the customer? If the merchant, then perhaps we can ignore the problem... if it is underquoting though I will do almost anything I need to in order to prevent this from occuring.

Cheers
Rod