As HighCore noted, DataSet isn't a good choice of a Model, but otherwise that sounds about right, there are a couple of concerns I would have from your post though.
You mention that you have variable "type" this is a large red flag. If you have variable types, how are you going to have consistent columns in your data grid? Now, if you mean that you are going to have a different data grid for each type (perhaps using typed Data Templates) then that would be ok.
When you say "format the data" I hope you mean "store it in a data object". WPF binds to properties of objects, so your datagrid should look something like:
<DataGrid ItemsSource={Binding DataItems}>
<DataGrid.Columns>
<DataGridTextColumn Header="Name" Binding="{Binding Name}"/>
...
</DataGrid.Columns>
</DataGrid>
Basically, make sure you bind to objects that are populated from your Model. The ViewModel is definitely the object that should be performing this translation.
Update
I apologize for not understanding the purpose of your application, in that specific application, what you are talking about makes more sense. That being said, I will try to address your concerns:
In general, you should need to change your model/view/view model if the underlying data context or objects changes. C# is strongly typed, and the whole point of WPF is to have declarative, strongly typed UIs. I understand that you are trying to show "generic" data, but unless you are doing a "SELECT *" type query, you are going to need to change some code anyways. If you know what the view that you are displaying is, then changing all the code if a field is modified/added is perfectly acceptable (and even desirable, because it forces you to account for the change everywhere it affects).
Variable, or "weak" types are a red-flag because, as noted above, C# is a strongly typed language. Strong typing has a lot of advantages, least among them good compile-time error checking. If you want to be in a weakly-typed environment, think twice about which language you are using.
This goes back to the generic data. You can use typed Data Templates to accomplish some "formatting" changes based on type, but this is in a polymorphic (as opposed to weakly-typed) scenario. You could use a converter to perform the currency format you describe, but I would think about what you are trying to do and make sure that it is the direction you want to go.
Update 2
Strong typing should be just fine for this scenario. In fact, you are communicating with a WCF service, which by definition is strongly typed (this is the whole point of DataContracts, if you aren't doing it this way, please fix it and save yourself a lot of trouble). So we know your model (the WCF service) has strongly typed data objects, with properties like "Sales Date", "Client Name", "Sale Import", "Vendor Name", and "Sales per client". Now we just need three views (or even one flexible view) to accomplish your three scenarios.
You certainly do not need three binaries, even with the three views approach (you just need a way to select which view is active). You could even have an app config that determines which "client" to use, or load your views through MEF. The one flexible view approach takes a lot more work, because you have to bind your column collection instead of having it statically defined (a problem, incidentally, I am currently working on for one of my projects).
In short, there are many ways to have different views appear. I would not recommend changing the view based on the data, because your user wouldn't expect it, and it will be extremely messy to implement. If you want "Client 1" to only have access to "View 1" I would set it in the app config or only distribute the "View 1" plugin and load it using MEF. If all clients should be able to see all views, some kind of combo box or navigation bar is in order.
Update 3
Having (potentially) multiple views for the same view model, and especially multiple view models for the same model, is one of the reasons to use MVVM! I'm glad you were able to discover this. On to your questions:
As to your first comment:
Your model (on the WCF side) won't have any knowledge of user filters, unless your request includes them. There isn't a problem with including that information (in fact I would encourage it to keep network utilization down), but you need to be aware of that when designing your service contract.
View models always (without exception to my knowledge) live on the client side. The client-side "model" becomes the WCF proxy in your scenario.
As to your second:
There is absolutely a way of creating data model classes from your Database, in fact, I would encourage it. .NET has a library called Entity Framework (currently at version 6.02, available on Nuget) that will automatically generate database "objects" with automatic foreign-key navigation and a host of other features (MSDN). A word of warning, EF classes, in general, can not be sent directly via WCF (due to the navigation properties, the recursion breaks the serializer). So, anything you want to send to your clients should be sent as a manually created DataContract, and a class on the server translates between the two.
I don't know about a link, but having multiple views is pretty simple, you just use a Content Presenter and set the backing UserControl property whenever you want to change. It can also be accomplished by using a tab control, and probably an infinite number of other ways.:
<ContentPresenter Content="{Binding CurrentView}"/>
See my note above on using EF classes with WCF. Even if you don't use EF, in general it is recommended to use custom built data objects as your contracts. That way, you are only sending the information that is needed, and your contracts library isn't cluttered with database/model objects.
Update 4
1. Remember, you don't want to expose your database objects directly to WCF, and you especially don't want to do this with EF objects (because of the navigation properties). So you could: (A) use EF for your DAL and translate to Data Contract objects for WCF (recommended) or (B) create your own model objects, that could potentially be the same as the data contract objects (though I would still keep them separate) and do the DAL through ADO.NET or something similar. If you use EF, the database CRUD operations are very easy to do, as you noted.
You only need a different view model if the data is different. If your view model consists of (primarily) a large collection of objects that the different views just display differently, then I see no reason to duplicate the code in multiple view models. The rule-of-thumb is: The View Model should be independent of the view. As long as you don't have any view specific code in your VM, you can reuse it for as many views as you want.
Your final question is huge, and while I am happy to give you my opinion, you will find that if you asked 100 engineers this question, they would all give you different answers (as it seems you have already found).
So, to start with, you are absolutely right. Using MVVM (or any design pattern) will increase the amount of code you have to write, sometimes dramatically (especially when you are just starting a MVVM project, the amount of boilerplate code seems absolutely ridiculous at times).
However, the point of design patterns is not to make our code size smaller, it is to make it more extensible, maintainable, and testable. Specific to MVVM, you have the ability to put multiple views on the same view model (as you have seen) and the ability to put multiple view models on the same model. This means if you want to add a view or view model, you don't have to rewrite a whole bunch of code. Additionally, both the view model and model are easily testable since they have no knowledge of the UI.
In general, my rule of good design is Use Common Sense!. If it is likely to be changed/extended in the future, using a design pattern is almost always worth the extra code. If I am just going to throw it away in an hour, who cares?
Like I said, the applicability of design patterns and when deviations are ok is a huge debate in software engineering. I would encourage you to just go with what makes sense (thinking about the future of course) and refactor when you are wrong.
Please let me know if that addresses your concerns, of if you have more questions.
