Both of those options would not work for an application such as mine. What boggles my mind, is how standard my application really is in the ecommerce industry.
I have our products set up on meijer.com, kmart.com, sears.com, amazon.com, wayfair.com, overstock.com, hayneedle.com and many mom&pop ecommerce sites, as well as a few I have coded myself. All of these sites host all 15,000+ items/variations based of spreadsheets that I have designed to be a university template. There is a standard in the industry for this sort of thing. MAP & MSRP pricing, SKU, UPC, Customs Codes, the whole 9 yards, all very standard.
Also, normally in ecommerce, they aren't called variations, but parent/child relationships.
Anyways, using the very product data spreadsheet that I've used for all of these companies and websites, it isn't usable with your plugin. Let me explain a normal load: spreadsheet has well over 15,000 products, for instance our tire covers have 1 parent sku and 34 children skus (17 sizes in at least 2 colors). For all of these websites I mentioned, including my own, you just designate what is parent, what is child, map the columns to the destination table and import CSV. Done.
It is my understanding that perhaps your CSV import suite *might* be able to accomplish this, but who would honestly feel that $100 is worth it, especially with out trying it first? Not to mention, you have to actually set up all these extra attribute columns... making it very confusing. It would be simpler to set up a "template products", with all relevant variations. Then download a .CSV template based on the sum of all template product variations. That way Woo can determine the extra attribute columns, not the user. Why would I pay $100 for a system that can't determine custom attribute columns on it's own? Or at least have a admin page that allows you to map the columns....
Secondly, what I outlined up there isn't even the best approach, it's just the most universal across ecomm sites. What I do in my own websites is record the upcharge amount for each option. So then you only have to upload a spreadsheet with the parent sku's, which is significantly less, then assign the options and the shopping cart calculates the totals based on base price + upcharge.
Stock, if it needs to be managed, is simple enough. Attach a qty to parent or child options and delegate which is more important.
My only options with this plugin were:
a) manually "link all" variations on the thousands of parent skus, then manually enter all children skus into the variations, then manually enter all children sku pricing into the variations. months of work.
b) pay $100 for a CSV-plugin that I haven't seen perform so no guaruntee that it works.
c)pay for some other plugin that claims to allow for upcharges, again, expensive and no reference on it's performance.
As for the third party plugins, I have tried countless. None of them allow for variation imports. A few claim they have been working on that for months, but no such luck.
Forgive my tone, but I'm amazed at how little this plugin understands how large ecommerce sites work. I spent over two weeks trying to get this plugin to do things properly, and I'm just so frustrated. I didn't want to spend a lot of time coding myself or copying my old source, but that's my best option now.
You also mention all of these oversights are covered in the documentation: I have been all through it in the last two weeks. Some of it is marginally brushed upon, and if it is, it's pushing the majorly expensive plugins.
Here's my thoughts: why not include the CSV Import suite, and other ecommerce standards like MAP pricing, custom forms and authorize.net API-integration, and offer them at a reasonable price. I could convince my boss to let me spend $30 on a whim for scripting that may or may not work, but $100?? I've purchased plugins in my day but 100 is steep.
Also, you have some form of validation that keeps people from messing with your data, and that frustrates advanced users. But hey, it works real well. I dissected your code and found where all the information is stored, and how, for product variations across numerous records and tables. Mostly the WP_posts and WP_posts_meta tables. Based on this information, I tried altering my tables myself to mass-import my data in the backend via phpmyadmin. I apparently missed a few spots, because after woo validated it would reset all my entries. Validation is necessary but the level that is present didn't make the platform feel very "open".
My feeling on this plugin is that it is meant for small stores out-of-the-box. Additional extensions may be available that may pick up the slack, but they are expensive and I personally feel they should be available out-of-the-box, because this stuff is so standard.
Anyways, I didn't expect a response from one of the devs, so I remorsefully apologize for my tone. Please understand I spent a couple weeks trying to make it work, even trying third party plugins, only to decide that my only real option is to stick with my own source. I grew very frustrated and very remorseful that I ever took the suggestion for Woo, and I hope I might warn others that think could do these things with it too.