For the second time we have a duplicate reference for two different orders, the first time both orders were created at the very same time, the second time the orders were created with 1 second difference.
Describe the bug
A clear and concise description of what the bug is.
So far it happened twice within a month or so, with hundreds of orders created just fine. We are unable to find out why so there are no steps to reproduce this at the moment, sorry.
Different order, same reference, different customer, different cart, same (or very close) date_add:
"id_order";"reference";"id_customer";"id_cart";"invoice_date";"date_add"
"1125";"C18101001125";"143131";"6367";"2018-10-10 22:06:36";"2018-10-10 22:06:36"
"1126";"C18101001125";"143130";"6372";"2018-10-10 22:06:36";"2018-10-10 22:06:36"
"2745";"C18102102744";"94587";"15912";"2018-10-21 21:01:59";"2018-10-21 21:01:59"
"2746";"C18102102744";"62536";"15904";"2018-10-21 21:02:00";"2018-10-21 21:02:00"
Additionnal information
PrestaShop version: 1.7.4.0
PHP version: 7.0
https://github.com/PrestaShop/PrestaShop/issues/11115#issuecomment-466052440
the source code is very simple for understand the problem :
public static function setLastInvoiceNumber($order_invoice_id, $id_shop)
{
if (!$order_invoice_id) {
return false;
}
$number = Configuration::get('PS_INVOICE_START_NUMBER', null, null, $id_shop);
// If invoice start number has been set, you clean the value of this configuration
if ($number) {
Configuration::updateValue('PS_INVOICE_START_NUMBER', false, false, null, $id_shop);
}
$sql = 'UPDATE `'._DB_PREFIX_.'order_invoice` SET number =';
if ($number) {
$sql .= (int)$number;
} else {
$getNumberSql = '(SELECT new_number FROM (SELECT (MAX(`number`) + 1) AS new_number
FROM `'._DB_PREFIX_.'order_invoice`'.(Configuration::get('PS_INVOICE_RESET') ?
' WHERE DATE_FORMAT(`date_add`, "%Y") = '.(int)date('Y') : '').') AS result)';
$getNumberSqlRow = Db::getInstance()->getRow($getNumberSql);
$newInvoiceNumber = $getNumberSqlRow['new_number'];
$sql .= $newInvoiceNumber;
}
$sql .= ' WHERE `id_order_invoice` = '.(int)$order_invoice_id;
return Db::getInstance()->execute($sql);
}
SELECT (MAX(number) + 1)
https://github.com/PrestaShop/PrestaShop/issues/11115#issuecomment-466335070
SELECT (MAX(`number`) + 1)
I see, so this is a race condition where two orders may get the same id. Nice find!
Hi @bm-services,
I did not manage to reproduce the issue with the last version 1.7.4.3.
I have different orders created in the very close date_add
I attached a screenshot.

Thanks to check & feedback.
I have the same exact problem, posted it on PS forum aswell https://www.prestashop.com/forums/topic/934098-1742-duplicate-order-code/



SOFTWARE VERSION:
Prestashop: 1.7.4.2 (migrated form an old 1.6.x if it can help understand something with MigrationPro)
Theme: warehouse 4.1.7
Nexi XPay: 3.1.0 from "Nexi Payments SpA"
COD+: 1.5.9 from "PrestaHost.eu"
PayPal: 4.4.2 from "Prestashop"
Hi @sirion89,
I used also the COD payment module provided by Prestashop but I did not manage to reproduce the issue.

