I have setup ubercart with USPS Shipping method. The problem is that it is not sending dimensions (length, height, width) to USPS therefore USPS is returning all the rates available for the package and its weight.

The package dimensions are 8x6x1 inch. Therefore it should return U.S.P.S. First-Class Mail Parcel, U.S.P.S. Parcel Post and U.S.P.S. Priority Mail but it is instead returning all that was listed before plus U.S.P.S. First-Class Mail that is incorrect. See USPS dimensions at this link http://www.usps.com/prices/first-class-mail-prices.htm

So I started playing with different dimensions to see if the size in the xml would change from Regular to Large. I entered 30x30x1 inch and it change to LARGE but it failed with the following error Dimensions are missing for Large Priority Mail. It seems that the dimensions LengthxWidthxHeight can be passed in the request but it is not being passed at all (http://www.usps.com/webtools/htm/Rate-Calculators-v2-3.htm). I wonder if passing the dimensions would fix my problem and return the right setting of shipping rates when dimension is 8x6x1 inch

API=RateV3&XML=ALL800208002002.6RECTANGULARLARGEFalse
<?xml version="1.0"?>
-2147219426DomesticRatesV3:clsRateV3.ValidateDimension;RateEngineV3.ProcessRequestDimensions are missing for Large Priority Mail.1000440

Comments

adamo’s picture

Check out the uc_usps_rate_request function in uc_usps.module. The dimensions are not included in the request XML. It looks like it would be pretty easy to add them. According to the USPS docs you linked to, dimensions are optional except:

Required when RateV3Request/Service contains one of the PRIORITY variants and RateV3Request/Size is LARGE.

gtin’s picture

Tahnks @adamo for the reply.

I did change the code to pass the dimensions as part of the XML request and this did not affect the outcome result. I would still get First Class Mail in the response when I would expect to see only First Class Mail Parcel because of the dimensions of the package. I am not sure what to do from here. I started using Flat Rate module instead of the USPS module as a solution for now. It seems that for a package that has more than 3/4 inch in height/thick should not the a First Class Mail rate unless it is First Class Mail Parcel. Not sure what I am doing wrong. This is what I added in line 450 of uc_usps module to test it:
/* ''. $package->width.''.
''. $package->length.''.
''.$package->height.''.
''.$package->girth.''.
*/

I am sure I made more changes since those properties I believe were not part of the package class. Anyways, I could not get this to work even though the request had all the dimensions tag with the right values.

TR’s picture

Status: Active » Closed (works as designed)

As @gtin said, USPS does not filter services based on the dimensions. In particular, if you send USPS dimensions that are greater than 3/4" thick it will still return a First Class Mail (letter) rate. So it would be up to Ubercart to 1) KNOW all USPS restrictions, 2) Keep up-to-date with all changes in these restrictions, and 3) Implement an algorithm to determine exactly which box size (USPS pre-printed or your own custom packaging) to hold all the products in your order. #3 is not a solvable problem except in a highly restricted problem domain.

To get the rates you want you'll have to make creative use of all the tools Ubercart already provides. Namely, package quantity, packaging strategy (all in one or each in its own), package type, shipping type, product classes, conditional actions, restrictions on USPS shipping services, rate markups and weight markups. Don't forget the flatrate and weightquote modules too. Shipping quotes are really only a tool to help you decide what to charge your customer - the charge is purely a business decision and doesn't necessarily have anything to do with actual cost (e.g. free shipping for purchases over $100). The USPS module allows you to make a very good estimate of the actual costs, but it would be literally impossible to be exactly correct all the time. So if your goal is simply to not lose money on shipping, adjust your markup so that on average you're collecting enough to cover your costs (which again, are not just the postage cost but include cost of boxes and packaging material.)

j0rd’s picture

Here's another issue which may be causing higher than expected shipping prices with USPS
#1134012: USPS "All in one" Product Packaging Not Working?

For me though, the above issue is not my problem, but this issue is. The problem my client is having is regarding USPS and Envelop shipping method always showing up for international orders. Now they've disabled "envelopes" and "small packages" to avoid international orders from choosing these, as they are always the cheapest, but rarely can fit the orders. The problem is, for small orders, say a single book purchase, which can fit in an envelope, now the only option to get this shipped to the customer is a $36 shipping option instead of a $12 envelope.

This is really USPS's fault for not filtering and @TR's comments and suggestions in #3 make sense and would get this process started.

--- HOW CAN WE MAKE THIS BETTER

I do think that Ubercart could add a very important heuristic to Conditional Actions to help site owners decided which shipping options is best though. This would be "Order Volume" and "Order Dimensions".

I'm trying to wrap my brain (i'm not longer good at algorithms) about the best way to deal with this would be, so suggestions are welcomed and feel free to call me an idiot.

I've done a quick google and seems other open source carts have found a good class to deal with this problem. The algorithm we need is "Knapsack" or "np-complete" I believe.

http://forum.opencart.com/viewtopic.php?t=30319

Which links to this public domain code here, which helps us add up dimensions of individual items and add them into the smallest appropriate box options available.

Here's the PHP class:
https://github.com/yetzt/boxing

