Both store triggers on reconcile_ref are triggered by the same condition,
but seen on 2 tables different, but they always happen together, so no
need for both.
On regular Odoo, the only problem is the performance: the write operation
is performed twice, but on a system with connector or other parallelization
technology, this provokes lot of concurrency problems.
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
When processing a partial reconciliation in a foreign currency, a
currency exchange difference might be generated during the
reconciliation process (see OPW for a detailed use case).
This prevents the user to process the reconciliation since he will get
the error: 'You have to provide an account for the write off/exchange
difference entry.'
The fix is to use the company-related foreign echange gain and loss
accounts automatically to book this difference.
opw-687975
The company currency is USD, the invoice currency is EUR.
- Create an invoice in EUR, set an invoice date
- Compute the taxes (click on "update" button)
- Change the exchange rate between EUR and USD
- Validate the invoice
At validation, the tax lines are not recomputed. Therefore, the tax
amounts, are still converted in the company currency using the old
rates. On the other hands, the other account move lines will have the
appropriate new rate.
Closes#14024
opw-692430
The company currency is USD, the invoice currency is EUR.
- Create an invoice in EUR, set an invoice date
- Compute the taxes (click on "update" button)
- Change the exchange rate between EUR and USD
- Validate the invoice
At validation, the tax amounts are not recomputed. Therefore, they are
still converted in the company currency using the old rate.
Closes#14024
opw-692430
when extending these methods with the new api, the context is a frozendict
so we need to copy before mutating.
this patch was made by searching for key addition to context and calls to the
update() method on the 8.0 addons, and checking if a copy was made before in
the method.
An issue occurs in the following situation:
- Define a currency exchange rate at day 1 and day 2
- Create an invoice at day 1, and calculate the taxes. Do not set an
invoice date!
- Validate the invoice at day 2
The exchange rate for taxes is the rate at day 1, while the exchange
rate for other amounts is the rate at day 2.
There is actually no way to know what was the rate applied for the
taxes at invoice validation. There are two solutions:
- recompute the taxes at validation
- force the user to set an invoice date and recompute manually the
taxes
The first solution might have unexpected effects, therefore the second
solution is applied.
Fixes#13473
opw-688517
This commit avoid a traceback when you open the form account_invoice_line
for a supllier invoice without having installed purchase.
The fields_view_get method add domain with purchase_ok field, but this
field can be missing on the model product.template because purchase is not
a dependence of account.
Invalid field 'purchase_ok' in leaf "<osv.ExtendedLeaf:
('purchase_ok', '=', True) on product_product
In stable version, the best fix found, is to remove the domain.
But we need to fix it in master, moving this field from purchase module to
product module. (odoo/odoo##13271)
This commit closes#13268 and closes#315 for stable version.
Todo: merge odoo/odoo#13271 in master (@qdp-odoo agreement)
When the General Ledger is printed, the initial balance is zero if the
filtering is done by period.
It appears that in this case, the method `_query_get` selects all the
periods before the selected period range thanks to:
`build_ctx_periods(cr, uid, first_period, context['period_from'])`
On the other hand, `_query_get` builds the query as:
`date_start <= %(date_start)s AND id NOT IN %(period_ids)s`
That doesn't make sense since we first choose the periods before the
selected period range, then we exclude them. What the method
`_query_get` is doing seems wrong, but since this method is used in many
reports, it is safer to only fix the GL report directly.
Another solution could be
https://gist.github.com/nim-odoo/453176d9ae820615e69f9a809a3780cc
opw-681601
Posted moves are not protected from modification if the journal is set
to 'autopost'.
If an account move is posted in a journal with 'Autopost' set, it is
possible to modify the associated move lines without any restriction.
This can for example lead to the creation of unbalanced moves.
The original issue fixed by this extra condition
(https://bugs.launchpad.net/openobject-addons/+bug/615268) does not
occur if the commit is reverted.
This reverts 4e95e4223Closes#12014
opw-683165
"total_invoiced" must only take customer invoices into account because
when you click on the button "invoiced" in the partner view form
you just see the customer invoices.
Adaptation for 8.0 of 9.0 fix made at 37569695
Closes#12044
qdp-odoo
Pedro M. Baeza
Odoo Translation Bot
Luc De Meyer
Goffin Simon
chafique-delli
Stefan Rijnhart
Nicolas Martinelli
Alexandre Fayolle
Jeremy Kersten
Martin Trigaux
Christophe