Have you tried to contact the module author?
You can contact the developer of this module PayPal here: https://www.202-ecommerce.com/en/partners-modules/technical-support/
Thanks!
Hi @khouloudbelguith,
I actually tried more then once to test this on my local env but always failed. I didn't try to contact the author because i feel like that if this thing occour with 3 different payment module i hardly belive it's module's fault. Ofc it could be that they are 3/3 mistaken, but it points me into thinking that is something more deep
@sirion89, We need to retrieve the PHP error log and the debug mode report in order to find out what's wrong.
Thanks!
I can't put my production website in dev mode since most of the page stop working (undefined indexes errors that comes from extra modules that i didn't develop). It doesn't even seem an error, because all the customers report no weird blank pages, everything goes "all right" for them. Except the double order/payment.
I was thinking if it was session-related, i don't really know what those peoples achieve to do but i learned the hard way that customers can take ways that you, as programmer, will never think about.
Maybe it's someone starting their orders from smartphone and ending on desktop using the same account? maybe they click more then once? multiple tabs open? i tried some of them in my local but never reached what they did.
I could do what you posted, but not what my customers did. It's just 4 orders out of something like 1k i got in 15 days
So, it hard to reproduce it & it is randomly.
Duplicate order reference for different order is made with the same customer or with a different one?
All from different customers, i just checked online. Even with different dates but they all share the same issue
@sirion89, could you please provide me the COD module to test it.
This is a public space.
You can provide me the module by email.
My address mail: khouloud.[email protected]
Let's be safe!
Thanks!
@sirion89, No, I didn't receive any mail!
Thanks to check.
@sirion89, I sent you email, thanks to reply me by sending one.
The spam mail that I receive, I cannot download the zip folder.
Thanks!
@sirion89, it is ok with this module too.
I created two orders at the same time.

