ShipScript has been an eBay Community volunteer since 2003, specializing in HTML, CSS, Scripts, Photos, Active Content, Technical Solutions, and online Seller Tools.
1 BEST ANSWER
Accepted Solutions
Having seen the data, here are the issues that testing exposed (which match the advice given by @dollybeauty :
Error 1:
"Error - Variations Specifics and Item Specifics entered for a Multi-SKU item should be different."
The test file contained these three columns that were populated in the Item Row, and that were duplicated in some manner in the Variation rows.
*Quantity *StartPrice C:Color
1 11.98 Red; Blue; Black; Grey; Baby Blue; Brown; Aqua; WhiteThe Quantity and StartPrice threw a warning that the system was able to overcome, but the C:Color column was fatal. The C:Color failure had nothing to do with the formatting of the values or the values themselves — Color could not be populated at all.
The solution was to leave those three fields empty in the top Item Row. It appears Color was fatal due to being a duplicate name used for a variation Attribute (treated as a variation Item Specific). In any event the C:Color heading could remain, but the column had to be left entirely empty for this product; meaning the particular Item Specific could be used by Item Rows for other products, but not by the Item Row for this particular variation product.
Error 2, 3:
"Error - Variation Specifics provided does not match with the variation specifics of the variations on the item."
An eye-glazing hurdle with 56 variations was verifying the data in the rows. There was a typo in one of the last rows:
Variation Size=XK|Color=White
It should have been:
Variation Size=XL|Color=White
With removing data from the three fields in the master record (Item Row), and with correcting the typo in one Variation Row, the file uploaded successfully to File Exchange.
Other tests:
I had to perform a lot of tests while nibbling my way toward the above results, so let me share what else I've learned.
1. Line Ends: Windows machines produce files where lines end in CR-LF (carriage return character followed by a linefeed (newline) character, sometimes shown as \r\n ). My experience many years ago showed that Apple used only the CR character and Unix/Linux and OSX+ used only the LF character to denote end of a line, while DOS and Windows have always used both. The test file used only LF and File Exchange accepted that without issue.
2. Order: I tested various arrangements of the two attributes Size|Color in the VariationDetails column, and order was not an issue. There could be Size|Color in the Item row and Color|Size in the Variation row, or the same mixup in alternating Variation Rows. Same with the PicURL to be associated with each color - it was not dependent on the order of the VariationDetails field.
3. Picture Arrangement: Instead of trying to put each PicURL on the same row as a matching color, I successfully put the eight pictures on the first 8 rows of variations, so there is no need to correlate to any specific variation combination. Instead, each picture is tied to a specific (color) Option, not to any one combination. However, more carefully matching a picture to a color row might make it easier to later add or remove a block of colors and its photos.
4. Spaces: One of the colors, "Baby Blue", had a space in the variation details. The space is fine within an option value, and the same holds true for using it to attach a photo to that color:
Size=XS;SM;MD;LG;XL;2XL;3XL|Color=Red;Blue;Black;Grey;Baby Blue;Brown;Aqua;White
Size=XS|Color=Baby Blue
Baby Blue=https://www.always...balloons-baby-blue.jpg
5. Headings: I left the C:MPN column populated for each variation (without populating the master Item Row) and also tried using the CustomLabel column for that data instead. Both worked fine.
@shipscript wrote:5. Headings: I left the C:MPN column populated for each variation (without populating the master Item Row) and also tried using the CustomLabel column for that data instead. Both worked fine.
However, note what @mypaymentstest just stated in another thread....
"C:MPN doesn't have the option to apply variant information. You can only provide parentline information for Item Specifics."
So even though File Exchange did not complain about the C:MPN column, perhaps File Exchange didn't apply it either. @mypaymentstest should the variation data in "C:MPN" be moved to the column "CustomLabel"?
Another question: on the upload screen, the Action count is 57, but when complete, the Action count becomes 1. Which count applies to the 5000 upload limit the number of data rows or the number of listings? Thanks
Your successfully uploaded multi-variation listing had hit-and-miss success with your server-hosted photos. eBay was able to pick up some of them, but missed a few here and there. The reason is that your server was not able to respond quickly enough when being peppered with image requests from eBay. Although you were transloading only 11 photos, eBay missed four of them, and that's a pretty poor rate for so few photos. 
- One solution is to address the throughput rate with your shared hosting service.
- Another is to upload a revision file with image replacements.
- The last solution is to manually revise your listings to upload replacements for those that failed to transload.
Find Skipped Photos
You can always use the photo scanner tool to see which photos failed to transload.
http://www.isdntek.com/ebaytools/BulkPhotoScanner.htm
Enter (1) sellername and (2) country, (3) click "Get Items".
When Buttons appear, (4) click Fast Scan.
When you have only a few items, you can review the URLs that appear in the grid, where it is usually pretty easy to see those that are not eBay. With a lot of listings, it may be easier to generate a report at the end of the scan for a File Exchange formatted list of Externally hosted photos (FE Ext Listings). Although the report will not be organized for variations, it will at least show the problem URLs for each listing.
@huntfor wrote:I opted to upload a revision file with image replacements....
Can you please define the word "transload" in the context we're using it in?
We download from a server to our desktop. We upload from our desktop to eBay. When passing data from peer-to-peer, from one server to another, it is often referred to as transloading because the desktop is not in the mix. However, you could also define this situation as your server uploading to eBay, but in reality, eBay is fetching from, or downloading from, your server. So, which is it, up or down? Transloading just means the two cloud-based peers are working it out between themselves and we don't worry which is up or down.
