Sales numbering

Nice to get the customer order, but extremely surprised and preoccupied with the fact that the quotation number is incorrect (off by one)…

Would have thought that it was a typo but our quotation was attached and, indeed, printed with the wrong quotation number !. The report generated now on the subject quotation has the next number.

So after soliciting the users, it appears that two services generated a different quotation on the same day to the same client… the database output is perhaps easier to understand:

 id | revision | number  | sale_date |   state   |        create_date         |         write_date         
 40 |        0 | D23-034 |           | quotation | 2023-01-31 13:14:15.015595 | 2023-01-31 13:14:15.68889
 38 |        0 | D23-035 |           | quotation | 2023-01-31 07:26:24.809339 | 2023-01-31 14:35:35.197832
(2 lignes)

as one can see D23-035 is the culprit.

This first user started his quotation early on the morning of 31 jan, saved his work in draft, and once the supplier responded with the prices requested he hit ‘quote’ at around 14h35.

The other user already had his prices so he went strait to quote at around 13h14.

Both of these quotations were sent to the customer (different services) with the same number, D23-034!

Both of these users are on the windows gtk client for 6.6… and now, since all the problems with the various forms, have since upgraded to 6.6.4, .5 and this week 6.6.6.
The server is current with the sale modules sale_advance_payment, sale_discount, sale_history, sale_secondary_unit, and sale_amendment activated.

Quotations are like invoices, they have juridic value (and not only in France). Is it the client or the server (or both) where this could have gone wrong? Unfortunately, I’m not looking forward to check a hundred quotations sent by email to see if the initially generated quotation is correct. And unwilling to do that on a permanent basis…
hopefully a dev may have a hint that this is a known and already fixed problem…

We also notice that there is a missing field for the quotation date, one should always be able reproduce exactly the quotation with the same version and date… the sale date being once confirmed.

Another issue is that for purchases, we needed to set price_decimal=5.

Unfortunately, with sale_discount, there are numerous cases where the unit price has greater than 2 decimals (5 are displayed). There are [public] customers that are unable to treat the generated quotations because only the total line amount is rounded and not the unit price after discounting the base price. We are forced to manually redo the quotation.

There should be an option either on the sale, the customer (or maybe even site for some) to round the sale unit price to a different number of decimals, or at least to the same as for the amount field… at least the formula with then work without round-off: quantity * unit price = amount

Finally, we have a case where we receive a customer order who decided on a previous revision and not the last revision issued. How to rollback to the version retained?


The sequences used for invoices and quotations have no the same behaviour on Tryton.
The invoices sequences are strict (they can not have any empty value) but the quotation sequences are not strict.

I can not see it nor understand it.

And for the remaining part as usual this is off-topic as there should be only one topic par topic.

OK, I read Sequences vs Sequence Strict
I don’t see any reason to accept empty values on quotations, and they certainly need to be unique and stable.
Does this mean we need to patch to call [in set_number()] Sequence.get() with _lock=True to avoid this situation? (referring to in trytond/trytond/ir)

As I indicated, the user who created what ended up as ‘D23-035’ had the number ‘D23-034’ printed in the quotation he created and sent it to the customer. The number is set as part of ‘quote()’. It should never change.

Is it possible there is some sort of caching issue present at the time?

From all the text I can not see how someone could understand that.

Please provide a scenario to reproduce such thing because the code is clear that a sale can be numbered only once.

For the record, this was an invalid issue: regarding sale quotation numbering issue (#12129) · Issues · Tryton / Tryton · GitLab