Thanks!
@khouloudbelguith mmm, it's very hard i guess. It happens with more then just one payment method and many other orders just looks fine. It has to be something related to the user-behaviour which make this happen. The sad fact is that we cannot simply call one of our customer preteding that he knows what he did "wrong" to make this issue happen :/
Sidenote: I deleted some of the older answer, just cleaned the place.
Hi @sirion89,
Despite our several trials, we could not reproduce your issue with the provided information.
It seems that your issue is not a PrestaShop's core bug but most likely a server configuration or customization problem.
I invite you to contact our support team: http://addons.prestashop.com/en/388-support to help you solve your issue.
Thanks!
Ty for the time spent, although i'm pretty sure it's related to PS, the guy which started this thread has my same issue, so it's not happening just to me.
Anyways, we will try to monitor this, if any new information helpful for debugging comes out, i will update this thread
For informations, I got the same error.
Since August, my reference on order is ALWAYS : REF005679
I'm trying to find what happened at this date.
Presta 1.7.3.3
Migrated from 1.4 with module
Paypal + other french bank
BUG Only on Production Database - not on TEST....WTF
Hi @fabrice-dresscodes,
Did you make any modifications in your Database table ps_orders?
As I said we need to retrieve the PHP error log and the debug mode report in order to find out what's wrong.
Thanks!
I don't think so...
I try to reproduce it on dev table...event if the git status is the same...
@fabrice-dresscodes, could you please provide the exact steps so I can reproduce the issue in my case also?
Thanks!
Hello,
I've the same problem too.
Two order with same reference.
In addition the second order is registered with a wrong customer. Maybe when the order has been created the query find wrong record.
The orders have 1 second difference.
Thanks,
Mario
Hi @manburg6,
Did you use any special method payment? did you use any social login connect?
We really need to retrieve the PHP error log and the debug mode report in order to find out what's wrong.
Thanks!
Sorry for late answer, I miss the notification email.
I have 3 payement method installe and activated: Bank Wire transfer, Paypal and COD.
Both the 2 two duplicated order are made using Bank Wire Transfer.
I do not use any social login connect.
I use Leotheme theme.
I try to find php error log, where I can find it?
Thanks,
Mario
You can find log here, the order was made the 8 decembrer 2018 al 9:37 am
Hope this helps.
I keep having this bug aswell, from time to time someone on my customer's website manage to do that. Another thing i noticed is that if you enter the order details you will see something like:
"customer paid xx , should have paid yy". Where yy is the SUM of the two order with the same reference total, and xx is fixed to one of the two order total. I don't even know if the customer actually paid the exact amount, seems like it gets splitted for unkown reason. I tried to search around and somebody else is speaking of splitted order but in case of different shipping method available for the product in the same order. This can't be my case since all my shipping method are available for ALL of the website's product
Hi @manburg6,
In your log file you a lot of errors with the "leofeatureviewstemplatesf" module, what is this exact module, it could be related to the problem?
Also, you have an issue with the "autoupgrade" module, did you make an upgrade?
@sirion89, we are trying to find the exact problem of this issue, if you any error log, thanks to provide us this errors.
Thanks!
I'm checking module with Leotheme support...
I've upgraded recently from 1.7.4.3 to 1.7.3.4 without any problem. I hope this solve the issue.
I'm trying to replicate the error and send you some more log....
@manburg6, thanks!
Waiting for your feedback.
I add a bit:
Befor to go live I removed the default demo customer from backoffice.
Now I've some record in ps_address table referring to that customer (id_customer=1) that don't exists any more...
I remove them.
No way.... I placed many order in the same time (1 second difference, as the two with same reference) but everything goes fine.
@manburg6, because you just deleted the customer & not his addresses.
Thanks!
I add a bit:
Befor to go live I removed the default demo customer from backoffice.
Now I've some record in ps_address table referring to that customer (id_customer=1) that don't exists any more...I remove them.
Sadly this is not the only bad thing that happen when you delete something in PS. My customer manager to remove a category and nothing got cascaded to the attached product, a lot of missing reference caused the product to doesn't save anymore, but this is offtopic here.
@khouloudbelguith im still trying to get some useful logs out of this issue, still no luck
No way.... I placed many order in the same time (1 second difference, as the two with same reference) but everything goes fine.
I tried this too and even @khouloudbelguith i guess, but this doesn't replicate the issue
@sirion89, ok thanks for your help.
I'm still waiting for your errors also.
Thanks!
In your log file you a lot of errors with the "leofeatureviewstemplatesf" module, what is this exact module, it could be related to the problem?
It was a warning due to PHP version.
Now I downgrade from 7.2 to 7.0 and warning disappear.
Thanks.
M.
@manburg6, thanks for your feedback.
@sirion89 any news about your issues?
Thanks!
@khouloudbelguith not yet, we found another bug in the while with the paypal module but we can't still understand what is going wrong with this. I guess it will take quite a while. We can't really put too much effort into this because the customer refuse to pay for assistance. I'll remember this post as soon as i have new info
@sirion89,
Thanks!
Waiting for your feedback.
Hi @sirion89,
Any news about your issue?
Thanks!
@khouloudbelguith nope sorry, it didn't even happen anymore during the last period
@sirion89, thanks for your feedback.
@bm-services, do still have the same issue?
Thanks!
Yes, we have this problem on several PrestaShop 1.7 (1.7.3.3, 1.7.4.0) when customer make several actions with his addresses (create new address or modify it) in checkout page. It creates multishipping orders, old address staying attached to a different carrier...
@bm-services, thanks for your feedback.
We need to retrieve the PHP error log and the debug mode report in order to find out what's wrong.
Thanks!
the source code is very simple for understand the problem :
public static function setLastInvoiceNumber($order_invoice_id, $id_shop)
{
if (!$order_invoice_id) {
return false;
}
$number = Configuration::get('PS_INVOICE_START_NUMBER', null, null, $id_shop);
// If invoice start number has been set, you clean the value of this configuration
if ($number) {
Configuration::updateValue('PS_INVOICE_START_NUMBER', false, false, null, $id_shop);
}
$sql = 'UPDATE `'._DB_PREFIX_.'order_invoice` SET number =';
if ($number) {
$sql .= (int)$number;
} else {
$getNumberSql = '(SELECT new_number FROM (SELECT (MAX(`number`) + 1) AS new_number
FROM `'._DB_PREFIX_.'order_invoice`'.(Configuration::get('PS_INVOICE_RESET') ?
' WHERE DATE_FORMAT(`date_add`, "%Y") = '.(int)date('Y') : '').') AS result)';
$getNumberSqlRow = Db::getInstance()->getRow($getNumberSql);
$newInvoiceNumber = $getNumberSqlRow['new_number'];
$sql .= $newInvoiceNumber;
}
$sql .= ' WHERE `id_order_invoice` = '.(int)$order_invoice_id;
return Db::getInstance()->execute($sql);
}
SELECT (MAX(number) + 1)
Hi @Alexandre17220,
Thanks for your feedback.
Ping @PrestaShop/prestashop-core-developers
Thanks!
SELECT (MAX(`number`) + 1)
I see, so this is a race condition where two orders may get the same id. Nice find!
@eternoendless thanks you!
@bm-services, @Alexandre17220, I’ll add this to the debug roadmap so that it’s fixed. If you have already fixed it on your end or if you think you can do it, please do send us a pull request!
Thanks!
@khouloudbelguith I have fixed it, but my correction cannot used for other environement because my customer don't change increment yearly or do other thing on invoice reference. For correct this for all instance of Prestashop, there is to alter table order_invoice or create a new table with trigger or maybe use a CRON for manage invoice number asynchronously periodically.
for my customer
I have change the auto_increment to max reference+1 :
ALTER TABLE ps_order_invoice AUTO_INCREMENT =
I made a override of order class and this
`public static function setLastInvoiceNumber($order_invoice_id, $id_shop) {
if (!$order_invoice_id) {
return false;
}
$sql = 'UPDATE `'._DB_PREFIX_.'order_invoice` SET number =id_order_invoice';
$sql .= ' WHERE `id_order_invoice` = '.(int)$order_invoice_id;
return Db::getInstance()->execute($sql);
}`
READERS : DON'T DO THIS IF YOU DON'T UNDERSTAND THIS
@khouloudbelguith the problem affect the last version of prestashop too..all version not simply 1.7.4.0
is There news about the correction of this problem ?
Hi @Alexandre17220,
Sorry not yet.
It is added to our bug roadmap, so it will be fixed, but PrestaShop is an open source project, so it can be solved before if someone submits a pull request to solve it.
Thanks for your understanding!
Same here with PS 1.7.5.0 + PHP 5.6 + Nginx 1.15.9 + bankwire module.
Only difference between 2 orders is "_id_address_delivery_" : one is with phone number and the other no:

