I will give you an example first:

public interface LoginAuth{
   public String encryptPassword(String pass);
   public void checkDBforUser();
}

Suppose you have 3 databases in your application. Then each and every implementation for that database needs to define the above 2 methods:

public class DBMySQL implements LoginAuth{
          // Needs to implement both methods
}
public class DBOracle implements LoginAuth{
          // Needs to implement both methods
}
public class DBAbc implements LoginAuth{
          // Needs to implement both methods
}

But what if encryptPassword() is not database dependent, and it's the same for each class? Then the above would not be a good approach.

Instead, consider this approach:

public abstract class LoginAuth{
   public String encryptPassword(String pass){
            // Implement the same default behavior here 
            // that is shared by all subclasses.
   }

   // Each subclass needs to provide their own implementation of this only:
   public abstract void checkDBforUser();
}

Now in each child class, we only need to implement one method - the method that is database dependent.

When To Use Interfaces

An interface allows somebody to start from scratch to implement your interface or implement your interface in some other code whose original or primary purpose was quite different from your interface. To them, your interface is only incidental, something that have to add on to the their code to be able to use your package. The disadvantage is every method in the interface must be public. You might not want to expose everything.

When To Use Abstract classes

An abstract class, in contrast, provides more structure. It usually defines some default implementations and provides some tools useful for a full implementation. The catch is, code using it must use your class as the base. That may be highly inconvenient if the other programmers wanting to use your package have already developed their own class hierarchy independently. In Java, a class can inherit from only one base class.

When to Use Both

You can offer the best of both worlds, an interface and an abstract class. Implementors can ignore your abstract class if they choose. The only drawback of doing that is calling methods via their interface name is slightly slower than calling them via their abstract class name.

In layman's terms:

Interfaces are for "can do/can be treated as" type of relationships.

Abstract ( as well as concrete ) classes are for "is a" kind of relationship.

Look at these examples:

class Bird extends Animal implements Flight;
class Plane extends Vehicle implements Flight, AccountableAsset;
class Mosquito extends Animal implements Flight;
class Horse extends Animal;
class RaceHorse extends Horse implements AccountableAsset;
class Pegasus extends Horse implements Flight;

Bird, Mosquito and Horse are Animals. They are related. They inherit common methods from Animal like eat(), metabolize() and reproduce(). Maybe they override these methods, adding a little extra to them, but they take advantage of the default behavior implemented in Animal like metabolizeGlucose().

Plane is not related to Bird, Mosquito or Horse.

Flight is implemented by dissimilar, unrelated classes, like Bird and Plane.

AccountableAsset is also implemented by dissimilar, unrelated classes, like Plane and RaceHorse.

Horse doesn't implement Flight.

As you can see classes (abstract or concrete) helps you build hierarchies, letting you inhering code from the upper levels to the lower levels of the hierarchy. In theory the lower you are in the hierarchy, the more specialized your behavior is, but you don't have to worry about a lot of things that are already taken care of.

Interfaces, in the other hand, create no hierarchy, but they can help homogenize certain behaviors across hierarchies so you can abstract them from the hierarchy in certain contexts.

For example you can have a program sum the value of a group of AccountableAssets regardless of their being RaceHorses or Planes.

Note: please forgive the C# syntax, but the principle of the answer is the same for Java and C#.

Now when i started programming I noticed that in all subclasses i basically needed to do the exact same thing

Based on this, it seems like you think abstract classes are only allowed to declare abstract methods. This is not the case.

An abstract class is a class that cannot be instantiated directly (only its derivations can be instantiated). An abstract method is a method in an abstract class which must be implemented in the derived class.

But an abstract class can have non-abstract methods:

public abstract class Artikel
{
    public int ArtikelId { get; set; }

    public string SayHello()
    {
        return "Hi, I'm artikel " + ArtikelId;
    }
}

When you derive Artikel into subclasses, you do not need to repeat the method body of the SayHello method. Its body has been declared in the base class and can be used by all of the derived classes.

I thought of making Artikel not abstract and put an interface between Artikel and the other classes

Interfaces prevent the ability to create a common method body. If you were to use an interface:

public interface IArtikel
{
    string SayHello();
}

Then you will be required to implement this method separately in every class:

public class Book : IArtikel
{
    public string SayHello()
    {
        // custom book logic
    }
}

// And the same for all other derived classes.

It's also possible to make an seperate class which inherits from Artikel where I can put all the methods, but then there the methods would still be needed to made three times, one for each subclass right?

Don't take this the wrong way, but your attempts at solving this suggest you don't really master OOP. If this SeparateClass was created as another (4th) subclass from Artikel, how would you expect e.g. the Book class to rely on the methods found in SeparateClass?

Is it a bad design choice if I keep Artikel as abstract?

Keep Artikel abstract, but give it non-abstract methods (i.e. with method bodies) for each method that you are now copy/pasting between all of its subclasses.