Just as an additional top this, one thing to consider is what if you want to allow users to be both supplier and shop?
What you would be better off doing is actually extracting the concept of a user as a person, away from the concept of what a user can do.
So, for example you may have the following Class'
User (The actual person logging in, and only information related to authentication.) Shopper (Someone purchasing or who can purchase) Supplier (An entity/company that sells things) Order (A base class that holds logic for an order) Purchase extends Order (Holds logic specific to being placed by a Shopper) Sale extends Order (Holds logic specific to being serviced by a Supplier)
Then simply use relationships to manage the application flow, referencing Sale or Purchase respectively.
User would simply house data and logic used for authentication, nothing more. A user could then register but without any constraints on what they can cant do.
Upon making a first purchase, a Shopper record is created, that is associated with a user, but with additional info needed to be able to service their purchase, both by the Supplier and the application. At this point a Purchase (order) is associated with the Shopper.
Lets say that User then wants to sell something, they list an item, at which time a Supplier record is created (and subsequent items etc). If a Shopper then buys their item, the order is created (by the user creating a Purchase), but it is managed as a Sale from the perspective of the Supplier.
Not only does this give a lot more freedom with regards to scaling the application, but it better represents the contextual business language commonly used within eCommerce.
All in all, much better, and all it requires is a couple of relationships, so much simpler!
Hope that helps :)