Hello everyone,
I don't think that fix proposed here works in our case because it isn't the generation of the order (not invoice !) reference which causes problem but the generation of a second command which has no place to be.
See the problem in the attached CSV: id_delivery_address are identical, id_customer, id_order, even date_add, etc...
We have this problem also on a PrestaShop 1.6.1.23 in this example:
pe_orders.txt
A precision : this problem happens with multi-shop with a big volume of orders.
One of them is 1.6.1.23 with advanced stock management activated.
Another (1.7.4.3) hasn't enabled advanced stock management.
We had this problem on a mono-shop with advanced stock management activatedand it disappeared when advanced stock management has been unabled.
I really think it's linked to stock management.
Just a little update from my side:
trying to perform SELECT reference,COUNT(reference) FROM ps_orders GROUP BY reference HAVING COUNT(reference) > 1 gives 44 orders that share the same reference out of a total of 52860 (ps_orders rows number). I fear it will be DAMN hard to reproduce
With this request, our PrestaShop 1.6.1.23 has 333 orders that have the problem for 62406 orders.
Hi sirion89,
Have you enabled advanced inventory management on your shop?
I think that it's linked to this problem.
@bm-services If you mean configuration -> products -> product stock -> allow stock management yes, i have that enabled on my site (dunno if all the translations are right, my website is on another lang )
Yes that is it, and do you use PrestaShop warehouses?
@bm-services Do you mean the active theme? yes, it's warehouse. We made a child-theme out of it but yeah, that's the parent theme
No, I mean about warehouse fonctionnality linked to advanced stock management. It allows to assign stock in several warehouses.
@bm-services I don't think so. Where that option should be located? (btw we should clean this chat-like thing and leave only the useful comments)
Warehouses are no more available in PS1.7. What is your PS version @sirion89?
Warehouses aren't available from 1.7.0 to 1.7.2 only.
@Klemart3D 1.7.4.2
I have same duplication problem with PS 1.7.5.0 and I'm not using warehouses (only advanced stock management)
Hi guys, could you please tell us how you created the orders with duplicate reference ?
Did you make a CSV import ?
In my case no CSV import, just a PS 1.7.5 shop migrated from 1.6. Orders with a duplicated ref are "created" by customers (not by an admin in BO) with the traditional checkout and with usual carriers and payment methods.
this is the prestashop core issue.prestashop team focus on this issue.there is no other payment gateway issue.
Hi here, @marionf !
Hi guys, could you please tell us how you created the orders with duplicate reference ?
It's possible by ordering two products that have two different specific carrier. The order will be split into two (one for each carrier), but with the same reference.
Screenshot :

