SRP principal say:
a class or module should have one, and only one, reason to change
I have some Facade class as my service layer classes. e.g SaleService, that it provide some methods e.g SaveOrder(), CancelOrder(), CreateOrder(), GetAllOrders(), GetAllPlannedOrders(), ...
I only put them together because of their conceptual relations.
Does using such classes with this methods, that may have more than one reasons to change(), violate SRP? If yes, how can I handle this problem?
The facade pattern does not violate SRP per se. Often the facade pattern hides a complex interaction between underlying objects. In this case the 'single responsibility' for the facade is managing these interactions. As long as these interactions do not change, there should be no reason for your facade to change. If the interactions get really complex, it may be worthwhile to split the implementation of your facade in multiple objects again.
If I look at your examples, I do not get the impression that you are really trying to hide complexity, so it might be interesting to reconsider the use of the facade pattern here.