Should there be single or multiple commands in cqrs for every condition? Example: If there is command GenerateAndSendReportToClient and it can find the client by SSN or by TaxNumber, should there be single command GenerateAndSendReportToClientClient that the user of the command can supply any of the two fields SSN or TaxNumber and in the command handler there be if logic to determine what is supplied and how to fetch the Client DomainEntity from the repository(i.e which method to use, FindBySsn() or FindByTaxNumber()), or, two separate commands GenerateAndSendReportToClientBySsn and GenerateAndSendReportToClientByTaxNumber with no branching logic in command handler. Having separate commands means there is duplication of logic and probably there will be some 'internal' command handler that contains it and uses some delegate to choose which and how a repository method be called.
This is probably a confused question, in that GenerateAndSendReportToClient sounds a lot more like a CQRS query message than a CQRS command. Yes, we're definitely asking the system to do something, but the thing we are asking the machine to do does not involve making changes to the system's "book of record".
(Probably - part of the difficulty here is that the name of a message doesn't tell us anything about its semantics, so trying to answer this is a bit like working in legacy code, trying to guess what "the original programmer" intended).
That said... when designing your message schemas, it's trade offs all the way down. There's nothing inherently wrong with having a single message that acts as a "GenerateReport" signal, with many optional elements in the message schema that describe arguments for the various filters when generating the report (in much the same way that a SQL query is a "message" that includes an optional WHERE "element" that allows you to narrow results").