Hi,

I have tried searching the forum for this bug I've enountered a while a go. I always thought it was related to the 'Duplicate order notification e-mail, and duplicate stock decrement' issue which was finally solved in D6-2.7 (http://drupal.org/node/1192018)

But since upgrading this bug kept popping up. It's quite easy to replicate;

- add product to cart and hit checkout
- don't enter any required address fields but just hit review order
- repeat a couple of times

Then go checkout admin/store/orders and you'll see (well in my case) that there is multiple rows of the same order by the same user all in_checkout but with incremented order IDs. So if a user has 10 validation errors in a row the order table is polluted with 10 useless db rows and the order ID is incremented with 10 for no reason.

Has this been mentioned before and can any replicate? Or is it maybe my setup / mix of modules causing this?

Cheers

Comments

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented
Title: Order ID increased on validation error? » Order ID increased on validation error on checkout page?

Changing to a more descriptive title!

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

This doesn't happen to me on a new install of 6.x-2.x-dev. The first time Review order is pressed a new order ID is generated, but then if further validation errors occur, the same order ID is recycled. Only if I navigate away, change the cart contents, then go back through checkout is a new order ID generated.

Perhaps this is caused by a contrib module which doesn't handle checkout validation correctly?

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented

Hi Longwave,

Ok, will test on a dev machine by disabling suspects one by one! I'll post back my findings!

But why increase the orderID when one navigates away? The customer is still working on the same order, I don't understand why a duplicate of the order has to be made as the old orderID will never be used again?

Cheers

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

If your customer changes the cart, it's not technically the same order if they already tried to check out, and you might want a record of what they attempted to order before changing their mind. You could say if they only change one item, it should be the same order, but at what point do you draw the line when it does become a new order?

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

Also this helps stop very old order numbers being recycled. Imagine you have a customer who tried to check out months ago, but failed for some reason, then comes back and completes checkout. In the meantime you may have had thousands of new orders; you probably want the order numbers to be roughly in sequence, and not give them the very old number they were originally assigned.

This is fixed in 7.x by trying to keep the order active until a timeout (fixed at 10 minutes) at which point a new order number is generated.

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented
Title: Order ID increased on validation error on checkout page? » Order ID increase on cart alterations is bad behaviour!
Status: Postponed (maintainer needs more info) » Active

Hi longwave, (please read with a smile)

I think these are pretty bogus reasons for the order ID to increment.
And honestly to me it sounds a bit like a "it's not a bug it's a feature" explanation :)

A webshop is often an online extension of a business;

Imagine a shop owner incrementing the receipt number on his register everytime a customer decides last minute to not take the blue but the orange bubble gum. In real life the shop owner sets the register to substract and scans the item to be taken off the total again.

Same with larger businesses. When a fax with an order arrives, someone from the sales department enters the order into the administrative software. Now an hour later the client calls he wants to add three more products. Do you really think there is a business in the world that would duplicate the previous order to add 3 products and leave the old order at some 'never completed' status?

It's not recycling old numbers, it's activating them! Which is rather normal in business a.f.a.i.k. The incremented sequence of order numbers is not important at all. Also because 'roughly in sequence' doesn't cut it anyway! That's why this module was developed; http://www.ubercart.org/project/uc_invoice

I really believe the increase of an order ID like what's happing now is bad functionality not reflecting real life business which might have become a feature after sneaking into the module as a bug and should be corrected!

Hope I'm not sounding too harsh, reading back it might come accross as harsh, but it's not the way I meant to write it. I just don't know another way of explaining it better than with those examples.

Cheers,
Bart

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

You can just delete old "in checkout" orders if you don't want them. And there are use cases in some stores for the existing behaviour, so admins can see previously uncompleted orders and try to figure out why customers did not finish them.

In 7.x this will effectively be fixed by #1298550: Create new 'abandoned' order status. (although probably not in the way you'd like). If you want to improve this in 6.x, then feel free to submit a patch to fix the existing behaviour, but otherwise it is likely to stay as-is for the foreseeable future. I still don't consider this an actual bug, perhaps it could be improved, but there are more important things to work on in Ubercart in my opinion so changing this is low on my priority list.

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented

Hi longwave,

Fast reply! Thanx! :)

I agree it's nice to see uncompleted orders so a sales team can maybe place calls to see why a customer didn't finish an order. But this is nice for uncompleted orders only. Not for altered orders.

Imagine someone adding stuff to a cart but not checking out yet, order ID 111. A week later he adds more stuff to the cart but not checking out, order ID 222. Then a week later he removes some items and adds some more again, order ID 333.

Now someone from sales goes through the list of orders left in checkout and calls clients starting the oldest order. So sales finds order 111, calls the client and asks why he didn't complete the order, client's answer; 'Au contraire my badly informed sales agent, I did and I actually bought more than the items you are referring too'... That will make you look good, not! And if you have a busy webshop and there is no reference between order ID 111, 222 and 333 it's a hell of a job for sales teams to find out of 333 is actually an altered version of 111 if possible at all!

