We have had two orders now that were duplicated. Upon receiveing e-mail notification of an order, we immediately retrieve the order, deleting it from the secure site and verifying that it has been deleted. In both instances, these orders were received, deleted and shipped. Approximately one month later, we received the duplicate order. When I say duplicate, I mean even the order number was identical, so it's not like the customer re-ordered the same thing. Is it perhaps a flaw in the transfer from the cart to the order form? Perhaps the customer's cart didn't clear? But, I would think if this was so happen, it would have happened sooner than a month after they placed their order. This has cost us $$ as one of the duplicate orders went out. We caught the second one. Please let us know. Also, I have purchased 3.0 but am waiting to change the site till after x-mas season. Too much work this close to the holidays. Has anyone else experienced this problem? Any solutions?
What probably happend is that the customer bookmarked the "Thank You" page ... and then (accidentally) went to that bookmark at a later date. In that case, if the order file had already been deleted from the server, there would be no way to verify that the particular order already existed so it could get placed again. This will not be an issue once you upgrade to uShop 3.0, but in the mean time while your using uShop 2.0, if you find that many customers are bookmarking the "Thank You" page, you may just want to link customers to your own custom "Thank You" page by specifying the "thankyou_url" parameter in your uShop 2.x Order Applet. Such as:
PARAM NAME=thankyou_url VALUE="http://www.yourdomain.com/thankyou.html"
And then have that "thankyou.html" page just say something like:
"Thank You! Your order has been placed."
You may also want to mention on that custom "Thank You" page that:
"You will be receiving an email receipt of your order."
We received two orders from two different people who ordered on the same day two hours apart and the order number was exactly the same. Is this a bug in the program? How can we prevent this from happening?
The order number is a randomly generated 7-digit integer.... and unless your server has a problem with it's clock and/or the seeding of its random number table... the chances of getting a duplicate order number are litterally one-in-a-million.
Apparently that one in a million happened or something else might not have been setup correctly.
What is your email and I'll send you the duplicate orders. Maybe you can figure out what happened.
Actually, I meant to say one-in-TEN-million ... so you must be getting a ton of orders :^) Just kidding.
Anyway, we did receive one other report of a duplicate order... so we're looking in to it, but so far haven't found anything that could be causing it. (The code that generates the random number is pretty basic - just two lines of code). If anything, however, we will be releasing an update soon where we've added a check to help prevent duplicate orders.
On a side note, the other person who had the duplicate order in uShop 3.0 was using an NT server. What type of server do you have... UNIX or NT?
Also, if you want to send us your duplicate orders, you can send them to firstname.lastname@example.org. By looking at them, maybe we'll be able recognize what happened there.
We are using LINUX 6.2.
One additional piece of information. From the order reader we only see one order with that particular order number. However, since we have order notification in place, we received two emails with the same order number from two different customers.
I also checked the order data directory and there is only one order file with that order number. It was from the customer who ordered after the first one so I suspect he overwrote the file of the other.
If we didn't get the email notification and only used the order ready we would not have known there were two orders with the same order number.
We don't need millions of orders. 50 orders a day would be enough for us.
I've emailed the duplicate order to the email address you've provided.
The same thing happened to us. Same day, two hours apart. The second order overwrote the first in the reader, but the emails have the same number generated as the random order number.
Any ideas on how to stop this? We keep our orders on the system and have not deleated any of them, so it had the data in place if it was supposed to be checking it prior to assigning it over.
Also, is there any issue that would occur by leaving all the old orders on the system? In other words, other than order depth, is there a reason to clean the order regestry periodically?
Are you referring to uShop 2.0 or uShop 3.0?... Assuming that you are referring to uShop 3.0....
That is interesting. Out of curiosity:
1) Was the second order just a repeat of the first order... or was it actually a new order with a duplicate order number?
2) Also, are you using one of the built-in payment processing systems to process payment information?
In any case, we are currently testing out a modification to the script in which we added a couple checks to prevent duplicate order numbers. This mod should be availble in the next update that we release (probably in about 2 weeks because we are adding/testing out some other things).
As for leaving the old orders on the system, it really doesn't matter that much (other than disk space - but the files are small anyway).... However, if you are NOT using one of the external payment processing systems to collect the credit card information... and thus, the credit card information is being stored in the order files.... then I would suggest deleting the order files every week or so... just to keep credit card numbers from unnecessarily sitting around on your secure server... just in case....
Sorry ... that's 3.15! No live processing, just manual entry from the ushop information at our counter card terminals, as the orders are being filled by our employees.
Yes, it was a new order with a duplicated number. The e-mail receipts came in 2 hours apart. The second order overwrote the first in the system, where the data from the first was replaced by the most recent in the data files. Order number one was for all intent and purpose ... gone from the system. This is the first time this has occured. We've done about 600 orders, so far.
Will we need to upgrade to 3.3 then the newest update, or will a straight upgrade work? All but that one anomaly is perfect, and working just like clock-work.
I would like to make a recomendation. A sequential order numbering system would be much better than a random sequence. If you offered enough place values and starting number control, a merchant could integrate their current sales order system directly with their online system, which would help it fit into their current accounting model and help it run easier. The way it is now, we have to manually generate a cross reference to the cart order number to keep the records accessible.
Thanks for the feedback.... and yes, we are considering some other options for generating the order number instead of just picking a random number....possibly by incorporating the current date within the number too. TBD.
As for the next update, since it looks like it is going to be another update to both the applets and the CGI scripts... all you will have to do is replace all of the .class files and replace the CGI scripts.... regardless of the version you are currently using. (So, no, you do NOT need to upgrade to 3.3 before upgrading to the next version. We'll post more information if there are any special instructions.)