When a product has multiple company taxes and b2c prices is enabled, price is
not computed properly and adds to the base price every company tax present.
This patch filters the company set on the company so taxes are computed just
for that company.
Part of the button was hidden by the (invisible) right column content
when using some particular themes.
This is because of a messy XML structure that cannot be safely repaired
in a stable version. This commit fixes the bug with CSS.
Note: this may need to be backported to 9.0 and the XML structure should
be improved in master.
Prefetching is underused when all fields are traversed one record at a time.
So instead, traverse all records one field at a time. This guarantees batch
prefetching/computation on every field being accessed.
- Set 'Tax calculation rounding method' to 'Round Globally'
- Create a expense product with a tax of 20% included in the price
- Create a expense of 19.99
- Submit the expense in a expense sheet
- Validate the expense
- Post the expense
- Register a payment of 19.99
The expense is not set as paid.
The source of the issue is that the tax line is created without being
rounded. In the specific example, two lines are created with amounts:
- 16.658
- 3.33166667 (Tax)
This introduces rounding error in the computation of the matched
percentage, and the expense is not set as paid.
We force the rounding of the taxes since the 'Round Globally' option has
no impact on an expense report.
opw-773908
- Create 2 companies: A is parent of B.
- Demo is in Company A
- Create 2 invoices for a partner: one in A, one in B (100 each)
- Validate the invoices
Connected as Demo, the 'Invoiced' amount on the partner form view (stat
button) is 100, while clicking on it shows both invoices (total of 200).
There is no need to manually add the company in the `where` clause since
the `_apply_ir_rules` will take care of adding the appropriate
multi-company rules.
opw-772479
Otherwise if a record rule is defined on a x2many field on the model, the creation will fail because
ir.translation creation check access rules on the model and in this case, the x2many relation are
not set yet.
Steps to reproduce the bug:
Let's consider a product A with a price of 100
Let's consider a pricelist P with a visible discount of 50% on product A.
Let's consider a quotation template Q with one line with the product A with 50%
of discount.
Let's create a SO with pricelist P and set the quotation template Q on it.
Bug:
The unit price of A on SO is 50 instead of 100 and the visible discount is 50%
instead of 75%.
With the fix:
The unit price is 100 and the discount is 75%
opw:771996
Use case to reproduce:
- Create a picking with a package
- Go to the source or destination package
- Click on package transfers
-> It displays all the pickings
This happens because the package transfer button calls
the all picking tree view that display them.
This commit use an action instead that will add a domain
on it in order to only display the pickings that used the
selected package.
opw-774013
- Create 2 companies: A is parent of B.
- Demo is in Company A
- Create 2 invoices for a partner: one in A, one in B (100 each)
- Validate the invoices
Connected as Demo, the 'Invoiced' amount on the partner form view (stat
button) is 100, while clicking on it shows both invoices (total of 200).
There is no need to manually add the company in the `where` clause since
the `_apply_ir_rules` will take care of adding the appropriate
multi-company rules.
opw-772479
- Create a customer invoice of 100, validate
- Refund the invoice
- Go to Accounting > Reports > Business Intelligence > Invoices
- A total of 200 is shown, while it should be 0.
- The same occurs with a vendor bill (-200 instead of 0)
The invoice lines have their sign modified at two places when used in
the report:
- in method `_compute_price` of `account.invoice.line`
- in method `_from` of `account.invoice.report`
The signs are computed with the following combination:
|Invoice type|`_compute_price`|`_from`|Report sign|
|------------|----------------|-------|-----------|
|out_invoice | +1| +1| +1|
|in_invoice | +1| -1| -1|
|out_refund | -1| -1| +1|
|in_refund | -1| +1| -1|
This is not correct: out_invoice and out_refund should have opposite
signs. Same applies to in_invoice and in_refund.
opw-772479
Closes#19954
- Set up a journal which only accepts SEPA payments
- Import a CAMT file which contains a statement containing:
No "Ustrd" data
A "AddtlNtryInf" description longer than 140 characters
- Reconcile the bank statement
A contrain is raised because the communication of the SEPA payment is
longer than 140 characters.
From commit https://github.com/odoo/enterprise/commit/ff84f8b7,
"AddtlNtryInf" is used if "Ustrd" is empty. However, "AddtlNtryInf" and
"Ustrd" do not have the same restrictions. "Ustrd" can have a maximum of
140 characters, while "AddtlNtryInf" can have a maximum of 500
characters.
opw-772009
That function is called when computing related fields in onchange mode.
The new implementation makes a direct access to the cache's implementation.
opw-772303
It seems to randomly save a bad value into the cache for star_date(time) field.
For already impacted database, it can be easily fixed with a simple update.
update calendar_event set start_datetime=start, stop_datetime=stop where allday = 'f';
update calendar_event set start_date=start, stop_date=stop where allday = 't';
Than can cause errors for google synchro.
Before this fix, if a (non-registered) user tried to unsubscribe an
address *not registered*, they'd get an unsub link, click on it, and
get a "Invalid or expired confirmation link." message, usually
wondering what the bloody hell happened.
Provide a clearer message in that case.
Observed via google sync, for some events being moved around during
sync the stop_datetime ends up being before the start_datetime failing
the sync. Not (explicitly) reading the computed fields from the old
record properly recomputes them during copy.
Underlying issue linked to (stored) computed fields when multiple
fields are computed by the same method *and* the creation provides a
subset of these fields explicitly: depending on the order in
which *recompute* iterates the fields, it's possible that some of the
fields provided explicitly get extracted (from the cache) before
fields not-provided trigger a recomputation (and overwrite) of
computed fields.
In this case `recompute` iterates [start_datetime, start_date,
stop_date, stop_datetime], if `start_datetime` and `stop_datetime` are
provided explicitly to create, first recompute will check for
`start_datetime`, find it in the cache and extract it, then it checks
for `start_date`, does not find it in the cache, calls
`_compute_dates` which writes all four fields, then it extracts the
recomputed `start_datetime`, creating an incoherence: `start_datetime`
is the one from the old event while `stop_datetime` is the one from
the update/computation. This may lead to invisible corruption if the
event is moved forwards (e.g. creates a multi-day event) and triggers
a validation error if the event is moved backwards (stop_datetime is
now before start_datetime).
ping @rco-odoo multi-field computes may need some special handling
with respect to invalidations & sequencing & the like (e.g. check
their caching as a unit or something).
OPW-771886
Martin Trigaux