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?
Cheers,