Object-oriented purchase data structure
Headers and namespaces
#include &quot;bits/stdc++.h&quot;

That's not a standard C++ header; prefer to use standard headers so that others can use your code.
using namespace std;

Bringing all names in from a namespace is problematic; namespace std particularly so. See Why is “using namespace std” considered bad practice?.
Naming
Choose a consistent naming convention and stick to it.  A common one that's closest to the majority of your code is to use PascalCase for types, camelCase for members and snake_case for variables.
Class Base
A default-constructed Base will have default-constructed Id and Name members.  It probably makes no sense to default-construct; I think it's better to explicitly declare a constructor:
public:
    Base(std::string id, std::string name)
      : id(std::move(id)), name(std::move(name))
    {}

Once initialized, there should be no reason to change the name or id, so we can remove the setters.  The accessors can be made const, so we can call them on instances of const Base:
    std::string getName() const { return name; }
    std::string getId() const { return id; }

Class Item
This seems mis-named - it's more like an &quot;order line&quot; that specifies how many items and their price.  Again, a default constructor seems wrong, although defaulting the quantity to 1 makes sense:
public:
    Item(std::string id, std::string name, double price, int quantity = 1)
      : Base(std::move(id), std::move(name)),
        itemPrice(price),
        itemQuantity(quantity)
    {
        if (itemQuantity &lt;= 0)
            throw new std::domain_error(&quot;negative quantity&quot;);
        if (itemPrice &lt;= 0)
            throw new std::domain_error(&quot;negative price&quot;);
    }

Whether it's reasonably to modify the price and quantity after construction really depends on your application, so I can't comment on that, but the getters should both be marked const, like the ones for id and name.
Also, I'll add the standard warning that floating-point is usually a poor choice for financial accounting - you'll avoid numeric rounding if you choose instead to represent currency amounts in integer values of the smallest denomination.
Class customer
Although customers may have names and identifiers, does that really make them the same kind of thing as items?  Unless you have a use case where you may want to use them interchangeably, public inheritance isn't really what you need here.  It's a common trap in OO design to assume that because two things are made from similar pieces that they must be similar things.  In some cases, it really is mere coincidence.  By way of analogy, chairs and dogs are both quadrupeds, but blindly choosing to treat them alike is a mistake that could turn around and bite you.
It is extremely kind of you to credit all your new customers with 5000 currency units in their accounts - but it might not be good business sense (even if they are Zimbabwean Third Dollars).  I recommend 0. as a more sensible default.
If the customer object is intended to be an autonomous object, it should be responsible for crediting and debiting the account, rather than setting the amount; I'd expect something more like:
void deposit(Currency amount)
{
    balance += amount;
}
void withdraw(Currency amount)
{
    balance -= amount;
}
Currency balance() const { return amount; }

(Real implementations usually involve some locking, so that concurrent operations don't interfere with each other, but that's a whole review in itself)
Why can a customer buy only one Item?  Usually, an order is composed of several items (each with a quantity) and refers to a customer (who may at a later date order more items - it's bad business to restrict them from doing that).
Something that looks really strange is this:
void print(){
    cout &lt;&lt; Custitem.getName() &lt;&lt; &quot; &quot; &lt;&lt; Custitem.getId() &lt;&lt; &quot; &quot; &lt;&lt; Custitem.getQuantity() &lt;&lt; &quot; &quot; &lt;&lt; Custitem.getPrice() &lt;&lt; &quot;\n&quot;;
    Custbalance -= Custitem.getQuantity()*Custitem.getPrice();
    cout &lt;&lt; Custbalance &lt;&lt; &quot;\n&quot;;
}

Why does the customer have to pay each time you print their order?
Usually, print() would look something like
std::ostream&amp; print(std::ostream&amp; o) const
{
    return o
      &lt;&lt; Custitem.getName()
      &lt;&lt; &quot; &quot; &lt;&lt; Custitem.getId()
      &lt;&lt; &quot; &quot; &lt;&lt; Custitem.getQuantity()
      &lt;&lt; &quot; &quot; &lt;&lt; Custitem.getPrice() &lt;&lt; &quot;\n&quot;
      &lt;&lt; Custbalance &lt;&lt; &quot;\n&quot;;
}

and the debiting of the account would be a separate (non-const) operation.