USPS shipping quotes work great, but do not allow for any package type other than Variable, which means users can check out, select the incorrect or cheapest shipping option, and the store loses money on the entire sale.

A customer can select a flat rate shipping option that is too small for the product and thus when the business owner fulfills the order, they lose money because they have to package it up and ship it using a different rate box.

undefined:
LG FLAT RATE BOX is an invalid container type for a REGULAR package and ONLINE service.

API=RateV4&XML=<RateV4Request USERID="609CUFFS1364">
<Revision>2</Revision>
<Package ID="0">
<Service>ONLINE</Service>
<ZipOrigination>95816</ZipOrigination>
<ZipDestination>95841</ZipDestination>
<Pounds>10</Pounds>
<Ounces>0.0</Ounces>
<Container>LG FLAT RATE BOX</Container>
<Size>REGULAR</Size>
<Machinable>True</Machinable>
</Package>
</RateV4Request>

<?xml version="1.0"?>
<RateV4Response>
<Package ID="0">
<Error>
<Number>-2147219407</Number>
<Source>DomesticRatesV4;clsRateV4.ValidateContainer;RateEngineV4.ProcessRequest</Source>
<Description>LG FLAT RATE BOX is an invalid container type for a REGULAR package and ONLINE service.</Description>
<HelpFile></HelpFile>
<HelpContext>1000440</HelpContext>
</Error>
</Package>
</RateV4Response>

Comments

rickupdegrove’s picture

Issue summary: View changes

Removed duplicate ISSUE SUMMARY

TR’s picture

Version: 6.x-2.6 » 7.x-3.x-dev
Category: bug » feature
rickupdegrove’s picture

Thank for for confirming it works as intended so quickly.

Reading through endless posts about this problem with USPS in general, and reading the source of
sites/all/modules/ubercart/shipping/uc_usps/uc_usps.module specifically this function below, it looks like it might be able to be "worked around" somehow but I can't seem to figure it out.

/**
 * Convenience function for select form elements.
 */
function _uc_usps_pkg_types() {
  return array(
    'VARIABLE' => t('Variable'),
    'FLAT RATE BOX' => t('Flat rate box'),
    'LG FLAT RATE BOX' => t('Large flat rate box'),
    'FLAT RATE ENVELOPE' => t('Flat rate envelope'),
    'RECTANGULAR' => t('Rectangular'),
    'NONRECTANGULAR' => t('Non-rectangular'),
  );
}

It seems that code was there for a reason at some point. So I matched the option LG FLAT RATE BOX to latest USPS Techical Guide, and and it is a valid definition, but the error:
LG FLAT RATE BOX is an invalid container type for a REGULAR package and ONLINE service.
seems to indicate this can be worked around somehow.

If not, and that function never worked thats fine I will ignore it. However perhaps someone can comment, or point to a url, which explains how they are dealing with this scenario:
A customer can select a flat rate shipping option that is too small for the product and thus when the business owner fulfills the order, they lose money because they have to package it up and ship it using a different rate box.

Thanks all.

~rickup

selwynpolit’s picture

subscribing... I notice the system only shows quotes when you set the package type to variable.

Jayson Cole LaFrance’s picture

Subscribing. When I was attempting to use the drop down, it didn't seem to behave how I expected. I thought it would help me limit the package options on a node-to-node basis. For example, selecting 'LG FLAT RATE BOX' => t('Large flat rate box'), I was hoping it would limit the customer's shipping options to "Large flat rate box". I've been searching for a solution but have come up empty handed.

In regards to the error: "LG FLAT RATE BOX is an invalid container type for a REGULAR package and ONLINE service"...

It looks like we need to have a drop-down to change the request REGULAR to LARGE based on theUSPS Rate Guide API. Right now it seems that the module is hard coded to REGULAR.

rickupdegrove’s picture

In response to #4

I actually did try this and it worked. I got options for shipping instead of an error. What I am uncertain of is if the client will lose money on the shipping which is my main concern. I just need more time & good suggestions like that one.

