Jump to content

Archived

This topic is now archived and is closed to further replies.

piernas

Ordering process question

Recommended Posts

I've been studying how oscommerce processes orders. When I was looking at some issues at the code that retrieves the order data I found something I didn't notice 'til recently:

Currently oscommerce manages all of these data in this way:

  • You can create an account by providing your customer data (name, company name, address, telephone, email...). This will be the default address from now on.
  • Then, you can add up to four additional addresses. You may then choose another address as a default address; but in this case, if you did not provide the same name, the account holder will change and the account name will refer to the data on the main address you select. So that way the only personal details that is still there from the original customer is the email address.
  • Additionally, over the checkout process you can choose different shipping and billing addresses. The order will then store the following data on the database:
  1. Customer address: Name and address from the default address.

  2. Billing address:  Name and address from the default address (or the selected one over the checkout process).

  3. Shipping address: Name and address from the default address (or the selected one over the checkout process).

In 99% of the cases default (customers) address will be used for billing, for shipping or for both addresses. Most cases the database will hold the same address repeated three times.

This is the logic I understand as correct for customer accounts:

  • There should be only one customer for each account. If for some reason one individual acts in representation of another person or company he should create/use another account. So, client details as company (in this case the customer should be the company not the individual/employee), full name, gender, email or contact number should not be edited once the account is created, unless some data has changed.
  • A customer should have a billing address where the invoice must be sent (and in some countries used for taxing). This address should be unique, same as client details.
  • He may have several shipping addresses (i.e. retail points for a business, usual and holidays address for an individual...).

 
The way I understand that it should work is:

  1. Customer creates an account and his name, company and email are written into the customer account. The address provided is stored as the billing account. This account may be editable but must refer to the account holder. This is the main (and unique) address if the customer does not provide other shipping addresses.
  2. Then customer can create additional accounts and set one of those as default shipping address for his convenience. It may contain the same addressee or a different name.
  3. In the order processing the customer may choose if the shipping address is other than the billing address. In the case of a shipping address exists and it is marked as default it will be pre-defined. If there's no default shipping address options to create or select one will be offered.
  4. If the billing address is not correct customer will have to modify (not choose another from the list so account holder could change).

I'm not sure if this is how your stores work. It's the logical way in my opinion. I would like to hear your comments as shopowners.

Share this post


Link to post
Share on other sites

To keep it simple...

 

In OSC, CUSTOMERS -> ADDRESS_BOOK in an ER diagram is an one to many relationship (well, throttled by max entries in address book). Address can either be for billing or for shipping, and the default address is used for both unless it was changed at checkout.

 

This is what I have done to my b2c shops...

 

1) Moved attributes phone numbers to address_book as we would like to be able to verify the bill to and ship to info as needed by calling the payee and the receiver. An order can have a different customer, bill to, and ship to entity (these actually come in handy as they can flag potential fraudulent orders).

 

2) Use simple registration (email and password only) to encourage customer sign up. This also go in parallel with Facebook login as FB had tighten the customer info given within the default scope in FBLogin. We store all customer email in one place regardless of if it's a store sign up or FBLogin or even just for newsletter. The flow of the checkout does change but it is one change for all...yes, core code change is needed...

 

Today, you won't find as many stores who would require as much customer info just to sign up. Tim

Share this post


Link to post
Share on other sites

×