Forum Moderators: buckworks
example we sell many types of widgets... some are large and some are small over 100k widgets in our system.
We currently have rates based on the weight of each item with a minimum shipping of say $5.00. Right now if a customer orders ten of the same widget the shipping currently totals the $5.00 x 10 .. which is way too high.
Our sales people can discount it on the fly if the customer calls in, but if they do it online the shipping rate just stacks up.
Has anyone found a good calculation for this?
like ..
1 item = base rate
2 items = (base rate + base rate) / 20%
3 items = (base rate + base rate + base rate) / 30%
i'm just using that as an example.
We currently have rates based on the weight of each item with a minimum shipping of say $5.00.
You currently compute shipping charges so as to discourage large orders. Shipping is cheap on one or two items, but outrageous on 100 items. Why not compute shipping on the total value or number of products or total weight like almost everyone else does? You could still have a minimum of say $5, or better yet more.
We do everything we can to discourage tiny orders and reward big ones. Shipping is the hard part of ecommerce.
Is this off-the-shelf, giving you limited control over the programming, or custom programmed?
If you coded it yourself, the ease at which you apply this depends on how well, or poorly, you've laid the groundwork for the shipping calculation.
We currently have rates based on the weight of each item with a minimum shipping of say $5.00.
I am presuming you have a place in your database with each item's shipping amount. I would have done this differently; I enter the actual weight of the item, then after a fairly complex calculation, pass the total weight of the order and expected package sizes to the shipper's API. The allows their rates to fluctuate without constantly adjusting the price of all my items. But let's move on based on my first assumption.
You say "minimum $5" so I'm presuming lighter items all have "5.00" in each field. So first, you need to update all those items so they reflect a closer approximation of the "shipping amount" for each item, that is,
Really-Light-Bracelet: 0.75
So when you do your calculation,
$min_charge=5.00;
$num_items = 0;
($item_shipping is a list of the shipping for each item)
foreach ($item_shipping as $ship_charge) {
$num_items++;
$total_shipping+=$ship_charge;
}
$total_shipping = ($total_shipping > $min_charge)?$total_shipping:$min_charge;
The previous means: if $total_shipping is greater than $min_charge, use that, otherwise use the minimum.)
Note that this, in itself, will nearly eliminate your problem without discounts.
With that out of the way, note how I've compiled $num_items, using your "num items" example. You could also do this if the order is over a certain dollar amount. So,
$break_limit = 10; // # of items at which you break
$percent_off = 10; // As a whole number, 10 percent, easier for customer (both your client and the shopper) to understand
$actual_percent = $percent_off/100; // now, .10
if ($num_items >= $break_limit) {
$orig_shipping=$total_shipping;
$total_shipping = $total_shipping - ($total_shipping * $actual_percent);
//(Better: $total_shipping -= ... above is for clarity)
print "Shipping: \$$total_shipping, $percent_off normal shipping of \$$orig_shipping for over $break_limit items. What a deal!";
Sadly, if you have all the item shipping coded into the database, this is a problem with the way and intent it was built, and this indeed brings you back to square one on your shipping piece.
You will have to update all the shipping charges in the database for all those over-priced items. What you (and I would probably) might be able to do is automate the process; have the client build a spreadsheet containing item number and new shipping charges for each item, export it as a .csv, then write a scriptlet to import the .csv and update the database items.
The really good news here - and another fork you should probably take, if you're changing these database items - is to make these fields represent the weight of the item, not a shipping charge. Then, as I mentioned, you can interface with the shipper's API to get a real-time price, and you won't have to mess with it again. Note that this only applies to USPS as is; if you use UPS, UPS needs the dimensions of the final package(s,) so you'd need to send package width, height, and length as well, which involves adding and entering database fields. It ain't pretty for this project. :-)
Too often we allow customers to steer us into the wrong direction. I can hear (and have heard) it now. "Nah, we don't need any of that, just make it so I can enter shipping charges for each item." (The reasons for this can vary, but most of the time, it's either ego or a "tight budget.") As you become more and more experienced, you learn how to tell them when they are stepping into a Very Bad Idea.
