Thanks guys, yes in general we will go with a lookup for each country, it wont be accurate but in future we can build rates for each province / state for each country which an admin would have to complete for each product (time consuming) but for now the solution will work. Thanks for the responses and thoughts, they are much appreciated. I see the UPS class is also quite interesting but its only if you using them :) Cheers Angelo -----Original Message----- From: Jochem Maas [mailto:jochem@xxxxxxxxxxxxx] Sent: 19 January 2010 04:53 AM To: Angelo Zanetti Cc: 'php-general' Subject: Re: integrating shipping with shopping cart site - OT Op 1/18/10 10:47 AM, Angelo Zanetti schreef: > Hi all, > > We are about to start a new project. Custom written shopping cart - quite > simple actually. However we have a concern when it comes to calculating the > shipping cost for an order. > > For each product we can determine the base cost based on weight, therefore > we can determine the total weight of an order. > > However we are struggling to determine how to calculate the shipping based > on where the delivery is going. > > In terms of DB and PHP would the best way to calculate it be done by having > a list of countries to ship to and a rate for each? Then you can apply the > rate to the current order (calculate according to the order weight). > > Problems arise when shipping to different parts of a country EG: > > New York vs California (quite far apart). Perhaps we should have a list of > cities but that could be massive? > > I know there is a PHP class / system that integrates with UPS but I don't > think the client is going to use UPS. > > Perhaps you can tell me how you have handled this issue in the past. > > Apologies if it is slightly off topic but it does still relate to PHP > indirectly. I'd start with defining shippingcost 'sets', each defining a number of costs by weight bands, some 'table defs': set: --------- id name set_bands: ---------- set_id upper_weight cost then it would be a case of linking (many-to-many relation) 'regions' to sets, if you approach this with a tree of regions you can effectively set values at a continent, country, state/province level ... as such you would only need to relate a 'shippingcostset' to a state if the shippingcosts are different to the given country's shippingcosts. world - north america - california - south america - europe - france - UK then your left with the problem of determining the smallest defined region a given address physically falls into .. using geo-spatial magic in the DB would be one way to do it. this is a hard problem (unless, maybe, the client is willing to sacrifice precision and instead using highly averaged shipping cost definitions to cover the real differences in costs - i.e. a fixed fee for all of europe, whereby such fee is just above the average real cost the client pays for shipping). my guess would be that building such a thing is hard, and would take lots of time ... best bet is to hook into the webservice of whatever shipping company the client intends to use ... even if you have to build your end of the webservice from scratch it will be many factors less hard that building a user-manageable, shipping cost algorythm. - sorry it's all a bit vague, I'm very tired :) my eyes are starting to bleed. > > Thanks in advance. > Angelo > > > http://www.wapit.co.za > http://www.elemental.co.za > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