Something like this would be a wonderful addition to Ubercart's Shipping functionality, if there's nothing integrated already. Then opening this up to shipping modules and conditional actions would solve the problem we are currently facing with USPS and other modules which don't do this themselves.

Site administrators could define box sized in the admin, if shipping modules made this available. Ubercart via this "boxing" class which is the smallest combination of boxes to allocate to a shipping quote and ask for a price. Ideally the shipping modules would provide adequate defaults for each box, but site administrators would have the ability to update them, should they change. Ideally if they changed, these changes could be applied back into the module and proper defaults would persist.

@TR, if you could chime in on this it would be helpful.

Even with this algorithm in place, Ubercart would still need a little bit of logic in determining which is the best combination of boxes to go for.

Perhaps the best way to go about it, is to just provide a conditional action for "Items fit in box", then do the calculation on the items and return yes or no. This would at the very least solve the problem I'm having with USPS and Envelopes.

TR’s picture

I've been working to address this. http://drupal.org/project/packaging
I am integrating this into uc_fedex and uc_canadapost first.

j0rd’s picture

Also it appears we're never sending dimension information with USPS Domestic, even though it seems to be required when "size" != REGULAR.

Also it appears we've hardcoded size for international rates to REGULAR, even though the documentation states

REGULAR: Package dimensions are 12’’ or less;
LARGE: Any package dimension is larger than 12’’

Here's the documentation reference I am using.
https://www.usps.com/webtools/htm/Rate-Calculators-v1-3.htm#_Toc281821309

Not sure if these are relevant, but just some discrepancies I've noticed looking at the API and documentation.

j0rd’s picture

@TR #5, Interesting, I'll take a look.

-- UPDATE: Just took a look at the code and it looks lovely. Good job on tackling this problem. Look very elegant and it will be useful for both Ubercart & Drupal Commerce, hopefully unifying the packaging problem between both solutions. That'll make everyone's life easier.

One thing I noticed, is that both the "classes/" and "stragegies/" folders don't contain any Drupal specific code. If we could keep it that way, it would allow a port to Drupal 6 fairly easy. It would also make a port to other non-drupal eCommerce platforms quite easy (not that I care about this).

Another item I noticed that might help separate Ubercart and Commerce code a little better, would be to create a sub-class of `PackagingProduct` for Ubercart & Commerce then change the constructor in each. Not really important at this stage in development, since I think you're just working on this personally right now, but in the future, someone on the Commerce team, could maintain their sub-class.

Taking a look at uc_canadapost 7.x-3.x now.

TR’s picture

Re: #6
The USPS is a mass of spaghetti code right now, and can't deal with box types and sizes properly without refactoring. USPS is making a change to their API on 22 Jan (although they haven't published the new API yet ...) so I'll be looking into some of these issue when I modify the module to deal with the new API.

Re: #7
uc_canadapost 7.x-3.x isn't working 100% right now - I'm using that branch as a testbed to experiment with how to integrate the packaging module with shipping modules. We should move any further discussion of this into the packaging module issue queue: http://drupal.org/project/issues/packaging

sander-martijn’s picture

Version: 6.x-2.0-rc6 » 6.x-2.9
Status: Closed (works as designed) » Active

I'm setting this back to active because this is not fixed. It is a huge problem inasmuch as it doesn't quote even close in some cases, so "works as designed" is not a fair assessment.

If you have an oversized box that you want to ship internationally, you cannot use the normal international shipping. You have to use Global Express Guaranteed. Even though we have GXG enabled, since it is quoting only on weight it uses standard international shipping and quotes ~$83 (in the case of the product we discovered this bug on, which is very large but only weighs 12lbs) when the actual cost to ship it is more like $350. That is a huge discrepancy.

From our conversations with USPS this has been fixed on their end (and post #8 states that the new API was released almost a year ago), so I think this should be revisited. Dimensions should be included when requesting quotes from USPS, to get as accurate of a quote as possible.

I cannot find any way through conditional actions to override this, or I would do it on a case by case basis (my client only has a few products that fall into this problem).

Another solution to this problem would be to enable administrators to set the available shipping options per product - this way we could just state that ups (which we don't have enabled for international) and GXG are the only shipping options for that particular product. This is also an acceptable solution and something I believe should be available anyway.

I'm curious about TR's module, but unfortunately it is only for D7 and I need a D6 solution.

DanZ’s picture

Version: 6.x-2.9 » 6.x-2.x-dev

It should be possible to set up individual flat rate shipping quotes for each product, and use conditional actions to make sure that those quotes appear as appropriate. This bypasses the USPS module, of course.

Ubercart 2 will only be supported until Drual 8 comes out, so there may be some reluctance to do this. You may wish to sponsor or hire a developer to get this implemented quickly.

longwave’s picture

Status: Active » Closed (duplicate)

Pretty sure this is the same as #1364508: USPS error: Dimensions are missing for package; unable to calculate postage. - there are some code changes in comment #3 in that thread that you might like to try. Followups should be posted in that issue, unless you are sure this is something different.

TR’s picture

Yeah, I don't see how this can possibly be addressed without something like the Packaging module. In general, it's simply not possible to determine package dimensions in a meaningful way. The best we can hope to do is provide a mechanism for doing this in restricted cases, should it be important for your use case.