Why generate an Order database record before the Customer finishes placing the Order?

Question

I'm working with an ordering system and trying to understand first of all why it was designed the way it was.

One of the things I can't understand is why the system creates a unique Order record for a potential customer even before the customer places the order.

So, what happens is the order goes in and chooses what they want to buy and then, before the Place your order button is displayed, an order record is already saved for the potential customer.

The effect of this - which is what is bothering me - is that there are thousands of abandoned orders in the system where the user never clicked on the final Place your order button to finalize the sale.

Shouldn't the order record be generated only after the user clicks "Place your order"? Why do it otherwise?

Answer 1

Judging from what you said, application provides very useful functionality. It remembers everything user selected, so he can close the page, check other outlets, think some more, get back to your site and see his order saved for him.

Also, ten thousands additional rows in database will cost you a penny, so I see no reason to worry about it. And if it turns into a problem, you can routinely clean them up, e.g. if user doesn't show up for a month.

Answer 2

Francis, there are a lot of reasons for this the first and formost being analytics and while there are other ways to achieve this, it is a good way to know (a) was the order abandoned and (b) at what point in the process. It is also good for letting the user come back and "checkout" 2 days later :)

Answer 3

Does the system work in the general ecommerce fashion with seperate "basket" and "order" entities? Or does it work by simply building up an order entity as the user add items to their order and then finalises that?

If the latter scenario then, as already mentioned, it probably works in the way you describe as a means of storing an order in progress. But if it's the former scenario (with a separate basket), then you're right in thats it a little odd and does seem unnecessary.

Usually dedicated ecommerce systems designed from the ground up, separate out the concepts of "basket" (a work in progress) from "order" (the finished product). But you do find a lot of systems that may have evolved over time, and might not have been originally designed with ecommerce in mind, where you get process occurring that are a little messy and less than optimal.