Logically, Commerce's list of customers should not be disconnected from Drupal's list of users (accounts). But account is only a login and a password. There could be several users (accounts) which buy products from your shop every month, but they are one company (one bank account, one billing/shipping address, one CEO, etc.). So we have several users but one customer.
Or even worse, one man will have several accounts.
How to solve this problem?
Does it mean that only admin can register customer accounts and attach them to appropriate user accounts?

Comments

4drian’s picture

I'm very keen to hear anyone's input on this as well. I'd need a way to have a customer (a company) associated with one or more user accounts. I'd also need the ability to create an order on behalf of a customer and send them a quote as opposed to asking them to log in and put the order together for themselves. Will there be flexibility to allow for these B2B multichannel scenarios or will we be stuck with the traditional B2C (customer = named person = user who creates the order) style of operation?

Would it be possible to have a customer type where this can be either consumer (a person) or business (a company)? This separation would also assist with compliance on the distance selling regulations in the UK.

jbnewman’s picture

Personally (or more aptly, professionally), I have a need for one customer -> many users (B2B), which will drive me to have to build out my own e-commerce module if I can't find something that supports it. :-( Given I might have to write it any way, I'd much prefer to simply do the code mods to someone else's module than having to write it from scratch... would such a patch be welcomed? Any advice about it?

rszrama’s picture

At this point, customer profile information is decoupled from user accounts such that a single user might have multiple customer records (i.e. different addresses). I'm not entirely satisfied with the present solution, but there's no reason you can't work with it to maintain the reverse association. We need to support that, and figuring that one component out for you in Commerce will be a lot easier than rewriting everything else. ; )

jbnewman’s picture

I took another look at the commerce_customer_profile schema, and at my existing implementation (CCK-based; doesn't have commerce features currently), and I see we have both embraced the concept of a customer having a single "owner". I simply added the construct of additional "associated users". It seems that adding an additional table, plus the associated UI-components, should be what's necessary. (Am I missing something)?

Assuming that to be the case, I'll start wading through drupal 7 docs and working on a patch.

jbnewman’s picture

Having dug through the d7 docs & the Commerce code a bit more, I find myself wondering if a "commerce_customer_user" module would be appropriate here?

redben’s picture

Component: Commerce » Customer

Updating component...

redben’s picture

If only profile2 was decoupled from user...
I have a use case (travel) where i need to store customer info AND travelers info, without having duplicates. Meaning i can have a user ordering for a trip where the travelers are him and his wife, and the wife could have a different user account ordering other stuff for her and her husband, without having duplicate profiles.
A general purpose "party"* api module that's neither tied to user nor commerce would have been great. Just like address.

*Party
en.wikipedia.org/wiki/Party_(law)
rszrama’s picture

Status: Active » Closed (won't fix)

I'm going to close this out as it is indeed an issue for contrib. I can envision several ways to associate users together as part of an organization such that their orders are all assigned to the organization. However, at a minimum, DC will still maintain the relationship with the actual user who purchased the order. If that user has a company field or something on his account, you can then create Views or work via a module to add the additional order displays and customizations you need.

So, in short - the core behavior won't advance beyond 1 user = 1 customer w/ multiple customer records (for 1.0 at least).

I fully support contrib work to build out the X users = 1 "customer" of course. : )