07-11-2019 08:04 AM
I sold an item to a customer who has PR (Puerto Rico) listed as their state and country. Neither eBay nor PayPal will let me generate a shipping label. I messaged the buyer a few days ago but haven't heard back. Does anyone know how I can change the country? It's populating as a domestic item.
Solved! Go to Best Answer
07-12-2019 04:53 PM - edited 07-12-2019 04:54 PM
@berserkerplanet wrote:I was able to change the buyer's address to PR country, and the label flow automatically changed the state to PR even though the zip code was still a SoCal zip.
Whether it would fly if I actually tried to purchase the label is unknown.
I'm going to say No, probably not, because purchase time is when the address gets validated via USPS (e.g. the 5-digit ZIP is expanded to 9 digits, that kind of thing), and at that point the mismatch between State Abbreviation and ZIP code should (in a perfect world) get flagged as an error. It could override the State based on the ZIP, or the ZIP based on the Street Address and City, but I would think the safer path would be to return an error about a City/ZIP or State/ZIP mismatch.
I really think we've gone as far as we should need to go with this, but in the absence of a clear line of communication between eBay programmers and users out here, how much of this they will understand is anyone's guess.
07-12-2019 06:22 PM
07-12-2019 06:40 PM
@berserkerplanet wrote:
I was hoping you would be up to doing the testing legwork since you are one of the best equipped to do so, and have/had PR sales, but whatever.
No, really, I don't think I'm missing your point, and I'm sure it's quite fixable on a case-by-case basis as you have explained it. Heck, I got further than I thought I would when following your guidance for editing/removing the Read Only attribute on the Country field, and if the full address ends up with correct values in all the fields, then it certainly should sail through USPS validation.
But our knowing how to fix the problem isn't going to get the problem fixed. That is, I think we as non-priv users have gone as far as possible in diagnosing the problem and debugging a possible solution, but it's still eBay coding that appears to be botching the process, and it's eBay that needs to step up and get it fixed, so that all its umpty-bazillion sellers can ship to Puerto Rico as easily as anywhere else.
As you have already pointed out, their "classic" form doesn't have this problem at all, and in fact when I view my Puerto Rican buyer's address through the classic form edit window rather than the "new" form's edit window, it shows me "United States" as his Country, not "PR" in that field. I'm wondering whether the buyer himself didn't put in any Country value at all, and the classic form is defaulting to "United States," but the new form is defaulting to picking up the State value instead.
(More pondering: if it's an iterating process that's collecting the address field values one at a time, perhaps it's failing to clear the previous value before reading the next one, and so when there is no Country value entered by the user, it accidentally reuses the State value to be the Country value as well.)
I'll try (again) to report the problem via that insipid "Tell us what you think" link, but given that all my previous reports have gone unacknowledged and apparently ignored, I'm not optimistic. I can't even get @Anonymous to answer me anymore...
07-12-2019 08:11 PM
07-13-2019 05:34 AM
@berserkerplanet wrote:
The workaround info is there in the other thread The bookmarklet that makes the country editing trivial is there, those who are adventurous can try it if they wish.
I'm still looking at this now. Customer has paid this morning, so I can try to get the correction process pushed through all the way to the end. I can always fall back on the "classic" form to do things properly if all else fails.
At this point I have the bookmarklet performing as advertised, but I am still hitting the wall with an Internal Error when I try to save the change of Country. That's where things stand at this moment. Taking a break to make breakfast for the family and think about anything else to try on this.
07-13-2019 08:02 AM
that sounds great, may be I can accept my buyer from overseas even not on my list, if it can change the shipping easy, thanks for sharing.
07-13-2019 05:59 PM - edited 07-13-2019 06:01 PM
@berserkerplanet wrote:
The workaround info is there in the other thread The bookmarklet that makes the country editing trivial is there, those who are adventurous can try it if they wish.
Okay, I have good news and a final (for now) update: It worked, and I was able to print the Puerto Rican address using the "new" form, without having to fall back on the "classic" form.
I'm not exactly sure why it worked, because I was repeatedly unable to get the edited/corrected Country value to save, so that I could get back to the main Shipping page without getting that Internal Error 500. The bookmarklet itself worked fine and exactly as advertised (and thank you for that); it's just that the website would not let me store the revised Ship To: address unless or until I changed the Country value back to "PR."
So I finally decided to just plow ahead with the Purchase and Print button again regardless, to see if the process would continue to hang at that point, and Lo and Behold, it went through successfully. I first went through the motions of plugging in "United States" as the corrected Country, ignored the Internal Error 500, cancelled my way out of the Edit screen in order to get back to the main form, and hit the Purchase and Print button. Success.
My only theory at this moment is that it didn't matter that the website wouldn't store the revised Ship To: address, because the local Country variable that I had redefined in my Edit session would be the one to be used for the Purchase and Print process following.
So my customer will be getting his package on time, and the next time I hear from him (he's a semi-regular of mine), I'll run through this again from start to finish without dithering so much in the middle, and see if I can confirm that that's how the workaround is succeeding.
07-13-2019 10:07 PM
07-15-2019 01:11 PM
@a_c_green wrote:
@bluestardiecast wrote:
Thank you for the work around - the PayPay edit option worked for our PR label today.
I can confirm that the other workaround of changing "new_label" to "back_to_classic" in the URL will also work, as it then brings up the "classic" Shipping form which is able to deal with this bug.
I had previously thought that this PR-as-a-country error was somehow created by the buyers when they set up their Ship To address, but it seemed like a weird error for someone who actually lives there to be making. Perhaps the root error for all this mess is that a programmer somewhere thought that Puerto Rico was another country (i.e. one that does not use the domestic US Postal System), and thus "PR" for "Puerto Rico" exists as a choice in the list of Country values. (It can be seen as a choice in more than one location in the lists of countries that you can exclude from selling/shipping to.)
A mailing address with "PR" in the Country field, when passed to the "classic" Shipping form, will trigger a unnecessary Customs form to be completed after the main Shipping form is finished. (In the classic form, you can tell when it's about to bring up a Customs form because the Blue button at lower right will read "Continue" instead of "Purchase postage.") As the Customs form is not actually required for domestic shipping to Puerto Rico, the classic form never actually passes it on for printing, using the domestic label template instead of the international Customs/address form template when printing the recipient's package label.
In comparison, the "new" form seems completely confounded by a Country field value of "PR," and simply hangs.
@Anonymous, can you please just give us a wave or something to let us know that this information will reach the programmer(s) who need to fix this? It looks like we users have come a long way in debugging the possible root problem as well as its side-effects, symptoms and available workarounds (thanks to @berserkerplanet
), so it would be helpful to know that our work is not in vain here. Thanks!
Hi @a_c_green, definitely passing along the details shared here. If I can get item numbers for these examples to include with the details sent to the tech teams, that would be much appreciated!
07-15-2019 03:02 PM
@Anonymous wrote:
Hi @a_c_green, definitely passing along the details shared here. If I can get item numbers for these examples to include with the details sent to the tech teams, that would be much appreciated!
Certainly; my item number is 333257464371. Send me a PM if you need anything else, including screen shots.
One key detail that I think is important to pass along to the programmers is that if you attempt to edit the buyer's Ship To: address via the new Shipping form, his address will come up showing that incorrect "PR" value as the Country. However, if you attempt to edit the buyer's Ship To: address via the "classic" Shipping form (by changing "new_label" to "back_to_classic" in the Shipping form's URL, then pressing Enter), his address will come up showing the correct "United States" value as the Country.
One theory (which you can check better than I) is that my Puerto Rican buyer (ID available via PM if you need it) has not entered a Country value in his Ship To: address, and the new Shipping form is plugging in an incorrect default value, possibly carrying forward and reusing the State value by mistake. Another possibility is that he plugged in "PR" for both his State and Country, but that the classic Shipping form knows to ignore the invalid Country value and just go with the other elements that it can validate as a United States address.
07-16-2019 12:24 PM
@a_c_green wrote:
@Anonymous wrote:
Hi @a_c_green, definitely passing along the details shared here. If I can get item numbers for these examples to include with the details sent to the tech teams, that would be much appreciated!Certainly; my item number is 333257464371. Send me a PM if you need anything else, including screen shots.
One key detail that I think is important to pass along to the programmers is that if you attempt to edit the buyer's Ship To: address via the new Shipping form, his address will come up showing that incorrect "PR" value as the Country. However, if you attempt to edit the buyer's Ship To: address via the "classic" Shipping form (by changing "new_label" to "back_to_classic" in the Shipping form's URL, then pressing Enter), his address will come up showing the correct "United States" value as the Country.
One theory (which you can check better than I) is that my Puerto Rican buyer (ID available via PM if you need it) has not entered a Country value in his Ship To: address, and the new Shipping form is plugging in an incorrect default value, possibly carrying forward and reusing the State value by mistake. Another possibility is that he plugged in "PR" for both his State and Country, but that the classic Shipping form knows to ignore the invalid Country value and just go with the other elements that it can validate as a United States address.
Hi @a_c_green, the item number is enough for me to grab the other details and test this out on my end. I've looped in our developers to identify any issues or potential enhancements that need to be put into place. Definitely keep me posted if you run into any other examples I can share with them in case they are needed. I will touch base with you if I need anything else!
07-16-2019 04:35 PM
@berserkerplanet wrote:
Good to hear. I had a feeling it might work. And do be sure to report back next time you get a PR sale.
PR needs to be country US for USPS, however, if you ship UPS or Fed Ex, it needs to be the country PR.