hey @bm-services @sirion89 Klemart3D,
Do the duplicated orders have different carriers? We are still trying to reproduce it. For what I can read, it is with different customer, but need to ask to be sure.
In my case it's not related to different carriers because it can be reproduced for a command with only one product (so with only one carrier) and one payment method.
In my last investigations, it can be related to addresses: sometimes 2 shipping addresses ID are sended in customer cart on PS1.7 but one of this address is deleted=1 in database, so that can create some problems like wrong shipping amount or wrong discounts.
It's very rarely and I never really understand how to reproduced it but it can be when a customer editing or deleting one ore some of it's address.
@Robin-Fischer-PS problem is related to multishipping, not us.
Hi,
I have a very similar issue, it's happening very often.
In my case orders have identical ref. code and customer details and the same datetime. The purchased items are distributed in both orders, while carriers are sometimes the same, sometimes different.
I have also noticed that in all cases the user had two different delivery addresses, and how @Klemart3D said only one address is visible in the BO. So I think the fact that the user was able to remove one of his addresses could cause the error.
Did you verify carriers assigned on products, in table ps_product_carrier?
Sometimes problem is here.
@bm-services yes I checked, there are only to rows in that table, but they belong to deleted products.

The issue is happening almost daily and in all the cases customer had deleted one of his delivery addresses, and in the two orders (duplicated) there is in the first case(half) the deleted address and in the second case(half) the new address. @khouloudbelguith
Fixed by #19139
Hi @Alexandre17220,
Sorry not yet.
It is added to our bug roadmap, so it will be fixed, but PrestaShop is an open source project, so it can be solved before if someone submits a pull request to solve it.Thanks for your understanding!
Hello! Anyone did find a solution? A lock system, cron, or any fix?
@iamtend0
Yes, I correct it a long time ago, I have overrided the ugly function "setLastInvoiceNumber"
Alter table order_invoice to add autoincrement and use it in setlastinvoicenumber
I think. maybe the presta team have correct it too ? Look the last source.
@iamtend0
Yes, I correct it a long time ago, I have overrided the ugly function "setLastInvoiceNumber"
Alter table order_invoice to add autoincrement and use it in setlastinvoicenumber
I think. maybe the presta team have correct it too ? Look the last source.
Thank you for your answer.
How do you add the auto_increment on invoice number with SQL ? Because there is already an auto_increment on the primary key.
So if I understand, you just auto incremented the number column and then deleted the SELECT MAX+1 part of the code to fix it?
I also have the problem on order references. I have got a lot of orders per day into FO & BO so when we make an order into BO along with a FO order (~less than 1sec apart) we can generate the same order reference for two different orders.
PS 1.7.6.7
I've the same problem:

