10 / 10
Dec 2010

We use a flat rate shipping for the total of the cart ( $1-75 = $7, $76-100 = $15, etc.) this works fine for the us 48 but we need to add a 50% more to the shipping total for Alaska and Hawaii. Is there a way to do this?

  • created

    Aug '09
  • last reply

    Dec '10
  • 9

    replies

  • 1.2k

    views

  • 3

    users

  • 3

    links

The only state/zipcode-based shipping we can support would use our standard USPS postal rate-lookup feature; we have no way of using zipcode to affect shipping calculation otherwise.

1 year later

Yes, but for some reason the USPS postal rates for Alaska and Hawaii are way off. Why is this? Have you done testing to verify the accuracy of the USPS postal rates for the noncontiguous states? The rates for the contiguous states seem accurate.

For USPS rates, we simply pass the order's total weight and number of separate packages to the USPS.com live rate-lookup API and take whatever rate they return for that query.



If the rates for AK/HI seem too high, it may be because the Packaging Type and Capacity you assigned in each product's settings are causing us to tell the rate API that you are sending more separate parcels than you really are, as it costs more to send any given weight divided into more parcels vs. fewer. Products configured to use the same Packaging Type can share unused Capacity in each other's packages to consolidate shipping into fewer parcels for the sake of rate calculation.



BTW, the post you replied to was made just before we rolled out a new, more flexible Shipping Calculation feature which we are using currently, announced here:

http://www.e-junkie.com/bb/topic/3656

...and as explained in more detail on our current help page for Shipping Calculation here:

http://www.e-junkie.com/ej/help.shipping.htm

No, the rates for AK/HI are way too low. I think you will find if you compare USPS rates that E-Junkie uses vs. actuals that there is definitely something off. How can a rate be accurate rated for every contigous state in the US and be off by 100% for HI? Just doesn't compute. Try it for yourself.



I did apply a different rate for AK/HI using shipping rules as described here:



http://www.e-junkie.com/bb/topic/3719/pg/0/?s1=3e90a8&s2=b8274b6d#post16269



So, I'm ok with this solution.



thx.

We haven't been able to reproduce any discrepancy with USPS rates for HI or AK in our cart vs. what we looked up on USPS.com manually. If you could provide more details about the shipment where you saw the discrepancy -- e.g., total weight, number of separate parcels, origin and destination zipcodes, we can try to reproduce any problem with that exact scenario, which may allow us to generalize enough to figure out what caused the problem.

Shipping to and from: 92121 to 96734



Packaging: Regular box, 4oz box and $2 for box



Handling: 7% of shipping



Product Weight used in E-Junkie: 60oz



Prior to setting up a rule, E-Junkie charged my customer $18.51. I had it setup using USPS Cheapest Service. The cheapest option was USPS Parcel Post at $34.44. The actual weight of the package is 30lbs. The package dimensions are 21in x 7in x 33in.



I would generally ship using FedEx Ground. The rate of $18.51 is accurate for shipping to the east coast using this service. But for shipping to Hawaii, the cheapest FedEx rate is $81.73.



Basically, the way I set up my shipping was I adjusted everything to match quite accurately the rates I'm charged from FedEx. Shipping outside of the contigous states and the shipping calculation goes out the window. My guess is there is a hang up with weight and package size.



So I setup a shipping rule for $0.40/oz for AK and HI. This gets me much closer.



Like I said before, in general, my shipping charges are quite accurate. So what I'm doing can't be too wrong.



thx.

Our USPS Cheapest rule only compares First Class vs. Priority Mail; it does not include Parcel Post or Media Mail (although you can set up Rules for those separately). This is actually a legacy holdover from before we had the more flexible Rules-based shipping calculation settings we have now, so that sellers who had things working as they wanted under the old system could keep their existing setup working as-is without having to add or change anything. All our USPS rate calculators would obtain their Package rate (rather than Envelope or Large Package, since we have no way of passing parcel type/size to the USPS rate API).



I looked up a rate manually using the postage calculator at USPS.com, for 60 oz. being shipped from 92121 to 96734; that is too heavy for First Class, so the Priority package rate it returned was $15.30 (Parcel Post would be $11.57). Add $2 for your box cost and add 7% handling = $18.51, so that does appear to be accurate for the Package rate going by USPS Priority Mail.

The problem is the dimensions. When you enter the dimensions I get a quote from USPS of $54.28 for Priority and $25.70 for Parcel Post. I realize that the E-Junkie system does not acquire rates based on package size. Which is where the problem lies.



I'm fine with creating the shipping rule. On a side note. When trying to create a shipping rule, it seems odd that you have to click "next". Why "next"? Why not "Shipping Rules"? I know that means you have to create a new button graphic. "Next" just doesn't make sense which is why I forgot it was there.



Thanks again for the help Tyson.

I can only guess at Development's reasons for choosing that Next button, but I reckon it was to make apparent there's another screen of settings, just like the Next button in product settings. I agree it's a bit confusing in other ways, such as the fact that clicking Next in that case actually does save all changes on that first screen, whereas everywhere else the Next button doesn't save changes until you get to a Submit button that does, and the Submit button on the Rules screen only saves a new Rule. It would also have been better yet to have all the Shipping settings together on one, big screen rather than splitting it into two, but we were limited to the size of the Flash-based interface we already had.



At any rate, we've already been working on an HTML-based replacement for our current Flash-based Admin, so that will resolve many of our current usability concerns and allow ongoing updates, tweaks, and enhancements to the Admin interface much easier for us to implement quickly and more frequently. While the Flash approach was great for our Founder to develop a slick, attractive interface from scratch six years ago, it's become long in the tooth and increasingly challenging to modify at all, which is why we've been leaving the current Admin as-is and rolling all new features and interface fixes into the new Admin project.



Long story short: many good things are in the works that will come out all at once when the new Admin goes live soon, so thanks for sticking with us -- we'll make the wait worthwhile. :^)