The system will require a default shipping method, so when the customer visits their basket, they see shipping costs calculated based off the default method.. We should store the followi
Trang 1The system will require a default shipping method, so when the customer visits
their basket, they see shipping costs calculated based off the default method There
should be a suitable drop-down list on the basket page containing the list of shipping
methods; when this is changed, the costs in the basket should be updated to reflect
the selected method
We should store the following details for each shipping method:
An ID number
A name for the shipping method
If the shipping method is active or not, indicating if it should be selectable by
customers
If the shipping method is the default method for the store
A default shipping cost, this would:
Be pre-populated in a suitable field when creating new products; however, when the product is created through the administration interface, we would store the shipping cost for the product with the product
Automatically be assigned to existing products in a store when a new shipping method is created to a store that already contains products
This could be suitably stored in our database as the following:
ID Integer, Primary Key,
Auto Increment ID number for the shipping method Name Varchar The name of the shipping method
Active Boolean Indicates if the shipping method is active
Default_cost Float The default cost for products for this
shipping method
This can be represented in the database using the following SQL:
CREATE TABLE `shipping_methods` (
`ID` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`name` VARCHAR( 50 ) NOT NULL ,
`active` BOOL NOT NULL ,
•
•
•
•
•
°
°
Trang 2Shipping costs
There are several different ways to calculate the costs of shipping products
to customers:
We could associate a cost to each product for each shipping method we have
in our store
We could associate costs for each shipping method to ranges of weights, and
either charge the customer based on the weight-based shipping cost for each
product combined, or based on the combined weight of the order
We could base the cost on the customer's delivery address
The exact methods used, and the way they are used, depends on the exact nature of
the store, as there are implications to these methods If we were to use location-based
shipping cost calculations, then the customer would not be aware of the total cost of
their order until they entered their delivery address There are a few ways this can be
avoided: the system could assume a default delivery location and associated costs,
and then update the customer's delivery cost at a later stage Alternatively, if we
enabled delivery methods for different locations or countries, we could associate
the appropriate costs to these methods, although this does of course rely on the
customer selecting the correct shipping method for their order to be approved;
appropriate notifications to the customer would be required to ensure they do
select the correct ones
For this chapter we will implement:
Weight-based shipping costs: Here the cost of shipping is based on the
weight of the products
Product-based shipping costs: Here the cost of shipping is set on a per
product basis for each product in the customer's basket
We will also discuss location-based shipping costs, and look at how we may
implement it To account for international or long-distance shipping, we will
use varying shipping methods; perhaps we could use:
Shipping within state X
US shipping outside of state X
International shipping (This could be broken down per continent if we
wanted, without imposing on the customer too much.)
•
•
•
•
•
•
•
•
Trang 3Product-based shipping costs
Product-based shipping costs would simply require each product to have a shipping
cost associated to it for each shipping method in the store As discussed earlier, when
a new method is added to an existing store, a default value will initially be used,
so in theory the administrator only needs to alter products whose shipping costs
shouldn't be the default cost, and when creating new products, the relevant text box
for the shipping cost for that method will have the default cost pre-populated
To facilitate these costs, we need a new table in our database storing:
Product IDs
Shipping method IDs
Shipping costs
The following SQL represents this table in our database:
CREATE TABLE `shipping_costs_product` (
`shipping_id` int(11) NOT NULL, `product_id` int(11) NOT NULL,
`cost` float NOT NULL, PRIMARY KEY (`shipping_id`,`product_id`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;
Weight-based shipping costs
Depending on the store being operated from our framework, we may need to base
shipping costs on the weights of products If a particular courier for a particular
shipping method charges based on weights, then there isn't any point in creating
costs for each product for that shipping method Our framework can calculate the
shipping costs based on the weight ranges and costs for the method, and the weight
of the product
Within our database we would need to store:
The shipping method in question
A lower bound for the product weight, so we know which cost to apply to
a product
A cost associated for anything between this and the next weight bound
•
•
•
•
•
•
Trang 4The table below illustrates these fields in our database:
ID Integer, primary key,
Auto increment A unique reference for the weight range Shipping_id Integer The shipping method the range applies to
Lower_weight Float For working out which products this weight
range cost applies to Cost Float The shipping cost for a product of this weight
The following SQL represents this table:
CREATE TABLE `shipping_costs_weight` (
`ID` int(11) NOT NULL auto_increment,
`shipping_id` int(11) NOT NULL,
`lower_weight` float NOT NULL,
`cost` float NOT NULL,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
To think about: Location-based shipping costs
One thing we should still think about is location-based shipping costs, and how we
may implement this There are two primary ways in which we can do this:
Assign shipping costs or cost surpluses/reductions to delivery addresses
(either countries or states) and shipping methods
Calculate costs using third-party service APIs
These two methods have one issue, which is why we are not going to implement
them—that is the costs are calculated later in the checkout process We want our
customers to be well informed and aware of all of their costs as early as possible
As mentioned earlier, however, we could get round this by assuming a default
delivery location and providing customers with a guideline shipping cost, which
would be subject to change based on their delivery address Alternatively, we could
allow customers to select their delivery location region from a drop-down list on the
main "shopping basket" page This way they would know the costs right away
•
•
Trang 5Regional shipping costs
We could look at storing:
Shipping method IDs
Region types (states or countries)
Region values (an ID corresponding to a list of states or countries)
A priority (in some cases, we may need to only consider the state delivery
costs, and not country costs; in others cases, it may be the other way around)
The associated costs changes (this could be a positive or negative value to
be added to a product's delivery cost, as calculated by the other shipping
systems already)
By doing this, we can then combine the delivery address with the products and
lookup a price alteration, which is applied to the product's delivery cost, which
has already been calculated Ideally, we would use all the shipping cost calculation
systems discussed, to make something as flexible as possible, based on the needs
of a particular product, particular shipping method or courier, or of a particular
store or business
Third-party APIs
The most accurate method of charging delivery costs, encompassing weights and
delivery addresses is via APIs provided by couriers themselves, such as UPS The
following web pages may be of reference:
http://www.ups.com/onlinetools
http://answers.google.com/answers/threadview/id/429083.html
Using such an API, means our shipping cost would be accurate, assuming our
weight values were correct for our products, and we would not over or under
charge customers for shipping costs One additional consideration that third-party
APIs may require would be dimensions of products, if their costs are also based on
product sizes
Shipping rules rules
Hopefully by using product and/or weight-based shipping methods, we can
provide accurate shipping costs; however, some couriers cap their shipping costs
•
•
•
•
•
•
•