Hi @HartLarsson,
It should be fixed in 1.7.7. Thanks for sharing.
@MatShir Where do you find information about this ?
1.7.7.0 beta change log : - #15514: Add condition to avoid duplicate invoice line. (by @FlorentinGarnier)
Invoice line in invoice, not duplicate invoice.. I think
Hi @Alexandre17220
If you check up on the thread, you can see thank the PR https://github.com/PrestaShop/PrestaShop/pull/19139 has close the issue.

The problem is not in this function in cart, but is in this ugly function :11115
Hi @PierreRambaud
Do you think the problem will persist despite your correction? What do you think about @Alexandre17220's concerns?
The problem might come from both parts.
Hi @HartLarsson,
It should be fixed in 1.7.7. Thanks for sharing.
i hope the upgrade from 1.7.6.7 to 1.7.7 will be possible wthout too many problems :)
@iamtend0
Yes, I correct it a long time ago, I have overrided the ugly function "setLastInvoiceNumber"
Alter table order_invoice to add autoincrement and use it in setlastinvoicenumber
I think. maybe the presta team have correct it too ? Look the last source.Thank you for your answer.
How do you add the auto_increment on invoice number with SQL ? Because there is already an auto_increment on the primary key.So if I understand, you just auto incremented the number column and then deleted the SELECT MAX+1 part of the code to fix it?
I also have the problem on order references. I have got a lot of orders per day into FO & BO so when we make an order into BO along with a FO order (~less than 1sec apart) we can generate the same order reference for two different orders.
see this : 11115
Hi @PierreRambaud
Do you think the problem will persist despite your correction? What do you think about @Alexandre17220's concerns?
The problem might come from both parts.
Wasn't mine, I just backport someone's pull request and fix tests :sweat_smile:
But I totally agree about the usage of SELECT (MAX(number) + 1) which is a very bad idea :/
Okay thanks for your input. We will say that the first PR backported by @PierreRambaud is the first part to solve this issue. I will reopen this issue. @Alexandre17220 If you think you have found the right solution, do not hesitate to make a Pull Request. We will be happy to review it.
@MatShir I confirm that this issue is a global mess 😅
I think many people observe the same issue (= duplicate order references) but there are actually multiple usecases, some which are faulty, some which are not.
I have noticed:
This usecase is not a bug ✅ . When a cart contains multiple products that cannot be shipped by a single carrier, then the order will be split into sub-orders. Each sub-order is being shipped by a different carrier but they all share the same order reference.
In my last investigations, it can be related to addresses: sometimes 2 shipping addresses ID are sended in customer cart on PS1.7 but one of this address is deleted=1 in database, so that can create some problems like wrong shipping amount or wrong discounts.
It seems there might be a issue related to customer using a deleted address but this seems to be random so it cannot be reproduced easily.
➡️ possibly a bug but as we dont have a step-by-step 100% reproductible scenario there is nothing we can do
We had this problem on a mono-shop with advanced stock management activated and it disappeared when advanced stock management has been unabled.
It seems there might be a issue related to using advanced stock management but AFAIK this comes from a module, not the Core then ? 🤔
Contributor @Alexandre17220 mentioned some wrong code in the logic of invoice number generation that is prone to race conditions issues.
As I said, I think many people observe the same issue (= duplicate order references) but there are actually multiple usecases, some which are faulty, some which are not. This GitHub issue is mixing all of these which is making the situation more ambiguous rather than helping. I suggest closing and locking this issue and opening new issues, one per _reproductible_ usecase to sort it out. Nothing will come out of this issue in its current state, there is too much informations that we cannot act on.
Most helpful comment
In my case no CSV import, just a PS 1.7.5 shop migrated from 1.6. Orders with a duplicated ref are "created" by customers (not by an admin in BO) with the traditional checkout and with usual carriers and payment methods.