I been having this issue for a while and tried using different conditions to get around it with no luck.
When you enter an international address with any zip code the USPS domestic rates also show along with International rates.

If you leave the zip code blank it shows only international rates. I tried just about every scenario with the same result. Our site is live and were seeing international customers choosing Domestic rates shown in the same list which causes problems as you can imagine.

USPS doesn't use zip codes to calculate shipping for International rates as far as I know.

CommentFileSizeAuthor
#12 1111396.patch2.13 KBTR
#3 1111396.patch1.89 KBTR
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alien73’s picture

Anyone else having this issue?

longwave’s picture

You might want to try upgrading to 6.x-2.x-dev, as there have been a few fixes to the USPS module since 6.x-2.4 was released.

http://drupalcode.org/project/ubercart.git/history/refs/heads/6.x-2.x:/s...

TR’s picture

Status: Active » Needs review
FileSize
1.89 KB

Here's a backport of just a few of the changes I made in uc_usps for Drupal 7. I think it should address the issue you're seeing.

Status: Needs review » Needs work

The last submitted patch, 1111396.patch, failed testing.

TR’s picture

Ignore the bot on this one - bot doesn't work with fixed point releases like 6.x-2.4 yet.

alien73’s picture

Thanks TR much appreciated!

alien73’s picture

Priority: Major » Critical
Status: Needs work » Active

Unfortunately the patch doesn't work. International customers can alter the USPS shipping rates simply by putting in a US zip code and get the cheaper Domestic rates. Store owner in turn will have to contact the customer and try to re-adjust the shipping rates to the higher rate.. Not very professional and in most cases you will lose business as we have already.

Note: If the zip code is left blank it works fine. The patch checks to see if the zip code is left blank, but it works without it anyways. The easy fix would be to bypass the zip code altogether with International USPS Rates since USPS doesn't use the zip to calculate shipping costs.

alien73’s picture

Assigned: Unassigned » alien73
Status: Active » Needs review

This fixes the issue

function uc_usps_rate_request($packages, $origin, $destination) {
  $request  = '<RateV3Request USERID="'. variable_get('uc_usps_user_id', '') .'">';
  $services_count = 0;
  $rate_type = variable_get('uc_usps_online_rates', FALSE);

  foreach ($packages as $package) {
    $qty = $package->qty;
    for ($i = 0; $i < $qty; $i++) {
      $request .= '<Package ID="'. $services_count .'">'.
        '<Service>'. ($rate_type ? 'ONLINE' : 'ALL') .'</Service>';

//->Start
//->Only use zipcode with USPS Domestic Rates  
     
	if ($destination->country == 840) {
	$request .= '<ZipOrigination>'. substr($origin->postal_code, 0, 5) .'</ZipOrigination>'.
        '<ZipDestination>'. substr($destination->postal_code, 0, 5) .'</ZipDestination>';
	}

//->End	

        $request .= '<Pounds>'. intval($package->pounds) .'</Pounds>'.
        '<Ounces>'. number_format($package->ounces, 1, '.', '') .'</Ounces>'.
        '<Container>'. $package->container .'</Container>'.
        '<Size>'. $package->size .'</Size>'.
        '<Machinable>'. ($package->machinable ? 'True' : 'False') .'</Machinable>'.
        '</Package>';

      $services_count++;
    }
  }
  $request .= '</RateV3Request>';

  return 'API=RateV3&XML='. drupal_urlencode($request);
}

TR’s picture

Assigned: alien73 » Unassigned
Priority: Critical » Normal

@alien73: What you say in #7 and #8 is contradictory and makes no sense.

There is only one line of my patch that is relevant to solving this issue, and that's the last changed line in the patch. The stuff at the top of the patch, which you refer to in #7, is there simply to reduce the calls to the USPS server, by waiting until the customer has provided all the necessary information before a quote is requested. (That is explained in the code comments.)

Specifically, the one line in my patch is a test to ensure the destination country is US *before* uc_usps_rate_request() is called. (uc_usps_rate_request() only returns domestic quotes, not international, and should never be called for an international rate request.) So in the case of my patch, uc_usps_rate_request() will not and can not be called for non-US countries, and domestic rates will not be requested. If you are still seeing domestic rates for non-US countries after you've applied my patch, then you've done something wrong. Did you actually apply the patch using "patch" or did you do it manually? I suspect you missed changing that one line at the bottom of the patch that does all the work for this issue.

You say my patch doesn't work, yet the alternative you present in #8 also checks the destination country and does something different if the destination is not the US. If your check works, my check has to work too. Your check, however, is in the wrong place. What you're doing is entering uc_usps_rate_request(), constructing a domestic rate request, then removing the zone code from that request if the country is not US - the request without zone code is still being sent to USPS, but without a zone the request is invalid and fails. That's a very poor way of doing things.

