Discussions

Customers & Users

Hi,

I think there is room for improving the way 'Customers' will be handled in Ubercore.

Our admin people have a lot of trouble dealing with the fact that a 'customer' does not exist until an order has been placed, even though a User for that 'Customer' is created.

I think the customer data for addresses, people, contacts etc could be better abstracted or more tightly tied to the drupal user. As it stands 'Customers' are really just fields in an order and thus you have multiple entries for each company when you View Customers.

Psy
Posted: Nov 1, 2009

Comments

chrisstrahl on November 12, 2009

Actually, most businesses Orchestra targets with Ubercart are not pure-play ecommerce businesses. Almost all of them have some back-end system driving their ecommerce implementation. Most of the time they want their customers in the system with the appropriate billing addresses, shipping addresses, and user accounts already created.

I would argue that this is almost a universal expectation of my client base - when they turn on ecommerce all of their existing customers (or at least the ones they choose) will already have an account up and going in Drupal/Ubercart. We currently get around this by adding a ton of custom CCK and code to the Users area of Drupal and tieing that in to the order process. It's really hard to do correctly, and I think that having a "customer" object would be awesome.

chrisstrahl on November 12, 2009

Being a "Customer" in most systems requires some basic data. Here is my vision for what this would look like:


  • A customer with a code and name stored in the system

  • Basic information (main contact number, web site, etc)

  • A stored billing and shipping address (multiple of both would be ideal

  • A list of associated users and contacts

  • The price list and terms associated with the customer

Some nice to haves:


  • "Consolidating Entities" or parent companies that can be related to other companies for billing or delivery purposes

  • Validity dates for customers

  • Maximum discounts allowed

  • Maximum / minimum order values

  • Reseller certificate information (probably would require a complex use of taxonomy or something)

Ryan Ryan Szrama on May 9, 2010

It's definitely on my radar, but I'm not sure it'll make sense here. One of the strongest arguments in favor of a customer entity separate from a user account was by TR, the fact that you might need to join multiple users or customer records from various systems to a single customer account. The customer may or may not have an actual user account on the Drupal site. In this case, an expanded profile wouldn't be helpful, but a separate customer entity with a user reference field would.

matt2000 on May 10, 2010

In theory, profile2 does not assume it's entities are attached to users either. A profile is simple 'a set of data that we know about someone.'

So in my mind, the fact that someone is a customer is simply one of those things we know about them. In this light, a 'customer record' could be nothing more than a set of order IDs stored in a profile.

If you really need something more, then I'd suggest that a customer entity should be nothing more than a collection of Foreign keys to other entities. (orders, profiles, user(s), etc.)

Practically speaking, for example, I'd rather that 'billing address' be a property of a profile rather than a customer. And order might store only a pointer to a particular revision of that particular profile field.