Line 579 was 
        '<Size>'. 'REGULAR' .'</Size>'.
I changed it to 
        '<Size>'. 'LARGE' .'</Size>'.

This was the "Constructs a quote request for international shipments"

There is still the "Constructs a quote request for domestic shipments"

If you look at line 534 it is not hard coded like the international, but I can't yet seem to find how to change this in the Ubercart UI anywhere.

        '<Size>'. $package->size .'</Size>'.

Any known info would be appreciated and since #1 leads me to believe this functionality won't be back ported to 6.x-2.x I am happy to share anything I come up with.

That is all for now but I will either edit or reply to this post when I have more info, this is an evolving issue.

rickupdegrove’s picture

This is for
Drupal 6.22
Ubercart 6.x-2.6

My unique solution: Remove Flat Rate Shipping

All products need to have "Variable" selected for "Package type" (this is the default but changing it will prevent a shipping estimate from being calculated) and if your settings "Prevent the customer from completing an order if a shipping quote is not selected" then nobody can check out.

See: /admin/store/settings/quotes/edit

This was a problem for me because this is an International store that ships virtually everywhere in the world and having people "call for quote" was not a viable option.

For Me: Flat rate boxes were the problem; choosing them as a shipping method gives the customer the option to choose the size of package for the shipment regardless of product size. When build(ing) an e-commerce solution the shipping is calculated correctly based on product weight and eliminates the need for flat-rate shipping options all together. Clients just need to define a weight to any products that are shippable. From my tests and personal experience, shipping product using a flat rate box is more expensive than shipping based on weight. For all future e-commerce builds, do not select flat rate shipping as an option.

pkchoo’s picture

Is there a solution to this yet?

I'm encountering the same issue where USPS is showing me all Priority Flat rate shipping options (small box, medium box, large box) regardless of order quantity. If I change the package type from variable, either it doesn't show a quote at all or it still shows all the size options.

cyborg_572’s picture

You might be able to work around it with the Product Quote module after applying the patches in #1182786: Getting it all working, which allows you to say on a product-by-product basis which shipping methods are allowed.

Right... 7.x-3.x don't mind me then.

rickupdegrove’s picture

Update:
Posted by TR on March 29, 2011 at 6:53pm
on http://drupal.org/node/1079640
Re #8: The new USPS API came with new package types. Your package type should be Variable, not Rectangular. You can change this on the product edit page. Variable is the default in code unless you have overridden the package type on the product edit page.

sswari’s picture

Yes, using Variable does give quotes, but it is still ALL quotes which seems to be the original issue, a customer can select the wrong option. Why can I not select the package size I want to use in the product configuration page? This works fine with UPS.

There also seems to be an issue with how it calculates the number of boxes that will be shipped, but that is a different issue.

sswari’s picture

Issue summary: View changes

A customer can select a flat rate shipping option that is too small for the product and thus when the business owner fulfills the order, they lose money because they have to package it up and ship it using a different rate box.

sadashiv’s picture

Issue summary: View changes

I am also facing a similar issue. USPS is not returning any quote even when package type is variable. I added some code to change the package count as per my requirements. I know all of products dimensions and how many quantity can fit in one large envelope so i added code in _uc_usps_package_products

foreach($packages as $key => $package) {
    $required_packages = 0;
    foreach($products as $product) {
      $required_packages += $product->qty/$product->pkg_qty;
    }
    if ($required_packages == 0)
    break;
    $required_packages = ceil($required_packages);
    $packages[$key][0]->qty = $packages[$key][0]->qty/ $required_packages;
    while ($required_packages > count($packages[0])) {
      $packages[$key][] = $packages[$key][0];
    }
  }

This modifies the packages as per the max per packet configured in the product edit and I setted up different flat rate quotes depending on the number of packages.

Hope this gets fixed soon

Thanks,
Sadashiv.

TR’s picture

Version: 7.x-3.x-dev » 8.x-4.x-dev

Shipping is being refactored for 8.x-4.x. It's unlikely that this will be backported to 7.x-3.x.