Hi everyone! Thanks for joining us for the Weekly Chat with eBay Staff. We don't have a specific topic this week, so feel free to share any general buying or selling questions you may have.
The chat thread will remain open until 2 PM PT at which point we'll close it from additional responses. After that time, we'll continue to work on responding to any queries that might still be unanswered.
To post your question, click Reply in the lower right corner of this post, type your question, and hit submit between 1-2 PM Pacific Time. The format of our chat mirrors the format of our Community Discussion Boards, where each post will appear in the thread chronologically. The Community Team will review each question as it comes in, and will quote the original question in our reply. This quote and the reply will appear later in the thread, so just keep scrolling down to see our answers.
Missed the chat? Send your questions to the podcast by calling 888-723-4630 or email us at podcast@ebay.com and maybe your questions will make it on the air! Or listen to past episodes while you wait for next Wednesday!
Hi all,
We ran out of time last week on the topic of Shipping form problems, in particular how the package dimensions were coming into the Shipping form unlabeled and in the reverse order of how they had been entered by the user. There was also disagreement on how the dimensions were generally ordered as standard practice. I normally trim followup quotes as they can quickly get to an ungodly length here, but am including (most of) the full quote just this once in order to get us back up to speed, as I noticed today that the problem is more deep-seated than first reported, something I'll get to below:
> @mam98031 wrote:
>> @a_c_green wrote:
>>> @mam98031 wrote
>>>> @mr_lincoln wrote
>>>> [...]
>>>> Subject: New Label Flow - Dimensions
>>>>
>>>> This request is a few weeks old, can you please provide an update
>>>> from the Shipping & Handling Team on the request to correct the
>>>> dimensional order of Length x Width x Height of packages. On the
>>>> listing form and pretty much everywhere else in life we enter
>>>> L x W x H but the most recent Label Flow has it backwards when it
>>>> transfers the Listing form dimensions to the label flow ...
>>>> they are showing H x W x L ...
>>>
>>> Standard on this kind of stuff is usually width by height by depth.
>>> That is standard in so many industries and I'm not sure why they are
>>> bucking the system on this one. It only creates confusion and mistakes.
>>
>> For clarity (especially since the fields aren't even labeled on the
>> Shipping form, as seen in the screenshot, I think we should describe
>> the order of values as Longest First and Shortest Last.
>> Length x Width x Depth is also a common description, but for Girth
>> calculations (Longest dimension, followed by distance around), there
>> has to be either an assumption that the Longest value comes first, or
>> the coding has to be smart enough to see which of the three values is
>> the greatest, and then treat the other two as Width and Depth.
>>
>> Frankly, I don't trust the coding seen to date in the new Shipping form,
>> and having the dimension fields come up both unlabeled and in the reverse
>> order that they were entered by the user does not inspire confidence.
>> Can we get whoever does Shipping form coding these days to correct the
>> order of the values to be as entered by the user, and label them for
>> clarity? (I did submit this as a request via the link on the Shipping
>> form some time back, but have seen nothing in response. I also pointed
>> out some bad grammar in the form that needed fixing, and that is not
>> fixed either.)
>
> Except that would be different than the way it is often done. Even USPS
> goes width, height, depth. To do something different than that seems to
> be to add unnecessary confusion.
Actually no, USPS uses Length, Width and Height, where Length comes up first and is the longest dimension, such as in this example from their Shipping calculation form:
This is also stated in their procedure for Girth calculations, in those Shipping methods that use it:
Length-first is also the order in which they specify dimensions of their own packaging:
PayPal also uses this standard practice for package dimension ordering in their Ship-Now form:
In short, it's only the eBay Shipping form that's introducing the dimensional values unlabeled and backwards, which at best confusing and at worst misleading. In fact, the errors are slightly worse than mr_lincoln first described, which I'll get to in a moment here.
The Create Your Listing form does not label the fields either, but inspecting the form coding shows the field names to be pkgLength, pkgWidth and pkgHeight in that order. In Google Chrome, you can see this for yourself by right-clicking on each field and selecting the Inspect option from your popup menu. The relevant code will come up highlighted in a frame on the right.
Any decision process within the Shipping form that uses a Girth calculation needs to add the Length (longest distance) to the distance around the other two dimensions. For example, a package that's 48"L x 18"W x 12"H in standard notation has a Girth of 108" (48+18+18+12+12). The Shipping form would show these dimensions unlabeled as 12 x 18 x 48 instead, and any code assuming that Length comes first, which it usually does, runs the risk of overestimating the Girth as 144" (12+18+18+48+48).
Now, here in the Shipping form is where things have gone sideways, and more so than first thought. In our example above, the Shipping form will show the dimensions on-screen as 12 x 18 x 48. If we inspect the field names in this form as we did in the Listing form above, the Shipping form is actually presenting what it thinks is the Length first: that field input name is dimensions.length, even though the value it's showing came from pkgHeight in the original form. Similarly, the third field input name is dimensions.height, even though the value it's showing came from pkgLength in the original form. Somewhere along the line, the stored dimensions got transposed into the opposite order, such as Last In First Out instead of First In First Out. Any process using those values for a Girth calculation will get it wrong.
In summary, I can see how an initial oversight like this can sneak through into Beta testing, but good grief, that bit of weirdness should have leapt off the screen. We sellers spotted it right away. Yet it's been an eternity (in QA Testing time) and no one has corrected it, or even replied to you Community folks to let us know when the fix can be expected.
An umpty-bazillion-dollar entity like eBay really needs to implement basic peer-review and QA testing for its website code. Dumping a new release into the wild for users to troubleshoot is just sloppy, and failure to correspond or have any useful dialogue about how quickly a fix can be developed is inexcusable. You folks in the Weekly Chat need to put pressure on the Engineering side to get their act together and start delivering some meaningful support, in both communication and software fixes.
-----
Edit: A reply to your comment can be found here
@maxoptical wrote:
I have a quesiton on Partial refund offers. If a return label is due by Tuesday but on Monday I make a offer to refund 50 percent of the purchase and the customer keeps the item. Do I still need to upload the return label by Tuesday or do I wait until the buyer accepts or declines my offer? I have spoken to several Anchor Support reps with no answers.
Thanks,
John Norman
Max Optical
@maxoptical if the buyer doesn't respond to the partial refund offer then no, the deadline to provide a return label. The buyer asked for a return, so we'll honor that request unless they accept the partial refund offer prior to the deadline provided to the seller. So if the buyer doesn't respond to the offer then you'll need to get the return label by the due date.