Please go back to my patch in #3 and make sure all the changes get applied properly before you test again.

alien73’s picture

Priority: Normal » Critical

Makes perfect sense TR... Have you really tried it!

Don't always reply on what you think the code will do without testing. An other thing don't always point fingers it's your fault to everyone all the time. I pointed out a problem with the missing MS state and you automatically thought it was my fault only to find bugs on your side with the .cif updates! Your Welcome!

We all appreciate your help, but your attitude is not pleasant. Were here helping others too, but without the sarcasm. Human Skills 101.... Just so you know.

====================

Tried your code and it really doesn't work. Looking at the code you would think the simple elseif statement would do the trick, but it doesn't.

My little fix calls the zip code from Domestic rates only and does not pass with International fixing the issue.
Passing the Zip Code to International rates is the wrong way as it's not needed.

//->Start
//->Only use zipcode with USPS Domestic Rates 

if ($destination->country == 840) {
$request .= '<ZipOrigination>'. substr($origin->postal_code, 0, 5) .'</ZipOrigination>'.
        '<ZipDestination>'. substr($destination->postal_code, 0, 5) .'</ZipDestination>';
}

//->End

Steps to reproduce!

1. Enter a International address then leave the zip code blank.. IT WORKS...
2. Now do the same thing, but now enter a US zip code or any zip code now you will see Domestic rates show along with International.

alien73’s picture

Does the Ubercart demo site have the USPS rates turned on?

TR’s picture

Version: 6.x-2.4 » 6.x-2.x-dev
Priority: Critical » Normal
Status: Needs review » Fixed
FileSize
2.13 KB

Re: #11: I don't know - you'll have to ask the ubercart.org people about that.

(Really, you're criticizing my handling of #1111338: State Mississippi missing from zones? I fixed that problem ONE HOUR after you stated the problem. Your initial issue said Mississippi wasn't in the list of US zones and expressed incredulity that this could happen. This is a testable fact, and it's not true. You then posted 10 minutes later to say the zone code MS was set to Massa e Carrara, which is a different fact. You posted again indicating you didn't need help any more, and you marked the issue as fixed. However, I did an investigation anyway and determined it was a real bug, which I traced back to a bad .cif file that was submitted by the community and tested (insufficiently, it seems) by the community. I reopened the issue (I even accepted the blame for the problem because I was the one that committed the bad patch), then I searched ALL the ~500 country files for both D6 and D7 Ubercart to make sure only that one was broken. I fixed the bug in both D6 and D7 and provided detailed information about what happened and possible side effects to look for on your site. All in ONE HOUR. You can't pay for service like that. Using it as an example of why I suck instead of thanking me (neither is necessary, BTW) reveals your own "attitude" more than anything.)

I committed the attached fix for this current issue. You'll see that in addition to #3 I had to rename $dest to $destination in three places in the D6 version, since that rename was also part of the extensive work I did on this module in D7. (Extensive work that included fixing this same bug when I discovered it in D7 last month). I know very well that I am fallible, but if you're going to pick an argument with me you should have your facts straight. My facts in #9 were correct; I made an argument based on logic and laid out the steps that led to my conclusion. You rejected the conclusion without examining the steps and finding where the argument broke down. What I (and you, BTW) missed was that this variable had been renamed, but there was no flaw in the logic. If you didn't just reject my conclusion maybe you would have caught that - instead it seems you read-in an "attitude" that you didn't like and chose to ignore the details of what I was saying.

alien73’s picture

TR,

Tried your updated code and it still doesn't work just hangs with International Shipping. Are you testing code or just coding with logic?

Also I'm sure you don't need to include this twice in the same function.

$destination = (object) $details;

My very poor way of doing things fix is working like a charm and seems to load faster! Haven't timed it though!

Be Happy!

alien73’s picture

Priority: Normal » Critical
Status: Fixed » Needs work
TR’s picture

Priority: Critical » Normal
Status: Needs work » Fixed

"just hangs with International Shipping".

I'm going to assume that you're now using 6.x-2.x-dev instead of patching 6.x-2.4 as before - the patch didn't touch any code having to do with international shipping. However, the USPS API has changed drastically recently and there is a port-in-progress to the new Domestic and International APIs that is included in the latest dev. So if you're seeing problems with international shipping in the latest dev it's probably due to the new API.

I've backported some more D7 changes for the IntlRateV2 API and committed them to 6.x-2.x-dev. You may open a separate issue for problems with the new international API, as that is unrelated to this thread. Be sure to post your XML request and response with any issue.

alien73’s picture

I'm using 6.x-2.4 as originally stated when I posted this issue then it was changed. I have it fixed on our side so our business can continue without glitches.

I already noted the problems I'll leave it up to you!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.