Suppose user A creates a sale order S in company X. He then changes to company Y
Sales manager B, in company X, creates the invoice for sale order S.
Bug: the compilation of the report fails because of the user.name in the
template. Then the tracking update fails, making it impossible to validate the
invoice.
opw 1884915
- Create a SO from an opportunity, keep the status draft
=> the 'Quote(s)' number is 1 on the opportunity
- Confirm the SO
The 'Quote(s)' number is 0 on the opportunity, but when clicking on the
stat button 1 quote is displayed.
The `search_default_draft` (and the `search_default_sales` of the Orders
stat button) are not working since the action doesn't use the
appropriate search view.
opw-1888442
Steps to reproduce the bug:
- Create three stockable products: Kit, C1 and C2
- Create a phantom BOM for Kit with C1 and C2 as components
- Set the invoicing policy of the kit based on delivered qty
- Create an SO for the kit and validate it
- On the delivery order, just deliver C1 and create a backorder for C2
- Cancel the backorder and duplicate it
- Deliver the duplicated backorder and validate it
Bug:
The delivered qty on the SO line has not been updated to 1.
opw:1886315
- Create the following products in FIFO costing method and real-time
valuation:
Prod Final (F); Invoiced on Delivered Quantity
Prod Comp1 (C1); Cost = 20
Prod Comp2 (C2); Cost = 10
- Create the BOM Kit for F:
2 Unit(s) of C1
1 Unit(s) of C2
- Create a SO for 3 Unit(s) of F
- Validate SO and picking
- Create the invoice and validate
The price unit taken into account for F in the anglo-saxon accounting
entry is:
20 + 10 = 30
=> entry in Stock Output Account is 3 * 30 = 90
while it should be:
(2 * 20) + (1 * 10) = 50
=> entry in Stock Output Account is 3 * 50 = 150
This should finally fix issues corrected with:
9a7ed7c: price unit multiplied by the qty sold (*)
f1fdb97: price unit taking into account only 1 unit of each
component
(*) In the use case solved, the price unit was:
(6 * 20) + (3 * 10) = 150
=> entry in Stock Output Account is 3 * 150 = 450
opw:1886216
Two account had the same account code. Because of that, one of them always failed to be created and logged a psql error. To fix that, we totally remove this account, as it never got created anyway.
Making a bank account reconcilable is a very common mistake, and leads to confusing and useless data (the move lines made on this account) to be displayed in the reconciliation widget. With this commit, we make sure the user cannot make this mistake anymore.
In A/B testing mode, a given recipient will only ever receive a single
email from a given mass-mailing campaign, no matter how many mailings
were sent to them.
This is useful for A/B-testing various mailings in order to check their
results. But is very difficult to understand for users who simply want
to organize their mailings into campaigns.
Additionally, the A/B testing option is hidden as a technical feature, so
it is hard to discover in order to troubleshoot unexpected number of
emails sent by a given mailing.
It will be safer to keep it off by default.
(keeping the parameter explicit, to better show that it is on purpose)
This partially reverts dee5c31264
Fix on sale_coupon (enterprise) https://github.com/odoo/enterprise/pull/2224 needs this change to be able to merge
SO lines when a program generates multiple discount lines on different taxes.
Closes#24971
task-1866977
task-1832967
task-1857843
When sorting by a many2many fields (e.g. partner_ids) with one of the record
having an empty value on the sorted field, the comparison method used to compare
and empty record (e.g. res.partner()) and a name_get result (e.g. "Agrolait").
This is because the sort_field was initialized with the result of self[field]
but never assigned a new value below.
Fallback on an empty string when no record is found
Fixes#26908
- Create a partner in Germany
- Set an invoice address for this partner in Poland
- Create an invoice for the Poland address, but the delivery to Germany
- Validate invoice
The Intrastat reports the transaction in Poland, while it should be
Germany.
opw-1878590
The depreciation was hardcoded as starting the first of January.
If a user changed the configuration to set a different value than 31/12 it had
no impact.
In saas-11.3, this was improved to allow to configure the behaviour at 805f3a610
opw-1878927
It has been argued that a regression took place because of e2efec8e54
Before that commit, everything was reconciled together
After, only payments and orders with a partner set were
While that commit improved performances (there are much less move lines to reconcile),
it introduced an inconvenience business wise because of the noise created
by the unreconciled lines
This commit proposes to cut the pear in half by introducing an ir parameter
to choose between the two options
OPW 1883594
closes#26971
Christophe Simonis