I did take a look at http://drupal.org/node/1298550 and it's an improvement indeed but not a solution to this issue (not bug :) )

I will see if I can come up with a patch but before I put in the time, will this be committed? (if coded correctly ofcourse) Since you don't think it's a bug I'm worried that the time I put into this is a waste if it won't be committed.

Also I wonder what others think? Preferrably others also having experience in retail/sales as I believe this is not a code issue but a business issue.

Cheers

wodenx’s picture

wodenx CreditAttribution: wodenx commented

Well - another issue that enters into this is identity theft. If you keep an order-in-progress hanging around indefinitely in an anonymous session, then the customer's personal information becomes vulnerable if it's not a private computer. I guess you could clear the order details and still reuse the order number - but then you have no way of knowing whether the returning customer is the same as the original one, so probably better just to mark the original order as abandoned. Of course this is not an issue for authenticated users - there you could simply associate the order with the current user, and that's probably not a bad idea.

In the scenario you describe in #8, there is a way of linking those three orders: use views to filter by customer email. Though as I say, if the customer is anonymous you have no reliable way of being sure it's actually the same person.

There was quite a bit of discussion of this issue at #1285938: Create order on initial checkout and the issues it references with regard to how this should be handled in 7.x, if you're interested in the logic that led up to the way it's being implemented.

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented

Hi Wodenx,

The issue you are mentioning with identity theft is what's currently is a possibility you mean?
I like your idea for authenticated users.

I think the order ID is nothing more than a auto incremented db field and shouldn't be communicated as an order ID. It's there to make life easier technically but not usefull administrative or business wise. Like I wrote 'roughly in sequence' isn't good enough. Maybe a revisioning system for orders is better. Everytime a user edits the cart a new revision is made under the same order ID. That way a sales team has better data to check what items had been removed and maybe contact customers as to why they removed the item? But the order ID isn't incremented for no good reason!

Then when a customer checks out a invoice ID is attached which should be in 100% sequence and his/hers old order IDs can be set to abandoned or cancelled. Also a setting to set in_checkout orders to abandoned after X time would be great and keeps everything clean.

I've read thru the issue queue you've mentioned. Interesting views and opinions!

Cheers,
Bartezz

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

Yes, the order ID is nothing but an autoincremented field but this is still enough for many stores that are already happily using Ubercart.

Order revisioning is very unlikely to be implemented now in 6.x but is a possibility in 7.x now we have order entities.

Separate invoice IDs are an open feature request at #982920: Better invoice/ billing system - German legal requirements like invoice number, date and so on and I think there is a contrib module somewhere that implements this to some extent.

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented
Category: support » feature

Hi longwave,

It's enough for me too! But not for the tax inspectors :) Like mentioned in #98920 orders have to be numbered consecutively by law in many countries (for all I know ALL countries in Europe have this legislation).

I think http://www.ubercart.org/project/uc_invoice solves this issue as a workaround. But it would be great if 7.x would solve this without contrib modules, maybe in combination with order revisioning like mentioned. So I've turned this into a feature request :)

Don't have any 7.x setups running currently but probably will be in the near future so I can test if yuou need me to!

Cheers

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Status: Active » Closed (duplicate)

As a feature request this is the same as #982920: Better invoice/ billing system - German legal requirements like invoice number, date and so on, so closing as a duplicate.

danisha’s picture

danisha CreditAttribution: danisha commented

Bartezz... The uc_invoice doesnt seems to be a workaround for this issue. going on every order page and creating a invoice number is a bit tedious job. I have no idea why haven't anyone not submitted any patch or a workaround to this multiple in checkout order status. This just takes a lot of database space as it creates multiple in-checkout orders. Please reply me if anyone got a solution. I am using last ubercart module for drupal 6. This seems to be a problem with ubercart drupal 6.

Bartezz’s picture

Bartezz CreditAttribution: Bartezz commented

Thanx for letting me know danisha! I haven't been working on the project in question for a while thus haven't been looking into this much but good to know anyway! Thumbs up!

danisha’s picture

danisha CreditAttribution: danisha commented

After hours of head banging, I had to hack the core ubercart drupal module. I dont know why but the ubercart uc_cart.module unsets the order session everytime the ubercart checkout page is loaded. Hence when the page is loaded or any validation error is there on the checkout page, a new order id is created for preventing the identity theft(which i have no clue what it is).

Coming back to my point. I just commented out the line 142 and 150 in uc_cart.pages.inc of ubercart.
eg:- unset($_SESSION['cart_order']);

I m in ubercart drupal 6

Now since the cart order is not unset hence there are no multiple in checkout status order created. Seems to be working fine for now. I know that hacking core ubercart module is not good, but i couldn't fine any other solution for this. Please do reply if it will cause any future error.
Thank you.