Most of the "principles" in SOLID (which are more like guidelines in most cases) are very context dependent, and we can't really see whether they are violated by the system you describe because we don't have much context.
For example:
We can't tell whether you have violated the single responsibility principle, because determining what is and is not a responsibility of a piece of code requires understanding how that code is specified, and how that specification is likely to change in future. If handling stock levels can change independently of how individual stock items are described, then grouping these together in the same module could well be a violation of SRP. But if both are consequences of the same specification (e.g. because you have a single supplier and the description is in the same format the supplier provides, so any change to one is likely to also involve a change of the other) then SRP is not violated here.
The validity of the Open/Closed Principle depends heavily on what the clients of a piece of code are, and whether they are considered part of the same module (and therefore likely to evolve together, be tested together, and so on) or different ones (at which point the stability that OCP provides can become very important), so without knowing how your book objects are actually used we can't tell whether this is violated.
Interface Segregation again depends on what the clients of an object are, not what the object itself does. While Christophe's answer identifies a likely violation of this, it is only actually a violation if there are separate modules in your system that would use the separated interfaces he proposes. If there is only a single module that accesses books or ebooks, and it always uses all of the facilities you describe, then there is no violation.
Dependency inversion requires detailed objects to depend on abstractions rather than the other way around, but all of the objects you describe have a similar level of abstraction. We'd need to see a much larger description of how your system uses these objects to know whether DIP is satisfied or not.
I've skipped Liskov Substitution out of the list above, because I really think of it as a different category. The four principles above are useful design guidelines. LSP almost always causes serious problems when it is violated. It is a much less subjective rule. But it is also dependent on the detailed behaviour of your objects. If your ebook object has valid behaviour for all of the methods included in your book objects, then LSP isn't violated. But if a client of book objects could fail due to ebook objects handling stock in an incompatible way (for example), then LSP is violated. A lot depends on what the observable side effects of your methods are, and even how they are documented as working.
Of all of them, I think LSP is the most likely to be violated in the system you describe, because I can't see a reasonable way an ebook could implement the replenishStocks() method that couldn't cause some client that isn't written with ebooks in mind to fail. And as Christophe points out, ISP is probably violated too. The others, we really don't have enough information to know.
As an aside, the SOLID principles don't contain any guidelines that are intended to promote code simplicity. For real world applications, they should always be used alongside such guidelines (and with an understanding that in many cases they will conflict with them, and that it's up to you as a system designer to work out which should take priority). Kent Beck's rules for simple design are a good starting point.
EBookclass, if you want to change howreplenish stocksis done, you will changeBookclass, so for me both classes have single responsibility.