Jul 2013
1 / 11
Jul 2013
Jul 2013
brian_ckc
Jul '13

I had a complaint from a customer that couldn't checkout and on trying myself I get the same problem.



Regardless or what country or zipcode is entered shipping says '-error-'



Please help, I'm assuming I'm not the only one because I haven't changed anything.



Regards,

Brian

mkp007
Jul '13

This does appear to be a USPS calculator related issue. I switched to UPS Ground calculator and it is now working; however, my rates are all wrong now.



still annoyed that this hasn't been responded to by tech support.

brian_ckc
Jul '13

I thought this weekend was quiet (no orders) and now know why. Do you know when this started? I think the last order I received was Thursday night or Friday morning.



I would have expected something like this to be on the main page at least acknowledging the issue. We still don't know if anyone is even looking at this issue.

E-junkie_GuruWebmaster & Support Guru
Jul '13

Apparently USPS rolled out an unexpected change to their rate lookup API today, so Development is working on sorting that out right now, with our apologies for the inconvenience and thanks for your patience and understanding.

brian_ckc
Jul '13

E-junkieGuru, thanks for the update. Can you please let me know when the problem started? When did USPS do the update?

E-junkie_GuruWebmaster & Support Guru
Jul '13

This should be fixed now, again with our thanks for your patience and understanding. This whole situation was rather bizarre. Not only did we not receive the usual advance notice from USPS of this impending change, which occurred outside of their typical update schedule (i.e., at a time when nobody would be expecting it), this was a rolling change that affected an existing API version (big no-no, as the whole point of a versioned APIs is that nothing changes for a given version number), and the actual change did not match what they'd documented for it, so it took a bit of guesswork and testing to get it working right. Your postage dollars at work...

brian_ckc
Jul '13

I can confirm it is working again now, so thanks for that.



Given what you've said about the change not matching the documents I guess there is a strong probability that they will do something similar in the coming days/weeks. Looking at the other threads it appears USPS have some history of unscheduled or undocumented changes.



I would still like to know when the problem first started, just to know what to tell our customers. When did USPS roll the changes out ? Was it Friday, Saturday or Today?

E-junkie_GuruWebmaster & Support Guru
Jul '13

According to USPS documentation, this update rolled out today, and the earliest email about the issue was sent to us this morning, so orders prior to today would not have been affected.

mkp007
Jul '13

As noted in my previous post:



It would seem logical to have a copy of the rate table stored locally on E-Junkie server and have that as an option to choose (shipping settings) in case this were to happen again. Probably too much effort for the e-junkie team.



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



It seems silly to rely on a separate company, server and API in order for the shopping cart to work. This is the 2nd time it happened this year. How much effort would it be to copy the rates to your server? Then, every time USPS notifies E-Junkie of a change, you can test and update those files.

E-junkie_GuruWebmaster & Support Guru
Jul '13

Thanks for your suggestion about having a local fallback for USPS rate lookups. I've discussed it with Development, and they're looking into it; if it turns out to be feasible and fairly straightforward to implement, they will do so.



From what we've discussed so far, if USPS fails to respond when we query for a rate, or responds but returns no usable rates, then we would resort to our local fallback lookup, but if they return at least one rate for any USPS shipping rules applicable to the buyer's order, we would accept that.



It's normal for USPS to not return any rate at all for shipping method(s) that aren't available for the buyer's order weight or destination, so we can't tell when that's the case vs. some glitch causing the missing rate(s). This means when our fallback comes into play, there's a slim chance this could result in applying a rate that isn't actually available for the buyer's order weight or destination; however, we reckon it's better to at least let the buyer place their order and sort out any potential shipping-rate issues later if needs be, rather than to prevent them from ordering at all.