Best regards,
Gentlemen, first and foremost, thanks for replying to my post on the Weekly Chat yesterday. Since the Chat is closed now I wanted to respond in kind to the suggestion to look at the Seller Hub CSV in lieu of Managed Payments NOT offering a date range programmable CSV formatted database (like PayPal) to meet most of a Seller's accounting needs for manipulating their transaction data. Regarding the Seller Hub version please note:
- The eBay Seller Hub CSV formatted database is NOT date range programmable, there are pre-selected time periods to select from. So these are “canned” reports. Here is just one reason “date range programmable” is required:
Anyone in our state who has a Tax ID for Resale purposes has to report to the state either monthly, quarterly, bi-annually or annually. The reporting frequency is determined by sales volume and dictated by the state. We have to remit sales tax to the state for IN state shipments. The date range programmable functionality allows a Seller to create the report for their unique reporting frequency, the Seller Hub CSV canned reports do not satisfy that requirement and would force a Seller to download monthly files and merge them causing more unnecessary work.
- Columns U and AQ are numeric values formatted wrong.
U is the eBay Item number
AQ is the carrier tracking number
The Seller Hub CSV file download puts these numbers in scientific format (I believe that’s correct terminology) and when converted to the actual number the results may not be accurate. This is definitely the case for column AQ – Tracking number, when converted almost ½ the tracking number is converted to zeros and the original numbers are lost. The yellow highlighted cells are the converted number after the download.
- No eBay FVF Fees column (needed for tax purposes)
- No shipping FVF Fees column (needed for tax purposes)
- No Refund column (needed for tax purposes)
- No PayPal Fees (needed for tax purposes - granted the eBay CSV is ONLY for the eBay end of transactions and will not pull data from PayPal but if this is the basis for reports for Managed Payments it is still lacking in its completeness.
So in closing this initial post, the Seller Hub CSV formatted database is heading in the right direction but is not there yet. It needs to be more flexible with the date range programmable functionality as well as include other transaction info per the above post.
@myjunqueyourtreasure wrote:
Good Luck getting that functionality as we STILL can't see our totals by calendar month (you know, the way most businesses and the govt run?)
I have been lobbying for the date range programmable CSV formatted database from day One on Managed Payments. If anyone says I sound like a broken record they are 100% correct ... Nobody is looking for MORE work to do so I am just miffed at why that functionality, which PayPal has had for FREE for years, is not part of the Managed Payments functionality ... there is absolutely NO reason why it can not be provided, none, zero - zip - zilch.
@myjunqueyourtreasure wrote:
And fwiw, I've watched your efforts from afar with great admiration.
What are they teaching MBAs these days anyway? It's obviously not Business 101
My sincere thanks ... its one thing to teach MBAs, its another to actually have someone on staff with one ... what's funny is this ongoing request of mine is very reasonable, PayPal figured it out to the tune of being able to go back 7 years. Every (not some, not most) EVERY financial institute uses a database to keep track of things ... monthly credit card bills are based on them, online banking is based on them, on and on and on ... its as simple as eBay and Adyen setting up a secure portal for members to access THEIR (Not eBay's, not Adyen's) transaction records.
@mr_lincoln wrote:
Gentlemen, first and foremost, thanks for replying to my post on the Weekly Chat yesterday. Since the Chat is closed now I wanted to respond in kind to the suggestion to look at the Seller Hub CSV in lieu of Managed Payments NOT offering a date range programmable CSV formatted database (like PayPal) to meet most of a Seller's accounting needs for manipulating their transaction data. Regarding the Seller Hub version please note:
- The eBay Seller Hub CSV formatted database is NOT date range programmable, there are pre-selected time periods to select from. So these are “canned” reports. Here is just one reason “date range programmable” is required:
Anyone in our state who has a Tax ID for Resale purposes has to report to the state either monthly, quarterly, bi-annually or annually. The reporting frequency is determined by sales volume and dictated by the state. We have to remit sales tax to the state for IN state shipments. The date range programmable functionality allows a Seller to create the report for their unique reporting frequency, the Seller Hub CSV canned reports do not satisfy that requirement and would force a Seller to download monthly files and merge them causing more unnecessary work.
- Columns U and AQ are numeric values formatted wrong.
U is the eBay Item number
AQ is the carrier tracking number
The Seller Hub CSV file download puts these numbers in scientific format (I believe that’s correct terminology) and when converted to the actual number the results may not be accurate. This is definitely the case for column AQ – Tracking number, when converted almost ½ the tracking number is converted to zeros and the original numbers are lost. The yellow highlighted cells are the converted number after the download.
- No eBay FVF Fees column (needed for tax purposes)
- No shipping FVF Fees column (needed for tax purposes)
- No Refund column (needed for tax purposes)
- No PayPal Fees (needed for tax purposes - granted the eBay CSV is ONLY for the eBay end of transactions and will not pull data from PayPal but if this is the basis for reports for Managed Payments it is still lacking in its completeness.
So in closing this initial post, the Seller Hub CSV formatted database is heading in the right direction but is not there yet. It needs to be more flexible with the date range programmable functionality as well as include other transaction info per the above post.
Hi @mr_lincoln, I first want to mention that it is a default setting in Microsoft Excel to format large numbers in scientific notation. I've not been able to find a way to change this within Excel (or other spreadsheets programs). Since this is something Excel does, you will need to be sure to format those columns every time a download is done. Before saving the file, format those columns and set the decimal place to 0. This will cause Excel to display the numbers in non-scientific notation. If the file is saved before making this change then the numbers will be altered, resulting in them ending in all 0's.
While it doesn't include information about fees or refunds, the Sold report that File Exchange already offers does have the ability to choose specific date ranges. This isn't an option with the Seller Hub download, so I'll be sure to pass your feedback over to that team (along with requests for fees and refund fields). Thanks!
@a_c_green wrote:
brian@ebay wrote:
Hi @mr_lincoln, I first want to mention that it is a default setting in Microsoft Excel to format large numbers in scientific notation. I've not been able to find a way to change this within Excel (or other spreadsheets programs). Since this is something Excel does, you will need to be sure to format those columns every time a download is done. Before saving the file, format those columns and set the decimal place to 0. This will cause Excel to display the numbers in non-scientific notation. If the file is saved before making this change then the numbers will be altered, resulting in them ending in all 0's.I think we're kinda-sorta on the same page as far as why those wacko Scientific Notation values (which look rather like overflows, actually) are coming in, although to be clear, the package tracking numbers should be treated as text strings, not numerical values of any kind, even as really big integers. (The USPS could be tracking their packages just as well with strings of letters, for what that's worth.) These tracking numbers should be transferred and stored as text strings even though they happen to be all digits.
While they may have been originally created from various internal values (e.g. origin ZIP code and/or destination ZIP code, and probably a checksum digit in there somewhere as well), once they are concatenated into a big long tracking number and assigned to the package, they should be stored for later reference as a string of text digit characters (i.e. "0" is ASCII 48, "1" is ASCII 49 and so on, in the same manner that "A" is stored as ASCII 65, "B" is ASCII 66, etc.) The tracking number should not be handled mathematically as something that a spreadsheet will try to interpret as a really big integer.
I was actually thinking the same thing about those numbers being stored as text rather then the current format being used.
