USPS - Do I have the latest?

[Ajeh]

Could you edit the file:
/includes/functions/functions_general.php

and search for the function:
function zen_round

and copy the function here ...

[patternman]

Currently:

////
// Wrapper function for round()
  function zen_round($number, $precision) {
/// fix rounding error on GVs etc.
    $number = round($number, $precision);

    return $number;
  }

I tried using the code from the current 1.3.9h, but I still got the same result. For reference:

////
// Wrapper function for round()
  function zen_round($value, $precision) {
    $value =  round($value *pow(10,$precision),0);
    $value = $value/pow(10,$precision);
    return $value;
  }

Thanks,
Jason

[Ajeh]

None of this makes any sense ...

Both of those functions give:
OUNCES SAYS: 15.68

Just for fun, what happens if you change the Tare Rate to 0:0 instead of 0:.57 ...

[patternman]

Thanks for all the help tonight.
I need to go home.
I'll take this up again tomorrow.
Jason

[Ajeh]

okie dokie ... have a good night ...

[patternman]

Ok, I spent a long time tonight during low traffic to play around and experiment...
Here's what I have determined.

After looking at the number of ounces closely, the numbers were indeed being rounded, but the server was not getting the job done correctly.

So instead of 6.56, it would give a number like 6.55999999999999960920149533194489777088165283203125
I repeated this with several products, and it always had similar results - except for the very few products (with tare) that had a perfect integer number of ounces already. Then everything worked again like magic.

So I thought maybe I'd use floor and ceil to get the job done instead of round. I don't really need to detail the many different variations of code that I tried to use for the zen_round function. In the end, nothing worked. It always returned the same long number. The only thing that made a difference was to turn the zen_round function into a one line ceil or floor function.

So then I tried doing the code changes directly into the usps.php file rather than the functions_general.php. No luck there. Any kind of attempts to get around the rounding error just returned the same value again.

Doing a little bit of reading, this seems to be a float problem with some versions of php. So I'll be discussing this with my web host. We just upgraded last week from 5.2.14 to 5.2.17. It just seems obvious that its the server software.

In the meantime, I've done a little work-around to get the international shipping quotes working again.
Where there was this line:

$shipping_ounces = zen_round($shipping_ounces, 2);

I replaced it with this line:

$shipping_ounces = ceil($shipping_ounces);

USPS always rounds up to the nearest whole ounce anyway.
So I never really needed those decimal places to begin with.

But the rounding errors make me very nervous and I don't really know what other surprises are in-store for me. So I hope to get to the bottom of this with our web host.

Thanks so much for your time and help.
This still isn't finished, so if there is anything else useful to contribute, please don't be shy.

Cheers.
Jason

[Ajeh]

Let us know if you come up with anything ...

[patternman]

Well, my wild ride finally comes to an end.
The issue was indeed the server.

Here is an example for generating the shipping quote.
The product weight + tare weight is exactly 6.56 ounces or 0.41 lbs * 16.
There is no rounding involved. There aren't even any percentages or fractions to be multiplied. The product weight is exactly 0.2 lbs. The tare weight is exactly 0.21 lbs.

But instead of giving 0.41, it gives this:
ORDER WEIGHT: 0.41000000000000003108624468950438313186168670654296875
Also, when trying to round this number (to two decimal places), it gives this:
ORDER WEIGHT: 0.409999999999999975575093458246556110680103302001953125

So even basic math was getting twisted somewhere.

Ok, here's the verdict:

In dealing with a recent PCI compliance scan, our webhost made an addition to the php.ini.
The value in php.ini was set to "precision=500".
This line was removed, and everything works fine now.
This was not a critical issue for pci compliance, so we're doing ok.

Cheers!
Jason

[Ajeh]

Thanks for the update that this was a setting on your server causing all of this confusion ...

[stellarweb]

Linda,

One of my customers received an email from USPS that says:
"Effective 8/24/11 the Rate and RateV2 versions of the web tools domestic rate calculator APIs will be retired. Integrators are encouraged to migrate to RateV4."

Will people be needing a new update for this? I see a mod for 1.3.9 but this customer has not upgraded yet...

THANKS!!