Can't eliminate index scan
Just because you have a covering index doesn't mean it won't scan, nor does it mean that a scan isn't still the best way to access the requested data.

You're returning, what, 3 million rows? Even if that's not most of the table, it still wouldn't make much sense to perform 3 million seek operations, nor is it likely there would be any benefit in seeking to the first row and performing a range scan for the rest. There is also the issue that multiple EXISTS clauses - multiple of which do not join to the index's leading key column - will not likely all be able to take advantage of the same output from the seek. And you have filters on all of the INCLUDE columns - they're not part of the key, so seeks on those columns are going to be difficult (in fact the only case where I've seen an index still be used to seek when there are WHERE clauses against non-key columns is when the column was BIT, and those scenarios did not introduce all the other variables you have above). You're also using PIVOT and aggregating, which I'm sure don't help.

Also, what table is CodCampo in (why isn't it properly prefixed with a table alias)? You may have one or both of the following two problems: 


It is a disjunction (OR clause) which can discourage seeks (see Paul's answer here).
If it is in tblcliente, then your index is not covering anyway.


You could try running the query with the FORCESEEK hint (also mentioned in Paul's example) and it will either fail to produce a plan (unlikely) or you will get a plan that you can share with us and, if you also share the scan plan you get without the hint, we can give further insight into why SQL Server chose the scan instead.

As an aside (this certainly won't help you get a seek), since the estimates were far lower, I'd check that your statistics are current.

And finally, don't always assume that a scan is bad and something you need to eliminate! In a lot of cases, a scan really is the best way to retrieve the data.