The `map_account()` method expects a browse_record as
parameter, and returns a browse_record (possibly the
argument if no mapping happened).
It was being called with an account ID instead, so
fiscal position mapping would never match, and would
always return the argument itself.
The `fiscal_position_id` field actually depends on both
the `shipping_partner_id` and the `partner_id` field,
not just the former.
Theoretically the recompute should trigger on both fields
anyway because changing the `partner_id` will automatically
change the `shipping_partner_id`.
Unfortunately this onchange chaining does not work as expected
as of Odoo 9, at least when the `partner_id` field is set
to the same value (was done for optimization reasons).
This special case really happens when you edit the Partner
from a sales order form view, and save the changes.
It triggers a "dummy on_change" for the `partner_id`
value, with the same value as before.
If the edit changed the fiscal position or another
field on which it depends, a recompute is really needed.
Adding the direct dependency works around this limitation,
and is semantically valid, too.
An extra fix of this special case in the framework might still
be nice to have, though.
Ref: feedback ID 29042
This is related to revision
b65c67a259
The field `seller_ids` is a field which is set
on the `product.template`, and this is why
the condition `(x.product_id == product)` is being applied
in the list comprehension searching the current seller
of the product sellers.
The `variant` variable is a string containing
the attribute name of a variant.
Therefore, if a product tempalte has only one variant, without
any attribute (e.g. when you don't use variants),
`variant` will be empty, and therefore the condition
`if variant:` will be `False`, and therefore it won't search
in the product sellers with a specific `product.product`, while it
should, as, even if there are no attributes, there could be a
seller line with this specific `product.product`.
Besides, as we are in the `name_get` of `product.product`, and
not the `name_get` of `product.template`, we are always in the case
of a `variant`, this test is therefore pointless.
opw-682390
This grouping was causing problem at the time of bank statement reconciliation, if the expenses were set as already paid by the company, since we had only one account.move related to several bank statement lines although the DB structure wasn't allowing such a case (the link was made as a m2o from account.move to account.bank.statement.line where a m2m would have been needed).
In the earlier fix 327f88df, the computation of the amount crashes when the
field `tax_id` is not set. Simply add an 'if' statement to avoid that case.
On the Customer invoice, Vendor Bills and Payments list views.
The feature exists for Journal Items and entries, but not on invoices and
payments.
Closes#13915Fixes#13914
When fetching the journal items linked to a bank statement, the
counterpart items are not retrievd since they are not directly linked to
the bank statement. It makes the entries look unbalanced.
Closes#13673
opw-690231
The below revision force the use of `ABS` on the
`price_subtotal_signed` because of a migration issue:
649b289fa1
This leads to issues regarding the advances, in
`out_invoice` invoices, where this amount
`price_subtotal_signed` is negative, and should
remain negative in this report, otherwise
the advance is counted twice: Once with
the advance invoice, and a second in the actual
invoice where the advance is removed with a line
with a negative `price_subtotal`
e.g.
- A sale order of 500€ without taxes
- Create an advance invoice for an advance payment of 10%: 50€ without taxes
- A second invoice with the remaining: 450€ without taxes
In the invoices report, the total without taxes for this customer was
displayed as 600€ (50 + 500 + 50)
instead of 500€ (50 + 500 - 50)
opw-682390
Now, when the module is not found, instead to display a traceback, we open a popup to upgrade to Enterprise.
That will be wrong in case of outdated / wrong link, but in most cases, it is because it is an enterprise module.
This commit closes#13882
TODO: Remove zindex 1051 on planner in master/saas-14
Other modules that was overriding old name method was just ignored.
Drop retro compatibility fixes in next freeze (saas-14) and stop
useless renaming.
This commit closes#13865
The field was a stored computed field without dependencies, and therefore it
was never (re)computed. Add a simple dependency on the model `ir.model.data`
to make the recomputation everytime a view is modified. Moreover, when views
are created from modules, delay the recomputation of view fields until their
`ir.model.data` record is created.
When a account statement is validated, it's not possible to cancel a statement line.
To cancel a line from a validated statement, you must first reset to new the statement.
In this way, it's not possible to have a validated statement with unreconciled lines.
opw:690766
On a PO linked to a purchase tender, changing the quantity on a PO line
will trigger a recompute of the unit price. However, this recomputation
will take into account the unit price of the supplier pricelist, not the
unit price on the purchase tender.
opw-690483
When the purchase tender of a PO refers to a blanket order, the price
unit used to create/update the order lines doesn't take into account the
potential difference of UoM.
When returning an item by entering an orderline with a negative quantity
you got a warning message asking you to confirm a large payment
amount. Introduced by 5a3d9ce9ce.
Closes#13777
If you validate an order it will be sent to the backend. If you then
close the POS frontend somehow before clicking 'Next order' this order
will be reloaded from localStorage when reopening it. This is
problematic because it allows the user to then modify this order and
validate it again. Everything will appear fine but in the backend this
new, modified order will be ignored as it has the same pos_reference as
the one that was sent initially.
The deeper underlying issue is that there exists a brief timeframe where
the same order can exist twice in the db: both as 'order' and
'unpaid_order'. To ensure this does not happen this fix removes the
order from the unpaid orders after it is saved as a validated order.
Fixes#13538
Before the fix, the tax base amount is computed only for a complete
invoice line. However, depending on the tax sequence and their inclusion
in the base amount, the tax base amount might be different for the
various taxes of an invoice line.
We keep track of the base amount for every single tax, and refactor the
`_compute_base_amount` to take these values into account.
opw-691177
Closes#13819
When registering a payment on an account invoice with an automated
action which adds a follower "On Creation & Update", the function
recompute was triggered(due to the field residual_company_signed)
and the same followers was added two times for the invoice.
The fix avoid to unlink and create the same followers several
times(because it was the case with the function "_add_follower_command")
opw:690939
The form widgets did not apply the 'style' attribute to the result of
the rendering. Because of that, many small adjustment were no longer
possible. This commit makes sure that it is indeed done.
The following configuration leads to different results:
- Deferred revenue: 12 entries, 1/month, prorata temporis, 1000€,
date 15th of October
- Asset: 12 entries, 1/month, prorata temporis, 1000€, linear, date
15th of October
Deferred revenues and assets should give identical results.
opw-690034
This is required in order to have those bank journal items appearing afterwards in the bank statement reconciliation widget (blue line) for reconciliation.
This revert the fix made on 7bdd4de and replace it with a proper one that do create an account entry from stock_input to stock_output on a dropship move. That way, we avoid the manual change of account on supplier invoice. See the whole discussion on odoo#12687
Christophe Simonis